- Looked at script for rebootstrapping into main archive from ports. * botch-main-archive-bootstrap-what-next - problem: only considers one source package at a time - needs global view (botch) Useful for understanding what to upload next to unblock buildds. - Fixed botch-wanna-build-sortblockers to understand bd-uninstallable multi-line output as well as build-needed single-line style. Used for: https://people.debian.org/~wookey/bootstrap/blocked-deps-list - compiler package naming and compiler binary naming patterns (there are multiple ones atm)? * using debian arch and triplet * very confusing but historic reason * so no changes and leave as is to not break things * too many things rely on it (also out of the archive) * there could be Provides of packages with Debian arch - do we need *-cross packages? (alternative multiarch) * depends on multiarch cross build dependencies working * are needed for some architectures - needed for architectures that are not in the archive * bootstrapping * different sysroot * mingw64 - there should be a limited number of host/build cross compiler combinations * all cross compilers should work on amd64 * and some other selected ones (armhf -> arm64) - two checks would be nice: * before crossing, a script should check if /usr/include contains files from packages that are not m-a:same * lintian should warn if a non m-a:same package puts headers in /usr/include (if a package shares files in /usr/include then it should be m-a:same and if it is not m-a:same then those headers should be moved to /usr/include//) * this warns when cross builds pick up header files installed for the build system * this warns when native builds pick up header files installed for the host architecture * multiarch wiki should be changed to encourage multiarching *-dev packages * TODO: wookey fixes this - cross compilers should conflict with gcc-multilib which provides the asm symlink * creates an unclean environment otherwise - right now: one source package per architecture * one git repository generates the source packages - where to put src:gcc-cross-defaults and src:gcc-cross-support * src:gcc-defaults should be extended to include cross - but native and cross compilers do not build in sync - but new upload is only done once everything is built * src:gcc-4.9 should be extended to include src:gcc-cross-support - helmut uploaded gcc-cross-support to experimental * Discuss toolchain dependency translation (e.g. gcc-${host}) * see also: CrossTranslatableBuildDeps and DebianBug:695287 * affected packages: http://bootstrap.debian.net/cross.html in the "conflict" table * solved by src:gcc-cross-support - build-essential needs to be * m-a: same * depend on gcc-for-host * then crossbuild-essential can go the way of the dodo - Discuss how we add missing metadata about early bootstrap into package lists. Another is that dependencies on build-essential are not spelled out. In bootstrap, We need an order to cross build build-essential though, so we need to know these dependencies. - when building build-essential, build-essential is not available - packages which are transitively build-essential should spell out dependencies - can be put in policy - problem of dependencies on virtual packages because we cannot know which binary package provides something before building it * example: glibc has different library names for different archs * also versions cannot be predicted * either: essential packages must list non-virtual dependencies as first alternatives in depends AND build-depends - but breaks transitions * or: extend Packages-List field with Provides information - must not be architecture independent (haskell, ocaml) - must not be versioned - must not contain substvars curly braces - must not contain arch-restrict. bracket * TODO: bring it up with affected maintainers (tiff, png, jpeg) * Problems with virtual packages within essential: When Build-Depends or Depends list virtual packages, it is non-obvious to figure out which source package needs to be build for satifying such a dependency, because in the bootstrap case, binary packages for the host architecture are missing. Proposed exclusive solutions, which have to be implemented for every package the same way: * Require transitively essential packages to list real packages in all of their Depends and Build-Depends as first alternatives. For example, this means depending on zlib1g-dev instead of libz-dev or shipping a real libz-dev meta package. * Require transitively essential packages to not vary their Provides among different architectures (Haskell and Ocaml do this) and have them list Provides in the Package-List field of their .dsc files. In this case, dpkg needs to allow for packages to add new entries to Package-List (in .dsc) and src:zlib1g would need to append provides=libz-dev to the Package-List entry for bin:zlib1g-dev. Transitively build essential packages affected are: [virtual] -> [real] * libz-dev -> zlib1g-dev * libpng-dev -> libpng12-dev * libgpmg1-dev -> libgpm-dev * libselinux-dev -> libselinux1-dev * libgmp10-dev -> libgmp-dev * libltdl3-dev -> libltdl-dev * libltdl7-dev -> libltdl-dev * libncurses-dev -> libncurses5-dev * libexpat-dev -> libexpat1-dev * libtiff-dev -> libtiff5-dev * standard way of defining target architecture in as environment variable * dpkg-buildpackage --target-architecture can set that * only outputting variables if option is specified == 2014-08-17 == * config.site currently lives in dpkg-cross for no good reason. It contains autoconf test results for various packages, but it makes more sense to move the test results to the package that is being tested. autoconf will examine /usr/share/config.site by default. It will source some files in /etc (local pre-configuration), then include /usr/lib/config.site/* and /usr/lib//config.site/* and afterwards source more files in /etc (local overrides). Files in the config.site directories are going to be shipped by binary packages and are named after the binary packages. For instance libc6-dev can contain scanf_cv_type_modifier=ms. * this will be in cross-support * Need to write corresponding policy * josch - write documentation for botch - integrating tobuild.py - make it python3 - find old versions in lintian - write patches for dpkg and apt for new build profile support * doko - libtool split (as agreed with maintainer) * uploaded * next: 1. archive test rebuild with libtool not depending on libtool-bin 2. fix failing packages 3. actually drop the dependency * helmut - preliminary patch to teach pkg-config to bring the triplet symlink to cross-wrapper just by installing the right pkg-config. depends on dpkg fixing dpkg-maintscript-helper dir_to_symlink * TODO: helmut (file bug with patch and put bugnumber) - filed #758408 gcc mips64el nobiarch * coinstallable toolchain - wrote a patch to pass --program-prefix=$(DEB_TARGET_GNU_TYPE)- and reverse symlinks to binutils' single build (preparation for coinstallable toolchains) and sent to doko and doko reviewed it - TODO helmut: needs to be rewritten to cover for binutils-multiarch * discussion about co-installable toolchain between helmut/doko - Not for jessie * tcc: DebianBug:695354 gcc: DebianBug:666743 * wookey - cross toolchain feddling - make cross-gcc + cross-gcc-defaults uploadable. - fix that guile doesnt cross build for any arch (bug filed #758463, maintainer happy) - fix cross-binutils to use dpkg-vendor instead of lsb-release and complain if it's null so either get nothing or the right thing and added ppc64. Done, and uploaded as cross-binutils_0.6 - add a 'cross' suffix so that independent updates from binutils are possible. * aron - fixed gmp symbols #750478 #746523 == 2014-08-18 == * helmut - write preliminary patch fixing dpkg-maintscript-helper dir_to_symlink to support relative targets (needed for pkg-config package split) and sent to guillem and locally committed - propose a new solution for CrossTranslatableBuildDeps and write a rough implementation == What do we want to have in Jessie == - splitting libtool? (into libtool-bin etc) DebianBug:682045 * archive rebuild required to find bugs * libtool architecture dependent, libtoolize (used by autoconf) is arch indep * Multiarch builds * Specify additional arches in header? - but information can be extracted from Build-Depends instead * Anything else needed? dak? dpkg? - they don't care if no new field * wanna-build, britney, dak need to understand this - dak, wanna-build understanding architecture qualifications: foo:arm64 - toolchains in the archive can be done either the multiarch way or the cross-toolchain-base way - cross-toolchain-base at least necessary for arches outside the archive * whole bootstrap in one package, outputs glibc packages - TODO: doko: revisit the build of the libgcc1 package * cross-binutils are separate * needs fixing for Jessie - corrected build profile uploaded for all affected packages == Agenda == - a machine which tests crossing packages to see if they cross compile or not * full archive cross builds * display results in the pts * current amazon based solution takes too long between upload and check - let qa.debian.org/dose do builddebcheck and cross-builddebcheck * How to ensure that build profiles work in Jessie? See DebianBug:744246 * Push into archive? (trying atm) * Set up copy of archive for testing? (painful) * we are just gonna wait for jessie * Other cross-build pieces * What should be in cross-build-essential (or finer-grained mechanism?) * nothing - it turns out. * autofoo cache data (, cmake toolchain files etc. Move out of dpkg-cross? yes. * Shared metadata for Host/Target matrix * good idea to have that but not important * also distribution specific * rebootstrap achievements * libgcrypt11 builds when setting ac_cv_sys_symbol_underscore=no * multiarch guile-2.0 shall be uploaded soon (according to wookey) * failing gcc stage2 multilib build (doesn't find crti.o). TODO helmut: try with an unstaged build * discuss need for `Cross-Builds: no` field (or how to otherwise store that information) - it would be useful to know about package that can never be cross compiled because there does not exist a cross compiler (for example for gobject-introspection) or because of cases like DebianBug:753047 - we can use an X-* header - we can store the knowledge in build tools Crossbuild QA feedback in PTS * needs crosstoolchains * libtool bug * missing multiarch by comparing with Ubuntu Multiarched-or-Not feedback in PTS * simple static list of whether library is multiarched on not - put in PTS - should all binary packages should have a multi-arch value? - explicitly set m-a: no? - people might just put m-a:no and be done with it * discuss how intersecting build profiles should be applied. Either `doc-generator , testsuite-runner ` or `doc-generator , testsuite-runner ` - individual profiles (nocheck, nodoc) are preferred over making everything stage1 * discuss whether more build profiles should be introduced, how about mapping some DEB_BUILD_OPTIONS to build profiles? (nodoc, nocheck, ...) - yes: nodoc * should some build profiles replace DEB_BUILD_OPTIONS? - coexist * discuss status of ReleaseGoals/CrossBuildableBase what is missing? Where are blockers? How to identify the set that must be cross-able for a minimal base system? * bootstrap info at qa.debian.org * example: https://packages.qa.debian.org/~pabs/g/ghc.html https://packages.qa.debian.org/~pabs/a/avahi.html * cross: DebianBug:745618 (problem: it must be manually decided in which package the bug is) * cycles: DebianBug:728298 (problem: all but self-cycles are not hard requirements) * TODO: josch change patches for new tracker - check if dpkg-checkbuildeps lets arch:all imply m-a:foreign * TODO: helmut file a bug == Guillem topics == * discuss handling of mixed positive and negative restrictions * make similar to gentoo use flags? yes, disjunctive normal-form * => means that dependency applies if ((stage1 AND nobiarch) OR nocheck ) * what should happen when an unknown namespace is encountered? unknown namespaces are interpreted as false * the current way is complicated and it is hard to see how this makes future extensions possible (solved by disjunctive normal-form) * super tiny issue of Build-Profiles field in binary package stanzas and Packages-List representation (whoever changes that gets to fix the bootstrap patches) * discuss the requirement that binary packages built with a build profile must be equal in functionality to those normally built (or be split or renamed) and how to enforce this (reproducible builds?) * when profile stage1 is active (with or without other profiles active at the same time ): * only things that expose an interface must remain the same * man pages and docs should be safely removable * for other profiles like cross, the created packages should contain everything * help2man is used during build by coreutils, bison, flex. all of them therefore fail to build * discuss substitution variables in Build-Depends DebianBug:751437 -> just use profile.nodoc * Guillem's 'fake' cross-toolchains idea * wookey will reuse the ideas for the cross-toolchains pending to be uploaded * partial archives for different ISAs? * mips people want it, otherwise three new arches * for 64bit ports (mips64/mips64el/mipsn32/mipsn32el), there would be MIPS III, MIPS64, and MIPS64rev2 * dpkg could have a binary package field specifiying HWcapabilities. * not conflated with dependency resolution - all such packages are equivalent in dependency terms * apt pinning could be told to examine that field * dpkg could have a check in --audit to check if installed packages are runnable on current system * repository layout is a separate issue. Simple version is separate repo, otherwise dak needs to understand to put in database. Could have separate tree, or filename suffix in order to go in shared file hierarchy * Decide if the baseline (default set of caps) is empty field or shorthand? * stopped tech-ctte bug * Multi-Arch interpreter