kellin opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Add post-compose rsync script
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/438
kellin reported a new issue against the project: `pungi-fedora` that you are following:
``
The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process.
I am going to make this more durable, however, it will also slightly change our process behind the scenes.
Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate.
Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed.
The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence.
@mohanboddu is fine with this change; does anyone else have objections?
@ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/issue/426
kevin reported a new issue against the project: `releng` that you are following:
``
As noted in this post:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
it seems we are only syncing out the drpms made in that specific compose. We should keep a (ideally configurable) amount of older ones around. I think for rawhide we were keeping 2 weeks, we could start with that.
as it is now unless someone updates on the day an update is pushed they won't get the advantage of the drpm.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7215
kellin opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Make release-candidate.sh script more durable
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/433
ralph opened a new pull-request against the project: `releng` that you are following:
``
A SOP for adjusting EOLs on arbitrary branches.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/7119
walters opened a new pull-request against the project: `pungi-fedora` that you are following:
``
AH: Stop generating raw-xz images
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/381
vondruch reported a new issue against the project: `releng` that you are following:
``
I was wondering why rubygem-factory_girl is not build by Koschei \[[1]\] and I was told by @msimacek that the package is not properly tagged for F28:
~~~
$ koji list-tagged --inherit f28-build --latest | grep rubygem-factory_girl
~~~
Please note that the package was incorrectly unbolcked in #6904 and the unblocking was later fixed by #6982, so this still might be some outfall of this. Not sure ...
[1]: https://apps.fedoraproject.org/koschei/package/rubygem-factory_girl
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7212
jkaluza reported a new issue against the project: `releng` that you are following:
``
This is follow-up of meeting we have with @Kellin, @puiteriwjk, @mboddu, @ralph and others about using ODCS for alpha/beta composes. More info about motivation can be found here: https://docs.google.com/document/d/1VLOgxmdHL6eXMK1dZAsimJ1U3gtppntdeQkM-x8…
In order to make ODCS scalable and keep using read-only access for /mnt/fedora_koji, we decided to run ODCS tasks in Koji runroot. We need to prevent deadlock scenario, when main runroot task with main pungi "process" submits to Koji another children runroot tasks (for example for buildinstall phase), but Koji would not have enough buiders for these runroot tasks ready.
It has been advised that we could fix that by using different Koji channels for main pungi runroot task (this is submitted by ODCS backend) and children pungi runroot tasks (these are submitted by Pungi main runroot task).
This request is official ticket asking for two new Koji channel. First one (for example "odcs"), to be used by ODCS backend process to spawn the main Pungi runroot. Second one (for example "odcs-pung") to be used by main Pungi runroot to spawn children runroot tasks.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7195