Re: Mandatory LC_ALL=C.UTF-8 during package building
Sorry for being late to this discussion, but there are a few points and a suggestion I'd like to make: 1. Reproducibility is not a big concern Quoting policy: Packages should build reproducibly, which for the purposes of this document means that given ... - a set of environment variable values; ... repeatedly building the source package ... with ... exactly those environment variable values set will produce bit-for-bit identical binary packages. There is also the practical side that our buildds already set LC_ALL=C.UTF-8, in main one can already assume that every package in a release has been built with in this environment. 2. RC is what does FTBFS on the buildds Usually a FTBFS is RC only when it happens on the buildds. FTBFS with non-C.UTF-8 locales itself is not RC, just like FTBFS on single-core machines is not RC. These are of course still bugs, especially if a different UTF-8 locale results in test failures that indicate runtime issues. 3. Importance of build-time diversity Less than 3 years ago, having build-arch/build-indep targets in debian/rules was a usecase important enought for some people that a MBF with hundreds of RC bugs was done and many people (including myself) spent time fixing this usecase by adding build-arch/build-indep targets to packages. Calling the clean target manually is something I frequently do. Doing a build test or autopkgtest with an Estonian or Turkish locale is hard/impossible when something (no matter whether debian/rules or debhelper or dpkg-buildpackage) enforces C.UTF-8. 4. C.UTF-8 or *some* UTF-8 locale? The main problems are with non-UTF-8 locales, it might be uncontroversial to declare building with a non-UTF-8 locale unsupported and make dpkg-buildpackage reject this with a message like: Building with a non-UTF-8 locale is no longer supported, please do LC_ALL=C.UTF-8 dpkg-buildpackage This should be sufficient to address the root cause of all/most of the current manual and tooling settings of C.UTF-8, and could actually enable useful testbuilds for finding problems for Turkish users. cu Adrian
The sarge release disaster - some thoughts
Hi, I'm a former Debian developer, and this mail contains some subjective observations of mine regarding what lessions Debian might learn from mistakes during the sarge release cycle. Contents: - Introduction - Have a second plan - Discover problems early and react - RC bugs - only a metric - Dump testing? Introduction These are just my personal thoughts. If you think 90% of this email are bullshit, I'm glad to hear that you think 10% of this email contain valid points. I'm talking about issues with the release management. This isn't meant as a personal offence against former release manager Anthony Towns and the current release managers Steve Langasek and Colin Watson and their assistants. Everyone makes mistakes and I might have made more mistakes in my life than all these people together. I do believe that the Debian release managers tried their best. But things went wrong. It wasn't bad luck - mistakes were made. And the mistakes should be evaluated to avoid them in the future. The situation today is that several announced release dates for sarge have passed, with the first one being December 1st 2003 [1]. Debian stable is horribly outdated - e.g. it's nowadays non-trivial finding new hardware completely supported by Debian 3.0 . Why don't I send this mail after the release of sarge? Well, I thought exactly this way several months ago. But much time passed since then, and the release of sarge is still not in the past. Have a second plan - Discover problems early and react -- Some pretty simple rule might have avoided several delays in the sarge release cycle: If there are risks that might cause great delays, habe a second plan if it doesn't work out as planned. Two examples: The Debian installer The timeline for the first officially announced release date was: - August 19th 2003: announcement - October 1st 2003: installer has to be in a state that it only requires "last minute fixes" - December 1st 2003: announced release date - December 1st 2003: announcement that sarge isn't being released I don't know whom of the people responsible to the installer had promised to Anthony that the installer would be ready that fast. Anthony said in his announcement that the timeline he set was an "aggressive goal". With this in mind, extra care would have been required to have a second plan if any part of his release plan would fail. Not after October 1st 2003 it sould have been clear that the progress of the installer wasn't as good as expected. This was 2 months before the announced release date. What would have been a second plan? Nobody likes boot-floppies. But considering the choice between releaseing Debian 3.1 with the new installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it might have been possible finding some Debian developers hacking boot-floppies to use them for Debian 3.1 . The new installer would have been ready in time for Debian 3.2 . Would this have been an ideal solution? No. But it's quite possible that it might have worked - and that it might have benefitted the users of Debian. The timeline for another failed release date: - August 2nd 2004: announcement - August 8th 2004: "Official security support for sarge begins" - September 15th 2004: announced release date The milestone that included the start of the official security support for sarge was only 6 days after the announcement, but is was missed by more than 6 months. Whyever it was expected to get testing-security for sarge that quick, it should have been obvious 6 days later that it wasn't possible that quick. What would have been a second plan? Use testing-proposed-updates. Using testing-proposed-updates for security fixes, users might have gotten security updates one or two days after the DSA on some architectures. Would this have been an ideal solution? No. But it would have worked without a great impact on the release date. RC bugs - only a metric --- Nowadays, it seems the main metric to measure the quality of a release inside Debian is the RC bug count. As with any metrics, work on improving the metric might make the metric look much better, but doesn't at the same time imply that the overall quality improved that much. An example: A major problem in Debian are MIA developers. Consider a MUA maintained by a MIA developer with the following bugs: - #1 missing build dependency (RC) - #2 MUA segfaults twice a day (not RC) Consider the two possible solutions: 1. a NMU fixing #1 2. - ensure that the maintainer is MIA - orphan all packages of the MIA maintainer - new maintainer adopts MUA - new maintainer fixes both bugs The first solution has a quick positive effect on the "RC bug count" metric. The second solution looks worse in this metric, but it's actually better for the users of Debian. Dump testing? - It seems noone
An alternative analysis of the etch architecture proposal
Let's analyze the requirements the release team sent for release architectures: - it must first be part of (or at the very least, meet the criteria for) scc.debian.org (see below) - there must be a developer-accessible debian.org machine for the architecture. That's obvious. - the release architecture must have a working, tested installer Assuming sarge releases with all 11 woody architectures, and the sarge installer will be used for etch, too, this shouldn't be a problem for any of these architectures. - the Security Team must be willing to provide long-term support for the architecture - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture - the Release Team can veto the architecture's inclusion if they have overwhelming concerns regarding the architecture's impact on the release quality or the release cycle length Assuming this is not being abused that's obvious. - the release architecture must be publicly available to buy new That's currently easily met by all 11 woody architectures. Alpha and hppa will obviously be the first candidates being affected by this rule, but I fail to see how dropping these two architectures will have a great impact on the release cycle. - the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages - the value of N above must not be > 2 - the release architecture must have successfully compiled 98% of the archive's source (excluding architecture-specific packages) These are restrictions only imposed by testing. If testing imposes restrictions with the effect of removing at about two thirds of the architectures from Debian stable, shouldn't it be time to evaluate whether the price of testing is really worth it? If Debian would dump testing [1], they would automatically go away. - issues with space on ftp.debian.org and on mirrors (especially hindering amd64) It might be a better point to start moving non-released architectures (GNU Hurd and sh) to a different location. Depending on what exactly hinders amd64 today, this might be sufficient [2]. Regarding mirrors, offering only m architectures or offering only Debian stable for n architectures should be solvable on a per-mirror basis without any effect on the release management. cu Adrian [1] http://lists.debian.org/debian-devel/2005/03/msg01320.html [2] my impression is that communication problems between the amd64 porters and the ftp admins might be a bigger problem for including the amd64 port than technical problems -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote: >... > SO archs will be handled exactly like we do now, EXCEPT that we will > not distribute .debs for most packages. I expect that we will > distribute .debs for base and build-essential, mainly -- the minimum > someone needs to install a working system and build more packages. >... > What would this mean for users? > > Basically, packages install slower on these archs. I have developed a > demonstration tool called srcinst, available from > http://people.debian.org/~jgoerzen/srcinst/. srcinst is capable of > filling all of a package's dependencies and build-depencies solely > from source. It will use apt-get -b source to build .debs, then > evaluate (and build, if necessary) their deps, then install them with > dpkg -i. In short, very similar to apt-get install, except it never > downloads a .deb from anywhere for any reason. (Most other tools > don't go this far, and still require .deb downloads for build-deps, or > don't handle deps at all) >... > So, what do you think? Could this work? Yes, this could work. That's what Gentoo is good at. Both source-only distributions like Gentoo and binary distributions like Debian are possible - and both have their advantages and disadvantages. I'd hate so see Debian drop most of it's architectures, and as I already expressed I think it's neither required for release management reasons nor for ftp space reasons. Your priority are your users, and if Debian has decided to focus only on some key architectures it would be the best for them to help them switching to Gentoo instead of hacking Debian to become some cheap Gentoo clone for most architectures. If the Debian developers intereested in the ports Debian intends to drop would switch to Gentoo for helping Gentoo to support all of their architectures and for providing easy Debian -> Gentoo transition paths this would serve your users better. > -- John cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 04:55:08PM -0500, Alec Berryman wrote: > Ola Lundqvist on 2005-03-15 22:45:45 +0100: > > > This is the problem. How do you make sure that the package is > > buildable on the architecture without building it? And if you have > > built it why not just add it to the archives. :) So you still need a > > buildd. :( > > Why not add it to the archives? Because there isn't enough disk space. Where exactly isn't enough space? On Debian servers? -> There'd be enough money for new disks or even new servers. On some mirrors? -> Not all mirrors have to mirror all ports. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 04:06:35PM -0800, Thomas Bushnell BSG wrote: > > I am of the opinion that the testing distribution has been a great > help in releasing. >... Is this just a personal opinion or backed by any objective evaluation? I'm asking because as I've already expressed my impression is that if testing was completely dumped, many of the issues leading to this dropping of several architectures wouldn't exist. > Thomas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 01:17:03PM +0100, Ingo Juergensmann wrote: >... > > But really, is there much benefit in > > making *releases* for the SCC architectures? > > The packages will still be built and d-i maintained as long as there are > > porters interested in doing that work for the architecture. The only > > difference is that those architectures won't influence testing and they > > won't be officially released. > > What will happen is something like this: > > A: "Oh, let's see what we got here a nice Alpha server..." > B: "Let us install Debian on it!" > *browsing the web* > A: "Oh, no release of Debian for Alpha... it's unsupported..." > B: "Sad... it's a nice machine, but without a working Linux on it, we're gonna > throw it away" A: Wait. Thank god, it's supported by Gentoo. > Ciao... // > Ingo \X/ cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
On Tue, Mar 15, 2005 at 07:40:09PM -0500, Joey Hess wrote: > Adrian Bunk wrote: > > Not after October 1st 2003 it sould have been clear that the progress > > of the installer wasn't as good as expected. This was 2 months before > > the announced release date. > > > > What would have been a second plan? > > Nobody likes boot-floppies. > > But considering the choice between releaseing Debian 3.1 with the new > > installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it > > might have been possible finding some Debian developers hacking > > boot-floppies to use them for Debian 3.1 . > > > > The new installer would have been ready in time for Debian 3.2 . > > IIRC when we did this for potato, getting the woody boot-floppies > updated to work with the new kernel and potato took something on the > order of 6 months. Do not make the mistake of thinking the boot-floppies > were maintainable. Expecting them to be ready in two months would be > impractical. Someone of the installer people must have promised ajt that the installer was ready at the dates in the release announcement (or ajt wouldn't have announced these dates) - and it should have been clear two months before the announced release date that this wouldn't work. Let me give the worst possible second plan: Release with the original potato boot floppies. I'm not talking about elegant solutions. I'm talking about hacks to not let the delays in the installer after the release announcement delay the whole release by a year or more. > Also, bear in mind that if we'd have done that, then we would still be > where we are right now, but would not have the debian installer ready to > release with sarge. It might have delayed the work on the new installer. But delaying Debian 3.2 by a few months if this would have enabled a release of Debian 3.1 in 2003 doesn't sound like a very bad tradeoff for your users. > > What would have been a second plan? > > Use testing-proposed-updates. > > testing-proposed-updates is _still_ missing autobuilders. Please correct me if I'm misunderstanding things: t-s required some infrastructure changes that took at about half a year. Getting missing autobuilders for t-p-u is a task that requires manpower and perhaps even money, but if it's _the_ showstopper, it should be resolvable within a few weeks or even days. So this might have reduced a half a year delay to a few weeks delay. > > Consider a MUA maintained by a MIA developer with the following bugs: > > - #1 missing build dependency (RC) > > - #2 MUA segfaults twice a day (not RC) > > > > Consider the two possible solutions: > > 1. a NMU fixing #1 > > 2. - ensure that the maintainer is MIA > >- orphan all packages of the MIA maintainer > >- new maintainer adopts MUA > >- new maintainer fixes both bugs > > > > The first solution has a quick positive effect on the "RC bug count" > > metric. > > The second solution looks worse in this metric, but it's actually better > > for the users of Debian. > > I doubt that many people NMU for RC bugs without also looking at the > recent release history of the package and checking to see what other bad > bugs the package may have. The first example that comes into my mind is the info package where the two NMUs didn't fix the many open segfault bugs (e.g. #259561 contained a trivial patch ACK'ed by upstream being one and a half months in the BTS before the latest NMU - note that this NMU was even done by a Release Assistant). This shouldn't be a personal offense against the person who did this particular NMU - it's simply the first example coming into my mind. > see shy jo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Wed, Mar 16, 2005 at 02:30:29PM +0100, Wouter Verhelst wrote: >... > Also it wouldn't help on slower architectures. People usually decline > installing NetBSD on m68k (even if that's possible) when it takes two > weeks to make the system useful, simply because everything needs to be > compiled manually. >... NetBSD also offers binary packages for many years. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 09:36:17AM -0500, Daniel Jacobowitz wrote: > On Wed, Mar 16, 2005 at 12:50:31PM +0100, Martin Schulze wrote: > > > We project that applying these rules for etch will reduce the set of > > > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > > > and amd64 -- which will be added after sarge's release when mirror space > > > is freed up by moving the other architectures to scc.debian.org). > > > This will drastically reduce the architecture coordination required in > > > testing, giving us a more limber release process and (it is hoped) a > > > much shorter release cycle on the order of 12-18 months. > > > > Since this is the first time I hear that so much of "architecture > > coordination" is required for testing, could you elaborate how much > > time this is referring to and which problems the release team has > > faced in particular? I'd be glad if somebody could propose an > > alternative solution, as dropping most architectures would be a large > > regression for Debian and its community. > > I think that all they mean is "the complicated act of getting, and > keeping, all architectures in sync in testing". For instance, getting > large packages built in the same version on every architecture, > discovering an architecture-specific bug, and redoing the whole thing > before it or any of its dependencies can migrate to testing. Not a new > problem, especially for anyone reading debian-release. >... I already sent two mails [1,2] where I expressed my opinion that dumping testing might be an option since it's the main reason for the underlying problems that seem to cause the proposed removal of two third of the Debian architectures from the Debian releases while it hasn't proven to bring any real benefits for the release. The interesting thing is that while people answered to other parts of these emails, noone said anything about my points regarding testing - neither in favor nor against them. I do not claim my points have to be correct, but IMHO this would be an alternative solution that should be evaluated. > Daniel Jacobowitz cu Adrian [1] http://lists.debian.org/debian-devel/2005/03/msg01320.html [2] http://lists.debian.org/debian-devel/2005/03/msg01367.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote: > On Wednesday 16 March 2005 18:12, Adrian Bunk wrote: > > I already sent two mails [1,2] where I expressed my opinion that dumping > > testing might be an option since it's the main reason for the underlying > > problems that seem to cause the proposed removal of two third of the > > Debian architectures from the Debian releases while it hasn't proven to > > bring any real benefits for the release. > > > > The interesting thing is that while people answered to other parts of > > these emails, noone said anything about my points regarding testing - > > neither in favor nor against them. > > You fail to list and address the points testing claims to address. > > Therefore I judge this part of your otherwise quite sensible mail ranting I > don't have to argue for or against because it has no real content except > expressing your personal animosities. > > Ouch. Seems like I fell into the communication trap myself. Here is a weak > try > at refuting your proposal: > > To archive a stable release, arches have to be in sync, there should be only > a > single version of every library and packages have to be installable. This > seem to be the problems I believe testing was designed to solve. Incidentally > this almost the list of "problems" you identify being the cause of testings > problems. Kinda matches. Going back to a frozen-only release cycle would > ignore these problems until half a year before the release. Then the same > work that is now done for testing would have to be done anyways: arches > brought to sync, libraries transitioned and package installability > guaranteed. I agree with you that testing helps with some problems like getting packages in sync and installable. But currently testing needs regular manual help by the five members of the release team to keep on running. Exactly the same amount of work they are currently doing [1] might bring the same effect without testing since this information (and much more) is also available without testing. "libraries transitioned" is a big point against testing: Transitions of API-compatible libraries are a pain _only_ due to testing. In unstable, such a transition can easily be done within a few days. But the transition to testing requires that all affected packages (which might be 100 source packages for some transitions) are ready _at the same time_, more exactly: - each package mustn't have more more RC bugs than the testing scripts estimate for the version in testing - each package must be built on every single architecture - the dependencies of every single affected package must be met after the transition - this way, often several transition generate a mega-transition of packages that have to go into testing at the same time Even if all this was fulfilled, a manual hint is still required. And for bigger transitions, there are always manual adjustments required since these requirements aren't fulfillable in practice. Check how many of the announcements of your release team mention as an important point that this transition was finally finished or that transition is the next important milestone. And without testing, all these transition problems wouldn't exist. > Thus I make two observations: > > 1) Only dropping testing would increase the risk (by delaying the detection > of > the problems) without noticeable reductions in amount of work (if Debian > still aims at a 12-18 month release cycle) As I tried to explain above, the same information is already available elsewhere and the same amount of work currently spent into testing might as well suffice to treat them equally. > 2) Providing a better alternative is more efficiently done by those > dissatisfied with the status-quo (i.e. you) as opposed to those who worked > hard to establish the status-quo as solution to their problems (i.e. > ftp-master and release team). Was this meant ironically? In case it was: If you work in a field, it often happens (and it's unfortunately quite normal) that you get a narrow view. > Thank you for still caring about Debian! > > Regards, David cu Adrian [1] as already said: I do not deny that the release team does much work -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 12:24:00AM +0100, Marco d'Itri wrote: > On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > > One of the conditions for SCC is "fully functioning Unix, including > > > > DNS and firewall support." What specifically is intended by "firewall > > > > support"? > > > I think that simple ACLs are the bare minimum. > > Ok, can you point me at the specific feature, and why is this feature > I think that the minimum is per-interface permit/deny ACLs which could > match at least on IP protocol number, TCP/UDP ports and ICMP types. > > > important for packaging in SCC? > Because Debian should not waste resources to support a toy OS (in this > case defined as one not secure enough to stay on the internet for real > work). The statement in the announcement was: - the port must include basic unix functionality, e.g resolving DNS names and firewalling "resolving DNS names" is obviouly required. But why is "firewalling" required? It's the question what a "toy OS" is, and whether a "toy OS" might be supported by Debian. It seems what makes Thomas suspicous is that of all current ports of Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is GNU/Hurd - this requirement is therefore either void for all current Debian ports or it was meant specifically against GNU/Hurd. Thomas' question is simply whether five of your six DPL candidates have signed that they want to kick GNU/Hurd even out of the proposed SCC archive or not. Steve's announcement only listed actions without giving the rationale for each of them, and it would therefore be required that someone of the 12 people who signed this announcement should clarify this point. > ciao, > Marco cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Thu, Mar 17, 2005 at 12:29:28AM +, Darren Salt wrote: > I demand that Adrian Bunk may or may not have written... > > [snip] > > And without testing, all these transition problems wouldn't exist. > > And without testing, there are those who currently use testing who'd use > stable instead, or possibly go elsewhere. > > (I'm currently using testing. Updating an installation from unstable over a > dial-up connection isn't /quite/ what I want...) Even if you are using unstable, noone forces you to update all packages on a daily basis. The main reason of people I know who are currently using testing is simply that Debian stable is much too outdated for being useful. I do believe that it was still possible to release a new stable Debian once a year [1] - and that this was still possible using a "traditional freeze" without testing. For making testing really usable, security support would be required. This requires manpower (that might perhaps be available). And it requires something else: The testing scripts would have to handle build dependencies as if they were dependencies. This shouldn't be too hard to implement, but my impression is, that the sole reason why it isn't implemented until now is, that it would increase the amount of manual work required by both the release team and all Debian developers even more. And this leaves still the question whether it's worth sacrificing eight architectures. cu Adrian [1] no, I'm not talking about point releases -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of buildds?
On Thu, Mar 17, 2005 at 12:21:15AM -0800, Thomas Bushnell BSG wrote: >... > Catchup has started to make some progress; the current disaster buildd > seems to be arm, now that mipsel has mostly caught up and s390 has > turned around. So long as at least a single buildd arch is having > trouble, we are all penalized. Are there any reasons why you "are all penalized" that are not only imposed by testing? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote: > On Mon, Mar 14, 2005 at 07:59:43PM +, Alastair McKinstry wrote: > > > AFAI can tell, anybody can host an archive of packages built from stable > > > sources for a scc or unofficial port. And - if I read the conditions on > > > becoming a fully supported Debian arch right - then having security > > > support > > > for an external pool of this arch is a good indicator that it should be a > > > fully supported stable release (amongst other things). > > > The plan as proposed is that the Debian scc ports are purely builds of > > unstable. Hence this build out of the last release (e.g. etch) becomes a > > subproject of a second-class project of Debian. It effectively has > > little credibility. > > Well, the release team are not the only Debian developers with credibility, > surely? Not everything needs to go through us; if the project has the will > to do stable releases of these architectures, in spite of the release team > being unwilling to delay other architectures while waiting for them, then > it should be very possible to provide full stable releases for these > architectures. >... Which delays are expected for etch, that are not only imposed by the usage of testing for release purposes? [1] I do still doubt that testing actually is an improvement compared to the former method of freezing unstable, and even more do I doubt it's worth sacrificing 8 architectures. > Steve Langasek cu Adrian [1] The installer might be a point, but since all sarge architectures will have a working installer and I hope there's not another installer rewrite planned for etch this shouldn't be a big issue. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote: > On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote: > > [1] The installer might be a point, but since all sarge architectures > > will have a working installer and I hope there's not another > > installer rewrite planned for etch this shouldn't be a big issue. > > This is still an issue. Joey Hess's mails have indicated very clearly that > it's > difficult to get an installer release out even when all arches are already > supported. You are referring to his email regarding problems with getting updates kernel images for all architectures? I agree that's a point. But this problem is already being attacked by the kernel team. There are also other areas where work on the installer might be easier if fewer architectures were supported, but are they heavy enough for dropping two thirds of the Debian architectures - or are they issues where improvements were possible? > - David Nusinow cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Thu, Mar 17, 2005 at 09:39:10PM +0100, David Schmitt wrote: > On Thursday 17 March 2005 00:21, Adrian Bunk wrote: > > On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote: > > "libraries transitioned" is a big point against testing: > > > > Transitions of API-compatible libraries are a pain _only_ due to > > testing. In unstable, such a transition can easily be done within a few > > days. > > Which leaves one with the problem that the new library might break any or all > of the depending packages, which testing would catch, while transitioning > unstable might not. But I have to admit that I didn't follow debian > development as closely as I do now in the times before testing and thus might > be arguing against the wind. This is possible (but see your own comment below). The bigger problems from the point of view of users aren't transitions (which usually go smooth - you simply have two versions of a library installed) but breakages like accidential ABI changes without an so-name change. These aren't necessarily caught be testing (except through the RC bug count), and libtiff is a good example where such a usere-visible problem made it into testing. > Perhaps the best would be to prepare the transition beforehand in > experimental > and push the packages together into unstable, like GNOME and KDE did their > respective last big updates? This also would be a step towards reducing > dependency on work from the central teams. That's a good idea and already done. But this is independent of the question whether testing is present or not. > Regards, David cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
>
> > Which delays are expected for etch, that are not only imposed by the
> > usage of testing for release purposes? [1]
>
> > I do still doubt that testing actually is an improvement compared to the
> > former method of freezing unstable, and even more do I doubt it's worth
> > sacrificing 8 architectures.
>
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?
Well, producing a release from a "snapshot" of unstable in a way that's
at least roughly comparable with current stable releases on this
architecture are:
- release management
- security support
Freezing for one architecture from some snapshot of unstable is roughly
comparable to a complete release process you as a release team are
doing. But it's worse. One email from you to d-d-a "We will freeze in
two months, please don't do big changes and stabilize your packages
instead." results in an unstable (and therefore a testing) that's in a
relatively good shape at the start of the freeze [1]. And after the
start of the freeze, most maintainers will work on stabilizing the
frozen packages instead of putting new versions into unstable. Yes, this
doesn't work 100%, but it still distributes a serious amount of work
from the release team to all maintainers. How much of this work will be
distributed away from the porters if they announce: "The m68k team will
release based on an unstable snapshot taken two months from now."?
And assuming you want to use such port specific releases on computers
that have more than one user and/or that are connected to any network,
you need security support. Joey (who should know best) already explained
that for the security team it doesn't matter whether much they have to
support 2 or 20 architectures within a release, but every additional
distribution causes a lot of extra work for them. Whom do you want to
put the burden for security releases of the 8 sarge architectures you
expect to not release with etch on? Should the security team carry this
burden, or should every porter team form their own security team
releasing their own DSA's?
That's so much extra work for every single port that makes it nearly
impossible for architectures to achieve what they get if they are in the
regular release process that it's nearly impossible.
> It sounds to me like it's exactly what you've always wanted,
> to eliminate testing from the release process...
>...
Yes, I'm not a fan of testing.
But I do understand how testing works.
Both my previous emails in these threads and this emails aren't emails
simply "testing bashing" emails without real contents. I'm trying to
point at the weaknesses of a release process with testing - like every
other release process, it has both advantages and disadvantages.
Testing has it's advantages.
You know that all packages have there dependencies fulfilled [2], were
built on all architectures, and some kinds of bugs are less likely to
make it into testing.
There were many release updates the release team sent that mentioned as
a major success that transition A is now finally into testing and it was
hoped that transition B will go into testing soon. How many weeks did it
took altogether that were spent getting transitions into testing that
were already completed in unstable? And how many hours have members of
the release team spent for hints, coordinating between maintainers etc.
for getting these transitions into testing? These are extra costs of
testing.
And you explained in your announcement that removing approx. 8 of the
current architectures from the release process "... will drastically
reduce the architecture coordination required in testing, giving us a
more limber release process and (it is hoped) a much shorter release
cycle on the order of 12-18 months."
IOW:
You are saying the current release process with testing has problems
that make it impossible to achieve a release cycle on the order of 12-18
months with many architectures.
One possible solution for this problem you observed is reducing the
number of architectures.
Another possible solution for this problem is to switch to a release
process without testing.
cu
Adrian
[1] This was more effective if freeze announcements weren't sent 6 days
before the freeze, but it's your choice as release manager to not
take the full advantages of early announcements.
[2] but build dependencies are still not tracked
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new arch support proposal, hopefully consensual (?)
On Sun, Mar 20, 2005 at 07:22:07PM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Debian as a whole shouldn't suffer from minority arches. So we decide to
> > refuse most of the constraints imposed by the minority arches... this
> > way the release team shouldn't pester porter until they setup an
> > rbuilder for security uploads or a supplementary buildd.
>
> A good strategy would be to limit the bandwith, cpu-power and man-power
> needed to build the packages of a distribution. This essentially means you
> only release a base system, like Fedora or FreeBSD does.
>
> Releases of additional packages ("Extra", "Ports") can then be made as
> snapshots with different release cylces for the slower architectures.
Every proposal that has different releases for different architectures
causes serious additional burdens for your security team.
> I think it is important to release the base system more often, and I really
> admire what Fedora has done here. And this was for sure only possible with
> a limited set of packages.
>...
If you split Debian into parts with independent sub-releases (like into
a "base system" and "extra" parts), getting all combinations of these
parts and all upgrades of parts correct at a level Debian users are used
from Debian stable becomes really non-trivial.
The complete release team signed the announcement stating that the
testing release process is not capable of release cycles in the order
of 12-18 months with 11 architectures.
The release team prefers to keep the release process with testing but
adapt the number of architectures to the capabilities of this release
process.
You want a completely different release process.
I for one do believe that the pre-testing release process was still able
to cope with releasing with the number of packages currently in unstable
on a dozen architectures and yearly releases with an amount of work
comparable to what is required for releases with the testing release
process.
> Greetings
> Bernd
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 12:50:03PM +0100, Wouter Verhelst wrote: > On Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote: > > So, I'd just like to re-emphasise this, because I still haven't seen > > anything that counts as useful. I'm thinking something like "We use s390 > > to host 6231 scientific users on Debian in a manner compatible to the > > workstations they use; the software we use is ; we rely on having > > security support from Debian because we need to be on the interweb 2; > > ...". At the moment, the only use cases I'm confident exist are: > > > > m68k, mips, mipsel, hppa: I've got one in the basement, and I like > > to brag that I run Debian on it; also I occassionally get some work out > > of > > it, but it'd be trivial to replace with i386. > > Aren't the first three of these also actively being used in embedded > applications? (not sure about that one; I'm not /that/ much involved > with embedded stuff) > > I can also imagine some hppa boxes being used as test or development > platform in the enterprise. Note that they were still being sold as new > only a few years ago. >... HP still produces both workstations and servers with PA-RISK processors. Note that 50 out of the 500 fastest computers in the world [1] are computers with PA-RISK processors manufactured by HP in 2004. cu Adrian [1] http://www.top500.org/ -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote: > On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: > > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > > * the release architecture must be publicly available to buy new > > > > Avoids a situation where Debian is keeping an architecture alive. > > > I don't understand this. What is the problem with Debian is keeping an > > architecture alive? What problem are you trying to solve here? > > Given that there are architectures that have been end-of-lifed (but *are* > still available for purchase new) that we've had problems keeping our > autobuilders running for, I think it's a fair guess that hardware that truly > is no longer available for purchase is going to be costly for the project to > continue to support for a stable release. >... The only sarge architectures that are likely of being affected by your "must be publicly available to buy new" rule during the next 10 years are hppa and alpha (dunno about s390). Both architectures had a long lifespan during which many machines were produced and damned fast machines are likely being produced until the last day when they'll be produced. For both of these architectures, HP still offers servers today. And if HP one day stops with this, they will still have to offer replacement parts for their costumers for _many_ years. Debian has good connections with HP. Wouldn't an arrangement with HP of getting hardware plus some years of support being an alternative to your announcement that you plan to drop the hppa and alpha architectures from Debian releases? > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 07:45:00AM +, Alastair McKinstry wrote: > > I think the point of this requirement is to support it we need buildds > in the future for security fixes. Hence while I might like my mips box, > etc. it would be irresponsible for us to do a release that we could not > support in e.g. two years time when the motherboards of our buildds die. Mips is extremely alive and it was a huge surprise if new mips-based products weren't available ten years from now. > Perhaps this clause could be refined, though: should it be a sub-arch > requirement and not just an arch one; or could we specify that its OK to > release if we have a given stock of replacement hardware available > (e.g. given our good relationship with HP, its likely we could get > sufficient Alpha hardware for several years after HP finally stop > shipping Alphas). The release team's announcement affects only hppa and alpha in the forseeable future. And in both cases an arrangement with HP could erase the problems. > Regards > Alastair McKinstry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Mon, Mar 21, 2005 at 11:13:40PM +, Matthew Garrett wrote: >... > People are far too busy picking on small details of proposals they don't > like instead of coming up with a decent and comprehensive set of > solutions. If you don't like what's been proposed, produce something > better. For the most part, that's how Debian works. My proposal is: Change the release process to a release process without testing. Rationale: The whole release team plus Anthony Towns who's the main developer of testing signed the following statement: <-- snip --> We project that applying these rules for etch will reduce the set of candidate architectures from 11 to approximately 4 ([...]). This will drastically reduce the architecture coordination required in testing, giving us a more limber release process and (it is hoped) a much shorter release cycle on the order of 12-18 months. <-- snip --> If your release process has problems with the current number of architectures, you have two choices: - announce that you plan to drop two third of the architectures - change the release process I'd prefer the second choice. Testing has it's advantages. You know that all packages have there dependencies fulfilled [1], were built on all architectures, and some kinds of bugs are less likely to make it into testing. But testing also has it's costs (read e.g. what Steve listed as three points that "probably account for more of my release management time than anything else" [2] - they are testing specific tasks). Testing helps with some problems like ensuring that all dependencies are fulfilled and that packages have been built on all architectures - but this information is also available elsewhere. What instead? What about the simple pre-testing release process: - announce a freeze date - freeze unstable at the announced date - work a few months on improving frozen until it's in a releasable state I do believe that such a simple release process would allow releasing once a year with a dozen architectures. And if the buildd on an architecture wasn't able to keep up with unstable it wasn't nice - but it wasn't a problem for the release management since it was enough if the buildd started to keep up with frozen after the freeze (and the number of daily uploads to frozen should be much smaller than the number of daily uploads to frozen). This would therefore make (at least from a release management point of view) all discussions regarding the required speed of buildds obsolete. cu Adrian [1] but build dependencies are still not tracked [2] http://lists.debian.org/debian-devel/2005/03/msg02334.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: >... > The top three things I've spent release management time on that I shouldn't > have had to are, in no discernable order: > > 1) processing new RC bug reports to set sarge/sid tags appropriately, so > that the RC bug list for sarge bears some resemblance to reality > > 2) prodding maintainers to get all packages associated with library soname > transitions synchronized so that they can progress into testing together > (seems to require an average of 2-3 iterations, and 3-4 weeks) > > 3) chasing down, or just waiting on (which means, taking time to poll the > package's status to find out why a bug tagged 'testing' is still open), > missing builds or fixes for build failures on individual architectures that > are blocking RC bugfixes from reaching testing > > Taken together, these probably account for more of my release management > time than anything else, including actual work on release-critical bugs. >... Is it correct that none of these three points that account for most of your release management time would exist in a release process without testing? > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 02:55:17PM +, Michael K. Edwards wrote: > On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: > > >... > > > The top three things I've spent release management time on that I > > > shouldn't > > > have had to are, in no discernable order: > > > > > > 1) processing new RC bug reports to set sarge/sid tags appropriately, so > > > that the RC bug list for sarge bears some resemblance to reality > > To the extent that maintainers accept upstream's crack-of-the-day into > sid, relying on a not-for-sarge mechanism instead of letting the bugs > pile up upstream, the testing scripts do worsen the traffic late in > the release cycle. Beats binge-purge, if you ask me, but YMMV. > During a freeze-by-whatever-mechanism, becoming informed about whether > allowing a given update would improve or worsen the situation takes > effort; sarge/sid tags are part of that analysis. I think Steve is > mostly saying that scrubbing the raw bug report data by disambiguating > sarge and sid bugs shouldn't be the release manager's job. Without testing, there was no need for anyone to do such a distinguishing before the freeze starts. And if you'd (in a relesase process without testing) freeze unstable for some time after the beginning of the freeze, you could get the point when frozen starts diverging from unstable even later. > > > 2) prodding maintainers to get all packages associated with library soname > > > transitions synchronized so that they can progress into testing together > > > (seems to require an average of 2-3 iterations, and 3-4 weeks) > > Yep, this is a lot of work. The alternatives are unbuildable packages > (left behind by a transition) or multiple versions of core libraries. > The relevant packaging teams are getting the hang of it, though, and > testing is a good tool for measuring progress towards an engineered > release. Again, I think Steve wants this to be more of a > maintainer/porter responsibility during more of the cycle. As I've already said in another email: Transitions of API-compatible libraries are a pain _only_ due to testing. In unstable, such a transition can easily be done within a few days. Remember the libtiff transition. Look at the various libexif transitions. ... The transition in unstable is trivial (changing the build dependencies in the packages). The complete transition into testing is a pain (in the libtiff case Steve cheated by introducing a second libtiff source package but it still took some time). > > > 3) chasing down, or just waiting on (which means, taking time to poll the > > > package's status to find out why a bug tagged 'testing' is still open), > > > missing builds or fixes for build failures on individual architectures > > > that > > > are blocking RC bugfixes from reaching testing > > Comments elsewhere; but I certainly don't think this is caused by > testing. Don't shoot the messenger. >... Steve's talking about bugs already fixed in unstable that might still be present in testing. Why do you think this wasn't caused by testing? > Cheers, > - Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 03:20:04PM -0800, Steve Langasek wrote: > On Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote: > > On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: > > >... > > > The top three things I've spent release management time on that I > > > shouldn't > > > have had to are, in no discernable order: > > > > 1) processing new RC bug reports to set sarge/sid tags appropriately, so > > > that the RC bug list for sarge bears some resemblance to reality > > > > 2) prodding maintainers to get all packages associated with library soname > > > transitions synchronized so that they can progress into testing together > > > (seems to require an average of 2-3 iterations, and 3-4 weeks) > > > > 3) chasing down, or just waiting on (which means, taking time to poll the > > > package's status to find out why a bug tagged 'testing' is still open), > > > missing builds or fixes for build failures on individual architectures > > > that > > > are blocking RC bugfixes from reaching testing > > > > Taken together, these probably account for more of my release management > > > time than anything else, including actual work on release-critical bugs. > > >... > > > Is it correct that none of these three points that account for most of > > your release management time would exist in a release process without > > testing? > > Misfiled bugs would be a problem in a freeze/unstable configuration, just as > they are in a testing/unstable configuration. In a freeze/unstable configuration, this starts after the freeze. (Or if you keep unstable frozen, even later.) And during a freeze, I wouldn't expect much activity in unstable, making the problem in the freeze/unstable configuration even smaller. In a testing/unstable configuration, this affects all bugs including bugs that were filed many months before the freeze. > Getting binaries up-to-date across all architectures for RC bugfixes would > be a problem in a frozen suite, just as it is in testing. But even if the autobuilders of an architecture have a problem with keeping up with unstable, they are much more likely being able to keep up with frozen since the amount of changes is much smaller. And it wasn't a problem if there was no autobuilder for an architecture for two weeks during a non-freeze time. > Library soname transitions would be unlikely to happen in a freeze, but that > just means any transitions that are in progress at the time all have to be > dealt with *when* we freeze, even if they aren't necessary transitions. Transitions in unstable are easy. The problem is usually only getting a transition into testing. Assuming a freeze is announced early enough, it shouldn't be a big deal ensuring that all transitions are completed before the freeze in a freeze/unstable configuration. > In any case, this overlooks one of the principal advantages of testing, > which is that it avoids releasing software that's already 1 year out of date > at the time of release. This was a goal of testing. The woody freeze took 7 months. Depending on how you count, the current freeze of sarge started more than one and a half years ago, or it started "only" seven and a half months ago - and sarge still isn't released. As things are today, sarge will release with an X11 being more than two years old. This is the second release with the testing release process, and the assumed advantages of testing still aren't visible through shorter release cycles. You yourself signed that statement that the testing release process is not capable of a release cycle on the order of 12-18 months with 11 architectures. And now two thirds of the Debian architectures should be removed from Debian releases because you still prefer a release process that has twice failed to show that it was superior to the former release process? > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On Wed, Mar 23, 2005 at 11:30:51AM -0800, Karl Chen wrote: > > On 2005-03-22 20:13 PST, Jeroen van Wolffelaar writes: > > Jeroen> I think it'd be good to ship sarge without such > Jeroen> situations, but again, this needs to be looked into on > Jeroen> a case-by-case basis, and I certainly dare not say > Jeroen> that every such case must be a bug (but I suspect so > Jeroen> in general). > > Source packages readline4 and readline5 both produce binary rlfe. > What do you think about this situation? The most recent version of the rlfe package (from readline5) is therefore available and it's not a problem. And in unstable, readline4 no longer produces a rlfe binary package. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
On Sun, Mar 27, 2005 at 03:00:07AM -0800, Steve Langasek wrote: > On Tue, Mar 15, 2005 at 01:39:27PM +0100, Peter 'p2' De Schrijver wrote: > > > | - the release architecture must have a working, tested installer > > > I hope that's obvious why. :) > > > As long as FAI or even raw debootstrap counts, I can agree here. > > No, debootstrap isn't an installer, and shouldn't be counted as such for the > purpose of release eligibility. If you have to install someone else's > operating system first to be able to install Debian, then we don't have an > installer. There *are* reasons that debian-installer has been emphasized as > much as it has during the sarge release. But isn't this a completely theoretical discussion regarding etch? Sarge contains a complete rewrite of the installer. That it missed the announced date of being completely ready on October 15th 2003 by that much time might be related to the number of architectures. But after sarge all 11 architectures have a working installer and unless the new installer is that bad that the next rewrite was scheduled for etch, I fail to see how the installer could be a major obstacle for any of the 11 sarge architectures in etch. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm
On Fri, Apr 01, 2005 at 03:48:00PM +0200, Andreas Barth wrote: >... > Major changes in etch > - > > If you intend to make major changes (like a C++ ABI bump) during the > development of etch, please speak with the release team as soon as > possible, describing the changes you're planning and why. This way, we > can help you to make your transitions as smooth as possible, ensuring > that packages go quickly into testing/etch, don't hold up other packages > or the release in general, and don't take us by surprise. We would > appreciate it if you could send these emails before the end of April > to [EMAIL PROTECTED] Is this an April Fool joke? If not, the release team should also send the information required for this: When is the estimated freeze date for etch? It doesn't need to be an exact date, but someting like "third quarter of 2005" or "mid-2008" would help to avoid situations like the sarge C++ transition that was too early [1] or the more than two years old X11 that will ship with sarge (and that doesn't support all hardware supported by recent X.org releases) [2]. And please learn from past release management mistakes and announce a _realistic_ estimated freeze date for etch [3]. >... > Keeping track of RC bugs in testing > --- > > Since BTS version tracking is a post-sarge feature, we depend on your > help to keep track of RC bugs that have been fixed in unstable but not > testing. Over the past few months, we've been tracking these bugs > mainly through the use of reopened, sarge-tagged bug reports. You can > continue to use this method to let the release team know about > release-critical issues, but we would encourage you to use > http://www.wolffelaar.nl/~sarge/ to send us comments on the > importance of particular updates waiting in testing. This applies not > just to release-critical issues (which should be marked as "critical" on > that page), but also to important ones (and "minor" ones, if you feel > inclined). For usage information about this site, please see the > previous announcement concerning it[1]. For the record: I started doing this during the last days [4]. RC bugs are IMHO better since they also show up in your RC bugs metric. > Cheers, > Andi Barth cu Adrian [1] the first birthday of gcc 3.4.0 is only a few days from now [2] the "outdated X11" problem was already present in woody where XFree86 4.2 might have been included [3] and avoid the non-working "aggressive goals" [5] [4] that's extra work only required by the usage of testing and version tracking in the BTS alone will not be sufficient to handle this - but that's a different discussion [5] http://lists.debian.org/debian-devel-announce/2003/08/msg00010.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to find out why a package was removed from testing?
On Fri, Apr 01, 2005 at 06:56:45PM -0800, Steve Langasek wrote: > On Fri, Apr 01, 2005 at 07:59:01PM +0200, Frank Küster wrote: > > Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > > > > On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote: > > > > Right, but open for 47 days already. If for this amount of days an RC > > > bug is open and nobody seems to have cared enough to fix it or even > > > provide a patch, I think it's justified hinting it out of sarge. > > > You are probably right. However, removing a package should not be done > > without > > > - adding a note about this to the release notes (Is there a package or > > pseudo-package for the release notes now? I don't think so). > > There is an upgrade-reports package, but not a release-notes package. > Perhaps upgrade-reports is good enough for the moment, since removed > packages are upgrade issues? > > Anyway, packages are removed from testing or unstable+testing all the time > when they're not releasable, without necessarily looking at whether they > were present in stable; and many of these may get back into testing before > release; so it's not really practical to track removals until we get close > to freeze (like, hmm, now). >... This still catches only part of the problem. I wouldn't assume that the majority of Debian users completely reads the release notes. Consider someone discovers a remotely exploitable hole in wwwoffle 13 months after the release of sarge. According to the Debian Popularity Contest, 1.5% of the Debian users run wwwoffle. Consider one third of them completely read the release notes and removed wwwoffle. Then one percent of all computers running Debian 3.1 will be vulnerable - and there will be no DSA warning them. You can argue "it was documented" - but the number of vulnerable Debian 3.1 machines will still make the script kiddies very happy. And wwwoffle is only one of many removed packages. > The release team doesn't remove packages from testing for reasons that don't > go through the BTS, and these are generally documented in > http://ftp-master.debian.org/testing/hints/ as noted. That's wrong. The release team does remove packages for getting library transitions into testing. If a package affected by the transition depends on a third package that is not yet ready for testing, it might be hinted for removal by the release team without any mentioning in the BTS. Consider e.g. the loop-aes-utils package would require libopenh323 [1]. You yourself would hint it for removal from testing today and it wouldn't have any chance of entering testing again for sarge [2] although it's completely bug-free. Or a package might simply be removed because it depends directly or indirectly on a buggy package without being itself buggy. > Steve Langasek cu Adrian [1] that's only a fictive example, but I'm too lame digging through 650kB update_excuses for finding some real examples [2] due to it's versioned util-linux dependency -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm
On Sat, Apr 02, 2005 at 12:35:55AM +0100, Matthew Garrett wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > It doesn't need to be an exact date, but someting like > > "third quarter of 2005" or "mid-2008" would help to avoid situations > > like the sarge C++ transition that was too early [1] or the more than > > two years old X11 that will ship with sarge (and that doesn't support > > all hardware supported by recent X.org releases) [2]. > > (snip) > > > [1] the first birthday of gcc 3.4.0 is only a few days from now > > The C++ ABI was broken with gcc 3.2.0. For most architectures, 3.4.0 > doesn't change anything. Is your point anything other than "The Debian > release process is broken and you should get rid of testing"? If not, > we've heard that several times already. It doesn't need reiterating. Where did I say that these problems had anything to do with testing? It seems you are one of the people who think "You don't like testing so everything you are saying has to be wrong.". Please check the facts: gcc 3.4 has a different C++ ABI compared to gcc 3.2/3.3 on _all_ architectures [1]. cu Adrian [1] look at libstdc++5 <-> libstdc++6 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why allow broken packages to get all the way to mirrors?
On Sun, Apr 03, 2005 at 02:26:34PM +0200, Thijs Kinkhorst wrote: > On Sun, April 3, 2005 05:39, John Hasler said: > >> For instance, let's say we are a food company. Why not check to see if > >> the food is rotten before it gets to the consumer? > > > > That's what Unstable is for. > > Why, if tests can be automated, do we have a need to go through the > process of spreading a package to mirrors, have people install it and file > bug reports by hand? (Often these reports are a day later already > out-of-date because it was just a matter of time.) Isn't one of our > strenghts that we can automate what we can so we can use our time for all > those tasks that are left? Where do fully automated bug preventing techniques really work in Debian? All places I know either require a serious amount of work to keep it running or require people regularily checking the reports (which is often not done). And note that "not installable packages" are only a small and not the worst class of bugs - and they are usually reported pretty fast. "unstable" is unstable and every user of unstable is expected to know what to do when the installation of a package fails. E.g. DSA-177-1 describes a _real_ problem - and this wouldn't have been caught. > Regards, > > Thijs Kinkhorst cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
On Mon, Apr 04, 2005 at 05:19:41PM +0200, Martin Schulze wrote: > Adrian Bunk wrote: > > The milestone that included the start of the official security support > > for sarge was only 6 days after the announcement, but is was missed by > > more than 6 months. > > > > Whyever it was expected to get testing-security for sarge that quick, it > > should have been obvious 6 days later that it wasn't possible that > > quick. > > > > What would have been a second plan? > > Use testing-proposed-updates. > > > > Using testing-proposed-updates for security fixes, users might have > > gotten security updates one or two days after the DSA on some > > architectures. > > > > Would this have been an ideal solution? > > No. > > But it would have worked without a great impact on the release date. > > No, it wouldn't, since t-p-u isn't autobuilt for all architectures > either. We would win nothing by using it without manually building > the packages on the missing architectures. Please correct me if my understanding was wrong. As far as I understood it, the situation was: t-p-u lacks autobuilders on some architectures. s-p-u required a non-trivial amount of changes in Debian-internal software. My point is: It turned out that the work to get s-p-u running requires more than half a year. If this was the _the_ show-stopper for the release, I can't believe it could take more than a few weeks for getting running autobuilders for architectures lacking autobuilders for getting t-p-u running. Then you can work around the missing s-p-u by using t-p-u. This way, you'd have reduced a delay by half a year to a delay by a few weeks. > > RC bugs - only a metric > > --- > > > > Nowadays, it seems the main metric to measure the quality of a release > > inside Debian is the RC bug count. > > > > As with any metrics, work on improving the metric might make the metric > > look much better, but doesn't at the same time imply that the overall > > quality improved that much. > > > > > > An example: > > > > A major problem in Debian are MIA developers. > > > > Consider a MUA maintained by a MIA developer with the following bugs: > > - #1 missing build dependency (RC) > > - #2 MUA segfaults twice a day (not RC) > > These are fixed during BSPs, so no problem to spend more time on. Unfortunately not. BSPs tend to focus on RC bugs and the success is often measured only in the RC bugs metric. Quoting what I already said in a different email in this thread: The first example that comes into my mind is the info package where the two NMUs didn't fix the many open segfault bugs (e.g. #259561 contained a trivial patch ACK'ed by upstream being one and a half months in the BTS before the latest NMU - note that this NMU was even done by a Release Assistant). This shouldn't be a personal offense against the person who did this particular NMU - it's simply the first example coming into my mind. >... > > Dump testing? > > - > > > > It seems noone asks the following question: > > Testing - is it worth it? > > As a preparation for stable and an interim "solution" between stable > and unstable it's quite well. > > > Several people have stated that with the size of Debian today, it > > wasn't possible to manage a release without testing with a "traditional" > > freeze (unstable will be frozen at a date, announced several months > > before), and that only testing makes releasing possible. > > I believe that it helps a lot to get and keep the software in proper > shape for a release with all supported architectures and depending > packages. Testing has it's advantages. There's always some manual work required for keeping testing running. And the complete release team signed the announcement stating that the testing release process is not capable of release cycles in the order of 12-18 months with 11 architectures. Are the advantages of the testing release process worth both the extra work and dropping two thirds of the Debian architectures from releases? >... > > testing was expected to make shorter freezes possible. > > Neither the woody nor the sarge freeze support this claim. > > This might not only be the fault of testing, but the positive effects of > > testing (if any) aren't visible. > > Hmm, we're not waiting for testing to freeze but we're waiting for > missing infrastructure to be implemented. Or am I mistaken? I don't know more than you. My point is: If there are areas where the testing release p
Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm
On Tue, Apr 05, 2005 at 04:15:40PM +0200, Andreas Barth wrote: > * Adrian Bunk ([EMAIL PROTECTED]) [050401 23:35]: > > On Fri, Apr 01, 2005 at 03:48:00PM +0200, Andreas Barth wrote: > > >... > > > Major changes in etch > > > - > > > > > > If you intend to make major changes (like a C++ ABI bump) during the > > > development of etch, please speak with the release team as soon as > > > possible, describing the changes you're planning and why. This way, we > > > can help you to make your transitions as smooth as possible, ensuring > > > that packages go quickly into testing/etch, don't hold up other packages > > > or the release in general, and don't take us by surprise. We would > > > appreciate it if you could send these emails before the end of April > > > to [EMAIL PROTECTED] > > > If not, the release team should also send the information required for > > this: > > > > When is the estimated freeze date for etch? > > As written by Steve on d-d-a recently: We plan 12-18 months for etch. Why do you need to know about all transitions this month if Debian 3.2 is scheduled for the end of 2006 or 2007? Can't this in the case of e.g. the C++ ABI bump cause the same problems as with Debian 3.1 that you transition too early and might have with the same amount of work done an even bigger ABI bump? > Cheers, > Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm
On Wed, Apr 06, 2005 at 01:17:54AM +0200, Wouter Verhelst wrote: > On Tue, Apr 05, 2005 at 04:52:29PM +0200, Adrian Bunk wrote: > > Why do you need to know about all transitions this month if Debian 3.2 > > is scheduled for the end of 2006 or 2007? > > ... so that the release team can plan ahead a bit? It's funny that the release team needs to know about transitions for etch that might occur in 2006 now, while even the freeze date for sarge isn't yet announced. Why are the people who want information that much in advance the same people that announce freeze dates 6 days before the start of the freeze? A _realistic_ [1] sarge timeline announced _in time_ [2] was IMHO of much higher value than planning post-sarge transitions. cu Adrian [1] no "aggressive goals" and double-checked that all release milestones are achievable [2] so that Debian maintainers know before the upload when low urgency uploads will have no chance of getting into sarge -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CVSNT package
On Thu, Apr 07, 2005 at 09:21:06PM +0200, Christian BAYLE wrote: > Hi all Hi Christian, > I've found on www.cvsnt.org > a NT ported version of CVS with some nice extra features > http://www.cvsnt.com/cvspro/compare.htm like ssl, acl > > I downloaded at http://www.cvsnt.org/wiki/Download and > It looks like you were packaging/NMUing this in the past > I can't find any reference in BTS about this, > Any idea why this is out of debian now? > The package is quite outdated, but I have it a little bit better now. >... the debian/changelog is the one of the Debian cvs package up to 1.11.1p1-5 plus one additional cvsnt entry at the top. It doesn't seem cvsnt itself was ever part of Debian. > Christian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
All GPL'ed programs have to go to non-free
The following might sound absurd, but it seems to follow directly from Debian's current interpretation of the DFSG: All GPL'ed programs have to go to non-free. Proof: You are only allowed to distribute verbatim copies of the GPL license text. In Debian, documents are considered software and are therefore subject to the DFSG. Debian does not plan any exceptions from the DFSG for RFCs, license texts or any other documentation. Debian will therefore have to move all GPL license texts to non-free. Section 1 of the GPL requires Debian to give every recipient of a GPL'ed work a copy of the GPL. Therefore, all GPL'd programs will have to go to non-free. Q.E.D. Is this a correct interpretation of what will happen after the release of sarge or is there any mistake in my proof? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote: >... > The progression I see is: > > unstable -> testing -> candidate -> stable > > The existing rules for promotion from unstable to testing continue to be > used. > > Promotion from testing to candidate requires meeting the same rules as > promotion from unstable to testing with the following exceptions: > packages must be in testing for at least 3 months, and have no release > critical bugs. >... One big problem testing has are transitions. This includes library transitions, but also other transitions like e.g. an ocaml transition affecting several dozen packages currently waiting to enter testing. Many transitions require a serious amount of manual coordination since all packages have to be ready to go into testing _at the same time_. Please explain how you think any bigger transition can ever enter your "candidate" if you add to the testing criteria a "3 months" criteria all affected packages have to fulfill at the same time? > Pat cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Thu, Apr 14, 2005 at 10:31:47PM -0400, Glenn Maynard wrote: > On Thu, Apr 14, 2005 at 08:08:18PM -0400, sean finney wrote: > > On Thu, Apr 14, 2005 at 11:47:26PM +0200, Adrian Bunk wrote: > > > Therefore, all GPL'd programs will have to go to non-free. > > > > there's nothing that prevents us from re-distributing modified copies > > of the GPL, we just can't do so and claim that they are the GPL. even > > if you did want to nitpick that (why?), such a restriction is acceptable > > according to the DFSG. for example, many authors choose to license > > their software under a 'modified GPL' or 'GPL-with-some-exceptions'. > > Er, no. The GPL can only be modified if the preamble is removed, which > means the preamble is an invariant section. The *only* reason the > text of the GPL is allowed in main is because including license texts > is a fundamental, unavoidable requirement of distributing software at > all, unless one limits oneself to public domain works. I'd also say that for a user, access to documentation is an unavoidable requirement for using the software (e.g. for most non-trivial uses it will be a pain to work with a gcc without any documentation of the available options - and even Debian developers will have to use the GFDL'ed documentation as part of their Debian work). That doesn't stop Debian from removing the documentation. > Adrian, you're deliberately wasting the project's time with a very old, > eternity-since-debunked "argument". That's known as "trolling". Unless > you have something of value to say, go away. If you call me a "troll", please tell me where this is documented. I have done: - read the last two months of debian-devel - read the draft "FAQ on documentation licensing" currently discussed on debian-legal I assume it's not expected to read the complete 10 years of debian-devel before being allowed to send an email to debian-devel. If you can point me to some document I should have found that explains Debians position on this issue I do hereby apologize in advance for wasting bandwith with this thread. If there isn't one, I await your apologize for calling me a troll. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 02:22:11PM +0100, Matthew Garrett wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > I'd also say that for a user, access to documentation is an unavoidable > > requirement for using the software (e.g. for most non-trivial uses it > > will be a pain to work with a gcc without any documentation of the > > available options - and even Debian developers will have to use the > > GFDL'ed documentation as part of their Debian work). > > The fact that we can remove the documentation and still distribute the > software demonstrates that it isn't an unavoidable requirement. The question remains whether a gcc or MySQL without documentation is of any practical value. In theory, your users are of equal priority for you as free software. In theory, you don't want to make the system depend on an item of non-free software In practice, you are making parts of Debian unusable without the documentation in non-free (which is according to your definition software) forcing users of Debian to use non-free. Until recently, non-free contained only some obscure things most people didn't require. It's funny that moving much documentation to non-free will force many users to add non-free to their sources.list ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 05:30:15PM +0200, Jacobo Tarrio wrote: > > > Adrian, you're deliberately wasting the project's time with a very old, > > > eternity-since-debunked "argument". That's known as "trolling". Unless > > > you have something of value to say, go away. > > If you call me a "troll", please tell me where this is documented. > > http://lists.debian.org/debian-project/2005/01/msg00062.html > > This is Message-id: <[EMAIL PROTECTED]> in case the > URL changes. I understood from Glenn's email that this was already discussed at some time somewhere. If I should have been able to find this specific email as an official statement of Debian, where is the link from some locations at www.debian.org (or a similar place) to it? If you call people who don't know about it a troll you should ensure that it's documented at the places where you'd expect to read it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 09:26:30PM +0200, Wouter Verhelst wrote: > On Thu, Apr 14, 2005 at 06:46:41PM -0500, John Hasler wrote: > > Matthew Garrett writes: > > > In general, the law doesn't allow us to modify the license attached to a > > > piece of software. > > > > That has nothing to do with creating a derivative of a license for use > > elsewhere. > > You are allowed to do that with the GPL, under certain conditions[1]: > > * You must not call it 'GNU GPL', and you must modify the > instructions-for-use at the end so that they don't mention GNU. > * You must remove the preamble. > > The former is already allowed by the DFSG (section four). The DFSG > doesn't talk about bits that must be stripped from software if you want > to make a modified version, but it's not even remotely the same thing as > having an invariant section that cannot either be removed or modified. > > Of course, you cannot modify the GPL and then assume that original > authors will accept your license; that is the only way in which the GPL > isn't modifiable. But that isn't a problem, is it? > > [1] http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCModifyGPL That's interesting. IOW: Different from what both I and several other people in this thread stated, the GPL is DFSG-free? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 09:33:00PM +0200, Wouter Verhelst wrote: > On Fri, Apr 15, 2005 at 03:44:04PM +0200, Adrian Bunk wrote: > > The question remains whether a gcc or MySQL without documentation is of > > any practical value. > > There are MySQL documentation packages? Or at least, there have been? Yes, the mysql-doc package contains the not DFSG free documentation from www.mysql.com . > Cool. Didn't know that. Then again, I've only been using MySQL since a > few years, so maybe it's normal that I didn't know. Which documentation did you use? If you say "none ever" you won. But if you used non-free documentation (in digital or printed form) imagine you wouldn't have been able to use any of this documentation. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 11:58:52AM -0400, Hubert Chan wrote: >... > In fact, I've never looked at the gcc documentation other than to look > up machine-specific options and optimization flags. It's easy to use > gcc without the documentation. Simple usage might work, but as soon as you reach any question like e.g. How do I pass in a additional path to the include path of gcc? Which optimization levels does gcc support? Which optimization option is best for my CPU? you are pretty lost without the documentation. >... > Adrian> Until recently, non-free contained only some obscure things most > Adrian> people didn't require. ... > > Such as a graphical web browser, back in the time before mozilla existed > or was usable. Or acroread (before the security vulnerability, when it > was decided to just drop it from the archive altogether), or the Flash > plugin (well, it's in contrib, but only because it downloads the actual > plugin from the web) or msttcorefonts (also in contrib, for the same > reason as the Flash plugin). Or giflib. Those are all obscure things. >... My point is: Non-free was going to contain mostly obscure things now that there are free replacements for Netscape and Acroread. Debian's steps of moving more and more things into non-free forces many users to use non-free who wouldn't do otherwise. Is this effect really wanted? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 07:17:08PM -0400, Glenn Maynard wrote: > On Sat, Apr 16, 2005 at 12:05:42AM +0200, Adrian Bunk wrote: > > If you call people who don't know about it a troll you should ensure > > that it's documented at the places where you'd expect to read it. > > I call anyone who starts a thread on debian-devel with the subject: > > "All GPL'ed programs have to go to non-free" > > a troll. I believe this is self-evident to everyone reading this > thread, so I don't feel obligated to explain myself further. I have to admit that the subject of my email lacked the question mark that was at the end of the email and that should have been at the end of the Subject, too. Is one missing question mark enough for being publically called a troll? I explained where I searched for the information, and I offered to you: <-- snip --> If you can point me to some document I should have found that explains Debians position on this issue I do hereby apologize in advance for wasting bandwith with this thread. <-- snip --> Please tell me where the document is I should have found that explains Debian's position on this issue and then you have my publically stated apology for starting this thread. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What do you win by moving things to non-free?
On Sat, Apr 16, 2005 at 09:07:58AM +1000, Matthew Palmer wrote: > On Sat, Apr 16, 2005 at 12:18:45AM +0200, Adrian Bunk wrote: > > On Fri, Apr 15, 2005 at 09:33:00PM +0200, Wouter Verhelst wrote: > > > Cool. Didn't know that. Then again, I've only been using MySQL since a > > > few years, so maybe it's normal that I didn't know. > > > > Which documentation did you use? > > > > If you say "none ever" you won. > > > > But if you used non-free documentation (in digital or printed form) > > imagine you wouldn't have been able to use any of this documentation. > > Probably not so lovely. But why can people only use documentation if it's > in Debian main? I've been getting along fine only using the non-free MySQL > manuals for quite some time: my brain has not exploded, and my wang hasn't > shrivelled up. If you have a point, I think you may need to make it more > obvious what it is, because I'm totally failing to see what it is in your > messages. Let me try to explain it: We agree that there's several software where not DFSG-free documentation [1] is required for many usages of the software. If I e.g. want to know what gcc option is best for my CPU, I'd currently use a "man gcc" or "info gcc". Currently, this works and this documentation is shipped with gcc. But post-sarge this documentation will move to non-free. Unless I want to search and use the upstream documentation locations of every affected software I use, I have to add non-free to my sources.list and take care that I install the now separate documentation packages for all software I use. The second point might only be a minor nuisance for me, but the first one will tell me that Debian would be much less usable if I wouldn't use non-free. Is this wanted? Now that there are usable free alternatives for Netscape and Acroread the need for users to use non-free was more and more decreasing. With the documentation and even more the firmware issues [2] you force users to use non-free and force distributors to ship both a Debian installer that includes non-free parts and an extra CD containing parts of non-free or Debian will be much less usable or even uninstallable for many users. There are three main points: The Debian Social Contract sets users as a priority equally to free software. I don't see in this discussions about "nearly DFSG-free" [3] things the requirements of your users discussed. Even if the goal is clear, there might be better ways than the "remove this and that today and care about the users later" that is currently done. And teaching people that in many cases non-free is a required component for them doesn't help free software. Today, you can tell a user that it's bad to install the binary-only nvidia drivers because they are in non-free - but if this user has already had to install the drivers for his network card and his SCSI adapter from non-free, the nvidia drivers will seem to be only one more package from non-free and the user will already have learned that it's quite common that important things are in non-free. Debian had a good reputation for caring about licence issues. Qt becoming GPL-licenced is one example where the Debian position had some influence on improvements. If Debian continues to get much "Debian anyway considers everything non-free" reputation for being more fundamentalistic than even RMS, less external people will seriously consider comments of Debian on licence problems. What do you win by moving things to non-free? > - Matt cu Adrian [1] digitally or printed [2] one funny thing about the firmware issue is that although Debian developers have spent many MB of emails on this issue, it still takes only five minutes to find a dozen firmware images still present in the kernel sources shipped today in both sarge and sid... [3] "nearly DFSG-free": this is not about Acroread or the nvidia modules that are obviously not DFSG-free - but e.g. a document with a small invariant section is not that far away from the DFSG -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 09:22:48PM -0400, Glenn Maynard wrote: > On Sat, Apr 16, 2005 at 02:51:32AM +0200, Adrian Bunk wrote: >... > > Please tell me where the document is I should have found that explains > > Debian's position on this issue and then you have my publically stated > > apology for starting this thread. > > http://lists.debian.org/debian-legal/2001/11/msg9.html footnote [1] > http://lists.debian.org/debian-devel/2004/05/msg00448.html > http://lists.debian.org/debian-project/2005/01/msg00059.html Two of these are by you and the third one explicitely states that the email only contains the personal opinion of the sender. Where's the official statement of Debian on this issue? www.debian.org tells me why mplayer can't be packaged - where does it tell me what Debian calls "software"? > And note that this isn't specific to the GPL, but common to all copyrighted > software that requires that the license text itself accompany the work. This > includes every free license I've seen in use, including the 2-clause BSD > license and the X11 license. > > FYI, I found the above via google: site:lists.debian.org "license texts" The only hit for site:www.debian.org "license texts" brings me to a debian-legal discussion where your new DPL suggests that the GFDL should be considered DFSG-free and invariant sections of up to 5% should be considered DFSG-free. It seems the opinions in Debian about the GFDL have changed during the last four years... > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you win by moving things to non-free?
On Fri, Apr 15, 2005 at 10:35:36PM -0400, Glenn Maynard wrote: >... > > What do you win by moving things to non-free? > > You inform people that what they're using is not Free. That's a fundamental > purpose of non-free: to be able to make some important but non-free pieces > available to users, while allowing users to know that some of the stuff > they're using is non-free, if they care. > > You present some incredibly strange arguments: you're not arguing that the > gcc manual is Free, but instead, apparently, saying "we shouldn't move non- I'd personally consider the gcc manual being free. But I'm attacking another point in the chain: Is the effect of what you are doing really in the spirit behind it or is it counter-productive? > free stuff to non-free because it teaches people that they need non-free > things". Here's a tip: it's a *good thing* to teach people that they > still need non-free things, if it's the truth; it just might inspire > people to create free versions, or convince the FSF to free up their works. > That's a fundamental reason for separating non-free, and that's never changed. What is the impression of the people you try to teach something to? First of all note that the vast majority of Debian users did choose Debian for technical reasons like the stability of stable or the working upgrades. If a system administrator has to choose between e.g. Gentoo and Debian, the percentage of system administrators who understand or want to understand the differences between the "free software" definitions of the two projects will be negligible - the decision will be based on technical reasons and personal preferences. Even further many Debian installations are used as a basis for non-free software - which is a configuration Debian has promised to support. As an example, 14 000 computers in the administration of my home town will soon be based on Debian. This project will be a success for both the companies who got the contract and the overall public reputation of Linux and Debian if the resulting solution will be able to completely replace the current Microsoft-based solution. If the resulting solution will fail, this will be a major drawback in the public reputation of Linux. I doubt anyone will care how many percent of this solution will be DFSG-free. The point when you can teach people about non-free comes later: One day, a system administrator using Debian asks: Why is $foo in non-free? Case 1: foo = nvidia binary modules Answer: Because these modules are binary-nonly and therefore undebuggable for everyone except Nvidia. They give you a much better 3D performance, but they sometimes lead to kernel crashes. Case 2: foo = some documentation Answer: Because the document contains a invariant section in which the author says he dedicates this manual to his dead father. In the first case you might have convinced a system administrator that non-free software has serious disadvantages. In the second case you'll hear a loud laugher. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you win by moving things to non-free?
On Fri, Apr 15, 2005 at 11:15:29PM -0400, Glenn Maynard wrote: > On Sat, Apr 16, 2005 at 04:29:42AM +0200, Bernd Eckenfels wrote: > > In article <[EMAIL PROTECTED]> you wrote: > > > Is this wanted? > > > > This may not be wanted, but what is your alternative? > > Well, it's not that we don't want gcc's documentation to be moved to > non-free; rather, we don't want gcc's documentation to *be* non-free. > The moving to non-free is just a side-effect; Adrian seems to be > saying that we should eliminate the side-effect and ignore the core > problem. What is the "core problem"? Are the differences between the FSF and Debian regarding issues like invariant sections in Debian really the core problem? Or are things like hardware with binary-only drivers and without specifications or software patents more important problems? As I tried to express in the "system administrator" example in the email I sent a few minutes ago, I'm sure nearly everyone outside the inner circle of the free software world will consider the whole GFDL discussion as being absurd. In the Qt/GPL case Debian was at least able to argue that it would otherwise break laws which convinces many people. And if the FSF doesn't want to change the GFDL in a way that Debian wants I doubt moving GFDL'ed documentation to non-free will put much pressure on them. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you win by moving things to non-free?
On Sat, Apr 16, 2005 at 12:31:23AM -0400, Glenn Maynard wrote: > On Sat, Apr 16, 2005 at 05:54:08AM +0200, Adrian Bunk wrote: >... > > Case 1: foo = nvidia binary modules > > Answer: Because these modules are binary-nonly and therefore > > undebuggable for everyone except Nvidia. They give you a > > much better 3D performance, but they sometimes lead to > > kernel crashes. > > > > Case 2: foo = some documentation > > Answer: Because the document contains a invariant section in which > > the author says he dedicates this manual to his dead father. > > > > > > > > In the first case you might have convinced a system administrator that > > non-free software has serious disadvantages. > > > > In the second case you'll hear a loud laugher. > > Maybe, since you conspicuously omitted the "and therefore" part in > case 2; the practical problems with invariant sections have been well > explored. (I'm not going to waste my time digging up discussions about > them for you, since you'll just complain that they're not an "official > position statement". Find them yourself.) It's not about a "and therefore" in the text I wrote. You missed my main point: Most people can't be convinced by reading a statement what Debian considers free and what not. But they can be convinced by technical arguments why free software is superior. You can convince people that non-free software is bad if you explain stability problems with the nvidia binary modules or the reason why majordomo was removed from non-free to them. The invariant section issues are things you can discuss inside Debian or with me or with the FSF. But for nearly everyone else the result if you explain the GFDL problem will be that he thinks that the differences between free and non-free software are pretty small. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Fri, Apr 15, 2005 at 04:45:17PM -0400, Patrick Ouellette wrote: > On Thu, Apr 14, 2005 at 11:59:52PM +0200, Adrian Bunk wrote: > > > > On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote: > > >... > > > The progression I see is: > > > > > > unstable -> testing -> candidate -> stable > > > > > > The existing rules for promotion from unstable to testing continue to be > > > used. > > > > > > Promotion from testing to candidate requires meeting the same rules as > > > promotion from unstable to testing with the following exceptions: > > > packages must be in testing for at least 3 months, and have no release > > > critical bugs. > > >... > > > > One big problem testing has are transitions. This includes library > > transitions, but also other transitions like e.g. an ocaml transition > > affecting several dozen packages currently waiting to enter testing. > > > > Many transitions require a serious amount of manual coordination since > > all packages have to be ready to go into testing _at the same time_. > > > > Please explain how you think any bigger transition can ever enter your > > "candidate" if you add to the testing criteria a "3 months" criteria all > > affected packages have to fulfill at the same time? > > > > The system should always be considered a FIFO system. There are only 2 > places packages can enter the system: unstable, and security-updates. > The coordination of dependent packages will always require manual > coordination. There is no way around it (unless you completely automate > the build process so it downloads the upstream tar ball and packages it > for Debian - and never breaks). The purpose of unstable is to allow > those problems to be worked out. Once the group of interdependent > packages is ready (managed to live in unstable for 10 days without a > release critical bug) then they will all meet the criteria set to be > promoted to testing. The same thing happens again. Once the entire > group satisfies the conditions, the entire group migrates to candidate. > The point of having the promotion conditions is to make sure the system > is not broken, and can handle library or interdependent package version > changes. The rules I referred to are found here: > http://www.debian.org/devel/testing The rules and goals of testing are clear. The more interesting points are the problems of testing that several years of using it have shown. > If package FOO has a RC bug, then everything that depends on FOO will be > stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed. If > fixing FOO breaks BAR, then they all wait again until BAR is fixed. Use > of experimental to work through some of these issues would help. > I'm not saying it won't take manual coordination to handle complex > changes to the system. I'm not saying it will make anyone's life > easier. What my proposal will do is provide the ability to decide when > package $PACKAGE makes it into stable, we will call that an official > release and give it a number. Alternatively, you could declare every > $INTERVAL Debian releases. What is in stable should have been well > tested, and supportable. Stable no longer is a static concept, but a > slowly evolving thing. If you cannot wrap your mind around to accepting > a stable that evolves, we could snapshot stable at release data and make > a separate archive (really a Packages.gz and related files as long as > the version of the package in the release exists in the package pool). You completely miss my point: There are several transitions every month, and a big transition can involve several hundred packets. Your proposal requires, that _every single_ package that is part of a transition has to be both ready and in testing for over 3 months before it can enter your proposed "candidate". If _one_ of the packages that is part of a transition is updated in testing during this time, the 3 months start again. For bigger transitions, it's therefore practically impossible that they will be able to enter your "candidate". Please try to understand the limitations of testing before proposing something even stricter. > Pat cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Fri, Apr 15, 2005 at 11:13:04PM -0400, Glenn Maynard wrote: >... > This makes it extremely clear that, as far as the Social Contract is > concerned, everything in Debian is software, covered by the DFSG. This > is a discussion that's done and complete, settled by GR2004-003, and > I'm not interested in rehashing those discussions yet again. > > (It's disappointing that on one hand, we have people insisting that > every decision should go through a complete GR to involve the whole > Project and refuse to accept any amount of consensus otherwise; while > on the other hand, the few issues--such as this one--that actually do > go through a GR and are firmly decided *still* come under debate again > and again.) >... I've heard three different stories describing this GR: 1. it contained only Editorial amendments and didn't change anything 2. the Debian developers decided in this GR that documentation has to fulfill the full DFSG guidelines 3. many Debian mistakenly agreed with it because they mistakenly beliefed after reading the title that it only contained editorial and no actual changes You claim that through this GR it was "firmly decided". If this was true, please give a good explanation WTF a GR that causes big changes was titled "Editorial amendments to the social contract" instead of "Debian will treat everything as software". > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you win by moving things to non-free?
On Sat, Apr 16, 2005 at 04:29:42AM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Is this wanted? > > This may not be wanted, but what is your alternative? If you really want to retain your "everything is software" point of view, think about the consequences and work on them _before_ starting the removals - and provide solutions for them that are available at the time of the removals. Actions mentioned in this thread like autobuilding parts of non-free, providing an installer that includes parts of non-free [1] and providing a CD with the distributable part of non-free are prerequisites if your users are still a priority for you. > Greetings > Bernd cu Adrian [1] that includes hardware drivers you are removing from the kernel sources -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Tue, Apr 19, 2005 at 11:52:19PM -0400, Glenn Maynard wrote: > On Wed, Apr 20, 2005 at 05:06:16AM +0200, Adrian Bunk wrote: > > I've heard three different stories describing this GR: > > 1. it contained only Editorial amendments and didn't change anything > > 2. the Debian developers decided in this GR that documentation has to > >fulfill the full DFSG guidelines > > 3. many Debian mistakenly agreed with it because they mistakenly > >beliefed after reading the title that it only contained editorial > >and no actual changes > > The SC, prior to GR2004-003, already required that documentation be > DFSG-free. I've never seen any strong argument otherwise, and > GR2004-003 simply made it explicitly clear. (GR2004-004 didn't make > any sense at all, nor does it make any sense that Sarge can ship > with non-free documentation, and at the time I found the posts of > the RM on the topic to make no sense at all, but I was satisfied with > the results of GR2004-003 and am able to bear the strangeness of > GR2004-004 for now, since it'll expire on its own.) >... If it contained only editorial changes as you are saying, you've thereby proven that your statement the documentation licencing was "firmly decided" was wrong. > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Tue, Apr 19, 2005 at 11:52:19PM -0400, Glenn Maynard wrote: >... > (GR2004-004 didn't make > any sense at all, nor does it make any sense that Sarge can ship > with non-free documentation, and at the time I found the posts of > the RM on the topic to make no sense at all, but I was satisfied with > the results of GR2004-003 and am able to bear the strangeness of > GR2004-004 for now, since it'll expire on its own.) > > (And if people really are voting for a GR after only reading the title, > I'd be even more disappointed, but I just don't believe that.) It's funny that out of the five people seconding GR2004-003, the first three did either second or even propose one of the first two suggestions in GR2004-004. If even the Debian developers seconding a GR are supporting changes to the result of this GR only one month later... > In any event, all of this is irrelevant: if people really think that > non-free documentation should be allowed in Debian, propose a GR to > allow it. Nothing short of that will make it so. If people really > think they were "tricked", fine--fix it with another GR. Unless and > until that happens, Debian's position is very clear. In GR2004-004, Proposal D to revert GR2004-003 did get a 2.3:1 majority by the developers over the proposal to keep the changes of GR2004-003. That's a pretty clear statement. The nice thing about 3:1 majorities is, that once you've tricked something as "Editorial amendments" into it, a 25% minority is enough to block reverting it... > Glenn Maynard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Wed, Apr 20, 2005 at 01:22:06AM -0400, Glenn Maynard wrote:
> On Wed, Apr 20, 2005 at 06:24:51AM +0200, Adrian Bunk wrote:
> > The nice thing about 3:1 majorities is, that once you've tricked
> > something as "Editorial amendments" into it, a 25% minority is enough to
> > block reverting it...
>
> Nobody was "tricked". I believe this claim so laughable, and at the
> same time so insulting to Debian Developers ("we forgot to read what
> we voted for! I want a do-over!"), that I don't feel inclined to argue
> it further. Again, the SC is crystal clear; again, only a GR will
> change that.
>
> My belief, from experience of many discussions on these topics on these
> lists, is that a huge majority of Debian Developers agree that documentation
> must follow the DFSG, that a fringe minority who want GNU documentation in
> Debian at any and all cost are making ludicrous claims, and that nobody is
> falling for them. I'm willing to continue arguments pertaining to the GFDL,
> but these "we didn't *really* want to require documentation to be free"
> arguments are going nowhere and are a waste of time, so I'm dropping them.
Only one month after GR2004-003, a two third majority of the Debian
developers preferred in GR2004-004 reverting GR2004-003 over keeping the
changes of GR2004-003.
You do believe that two thirds are a "fringe minority" and less than one
third is "a huge majority"?
After the whole GR2004-003 mess it's hard to say what the majority of
Debian developers really wants.
> Glenn Maynard
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Wed, Apr 20, 2005 at 09:39:23AM -0400, Daniel Burrows wrote: > > Adrian, > > I believe that you are misrepresenting the outcome of -004. The proposal > to > postpone the changes till after the release, then reinstate them, defeated > option D (rescind -003) by a 2:1 majority. The only options I can see that > D defeated by a 2.3:1 majority are option F (do nothing at all) and Further > Discussion, which all the voters had been told would result in a further > delay of the Sarge release. A 2.3:1 majority preferred option D to revert -003 over option F to reaffirm -003. Rereading the results, I get your point about option B compared to D, making the whole issue even more mysterious. Could anyone give a definitive answer to the following questions: - Did -003 contain real changes [1] or didn't it change anything? - How is it possible to happen that only a small amount of the Debian developers (less than one out of four) participates in a GR vote, the consequences of this GR do not become widely known until after the GR, and one month later, corrections to this GR are widely accepted? - If -003 changed anything, were there Debian developers who mistakenly agreed to -003 because of it's obfuscated "Editorial amendments" title? If the intention of GRs was to express the opinion of the Debian developers, the whole -003 and -004 mess seems to be a way how to not do it. > Daniel cu Adrian [1] as stated in the accepted option B of -004 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Wed, Apr 20, 2005 at 02:06:12PM -0700, Jeff Carr wrote: > Adam M wrote: > > >Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01, > >2005-01-02, etc..? > > Because redhat makes money selling releases. > > > The releases are there to provide interface stability. Everyone does > this. > > Everyone being other distributions? I disagree. How many Fortune 500 > customers have you deployed debian for? interface stablility? Anyone > that cares looks at packages that matter specifically if it's being > deployed commercially. > > It's much better for acceptance that you don't have to have > conversations with managers because someone explains to them that you > should be using redhat because you are using "Debian unstable" or > "Debian testing" and it's *dangerous* and *unstable*. Get rid of these > stupid symlinks; debian sid's been superior to fedora for years. There are at least three different comparisons: Debian sid is comparable to e.g. RedHat Fedora or Gentoo (which of these three is best is a different discussion). Debian sid is for experienced computer users who always want the latest software and who can live with a bug here or there. Debian stable is comparable to personal editions of other distributions like e.g. SuSE Professional. These distributions are for users with few experience who simply want a running system. Debian is a bit behind in terms of being up-to-date and of userfriendlyness, but it's far superior in it's stability. Debian stable is comparable to the enterprise products of e.g. RedHat or SuSE. These distributions are usually installed on servers that are installed and intensively tested once. Security fixes are a must but mustn't cause any breakages. Updates to new upstream versions which might break something Note that you can't cover the last use case without a long-living and non-changing stable. > >Now, if you want to support snapshot of Debian with 36 month security, > >well, be my guest :) In the last 36-months, there were about 30 > >uploads of Apache to unstable. > > Excellent. > > > Now, if only 15 such versions > >propagated to stable snapshots, then you find a remote hole, and > >suddenly you have to backport a security fix for 15 versions of > >Apache! > > What? > > Isn't the process: > > 1) make a patch > 2) give it to the apache developers > 3) new packaged apache versions have the patch > 4) patch makes it upstream > 5) patch no longer needed in debian package Look at the third use case I explained above. For these users of Debian, long-living releases where the _only_ changes are security fixes are _very_ important. >... > >In many ways, current testing is your stable. > > No kidding, so what the heck is the point of having a stable symlink to > woody. The stable, testing and unstable symlinks should be removed. They > are just being used as FUD by people against debian. They are not (see above). > >Extending the testing period from testing to your proposed candidate > >and then stable would do nothing about normals bugs. RC bugs are > >usually found quite quickly by people using unstable. > > Why not let people choose what they want to use "woody" "sarge" or "sid" > and never change the names again. I think lots of people are happy with > how things work now. No need to ever do a release again. Just remove the > old/arcane symlinks. Almost everyone I know uses sid; I don't think > anyone is going to switch to sarge once sid is out. See above. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Wed, Apr 20, 2005 at 03:18:52PM -0700, Jeff Carr wrote: > Adrian Bunk wrote: >... > >Debian stable is comparable to the enterprise products of e.g. RedHat or > >SuSE. > > > >These distributions are usually installed on servers that are installed > >and intensively tested once. Security fixes are a must but mustn't cause > >any breakages. Updates to new upstream versions which might break > >something > > Well, that is wishful thinking, but I've deployed debian sid against RH > enterprise and commercial dists. Sometimes sid, sometimes sarge. It > really depends on the customer and the competance of their staff. > > In any case, you are thinking wishfully here and I'm not sure you have > deployed debian to large clients. The primary problem is the poor > impression that: > > woody == stable == old > sarge/sid == testing/unstable == broken == pain == my servers crash > > >Note that you can't cover the last use case without a long-living and > >non-changing stable. > > I think the debian community would be better served if never again the > words "stable" were tied to a particular release. > > How can you really say woody is any more "stable" than sid anyway? There > are things so broken in the old versions of packages in woody that they > can not be used anymore in a modern enviornment. Sure, it might be > stable in the sense that it doesn't crash, but useless vs stable is > undesirable. Having woody == stable is giving the false impression to > people that don't know better that: > > debian stable == old == obsolete == something is wrong with this picture > > It just makes it hard to build confidence with decision makers that > sid/sarge is safe to use over RHEL. >... Let my try to explain it: The "debian stable == obsolete" is a release management problem of Debian. One release every year and it would be suitable for most purposes. You say you've deployed Debian sarge and sid in server environments (even sarge, although months old security fixes might be missing???). Let me ask some questions: - How many thousand people can't continue working if the server isn't available? - How many million dollar does the customer lose every day the server is not available? - How many days without this server does it take until the company is bankrupt? If the mail server of a small company isn't running for a few hours it's not a problem - but there are also other environments. Regarding things broken in woody: In many environments, the important number is not the total number of bugs but the number of regressions. Doing intensive tests once when you install/upgrade the machine is acceptable, but requiring this every month because it's required for the security updates that bring new upstream releases is not acceptable. > >Look at the third use case I explained above. For these users of Debian, > >long-living releases where the _only_ changes are security fixes are > >_very_ important. > > Again, I don't think you ever built a commercial product around Linux > based on your statements here. No offence if you have, maybe it's just > corporate culture differences between the EU and US? There are reasons why companies pay several thousand dollars licence fees for every computer they run the enterprise version of some distribution on. E.g. RedHat supports each version of their enterprice edition for seven years. A few thousand dollars are _nothing_ compared to the support costs and man months that have to be put into setting up and testing the system. And I doubt these are only corporate culture differences between the EU and US: How many days does it take in the US until a bank is bankrupt after a critical part of their computer infrastructure is broken? > >>No kidding, so what the heck is the point of having a stable symlink to > >>woody. The stable, testing and unstable symlinks should be removed. They > >>are just being used as FUD by people against debian. > > > >They are not (see above). > > I think I explained poorly what I meant by FUD. What I meant was that > people that want other distributions to be used, use the FUD that sarge > is "dangerous" and the only "stable" version of debian is ancient and > too old to use. I'd say both is not FUD - it's true. Debian stable is ancient - but that's something you have to ask the Debian release management about. If the officially announced release date for sarge is now missed by more than one and a half years this is the issue where investigation should take place. Regarding sarge: I do personally know people who had serious mail l
Re: Temporal Release Strategy
On Wed, Apr 20, 2005 at 04:23:02PM -0700, Jeff Carr wrote: > Adrian Bunk wrote: > > >Let me ask some questions: > >- How many thousand people can't continue working if the server isn't > > available? > >- How many million dollar does the customer lose every day the server is > > not available? > >- How many days without this server does it take until the company is > > bankrupt? > > These are interesting questions, but not really applicable. I've never > seen a corporate enviornment where an upstream or outside distribution > is deployed without being tested internally first. I don't think it's > something that should be taken into account in the release process. > Companies have internal methods for deployment that double check and > verify a distribution before it is used. >... Yes, such companies do test all changes. But being sure that it's _very_ unlikely that a security update breaks something makes life much easier. And then there's the class of problems you could recently observe with PHP 4.3.10: PHP 4.3.10 fixed more than half a dozen known security problems, but it also contained a performance regression letting some scripts run slower by a factor of more than 50 (sic). If your distribution gives you PHP 4.3.10 to fix the security problems and you use PHP4 on a busy server you have a big problem in such a situation. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 12:26:45AM -0700, Steve Langasek wrote: > > Well, the other big ones would be the installer, being synced up on sources, > and the ability to do point releases. It seems the first two are addressed, > and the third seems to be more or less the same question as that of security > support -- whether the people involved are willing to coordinate with an > externally-hosted repo when doing updates. A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? This wouldn't require any extra work. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 11:40:03AM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 23 Apr 2005, Adrian Bunk wrote: > > A silly question to you as release manager: > > Silly indeed. Use the list archives. You cannot miss the monstruous threads > about it. I didn't miss the threads, but much of it looked mostly like the amd64 developers using non-friendly words because the ftp admins didn't respond to them. > > What exactly are the technical reasons why amd64 can't simply be shipped > > as 12th architecture with sarge? > > Mirror space. Instead of replying and beating a dead, burried, and already > decomposed horse, just go read the archives. I might have missed this email in the huge threads, but could you point me to an email explaining why increasing the archive space by less than 10% exacly hits a hard limit in mirror space? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 12:21:49PM -0400, Patrick Ouellette wrote: > On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote: > > The rules and goals of testing are clear. > > > > The more interesting points are the problems of testing that several > > years of using it have shown. > > > > > If package FOO has a RC bug, then everything that depends on FOO will be > > > stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed. If > > > fixing FOO breaks BAR, then they all wait again until BAR is fixed. Use > > > of experimental to work through some of these issues would help. > > > I'm not saying it won't take manual coordination to handle complex > > > changes to the system. I'm not saying it will make anyone's life > > > easier. What my proposal will do is provide the ability to decide when > > > package $PACKAGE makes it into stable, we will call that an official > > > release and give it a number. Alternatively, you could declare every > > > $INTERVAL Debian releases. What is in stable should have been well > > > tested, and supportable. Stable no longer is a static concept, but a > > > slowly evolving thing. If you cannot wrap your mind around to accepting > > > a stable that evolves, we could snapshot stable at release data and make > > > a separate archive (really a Packages.gz and related files as long as > > > the version of the package in the release exists in the package pool). > > > > You completely miss my point: > > > > There are several transitions every month, and a big transition can > > involve several hundred packets. > > > > Your proposal requires, that _every single_ package that is part of a > > transition has to be both ready and in testing for over 3 months before > > it can enter your proposed "candidate". > > > > If _one_ of the packages that is part of a transition is updated in > > testing during this time, the 3 months start again. For bigger > > transitions, it's therefore practically impossible that they will be > > able to enter your "candidate". > > I don't believe I missed your point, you just don't seem to be able to > grasp the fact that I intend candidate to change slowly. > > Yes, I am proposing that every package involved in a transition be of > adequate quality to be promoted to candidate. The purpose of the entire > release system is to ensure the quality of the Debian distribution. > Debian releases "when it's ready" because Debian demands a certain > minimum level of quality (currently defined as an arbitrary number of RC > bugs in packages of variable importance in the distribution as seen by > the release manager). I'm proposing a system that allows "when it's > ready" to be defined and automated. Our current release system places > an enormous burden on the release manager. > > > > > Please try to understand the limitations of testing before proposing > > something even stricter. > > > > I understand the limitations of testing. In fact, I am depending on the > limitations of the testing rules to ensure that candidate is of adequate > quality and changes slowly enough to be used on desktop workstations and > that stable is adequate for servers. The problem is that for many transitions, "slowly" means "never", since the criteria you set are unlikely to be fulfilled for all parts of such a transition at any time in the future. And the more time passes, it becomes more and more complicated since additional transitions might be interdependent with a transition making the problem even more complicated. > I am proposing a system that removes some of the arbitrary nature of > what we call a stable package. I'm proposing that we define QUALITY > CONTROL standards that ALL packages adhere to so that when someone says > they recommend Debian's testing/candidate/stable release, they can point to a > testing system that allows the person to select which branch they use > based upon well know published criteria for the stability of that > particular branch. The user controls the amount of risk they are > willing to have in their system. That's already true today. People who like the latest software can choose between unstable and testing with testing usually having a bit less known bugs. People who want stability use stable. > Testing, candidate and stable should change progressively slower. That > is the entire point. As I am trying to explain, the speed of changes to stable will sonn become zero. If you believe your approach
Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 12:02:39PM -0400, Patrick Ouellette wrote: > On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote: > > Let my try to explain it: > > > > > > The "debian stable == obsolete" is a release management problem of > > Debian. One release every year and it would be suitable for most > > purposes. > > This is the problem. Debian has NEVER been able to have a release every > year. Most server administrators I know would prefer a release cycle > longer than 12 months, most desktop users would prefer around 12-24 > months. But this peoblem is not solved by your proposal (and please read my other email why your proposal won't work). Your release management has announced that the testing release process was able to achive this if they drop two thirds of the Debian architectures. I'd say the pre-testing was able to achieve this with a dozen architectures. > The issue has always been one of "how many RC bugs are acceptable in the > release" and this has always been at the discretion of the release > manager. This number has never been highe than zero [1]. > > You say you've deployed Debian sarge and sid in server environments > > (even sarge, although months old security fixes might be missing???). > > > > Let me ask some questions: > > - How many thousand people can't continue working if the server isn't > > available? > For comparative purposes, I have worked as systems/network/admin where > the number has been as small as 50 and as large as 30,000. > > > - How many million dollar does the customer lose every day the server is > > not available? > > We measured it in millions of dollars per hour, not day. > > > - How many days without this server does it take until the company is > > bankrupt? > > We never got to that point, because it was simply not an option. And critical machines for such a company were running a Debian testing or unstable??? > > If the mail server of a small company isn't running for a few hours it's > > not a problem - but there are also other environments. > > Since you seem to be trolling, I'll feed the troll: If that small > company relies on the email server to take orders from customers, that > few hour outage could translate into a large amount of money. If that > small company is not financially sound, that few hour outage may be the > cause of that small business failing. Large organizations are much I am not trolling. All I wanted to say is that there are not that much computer-bound small companies that can live with some outages. > better equipped to weather a temporary outage (larger cash reserves, > ability to implement backup systems, etc). An interesting problem about software bugs is, that they affect backup systems as well. >... > > > >Look at the third use case I explained above. For these users of Debian, > > > >long-living releases where the _only_ changes are security fixes are > > > >_very_ important. > > > > > > Again, I don't think you ever built a commercial product around Linux > > > based on your statements here. No offence if you have, maybe it's just > > > corporate culture differences between the EU and US? > > > > > > There are reasons why companies pay several thousand dollars licence > > fees for every computer they run the enterprise version of some > > distribution on. E.g. RedHat supports each version of their enterprice > > edition for seven years. A few thousand dollars are _nothing_ compared > > to the support costs and man months that have to be put into setting up > > and testing the system. > > So it should be no problem for those companies who choose to run Debian > to forward a small donation to Debian for all the thousands they save. > Or maybe they should allow their staff to spend several hours a week > getting paid to contribute to Debian. AFAIK neither money nor human resources are a problem of Debian. SPI already has more money than plans how to reasonable spand it, and if manpower was a problem in a project with nearly thousand official and trusted developers, this would be an organizational problem but not a problem you could solve by adding more people to the project - people discovered not less than thirty years ago that adding people to a project often _increases_ the time until the goal is reached. > My point is Debian is NOT a corporate product. If it is found to be > useful by corporations that's great for them. If the corporations want > to run Debian, there are companies that offer similar support for Debian > that RedHat a
Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 02:54:38PM -0400, Patrick Ouellette wrote: > On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote: > > > > The problem is that for many transitions, "slowly" means "never", since > > the criteria you set are unlikely to be fulfilled for all parts of such > > a transition at any time in the future. > > > > And the more time passes, it becomes more and more complicated since > > additional transitions might be interdependent with a transition making > > the problem even more complicated. > > > > You are very good at repeating "this will never work." You are > essentially saying it is impossible for a package to have no RC bugs, > and that those bugs are never going to be fixed fast enough to progress > through the quality control system I proposed. I have a bit more faith > in my fellow Debian Developers than that. > > I admit that the candidate phase will change more slowly than testing - > it is supposed to. The stable (or whatever it is called - maybe > production) section will change even more slowly. This is by design. Show me how my tiff transition example will work in your proposal, and you can prove me wrong... >... > > > Testing, candidate and stable should change progressively slower. That > > > is the entire point. > > > > > > As I am trying to explain, the speed of changes to stable will sonn > > become zero. > > The speed of changes to stable is currently zero. Debian does not have > to do anything to maintain that. My proposal would at the very least > change that from zero to "glacially slow," with the option to pick a > version that changes "slow", "fast", or "continuously." > > > > > > If you believe your approach would work, please try the following: > > > > Take stable from today, and make this your "candidate". > > Take testing from today. > > > > Actually, I am planning on working on that this weekend. I was not > going to start with the current stable, but with the current testing. I > will be building a candidate list by using my proposed rules (0 RC bugs, > 3 months or more in testing). > > I will build a "new stable" from the candidate list with those packages > that have been in testing 6 or more months with 0 RC bugs. Where do you get the information from how long a package is in testing? Do you have 6 months of update_output, or is there a source I do not know about? > It will be interesting to see how many required, base, standard, and > optional packages meet the standard I propose. >... Since even glibc in testing will not be in your candidate list, I can predict that your result set will be very small since you have to ensure that all dependencies and build dependencies are fulfillable... > Pat cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 23, 2005 at 01:20:42PM -0700, Steve Langasek wrote: > On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: > > > A silly question to you as release manager: > > > What exactly are the technical reasons why amd64 can't simply be shipped > > as 12th architecture with sarge? > > We are already running into size constraints (on an ongoing basis) with our > mirrors due to the size of the archive. Some of our mirrors have had to > choose between distributing Debian and distributing other stuff -- some pick > one, some pick the other, but in either case it's bad for the users. The > ftpmasters believe it is not in our interest to exacerbate this situation by > adding another arch before a sensible per-arch partial mirroring solution is > in place. What are the technical problems with such a solution? To be honest, I still do not understand why such an overly complicated solution like in your SCC proposal was required. Why can't a mirror who has a problem with the size of the Debian archive use a tool like debmirror to create the subset it needs? And if this was a problem for some mirrors, Debian could itself create a few such subsets and offer them for mirrors from a different location. Where is the technical problem behind the whole mirror issue that can't be reasonable solved within a pretty short amount of time? Perhaps I'm dumb, but as far as I understand it, there's no release management reason against shipping amd64 with sarge, and it would both be good for the reputation of Debian and prevent the required extra work of maintaining amd64 for sarge externally if amd64 was included in sarge. That's why I'm trying to understand the technical problems behind solving the mirror issue - and have failed to understand them. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sun, Apr 24, 2005 at 12:12:42AM +0200, Josselin Mouette wrote: > Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : > > We are already running into size constraints (on an ongoing basis) with our > > mirrors due to the size of the archive. > > Given that - if I believe the security team [1] - we are not able to > provide security updates for arm, even in woody, is there any point in > including it in sarge when we could include an architecture with working > autobuilders just in place? > > [1] http://lists.debian.org/debian-x/2005/04/msg00183.html Could anyone explain the story behind this? Why exactly is there no longer an ARM autobuilder? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sun, Apr 24, 2005 at 12:24:44AM +0200, Andreas Barth wrote: > * Josselin Mouette ([EMAIL PROTECTED]) [050424 00:15]: > > Le samedi 23 avril 2005 à 13:20 -0700, Steve Langasek a écrit : > > > We are already running into size constraints (on an ongoing basis) with > > > our > > > mirrors due to the size of the archive. > > > Given that - if I believe the security team [1] - we are not able to > > provide security updates for arm, even in woody, is there any point in > > including it in sarge when we could include an architecture with working > > autobuilders just in place? > > Beyond the fact that it is too late to add another architecture for > sarge, removing arm from sarge does not make the mirror pulses much AFAIK, a freeze date for sarge isn't even announed. Is there any planned date, or will there be a "freeze starts tommorow" surprise a few weeks or months from now? > smaller - and AFAIK the size of the mirror pulses is the main problem. You signed the announcement that the Debian archive would have to be splitted, but even you don't know what exactly the problem is you support the solution for??? > Cheers, > Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Fri, Apr 29, 2005 at 03:50:37PM +0200, Andreas Barth wrote: > * Martin Waitz ([EMAIL PROTECTED]) [050429 15:40]: > > On Mon, Apr 25, 2005 at 05:22:53PM +0200, Andreas Barth wrote: > > > Why not? removing arm from testing does not change at all the number of > > > binary arm packages being pushed each day, as the packages between > > > testing and unstable are shared (and only few packages go in via t-p-u). > > > So, the only win is that packages are faster removed - but as unstable > > > and testing are quite in sync, even this is not so much difference. > > > Adding a new arch however adds a lot of new binary packages to be pushed > > > each day > > > > well, those should be about as much as are saved by removing another > > arch -- once the new architecture is uptodate in testing and unstable. > > Actually, that is exactly what is planned post-sarge (well, not removing > an arch, but splitting the archive so that mirrors are only required to > carry some of our current architectures). There is a simple reason why > we don't do it now: We prefer to use the ftp-masters time for resolving > issues we need to release sarge. (And, BTW, of course an architecture > won't be considered for inclusion in sarge unless we have tested it for > a decent time in unstable, so even adding amd64 to sid today won't make > it an sarge architecture, except if we want to delay sarge even more.) > > > > * too much bandwith needed to update all mirrors. > > > >do all mirrors sync with ftp-master? would it help to establish > >a mirror hierarchy where only a few selected mirrors are allowed > >to connect to our master server? > > This is already the case. But there are places where our _mirrors_ > bandwith is too expansive to make the daily pushes even larger. Sorry, but I still don't understand it: You could continue to offer the complete archive as it is today, and it shouldn't be a big amount of work to offer one or more partial archives (e.g. only stable or only i386) from different locations - and a mirror with bandwith problems could simply switch to using a partial archive. This wouldn't be as complicated as the SCC proposal, would have exactly zero impact on release management and should be implemantable within a few days. Considering that this might make it possible to ship amd64 with sarge which would have a positive effect on the reputation of Debian, could you please explain which technical problems I do oversee when thinking that the technical problems of such a solution were small? If such a solution would e.g. take two weeks and would have been implemented at the day of the SCC announcement, it was running for one month today... Could someone please enlighten me? > Cheers, > Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Fri, Apr 29, 2005 at 09:10:10PM -0700, Steve Langasek wrote: > On Fri, Apr 29, 2005 at 10:52:02PM -0500, Adam M. wrote: > > > >Ideally, we would have agreement to update all of the following packages to > > >libmysqlclient12 at the same time: > > > I would suggest that libmysqlclient14 should be used if possible. MySQL > > has changed the way passwords are stored in the database and this > > prevents clients from connecting to MySQL databases unless old-passwords > > option is enabled (which it is in Debian). libmysqlclient12 clients > > cannot connect to MySQL 4.1.x and newer databases unless old password is > > explicitly used or enabled. > > That's not true. It's only libmysqlclient10 that can't connect using the > new protocol. >... Please check the facts before spreading such misinformation. The password hashing change in MySQL occured between 4.0 and 4.1, and clients using libmysqlclient12 therefore can't connect to MySQL 4.1 servers using the new password hashing. The problem can be easily reproduced in unstable by e.g. trying to connect from phpMyAdmin to a MySQL 4.1 database using a user who's password was set without the old_passwords option being active. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of PHP5?
On Mon, Apr 25, 2005 at 07:57:13PM +0200, Joerg Jaspert wrote: > On 10270 March 1977, Piotr Roszatycki wrote: > > > 1. The ftpmaster was a member of pkg-php project, he boycotts my work and > > don't offer something else. > > Im not a member of the php project and I would have rejected it too, I > dont think it has anything todo with jvw beeing intrested in php stuff... > > I cant see much coordination with existing php maintainer(s). As far as I > know they/he informed you about the project on alioth. This sounds like a valid reason for rejecting a package. > And then there is this yada packaging you used. > Nothing against it, whoever wants it can use it[1] - but for such a popular > package that probably will receive a lot of help from different people > this is IMO the worst thing ever to choose. > Something that is known to many,like debhelper, cdbs, whatever is for > sure the better thing to use. > > [1] No flamewar against it intended. Not that I was a friend of yada, but AFAIK it's allowed for a maintainer to use whatever tools he wants for his packaging. If this is wrong and I missed a part of Debian policy not allowing yada, RC bugs should be filed against all packages using yada. And ftpmaster alone was a bad point to disallow yada. As long as a later conversion to yada is allowed, it's quite useless. > bye Joerg cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of 'sarge' for the amd64 architecture
On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > Sorry, but I still don't understand it: > > > > You could continue to offer the complete archive as it is today, and it > > shouldn't be a big amount of work to offer one or more partial archives > > (e.g. only stable or only i386) from different locations - and a mirror > > with bandwith problems could simply switch to using a partial archive. > > > > This wouldn't be as complicated as the SCC proposal, would have exactly > > zero impact on release management and should be implemantable within a > > few days. > > Yes it absolutely would be trivial. All it needs is a script to make a > linkfarm and sync that daily. I can even give you a script for it. And noone has said _why_ this isn't simply done... > > Considering that this might make it possible to ship amd64 with sarge > > which would have a positive effect on the reputation of Debian, could > > you please explain which technical problems I do oversee when thinking > > that the technical problems of such a solution were small? > > > > If such a solution would e.g. take two weeks and would have been > > implemented at the day of the SCC announcement, it was running for one > > month today... > > > > Could someone please enlighten me? > > Back when we asked for amd64 inclusion more than a year ago some > people just ignored it, hiding the (non) problem in the process for > many month. Then the same people don't want to do anything to fix the > problem easy and quickly but rather design a grand scheme to solve a > million problems at once with the Vancouver proposal. And through all > those delays we are now at the "Now it is too late to add amd64" > stage. There were also not so nice things like ftpmasters ignoring emails and amd64 porters calling them names for doing this. This was wrong in both directions, and was one more negative result of communication problems inside Debian. > So, after letting off some steam, please consider some other things > adding amd64 would affect: > > 1. release team > > Another arch to sync. And, as with every arch, there would be some > packages that fail just there. There are still a lot of amd64 specific > FTBFS bugs (lots of them with patches) that would all become RC. The > RC count would double overnight at least for a few weeks. (yeah, it > would be back down if this had happened weeks ago) Besides the fact that I think the RC bug count metric isn't a good metric for measuring the quality (it's a good example for the known fact that in such cases only the metric is improved, but other things that aren't measured by this metric tend to be ignored), FTBFS bugs on architectures a package was never built on are not considered RC. Are there any FTBFS issues on amd64 in important packages that aren't easily solvable? > 2. security ream > > Who knows about amd64? Who is able to debug code to see if security > problems also exist there? Who will maintain the amd64 security buildd What kind of amd64 specific security problems do you expect (except for kernel issues)? > (since us Non-DDs are not allowed)? Who will get the wanna-build > admins to add the amd64 buildd? Seeing as after over 6 month there are > still 2 of the old archs without a security buildd for testing this > seems to be a realy big problem. What is the real problem? Getting hardware? Getting money for hardware? Finding administratores for the machines? > 3. britney > > One more arch, 15K more packages to consider. Britney needs more ram, > more time, gets slower overall and probably fails more often. More > hints needed costing more manual time. Why are more hints needed? And if the problem is Britney being resource hungry, adding more RAM to the computer it's running on might be an option? > 4. D-I docs and CDs > > There are no docs covering amd64 yet as nobody has done any work in > that regard. Since amd64 is basicaly just a i386 on steroids adapting > those docs should be easy. But it has to be done. There are also some > (hopefully minor) quircks left in debian-cd to investigate. Might be > caused by the missing docs. And you have to do this work for your separate amd64 release. > I do however feel that the need of Debians users to have amd64 over > the next 2 years till etch is out far outweights the inconvenience of > adding it. That's why the amd64 team, recently with much entusiasm > from other parts of the debian foodchain, is doing the inofficial > release in parallel with sarge. Which creates extra work... > Sources are the same, cdimages will be on
Re: Outrageous Maintainer
On Sun, May 01, 2005 at 12:38:41AM +0200, Jeroen van Wolffelaar wrote: > On Sat, Apr 30, 2005 at 06:45:26PM -0300, Otavio Salvador wrote: > > But you remove the package from testing doesn't mean we won't have > > users with it installed since it was present there so, IMHO, the > > Conflict is need. > > The bug is in the other package, packages are not required to work > around other bugs in other packages, that'd be a gigantic mess of > workarounds. If dash breaks using my package for whatever reason, I'm > not going to add a conflict: dash (with non-fixed version or whatever), > dash needs to fix it. > > Ditto here, and the fix is removing the package. That's a pretty maintainer-centric view. For your _users_, it doesn't matter which of the packages was "guilty" - and a Conflicts is cheap. See e.g. #218717 and #220983 for examples where the other packages was technically wrong, but a Conflicts in libc6 was the only possible solution. I hope you agree that a Conflicts in a non-"guilty" package is better than email loss for your users? > --Jeroen cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OT: Re: economic disadvantage of closed-source business model
On Mon, May 02, 2005 at 07:55:23PM -0700, Mashilamani Sambasivam wrote: > Hello, > I just want to get the opinion/comments of > developers on some 10 slides I made, if you have time: > 'Brief Analysis and Generalisation of Closed-Source > Software Business Model to All Maximum-Profit Based > Businesses ' > the url: > http://logo3dforkids.sphosting.com/slide1.html This contains some random and often questionable opinions regarding market economy. That the source you quote is 145 years old (sic) only shows that that is misses that many years of both econimic research and economic experience... There are many things you could validly critizise regarding today's market economy - but this requires a real understanding of today's ecomnomy instead of trying to adapt some 19th century opinions to today's economy (that the profit of a corporation would "accumulate ... in the hands of few CEOs and top management" is just an example that you don't even seem to understand where the profits are going to). Regarding the closed-source business model: What you propose (price should reflect only the production costs) works perfectly with a closed-source business model. > hope this is appropriate for this email group. Nope, it's not appropriate. > Thanks much, > Masi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Tue, May 03, 2005 at 12:15:43AM -0700, Steve Langasek wrote: > On Tue, May 03, 2005 at 03:54:10AM +0200, Adrian Bunk wrote: > > On Fri, Apr 29, 2005 at 09:10:10PM -0700, Steve Langasek wrote: > > > On Fri, Apr 29, 2005 at 10:52:02PM -0500, Adam M. wrote: > > > > > >Ideally, we would have agreement to update all of the following > > > > >packages to > > > > >libmysqlclient12 at the same time: > > > > > I would suggest that libmysqlclient14 should be used if possible. MySQL > > > > has changed the way passwords are stored in the database and this > > > > prevents clients from connecting to MySQL databases unless old-passwords > > > > option is enabled (which it is in Debian). libmysqlclient12 clients > > > > cannot connect to MySQL 4.1.x and newer databases unless old password is > > > > explicitly used or enabled. > > > > That's not true. It's only libmysqlclient10 that can't connect using the > > > new protocol. > > >... > > > Please check the facts before spreading such misinformation. > > Indeed, the facts *were* checked; a libmysqlclient12 can connect to a MySQL > 4.1 server on Debian using the default password hash algorithm. > > Unfortunately, it turns out this is because the Debian package has changed > the default. > > Had I been aware of this three months ago, I almost certainly would have > been trying to get people to switch to libmysqlclient14 instead of > libmysqlclient12. :/ What exactly did you check? Where did libmysqlclient10 fail for you while libmysqlclient12 worked? To confirm that libmysqlclient10 works fine with MySQL 4.1 servers, I recompiled PHP4 with libmysqlclient10 and it worked like a charm (with old_passwords in the MySQL server). > Steve Langasek cu Adrian BTW: The interaction between the two MySQL server packages in unstable/sarge at purge time is *ahem* interesting. They are really time bombs ready to explode in a few days or years. It seems RC bugs are required for both of them... -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A way _not_ to handle bugs
severity 306015 grave thanks Hi Steve, first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than "This is not a missing dependency, feh" I know that downgrading RC bugs makes your RC bugs metric look better, but this bug is a good example why only working on improving a metric is a bad thing. In my testing, e.g. php4 from woody together with php4-mysql from sid is _not_ a working combination. Please either explain why "this is not a missing dependency" or promise to be a little more careful in the future instead of blindly downgrading bugs. TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of PHP5?
On Tue, May 03, 2005 at 11:26:19AM +0100, Mark Brown wrote: > On Tue, May 03, 2005 at 04:04:44AM +0200, Adrian Bunk wrote: > > On Mon, Apr 25, 2005 at 07:57:13PM +0200, Joerg Jaspert wrote: > > > > And then there is this yada packaging you used. > > > Not that I was a friend of yada, but AFAIK it's allowed for a maintainer > > to use whatever tools he wants for his packaging. > > > If this is wrong and I missed a part of Debian policy not allowing yada, > > RC bugs should be filed against all packages using yada. > > The issue wasn't the use of yada per se, it was the use of yada in the > context of something like updating PHP where there are existing packages > and maintainers. Using one of the more obscure helper packages is a > sign of lack of coordination rather than outright bugginess. I said at the beginning of my email, that I do think the PHP4 <-> PHP5 maintainer situation is a valid reason for rejecting these packages - independent of the kind of packaging. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Tue, May 03, 2005 at 07:08:50AM -0400, sean finney wrote: > On Tue, May 03, 2005 at 10:22:04AM +0200, Adrian Bunk wrote: > > BTW: The interaction between the two MySQL server packages in > > unstable/sarge at purge time is *ahem* interesting. > > They are really time bombs ready to explode in a few days or > > years. > > It seems RC bugs are required for both of them... > > if there's a problem, please file a bug about it instead of making > vague remarks like this. I already did this (#307473). It took a bit of time to properly test it and understand all implications of this problem which is why I didn't immediately send the bug. > sean cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 08:30:22AM -0700, Thomas Bushnell BSG wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > severity 306015 grave > > thanks > > > > Hi Steve, > > > > first of all, if you downgrade a bug only a good hour after I upgraded > > it, it would be nice if you would: > > - Cc me > > - send a better explanation than "This is not a missing dependency, feh" > > Looking at the bug log, it seems that you had no business increasing > the severity in the first place. You didn't report the bug, you > aren't the maintainer, and now you are playing BTS wars. It's up to > the maintainer and Steve, secondarily it's up to the submitter of the > bug, and it doesn't seem to concern you at all. You seem to confuse this with bug closing. It's common practice to adjust the severity of a bug to a RC one if a RC issue was mistakenly reported as non-RC, and neither your Developers Reference nor your release team have ever disagreed with this practice. The alternative would be to send a second bug for the same issue with the correct RC severity. If this makes you happy I can do this in the future. > This bug does not make the package "unusable or mostly so" because it > has a trivial workaround available. So it was wrong of you to mark it Once upon a time, Debian was famous for it's working upgrades. You can workaround many bugs - but why do you emphasize on the fact that there was "a trivial workaround available" if the fix for the bug is trivial? > grave, unless you are just seeking attention. It might be "serious", > but the submitter himself thought it was "important". You didn't give > any reasons for busting in and changing it. That's wrong. grave <-> serious isn't worth a discussion since there's not a big difference between them (both are RC) Even Steve had always agreed that missing dependencies that break partial upgrades from woody were RC bugs And even in the email were he downgraded this bug he only wrongly stated "This is not a missing dependency" - not that missing dependencies weren't RC. > Thomas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 12:40:21PM -0700, Steve Langasek wrote: >... > On Tue, May 03, 2005 at 12:27:32PM +0200, Adrian Bunk wrote: > > > first of all, if you downgrade a bug only a good hour after I upgraded > > it, it would be nice if you would: > > - Cc me > > - send a better explanation than "This is not a missing dependency, feh" > > If you are going to upgrade bugs to RC severity without talking to the > maintainers first, it would be nice if you would be right. I have explained how this can produce non-working package combinations. If you do immediately lower the severity of a bug I raised the severity of again, could you please at least put my in the Cc header of the message you send to the BTS? > > In my testing, e.g. php4 from woody together with php4-mysql from sid is > > _not_ a working combination. > > $ apt-cache show php4-mysql > Package: php4-mysql > Version: 4:4.3.10-12 > Depends: Depends: libc6 (>= 2.3.2.ds1-4), libmysqlclient12, debconf (>= 0.5) > | debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-12) > > ^^^ > > php4-mysql does not depend on php4 because the php4 package is *not* > required to be installed in order for php4-mysql to be usable: installing > any of the packages that provide phpapi-20020918 is sufficient to give you > a php4 engine that can be used with php4-mysql. php4-mysql does not depend > on any particular package providing the interface, because it has no way of > knowing which one the user wants. > > The actual bug you're describing, therefore, is that the package > relationships do not prevent you from having multiple PHP engines > co-installed on your system that each provide different extension ABIs. > This is a well-known bug that's irritating but not release-critical, and > fixing it in sarge would not be at all straightforward. >... I'd consider this RC, and I think there might be good solutions that are not too difficult (e.g. Conflicts with the woody versions). But with this explanation, I understand your point. Communication is important. Why haven't you simply sent this explanation together with the control message and a Cc to me? This way I would have understood why you've downgraded it (whether I agree or not), and instead of becoming angry I would have thought about possible solutions for this bug (with this information I didn't have before). With this information you've now shared with me, my suggestion would be: All the packages providing phpapi-20020918 are built from the same source package. What about providing php-4.3.10 and letting packages like php4-mysql depend on such a version-specific provides? This would also make sense in cases like the ZTS transitions were you could change this Provides and automatically have all dependencies correct. Perhaps this suggestion doesn't work for some reason. But if you'd have shared the reasons why you don't think this issue was RC, you'd have helped me to think about ways how to fix this issue properly instead of sending an unfriendly email. I do admit that my email was overly unfriendly, but I hope you can understand that a bit of information from you would have been better. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 09:24:34AM -0700, Thomas Bushnell BSG wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > You seem to confuse this with bug closing. It's common practice to > > adjust the severity of a bug to a RC one if a RC issue was mistakenly > > reported as non-RC, and neither your Developers Reference nor your > > release team have ever disagreed with this practice. > > If you are also encountering the bug, then this is true, but I would > expect you, being as knowledgeable as you are, to indicate that in the > bug report and add yourself as a submitter. I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? >... > > Even Steve had always agreed that missing dependencies that break > > partial upgrades from woody were RC bugs And even in the email were he > > downgraded this bug he only wrongly stated "This is not a missing > > dependency" - not that missing dependencies weren't RC. > > This seems to indicate that he thinks there is a different explanation > for the bug, and that while adding the package in question as a > dependency makes it go away, this is not the correct fix. But I can > only guess, as can you, which means it would be good to hold off > until he can say rather than play BTS tag. That's exactly the problem. He has now given an explanation. As I've said in another email in this thread, giving this explanation in the email he lowered the severity with and sending me a Cc would have been perfect. > Thomas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
On Tue, May 03, 2005 at 12:46:32PM -0700, Steve Langasek wrote: >... > 30 May 2005 > Release > > And if everything goes well, we'll be ready to release at the end of the > month. >... Setting goals is the easy part of release management. Ensuring that the goals are met is the hard part of the work of a release manager. This is the third officially announced release date for sarge that gets a wider media coverage. The December 1st 2003 date was missed because the development of the installer took more than a year longer than expected. The September 15th 2004 date was missed because the security infrastructure for testing took more than 6 months instead of only 6 days. I'm sure you've learned from these two fiascos, and you've done everything to ensure that you will not miss your milestone dates. Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: > Adrian Bunk wrote: > > >grave <-> serious isn't worth a discussion since there's not a big > >difference between them (both are RC) > > You are 100% wrong here. Why do we have bug severities then? Severities > are there to inform the developer and the rest of the Debian world about > the seriousness of the bug. I tend to stay away from packages that have > grave or critical bugs against them before I read the bug report. So, > let me refresh your mind about bug severities, >... Let me try to reformulate my point: important <-> serious or important <-> grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's "only" a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. > - Adam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
On Wed, May 04, 2005 at 03:05:24PM +0200, Jeroen van Wolffelaar wrote: > On Wed, May 04, 2005 at 02:42:15PM +0200, Adrian Bunk wrote: > > Can you tell about the possible risks that may affect your release plan > > and what you have done to ensure that they will not delay your release > > plan? > > Can you tell me about the usefulness of whining[1] about release policy > for years, and how this will not delay the release? Debian DPL candidates often talk during their election campaigns about a lack of communication in Debian. But when asking for some background of an announcement that's considered evil? > --Jeroen > > [1] I don't use this word lightly in mail, but to be honest, your > continued vendetta against the current release policy is quite > annoying. Especially seen in the light of your resignation as Debian > Developer, by which you abstained from any committment to help > Debian constructively from the inside, this is not really a fair > thing to do. As we say in the Netherlands, "De beste stuurlui staan > aan wal", "The best boatsmen are standing on shore": it's easy to > complain while not bearing any responsibility, rather than actually > doing the job You are confusing cause and effect. Please look at the reasons why I resigned. I stated before my resignation, that my personal motivation went down to zero because more than one year after the start of the woody freeze, we were still far away from a freeze although I did my best in helping getting nearer to a release, there was zero visible progress [1]. This is the reason why I resigned some time later [2]. At the time when I was a Debian maintainer (maintaining 42 packages and being an active member of the QA team), there were exactly zero possibilities for an average maintainer like me to influence anything from the inside except for the more theoretical influences of starting a GR or participating in votes (which gives me at about as much influence as I have on politics in real life). If this has changed, and Debian maintainers now have more influence I'd be glad to rejoin and help Debian from the inside. You might disagree with this, but the whole sarge release cycle until now was not able to show me that the current release process was working (and even worth dropping two thirds of the Debian architectures, because as your release team announced the testing release process can't cope with a dozen architectures). cu Adrian [1] http://lists.debian.org/debian-devel/2002/01/msg00961.html [2] http://lists.debian.org/debian-devel/2002/01/msg02160.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 08:45:21AM +0200, Andreas Tille wrote: > On Sat, 7 May 2005, Joey Hess wrote: > > >bb > I did not checked your complete list but our most frequently used > programs at exhigition boothes. It currently has no RC bug (the only > grave bug was solved two weeks ago. > > So something is wrong either with your list of with the removal. That's a funny example of the result of the release team's focus only on the RC bugs metric: This package had a more than six years old "normal" bug stating that bb crashes on alpha (#32160). Last month, a second bug for exactly the same issue was sent with severity "grave" (#304434). This second bug report included a trivial one line fix for this bug. You might think the second bug made the situation better because it included a patch for a more than six years old bug that made the package unusable on 64bit machines. But in the logic of your release team, the first non-RC bug didn't show in their RC bugs metric while the second bug did. bb was therefore removed from testing a few days after the second bug was sent (really not many days since the fixed package was uploaded 12 days after the second bug report was sent). > Kind regards > > Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 03:07:44PM +0200, Petter Reinholdtsen wrote: > [Joey Hess] > > So here is a list (from update-excuses) of all 491 packages that is > > being held out of sarge[1]. > > I would be even more interested in seeing which packages in woody are > now missing in sarge. Anyone have such a list available? >... At the bottom is a complete list of the 2070 binary packages present in woody but not in sarge (including nun-US and contrib/non-free). Most interesting might be the following list of 129 binary packages present in both woody and sid but not in sarge: abuse abuse-frabs abuse-lib abuse-sdl abuse-sfx apt-proxy autorespond barrendero bb blootbot bookview cce configlet-frontends coq-doc crystalspace crystalspace-dev crystalspace-doc cursel debget dhcp-dns directory-administrator divine doomlegacy-data doom-wad-shareware doxymacs eglade eroaster ext2resize falconseye falconseye-data filler freewrl gkdial gkdial-gnome gnokii gnome-chess gnome-pim goldedplus gpsim-led grunch gsnes9x gwydion-dylan gwydion-dylan-dev ibm-jdk1.1-installer id-utils innovation3d innovation3d-dev innovation3d-plugins install-doc interchange interchange-cat-foundation interchange-ui ipac-ng ipmenu jswat kannel kernel-patch-openmosix kernel-patch-uml kimberlite kimberlite-doc l2tpd ldmud lftp libapache-mod-interchange libavalon-excalibur-java libavalon-excalibur-java-doc libflash0 libflash-dev libgcrypt1 libgcrypt-dev libgcrypt-doc libgd-perl libmail-cclient-perl libroxen-floatingcode libsoap-java libsoap-java-doc mailscanner mercury mindy mp3burn murasaki ndtpd nvclock ohphone ohphone-basic oops openmosix opustex p2c panorama partimage partimage-server phpdoc ploticus plucker python-configlet python-parted python-pcgi qmail-src r5rs-doc rootstrap saxon-catalog scilab sformat siege-ssl smail stella symlinks tcl8.0-ja t-gnus tk8.0-ja tleds trn tth ultrapoint unrar user-mode-linux wap-wml-tools watchdog xa+cv xfractint xmms-wmdiscotux xtux xtux-client xtux-common xtux-server yh zmailer zope-popyda cu Adrian All packages in woody but not in sarge: 3270-common 3dwm-clock 3dwm-csgclient 3dwm-geoclient 3dwm-pickclient 3dwm-server 3dwm-texclient 3dwm-vncclient a52dec a52dec-dev abc2mtex abiword-gtk abuse abuse-frabs abuse-lib abuse-sdl abuse-sfx acl-dev adbbs addressbook admwebuser aegis3 aegis3-doc aegis3-tk aegis3-web aethera agbrowser agsatellite alsaconf alsa-headers-0.4 alsa-headers-0.5 alsa-modules-2.4.16-386 alsa-modules-2.4.16-586 alsa-modules-2.4.16-586tsc alsa-modules-2.4.16-686 alsa-modules-2.4.16-686-smp alsa-modules-2.4.16-k6 alsa-modules-2.4.16-k7 alsa-source-0.4 alsa-source-0.5 alsa-utils-0.4 alsa-utils-0.5 althea althea-ssl amavis-postfix amaya-dict-de amaya-dict-en amaya-dict-es amaya-dict-fr amaya-dict-it amaya-dict-ne amaya-dict-se ami-gnome amiwm amp am-utils-dev anti-aliasing-howto apt-localepurge apt-proxy arch argante aris-extractor ari-yahoo arpack++ arpack2 arpack2-dev asd4 asd4-clients asmodem asnparser attr-dev autoinstall autoinstall-i386 automake automake1.5 autorespond awe-drv awe-midi awe-netscape-libc5 awe-netscape-libc6 axyftp-doc axyftp-gtk axyftp-lesstif barrendero basilix bass battstat-applet bb bblaunch bbpal beaver bigloo-runtime-2.4b binutils-sparc blackened blatte blootbot blt8.0-dev blt-common bnc bonobo-python bookmarker bookview bpowerd bsd-ftpd btoa bulkmail busybox-source-0.60.0 c3270 captain casio catalog caudium-php4 cbb cce ccf cdbakeoven cdebconf-dev cdindex-client cdrecord-dev cedictb5 cedictgb cedicttools cern-httpd cfitsio2 cfitsio-dev cfitsio-doc chaos chpp cil cim clanlib clanlib0-common clanlib0-common-dev clanlib0-display-fbdev clanlib0-display-ggi clanlib0-display-glx clanlib0-display-svga clanlib0-display-x11 clanlib0-docs clanlib0-utils clanlib-dev clanlib-gl clanlib-gui clanlib-jpeg clanlib-mikmod clanlib-network clanlib-png clanlib-sound clanlib-ttf clanlib-vorbis cl-imho cl-local-time cl-local-time-db cl-metadata cl-uncommonsql cl-uncommonsql-mysql cl-uncommonsql-oracle cl-uncommonsql-postgresql cocoon cocoon2 cocoon2-doc cocoon2-example cocoon-doc cocoon-example cocoon-lib communicator communicator-base-477 communicator-nethelp-477 communicator-smotif-477 communicator-spellchk-477 configlet-frontends console-tools-libs cooledit coolicon coolman coq-doc cost courier-debug cpp-3.0 cpp-3.0-doc cqcam crystalspace crystalspace-demos crystalspace-dev crystalspace-doc cucipop cupsys-pstoraster curl-ssl cursel cvs-conf cvs-pcl cvsup cvsupd cxhextris cyrus-nntp d4x-gnome-applet dbf2pg dcopperl dcoppython ddt-client ddt-server debconf-tiny debget debian-guide debian-guide-es debian-guide-zh-s debian-guide-zh-t debian-test debrecipes-es debwrap devhelp-book-ggad devhelp-book-gnome devhelp-book-gtk dhcp-dns directory-administrator distributed-net-pproxy ditty divine dmachinemon-gtkiface dmapi dmapi-dev dmbt docbook-xml-jrefentry docbook-xml-simple docbook-xml-slides docbook-xml-website docbook-xsl-stylesheets doc-es-misc doc-jakarta-ja doc-linux-fr doc-linux-zh-s
Re: packages missing from sarge
> At the bottom is a complete list of the 2070 binary packages present in > woody but not in sarge (including nun-US and contrib/non-free). Correction: 2069 binary packages The entry "packages:" was a bug in my quick&dirty scripting... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sun, May 08, 2005 at 03:54:46AM -0700, Steve Langasek wrote: > > Yes, it's called "garbage in, garbage out". If people aren't going to file > bugs at the proper severity, and if package maintainers aren't going to > treat release-critical bugs with the appropriate urgency when they *are* > filed at the wrong severity, there's no way in hell anyone is going to know > there's a problem. > > It's not the metric that's broken here. If your release management is based on the assumption all bugs in Debian were at the correct severity and tagged correctly, your release management is based on an assumption that isn't true. See #302282 for an example where even you yourself tagged a bug wrongly as "sid"... And since you say the package maintainers were responsible for correct bug severities: How often does a quick NMU that gives a fast improvement in the RC bugs metric hide the real problem that the maintainer is completely or partially MIA? > Steve Langasek cu Adrian BTW: In case anyone of the release team takes the announced 30 May 2005 release date (that already got some media coverage) seriously, I'd be glad to bet some some Euros against it... -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: > [Adrian Bunk] > > The entry "packages:" was a bug in my quick&dirty scripting... > > Thanks for making a nice summary of the relevant packages. :) > > Feel free to include the script to generate the list when you generate > dynamic list of packages like this. It would make it easier for all > of us to re-generate it on demand. :) To be honest, I do not like to make ugly 5 minute hacks public. I can send it to you privately, but is seems Javier has already sent a better looking script. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: > On Tue, 10 May 2005, Adrian Bunk wrote: > > Speaking as somebody who is quite unrelated to release issues (except > that I keep my packages bug free) I have some questions: > > >were at the correct severity and tagged correctly, your release > >management is based on an assumption that isn't true. > Interesting statement but what is your suggestion to improve this? > > >And since you say the package maintainers were responsible for correct > >bug severities: > > > >How often does a quick NMU that gives a fast improvement in the RC > >bugs metric hide the real problem that the maintainer is completely or > >partially MIA? > Actually what is your opinion how to improve the QA process? It might sound strange, but I'd suggest to completely disallow NMUs without maintainer permission. This would make it take longer until RC bugs are fixed, but it would help on speeding up the finding of maintainers who are for any reason not able to properly maintain their packages. > >BTW: In case anyone of the release team takes the announced 30 May 2005 > >release date (that already got some media coverage) seriously, I'd > >be glad to bet some some Euros against it... > What is the lesson whe should learn from this? I might be wrong and the release team really thinks this is a date they will reach. But otherwise, the problem seems to be that in any other area I know the quality of release management is in a big part measured in how it manages to reach the goals. Debian release management has the big advantage to setting their own goals. But the last date (September 2004) set by the current release management failed because security support for sarge that was assumed to be ready six days after the announcement took more than six months. I asked: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? but noone of the release team did bother to answer. > Just curious > >Andreas. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:50:48AM +0200, Wouter Verhelst wrote: > On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote: > > On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: > > > On Tue, 10 May 2005, Adrian Bunk wrote: > > > >How often does a quick NMU that gives a fast improvement in the RC > > > >bugs metric hide the real problem that the maintainer is completely or > > > >partially MIA? > > > Actually what is your opinion how to improve the QA process? > > > > It might sound strange, but I'd suggest to completely disallow NMUs > > without maintainer permission. > > > > This would make it take longer until RC bugs are fixed, but it would > > help on speeding up the finding of maintainers who are for any reason > > not able to properly maintain their packages. > > What are we trying to do, then? > > Release Debian, or find MIA maintainers? Based on your previous mails, I > thought you wanted the first. That will go a *lot* easier if we don't Both belong together. The release team plans with a < 1 month freeze and a big emphasis on the RC bugs metric. To be honest, I was very surprised if the release team would miss it's own release date by less than one month. E.g. there will always be problems like bugs with a too low severity or wrong tags that will show up late in the freeze. If there was more focus on the many other problems like maintainers not properly maintaining their packages instead of only on the RC bugs metric both before and during the freeze, the resulting release was better and some negative surprises were less likely. This might seem to defeat the goal of super-short freezes, but I have yet to see at least one freeze that was not only announced as super-short, but that was actually as short as it was announced... > have buggy packages anymore, for which NMU's can be helpful under > certain circumstances. This depends on how you define "buggy packages". If you count only RC bugs you are correct. But non-RC bugs aren't the only bugs. Many annoying things like segfaults under specific circumstances are not considered RC. As an example, look at how many segfaults in the texinfo source package are unfixed for several months. And the last NMU didn't include e.g. my upstream-approved one-line patch for the #259561 segfault. Well, this bug is only "important"... RC bugs are a metric to measure the quality of Debian. But as it is a well-known fact about metrics, work on improving the metric often only improves the metric but not what it was supposed to measure. > If, however, you are indeed intent on finding MIA maintainers for some > to me obscure reason, then I think it'd be nice if you'd talk to those > people actually doing that work at this moment, to see whether they > agree with you that NMU's make their work harder. My guess is that > you'll find they don't, but then of course I haven't asked either. Completely MIA maintainers are one part of the problem. But then there's the class of maintainers who manage to upload a new upstream version and perhaps fix some RC bugs every few months but are not able to properly handle all bugs in their packages. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 09:36:39AM -0700, Thomas Bushnell BSG wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > What's the syntax for the email to [EMAIL PROTECTED] for adding a second > > submitter? > > I believe > > submitter [EMAIL PROTECTED],[EMAIL PROTECTED] > > works just fine. I'm quite surprised - I have to admit it actually works (and Colin immediately fixed two minor glitches with multiple submitters). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Relevance of unzoo?
On Wed, May 11, 2005 at 12:39:04PM +0200, Thomas Schoepf wrote: > Hi, Hi Thomas, > how important is it to have unzoo, now that zoo is in main? > unzoo is only able to list and extract files, not to add new ones. the functionality of unzoo is a subset of the functionality of zoo? In this case a dropping of unzoo seems reasonable. But the packages clamav and amavis-ng do recommend the unzoo package. However they use it (I havn't checked) they should be converted to use the zoo package before the unzoo package gets removed. > Thomas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, May 14, 2005 at 11:07:36AM +0200, Thomas Hood wrote: > On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote: > > Completely MIA maintainers are one part of the problem. > > > > But then there's the class of maintainers who manage to upload a new > > upstream version and perhaps fix some RC bugs every few months but are > > not able to properly handle all bugs in their packages. > > > In part this is a consequence of scarce manpower. In part it is a > consequence of the institution of package ownership and other > organisational flaws. If you agree with this diagnosis then I am curious > to know which of the following you plan to do. > > 1. continue to participate in the Debian project despite its >dysfunctional organisation; > 2. push for changes to the organisation; > 3. participate in another project instead. > > (There are other possibilities, of course.) Some years ago the only choice for me was 1) since 2) was not possible for an average Debian maintainer. I was glad to hear if this had changed since I left. > Thomas Hood cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:33:36PM -0700, Steve Langasek wrote: > On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > > Steve Langasek schrieb: > > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > > >>not just get 2.3.x pushed into sarge? Are there any other big issues > > >>with it, that weren't in 2.2.x? Some people might certainly like the > > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > > >>fine for me though --- anything but 2.1.x for me :-) > > Mainly because 2.3.x causes other openswan boxes to crash in some > > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > > keep bugging upstream with it for at least 3 months. No fix until now, > > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > > even 2.2.0-5). > > > > Because 2.2.3 is no longer in the archive, and resurrecting new binaries > > > via > > > t-p-u gives us even less than the usual protection against breakage caused > > > by a lack of testing. :/ > > Does that mean that the only way to get the known stable 2.2.0-x back > > into testing is an upload to unstable with an epoch? I really wouldn't > > like to go that route if I can avoid it > > Well, AFAIK openswan has never actually been in testing /before/, so it's > not a matter of getting it /back/; but yes, the upshot is that I'm not > comfortable adding packages to testing via t-p-u. That's wrong, openswan was in testing earlier this year. Read e.g. [1]. > Steve Langasek cu Adrian [1] http://lists.debian.org/debian-release/2005/01/msg00181.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?
On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote: > Short version: > Should users first upgrade dpkg and aptitude before upgrading the rest of > the system or can the upgrade safely be done using Woody's version of the > package tools? > > Long version: > The current version of the release notes tells users to (simplified): > 1. apt-get install aptitude > 2. change the /etc/apt/sources.list to point to "stable" > 3. aptitude update > 4. aptitude -f --with-recommends dist-upgrade > > Step 1. is meant to install the Woody version of aptitude, but of course > it will not if the sources.list already points to "stable" and the user > has already done an 'apt-get update'. > > There have of course been improvements in Sarges version of aptitude. Also > I wonder if upgrading the packaging tools as part of the dist-upgrade > could in itself be a source of problems. > > Therefore the question if it would be better to change the procedure to: > 1. change the /etc/apt/sources.list to point to "stable" > 2. apt-get update > 3. apt-get install aptitude dpkg > 4. aptitude -f --with-recommends dist-upgrade > ??? > > I have done an upgrade myself a while back using the second method [1] and > noticed: > - 'apt-get install aptitude' does _not_ upgrade dpkg automatically; > as it seemed to me better to have all package tools from the same > version, I upgraded both aptitude and dpkg before continuing with the > rest of the upgrade; > - in my test upgrading aptitude and dpkg also upgraded the following: > apt apt-utils aptitude debconf debconf-utils debhelper dpkg dpkg-dev > libc6 libc6-dev libdbd-mysql-perl libdbi-perl libgcc1 libncurses5 > libncurses5-dev libpopt0 locales perl perl-base perl-modules whiptail > zlib1g > and installed: > debconf-i18n dselect gcc-3.3-base gettext intltool-debian > libdb1-compat libdb4.2 libgdbm3 liblocale-gettext-perl > libnet-daemon-perl libnewt0.51 libplrpc-perl libsigc++-1.2-5c102 > libstdc++5 libtext-charwidth-perl libtext-iconv-perl > libtext-wrapi18n-perl linux-kernel-headers po-debconf slang1a-utf8 > I understand that for some arches (hppa) this may necessitate upgrading > the kernel first. > > Comments very, very welcome. <-- snip --> # apt-get install aptitude dpkg ... The following packages will be REMOVED: cyrus-imapd wine ... [answer n] # apt-get install aptitude dpkg cyrus-imapd wine ... The following packages will be REMOVED: autoconf2.13 ... [answer n] # apt-get install aptitude dpkg cyrus-imapd wine autoconf2.13 ... [nothing to be removed] <-- snip --> OTOH, at least in the woody installation I tried this, "aptitude -f --with-recommends dist-upgrade" works fine. It seems aptitude in woody has a better Conflicts handling than apt in woody making the first step easier for users. > Cheers, > Frans Pop > > [1] http://lists.debian.org/debian-release/2004/11/msg00105.html cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?
On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote: > * Adrian Bunk [Mon, 16 May 2005 18:14:20 +0200]: > > On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote: > > > > The current version of the release notes tells users to (simplified): > > > 1. apt-get install aptitude > > > 2. change the /etc/apt/sources.list to point to "stable" > > > 3. aptitude update > > > 4. aptitude -f --with-recommends dist-upgrade > > > > Therefore the question if it would be better to change the procedure to: > > > 1. change the /etc/apt/sources.list to point to "stable" > > > 2. apt-get update > > > 3. apt-get install aptitude dpkg > > > 4. aptitude -f --with-recommends dist-upgrade > > > OTOH, at least in the woody installation I tried this, > > "aptitude -f --with-recommends dist-upgrade" works fine. > > > It seems aptitude in woody has a better Conflicts handling than apt in > > woody making the first step easier for users. > > So, to make that clear, you're proposing the following: >... I'm not proposing anything since I don't know enough about these issues for giving any recommendation. All I said was that the way you proposed seems to be worse than the currently documented way (at least in my test cases). > Note that in (4), the command is aptitude, not apt-get. Does this make any difference? > BTW, why "change sources.list to point to 'stable'" instead of > 'sarge'? Probably there'll be a reason I'll love to here, but all are > disadvantages to me, e.g.: >... I'd agree that "stable" is a bad choice since this will lead to people accidentially upgrading to etch (without reading the etch release notes telling them how to do it best). > Cheers, > Adeodato Simó cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing ipfwadm
On Mon, May 16, 2005 at 09:49:01AM -0700, Adam McKenna wrote: > I am not sure whether the ipfwadm package should be removed. Kernels up to > 2.4 still have support for ipfwadm filtering rules, so theoretically people > could still be using it with current kernels. > > cc'ing debian-devel. If the consensus there is that the package should be > removed, I'll request its removal. _All_ kernel versions in sarge support ipfwadm. Not that I expect many people to use it, but I don't see a good reason for removing it. > --Adam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?
On Mon, May 16, 2005 at 08:12:04PM +0200, Adrian Bunk wrote: > On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote: >... > > Note that in (4), the command is aptitude, not apt-get. > > Does this make any difference? >... It does. My fault, I confused (4) with (3). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC on mysql 4.1 in sarge
On Wed, May 18, 2005 at 11:23:35AM -0400, sean finney wrote: >... > the following upgrade paths work: > > mysql-server/woody -> mysql-server/sarge > mysql-server/woody -> mysql-server/sarge -> mysql-server-4.1/sarge > > but this does not: > > mysql-server/woody -> mysql-server-4.1/sarge > > so at this point, we're not sure what to do to cover this last problem, > as we have no guarantee the preinst of mysql-server-4.1 will even run > before mysql-server/woody is removed. the only fix we can think of is > to remove the two directories from the files.list of the woody package. > > so we've come up with three options, none of which are great: > > 1 the most recenty woody security update caused problems for some > people, and there's a package already waiting to go in to fix this > problem. we could put a fix into the woody mysql-server package into > this package before the security team handles it. > 2 if there's going to be a final woody point release, we could put a > fixed version in there You must not assume that users have the latest security fixes or the latest point releases installed. > 3 give up on trying to fix it, assume that symlinks might get lost, and > put something in a README file telling users what they have to do > in order to fix up their database after restoring the symlinks. > > i don't see 1 happening, i don't know if the prerequisite (woody release > update) for 2 is going to happen, and 3 doesn't make me all too happy > as a "solution". > > > so, questions, comments, suggestions all welcome, 4 drop mysql-dfsg-4.1 from unstable/sarge Other issues like #308762 are also still possible on direct mysql-server/woody -> mysql-server-4.1/sarge upgrade paths - and there will be users doing such upgrade paths. The whole mysql-dfsg/mysql-dfsg-4.1 setup is really ugly in some corner cases. Is shipping MySQL 4.1 with sarge really worth all the troubles, especially considering that MySQL 4.0 is quite usable? Also consider that some weeks from now MySQL 4.1 will also soon be no longer current when MySQL 5.0 will be released. > sean cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
