RE: Inactive packagers to be removed after the F37 release
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 ___ 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: Build failure on f37-x86_64, stdlib.h: No such file or directory
Bruno Postle wrote on 2022/09/04 17:44: Can someone give me hint as to what I'm doing wrong here, I have a C++ package that builds fine for f35 & f36 with x86_64 & aarch64, but which fails on f37-x86_64 (the build is ok on f37-aarch64): https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/ [ 0%] Building CXX object CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o /usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3 -DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3 -DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3 -DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS -DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)" -DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA -I/usr/include/opencascade -I/usr/include/COLLADABaseUtils -I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem /usr/include -lxml2 -DNDEBUG -O3 -fPIC -Wall -Wextra -Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC -DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -MF CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d -o CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp In file included from /usr/include/c++/12/ext/string_conversions.h:41, from /usr/include/c++/12/bits/basic_string.h:3960, from /usr/include/c++/12/string:53, from /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27: /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ This command line contains "-isystem /usr/include", on other architectures this is not included, this is the difference. But currently I cannot figure out where this "-isystem /usr/include" came from. Regards, Mamoru ___ 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: F37 side tag after branching point
Here we go: - F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8414514ae6 - rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c2d48988e After the mass rebuild in the F37 side tag, we tagged all builds also in a rawhide side tag, rebuilt everything in one go, untagged the F37 builds, and created the update for rawhide. Quick and easy. Thanks all for your help. Iñaki On Wed, 24 Aug 2022 at 19:04, Kevin Fenzi wrote: > > Just to chime in from a releng perspective here... > > IMHO you should do builds for f38 now also (either by making a side tag > and bootstrapping them just like was done for f37, or tagging f37 builds > you need into the f38 sidetag). > > While it's technically possible to push the f37 builds into rawhide > also, it would take releng manually tagging them in, bypassing bodhi, > gating and CI completely. It's much better to build again for > f38/rawhide and let those builds get checked by gating and CI, etc. > > If you run into any problems, let me know... > > 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 -- Iñaki Úcar ___ 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 6:29 PM Alexander Bokovoy wrote: > You might want to watch our Nest with Fedora 2022 talk. More features > are coming too, we are working on a direct FIDO2 integration in SSSD and > FreeIPA . Thanks for the update. Good news about the progress. I will watch the talks. ___ 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 su, 04 syys 2022, Gary Buhrmaster wrote: On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson wrote: Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely. Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)). 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(*). FreeIPA 4.9.10+ supports integration with an external OAuth2 identity provider (IdP). It needs OAuth2 device authorization grant flow support from IdP which Ipsilon does not support but Keycloak or any of major public IdPs aside from Gitlab do support. Keycloak does support FIDO2/WebAuthn too, so FreeIPA in Fedora 36 or later can be set up to operate with WebAuthn and no passwords in your own deployments. Fedora AAA uses RHEL IdM as a backend and there this feature is coming in next minor RHEL releases. It is not fully functional yet but for Fedora AAA use-case things are there with FreeIPA side. For Fedora users it would look like similar to the current Kerberos flow: (1) obtain an anonymous PKINIT ticket to use as a FAST channel, and (2) attempt to authenticate to Fedora KDC. If sssd-idp subpackage is installed and your Fedora AAA account is configured to use external IdP for your access authorization, then you'd be asked to visit a URL where you'd authenticate and then grant that authorization to Fedora AAA system. This IdP can be something that Ipsilon could federate to purely for the user authentication purposes. This is not implemented in Fedora AAA yet. You might want to watch our Nest with Fedora 2022 talk. More features are coming too, we are working on a direct FIDO2 integration in SSSD and FreeIPA, but a lot of help is needed from desktop folks as well to make it usable for login to graphical environments. GDM login is ugly right now as a message we push through PAM prompts is simply not fitting into GDM input boxes and you don't know where to go for your IdP access. See https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html for practical workshop details on how to set and use this in FreeIPA. Nest With Fedora's talk replay is available here: https://app.hopin.com/events/nest-with-fedora-2022/replay/Um91bmR0YWJsZVJlY29yZGluZ0FyY2hpdmU6MTM2OTQ3 (skip to 8:55 or so to the talk's start). Slides can be found here but the talk also has several demos: https://vda.li/talks/2022/2022-Nest-With-Fedora-FreeIPA-and-OAuth2.pdf (*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point. Ipsilon is orphaned in Fedora. If not picked up, it will disappear. It would be sad but a practical issue is that upstream seem to be less active too. Not sure how it goes but given that Fedora AAA is deployed or going to be eventually deployed in a containerized way, then probably focusing on another feature rich open source IdP could be a better option. -- / 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 Sun, Sep 4 2022 at 04:48:10 PM +, Gary Buhrmaster wrote: 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. Michael ___ 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 3:48 PM Adam Williamson wrote: > Personally, once a year wouldn't be anywhere near frequent enough to > trigger me to Do Something About It - it took me years to turn off > Bugzilla's "hey look you have needinfo bugs!" thing and I was getting > that every *day*. :P But I dunno about others. At least you did not have to actively respond once a day in order to keep your packaging status. If you did, I suspect you would have figured out a different solution (and being required to respond is what we are talking about here). I am not sure how often a required response should be (and as you rightly say, it can vary by person). While (putting my security hat on) I would prefer security awareness training happen continuously and constantly(*), a yearly refresher/revalidation seems to be the industry norm, where one agrees, yet again, that they are aware of, and agree to, their roles and responsibilities. (*) And not due to repeated "You opened *what* email attachment?" ___ 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 3:52 PM Adam Williamson wrote: > Well, not really. 2FA isn't a magic bullet. I would be in favor of > doing this, but you can't treat any security measure as solving all > your problems completely. Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)). 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(*). (*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point. ___ 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: [Test-Announce] Proposal to CANCEL: 2022-09-05 Fedora QA Meeting
Hey! Can't join on Tuesday next week as i will be at the Red Hat Open Tour Stockholm event then On 9/4/22, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting tomrrow. It's a holiday > in North America and I don't have anything much for the agenda again. > There will be a blocker review meeting on Tuesday, due to the holiday. > > If you're aware of anything it would be useful to discuss this week, > please do reply to this mail and we can run the meeting on Tuesday. > > Thanks folks! > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ 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
[Test-Announce] Proposal to CANCEL: 2022-09-05 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomrrow. It's a holiday in North America and I don't have anything much for the agenda again. There will be a blocker review meeting on Tuesday, due to the holiday. If you're aware of anything it would be useful to discuss this week, please do reply to this mail and we can run the meeting on Tuesday. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, 2022-09-04 at 10:18 +0200, Vitaly Zaitsev via devel wrote: > On 04/09/2022 02:40, Adam Williamson wrote: > > Maybe if there are > > folks like that they'd be happy to drop the privileges so if they do > > lose their laptop or something, the consequences are more limited. > > We just need to force all proven packagers to use 2FA. Problem solved. Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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, 2022-09-04 at 03:02 +, Gary Buhrmaster wrote:
> On Sun, Sep 4, 2022 at 1:06 AM Kevin Fenzi wrote:
>
> > Perhaps it would be better (although more noisy) to just mail all
> > provenpackagers every cycle and ask if anyone would like to leave the
> > group?
>
> One should ask a PP (I am not so honored), but getting
> an email every cycle (and requiring an affirmative response)
> would be one of those reasons that I would consider a
> loophole closure loophole bypass ("stop annoying me!").
Personally, once a year wouldn't be anywhere near frequent enough to
trigger me to Do Something About It - it took me years to turn off
Bugzilla's "hey look you have needinfo bugs!" thing and I was getting
that every *day*. :P But I dunno about others.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
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 1:38 PM Mattia Verga via devel 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]. Thanks for doing this. The list does not look unduly long or scary(*), especially if a fair number of the packagers reengage (as I expect many will). And if, in the end, I need to pick up a few (mostly leaf) packages that I strongly care about that will work out too. (*) There are some of what I consider core/fundamental packages in the list that I have little doubt either the current packager, or someone else, will pick up as needed (php would seem to be a poster child, but I did see a few others that are fundamental). ___ 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 19/08/22 18:53, Gary Buhrmaster ha scritto: > On Fri, Aug 19, 2022 at 10:47 AM P J P wrote: > >> * Interesting numbers there. > (see below on another number) > >> * While I get that such pruning from time to time is generally good. >>What happens to the packages orphaned by removing inactive packagers? >> >> * Removing orphaned packages may not be easy, as other packages may depend >> on them. > Obviously, if the packages are still desired or needed, an > active packager will need to pick them up. For a number of > those packages I suspect that they have been running more > or less on successful auto-pilot (mass rebuild) for some > time, so picking them up should not result in substantially > increased workload going forward after the initial take, but > I admit I, myself, do not look forward to having to add to > the list of packages I might need to feel (at least notionally) > responsible for if I end up having to take some of them on > due to dependencies in things I do care about. > > I would also say, that while it is probably not entirely easy > to do so, a *very* interesting additional number would > have been how many packages would be orphaned if > all of the identified packagers are removed, just so we > have an order of magnitude of what we are looking at > moving forward. But that list is probably best produced > at a later time, as, for all we know, many of the people > may indeed still be active (and because their packagers > do run on auto-pilot, do not regularly engage). > > These are, of course, probably mostly first run issues. > Once the process is in place and ongoing, the order of > magnitude of the people and packages is likely to be > the usual background noise levels. 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). Mattia [1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt ___ 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
Manually queue Koschei build?
I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29. While I could just ignore it, I was wondering if there was a way to force a rebuild? I see the priority field but I don't have any reference for what a good value would be, it's not particularly intuitive. Thanks, Richard [1] https://koschei.fedoraproject.org/package/OpenColorIO?collection=epel7 ___ 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: 20220904.n.0 changes
OLD: Fedora-37-20220903.n.0 NEW: Fedora-37-20220904.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.33 MiB 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 = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-37-20220904.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-37-20220904.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: R-Rcompression-0.93.2-34.fc37 Summary: R Package for in-memory compression RPMs:R-Rcompression Size:1.33 MiB = 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
Fedora rawhide compose report: 20220904.n.0 changes
OLD: Fedora-Rawhide-20220903.n.0 NEW: Fedora-Rawhide-20220904.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:1 Upgraded packages: 32 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.33 MiB Size of upgraded packages: 567.60 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 20.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20220904.n.0.iso = DROPPED IMAGES = Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20220903.n.0.x86_64.tar.gz = ADDED PACKAGES = = DROPPED PACKAGES = Package: R-Rcompression-0.93.2-34.fc37 Summary: R Package for in-memory compression RPMs:R-Rcompression Size:1.33 MiB = UPGRADED PACKAGES = Package: AusweisApp2-1.24.1-1.fc38 Old package: AusweisApp2-1.22.3-2.fc37 Summary: Online identification with German ID card (Personalausweis) RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc Size: 20.73 MiB Size change: 2.89 MiB Changelog: * Fri Sep 02 2022 Bj??rn Esser - 1.24.1-1 - New upstream release Package: asio-1.24.0-2.fc38 Old package: asio-1.16.1-6.fc37 Summary: A cross-platform C++ library for network programming RPMs: asio-devel Size: 19.98 MiB Size change: 9.34 MiB Changelog: * Sun Jul 31 2022 Julian Sikorski - 1.22.2-1 - Update to 1.22.2 * Sat Aug 13 2022 Julian Sikorski - 1.24.0-1 - Update to 1.24.0 * Sat Sep 03 2022 Julian Sikorski - 1.24.0-2 - Rebuild due to disappearing side tag Package: cinnamon-session-5.4.0-3.fc38 Old package: cinnamon-session-5.4.0-2.fc37 Summary: Cinnamon session manager RPMs: cinnamon-session Size: 582.94 KiB Size change: -252 B Changelog: * Sat Sep 03 2022 Leigh Scott - 5.4.0-3 - Accept Desktop Entry Specification v1.5 Package: ddnet-16.3.1-1.fc38 Old package: ddnet-16.2.2-2.fc37 Summary: DDraceNetwork, a cooperative racing mod of Teeworlds RPMs: ddnet ddnet-data ddnet-server Size: 32.77 MiB Size change: 103.03 KiB Changelog: * Sat Sep 03 2022 S??rgio Basto - 16.3.1-1 - Update ddnet to 16.3.1 (#2118277) Package: gamemode-1.7-1.fc38 Old package: gamemode-1.6-4.fc36 Summary: Optimize system performance for games on demand RPMs: gamemode gamemode-devel Size: 566.25 KiB Size change: 36.82 KiB Changelog: * Thu Jul 21 2022 Fedora Release Engineering - 1.6-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Sat Sep 03 2022 Peter Robinson - 1.7-1 - Update to 1.7 Package: gimp-2:2.10.32-3.fc38 Old package: gimp-2:2.10.30-1.fc37.3 Summary: GNU Image Manipulation Program RPMs: gimp gimp-devel gimp-devel-tools gimp-libs Size: 92.46 MiB Size change: 624.52 KiB Changelog: * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-1 - Version 2.10.32 * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-2 - Remove more cruft for unstable version packaging * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-3 - Add and update (build-)dependencies Package: gnome-subtitles-1.8-1.fc38 Old package: gnome-subtitles-1.7.2-3.fc37 Summary: Subtitle editor for Gnome RPMs: gnome-subtitles Size: 6.28 MiB Size change: 4.57 MiB Changelog: * Thu Aug 25 2022 Julian Sikorski 1.7.2-4 - Rebuild for gtk-sharp3-3.22 * Sat Sep 03 2022 Julian Sikorski 1.8-1 - Update to 1.8 - switch to meson - bundle gst-sharp and gtk-sharp until system versions can be used - drop outdated user guide - update the URL - switch to .xz sources - move COPYING from %%doc to %%license Package: goaccess-1.6.3-1.fc38 Old package: goaccess-1.6.2-1.fc38 Summary: Real-time web log analyzer and interactive viewer RPMs: goaccess Size: 1.36 MiB Size change: 5.54 KiB Changelog: * Sat Sep 03 2022 Eduardo Echeverria - 1.6.3-1 - Update to 1.6.3 Package: golang-github-gobuffalo-flect-0.3.0-1.fc38 Old package: golang-github-gobuffalo-flect-0.2.5-2.fc37 Summary: Inflection engine for Golang RPMs: golang-github-gobuffalo-flect-devel Size: 44.17 KiB Size change: 223 B Changelog: * Sat Sep 03 2022 Elliott Sales de Andrade 0.3.0-1 - Update to latest version (#2123970) Package: golang-github-subosito-gotenv-1.4.1-1.fc38 Old package: golang-github-subosito-gotenv-1.4.0-1.fc37 Summary: Load environment variables from `.env` or `io.Reader` in Go RPMs: golang-github-subosito-gotenv-devel Size: 17.27 KiB Size change: 110 B Changelog: * Sat Sep 03 2022 Elliott Sales de Andrade 1.4.1-1 - Update to latest version (#2120894) Package: golang-github-tdewolff-minify-2.12.1-1.fc38 Old package: golang-github-tdewolff-minify-2.11.10-5.fc37
Build failure on f37-x86_64, stdlib.h: No such file or directory
Can someone give me hint as to what I'm doing wrong here, I have a C++ package that builds fine for f35 & f36 with x86_64 & aarch64, but which fails on f37-x86_64 (the build is ok on f37-aarch64): https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/ [ 0%] Building CXX object CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o /usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3 -DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3 -DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3 -DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS -DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)" -DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA -I/usr/include/opencascade -I/usr/include/COLLADABaseUtils -I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem /usr/include -lxml2 -DNDEBUG -O3 -fPIC -Wall -Wextra -Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC -DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -MF CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d -o CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp In file included from /usr/include/c++/12/ext/string_conversions.h:41, from /usr/include/c++/12/bits/basic_string.h:3960, from /usr/include/c++/12/string:53, from /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27: /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ -- Bruno ___ 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 02:40, Adam Williamson wrote: Maybe if there are folks like that they'd be happy to drop the privileges so if they do lose their laptop or something, the consequences are more limited. We just need to force all proven packagers to use 2FA. Problem solved. -- 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 04/09/2022 00:01, Adam Williamson wrote: But yeah, looking at that, one 'loophole' is it doesn't check if they're actually needing*proven* packager powers - just packager powers. If a proven packager is only building packages they have explicit commit rights to, they may not need proven packager powers any more? According to Fedora Provenpackager policy, proven packagers should only use their powers during approved bulk changes, rebuilding dependent packages, etc. It's fine that they didn't change other packages during the reporting period. -- 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 04/09/22 00:01, Adam Williamson ha scritto: > On Sat, 2022-09-03 at 13:04 -0700, Kevin Fenzi wrote: >> On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote: >>> So, I have a probably-controversial idea for a follow-up on this. >>> >>> Even after this sweep, we have 141 proven packagers. That's a lot of >>> people who can build almost anything in Fedora. >>> >>> It should be possible to check whether a provenpackager has built any >>> package they don't have direct commit rights to in the last X months. >>> >>> Should we construct that search, run it, and propose removing >>> provenpackager status from folks who aren't using it, to cut down that >>> set? >> That policy was setup before this one for packagers. ;) >> >> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ > Look, I'm getting old, okay? ;) > > But yeah, looking at that, one 'loophole' is it doesn't check if > they're actually needing *proven* packager powers - just packager > powers. If a proven packager is only building packages they have > explicit commit rights to, they may not need proven packager powers any > more? I sometimes use my PP powers to fix build tagging issues / updates flows caused by Bodhi glitches, but I (very) rarely use them to build someone else package. What I mean is whatever test is done to check if someone needs to be PP doesn't assume the power is just used to build packages. 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
