Some mkosi fixes

[Vogtinator]

With the .sha256 file generation, Repotype: checksumsfile should work.

CC @bluca

[bluca]

Any chance publishing the recipe can be salvaged? It is very nice to be able to reproduce them. Can they be in a directory named after the image or so?

[Vogtinator]

Any chance publishing the recipe can be salvaged? It is very nice to be able to reproduce them. Can they be in a directory named after the image or so?

To make them unique, they would have to be named after the package + multibuild flavor.

What's the use case you have in mind?

[bluca]

I don't have a specific use case in mind, just that I remember from when we added livebuild support, the fact that you could download images but not recipes without an account was an issue, and I didn't want a repeat. It's not a huge issue, if there's no alternative that's fine.

[mlschroe]

Your sha256 files contain the full path, which is probably not intended. How about something simpler like:

    for f in "$BUILD_ROOT/$TOPDIR"/OTHER/* ; do
        test -f "$f" && chroot "$BUILD_ROOT" sh -c "cd /$TOPDIR/OTHER && sha256sum \"${f##*/}\" > \"${f##*/}.sha256\""
    done

(untested)

[Vogtinator]

Your sha256 files contain the full path, which is probably not intended. How about something simpler like:

Indeed, fixed. Slightly differently though, with just a single chroot still

[Vogtinator]

I don't have a specific use case in mind, just that I remember from when we added livebuild support, the fact that you could download images but not recipes without an account was an issue, and I didn't want a repeat. It's not a huge issue, if there's no alternative that's fine.

IMO the repo shouldn't be used for publishing sources as-is, there are better ways for distribution. IMO the current state doesn't really make sense anyway as the recipe file on its own is incomplete without the other source files.

We can also keep the recipe file as build result and just ignore it during publishing. I'm wondering what we need it for, maybe for image build dependencies?

[bluca]

I don't have a specific use case in mind, just that I remember from when we added livebuild support, the fact that you could download images but not recipes without an account was an issue, and I didn't want a repeat. It's not a huge issue, if there's no alternative that's fine.

IMO the repo shouldn't be used for publishing sources as-is, there are better ways for distribution. IMO the current state doesn't really make sense anyway as the recipe file on its own is incomplete without the other source files.

We can also keep the recipe file as build result and just ignore it during publishing. I'm wondering what we need it for, maybe for image build dependencies?

The manifest is used for build dependencies, at least that was the intention in 1bead5d so yeah this should be fine to drop

[thkukuk]

I don't have a specific use case in mind, just that I remember from when we added livebuild support, the fact that you could download images but not recipes without an account was an issue, and I didn't want a repeat. It's not a huge issue, if there's no alternative that's fine.

Sorry for the late response, was on vacation.
If you take my repository for building sysext images for MicroOS with mkosi as example, the mkosi.conf file alone is pretty useless. You need the files in the mkosi.images subdirectory, too. And here it starts: you need to parse the config to find all referenced directories and other files. I prefer the solution we do for kiwi files: create an extra RPM with all required files from it.

https://github.com/thkukuk/microos-sysext
https://build.opensuse.org/project/monitor/home:kukuk:sysext

[bluca]

I don't have a specific use case in mind, just that I remember from when we added livebuild support, the fact that you could download images but not recipes without an account was an issue, and I didn't want a repeat. It's not a huge issue, if there's no alternative that's fine.

Sorry for the late response, was on vacation. If you take my repository for building sysext images for MicroOS with mkosi as example, the mkosi.conf file alone is pretty useless. You need the files in the mkosi.images subdirectory, too. And here it starts: you need to parse the config to find all referenced directories and other files. I prefer the solution we do for kiwi files: create an extra RPM with all required files from it.

https://github.com/thkukuk/microos-sysext https://build.opensuse.org/project/monitor/home:kukuk:sysext

Yeah makes sense, I've already approve this, thanks.

BTW in that example, which looks great by the way, you are building both base and extensions in the same build - is anyone working on finishing the image-dependency-handling integration in OBS so that you can build the base and the extension separately? The idea being that for example in the MicroOS case, the base would be built in the MicroOS project itself, and then users can build-depend on it and build their own extensions in their own projects

[thkukuk]

BTW in that example, which looks great by the way, you are building both base and extensions in the same build - is anyone working on finishing the image-dependency-handling integration in OBS so that you can build the base and the extension separately? The idea being that for example in the MicroOS case, the base would be built in the MicroOS project itself, and then users can build-depend on it and build their own extensions in their own projects

I would be already more than happy if we get full basic support for mkosi in OBS, like publishing the images with signed meta data to make it directly usable by importctl and systemd-sysupdate.
Currently I have no resources to do more and I don't see anybody else working on it.
Maybe this changes if we have this fully integrated in MicroOS and SL Micro 6.x and customer demand is there.