[releng] Issue #7074: Compose configuration changes needed for modular fedora
by Dennis Gilmore
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
5 years, 5 months
[releng] Issue #7017: Set up koji policy/channels for known archful noarch
packages.
by Ralph Bean
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
5 years, 5 months
[releng] Issue #7012: Tag hierarchy for modular updates.
by Ralph Bean
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
5 years, 6 months
[releng] Issue #7530: koji: HTTPError: HTTP Error 503: Backend fetch failed
on s390x
by Till Maas
till reported a new issue against the project: `releng` that you are following:
``
A few builds failed with a traceback in the result:
For example: https://koji.fedoraproject.org/koji/taskinfo?taskID=27239575
```
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1244, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 307, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 209, in call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 1195, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 477, in localPath
fsrc = six.moves.urllib.request.urlopen(url)
File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python2.7/urllib2.py", line 435, in open
response = meth(req, response)
File "/usr/lib64/python2.7/urllib2.py", line 548, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib64/python2.7/urllib2.py", line 473, in error
return self._call_chain(*args)
File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/usr/lib64/python2.7/urllib2.py", line 556, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 503: Backend fetch failed
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7530
5 years, 7 months