[releng] Issue #7012: Tag hierarchy for modular updates.
by Ralph Bean
ralph reported a new issue against the project: `releng` that you are following:
``
OK, the patch to bodhi that enables mashing modules is basically done. @mcurlej is wrapping up the test suite. Our target is to merge, release, and deploy it around Sept 20th, just after Beta freeze thaws.
In order to use it, we're going to need to create some new tags for the tag hierarchy.
The tag hierarchy for f27 currently looks like:
~❯ koji list-tag-inheritance --reverse f27
f27 (417)
├─f27-binutils-rebuild (1868)
├─f27-rebuild (1849)
├─f27-gcc-abi-rebuild (1274)
├─f27-atomic (433)
├─f27-openh264 (432)
├─f27-modularity (431)
├─f27-compose (419)
└─f27-updates (418)
├─f27-pending (427)
├─f27-override (424)
│ └─f27-build (425)
│ ├─f27-gnome (2116)
│ ├─f27-ocaml2 (1838)
│ ├─f27-boost (1805)
│ ├─f27-perl (1489)
│ ├─f27-ocaml (1082)
│ ├─f27-llvm4 (493)
│ └─f27-infra (428)
│ └─f27-infra-stg (429)
│ └─f27-infra-candidate (430)
├─f27-updates-pending (423)
├─f27-updates-testing (421)
│ └─f27-updates-testing-pending (422)
│ └─f27-signing-pending (426)
└─f27-updates-candidate (420)
For f27 updates, we're going to need a tag structure something like this:
~❯ koji list-tag-inheritance --reverse f27-modular
f27-modular
└─f27-modular-updates
├─f27-modular-pending
├─f27-modular-updates-pending
├─f27-modular-updates-testing
│ └─f27-modular-updates-testing-pending
│ └─f27-modular-signing-pending
└─f27-modular-updates-candidate
Once that's done (and once the updated bodhi is deployed) we'll need to create a 'F27 Modular' "release" in bodhi's database that points to these tags.
Lastly, the MBS will need to start tagging its built modules into `f27-modular-updates-candidate`.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7012
5 years, 6 months
[releng] Issue #7069: Enable annotaions of binaries compiled by gcc
by Nicholas Clifton
nickc reported a new issue against the project: `releng` that you are following:
``
I would like to enable binary annotations for files compiled by gcc. This will allow extra information to be stored in these files, such as which hardening options were used, the stack size requirements, potential ABI conflicts and so on.
In order to do this I propose patching the redhat-rpm-config rpm to enable the use of the annobin plugin. This plugin will add the extra information to the binary files. Some example scripts in the annobin package demonstrate how this information might be used.
This change has several possible consequences for release engineering:
* It might break the building of any package that uses gcc.
[I have tried to test building various packages locally, and these have all succeeded,
but I do not have the equivalent of an entire Fedora build system].
* The size of gcc built binaries will increase. Not by a huge amount I hope, since
the annotation format is designed to be compact, but it could still be a factor. Note
the information is stored in an unallocated section in the binary, so it will not affect
the size of the executable in memory, only on disk.
* if the annotations work it should allow releng the opportunity to add extra checks
for ABI incompatibilities and hardening problems.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7069
6 years, 1 month
[releng] Issue #7100: new koji tags for atomic host
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
With the new [Fedora CI objective](https://fedoraproject.org/wiki/Objectives/Continuous_Integrati...
we will have better testing of the packages that comprise Fedora Atomic Host
and eventually extend that out to packages that aren't included in Atomic Host
(i.e. the broader Fedora).
It is almost guaranteed that we won't catch everything before some packages make
it into stable (some long running tests or even possibly some failures that we
don't yet have tests for). For that reason we have established that we will need
the ability to revert packages in Atomic Host that fail tests (or are otherwise bad).
This is mostly so that the testing of future packages doesn't get blocked by a host
that is now in a bad state.
We had previously considered using modularity for this purpose, but we aren't quite
ready to use modularity yet. In the interim we'd like to use a few koji tags and a rigorous
definition of Atomic Host to achieve this goal.
Today:
- we have the `f27-atomic` tag. This is used to primarily "freeze" our install
media for Atomic Host at the f27 "release day" package set. Occasionally we will need
a new version of anaconda or ostree/rpm-ostree for the installer and we'll ask to
have things tagged into this tag.
- we build our ostree for Atomic Host from the release day repo (f27) as well as the
updates repo that was created by Bodhi (f27-updates).
Proposed Future:
- we have an `f27-atomic-installer` tag that is used for the same purpose as the
`f27-atomic` tag is today. Mainly to freeze the installer package set at f27
release day packages. This tag inherites from f27 (release day) tag.
- we have an `f27-atomic-overrides` tag. This tag does not inherit from any other
tag and only contains rpms that we have tagged in there for reverting to previous
versions of rpms.
- we have a dist-repo for `f27-atomic-overrides` so that whenever we tag something
into that tag we can request a repo get created for it.
- we update the ostree compose definition (in our pungi configs) to pull from this new
dist-repo, as well as f27 and f27-updates. In our fedora-atomic tree manifest we will
specify NVR for rpms (possibly even for all packages that make up atomic host).
- we request a new "atomic" koji permission. This permission will have the appropriate
policy to allow people with this permission to add/remove packages from these tags.
Thanks to @mikeb who helped me come up with this solution by providing technical guidance.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7100
6 years, 4 months
[releng] Issue #7018: F27 stable push requests
by Adam Williamson
adamwill reported a new issue against the project: `releng` that you are following:
``
This ticket will be used for requesting pushes of tested blocker / freeze exception fixes during F27 release freezes. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process . Similar to candidate compose request tickets, this ticket can be closed by releng after each push and re-opened by QA each time a new push is needed.
Please push:
== Blockers ==
* [selinux-policy-3.13.1-280.fc27](https://bodhi.fedoraproject.org/updates/F... for [#1488404](https://bugzilla.redhat.com/show_bug.cgi?id=1488404) [#1484566](https://bugzilla.redhat.com/show_bug.cgi?id=1484566)
* [389-ds-base-1.3.7.3-1.fc27 freeipa-4.6.0-2.fc27 python-pyldap-2.4.37-2.fc27](https://bodhi.fedoraproject.org/updates/FEDO... for [#1455561](https://bugzilla.redhat.com/show_bug.cgi?id=1455561) [#1483159](https://bugzilla.redhat.com/show_bug.cgi?id=1483159) [#1488295](https://bugzilla.redhat.com/show_bug.cgi?id=1488295) [#1465390](https://bugzilla.redhat.com/show_bug.cgi?id=1465390) [#1488640](https://bugzilla.redhat.com/show_bug.cgi?id=1488640)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7018
6 years, 5 months