This page is not written in moin syntax

The plain text of this page is written to be an email to d-devel@l.d.o and thus will not render properly in moin. Please use the plain text view (by appending ?action=raw to the url) to read this page.

Hi,

this is the report for the Bootstrap Sprint [1] which was recently held in Paris, France from 2014-08-16T10:00:00+02 until 2014-08-19:T18:00:00+02. Six people attended the sprint:

We feel that our sprint was extremely productive and the next sections will give an overview about what was discussed, achieved and planned for the future.

[1] https://wiki.debian.org/Sprints/2014/BootstrapSprint

0. General notes


Throughout this email we will use the terms "build architecture" to mean the architecture that a package is built on, "host architecture" to mean the architecture a package is built for and "target architecture" to mean the architecture a compiler produces code for.

If not otherwise specified, the term "package" will mean both, "binary package" and "source package". And if not otherwise specified, the term "dependency" means both "build dependency" and "runtime dependency".

The term "Sources file" or "Sources" refers to the source package control file that can be retrieved from mirrors or be found in /var/lib/apt/lists/. The term "Packages file" or "Packages" refers to the binary package control file from the same locations.

The term FTCBFS is analogous to FTBFS and expands to "fails to cross build from source".

1. Problems with early bootstrapping


1.1. Acquiring the list of Essential:yes binary packages


When starting a new port, the host architecture binary packages are not known. The only input is the data from a Sources file. Thus, the set of binary packages which are Essential:yes are not known at this point, because that information is encoded in the Packages file which does not exist for the new architecture yet. It is important to know the set of Essential:yes packages so that the right source packages can be cross compiled for the new architecture to create a native build environment that at the very least includes all Essential:yes packages and build-essential. We decided that using the information of the Priority field for binary packages can be used to solve this problem. Priority:required packages are a small superset of Essential:yes packages and their information is encoded in the Packages-List field in the Sources file. This approach requires that the set of Priority:required continues to be a very conservative and small selection to not make the bootstrap problem harder.

1.2. Dependencies on build-essential are not spelled out by base packages


All binary packages implicitly depend on Essential:yes packages. All source packages implicitly depend on build-essential. This assumption helps reduce the number of needed dependencies in settings where all Essential:yes packages and build-essential are available. This is not the case during the initial bootstrap of an architecture where no packages of the host architecture exist yet. Some of the source and binary packages involved in creating the Essential:yes and build-essential packages must have additional dependencies on packages which are otherwise Essential:yes or build-essential so that cross-build dependencies in an initial bootstrap can be correctly resolved.

1.3. Source packages that build virtual packages are not known


Since the Packages file does not exist in an early bootstrap it is not possible to retrieve the information about which binary packages provide virtual packages. If either packages depend on virtual packages, then it is currently not possible to retrieve the source package that should be built to create the binary package that provides the virtual dependency. Here is a small overview of binary packages that were found to expose this problem in an early bootstrap:

We see three solutions to this problem which all carry their own flaws but can be used together to help mitigate each other's disadvantages.

1.3.1. Provides information in the Packages-List field


The information of which virtual packages are provided by a binary package could be encoded in the Packages-List field in a Sources file. This has some restrictions, though:

1.3.2. Packages should depend on non-virtual packages


If packages depend on virtual packages, they must carry a non-virtual alternative as well to facilitate bootstrapping. We recognize that this solution makes transitions harder which would otherwise just be solved by a binNMU. Thus, this is probably not a solution that can be applied to all packages.

1.3.3. Switching virtual and real package names around


Consider a binary package of the form libfooN-dev which provides libfoo-dev. If the binary package does not bump API on each bump of N then the problem can be solved the following way. Switch the package content to a real binary package libfoo-dev and let it provide libfooN-dev. When there is a N+1 then there can be a real package libfooN-dev while the content of the N+1 goes into libfoo-dev and provides libfooN+1-dev. When the transition is over, the real package libfooN-dev can be dropped.

An example of a package which handles transitions like this even though it is not a shared library is automake.

1.4. Source packages create binary packages of different version


