Hi, Quoting Joe MacDonald (2024-05-24 00:41:55) > > 1. maybe this sphinx-related dependency is only used to build Arch:all > > documentation packages? If yes, it could be moved to > > Build-Depends-Indep and is thus not interfering with cross building > > anymore as we only need to build Arch:any packages > > Based on the incomplete log I provided (due to pastebin size limitations) > I think it's this and I could try that on my side to see what kind of > trouble that gives. I looked at debian/rules and sphinx is used to generate the man page which ends up in the arch:any qemu package so no, it cannot be moved to B-D-I. > > 3. maybe you need the build architecture version of the package, in which > > case you have to mark the build dependency on python3-sphinx-rtd-theme > > with :native Some :native annotations were done back in 2021 to make qemu cross-buildable. See this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995622 > > > I'm say sbuild because that's the first thing I tried and probably the > > > solution I'd prefer, but both 'sbuild --host arm64 qemu' and 'dget ... ; > > > pdebuild -- --host-arch arm64' fail in the same way, so I didn't think it > > > was sbuild/schroot specific and more of a general build thing. > > > > Yes, this is not specific to sbuild but a result of how the current metadata is > > as it is. You will experience the same problem without sbuild or pbuilder. > > But if I was building for arm64 on an arm64 platform, that should still > work, correct? Even if I was choosing to build it with sbuild, the way I > did with the pure-x86_64 sbuild log? Or am I missing something else in > the explanation here? Yes, native building for arm64 on arm64 with sbuild works fine as proven by what the Debian buildds last did 3 days ago: https://buildd.debian.org/status/package.php?p=qemu > > Also, you can see how qemu currently fails to cross build from source due > > to unsatisfied cross build dependencies here: > > > > http://crossqa.debian.net/src/qemu > > > > Last time it built was quite a while ago. It is likely, that making it > > cross-build will involve much more problems than just > > python3-sphinx-rtd-theme. > Thanks for the link. You're correct, that has been a long time. I'm curious > about the unsatisfied dependency there, python3-setuptools-whl, but maybe > that's just something else I'd bump into after addressing the sphinx thing. Maybe try this patch and see if it fixes things for you? --- qemu-9.0.0~rc2+ds/debian/control 2024-04-03 14:13:44.000000000 +0200 +++ qemu-9.0.0~rc2+ds/debian/control 2024-05-24 06:13:53.000000000 +0200 @@ -6,12 +6,12 @@ Uploaders: Michael Tokarev <mjt@tls.msk.ru> Build-Depends: debhelper-compat (= 13), python3:any, - python3-venv, + python3-venv:any, python3:any (>> 3.11) | python3-tomli, meson (>> 0.63.0~), ninja-build, flex, bison, # for python3-sphinx:native see #995622 - python3-sphinx:native, python3-sphinx-rtd-theme, + python3-sphinx:native, python3-sphinx-rtd-theme:native, Build-Depends-Arch: # In comments below we also specify (system-specific) arguments # to qemu's configure script, -- optional features which depend > > What is your motivation? What makes you want to cross-build qemu? > > I need to build qemu binaries for arm64 hardware but I don't have arm64 > hardware to do the building. Being able to do the build-native > architecture is definitely desirable but it's, unfortunately, not an > option for me. I'm in a similar boat. I *do* have arm64 hardware (the laptop I'm currently typing this on is arm64) but building packages like the linux kernel on this machine is not fun (takes more than 3 hours), so I'd like to cross-build it on amd64 for arm64. > One other approach I tried that I didn't mention previously, is using > sbuild-qemu. I followed the instructions here: > > https://anarc.at/blog/2022-04-27-sbuild-qemu/ > > after I'd seen it discussed in the mailing list archives here. That's > definitely my least desirable approach since now I'm running an aarch64 > qemu to do native compiling, but if it's all I have I'll go with it. Yes, qemu emulation can be around 20 times slower than doing things natively. We did this a long time for gstreamer which could not be cross-built due to gobject-introspection and it resulted in the build taking hours instead of minutes... In case you find bugs in sbuild-qemu, Christian Kastner would like to hear them. > Unfortunately that also didn't work for me, it failed due to missing gcc > implementations. > > -------------------------------------------------------------------------- > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: gcc-alpha-linux-gnu but it is not installable > Depends: gcc-powerpc64-linux-gnu but it is not installable > Depends: gcc-sparc64-linux-gnu but it is not installable > Depends: gcc-hppa-linux-gnu but it is not installable > E: Unable to correct problems, you have held broken packages. > -------------------------------------------------------------------------- > > Since I don't actually care about any of those architectures, I suppose I > could always just disable them in the qemu configuration. Is that maybe my > best course of action now, do you think? Those build dependencies are in Build-Depends-Arch and only required to build Architecture:all packages. You should run sbuild with --no-arch-all and then they will not be needed. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature