Hi Vagrant,
Sorry for not following up on this sooner and thanks for keeping track
of it.
On 11/26/18 8:42 AM, Vagrant Cascadian wrote:
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!
I tried this as well last week, and noticed that the riscv64 port is now
also available, and it builds fine with the cross-compilers in the
archive. I haven't tested the result, though. I pushed this to the
qemu-v2 branch. I didn't push it earlier, because I still need to
document the examples.
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...
The "build-targets" target invokes $${CROSS_COMPILE}strip on u-boot.elf,
so they should be stripped. I didn't verify this yet, but if it turns
out they aren't stripped, I'll try to find out what needs to be changed
to fix this.
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.
I didn't realize that r-b always does a full binary build, instead of
the binary-arch build on the buildds. This fails when the arch:all build
doens't work on some architectures. I think this is an issue in the r-b
setup.
The dh_strip issue also shows that doing separate binary-arch and
binary-indep builds or a full binary build can make a difference.
Inspired by both these issues, I filed https://bugs.debian.org/914714,
to see how the r-b infrastructure can be improved to deal with this.
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.
Running a qemu/kvm instance with a different architecture than the
system it is running on, doesn't seem to be an unusual use case,
especially if the system can handle both (and i386 vm on amd64,
armel/armhf on armhf/arm64), so it would be unfortunate to have to
enable multi-arch for that.
I still feel that the advantages of arch:all binaries outweigh possible
disadvantages (once all the bugs, like the strip issue, are fixed). But
if you feel strongly the other way, I can change the patches.
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.
Changing this later might require some thought. If we can avoid that,
that would be nice.
I hope to have some time this week to work on the documentation and some
small cleanup (like lintian etc) and do some more tests.
Thanks,
Ivo