The information for which source package version corresponds to a given binary package resides in the Source field of a Packages file which does not exist in an early bootstrap. Thus, for now, versioned dependencies are ignored during a bootstrap. If a package depends on foo (>= 1.0) then the bootstrapper can only hope that if they build the source package building foo then the produced binary package does actually satisfy the versioned dependency. We have not yet encountered an example in practice where this limitation posed a problem.

1.5. Rebuild for Packages-List field


Where solutions require more information in the Packages-List to be present, the source packages in question must be rebuilt with a new enough dpkg version once all features are implemented in dpkg. So at some point in the future it might be necessary to do a rebuild of some seldom uploaded source packages.

2. Partial archives for different ISAs


TODO: aron

3. Cross compilers in main


TODO: wookey, doko, helmut: please expand the notes which I sorted into sections into text. Feel free to reorganize the sections if necessary.

3.1. Cross compiler naming


TODO: wookey, doko, helmut: expand this

3.2. Build/Host matrix and shared metadata


TODO: wookey, doko, helmut: expand this

3.3. Need for *-cross packages


TODO: wookey, helmut: expand this

3.4. Crossbuild checks


Many binary Multi-Arch:no packages still ship their headers in /usr/include. This can lead to the wrong version being picked up during cross or native building. To avoid this, two checks could be implemented.

The first check could be Lintian warning if a non-Multi-Arch:same package puts headers in /usr/include. If a binary package ships architecture independent headers in /usr/include then it should be marked Multi-Arch:same. If the headers differ between architectures, then they should be moved to /usr/include/<triplet>/.

The multiarch wiki page should be changed to encourage multiarching of *-dev packages.

3.5. Conflict with gcc-multilib


TODO: doko, helmut: expand this

3.6. Source packages layout


TODO: wookey, helmut: expand this

3.7. src:gcc-cross-defaults and src:gcc-cross-support


3.8. crossbuild-essential


TODO: wookey

3.9. Cross pkg-config


TODO: helmut

3.10. Cross binutils


TODO: wookey

3.11. config.site


TODO: wookey, helmut, doko

3.12. Coinstallable toolchains


TODO: helmut

3.13. Archive support for arch qualifiers


TODO: wookey, helmut

3.14. Multiarch builds


These work nicely on a local machine (with apt-get --only-source build-dep <package>; apt-get --only-source --build -oDpkg::Build-options="-aarm64 -B" source <package>. See MultiarchCrossToolchainBuild for details). But this is no use for in-archive cross-toolchains as network access is not allowed.

Packages to do the build in an archive-compatible way exist at <http://anonscm.debian.org/cgit/crosstoolchain/cross-gcc.git> but to use those in the archive requires tools to understand what to do with cross-arch dependencies.

3.15. Wookey stuff


TODO: wookey: please put the following stuff somewhere in the earlier subsections or create a new section

4. Cross compile support in source packages


4.1. Build dependency translation when cross compiling


If a source package explicitly depends on a versioned build tool like gcc, g++ or cpp, then this build dependency might have to be translated to the appropriate cross compiler when cross compiling the source package. The wiki page at [1] gives an extensive list of how this could be accomplished. All existing solutions had considerable disadvantages so we came up and agreed upon a seventh solution.

[1] https://wiki.debian.org/CrossTranslatableBuildDeps

Consider the following example binary packages (it does not matter from which source package(s) they will build). The left column shows a cross compiler for mips as installed on a amd64 machine. The right column shows them installed on a mips machine but this time it's a cross compiler for amd64.


+


Package: gcc-for-build | Package: gcc-for-build Architecture: amd64 | Architecture: mips Multi-Arch: same | Multi-Arch: same Depends: gcc | Depends: gcc Contents: empty | Contents: empty

Package: gcc-cross | Package: gcc-cross Architecture: mips | Architecture: amd64 Multi-Arch: same | Multi-Arch: same Depends: gcc-mips-linux-gnu | Depends: gcc-x86_64-linux-gnu Contents: empty | Contents: empty

