Cayetano Santos <[email protected]> writes: >>dim. 08 mars 2026 at 18:24, Rutherther <[email protected]> wrote: > >> Hello, >> >> Cayetano Santos <[email protected]> writes: >> >>> Hi Guix, >>> >>> Regarding a system.scm [0] file, this command >>> >>> image=$(guix system image --image-type=qcow2 --image-size=16GB >>> --save-provenance system.scm) >>> >>> Produces always the same image (corresponding to guix log tag v1.5.0), >> >> How exactly are you checking that? I am asking since the guix inside of >> the image would be 1.5.0 till yesterday, that is correct. Guix package >> was never updated past 1.5.0 until yesterday. So till yesterday, the >> `guix describe` in the image would always be producing the 1.5.0 tag >> commit. > > I’m building the image (today), then I ssh into it, and I’m using ‘guix > describe’, which returns "guix 230aa37", so v1.5.0. > >> `guix system describe` should be used to read the system provenance. > > Ah ! Here I get the same as the ‘guix describe’ in the machine used to > build the image, so a recent revision (in my local replication).
So then all is as expected. If you want the target image to have a newer guix, you will have to use something like (current-guix) in the guix-service-type's configuration, in the guix field. > > >>> regardless of the status of current guix. I would intuitively expect >>> it instead to build an up to date image, identical to current local >>> guix. Or at least, this was my first intuition about a rolling release. >>> >>> Is this correct, or am I doing something wrong ? Is there a means to >>> produce an up to date image, other than building v1.5.0 followed by a >>> guix pull ? This approach is problematic, as the time it takes >>> increases with the number of commits since v1.5.0, which following the >> >> So it seems there should be a cache if the build system here supports >> that. Or a newer tarball should be built instead of doing guix pull. > > The thing is that, in sr.ht, once a day we launch yesterdays’ image, > then we build a new one on disk, ssh into it, do by a guix pull and the > resulting image replaces the older. >> > >>> [0] >>> https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/guix/system.scm >>> [1] https://builds.sr.ht/~sircmpwn/refresh/guix > >> This log has no guix describe for later, so it's impossible to know what >> guix has been used during the build. > > If you scroll down (only timeout logs, forget failures due to network), > you’ll see how during the pulling stage the number of commits increases > everyday, the reason being that we start everyday from v1.5.0, then we > pull everything since then. But that doesn't tell you the guix you are actually using. That's what the guix describe would be for, validating the guix being used is the one you pulled. As a proxy, you would use the provenance - `guix system describe` to know what guix produced the image. > >> Also, what does the provenance inside of the image look like? (in >> /var/guix/profiles/system/provenance, or through `guix system describe`)? > > IIUC, provenance gives the channel config of the system where the image > is built, so the last one to build, before it started failing. > > The problem remains the same, how can I produce an up to date image as > for ‘guix descrive’, starting from an up to date system, avoiding You are producing an up to date image! > pulling all commits since v1.5.0 ? Probably this is due to my > misunderstanding on how system image operates, but I always thought that No, it is not a misunderstanding on how system image operates, it is a misunderstanding on where the `guix` executable comes from in a Guix system. It comes from the guix-service-type service that defaults to the guix package. And that package happened to be 1.5.0 for the whole time since 1.5.0. Just use (current-guix) or (guix-for-channels ...) in place of the package if you want to have the same guix as your current guix on the target. However, this will prolong the whole build as guix derivation will need to be computed once more. > building a new image effectively produced an up to date system, not an > old one. It does produce a system built from the guix executable executing guix system image. So an up to date image. > But if we’re building always the same, "230aa37", pulling takes longer and > longer, until it times out. And so the utilily of building a new image, > based on current one, pulling only commits since yesterday. I am doubtful using current guix would help, though. Note the correspondence of the first failure being with the glibc graft. (graft 20th of Feb, failing build 21st of Feb) Since that time the guix pull is just going to take longer. Even if you update guix, you won't have the ungrafted packages, only the grafted ones, so the ungrafted will need to be realized again first. Well you can try, maybe I am wrong, you will see. Also, if you want to prevent reauthentication of the checkout, you will have to persist the ~/.cache/guix. I don't think using newer guix inside of the image would help that situation in any way. Note that there is over 6k commits since 1.5.0, so the number in the latest build, being Authenticating channel 'guix', commits 9edb3f6 to 1a73454 (1,761 new commits)... does not correspond to that. You already seem to be using the cache from the earlier images somehow. Rutherther PS: Is there a good reason for using -v0? It leaves you blind to these kind of changes. Just did guix gc, trying to guix pull ``` > guix pull Updating channel 'guix' from Git repository at 'https://git.guix.gnu.org/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 3c078b5 (747 new commits)... Building from this channel: guix https://git.guix.gnu.org/guix.git 3c078b5 substitute: looking for substitutes on 'https://nonguix-proxy.ditigal.xyz'... 100.0% substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0% 16.7 MB will be downloaded guile-3.0.9-debug 7.8MiB 5.6MiB/s 00:01 ▕██████████████████▏ 100.0% substitute: looking for substitutes on 'https://nonguix-proxy.ditigal.xyz'... 100.0% substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0% 0.0 MB will be downloaded bash-minimal-5.2.37-doc 321KiB 3.4MiB/s 00:00 ▕██████████████████▏ 100.0% substitute: looking for substitutes on 'https://nonguix-proxy.ditigal.xyz'... 100.0% substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0% 1.1 MB will be downloaded bash-static-5.2.37-doc 321KiB 3.9MiB/s 00:00 ▕██████████████████▏ 100.0% substitute: looking for substitutes on 'https://nonguix-proxy.ditigal.xyz'... 100.0% substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 100.0% ``` Now again gc and with -v0 ``` > guix pull -v0 Updating channel 'guix' from Git repository at 'https://git.guix.gnu.org/guix.git'... Building from this channel: guix https://git.guix.gnu.org/guix.git 3c078b5 Computing Guix derivation for 'x86_64-linux'... / ``` With this you could possibly see a change starting from 21st of Feb of increased number of downloads, causing the failure due to extra time taken here. > > All in all, I need to produce an (updated since last time) clone image > from current one, saving it as qcow2. I hope this is clear. > > Thanks for you help ! > > C.
