Due to an https://pagure.io/pungi/issue/744 we don't have any checksum files for 32 bit images, except for Server. Looking at nearer, we saw that i686 ISO files have not been built at all, while the i686 netinstall images are there, but they are missing checksums. The fact that most 32bit images on our websites are normal i686 ISO files will already drop many of the links, specially in labs.fp.o and spins.fp.o. So, the question is: Do we want to keep 32bit netinst images on Beta pages even without checksums or do we want to drop them completely?
Persoanlly I am fine with bot (it is a Beta release and just for a few weeks), but it is important for us to know which way we want to go for.
So, I would like to have inputs from @mattdm or @pfrields before taking any decision here. Thanks!
PS: the best would be to regenerate them for netinstall images, but I don't know if we can do that now and if we can get them signed.
I would like to point out that shipping the i386 images without checksum can also be a problem from marketing POV, since it would give the feeling that we don't care about the security of distributed distro components.
I would like to go with either dropping everything from i386(even server since it has blockers) and letting people know that we were unable to produce i386 images due to technical reasons or generating the checksums for i386 and syncing them back to mirrors(for which I am not sure what's the policy is, can we generate them now?)
Either option (removing the images or adding checksums) involves mucking with the compose output (rather than following the pure path of delivering it directly), right?
In that case, I think rel-eng adding the checksums seems like the best approach, assuming rel-eng has the ability to manually do that.
Same for websites, both are not ideal 3 days before the release.
Hopefully this is possible, adding also @ausil for any comment about regenerating checksums ;)
The checksums are not there because buildinstall failed to run successfully. Looking at the logs implantisomd5sum failed to run, after trying to reproduce, I filled https://bugzilla.redhat.com/show_bug.cgi?id=1497458 there is already a fix for the bug in pungi that caused it to be copied over, there should not be any content there at all. https://pagure.io/pungi/c/fcbc3ed4aeeab81056fc5b18d4c4f4445009d915?branch=master is the fix. What should happen is that we remove all the install trees for the failed tasks which is
[ausil@compose-x86-01 ~]$ grep "Failed buildinstall" /mnt/koji/compose/27/Fedora-27-20170927.1/logs/global/pungi.global.log 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Everything>, arch <s390x>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Server>, arch <s390x>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Workstation>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Server>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Everything>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Cloud>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Cloud>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Everything>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Server>, arch <i386>, subvariant <None>. 2017-09-28 02:15:51 [INFO ] Failed buildinstall on variant <Workstation>, arch <i386>, subvariant <None>.
So, remove them, and ask people interested in i686 to test the nightlies?
Nightlies are all failing also. So no there is nothing to test until the bug I filed is fixed.
Ok thank you, I'm going to drop all images from the websites and add a disclaimer on top explaining the reason.
It would be good IMHO to add a line also to the release announcement.
Is someone going to contact the x86 SIG on this? [And if that someone is me :smile: ] what do I need to say? I see that the upstream bug was fixed in pungi but not sure what the real problem is.
@smooge the real bug was listed in my comment https://bugzilla.redhat.com/show_bug.cgi?id=1497458
I'm closing this as fixed for prerelease websites. Should be fixed for GA though.
Metadata Update from @robyduck: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.