Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-17 08:07, Gianfranco Costamagna wrote: Hi all changed something and sponsored in deferred/12 Thanks, this has been a good learning experience. Also thanks for fixing the bug references! Thomas
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-16 10:00, Gianfranco Costamagna wrote: dh_auto_configure already injects some flags such as libdir and multiarch stuff it would be nice to remove them [..] Also, please take the opportunity to fix the changelog as josch pointed out :) Hi Gianfranco and Johannes, the issues you mentioned should be now fixed in the last update on mentors. Thanks, Thomas
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Hi Thomas,
(package removed from deferred queue)
>I have uploaded a new version to mentors with the two changes you
>mentioned in your mails today:
>- Using dh_auto_configure instead of calling ./configure directly.
mm nack :)
dh_auto_configure already injects some flags such as libdir and multiarch stuff
it would be nice to remove them
dh_auto_configure -- --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu
--htmldir=\${prefix}/share/doc/libcgicc-doc/html --disable-demos
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--prefix=/usr --libdir=\${prefix}/lib/x86_64-linux-gnu
--htmldir=\${prefix}/share/doc/libcgicc-doc/html --disable-demos
I think some duplication can be avoided :)
>- Removed the Replaces and Conflicts directive for the binary package.
>
>Use this package if you deem those changes worth the hassle of
>re-uploading the package to deferred/15. If not, then I'm happy to keep
>the changes for the next time I need to update the cgicc package.
this change is nice
Also, please take the opportunity to fix the changelog as josch
pointed out :)
thanks a lot!
Gianfranco
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-15 12:35, Gianfranco Costamagna wrote: BTW for a next update would be nice to consider using dh_auto_configure instead of directly calling ./configure Hi Gianfranco, I have uploaded a new version to mentors with the two changes you mentioned in your mails today: - Using dh_auto_configure instead of calling ./configure directly. - Removed the Replaces and Conflicts directive for the binary package. Use this package if you deem those changes worth the hassle of re-uploading the package to deferred/15. If not, then I'm happy to keep the changes for the next time I need to update the cgicc package. Thanks, Thomas
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-11 22:22, Gianfranco Costamagna wrote: I see you forgot to probably run dh_clean (I see debian/autoreconf.before and debian/autoreconf.after files) D'oh. They were leftovers from a previous build and are gone now. and I still see a libcgicc3-dev package (instead of libcgicc-dev) Yes, that was my mistake; I misunderstood your suggestion and made libcgicc-dev a virtual package. The last update on mentors now consists of libcgicc3, libcgicc-dev and libcgicc-doc. Thanks, Thomas
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Gianfranco Costamagna: > Hi, > >> I have uploaded a new package to mentors, with the two outstanding > >> issues fixed. > > not sure... > I see you forgot to probably run dh_clean > (I see debian/autoreconf.before and debian/autoreconf.after files) > > [...] > > G. > That needs a "dh_autoreconf_clean" (before the dh_clean). Thanks, ~Niels
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Hi, >I have uploaded a new package to mentors, with the two outstanding >issues fixed. not sure... I see you forgot to probably run dh_clean (I see debian/autoreconf.before and debian/autoreconf.after files) and I still see a libcgicc3-dev package (instead of libcgicc-dev) >Thanks again for your patient and thorough reviews! thanks to you for fixing it :) I'm happy to see you keeping up with my reviews :D G.
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-11 16:18, Gianfranco Costamagna wrote: let me know that last two bits and I'll probably sponsor in deferred/10 (due to the high changes number) (Adding Chris to the loop, in case he as maintainer has a different opinion) Hi Gianfranco, I have uploaded a new package to mentors, with the two outstanding issues fixed. Thanks again for your patient and thorough reviews! Thomas
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Hi, >I missed to add you and 837...@bugs.debian.org in my last mail. In the >upload to mentors from last week I have addressed your feedback (at >least I think I did, that is). The only thing I'm not entirely sure >about is the missing build-dependency on pkg-config as build-dependency, >as described below. if not needed, it is fine to leave it out :) I have some last things to ask: if you bump compat level to 10, you can avoid dh-autoreconf at all Build-Depends: debhelper (>=10) Build-Depends-Indep: doxygen and in rules: "--with autoreconf" can be removed. Last thing: Package: libcgicc3-dev Provides: libcgicc3-dev well, every package provides itself :p I would change it to the unversioned libcgicc-dev because this way you will be able to rebuild reverse dependencies on next soname bump without having to perform sourceful uploads. let me know that last two bits and I'll probably sponsor in deferred/10 (due to the high changes number) (Adding Chris to the loop, in case he as maintainer has a different opinion) thanks! G.
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Hi Gianfranco, I missed to add you and 837...@bugs.debian.org in my last mail. In the upload to mentors from last week I have addressed your feedback (at least I think I did, that is). The only thing I'm not entirely sure about is the missing build-dependency on pkg-config as build-dependency, as described below. Cheers, Thomas On 2016-10-02 18:07, Thomas Pircher wrote: On 2016-09-28 22:37, Gianfranco Costamagna wrote: [..] drop the explicit dependencies since dh-autoreconf already depends on automake and libtool? If this is the customary way then I'll drop the explicit dependencies on automake and libtool. I think so. dh-autoreconf should be enough (with an added pkg-config if needed, IIRC) Hi Gianfranco, automake and libtool are no longer explicit dependencies in my latest upload to mentors [1]. But I haven't added pkg-config. It is not required for building libcgicc and I could not find a mention of pkg-config in the dh-autoreconf documentation. But if I'm missing something than I'll be happy to add the build dependency. I think patching it to be architecture independent might be the best solution Thanks for that. I had not appreciated that packages may contain bit-identical files. That does indeed solve my problem, and I have patched out the --host and --libdir options and re-added the script to the package. Thanks again for your continuing efforts! Thomas [1] https://mentors.debian.net/package/libcgicc
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-28 22:37, Gianfranco Costamagna wrote: [..] drop the explicit dependencies since dh-autoreconf already depends on automake and libtool? If this is the customary way then I'll drop the explicit dependencies on automake and libtool. I think so. dh-autoreconf should be enough (with an added pkg-config if needed, IIRC) Hi Gianfranco, automake and libtool are no longer explicit dependencies in my latest upload to mentors [1]. But I haven't added pkg-config. It is not required for building libcgicc and I could not find a mention of pkg-config in the dh-autoreconf documentation. But if I'm missing something than I'll be happy to add the build dependency. I think patching it to be architecture independent might be the best solution Thanks for that. I had not appreciated that packages may contain bit-identical files. That does indeed solve my problem, and I have patched out the --host and --libdir options and re-added the script to the package. Thanks again for your continuing efforts! Thomas [1] https://mentors.debian.net/package/libcgicc
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
Hi > They are both used in the build. But if I understand you right, are you > suggesting to drop the explicit dependencies since dh-autoreconf already > depends on automake and libtool? If this is the customary way then I'll > drop the explicit dependencies on automake and libtool. I think so. dh-autoreconf should be enough (with an added pkg-config if needed, IIRC) > This file is made obsolete by the pkg-config file, and it was creating a > problem for multiarch packages: it would install in > /usr/bin/cgicc-config, making it impossible to install two architectures > of this package. this is a problem when the files are not bit-bit identical between architecture, and this seems to be this case ## Host information --host)echo "x86_64-pc-linux-gnu" && exit 0 ;; this changes. You can patch that change out, as example you can grab what we did for libpng1.6[1] or try to print the triplet at runtime, when the user asks for it maybe dpkg-architecture has something interesting for you [1] https://sources.debian.net/src/libpng1.6/1.6.25-1/debian/patches/libpng-config.patch/ > | Using this kind of system to pass compile file is obsolete and will > likely introduce bugs in a multi-arch system. > | Particularly, this kind of script could only belong to a package that > is not Multi-Arch. > > So I took this as excuse to remove the file from the package. > > One possible solution (suggested by lintian) is to move the file out of > the way (to /usr/share/doc, I presume) so it is still shipped, but it >won't be found by build tools, which kind of defeats its purpose. I'm >doubtful there is any benefit in shipping this file. I think patching it to be architecture independent might be the best solution >As far as I can see from the CVS changes, the 'current' value in the >soname was increased in the early 2000's, presumably due to ABI changes. >Then in 2013 the soname was decreased from 5 to 3 in order to match the >library version. This was done as part of these bugs: > >I presume the package should follow the upstream soname. And this would >probably also justify the renamed package, as you were musing in your >mail. If there are no objections, I will rename the packages from >libcgicc5 to libcgicc. libcgicc3 you mean :) >This should be fixed by the renaming from libcgicc5* -> libcgicc*. always a final 3 >Raised as https://savannah.gnu.org/bugs/index.php?49120 >Thinking again, I guess that's not correct. This would require the >packages to be renamed to libcgicc3. oops you got it already >I have uploaded a new build to debian mentors for further review. I'll have a look if you can provide an answer to my above comments :) thanks! Gianfranco signature.asc Description: OpenPGP digital signature
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-18 19:11, Thomas Pircher wrote: Thinking again, I guess that's not correct. This would require the packages to be renamed to libcgicc3. Hi, I have uploaded a new build to debian mentors for further review. https://mentors.debian.net/package/libcgicc This build should address the issues raised on my previous upload, modulo mistakes and misinterpretations on my side. This version does rename the libraries to libcgicc3 (from libcgicc5), replacing and conflicting with the previous name. Thanks, Thomas
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-18 17:39, Thomas Pircher wrote: W: libcgicc5: package-name-doesnt-match-sonames libcgicc3 This should be fixed by the renaming from libcgicc5* -> libcgicc*. Thinking again, I guess that's not correct. This would require the packages to be renamed to libcgicc3. Thomas
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-15 10:49, Gianfranco Costamagna wrote: changes are huge, but being half mia, and on lowNMU threshold... (and too many bugs here, so lets do it) First of all, thanks for the detailed review. I have addressed most issues but not yet uploaded a new version to mentors, pending a couple of questions. 1) have patches been upstreamed? Patch 0001 (pkg-config change) comes from the upstream bug tracker and patch 0002 (empty index.html) has been upstreamed. Patch 0003 (removal of /usr/bin/cgicc-config, see also below, point 7) is not, since I see this as a packaging issue rather than an upstream problem. 2) patch description might be nice 3) d/p/003-no-old-style-config.patch So, in case please patch Makefile.am 4) automake, libtool, doxygen, dh-autoreconf doxygen might be needed only for arch:all builds, so you might want to move it into Build-Depends-Indep Fair points, my next upload to mentors will fix these. 5) automake, libtool, are them useful? They are both used in the build. But if I understand you right, are you suggesting to drop the explicit dependencies since dh-autoreconf already depends on automake and libtool? If this is the customary way then I'll drop the explicit dependencies on automake and libtool. 6) new files diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.dirs diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.install why? Uh, these files are not needed and are leftovers from my experiments with a multi-arch library and will be removed in my next upload. 7) /usr/bin/cgicc-config this was shipped before, why are you removing it? This file is made obsolete by the pkg-config file, and it was creating a problem for multiarch packages: it would install in /usr/bin/cgicc-config, making it impossible to install two architectures of this package. Also, https://lintian.debian.org/tags/old-style-config-script.html says: | Using this kind of system to pass compile file is obsolete and will likely introduce bugs in a multi-arch system. | Particularly, this kind of script could only belong to a package that is not Multi-Arch. So I took this as excuse to remove the file from the package. One possible solution (suggested by lintian) is to move the file out of the way (to /usr/share/doc, I presume) so it is still shipped, but it won't be found by build tools, which kind of defeats its purpose. I'm doubtful there is any benefit in shipping this file. 8) library changed soname? from libcgicc.so.5.0.2 to libcgicc.so.3.2.10 As far as I can see from the CVS changes, the 'current' value in the soname was increased in the early 2000's, presumably due to ABI changes. Then in 2013 the soname was decreased from 5 to 3 in order to match the library version. This was done as part of these bugs: https://savannah.gnu.org/bugs/?func=detailitem_id=38053 https://savannah.gnu.org/bugs/?func=detailitem_id=38224 I presume the package should follow the upstream soname. And this would probably also justify the renamed package, as you were musing in your mail. If there are no objections, I will rename the packages from libcgicc5 to libcgicc. W: libcgicc5: package-name-doesnt-match-sonames libcgicc3 This should be fixed by the renaming from libcgicc5* -> libcgicc*. X: libcgicc5: shlib-calls-exit usr/lib/x86_64-linux-gnu/libcgicc.so.3.2.10 (^^ this is something for upstream) Raised as https://savannah.gnu.org/bugs/index.php?49120 Thanks, Thomas
