Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

solbuild: Drop fakeroot use, use eopkg.bin #3850

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

ermo
Copy link
Contributor

@ermo ermo commented Sep 16, 2024

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
Copy link
Contributor

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
Copy link
Member

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

@ermo
Copy link
Contributor Author

ermo commented Sep 17, 2024

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
Copy link
Member

davidjharder commented Sep 17, 2024

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
Copy link
Member

Staudey commented Sep 17, 2024

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
Copy link
Member

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
Copy link
Member

davidjharder commented Sep 17, 2024

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

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

@HarveyDevel
Copy link
Member

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
Copy link
Contributor Author

ermo commented Sep 18, 2024

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
Copy link
Contributor Author

ermo commented Sep 18, 2024

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

ermo commented Sep 19, 2024

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

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

@joebonrichie
Copy link
Contributor

joebonrichie commented Sep 19, 2024

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 ermo changed the title No fakeroot solbuild solbuild: Stop using fakeroot, start using eopkg.bin Sep 21, 2024
@ermo ermo changed the title solbuild: Stop using fakeroot, start using eopkg.bin solbuild: Drop fakeroot use, use eopkg.bin Sep 21, 2024
@ermo ermo force-pushed the no-fakeroot-solbuild branch 2 times, most recently from 13cefcc to 3d9df18 Compare September 22, 2024 09:47
@ermo
Copy link
Contributor Author

ermo commented Sep 22, 2024

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

@joebonrichie
Copy link
Contributor

joebonrichie commented Sep 26, 2024

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

@ermo
Copy link
Contributor Author

ermo commented Oct 16, 2024

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.

This commit represents a 1.7.0 pre-release build.

In my tests, dropping fakeroot is always a bonus.

Using eopkg.bin instead of eopkg.py2 can add a slight wall clock overhead.

However, this is offset by eopkg.bin being immune to py3 stack upgrade
work, which will become increasingly necessary as we work toward removing
python2 and eopkg.py2.

Note: The present relase still uses eopkg.py2 to build old pspec.xml pkgs.

Signed-off-by: Rune Morling <[email protected]>
By default, this will be eopkg.bin, which in turn means that the solbuild
images should be built w/eopkg.bin, so the FilesDB doesn't continuously
get rebuilt on solbuild build invocations due to the new eopkg FilesDB
auto-upgrade code.

The end result is that we will no longer be using eopkg.py2 in our build
pipeline. Yay.

Signed-off-by: Rune Morling <[email protected]>
@ermo ermo added Platform Integration Integration of various components within Solus Plumbing Core components Tooling Tools and scripts labels Oct 20, 2024
@ermo ermo added this to the Solus 4.7 milestone Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform Integration Integration of various components within Solus Plumbing Core components Tooling Tools and scripts
Projects
Status: In Progress
Status: In Progress
Development

Successfully merging this pull request may close these issues.

7 participants