bug#71577: Some Images jobset lack artifacts

bug#71577: Some Images jobset lack artifacts

[Vincent Legoll]

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 ?

(1) - https://guix.gnu.org/en/download/latest
(2) - https://guix.gnu.org/en/download
(3) - https://ci.guix.gnu.org/jobset/images

-- 
Vincent Legoll

bug#71577: Some Images jobset lack artifacts

[Ludovic Courtès]

Hi Vincent,

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

> 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).

> 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’.

bug#71577: Some Images jobset lack artifacts

[Vincent Legoll]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Hello Ludo,

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

> 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 :
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.

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


> > 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 #2: Type: text/html, Size: 2906 bytes --]

bug#71577: Some Images jobset lack artifacts

[Ludovic Courtès]

Hi,

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

> 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’.

bug#71577: Some Images jobset lack artifacts

[Vincent Legoll via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Hello,

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'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.


> (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 #2: Type: text/html, Size: 2023 bytes --]

bug#71577: Some Images jobset lack artifacts

[Ludovic Courtès]

Hi,

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

> 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.

[...]

> 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.

> 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’.