Spec URL: http://dl.kwizart.net/review/box86.spec SRPM URL: http://dl.kwizart.net/review/box86-0.1.4-1.fc31.src.rpm Description: Linux Userspace x86 Emulator Fedora Account System Username: kwizart Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=56251261 This package is known to only work on arm.
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? > %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 > %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? Also, I think you can catch the libstdc++ SO files with a tailing '*' at the end, instead of the digits. "/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? Extra items in the review below: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package installs properly. Note: Installation errors (see attachment) See: https://docs.fedoraproject.org/en-US/packaging-guidelines/ ===== MUST items ===== C/C++: [x]: Provides: bundled(gnulib) in place as required. Note: Sources not installed Review: Not sure about this. The full gnulib is NOT bundled, just 3 SO files. [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt packages [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: There is no build directory. Running licensecheck on vanilla upstream sources. No licenses found. Please check the source files for licenses manually. [x]: License file installed when any subpackage combination is installed. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib/i386-linux-gnu Review: As mentioned before, this is not a standard Fedora dir. [!]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/i386-linux-gnu, /etc/binfmt.d Review: Same here. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [!]: %config files are marked noreplace or the reason is justified. Note: No (noreplace) in %config /etc/binfmt.d/box86.conf [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [ ]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 30720 bytes in 3 files. [x]: Package complies to the Packaging Guidelines [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: No %config files under /usr. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [ ]: %check is present and all tests pass. Review: Yes, but tests fail. [x]: Packages should try to preserve timestamps of original installed files. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [!]: Rpmlint is run on all installed packages. Note: Mock build failed See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_use_rpmlint [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Installation errors ------------------- INFO: mock.py version 2.6 starting (python version = 3.8.6)... Start: init plugins INFO: selinux enabled Finish: init plugins INFO: Signal handler active Start: run Start: chroot init INFO: calling preinit hooks INFO: enabled root cache INFO: enabled package manager cache Start: cleaning package manager metadata Finish: cleaning package manager metadata INFO: enabled HW Info plugin Mock Version: 2.6 INFO: Mock Version: 2.6 Finish: chroot init INFO: installing package(s): /data/rpmbuild/SPECS/box86/box86-debugsource-0.1.4-1.fc34.armv7hl.rpm /data/rpmbuild/SPECS/box86/box86-debuginfo-0.1.4-1.fc34.armv7hl.rpm /data/rpmbuild/SPECS/box86/box86-0.1.4-1.fc34.armv7hl.rpm ERROR: Command failed: # /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 34 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk install /data/rpmbuild/SPECS/box86/box86-debugsource-0.1.4-1.fc34.armv7hl.rpm /data/rpmbuild/SPECS/box86/box86-debuginfo-0.1.4-1.fc34.armv7hl.rpm /data/rpmbuild/SPECS/box86/box86-0.1.4-1.fc34.armv7hl.rpm --setopt=tsflags=nocontexts Rpmlint ------- Checking: box86-0.1.4-1.fc34.armv7hl.rpm box86-debuginfo-0.1.4-1.fc34.armv7hl.rpm box86-debugsource-0.1.4-1.fc34.armv7hl.rpm box86-0.1.4-1.fc31.src.rpm box86.armv7hl: W: executable-stack /usr/bin/box86 box86.armv7hl: W: conffile-without-noreplace-flag /etc/binfmt.d/box86.conf box86.armv7hl: W: no-manual-page-for-binary box86 box86.src:56: E: hardcoded-library-path in %{_prefix}/lib/i386-linux-gnu/libgcc_s.so.1 box86.src:57: E: hardcoded-library-path in %{_prefix}/lib/i386-linux-gnu/libstdc++.so.5 box86.src:58: E: hardcoded-library-path in %{_prefix}/lib/i386-linux-gnu/libstdc++.so.6 4 packages and 0 specfiles checked; 3 errors, 3 warnings. Source checksums ---------------- https://github.com/ptitSeb/box86/archive/v0.1.4/box86-0.1.4.tar.gz : CHECKSUM(SHA256) this package : be4a026310c90ff0171d13bd492fc8a3e7f84e3f494eb2cdf0f96d1566f3a1bc CHECKSUM(SHA256) upstream package : be4a026310c90ff0171d13bd492fc8a3e7f84e3f494eb2cdf0f96d1566f3a1bc Requires -------- box86 (rpmlib, GLIBC filtered): config(box86) ld-linux-armhf.so.3 libc.so.6 libdl.so.2 libgcc_s.so.1 libgcc_s.so.1(GCC_3.5) libm.so.6 libpthread.so.0 librt.so.1 rtld(GNU_HASH) box86-debuginfo (rpmlib, GLIBC filtered): box86-debugsource (rpmlib, GLIBC filtered): Provides -------- box86: box86 box86(armv7hl-32) config(box86) box86-debuginfo: box86-debuginfo box86-debuginfo(armv7hl-32) debuginfo(build-id) box86-debugsource: box86-debugsource box86-debugsource(armv7hl-32)
*** Bug 1800429 has been marked as a duplicate of this bug. ***
Hello, any updates on this? :) I saw the duplicate bug request was closed.
(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.
> This package is known to only work on arm. Though, I'd try to build on all possible architectures anyways without caring about usefulness. Fedora policy suggests to hardly try to avoid any excluded architecture if the package successfully builds there somehow. "Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line." https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures
(In reply to Raphael Groner from comment #5) > > This package is known to only work on arm. > > Though, I'd try to build on all possible architectures anyways This is the package description: "Box86 lets you run x86 Linux programs (such as games) on non-x86 Linux, like ARM (host system needs to be 32bit little-endian)." So this package MUST be 32bit by design and "of course" building it on x86 is not relevant are the software intend to translate x86 binaries into something else 32 bit, little endian. So arm is really the only relevant architecture, unless you ignore what's the package is about. > "Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, > describing the reason that the package does not compile/build/work on that This is fine for most packages that incidentally don't build for an architecture whereas they should do. The difference here is that this package is not "designed" to build on others architectures (specially not 64bit ones as it's described on the upstream project). For the very same reason that wine 64bit cannot translate 32bit windows executable and vis versa)... I hope that it's clear enough... The only issue remains that to translate x86 linux binaries for arm, there is a need to install some x86 dependencies on the host. And if using fedora packages, then there is a path clash to be expected. (as x86 and arm libraries are using the same /usr/lib/ path). So this package looks very complex to use on the fedora side. (unless using x86 binary with only a deps on libc++). I only expect to build a dedicated chroot with x86 libraries and libstdc++ replaced by box86... But that's so unusual that I don't expect this package to land in fedora officially, so unless one has a better idea, there is my copr...
Official support for emulation of x86 (32 bits) only is poor but more than nothing. What about aarch64 then?
(In reply to Raphael Groner from comment #7) > Official support for emulation of x86 (32 bits) only is poor but more than > nothing. What about aarch64 then? Aarch64 been a 64bit architecture, there is no plan for box86 to support it, ever.
Propably answers at (virtual) FOSDEM stand: https://stands.fosdem.org/stands/box86/main/
Ping. What's the state here? As my initially another review request was overwhelmed with this one any progress would be nice.
> Ping. What's the state here? As my initially another review request was overwhelmed with this one any progress would be nice. Packaging is clean on the packaging wide.IMO. Only usability is to be proven. See next. > The only issue remains that to translate x86 linux binaries for arm, there is a need to install some x86 dependencies on the host. And if using fedora packages, then there is a path clash to be expected. (as x86 and arm libraries are using the same /usr/lib/ path). So this package looks very complex to use on the fedora side. (unless using x86 binary with only a deps on libc++). I only expect to build a dedicated chroot with x86 libraries and libstdc++ replaced by box86... This runtime test need to be proven for the package to be usable at all.
Any progress on this?
Well, there's now also box64 for emulation with 64 bits but both box86 (with 32 bits) and box64 are incompatible. Someone should create another request for box64.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
Box86 is unlikely to be relevant now that armhfp has faded out on fedora higher than 36. If some want to still relies on it, I have it packaged in this copr repository https://copr.fedorainfracloud.org/coprs/kwizart/grate-driver/packages/ Please note that I'm still unable to verify the usability on fedora where we are not (compared to debian) a multiarch distro.