building unstable packages with stable
I'm using sourceforge's compile farm and I'd like to know how to use it to compile packages for unstable. They use woody. I also have an account on HP's testdrive systems. Is there any reasonably easy way to do this? I know that the buildd's can take care of it, but I'd like to be able to do this myself. Even if they have gcc 3.3 how would I specify that it should be used instead of gcc 2.x (default 2.95.x on Woody)? I see that gcc-3.0 is available for woody, but 3.3 isn't... I think I'm stuck as far as the c++ abi transition goes for using sf's compile farm. Drew Daniels
Splitting a package
I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could be part of a larger .deb. The advantages however are fewer "dependencies" which I believe should be marked as "Suggests:" in the larger package. So my questions: What's a good general guideline about splitting packages these days? Split packages for these modules would defiantly have some large language "Depends:", would it be good enough for a larger package to merely suggest these or should they be recommended or even depended upon? Imo these modules wouldn't be used much. Thanks Drew Daniels
pgp 2.6.3i vs pgp5i vs gnupgp
Hi, I would like to setup a key to eventually be used for Debian related activities (the kind nm's need). I would like to use an existing version of pgp on a set of solaris systems I have access to, the problem is they have PGP version 2.6.3i. I'm unsure as to whether this is a secure version of PGP and what kinds of bugs it has in it. Reading through the Debian packages I find that pgp is up to version 2.6.3i-9, and reading it's changelog I do not see significant reason to use a version newer than 2.5.3i. The description does say it "is obsolete compared to PGP 5." I have also seen patches for 2.6.3i, but I don't know if any are necessary, or significantly useful to me. pgp5i's description says "This is version 5.0i, and has significant changes compared to 2.6.3a. You may want to consider keeping the old version handy." I don't know what any of these significant change are or why I'd still want the old version. Hmm, it also seems to have a potential bug in it's description by saying "it does not have a license for its use of the RSA cryptosystem, on which some nasty people claim a patent." I think pgp maintainers removed those kinds of strings from their package as the RSA cryptosystem patent expired? My understanding of gnupg, is that it's the same as pgp5i, but without the patented IDEA related stuff. Is the version that I have available good enough? What other benefits might a newer version provide (as related to Debian)? Below is the text I get from pgp on this Solaris system. > pgp Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 International version - not for use in the USA. Does not use RSAREF. Current time: 2003/03/17 20:09 GMT For details on licensing and distribution, see the PGP User's Guide. For other cryptography products and custom development services, contact: Philip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone +1 303 541-0140 For a usage summary, type: pgp -h Thanks Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
General programming questions list?
Hi, Where should I post general programming questions? What are some good (interactive) resources? I'm still reading the required and suggested new maintainer's documentation, so forgive me if it's pointed out somewhere. A real example should anyone be inclined to comment: In C++, I have a base class and a derived class. I want to allow operator= to be overloaded properly for my derived class such that it can have the base class assigned to it. Do I need to define derivedClass::operator=() to copy all the members and set any new members to null? Can I somehow use the operator=() function from the base class to save time (especially since the base class isn't written by me)? Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pgp 2.6.3i vs pgp5i vs gnupgp
On Mon, 17 Mar 2003, Chad Miller wrote: > On Mon, Mar 17, 2003 at 02:57:26PM -0600, Drew Scott Daniels wrote: > > I would like to setup a key to eventually be used for Debian related > > activities (the kind nm's need). I would like to use an existing version > > of pgp on a set of solaris systems I have access to, the problem is they > > have PGP version 2.6.3i. I'm unsure as to whether this is a secure version > > of PGP and what kinds of bugs it has in it. > > I think you'll want to consider using GnuPG. PGP's future is pretty > uncertain, and it was pretty bleak until extremely recently. > > About this Solaris machine, beware that you shouldn't be running anything > that you want to keep secure on a multi-user machine. Most of us keep > our keys on machines that are unreachable from the internet. A single > unpatched Solaris bug could expose your key to the world, and if you're > able to upload packages to Debian based on that key, then millions of > people could be affected by your single fsck-up. > How about for validation of PGP messages. Is the version on the solaris system good enough for validation? I've decided to carry a disk around with my key and have GnuPG on all the various single user machines that I use. I don't want to have to download messages to validate them instead of doing it on the remote server, although I do realize the minor, but real security issues involved in this too. I've also found useful information at pgpi.org since my last post. It seems that the IDEA algorithm is not in 2.6.x, but is in 5.0i and some other versions. I also found pointers to the non-free "free" pgp 8 for windows (yes, most of "my" single user machines are stuck with windows). It's license is DFSG non-free to the point at which I'm questioning it's value over GnuPG. I don't know whether IDEA adds much value yet. Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
GnuPG/gpg signature
Hi, I want to create myself a good gpg signature for use as a Debian Developer. I am uncertain as to what the best way to do this is. I'm under the impression that RSA is a better algorithm than Elg-e or DSA, and I do know about the potential incompatibilities, but I think they are few. I am thinking that I should stick with the default keysize of 1024 as I think it's good enough, and I read that keys larger than 1024 can have hash problems, but I never saw any explanation. I would like to create myself one primary key that doesn't have an e-mail address in the ID. I would then like to be able to create sub keys, but I don't quite understand what a subkey is, and the Developer's reference (iirc) warns that having more than 2 subkeys may corrupt my key on the keyservers? Would I be able to remove subkeys and replace them? I remember seeing some pgp keys with photo ID attached somehow to them and I also see gpg options for viewing photo's. I would like to be able to include a photo with my key or subkey, but I see no documentation on how to do so. I am also unsure as to whether the photo should be part of a subkey as I would like to replace it every few years to keep it current. So my questions are: Are my choices of keysize, algorithm and subkey usage good choices? What's the proper usage for and of subkeys? If possible, what's the best way to include photo ID in a key/subkey? Or even, where might I find better documentation on these? gnupg.org's website links to a manpage, mini-howto and a user-guide all of which were insufficient to answer my questions. Since I'm looking to use a subkey for debian I'm posting my questions here. I'll revert to gnupg's mailing list if my general gnupg questions can't be/aren't answered here. Thanks Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian-email@lists.debian.org
Why is [EMAIL PROTECTED] not web accessible? http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-mailing-lists-special explains why debian-private isn't accessible. Should I file a bug against the developer's reference or against lists.debian.org? I don't think I'm stating a false dichotomy, as it should either be available or explained somewhere why it is not. Imho, debian-email should be publicly accessible and a bug should be filed against lists.debian.org, but then I wonder if there's some "private" email going to debian-email that shouldn't go to [EMAIL PROTECTED] Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
search/get bug database, rc bugs excuses, closing bugs
Hi, Where might I get a copy of the bug database? Is there any way to search the bug database by text? I filed a bug (#187064 [1]) against bugs.debian.org, but I want to know if there may be some kind of work around. Please note that "good" search engines cannot be used due to the robots.txt file on bugs.debian.org. I also noticed that several of the scripts on qa.debian.org that list the number of bugs for various packages do so incorrectly. They don't list merged bugs as one bug. This may cause problems with various metrics, but more importantly does the update excuses script count merged bugs as one? Is there any policy on when to close a bug besides the Developer's reference section 5.8.3 [2] section 6 which says "Once a corrected package is available in the unstable distribution, you can close the bug"? I think that release worthy (X.XrX+1) bugs should remain open until all the Debian distributions have the bug fixed. I think the distribution tags were created to encourage bugs remaining in specific distributions to remain open. The security team tracks security bugs, but there are other critical bugs that could be fixed in unstable but not allowed into testing before release. There is also the problem of packages getting rejected from proposed-updates. There is also a further problem of packages not being created to fix release worthy bugs in older distributions (like potato) which are still "supported". In all these cases it seems like policy prefers for the bugs, that these packages fix, to be closed. Has this issue been brought up before? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=187064 [2] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: search/get bug database, rc bugs excuses, closing bugs
On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote: > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote: > > Where might I get a copy of the bug database? Is there any way to search > > the bug database by text? > > Sorry, not yet, unless you have an account on master to poke around > inside /org/bugs.debian.org/spool. Would all the BTS available bugs be there? Would anything else be there? [...] > > that release worthy (X.XrX+1) bugs should remain open until all the Debian > > distributions have the bug fixed. I think the distribution tags were [...] > They were created more as a hack for release-critical bugs than anything > else, IMHO. For non-RC bugs I wouldn't worry about them. The real > solution is proper version tracking, as ever. I said "release worthy" in case the term RC missed anything. Is there a draft document talking about proper verion tracking for Debian yet? Sorry to poke, but I'm curious. I've done quite a bit of research into BTS's, trouble ticket systems, contact managers, issue tracking systems... I haven't seen any authorative opensource solutions, just conventionally used programs like sourceforge (& derivatives) and bugzilla (gnats isn't really used much from what I've seen). I'd enjoy contributing to a Debian BTS rewrite. > It's fairly simple: if a bug needs to be fixed in more than one > distribution then the maintainer should leave it open (possibly with > tags) until it has been fixed in all those distributions. Otherwise it > is left up to the maintainer's discretion to close it appropriately. > Common sense ought to apply. I agree, I just wish it said somewhere. I also wonder about proposed-updates? Should a bug remain open until the package makes it into a stable release? Perhaps the "fixed" tag should be used when a package is fixed in proposed-updates, but not yet in a stable release. Can I quote you on this issue of when to close bugs? Drew Daniels PS: I have not subscribed and would appreciate getting a cc reply to this message. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: search/get bug database, rc bugs excuses, closing bugs
On Fri, 4 Apr 2003, Colin Watson wrote: > On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote: > > On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote: > > > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote: > > > inside /org/bugs.debian.org/spool. > > Would anything else be there? > Bits and pieces of state. There are no hidden bugs, if that's what you > mean. > Is there any structure to the file(s)? Are the sorted by bug/package/srcpkg? Reading another message in this thread it seems that each bug is in a separate file, but is there any directory structure? > > used much from what I've seen). I'd enjoy contributing to a Debian BTS > > rewrite. > > I tend to take a very dim view of rewrites: I'd much rather extend and > improve existing code than get distracted by rewriting it, particularly > for tasks like this that require very few changes to existing code and > lots of new code. Also, when working with existing code you can > prototype the improvements alongside the live system for a while until > they become stable. > Working with old code at work, and hearing the occasional groan about how complicated the BTS code is makes me worry about just doing a few changes. I am however willing to do some rewriting of debbugs. > That aside, http://bugs.debian.org/~cjwatson/version-tracking.html is my > current thinking. I'm going to start prototyping the changelog parsing > Real Soon Now (I'm changing jobs in a few weeks' time, with the result > that I'll probably have a week or two in between free to hack on things > like this). At that point I'll probably know whether help is needed. > Very interesting. I'd like to comment on this and say that I think that perhaps branches should be tracked according to the distribution directories. Changes in the woody branch may not (or can't?) appear in the changelog for the unstable branch of a package. It's not clear to me what you're doing with the non-duplicated information. It would be nice to have automatic bug closing through the changelogs for each distribution though. I think the tags potato, woody, sarge and sid could all be extended. They could be used appropriately and perhaps the only additions needed would be: "Version-branch:" for each distribution instead of "Version:". "FixedVer-branch:" where branch=distribution tag, to show what fixes each branch. reportbug patched to: Include the distribution tag automatically Use "Version-branch:", instead of "Version:" Parse changelogs for each of the distributions and close bugs using the "FixedVer-branch:" field as well as removing the tag for that distribution and if there are no distribution tags left close the bug? And another nice feature to have would be to allow viewing of bugs by distribution. I imagine these changes might be seem unnecessary, but I wanted to get my two bits in on what colour the bike shed should be [1]. [1] http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers Thanks Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
building unstable packages with stable
I'm using sourceforge's compile farm and I'd like to know how to use it to compile packages for unstable. They use woody. I also have an account on HP's testdrive systems. Is there any reasonably easy way to do this? I know that the buildd's can take care of it, but I'd like to be able to do this myself. Even if they have gcc 3.3 how would I specify that it should be used instead of gcc 2.x (default 2.95.x on Woody)? I see that gcc-3.0 is available for woody, but 3.3 isn't... I think I'm stuck as far as the c++ abi transition goes for using sf's compile farm. Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Splitting a package
I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could be part of a larger .deb. The advantages however are fewer "dependencies" which I believe should be marked as "Suggests:" in the larger package. So my questions: What's a good general guideline about splitting packages these days? Split packages for these modules would defiantly have some large language "Depends:", would it be good enough for a larger package to merely suggest these or should they be recommended or even depended upon? Imo these modules wouldn't be used much. Thanks Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pgp 2.6.3i vs pgp5i vs gnupgp
Hi, I would like to setup a key to eventually be used for Debian related activities (the kind nm's need). I would like to use an existing version of pgp on a set of solaris systems I have access to, the problem is they have PGP version 2.6.3i. I'm unsure as to whether this is a secure version of PGP and what kinds of bugs it has in it. Reading through the Debian packages I find that pgp is up to version 2.6.3i-9, and reading it's changelog I do not see significant reason to use a version newer than 2.5.3i. The description does say it "is obsolete compared to PGP 5." I have also seen patches for 2.6.3i, but I don't know if any are necessary, or significantly useful to me. pgp5i's description says "This is version 5.0i, and has significant changes compared to 2.6.3a. You may want to consider keeping the old version handy." I don't know what any of these significant change are or why I'd still want the old version. Hmm, it also seems to have a potential bug in it's description by saying "it does not have a license for its use of the RSA cryptosystem, on which some nasty people claim a patent." I think pgp maintainers removed those kinds of strings from their package as the RSA cryptosystem patent expired? My understanding of gnupg, is that it's the same as pgp5i, but without the patented IDEA related stuff. Is the version that I have available good enough? What other benefits might a newer version provide (as related to Debian)? Below is the text I get from pgp on this Solaris system. > pgp Pretty Good Privacy(tm) 2.6.3i - Public-key encryption for the masses. (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18 International version - not for use in the USA. Does not use RSAREF. Current time: 2003/03/17 20:09 GMT For details on licensing and distribution, see the PGP User's Guide. For other cryptography products and custom development services, contact: Philip Zimmermann, 3021 11th St, Boulder CO 80304 USA, phone +1 303 541-0140 For a usage summary, type: pgp -h Thanks Drew Daniels
General programming questions list?
Hi, Where should I post general programming questions? What are some good (interactive) resources? I'm still reading the required and suggested new maintainer's documentation, so forgive me if it's pointed out somewhere. A real example should anyone be inclined to comment: In C++, I have a base class and a derived class. I want to allow operator= to be overloaded properly for my derived class such that it can have the base class assigned to it. Do I need to define derivedClass::operator=() to copy all the members and set any new members to null? Can I somehow use the operator=() function from the base class to save time (especially since the base class isn't written by me)? Drew Daniels
Re: pgp 2.6.3i vs pgp5i vs gnupgp
On Mon, 17 Mar 2003, Chad Miller wrote: > On Mon, Mar 17, 2003 at 02:57:26PM -0600, Drew Scott Daniels wrote: > > I would like to setup a key to eventually be used for Debian related > > activities (the kind nm's need). I would like to use an existing version > > of pgp on a set of solaris systems I have access to, the problem is they > > have PGP version 2.6.3i. I'm unsure as to whether this is a secure version > > of PGP and what kinds of bugs it has in it. > > I think you'll want to consider using GnuPG. PGP's future is pretty > uncertain, and it was pretty bleak until extremely recently. > > About this Solaris machine, beware that you shouldn't be running anything > that you want to keep secure on a multi-user machine. Most of us keep > our keys on machines that are unreachable from the internet. A single > unpatched Solaris bug could expose your key to the world, and if you're > able to upload packages to Debian based on that key, then millions of > people could be affected by your single fsck-up. > How about for validation of PGP messages. Is the version on the solaris system good enough for validation? I've decided to carry a disk around with my key and have GnuPG on all the various single user machines that I use. I don't want to have to download messages to validate them instead of doing it on the remote server, although I do realize the minor, but real security issues involved in this too. I've also found useful information at pgpi.org since my last post. It seems that the IDEA algorithm is not in 2.6.x, but is in 5.0i and some other versions. I also found pointers to the non-free "free" pgp 8 for windows (yes, most of "my" single user machines are stuck with windows). It's license is DFSG non-free to the point at which I'm questioning it's value over GnuPG. I don't know whether IDEA adds much value yet. Drew Daniels
GnuPG/gpg signature
Hi, I want to create myself a good gpg signature for use as a Debian Developer. I am uncertain as to what the best way to do this is. I'm under the impression that RSA is a better algorithm than Elg-e or DSA, and I do know about the potential incompatibilities, but I think they are few. I am thinking that I should stick with the default keysize of 1024 as I think it's good enough, and I read that keys larger than 1024 can have hash problems, but I never saw any explanation. I would like to create myself one primary key that doesn't have an e-mail address in the ID. I would then like to be able to create sub keys, but I don't quite understand what a subkey is, and the Developer's reference (iirc) warns that having more than 2 subkeys may corrupt my key on the keyservers? Would I be able to remove subkeys and replace them? I remember seeing some pgp keys with photo ID attached somehow to them and I also see gpg options for viewing photo's. I would like to be able to include a photo with my key or subkey, but I see no documentation on how to do so. I am also unsure as to whether the photo should be part of a subkey as I would like to replace it every few years to keep it current. So my questions are: Are my choices of keysize, algorithm and subkey usage good choices? What's the proper usage for and of subkeys? If possible, what's the best way to include photo ID in a key/subkey? Or even, where might I find better documentation on these? gnupg.org's website links to a manpage, mini-howto and a user-guide all of which were insufficient to answer my questions. Since I'm looking to use a subkey for debian I'm posting my questions here. I'll revert to gnupg's mailing list if my general gnupg questions can't be/aren't answered here. Thanks Drew Daniels
debian-email@lists.debian.org
Why is [EMAIL PROTECTED] not web accessible? http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-mailing-lists-special explains why debian-private isn't accessible. Should I file a bug against the developer's reference or against lists.debian.org? I don't think I'm stating a false dichotomy, as it should either be available or explained somewhere why it is not. Imho, debian-email should be publicly accessible and a bug should be filed against lists.debian.org, but then I wonder if there's some "private" email going to debian-email that shouldn't go to [EMAIL PROTECTED] Drew Daniels
search/get bug database, rc bugs excuses, closing bugs
Hi, Where might I get a copy of the bug database? Is there any way to search the bug database by text? I filed a bug (#187064 [1]) against bugs.debian.org, but I want to know if there may be some kind of work around. Please note that "good" search engines cannot be used due to the robots.txt file on bugs.debian.org. I also noticed that several of the scripts on qa.debian.org that list the number of bugs for various packages do so incorrectly. They don't list merged bugs as one bug. This may cause problems with various metrics, but more importantly does the update excuses script count merged bugs as one? Is there any policy on when to close a bug besides the Developer's reference section 5.8.3 [2] section 6 which says "Once a corrected package is available in the unstable distribution, you can close the bug"? I think that release worthy (X.XrX+1) bugs should remain open until all the Debian distributions have the bug fixed. I think the distribution tags were created to encourage bugs remaining in specific distributions to remain open. The security team tracks security bugs, but there are other critical bugs that could be fixed in unstable but not allowed into testing before release. There is also the problem of packages getting rejected from proposed-updates. There is also a further problem of packages not being created to fix release worthy bugs in older distributions (like potato) which are still "supported". In all these cases it seems like policy prefers for the bugs, that these packages fix, to be closed. Has this issue been brought up before? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=187064 [2] http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping Drew Daniels
Re: search/get bug database, rc bugs excuses, closing bugs
On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote: > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote: > > Where might I get a copy of the bug database? Is there any way to search > > the bug database by text? > > Sorry, not yet, unless you have an account on master to poke around > inside /org/bugs.debian.org/spool. Would all the BTS available bugs be there? Would anything else be there? [...] > > that release worthy (X.XrX+1) bugs should remain open until all the Debian > > distributions have the bug fixed. I think the distribution tags were [...] > They were created more as a hack for release-critical bugs than anything > else, IMHO. For non-RC bugs I wouldn't worry about them. The real > solution is proper version tracking, as ever. I said "release worthy" in case the term RC missed anything. Is there a draft document talking about proper verion tracking for Debian yet? Sorry to poke, but I'm curious. I've done quite a bit of research into BTS's, trouble ticket systems, contact managers, issue tracking systems... I haven't seen any authorative opensource solutions, just conventionally used programs like sourceforge (& derivatives) and bugzilla (gnats isn't really used much from what I've seen). I'd enjoy contributing to a Debian BTS rewrite. > It's fairly simple: if a bug needs to be fixed in more than one > distribution then the maintainer should leave it open (possibly with > tags) until it has been fixed in all those distributions. Otherwise it > is left up to the maintainer's discretion to close it appropriately. > Common sense ought to apply. I agree, I just wish it said somewhere. I also wonder about proposed-updates? Should a bug remain open until the package makes it into a stable release? Perhaps the "fixed" tag should be used when a package is fixed in proposed-updates, but not yet in a stable release. Can I quote you on this issue of when to close bugs? Drew Daniels PS: I have not subscribed and would appreciate getting a cc reply to this message.
Re: search/get bug database, rc bugs excuses, closing bugs
On Fri, 4 Apr 2003, Colin Watson wrote: > On Thu, Apr 03, 2003 at 06:52:47PM -0600, Drew Scott Daniels wrote: > > On Fri, 4 Apr 2003 00:39:34 +0100, Colin Watson wrote: > > > On Thu, Apr 03, 2003 at 01:19:54PM -0600, Drew Scott Daniels wrote: > > > inside /org/bugs.debian.org/spool. > > Would anything else be there? > Bits and pieces of state. There are no hidden bugs, if that's what you > mean. > Is there any structure to the file(s)? Are the sorted by bug/package/srcpkg? Reading another message in this thread it seems that each bug is in a separate file, but is there any directory structure? > > used much from what I've seen). I'd enjoy contributing to a Debian BTS > > rewrite. > > I tend to take a very dim view of rewrites: I'd much rather extend and > improve existing code than get distracted by rewriting it, particularly > for tasks like this that require very few changes to existing code and > lots of new code. Also, when working with existing code you can > prototype the improvements alongside the live system for a while until > they become stable. > Working with old code at work, and hearing the occasional groan about how complicated the BTS code is makes me worry about just doing a few changes. I am however willing to do some rewriting of debbugs. > That aside, http://bugs.debian.org/~cjwatson/version-tracking.html is my > current thinking. I'm going to start prototyping the changelog parsing > Real Soon Now (I'm changing jobs in a few weeks' time, with the result > that I'll probably have a week or two in between free to hack on things > like this). At that point I'll probably know whether help is needed. > Very interesting. I'd like to comment on this and say that I think that perhaps branches should be tracked according to the distribution directories. Changes in the woody branch may not (or can't?) appear in the changelog for the unstable branch of a package. It's not clear to me what you're doing with the non-duplicated information. It would be nice to have automatic bug closing through the changelogs for each distribution though. I think the tags potato, woody, sarge and sid could all be extended. They could be used appropriately and perhaps the only additions needed would be: "Version-branch:" for each distribution instead of "Version:". "FixedVer-branch:" where branch=distribution tag, to show what fixes each branch. reportbug patched to: Include the distribution tag automatically Use "Version-branch:", instead of "Version:" Parse changelogs for each of the distributions and close bugs using the "FixedVer-branch:" field as well as removing the tag for that distribution and if there are no distribution tags left close the bug? And another nice feature to have would be to allow viewing of bugs by distribution. I imagine these changes might be seem unnecessary, but I wanted to get my two bits in on what colour the bike shed should be [1]. [1] http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers Thanks Drew Daniels
NUM request procedure
Hi, What would be the proper procedure for requesting an NMU? Assuming that all the conditions are met as described in http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu and it's sub sections, except that the person desiring the NMU is not a debian developer, would it be appropriate to bother a Debian developer to do an NMU? Who should be bothered with this request? My answer so far has been Colin Watson is the person to bug, but then I don't want to flood him with work, annoy him with requests... He's just stepped forward allot in all the different forums that I've looked at for NMU's. I've found that sometimes there doesn't seem to be a correct forum and that's part of my problem. For "public" security bugs I would bug the Security Team, but they seem overworked and may be getting frustrated going through my requests... I've started trying to write patches, fix up bugs to be more accurate, investigate vulnerabilities... I'm not a Debian developer and I haven't yet got into creating debs... There was the whole issue with NM's fixing bugs described in the thread http://lists.debian.org/debian-mentors/2003/debian-mentors-200304/msg00166.html too... For now I'll keep on doing what I'm doing and post NMU requests here when I don't see a more appropriate forum. Drew Daniels
Re: The Debian Mentors Project
I'm glad to see this service. The Developer's Reference lists http://www.internatif.org/bortzmeyer/debian/sponsor/ as being a place to co-ordinate the sponsoring of packages. Currently it's unavailable to me (down?). Other problems I have with it include: no place to upload packages and it's for "Sponsorship of future Debian developers". It's a great resource, but "The Debian Mentors Project" takes things a few steps further. mentors.debian.net provides a place to put packages and a chance for people to use the Debian system for uploading packages (dupload, dput...). It also allows for a chance to practice using keys and signing packages properly. Alioth takes things in a different direction. Alioth allows non-Dd's to contribute directly to an active project and provides space to put packages. Alioth can be thought of as a better spot for packages as it doesn't easily allow for apt-get lines. Alioth does not allow for (afaik) the usage of dput and dupload which is good practice for people who want to become a Debian developer. Alioth doesn't seem to require that its users want to become Debian developers. Drew Daniels
