#10816 Bodhi update FEDORA-2022-a5a2935398 was part of Silverblue compose before pushed to stable
Opened 3 months ago by jlebon. Modified 2 months ago

  • Describe the issue

It seems like https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5a2935398 was included in the latest stable Silverblue f36 compose before the update was actually shipped to stable. This in turn caused issues for anyone using layered packages which need to pull in the matching glibc-devel:

https://github.com/fedora-silverblue/issue-tracker/issues/248#issuecomment-1142064765

Can we (1) push that update to stable (or alternatively, fix the compose so that it doesn't get pulled in), and (2) figure out what happened so that it doesn't happen?

  • When do you need this? (YYYY/MM/DD)

For (1), soon. For (2), we can take our time.

  • When is this no longer needed or useful? (YYYY/MM/DD)

Never

  • If we cannot complete your request, what is the impact?

If it happens again, upgrades may break on rpm-ostree-based systems. The same issue may also occur on non-rpm-ostree based systems if the repo misconfiguration issue also affected other parts of the compose.


So, we had some updates compose failures (that update is in the failing push/compose).

But I don't understand how silverblue would have it from a failed compose... we don't sync that out until the end when it has all properly finished. ;(

Can you tell exactly when it was added?

Looks like it was introduced in the latest compose (currently 36.20220530.2):

$ ostree show fedora:fedora/36/x86_64/silverblue
commit 0012652675bd01b43fa8853169c21ecaff0ae2fca3ff2a8acb4f9b519140cca5
Parent:  5ad35d7b348e90bf13d7bfdb4464e3768767f57b1d08e7e44e4603e41d587603
ContentChecksum:  833633afc25e41295f6b5c111478abcc562f3a2780917629dfd7ad19eda94961
Date:  2022-05-30 05:29:49 +0000
Version: 36.20220530.2
(no subject)

Found 1 signature:

  Signature made Mon 30 May 2022 01:29:56 AM using RSA key ID 999F7CBF38AB71F4
  Can't check signature: public key not found
$
$ rpm-ostree db diff 5ad35d7b348e90bf13d7bfdb4464e3768767f57b1d08e7e44e4603e41d587603 0012652675bd01b43fa8853169c21ecaff0ae2fca3ff2a8acb4f9b519140cca5
ostree diff commit from: 5ad35d7b348e90bf13d7bfdb4464e3768767f57b1d08e7e44e4603e41d587603
ostree diff commit to:   0012652675bd01b43fa8853169c21ecaff0ae2fca3ff2a8acb4f9b519140cca5
Upgraded:
  glibc 2.35-9.fc36 -> 2.35-10.fc36
  glibc-all-langpacks 2.35-9.fc36 -> 2.35-10.fc36
  glibc-common 2.35-9.fc36 -> 2.35-10.fc36
  glibc-gconv-extra 2.35-9.fc36 -> 2.35-10.fc36

Metadata Update from @kevin:
- Issue tagged with: medium-gain, medium-trouble, ops

3 months ago

So, yeah, there was a failed compose then.

https://kojipkgs.fedoraproject.org/compose/updates/Fedora-36-updates-20220530.2/logs/global/pungi.global.log

And yeah, it looks like it synced during that?
https://lists.fedoraproject.org/archives/list/releng-cron@lists.fedoraproject.org/message/4EE3BT7TEAIDY5J5F27DHX3PJHFI6UOM/
Or perhaps that was the compose before it.

In any case it shouldn't sync if the compose failed. ;(

I think it might be a bug in new-updates-sync?

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog