Agenda: Multiarch - from 11:00 ========= * Apt/dpkg/aptitude disagreement on corner-cases does m-a:foreign package foo with arch:A satisfy a dependency on foo:B? Example: foo-dbgsym depends foo:amd64, where foo is M-A: foreign - foo:i386 will *not* work https://lists.alioth.debian.org/pipermail/multiarch-devel/2015-April/000099.html Agreed: Use dpkg's way, i.e. :arch restrictions are stronger than M-A:foreign. * Possible feature request: Syntax sugar to ease writing "foo:" depends (or something architecture agnostic like "foo:same") * Multiarch embedded interpreter problem * Are we declaring #666772 wontfix officially (apt cross-build-dep handling should be liberal with Arch: all packages) i.e we mark all M-A: foreign packages foreign explicitly. * Document Multiarch in policy (#687900, #621050, #684672, #650974, #636383, #687900). This really does need doing! Converting the multiarch spec(s) into policy is not trivial. The spec and policy layouts are very different, and corner-cases must be decided. - Needs someone to draft it - We should probably have two documents - Policy (for Debian maintainers) and a distro agnostic document for upstreams - deb-control and deb-src-control manpages document some of this. * Update advice on -dev packages and tell maintainers to multiarch them? - Recommend that maintainers multi-arch them - Document common pit-falls (if any) * Arch-qualified conflicts e.g jack audio connection kit has two libraries providing same name. Cannot install both on different arches. * "Conflicts: foo:" should do the "right thing(tm)" - Provides: foo:foreign - would have the same effect as a meta package foo which is marked m-a: foreign and depends on the real provider (which then has any m-a value) - use case: gcc could Provides: gcc-for-build:foreign - alternative: Provides: foo:any - virtual packages are problematic during bootstrapping * multiarch interpreter problem - https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges - https://wiki.debian.org/Multiarch/InterpreterProposal at most 1600 pkgs affected is only binaries, does not include source build-deps chains. The size of that issue needs checking. How common are problematic chains? Ruby needs all the modules + libraries to match arch, so specifying the whole chain that way is OK Can we use :native for arch all packages to indicate packages with this property? - if a package foo with arch:A depends on bar:any where bar is m-a:no and arch:A, is that dependency satisfied? - dpkg thinks "no" - apt thinks "sometimes" - should a dependency on bar:any not only allow the exception to only be satisfiable by a m-a:allowed package bar if bar is of a different architecture? - more research of the results of http://lists.debian.org/20150418212413.6468.60208@hoothoot have to be done - the results do not yet include source package dependencies - the results do not test co-installability of m-a:same packages but only interdependencies of two different packages - breaks/conflicts/replaces for m-a:same packages - #770301, #770345 fakeroot has been split - so you need to install libfakeroot for all arches you want to use it on install libfakeroot:* (this works). Or just list all of the arches in recommends. but nothing brings in all the other arches that you might want to use. e.g eatmydata wants it. field for 'this should be installed on all arches'? this is referred-to on the multiarch-interpreter page. This is high-level thing, so maybe apt will use it. not a dpkg-level thing. Could we use the 'enhances' filed for this? - conflicting ELF loader filenames - https://lists.debian.org/debian-devel/2014/12/msg00191.html - possible solution: - have qemu-user rewrite the INTERP to a M-A loader path - glibc only installs a loader symlink at the "old" path only on the native and its multilib arches (package install time decision) * Other issues from packagers? == Lunch == 12:30? YES! CrossBuilding From 13:00 ============= General roadmap - what still needs doing? * Cross-dependencies gcc-cross-support needs to be merged in gcc-defaults. Is this scheme acceptable to gcc maintainer. https://wiki.debian.org/CrossTranslatableBuildDeps * Multiarching more packages * -pkg-config * triggers in pkg-config triggered by cross-gcc-defaults? * packages with only symlinks inside? * include the symlink in some other package? * dpkg architecture removal/addition hooks * clang should use arch hooks to add triplet-clang names * toolchain support packages dpkg-cross -> cross-support enable cross-build-essential * Cmake crossing - state? ddate, libical are simple test-cases for cmake debhelper bug 794396. pending. how well does multiarch work? Avoid relying on qemu. This lets people bootstrap new things may not be available. Also it prevents from broken implementations. * Co-installable toolchains: crossbuild-essential-$arch needs to go into unstable * Using build profiles * sbuild issues experimental pbuilder runs better as non-root. does sbuild needs fixing? * Documentation - anyone want to improve the wiki? * self build-dependencies: can build the package twice, or build-depend on yourself at same version rigorous way says build twice if that's what you need. gpg-error-config, and postgres refuse to use pkg-config. needs patches and education. * Running test builds. of piuparts foreign installs. patch is attached to piuparts bug #794575 (ajames) * Cross-c.i: debomatic 1000 packages. popcon of things with satifiable cross-depends. * help2man is a pain. Stop doing this. Kick upstreams to not do it. Get packagers to remove it. Supply patches! skip running it on cross. * gobject-introspection needs a cross-introspector. * Config.site maintenance (centrally or package maintained?) packages do not use the same names for the checks. Who set variables? CONFIG.SITE NOCHECK = env CC, CC_FOR_BUILD - always overrideable CXX, CXX_FOR_BUILD lets do a lot in dpkg. Bootstrapping ============= * Essential set * Reduce size of strongly-connected set * Build-depends indep * More build profile usage * Virtual packages are problematic during bootstrapping Cross-Toolchain packaging ========================= * Self-contained toolchain builds (gcc5) OK? for stretch, yes. * Convert gcc4.9 to self-contained or leave multiarch-built? * roadmap: * get glibc using gcc-5 (instead of gcc-4.8) for building * drop the pre-5 cross-compilers from the archive * Should cross-toolchains be multilibbed? * Cross-build-essential in unstable * Merge cross-gcc (wdotap) patches into gcc? * Cross-dependency support (as in gcc-cross-support) OK. * Matthias does not want to commit to supporting any foreign-arch build-dependencies in gcc or its build-dependencies (glibc, etc) for stretch * wanna-build may support foreign-arch build-dependencies in stretch but this will be new and not yet well understood, and there is no committment to take these into the packages for stretch * Co-installable compilers.