Re: Excessive wait for DAM - something needs to be done
On Wed, 16 Jul 2003, Matt Ryan wrote: > Adam Heath wrote: > > On Sun, 13 Jul 2003, Jamin W. Collins wrote: > > > > > 2000-12-17 - Eray Ozkural <[EMAIL PROTECTED]> > > >http://nm.debian.org/nmstatus.php?email=erayo%40cs.bilkent.edu.tr > > >* DAM Comment: Have asked applicant to get 5 sponsors. > > > > Read the list archives. You'll find that this person might never be > allowed > > into debian. > > FFS, yet again the big children in the playground take away the toys from > the others. I can't see why this poor person has been excluded from joining > the gang other than malicious intent from the DAM. I'm happy to be one of > the 5 sponsors if they are still interested - any other volunteers to help > show Debian is not a bunch of snobby w*nkers? This person won't be allowed in because of stonewalling from the powers that be, but because the person has demonstrated publically a multitude of times, that he is not deserving of the *privledge*. It's not everyone's god given *right* to become a developer. You have to prove your worth.
Re: cogito no longer conflicts with git or cgvg
On Fri, 10 Jun 2005, Sebastian Kuzminsky wrote: > The new cogito package (0.11.3+20050610-1) is on its way into sid. > It does not install /usr/bin/git or /usr/bin/cg, and so it does not > conflict with git or with cgvg. > > I made a note about this in /usr/share/doc/cogito/README.Debian, and I > updated the git docs to remove all the mentions of those programs. > > I guess I just prefer getting flamed by the git/cogito people rather > than the Debian people. :-/ It's not nescessary or even warranted to send emails of this kind to debian-devel whenever you upload a new package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source -i on debian native packages
On 26 Nov 2001, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. Never build a full release from the cvs work directory. Always cvs export to another directory first. Doing test builds from the cvs work dir is fine. But do final releases from a temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout is safer for repeatability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian goes wild?
On Sun, 9 Sep 2001, Joey Hess wrote: > Christian T. Steigies wrote: > > #define __NR_olduname 109 > > #define __NR_iopl /* 110 */ not supported > > #define __NR_vhangup111 > > #define __NR_idle /* 112 */ Obsolete > > #define __NR_vm86 /* 113 */ not supported > > #define __NR_wait4 114 > > > > We need to fix the kernel (again)? > > Yep, looks like exactly it. Either the kernel needs fixin, or h2ph needs > to deal with it. Actually, just h2ph. I'm fairly certain some c standard says something about comments inside #defines. >From what I recall, current standards say comments are removed first, then macros are defined/expanded. This implies this wasn't always the case. However, the kernel depends on gcc, which is recent enough to allow the above. So anything that would parse these files needs to support the same parsing semantics. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian goes wild?
On Sun, 9 Sep 2001, Joey Hess wrote: > Christian T. Steigies wrote: > > #define __NR_olduname 109 > > #define __NR_iopl /* 110 */ not supported > > #define __NR_vhangup111 > > #define __NR_idle /* 112 */ Obsolete > > #define __NR_vm86 /* 113 */ not supported > > #define __NR_wait4 114 > > > > We need to fix the kernel (again)? > > Yep, looks like exactly it. Either the kernel needs fixin, or h2ph needs > to deal with it. Er, I see. It is a kernel problem. Ignore my previous mail. 'not supported' is not inside a comment. I bet this was done to detect code that attempted to use those defines on arches that don't support it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#126434: ITP: super-sed -- An enhanced version of sed
On 26 Dec 2001, Ganesan R wrote: > 1. The source tarball is still called sed (the latest version is >sed-3.52.tar.gz). What are my options of dealing with this other than >asking upstream to change the source tarball? You can rename the source tarball when uploading to debian. No problems. > 2. I compiled with a program prefix of 's', so super sed binary will be >called ssed to differentiate it from GNU sed. I'll also use alternatives >to make this the default sed. This takes care of the binary and the man >page, however the info pages are still called sed.info, sed.info-1 :-(. You can't use alternatives in this situation, because the real said doesn't use them. alternatives can have multiple slaves, not just one, so the info pages can be linked to the main binary as the same time the manpages are linked. What you want is dpkg-divert. But I vote against diverting /usr/bin/sed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Excessive wait for DAM - something needs to be done
On Sun, 13 Jul 2003, Jamin W. Collins wrote: > 2000-12-17 - Eray Ozkural <[EMAIL PROTECTED]> >http://nm.debian.org/nmstatus.php?email=erayo%40cs.bilkent.edu.tr >* DAM Comment: Have asked applicant to get 5 sponsors. Read the list archives. You'll find that this person might never be allowed into debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Excessive wait for DAM - something needs to be done
On Wed, 16 Jul 2003, Matt Ryan wrote: > Adam Heath wrote: > > On Sun, 13 Jul 2003, Jamin W. Collins wrote: > > > > > 2000-12-17 - Eray Ozkural <[EMAIL PROTECTED]> > > >http://nm.debian.org/nmstatus.php?email=erayo%40cs.bilkent.edu.tr > > >* DAM Comment: Have asked applicant to get 5 sponsors. > > > > Read the list archives. You'll find that this person might never be > allowed > > into debian. > > FFS, yet again the big children in the playground take away the toys from > the others. I can't see why this poor person has been excluded from joining > the gang other than malicious intent from the DAM. I'm happy to be one of > the 5 sponsors if they are still interested - any other volunteers to help > show Debian is not a bunch of snobby w*nkers? This person won't be allowed in because of stonewalling from the powers that be, but because the person has demonstrated publically a multitude of times, that he is not deserving of the *privledge*. It's not everyone's god given *right* to become a developer. You have to prove your worth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian goes wild?
On Sun, 9 Sep 2001, Joey Hess wrote: > Christian T. Steigies wrote: > > #define __NR_olduname 109 > > #define __NR_iopl /* 110 */ not supported > > #define __NR_vhangup111 > > #define __NR_idle /* 112 */ Obsolete > > #define __NR_vm86 /* 113 */ not supported > > #define __NR_wait4 114 > > > > We need to fix the kernel (again)? > > Yep, looks like exactly it. Either the kernel needs fixin, or h2ph needs > to deal with it. Actually, just h2ph. I'm fairly certain some c standard says something about comments inside #defines. >From what I recall, current standards say comments are removed first, then macros are defined/expanded. This implies this wasn't always the case. However, the kernel depends on gcc, which is recent enough to allow the above. So anything that would parse these files needs to support the same parsing semantics.
Re: lintian goes wild?
On Sun, 9 Sep 2001, Joey Hess wrote: > Christian T. Steigies wrote: > > #define __NR_olduname 109 > > #define __NR_iopl /* 110 */ not supported > > #define __NR_vhangup111 > > #define __NR_idle /* 112 */ Obsolete > > #define __NR_vm86 /* 113 */ not supported > > #define __NR_wait4 114 > > > > We need to fix the kernel (again)? > > Yep, looks like exactly it. Either the kernel needs fixin, or h2ph needs > to deal with it. Er, I see. It is a kernel problem. Ignore my previous mail. 'not supported' is not inside a comment. I bet this was done to detect code that attempted to use those defines on arches that don't support it.
Re: dpkg-source -i on debian native packages
On 26 Nov 2001, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. Never build a full release from the cvs work directory. Always cvs export to another directory first. Doing test builds from the cvs work dir is fine. But do final releases from a temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout is safer for repeatability.
Re: Bug#126434: ITP: super-sed -- An enhanced version of sed
On 26 Dec 2001, Ganesan R wrote: > 1. The source tarball is still called sed (the latest version is >sed-3.52.tar.gz). What are my options of dealing with this other than >asking upstream to change the source tarball? You can rename the source tarball when uploading to debian. No problems. > 2. I compiled with a program prefix of 's', so super sed binary will be >called ssed to differentiate it from GNU sed. I'll also use alternatives >to make this the default sed. This takes care of the binary and the man >page, however the info pages are still called sed.info, sed.info-1 :-(. You can't use alternatives in this situation, because the real said doesn't use them. alternatives can have multiple slaves, not just one, so the info pages can be linked to the main binary as the same time the manpages are linked. What you want is dpkg-divert. But I vote against diverting /usr/bin/sed.
Re: Excessive wait for DAM - something needs to be done
On Sun, 13 Jul 2003, Jamin W. Collins wrote: > 2000-12-17 - Eray Ozkural <[EMAIL PROTECTED]> >http://nm.debian.org/nmstatus.php?email=erayo%40cs.bilkent.edu.tr >* DAM Comment: Have asked applicant to get 5 sponsors. Read the list archives. You'll find that this person might never be allowed into debian.
