[releng] Issue #8023: [System-wide change] Fully remove deprecated and
unsafe functions from libcrypt
by Björn Esser
besser82 reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
System-wide change to remove the encrypt, encrypt_r, setkey, setkey_r, and fcrypt functions from the system-default libcrypt library. This includes a so-name bump from `libcrypt.so.1` to `libcrypt.so.2`. A compatibility library for the `libcrypt.so.1` library will still be provided, so there is no fallout or negative impact on the build-roots for Fedora 30.
The packages requiring `libcrypt.so.1` can either be rebuild during a planned mass-rebuild or by the requestee.
See: TBA
* When do you need this?
Before the mass-rebuild for Fedora 30 starts.
* When is this no longer needed or useful?
After the completion deadline of system-wide changes for Fedora 30.
* If we cannot complete your request, what is the impact?
The change cannot be done nor completed.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8023
5 years
[releng] Issue #8026: Packages are not retired entirely
by Vít Ondruch
vondruch reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
There was recently mass retirement of orphaned packages. However, the retirement does not work as expected IMO and not everything is removed.
Now I'll continue to speak specifically about rubygem-acts-as-taggable-on \[[1]\], but I suspect that this is a general issue.
I have no Idea why there is still "ruby-packagers-sig" listed among committers. Every committer should be removed upon retirement IMO and groups especially.
Also, the package is somehow watched by me. I don't know it that is because I am member of ruby-packagers-sig, but I definitely don't want to watch such package.
* When do you need this? (YYYY/MM/DD)
The sooner the better.
* When is this no longer needed or useful? (YYYY/MM/DD)
When Pagure is fixed or replaced by something else.
* If we cannot complete your request, what is the impact?
I am annoyed ;)
[1] https://src.fedoraproject.org/rpms/rubygem-acts-as-taggable-on
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8026
5 years
[releng] Issue #8012: Self-contained change proposal: krb5 crypto
modernization
by Robbie Harwood
rharwood reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Mandatory check with rel-eng is required for Fedora 30 change proposal [krb5 crypto modernization](https://fedoraproject.org/wiki/Changes/krb5_crypto_moderni.... I don't expect any impact, but that's why we do these checks.
* When do you need this? (YYYY/MM/DD)
Change submission deadline is 2019-01-29 for self-contained changes
* When is this no longer needed or useful? (YYYY/MM/DD)
Beta freeze is 2019-03-05, but I think it really should be done before the submission deadline of 2019-01-29.
* If we cannot complete your request, what is the impact?
I'm not actually sure and policy doesn't really say. I think it goes forward anyway without your input? Maybe it doesn't get accepted? Hopefully this isn't an issue.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8012
5 years
[releng] Issue #7994: Inform module maintainers when their module/stream is
going to EOL
by Mohan Boddu
mohanboddu reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Currently there is no way right now to intimate the module maintainers when their module/stream is going EOL. It would good if we can send some notifications about it prior to their EOL.
This requires parsing through all modules/streams in PDC to get their EOL dates and if its getting EOL'd in a week (or something more, we have to decide on this duration) , then find the maintainer of that module in dist-git and send them an email.
* When do you need this? (YYYY/MM/DD)
ASAP
* When is this no longer needed or useful? (YYYY/MM/DD)
Its always useful
* If we cannot complete your request, what is the impact?
Every time maintainers will have issues pushing to dist-git if their module/stream is EOL'd.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7994
5 years
[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 #8191: logs attached to FTBFS issues are too short to be
usable for anything
by Zbigniew Jędrzejewski-Szmek
zbyszek reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Pretty much every FTBFS bugs has "file build.log too big, will only attach last 1024 bytes" and "file root.log too big, will only attach last 1024 bytes". 1024 *lines* would be somewhat useful, but 1024 characters is just the spew that mock outputs at the end of every build and contains no hint why the build failed whatsoever.
In addition, the message does not specify what kind of failure was encountered. koji knows this and says to look either in root.log (dependency issues) or build.log (build issues). It would be great if this could be included in the bug message.
* When do you need this? (YYYY/MM/DD)
For the next rebuild.
* When is this no longer needed or useful? (YYYY/MM/DD)
When packages stop failing to build.
* If we cannot complete your request, what is the impact?
Maintainers have harder time solving FTBFS bugs.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8191
5 years