backporting systemd v228 for Leap; @ install, "nothing provides this-is-only-for-build-envs"?

English Open Build Service (OBS)
1

I want to use systemd-boot for UEFI boot on openSUSE Leap 42.1.

Leap’s systemd is at v = systemd-210-86.1.x86_64.

systemd-boot available for v >= 220.

Base:System provides build for latest systemd, v = 228.

I’m attempting to build @OBS for Leap, using those sources.

I’ve managed to build ‘successfully’ – at least no errors reported – here:


    https://build.opensuse.org/package/show/home:pgnd:Base:System/systemd

When I attempt to install locally from that repo,


    zypper up systemd
        Loading repository data...
        Reading installed packages...
        Resolving package dependencies...

        Problem: nothing provides this-is-only-for-build-envs needed by systemd-228-14.1.x86_64
         Solution 1: do not install systemd-228-14.1.x86_64
         Solution 2: break systemd-228-14.1.x86_64 by ignoring some of its dependencies

The prjconf


    https://build.opensuse.org/project/prjconf/home:pgnd:Base:System

contains


    Ignore: systemd-mini:this-is-only-for-build-envs
    Ignore: libsystemd0-mini:this-is-only-for-build-envs
    Ignore: udev-mini:this-is-only-for-build-envs
    Ignore: libudev-mini1:this-is-only-for-build-envs

which was necessary/sufficient to eliminate build-time errors @OBS.

What additional, or fixed, config is necessary to get past this uninstallable dep?

2

What happens if you simply choose option 2?
Assumes of course that you are installing into a displosable test system.

TSU

3

‘option 2’ will do exactly what it offers … ignore the dependency.

I don’t want to ignore it. I want to understand/fix it. The goal is to get to a production quality build, not a kludge/workaround.

The prjconf required the Ignores just to build.

TBH, I’ve no idea why these “nothing-provides-this-is-only-for-build-envs-quot” refs are used in the first place. There’s also a ‘bootstrap’ flag that appears to toggle these.

I was advised to ask ‘systemd-maintainers’ about this build/spec, as it’s “theirs”. I asked a couple of times; once, just ignored the question, the other I can’t manage to even get posted to the list.

So moved here, hoping to bump into some expertise on this build.

4

Unless someone else speaks up,
I suspect the dependency you’ve run into is only a way to warn the User some software critical to functionality (The subsystem systemd is absolutely critical to functionality from which there may not be any recoverable option if it fails). This is OK if you’re building only for yourself or Users are building only for specific targets but could be extremely damaging if it’s faulty and is installed by some unknown person.

So, in this case the dependency is likely not related directly to the systemd you’re running.

I don’t see that your dependency is actually an RPM but you could search your system for any files with that name and if found inspect its contents.

Just Guessing,
TSU

5

And why did you set this flag in the first place if you do not even know what it does? Do not set it and you won’t get this strange dependency. Do not touch it in spec file at all.

6

Because someone in #irc with apparent experience & actually trying to help instructed to toggle the flag.

At the time, bootstrap -> 0 failed, bootstrap ->1 worked.

7

And created minimal package intended to be used only in build root. This package is also stripped down and exists mostly to satisfy dependencies during packages build, not to be actually used on any real system.

I assume Leap is disabled for systemd in Base:System for a reason (most likely newer systemd requires newer versions of some other software). But to know for sure - please show build logs with bootstrap == 0.

8

https://build.opensuse.org/build/home:pgnd:Base:System/openSUSE_Leap_42.1/x86_64/systemd/_log

9

It does not build systemd-remote (at least) because Leap has too old version of microhttpd. I doubt you actually need it, so just remove related files from file list. Or build newer microhttpd as part of your project. The latter is probably preferable if you want exactly the same package.

And there may be other missing dependencies, you need to analyze why it fails and fix root cause.

10

I’ve addded devel:c_c++ as a project build dep – I think that should do it; building now.

More interesting to me is where/how you tracked down the too-old mictohttpd? I didn’t see any microhttpd-specific complaint in the buildlog for systemd, so clearly I’m not looking in the right place.

11 
   78s] checking for MICROHTTPD... no...
   83s]         MICROHTTPD:              no

And of course you need to know that systemd configure.ac does

PKG_CHECK_MODULES(MICROHTTPD, [libmicrohttpd >= 0.9.33],

and that it also does

AM_CONDITIONAL(HAVE_REMOTE, [test "$have_microhttpd" = "yes" -o "$have_libcurl" = "yes"])

Yes, you need to understand what code does if you want to package it.

P.S. unfortunately README does not mention minimal versions, care to file upstream issue (or patch) for it?

12

Except you won’t be able to install it because Leap does not have this version, so requirements won’t be satisfied.

13

if/when I manage to get a successful buikkd (still no, atm: Welcome - openSUSE Build Service), I’ll gather all & do so.

Unfortunately, this OBS build is a kludge atm. systemd-maintainers have refused to build/release a current systemd for Leap, stating only to use TW, which is not an option here. Ideally, I’d like to use online OBS to provide the solution; not yet clear if that’s worth the continued effort, versus a clean upstream build locally.