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: 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: 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: 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
* 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: 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
* 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: 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
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: 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
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: 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
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: 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: 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: 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: 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
* 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
* 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: 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: 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
* 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#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#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#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: 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: 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: 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: 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: 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: "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: 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
amd64: ftp-masters questions (was: -= PROPOSAL =- Release sarge with amd64)
* Martin Michlmayr - Debian Project Leader ([EMAIL PROTECTED]) [040717 15:55]: > [AMD64 situation] > As to the > technical questions ftpmaster wants to raise, I'm quite disappointed > that they have not been posted yet because I was promised at DebConf > that it would happen soon. I've now asked someone I trust to find out > what these issues are exactly so hopefully progress will be made on > that soon. Is there any progress on this issue? 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
historic mails from me - please ignore
Hi, I seem to have un-frozen a couple of historic mails. Sorry for the noise, please ignore 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: Obfuscated source
* Bruce Perens ([EMAIL PROTECTED]) [041212 17:50]: > Goswin von Brederlow wrote: > > >Imagine a source where all variables are named v and all > >functions f. Is that still free? Where do we draw the line? > >When does source stop to be bad style and start to become obfuscated > >and unacceptable for main? > > > > > This has been handled before. Some people strip all comments and > unnecessary white space, and make all symbol names meaningless numbers. > In general it's done by a program, and they don't actually use that > version of the code for their own work. Thus, it's not the preferred > source code under the GPL. "preferred form for modification" is _only_ a GPL-term and not part of the SC. 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: Obfuscated source
* John Hasler ([EMAIL PROTECTED]) [041212 19:35]: > Andi writes: > > "preferred form for modification" is _only_ a GPL-term and not part of > > the SC. > The SC is not a legal document. Common sense should suffice to conclude > that obfuscated source does not comply with the DFSG. I didn't argue against that. I just said that the "preferred form of modification" is _not_ the language of the SC, but the language of one of the licenses that we consider as free. 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: Are BLOBs source code?
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 20:25]: > Compiled in the blob MUST comply to the GPL. The nature of being a > blob already seems to violate that. Only if the blob is derived from the GPL-code. 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: Linux Core Consortium
* Tollef Fog Heen ([EMAIL PROTECTED]) [041212 21:35]: > * Goswin von Brederlow > | Tollef Fog Heen <[EMAIL PROTECTED]> writes: > | > * Brian Nelson > | > > | > | Anyone, developer or non-developer, can help fix toolchain problems. > | > | However, the only people who can work on the testing-security > | > | autobuilders are ... the security team and the ftp-masters? What's > | > | that, a handful of people? With a bottleneck like that, isn't that a > | > | much more important issue? > | > > | > The problem is not the autobuilder infrastructure per se. It is that > | > testing and unstable are largely in sync (!). This, combinded with the > | > fact that testing must not have versions newer than unstable (they > | > will then be rejected) means testing-security wouldn't work at the > | > moment. > | > | How is that different from testing-proposed-updates? > > t-p-u is not uploaded from another host through a mapping. (Remember, > uploads to stable are mapped to stable-security on > security.debian.org, then uploaded to stable from that host. The > .changes file however, does not list stable-security, it only lists > stable. And the trivial fix, to drop the mapping won't help either, > since then any DD could upload to stable by uploading to > stable-security, and we don't want that.) IIRC the changes file lists stable-security, e.g.: hpsockd (0.6.woody1) stable-security; urgency=high (just looked into queue/done for that). And katie on ftp-master maps stable-security to proposed-updates. > Also, AIUI, t-p-u will mostly be used when there's a newer version in > unstable and you can't get the version in unstable in (because of > dependencies) or you have to get a fix in immediately, in which case > you upload to "unstable testing-proposed-updates", so you don't hit > the version skew issue. Also uploads to testing-security will go to t-p-u on ftp-master, via the same mapping mechanismn. (Just look into katie.conf, you'll see the mappings there.) BTW, there is now at http://people.debian.org/~aba/dak.patch a draft of a patch tackling the necessary changes for *security. However, as this is my first real katie-patch, there might be issues I don't (currently) see, and even if not, implementing on ftp-master requires more than just a short glance over 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: Are BLOBs source code?
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 21:55]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > * Goswin von Brederlow ([EMAIL PROTECTED]) [041212 20:25]: > >> Compiled in the blob MUST comply to the GPL. The nature of being a > >> blob already seems to violate that. > > Only if the blob is derived from the GPL-code. > No, always. Compiled in it is part of the binary which is a work > derived from the GPLed work. It is like linking to a non GPL library. > > Only seperate (e.g. in an initrd) you can say it is just an > aggregation of works. Why should elf-aggregation always mean to be part of a derived code, and fs-level aggregation mean that not? Even e.g. Linus writes that there _are_ examples where elf-aggregation does not mean a derived work (well, of course: the default assumptation is that it is derived, but it could be proven otherwise). 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: Linux Core Consortium
* Goswin von Brederlow ([EMAIL PROTECTED]) [041212 22:20]: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > t-p-u is not uploaded from another host through a mapping. (Remember, > > uploads to stable are mapped to stable-security on > > security.debian.org, then uploaded to stable from that host. The > > .changes file however, does not list stable-security, it only lists > > stable. And the trivial fix, to drop the mapping won't help either, > > since then any DD could upload to stable by uploading to > > stable-security, and we don't want that.) > > > > Also, AIUI, t-p-u will mostly be used when there's a newer version in > > unstable and you can't get the version in unstable in (because of > > dependencies) or you have to get a fix in immediately, in which case > > you upload to "unstable testing-proposed-updates", so you don't hit > > the version skew issue. > Which is exactly what you have with security. There is a newer version > in unstable than what you upload. Not if testing and unstable are in sync. In this case, the upload to testing-security needs to also go to unstable, and not only to testing-proposed-updates. > The problem seems to be more in rejecting unauthorized uploads to > testing-security than a version problem. No, that's easy. Allow security only via scp to queue/unchecked, and not via anonymous ftp, means only to the few people that have direct access to ftp-master, including a wrapper for the security team. 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: Problems to upload
* Andreas Tille ([EMAIL PROTECTED]) [041217 07:55]: > When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master > but with zero bytes and I'm not allowed to remove this file. The _only_ way to remove failed uploads is to upload a commands file, e.g. with dcut. 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
whois 4.6.24+volatile3 accepted into woody-volatile
Hi, I just accepted whois 4.6.24+volatile3 into woody-volatile. This version reflects the changed address of the .org whois registrary and is adapted to the new query format of the .de whois registrary; besides of this, some IP address mappings were updated. Please see the package changelog for a full description of the changes. The updated package is available as source and as binary for all woody release architectures at http://volatile-ftp.debian.net/debian-volatile/pool/main/w/whois/ . You can also add deb http://volatile-ftp.debian.net/debian-volatile woody-volatile main deb-src http://volatile-ftp.debian.net/debian-volatile woody-volatile main to your sources.list to get all updates to woody-volatile. For further informations about volatile, please see volatile.debian.net. If there are any issues, please don't hesitate to speak with 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
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
* Ingo Juergensmann ([EMAIL PROTECTED]) [050105 07:35]: > On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: > > > Please note that year 2005 has come to an end and > > > the year 2005 is now - even in my mail address! > > Does the new address bring with it a more constructive attitude towards > > volunteers who have contributed countless hours over the years to keeping > > this project running, or should I plan to killfile this one as well? > So you decided to play a "my volunteer work is worth more than your > volunteer work" game? When you do feel annoyed by me, why do you still reply > to my mails? Trolling attitude of yours... I don't understand why you try to make as many developers opposed to you as possible. For me, Steve is an very easy to work with developers, and he doesn't flame easily, so you should ask yourself what mistake you 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
partial patches - server application
Dear all, with ideas and code (and a lot more) from Anthony, I was able to put together the server part for partial patches in a way that it seems to me that it might be included in dak. The resulting files are available from deb http://merkel.debian.org/~aba/debian sid main contrib non-free (or any other combination of suites and components you like) However, there are only the dist files on that place, _no_ downloadable pool is available there. The partial files are included in a subdirectory called diff in each "low-level" directory like unstable/main/source, and have an Index-file pointing to the other files, and one or more (at maximum 14) patches. Such an Index-File looks like: Canonical-Path: dists/sid/main/binary-i386/Packages SHA1-History: f3a0c1972021af11782c661d1bd5214f1d443868 13345332 2005-01-04-1633.27 9891de37f8f56b15e2dcffe6b02afa94f8bfa472 13346502 2005-01-05-1633.08 SHA1-Patches: c3ad4f802238c5becefb1551722fd26d00452db4 33228 2005-01-04-1633.27 2314857b6ffed5f55c3f667ec14bba860818a7ad 66436 2005-01-05-1633.08 This means: If the local file dists/sid/main/binary-i386/Packages has the sha1-sum of f3a0c1972021af11782c661d1bd5214f1d443868, take the patch named 2005-01-04-1633.27 (and this patch has the given size and sha1-sum). Of course, this patch is a gz'ed file. The Patches are ed-style, which is better for size. The script is run once every night at about 23:00 UTC. The script itself is available at http://merkel.debian.org/~aba/tiffani If there are any questions, please don't hesitate to speak with me. Cheers, Andi
Re: partial patches - server application
* Andreas Metzler ([EMAIL PROTECTED]) [050106 11:10]: > On 2005-01-06 Andreas Barth <[EMAIL PROTECTED]> wrote: > [...] > > deb http://merkel.debian.org/~aba/debian sid main contrib non-free > > (or any other combination of suites and components you like) > > > However, there are only the dist files on that place, _no_ downloadable > > pool is available there. > > > The partial files are included in a subdirectory called diff in each > > "low-level" directory like unstable/main/source, and have an Index-file > > pointing to the other files, and one or more (at maximum 14) patches. > > Such an Index-File looks like: > [...] > > Hello, > This looks extremely promising, thank you. > > Is there actually a good[1] reason for keeping the patches both as > plain and gzipped? The good reason is that it was easier to test with them by hand, and I was too lazy to remove them before now - they are gone now, and tiffani is changed to not produce them any more. 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: partial patches - server application
* Florian Weimer ([EMAIL PROTECTED]) [050106 11:45]: > * Andreas Barth: > > This means: If the local file dists/sid/main/binary-i386/Packages has > > the sha1-sum of f3a0c1972021af11782c661d1bd5214f1d443868, take the patch > > named 2005-01-04-1633.27 (and this patch has the given size and > > sha1-sum). Of course, this patch is a gz'ed file. The Patches are > > ed-style, which is better for size. > Is this really a good idea? patch invokes ed(1) to process ed > scripts, and this might lead to execution of arbitrary commands. It is agreed that the usage of patch and ed is _not_ the recommended way for production code (but acceptable for prototype code). However, as already discussed last time, the patches need only a tiny subset of ed that is not only provided by red, but can even be implemented internally in apt. 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 mirror scripts
* Goswin von Brederlow ([EMAIL PROTECTED]) [050131 19:35]: > [EMAIL PROTECTED] (Otto Wyss) writes: > > I guess mirrorer doesn't care for bandwith saving as DpartialMirror, > > correct me if I'm wrong. > Currently it will always redownload the Packages/Sources files as gzip > on every update to fix a bug in the apt methods. But I already > suggested only updating those that don't match the Release file. And, > unless you have an rsync method for apt, it won't rsync files. > > While rsyncing the Packages files sounds like a good idea to save > traffic it actualy is a bit insignificant compared to the daily > traffic of new sources and debs. > > The good news is that Andreas Barth is working on enabling > Packages/Sources diff files for the Debian archive and that would > reduce Packages/Sources updates to ~30K a day instead of the >3MB > download. Once the apt method for this is written mirrorer can use it. There is code available from Anthony on http://ftp-master.debian.org/~ajt/untiffani and http://ftp-master.debian.org/~ajt/apt-qupdate that works well (well, except if merkel was down for a few days like just happened). 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-ftp way to upload packages
* Jose Carlos Garcia Sogo ([EMAIL PROTECTED]) [050131 23:20]: > El lun, 31-01-2005 a las 23:15 +0100, Bartosz Fenski aka fEnIo escribió: > > Hello. > > > > Is there any way to upload packages without using FTP? > > My provider has some queueing stuff and ftp has very low priority... this > > way I get many timeouts uploading packages. > > > > The I have to use .commands files and try to upload one more time. > > > > SSH/SCP has very high priority in our LAN, so this way would be great for > > me... is it possible to use it? > Yes, scp to gluck (or other debian machine) and use dupload/dput from > there. Or just upload into glucks delayed queue into day 0. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-ftp way to upload packages
* Marc Haber ([EMAIL PROTECTED]) [050201 10:10]: > On Mon, 31 Jan 2005 23:26:51 +0100, Frank Lichtenheld > <[EMAIL PROTECTED]> wrote: > ,>scp to a Debian host (like gluck or merkel) and ftp from there. Or > >just scp it to the DELAYED queue on gluck (1day) and let it ftp it for > >you ;) > Does it ftp in time for the daily dinstall? The 0-day queue is ftp-ed about 1 hours before dinstall, IIRC. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
* Al Stone ([EMAIL PROTECTED]) [050202 19:05]: > Ah, this is what I was looking for; thanks. I had tried a > couple of other machines but not merkel. Please see the Developer's Reference, 4.4.2 The ftp-master server: http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-servers-ftp-master | It is restricted; a mirror is available on merkel. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About valid and invalid user names
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) [050205 16:35]: > On Sat, 05 Feb 2005, Marc Haber wrote: > > adduser has two bug reports open where people are asking for user name > > rules to be relaxed. One report wants "." to be allowed in user names, > > another wants usernames to start with numbers. > Allowing the dot is ok. I do think that usernames starting with numbers is > asking for total breakage, though. IMHO even the dot is, eh, difficult. Consider a chown user.group file. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295122: RFA: iproute -- Professional tools to control the networking in Linux kernels
Package: wnpp Hi, anyone who wants to work on iproute is greatly welcome, perhaps also as co-maintainer (and I'm also willing to sponsor people). The reason I intend to give the package away is that I'm not really the great networking guy, but I'll try to give the package a warm home till I can pass it over to someone else -- and as iproute is quite vital for some purposes, I'll do some checks before giving the package away. It is _not_ orphaned, I'm "only" looking for somebody else for maintaining. The description is: This is `iproute', the professional set of tools to control the networking behavior in kernels 2.2.x and later. . At least, the options CONFIG_NETLINK and CONFIG_NETLINK_DEV (or CONFIG_RTNETLINK) must be compiled into the running kernel. . This package is also known as iproute2 upstream and in some documentation. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Take APT 0.6 discussion public!
* Thaddeus H. Black ([EMAIL PROTECTED]) [050216 20:20]: > AJ, having respect for and deference to your inestimable > Debian work, nevertheless I object. When have you ever > seen Martin F. Krafft gratuitously insult anyone? Too often. In this thread, and in others. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: b.d.o -> ldap gateway reeeeaally slow
* sean finney ([EMAIL PROTECTED]) [050218 00:30]: > is this a problem of the server being generally over-taxed, or just > a sluggish ldap implementation? in either case, has someone looked > to see if the ldap db could be optimized/indexed? if not and someone > could send me the slapd.conf i could send some recommendations on things > to speed it up... This is due to the fact that spohr runs woody, and I was told that slapd on woody is a bit bad performance-wise (and also lacks other features). Seems finally be time to get sarge out soon, yes? :) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* John Hasler ([EMAIL PROTECTED]) [050220 15:25]: > Marc writes: > > I would consider it a feature to have mailman work immediately after > > installation on a default system, and the exim4 configuration scheme has > > explicitly invented with that possibility in mind. > I would consider it an obnoxious bug for the installation of a package to > alter my email configuration. At least make enabling the change a Debconf > question. why, in the default case? Is it also an "obvious bug" to change your apache configuration? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Petter Reinholdtsen ([EMAIL PROTECTED]) [050221 12:30]: > [Thiemo Seufer] > > Those would need to go into experimental, where no buildd problem > > exists by definition. > I'm told there are some autobuilders for experimental, and believe > your definition of experimental need some adjustment. :) Thiemo knows that pretty well :) However, if they are overloaded/broken/whatever, the real implications are quite limited, and it doesn't matter for purposes like preparation of the next stable release. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Dirk Eddelbuettel ([EMAIL PROTECTED]) [050222 05:45]: > It delays our releases in the sense that it affects our resources: > - available maintainer and developer time, You mean, we have some great people working as porters and also giving a general helping hand, and we would loose them if we throw most arches out? :) > - cpu cycles (witness Wouter's request to compile big packages rarely), It is _definitly_ a bad idea to "just upload" packages every few days. This has nothing to do with buildds, but just with general good or bad preparations. > - security response time (more builds to do) that is not an issue. > and that it > - increases the load on infrastructure (t-p-u, security) There's no real difference between 2 and 11 archs > - scarce resource such as release managers, ftp admins, ... no. Frankly speaking, the most costly point with other arches is that there are too often these useless discussions. _That_ is beyond all the most expansive 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Matthew Palmer ([EMAIL PROTECTED]) [050222 06:20]: > Security autobuilders are on their way. You could make the argument that if > we only had a couple of architectures we wouldn't really need security > autobuilders, but I think that automating everything that can be automated > is a Good Thing. We have security autobuilders since woody. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
* Goswin von Brederlow ([EMAIL PROTECTED]) [050222 15:15]: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: > >> Is the problem that you use apt-get to install the current version, and > >> then check what you got? Because you can't tell apt-get to install > >> at least version X else fail? > > Yes, that's how it works currently. > > > > Since this also makes autobuilding experimental harder, work is being > > done to use ``apt-cache policy'' output to determine whether the right > > version of a package is available and break off if not, but it's still > > got some bugs (including situations where the build is broken off > > because sbuild (incorrectly) thinks the right version of a package isn't > > available). > apt-get build-dep should be improved to be buildd useable > instead. It's is wastefull to have two seperate and differently buggy > implementations floating around. It would be definitly a good idea to improve apt-get build-dep, and make sbuild using a solution based on apt. But, I'm not going to hold my breath for that to happen. :) And, as always, patches 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
* Wouter Verhelst ([EMAIL PROTECTED]) [050222 18:00]: > On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote: > > I can always tell you how to do things and you never have to > > listen. But my opinion stands that improving apt-get is the right > > thing to do, not having two divergent systems. > sbuild includes some centralized build-dependency override system which > would be a bad idea to use with apt-get, but which is part of its > build-dependency parsing code. > How you want to merge the two considering the above is a mystery to me > :-) I think this is possible with some special option to apt. In fact, I think this would make a nice target - but, as it is with nice targets, they're usually not the things that are implemented, but just the pressing targets. :) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the ongoing xfree86 buildd saga
* Ingo Juergensmann ([EMAIL PROTECTED]) [050223 22:55]: > On Wed, Feb 23, 2005 at 12:57:25PM -0800, Thomas Bushnell BSG wrote: > > > > See why the current buildd system is obsolete? > > I've never disagreed with the fact that the current buildd system is > > creaking. > > What would it take for multibuild to succeed? or something else? > People who care and have the will to finish it. As always. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* Kalle Kivimaa ([EMAIL PROTECTED]) [050304 17:35]: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > Source code is source code. Obfuscated or not does not change that. It > > fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you > > would have to show that it is not source and the gcc already prooves > > you wrong there. If you use 'obfuscation' or in other words > > 'readability' as measurement what source is then a lot of perl code > > would not qualify in my eyes. > Source code is commonly defined as "the author's most preferred source > of making modifications". No. There are people running around claiming this, but that doesn't make it truth. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debootstrap-farm (was: Automatic building of (parts of) the archive)
* Frank Küster ([EMAIL PROTECTED]) [050305 20:00]: > While I only read it back then, I wanted to actually do the stuff > described in the cheat sheet. However, it mentions the command > "debootstrap-farm". I can't find anything about it. What is changed in > this command, compared to standard debootstrap? Actually, I added all extra things in that to the commands listed, so just use the normal debootstrap, and everything works. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* Henning Makholm ([EMAIL PROTECTED]) [050307 09:50]: > Scripsit Nick Phillips <[EMAIL PROTECTED]> > > > I also think that it would be a very good thing if we were to use our > > collective discretion more often -- to say, for example, "well, you could > > call this source, but it's bloody horribly ugly and painful source, > > and we don't want that kind of crap in Debian" a bit more often. > Yes, but we shouldn't act as if it was a _freedom_ problem. It's a > _quality_ problem and should be treated as such, i.e. without invoking > the DFSG. Agreed. Especially as "it's too horibly broken" is by itself a serious bug. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
* John Hasler ([EMAIL PROTECTED]) [050307 14:50]: > Henning Makholm writes: > > Yes, but we shouldn't act as if it was a _freedom_ problem. > If it was deliberately made bloody horribly ugly and painful in order to > make changing it difficult, it's a freedom problem. > > There are sure to be borderline cases, but it usually isn't all that hard > to tell the difference between appalling style and deliberate obfuscation. My guide for freedom issues within Debian is the SC and the DFSG. What is yours? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
* Clint Byrum ([EMAIL PROTECTED]) [050307 18:15]: > Please understand.. I want Debian to be great. I want it to "release > when it is ready." Under the current system, being ready means achieving > an enormous number of goals that benefit a very small number of users. For sarge, the number of architectures is not the holding problem. For post-sarge, there has been some discussion inside the release team and the ftpmasters that will be published soon. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is xprint still used by mozilla, etc?
* Torsten Landschoff ([EMAIL PROTECTED]) [050311 22:55]: > On Thu, Mar 10, 2005 at 09:18:19PM -0500, Joey Hess wrote: > > Like I said at the head of this thread I explicitly added xprt-xprintorg > > to the deaktop task on user request. However, nothing I've seen so far > > seems to be a solid reason to keep it. OTOH, if the high priority > > debconf question goes away, I don't care if it's left in. > Why doesn't that option default to 600dpi anyway? Don't think there are > many people out there who can see the difference between 600 and 1200 > dpi... It's trivially seen if you print to a real high-quality device, as the 600dpi the too-large pixles can be seen. However, for usual purposes, you don't need 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]: > Since the all but one of the other arch buildd's have empty > needs-build queues, it is harmless to force them to execute a > recompile and costs no scarce resources. I did check this before > uploading. Even in the case the buildds otherwise idleing, it costs time of the buildd admin to check the log and sign the upload. > If, perhaps, there was a clear indication of the buildd ordering > policy, then it could be properly used. Until then, I go on the basis > of guesswork. The ordering applied is (in this order, first difference wins) - >= standard - not uncompiled - priority of the package - priority of the section - name That all is BTW visible from the code (or you could just ask). 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 04:25]: > Steve Langasek <[EMAIL PROTECTED]> writes: > > The queue ordering is entirely automatic, and AIUI the queue(s) is (are) > > sorted by: > > > > - target suite > > - package priority > > - package section > > - package name > > > > I personally believe it would be beneficial to prioritize by upload urgency > > as well (probably as a sort criterion between package priority and package > > section), but the w-b maintainers disagree. > I see, the problem is clearly that gnucash is in the "Extra" priority > instead of the "Optional" section where it belongs. I'll request the > ftpmasters to change it. Our goal is that the queue gets empty from time to time, and so, priority shouldn't prevent a package from being built. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Matthew Palmer ([EMAIL PROTECTED]) [050312 05:25]: > On Fri, Mar 11, 2005 at 07:14:35PM -0800, Steve Langasek wrote: > > The queue ordering is entirely automatic, and AIUI the queue(s) is (are) > > sorted by: > > > > - target suite > > - package priority > > - package section > > - package name > > > > I personally believe it would be beneficial to prioritize by upload urgency > > as well (probably as a sort criterion between package priority and package > > section), but the w-b maintainers disagree. > I'm trying to work out why package *section* matters at all. Package name > is a bit odd, too, but including the section in there is just totally whack. Because we want packages in base to be preferred, as well as packages in libs. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Ingo Juergensmann ([EMAIL PROTECTED]) [050312 14:15]: > On Sat, Mar 12, 2005 at 02:06:24PM +0100, Martin Zobel-Helas wrote: > > As it has been said earlier, the machines are back, but just need to > > catch up. So just waiting might be the easiest thing to do. > More machines can catch up faster than few can do. > When one machine out of a dozen machines is unavailable, it has less impact > than one machine failure out of two machines, although the chances will > raise that a machine will fail somewhen with more machines. But the impact > is less critical... If you take a look at http://buildd.debian.org/stats/graph2-week-big.png, you can e.g. see for mipsel exactly at which date the slow and at which the fast machine became available again. The fast machine alone is able to keep up with the usual upload rates. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Matthew Palmer ([EMAIL PROTECTED]) [050313 01:05]: > On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote: > > Er, packages *do* eventually get built; they just don't get built in any > > kind of FIFO order. > Er, no. Unless there's some sort of aging process (not yet described in the > threads here) which will result in an extra package called zappa in section > x11 from eventually being promoted above a package aardvark in section > admin, it is entirely possible that package will never be built. All it > requires is for the rate of new packages entering the queue before zappa to > be equal to or greater than the rate of packages leaving the queue due to > having been built or removed. If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Andreas Barth ([EMAIL PROTECTED]) [050313 23:15]: > * Thomas Bushnell BSG ([EMAIL PROTECTED]) [050312 02:05]: > > If, perhaps, there was a clear indication of the buildd ordering > > policy, then it could be properly used. Until then, I go on the basis > > of guesswork. > The ordering applied is (in this order, first difference wins) > - >= standard > - not uncompiled > - priority of the package > - priority of the section > - name Which goes in front of that ordering is that all buildds check wanna-build in the order of the priority of the suites, i.e. security uploads first, than stable, ..., but only take packages not in noauto, and, if all queues are empty, also take up packages in noauto_weak in the same order (both are individual settings at each buildd). 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Matthew Palmer ([EMAIL PROTECTED]) [050313 23:50]: > I think I slightly misunderstood the "ordering by section" bit -- I was > assuming an alphabetical ordering by section. So once base and libs have > had their priority building, what's the ordering after that? Alphabetical > by section, or does it go straight into a alphabetical by package name? It is a highly ordered list, more or less libs+base first, than devel, shells, perl, python. After that graphics, admin, utils. Just to look at the other side of the sorting order, at the end of the list is hamradio, non-US and embedded. The large ones like gnome and kde are in the middle of the list. Please see wanna-builds source for the full 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]: > On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote: > > Our goal is that the queue gets empty from time to time, and so, > > priority shouldn't prevent a package from being built. > > How often should the queue be emptied, or when will an architecture be > declarared not-keeping-up? In light of http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages at least once per day for etch. > According to > http://people.debian.org/~igloo/needs-build-graph/index.php?days=30 > arm hasn't been empty in over 3 weeks, and it's getting worse still. > s390 is also rising steeply. It is not only a question of days, but also, what expectations we have for the architecture. If we e.g. know that in the next days a buildd will be switched on again (as the buildd crashed, and the local admin is away), we are of course a bit more tolerant. Also, vacations are accepted. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:55]: > On Mon, Mar 14, 2005 at 12:01:59AM +0100, Andreas Barth wrote: > > It is a highly ordered list, more or less libs+base first, than devel, > > shells, > > perl, python. After that graphics, admin, utils. Just to look at the > > other side of the sorting order, at the end of the list is hamradio, > > non-US and embedded. The large ones like gnome and kde are in the middle > > of the list. Please see wanna-builds source for the full list. > Given how low hamradio (and the like) are prioritised, I suggest that we > get smarter about 'tesing' and omit some sections on some architectures. We won't omit some sections on some architectures, but all sections on some architectures :) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Robert Millan ([EMAIL PROTECTED]) [050314 10:50]: > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > > > > To be eligible for inclusion in the archive at all, even in the > > (unstable-only) SCC archive, ftpmasters have specified the following > > architecture requirements: > > > > [...] > > > > - binary packages must be built from the unmodified Debian source > > (required, among other reasons, for license compliance) > Is this a simple sanity requirement (i.e. no hacked crap being uploaded to the > archive), or does it imply that all packages in base (or base + > build-essential) > need to be buildable from unmodified source? This is a legal/DFSG requirement: We can't distribute binaries without source. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Tollef Fog Heen ([EMAIL PROTECTED]) [050314 10:55]: > * Steve Langasek > > | If you are planning any other transitions that will affect a lot of > | packages, please let us know in advance. We will need to complete the > | larger transitions as fast as possible, to get testing back into a > | nearly releasable state quickly again after the release. > Multiarch. I have yet to see a proposal how to do multiarch in the right way. This might be partly related to the fact that I don't follow all lists around, but well - this needs to be done. However, given the timeframe, I seriously doubt that we can do multiarch in time for etch. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Sven Luther ([EMAIL PROTECTED]) [050314 11:20]: > On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote: > > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > > > - the port must demonstrate that they have at least 50 users > > How do you demonstrate that? Via popularity-contest? > But then, popularity-contest installation per default was dropped for > debian-installer rc3, so ... We don't say "it needs 50 entries in popularity-contest", but just: 50 users. How this is demonstrated, may be different. Enough traffic on the porter list might also be enough - or enough bug reports coming from that arch. Or whatever. I don't expect that to be the blocking critieria for any arch. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Sven Luther ([EMAIL PROTECTED]) [050314 11:35]: > Well, but wouldn't reenabling the popularity-contest by default for sarge help > a lot on that ? There was a technical reason why it was removed - more or less, if you want this changed, you need to submit a patch (but it might be too late now, as RC3 should be more or less building). 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Goswin von Brederlow ([EMAIL PROTECTED]) [050314 15:35]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > * Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]: > >> On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote: > >> > Our goal is that the queue gets empty from time to time, and so, > >> > priority shouldn't prevent a package from being built. > >> > >> How often should the queue be emptied, or when will an architecture be > >> declarared not-keeping-up? > > > > In light of > > http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html > > the release architecture must have N+1 buildds where N is the number > > required to keep up with the volume of uploaded packages > > at least once per day for etch. > That means no more m68k. Given that some packages compile up to 12 > days there will be plenty of times the queue doesn't empty once per > day. needs-build can be empty even if packages _are_ currently building. > I would like to see some stats showing on how many days in the last > year an arch reached 0 needs-build. I highly doubt that any arch > managed to do it every day troughout the last year. You know why goals are important? 0 needs-build is definitly a goal we should work to. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vancouver meeting - clarifications
ase architecture, we can and will improve our scripts. Having said this, this all doesn't exclude the possibility for a non-release arch to have some "testing" which can be (mostly) in sync with the release architectures testing - just that if it breaks, the release team is not forced anymore to hold the strings together. For example, the amd64-people are doing something like that right now. We are all committed to the quality of debian, and for faster releases, and this proposal is one where we think we can help scale to more packages and architectures, and still get the release time to an acceptable level. I hope that this mail is able to shed some light onto these issues. Please accept my apologies for the missing information in the first mail. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
* Tollef Fog Heen ([EMAIL PROTECTED]) [050315 10:50]: > * Andreas Barth > | For example, the more architectures are included the longer the migration > | testing script takes. We are already at the limit currently (and also > | have out-of-memory issues from time to time). For example, currently we > | restrict the number of some hints to only 5 per day to keep up the > | scripts. Also, the udebs are not taken into account, which requires more > | manual intervention. With a lower number of release architecture, we can > | and will improve our scripts. > Debian has a fairly big chunk of cash lying about. If we have > problems doing testing migration because of not enough hardware, this > is something I think we should spend money on. Or we could ask a > sponsor (hi HP!:) if they would be willing to donate some more memory. Well, that was one of the examples where we pay a price for more architectures. Of course, the testing migration script is not all, and this problem can be solved, but I think we should not forget that we pay a price - even if at the end, we think the price is acceptable. (And, BTW, newraff is a quite mature box. Of course, there is always more and better hardware available, but newraff is already a very good machine. And, we want to give the testing migration script more tasks, like handling of the udebs, which puts load off from human being and on into a script. But that increases the ressources the script uses.) One of the problems is that for every decision (and even for the decision to don't make a decision), we pay a price. There are prices I'm not willing to pay (like another release cycle of the length of sarge) - but well, if Debian goes into that direction, I'll go out of the way. Other people are not willing to pay other prices. My goal is to find a route to take that as many people as possible are considering as acceptable. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Steve Langasek ([EMAIL PROTECTED]) [050315 00:00]: > Colin mentioned the possibility of adding an "Architecture:" field > instead. That seems better than an etch-ignore tag anyway, for what you > want to achieve here. Yes, that sounds well. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Colin Watson ([EMAIL PROTECTED]) [050315 12:55]: > I wonder if we could simply use the current support in britney for > declaring that an architecture isn't keeping up to date and that any > problems with it shouldn't block the rest of testing. In that case, it might be better in the long term to make some "synchronize" runs outside of current britney, as that might be better in terms of speed and memory 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
Hi, * Tollef Fog Heen ([EMAIL PROTECTED]) [050315 12:40]: > * Andreas Barth > | (And, BTW, newraff is a quite mature box. Of course, there is always > | more and better hardware available, but newraff is already a very good > | machine. And, we want to give the testing migration script more tasks, > | like handling of the udebs, which puts load off from human being and on > | into a script. But that increases the ressources the script uses.) > (As I'm not a RM/RA and don't have access to newraff, I didn't know > newraff ran out of memory due to the testing scripts -- in fact, I > thought it was doing very well, given that auric used to have problems > completing the testing scripts at all (IIRC), while aj said the > scripts take about 20 minutes on newraff now (he posted this in > January).) Well, but the saved time is already used: We rerun britney sometimes multiple times a day. That makes resolving of some critical issues much faster. So, we can only trade one issue with another. (And please remember that even if the proposed policy would become effective without any change, that doesn't necessarily mean the end to a certain architecture, but just that the the amount of extra work the architectures had been for the release team and other core teams needs to go down. Of course, having better support is my prefered way, but if that doesn't work, getting the number of archs down is another possiblity.) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
* Peter 'p2' De Schrijver ([EMAIL PROTECTED]) [050315 13:45]: > > | - the release architecture must have successfully compiled 98% of the > > | archive's source (excluding architecture-specific packages) > > well, that's just an "the architecture is basically working", so that we > > don't get too many RC-bugs because of architecture-specific issues, and > > also don't get too many packages kept out of testing for not all archs > > being built. Of course, the 98% is not engraved into stone, and might just > > be another arbitrary high number like 97.5%. From looking at the usual > > level where we start noticing problems with testing migrations, a number > > in this range is sane. > I strongly disagree with this. There is a need for a set of base > packages to work, but it's entirely reasonable to have a release for eg > m68k without KDE or other large package sets. It's not as if debian/m68k > would be unusable without KDE packages for example. You might try to convince me that KDE is architecture-specific :) I hope you can agree that we need to say that "almost all" packages that should be build are build. And I consider 97.5% to be a reasonable level. Also, if we exclude too much, we might start to ask the question why we should do a stable release for an arch that builds only a very minor part of the archive. But the "excluding architecture-specific packages" gives of course some possibilities which packages count and which not. > > | - the release architecture must have a working, tested installer > > I hope that's obvious why. :) > As long as FAI or even raw debootstrap counts, I can agree here. Any installer inside Debian. Of course, we can't tell people "To install Debian, you first need to install Gentoo" :) > I fail to see why less archs allows you to improve the scripts. You can > always improve them, regardless of how many usage they get. I believe > there is sufficient algorithm knowhow in the debian developer community > to solve the scalability problems. Anyone who provides better scalability for britney is 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Henning Makholm ([EMAIL PROTECTED]) [050315 12:45]: > Scripsit Steve Langasek <[EMAIL PROTECTED]> > > In this instance, the current blocker is only an issue at all because > > ftp-master is not scaling well to handle all of the wanna-build ssh > > connections that are implied by the activation of another build queue... > Is there an underlying reason why the wanna-build management for all > architectures needs to happen on ftp-master? For any architecture that builds directly from accepted, having wanna-build on ftp-master has some improvements. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050315 20:15]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > | - the release architecture must have N+1 buildds where N is the number > > | required to keep up with the volume of uploaded packages > > The reason for this proposal should be instantly clear to everyone who > > ever suffered from buildd backlogs. :) > I note that you have not answered why N must be <= 2. Can you please > explain that part? Please remember what I said at the top of my mail: | I'll answer the reasons from the release point of view - but | please remember that there are also ftp-masters/mirror concerns that the | release team doesn't directly take care of, but which are of course still | important. So, now to the answer: I can't remember any release team reason for that part, but that might be due to any of these reasons: 1. It was discussed during I was not in the room (which might be easily the case, as I was sick for half the time) 2. There is no release team reason - but from another team. Sorry for not being able to give a final answer on 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050316 01:05]: > How does one become an ftpmaster or release manager? How were the > current ones chosen? Do they simply choose their successors? After working on release issues for some time (and offering hints etc), Collin asked me whether I want to become a release assistent. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]: > Andreas Barth wrote: > >If that happens for a too long period, we might consider such an > >architecture to be too slow to keep up, and will eventually discuss > >about kicking it out of the architectures we wait for testing migration > >at all, or even kicking it out of testing at all. Not waiting for such > >an arch has happened and might happen again. > I think it makes sense to shorten the list of arches we wait upon for > testing migration, but I fail to see the usefulness of removing an arch > from testing. If we don't wait for an arch, it gets out-of-sync quite soon, and due to e.g. legal requirements, we can't release that arch. (In other words, if an arch is too long ignored for testing, we should remove it, as we can't release it in any case.) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) [050317 01:30]: > On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: > > In article <[EMAIL PROTECTED]> you write: > > >I have an e3500 to replace both auric and vore (and the raid), but I > > >haven't gotten an ok from James to do so yet. > > That would cut the number of sparc buildds down to one, when two are > > required for RC archtectures under the new proposal. > That's ok because two buildd's can run on the one machine. It has 6 cpu's. That still doesn't suffice the N+1-requirement. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Ben Collins ([EMAIL PROTECTED]) [050317 03:25]: > On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote: > > Ben Collins <[EMAIL PROTECTED]> writes: > > > On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: > > > > In article <[EMAIL PROTECTED]> you write: > > > > >I have an e3500 to replace both auric and vore (and the raid), but I > > > > >haven't gotten an ok from James to do so yet. > > > > > > > > That would cut the number of sparc buildds down to one, when two are > > > > required for RC archtectures under the new proposal. > > > > > > That's ok because two buildd's can run on the one machine. It has 6 cpu's. > > > > That cannot be the requirement. The point has to be an additional and > > independently functioning piece of hardware. If the disk blows or it > > is compromised or something, the others should be able to continue. > The requirement sucks, lets leave it at that. If the machine dies, I can > have two to replace it within a day or two. Ah, so why is vore down now for some time now? If it's so easy to replace a broken machine, why don't you just do it? (And, BTW, you might be on vacation, sick, ... - we need more than just one machine.) 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
* Andreas Barth ([EMAIL PROTECTED]) [050317 10:54]: > Ah, so why is vore down now for some time now? If it's so easy to that should read as auric of course. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
* martin f krafft ([EMAIL PROTECTED]) [050317 17:10]: > Why can't we have separate sid->testing propagation for each arch, > then freeze testing as before, get rid of RC bugs, and release? Because than the security team may need to fix 11 different source packages (or how many architectures we actually release) instead of 1. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
* Mike Fedyk ([EMAIL PROTECTED]) [050317 19:30]: > Andreas Barth wrote: > >If we don't wait for an arch, it gets out-of-sync quite soon, and due to > >e.g. legal requirements, we can't release that arch. (In other words, if > >an arch is too long ignored for testing, we should remove it, as we > >can't release it in any case.) > That would be understandable with the intention to release all arches at > the same time. I was speaking about release archs (i.e. the archs where the release team has to keep the strings together). For others archs, things may be different. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bts2ldap down?
* Henry Jensen ([EMAIL PROTECTED]) [051117 10:13]: > This morning I cannot reach the LDAP server - again. > Has something changed again or is bts2ldap.debian.net just down? it was just down, and is restarted right now. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
* Joey Hess ([EMAIL PROTECTED]) [051121 16:34]: > The LDAP interface is not production quality enough to be used by > anything IMHO. It seems to be down or moved to somewhere else half the > time. It should now have a permanent address at bts2ldap.debian.net, so at least the moving around should be part of the history. However, sadly, it's still only project and not product quality. Any help on that would be welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what does Enhances *really* mean?
* Peter Samuelson ([EMAIL PROTECTED]) [051122 12:58]: > I thought that Enhances is merely the converse of Suggests, and that it > was invented for situations where it is problematic or inconvenient to > use Suggests directly, as when a main package wishes to suggest a > non-free package. > > In which case, of course, if "foo Depends: foo-data", then "foo-data > Enhances: foo" is already implied. Agreed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
* Goswin von Brederlow ([EMAIL PROTECTED]) [051123 15:51]: > - binNMU version scheme changed > > The developer reference _still_ states binNMU should be versioned as > 1.2-3.0.1. The DAK will no longer accept this. I am sorry that the developers reference is a bit lagging currently. Do you have some new wording available, or do you want till I find time to fix it myself? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
