[releng] Issue #8468: fedora-scm-requests new repository procedure
repeatedly keeps the repo owned by the releng person
by Miro Hrončok
churchyard reported a new issue against the project: `releng` that you are following:
``
1. I've create a new repository request, where something was wrong
2. @limb processed the request, closed as invalid
3. I fixed the thing and reopened the issue
4. @limb processed the request, closed as invalid again (already exists)
5. as a result, the repo was created, but owned by @limb
This is probably broken in some script that @limb runs, it probably creates the repo, checks some constraints and assigns the repo to me. When the constraints fail, the repo exists, but is not assigned to me. I cannot provide more details, because I have no idea what happens "on the other side".
This already happened twice to me:
https://pagure.io/releng/fedora-scm-requests/issue/10716
https://pagure.io/releng/fedora-scm-requests/issue/13178
In both cases, the branch was set to epel7 and initial_commit to false, if that makes any difference.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8468
4 years, 6 months
[releng] Issue #7662: Build once,
run everywhere seems to be pretty unsupported (modularity)
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Today we've encountered issue that if your modulemd contains something like
```yaml
- buildrequires:
platform: [f29]
requires:
platform: []
```
MBS doesn't tag it properly into f28-* because it checks for buildrequires and not for requires. Which is wrong: https://pagure.io/fm-orchestrator/issue/974
However, @puiterwijk mentioned that bodhi doesn't support this either because it would pick first tag instead of creating updates for multiple ones. It seems that bodhi would need to change some core parts for this.
I'm submitting this ticket just to make sure that work is scoped and if can't be completed before F29 bodhi activation point, could be workarounded.
* When do you need this? (YYYY/MM/DD)
F29 Bodhi activation point.
* When is this no longer needed or useful? (YYYY/MM/DD)
When modularity dies.
* If we cannot complete your request, what is the impact?
One of the main use-cases for modularity doesn't work.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7662
4 years, 6 months
[releng] Issue #7555: permission to build livecd for minishift
by Praveen Kumar
kumarpraveen reported a new issue against the project: `releng` that you are following:
``
I am part of minishift[0] development team and currently, we only have support for CentOS and RHEL live iso to provision Openshift locally, we also want to add support for Fedora iso so people can try the latest development around container world.
As a starting point we only first try the scratch build of the iso with f28/f29/rawhide.
```
$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: kumarpraveen(a)FEDORAPROJECT.ORG
Valid starting Expires Service principal
06/08/2018 12:31:28 06/09/2018 12:28:38 HTTP/koji.fedoraproject.org(a)FEDORAPROJECT.ORG
renew until 06/15/2018 12:28:32
06/08/2018 12:28:38 06/09/2018 12:28:38 krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG
renew until 06/15/2018 12:28:32
$ koji spin-livecd --scratch minishift-fedora 1.0.0 rawhide x86_64 fedora.ks
spin-livecd is deprecated and will be replaced with spin-livemedia
[====================================] 100% 00:00:00 19.70 KiB 33.12 KiB/sec
ActionNotAllowed: livecd permission required
```
[0] https://github.com/minishift/minishift
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7555
4 years, 6 months
[releng] Issue #7477: Changes for release SOP before f29
by Kevin Fenzi
kevin reported a new issue against the project: `releng` that you are following:
``
This ticket will collect any changes we need to make to the release SOP that were missed in f28 but we should add in f29.
We should collect them here and then close this once all of them are merged into the SOP.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7477
4 years, 6 months
[releng] Issue #7428: Anaconda & bodhi update improvements
by Martin Kolman
m4rtink reported a new issue against the project: `releng` that you are following:
``
I would like to start by saying that the Bodhi update process works just fine for Anaconda during freeze periods - we just build a new version of Anaconda or any of it's related packages with all the blocker a FE fixes, put it to an update and basically hand it over to Fedora QA, who handle the rest (make sure it ends up in the appropriate compose, etc.).
Where I think the Bodhi process does not really work are the periods when Fedora is not in freeze (so after Bodhi activation and before Beta freeze and after Beta freeze and before Final freeze).
As regular users are rather unlikely to test Installer updates (with the whole "you need to reinstall your machine to test it" thing) so the Anaconda updates generally sit there for the full 7 days (+any Bodhi push overhead) and are then pushed to stable possibly without any testing. Also any changes to the update, such as adding a fixed build or adding additional packages reset karma and (IIRC) also the waiting period.
Given that the no-freeze period are generally about two weeks, it's actually pretty challenging to get any regular Anaconda updated to stable at all. This can then result in users getting 6+ weeks (4 weeks freeze, 1-2 weeks in Bodhi) of changes at once, possibly right before the next freeze. Or the update might not even make it in before the next freeze has started due to all the delays, complicating maters further.
I'm not sure if there is a simple solution for this (other than "go bother Adam/Fedora QA for each update") but it would be ideal if each Anaconda update would both:
- get some actual testing (other than our unit tests/CI)
- would reach composes much sooner, making it possible to do more smaller releases outside of the freeze period, making the discovery and fixing of release blocking issues more likely before they can wreak havoc during the freeze period
Maybe some more automated CI & some notification mechanism for Fedora QA that fires when new updates for Anaconda shows up ? Ideally with some commitment to tests it & push to stable if it looks fine.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7428
4 years, 6 months
[releng] Issue #7337: Emit fedmsg when candidate composes are synced to stage
by Adam Williamson
adamwill reported a new issue against the project: `releng` that you are following:
``
Candidate composes (as opposed to nightly composes) for Branched are synced to https://dl.fedoraproject.org/pub/alt/stage/ after they're built. This is supposed to be the preferred download location for them (rather than kojipkgs).
However, there is currently no fedmsg emitted when this happens, so automated systems have no good way to know when a candidate compose has been synced and is available from stage/. It would be good if there was a fedmsg for this (probably a `compose` one).
@puiterwijk
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7337
4 years, 6 months
[releng] Issue #8126: purge-ami script not processing correctly
by Kevin Fenzi
kevin reported a new issue against the project: `releng` that you are following:
``
We have a script in releng/scripts/clean-amis.py
It runs every 10 days and is intended to delete any ami images we have on amazon that are older than 10 days.
Sadly, it's not working correctly and we have a bunch of old images.
From the cron output:
```
Traceback (most recent call last):
File "./clean-amis.py", line 188, in <module>
amis = _get_nightly_amis_nd(delta=864000, end=int(end))
File "./clean-amis.py", line 84, in _get_nightly_amis_nd
compose_id = msg['compose']['compose_id']
TypeError: string indices must be integers
```
We should try and get this fixed asap.
CC: @sayanchowdhury and @pfrields
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8126
4 years, 6 months
[releng] Issue #8265: RFC: Separate target for Rust packages
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
Hello,
You probably saw that we were planning work on MBI, but so far we didn't got any resources. Meanwhile I would like to move rust crates out of rawhide repo to its own (but it will be still built from src.fp.o, everything will be still conforming to guidelines and so on).
Would it be feasible to create some kind of `rust` tag in koji where we would build all our crates?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8265
4 years, 6 months