Re: Buildd & binary-indep
On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote: > No, it builds all the content for arch:all and non-arch:all, but only > creates the non-arch:all binaries. The issue is that there's currently > no way for the buildds to say "Only build the non-arch:all content" > since the only required build target is "build". what's the problem with requiring the binary-arch target for all packages in debian after squeeze release? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aan4ncga@faui44a.informatik.uni-erlangen.de
Re: Buildd & binary-indep
On 2010-09-26, Reinhard Tartler wrote: > On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote: >> No, it builds all the content for arch:all and non-arch:all, but only >> creates the non-arch:all binaries. The issue is that there's currently >> no way for the buildds to say "Only build the non-arch:all content" >> since the only required build target is "build". > what's the problem with requiring the binary-arch target for all > packages in debian after squeeze release? That's already required. What's not required (yet?) is a build target that only builds arch:any or arch:all. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni9u2af.tho.tr...@kelgar.0x539.de
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Raphael On 09/23/2010 02:30 PM, Raphael Hertzog wrote: > On Thu, 23 Sep 2010, Luk Claes wrote: >>> Raphael's article is now published, and is probably a good basis for >>> discussing CUT on -de...@. >>> Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/ >> >> Personally I have the feeling that if we would choose for rolling as >> described in the article, that testing would actually get replaced by >> rolling and we do not care about extensive architecture support anymore. >> Not sure if we want to take that route. Personally I think we are > > The article describes the broad range of possibilities. But I agree that > it would be bad to pick the extreme choice where rolling only > takes into account the mainstream architectures. I think it's safe > to keep that restriction for installation media made available on > snapshots but rolling itself should be consistent with testing in terms of > architecture support. > > Given this, it means rolling becomes a superset of testing outside of > freeze, and a replacement for testing during the freeze. I would suggest > to start that way to not disturb the processes in places, but in the long > term I agree it should supersede testing. testing would be a branch of > rolling that starts at freeze time. This branch could then remove the > packages that are not deemed safe for a long term release. IMHO, what is missing from rolling should be added to testing, not worked around by introducing another suite: >> already taking the necessary steps to have a nice compromise regarding >> architecture support as well as most removals. Certainly there are >> improvements possible, though I'd rather have them implemented in >> testing proper (even if we would rename testing ;-)). > > I would like this if it were possible. But I'm not sure how to achieve it. > > How can we ensure that testing always contains a stable version of > chromium ? The current decision of keeping it out of testing was right > given our actual constraints on what's ok for a stable release. > I would argue that we need to redefine our criteria for a stable release > and I plan to have this discussion at some point but I think in the mean > time having rolling is good way to fix this. I'd rather fix this so chromium can be added to testing and stable. > How can we ensure that testing continues to be updated during > freeze time ? This one is really not fixable without a second > distribution. I know it's also the most problematic aspect for the release > team because you fear that it will make people care less about getting a > stable release out of the door. I think this fear is not completely > justified, people that do not care do not need an excuse to not care, they > already do it (unfortunately). I think this is completely the wrong question, we'd better ask the question: Why do freezes have to take that long? I do think it's completely wrong to have the people causing the long freezes benefit from another suite which fits better with not really caring about stable, I'd rather have some peer pressure to have a constantly usable testing which can be released fast (aka without a long freeze being necessary). I do think having snapshots could help with that goal. >> Regarding the snapshots, I think that unless they are not frequent (aka >> one about every 6 months) we'd better spend our energy on more frequent >> d-i releases and just promote the use of testing more. If the snapshots >> would not be frequent they could probably help the general release >> process, be a better service to many users and maybe even help to solve >> the problems we have with clamav and chromium related packages. > > Why would non-frequent snapshots help more than frequent snapshots? Because in that case they could really be used and supported for installing, better user testing, security... > Why do you believe that those snapshots would not be d-i releases in some > ways? Because now it's really hard to have frequent d-i releases aka having two during a current release cycle is about the norm. It's also not that easy to get a d-i release as it needs quite some coordination regarding transitions (which affect d-i) and d-i package uploads. Going from 2 to 8 or more looks impossible to me, while having about 4 should be doable and not cause too much coordination problems. > Personally I would like to have snapshots every 2 or 3 months. Colin > Watson pointed out in an LWN comment (http://lwn.net/Articles/406597/): > | There's a good chance that CUT could serve a dual purpose of making it > | easier to prepare new stable releases. As many projects have found, if you > | have more-or-less releaseable checkpoints every so often then it's easier > | to prepare a better-than-usual one for your gold release. s/2 or 3 months/6 months/ and I'm with you on this. > And I agree with him in general. By officially endorsing a constantly > usable rolling distribution, it's clear to everybody that what go
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Luk, On 26/09/10 at 15:55 +0200, Luk Claes wrote: > I think this is completely the wrong question, we'd better ask the > question: Why do freezes have to take that long? I would be interested in hearing your answer to that question. It would help to understand the rest of your mail. It seems to me that given our quality objectives and the fact that Debian is mostly developed by volunteer developers, it's difficult to do much better than we currently do regarding duration of freezes. > I do think it's completely wrong to have the people causing the long > freezes benefit from another suite which fits better with not really > caring about stable, I'd rather have some peer pressure to have a > constantly usable testing which can be released fast (aka without a > long freeze being necessary). To me, it looks like almost everybody in Debian is causing long freezes, not a specific subset of the DDs. But you seem to disagree? > I do think having snapshots could help with that goal. I don't see how. Could you elaborate? (Just to clarify, because my mail could be understood differently: I'm honestly very much interested in hearing your RM's opinion on this topic) - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926144018.ga28...@xanadu.blop.info
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hey, On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes wrote: > IMHO, what is missing from rolling should be added to testing, not > worked around by introducing another suite: I believe it's the other way around, actually. To me, adding stuff to testing is the workaround. Testing is not meant to be used like a rolling release distribution, as it is based on a set of constraints which do not have anything to do with rolling releases and constantly reasonably up-to-date distributions. And that's why it rears its ugly head (generally by freeze time) for users which were expecting it to be a rolling-like distribution. >> How can we ensure that testing always contains a stable version of >> chromium ? The current decision of keeping it out of testing was right >> given our actual constraints on what's ok for a stable release. >> I would argue that we need to redefine our criteria for a stable release >> and I plan to have this discussion at some point but I think in the mean >> time having rolling is good way to fix this. > > I'd rather fix this so chromium can be added to testing and stable. And how can that be done? Chromium can't go into stable, so it must be removed from testing as the product of testing is stable. People have suggested backports and volatile, but I see those solutions as an afterthought. >> How can we ensure that testing continues to be updated during >> freeze time ? This one is really not fixable without a second >> distribution. I know it's also the most problematic aspect for the release >> team because you fear that it will make people care less about getting a >> stable release out of the door. I think this fear is not completely >> justified, people that do not care do not need an excuse to not care, they >> already do it (unfortunately). > > I think this is completely the wrong question, we'd better ask the > question: Why do freezes have to take that long? I do think it's > completely wrong to have the people causing the long freezes benefit > from another suite which fits better with not really caring about > stable, I'd rather have some peer pressure to have a constantly usable > testing which can be released fast (aka without a long freeze being > necessary). I do think having snapshots could help with that goal. I agree that having much shorter freezes would make the situation a lot better and I do believe that snapshots could provide some sort of quality assurance that would help shorten freezes. This does not solve the other issues with using testing the way many people use it nowadays. >> Why would non-frequent snapshots help more than frequent snapshots? > > Because in that case they could really be used and supported for > installing, better user testing, security... I think it kind of depends on how the CUT team plans to assure some level of quality to the snapshots. If it's just about automated testing and minimal user intervention (as hinted in the BoF video), I don't see why non-frequent snapshots would be a requirement. > Right, though I don't see the need for rolling in this situation unless > we want to keep long freezes and half baked solutions for difficult to > support packages. I'd rather have these issues fixed than worked > around... and I hope many people support that? Testing or unstable only exist to support stable. Stable is the final product, testing and unstable are byproducts which people aren't supposed to use unless they're trying to improve the next stable in some way. I think what the CUT team is trying to achieve is to make testing or the rolling suite a first-class citizen and I really like that idea. I'm under the impression that some (most?) developers care at least as much about testing and unstable as they care about stable, as they use testing or unstable on a daily basis in their machines. Some may be afraid that a rolling release model would mean some maintainers aren't going to care about stable anymore. I think this is a valid point, but preventing maintainers from working on what they care about doesn't seem right and might actually stray maintainers away from the project. Who knows, maybe having a rolling suite would even allow us to "unfork" some Debian derivatives. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik81b7l5l8bbivub=5sopzw8-fcm3zhxlygw...@mail.gmail.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/26/2010 04:40 PM, Lucas Nussbaum wrote: > Hi Luk, Hi Lucas Note that this is my personal opinion and does not represent the opinion of the Release Team perse. > On 26/09/10 at 15:55 +0200, Luk Claes wrote: >> I think this is completely the wrong question, we'd better ask the >> question: Why do freezes have to take that long? > > I would be interested in hearing your answer to that question. It would > help to understand the rest of your mail. It seems to me that given our > quality objectives and the fact that Debian is mostly developed by > volunteer developers, it's difficult to do much better than we currently > do regarding duration of freezes. Of course there are multiple reasons. Though I think one of the most obvious ones is that we as a project don't do a genuine stable release often so sometimes delay the freeze willingly or not. Another reason IMHO is that instead of working together and sharing the responsability for a release we often tend to do the opposite: by not having clear and timely communication on one hand and by trying to get the latest and greatest last minute at the other hand. I think we as Release Team should work on having better communication with the project on timings of freezes and on why and how some decisions are made. I also think we should evolve to having more responsability to packaging teams and maintainers to choose the versions they want to help support for a longer time. On the other hand I hope packagers could refrain from trying to have last minute changes and help on fixing the remaining issues faster. >> I do think it's completely wrong to have the people causing the long >> freezes benefit from another suite which fits better with not really >> caring about stable, I'd rather have some peer pressure to have a >> constantly usable testing which can be released fast (aka without a >> long freeze being necessary). > > To me, it looks like almost everybody in Debian is causing long freezes, > not a specific subset of the DDs. But you seem to disagree? No, I surely cannot disagree atm. Though I do not want to promote another suite which in effect shifts the attention even more from the testing suite. >> I do think having snapshots could help with that goal. > > I don't see how. Could you elaborate? snapshots can be mini releases so they could help in having everyone more familiar with releases and could hopefully help in making communication, coordination and cooperation on releases easier. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9f612c.4080...@debian.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/26/2010 05:02 PM, Fernando Lemos wrote: > On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes wrote: >>> Why would non-frequent snapshots help more than frequent snapshots? >> >> Because in that case they could really be used and supported for >> installing, better user testing, security... > > I think it kind of depends on how the CUT team plans to assure some > level of quality to the snapshots. If it's just about automated > testing and minimal user intervention (as hinted in the BoF video), I > don't see why non-frequent snapshots would be a requirement. Right, though I'd rather see them as a kind of mini releases instead. >> Right, though I don't see the need for rolling in this situation unless >> we want to keep long freezes and half baked solutions for difficult to >> support packages. I'd rather have these issues fixed than worked >> around... and I hope many people support that? > > Testing or unstable only exist to support stable. Stable is the final > product, testing and unstable are byproducts which people aren't > supposed to use unless they're trying to improve the next stable in > some way. I think what the CUT team is trying to achieve is to make > testing or the rolling suite a first-class citizen and I really like > that idea. Right, though I'd rather have testing usable all the time than having an extra suite which will cause an extra burden on maintainers while not helping to have smoother releases. So I'd rather have the best of both than both under expectations. > I'm under the impression that some (most?) developers care at least as > much about testing and unstable as they care about stable, as they use > testing or unstable on a daily basis in their machines. Some may be > afraid that a rolling release model would mean some maintainers aren't > going to care about stable anymore. I think this is a valid point, but > preventing maintainers from working on what they care about doesn't > seem right and might actually stray maintainers away from the project. I'm not against having a constant useable testing, on the contrary. I just don't see why we want to choose for working around the problems we currently have with testing instead of fixing them for everyone. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9f6410.6070...@debian.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Luk, thanks for your valuable comments. On Sun, 26 Sep 2010, Luk Claes wrote: > Of course there are multiple reasons. Though I think one of the most > obvious ones is that we as a project don't do a genuine stable release > often so sometimes delay the freeze willingly or not. Another reason > IMHO is that instead of working together and sharing the responsability > for a release we often tend to do the opposite: by not having clear and > timely communication on one hand and by trying to get the latest and > greatest last minute at the other hand. I think that having an official "rolling" release always available would reduce the pressure of maintainers to always push the latest into the next stable release precisely because there's an alternative... so it would rather help concerning this point. We can surely do better in terms of length of freeze and better communication is surely important in the whole picture. "Not having rolling" does not seem something that will help. I can understand the fear but IMO it's not based on anything concrete. > I think we as Release Team should work on having better communication > with the project on timings of freezes and on why and how some decisions > are made. I also think we should evolve to having more responsability to > packaging teams and maintainers to choose the versions they want to help > support for a longer time. Full ack. > On the other hand I hope packagers could refrain from trying to have > last minute changes and help on fixing the remaining issues faster. Fixing remaining issues is a general QA problem. We must do more prevention so that unmaintained packages are not discovered only during freeze when it's too late but way sooner. Again it's unrelated to the existence of rolling, the problem is inactive maintainer not taking care of their packages and those are not the same that would actively push their packages to rolling. Those maintainers have package that have not migrated to testing for a long time usually. > No, I surely cannot disagree atm. Though I do not want to promote > another suite which in effect shifts the attention even more from the > testing suite. This fear is unjustified. The consequences are much more complicated than this. It might attract more contributors from derivatives which would benefic for the general quality and thus the freeze time. Or it might mean more users who discover the RC bugs quicker than we're doing right now with testing... etc. I can understand your fear but I think it's wrong to be opposed to the rolling idea on the sole ground that it might meant less people caring about a stable release. Of course, we must design rolling in a way that it supports testing and vice-versa. In the mid-long term, they might merge again but right now it's easier to start with a new release where we can experiment a bit rather than push important changes to the current release process. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100926184008.gi22...@rivendell.home.ouaza.com
Re: Buildd & binary-indep
Am Sonntag, den 26.09.2010, 08:50 + schrieb Philipp Kern: > On 2010-09-26, Reinhard Tartler wrote: > > On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote: > >> No, it builds all the content for arch:all and non-arch:all, but only > >> creates the non-arch:all binaries. The issue is that there's currently > >> no way for the buildds to say "Only build the non-arch:all content" > >> since the only required build target is "build". > > what's the problem with requiring the binary-arch target for all > > packages in debian after squeeze release? > > That's already required. What's not required (yet?) is a build target that > only builds arch:any or arch:all. Let me rephrase Reinhard: what's the problem with requiring the build-arch and build-indep target for all packages in debian after squeeze release? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#598044: ITP: autoconf-dickey -- automatic configure script builder (Thomas Dickey's version)
>>> Yet another autoconf version, as if the four that we already have in the >>> archive weren't enough. :-( But it is needed for ncurses if we ever >>> need to patch configure.in, see #580190. >> And its not possible to fixup the idiot who uses an own autoconf >> version? > Considering that his dispute with the GNU Autoconf maintainers > originates in the last millennium and he's been maintaining his patches > for twelve years or so, the answer is: no, that is not possible. *sigh* >> Or if that doesn't work, replace the shit in his source by something that >> works with all the lot we already have? > Given that > - Thomas makes extensive use of the features that he introduced in > his patched autoconf version and that were rejected by the GNU > maintainers; > - his fork is based on a very old autoconf version (2.52) that we don't > have, and I have no idea what would break if we patch out the > incompatible macros and use either autoconf2.59 or autoconf2.13; > - ncurses' configure.in changes very frequently (patches for ncurses are > released weekly, and about every second-third patch touches > configure.in); > this would be a maintenance nightmare. An autoconf wizard that wants to > tackle this task is welcome to join the ncurses team and try, but I'm > not going to do that. That hypothetical wizard should also have a look > at xterm, lynx-cur and possibly other packages that are maintained by > Thomas Dickey to bring them in line with Policy §2.2.1. Sounds like a task to get rid of software from that guy wouldnt be all to bad one. Ohwell. -- bye, Joerg SUSE = Soll Unix Sein, Eigentlich. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5gg1cq2@gkar.ganneff.de
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Raphael On 09/26/2010 08:40 PM, Raphael Hertzog wrote: > On Sun, 26 Sep 2010, Luk Claes wrote: >> Of course there are multiple reasons. Though I think one of the most >> obvious ones is that we as a project don't do a genuine stable release >> often so sometimes delay the freeze willingly or not. Another reason >> IMHO is that instead of working together and sharing the responsability >> for a release we often tend to do the opposite: by not having clear and >> timely communication on one hand and by trying to get the latest and >> greatest last minute at the other hand. > > I think that having an official "rolling" release always available would > reduce the pressure of maintainers to always push the latest into the next > stable release precisely because there's an alternative... so it would > rather help concerning this point. We do already have experimental. >> On the other hand I hope packagers could refrain from trying to have >> last minute changes and help on fixing the remaining issues faster. > > Fixing remaining issues is a general QA problem. We must do more > prevention so that unmaintained packages are not discovered only during > freeze when it's too late but way sooner. Indeed, so I'm not arguing against having more testing of testing with snapshots. > Again it's unrelated to the existence of rolling, the problem is inactive > maintainer not taking care of their packages and those are not the same > that would actively push their packages to rolling. What do you base this on? It does not at all seem clear to me that rolling would not introduce maintainers who only care about rolling. > Those maintainers have package that have not migrated to testing for a > long time usually. Right, though inactive maintainers are not usually the problem as they can be worked around (NMU). >> No, I surely cannot disagree atm. Though I do not want to promote >> another suite which in effect shifts the attention even more from the >> testing suite. > > This fear is unjustified. The consequences are much more complicated than > this. It might attract more contributors from derivatives which would > benefic for the general quality and thus the freeze time. Or it might > mean more users who discover the RC bugs quicker than we're doing right > now with testing... etc. It might also attract more users that file bugs that are already fixed or that were never in unstable nor testing. I still fail to see why the problems with testing have to be worked around at instead of be fixed properly. > I can understand your fear but I think it's wrong to be opposed to the > rolling idea on the sole ground that it might meant less people caring > about a stable release. It's not only that, but also the fear that the problems we do have with testing will stay instead of getting fixed properly... I think it's great to have discussion about the issues and even about possible solutions, though I don't think we should try to be hasty nor introduce extra suites to work around issues we are having with suites we have today. > Of course, we must design rolling in a way that it supports testing and > vice-versa. In the mid-long term, they might merge again but right now > it's easier to start with a new release where we can experiment a bit > rather than push important changes to the current release process. Are you talking about introducing rolling during the current freeze? I think that would only prove my point that it shifts attention away from testing... Besides we still need to fix the current issue we have with chromium and similar packages before the release... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9fb29b.2070...@debian.org
Re: Buildd & binary-indep
On 09/26/2010 03:45 PM, Joachim Breitner wrote: > Am Sonntag, den 26.09.2010, 08:50 + schrieb Philipp Kern: >> On 2010-09-26, Reinhard Tartler wrote: >>> On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote: No, it builds all the content for arch:all and non-arch:all, but only creates the non-arch:all binaries. The issue is that there's currently no way for the buildds to say "Only build the non-arch:all content" since the only required build target is "build". >>> what's the problem with requiring the binary-arch target for all >>> packages in debian after squeeze release? >> >> That's already required. What's not required (yet?) is a build target that >> only builds arch:any or arch:all. > > Let me rephrase Reinhard: > what's the problem with requiring the build-arch and build-indep target > for all packages in debian after squeeze release? Lucas did (in 2007) an archive rebuild with a patched dpkg to call build-arch instead of build when -B is passed. He posted the results in bug #229357. Relevant part: > Of those 1823 packages, 31 packages failed to build. Unfortunately, the logs are no longer available so it's not possible to know which packages failed to build (unless Lucas still has them somewhere?). -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
