Bug#699734: RFS: pfm/2.0.7-1
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package pfm
Package name: pfm
Version : 2.0.7-1
Upstream Author : Willem Herremans w.herrem...@scarlet.be
URL : http://pgfoundry.org/projects/pfm/
License : GPL-2
Section : misc
It builds those binary packages:
pfm - PostgreSQL graphical client using Tcl/Tk
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/pfm
Alternatively, one can download the package with dget using this
command:
dget -x http://mentors.debian.net/debian/pool/main/p/pfm/pfm_2.0.7-1.dsc
Changes since the last upload:
2.0.7-1:
* New Upstream version (depends itcl3 and tcl/tk = 8.5).
* Use upstream desktop file and icon.
* Remove references to pgintcl and tclkit as they are no longer shipped in the
upstream tarball.
* Move html documentation to /usr/share/doc/pfm/html/.
1.5.4-2:
* Depend on tcl and tk default versions =8.4 (closes: #654278).
* Updated watch file (thanks to Bart Martens).
* Fix lintian warnings.
- Move build commands to binary-indep target.
- Add ${misc:Depends} dependency.
- Add stub build-arch and build-indep targets.
- Upgrade build to debhelper compat 8.
- Move upstream web URL to Homepage field in control
file (closes: #615310).
- Update to standards version 3.9.4 (no
changes).
* Add doc-base control file.
* Provide .desktop file.
* Change to source format 3.0 (quilt).
Regards,
Mark Hindley
--
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/20130204094750.gv6...@hindley.org.uk
Bug#699474: RFS: b43-fwcutter/1:017-1 [ITA]
On 02/04/2013 01:32 PM, Ma Xiaojun wrote: On Fri, Feb 1, 2013 at 5:25 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: No, unfortunately the package is not ok yet. When I install the package b43-fwcutter, it will prompt the debconf question in Spanish. Really? Where to check the source package content? Yes, really. Check: b43-fwcutter-017/debian/po/en.po I presume that this might come due to the fact that the .po file is called en.po instead of es.po and the Spanish translation is invoked when the locale is set to English (which is the case for me), I will test that. I haven't used debconf translations before. Also, after installing b43-fwcutter, nothing further happens. I have to install the firmware-b43-debs manually which is very confusing. Ideally, the package b43-fwcutter should detect the hardware and prompt for the installation of the proper package or at least depend on them. b43-fwcutter itself is just a firmware cutter as its name suggests. http://linuxwireless.org/en/users/Drivers/b43#Install_b43-fwcutter The thing is that absolutely nothing happens when installing the b43-fwcutter which I found confusing. So, obviously people have to ignore this package and always install the installer packages. This should be mentioned at least in the README.Debian or better in the package description. I also don't see why you can't just merge everything into one binary package. You install a package b43-firmware, it detects your hardware in the preinst script and downloads and installs the firmware accordingly. If the detection fails, it should prompt whether to download the firmware anyway and then abort the installation or continue the installation, depending on the user choice. But maybe that's just me. I'd be happy if you have convincing arguments why it should be handled differently. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/510fad87.9010...@physik.fu-berlin.de
Bug#699474: RFS: b43-fwcutter/1:017-1 [ITA]
2013/2/4 John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de On 02/04/2013 01:32 PM, Ma Xiaojun wrote: On Fri, Feb 1, 2013 at 5:25 AM, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: No, unfortunately the package is not ok yet. When I install the package b43-fwcutter, it will prompt the debconf question in Spanish. Really? Where to check the source package content? Yes, really. Check: b43-fwcutter-017/debian/po/en.**po I presume that this might come due to the fact that the .po file is called en.po instead of es.po and the Spanish translation is invoked when the locale is set to English (which is the case for me), I will test that. I haven't used debconf translations before. You are right!, my mistake, sorry! (fixed) Also, after installing b43-fwcutter, nothing further happens. I have to install the firmware-b43-debs manually which is very confusing. Ideally, the package b43-fwcutter should detect the hardware and prompt for the installation of the proper package or at least depend on them. b43-fwcutter itself is just a firmware cutter as its name suggests. http://linuxwireless.org/en/**users/Drivers/b43#Install_b43-**fwcutterhttp://linuxwireless.org/en/users/Drivers/b43#Install_b43-fwcutter The thing is that absolutely nothing happens when installing the b43-fwcutter which I found confusing. So, obviously people have to ignore this package and always install the installer packages. This should be mentioned at least in the README.Debian or better in the package description. I also don't see why you can't just merge everything into one binary package. You install a package b43-firmware, it detects your hardware in the preinst script and downloads and installs the firmware accordingly. If the detection fails, it should prompt whether to download the firmware anyway and then abort the installation or continue the installation, depending on the user choice. this part of the changelog[1], explains why it was necessary to split the package, however I think this will be no problem for us because the driver supports all cards with the Kerner 3.2 (which is in wheezy) Adrian and I are working on a new version of b43-fwcutter without virtual packages, which installed the appropriate firmware, depending on each card This will be more clear to users :) [1]: http://paste.debian.net/hidden/582ce9f5/ But maybe that's just me. I'd be happy if you have convincing arguments why it should be handled differently. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Regards. -- Epsilon http://wiki.debian.org/DanielEcheverry Linux user: #477840 Debian user Software libre http://www.rinconinformatico.net liberar blackberry http://enchulatucelu.com Libros online http://www.todopdf.net garmin y campin http://www.fitnessdeportes.com
Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications
Package looks pretty good ! Some quick comments: What's with the renaming (Please add a REAMDE.source for explanation thanks) ? $ uscan --verbose --force-download [...] Newest version on remote site is 1.4.1, local version is 1.4.1+repack1 = remote site does not even have current version -- Scan finished $ wget http://stable.hypertriton.com/agar/agar-1.4.1.tar.gz $ md5sum agar_1.4.1+repack1.orig.tar.gz agar-1.4.1.tar.gz 3483244d3be644f769f5b79fe4817063 agar_1.4.1+repack1.orig.tar.gz ce71fb11ad79c926a968a4ed29053820 agar-1.4.1.tar.gz And I have not look carefully if this is an issue with private glx implementation, but package currently FTBFS on my system: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libag-gui4/DEBIAN/symbols doesn't match completely debian/libag-gui4.symbols --- debian/libag-gui4.symbols (libag-gui4_1.4.1+repack1-1_amd64) +++ dpkg-gensymbolsXVrKDS 2013-02-04 15:46:19.0 +0100 @@ -931,7 +931,7 @@ agDefaultFont@Base 1.4.1 agDirDlgClass@Base 1.4.1 agDriverClass@Base 1.4.1 - agDriverGLX@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# agDriverGLX@Base 1.4.1 agDriverList@Base 1.4.1 agDriverListSize@Base 1.4.1 agDriverMwClass@Base 1.4.1 @@ -1074,4 +1074,4 @@ agWindowToFocus@Base 1.4.1 agnKeySyms@Base 1.4.1 agnUnitGroups@Base 1.4.1 - modMasks@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# modMasks@Base 1.4.1 dh_makeshlibs: dpkg-gensymbols -plibag-gui4 -Idebian/libag-gui4.symbols -Pdebian/libag-gui4 -edebian/libag-gui4/usr/lib/libag_gui.so.4.0.0 returned exit code 1 make: *** [binary] Error 1 Thanks, -- 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/CA+7wUsyy3rU9PGndtH0s5i9kRMeR8O43tR1+FH4HRF-UCuek=g...@mail.gmail.com
Bug#699651: RFS: mosquitto/1.1.2-1
I don't indent to sponsor this package, but here's a quick review: * Roger Light ro...@atchoo.org, 2013-02-02, 22:52: * Bumped standards release to 3.9.3. No changes needed. Lintian says: W: mosquitto source: out-of-date-standards-version 3.9.3 (current is 3.9.4) * Debhelper bumped to version 9 to help fix hardening-no-fortify-functions. Well, it didn't fix it. Lintian emits: W: libmosquitto1: hardening-no-relro usr/lib/libmosquitto.so.1 W: libmosquitto1: hardening-no-fortify-functions usr/lib/libmosquitto.so.1 W: mosquitto: hardening-no-fortify-functions usr/bin/mosquitto_passwd W: mosquitto: hardening-no-fortify-functions usr/sbin/mosquitto blhc confirms that at least some binaries were built without hardening. * Added upstart init script. * Modified normal init script to work if upstart is used. Lintian says: I: mosquitto: output-of-updaterc.d-not-redirected-to-dev-null mosquitto postinst E: mosquitto: duplicate-updaterc.d-calls-in-postinst mosquitto I: mosquitto: output-of-updaterc.d-not-redirected-to-dev-null mosquitto postrm E: mosquitto: duplicate-updaterc.d-calls-in-postrm mosquitto What is the build-dependency on python-setuptools for? AFAICS this package doesn't use setuptools. Both debian/rules and the top-level Makefile don't trap errors. See Policy §4.6 for details. Why do you need two for loops in debian/rules? They do exactly the same thing. You iterate over all supported Python 3 versions, but you build-depend only on the default one. Similarly, the python (= 2.6.6-3~), python2.7 build-dependency is not sufficient. You want: python-all (= 2.7). Why X-Python-Version: = 2.7? Upstream's setup.py says: 'Programming Language :: Python :: 2.6' What happened to python-mosquitto's Depends? Unless you have very good reasons, the -dev packages should be unversioned. License and copyright information for uthash.h is not included in debian/copyright. uthash is packaged separately in Debian. You should build mosquitto against the uthash-dev package instead of the embedded copy. mosquitto_passwd creates temporary files in current working directory in a non-atomic way. This is insecure if cwd if world-writable (e.g. /tmp). Moreover, rename() will fail if the password file is on a different partition than cwd. (And it'll fail silently, since the return value is 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/20130204150625.ga4...@jwilk.net
Re: nbc package has been removed from Mentors
Le 16/07/2012 11:17, Slavko a écrit : Dear mentors, Dňa Sun, 15 Jul 2012 09:54:17 + (UTC) mentors.debian.net supp...@mentors.debian.net napísal: Your package nbc all versions has been removed from mentors.debian.net for the following reason: Your package found no sponsor for 20 weeks I was patient with my package, but i was no success to find the sponsor. Please, what did i wrong? Or, please, what i must do better? Need i upload it again? Or something other? Or i need to suppose, that this package is not interested for Debian people and do not waste the sponsor's and my time with it, please? I think that this package can be interesting for Debian users. But, for now, you need to find a DD that is interested in it to sponsor it. This usually mean a DD that have LEGO Mindstorms NXT bricks so that he can test the package. Not sure there are lots of them. And, in this small population, one of them must accept to sponsor you. Ie, he must have some free time to check and test the package. I think that the best thing to do is to continue to maintain this package and to upload it regularly on mentor until a DD accepts to introduce it in Debian. Regards, Vincent thanks -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/510fd638.40...@free.fr
Re: Bug#699474: RFS: b43-fwcutter/1:017-1 [ITA]
On Mon, Feb 04, 2013 at 13:45 +0100, John Paul Adrian Glaubitz wrote: On 02/04/2013 01:32 PM, Ma Xiaojun wrote: b43-fwcutter itself is just a firmware cutter as its name suggests. http://linuxwireless.org/en/users/Drivers/b43#Install_b43-fwcutter The thing is that absolutely nothing happens when installing the b43-fwcutter which I found confusing. So, obviously people have to ignore this package and always install the installer packages. This should be mentioned at least in the README.Debian or better in the package description. I also don't see why you can't just merge everything into one binary package. You install a package b43-firmware, it detects your hardware in the preinst script and downloads and installs the firmware accordingly. If the detection fails, it should prompt whether to download the firmware anyway and then abort the installation or continue the installation, depending on the user choice. But maybe that's just me. I'd be happy if you have convincing arguments why it should be handled differently. There is no reason why users shouldn't be able to use b43-fwcutter on systems that do not have the hardware in question installed. The obvious use case is to be able to extract the firmware for another system that does not have a working internet connection in order to copy it via a thumbdrive. I find the distinction into b43-fwcutter and the -installer packages to be clear and correct. One problem with the b43-fwcutter package is its description in that it states: --- snip --- Utility for extracting Broadcom 43xx firmware fwcutter is a tool which can extract firmware from various source files. It's written for BCM43xx driver files. It grabs firmware for BCM43xx from website and install it. --- snip --- ^^ Which should be corrected. -- Wolodja deb...@babilen5.org 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Packaging ulogd 2.x
Hello I'm trying to package the last ulogd version (2.0.1) and I'm willing to maintain/adopt it in the long run (disclaimer: I'm not a DD neither a DM). [cc'ed both current ulogd maintainer and reporter of ulogd2 ITP[1]] I have some doubts with respect to packaging: 1. ulogd vs ulogd2 package name. I'm not sure why the ITP was filled changing the package name. It's true the file format has changed but it has changed before too between versions 1.02-2 and 1.23-1. I've decided to use the existing package name and document a file syntax change and use debconf to show a warning (actually it's what the current package is doing if you upgrade from 1.23). It this recommended practice? Is there any policy on this? 2. package version I'm using 2.0.1-0.1 hoping that someone will do an NMU. Is there any difference between 2.0.1-1 and 2.0.1-0.1? Policy here? 3. migrating d/copyright to DEP5 Current copyright is here[2] and I would like to migrate it to DEP5. From my previous experience it's enough to specify the upstream license in the 'Header paragraph' and then a 'Files paragraph' for debian/* files. In [3] you can see that apart from laforge's copyright, there are 3 other names (Daniel, Joerg and Achilleas) involved without copyright. 4. Versioned library dependency Upstream code requires libnetfilter-conntrack = 1.0.2 for building[3] but that dependency is not picked by shlibs:Depends neither by misc:Depends. The binary package ends depending o 'libnetfilter-conntrack3'. Should I add the versioned dependency manually? Thanks. Regards, maykel [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502305 [2] https://github.com/mmoya/pkg-ulogd/blob/master/debian/copyright [3] https://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=configure.ac;h=10b6e1fe33c1efc7a1f1cc0e45f361417b838d88;hb=a81f4f3e332f527abec1175f2b26228464edc78d#l48 -- 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/510fefc6.2060...@mmoya.org
Re: Packaging ulogd 2.x
El 04/02/13 18:28, Maykel Moya escribió: 3. migrating d/copyright to DEP5 Current copyright is here[2] and I would like to migrate it to DEP5. From my previous experience it's enough to specify the upstream license in the 'Header paragraph' and then a 'Files paragraph' for debian/* files. In [3] you can see that apart from laforge's copyright, there are 3 other names (Daniel, Joerg and Achilleas) involved without copyright. Ooops. Forgot the question here, so... What is the current practice for porting a copyright like this to DEP5? Thanks. maykel -- 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/510ff0f5.1090...@mmoya.org
Bug#699776: RFS: pycdio/0.18-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package pycdio * Package name: pycdio Version : 0.18-1 Upstream Author : Rocky Bernstein ro...@gnu.org * URL : https://savannah.gnu.org/projects/libcdio * License : GPL-3+ Section : python It builds those binary packages: python-pycdio - Python interface to libcdio optical media control library To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pycdio Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pycdio/pycdio_0.18-1.dsc This is a first upload. Changelog: pycdio (0.18-1) unstable; urgency=low * Initial package release. (Closes: #699772) -- Benjamin Eltzner b.eltz...@gmx.de Tue, 4 Feb 2013 21:46:59 +0200 Regards, Benjamin Eltzner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRECfeAAoJEK27BRz67lmpMXMQAJ7tFKwTTSI+hZtVQ7VpqnFT XfCxMTd4RxW1l82t+9XxblFJI5PRvv9uEzIlOMI7qGtE2zZoBykR6X+ldETPYMc5 LWLpVeYC7R+gC8DBXTUDNe0BhhkSYBEG22qZmlyPrez9cGmTTg7bAy/DY5fR2QYI YryN39ccWAUz1M79oTUMgPVUs1a43EMQXxnLN0yNq+mxOLYqlwn3JqfTdxUb42Wm xFAqfUj/UFEF5inQBP2HCLBPuAWYMkfqiEIKKMhou1t6ZLnZO4DSvQiOp3Ye+nHL CS6mJZPRlohMSObfvrt7cCViHD72tALC213EZEP8+hfQNGkcQt8IHaY9zEzUNxeG SS9B3Dr7U6gDa37zW0e87nZ1WtCSSGfFfL4ib7xrc0J2idjCtXFlVZwHrMoKGtHu JD9rbmrwsm0Gzy0G4ZK0kI1aOXOI9mFg5vuETwhiod1zrKu/ahw4u4VuSk5Tpvbt zVmQbqX5YRpmDY8m/dk/MsjxxzgxF/RQhZCIU4Ebd6C/jCweD/3IAzhZ7b8s9HpD YUftOS+4+40VSQHBHz8adzLvw2toY4BFVKLm9d0TdKqQzOgNppSg8X5ZIiBKHNs0 oPd7njUY5Nad1PF7k2SENbprUoYgdB9BhT8Q4KpIm6lGgI0Tx0RCjiqfBj9Yqtyg 6oyVEu18Hw4Cfc4VBWp3 =D7AJ -END PGP SIGNATURE- -- 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/511027df.80...@gmx.de
Bug#696782: RFS: sequitur-g2p/0.0.r1668-1 [ITP] -- Grapheme to Phoneme conversion tool
Il 24/01/2013 01:53, Jakub Wilk ha scritto:
* Giulio Paci giuliop...@gmail.com, 2013-01-14, 02:32:
http://mentors.debian.net/debian/pool/main/s/sequitur-g2p/sequitur-g2p_0.0.r1668-1.dsc
The license has this additional clause:
Should a provision of no. 9 and 10 of the GNU General Public License be
invalid or become invalid, a valid provision is deemed to have been agreed
upon which comes
closest to what the parties intended commercially. In any case
guarantee/warranty shall be limited to gross negligent actions or intended
actions or fraudulent concealment.
Shouldn't that be 11 and 12 instead of 9 and 10? I can't make sense of
it otherwise...
I asked the author. He explained that the problem was their legal department
was worried that the license terms could be changed by third party (i.e.,
FSF).
This is trivially fixed by including the whole license text in the tarball. I
don't see how adding extra clauses could help here, even if they made sense...
I know. I also pointed it upstream.
Our thought is that this clause is there just to say that the software is
released under GPL-2, so the reference to 9 and 10 should be right.
Unfortunately the author is not working anymore for the copyright owner, and
he cannot change the license. I wrote to the current head of department last
week, but I have
not received any answer yet.
Do you think the license, as it is, is acceptable?
Well, license with clauses I can't understand is not something acceptable for
me. But you may want to ask debian-legal@ folks for their opinion.
I got these replies:
http://lists.debian.org/debian-legal/2013/01/msg00034.html
http://lists.debian.org/debian-legal/2013/01/msg00035.html
http://lists.debian.org/debian-legal/2013/02/msg7.html
They all seem to indicate that the additional clause is non sense, but the
license is acceptable.
lintian4python emits a bunch of tags:
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/bin/sequitur-g2p:46
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/Evaluation.py:34
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/Minimization.py:48
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/SequenceModel.py:37
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/SequiturTool.py:41
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/g2p.py:46
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/misc.py:35
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/sequitur.py:38
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/symbols.py:41
w: sequitur-g2p: inconsistent-use-of-tabs-and-spaces-in-indentation
usr/share/pyshared/tool.py:50
The patch that fixes this is huge, and clearly not maintainable. Please make
sure this problem is fixed upstream by their next release.
Please also ask them to not include *.pyc files in the tarballs.
I will do, if I will ever be able to get in contact with someone upstream.
Unfortunately the original author is not working anymore for RTWH Aachen
University.
I wrote two times to the head of the department responsible for this software
to ask about the license and to ask if there is anyone that I can contact to
provide patches,
but I received no answer yet.
The shebang should be fixed before the dh_pysupport call. (python-supports
looks at shebangs to generate the ${python:Depends} substvar.)
Done.
I also switched from dh_pysupport to dh_python2.
Bests,
Giulio.
--
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/51102d68.7060...@gmail.com
Re: Packaging ulogd 2.x
On Tue, Feb 5, 2013 at 1:28 AM, Maykel Moya wrote: 1. ulogd vs ulogd2 package name. I'm not sure why the ITP was filled changing the package name. It's true the file format has changed but it has changed before too between versions 1.02-2 and 1.23-1. I've decided to use the existing package name and document a file syntax change and use debconf to show a warning (actually it's what the current package is doing if you upgrade from 1.23). It this recommended practice? Is there any policy on this? I would recommend not renaming the package and handling package upgrades properly, a warning doesn't sound like what I as a user of a package would expect. 2. package version I'm using 2.0.1-0.1 hoping that someone will do an NMU. Is there any difference between 2.0.1-1 and 2.0.1-0.1? Policy here? The package is orphaned, so it would not be an NMU. It should be either a QA upload or an adoption. 3. migrating d/copyright to DEP5 Current copyright is here[2] and I would like to migrate it to DEP5. From my previous experience it's enough to specify the upstream license in the 'Header paragraph' and then a 'Files paragraph' for debian/* files. In [3] you can see that apart from laforge's copyright, there are 3 other names (Daniel, Joerg and Achilleas) involved without copyright. Forgot the question here, so... What is the current practice for porting a copyright like this to DEP5? Same as for a new package; go through the upstream code looking for copyright and license statements. licensecheck can help there and /usr/lib/cdbs/licensecheck2dep5 can generate DEP5 output from the licensecheck output. You still need to go through the upstream code to make sure the output is complete and correct. 4. Versioned library dependency Upstream code requires libnetfilter-conntrack = 1.0.2 for building[3] but that dependency is not picked by shlibs:Depends neither by misc:Depends. The binary package ends depending o 'libnetfilter-conntrack3'. Should I add the versioned dependency manually? 1.0.2 is not available in Debian yet, so I wonder how you built it without that dependency satisfied? The build-dependency should be versioned, but the resulting shlibs:Depends is the responsibility of the libnetfilter-conntrack maintainer. I would suggest finding out the reason for the versioned build-dependency. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6F3On=QRYkMc8zQNY_duEafBTXsMeVt+-k2R2xtmACW=g...@mail.gmail.com
Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications
On 02/04/2013 09:50 AM, Mathieu Malaterre wrote: What's with the renaming (Please add a REAMDE.source for explanation thanks) ? $ uscan --verbose --force-download [...] Newest version on remote site is 1.4.1, local version is 1.4.1+repack1 = remote site does not even have current version -- Scan finished $ wget http://stable.hypertriton.com/agar/agar-1.4.1.tar.gz $ md5sum agar_1.4.1+repack1.orig.tar.gz agar-1.4.1.tar.gz 3483244d3be644f769f5b79fe4817063 agar_1.4.1+repack1.orig.tar.gz ce71fb11ad79c926a968a4ed29053820 agar-1.4.1.tar.gz This was because a pre-built Windows binary was included in the upstream source tarball. The complete source for the binary is included. After some discussion, the executable is now being left in and the pristine tarball is being included. I change the package version accordingly and re-uploaded to m.d.n. And I have not look carefully if this is an issue with private glx implementation, but package currently FTBFS on my system: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libag-gui4/DEBIAN/symbols doesn't match completely debian/libag-gui4.symbols --- debian/libag-gui4.symbols (libag-gui4_1.4.1+repack1-1_amd64) +++ dpkg-gensymbolsXVrKDS 2013-02-04 15:46:19.0 +0100 @@ -931,7 +931,7 @@ agDefaultFont@Base 1.4.1 agDirDlgClass@Base 1.4.1 agDriverClass@Base 1.4.1 - agDriverGLX@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# agDriverGLX@Base 1.4.1 agDriverList@Base 1.4.1 agDriverListSize@Base 1.4.1 agDriverMwClass@Base 1.4.1 @@ -1074,4 +1074,4 @@ agWindowToFocus@Base 1.4.1 agnKeySyms@Base 1.4.1 agnUnitGroups@Base 1.4.1 - modMasks@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# modMasks@Base 1.4.1 dh_makeshlibs: dpkg-gensymbols -plibag-gui4 -Idebian/libag-gui4.symbols -Pdebian/libag-gui4 -edebian/libag-gui4/usr/lib/libag_gui.so.4.0.0 returned exit code 1 make: *** [binary] Error 1 The package builds as-is in a current sid pbuilder environment. Those symbols are only built when the package configuration can successfully detect the presence of working GLX headers. It would be useful to check the config.log to identify the reason why this was unsuccessful for you. -- Stephen M. Webb stephen.w...@bregmasoft.ca signature.asc Description: OpenPGP digital signature
Bug#699669: RFS: agar/1.4.1+repack1-1 [ITP] -- toolkit for graphical applications
On 02/04/2013 09:50 AM, Mathieu Malaterre wrote: What's with the renaming (Please add a REAMDE.source for explanation thanks) ? $ uscan --verbose --force-download [...] Newest version on remote site is 1.4.1, local version is 1.4.1+repack1 = remote site does not even have current version -- Scan finished $ wget http://stable.hypertriton.com/agar/agar-1.4.1.tar.gz $ md5sum agar_1.4.1+repack1.orig.tar.gz agar-1.4.1.tar.gz 3483244d3be644f769f5b79fe4817063 agar_1.4.1+repack1.orig.tar.gz ce71fb11ad79c926a968a4ed29053820 agar-1.4.1.tar.gz This was because a pre-built Windows binary was included in the upstream source tarball. The complete source for the binary is included. After some discussion, the executable is now being left in and the pristine tarball is being included. I change the package version accordingly and re-uploaded to m.d.n. And I have not look carefully if this is an issue with private glx implementation, but package currently FTBFS on my system: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libag-gui4/DEBIAN/symbols doesn't match completely debian/libag-gui4.symbols --- debian/libag-gui4.symbols (libag-gui4_1.4.1+repack1-1_amd64) +++ dpkg-gensymbolsXVrKDS 2013-02-04 15:46:19.0 +0100 @@ -931,7 +931,7 @@ agDefaultFont@Base 1.4.1 agDirDlgClass@Base 1.4.1 agDriverClass@Base 1.4.1 - agDriverGLX@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# agDriverGLX@Base 1.4.1 agDriverList@Base 1.4.1 agDriverListSize@Base 1.4.1 agDriverMwClass@Base 1.4.1 @@ -1074,4 +1074,4 @@ agWindowToFocus@Base 1.4.1 agnKeySyms@Base 1.4.1 agnUnitGroups@Base 1.4.1 - modMasks@Base 1.4.1 +#MISSING: 1.4.1+repack1-1# modMasks@Base 1.4.1 dh_makeshlibs: dpkg-gensymbols -plibag-gui4 -Idebian/libag-gui4.symbols -Pdebian/libag-gui4 -edebian/libag-gui4/usr/lib/libag_gui.so.4.0.0 returned exit code 1 make: *** [binary] Error 1 The package builds as-is in a current sid pbuilder environment. Those symbols are only built when the package configuration can successfully detect the presence of working GLX headers. It would be useful to check the config.log to identify the reason why this was unsuccessful for you. -- Stephen M. Webb stephen.w...@bregmasoft.ca -- 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/51107b04.7080...@bregmasoft.ca
