[releng] Issue #6577 `Fedora 26 mass rebuild`
by Carlos O'Donell
codonell added a new comment to an issue you are following:
``
---
<dhorak> codonell: the shadow process is running, the right glibc version will be used when the mass rebuild will be processed in the s390 koji instance
---
Looks like s390x is good for glibc.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6577
7 years, 3 months
[releng] Issue #6577 `Fedora 26 mass rebuild`
by Jakub Jelinek
jakub added a new comment to an issue you are following:
``
I'd say yes, the silent wrong-code issues I've been aware should be resolved by now, if there is some ICE or similar bug left, it can be resolved post mass rebuild (the package will fail to build).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6577
7 years, 3 months
[releng] Issue #6577 `Fedora 26 mass rebuild`
by Carlos O'Donell
codonell added a new comment to an issue you are following:
``
As of right now glibc 2.25 for Fedora 26, based on the final upstream 2.25 (released 3 days ago) is building in rawhide (https://koji.fedoraproject.org/koji/taskinfo?taskID=17682458), and scratch builds all passed already.
It is important that we use the final glibc 2.25 for mass rebuilds, just as important as using the right compiler.
The issue with glibc is that it forms the basis of the lowest-level ABI and API guarantees we have in the distribution. As the final glibc release approaches we keep rawhide in sync as close as possible. Therefore day-to-day we know exactly where we stand. The _final_ touches are that we move Rawhide to the official release tag such that upstream provides Fedora all the assurances of an ABI guarantee. In reality we are 99.99% assured anyway, but we like to meet the letter of the guarantee by being on the right branch. That's what we're doing here.
So I'm OK with the mass rebuild as long as glibc-2.25-1 is used.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6577
7 years, 3 months
[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Colin Walters
walters added a new comment to an issue you are following:
``
Yeah, having to regenerate images just to get a new commit ID is a bit annoying. Down the line, I think we should go to automatic in place updates. Once we do that across the board, the cloud images are more of an asynchronous starting point - in other words, we don't necessarily respin the AMIs/qcow2 etc. for each release.
This becomes more of a polar opposite from the current "image-focused, ostree is a lookaside" approach. Now, I'm well aware that there is a *large* contingent of public cloud users who basically just want updated AMIs (and/or respin their own), and don't care about in place updates (whether ostree or not).
Going down a rabbit hole a bit, one thing we could conceive of is moving away from the ostree commit history. This would get more natural if we used Docker/OCI for transport. Really, the only thing causing the commit IDs to differ is the parent history (and timestamp, but we control that). There'd be a lot of tradeoffs in this...but it's a conceptual question as to how useful the ostree history really is.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months
[releng] Issue #6622 `Request to add packages to f25-infra tag`
by Ralph Bean
ralph reported a new issue against the project: `releng` that you are following:
``
For the PDC upgrade, I need four packages added to the f25-infra tag:
- python-django-cors-headers
- python-django-rest-framework-composed-permissions
- python-pdc
- patternfly1
The first two have package reviews up and will be included in Fedora.
The last two, I do not intend to package for Fedora (patternfly1 bundles a thousand nodejs things and python-pdc, I would rather leave to the PDC devs to get into Fedora).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6622
7 years, 3 months