https://bugzilla.redhat.com/show_bug.cgi?id=1901665 Nicolas Chauvet (kwizart) <kwizart@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kwizart@xxxxxxxxx | |) | --- Comment #4 from Nicolas Chauvet (kwizart) <kwizart@xxxxxxxxx> --- (In reply to Andy Mender from comment #1) > First, big thanks for bringing this package to Fedora! :) > > > %check > > # Tests are failing for now > > %ctest || : > > Any indication why they are failing? Could you add an extra comment > explaining that? Tests are probably failing because box86 isn't yet registered in binfmt.d/ > > %files > > %license LICENSE > > %doc CHANGELOG.md README.md USAGE.md > > %config %{_sysconfdir}/binfmt.d/box86.conf > > The config file should be marked as "noreplace", otherwise it will get > overwritten on package reinstalls and updates: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_configuration_files This file is intended to register box86 as an "interpreter" for any x86 binaires. So unless it doesn't work there is no reason to change it. Actually, there is a better location for this in /usr/lib/binfmt.d/box86.conf. I will change it, but for now there is an error while registering... (need to be investigated). > > %ifnarch %{ix86} > > %{_prefix}/lib/i386-linux-gnu/libgcc_s.so.1 > > %{_prefix}/lib/i386-linux-gnu/libstdc++.so.5 > > %{_prefix}/lib/i386-linux-gnu/libstdc++.so.6 > > %endif > If the target is ARM 32-bit, is the if-clause needed and would it still work > if you used %{_libdir} (the preferred macro) instead? Yes arm is the only relevant architecture, but I'm not yet sure when it could generate the stub libraries. Also it's theoretically possible to build box86 as x86 binary for debug purpose (then the libraries won't be relevant). > Also, I think you can catch the libstdc++ SO files with a tailing '*' at the > end, instead of the digits. There is expectation that SO version are explicit to avoid any surprise. > "/usr/lib/i386-linux-gnu" seems like a Debian/Ubuntu libdir. Is there any > way to convert it to a Fedora-compatible path or put the packaged SO files > into a box86-specific dir in /usr/lib and let cmake link against these? That's a big question. Debian might not forbid to install x86 binaries into arm host (and the other way is even more relevant to ease cross-compilation), so theses binaries will be installed on a dedicated "multiarch" directory. (not tested, not certain either). In fedora, this is prevented because arm and x86 are using the same paths (/usr/lib), and also this break a very strong assumption with RPM (for the least). A possible way forward would be to install an x86 chroot (with qemu-x86-static) into /var/lib/box86 and install x86 binaries there. Then there is a need to replace "normal" libgcc.i686 and libstdc++ by the box86 version. There is probably a packaging problem, because we don't want to have libraries provided by box86 in %{_prefix}/lib/i386-linux-gnu/ to interfere with normal native arm equivalent in the RPM computation. So there is probably a need to exclude this path from the packaging. But we can still retain the %{_prefix}/lib/i386-linux-gnu path as they won't conflicts with the arm system linker (this path isn't registered in /etc/ld.so.conf.d). As I haven't managed to use box86 to run any x86 binary yet, this is still unclear how to deal with that... Any idea ? Given the various assumptions that this package break, I think it might be more relevant for copr than with normal fedora repositories. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
