Some Images jobset lack artifacts

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Vincent Legoll
Owner
unassigned
Submitted by
Vincent Legoll
Severity
normal
V
V
Vincent Legoll wrote on 15 Jun 21:43 +0200
(name . Bug Guix)(address . bug-guix@gnu.org)
CAEwRq=q3XeJ8E-TYmsEyRb5phX7FuL0k205ah==X2_wuh7nfgw@mail.gmail.com
Hello,

I wanted to try a fresh guix in a VM, but the "Download / Latest"
page (1) does not have the:
"QCOW2 virtual machine (VM) image"
"GNU Guix 1.4.0 QEMU Image"
that is available on the "Download / Standard" page (2)

BTW, DL latest page also lacks checksum files to verify integrity.

So I looked at the CI, in the images jobset page (3), and strangely,
some jobs have "Build outputs" download links (but no checksum either),
whereas some other only have "Outputs" which is a store file path:

have downloadable artifacts:
hurd-barebones.qcow2
iso9660-image
pine64-barebones-raw-image
pinebook-pro-barebones-raw-image

no downloadable artifacts:
novena-barebones-raw-image
disk-image

Is that intended or an oversight ?

I think if this is fixed (missing artifacts and checksums), that page
could replace the "Download / Latest" one and the menu link could
directly link here.

WDYT ?


--
Vincent Legoll
L
L
Ludovic Courtès wrote on 24 Jun 10:49 +0200
(name . Vincent Legoll)(address . vincent.legoll@gmail.com)(address . 71577@debbugs.gnu.org)
87wmmek9nl.fsf@gnu.org
Hi Vincent,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

Toggle quote (6 lines)
> I wanted to try a fresh guix in a VM, but the "Download / Latest"
> page (1) does not have the:
> "QCOW2 virtual machine (VM) image"
> "GNU Guix 1.4.0 QEMU Image"
> that is available on the "Download / Standard" page (2)

This is now fixed:


For the record, the problem was that we’d be removing GC roots too
early, which was fixed here:


Toggle quote (2 lines)
> BTW, DL latest page also lacks checksum files to verify integrity.

Since this process is automated, there cannot be a signature to verify
the authenticity of those binaries (integrity is most likely verified
indirectly via embedded checksums in the container formats).

Toggle quote (6 lines)
> no downloadable artifacts:
> novena-barebones-raw-image
> disk-image
>
> Is that intended or an oversight ?

I think it was intentional that we’d only provide the “most useful”
images for download. If you think others should be added, please let’s
discuss it on guix-devel.

Thanks!

Ludo’.
L
L
Ludovic Courtès wrote on 24 Jun 10:49 +0200
control message for bug #71577
(address . control@debbugs.gnu.org)
87v81yk9nc.fsf@gnu.org
close 71577
quit
V
V
Vincent Legoll wrote on 24 Jun 20:30 +0200
Re: bug#71577: Some Images jobset lack artifacts
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 71577@debbugs.gnu.org)
CAEwRq=pM8v6b7ZT+xdmZqWy9ag56CuQcXQct1MtGDFMbdKat9Q@mail.gmail.com
Hello Ludo,

On Mon, Jun 24, 2024 at 8:49?AM Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (19 lines)
> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>
> > I wanted to try a fresh guix in a VM, but the "Download / Latest"
> > page (1) does not have the:
> > "QCOW2 virtual machine (VM) image"
> > "GNU Guix 1.4.0 QEMU Image"
> > that is available on the "Download / Standard" page (2)
>
> This is now fixed:
>
> https://guix.gnu.org/en/download/latest/
>
> For the record, the problem was that we’d be removing GC roots too
> early, which was fixed here:
>
>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=489fc437c7b3aa0af41a40d6090eb4c51ced0028
>

Yes, I remember seeing some discussion about this.

But I tried to have a new look at :

But with another browser, another computer, reloading the page in firefox,
or even forced reloading (CTRL+F5) I'm still not seeing the x86_64 qcow2.

