Re: Inactive packagers to be removed after the F37 release
On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson wrote: > On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: > > Hello everyone! > > > > I just completed the first run of FESCo's newly approved Inactive > > Packager Policy[1]. Packagers that have been identified as inactive > > have a ticket in the find-inactive-packagers repo[2]. One week after > > the F37 final release, packagers who remain inactive will be removed > > from the packager group. (Note that pagure.io is one of the systems > > checked for activity, so commenting on your ticket that you're still > > around will prevent you from showing up in the second round.) > > So, I have a probably-controversial idea for a follow-up on this. > I'll add one more idea/loophole to consider closing. I am a member of the packager group but no longer maintain any packages. I am active enough in other ways to not be noticed by this policy. I don't think that is right. I have submitted a ticket to voluntarily give up my packager rights under this policy. However, we should probably verify that a packager actually has at least one package or is a proven packager as a part of this policy. I realize that it is very hard to know how long someone has not had any packages, so this could result in a request to validate to a person who is temporarily without a package during the period when the script is run, however I think this is a reasonable edge case to resolve manually. regards, bex -- Don't rush to reply to this email. Enjoy work/life balance. I read email once a day and am in the CE(S)T timezone. If you have an urgent email, ping me, and consider other mediums for urgent messages in the future. Brian "bex" Exelbierd (he/him/his) Business Strategist for Communities and Developers Red Hat Enterprise Linux @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ 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: Inactive packagers to be removed after the F37 release
On 04/09/2022 19:30, Michael Catanzaro wrote: And anybody who isn't willing to buy a security key wouldn't be able to contribute to Fedora at all. So, you want to ban all contributors from countries where such tokens are prohibited, am I right? Strongly -1. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
Il 05/09/22 08:59, Brian (bex) Exelbierd ha scritto: > On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson > wrote: > >> On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: >>> Hello everyone! >>> >>> I just completed the first run of FESCo's newly approved Inactive >>> Packager Policy[1]. Packagers that have been identified as inactive >>> have a ticket in the find-inactive-packagers repo[2]. One week after >>> the F37 final release, packagers who remain inactive will be removed >>> from the packager group. (Note that pagure.io is one of the systems >>> checked for activity, so commenting on your ticket that you're still >>> around will prevent you from showing up in the second round.) >> >> So, I have a probably-controversial idea for a follow-up on this. > > I'll add one more idea/loophole to consider closing. I am a member of the > packager group but no longer maintain any packages. I am active enough in > other ways to not be noticed by this policy. I don't think that is right. I'm sorry for that. The script currently searches for user activity in src.fp.o, pagure.io, Bodhi, Bugzilla and Fedora mailing lists. Can you tell me where you're active, so, maybe, I can add that place in the search pattern? > I have submitted a ticket to voluntarily give up my packager rights under > this policy. However, we should probably verify that a packager actually has > at least one package or is a proven packager as a part of this policy. I > realize that it is very hard to know how long someone has not had any > packages, so this could result in a request to validate to a person who is > temporarily without a package during the period when the script is run, > however I think this is a reasonable edge case to resolve manually. > > regards, > > bex I don't agree with that. If a user haven't got any commit right to any package, they don't need to be in the packager group, that's exactly the scope of this policy. Maybe they left years ago, their commit rights were removed, but they never have been removed from packagers. Mattia___ 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: Inactive packagers to be removed after the F37 release
Il 05/09/22 08:55, Douglas Kosovic ha scritto: > On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga wrote: >> If anyone wants to have a look to what packages **may** be orphaned >> when those users are removed from the packager group, I've set up a >> script and uploaded the results here [1]. >> >> Do not be too scared by those results: there's still plenty of time for >> those users to show up and declare their willingness to maintain their >> status. If you, however, see a package you care listed with an asterisk >> (look at the bottom of the list), take notice that these are the >> packages that will surely be orphaned, because the current >> maintainer has asked to be removed from the packager group. >> Maybe you can start asking them to transfer the package to you. >> >> I plan to post an updated list before the end of the month and at >> mid October (or maybe Ben will do, if he prefer). >> >> [1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt > Regarding the following package from that list : > - NetworkManager-l2tp (owned by ivanromanov) > > I've been maintaining the package (and upstream source) since 2016, but I'm > not the 'owner" or "main admin", just a member/admin. > > What's the best way to become owner of the NetworkManager-l2tp package? > > > > Thanks, > Doug > Since we're still unsure if ivanromanov is reachable or not, I'd say: - open a BZ ticket on that package, asking ivanromanov to become the main-admin - wait and see if the package will be orphaned in case the main-admin is removed by this policy, then you can take it over I don't think it's wortwhile to open a unresponsive maintainer ticket at this point. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: OpenSSL sync with RHEL
Dear colleagues, I'm going to push the updated version of OpenSSL to rawhide. This version incorporates FIPS-related changes from RHEL 9. A major change that may affect your applications in FIPS mode is limiting the RSA encryption. There are also minor tweaks limiting explicit curves support in a similar way as it is done in RHEL. -- Dmitry Belyavskiy ___ 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
Review request: python-qt6
Hi I've put up python-qt6 for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2124098 Happy to review in exchange. Thanks Sandro ___ 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 with sequoia pgp
Quoting Neal H. Walfield (2022-09-02 16:31:18) > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > Sequoia PGP. > > https://rpm.org/wiki/Releases/4.18.0 > https://sequoia-pgp.org/ > > Thanks to Fabio Valentini (decathorpe) for packaging not only > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > With this note, I'd firstly like to make the Fedora community more > aware of this project. (I don't think it has been mentioned here > yet.) > > Second, although the internal OpenPGP backend is still the default > backend, it will be removed in rpm 4.19: > > https://github.com/rpm-software-management/rpm/issues/1935 > > It is probably best to start the transition as soon as possible to > work out any kinks. > > In that vein, I'd like to offer my help. Making this type of change > needs to be done carefully. Perhaps these are questions or concerns. > I'd like to hear them and respond to them. There is also technical > work that needs to be done. I'm more of a developer than a packager, > but if Fedora decides to use the Sequoia backend, I'd like to offer my > help in any way I can. > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > work to port it to Sequoia to OpenSSL: > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 Mind the https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies Will we need to introduce a configuration mechanism to limit algorithm selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > ... ___ 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: Inactive packagers to be removed after the F37 release
On Monday, 05 September 2022 at 09:16, Vitaly Zaitsev via devel wrote: > On 04/09/2022 19:30, Michael Catanzaro wrote: > > And anybody who isn't willing to buy a security key wouldn't be able to > > contribute to Fedora at all. > > So, you want to ban all contributors from countries where such tokens are > prohibited, am I right? Strongly -1. Wait, what? Which countries are 2FA token illegal in? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: Inactive packagers to be removed after the F37 release
On Mon, 2022-09-05 at 10:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > Wait, what? Which countries are 2FA token illegal in? > > Regards, > Dominik I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1. Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA. And if doing it across the board is inconvenient, at least for "important" packages/roles. There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA. ___ 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 with sequoia pgp
On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin wrote: > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > Sequoia PGP. > > > > https://rpm.org/wiki/Releases/4.18.0 > > https://sequoia-pgp.org/ > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > With this note, I'd firstly like to make the Fedora community more > > aware of this project. (I don't think it has been mentioned here > > yet.) > > > > Second, although the internal OpenPGP backend is still the default > > backend, it will be removed in rpm 4.19: > > > > https://github.com/rpm-software-management/rpm/issues/1935 > > > > It is probably best to start the transition as soon as possible to > > work out any kinks. > > > > In that vein, I'd like to offer my help. Making this type of change > > needs to be done carefully. Perhaps these are questions or concerns. > > I'd like to hear them and respond to them. There is also technical > > work that needs to be done. I'm more of a developer than a packager, > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > help in any way I can. > > > > > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > Mind the > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > Will we need to introduce a configuration mechanism to limit algorithm > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? Isn't this handled at the level of the crypto library? OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow system crypto policy, just as OpenSSL does? For example, I don't see anything related to crypto policies in the gnupg2 package, either. Fabio ___ 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 with sequoia pgp
On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini wrote: > > On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin > wrote: > > > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > > Sequoia PGP. > > > > > > https://rpm.org/wiki/Releases/4.18.0 > > > https://sequoia-pgp.org/ > > > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > > > > With this note, I'd firstly like to make the Fedora community more > > > aware of this project. (I don't think it has been mentioned here > > > yet.) > > > > > > Second, although the internal OpenPGP backend is still the default > > > backend, it will be removed in rpm 4.19: > > > > > > https://github.com/rpm-software-management/rpm/issues/1935 > > > > > > It is probably best to start the transition as soon as possible to > > > work out any kinks. > > > > > > In that vein, I'd like to offer my help. Making this type of change > > > needs to be done carefully. Perhaps these are questions or concerns. > > > I'd like to hear them and respond to them. There is also technical > > > work that needs to be done. I'm more of a developer than a packager, > > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > > help in any way I can. > > > > > > > > > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > > work to port it to Sequoia to OpenSSL: > > > > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Mind the > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > > > Will we need to introduce a configuration mechanism to limit algorithm > > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > > Isn't this handled at the level of the crypto library? That's my question, really: does it need extra configuration generated or will it just attempt a low-level library operation and fail gracefully when it finds the operations blocked? > OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow > system crypto policy, just as OpenSSL does? > For example, I don't see anything related to crypto policies in the > gnupg2 package, either. Unfortunately, nettle and gnupg2 don't follow crypto-policies (yet?). It's only beginning to expand beyond networking protocols (TLS/SSH/KRB...). ___ 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: Users with commit rights in src.fp.o but no more in packager group
Dne 03. 09. 22 v 22:28 Kevin Fenzi napsal(a): On Sat, Sep 03, 2022 at 02:01:59PM +, Mattia Verga via devel wrote: Il 26/08/22 07:17, David Tardon ha scritto: Hi, On Thu, 2022-08-25 at 11:04 +0300, Alexander Bokovoy wrote: On to, 25 elo 2022, Miro Hrončok wrote: We use the python-maint pseudo-account to be the default Bugzilla assignee for Pythons, e.g. https://src.fedoraproject.org/rpms/python3.11 Note that it does *not* require the account to be listed in maintainers or to have commit rights. Same for ipa-maint account. Same for systemd-maint and dracut-maint. D. So... wouldn't be better to have a consistent way across all packages to deal with these cases? Sure, but Fedora has been around for many years, accross a bunch of differnt applications and these things have never been completly set. :( What's better, a pseudo-user to be the main-admin of a package, or a real user to be the main-admin and just add the pseudo-user as the default assignee of bugs? What is the difference between pseudo-users and groups? The group membership management is certainly PITA, because group members cannot e.g. remove the group from retired packages: https://pagure.io/releng/issue/10954 Apart from that, I don't think that the pseudo-users or group ownership would work. I saw a good amount of people giving the packages to some groups or pseudo-users, but in turn, that meant there is nobody who would care about such package. Vít We discussed this back when we switched from pkgdb to pagure-dist-git some. One thought at the time was that we make every package use a pseutouser for main-admin, but there's downsides to that too. On the plus side it would allow us to get rid of 'main admin'. Who owns the credentials of those pseudo-users? Also, Fedora Accounts user pages links to non-existent wiki pages... it would be nice to have a description about them (if there's a consensus of continue listing them as main-admin). Many of them the group using them has the credentials, or no one at all. I'm not sure it's possible to get them all sorted, but I agree at least a wiki page with info on them would be good to have at the very least. kevin ___ 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 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Mon, Sep 05, 2022 at 08:33:40AM +, Tommy Nguyen wrote: > On Mon, 2022-09-05 at 10:13 +0200, Dominik 'Rathann' Mierzejewski > wrote: > > Wait, what? Which countries are 2FA token illegal in? > > > > Regards, > > Dominik > > I cannot think of any reason why 2FA would be illegal in any country > when TOTP is based on HMAC and by default uses SHA-1. > > Further if I may offer my unsolicited opinion, I am strongly in favor > in requiring 2FA. And if doing it across the board is inconvenient, at > least for "important" packages/roles. > > There's been too many supply chain incidents (see npm, github, any > corporate data breach, et al.) that I think Fedora would benefit from > mandating 2FA. Those who've been around a long time will remember that we've discovered compromises of a Fedora maintainer's account in the past: https://lwn.net/Articles/424484/ Out of an abundance of caution / paranoia, we even later went as far as to force a mass password change and new SSH key creation across all our maintainers: https://lists.fedoraproject.org/pipermail/devel-announce/2011-October/000840.html We got lucky back in 2011 that the impact was not too bad, but luck runs out eventually, so 2fa for maintainers has clear benefits in reducing risk to Fedora and its consumers. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Users with commit rights in src.fp.o but no more in packager group
On 05. 09. 22 11:07, Vít Ondruch wrote: Apart from that, I don't think that the pseudo-users or group ownership would work. I saw a good amount of people giving the packages to some groups or pseudo-users, but in turn, that meant there is nobody who would care about such package. +100 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
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 fail to install and/or build 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://churchyard.fedorapeople.org/orphans-2022-09-05.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 abduco dfateyev, orphan0 weeks ago bumpversionjdornak, orphan 0 weeks ago clinfo orphan 0 weeks ago colm jtaylor, lorbus, orphan 0 weeks ago ellorphan 0 weeks ago espresso-abavigne, orphan 0 weeks ago fortune-modepel-packagers-sig, orphan, 0 weeks ago sergiomb, shlomif geteltoritoorphan 0 weeks ago gimp-focusblur-plugin orphan 0 weeks ago git-archive-allorphan 0 weeks ago git-fame fale, ignatenkobrain, orphan0 weeks ago git-lab-porcelain orphan 3 weeks ago gmqcc orphan 0 weeks ago hctavigne, orphan 0 weeks ago httrackcicku, fale, orphan 0 weeks ago ipsilonorphan, puiterwijk, simo2 weeks ago kelbt orphan 0 weeks ago libmaxminddb jtaylor, mruprich, orphan 0 weeks ago libtomlorphan 0 weeks ago libtvdborphan 1 weeks ago mcpanelorphan 0 weeks ago metapixel orphan 1 weeks ago mirrorlist-server adrian, orphan, rust-sig0 weeks ago monobristolorphan 0 weeks ago mozilla-https-everywhere orphan, rathann 1 weeks ago novacom-client orphan 2 weeks ago novacom-server orphan 2 weeks ago nsca-ngorphan 0 weeks ago origin go-sig, orphan, tdawson 0 weeks ago parzip orphan 0 weeks ago perl-BSSolvngompa, orphan 0 weeks ago perl-Parse-Debian-Packages orphan 0 weeks ago php-psr-http-clientorphan 0 weeks ago pidgin-save-conv-order orphan 1 weeks ago python-aiofilesorphan 0 weeks ago python-aioodbc orphan 0 weeks ago python-aiorpcx jonny, orphan 0 weeks ago python-argopt orphan 0 weeks ago python-arpybochecha, orphan, python-sig0 weeks ago python-august orphan 2 weeks ago python-bitstruct orphan 2 weeks ago python-calligrabot merlinm, orphan 2 weeks ago python-colanderinfra-sig, lmacken, orphan, ralph 0 weeks ago python-coreapi orphan 0 weeks ago python-coreschema orphan 0 weeks ago python-cu2qu orphan 2 weeks ago python-daemonize orphan 0 weeks ago python-devtoolsorphan
Re: Inactive packagers to be removed after the F37 release
On 05/09/2022 10:13, Dominik 'Rathann' Mierzejewski wrote: Wait, what? Which countries are 2FA token illegal in? Russia, China and all countries from the US export banlist. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 10:33, Tommy Nguyen wrote: I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1. In some countries (eg. Russia, China) all cryptographic devices must be certified by local government security service. Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA. Who will pay for these devices? Red Hat? Gnome Foundation? Most maintainers won't be happy to spend $50 on a hobby project. There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA. For 15 years, there hasn't been a single incident with Fedora. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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 with sequoia pgp
Hi Paul, Thanks for your comments. On Fri, 02 Sep 2022 20:21:21 +0200, Paul Wouters wrote: > On Fri, 2 Sep 2022, Neal H. Walfield wrote: > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > I think this should be considered a blocker for changing gpg backends. That's a decision for Fedora. I have no strong preference. (For what it's worth, rpm doesn't use gpg. rpm has an internal OpenPGP backend, which was developed in house.) > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Note2: There are lots of reasons to use Sequoia, but one user-visible > > reason is improved usability. When a user imports a certificate, > > Sequoia lints it and displays potential issues, or reasons why it > > can't be imported: > > > > > > https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 > > > > $ rpm --import peter-expired-backsig.pgp > > Certificate 251C20A67D942D45: > >Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z > >Certificate does not have any usable signing keys > > > > Whereas before rpm would just say: > > > > error: peter-expired-backsig.pgp: key 1 import failed. > > That seems like a fairly minor point to change backends and crypto > library for and could be something that can be fixed in the current > backend as well? I spent some time looking at and trying to improve rpm's OpenPGP implementation. It's quite hairy. See, for example, this issue: https://github.com/rpm-software-management/rpm/issues/2004 Even Panu (rpm's maintainer) does not have great confidence in the OpenPGP parser's robustness: I think the only safe assumption is to assume it a bug in rpm's parser. Shock horror :laughing: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-1096286416 If you want to have a look at the code, here's a good place to start: https://github.com/rpm-software-management/rpm/blob/d703160/rpmio/rpmpgp_internal.c#L965 I suspect that this hairiness is because the internal OpenPGP parser started as a minimal implementation to handle data generated by GnuPG when it was written about 20 years ago. Panu writes: https://github.com/rpm-software-management/rpm/pull/1813#discussion_r790681223 the rpm implementation strives to do the bare minimum to get by https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1080606598 The current "API" is ad-hoc stuff added over the course of 20 years, by people with not much OpenPGP experience. I'm sure it shows. And, over time it has grown in complexity to accommodate new requirements, like support for RFC 4880, and subkeys. Whatever the case, Panu doesn't want to invest more time into it: https://github.com/rpm-software-management/rpm/issues/1935 There's something seriously wrong when a significant percent of package manager development discussions is about OpenPGP specification and its interpretation in the RPM context. This is negatively impacting development of RPM "core business", to the point that this has to stop. There's exactly one way to stop it, and that's getting rid of the internal parser, one way or the other. Targeted for RPM 4.19 in 2023, and this also means that no major developments to the existing parser should be done, from here on it's strictly in critical fixes only -mode. Those are reasons against the internal OpenPGP implementation. But, I also want to briefly say why I (a co-founder of the Sequoia project), think that Sequoia is a good choice. In Sequoia we've spent a lot of time trying to get the little details right. In particular, we invested a lot of effort in certificate canonicalization, which is essential to making sure OpenPGP certificates are interpreted in a sane way. There is a nice write up of why this is hard by the author of PGPainless: https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/ When I first thought about signature verification in OpenPGP I thought “well, it cannot be that hard, right?”. In the end all you got to do is check if a signature was made by the given key and if that signature checks out (is cryptographically correct). Oh boy, was I wrong. (For the haters: yes, OpenPGP is complicated, but I suspect this type of complexity will be present in some form of another is all PKIs that support expirations, revocations, etc.) It's due to this infrastructure that Sequoia is so often able to return informative error messages that go to the root cause of the problem. While developing Sequoia, we didn't just rely on our interpretation of the RFC. We also looked at what other implementations were doing and tried to push the whole ecosystem forward. This is demonstrated through Justus' work on the OpenPGP interoperability test suite: https://tests.sequoia-pgp.org/ Please share any oth
Re: Orphaned packages looking for new maintainers
> tasksh orphan 0 weeks ago Taken tasksh over to begin with. Co-maintainers welcome. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
> > However, last this was discussed, the Fedora AAA system(s) > > did not (yet?) support the full fido2/webauthn/passkey > > functionality, so at this time such full integration is just a > > dream(*). > > You don't have to be a provenpackager to be able to do serious damage; > you just need to maintain one package that's installed by a > sufficiently-interesting quantity of Fedora users. In the long run, we > should be moving to require WebAuthn for all Fedora > authentication-related purposes, since it's unphishable. Last year I > entered my GitHub password into a phishing page that was proxying the > real GitHub... if the evil page had gone to just slightly more effort, > it could have easily intercepted a simple TOTP/HOTP challenge. This is > not possible with WebAuthn, which I would say actually is pretty much > equivalent to a security magic bullet. > > That said, I say this keenly aware that WebKitGTK doesn't support > WebAuthn yet, and I would be interacting with Fedora packaging a lot > less if I couldn't use my normal web browser. And anybody who isn't > willing to buy a security key wouldn't be able to contribute to Fedora > at all. But webauthn and 2FA only stops someone else from compromising my account, it would probably be easier to join and become a packager by packaging a random leaf package no one would use, then as a packager pick up an random orphaned package that's in the core distro and then just compromise the distro that way TBH. 2FA won't stop that as they can just setup an actual 2FA token for their packaging account. ___ 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
jwm license change
jwm-2.4.2 in Fedora-rawhide changed its license from GPLv2 to MIT -- Ali Erdinc Koroglu Linux OS Systems Engineering - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
fortune-mod says "Orphaned for: Orphaned by releng" , which user was considered unresponsive ? Where I can find the tickets of unresponsive maintainer ? Thank you On Mon, 2022-09-05 at 12:36 +0200, Miro Hrončok wrote: > 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 fail to install and/or build 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://churchyard.fedorapeople.org/orphans-2022-09-05.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 > = > === > abduco dfateyev, orphan 0 > weeks ago > bumpversion jdornak, orphan 0 > weeks ago > clinfo orphan 0 > weeks ago > colm jtaylor, lorbus, orphan 0 > weeks ago > ell orphan 0 > weeks ago > espresso-ab avigne, orphan 0 > weeks ago > fortune-mod epel-packagers-sig, orphan, 0 > weeks ago > sergiomb, shlomif > geteltorito orphan 0 > weeks ago > gimp-focusblur-plugin orphan 0 > weeks ago > git-archive-all orphan 0 > weeks ago > git-fame fale, ignatenkobrain, orphan 0 > weeks ago > git-lab-porcelain orphan 3 > weeks ago > gmqcc orphan 0 > weeks ago > hct avigne, orphan 0 > weeks ago > httrack cicku, fale, orphan 0 > weeks ago > ipsilon orphan, puiterwijk, simo 2 > weeks ago > kelbt orphan 0 > weeks ago > libmaxminddb jtaylor, mruprich, orphan 0 > weeks ago > libtoml orphan 0 > weeks ago > libtvdb orphan 1 > weeks ago > mcpanel orphan 0 > weeks ago > metapixel orphan 1 > weeks ago > mirrorlist-server adrian, orphan, rust-sig 0 > weeks ago > monobristol orphan 0 > weeks ago > mozilla-https-everywhere orphan, rathann 1 > weeks ago > novacom-client orphan 2 > weeks ago > novacom-server orphan 2 > weeks ago > nsca-ng orphan 0 > weeks ago > origin go-sig, orphan, tdawson 0 > weeks ago > parzip orphan 0 > weeks ago > perl-BSSolv ngompa, orphan 0 > weeks ago > perl-Parse-Debian-Packages orphan 0 > weeks ago > php-psr-http-client orphan 0 > weeks ago > pidgin-save-conv-order orphan 1 > weeks ago > python-aiofiles orphan 0 > weeks ago > python-aioodbc orphan 0 > weeks ago > python-aiorpcx jonny, orphan 0 > weeks ago > python-argopt orphan 0 > weeks ago > python-arpy bochecha, orphan, python-sig 0 > weeks ago > python-august orphan 2 > weeks ago > python-bitstruct orphan 2 > weeks ago > python-calligrabot merlinm, orphan
Re: Inactive packagers to be removed after the F37 release
Hi Mattia, We seem to be having the same conversation but with opposite interpretations :) I'll try to clarify my comments below. On Mon, Sep 5, 2022 at 9:25 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > Il 05/09/22 08:59, Brian (bex) Exelbierd ha scritto: > > > > On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson > wrote: > >> On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote: >> > Hello everyone! >> > >> > I just completed the first run of FESCo's newly approved Inactive >> > Packager Policy[1]. Packagers that have been identified as inactive >> > have a ticket in the find-inactive-packagers repo[2]. One week after >> > the F37 final release, packagers who remain inactive will be removed >> > from the packager group. (Note that pagure.io is one of the systems >> > checked for activity, so commenting on your ticket that you're still >> > around will prevent you from showing up in the second round.) >> >> So, I have a probably-controversial idea for a follow-up on this. >> > > I'll add one more idea/loophole to consider closing. I am a member of the > packager group but no longer maintain any packages. I am active enough in > other ways to not be noticed by this policy. I don't think that is right. > > I'm sorry for that. The script currently searches for user activity in > src.fp.o, pagure.io, Bodhi, Bugzilla and Fedora mailing lists. Can you > tell me where you're active, so, maybe, I can add that place in the search > pattern? > I am in the packager group. I have no packages. I have activity in BZ, Fedora mailing lists, etc. However, I believe the script should flag me for removal from the packager group because I do not have commit rights to any package and am not a proven packager. regards, bex I have submitted a ticket to voluntarily give up my packager rights under > this policy. However, we should probably verify that a packager actually > has at least one package or is a proven packager as a part of this policy. > I realize that it is very hard to know how long someone has not had any > packages, so this could result in a request to validate to a person who is > temporarily without a package during the period when the script is run, > however I think this is a reasonable edge case to resolve manually. > > regards, > > bex > > I don't agree with that. If a user haven't got any commit right to any > package, they don't need to be in the packager group, that's exactly the > scope of this policy. Maybe they left years ago, their commit rights were > removed, but they never have been removed from packagers. > > Mattia > ___ > 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 > -- Don't rush to reply to this email. Enjoy work/life balance. I read email once a day and am in the CE(S)T timezone. If you have an urgent email, ping me, and consider other mediums for urgent messages in the future. Brian "bex" Exelbierd (he/him/his) Business Strategist for Communities and Developers Red Hat Enterprise Linux @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ 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 with sequoia pgp
Hi Neal, "Neal H. Walfield" writes: > Hi all, > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > Sequoia PGP. > > https://rpm.org/wiki/Releases/4.18.0 > https://sequoia-pgp.org/ > > Thanks to Fabio Valentini (decathorpe) for packaging not only > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ As Sequoia is written in Rust, what is your RISCV story? Fedora is (at least that's my impression) a quite popular choice for RISCV boards, so rpm working on RISCV would be crucial for us staying relevant. Cheers, Dan ___ 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 37 compose report: 20220905.n.0 changes
OLD: Fedora-37-20220904.n.0 NEW: Fedora-37-20220905.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED 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
perl-BSSolv license corrected
I corrected a license declaration in perl-BSSolv package from "GPL or Artistic" to "GPL-1.0-or-later OR Artistic-1.0-Perl". -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
On Mon, 05 Sep 2022 10:12:23 +0200, Alexander Sosedkin wrote: > Mind the > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > Will we need to introduce a configuration mechanism to limit algorithm > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? Good question. Sequoia has a flexible mechanism to describe its cryptographic policy: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html There isn't yet a way to configure it using a configuration file, but that is doable. Here's the issue, fwiw: https://gitlab.com/sequoia-pgp/sequoia/-/issues/857 One potential issue is that OpenPGP fingerprints are computed using SHA-1. In practice this is not a security problem as fingerprints don't need collision resistance, just second pre-image resistance, which SHA-1 still has. The upcoming version of the OpenPGP specification specifies SHA2 256-based fingerprints https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-06#section-5.5.4 But we won't be able to switch immediately: users would have to create new certificates, and old certificates would have to fall out of use. Neal ___ 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 with sequoia pgp
On Mon, Sep 5, 2022 at 2:18 PM Dan Čermák wrote: > > Hi Neal, > > "Neal H. Walfield" writes: > > > Hi all, > > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > Sequoia PGP. > > > > https://rpm.org/wiki/Releases/4.18.0 > > https://sequoia-pgp.org/ > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > As Sequoia is written in Rust, what is your RISCV story? Fedora is (at > least that's my impression) a quite popular choice for RISCV boards, so > rpm working on RISCV would be crucial for us staying relevant. I don't think architecture support is a problem. This might have been an issue when Rust was relatively new, but the list of supported targets is pretty big now: https://doc.rust-lang.org/nightly/rustc/platform-support.html For example, RISC-V (riscv64gc-unknown-linux-gnu) is supported by the Rust toolchain at the same level (Tier 2) as three other architectures we have (armv7hl / armv7-unknown-linux-gnueabihf, ppc64le / powerpc64le-unknown-linux-gnu, s390x / s390x-unknown-linux-gnu). Only x86 (x86_64-unknown-linux-gnu / i686-unknown-linux-gnu) and aarch64 (aarch64-unknown-linux-gnu) have better support (Tier 1). Fabio ___ 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: Inactive packagers to be removed after the F37 release
On Monday, 05 September 2022 at 12:40, Vitaly Zaitsev via devel wrote: > On 05/09/2022 10:13, Dominik 'Rathann' Mierzejewski wrote: > > Wait, what? Which countries are 2FA token illegal in? > > Russia, China and all countries from the US export banlist. Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Especially since for example Google's Titan Security Keys are made by a Chinese company Feitian[1][2]. [1] https://www.cnbc.com/2018/08/30/google-titan-made-by-chinese-company-feitian.html [2] https://www.zdnet.com/article/google-launches-titan-security-keys-but-recommends-keys-from-chinese-firm-with-military-links-in/ Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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 with sequoia pgp
Hi Dan, On Mon, 05 Sep 2022 14:18:05 +0200, Dan Čermák wrote: > "Neal H. Walfield" writes: > As Sequoia is written in Rust, what is your RISCV story? Fedora is (at > least that's my impression) a quite popular choice for RISCV boards, so > rpm working on RISCV would be crucial for us staying relevant. This is a valid concern, and one that I'm also worried about. According to this web page: https://fedoraproject.org/wiki/Architectures/RISC-V Fedora wants to support the RV64GC architecture, which I think corresponds to riscv64gc-unknown-linux-gnu. The Rust project indicates that riscv64gc-unknown-linux-gnu is a Tier 2 architecture: https://doc.rust-lang.org/nightly/rustc/platform-support.html FWIW, Fedora also supports armv7hl (armv7-unknown-linux-gnueabihf) and s390x-unknown-linux-gnu, which are also Tier 2 Rust architectures, but which have Rust packages: https://koji.fedoraproject.org/koji/buildinfo?buildID=1939157 So, I guess the bad news is that RISCV is not Tier 1, but the good news is that Tier 2 is already pretty good. Relatedly, I hear that Linux will start using Rust. I suspect that as that happens, a lot more resources will be invested in making sure Rust has good support on all of the platforms that Linux supports. Finally, rpm 4.18 will support both the internal OpenPGP parser and the Sequoia-based parser. So, if the Sequoia-based parser proves inadequate for some platforms (e.g., it doesn't compile or the test suite fails), Fedora can still fallback to the internal parser on that platforms. Note, though, that the internal OpenPGP parser is slated to be removed in 4.19: https://github.com/rpm-software-management/rpm/issues/1935 Neal ___ 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: Thunderbird 102 pushed to F36 stable
Hi, As I did those updates.. On Friday, 2022-09-02 17:49:57 +, Mattia Verga via devel wrote: > Here we go again: thunderbird 102 update was submitted to F36. Actually we already had 102.2.0 a week before on 2022-08-23 with https://bodhi.fedoraproject.org/updates/FEDORA-2022-ddee3eb27c for f35 https://bodhi.fedoraproject.org/updates/FEDORA-2022-33dd0f2f3e for f36 after Jan did the rebase to 102.1.0 that was not pushed. We maybe could had gone with 91.13.0 instead of 102.2.0, backing out the rebase for one update, but that was the last 91.x release and newer security fixes will not be released for it, specifically that high-impact CVE-2022-3033 information leak fixed with 102.2.1 is not adressed there. > This new version was known to bring incompatible changes to several > addons, I wasn't aware of that, I'm "only" doing the security updates, and the update to 102.2.0 didn't bring any such up. The releasenotes don't indicate such either: https://www.thunderbird.net/en-US/thunderbird/102.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.1.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.2.0/releasenotes/ Furthermore the 102.2.0 release isn't marked as "not as an upgrade from Thunderbird version 91 or earlier" anymore, which 102.0 and 102.1.0 were. > yet it has been submitted to a stable Fedora release with > autopush enable and just a karma threshold of 2. It took less than 5 > hours from the time the update was submitted to the time the update was > pushed to stable. I chose karma +2 because the past has shown that it rarely gets more votes in f36 and in f35 even less and thought that security updates shouldn't linger around more than necessary. > Package maintainers should put more attention when pushing critical > updates like this and avoid that the update being immediately pushed to > stable. Now, holding off only the 102.2.1 push with https://bodhi.fedoraproject.org/updates/FEDORA-2022-4fcde117f2 for f35 doesn't make sense with 102.2.0 already being in. If for Thunderbird a rebase really would need a FESCo exception then that seems to be a new handling for Thunderbird as also in the past there were rebases from for example 78.11.0 to 91.1.0 in stable f33/f34 (I wasn't involved with) when 78.x was discontinued. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 05. 09. 22 14:07, Sérgio Basto wrote: fortune-mod says "Orphaned for: Orphaned by releng" , which user was considered unresponsive ? Where I can find the tickets of unresponsive maintainer ? $ koji list-history --package=fortune-mod ... Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in f38 by bodhi owner.name: sheltren -> orphan Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in f37 by bodhi owner.name: sheltren -> orphan Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in f36 by bodhi owner.name: sheltren -> orphan There was no non-responsive maintainer process for sheltren. Searching for sheltren in the releng ticket tracker yields nothing. Note that even the maintainer can orphan the package with the reason set to "Orphaned for: Orphaned by releng", there is no guard protecting against that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, Sep 5, 2022 at 4:09 PM Miro Hrončok wrote: > > On 05. 09. 22 14:07, Sérgio Basto wrote: > > > > fortune-mod says "Orphaned for: Orphaned by releng" , which user was > > considered unresponsive ? > > Where I can find the tickets of unresponsive maintainer ? > > $ koji list-history --package=fortune-mod > ... > Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in f38 by bodhi > owner.name: sheltren -> orphan > Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in f37 by bodhi > owner.name: sheltren -> orphan > Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in f36 by bodhi > owner.name: sheltren -> orphan > > > There was no non-responsive maintainer process for sheltren. > Searching for sheltren in the releng ticket tracker yields nothing. > > Note that even the maintainer can orphan the package with the reason set to > "Orphaned for: Orphaned by releng", there is no guard protecting against that. The package was orphaned by releng because the primary maintainer was no longer in the "packager" group: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WR4ZROGR3J7OEZ7IP2XTKT37LRMBCTM3/ Fabio ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote: Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Sure (in Russian, use Google Translate): - http://clsz.fsb.ru/clsz/in-out.htm - http://clsz.fsb.ru/clsz/notif.htm -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote: Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it. Sure (in Russian, use Google Translate): - http://clsz.fsb.ru/clsz/in-out.htm - http://clsz.fsb.ru/clsz/notif.htm The site blocks access from outside of Russia. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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: Inactive packagers to be removed after the F37 release
On 05/09/2022 17:05, Alexander Bokovoy wrote: The site blocks access from outside of Russia. Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English. Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-notification-for-encryption-or-notification-for-encrypted-pr/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, 2022-09-05 at 16:16 +0200, Fabio Valentini wrote: > On Mon, Sep 5, 2022 at 4:09 PM Miro Hrončok > wrote: > > > > On 05. 09. 22 14:07, Sérgio Basto wrote: > > > > > > fortune-mod says "Orphaned for: Orphaned by releng" , which user > > > was > > > considered unresponsive ? > > > Where I can find the tickets of unresponsive maintainer ? > > > > $ koji list-history --package=fortune-mod TIL > > ... > > Mon Sep 5 07:11:28 2022 package owner changed for fortune-mod in > > f38 by bodhi > > owner.name: sheltren -> orphan > > Mon Sep 5 12:08:51 2022 package owner changed for fortune-mod in > > f37 by bodhi > > owner.name: sheltren -> orphan > > Mon Sep 5 15:02:35 2022 package owner changed for fortune-mod in > > f36 by bodhi > > owner.name: sheltren -> orphan > > > > > > There was no non-responsive maintainer process for sheltren. > > Searching for sheltren in the releng ticket tracker yields nothing. > > > > Note that even the maintainer can orphan the package with the > > reason set to > > "Orphaned for: Orphaned by releng", there is no guard protecting > > against that. > > The package was orphaned by releng because the primary maintainer was > no longer in the "packager" group: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WR4ZROGR3J7OEZ7IP2XTKT37LRMBCTM3/ > Thank you, I took the fortune-mod -- Sérgio M. B. ___ 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: Inactive packagers to be removed after the F37 release
On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote: On 05/09/2022 17:05, Alexander Bokovoy wrote: The site blocks access from outside of Russia. Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English. Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-notification-for-encryption-or-notification-for-encrypted-pr/ There are solutions by Russian companies which use WebAuthn and were certified by Russian state (FSTEK). For example, Avanpost Web SSO and Avanpost FAM were certified in 2021. They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia. I happen to know as they support FreeIPA integration officially. The issue right now is not a non-certified usage but a basic unavailability of these tokens inside the country. However, this is a completely different store. Avanpost's press-releases (in Russian): https://avanpost.ru/news/928/ https://avanpost.ru/news/944/, and https://avanpost.ru/news/973/ -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
I've taken a few more (a few for the neuro-sig): > Depending on: mcpanel (1), status change: 2022-08-30 (0 weeks ago) > eegview (maintained by: aekoroglu, ankursinha, neuro-sig) > eegview-0.0-15.fc37.src requires mcpanel-devel = 0.0-15.fc37 > eegview-0.0-15.fc37.x86_64 requires libmcpanel.so.0()(64bit) Taken for neuro-sig, co-maintainers welcome > Depending on: python-aiofiles (5), status change: 2022-08-30 (0 weeks ago) > > > python-matrix-nio (maintained by: ankursinha) > python-matrix-nio-0.19.0-6.fc38.src requires > python3dist(aiofiles) = 0.7 > python3-matrix-nio-0.19.0-6.fc38.noarch requires > python3.11dist(aiofiles) = 0.7 Taken for myself, co-maintainers welcome. > Depending on: python-piexif (3), status change: 2022-08-30 (0 weeks ago) > > vimiv-qt (maintained by: ankursinha) > vimiv-qt-0.8.0-7.fc37.x86_64 requires python3-piexif = > 1.1.3-14.fc37 Taken for myself, co-maintainers welcome. > Depending on: python-rply (4), status change: 2022-08-30 (0 weeks ago) > python-rnc2rng (maintained by: iztokf) > python-rnc2rng-2.6.6-3.fc37.src requires python3dist(rply) = > 0.7.8 > python3-rnc2rng-2.6.6-3.fc37.noarch requires > python3.11dist(rply) = 0.7.8 > > python-citeproc-py (maintained by: ankursinha, ignatenkobrain, > neuro-sig) > python-citeproc-py-0.6.0-5.fc37.src requires > python3dist(rnc2rng) = 2.6.6 > > python-duecredit (maintained by: ankursinha, neuro-sig) > python-duecredit-0.9.1-5.fc37.src requires > python3dist(citeproc-py) = 0.6 > python3-duecredit-0.9.1-5.fc37.noarch requires > python3.11dist(citeproc-py) > = 0.6, python3dist(citeproc-py) = 0.6 > > python-pybids (maintained by: ankursinha, neuro-sig) > python-pybids-0.13.1-5.fc37.src requires python3dist(duecredit) > = 0.9.1 Taken for neuro-sig, co-maintainers welcome > Depending on: rtfilter (2), status change: 2022-08-30 (0 weeks ago) > mcpanel (maintained by: orphan) > mcpanel-0.0-15.fc37.i686 requires librtfilter.so.1 > mcpanel-0.0-15.fc37.src requires rtfilter-devel = 1.1-16.fc37 > mcpanel-0.0-15.fc37.x86_64 requires librtfilter.so.1()(64bit) > > eegview (maintained by: aekoroglu, ankursinha, neuro-sig) > eegview-0.0-15.fc37.src requires mcpanel-devel = 0.0-15.fc37 > eegview-0.0-15.fc37.x86_64 requires libmcpanel.so.0()(64bit) Taken for neuro-sig, co-maintainers welcome -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 05/09/2022 17:58, Alexander Bokovoy wrote: They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia. AFAIK, Aladdin and Rutoken requires their own proprietary drivers for GNU/Linux. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: Manually queue Koschei build?
On Mon, Sep 5, 2022 at 6:00 PM Richard Shaw wrote: > > I was able to fix my EPEL 7 package and performed a successful build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=2058266 > > So I forced a Koschei build to clear the error, but it still built the > PREVIOUS SRPM: > https://koschei.fedoraproject.org/build/13643482 IIUC, koschei takes the latest SRPM from the *buildroot*. So if you didn't file a buildroot override for the successful build, it cannot see it until it is pushed to stable. Fabio ___ 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: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 5:30 PM Michael Catanzaro wrote: > And anybody who isn't willing . ... or able (they are not free, and there may be other restrictions regarding crypto capable device export/import that can require a bit of hoop jumping due to sourcing site shrinkage, all of which does raise bars a bit higher) > ... to buy a security key wouldn't be able to contribute to Fedora > at all. True, and we (as a community) need to understand and support all that wish to contribute, even if they do not have those means. But it is also true that the intent with passkey includes being able to use your (sufficiently modern) mobile device or computer as a source rather than just a physical key(*) (and while I have not tried it (so have no idea how complete/capable it is) I recall there is a golang implementation using your computers TPM2 chip that can be a fido2 authenticator "key" on Linux). While we clearly are not *there* yet, we are getting closer every year where almost everyone has a usable authenticator available to them nearly all the time (typically carried around in their back pocket, or with the user's face staring at the screen). (*) At the recent RSA conference I saw a live demo from a person with devices running iOS, Android, macOS and Windows (no Linux) which could transparently exchange credentials created via FIDO2/passkey technology (even the presenter was a bit surprised there was only a minor "demo effect" glitch since it was partially pre-GA code, but work it did). ___ 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
Help needed with Python fc36 build failing
I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed with Python fc36 build failing
On 05. 09. 22 19:00, Sandro wrote: I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files They include metadata for setuptools in pyproject.toml only (PEP 621): https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5 This has only been supported since setuptools 61.0.0: https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/ On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml. Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing: https://github.com/pypa/setuptools/issues/2329 My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed with Python fc36 build failing
On 05. 09. 22 19:17, Miro Hrončok wrote: My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. Apologies, I now realized that @penguinpee is you. In that case, you might consider not using this feature until Fedora 36 goes EOL. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Sympy 1.11 (review swaps)
On Wed, Aug 31, 2022 at 1:37 PM Jerry James wrote: > They're all done, except for this one: > > python-furo: https://bugzilla.redhat.com/show_bug.cgi?id=2121594 > > It's a bit complicated, due to needing a pile of JavaScript at build > time. Who would like to swap reviews? Give me a complicated one. :-) I am still looking for a reviewer for python-furo. Who needs a review? I'll swap you. -- Jerry James http://www.jamezone.org/ ___ 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
StrongCryptoSettings3 Setting Test Day
Hey All, We have a bunch of test days coming up, we are currently running StrongCryptoSettings3 test day. I will be keeping this open for community members to come and test. It's fairly simple, just run the commands you find in[0] and your output should correspond to [1] This is an *unconventional* test day which means, two things 1. You must try out any exotic VPN, git work flow, chat apps and see if they work 2. Anything which will use OpenSSL will be affected and any corner case should be possibly tested! The first set of quick command execution will be easy. The test day matrix will be open for the time being and it will be great to have this tested! [0] https://fedoraproject.org/wiki/Test_Day:2022-09-05_StrongCryptoSettings3#How_to_test? [1] https://pagure.io/fedora-qa/issue/707#comment-813926 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed with Python fc36 build failing
On 05-09-2022 19:17, Miro Hrončok wrote: On 05. 09. 22 19:00, Sandro wrote: I see the following errors in the build log of a fc36 build [1]: ValueError: Globs did not match any module: pymunin Going up it looks like the name of the package is not expanded and falls back to UNKNOWN: Successfully built UNKNOWN However, the builds for fc37 and rawhide did succeed. I also tried a local mock build for x86_64, but the result is the same. I fail to grasp what's going on here. [1] https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-36-armhfp/04809614-python-PyMunin3/ Looking at the project https://pypi.org/project/PyMunin3/3.0.1/#files They include metadata for setuptools in pyproject.toml only (PEP 621): https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L5 This has only been supported since setuptools 61.0.0: https://setuptools.pypa.io/en/latest/history.html#v61-0-0 https://peps.python.org/pep-0621/ On Fedora 36, setuptools is 59.6 and it does not read/understand the information from pyproject.toml. Unfortunately, when no name or version is present, setuptools does the UNKNOWN==0.0.0 thing: https://github.com/pypa/setuptools/issues/2329 My guess is that when PyMunin3 started to use this feature: https://github.com/penguinpee/PyMunin3/commit/3993dcaa5366da9d771575e8735dd5a7a2c13894 They should have changed the minimal required setuptools version in: https://github.com/penguinpee/PyMunin3/blob/v3.0.1/pyproject.toml#L2 In fact: https://github.com/penguinpee/PyMunin3/pull/3 To package PyMunin3 on Fedora 36, you might need to revert 3993dcaa5366 via a patch or somebody would need to backport this feature to setuptools 59. That might be non-trivial. Due to a significant amount of other braking changes, updating setuptools in Fedora 36 to 61 is not very likely. Thank you, Miro, for the explanation and the pull request. I remember switching away from setup.cfg after being told that pyproject.toml is the way forward. I must have missed the fact that this required a newer minimum version of setuptools. Since this package has yet to make its way into Fedora, I don't mind if it's not available for F36. It will trickle down (or is it up?) from F37. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed with Python fc36 build failing
On Mon, Sep 5, 2022 at 2:01 PM Sandro wrote: > Thank you, Miro, for the explanation and the pull request. I remember > switching away from setup.cfg after being told that pyproject.toml is > the way forward. I must have missed the fact that this required a newer > minimum version of setuptools. pyproject does not work well, and is not backwards compatible. This is particularly a problem for EPEL ports from Fedora. Personally, I'd like to see it fixed for EPEL before relying on it for anything in Fedora. ___ 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
Review swap: a port compiler plugin for Rebar3
Hello All! This spec is actually quite simple - it does all the heavy lifting with generic Erlang macros, builds cleanly, so it won't take you long https://bugzilla.redhat.com/show_bug.cgi?id=2123175 I am willing to review something which got stuck in your queue for a while. -- With best regards, Peter Lemenkov. ___ 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: packaging multiple versions and compat packages
Hi all, Can someone point me to a good resource on how (if permitted) I can make appropriate compat(?) packages to allow for two major versions of the same package to be available? Is this allowed for EPEL? Thanks -- Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@mefuller.dev @fuller:fedora.im @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 ___ 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
Conditional Patch line
I have a downstream patch[0] which -- I don't really understand why -- breaks riscv64 builds but is necessary for primary Fedora arches. Is it correct to do: %ifnarch riscv64 Patch123: downstream.patch %endif given that the package uses %autosetup and therefore doesn't have explicit %patch lines. I think this means that if I build the SRPM on riscv64 then the downstream patch wouldn't be included, meaning that SRPM would then fail to build on other arches. In this particular case that doesn't matter, but it feels wrong. Is there a recommended way to do this (apart from fixing the patch)? Rich. [0] https://pagure.io/fedora-ocaml/c/41d5e2db7a4667560d6aedda11a3c6a80c8f1b83?branch=fedora-37-4.14.0 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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: Conditional Patch line
On Monday, 05 September 2022 at 21:42, Richard W.M. Jones wrote: > I have a downstream patch[0] which -- I don't really understand why -- > breaks riscv64 builds but is necessary for primary Fedora arches. Is > it correct to do: > > %ifnarch riscv64 > Patch123: downstream.patch > %endif > > given that the package uses %autosetup and therefore doesn't have > explicit %patch lines. > > I think this means that if I build the SRPM on riscv64 then the > downstream patch wouldn't be included, meaning that SRPM would then > fail to build on other arches. In this particular case that doesn't > matter, but it feels wrong. Is there a recommended way to do this > (apart from fixing the patch)? Change %autosetup to plain %setup and apply the patch conditionally instead of conditionally including it in the SRPM. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: Conditional Patch line
On Mon, Sep 05, 2022 at 09:56:58PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 05 September 2022 at 21:42, Richard W.M. Jones wrote: > > I have a downstream patch[0] which -- I don't really understand why -- > > breaks riscv64 builds but is necessary for primary Fedora arches. Is > > it correct to do: > > > > %ifnarch riscv64 > > Patch123: downstream.patch > > %endif > > > > given that the package uses %autosetup and therefore doesn't have > > explicit %patch lines. > > > > I think this means that if I build the SRPM on riscv64 then the > > downstream patch wouldn't be included, meaning that SRPM would then > > fail to build on other arches. In this particular case that doesn't > > matter, but it feels wrong. Is there a recommended way to do this > > (apart from fixing the patch)? > > Change %autosetup to plain %setup and apply the patch conditionally > instead of conditionally including it in the SRPM. There are 26 patches so that's a bit of a PITA. Is there not an easier way? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Conditional Patch line
On Monday, September 5, 2022 Richard W.M. Jones wrote:
> I have a downstream patch[0] which -- I don't really understand why --
> breaks riscv64 builds but is necessary for primary Fedora arches. Is
> it correct to do:
>
> %ifnarch riscv64
> Patch123: downstream.patch
> %endif
>
> given that the package uses %autosetup and therefore doesn't have
> explicit %patch lines.
>
> I think this means that if I build the SRPM on riscv64 then the
> downstream patch wouldn't be included, meaning that SRPM would then
> fail to build on other arches. In this particular case that doesn't
> matter, but it feels wrong. Is there a recommended way to do this
> (apart from fixing the patch)?
Yes, conditionalizing Source or Patch lines is a bad idea. This exact case is
explicitly forbidden by the guidelines[1]. There is also a guidelines PR to
forbid any type of Source/Patch conditionaliztion[2].
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
#_no_arch_specific_sources_or_patches
[2]: https://pagure.io/packaging-committee/pull-request/1163
If you don't want to add %patchX for every Patch, you can use regular `%setup
-q` together with %autopatch, which allows more granular control than
`%autosetup`.
>From /usr/lib/rpm/macros:
```
# Apply patches using %autosetup configured SCM.
# Typically used with no arguments to apply all patches in the order
# introduced in the spec, but alternatively can be used to apply indvidual
# patches in arbitrary order by passing them as arguments.
# -vVerbose
# -p Prefix strip (ie patch -p argument)
# -m Apply patches with number >= min only (if no arguments)
# -M Apply patches with number <= max only (if no arguments)
%autopatch(vp:m:M:) %{lua:
```
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
signature.asc
Description: This is a digitally signed message part.
___
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: Inactive packagers to be removed after the F37 release
On Monday, September 5, 2022 Peter Robinson wrote: > it would probably be easier to join and become a packager by > packaging a random leaf package no one would use, then as a packager > pick up an random orphaned package that's in the core distro and then > just compromise the distro that way TBH. They wouldn't even need to pick up a core package. "Supplements: kernel" would get them far enough... -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: [EPEL-devel] EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: Conditional Patch line
On 5/9/22 16:42, Richard W.M. Jones wrote: I have a downstream patch[0] which -- I don't really understand why -- breaks riscv64 builds but is necessary for primary Fedora arches. Is it correct to do: %ifnarch riscv64 Patch123: downstream.patch %endif When I have to do things like that (often temporarily), I do something like this %ifnarch riscv64 Patch123: downstream.patch %else Source23: downstream.patch %endif given that the package uses %autosetup and therefore doesn't have explicit %patch lines. I think this means that if I build the SRPM on riscv64 then the downstream patch wouldn't be included, meaning that SRPM would then fail to build on other arches. In this particular case that doesn't matter, but it feels wrong. Is there a recommended way to do this (apart from fixing the patch)? Rich. [0] https://pagure.io/fedora-ocaml/c/41d5e2db7a4667560d6aedda11a3c6a80c8f1b83?branch=fedora-37-4.14.0 Pablo. ___ 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: Conditional Patch line
On Mon, 2022-09-05 at 15:00 -0500, Maxwell G via devel wrote:
> On Monday, September 5, 2022 Richard W.M. Jones wrote:
> > I have a downstream patch[0] which -- I don't really understand why
> > --
> > breaks riscv64 builds but is necessary for primary Fedora arches.
> > Is
> > it correct to do:
> >
> > %ifnarch riscv64
> > Patch123: downstream.patch
> > %endif
> >
> > given that the package uses %autosetup and therefore doesn't have
> > explicit %patch lines.
> >
> > I think this means that if I build the SRPM on riscv64 then the
> > downstream patch wouldn't be included, meaning that SRPM would then
> > fail to build on other arches. In this particular case that
> > doesn't
> > matter, but it feels wrong. Is there a recommended way to do this
> > (apart from fixing the patch)?
>
> Yes, conditionalizing Source or Patch lines is a bad idea. This exact
> case is
> explicitly forbidden by the guidelines[1]. There is also a guidelines
> PR to
> forbid any type of Source/Patch conditionaliztion[2].
because src.rpm will be different if build in one specific arch and
src.rpm should have the same results built in any arch
> [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/
> #_no_arch_specific_sources_or_patches
>
> [2]: https://pagure.io/packaging-committee/pull-request/1163
>
> If you don't want to add %patchX for every Patch, you can use regular
> `%setup
> -q` together with %autopatch, which allows more granular control than
> `%autosetup`.
>
> From /usr/lib/rpm/macros:
>
> ```
> # Apply patches using %autosetup configured SCM.
> # Typically used with no arguments to apply all patches in the order
> # introduced in the spec, but alternatively can be used to apply
> indvidual
> # patches in arbitrary order by passing them as arguments.
> # -vVerbose
> # -p Prefix strip (ie patch -p argument)
> # -m Apply patches with number >= min only (if no
> arguments)
> # -M Apply patches with number <= max only (if no
> arguments)
> %autopatch(vp:m:M:) %{lua:
> ```
maybe this works:
%autosetup -M122 -m124
%ifnarch riscv64
%patch123 -p1
%endif
--
Sérgio M. B.
___
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: Users with commit rights in src.fp.o but no more in packager group
On Mon, Sep 05, 2022 at 12:13:26PM +0200, Miro Hrončok wrote: > On 05. 09. 22 11:07, Vít Ondruch wrote: > > > > Apart from that, I don't think that the pseudo-users or group ownership > > would work. I saw a good amount of people giving the packages to some > > groups or pseudo-users, but in turn, that meant there is nobody who > > would care about such package. > > +100 While that can surely happen, it can and does also happen when someone is 'main admin' of a package. :) You can't make someone care. I think the best thing we can do is match up the people who care with the packages they care about. Using main admin as a indicator of who cares for the package doesn't seem right to me. You can definitely have cases of packages where multiple people work on it, or cases where just one person does, but they aren't the main admin. Anyhow, the only real reason we need main admin is that bugzilla needs 1 specific user to assign bugs to. Perhaps we could consider this when/if we ever move off bugzilla. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Thunderbird 102 pushed to F36 stable
As I did those updates.. well explained, thx. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. not terribly differently than others -- with an abundance of end-user education and caution? tbird version update -- across ESLs or not -- breaking one's install, or eating one's mailstore, is not _automatically_ a universal fact for tbird, it's more often an issue specific to one's system; not uncommmonly, your config &/or your addons. for other ppl, the upgrade's been working fine in production for awhile now with upstream releases, with early fedora tbird builds, and now the fedora release pkgs. for me, the lack of a long-overdue v102 update was 'costing' much more than not ... on F36, thunderbird packages are still available in two major versions dnf list --showduplicates thunderbird Last metadata expiration check: 0:01:09 ago on Sat 03 Sep 2022 07:36:45 AM EDT. Available Packages thunderbird.x86_6491.7.0-1.fc36 fedora thunderbird.x86_64 102.2.1-1.fc36 updates older version's still easily installed, dnf install thunderbird-91.7.0-1.fc36.x86_64 historical versions are still available, and quite easily installed & functional, from https://www.thunderbird.net/en-US/thunderbird/releases/ ESL or not, how exactly was thunderbird 102 'pushed' to ppl's systems? did they enable autoupdates? or, click to allow the update? if tbird's a critical update for 'you', you do have backups of your tbird configs & mailstores? keep up to date with thunderbird version progress/news/chengelogs/notes? remembered that addons are not tbird or fedora issues, and checked current/future compatibility of your addons, as well as whether they're well maintained? communicated issues/bugs/etc to the respective projects? and have waited to update until after checking/verifying that it works for you? and, in case none of that was done, since firefox/tbird major-version update issues _are_ historically well-known (if unfortunate), you froze version upgrades of tbird on your system https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html to make sure that you're never surprised by an update you don't want/expect? my $0.02. ___ 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: hardened malloc is big and slow
On Wed, Aug 31, 2022 at 10:19:51AM -0700, John Reiser wrote: > > Bottom line opinion: hardened_malloc ... costs too much. > > Attempting to be constructive: Psychologically, I might be willing to pay > a "security tax" of something like 17%, partly on the basis of similarity > to the VAT rate (Value Added Tax) in some parts of the developed world. The comparison is being done incorrectly. Since hardened_malloc builds both a lightweight and heavyweight library by default, and since I already explained this and that the lightweight library still has optional security features enabled, it doesn't seem to have been done in good faith. My previous posts where I provided both concise and detailed information explaining differences and the approach were ignored. Why is that? As I said previously, hardened_malloc has a baseline very hardened allocator design. It also has entirely optional, expensive security features layered on top of that. I explained in detail that some of those features have a memory cost. Slab allocation canaries have a small memory cost and slab allocation quarantines have a very large memory cost especially with the default configuration. Those expensive optional features each have an added performance cost too. Measuring with 100% of the expensive optional features enabled and trying to portray the performance of the allocator solely based on that is simply incredibly misleading and disregards all of my previous posts in the thread. hardened_malloc builds both a lightweight and heavyweight library by default. The lightweight library still has 2 of the optional security features enabled. None of the optional security features is provided by glibc malloc and if you want to compare the baseline performance then none of those should be enabled for a baseline comparison. Take the light configuration, disable slab allocation canaries and full zero-on-free, and there you go. I also previously explained that hardened_malloc does not include a thread cache for security reasons inherent to the concept of a thread cache. An array-based thread cache with out-of-line metadata would still hurt security, but would be a more suitable approach than a free list compromising the otherwise complete lack of inline metadata. Compare hardened_malloc with the optional security features disabled to glibc malloc and also to glibc malloc with tcache disabled. It's easy enough to stick a thread cache onto hardened_malloc and if there was demand for that I could implement it in half an hour. At the moment, the current users of hardened_malloc don't want to make the sacrifice of losing 100% reliable detection of invalid frees along with the many other benefits lost by doing that. ___ 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: hardened malloc is big and slow
On Wed, Aug 31, 2022 at 05:59:42PM +0200, Pablo Mendez Hernandez wrote: > Adding Daniel for awareness. Why was the heavyweight rather than lightweight configuration used? Why compare with all the expensive optional security features enabled? Even the lightweight configuration has 2 of the optional security features enabled: slab canaries and full zero-on-free. Both of those should be disabled to measure the baseline performance. Using the heavyweight configuration means having large slab allocation quarantines and not just zero-on-free but checking that data is still zeroed on allocation (which more than doubles the cost), slot randomization and multiple other features. It just doesn't make sense to turn security up to 11 with optional features and then present that as if it's the performance offered. I'm here to provide clarifications about my project and to counter incorrect beliefs about it. I don't think it makes much sense for Fedora to use it as a default allocator but the claims being made about memory usage and performance are very wrong. I already responded and provided both concise and detailed explanations. I don't know what these nonsense measurements completely disregarding all that are meant to demonstrate. It's a huge hassle for me to respond here because I have no interest in this list and don't want to be subscribed to it. I didn't propose that Fedora uses it and don't think it makes sense for Fedora. At the same time I already explained that glibc malloc is ALSO a very bad choice in detail. Linux distributions not willing to sacrifice much for security would be better served by using jemalloc with small chunk sizes on 64 bit operating systems. ASLR is too low entropy on 32 bit to afford the sacrifice of a few bits for chunk alignment though. It can be configured with extra sanity checks enabled and with certain very non-essential features disabled to provide a better balance of security vs. performance. The defaults are optimized for long running server processes. It's very configurable, including by individual applications. hardened_malloc builds both a lightweight and heavyweight library itself. The lightweight library still has the optional slab allocation canary and full zero-on-free features enabled. Both those should be disabled to truly measure the baseline cost. None of those optional features is provided by glibc malloc. None of them is needed to get the benefits of hardened_malloc's 100% out-of-line metadata, 100% invalid free detection, entirely separate never reused address space regions for all allocator metadata and each slab allocation size class (which covers up to 128k by default), virtual memory quarantines + random guards for large allocations, etc. etc. The optional security features are optional because they're expensive. That's the point of building both a sample lightweight and heavyweight configuration by default. Lightweight configuration is essentially the recommended configuration if you aren't willing to make more significant sacrifices for security. It's not the highest performance configuration it offers, just a reasonable compromise. Slab allocation canaries slightly increase memory usage. Slab allocation quarantines (disabled in lightweight configuration, which is built by default) greatly increase memory usage, especially with the default configuration. The whole point of quarantines is that they delay reuse of the memory and since these are slab allocations within slabs the memory gets held onto. If you wanted to do measure the baseline performance, then you'd do as I suggested and measure with all the optional features disabled (disable at least those 2 features included in optional) and compare that to both glibc malloc and glibc malloc with tcache disabled. I explained previously that hardened_malloc could provide an array-based thread cache as an opt-in feature, but currently it isn't done because it inherently reduces security. No more 100% reliable detection of all invalid frees and a lot more security properties lost. Also hardly makes sense to have optional features like quarantines and slot randomization underneath unless the thread caches are doing the same thing. As I said previously, if you compare hardened_malloc with optional features disabled to glibc malloc with tcache disabled, it performs as well and has much lower fragmentation and lower metadata overhead. If you stick a small array-based thread cache onto hardened_malloc, then it can perform as well as glibc with much larger freelist-based thread caches since it has a different approach to scaling with jemalloc-style arenas. ___ 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.f
Re: hardened malloc is big and slow
On Mon, 2022-09-05 at 22:45 -0400, Daniel Micay via devel wrote: > The comparison is being done incorrectly. Since hardened_malloc > builds > both a lightweight and heavyweight library by default, and since I > already explained this and that the lightweight library still has > optional security features enabled, it doesn't seem to have been done > in > good faith. My previous posts where I provided both concise and > detailed > information explaining differences and the approach were ignored. Why > is > that? I agree. I decided to do a more fair test myself (I'm quite interested in hardened_malloc). First, I downloaded the source RPM for my current kernel: dnf download --source kernel-5.19.6-200.fc36.x86_64 Then made both heavy and light variants: sysctl -p /etc/sysctl.d/hardened_malloc.conf make VARIANT=light Setup the chroot: mock -r fedora-36-x86_64 --init Create our SRPM: mock -r fedora-36-x86_64 --buildsrpm --spec kernel.spec --sources $PWD --resultdir $PWD Now do the compilations: cp out-light/libhardened_malloc.so . ./preload.sh /usr/bin/time mock -r fedora-36-x86_64 --rebuild kernel- 5.19.6-200.fc36.src.rpm >light.out 2>&1 /usr/bin/time mock -r fedora-36-x86_64 --rebuild kernel-5.19.6- 200.fc36.src.rpm >no_preload.out 2>&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
