Re: Introducing Build-Recommends / Build-Core-Depends?
Kyle Willmon writes (Re: Introducing Build-Recommends / Build-Core-Depends?): So, if you think it's ok to leave out the words Depends and Recommends, the logical idea would be to use Build-Stage1 (though I do not think this is the correct route. I, personally, am in favor of Build-Depends-Stage1) Sorry to join the bikeshed discussion, but: AIUI there are packages which need three build stages to bootstrap. So the field name ought to have a number 1 so that those packages can have 2. Ian. -- 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/20090.2201.569800.902...@chiark.greenend.org.uk
Re: Introducing Build-Recommends / Build-Core-Depends?
Hi there, On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: Introducing Build-Recommends / Build-Core-Depends We should be able to specify in the package saying only these build-dependencies are needed to get a functionally working package. For such an build, the packages which are not needed for building working core packages are annoted in an additional header (e.g. Build-Recommends), but are still specified in Build-Depends to not break the old tools. Optionally, we could introduce Build-Core-Depends which only has the minimum set of build-dependencies the package needs. Technically, that's not that large a difference but just a different way of writing it down. Build-Recommends is a bad name for this for two reasons: 1) Since Build-Depends would still contain the full set of build-dependencies for compatibility with existing tools, the buildds would have to calculate the *difference* between Build-Recommends and Build-Depends to determine which packages need to be installed for a bootstrapping build. It's better to just declare outright which dependencies should be used for the bootstrap (which is likely to be a small and rarely changing set, easier for the maintainer to keep track of anyway). 2) The name implies a *choice* about whether to use these packages when building - leading inevitably to the sorts of discussions we've already seen in this thread about extending this into an equivalent of Gentoo USE flags. We do *not* want that kind of unmaintanable stew; we should use this interface solely for bootstrapping, and the field names should suggest this. So Build-Core-Depends would certainly be a better approach, but I wonder why this isn't being called Build-Depends-Stage1 or similar? I know that has been discussed in the recent past. Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed (so we could do an automated graph analyis, and also dh and cdbs could just drop them, so that debian/rules doesn't need to reflect the dependencies); however, any package in an binary packages build-depends needs to be part of the source package build-depends-line so that just downloading all build-depends does the right thing (as of now). Packages with no additional Build-Depends specified can be built with the minimum set installed. Per-binary-package build-depends would be very inelegant. They're only useful if the parts requiring additional bootstrapping are split into separate binary packages, and as we know that won't always be the case, this adds very little to the design. I don't think that debian/rules should be silently discarding binary packages based on what build-dependencies are installed anyway - that would certainly break the behavior of dpkg-buildpackage -d, for one thing. Can you elaborate on how you see this helping with automated graph analysis? If the goal is to get the entire archive bootstrapped, which I assume it is, then the mere existence of a Build-Depends-Stage1 field is sufficient to tell us everything we need to know about bootstrapping order. (If it isn't, then that implies we actually need a Build-Depends-Stage2 as well. I understand no one has found such a case of nested build-dependency loops yet, so we should probably just ignore this possibility; but if you think this is a real risk, all the more reason to use Stage1 notation which is extensible in the obvious way.) Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. This is the signal for dpkg-buildpackage etc to only check for the minimal set of packages, and for the debian/rules to accept if some functionality is missing (i.e. might require changes to usage of ./configure). s/norecommends/stage1/ :) (Buildds should do it in a way that they first check if however all recommends are available, and only failing that setting the header - makes it more likely we get full packages early; but that's an implementation sidenote). Full ack... Resulting packages All binary packages built need to be functionally working, and follow the standard for packages on ftp-master. This means they could e.g. miss documentation (as long as they are not RC-buggy, i.e. they need to have changelog and copyright), and that it might be that not all binary packages are built (e.g. via the Build-Dependency-mechanimsn in debian/control above). Often cutting off documentation and graphical packages is enough for a minimal version. Why is it important that these packages follow the standards for packages on ftp-master? Do you intend to have such packages published to the main archive? Wouldn't it be better to stow bootstrap packages in a separate archive that's only used by the buildds? (In which case, do we really care about trying to set explicit policy
Re: Introducing Build-Recommends / Build-Core-Depends?
On Mon, Sep 12, 2011 at 03:36:46PM +0100, Steve Langasek wrote: On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: Introducing Build-Recommends / Build-Core-Depends Build-Recommends is a bad name for this for two reasons: [...] So Build-Core-Depends would certainly be a better approach, but I wonder why this isn't being called Build-Depends-Stage1 or similar? What about Build-Minimal? Shorter. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: Introducing Build-Recommends / Build-Core-Depends?
On Mon, Sep 12, 2011 at 10:57:10PM +0200, Adam Borowski wrote: On Mon, Sep 12, 2011 at 03:36:46PM +0100, Steve Langasek wrote: So Build-Core-Depends would certainly be a better approach, but I wonder why this isn't being called Build-Depends-Stage1 or similar? What about Build-Minimal? Shorter. Build-Minimal doesn't capture the fact that we are talking about dependencies. Build-Depends-Minimal would work, but is not actually shorter than Build-Depends-Stage1 and it is also not specific to bootstrapping which was an argument Steve made against many other suggestions. So, if you think it's ok to leave out the words Depends and Recommends, the logical idea would be to use Build-Stage1 (though I do not think this is the correct route. I, personally, am in favor of Build-Depends-Stage1) Thanks - Kyle Willmon -- 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/20110912221812.ga31...@mail.tuxags.com
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sun, 14 Aug 2011 17:54:55 -0500 Peter Samuelson pe...@p12n.org wrote: [Andreas Barth] Introducing Build-Recommends / Build-Core-Depends We should be able to specify in the package saying only these build-dependencies are needed to get a functionally working package. For such an build, the packages which are not needed for building working core packages are annoted in an additional header (e.g. Build-Recommends), but are still specified in Build-Depends to not break the old tools. I think I really prefer the option of doing per-binary-package Build-Depends. That doesn't break build-dependency loops. The whole point is that when bootstrapping a new architecture, certain packages must be built in a restricted mode which is *not* uploaded to the main archive but which provides sufficient support to build the other side of the dependency loop. Packages are then rebuilt when all it's build-dependencies are ready. Please lookup the link provided by Andreas to Wookey's talk at DebConf11. Why is a separate field needed at the source package level? Please read the original post in this thread again. This is not about how packages are split in the archive. This is not about per-binary. This is source:binary dependency loops when bootstrapping (or cross-building) and entire set of packages from scratch. It is implied by the existence of at least one Build-Depends field at the binary package level. The only reason you'd need a separate field is if you're talking about building two different variants of a single _binary_ package. Is that really useful? The variant is installed locally so that the packages which depend on it can be built. Then the original package can be rebuilt when it's build dependencies exist, along with packages which were built against (or using) the interim version. This can all be done but it involves making manual changes in various packages to allow for the variant build. It is sign at least in many cases that it may be useful to split the binary packages further. (And, come to think of it, for build deps like docbook processors, we already have Build-Depends-Indep. I wonder if we're using it everywhere we should be.) It's not just about documentation - that could be handled by DEB_BUILD_OPTIONS=nodocs as Build-Depends-Indep is the opposite. It's not about building just the architecture-independent bits, it's about building the architecture-dependent stuff when the build-dependencies have not yet been built. (Often because those build-dependencies themselves have runtime dependencies on the library which is being built - and therefore cannot be installed - and the library uses those binaries to as part of it's build. Classic dependency:build-dependency loop which makes bootstrapping impossible without changes in the package(s).) Source: libfoo Build-Depends: bar Package: libfoo3 Package: libfoo-bin Source: bar Package: bar Depends: libfoo-bin Other examples include poppler:cups:poppler:cups which doesn't involve documentation at all - see Wookey's talk at DebConf11 for all the gory detail. (Link in Andreas' original post.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp85vvhJ5bxt.pgp Description: PGP signature
Re: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
Eugene V. Lyubimkin wrote: If we accept the idea there's now more than one way to build the package, I would like us do not limit the number of ways to '2' but rather extend the prospoal to set up something similar to Gentoo's USE flags. The advantages of that idea: - porters/buildds/local administrators will have the greater flexibility to choose what the want to (re)build; - for the architecture bootstrap this could be used for packages that need to be rebuilt more than once with growing set of features build-by-build (don't know if such packages exist). The disadvantage is obvious: harder to implement. I imagine it to look something like: Source: fbreader Build-Depends-Core: debhelper (= 7), libbz2-dev Build-Depends-Qt3: libqt3-mt-dev Build-Depends-Qt4: libqt4-dev Build-Depends-Gtk2: libgtk2.0-dev Like in the original proposal, sets of build-depends are to be chosen by DEB_BUILD_OPTIONS, for example DEB_BUILD_OPTIONS=use=gtk2,qt4. In absence of 'use' flag (i.e. by default), all 'optional' packages are built. And like in the original proposal, there's a header in the resulting .changes (and possibly in something else) which determines what was the value of the 'use' flag when building, like Built-With: gtk2,qt4. For the compatibility, dpkg-genchanges would combine all Build-Depends-* to a single Build-Depends. I can see this turning into a large mess. What's the benefit for Debian for all the extra work here? If you want massively differing builds on every machine, Gentoo exists already... -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- 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/e1qsu6z-0001ot...@mail.einval.com
Re: Introducing Build-Recommends / Build-Core-Depends?
Andreas Barth wrote: * Colin Watson (cjwat...@debian.org) [110813 15:27]: On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have misspelled this slightly), and for a bootstrap-aware autobuilder to build its way through each of the stages until it reaches the real Build-Depends. I personally prefer this approach because it makes it clearer that the final build-depends is what we really want to reach, and that binaries uploaded to the real Debian archive still need to have all those build-dependencies in place. Wookeys proposal is less generic and more centric to bootstrapping. Which has its advantages, and its disadvantages. I'm not saying that this proposal is better. It is different, and has a different set of advantages. Plusside is that it's more generic, so you could do more with debian/control fields, debhelper and cdbs, and less with specific additions to debian/rules. Generic options are usually better IMHO, but well - YMMV. Often, yes. But also often at extra cost. Where is the added benefit here - i.e. what are the use cases? I'm 100% behind making the bootstrap phase more simple, but I can't see many others... Also, Build-Recommends is an atrocious name. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- 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/e1qsu9s-0001w7...@mail.einval.com
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-13 13:28 +0200]: Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed ... An optional Build-Depends: field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. How do I build foo-stage1, but not foo-stage2? With a binary option like the above, it does not seem to be possible, unless dpkg-buildpackage decides based on the installed packages which packages it builds. Doing so might require using equivs if in early bootstrapping stages a part of the build dependencies is manually compiled instead of installed via dpkg, and it might waste time if dpkg-buildpackage decides to build a large binary package that is not needed yet. The most obvious ways to specify which packages should be build seem to be mybikeisred=[foo-stage1,...] added to the environment DEB_BUILD_OPTIONS or a new optional environment variable DEB_BUILD_PACKAGES which would contains a comma separated list of to be built packages and an additional make target binary-pkg-foo-stage1 in debian/rules. To prevent building packages needed for bootstrapping only by default, a new field in the source package's paragraph of the control file could be used, e.g., NotBuiltByDefault: foo-stage1, foo-stage2. Not adding such a field to the binary package's paragraph instead has the same reason as described at the beginning of my mail. Regards Carsten -- 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/20110815113559.ga14...@furrball.stateful.de
Re: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
* Steve McIntyre (st...@einval.com) [110815 12:27]: Eugene V. Lyubimkin wrote: Source: fbreader Build-Depends-Core: debhelper (= 7), libbz2-dev Build-Depends-Qt3: libqt3-mt-dev Build-Depends-Qt4: libqt4-dev Build-Depends-Gtk2: libgtk2.0-dev I can see this turning into a large mess. What's the benefit for Debian for all the extra work here? If you want massively differing builds on every machine, Gentoo exists already... Ack. Andi -- 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/20110815113943.gx15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Steve McIntyre (st...@einval.com) [110815 12:30]: Andreas Barth wrote: Generic options are usually better IMHO, but well - YMMV. Often, yes. But also often at extra cost. No doubt about that. Where is the added benefit here - i.e. what are the use cases? I'm not sure I could speak about cases, but an obvious use case aside from bootstrapping is backporting, where I could just drop off dependencies I'm not going to use instead of looking at the code and figuring out if it's easier to backport yet another library or change the code. Just because I know that removing dependencies not in Build-Core-Depends will just work. Also, Build-Recommends is an atrocious name. :-) Names are only names ;) Andi -- 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/20110815114220.gy15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Steve McIntyre [2011-08-15 11:12 +0100]: Andreas Barth wrote: Generic options are usually better IMHO, but well - YMMV. Often, yes. But also often at extra cost. Where is the added benefit here - i.e. what are the use cases? I'm 100% behind making the bootstrap phase more simple, but I can't see many others... Backporting a subset of the binary packages in a source package is one, e.g., I might want to run the latest emacs23-nox on a server, but not emacs23. Regards Carsten -- 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/20110815114258.gb14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Carsten Hey (cars...@debian.org) [110815 13:36]: An optional Build-Depends: field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev No, it's not. There is an really large difference: This here means the maintainer needs to write down by hand what the path to build the package is. My proposal just documents dependencies, and let the rest to be done by graph checkers. That means way more documented. That is the core difference. It does only by hand what needs to be done by hand, and writing up the path bit by bit isn't. Andi -- 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/20110815114621.gz15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-15 13:46 +0200]: * Carsten Hey (cars...@debian.org) [110815 13:36]: An optional Build-Depends: field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev No, it's not. There is an really large difference: This here means the maintainer needs to write down by hand what the path to build the package is. There seems to be a misunderstanding, caused by choosing an unfortunate example, here is an other one: Source: emacs23 Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev If necessary, debhelper could ensure that the binary packages's dependencies are included in the Build-Depends line. apt-cache showsrc emacs23 currently displays something similar to: Package: emacs23 Binary: emacs, emacs23-lucid, emacs23-nox, emacs23, ... ... Build-Depends: gnome, kde, ncurses-dev ... If per-package build dependencies are added, it could look like this with my proposal: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev ... With your proposal it would either miss information, invent yet an other syntax, or use multiple fields per source package with the same name but a different semantic: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends: ncurses-dev ... Regards Carsten -- 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/20110815123553.gc14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Carsten Hey (cars...@debian.org) [110815 14:36]: * Andreas Barth [2011-08-15 13:46 +0200]: * Carsten Hey (cars...@debian.org) [110815 13:36]: An optional Build-Depends: field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev No, it's not. There is an really large difference: This here means the maintainer needs to write down by hand what the path to build the package is. There seems to be a misunderstanding, caused by choosing an unfortunate example, here is an other one: Source: emacs23 Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev That's just re-ordering the way the entries are specified. I don't mind either way, but I'd consider it more natural to have it at the binary packages. Andi -- 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/20110815124054.gs2...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
On Mon, Aug 15, 2011 at 13:42:20 +0200, Andreas Barth wrote: I'm not sure I could speak about cases, but an obvious use case aside from bootstrapping is backporting, where I could just drop off dependencies I'm not going to use instead of looking at the code and figuring out if it's easier to backport yet another library or change the code. Just because I know that removing dependencies not in Build-Core-Depends will just work. You don't actually know that, unless you're suggesting we expand our support matrix by a few orders of magnitude to support any and all combinations of packages built with some random combination of their optional build-deps. Works enough to get to the next stage of the bootstrap isn't the same as just works. Cheers, Julien -- 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/20110815152448.gy32...@radis.liafa.jussieu.fr
Re: Introducing Build-Recommends / Build-Core-Depends?
Andreas Barth wrote: Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed (so we could do an automated graph analyis, and also dh and cdbs could just drop them, so that debian/rules doesn't need to reflect the dependencies) So there would need to be an interface in dpkg to get a list of binary packages to build. In order for this not to make debhelper slow, it would need to be a startlingly fast interface, for something that needs to read the status file. :/ Or DEB_BUILD_OPTIONS could have something set for this case and the status file lookup avoided in the general case. debhelper would need to disable dh_install --fail-missing in this case too. Happily dh_movefiles is not used by default, as if some packages are not built, this could result in files that were normally put in those packages instead being moved into another package. I don't think other parts of debhelper have problems if some binary packages are skipped. To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version Is package_version supposed to be a list of the packages and versions used in the minimal build? -- see shy jo signature.asc Description: Digital signature
Re: Introducing Build-Recommends / Build-Core-Depends?
* Joey Hess (jo...@debian.org) [110815 18:32]: Andreas Barth wrote: Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed (so we could do an automated graph analyis, and also dh and cdbs could just drop them, so that debian/rules doesn't need to reflect the dependencies) So there would need to be an interface in dpkg to get a list of binary packages to build. In order for this not to make debhelper slow, it would need to be a startlingly fast interface, for something that needs to read the status file. :/ Or DEB_BUILD_OPTIONS could have something set for this case and the status file lookup avoided in the general case. I'd rather consider the second case - accept a slower debhelper on partial builds. debhelper would need to disable dh_install --fail-missing in this case too. Happily dh_movefiles is not used by default, as if some packages are not built, this could result in files that were normally put in those packages instead being moved into another package. Ok - we should add that to if the maintainer enables this mechanismn, he needs to make sure that ... (and in lots of cases, that's not an issue). Does that sound ok? To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version Is package_version supposed to be a list of the packages and versions used in the minimal build? Yes. We basically have a list of such packages anyways within the buildd log these days, but adding it here wouldn't hurt. Andi -- 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/20110815173754.gb15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
Le Mon, Aug 15, 2011 at 11:12:36AM +0100, Steve McIntyre a écrit : Andreas Barth wrote: Generic options are usually better IMHO, but well - YMMV. Often, yes. But also often at extra cost. Where is the added benefit here - i.e. what are the use cases? I'm 100% behind making the bootstrap phase more simple, but I can't see many others... I think Build-Recommends would be well suited for skipping or disabling regression tests when ‘test dependancies’ are not available. With “DEB_BUILT_OPTIONS=nocheck”, the tests are skipped, but the packages needed to run the tests are still installed, which means that if they are not available, the package can not be built. Here is an example: bioperl-run contains BioPerl wrappers for common command-line tools. t-coffee contains the T-COFFEE command-line tool to align nucleotidic sequences. bioperl-run's regression tests try the wrapper for T-COFFEE, and therefore bioperl-run Build-Depends on t-coffee. t-coffee fails to build from source on armel (where its regression test fails). If t-coffee is removed from armel (where it probably never worked), bioperl-run can not be rebuilt there. This chain of build dependancies is weak, but brings the benefit of running full regression tests at build time and include the results in the build logs. I think that DEP 8 is complementary to this, but can not replace this feature in the short term. A Build-Recommends field would allow packages to be resilient to the absence of one of the components featured in their regression tests. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110816001145.ge19...@merveille.plessy.net
Re: Introducing Build-Recommends / Build-Core-Depends?
[Andreas Barth] Introducing Build-Recommends / Build-Core-Depends We should be able to specify in the package saying only these build-dependencies are needed to get a functionally working package. For such an build, the packages which are not needed for building working core packages are annoted in an additional header (e.g. Build-Recommends), but are still specified in Build-Depends to not break the old tools. I think I really prefer the option of doing per-binary-package Build-Depends. The presence of a Build-Depends field for a specific binary package already implies that if you have those specific build-deps available, you can build at least that one package. I guess the way to bootstrap would be to hold the package until you have enough build-deps to build at least one binary package from it, then do so, with some way to tell dpkg-buildpackage to not abort if the source package level build-deps are not all available. Why is a separate field needed at the source package level? It is implied by the existence of at least one Build-Depends field at the binary package level. The only reason you'd need a separate field is if you're talking about building two different variants of a single _binary_ package. Is that really useful? It is sign at least in many cases that it may be useful to split the binary packages further. (And, come to think of it, for build deps like docbook processors, we already have Build-Depends-Indep. I wonder if we're using it everywhere we should be.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20110814225455.ga7...@p12n.org
Introducing Build-Recommends / Build-Core-Depends?
Hi, During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Below is my summary of the ideas - names et all are of course just names and up to be changed. Advantage of this schema is that most implementation is just package-local - the maintainer knows which minimal versions his source package could produce, and just annotates them. Coordination between different packages is not needed so much anymore, and we could try to bring the build-dependencies more into a tree-shape. Please see e.g. http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv for the talk. Situation The usual variants of build-dependency-loops mean that the source package could still produce working binary packages, but documentation and/or additional (e.g. -x11) packages are missing. In the few cases where this is not possible, porters need to hand-hold the package anyways. This proposal would like to remove the repetative parts of bootstraping a new architecture, not the parts where the porters really need to port. A typical loop is e.g. cups needs qt, which needs poppler which needs cups to build correctly. The typical core loops only involves changing a small number of packages, however many packages are affected by the loop (e.g. any package using qt or poppler as build-depends). I'd like to have that fixed in a way that we get rid of the build-dependency-loops as far as technically possible. Upstream is usually better than we are by using ./configure and scaning which packages are there, and which not, whereas we usually depend on the full archive being already built. Introducing Build-Recommends / Build-Core-Depends We should be able to specify in the package saying only these build-dependencies are needed to get a functionally working package. For such an build, the packages which are not needed for building working core packages are annoted in an additional header (e.g. Build-Recommends), but are still specified in Build-Depends to not break the old tools. Optionally, we could introduce Build-Core-Depends which only has the minimum set of build-dependencies the package needs. Technically, that's not that large a difference but just a different way of writing it down. Also, the binary packages in the debian/control template could have Build-Depends specified which means that they should only be built if those packages are actually installed (so we could do an automated graph analyis, and also dh and cdbs could just drop them, so that debian/rules doesn't need to reflect the dependencies); however, any package in an binary packages build-depends needs to be part of the source package build-depends-line so that just downloading all build-depends does the right thing (as of now). Packages with no additional Build-Depends specified can be built with the minimum set installed. Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. This is the signal for dpkg-buildpackage etc to only check for the minimal set of packages, and for the debian/rules to accept if some functionality is missing (i.e. might require changes to usage of ./configure). (Buildds should do it in a way that they first check if however all recommends are available, and only failing that setting the header - makes it more likely we get full packages early; but that's an implementation sidenote). Resulting packages All binary packages built need to be functionally working, and follow the standard for packages on ftp-master. This means they could e.g. miss documentation (as long as they are not RC-buggy, i.e. they need to have changelog and copyright), and that it might be that not all binary packages are built (e.g. via the Build-Dependency-mechanimsn in debian/control above). Often cutting off documentation and graphical packages is enough for a minimal version. To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. Tools This affects dpkg-buildpackage, dpkg-checkbuilddeps, and dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease migration of packages to build-recommends. It would be nice if wanna-build could cope
Re: Introducing Build-Recommends / Build-Core-Depends?
On 2011-08-13, Andreas Barth a...@not.so.argh.org wrote: Introducing Build-Recommends / Build-Core-Depends I like making it easier to bootstrap new architectures, but I don't like overloading the 'recommends' word with a partly different meaning. (And since this is my biggest issue with this proposal, I think it is very good :) /Sune -- 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/slrnj4cotd.p7v.nos...@sshway.ssh.pusling.com
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sat, 13 Aug 2011 11:44:46 + (UTC) Sune Vuorela nos...@vuorela.dk wrote: On 2011-08-13, Andreas Barth a...@not.so.argh.org wrote: Introducing Build-Recommends / Build-Core-Depends I like making it easier to bootstrap new architectures, but I don't like overloading the 'recommends' word with a partly different meaning. It's not 'that' different. Recommends currently means that the majority of installations would be expected to need it. Build-Recommends means that the majority of builds would be expected to need it. Personally, I'm not sure if Build-Core-Depends is better but there does need to be a way to list particular build-dependencies as imperative and configurable, usually along the lines of what the upstream ./configure type script can disable. (And since this is my biggest issue with this proposal, I think it is very good :) Agreed. I think the idea can be extended. There isn't much point in *only* listing those packages which are directly involved in bootstrapping cycles today, this would only cause repeated cycling through the packages as the packages update their functional support. It would be useful for this proposal to be adopted by many, many packages on the basis of what can be disabled (with judicious use of the debhelper -N option and changes in debian/rules to the ./configure or equivalent support) as a form of future proofing. If your (typically library) package *can* have functionality disabled, it should be possible to use this support to build the package that way for bootstrapping purposes, whether or not anyone is aware of a problem in advance. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpOg33138G83.pgp Description: PGP signature
use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
On 2011-08-13 13:28, Andreas Barth wrote: Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. This is the signal for dpkg-buildpackage etc to only check for the minimal set of packages, and for the debian/rules to accept if some functionality is missing (i.e. might require changes to usage of ./configure). (Buildds should do it in a way that they first check if however all recommends are available, and only failing that setting the header - makes it more likely we get full packages early; but that's an implementation sidenote). This proposal effectively means there will two ways of building the package: 'core' and 'full' one. If we accept the idea there's now more than one way to build the package, I would like us do not limit the number of ways to '2' but rather extend the prospoal to set up something similar to Gentoo's USE flags. The advantages of that idea: - porters/buildds/local administrators will have the greater flexibility to choose what the want to (re)build; - for the architecture bootstrap this could be used for packages that need to be rebuilt more than once with growing set of features build-by-build (don't know if such packages exist). The disadvantage is obvious: harder to implement. I imagine it to look something like: Source: fbreader Build-Depends-Core: debhelper (= 7), libbz2-dev Build-Depends-Qt3: libqt3-mt-dev Build-Depends-Qt4: libqt4-dev Build-Depends-Gtk2: libgtk2.0-dev Like in the original proposal, sets of build-depends are to be chosen by DEB_BUILD_OPTIONS, for example DEB_BUILD_OPTIONS=use=gtk2,qt4. In absence of 'use' flag (i.e. by default), all 'optional' packages are built. And like in the original proposal, there's a header in the resulting .changes (and possibly in something else) which determines what was the value of the 'use' flag when building, like Built-With: gtk2,qt4. For the compatibility, dpkg-genchanges would combine all Build-Depends-* to a single Build-Depends. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/20110813125846.GA1656@r500-debian
Re: Introducing Build-Recommends / Build-Core-Depends?
Le Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth a écrit : We should be able to specify in the package saying only these build-dependencies are needed to get a functionally working package. For such an build, the packages which are not needed for building working core packages are annoted in an additional header (e.g. Build-Recommends), but are still specified in Build-Depends to not break the old tools. Dear Andreas and everybody, I think that Build-Recommends would be very useful also in the case of packages that run regression tests with extensive dependancies. At build time, the package could check for the availability of the recommended build dependancies, and skip the steps that need them if they are not available. With such a behaviour, it would not be needed to duplicate the information between the Build-Depends and the Build-Recomends field. The Build-Recomends field has been proposed in the past and most objections were about reproducibility of the builds. Perhaps some policy could constraint the use of Build-Recomends in order to avoid it to be misused. To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. Another possibility would be to append something like “~minimal” (or shorter) to their version number. But perhaps that would break the parsing of version number for detecting binNMUs, if +b1~minimal would not be considered so. Tools This affects dpkg-buildpackage, dpkg-checkbuilddeps, and dpkg-gencontrol. It also (should) affect debhelper and cdbs to ease migration of packages to build-recommends. mk-build-deps is inherently tolerant to missing dependancies, since it uses a combination of equivs and apt-get -f install, but on the other hands it means that it will not be able to allow to distinguish Build-Depends and Build-Recommends, as apt-get -f install does not seem to install Recommends by default. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110813130900.ga20...@merveille.plessy.net
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have misspelled this slightly), and for a bootstrap-aware autobuilder to build its way through each of the stages until it reaches the real Build-Depends. I personally prefer this approach because it makes it clearer that the final build-depends is what we really want to reach, and that binaries uploaded to the real Debian archive still need to have all those build-dependencies in place. I think Wookey indicated that there was at least one case where more than one stage is required, in which case Build-Recommends does not really seem to solve the full problem. -- Colin Watson [cjwat...@debian.org] -- 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/20110813132734.gb32...@riva.dynamic.greenend.org.uk
Re: Introducing Build-Recommends / Build-Core-Depends?
Hi, just a minor note: Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth: To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. This seems to be an unfortunate choice of a field name, as it has different semantics than other Build-Depends fields. Why not Built-With:? Also, this might be useful independently from your feature, and in all package, and is similar to what dh-buildinfo provides. 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: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
* Eugene V. Lyubimkin (jac...@debian.org) [110813 14:58]: On 2011-08-13 13:28, Andreas Barth wrote: Building with core Dependencies only If doing an build of the core functionality only, norecommends is added to the environment DEB_BUILD_OPTIONS. This is the signal for dpkg-buildpackage etc to only check for the minimal set of packages, and for the debian/rules to accept if some functionality is missing (i.e. might require changes to usage of ./configure). (Buildds should do it in a way that they first check if however all recommends are available, and only failing that setting the header - makes it more likely we get full packages early; but that's an implementation sidenote). This proposal effectively means there will two ways of building the package: 'core' and 'full' one. If we accept the idea there's now more than one way to build the package, I would like us do not limit the number of ways to '2' but rather extend the prospoal to set up something similar to Gentoo's USE flags. Eh, sorry. This proposal doesn't say there are exactly two ways, but this is the minimal set of dependencies to get at least one working binary package out and with this, you get all working binary packages. You could build with anything inbetween as well. Also, more flags are already available via DEBBUILDOPTIONS like nodocs. However, we should make sure that we consistently get what we want for the main archive. So (except during bootstrapping time) buildds should run with the default options. Andi -- 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/20110813141234.gt15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Colin Watson (cjwat...@debian.org) [110813 15:27]: On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have misspelled this slightly), and for a bootstrap-aware autobuilder to build its way through each of the stages until it reaches the real Build-Depends. I personally prefer this approach because it makes it clearer that the final build-depends is what we really want to reach, and that binaries uploaded to the real Debian archive still need to have all those build-dependencies in place. Wookeys proposal is less generic and more centric to bootstrapping. Which has its advantages, and its disadvantages. I'm not saying that this proposal is better. It is different, and has a different set of advantages. Plusside is that it's more generic, so you could do more with debian/control fields, debhelper and cdbs, and less with specific additions to debian/rules. Generic options are usually better IMHO, but well - YMMV. I think Wookey indicated that there was at least one case where more than one stage is required, in which case Build-Recommends does not really seem to solve the full problem. As long as all stages produces binary packages which are policy conformant working, it does. Consider this case: Source: A Build-Depends: b, c Build-Core-Depends: Binary: a1 Binary: a2, build-depends b Binary: a3, build-depends c Source: B Build-Depends: a1 Binary: b Source: C Build-Depends: a2 Binary: c In this case, the first run on A will only produce a1. Then B could be built, then re-build A with what is available now. This will produce a1 and a2. Then build C. Then re-build A with all Build-Depends installed, which will give us a full package set. Andi -- 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/20110813142328.gu15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Joachim Breitner (nome...@debian.org) [110813 16:05]: Hi, just a minor note: Am Samstag, den 13.08.2011, 13:28 +0200 schrieb Andreas Barth: To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. This seems to be an unfortunate choice of a field name, as it has different semantics than other Build-Depends fields. Why not Built-With:? As said - names are just names now, and I assume them to change till implementation. (But if, I think Build-With is better.) Also, this might be useful independently from your feature, and in all package, and is similar to what dh-buildinfo provides. My proposal isn't restricted to the package required to bootstrapping. However, if they make bootstrapping way easier, that's the use case why we should invest the effort. I see more usage in other areas than only bootstrapping; that's the reason why I tried to make it a bit more generic. Andi -- 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/20110813142636.gv15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
Hi! On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote: During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Below is my summary of the ideas - names et all are of course just names and up to be changed. Advantage of this schema is that most implementation is just package-local - the maintainer knows which minimal versions his source package could produce, and just annotates them. Coordination between different packages is not needed so much anymore, and we could try to bring the build-dependencies more into a tree-shape. Please see e.g. http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv for the talk. During the Extremadura Embedded meeting in 2006 we discussed too these things, and I came up with the following proposals, which should be generic enough not only for bootstrapping but also for embedded type of reduced builds: http://www.hadrons.org/~guillem/debian/docs/embedded.proposal regards, guillem -- 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/20110813144839.ga5...@gaara.hadrons.org
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sat, 13 Aug 2011, Andreas Barth wrote: Resulting packages All binary packages built need to be functionally working, and follow the standard for packages on ftp-master. This means they could e.g. miss documentation (as long as they are not RC-buggy, i.e. they need to have changelog and copyright), and that it might be that not all binary packages are built (e.g. via the Build-Dependency-mechanimsn in debian/control above). Often cutting off documentation and graphical packages is enough for a minimal version. To mark such packages and to be able to decide when to re-schedule the build, all binary-packages get the additional header Build-Depends: minmal package_version injected, so that one could see later on that this was a partial build and reschedule a new build when newly upcoming packages allow more binary packages to be built, or all build-dependencies are available and we could do a clean full build. The resulting packages MUST NOT lack any files or symbols/modules that would be noticed by packages that depend on it. Otherwise, we might have unexpected (and untracked!) partial functionality down the dependecy graph. Alternatively, we can annotate all packages that depend on this one for rebuilding. This is entirely doable, but it may require an extremely large number of rebuilds (entire trees might need to be rebuilt a number of times) even if you do intelligent partitioning of the rebuild set. I actually prefer the second alternative, because it is entirely non-trivial to know that you're missing a symbol or file that could be used by some other package (especially if such packages do something weird). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110813150941.ga32...@khazad-dum.debian.net
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sat, 13 Aug 2011 16:48:39 +0200 Guillem Jover guil...@debian.org wrote: On Sat, 2011-08-13 at 13:28:36 +0200, Andreas Barth wrote: During bootstraping a new architecture, there are sometimes ugly build-dependency-loops (usually involving generating documentation for the core build utilities means you need to have the architecture already available; same with graphical tools). During DebConf, Wookey had a talk which lead to us discussing some ideas how to support that. Most packages are not affected at all by that, and current behaviour isn't changing as long as package source files are not changed. Below is my summary of the ideas - names et all are of course just names and up to be changed. Advantage of this schema is that most implementation is just package-local - the maintainer knows which minimal versions his source package could produce, and just annotates them. Coordination between different packages is not needed so much anymore, and we could try to bring the build-dependencies more into a tree-shape. Please see e.g. http://meetings-archive.debian.net/pub/debian-meetings/2011/debconf11/low/745_Bootstrapable_Debian.ogv for the talk. During the Extremadura Embedded meeting in 2006 we discussed too these things, and I came up with the following proposals, which should be generic enough not only for bootstrapping but also for embedded type of reduced builds: http://www.hadrons.org/~guillem/debian/docs/embedded.proposal Sounds like we need an Emdebian / FTP / Dpkg sprint in 2011/2012 to finally decide on one of the many ideas, get it *implemented* and stop going around the same loop with different names but the same objective. There's nothing intrinsically wrong with the 2006 proposal, just like there isn't that much wrong with Wookey's DebConf11 proposal and Andreas' current nomenclature in this thread. Can we please stop discussing / painting the bike shed, get together and fix this for Wheezy? It's an ideal time when so many libraries are being refreshed for MultiArch and the revolution in cross-building which MultiArch itself can provide. (Note: there won't be any point in a sprint unless Guillem Raphael are able to attend and this would also give a chance to sort out the TDeb stalemate at the same time.) Guillem - at DebConf11, our DPL pushed for more sprints. All that's needed is the date of a long weekend which you and Raphael can be in the same place. The venue will presumably be somewhere in France / western Europe. Steve McIntyre Neil McGovern stepped forward to organise the event itself. All the team need is a date when you, Guillem, Raphael are both available. Just don't schedule it over the weekend of Steve McIntyre's wedding (Sept 10th) or I will be in BIG trouble. ;-) (Something in late October / November this year anyone?) It'll be REALLY disappointing if this thread just results in yet more discussion over semantics and nomenclature. Debian is a do-ocracy, so 6 years of discussion really needs to end with something actually being done. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgprYLVlku8Aq.pgp Description: PGP signature
