Re: how to build packages with a specific complier ?
Le 16/06/2016 à 16:39, Gianfranco Costamagna a écrit : > Hi, > > >> # CC=gcc-6 \> #CPP=cpp-6 >> # >> # RICHARD, IS IT CORRECT ? > > nope :) > > anyway, I did > create a chroot with the build dependencies > check if the library was not installed (the one you didn't like) > git clone > dpkg-buildpackage &> ../log > > installed gcc-6 stuff > your workaround in configure > dpkg-buildpackage &> ../log2 > > well, gcc-6 was detected, but not used during build > > so I did export CC=gcc-6 CPP=cpp-6 > dpkg-buildpackage &> ../log3 > > here I can see that gcc-6 and gpp-6 are called in configure, build and test. > > Attached logs for the last try and the three log log2 and log3 > > G. May I ask you another test, please ? # Clone gnustep-base git clone https://anonscm.debian.org/git/pkg-gnustep/gnustep-base.git # Enter in gnsutep-base dir cd gnustep-base # Install build-dependencies # (libffcall1-dev IS REPLACING libffi-dev) apt-get --no-install-recommends install debhelper gnustep-make gobjc-5 libxml2-dev libxslt1-dev libgnutls28-dev zlib1g-dev m4 libavahi-client-dev libicu-dev dh-autoreconf dh-exec texinfo texlive-latex-base texlive-fonts-recommended xml-core build-essential libffcall1-dev # 1- gcc-5 with libffcall1-dev # Make sure libffi is NOT installed apt remove libffi-dev libffi6 libffi6-dbg # Replace libffi-dev by liffcall1-dev # in debian/control AND debian/templates/control.m4 # Edit debian debian/rules, # in the override_dh_auto_configure target: # #dh_auto_configure -- \ # ac_cv_lib_kvm_kvm_getenvv=no \ #--disable-bfd \ # --disable-libffi \ #--enable-ffcall # build package with default compiler # Send me the Tests/tests.log file 2 -gcc-6 with libffcall1-dev #rebuild package with gcc-6 # Send me the Tests/tests.log file Thanks Eric
Re: how to build packages with a specific complier ?
Le 16/06/2016 à 16:39, Gianfranco Costamagna a écrit : > Hi, > > >> # CC=gcc-6 \> #CPP=cpp-6 >> # >> # RICHARD, IS IT CORRECT ? > > nope :) > > anyway, I did > create a chroot with the build dependencies > check if the library was not installed (the one you didn't like) > git clone > dpkg-buildpackage &> ../log > > installed gcc-6 stuff > your workaround in configure > dpkg-buildpackage &> ../log2 > > well, gcc-6 was detected, but not used during build > > so I did export CC=gcc-6 CPP=cpp-6 > dpkg-buildpackage &> ../log3 > > here I can see that gcc-6 and gpp-6 are called in configure, build and test. > > Attached logs for the last try and the three log log2 and log3 > > G. Thanks to you Gianfranco, we now know that the issue is not at gcc level.
Re: how to build packages with a specific complier ?
Le 16/06/2016 à 10:37, Gianfranco Costamagna a écrit : > Hi, > >> As far as I know, the plan is to switch to gcc-6 by default for stretch: >> https://lists.debian.org/debian-gcc/2016/01/msg00100.html >> so while identifying and backporting the fix to gcc-5 would be nice, I'd >> recommend not putting too much effort there. > > fully agree, this is why I didn't bother about bisecting the issue. > > Eric, if you want a test build on a porterbox I can do it, just > give me a list of commands to issue and I'll happily execute them for you > (please note: porterboxes don't allow "everything", so debugging might not > be trivial to perform) > > G. First test: # Install git-buildpackage and build-essential if needed apt-get --no-install-recommends install git-buildpackage build-essential # Clone gnustep-base gbp clone https://anonscm.debian.org/git/pkg-gnustep/gnustep-base.git # Enter in gnsutep-base dir cd gnustep-base # Install build-dependencies apt-get --no-install-recommends install debhelper gnustep-make gobjc-5 libffi-dev libxml2-dev libxslt1-dev libgnutls28-dev zlib1g-dev m4 libavahi-client-dev libicu-dev dh-autoreconf dh-exec texinfo texlive-latex-base texlive-fonts-recommended xml-core # 1- gcc-6 with libffi-dev # Install gcc-6 and gobjc-6 sudo apt-get --no-install-recommends install gcc-6 gobjc-6 # Make sure libffi-dev is installed apt-get --no-install-recommends install libffi-dev # Make sure ffcall is not-installed apt remove libffcall1-dev libffcall1 # Edit debian debian/rules, # in the override_dh_auto_configure target, # add CC= to dh_auto_configure : # #dh_auto_configure -- \ # ac_cv_lib_kvm_kvm_getenvv=no \ #--disable-bfd \ # CC=gcc-6 \ #CPP=cpp-6 # # RICHARD, IS IT CORRECT ? # build package gbp buildpackage --git-ignore-new # Send me the Tests/tests.log file # and ../gnustep-base_1.24.9-1_s390x.build # (you can rename them) Thanks Eric
Re: how to build packages with a specific complier ?
Le 16/06/2016 à 10:37, Gianfranco Costamagna a écrit : > Hi, > >> As far as I know, the plan is to switch to gcc-6 by default for stretch: >> https://lists.debian.org/debian-gcc/2016/01/msg00100.html >> so while identifying and backporting the fix to gcc-5 would be nice, I'd >> recommend not putting too much effort there. > > fully agree, this is why I didn't bother about bisecting the issue. > > Eric, if you want a test build on a porterbox I can do it, just > give me a list of commands to issue and I'll happily execute them for you > (please note: porterboxes don't allow "everything", so debugging might not > be trivial to perform) > > G. Thanks Gianfranco, There just two tests to do: * build gnustep-make with gcc-6 I think a CC var should be set when calling configure script (Richard ?) in debian/rules. * replace libffi-dev build-dependency by libffcall1-dev. (and trying to build with ggc-5 and gcc-6) Eric
Re: how to build packages with a specific complier ?
Le 15/06/2016 à 23:20, Jerome BENOIT a écrit : > > On 15/06/16 20:54, Eric Heintzmann wrote: >> How can we debug with upstream, without any access to a 390x machine ? > > You can ask for an access to Debian Porter machine: > https://db.debian.org/machines.cgi > https://dsa.debian.org/doc/schroot/ I'm not DD nor DM, but can I have an access to zelenka.debian.org ? If yes, where should I ask ? Thanks
Bug#827383: RFS: gmp-ecm/7.0.1+ds-2 [RC] -- Factor integers using the Elliptic Curve Method
Le 15/06/2016 à 23:12, Jerome BENOIT a écrit : > Hello Eric, > > On 15/06/16 20:57, Eric Heintzmann wrote: > > > > Le 15/06/2016 à 16:41, Jerome Benoit a écrit : > >> Package: sponsorship-requests > >> Severity: serious > >> Justification: fails to build from source (but built successfully > in the past) > >> > >> Dear Sponsors, > >> > >> I am looking for sponsorship for the Debian package gmp-ecm > [1], a mathematical package. > >> This release mainly works around an unisolated gcc-5 issue for > arch s390x which caused > >> a FTBFS. > >> > > How did you fixed this issue ? > > I would like to use you solution on gnustep-base. > > The lazy way. As it works well with gcc-6, the package is built with > gcc-6 (only on s390x arch). > See the git repository at Alitoh (and certainly sooner, the source > material at Debian Sources). Thanks for you quick answer. In your changelogs you write about a not isolated gcc. Is there a bug report somewhere (in debian, in gcc upstream ...)? Thanks signature.asc Description: OpenPGP digital signature
Bug#827383: RFS: gmp-ecm/7.0.1+ds-2 [RC] -- Factor integers using the Elliptic Curve Method
Le 15/06/2016 à 16:41, Jerome Benoit a écrit : > Package: sponsorship-requests > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Dear Sponsors, > > I am looking for sponsorship for the Debian package gmp-ecm [1], a > mathematical package. > This release mainly works around an unisolated gcc-5 issue for arch > s390x which caused > a FTBFS. > How did you fixed this issue ? I would like to use you solution on gnustep-base. Thanks Eric
Re: how to build packages with a specific complier ?
Le 15/06/2016 à 14:16, Gianfranco Costamagna a écrit : > Hi, > >> It appears that some tests fail for one of my package (gmp-ecm) on one >> architecture (s390x): >> after some investigation, it appears that it is a compiler issue: building >> with gcc-6 (instead of gcc-5) >> causes no issue. So now I want to impose the gcc-6 to d/rules ? What is the >> best way to do so ? I have a similar issue with gnustep-base package on s390x arch: some tests fails. > > Debug and fix gcc-5 is preferred, otherwise something like > How can we debug with upstream, without any access to a 390x machine ? Thanks Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi Gianfranco, Le 16/05/2016 15:16, Gianfranco Costamagna a écrit : > Hi Eric, > > nice indeed, so please wait some more time, and ping me back in 7-15 days if > nobody > picked up the work in the meanwhile. > > Iain R. Learmonth has uploaded gnustep-make. Thanks to you for helping me to improve gnustep-make packaging. Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
oops ! accidentally removed gsdh_gnustep symlinks ! Fixed and reuploaded add this line to changelog * Provide a new debian/gnustep-make.links. https://mentors.debian.net/package/gnustep-make or dget -x https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi
Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
What is the second question ?
Thanks
Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 17/05/2016 19:27, Eric Heintzmann a écrit :
> Hi,
> Reuploaded !
https://mentors.debian.net/package/gnustep-make
or
dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
Updated changelog:
gnustep-make (2.6.8-1) unstable; urgency=low
* Team upload.
* In agreement with the Debian GNUstep maintainers,
add myself as new Co-Maintainer.
* New upstream version
* Remove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
* Update no-gzip-timestamps.patch.
* Update use-makeinfo.patch.
* Bump Standards-Version to 3.6.8 in debian/control.
* Set debhelper compatibility level to 9.
* Update Vcs-* fields in debian/control
* Rewrite debian/rules:
+ Use dh $@ --with autoreconf and --buiddirectory
+ No more use autotools-dev: drop dependencies
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
- remove fhs-system-includedir.patch
- remove obsolete {gnustep:Depends} var in debian/control
+ Remove debian/control.in file, useless now
+ Remove debian/fhs/gnustep-common.disr.in, now useless
+ Remove debian/fhs/gnustep-common.links.in, now useless
+ Remove debian/gnustep-make.dirs.in, now useless
* Provide a new debian/clean file.
* Update debian/copyright file.
* Update debian/watch file to version 4.
* Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
* Provide a new debian/gnustep-make-doc.install file.
* Provide a new debian/gnustep-make-doc.info file.
* Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
* Provides new debian/gnustep-make-doc.doc-base.* files.
* Provide a new debian/gnustep-make.install file.
* Provide a new debian/gnustep-make.lintian-overrides file.
* Provide a new debian/gnustep-make.manpages file:
remove debian/gnustep-test.1 file, useless now.
* Provide a new debian/gnustep-make.docs file.
* Rename debian/fhs dir to debian/dh_gnustep.
* gnustep-make now Depends on {perl:Depends}
* New debian/addons dir:
+ remove debian/gs_make.in and debian/config.mk.in, now useless
+ new gs_make and config.mk files in debian/addons dir
+ move debian/gs_make.1 to debian/addons dir
* Remove debian/gnustep-make.dirs.in, useless now.
* Provide a new debian/gnustep-common.maintscript file.
* Provide a new debian/gnustep-common.install file.
* Provide a new debian/gnustep-common.manpages file.
* Provide a new debian/gnustep-common.docs file.
* Provide a new debian/gnustep-common.dirs file.
* Provide a new debian/gnustep-common.links file.
* Provide a new debian/gnustep-common.lintian-overrides file.
* Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces and Breaks gnustep-common (<<2.6.8-1).
-- Eric Heintzmann <heintzmann.e...@free.fr> Tue, 03 May 2016 22:13:30
+0200
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi,
Reuploaded !
Le 17/05/2016 18:58, Eric Heintzmann a écrit :
>
>
> Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
>> Hi,
>>> switch to autoreconf done
>>
>> nice!
>>
>> little nitpick before answering to the open points:
>> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
>> +
>> errors.
>>
>>
>> there is a new space in changelog
>> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff
>> the debian changes, you will
>> see it)
>>
> Fixed, thanks
>
>
>>> Breaks + Replace done
>> Depends: gnustep-common (>= ${source:Version}),
>> gnustep-common (<< ${source:Version}.1~),
>> gobjc,
>> -autotools-dev,
>> ${misc:Depends},
>> -${gnustep:Depends}
>> +${perl:Depends}
>> +Replaces: gnustep-common (<< 2.6.8-1)
>> +Breaks: gnustep-common (<< 2.6.8-1)
>>
>>
>>
>> seems fine [1], just two questions: why did you drop gnustep:Depends?
> Let see at dh_gnustep manpage:
>
> "dh_gnustep is a program based on debhelper that is responsible for
> doing GNUstep-specific modifications, such as moving files in the
> GNUstep hierarchy within the System domain, rooted at
> /usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
> (FHS)-compliant locations."
>
> it is obsoleted by configure option --with-layout=debian
> And I have no perl skills to update it.
>
>
> Let s look again at dh_gnustep manpage:
>
> "GNUstep dependencies:
> Adds any extra dependencies needed for GNUstep. Currently, the
> only dependency added is to ensure that the package uses the same
> filesystem layout as the other GNUstep packages installed on the
> system."
>
> In reality {gnustep:Depends} just add a dependencies to virtual package
> provided by gnustep-common: gnustep-fslayout-fhs
> Of course I can add a dependency to gnustep-fslayout-fhs,
> but since gnustep-make depends on latest gnustep-common,
> it is not needed.
>
> I will update changelog like that:
>
> + Use --with-layout=debian in configure scripts:
> - remove fhs-system-includedir.patch
> - remove obsolete {gnustep:Depends} var in debian/control
>> [1]
>> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
>
> Thanks for the link
>
> Thanks,
> Eric
>
>
>
>
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 17/05/2016 11:52, Gianfranco Costamagna a écrit :
> Hi,
>> switch to autoreconf done
>
>
> nice!
>
> little nitpick before answering to the open points:
> * debian/patches/manpage-spelling-errors.patch: New, fix two spelling
> +
> errors.
>
>
> there is a new space in changelog
> (pull-debian-source gnustep-make debdiff of the two dsc files, filterdiff the
> debian changes, you will
> see it)
>
Fixed, thanks
>> Breaks + Replace done
>
> Depends: gnustep-common (>= ${source:Version}),
> gnustep-common (<< ${source:Version}.1~),
> gobjc,
> -autotools-dev,
> ${misc:Depends},
> -${gnustep:Depends}
> +${perl:Depends}
> +Replaces: gnustep-common (<< 2.6.8-1)
> +Breaks: gnustep-common (<< 2.6.8-1)
>
>
>
> seems fine [1], just two questions: why did you drop gnustep:Depends?
Let see at dh_gnustep manpage:
"dh_gnustep is a program based on debhelper that is responsible for
doing GNUstep-specific modifications, such as moving files in the
GNUstep hierarchy within the System domain, rooted at
/usr/lib/GNUstep/System, to Filesystem Hierarchy Standard
(FHS)-compliant locations."
it is obsoleted by configure option --with-layout=debian
And I have no perl skills to update it.
Let s look again at dh_gnustep manpage:
"GNUstep dependencies:
Adds any extra dependencies needed for GNUstep. Currently, the
only dependency added is to ensure that the package uses the same
filesystem layout as the other GNUstep packages installed on the
system."
In reality {gnustep:Depends} just add a dependencies to virtual package
provided by gnustep-common: gnustep-fslayout-fhs
Of course I can add a dependency to gnustep-fslayout-fhs,
but since gnustep-make depends on latest gnustep-common,
it is not needed.
I will update changelog like that:
+ Use --with-layout=debian in configure scripts:
- remove fhs-system-includedir.patch
- remove obsolete {gnustep:Depends} var in debian/control
>
> [1]
> http://debomatic-amd64.debian.net/distribution#unstable/gnustep-make/2.6.8-1/piuparts
Thanks for the link
Thanks,
Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi,
Le 16/05/2016 21:15, Gianfranco Costamagna a écrit :
> Hi Eric,
>
>
> As you wish, you can switch in a later upload, or do it now and maybe
> fix/revert in case of troubles
switch to autoreconf done
> I don't think so, but I can review a patch/package, because some lines
> without their context have no meaning (you need to put the
> breaks+replaces in the right binary package).
Breaks + Replace done
>> OK, I'm going to update gnustep make to do improvements you suggested.
>> Since I am not familiar with mentors rules, I have a question :
>> Should I prepare a new revision (ie 2.6.8-2) or should I update the
>> 2.6.8-1 revision and reupload it ?
>
> please upload -1 revision until it gets sponsored!
OK I've just reuploaded gnustep-make 2.6.8-1
Changes:
Updated changelog
Updated control file
Remove all debian/*/*.in files
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/gnustep-make
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
Changelog:
gnustep-make (2.6.8-1) unstable; urgency=low
* Team upload.
* In agreement with the Debian GNUstep maintainers,
add myself as new Co-Maintainer.
* New upstream version
* Rremove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
* Update no-gzip-timestampss.patch.
* Update use-makeinfo.patch.
* Bump Standards-Version to 3.6.8 in debian/control.
* Set debhelper combatibility level to 9.
* Update Vcs-* fields in debian/control
* Remove no more needed {gnustep:Depends} var in debian/control.
* Rewrite debian/rules:
+ Use dh $@ --with autotools-dev and --buiddirectory
+ No more use autotools-dev: drop dependencies
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
remove fhs-system-includedir.patch
+ Remove debian/control.in file, useless now
+ Remove debian/fhs/gnustep-common.disr.in, now useless
+ Remove debian/fhs/gnustep-common.links.in, now useless
+ Remove debian/gnustep-make.dirs.in, now useless
* Provide a new debian/clean file.
* Update debian/copyright file.
* Update debian/watch file to version 4.
* Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
* Provide a new debian/gnustep-make-doc.install file.
* Provide a new debian/gnustep-make-doc.info file.
* Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
* Provides new debian/gnustep-make-doc.doc-base.* files.
* Provide a new debian/gnustep-make.install file.
* Provide a new debian/gnustep-make.lintian-overrides file.
* Provide a new debian/gnustep-make.manpages file:
remove debian/gnustep-test.1 file, useless now.
* Provide a new debian/gnustep-make.docs file.
* Rename debian/fhs dir to debian/dh_gnustep.
* gnustep-make now Depends on {perl:Depends}
* New debian/addons dir:
+ remove debian/gs_make.in and debian/config.mk.in, now useless
+ new gs_make and config.mk files in debian/addons dir
+ move debian/gs_make.1 to debian/addons dir
* Remove debian/gnustep-make.dirs.in, useless now.
* Provide a new debian/gnustep-common.maintscript file.
* Provide a new debian/gnustep-common.install file.
* Provide a new debian/gnustep-common.manpages file.
* Provide a new debian/gnustep-common.docs file.
* Provide a new debian/gnustep-common.dirs file.
* Provide a new debian/gnustep-common.links file.
* Provide a new debian/gnustep-common.lintian-overrides file.
* Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces: and Breaks gnustep-common (<<2.6.8-1).
-- Eric Heintzmann <heintzmann.e...@free.fr> Tue, 03 May 2016 22:13:30
+0200
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Hi Gianfranco,
Le 16/05/2016 21:15, Gianfranco Costamagna a écrit :
> Hi Eric,
>
>
>> I think there are too many changes in this release.
>> Is it okay to remove autoreconf for now,
>> and replace autotools-dev by autoreconf at next release ?
>
> it is, just a side note: I never had issues with that move, and in general
> issues
> arises when: the configure/Makefiles are patched (because you obviously need
> to patch
> configure.ac and Makefile.am instead), or bad config.guess/config.sub files
> (and usually the result is a build failure on some ports).
>
> As you wish, you can switch in a later upload, or do it now and maybe
> fix/revert in
> case of troubles
Finally, I'm going to swith to autoreconf now.
>> Reorg: gnustep-common and gnustep-make existed; move one file from
>> gnustep-common to gnustep-make; new gnustep-common does not require new
>> gnustep-make
>> Breaks: gnustep-make (<<2.6.8-1)
>> Breaks: gnustep-common (<<2.6.8-1)
>>
>> Is it okay to do that?
>
> I don't think so, but I can review a patch/package, because some lines
> without their
> context have no meaning (you need to put the breaks+replaces in the right
> binary
> package).
Finally, I reflected and I think we should not mix different version of
gnustep-make and gnustep-common binary packages.
It is unsupported by upstream andI could lead to strange bugs.
gnustep-common will Breaks: gnustep-make (<< {source:Version})
and
gnustep-make will Depends: gnustep-common(>= {source:Version}
It should prevents the mix of versions and thus Break or Replaces are
now useless
Thanks
Eric
signature.asc
Description: OpenPGP digital signature
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 16/05/2016 15:16, Gianfranco Costamagna a écrit : > Hi Eric, > > > >> Well autotools-dev already used. No changes here. >> About autoreconf, I'm not familiar with it. >> I installed it to test it. Since all seems ok, I've not removed it. > > https://wiki.debian.org/Autoreconf > > I was talking more about removing autotools-dev I think there are too many changes in this release. Is it okay to remove autoreconf for now, and replace autotools-dev by autoreconf at next release ? > > > 3) +Replaces: gnustep-common (<< 2.6.8-1) > > this is something I don't understand. > If you upgrade gnustep make bin package with old gnustep-common installed, > we need to replace the gnustep-config.1 manpage. > > > that file is currently inside gnustep-common > > and you moved into gnustep-make > https://packages.debian.org/sid/alpha/gnustep-common/filelist Yes, the executable was in gnustep-make, thus i moved the manpage to gnustep-make. > > you probably need some more keywords to ensure a good upgrade path > https://wiki.debian.org/PackageTransition Reorg: gnustep-common and gnustep-make existed; move one file from gnustep-common to gnustep-make; new gnustep-common does not require new gnustep-make Breaks: gnustep-make (<<2.6.8-1) Breaks: gnustep-common (<<2.6.8-1) Is it okay to do that? >> Yes, this is a consequence of the debian/rules rewriting. > > line 25, you could add something like "remove control.in file, useless now" > or similar wording, that one was my question OK, i m going to do that > >> I tested it with latest upstream version of gnustep-base, gnustep-gui >> and and gnustep-back, >> and all seems okay. I >> tried it with several GNUstep related debian packages and all seems to >> works fine. >> I also tried to rebuild several debian gnustep packages with it and I >> did not find any FTBFS. > > nice indeed, so please wait some more time, and ping me back in 7-15 days if > nobody > picked up the work in the meanwhile. OK, I'm going to update gnustep make to do improvements you suggested. Since I am not familiar with mentors rules, I have a question : Should I prepare a new revision (ie 2.6.8-2) or should I update the 2.6.8-1 revision and reupload it ? Thanks Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
>> also, the control.in file removal is not documented I guess > Yes, this is a consequence of the debian/rules rewriting. I mean I've removed control target in debian/rules file, thus I removed control.in which was not needed any longer. Thanks Eric
Bug#824262: Fwd: Re: gnustep-make ack
Ack from Gurkan. Yavor doesn't reply to email. Message transféré Return-Path:gur...@phys.ethz.ch Received: from zimbra89-e15.priv.proxad.net (LHLO zimbra89-e15.priv.proxad.net) (172.20.243.140) by zimbra89-e15.priv.proxad.net with LMTP; Mon, 16 May 2016 13:52:13 +0200 (CEST) Received: from phd-imap.ethz.ch (mx15-g26.priv.proxad.net [172.20.243.85]) by zimbra89-e15.priv.proxad.net (Postfix) with ESMTP id BFD2E3085DC for <heintzmann.e...@free.fr>; Mon, 16 May 2016 13:52:12 +0200 (CEST) Received: from phd-imap.ethz.ch ([129.132.80.51]) by mx1-g20.free.fr (MXproxy) with ESMTPS for heintzmann.e...@free.fr (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256); Mon, 16 May 2016 13:52:09 +0200 (CEST) X-ProXaD-SC:state=HAM score=0 Received: from localhost (phd-mailscan.ethz.ch [192.168.127.2]) by phd-imap.ethz.ch (Postfix) with ESMTP id 3r7f2h1CwNzjc2 for <heintzmann.e...@free.fr>; Mon, 16 May 2016 13:52:12 +0200 (CEST) X-Virus-Scanned:Debian amavisd-new at phys.ethz.ch Received: from phd-mxin.ethz.ch ([IPv6::::192.168.127.53]) by localhost (phd-mailscan.ethz.ch [:::192.168.127.2]) (amavisd-new, port 10024) with LMTP id fFYxFNg-qXuB for <heintzmann.e...@free.fr>; Mon, 16 May 2016 13:52:12 +0200 (CEST) Received: from [10.0.1.14] (84-73-61-124.dclient.hispeed.ch [84.73.61.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gur...@phd-mxin.ethz.ch) by phd-mxin.ethz.ch (Postfix) with ESMTPSA id 3r7f2h0CRBzQ50 for <heintzmann.e...@free.fr>; Mon, 16 May 2016 13:52:12 +0200 (CEST) From: Gürkan Myczko <gur...@phys.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject:Re: gnustep-ameke ack Message-Id: <4397053c-73d5-4402-adc6-8f5c8fa5f...@phys.ethz.ch> Date: Mon, 16 May 2016 13:52:11 +0200 References: <5739ae33.40...@free.fr> In-Reply-To:<5739ae33.40...@free.fr> To: Eric Heintzmann <heintzmann.e...@free.fr> X-Mailer: iPhone Mail (13F68) Hi eric I am glad if you do so, thank you! Gürkan > On May 16, 2016, at 13:25, Eric Heintzmann <heintzmann.e...@free.fr> wrote: > > Hi Gurkan, > > Can you give an ack to add myself as uploader of gnustep-make ? At: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824262 > > Thanks > > Eric >
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 16/05/2016 12:40, Gianfranco Costamagna a écrit : > control: tags -1 moreinfo > > Hi Eric, some questions on the changes: > 1) why do you need both autotools-dev and autoreconf? Well autotools-dev already used. No changes here. About autoreconf, I'm not familiar with it. I installed it to test it. Since all seems ok, I've not removed it. > > 2) did you get an ack from maintainers to add yourself as uploader Yes. In addition, I've just asked them to post their ask on this list now. > > > 3) +Replaces: gnustep-common (<< 2.6.8-1) > > this is something I don't understand. If you upgrade gnustep make bin package with old gnustep-common installed, we need to replace the gnustep-config.1 manpage. > > also, the control.in file removal is not documented I guess Yes, this is a consequence of the debian/rules rewriting. > > maybe Aron (ccd), being the latest sponsor might give you an additional > review and sponsor the package Thanks for the tip. > > thanks for the really nice work! Thanks, I worked hard last week with upstream. > I did a test build and the build logs looks good to be, as well as the built > binaries (however I didn't install them). I tested it with latest upstream version of gnustep-base, gnustep-gui and and gnustep-back, and all seems okay. I tried it with several GNUstep related debian packages and all seems to works fine. I also tried to rebuild several debian gnustep packages with it and I did not find any FTBFS. Eric
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 15/05/2016 03:26, Adam Borowski a écrit : > On Sun, May 15, 2016 at 03:04:37AM +0200, Eric Heintzmann wrote: >> Le 15/05/2016 02:46, Adam Borowski a écrit : >>> On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote: >>>> I am looking for a sponsor for my package "gnustep-make" >>>> >>>> * Package name: gnustep-make >>>>Version : 2.6.8-1 >>>> >>>> dget -x >>>> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc >>> As there's LOADS of packaging changes, could you please push them to a VCS? >>> That'd make reviewing greatly easier. From the new changelog I assume you >>> used git, I just don't see anything new past 2.6.6-3 on any branches on >>> pkg-gnustep/gnustep-make.git. >> Sorry, but I've not used git nor any VCS because I work all alone >> since I am the last active member of the Debian GNUstep maintainers. >> If I had knew that make reviewing easier, I would have used Git. >> If you want I can push my changes on pkg-gnustep/gnustep-make.git >> but there will be only one big commit. >> Sorry, I ve done a mistake how can I repair it ? > Oif. I guess trying to split this big commit would be far more work than > just reviewing it the hard way, so there's nothing that can be done here. > That's unfortunate as it raises the difficulty of review considerably. > > As gnustep-make is a complex package I'm not familiar with, I'm afraid > I'll leave it to someone with more time and experience. > I think I can split this big commit in multiple commits, one for each file. If needed I will do it. Thanks
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Le 15/05/2016 02:46, Adam Borowski a écrit : > Hi! > > On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote: >> I am looking for a sponsor for my package "gnustep-make" >> >> * Package name: gnustep-make >>Version : 2.6.8-1 >> >> dget -x >> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc > As there's LOADS of packaging changes, could you please push them to a VCS? > That'd make reviewing greatly easier. From the new changelog I assume you > used git, I just don't see anything new past 2.6.6-3 on any branches on > pkg-gnustep/gnustep-make.git. Sorry, but I've not used git nor any VCS because I work all alone since I am the last active member of the Debian GNUstep maintainers. If I had knew that make reviewing easier, I would have used Git. If you want I can push my changes on pkg-gnustep/gnustep-make.git but there will be only one big commit. Sorry, I ve done a mistake how can I repair it ? Thanks
Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "gnustep-make"
* Package name: gnustep-make
Version : 2.6.8-1
Upstream Author : GNUstep Maintainer <gnustep-maintai...@gnu.org>
* URL : http://gnustep.org
* License : GPL-3+
Section : gnustep
It builds those binary packages:
gnustep-common - Common files for the core GNUstep environment
gnustep-make - GNUstep build system
gnustep-make-doc - Documentation for GNUstep Make
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/gnustep-make
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
More information about GNUstep can be obtained from
http://gnustep.org/information/aboutGNUstep.html
Changes since the last upload:
gnustep-make (2.6.8-1) unstable; urgency=low
.
* Team upload.
* Add myself as new Co-Maintainer.
* New upstream version
* Rremove patches applied upstream:
+ honor-CFLAGS.patch
+ info-document-missing-direntry.patch
+ library-combo-whatis-entry.patch
+ manpage-spelling-errors.patch
+ test-clean-core.patch
+ texi-section-level.patch
* Update no-gzip-timestampss.patch.
* Update use-makeinfo.patch.
* Bump Standards-Version to 3.6.8 in debian/control.
* Set debhelper combatibility level to 9.
* Update Vcs-* fields in debian/control
* Remove no more needed {gnustep:Depends} var in debian/control.
* Rewrite debian/rules:
+ Use dh $@ --with autotools-dev, autoreconf and buiddirectory
+ Disable strict gnustep-make version 2 mode for now
+ Build and install doc in *-indep sequence (Closes: #823281, #806197)
+ Use --with-layout=debian in configure scripts:
remove fhs-system-includedir.patch
* Provide a nex debian/clean file.
* Update debian/copyright file.
* Update debian/watch file to version 4.
* Replace debian/upstream/signig-key.pgp by signing-key.asc:
remove debian/source/include-binaries file.
* Provide a new debian/gnustep-make-doc.install file.
* Provide a new debian/gnustep-make-doc.info file.
* Rename debian/gnustep-make-doc.doc-base to
debian/gnustep-make-doc.doc-base.gnustep-make.
* Provides new debian/gnustep-make-doc.doc-base.* files.
* Provide a new debian/gnustep-make.install file.
* Provide a new debian/gnustep-make.lintian-overrides file.
* Provide a new debian/gnustep-make.manpages file.
* Provide a new debian/gnustep-make.docs file.
* Rename debian/fhs dir to debian/dh_gnustep.
* New debian/addons dir: move gs_make and config.mk to it.
* Update debian/gnustep-common.dirs and debian/gnustep-common.links.
* Provide a new debian/gnustep-common.maintscript file.
* Provide a new debian/gnustep-common.install file.
* Provide a new debian/gnustep-common.manpages file.
* Provide a new debian/gnustep-common.docs file.
* Move gnustep-config.1 manpage to gnustep-make package:
gnustep-make now Replaces: gnustep-common (<< 2.6.8-1).
Regards,
Eric Heintzmann
Bug#823249: RFS: camera.app/0.8.0-10 [RC] -- GNUstep application for digital still cameras
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "camera.app"
* Package name: camera.app
Version : 0.8.0-10
Upstream Author : Stefan Kleine Stegemann <ste...@wms-network.de>
* URL : http://home.gna.org/gsimageapps/
* License : GPL-2.0+
Section : gnustep
It builds those binary packages:
camera.app - GNUstep application for digital still cameras
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/camera.app
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/camera.app/camera.app_0.8.0-10.dsc
Changes since the last upload:
* Team upload, in harmony with Gürkan,:
- move Debian GNUstep maintainer to Maintainer field,
- move Gürkan to Uploaders field,
- Add myself as new Co-Maintainer.
* Bump debhelper compat to 9.
* Upgrade to source format 3.0 (quilt).
* Bump Standards-Version to 3.9.8.
* Add Vcs-Browser and Vcs-Git fields.
* Update gnustep Build-Depends.
* Update libgphoto2-dev Build-Depends.
* Add ${misc:Depends} to Depends field.
* Update Description field.
* Reformat debian/copyright file.
* Provide a new debian/watch file.
* Rewrite debian/rules:
overrides 2 GNUmakefile.preamble variables (Closes: #820707).
* Update debian/Camera.desktop file (Closes: #618456)
and install it using debian/install file.
* According with lintian and #741573 don't install menu file any longer.
* According to debian policy 9.1.1, move
/usr/lib/GNUstep/Applications/Camera.app/Resources dir
to /usr/share/GNUstep/Camera.app:
- use debian/install file,
- use dh_symlink and dpkg-maintainer-script (and thus add dependency
to dpkg (>= 1.17.4)) to create symlink from old to new locations.
(provide new camera.app.links and new camera.app.maintscript files).
Regards,
Eric Heintzmann