Package: gcc-mips-linux-gnu | Package: gcc-mips-linux-gnu Architecture: amd64 | Architecture: mips Multi-Arch: foreign | Multi-Arch: foreign Contents: /usr/bin/mips-linux-gnu-gcc | Depends: gcc

Package: gcc-x86_64-linux-gnu | Package: gcc-x86_64-linux-gnu Architecture: amd64 | Architecture: mips Multi-Arch: foreign | Multi-Arch: foreign Depends: gcc | Contents: /usr/bin/x86_64-linux-gnu-gcc

With this binary package layout, source packages which need a versioned gcc build dependency can now build depend on gcc-for-build during native building and gcc-cross during cross building using the build profile "cross". Should the source package require execution of the native compiler during a cross build, then the source package can build depend on gcc-for-build in the "cross" profile as well. Packages depending on gcc-cross have to call the triplet version of gcc.

The mechanism works because the packages gcc-for-build and gcc-cross are Multi-Arch:same. Therefore, if they are build depended upon, their host architecture version will be chosen. Depending on its architecture, gcc-cross will depend on a different gcc-<triplet> binary package. The gcc-<triplet> binary packages in turn are Multi-Arch:foreign and either ship a cross compiler or depend on the native gcc depending on their architecture. If gcc-x86_64-linux-gnu:amd64 is installed, then one will get the native gcc compiler on amd64 through its dependency on gcc. If gcc-mips-linux-gnu:amd64 is installed then one will get the cross compiler for mips.

The system works because dependencies on Multi-Arch:foreign packages should be satisfied by the native architecture version of the package. Currently, apt resolves Multi-Arch:foreign dependencies in that way. On the other hand, the dependency of gcc-cross on gcc-mips-linux-gnu can also be satisfied by a foreign architecture package. This package would be the native version of the foreign architecture compiler. It would produce the code of the right architecture but would probably not be executable on the build architecture. Though this is a general problem of Multi-Arch:foreign packages which does not only affect this mechanism.

4.2. help2man issue


Source packages that build depend on help2man cannot be cross compiled because they require a build architecture binary to be executed for generating the man page. There exist different solutions to the problem:

4.3 libtool


Build dependencies on libtool make cross build dependencies of a quarter (83) of the source packages in the transitively build-essential set unsatisfiable because the build as well as the host architecture version of the libtool binary package would be required but libtool cannot be co-installed and is not Multi-Arch:foreign either.

This bug was filed as bug#682045 and was taken care of by Matthias Klose. The libtool binary was split into libtool and libtool bin and an upload was done in accordance with the libtool maintainer. The next step is to do an archive rebuild with libtool not depending on libtool-bin, fixing packages that fail to compile and then dropping the build dependency.

5. Bootstrap and Crossbuild Quality Assurance


5.1. dose-builddebcheck for cross


dose-debcheck is run regularly for all binary packages at [1]. Ralf Treinen was contacted and agreed that dose-builddebcheck could be run in addition as well. We have to contact him and ask about the possibility to also include running dose-builddebcheck with a foreign host architecture for selected targets to spot FTCBFS problems early. Such a service would enhance the results that are already generated at [2].

[1] https://qa.debian.org/dose/debcheck/ [2] http://bootstrap.debian.net/cross.html

5.2. Archive Cross Rebuilds


Just as full archive rebuilds are regularly done natively, they could also be done regularly (for example on Amazon AWS). It should not be hard to implement such a service as sbuild has cross compilation support. The results of those rebuilds could be displayed on the pts or the new tracker platform. This item needs cross compilers in the main archive. It would be even better to schedule a crossbuild on every package upload to quickly identify problems right after they are introduced.

5.3. Cross-Builds:no field


When starting to cross build the archive regularly, then there should be a method mark source packages as not-cross buildable. Packages would be marked as such if their build system does not allow any cross compilation. This is for example the case if there exists no cross compiler (example: gobject-introspection). We already store a similar information in the Architecture field where we restrict the architecture to certain values if the software project can only be built for a subset of architectures. Having a Cross-Builds:yes field would invite trouble as it is not clear for which combination of build/host architecture the source package is supposed to cross compile. A Cross-Builds:no field would mark the source package as not cross compilable at all. If such a field existed, then an archive auto cross builder would not attempt to cross build those source packages and would also not warn in the pts or tracker about the failure. Until such a field is agreed upon, the information can also be stored local to the cross rebuild machinery or stored in a custom XS-Cross-Builds:no field. Another good heuristic might be to check the build dependencies of source packages before build. If they build depend on, for example gobject-introspection binary packages, then it is unlikely that they can be cross compiled. This heuristic would avoid having to flag tons of packages but would also not be always correct.

