On 2018-10-10, Vagrant Cascadian wrote: > On 2018-09-30, Ivo De Decker wrote: >> I pushed a branch 'qemu' to salsa which creates a u-boot-qemu package with >> the >> images for the architectures that are actually in debian: ... >> Inspired by other qemu bootloaders (like edk2, openbios, ...), I created this >> as an arch all package, which is built using the cross compilers available in >> the archive. This caused some changes in the build of the package. I would be >> interested to get your feedback on this. Do you think this is an acceptable >> way forward?
The branch still merges on top of 2018.11-1 and if building arch:all only, it builds! Cool! When building arch:amd64+all it FTBFS, as dh_strip is called and attempts to use amd64 strip on the arm*/mips* binary uboot.elf files. My local workaround was: +override_dh_strip: + dh_strip -X qemu_ Which seemed to work ok, but of course, leaves them unstripped... It also needs some updates to debian/bin/update-lintian-overrides, which I took a quick stab at, but fighting with it probably highlights that the overrides updating should be refactored a bit anyways, and this arch:all cross-build just makes it more obvious. > Overall, I like the improvements, but I have mixed feelings. > > With multi-arch being possible, I'm inclined to keep things native... At > the same time, multi-arch is a bit annoying to require for someone > wanting to use qemu to boot a foreign architecture... > > Since all the cross-compilers are (currently) only available on > amd64/i386, this would mean you can't build u-boot's arch:all packages > on anything other than amd64/i386, which might cause problems for > tests.reproducible-builds.org, which builds both arch:any and arch:all > packages for amd64, i386, arm64 and armhf. This all still holds true, especially in light of the dh_strip issues. So, it still seems like it would be easier to just add u-boot-qemu native builds, but that's less useful to the end-user. Then again, an end-user doing u-boot with qemu on non-native architectures is pretty sophisticated already... maybe requiring multi-arch isn't too much to ask of them. > I think it would also be easier to transition to arch:all later and > start off with native packages than the other way around. Now I'm not as sure that will be an easier transition... changing later would probably be just about as annoying either way. live well, vagrant
signature.asc
Description: PGP signature
