[releng] Issue #8176: Asking for agreement for a new micro-service
Message-Tagging-Service
by Chenxiong Qi
cqi reported a new issue against the project: `releng` that you are following:
``
A RFR ticket fedora-infrastructure#7563 was opened for a new micro-service named Message-Tagging-Service (aka MTS) to deploy in Fedora. It is a message-driven service triggered by MBS message to tag specific module build. That RFR ticket has detailed information for the service and requirement from module maintainers.
I was reminded that I need to open a ticket to ask for agreement on the proposal in the RFR ticket. This is the one. Currently, two things may be relative to rel-eng.
- MTS requires a rule file in order to find out which tags should be applied to a specific module build. Rule file is a yaml file, here is an example[1] and format explanation[2]. Once the RFR ticket is done through the process, I'm not sure if rel-eng could fill rules in the rule file and then maintain the rules updates.
- MTS should have a keytab to log into Koji and tag builds with proper permission. This is just like what MBS does currently to tag module build imported to Koji. The difference is after MTS is online, MBS will stop tagging, and MTS does that instead.
Thanks!
[1] https://github.com/fedora-modularity/message-tagging-service/blob/master/....
[2] https://pagure.io/modularity/blob/master/f/drafts/module-tagging-service/...
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8176
5 years
[releng] Issue #8165: new koji tag for Fedora CoreOS continuous builds
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
We are exploring the idea of building and tagging some rpms that we care about more continously. After discussing with releng we can start by having a `f29-coreos-continuous` tag and a distrepo set up off of that. We'll use f29 for now to experiment with and then apply it to f30 once it's working.
* When do you need this? (YYYY/MM/DD)
This week would be nice.
* When is this no longer needed or useful? (YYYY/MM/DD)
N/A
* If we cannot complete your request, what is the impact?
We can't explore this option for building more continuously using koji and need to implement it in a separate system that is less like production.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8165
5 years
[releng] Issue #7907: Fedora 30 Toolchain Rebase: glibc 2.29, gcc 9.0
by Carlos O'Donell
codonell reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
All Fedora releases must be released using a released and supported version of the core toolchain involving glibc, gcc, and binutils.
The Fedora toolchain team is responsible for ensuring that Fedora Rawhide stabilizes static linking, code generation, and library ABI, before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by binutils, gcc, glibc or other components, the Fedora toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of all components and fix any last minute ABI or code-generation changes.
* When do you need this? (2019/01/30)
We need a mass rebuild.
Change page for review: https://fedoraproject.org/wiki/Changes/GLIBC229
Owner: Carlos O'Donell carlos(a)redhat.com
glibc mass rebuild request: This request.
Change page for review: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
Owner: Carlos O'Donell carlos(a)redhat.com
glibc mass rebuild request: ppc64le transition to 128-bit IEEE long double.
GCC will file a system-wide change request for GCC 9 transition also in December.
Binutils will remain as 2.31.1 and will not change (Nick Clifton's notes).
* If we cannot complete your request, what is the impact?
I we cannot do a mass rebuild then we should not transition to glibc 2.29 or gcc 9, but we might still be able to transition via targeted mass rebuilds.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7907
5 years
[releng] Issue #7961: Incomplete repo creation
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
Something bad happened when processing following ticket: https://pagure.io/releng/fedora-scm-requests/issue/9143
```
- Checking for PDC global-component golang-github-tv42-httpunix
- Creating PDC global-component golang-github-tv42-httpunix
- Checking for existing PDC branch (rpm)golang-github-tv42-httpunix#master
- Creating PDC branch (rpm)golang-github-tv42-httpunix#master
- Mapping SL rawhide:2222-01-01 to (rpm)golang-github-tv42-httpunix#master
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
timeout=timeout
File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen
body_pos=body_pos, **response_kw)
File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen
body_pos=body_pos, **response_kw)
File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen
body_pos=body_pos, **response_kw)
[Previous line repeated 2 more times]
File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 711, in urlopen
retries = retries.increment(method, url, response=response, _pool=self)
File "/usr/lib/python3.7/site-packages/urllib3/util/retry.py", line 398, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='pdc.fedoraproject.org', port=443): Max retries exceeded with url: /rest_api/v1/component-branch-slas/ (Caused by ResponseError('too many 400 error responses'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/fedscm-admin", line 11, in <module>
load_entry_point('fedscm-admin==1.0.2', 'console_scripts', 'fedscm-admin')()
File "/usr/lib/python3.7/site-packages/click/core.py", line 763, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/click/core.py", line 716, in main
rv = self.invoke(ctx)
File "/usr/lib/python3.7/site-packages/click/core.py", line 955, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.7/site-packages/click/core.py", line 554, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/fedscm_admin/fedscm_admin.py", line 72, in cli
process_all_tickets(auto_approve=auto_approve)
File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 204, in process_all_tickets
process_ticket(issue, auto_approve=auto_approve)
File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 268, in process_ticket
'initial_commit', True))
File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 439, in prompt_for_new_repo
sla, eol, repo, branch_name, branch_type)
File "/usr/lib/python3.7/site-packages/fedscm_admin/pdc.py", line 193, in new_sla_to_branch
timeout=60, http_verb='post', service_name='PDC')
File "/usr/lib/python3.7/site-packages/fedscm_admin/request_utils.py", line 86, in requests_wrapper
return requests_function(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 572, in post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 524, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 637, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 507, in send
raise RetryError(e, request=request)
requests.exceptions.RetryError: HTTPSConnectionPool(host='pdc.fedoraproject.org', port=443): Max retries exceeded with url: /rest_api/v1/component-branch-slas/ (Caused by ResponseError('too many 400 error responses'))
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7961
5 years
[releng] Issue #7921: setgid bit on Fedora 29 directories
by Ian Wienand
iwienand reported a new issue against the project: `releng` that you are following:
``
Hello,
We rsync a Fedora mirror to a local AFS volume. When I added the F29 directories we started getting
```
receiving incremental file list
rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/.": Permission denied (13)
rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything": Permission denied (13)
rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything/x86_64": Permission denied (13)
rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular": Permission denied (13)
rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular
```
Quite bizarre and unhelpful; turns out on stracing the failing call is
```
3213 chmod(".", 02755 <unfinished ...>
```
On AFS, you need administrator permissions to setgid (02) which the mirror user doesn't have. I tried on several different rsync mirrors and they all do the same, so I'm assuming this comes from the master sync.
I can avoid this problem by dropping "-p" from our rsync command; however we haven't (and don't) need this for any of the other fedora directories.
Could someone check if this has inadvertently been applied to the F29 directories somehow?
Thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7921
5 years
[releng] Issue #7275: provide casync index and object storage files for
images on getfedora.org
by Basti Endres
sedrubal reported a new issue against the project: `releng` that you are following:
``
[casync](https://github.com/systemd/casync) is like a new and better rsync for directory trees, binary files and system images. It can speed up downloads if the user already has a similar image on his local machine.
For example if a user already has fedora 26 and he wants to download fedora 27 he can use fedora 26 as local seed and download only differences using casync. The same applies if he has fedora workstation and he wants to download fedora server.
It was great if you provide a `.caibx` index file for each image and a (global) `.castr` object storage on the fedora ftp mirrors.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7275
5 years
[releng] Issue #7300: Deny push / Implement git hook for unescaped macro in
%changelog
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
```python
#!/usr/bin/python3
import re
import sys
replace = False
out = []
with open(sys.argv[1], "r"):
for l in open(sys.argv[1], "r"):
out.append(l)
if l.startswith("%changelog"):
replace = True
continue
if not replace:
continue
if l.startswith("%"):
replace = False
continue
if l.startswith("*"):
# XXX: HACK
continue
out[-1] = re.sub(r"([^%])%([^% \n\d])", r"\1%%\2", l)
with open(sys.argv[1], "w") as f:
f.writelines(out)
```
This is something I've been using for automatic fix myself. I think we should either prohibit pushing this or have git-hook which would fix it automatically.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7300
5 years
[releng] Issue #7878: Please make pm_request available (and working) in koji
by Nicolas Mailhot
nim reported a new issue against the project: `releng` that you are following:
``
So the Go (golang) ecosystem is a morass of fast-changing software, with massive code reuse, and components that get created/forked/renamed/deprecated at a fast pace. This is similar to other "modern" language ecosystems such as javascript.
This has led to mass-generation of Go spec files in Fedora from code analysis tools (and has prevented any form of official Fedora Go packaging guidelines).
However, generating specs outside rpm leads to specs that rot at a fast pace. No one really understands or audits the generated code, and as soon as you need to adapt it due to some upstream quirk you lose the ability to regenerate it cleanly.
And you can not ignore golang or javascript, the first is used by pretty much any container-oriented software, the other by pretty much anything that needs to present a web ui.
Therefore I've been trying for a year to put back the generation logic within rpm macros, so it's centralized, audited and and controlled by Fedora, and the generation logic is cleanly separated from human adaptations in the corresponding spec files.
For build requires, that means computing the code needs in %prep and getting mock to install the corresponding packages. The approach agreed on with FPC members and upstream mock was to use the pm_request mock plug-in and the corresponding logic written by the Java sig in javapackages.
https://github.com/rpm-software-management/mock/issues/160
Unfortunately the Java SIG code was too imbricated with Java specific things to be reusable so I ended up writing a separate mock pm request client
https://github.com/nim-nim/mock-install
https://copr.fedorainfracloud.org/coprs/nim/mock-install/
https://bugzilla.redhat.com/show_bug.cgi?id=1629371
And now I find out pm_request is not available in koji and copr (don't know it it was before and has been removed since, or if it was never enabled because the java sig built its stuff elsewhere)
Anyway:
1. please enable pm_request in koji
2. please make sure that it works
https://github.com/rpm-software-management/mock/issues/218
How to test:
1. take a mock install binary from
https://copr.fedorainfracloud.org/coprs/nim/mock-install/
2. use any spec you like that calls mock-install <package-name> from %prep
See also
https://pagure.io/koji/issue/1133
https://bugzilla.redhat.com/show_bug.cgi?id=1641187
https://bugzilla.redhat.com/show_bug.cgi?id=1641191
https://bugzilla.redhat.com/show_bug.cgi?id=1629371
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7878
5 years