On Thu, Jan 16, 2020 at 11:18 AM Ondřej Surý <ond...@sury.org> wrote: > while your effort is valiant, I see a little value in it as there’s no real > world use case. While your arguments are valid, you are imposing additional > work on generally already overloaded maintainers with unclear goal and > purpose. > > Perhaps your energy and enthusiasm (which I appreciate) could be spent on > helping fixing reproducible builds in packages or cross-building. Those are > practical and you won’t find any resistance in accepting patches for these > two use cases.
OK, makes sense. This was, in fact, an offshoot of the beginning stages of a project to create some way to automate bootstrapping an architecture starting with automated cross builds of the core packages. (Incidentally, another offshoot was creating local patches to sbuild which add an operation mode using systemd-nspawn --ephemeral to start a container (along with the base being a BTRFS subvolume to speed up the cloning), systemd-run -M debian-sid-amd64-xxx [--property=PrivateNetwork=yes] cmd..., etc. When I sent a message to sbu...@packages.debian.org there didn't seem to be any interest in having me clean up the patches and send them on. Still, do you think if I posted bug reports for issues I found due to the builds running under seccomp filters, as wishlist bugs and with either suggested patches or a request for advice on further debugging it myself where I got stuck, that maintainers might be willing to consider them? Also, by the way, the amd64 -> i386 cross built core packages largely worked OK, with the exception of gcc-9, which ended up with incorrect include-fixed/limits.h, and with a compiler that required -lssp when building with -fstack-protector-strong or -fstack-protector as almost all Debian packages do. To anybody on the list: is there something I did wrong with the cross build there, which was to run "dpkg-buildpackage -a i386 -B -Pcross"?) -- Daniel Schepler
