Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Jan, On Fri Apr 26, 2024 at 08:46 +0200, Jan Kolarik wrote: > Hi Maxwell, > > This contains an update to dnf 5.2.0 which has breaking API changes. I did > > not > > see these communicated anywhere and the Change Proposal did not mention > > that > > the update would include a major version bump at the same time as the > > switch to > > dnf5 as default. > > > > You're right; we missed this. I'm sorry about that. Our initial intention > wasn't to do a major version bump, but implementing the new functionality > without breaking ABI and API would have required a lot of extra work. That makes sense. I'm sorry if I was a bit harsh here. > Would it be possible to provide a testing Copr ... > > > > Sure, as mentioned earlier, there's a dnf5-testing COPR specifically for > these purposes: > https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-testing. It looks like the packages in that Copr Obsolete dnf4, while I want to keep using dnf4 on my f39 machine. I built my own dnf5 package without the dnf5_obsoletes_dnf bcond locally, but it'd be nice to have pre-built RPMs for that. > ... and a porting guide so API users can fix their software > > before this is pushed to rawhide? > > > > We'll add a section about the API changes between dnf5 versions 5.1 and > 5.2, and we'll reach out to the several teams affected by this. That would be great! It looks like work on this has started in https://github.com/rpm-software-management/dnf5/pull/1456. Thank you. > We'll also ensure that the builds for our reverse dependencies are > passing with this update. We definitely don't want to push this before > these projects are fixed. > Still, I hope no harm has been done yet. That's actually the purpose of > this side-tag, to identify any gaps we may have missed while working on the > switch. The 5.2.0.0 API changes aren't significant, there are though many > ABI-breaking changes. Yeah, as long as we make sure everything is ported before the side tag is merged, we should be good to go. I saw some patches for dnf 5.2.0 compatibility in ansible upstream, so we may just need to backport those. As for fedrq, I have a WIP patch to add compatibility for dnf 5.2.0. The only thing I have not been able to figure out is [1]. I assume stable Fedoras will keep dnf 5.1.0, so the plan is to maintain compatibility with those for now so users can still opt in to the libdnf5 backend. [1] https://github.com/rpm-software-management/dnf5/issues/1450. Thanks, Maxwell -- ___ 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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
Hi Jan, On Thu Apr 25, 2024 at 07:42 +0200, Jan Kolarik wrote: > We've prepared a side-tag for testing Rawhide with dnf5 as the default > package manager. Instructions for installing the packages from the side-tag > can be found at the following link [1]. > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2 Thank you for the announcement. I appreciate the oppurtunity to test the update before it's pushed to rawhide. This contains an update to dnf 5.2.0 which has breaking API changes. I did not see these communicated anywhere and the Change Proposal did not mention that the update would include a major version bump at the same time as the switch to dnf5 as default. This update completely breaks fedrq due to the removed methods. ansible, lorax, and osbuild also depend on libdnf5. Have these applications had a chance to port to the new API? Would it be possible to provide a testing Copr and a porting guide so API users can fix their software before this is pushed to rawhide? Best, Maxwell -- ___ 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: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On Fri Apr 19, 2024 at 14:23 +1000, Nathan Scott wrote: > Hi Neal, > > On Thu, Apr 18, 2024 at 1:02 PM Neal Gompa wrote: > > On Wed, Apr 17, 2024 at 10:43 PM Nathan Scott wrote: > > > On Thu, Apr 18, 2024 at 12:29 PM Neal Gompa wrote: > > > > [...] > > > > retaining Redis will just hurt us in the long term. > > > > > > Noone is saying we should retain Redis. I'm advocating for a more > > > appropriate transition that is respectful of the work and expertise the > > > existing package maintainers bring. > > > > > > I think f41 is appropriate and possible, but "more haste, less speed" > > > is the way to get there, with minimal breakage to Fedora and users. > > > > > > > From my perspective, I don't see any breakage happening. We also > > haven't *done* anything yet. > > > > Sooo, about that... :) I see there is a valkey build winging its way > toward f39 and f38 now: > https://bodhi.fedoraproject.org/updates/?packages=valkey > > If someone has an active redis installation on those systems and > install that - aren't they in for a bit of a surprise? Correct me if I'm > wrong, but this will replace redis - leaving /var/lib/redis with their > current data, and start a new "redis-server" (aka "valkey-server") > process writing into a new, empty rdb file below /var/lib/valkey, no? > If so, how do they reconcile those split rdb files? > > Let's slow down a bit, it's not so urgent that we risk peoples data. The package does not have any Obsoletes, so nothing should happen unless users take explicit action to install valkey. -- ___ 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: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On Thu Apr 18, 2024 at 11:51 +1000, Nathan Scott wrote: > > > == Owner == > > > * Name: [[User:jonathanspw|Jonathan Wright]] > > > * Email: jonat...@almalinux.org > > > > It would be nice to have Remi who currently maintains redis on board as > > well. > > > > This is the second time this has been requested, but not yet actioned. > > https://bugzilla.redhat.com/show_bug.cgi?id=2274206 > https://src.fedoraproject.org/rpms/valkey > https://src.fedoraproject.org/rpms/redis > > Can we resolve this before allowing this Change Proposal to proceed, > please? I think its in Fedora's interest to see 'new redis' maintained > by group, rather than an individual, if the existing maintainers wish to > (continue to) be involved. > > The 'new' valkey package is very closely derived from redis packaging > which other Fedora maintainers have been looking after for ~14 years. Yeah, I strongly agree. Thank you, Nathan and Remi, for the work you've done to maintain redis up until now. -- ___ 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: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On 4/18/24 00:51, Remi Collet wrote:
Le 17/04/2024 à 18:37, Maxwell G a écrit :
On Wed Apr 17, 2024 at 16:38 +0100, Aoife Moloney wrote:
Thank you for submitting this!
I agree we’ll have to get rid of redis in the future, and than such a
switch will make a strong statement about our disapproval to redis
about this License change.
But I also think this is a bit early (F41)
- Valkey is very young, and they is no proof it will be best choice
- Redis 7.2 is still there and maintained (even version 6.2 and 7.0
are maintained), and keeping it have no security issue.
So I’m -1 for F41 and probably +1 for F42
One option is to introduce {valkey,redict}-redis-compat packages now
(users could "dnf swap redis " themselves) and then
consider making one "the default" and Obsoleting redis in F42.
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On 4/17/24 02:20, Zbigniew Jędrzejewski-Szmek wrote: I don't think we should make this particular functionality special. Yeah, I tend to agree. If we want to reimagine the way BRP scripts work, that should be a separate discussion. -- ___ 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: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On 4/13/24 06:41, Fabio Valentini wrote: On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek wrote: Yes. But actually I think Rust is the optimal choice here. Writing this in Python would be possibly slightly nicer, but we don't want to pull the interpreter and packages into the buildroot. Python also has the problem (challenge?) that it needs to be bootstrapped once per year. The less packages are involved in the bootstrap, the easier it is. And if the brp was written in Python, we'd need to deal with that, and it would probably increase the number of builds which are done without the cleanup. Having this as an indepedent binary avoids some of the issues with bootstrap. I think Rust*would* be a good choice here ... BUT add-determinism uses pyo3 to link to CPython, so it pulls in python3-libs anyway. So you get the downsides of pulling in Python without the upsides of using Rust ... Would it be possible to shell out to Python instead of using pyo3? I assume add-determinism's Python handler is not that complicated given that marshalparser does most of the work. -- ___ 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: F41 Change Proposal: Replace Redis with Valkey (system-wide)
On Wed Apr 17, 2024 at 16:38 +0100, Aoife Moloney wrote: Thank you for submitting this! > == Owner == > * Name: [[User:jonathanspw|Jonathan Wright]] > * Email: jonat...@almalinux.org It would be nice to have Remi who currently maintains redis on board as well. > == Detailed Description == > We will replace Redis with Valkey due to the recent licensing changes > in Redis, which have rendered it incompatible with Free and Open > Source Software (FOSS) principles. This shift in Redis's licensing can > impact Fedora's commitment to FOSS, potentially limiting users' > freedom to modify and redistribute the software under the same terms. > Valkey, a fork of Redis, emerges as a viable alternative because it > retains a FOSS-compatible license and has robust community and > developmental support. Adopting Valkey allows us to continue offering > users a powerful in-memory data structure store without compromising > on licensing restrictions. I assume you've also considered https://codeberg.org/redict/redict as an alternative? Redict seems more open to helping distributions. Redict already plans to remove its in-tree, patched lua copy to benefit distributions like ours that favor system libraries. It has committed to using FOSS infrastructure (Codeberg, builds.sr.ht, Matrix, IRC, FOSS container registry) instead of proprietary infrastructure (Github, Discord) which is something that Fedora also values. It was started by Drew Devault of Sourcehut who has a strong commitment to FOSS. On the other hand, some of the original contributors and the Linux Foundation have gotten behind Valkey. I would at least address Redict in passing in the Change proposal even if you've already decided that Valkey is the better choice. -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-04-12 13:04:40 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change container-workflow-tool orphan 2 weeks ago emacs-htmlize orphan 3 weeks ago jolokia-jvm-agent orphan 0 weeks ago kio-upnp-ms jgrulich, orphan 5 weeks ago libteam orphan 0 weeks ago loudgainorphan 4 weeks ago mingw-freeimage orphan 0 weeks ago mrxvt orphan 4 weeks ago nextcloud ichavero, orphan 2 weeks ago perl-WWW-Google-Contactsorphan 5 weeks ago php-aws-sdk3orphan 2 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 2 weeks ago php-christophwurst-id3parserorphan 2 weeks ago php-deepdiver-zipstreamer orphan 2 weeks ago php-doctrine-dbal orphan, remi 2 weeks ago php-fgrosse-phpasn1 orphan 2 weeks ago php-giggsey-locale orphan 2 weeks ago php-guzzlehttp-guzzle6 orphan 2 weeks ago php-league-uri-interfaces orphan 2 weeks ago php-opencloud-openstack orphan 2 weeks ago php-opis-closureorphan, remi 2 weeks ago php-pimple orphan 2 weeks ago php-punic orphan 2 weeks ago php-ralouphie-getallheaders orphan 2 weeks ago php-scssphp orphan 2 weeks ago php-stecman-symfony-console-orphan 2 weeks ago completion prometheus-jmx-exporter orphan 0 weeks ago prometheus-simpleclient-javaorphan 0 weeks ago python-aiomqtt orphan 5 weeks ago python-autoprop orphan 5 weeks ago python-colorcet orphan 5 weeks ago python-jose orphan 1 weeks ago python-limits orphan 4 weeks ago python-paramorphan 5 weeks ago python-pyct orphan 5 weeks ago python-signature-dispatch orphan 5 weeks ago python-vecrec orphan 5 weeks ago snakeyaml mizdebsk, orphan, sbluhm 0 weeks ago vim-editorconfigorphan 1 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,
Orphaned packages looking for new maintainers
Report started at 2024-04-12 13:04:40 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change container-workflow-tool orphan 2 weeks ago emacs-htmlize orphan 3 weeks ago jolokia-jvm-agent orphan 0 weeks ago kio-upnp-ms jgrulich, orphan 5 weeks ago libteam orphan 0 weeks ago loudgainorphan 4 weeks ago mingw-freeimage orphan 0 weeks ago mrxvt orphan 4 weeks ago nextcloud ichavero, orphan 2 weeks ago perl-WWW-Google-Contactsorphan 5 weeks ago php-aws-sdk3orphan 2 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 2 weeks ago php-christophwurst-id3parserorphan 2 weeks ago php-deepdiver-zipstreamer orphan 2 weeks ago php-doctrine-dbal orphan, remi 2 weeks ago php-fgrosse-phpasn1 orphan 2 weeks ago php-giggsey-locale orphan 2 weeks ago php-guzzlehttp-guzzle6 orphan 2 weeks ago php-league-uri-interfaces orphan 2 weeks ago php-opencloud-openstack orphan 2 weeks ago php-opis-closureorphan, remi 2 weeks ago php-pimple orphan 2 weeks ago php-punic orphan 2 weeks ago php-ralouphie-getallheaders orphan 2 weeks ago php-scssphp orphan 2 weeks ago php-stecman-symfony-console-orphan 2 weeks ago completion prometheus-jmx-exporter orphan 0 weeks ago prometheus-simpleclient-javaorphan 0 weeks ago python-aiomqtt orphan 5 weeks ago python-autoprop orphan 5 weeks ago python-colorcet orphan 5 weeks ago python-jose orphan 1 weeks ago python-limits orphan 4 weeks ago python-paramorphan 5 weeks ago python-pyct orphan 5 weeks ago python-signature-dispatch orphan 5 weeks ago python-vecrec orphan 5 weeks ago snakeyaml mizdebsk, orphan, sbluhm 0 weeks ago vim-editorconfigorphan 1 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,
Re: convert everything to rpmautospec?
On Sun Apr 7, 2024 at 15:15 +, Zbigniew Jędrzejewski-Szmek wrote: > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g. when they want to push some fix or separately from other >work) > - people submitting pull requests against src.fp.o MAY also > include a conversion in the pull request and packagers SHOULD > merge it. I happily use rpmautospec for the Go and Rust libraries I maintain that are simple, mostly autogenerated packages, but I otherwise prefer using manual changelogs. They allow me more control over the changelog and maintain the separation between the developer commit log and the user- facing changelog that I keep for the rest of my projects. I understand the merits of rpmautospec, but I would very much not like to be forced to use it for all my packages. -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-04-02 16:05:20 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change botan orphan 1 weeks ago container-workflow-tool orphan 1 weeks ago emacs-htmlize orphan 1 weeks ago kio-upnp-ms jgrulich, orphan 3 weeks ago ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago liquidshell orphan 5 weeks ago loudgain orphan 3 weeks ago mrxvt orphan 3 weeks ago nextcloud ichavero, orphan 1 weeks ago perl-Git-PurePerl iarnell, orphan 6 weeks ago perl-Net-GitHub jplesnik, lkundrak, orphan, 6 weeks ago ppisar perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 6 weeks ago Simple perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 6 weeks ago Simple perl-String-Diff iarnell, orphan 6 weeks ago perl-WWW-Google-Contacts orphan 3 weeks ago php-aws-sdk3 orphan 1 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago php-christophwurst-id3parser orphan 1 weeks ago php-deepdiver-zipstreamer orphan 1 weeks ago php-doctrine-dbal orphan, remi 1 weeks ago php-fgrosse-phpasn1 orphan 1 weeks ago php-giggsey-localeorphan 1 weeks ago php-guzzlehttp-guzzle6orphan 1 weeks ago php-league-uri-interfaces orphan 1 weeks ago php-opencloud-openstack orphan 1 weeks ago php-opis-closure orphan, remi 1 weeks ago php-phpSmug orphan 5 weeks ago php-pimpleorphan 1 weeks ago php-punic orphan 1 weeks ago php-ralouphie-getallheaders orphan 1 weeks ago php-scssphp orphan 1 weeks ago php-stecman-symfony-console- orphan 1 weeks ago completion python-aiomqttorphan 4 weeks ago python-autoprop orphan 4 weeks ago python-colorcet orphan 4 weeks ago python-extractcode@python-packagers-sig, orphan3 weeks ago python-jose orphan 0 weeks ago python-limits orphan 3 weeks ago python-param orphan 4 weeks ago python-pyct orphan 4 weeks ago python-signature-dispatch orphan 4 weeks ago python-vecrec orphan 4 weeks ago telepathy-logger-qt @kde-sig, jgrulich, orphan 3
Re: Golang bundled() Provides generator
On Tue Apr 2, 2024 at 17:16 +0200, Dan Čermák wrote: > Hi Maxwell & Go SIG, Hi Dan, Thank you for reaching out! > we have recently started working on introducing a bundled() provides > generator for golang in openSUSE and found a very simple solution using > the output of `go version -m /path/to/binary` [1] It seems that only works when builds are performed with GO111MODULE turned on[1]. We have it turned off by default, although I suppose we can turn it on when doing vendored builds—we only need to turn it off when using the RPM-packaged dependencies for un-vendored packages. Without GO111MODULE, the dep information doesn't show up with "go version -m." [1] https://go.dev/blog/go116-module-changes > The solution is of course only that simple, because we build more or > less all go binaries with vendored dependencies and hence we do not need > to distinguish between those build with vendored and those build > without. > > As I would like to align the Fedora and openSUSE go packaging closer > together and hence, if possible, find a solution to use this generator > for both Fedora and openSUSE. I think it is a bit simpler and does not > require to ship the modules.txt in the final rpm. However, I see that > both are rather weak reasons. > > Do you see a way how we can find a common solution? E.g. by having a > macro %go_enable_bundled_provides that would set an environment variable > and enable the bundled generator? Other than the technical issue with GO111MODULE, I still prefer modules.txt approach. It is more efficient, as we don't need to process every single binary file in the package, and it requires explicit opt-in from the packager. Best, Maxwell -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-04-02 16:05:20 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change botan orphan 1 weeks ago container-workflow-tool orphan 1 weeks ago emacs-htmlize orphan 1 weeks ago kio-upnp-ms jgrulich, orphan 3 weeks ago ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago liquidshell orphan 5 weeks ago loudgain orphan 3 weeks ago mrxvt orphan 3 weeks ago nextcloud ichavero, orphan 1 weeks ago perl-Git-PurePerl iarnell, orphan 6 weeks ago perl-Net-GitHub jplesnik, lkundrak, orphan, 6 weeks ago ppisar perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 6 weeks ago Simple perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 6 weeks ago Simple perl-String-Diff iarnell, orphan 6 weeks ago perl-WWW-Google-Contacts orphan 3 weeks ago php-aws-sdk3 orphan 1 weeks ago php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago php-christophwurst-id3parser orphan 1 weeks ago php-deepdiver-zipstreamer orphan 1 weeks ago php-doctrine-dbal orphan, remi 1 weeks ago php-fgrosse-phpasn1 orphan 1 weeks ago php-giggsey-localeorphan 1 weeks ago php-guzzlehttp-guzzle6orphan 1 weeks ago php-league-uri-interfaces orphan 1 weeks ago php-opencloud-openstack orphan 1 weeks ago php-opis-closure orphan, remi 1 weeks ago php-phpSmug orphan 5 weeks ago php-pimpleorphan 1 weeks ago php-punic orphan 1 weeks ago php-ralouphie-getallheaders orphan 1 weeks ago php-scssphp orphan 1 weeks ago php-stecman-symfony-console- orphan 1 weeks ago completion python-aiomqttorphan 4 weeks ago python-autoprop orphan 4 weeks ago python-colorcet orphan 4 weeks ago python-extractcode@python-packagers-sig, orphan3 weeks ago python-jose orphan 0 weeks ago python-limits orphan 3 weeks ago python-param orphan 4 weeks ago python-pyct orphan 4 weeks ago python-signature-dispatch orphan 4 weeks ago python-vecrec orphan 4 weeks ago telepathy-logger-qt @kde-sig, jgrulich, orphan 3
Re: %pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
On Wed Mar 27, 2024 at 15:48 +0100, Karolina Surma wrote: > Hello, Hi Karolina, Thank you for bring this to the mailing list. > recently, we were suggested an improvement for %pyproject_buildrequires > -r/-x. > We could read the project's runtime dependencies (if they're not marked > as `dynamic`) from pyproject.toml [project] table directly, without > calling prepare_metadata_for_build_wheel or building the wheel to read > the dependency metadata from it. > Reading the metadata via prepare_metadata_for_build_wheel is already > quite fast, however implementing that hook is optional for the build > backends. I'll note that all build backends packaged in Fedora (setuptools, hatchling, flit-core, poetry-core, the pdm one, and scikit) other than meson-python support this hook. Only 9 packages BuildRequire python3-meson-python. > Maxwell has raised some valid concerns there: > - Other tools (build frontends, e.g. pip/build) call > prepare_metadata_for_build_wheel, our macros would diverge in > functionality compared to the rest of the landscape. > - pyproject.toml's [project] may not be the source of metadata that the > build backend uses. A project could switch to a build backend without > PEP 621 support (e.g. poetry-core) and forget to remove the [project] table. > - There can be potential differences between BuildRequires and Requires > generators when one generates dependencies based on the pyproject.toml > [project] table while the other on the packaged dist-info metadata. > - Using macros to build on older systems: e.g. RHEL 9's old setuptools > version silently ignores the pyproject.toml [project] table - > %pyproject_buildrequires could still pull the dependency information > from it, but the resulting package would be broken because it did not > include those in the packaged dist-info metadata. I could not have said it better myself :D. > One way to mitigate would be to make the proposed behavior opt-in only, > with the possibility to either build wheel with -w option (already > existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case > backend doesn't have prepare_metadata_for_build_wheel. Yeah, I think -p (for *p*yproject) is good flag name choice. > However, this adds a layer of complexity for packagers and macros > maintainers. > The questions we'd love your input for: > - Should this behavior exist but not be the default (explicit flag > would be required to opt-in)? I consider this the only reasonable solution other than not implementing the feature at all. > - Can you think of a better alternative than the ones described here? I guess I will throw something out there, but I am not convinced it is a great idea: what about making the `-p` flag fail if `prepare_metadata_for_build_wheel` is available? In my opinion, this should only be a last resort for backends that do not implement the hook. —Maxwell -- ___ 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
Orphaned packages looking for new maintainers
-limits python-param python-pyct python-signature-dispatch python-vecrec python-wtforms-sqlalchemy qterm raptor rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit telepathy-logger-qt Orphans (dependend on) (13): botan deepin-dock golang-github-googlecloudplatform-guest-logging libmodulemd1 libtranslate perl-Spreadsheet-WriteExcel-Simple php-ircmaxell-security-lib php-nyholm-psr7 python-autoprop python-param python-pyct python-signature-dispatch raptor Orphans (rawhide) for at least 6 weeks (dependend on) (5): golang-github-googlecloudplatform-guest-logging libmodulemd1 libtranslate php-ircmaxell-security-lib php-nyholm-psr7 Orphans (rawhide) (not depended on) (50): R-presser atinout emacs-htmlize gnome-shell-extension-freon gnome-translate golang-storj-uplink google-compute-engine-guest-configs google-disk-expand google-guest-agent google-osconfig-agent kio-upnp-ms ktp-contact-runner lightly liquidshell loudgain mrxvt ocaml-newt perl-Git-PurePerl perl-Net-GitHub perl-PDF-Haru perl-Spreadsheet-ParseExcel-Simple perl-String-Diff perl-WWW-Google-Contacts phosh-mobile-settings php-doctrine-persistence2 php-doctrine-persistence3 php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpSmug php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode python-aiomqtt python-colorcet python-extractcode python-limits python-vecrec python-wtforms-sqlalchemy qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit telepathy-logger-qt Orphans (rawhide) for at least 6 weeks (not dependend on) (30): R-presser atinout gnome-translate golang-storj-uplink google-compute-engine-guest-configs google-disk-expand google-guest-agent google-osconfig-agent lightly ocaml-newt perl-PDF-Haru phosh-mobile-settings php-doctrine-persistence2 php-doctrine-persistence3 php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit Depending packages (rawhide) (39): COPASI deepin-calendar deepin-control-center deepin-daemon deepin-dock deepin-draw deepin-editor deepin-file-manager deepin-launcher deepin-network-core deepin-session-shell deepin-session-ui deepin-system-monitor fedmod git-annex gnome-translate google-guest-agent google-osconfig-agent guitone ikiwiki lua-event monotone perl-Spreadsheet-ParseExcel-Simple php-ircmaxell-random-lib php-symfony-psr-http-message-bridge python-autoprop python-bluepyopt python-colorcet python-datalad python-efel python-elephant python-ephyviewer python-neo python-pyct python-pynn python-vecrec startdde trac-monotone-plugin traverso Packages depending on packages orphaned (rawhide) for more than 6 weeks (6): fedmod gnome-translate google-guest-agent google-osconfig-agent php-ircmaxell-random-lib php-symfony-psr-http-message-bridge -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2024-03-21 16:09:32 UTC -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned packages looking for new maintainers
-limits python-param python-pyct python-signature-dispatch python-vecrec python-wtforms-sqlalchemy qterm raptor rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit telepathy-logger-qt Orphans (dependend on) (13): botan deepin-dock golang-github-googlecloudplatform-guest-logging libmodulemd1 libtranslate perl-Spreadsheet-WriteExcel-Simple php-ircmaxell-security-lib php-nyholm-psr7 python-autoprop python-param python-pyct python-signature-dispatch raptor Orphans (rawhide) for at least 6 weeks (dependend on) (5): golang-github-googlecloudplatform-guest-logging libmodulemd1 libtranslate php-ircmaxell-security-lib php-nyholm-psr7 Orphans (rawhide) (not depended on) (50): R-presser atinout emacs-htmlize gnome-shell-extension-freon gnome-translate golang-storj-uplink google-compute-engine-guest-configs google-disk-expand google-guest-agent google-osconfig-agent kio-upnp-ms ktp-contact-runner lightly liquidshell loudgain mrxvt ocaml-newt perl-Git-PurePerl perl-Net-GitHub perl-PDF-Haru perl-Spreadsheet-ParseExcel-Simple perl-String-Diff perl-WWW-Google-Contacts phosh-mobile-settings php-doctrine-persistence2 php-doctrine-persistence3 php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpSmug php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode python-aiomqtt python-colorcet python-extractcode python-limits python-vecrec python-wtforms-sqlalchemy qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit telepathy-logger-qt Orphans (rawhide) for at least 6 weeks (not dependend on) (30): R-presser atinout gnome-translate golang-storj-uplink google-compute-engine-guest-configs google-disk-expand google-guest-agent google-osconfig-agent lightly ocaml-newt perl-PDF-Haru phosh-mobile-settings php-doctrine-persistence2 php-doctrine-persistence3 php-echonest-api php-endroid-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit Depending packages (rawhide) (39): COPASI deepin-calendar deepin-control-center deepin-daemon deepin-dock deepin-draw deepin-editor deepin-file-manager deepin-launcher deepin-network-core deepin-session-shell deepin-session-ui deepin-system-monitor fedmod git-annex gnome-translate google-guest-agent google-osconfig-agent guitone ikiwiki lua-event monotone perl-Spreadsheet-ParseExcel-Simple php-ircmaxell-random-lib php-symfony-psr-http-message-bridge python-autoprop python-bluepyopt python-colorcet python-datalad python-efel python-elephant python-ephyviewer python-neo python-pyct python-pynn python-vecrec startdde trac-monotone-plugin traverso Packages depending on packages orphaned (rawhide) for more than 6 weeks (6): fedmod gnome-translate google-guest-agent google-osconfig-agent php-ircmaxell-random-lib php-symfony-psr-http-message-bridge -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2024-03-21 16:09:32 UTC -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-03-04 18:10:50 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change R-presser @r-maint-sig, orphan 4 weeks ago atinout orphan 3 weeks ago deepin-dock @deepinde-sig, cheeselee,2 weeks ago felixonmars, orphan, zsun gnome-translate orphan 4 weeks ago golang-github-@go-sig, ngompa, orphan 3 weeks ago googlecloudplatform-guest- logging golang-gocloud@go-sig, orphan 3 weeks ago golang-storj-uplink @go-sig, orphan 3 weeks ago google-compute-engine-guest- ngompa, orphan 3 weeks ago configs google-disk-expandorphan 3 weeks ago google-guest-agent@go-sig, ngompa, orphan 3 weeks ago google-osconfig-agent @go-sig, orphan 3 weeks ago libmodulemd1 @copr-sig, orphan4 weeks ago libtranslate orphan 4 weeks ago lightly orphan 5 weeks ago liquidshell orphan 1 weeks ago ocaml-newtorphan 4 weeks ago perl-Git-PurePerl iarnell, orphan 1 weeks ago perl-Net-GitHub jplesnik, lkundrak, orphan, 1 weeks ago ppisar perl-PDF-Haru orphan 3 weeks ago perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 1 weeks ago Simple perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 1 weeks ago Simple perl-String-Diff iarnell, orphan 1 weeks ago perl-pgsql_perl5 orphan 0 weeks ago phosh-mobile-settings orphan 3 weeks ago php-doctrine-persistence2 orphan 4 weeks ago php-doctrine-persistence3 orphan 4 weeks ago php-echonest-api orphan 4 weeks ago php-endroid-qrcodeorphan 4 weeks ago php-interfasys-lognormalizer orphan 4 weeks ago php-ircmaxell-random-lib orphan 4 weeks ago php-ircmaxell-security-liborphan 4 weeks ago php-kukulich-fshl orphan 4 weeks ago php-mikealmond-musicbrainzorphan 4 weeks ago php-nyholm-psr7 orphan 4 weeks ago php-pear-MDB2-Schema orphan 3 weeks ago php-phpSmug orphan 1 weeks ago php-phpdocumentor-reflection- orphan 4 weeks ago docblock php-symfony-monolog-bundleorphan 4 weeks ago php-true-punycode orphan 4
Re: [Fedora-legal-list] Trivy for licenses
On Tue Mar 5, 2024 at 04:06 +, Maxwell G wrote: > On Mon Mar 4, 2024 at 22:35 +0100, Sandro wrote: > > On 04-03-2024 07:59, Miroslav Suchý wrote: > > > It would welcome if anyone can help Robert here: > > > https://bugzilla.redhat.com/show_bug.cgi?id=2235055 > > > > I had a look and it seems the package is currently stuck on broken > > python-pymaven-patch, which requires python-lxml < 5~~. In rawhide and > > f40 python-lxml was updated to 5.1.0 two months ago. > > > > For about as long there has been a PR open for python-pymaven-patch > > removing that version constraint. Notably, the maintainer of > > python-pymaven-patch is the same person, who submitted the > > scancode-toolkit review request. > > > > There may be more trouble down the road. But for the moment, I don't see > > how others can help driving this forward. A proven packager could merge > > the PR. But I don't know how eclipseo, who's a proven packager, would > > feel about that. > > Fixing FTI bugs that are unaddressed by a package's maintainer > definitely falls under the purview of a provenpackager. > I rebased the PR [1] and will merge it once CI passes. > > [1] https://src.fedoraproject.org/rpms/python-pymaven-patch/pull-request/1 It also looks like a bunch of the tests are failing and have been skipped. That's not super ideal. It looks like [1] has been open upstream for some time. I have not yet looked closely at the failures, but Philippe, if you have any pointers to give, that would certainly be helpful. [1] https://github.com/nexB/scancode-toolkit/issues/3496 -- ___ 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: [Fedora-legal-list] Trivy for licenses
On Mon Mar 4, 2024 at 22:35 +0100, Sandro wrote: > On 04-03-2024 07:59, Miroslav Suchý wrote: > > It would welcome if anyone can help Robert here: > > https://bugzilla.redhat.com/show_bug.cgi?id=2235055 > > I had a look and it seems the package is currently stuck on broken > python-pymaven-patch, which requires python-lxml < 5~~. In rawhide and > f40 python-lxml was updated to 5.1.0 two months ago. > > For about as long there has been a PR open for python-pymaven-patch > removing that version constraint. Notably, the maintainer of > python-pymaven-patch is the same person, who submitted the > scancode-toolkit review request. > > There may be more trouble down the road. But for the moment, I don't see > how others can help driving this forward. A proven packager could merge > the PR. But I don't know how eclipseo, who's a proven packager, would > feel about that. Fixing FTI bugs that are unaddressed by a package's maintainer definitely falls under the purview of a provenpackager. I rebased the PR [1] and will merge it once CI passes. [1] https://src.fedoraproject.org/rpms/python-pymaven-patch/pull-request/1 -- ___ 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: [Fedora-legal-list] Trivy for licenses
On Mon Mar 4, 2024 at 07:59 +0100, Miroslav Suchý wrote: > Dne 03. 03. 24 v 20:22 Philippe Ombredanne napsal(a): > > > If you want robust license detection, consider using ScanCode [2] and > > Scancode.io [3] for more complex pipelines. Both are tools that I > > co-maintain and are considered as better tools for this. Do not > > hesitate to reach out for help! > > *nod* > > It would welcome if anyone can help Robert here: > https://bugzilla.redhat.com/show_bug.cgi?id=2235055 Robert has not been very responsive as of late. It might be a good idea for someone else to pick it up and start a new review ticket. -- ___ 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: [Fedora-legal-list] Trivy for licenses
On Sun Mar 3, 2024 at 20:22 +0100, Philippe Ombredanne wrote: > Hi Maxwell: Hi Philippe, > On Sun, Mar 3, 2024, Maxwell G wrote: > > Has anyone every used trivy [1] to scan for licenses? It appears more > > robust and better maintained than askalono-cli and can detect files with > > multiple licenses and licenses embedded in file headers. I have been > > running it with "trivy fs --scanners license --license-full ." > > > > [1] https://github.com/aquasecurity/trivy > > IMHO trivy is not a robust tool for license detection from me trying it. I am not necessarily looking for the most robust tool for license detection. I am just looking for a relatively performant and reasonably accurate tool to scan a tree of Go modules for license files for the go-vendor-tools [1] project that I am working on. I evaluated askalono-cli and trivy for this purpose, and they both fulfil that criteria. I implemented support for both of them and added an option to choose which to use. The Fedora legal docs describes askalono as: It is most useful for quick analysis of packages coming out of ecosystems featuring projects known to have (1) highly standardized approaches to layout of license information (it specifically looks only for files that are named LICENSE or COPYING or some obvious variant on those), (2) generally simple license makeup, and (3) cultural preferences for a highly limited set of licenses (for example, Rust crates that don’t bundle legacy C code, Go modules, or Node.js npm packages). That is exactly what I am using it for. Trivy does a better job at detecting license files paths than asaklono and can also handle files with multiple licenses and some license headers. My code already checks that there is at least one license file in each Go module, so if one is missing, the go-vendor-tools license checker will fail and require the user to take manual action. The Go ecosystem is relatively standardized in terms of licensing, so I do not feel the need to use a tool like scancode which analyzes every single file and takes a very long time to run. > It is mostly based on google/licenseclassifier which had a single > commit in the last 17 months, and this means this is not more > maintained than askalono (and frankly both are fairly lightweight > I would not rely on > these for anything serious and certainly not to scan code for license > prior to its inclusion in Fedora. tools for license detection). I am striving for "reasonably sure" that all license texts are accounted for as opposed to spending 45 minutes performing a detailed license files for each package. > If you want robust license detection, consider using ScanCode [2] and > Scancode.io [3] for more complex pipelines. Both are tools that I > co-maintain and are considered as better tools for this. Do not > hesitate to reach out for help! I will definitely spend more time playing with scancode-toolkit, but I worry about the amount of time it takes to run on a large go vendor tree and that it has not been packaged for Fedora yet---it has a lot of Python dependencies. I opened [2] to track implementing a scancode backend for go-vendor-tools. I will be sure to let you know if I have any questions! [1] https://gitlab.com/gotmax23/go-vendor-tools/ [2] https://gitlab.com/gotmax23/go-vendor-tools/-/issues/15 Thanks, Maxwell -- ___ 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: Trivy for licenses
On Sun Mar 3, 2024 at 17:28 +0100, Miroslav Suchý wrote: > Dne 03. 03. 24 v 7:35 Maxwell G napsal(a): > > > > Has anyone every used trivy [1] to scan for licenses? It appears more > > robust and better maintained than askalono-cli > > and can detect files with multiple licenses and licenses embedded in file > > headers. I have been running it with "trivy > > fs --scanners license --license-full ." > > > > [1] https://github.com/aquasecurity/trivy > > This is new to me. Yeah, me too. I had not seen it anywhere before, so I figured I would ask about it. > Looks good. I will add it to > https://docs.fedoraproject.org/en-US/legal/license-audit-tools/ Cool! Feel free to tag me if you would like a review of the docs PR. > And the upstream provides rpm. Static build, but better than nothing. I or another member of the Go SIG could probably package it if there is interest. -- ___ 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
Trivy for licenses
Hi, Has anyone every used trivy [1] to scan for licenses? It appears more robust and better maintained than askalono-cli and can detect files with multiple licenses and licenses embedded in file headers. I have been running it with "trivy fs --scanners license --license-full ." [1] https://github.com/aquasecurity/trivy -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-02-21 17:04:45 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change R-presser @r-maint-sig, orphan 3 weeks ago applet-window-buttons @kde-sig, orphan 3 weeks ago atinout orphan 1 weeks ago bismuth @kde-sig, orphan 3 weeks ago deepin-dock @deepinde-sig, cheeselee,0 weeks ago felixonmars, orphan, zsun drumstick0orphan, yanqiyu 4 weeks ago elpa @scitech_sig, orphan 6 weeks ago gnome-translate orphan 3 weeks ago golang-github-apache-arrow@go-sig, orphan 0 weeks ago golang-github-@go-sig, ngompa, orphan 2 weeks ago googlecloudplatform-guest- logging golang-gocloud@go-sig, orphan 2 weeks ago golang-storj-uplink @go-sig, orphan 2 weeks ago google-compute-engine-guest- ngompa, orphan 2 weeks ago configs google-disk-expandorphan 2 weeks ago google-guest-agent@go-sig, ngompa, orphan 2 weeks ago google-osconfig-agent @go-sig, orphan 2 weeks ago kpipewire5@kde-sig, orphan 5 weeks ago libmodulemd1 @copr-sig, orphan3 weeks ago libtranslate orphan 3 weeks ago lightly orphan 3 weeks ago ocaml-newtorphan 3 weeks ago perl-BackPAN-Indexiarnell, orphan 0 weeks ago perl-Cache-FastMmap iarnell, orphan 0 weeks ago perl-Git-PurePerl iarnell, orphan 0 weeks ago perl-Git-Repository iarnell, orphan 0 weeks ago perl-Net-GitHub jplesnik, lkundrak, orphan, 0 weeks ago ppisar perl-PDF-Haru orphan 1 weeks ago perl-SOAP-Litemspacek, orphan, pghmcfc,0 weeks ago ppisar perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 0 weeks ago Simple perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 0 weeks ago Simple perl-String-Diff iarnell, orphan 0 weeks ago phosh-mobile-settings orphan 1 weeks ago php-doctrine-persistence2 orphan 3 weeks ago php-doctrine-persistence3 orphan 3 weeks ago php-echonest-api orphan 3 weeks ago php-endroid-qrcodeorphan 3 weeks ago php-interfasys-lognormalizer orphan 3 weeks ago php-ircmaxell-random-lib orphan 3 weeks ago php-ircmaxell-security-liborphan 3
Orphaned packages looking for new maintainers
Report started at 2024-02-21 17:04:45 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in the left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change R-presser @r-maint-sig, orphan 3 weeks ago applet-window-buttons @kde-sig, orphan 3 weeks ago atinout orphan 1 weeks ago bismuth @kde-sig, orphan 3 weeks ago deepin-dock @deepinde-sig, cheeselee,0 weeks ago felixonmars, orphan, zsun drumstick0orphan, yanqiyu 4 weeks ago elpa @scitech_sig, orphan 6 weeks ago gnome-translate orphan 3 weeks ago golang-github-apache-arrow@go-sig, orphan 0 weeks ago golang-github-@go-sig, ngompa, orphan 2 weeks ago googlecloudplatform-guest- logging golang-gocloud@go-sig, orphan 2 weeks ago golang-storj-uplink @go-sig, orphan 2 weeks ago google-compute-engine-guest- ngompa, orphan 2 weeks ago configs google-disk-expandorphan 2 weeks ago google-guest-agent@go-sig, ngompa, orphan 2 weeks ago google-osconfig-agent @go-sig, orphan 2 weeks ago kpipewire5@kde-sig, orphan 5 weeks ago libmodulemd1 @copr-sig, orphan3 weeks ago libtranslate orphan 3 weeks ago lightly orphan 3 weeks ago ocaml-newtorphan 3 weeks ago perl-BackPAN-Indexiarnell, orphan 0 weeks ago perl-Cache-FastMmap iarnell, orphan 0 weeks ago perl-Git-PurePerl iarnell, orphan 0 weeks ago perl-Git-Repository iarnell, orphan 0 weeks ago perl-Net-GitHub jplesnik, lkundrak, orphan, 0 weeks ago ppisar perl-PDF-Haru orphan 1 weeks ago perl-SOAP-Litemspacek, orphan, pghmcfc,0 weeks ago ppisar perl-Spreadsheet-ParseExcel- jplesnik, orphan, ppisar 0 weeks ago Simple perl-Spreadsheet-WriteExcel- jplesnik, orphan, ppisar 0 weeks ago Simple perl-String-Diff iarnell, orphan 0 weeks ago phosh-mobile-settings orphan 1 weeks ago php-doctrine-persistence2 orphan 3 weeks ago php-doctrine-persistence3 orphan 3 weeks ago php-echonest-api orphan 3 weeks ago php-endroid-qrcodeorphan 3 weeks ago php-interfasys-lognormalizer orphan 3 weeks ago php-ircmaxell-random-lib orphan 3 weeks ago php-ircmaxell-security-liborphan 3
Orphaned packages looking for new maintainers
-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode purple-mm-sms python-GridDataFormats python-extractcode python-jupyter-collaboration python-kaitaistruct python-limits qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit tachyon virtme xdrawchem Orphans (rawhide) for at least 6 weeks (not dependend on) (0): Depending packages (rawhide) (21): calls cp2k fedmod gnome-translate google-guest-agent google-osconfig-agent kmid2 maui-mauikit pgadmin4 phosh phosh-mobile-settings php-ircmaxell-random-lib php-symfony-psr-http-message-bridge plasma-dialer pymol python-GridDataFormats python-jupyter-collaboration python-jupyter-ydoc python-y-py python-ypy-websocket rust-yrs Packages depending on packages orphaned (rawhide) for more than 6 weeks (0): -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2024-02-13 01:13:36 UTC -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned packages looking for new maintainers
-qrcode php-interfasys-lognormalizer php-ircmaxell-random-lib php-kukulich-fshl php-mikealmond-musicbrainz php-pear-MDB2-Schema php-phpdocumentor-reflection-docblock php-symfony-monolog-bundle php-true-punycode purple-mm-sms python-GridDataFormats python-extractcode python-jupyter-collaboration python-kaitaistruct python-limits qterm rubygem-rest-client rubygem-rubygems-mirror rust-loopdev sphinxbase svnkit tachyon virtme xdrawchem Orphans (rawhide) for at least 6 weeks (not dependend on) (0): Depending packages (rawhide) (21): calls cp2k fedmod gnome-translate google-guest-agent google-osconfig-agent kmid2 maui-mauikit pgadmin4 phosh phosh-mobile-settings php-ircmaxell-random-lib php-symfony-psr-http-message-bridge plasma-dialer pymol python-GridDataFormats python-jupyter-collaboration python-jupyter-ydoc python-y-py python-ypy-websocket rust-yrs Packages depending on packages orphaned (rawhide) for more than 6 weeks (0): -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2024-02-13 01:13:36 UTC -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: fedrq - new repoquerying tool
Hi everyone, On 2/11/23 23:31, Maxwell G via devel wrote: I've been working on a repoquerying tool called fedrq [1] that I'd like to share with you. Here's the elevator pitch: fedrq provides a friendly interface to query the Fedora repositories. It makes it really easy to query across Fedora and EPEL branches. It uses the dnf Python bindings (libdnf5 backend is almost done) and doesn't shell out to dnf repoquery. Amongst other things, fedrq allows querying for reverse dependencies, packages that contain a certain Provide or file, subpackages of an SRPM, and general package metadata. My favorite features are the easy branch switching, `fedrq subpkgs` (there's no real equivalent in dnf repoquery), and the ability to dump package metadata as JSON. The many threads about how to properly query for dependencies when doing SO name bump rebuilds and my own frustrations with dnf repoquery inspired this tool. [1] https://sr.ht/~gotmax23/fedrq/ [2] https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq/ [3] https://gotmax23.srht.site/fedrq/fedrq.1.html#EXAMPLES I have been actively developing fedrq for over a year now. Since last February, there have been many changes, improvements, and new features introduced[1]. fedrq has new commands including the download, download-spec, changelogs, and make-cache subcommands, new output formatting options, and many built-in release configurations to make it easy to query other RPM-based distributions. I also fleshed out the public API to provide a strong compatibility layer between the dnf and libdnf5 (Package)Query APIs. It's been heartening to see the tool adopted by Fedora developers and receive feedback and questions. fedrq has been under beta (0.Y.Z releases) up until now, but development is nearing the 1.0.0 release milestone. Before that, I wanted to reach out again to see if anyone had additional feedback, suggestions, questions, or any other commentary. Feel free to respond here or hop over to fedrq's mailing list[2]! [1] https://fedrq.gtmx.me/News/ [2] https://lists.sr.ht/~gotmax23/fedrq Best, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-01-28 16:04:44 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainersStatus Change 3proxy orphan 3 weeks ago applet-window-buttons @kde-sig, orphan0 weeks ago bismuth@kde-sig, orphan0 weeks ago cdsclient @astro-sig, orphan 4 weeks ago csmith orphan 4 weeks ago drumstick0 orphan, yanqiyu 1 weeks ago elpa @scitech_sig, orphan3 weeks ago kpipewire5 @kde-sig, orphan2 weeks ago lightlyorphan 0 weeks ago php-PHP-CSS-Parser orphan 3 weeks ago plasma-bigscreen @kde-sig, orphan0 weeks ago python-GridDataFormats @scitech_sig, orphan3 weeks ago python-compressed-rtf orphan 4 weeks ago python-extractcode @python-packagers-sig, orphan 0 weeks ago python-flit@epel-packagers-sig, @python- 0 weeks ago packagers-sig, orphan, salimma python-jupyter-collaboration orphan 2 weeks ago python-jupyter-server-fileid orphan 2 weeks ago python-jupyter-ydocorphan 2 weeks ago python-kaitaistructorphan 3 weeks ago python-maya@neuro-sig, orphan 5 weeks ago python-mmtf@scitech_sig, orphan3 weeks ago python-mrcfile orphan 3 weeks ago python-red-black-tree-mod orphan 4 weeks ago python-represent orphan 0 weeks ago python-y-py@python-packagers-sig, orphan 2 weeks ago python-ypy-websocket orphan 2 weeks ago qterm orphan 4 weeks ago rubygem-hrxjcpunk, orphan, tdawson 5 weeks ago rubygem-linked-listjcpunk, orphan, tdawson 5 weeks ago rubygem-rubygems-mirror@ruby-packagers-sig, orphan 1 weeks ago rust-lib0 @rust-sig, orphan 2 weeks ago rust-yrs @rust-sig, orphan 2 weeks ago scamp @astro-sig, orphan 4 weeks ago sphinxbase @epel-packagers-sig, orphan 0 weeks ago tachyon@scitech_sig, orphan3 weeks ago virtme orphan 3 weeks ago xdrawchem @scitech_sig, orphan3 weeks ago The following packages require above mentioned packages: Depending on: applet-window-buttons (1), status change: 2024-01-24 (0 weeks ago) maui-mauikit (maintained by: thunderbirdtr) maui-mauikit-2.1.1-4.fc39.i686 requires applet-window-buttons = 0.11.1-7.fc39 maui-mauikit-2.1.1-4.fc39.x86_64 requires applet-window-buttons = 0.11.1-7.fc39 Depending on: cdsclient (1), status change: 2023-12-29 (4 weeks ago) scamp (maintained by: @astro-sig, orphan) scamp-2.10.0-5.fc38.src requires cdsclient = 3.84-16.fc39 scamp-2.10.0-5.fc38.x86_64 requires cdsclient = 3.84-16.fc39 Depending on: drumstick0 (1), status change: 2024-01-18 (1 weeks
Orphaned packages looking for new maintainers
Orphaned packages looking for new maintainers -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-flit
On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:
> Hello.
Hi Miro,
Thanks for the announcement!
> Now when python-flit-core has been split out of python-flit, I do no longer
> have a use-case for python-flit and hence I have orphaned it.
For context, flit-core is the PEP 517 build backend that we need for use
with %pyproject_* in RPM builds. python3-flit provides the flit CLI that
can be used for basic Python project management (publishing to PyPI and
such). python3-flit and python3-flit-core used to be built from the same
SRPM, but we recently split it into two separate packages to simply the
specfile and help with RHEL builds.
While Python developers can always install the flit CLI with pipx or in
a virtual environment, it is nice to have a global version managed by
the system package manager.
I'll probably end up taking the package.
> $ repoquery -q --repo=rawhide{,-source} --whatrequires flit
> python-perky-0:0.8.2-3.fc39.src
> python-pydyf-0:0.8.0-1.fc40.src
> python-pyrpm-0:0.14.1-3.fc39.src
> python-signature-dispatch-0:1.0.1-4.fc39.src
> python-vecrec-0:0.3.1-11.fc40.src
> weasyprint-0:60.2-1.fc40.src
>
> The packages would probably build fine with flit-core (happy to help with
> that
> if you are interested).
Regardless, those packages should switch to using flit-core to build.
Pulling in all of flit is not necessary for RPM builds.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
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-flit
On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:
> Hello.
Hi Miro,
Thanks for the announcement!
> Now when python-flit-core has been split out of python-flit, I do no longer
> have a use-case for python-flit and hence I have orphaned it.
For context, flit-core is the PEP 517 build backend that we need for use
with %pyproject_* in RPM builds. python3-flit provides the flit CLI that
can be used for basic Python project management (publishing to PyPI and
such). python3-flit and python3-flit-core used to be built from the same
SRPM, but we recently split it into two separate packages to simply the
specfile and help with RHEL builds.
While Python developers can always install the flit CLI with pipx or in
a virtual environment, it is nice to have a global version managed by
the system package manager.
I'll probably end up taking the package.
> $ repoquery -q --repo=rawhide{,-source} --whatrequires flit
> python-perky-0:0.8.2-3.fc39.src
> python-pydyf-0:0.8.0-1.fc40.src
> python-pyrpm-0:0.14.1-3.fc39.src
> python-signature-dispatch-0:1.0.1-4.fc39.src
> python-vecrec-0:0.3.1-11.fc40.src
> weasyprint-0:60.2-1.fc40.src
>
> The packages would probably build fine with flit-core (happy to help with
> that
> if you are interested).
Regardless, those packages should switch to using flit-core to build.
Pulling in all of flit is not necessary for RPM builds.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
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: Proposal: Eliminate buildroot overrides
On Mon Jan 22, 2024 at 13:07 -0500, Stephen Gallagher wrote: > tl;dr: Buildroot overrides should be restricted to releng members and > packagers should use on-demand side-tags instead. Previous discussion from December 2022: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X2RQQQ76NYDF4Y3L3WSSNW2MSIOI6CHW/#X2RQQQ76NYDF4Y3L3WSSNW2MSIOI6CHW I believe we ultimately concluded that there were still some valid usecases for buildroot overrides. I'm not sure the situation has materially changed since then. -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Orphaned packages looking for new maintainers
Report started at 2024-01-15 15:04:52 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 3proxyorphan 1 weeks ago cdsclient @astro-sig, orphan 2 weeks ago cp2k @scitech_sig, jussilehtola, 1 weeks ago lecris, orphan, tomspur csmithorphan 2 weeks ago drumstick0orphan, yanqiyu 2 weeks ago elpa @scitech_sig, orphan 1 weeks ago kf6-karchive @kde-sig, orphan 0 weeks ago kf6-kplotting @kde-sig, orphan 0 weeks ago kf6-networkmanager-qt @kde-sig, orphan 0 weeks ago kf6-syntax-highlighting @kde-sig, orphan 0 weeks ago kio-ftps @kde-sig, orphan, rdieter, 0 weeks ago than kjots @kde-sig, orphan 0 weeks ago kmag @kde-sig, orphan, rdieter, 0 weeks ago than kmetronomeorphan 2 weeks ago koko @kde-sig, orphan 0 weeks ago kongress @kde-sig, orphan,0 weeks ago thunderbirdtr kpipewire5@kde-sig, orphan 0 weeks ago libASLorion, orphan, slaanesh 4 weeks ago mygnuhealth orphan 2 weeks ago obs-service-cargo_vendor orphan 4 weeks ago php-PHP-CSS-Parserorphan 1 weeks ago python-GridDataFormats@scitech_sig, orphan 1 weeks ago python-Pymplerorphan 1 weeks ago python-colorspacious orphan 1 weeks ago python-compressed-rtf orphan 2 weeks ago python-google-cloud-access- @python-packagers-sig, fkolwa, 4 weeks ago approval miyunari, orphan python-google-cloud-access- @python-packagers-sig, fkolwa, 4 weeks ago context-manager miyunari, orphan python-google-cloud-api-gateway @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-apigee- @python-packagers-sig, fkolwa, 4 weeks ago connect miyunari, orphan python-google-cloud-appengine-@python-packagers-sig, fkolwa, 4 weeks ago admin miyunari, orphan python-google-cloud-asset @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-automl@python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-bigquery @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-bigquery- @python-packagers-sig, fkolwa, 4 weeks ago connectionmiyunari, orphan
Orphaned packages looking for new maintainers
Report started at 2024-01-15 15:04:52 UTC The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://a.gtmx.me/orphans/orphans.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 3proxyorphan 1 weeks ago cdsclient @astro-sig, orphan 2 weeks ago cp2k @scitech_sig, jussilehtola, 1 weeks ago lecris, orphan, tomspur csmithorphan 2 weeks ago drumstick0orphan, yanqiyu 2 weeks ago elpa @scitech_sig, orphan 1 weeks ago kf6-karchive @kde-sig, orphan 0 weeks ago kf6-kplotting @kde-sig, orphan 0 weeks ago kf6-networkmanager-qt @kde-sig, orphan 0 weeks ago kf6-syntax-highlighting @kde-sig, orphan 0 weeks ago kio-ftps @kde-sig, orphan, rdieter, 0 weeks ago than kjots @kde-sig, orphan 0 weeks ago kmag @kde-sig, orphan, rdieter, 0 weeks ago than kmetronomeorphan 2 weeks ago koko @kde-sig, orphan 0 weeks ago kongress @kde-sig, orphan,0 weeks ago thunderbirdtr kpipewire5@kde-sig, orphan 0 weeks ago libASLorion, orphan, slaanesh 4 weeks ago mygnuhealth orphan 2 weeks ago obs-service-cargo_vendor orphan 4 weeks ago php-PHP-CSS-Parserorphan 1 weeks ago python-GridDataFormats@scitech_sig, orphan 1 weeks ago python-Pymplerorphan 1 weeks ago python-colorspacious orphan 1 weeks ago python-compressed-rtf orphan 2 weeks ago python-google-cloud-access- @python-packagers-sig, fkolwa, 4 weeks ago approval miyunari, orphan python-google-cloud-access- @python-packagers-sig, fkolwa, 4 weeks ago context-manager miyunari, orphan python-google-cloud-api-gateway @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-apigee- @python-packagers-sig, fkolwa, 4 weeks ago connect miyunari, orphan python-google-cloud-appengine-@python-packagers-sig, fkolwa, 4 weeks ago admin miyunari, orphan python-google-cloud-asset @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-automl@python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-bigquery @python-packagers-sig, fkolwa, 4 weeks ago miyunari, orphan python-google-cloud-bigquery- @python-packagers-sig, fkolwa, 4 weeks ago connectionmiyunari, orphan
Re: Removing deprecated %patch syntax from go-sig's packages
On Tue Jan 9, 2024 at 17:30 +, Maxwell G wrote: > Hi everyone, > > RPM has deprecated the `%patchN` syntax in favor of `%patch -PN` where > `N` is the patch number. See the RPM documentation for more information > [1]. In current RPM versions, this syntax only emits a deprecation > warning, but support for this syntax has been removed completely on the > rpm master branch [2]. Around 100 packages maintained by the go-sig > still use this syntax. > > Later this week/early next week, I will run this script [3] over the > affected go-sig packages [4] to update them to the modern patch syntax. > For example, the script will change: > > %patch0 -p1 -> %patch -P0 -p1 > %patch0005 -p2 -> %patch -P0005 -p2 > > If anyone has any objections or would like to exclude a package, please > let me know. > > ---Maxwell > > [1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 > [2] > https://github.com/rpm-software-management/rpm/commit/afd352481bacea521ce5ba01e989866478278532 > [3] > https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/new_patch_syntax.sh > [4] > https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/new_patch_syntax/packages This has been completed. Have a good weekend! -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Changes/RemovePythonMockUsage affected packages
zbyszekpython-libarchive-c python-music21 python-pysb Best, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Changes/RemovePythonMockUsage affected packages
zbyszekpython-libarchive-c python-music21 python-pysb Best, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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
Removing deprecated %patch syntax from go-sig's packages
Hi everyone, RPM has deprecated the `%patchN` syntax in favor of `%patch -PN` where `N` is the patch number. See the RPM documentation for more information [1]. In current RPM versions, this syntax only emits a deprecation warning, but support for this syntax has been removed completely on the rpm master branch [2]. Around 100 packages maintained by the go-sig still use this syntax. Later this week/early next week, I will run this script [3] over the affected go-sig packages [4] to update them to the modern patch syntax. For example, the script will change: %patch0 -p1 -> %patch -P0 -p1 %patch0005 -p2 -> %patch -P0005 -p2 If anyone has any objections or would like to exclude a package, please let me know. ---Maxwell [1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1 [2] https://github.com/rpm-software-management/rpm/commit/afd352481bacea521ce5ba01e989866478278532 [3] https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/new_patch_syntax.sh [4] https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/new_patch_syntax/packages -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: Enabling GOPROXY and GOSUMDB in Fedora
On Wed Dec 20, 2023 at 07:57 -0800, Brad Smith wrote: > The go.env file does not, as far as I can tell, contain the original > values from upstream. Just the modified values. Unless I modified the > file and cannot recall doing so! My suggestion was to include the > original upstream settings as comments. Ah, now I see what you mean. Yes, we should definitely update those comments. -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: Enabling GOPROXY and GOSUMDB in Fedora
On Wed Dec 20, 2023 at 12:14 +0100, Ondrej Pohorelsky wrote: > On Tue, Dec 19, 2023 at 11:11 PM Neal Gompa wrote: > > > On Tue, Dec 19, 2023 at 4:14 PM Brad Smith > > wrote: > > > > > > At a minimum, I recommend that the patch include the original values > > > for GOPROXY, GOSUMDB, and GOTOOLCHAIN as comments. This makes it > > > easier to change back to default values. At the moment, one has to > > > visit the relevant web pages. > > > > > > I lean towards providing upstream defaults in this case with updated > > > content on the developer portal (and elsewhere?) with information on > > > why changing these values would be useful. I agree that the comments > > > in the thread are persuasive (for me). > > > > > > > I agree with this. I'd rather keep the patch than revert to upstream > > defaults. > If you decide to keep the envars as they are now, I would also agree with > having the original values commented. Can someone clarify what they mean by this? The patch itself [1] makes it pretty clear what the original values are. I think the main thing is improving the user-facing documentation about why we do this and how to restore the original behavior. The Fedora Developer Portal (which really needs to be promoted more; it's a great resource!) documents [2] that we change GOPROXY and GOTOOLCHAIN, but it doesn't mention GOSUMDB, and it's lacking clear instructions about how to change the values back to defaults. [1]: https://src.fedoraproject.org/rpms/golang/blob/rawhide/f/0001-Modify-go.env.patch [2]: https://developer.fedoraproject.org/tech/languages/go/go-installation.html#fedora-specific-notes -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: *****SPAM***** Enabling GOPROXY and GOSUMDB in Fedora
On Tue Dec 19, 2023 at 17:33 +0100, Alejandro Saez Morollon wrote: > TL;DR: Remove a patch we ship in Go that disables GOPROXY and GOSUMDB and > follow upstream defaults, or keep it? I support keeping the Google Go module proxy disabled by default. Our packages should not send telemetry data to Google without explicit opt-in. We can highlight in the documentation how to re-eanble GOPROXY and GOSUMDB if necessary. -- Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: Proven to be sickened
On Fri Dec 1, 2023 at 16:26 +0100, Michael J Gruber wrote: > So, due to me following my package (notmuch) upstream and testing early > against upstream's git, reporting and working with upstream, I noticed a > FTBFS and helped fixing it. Nothing urgent since it was basically just a > test failing for the wrong reasons. > > Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue > whatsoever? FTBFS/FTI bugs are considered serious Unhandled issues[1] that provenpackagers are deputized to fix. The package FTBFS and merging the Ruby update side tag without fixing the FTBFS would've caused it FTI and broken other packages. One of these is aerc which I help maintain, so I'm happy that Mamoru took the time to fix it. Many packagers view FTBFS bugs as low priority issues, but when they're not addressed, they can cause larger issues that affect other packages in the distribution. > Dunno whether it's the new fmn or what. That works for *my* actions with > pagure/bodhi/koji but fails to report copr actions to me, and > apparently also actions by others. Yeah, you may have to go to https://nofications.fedoraproject.org and readjust your settings. [1]: https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which_packages/#unhandled_issues -- Best, Maxwell G (@gotmax23) Pronouns: He/They -- ___ 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: Optional %changelog (was: F38 proposal: Rpmautospec by Default (System-Wide Change proposal))
I'll bite :). I changed the subject accordingly. On Tue Oct 24, 2023 at 00:31 +0200, Pavel Raiskup wrote: > Packaging become an automatized task, and maintainers don't pay > attention to %changelog beauty so they simply generate it from git-log > (but I'd claim that git-log != %changelog). I tend to agree. A package's git log and %changelog have different purposes and cater to different audiences. The former focusses on developers. Each commit should each contain a single logical change to the code in distgit (specfile/patches/sources) with body text to justify the change as appropriate. The %changelog is a user-visible summary that should only mention user-visible changes and not have extra information related to the development itself. For simpler packages, combining these two logs via rpmautospec (with the ability to [skip changelog] commits) can work well, but in other cases, including every single commit message can create a %changelog full of garbage or otherwise confuse packagers. > %changelog become one of the most painful maintainers' headache :) > > What do you think about a static changelog like: > > %changelog > * See https://src.fedoraproject.org/rpms//commits/rawhide > > Aren't we ready to admit (something like) this is enough? The %changelog is supposed to follow a specific format, as per the guidelines, and the datestamps are used to set $SOURCE_DATE_EPOCH. Replacing the entire changelog with this type of text would break that, and I think having a (potentially flawed) %changelog generated from the git log is better than none at all. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: Looking for a volunteer to automate the orphaned packages process
2023-10-19T09:06:53Z Miro Hrončok : you might know I run a script that generates https://churchyard.fedorapeople.org/orphans.txt https://churchyard.fedorapeople.org/orphans.json The script is located at https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py I try to monitor the output and whenever it is stuck, I restart it. Every 2 weeks I try to save a copy of the generated file and send it to the devel list, devel announce list and the affected maintainers. Every branching, the script needs (trivial) changes. When I see packages orphaned for 6+ weeks, I retire them. I took this task a coupe years back because I was not satisfied with the status quo at that time (packages orphaned for year+ lingering in the distro). The task is semi-automated but not fully. After almost 5 years, I think it's time to pass this to somebody else. Preferably to somebody who would enjoy automating it entirely. I can provide all the details about the operation if you want to become the reaper's apprentice. Please do let me know. I believe this process is essential for the health of Fedora but I'd like to be relieved of this task. Hi Miro, Thanks for all of your work on the orphaned package process and related processes up until now. I agree that making sure that packages in the distro are maintained is crucial. This task interests me and is similar to previous work I've done in the Go ecosystem, but I'm not sure I'm up for additional responsibilities right now, at least not before EOY. Best, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: Python enable dependency generator problem
On Wed Oct 11, 2023 at 09:31 -0300, Priscila Gutierres wrote: > Thank you, > It works removing -t from %pyproject_buildrequires, EXCEPT if I keep all > the pytest tests running > When running the test, it blames about the modules needed for the tests, as > you can see here: https://paste.centos.org/view/5f0e107a That's because you didn't add (automatic or otherwise) BuildRequires for the test dependencies. > Deleting line 61 here: https://paste.centos.org/view/c25fee49, everything > works as expected +_+ That's very much the wrong solution. Unless the test suite is something kooky, you ought to run it in %check during the RPM build. If the test suite indeed cannot be run due to dependency on network access or a system service or a similar reason, you should use %py3_check_import / %pyproject_check_import. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: Execute RPM dependency generators on the .spec file which ships them
On Mon Oct 9, 2023 at 17:30 +0200, Vít Ondruch wrote:
>
> Dne 09. 10. 23 v 9:21 Petr Pisar napsal(a):
> > V Fri, Oct 06, 2023 at 06:06:14PM +0200, Vít Ondruch napsal(a):
> > That's hilarious because it's completely out of specification for the
> > genarators
> > <https://rpm-software-management.github.io/rpm/manual/dependency_generators.html#generators>:
> >
> > A generator is just an executable that reads file name(s) from stdin
> >
> > While your rpm-local-generator-test.spec redefines it to a function reading
> > an argument:
> >
> > %global __local_generator_provides()
> > local-generator-provide(%%{basename:%{1}})
> >
> > I'd like to see comments from RPM maintainers.
>
>
> This is documented:
>
> https://rpm-software-management.github.io/rpm/manual/dependency_generators.html#parametric-macro-generators-rpm--416
>
> I have used the function just because of simplicity, nothing else. You
> can see real life usage of the function generators here:
>
> https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/pythonname.attr
Indeed, the parametric generators are quite convenient for simpler
usecases, as you don't need to execute a bunch of processes just to
print some text to stdout.
For packages with a lot of files (e.g. ansible which I maintain), this
really adds up.
--
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: F40 Change Proposal: KDE Plasma 6 (System Wide)
On Tue Sep 26, 2023 at 13:07 +0200, Kevin Kofler via devel wrote: > Maxwell G wrote: > > Also, I do not like that this is tied together to the Plasma 6 change. > > Nobody is actually talking about the subject of the change, KDE Plasma > > 6; most of the conversation is about dropping X11 which was tacked on to > > this Change. > > It would be better as a separate Change with a separate discussion, IMO. > > +1 > > This looks to me a lot like a typical political maneuver, sneaking an > undesirable change into an otherwise desirable larger one in an attempt to > get the undesirable part through with less resistance. I am not suggesting that there is malicious intent here. Even if I do not agree with it, the Change owners did justify their reasoning for doing this. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: F40 Change Proposal: KDE Plasma 6 (System Wide)
On Wed Sep 13, 2023 at 16:53 +0100, Aoife Moloney wrote: > This upgrade is also notable that for Fedora Linux (and Fedora Extra > Packages for Enterprise Linux 10, once that materializes), KDE Plasma > will '''not''' offer an X11 session. Fedora KDE has been fully Wayland > by default from login ([[Changes/WaylandByDefaultForSDDM|since Fedora > Linux 38]]) to desktop ([[Changes/WaylandByDefaultForPlasma|since > Fedora Linux 34]]), and the SIG is confident in the quality and > development around the Plasma Wayland experience to stand fully behind > it. > > == Feedback == > > Why drop the X11 session? > > Three reasons for this removal: > > * > [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality#JIRA-RHELPLAN-121048 > The Xorg server is deprecated since RHEL 9.0] and will be dropped in > "a future major RHEL release". > * Graphics fallback modes are Wayland-friendly now with > [[Changes/ReplaceFbdevDrivers|SimpleDRM enabled since Fedora Linux > 36]]. > * NVIDIA drivers (since v495~v515) support GBM for Wayland instead of > EGLStreams. Wayland is fully supported on current NVIDIA drivers. > > This will drastically reduce our support burden and give us the > ability to focus on quality for the KDE Plasma stack and continue our > feature-forward nature. The Fedora KDE SIG will maintain a single code > stream for all supported distribution targets (Fedora Linux 40+, > Fedora Extra Packages for Enterprise Linux 10+). > > This also does not mean that X11 applications will not work in Plasma > 6, as we will still support Xwayland for running X11 applications on > Plasma Wayland. My laptop with NVIDIA Optimus graphics cannot connect to an external monitor unless I log in to the X11 session. This is a known problem [1]. Please don't throw out the baby with the bath water. Making Wayland the default and even removing X11 from the default installation is one thing, but entirely removing it does not make sense to me. Some people still have niche usecases that do not work with Wayland. We can iterate on the Wayland session without breaking users. Also, I do not like that this is tied together to the Plasma 6 change. Nobody is actually talking about the subject of the change, KDE Plasma 6; most of the conversation is about dropping X11 which was tacked on to this Change. It would be better as a separate Change with a separate discussion, IMO. [1] https://community.kde.org/Plasma/Wayland_Showstoppers -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: The new Change discussion process is painful
On Wed Sep 13, 2023 at 12:19 +0200, Sandro wrote: > On 13-09-2023 08:09, Adam Williamson wrote: > > From there, it's up to people where they see and respond to them. If > > more people are responding in discourse than on the mailing list, that > > would seem to suggest that there*is* a reason to announce things > > there... > > I'm quite sure Matthew (mattdm) would disagree with above statement. The > idea was/is, iirc, to only announce on both channels, but have the > discussion take place on Discourse. Right, people were asked not to comment on the mailing list and some people just ignored that and replied anyways. That doesn't necessarily mean that people that followed that request wouldn't have participated if it was only announced on the mailing list. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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?
On Tue Sep 12, 2023 at 09:21 +0200, Sandro wrote: > On 12-09-2023 03:36, Maxwell G wrote: > >> It isn't packaged for Fedora yet, though. Is anyone using it, and would > >> like to package + maintain it for Fedora? > > IIRC, we used to have nim in Fedora and then it was retired. > > Indeed. That may be a good starting point. > > There's also nim-srpm-macros [1], which has a bit of a misleading name. > It's for converting nimble packages to RPM. > > [1] https://src.fedoraproject.org/rpms/nim-srpm-macros > That's actually named according to convention. It only contains a `%nim_arches` definition which is needed during the SRPM build stage and used to be Required by redhat-rpm-config and part of the default buildroot. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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?
On Sun Sep 10, 2023 at 22:04 +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? IIRC, we used to have nim in Fedora and then it was retired. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: An update on RHEL moving to issues.redhat.com
2023-09-09T01:05:39Z Brendan Conoboy : All new issues found or desired in RHEL (Or CentOS Stream) need to be filed on issues.redhat.com[http://issues.redhat.com]. Hi Brendan, Thanks for the update. How can I watch (i.e. get email notifications about) specific packages' bugs in Jira like I could with <https://bugzilla.redhat.com/userprefs.cgi?tab=component_watch>? I currently watch ansible-core bugs so I can keep up with RHEL changes and properly maintain the ansible community package in EPEL. Thanks again, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: F40 Proposal: Revitalize Forge Macros (Self-Contained Change proposal)
On Wed Aug 23, 2023 at 12:32 +0200, Sandro wrote:
> On 19-08-2023 23:15, Maxwell G wrote:
> > == Summary ==
> > Up until now, the
> > [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/7331757cf12ee645e895e7e6e91d73ff66106e12/f/macros.forge
> > forge macros]
> > have been part of {{package|redhat-rpm-config}}.
> > We will split them out into a new `forge-srpm-macros` package.
> > We will add more test coverage and add a new `%forgeversion` macro to allow
> > adding snapshot info to Version instead of Release.
>
> Hi Max,
>
> I'm going through my post Flock, post vacation backlog. Thanks for that
> proposal. I'm an avid user of the forge macros. Let me know if I can
> help in any way making this happen.
Cool! Thanks for offering to help. Here are some potential areas people
can help with if interested :)
Helping test your packages against the new forge macros would be
very helpful. See
https://fedoraproject.org/wiki/Changes/Revitalize_Forge_Macros#How_To_Test
for instructions.
Once the Change is approved, I'll need a package review for the new
package.
Any type of docs or code contribution is also appreciated.
> PS: I'm replying directly since I haven't gone through the Discourse
> backlog yet and discussion may be taking place there.
This Change is only on the mailing list so not to worry. The other F40
changes should be on Discourse. I hope it's okay with you that I
included devel@ on the reply.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: Looking for a new (possibly better) python-argcomplete maintainer
On Wed Aug 23, 2023 at 13:00 +0200, Sandro wrote: > On 21-08-2023 13:13, Miro Hrončok wrote: > > I don't want to maintain it, but pytest uses it for tests, so I don't > > want to be retired. Is there somebody else who would take better care of > > it than I do? > > > Miro, you are way too young to "be retired". > > I'd be willing to take over maintainership of the package. As always, > co-maintainers are welcome. I maintain two of my packages on that list (fedrq and ansible-core), so I'm happy to co-maintain. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ python-devel mailing list -- python-de...@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-de...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Proposal: Revitalize Forge Macros (Self-Contained Change proposal)
(I'm announcing this myself as per https://pagure.io/fesco/issue/3051.)
https://fedoraproject.org/wiki/Changes/Revitalize_Forge_Macros
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.
== Summary ==
Up until now, the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/7331757cf12ee645e895e7e6e91d73ff66106e12/f/macros.forge
forge macros]
have been part of {{package|redhat-rpm-config}}.
We will split them out into a new `forge-srpm-macros` package.
We will add more test coverage and add a new `%forgeversion` macro to allow
adding snapshot info to Version instead of Release.
== Owner ==
* Name: [[User:gotmax23| Maxwell G]]
* Email: maxw...@gtmx.me
== Detailed Description ==
The forge macros will be removed from
{{package|redhat-rpm-config}} in favor of a standalone `forge-srpm-macros`
package.
{{package|redhat-rpm-config}} will gain a dependency on `forge-srpm-macros`.
This will ease maintenance and allow the forge macros to develop independently
of redhat-rpm-config.
This split will also allow us to address longstanding issues such as
lack of test coverage and noncompliance with the new Versioning Guidelines that
mandate putting snapshot info in Version instead of Release.
Development is under way in https://git.sr.ht/~gotmax23/forge-srpm-macros.
Maintaining the macros in a separate upstream repository enables us to have
proper CI and proper versioning and frees us from having to sync macro files
across distgit branches.
The new forge-srpm-macros project
now has support for Codeberg, nested Gitlab groups, and a new
[https://git.sr.ht/~gotmax23/forge-srpm-macros/commit/145b7fc72a31b7e547bfdd114c6c68aa56374043
`%forgeversion` macro].
There are also unit tests covering the core forge macros functionality to
prevent future regressions.
The tests have already uncovered a two year old bug in the Pagure forge
functionality!
For now, we will limit this Change to rawhide, but we may backport the
`forge-srpm-macros` package to stable Fedora releases depending on feedback
from the redhat-rpm-config maintainers and other stakeholders.
This is not a backwards incompatible Change,
so it should be safe to backport after proper testing in Rawhide.
== Feedback ==
The redhat-rpm-config maintainers have expressed that they'd prefer if the forge
macros were split into a separate project.
Other developers have expressed that the lack of regression tests makes them
hesitant to propose or accept changes to the forge macros; this Change fixes
that.
The Go SIG who makes use of {{package|go-rpm-macros}} that relies on the forge
macros is happy to see more maintenance of these macros.
The inability to get changes into the forge macros have blocked us from fixing
bugs that affect the Go macros.
== Benefit to Fedora ==
This split out will ease maintenance and allow us to address longstanding
issues in the current codebase.
== Scope ==
* Proposal owners:
** ✅ Create an upstream repository for the forge-srpm-macros project
** ✅ Prepare a PR for {{package|redhat-rpm-config}} to remove the macros and
associated forge.lua code and add a dependency on the new package:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/260
** Submit the `forge-srpm-macros` package for review
** Build `forge-srpm-macros` and the updated {{package|redhat-rpm-config}}
package in a side tag using provenpackager privileges
** Close existing PRs open against the forge macros and direct authors to the
new project
* Other developers:
** Review the {{package|redhat-rpm-config}} PR
** Preform test builds of packages that use the forge macros
* Policies and guidelines:
** ✅ Adjust the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ SourceURL
Packaging Guidelines] to recommend the new `%forgeversion` macro:
https://pagure.io/packaging-committee/pull-request/1295
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
There shouldn't be any.
The forge macros will remain in the buildroot,
and {{package|redhat-rpm-config}} will Require the new package.
== How To Test ==
There is a test Copr available that contains builds of `forge-srpm-macros`'
`main` branch.
You can use it in mock like this:
copr mock-config gotmax23/forge-srpm-macros-dev fedora-rawhide-x86_64 >
~/.config/mock/forge.cfg
fedpkg sources
# To preform a full package build
mock --spec *.spec --source . -r forge
# To build a source package only
mock --buildsrpm --spec *.spec --source . -r forge
== User Experience ==
This is a developer focussed Change.
This Change does not propose any drastic changes to the macros themselves and
does not mandate specfile changes,
so it shouldn't be too visible.
== Dependencies ==
This change requires coordination with the red
Re: %pyproject_save_files license handlers
On Sat Aug 19, 2023 at 22:13 +0200, Miro Hrončok wrote: > On 19. 08. 23 19:44, Maxwell G wrote: > > Hi Pythonistas, > > > > %pyproject_save_files automatically handles marking license files > > with %license when a build backend installs them into a package's > > dist-info directory and the License-File header is specified in the > > METADATA file. Currently, only setuptools and hatchling meet this > > criteria. Notably, poetry and flit do not support this. They will > > install license texts into the dist-info directory, but they do not add > > the License-File metadata. The License-File tag is not standardized, and > > discussion on PEP 639 which defines this standard has stalled. I believe > > relying on this feature is a problem, as if a project changes build > > systems or some other config and a packager doesn't realize, suddenly > > the license file won't be marked with %license or even worse, not > > installed at all. Since the pyproject macros read the build backend from > > pyproject.toml without packagers having to manually specify anything > > (which is generally great!), this situation seems likely to occur. > > > > Until these issues are resolved, I propose banning this in Fedora and > > requiring packagers to manually mark files with %license or at least > > adding a large warning to the Packaging Guidelines. It can be similar to > > the `'*' +auto` flags which are used by pyp2spec for automatic PyPI > > builds in Copr but not allowed in Fedora proper. > > What do y'all think? Am I missing something? > > Hey. Alternatively to banning this: what if we make %pyproject_save_files > fail > without a license? Obviously, that would be a breaking change, so it could be > opt-in first. > >%pyproject_save_files -l ... > > When used like this, no License-File header would result in an error. > > We could introduce a reverse flag -L (don't fail without a license), and have > a > discussion about changing the default later. > > The guidelines could than say something like: If there is a license file you > MUST do one of the following when using %pyproject_save_files: > > 1) use -l and don't list it in %files explicitly > 2) use -L and list it in %files explicitly > > That way, we ensure the license is packaged (and marked as %license) while > not > reducing automation. > I like -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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
F40 Proposal: Revitalize Forge Macros (Self-Contained Change proposal)
(I'm announcing this myself as per https://pagure.io/fesco/issue/3051.)
https://fedoraproject.org/wiki/Changes/Revitalize_Forge_Macros
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive community
feedback. This proposal will only be implemented if approved by the
Fedora Engineering Steering Committee.
== Summary ==
Up until now, the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/7331757cf12ee645e895e7e6e91d73ff66106e12/f/macros.forge
forge macros]
have been part of {{package|redhat-rpm-config}}.
We will split them out into a new `forge-srpm-macros` package.
We will add more test coverage and add a new `%forgeversion` macro to allow
adding snapshot info to Version instead of Release.
== Owner ==
* Name: [[User:gotmax23| Maxwell G]]
* Email: maxw...@gtmx.me
== Detailed Description ==
The forge macros will be removed from
{{package|redhat-rpm-config}} in favor of a standalone `forge-srpm-macros`
package.
{{package|redhat-rpm-config}} will gain a dependency on `forge-srpm-macros`.
This will ease maintenance and allow the forge macros to develop independently
of redhat-rpm-config.
This split will also allow us to address longstanding issues such as
lack of test coverage and noncompliance with the new Versioning Guidelines that
mandate putting snapshot info in Version instead of Release.
Development is under way in https://git.sr.ht/~gotmax23/forge-srpm-macros.
Maintaining the macros in a separate upstream repository enables us to have
proper CI and proper versioning and frees us from having to sync macro files
across distgit branches.
The new forge-srpm-macros project
now has support for Codeberg, nested Gitlab groups, and a new
[https://git.sr.ht/~gotmax23/forge-srpm-macros/commit/145b7fc72a31b7e547bfdd114c6c68aa56374043
`%forgeversion` macro].
There are also unit tests covering the core forge macros functionality to
prevent future regressions.
The tests have already uncovered a two year old bug in the Pagure forge
functionality!
For now, we will limit this Change to rawhide, but we may backport the
`forge-srpm-macros` package to stable Fedora releases depending on feedback
from the redhat-rpm-config maintainers and other stakeholders.
This is not a backwards incompatible Change,
so it should be safe to backport after proper testing in Rawhide.
== Feedback ==
The redhat-rpm-config maintainers have expressed that they'd prefer if the forge
macros were split into a separate project.
Other developers have expressed that the lack of regression tests makes them
hesitant to propose or accept changes to the forge macros; this Change fixes
that.
The Go SIG who makes use of {{package|go-rpm-macros}} that relies on the forge
macros is happy to see more maintenance of these macros.
The inability to get changes into the forge macros have blocked us from fixing
bugs that affect the Go macros.
== Benefit to Fedora ==
This split out will ease maintenance and allow us to address longstanding
issues in the current codebase.
== Scope ==
* Proposal owners:
** ✅ Create an upstream repository for the forge-srpm-macros project
** ✅ Prepare a PR for {{package|redhat-rpm-config}} to remove the macros and
associated forge.lua code and add a dependency on the new package:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/260
** Submit the `forge-srpm-macros` package for review
** Build `forge-srpm-macros` and the updated {{package|redhat-rpm-config}}
package in a side tag using provenpackager privileges
** Close existing PRs open against the forge macros and direct authors to the
new project
* Other developers:
** Review the {{package|redhat-rpm-config}} PR
** Preform test builds of packages that use the forge macros
* Policies and guidelines:
** ✅ Adjust the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ SourceURL
Packaging Guidelines] to recommend the new `%forgeversion` macro:
https://pagure.io/packaging-committee/pull-request/1295
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
There shouldn't be any.
The forge macros will remain in the buildroot,
and {{package|redhat-rpm-config}} will Require the new package.
== How To Test ==
There is a test Copr available that contains builds of `forge-srpm-macros`'
`main` branch.
You can use it in mock like this:
copr mock-config gotmax23/forge-srpm-macros-dev fedora-rawhide-x86_64 >
~/.config/mock/forge.cfg
fedpkg sources
# To preform a full package build
mock --spec *.spec --source . -r forge
# To build a source package only
mock --buildsrpm --spec *.spec --source . -r forge
== User Experience ==
This is a developer focussed Change.
This Change does not propose any drastic changes to the macros themselves and
does not mandate specfile changes,
so it shouldn't be too visible.
== Dependencies ==
This change requires coordination with the red
%pyproject_save_files license handlers
Hi Pythonistas, %pyproject_save_files automatically handles marking license files with %license when a build backend installs them into a package's dist-info directory and the License-File header is specified in the METADATA file. Currently, only setuptools and hatchling meet this criteria. Notably, poetry and flit do not support this. They will install license texts into the dist-info directory, but they do not add the License-File metadata. The License-File tag is not standardized, and discussion on PEP 639 which defines this standard has stalled. I believe relying on this feature is a problem, as if a project changes build systems or some other config and a packager doesn't realize, suddenly the license file won't be marked with %license or even worse, not installed at all. Since the pyproject macros read the build backend from pyproject.toml without packagers having to manually specify anything (which is generally great!), this situation seems likely to occur. Until these issues are resolved, I propose banning this in Fedora and requiring packagers to manually mark files with %license or at least adding a large warning to the Packaging Guidelines. It can be similar to the `'*' +auto` flags which are used by pyp2spec for automatic PyPI builds in Copr but not allowed in Fedora proper. What do y'all think? Am I missing something? -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: RPM packaging help
On Mon Aug 14, 2023 at 12:49 -0400, Andrew Heath wrote:
> Ok, I tried rebuilding on my f38 mock system with the spec and changes and
> running into some issues with the check section, I have attached a link to
> the failed section for review. If i comment out the %check section all
> builds good
You're missing a `BuildRequires: openssl` and
`%{python3_sitelib}receptor_python_worker-%{version}.dist-info/` is
missing a slash after `%{python3_sitelib}`.
Also, you should apply the feedback from the previous post to the
specfile.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: RPM packaging help
On Mon Aug 14, 2023 at 12:49 -0400, Andrew Heath wrote: > Ok, I tried rebuilding on my f38 mock system with the spec and changes and > running into some issues with the check section, I have attached a link to > the failed section for review. If i comment out the %check section all > builds good Can you please post the test specfile and SRPM so folks can actually test it? -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: RPM packaging help
On Mon Aug 14, 2023 at 12:49 +0200, Bob Mauchin wrote:
> On Sun, 13 Aug 2023, 21:39 Maxwell G, wrote:
>
> > > %build
> > > %if %{with bundled}
> > > export GO111MODULE=on
> > > export GOFLAGS=-mod=vendor
> > > %endif
> >
> > I think you can remove these GO* exports.
> >
> >
> >
> >
>
> Why though? If we vendor the stuff, wouldn't it be better to run on Go
> modules to be closer to upstream?
If you want to run in Go modules mode,
you need
-export GO111MODULE=on
+%global gomodulesmode GO111MODULE=off
Due to $SHENANIGANS, the macros ignore the value of the GO111MODULE env
var and only read from the macro.
We could probably fix this, but we'd have to make sure it doesn't break
existing packages that `export GO111MODULE` which is currently a NOOP.
> We should move all the ecosystem to go modules but ENOTIME.
Yeah...
> > > Now we need to add the Python parts. This is actually way more tricky
> > because the Python
> > > macros are not designed
> > > to work with multiple packages inside one repo. It can handles "extra"
> > packages but not
> > > independent packages.
> >
> > > We have added some logic to handle separate record files for each
> > package.
> >
> > Hmm, you shouldn't need to do that.
> >
> >
> >
> >
>
> I don't know, I think it is better to use the Python guidelines and macros
> if possible.
Yes, but redefining the macro instead of doing it manually as the
maintainers recommend for more complicated usecases doesn't accomplish
this.
> > > # Generated by go2rpm 1.9.0
> > > %bcond_without check
> > > %bcond_without bundled
> > > %bcond_without golang_library
> > > %if %{defined rhel}
> > > %bcond_without bundled
> > > %endif
> > > %if %{with bundled}
> > > %bcond_with golang_library
> > > %endif
> >
> > would be better written as
> >
> > %bcond check 1
> > %bcond bundled 1
> > %bcond golang_library %{without bundled}
> >
> >
> >
>
> I need to read the doc regarding bcond compared to bcond_without.
See
https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: RPM packaging help
On Sun Aug 13, 2023 at 11:28 -0700, Brad Smith wrote: > On Sun, Aug 13, 2023 at 9:12 AM Robert-André Mauchin > wrote: > > > > > > > I don't have an ETA on the K8S situation. > > > > Please let me know if there is anything that can be done with the > kubernetes rpms to help. The kubernetes rpms are completely separate from the unbundled golang-k8s-* packages and use bundled dependencies as far as I know. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: RPM packaging help
ng(github.com/vishvananda/netns) = 0.0.4
> Provides: bundled(golang(golang.org/x/crypto) = 0.8.0
> Provides: bundled(golang(golang.org/x/exp) = 0.0.0-20230425git47ecfdc
> Provides: bundled(golang(golang.org/x/mod) = 0.10.0
> Provides: bundled(golang(golang.org/x/net) = 0.9.0
> Provides: bundled(golang(golang.org/x/oauth2) = 0.7.0
> Provides: bundled(golang(golang.org/x/sys) = 0.8.0
> Provides: bundled(golang(golang.org/x/term) = 0.8.0
> Provides: bundled(golang(golang.org/x/text) = 0.9.0
> Provides: bundled(golang(golang.org/x/time) = 0.3.0
> Provides: bundled(golang(golang.org/x/tools) = 0.8.0
> Provides: bundled(golang(google.golang.org/appengine) = 1.6.7
> Provides: bundled(golang(google.golang.org/protobuf) = 1.30.0
> Provides: bundled(golang(gopkg.in/inf.v0) = 0.9.1
> Provides: bundled(golang(gopkg.in/yaml.v2) = 2.4.0
> Provides: bundled(golang(gopkg.in/yaml.v3) = 3.0.1
> Provides: bundled(golang(k8s.io/api) = 0.27.1
> Provides: bundled(golang(k8s.io/apimachinery) = 0.27.1
> Provides: bundled(golang(k8s.io/client-go) = 0.27.1
> Provides: bundled(golang(k8s.io/klog/v2) = 2.100.1
> Provides: bundled(golang(k8s.io/kube-openapi) = 0.0.0-20230501git8b0f38b
> Provides: bundled(golang(k8s.io/utils) = 0.0.0-20230505git9f67429
> Provides: bundled(golang(sigs.k8s.io/json) = 0.0.0-20221116gitbc3834c
> Provides: bundled(golang(sigs.k8s.io/structured-merge-diff/v4) = 4.2.3
> Provides: bundled(golang(sigs.k8s.io/yaml) = 1.3.0
> %endif
You don't need manual bundled(golang(...)) Provides in the specfile
anymore. This is handled by a generator after the build when
vendor/modules.txt is marked with %license in %files. This specfile
already does that.
> %build
> %if %{with bundled}
> export GO111MODULE=on
> export GOFLAGS=-mod=vendor
> %endif
I think you can remove these GO* exports.
> Now we need to add the Python parts. This is actually way more tricky because
> the Python
> macros are not designed
> to work with multiple packages inside one repo. It can handles "extra"
> packages but not
> independent packages.
> We have added some logic to handle separate record files for each package.
Hmm, you shouldn't need to do that.
> # Generated by go2rpm 1.9.0
> %bcond_without check
> %bcond_without bundled
> %bcond_without golang_library
> %if %{defined rhel}
> %bcond_without bundled
> %endif
> %if %{with bundled}
> %bcond_with golang_library
> %endif
would be better written as
%bcond check 1
%bcond bundled 1
%bcond golang_library %{without bundled}
After getting rid of those macro definitions:
> %package -n python3-receptorctl
> Summary:Front-end CLI and importable Python library that interacts
> with Receptor
>
> %description -n python3-receptorctl
> Receptorctl is a front-end CLI and importable Python library that interacts
> with Receptor over its control socket interface.
This package should be named receptorctl not python3-receptorctl.
Change `-n python3-receptorctl` to `-n receptorctl` everywhere.
> %pyproject_save_files receptorctl
> %pyproject_save_files receptor_python_worker
> %global receptorctl_pyproject_files
> %{_builddir}/%{_pyproject_files_prefix}-receptorctl-pyproject-files
> %global receptor_python_worker_pyproject_files
> %{_builddir}/%{_pyproject_files_prefix}-receptor_python_worker-pyproject-files
Remove all of this %pyproject_save_files stuff. You can handle it
manually instead of using the macros.
Change
> %files -n python3-receptorctl -f %{receptorctl_pyproject_files}
> %doc README-receptorctl.md
> %{_bindir}/receptorctl
to
%files -n receptorctl
%doc README-receptorctl.md
%{_bindir}/receptorctl
%{python3_sitelib}/receptorctl/
%{python3_sitelib}/receptorctl-%{version}.dist-info/
and change
> %files -n python3-receptor-python-worker -f
> %{receptor_python_worker_pyproject_files}
> %doc README-receptor-python-worker.md
> %{_bindir}/receptor-python-worker
to
%files -n python3-receptor-python-worker
%doc README-receptor-python-worker.md
%{_bindir}/receptor-python-worker
%{python3_sitelib}/receptor_python_worker/
%{python3_sitelib}receptor_python_worker-%{version}.dist-info/
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: RPM packaging help
Hi Robert-André and Andrew,
On Fri Aug 11, 2023 at 06:47 +0200, Robert-André Mauchin wrote:
> On 8/10/23 15:43, Andrew Heath wrote:
> > All,
> > My name is Andrew, and I have been working with the Fedora Infra team and
> > we are trying to
> > create some RPMs for some projects that we are working on, one of the RPMs
> > we need to create
> > is for the Ansible receptor[1 <https://github.com/ansible/receptor>]. I
> > have a copy of the
> > spec file from downstream Red Hat that gives some guidance but where its a
> > mix of python and
> > go-lang I was wondering if I could have some guidance from more experienced
> > packers on how
> > to package up the application correctly so that we can get the package in
> > use for the Fedora
> > Infra.
> >
> > Links:
> > [1]: https://github.com/ansible/receptor
> > <https://github.com/ansible/receptor>
> >
> > --
> > Sincerely,
> > Andrew Heath
> > aheath1...@gmail.com <mailto:aheath1...@gmail.com>
>
> Hello,
>
> Is the final package for RHEL or Fedora? There are different guidelines
> regarding bundling I
> believe.
I would follow the Go Packaging Guidelines and use unbundled deps if
possible. If there are too many unpackaged dependencies or you run into
broken packages or other issues, I'd go with vendoring. I and others at
Flock discussed using more vendoring for Go packages given the
unmaintainable large stack of Go library packages and the outdated
and/or broken state of many of them.
> The first issue I see is that there are two separate Python project in two
> subdirectories.
> Not sure how to handle that.
>
> Could you share the dowstream?
https://fedorapeople.org/~gotmax23/receptor-1.4.1-1.el9ap.src/
This specfile does not use the modern Pyproject Python macros nor the
modern Go macros. It doesn't have an SPDX license identifier either.
The way it does vendoring is a problem, as it provides no instructions
to regenerate the archive with `go mod vendor`.
I believe Yaakov Selkowitz wrote a good script for this (I remember
asking him to provide one when reviewing a "vendor dependencies for X"
PR for an ELN package), but I can't seem to find it :(.
The vendor archive should contain %{version} in its name so that it's
tied to the main archive.
The specfile should have `%license vendor/modules.txt` so that the
go_mod_vendor generator can create the appropriate `bundled()` Provides.
The License field needs to account for the licenses of the bundled
libraries.
Overall, this is a complicated project and perhaps not the best for
someone new to RPM packaging. I grimaced when I first saw Go and Python
mixed together in the repository. I would suggest starting with
something like ansible-builder and ansible-navigator or other more
straightforward parts of the AWX/AAP stack and move on to this.
That said, I'm happy to answer any potential questions as best as I can.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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 CFP: Language SIGs discussion
On Wed Jul 26, 2023 at 14:09 +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 05, 2023 at 01:39:47PM +0200, Fabio Valentini wrote: > > On Wed, Jul 5, 2023 at 8:23 AM Jens-Ulrik Petersen > > wrote: > > > > > > I have submitted a Flock proposal to have a common discussion session for > > > (modern) Language SIGs. I think for this to be successful we need > > > representatives from various Language SIGs to be there (Rust, Haskell, > > > OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX > > > come to mind immediately - surely there are more). Language packaging > > > experts are also welcome of course independently or affiliated to one or > > > more language SIGs. Of course I also hope there will be broad attendance > > > by interested contributors. > > > > This is a great idea, but I don't think any Rust SIG members will be > > at Flock this year :( > > I'll be there and I hope to join the session. I wanted to be there to talk about Changes/Mass_Retire_Golang_Leaves and some of the other work we've been doing in the Go SIG to clean up our packages, as I think it'd be useful to other SIGs, but I'll only be at Flock the last two days :(. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: DNF5-5.0.1 has a stable API
2023-07-19T13:39:57Z Peter Robinson : On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella wrote: Hi all, Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This update makes DNF5's API stable. This means that changes to the API won't happen in stable Fedora releases. How compatible is this API with the old dnf4 API? The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's not at all compatible. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedora-review workarounds for dnf5
On Tue Jul 18, 2023 at 15:27 +0200, Fabio Valentini wrote: > On Tue, Jul 18, 2023, 15:22 Maxwell G wrote: > > > On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote: > > > Hello Jerry, > > > I proposed a workaround a few days ago > > > https://pagure.io/FedoraReview/pull-request/485 > > > > > > but your patch looks like a proper fix. I'll try it and merge to the > > > fedora-review codebase. > > > > > > Does anybody know what was the purpose of --resolve and if it will be > > > no problem when we remove it? > > > > --requires --resolve resolves the entire dependency tree of a package. > > --requires just prints the direct dependencies that are specified in the > > RPM metadata. > > I don't know what this code is used for, > > but I don't think simply removing --resolve is the right solution. > > > > Is it though? I assume you're thinking of "--recursive". As far as I know, > "--requires --resolve" force resolution of virtual provides instead. I > don't think removing "--resolve" is the correct solution for this case. > > For example, the check if a package depends on something that's deprecated > (i.e. "Provides: deprecated ()") would need to resolve and check the actual > package dependencies, not only virtual provides. > > Fabio Indeed. You're right! -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedora-scm-requests email
On Tue Jul 18, 2023 at 13:47 +0200, Fabio Valentini wrote: > On Tue, Jul 18, 2023 at 4:38 AM Maxwell G wrote: > > > > Hi, > > > > It seems the fedora-scm-requests processor is creating the initial > > repository commits with `releng bot ` as the > > committer. Does anyone know where this is coming from? Should it be > > changed to something @fedoraproject.org? > > Yeah this is really weird, I see it now in my packages too ... > Earliest package created by releng-bot I could find quickly: > https://src.fedoraproject.org/rpms/rust-pyo3_0.15/c/fc77732c9f43bc7d472ae1c7de15bf9f90e2b730?branch=rawhide > > So indeed seems to have been this way since the start. Yeah, I also noticed this from the beginning and found it strange. I requested some packages yesterday, and it occurred to me that maybe this wasn't intentional and I should report it :). -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedora-review workarounds for dnf5
On Tue Jul 18, 2023 at 12:38 +0200, Jakub Kadlcik wrote: > Hello Jerry, > I proposed a workaround a few days ago > https://pagure.io/FedoraReview/pull-request/485 > > but your patch looks like a proper fix. I'll try it and merge to the > fedora-review codebase. > > Does anybody know what was the purpose of --resolve and if it will be > no problem when we remove it? --requires --resolve resolves the entire dependency tree of a package. --requires just prints the direct dependencies that are specified in the RPM metadata. I don't know what this code is used for, but I don't think simply removing --resolve is the right solution. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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
fedora-scm-requests email
Hi, It seems the fedora-scm-requests processor is creating the initial repository commits with `releng bot ` as the committer. Does anyone know where this is coming from? Should it be changed to something @fedoraproject.org? -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: Remove forum email notification delay
On Fri Jul 7, 2023 at 15:56 +, Maxwell G wrote: > Hi, > > Can the configured 5 minute delay between forum posting and email > notifications going out be turned off? > It disadvantages users who participate via email and is an unwelcome > diversion from the way the mailing lists work. s/diversion/divergence/ -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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
Remove forum email notification delay
Hi, Can the configured 5 minute delay between forum posting and email notifications going out be turned off? It disadvantages users who participate via email and is an unwelcome diversion from the way the mailing lists work. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu Jul 6, 2023 at 20:17 CDT, Michael Catanzaro wrote: > I'm attaching a screenshot to give an idea of what this would look like > in gnome-initial-setup. I don't have a gnome-control-center screenshot > handy, but it would be similar, except there it would default to off. I don't see an attachment. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu Jul 6, 2023 at 14:32 CDT, Michael Catanzaro wrote: > > On Thu, Jul 6 2023 at 08:19:07 PM +0200, Vitaly Zaitsev via devel > wrote: > > All telemetry collection MUST be an opt-in feature (disabled by > > default). I'm strongly against enabling it by default. > > As explained in the proposal document, we know that opt-in metrics are > not very useful because few users would opt in, and these users would > not be representative of Fedora users as a whole. We are not interested > in opt-in metrics. Opt-out telemetry isn't going to be representative of the whole community either. Privacy concious users are going to opt out, and then their voices won't be heard. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On Wed Jul 5, 2023 at 00:50 +0200, Sandro wrote:
> On 05-07-2023 00:06, Maxwell G wrote:
> > On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote:
> >
> >> I see one of my packages, python-fvs, in the list of failed builds. I'm
> >> also one of the maintainers of Bottles, which requires python-fvs.
> >> Bottles itself is mostly Python code. I would have expected Bottles to
> >> be rebuild as well. With python-fvs failing, Bottles should fail to
> >> install.
> >>
> >> But bottles never received the 'Rebuilt for Python 3.12' commit. Most
> >> interestingly, neither did python-fvs. But it is on the list of failed
> >> builds.
> >
> > AFAIK, the rebuild scripts only rebuild packages whose dependencies are
> > available. python-fvs depends on python3-orjson which fails to build
> > with Python 3.12. Its tests segfault. I opened [1] upstream. bottles
> > then depends on python3-fvs so that wasn't rebuilt either.
>
> So, python-fvs fails to build solely because python-orjson is not
> available. And that is determined before the package is even build.
> Smart! ;)
> Albeit, it's a bit misleading, since the package wasn't really build. I
> was interested to learn why python-fvs failed to build. That's why I
> went looking for the build.
Yeah. Technically, it does fail to build from source (if you tried to
build it, it would fail at the dnf builddep stage). It's a bit
counterintuitive, but it makes more sense that wasting koji resources to
rebuild something that you know will fail.
> But what about Bottles? It was never built in f39-python either and
> python-fvs is not a build requirement for Bottles, only a runtime
> requirement. Does that also exclude it from being build in the side-tag?
Ah, I was not entirely correct. Looking more closely, bottles doesn't
depend on python(abi) at runtime (i.e. it doesn't install any files into
%{python3_sitelib} and/or %{python3_sitearch}) or link to libpython, so
it isn't part of the rebuild to begin with. It just depends on
/usr/bin/python3. That package does some kooky mason stuff instead of
using standard Python packaging tools, and it isn't tied to a specific
python version. It will FTI once the side tag is merged if python-orjson
and python-fvs aren't built, though.
> Sorry, if all that is obvious to experienced packagers. It's the first
> time for me that I'm going through a mass rebuild as a package maintainer.
Nah, Python mass rebuilds are a pretty special event :).
Tomáš and Miro gave a good talk about the process at Nest if you're
curious: https://www.youtube.com/watch?v=0ODrMrYnDYs
--
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote: > I see one of my packages, python-fvs, in the list of failed builds. I'm > also one of the maintainers of Bottles, which requires python-fvs. > Bottles itself is mostly Python code. I would have expected Bottles to > be rebuild as well. With python-fvs failing, Bottles should fail to install. > > But bottles never received the 'Rebuilt for Python 3.12' commit. Most > interestingly, neither did python-fvs. But it is on the list of failed > builds. AFAIK, the rebuild scripts only rebuild packages whose dependencies are available. python-fvs depends on python3-orjson which fails to build with Python 3.12. Its tests segfault. I opened [1] upstream. bottles then depends on python3-fvs so that wasn't rebuilt either. [1]: https://github.com/ijl/orjson/issues/400 -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead. The package has `Provides: deprecated()` so that cannot be done without violating policy. python-IPy kevin https://src.fedoraproject.org/rpms/python-IPy/pull-request/1 python-chai kevin pingou https://src.fedoraproject.org/rpms/python-chai/pull-request/3 -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead. The package has `Provides: deprecated()` so that cannot be done without violating policy. python-IPy kevin https://src.fedoraproject.org/rpms/python-IPy/pull-request/1 python-chai kevin pingou https://src.fedoraproject.org/rpms/python-chai/pull-request/3 -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: ELN: Mass-rebuild has started
On Mon Jun 26, 2023 at 17:19 -0400, Stephen Gallagher wrote: > On Mon, Jun 26, 2023 at 5:08 PM Maxwell G wrote: > > > > 2023-06-26T20:21:06Z Stephen Gallagher : > > > > > Just a heads-up that we've begun the targeted mass-rebuild for Fedora > > > ELN. It's running in Koji's "background" priority, so it should > > > hopefully not significantly impact other builds. My estimate is that > > > it will be running for about the next two days, followed up by manual > > > rebuilds for flaky tests/network hiccoughs, etc. > > > > Is that going to conflict with the ongoing Python 3.12 rebuild? > > It should not. I triggered the builds from the git hash of whatever > was current in the `eln` tag. Ah, do you just bump the eln disttag and not touch packages' Release fields and changelogs at all? -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: ELN: Mass-rebuild has started
2023-06-26T20:21:06Z Stephen Gallagher : Just a heads-up that we've begun the targeted mass-rebuild for Fedora ELN. It's running in Koji's "background" priority, so it should hopefully not significantly impact other builds. My estimate is that it will be running for about the next two days, followed up by manual rebuilds for flaky tests/network hiccoughs, etc. Is that going to conflict with the ongoing Python 3.12 rebuild? -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: SIG proposal: Multimedia SIG
On Mon Jun 19, 2023 at 22:20 +0100, Philip Wyett wrote: > On Mon, 2023-06-19 at 21:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hello! > > > > With the growing number of multimedia packages in Fedora, mostly owing > > to the introduction of ffmpeg package and Legal permission to enable > > and ship many popular codecs, I think we've reached the critical mass of > > packages and maintainers that warrants the creation of a Multimedia SIG. > > > > I propose, similar to the recently established LibreOffice SIG, to > > create a FAS group, Bugzilla account and a private mailing list. > > > > Private mailing list? No part of this project should have private anything > IMHO. This is how all Fedora packaging SIGs work. They have a private mailing list that's only used for Bugzilla notifications that may contain private bugs with sensitive information, and then everything else is handled over standard, public channels. Using the Python SIG as an example: - python-de...@lists.fedoraproject.org -> Public discussion list - python-packagers-...@lists.fedoraproject.org -> List used for the Bugzilla account and nothing else. Only open to members of the @python-packagers-sig FAS group. - #python:fedoraproject.org / #fedora-python -> Synchronous communication -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: HEADS UP: RPM 4.19 soname bump in Rawhide
On Fri May 19, 2023 at 22:59 +0200, Michal Domonkos wrote:
> On Fri, May 19, 2023 at 05:37:06PM +0100, Richard W.M. Jones wrote:
> > Nevertheless I do believe if the librpm changed its API then every
> > package which _BuildRequires_ rpm-devel should be rebuilt, just to
> > check the change doesn't affect them.
>
> Yes, we were primarily focusing on runtime dependencies now so that Rawhide
> isn't broken when the side-tag is pushed, however any API incompatibility in
> the packages that BuildRequire rpm-devel would just be pushed back to the
> earliest moment they're rebuilt in Rawhide by their maintainers.
>
> So I also think that ideally we should try rebuilding those ourselves to
> identify potential issues while 4.19 is not yet in Rawhide.
>
> I'll talk to my team on Monday, we'll perhaps do just that. A quick check
> with
>
> dnf repoquery --release=rawhide --disablerepo="*" --enablerepo="*-source"
> \
> --arch=src --whatrequires rpm-devel
>
> shows a couple of additional packages that weren't covered in this thread so
> far
I guess I'll plug fedrq [1] here, as this type of situation (a long
thread about how to properly use dnf repoquery to find reverse
dependencies) is one of my motivations for writing that tool :).
If you're looking for any package that requires (any virtual provide) of
rpm-libs or rpm-devel at buildtime or runtime, this query will get you
there:
$ fedrq wr -X -F source rpm-devel rpm-libs
...
The `-F source` option prints out a single deduplicated list of source
package name. If a package in the final query is a source package, the
`source` formatter spits out the package {NAME} and if the package is a
binary RPM, it spits out the package's {SOURCE_NAME}.
`-X` is short for `--exclude-subpackages` and will make sure rpm itself
doesn't show up in the output ;).
You can pass `-b rawhide` to explicitly query the rawhide repositories,
but that's already the default (unless you change it in the config file).
fedrq of course supports the .so name based queries, but I think it's
much better to unintentionally rebuild a couple packages that don't
*need* to be rebuilt and potentially find an FTBFS in advanced than to
unintentionally miss something.
[1] https://fedrq.gtmx.me/
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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] Ansible in EPEL 8
Hello EPEL users and developers, RHEL 8.8 was released yesterday, so I have updated ansible in EPEL 8 from 6.3.0 to 7.2.0 to match RHEL 8.8's ansible-core bump from 2.13.3 to 2.14.2. Each ansible major version is tied to a specific major version of ansible-core, and we keep them in sync. Along with this change, RHEL 8.8 builds ansible-core for the python3.11 stack instead of the python39 stack that it was previously built for. Therefore, ansible in EPEL 8 is now built for python3.11 as well. I also updated ansible-collection-community-general to 7.0.0 as per the discussions in [1]. Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ca07fe358c Please help test and give karma. Until this update is pushed to stable, you may receive an error like this when running dnf upgrade ``` Error: Problem: package ansible-6.3.0-2.el8.1.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed - cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-2.el8_7.x86_64 - cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-1.el8.x86_64 - cannot install the best update candidate for package ansible-core-2.13.3-2.el8_7.x86_64 - cannot install the best update candidate for package ansible-6.3.0-2.el8.1.noarch (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ``` There are a couple potential solutions: 1. Run $ dnf upgrade --exclude ansible-core to skip ansible-core and upgrade everything else. 2. Later today or tomorrow, you'll be able to install ansible 7.2.0 from testing with $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core and then run a plain `dnf upgrade` as usual. Note that EPEL tracks RHEL and not rebuilds. Some rebuilds may lag behind RHEL and not yet have 8.8 content. Our goal is to get packages out as soon as possible so we don't break updates for RHEL users. [1] https://lists.fedoraproject.org/archives/search?q=A+coordinated+plan+for+ansible-collection+updates+in+EPEL%3F=1=epel-devel%40lists.fedoraproject.orgÚte-asc -- Happy automating, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: [EPEL-devel] Re: python3.11-rpm to EPEL 9
On Tue May 16, 2023 at 11:04 +0200, Miro Hrončok wrote:
> On 15. 05. 23 16:49, Maxwell G wrote:
> > On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
> >> Hello,
> >>
> >> I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
> >>
> >> See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
> >
> > Cool!
> >
> >> I decided to reuse the python3-rpm component (currently epel7 only). Let me
> >> know if I should not.
> >
> > Are we able to build for multiple Python versions out of the same
> > specfile?
>
> It's possible, but it's not nice.
>
> In principle, this works:
>
>%build
>%define py3x_build() %{global python3_pkgversion %1}%py3_build
>%py3x_build 39
>%py3x_build 3.11
>
>%install
>%define py3x_install() %{global python3_pkgversion %1}%py3_install
>%py3x_install 39
>%py3x_install 3.11
>
> But with a project like RPM, we might need to run configure multiple times as
> well and create separate working directories. Will need to check.
Yeah, that could work,
but I'd change %{global python3_pkgversion %1} to
%{define python3_pkgversion %1} in the py3x_* macro definitions so you
only change the definition of %python3_pkgversion within those macros'
scopes.
> > Unless there's some other way to work around this, I'd use a
> > python3.11-rpm or python3.11-rpm-epel component like we've been doing
> > for the other alt python stacks in RHEL 8.
>
> I consider the "not nice" way easier, as it will only require to keep one
> package synced with c8s rpm, and not many. Will try to hack it up and show
> how
> it looks like.
I tend to agree. Syncing packages with RHEL and CentOS Stream is
difficult and tedious so better to limit the amount of times you have to
do it. Carl's new EPEL 10 proposal will hopefully with this.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: PyPI name blocking request for vkbasalt-cli
On Tue May 16, 2023 at 13:15 +0200, Sandro wrote: > Did I misunderstand/misinterpret the guidelines? The review is currently > stalled due to the PyPI parity issue. > > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2188653 I didn't mean to hold up the package on this. It should be fixed, but I don't consider this issue a blocker. I just didn't have time to complete a full review myself , so I left a drive by comment and didn't assign it to myself or set the fedora-review? flag. I'll try to take a look later. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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] Re: python3.11-rpm to EPEL 9
On Tue May 16, 2023 at 11:04 +0200, Miro Hrončok wrote:
> On 15. 05. 23 16:49, Maxwell G wrote:
> > On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
> >> Hello,
> >>
> >> I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
> >>
> >> See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
> >
> > Cool!
> >
> >> I decided to reuse the python3-rpm component (currently epel7 only). Let me
> >> know if I should not.
> >
> > Are we able to build for multiple Python versions out of the same
> > specfile?
>
> It's possible, but it's not nice.
>
> In principle, this works:
>
>%build
>%define py3x_build() %{global python3_pkgversion %1}%py3_build
>%py3x_build 39
>%py3x_build 3.11
>
>%install
>%define py3x_install() %{global python3_pkgversion %1}%py3_install
>%py3x_install 39
>%py3x_install 3.11
>
> But with a project like RPM, we might need to run configure multiple times as
> well and create separate working directories. Will need to check.
Yeah, that could work,
but I'd change %{global python3_pkgversion %1} to
%{define python3_pkgversion %1} in the py3x_* macro definitions so you
only change the definition of %python3_pkgversion within those macros'
scopes.
> > Unless there's some other way to work around this, I'd use a
> > python3.11-rpm or python3.11-rpm-epel component like we've been doing
> > for the other alt python stacks in RHEL 8.
>
> I consider the "not nice" way easier, as it will only require to keep one
> package synced with c8s rpm, and not many. Will try to hack it up and show
> how
> it looks like.
I tend to agree. Syncing packages with RHEL and CentOS Stream is
difficult and tedious so better to limit the amount of times you have to
do it. Carl's new EPEL 10 proposal will hopefully with this.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: python3.11-rpm to EPEL 9
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote: > Hello, > > I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next. > > See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4. Cool! > I decided to reuse the python3-rpm component (currently epel7 only). Let me > know if I should not. Are we able to build for multiple Python versions out of the same specfile? That PR has: ``` + # We'll build python3.11-rpm only for now + # Once a new Python version is added, + # the spec will need to change to support multiple Pythons anyway + %global python3_pkgversion 3.11 ``` but I thought we got rid of the %py3_other_* stuff that allowed building for multiple Python versions out of the same specfile. Unless there's some other way to work around this, I'd use a python3.11-rpm or python3.11-rpm-epel component like we've been doing for the other alt python stacks in RHEL 8. > If there is a significant demand, I can try add this (and python39-rpm) to > EPEL > 8 as well. As I said on IRC, I'd like that for fedrq. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: [EPEL-devel] python3.11-rpm to EPEL 9
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote: > Hello, > > I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next. > > See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4. Cool! > I decided to reuse the python3-rpm component (currently epel7 only). Let me > know if I should not. Are we able to build for multiple Python versions out of the same specfile? That PR has: ``` + # We'll build python3.11-rpm only for now + # Once a new Python version is added, + # the spec will need to change to support multiple Pythons anyway + %global python3_pkgversion 3.11 ``` but I thought we got rid of the %py3_other_* stuff that allowed building for multiple Python versions out of the same specfile. Unless there's some other way to work around this, I'd use a python3.11-rpm or python3.11-rpm-epel component like we've been doing for the other alt python stacks in RHEL 8. > If there is a significant demand, I can try add this (and python39-rpm) to > EPEL > 8 as well. As I said on IRC, I'd like that for fedrq. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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] Re: Upcoming removal of rust2rpm + major Rust packaging toolchain update for EPEL 9
We have submitted the new Rust packaging toolchain to EPEL 9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-fecd6bbae1 Please help test and provide karma. This update has been in epel9-next for a couple months now, but we can push it to epel9 now that RHEL 9.2 that contains python3.11 is GA. See below for the original announcement. On Sun Feb 26, 2023 at 16:31 +0100, Fabio Valentini wrote: > Hello EPEL packagers, > > The latest version of the Rust packaging toolchain will soon be > available for EPEL 9 (i.e. rust2rpm v24, rust-packaging v24, and > cargo2rpm v0.1). This is a major upgrade from rust2rpm v21 which is > currently in EPEL 9, but also comes with the drawback that it now > requires Python >= 3.10. > > However, I have split the Rust packaging tools into three separate > projects (previously everything was in a monorepo) to make packaging > them easier: > > The two components which are needed at build-time (RPM macros + the > cargo2rpm Python module that powers them) can still be built for EPEL > 9, as cargo2rpm has no third-party dependencies and only needs Python > >= 3.10, and will hence be built with python3.11 on EPEL 9 as soon as > that is available. > > The spec generator (rust2rpm) has also been split off from > rust-packaging into a separate package, which will *not* be available > on EPEL 9. rust2rpm requires Python >= 3.10, but it also has a few > non-trivial third-party dependencies (most notably, jinja2). Since > most Rust packagers primarily work on Fedora, I don't think the effort > of packaging all missing dependencies for Python 3.11 just to make > /usr/bin/rust2rpm available for EPEL 9 would be worth it. > > There are three Pull Requests which will implement this update: > https://src.fedoraproject.org/rpms/cargo2rpm/pull-request/1 > https://src.fedoraproject.org/rpms/rust-packaging/pull-request/6 > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/65 > (kudos to @gotmax23!) > > These changes (i.e. rust-packaging v24 + cargo2rpm) have now been live > in "production" in Fedora for over a week, and based on user and CI > feedback, I expect these updates to cause no regressions on EPEL 9. > > Fabio > ___ > epel-announce mailing list -- epel-annou...@lists.fedoraproject.org > To unsubscribe send an email to epel-announce-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-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ > 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 -- Happy packaging, Maxwell G (@gotmax23) Pronouns: He/They ___ 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] Ansible in EPEL 9
Hello EPEL users and developers, RHEL 9.2 was released today, so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL 9.2's ansible-core bump from 2.13.3 to 2.14.2. Each ansible major version is tied to a specific major version of ansible-core, and we keep them in sync. Along with this change, RHEL 9.2 builds ansible-core for the python3.11 stack instead of the default python3 (3.9) stack. Therefore, ansible in EPEL now built for python3.11 as well. Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1 Please help test and give karma. Until this update is pushed to stable, you may receive an error like this when running dnf upgrade ``` Error: Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed - cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-2.el9_1.x86_64 - cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-1.el9.x86_64 - cannot install the best update candidate for package ansible-core-2.13.3-2.el9_1.x86_64 - cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ``` There are a couple potential solutions: 1. Run $ dnf upgrade --exclude ansible-core to skip ansible-core and upgrade everything else. 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install ansible 7.2.0 from testing with $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core and then run a plain `dnf upgrade` as usual. -- Happy automating, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: changing the name of a package
On Sat May 6, 2023 at 16:38 +0200, Sandro wrote: > On 06-05-2023 16:29, Globe Trotter via devel wrote: > > sudo fedrq whatrequires python-PyPDF2 > > > > does not list pdf-stapler as a reverse dependency, however it does > > include python3-staplelib which is part of the pdf-stapler > > packaging. > > It lists python3-staplelib for me: > > fedrq wr python3-PyPDF2 > pdfposter-0.7.post1-16.fc38.noarch > python-mapnik-3.0.23-23.20200224git7da019c.fc39.src > python3-krop-0.5.1-16.fc38.noarch > python3-staplelib-1.0.0-0.13.20191215git8753251.fc38.noarch You can use `fedrq whatrequires` with the `-F source` option to get the names of the source packages. ``` $ fedrq wr -F source python3-PyPDF2 pdfposter python-mapnik krop pdf-stapler ``` The maintainer emails are , so you'd need to email ``` $ fedrq wr -F source python3-PyPDF2 | sed 's|$|-maintain...@fedoraproject.org|' pdfposter-maintain...@fedoraproject.org python-mapnik-maintain...@fedoraproject.org krop-maintain...@fedoraproject.org pdf-stapler-maintain...@fedoraproject.org ``` to get in contact with them. -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: It’s time to transform the Fedora devel list into something new
On Wed Apr 26, 2023 at 18:04 +0200, Vitaly Zaitsev via devel wrote: > On 20/04/2023 23:20, Matthew Miller wrote: > > It’s time to transform the Fedora devel list into something new > > I think such serious questions should be put to a vote. Not a FESCo > vote, but a vote for all Fedora contributors (can be combined with the > next FESCo elections). I think having this as a "ballot referendum" of sorts is a good idea. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: It’s time to transform the Fedora devel list into something new
I think we'd miss with fractured forum categories. > Enter Discourse > --- > > If you’ve talked with me about anything related to any of this in the > past ten years, you probably already know that I like Discourse. It’s > good software made by cool people. And, it’s entirely open source, with > a SaaS business model but with real, usable releases. (No open core, no > “open source theoretically but good luck”.) I definitely appreciate that it's fully open source. This is more than I can say about other tools we're trying to move towards such as Gitlab. > And, we have it in production in Fedora already, at > https://discussion.fedoraproject.org, with categories for > announcements, user help, project discussion, and social > conversation — as well as special categories for dedicated workflows. Thank you for the work you put in to organizing and setting this up. > In Project Discussion, each different Fedora team can have its own tag, > and you can subscribe to those that you’re interested in. Cross-posting > is easy: tag a post with multiple teams. Are there measures in place to avoid tag sprawl that makes it difficult to keep an eye on everything and subscribe? > Topics can be renamed, if needed, or split out into side-conversations. > The long tangents from these conversations can actually be interesting > on their own without distracting from the main topic. Moderation tools > allow us to handle posts that are outside of expected Fedora > contributor behavior, with varying levels of action as appropriate. That is nice side effect of having a centralized platform. Of course, it can't solve problematic behavior, but it's nice to know that there's mitigation in place. It's just a question of whether these tools are used effectively and fairly and not excessively. I think I trust y'all to do that :). Still, I'd hope it's possible to improve moderation and encourage healthy dialogue without kludges. > You can use markdown formatting, including images (with easy addition > of alt text for people for whom images are a barrier). You can edit > your posts to fix typos or correct mistakes. There are polls and lots > of other useful features. These are definitely nice to have. I will note that these are incompatible with plain text email notifications which many here appreciate. > And, you can interact with it all by email. That interface isn’t > perfect, but it’s way better than any other forum software I’ve seen. > (I’ve written a guide: https://discussion.fedoraproject.org/t/25960) > At the same time, your individual email address is hidden, so it won’t > be a spam magnet (or a target for off-list harassment, a problem we > unfortunately have with devel list). Yeah, I'm not sure the email interface is really comparable to the ML experience. You can't post directly via email without the whole moderation queue thing mentioned in your linked post. Email interaction seems to be a second class citizen. I'm not sure what the point in moving off the mailing list is if you keep suggesting ways that people can make forum software behave more like the mailing list that we already have. > That said, it is web-first software. (Or mobile, if that’s your thing.) > That requires some adjustment, I know. I hope opening up a Fedora > Discussion tab – or keeping one open — becomes an easy habit. I wouldn't like that much. The only tab I always have open is Matrix, and I'd prefer not to have to have more always open browser tabs. I already have an email client. > Not just Fedora > --- > > There’s a big trend towards Discourse in open source projects overall. > Python and Gnome have both migrated entirely from their mailing lists. > Ansible is working on it. Ansible's mailing lists have been mostly announcements for a while. The plan is to move discussions and announcements away from various Github issue trackers and Github Discussions in various organizations into a central place. Fedora's level of mailing list usage and participation is significantly larger. > Plus, there’s Rust, Kubernetes, Nextcloud, > Flathub, Grafana, Home Assistant, KDE, and I’m sure many others. I'd argue that this is a type of fragmentation. Each has its own site that users have to separately sign up for and follow. > Concrete proposal > - While I think it makes sense for new teams to consider adopting the forums instead of mailing lists, I am not convinced that we should shut down devel@ and alienate the _current_ devs who seem to favor the current approach. Thanks for listening, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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
python-orjson Review Swap
Hi everyone, I'm looking for a review swap for python-orjson [1], preferably something in Go or Python. This package is needed by newer versions of bottles and is starting to be used by other Python projects as well. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2184237 -- Thanks, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedrq - new repoquerying tool
On Sun Feb 12, 2023 at 05:31 +, Maxwell G wrote: > Hi Fedorians, > > I've been working on a repoquerying tool called fedrq [1] that I'd > like to share with you. Here's the elevator pitch: fedrq provides a > friendly interface to query the Fedora repositories. It makes it > really easy to query across Fedora and EPEL branches. > > [1] https://fedrq.gtmx.me I've submitted fedrq for Fedora inclusion and it was pushed to updates a couple days ago [1]. Thanks to Benson for reviewing it! Since last time, there's been quite a few changes. fedrq now supports both dnf and libdnf5. Commands produce (mostly) the same output between the two backends. I reimplemented hawkey's Package sort algorithm in fedrq's libdnf5 backend. fedrq's API [3] exposes its inbuilt repository definitions and abstraction/compatibility layer over the libdnf5 and dnf package Query APIs. fedrq's CLI interface has also gained new functionality. There's new whatrequires-src and whatobsoletes subco mmands, there's --forcearch support, there's more output formatting options, and there more flexible repository selection. I also added a doc explaining the differences between fedrq and dnf repoquery [4]. [1] https://bodhi.fedoraproject.org/updates/?search=fedrq-0.5.0 [2] https://pagure.io/GoSIG/go-leaves [3] https://fedrq.gtmx.me/API/Summary [4] https://fedrq.gtmx.me/dnf-repoquery-diff -- Best, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
On Mon Mar 27, 2023 at 07:27 -0700, Kevin Fenzi wrote: > On Mon, Mar 27, 2023 at 11:57:04AM -, Aleš Matěj wrote: > > However you are right dnf can't handle that. It looks for deltas in the > > same repo where it finds > > the normal update package. It would require changes in dnf and libdnf. > > ok. Thanks for the info. > > If we want to bring drpms back to useful, I think this would probibly be the > best way to go. Then we could have some app that creates them async and > dnf could use them if available. > > kevin Can you or someone else more familiar with DRPMs than I file a dnf5 RFE? https://github.com/rpm-software-management/dnf5/issues/new -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: Go leaves will be mass retired in one month
Hi,
I will stop accepting opt-outs from the mass retirement at the end of
this week and proceed with the next steps. If you are one of the
maintainers below, please double check the leaves list. Let me know if
you see any errors. Follow the steps below if you need any of the leaf
packages as a dependency for a project you're working on packaging or
have another valid reason to opt out a package.
Thanks!
On Sat Feb 18, 2023 at 21:01 +, Maxwell G wrote:
> Hi Fedorians,
>
> Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As
> part of this Change, all Go library packages that are leaves will be be
> mass retired and removed from the Fedora 39 repositories in
> approximately one month.
>
> The following maintainers/groups own, co-maintain, or watch at least one
> package that we have identified as a leaf:
>
> @deepinde-sig
> @go-sig
> @osbuild-sig
> agerstmayr
> anthr76
> athoscr
> atim
> carlwgeorge
> dcavalca
> dctrud
> eclipseo
> fab
> fale
> fuller
> gundersanne
> jchaloup
> jdoss
> jjelen
> laiot
> logic
> mayorga
> mgoodwin
> nathans
> obudai
> pwouters
> qulogic
> rga
> rominf
> yanqiyu
>
> I will forward this message to those users separately instead of BCCing.
> Apparently, some people have broken filters that hide any email sent to
> the ML even if it's addressed to them directly.
>
>
> See [2] for a full list of leaves and [3] for a maintainer by maintainer
> breakdown. Maintainers may opt out by cloning
> https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}`
> file with a short justification.
> Something like:
>
> ```
> git clone ssh://g...@pagure.io/GoSIG/go-leaves.git
> cd go-leaves
> echo "Dependency for foo (review bug #X)" > ./opt-out/bar
> git add ./opt-out/bar
> git commit -m "opt out bar"
> git push origin
> ```
>
> All Go SIG members have write access to this repository. Other users can
> submit a pull request. You're also welcome to file an issue and I'll
> push the file for you.
>
>
> After a month has passed, we'll remove Go SIG write access from the
> repository and stop accepting additional opt-outs. Then, we'll preform
> test builds in Copr to make sure there's no false positives in the list.
> Finally, I'll verify the results, opt out any additional false
> positives, and preform the mass retirement. As usual, anybody can
> unretire packages without a re-review within eight weeks by filing a
> releng ticket.
>
>
> [1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
> [2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves
> [3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer
>
> Thank you for your cooperation,
> --
> Maxwell G (@gotmax23)
> Pronouns: He/They
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Go leaves will be mass retired in one month
Hi,
I will stop accepting opt-outs from the mass retirement at the end of
this week and proceed with the next steps. If you are one of the
maintainers below, please double check the leaves list. Let me know if
you see any errors. Follow the steps below if you need any of the leaf
packages as a dependency for a project you're working on packaging or
have another valid reason to opt out a package.
Thanks!
On Sat Feb 18, 2023 at 21:01 +, Maxwell G wrote:
> Hi Fedorians,
>
> Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As
> part of this Change, all Go library packages that are leaves will be be
> mass retired and removed from the Fedora 39 repositories in
> approximately one month.
>
> The following maintainers/groups own, co-maintain, or watch at least one
> package that we have identified as a leaf:
>
> @deepinde-sig
> @go-sig
> @osbuild-sig
> agerstmayr
> anthr76
> athoscr
> atim
> carlwgeorge
> dcavalca
> dctrud
> eclipseo
> fab
> fale
> fuller
> gundersanne
> jchaloup
> jdoss
> jjelen
> laiot
> logic
> mayorga
> mgoodwin
> nathans
> obudai
> pwouters
> qulogic
> rga
> rominf
> yanqiyu
>
> I will forward this message to those users separately instead of BCCing.
> Apparently, some people have broken filters that hide any email sent to
> the ML even if it's addressed to them directly.
>
>
> See [2] for a full list of leaves and [3] for a maintainer by maintainer
> breakdown. Maintainers may opt out by cloning
> https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}`
> file with a short justification.
> Something like:
>
> ```
> git clone ssh://g...@pagure.io/GoSIG/go-leaves.git
> cd go-leaves
> echo "Dependency for foo (review bug #X)" > ./opt-out/bar
> git add ./opt-out/bar
> git commit -m "opt out bar"
> git push origin
> ```
>
> All Go SIG members have write access to this repository. Other users can
> submit a pull request. You're also welcome to file an issue and I'll
> push the file for you.
>
>
> After a month has passed, we'll remove Go SIG write access from the
> repository and stop accepting additional opt-outs. Then, we'll preform
> test builds in Copr to make sure there's no false positives in the list.
> Finally, I'll verify the results, opt out any additional false
> positives, and preform the mass retirement. As usual, anybody can
> unretire packages without a re-review within eight weeks by filing a
> releng ticket.
>
>
> [1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves
> [2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves
> [3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer
>
> Thank you for your cooperation,
> --
> Maxwell G (@gotmax23)
> Pronouns: He/They
___
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
