Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
On 4/24/24 11:14 AM, Aoife Moloney wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE
Announced -
https://discussion.fedoraproject.org/t/f41-change-proposal-drop-mandatory-requires-on-jre-system-wide/114186
[snip]
=== Context ===
Java packages are compiled using `javac` into `.class` files and
composed into `.jar` archives. Jar archives can be used as compile or
runtime dependencies for other packages or can be directly executed
with the java command provided by a JRE.
Jar archives can be executed using the command: `java -jar ${FILE}`.
This command executes the `main` method either specified via CLI or
specified within the Jar manifest file.
Java packages, which serve as libraries only, lack the `main` method
and are not executable. Therefore, there is no requirement on any
specific JRE imposed by the library implicitly.
Sort of... bytecodes do get introduced over time, right? While in practice I
expect nobody will try and running, say, anything older than Java 7 (JSR 7
introduced invokedynamic), should there be a way to specify a generic minimum
runtime version? I guess the tricky thing here is that different JDKs might not
be packaged in a way where they all implement a common virtual provide that can
be targeted
$ fedrq pkgs -P java-headless
java-21-openjdk-headless-1:21.0.2.0.13-3.fc41.x86_64
$ fedrq pkgs -P java-headless -F provides
libjsvml.so()(64bit)
libsyslookup.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
lible.so()(64bit)
libjava.so()(64bit)
libjsig.so()(64bit)
libverify.so()(64bit)
java-21-openjdk-headless(x86-64) = 1:21.0.2.0.13-3.fc41
config(java-21-openjdk-headless) = 1:21.0.2.0.13-3.fc41
java-21-headless = 1:21.0.2.0.13-3.fc41
java-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
java-headless = 1:21.0.2.0.13-3.fc41
java-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-21-headless = 1:21.0.2.0.13-3.fc41
jre-21-openjdk-headless = 1:21.0.2.0.13-3.fc41
jre-headless = 1:21.0.2.0.13-3.fc41
jre-openjdk-headless = 1:21.0.2.0.13-3.fc41
=== Different JDKs ===
This proposal is also related to the topic of different JDKs.
Developers may want to use or build packages which use a JDK different
than the one provided by the `java--openjdk` package. After this
proposal was implemented, they would be able to depend on Java library
packages with no introduction of the OpenJDK package.
=== Rationale ===
Java libraries are more similar to native libraries than to libraries
written in dynamic scripting languages. They are compiled to a
bytecode and are not executable. Java libraries can be used as
dependencies for any Java application and there is no implicit
dependency on the system default JDK.
Java applications, on the other hand, are expected to be tested and to
work with the system JDK and from the user's perspective: after
installing an application they must be able to simply run the binary.
Therefore the `Requires` on the system JDK is kept for Java
applications.
Would this be clearer if it says "the JRE from the system JDK"? Since the apps
are not actually pulling in the full JDK itself.
Best regards,
--
_o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
OpenPGP_0x8B229D2F7CCC04F2.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Anyone want to maintain openssl3 for epel8?
On 4/22/24 17:03, Michel Lind wrote: I created this (tracking c9s' openssl package) since there were plans to start depending on openssl v3 in systemd back in 2022, but looks like that has not happened yet - and CentOS Hyperscale SIG is no longer updating our systemd package for c8s. The maintenance involved is mainly rebasing changes from c9s, though someone who actually have a need for this would be better able to verify that the builds are actually working. If there's no taker in two weeks, per https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ I'll retire the package. As a parting gift, this update closes most of the open bugs. There are two CVEs from 2024 that I can't confirm are fixed in the c9s package so I left them in NEW https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b002585dd2 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Heads-up] More spring cleaning: orphaning bamf
On 4/22/24 16:32, Fabio Valentini wrote: On Mon, Apr 22, 2024 at 11:12 PM Michel Lind wrote: Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed $ fedrq whatrequires bamf bamf-daemon-0.5.5-8.fc40.x86_64 bamf-devel-0.5.5-8.fc40.i686 bamf-devel-0.5.5-8.fc40.x86_64 plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 So if you use plank, or otherwise have a need for this, feel free to take this over. The story with plank is a bit weird ... The last release was in 2019, and elementary OS forked it some years later, because upstream development was pretty much dead. At that point, I was a (co-)maintainer of the plank package, and switched the package to build from the elementary fork, because it had fixes and support for some new stuff. However, elementary has been developing their own dock from scratch (with eyes on eventual Wayland support), and the plank project on launchpad actually looks more active again :| So maybe the package should be switched back to the original upstream when / if the new elementary Dock is ready (it's not yet) ... Nice. The plank in our dist-git is from... uh, 2021. So it's probably overdue for an update. -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Anyone want to maintain openssl3 for epel8?
I created this (tracking c9s' openssl package) since there were plans to start depending on openssl v3 in systemd back in 2022, but looks like that has not happened yet - and CentOS Hyperscale SIG is no longer updating our systemd package for c8s. The maintenance involved is mainly rebasing changes from c9s, though someone who actually have a need for this would be better able to verify that the builds are actually working. If there's no taker in two weeks, per https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ I'll retire the package. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Heads-up] More spring cleaning: orphaning bamf
On 4/22/24 16:12, Michel Lind wrote: Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed That should have been plank-maintainers, sorry -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Heads-up] More spring cleaning: orphaning bamf
Dear all, I've been maintaining bamf for... quite some time, and don't actually have a need for it anymore. It's pretty much in maintenance mode upstream as well. I've built the last stable version in Rawhide to close https://bugzilla.redhat.com/show_bug.cgi?id=2055853 but will probably not build for stable releases, I'll let the new maintainer(s) handle that. Right now it looks like only plank actually uses it; its maintainer is cc:ed $ fedrq whatrequires bamf bamf-daemon-0.5.5-8.fc40.x86_64 bamf-devel-0.5.5-8.fc40.i686 bamf-devel-0.5.5-8.fc40.x86_64 plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 So if you use plank, or otherwise have a need for this, feel free to take this over. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: orphaned bti (bash twitter id*ocy)
Dear all, I just orphaned https://src.fedoraproject.org/rpms/bti - a command-line Twitter client. I no longer use Twitter anymore, this package has basically not needed any attention (it rebuilds fine) but I'm not sure if it works anymore post-takeover. It does have an open issue asking for a port to pcre2, but upstream has not committed anything in 7 years. There is a PR from 2021 that addressed the pcre2 issue, if anyone wants to pick this up: https://github.com/gregkh/bti/pull/54 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: Proposing incompatible upgrade of python-asgiref from 3.4.1 to 3.7.2
Hi all, On 4/11/24 16:25, Michel Lind wrote: Dear all, Django 4.2 (the only currently supported LTS series) requires asgiref >= 3.6, so I would like to propose updating python-asgiref in EPEL 9 at least to 3.6.0, but ideally to 3.8.1 for future proofing. The affected packages (maintainers bcc:ed) are python-django3 (which I maintain, and has just reached EOL) and python-opentelemetry ❯ fedrq whatrequires 'python3dist(asgiref)' -b epel9 python-django3-3.2.20-3.el9.src python-opentelemetry-1.12.0-8.el9.src ❯ fedrq pkgs --src -P python-django3 -F requires -b epel9 | grep asgi python3dist(asgiref) >= 3.3.2 (python3dist(asgiref) < 4~~ with python3dist(asgiref) >= 3.3.2) ❯ fedrq pkgs --src -P python-opentelemetry -F requires -b epel9 | grep asgi (python3dist(asgiref) >= 3 with python3dist(asgiref) < 4) It's been a week, the maintainers of the specific packages have granted their approval and the Steering Committee has been consulted. Since opentelemetry and django3 builds fine with asgiref 3.7.2 from Fedora, I have now built it and published an update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-d56e78a735 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Picking up protobuf
Hi Major, On 4/18/24 13:25, Major Hayden wrote: On Wed, Apr 17, 2024, at 21:51, Michel Lind wrote: Hi all, protobuf was recently orphaned without any announcement to this list. I've picked it up since et depends on it. Thanks for picking that up, Michel. I intended to mail the list yesterday and totally lost track of time. 臘♂️ No worries! I was wondering who the previous maintainer was - the RHBZ overrides made it super confusing :) The big challenge we had with protobuf is that updating it broke quite a few things built against the old version. But staying put with the same version led to problems with newer packages that were coming along day by day. Yeah... it might be worth just upgrading in Rawhide and not touch the stable releases, as Sérgio suggested, unless there is an urgent security update? We should let maintainers of protobuf dependents chime in too. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Picking up protobuf
Hi Neil, On 4/18/24 06:37, Neil Hanlon wrote: thanks Michel! I'd be happy to help maintain if you would like assistance. There are 3 previous maintainers, plus the EPEL bugzilla is overridden to Peter Lemenkov (cc:ed) who is not in the ACL yet. So I'd rather take things slow and not make unilateral ACL changes. Any PR welcome though! (And I'll try and sort out existing issues and PRs in between conference prep). Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Picking up protobuf
Hi Sérgio, On 4/18/24 06:44, Sérgio Basto wrote: On Wed, 2024-04-17 at 21:51 -0500, Michel Lind wrote: Hi all, protobuf was recently orphaned without any announcement to this list. I've picked it up since et depends on it. Update protobuf is a huge task see https://src.fedoraproject.org/rpms/protobuf/pull-request/26 ( move from protobuf-3.19.6 to 3.25.1 ) I think we should try enforce the update on rawhide , and just after look to protobuf-3.26. Agreed - we definitely should only do major upgrades on Rawhide. Best, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Picking up protobuf
Hi all, protobuf was recently orphaned without any announcement to this list. I've picked it up since et depends on it. Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: Proposing incompatible upgrade of python-asgiref from 3.4.1 to 3.7.2
On 4/16/24 15:56, Michel Lind wrote: I'll confirm whether we can go ahead with updating this at the EPEL meeting tomorrow, or we should wait a full week per https://tdawson.fedorapeople.org/epel-docs/public/epel/epel-policy-incompatible-upgrades/ since this blocks the packaging of python-django4.2, and Django 3 is already EOL. Google failed me, this is the actual policy https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: Proposing incompatible upgrade of python-asgiref from 3.4.1 to 3.7.2
Dear all, On 4/11/24 16:25, Michel Lind wrote: Dear all, Django 4.2 (the only currently supported LTS series) requires asgiref >= 3.6, so I would like to propose updating python-asgiref in EPEL 9 at least to 3.6.0, but ideally to 3.8.1 for future proofing. The affected packages (maintainers bcc:ed) are python-django3 (which I maintain, and has just reached EOL) and python-opentelemetry ❯ fedrq whatrequires 'python3dist(asgiref)' -b epel9 python-django3-3.2.20-3.el9.src python-opentelemetry-1.12.0-8.el9.src ❯ fedrq pkgs --src -P python-django3 -F requires -b epel9 | grep asgi python3dist(asgiref) >= 3.3.2 (python3dist(asgiref) < 4~~ with python3dist(asgiref) >= 3.3.2) ❯ fedrq pkgs --src -P python-opentelemetry -F requires -b epel9 | grep asgi (python3dist(asgiref) >= 3 with python3dist(asgiref) < 4) The latest python-django3 and python-opentelemetry epel9 commits have been rebuilt successfully in COPR against F39's asgiref 3.7.2, all rebuilt for both epel9 and epel9-next. https://copr.fedorainfracloud.org/coprs/salimma/asgiref-3.7/packages/ I'll confirm whether we can go ahead with updating this at the EPEL meeting tomorrow, or we should wait a full week per https://tdawson.fedorapeople.org/epel-docs/public/epel/epel-policy-incompatible-upgrades/ since this blocks the packaging of python-django4.2, and Django 3 is already EOL. (per private discussion with the opentelemetry maintainer, music greenlit the upgrade provided opentelemetry scratch-rebuilds fine as is) Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: Django latest vs LTS maintenance plan
Hi Kevin, On 4/12/24 11:45, Kevin Fenzi wrote: On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote: Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it To be clear, in fedora right? There wouldn't be a bare python-django in EPEL? Correct. There is no bare python-django in epel8 and epel9 currently and I don't plan to introduce one. There is /unfortunately/ one for epel7, but happily that will go EOL soon. - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. I think it does make a lot of sense. ;) On the epel side, it would be good to make some noise/announce when a LTS one is marked deprecated and when it's retired, since 3rd parties might be using it for the external stuff even if everything in EPEL moves to the new one. Good point! That's also a reason I marked it as deprecated only (and don't plan on removing it immediately even when python-django4.2 is in epel9). I'll add concern for external usage as an explicit consideration. Would a EPEL package moving to a new LTS release need exceptions/announcements also? I mean, ideally it doesn't matter, but it would be a large version jump, even if the dependent package didn't change otherwise. Also, there might be cases where the dependent package does have to change... ie, foo-1.0 works with django-3.2, but when 4.2 lands you have to upgrade to foo-2.0 to work with it? Exceptions, not in most cases where it's a no-op. But in case the package needs to be updated, I expect it needs an incompatible update exception, yes. We might want to consider a single announcement when the old LTS is already deprecated and we can't hold off on rebuilding packages where the old versions don't work with the new LTS yet, but otherwise, we probably should only do incompatible upgrades if something needs the new version (e.g. our mailman stack) Anyhow, I think this is a pretty reasonable process, but we should make sure and communicate it very well, document it and make sure epel steering comittee is happy with it. Agreed. I filed https://pagure.io/epel/issue/271 so we can discuss it tomorrow. Thanks, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: network service removed in Fedora 40 without a Change proposal(?)
On Mon, Apr 15, 2024 at 09:20:32PM -, Japheth J.C. Cleaver wrote: > > The System-V scripts are also deprecated since systemd v254 so > > eventually they'll be going away too: > > > > https://lists.freedesktop.org/archives/systemd-devel/2023-August/049349.html > > This change should be reverted in Fedora. The "systemd cabal"'s hatred of > SysV is insufficient justification for this dropping a 'network' service, and > there exist myriad third-party tools that prefer imperative control over > their start process anyway. Regardless of whether you agree with deprecating SysV or not, network-scripts' removal from Fedora has nothing to do with the "systemd cabal" - indeed, the systemd maintainer in Fedora, zbyszek, voted in favor of restoring network-scripts earlier today. Best regards, and let's treat each other respectfully, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Updating Taskwarrior to v3
Hi Ankur, On 4/15/24 07:59, Ankur Sinha wrote: On Mon, Apr 15, 2024 14:18:59 +0200, Jos Vos wrote: On Mon, Apr 15, 2024 at 12:15:55PM +0100, Ankur Sinha wrote: Hrm, but the problem here is that a user that currently has the task package installed (currently v2) will end up with v3 if I update the task package to v3---which is something we'd like to avoid here. Just a side question: is this task v3 update planned to be distributed *during* an OS lifecycle or only at the start of a new one (e.g. F41, I assume it is too late for F40 now)? Are there any Fedora policies for this kind of incompatible updates? The general policy is to not introduce backwards incompatible changes to stable releases: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases I am thinking that the best way for this would be to announce it as a self-contained change so it'll land in rawhide (F41). In the meantime, I can perhaps keep a COPR repository for stable Fedora releases (F39/F40) for users that do want to use taskv3 already. https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_self_contained_changes How does that sound? What you can probably do now is to introduce the compat package *first* into all stable releases - and make it obsolete the task package at the current NEVRA. Then for Rawhide, you can update the task package to version 3 - that way current users will get moved to task2 seamlessly (probably make the update suggest they log out, just in case), and when task v3 is packaged, they can then export their current database using the existing task2 and import it after reinstalling task? Best, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote: > Regarding libteam, the author of the package is the maintainer, email in > bugzilla is different than the one on the project. I wonder if Jiro just > missed the notification that his package is failing to build in F40. > Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do so, maybe change your email in https://accounts.fedoraproject.org/user/salimma/settings/email/ ? Meanwhile I'm doing a build that removes the network-scripts-teamd subpackage - my initial glance at the changelog was wrong, most Fedora releases are already on 1.32 so we don't need to bump the package yet. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Fri, Apr 12, 2024 at 09:09:31AM -0500, Maxwell G wrote: > Report started at 2024-04-12 13:04:40 UTC > libteam orphan 0 weeks > ago > > The following packages require above mentioned packages: > Depending on: libteam (56), status change: 2024-04-07 (0 weeks ago) > NetworkManager (maintained by: @gnome-sig, alexl, bengal, caolanm, > danw, dcbw, ffmancera, ihuguet, liangwen12year, lkundrak, rhughes, rstrode, > thaller) > NetworkManager-1:1.46.0-2.fc41.src requires teamd-devel = > 1.32-4.fc40 > NetworkManager-team-1:1.46.0-2.fc41.x86_64 requires > libteamdctl.so.0()(64bit) > > anaconda (maintained by: anaconda-maint, jkonecny, kkoukiou, m4rtink, > rvykydal, vladimirslavik, vponcova) > anaconda-core-41.9-1.fc41.x86_64 requires NetworkManager = > 1:1.46.0-2.fc41, NetworkManager-libnm = 1:1.46.0-2.fc41, NetworkManager-team > = 1:1.46.0-2.fc41, teamd = 1.32-4.fc40 > anaconda-gui-41.9-1.fc41.x86_64 requires NetworkManager-wifi = > 1:1.46.0-2.fc41 > > ladvd (maintained by: @epel-packagers-sig, ixs, ttorcz) > ladvd-1.1.2-20.fc40.src requires libteam-devel = 1.32-4.fc40 > ladvd-1.1.2-20.fc40.x86_64 requires libteam.so.5()(64bit) > ... That's a lot of dependent packages! I've taken up libteam, the open bugs seem reasonable to fix and there is a new release as well (I'll prioritize fixing the bug first then build the new release in Rawhide first). If there's anyone who is interested in comaintaining libteam, let me know. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote: > > > On 11. 04. 24 22:41, Michel Lind wrote: > > The different Django stacks are in the process of being updated so they > > can be swapped without affecting dependents, by providing and > > conflicting with the virtual `python-django-impl`; not only will this > > allow us to swap one Django LTS for another in EPEL when the older one > > EOLs, but it also allows those with dependencies that are not qualified > > for the latest Django to swap to the LTS in Fedora > > I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: > pytohn3dist(django)`? > Oh good point, that would work too. We'd still need to come up with names for the bash-completion and doc subpackages though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote: > > > On 11. 04. 24 22:41, Michel Lind wrote: > > The different Django stacks are in the process of being updated so they > > can be swapped without affecting dependents, by providing and > > conflicting with the virtual `python-django-impl`; not only will this > > allow us to swap one Django LTS for another in EPEL when the older one > > EOLs, but it also allows those with dependencies that are not qualified > > for the latest Django to swap to the LTS in Fedora > > I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: > pytohn3dist(django)`? > Oh good point, that would work too. We'd still need to come up with names for the bash-completion and doc subpackages though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] RFC: Proposing incompatible upgrade of python-asgiref from 3.4.1 to 3.7.2
Dear all, Django 4.2 (the only currently supported LTS series) requires asgiref >= 3.6, so I would like to propose updating python-asgiref in EPEL 9 at least to 3.6.0, but ideally to 3.8.1 for future proofing. The affected packages (maintainers bcc:ed) are python-django3 (which I maintain, and has just reached EOL) and python-opentelemetry ❯ fedrq whatrequires 'python3dist(asgiref)' -b epel9 python-django3-3.2.20-3.el9.src python-opentelemetry-1.12.0-8.el9.src ❯ fedrq pkgs --src -P python-django3 -F requires -b epel9 | grep asgi python3dist(asgiref) >= 3.3.2 (python3dist(asgiref) < 4~~ with python3dist(asgiref) >= 3.3.2) ❯ fedrq pkgs --src -P python-opentelemetry -F requires -b epel9 | grep asgi (python3dist(asgiref) >= 3 with python3dist(asgiref) < 4) The relevant breaking changes seem to be (starting from the safest option of upgrading only to 3.6.0) https://github.com/django/asgiref/blob/main/CHANGELOG.txt * 3.6.0 Support for the ``ASGI_THREADS`` environment variable, used by ``SyncToAsync``, is removed. In general, a running event-loop is not available to `asgiref` at import time, and so the default thread pool executor cannot be configured. Protocol servers, or applications, should set the default executor as required when configuring the event loop at application startup. I don't see anything that could be breaking in 3.7.x and 3.8.x, but PTAL Note that Fedora's opentelemetry 1.24 has not bumped its asgiref requirement, so we are probably OK leaving it as is ❯ fedrq pkgs --src -P python-opentelemetry -F requires | grep asgi python3dist(asgiref) (python3dist(asgiref) >= 3 with python3dist(asgiref) < 4) ❯ fedrq pkgs --src python-opentelemetry python-opentelemetry-1.24.0-3.fc41.src Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RFC: Django latest vs LTS maintenance plan
Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. [^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/ Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] RFC: Django latest vs LTS maintenance plan
Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. [^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/ Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
RFC: Django latest vs LTS maintenance plan
Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. [^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/ Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 01:45:26PM -0400, Ben Beasley wrote: > The rust-circular-buffer crate was packaged as a dependency for bpftop, > https://github.com/Netflix/bpftop. > > I won’t necessarily be packaging bpftop myself, but I know several parties > are interested in doing so, and I expect it will happen soon one way or the > other. > > A few existing dependencies still need to be updated first: > > Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 with > crate(anyhow/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 0.23.0 > with crate(libbpf-rs/default) < 0.24.0~) > Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 1.4.0 > with crate(libbpf-sys/default) < 2.0.0~) > Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with > crate(ratatui) < 0.27.0~) > Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 0.26.1 > with crate(ratatui/crossterm) < 0.27.0~) > Problem 6: nothing provides requested (crate(tui-input/default) >= 0.8.0 > with crate(tui-input/default) < 0.9.0~) > Speaking of all the bpf* - I have a TODO (will ping the chat too) to update below, which I expect will require a lot of libbpf-* to be updated. For ratatui -- nu-explore >= 0.91.0 needs 0.26, but I dropped it to 0.25 instead, trying to remember why. Ah... because dua-cli, gimoji, and tui-react needs the old one ❯ fedrq-cratedeps-verbose.sh ratatui rust-dua-cli : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~) rust-gimoji : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) < 0.26.0~) rust-nu-explore : (crate(ratatui/default) >= 0.25.0 with crate(ratatui/default) < 0.26.0~) rust-tui-react : (crate(ratatui) >= 0.25.0 with crate(ratatui) < 0.26.0~) Best, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
Hi Fabio,
On Thu, Apr 11, 2024 at 03:26:13PM +0200, Fabio Valentini wrote:
> If you know of a reason why a leaf package where I am the primary
> maintainer should not be retired, please let me know, and I will
> exclude it from the list.
>
Thanks for organizing the cleanup!
>
> +--++---+--+
> | Package | Leaf since | Leaf days | Maintainer
> |
> +--++---+--+
> | rust-atomic-traits | 2022-09-02 | 587 | salimma
> |
Still trying to package mmtk, please keep this one for now
> | rust-signal | 2023-02-23 | 413 | salimma
> |
Not sure about this one. Looks like psutil depends on it, and ytop
depends on psutil, but ytop is almost 4 years old... probably retire it
> | rust-sptr| 2023-03-28 | 380 | salimma
> |
This is needed by portable-atomic which is needed by pyo3, right?
> | rust-xcb | 2023-05-10 | 337 | salimma
> |
We can kill this I guess. Death to X
> | rust-powierza-coefficient| 2023-06-16 | 300 | salimma
> |
I wonder what used it in the past. crates.io now only lists kn ... so
yeah kill it
> | rust-wayland-commons | 2024-01-02 | 100 | salimma
> |
Looks like wayland-{client,server} no longer needs this (since > 0.29).
Kill.
> | rust-nom-supreme | 2024-01-04 |98 | salimma
> |
Can't find what's actually using it, maybe kill
> | rust-vec1| 2024-01-04 |98 | salimma
> |
Ditto - not sure what I needed this for, probably dropped upstream
> | rust-async-process | 2024-01-07 |95 | decathorpe
> |
> | rust-notify-debouncer-mini | 2024-01-07 |95 | decathorpe
> |
> | rust-safetensors | 2024-01-07 |95 | thunderbirdtr
> |
> | rust-unidecode | 2024-01-15 |87 | decathorpe
> |
> | rust-rlimit | 2024-01-17 |85 | salimma
> |
Ditto
> | rust-base32 | 2024-01-20 |82 | salimma
> |
rbw needs this, still in progress
>
> - salimma (10): rust-atomic-traits, rust-base32, rust-nom-supreme,
> rust-powierza-coefficient, rust-rlimit, rust-signal, rust-sptr,
> rust-vec1, rust-wayland-commons, rust-xcb
>
Best,
--
_o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 05:39:11PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Apr 08, 2024 at 01:12:38PM -0500, Michel Lind wrote: > > On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote: > > > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > > > It's bascially the same problem as Fedora has when users upgrade from > > > > Fredora > > > > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that > > > > upgrade path > > > > between Fedoras is not maintained anymore and users need to do "dnf > > > > distro-sync" to ignore the RPM versioning. > > > > > > > > All that stems from tha fact that a number of commits between parallelly > > > > supported braches is not monotonic. > > > > > > > > > > We did this long before rpmautospec existed. We switched to this > > > behavior in Fedora 23 because we have never fully maintained "upgrade > > > paths" across releases. > > > > > > > Per private message with Neal this seems to be the Change that brought > > it about: > > > > https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades > > > > I'm ... a bit surprised that we don't seem to have any documentation > > stating explicitly that the assumption that NEVRAs in a newer release > > are no longer assumed to be monotonically higher. > > That Change was primarily about replacing fedup with > dnf-plugin-system-upgrade, > changing from a custom-initrd-based solution that was rather fragile, to > a special systemd target during early boot. > > dnf-plugin-system-upgrade uses 'distro-sync' because that's the most > reliable and easy way to do the upgrade, suitable for end users. > But this doesn't necessarilly mean that this is the only upgrade > method that can be used. That Change certainly wasn't intended to > change the packaging guidelines. > > In general, we still keep the upgrade path. It's not enforced all > the time, but I think it's still good style. > Fair enough, thanks. There's some confusion there because of this assertion that this is no longer done, instead of just not enforced. Best, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 09, 2024 at 02:20:37PM +0200, Petr Pisar wrote: > > - should we extend this further and say, if we no longer assume NEVRAs > > are monotonically increasing in a new release, we should allow > > packagers to use this opportunity to drop epochs in Rawhide? (likely > > with proper announcement beforehand in devel@) > > > Who will check reverse dependncies? E.g. perl will drop "Epoch: 4". Who will > check that no other package "Requires: perl > 4:..."? I remind that > fedora-ci.koji-build.rpmdeplint.functional gating test is still not enforced > globally. > Good point. I'm still following up on trying to get the current gating tests enabled for EPEL -- and there are still occasions where they don't run on Fedora too. There's also the issue that, AIUI, the installability check tests whether the packages in the update set are installable, but does not check whether they break any revdep... room for improvement there, and maybe that can be tackled first. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 08:47:20PM +0200, Leon Fauster via devel wrote: > Am 08.04.24 um 20:12 schrieb Michel Lind: > >(this might require coordination with RH's Leapp developers and > >AlmaLinux's ELevate developers, to make sure those support upgrading > >to lower NEVRAs too) > > Would have a major EL release have a lower package NEVRA? > Mmmh, how many fedora releases are in between? :-) > If, say, EL9 inherits a Fedora 34 package with epoch set to 1, and we allow Fedora epoch to be reset in Rawhide, and EL10 then inherits a Fedora 40 package with epoch reset to 0 (change as suitable - more likely to be EL10 from F40 and EL11 from F46, but in general there are 6 Fedora releases in between) -- then even if the version is higher because the epoch is dropped, the EL(N+1) NEVRA will be lower. Cheers, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 08, 2024 at 07:21:40AM -0400, Neal Gompa wrote: > On Mon, Apr 8, 2024 at 7:11 AM Petr Pisar wrote: > > It's bascially the same problem as Fedora has when users upgrade from > > Fredora > > 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade > > path > > between Fedoras is not maintained anymore and users need to do "dnf > > distro-sync" to ignore the RPM versioning. > > > > All that stems from tha fact that a number of commits between parallelly > > supported braches is not monotonic. > > > > We did this long before rpmautospec existed. We switched to this > behavior in Fedora 23 because we have never fully maintained "upgrade > paths" across releases. > Per private message with Neal this seems to be the Change that brought it about: https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades I'm ... a bit surprised that we don't seem to have any documentation stating explicitly that the assumption that NEVRAs in a newer release are no longer assumed to be monotonically higher. e.g. packaging guidelines still say "Rawhide is allowed to lag *temporarily*" (emphasis mine) https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily I suppose the user facing documentation does say that upgrading using only DNF is not tested -- but there's no guideline about loosening monotonicity provided to packagers as far as I can tell. https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/#_can_i_upgrade_between_fedora_releases_using_only_dnf So, questions: - should we update the packaging docs? Does this need to be a new Change Proposal or does this just need to go through the Fedora packaging committee? (Those involved in the Change like zbyszek can probably advise here) - should we extend this further and say, if we no longer assume NEVRAs are monotonically increasing in a new release, we should allow packagers to use this opportunity to drop epochs in Rawhide? (likely with proper announcement beforehand in devel@) (this might require coordination with RH's Leapp developers and AlmaLinux's ELevate developers, to make sure those support upgrading to lower NEVRAs too) Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Sat, Mar 30, 2024 at 04:30:53PM -0500, Chris Adams wrote: > Once upon a time, Kevin Kofler said: > > Unit tests are something for upstream developers. They should NEVER be run > > in a distribution build. > > Upstream developers aren't testing in every Fedora release (which > whatever the current compiler+library+app combo is), so unit tests > should always be run when available in the Fedora environment. > Don't forget architectures. One of the reasons I use to justify getting my company's open source projects in distributions like Fedora and Debian is to surface issues when compiling against various compiler+library+app combo as you noted but as importantly, architecture specific issues. Preserving the build artifacts so they can't be tampered with during the test run is probably worthwhile though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)
Hi Jens, Apologies for resurrecting and older thread here On Thu, Feb 22, 2024 at 02:06:22PM +0800, Jens-Ulrik Petersen wrote: > (Not sure if it makes sense to post to Discourse: Haskell library reviews > are still a little bit "esoteric" since ghc uses some non-standard linking > (ie various warnings appear which tend to discourage/throw less experienced > reviewers alas: perhaps they should be spelled out further as exception(s) > in the Haskell Packaging policy, so I don't need to keep explaining them). > Warnings from fedora-review and rpmlint, or in the build output? If the warnings are from the first two, we should probably try and get them fixed - I will try and look closely the next time I do a Haskell review. Some other ecosystems (e.g. Guile) also trigger a lot of rpmlint warnings, and I have in mind fixing the rpmlint policies so that at some point we can actually make use of the result - right now there's too many false positives. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: planning to retire libgee06
Dear all, Just a heads up that the legacy libgee06 package is FTBFS for F40/F41: https://bugzilla.redhat.com/show_bug.cgi?id=2261317 and only has one dependent, libfep: ``` ❯ fedrq whatrequires libgee06-devel libfep-0.1.0-24.fc40.src ❯ fedrq whatrequires libgee06-devel -b f39 libfep-0.1.0-22.fc39.src ❯ fedrq whatrequires libfep-devel -b f39 ibus-fep-1.4.4-23.fc39.src libskk-1.0.4-12.fc39.src ``` Since libfep itself has dependents, I checked and it looks like it does not actually need libgee06 (or libgee) - or not anymore - and rebuilding it with the BR dropped succeeds with virtually the same Requires and Provides in the generated RPMs: https://src.fedoraproject.org/rpms/libfep/pull-request/1 I'm cc:ing the libfep maintainers; if I don't hear back in a few days I'll merge and build this and retire the package. Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Flock 2 Fedora 2024 Rochester New York USA
Hi smooge, On Wed, Feb 28, 2024 at 08:36:19AM -0500, Stephen Smoogen wrote: > I had not seen any announcements on this so wanted to drop it here > https://flocktofedora.org > Thanks for posting this! Can we get it out to devel-announce too? Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Introduction / unorphaning package request
On Mon, Feb 26, 2024 at 11:32:44AM -0800, Josh Stone wrote: > Welcome! > > Since name collisions are fun, I want to clarify for everyone else that > we are not the same person. I'm jistone, he's jostone, and I'm sure this > won't confuse anyone... :) > You should sponsor jostone for extra confusion :) > On 2/23/24 6:23 AM, Joshua Stone wrote: > > Hello everyone, > > > > I've been a Linux user since my friends showed me Ubuntu 9.04! That was > > a lifesaver when I needed an OS with a functional office suite after my > > MS Office 2007 license expired and Windows Vista was having stability > > issues. After multi-booting Windows and Linux for several years, I had > > decided that I no longer boot Windows enough to warrant the disk space, > > so I've been running Linux exclusively for over a decade. > > > > When I was first using Linux, I would distro hop between Ubuntu, Linux > > Mint, and Fedora, finally before settling on Fedora right around the > > time it switched to Wayland by default. > > > > I think Fedora has been very beneficial for me because it's given me > > enough of a background on RPM-based distros to have a career where I can > > use Linux professionally. My current employment is at Red Hat so I spend > > a lot of time packaging software. > > > > I also spend time maintaining several apps on Flathub, and I'd like to > > expand maintenance efforts to Fedora! > > > > Earlier I filed a request for unorphaning a package: > > > > https://pagure.io/releng/issue/11963 <https://pagure.io/releng/issue/11963> > > > > It would appear that there are several requirements I must fulfill, > > especially finding a sponsor. If there's anyone who can help, then I'd > > really appreciate it! I hope to be more involved with the Fedora community! > > > > Thanks! > > > > - Josh > > > > -- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Introduction / unorphaning package request
Hi Josh, On Fri, Feb 23, 2024 at 09:23:34AM -0500, Joshua Stone wrote: > Hello everyone, > > > I also spend time maintaining several apps on Flathub, and I'd like to > expand maintenance efforts to Fedora! > Welcome! > Earlier I filed a request for unorphaning a package: > > https://pagure.io/releng/issue/11963 > > It would appear that there are several requirements I must fulfill, > especially finding a sponsor. If there's anyone who can help, then I'd > really appreciate it! I hope to be more involved with the Fedora community! > You might want to join https://matrix.to/#/#golang:fedoraproject.org - the Golang SIG members are there, and you might get one of them to sponsor you. Note that there is a specific template to use for unretiring (not unorphaning - the package is retired because it was orphaned for too long), and it would have asked for the Bugzilla issue for the re-review - the package would have to be reviewed again as if it's a new package. I can't link to the template now since it seems OpenID is acting up right now :( This provides the full instructions for becoming a packager: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ and this for unretiring https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming and these are the packaging guidelines for Golang https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ HTH, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: updating python-poetry-core in EPEL 9 to 1.6.1
On Fri, Feb 16, 2024 at 01:44:34PM -0600, Michel Lind wrote: > On Fri, Feb 16, 2024 at 01:27:18PM -0600, Michel Lind wrote: > > except for python-asyncmy: > > https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/build/7026743/ > > > Looks like this is a known issue fixed in 0.2.7: > https://github.com/long2ice/asyncmy/blob/dev/CHANGELOG.md > > and there are no breaking changes up to 0.2.9 that is in our F39 branch, > which rebuilds fine as is. > > So the current plan is to build python-poetry-core 1.6.1-1 and > python-asyncmy 0.2.9-1 in a sidetag on Monday and then put up an update. > > cc-ing python-asyncmy maintainer here > > I'll post here when the update goes out, and if there's any concern > between now and Monday, let me know and I can delay that until that is > addressed. > These have now been built and submitted to Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-9efcc70a30 Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)
On Thu, Feb 15, 2024 at 07:53:38PM +, Christopher Klooz wrote: > On 14/02/2024 17.35, Michel Lind wrote: > > As a pandoc user, I'm happy to help with any reviews. Is there a list > > where this tends to get posted, apart from devel? > > > > Thanks, > > > > Michel > > Once the package needs a review, the request should be found here: > http://fedoraproject.org/PackageReviewStatus/ > > Details of the roles of "contributor" and "reviewer" in the "package review > process" can be found here: > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ > (based upon its history, I expect this page is kept updated but I don't know > for sure) > > According to the elaboration, you need to be in the FAS packager group, even > for reviews. > Thanks. I'm a long term packager so I know about these already ;) Was just wondering if there's another place where Haskell packaging is coordinated. -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposing a Fedora SIG for the upcoming COSMIC desktop environment
Hello and welcome! On Fri, Feb 16, 2024 at 08:59:49PM -, Ryan Brue wrote: > Hello all! This is my first time using a mailing list, but I want to do this > more often in the future :) > > > If you happen to like rust, or are simply excited to see another desktop > environment join the space, share your interest! > If there is enough interest, I would suggest we then create a matrix group, > similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC > bridge as well, for those interested in using IRC. Happy to join the Matrix room when it's created! Can't commit to being that involved, but it seems like there's going to be a lot of overlap on the packaging side with the Rust SIG I'm already in (Rust crates in Fedora are all co-maintained by the SIG) so feel free to drop in and ask questions at #rust:fedoraproject.org Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: updating python-poetry-core in EPEL 9 to 1.6.1
On Fri, Feb 16, 2024 at 01:27:18PM -0600, Michel Lind wrote: > except for python-asyncmy: > https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/build/7026743/ > Looks like this is a known issue fixed in 0.2.7: https://github.com/long2ice/asyncmy/blob/dev/CHANGELOG.md and there are no breaking changes up to 0.2.9 that is in our F39 branch, which rebuilds fine as is. So the current plan is to build python-poetry-core 1.6.1-1 and python-asyncmy 0.2.9-1 in a sidetag on Monday and then put up an update. cc-ing python-asyncmy maintainer here I'll post here when the update goes out, and if there's any concern between now and Monday, let me know and I can delay that until that is addressed. Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] RFC: updating python-poetry-core in EPEL 9 to 1.6.1
Dear all, Per https://bugzilla.redhat.com/show_bug.cgi?id=2262237 I'm planning to update python-poetry-core to 1.6.1; based on the changelog there should be no breaking change. The request is to update to at least 1.2 which is needed by python-dns-lexicon which is blocking certbot from being updated. https://github.com/python-poetry/poetry-core/blob/main/CHANGELOG.md I have a COPR that rebuilds every dependent packages - found using `fedrq whatrequires python3-poetry-core -b epel9 -F source --src | tee dependents.txt` So far everything (taken from epel9 branch) builds fine: https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/builds/ except for python-asyncmy: https://copr.fedorainfracloud.org/coprs/salimma/poetry-core-epel9-wip/build/7026743/ I'll try to repro rebuilding against the current poetry-core and the proposed update, to see if it's related to this or not. If the asyncmy failure is related, I'll try and fix it (or try a lower version of poetry-core that let it be compiled) before doing official builds. Will probably let this sit until Monday to give people chance to comment. Best regards, -- Michel Lind identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)
As a pandoc user, I'm happy to help with any reviews. Is there a list where this tends to get posted, apart from devel? Thanks, Michel On Fri, Feb 09, 2024 at 11:26:33PM +0800, Jens-Ulrik Petersen wrote: > I should also have added there's an increasing amount of technical debt > with the pandoc packaging - I guess I need to beg people to help with > package reviews: also reminded of our packaging (review) streamlining > discussion from Flock last year. > > Jens > > On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen, wrote: > > > Hello I am here - thanks for contacting me. > > > > I was hoping to cover this as part of my F40 Change, but unfortunately I > > haven't gotten to it, so the Change is now at risk of being deferred to F41. > > > > Nevertheless I will see what I can do about this for F40: maybe a backport > > can also be done for F39. > > > > Next time you could also comment on the relevant bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1996301 - that would be > > appreciated. > > > > Thanks, Jens > > > > PS Special thanks to Neal Gompa for pinging me in Matrix. > > > > > > On Fri, 9 Feb 2024, 20:05 Christopher Klooz, wrote: > > > >> I cannot reach the maintainer petersen (see mail below): The package > >> "pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1. > >> Among the updates since 3.1.3, there have been two security-critical > >> (including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6). > >> > >> The actual risk is limited, but these should be updated nevertheless. > >> > >> Does anyone know how to reach him by other means? > >> > >> Regards, > >> Chris > >> > >> > >> Forwarded Message > >> Subject: Fedora package "pandoc" outdated and contains security > >> vulnerability > >> Date: Thu, 1 Feb 2024 15:55:09 +0100 > >> From: py0...@posteo.net > >> To: peter...@fedoraproject.org > >> > >> Hi petersen, > >> > >> I am reaching out because of the package "pandoc", which you maintain. > >> > >> I have seen that the package is still at version 3.1.3 [1] when I tried > >> to install it with dnf, whereas the current version is 3.1.11.1 [2]: is > >> this intended or an accident? > >> > >> It has to be noted that the updates that have been added in the meantime > >> contain fixes for security vulnerabilities (at least CVE-2023-35936; I have > >> just roughly skimmed the changelogs). So at the moment, it seems the Fedora > >> build can be exploited by attackers in some circumstances [3] [4] because > >> it is still at 3.1.3. > >> > >> Regards & thanks for maintaining, > >> > >> Chris > >> > >> [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560 > >> > >> [2] https://hackage.haskell.org/package/pandoc & > >> https://github.com/jgm/pandoc > >> > >> [3] https://github.com/jgm/pandoc/releases?page=1 > >> > >> [4] https://github.com/jgm/pandoc/releases?page=2 > >> > >> -- > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > >> Do not reply to spam, report it: > >> https://pagure.io/fedora-infrastructure/new_issue > >> > > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Fri, Feb 02, 2024 at 12:58:27AM +0100, Kevin Kofler via devel wrote: > Daniel P. Berrangé wrote: > > The approved KDE change > > https://fedoraproject.org/wiki/Changes/KDE_Plasma_6 indicates the intent > > for existing Plasma X11 installs to switch to Wayland during the upgrade > > process. > > > > There's no perfect answer as some users will be happy to switch to > > Wayland, while others will not, while perhaps more will not even be aware > > of anything changing. > > > > IMHO if the KDE Sig wants the upgrade path to take users from X11 to > > Wayland automatically, then the criteria for allowing back in RPMs > > with X11 builds should include "no interference with the X11->Wayland > > upgrade path determined by the KDE Sig". > > > > The BZ ticket indicates that there was some testing to show that is not > > causing a problem with the upgrades, so it might be a non-issue, but > > setting clear expectations in this respect would be a good idea anyway. > > As I wrote (and confirmed by testing) in the BZ ticket, the packages as > submitted already do not interfere with the X11->Wayland upgrade path > determined by the KDE Sig, and I do not intend changing that. (Adding > versioned self-Obsoletes could possibly theoretically achieve that, but that > is a game I do not intend to play. The only thing I care about, which is why > I bumped that Epoch, is that the upgrade Obsoletes is applied only ONCE on > the upgrade to Fedora 40 and not on routine updates in Fedora 40 or on > upgrades from Fedora 40 to later releases, because anybody who still/again > has the -x11 packages on Fedora 40 has explicitly opted in and should not > have to opt in repeatedly.) > > While (as also stated in the BZ ticket) I disagree that it is helpful to > forcefully remove the -x11 packages on the upgrade to F40, my packages do > not and will not interfere with that process. > There seems to be a way for both sides to get what they want here (note: I am neither, but I hope this might be helpful) - KDE SIG wants to obsolete X11 packages on upgrade just once - Apart from the impact of that, this is actually standard packaging practice when subpackages are no longer offered otherwise the upgrade will break - If the obsolete indicates the NEVRA of the -x11 subpackage being obsoleted, instead of floating to the current NEVRA, you can actually re-provide the missing package without having to bump epoch - KDE SIG likely also want people to test Wayland, so defaulting to the X11 packages being removed makes sense here - *However* there are quite likely cases where Wayland does not work (yet) or could not work (without hardware replacement) for some users' use cases. These should not be given short shrift - So a workaround for such cases needs to be available - There is also concern that any issue will land on the KDE SIG's laps This might address all concerns: - Can we make the x11 packages be named explicitly as compat packages (e.g. prefixed with compat-) - Marking them as deprecated is also reasonable. This is standard practice for compat packages - KDE SIG, as part of the Change Proposal, should also document how to install these compat packages so affected users can install them - After a sufficient grace period where people get their -x11 packages removed by default on upgrade, the compat-*-x11 packages should be allowed to Provide: the old non-compat name so people who upgrade later keep their X11 experience intact - This grace period should be part of the release announcement Does this seem workable? Any feedback appreciated - I try to keep up with this thread but I might have missed some points. Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help packaging go with its dependencies
On Fri, Feb 02, 2024 at 06:02:13PM -0300, Priscila Gutierres wrote: > I'm trying to package kubectl for Fedora, but I'm having a bad time with > some dependencies. > I created the specfile using go2rpm, and I'm using auto dependencies: > https://pastebin.com/fmvttDBt > > %generate_buildrequires > %go_generate_buildrequires > > But it is blaming that some dependencies are missing: > > Failed to resolve the transaction: > Package "go-rpm-macros-3.3.1-3.fc40.x86_64" is already installed. > No match for argument: golang(github.com/chai2010/gettext-go/gettext) > No match for argument: golang(github.com/russross/blackfriday) > No match for argument: golang(k8s.io/kubectl/pkg/generated) > > I could find, for example, golang-github-chai2010-gettext: > https://src.fedoraproject.org/rpms/golang-github-chai2010-gettext > But it isn't found when trying to create a mock package. > Looks like that package provides golang(github.com/chai2010/gettext-go), as well as gettext-go/mo, /plural, and /po, but not gettext-go/gettext ❯ fedrq pkgs golang-github-chai2010-gettext-devel -F provides golang(github.com/chai2010/gettext-go) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/mo) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/plural) = 1.0.2-12.fc40 golang(github.com/chai2010/gettext-go/po) = 1.0.2-12.fc40 golang-github-chai2010-gettext-devel = 1.0.2-12.fc40 golang-ipath(github.com/chai2010/gettext-go) = 1.0.2-12.fc40 Curious, given upstream's go.mod lists github.com/chai2010/gettext-go without the additional /gettext: https://github.com/kubernetes/kubectl/blob/b73518af09755bb9607e8755e7fc111ee1adceb5/go.mod#L9 Seems like either %go_generate_buildrequires is doing the wrong thing, or the golang-github-chai2010-gettext package is not exporting the right virtual provide. Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-represent
On Wed, Jan 24, 2024 at 05:48:58PM +0100, Lumír Balhar wrote: > Hello. > > I'm going to orphan python-represent. I updated it to the latest version so > if you take it, there is nothing to be done now. It's a leaf package and I > don't have any use for it. > I've taken it, thanks! -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned python-mccabe (dependency of pylint)
On Thu, Feb 01, 2024 at 01:03:55AM +0100, Miro Hrončok wrote: > On 01. 02. 24 0:51, Michel Lind wrote: > > I see limb already took the package (thanks limb) - note that the > > default bugzilla assignee still seems to be 'orphan', I'm assuming that > > will fix itself eventually > > Not by itself, the package has a epel bugzilla contact override, so when the > main admin changes, the fedora bugzilla contact needs to be changed as well. > I've just done that. > Thank you! python-hypothesmith now fixed, and confirmed working by rebuilding python-libcst with tests enabled (which requires hypothesmith). The non-bootstrap python-libcst 1.1.0 is building in Koji now. Best, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned python-mccabe (dependency of pylint)
On Tue, Jan 30, 2024 at 02:59:04PM +0100, Miro Hrončok wrote: > Hello. > > I have orphaned python-mccabe. > > It does not build with updated hypothesis, because the update broke > hypothesmith and I don't have time to look into it: > > https://bugzilla.redhat.com/2261579 > > mccabe is a dependency of pylint. > Apologies for the hypothesmith breakage - it's not meant to last that long but turns out updating hypothesmith requires bumping libcst first and it now has a Rust component. libcst is built, hypothesmith seems to build fine locally but the test suite (using hypothesis) is ... not fast. I'll try and submit it ASAP. I see limb already took the package (thanks limb) - note that the default bugzilla assignee still seems to be 'orphan', I'm assuming that will fix itself eventually -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned python-mccabe (dependency of pylint)
On Tue, Jan 30, 2024 at 02:59:04PM +0100, Miro Hrončok wrote: > Hello. > > I have orphaned python-mccabe. > > It does not build with updated hypothesis, because the update broke > hypothesmith and I don't have time to look into it: > > https://bugzilla.redhat.com/2261579 > > mccabe is a dependency of pylint. > Apologies for the hypothesmith breakage - it's not meant to last that long but turns out updating hypothesmith requires bumping libcst first and it now has a Rust component. libcst is built, hypothesmith seems to build fine locally but the test suite (using hypothesis) is ... not fast. I'll try and submit it ASAP. I see limb already took the package (thanks limb) - note that the default bugzilla assignee still seems to be 'orphan', I'm assuming that will fix itself eventually -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cached Package Review Tracker - Tickets that passed automated review
Hi Jakub, On Tue, Jan 23, 2024 at 09:33:37PM +0100, Jakub Kadlcik wrote: > Hello, > if you use the Cached Package Review Tracker > https://fedoraproject.org/PackageReviewStatus/ > there is a new "feature" that you may find useful. > > Fedora Review Service runs the fedora-review tool on every new Bugzilla > ticket. If no errors are found, the ticket is marked with a special > keyword. Such tickets are then displayed in the "New tickets that passed CI > checks" section of the cached tracker. > https://fedoraproject.org/PackageReviewStatus/triaged.html > > They are also highlighted in the "New Fedora tickets" section > https://fedoraproject.org/PackageReviewStatus/reviewable.html > (see the color legend) > > The presumption is - if a ticket passes all fedora-review checks, it is > probably in relatively good shape and the package review could be quick and > simple. > Amazing, thank you! -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 24, 2024 at 10:35:09AM -0700, Jerry James wrote: > On Wed, Jan 24, 2024 at 9:39 AM Miro Hrončok wrote: > > Based on the current fail to build from source policy, the following > > packages > > should be retired from Fedora 40 approximately one week before branching. > [snip] > > cl-asdf green > > I fixed cl-asdf in Rawhide. Mind building it in F39 and F38 too? It fails to build there and there is one bug open for each Thanks, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 24, 2024 at 05:53:52PM +0100, Miro Hrončok wrote: > On 24. 01. 24 17:50, Michel Lind wrote: > > On Wed, Jan 24, 2024 at 05:38:59PM +0100, Miro Hrončok wrote: > > > Dear maintainers. > > > > > > Based on the current fail to build from source policy, the following > > > packages > > > should be retired from Fedora 40 approximately one week before branching. > > > > > [snip] > > > golang-github-eclesh-welford abulimov, dcavalca, go-sig > > I fixed this one last week - curious how it ended up on the > > list? > > No successful Rawhide build. > Aha, thanks. golang-github-google-gopacket is now built on Rawhide and stable releases. Checking welford now. -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Wed, Jan 24, 2024 at 05:38:59PM +0100, Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 40 approximately one week before branching. > [snip] > golang-github-eclesh-welford abulimov, dcavalca, go-sig I fixed this one last week - curious how it ended up on the list? https://bodhi.fedoraproject.org/updates/?packages=golang-github-eclesh-welford https://bugz.fedoraproject.org/golang-github-eclesh-welford shows no bug open (though I noticed it just failed in the mass rebuild) Best, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes/RemovePythonMockUsage affected packages
On Fri, Jan 12, 2024 at 08:21:12PM +, Maxwell G wrote: > Hi everyone, > > https://fedoraproject.org/wiki/Changes/RemovePythonMockUsage has been > approved, so Michel and I will be working on identifying packages that > still depend on python3-mock. python3-mock has been deprecated for 6 > releases in favor of unittest.mock from the Python standard library, and > we would like to finally retire the package. We will help with PRs, but > we would also appreciate help from packagers to fix their own packages. > https://fedoraproject.org/wiki/Changes/DeprecatePythonMock#How_to_migrate_to_unittest.mock > provides guidance on how to accomplish that. Please reach out to us or > pop into https://matrix.to/#/#python:fedoraproject.org if you have any > questions. > > Here is a list of packages that currently depend on python3-mock at > runtime and/or buildtime: > 60 of these packages build fine with a stub python-mock, so the dependency can just be removed from those: https://pagure.io/michel-slm/python-mock-drawdown/blob/main/f/false-positives.txt (Will generate the per-maintainer list later - and send out PRs to the affected packages) Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changes/RemovePythonMockUsage affected packages
On Fri, Jan 12, 2024 at 08:21:12PM +, Maxwell G wrote: > Hi everyone, > > https://fedoraproject.org/wiki/Changes/RemovePythonMockUsage has been > approved, so Michel and I will be working on identifying packages that > still depend on python3-mock. python3-mock has been deprecated for 6 > releases in favor of unittest.mock from the Python standard library, and > we would like to finally retire the package. We will help with PRs, but > we would also appreciate help from packagers to fix their own packages. > https://fedoraproject.org/wiki/Changes/DeprecatePythonMock#How_to_migrate_to_unittest.mock > provides guidance on how to accomplish that. Please reach out to us or > pop into https://matrix.to/#/#python:fedoraproject.org if you have any > questions. > > Here is a list of packages that currently depend on python3-mock at > runtime and/or buildtime: > 60 of these packages build fine with a stub python-mock, so the dependency can just be removed from those: https://pagure.io/michel-slm/python-mock-drawdown/blob/main/f/false-positives.txt (Will generate the per-maintainer list later - and send out PRs to the affected packages) Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Orphaning python-mistune on EPEL
Hi Miro, On Wed, Jan 10, 2024 at 02:51:33PM +0100, Miro Hrončok wrote: > Hello, > > I recently took python-mistune in Fedora. > I am not interested in maintaining it in EPEL. > > It is branched for epel7, epel8 and epel9. > > @epel-packagers-sig is a collaborator so I assume somebody built this in > epel9 without taking responsibility. > > There is a low impact CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2112231 > > If somebody want to maintain it, let me know and I'll make you the epel > point of contact. > Please mark me as the EPEL POC. Thanks, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Mailman3 web components for EPEL 9 now in Bodhi!
On Thu, Dec 21, 2023 at 02:13:26PM -0600, Michel Lind wrote: > Dear all, > > I'm happy to be able to provide this holiday present to the infra team > (and other interested parties) - after chasing through tens of > dependencies, going through multiple stalled EPEL requests, and evolving > ebranch to automate some of these pain points, the `mailman3` web > components are now built for EPEL 9 and available to test! > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4c6b819c9c > Thanks in particular to Neal Gompa and Kevin Fenzi for all the assistance and coordination in getting blockers dealt with. -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Mailman3 web components for EPEL 9 now in Bodhi!
Dear all, I'm happy to be able to provide this holiday present to the infra team (and other interested parties) - after chasing through tens of dependencies, going through multiple stalled EPEL requests, and evolving ebranch to automate some of these pain points, the `mailman3` web components are now built for EPEL 9 and available to test! https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4c6b819c9c This is a follow-up to `mailman3` itself that entered EPEL 9 two months ago: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f022c8f3ad There are probably some missing plugins etc. that have not been branched and built for EPEL 9 yet, let me know if you have a list and I'm happy to get to them next. Happy holidays, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: packaging of nix
I'd love to comaintain. I'm interested in Nix and Guix, but the latter really needs us to revamp our Guile packaging guidelines to package properly. Best, -- Michel Lind -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is package (gnome-shell extension) split into legacy and current required?
Hi, On Mon, Oct 16, 2023 at 12:02:05PM +0200, Alexander Ploumistos wrote: > Hello, > > I maintain the gnome-shell extension for bubblemail. I was informed by > the upstream developer that in order to support GNOME ≥ 45, he is > rewriting most of the code. What is currently the master branch will > support (recent) GNOME versions up to 44.x and there will be another > branch for 45 and newer. > Do I need to create something like a compat package or can I just > switch to the new source/branch from F39 onward? I suppose that a > bugfix for F37 and F38 down the road is not out of the question, so > there will be two different upstream branches for different Fedora > versions. > I maintain Argos, where there's also a PR I'm shipping in Fedora >= 39 because it drops support for older GNOME releases. Since Fedora only introduces major GNOME versions in new releases, I think it's safe to use the same dist-git repo and just let the spec diverges. Assuming the fixes in the branch that supports legacy GNOME are few and far between, you can probably do something similar to this: https://src.fedoraproject.org/rpms/gnome-shell-extension-argos/c/fed457b5b1a9c70395025e92e85d801d80bae206?branch=rawhide (in this case, some patches are conditionally applied only to releases with GNOME >= 45, but you can also do it the other way around) HTH, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Anyone interested in packaging + maintaining the nimble language?
Hi Ankur, On Sun, Sep 10, 2023 at 10:04:18PM +0100, Ankur Sinha wrote: > Hi folks, > > I have a package that has begun to use the nimble language in its new > version: > https://bugzilla.redhat.com/show_bug.cgi?id=2181693 > https://nim-lang.org/ > > It isn't packaged for Fedora yet, though. Is anyone using it, and would > like to package + maintain it for Fedora? > This looks like an interesting language, so #whynot (famous last words). Would you be interested in co-maintaining? Going to try and beat this into shape for packaging, I've already discovered that the official tarball is missing files needed for rebuilding from source :( https://github.com/nim-lang/Nim/issues/22692 Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Access superseded Fedora RPMs
Hi Kai, On Fri, Sep 08, 2023 at 09:58:58PM +0200, Kai A. Hiller wrote: > Hello, > > I’m trying to recreate – on the level of RPMs – a Fedora system as resolved > by DNF at an earlier moment in time (think lockfile). Collecting a list of > the installed RPMs and their versions for a given system is easily done via > `dnf list installed`; though, afaict these RPMs in their exact versions may > no longer be available at Fedora mirrors at a later point in time. This > leads to my question: Is there a Fedora-canonical way of finding and > attaining these superseded RPMs? > > (Alternatively, I was thinking about hosting a private, modified mirror that > serves all versions of an RPM. Does that sound like a good idea?) > Try installing fedora-repos-archive -- you'll get a repo definition for fedora-updates-archive, which has all versions of released updates rather than just the latest. IIRC it was added on the request of CoreOS. Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
