Re: Linux Core Consortium
* Brian Nelson ([EMAIL PROTECTED]) [041210 19:55]: > Yup. There's never been a sense of urgency. The RM's throw out release > dates and goals every once in a while, but no one seems to take those > seriously. Not true. (And, perhaps you noticed, the release team avoided to give specific days in the last time, and the timeline depends on a day N.) > And probably for good reason. Remarks like this _are_ driving the release back. > For the second straight > release, when we've gotten to a point that it seemed we were nearly > ready for a release, we then discover we have no security autobuilders. > The release then gets pushed back a few more months, while the plebeian > developers sit around twiddling their thumbs unable to help wondering > why the hell no one thought to set up the autobuilders in the 2+ years > we've been preparing a release. Be assured, the setting up the security autobuilders are a topic since I'm following the process of releasing sarge closely. Like e.g. in http://lists.debian.org/debian-devel-announce/2004/08/msg3.html which tells us that we need them for being able to freeze. Or, a bit later, http://lists.debian.org/debian-devel-announce/2004/09/msg5.html. This even tells: | The bad news is that we still do not have an ETA for the | testing-security autobuilders to be functional. This continues to be | the major blocker for proceeding with the freeze I don't think this mean that we suddenly discover it, but as other issues were more prominently blockers e.g. in July (like the toolchain), those issues were resolved back in September (and are still resolved now). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: "Why is package X not in testing yet" - where's the page
* Frank Küster ([EMAIL PROTECTED]) [041209 17:25]: > I used to check testing migration with the link > > http://bjorn.haxx.se/debian/testing.pl > > but the host is no longer found. Does anybody know whether this is just > a temporary problem? Or is there an alternative site? Both nameservers (which are just one ip-adresses next to each other) are not found currently. If the author wants, I'd offer secondary DNS servers. Also, we might perhaps consider to integrate these scripts into pts or on release.d.o. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: charsets in debian/control
* Roger Leigh ([EMAIL PROTECTED]) [041207 00:40]: > I think going to UTF-8 as the default locale charmap for all locales > is a feasable goal for etch, as is recoding everything to UTF-8 (where > it makes sense). "feasable goal" and "etch" are the magic words I think: I agree on that, but I don't want to claim that we are already there today. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Debian's status as a legal entity and how it could effect a potential defense.
* Hamish Moffatt ([EMAIL PROTECTED]) [041206 13:45]: > Having said that, this package doesn't really advance Debian in any > way. It won't gain us any users [...]. And that's the reason why I think it should not be included. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug #277824; is the hotkeys maintainer dead?
* Thomas Folz-Donahue ([EMAIL PROTECTED]) [041206 04:00]: > Where is Anthony Wong? > [...] > debian-developers, now I turn to you. Where is Anthony Wong, and how > can I get this feature-restoring patch in the hotkeys package? Please see http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa for how to deal with such issues. The maintainer is currently un-available, so you need some Developer who does a NMU. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: charsets in debian/control
* Josselin Mouette ([EMAIL PROTECTED]) [041205 13:05]: > Le dimanche 05 décembre 2004 à 11:43 +0100, Andreas Barth a écrit : > > I think most of us agree that non-UTF-8-characters are not a good idea > > (please note the UTF-8-characters is a superset of ASCII). For some > > places (like package names), I think most of us even agree that only > > ASCII-characters should be used. Also, there is the proposal that in > > other fields (i.e. names), an translation should (also) be used if the > > characters are not in some basic classes (more or less: ASCII plus > > ASCII-similar letters). > > > > So, I personally consider non-UTF-8-characters an bug, and > > UTF-8-not-ASCII on the way from bug to allowed. > > Many of us have names that can't be written using ASCII. Furthermore, > the Debian tools need consistency between the developer name in the > changelog and the Maintainer/Uploaders fields in the control file. The > only way for these developers to have a policy-compliant changelog > without having their uploads considered as NMUs is to encode the control > file in UTF-8. Though I agree on your last statement (and please, remember, I'm from germany where non-ASCII-characters are also in common use), I still consider that UTF-8-not-ASCII has not finally reached ok, but it's on the way to it (and I consider this a good thing). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: charsets in debian/control
* Petter Reinholdtsen ([EMAIL PROTECTED]) [041205 11:30]: > [Peter Samuelson] > > We seem to be moving to a de facto standard of UTF-8 for non-ASCII > > characters in debian/control files. This is not specified in Policy > > [1], but for hopefully obvious reasons, consistency is a Good Thing, > > and UTF-8 seems to be the best solution for this sort of thing. > Some will argue that only ASCII is acceptable in debian/control files. > I am not one of these. > > I agree that we should standardise on UTF-8 for both the changelog and > the control file (and the copyright file, for the upstream author and > package author names). We need to be able to correctly represent the > names of people, and it can not be done using ASCII only. > > Good to see that most packages already uses UTF-8. I hope the > packages using other charsets can be converted to UTF-8 as soon as > possible. There are different way to view that, and there is a policy bug about that very topic. I think most of us agree that non-UTF-8-characters are not a good idea (please note the UTF-8-characters is a superset of ASCII). For some places (like package names), I think most of us even agree that only ASCII-characters should be used. Also, there is the proposal that in other fields (i.e. names), an translation should (also) be used if the characters are not in some basic classes (more or less: ASCII plus ASCII-similar letters). So, I personally consider non-UTF-8-characters an bug, and UTF-8-not-ASCII on the way from bug to allowed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#284283: ITP: fairuse -- spam filter based on sender identity verification
* Stephen Birch ([EMAIL PROTECTED]) [041205 09:10]: > Package: wnpp > Severity: wishlist > > * Package name: fairuse > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ If you don't mind to update this information, it might be good :) > * License : Free for non-commercial use means non-free, right? > Description : spam filter based on sender identity verification > > Subject to license verification (DFSG compliant): > > FairUCE is a spam filter that prevents spam from reaching the > recipient's inbox by verifying the identity of the sender. It will stop > the vast majority of spam without the use of a content filter, and > without requiring a probable spam or bulk folder that needs to be > checked periodically. Is the name FairUCE or fairuse? And, what is the major advantage over e.g. using SPF? (In other words: In which way is the verification done?) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#284219: please remove gnu-standards
* Glenn Maynard ([EMAIL PROTECTED]) [041204 22:25]: > 2004-004 is not "allow non-free documentation in main for Sarge; we > don't care"; it's "allow non-free documentation in main because we don't > have time before Sarge to deal with it all". In no way does it discourage > maintainers with the time and inclination to deal with it before Sarge > from doing so. Well, handling it in a good way is of course appreciated, one way you proposed yourself: > (I'd suggest that gnu-standards be moved to non-free, though, not removed.) Just dropping on the floor is not appreciated. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#284219: please remove gnu-standards
* Ben Pfaff ([EMAIL PROTECTED]) [041204 18:25]: > Package: ftp.debian.org > Version: 2004-12-04 > > Please remove the gnu-standards package (that I maintain). Its > use of the GNU FDL violates Debian's DFSG, so it cannot remain in > the distribution. I think it might be a good thing if you orphan this package before you ask for removal, especially as you (and we all) know that GFDL-docu is allowed in the upcoming release of sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Christian Perrier ([EMAIL PROTECTED]) [041202 08:15]: > As already written in -women, this is the point which saddens me the > most in this thread. I'm really disappointed by seeing most > contributors just not realize why this package, as proposed, is likely > to hurt the feelings of several women (probably not all, I don't know) > as well as, indirectly or not, some men. > > I have indeed no intention for objection this package in any > matter. I'd just hope that the maintainer proposing it realizes that, > though he personnally doesn't think so, his work may hurt some people. > > Legal nitpicking is another issue, which I personnally do not consider > the most important one, indeed. > > The package is currently sexist, in my opinion. I just hope that > saying this loud enough will make the maintainers change their > mind. If it does not, well the result will be another sexist thing in > free software. > > I someday wish I had an opportunity to talk of this with Bruno > Bellamy, by the way (the artist whose drawings are used in this > package). His artwork (and good work) is widely used in the free software > community in France and (personal opinion, still) may sometime ring > this bell of sexism. I think you described the important issues quite well. Making a good distribution is more than just "upload any package which you legally could". Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283751: ITP: fakepop -- fake pop3 server to warn users that only pop3-ssl is available
* Ron Johnson ([EMAIL PROTECTED]) [041201 12:40]: > On Wed, 2004-12-01 at 22:25 +1100, Matthew Palmer wrote: > > On Wed, Dec 01, 2004 at 05:17:33AM -0600, Ron Johnson wrote: > > > On Wed, 2004-12-01 at 11:04 +, Steve McIntyre wrote: > > > > So, let me get this straight - fakepop will allow people to log in > > > > (using their username and password) in the clear and THEN tell them > > > > that they should have used POP over SSL instead. Quite how is this > > > > better than "connection refused"? > > > Read the description: > > > "You can customize messages in /etc/fakepop/ directory to teach > > > your users how they should configure their mail clients to use > > > pop3-ssl instead of pop3" > > So I can put "All your mail is belong to us" in my /etc/fakepop/ directory, > > so that people know that their passwords *have* been successfully sent in > > the clear before being told to reconfigure their mail client? Well, *I'm* > > comforted. > But since the password isn't valid, does it make much difference? > > For example, my pop3 password isn't the same as my GnuPG passphrase. Well, but the probability that users who mis-use pop3 instead of pop3-ssl use their pop3-ssl password for pop3 is quite high. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
* Steve McIntyre ([EMAIL PROTECTED]) [041201 12:20]: > Rather than argue about morality, legality, whatever, shouldn't we be > considering this in other terms - simple usefulness? Instead of asking > "why shouldn't this go into Debian?", ask "why _should_ this go into > Debian?". > > We seem to have a growing and worrying trend to pick up any random > free software and add it to the distribution without considering > whether it's actually useful or not... Agreed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay ([EMAIL PROTECTED]) [041116 16:50]: > On Tue, Nov 16, 2004 at 03:01:03PM +0100, Andreas Barth wrote: > > I agree with you that fixing is only required if this might be a problem > > for upgrades from woody. As this bug report is quite young, I think the > > best thing really is to give the maintainer enough time to take a look > > at it, and decide whether this needs to be fixed first (and if, how) or > > not. > I don't recommend 3.0.1 go into sarge. 3.0.2 will be released shortly, > and that fixes a few more bugs that should make it mature enough. I understand this as that I should keep my block hint, and once 3.0.2 has survived 10 days in unstable, it will automatically go in? > This bug, specifically [...] I trust you as maintainer that you do the right thing. I just saw this bug on skimming through the bug list, and wanted to know your opinion on it. Thanks for your explanation. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) [041116 14:55]: > On Tue, 16 Nov 2004, Andreas Barth wrote: > > * Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: > > > On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: > > > > Given that SA3 is a major change, and we had massive memory issues with > > > > the previous upload, the transfer to sarge is a bit delayed. I expect > > > > that SA3 will go in one of these days, and it is _definitly_ on my > > > > direct watch list. > > > FWIW, we've run SA3 here (with a couple thousand users) in a woody > > > backport > > > for almost a week now, with no problems. This is of course not to say > > > there > > > is no bugs... :-) > > This is definitly one of the good news, and together with the other good > > news I was almost convinced to let SA3 through. However, I'm not too > > sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I > > would like some feedback from the maintainer. > IMHO it only *has* to be fixed in sarge if it affects upgrades from > 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be > enough. I agree with you that fixing is only required if this might be a problem for upgrades from woody. As this bug report is quite young, I think the best thing really is to give the maintainer enough time to take a look at it, and decide whether this needs to be fixed first (and if, how) or not. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Steinar H. Gunderson ([EMAIL PROTECTED]) [041116 12:30]: > On Tue, Nov 16, 2004 at 10:54:44AM +0100, Andreas Barth wrote: > > Given that SA3 is a major change, and we had massive memory issues with > > the previous upload, the transfer to sarge is a bit delayed. I expect > > that SA3 will go in one of these days, and it is _definitly_ on my > > direct watch list. > FWIW, we've run SA3 here (with a couple thousand users) in a woody backport > for almost a week now, with no problems. This is of course not to say there > is no bugs... :-) This is definitly one of the good news, and together with the other good news I was almost convinced to let SA3 through. However, I'm not too sure if bug 279981 needs to be solved prior to SA3 going to sarge, and I would like some feedback from the maintainer. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
Hi, * Ramunas Vabolis ([EMAIL PROTECTED]) [041116 09:15]: > I was wondering too, why there is no SA3 in sarge yet. A friend of mine > asked to write a couple words about this new version from a system > administrator view. Given that SA3 is a major change, and we had massive memory issues with the previous upload, the transfer to sarge is a bit delayed. I expect that SA3 will go in one of these days, and it is _definitly_ on my direct watch list. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
* Marc Haber ([EMAIL PROTECTED]) [041113 19:20]: > On Sat, 13 Nov 2004 14:53:25 +0100, Martin Schulze <[EMAIL PROTECTED]> > wrote: > >Adrian 'Dagurashibanipal' von Bidder wrote: > >> Will the start of official security support for sarge be announced widely, > >> to get as much testing as possible? (Like: general debian-announce, press > >> contacts, ...) > >No. Why should it? > Because it was widely announced to start on September 15, and many > people are already running sarge. We learned from that mistake, and don't announce any fixed dates until we have it working (and, BTW, we announced also that we won't make it at that date - but I also know that enough magazines have just ignored that). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)
* Santiago Vila ([EMAIL PROTECTED]) [041113 15:25]: > On Sat, 13 Nov 2004, Martin Schulze wrote: > > Adrian 'Dagurashibanipal' von Bidder wrote: > > > On Tuesday 09 November 2004 23.44, Colin Watson wrote: > > > > N+0 days > > > > Official security support for sarge begins > > > > > > Will the start of official security support for sarge be announced > > > widely, > > > to get as much testing as possible? (Like: general debian-announce, press > > > contacts, ...) > > > > No. Why should it? The new release of Debian will be widely announce. > > > > How do you want to test official security support? Suddenly discover > > loads of vulnerabilities? > The day it is officially known that security support exist for sarge, > lots of people will migrate their servers to sarge, even if it is not > released as stable yet, so yes, it would be interesting that it is > announced, widely or not, so that sarge (not the security support) > get as much testing as possible before the release. Be sure that we take care that as much testing as possible is done before the final release. But - as we don't know when what will happen, it is a bad idea to promise certain actions on certain days now. (Of course, we know that a lot of users will upgrade as soon as security support is in place - I'll do the same with my servers. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#280675: ITP: l2tpns
* Jonathan McDowell ([EMAIL PROTECTED]) [041112 15:10]: > On Wed, Nov 10, 2004 at 10:34:04PM +, Jonathan McDowell wrote: > > * Package name: l2tpns > > Version : 2.0.5 > > Upstream Author : David Parrish and others <[EMAIL PROTECTED]> > > * URL : http://l2tpns.sf.net/ > > * License : GPL > > Description : L2TP LNS which does not require l2tpd, pppd or any > > kernel patches. > > > >L2TPNS is half of a complete L2TP implementation. It supports only > >the LNS side of the connection. > > > >L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2 > > protocol > >(e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS > > implements > >PPP over L2TP only. > > > >Also supports ISP features like speed throttling, walled garden, usage > >accounting, and more. > Please stop following up to this ITP and telling me you don't understand > the description unless you have prior experience of L2TP in an ISP > environment. If you don't know what L2TP is or how an LNS fits into the > picture, then this package probably isn't for you. I don't believe any > of the terms used should be alien to the sort of person this package > will be of use to. Frankly speaking, the description should make sense for people who _don't_ have a clue about the topic - and even if only telling them that they should ignore the package. So, perhaps add something like L2TPNS is the implementation of the internet services provider (ISP) side of L2TP, i.e. it supports LNS. If you are not an ISP, you won't need it. For some more ideas, please see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: G++ in sarge.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [041112 12:20]: > I would like to know if the Debian community is really going to release > Sarge with G++ 3.3.x as the default C++ compiler. > > My question stems from the fact that Sarge will probably be the only > stable release in the next year or two, that Sarge's packages C++ code > is compiled against libstdc++5, and that that library is unable to cope > with file streams longer than 2 Gb. > > I think the answer to this question ---only relevant for me, probably--- > could be a simple "yes" or "no", without making any noise and without > wasting developers' time in futile discussion. Sarges toolchain is frozen, and if we want to release at all, the answer is: Sarge will release with gcc-3.3 as default compiler, but gcc-3.4 is also included. However, I really hope that we manage to release etch a bit faster than sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
spamassassin3 - is memory usage ok now?
Hi, I can remember some people complained that spamassassin3 had increased ressource usage. For the people who had problems: Are they fixed now with the new release that appeared in unstable? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: more current iproute
* Milan P. Stanic ([EMAIL PROTECTED]) [041110 12:35]: > Why version is iproute_20041019 while the upstream is > iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is > appended to serve as timestamp, I think. Because changing the version format would be a bad think in a NMU. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
more current iproute
Dear all, I uploaded the current version of iproute (that also works with current 2.6-kernels) to experimental. As this is a major change, any test reports are appreciated. Also, a review of the source whether I managed to keep all security patches might be a good idea (I'm quite confident that I did, but - a independent look might be a good thing). Please note that I'm aware that the package documentation is not in the best state, but as this was a NMU, I didn't do the changes that I would have done with a normal maintainer upload. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NMU on sysklogd
* Jerome Warnier ([EMAIL PROTECTED]) [041028 15:25]: > It is really annoying since every log analysis tool is failing on this > every week at least? By "log analysis tool" I mean anything relying on > files in /var/log to do something. > [..] > Could someone go through the list and NMU this? I'm willing to help, if > necessary. For Bug 275111 - I think this bug needs a proper explanaition / patch, because that's the only way to fix it. In general: sysklogd is already frozen for release of sarge. So, please don't upload _anything_ which won't make it for sarge, i.e. only RC-bug fixes. Changes like using /etc/defaults might be nice, but are not possible any more for sarge. (And, I guess that the maintainer might do a cleanup round after release of sarge.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [041028 22:00]: > Also note that there are _many_ patches in the BTS for RC (and many other > bugs). But RC bugs do not get fixed in time [0] this also shows that a > number of packages are not being properly maintained and we maybe could > maybe think a way to force the maintainer to give over maintainership if he > is overloaded with other work and he cannot fix the package in time. I plan to go through the packages that are not released with sarge, and propose to orphan / delete some / most of them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Versioned bugs in the BTS (was: Drop testing)
* Frank Küster ([EMAIL PROTECTED]) [041028 17:00]: > Matthias Urlichs <[EMAIL PROTECTED]> wrote: > > Besides, we'll have a bug database which tracks version numbers. This in > > turn means that we have a nice distinction between bugs that are actually > > RC in the "fix this if we'd want to release Etch tomorrow" sense, and bugs > > that are RC in the "keep this out of testing" sense. > This sounds great, and I heard that it has been promised for after the > sarge release, sounding as if it was implemented yet. Is the counterpart > also implemented, namely testing scripts that take this information into > account? The implementation of version in the BTS is done so that the second is not _so_ hard to implement (speaking as someone who has seen lots of parts of britney). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Jan Nieuwenhuizen ([EMAIL PROTECTED]) [041028 14:05]: > Thomas Bushnell writes: > > So the RC bugs should not be blocking release unless they are *new* RC > > bugs which don't already exist. > I'd word that a bit differently: the definition of an RC bug should > *never* allow a bug still present in stable now (+ security.stable) to > reach the level of RC. We _have_ RC-bugs in woody - even RC-bugs we won't fix. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Ubuntu discussion at planet.debian.org
* Marcelo E. Magallon ([EMAIL PROTECTED]) [041026 09:35]: > On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote: > > > Okay, it's a month old, but there hasn't been any since. > > > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html > > > "We are also still missing official autobuilders for > > > testing-proposed-updates on alpha and mips. All other architectures > > > appear to be keeping up with t-p-u uploads." > >Missing a buildd on an arch or too is a far cry from t-p-u > > being unsupported. > Testing is by design all-or-nothing. As long as a single architecture > hasn't buildd support for t-p-u, the buildd support for t-p-u is as > good as missing. You could do builds by hand, but then again, how many > developers actually do that? And, please don't do it. We definitly can't release without official buildds for all architectures, so please no binary-only uploads in t-p-u (if the release team would consider different, I'd have started building mips and alpha there long ago). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:10]: > At least they won't poison Sid with fresh things that may others life > more difficult. Eg. new library versions. And why should that work better than now? The developers _are_ asked to not poison sid. The advantage of testing is however that we have some chance to un-do broken actions. > > they like less than x but still more than y. So this will at least fail, > > and probably hurt debian too. > Maybe. What is the alternative? Continue with the current method and > release Edge... 2009 or so? If we could get back to facts, our main problem is _not_ that sarge is not in release-quality. Sarge is (mostly) in very good shape, and the remaining problems would be there also with your proposal. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Drop testing
* Eduard Bloch ([EMAIL PROTECTED]) [041025 15:00]: > #include > * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]: > > > > not look appear as critical for maintainer, or not important enough to > > > touch > > > package in the holy "frozzen" state). Such bugs are a disaster, they make > > > our definition of a Stable release absurd. Yes, Debian Stable has become a > > > buggy stable release. Just face it. > > > > AIUI, you propose to freeze unstable and go back to the old method of > > having updates during the freeze be manually put in at the discretion of > > the Release Managers. If we did that, how would one of these "ugly bugs" > > be any more likely to be fixed in frozen unstable than it is in today's > a) The release time would be shorter I would like to see a prove of this. > b) It would be up to humans (and not some obscure scripts) to decide whether > the bugs deseves a fix or not This is already the case. If the humans decide that a bug should be fixed, they can either just do it, or at least upgrade the bug to RC-grade. If they decide that it is actually not so bad that it requires a fix for the release, they could downgrade it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Ubuntu discussion at planet.debian.org
* Matthias Urlichs ([EMAIL PROTECTED]) [041023 23:00]: > Hi, Manoj Srivastava wrote: > > Secondly, buildd's do > > not work with experimental. > That can be fixed quite easily. In fact, my own (personal) buildds do it. Actually, I'm also building experimental packages, for mips, hppa, sparc and alpha. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: NMU for libpaper
* Hamish Moffatt ([EMAIL PROTECTED]) [041023 12:40]: > On Sat, Oct 23, 2004 at 08:43:27AM +0200, Christian Perrier wrote: > > > An NMU for a wishlist bug is questionable IMHO. The bug report for > > > hylafax-client is vague; it says that there are (tiny) differences > > > between "default" and "ISO A4" in the pagesizes file but fails to > > > explain why that's a problem. > > > > > > Rather than NMU just for this bug, you could try to contact the > > > > Rather than NMU just for this bug, also NMU for the 3 l10n bugs > > sitting in the BTS...:-) > Also all wishlist. But NMUs for l10n is accepted, and even l10n updates are pushed through to testing for freezed packages. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Ubuntu discussion at planet.debian.org
* Otavio Salvador ([EMAIL PROTECTED]) [041022 22:15]: > Sure but not we have the experimental distribution to deal with it > while we are stabilizing the unstable and testing distribution. The > current problem is experimental is not a full distribution and doesn't > have buildd systems. Actually, a lot of packages in experimental are autobuilded now (as long as they are buildable in unstable, and only on some archs). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Security updates for sarge? (was: Ubuntu discussion at planet.debian.org)
* Jan Niehusmann ([EMAIL PROTECTED]) [041022 11:10]: > Question to the security team: What's holding back security support for > sarge? (This is not a complaint - I'm just curious) There are no autobuilders for testing-security. See the latest release update http://lists.debian.org/debian-devel-announce/2004/09/msg5.html: | The bad news is that we still do not have an ETA for the | testing-security autobuilders to be functional. This continues to be | the major blocker for proceeding with the freeze; we would /like/ to | have security support in place for sarge before encouraging widespread | upgrade woody->sarge upgrade testing, but we /need/ to have it in place | before releasing, so it would be unwise to try to freeze the rest of the | archive without any confirmed schedule for the last stages of the | release. The good news is that we finalized the toolchain for sarge in the very last days. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Reproducible, precompiled .o files: what say policy+gpl?
* John Hasler ([EMAIL PROTECTED]) [041019 00:55]: > I _think_ it would also be acceptable for you to build the debs you upload > with CC=icc. I disagree to that statement. IMHO all binary packages uploaded into debian should be the same as if autobuild. Everything else produces pain for QA, security and further NMUs. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Reproducible, precompiled .o files: what say policy+gpl?
* Wouter Verhelst ([EMAIL PROTECTED]) [041019 00:40]: > On Mon, Oct 18, 2004 at 07:51:00PM +0200, Josselin Mouette wrote: > > Le lundi 18 octobre 2004 à 19:22 +0200, Wesley W. Terpstra a écrit : > > > So, when it comes time to release this and include it in a .deb, I ask > > > myself: what would happen if I included (with the C source and ocaml > > > compiler) some precompiled object files for i386? As long as the build > > > target is i386, these object files could be linked in instead of using > > > gcc to produce (slower) object files. This would mean a 2* speedup for > > > users, which is vital in order to reach line-speed. Other platforms > > > recompile as normal. > > > > > > On the other hand, is this still open source? > > > Is this allowed by policy? > > > Can this go into main? > > > > Main must be built with only packages from main. > No, that's not true. > > In addition, the packages in _main_ > * must not require a package outside of _main_ for compilation or > execution (thus, the package must not declare a "Depends", > "Recommends", or "Build-Depends" relationship on a non-_main_ > package), > > There's a difference, which is crucial. ICC may not be Free Software, > policy does not say you must only use Free Software to build a package; > it says you must not /require/ a package outside main to build it. > > The difference is subtle, but crucial. > > Wesley's software can be built using software in main. It will not be as > fast, but it will still do its job, flawlessly, without loss of > features, with the ability to modify the software to better meet one's > needs if so required. I disagree. A program is IMHO not only specified by the fact that it does certain transformations from input to output, but also by the speed it does this. If this specification can be matched by gcc, why consider using icc at all? And if not, it requires icc. (You can also consider what happens when we want to do a security update: Does the security team need to install icc, or do we want that the software runs significantly slower afterwards, and misses its specification?) If icc is required for that application, than it needs to go to contrib. If not, please compile it with gcc. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Martin Schulze ([EMAIL PROTECTED]) [041017 11:20]: > Andreas Barth wrote: > > * Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: > > > The goal should be that I, as a user, can add volatile to my > > > sources.list and periodically do an apt-get upgrade - without risking > > > to suddenly have my web browser updated to a new major release where > > > it starts behaving differently, all my users' preferences get out of > > > kilter, etc. > > I think this is one of the most important statements - and I think it > > describes our policy quite well. > > > > I could however see the possiblity to add a new package "mozilla1.7", > > that users can optionally install. However, I also won't like it. > Please be very careful with packages like these. It may require a > new version of libfoo1 and libbar2g and libbaz0g etc. which people > may accidently install, which in turn can hurt them in other areas > and contribute "strange" bug reports. As soon as it requires new versions of some libraries, this is a no-go. People who want it may go to backports.org or so. Perhaps we may add an news item on volatiles page about that then. The main word is "above all, do no harm". The default action is to not add something. > If you plan something like this, please at least use the componentised > layout of backports.org and don't pollute the main volatile archive > with this. (Still, I don't believe, such a packages incl. dependencies > should go into volatile.debian.net.) I'm definitly not adding a new package to volatile without being definitly sure that it should go in (and as long as you disagree, I'm not sure about that). And, as long as somebody thinks this polutes volatile, this also can't be the right thing. Volatile usage should be risk-free (as in security usage). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 21:00]: > Happily, Andi appears open-minded, but focused on the hard work of > doing the 'obviously right' things first. Well, I'm just waiting for maintainers to say: "Yes, please include a more uptodate version of my package foo." Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* John Hasler ([EMAIL PROTECTED]) [041011 19:55]: > Andreas Barth writes: > > I could however see the possiblity to add a new package "mozilla1.7", > > that users can optionally install. However, I also won't like it. > I see no reason for new packages to ever go into volatile. Such things > belong in backports. If we really say: "Well, we recommend to upgrade your package to the newest version.", _than_ I think adding it to volatile may be ok. However, certainly a border case, and certainly not the most important thing to start off (so, IMHO, we can just postpone the discussion about, and start with the things we all agree about). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041011 18:30]: > The goal should be that I, as a user, can add volatile to my > sources.list and periodically do an apt-get upgrade - without risking > to suddenly have my web browser updated to a new major release where > it starts behaving differently, all my users' preferences get out of > kilter, etc. I think this is one of the most important statements - and I think it describes our policy quite well. I could however see the possiblity to add a new package "mozilla1.7", that users can optionally install. However, I also won't like it. cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 15:35]: > On Mon, Oct 11, 2004 at 02:02:47PM +0200, Andreas Barth wrote: > > Of course we need to reserve the right to drop packages - but, doing > > that would still be bad. Adding a package to volatile means for me that > > we are very confident that we can support it till the current debian > > major release is archived. If we can't do that, we shouldn't have added > > it in the first place. > Hmm, deja vu ;) > > What happens to packages that become orphaned? The same that happens with them in stable. The volatile team has to keep care of them till the current debian major release is archived. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* paddy ([EMAIL PROTECTED]) [041011 12:55]: > On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > I would like 'must' keep them functional: IOW, voltaile is prepared to > drop packages from volatile that are, for whatever reason, unable to keep > up with the purpose. It would be sad if volatile ended up containing > useless packages! Of course we need to reserve the right to drop packages - but, doing that would still be bad. Adding a package to volatile means for me that we are very confident that we can support it till the current debian major release is archived. If we can't do that, we shouldn't have added it in the first place. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Florian Weimer ([EMAIL PROTECTED]) [041010 16:40]: > * Andreas Barth: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > Can volatile receive critical updates which are usually not applied to > stable because backports are not available for some reason? Are you speaking about mozilla? ;) Well, that's definitly not the first purpose of volatile, and so, I would like to postpone it a bit. However, in the long run, I think you're right about adding newer packages if they fix security issues, and we can't fix them otherwise. But I think it needs more than just some consideration how to do this in a non-breaking way. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Jesus Climent ([EMAIL PROTECTED]) [041009 11:10]: > I meant for the > kernel, which in some cases it could be tagged non automatic for updates, so > that only the package is installed if the users wishes so. Making 2.6 kernels > available for woody could have been an scenario where this approach could have > work, except for the dependencies that the new kernel requires, but still is a > good example of a possibility. Generally, new packages could be added to volatile, as long as there is a very good usage of them. However, if I see how painful security updates for the kernel currently are for the security team, I think we should better reconsider this very good - because once a package is added, we need to do security updates on it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Hi, * Francesco Paolo Lovergine ([EMAIL PROTECTED]) [041008 21:15]: > On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > > - for bugs, the normal debian bug tracking system should be used. > ... adding a volatile tag probably as for experimental? But if nothing > would be broken by volatile pkgs, probably BTS is superfluous ;-) After sarge, the BTS is able to track versions. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* martin f krafft ([EMAIL PROTECTED]) [041008 20:50]: > also sprach Marco d'Itri <[EMAIL PROTECTED]> [2004.10.08.2029 +0200]: > > Is looking up .org domains in the wrong whois server enough to be > > considered "useless"? > I found it rather useless in woody when the .org registrar changed. There are more packages that I consider rather useless than that should be included in volatile - the criterion should be what almost everybody considers useless. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Hi, * Martin Zobel-Helas ([EMAIL PROTECTED]) [041008 20:25]: > Is for example a package "whois" also a candidate for volatile? > Regestries change from time to time; i just consider .org changed within > the last 2,5 years... Well, I would start small (and this means to exclude whois), and revisit policy after some time to see what we should add or remove to it. And, furthermore, why not do the next release of whois in a way that it's possible to dynamically only update the zones (quite similar to the virus scanners definitions), perhaps downloading from some debian site once a month? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* martin f krafft ([EMAIL PROTECTED]) [041008 20:30]: > And I certainly don't think it should be volatile.debian.*net*. I'm open to changing this; however, for the start, it's easier with debian.net - same as planet that also came to life as planet.debian.net. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Duncan Findlay ([EMAIL PROTECTED]) [041008 20:10]: > On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: > > Agreed. So, this means: Backport the necessary changes. Sometimes, it's > > just not enough to only update the virus scanner definitions, because > > new functionality is needed to scan the files (just consider that a very > > new archive format gets so popular that it needs to be supported, just > > like zip now). > When spamassassin is upgraded, it's more than just the rules. Often > the method of parsing the message is changed -- leading to better > results, or support for different tests is added, etc. It would be > very difficult to only backport the appropriate changes, and the > result would be less stable than the version from which backporting > was taking place. On the other hand, each new version makes minor > changes to functionality. Well, I think, it's in the end a case-by-case decision whether it's better to take more or less a current package, und perhaps weed out some definitly unrelated changes, or to take the old package and backport some changes. Of course, in the end, the goal needs to be to make the package as useable as possible - and of course, above all, do no harm, and don't break things. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041008 19:50]: > Scripsit Andreas Barth <[EMAIL PROTECTED]> > > Some things are not so obvious: > Should volatile include updates of packages such as debian-keyring? > debian-policy and developers-reference? Pros: Well, these updates don't break any thing. Cons: There is no need to treat them special, or do security updates. Furthermore, it's easy to get them from backports.org. Perhaps, adding some information about how easy it's to get them from there would however be a good idea. (And, of course, if someone does a "developers backport collection", including keyring, developers-reference, dpatch, debhelper etc, this might also be a good collection - but this has than a different target group than volatile.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:25]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > - volatile is not "just another place" for backports, but should only > > contain changes to stable programs that are necessary to keep them > > functional; > I think your proposal looks good, but I would like to see this > particular item fleshed out more fully. In particular, what kinds of > changes are being considered here? > > In other words, would it count as "necessary" to say "new upstream > major release provides a new feature which keeps the virus scanner > useful, and also changes a bajillion unrelated things"? > > In my book, the new virus definitions would be necessary, but not the > bajillion unrelated things, and I would like to see a rule that you > could not just put in the new upstream major release merely to get the > new virus definitions. Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). And, if there are changes that should be available on stable, but not be the default (like e.g. the current spamassassin3), than they might get in as new package, not disturbing the users of the old one, but giving more choices. (Of course, even then, the package needs to be a bit more mature than the curent spamassassin3, but that's a different thing. ;) > That is, some kind of "minimal change to > preserve utility" rule, which might require the volatile-managers or > whoever to be Real Programmers and not just compilers. Of course it requires them to be Real Programmers. The job is _not_ mechanically compiling something on stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:20]: > In other words, it sounds like the whole virus-scanner bit is a red > herring, and what you actually want is just a repository that doesn't > have the stability restrictions that Debian normally has. Maybe > that's a good idea, but it needs to be argued for by something other > than "oooh, virus scanners!" This repository exists, and it's called backports.org. For the volatile archive, there _is_ one difference: The volatile archive is only for the packages that have some regression due to the fact that some time has passed - and e.g. virus scanners typically have this behaviour. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
about volatile.d.o/n
Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not "just another place" for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; - It should allow any administrator to "just use" volatile, as they "just use" security.d.o, and they should be confident that nothing is broken by that; - for bugs, the normal debian bug tracking system should be used. Some things are not so obvious: - security support: There should be security support for volatile. However, security.d.o is probably not the right place for that, and adding another task to the security-team is IMHO also not the way to go. So, this needs to be placed on the burden of the volatile team. - "releases" of volatile: One could consider to seperate volatile into a release and a staging area. An advantage would be that system administrators would only need to update on some times. However, if we restrict volatile, only upload required changes and don't have more than 10 packages in it, we don't need that. - adding volatile packages to point releases: Though it may be seen as good idea to add volatile packages at the next point release, this is currently a no-go. I can see the good reasons for that, and I accept them. Two technical questions remain open for now, and needs to be solved independend of the policy questions above. - ftp-server: Should volatile be a "normal" part of the debian ftp-server, or be setup independently (like e.g. security.d.o is)? Normal part would of course be nicer for our users (and especially mirroring is free), but requires some more work initially. However, this decision is in the domain of the ftp-masters. - architectures/buildd support (partly connected with ftp-server): Which architectures should be supported? Perhaps starting with a smaller number is a good idea, and adding more if they can cope with the updates. I added http://volatile.debian.net/ to be a placeholder for the current discussions. Also, there is a archive present on http://volatile.debian.net/debian-volatile, so if maintainers want to start adding packages, they may contact me. That's all for now. Comments and suggestions are welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
Hi,
* paddy ([EMAIL PROTECTED]) [041008 16:05]:
> On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
> > * paddy ([EMAIL PROTECTED]) [041008 15:10]:
> > > What are the pros and cons for
> > > volatile-{stable,release,or-whatever-you-call-it}
> > > as an all-at-once release model, rather than a rolling-when-its-ready
> > > model more like security.d.o ?
> >
> > well, not exactly an "all at once", but having not just a random minor
> > update to pop up every day is IMHO a great feature for system
> > administrators - they're not forced into additional update rounds.
>
> If volatile-stable included as a criterion time-served three months
> (pick a number, archive wide or perhaps per source package),
> I believe it could prove a wise choice of mechanism: familiar,
> cheap to implement, and a good proxy for some desirable qualities.
Yes, that is exactly what I mean. Not too many updates to mechanismns,
except if really required. And of course, the daily update of e.g.
clamavs files, should be done by a cronjob from clamavs site, and not by
installing a new deb every day.
> I don't understand 'forced into additional update rounds'.
A lot of admins (including me) use tools that tell them "Hey, you forgot
to update your packages" if they are not current. And, if the last
update fixed a security bug, this is actually needed.
> In what use-cases is a three-month clamav good, a two-year-old clamav
> not, and newer not interesting? What does it do?
Well, as I said above: If there is a good reason for an update, it
should be in. But - don't fix it if it is not broken, and who wants to
use the very newst development version could just use some backports,
e.g. from backports.org. volatile is IMHO more a "it is more current
than stable, but otherwise, we change as less as possible".
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
> What are the pros and cons for
> volatile-{stable,release,or-whatever-you-call-it}
> as an all-at-once release model, rather than a rolling-when-its-ready
> model more like security.d.o ?
well, not exactly an "all at once", but having not just a random minor
update to pop up every day is IMHO a great feature for system
administrators - they're not forced into additional update rounds.
> Does anybody want to use a three month old clamav ?
> (with up-to-date definitions of course)
> Why?
I do. Why: Because there is no reason to update it more often.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
* Jesus Climent ([EMAIL PROTECTED]) [041007 13:10]: > On Wed, Oct 06, 2004 at 04:12:48PM -0700, Thomas Bushnell BSG wrote: > > In other words, are your upgrades going to be "install the latest > > upstream", or are they going to be "fetch the relevant new things from > > upstream and put them in the old thing"? I agree completely that the > > latter is more work, but that is not an excuse for choosing the > > destabilizing strategy. > It is my point of view that with volatile in place, the policy for allowing > updates on such repository could introduce things which break other apps. This policy is even not ok for a normal major debian upgrade. We have exim and exim4, we have inn and inn2 for exactly that reason, and we should also provide spamassassin and spamassassin3. This doesn't mean that spamassassin3 shouldn't be added to volatile.debian.net, but it definitly means that we should not break api by providing it as spamassassin. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041006 23:25]: > Unfortunately, most of what I have seen has been an attempt to have a > new place that involves no actual backporting and publicity work, > rather than volunteering to take that load on. Actually, I'm considering very much to pick the task up (and have also already volatile.d.n ;), but there are some issues that needs to be considered before doing a public announcement. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Marco d'Itri ([EMAIL PROTECTED]) [041006 23:05]: > On Oct 06, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > > Well, if I dist-upgrade my mail server so a new spamassassin comes in, my > > mail setup breaks. Now, that is clearly broken, and an RC bug on some > > package. > We are talking about unstable. We are talking about a package aimed for next stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* martin f krafft ([EMAIL PROTECTED]) [041006 22:40]: > also sprach Andreas Barth <[EMAIL PROTECTED]> [2004.10.06.2234 +0200]: > > I guess spamassassin3 won't be added to sarge. Can you remember > > the upload of the latest kde to unstable, and the explicit NO from > > the release masters? Can you remember that already before that it > > was said "no new upstream versions"? Spamassassin 3 is a new > > upstream version - so, no spamassassin 3 in sarge. > Fair enough. But what if we provide spamassassin3 in addititon to > spamassassin (2.64) ? That can be done of course - as well as we have exim4 in addition to exim, or inn2 in addition to inn. But in this case, reverting the latest upload of spamassassin might be a good idea. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* martin f krafft ([EMAIL PROTECTED]) [041006 16:35]: > also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.06.1616 +0200]: > > This is backwards. The conflicts must be added in spamassassin in > > order that we don't forget to remove said other packages from > > sarge if necessary. > That prevents SA from entering Sarge. That's a feature. > I say: remove all the others from Sarge unless or until they comply > with SA 3. I guess spamassassin3 won't be added to sarge. Can you remember the upload of the latest kde to unstable, and the explicit NO from the release masters? Can you remember that already before that it was said "no new upstream versions"? Spamassassin 3 is a new upstream version - so, no spamassassin 3 in sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Francesco P. Lovergine ([EMAIL PROTECTED]) [041006 15:05]: > On Wed, Oct 06, 2004 at 02:40:47PM +0200, Jesus Climent wrote: > > On Wed, Oct 06, 2004 at 02:32:09PM +0200, Andreas Barth wrote: > > > > Just for record, I and a few other people removed spamassassin 3 on > > > > my workstation due to performace problems. It is really a memory > > > > and cpu hog. I doubt it is usable as is on any box without > > > > a good deal of horsepower and memory. I would add at least > > > > a big warning in its NEWS file about this, until its problems will be > > > > not solved. > > > If this is not solved, we really should consider to re-introduce > > > spamassassin 2 as spamassassin, and the version 3 as spamassassin3. > Unfortunately, it is also used as the only anti-spam plugin in other > software, such as amavis AFAIK. As pointed before anyway, releasing those > kind of tools and thinking of having them frozen for a couple of > years is a non-sense, plain and clear. The volatile archive > is having more and more sense. Sorry, but the basic problem I'm speaking about has nothing to do with volatile - but just that requiring substancially more memory might be a bad idea. We still have inn1 and inn2 parallel (and I'm a happy user of inn1), for similar reasons. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: possible mass bug filing: spamassassin 3
* Francesco P. Lovergine ([EMAIL PROTECTED]) [041006 14:20]: > On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: > > Spamassassin 3 is finally in unstable. Thanks to Duncan (and > > possibly others involved)! > Just for record, I and a few other people removed spamassassin 3 on > my workstation due to performace problems. It is really a memory > and cpu hog. I doubt it is usable as is on any box without > a good deal of horsepower and memory. I would add at least > a big warning in its NEWS file about this, until its problems will be > not solved. If this is not solved, we really should consider to re-introduce spamassassin 2 as spamassassin, and the version 3 as spamassassin3. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: BTS and maintainer changes (and PTS)
* Isaac Clerencia ([EMAIL PROTECTED]) [031216 11:25]: > On Tue, 2003-12-16 at 06:19, Graham Wilson wrote: > > On Tue, Dec 16, 2003 at 01:05:44AM +, Henning Makholm wrote: > > > I recently adopted autotrace, and had a package with an updated > > > control file uploaded; it has now been in the archive for several > > > days. > > I am in the same situation with hostname. > I have a similar problem, but with PTS, I uploaded a month ago > "openrpg", and it is already in the archive, but > http://packages.qa.debian.org/o/openrpg.html > doesn't show any information about it, and > http://packages.qa.debian.org/o/openrpg/news/ > is empty ... PTS and packages.qa is also still affected by the compromise (read: mostly not really working). However, the key developer for that is working on it (but was/is having problems due to having no key in the keyring due to the gnupg-problem). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
dpkg-sig as name for the .deb-files signature tool
retitle 223311 ITP: dpkg-sig -- create and verify signatures on .deb-files thanks Hi, I announced the packaging of a low-level tool for creating and verification of signatures on deb-archive files with the name debsigs-ng. This name was criticized, because it looks like a fork of debsigs. So, I had some discussion on IRC. Some names were prefered in discussion. At the end, we had some dpkg-* names in discussion, as well as dpst (debian package signature tool) and trusted-deb. The last one left the discussion area as it promises rather too much - the tool is _not_ a high level tool that plugs into apt or dpkg, but it is just on the same level as dpkg-deb. dpst is IMHO rather too cryptic, so I decided to dpkg-sig. A preliminary version is apt-able at deb http://dpkg-sig.turmzimmer.net/dpkg-sig/ ./ deb-src http://dpkg-sig.turmzimmer.net/dpkg-sig/ ./ Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revocation list for old packages with security holes (was: Re: Revival of the signed debs discussion)
* Julian Mehnle ([EMAIL PROTECTED]) [031210 13:40]: > Joey Hess <[EMAIL PROTECTED]> wrote: > > Goswin von Brederlow wrote: > > > What can we do with deb signatures? > > > > > > For our current problem, the integrity of the debian archive being > > > questioned, the procedure would be easy and available to every user: > > > > > > 1. get any clean Debian keyring (or just the key signing the keyring) > > > 2. verify the latest Debian keyring > > > 3. verify that each deb was signed by a DD and the signature fits > > > > The canoical attack against signed debs in this situation is to find a > > signed deb on snapshot.debian.net that contains a known security hole. > > Now inject it into the compromised archive, with a changed filename, and > > edit the Packages file to have its md5sum. Now a user's checks will > > succeed -- the package is signed with a developer's key -- but they will > > install the old, insecure .deb. The only hint will be a warning from > > dpkg that it is downgrading the package, and a clever attacker might > > avoid even that. > We could use a revocation list where signatures of packages with known > security holes are listed as being revoked. Of course, you'd > need to be online to check it when installing/updating packages. And the > revocation list would best be served from a server that's > secure and separate from the archive servers to make attacks against it a bit > more difficult. Yes, that would also be a good enhancement. However, verifying the actual control files of a package again the information in Packages is also worth doing. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: more details on the recent compromise of debian.org machines
Hi, * Marc Haber ([EMAIL PROTECTED]) [031128 10:55]: > I would like to know whether the attacker was able to log in to auric, > even as unprivilieged user. Did she actively try to compromise auric? > > What kind of verification of auric's integrity was done / is planned > to be done? > > [more questions] Were these questions answered on debian-private, or did I miss the answer here? I would really be interested in the answer. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#223311: ITP: debsigs-ng -- create and verify signatures on .deb-files
Package: wnpp Version: N/A; reported 2003-12-08 Severity: wishlist * Package name: debsigs-ng Version : 0.1 Upstream Author : Andreas Barth <[EMAIL PROTECTED]> * URL : http://debsigs.turmzimmer.net/ * License : GPL Description : create and verify signatures on .deb-files debsigs-ng is a low-level tool for creation and verification of signature on the Debian archive files (deb). The created signed files are strict compatible with dpkg and the apt-utils. These tools could also verify older signatures done by debsigs.
Re: Requirements on signatures on debs
* Andreas Barth ([EMAIL PROTECTED]) [031206 18:10]: > I've tried to write down a list of requirements for the signature > names (and what should be signed). I'll update the web version of this > on http://debsigs.turmzimmer.net/policy.html After some discussions, I updated my proposal (and also the website). | Names of the signature files | |There are quite different people and roles who handle a package during |it's lifetime. These are (among others): | * Maintainer as part of the build process | * non-Maintainer as part of the build process (NMUs) | * sponsor | * buildd | * buildd-Admin (or is this aequivalent to the non-Maintainer?) | * dinstall for installing | |These persons fall into three main categories: | * someone building a binary deb, e.g. a maintainer, a buildd, ... | * someone providing this deb as a part of the archive, e.g. dinstall | * someone approving a binary for a given situation, e.g. the |security team for security.debian.org | |Overall, _gpg is used as a general prefix. For the first category, the |signature is named _gpgbuilder. For the second, a usefull name would |be _gpgorigin (as "origin" is commonly used for such things, e.g. at |apt pinning). For the third, this is a bit more complex, and so we |leave it open. A commonly used name could be _gpgapproval, but |everyone could use what he sees as usefull. | |Sometimes (especially with the last one), there could be clashes. In |the case of a clash, the new signature is created as |[0-9A-Z], with the lowest free one. (That means, if |_gpgapproval is used, the next one would be _gpgapproval0, and then |_gpgapproval1, and so on.) | |Some signatures are done by scripts, and some by human. This |distinction can (and should) be made by the used key, not by anything |else. | | What the signature provides | |Each signature signs: | * control and data information | * all previous signatures | * the time information that is embedded in the tar-files and inside |the previous signatures | |It should be possible to make signatures remote, without downloading |the whole deb. For this, the signature is done over the md5sums (as |provided by the md5sums-utility) of all ar members, in the order in |which they are present in the archive. After doing the signature, the |new archive member is appended to the deb file. No other way of |altering the deb except appending a new signature is allowed; |otherwise, the previous signatures could be broken. | | Signature verification | |If a signature is due to be verified, the md5sum of the previous |archive members is made. The signature itself, and the following |archive members are supressed for that. The signature is then verified |on that md5sum. This has the bonus that signature verification could |also be done by hand, for debugging or in special situations. If there are any questions on this, I'm happy to answer them. If not, I'll provide a debsigs-ng on my website that generates and verifies conforming signatures. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
[PROPOSAL] definition of deb binary files
Hi, I made a proposal of an updated deb format definition. I based that on the manpage deb (part of dpkg-dev), and on reverse engineering of dpkg-deb/build.c. I hope I've written the standard in a right and easy to understandable way. I did (by purpose) not add anything about signatures etc, but I just wanted to document what we have at current. Discussion about additions should (IMHO) be kept seperate. IMHO this definition should become part of the policy; I propose either an new chapter 12, or an addition to chapter 3 Binary packages, whatever seems more appropriate. This means that also some parts of Appendix B could be removed at this occasion. I'm also Ccing one bug of apt-utils, where I also got some of the information from, and debian-devel. Please restrict the crossposting on answers if usefull. Cheers, Andi DESCRIPTION The .deb format is the Debian binary package file format. It is understood by dpkg 0.93.76 and later, and is generated by default by all versions of dpkg since 1.2.0 and all i386/ELF versions since 1.1.1elf. The format described here is used since Debian 0.93; details of the old format are described in deb-old(5). OVERALL FORMAT The file is an ar archive in a certain ar version and with a magic number of !. Due to the robustness principle, extracting tools should be able to cope with as many of the different ar versions as possible; if they don't, its at maximum a wishlist bug. On the other hand, tools providing .deb-files MUST only provide strictly standard compatible files. Every other behaviour is a serious bug! The first member of the archive is name debian-binary and contains a series of lines, separated by newlines. Currently only one line is present, the format version number. The 2.0 format is current, and this format is described in that document. Programs which read .deb-files should be prepared for the minor number to be increased and new lines to be present, and should ignore these if this is the case. If the major number has a value a programm doesn't know, an incompatible change has happend, and the program should abort with an error. OVERALL AR FORMAT The ar-format is (by purpose) one of the most ancient formats. This has the reason that it should be possible to unpack .deb-files on as many different computers as possible. Furthermore, it makes it also more easy for our code to handle it. Any ar files can be written as AR-FILE := HEADER [MEMBER]*. The header is the string "!\n" (not null terminated). Each member itself consists of the member head, and of the body, and, if necessary, a padding '\n'. All information in the members head is printable ascii, and each value is padded with spaces on the right side; at least one space must be present, so the information must be shorter than the maximum number of bytes available. The head is composed of the name (16 bytes), the date in seconds since epoch (1970-1-1 0:00:00 UTC) in decimal notion (12 bytes), the uid and gid of the owner in decimal notion (each 6 bytes; usually both 0), the file member mode in octal notion, begining with 1 (8 bytes; usually 100644), the size of the member body (the size is measure without possible padding to the body; 10 bytes) and the two bytes "`\n". After the member head, the member body follows unquoted; if the member body has uneven lenght, it is padded with a single '\n'; so any members start on an even byte boundry. So, the initial member looks like: debian-binary 1070194109 0 0 100644 4 ` 2.0 Newer ar features (as longer file names, filesnames with spaces, ...) are a violation of this standard; however, extracting tools should try to support them as good as possible, but if they do not, that's just at maximum a wishlist bug. DEB 2 ARCHIVE MEMBERS Archives with the major number 2 must have (after the initial member debian-binary) in this exact order the members control.tar.gz and data.tar.gz. After this, optional members can follow, but they must have a '_' as the first character of their name. control.tar.gz is a gzipped tar archive containing the package control information, as a series of plain files, of which the file control is mandatory and contains the core control information. Please see the Debian Packaging Manual, section 2.2 for details of these files. The control tarball may optionally contain an entry for `.', the current directory. data.tar.gz contains the filesystem archive as a gzipped tar archive. DEB 1 ARCHIVE MEMBERS See the man-page deb-old(5) for a definition. -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Requirements on signatures on debs (was: Revival of the signed debs discussion)
First: There is now a version of debsigs that creats debs that the apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried it with the unmodified apt-utils of woody). * Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]: > I agree with you that every instance along the way to the archive > should sign the package: > > 1. maintainer > 2. sponsor > 3. buildd > 4. buildd admin > 5. dinstall I've tried to write down a list of requirements for the signature names (and what should be signed). I'll update the web version of this on http://debsigs.turmzimmer.net/policy.html policy for debsigs What are the technical conditions Current, signatures are created with debsigs and each is stored in an extra file in the deb. One (due to policy unchangeable) condition is that non-standard filesnames in the deb start with _ and that all filenames are not longer than 14 characters. debsigs uses as prefix the characters "_gpg", which is quite usefull. So, there are (at maximum) 10 characters left for usage of signature names. What should signature reflect? There are quite different people and roles who handle a package during it's lifetime. These are (among others): * Maintainer as part of the build process * non-Maintainer as part of the build process (NMUs) * sponsor * buildd * buildd-Admin (or is this aequivalent to the non-Maintainer?) * dinstall for installing There are a few key differences: Some roles are bound to scripts that do their action independing on any human action, some are bound more or more less to human interaction. One other key question is: Should each signature stand for it's own (means: one could delete one signature from inbetween a deb), or should they depend on each other)? The former has the advantage that this is the current approach, and technically easier. The later has the advantage that this enforces identification in which order which persons and roles did handle the deb. I'm open for additions, suggestions, comments or (due I hope not) errors. Please tell me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
apt-utils compatible debsigs
Hi, we had a discussion about signed deb-files. One major drawback was the incompatibility between apt-utils and debsigs. I updated debsigs to create a compatible version; this is apt-able at deb http://debsign.turmzimmer.net/ ./ deb-src http://debsign.turmzimmer.net/ ./ (and of course also sent to the BTS). I also put some more ideas to that website. I would like some feedback on this change (and it is admited that the major drawback of this change is that it is ugly, and should be backed out one we have a "debian ar"), and on the other contents of this website. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Henning Makholm ([EMAIL PROTECTED]) [031206 13:25]: > Scripsit Goswin von Brederlow <[EMAIL PROTECTED]> > > If a package is compromised we can proof that the DD of the package > > either is malicious or incompetent. > Say, we just had a major compromise on certain Debian machines. Pray > tell, who do you think this proves is malicious or incompetent? We'd > certainly want to toss out the culprit ASAP. IMHO there can also be a third explanation: "Bad luck". But this also nullifies the trust in any keys on any compromised machine - and the administrators did replace the keys. (And, to be honest: Perhaps one should discuss whether the kernel-team would need some security team, like we have here at Debian. But speaking what other should do is always very easy, and leads mostly to nothing than hot air. For this cause, I didn't start and don't want to say anything more to this topic. If someone with profound security knowledge would want to help out there, this would be a much better starting point for any discussion.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
* Anthony Towns (aj@azure.humbug.org.au) [031206 08:10]: > On Fri, Dec 05, 2003 at 05:46:30PM +0100, Marc Haber wrote: > > On Thu, 4 Dec 2003 13:43:39 +1000, Anthony Towns > > wrote: > > >The one that gets installed later, Pre-Deps the one that gets installed > > >earlier. exim4-daemon Pre-Depends: exim4-config; exim4-config Depends: > > >exim4-base, probably. > > Unfortunately, that doesn't work. > Err, of course it doesn't. What a stupid idea. > > Seriously, I think you need to reconsider having the configuration in > a separate package. > > What're you trying to achieve exactly? Allowing for different configuration mechanismn. And I (as a user of exim4) like that very much. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Matt Zimmerman ([EMAIL PROTECTED]) [031204 22:25]: > On Thu, Dec 04, 2003 at 03:58:38PM -0500, Daniel Jacobowitz wrote: > > On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote: > > > What kind of real world attacks do signed debs prevent? > > > > > > The only one which comes to mind is a rogue Debian developer that you do > > > not wish to trust, even though the project trusts him. > > Someone pretending to be someone Manoj trusts, offering him a corrupted > > .deb offline? > s/offline/without the corresponding signed metadata/ > > The advantage would certainly appear to be one of convenience (keeping > everything in one file), rather than security (preventing attacks). If it is more convenient, than security actions are far more often made. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Goswin von Brederlow ([EMAIL PROTECTED]) [031204 15:10]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > Ok? > Sounds ok but the upload rules can be tightened much much later. First > we have to get signing started, which means fixing apt-utils or > debsigs or preferably both. And of cause change policy to > allow/suggest it. I want to know before going on a trip where this trip is suggested to end. Of course, after knowing, we should really start with the first steps. And these are, as you say: - Fix apt-utils - Sign md5sum-files instead of the concatenated binaries (to allow for reomte signing) - Change policy And don't forget: Start to sign as soon as the toolchain is ready for it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: exim4-config and exim4-base installed on systems with non-exim-MTA
* Tore Anderson ([EMAIL PROTECTED]) [031203 23:55]: > * Marc Haber > > The way -config does the configuration is something that is questioned > > by a lot of people. Most conservative eximists hate the configuration > > being split out in several files, > Absolutely, this is a slight convenience for the packagers which causes > a major inconvenience to the users. Well, in my opinion anyway. In my opinion the way exim4 handles the configuration adds a major benefit for the persons using exim4. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Wouter Verhelst ([EMAIL PROTECTED]) [031203 23:10]: > Op wo 03-12-2003, om 10:09 schreef Andreas Barth: > > > > file back signed by the build admin. The debian archive scripts > > > > accepts packages signed by a buildd-key only if it is a binary package > > > > for this architecture, the key is valid (i.e. in the right year), and > > > > this package has been handed out to this autobuilder for building. > > > > > > Valid for the autobuilder the package has been handed to and that send > > > it in and if the changes file is correct. > > > > > > But what if the buildd failed and someone manually build the deb, > > > signes it and uploads? The debian archive scripts would need a way to > > > distinguish between autobuild packages and manually build binary-only > > > uploads. > > I don't see why that would be the case. Could you elaborate? > > > The archive script would of course continue to accept any deb by any > > DD under the same conditions as today. The question to the > > buildd-admins is: How often does this happen? > > Hardly ever, if at all. Most "manual" bin-NMU's are done by people that > are not buildd admins. I don't understand what you mean. Perhaps it would be best if I try to rephrase my ideas: The archive scripts accept a package currently if the following conditions are met: * There is an signed changes file for the debs by a DD These would be harded to the following: * There is an signed changes file for the debs by a DD * The debs are signed - by an DD or - by an buildd, if this buildd was the one to build this package. So, the archive scripts don't distinguish between autobuild packages and manually build binary-only packages, but they look at the debs, and verify the signature. If the signature is by a DD, everything is ok. If the signature is by a buildd, they verify that the buildd had had an job to build this deb. Ok? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Goswin von Brederlow ([EMAIL PROTECTED]) [031203 03:25]: > Henning Makholm <[EMAIL PROTECTED]> writes: > > If an attacker compromises the buildd to the point where he can gain > > access to its secret key, he could just as well attack its build > > environment, or simply use his access to convincingly forge an email > > to you, asking you to sign a malicious package. > The maintainers signature is worth a bit more. If the buildd is > compromised the onsite key can be used to create new packages at will > and predate them to before the attack. With the maintainers key only > packages build after the attack can be compromised and if the start of > the attack can be determined only a few packages have to be removed. If the archive maintainance script signs also the package (and the signature does keep the signing time), than you don't gain extra security by the extra signature. The only case where you would gain anything is if an attacker gets both keys under his own control. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Goswin von Brederlow ([EMAIL PROTECTED]) [031203 03:40]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > * Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]: > > > So unless you have a suggestion that would solve this particular issue, > > > I'm afraid this idea won't work in practice. > > Two suggestions come to my mind. However, I can't judge how useful > > they are in reality. > > > > Signing by the buildd: > > The buildd could sign the debs by a buildd-key (one key for each > > buildd and each year). They could sign e.g. after they get the changes > Must be signed before the chnages files since the szec and checksum > change by signing. Not necessarily because of the options: 1. Accept a buildd-signature on the changes-file 2. Remove the signature out of the deb for the changes-verification if the signature is by a buildd 3. Make a preliminary signature on the deb for creation of the changes-file, but keep that secret and add it only after receiving of the changes-file. > > file back signed by the build admin. The debian archive scripts > > accepts packages signed by a buildd-key only if it is a binary package > > for this architecture, the key is valid (i.e. in the right year), and > > this package has been handed out to this autobuilder for building. > > Valid for the autobuilder the package has been handed to and that send > it in and if the changes file is correct. > > But what if the buildd failed and someone manually build the deb, > signes it and uploads? The debian archive scripts would need a way to > distinguish between autobuild packages and manually build binary-only > uploads. The archive script would of course continue to accept any deb by any DD under the same conditions as today. The question to the buildd-admins is: How often does this happen? Does this need special handling, or is it ok for them if they sign in these rare cases with their normal key? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Steve Langasek ([EMAIL PROTECTED]) [031202 22:10]: > AFAIK, apt does not sanity check the relationship between package names > and filenames (and it's not obvious that this should be part of its > responsibilities), and dpkg only gets a list of .debs to install once > they've been downloaded. So this should be handled for a safer environment. E.g. dpkg could get an explicit "I want downgrade"-switch, along with an "install without signature validation". With these (and these switches not used by apt by default), there would be no danger in your scenario (except wasted bandwith). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]: > As much as I like this idea in principle, storing signatures inside > .debs has a serious problem: it won't work for us buildd maintainers. Workability for the buildd maintainers is IMHO _certainly_ one important thing. > As I explain in my document on wanna-build (usually at > http://people.debian.org/~wouter/wanna-build-states, but due to some > problems with that machine temporarily currently at > http://www.grep.be/wanna-build-states.html too), buildd maintainers do > not manually log in to their autobuilder to sign each and every .changes > on its hard disk; instead, they extract the .changes file from the mails > of successful messages sent to them (and to [EMAIL PROTECTED], > which processes them into what people can look up on > http://buildd.debian.org), sign that, and send it back. In reply, the What checks do you do to such a package before signing? > So unless you have a suggestion that would solve this particular issue, > I'm afraid this idea won't work in practice. Two suggestions come to my mind. However, I can't judge how useful they are in reality. Signing by the buildd: The buildd could sign the debs by a buildd-key (one key for each buildd and each year). They could sign e.g. after they get the changes file back signed by the build admin. The debian archive scripts accepts packages signed by a buildd-key only if it is a binary package for this architecture, the key is valid (i.e. in the right year), and this package has been handed out to this autobuilder for building. Creating special helper scripts: It could be possible to extract a small file (more or less like the current changes file) out of each deb. So you could just sign this file, and sent it back to the buildd. The buildd would then extract the signature, and include it into the deb before upload. This would however need to change the way debsign works: Currently debsign makes a simple binary stream out of the members of the ar. Instead of this, debsign should create e.g. a md5sum-file (like the current changes, but "one level lower") out of the binaries, and then sign this file. It is possible to write a verify-script that could accept the old and the new verifying-method. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]: > Goswin von Brederlow wrote: > > What can we do with deb signatures? > > > > For our current problem, the integrity of the debian archive being > > questioned, the procedure would be easy and available to every user: > > > > 1. get any clean Debian keyring (or just the key signing the keyring) > > 2. verify the latest Debian keyring > > 3. verify that each deb was signed by a DD and the signature fits > The canoical attack against signed debs in this situation is to find a > signed deb on snapshot.debian.net that contains a known security hole. To avoid this attack, it is necessary that the filename of the deb or the version of the package is also signed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > Technical details should IMHO be discussed later, but a sample > > passport could look like: > > > > accepted by katie on Mon, 1 Dec 2003 20:34:58 + because of good > > signature of DD, KeyID 0x01234567 > > build by DD on Sun, 30 Nov 2003 14:34:33 +0100 > > mgetty-voice_1.1.30-6_i386.deb > > 450b2b4ffa0be49b43f7358099117f7d control.tar.gz > > fb00a05d140ec3e830d6227f3fdd743d data.tar.gz > All debs would contain the same string "accepted by katie on * because > of good signature of DD, KeyID *". Thats a lot of bytes wasted. There is a mere misunderstanding. If you singned the deb, katie would write "accepted by katie on * because of good signature of Goswin von Brederlow <[EMAIL PROTECTED]>, KeyID 0x...". And of course, this string should be made shorter, but that's something we can at the moment leave for later discussion IMHO. It could e.g. be: "katie: 2003-...: sig ok, Goswin von Brederlow <[EMAIL PROTECTED]>, 0x" > The date is already stored in the ar archive so thats wasted too. Almost everything is "already stored in the ar archive". But not in a secure way. The question is just: Which information is needed to be secured. And I for myself want the day something was transfered to the pool to be signed. > Each signing instance should have an unique key. They key ID then > identifies who signed it and the reason (being allways the same) could > be documented in some Readme. The reason is not always necessarily the same, e.g. if someone sponsors someone else. However, this could be solved with your proposal. > I agree with you that every instance along the way to the archive > should sign the package: fine. > debsigs allows for 10 chars for the name of the signature. > 8 chars would be key ID. > 1-2 chars could be used to denote the reason of the signature: > > DM - DD maintainer > NM - non DD maintainer > DN - non maintainer upload by a DD > NN - non maintainer non dd upload > SP - sponsor > BD - buildd > BA - buildd admin > DI - deinstall Good idea. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)
* Gergely Nagy ([EMAIL PROTECTED]) [031201 23:10]: > > * Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]: > > > I think, at least Packages like "dpkg" or "gnupg" should call > > > "dh_md5sums". I was wondering, if it would be usefull to make > > > a mass bug-filling against these Packages. Before, it would be > > > nice to have a List of Packages (maybe sorted by Maintainer) > > > which do not call "dh_md5sums". > > > > > > IMHO Lintian should also check if "dh_md5sums" is called and > > > print at least a warning if this is not the case. > > I agree with you, and I would support mass-filling, if first such a > > list has been published here on d-d, together with the warning of > > mass-filling. > I disagree. Filing bugs on packages not having md5sums _might_ be ok, > altough last time I checked, md5sums were only sugested, nowhere near > a must in policy. Filing bugs based on missing calls to dh_md5sums is > simply stupid. You don't need to build-depend on debhelper to have > md5sums. It was understood (at least from my side) that the checks should actually be performed on the debs, and just for the existence of md5sums, and of course not on the way of creating them. Everyone is free to use the build tool he himself likes most. Sorry if I was unclear about that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Goswin von Brederlow ([EMAIL PROTECTED]) [031201 14:40]: > Instead of keeping extra files with the signature of the deb the > information could be stored inside the deb itself. Of cause the > signature can't be contained in the thing being signed. Instead the > signature would be added to the end or the ar archive and contain > signatures for all the files (uncompressed?) before it in the archive. > [...] In principle I agree with your plan. Just a few suggestions what could (perhaps?) be also done: I would like it even more if there would be something along each package that identifies what was done to the deb-file since creation (see it as a something like a "passport" or "signature file", where each entry adds new information to the file). This would also have the advantage that a system administator could verify signatures without following who is accepted as a DD, and who is resigning - without a compromise of the debian server, verifying any deb with the archive key is enough. If there is however a suspecion of problems, he could always make stricter checks, without requiring more infos from the archive. (And of course, any administrator could also make checks stricter and demand a signature by a DD plus a signature by the archive script). More in detail this would mean that after building, the maintainer signs the md5sums, and a "build this package on ". After accepted by the archive, the archive script adds a line with something like "accepted by katie on because of good signature of " to the top, and signs the whole thing. This has one major drawback: Either the deb-file must be changed during acceptance to the archive, or the "passport" must reside in an extra file. (And there is of course a "mixed mode" possible: Extra file at the moment, and after sarge is released, the files move within the deb.) Technical details should IMHO be discussed later, but a sample passport could look like: accepted by katie on Mon, 1 Dec 2003 20:34:58 + because of good signature of DD, KeyID 0x01234567 build by DD on Sun, 30 Nov 2003 14:34:33 +0100 mgetty-voice_1.1.30-6_i386.deb 450b2b4ffa0be49b43f7358099117f7d control.tar.gz fb00a05d140ec3e830d6227f3fdd743d data.tar.gz Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
* christophe barbe ([EMAIL PROTECTED]) [031201 20:10]: > On Mon, Dec 01, 2003 at 07:43:17PM +0100, Michael Ablassmeier wrote: > > Unfortunately many Maintainers do not use "dh_md5sums" to ship > > an .md5sums File in their Package(s). This makes it harder to > > check the already installed Files on a Debian installation. > > > > I think, at least Packages like "dpkg" or "gnupg" should call > > "dh_md5sums". I was wondering, if it would be usefull to make > > a mass bug-filling against these Packages. Before, it would be > > nice to have a List of Packages (maybe sorted by Maintainer) > > which do not call "dh_md5sums". > Before mass bug-filling, it would be necessary to make it mandatory > which unfortunately is not the case right now afaik. Severity: wishlist Where is the problem? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Mass-filling against packages without MD5-sums? (was: debsums for maintainer scripts)
* Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]: > I think, at least Packages like "dpkg" or "gnupg" should call > "dh_md5sums". I was wondering, if it would be usefull to make > a mass bug-filling against these Packages. Before, it would be > nice to have a List of Packages (maybe sorted by Maintainer) > which do not call "dh_md5sums". > > IMHO Lintian should also check if "dh_md5sums" is called and > print at least a warning if this is not the case. I agree with you, and I would support mass-filling, if first such a list has been published here on d-d, together with the warning of mass-filling. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Scott James Remnant ([EMAIL PROTECTED]) [031201 18:40]: > On Mon, 2003-12-01 at 16:26, John Goerzen wrote: > > Even if the attacker could place a new keyring file in the archive, > > people verifying signatures on signed .debs would not install it, since > > it would not have the signature of a developer. > What defines "the signature of a developer"? That their key is in the > keyring, so if a hax0r decided to comprise our keyring and add a key to > it, there'd be no way to tell that it wasn't a developer's key. For dpkg on my computer: That the signature is in _my_ _currently_ installed keyring package. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* Marc Haber ([EMAIL PROTECTED]) [031201 18:25]: > On Mon, 01 Dec 2003 15:56:59 +, Scott James Remnant > <[EMAIL PROTECTED]> wrote: > >Download the source package components, verify their MD5 signatures > >against the Sources file, verify the MD5 signature of the Sources file > >against the Release file and verify that file's GPG signature. This > >proves that the package has successfully passed through the ftp-master > >process and entered the archive. > The GPG signature on the Release file is automatically generated with > a key that was stored on one of the compromised boxes. That trust > chain is thus broken at its very beginning, and unfortunately the > stable release manager seems to ignore questions on IRC asking for a > 3.0r2 Release file signed with his personal GPG key. It is certainly a very good idea to sign the long living Release-files (also|only) with an off-line key. It would IMHO even better if also the debs are (better) signed than they are, because double protection is always better than single protection. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Revival of the signed debs discussion
* John Goerzen ([EMAIL PROTECTED]) [031201 17:40]: > Even if the attacker could place a new keyring file in the archive, > people verifying signatures on signed .debs would not install it, since > it would not have the signature of a developer. And to be honest: If all debs are signed, and it is easy possible, I would restrict accepted signatures at my private machine for the keyring package to James - and let me send a mail if there is a keyring package signed by any other DD. So, the real danger would be if James key is stolen. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Source only uploads? -- Survey evaluation
* Roland Stigge ([EMAIL PROTECTED]) [031201 15:55]: > On Sat, 2003-11-15 at 14:50, Roland Stigge wrote: > > [...] > > Instead, I volunteer to host a small, unofficial and non-anonymous > > survey to get an impression of the community's opinion. If you are a > > Debian Developer, please send me a private mail with > > > > "Source only uploads: Yes" > > > > or > > > > "Source only uploads: No" > > > > in the subject. At the beginning of December, I will post the results, > > and if there is any doubt, I will disclose the list of names and votes. > > Unfortunately, there wasn't much response to this. Maybe this is related > to the big Debian KO. I didn't see this survey timly (and as I'm not a DD you'd probably also not interested in my opinion). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Some observations regardig the progress towards Debian 3.1
* Matt Zimmerman ([EMAIL PROTECTED]) [031118 19:55]: > On Tue, Nov 18, 2003 at 06:06:08PM +0100, Adrian Bunk wrote: > > Why did debian-installer miss the dates in the latest release timeline > > by so many months? > Because those dates were made up out of thin air? Then the obvious question is: Why are official timelines made up out of thin air, and why are no updates of such timelines published on d-d-a? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Some observations regardig the progress towards Debian 3.1
* Goswin von Brederlow ([EMAIL PROTECTED]) [031116 13:40]: > Adopting is easy compared to getting a NMU or a hijack sponsort. My first upload to the archive was a (of course sponsored) hijack. So, it's possible (but I had however the blessings of Martin on d-qa, and more-than-one-try to reach the former maintainer before, and the rest of the recommended way to deal with unreachable maintainers). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Some observations regardig the progress towards Debian 3.1
* David Starner ([EMAIL PROTECTED]) [031116 10:55]: > Alexander Winston wrote: > > On Sat, 2003-11-15 at 23:17, David Starner wrote: > > > If you were a Debian developer, you could fix this by adopting or at least > > > NMUing important programs that were unmaintained. Is it easier to stand > > > on the outside and complain then actually work to making it better? > > But it may take many months or even years before he reaches official > > Debian developer status... Could anything be done about that, perhaps? > Actually, Adrian Bunk _was_ a Debian maintainer, but he retired; see > <http://www.debianplanet.org/node.php?id=581>. He actively chose to > make these posts instead of trying to make things better from the inside. Actually, this article is from January 2002, almost two years ago. So, to me as someone who is reading d-d since about April 03, it seems that Adrian is starting to help again Debian. I've seen a lot of usefull suggestions and bug reports, and I do welcome this as a usefull contribution to Debian. (I also share most of his conclusions. Why do we make a release plan if a lot of important packages ignore the plan?) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: ftpmaster accepts packages that have been rejected a few days ago
* Matt Zimmerman ([EMAIL PROTECTED]) [031114 17:55]: > On Fri, Nov 14, 2003 at 08:28:16AM +0100, Marc Haber wrote: > > How long did Eray wait for formal rejection? Did he receive regular > > updates about the state of affairs? > I don't know what Eray received via private mail, but he certainly kept the > rest of debian-devel up-to-date on the process by complaining loudly every > other day. >From the mails I received from Eray, he had till the very last moment the impression that he'll be accepted if he just find five sponsors (and that the debian cabal always pissed of the fifth). However, this was Eray, so I don't know whether he realised what was written to him. ;) And: Eray is _the_ example of a rejection where I would've liked to be informed of it. (Though it was not necessary, because Eray did that himself after the rejection - but in some cases it could happen to someone with at least some clue. And I don't really see why it is more worse to publish a rejection by DAM, than those by the AM. The last ones _are_ published at the moment.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
* Robert Millan ([EMAIL PROTECTED]) [031109 19:25]: > On Mon, Nov 10, 2003 at 01:40:34AM +1100, Martin Michlmayr wrote: > > * Robert Millan <[EMAIL PROTECTED]> [2003-11-09 14:40]: > > > Actualy, I didn't even bother to provide System.map, and my system > > > works quite well. I can add it if you bring me a reason to do so, > > > though. > > So you're saying that you don't know what System.map is good for? > No, but if you actualy cared you'd be telling me instead of asking. Sorry, but: If you want to package a linux kernel, you should _know_ the few basic names and concepts. Otherwise you'll make live hard for people using your package. Knowledge of System.map is a _must_, also knowing of initrd and similar concepts. If not, don't waste your and our time with trying to make a package. (The same is of course valid for any other package: Who wants to package kde must know to what the term "mouse" refers to in connection with computers.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Where are we now? (Was: Bits from the RM)
* Jamin W. Collins ([EMAIL PROTECTED]) [031002 22:18]: > On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote: > > Quite seriously, I prefer using dselect... the main complaint I've > > heard from new users is being able to search for a specific package > > quickly. As soon as I teach them about / for find and \ for find > > again, they generally find it just as useful as I do. > Not I. I made a few attempts to use it in the beginning. After that I > decided that any and all installs I did from that point forward would > not run dselect. I did it just the other way round: I've made a few attempts to use aptitude, and then decided that I stay with apt-get and dselect. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Debian should not modify the kernels!
* Russell Coker ([EMAIL PROTECTED]) [030921 16:41]: > Bad analogy. Consider the way that the Harry Potter books have been modified > for the limited vocabulary of the American audience. I hope that you're joking. (Well, I fear that you're not.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: configure web proxy via DHCP server
* Brian May ([EMAIL PROTECTED]) [030831 01:35]: > On Sat, Aug 30, 2003 at 10:30:31AM +0200, Javier Fern?ndez-Sanguino Pe?a > wrote: > > All of these, IIRC, provide means to run user-defined scripts for > > autoconfiguration. Setting up the proxy server might be just a manner of > > setting up the http_proxy environment variable depending on your location > > (although some browsers might not use it). > No, setting http_proxy wont work unless youo log out and back in again, > or at least close all your terminal sessions. > > It won't work for programs like Mozilla. But it would be cool if this information is stored in "the proper place" and we patch applications like mozilla that they have a config-option to use this information. But that's probably a post-sarge thing. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
