| mazzy | fungi, mordred: i have a question about the dib. so i'm approaching to create an image for flatcar. what it's not clear to me is the concept of base image. for base image you mean the environment where the building will happen and that then will be discarded or is it the image from which the final OS image is based on? | 08:00 |
|---|---|---|
| mazzy | i'm asking because in the case of flatcar, the doc says | 09:51 |
| mazzy | The SDK chroot has a full toolchain and isolates the build process from quirks and differences between host OSes. The SDK must be run on an x86-64 Linux machine, the distro should not matter (Ubuntu, Fedora, etc). | 09:51 |
| mazzy | so in my case the base image can be ubuntu? | 10:02 |
| fungi | mazzy: a bit of context might help. it looks like dib uses the term "base image" in reference to an image creation mode which starts with an existing image mounted on a loop device as the initial chroot and then modifies that as instructed by subsequent elements. an alternative is the -minimal variants it has for some platforms, where its "base image" is effectively an empty chroot and then | 12:29 |
| fungi | some tools run on the host system (installed outside the chroot) are used to bootstrap packages into that chroot (debootstrap, rpmstrap, et cetera) | 12:29 |
| fungi | i don't know if the term "base image" is entirely standardized in dib, for example the gentoo element's readme refers to it as a "baseline" instead: https://docs.openstack.org/diskimage-builder/latest/elements/gentoo/README.html | 12:31 |
| mordred | yeah. so it seems to me that the flatcar sdk it more akin to debootstrap in structure | 13:10 |
| mordred | I'd look at making an element similar to the debootstrap one - it should be a similar pattern at least | 13:12 |
| mazzy | more, fungi: thanks guys. I'll try to follow the structure of debootstrap | 13:34 |
| corvus | mordred: i think i found a minory issue with https://review.opendev.org/806448 | 14:18 |
| corvus | mordred: but the rest lgtm -- and i did end up tracing through all of it :) | 14:18 |
| mordred | corvus: you're right. I think let's pin 3.7 to latest since that's the default in the dockerfile | 14:40 |
| corvus | mordred: ++ | 14:41 |
| opendevreview | Monty Taylor proposed opendev/system-config master: Produce both buster and bullseye container images https://review.opendev.org/c/opendev/system-config/+/806448 | 14:44 |
| mordred | clarkb: thanks for the weird ARG fix | 14:45 |
| corvus | mordred: lgtm :) | 14:46 |
| mazzy | mordred: i was looking at the debootstrap element but perhaps i'm missing some repos becuase i do not get where the actual fetching of the debootstrap tar is made https://github.com/openstack/diskimage-builder/blob/a6ee4d0c217335cf83ca9a42de78263d085ab839/diskimage_builder/elements/debootstrap/root.d/08-debootstrap#L33 according the pattern I would | 20:09 |
| mazzy | expect that debootstrap elemenet would use cache-url element to populate the cache with the tar but i didn't find the actual pulling of the the tar defined in the env var. what am i missing? | 20:09 |
| fungi | mordred: the system-config-upload-image-matrix-eavesdrop POST_FAILURE on your https://review.opendev.org/806448 is truly baffling me | 22:39 |
| fungi | i'll set an autohold on it if you don't have any immediate ideas | 22:39 |
| mordred | fungi: haven't looked yet, but we've been seeing issues during cleanup phase. | 22:54 |
| fungi | mordred: it's consistently complaining "Release 'buster-backports' for 'libolm-dev' was not found" even though https://packages.debian.org/buster-backports/libolm-dev is a thing | 23:14 |
| fungi | did it again on recheck | 23:14 |
| fungi | makes me wonder if there's a problem with the backports suite | 23:15 |
| corvus | fungi, mordred: i think we need one more update based on latest change | 23:19 |
| corvus | fungi, mordred: left comment -- i think we need to specify the -bullseye tag in the matrix-eavesdrop image | 23:21 |
| corvus | though, tbh, i'm not 100% sure on that | 23:23 |
| corvus | because no matter what image it got, it should have installed the backports repo? | 23:24 |
| corvus | looking at the build steps in https://zuul.opendev.org/t/openstack/build/b5cfc966fe0c4dc586417905a47125bc i don't see it pulling from backports | 23:25 |
| corvus | during the apt-get update | 23:25 |
| corvus | yeah actually this should all be working for -buster, so my comment is wrong | 23:26 |
| corvus | oh! i see it. | 23:29 |
| corvus | fungi, mordred: okay, updated comments. it's not mordred's fault. The gate pipeline configuration was wrong (the 'build' vs 'upload' job dep error) | 23:30 |
| corvus | our first clue should have been "it worked in check but not gate" :) | 23:31 |
| fungi | good point, i wondered if we were just not running that job in check, i should have looked :/ | 23:32 |
| corvus | i'll go ahead and update the change | 23:45 |
| opendevreview | James E. Blair proposed opendev/system-config master: Produce both buster and bullseye container images https://review.opendev.org/c/opendev/system-config/+/806448 | 23:46 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!