Re: RFS: dnshistory (updated package)
Paul Wise writes: > On Sat, May 2, 2009 at 12:23 AM, Matthias Julius wrote: > >> As explained in another post this should not affect the user since the >> database format has not changed. > > Please investigate the DB->upgrade thing Clint mentioned and forward > that upstream, with a patch if you are able. Yes, I plan to do that. >> http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc > > Uploaded, thanks for your contriibution to Debian :) Thanks a lot. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
On Sat, May 2, 2009 at 12:23 AM, Matthias Julius wrote: > As explained in another post this should not affect the user since the > database format has not changed. Please investigate the DB->upgrade thing Clint mentioned and forward that upstream, with a patch if you are able. > I have not done anything about this. How much harm does this actually > do? At least this does not cause extra package dependancy because > libm comes with libc6. Very minimal, it just means dnshistory loads more libraries than it needs to and therefore uses slightly more RAM than it could. I suggest ignoring it for now, but sending a patch upstream for them to include in their VCS and the next release. > I think it might be appropriate to elevate this pedantic notice to > info level. I'm not sure if I agree, but please file a bug on lintian if you think that is the case. > I would welcome if you could have a look at the new package which is > at the same location on mentors: > > http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc Uploaded, thanks for your contriibution to Debian :) Please mail this list for future uploads and I will upload if I am able. It might be a good idea to make a patch that either sets the path in doc/dnshistory.1 based on the parameters to ./configure or removes the path from the manual page and send that upstream, so that less distributions need to patch that file or care about patching it. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Here we go ... Paul Wise writes: > On Tue, Apr 28, 2009 at 1:04 AM, Matthias Julius wrote: > >> I would really be grateful if someone could take a look at this >> package and possibly upload it for me. > > You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but > the current dnshistory package is built against libdb4.6. Should you > add another debian/NEWS entry about this? I'm not sure what to do in > this situation, could you investigate? As explained in another post this should not affect the user since the database format has not changed. > > Only the above is a blocker, some other things you may want to look at: > > Please use $(QUILT_STAMPFN) instead of patch in debian/rules. > > Please make build-stamp depend on configure-stamp. > > ./configure gets run twice on my machine in pbuilder due to the above > two issues. Fixed. > > For some reason the mktime test in ./configure takes ages and a lot of > CPU in pbuilder and then fails. This should be fixed by running autoconf from the configure target. > > I get one dpkg-shlibdeps warning, please ask upstream to remove -lm > from the link flags: > > dependency on libm.so.6 could be avoided if > "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked > against it (they use none of its symbols). I have not done anything about this. How much harm does this actually do? At least this does not cause extra package dependancy because libm comes with libc6. > > I get one lintian pedantic complaint: > > P: dnshistory: copyright-refers-to-symlink-license > usr/share/common-licenses/GPL This is fixed as well. I think it might be appropriate to elevate this pedantic notice to info level. I would welcome if you could have a look at the new package which is at the same location on mentors: http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Clint Adams writes: > Typically the fear which motivates this type of question is unfounded. > Looking at the dnshistory source code, it appears that the use of BDB > is trivial. Generally when the feature set you require could just > as easily have been satisfied by GDBM, there are rarely compatibility > worries. dnshistory is using simple B-trees, which haven't changed > incompatibly in over 5 years. > > If, in a future BDB version, the database file created by dnshistory > is using too old a format, the attempt to open it would return > DB_OLD_VERSION, and you could add code to dnshistory to DB->upgrade() > the file, seamlessly resolving the issue. > > It would be a different story if dnshistory were using transactions > or other subsystems. > > I believe this is a clear case of build-depending on libdb-dev being > the proper solution. Thank you for your explanation. I will keep it as it is then. And since the database format did not change from 4.6 to 4.7 there should be nothing for the user to worry about. I will take care of the other issues and upload a new package to mentors soon. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
> > According to > > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html > > it is not even safe to assume that the API of a new major or minor > > version is backwards compatible. This means that a binNMU triggered > > by a libdb transition may cause the application to FTBS or not to work > > correctly. > > > > Therefore, I am beginning to think that build-depending on libdb-dev > > is not such a good idea. > > > > I am considering to build-depend on libdb4.7-dev to address a number > > of issues: > > - dnshistory can be tested when it is to be rebuilt with a new libdb > > version > > - when the database files need to be upgraded this can be mentioned in > > debian/NEWS > > - this allows to skip a couple of libdb versions potentially saving > > the users unnecessary database upgrades. > > > > Of course, this means there will be a new upload necessary every time > > the libdb version used is supposed to be dropped from the archive. > > > > Are there other reasons why I should not do that? > > I'll let the NMUer and the libdb maintainer answer that (BCCed). Typically the fear which motivates this type of question is unfounded. Looking at the dnshistory source code, it appears that the use of BDB is trivial. Generally when the feature set you require could just as easily have been satisfied by GDBM, there are rarely compatibility worries. dnshistory is using simple B-trees, which haven't changed incompatibly in over 5 years. If, in a future BDB version, the database file created by dnshistory is using too old a format, the attempt to open it would return DB_OLD_VERSION, and you could add code to dnshistory to DB->upgrade() the file, seamlessly resolving the issue. It would be a different story if dnshistory were using transactions or other subsystems. I believe this is a clear case of build-depending on libdb-dev being the proper solution. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
On Thu, Apr 30, 2009 at 9:21 PM, Matthias Julius wrote: > Matthias Julius writes: > >> Paul Wise writes: >> >>> I don't see anything in the maintainer scripts that would migrate the >>> db files. Does dnshistory or libdb handle upgrading the on-disk db >>> format? Or can libdb handle older versions of the on-disk db format? >> >> I was assuming the latter. But, reading >> http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html >> this does not look like a safe assumption. > > According to > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html > it is not even safe to assume that the API of a new major or minor > version is backwards compatible. This means that a binNMU triggered > by a libdb transition may cause the application to FTBS or not to work > correctly. > > Therefore, I am beginning to think that build-depending on libdb-dev > is not such a good idea. > > I am considering to build-depend on libdb4.7-dev to address a number > of issues: > - dnshistory can be tested when it is to be rebuilt with a new libdb > version > - when the database files need to be upgraded this can be mentioned in > debian/NEWS > - this allows to skip a couple of libdb versions potentially saving > the users unnecessary database upgrades. > > Of course, this means there will be a new upload necessary every time > the libdb version used is supposed to be dropped from the archive. > > Are there other reasons why I should not do that? I'll let the NMUer and the libdb maintainer answer that (BCCed). > Is there a convenient way to find all reverse build-depends of a > package? build-rdeps from the devscripts package. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Matthias Julius writes: > Paul Wise writes: > >> I don't see anything in the maintainer scripts that would migrate the >> db files. Does dnshistory or libdb handle upgrading the on-disk db >> format? Or can libdb handle older versions of the on-disk db format? > > I was assuming the latter. But, reading > http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html > this does not look like a safe assumption. According to http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html it is not even safe to assume that the API of a new major or minor version is backwards compatible. This means that a binNMU triggered by a libdb transition may cause the application to FTBS or not to work correctly. Therefore, I am beginning to think that build-depending on libdb-dev is not such a good idea. I am considering to build-depend on libdb4.7-dev to address a number of issues: - dnshistory can be tested when it is to be rebuilt with a new libdb version - when the database files need to be upgraded this can be mentioned in debian/NEWS - this allows to skip a couple of libdb versions potentially saving the users unnecessary database upgrades. Of course, this means there will be a new upload necessary every time the libdb version used is supposed to be dropped from the archive. Are there other reasons why I should not do that? Is there a convenient way to find all reverse build-depends of a package? Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Paul Wise writes: > I don't see anything in the maintainer scripts that would migrate the > db files. Does dnshistory or libdb handle upgrading the on-disk db > format? Or can libdb handle older versions of the on-disk db format? I was assuming the latter. But, reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html this does not look like a safe assumption. Unless the application itself checks the libdb version and upgrades its database files. At least with the transition from 4.6 to 4.7 the database file format did not change. > Bug upstream and run autoconf until the next upstream release. OK. I'll try to do that. > IMO screenshots of console apps can still be useful. Sure, but this is mostly intended to be used as a pre-processor by other applications like awffull or webalizer. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
On Tue, Apr 28, 2009 at 10:25 PM, Matthias Julius wrote: > I am not quite sure how to deal with that one. Since Luk Claes NMUed > the package to change the Build-Depends from libdb4.4-dev to libdb-dev > I don't really have control over which libdb version dnshistory is > built against. If it happens that a new libdb is uploaded before > dnshistory has been built on all archs or if a binNMU is triggered by > a libdb transition debian/NEWS will be outdated. > > I wonder how other packages build-depending on libdb-dev handle this. > > That entry in debian/NEWS is somewhat special in that the dependancy > on libdb had been downgraded from 4.5 to 4.4 in order to allow > dnshistory to migrate into testing (etch at the time) and libdb4.5 was > being kept out. > > On upgrade I would expect db files to be migrated if necessary. I don't see anything in the maintainer scripts that would migrate the db files. Does dnshistory or libdb handle upgrading the on-disk db format? Or can libdb handle older versions of the on-disk db format? >> For some reason the mktime test in ./configure takes ages and a lot of >> CPU in pbuilder and then fails. > > As explained by Sven this is due to an outdated ./configure. What is > the best way to deal with that? Ignore? Run autoconf from > debian/rules? Bug upstream? Bug upstream and run autoconf until the next upstream release. >> I get one dpkg-shlibdeps warning, please ask upstream to remove -lm >> from the link flags: >> >> dependency on libm.so.6 could be avoided if >> "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked >> against it (they use none of its symbols). > > How important is this? I doubt upstream will release a new version > just to fix those minor issues. Fairly minor, just something to fix in the VCS (which seems to be bzr on launchpad). >> You might want to review the debtags and upload a screenshot: > > Since this is a console application and not primarily meant to be run > directly by the user a screenshot is probably not very beneficial. IMO screenshots of console apps can still be useful. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Paul Wise writes: > You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but > the current dnshistory package is built against libdb4.6. Should you > add another debian/NEWS entry about this? I'm not sure what to do in > this situation, could you investigate? I am not quite sure how to deal with that one. Since Luk Claes NMUed the package to change the Build-Depends from libdb4.4-dev to libdb-dev I don't really have control over which libdb version dnshistory is built against. If it happens that a new libdb is uploaded before dnshistory has been built on all archs or if a binNMU is triggered by a libdb transition debian/NEWS will be outdated. I wonder how other packages build-depending on libdb-dev handle this. That entry in debian/NEWS is somewhat special in that the dependancy on libdb had been downgraded from 4.5 to 4.4 in order to allow dnshistory to migrate into testing (etch at the time) and libdb4.5 was being kept out. On upgrade I would expect db files to be migrated if necessary. > > Only the above is a blocker, some other things you may want to look at: > > Please use $(QUILT_STAMPFN) instead of patch in debian/rules. > > Please make build-stamp depend on configure-stamp. > > ./configure gets run twice on my machine in pbuilder due to the above > two issues. I will take care of that. > > For some reason the mktime test in ./configure takes ages and a lot of > CPU in pbuilder and then fails. As explained by Sven this is due to an outdated ./configure. What is the best way to deal with that? Ignore? Run autoconf from debian/rules? Bug upstream? > > I get one dpkg-shlibdeps warning, please ask upstream to remove -lm > from the link flags: > > dependency on libm.so.6 could be avoided if > "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked > against it (they use none of its symbols). How important is this? I doubt upstream will release a new version just to fix those minor issues. > > I get one lintian pedantic complaint: > > P: dnshistory: copyright-refers-to-symlink-license > usr/share/common-licenses/GPL Good catch, I will fix that, too. > > You might want to review the debtags and upload a screenshot: Since this is a console application and not primarily meant to be run directly by the user a screenshot is probably not very beneficial. Thanks for reviewing my package. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
On 2009-04-28 12:45 +0200, Paul Wise wrote: > For some reason the mktime test in ./configure takes ages and a lot of > CPU in pbuilder and then fails. This means that `configure' needs to be regenerated with a newer version of autoconf (2.61-7 or better). See http://lists.debian.org/debian-devel/2008/03/msg00675.html for details. Sven -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
On Tue, Apr 28, 2009 at 1:04 AM, Matthias Julius wrote: > I would really be grateful if someone could take a look at this > package and possibly upload it for me. You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but the current dnshistory package is built against libdb4.6. Should you add another debian/NEWS entry about this? I'm not sure what to do in this situation, could you investigate? Only the above is a blocker, some other things you may want to look at: Please use $(QUILT_STAMPFN) instead of patch in debian/rules. Please make build-stamp depend on configure-stamp. ./configure gets run twice on my machine in pbuilder due to the above two issues. For some reason the mktime test in ./configure takes ages and a lot of CPU in pbuilder and then fails. I get one dpkg-shlibdeps warning, please ask upstream to remove -lm from the link flags: dependency on libm.so.6 could be avoided if "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked against it (they use none of its symbols). I get one lintian pedantic complaint: P: dnshistory: copyright-refers-to-symlink-license usr/share/common-licenses/GPL You might want to review the debtags and upload a screenshot: http://debtags.alioth.debian.org/edit.html?pkg=dnshistory http://screenshots.debian.net/package/dnshistory -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: dnshistory (updated package)
Matthias Julius writes: > I am looking for a sponsor for the new version 1.3-2 > of my package "dnshistory". > > It builds these binary packages: > dnshistory - Translating and storing of IP addresses from log files > > The package appears to be lintian clean. > > The upload would fix these bugs: 434881 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc > > I have contacted my previous sponsor twice in the last couple of > weeks. He did not respond to my emails. > > I would be glad if someone uploaded this package for me. I would really be grateful if someone could take a look at this package and possibly upload it for me. Besides fixing that minor man page bug this is essentially a house-keeping upload. Here is the changelog entry for this upload: , | dnshistory (1.3-2) unstable; urgency=low | | * Acknowledge NMU | * Fix default location of database file in man page (Closes: #434881) | * Update Standards-Version to 3.8.1 | * Don't ship config.guess and config.sub in source package, we take them from | autotools-dev anyway | * Make Homepage its own field in debian/control | * Now using quilt; added debian/README.sources | | -- Matthias Julius Fri, 13 Mar 2009 13:27:43 -0400 ` Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: dnshistory (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3-2 of my package "dnshistory". It builds these binary packages: dnshistory - Translating and storing of IP addresses from log files The package appears to be lintian clean. The upload would fix these bugs: 434881 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dnshistory - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dnshistory/dnshistory_1.3-2.dsc I have contacted my previous sponsor twice in the last couple of weeks. He did not respond to my emails. I would be glad if someone uploaded this package for me. Kind regards Matthias Julius -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
