mprahl reported a new issue against the project: `releng` that you are following:
``
The SLs in PDC for the f27 branch [1] were made with the assumption that the f27 GA date would be October 24th. Once the GA date is finalized, we should update these entries to reflect that. When the time comes feel free to ping me and I can write a script to do it.
1 - https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=f27
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7092
pwhalen reported a new issue against the project: `releng` that you are following:
``
The fedora-docker-base images for armhfp are failing with the error:
ApplianceError: Image status is FAILED: sh: /bin/sh: No such file or directory. All other arches completed successfully.
https://koji.fedoraproject.org/koji/taskinfo?taskID=22112174
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7076
ellert reported a new issue against the project: `releng` that you are following:
``
See https://koji.fedoraproject.org/koji/taskinfo?taskID=22120278
Build for aarch64 fails with the following error in root.log:
DEBUG util.py:439: Error: No Package found for emacs
DEBUG util.py:577: Child return code was: 1
The x86_64 build finds emacs and starts properly.
This package has built successfully on EPEL 7 aarch64 before. The emacs package used to be there.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7075
ausil reported a new issue against the project: `releng` that you are following:
``
* enable createiso generation on all arches.
* enable Minimal and Base container everywhere it makes sense
* Enable disk images (raw.xz and qcow2) as appropriate, x86_64, ppc64le, aarch64
* configure 32 bit arm images using apliance-creator
* configure syncing of contanet to mirrors
* configure sending of compose reports to email lists
* ensure all needed fedmsg's are sent
* setup empty repos for updates and updates-testing for fedora 27
@rashmin and @tmlcoch I will setup a meeting to go over the steps needed and how to test and get it implemented. With this done we should be able to setup compose configurations for Beta.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7074
mohanboddu reported a new issue against the project: `releng` that you are following:
``
Generally QA files the tickets for RC composes, this is an extra compose(s) for releng to work on since this wont follow the normal release cycle.
This ticket will help us tracking the work and issues with the modular RC composes.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7058
mohanboddu reported a new issue against the project: `releng` that you are following:
``
For a traditional release we generate torrents for almost all the iso's in the compose. So, its safe to assume that a modular release also requires torrents generated for the iso's.
There is not much work/code changes are needed here, but just an informational ticket for releng.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7057
ralph reported a new issue against the project: `releng` that you are following:
``
Reported by @sgallagh in a discussion with @ralph and @mikeb.
There are these funny things called 'archful noarch' packages. Packages which produce noarch binary rpms, but which can only be built on specific architectures (x86_64, specifically).
In the traditional world, when you submit a build of one of these package to koji, your build is sent to a builder with a random architecture. Usually this is wrong, and your build fails. You then submit and submit again until it works. This is colloquially called "winning the builder lottery." It is annoying, but people put up with it.
In the modular world, this poses a real problem. The MBS won't know *why* the build failed and we can't expect it to try over and over again until it wins the builder lottery. We need a better solution.
The solution we came up with on a whiteboard (a few months ago) was that we can set up a *channel* in koji called `x86_64-builders` (or something like that). Then, start maintaining a list of all known "archful noarch" packages. This could start with one or two packages and then we grow it over time.
We would then create a new koji hub policy that says something like:
"Whenever a build is submitted of a package that matches any of the packages in the curated list, submit the build to the x86_64-builders channel."
What do you think? Will it work?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7017
ralph reported a new issue against the project: `releng` that you are following:
``
OK, the patch to bodhi that enables mashing modules is basically done. @mcurlej is wrapping up the test suite. Our target is to merge, release, and deploy it around Sept 20th, just after Beta freeze thaws.
In order to use it, we're going to need to create some new tags for the tag hierarchy.
The tag hierarchy for f27 currently looks like:
~❯ koji list-tag-inheritance --reverse f27
f27 (417)
├─f27-binutils-rebuild (1868)
├─f27-rebuild (1849)
├─f27-gcc-abi-rebuild (1274)
├─f27-atomic (433)
├─f27-openh264 (432)
├─f27-modularity (431)
├─f27-compose (419)
└─f27-updates (418)
├─f27-pending (427)
├─f27-override (424)
│ └─f27-build (425)
│ ├─f27-gnome (2116)
│ ├─f27-ocaml2 (1838)
│ ├─f27-boost (1805)
│ ├─f27-perl (1489)
│ ├─f27-ocaml (1082)
│ ├─f27-llvm4 (493)
│ └─f27-infra (428)
│ └─f27-infra-stg (429)
│ └─f27-infra-candidate (430)
├─f27-updates-pending (423)
├─f27-updates-testing (421)
│ └─f27-updates-testing-pending (422)
│ └─f27-signing-pending (426)
└─f27-updates-candidate (420)
For f27 updates, we're going to need a tag structure something like this:
~❯ koji list-tag-inheritance --reverse f27-modular
f27-modular
└─f27-modular-updates
├─f27-modular-pending
├─f27-modular-updates-pending
├─f27-modular-updates-testing
│ └─f27-modular-updates-testing-pending
│ └─f27-modular-signing-pending
└─f27-modular-updates-candidate
Once that's done (and once the updated bodhi is deployed) we'll need to create a 'F27 Modular' "release" in bodhi's database that points to these tags.
Lastly, the MBS will need to start tagging its built modules into `f27-modular-updates-candidate`.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7012
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
It's [uncommon](https://lists.fedoraproject.org/archives/list/devel@lists.fedorap… that people have to wait 2-3 days to get their SCM repo if they submit request on saturday morning (some of US times). It definitely applies for US holidays because @limb is located there.
I would like to help myself in processing those tickets during weekends/holidays and whatever time you will tell me I should do.
@kevin suggested to open releng ticket to track this, so here we go. As Patrick mentioned, there is no granular access so probably I would need to get more permissions just for this but I will use them only for this.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7178