[releng] Issue #7071: libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose
fweimer reported a new issue against the project: `releng` that you are following: `` The multlib RPM went missing:
$ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/27/x86_64/l/ | grep libcrypt -rw-r--r-- 74,352 2017/09/15 12:51:44 libcrypt-2.26-8.fc27.i686.rpm -rw-r--r-- 73,492 2017/09/15 12:53:17 libcrypt-2.26-8.fc27.x86_64.rpm -rw-r--r-- 66,192 2017/09/15 12:50:54 libcrypt-nss-2.26-8.fc27.x86_64.rpm
This currently breaks updates, see [#1495431](https://bugzilla.redhat.com/show_bug.cgi?id=1495431). ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
ausil added a new comment to an issue you are following: `` I believe what we are hitting here is #4084 @katec FYI
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
fweimer added a new comment to an issue you are following: `` Is there anything we should do on the glibc side? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
mohanboddu added a new comment to an issue you are following: `` @fweimer Nothing needs to be changed. Takskotron check on whats available in fedora+updates repo, so until the multilib lands in the repos the same time the update that drags it in lands in those repos, taskotron cant do anything about them. Please file an issue at https://pagure.io/taskotron/task-rpmdeplint for better tracking.
Closing it since we cant do anything until the update lands in f27 repo. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The status of the issue: `libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose` of project: `releng` has been updated to: Closed as Fixed by mohanboddu.
fweimer added a new comment to an issue you are following: `` @mohanboddu, I find your response confusing. I think the f27-testing compose is broken. Surely is a bug which needs fixing, with an immediate workaround to get f27-testing into a consistent state, and a long-term fix for whatever the underlying bug is. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The status of the issue: `libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose` of project: `releng` has been updated to: Open by fweimer.
fweimer added a new comment to an issue you are following: `` The issue is back:
``` [fweimer@oldenburg ~]$ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/27/x86_64/l/ | grep libcrypt -rw-r--r-- 45,052 2017/10/15 23:50:10 libcrypt-2.26-14.fc27.i686.rpm -rw-r--r-- 44,184 2017/10/15 23:50:00 libcrypt-2.26-14.fc27.x86_64.rpm -rw-r--r-- 36,800 2017/10/15 23:49:43 libcrypt-nss-2.26-14.fc27.x86_64.rpm [fweimer@oldenburg ~]$ ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
fweimer added a new comment to an issue you are following: `` Another incident:
``` $ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/28/Everything/x86_64/Packages/g/ | grep glibc-headers -rw-r--r-- 465,956 2018/05/18 17:21:33 glibc-headers-2.27-14.fc28.x86_64.rpm ```
`glibc-headers.i686` is missing. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The status of the issue: `libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose` of project: `releng` has been updated to: Closed as Can't Fix by kevin.
kevin added a new comment to an issue you are following: `` So, before we used pungi for GA releases and mash for updates and each had their own setup for this and it was confusing. Now we are only using pungi and it in turn uses python-multilib.
So, can you file a bug against python-multilib and see if we can get it fixed in that one place once and for all and then it should stay fixed hopefully.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
fweimer added a new comment to an issue you are following: `` https://bugzilla.redhat.com/show_bug.cgi?id=1582634 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
lsedlar added a new comment to an issue you are following: `` I don't think this is a python-multilib problem. It's caused by the process generating the updates composes. As I understand it, only actually updated packages get into the updates compose.
Looking at the example of glibc-headers, it's in nightly rawhide because `libxcrypt-devel-4.0.1-1.fc29.i686` depends on it, not by any property of the actual glibc-headers package.
If there is no i686 package in the updates that would require glibc-headers, it will not be there.
I'm not sure how best to solve this. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
lsedlar added a new comment to an issue you are following: `` A possible solution would be to use Pungi's `prepopulate` feature: it's a list of packages that should be included in the compose even if the configuration does not say so specifically. At GA time a package list would be generated from the compose that would say which packages are multilib (and on which variant and arch).
This file would be added to the config file used by Bodhi. If a package on the list is updated, it's multilib version would be pulled in.
This approach does not cover case when new multilib packages are added as updates. In such case the listing would have to be updated (either manually or via some automated process).
If this is an acceptable solution, I will need to write a script to create the listing. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The status of the issue: `libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose` of project: `releng` has been updated to: Open by fweimer.
fweimer added a new comment to an issue you are following: `` Reopening, per: https://bugzilla.redhat.com/show_bug.cgi?id=1582634#c1
Why do we cannot ship a full, regular compose in updates-testing? Is it the metadata size?
Would it be possible to generate a regular compose and then drop all packages which are available elsewhere? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
lsedlar added a new comment to an issue you are following: `` [Comment 3 on compose-utils#70](https://pagure.io/compose-utils/pull-request/70#comment-54301) links to what the package list would look like. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
syeghiay added a new comment to an issue you are following: `` @mohanboddu will look into this issue. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The issue: `libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose` of project: `releng` has been assigned to `mohanboddu` by syeghiay.
fweimer added a new comment to an issue you are following: `` The Fedora 29 GA compose has glibc-headers.i686, but the Fedora 29 updates compose lacks glibc-headers.i686.
This breaks updates for users if they have accidentally installed glibc-headers.i686. Please fix. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
kevin added a new comment to an issue you are following: `` @lseldar I see in that example list there is debuginfo and debugsource, will pungi put those in the right place in the tree? Or would they get added to the main repos?
Otherwise, this seems ok to me, we could generate this for f29 and start trying to use it for updates-testing/updates. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
mohanboddu added a new comment to an issue you are following: `` @kevin Is it by any chance, we are filtering glibc and libgcc packages in [pungi configs](https://pagure.io/pungi-fedora/blob/f29/f/fedora-final.conf#_164) of normal composes but not in [bodhi pungi configs](https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/... ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
kevin added a new comment to an issue you are following: `` Nope, those are different... glibc32, libgcc32 are special 32 bit packages we have in the koji x86_64 buildroot in order to build some 32 bit stuff. They never should be shipped to users.
glibc.i686 and libgcc.i686 are just the 32 bit versions of those and are shipped to all i686 users, and some x86_64 users to run 32bit binaries.
The problem here is that they are multilib in GA repo, so people can install them, but then in updates we only have the x86_64 one, so there's a mismatch and dnf complains and the user complaines, etc. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
lsedlar added a new comment to an issue you are following: `` The debuginfo packages will still end up in debuginfo repo. Anything else would be a bug. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
syeghiay added a new comment to an issue you are following: `` @humaton will talk to @mohanboddu about this ticket. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
The status of the issue: `i686 packages go sporadically missing from the x86_64 compose` of project: `releng` has been updated to: Closed as Fixed by mohanboddu.
mohanboddu added a new comment to an issue you are following: `` From our grooming discussion on #fedora-releng channel on Apr 12 2019
``` Proposal: Close the ticket and ask them to reopen if they find any issues ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071
rel-eng@lists.fedoraproject.org
-
Dennis Gilmore -
Florian Weimer
-
Kevin Fenzi
-
Lubomír Sedlář
-
Mohan Boddu
-
Suzanne Yeghiayan