Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]: > Where does it say the scope for 4. Autobuilding is "buildds must not > fail" ? There are always bugs in any document. For sarge, we e.g. sarge-ignored some MTAs which didn't provide -bs, though LSB requires that. Now, we adjusted the policy to make it legal (as long as they conflict with lsb of course). Nothing wrong with that, the text isn't written in stone. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]: > That was not a link before it was changed before sarge release, in July > 2004. The link was added later because people were barking around. The meaning was always the same. Anyways, July 2004 is a *bit* history now, don't you think so? > So, what is written on http://www.debian.org/Bugs/Developer#severities > doesn't count (not to say it's crap), and it's not necessary to change > it. If you disagree with what is written on the page, you might want to ask [EMAIL PROTECTED] for clarification, or you could appeal to the Technical Committee, or you could ask the developers in a GR. Until you succeed at at least one of the ways, the definition as written down by a member of [EMAIL PROTECTED] stays valid. As it is always. Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]: > Andreas Barth a écrit : > >A violation of the parts of the debian policy as listed on > >http://release.debian.org/etch_rc_policy.txt is serious level (that > >should be the same as the must-directives in policy, but - well, I hope > >that I have finally time post-etch to sync that finally). > > > >Any other policy violation is at most important level (unless it > >conincides with one of the other criteria for RC bugs, of course). > > > > Note that what we are discussing (must have in targets debian/rules) are > listed on http://release.debian.org/etch_rc_policy.txt As vorlon said, that is listed under the heading of "4. Autobuilding", so the scope is "buildds must not fail" of this rule. That is why I asked to file the cases where buildds failed as serious, and the others as important (and cases where "Packages in the archive must not be so buggy [...] we refuse to support them." as serious as well, that is under section "5. General"). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:25]: > On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> > wrote: > > * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: > > > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL > > > PROTECTED]> wrote: > > > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: > > > > > Note how subtly the Etch RC policy removes the first alternative of > > > > > the > > > > > serious bug description... > > > > > > > > Which do you mean? Please read the Etch RC policy. It tells: > > > > | In addition to the issues listed in this document, an issue is release > > > > | critical if it: > > > > | [...] > > > > | * in the maintainer's opinion, makes the package unsuitable > > > > | for release > > > > > > > > So, what does the Etch RC policy remove from the bugs.d.o description? > > > > > > 'is a severe violation of Debian policy (roughly, it violates a "must" or > > > "required" directive), or' > > > > The html-code for this part is: > > serious > > is a http://release.debian.org/etch_rc_policy.txt";>severe > > violation of Debian policy (roughly, it violates a "must" or "required" > > directive), or, in the package maintainer's opinion, makes the package > > unsuitable for release. > > > > So, obviously http://www.debian.org/Bugs/Developer#severities defines > > that "severe violation of Debian policy" means anything referenced in > > the etch_rc_policy-document. > > Yeah, right, whatever, as soon as etch is release on December 4th... What do you intend to say by that? The definition of serious was already that way when I was looking at the release from the very outside, before I was a DD even (ok, it was sarge_rc_policy.txt, and not etch at that time). It has *nothing* whatsoever to do with the planned release date ... But I need to admit that I get sick, seriously sick. If someone doesn't agree with something, he just says "you do it wrong just for release of etch on $date". I really hate that. Especially when it's about things that are done that way since ages, but someone just recently has become aware of that. That really takes the fun away from Debian for me. I don't know if that's what you intend, but that's what you achieve. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]: > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> > wrote: > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: > > > Note how subtly the Etch RC policy removes the first alternative of the > > > serious bug description... > > > > Which do you mean? Please read the Etch RC policy. It tells: > > | In addition to the issues listed in this document, an issue is release > > | critical if it: > > | [...] > > | * in the maintainer's opinion, makes the package unsuitable > > | for release > > > > So, what does the Etch RC policy remove from the bugs.d.o description? > > 'is a severe violation of Debian policy (roughly, it violates a "must" or > "required" directive), or' The html-code for this part is: serious is a http://release.debian.org/etch_rc_policy.txt";>severe violation of Debian policy (roughly, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release. So, obviously http://www.debian.org/Bugs/Developer#severities defines that "severe violation of Debian policy" means anything referenced in the etch_rc_policy-document. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]: > Note how subtly the Etch RC policy removes the first alternative of the > serious bug description... Which do you mean? Please read the Etch RC policy. It tells: | In addition to the issues listed in this document, an issue is release | critical if it: | [...] | * in the maintainer's opinion, makes the package unsuitable | for release So, what does the Etch RC policy remove from the bugs.d.o description? > Anyways, I've always thought the bts severity levels and release > criticality were orthogonal things. i.e. it's more complicated than > just saying "critical, grave and serious levels are RC". That is wrong. > There are > important or even normal issues (as per definition of the severity > levels) that are more release critical than serious (again, as per > definition of the severity levels) bugs. Wrong. A bug is release-critical :<=> the bug has severity serious, grave, critical and has not been given an excemption by the release team > But yet, violation of the Debian policy should be granted serious level. > etch-ignore is here to make the issue not release critical. Wrong. Etch-ignore is for exemptions for issues that otherwise match the definition of release critical on that page. It is not for "normal sorting" of issues. A violation of the parts of the debian policy as listed on http://release.debian.org/etch_rc_policy.txt is serious level (that should be the same as the must-directives in policy, but - well, I hope that I have finally time post-etch to sync that finally). Any other policy violation is at most important level (unless it conincides with one of the other criteria for RC bugs, of course). Cheers, Andi Debian Release Manager -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 15:06]: > Among all of the bugs reported by lintian, one concerns a lot of > packages, the presence of the clean, binary, binary-arch, binary-indep > and build targets. This is required by both the section 4.9 of the > policy and the Etch release standards [1]. Here is the list of affected > packages. What to do with them? If the bug also affects our autobuilders (especially the package has binary-any-packages), serious. Otherwise, important severity. If a package is totally broken (which might be in this case), serious might also be ok - but that needs to be decided on a case-by-case-basis. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
* Tshepang Lekhonkhobe ([EMAIL PROTECTED]) [061019 18:09]: > On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > >[Aurelien Jarno] > >> I have just run lintian on all the archive (amd64) for both binaries and > >> sources, and the results are a bit scary. It looks like a lot of > >> maintainers are uploading their packages, and don't really care with the > >> policy. > > > >What is the technical problem triggered by the packages with this > >lintian message? Is the autobuilders able to build these packages? > >If the autobuilders fail, I recommend you report that as a important > >or serious problem, and it it isn't, I recommend you report it as a > >normal bug. > > Doesn't policy violation warrant Critical severity? No. Please see the top of http://release.debian.org/etch_rc_policy.txt for which bugs are critical, grave and serious. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#393411: Source package contains non-free IETF RFC/I-D's
* Simon Josefsson ([EMAIL PROTECTED]) [061016 13:19]: > I went over many packages looking for names of likely non-free files, > and there may be false positives. If this is the case for your > package, I'm sorry for the noise. Sorry, but that is unacceptable behaviour. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making SELinux standard for etch
Hi, * Manoj Srivastava ([EMAIL PROTECTED]) [061007 00:41]: > I brought this over on the debian-installer mailing list, and > suggested that we ship SELinux installed, but turned off by default; > and a README or a short shell script fr the local administrator to > enable SELinux. Our support at this point is better in some respects > to any other distribution (selecting and installing modular policy > modules, for instance). All the core packages support SELinux (unlike > in, say, Ubuntu). > >We can do this by adding selinux-policy-refpolicy-targeted, > and the dependencies, to the standard install. I am happy that SELinux is so good now. However, I think it is a bit late to make such changes now. > As per policy, I am raising a balloon about ths issue; I think > if we ship vacation, finger, and sharutils, we can also ship > mandatory acess controls in the standard distribution :) [EMAIL PROTECTED]:~$ zcat /org/ftp.debian.org/ftp/dists/testing/*/binary-i386/Packages.gz | grep-dctrl -P vacation -s Priority Priority: extra We already fixed that pre-sarge, btw. :) If people think finger and sharutils are not important enough anymore to still be standard, we can still fix that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apache 2.2 uploaded to unstable (was: Re: Bug#389053: apache2-common: API module structure `perl_module' in file /usr/lib/apache2/modules/mod_perl.so is garbled)
* Tollef Fog Heen ([EMAIL PROTECTED]) [061001 22:00]: > I'll be filing policy- and uninstallability bugs on quite a bunch of > packages over the next days. If you maintain an apache module which > does not depend on apache2-common: shame on you, please add a dependency > on apache2.2-common. If you maintain an apache module which does depend > on apache2-common: please change it to apache2.2-common, recompile and > test the module. I'm not so sure I like to see another 50 RC bugs only for packages already in etch, just for renaming apache2-common to apache2.2-common. Is/Was that really necessary? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release update: release notes, base freeze
* Andreas Barth ([EMAIL PROTECTED]) [060928 08:56]: > we hope to address with a General Resolution; or will be fixed with the > removal of mozilla or the addition of X.org 7.1. This means that we are "removal of mozilla" means of course the old all-in-one-suite that is no longer supported by upstream, not the web browser itself. We thought that as obvious, but as I already got the first flame, it isn't so obvious for some others. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
* Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]: > 2) [technical] Remove the single point of failure by adding a > Distribution: field to debian/control, say. The package will be > rejected if the two fields in control and changelog do not match. or just make dpkg-buildpackage fail if that happens (or rather dpkg-genchanges), which isn't too hard to achive actually. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: release update: freeze, RC Bug count, python, toolchain
Hi, * Adam Borowski ([EMAIL PROTECTED]) [060809 12:19]: > On Tue, Aug 08, 2006 at 11:45:46PM +0200, Andreas Barth wrote: > > Full IPv6 support > > = > > > > There has been some confusion about the Etch release goal about IPv6. Our > > understanding of that release goal is that all network applications should > > be > > able to work with both IPv4 and IPv6. Also stateful packet filtering should > > work for both protocols. Please consider all bugs tagged "ipv6" to be > > upgraded to at least important - or even better, fix them. > > How invasive ways are welcome/allowed? That's a good question. > For example, I use pound (a reverse proxy/URL redirector/SSL wrapper). > * unstable has 2.0 > * I use 2.0.9 with my partial (listen-only) IPv6 > * upstream just released 2.1 > The maintainer seems to be MIA. I didn't unload my patches (IPv6, WebDAV) > into the BTS yet as upstream kept saying they'll release "tomorrow" or "in > three days from now" for a few months. The new stable upstream release got > released on Saturday, but I've been sick so I didn't port my IPv6 patch to > 2.1 yet; it should be done and tested soon, though. > > So, should I: > a) make a backport to 2.0; or > b) provide patches for the current upstream (2.1) only; or > c) do a complete overhaul, including unrelated issues; giving the maintainer >a tarball and svn > > (Of course, asking the maintainer again is the first thing to do) Well, what I would do is to: 1. speak with the maintainer; 2. if that fails, check if the maintainer is still active (see section about MIA maintainers in the developers reference); 3. if the maintainer is no longer active, let the QA group orphan the package, adopt it and fix it; 3a. if this takes too long, put a minimal-invasive new upstream version into experimental and encourage people to use it (via planet, ...). Of course, this are only some ideas from the top of my head; there might be a more appropriate way to deal with the issues in a case. BTW, IMHO there is never an issue with putting patches to the BTS, even if they're intended for future releases (as long as they work). Why not? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#380173: ITP: deb822 -- Read and manipulate RFC822-like files (e.g. .dsc and .changes)
* Thomas Viehmann ([EMAIL PROTECTED]) [060728 08:36]: > The copyright file is broken. cf. #336982 > > > deb822 abstractifies the RFC822 format used in Debian's control files. You > > can use a deb822 object like a Python dictionary, referring to control > > fields > > as dictionary keys. > > Is it really worth doing this? I would like it, yes. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
* Simon Richter ([EMAIL PROTECTED]) [060726 15:38]: > Andreas Barth wrote: > > > Suggests is *way* weaker. The Needs would trigger automatic installation > > with any tool. Actually, if > > A->B (depends), B->C(depends), and C->B(Needs), then A won't be > > configured until both B and C are installed. > > What stops us from using Recommends for that. The definition for > Recommends used to be "you may not install these, but you should have a > reason for it", which is exactly the foo/foo-data case. actually, Recommends are still weaker. I personally see a gap between Depends and Recommends, which is Needs. If I'm the only one, it's ok. If other people see the same gap, we might want to fix it. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
* Frank Küster ([EMAIL PROTECTED]) [060726 14:49]: > What about using Suggests instead of "Depends-for-being-useful"? Suggests is *way* weaker. The Needs would trigger automatic installation with any tool. Actually, if A->B (depends), B->C(depends), and C->B(Needs), then A won't be configured until both B and C are installed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
* Stephen Gran ([EMAIL PROTECTED]) [060726 13:46]:
> This one time, at band camp, Andreas Barth said:
> > Hi,
> >
> > * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]:
> > > But, for example, foo <-Depends-> foo-data is not usually an example
> > > of a silly dependency.
> >
> > Actually, there is no reason why foo-data needs foo configured before
> > being configured, but there might be reason for the other direction.
> > Why not inventing some new "Depends-for-being-useful" from foo-data to
> > foo, and having Depends cycle-free?
>
> Like, say, Enhances: ?
>
> I always thought that basically meant "useless by myself, but is useful
> for foo". Pity it never got implemented into anything much.
Enhances is the reverse of Suggests.
We have (I'm now using needs, though this is perhaps not the perfect
word for the new dependency):
(A (op) B) means:
Pre-Depends B configured before A being unpackaged
Depends B configured before A being configured
NeedsB configured before A being used
Basically, that would give us a new package status, pending (or so). If
we have A -> B (Needs), that would change the installation from:
{pre-depends satisfied} -> [pre-instA] -> [unpacking A] -> unpackaged ->
[configuring A] -> installed
to
{pre-depends satisfied} -> [pre-instA] -> [unpacking A] -> unpackaged ->
[configuring A] -> pending -> {all Needs satisfied} -> installed
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
Hi, * Ian Jackson ([EMAIL PROTECTED]) [060726 13:18]: > But, for example, foo <-Depends-> foo-data is not usually an example > of a silly dependency. Actually, there is no reason why foo-data needs foo configured before being configured, but there might be reason for the other direction. Why not inventing some new "Depends-for-being-useful" from foo-data to foo, and having Depends cycle-free? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Self-conflicts and self-depends
* martin f krafft ([EMAIL PROTECTED]) [060724 23:28]: > also sprach Fabio Tranchitella <[EMAIL PROTECTED]> [2006.07.24.2204 +0100]: > > I've noticed that some packages conflict or depend on themself. As far > > as I know, this makes no sense and the dependency (of conflict) should > > be removed, but I prefer to ask here before filing useless bug reports. > > I agree with you on the depends, but I wonder if the self-conflict > actually has an effect on the upgrade path. Well, what is the reason to conflict on itself? It makes sense for conflict on provides for virtual packages, but on the real package? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
* Marc Haber ([EMAIL PROTECTED]) [060630 10:58]: > On Fri, 30 Jun 2006 08:44:30 +0200, Martin Michlmayr <[EMAIL PROTECTED]> > wrote: > >Your guess is correct, see #372504. "This is currently a UI problem. > >It displays the line three times, but it only downloads it in the > >first. The other two lines are unpack and rred (patch)." > > So the "rred" is not a badly formatted and partially overwritten > "transferred" but an actual string? it's a restricted version of ed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
* Julian Gilbey ([EMAIL PROTECTED]) [060614 10:54]: > On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote: > > * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: > > > Does anyone know why the binary package gnome is no longer in testing? > > > The source package meta-gnome2 is there > > > > Seems like an accident currently. We're researching the matter. > > > > Cheers, > > Andi > > It's still not in testing. fixed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
* Adeodato Simó ([EMAIL PROTECTED]) [060606 11:54]: > No, it does not break. Analyzing software licensing does in fact not > require any developer privileges _at all_, in the same measure _preparing_ > a full set of GNOME packages does not, either. But the same way those > packages don't become "official" unless a developer signs them, non-DDs > can't have their word count as official either, even if they're more > knowledgeable than any DD on the subject matter. It has happened in the past that the DPL asked a DD and a NM to make together a team to deal with a problematic license and to give together official Debian statements. This is ok, and good, but of course, that's the exception and not the rule. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
Hi, * Andreas Barth ([EMAIL PROTECTED]) [060510 23:10]: > we think the switch to gcc 4.1 > as default should only be made if not more than 20 packages become RC > buggy by it. Also, the switch should happen latest 1.5 months prior to > freeze, that is Jun 15th. As we are below the 20 packages count if bug #366820 is correct (and Martin just confirmed the number), it is ok to do the switch now. Martin, can you please also mark these bugs as serious now (as they're FTBFS then)? Thanks for the fast work and the many NMUs to all people involved - and please continue on NMUing the remaining issues out, and then go on to solve other RC bugs. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
* Joey Hess ([EMAIL PROTECTED]) [060526 10:17]: > My memory is horrible, but IIRC James Troup (ie, our keymaster..) did > some similar study at the DebConf5 KSP and ended up with a list of > people whose GPG signtures he didn't trust anymore because of whatever > trick they fell for. I know that Peter Palfrader (weasel) submits sometimes a clear fake key to KSPs and looks for people signing it. (No, there is nobody there who claims to be that person. Only the key on the list.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
* Manoj Srivastava ([EMAIL PROTECTED]) [060525 08:15]: > On 24 May 2006, Andreas Barth stated: > > > * Steve Langasek ([EMAIL PROTECTED]) [060524 17:54]: > >> So I guess you can still criticize folks for this if you want to, > >> but I know that my own ongoing notion of "best practices" comes > >> from stuff I learned long ago plus new ideas discussed on this > >> mailing list, not from the devref. > > > > Well, wouldn't it be a good idea to make just sync the dev ref with > > what you consider as best practice? (And, BTW, I make much effort to > > only update the dev ref with correct information.) > > "Best" practices are subjective. I am sure people who write > dev ref feel those are best practices, I just happen to > differ. Substituting my biases for the current authors biases is > unlikely to improve matters for the majority of developers. Well, I try to avoid that there is a bias at all (though of course I know it is next to impossible to have none at all, it is quite possible to get the bias very small). For this reason, if anyone detects something he considers as bias, please tell me. That's the only way it could be fixed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
* Stephen Frost ([EMAIL PROTECTED]) [060525 06:01]: > Unfortunately, neither the FAQ nor emails from Sun are actually legally > binding I'm not sure why mails shouldn't be legally binding (of course, depending on their content - I didn't see any mails up to now). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366820: gcc 4.1-transition: also viewable via usertags
Hi, this dependend bugs are also available via usertags: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-4.1;[EMAIL PROTECTED] Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
* Steve Langasek ([EMAIL PROTECTED]) [060524 17:54]: > So I guess you can still criticize folks for this if you want to, but I know > that my own ongoing notion of "best practices" comes from stuff I learned > long ago plus new ideas discussed on this mailing list, not from the devref. Well, wouldn't it be a good idea to make just sync the dev ref with what you consider as best practice? (And, BTW, I make much effort to only update the dev ref with correct information.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libdb transition policy? (Was: Re: Bug#367853: libetpan: Please consider transitioning to libdb4.4)
* Nikita V. Youshchenko ([EMAIL PROTECTED]) [060523 17:22]: > However, if I will build library against libdb4.4 instead of libdb4.2, this > will probably break any binaries built against the library - both packaged > and local. Why that? It would only affect packages that (correctly or wrongly) also depend on libdb4.2. (And libdb4.2 unfortunatly doesn't have versioning, otherwise, it wouldn't be any issue; lidb4.3 and libdb4.4 are better in that regard.) AFAICS, this is only the case with etpan-ng. So, perhaps a conflict between your new version and the current version of etpan-ng and an upload of a changed version of etpan-ng (with a conflict to the current version of libetpan) could help? Gerfried, what do you think? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Don Armstrong ([EMAIL PROTECTED]) [060511 20:21]: > On Thu, 11 May 2006, Andreas Barth wrote: > > * Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]: > > > >>>>> Andreas Barth <[EMAIL PROTECTED]> writes: > > > > > > >> An upload of python-defaults switching to 2.4 has been repeatedly asked > > > >> during the last months, and it was ignored by the maintainer. I'm not > > > >> aware of anything preventing this upload currently. > > > > > > > The maintainer is not ignoring it, but the transition needs to have some > > > > issues fixed first. (And if you want to discuss aboutt hat, please leave > > > > -release out of the discussion. :) > > > > > > The last time this came up in, the majority view was to transition to 2.4 > > > as > > > default the "old way" rather than keeping it pending for so long. > > > > I'm not really aware of the python issues. Are there enough python > > people on Debconf to make an ad-hoc BoF about python? > > There are slots available for this; if someone wants to organize this, > let me know, and I'll give you a slot. I'd like to organize this, but it depends a bit on the python people - there is no sense organizing it w/o them. :) Well, perhaps give me a slot now, and we could still cancel it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060512 00:00]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > * Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]: > >> Domenico Andreoli <[EMAIL PROTECTED]> writes: > >> > what about the transition to python 2.4? is it going to start or etch > >> > is going to ship with 2.3? > >> > >> Yeah, what about it? > >> > >> There is an open bug, it's blocking lilypond which should have an > >> updated version in etch, and the python team has been discussing it > >> apparently but there is a deafening silence about telling me what the > >> plan is. > > > > Ok, I'll make sure there is some information latest for the next relese > > update, which is due in May. > > How about, right now, just a statement "this is what the issues are". > Or even, "this [URL here] is the mailing list post where the issues > are outlined." I forgot about them. So, I need to collect them again. Even release managers don't have a superhuman brain (though we sometimes pretend we do :). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:56]: > So, what are the issues that need to be fixed? Currently #360851 > doesn't say it's blocked by anything, and two packages are blocked > waiting for it. As said, I put it on my "need to work on"-list, and you'll get results in May (and hopefully already after the python BoF on debconf). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
python 2.4?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]: > Domenico Andreoli <[EMAIL PROTECTED]> writes: > > what about the transition to python 2.4? is it going to start or etch > > is going to ship with 2.3? > > Yeah, what about it? > > There is an open bug, it's blocking lilypond which should have an > updated version in etch, and the python team has been discussing it > apparently but there is a deafening silence about telling me what the > plan is. Ok, I'll make sure there is some information latest for the next relese update, which is due in May. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
* Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: > Does anyone know why the binary package gnome is no longer in testing? > The source package meta-gnome2 is there Seems like an accident currently. We're researching the matter. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]: > >>>>> Andreas Barth <[EMAIL PROTECTED]> writes: > > >> An upload of python-defaults switching to 2.4 has been repeatedly asked > >> during the last months, and it was ignored by the maintainer. I'm not > >> aware of anything preventing this upload currently. > > > The maintainer is not ignoring it, but the transition needs to have some > > issues fixed first. (And if you want to discuss aboutt hat, please leave > > -release out of the discussion. :) > > The last time this came up in, the majority view was to transition to 2.4 as > default the "old way" rather than keeping it pending for so long. I'm not really aware of the python issues. Are there enough python people on Debconf to make an ad-hoc BoF about python? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libgnutls (was: gcc 4.1 or not)
* Mike Hommey ([EMAIL PROTECTED]) [060511 11:00]: > On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL > PROTECTED]> wrote: > > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: > > > Hi, > > > > hi, > > > > > there were some requests, e.g. by Martin Michlmayr to the release team > > > whether we could switch gcc to 4.1 or not for etch. As we're heading to > > > > what about the transition to python 2.4? is it going to start or etch > > is going to ship with 2.3? > > what about the transition to libgnutls13 ? I noticed yesterday when > debootstraping that we get libgnutls11, 12 AND 13 installed by default. > Do we really need that many libgnutls ? Please see e.g. bug #363294, there are some discussions about that. Of course, as in all that issues, feel free to help with packages moving away from gnutls11, but that is as of now not an RC bug (and we speak of 68 packages in testing currently using libgnutls11, which are not too few). However, it would be quite more helpful to reduce the number of real RC bugs - we need to get down from the number of 400. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
python version? (was: gcc 4.1 or not)
* Josselin Mouette ([EMAIL PROTECTED]) [060511 10:48]: > Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit : > > what about the transition to python 2.4? is it going to start or etch > > is going to ship with 2.3? > > An upload of python-defaults switching to 2.4 has been repeatedly asked > during the last months, and it was ignored by the maintainer. I'm not > aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Wouter Verhelst ([EMAIL PROTECTED]) [060511 08:59]: > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: > > there were some requests, e.g. by Martin Michlmayr to the release team > > whether we could switch gcc to 4.1 or not for etch. As we're heading to > > freeze etch rather soon and also the RC bug count doesn't look too good, > > and we want to be on time this time :), we think the switch to gcc 4.1 > > as default should only be made if not more than 20 packages become RC > > buggy by it. Also, the switch should happen latest 1.5 months prior to > > freeze, that is Jun 15th. > > Additional data point: GCC 4.0 on m68k is mostly crap, and probably the > reason why we haven't been able to make it back as a release candidate > architecture yet. Yes, known. However, we have to consider what is worse - adding more RC bugginess on all arches, or being bad to one arch already having some (other) issues. And I think the number of 20 new RC bugs is fair to both sides (or that's at least what we thought when we discussed about the numbers). > GCC 4.1 fixes a _lot_ of the GCC 4.0 bugs on m68k, and we'd really, > _really_ love to see it become the default, at the very least on our > architecture. So, I guess that means we'll have to help out there, > doesn't it? ;-) Definitly. :) > > One: What's the easiest way to extract the list of gcc-4.1 related bugs > from the BTS? There is none I know - I asked Martin already yesterday on IRC to provide such a way. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc 4.1 or not
Hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. The RC bug NMU policy also applies to such bugs, but please be aware: Do not upload package until you make sure you don't break anything. Please check also that you're not just disturbing a transition (e.g. don't NMU packages in sid the day before they go to testing :). Questions should go to debian-release also (though of course I read d-d also :). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
APT key maintainence
* Pierre Habouzit ([EMAIL PROTECTED]) [060506 12:46]: > if you take the 2y validity with 1y overlap, to have no problems, > users/images/... just have to be updated once a year (and will have a > life of at least one year, almost two if those are updated as soon as a > new key exists), which sounds reasonnable to me. Actually, if someone installs etch r0, I expect that he can install etch r5 without any hassle (unless ftp-master was hijacked :). This means that the key used in r5 needs to be available in etch r0. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the BTS gains a remote bug tracking feature for free !
* Martin Michlmayr ([EMAIL PROTECTED]) [060503 14:45]: > * Christoph Berg <[EMAIL PROTECTED]> [2006-05-03 14:28]: > > Automatically setting the 'fixed-upstream' tag is certainly a very > > nice idea that no one will object to. > > Unfortunately, there are always corner cases. What if upstream marks > something as fixed, you get a Debian bug report that the bug is still > there and you mark it as forwarded to the original bug report, waiting > for it to be reopened. In the meantime, the tool will tag the bug as > "fixed-upstream" which is obviously wrong. Basically, the tool should just work on *changes* upstream, i.e. if upstream goes from reopened to resolved/fixed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Darren Salt ([EMAIL PROTECTED]) [060502 19:03]: > I demand that Andreas Barth may or may not have written... > > * Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]: > >> On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote: > >>> Or you could create the diffdebs before upload or on ftp-master, and > >>> include the diffdebs somehow in the Packages file (so they're signed as > >>> well by the usual mechanismn). > > >> My initial view is that any delta package system that doesn't reproduce > >> the exact same .debs as downloading the package from scratch is a > >> non-starter. > > > Why that? Of course, you need all the maintainer scripts etc in the > > diffdeb, but not all the regular files. > > I wouldn't like to rely on the admin not having modified any of the package's > files (/etc aside). Yes, this shouldn't happen, but it does :-) > > Of course, if you're running md5sums on all of the package's files, this can > be caught... One need to do that, yes of course. Together with a list of permissions. I'm not demanding it's trivial. But it's possible if one really minds. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Brian Eaton ([EMAIL PROTECTED]) [060501 19:21]: > On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote: > >Or you could create the diffdebs before upload or on ftp-master, and > >include the diffdebs somehow in the Packages file (so they're signed as > >well by the usual mechanismn). > My initial view is that any delta package system that doesn't > reproduce the exact same .debs as downloading the package from scratch > is a non-starter. Why that? Of course, you need all the maintainer scripts etc in the diffdeb, but not all the regular files. Normally, the operation works as follows: call maintainer script old-prerm upgrade newversion call maintainer script new-preinst upgrade oldversion unpack new packages files, temporarily renaming the old packages file (1) call maintainer script old-postrm upgrade newversion remove any files only in the old package (2) maintainer scripts and file list are being replaced delete backup files (3) call maintainer script new-postinst upgrade oldversion Now, the difference would be: record in the diffdeb package which files go unchanged, so at (1) only the changed files are overwritten. At (2), only the files neither in the new package nor in the unchanged list are removed, and (3) just deletes less backup files. In the end, the only difference is that less files are written, and no new inode is used by the script. Of course, you basically need to adjust the new "normal" deb so that the files have the same date in the normal deb and in the previous deb (so you basically need a way to say "create a diffdeb to that deb", and you get the diffdeb and the adjusted new deb for upload (so it needs to happen prior to upload). > It opens up the door to all kinds of funky > maintenance questions like "well, did you install from the patch > package, or the real package? was this a bug in the patch package?", > etc... Ideally, package maintainers will never have a reason to care > that delta packages exist. Exactly. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Brian Eaton ([EMAIL PROTECTED]) [060501 17:49]: > On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote: > >* Brian Eaton ([EMAIL PROTECTED]) [060501 16:42]: > >> On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote: > >> > > >> >If one does it right, it might be enough if the original package is > >> >*installed*. And that happens quite often, e.g. even for security > >> >upgrades. > > > >> So to do this you'd rebuild the original .debs on the fly, from the > >> files installed on the system? Cool! Do you know if anyone has tried > >> doing this? > > > >No, why? You could just create a diffdeb that contains only the changed > >files. > > That sounds reasonable. It depends on the mechanism used to cache > checksums on the server side. If you're going to handle individual > files instead of .debs, you would need to run the checksum routines on > the files individually instead of on the .debs as a whole. Or you could create the diffdebs before upload or on ftp-master, and include the diffdebs somehow in the Packages file (so they're signed as well by the usual mechanismn). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Brian Eaton ([EMAIL PROTECTED]) [060501 16:42]: > On 5/1/06, Andreas Barth <[EMAIL PROTECTED]> wrote: > >* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]: > >> The only time delta packages will be a win is for upgrades where the > >> client has the original package cached. > > > >If one does it right, it might be enough if the original package is > >*installed*. And that happens quite often, e.g. even for security > >upgrades. > So to do this you'd rebuild the original .debs on the fly, from the > files installed on the system? Cool! Do you know if anyone has tried > doing this? No, why? You could just create a diffdeb that contains only the changed files. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
* Brian Eaton ([EMAIL PROTECTED]) [060501 15:51]: > The only time delta packages will be a win is for upgrades where the > client has the original package cached. If one does it right, it might be enough if the original package is *installed*. And that happens quite often, e.g. even for security upgrades. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Joey Hess ([EMAIL PROTECTED]) [060427 18:38]: > c) The mipsel builds had been down nearly as long. And that machine >seems to be dead. Argh. Would you need access to another mipsel machine? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Olaf van der Spek ([EMAIL PROTECTED]) [060427 17:54]: > On 4/27/06, Sven Luther <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 27, 2006 at 11:43:02AM -0400, Toni L. Harbaugh-Blackford > > [Contr] wrote: > > > Just what are the rules for someone to have commit access? > > > > None, it is the full decision of the project admin, and i believe what > > happened here is that one such project admin did let some petty personal > > considerations overstep his responsabilities. > > Why don't you ask the admins instead of continuing based on beliefs? Hey, that would be violating the rules of a flame fest. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Sven Luther ([EMAIL PROTECTED]) [060427 17:03]: > On Thu, Apr 27, 2006 at 04:52:09PM +0200, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [060427 15:05]: > > > Andreas, do you have an explanation of why d-i commit access was taken > > > from > > > me, and why i find out only now as i was going to fix the issue ? > > > > http://lists.debian.org/debian-boot/2006/03/msg01075.html sounds like > > you stepped back, and > > http://lists.debian.org/debian-powerpc/2006/03/msg00490.html confirms > > that. > > I stepped back from d-i powerpc port maintainer, not as d-i contributor. I don't call myself authoritative what your other contributions to d-i include. It might be a good idea to clarify your status within the d-i team first, instead of telling all people that debian has stopped ppc support (which is just wrong, and is definitly neither the intention of the d-i team nor the release team). > Also, i don't believe there is any justification for taking away svn commit > access except when there was a clear misuse of it being made. Actually, I think revoking svn commit access from people who stopped to work on d-i (or any project, that is not d-i specific) is ok. E.g. we also "revoke" upload privileges of people who don't do Debian work anymore. If that was a misunderstanding - please try to clarify it in private first (without the noise that this thread makes). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Sven Luther ([EMAIL PROTECTED]) [060427 15:05]: > Andreas, do you have an explanation of why d-i commit access was taken from > me, and why i find out only now as i was going to fix the issue ? http://lists.debian.org/debian-boot/2006/03/msg01075.html sounds like you stepped back, and http://lists.debian.org/debian-powerpc/2006/03/msg00490.html confirms that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Toni L. Harbaugh-Blackford [Contr] ([EMAIL PROTECTED]) [060427 14:38]: > I don't think you understand. There was not a peep on the list about > anything being up with the daily image until Sven explicitely stated it. > I would have expected the maintainer or others privy to the situation > to have said something earlier, along the lines of: > [...] Yes, that is what I assumed what happened, and that is what really worries me. But I don't think it is as bad as Sven tries to make it look like - it is currently at a level where it could be repaired, and where we could still prevent that bad things remain. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Toni L. Harbaugh-Blackford [Contr] ([EMAIL PROTECTED]) [060427 13:53]: > On Thu, 27 Apr 2006, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [060427 13:23]: > > > Dear fellow powerpc folk, this clearly means that the debian support for > > > powerpc is dead or almost so, and i strongly recomend you to go find > another > > > distribution to run which cares a bit more about the powerpc > architecture. > > > > I'd rather prefer if you don't overexegerate. > > I'm not sure he's exagerating. There has been a grave silence about the > daily images not building, for anyone who doesn't access IRC anyway. I'm not too happy either to become aware of that issue in this way - but well, I think his cited words "debian support for powerpc is dead or almost so" and his recommendation people to change away from debian do way more harm than the images not building the images for a month, and I also don't really see any ground for these words. Of course, best that could happen now would be if someone just takes up the loose ends, and tries to fix the issues - and I hope someone just does. > I would have expected to see some mention of it on the list so people who > don't stay on IRC (and people who are only interested in the ppc architecture) > would know what was going on. I never doubted that. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
* Sven Luther ([EMAIL PROTECTED]) [060427 13:23]: > On Thu, Apr 27, 2006 at 12:53:12PM +0200, Frans Pop wrote: > > On Thursday 27 April 2006 12:14, Sven Luther wrote: > > > 1) daily build business card and netinst isos are failing to build > > > since april 1, which means they don't include the broadcom tg3 module > > > at all, and are thus not really usable for installs at this time. > > > > Reason is that prep and chrp d-i cdrom images are failing in daily d-i > > builds. This results in debian-cd not being able to find a file needed > > for mkisofs. > > > > I understand from comments on IRC that this is due to a kernel issue? > > Oh fun, i don't have any commit access to the d-i repo anymore, so i can't > even fix this issue myself. This clearly shows the pettiness of the d-i team, > i am disgusted. ... > > Dear fellow powerpc folk, this clearly means that the debian support for > powerpc is dead or almost so, and i strongly recomend you to go find another > distribution to run which cares a bit more about the powerpc architecture. I'd rather prefer if you don't overexegerate. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted mailman 2.1.5-8sarge3 (source sparc)
Hi, * Lionel Elie Mamane ([EMAIL PROTECTED]) [060412 13:49]: > mailman (2.1.5-8sarge3) stable; urgency=high > . >* Don't delete other package's ucf-managed configuration files > (closes: #358575) > Files: > 2a02b24630b797a17c52380d299a4b2f 633 mail optional mailman_2.1.5-8sarge3.dsc > 90f03d59fcbe53e8f7399574641d9c92 118330 mail optional > mailman_2.1.5-8sarge3.diff.gz > 615500ff6cd8404ec4563456f1145617 6616342 mail optional > mailman_2.1.5-8sarge3_sparc.deb what's that? Can't you *please* *please* ask first on debian-release before uploading a new version - especially if there is already a version in proposed-updates that is scheduled for the next stable point release (like a security update)? This was now *very* near to delaying the next stable point release (but the ftp-masters helped us out). Please ask first at debian-release@lists.debian.org, and attach a diff. That will help us all, give you immediate feedback and makes sure there are no unnecessary actions required. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc_2.3.6-6_i386.changes REJECTED
* Frans Pop ([EMAIL PROTECTED]) [060411 15:27]: > On Tuesday 11 April 2006 15:08, Goswin von Brederlow wrote: > > When doing a full upgrade (stable->unstable) could it happen that apt > > breaks the libc6<->libc-bin depends cycle and put them into seperate > > dpkg calls? I don't remember how smart/stupid libapt was there. It > > might be best to add "apt-get install libc6 libc-bin" to the upgrade > > instructions. > > If that is needed, please file a bug report against release-notes. But it would better if that wouldn't be needed at all. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
which packages are older/missing?
Hi, I have two package lists, and want to find out which packages are missing in one of the lists or are older than in the other list. Of course, it's easy to write such a program but if somebody has already done that, I'd try to safe the effort. Any hints for me? (or as alternative, what's the best way to read a package list into python?) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
* Petter Reinholdtsen ([EMAIL PROTECTED]) [060313 08:03]: > [Steinar H. Gunderson] > > Perhaps the ftpmasters are busy with the mirror split? > > Could be, but I believe I heard that most NEW processing is done by > one of the assistants while the mirror split is done by someone else. > I guess that one person got busy or demotivated. I suspect NEW Well, that person is currently on the CeBIT and manning the Debian booth there. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
* Frank Küster ([EMAIL PROTECTED]) [060312 12:24]: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > > Actually, in case stockholm gets elected, > > Sorry, where's the Wiki page describing codenames for DPL candidates? Sorry for using the IRC name. I try to avoid that in mail, but failed this time. stockholm = Andreas Schuldei. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
* Lars Wirzenius ([EMAIL PROTECTED]) [060309 19:56]: > That reminds me of something I meant to propose some time ago: someone > with a bit of time on their hands could make a wiki page, > DplPromises2006 say, and list all the promises of all the candidates. > Then, during the next year, we can keep coming back to that page and > check how well they keep their promises. Actually, in case stockholm gets elected, I plan to list all of his promises in his status mails, and give an overview what worked and what not. (That is basically what "milestones" means in his platform.) I think that's a good thing to do. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
* Daniel Stone ([EMAIL PROTECTED]) [060309 19:53]: > Please point me to a candidate who is claiming that 'there is no problem > and that we should all be friends'. krooger. Sorry, couldn't resist. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
Hi, * Martin Schulze ([EMAIL PROTECTED]) [060309 11:37]: > I'm sorry to announce this but you'll have to find a new person who works > on updating Debian stable and who is willing to cope with black holes and > ftpmasters. Martin, thank you very much for your great services you did as stable release manager during the last years. I'd like to inform you that Martin Zobel-Helas and I are going to take over the task of the stable release manager. We intend to add more people to that task, but well - that can be done anytime later. Martin agreed to that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ signature.asc Description: Digital signature
Re: Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)
* Adeodato Simó ([EMAIL PROTECTED]) [060305 14:44]: > * Andreas Barth [Sun, 05 Mar 2006 14:16:50 +0100]: > > > Well, if s-p-u would *only* contained approved packages for the next > > point release, I would agree with you. However, s-p-u contains any kind > > of packages right now. > > Right, I've always thought it'd be useful to have a place to make > _accepted_ s-p-u uploads available (read: those that'll be in the next > stable point release fore sure). Currently s-p-u is not that place, > nor is debian-volatile as per its definition, but _maybe_ the exim4 > issue is important enough as to make the volatile archive admins > consider an exception. The plan is to make s-p-u such a place, but until it happens, I think volatile can have such packages as an exception, if the bug is severe enough. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Propose exim4 for debian-volatile (Was: exim4_4.50-8sarge1)
* Stephen Gran ([EMAIL PROTECTED]) [060304 12:33]: > This one time, at band camp, Martin Zobel-Helas said: > > I don't see any reason accepting packages into debian-volatile, when > > they contain no volatile data. Also if the package will be in the next > > stable point-release i don't see any reason why to put it into > > volatile... > > I am sorry to say, but I have to agree with zobel here. The changes > aren't exactly what I think of when I think of the voltile archive > mandate (although again, perhaps that needs to be better spelled out so > as to make things more clear). Additionally, exim4 packages are already > available in s-p-u, so I don't see a pressing reason to make them > available in another repository. > > I am willing to be convinced I am wrong here, but at first blush I don't > see it as suitable. Well, if s-p-u would *only* contained approved packages for the next point release, I would agree with you. However, s-p-u contains any kind of packages 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: timezone data packaged separately and in volatile?
* Martijn van Oosterhout ([EMAIL PROTECTED]) [060207 14:09]: > ISTM the d-volatile is the right place for this. However, in the mean > time I think someone should send a message to debian-announce that > anyone running a debian machine with an Australian (or other affected) > timezone needs to get updated zone files from $location. Well, if we *have* files at $location that can be used for this, and that allow updates to etch, these files can directly be put into volatile. The round-trip time for such an update is less than 24 hours, if all relevant people (in this case: the glibc people) agree on how to do it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: > On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: > > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > > > I also think volatile is precisely the wrong place to put this kind of > > > data -- it isn't part of the default apt.sources for one thing; and it > > > places an extra burden on the maintainer(s) (who know have to track > > > three different upgrade paths, etc.). > > > > Only because you have a prejudice against volatile doesn't mean its the > > wrong place. Volatile is rather the exactly right place for this kind of > > update. > > It is precisely the wrong place because volatile isn't in > apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? > As it is, volatile is a great solution in search of a problem. It is > unfortunate that you, and others, seem to latch onto things like as a > reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > I also think volatile is precisely the wrong place to put this kind of > data -- it isn't part of the default apt.sources for one thing; and it > places an extra burden on the maintainer(s) (who know have to track > three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anthony Towns: What I did today
* Wouter Verhelst ([EMAIL PROTECTED]) [060115 10:00]: > If you remove cruft from one of your packages, do you start notifying > developers on d-d-a? In case of the developers reference, I did. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* David Nusinow ([EMAIL PROTECTED]) [060112 21:47]: > On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote: > > However, on the other hand feel free to create a "common maintained > > packages team" that adopts such packages :) > Isn't that pretty much what the qa team does? Not really. All qa-maintained packages are up for adoption or removal and are only maintained at a "if it breaks too bad". Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* Frank Küster ([EMAIL PROTECTED]) [060112 19:36]: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > * Frank Küster ([EMAIL PROTECTED]) [060112 18:11]: > >> Andreas Barth <[EMAIL PROTECTED]> wrote: > >> > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]: > >> >> Re: Thomas Viehmann in <[EMAIL PROTECTED]> > >> >> > Really, how about just automatically[1] removing orphaned packages > >> >> > without maintained rdepends from testing? > >> >> > >> >> Seconded. > >> > > >> > well, just make a list that I can just copy into my hint file. > >> > >> Hm, I can't find the context: Are you talking about all such packages, > >> or only packages with RC bugs? > > > > The ones that are orphaned for some time. If we see it doesn't work or > > is not worth, we can change that back of course. > > I can't see why removing an orphaned package that has no RC bugs, and > let's say, even no important bugs, and which is stable in the sense that > there's no new upstream version (e.g. an established font), from testing > makes testing's quality better. What about a hypothetical package that > has no bugs at all, but some users according to popcon? One can try to come up with some metric, yes. However, on the other hand feel free to create a "common maintained packages team" that adopts such packages :) Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]: > >> Re: Thomas Viehmann in <[EMAIL PROTECTED]> > >> > Really, how about just automatically[1] removing orphaned packages > >> > without maintained rdepends from testing? > >> > >> Seconded. > > > > well, just make a list that I can just copy into my hint file. > > Hm, I can't find the context: Are you talking about all such packages, > or only packages with RC bugs? The ones that are orphaned for some time. If we see it doesn't work or is not worth, we can change that back of course. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* Thomas Viehmann ([EMAIL PROTECTED]) [060112 15:56]: > Thijs Kinkhorst wrote: > > I very much agree that we should strive to make packages as good as > > possible, but if users depend on a package and there are no real > > showstoppers in it, we might do our users a better service with shipping > > than with not shipping the package. > No. Shipping unsupported packages no developer cares about is a bad idea. Well, by definition if a package is too broken to support it, the bug is RC. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]: > Re: Thomas Viehmann in <[EMAIL PROTECTED]> > > Really, how about just automatically[1] removing orphaned packages > > without maintained rdepends from testing? > > Seconded. well, just make a list that I can just copy into my hint file. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Steve Langasek ([EMAIL PROTECTED]) [060106 13:05]: > The exposure of the archive key is higher, because it sits on an > Internet-connected, ssh-accessible server. Also, you don't have to trust > AJ's key; in contrast with Florian's assessment of the NM-suitability of the > three ftpmasters, one ftp assistant, and one RM who have signed this key so > far :), I would encourage you to log into merkel and verify, directly and > securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and > upload your signature to the public keyservers as well, if you are satisfied > that this is the key that is being used on ftp-master.debian.org to sign the > archive. I disagree with that - having this key sitting on merkel means nothing. Checking the configuration on /org/ftp.d.o/katie/katie.conf and the keyring ziyi uses on ftp-master (i.e. spohr) means something. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Florian Weimer ([EMAIL PROTECTED]) [060106 11:56]: > * Bernd Eckenfels: > > >> IOW using the old key to sign the new key only requires that the old > >> key be "good" at one point during the new year, whereas continuing to > >> use the old key requires that it be "good" all year. > > > > Yes, but it breaks a long term usage like web of trust. > > The Debian archive key does not take part in the web of trust. > Anybody who has passed the OpenPGP NM checks should not sign that key. I disagree. There are people who have first-hand knowledge that this key is used for the usage written in the key id, i.e. sign the debian archive. These people can IMHO sign the key. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Steinar H. Gunderson ([EMAIL PROTECTED]) [060103 23:37]: > On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote: > > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just > > starting to get implemented). > > The real question (IMHO) is probably whether it would be possible to get > newer kernels into volatile. I'd guess "probably not", given that stuff like > udev tends to break every other release, but it's a tempting thought -- the > sarge machine here seems to run miles better with a 2.6.14 backport (yay for > backports.org) than it ever did with 2.6.8 (which seems to have a really > really unstable USB layer). I think it would be possible, but it requires some help from the kernel team side - and of course I can understand if they don't want to take care of yet another kernel version. Please see the discussion starting at http://lists.debian.org/debian-kernel/2005/12/msg00678.html Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
* Sven Luther ([EMAIL PROTECTED]) [060103 23:02]: > On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote: > > the other hand side, the difference is only one week - and if nothing is > > broken by that, we can freeze the kernel at N-110 also. > i think comparing the kernel with the toolchain is overkill, if nothing else a > last minute change in the toolchain will need a kernel recompile anyway maybe. > I do confess that i read June 30 at first, and this seemed much less > acceptable to me. well, the kernel is definitly about the same level as the toolchain and standard/base - changes can have very easily impact on the installer, and it is not an option to remove the package if it is broken. > > > > N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] > > > > N-45 = Wed 18 Oct 06: general freeze [about 2 months after base > > > > freeze, d-i RC] > > > > N = Mon 4 Dec 06: release [1.5 months for the general freeze] > > > > > > We will have a kernel which is outdated by two versions at release time > > > with > > > this plan, since there are about 1 kernel upstream release every 2 month. > > > > Well, if we want to release with a newer kernel, we need to make sure > > d-i doesn't stumble over it. Experience tells us that there are enough > > What experience ? I was speaking about the installer. And usually there are lots of last-minute changes that need to go in - not only new languages, but lots of other small minor, but still important bug fixes. > > Also, the kernel will be outdated sooner or later anyways - so, if after > > one year the kernel is 12 or 14 months old is not too much a difference. > > Hehe, me runs sid kernels installed almost as is on all my sarge systems > indeed, just with rebuild yaird and mininmally backported udev. Well, but then an older kernel doesn't hurt you? :P > Indeed, but you have only the sarge experience to go by, and taking the sarge > experience on this is hardly fair to the huge amount the kernel team has > devoted to streamline the process. Of course, we have seen that the kernel build process is way more mature now. Nobody doubts that. > Also, i don't really believe joeyh and fjp > are really the relevant maintainers with regard to the debian kernel and its > application, since they lack the vision of how things could go better, or more > thruthfully, probably lack the time and motivation to think really about the > issue, and why should they, it is the kernel team jobs :) Well, they are definitly the relevant people for the installer. And, frankly speaking, at least I have good experience with both of them. > d-i is only a part of the problem anyway, and i believe the less problematic. > out-of-tree modules and third-party patches are a worse mess. Hm, which out-of-tree modules do you consider to be release critical, i.e. we cannot release without them? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Hi, thanks for your mail. I just want to point out that we published the timeline already back in October, but of course, that shouldn't refrain us from changing it if this is necessary. :) [re-arranged the quote] * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]: > On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote: > > N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels > > N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including > > e.g. cdbs) > > Why do you put the kernel together with the essential toolchain freeze, it > should be together with the rest of base, i believe. Hm, I'm quite sure we had some good reason for this; however, I cannot really remember why we put the kernel to the essential tool chain. On the other hand side, the difference is only one week - and if nothing is broken by that, we can freeze the kernel at N-110 also. > > N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] > > N-45 = Wed 18 Oct 06: general freeze [about 2 months after base > > freeze, d-i RC] > > N = Mon 4 Dec 06: release [1.5 months for the general freeze] > > We will have a kernel which is outdated by two versions at release time with > this plan, since there are about 1 kernel upstream release every 2 month. Well, if we want to release with a newer kernel, we need to make sure d-i doesn't stumble over it. Experience tells us that there are enough last-minutes changes to the installer that we cannot avoid to better not change the kernel; if the installer team (i.e. Joey Hess or Frans Pop) tell us otherwise, we can of course adjust our plannings. However, there will be a minimum periode where we just need to freeze everything to get enough testing to the proposed release. Also, the kernel will be outdated sooner or later anyways - so, if after one year the kernel is 12 or 14 months old is not too much a difference. > So, we will be asking the question about the upgradability of the kernel later > during this release process, and i believe that it is not something which > should be ignored. Well, we as release team first believe what is told us by the relevant maintainers. Our current status is that kernel upgrades late in the release process (especially after the d-i RC) are rather painfull. 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]
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: 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: 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: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 23:26]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > You think that December 2006 (the expected release time of etch) is too > > early to drop Kerberos 4? > I'm not sure. I think it's going to be tight for some people, but on the > other hand not shipping etch with MIT Kerberos 1.5 is not exactly > appealing. I expect, though, that Stanford will be in a situation where > that will be fine with us by December, and we're historically one of the > slower sites to migrate, so maybe it will be okay. On the other hand, sarge will be supported till December 2007, so this should give enough time for migration, provided we warn of this scenario properly. But perhaps it's better to reconsider it again, as we have enough time to decide. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 21:47]: > Andreas Barth <[EMAIL PROTECTED]> writes: > > Well, my question is simple: should I push packages to go away from > > kerberos-4-support? Unless there is a good reason to do not, I would > > start to push into that direction. And of course, feel free to send me > > things that need to be changed. As usual, the maintainers have a special > > say in everything (that's why I Cced them). :) > I think it's time to encourage maintainers to start thinking about this, > as the next major release of MIT Kerberos is also going to drop Kerberos > v4 support as of May of 2006. Kerberos 4 support will still be there in > the MIT package until at least that time, and there are some sites who are > still in the process of transitioning away, so I wouldn't want to see too > many things disappear too quickly, but it's certainly time to think about > how to drop it over time. You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: drop kerberos4-support?
Hi, while my regular "clean up RC-bugs"-work I noticed that the package krb4 is RC-buggy in more than one way. On further investigation, I also noticed that kerberos 4 is dying right now, and also that the bugs are not as easy to fix. Also, upstream doesn't look too active according to http://www.pdc.kth.se/kth-krb/. For this reason, I started to consider to push dropping of the krb4-package from unstable. This has some influence on the heimdal-package, and also on the release notes for migration issue. However, I personally tend to go that way. Please see bug #315059 for some discussion; especially, heimdal in experimental stopped to depend on kerberos 4. Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [051108 07:11]: > "Erast Benson" <[EMAIL PROTECTED]> writes: > > I understand your concern. We will release ISO image with CDDL/GPL sources > > very soon. Majority of them already available at /apt. The rest is > > comming. > Once again, delete the binaries *now*. You could send them e.g. a DMCA Takedown Notice. Especially as they didn't listen before. Of course only if you're the author of one of the relevant programms. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bts2ldap-gateway: new host bts2ldap.debian.net
Hi, once again, the ldap-part of the bts2ldap-gateway changed its location. It is now on bts2ldap.debian.net (but this host name has the advantage that it can stay, even if the ldap-server moves once again :), port is 10101. Thanks to Andrew Pollock for offering some space on one of his machines for this. The index-files are still available as files on merkel and master. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
* Glenn Maynard ([EMAIL PROTECTED]) [051104 14:40]: > On Fri, Nov 04, 2005 at 02:05:43PM +0100, Florian Weimer wrote: > > * Wouter Verhelst: > > > > >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be > > >> contributed back to the community. > > > > > > No, that's not true. > > > > > > Any *distributed* changes to foo.c must be contributed back to the > > > community. > > > > Huh? Why do you think so? > > Because that's what the GPL says, in relatively plain language. I cannot remember to have read that. Perhaps you can cite the appropriate section. The only thing the GPL requires is that I do not further control the distribution of any file I gave someone else (except as far as controlled by the terms of the GPL). It does not require me or the other person to share the information with anyone else. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
* Anthony Towns (aj@azure.humbug.org.au) [051101 17:23]: > On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote: > > So, would anybody object if I set up a cronjob that emails the PTS > > whenever a (source) package propagates to, or is removed from, testing? > I won't so nobody'd object; but it's one of the things we agreed we > wanted at the Vancouver meeting. I think there was going to be a > -testing-changes list or something, perhaps? I forget exactly. We agreed to both maintainer mails (but PTS might be more appropriate for that), and a summary to -testing-changes. IOW, whoever shows code up for any of the tasks has some bonus points :) Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
* Aurelien Jarno ([EMAIL PROTECTED]) [051031 14:31]: > So it seems that unstable is again, as before the release, half-frozen. > Maybe we could change its name? > > Seriously, I begin to consider that as a real problem. I am not blaming > you, release maintainers, you are doing your job. From my point of view, > we have a real problem because of our testing + unstable scheme. Actually, libc++-changes shouldn't occur that often, and I don't think it's a real problem to avoid uploads for something like 10 days. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:58]: > Leaving around unused accounts is plainly wrong too, and also a > potential security risk. I'm certain you can proof this. > If we're going to try to push for a broad > change in how this is handled then let's do it the *right* way by > creating such a system as I described above, Feel free to implement such a system. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]: > Additionally, this is *not* a problem with the orphaning of the file, > it's a problem with the reuse of a previously-used uid. I could see > adding a system to track previously-used uids and not reusing them. I > don't believe using passwd for that (and keeping unused accounts in > passwd/shadow/group/gshadow/etc) is appropriate. It would seem enough > to me, at least, to keep an ever-increasing counter where the current > value is the next available uid. This could be reset if it reaches the > max, or an error presented to the user about it or some such. Well, I could see us to build such a system. But this system isn't there - and IMHO the next working way to prevent uids of being reused is to keep the account in question (perhaps locked etc, as suggested elsewhere). Anything else is IMHO plainly broken. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]: > * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: > > Stephen Frost <[EMAIL PROTECTED]> writes: > > > Same way you know that the system administrator hasn't modified a file > > > in /usr/bin. > > > > Um, I know that by comparing the contents against a known-true > > version. How do I detect whether the system administrator has used a > > UID? > > Except last I checked, we don't do such comparison. If you really > wanted to know if the UID was used you could do a find /, etc. Neither > is necessary though, which is the point. > > > Moreover, the consequences of getting the one wrong are that you > > delete the sysadmin's changes. The consequences of the other are an > > important and difficult-to-detect security hole. > > This is just patently false, as has been pointed out elsewhere. What > security hole, exactly, is created by orphaning a file? Well, if some process (maybe within the package) creates a private log file that contains sensitive information, and this log file can later on be read by a process with much less privileges, this is usually considered as security relevant issue. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:48]: > Andreas Barth wrote: > >* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: > >>in my workstation I try out a new package (for scientfic computing, a > >>game for Lucas, a new development package) at least once each two days, > >>and a lot of times they come with their libs and their daemons -- and > >>their users. So I see them, and think "oh, no, this is not what I > >>thought it would be", and --purge them. And the daemons' users pile up > >>in /etc/passwd. > > > >well, perhaps take it as administrators job to clean up /etc/passwd from > >time to time if you install that many packages (because you as > >administrator know which users were co-used with someone else, and which > >not). But this is definitly not the most common scenario. > > It seems that you still did not get my point. > My point is, in a SoHo workstation, this is exactly the most common > scenario nowadays (example: "hmm. let me try this new dvd-player... I > open synaptic, install it, ... nah, it does not work as I expected [but > it installed gstreamer, jackd, etc in the process] let me try the next > one in the list...") I fear, you still did not get my point. We have two ways to choose from, both with advantages and disadvantages. One has the disadvantage to be able to make systems magically fail and expose security risks. The other has the disadvantage to make /etc/passwd a bit too large in some cases. Isn't it obvious that we shouldn't go for the security risk? I don't mind at all if we get some clever way like marking the user in the gecos-field and have an "debuserfoster". But I mind very much to try to deal security with "looks nicer". Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]: > in my workstation I try out a new package (for scientfic computing, a > game for Lucas, a new development package) at least once each two days, > and a lot of times they come with their libs and their daemons -- and > their users. So I see them, and think "oh, no, this is not what I > thought it would be", and --purge them. And the daemons' users pile up > in /etc/passwd. well, perhaps take it as administrators job to clean up /etc/passwd from time to time if you install that many packages (because you as administrator know which users were co-used with someone else, and which not). But this is definitly not the most common scenario. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]: > Andreas Barth wrote: > >* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: > >>"We can provide a sensible default for system users' removals that > >>copes with most situations and leave a door open (through debconf) > >>to sysadmins that want to fiddle with system users." > > > >I really want to warn to try to be too smart by half. Reserving the > >name/uid-space by not removing the accounts works reasonable well, > >and having at maximum 5-10 unnecessary accounts is also not the end > >of the world either. > > Problem being, if daemons don't remove their (supposedly exclusive-use) > accounts, you can end in two years with 100 unnecessary accounts in a > workstation. How many daemon packages do you install in two years? I even doubt that we have 100 packages that add accounts at all in debian. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]: > "We can provide a sensible default for system users' removals that copes with > most situations and leave a door open (through debconf) to sysadmins that > want to fiddle with system users." I really want to warn to try to be too smart by half. Reserving the name/uid-space by not removing the accounts works reasonable well, and having at maximum 5-10 unnecessary accounts is also not the end of the world either. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* Gabor Gombas ([EMAIL PROTECTED]) [051026 18:03]: > On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote: > > > > i don't think removing and reusing users is a good idea in practice. > > > what harm would there be in simply leaving the user account on the > > > system permenantly, with maybe locking the account and setting the > > > shell to /bin/false? > > > > Yep, that's probably best practice. > > Note that most system groups are already locked and have the shell set > to /bin/false by default, anything else is likely a change made by the > admin manually. Forcibly locking the account is thus overriding the > admin's decision, so it must be at least clearly documented somewhere. Well, locking of course only if the application needed something else than /bin/false in the first place. :) > Another thing would be to change the GECOS indicating that the account > is now stale, and have some small utility to list/remove all such > accounts. So whoever wants to automatically remove unused accounts can > configure apt to do so by calling this utility from DPkg::Post-Invoke. That might be possible, yes. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the release team: the plans for etch
* sean finney ([EMAIL PROTECTED]) [051026 14:20]: > On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote: > > If a package's postrm removes the user, and the next package's postinst > > just calls "adduser", then the admin have no control over the reusing. > > > > If you want to allow automatic user/group removal, then adduser should > > be extended to remember every UID/GID that was ever used by a system > > user, and never reuse them again even if they have since been removed > > from /etc/passwd and/or /etc/group. > > i don't think removing and reusing users is a good idea in practice. > what harm would there be in simply leaving the user account on the > system permenantly, with maybe locking the account and setting the > shell to /bin/false? Yep, that's probably best practice. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tiffani now on ftp.debian.org / people.d.o/~aba/ turned off
Hi, as some of you already know, Anthony turned on tiffani on ftp-master. As the tiffani on people is now longer needed (and also broken by this change), I disabled the cronjob. Please just use your normal debian mirror for support of partial lists. Thanks for all your help, support, debugging etc. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