Is there some propagation delay, or something on my side that is wrong ?


Toggle quote (7 lines)
> > BTW, DL latest page also lacks checksum files to verify integrity.
>
> Since this process is automated, there cannot be a signature to verify
> the authenticity of those binaries (integrity is most likely verified
> indirectly via embedded checksums in the container formats).
>

That's why I spoke about checksum and not signatures, I'm not talking
about authenticity, but just about DL checking.

I don't really know if qcow has integrated checksums, but I doubt raw
image does. So I think this could still have some usefulness.

Thanks

--
Vincent Legoll
Attachment: file
L
L
Ludovic Courtès wrote on 25 Jun 16:54 +0200
(name . Vincent Legoll)(address . vincent.legoll@gmail.com)(address . 71577@debbugs.gnu.org)
87a5j9dqeu.fsf@gnu.org
Hi,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

Toggle quote (6 lines)
> But I tried to have a new look at :
> https://guix.gnu.org/en/download/latest/
>
> But with another browser, another computer, reloading the page in firefox,
> or even forced reloading (CTRL+F5) I'm still not seeing the x86_64 qcow2.

There’s no x86_64 QCOW2 image, that’s why. :-)

(The bug that was fixed is that the installation ISO and the Hurd QCOW2
are no longer 404.)

I hope this clarifies the situation.

Thanks,
Ludo’.
V
V
Vincent Legoll wrote on 25 Jun 23:11 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 71577@debbugs.gnu.org)
CAEwRq=pFmUqwEwFZqFfUwwmNwxBUUxUt5zkq39t6_UcQr7d5Fw@mail.gmail.com
Hello,

On Tue, Jun 25, 2024 at 2:54?PM Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (3 lines)
> There’s no x86_64 QCOW2 image, that’s why. :-)
>

OK, that's a why, but may I ask why ?

I'm not trying to be painful, but, there's the 'release' download page, and
there's the 'latest'.

I was assuming (now I understand that was the wrong thing to do) that
I would find on the 'latest' page the same things as on the release page,
just built with git HEAD code.


Toggle quote (4 lines)
> (The bug that was fixed is that the installation ISO and the Hurd QCOW2
> are no longer 404.)
>

Yeah, I followed that, and that's not the "problem" I have, that was simply
a bug that has been fixed, this happens, and it's normal.

And to be completely clear, I'm not reporting this issue for myself, because
I built that x86_64 qcow2 image locally and it's woking fine. I just think
the
path of least surprise for people who click on the latest dowload page is to
find the same as on the release one.

Maybe you have decided that it's not worth the computing power usage,
and that would be fine with me. Just close the issue as "wontfix".

Thanks

--
Vincent Legoll
Attachment: file
L
L
Ludovic Courtès wrote on 5 Jul 09:43 +0200
(name . Vincent Legoll)(address . vincent.legoll@gmail.com)(address . 71577-done@debbugs.gnu.org)
87y16g5ln3.fsf@gnu.org
Hi,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

Toggle quote (7 lines)
> On Tue, Jun 25, 2024 at 2:54?PM Ludovic Courtès <ludo@gnu.org> wrote:
>
>> There’s no x86_64 QCOW2 image, that’s why. :-)
>>
>
> OK, that's a why, but may I ask why ?

I don’t think there’s any particular reason, though one valid
consideration is disk usage.

[...]

Toggle quote (6 lines)
> And to be completely clear, I'm not reporting this issue for myself, because
> I built that x86_64 qcow2 image locally and it's woking fine. I just think
> the
> path of least surprise for people who click on the latest dowload page is to
> find the same as on the release one.

Yeah, we should probably consider doing that for symmetry.

Toggle quote (3 lines)
> Maybe you have decided that it's not worth the computing power usage,
> and that would be fine with me. Just close the issue as "wontfix".

I’m closing this one but we can track the QCOW2 image issue separately.

Thanks,
Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 71577@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 71577
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch