Re: Uploaded package is not showing up in mentors
Hi Arno, On Tue, Nov 8, 2011 at 2:48 AM, Arno Töll deb...@toell.net wrote: snipped You are missing dwm_5.9.orig.tar.gz there. If you forgot it for mentors too, that would explain your problem (however, you should have gotten a reject mail then). I think I missed while copying it to server. But I was uploading it to mentors for sure. I'll upload the orig tar ball to server by tonight. Best Regards -- Vasudev Kamath http://vasudevkamath.blogspot.com http://identi.ca/vasudev http://twitter.com/vasudevkamath -- 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/CAK+NOPU0kOAmiqiMqU_vQ=rrlnco8+gen9vujzec-z4xnkh...@mail.gmail.com
Re: How to maintain a large symbols file of a C++ library
Dear Thomas, Thomas Weber schrieb am 08.11.2011 00:18: I'm in the process of converting Debian's Octave packages into a structure with proper library packaging. The symbols file of these three C++ libraries has about 30k lines. I'm pretty new to symbols handling, so I'm looking for advice on how to handle this. Is there a simple way to reduce the pure size of this file? Or is this size normal? Further, looking at dpkg-gensymbols(1), it seems I should take special care about some C++-features - can you point me to an example of how to do this? I'd say: have a look at the Qt/KDE process and the pkgkde- helpers (warning: I'm not sure how well those behave for non-KDE/non-Qt libraries). A description on how to work with symbols for KDE/Qt stuff is available at [0]. Kind regards, Kai Wasserbäch [0] http://pkg-kde.alioth.debian.org/symbolfiles.html -- E-Mail: cu...@debian.org IRC: Curan Jabber: dri...@debianforum.de URL: http://wiki.debian.org/C%C3%B9ran GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 signature.asc Description: OpenPGP digital signature
Adopt an abandoned ITP?
Hi, There is a package I desperately want in Debian and there already is an ITP for it that is almost a year old. There wasn't any activity on it except that the author reverted the automatic ITP - RFP conversion after 6 monts of inactivity. I did write to the bug-author a few days ago if he still intends to package it but haven't received a response yet. So in general: What is appropriate the procedure in adopting such a bug? I don't want to 'hijack' anything. How long should I wait for a response from the author? Should I file a new bug or change the owner of the old one? greetings, Mati -- me on twitter: @mathiasertl | soup: http://soup.er.tl I only read plain-text mail! I prefer signed/encrypted mail! signature.asc Description: This is a digitally signed message part.
Re: Adopt an abandoned ITP?
Mathias Ertl m...@fsinf.at writes: There is a package I desperately want in Debian and there already is an ITP for it that is almost a year old. There wasn't any activity on it except that the author reverted the automatic ITP - RFP conversion after 6 monts of inactivity. I did write to the bug-author a few days ago if he still intends to package it but haven't received a response yet. So in general: What is appropriate the procedure in adopting such a bug? I don't want to 'hijack' anything. How long should I wait for a response from the author? Should I file a new bug or change the owner of the old one? This largely depends on which ITP bug we're talking about, as there might be good reasons the ITP is still pending. Without more information, though, no reasonable suggestion can be made, in my opinion. -- |8] -- 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/87d3d2svv3.fsf@algernon.balabit
Re: How to maintain a large symbols file of a C++ library
On Tue, Nov 8, 2011 at 12:18 AM, Thomas Weber twe...@debian.org wrote: Hi, I'm in the process of converting Debian's Octave packages into a structure with proper library packaging. The symbols file of these three C++ libraries has about 30k lines. I'm pretty new to symbols handling, so I'm looking for advice on how to handle this. Is there a simple way to reduce the pure size of this file? Or is this size normal? Further, looking at dpkg-gensymbols(1), it seems I should take special care about some C++-features - can you point me to an example of how to do this? Thanks Thomas Try to use hidden linking before doing this. Ask upstream hel, if needed. I am doing the same with imageemagick and next revision will include it. BTW do you need help on arpack ? Bastien -- 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/2007231800.GA27343@t61 -- 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/cae2spayqbna8rtiylbwm1l0zt7pfs77boebc1o9lrtgkccu...@mail.gmail.com
Re: Adopt an abandoned ITP?
Obviously, you should give the ITP/RFP bug author much more than a few days to respond... Have you mentioned your interest to the bug page? I would try to contact the bug author at least a few more times. On Tue, Nov 8, 2011 at 12:21 PM, Gergely Nagy alger...@balabit.hu wrote: Mathias Ertl m...@fsinf.at writes: There is a package I desperately want in Debian and there already is an ITP for it that is almost a year old. There wasn't any activity on it except that the author reverted the automatic ITP - RFP conversion after 6 monts of inactivity. I did write to the bug-author a few days ago if he still intends to package it but haven't received a response yet. So in general: What is appropriate the procedure in adopting such a bug? I don't want to 'hijack' anything. How long should I wait for a response from the author? Should I file a new bug or change the owner of the old one? This largely depends on which ITP bug we're talking about, as there might be good reasons the ITP is still pending. Without more information, though, no reasonable suggestion can be made, in my opinion. -- |8] -- 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/87d3d2svv3.fsf@algernon.balabit -- 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/camtvz+vs0aslkwrgbdatxayxonsrzgw4wkxfcbqu89d_xnl...@mail.gmail.com
Re: Adopt an abandoned ITP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 08.11.2011 12:21, Gergely Nagy wrote: This largely depends on which ITP bug we're talking about, as there might be good reasons the ITP is still pending. Without more information, though, no reasonable suggestion can be made, in my opinion. right. However, given that there was no visible activity for the past 6 months and the owner is still not responding (say, for a reasonable time frame after you asked him - don't forget do send a copy to the bug report itself), you may safely take over the ITP. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOuRRRAAoJEMcrUe6dgPNtWT4QAITjwEKh4JE9UimXmKr5sQBf xig365npKCjCyiUbsBR2OH1cAjBQKNnHHM8HEZAu2QejEome93QnoJ6M0aP6wSv3 LJIO8N8mpL4xzqvw7aY2PmY5E2hE9mF37Xn7BskvsK9MaS6b7+NLEkBqBFhSNDPL jaeL0F3MR3t079Z9wVdcdpn6sY+jvblD00MpKsVU8C2mgrFo+0Z9YqMadnZG8Zli O+NOXdSEWPjx8NZZvGgtQk5RM33inwRx8X4iMPa4O7eo1nRgK+FoCGww8mO48Lru YhioipCSjhlhSXj9znTdi3hjCgC2cZzXNf79IJiC7n/4FA6zpa/a3GN5noXmUcD+ /yvXRCE0XPlhCX42MgHaTnXU9JMq90A4EMRhSyNZEYnIjg1IUu7BDCF1yGES7d75 Ly2iCO3U3CasvN78g5DBQnLkW00clF0QhFxVhbsf6frImI7qf5IlvCCOm1lrFA23 ltB7ig6GE7IJASRkFf2iBTcE1V7rax3DVnwu91dNNJw0lHwUYFnd+X/7gT72gPVt Cb1TOZVCnDkec/QfHxl0qHxIFaJl/0qnMe2iubFgzr+p6VT7pCEYAEBYzaut7WwL 1Eqlz0sel/jCXJArO3KVRgkPCwx/wbhPvjfajz/K+UNu3r3fWajsl7L9ykT5FniG RCBynDec0IfICYRfmCc9 =W4L6 -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/4eb91451.2050...@toell.net
Re: Adopt an abandoned ITP?
You could also offer to co-maintain... On Tue, Nov 8, 2011 at 12:36 PM, Guido van Steen vanst...@users.sourceforge.net wrote: Obviously, you should give the ITP/RFP bug author much more than a few days to respond... Have you mentioned your interest to the bug page? I would try to contact the bug author at least a few more times. On Tue, Nov 8, 2011 at 12:21 PM, Gergely Nagy alger...@balabit.hu wrote: Mathias Ertl m...@fsinf.at writes: There is a package I desperately want in Debian and there already is an ITP for it that is almost a year old. There wasn't any activity on it except that the author reverted the automatic ITP - RFP conversion after 6 monts of inactivity. I did write to the bug-author a few days ago if he still intends to package it but haven't received a response yet. So in general: What is appropriate the procedure in adopting such a bug? I don't want to 'hijack' anything. How long should I wait for a response from the author? Should I file a new bug or change the owner of the old one? This largely depends on which ITP bug we're talking about, as there might be good reasons the ITP is still pending. Without more information, though, no reasonable suggestion can be made, in my opinion. -- |8] -- 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/87d3d2svv3.fsf@algernon.balabit -- 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/camtvz+u7sxzcd_gumgavkcx8ppfq+82m6tfx1buiyf4da+e...@mail.gmail.com
Re: Adopt an abandoned ITP?
On Tuesday, November 08, 2011 12:21:20 PM Gergely Nagy wrote: This largely depends on which ITP bug we're talking about, as there might be good reasons the ITP is still pending. Without more information, though, no reasonable suggestion can be made, in my opinion. Its about php-pecl-http and bug #606117. I didn't want to expose the bug publicly in fear of giving the impression of hijacking the package, but here it goes :) On Tuesday, November 08, 2011 12:37:17 PM Guido van Steen wrote: You could also offer to co-maintain... I did offer to co-maintain. I will however give the author another week or two and try another email in a week or so. On Tuesday, November 08, 2011 12:36:49 PM Arno Töll wrote: However, given that there was no visible activity for the past 6 months and the owner is still not responding (say, for a reasonable time frame after you asked him - don't forget do send a copy to the bug report itself), you may safely take over the ITP. The only activity is reclaiming the bug and changing it to ITP again. Thanks for your thoughts on that, in any case, so far! greetings, Mati -- me on twitter: @mathiasertl | soup: http://soup.er.tl I only read plain-text mail! I prefer signed/encrypted mail! signature.asc Description: This is a digitally signed message part.
Re: Adopt an abandoned ITP?
Mathias Ertl m...@fsinf.at writes: On Tuesday, November 08, 2011 12:37:17 PM Guido van Steen wrote: You could also offer to co-maintain... I did offer to co-maintain. I will however give the author another week or two and try another email in a week or so. On Tuesday, November 08, 2011 12:36:49 PM Arno Töll wrote: However, given that there was no visible activity for the past 6 months and the owner is still not responding (say, for a reasonable time frame after you asked him - don't forget do send a copy to the bug report itself), you may safely take over the ITP. The only activity is reclaiming the bug and changing it to ITP again. Thanks for your thoughts on that, in any case, so far! There seems to be another little note hidden inside the retitle[1]: , | # Argh, this just needs a little more work on my end. | # | # http://gitorious.org/pecl-http/pkg-debian | # | retitle 606117 ITP: php5-pecl-http -- Extended HTTP support for php5 | owner 606117 ! ` [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=18;bug=606117 Though, the git repo mentioned there was last modified last december as far as I see, so yup, it does look pretty much stale, and as others said aswell: give him a week or two more, and then take over if you get no response. I would also Cc the bug in question, to give your intention (both the co-maintaining help offer, and the possibility of adopting the ITP) a little bit more visibility, and transparency. -- |8] -- 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/878vnqstq3.fsf@algernon.balabit
Re: Adopt an abandoned ITP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Mathias, On 08.11.2011 12:54, Mathias Ertl wrote: I did offer to co-maintain. I will however give the author another week or two and try another email in a week or so. It is not visible you did so. Please CC: the bug report for increased transparency. Starting with that day, give the author another week or two to respond, then take over the bug. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOuRvHAAoJEMcrUe6dgPNtI8IQAJYLdAyryWTzsfctmm8k2Bkb AVBYR40gmdJgP2HMLUAp4RQYvADkHxyJVC2o/mYCNx+aPB+OE/WMP3Gsu/CSkTtT 6ORWy0jnkdlECE5BiSxfOkmNmBajxcuLUOS2z0tuLWIbzSRcIpjXI5XOAI3Tu9M8 u4U7bmeYfCp6zcZZrIXRcNs84pLsaYcOQDhNOZRTMNrxrqspBxHsuZv9X0fYmmsZ cR76MlieYkbs6p5KemoIhdSvnllunjALPkZTmj21SKpHNCMl1Zeyv0ga/TZUNuE3 dm6hLrArGZUzYWWZ2QoGI0LQnhTfnuduxM1K6YLFo0TyWF3pdlN354d0n1hFFfQC 3bYShD/uf3/+38JUC7r+XG4poJ/+CBw8CA++DPFulzDTp5Xpq0ZIfUwHFytsZUxl tOz4My0JRcr0M04g/jqR1ZToUA7Gn1Bm1emvkeYgLG3t8m4Yan1HlnGyuJ1QD3md ruD02Huvkic98umiV1A0spQ9xn6cLxvTwek0dO9OzSFg1ij7PpDhSl7qjHHNMG/0 lYAB2Gtxtl2nWzN4aNjkj48ApXQpt2JVDi/SJtaAOAqhgFXH8gr8Ke7RN7uu5vU4 qXSjSFbos5EmXz+ug1EIn4VYiARuIpv953HMXWLnbCW8mQ2cUAJdT6EPdmVPWZXr m5HTGOT6lUKelK/CKH4h =VoJR -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/4eb91bc7.9080...@toell.net
Re: leechcraft (closes ITP bug, 33 days have passed)
While I think this package is interesting, I do not intend to sponsor it. That said, here is a review of the source package: I'm not sure it is appropriate to change the ABI names used by upstream to a Debian-specific one. If you want to change the library names that should be done upstream. Please talk to upstream about how to make your patches unnecessary. Please add DEP-3 headers to your patches: http://dep.debian.net/deps/dep3/ qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. Some of the icons were created in Inkscape but the source code (SVG files) is missing. There are some pre-compressed audio files, I guess the preferred form for modification for those is missing and therefore we cannot distribute them since they are probably GPL licensed. In addition there is DFSG item 2. Your version number and your debian/rules get-orig-source do not indicate the reason for the tarball repacking. You can use wildcards in .install files like these: usr/share/leechcraft/translations/*/LC_MESSAGES/libeiskaltdcpp.mo usr/share/leechcraft/translations/leechcraft_poshuku_*.qm Some of the files have the incorrect FSF address in them, you might want to report that upstream. P: leechcraft source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5/ There are some .DS_Store files in the tarball, these are a waste of space, you might want to ask upstream to remove them. cppcheck finds some issues: qxmpp/src/QXmppTransferManager.cpp:423]: (error) Memory leak: buffer [src/plugins/azoth/plugins/metacontacts/managecontactsdialog.cpp:50]: (error) Possible null pointer dereference: entry - otherwise it is redundant to check if entry is null at line 53 [src/plugins/bittorrent/tabwidget.cpp:705]: (error) instance of Applier object destroyed immediately [src/plugins/bittorrent/tabwidget.cpp:715]: (error) instance of Applier object destroyed immediately [src/plugins/eiskaltdcpp/dcpp/PerFolderLimit.cpp:92]: (error) Possible null pointer dereference: message - otherwise it is redundant to check if message is null at line 84 ... I stopped it that this point but there might be more issues. -- 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/caktje6gp72t93qe8cdc0a2lagvkldjwdo2imv9zrkavcozp...@mail.gmail.com
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, Boris Pek tehnic...@yandex.ru writes: I am looking for a sponsor for my package leechcraft. I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? Regards, Ansgar -- 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/s2sty6evjcj@bistromathics.mathi.uni-heidelberg.de
[RFH] libxmlezout : out of date on many archs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have uploaded one of the packages I maintain and in the PTS [1] I have many out of date on i386 and so on messages. It seems that was the reason why the previous version (1.01.1-4) didn't reach testing. Since I don't understand this problem, I don't know how can I solve it. Any help, advices, url welcome, Thanks in advance, xavier [1] http://packages.qa.debian.org/libx/libxmlezout.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65OA8ACgkQVIZi0A5BZF5qswCeKfGVDaZtGRmr6gp8VXsoA/ZJ 7A8AnikqPjsXRO/gabVBRW4dr8g0XM71 =70Th -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/4eb93810.7000...@ipno.in2p3.fr
Re: [RFH] libxmlezout : out of date on many archs
Hi! Am 08.11.2011 15:09, schrieb Xavier Grave: I have uploaded one of the packages I maintain and in the PTS [1] I have many out of date on i386 and so on messages. It seems that was the reason why the previous version (1.01.1-4) didn't reach testing. Since I don't understand this problem, I don't know how can I solve it. Any help, advices, url welcome, Thanks in advance, xavier [1] http://packages.qa.debian.org/libx/libxmlezout.html Ha, that's a tricky one. First guess would have been: Not yet build on all archs, however looking at [1] (also linked from the qa site) show's all archs (but hurd) are build successfully and in the archive. So look again at the qa page: It says out of date on i386: libxmlezout0, libxmlezout1-dev (from 1.06-2). It seems you recently droped these two packages. They are still in wheezy and used there, so your package can't migrate without the old packages being removed. That's job of the ftp-team, and usually you don't have to care about that, as the ftp-team get's notified about this cruft, and tries to remove it. See [2] for the current Cruft report which also mentiones your package. As said: Normally the ftp-team does that for you, and you don't have to do anything special. However, in this case the ftp-team could do anything about it. When trying to remove your old package, one sees the following (AFAIK you could try that out on ries.debian.org, if you are an DD, if not apt-cache rdepends might help you): Checking reverse dependencies... # Broken Depends: liblog4ada: liblog4ada1-dev narval: libnarval-dbg [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1-dev [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1.10.1 [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-generic-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-servers [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-tests-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] # Broken Build-Depends: liblog4ada: libxmlezout1-dev narval: libxmlezout1-dev So, your package can't be removed, because that would break other packages. Brolen Depends can usually be solved by requesting binary NMUs (binNMUs). AFAIK that's easiest done with bug against the release.debian.org apckage. Broken Build-Depends usually means that you have to tell the maintainers of these packages to fix their packages. Once they are uploaded, the old package may be removed, and may migrate to testing. Also note that you don't have to request binNMUs, if the package needs a sourceful upload anyway. 1: https://buildd.debian.org/status/package.php?p=libxmlezout 2: http://ftp-master.debian.org/cruft-report-daily.txt Best regards, Alexander -- 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/4eb9437a.1050...@debian.org
Re: leechcraft (closes ITP bug, 33 days have passed)
While I think this package is interesting, I do not intend to sponsor it. Thanks a lot for such detailed review! And for possibility to practice in English. =) That said, here is a review of the source package: I'm not sure it is appropriate to change the ABI names used by upstream to a Debian-specific one. If you want to change the library names that should be done upstream. Please talk to upstream about how to make your patches unnecessary. I have talked a lot with main upstream developer. It was our common conclusion that I will maintain such patches special for Debian and Ubuntu. Please add DEP-3 headers to your patches: http://dep.debian.net/deps/dep3/ Is it really necessary? I can make it if yes. But these patches are trivial... And they are under the same copyright as debian/ directory. qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... * qxmpp package already exist in Debian. But it is absolutely not suitable for leechcraft. Leechcraft authors have made a lot of patches which are not included in upstream of qxmpp project. Some patches they (upstream) applied but not all. More over qxmpp is the static library. And nobody uses patched version of qxmpp except leechcraft project. So it should not be moved into separate package. * eiskaltdcpp package already exist in Debian. But it is another project with own binaries. Its authors have made special modification for leechcraft project (it also includes a lot of patches). And this modification is now just usual leechcraft plugin. It can't be used separately. So them should not be splitted. * etc... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. Some of the icons were created in Inkscape but the source code (SVG files) is missing. I haven't sighted it. What files are you talking about? I'll ask in upstream. There are some pre-compressed audio files, I guess the preferred form for modification for those is missing and therefore we cannot distribute them since they are probably GPL licensed. In addition there is DFSG item 2. What files are you talking about? And what's the problem with pre-compressed audio files? I am not sure that understood you correctly. Your version number and your debian/rules get-orig-source do not indicate the reason for the tarball repacking. But it is described in debian/copyright: https://github.com/tehnick/leechcraft-debian/blob/master/debian/copyright#L6 Non-free content and unnecessary files were removed from tarball. And yes, I have read Best Packaging Practices section in the Debian Developer's Reference. But these unnecessary files are not using anywhere and staying in repository due to historical or other reasons. I can described reasons for each deleted file or directory if you want. So it was our common decision with upstream developers to remove them from tarball in Debian. You can use wildcards in .install files like these: usr/share/leechcraft/translations/*/LC_MESSAGES/libeiskaltdcpp.mo usr/share/leechcraft/translations/leechcraft_poshuku_*.qm Hmm, I use wildcards. Maybe I have missed it somewhere. Some of the files have the incorrect FSF address in them, you might want to report that upstream. I had already sent suitable patches to upstream and they were applied in upstream git repository. So next stable release will be clean from this point. But this can't cause to not upload the package in Debian. So we don't need to wait next release. P: leechcraft source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5/ I use last actual version of this document. There are some .DS_Store files in the tarball, these are a waste of space, you might want to ask upstream to remove them. Already done some time ago. And files already removed from the git repository. So next stable release will be clean from this point. But this also can't cause to not upload the package in Debian. So we don't need to wait next release... cppcheck finds some issues: qxmpp/src/QXmppTransferManager.cpp:423]: (error) Memory leak: buffer [src/plugins/azoth/plugins/metacontacts/managecontactsdialog.cpp:50]: (error) Possible null pointer dereference: entry - otherwise it is redundant to check if entry is null at line 53 [src/plugins/bittorrent/tabwidget.cpp:705]: (error) instance of Applier object destroyed immediately [src/plugins/bittorrent/tabwidget.cpp:715]: (error) instance of Applier object destroyed immediately [src/plugins/eiskaltdcpp/dcpp/PerFolderLimit.cpp:92]: (error) Possible null pointer dereference:
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. Also not of all plugins are enabled now. So it will be more packages... You can compare it with KDE infrastructure: kdelibs + lot of programs. Best regards, Boris. -- 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/421711320765...@web144.yandex.ru
Re: [RFH] libxmlezout : out of date on many archs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 08/11/2011 15:58, Alexander Reichle-Schmehl a écrit : Hi! snip Ha, that's a tricky one. Fixing it with your help will make me learn more about Debian internals, thanks ! First guess would have been: Not yet build on all archs, however looking at [1] (also linked from the qa site) show's all archs (but hurd) are build successfully and in the archive. So look again at the qa page: It says out of date on i386: libxmlezout0, libxmlezout1-dev (from 1.06-2). It seems you recently droped these two packages. They are still in wheezy and used there, so your package can't migrate without the old packages being removed. That's job of the ftp-team, and usually you don't have to care about that, as the ftp-team get's notified about this cruft, and tries to remove it. See [2] for the current Cruft report which also mentiones your package. As said: Normally the ftp-team does that for you, and you don't have to do anything special. However, in this case the ftp-team could do anything about it. When trying to remove your old package, one sees the following (AFAIK you could try that out on ries.debian.org, if you are an DD, if not apt-cache rdepends might help you): I'm not DD but DM. Checking reverse dependencies... # Broken Depends: liblog4ada: liblog4ada1-dev narval: libnarval-dbg [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1-dev [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1.10.1 [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-generic-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-servers [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-tests-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] # Broken Build-Depends: liblog4ada: libxmlezout1-dev narval: libxmlezout1-dev So, your package can't be removed, because that would break other packages. Brolen Depends can usually be solved by requesting binary NMUs (binNMUs). AFAIK that's easiest done with bug against the release.debian.org apckage. Broken Build-Depends usually means that you have to tell the maintainers of these packages to fix their packages. Once they are uploaded, the old package may be removed, and may migrate to testing. Also note that you don't have to request binNMUs, if the package needs a sourceful upload anyway. liblog4ada is a package of mine, so if I upload it also, it should solve part of the problem ? (I will have to fix narval, polyorb, also) Thanks a lot for all your explanations, I'll go try fix this problem. xavier 1: https://buildd.debian.org/status/package.php?p=libxmlezout 2: http://ftp-master.debian.org/cruft-report-daily.txt Best regards, Alexander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65Sa8ACgkQVIZi0A5BZF52egCfXOmVtPUaYr0j9+lxrxZrAz0h fQIAn2W5BatLTNWZdZ90YfmxPubLvhX4 =OIYn -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/4eb949af.3060...@ipno.in2p3.fr
Re: RFS: flex-sdk-4.5
On Sun, Nov 6, 2011 at 07:19, Damien Raude-Morvan draz...@debian.orgwrote: Le dimanche 06 novembre 2011 16:02:55, Joey Parrish a écrit : Hi Joey, I haven't heard back in a while. Anything wrong with my package or repo that's holding up an upload? Your repository doesn't show up on [1], did you setup post-update hook ? --- mv hooks/post-update.sample hooks/post-update chmod +x hooks/post-update --- [1] http://anonscm.debian.org/gitweb/ No, I don't believe I did that. I'll try to take care of that. Thanks, --Joey
Re: [RFH] libxmlezout : out of date on many archs
Hi! Am 08.11.2011 16:24, schrieb Xavier Grave: Checking reverse dependencies... # Broken Depends: liblog4ada: liblog4ada1-dev narval: libnarval-dbg [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1-dev [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] libnarval1.10.1 [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-generic-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-servers [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] narval-tests-actors [amd64 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc s390 sparc] # Broken Build-Depends: liblog4ada: libxmlezout1-dev narval: libxmlezout1-dev [..] liblog4ada is a package of mine, so if I upload it also, it should solve part of the problem ? (I will have to fix narval, polyorb, also) Yes, you have to upload liblog4ada. As it build depends on libxmlezout1-dev, which you droped in one of your last uploads, there's no way libxmlezout can migrate to testing without breaking the existing liblog4ad in testing. Same with narval. Best regards, Alexander -- 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/4eb950bf.7010...@debian.org
Re: RFS: flex-sdk-4.5
On Mon, Nov 7, 2011 at 08:02, Jaldhar H. Vyas jald...@debian.org wrote: On Sun, 6 Nov 2011, Joey Parrish wrote: Jaldhar, I haven't heard back in a while. Anything wrong with my package or repo that's holding up an upload? Sorry, real life got in the way. A couple of things I noticed. 1. I think I mentioned this before; we should concentrate on 4.5. I don't see any purpose in having multiple versions of the flex sdk in Debian do you? No, but my last company used Flex quite a lot, and every new version seemed to introduce incompatibilities. Software written for 4.1 won't necessarily work without modification on 4.5. So I thought it would make sense to be prepared to provide multiple versions if/when the need arises. For now, I would release the 4.5 package and wait to see if any packages that build-depend on flex-sdk fail to build with 4.5, in which case they can instead build-depend on a specific version that we will have ready in advance. It's also possible that after 4.5, Adobe will release 4.6 or 5.0, in which case I didn't want to be locked into the package name flex-sdk now, just to have to split into 4.5 and 5.0 packages later. So multiple versions is mainly about avoid the assumption that 4.5 is good for everybody, either now or in the future. If backward compatibility were maintained by Adobe, this would be a non-issue, of course. 2. Debian has a utility called git-buildpackage which is a wrapper around dpkg-buildpackage and, as the name suggests, allows building a .deb directly from a git repository. It is not required but it would be nice if flex-sdk could work with it. In order to do so, the debianized source needs to be in the master branch and the upstream source in a branch called upstream. (Actually you can change these but those are the defaults.) Another called pristine-tar allows keeping the upstream tarball within the git repository. I'll go ahead and set this up for you if you like. Yes, please. I could definitely use help, and I can learn more about debian from your mods. 3. Rather than lug around all the bits of the upstream source which will never be used in Debian such as .exe and .a files, they should be removed from the .orig.tar.gz (And eventually all other non DFSG-compliant bit too but that will be a work in progress.) Ordinarily we like to keep it as close to what upstream is shipping as possible but this is one of the exceptions to that rule. These changes should be documented in a file called debian/README.source and I suppose in the get-orig-source target of debian/rules. I don't have the code in front of me right now, but I believe I removed all the .exe and .bat files in debian/rules. I understand why you'd remove them in the .tar.gz, but I thought that for simplicity's sake, removing everything from the .tar.gz would wait until we were building from source. Adobe keeps those in their svn repo, unfortunately. The .a files may be necessary, because the SDK is able to produce AIR binaries for mobile devices. Ideally, those would also be built from source, but in the mean time, they should not be deleted from the package, IMO. Thanks, --Joey
Re: Buildings fails due to missing link against gzclose
Info: the problem vanished when I've builded with other builders than pbuilder. Greetings, Daniel Stender On 06.11.2011 22:35, Andrey Rahmatullin wrote: On Sun, Nov 06, 2011 at 05:34:41PM +0100, Daniel Stender wrote: we are trying to build the Gummi (LaTeX editor with preview pane) 0.6 beta with Pdebuilder (Sid) on Ubuntu Oneiric, but the building fails due to a missing link against 'gzclose' (Zlib) - please see the build log: http://paste.debian.net/143237/ That's because -lz was not specified in the link command. I've contacted the developers, and they added the reference to the upstream: http://dev.midnightcoding.org/redmine/projects/gummi/repository/diff?rev=1032rev_to=1031 but it still fails to build and we're stuck a little here. I don't see how can this patch help as -lz still is not used in the link command. $(zlib_LIBS) needs to be added to gummi_LDADD in src/Makefile.am. -- 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/4eb9576e.6020...@danielstender.com
RFS: yubiserver (new package in Debian, 2nd try)
Dear mentors, I am looking for a sponsor for my package yubiserver. * Package name: yubiserver Version : 0.1-1 Upstream Author : [Nanakos Chrysostomos nana...@wired-net.gr] * URL : [http://www.include.gr/debian/yubiserver/yubiserver-0.1.tar.gz] * License : [GPL-2+] Section : admin It builds those binary packages: yubiserver - Yubikey OTP and HOTP/OAUTH Validation Server To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yubiserver Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yubiserver/yubiserver_0.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Nanakos Chrysostomos -- 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/2008164133.ga6...@dinofilaria.home
RFS: mpg321 (3rd try)
Dear mentors, I am looking for a sponsor for my package mpg321. * Package name: mpg321 Version : 0.3.0-1 Upstream Author : Nanakos Chrysostomos nana...@wired-net.gr * URL : http://mpg321.sourceforge.net * License : GPL-2+ Section : sound It builds those binary packages: mpg321 - Simple and lightweight command line MP3 player To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mpg321 The new changelog entries are: * Fixed trailing / when printint directory. Bug reported from Erik (Gentoo). * Fixed mistake for '--cdr' option. It should be 'cdr file' than 'wave file' in output. * mpg321 now supports multiprocessing buffering.Check '-b' option. (Closes: Bug#113405). * Added '-3' or '--restart' option in man file. * Added ALSA volume control when using output buffer. * Added Mute/unmute into Basic Keys functionality. Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mpg321/mpg321_0.3.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Nanakos Chrysostomos -- 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/2008165416.gb6...@dinofilaria.home
Re: Uploaded package is not showing up in mentors
Hello Arno, On 22:18 Mon 07 Nov , Arno Töll wrote: Hello Vasudev, On 05.11.2011 15:09, Vasudev Kamath wrote: Sure I've uploaded all the files at this URL[1] snipped [1] http://silpa.org.in/~vasudev/dwm/ You are missing dwm_5.9.orig.tar.gz there. If you forgot it for mentors too, that would explain your problem (however, you should have gotten a reject mail then). As I mentioned I've uploaded orig.tar ball to above URL. I tried uploading the package again today but no luck it won't showup on the mentors web inteface. Best Regards -- Vasudev Kamath http://blog.copyninja.info vasu...@joindiaspora.com (Ostatus) signature.asc Description: Digital signature
Re: Uploaded package is not showing up in mentors
Quoting Vasudev Kamath kamathvasu...@gmail.com: As I mentioned I've uploaded orig.tar ball to above URL. I tried uploading the package again today but no luck it won't showup on the mentors web inteface. According to one of the mentors, there has a glitch in the upload script for the last day or so. I wasn't able to upload either, but my most recent attempt was successful. Maybe you should simply try one last time, now that the upload script appears to have been fixed. -- OLE WOLF[1] Rødhættevej 4 * 9400 Nørresundby Telefon: 9632-0108 * Mobil: 2467-5526 * Skype: ole.wolf * SIP: ole.w...@ekiga.net Links: -- [1] http://naturloven.dk smime.p7s Description: S/MIME Cryptographic Signature
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, Boris Pek tehnic...@yandex.ru writes: I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Regards, Ansgar [1] https://launchpadlibrarian.net/84683703/buildlog_ubuntu-precise-i386.leechcraft-unstable_0.4.90-670-g4cccdc3-0ppa1~precise1_BUILDING.txt.gz -- 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/87lirqldfd@deep-thought.43-1.org
Re: Need assistance in packaging / Brauche Hilfe bei der Erstellung von Paketen
Siegfried-Angel Gevatter Pujals (RainCT) wrote... Hi Björn, Maybe someone else can give you more details, but in the meantime here are some useful links (which should have more than enough information to get you started if you're already familiar with packaging): 2011/11/7 Björn Esser bjoern.es...@googlemail.com: how to write/create man-pages See https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles#Man_Pages. nroff is rather complex and error-prone. Therefore I suggest using POD to write manpages although this is frowned upon, hence there's no dh_installpod, hence debian/rules becomes ugly if you want acceptable manpages from POD. And this document recommends the usage of cdbs, something I wouldn't do anymore. one source in multiple packages (e.g. somewhat (arch), somewhat-doc(no-arch), somewhat-data (no-arch), etc.), removing obsolete/not used files from the package I've found http://wiki.debian.org/PkgSplit, but that page lets it look much more scary than it actually is. To me it looks really scary. Nowaday when debian/rules can be as terse as #!/usr/bin/make -f %: dh $@ I'd only recommend instructions that are based on that debhelper 7 mechanism. Everything else should be seen as legacy, nothing to show to beginners. By the way, I'm looking for a straightforward way using debhelper7 to do upstream's triple-jump (./configure ; make ; make install) to create a set of binary packages from a single source package. Only the configure options are different, and of course I'll have to override dh_auto_configure. At the moment, overrides for dh_auto_configure, dh_auto_build, dh_auto_test, and dh_auto_clean are required, too. With an unpleasant result. Christoph -- 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/1320775...@msgid.manchmal.in-ulm.de
Re: leechcraft (closes ITP bug, 33 days have passed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Boris, On 08.11.2011 15:58, Boris Pek wrote: qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... ... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. I'm sorry, but our policy is very clear on this point. Please refer to §4.13 [1] for some more background. While it is not a strict must requirement for every case, there are very good reasons to avoid embedded code copies whenever possible. I'd consider your case as when possible which makes it somewhat unlikely to find a sponsor for it as is, which would upload your package. Note, some popular packages aren't part of Debian for this very same reason. Think of xbmc for example [2]. We, as a distribution have to be very careful when embedding libraries and third party applications into a package. You can happily do that upstream if the respective licenses allow that, but such a package is not maintainable in a distribution for the general public. Think of security updates, transitions and other updates and we didn't even talk about the waste of space yet. That's especially true for you, who are embedding regular packages into your binary package which works fine for ... well a lot of reverse dependencies. If it does not work for you as is with your upstream source, well, I'd expect the problem to be with it rather on your side. [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469397 - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOuXxEAAoJEMcrUe6dgPNtQX4QAIWAtali7SBRti9j/8r/g8eA kygbHuYMNBCpkfq6VtJJUNITygWgCn/Fj0+bKM7phOWkcoK6xTkbGJB9k2OZYTkz wnkTci7EehJj+DTOgS3oyNDtzGI/9wV5gSuV7SoeXk5UK6wkk+Wu1U4YwYDbfdvJ kkcdKDhAZOxihjqii82Lq4HsosLyUytvosJV8khtvzttZ6YC3skju2QjRZzVLvuE 0BakI+CuG3NZivRRKdeeQ1cRxCTYWoVWS0fo47i1X1sRscHslhxfr8kwICJB03Yk 3ZtKtYetlGFoZydK8NOuZcW+PXs3MrEaRiX2P4Z9OVzS0BOmA2m0MMJa4s8a4cD+ W/bTFyGFwQDjLs/wDSmUnSizC+Q+6uQ4YzQR7FxfAc3CCnQ1RFlvoGJH5krAMdi7 v8x85YavjqeE013XB/RpE1KXcMfDrI0YAqiaf2vp2uXoweDKv09hDFbWcnfwQTS4 eOfW1xONuQpy32o+KeB47JF/sXhEbST+gL1iYxIVJ86UKjILT3gQIjocRCMmKRLY 9gXsI+6AOgWG9FiFBHI57XQ6SUO/DXi6Je9UhyP/M09QcckZdfXmsVXjjZP9sdWd TGkhD7n5C60Hl3iJBLx8xFBHdcmr9nGw2FOZygMtJqpb3wV3xlTwD/XEE/KvS+Qp m+bLeXfKDPvd3b4+kSKI =2WZU -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/4eb97c44.8060...@toell.net
Re: RFS: python-cpl
* Ole Streicher debian-de...@liska.ath.cx, 2011-11-03, 21:07:
http://mentors.debian.net/package/python-cpl
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/p/python-cpl/python-cpl_0.3.5-1.dsc
I don't intend to sponsor this package, but here's my cursory review:
- Please honour DEB_BUILD_OPTIONS=nocheck.
- If possible, please run tests with all supported Python versions.
- Why priority extra?
- Don't use ${python:Provides} unless you have to AND you know what you
are doing. Rationale:
http://lists.debian.org/20110324164804.ga5...@jwilk.net
--
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/2008204534.ga1...@jwilk.net
Re: leechcraft (closes ITP bug, 33 days have passed)
[...] You can use wildcards in .install files like these: [...] usr/share/leechcraft/translations/leechcraft_poshuku_*.qm [...] I have just found again the reason to not use it. Available wildcards are very primitive. And they will affect to sub-plugins. For example: usr/share/leechcraft/translations/leechcraft_poshuku_*.qm will also affect to sub-plugins: usr/share/leechcraft/translations/leechcraft_poshuku_ru.qm and usr/share/leechcraft/translations/leechcraft_poshuku_cleanweb_ru.qm which should be in different packages... Regards, Boris. -- 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/366251320785...@web126.yandex.ru
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, I probably won't sponsor the package, but I was wondering if it is really necessary to build 53 binary packages (if I did not miscount)? The short answer: yes, it is. Here I can cite the description from my first message: LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. I made separate packages for each plugin. So user will be able to install only those packages which he really need. This is the main idea of the project... LeechCraft is very flexible. This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). Hmm, I have not thought about such an effect. It's bad news. I will think that can I do to decrease number of packages. This will damage general idea unfortunately but it is really more important. For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Yes, this is true. But its sub-plugins realise different communicating protocols. Of cause they can be disabled in settings dialog, users will not be able to remove unnecessary plugins completely. Also I will look to other similar software. Like kopete, pidgin, etc... [1] https://launchpadlibrarian.net/84683703/buildlog_ubuntu-precise-i386.leechcraft-unstable_0.4.90-670-g4cccdc3-0ppa1~precise1_BUILDING.txt.gz My PPA is really useful. It is nice. Regards, Boris. -- 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/46651320787...@web113.yandex.ru
Re: leechcraft (closes ITP bug, 33 days have passed)
Hi, qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox, hunspell/myspell (and anything else in 3rdparty or third-party dirs) are either already in Debian or should be packaged separately, you should not include them in the binary package or tarball. You are really mistaken at this point. Maybe you have read my description inattentive or I have write it not enough clean. So I should explain here... * qxmpp package already exist in Debian. But it is absolutely not suitable for leechcraft. Leechcraft authors have made a lot of patches which are not included in upstream of qxmpp project. Some patches they (upstream) applied but not all. More over qxmpp is the static library. And nobody uses patched version of qxmpp except leechcraft project. So it should not be moved into separate package. * eiskaltdcpp package already exist in Debian. But it is another project with own binaries. Its authors have made special modification for leechcraft project (it also includes a lot of patches). And this modification is now just usual leechcraft plugin. It can't be used separately. So them should not be splitted. * etc... All these files were carefully described in suitable sections of debian/copyright file. And I don't see any reason to break current structure of the package. I'm sorry, but our policy is very clear on this point. Please refer to §4.13 [1] for some more background. While it is not a strict must requirement for every case, there are very good reasons to avoid embedded code copies whenever possible. I'd consider your case as when possible which makes it somewhat unlikely to find a sponsor for it as is, which would upload your package. Please read my answers carefully before replying. I have a strong feeling that you just ignore my arguments. And that you want to throw my work into trash. Maybe you don't understand that these files are part of the project. They can't be cut from the project without destruction. Like a brick can't be moved from a wall without detrimental consequences. I can repeat my arguments in other words to make sure in common understanding between us. * qxmpp is a fork as you wish. It is the internal part of the project. Even if it is not included in original upstream tarball. * eiskaltdcpp is internal part of the project. It was produced specially for leechcraft by original authors. * miniupnpc is not used. It just present in tarball. Its license can't be cause of any problems. Plugin will use debian package miniupnpc from the main repo. Note, some popular packages aren't part of Debian for this very same reason. Think of xbmc for example [2]. Yes I know other examples. It doesn't matter. We, as a distribution have to be very careful when embedding libraries and third party applications into a package. You can happily do that upstream if the respective licenses allow that, but such a package is not maintainable in a distribution for the general public. Think of security updates, transitions and other updates and we didn't even talk about the waste of space yet. Please don't think that I am stupid or that I don't know basic principles of distribution of *nix systems. 1) You must agree that we are not talking about any system library. 2) We are talking about _internal_ library in the project. It is used only in this program and nowhere else. So where is no necessary to maintain it separately. 3) This library is not simple duplication of original sources from another library. This is completely another library now. 4) This is completely static library. It can't be updated in programs without their re-building. 5) Also we are talking about _internal_ plugin in the project. It can't be used in other way. Only in this program. And the last argument is that [1] is not strict rules but just recommendations which allow exceptions. That's especially true for you, who are embedding regular packages into your binary package which works fine for ... well a lot of reverse dependencies. If it does not work for you as is with your upstream source, well, I'd expect the problem to be with it rather on your side. Eh... You have absolutely ignored my description. This is not project fault that qxmpp upstream don't want integrate all their patches. They had to made a fork. In conclusion I want note that you shouldn't destroy anything without proposing possible solutions. Because this is way to nowhere. So have you any constructive recommendations which can be discussed?.. Finally please answer to my previous questions (from previous messages). It is important. In any case thanks for spending your time. Regards, Boris [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469397 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: RFS: yubiserver (new package in Debian, 2nd try)
On Tue, Nov 08, 2011 at 06:41:33PM +0200, Nanakos Chrysostomos wrote: dget -x http://mentors.debian.net/debian/pool/main/y/yubiserver/yubiserver_0.1-1.dsc It doesn't build with pbuilder. Please see below. [...] dh_testdir # Add here commands to configure the package. ./configure --prefix=/ --bindir=/usr/bin --sbindir=/usr/sbin --mandir=/usr/share/man --with-default-sqlite3-db-file=/etc/yubiserver/yubiserver.sqlite --with-default-yubiserver-log-file=/var/log/yubiserver.log configure: error: cannot find install-sh, install.sh, or shtool in build-aux ./build-aux make: *** [configure-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package signature.asc Description: Digital signature
Re: How to maintain a large symbols file of a C++ library
On Tue, Nov 08, 2011 at 12:21:16PM +0100, roucaries bastien wrote: On Tue, Nov 8, 2011 at 12:18 AM, Thomas Weber twe...@debian.org wrote: Hi, I'm in the process of converting Debian's Octave packages into a structure with proper library packaging. The symbols file of these three C++ libraries has about 30k lines. I'm pretty new to symbols handling, so I'm looking for advice on how to handle this. Is there a simple way to reduce the pure size of this file? Or is this size normal? Further, looking at dpkg-gensymbols(1), it seems I should take special care about some C++-features - can you point me to an example of how to do this? Thanks Thomas Try to use hidden linking before doing this. Ask upstream hel, if needed. Do you mean GCC's -fvisibility=hidden? If yes, I'm at a loss at how to do this in a sensible way - if the symbols were exported before, changing this in Debian might break other software that actually uses these symbols. BTW do you need help on arpack ? Opps, thanks for pointing me at this. I had totally forgotten about arpack being bundled. Thomas -- 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/2008224756.GA1123@t61
Re: leechcraft (closes ITP bug, 33 days have passed)
On Tue, 08 Nov 2011 23:23:06 +0200 Boris Pek tehnic...@yandex.ru wrote: This seems to be a bit excessive. There is no real use in having many tiny packages for every function; please keep in mind that this will make the Packages index even larger (which also affects users that do not even have the package installed). Hmm, I have not thought about such an effect. It's bad news. I will think that can I do to decrease number of packages. This will damage general idea unfortunately but it is really more important. For example, I think many of the leechcraft-azoth-* packages could be merged into a single package: they do not seem to be very large nor introduce large dependencies according to an build log I found on launchpad[1]. Yes, this is true. But its sub-plugins realise different communicating protocols. Of cause they can be disabled in settings dialog, users will not be able to remove unnecessary plugins completely. Also I will look to other similar software. Like kopete, pidgin, etc... gstreamer is also distributed with many plugins per package. I think that approach has more advantages than disadvantages compared to one package per plugin. For users that want to use most of the plugins, having them in individual packages will waste more disc space in package overheads than they'll save by only having the plugins they need. And installing/upgrading many small packages takes longer than one large one. -- 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/2009010101.38ab6cfa@tiber
Re: RFS: flex-sdk-4.5
On Tue, 8 Nov 2011, Joey Parrish wrote: No, but my last company used Flex quite a lot, and every new version seemed to introduce incompatibilities. Software written for 4.1 won't necessarily work without modification on 4.5. So I thought it would make sense to be prepared to provide multiple versions if/when the need arises. For now, I would release the 4.5 package and wait to see if any packages that build-depend on flex-sdk fail to build with 4.5, in which case they can instead build-depend on a specific version that we will have ready in advance. Well, the only data point I have is yui which works fine with 4.5. I don't know of any other packages in Debian which need flex-sdk yet. So I would wait to cross that bridge when we get to it. Also when it does become necessary, the easier way will be to use git branches rather than have seperate sets of files. It's also possible that after 4.5, Adobe will release 4.6 or 5.0, in which case I didn't want to be locked into the package name flex-sdk now, just to have to split into 4.5 and 5.0 packages later. So multiple versions is mainly about avoid the assumption that 4.5 is good for everybody, either now or in the future. If backward compatibility were maintained by Adobe, this would be a non-issue, of course. Oh the package should continue to be called flex-sdk-4.5 absolutely. I don't have the code in front of me right now, but I believe I removed all the .exe and .bat files in debian/rules. I understand why you'd remove them in the .tar.gz, but I thought that for simplicity's sake, removing everything from the .tar.gz would wait until we were building from source. Adobe keeps those in their svn repo, unfortunately. The .a files may be necessary, because the SDK is able to produce AIR binaries for mobile devices. Ideally, those would also be built from source, but in the mean time, they should not be deleted from the package, IMO. The bottom line is if the package contains files for which there is no source code it cannot be included in Debian main. Perhaps the .a files can be split into a seperate (source) package called flex-sdk-nonfree or something. -- Jaldhar H. Vyas jald...@debian.org La Salle Debain - http://www.braincells.com/debian/
Re: Buildings fails due to missing link against gzclose
On Tue, Nov 08, 2011 at 05:23:10PM +0100, Daniel Stender wrote: Info: the problem vanished when I've builded with other builders than pbuilder. pbuilder was created to be able to build in a controlled environment. No wonder that some errors are not present in uncontrolled environments, but that doesn't mean they do not exist at all. gummi-0.5.999-svn1032.tar.gz cannot be built on my sid system even without pbuilder. Greetings, Daniel Stender On 06.11.2011 22:35, Andrey Rahmatullin wrote: On Sun, Nov 06, 2011 at 05:34:41PM +0100, Daniel Stender wrote: we are trying to build the Gummi (LaTeX editor with preview pane) 0.6 beta with Pdebuilder (Sid) on Ubuntu Oneiric, but the building fails due to a missing link against 'gzclose' (Zlib) - please see the build log: http://paste.debian.net/143237/ That's because -lz was not specified in the link command. I've contacted the developers, and they added the reference to the upstream: http://dev.midnightcoding.org/redmine/projects/gummi/repository/diff?rev=1032rev_to=1031 but it still fails to build and we're stuck a little here. I don't see how can this patch help as -lz still is not used in the link command. $(zlib_LIBS) needs to be added to gummi_LDADD in src/Makefile.am. -- WBR, wRAR signature.asc Description: Digital signature
