Re: RFS: hashalot (updated)
Adam Borowski scrisse: As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I've seen that you've already found Kapil available, fine :). Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. It also seems to contain a heavy autotool-ization. Looking at the diff and at your email, is that all ok? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgp9Ck6a1RZeC.pgp Description: PGP signature
Re: RFS: hashalot (updated)
On Thursday 24 January 2008 04:40, Kapil Hari Paranjape wrote: * Vcs-Svn and Vcs-Browser. Shouldn't the Vcs-Svn entry start with svn: instead of http:? SVN can be run over a variety of protocols, next to svn including ssh and http(s). Which is an excellent feature if you ask me :-) Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Adam Borowski scrisse: As the diff is small (except for file deletions), this shouldn't take much of your time. If someone could upload this, that would be cool. I've seen that you've already found Kapil available, fine :). Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. It also seems to contain a heavy autotool-ization. A diff from the previous packages, I mean. I wasn't clear enough, sorry. As in debdiff hashalot_0.3-4.dsc hashalot_0.3-5.dsc. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex: long term / current release 0.2.8-3
* Andreas Hoenen [EMAIL PROTECTED] [080123 22:19]: causes patch-stamp to be executed as first action before the build-stamp commands get executed. Symmetrical to this the construct clean: clean1 unpatch clean1: causes unpatch to be executed as last action after all clean1 commands. AFAIK that might happen, but only by coincidence (i.e. specific implementation of make and no -j arguments). To make sure unpatch is called after clean1, make unpatch depend on clean1. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: Hello, Some quick comments. On Thu, 24 Jan 2008, Adam Borowski wrote: * Buffer overflow on RMD160: It will cause only a crash instead of executing arbitrary code, and considering the typical usage this is nearly always harmless. Yet, in non-typical uses even wrong output can be pretty bad for a hash. A nearly-identical fix is already in Ubuntu (they move some functions around without an apparent reason). Has this patch been submitted upstream? Yes, albeit only a week ago. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:10:11AM +0530, Kapil Hari Paranjape wrote: Has this patch been submitted upstream? Yes, albeit only a week ago. Is upstream still working on this package? The last upload seems to have been in 2004! On Thu, 24 Jan 2008, Luca Bruno wrote: I've seen that you've already found Kapil available, fine :). Luca Bruno: please consider sponsoring if you like. On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. It is indeed true that diff -ur hashalot-0.3-[45] | wc -c returns just about 5K. And these are the changes documented in the changelog. At a cursory glance it looks like this package may continue to need such large patches it it continues to be un-maintained upstream (if only for re-autotool-ing!). Is Adam willing to take up the task of being de-facto long-term maintainer of the package in this case? Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Thu, Jan 24, 2008 at 04:44:48PM +0530, Kapil Hari Paranjape wrote: On Thu, 24 Jan 2008, Adam Borowski wrote: On Thu, Jan 24, 2008 at 09:25:05AM +0100, Luca Bruno wrote: Anyway your gzipped diff is 70K (almost as big as the original tarball), which seems to clash with your previous statement. Matthias Urlich enabled AM_MAINTAINER_MODE some time ago -- this stops _new_ unrequested autotoolization changes, but is a reautotooling by itself. It is indeed true that diff -ur hashalot-0.3-[45] | wc -c returns just about 5K. And these are the changes documented in the changelog. Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? At a cursory glance it looks like this package may continue to need such large patches it it continues to be un-maintained upstream (if only for re-autotool-ing!). Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Autotoolage changes appear to be huge, but they're all auto-generated files. Is Adam willing to take up the task of being de-facto long-term maintainer of the package in this case? In long-term, the package will most likely be absorbed into cryptsetup, where already most of functionality has gone to. Unless somehow it is needed for something else (there appears to be no other hasher for RMD160 around), it will probably go away completely. It's mostly there to avoid breaking people's setups. Regards. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: gnash (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.8.1+cvs20080124.0900-1 of my package gnash. It builds these binary packages: gnash - free Flash movie player gnash-common - free Flash movie player - common files/libraries gnash-cygnal - free Flash movie player - Media server gnash-tools - free Flash movie player - Command-line Tools mozilla-plugin-gnash - free Flash movie player - Plugin for Mozilla and derivatives The current package in the repositories has to be removed due to licensing problems. Gnash is GPLv3 and it links against Qt. Although newer versions of Qt are GPLv3, the one in the repositories is not ( http://packages.debian.org/changelogs/pool/main/q/qt-x11-free/qt-x11-free_3.3.7-9/libqt3-mt-dev.copyright : You may use, distribute and copy the Qt GUI Toolkit under the terms of GNU General Public License version 2). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnash - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnash/gnash_0.8.1+cvs20080124.0900-1.dsc I would be glad if someone uploaded this package for me. Greetings, Miry PS: I have added the label XS-DM-Upload-Allowed: yes to debian/control to allow Debian Maintainers uploads (that's me). If you're not comfortable with that, please ignore this sponsorship request. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnash (updated package)
On 24/01/2008, Miriam Ruiz wrote: PS: I have added the label XS-DM-Upload-Allowed: yes to debian/control to allow Debian Maintainers uploads (that's me). If you're not comfortable with that, please ignore this sponsorship request. Hi Miry. It's no longer an XS- field, see the changelog entry of dpkg/1.14.16. Cheers, -- Cyril Brulebois pgp84OzIG6uFr.pgp Description: PGP signature
Re: RFS: ladr and prover9-manual (updated package)
Peter Collingbourne wrote: Dear mentors, I am looking for a sponsor for my packages ladr and prover9-manual I'll take care of this request. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex: long term / current release 0.2.8-3
Michal Čihař [EMAIL PROTECTED] wrote: snip/ Uploaded, thanks for your effort. Next time you want to upload it, please ask directly me with [sponsoring] in subject. -- Michal Čihař | http://cihar.com | http://blog.cihar.com Thanks for your upload. I will do as you suggested. Regards, Andreas -- Andreas Hoenen [EMAIL PROTECTED] GPG: 1024D/B888D2CE A4A6 E8B5 593A E89B 496B 82F0 728D 8B7E B888 D2CE pgpSzCOO8uwnj.pgp Description: PGP signature
Ubuntu Package for Debian
Hi, There is a package in the Ubuntu distro called gfceu which is a gnome front end for the NES emulator fceu. How did I get a Ubuntu package into the Debian distro? I am not a Debian developer, so I can not upload packages directly into the Debian archive. -Matt
Re: Ubuntu Package for Debian
On Thu, Jan 24, 2008 at 03:54:34PM -0600, Matthew Williams wrote: How did I get a Ubuntu package into the Debian distro? I am not a Debian developer, so I can not upload packages directly into the Debian archive. You do the packaging using debian unstable (using a debian unstable chroot, for example). You test your package using unstable as well. When your're happy with your package, you upload it somewhere and send a RFS message to this list, so others can review your package. See: http://people.debian.org/~codehelp/ http://people.debian.org/~mpalmer/debian-mentors_FAQ.html signature.asc Description: Digital signature
Re: Ubuntu Package for Debian
You should read the Debian Policy Manual at http://www.debian.org/doc/debian-policy/ and make sure that your package at least follows the guidelines denoted by must and required. Your package should also conform to the guidelines denoted as should and recommended as not following them is generally considered a bug. If you're not using lintian, you should use it now. There's also guidelines denoted as may and optional which are generally suggestions for your packages. These suggestions are a good idea most of the time, like in the case with using the nostrip DEB_BUILD_OPTIONS to offer a way for your package to be debugged. Once you think your package is ready, start by uploading to mentors.debian.net. On Jan 24, 2008 4:54 PM, Matthew Williams [EMAIL PROTECTED] wrote: Hi, There is a package in the Ubuntu distro called gfceu which is a gnome front end for the NES emulator fceu. How did I get a Ubuntu package into the Debian distro? I am not a Debian developer, so I can not upload packages directly into the Debian archive. -Matt -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
Hello, Sorry about the delay in responding. Different time zones! On Thu, 24 Jan 2008, Adam Borowski wrote: Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? I think so. The package does not depend on anything substantial other than the C library and compiler. Updating the autotool-age should not be necessary. I notice that you have shifted the man page from section 1 (used by upstream) to section 8. Since hashalot is not just a command to be used by system administrators, I don't know why this has been done. Debian patches are small: -q for suppressing output, manpage and now the buffer overflow fix. Rather than include the manpage you should patch the upstream manpage. (Upstream seems to have included the manpage written by Matthias Ulrich at some stage but the Debian packaging hasn't taken this into account). In long-term, the package will most likely be absorbed into cryptsetup, Now that there is luks, there is some doubt about this! It's mostly there to avoid breaking people's setups. That is a very good reason indeed. Overall, it would be good if you simplified the Debian .diff.gz so that it is clear that it consists of (a) packaging (b) bug fixes to the upstream code. (Usually (b) is done by using dpatch or quilt but I won't insist on this). That way anyone wanting to utilise the code later would know exactly what parts to use. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: QA Uploads
Hi folks, Sorry for the cross-post but since these are QA uploads, I wasn't sure which list would be preferred. I have 4 packages from the Orphaned Packages with incorrect maintainer lists that I have put on mentors if someone has time to review/upload. http://mentors.debian.net/debian/pool/main/s/sn/sn_0.3.8-7.dsc http://mentors.debian.net/debian/pool/main/q/quack-el/quack-el_0.30-2.dsc http://mentors.debian.net/debian/pool/main/l/libapache2-mod-xmlrpc2/libapache2-mod-xmlrpc2_2.2.1-3.dsc Fairly intrusive but makes it build and fixes 2 important bugs. http://mentors.debian.net/debian/pool/main/k/kxgenerator/kxgenerator_0.3.7+dfsg-2.dsc Thank you, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: QA Upload - grokking-the-gimp
Hi, Here is another orphaned package from the list. http://mentors.debian.net/debian/pool/non-free/g/grokking-the-gimp/grokking-the-gimp_1.0-2.dsc Thank you, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: Another QA Upload -- amavis-stats
Hi, Here is another QA upload. Mainly setting maintainer to QA and a couple of lintian fixes. http://mentors.debian.net/debian/pool/main/a/amavis-stats/amavis-stats_0.1.12-9.dsc Thank you, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hashalot (updated)
On Fri, Jan 25, 2008 at 06:19:57AM +0530, Kapil Hari Paranjape wrote: Hello, Sorry about the delay in responding. Different time zones! Hah, it's 4am, it's me who's hitting the bed now... On Thu, 24 Jan 2008, Adam Borowski wrote: Actually, it seems that reverting to upstream autotooling doesn't break anything (except obviously being unfriendly to those who want to update autotoolage themselves). I would need to rename a file by hand in debian/rules, that's all. Should I remove those parts from the diff? I think so. The package does not depend on anything substantial other than the C library and compiler. Updating the autotool-age should not be necessary. Actually, it does check for all the headers, then... doesn't use that information at all. configure.ac should be empty except for invoking automake. Even that old automake 1.7 upstream used knows where to install things good enough. I thus reverted this part of the diff, reducing it by a factor of 20... I notice that you have shifted the man page from section 1 (used by upstream) to section 8. Since hashalot is not just a command to be used by system administrators, I don't know why this has been done. Matthias Urlichs did this because: 1. hashalot is good nearly solely for cryptsetup. A nicer interface for using the hashes could be nice but SHA256, SHA384 and SHA512 are already provided by coreutils, so anything an user would use is RMD160. Which was totally broken for anything but one-line strings until this upload and no one complained. 2. binary output can be dangerous for an unwary user Rather than include the manpage you should patch the upstream manpage. (Upstream seems to have included the manpage written by Matthias Ulrich at some stage but the Debian packaging hasn't taken this into account). Good point, fixed this. In long-term, the package will most likely be absorbed into cryptsetup, Now that there is luks, there is some doubt about this! luks doesn't need an external helper for this task. Overall, it would be good if you simplified the Debian .diff.gz so that it is clear that it consists of (a) packaging (b) bug fixes to the upstream code. (Usually (b) is done by using dpatch or quilt but I won't insist on this). Ok, I did this, then overwrote 0.3-5 on mentors. There's a watch file for uscan now as well. Bye for tonight! -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
