Re: cannot allocate memory in static TLS block (Was: Bug#953832: drmaa: autopkgtest failure: RuntimeError: Could not find drmaa library)
Hi Andreas, On 14-03-2020 14:30, Andreas Tille wrote: > Hi Paul, [...] > Any help would be welcome I can't help you with this. Paul signature.asc Description: OpenPGP digital signature
Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
Hi, On 06-02-2020 00:07, Adam D. Barratt wrote: > On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote: >> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas >> wrote: >>> Because this changes the versioning scheme from kernel releases >>> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf >>> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I >>> believe. >> >> I had this doubt but 5.4.13-1 is the linux source version, and >> libbpf0 has the version of 0.0.5. And since there is no separate >> source for libbpf so will this not be considered as a new package >> rather than a version change? > > No. There is currently a libbpf0 binary package. After the source > package split, there will still be a libbpf0 binary package. The > version of that binary package cannot go backwards. > > (The source package will indeed be NEW, but that's not the issue under > discussion here.) But, if I am correct, the source could be using a version without epoch and only use the epoch in the binary package (which can be dropped if libbpf0 is ever replaced by libbpf1). Paul
Re: Meaning of "Checking build-dependency (indep) on amd64" excuse
Hi Feri, Please CC me on reply. >> I think I understand the rest, although I don't know whether the >> autopkgtest regression blocks migration indefinitely. That would be >> unfortunate, because unstable pcs needs unstable pacemaker, so they >> deadlock... > > I think you will need to ask the release team to hint them in > together. Yes, they will block unless overridden by the release team, or better, when you change your package relations such that the migration software figures out that they need to be tested together. (The release team and I can do the latter manually, but that is not really sustainable.) With the current code your options are: - *versioned* depends on one of the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable already - *versioned* breaks or conflicts on the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable - *versioned* test dependency in the package that is used for autopkgtest (only helps if the version that is tested is already taken from unstable). The version of the test dependency will NOT be added to the triggers, but if the version of the autopktest is going to be taken from unstable already due to other considerations, with the current settings of ci.d.n and autopkgtest the required version will be installed. Mind you, if the migration software asks for a test with multiple packages from unstable (visible in the triggers string) a PASS will be used for all those packages, so you only need to "fix" this in one package. Paul signature.asc Description: OpenPGP digital signature
Re: r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)
Hi Andreas On 10-05-18 22:08, Andreas Tille wrote: > On Thu, May 10, 2018 at 12:57:54PM -0500, Dirk Eddelbuettel wrote: >> | >> | ftp.debian.org is the right pseudo-package for removal (of the 0.8-1 >> | packages) from unstable. >> >> Ok, thanks, filed as #898354. > > Seems that bug is somehow needed for this specific issue. However, I > think I had other packages moved from Arch=any to Arch=all without any > trouble. So my question is: Did something changed in the software > dealing with those uploads recently or is that package in some other > aspect different which might cause the observed issue? You may be right, or maybe somebody behind the scene took action. I now looked up the cruft report, and r-cran-dbi is mentioned. https://ftp-master.debian.org/cruft-report-daily.txt Paul signature.asc Description: OpenPGP digital signature
Re: r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)
Hi, On 10-05-18 19:57, Dirk Eddelbuettel wrote: > On 10 May 2018 at 19:47, Paul Gevers wrote: > | On 10-05-18 14:04, Dirk Eddelbuettel wrote: > | > Sorry about that. It must have been an old packaging oversight that only > came > | > to light now -- DBI never had a src/ directory and should have been 'all' > all > | > along. > | > > | > Any idea how we can correct that at the repo? Shall we file a bug with > release.d.o? > | > | ftp.debian.org is the right pseudo-package for removal (of the 0.8-1 > | packages) from unstable. > > Ok, thanks, filed as #898354. Thanks. @Andreas/team, once that bug gets fixed, I'll reschedule all the regressing r-* packages. Good catch. Excellent cooperation. Paul signature.asc Description: OpenPGP digital signature
Re: r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)
Hi Dir, On 10-05-18 14:04, Dirk Eddelbuettel wrote: > Sorry about that. It must have been an old packaging oversight that only came > to light now -- DBI never had a src/ directory and should have been 'all' all > along. > > Any idea how we can correct that at the repo? Shall we file a bug with > release.d.o? ftp.debian.org is the right pseudo-package for removal (of the 0.8-1 packages) from unstable. Paul signature.asc Description: OpenPGP digital signature
Re: controlling error handling in sourced shell code
control: tags -1 -help On 20-12-15 15:03, Paul Gevers wrote: > I am looking into fixing bug 807353¹ against my package dbconfig-common. > dbconfig-common is written in shell, such that it can easily be sourced > and used in maintainer scripts. The issue is that when you call a > sourced function in the test part of an if-then-fi statement, the "set > -e" option of the calling script doesn't propagate into the sourced > function. Unfortunately, dbconfig-commons error handling relies on that > behavior. I found a (slightly hacky, but probably adequate) solution for > bash², but that doesn't seem to be generic enough for e.g. dash as it > relies on the errtrace option. Does anybody here have an idea how to > solve this properly? I think I'll just have to add a "|| return $?" in several dozens of locations and hope I don't miss any. Anybody a better idea? And I'll probably contact the packages that call dbconfig-common in such an if statement to reconsider. Paul signature.asc Description: OpenPGP digital signature
controlling error handling in sourced shell code
control: tags -1 help Hi all, I am looking into fixing bug 807353¹ against my package dbconfig-common. dbconfig-common is written in shell, such that it can easily be sourced and used in maintainer scripts. The issue is that when you call a sourced function in the test part of an if-then-fi statement, the "set -e" option of the calling script doesn't propagate into the sourced function. Unfortunately, dbconfig-commons error handling relies on that behavior. I found a (slightly hacky, but probably adequate) solution for bash², but that doesn't seem to be generic enough for e.g. dash as it relies on the errtrace option. Does anybody here have an idea how to solve this properly? Paul ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807353 ² http://fvue.nl/wiki/Bash:_Error_handling#.60Break.27_trap_in_function_in_sourced_script_with_.60errtrace.27 signature.asc Description: OpenPGP digital signature
Bug#805250: RFS: chrony/2.1.1-1
Control: owner -1 ! Hi Vincent On 16-11-15 00:03, Vincent Blut wrote: > Here is the changelog for the version 2.1.1. Looks good. I just ran debmake -k on the copyright file and it found one missing license: GPL-2+ on test/simulation/test.common. I think the tool is right. You didn't push the pristine-tar target. Can you please do so? Paul signature.asc Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
Hi Vincent, On 17-09-15 22:03, Vincent Blut wrote: > Le jeu. 17 sept. 2015 à 19:58, Paul Gevers <elb...@debian.org> a écrit : > I will then revert commit e88f1460f3e. >> As I would call this a regression, I rather have it fixed in our current >> upload. And I think we made a good choice in the past to actually use >> the NEWS file as changelog file. > > I definitely agree with you, Ping Let's not have this hanging around for too long on such a trivial thing. Paul signature.asc Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
Hi Vincent,
On 16-09-15 22:13, Vincent Blut wrote:
> Le mer. 16 sept. 2015 à 19:57, Paul Gevers <elb...@debian.org> a écrit :
>> Commit e88f1460f3e now prevents the upstream NEWS file to be installed
>> as upstream changelog. I rather have that stayed in. You probably should
>> call "dh_installchangelogs NEWS debian/NEWS" or something like that.
>
> Well, not really. In fact, neither upstream nor we install the
> upstream NEWS file by default.
If you would have tried the command from my previous e-mail, you would
have seen that this is not true. In the previous version of the package,
we install upstream NEWS file as /usr/share/doc/chrony/changelog.gz
$ debdiff chrony_1.31.1-1_amd64.changes chrony_1.31.1-2_amd64.changes
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rw-r--r-- root/root /usr/share/doc/chrony/NEWS.Debian.gz
Files in first .changes but not in second
-
-rw-r--r-- root/root /usr/share/doc/chrony/changelog.gz
Control files: lines which differ (wdiff format)
Installed-Size: [-725-] {+719+}
Version: [-1.31.1-1-] {+1.31.1-2+}
> But I agree that it would make sense to have it installed, so I’ll
> add it to debian/docs in a future upload (2.x serie) unless you
> absolutely want it for the release being discussed here.
As I would call this a regression, I rather have it fixed in our current
upload. And I think we made a good choice in the past to actually use
the NEWS file as changelog file.
Paul
signature.asc
Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
Building right now. On 15-09-15 23:08, Joachim Wiedorn wrote: > for clarifying: > > The NEWS.Debian file will be used while updating the package: > If you write a new entry into NEWS.Debian, this new entry will be shown > while running apt-get install. And from man dh_installchangelogs: The NEWS file is always installed with a name of NEWS.Debian. So in the source is is called debian/NEWS, which ends up as NEWS.Debian in the package. That is where the confusion came from. Paul signature.asc Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
Hi Vincent, On 15-09-15 21:56, Vincent Blut wrote: > I also pushed the changes to the git repository. Commit e88f1460f3e now prevents the upstream NEWS file to be installed as upstream changelog. I rather have that stayed in. You probably should call "dh_installchangelogs NEWS debian/NEWS" or something like that. Hint: to be sure I was not missing anything this time I also ran $ debdiff chrony_1.31.1-1_amd64.changes chrony_1.31.1-2_amd64.changes Paul signature.asc Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
Control: owner -1 ! Hi Vincent, On 15-09-15 21:56, Vincent Blut wrote: > Could you please take a look at chrony 1.31.1-2¹? Sure, my dashboard told me that there was a new chrony, so I was expecting this e-mail. Surprisingly it was not to package that. Could you also fix the watch file, as you seem to be not following the 2.x branch? > In 1.31.1-1, the NEWS.Debian file wasn’t copied by dh_installchangelogs > to /usr/share/doc/chrony because it seems that tool can’t cope with that > filename. So I renamed it to NEWS, and also removed an unnecessary call to > dh_installchangelogs in d/rules. Consequently, apt-listchanges is now > able the read that file at install time. Shame on me that I didn't check that it was really installing... Paul signature.asc Description: OpenPGP digital signature
Bug#799093: RFS: chrony/1.31.1-2
On 15-09-15 22:06, Paul Gevers wrote: > On 15-09-15 21:56, Vincent Blut wrote: >> Could you please take a look at chrony 1.31.1-2¹? > > Sure, my dashboard told me that there was a new chrony, so I was > expecting this e-mail. Surprisingly it was not to package that. Could > you also fix the watch file, as you seem to be not following the 2.x branch? And I may have asked before, why aren't you? Looking at the version numbers and their timing, you are just lagging, not really following an other branch are you? What is the plan? So if you want to switch to 2.x, you don't need to update the watch file, and I can upload as is (after checking). Paul signature.asc Description: OpenPGP digital signature
Bug#793876: RFS: chrony/1.31.1-1
Hi Vincent, On 24-08-15 23:52, Vincent Blut wrote: Which file do you have in common with ntp? Please re-read ¹. I guess I’ve been misled by § 7.6.2! The previous section shows the usage of the 'replaces:' field for packages providing *files* already provided by another package. However, the section 7.6.2 seems to be for *packages* that /do conflict/; I interpreted that /do conflict/ by packages providing the same functionality. I even was quite sure my interpretation was correct after seeing the usage example about MTAs. I didn't check if ntp is also doing the conflicts/replaces/provides dance on time-deamon. If so I than you don't need to mention ntp specifically at all¹¹. It does not. There is still an opened bug report² about adding ntp to the time-daemon virtual package, but the discussion has stalled since few years now. Anyway, depending on your answer, I’ll revert this commit. Lets not do that until we agree. :) Ok. Hmm, so I believe Conflicts or maybe even Breaks is indeed enough. Once ntp provides time-daemon, that can be removed as well. Oh, you not understanding me makes sense. It was me who didn't understand what you were doing. I was assuming there now was a new mechanism, but now you explained it is just a better implementation of the same thing. But then again, maybe make that a little clearer in your changelog for others like me? Ok, maybe adding something like: “Basically, this directive makes the detection of the standard (Local or UTC time) set in /etc/adjtime — and used by the hardware clock — clearer compared to the text processing method we used to use in the post install script to complete the same task.” What do you think? Sounds like some good text (but maybe a little long for the changelog. I believe the NEWS file is there for this purpose. Can you please explain me how commit 1ce86d3 works (the Breaks of util-linux). As the hwclockfile directive can only deal with /etc/adjtime, we need to ensure that we migrated from /etc/default/rcS to /etc/adjtime. To be honest, I’m not sure that break is even needed, because this migration happened prior to Wheezy. I haven't looked it up, is util-linux in essential? Otherwise, shouldn't you depend on it with the higher than dependency? Indeed, util-linux is essential hence the fact it is not listed in the 'Depends:' field. Thus I think Depends: util-linux (= 2.20.1-5) is more correct. It is in essential, but you require a version higher than possible (when was 2.20.1-5 introduced?). You confirm my ideas here. But as I mentioned in my other mail (below), I challenge you to come up with a way to run them which is acceptable in Debian's autopkgtest framework. Challenge accepted, but I’ll have to document myself about autopkgtest, especially on the integration of upstream tests. Great. Not needed for this upload per se. So, please fix the dependencies in git (I don't need the dsc, just ping me when your done) and I will build and upload. Paul signature.asc Description: OpenPGP digital signature
Bug#793876: RFS: chrony/1.31.1-1
Hi Vincent, [I am merging the e-mails you send yesterday to make the thread easier again.] On 20-08-15 18:12, Vincent Blut wrote: Le jeu. 20 août 2015 à 12:10, Paul Gevers elb...@debian.org a écrit : On 19-08-15 21:29, Vincent Blut wrote: Please add the CVE numbers that were fixed by upstream to your changelog such that the trackers can find it automatically. TIP: if you would have done that and mention that in your RFS you would have probably found a sponsor earlier. I didn’t include them because those fixes have been backported to chrony 1.30-2 in Debian (thanks Joachim btw) and consequently the CVE numbers have already been mentionned in this release’s changelog. Ack. Your priority switch from extra to optional may require a ping to somebody. I am not sure and I would need to search, so please do that yourself. Yes. I’ll have to send a bug report to the ftp.debian.org pseudo-package asking for the modification of the section/priority in the override-file. Will do later today… or tomorrow. Ack. Which file do you have in common with ntp? Please re-read ¹. I guess I’ve been misled by § 7.6.2! The previous section shows the usage of the 'replaces:' field for packages providing *files* already provided by another package. However, the section 7.6.2 seems to be for *packages* that /do conflict/; I interpreted that /do conflict/ by packages providing the same functionality. I even was quite sure my interpretation was correct after seeing the usage example about MTAs. I didn't check if ntp is also doing the conflicts/replaces/provides dance on time-deamon. If so I than you don't need to mention ntp specifically at all¹¹. Anyway, depending on your answer, I’ll revert this commit. Lets not do that until we agree. :) I assume that the change of maintainership has the consent of Joachim? Yes, we’ve discussed about this privately some times ago. Still ok Joachim? Ack on the other mail of Joachim. Wouldn't the hwclockfile stuff in /etc not warrant an debian/NEWS update? Or at the very least some help in the changelog? I don’t think so. Finally, that change have no impact for the user. Previously we had to check (in the postinst script) if the RTC keeps local time or UTC by parsing /etc/adjtime and/or /etc/default/rcS. Depending on the result, we set (or no) the rtconutc directive in /etc/chrony.conf. But now chrony is grown enough to check that by itself. Each time it is started, it will parse the correspondent value in the /etc/adjtime file. So, as you can see, the whole point of using the hwclockfile directive is to have something cleaner than playing the text processing game for the same result. Doesn't this actually require a migration path? What if the /etc/chrony and /etc/adjtime are NOT answering the same? Well, I’m not sure I’m understanding you here. The chronyd daemon will use what /etc/adjtime returns, thanks to the 'hwclockfile /etc/adjtime' directive. Oh, you not understanding me makes sense. It was me who didn't understand what you were doing. I was assuming there now was a new mechanism, but now you explained it is just a better implementation of the same thing. But then again, maybe make that a little clearer in your changelog for others like me? Can you please explain me how commit 1ce86d3 works (the Breaks of util-linux). As the hwclockfile directive can only deal with /etc/adjtime, we need to ensure that we migrated from /etc/default/rcS to /etc/adjtime. To be honest, I’m not sure that break is even needed, because this migration happened prior to Wheezy. I haven't looked it up, is util-linux in essential? Otherwise, shouldn't you depend on it with the higher than dependency? I assume you tested all migrations for admins that already ran chrony as a different users as described in the README.Debian. Are the manual steps even needed? Shouldn't this go into a NEWS file instead of the README file? I tested a lot of use cases, but Jerome Benoit informed me he had an issue possibly related to this change, but as he uses a custom init script etc., I will have to check his atypical configuration. Ack. Line 36 of the README.Debian file ends weird now, you removed a filename but not the and in front. Indeed, will fix. You mean line 27 right? I am talking about The scripts /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and read key 1 from /etc/chrony/chrony.keys and use it as the password to send chronyc commands. In my version that is on line 36. Nice to have, could you think of some autopkgtest test²? And why are the tests disabled. Unless they fail and can't be fixed, it is really recommended to run them. I’m definitely interested in autopkgtest. However I’ll need some times to dive through its meanders. I don’t known why tests have originally been disabled, but I guess it’s because they depend on the clknetsim tool which is not packaged in Debian. Also, if that tool isn’t installed
Bug#793876: RFS: chrony/1.31.1-1
Hi On 20-08-15 22:33, Joachim Wiedorn wrote: Hello Vincent, Vincent Blut wrote on 2015-08-20 18:36: features. By the way, if I want to close these outdated bug reports, what’s the canonical way to do it? I guess I can’t do that from d/changelog? do it in the changelog: e.g. LP: #1313200 I think Vincent means bugs that are closed in a previous upload. Just send a mail to bug-number-d...@bugs.debian.org¹. Paul ¹ https://www.debian.org/Bugs/Developer#closing signature.asc Description: OpenPGP digital signature
Bug#793876: RFS: chrony/1.31.1-1
Hi Vincent, Live from Debconf15. On 19-08-15 21:29, Vincent Blut wrote: I am looking for a sponsor for my package chrony Please note this is a first manual inspection. Not all items are critical, most are just nitpicks or tips or questions. Please add the CVE numbers that were fixed by upstream to your changelog such that the trackers can find it automatically. TIP: if you would have done that and mention that in your RFS you would have probably found a sponsor earlier. Your priority switch from extra to optional may require a ping to somebody. I am not sure and I would need to search, so please do that yourself. Which file do you have in common with ntp? Please re-read ¹. I assume that the change of maintainership has the consent of Joachim? Wouldn't the hwclockfile stuff in /etc not warrant an debian/NEWS update? Or at the very least some help in the changelog? Doesn't this actually require a migration path? What if the /etc/chrony and /etc/adjtime are NOT answering the same? Can you please explain me how commit 1ce86d3 works (the Breaks of util-linux). I assume you tested all migrations for admins that already ran chrony as a different users as described in the README.Debian. Are the manual steps even needed? Shouldn't this go into a NEWS file instead of the README file? Line 36 of the README.Debian file ends weird now, you removed a filename but not the and in front. Nice to have, could you think of some autopkgtest test²? And why are the tests disabled. Unless they fail and can't be fixed, it is really recommended to run them. I think the comments you added in commit df80cd25 in the copyright file, should the Comment field.³ And tip to prevent the fix in commit 7245a4, use dch to write the timestamps (e.g. dch -rm) You could maybe remind upstream to update their copyright years when they make changes. Paul My TODO in the review Are the man pages regrenerated Are (new) examples installed Are (new) tests run (some seem to require network) check closed bugs ¹ https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces ² http://dep.debian.net/deps/dep8/ ³ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#comment-field signature.asc Description: OpenPGP digital signature
Bug#793876: RFS: chrony/1.31.1-1
Hi On 20-08-15 12:10, Paul Gevers wrote: Are the man pages regrenerated Could you check with upstream that he/she really is generating the man pages by hand in groff format? If not, ask him to include the source. Are (new) examples installed Is there a reason why you don't install the examples? (I could imaging it is because you setup the package in Debian anyways, but please tell). Are (new) tests run (some seem to require network) It would be could if you investigated if you can run the upstream tests. I can come up with multiple ways to do this, I like you to at least give it a thought and maybe propose something (not required for this upload though). check closed bugs Ack... Have you been active in pursuing the other bugs as well? Paul signature.asc Description: OpenPGP digital signature
Bug#793876: RFS: chrony/1.31.1-1
control: owner -1 ! On 19-08-15 21:29, Vincent Blut wrote: So, nobody’s interested to see chrony updated ? ;-) I will look at it soon. Paul signature.asc Description: OpenPGP digital signature
Re: R: Validating user input with debconf
You can also check how I solved this in dbconfig-common in the dbc_get_app_pass function that is called during configure of any package that depends on dbconfig-common: https://sources.debian.net/src/dbconfig-common/1.8.52/dpkg/common/#L853 Although in this case the non-interactive mode is easier because then you don't do the check as the password is empty. But you can see how to check for that here: https://sources.debian.net/src/dbconfig-common/1.8.52/dpkg/common/#L715 Paul On 10-08-15 08:49, Gianfranco Costamagna wrote: Hi, sorry for top posting, I'm on mobile. can you please try to look at virtualbox-ext-pack and see if it fits your needs? It is a package that downloads stuff from the internet after showing you a license and asking to accept it. cheers, G. -- Il lun 10 ago 2015 01:15 CEST, Yurkao ha scritto: Hello mentors I have the following question: I want to validate user input while configuring the package and if user provides incorrect input - reprompt question until valid value is provided. Is it a good practice to do that with debconf? If it is - where should I do this ? In config script? Postinst? The naive asnwer is: prompt user in config script until user provides valid input. This would work fine, but on the other hand the debconf frontend could be non interactive. In this case, if wrong answer was preseeded, looping really doesn't help - because debconf just spinning in the loop without getting any input from user. Any ideas/suggestions for correct solution? Best regards, Yurii Oleynikov -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/83cd318c-1501-4abb-8ae2-67d13b0d0...@gmail.com signature.asc Description: OpenPGP digital signature
Re: response 30 when sending INPUT command to debconf
On 28-04-15 14:26, Christopher Baines wrote: This happens when the package is installed, and I am running dpkg-reconfigure. The manpage seems to suggest that this can happen for three reasons: Debconf decides if the question is actually displayed, based on its priority, and whether the user has seen it before, and which frontend is being used. If the question will not be displayed, debconf replies with code 30. Priority should not matter, since I am using dpkg-reconfigure. I am explicitly setting the seen flag to false, and I am unsure if its an issue with the frontend, as other similar questions work. Does anyone know why this is happening, and is there any way to get more information about what debconf is doing? DEBCONF_DEBUG=developer dpkg-reconfigure your_package_here This will also show WHY you get the 30 response. Paul signature.asc Description: OpenPGP digital signature
Re: [Debian-med-packaging] Bug#775302: [fis-gtm] UTF-8 libgtmutils.so in fis-gtm-6.2-000 is missing routines (fwd)
Hi On 24-04-15 06:02, Amul Shah wrote: While this fix works, it strikes me as not completely correct because 21 # Set up locale support in the pbuilder environment 22 override_dh_auto_build: 23 mkdir -p debian/tmp/locale/ 24 localedef -f UTF-8 -i en_US ./debian/tmp/locale/en_US.UTF-8/ 25 export LOCPATH=$(CURDIR)/debian/tmp/locale/ \ 26 export LC_ALL=en_US.UTF-8 \ 27 dh_auto_build I played around with attempting to use the LOCPATH and LC_ALL settings from override_dh_auto_build in override_dh_auto_install, but $(CURDIR)/debian/tmp/locale does not exist at override_dh_auto_install. I can either repeat the steps from override_dh_auto_build to generate the locale in override_dh_auto_build or I can use my fix as is because all fis-gtm needs is a valid Unicode locale to proceed with compilation. Thoughts? Do I need to go read the manual(s) again? I may be completely wrong, but I think the exports need to happen before any of the targets in the general section of the makefile (debian/rules is a plain makefile). Of course you have to make sure that the localedef command is done in the right target, as it seems to me that that should NOT be in the general section. Paul signature.asc Description: OpenPGP digital signature
Re: dquilt debuild problem
Hi João, I haven't used dquilt in a while (its use has rapidly decrease since source format 3) but have you checked that refreshing with plain quilt (without the d) solves the issue? To understand the issue, you may even compare the patch file before and after quilt refresh to see what has changed. Paul On 22-04-15 03:29, João Vanzuita wrote: Hi guys, I'm trying to package this hello world, it's the 1st revision and I made a patch for it. When I use debuild I get an error message. The steps I did and the error message is bellow, can you help me ? root@home:~/pkgs/hello-0.1# rm debian/patches/ -r root@home:~/pkgs/hello-0.1# dquilt import ../add_copyright_to_upstream Importing patch ../add_copyright_to_upstream (stored as add_copyright_to_upstream)root@home:~/pkgs/hello-0.1# dquilt top No patches applied root@home:~/pkgs/hello-0.1# dquilt push Applying patch add_copyright_to_upstream patching file hello_world.c Now at patch add_copyright_to_upstream root@home:~/pkgs/hello-0.1# dquilt top add_copyright_to_upstream root@home:~/pkgs/hello-0.1# dquilt pop -a Removing patch add_copyright_to_upstream Restoring hello_world.c No patches applied root@home:~/pkgs/hello-0.1# while dquilt push; do dquilt refresh; doneApplying patch add_copyright_to_upstream patching file hello_world.c Now at patch add_copyright_to_upstream Refreshed patch add_copyright_to_upstream File series fully applied, ends at patch add_copyright_to_upstream ###root@home:~/pkgs/hello-0.1# debuild dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-buildpackage: source package hello dpkg-buildpackage: source version 0.1-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Joao Vanzuita joaovanzu...@me.com dpkg-source --before-build hello-0.1 dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean make[1]: Entering directory '/root/pkgs/hello-0.1'rm -f *.o hello_world make[1]: Leaving directory '/root/pkgs/hello-0.1'dh_clean dpkg-source -b hello-0.1 dpkg-source: info: using source format `3.0 (quilt)'dpkg-source: info: building hello using existing ./hello_0.1.orig.tar.gzpatching file hello_world.cHunk #1 FAILED at 1.1 out of 1 hunk FAILEDdpkg-source: info: the patch has fuzz which is not allowed, or is malformeddpkg-source: info: if patch 'add_copyright_to_upstream' is correctly applied by quilt, use 'quilt refresh'to update it dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/add_copyright_to_upstream/ --reject-file=- hello-0.1.orig.VOGEM5/debian/patches/add_copyright_to_upstream gave error exit status 1 dpkg-buildpackage: error: dpkg-source -b hello-0.1 gave error exit status 2 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc failed root@home:~/pkgs/hello-0.1# signature.asc Description: OpenPGP digital signature
Re: Debian git workflow
On 03-04-15 17:55, Felix Natter wrote: does nobody have an opinion on this? In short: Is it better to have _a lot_ of beta gbp import-origs, commits that are reverted/superceded etc. OR develop on a private repository and copy the debian/* changes to alioth on a release? If this means that from one release to the next is only one commit, I personally don't like it. Usually history (with good commit messages) helps a lot with figuring out why what happened and where bugs were introduced. Not only for my own packages, but especially if I look at packages done by others, be it to fix some bug via NMU or because of take over. Basically, if you are only doing one commit, there is hardly any use for the repository, as I could get the same by downloading the packages from snapshot.d.o. Paul signature.asc Description: OpenPGP digital signature
Bug#780935: RFS: bakefile/1.2.5.1-1 [ITP]
On 22-03-15 06:39, Riley Baird wrote: -The upstream tarball contains embedded code copies of the java version of antlr, which violates Debian policy. This depends on the license, but in general this statement is not completely true. You'll need to repack the tarball and add +ds to the version number, add a dependency on libantlr-java and possibly modify the build process to accommodate this change. Indeed, you should not USE the embedded copy if it can be avoided at all (yes, you may have to jump through some hoops). If you are not doing a repack (and certainly if you really can't avoid using the embedded copy), you must notify the security team. However, I would not do a repack only to get rid of the embedded copy. Removing it in the clean target to make sure it doesn't get used is quite acceptable IMHO. Paul signature.asc Description: OpenPGP digital signature
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
Hi Jörg, Ping. Any progress on xmlrpc-c? On 10-01-15 21:35, Paul Gevers wrote: On 10-01-15 20:59, Paul Gevers wrote: I think you don't need to add the version to the dpkg-gensymbols call, and if you do, why strip the Debian part of the version? Doesn't dh_makeshlibs call dpkg-gensymbols itself? So if you try to override anything, shouldn't the dpkg-gensymbols calls be BEFORE the dh_makeshlibs call? This doesn't look right to me. Have you seen https://wiki.debian.org/UsingSymbolsFiles where it describes a way to create a symbols file that contains as much history as possible? I disabled the calls to dpkg-gensymbols in your d/rules file and I manually removed the symbols for 1.39.2 for libxmlrpc-c++8 that you already added and I find that the symbols files are created. Indeed, lintian complains, but that is fixed by generating the symbols files before the build such that you can also build on it later. Yes, you can then strip them with -v (as you have them now in the package). Really, no need for the override of dh_makeshlibs AFAICT. The reason why I wouldn't want to have this in the rules is the risk of being forgetting to update the symbols file the next time it needs to be updated. In the end that would lead to to strict requirements on the version. I saw you made some changes after the last e-mail, but you didn't comment on it or my other e-mail (and I like to see your comments before I decide what to think of the current state). Oh, and by the way, your get-orig-source target is broken. If I run it now, the $DATE string does not match the date in the changelog. Paul signature.asc Description: OpenPGP digital signature
simple shell question
Hi all, I am wondering about the following, what is the practical difference in a shell script between [ $foo ] and [ -n $foo ] or [ ! $foo ] and [ -z $foo ] Looking up their literal meaning shows that they are different of course, but is there also a practical difference? Paul signature.asc Description: OpenPGP digital signature
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
On 10-01-15 20:59, Paul Gevers wrote: I think you don't need to add the version to the dpkg-gensymbols call, and if you do, why strip the Debian part of the version? Doesn't dh_makeshlibs call dpkg-gensymbols itself? So if you try to override anything, shouldn't the dpkg-gensymbols calls be BEFORE the dh_makeshlibs call? This doesn't look right to me. Have you seen https://wiki.debian.org/UsingSymbolsFiles where it describes a way to create a symbols file that contains as much history as possible? If the symbols file contains versions with the Debian revision lintian displays a error[1]. No dpkg-gensymbols must run manually. Without the separate call no symbol files found. With I can found the diffs in the buildlog. And yes dpgk-gensymbols must be running befor dh_makeshlibs. Changed. I will do some testing and come back to this. This is not my experience with libraries and symbols files. I disabled the calls to dpkg-gensymbols in your d/rules file and I manually removed the symbols for 1.39.2 for libxmlrpc-c++8 that you already added and I find that the symbols files are created. Indeed, lintian complains, but that is fixed by generating the symbols files before the build such that you can also build on it later. Yes, you can then strip them with -v (as you have them now in the package). Really, no need for the override of dh_makeshlibs AFAICT. The reason why I wouldn't want to have this in the rules is the risk of being forgetting to update the symbols file the next time it needs to be updated. In the end that would lead to to strict requirements on the version. Oh, and by the way, your get-orig-source target is broken. If I run it now, the $DATE string does not match the date in the changelog. Paul signature.asc Description: OpenPGP digital signature
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
Hello Jörg, On 07-01-15 13:12, Jörg Frings-Fürst wrote: Am Montag, den 05.01.2015, 21:55 +0100 schrieb Paul Gevers: On 30-12-14 21:17, Jörg Frings-Fürst wrote: Am Montag, den 29.12.2014, 11:13 +0100 schrieb Paul Gevers: On 26-12-14 20:48, Jörg Frings-Fürst wrote: Sure, saw that. I guess you want to follow the stable release tree? Yes. And eventually the Advanced release in Experimental. Ack. * New missing debian/xmlrpc-c-config.man and debian/xmlrpc.man. You created these files with help2man. I prefer it when you do this at build time, so that the man page stays up-to-date. I think you can tweak the settings of help2man to not add the date and your name. Yes the manfiles was basically made with help2man, but also massive edited. Therefore I don't build them at build time. Then I really suggest you remove the first line of the man page file. Did you send this manpage upstream then? Ideally you should be able to drop this file again once upstream excepts it. Also I suggest to either drop the statement about may be used by others or improve the wording such that you actually really mention a common license name that applies to your work on this man page. Are this ok? This manual page was written by Jörg Frings-Fürst for the Debian project and is licensed under BSD-3. It is ok for me. Maybe a nicer statement (less ambiguous in the sense that the project has the full license), is licensed under the same license as xmlrpc-c. Just wondering (haven't check yet), but you only add symbols files for amd64 and i386. Is this working correctly with the other archs? Or are they going to be more strict as a result? My error. I have differences between amd64 and i386. So I have renamed the symbols file for libxmlrpc-c++8 to *.amd86 and *.i386. I have renamed libxmlrpc-c++8.symbols.amd64 to libxmlrpc-c++8.symbols. Wouldn't it be possible to merge the symbols files so that the common part can still be used (haven't checked the content of the files myself yet). No, the symbols file are different between i386 and the other archs. Ok. I think you don't need to add the version to the dpkg-gensymbols call, and if you do, why strip the Debian part of the version? Doesn't dh_makeshlibs call dpkg-gensymbols itself? So if you try to override anything, shouldn't the dpkg-gensymbols calls be BEFORE the dh_makeshlibs call? This doesn't look right to me. Have you seen https://wiki.debian.org/UsingSymbolsFiles where it describes a way to create a symbols file that contains as much history as possible? If the symbols file contains versions with the Debian revision lintian displays a error[1]. No dpkg-gensymbols must run manually. Without the separate call no symbol files found. With I can found the diffs in the buildlog. And yes dpgk-gensymbols must be running befor dh_makeshlibs. Changed. I will do some testing and come back to this. This is not my experience with libraries and symbols files. Please separate your commits to git to ease review and understanding. ok Thanks for doing this a bit. However, your commit dbfaa7a7cc is horrible to review though, because you mix upstream changes due to the new release with your changes. I recommend to have the new upstream release in a clean commit and then add your changes nicely documented afterwards. If you want I can make a git reset and push the changes separately. Please don't rewrite history in published git repositories, it is considered (for good reasons) bad practice). I'll figure it out, but just keep it in mind for next times (and other projects ;) ). It looks like you are mixing ideas in your d/rules file. You export DEB_BUILD_MAINT_OPTIONS = hardening=+all, but at the same time you declare all the *FLAGS manually (which you shouldn't). Also you don't use or export the *FLAGS. I think you should check the last section of dpkg-buildflags(1). (I could be wrong here). I think it would make 500-mk_gennnmtab.patch unnecessary. First I think hardening all is requested for xmlrpc-c. Only with export DEB_BUILD_MAINT_OPTIONS = hardening=+all a get a FTBFS: /usr/bin/ld: AbyssServer.osh: relocation R_X86_64_PC32 against symbol `_ZN8xmlrpc_c11AbyssServer10ReqHandler9terminateEv' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status I reproduce this behavior. With [C|CPP|CXX]FLAGS += -fPIC the build runs, but I get by testing with blhc CPPFLAGS missing (-D_FORTIFY_SOURCE=2): [..] Then with [C|CPP|CXX]FLAGS += -fPIC -D_FORTIFY_SOURCE=2 blhc display on errors. But still I don't understand it. Shouldn't the flags be exported to be used, so why does this work. Also I think DEB_flag_MAINT_APPEND is meant for this, so I think it is cleaner. Only lintian says: I: libxmlrpc-c++8: hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/libxmlrpc_packetsocket.so.8.39
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
Hi Jörg, On 30-12-14 21:17, Jörg Frings-Fürst wrote: first sorry for my late answer. I was i little bit ooo and then the 31C3. No problem. Also sorry I didn't replied sooner. Am Montag, den 29.12.2014, 11:13 +0100 schrieb Paul Gevers: On 26-12-14 20:48, Jörg Frings-Fürst wrote: Ironically, upstream just (15 hours ago) seems to have released 1.33.15 as tar ball. I have seen it too. But the download diretory is Xmlrpc-c Super Stable/. I thinks its only a new Super Stable release. Sure, saw that. I guess you want to follow the stable release tree? * New debian/patches/200-test_port.diff: - Change port for testing from 8080 to 7890 (Closes: #722503). I am missing some background, either in the bug or in the patch file. Why do you think hard coding 7890 is any better than 8080? And why do you consider this Forwarded: not-needed? Michael suggested to try multiple ports instead of relying on one port and I think upstream should be interested in such a patch. My first opinion was to change nothing. On debian the builds was running in a clean system without network. So there are no changes required. On a build on a normal system port 8080 often be used by proxies or http servers. So I switched the port for the build tests to 7890. I think that the using of multiple ports in this case the coast are to high. In my opinion is the best way to set the port for testing at build time as configure variables (--testport=7890 or so). But this must be discussed with upstream. So have set Forwarded: not-needed. Well, some of this information was/is very welcome in the patch header. Maybe with a link where to the e-mail thread where you started the discussion about it (so that in the far future we can check what actually became of the request). * New debian/patches/005-xmlrpc_example.diff: - Backport from upstream release 1.34.0 (Closes: #524550). If you still want me to upload your current package, could you add a source URL to the DEP5 header? The bts seems to say it should be here: http://sourceforge.net/p/xmlrpc-c/code/2491 but with that commit I don't see any content there. At least mention the proper revision in the headers. Also, the patch seems to fix more than just the bug in the bts. Please document what it is supposed to fix. I have rewriten the patch, so that only the wrong example is removed. Ack. * New missing debian/xmlrpc-c-config.man and debian/xmlrpc.man. You created these files with help2man. I prefer it when you do this at build time, so that the man page stays up-to-date. I think you can tweak the settings of help2man to not add the date and your name. Yes the manfiles was basically made with help2man, but also massive edited. Therefore I don't build them at build time. Then I really suggest you remove the first line of the man page file. Did you send this manpage upstream then? Ideally you should be able to drop this file again once upstream excepts it. Also I suggest to either drop the statement about may be used by others or improve the wording such that you actually really mention a common license name that applies to your work on this man page. Just wondering (haven't check yet), but you only add symbols files for amd64 and i386. Is this working correctly with the other archs? Or are they going to be more strict as a result? My error. I have differences between amd64 and i386. So I have renamed the symbols file for libxmlrpc-c++8 to *.amd86 and *.i386. I have renamed libxmlrpc-c++8.symbols.amd64 to libxmlrpc-c++8.symbols. Wouldn't it be possible to merge the symbols files so that the common part can still be used (haven't checked the content of the files myself yet). I think you don't need to add the version to the dpkg-gensymbols call, and if you do, why strip the Debian part of the version? Doesn't dh_makeshlibs call dpkg-gensymbols itself? So if you try to override anything, shouldn't the dpkg-gensymbols calls be BEFORE the dh_makeshlibs call? This doesn't look right to me. Have you seen https://wiki.debian.org/UsingSymbolsFiles where it describes a way to create a symbols file that contains as much history as possible? Please separate your commits to git to ease review and understanding. ok Thanks for doing this a bit. However, your commit dbfaa7a7cc is horrible to review though, because you mix upstream changes due to the new release with your changes. I recommend to have the new upstream release in a clean commit and then add your changes nicely documented afterwards. I don't understand why you created a new upstream release. As far as I see it the only change is the version number and the distclean target in the Makefile. No further changes in the files that you decided to keep around. Are the upstream change from 1.33.14 to 1.33.15 not enough? As I said, there weren't ANY. But as you now package a full new version, this point is moot. A new version is uploaded to mentors. Again, I
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
Control: owner -1 ! Hi Jörg, On 26-12-14 20:48, Jörg Frings-Fürst wrote: I am looking for a sponsor for my package xmlrpc-c I am willing to help, review below is incomplete yet though (just scanned the changes once). Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xmlrpc-c/xmlrpc-c_1.33.15+svn20141223~2672-1.dsc I use the git repository. I assume it is the same. Ironically, upstream just (15 hours ago) seems to have released 1.33.15 as tar ball. * New debian/patches/200-test_port.diff: - Change port for testing from 8080 to 7890 (Closes: #722503). I am missing some background, either in the bug or in the patch file. Why do you think hard coding 7890 is any better than 8080? And why do you consider this Forwarded: not-needed? Michael suggested to try multiple ports instead of relying on one port and I think upstream should be interested in such a patch. * New debian/patches/005-xmlrpc_example.diff: - Backport from upstream release 1.34.0 (Closes: #524550). If you still want me to upload your current package, could you add a source URL to the DEP5 header? The bts seems to say it should be here: http://sourceforge.net/p/xmlrpc-c/code/2491 but with that commit I don't see any content there. At least mention the proper revision in the headers. Also, the patch seems to fix more than just the bug in the bts. Please document what it is supposed to fix. * New missing debian/xmlrpc-c-config.man and debian/xmlrpc.man. You created these files with help2man. I prefer it when you do this at build time, so that the man page stays up-to-date. I think you can tweak the settings of help2man to not add the date and your name. Other (random) remarks: Please target experimental during the freeze, unless you are fixing something that needs to go into jessie. Just wondering (haven't check yet), but you only add symbols files for amd64 and i386. Is this working correctly with the other archs? Or are they going to be more strict as a result? Please separate your commits to git to ease review and understanding. I don't understand why you created a new upstream release. As far as I see it the only change is the version number and the distclean target in the Makefile. No further changes in the files that you decided to keep around. Paul signature.asc Description: OpenPGP digital signature
Bug#768916: RFS: systempreferences.app/1.2.0-2 -- GNUstep preferences application [RC]
Control: owner -1 ! Judging the response of Sebastian in bug 768764, he doesn't have time anymore. Building right now, uploading after dinner... Paul signature.asc Description: OpenPGP digital signature
Bug#770146: RFS: gnustep-back/0.24.0-4 -- GNUstep GUI Backend [RC]
Control: owner -1 ! Control: tags -1 pending On 19-11-14 07:57, Yavor Doganov wrote: I'm looking for a sponsor for my package gnustep-back. Building now, etc... Paul signature.asc Description: OpenPGP digital signature
Bug#770224: RFS: gnustep-base/1.22.1-4+deb7u1 -- GNUstep Base library [RC SECURITY] [wheezy]
Control: owner -1 ! Control: tags -1 pending On 19-11-14 22:14, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-base. Building soon, etc... Paul signature.asc Description: OpenPGP digital signature
Bug#769688: RFS: gnustep-sqlclient/1.8.1-1 -- SQL client library for GNUstep
Control: owner -1 ! Control: tags -1 pending On 15-11-14 16:53, Yavor Doganov wrote: I'm looking for a sponsor for my package gnustep-sqlclient. You found one. As always I build from git, I assume that is all right. Paul signature.asc Description: OpenPGP digital signature
Bug#769142: RFS: rsskit/0.3-3 -- GNUstep RSS framework [RC]
Control: owner -1 ! On 11-11-14 19:47, Yavor Doganov wrote: I am looking for a sponsor for my package rsskit. It builds these binary packages: This upload is targeted for t-p-u; the debdiff was pre-approved by the release team (release.d.o #768923). Checking, building etc... Paul signature.asc Description: OpenPGP digital signature
Re: HELP: Bug#766821: relion: FTBFS: B-D on nonexistent openmpi-gcc
On 26-10-14 07:37, Vincent Cheng wrote: Anny suggestion for a solution since I have no idea about those other architectures? Drop the build-dep on openmpi-gcc. You must make sure that the first build dependency in a set of alternative build-deps is always installable, otherwise it's going to FTBFS on the buildds (even if it builds fine for you locally). This isn't an arch-specific problem if that's what you're concerned about; if you had uploaded source+i386 (instead of amd64) packages, the amd64 build would have failed on the buildds instead. Or, if you want openmpi-gcc to be used on the architectures where it is available, use the arch syntax in the BD. e.g. (untested) Build-Depends: openmpi-gcc (amd64), libopenmpi-dev (!amd64) Paul signature.asc Description: OpenPGP digital signature
Bug#764067: lintian: prevent misuse of overrides by allowing maintainer comments
Package: lintian Version: 2.5.28~bpo70+1 Severity: wishlist X-Debbugs-CC: Debian mentors debian-mentors@lists.debian.org Hi Lintian maintainers, The following wish list bug results from a brief discussion (see the final message with more information below) on the d-mentors e-mail-list. It is noted that people use lintian overrides to hide investigated issues that don't have a short term solution. Paul Wise mentioned this is not where overrides are for. So, Paul and I suggest the following: - Add a way to document information about lintian messages, related to the current package, such that it is clear that the message has been investigated but can/will not be solved (in the short term). - Add an argument to lintian to not show messages that have such a comment to allow a maintainer to focus on unresolved/uninvestigated/new messages instead of either abusing overrides or having to remember everything. Thanks for considering and the great tool that lintian is. Paul Original Message Subject: Re: lintian overrides [Was: Bug#763540: Review of psocksxx/0.0.5-1] Date: Sun, 5 Oct 2014 09:12:25 +0800 From: Paul Wise p...@debian.org To: Debian mentors debian-mentors@lists.debian.org On Sat, Oct 4, 2014 at 1:54 PM, Paul Gevers wrote: I have seen this before and I (as a maintainer) don't understand this comment so bold as it is put here. I would say that overrides can help you to see which items you (or your sponsee¹ in case of sponsorship) already investigated. The point of lintian overrides is to hide issues shown by default that are the fault of lintian where lintian cannot be fixed. Anything else is not the way overrides were meant to be used. In the case of pedantic and info, you could even say that an override is allowed when the item might be still valid but for whatever reason is not going to be fixed (soon). Valid suggestions by lintian shouldn't be hidden. pedantic, experimental and info are hidden by default so there is no need to hide them even if they are the fault of lintian and can't be fixed in lintian, much of the time they are valid issues though. lintian on nearly every build I do and it help me to keep track of the issue I think I still need to resolve. As long as each override has an extensive and valid explanation, I don't see anything wrong with that and I prefer it over having to scroll through items that are ignored anyways. That is an interesting use-case but I think just comments in README.source or elsewhere is the way to go rather than overrides. I think it would be interesting to be able to add comments associated with lintian tags but not override them, so it would produce something like the below (with pedantic turned on). That would cover your use-case without misusing overrides. C: No time to write manual pages, help welcome W: codespell: binary-without-manpage usr/bin/codespell C: Need to ask upstream about this P: codespell: no-upstream-changelog Could you file a bug asking for this feature? Perhaps something like this in debian/package.lintian-comments could be the way to go? # No time to write manual pages, help welcome codespell: binary-without-manpage usr/bin/codespell # Need to ask upstream about this codespell: no-upstream-changelog As a sponsor, I always check all the overrides and only accept those I understand. Documenting the reason goes a long way for that (as well as it helps in the future to remember the original reasoning). Documentation is definitely useful, especially during sponsorship, but it doesn't need overrides. signature.asc Description: OpenPGP digital signature
lintian overrides [Was: Bug#763540: Review of psocksxx/0.0.5-1]
On 04-10-14 00:44, Paul Wise wrote: They are also not for experimental, pedantic or info level issues. So all of these issues should either be ignored or fixed but not overridden. I have seen this before and I (as a maintainer) don't understand this comment so bold as it is put here. I would say that overrides can help you to see which items you (or your sponsee¹ in case of sponsorship) already investigated. In the case of pedantic and info, you could even say that an override is allowed when the item might be still valid but for whatever reason is not going to be fixed (soon). I run the full lintian on nearly every build I do and it help me to keep track of the issue I think I still need to resolve. As long as each override has an extensive and valid explanation, I don't see anything wrong with that and I prefer it over having to scroll through items that are ignored anyways. As a sponsor, I always check all the overrides and only accept those I understand. Documenting the reason goes a long way for that (as well as it helps in the future to remember the original reasoning). Paul ¹ Sorry for my English in case this word is wrong, I mean the person that gets sponsored. signature.asc Description: OpenPGP digital signature
Bug#741648: RFS: cbootimage/1.2-2
Hi Marc, On 05-09-14 16:29, Eriberto Mota wrote: Not mandatory or recommended by policy. However, a good practice commonly requested by all sponsors to allow the control of the code by you or any external people. You must implement it. Just to be sure, I read this as You must implement it if you want me [Eriberto Mota] to sponsor this package. Although I agree that it is common practice, I really think the must in general is out of place. You must review each file. Use 'grep -sriA25 copyright *' to help you. Or run licensecheck (check the man page). Paul signature.asc Description: OpenPGP digital signature
emacspeak - piuparts and gnupg
Hi all, I am trying to investigate why emacspeak has a piuparts purge failure [1]. It fails because there are files in /root/.gnupg/. As emacspeak doesn't depend on gnupg and doesn't do anything of itself with gnupg, I don't have a clear picture of where to start. It seems that emacspeak is the only package that has this error, so either other packages are working around it, or it is indeed something peculiar of emacspeak. Does anybody have a hint of where and how to start investigating? I expect this happens during postinst or *rm, so I could add some debugging output to a testing package and check when the files appear, but maybe somebody already knows better, which would save some time. Paul [1] https://piuparts.debian.org/sid/fail/emacspeak_40.0+dfsg-2.log signature.asc Description: OpenPGP digital signature
Bug#755962: RFS: zipper.app/1.5-1 [ITA] -- Archive manager for GNUstep
Control: owner -1 ! Control: tags -1 pending On 24-07-14 23:08, Yavor Doganov wrote: I am looking for a sponsor for my package zipper.app. You found one one. Building right now (for real), but still I have some remarks that I like you to fix next time: * If suggests are not installed, is the description still correct? * Remove empty d/patches/series and d/patches * Lintian warns for a spelling error: overriden overridden Paul signature.asc Description: OpenPGP digital signature
Bug#751698: RFS: talksoup.app/1.0alpha-32-g55b4d4e-2 [ITA]
Hi Yavor, Several new remarks. When they are resolved (by an explanation or a fix) I will build and upload. - library files are not in /usr/lib anymore but in /usr/lib/talksoup.app/ . As far as I can tell this is good, but it is not documented in changelog. - d/copyright: * years of Adrew, start in 2003: Testing/IRCSwarm/IRCSwarmBot.h. Furthermore, I have the impression (e.g. due to the packaging date in Debian in the original d/copyright) that all files start in or before 2003. * Misc/GNUstep.h is missing copyright notice - The desktop icon doesn't show in my start menu (KDE) I am not sure it this is because KDE doesn't support tiff, or that tiff in general is not accepted in desktop files. Anyways, I think the png in the menu file is usable. Paul signature.asc Description: OpenPGP digital signature
Bug#756373: RFS: gnustep-examples/1:1.4.0-1 -- GNUstep example applications
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On 29-07-14 12:39, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-examples. Some remarks, when they are resolved I think I will upload. * copyright file needs updated dates (also in the negative direction) * copyright needs to mention the NeXT license and license holder * Your watch file fails for me (is this a feature of a newer uscan?): paul@wollumbin ~/tmp/sponsorships/gnustep-examples $ uscan --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: opts=pasv,pgpsigurlmangle=s/$/.sig/ ftp://ftp.gnustep.org/pub/gnustep/(core|usr-apps)/gnustep-examples-(.*)\.tar\.gz uscan warning: In watchfile debian/watch, reading webpage ftp://ftp.gnustep.org/pub/gnustep/ failed: 401 Welcome to the GNUstep archive site at ftp.gnustep.org. -- Scan finished Paul BTW: Similar to talksoup.app, you have a tiff icon in desktop files however, this time they work... signature.asc Description: OpenPGP digital signature
Bug#750865: RFS: lynkeos.app/1.2-7
On 07-08-14 10:56, Yavor Doganov wrote: Clean fails for me in my normal environment. Again, I'd kindly ask you for some more information. fakeroot debian/rules clean is supposed to fail if the build-dependencies are not installed as GNUSTEP_MAKEFILES will be undefined in that case. Please see below. It is very similar to the other trace I sent you. I think I finally understand. You recently fixed an issue in gnustep-make which is exactly fixing this issue. As I am on wheezy, the gnustep-make is not up-to-date. I already started on working my way through some of the packages to backport them for local purposes (like this one ;) ) but haven't got around the full set. That actually was the reason why I requested the ~ in the dependencies on gnustep-make. Anyways, I accept this failure, although I don't like it and I think that the clean target should just work. If build dependencies are not present, obviously the package is not build (or I think you can at least assume it) and clean up should have less to do. I have three more items (and then I will upload), but this time I provide patches: - Please install upstream changelog (as also noted by Lintian) - Please fix a spelling error (found by Lintian): Written - Please install the man page into a valid section for Debian. Of course it can be merged into the other manpage patch if you rather want that. Paul paul@wollumbin ~/tmp/sponsorships/lynkeos.app $ TEST=lintian pdebuild dpkg-checkbuilddeps: Unmet build dependencies: gnustep-make (= 2.6.6-2) libavcodec-dev (= 6:10.1) libavformat-dev (= 6:10.1) libswscale-dev (= 6:10.1) libfftw3-dev libtiff-dev libgnustep-gui-dev W: Unmet build-dependency in source dpkg-buildpackage: source package lynkeos.app dpkg-buildpackage: source version 1.2-7 dpkg-buildpackage: source changed by Yavor Doganov ya...@gnu.org dpkg-source --before-build lynkeos.app dpkg-source: info: applying hurd-ftbfs-fix.patch dpkg-source: info: applying compilation-errors.patch dpkg-source: info: applying libav-build-fix.patch dpkg-source: info: applying plist-icon.patch dpkg-source: info: applying manpage-fix.patch dpkg-source: info: applying libav-0.7.patch dpkg-source: info: applying libav-9.patch dpkg-source: info: applying libav-10.patch dpkg-source: info: applying format-security.patch dpkg-source: info: applying gcc-warnings.patch dpkg-source: info: applying fix_manpage_section.patch dpkg-source: info: applying fix_spelling_error.patch dpkg-checkbuilddeps: Unmet build dependencies: gnustep-make (= 2.6.6-2) libavcodec-dev (= 6:10.1) libavformat-dev (= 6:10.1) libswscale-dev (= 6:10.1) libfftw3-dev libtiff-dev libgnustep-gui-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/media/home/paul/tmp/sponsorships/lynkeos.app' /usr/bin/make -C Sources distclean make[2]: Entering directory `/media/home/paul/tmp/sponsorships/lynkeos.app/Sources' GNUmakefile:1: /common.make: No such file or directory GNUmakefile:42: /application.make: No such file or directory make[2]: *** No rule to make target `/application.make'. Stop. make[2]: Leaving directory `/media/home/paul/tmp/sponsorships/lynkeos.app/Sources' make[1]: *** [override_dh_clean] Error 2 make[1]: Leaving directory `/media/home/paul/tmp/sponsorships/lynkeos.app' make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 Description: Debian policy 12.1 says that man pages should be installed in sections 1 to 9. Author: Paul Gevers elb...@debian.org --- a/GNUstep/lynkeos.1 +++ b/GNUstep/lynkeos.1 @@ -1,6 +1,6 @@ .\ -*-Nroff-*- .\ -.TH Lynkeos 1x 2005-04-17 Lynkeos +.TH Lynkeos 1 2005-04-17 Lynkeos .SH NAME Lynkeos \- application dedicated to the processing of astronomical (mainly planetary) images taken with a webcam through a telescope. .SH SYNOPSIS Description: Fix lintian reported spelling error Author: Paul Gevers elb...@debian.org --- a/Sources/ffmpeg_access.c +++ b/Sources/ffmpeg_access.c @@ -358,7 +358,7 @@ TIFFSetField(image, TIFFTAG_RESOLUTIONUNIT, RESUNIT_INCH); // Write the information to the file - printf(Writting file ... %d \n,width*height); + printf(Writing file ... %d \n,width*height); TIFFWriteEncodedStrip(image, 0, buffer, width*height*6); printf(done ...\n); From 56647974dc1ca1a78d7180a66cf357ef59152680 Mon Sep 17 00:00:00 2001 From: Paul Gevers elb...@debian.org Date: Fri, 8 Aug 2014 20:44:59 +0200 Subject: [PATCH] install upstream ChangeLog into the binary package --- debian/rules |3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index 30196d7..179d9b6 100755 --- a/debian/rules +++ b/debian/rules @@ -40,3 +40,6
Bug#751875: RFS: gorm.app/1.2.20-1
Control: tags -1 +pending -moreinfo Hi Yavor, On 06-08-14 13:25, Yavor Doganov wrote: I find the man page rather short, is it reasonable to improve it? I have extended it as much as I could. Looks much better now, thanks. I didn't check yet, but aren't you know installing the d/docs adn d/examples files into all packages? Is that what you want? They're installed only in the gorm.app package which is what I want. Yes, sorry, as I said, I hadn't checked yet. Did you already forwarded your patches? No; link-libs will be rejected (for some reason upstream considers it a feature not to link the dynamically loadable modules), so I have to rework it somehow. Regarding texinfo-fixes, I'd like to fix more (minor) issues before forwarding upstream but have postponed that as there are currently more important problems to deal with. Again, as I have said before, it might be nice to document such things in the header so it is clear for everybody. Could you please post the error message? Please see below: paul@wollumbin ~/tmp/sponsorships/gorm.app $ TEST=lintian pdebuild dpkg-checkbuilddeps: Unmet build dependencies: libgnustep-gui-dev cm-super-minimal W: Unmet build-dependency in source dpkg-buildpackage: source package gorm.app dpkg-buildpackage: source version 1.2.20-1 dpkg-buildpackage: source changed by Yavor Doganov ya...@gnu.org dpkg-source --before-build gorm.app dpkg-checkbuilddeps: Unmet build dependencies: libgnustep-gui-dev cm-super-minimal dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/media/home/paul/tmp/sponsorships/gorm.app' /usr/bin/make -C Documentation distclean make[2]: Entering directory `/media/home/paul/tmp/sponsorships/gorm.app/Documentation' GNUmakefile:2: /common.make: No such file or directory GNUmakefile:30: /documentation.make: No such file or directory make[2]: *** No rule to make target `/documentation.make'. Stop. make[2]: Leaving directory `/media/home/paul/tmp/sponsorships/gorm.app/Documentation' make[1]: *** [override_dh_clean] Error 2 make[1]: Leaving directory `/media/home/paul/tmp/sponsorships/gorm.app' make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 Any errors should be ignored by gnustep-make by default. Might it be that not gnustep-make is used? Adding a hyphen triggers a lintian warning, so I've added a check for the presence of the .info file instead. Sure, I saw the same after I posted. Most importantly, I am not convinced yet, that the debian/copyright file is a proper description of the situation. Some items that I saw and I like clarification for: + in the README: Icons - Mostly by Andrew Lindsay. Gorm application icon by Jesse Ross. Code - GormViewKnobs.m adapted from code by Gerrit van Dyk. I cannot put this in debian/copyright as that file should document copyright, not authorship. Gorm is an official GNU package and copyright is assigned to the FSF. Ack. + GormImageInspector/GormNSSplitViewInspector and many more contain the header All Rights reserved. Please check with upstream. These files are most probably instantiated with Gorm itself which puts this notice. I'll ask upstream to replace it with the actual license notice. All rights reserved has no legal weight anyway. Thanks. + Documentation/COPYING and most GNUmakefiles say GPL-2+ The former is correct. Apparently most makefiles were omitted during the switch to GPL-3+. I'll ask upstream to rectify this. Ack. The d/copyright file mentions Examples/* but that does not exist in the root. So, what do you mean. Thanks, it should have been Documentation/Examples/*. Fixed. Thought so. Thanks. I have already build the binary and I will upload as-is, but lintian also warns me about a spelling error: I: gorm.app: spelling-error-in-binary usr/lib/gorm.app/libGormCore.so.1.2.20 Recieved Received And I saw that several document seem to be double installed, e.g.: ./usr/share/GNUstep/Documentation/README ./usr/share/doc/gorm.app/README and ./usr/share/GNUstep/Documentation/NEWS ./usr/share/doc/gorm.app/NEWS.gz Maybe it makes sense to install everything under /usr/share/GNUstep/Documentation/ into /usr/share/doc/gorm.app and creating a softlink from one to the other, as Debian users expect to find the documentation in the /usr/share/doc location while GNUstep users might look in the other location. Paul signature.asc Description: OpenPGP digital signature
Bug#750800: RFS: gtamsanalyzer.app/0.42-7
Hi Yavor, This bug was already closed, but I already had a look... On Sat, 07 Jun 2014 04:57:13 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package gtamsanalyzer.app. gtamsanalyzer.app - Qualitative Research Software for GNUstep First remark, I don't really like the short description. It doesn't tell me what this piece of software does, when would I be interested to install it? Some remarks I have nevertheless: Icon in desktop file in /usr/lib Description could do with an update: if the file format is not the same after 10 years, it clearly doesn't belong in the description. Also, I don't think MAC OS is relevant in Debian. Copy of Apples license seems to have been made with the wrong encoding: AppleÕs To prevent accidental use of embedded code copies, I would remove them in the clean target Patches upstream? Build tif files from source: .xcf Thinks I saw in the upstream tar ball and didn't really like: Source/.thumbnails, .bk files, NoXML.tar.gz. Paul signature.asc Description: OpenPGP digital signature
Bug#751550: RFS: aclock.app/0.4.0-1 [ITA]
Hi Yavor, On 04-08-14 22:12, Yavor Doganov wrote: Paul Gevers wrote: Are there any sources for the png/wav in Resources ? There's a Blender file (cuckoo.blend) in the top directory. Then I really suggest to create the images (and the wav?) from that file during building. I share the opinion of many (most?) DD's that the only way to make sure that we can build from sources with tools available in Debian is to actually do that. I don't know blender though, so I can imagine that it is not trivial to automate this. In that case, please verify that the blender file is really the source of the images and document that fact in either d/copyright or in a comment in d/rules I tried (fix pushed in Git). I still have to pull, but thanks already. I found one more thinks to remark: The location of icon in the desktop file point to /usr/lib/ Paul signature.asc Description: OpenPGP digital signature
Bug#751698: RFS: talksoup.app/1.0alpha-32-g55b4d4e-2 [ITA]
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On Sun, 15 Jun 2014 20:15:41 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package talksoup.app. Some remarks: Icon in desktop file in /usr/lib/ Text about license file on Debian systems does not mention the version It would be nice if the patch header for origin of the patch contains URL instead of just upstream Patches need sending upstream? Paul signature.asc Description: OpenPGP digital signature
Bug#750865: RFS: lynkeos.app/1.2-7
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On Sat, 07 Jun 2014 21:20:42 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package lynkeos.app. Some remarks in random order: The location of icon in the desktop file point to /usr/lib/ Could you add tilde to the dependency on gnustep-make (for backports) Short description, the for GNUstep seems misplaced. I suggest to either insert an extra comma, or move the for GNUstep after Tool. Description: Mac OS X is irrelevant I would simplify the patching of the png. Just include the binary file in the debian tree and copy/clean it during building. (Adding a binary file in the debian tree requires a flag to be set somewhere..) Update years in copyright: first file is from 1998 Are the patches sent upstream? Clean fails for me in my normal environment. Paul signature.asc Description: OpenPGP digital signature
Bug#751550: RFS: aclock.app/0.4.0-1 [ITA]
Control: tags -1 pending On 06-08-14 13:57, Yavor Doganov wrote: Then I really suggest to create the images (and the wav?) from that file during building. I share the opinion of many (most?) DD's that the only way to make sure that we can build from sources with tools available in Debian is to actually do that. That's news to me. Is it? I thought I saw you doing the same thing with the some xpm files in multiple GNUstep packages. Only one package in the archive build-depends on blender (gfpoken) and that is because the upstream build system invokes blender. Only three packages build-depend on gimp (gfpoken, openntd-opengfx, xbmc) -- for the first two gimp is invoked by the upstream build system, and xbmc uses it to regenerate a logo with Debian modifications (which looks reasonable). Well, I do it in multiple of my packages, e.g. in Winff to create the pdfs from Libre Office files. Using blender to regenerate the png files has no practical benefit, it will only make the package not buildable on architectures where blender is not installable or not yet built. True. An alternative would be to create a target in the rules file that can be used once in a while to check it is possible. Anyways, this is not a hard requirement by me (it might be for others). If there is a consensus among DDs that all arch-indep files should be regenerated during build I suggest to make it legitimate by documenting it in the Debian Policy. That is a good idea. When I have better internet access, I will check for past discussion and hopefully follow-up on it. A far more serious concern is whether the .gorm files will be loadable with future gnustep-gui releases or editable with future gorm.app versions. Can you help me a bit, how does this work? Are the .gorm files in the packages created by the maintainer? Are they the source files, or created during building? (I must admit I don't have a clue how this all works.) In that case, please verify that the blender file is really the source of the images and document that fact in either d/copyright or in a comment in d/rules Why should I document this? I really don't understand this requirement and where it comes from. Well, it comes from me as I had to ask you during the reviewing how this all works. If it is documented, you don't need to do the same next time (with a next sponsor or otherwise interested person). The location of icon in the desktop file point to /usr/lib/ AFAICT this is not a bug. Sure not. But I think it makes sense to use the canonical location. On the other hand, you also gave an argument of using the /usr/lib location. Building now, uploading soon. Paul signature.asc Description: OpenPGP digital signature
Bug#751550: RFS: aclock.app/0.4.0-1 [ITA]
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On Sat, 14 Jun 2014 09:19:24 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package aclock.app. I have several (in random order) remarks: Are there any sources for the png/wav in Resources ? The man page is rather brief. Could you reasonably extend it? The text in d/copyright about the Debian license file doesn't mention its version. Paul signature.asc Description: OpenPGP digital signature
Bug#751659: RFS: gridlock.app/1.10-4 [ITA]
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On Sun, 15 Jun 2014 10:45:38 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package gridlock.app. I have several (in random order) remarks: Please acknowledge nmus (even if the content is nearly all yours) Are the d/dirs really needed? What for? Did you forward the patches? If not why not (I think I know). Paul signature.asc Description: OpenPGP digital signature
Bug#751875: RFS: gorm.app/1.2.20-1
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, On Tue, 17 Jun 2014 14:50:16 +0300 Yavor Doganov ya...@gnu.org wrote: I am looking for a sponsor for my package gorm.app. I have several (in random order) remarks: I find the man page rather short, is it reasonable to improve it? I didn't check yet, but aren't you know installing the d/docs adn d/examples files into all packages? Is that what you want? Did you already forwarded your patches? The clean target doesn't work in my normal workspace, maybe add a hyphen in front of the $(MAKE) -C Documentation distclean command or is there something else missing? Most importantly, I am not convinced yet, that the debian/copyright file is a proper description of the situation. Some items that I saw and I like clarification for: + in the README: Icons - Mostly by Andrew Lindsay. Gorm application icon by Jesse Ross. Code - GormViewKnobs.m adapted from code by Gerrit van Dyk. + GormImageInspector/GormNSSplitViewInspector and many more contain the header All Rights reserved. Please check with upstream. + Documentation/COPYING and most GNUmakefiles say GPL-2+ The d/copyright file mentions Examples/* but that does not exist in the root. So, what do you mean. Paul signature.asc Description: OpenPGP digital signature
Bug#755210: RFS: gnustep-sqlclient/1.7.3-2 -- SQL client library for GNUstep
Control: owner -1 ! Control: tags -1 pending On 18-07-14 21:56, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-sqlclient. As I sponsored the initial upload, I will take this one as well. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
On 15-07-14 18:52, Yavor Doganov wrote: Paul Gevers wrote: Whatever you do, to prevent accidental usage of a pre-build object file it is very common to at least clean them. It is done by `make distclean'. I hate to disagree, but for me it doesn't. After `make distclean` the files are still there. And you still should fix it some way in the Debian package during the building. E.g. it seems that you removed libtool for a reason, but once you are building, it is back as the source is unpacked and you don't remove it in a clean action. By the way, that file is restored by the `make distclean` command. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Control: owner -1 ! Control: tags -1 moreinfo Hi Yavor, Before I upload this package to the new queue, could you please comment on the lintian errors about missing source? I am looking for a statement like: I added lintian overrides for these files as the source is available several directories higher. What is more, I made sure that these files are actually build during the package building to prove they are DFSG-free by doing and I added them to the clean target by adding a debian/clean file with the appropriate content. I provided a patch to upstream to make sure these files are removed on clean by the regular build system. I also made sure that these files were used in the appropriate way during build. (I haven't checked the content, but these files should be used to test the build, no?) Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
Hi Yavor, And an additional remark: the COPYING file and the headers in several (all?) source files don't match. The COPYING file says LGPL-2.1+ while the headers say LGPL-2+. Please update your d/copyright file to match the situation. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
On 15-07-14 14:54, Yavor Doganov wrote: Paul Gevers wrote: Before I upload this package to the new queue, could you please comment on the lintian errors about missing source? The reason for these is gnustep-make's incapable dist rule, combined with not so careful upstream. I am looking for a statement like: I added lintian overrides... Hmm, but I have not overridden them, I don't feel I should. I have informed upstream and I hope it won't happen in subsequent releases. Well, to document this fact is exactly why an override would be nice. But I understand you position, I guess you just want to prevent it happens again next time, right? But think of people other than you working on the package (e.g. me or anybody in the future that needs to NMU the package). I haven't checked, but ftp-masters use also several lintian checks as auto-reject. So maybe this is even needed to pass the NEW queue. I'm not cleaning them explicitly either as gnustep-make's distclean rule does that. There's little I can do given that the object files are in the .orig tarball; adding a lintian override won't change that. Well, the source has to be DFSG-free. How we guarantee that usually is by building everything from source during the build. If you don't want to build it, you have to remove them from source and repack (I had to do that for some releases of one of my upstreams as well). It is an annoyance, sure, but necessary if we uphold the social contract. So, either remove the files from the source, or build during build. Yes and no. They depend on a test framework that is not packaged for Debian, so they're unused for the debian package build. Ack. As for the license, debian/copyright is correct. It is true there are discrepancies, I'll ask upstream to rectify this. Please add a comment field to the copyright file. Otherwise the ftp-master is going to ask the same questions again (or going to reject the package). Also noting somewhere that this package is a requisite for agenda.app is good, e.g. in the ITP. Paul signature.asc Description: OpenPGP digital signature
Bug#754870: RFS: systempreferences.app/1.2.0-1 -- GNUstep preferences application
Control: owner -1 ! Control: tags -1 pending I like the Description of the packages to be consistent. Either System Preferences *is* or System Preferences *are*. I think the second option is the logic one considering the name, but otherwise you need something like The System Preferences application When in doubt about such descriptions, I recommend e-mailing debian-l10n-english@l.d.o for advice. Paul signature.asc Description: OpenPGP digital signature
Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
On 15-07-14 16:05, Yavor Doganov wrote: Well, the source has to be DFSG-free. How we guarantee that usually is by building everything from source during the build. If you don't want to build it, you have to remove them from source and repack I don't understand. It is quite common for a package not to build some part of the source; this is not a problem at all as long as everything is DFSG-compliant. Which is the case here. This is true if you mean that not all source is used during a build. However, a lot of the Debian developers (yes, there is debate on this how far you should stretch this argument) consider a tar-ball to meet the DFSG if the files are either the preferred form for modification OR build-able from such a form with tools available in Debian (e.g. MS Windows executables in the source are frowned upon by most). In order to guarantee that they are indeed buildable, a lot of DD's will just say, let's build them than. Whatever you do, to prevent accidental usage of a pre-build object file it is very common to at least clean them. Paul signature.asc Description: OpenPGP digital signature
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
Control: owner -1 ! Control: tags -1 pending I uploaded the package, but may I request that next time you add a symbols file so that depending packages get a properly versioned dependency? See lintian info tag: I: libperformance0.5: no-symbols-control-file usr/lib/libPerformance.so.0.5.0 N: N:Although the package includes a shared library, the package does not N:have a symbols control file. N: N:dpkg can use symbols files in order to generate more accurate library N:dependencies for applications, based on the symbols from the library N:that are actually used by the application. N: N:Refer to the dpkg-gensymbols(1) manual page and N:https://wiki.debian.org/UsingSymbolsFiles for details. N: N:Severity: wishlist, Certainty: certain N: N:Check: shared-libs, Type: binary, udeb Paul signature.asc Description: OpenPGP digital signature
Bug#753348: RFS: gnustep-performance/0.5.0-1 [ITP] -- GNUstep performance library
On 15-07-14 18:46, Yavor Doganov wrote: Paul Gevers wrote: I uploaded the package, but may I request that next time you add a symbols file so that depending packages get a properly versioned dependency? Symbols files are ultimately unapplicable for Objective-C libraries (see #749202). Using them can be very harmful -- lax dependencies or spurious build failures when a private class or category is removed. I don't override these as they're informational tags and it's a lintian bug that should be addressed. Thanks for clarifying. As lintian bugs often don't get resolved quickly (I don't blame anybody here), I still recommend adding the lintian override with the comment you wrote above. Once the bug is fixed, lintian will warn you that there are unused lintian overrides. As long as you rely on sponsors for you uploads, it helps documenting these things right in the location where people expect to find the information and it saves you a round trip of e-mail next time (even in case I do the sponsoring, I might just have forgotten what you told me above). Just for your info, I run lintian on nearly every build that I do, and just keeping track of the errors/warnings/info tags that I already have judged is annoying. Therefor I override them if I am sure enough that they are wrong. The ones I don't override are the ones that I still have to come to a final conclusion. But of course, it is your package. Let's just agree that it helps me in helping you getting your packages updated in Debian if you document that you thought about the lintian warnings (by overriding them with a good comment attached). Paul signature.asc Description: OpenPGP digital signature
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
Hi Yavor, On 01-07-14 17:13, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-sqlclient. libsqlclient1.7 - SQL client library for GNUstep (runtime library) This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 [1]: If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Paul [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-support-files signature.asc Description: OpenPGP digital signature
Bug#753406: RFS: gnustep-sqlclient/1.7.3-1 [ITP] -- SQL client library for GNUstep
On 15-07-14 21:16, Yavor Doganov wrote: Paul Gevers wrote: libsqlclient1.7 - SQL client library for GNUstep (runtime library) This package contains files in an unversioned sub-directory of /usr/lib/ This is a violation of Debian policy §8.2 Right, I totally missed that... I'm not sure how to fix this. The bundles are dynamically opened by the library, it is useless without them. Putting them in a separate unversioned package won't work as it is because it would still make two versions of the library impossible to coexist. Unless they don't link with the library, in which case there's still the valid scenario when the API changes and the old library is unable to load or work with the new bundles. I'd appreciate any suggestions. I assume you read the sentences in the policy after my quote. Why wouldn't that work for this package, i.e. put the files in a sub-directory of /usr/lib/libsqlclient1.7/? Is the location of these Bundles so hard-coded that they can't be relocated? Paul signature.asc Description: OpenPGP digital signature
Bug#751208: RFS: lusernet.app/0.4.2-7
Control: owner -1 Control: pending -1 On 11-06-14 06:12, Yavor Doganov wrote: I am looking for a sponsor for my package lusernet.app. I am building and uploading shortly, however, please add the following to your git tree in debian/copyright (preferably you figure out the dates of the contribution as well. Files: News.app.tiff Copyright: Andrew Lindesay License: GPL-2+ Paul signature.asc Description: OpenPGP digital signature
Re: Raleway and Open Sans fonts in Debian
On 04-07-14 22:03, Sergey Shnatsel Davidoff wrote: Should I request splitting these fonts into individual packages? If yes, how do I do that? You can request a split. File it as a wishlist bug against the providing package (as you would with any bug). Also prepare yourself to get wontfix as a response. Paul signature.asc Description: OpenPGP digital signature
Bug#749452: RFS: gnustep-gui/0.24.0-1
Hi Yavor, On 27-05-14 02:57, Yavor Doganov wrote: I am looking for a sponsor for my package gnustep-gui. I can't promise that I will upload the package, but if you can push your changes to the packaging git I promise that I will have a look. (I prefer the git over just the package as it makes it cleaner visible what your changes are and if you properly separate your commits and write proper log messages, also the logic is better preserved.) Paul signature.asc Description: OpenPGP digital signature
Bug#749452: RFS: gnustep-gui/0.24.0-1
On 04-07-14 22:01, Paul Gevers wrote: I can't promise that I will upload the package, but if you can push your changes to the packaging git I promise that I will have a look. Never mind, I was fooled by the web interface of gitweb [1], which didn't show the changes of the experimental branch. Going to look into it this weekend. Paul [1] http://anonscm.debian.org/gitweb/?p=pkg-gnustep/gnustep-gui.git signature.asc Description: OpenPGP digital signature
Re: how to properly remove an empty config directory
On 20-06-14 07:55, Guido van Steen wrote: 3. remove the empty directory /etc/apt.conf.d that shouldn't exits. More precise: 3. remove the empty directory /etc/apt.conf.d if it is empty. well, the command rmdir only removes a dir when it is empty. I think you already got the answer to do it in postinst. What part of the answer is not answering your question? Paul signature.asc Description: OpenPGP digital signature
Re: how to convert a .doc file in the context of a package build?
On 14-05-14 05:39, Paul Wise wrote: (but not in a package build context). libreoffice --headless --convert-to pdf --outdir . input.ods I do use it during packaging. Well, soffice as command, but I assume that is a synonym. (Package: winff) Paul signature.asc Description: OpenPGP digital signature
Re: argument against splitting packages
On 24-04-14 20:41, Don Armstrong wrote: The cases where you should split are generally really obvious; if it's not clear, ask here or in #debian-mentors, and you'll get some reasonable advice. Ok, so let me show one of the two issues I have at hand (the other is currently being discussed on pkg-pascal-de...@lists.alioth.debian.org). The doublecmd-help package [1] of Graham Inggs (who I sponsor a lot), is currently building three packages. One package per language that is provided by upstream. These packages together add up to 12MB, about 4MB per package. Now, if I were a user of one of these packages I would appreciate the languages being separated (which means less HD space), but as a non-user of the package, it just adds two additional packages. So where would a reasonable size limit be? The other discussion is indeed about packages that are usually found together, but also the installed size is ~200MB, so splitting up for people that don't need all components could save significant space. Paul [1] http://packages.qa.debian.org/d/doublecmd-help.html PS: I assume Graham is still on this list. I am not trying to hide this from him. signature.asc Description: OpenPGP digital signature
argument against splitting packages
Hi all, In the last couple of days, the following came up multiple times. Splitting binary packages adds to the total amount of packages in Debian. I have heard that (some) people are very careful before they decide to do that. What is the argument? I can come up with one, but I wonder if there is more to it. The one argument that I can come up with is that adding a package also adds about 1kB to the data that everybody in Debian has to download (on every update), also the people that are not interested in the package (which may be many). Paul signature.asc Description: OpenPGP digital signature
Re: header-only dependence
On 22-03-14 13:33, Nico Schlömer wrote: Hi all, I'm packaging a library libA which depends on a header-only library libB. Obviously I need libB to be present whenever I build an executable against libA. Where in debian/control will I have to fill in libB? If I am correct, you should have libA-dev depend on libB-dev (or libB if I understand you correctly). Thus, if you are building against libA, you also have the headers of libB available, but users of libA (or there reverse dependencies) don't. Paul signature.asc Description: OpenPGP digital signature
Bug#739029: RFS: qgis/2.0.1-2
Hi Bas, [ Sorry, no intent to sponsor this right now, but ... ] On 15-02-14 03:12, Bas Couwenberg wrote: I am looking for a sponsor for my package qgis This package is part of a proposed transition (by you). You would do well to at least mention this fact in your RFS. Paul signature.asc Description: OpenPGP digital signature
Bug#737907: RFS: chrony/1.29.1-1 -- Set the computer clock from time servers
On 06-02-14 22:04, Joachim Wiedorn wrote: I am looking for a sponsor for my package chrony If nobody beats me to it, I will have a look. Feel free to bug me if I haven't responded within a week. Paul signature.asc Description: OpenPGP digital signature
Bug#737907: RFS: chrony/1.29.1-1 -- Set the computer clock from time servers
On 06-02-14 22:04, Joachim Wiedorn wrote: I am looking for a sponsor for my package chrony From the Debian side this looks trivial and I think I will upload as is, but some remarks still. - Upstream FAQ removed two questions and part of the answer to one question is now part of the answer to another question. I am unsure if this is intended. - Your watch file doesn't work, please find attached a version that works and at the same time takes advantage of the fact that upstream signs its releases. You need the also attached keyring for that but feel free to generate that yourself as well. - Your git repository would do well with a pristine-tar target, so I don't need to download the upstream tar ball. - The patches are documented as not forwarded to upstream, why not (three out of four)? Paul # watch control file for uscan version=3 opts=\ pgpsigurlmangle=s/\.tar\.gz$/-tar-gz-asc.txt/ \ http://download.tuxfamily.org/chrony/chrony-([\d\.]*)\.tar\.gz upstream-signing-key.pgp Description: application/pgp-encrypted signature.asc Description: OpenPGP digital signature
Bug#737907: RFS: chrony/1.29.1-1 -- Set the computer clock from time servers
Hi Joachim, On 08-02-14 18:51, Joachim Wiedorn wrote: - Your watch file doesn't work, please find attached a version that works and at the same time takes advantage of the fact that upstream signs its releases. You need the also attached keyring for that but feel free to generate that yourself as well. Thanks for this hint. It comes from the seldom version number. I have installed the pgp key and tested your watch file locally. usan give me a warning, that the pgpsigurlmangle option is unknown. I will look futher for a solution. Which version of Debian are you running? It might be that the mangle that I provided works for Wheezy. If I am correct, recently changes were made to uscan in this field. - Your git repository would do well with a pristine-tar target, so I don't need to download the upstream tar ball. That's right, but I never change something at the sources, so why should I add the sources, which do not exist as original archive in git repo? I don't understand what you mean. pristine-tar makes sure you can restore the original tar (with equal checksum) without additional needs. You already have an upstream branch in your git repo, adding the pristine-tar is than hardly any effort, with gain for your sponsors or possible coworkers, that don't need to download the original tar. Paul signature.asc Description: OpenPGP digital signature
Bug#736085: RFS: doublecmd/0.5.8-1 -- twin-panel (commander-style) file manager
Control: owner 736085 ! On 19-01-14 16:41, Graham Inggs wrote: I am looking for a sponsor for my update to package doublecmd: Interesting that I have missed this the first time that you did this work. Funny thing is that we are trying to get things related to FreePascal into one team, so I invite you to have a look at pkg-pascal on Alioth [1]. Furthermore, there is a package called tuxcmd, which is also a twin-panel file manager and also written in FreePascal. doublecmd wouldn't be a fork of that project (which has stalled upstream)? If upstream of doublecmd is really active, maybe we should drop tuxcmd altogether (it is orphaned). If we do, maybe we could help people migrate in the next release by handling this properly. Could you investigate (if you have the time of course) if tuxcmd has features that are still lacking in doublecmd? Paul [1] http://alioth.debian.org/projects/pkg-pascal signature.asc Description: OpenPGP digital signature
Bug#736085: RFS: doublecmd/0.5.8-1 -- twin-panel (commander-style) file manager
Hi Graham, On 19-01-14 16:41, Graham Inggs wrote: I am looking for a sponsor for my update to package doublecmd: By source and binary inspection: - Some (if not all, I am unsure) of your Conflicts are unneeded, Breaks is good enough. Please read [1] and following paragraphs carefully again. - In line with the previous comment, your debugging packages might be missing Breaks/Replaces on each other, they can't be both installed at the same time. But it is possible that that is handled properly via their Provides. Did you actually test this? - Why are there still plugins in the doublecmd-(gtk|qt) packages? - Did you deliberately put some documentation in /usr/share/doublecmd/doc? I think it is more appropriate in /usr/share/doc/ - Am I mistaken, or are the debian/*.dir files not doing anything useful? Paul [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks signature.asc Description: OpenPGP digital signature
Re: Wish to package astronomy software
[Are you subscribed to debian-mentors? CC'ing you just in case you're not]. On 05-01-14 12:42, Bamm wrote: I'm Bamm from the Philippines. I'm new to this list Welcome. and I hope to gain advice how to package for Debian. Have you read the front page of https://mentors.debian.net/ If it is not clear after reading that, you are welcome to ask specific questions here. I received advice to start with simple packages, and I chose xvarstar to start with. Please file an ITP (Intend to package) bug against the WNPP (pseudo) package. You should use the reportbug command for that, as it gives you the proper template to file out. I am reading the Debian New Maintainers' Guide and have been able to do the packaging privately. Good, next thing is to provide us with the source. Can I get advice how I can apply to be a packager for this package? I would also like some feedback on the source package I made. It should all be written on mentors.d.n. Paul signature.asc Description: OpenPGP digital signature
Re: Wish to package astronomy software
On 05-01-14 14:23, Bamm wrote: Please file an ITP (Intend to package) bug against the WNPP (pseudo) package. You should use the reportbug command for that, as it gives you the proper template to file out. Thanks! Where do I report the ITP bug? Is there an online form, e.g., bugzilla? $ reportbug wnpp Please read: http://www.debian.org/Bugs/Reporting Good, next thing is to provide us with the source. I have created my source package. How do I provide it to you? Is it allowed to attach it into this message? Please read https://mentors.debian.net/ and use it as your upload facility. Paul signature.asc Description: OpenPGP digital signature
Re: empty-binary-package
On 02-01-14 20:44, Russ Allbery wrote: Be aware of one gotcha: the destination column in *.install files specifies the destination *directory*, not file name. You cannot use dh_install to rename files; Except if you build depend on dh-exec and use it (The man page is good, so I am not going to explain that here). Paul signature.asc Description: OpenPGP digital signature
Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers
Control: -1 pending On 30-11-13 11:05, Graham Inggs wrote: I've pushed some commits to the git on collab-maint. I added a comment about the overridden Lintian spelling error warnings, rewrote the package descriptions, merged the changes I had made in d/control into d/control.in and regenerated d/control, and updated d/watch. Looks good now, except that I get: P: mtink source: duplicate-in-relation-field in source build-depends: debhelper, debhelper (= 8) I removed the non-versioned one from the control file, but please check how to make the generation of the control file do the right thing. I did find Ubuntu bug LP: #810871 was the same as Debian bug #716543 and marked it accordingly. Nice. Building and uploading. I push my changes to git and tag it. Paul signature.asc Description: OpenPGP digital signature
Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers
On 21-11-13 16:28, Graham Inggs wrote: I have looked, but don't think there is anything I can fix there. Hmm, than I will leave some comments here and there. And, as you have been working on silencing lintian, why have you not tried to fix the extended-description-is-probably-too-short info warning? Override? :) Well, , the idea would be to give a better description of course. But maybe there is not a hell of a lot to tell more. While importing the previous versions, I noticed there was a debian/control.in file which I had overlooked previously. It seems that debian/control needs to be generated manually from this file. Yes, people have applied such creation during building, but policy doesn't allow that (for debian/control). I haven't encountered this arrangement before and to me it seems like maintaining this file is more of a hassle than it is worth. Do I have to maintain it, or can I remove it? If you think it doesn't help, yes, you can remove it. Usually if this is done, it is because this way you can automate replacing variables in the file. E.g. fpc and lazarus (which I co-maintain) use that procedure for versioned packages. Paul signature.asc Description: OpenPGP digital signature
Re: Upstream tarballs with varying line endings
On 21-11-13 19:17, Felix Natter wrote: 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream (generate tarball, extract, fix line endings, generate tarball) Sound like a good solution. 2. write a get-orig-source target that does the same? If yes, shall I append +dfsg1 to the version number? = I guess both are possible are OK for Debian? The second option is usually frowned upon. Line-endings does not sound like a good reason to deviate from the upstream tar-ball. Acceptable reasons are thinks like non-dfsg material. See the developers-reference, section 6.7.8.2 http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz Paul signature.asc Description: OpenPGP digital signature
Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers
On 14-11-13 21:56, Paul Gevers wrote: Would you mind creating a VCS repository on Alioth (collab-maint comes to mind) to ease further QA maintenance? That's a good idea. I will do that. Alioth is down due to broken disk raid, so you'll have to wait for now. Alioth is up again. Additional question: have you checked if you could solve one of the Ubuntu bugs against mtink? And, as you have been working on silencing lintian, why have you not tried to fix the extended-description-is-probably-too-short info warning? [PING] Paul signature.asc Description: OpenPGP digital signature
Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers
On 13-11-13 14:46, Graham Inggs wrote: Isn't it (easily) possible to fix these spelling errors, or are they false positives? If you stick to the overrides, please document why in the override file. Well, they occur in non-English messages so I would say false positives, but perhaps the best solution is for me to ask in the relevant debian-l10n-* mailing lists. Fair enough. I will add a note to the override file. Would you mind creating a VCS repository on Alioth (collab-maint comes to mind) to ease further QA maintenance? That's a good idea. I will do that. Alioth is down due to broken disk raid, so you'll have to wait for now. No hurry. Additional question: have you checked if you could solve one of the Ubuntu bugs against mtink? And, as you have been working on silencing lintian, why have you not tried to fix the extended-description-is-probably-too-short info warning? Paul signature.asc Description: OpenPGP digital signature
Bug#729359: RFS: mtink/1.0.16-8 [QA] -- Status monitor tool for Epson inkjet printers
Control: owner -1 ! On 12-11-13 11:01, Graham Inggs wrote: * Override remaining Lintian spelling error warnings. Isn't it (easily) possible to fix these spelling errors, or are they false positives? If you stick to the overrides, please document why in the override file. Would you mind creating a VCS repository on Alioth (collab-maint comes to mind) to ease further QA maintenance? Paul signature.asc Description: OpenPGP digital signature
Bug#714310: RFS: polyphone/1.1-1 [ITP]' from 'RFS: polyphone/1.0-1 [ITP]
[A review of part of the review] On 09-11-13 16:51, Daniel Lintott wrote: I'm also fairly new to reviewing, so forgive me if I miss something! 1. As your package is not yet in debian, the entries in debian/changelog should be merged to a single entry, for the version of the package that will enter Debian. This will also ensure your ITP bug is closed correctly upon upload. While most sponsors indeed prefer this, it is not needed per se. Also bugs in previous changelog entries can be closed with the upload if the sponsor takes special care. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
On 10/13/13 19:24, Graham Inggs wrote: If dx-doc and dxsamples are not installed, dx still functions, except that the online help and samples are not available. My reasoning was that if either dx-doc or dxsamples were installed on their own, without dx, there would be no change in their functionality whether the symlinks were present or not. The help and samples functions in dx, however, would not work if the symlinks were missing. Thanks for the explanation, I appreciate your thoroughness. I hope these benefits outweigh the risks of changing the prefix. Please go ahead. And as a side note, I prefer to upload dx and dxsamples closely together in time, so that users won't be disrupted (too long) for the change in the locations in either package. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
Hi Graham, I hope this is my last comment in this bug ;) On 11-10-13 17:37, Graham Inggs wrote: I agree that in most cases you would want the symlinks in the package that provides the target files. I think an exception would be where there is not a strong dependence (either way) between the package providing the target files and the package that needs, or makes use of, the symlinks. I that case, I think the symlinks should go in the package that uses them. Hmm, and in that case *I* would say they go (similar to the general case) into the package that provides the files. So that it is clear which package actually provides that functionality. See the bug mentioned below for an other example in your direction, however. Seems like this is a matter of taste. Anyway, why does dx need/use the symlink if it can, apparently, function well without the data. Also, in the dx package there are several symlinks located in /usr/lib/dx, I feel having all of these in the dx package rather than some in dx, some in dx-doc and some in dxsamples makes the most sense. Yes, but apart from thinking about how you would like it to be, you are here also changing the way it used to be. This always has additional risks, so usually, I would only do it if it would bring real benefits. We already saw the potential risk when it was forgotten to declare the proper replaces/breaks. In my case, dx recommends dx-doc and suggests dxsamples. I have not checked, but it seems as if the Lintian tag does not follow recommends and suggests dependencies, only depends. I think due to the default behavior in Debian, checking in Recommends makes lots of sense. I am not too sure about Suggests. But please, in case you persist, override the lintian warning, and note the lintian bug. Do you think I should file a bug against Lintian querying this? I already did a long time ago :) http://bugs.debian.org/683059 Maybe YOU want to add a note about Suggests. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
On 07-10-13 14:47, Graham Inggs wrote: On 05/10/2013 19:22, Paul Gevers wrote: What I intended you to do is to state the above also in bug 412811, so that it is clear for people looking at that bug report. And when you communicate with debian-legal, make sure the bug is in CC. I will do. I intend to follow up in both bugs after I have made further progress and after the upload records me as the maintainer of dxsamples. What I wrote in this bug was to let you know I was working on both. I should have made that clear. Ack. But I still think you can comment on these bugs, even if technically you are not yet the maintainer. These directories don't exist, am I (and lintian) right? So why do you even want these symlinks? Speculating now, but maybe this was something from the past. My understanding is these symlinks link the samples and java directories located in /usr/share/dx to where the main dx program expects to find them in /usr/lib/dx. A similar relationship exists with the dx-doc package where the main dx package has symlinks linking html and help located in /usr/share/doc/dx into /usr/lib/dx. Ah, I now see what you mean. The /usr/share/dx/java/* and /usr/share/dx/samples/* are files in dxsamples. Why did you want to move them from dxsamples to dx? Most of the time, but certainly not always, I would put them in the package that provides the target files. This is also what lintian warns about, so I guess my idea is not strange. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
On 05-10-13 09:23, Graham Inggs wrote: I have completed the changes in dx (getting dxexec to run on kfreebsd) and I think both packages are now ready for sponsoring. This week I have more time. I will try to look at both soon. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
On 28-09-13 11:15, Graham Inggs wrote: Could you please tag bug 412811 (new upstream version) as wont-fix if you still believe it is not fixable (please check). I did check on this with the previous maintainer and I intend to get the opinion of debian-legal on how to proceed. It may be possible to simply remove the offending example and release the new version. What I intended you to do is to state the above also in bug 412811, so that it is clear for people looking at that bug report. And when you communicate with debian-legal, make sure the bug is in CC. And could you please at least comment on bug 173709 (crashing examples). (moreinfo unreproducible are possible tags). Might even belong in dx instead of dxsamples. I did have a brief look at this and found there is a small number of samples that require scripts to be run or interactors to be built first. One of the samples in the bug report, supervise/complexdemo, is one of these. It may be that the reporter did not follow the instructions in the Readme. Same as above, please post this information to that bug report. And don't forget that follow ups to bug reports don't automatically go to the submitter. I have often made that mistake before somebody told me. dxsamples includes two symlinks: usr/share/dx/samplesusr/lib/dx/samples usr/share/dx/javausr/lib/dx/java These directories don't exist, am I (and lintian) right? So why do you even want these symlinks? Speculating now, but maybe this was something from the past. I feel it would be better if these were moved to the dx package as dx is only recommended by dxsamples Does that seem reasonable? If we still need them, yes. Else just drop them. But you forgot to Breaks: dxsamples ( 4.2.0-2) Replaces: dxsamples ( 4.2.0-2) in dx. See policy 7.6.1 [1] [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces For the small number of samples that require interactors to be built, I feel that dxsamples needs a suggests on libdx4-dev or the virtual package dx-dev. Does that seem reasonable, and which is preferred? As you provide dx-dev, I prefer that, but I can live with your current choice. Paul signature.asc Description: OpenPGP digital signature
Bug#724757: RFS: dxsamples/4.2.0-2 [ITA] -- Sample programs for the OpenDX Data Explorer
Control: owner -1 ! On 27-09-13 17:09, Graham Inggs wrote: * Package name: dxsamples Version : 4.2.0-2 Could you please tag bug 412811 (new upstream version) as wont-fix if you still believe it is not fixable (please check). And could you please at least comment on bug 173709 (crashing examples). (moreinfo unreproducible are possible tags). Might even belong in dx instead of dxsamples. Paul signature.asc Description: OpenPGP digital signature
FWD: RFS: doublecmd/0.5.6-1 [ITP] -- twin-panel (commander-style) file manager
Hi all, [Apparently not all e-mail ends up on d-mentors]. Graham is looking for a sponsor for his package doublecmd: * Package name: doublecmd Version : 0.5.6 Upstream Author : Alexander Koblov alexx2...@mail.ru * URL : http://doublecmd.sourceforge.net * License : GPL, LGPL Section : utils It builds the following binary packages: doublecmd-common - twin-panel (commander-style) file manager doublecmd-gtk - twin-panel (commander-style) file manager (GTK2) doublecmd-gtk-dbg - twin-panel (commander-style) file manager (GTK2 - Debug) doublecmd-qt - twin-panel (commander-style) file manager (Qt4) doublecmd-qt-dbg - twin-panel (commander-style) file manager (Qt4 - Debug) His packaging attempt is available here: http://anonscm.debian.org/gitweb/?p=collab-maint/doublecmd.git In addition, there is a separate help package which builds the following binary packages: doublecmd-help-en - Documentation for Double Commander (English) doublecmd-help-ru - Documentation for Double Commander (Russian) doublecmd-help-uk - Documentation for Double Commander (Ukranian) His packaging attempt of the help package is available here: http://anonscm.debian.org/gitweb/?p=collab-maint/doublecmd-help.git Regards Paul, for Graham Inggs Original Message Subject:A favour please? Date: Tue, 24 Sep 2013 11:58:20 +0200 From: Graham Inggs graham.in...@gmail.com To: Paul Gevers elb...@debian.org Hi Paul Could you forward this RFS bug to the debian-mentors mailing list please? http://bugs.debian.org/721497 I'm not sure why my bugs and posts are no longer appearing in the list. Regards Graham signature.asc Description: OpenPGP digital signature
Re: Volunteer in need of a mentor
Hi Beco, Welcome. On 23-09-13 21:39, Beco wrote: After some time programming my own softwares to solve little problems, scientific problems, and some useful exercises to teach C, I decided it's time to do another step. I am ready to help a little more, starting with packaging one little guy I have here. Good. I'll be very slow in this process, so I need a patient mentor It is our custom on this list to try to just answer questions as they come along. So no dedicated mentor is appointed. Just try to describe what you did and what problems you have and if somebody can help you and has the time, she will. I would need help to find useful links Although it might be a touch read, I really recommend to familiarize yourself with the policy [1]. A real good read is the maintainer guide [2] and the developers reference [3]. [1] http://www.debian.org/doc/debian-policy/ [2] http://www.debian.org/doc/manuals/maint-guide/ [3] http://www.debian.org/doc/manuals/developers-reference/index.en.html My first attempt will be a C library, I call libeco.h, I don't recommend packaging a library to start with. It is difficult to get all the packaging tricks of a normal package in Debian right. Let alone the additional problems of proper library handling. So, may I recommend you to have a look at our wnpp bug page [4] and check if there are packages that you use that are up for adoption (O or RFA)? That way you can get the hang of packaging for Debian, while increasing the quality of the archive. Yes, I know it is more fun to package your own stuff, but this is a real good way to help Debian. [4] http://bugs.debian.org/wnpp Paul signature.asc Description: OpenPGP digital signature
