grinnz reported a new issue against the project: `releng` that you are following:
``
The Cinnamon livemedia compose is missing several packages that are dependencies of the 'cinnamon' metapackage, despite including that package and others from the @cinnamon-desktop group as the kickstart has been unchanged. The issue seems to have started occurring after 2018-01-06, the earliest compose log that's still there is: https://kojipkgs.fedoraproject.org//packages/Fedora-Cinnamon-Live/Rawhide/2… and here is one from today: https://kojipkgs.fedoraproject.org//packages/Fedora-Cinnamon-Live/Rawhide/2…
These logs say "Downloading 1426 RPMs" or so, I don't have the logs from 2018-01-05 and earlier but the number is supposed to be around 1470. As the kickstart isn't doing anything except including the @cinnamon-desktop group itself, I'm not sure how to debug this further.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7325
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
It would be very nice if you could set up automatic removal of all files except `dead.package` for repositories. Since `rpm-specs-latest.tar.xz` is not updated very often, I try to run grep on all git repositories, but unfortunately there are packages which are dead but still have spec file in there. I know that I could filter all such packages, but I think it would be better to clean them up anyway.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7311
adamwill reported a new issue against the project: `releng` that you are following:
``
Going by fedmsg logs, there have been some very wrongly-formed attempts at update composes (my personal favourite is `Fedora-Modular-f27-updates-updates-Fedora-Modular-27-20171013.0`...), but most of them seem to have been cleaned up. There is still one that's clearly wrong, though, this one:
https://kojipkgs.fedoraproject.org/compose/updates/Fedora-Modular--updates-…
It was obviously meant to be `Fedora-Modular-27-updates-testing-20171031.0`, but somehow lost the release number. It'd make things cleaner if it got killed, I think.
(There's probably very little value in keeping *any* of those `Fedora-Modular-27-updates-testing` composes around, but I'll leave that to you to figure out).
@mohanboddu
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7268
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
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. That means that even the pungi running in Koji runroot task needs to be able to spawn another runroot task and therefore it needs some secret files like keytab.
The advised solution for that was creating new secret volume which could be mounted in ODCS pungi runroot task and pungi in that runroot task can read kerberos keytab from that storage.
ODCS backend/frontend would not have access to that directory.
This ticket is official request for such storage.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7194
bowlofeggs reported a new issue against the project: `releng` that you are following:
``
Greetings releng!
@puiterwijk and I came up with a glorious plan for Bodhi to give it a REST API to control mashing. This is needed in order to automate mass container rebuilds because Bodhi will need to be able to mash the lower layers into the registry before the higher layers that depend on them can be built. A REST API will allow automated services to ask Bodhi to do that when needed.
Giving Bodhi a REST API into the masher opens the possibility for a lot of other Nice Things™ for releng, such as a much better way to see the status of the masher than we have today. Aren't you tired of tailing the logs to see what the masher is doing, or looking for lock files in the mash directory? Wouldn't it be nice if a CLI or possibly even web interface could tell you what's up? This will even make it possible to give bodhi a web interface to control the masher.
Anyways, I'd like to solicit releng's feedback on the proposal. I have created a project for this that has all of the individual tickets that express the proposal in more detail than I've written here:
https://github.com/fedora-infra/bodhi/projects/2
The tickets are arranged from top to bottom in priority order. The tickets that are marked "high priority" mean that I am going to attempt to get them done by Feb 20 (no guarantees though!), and they are required for Bodhi to support containers. The remaining tickets I will pursue after that. Please peruse the various tickets, and please provide feedback in the tickets if you have any.
I filed this ticket so we could discuss it during one of your weekly meetings, if you like.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7174
zdohnal reported a new issue against the project: `releng` that you are following:
``
Hi,
this Monday I finally got to issue which I already discussed on devel-list - removing ghostscript-fonts from Fedora, because they are deprecated long ago and they are replaced by urw-base35-fonts. Two remaining components ghostscript and hylafax+, which had dependency on ghostscript-fonts, removed this dependency, so I retired it for F27 and F28.
But problem is, I didn't check Fedora 27 schedule, and F27 is already in Final Freeze, in which retiring packages mustn't happen (I check emails regulary on devel, devel-announce, fedora-announce and test-announce, but all I saw was postponing Fedora 27, so I thought it isn't Final Freeze already), I'm really sorry about it.
What can I do now for F27? Should I request unretirement for only one release? Or will package be retired for F27?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7150