Re: Change in my sponsorship requirements
On Sun, Jul 15, 2007 at 09:37:39PM +0200, Christoph Haas <[EMAIL PROTECTED]> wrote: > As I outlined in the mentors.debian.net thread I'm a great fan of not > having different uploads with the same revision number. So I'd even like > to enforce that uploads to mentors.debian.net with the same revision > number as an existing upload is ignored. > > However the above proposals have two issues I don't really like: > > - they tell the package maintainer that the revision must be "-1" when > the package finally enters Debian. The "pre" releases using the > "~unreleased.1" syntax tastes complicated. > - if the sponsor deems the package worthy to be uploaded then the > sponsoree would still need to build the package again because it is > finally allowed to carry the "-1" revision The sponsor should have to build the package anyways, so why not make the sponsor consolidate the changelog if he thinks it's worth uploading ? > Why so complicated? Just increase the revision number. And if 1.0-8 is > the first revision that fits the sponsor's taste then be it so. The > ftp-master server is not oppinionated on revisions higher than "-1". But then, the maintainer or the sponsor would have to take an extra care to include the .orig.tar.gz in the changes, because default options of build tools won't if the revision is not -1. Mike -- 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, 14.07.2007 14:15 |=- > 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 ? If the version number is bigger - yes. I am not sure whether it is required for the Maintainer: field to be the same. I guess not. David, Jose, since it appears you both are interested in maintaining that package, I very much hope that you end up co-maintaining it :) Please do not take my upload as an act of preference of one's package over the other's. It was Charles' polite asking that make me consider it for upload. - -- Damyan IvanovJabberID: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmv3lHqjlqpcl9jsRAjVGAKCMSTjFTK+0TD6DNUBpvFyWeBdOBQCcDNiI cUr9TYNSz5RUUW5xHM5HU0s= =LytU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: funguloids
Dear mentors, I am looking for a sponsor for my package "funguloids". * Package name: funguloids Version : 1.06-1 Upstream Author : Mika Halttunen <[EMAIL PROTECTED]> * URL : http://funguloids.sourceforge.net/ * License : zlib/libpng Section : contrib/games It builds these binary packages: funguloids - space-flying-mushroom-picking-simulator game The package appears to be lintian clean. The upload would fix these bugs: 428718 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/f/funguloids - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/f/funguloids/funguloids_1.06-1.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]
RFS: warsow (corrected package)
Dear mentors, I am looking for a sponsor for my package "warsow". These include some corrections needed in order for warsow to be accepted, as noted by this email. http://lists.alioth.debian.org/pipermail/pkg-games-devel/2007-July/003982.html * Package name: warsow Version : 0.31.dfsg-2 Upstream Author : Fabrice Demurger * URL : http://www.warsow.net/ * License : GPL Section : contrib/games It builds these binary packages: warsow - A comic-style fast-paced 3D ego-shooter warsow-server - Server for the Warsow 3D ego-shooter game The package appears to be lintian clean. The upload would fix these bugs: 375430 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/w/warsow - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/w/warsow/warsow_0.31.dfsg-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: Broken uploads to mentors.debian.net
On Sun, Jul 15, 2007 at 10:41:57PM +0200, Christoph Haas wrote: > I have no good explanation for the situation Neil mentioned though. The > package maintainer must have uploaded a package with an orig tarball. > But then the orig tarball was changed and an upload without an orig > tarball was done that mentioned the orig tarball though. > > How come the .dsc file mentions an orig file that is not uploaded? All > files mentioned in the .dsc file must be uploaded. I'm confused. No they don't. All the files mentioned in a .changes get uploaded, because the .changes represents the changes made to the archive (hence the name). In contrast, a .dsc describes a particular Debian source package. If someone builds a Debian source package with a different .orig.tar.gz to another source package (of the same source package name and upstream version), then you'll get a different .orig.tar.gz mentioned in the .dsc. What happens from there is a matter for whatever is processing the .dsc after that. >From a personal perspective, I think m.d.n should work as close to ftp-master as possible. If you want to keep the ability to have people take multiple stabs at a single package revision, then at the very least, .dsc files should be verified after upload and if the sums don't *all* match or one of the files in the .dsc is missing, the upload is rejected. That would solve Neil's problem, at the very least. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ftpsync -- fast ftp directory synchronization
On Sun, Jul 15, 2007 at 05:13:58PM +0200, Julian Andres Klode wrote: > I am looking for a sponsor for my package "ftpsync". Any major feature improvements over sitecopy? - Matt -- 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 22:41:57 +0200 Christoph Haas <[EMAIL PROTECTED]> wrote: > On Sun, Jul 15, 2007 at 12:31:29AM +0200, I wrote: > > On Sat, Jul 14, 2007 at 10:42:52PM +0100, Neil Williams wrote: > > > > > > However, the .dsc file uploaded to m.d.n references a > > > different .orig.tar.gz: > > > 8287bfd7e9ef9a507024bf34761791d8 9562064 xracer_0.96.9.orig.tar.gz > > > > I'll look into this later today and probably fix it. > > Now I checked the import script at mentors.debian.net and also did a > few test uploads. If a 'dsc' file mentions an orig tarball then the > old tarball is replaced in every case. So if the package maintainer > would upload a package built with "-sa" (including the orig tarball > even with non-1 revisions) then everything should work well. > > I have no good explanation for the situation Neil mentioned though. It turned out to be due to a broken upload - an FTP connection timeout. (I've been busy finalising the actual upload.) The maintainer used nemesis to keep the next connection alive. > The package maintainer must have uploaded a package with an orig > tarball. But then the orig tarball was changed and an upload without > an orig tarball was done that mentioned the orig tarball though. > > How come the .dsc file mentions an orig file that is not uploaded? All > files mentioned in the .dsc file must be uploaded. I'm confused. Is there some way of detecting a failed FTP upload and removing the corrupted files? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpP9fGbpvxMU.pgp Description: PGP signature
Re: Broken uploads to mentors.debian.net
On Sun, Jul 15, 2007 at 12:31:29AM +0200, I wrote: > 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 > > I'll look into this later today and probably fix it. Now I checked the import script at mentors.debian.net and also did a few test uploads. If a 'dsc' file mentions an orig tarball then the old tarball is replaced in every case. So if the package maintainer would upload a package built with "-sa" (including the orig tarball even with non-1 revisions) then everything should work well. I have no good explanation for the situation Neil mentioned though. The package maintainer must have uploaded a package with an orig tarball. But then the orig tarball was changed and an upload without an orig tarball was done that mentioned the orig tarball though. How come the .dsc file mentions an orig file that is not uploaded? All files mentioned in the .dsc file must be uploaded. I'm confused. 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]
Re: Change in my sponsorship requirements
On Sun, Jul 15, 2007 at 12:41:16PM +0200, Bart Martens wrote: > On Sun, 2007-07-15 at 11:45 +0200, martin f krafft wrote: > > I make use of > > the new ~ character in version strings. Even more my own packages, > > I'll release > > > > 1.0-1~unreleased.1 > > 1.0-1~unreleased.2 > > 1.0-1~unreleased.3 > > > > until it's final and I can release 1.0-1, for which I merge the > > previous changelog entries. This is more work and requires more > > recompiles, but it does the job without cluttering the changelog. > > That is a good approach, in my opinion. > > To make this approach more complete, the packager requesting a sponsor > could package the software initially with this version and revision: > >1.0~rfs.1-1~rfs.1 > > After each review the revision number is incremented: > >1.0~rfs.1-1~rfs.2 >1.0~rfs.1-1~rfs.3 >1.0~rfs.1-1~rfs.4 > > When the .orig.tar.gz needs repackaging, then this happens: > >1.0~rfs.2-1~rfs.1 >1.0~rfs.3-1~rfs.1 > > And when it's finally allright, then the package (containing a > debian/README.Debian-source) can still get this version and revision > when uploaded to Debian: > >1.0-1 As I outlined in the mentors.debian.net thread I'm a great fan of not having different uploads with the same revision number. So I'd even like to enforce that uploads to mentors.debian.net with the same revision number as an existing upload is ignored. However the above proposals have two issues I don't really like: - they tell the package maintainer that the revision must be "-1" when the package finally enters Debian. The "pre" releases using the "~unreleased.1" syntax tastes complicated. - if the sponsor deems the package worthy to be uploaded then the sponsoree would still need to build the package again because it is finally allowed to carry the "-1" revision Why so complicated? Just increase the revision number. And if 1.0-8 is the first revision that fits the sponsor's taste then be it so. The ftp-master server is not oppinionated on revisions higher than "-1". 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]
Re: Change in my sponsorship requirements
On Sun, Jul 15, 2007 at 12:23:48PM +0200, Bart Martens wrote: > On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: > > I think it is easier for everyone if every change > > during sponsorship gets a new Debian version, so if you need me to > > sponsor packages, each upload to mentors.debian.net must use a new > > Debian version. > That makes debian/changelog written by newbie packagers needlessly long. Giving each upload a different version number doesn't mean that you have to retain changelog entries for each previous version; you can just renumber the changelog entry and append to it. -- 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]
Re: Change in my sponsorship requirements
On Sun, 15 Jul 2007 18:32:23 +0300 > On Sunday 15 July 2007, martin f krafft wrote: > > Yes, exactly. Each packaging attempt gets a separate changelog entry > > and when it's final, you merge them all, effectively erasing the > > history. Martin - my only problem with this collapsing of the changes is that debian/changelog would need to be edited by the sponsor to achieve this without causing yet another rebuild and upload to mentors.d.n cycle. dpkg can collapse the changes from multiple versions into the .changes file automatically and with no need to either edit package files or cause another build/upload cycle. The only difference is that the timestamps are retained. IMHO that is preferable to a whole new cycle or sponsors editing the package directly. > packagename (1.0-1~unreleased.1) unstable; urgency=low > -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 > packagename (1.0-1~unreleased.1) unstable; urgency=low > -- John Doe <[EMAIL PROTECTED]> Sun, 07 May 2007 21:52:26 +0200 > // merging all changelog rows in one changelog entry > packagename (1.0-1) unstable; urgency=low It's easy when it is your package but sponsors aren't supposed to be changing the package between mentors.d.n and ftp-master.d.o I'm not sure that just losing the history is sufficient benefit for losing the direct link between mentors.d.n and packages.d.o. I thought that sponsors should only be adding a signature, not changing fundamental files like debian/changelog. Plus the sponsor can't use any debchange type command to do the work because that will put their name into the final timestamp, causing lintian errors of an NMU and another rebuild. IMHO it would be better to keep the ~unreleased or ~rfs change entries intact - with timestamps - into the final package. However, this still means either the sponsor edits debian/changelog and rebuilds prior to the upload OR the sponsor gives the green light to the maintainer to rebuild without the ~rfs suffix on the latest changelog entry (or create yet another), reupload to mentors.d.n and the sponsor has to again check the package and make sure that this is all that has been changed. With timezone issues etc., it can take an appreciable amount of time to complete a full cycle through mentors.d.n. I'm happier with: packagename (1.0-2) unstable; urgency=low -- John Doe <[EMAIL PROTECTED]> Sun, 08 May 2007 14:52:26 +0200 packagename (1.0-1) unstable; urgency=low -- John Doe <[EMAIL PROTECTED]> Sun, 07 May 2007 21:52:26 +0200 (p)?debuild -sa -v 1.0-1 That could even fit into an alias sponsornew='debuild -sa' and psponsornew etc. Then continue thus until the sponsor is happy with the package, at which point it can be uploaded with only a signature added or modified by the sponsor. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpTqBat2e2T6.pgp Description: PGP signature
Re: Change in my sponsorship requirements
>> Yes, exactly. Each packaging attempt gets a separate changelog entry >> and when it's final, you merge them all, effectively erasing the >> history. >> > > If I understand you correctly you mean a progress as follows: > > === Day 1 === > Day 1 is probably a bit confusing here. A new revision every day makes no sene, more after publishing the work somewhere or if you want to test it on machines. > packagename (1.0-1~unreleased.1) unstable; urgency=low > > * newbie change 1. > > -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 > > === Day 2 === > packagename (1.0-1~unreleased.1) unstable; urgency=low > -^^ that should be 1.0-1~unreleased.2 > * newbie change 2. > > -- John Doe <[EMAIL PROTECTED]> Sun, 07 May 2007 21:52:26 +0200 > > [...] > > IMO, it is acceptable, but way too complicated and doesn't match completely > the official procedure. > not really complicated, that's what dch(1) is for. And official procedures can be changed - although I don't see why this would not match an official procedure, as long as the unreleased versions are not uploaded into debian. Best regards, Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: dir2ogg -- audio file converter into ogg-vorbis format
Dear mentors, I am looking for a sponsor for my package "dir2ogg". * Package name: dir2ogg Version : 0.10-1 Upstream Author : me - Julian Andres Klode <[EMAIL PROTECTED]> * URL : http://jak-linux.org/projects/dir2ogg/ * License : GPL Section : sound It builds these binary packages: dir2ogg- audio file converter into ogg-vorbis format The package appears to be lintian clean. The upload would fix these bugs: 428188 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dir2ogg - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dir2ogg/dir2ogg_0.10-1.dsc I would be glad if someone uploaded this package for me. Kind regards Julian Andres Klode -- long description: dir2ogg converts MP3, M4A, WMA and WAV files to the open-source OGG format. It is a python script that simply binds together mpg123, faad, and oggenc making it easier for the user to convert his/her music files. It also supports id3 tags. . Homepage: http://jak-linux.org/projects/dir2ogg/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Change in my sponsorship requirements
On Sunday 15 July 2007, martin f krafft wrote: > also sprach Colin Tuckley <[EMAIL PROTECTED]> [2007.07.15.1618 +0200]: > > No, I saw it and assumed that is what would happen in the case > > where the uploads use ~r1 etc and the final upload to Debian by > > the sponsor deleted the extra part of the revision. > > > > It's having all the changelog entries for the packaging *attempts* > > in the final debian package that I'm objecting to. > > Yes, exactly. Each packaging attempt gets a separate changelog entry > and when it's final, you merge them all, effectively erasing the > history. If I understand you correctly you mean a progress as follows: === Day 1 === packagename (1.0-1~unreleased.1) unstable; urgency=low * newbie change 1. -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 === Day 2 === packagename (1.0-1~unreleased.1) unstable; urgency=low * newbie change 2. -- John Doe <[EMAIL PROTECTED]> Sun, 07 May 2007 21:52:26 +0200 packagename (1.0-1~unreleased.1) unstable; urgency=low * newbie change 1. -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 === Day 3 - ready to release === // merging all changelog rows in one changelog entry packagename (1.0-1) unstable; urgency=low * newbie change 1. * newbie change 2. -- John Doe <[EMAIL PROTECTED]> Sun, 08 May 2007 21:52:26 +0200 IMO, it is acceptable, but way too complicated and doesn't match completely the official procedure. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: ftpsync -- fast ftp directory synchronization
Dear mentors, I am looking for a sponsor for my package "ftpsync". * Package name: ftpsync Version : 0.1-1 Upstream Author : me - Julian Andres Klode <[EMAIL PROTECTED]> * URL : http://jak-linux.org/projects/ftpsync/ * License : GPL Section : net It builds these binary packages: ftpsync- fast ftp directory synchronization The package appears to be lintian clean. The upload would fix these bugs: 429856 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/ftpsync - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/ftpsync/ftpsync_0.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Julian Andres Klode -- long description: ftpsync provides fast synchronization of directories on ftp sites. It uses text files and sha1sums to calculate differences and uploads only the changed files, new files and new directories and removes obsolete files and directories on the ftp site . Homepage: http://jak-linux.org/projects/ftpsync/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Change in my sponsorship requirements
also sprach Colin Tuckley <[EMAIL PROTECTED]> [2007.07.15.1618 +0200]: > No, I saw it and assumed that is what would happen in the case > where the uploads use ~r1 etc and the final upload to Debian by > the sponsor deleted the extra part of the revision. > > It's having all the changelog entries for the packaging *attempts* > in the final debian package that I'm objecting to. Yes, exactly. Each packaging attempt gets a separate changelog entry and when it's final, you merge them all, effectively erasing the history. Apart from that, don't be ashamed of making progress! -- 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 heisenberg may have been here. signature.asc Description: Digital signature (GPG/PGP)
Re: Change in my sponsorship requirements
On Sun, 2007-07-15 at 16:47 +0300, George Danchev wrote: > On Sunday 15 July 2007, Bart Martens wrote: > > On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote: > --cut-- > > Something like this ? > > > > packagename (0.1.0-8) unstable; urgency=low > > > > * Updated debian/watch to recognize both ".tar.gz" and ".tar.bz2", > > now revealing the real latest upstream release. > --cut-history-- > > It's not a huge problem, but it's not so nice to have all beginners > > mistakes logged forever for the whole world to see. > > Then you are trying to cheat the world behind the scene, right ? ... in the > name of PR ? If that is the real history, let be it. No, it's not about "cheat" and "pr" and changing "the real history", but for me it's about what I wrote in my previous messages and about some very reasonable (numbered) part Colin wrote. > > OTOH, as a sponsee, I won't work with sponsors who force me to edit the past > in the name of spurious beautification ;-) No, this debate is not about forcing to summarize debian/changelog, but about forcing to preserve everything in debian/changelog during the entire sponsoring process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
martin f krafft wrote: > You may have missed my point about merging the changelog entries > when preparing the final version. Until then, having changelog > entries for mentee changes is rather helpful to the sponsor, > I think. No, I saw it and assumed that is what would happen in the case where the uploads use ~r1 etc and the final upload to Debian by the sponsor deleted the extra part of the revision. It's having all the changelog entries for the packaging *attempts* in the final debian package that I'm objecting to. Colin -- Colin Tuckley | [EMAIL PROTECTED] | PGP/GnuPG Key Id +44(0)1903 236872 | +44(0)7799 143369 | 0x1B3045CE "My mind free-associates far too much; I'm going to have to start charging it." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
also sprach Colin Tuckley <[EMAIL PROTECTED]> [2007.07.15.1501 +0200]: > 1) I don't want my failed attempts seen forever. > > 2) it's a lot of unneeded and irrelevant information. (it's about the > packaging *attempt* not about the packaging). You may have missed my point about merging the changelog entries when preparing the final version. Until then, having changelog entries for mentee changes is rather helpful to the sponsor, I think. -- 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 it may look like i'm just sitting here doing nothing. but i'm really actively waiting for all my problems to go away. signature.asc Description: Digital signature (GPG/PGP)
Re: Change in my sponsorship requirements
also sprach Bart Martens <[EMAIL PROTECTED]> [2007.07.15.1241 +0200]: > When the .orig.tar.gz needs repackaging, then this happens: > >1.0~rfs.2-1~rfs.1 >1.0~rfs.3-1~rfs.1 This should not need to happen. The orig.tar.gz should hardly ever be repacked. -- 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 "zum christentum wird man nicht geboren, man muß dazu nur krank genug sein." - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Re: Change in my sponsorship requirements
On Sunday 15 July 2007, Bart Martens wrote: > On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote: --cut-- > Something like this ? > > packagename (0.1.0-8) unstable; urgency=low > > * Updated debian/watch to recognize both ".tar.gz" and ".tar.bz2", > now revealing the real latest upstream release. --cut-history-- > It's not a huge problem, but it's not so nice to have all beginners > mistakes logged forever for the whole world to see. Then you are trying to cheat the world behind the scene, right ? ... in the name of PR ? If that is the real history, let be it. OTOH, as a sponsee, I won't work with sponsors who force me to edit the past in the name of spurious beautification ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
Bart Martens wrote: > It's not a huge problem, but it's not so nice to have all beginners > mistakes logged forever for the whole world to see. Speaking as someone in NM, that is an important point. I don't use mentors for my uploads, I either use my own web space or a system put in place by my AM which allows me to upload packages to his puiparts system where they get checked. Both mean that I can keep the version the same until it's ready for upload. If I did have to use mentors then I wouldn't mind using the ~r1 idea, with the final uploaded version having that part removed, but I would be against changing the actual Debian revision each time for two reasons. 1) I don't want my failed attempts seen forever. 2) it's a lot of unneeded and irrelevant information. (it's about the packaging *attempt* not about the packaging). Colin -- Colin Tuckley | [EMAIL PROTECTED] | PGP/GnuPG Key Id +44(0)1903 236872 | +44(0)7799 143369 | 0x1B3045CE No trees were harmed during the production of this message, but a large number of electrons were terribly inconvenienced -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
Bart Martens wrote: On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote: On Sun, 15 Jul 2007 12:23:48 +0200 Bart Martens <[EMAIL PROTECTED]> wrote: On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: I think it is easier for everyone if every change during sponsorship gets a new Debian version, so if you need me to sponsor packages, each upload to mentors.debian.net must use a new Debian version. That makes debian/changelog written by newbie packagers needlessly long. Why is the length of the changelog of concern? Readability and relevance for the uploaded package. If the same items are detailed overall, it is only three extra lines per change - one for the version line, one blank, one timestamp. Something like this ? packagename (0.1.0-8) unstable; urgency=low * Updated debian/watch to recognize both ".tar.gz" and ".tar.bz2", now revealing the real latest upstream release. -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 23:52:26 +0200 packagename (0.1.0-7) unstable; urgency=low * Updated debian/watch to replace any "-(rc\d+)$" by "~$1". -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 21:52:26 +0200 packagename (0.1.0-6) unstable; urgency=low * Updated debian/watch to replace "-rc4" by "~rc4". -- John Doe <[EMAIL PROTECTED]> Sun, 11 May 2007 21:52:26 +0200 packagename (0.1.0-5) unstable; urgency=low * Fixed debian/watch again. Now tested with "uscan --report-status". -- John Doe <[EMAIL PROTECTED]> Sun, 10 May 2007 21:52:26 +0200 packagename (0.1.0-4) unstable; urgency=low * Fixed debian/watch. -- John Doe <[EMAIL PROTECTED]> Sun, 08 May 2007 21:52:26 +0200 packagename (0.1.0-3) unstable; urgency=low * Added debian/watch. -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 It's not a huge problem, but it's not so nice to have all beginners mistakes logged forever for the whole world to see. I do agree with the Bart, that whatever mistakes people does when they are beginners , i think no need to see for biginners . PS:- Though i am not DD . above mentions view is my personal . Regards, Bart Martens Thanks Deepak Tripathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
Hi, IMHO it's a good idea to follow the requirements of ftp-master, it's a good practice that get used the new devoloppers to made the things in the right way, I understand the issues of this in the changelogs, but I think it's funny to see after many years the mistakes made attempting to made my first debian package (when I've adopted my first package I thought this issue mandatory). I believe that this problem is only for the first packets, then it is begun to make some most accurate jobs. I also think also that this can get used the new developers to write good changelogs and to avoid a RFS for very preliminary works. however I repeat, IMHO :) cheers, freancesco Il giorno dom, 15/07/2007 alle 13.40 +0200, Bart Martens ha scritto: > On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote: > > On Sun, 15 Jul 2007 12:23:48 +0200 > > Bart Martens <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: > > > > I think it is easier for everyone if every change > > > > during sponsorship gets a new Debian version, so if you need me to > > > > sponsor packages, each upload to mentors.debian.net must use a new > > > > Debian version. > > > > > > That makes debian/changelog written by newbie packagers needlessly > > > long. > > > > Why is the length of the changelog of concern? > > Readability and relevance for the uploaded package. > > > > > If the same items are detailed overall, it is only three extra lines > > per change - one for the version line, one blank, one timestamp. > > Something like this ? > > packagename (0.1.0-8) unstable; urgency=low > > * Updated debian/watch to recognize both ".tar.gz" and ".tar.bz2", > now revealing the real latest upstream release. > > -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 23:52:26 +0200 > > packagename (0.1.0-7) unstable; urgency=low > > * Updated debian/watch to replace any "-(rc\d+)$" by "~$1". > > -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 21:52:26 +0200 > > packagename (0.1.0-6) unstable; urgency=low > > * Updated debian/watch to replace "-rc4" by "~rc4". > > -- John Doe <[EMAIL PROTECTED]> Sun, 11 May 2007 21:52:26 +0200 > > packagename (0.1.0-5) unstable; urgency=low > > * Fixed debian/watch again. Now tested with "uscan --report-status". > > -- John Doe <[EMAIL PROTECTED]> Sun, 10 May 2007 21:52:26 +0200 > > packagename (0.1.0-4) unstable; urgency=low > > * Fixed debian/watch. > > -- John Doe <[EMAIL PROTECTED]> Sun, 08 May 2007 21:52:26 +0200 > > packagename (0.1.0-3) unstable; urgency=low > > * Added debian/watch. > > -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 > > > It's not a huge problem, but it's not so nice to have all beginners > mistakes logged forever for the whole world to see. > > Regards, > > Bart Martens -- 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: Change in my sponsorship requirements
On Sun, 2007-07-15 at 12:02 +0100, Neil Williams wrote: > On Sun, 15 Jul 2007 12:23:48 +0200 > Bart Martens <[EMAIL PROTECTED]> wrote: > > > On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: > > > I think it is easier for everyone if every change > > > during sponsorship gets a new Debian version, so if you need me to > > > sponsor packages, each upload to mentors.debian.net must use a new > > > Debian version. > > > > That makes debian/changelog written by newbie packagers needlessly > > long. > > Why is the length of the changelog of concern? Readability and relevance for the uploaded package. > > If the same items are detailed overall, it is only three extra lines > per change - one for the version line, one blank, one timestamp. Something like this ? packagename (0.1.0-8) unstable; urgency=low * Updated debian/watch to recognize both ".tar.gz" and ".tar.bz2", now revealing the real latest upstream release. -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 23:52:26 +0200 packagename (0.1.0-7) unstable; urgency=low * Updated debian/watch to replace any "-(rc\d+)$" by "~$1". -- John Doe <[EMAIL PROTECTED]> Sun, 12 May 2007 21:52:26 +0200 packagename (0.1.0-6) unstable; urgency=low * Updated debian/watch to replace "-rc4" by "~rc4". -- John Doe <[EMAIL PROTECTED]> Sun, 11 May 2007 21:52:26 +0200 packagename (0.1.0-5) unstable; urgency=low * Fixed debian/watch again. Now tested with "uscan --report-status". -- John Doe <[EMAIL PROTECTED]> Sun, 10 May 2007 21:52:26 +0200 packagename (0.1.0-4) unstable; urgency=low * Fixed debian/watch. -- John Doe <[EMAIL PROTECTED]> Sun, 08 May 2007 21:52:26 +0200 packagename (0.1.0-3) unstable; urgency=low * Added debian/watch. -- John Doe <[EMAIL PROTECTED]> Sun, 06 May 2007 21:52:26 +0200 It's not a huge problem, but it's not so nice to have all beginners mistakes logged forever for the whole world to see. Regards, Bart Martens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
Hi, On Sunday 15 July 2007, Bart Martens wrote: > > Or is this "over the top"? Maybe it needlessly complicates things for > newbie packagers... > > Non-DD's are also welcome to comment ! > a good approach in my opinion, it's: 1.0-1~rfs.1 1.0-1~rfs.2 1.0-1 version and revision for debian upload Regards, Francesco -- Francesco Cecconi ' |BrAnD| ' [EMAIL PROTECTED] GPG Key ID: 11F6E468 | Debian pkg Maintainer Key fingerprint = A45A 59F0 15F8 BF5E 41AC 8478 D931 DAA2 11F6 E468 signature.asc Description: This is a digitally signed message part.
Re: Change in my sponsorship requirements
On Sun, 15 Jul 2007 12:23:48 +0200 Bart Martens <[EMAIL PROTECTED]> wrote: > On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: > > I think it is easier for everyone if every change > > during sponsorship gets a new Debian version, so if you need me to > > sponsor packages, each upload to mentors.debian.net must use a new > > Debian version. > > That makes debian/changelog written by newbie packagers needlessly > long. Why is the length of the changelog of concern? If the same items are detailed overall, it is only three extra lines per change - one for the version line, one blank, one timestamp. I'm all for 'small is good, tiny is best' in an embedded context but then we drop the entire debian/changelog - I see little reason to worry about the length of debian/changelog in a Debian package. > I would regret that this would be enforced at mentors (I know, you did > not suggest that). True, I see no reason to make this a blanket change. Just me. > I prefer only one added block in debian/changelog > per upload to Debian, although I allow multiple blocks if the packager > wants that. e.g. in emdebian-tools, new versions are uploaded to Emdebian (v0.2.x) and new releases are uploaded to Debian (v0.x.0). It's specialised, yes, but it is perfectly usable by specifying the -v option to dpkg-buildpackage (via debuild or pdebuild if required). That way, all bugs closed in the changelog are closed with the Debian upload. (Emdebian does not have a BTS of our own.) Similarly, when using multiple mentor versions, it is just a case of collating those versions into the .changes file using -v. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpIwTcbqd2aW.pgp Description: PGP signature
Re: Change in my sponsorship requirements
On Sun, 2007-07-15 at 11:45 +0200, martin f krafft wrote: > I make use of > the new ~ character in version strings. Even more my own packages, > I'll release > > 1.0-1~unreleased.1 > 1.0-1~unreleased.2 > 1.0-1~unreleased.3 > > until it's final and I can release 1.0-1, for which I merge the > previous changelog entries. This is more work and requires more > recompiles, but it does the job without cluttering the changelog. That is a good approach, in my opinion. To make this approach more complete, the packager requesting a sponsor could package the software initially with this version and revision: 1.0~rfs.1-1~rfs.1 After each review the revision number is incremented: 1.0~rfs.1-1~rfs.2 1.0~rfs.1-1~rfs.3 1.0~rfs.1-1~rfs.4 When the .orig.tar.gz needs repackaging, then this happens: 1.0~rfs.2-1~rfs.1 1.0~rfs.3-1~rfs.1 And when it's finally allright, then the package (containing a debian/README.Debian-source) can still get this version and revision when uploaded to Debian: 1.0-1 Or is this "over the top"? Maybe it needlessly complicates things for newbie packagers... Non-DD's are also welcome to comment ! Regards, Bart Martens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
On Sun, 2007-07-15 at 10:33 +0100, Neil Williams wrote: > I think it is easier for everyone if every change > during sponsorship gets a new Debian version, so if you need me to > sponsor packages, each upload to mentors.debian.net must use a new > Debian version. That makes debian/changelog written by newbie packagers needlessly long. > This doesn't affect any other sponsor, it's just a change in how I > prefer to sponsor. True, it doesn't affect other sponsors. I would regret that this would be enforced at mentors (I know, you did not suggest that). I prefer only one added block in debian/changelog per upload to Debian, although I allow multiple blocks if the packager wants that. Regards, Bart Martens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: include aoTuV patch
Hi, Adeodato. Thanks for your answer. On Jul 08 2007, Adeodato Simó wrote: > * Rogério Brito [Sat, 07 Jul 2007 19:55:52 -0300]: > > > Besides that, what do you mean with "these characteristics"? That it > > is an "intrusive" patch? > > Intrusive, wishlist. Would there then, be the possibility of having another binary package built from the libvorbis sources producing, say, libvorbis-aotuv, for those that would prefer that as the encoder of choice? This would, indeed, be a quite nice addition to the package, especially for those that want to encode voice (I use it to encode my classes and, at quality -2, it gives superb crispness, which is not achieved by the reference encoder at level -1 or even 0). Some words like "Caution! This package contains an experimental patch" in the description of the binary package would be sufficient, I guess. Please let me know what you think. > > I get a blank page with just a link to the parent package. > > It's a Bazaar branch, so you have to retrieve it with: > > % bzr get http://bzr.debian.org/pkg-xiph/libvorbis Sorry. I am not used to bazaar. I thought that it was just like, say, websvn, where you can browse the sources without having to use a specific tool. But it was nice to learn this behavior, as this is my first contact with bazaar. :-) Thanks, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
also sprach Neil Williams <[EMAIL PROTECTED]> [2007.07.15.1133 +0200]: > I think it is about time that I changed the way I handle one element of > my sponsoring: I think that trying to retain the same Debian version > during the entire sponsorship process is prone to error and teaches bad > habits. In future, I think it is easier for everyone if every change > during sponsorship gets a new Debian version, so if you need me to > sponsor packages, each upload to mentors.debian.net must use a new > Debian version. The simplest way to do that is with 'dch -i' and then a > comment about what was fixed in this upload. This is how the Debian > archive expects everyone to handle debian/changelog so this is what I > should encourage during sponsoring. I agree and I usually adopt the same procedure, except I make use of the new ~ character in version strings. Even more my own packages, I'll release 1.0-1~unreleased.1 1.0-1~unreleased.2 1.0-1~unreleased.3 until it's final and I can release 1.0-1, for which I merge the previous changelog entries. This is more work and requires more recompiles, but it does the job without cluttering the changelog. I encourage others to do the same (or something similar). -- 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 i must confess, I was born at a very early age. -- groucho marx signature.asc Description: Digital signature (GPG/PGP)
Re: Broken uploads to mentors.debian.net
On Sunday 15 July 2007, Kel Modderman wrote: > 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. True. The sad part is that such aesthetic sentiments fly directly in the face of the technical correctness. Why should a potential package user/reviewer/whatever check/review once again the "-1" version of the source package when its changelog keep reading "Initial release (closes: #number)". Also there is no information what has been changed (or corrected) and why certain decisions have been made in the past. Having multiple "-1" versions floating around doesn't help communication, nor upgrading from previous "-1". I believe in the simple, but efficient rule => if your package has already gone public, never kill its changelog history. > 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. Correct, this is how uploading to official archive works. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Change in my sponsorship requirements
I think it is about time that I changed the way I handle one element of my sponsoring: I think that trying to retain the same Debian version during the entire sponsorship process is prone to error and teaches bad habits. In future, I think it is easier for everyone if every change during sponsorship gets a new Debian version, so if you need me to sponsor packages, each upload to mentors.debian.net must use a new Debian version. The simplest way to do that is with 'dch -i' and then a comment about what was fixed in this upload. This is how the Debian archive expects everyone to handle debian/changelog so this is what I should encourage during sponsoring. This doesn't affect any other sponsor, it's just a change in how I prefer to sponsor. Reasoning: 1. Using the same version all the time means that I have to either use a separate directory or remove all trace of the previous download before using dget -x and I would much prefer to have those other versions around - if only to ensure that I know which problems are meant to have been fixed without relying on my memory! :-) 2. Using separate versions also allows easy use of debdiff and 'interdiff -z' which are invaluable for checking exactly which files have been changed between versions. 3. Using different versions also means you usually only upload the .orig.tar.gz once so that makes it easier for slow or problematic connections. (One day, I'll get around to a checklist on people.debian.org) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpXd4gegi7OJ.pgp Description: PGP signature
