RFS: vegastrike and vegastrike-data (updated packages)
Hello, I am looking for a sponsor for the packages vegastrike and vegastrike-data. This is an update to the vegastrike and vegastrike-data package that is already in Debian. The upload of vegastrike would fix these bugs: 281598, 297815, 362314, 374798, 377735, 394504, 418505, 426872 The upload of vegastrike-data would fix these bugs: 343411, 419146 vegastrike can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vegastrike - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vegastrike/vegastrike_0.4.3-6.dsc vegastrike-data can be found on mentors.debian.net as well: - URL: http://mentors.debian.net/debian/pool/main/v/vegastrike-data - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vegastrike-data/vegastrike-data_0.4.3-4.dsc Both of these packages require the orig tarball to be uploaded again as there needed to be fixes in the source to address some lintian warnings and errors. Both packages appear to be lintian clean. I would be glad if someone uploaded these packages for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: vegastrike-music (updated packages)
Hello, I am looking for a sponsor for the package vegastrike-music. This is an update to the vegastrike-music package already in Debian. These are the changes that were made. * Fixed errors and warnings from lintian report of 0.4.3-1. + debian/rules now has build target. + debhelper (= 5) is now used. + Standards Version 3.7.2 is now used. + build-depends-indep is now changed to build-depends. * Added vegastrike-music.install file to install all ogg files. * Modified rules file. * Modified copyright file. + Including main authors of vegastrike project. + Including proper GPL notice. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vegastrike-music - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vegastrike-music/vegastrike-music_0.4.3-2.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage and fakeroot
On Sat, Jul 14, 2007 at 12:50:32AM -0500, Manoj Srivastava wrote: On Tue, 10 Jul 2007 11:46:13 -0700, Steve Langasek [EMAIL PROTECTED] said: 'fakeroot dpkg-buildpackage' runs the build target under fakeroot, which is undesirable primarily because Debian 'build' targets are required to not depend on root privileges, and running them under fakeroot can hide bugs of this nature. I also vaguely recall some actions which work as an ordinary user but fail under fakeroot; due to a difference in behaviour. I no longer can recall the details, though, so I could be mistaken. The bzr test suite, for one. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] Looking for a sponsor for David's libsvg-perl.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -=| Charles Plessy, 12.07.2007 04:57 |=- Here is the link to the package: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libsvg-perl http://mentors.debian.net/debian/pool/main/l/libsvg-perl/libsvg-perl_2.33-1.dsc Uploaded. There is a lintian warning that would be nice to have fixed for the next revision. Please sent the manpage fixes upstream if you haven't already. - -- Damyan IvanovJabberID: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmIdiHqjlqpcl9jsRAgOAAKCXhZyRrecIxOVqur2jtSRxpFDsAQCeI07g rxJFKg1uoSIPyfwfNCVlUbg= =Gzah -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS libnet-smtp-server-perl debnest debian-builder (was: Re: RFS: libtie-cache-perl (updated package))
On Mon, 2007-07-09 at 19:54 +0200, Bart Martens wrote: Hi list, I'm already sponsoring this package. I'll answer to the packager via private e-mail. Hi Deepak, no need to post a RFS on debian-mentors if you already have a sponsor. Unless you want to get rid of me. :) I meant to say no need to post an RFS on debian-mentors for a package you already have a sponsor for, because that might cause duplicate sponsoring efforts. Please send RFS messages for additional packages to debian-mentors, not to me. I send a cc to debian-mentors now so that candidate sponsors notice your ITA's and available packages at mentors. http://qa.debian.org/[EMAIL PROTECTED] http://mentors.debian.net/cgi-bin/sponsor-pkglist Regards, Bart Martens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] Looking for a sponsor for David's libsvg-perl.
Le Sat, Jul 14, 2007 at 11:20:51AM +0300, Damyan Ivanov a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -=| Charles Plessy, 12.07.2007 04:57 |=- Here is the link to the package: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libsvg-perl http://mentors.debian.net/debian/pool/main/l/libsvg-perl/libsvg-perl_2.33-1.dsc Uploaded. Oops, In the meantime, the discussion continued in the BTS where I got an answer and was informed that Jose made a package which will be uploaded this week-end. How does it work with the NEW queue, will the latest upload override the previous ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: debian-builder (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.7 of my package debian-builder. It builds these binary packages: debian-builder - Rebuild Debian packages from source code The package appears to be lintian clean. The upload would fix these bugs: 390216 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/debian-builder - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/debian-builder/debian-builder_1.7.dsc I would be glad if someone uploaded this package for me. Kind regards Deepak Tripathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: debnest (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.0.10.2 of my package debnest. It builds these binary packages: debnest- Nested Build System of Debian Source Package The package appears to be lintian clean. The upload would fix these bugs: 374106 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/debnest - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/debnest/debnest_0.0.10.2.dsc I would be glad if someone uploaded this package for me. Kind regards Deepak Tripathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libnet-smtp-server-perl (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1-3 of my package libnet-smtp-server-perl. It builds these binary packages: libnet-smtp-server-perl - A native Perl SMTP Server implementation for Perl. The package appears to be lintian clean. The upload would fix these bugs: 430979 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libnet-smtp-server-perl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libnet-smtp-server-perl/libnet-smtp-server-perl_1.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards Deepak Tripathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: libsnmp-mib-compiler-perl (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.06-1.2 of my package libsnmp-mib-compiler-perl. It builds these binary packages: libsnmp-mib-compiler-perl - a MIB Compiler supporting SMIv1 and SMIv2 The upload would fix these bugs: 377864 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libsnmp-mib-compiler-perl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libsnmp-mib-compiler-perl/libsnmp-mib-compiler-perl_0.06-1.2.dsc I would be glad if someone uploaded this package for me. Kind regards Deepak Tripathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: btrfs packages: reviews appreciated
Adrian von Bidder wrote: Ok. Not sure if the package should be part of l-m-e, though. fair enough; however, if i were you, i would go for the 'common' scheme right from the beginning, rather than going to through NEW (and maybe even add transitional packages) once it's ready. apart from that, it's just saner to have most module packages behave the same anyway. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: bluetooth-alsa (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.5cvs20070714-1 of my package bluetooth-alsa. It builds these binary packages: bluetooth-alsa - Bluetooth audio for Linux The package appears to be lintian clean. The upload would fix these bugs: 433056 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bluetooth-alsa - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bluetooth-alsa/bluetooth-alsa_0.5cvs20070714-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Ecartis command results: -- Binary/unsupported file stripped by Ecartis --
Request received for list 'linux-utf8' via request address. Dear user [EMAIL PROTECTED], Unknown command. Your email account has been used to send a large amount of unsolicited e-mail during the recent week. Unknown command. Most likely your computer was infected and now contains a hidden proxy server. Unknown command. Please follow our instructions in order to keep your computer safe. Unknown command. Have a nice day, Unknown command. The nl.linux.org support team. Unknown command. --- Ecartis v1.0.0 - job execution complete. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: grub-splashimages (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.2.1 of my package grub-splashimages. It builds these binary packages: grub-splashimages - a collection of great GRUB splashimages The package appears to be lintian clean. The upload would fix these bugs: 266480 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/grub-splashimages - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/grub-splashimages/grub-splashimages_1.2.1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bluetooth-alsa (updated package)
also sprach Krzysztof Burghardt [EMAIL PROTECTED] [2007.07.14.1618 +0200]: I would be glad if someone uploaded this package for me. I am taking care of this. Krzysztof, since you applied Steve's patch, it would have been good to give him credit in the changelog. Please keep that in mind for the future. As the patch is trivial and I am almost sure Steve won't mind, I don't see an immediate call for action. However, running linda against the package, I get: W: bluetooth-alsa; The library liba2dpdcommon has a different SOVER versus the shlibs file. (shlibs-sover-mismatch) This does not look good. Please investigate and send an email to me when you have provided an updated version, which I then can sponsor. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems this week dragged past me so slowly; the days fell on their knees... -- david bowie signature.asc Description: Digital signature (GPG/PGP)
Re: RFS: grub-splashimages (updated package)
On 14/07/07, Krzysztof Burghardt [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.2.1 of my package grub-splashimages. I will take a look. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bypassing required libraries check exporting DEPS_CFLAGS and DEPS_LIBS
Hi, I'm trying to package gtkol-ldap a ldap client, I think it's a good program, the problem is that when I try to build it I get an error for a required lib that I have installed but because a bug it is not detected correctly, I've found a trick to avoid it but I don't know if it's a good solution or if it's a bad way to do the package... So I ask mentors for comments :) gtkol-ldap requires libgenerics-dev and libgtkol-dev but when it calls pkg-config --cflags libgtkol-1.4 it fails because of bug #427213, I've reported this bug 42 days ago but without any response, so now I'm trying to bypass this, exporting DEPS_CFLAGS and DEPS_LIBS to bypass the check of required libraries in the configure script. It's a so bad solution? cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: RFS: vegastrike and vegastrike-data (updated packages)
On Sat, 2007-07-14 at 02:34 -0400, Andres Mejia wrote: I am looking for a sponsor for the packages vegastrike and vegastrike-data. I've enjoyed playing it from time to time, so I'm interested. But read on. This is an update to the vegastrike and vegastrike-data package that is already in Debian. There seems to have been some additional changes in the SVN repository on svn://svn.debian.org/pkg-games/packages/trunk/vegastrike -- would it make more sense to just point to svn tags in that repository and ask sponsors to build and upload that? I only gave it a cursory look, but there seems to be an issue with the versioning. The last version in sid is 0.4.3.debian-1, which is greater than 0.4.3-7 (the last version in SVN). So you're more or less stuck with 0.4.3.debian-N until upstream releases 0.4.4 or greater. Or are you using x.y.z-N in SVN and expect a Debian sponsor to use x.y.z.debian-N when uploading? Please mention such things when asking for a sponsor. I can't see anything inherently wrong with the package at the moment, but you have been asked some questions in http://lists.alioth.debian.org/pipermail/pkg-games-devel/2007-July/003966.html that probably need to be answered first. Among other things, the team decision seems to be to use quilt and not dpatch. Both of these packages require the orig tarball to be uploaded again as there needed to be fixes in the source to address some lintian warnings and errors. It's very good to have documented the steps you took to package the upstream source from their SVN, but if possible, to ease future maintenance, it would be a good idea to write a script that automates all the steps you took, and include it in the debian directory. Of course, it'll need updating from time to time, but it would remove any ambiguity about what your orig tarball actually is meant to contain, while still allowing sponsors/uploaders to get pristine source from upstream. Anyway, could you clarify the work process and work with the pkg-games team -- if everyone there is busy then I suppose I could upload, but not until I know about how that team works and maintains this package. (Maybe I should join it -- have to give that some thought.) That would be good advice for any prospective sponsor, I suppose. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: bypassing required libraries check exporting DEPS_CFLAGS and DEPS_LIBS
On Sat, 14 Jul 2007 18:32:48 +0200 Francesco Namuri [EMAIL PROTECTED] wrote: Hi, I'm trying to package gtkol-ldap a ldap client, I think it's a good program, the problem is that when I try to build it I get an error for a required lib that I have installed but because a bug it is not detected correctly, I've found a trick to avoid it but I don't know if it's a good solution or if it's a bad way to do the package... So I ask mentors for comments :) 1. You must ensure that the package will rebuild once the bug is fixed. 2. You should add a full patch to that bug report - possibly as an NMU - and make an RFS for that if there is still no response. It's been nearly two weeks since that bug was filed. Add a patch and a notice that you intend to prepare an NMU then wait another week or so. i.e. Fix the problem, don't workaround it. The libgtkol1 package appears to have no reverse dependencies (except it's own -dev) so it is quite possible that this bug has been completely missed. Quite why a library exists in Debian that is not used by any application (and which would therefore appear in the output of deborphan on every installation) is a separate question. This also means that your RC bug may not get that much attention! Make it easy to fix the bug and you will probably get better results. gtkol-ldap requires libgenerics-dev and libgtkol-dev but when it calls pkg-config --cflags libgtkol-1.4 it fails because of bug #427213, I've reported this bug 42 days ago but without any response, so now I'm trying to bypass this, exporting DEPS_CFLAGS and DEPS_LIBS to bypass the check of required libraries in the configure script. It's a so bad solution? It is if your workaround breaks when the bug is fixed. There is no point rushing uploads. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp8mmyik8zfv.pgp Description: PGP signature
RFS: libsbc (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.0cvs20070327-2 of my package libsbc. It builds these binary packages: libsbc-dev - Development files for subband codec (SBC) library libsbc0- Subband codec (SBC) library sbcinfo- Subband codec (SBC) analyzer The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libsbc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libsbc/libsbc_0.0cvs20070327-2.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bluetooth-alsa (updated package)
2007/7/14, martin f krafft [EMAIL PROTECTED]: Krzysztof, since you applied Steve's patch, it would have been good to give him credit in the changelog. Please keep that in mind for Sure. If patch is not trivial and I decide to apply this. In this case I haven't applied this patch, as it lacks definition of minimal version need by plugz. Along this trivial patch as this one is not a subject of any kind of authors right (according to Polish law regulations). So it's public domain, isn't it? However, running linda against the package, I get: W: bluetooth-alsa; The library liba2dpdcommon has a different SOVER versus the shlibs file. (shlibs-sover-mismatch) This does not look good. Please investigate and send an email to me when you have provided an updated version, which I then can sponsor. Looks like #313587. shlibs: liba2dpdcommon 0 bluetooth-alsa and library name: liba2dpdcommon.so.0.0.0 Best regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bluetooth-alsa (updated package)
On Sat, Jul 14, 2007 at 09:54:01PM +0200, Krzysztof Burghardt wrote: 2007/7/14, martin f krafft [EMAIL PROTECTED]: Krzysztof, since you applied Steve's patch, it would have been good to give him credit in the changelog. Please keep that in mind for Sure. If patch is not trivial and I decide to apply this. In this case I haven't applied this patch, as it lacks definition of minimal version need by plugz. (It didn't include the minimal version because there are no versions of libbluetooth2-dev in the archive that fail the version requirement.) Along this trivial patch as this one is not a subject of any kind of authors right (according to Polish law regulations). So it's public domain, isn't it? There's nothing in my patch that's copyrightable in my home territory, and even if there was I would be happy for you to consider it so. Of course, crediting patch submitters is less about law than it is about community and the /appreciation/ of the contributions of others; many times a bug fix results in a trivial, non-copyrightable patch but the bug itself is very subtle and the effort that goes into the debugging is worthy of recognition. This is obviously not the case here, I couldn't care less if you credit me for this change. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Broken uploads to mentors.debian.net
Just had a problem with a package for sponsoring that, AFAICT, could not happen with other repositories that I use, so I'm a tad concerned about how it happened on m.d.n. http://mentors.debian.net/debian/pool/main/x/xracer/ A package has been uploaded to m.d.n several times during sponsoring (not uncommon) at the same version (also no uncommon) so the .orig.tar.gz is unchanged (which is correct): xracer_0.96.9.orig.tar.gz 26-Jun-2007 17:26 9.1M Other files have been updated, as expected: xracer_0.96.9-1.diff.gz 14-Jul-2007 17:28 28K xracer_0.96.9-1.dsc 14-Jul-2007 17:28 1.4K That .orig.tar.gz on m.d.n is the same as my last build: 41bdf64eca9960ae8932e27e7ba2bea1 9562055 xracer_0.96.9.orig.tar.gz However, the .dsc file uploaded to m.d.n references a different .orig.tar.gz: 8287bfd7e9ef9a507024bf34761791d8 9562064 xracer_0.96.9.orig.tar.gz Of course, dget -x now refuses to unpack this package - error from dpkg-source. I suspect an error in the .dsc but I thought that dput should have caught that or that the repository management tools at m.d.n should have complained (noisily): Uploaded foo.dsc needs foo.orig.tar.gz with md5sum which differs from the existing foo.orig.tar.gz with md5sum or similar and rejected the upload. I know I have had those kind of warnings from reprepro with other repositories - IIRC it is why we have md5sums in the .dsc in the first place (in addition to GnuPG signatures). Is this a result of the need to allow repeated uploads of packages at the same version? Can something be done with the m.d.n scripts that handle dput uploads to enforce a check that the existing .orig.tar.gz (which should not normally change during sponsorship) matches the reference in the .dsc and allow for the odd occasion where the .orig.tar.gz does have to be repackaged with an explicit mechanism? At the very least, m.d.n should be able to prevent this situation where 'dget -x' fails as this is the most common method of sponsors obtaining sources from m.d.n. If it helps, I have been able to fettle the .dsc to use the correct values for the existing .orig.tar.gz and it has unpacked OK - it appears to simply be an error in the .dsc caused by some problem with the sponsoree. However, I am unable to upload the package in this condition (which is frustrating for the sponsoree because this package has had quite a few changes and he has put in a significant amount of work getting it ready for sponsoring). I was all ready to upload the package tonight too. :-( (Ying-Chun Liu will probably upload a fixed .dsc in due course, so for the record, this is the .dsc that should have been refused.) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.0 Source: xracer Binary: xracer, xracer-tools Architecture: any Version: 1:0.96.9-1 Maintainer: Ying-Chun Liu (PaulLiu) [EMAIL PROTECTED] Standards-Version: 3.7.2 Build-Depends: libjpeg62-dev, debhelper (= 5), freeglut3-dev, gettext, html2text, perl, netpbm, libxmu-dev, libxi-dev, libtool, autoconf (= 2.52), automake, quilt (= 0.40), docbook-to-man Build-Conflicts: autoconf2.13 Files: 8287bfd7e9ef9a507024bf34761791d8 9562064 xracer_0.96.9.orig.tar.gz 5bbfd0dcdcdc17e59fd7127fed2fdf1a 29021 xracer_0.96.9-1.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBRpjrfvgLgUbQQog2AQpnQQ/9Er7++cD0gb/qDg/70yU+ofC5E5lysy9u djSiMopoYR1Xy6b5mkWOew4wofEKHj08PGK6Nudu4FjAoxZ1DeIaeqdZlC+nqDvR pcL/FISLyL9BwtsfKSkyj+MjcqOQUTOX1ohyPV/qDbOUsByaYAu0uT1d1y4v5rkp AwmCHhF/BNqW0nSne5KfQwjM4qY3lekH+qAcNtMFHgifBkZLEEXh7d9H5BoQJAWv Sv5P6lRPj/W0INqWIIlE1FGec9979NZhTw9Y5G9713SWYbazGSKi6qPZYrSJZGKT 3cE4x1UO17dnOVSg556UWnCuurnM3FUWpyhg8va9goHZspjQ/MCniDuFIfqgHk7X YpTNvhZsdrXo2L3uHxoAhgFg5JoopfZNyM9CxoTxSPkb/TxpBi2QAciegpBBIYsZ X5FXjLpD/HIlRoo5iUktIjGj+zWRRR62frrUaLQJFoAlVvwJiSQvT/KDwB4qlz2t eAtMdcit1jk9ndDeXK24waW0HZWq2IIqYgETq+r6CMDNp48IfzK22gsrGqZ8jBd3 0JHJGRtXJTzf/HFWZS0LGcq7gr1JPp3KO4WhpqrJaEzGmYGET6bc9NbaBDjzIVeU Z/b5/K2MPs2kXzZmiU31E5o/soH5CjIo+Ewh+QMqaXSNVh0+ej+2wR4+oa4tOkjq 4IPBBpj/PDs= =fgz9 -END PGP SIGNATURE- For reference, this is my fettled .dsc (removed the GnuPG sig for obvious reasons): Format: 1.0 Source: xracer Binary: xracer, xracer-tools Architecture: any Version: 1:0.96.9-1 Maintainer: Ying-Chun Liu (PaulLiu) [EMAIL PROTECTED] Standards-Version: 3.7.2 Build-Depends: libjpeg62-dev, debhelper (= 5), freeglut3-dev, gettext, html2text, perl, netpbm, libxmu-dev, libxi-dev, libtool, autoconf (= 2.52), automake, quilt (= 0.40), docbook-to-man Build-Conflicts: autoconf2.13 Files: 41bdf64eca9960ae8932e27e7ba2bea1 9562055 xracer_0.96.9.orig.tar.gz 681a348d0a1bff2b867c37893e1a62db 28722 xracer_0.96.9-1.diff.gz The change in the .diff.gz appears to be just because I build on amd64 - interdiff -z reports no differences. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpe2v7KutUd8.pgp Description: PGP signature
Re: Broken uploads to mentors.debian.net
On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote: Just had a problem with a package for sponsoring that, AFAICT, could not happen with other repositories that I use, so I'm a tad concerned about how it happened on m.d.n. http://mentors.debian.net/debian/pool/main/x/xracer/ A package has been uploaded to m.d.n several times during sponsoring (not uncommon) at the same version (also no uncommon) so the .orig.tar.gz is unchanged (which is correct): xracer_0.96.9.orig.tar.gz 26-Jun-2007 17:26 9.1M Other files have been updated, as expected: xracer_0.96.9-1.diff.gz 14-Jul-2007 17:28 28K xracer_0.96.9-1.dsc 14-Jul-2007 17:28 1.4K That .orig.tar.gz on m.d.n is the same as my last build: 41bdf64eca9960ae8932e27e7ba2bea1 9562055 xracer_0.96.9.orig.tar.gz However, the .dsc file uploaded to m.d.n references a different .orig.tar.gz: 8287bfd7e9ef9a507024bf34761791d8 9562064 xracer_0.96.9.orig.tar.gz Of course, dget -x now refuses to unpack this package - error from dpkg-source. I suspect an error in the .dsc but I thought that dput should have caught that or that the repository management tools at m.d.n should have complained (noisily): Uploaded foo.dsc needs foo.orig.tar.gz with md5sum which differs from the existing foo.orig.tar.gz with md5sum or similar and rejected the upload. I know I have had those kind of warnings from reprepro with other repositories - IIRC it is why we have md5sums in the .dsc in the first place (in addition to GnuPG signatures). Is this a result of the need to allow repeated uploads of packages at the same version? Actually I don't like the idea of uploading a different file with the same revision number. But a lot of sponsors seem to expect a ~mentors001 revision suffix or just always a -1 revision until the package is sponsored. When I sponsor packages I always make my sponsorees use proper revision numbers. Who cares if it takes 10 revisions until the package is ready for upload? Let it be revision -10 then. At least I don't need to know that the sponsoree meant the version from yesterday evening 7 p.m. CET-4 but rather use revision -4. I found it educationally better to handle mentors.debian.net just like the usual ftp-master: - once uploaded the orig tarball can't be altered any more - new uploads are only valid with higher version/revision numbers But since so many people insisted that the same revision should be allowed to be overwritten I didn't enforce that. Can something be done with the m.d.n scripts that handle dput uploads to enforce a check that the existing .orig.tar.gz (which should not normally change during sponsorship) matches the reference in the .dsc and allow for the odd occasion where the .orig.tar.gz does have to be repackaged with an explicit mechanism? I just checked the import script I wrote quite a while ago that handles the uploaded files. There is but one situation that I can think of where that clash of orig tarballs could happen: - a sponsoree creates a package for the first time - the orig tarball gets uploaded as it is referenced in the changes/dsc file - the sponsoree somehow alters the orig tarball but keeps the filename (or rather the name and version number) - mentors.debian.net believes it already has the orig file in the pool directory and ignores the newly uploaded file Instead of obeying the MD5 sum of the package at that point (I do when the .dsc file is checked though) I'll make sure that all the uploaded files will replace all previous existing files of a source package in the pool directories. That should do it. At the very least, m.d.n should be able to prevent this situation where 'dget -x' fails as this is the most common method of sponsors obtaining sources from m.d.n. Correct. I have to either forbid that or make it work gracefully. I think I'll rather accept that but send the uploader a big warning. If it helps, I have been able to fettle the .dsc to use the correct values for the existing .orig.tar.gz and it has unpacked OK - it appears to simply be an error in the .dsc caused by some problem with the sponsoree. However, I am unable to upload the package in this condition (which is frustrating for the sponsoree because this package has had quite a few changes and he has put in a significant amount of work getting it ready for sponsoring). I was all ready to upload the package tonight too. Current workaround: let the sponsoree delete the package through the web interface and re-upload. I'll look into this later today and probably fix it. Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nagvis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package nagvis. * Package name: nagvis Version : 1.1rc2-1 Upstream Author : Lars Michelsen [EMAIL PROTECTED], Michael Luebben [EMAIL PROTECTED] * URL : http://nagvis.org * License : gpl Section : misc It builds these binary packages: nagvis - Visualization addon for Nagios The package appears to be lintian clean. The upload would fix these bugs: 433048 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/n/nagvis - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/n/nagvis/nagvis_1.1rc2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Hendrik Frenzel - -- I am chaos. I am the substance from which your artists and scientists build rhythms and rhimes. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and I tell you that you are free. - Eris, Goddess Of Chaos, Discord Confusion. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGmU88jWcQfAgCZA8RCKQoAJsGFq/fu0md7DZUpwRGEZVaDZT8hgCghEQE 99u0/31RZQdJ6dr85NFaK54= =SUfI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nagvis-iconset-bigfolder-nuvola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package nagvis-iconset-bigfolder-nuvola. * Package name: nagvis-iconset-bigfolder-nuvola Version : 20070429-1 Upstream Author : Lars Michelsen [EMAIL PROTECTED], Michael Luebben [EMAIL PROTECTED] the art.gnome.org team [EMAIL PROTECTED] * URL : http://nagvis.org * License : gpl Section : misc It builds these binary packages: nagvis-iconset-bigfolder-nuvola - Iconset bigfolder nuvola for NagVis The package appears to be lintian clean. The upload would fix these bugs: 433097 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/n/nagvis-iconset-bigfolder-nuvola - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/n/nagvis-iconset-bigfolder-nuvola/nagvis-iconset-bigfolder-nuvola_20070429-1.dsc I would be glad if someone uploaded this package for me. Kind regards Hendrik Frenzel - -- I am chaos. I am the substance from which your artists and scientists build rhythms and rhimes. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and I tell you that you are free. - Eris, Goddess Of Chaos, Discord Confusion. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGmU9FjWcQfAgCZA8RCJigAJ4zkRkyZAC+cg6A9EXeGhjax6GsqwCgzqCI INa0rUezjSJeL/9mS228VgM= =I3gK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nagvis-shapes-dropline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package nagvis-shapes-dropline. * Package name: nagvis-shapes-dropline Version : 20070426-1 Upstream Author : Lars Michelsen [EMAIL PROTECTED], Michael Luebben [EMAIL PROTECTED] the art.gnome.org team [EMAIL PROTECTED] * URL : http://nagvis.org * License : gpl Section : misc It builds these binary packages: nagvis-shapes-dropline - Dropline shapes for NagVis The package appears to be lintian clean. The upload would fix these bugs: 433096 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/n/nagvis-shapes-dropline - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/n/nagvis-shapes-dropline/nagvis-shapes-dropline_20070426-1.dsc I would be glad if someone uploaded this package for me. Kind regards Hendrik Frenzel - -- I am chaos. I am the substance from which your artists and scientists build rhythms and rhimes. I am the spirit with which your children and clowns laugh in happy anarchy. I am chaos. I am alive, and I tell you that you are free. - Eris, Goddess Of Chaos, Discord Confusion. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGmU9KjWcQfAgCZA8RCJTjAJoDydXKJqvAwlS86Cndd2Cu658+qgCdElAO ycL/o0MfIxWDU0IiP0ew3PM= =ITC+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Broken uploads to mentors.debian.net
On Sun, 15 Jul 2007 00:31:29 +0200 Christoph Haas [EMAIL PROTECTED] wrote: On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote: Is this a result of the need to allow repeated uploads of packages at the same version? Actually I don't like the idea of uploading a different file with the same revision number. But a lot of sponsors seem to expect a ~mentors001 revision suffix or just always a -1 revision until the package is sponsored. When I sponsor packages I always make my sponsorees use proper revision numbers. Who cares if it takes 10 revisions until the package is ready for upload? Let it be revision -10 then. At least I don't need to know that the sponsoree meant the version from yesterday evening 7 p.m. CET-4 but rather use revision -4. I found it educationally better to handle mentors.debian.net just like the usual ftp-master: - once uploaded the orig tarball can't be altered any more - new uploads are only valid with higher version/revision numbers I'm coming around to that way of doing things, I must say. :-) Aligning m.d.n with ftp-master can't really be a bad thing - the fewer surprises I get, the easier it is to sponsor. AFAICT the habit of keeping the same version during sponsorship comes down to the package hasn't been uploaded to Debian / is not available to users so why change the version. Personally, I'm beginning to think that this is spurious. Lots of upstream packages move from 0.1 to 0.6 and there is no particular reason why all debian versions must be sequential - gaps are perfectly acceptable. If sponsors choose to create gaps during sponsoring and then use -sa as necessary, is there really a problem with that? - the sponsoree somehow alters the orig tarball but keeps the filename (or rather the name and version number) - mentors.debian.net believes it already has the orig file in the pool directory and ignores the newly uploaded file Instead of obeying the MD5 sum of the package at that point (I do when the .dsc file is checked though) I'll make sure that all the uploaded files will replace all previous existing files of a source package in the pool directories. That should do it. Thanks for the quick response. At the very least, m.d.n should be able to prevent this situation where 'dget -x' fails as this is the most common method of sponsors obtaining sources from m.d.n. Correct. I have to either forbid that or make it work gracefully. I think I'll rather accept that but send the uploader a big warning. OK. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpM3tWEDygTn.pgp Description: PGP signature
Re: RFS: gimmie
Michael Biebl wrote: Thierry Randrianiriana schrieb: I would be glad if someone uploaded this package for me. the package looks well done, I only have some smaller points: [..] If you can address the above issues, I'll gladly sponsor your package. Hi Thierry, haven't heard from you so far. Have you found another sponsor or are you still interested in having your package sponsored? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Broken uploads to mentors.debian.net
On Sun, 15 Jul 2007 09:00:44 am Neil Williams wrote: On Sun, 15 Jul 2007 00:31:29 +0200 Christoph Haas [EMAIL PROTECTED] wrote: On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote: Is this a result of the need to allow repeated uploads of packages at the same version? Actually I don't like the idea of uploading a different file with the same revision number. But a lot of sponsors seem to expect a ~mentors001 revision suffix or just always a -1 revision until the package is sponsored. When I sponsor packages I always make my sponsorees use proper revision numbers. Who cares if it takes 10 revisions until the package is ready for upload? Let it be revision -10 then. At least I don't need to know that the sponsoree meant the version from yesterday evening 7 p.m. CET-4 but rather use revision -4. I found it educationally better to handle mentors.debian.net just like the usual ftp-master: - once uploaded the orig tarball can't be altered any more - new uploads are only valid with higher version/revision numbers I'm coming around to that way of doing things, I must say. :-) Aligning m.d.n with ftp-master can't really be a bad thing - the fewer surprises I get, the easier it is to sponsor. AFAICT the habit of keeping the same version during sponsorship comes down to the package hasn't been uploaded to Debian / is not available to users so why change the version. Personally, I'm beginning to think that this is spurious. Lots of upstream packages move from 0.1 to 0.6 and there is no particular reason why all debian versions must be sequential - gaps are perfectly acceptable. If sponsors choose to create gaps during sponsoring and then use -sa as necessary, is there really a problem with that? IMHO, that shows that the potential sponsoree is competent at updating the changelog to deal with reported bugs and the (s)he becomes familiar with tools like debchange(1). Possibly the most important skill a maintainer could possess, second to having the ability to actually fix reported bugs. If a potential sponsor refuses any package because the changelog has been updated for _every_ change (even for developmental changes, even for first upload to debian) then i would say that is poor form, because those are bad developmental habits to teach. the package hasn't been uploaded to Debian / is not available to users so why change the version is purely aesthetic sentiment. Please don't let that compromise the historical and technical merits of any package. I would hope that bumping changelog revisions with detailed descriptions of each and every change be actively encouraged. This assists the maintainer in his/her learning of skills, and allows them to keep history of what problems they have encountered before and how they solved the problem. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vegastrike and vegastrike-data (updated packages)
On 7/14/07, Fabian Fagerholm [EMAIL PROTECTED] wrote: On Sat, 2007-07-14 at 02:34 -0400, Andres Mejia wrote: I am looking for a sponsor for the packages vegastrike and vegastrike-data. I've enjoyed playing it from time to time, so I'm interested. But read on. This is an update to the vegastrike and vegastrike-data package that is already in Debian. There seems to have been some additional changes in the SVN repository on svn://svn.debian.org/pkg-games/packages/trunk/vegastrike -- would it make more sense to just point to svn tags in that repository and ask sponsors to build and upload that? I've included the extra changes found in SVN. It'll all be with this version update. It would make more sense to use the SVN, but I'm not sure if all sponsors would prefer getting the packages this way. I only gave it a cursory look, but there seems to be an issue with the versioning. The last version in sid is 0.4.3.debian-1, which is greater than 0.4.3-7 (the last version in SVN). So you're more or less stuck with 0.4.3.debian-N until upstream releases 0.4.4 or greater. Or are you using x.y.z-N in SVN and expect a Debian sponsor to use x.y.z.debian-N when uploading? Please mention such things when asking for a sponsor. Well, I've changed the version to 0.4.3.debian-2. Upstream is planning on releasing an update sometime in August. My intention was to drop the version back to 0.4.3-x and maybe add a Replaces and Conflicts field with vegastrike (=0.4.3.debian-1), but a new release is planned anyways. I can't see anything inherently wrong with the package at the moment, but you have been asked some questions in http://lists.alioth.debian.org/pipermail/pkg-games-devel/2007-July/003966.html that probably need to be answered first. Among other things, the team decision seems to be to use quilt and not dpatch. I've made some corrections from that email. The XS-* lines are back in. I didn't think they were useful but Eddy brought up a good point. I've documented the change with the Suggests line of vegastrike-data. With the patch that modifies python1.5 to python, that was to fix a lintian error. I've added a note in the changelog. Also, there's no python1.5 in Debian anymore so I don't think there's a choice but to use python instead. I've tested the game with this and it runs fine. With the use of dpatch, it's acceptable to the team, yet quilt is highly preferred. I just haven't used quilt enough to know if it really is that much better to use as far as packaging goes. For now, I've stuck with dpatch. Both of these packages require the orig tarball to be uploaded again as there needed to be fixes in the source to address some lintian warnings and errors. It's very good to have documented the steps you took to package the upstream source from their SVN, but if possible, to ease future maintenance, it would be a good idea to write a script that automates all the steps you took, and include it in the debian directory. Of course, it'll need updating from time to time, but it would remove any ambiguity about what your orig tarball actually is meant to contain, while still allowing sponsors/uploaders to get pristine source from upstream. I'll do this if needed in the next release. I don't think there will need to be any changes to the orig tarball after these changes. Anyway, could you clarify the work process and work with the pkg-games team -- if everyone there is busy then I suppose I could upload, but not until I know about how that team works and maintains this package. (Maybe I should join it -- have to give that some thought.) That would be good advice for any prospective sponsor, I suppose. This should be done now. As far as the collaboration with the team, I've received some help and comments here and there. If there's something wrong with a package, they either fix it or let me and/or the others know. As far as how we maintain this package, there's a general way the team handles all packages. We strive for using the same tools (http://wiki.debian.org/Games/ToolsDiscuss) and there's some goals set at http://wiki.debian.org/Games/Development . For sponsors, there's some information at http://wiki.debian.org/Games/Sponsors. Any suggestions is welcome. I'm uploading the changes overnight. Should be all done in the next three hours. Thanks. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vegastrike and vegastrike-data (updated packages)
Andres Mejia [EMAIL PROTECTED] writes: With the use of dpatch, it's acceptable to the team, yet quilt is highly preferred. I just haven't used quilt enough to know if it really is that much better to use as far as packaging goes. For now, I've stuck with dpatch. It takes a little bit of getting used to (although there is excellent documentation), but yes, at least in my opinion, it really is that much better. It offers way more functions for manipulating patches, and if you're used to regular version control, the quilt patch editing mechanism just feels more natural than dpatch's. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