5.4. Bootstrap info in pts/tracker


The pts/tracker could show info about hard dependency cycles (self-cycles). There exist two patches for the pts (#745618 and #728298) which have to be rewritten for the new tracker. Additionally, the information should only be displayed once source packages with the new build profile syntax can be uploaded to the archive. Thus, any such info can only be available once Jessie is released. In addition it would be a good longterm goal to move the machinery behind bootstrap.debian.net onto Debian infrastructure to be more robust for such a QA task.

5.5. Display multiarch hints in pts/tracker


Downstream distributions of Debian like Ubuntu could be used to determine which packages in Debian lack multiarch annotations. Especially Ubuntu is useful as a source as multiarch cross building has been tested there for a while and thus more packages have been fixed.

5.6. Require an explicit multiarch value


Lintian could warn if a binary package was not explicitly marked with a multiarch value. The reason would be that this would force maintainers to make a clear decision about the multiarch status of their package instead of defaulting to Multi-Arch:no. The likely outcome though, would be that maintainers would tag their package Multi-Arch:no just to get rid of the Lintian warning instead of investing time to properly multiarch their package.

6. Build Profiles


6.1. New evaluation logic


The original build profile proposal defined an evaluation scheme of the restriction list which was very hard to understand, contained corner cases that would probably never be used and also limited expressiveness a lot. We agreed that if this new syntax is introduced it should allow for maximum expressiveness and be intuitive and easy to understand at the same time. We decided that letting profile restrictions form a disjunctive normal form would satisfy both requirements. The new evaluation scheme allows to specify more conditions and is at the same time easier to understand and implement.

Here an example:

The source package will depend on foo (>= 1.0) if both, stage1 and cross are active as a profile. The source package will depend on bar on amd64 if either stage1 or cross are active. Terms within <> "brackets" are AND-ed and form a conjunction. Multiple of those groups are OR-ed and form a conjunction. This also means that in contrast to the original proposal, the order of build profiles does not matter. With this solution, build profiles gain the same amount of expressiveness as Gentoo USE flags.

As a result of this change, we will also drop our efforts to make the archive understand the build proflie syntax before the Jessie release. This also let to a reassignment of bug#744246 to dpkg.

Patches for dpkg and apt to support this change have been written and are currently being tested.

6.2. No "profile" prefix


We decided to drop the profile prefix from the restriction syntax. The "profile" prefix was included in the original proposal to allow for future extensions of the syntax. But we cannot see how the build profile syntax as a selector of build dependencies can be extended for other use cases. All future additions that we came up with and that were suggested on discussions on debian-devel only imply a tagging of build dependencies but not their selection. But a tagging mechanism, if ever introduced, would not need to make use of the <> brackets as a meta character. With the current meaning of the syntax, any other prefix namespace can only ever take the role of a dependency selector and would thus fit in the "profile" namespace. Proponents of the need for "future extensibility" of the syntax were at no point able to give as a single concrete example for such a use case. We therefore think that having a prefix mechanism would noly introduce unnecessary complexity in the implementation and would make the restriction logic harder to read, write and understand for no conceivable practical gain.

6.3. Binary package contents


Binary packages built with a build profile must contain the exact same content as when they are built without a build profile (a full build). This requirement is necessary to not break the dependency system. Anybody depending on a binary package mast continue to be able to make the assumption that it ships a certain content, no matter how the binary package was built. If binary package contents change significantly due to a build with fewer dependencies and thus less features, then the binary package has to be split into two or more individual binary packages.

This requirement is relaxed for builds with the "stage1", "stage2" and "nodoc" profile. With these profiles, binary packages are allowed to leave out content which does not expose a functional interface. Such content would be documentation like man pages or locale information.

6.4. nodoc build profile


In addition to the existing build profiles "stage1", "stage2", "nocheck", "nobiarch" and "cross" we add an additional profile called "nodoc". Its purpose is to do builds without the build dependencies required for building documentation. There is no policy defined "nodoc" value for DEB_BUILD_OPTIONS. Current source packages use "nodoc" as well as "nodocs". We decided to go for the singular as "nocheck" is singular as well. In addition, *-doc packages have a "doc" prefix and not a "docs" prefix. We suggest to add "nodoc" as a DEB_BUILD_OPTIONS to policy.

6.5. Relationship to DEB_BUILD_OPTIONS


Some DEB_BUILD_OPTIONS like "nocheck" and "nodoc" are mapped to build profile names. Build profiles could take over the job of these DEB_BUILD_OPTIONS in the long term. For now, DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES will coexist.

6.6. Profile name application


Especially the "stage1" and "stage2" build profiles with the meaning of "build the source package with less features" overlap with other profile names like "nocheck" and "nodoc". If in doubt, build dependencies should be flagged with the more specialized build profile. So instead of writing:

It should be enough to write:

In the same way, instead of writing:

It should be enough to write:

It is the task of the builder to figure out which profiles to activate to perform a build.

7. Rebootstrap


TODO: helmut

8. Botch


8.1. Bootstrap from zero


Botch integrated a new script from Helmut Grohne which allows to create a build order without having access to the host architecture Packages file which does not exist at this point. Botch did not yet include such a facility because it catered for two other use cases: calculating a build order for rebootstrapping existing architectures and calculating and analyzing a dependency graph to find the best points to break it (finding a feedback arc set). With the new script botch will soon be able to also handle the case where not even the information about the host architecture binary packages exists in the beginning. This will then also allow botch to be used to schedule transitions as the resulting binary packages are not available in that scenario either. The challenges of bootstrapping from nothing have been explained in the first section.

8.2. Miscellaneous additions fixes


9. Miscellaneous


9.1. Find outdated versions


Versioned dependencies are problematic for bootstrapping because versioned compiler dependencies have to be translated and the versions of binary packages is not known a priori during a bootstrap from zero. Many packages in the archive declare versioned dependencies with a minimum version which is even fulfilled by oldstable. We propose that lintian warns if a version constraint is obsolete because it would even be fulfilled by oldstable. This was filed as bug#758425 against Lintian.

9.2. Dpkg can set the target architecture


To have a common and unified interface, it was agreed with Guillem Jover that dpkg-buildpackage should have a --target-architecture switch added which sets the target architecture just as -a sets the host architecture. Perhaps the variables might only be output if the switch is passed, to avoid further confusing maintainers that do not usually need those variables.

9.3. Fixed bugs


TODO: all

The following bugs have been fixed during the sprint in addition to the ones mentioned earlier:

9.4. Filed bugs


TODO: all

The following bugs have been filed during the sprint in addition to the ones mentioned earlier:

9.5. Fix dpkg-maintscript-helper


pkg-config required a dir-to-symlink switch (TODO: helmut, expand), and to comply with policy the symlink target pathname should be relative as specified by the Debian policy. But dpkg-maintscript-helper was not handling those correctly. Helmut prepared a patch to fix the dir_to_symlink command, and Guillem merged and added a check to the symlink_to_dir command so that it ensured only absolute paths are being passed on. These were included in the dpkg 1.17.13 upload.

9.6. Arch:all sometimes implies M-A:Foreign for dpkg-checkbuilddeps


TODO: helmut, guillem Once you have a bug filed for this you can add it to section 8.4. and delete this section

10. Epilogue


We would like to thank Roberto di Cosmo for kindly hosting the Bootstrap Sprint at IRILL in Paris, France. We'd also like to thank Debian and it's donors who covered our travel expenses and without who this sprint could not have happened.

+


+ | The original sprint notes start here | +


+

2014-08-17

* josch

2014-08-18

What do we want to have in Jessie

Agenda

Guillem topics