Fedora Release Engineering Meeting Summary for 2018-05-29
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2019-05-30)
======================================
Meeting started by mboddu at 16:01:47 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-05-29/releng.20...
.
Meeting summary
---------------
* init process (mboddu, 16:01:48)
* #7400 Rethink how we handle networking config with createImage (oz /
ImageFactory) (mboddu, 16:07:21)
* LINK: https://pagure.io/releng/issue/7400 (mboddu, 16:07:28)
* mboddu commented on the ticket to check with mikem and adamw and if
anyone can make the necessary changes to koji (mboddu, 16:19:11)
* #7802 Several EPEL7 package conflicts with RHEL/CentOS 7.5 (mboddu,
16:20:59)
* LINK: https://pagure.io/releng/issue/7802 (mboddu, 16:21:05)
* LINK:
https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json
(nirik, 16:28:37)
* LINK:
https://infrastructure.fedoraproject.org/repo/json/pkg_el6.json
(nirik, 16:28:42)
* mboddu will ping the maintainer about the specific epel packages
that that are causing issues (mboddu, 16:40:02)
* mboddu will create a ticket to create a script that will compose
epel packages with rhel package list json file and report back with
results (mboddu, 16:40:53)
* LINK: https://pagure.io/is-it-in-rhel (cverna, 16:42:55)
* #7763 define and implement retention policy for nightly composes
(mboddu, 16:47:03)
* LINK: https://pagure.io/releng/issue/7763 (mboddu, 16:47:09)
* We will not change the policy but we will keep track of the koji
event id (probably in fpdc) from which we can clone a koji tag and
run a compose from it if and when its really needed. (mboddu,
16:51:43)
* Open Floor (mboddu, 16:53:03)
* F28 went EOL yesterday (mboddu, 16:53:26)
* FLOCK CFP selection starts on Jun 1st, so please submit your talks
(mboddu, 16:54:26)
* nirk is looking into upgrading builders to F30 and killing ppc64 and
also working on moving s390x builders to kvm (mboddu, 17:03:39)
* nirik is working on - Oz and ImageFactory in rawhide moved to
python3 and trying to move them to f30-infra and if everything works
out, then moving to python3 koji. (mboddu, 17:03:59)
Meeting ended at 17:07:48 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (66)
* nirik (59)
* zodbot (8)
* cverna (6)
* pwhalen (6)
* bcotton (3)
* tyll (0)
* puiterwijk (0)
* masta (0)
* jednorozec (0)
* pbrobinson (0)
* dustymabe (0)
* pingou (0)
* ksinny (0)
* maxamillion (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
5 years
[releng] Issue #7763: define and implement retention policy for nightly
composes
by Dan Horák
sharkcz reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Right now we have only last 14 days of the nightly composes. Which makes it impossible to compare current compose with an old one to see what changed (mainly functionally). The polocy could be time based (like keep 1 compose per week for 4 weeks preceding the 14 days, then keep 1 per month, until previous GA). Or it can be based on the openqa testing and keep composes "nominated for further testing". Or something else.
One of the reason for this request is https://bugzilla.redhat.com/show_bug.cgi?id=1623547 where I'm almost sure I had a F-29 nightly compose behaving sanely on s390x in the past, but have nothing I could compare with the current state.
* When do you need this? (YYYY/MM/DD)
soon
* When is this no longer needed or useful? (YYYY/MM/DD)
never
* If we cannot complete your request, what is the impact?
Difficult to find out what changed (functionally) in the composes as the previous compose is the GA compose of the last release. AFAIK it's almost impossible to recreate an old compose from a given date on demand.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7763
5 years
[releng] Issue #7802: Several EPEL7 package conflicts with RHEL/CentOS 7.5
by Eli Young
elyscape reported a new issue against the project: `releng` that you are following:
``
#### Describe the issue
The releases of RHEL and CentOS 7.5 (and likely earlier versions) brought with them new packages that were previously provided by EPEL7. Some of these are still present in EPEL, potentially causing conflicts. Particularly problematic are various packages that are provided in EPEL as python2-* and provided in upstream as python-*. While fully-overlapping names are suboptimal, these partially-overlapping names that provide the same actual package leads to issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla].
I have attached 4 files containing lists of problematic packages:
filename|description|impact if unresolved
-|-|-
base-and-updates-full.txt|EPEL7 packages also in upstream base or updates|moderate
base-and-updates-partial.txt|EPEL7 packages also in upstream base or updates as python-*|significant
extras-full.txt|EPEL7 packages also in upstream extras|moderate
extras-partial.txt|EPEL78 packages also in upstream extras as python-*|significant
#### When do you need this? (YYYY/MM/DD)
No specific date, but sooner is better.
#### When is this no longer needed or useful? (YYYY/MM/DD)
N/A
#### If we cannot complete your request, what is the impact?
EPEL-provided packages with full name overlap may potentially override upstream packages. EPEL-provided packages with partial name overlap may cause issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla].
<!!image>
<!!image>
<!!image>
<!!image>
[certbot]: https://github.com/certbot/certbot/issues/6314
[bugzilla]: https://bugzilla.redhat.com/show_bug.cgi?id=1578071
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7802
5 years
[releng] Issue #8394: Tracker for rhel packages
by Mohan Boddu
mohanboddu reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
We dont know when packages gets added to rhel from epel. So, we want to track them and block them in epel or whitelist them for arch specific packages.
From RelEng meeting on May 29 2019
```
[12:25:47] <mboddu> nirik: I know there is no communication involved when packages are moved to RHEL and we have to remove them in EPEL
[12:26:27] <mboddu> Cant we ask RHEL maintainers to send us the list whenever they do so, or once a week/month?
[12:26:57] <mboddu> Or at the least when there is a release?
[12:28:10] <nirik> we have a list of packages in rhel
[12:28:37] <nirik> https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json
[12:28:42] <nirik> https://infrastructure.fedoraproject.org/repo/json/pkg_el6.json
[12:29:42] <mboddu> nirik: Yes, I know them, but they contain all of them, not anything newly added
[12:30:07] <mboddu> Or we can write our own thing to compare list of packages in epel vs those json files
[12:30:26] <nirik> sure.
[12:30:41] <nirik> but we need to whitelist the limited arch ones...
[12:30:50] <mboddu> Yes
[12:30:55] <bcotton> do we know how often that changes? because if it's infreqent, I can talk to my counterparts who work on RHEL to notify me/someone
[12:32:03] <nirik> it changes at point releases...
[12:32:21] <nirik> I'm not sure notifying us is great.
[12:32:22] <mboddu> bcotton: ^ mostly at point releases
[12:32:34] <mboddu> nirik: Why?
[12:32:52] <nirik> there is supposed to be a step when adding a new package to rhel to file a bug on the epel package if it exists and getting the maintainer to retire it.
[12:33:05] <nirik> because releng doesn't scale, and we should get this as automated as possible.
[12:33:10] <nirik> manual workflows suck.
[12:33:26] <bcotton> agreed. if there's something that's supposed to be happening that isn't, i can bring that up, too
[12:34:16] <nirik> I suppose the best we might do is a script that runs every day and checks rhel against epel and has a whitelist. When something new comes up we retire it or whitelist it. but thats still manual... so dunno.
[12:34:23] <mboddu> That is true, but we can add something like "Talk to epel maintainer....blah blah....if the epel maintainer doesn't respond then talk to RelEng"
[12:35:29] <mboddu> I am okay with either one rather then being in the dark unless someone files a ticket
[12:38:00] <nirik> well, sure, but it needs script writing...
[12:38:55] <mboddu> nirik: I am okay with it
[12:39:03] <mboddu> I will create a ticket for it
[12:39:15] <nirik> so, yeah... lets put the generic solution in a ticket...
[12:39:25] <nirik> and in this one ask reporter for specfic details
[12:40:02] <mboddu> #info mboddu will ping the maintainer about the specific epel packages that that are causing issues
[12:40:52] <mboddu> #info mboddu will create a ticket to create a script that will compose epel packages with rhel package list json file and report back with results
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8394
5 years
[releng] Issue #8388: Change Proposal Approval: Node.js 12.x
by Stephen Gallagher
sgallagh reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
System-wide Change https://fedoraproject.org/wiki/Changes/Nodejs12x requires rel-eng sign-off
The only involvement rel-eng might have is approving a PR for fedora-module-defaults, but I have privileges on that repo. This ticket is basically a NOOP from my perspective.
* When do you need this? (YYYY/MM/DD)
2019-06-14
* When is this no longer needed or useful? (YYYY/MM/DD)
2019-06-31
* If we cannot complete your request, what is the impact?
The Change cannot proceed.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8388
5 years