Bug 1901665 - Review Request: box86 - Linux Userspace x86 Emulator
Summary: Review Request: box86 - Linux Userspace x86 Emulator
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1800429 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-25 18:37 UTC by Nicolas Chauvet (kwizart)
Modified: 2022-12-28 18:42 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-12-28 18:42:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicolas Chauvet (kwizart) 2020-11-25 18:37:26 UTC
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.

Comment 1 Andy Mender 2020-11-25 20:45:55 UTC
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)

Comment 2 Raphael Groner 2020-11-26 02:59:22 UTC
*** Bug 1800429 has been marked as a duplicate of this bug. ***

Comment 3 Andy Mender 2020-12-28 11:15:31 UTC
Hello, any updates on this? :)

I saw the duplicate bug request was closed.

Comment 4 Nicolas Chauvet (kwizart) 2021-01-04 08:38:24 UTC
(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.

Comment 5 Raphael Groner 2021-01-17 13:57:14 UTC
> 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

Comment 6 Nicolas Chauvet (kwizart) 2021-01-17 20:24:47 UTC
(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...

Comment 7 Raphael Groner 2021-01-18 16:51:50 UTC
Official support for emulation of x86 (32 bits) only is poor but more than nothing. What about aarch64 then?

Comment 8 Nicolas Chauvet (kwizart) 2021-01-18 17:23:22 UTC
(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.

Comment 9 Raphael Groner 2021-02-05 13:01:26 UTC
Propably answers at (virtual) FOSDEM stand: https://stands.fosdem.org/stands/box86/main/

Comment 10 Raphael Groner 2021-07-30 15:23:04 UTC
Ping. What's the state here? As my initially another review request was overwhelmed with this one any progress would be nice.

Comment 11 Nicolas Chauvet (kwizart) 2021-08-20 07:25:51 UTC
> 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.

Comment 12 fdsfsdfsdfsdfdssdfsdfds 2021-09-28 09:40:33 UTC
Any progress on this?

Comment 13 Raphael Groner 2021-09-28 14:13:36 UTC
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.

Comment 14 Package Review 2022-09-29 00:45:22 UTC
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.

Comment 15 Package Review 2022-10-30 00:45:15 UTC
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.

Comment 16 Nicolas Chauvet (kwizart) 2022-12-28 18:42:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.