RFS: l7-filter-userspace
Dear mentors, I am looking for a sponsor for my package "l7-filter-userspace". * Package name: l7-filter-userspace Version : 0.10-1 Upstream Author : Ethan Sommer, Matthew Strait * URL : http://l7-filter.sourceforge.net/ * License : GPLv2+ Section : net It builds these binary packages: l7-filter-userspace - Userspace layer 7 packet classifier The package appears to be lintian clean. The upload would fix these bugs: #503104. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/l7-filter-userspace - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/l7-filter-userspace/l7-filter-userspace_0.10-1.dsc The package recommends l7-procotols, which is not in Debian, however it has been already ITP-ed (#504398) and uploaded to mentors.debian.net. I would be glad if someone uploaded this package for me. -- Jakub Wilk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Gergely Nagy , 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have "r" in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. stuff isn't all that huge, and this review would concentrate on distributability alone, so would be fairly fast in most cases. Might be fast, but it's also boooring. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119165845.ga8...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Lucas Nussbaum , 2012-01-19, 19:27: I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. For example, the wnpp bugs are often misformed, or people don't follow the right process. The big difference is that nobody reads the wnpp bug traffic. But debian-mentors (or whatever the pseudo-package will be eventually called) bug traffic will land on this mailing list. Malformed bug titles will be promptly corrected, people don't following the process will be educated. :) * Integration into UDD bug search[2] [2] <http://udd.debian.org/bugs.cgi> It might be better to write a separate cgi for that, to add more specific logic. For example, you could easily split the list with: - new packages - new uploads for existing packages - packages already uploaded (RFS that should be closed) - RFS that couldn't be parsed Or we could write a bot that would usertag the bugs appropriately. Then you could use normal BTS view rather than UDD. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119190233.ga1...@jwilk.net
Re: RFS: python-x2go
inreg.py:64: undefined name 'X2goNotImplementedYetException' ./x2go/backends/control/_stdout.py:171: undefined name 'SSHException' ./x2go/backends/printing/_winreg.py:75: undefined name 'X2goNotImplementedYetException' ./x2go/backends/terminal/_stdout.py:325: undefined name 'X2goTerminalSessionException' ./x2go/backends/terminal/_stdout.py:942: undefined name 'X2goTerminalSessionException' ./x2go/backends/terminal/_stdout.py:944: undefined name 'X2goTerminalSessionException' I believe that the above are mostly (or all) true positives. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012012647.ga3...@jwilk.net
Re: RFS: git2cl
* Dmitry Smirnov , 2012-01-20, 23:49: But how much time and effort one can afford in order to regenerate single HTML file? Surely it wouldn't cost you more time than arguing about the issue takes. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120120132708.ga7...@jwilk.net
Re: RFS: libpam-abl , bug fix , package is already in Debian
* Alex Mestiashvili , 2012-01-16, 20:16: http://mentors.debian.net/debian/pool/main/libp/libpam-abl/libpam-abl_0.4.2-2.dsc The changelog says "debian/control added DM-Upload-Allowed", but 0.4.2-1 had already this field. What do you mean by "other architectures" (in the patch header)? Hi Jakub , It failed to built on many archs - https://buildd.debian.org/status/package.php?p=libpam-abl With this patch it suppose to be better , but I agree that the description sounds ambiguous. I've uploaded a new version with the corrected description . Assuming that the patch header was meant to follow DEP-3, then please note that the Description field is supposed to be like Description in debian/control: there are two parts, short and long one (though the latter is optional). But let's go to more important things. This: printf(PAD "%s (%lu)\n", buf, (unsigned long)data.size / sizeof(time_t)); is surely better than: printf(PAD "%s (%ld)\n", buf, (long int)data.size / sizeof(time_t)); (which you had in the previous version). But to be pedantically correct, it really should be: printf(PAD "%s (%zu)\n", buf, (size_t)data.size / sizeof(time_t)); I also modified changelog such a way that line "debian/control added DM-Upload-Allowed" appears in the correct section , but I have some doubts if it is ok to edit old changelog sections . That's fine with me. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120120172858.ga8...@jwilk.net
Re: RFS: watermelons
(Sorry for the late reply! :P)
* Stephen M. Webb , 2011-09-16, 10:47:
http://mentors.debian.net/debian/pool/main/w/watermelons/watermelons_1.1.1-1.dsc
The Larabie font is non-free. You have the following choices:
1) Document this fact in debian/copyright and move the package to
non-free.
2) Remove the font from the source package and move the binary package
to contrib (the source package can remain in main).
3) Remove the font from the source package and use a different font at
runtime.
How do you know that the package is GPL-2+ licensed? I didn't see any
explicit license grant in the source code. Please see:
http://lists.debian.org/debian-legal/2003/12/msg00194.html
Each option has its pros and cons, so I leave the decision up to you.
Please merge changelog entries for -1 and -2.
python is needed for the clean target, so it should go to Build-Depends,
not Build-Depends-Indep.
You build-depend on python-support, but you don't use it. On the other
hand, if you use dh_python2, you need to bump versioned dependency on
python to >= 2.6.6-3~.
Add ${python:Depends} to Depends (and then you can remove explicit
"python").
The watch file is slightly broken (uscan reports that version on
upstream site is an empty string), but I don't know it there's much we
can do about this.
Lintian emits:
W: watermelons: binary-without-manpage usr/games/watermelons
The game crashes when trying to save highscore:
| Traceback (most recent call last):
| File "melons.py", line 1, in
| import main
| File "/usr/share/pyshared/watermelon/main.py", line 56, in
| g.run(menu.Menu(g))
| File "/usr/lib/python2.7/dist-packages/pgu/engine.py", line 104, in run
| self.loop()
| File "/usr/lib/python2.7/dist-packages/pgu/engine.py", line 123, in loop
| if self.fnc('event',e): return
| File "/usr/lib/python2.7/dist-packages/pgu/engine.py", line 79, in fnc
| if v != None: r = f(v)
| File "/usr/share/pyshared/watermelon/menu.py", line 329, in event
| self.high.save()
| File "/usr/lib/python2.7/dist-packages/pgu/high.py", line 52, in save
| self.highs.save()
| File "/usr/lib/python2.7/dist-packages/pgu/high.py", line 145, in save
| f = open(self.fname,"w")
| IOError: [Errno 13] Permission denied: 'melons.hs'
/usr/share/pyshared/ is an implementation detail of Python helpers. You
shouldn't really rely on it existence, like you do in the
/usr/games/watermelons. (But see below.)
Since watermelons' Python modules are obviously not meant to be used by
other software, please don't install them as public modules. Install
them to a private directory, e.g. /usr/share/games/watermelons/.
If you made melons.py executable, /usr/games/melons could be just a
symlink to it, no need for a shell wrapper script.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120121132415.ga7...@jwilk.net
Re: RFS: gcc-4.5-doc-non-dfsg
* Samuel Bronson , 2012-01-21, 00:38: * Package name: gcc-4.5-doc-non-dfsg Does "non-dfsg" really need to be a part of source package name? What if FSF decides to free the documentation one day? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120121160935.ga4...@jwilk.net
Re: RFS: gcc-4.5-doc-non-dfsg
* Samuel Bronson , 2012-01-21, 13:44: * Package name : gcc-4.5-doc-non-dfsg Does "non-dfsg" really need to be a part of source package name? What if FSF decides to free the documentation one day? Then this source package will disappear, and its binary will be built from pristine gcc sources. Right, that was a silly argument. Thanks for pointing that out. As for the name, a quick look at the changelog will show that I obtained it by replacing "4.4" with "4.5" in the name of the source package that mine is based on. Still, I see no reason to include "dfsg" or "non-dfsg" in any package name (other than maybe "I want to repeat mistakes of my predecessors" :P). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122131638.ga3...@jwilk.net
Re: RFS: quickrdp
* Tobias Eliasson , 2012-01-21, 09:13: Tsclient is not a requirement for QuickRDP 1.1, but launching RDP connections won't work without it. If tsclient is being removed in a near future No, no. tsclient has been _already_ removed from unstable and testing (which are the distributions we care as far as new packages are concerned). I guess QuickRDP has to rely on rdesktop or another RDP frontend in a near future release. Will this affect this package however? This what _I_ wanted to ask. :) Yes, unfortunately a lot of people are still stuck with devices and hosts that only allow telnet :(. And since telnet package is 'Priority: standard', I don't see any reason not to change Recommends to Suggest. There are multiple implementations of telnet in Debian. Does quickrdp really need this particular one provided by the "telnet" binary package? If not, then the recommendation/suggestion should be changed to "telnet-client". Same goes for perl-base, but that's just for perl script support in QuickRDP. I guess Suggests will work here aswell. Do I understand correctly that this feature allows users to run their own Perl scripts? If this is the case, it should be probably "perl", not "perl-base". I don't understand why Lintian complains on helper-template-in-copyright. I can't see that it's actually a template anymore. Sure I used dh_make to create the template, but I've changed all parts I should as far as I understand... (obviously not though). It doesn't like "Upstream Author(s)". Just remove the "(s)". And why out-of-date-standards-version is 3.8.4 instead of 3.9.2 I have no idea. "Standards-Version: 3.8.4" is in debian/control, isn't it? How would I proceed here? I have obviously changes to make and I am upstream author. Since this ITP and RFS a new release of QuickRDP has been launched with new bugfixes that goes under version name 1.1.1. Since there already is a ITP bug filed should I just upload a new package to mentors.debian.org with the new version name Yes, please do. even if ITP#655156 states that 1.1 is the package in focus? Nobody cares about version numbers in the ITP bugs. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122141600.ga6...@jwilk.net
Re: How to migrate to testing
* Arno Töll , 2012-01-24, 11:48: The problem is now that the new version depends on some packages that are still not available everywhere (libatlas-base-dev), Like where? (Presumably you meant s/depend/build-depends/.) and it also fails to build on mips and mipsel (when running the unit test of the package). [..] So, what should I do now? Yes. Testing migration rules require that the package is built on all architectures it built in the past in order to enter Testing [1]. File a ftpmaster removal bug (ANAIS - architecture not in source) of outdated architectures in unstable for your package. Once they did, your package can migrate again [2]. Err. Removing binary packages should be only done a last resort. Also, ANAIS means "architecture (is) not allowed in (Architecture field in) source (package)". It _does not_ mean "the package is out of date on this architecture". -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124114636.ga2...@jwilk.net
Re: How to migrate to testing
* Olе Streicher , 2012-01-24, 12:52: The problem is now that the new version depends on some packages that are still not available everywhere (libatlas-base-dev), Like where? (Presumably you meant s/depend/build-depends/.) You are right here. However, the binary would depend from libatlas3gf-base, which is also not available on these platforms. "These" meaning what? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124120112.ga3...@jwilk.net
Re: How to migrate to testing
* Olе Streicher , 2012-01-24, 13:04: The problem is now that the new version depends on some packages that are still not available everywhere (libatlas-base-dev), Like where? (Presumably you meant s/depend/build-depends/.) You are right here. However, the binary would depend from libatlas3gf-base, which is also not available on these platforms. "These" meaning what? armhf and s390x. Oh, you don't need to worry much about these. They are not release architectures and they don't affect testing migrations. Of course, if you had (too much :P) time and access to the architectures in question, help in making atlas buildable there would be surely appreciated. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124130131.ga8...@jwilk.net
Re: How to migrate to testing
* Olе Streicher , 2012-01-24, 14:25: The main problem is that on the mips and mipsel architectures the packages compile but their unit tests fail - timeout on mips, Does the test suite involve heavy floating-point computations? Two of our mips buildds, corelli and lucatelli, doesn't have FPU, so it wouldn't be surprising if they couldn't run such a testsuite in a reasonable time. If this is the case, you probably want to ask mips buildd maintainers to blacklist your package on these buildds. and segfault on mipsel. The previous packaged version still didn't come with unit tests. I informed the upstream author, but they probably more concentrate on common platforms. I think, for practical reasons, one would not use sextractor on a MIPS machine yet, because it needs some processing power, so removing these architectures until a fix is available would be a better alternative thant using of a 6-year-old, buggy version (which never passed this kind of unit-test). It might be true that nobody will every use the package on MIPS. It's even possible that the old package doesn't work on MIPS at all. However it's also likely that the bug we're observing on MIPS exists also on other architectures, but it's latent there. How should I proceed here? File an RC bug against the package, tag it "help", send a copy of the bug report to debian-m...@lists.debian.org. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124171400.ga2...@jwilk.net
Re: How to migrate to testing
* Joachim Wiedorn , 2012-01-24, 19:05: Does the test suite involve heavy floating-point computations? Two of our mips buildds, corelli and lucatelli, doesn't have FPU, so it wouldn't be surprising if they couldn't run such a testsuite in a I have seen in some packages that tests were disabled because of some problems. So my idea for armhf and s390x is to disable only tests needing these floating-point computations. Wait, I'm confused. Are we still talking about sextractor? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120124185455.ga8...@jwilk.net
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
* Stephen M. Webb , 2012-01-25, 17:39: dget -x http://mentors.debian.net/debian/pool/main/s/skstream/skstream_0.3.8-1.dsc [snip] Changes since the last upload: skstream (0.3.8-1) UNRELEASED; urgency=low . * new maintainer (closes: #653977) This is a bit misleading. It would normally interpret such item as "I set myself as Maintainer". But this is not what happened here: you set Debian Games Team as maintainer, and added yourself to Uploaders. I think this should be written explicitly in the changelog. Now, I don't know what this package has to do with games, but if DGT fold don't mind, meh. (I'm not one of them, which is also a good excuse not to sponsor this package. :P) * renamed binary packages due to SONAME change But here are reverse-dependencies of the old binary package. Which means that uploading this to unstable starts a transition. What this discussed with the release team? It probably should, even though the number of involved packages is small. That said, the best moment to talk to the release team would be after the package has been thoroughly reviewed (thus: not yet). * moved to debhelper 8 What does this mean? I see that you rewrote debian/rules from scratch, apparently introducing regressions... Is that a part of "moved to debhelper 8"? Does you new d/rules support DEB_BUILD_OPTIONS=noopt like the old one did? Are you sure that there are no other regressions? * added debian/symbols file This looks a bit suspicious. Symbols that exist only on amd64? I seriously doubt it... * debian/copyright: convert to DEP-5 format I see no such changes to debian/copyright in my debdiff. You converted the package to source format 3.0 (quilt), but this is not documented in the changelog. Why is the patch name 0001-gcc-4.4.patch if the description is "fixes compilation errors with GCC **3.3**" (emphasis mine). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120126114901.ga6...@jwilk.net
Re: RFS: bibtool
* Adam Borowski , 2012-01-26, 16:23: The debian/copyright was corrected as well: lintian failed to detect non ASCII chars. Because they're perfectly fine. You're not supposed to mangle the names of copyright holders, etc. It should use UTF-8. Right. I somehow can't seem to find a policy paragraph specifying this There is none, as far as I know. (an omission?), Looks like it. Please feel free to file a bug against Policy. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120126153316.ga3...@jwilk.net
Bug#657428: RFS: surf -- simple web browser (QA upload)
owner 657428 !
thanks
* Vasudev Kamath , 2012-01-26, 13:17:
dget -x http://mentors.debian.net/debian/pool/main/s/surf/surf_0.4.1-5.dsc
This package builds without any lintian warnings. Below is the changelog
surf (0.4.1-5) unstable; urgency=low
* QA upload.
Here, for completeness, I would mention that you changed the Maintainer
field to Debian QA Group.
* debian/control:
+ Bumped Standards-Version to 3.9.2
Did this require any changes to the packaging?
* debian/surf.postinst:
+ Reduced the update-alternative priority to 30 as per request from user
to the previous maintainer
Hmm. Was there a bug report about that?
* debian/rules:
+ Introduced dpkg-buildflags by patching config.mk with
dpkg-buildflags.patch
This is formulated in a confusing way. I had to look at sources to
understand what happened.
Okay, so there are two changes:
1) You added a patch for config.mk that makes it honour {C,CPP,LD}FLAGS
from environment.
2) You added a hunk to debian/rules that exports these variables.
The hunk looks like this:
+#export DH_VERBOSE=1
+
+-include /usr/share/dpkg/buildflags.mk
+export CPPFLAGS CFLAGS LDFLAGS
Unfortunately, this _won't_ do the right thing for these dpkg-dev
versions that didn't provide the /usr/share/dpkg/buildflags.mk file.
Please see
<http://lists.debian.org/debian-mentors/2011/10/msg00307.html> to
understand why.
* debian/source/local-options:
+ Introduced local-options to undo the patches
No, no, no. debian/source/local-options doesn't belong in the source
package. And if you look carefully, dpkg-source in fact didn't include
it in .debian.tar.gz.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120127154642.ga8...@jwilk.net
Bug#657428: RFS: surf -- simple web browser (QA upload)
* Vasudev Kamath , 2012-01-27, 21:52: + Reduced the update-alternative priority to 30 as per request from user to the previous maintainer Hmm. Was there a bug report about that? No previous maintainer Kai forwarded mail to me as I had adopted his dwm package. I asked the reporter to raise a bug but he didn't do that. So what do you suggest me to do for this? Shall I raise a bug or its not required?. Well, I wanted to have some insight into what problem we're trying to solve here. Having it documented somewhere (preferably in a bug report) would be nice. The hunk looks like this: +#export DH_VERBOSE=1 + +-include /usr/share/dpkg/buildflags.mk +export CPPFLAGS CFLAGS LDFLAGS Unfortunately, this _won't_ do the right thing for these dpkg-dev versions that didn't provide the /usr/share/dpkg/buildflags.mk file. Please see <http://lists.debian.org/debian-mentors/2011/10/msg00307.html> to understand why. Ok I went through the conversation so I need to build-depend on dpkg-dev correct version for this and add conditional check for buildflags.mk. Please correct me if I'm wrong There is more than one way to fix this. The simplest is to have versioned build-dependency on dpkg-dev. (And then you don't need "-" prefix before include, or other conditional checks.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127165203.ga5...@jwilk.net
Re: RFS: dmaths
* Innocent De Marchi , 2012-01-24, 19:00: Hi Jakob, *cough* :) I have decided to make profound changes in the compilation of the package: I've removed some unnecessary things and updated debian/rules to dh $@. In addition, I have automated the process of packaging of sources. Thus, the compilation is more clear and simple. I hope that the package is now better. The package is in http://mentors.debian.net/debian/pool/main/d/dmaths/dmaths_3.4.2+dfsg1-1.dsc Thanks, I like the new .orig.tar more. I do wonder however, what happened to debian/dmaths.patch. Are these files mini_memo_dmaths_1.5.odt memo_OOo_dmaths_1.5.odt Lisez-moi.odt install.odt used for anything? If they are not, I'd appreciate if you could remove them from .orig.tar, too. It'll make future reviews easier. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127180502.ga...@jwilk.net
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
* Stephen M. Webb , 2012-01-26, 12:05: * renamed binary packages due to SONAME change But here are reverse-dependencies of the old binary package. Which means that uploading this to unstable starts a transition. What this discussed with the release team? It probably should, even though the number of involved packages is small. That said, the best moment to talk to the release team would be after the package has been thoroughly reviewed (thus: not yet). The old and new library packages are parallel-installable. I consider this a feature, Right, this is a property of every respectable shared library. since the library is a part of an MMORPG stack, and I anticipate a newer client app revision getting in to Debian long before a new server app, so the coexistence of both old and new SONAMEs will be required, at least for a little while. Could elaborate more of this? What is "client app" and "server app" in this context? Please bear in mind that having multiple versions of the same source package in a single suite is not really a desired state. As far as unstable is concerned, you don't have control over when the old package will be removed. While I think ftp-masters usually wait until the old version don't have rdepeds anymore, they can also do it whenever they see fit (possibly rendering not-yet-rebuilt packages uninstallable). Until very recently, it wasn't even possible (unless some dirty hacks were involved) to keep multiple versions of a library in testing. It's doable now, but such a state certainly doesn't make the Release Team happy. But, as you say, this will need to be discussed with the release team after this package (and other upgraded packages in the stack) has been thoroughly reviewed. Great. Does you new d/rules support DEB_BUILD_OPTIONS=noopt like the old one did? Are you sure that there are no other regressions? I have the greatest confidence that the dh sequencer support Debian policy much better than the previous hand-rolled debian/rules script. I have confirmed that the new debian/rules does indeed support DEB_BUILD_OPTIONS=noopt and DEB_BUILD_OPTIONS=nostrip. Did you build in unstable? I just did (with DEB_BUILD_OPTIONS=noopt), and saw this in the build log: /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.. -I.. -g -O2 -Wall -DNDEBUG -c -o sksocket.lo sksocket.cpp I would appreciate an explicit list of any apparent regressions, since they aren't apparent to me from the build logs or runtime testing of the package. I didn't have anything specific in mind (except noopt support). Looking at old debian/rules there are some things that dh certainly doesn't do: - setting LDFLAGS=-lstdc++; - passing --disable-debug to configure. Maybe these were no-ops or simply wrong. Maybe not. I didn't check. :) Now some things I didn't catch in my initial review: The package descriptions were modified, but this is not documented in the changelog. The .orig.tar is compressed with bz2, but uscan would download a .tar.gz. I see the upstream provides bzip2ed tarballs too, so it should be a matter of fixing debian/watch. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127184549.ga1...@jwilk.net
Re: Renaming file names because of conflicts
* Olе Streicher , 2012-01-27, 19:57: overwrite_dh_movefiles: dh_movefiles mv debian/wcstools/bin/imcat debian/wcstools/bin/imcatalog mv debian/wcstools/man/man1/imcat.1 debian/wcstools/man/man1/imcatalog.1 But dh never calls dh_movefiles, so it wouldn't call the override either. (Also, typo: overwrite->override :P) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012012719.ga8...@jwilk.net
Bug#657428: RFS: surf -- simple web browser (QA upload)
* Vasudev Kamath , 2012-01-27, 23:49:
+ Reduced the update-alternative priority to 30 as per request
from user to the previous maintainer
Hmm. Was there a bug report about that?
No previous maintainer Kai forwarded mail to me as I had adopted his
dwm package. I asked the reporter to raise a bug but he didn't do
that. So what do you suggest me to do for this? Shall I raise a bug
or its not required?.
Well, I wanted to have some insight into what problem we're trying to
solve here. Having it documented somewhere (preferably in a bug
report) would be nice.
Done reported it as bugs by including mail content which I got and
added closes in changelog
For the record, the bug number is #657646.
As I commented there, I'm not convinced that reducing priority is
necessary. That said, it won't do (much) harm either, so I don't really
mind.
Please consider applying the attached patch, which fixes some minor
whitespace issues.
I see you added patch header to debian/patches/X11.diff, which is great,
but if it was meant to follow DEP-3:
- "Last-Updated" should be spelled "Last-Update" and should use
-MM-DD format.
- You could add Bug-Debian field.
Oh, my remark about Last-Update(ed) also applies to
dpkg-buildflags.patch. :)
--
Jakub Wilk
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,8 +14,9 @@
* Added patch to config.mk to make it honour {C,CPP,LD}FLAGS environment
variable
* debian/rules:
-+ Export {C,CPP,LD} FLAGS environment variables for introducing
++ Export {C,CPP,LD}FLAGS environment variables for introducing
dpkg-buildflags
+
-- Vasudev Kamath Fri, 27 Jan 2012 23:22:17 +0530
surf (0.4.1-4.1) unstable; urgency=low
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: surf
Section: web
Priority: optional
-Build-Depends: debhelper (>= 8), libgtk2.0-dev, libwebkit-dev,dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 8), libgtk2.0-dev, libwebkit-dev, dpkg-dev (>= 1.16.1)
Standards-Version: 3.9.2
Maintainer: Debian QA Group
Homepage: http://surf.suckless.org
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
* Stephen M. Webb , 2012-01-27, 18:20: * debian/rules: add --with autoreconf to regenerate autoconfigury A typo, though I'm not sure which word you had in mind. :P * debian/control: tweaked for multi-arch Could you be more explicit about how it was tweaked? BTW, you could add "Multi-Arch: same" field to all 3 packages, so that there's an actual benefit from installing stuff into multi-arch directories. :) I see test failures in my build log: | make check-TESTS | make[3]: Entering directory `/build/skstream-hivd_N/skstream-0.3.8/test' | ...F.F.F.F | | | !!!FAILURES!!! | Test Results: | Run: 22 Failures: 4 Errors: 0 | | | 1) test: tcpskstreamtest::testConstructor_2 (F) line: 141 childskstreamtest.h | assertion failed | - Expression: sks->is_open() | - Check that echo service is running on local machine | | | 2) test: tcpskstreamtest::testOpen (F) line: 160 childskstreamtest.h | assertion failed | - Expression: skstream->is_open() | - Check that echo service is running on local machine | | | 3) test: tcpskstreamtest::testOpenNonblock (F) line: 189 childskstreamtest.h | assertion failed | - Expression: skstream->is_open() | | | 4) test: rawskstreamtest::testConstructor_1 (F) line: 262 childskstreamtest.h | assertion failed | - Expression: skstream.is_open() | - Raw only works on GNU/Linux and you must be root | | | PASS: skstreamtestrunner | = | 1 test passed | = ...but then the build process continues. :/ -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120128000951.ga9...@jwilk.net
Bug#657783: RFS: haildb 2.3.2-1.1 [NMU] [RC] -- Library implementing InnoDB-like database
* Tobias Frost , 2012-01-28, 19:52: * Update standards version to 3.9.2, no changes required No, no, no. We don't do such things in NMUs. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120128191237.ga3...@jwilk.net
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
* Stephen M. Webb , 2012-01-27, 21:26: * debian/rules: add --with autoreconf to regenerate autoconfigury A typo, though I'm not sure which word you had in mind. :P I don't see the typo. I added "--with autoreconf" to regenerate the autoconfigury (config.guess, config.sub, aclocal.m4, ltmain.sh, libtools, etc). Hmm. Maybe the word "autoconfigury" exists, but it's certainly the first time I see it. Also, according to minechangelogs, this word doesn't exist in any changelog amongst packages in the archive. I'd rewrite this sentence as: "... to regenerate autotools files". Do you suggest it's better to go whole-enchilada multi-arch? I think it's a low-hanging fruit, but I'm surely not going to force it upon you. I see test failures in my build log: Me too. The tests rely on manually configuring the OS is a specific, non-standard way. Should I just disable the test targets during the build to reduce the noise? All right, most of the failure have reasonable explanation (either they require echo service running or root privileges). But what about: test: tcpskstreamtest::testOpenNonblock (F) line: 189 childskstreamtest.h ? More importantly, since the build process succeeded, does it mean that _any_ build failure would be ignored. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120128224914.ga4...@jwilk.net
Re: RFS: quickrdp
* Tobias Eliasson , 2012-01-27, 07:38: Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/q/quickrdp/quickrdp_1.1.2-1.dsc Using "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)" would be more friendly to backporters. When referring to the language, the usual capitalization is "Perl", not "perl". Please consider fixing this in the package description. If you enable informative tags, lintian emits: I: quickrdp: hyphen-used-as-minus-sign usr/share/man/man1/quickrdp.1.gz:46 I: quickrdp: hyphen-used-as-minus-sign usr/share/man/man1/quickrdp.1.gz:50 I built the package with DEB_BUILD_OPTIONS=noopt, but it was compiled with optimizations anyway: | g++ -c src/PerlDatabase.cpp -o obj/PerlDatabase.o -O2 -g -Wall -I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -L/usr/lib/i386-linux-gnu -pthread -L/usr/lib/i386-linux-gnu -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -DDATA_PATH=\"/usr/share/quickrdp/\" | g++ -c src/RDPDatabase.cpp -o obj/RDPDatabase.o -O2 -g -Wall -I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -L/usr/lib/i386-linux-gnu -pthread -L/usr/lib/i386-linux-gnu -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -DDATA_PATH=\"/usr/share/quickrdp/\" | g++ -c src/RDPFrame.cpp -o obj/RDPFrame.o -O2 -g -Wall -I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -L/usr/lib/i386-linux-gnu -pthread -L/usr/lib/i386-linux-gnu -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -DDATA_PATH=\"/usr/share/quickrdp/\" ...and so on. The default value for "Locale telnet/Perl/SSH executable" dialogs appears to be "gnome-terminal". (??!) The .orig tarball on mentors is not identical to the one uscan downloads. Why? I'm afraid I can't devote more time to this package. I hope you'll find another sponsor soon. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129231338.ga4...@jwilk.net
Re: RFS: python-x2go
* Mike Gabriel , 2012-01-28, 04:11: Hi Jakub, Can you take a look again? Lintian now emits: P: python-x2go source: unneeded-build-dep-on-quilt I: python-x2go source: quilt-patch-missing-description 001_fix-undefined-objects.patch I: python-x2go source: quilt-patch-missing-description 002_setuppy-no-setuptools.patch P: python-x2go-doc: no-upstream-changelog I: python-x2go-doc: possible-documentation-but-no-doc-base-registration In override_dh_auto_clean, you call "dh override_dh_auto_clean". This doesn't make sense. (I'm surprised that it doesn't make your clean target fail...) I (and most other sponsor here) normally require one changelog entry per upload to the archive. -> DONE I would throw out most of the current changelog contents. Initial entry usually consinst only of a single line like "Initial release (closes: #314159)". Changes to the upstream source (i.e. patches) or non-obvious packaging decisions are worth documenting too, but that's it. For example, you wrote "* Add watch file". Very well, you did add it. But you also had added debian/control, debian/copyright and debian/changelog at some point. Would you write about them, too? ;) I'd exclude x2go.tests module from the binary package. -> TODO, not sure how to do that... Use rm. :) setup.py have install_requires = ['setuptools', ...], but the package doesn't depend on python-setuptools. So either setup.py or the Depends is wrong (probably the former). -> DONE (by patch 002_... Have you forwarded it upstream? $ pyflakes . | grep ': undefined name' [snip - lots of pyflakes warnings] I believe that the above are mostly (or all) true positives. -> DONE (by patch 001_...) Have you forwarded it upstream? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129235351.gb4...@jwilk.net
Re: dh_gencontrol and space separated list
* Mathieu Malaterre , 2012-01-30, 17:07:
Hi all,
I am trying to automated the list of archs from d/rules files. I am using :
...
include /usr/share/mono/mono-archs.make
%:
dh $@ --with cli
mono_archs=$(DEB_MONO_ARCHS)
override_dh_gencontrol:
dh_gencontrol -- -Vmono:Archs:"$(mono_archs)"
...
It seems like this is a bad idea, as I get:
$ dpkg-buildpackage
dpkg-buildpackage: source package gdcm
dpkg-buildpackage: source version 2.2.0-2
dpkg-buildpackage: source changed by Mathieu Malaterre
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build gdcm-2.2.0
dpkg-source: error: `${mono:Archs}' is not a legal architecture string
dpkg-buildpackage: error: dpkg-source --before-build gdcm-2.2.0 gave
error exit status 255
Note that this error came from dpkg-source, before debian/rules was run.
(Therefore, it has nothing to do with dh_gencontrol.)
If you're trying to use ${mono:Archs} in the Architecture field, then
no, you can't do this:
"While variable substitution is done on all control fields, some of
those fields are used and needed during the build when the substitution
did not yet occur. That's why you can't use variables in the Package,
Source and Architecture fields." (from deb-substvars manpage)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120130161834.ga3...@jwilk.net
Re: sponsorship-requests
* Boris Pek , 2012-01-30, 23:01: But this list was quite interesting (at least for me). Sponsored maintainers can learn more not only by own mistakes but also when they are reading other emails here. System messages from the bot are not very useful. Just a noise... I am sorry that this caused trouble to you. We could ask listmasters to filter out BTS bot messages. Now, there are certainly people (e.g. me) who do want to see control messages. But they could always subscribe to sponsorship-requests via PTS. What do others think? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130214402.ga8...@jwilk.net
Re: Updated upstream source with same version
* Daniele Tricoli , 2012-01-31, 01:13: I'm working on tipa (see #534384) Thanks! and I want to regenerate the orig source because upstream updated PostScript Type 1 Fonts and added a reference manual. The problem is that upstream did't make a new release but updated 1.3 instead. The last packaged version of tipa in Debian is 2:1.3-15. I am aware of two ways for handle the problem: 1) increase epoch: so use 3:1.3-1 Sorry, this won't work. Epoch is not included in .orig.tar name, and dak wouldn't accept a different file with the same name. 2) play with the version: for example somthing like 2:1.3+0-1 $ dpkg --compare-versions "2:1.3+0-1" gt "2:1.3-15" && echo "ok" confirms that it should work. I don't like very much solution n° 2, so I would like to choose the first. Are there any other solutions? Yes, ask upstream to do a proper release with new version number. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131002252.ga...@jwilk.net
Re: Updated upstream source with same version
* Daniele Tricoli , 2012-01-31, 01:50: Sorry, this won't work. Epoch is not included in .orig.tar name, and dak wouldn't accept a different file with the same name. Many thanks for the explaination. Yes, ask upstream to do a proper release with new version number. I wrote upstream and I asked to do a proper release. I hope he will do. If he won't, the only way to update tipa is using the version name hack, right? There is another option, but it's not necessarily less ugly: Keep the current tarball and include the additional files either in .debian.tar or in a supplementary .orig.tar. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFS: libpam-abl , bug fix , package is already in Debian
* Alex Mestiashvili , 2012-01-28, 12:09: I also modified changelog such a way that line "debian/control added DM-Upload-Allowed" appears in the correct section , but I have some doubts if it is ok to edit old changelog sections . That's fine with me. But please don't change timestamp for the old version. (Also, "DM-Upload-Allowed: yes" used to be the last line in the source stanza, is there a reason you moved it?) I've re-uploaded the package with fixed version string : http://mentors.debian.net/debian/pool/main/libp/libpam-abl/libpam-abl_0.4.3+testing.1-1.dsc What does "+testing.1" mean? Is that a pre-release thing? If this is the case, then use "~" instead of "+". -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131234227.ga4...@jwilk.net
Re: RFS: python-x2go
* Mike Gabriel , 2012-01-30, 23:50: I'd exclude x2go.tests module from the binary package. -> TODO, not sure how to do that... Use rm. :) -> DONE What is "rm debian/python-x2go/usr/share/pyshared/x2go/tests -Rfv" for? It doesn't seem to remove anything. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201000645.ga6...@jwilk.net
Re: build-indep and buildd
* Roger Leigh , 2012-02-01, 12:52: Could someone please gives an update on the status of build-indep target and buildd machine ? I am using the following pattern (as per dh documentation): #!/usr/bin/make -f %: dh $@ override_dh_auto_build-indep: $(MAKE) -C docs # No tests needed for docs override_dh_auto_test-indep: However buildd machine are still running -indep target. I'd like to test my package first on my local machine to mimic what would a buildd machine do (I cant find the dpkg-buildpackage command line option used for buildd) I would make sure you are Build-Depending upon a new enough debhelper; some versions were buggy until recently. The earliest non-broken version is 8.9.10, though at this point >= 9 is probably best. But that of course won't help, as dpkg-buildpackage doesn't use build-indep. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201125941.ga1...@jwilk.net
Re: sponsorship-requests
* Jakub Wilk , 2012-01-30, 22:44: We could ask listmasters to filter out BTS bot messages. Based on the feedback I received so far, I'm going to do that. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120202170457.ga6...@jwilk.net
Re: RFS: dmaths
* Innocent De Marchi , 2012-01-28, 17:33: Are these files mini_memo_dmaths_1.5.odt memo_OOo_dmaths_1.5.odt Lisez-moi.odt install.odt used for anything? If they are not, I'd appreciate if you could remove them from .orig.tar, too. It'll make future reviews easier. I have reviewed: no reference to them in macros files. I've deleted them (in the script for repackaging). Oh, I just realized that they were documentation files installed into /usr/share/doc/. Well, in that case maybe it's worth keeping them. (On the other hand they are all in French, so I have no idea how useful they are.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120202220116.gb8...@jwilk.net
Re: RFS: libpam-abl , bug fix , package is already in Debian
* Alex Mestiashvili , 2012-02-01, 18:51: What does "+testing.1" mean? Is that a pre-release thing? If this is the case, then use "~" instead of "+". Yes , it is pre-release version . The upstream had "-testting.1" in his version and I had to change this to meet the upstream_version requirements . "-" is allowed in upstream_version. But please notice that: 0.4.3-1 << 0.4.3+testing.1-1 << 0.4.3-testing.1-1 So you'll have a big problem once upstream releases the final 0.4.3. That's why you should use "~": 0.4.3~testing.1-1 << 0.4.3-1 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120202220803.gc8...@jwilk.net
Re: why does debian packaging think ITP is still open?
* Paul Elliott , 2012-02-07, 09:59: If I look at my package thru debian packaging: http://packages.qa.debian.org/libs/libswe.html It thinks my ITP #635672 is still open. However the changelog file contains a entry like this: . libswe (1.77.00.0001-1) unstable; urgency=low * Initial release (Closes: #635672) ... Why does packaging not see this? Have I made a mistake? Not you, but your sponsor. Quoting Developer's Reference §5.8.4: “Unless specified different by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).” -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120207161853.ga1...@jwilk.net
Re: RFS: dmaths
I finally found time to actually install the software and play a bit with it. I have to admit that I am deeply disappointed. I spent maybe 5 minutes and I saw: - tooltips in French; - tooltips in German; - dialog boxes in French; - *lots* of error messages in French; - an error box with no message at all (!); - unhandled exceptions in Basic code. (Mind you, I don't speak French or German and I've never configured my system or LibreOffice to use any of these languages.) This is not the kind of quality I expect from software that is in Debian. I am not willing to sponsor this package. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120208221812.ga2...@jwilk.net
Re: How to convince maintainer to use --as-needed?
* Stephen M. Webb , 2012-02-10, 07:12: I seek your advice regarding the best practice with using --as-needed. The --as--needed flag is automatically added to package builds in Ubuntu. If you do not want your package to fail to build from source (and thus not be included in the Ubuntu GNU/Linux distribution), you will at least test your project builds with that linker flag. That's not a very strong argument, to be honest. Here are some flam^H^H^H^Hthreads that discuss both pros and cons of --as-needed: http://lists.debian.org/debian-devel/2007/12/msg00265.html http://lists.debian.org/debian-amd64/2010/11/msg2.html -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210123053.ga4...@jwilk.net
Re: how to manage d/changelog for updated but not yet sponsored package
* Ben Finney , 2012-02-13, 13:40: I want to keep trace of it in the d/changelog by keeping my first version entry and adding a second entry. Can I do that ? Will it confuse some Debian robots ? It's fine. I consider uploading the package to ‘mentors.debian.net’ a release of the package, since at that point interested people (e.g. reviewers) can rely on it, and the version should refer uniquely to what I uploaded at that time. Be aware, though, that some people disagree (on the grounds that it's not a new version until it enters Debian). I believe that vast majority of sponsors disagree. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213105345.ga2...@jwilk.net
Re: how to manage d/changelog for updated but not yet sponsored package
* Charles Plessy , 2012-02-13, 20:07: I consider uploading the package to ‘mentors.debian.net’ a release of the package, since at that point interested people (e.g. reviewers) can rely on it, and the version should refer uniquely to what I uploaded at that time. Be aware, though, that some people disagree (on the grounds that it's not a new version until it enters Debian). I believe that vast majority of sponsors disagree. Note however that the FTP team does not reject such packages. What kind of argument is that? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213223622.gb1...@jwilk.net
Re: RFS: themole
* installing by just copying python files to /usr/share/themole is far from elegant. Uh? This is the idiomatic way to install Python applications. there is no byte-compilation of files, unless themole gets invoked by root (which in term is a bad thing itself as /usr/share gets written to at run time, and it is not cleaned up on uninstall). a simple --with python3 after "dh $@" won't do by itself either. Yes, it would. dh_python3 does care of bytecompiling stuff in /usr/share/$packagename/ (even though it's not documented, sigh). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213233144.ga7...@jwilk.net
Re: RFS: themole
* installing by just copying python files to /usr/share/themole is
far from elegant.
Uh? This is the idiomatic way to install Python applications.
are you sure?
Well, I've been reviewing packages implemented in Python for over 2
years. You are the first person who questioned my expertise on this
subject. So while I feel now a bit embarrassed, yes, I'm sure.
i've made a short survey by looking at files in
/{{usr,}/{s,}bin,usr/games}/ and looking for symlinks to /usr/share to
as python scripts (found five distinct packages doing that: gdebi, gtg,
python-xlrd, and upnp-inspector), looking for things that modify
PYTHONPATH (only paraview and non-python stuff), and looking for
scripts that do sys.path.append to use usr/share (no matches, but i've
just written two bug reports after going through occurrences of
path.append, one of them security critical)
so all in all, of those 76 packages that install python scripts to the
PATH (not counting the ^python packages), only half a dozen try to load
code directly from /usr/share. the others either have very small
executables (which reside solely in the bin folder and don't have any
auxiliary code) or use pyshared or dist-packages.
It's a bit hard to me to comment on your numbers, as I don't know which
packages did you look at.
So instead I did my own survey. I analysed all (164) binary packages
(co-)maintained by Python Applications Packaging Team in unstable/main.
- 20 don't ship any Python module at all.
- 73 ship private modules.
- 77 ship public modules.
(By simple math: - 6 ship both private and public modules.)
Amongst those that ship only public modules:
- There are 7 python-$something packages.
- There are at least 15 packages (mercurial-*, trac-*, maybe more) that
are plugins to other software. Directory layout of such packages is
determined by layout of software they extend.
It is true that there's non-negligible amount of Python scripts that are
thin wrappers over some public Python modules. Sometimes it's
because upstream provides (more or less) well-defined and (hopefully)
stable API to be used by other software. (Please note that it's
certainly not the case for themole!) In such case, the modules should be
in sys.path and the package name should be python-$something.
Sadly, often the only reasons behind installing stuff into public
places are:
1) poor support for such arrangement in distutils;
2) Debian maintainer(s) being either too lazy to fix it, or being
ignorant of namespace pollution.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214170949.ga...@jwilk.net
Re: how to install python applications
We encourage an application's modules to be installed privately when
they won't be of any use to other modules / applications.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
so what is the preferred way to make the programs find their modules,
then?
* put the main python file in /usr/share/my_package/ and symlink it
from /usr/bin (as it is done in themole), relying on python to resolve
the symlink and find the required modules next to the invoked file
* have a "import sys; sys.path.append('/usr/share/my_program'); import
my_main; my_main.run()" main wrapper in /usr/bin/
Choosing between these two is largely a matter of taste. The first one
is usually less work, so I prefer it.
* some distutils/distribute/distutils2 magic i'm not aware of
None that I'm aware. ISTR somebody claimed that distutils2 was supposed
to have some magic for this, but I can't see anything obvious in the
documentation.
and, unless it's the third option: is there an elegant way to integrate
that with packages that are already proper (in a python sense) packages
and have a setup.py?
Two possible ways that come to mind:
1) python setup.py install --root=debian/foo --install-lib=/usr/share/foo
--install-scripts=/usr/share/foo
2) Ignore setup.py completely and use dh_install to move stuff into
appropriate places.
(In both cases things get a bit hairy if a script has the name as Python
package name...)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214235852.ga...@jwilk.net
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
* Geoffroy Youri Berret , 2012-02-17, 00:41: - In debian/mpd-sima.postrm, you use awk but you don't Depend on it. Right, I replaced it with a “grep | cut” alternative. While I personally don't like awk :P, but if you like it, you _can_ use it in maintainer scripts without depending on it. awk is (in a way) an essential package: http://lists.debian.org/debian-mentors/2005/11/msg00193.html I believe that lintian would yell at you if you had unversioned dependency on awk. (And versioned dependency on awk would render your package uninstallable. :P) You're also checking if /usr/sbin/deluser is executable and silently not removing the user if it's not (same thing for delgroup). Since you Depend on adduser, you should assume these commands exist, and it should be an error visible to the user if they don't. Corrected as well. Err. What Policy §6.5 says: “[…] all ‘postrm’ actions may only rely on essential packages and must gracefully skip any actions that require the package's dependencies if those dependencies are unavailable.” So checking for existence of /usr/sbin/deluser _is_ the right thing if you want to use it. See this however: http://lists.debian.org/debian-devel/2012/02/msg00094.html - Regarding debian/wrappers, why not intall the python modules some place where python can find them by default? Well, these are not pure python modules but python applications. Hope I got you right, but they are private module which should stay private and should not get into python name space. ACK Hence the shell wrappers. I recommend to write such wrappers in Python, so that a user can run the software using non-default version easily. Or even easier, just make /usr/bin/$something -> /usr/share/mpd-sima/$something symlinks. And I think first line should read "#!/bin/sh", as outlined in debian policy 10.4. I guess I got confused by the python policy recommending a "/usr/bin/env" sha-bang. It's a very weak recommendation, if recommendtation at all. Python Policy §3.1 reads: “Programs that can run with any version of Python must begin with #!/usr/bin/python or #!/usr/bin/env python (the former is strongly preferred).” -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120217002832.ga4...@jwilk.net
Bug#659822: RFS: mpd-sima/0.9.0-1 (New upstream version)
* Benoît Knecht , 2012-02-17, 12:01:
- In debian/mpd-sima.postrm, you use awk but you don't Depend on it.
Right, I replaced it with a “grep | cut” alternative.
While I personally don't like awk :P, but if you like it, you _can_
use it in maintainer scripts without depending on it. awk is (in a
way) an essential package:
http://lists.debian.org/debian-mentors/2005/11/msg00193.html
I believe that lintian would yell at you if you had unversioned
dependency on awk. (And versioned dependency on awk would render your
package uninstallable. :P)
Interesting. In my package (minidlna), I'm depending on (gawk | mawk),
because I'm using awk in one of the maintainers scripts too; I take it
I should remove it, right?
If you use only basic functionality of awk, you can remove it, yes.
You're also checking if /usr/sbin/deluser is executable and silently
not removing the user if it's not (same thing for delgroup). Since
you Depend on adduser, you should assume these commands exist, and
it should be an error visible to the user if they don't.
Corrected as well.
Err. What Policy §6.5 says: “[…] all ‘postrm’ actions may only rely on
essential packages and must gracefully skip any actions that require
the package's dependencies if those dependencies are unavailable.”
So checking for existence of /usr/sbin/deluser _is_ the right thing if
you want to use it. See this however:
http://lists.debian.org/debian-devel/2012/02/msg00094.html
Yes, I realize now my advice was misleading at best.
Or I might have misread it. :)
What I meant is that you should try running the command anyway, so that
the error becomes visible to the user, but then catch the exit status;
something like:
deluser ${USER} || echo "Removing ${USER} failed."
This way, if the user is watching the output, they will know they need
to remove the user by hand afterwards. Does it make sense? (Again, I'm
doing this in my package, so I'd like to know if that's wrong.)
You should redirect the message to stderr. Other than that, I doesn't
look crazy, but I don't have a strong opinion about that.
The only example that is included in the Policy is:
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
db_purge
fi
(However debconf, in contrast to deluser, is supposed to work even when
its dependencies are not installed.)
I took a look at packages installed on my system, and there appears to
be great variety of style of this “gracefully skipping” in the wild.
Perhaps it's something worth standardising.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120217122306.ga6...@jwilk.net
Bug#660162: sponsorship-requests: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-16, 19:29: The 'tack' program is a diagnostic tool that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard ncurses release. I'll take a look at this. tack (1.07-2) unstable; urgency=low [snip] -- Samuel Bronson Thu, 16 Feb 2012 14:40:07 -0500 tack (1.07-1) unstable; urgency=low [snip] -- Samuel Bronson Sat, 04 Feb 2012 23:37:39 -0500 Please merge these two into a single 1.07-1. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120217161231.ga9...@jwilk.net
Bug#660162: RFS: tack/1.07-2
To be pedantically correct, build-dependency on autotools-dev should be
bumped to >= 20110508.1, as this version introduced the dh addon. (I
said “pedantically”, because a sufficient version is already in stable.)
Could you regenerate autotools stuff at build time? autoconf-dickey is
now in the archive, so this should be feasible. (If you feel
adventurous, you could try also with GNU autoconf.)
As far[0] as I can see, your debian/rules doesn't honour
DEB_BUILD_OPTIONS=noopt. You might want to acquire “correct”
{C,CPP,LD}FLAGS from dpkg-buildflags (enabling hardening as a
side-effect).
[0] Not very far, I didn't try to build the package yet. :P
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120218221752.ga8...@jwilk.net
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
* Benoît Knecht , 2012-02-21, 13:36: In the same file, you run compileall unconditionally; I guess it should only run during configure. What's wrong with running it unconditionally? As far as I know, none of the Python helpers in the wild create maintainer script fragments that'd check the first argument. You do not honor the settings from /etc/python/debian_config [1]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation Righto. Implementing byte-compiling is not really straight-forward. If you do it yourself, there's a great chance you'll do it wrong. Apart from the issue mentioned by Benoît: - Modules are not re-byte-compiled when the default Python version changes. - postrm doesn't remove anything (unless /bin/sh is a symlink to bash, which is not the default these days). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120221181905.ga...@jwilk.net
Re: versioning trouble
* Jerome BENOIT , 2012-02-22, 01:46: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: This is correct. You should have used "~" instead of "+", because: 2.54~cvs20120219 << 2.54 << 2.54+cvs20120219 how can I can manage it ? May I force version 2.54 ? may I use some work around here ? It would have been slightly easier for us if you said whether or not the package with such bad version has been uploaded to the archive, or at least mentioned the package name. I will assume that we're talking about bibtool, which has been already uploaded to unstable. You cannot use a lower version than the existing one. dak would reject such upload. The options you have are: 1) Use an epoch. However, once use epoch, you have to carry it forever. 2) Invent a version that is bigger than 2.54+cvs20120219, e.g: - "2.54+cvssucks" or - "2.54+really" or - "2.54.". 3) Instead of uploading 2.54, upload a CVS snapshot with a version number like "2.54+cvs20120212". 4) Wait until upstream releases 2.55. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120222014105.ga7...@jwilk.net
Re: RFS: python-gnupg
(I don't intend to sponsor this package.) * Elena ``of Valhalla'' , 2012-02-22, 12:23: dget -x http://mentors.debian.net/debian/pool/main/p/python-gnupg/python-gnupg_0.2.8-1.dsc Lintian from git[0] reports: W: python-gnupg source: syntax-error-in-dep5-copyright line 18: Continuation line outside a paragraph. Question to upstream: does random_binary_data need to be _that_ big? Seriously, it takes >97% of space in the tarball. :| You don't need to pass --buildsystem=python_distutils to dh, it'll detect the build system automatically. You probably also want to remove the "This file was automatically generated etc. etc." comment from debian/rules. Upstream provides a test suite. Please run it at build time, ideally using all supported Python versions. Upstream appears to support Python 3.X. Please consider building a separate python3-gnupg package. Please add Homepage field. Please add watch file. [0] I don't recommend running lintian from git in general. I just happened to know that git version will detect a bug in your copyright file, which unstable version doesn't yet. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120222122253.ga5...@jwilk.net
Re: RFS: python-gnupg
* Elena ``of Valhalla'' , 2012-02-23, 15:58: dget -x http://mentors.debian.net/debian/pool/main/p/python-gnupg/python-gnupg_0.2.8-1.dsc [many different problems] Thanks for your comments, I'm going to fix the package and reupload it. One question: should I increase the revision number I believe that most sponsors prefer not bumping revision in such case. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120223180350.ga2...@jwilk.net
Re: RFS: themole | python3 only app | 8 days since last RFS
(I don't intend to sponsor this package.) * Raúl Benencia , 2012-02-23, 09:40: http://mentors.debian.net/debian/pool/main/t/themole/themole_0.2.6-1.dsc Why priority "extra"? You build depend on "debhelper (>= 9.0.0)", but debhelper doesn't use such versioning scheme anymore. Even if did, "debhelper (>= 9)" would be both shorter and more friendly to backporters. Debian Policy 3.9.3 has been just released, you probably want to bump Standards-Version. Vcs-* fields are support for point to Debian packaging repository, not upstream repository. Unless there are good reasons (like: license issues, or tremendous space saving), I'd advise to use the pristine upstream tarball. But if you really must repackage, then it'd nice if: - package had version number that indicate that the source was repackaged (it's common to use +dfsg suffix is stuff was repackaged for DFSG reasons, or +ds otherwise); - you provided get-orig-source target in debian/rules. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120223191119.ga5...@jwilk.net
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-20, 14:50: * Bump debhelper build-depends: to (>= 7.0.50~), since we use override_dh_ targets. This should be omitted from the changelog, given that it's… * Add support for dpkg-buildflags(1) by bumping debhelper to compatibility level 9. …completely superseded later on. (Even though you didn't mention explicitly anything about Build-Depends.) You build-depend on ‘debhelper (>= 9~)’. How about dropping the tilde? The set of debhelper versions satisfying such requirement wouldn't change. Please run autoreconf-dickey with -f. (dh_autoreconf does run autoreconf with -f -i by default, but only if you don't supply the “program” parameter.) You dropped ‘LDFLAGS="-Wl,-z,defs,-ltic"’, but this is not documented. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120223222805.ga8...@jwilk.net
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-24, 18:32:
http://mentors.debian.net/debian/pool/main/t/tack/tack_1.07-1~mentors3.dsc
Arno is breaking mentors.d.n at the moment, so I took a look at git
repository instead. (I'm assuming it's up to date…)
* Re-add debian/watch file (was dropped in 1.06-3).
+ Enable uupdate.
As I said on IRC, uupdate is a no-no for me.
* Use dh-autoreconf to regenerate the configure script during build
+ Build-depends on dh-autoreconf and autoconf-dickey.
+ This also takes care of pulling up-to-date config.guess and config.sub
scripts in from autotools-dev.
Are you sure? As far as I can see it doesn't do that:
$ ls -l config.{sub,guess}
-rwx-- 1 jwilk users 44941 Nov 20 2009 config.guess
-rwx-- 1 jwilk users 34423 Nov 20 2009 config.sub
$ dh_autoreconf autoreconf-dickey -- -f -i
$ ls -l config.{sub,guess}
-rwx-- 1 jwilk users 44941 Nov 20 2009 config.guess
-rwx-- 1 jwilk users 34423 Nov 20 2009 config.sub
- DEB_LDFLAGS_MAINT_APPEND for the rest.
DEB_*_MAINT_* were added to dpkg-buildflags in 1.16.1, so you need a
versioned build-dep for that.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120226001639.ga1...@jwilk.net
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-25, 22:43: + ... except with autoconf-dickey it doesn't, so use autotools-dev's dh_ commands; bump build-depends to autotools-dev (>= 20100122.1) accordingly. (Yes, even though it says "Do NOT" in the autools-dev README.Debian.gz.) Typo: autools-dev → autotools-dev. * Add support for dpkg-buildflags(1) by bumping debhelper compatibility level (and build-depends) to 9. I wanted to double-check that the hardening flags are actually used, but the build log is not particularly helpful: |dh_auto_build | make[1]: Entering directory `/build/tack-9xzja7/tack-1.07' | compiling ansi | compiling charset | compiling color | compiling control | compiling crum | compiling edit | compiling fun | compiling init | init.c: In function 'reset_init': | init.c:134:3: warning: ignoring return value of 'system', declared with attribute warn_unused_result [-Wunused-result] | compiling menu | compiling modes | compiling output | compiling pad | compiling scan | compiling sync | compiling sysdep | sysdep.c: In function 'spin_flush': | sysdep.c:369:4: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] | compiling tack | linking tack ... Could you please make it print actual commands that are being run? (See also bug #628515.) Later in the build log I see: | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if "debian/tack/usr/bin/tack" were not uselessly linked against it (they use none of its symbols). It would be nice if you could get rid of this dependency. (But that's OK if you don't want to.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226130904.ga5...@jwilk.net
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-26, 17:49: * Fix "hyphen-used-as-minus-sign" warning from lintian. This patch... * New patch 03-allow-echoing-compilation-commands.patch, which enables printing of compilation commands by default. ...and this patch have Forwarded headers pointing to gmane. Could you use links to the "official" web archive (i.e., http://lists.gnu.org/archive/html/bug-ncurses/) instead? Not every one likes gmane (e.g. I cannot stand its UI); lists.gnu.org would be more neutral. (I won't be insistent about this, feel free to ignore me.) Also, if you wanted the patch headers to follow DEP-3, then you probably need to remove stuff like "diff -Naurp tack.orig/tack.1 tack/tack.1" or "Index: tack-1.06/tack.1". Otherwise such lines could[0] be misinterpreted by a parser as a part of patch header. [0] I said "could" because the specification is far being clear (or maybe I should say s/clear/unambiguous/). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227002112.ga8...@jwilk.net
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson , 2012-02-27, 21:20: http://mentors.debian.net/debian/pool/main/t/tack/tack_1.07-1~mentors7.dsc (The new stuff can wait for a release.) Okay. There's a typo in the copyright file: Copyrigtt -> Copyright. But, to be frank, I'd just do s/Copyrig[ht]t (c) //g. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120228174658.ga6...@jwilk.net
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
(Please use X-Debbugs-Cc, rather than Cc, when submittig bugs. That way
the other parties will get the mail with bug number in the subject.)
I don't intend to sponsor this package, but here's my review:
* Paul Elliott , 2012-02-28, 18:32:
dget -x
http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.77.00-0-3.dsc
Please get rid of “<645551 is the bug number of your ITP>” and “source
package automatically created by stdeb” cruft from the changelog.
“Vcs-Browser” would be more consistent and more common capitalization
than “Vcs-browser”.
I'd merge all 3 changelog entries into one, and remove of the stuff from
it. There's no point mentioning that e.g. you added copyright file in an
initial release. Of course you did. (But OTOH patches you added might be
worth mentioning.)
Remove ${python:Breaks}, nothing generates this substitution variable
anymore.
The package description is very bad. Please see Developer's Reference
§6.2.3.
The copyright file doesn't say where the upstream sources were obtained.
This is serious violation of Policy §12.5.
I don't understand your lintian override. Why you can't correct the
spelling?
You can remove “--buildsystem=python_distutils” from debian/rules; dh is
able to detect the build system automatically.
Please get rid of the “This file was automatically generated by stdeb”
comment.
Do not use patches to remove files. Such patches are huge and are very
likely cause conflicts in the future. Just remove the files in
debian/rules (but see below).
The patches have “Forwarded: yes”, but were they actually forwarded? If
yes, to who? They look Debian-specific to me.
Assuming that you meant to use DEP-3 for your patch headers, and as far
as I understand the specification, you need an empty line before the
pseudo-header.
Please regenerate pydoc/* at build time.
The binary package name is wrong. It should be python-swisseph, as per
Python Policy §2.2.
Upstream seems to support Python 3, too. Please consider building a
separate python3-swisseph package.
The is no source for PDFs in the doc/ directory. You have the following
options:
- Ask upstream to include the source in their tarballs.
- Repackage their tarballs.
If you choose the latter option, you could also get rid of unneeded
files that delete-no-longer-need-swe-files patch currently removes.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120229124946.ga4...@jwilk.net
Bug#661665: RFS: openastro.org/1.1.25-2 [ITP]
I don't intend to sponsor this package, but here's the review:
* Paul Elliott , 2012-02-28, 18:32:
dget -x
http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.1.25-2.dsc
(Please see my reply to #661664. Many things I noted there applies to
this package, too. I won't mention them here again.)
Lintian emits:
P: openastro.org source: debian-control-has-unusual-field-spacing line 5
"debhelper (>= 7.0.50~)" instead of "debhelper (>= 7.0.50)" would be a
bit more friendly to backporters.
With dh_python2, you should use X-Python-Version, not XS-Python-Version.
Also, remove XB-Python-Version.
The package is arch:all, so there's no point including ${shlibs:Depends}
in Depends, as it won't be ever substituted.
Is there a reason for patching _comments_ in
0005-rename-openastro.py-as-required-by.patch? That looks strange.
When built with restrictive umask (e.g. 027), the package FTBFS:
| dh_fixperms
| chmod -x debian/openastro.org/usr/share/openastro.org/icons/aspects/*.svg
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/0.svg: new
permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/120.svg:
new permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/135.svg:
new permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/144.svg:
new permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/150.svg:
new permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/180.svg:
new permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/30.svg: new
permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/45.svg: new
permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/60.svg: new
permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/72.svg: new
permissions are rw-r--r-x, not rw-r--r--
| chmod: debian/openastro.org/usr/share/openastro.org/icons/aspects/90.svg: new
permissions are rw-r--r-x, not rw-r--r--
| make[1]: *** [override_dh_fixperms] Error 1
Then, if I try to build it again it fails with:
| dpkg-source -b openastro.org-1.1.25
| dpkg-source: info: using source format `3.0 (quilt)'
| dpkg-source: info: building openastro.org using existing
./openastro.org_1.1.25.orig.tar.gz
| dpkg-source: warning: ignoring deletion of file openastro.py
| dpkg-source: warning: ignoring deletion of file openastromod/swiss.py.orig
| dpkg-source: warning: executable mode 0700 of 'openastro' will not be
represented in diff
| dpkg-source: info: local changes detected, the modified files are:
| openastro.org-1.1.25/openastro
| dpkg-source: info: you can integrate the local changes with dpkg-source
--commit
| dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/openastro.org_1.1.25-2.diff.4r9kOA
| dpkg-buildpackage: error: dpkg-source -b openastro.org-1.1.25 gave error exit
status 2
Are the Python modules included in this package supposed to be used by
other software? If yes, then the package name should be
python-openastromod. If no, then please move them to a private
directory.
Version number passed to distutils.core.setup() contains a trailing
newline. Please report his to upstream.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120229172919.ga4...@jwilk.net
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP]
* Daniel Martí , 2012-02-29, 23:43: - Modules are not re-byte-compiled when the default Python version changes. * How should I solve this? I understand the problem, but scroogling around hasn't shown me any tips. The whole point of Python helpers (e.g. dh_python2) is to allow you not worry about such details. So just remove debian/postinst and debian/prerm; they are not needed anymore. But if you are curious how dh_python2 does it: it installs /usr/share/python/runtime.d/heybuddy.rtupdate into your binary package, which can be then called by python upon upgrade. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229225831.ga...@jwilk.net
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP]
* Daniel Martí , 2012-03-01, 15:22: I've removed postinst and prerm, and cleaned debian/rules of dh_python2 inside auto_install overrides (it builds exactly fine without it, so I guess it is run already by --with python2). Correct. I'd be very grateful if you could review it and upload it. Just to be clear: I don't intend to sponsor this package. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120301152850.ga4...@jwilk.net
Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]
* Paul Elliott , 2012-03-01, 14:03: On the issue of the pdfs, those pdfs are rebuilt from source in another package that depends on this package. Personally, I don't buy the “source is in another package” argument. It might be true for the time being (I didn't check), but next version of the other package could come with different documentation or simply without it. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120301231948.ga4...@jwilk.net
Bug#659522: RFS: prelink/0.0.20111012-1 [ITA] - ELF prelinking utility to speed up dynamic linking
* Daniel Martí , 2012-02-11, 21:15: dget -x http://mentors.debian.net/debian/pool/main/p/prelink/prelink_0.0.20111012-1.dsc Lintian report errors and warnings: W: prelink source: ancient-libtool ltconfig W: prelink source: ancient-libtool ltmain.sh 1.4.2 E: prelink source: ancient-autotools-helper-file config.sub 2002-09-05 E: prelink source: ancient-autotools-helper-file config.guess 2002-09-03 …and a few other minor issues: I: prelink: possible-documentation-but-no-doc-base-registration P: prelink: maintainer-script-without-set-e postrm -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120302133535.ga5...@jwilk.net
Disappearing
I have just unsubscribed from debian-mentors. In the unlikely event that I started reviewing your package AND you feel I should be obliged to continue the review, please Cc me. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120302212206.ga6...@jwilk.net
Re: Request For a Review: python-mpd2/0.4.1-1 [ITP]
* Geoffroy Youri Berret , 2012-03-20, 15:50: http://mentors.debian.net/debian/pool/main/p/python-mpd2/python-mpd2_0.4.0-1.dsc You wrote "debhelper (>= 9.0.0)" but debhelper doesn't use such versioning scheme anymore. I'd use plain "debhelper (>= 9)". python-all is needed in the clean target so it should go to Build-Depends, not Build-Depends-Indep. (OTOH, python3-setuptools could be in Build-Depends-Indep.) The benefits of splitting Build-Depends-Indep for arch:all-only packages are negligible, so I normally recommend using Build-Depends only. What is #Vcs-Git: git://git.debian.org/pkg-mpd/python-mpd2.git #Vcs-Browser: http://git.debian.org/?p=pkg-mpd/python-mpd2.git supposed to mean? Is Python 3.1 really not supported? I couldn't find any information about this in upstream source. If it's really not, then you need a version constraint for the build-dependency. Your Replaces is versioned but Conflicts is not. This is awkward. What has changed in python-mpd 0.3.0 that Replaces is not needed anymore? Is the conflict with python-mpd going to be permanent, or do you plan removing the other package at some point? In the former case, priority of one of the packages should be extra. (Policy §2.5: “optional packages should not conflict with each other”.) Lintian emits: I: python-mpd2 source: duplicate-long-description python-mpd2 python3-mpd2 Is there any reason for using a less liberal license for Debian packaging than the one upstream uses? You define PYTHON2 variable in debian/rules, but you don't use it. What is #override_dh_installchangelogs: # dh_installchangelogs -k foo/NEWS.rst supposed to mean? The watch file doesn't work: $ uscan --report uscan warning: In debian/watch, no matching hrefs for watch line http://pypi.python.org/packages/source/p/python-mpd/python-mpd2-(.*)\.tar\.gz -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120320160021.ga2...@jwilk.net
Bug#668966: RFS: dparser-1.16-1 [ITP] -- a scannerless GLR parser generator
Please use X-Debbugs-Cc instead of regular Cc when filing bugs:
http://www.debian.org/Bugs/Reporting#xcc
Thanks!
I don't intend to sponsor this package, but here's my review:
* Markus Wanner , 2012-04-16, 07:45:
http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.26-1.dsc
base-makefile-fixes.patch removes this line:
LIBS += -lm
But this is explained neither in the patch description nor in the
changelog.
The fix-python-makefile patch will break if Python version is longer
than 3 characters. (I know, unlikely, but it still bothers me. ;P) You
could query distutils directly for the build directory using the
following code:
python -c 'from distutils.command.build import build; from distutils.core
import Distribution; b = build(Distribution()); b.finalize_options(); print
b.build_platlib'
More importantly, the fix-python-makefile patch violates Policy §4.6.
Oh, and please don't add commented-out code, thanks.
Have you forwarded the manpage-hyphen-correction patch upstream?
Why priority extra? I'd use optional.
I'd rather not use ${python:Provides}. See:
http://lists.debian.org/20110324164804.ga5...@jwilk.net
In debian/copyright, you need to either add newlines (escaped by dots)
between list items or indent the whole list by an extra space. (License
uses the same rules as Description in debian/control; see Policy §5.6.13
for details.)
Please honour DEB_BUILD_OPTIONS=nocheck.
Please honour DEB_BUILD_OPTIONS=noopt.
This part of upstream makefile:
ifeq ($(ARCH),x86_64)
CFLAGS += -fPIC
endif
smells like a violation of Policy §10.2.
The package fails to build in a minimal environment:
python2.6 setup.py build
make[2]: python2.6: Command not found
make[2]: *** [all] Error 127
I see lots of
make[3]: svnversion: Command not found
in the build log. Is that intentional?
What is debian/dparser-doc.install for?
Version declared in setup.py is 1.9. Shouldn't that be 1.26?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120416213550.ga7...@jwilk.net
Bug#668966: RFS: dparser-1.16-1 [ITP] -- a scannerless GLR parser generator
* Jakub Wilk , 2012-04-16, 23:35: * Markus Wanner , 2012-04-16, 07:45: http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.26-1.dsc One more thing: pyversions -vr debian/control could be (more conventionally and more succinctly) written as: pyversions -vr -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120418151112.ga2...@jwilk.net
Bug#669209: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Eeek, I replied to the wrong bug. For the record, my review is here: http://lists.debian.org/debian-python/2012/04/msg00078.html -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120419091146.ga4...@jwilk.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
(I don't intend to sponsor this package.) * Dmitry Nezhevenko , 2012-04-22, 14:03: dget -x http://mentors.debian.net/debian/pool/main/p/python-django-djblets/python-django-djblets_0.6.17-1.dsc I'd use "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)", for easier backporting. DEP-5 spec says "There are many versions of the MIT license. Please use Expat instead, when it matches." "Files: media/js/jquery*" - did you mean "Files: djblets/media/js/jquery*"? More importantly, I don't see source for some of these files. License of feedparser.py is not documented in debian/copyright. AFAICS you don't need --buildsystem=python_distutils, dh will detect it automatically. Upstream provides a test suite. Please run it at build time, against all supported Python versions. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120424231708.ga9...@jwilk.net
Bug#669599: RFS: python-django-evolution/0.6.7-1 [ITP] -- Schema evolution for the Django web framework
(I don't intend to sponsor this package.) * Dmitry Nezhevenko , 2012-04-20, 13:39: http://mentors.debian.net/debian/pool/main/p/python-django-evolution/python-django-evolution_0.6.7-1.dsc Why priority extra? I'd use "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)", for easier backporting. What is python-feedparser dependency for? AFAICS you don't need --buildsystem=python_distutils, dh will detect it automatically. Upstream provides a test suite. Please run it at build time, against all supported Python versions. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120424233313.ga6...@jwilk.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
* Dmitry Nezhevenko , 2012-04-25, 11:46:
Yes. Will fix. But how can I handle these js files? There are actually
three versions of "minified" jQuery:
jquery-1.3.2.min.js
This one is jQuery...
jquery-ui-1.6rc2.min.js
jquery-ui-1.6rc5.min.js
...and these two is jQuery UI (a user interface library for jQuery). Not
sure why two versions are needed. I don't see any reference to 1.6rc2 in
the code.
If it will work, is it enough to just not use/remove these embedded
versions? Or I should repack upstream tarball?
You have the following options:
1) Repack the tarball.
2) Include the source somewhere in debian/ (in that case please mention
the fact in the copyright file; otherwise ftp-masters might miss it
while reviewing the .orig.tar!).
3) Ask upstream to provide the source in their tarballs.
Option 3 is preferable, but it also might be the hardest one.
jQuery UI has also a different copyright holder than jQuery proper, so
if you choose 2) to 3), you need to reflect that in the copyright file.
Oh, and looking again at jQuery UI, it's even worse than "just" missing
source: it's undistributable. The license is GPL or MIT. The GPL
requirements are obviously not satisfied. The MIT requirements ("The
above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.") are not satisfied
either.
Upstream provides a test suite. Please run it at build time, against
all supported Python versions.
Some of these tests are known-to-fail outside of specially configured
environment. How this should be handled?
Is it feasible to create such specially configured environment in
debian/rules? If yes, do it. :)
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120425101523.ga8...@jwilk.net
Bug#670204: RFS: pylucene/3.5.0-1 ITA -- Python extension for accessing Java Lucene
(I don't indend to sponsor this package.) * Dmitry Nezhevenko , 2012-04-24, 02:01: http://mentors.debian.net/debian/pool/main/p/pylucene/pylucene_3.5.0-1.dsc I'd use "debhelper (>= 8)" instead of "debhelper (>= 8.0.0)". Could you build a transitional package to allow smooth pylucene -> python-lucene upgrades? Please trap errors from "make clean" in debian/rules. PYTHON_DEFAULT, USR_SHARE and PYTHON_SHAREDDIR variables appear to be unused. Out of curiosity, what is NUM_FILES variable for? AFAIK dh_installchangelog installs CHANGES file automatically, so the override is not needed. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425105547.ga1...@jwilk.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
* Dmitry Nezhevenko , 2012-04-25, 17:59: I've addressed all issues reported by Jakub except tests one: - upstream tarball is now repacked with all JQuery files removed. - changed debhelper dependency to > 8 - changed package priority to optional - Use Expat license instead of MIT in debian/copyright, added feedparser license - Removed --buildsystem=python_distutils Running test suite is not currently possible. Issues reported to upstream. Once they will be fixed, I'll try to run them. Updated package: dget -x http://mentors.debian.net/debian/pool/main/p/python-django-djblets/python-django-djblets_0.6.17+dfsg-1.dsc AFAICS you don't need the dh_link override: dh_link would remove the file anyway if it existed. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120426154715.ga3...@jwilk.net
Bug#669599: RFS: python-django-evolution/0.6.7-1 [ITP] -- Schema evolution for the Django web framework
* Dmitry Nezhevenko , 2012-04-27, 15:47: http://mentors.debian.net/debian/pool/main/d/django-evolution/django-evolution_0.6.7-1.dsc lintian4python reports (among others): e: python-django-evolution: pyflakes-undefined-name usr/share/pyshared/django_evolution/evolve.py:72: sql_file_name -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427133516.ga2...@jwilk.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
* Dmitry Nezhevenko , 2012-04-27, 15:31: I've renamed source package to djblets to match upstream name. Binary package is still named python-django-djblets to match python policy. Erm, in accordance with Python Policy §2.2, the binary package name should be python-djblets, NOT python-django-djblets. dget -x http://mentors.debian.net/debian/pool/main/d/djblets/djblets_0.7~git20120402+dfsg-1.dsc This re-introduces the minified JavaScript code. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427134609.ga3...@jwilk.net
Bug#670619: RFS: django-pipeline/1.2.2.1-1 [ITP] -- Asset packaging library for Django
* Dmitry Nezhevenko , 2012-04-27, 14:22: dget -x http://mentors.debian.net/debian/pool/main/d/django-pipeline/django-pipeline_1.2.2.1-1.dsc As per Python Policy §2.2, the binary package name should be python-pipeline. Except that this name (not only Debian package name, but also Python module name) is already taken. Oops! lintian4python reports (among others): e: django-pipeline source: python-module-but-no-python-depends python-django-pipeline -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427140219.ga5...@jwilk.net
Bug#669598: RFS: python-django-djblets/0.6.17-1 [ITP] -- Collection of useful extensions for Django
* Dmitry Nezhevenko , 2012-04-27, 16:56: I've renamed source package to djblets to match upstream name. Binary package is still named python-django-djblets to match python policy. Erm, in accordance with Python Policy §2.2, the binary package name should be python-djblets, NOT python-django-djblets. Yes. I know. But at the same time it looks like this is a common practice to name packages for django as python-django. apt-cache search python-django shows something around 60 packages named as python-django. It's more like 45. And some of these do follow the Python naming policy. Half of the rest shouldn't have been uploaded to Debian in the first place IMHO, as the module name they provide is way too generic. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427142417.ga7...@jwilk.net
Bug#670619: RFS: django-pipeline/1.2.2.1-1 [ITP] -- Asset packaging library for Django
* Dmitry Nezhevenko , 2012-04-27, 17:09: dget -x http://mentors.debian.net/debian/pool/main/d/django-pipeline/django-pipeline_1.2.2.1-1.dsc As per Python Policy §2.2, the binary package name should be python-pipeline. Except that this name (not only Debian package name, but also Python module name) is already taken. Oops! Hmm. How I should handle it? Ask upstream to rename the module to something less generic. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120427152030.ga1...@jwilk.net
Bug#671403: RFS: python-lzo/1.08-1 [ITP] -- Python bindings for the LZO data compression library
* Mehdi Abaakouk , 2012-05-03, 22:26: http://mentors.debian.net/debian/pool/main/p/python-lzo/python-lzo_1.08-1.dsc Have you forwarded the patch upstream? Wouldn't it make sense to omit the "download/" part from the Homepage field? Since the licenses for debian/ directory and for the rest of the package are identical, you could save some space by moving their texts to a standalone license paragraph. Could you get rid of the comment in debian/rules? You don't need --buildsystem=python_distutils; dh with detect the build system automatically. Upstream provides a test suite. Please run it at build time, using all supported Python versions. pyflakes reports (among others): ./setup.py:24: undefined name 'CURL_DIR' ./setup.py:25: undefined name 'CURL_DIR' This does not affect Debian, but you might want to report it upstream. This packages closes ITP #671375 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671375) As per Developer's Reference §5.1, you should have sent a copy of the ITP to debian-devel. Also, Version pseudo-header doesn't make sense for wnpp bugs. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504162602.ga8...@jwilk.net
Bug#671403: RFS: python-lzo/1.08-1 [ITP] -- Python bindings for the LZO data compression library
* Abaakouk Mehdi , 2012-05-07, 11:14: You don't need --buildsystem=python_distutils; dh with detect the build system automatically. I have to use the python build system because the upstream provide a Makefile You are right. Sorry! Somehow I didn't notice the makefile. Upstream provides a test suite. Please run it at build time, using all supported Python versions. Added, but can you tell me if they are a better way to launch test against all supported debian python version ? You should use "pyversions -r" to get list of supported versions. Please honour DEB_BUILD_OPTIONS=nocheck. Please comply with Policy §4.6. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507100953.ga5...@jwilk.net
Bug#671403: RFS: python-lzo/1.08-1 [ITP] -- Python bindings for the LZO data compression library
* Mehdi Abaakouk , 2012-05-07, 14:11:
http://mentors.debian.net/debian/pool/main/p/python-lzo/python-lzo_1.08-3.dsc
Please merge the changelog entries into one. (I prefer one entry per
upload to the archive.)
I'd rather use $(shell pyversions ...) rather than `pyversions ...` - in
the former case pyversions output will be recorded in build log.
The test suite is slightly broken:
If lzo.decompress("xx") didn't raise exception, it would print
"Exception handling does NOT work !", but then proceed to return 0
(meaning sucess).
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120507133038.ga8...@jwilk.net
Bug#671403: RFS: python-lzo/1.08-1 [ITP] -- Python bindings for the LZO data compression library
* Mehdi Abaakouk , 2012-05-07, 19:37: Do you want my next upload to only contain that? python-lzo (1.08-1) unstable; urgency=low * Initial import (Closes: #671375) * add patches/01-use-lzo2-insteadof-lzo.patch to use lzo2 instead of lzo * add patches/02-fix-exception-handling-in-test.patch -- Mehdi AbaakoukMon, 07 May 2012 19:31:01 +0200 Right, that would be great. If you want to, will mentors.debian.org allow me to upload a previous revision of the package ? Yes, I believe it will. Or should I delete the package in the mentors.debian.org archive ? This shouldn't be necessary. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507182225.ga7...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-05-20, 03:20: nyancat (1.0+git20120519.5fe3de9-1) unstable; urgency=low * New upstream release - Fixes buildflags being incorrectly passed. Allows build hardening flags. * Switch to debhelper v9 OK. * Use reconf-inetd to provide nyancat-server configs I think you need some extra code in postinst to deal with this transition. See 'Transition of "Depends: update-inetd" packages' section of DEP-9. You updated nyancat-server's Description, but it's not documented in the changelog. nyancat-server manpage is gone, but it's not documented either. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523102758.gb3...@jwilk.net
Bug#673096: RFS: figlet/2.2.4-1
* Jonathan McCrohan , 2012-05-16, 00:27: dget -x http://mentors.debian.net/debian/pool/main/f/figlet/figlet_2.2.4-1.dsc One can also check out the package repository using git: git clone http://git.dereenigne.org/pkg-figlet.git More information about figlet can be obtained from http://www.figlet.org. Changes since the last upload: figlet (2.2.4-1) unstable; urgency=low * New upstream release. (closes: #617422) - Relicensed as BSD; figlet can move back to main \o/ * Improve packaging - Update S-V to 3.9.3 - Bump Debhelper to v9 - Switch to dpkg-source 3.0 (quilt) format .diff.gz of the previous package touches some upstream files. What happened to this delta? (This should be documented in the changelog.) I see you added makefile_set_debian_paths.patch, but this is not mentioned in the changelog. What's up with figlist_man_hyphen-used-as-minus-sign.patch? It's not listed in debian/patches/series. - Update debian/copyright (closes: #436302) You need to indent the enumerated list by an extra space. (Or alternatively: make all lines of the list indented by exactly one space, and then add (escaped) empty lines between the points.) - Fix moolets bashism (closes: #530082) You introduced a dashism instead... Oh, and it you are at fixing this, please also fix the security hole (insecure creation of temporary files). - Move figlet manpage to alternatives system (closes: 403665) I'd add a # here, for consistency with the other "closes" lines. Shouldn't you use --slave here? - Add watchfile Does ftp.figlet.org support only passive mode? (That would be very odd.) If this is not the case, I would not put "opts=pasv" in debian/watch. - Remove references to depreciated figfonts(-cjk) packages s/depreciated/deprecated/ maybe? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523173338.ga9...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-05-23, 11:48: I think you need some extra code in postinst to deal with this transition. See 'Transition of "Depends: update-inetd" packages' section of DEP-9. I purposely haven't added postinst code because according to popcon [1], nobody has installed the package. Well, I have it installed. Is that enough? :) Similarly, I didn't see a point in adding a NEWS page which could be confusing for users who were installing nyancat-server for the first time. I'm confused. What "NEWS page"? You updated nyancat-server's Description, but it's not documented in the changelog. nyancat-server manpage is gone, but it's not documented either. Again, for similar reasons, but this can be changed. Great, then please change it. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120524150940.ga4...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-05-25, 01:24:
- Add hardening-no-stackprotector override; false detection
I'd rather not add the override, but ignore the tag for the time being.
hardening-no-stackprotector will be disabled in the next lintian
release.
(Also: s/override/lintian override/. Otherwise it's not necessarily
obvious you're talking about lintian.)
- Update postinst to aid transition to reconf-inetd
You also removed postrm; please document that.
The postinst didn't work for me. I ended up with:
$ grep nyancat /etc/inetd.conf
## telnet stream tcp nowait nobody /usr/bin/nyancat
nyancat -t
telnet stream tcp6 nowait nobody /usr/bin/nyancat-server nyancat -t
telnet stream tcp nowait nobody /usr/bin/nyancat-server nyancat -t
What is "exit 0" in postinst for? It doesn't hurt, but it strikes me as
odd.
I think it would make sense if nyancat-server had a strict versioned (=
${binary:Version}) dependency on nyancat.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120525103454.ga9...@jwilk.net
Bug#673096: RFS: figlet/2.2.4-1
I'm no longer interested in sponsoring this package. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530112155.ga9...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-05-25, 23:57: * Use reconf-inetd to provide nyancat-server configs Now I realized the old postrm was broken... Ooops. Why --multi in the update-inetd call? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120531180445.ga8...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-05-31, 23:37: Why --multi in the update-inetd call? Because the new reconf-inetd entries are added before the postinst runs. update-inetd will see multiple telnet entries and alert the user that multiple servers exist for that service. --multi allows update-inetd to remove all three nyancat entries, two of which will then added back upon next reconf-inetd run. But next reconf-inetd run can happen a month later. (Or never.) In the mean time, nyancat server won't be running, will it? Or did I misunderstand something? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120531233752.ga7...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-06-02, 15:19: if dpkg --compare-versions "$2" lt "1.0+git20120523.99dc310-1"; then Shouldn't it be s/lt/lt-nl/? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602161905.ga8...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-06-02, 17:42: Shouldn't it be s/lt/lt-nl/? What difference does it make? Surely if the package was not previously installed, the grep match would fail, making the rest of the postinst no-op. Well, the line could have been added by user, in which case we shouldn't touch it. (Admittedly that's not very likely scenario...) But using lt has benefits too: if the user removed old nyancat-server, then installing the new one would clean after the buggy postrm. I'll leave the decision to you. I would add -x/--line-regexp to the fgrep call. Wouldn't it be nice if the postinst also take care of the case when the user enabled the service? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602172329.ga1...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-06-02, 19:27: I would add -x/--line-regexp to the fgrep call. Wouldn't it be nice if the postinst also take care of the case when the user enabled the service? Couldn't both of these issues be addressed by removing '## ' from the grep? I think we do need -x (or an equivalent of it). If the user appended some options to nyancat-server command-line, we must not remove such entry. BTW, shouldn't you use --pattern (instead of, or maybe in addition to, --multi)? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602185957.ga2...@jwilk.net
Bug#673096: RFS: figlet/2.2.4-1
* Bart Martens , 2012-05-28, 10:06: This seems an easy solution for figlet 2.2.4-1 : ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-3.TXT The license attached to this file is non-free: at the very least it doesn't allow modifications and it discriminates against fields of endeavor. (Not that I think it matters, but some people participating in this thread seemed to think it's a Very Big Deal, so I thought I'll mention that.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603123807.ga6...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-06-03, 03:12: I've uploaded a new version to mentors.d.n with changes to the postinst based on Serafeim's suggestions. I think solves all of the remaining transition issues. You wrote: if [ "fgrep -q -x ..." -o "fgrep -q -x ..." ]; then This condition is always true (also: not very portable). You want this instead: if fgrep -q -x ... || fgrep -q -x ...; then -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603195614.ga2...@jwilk.net
Bug#672185: RFS: gnome-session-shutdown/1.81-1 [ITP] -- Shutdown command for GNOME
(I don't intend to sponsor this package.)
* Jacopo Lorenzetti , 2012-05-09, 02:13:
http://mentors.debian.net/debian/pool/main/g/gnome-session-shutdown/gnome-session-shutdown_1.81-1.dsc
I'd use "=" instead of ":=" in debian/rules, so that the variable is not
uselessly evaluated even when it's not used. (And it won't be used most
of the time.)
The definition of DEBIAN_DIR could be simplified to:
$(dir $(firstword ${MAKEFILE_LIST}))
That said, I wouldn't bother with implementing get-orig-source target
when pristine upstream tarballs is being used.
What is build-dependency on docbook2x for?
I see some bugs and weirdnesses in upstream code:
Line 46:
import string
string module is so 90s! ;) Most of functions from that module
(including the ones you use) are deprecated.
Line 52:
# If running outside X try connecting to main display
try:
display = os.environ['DISPLAY']
except KeyError:
os.environ['DISPLAY'] = ':0.0'
This is weird. I haven't seen any program behaving that way. It's user
responsibility to set DISPLAY correctly, and I wouldn't want any program
to second-guess me on that matter.
Line 233:
wall.communicate(message)[0]
This looks a bit odd. Was the expression supposed to be assigned to
something? If not, the "[0]" part is redundant.
Line 287:
pidf.close
This is no-op. I guess it should be: "pidf.close()".
Line 288:
except:
return False
Catching all exceptions is almost always wrong (unless you re-raise them
later), for two reasons:
- you don't want to catch things like KeyboardInterrupt;
- you don't want to inadvertently ignore an exception that was raised
because of a bug in your program.
Please catch only exceptions you actually expect to be raised during
normal program execution.
Line 304:
if e.errno != errno.EEXIST:
You didn't import the errno module.
Lines 313-131: similar problems like in 287-288.
Line 349:
gettext.install('gnome-session-shutdown', LOCALE_DIR, unicode=1)
AFAIK if you can omit the LOCALE_DIR part, Python will do the right
thing. No need to hard-code path to locale directory.
Line 360:
for fname in os.listdir('/proc'):
if fname.isdigit():
if int(fname) >= 1000:
This looks very dubious to me. Why ">= 1000"?
Running pygettext on the source file results in:
$ pygettext gnome-session-shutdown
*** gnome-session-shutdown:131: Seen unexpected token "+"
*** gnome-session-shutdown:375: Seen unexpected token "+"
*** gnome-session-shutdown:397: Seen unexpected token "+"
*** gnome-session-shutdown:429: Seen unexpected token "+"
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120604135841.ga3...@jwilk.net
Bug#675388: RFS: python-cups/1.9.61-0.1 [RC] [NMU]
(I don't intend to sponsor this NMU.) * Rob Adams , 2012-05-31, 11:53: dget -x http://mentors.debian.net/debian/pool/main/p/python-cups/python-cups_1.9.61-0.1.dsc [...] Changes since the last upload: * Non-maintainer upload. * New upstream release. (Resolves: #656640) Did you mean s/Resolved/Closes/? * debian/control: - bump standard-version to 3.9.3 Were any packaging changes needed to do this? Anyway, this not appropriate for any NMU. * debian/compat: - bump to 9 Were any packaging changes needed to do this? Again, not appropriate for an NMU. * debian/rules: - switch from python-support to dh_python2 We don't do things like this in an NMU. What is this: | binary-*: | dh_python2 (in debian/rules) supposed to do? You added "X-Python-Version: >= 2.6", presumably because the new upstream version doesn't support with 2.5 anymore. Do you know why? You forgot to bump B-D on python-all-dev to >= 2.6.6-3~ (for dh_python2 support). * debian/source.lintian-override: - package-needs-versioned-debhelper-build-depends 9. No, lintian is correct. Fix the bug instead. Other changes you made that are not documented in the changelog: - added a trailing comma Uploaders (?!); - changed package description; - changed debian/copyright; - removed a patch; - added DEB_BUILD_HARDENING=1 and DEB_BUILD_HARDENING_STACKPROTECTOR=1 in debian/rules (?!); - prepended -fstack-protector to CFLAGS (shouldn't you use dpkg-buildflags to acquire CFLAGS instead?). Why "[RC]" in the bug title? As far as I can see the only bug this package fixes has severity normal. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120605150346.ga6...@jwilk.net
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
* Jonathan McCrohan , 2012-06-05, 02:53: Another version uploaded with a revised postinst which is based on the updated DEP-9 example. You don't need to check for existence of /usr/sbin/reconf-inetd. In postinst configure, it's guaranteed that packages you depend on are unpacked and configured (though the latter only if there are no dependency loops). That said, this extra check doesn't hurt, so unless I find other bugs, I'll upload the package as-is. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120605182953.ga1...@jwilk.net
