Fedora Release Engineering Meeting Summary for 2018-06-28
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2018-06-28)
======================================
Meeting started by mboddu at 17:01:54 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2018-06-28/releng.20...
.
Meeting summary
---------------
* init process (mboddu, 17:01:54)
* #7589 Bug 1575762: Installation of F28 fails on systems using RAID
(mboddu, 17:05:44)
* LINK: https://pagure.io/releng/issue/7589 (mboddu, 17:05:53)
* Closing the ticket as we generally wont respin the images and mark
is as common-bug to document it. (mboddu, 17:25:38)
* #7553 Arch-Specific Runtime Dependencies in sub-packages (mboddu,
17:27:03)
* LINK: https://pagure.io/releng/issue/7553 (mboddu, 17:27:11)
* mboddu will ask the reporter in the ticket if the proposals answers
his question. (mboddu, 17:36:41)
* #7445 [RFE][PATCH] make $releasever return "rawhide" on Rawhide
(mboddu, 17:37:40)
* LINK: https://pagure.io/releng/issue/7445 (mboddu, 17:37:46)
* nirik will write up something and will take it to devel/qa lists
(mboddu, 17:46:02)
* Alternate arch updates (mboddu, 17:47:04)
* we are still waiting on moving s390 koji builders to primary koji
(mboddu, 17:49:29)
* Open Floor (mboddu, 17:49:39)
* nirik has one more update which is currently a suspense (mboddu,
17:55:10)
Meeting ended at 17:56:34 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (60)
* nirik (33)
* zodbot (7)
* adamw (4)
* Kellin (3)
* tyll (0)
* puiterwijk (0)
* masta (0)
* pbrobinson (0)
* dustymabe (0)
* pingou (0)
* maxamillion (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
5 years, 11 months
Release criteria proposal: drop kickstart package criterion
by Adam Williamson
Hi, folks!
We currently have a Final release criterion that reads as follows:
"A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository.
The included kickstarts must define the correct set of release
repositories.
Why?
This is considered part of Fedora's duty to be 'self-hosting': the
kickstarts used to produce the release images are a vital piece of
information required to duplicate that release, so they must be
preserved along with the release."
Lately this requirement has been fairly annoying in practice. Updating
the package prior to release does not appear to be in anyone's regular
schedule, so invariably what happens is shortly before the release
deadline I realize we haven't built a 'release' spin-kickstarts package
and have to file a blocker bug and ping people with the necessary
permissions (of which there are only a few) to build one in a tearing
hurry. Then we have to approve the blocker bug and push the updated
package through the freeze, all wasting time we could be spending on
more important fixes.
The benefit here is really fairly tiny, as well. It's arguable whether
anyone cares particularly whether a Fedora release, as a frozen
artifact, is 100% internally reproducible (and I'm not sure whether our
releases actually *are* reproducible in any case, these days, I'm not
at all sure we ship all the necessary metadata and so on for *every
single deliverable* within the distribution).
These days I'd suggest it should be quite acceptable to simply use git
tags for this purpose. It should be quite easy for rel-eng to adjust
the release scripts to create a tag in the fedora-kickstarts repo (and
why not fedora-comps too, while we're at it) for each 'candidate'
compose, named for the compose ID. That would make it very easy to
access the correct kickstarts for any Fedora candidate compose just by
a 'git checkout', with no need for the cumbersome work of getting the
package into the compose.
Naturally this would go along with updates to any relevant docs or wiki
pages, recommending to use the git repository instead of the RPM
packages, and explaining the tagging scheme. As for the package, we
could either keep it but not sweat about updating it for each release,
retire it entirely, or change it to contain only a text file pointing
to the git repository (or to the doc / wiki page that explains the git
repo location and tagging strategy).
Thoughts? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 11 months
[releng] Issue #7587: Commit access to capstone
by Michal Ambroz
rebus reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Hello, I am one of the admins of capstone (https://src.fedoraproject.org/rpms/capstone), but I am not able to commit changes to the package (FAS id is rebus).
```
[mambroz@hermes master]$ fedpkg push
Counting objects: 3, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 659 bytes | 659.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: FATAL: W refs/heads/master rpms/capstone rebus DENIED by fallthru
remote: error: hook declined to update refs/heads/master
To ssh://pkgs.fedoraproject.org/rpms/capstone
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'ssh://rebus@pkgs.fedoraproject.org/rpms/capstone'
Could not execute push: Command '['git', 'push']' returned non-zero exit status 1
```
* When do you need this? (YYYY/MM/DD)
I wanted to fix the https://bugzilla.redhat.com/show_bug.cgi?id=1594842
* When is this no longer needed or useful? (YYYY/MM/DD)
I do not expect the issue to go away by itself
* If we cannot complete your request, what is the impact?
I wont be able to push updates to the capstone package.
Thank you
Michal Ambroz
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7587
5 years, 11 months
[releng] Issue #6230: sign our docker images
by Mohan Boddu
mohanboddu added a new comment to an issue you are following:
``
From our releng meeting on June 21st 2018:
>
[13:58:57] <mboddu> #info With upcoming new robosig, we will start supporting container signing and they will signed just like what we have with rpms today, containers will be signed when they are submitted to bodhi.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6230
5 years, 11 months