solbuild: Drop fakeroot use, use eopkg.bin

[ermo]

Summary

Adds the new solbuild with no-fakeroot functionality.

Important note: Landing this PR to -unstable needs to be followed up by updating the solbuild image, otherwise we will get some really annoying failures related to libglib-json moving certain files to a -devel subpackage IIUC.

Depends on #4063 and should be landed after it.

Test Plan

• Complete the Test Plan for pisi/eopkg: Add versioned FilesDB and LazyDB instances #4063 first
• Check out the branch associated with the present PR
• Build solbuild with go-task localcp and install it
• Run solbuild version and check that it shows 1.7.0
• Check out the branch from pisi/eopkg: Add versioned FilesDB and LazyDB instances #4063 again
• Demonstrate to yourself that the two PRs taken together are self-hosting:
  • Re-build pisi, eopkg, ypkg from the 4063 branch w/ go-task localcp and re-install each of them after each build completes
  • Switch back to the present solbuild branch, and rebuild solbuild with go-task localcp and re-install it after the build completes
  • It is important that you do not clean the Local repo cache before doing this!
  • Once again, pay attention to the FilesDB (version: output. It should shift from being version 3 to version 4 from eopkg and onwards, which is a sign that the new solbuild is now asking ypkg-install-deps to use eopkg.bin to install deps (it was hardcoded to eopkg -> eopkg.py2 in ypkg before).
• Build a bunch of packages of your choice (using go-task local or go-task localcp) to test the new tooling versions.
  • Again, pay special attention to the FilesDB (version: output in the build logs.
  • If you do, you will realise that the FilesDB is getting rebuilt during each build. This is because the solbuild backing image has not yet been generated with the new version of eopkg.bin. Once the pisi/eopkg: Add versioned FilesDB and LazyDB instances #4063 PR and the present PR has been landed, we can then update the solbuild images to also use eopkg.bin and FilesDB (version: 4).

Checklist

• Package was built and tested against unstable

[androidnisse]

I have tried this with the new cargo macro to be able to use multiple binaries but still seems to get issues.
https://gist.github.com/androidnisse/5ed5bc83c5169e7e8c1263013a8f0879
https://gist.github.com/androidnisse/34090b8177211a24f9540e64d10398f3

[malfisya]

Tested this PR with pcsx2 and gapless. Seems OK so far

[ermo]

I have tried this with the new cargo macro to be able to use multiple binaries but still seems to get issues. https://gist.github.com/androidnisse/5ed5bc83c5169e7e8c1263013a8f0879 https://gist.github.com/androidnisse/34090b8177211a24f9540e64d10398f3

From what I remember from Serpent OS, @ReillyBrogan also added default RUSTFLAGS that explicitly makes Rust use the release profile, but adds the necessary debugging options for that. Looking at ypkg, it seems like those changes never made it across for safe use of the %cargo family of macro actions? 🤔

[davidjharder]

I get this error Nope, see later comment

 🗲  Package has explicitly requested networking, sandboxing disabled
 ✓  Now starting build package=hugo
usage: ypkg-build [-h] [-n] [-v] [-t TIMESTAMP] [-D OUTPUT_DIR] [filename]
ypkg-build: error: unrecognized arguments: -B /home/build/work/package.yml

[Staudey]

I have tried this with the new cargo macro to be able to use multiple binaries but still seems to get issues. https://gist.github.com/androidnisse/5ed5bc83c5169e7e8c1263013a8f0879 https://gist.github.com/androidnisse/34090b8177211a24f9540e64d10398f3

Doesn't look like this is using the new ypkg

+ '[' 4 -eq 1 ']'

That's the old logic
getsolus/ypkg@c7074c2

[HarveyDevel]

Same error as David.

 ✓  Now starting build package=firefox
usage: ypkg-build [-h] [-n] [-v] [-t TIMESTAMP] [-D OUTPUT_DIR] [filename]
ypkg-build: error: unrecognized arguments: -B /home/build/work/package.yml
 ✗  Failed to build packages err="Failed to start build of package, reason: exit status 2\n"
task: Failed to run task "build": exit status 1

[davidjharder]

Staudey clued me in: subsequent builds also have to use task localcp

ermo, I edited your description slightly to point this out.

[HarveyDevel]

I could not build firefox 130.0.1 without tmpfs so I tried this however it fails with a different error:

https://gist.githubusercontent.com/HarveyDevel/35b4f24bf0f7e54e21ecd7a31ac88936/raw/37cb0567749c5ff659ee17a85f0a95063cccf42a/build.log

[ermo]

Staudey clued me in: subsequent builds also have to use task localcp

ermo, I edited your description slightly to point this out.

Subsequent builds can use either the local or localcp targets (the latter also copies the build artifacts to the local repo in addition to building against the local-unstable-x86_64 profile).

Test plan in OP updated to reflect this.

[ermo]

I could not build firefox 130.0.1 without tmpfs so I tried this however it fails with a different error:

https://gist.githubusercontent.com/HarveyDevel/35b4f24bf0f7e54e21ecd7a31ac88936/raw/37cb0567749c5ff659ee17a85f0a95063cccf42a/build.log

Looks like the cache dir logic might not work properly yet -- possibly due to permissions. Any chance you could chroot into the failed build and check the permissions of the sccache path in the log?

[HarveyDevel]

It appears only YPKG/sources remains so I could not check sccache only cache which it also complained about in the log.

WARNING: The directory '/home/build/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.

drwxr-xr-x 5 build build 4.0K Sep 18 00:12 .cache

[androidnisse]

I have tried this with the new cargo macro to be able to use multiple binaries but still seems to get issues. https://gist.github.com/androidnisse/5ed5bc83c5169e7e8c1263013a8f0879 https://gist.github.com/androidnisse/34090b8177211a24f9540e64d10398f3

Doesn't look like this is using the new ypkg

+ '[' 4 -eq 1 ']'

That's the old logic getsolus/ypkg@c7074c2

Yes, I seemed to have used the old ypkg so my report can be dismissed.

[joebonrichie]

I could not build firefox 130.0.1 without tmpfs so I tried this however it fails with a different error:

https://gist.githubusercontent.com/HarveyDevel/35b4f24bf0f7e54e21ecd7a31ac88936/raw/37cb0567749c5ff659ee17a85f0a95063cccf42a/build.log

getsolus/solbuild#110

[HarveyDevel]

Patched it locally now firefox will fail at the xvfb-run step:

https://gist.githubusercontent.com/HarveyDevel/dc5cd6e0fa64fab41be77a7fa8b65d40/raw/28f20ce16e44214777f12470eff08925dcf170fe/build.log

WARNING: The directory '/home/build/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you should use sudo's -H flag.
Running Firefox as root in a regular user's session is not supported. ($HOME is /home/build which is owned by build.)
started SP3 server on port 8000
Firefox exited with code 1 during profile initialization

[ermo]

@joebonrichie what if we changed the build dir to /root?

I think firefox is being too smart for its own good here.

[joebonrichie]

ypkg is failing to find seemingly specifically glib2 libs with fakeroot-less solbuild. So won't add the needed dep on glib2 in some circumstances.

[Build] install successful (0:00:00.196609)
[Examine] Examining packages
[Stripped] /usr/bin/g-ir-generate
[Stripped] /usr/bin/g-ir-inspect
[Stripped] /usr/bin/g-ir-compiler
[Stripped] /usr/lib64/gobject-introspection/giscanner/_giscanner.cpython-311-x86_64-linux-gnu.so
[Stripped] /usr/lib64/libgirepository-1.0.so.1.0.0
[Dependency] /usr/bin/g-ir-compiler adds dependency on libffi.so.7 from libffi
Fatal: Unknown symbol: libgobject-2.0.so.0
Fatal: Unknown symbol: libglib-2.0.so.0
[Dependency] /usr/bin/g-ir-compiler adds dependency on libgio-2.0.so.0 from glib2
[Dependency] /usr/bin/g-ir-compiler adds dependency on libc.so.6 from glibc
[Dependency] /usr/bin/g-ir-compiler adds dependency on libm.so.6 from glibc
[Dependency] /usr/bin/g-ir-generate adds dependency on libglib-2.0.so.0 from glib2
[Dependency] /usr/lib64/gobject-introspection/giscanner/_giscanner.cpython-311-x86_64-linux-gnu.so adds dependency on libgobject-2.0.so.0 from glib2
[Dependency] /usr/lib64/libgirepository-1.0.so.1.0.0 adds dependency on libgmodule-2.0.so.0 from glib2
[PKGCONFIG] gobject-introspection-devel adds dependency on glib2-devel
[Package] Creating /home/build/work/gobject-introspection-devel-1.80.1-38-1-x86_64.eopkg ...
[Package] gobject-introspection-devel-1.80.1-38-1-x86_64.eopkg took 0:00:00.041677 to emit
[Package] Creating /home/build/work/gobject-introspection-1.80.1-38-1-x86_64.eopkg ...
[Package] gobject-introspection-1.80.1-38-1-x86_64.eopkg took 0:00:00.079748 to emit
[Package] Building complete

[ermo]

The version I just pushed was synced with solbuild git master, which is in a 1.7.0-pre state currently.

[joebonrichie]

Depends on getsolus/eopkg#87 and requires the solbuild image to be rerolled with eopkg.bin so files4.db gets created.

[ermo]

The latest version of this no longer uses files4.db and will correctly autoupgrade/create /var/lib/eopkg/info/files.db as necessary, provided that the Test Plan from #4063 is completed first.

[ermo]

Note: I have double bumped this past the solbuild release that staff have been using for local tests, hence the failing tests.

[TraceyC77]

I've tested this and the related PR with the test plan.
I built syncthing 1.28.0 using the updated tooling. Verified it was using FilesDB v4 and built successfully.

Installing 1 / 23
perl-net-ssleay-1.94-18-1-x86_64.eopkg [cached]
Installing perl-net-ssleay, version 1.94, release 18
Rebuilding the FilesDB...
Adding packages to FilesDB /var/lib/eopkg/info/files.db:
....
228 packages added in total.
Done rebuilding FilesDB (version: 4)
``

This has *not* fixed the issue with eopkg showing there is an update to `qtkeychain-qt5-devel` when it is up to date. I'll open a separate issue for that in the eopkg repo

[silkeh]

Tested this as per getsolus/solbuild#77. LGTM!