Re: Strange error building on Rawhide
On 6/26/24 20:03, Stephen Smoogen wrote: On Wed, 26 Jun 2024 at 10:32, Ron Olson wrote: Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Does it happen to any spec rebuild or just this one? And if this one what is the spec file? The /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT is outside of the buildroot as that should be /home/rolson/rpmbuild/BUILDROOT/ so I could see a bad definition somewhere trying to set up a copy to the wrong destination /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT is the new-style buildroot path in rpm >= 4.20 and so is actually expected in rawhide. It'd only be outside if this was somehow mixed with an older rpm and I don't see how that could happen. I fail to see anything out of the ordinary in swift-lang.spec, but then the one in dist-git is version 5.10.1 whereas the error is on 6.0. - Panu - -- ___ 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
On 2024-06-26 5:42 PM, Gordon Messmer wrote: On 2024-06-25 10:37 AM, Kevin Fenzi wrote: I wonder if this wouldn't fit in as a CI test? Do you mean https://docs.fedoraproject.org/en-US/ci/generic_tests/ ? Maybe it would? If I misunderstand this, please correct me: Because Fedora uses "-z,relro" and "-z,now" in %build_ldflags, all binaries should have a fully resolved GOT when they reach main(). That being the case, gdb could be started with any binary, Oh, no... now I remember... the compromised library detects startup under gdb and doesn't initialize itself. That's why the proof of concept implementation attaches to a running sshd. -- ___ 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
Am 27.06.24 um 02:03 schrieb Gordon Messmer: On 2024-06-24 10:34 PM, Alexander Bokovoy wrote: On Пан, 24 чэр 2024, Gordon Messmer wrote: (As a topic for later: the tirpc library exports functions with the same name as functions that appear in libc, so the behavior of erroring on duplicate symbols needs to be rationalized. Maybe an exemption for libtirpc.so? Are there other libraries that do this?) Most of alternative memory allocation libraries provide their own free/malloc replacements to be used with LD_PRELOAD, e.g. jemalloc. Good point. But I'm mostly concerned with the libraries that binaries link directly against, since those are the cases where the got-audit will always see symbol duplication. Well, jemalloc provides a few more function for e.g. fine-tuning which some applications make use of (and as such need to link against jemalloc directly). -- ___ 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
On 2024-06-25 10:37 AM, Kevin Fenzi wrote: I wonder if this wouldn't fit in as a CI test? Do you mean https://docs.fedoraproject.org/en-US/ci/generic_tests/ ? Maybe it would? If I misunderstand this, please correct me: Because Fedora uses "-z,relro" and "-z,now" in %build_ldflags, all binaries should have a fully resolved GOT when they reach main(). That being the case, gdb could be started with any binary, at which point it could set a breakpoint at "main", run the binary, and then audit the GOT at the breakpoint. Does that sound right? Or something that might be added to rpminspect? It's been a few months since I looked at rpminspect. Does it install a package and all of its deps in order to inspect it? The GOT can't be audited unless the process can start. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in July
On Wed, Jun 26, 2024 at 10:40:33AM +0200, Marcin Juszkiewicz wrote: > W dniu 25.06.2024 o 23:29, Miro Hrončok pisze: > > Depending on: libratbag (1) > > piper (maintained by: vtrefny) > > piper-0.7-8.fc41.noarch requires libratbag-ratbagd > > piper-0.7-8.fc41.src requires libratbag-ratbagd > > Added fix to https://bugzilla.redhat.com/show_bug.cgi?id=2225974 report. thanks, I've applied this one now. ftr, libratbag is effectively unmaintained and really should be orphaned. I've asked Benjamin and Stephen to orphan it so chances are it'll find itself on the orphan list and up for grabs within the next few days. Cheers, Peter -- ___ 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: Following up on: Three steps we could take to make supply chain attacks a bit harder
On 2024-06-24 10:34 PM, Alexander Bokovoy wrote: On Пан, 24 чэр 2024, Gordon Messmer wrote: (As a topic for later: the tirpc library exports functions with the same name as functions that appear in libc, so the behavior of erroring on duplicate symbols needs to be rationalized. Maybe an exemption for libtirpc.so? Are there other libraries that do this?) Most of alternative memory allocation libraries provide their own free/malloc replacements to be used with LD_PRELOAD, e.g. jemalloc. Good point. But I'm mostly concerned with the libraries that binaries link directly against, since those are the cases where the got-audit will always see symbol duplication. Yes, it is definitely an interesting test. Thank you for investing your time and resources into this. Thanks. I'll keep plugging away at it. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning some packages
Considering this, I am also orphaning my package python-ZConfig. It is a dependency for python-ZEO and python-ZODB, which you orphaned, and for python-zdaemon, which (without python-ZEO) will become a leaf package. On 6/26/24 12:11 PM, Jerry James wrote: I have orphaned some packages I no longer use. Many of these supported sagemath. Since F38 reached EOL, there is no sagemath package in any supported Fedora release. Most of these packages are on their latest version, have no open bugs, and are not used by any other package in Fedora. Exceptions are noted below. Orphaned packages: coxeter ecl: used by maxima eclib freetdi-gala gmp-ecm: used by giac gnofract4d jmol jni-inchi libhomfly mcqd minisat2: used by cbmc and link-grammar ocaml-ppx-import primecount python-BTrees python-ZEO python-ZODB python-ZODB3 python-j1m.sphinxautozconfig python-persistent: version 6.0 is available python-pplpy python-primecountpy python-sphinxcontrib-zopeext python-tdlib: version 0.9.3 is available python-zodbpickle python-zope-testrunner: used by python-flexmock, python-lazr-config, python-lazr-delegates, python-repoze-sphinx-autointerface, python-zope-configuration, python-zope-event, python-zope-i18nmessagid, python-zope-schema python-zopeundo rubiks sharedmeataxe sirocco stp symmetrica tlx -- ___ 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 Bootable Containers Initiative Updates
Last month, the Fedora Council approved a Community Initiative [1] aimed at enhancing collaboration among image-based Fedora variants (like CoreOS, IoT and Atomic Desktop) and empowering other projects and individual users to create their own Fedora-based derivatives by working together on bootable container technologies. We've been holding meetings and chatting on matrix, and have been compiling a list of issues [2] and a general roadmap [3] aligned around convergence among the different image-based Fedora workgroups, and a set of cross-cutting feature areas related to composefs. anaconda, CI, dnf and partial pulls with zstd:chunked. If you're interested in getting involved, join us for our meetings every Tuesday at 14:00 UTC (https://meet.google.com/poh-xmxm-qyc) or reach out on matrix in #bootc:fedoraproject.org. If you want to learn more about the technology, there were a few talks related to Bootable Containers at Devconf.cz earlier this month that are worth checking out: - Keynote: What if you could boot a container? - DevConf.CZ 2024 https://www.youtube.com/watch?v=ERVyBc_fElY - Customize your OS like a container - https://www.youtube.com/watch?v=fDvE3hbmLUo - Streamlining bootable container workflows with podman-bootc - https://www.youtube.com/watch?v=uLPyeXmIdyE [1] https://fedoramagazine.org/get-involved-with-fedora-bootable-containers/ [2] https://gitlab.com/fedora/bootc/tracker/-/issues [3] https://gitlab.com/fedora/bootc/tracker/-/issues/24 -- Jason Brooks He/Him Senior Manager, Community Architects & Infrastructure Red Hat Open Source Program Office (OSPO) https://community.redhat.com | https://osci.io -- ___ 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
Planned Outage - fedorapeople.org - 2024-06-27 21:00 UTC
There will be an outage starting at 2024-06-27 21:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-06-27 21:00 UTC' Reason for outage: We will be moving the fedorapeople.org vm to a RHEL9 install. During the outage repos and access to the server will be unavailable as we sync data from the old vm. Additionally, we will be pointing fedoraplanet.org to a new application that pulls rss feeds from the fedora account system instead of using .planet files. Please make sure your rss feed(s) are set in your account to continue sindicating them on fedoraplanet.org Affected Services: fedorapeople.org and all data stored there. Ticket Link: https://pagure.io/fedora-infrastructure/issue/12008 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/ signature.asc Description: PGP signature -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-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: Orphaning some packages
On Wed, Jun 26, 2024 at 10:11 AM Jerry James wrote: > I have orphaned some packages I no longer use. Many of these > supported sagemath. Since F38 reached EOL, there is no sagemath > package in any supported Fedora release. Most of these packages are > on their latest version, have no open bugs, and are not used by any > other package in Fedora. Exceptions are noted below. Now that I sent the previous email, I realize I should have orphaned a few more. Here they are: - latte-integrale - naga - python-pytest-cython - python-sphinxext-rediraffe: used by python-pyqtgraph -- 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
Re: Bodhi update for mesa stuck waiting on test gating?
On Wed, 2024-06-26 at 14:06 -0400, Scott Talbert wrote: > Hi, > > Can someone please check this update for mesa? [1] > > If I'm reading the results correctly, it seems like it is waiting on > update.server_freeipa_replication_replica for 64bit server, but if you > click on that test, it shows that test passed 3 hours ago. Ugh, it's a thing that happens occasionally and I can't figure out why. Somewhere along the chain (openQA should generate an internal event, a plugin I wrote for openQA receives it and generates a fedora-messaging message, a message listener receives the message and sends a report to resultsdb) something breaks occasionally, and I'm not sure what - either openQA isn't generating the internal "job done" event at all, or my plugin isn't receiving it or is having trouble dealing with it somehow, but no idea which one exactly is happening or why. It's rather hard to figure out. There is a dumb check script running every 24 hours now that catches cases like this and fixes them up, so it would have got cleaned up soonish, but I've gone ahead and done it manually for this one. Sorry for the trouble. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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
Bodhi update for mesa stuck waiting on test gating?
Hi, Can someone please check this update for mesa? [1] If I'm reading the results correctly, it seems like it is waiting on update.server_freeipa_replication_replica for 64bit server, but if you click on that test, it shows that test passed 3 hours ago. Thanks, Scott [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-2396f3423d -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 6/26/24 5:24 AM, Florian Weimer wrote: * Miroslav Suchý: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # Seehttps://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? to clarify how a package maintainer might view this - my thinking is that seeing "LicenseRef-Callaway-GPLv2" would be a reminder that they need to generally check the actual license, and likely check whether this was intended to be GPL-2.0-only or GPL-2.0-or-later (assuming that GPLv2 was correct to begin with) Is that what you are thinking too, Miro? Could you add an HTML anchor with GPLv2 specific information? Otherwise it looks a bit silly to anyone who isn't familiar with the GPLv2 ambiguity, and will likely result in unchecked replacement with GPL-2.0-only in many cases. Thanks, Florian -- ___ legal mailing list --le...@lists.fedoraproject.org To unsubscribe send an email tolegal-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/le...@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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 6/26/24 8:41 AM, Richard Fontana wrote: On Wed, Jun 26, 2024 at 10:24 AM Jerry James wrote: On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý wrote: We will get valid SPDX formula. Some legacy license names contain spaces. Simply slapping "LicenseRef-Fedora-" on the front will only affect the first word of such multiword license names, resulting in an invalid SPDX formula. We would also have to convert those spaces to hyphens, right? Correct, if I'm reading the SPDX license expression grammar correctly (https://spdx.github.io/spdx-spec/v3.0//annexes/SPDX-license-expressions/), spaces would have to be converted and the hyphen is probably the only sensible separator. So e.g. "BSD with advertising" becomes "LicenseRef-Callaway-BSD-with-advertising". correct re: spacing and your example -- ___ 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: Strange error building on Rawhide
On Wed, 26 Jun 2024 at 10:32, Ron Olson wrote: > > Hey all- > > I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very > end, to the %install section, then errors out with: > > + /usr/bin/add-determinism --brp -j4 > /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT > Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is > outside of $RPM_BUILD_ROOT > error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) > > Never, ever seen that particular message. I’m assuming the RPM build tools on > Rawhide are newer and perhaps there’s something I should be adding to my spec > file that I’m not aware of, as often is the case. :\ > Does it happen to any spec rebuild or just this one? And if this one what is the spec file? The /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT is outside of the buildroot as that should be /home/rolson/rpmbuild/BUILDROOT/ so I could see a bad definition somewhere trying to set up a copy to the wrong destination > Thanks for any help, > > Ron > > -- > ___ > 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 -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: Strange error building on Rawhide
So you're runnning rpmbuild in a toolbox, right? Can you reproduce this with mock? [ I think we bottom post here in general, but I kept with your choice. Feel free to reorder ... ] Ron Olson venit, vidit, dixit 2024-06-26 17:35:11: > Dunno if it should matter, but this is: Fedora Linux 41 (Toolbx > Container Image Prerelease), running on a Sway Atomic machine (Fedora > Linux 40.20240613.0 (Sway Atomic)). > > On 26 Jun 2024, at 10:31, Ron Olson wrote: > > > Hey all- > > > > I’m trying to build Swift 6 on Rawhide and it looks like it gets to > > the very end, to the %install section, then errors out with: > > > > ``` > > + /usr/bin/add-determinism --brp -j4 > > /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT > > Error: Path > > "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is > > outside of $RPM_BUILD_ROOT > > error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) > > ``` > > > > Never, ever seen that particular message. I’m assuming the RPM build > > tools on Rawhide are newer and perhaps there’s something I should be > > adding to my spec file that I’m not aware of, as often is the case. > > :\ > > > > Thanks for any help, > > > > Ron -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
Unfortunatelly I do not see a clear consensus here. I think that exactly for such cases we have good instution: FESCO. I filed https://pagure.io/fesco/issue/3230 and I will follow FESCO decision. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ 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
Orphaning some packages
I have orphaned some packages I no longer use. Many of these supported sagemath. Since F38 reached EOL, there is no sagemath package in any supported Fedora release. Most of these packages are on their latest version, have no open bugs, and are not used by any other package in Fedora. Exceptions are noted below. Orphaned packages: coxeter ecl: used by maxima eclib freetdi-gala gmp-ecm: used by giac gnofract4d jmol jni-inchi libhomfly mcqd minisat2: used by cbmc and link-grammar ocaml-ppx-import primecount python-BTrees python-ZEO python-ZODB python-ZODB3 python-j1m.sphinxautozconfig python-persistent: version 6.0 is available python-pplpy python-primecountpy python-sphinxcontrib-zopeext python-tdlib: version 0.9.3 is available python-zodbpickle python-zope-testrunner: used by python-flexmock, python-lazr-config, python-lazr-delegates, python-repoze-sphinx-autointerface, python-zope-configuration, python-zope-event, python-zope-i18nmessagid, python-zope-schema python-zopeundo rubiks sharedmeataxe sirocco stp symmetrica tlx -- 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
Re: Strange error building on Rawhide
Dunno if it should matter, but this is: Fedora Linux 41 (Toolbx Container Image Prerelease), running on a Sway Atomic machine (Fedora Linux 40.20240613.0 (Sway Atomic)). On 26 Jun 2024, at 10:31, Ron Olson wrote: Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 10:24 AM Jerry James wrote: > > On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý wrote: > > We will get valid SPDX formula. > > Some legacy license names contain spaces. Simply slapping > "LicenseRef-Fedora-" on the front will only affect the first word of > such multiword license names, resulting in an invalid SPDX formula. > We would also have to convert those spaces to hyphens, right? Correct, if I'm reading the SPDX license expression grammar correctly (https://spdx.github.io/spdx-spec/v3.0//annexes/SPDX-license-expressions/), spaces would have to be converted and the hyphen is probably the only sensible separator. So e.g. "BSD with advertising" becomes "LicenseRef-Callaway-BSD-with-advertising". Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
Dne 26. 06. 24 v 16:28 Vít Ondruch napsal(a): Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a): On 26. 06. 24 5:59, Richard Fontana wrote: On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: On 25. 06. 24 22:50, Miroslav Suchý wrote: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? I don't understand what is the benefit of doing this at all. Sorry. The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.) What is the benefit of that outcome? I understand the benefit of SPDX in general. I don't understand the benefit of converting everything to custom LicenseRef identifiers. My original proposal was to basically replace all remaining Callaway licenses by something what has become `LicenseRef-Callaway-` prefix. The main motivation is to make sure we properly distinguish between Callaway MIT and SPDX MIT definitions and similar cases. This IMHO should have been done from the start, prior we converted even single license. Also, my intention was to avoid comments such: ~~~ # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed ~~~ This kind of comments are always wrong IMHO. But if Mirek was talking about modifying all remaining Callaway identifiers across the whole Fedora (which was not very clear), then I am fine with the proposal as it is (including comment ;) ). BTW I also don't see the immediate need to convert everything into SPDX. But I'll rather have `LicenseRef-Callaway-` prefixed license identifiers than having around comments such as the above or `SPDX` in changelog entries. Vít Vít We are already making it clear that the expressions are legacy by... being legacy. Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion? OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Strange error building on Rawhide
Hey all- I’m trying to build Swift 6 on Rawhide and it looks like it gets to the very end, to the %install section, then errors out with: ``` + /usr/bin/add-determinism --brp -j4 /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" is outside of $RPM_BUILD_ROOT error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) ``` Never, ever seen that particular message. I’m assuming the RPM build tools on Rawhide are newer and perhaps there’s something I should be adding to my spec file that I’m not aware of, as often is the case. :\ Thanks for any help, Ron-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a): On 26. 06. 24 5:59, Richard Fontana wrote: On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: On 25. 06. 24 22:50, Miroslav Suchý wrote: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? I don't understand what is the benefit of doing this at all. Sorry. The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.) What is the benefit of that outcome? I understand the benefit of SPDX in general. I don't understand the benefit of converting everything to custom LicenseRef identifiers. My original proposal was to basically replace all remaining Callaway licenses by something what has become `LicenseRef-Callaway-` prefix. The main motivation is to make sure we properly distinguish between Callaway MIT and SPDX MIT definitions and similar cases. This IMHO should have been done from the start, prior we converted even single license. Also, my intention was to avoid comments such: ~~~ # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed ~~~ This kind of comments are always wrong IMHO. But if Mirek was talking about modifying all remaining Callaway identifiers across the whole Fedora (which was not very clear), then I am fine with the proposal as it is (including comment ;) ). Vít We are already making it clear that the expressions are legacy by... being legacy. Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion? OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý wrote: > We will get valid SPDX formula. Some legacy license names contain spaces. Simply slapping "LicenseRef-Fedora-" on the front will only affect the first word of such multiword license names, resulting in an invalid SPDX formula. We would also have to convert those spaces to hyphens, right? -- 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
Re: Enabling RPM based sysuser handling
Now that the dust from 4.20 landing has settled a bit...
On 6/6/24 23:25, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
I think all the issues wrt. sysusers in systemd and setup have been
resolved.
On Tue, May 14, 2024 at 11:34:51AM +, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:
On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
I outlined the migration process last year in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
but failed to follow-up, so I'm glad to see this getting revisited.
I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.
It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)
I was confused here. setup generates its two sysusers files from the
passwd/groups file that it distributes, so they will always match.
We added the missing group defintions that systemd-udev relies on to
default groups file distributed by setup (in setup-2.15.0-3). The next
build of systemd (256~rc4-1) will drop its sysusers.d/basic.conf file.
Please carry on with the enablement of rpm sysusers handling ;)
Excellent :) With the duplicates gone from systemd basic.conf gone, a
logical next step would be turning on hard dependencies for users and
groups before the F41 mass rebuild (by dropping
rpm-4.19.91-weak-user-group.patch from Fedora rpm).
All the necessary user/group provides should already be in place since
F40 mass rebuild, and it shouldn't matter which mechanism actually
creates the users, so it's not committing to any changes in user/group
handling as such, this is just an extra packaging hygiene step in the
process.
I'll be out for the entire July, but Florian and Michal will be around.
- Panu -
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 02:32:34PM +0200, Miro Hrončok wrote: > On 26. 06. 24 14:17, Miroslav Suchý wrote: > > Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a): > > > > > > Clearly, I must miss something. What do we gain by causing all > > > license tags to conform to the SPDX license expression standard > > > despite actually just using the old tag with extra boilerplate? > > > > We will get valid SPDX formula. And all tools generating SBOMs from RPMs > > can use it and it will produce valid SBOM document. > > > > If we keep the old value, it will not be valid SPDX formula and all > > tools build on top of that have to put if/else into their workflow. > > And what good is a valid SPDX formula if it contains custom identifiers? This has already been answered multiple times now. Tools that process SPDX expressions can now handle Fedora RPMs without needing custom parsing code. This allows querying & reporting on licenses in Fedora packages. The LicenseRef-Callaway- terms that are extracted are still providing useful information about the package license. Not as useful as it would be eventually, due to the historical license minimization, but still none the less useful. It is up to the users of the tools to decide how they interpret the data that is extracted. > If we converted all the Licenses of all our packages to > LicenseRef-Fedora-Unknown, it would still be a valid formula, but clearly, > we would not want that. Or would we? That would be throwing away data that we've got today, so would be a step backwards. 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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 26. 06. 24 14:17, Miroslav Suchý wrote: Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a): Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document. If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow. And what good is a valid SPDX formula if it contains custom identifiers? If we converted all the Licenses of all our packages to LicenseRef-Fedora-Unknown, it would still be a valid formula, but clearly, we would not want that. Or would we? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: 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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a): Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document. If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, 26 Jun 2024 at 05:48, Miro Hrončok wrote: > > On 26. 06. 24 5:59, Richard Fontana wrote: > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: > >> > >> On 25. 06. 24 22:50, Miroslav Suchý wrote: > >>> Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > Could you make the comment something like this? > > # Automatically converted from old format: GPLv2 > # TODO check if there are other licenses to be listed > License: GPL-2.0-only > >>> > >>> We (the Change owners) discussed this on a meeting today. And we agreed > >>> on output: > >>> > >>> # Automatically converted from old format: GPLv2 > >>> # TODO convert to correct SPDX identifier > >>> # See > >>> https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > >>> License: LicenseRef-Callaway-GPLv2 > >>> > >>> This is valid SPDX identifier. But not on the list of Fedora's allowed > >>> licenses, so any QA tool will remind you to check the license. > >>> > >>> What do you think? > >> > >> I don't understand what is the benefit of doing this at all. Sorry. > > > > The benefit I see is that it immediately causes all license tags to > > conform to the SPDX license expression standard, while also making it > > very clear what parts of those license expressions are actually legacy > > elements that have to be examined and replaced. (This assumes we > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > What is the benefit of that outcome? > > I understand the benefit of SPDX in general. > > I don't understand the benefit of converting everything to custom LicenseRef > identifiers. > > We are already making it clear that the expressions are legacy by... being > legacy. > > Clearly, I must miss something. What do we *gain* by causing all license tags > to conform to the SPDX license expression standard despite actually just using > the old tag with extra boilerplate? > > I am not trying to fight this decision, I am genuinely confused: What it is > that makes us hurry this. Why cannot we keep the gradual conversion? > The following is just my take on this and probably not what Richard or Miroslav (and others) are not thinking The biggest reason to get as many licenses into the same format is to help the growing number of Fedora Containers and Fedora Cloud users. Various organizations ranging from Universities to small businesses will be needing to add various 'auditing' tools for Software Bills of Materials in the coming years for various regulatory reasons. Most of this tooling is less than 'robust' and not easily fixed by the users of the software. Running into non-standard fields just means whatever software is rejected as not usable. Using something like `LicenseRef-Callaway-GPLv2` can cut out the user problems while making it clear to the project where work can be done in the future. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: 20240626.n.0 changes
OLD: Fedora-Rawhide-20240625.n.0 NEW: Fedora-Rawhide-20240626.n.0 = SUMMARY = Added images:8 Dropped images: 1 Added packages: 5 Dropped packages:8 Upgraded packages: 128 Downgraded packages: 0 Size of added packages: 638.34 KiB Size of dropped packages:1.83 MiB Size of upgraded packages: 3.30 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 7.90 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Sericea ociarchive x86_64 Path: Sericea/x86_64/images/Fedora-Sericea-Rawhide.20240626.n.0.ociarchive Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240626.n.0.x86_64.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240626.n.0.aarch64.iso Image: Kinoite ociarchive aarch64 Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240626.n.0.ociarchive Image: Silverblue ociarchive aarch64 Path: Silverblue/aarch64/images/Fedora-Silverblue-Rawhide.20240626.n.0.ociarchive Image: Sericea ociarchive aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240626.n.0.ociarchive Image: Cloud_Base vhd-compressed aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Azure.aarch64-Rawhide-20240626.n.0.vhdfixed.xz Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240626.n.0.iso = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20240625.n.0.iso = ADDED PACKAGES = Package: erlang-cache_tab-1.0.30-1.fc41 Summary: Erlang cache table application RPMs:erlang-cache_tab Size:267.31 KiB Package: erlang-epgsql-4.7.1-1.fc41 Summary: Erlang PostgreSQL client library RPMs:erlang-epgsql Size:262.69 KiB Package: rust-onefetch-ascii-2.21.0-1.fc41 Summary: Display colorized ascii art to the terminal RPMs:rust-onefetch-ascii+default-devel rust-onefetch-ascii-devel Size:20.59 KiB Package: rust-onefetch-image-2.21.0-1.fc41 Summary: Display images in the terminal RPMs:rust-onefetch-image+default-devel rust-onefetch-image-devel Size:23.13 KiB Package: rust-uzers0.11-0.11.3-1.fc41 Summary: Library for accessing Unix users and groups RPMs:rust-uzers0.11+cache-devel rust-uzers0.11+default-devel rust-uzers0.11+log-devel rust-uzers0.11+logging-devel rust-uzers0.11+mock-devel rust-uzers0.11-devel Size:64.62 KiB = DROPPED PACKAGES = Package: future-1.0.0-1.fc41 Summary: Easy, clean, reliable Python 2/3 compatibility RPMs:python3-future Size:998.29 KiB Package: preprocess-2.0.0-11.fc40 Summary: A portable multi-language file Python2 preprocessor RPMs:python3-preprocess Size:39.32 KiB Package: rust-atk0.15-0.15.1-4.fc40 Summary: Rust bindings for the ATK library RPMs:rust-atk0.15+default-devel rust-atk0.15+dox-devel rust-atk0.15+v2_30-devel rust-atk0.15+v2_32-devel rust-atk0.15+v2_34-devel rust-atk0.15+v2_38-devel rust-atk0.15-devel Size:97.02 KiB Package: rust-atomic0.5-0.5.3-1.fc41 Summary: Generic Atomic wrapper type RPMs:rust-atomic0.5+default-devel rust-atomic0.5+fallback-devel rust-atomic0.5+nightly-devel rust-atomic0.5+std-devel rust-atomic0.5-devel Size:48.26 KiB Package: rust-gdk0.15-0.15.4-4.fc40 Summary: Rust bindings for the GDK 3 library RPMs:rust-gdk0.15+default-devel rust-gdk0.15+dox-devel rust-gdk0.15+v3_20-devel rust-gdk0.15+v3_22-devel rust-gdk0.15+v3_24-devel rust-gdk0.15-devel Size:141.91 KiB Package: rust-gtk-sys0.15-0.15.3-4.fc40 Summary: FFI bindings to libgtk-3 RPMs:rust-gtk-sys0.15+default-devel rust-gtk-sys0.15+dox-devel rust-gtk-sys0.15+v3_20-devel rust-gtk-sys0.15+v3_22-devel rust-gtk-sys0.15+v3_22_26-devel rust-gtk-sys0.15+v3_22_27-devel rust-gtk-sys0.15+v3_22_29-devel rust-gtk-sys0.15+v3_22_30-devel rust-gtk-sys0.15+v3_22_6-devel rust-gtk-sys0.15+v3_24-devel rust-gtk-sys0.15+v3_24_1-devel rust-gtk-sys0.15+v3_24_11-devel rust-gtk-sys0.15+v3_24_30-devel rust-gtk-sys0.15+v3_24_8-devel rust-gtk-sys0.15+v3_24_9-devel rust-gtk-sys0.15-devel Size:231.49 KiB Package: rust-gtk3-macros0.15-0.15.6-3.fc40 Summary: Rust bindings for the GTK 3 library RPMs:rust-gtk3-macros0.15+default-devel rust-gtk3-macros0.15-devel Size:22.30 KiB Package: rust-regex-syntax0.7-0.7.5-2.fc40 Summary: Regular expression parser RPMs:rust-regex-syntax0.7+arbitrary-devel rust-regex-syntax0.7+default-devel rust-regex-syntax0.7+std-devel rust-regex-syntax0.7+unicode-age-devel rust-regex-syntax0.7+unicode-bool-devel rust-regex-syntax0.7+unicode-case-devel rust-regex-syntax0.7+unicode-devel rust-regex-syntax0.7+unicode-gencat-devel rust-regex-syntax0.7+unicode-perl-devel rust-regex-syntax0.7+unicode-script-devel rust-regex-syntax0.7+unicode-segment-devel rust-regex-syntax0.7-devel Size:291.02 KiB = UPGRADED PACKAGES = Package: Lmod-8.7.43-1.fc41 Old package: Lmod-8.7.39-1.fc41 Summary
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
* Miroslav Suchý: > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): >> >> Could you make the comment something like this? >> >> # Automatically converted from old format: GPLv2 >> # TODO check if there are other licenses to be listed >> License: GPL-2.0-only > > We (the Change owners) discussed this on a meeting today. And we agreed on > output: > > # Automatically converted from old format: GPLv2 > # TODO convert to correct SPDX identifier > # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > License: LicenseRef-Callaway-GPLv2 > > This is valid SPDX identifier. But not on the list of Fedora's allowed > licenses, so any QA tool will remind you to check the license. > > What do you think? Could you add an HTML anchor with GPLv2 specific information? Otherwise it looks a bit silly to anyone who isn't familiar with the GPLv2 ambiguity, and will likely result in unchecked replacement with GPL-2.0-only in many cases. Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 11:22:15AM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 26, 2024 at 11:47:55AM +0200, Miro Hrončok wrote: > > On 26. 06. 24 5:59, Richard Fontana wrote: > > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: > > > > > > > > On 25. 06. 24 22:50, Miroslav Suchý wrote: > > > > > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > > > > > > > > > > > Could you make the comment something like this? > > > > > > > > > > > ># Automatically converted from old format: GPLv2 > > > > > ># TODO check if there are other licenses to be listed > > > > > >License: GPL-2.0-only > > > > > > > > > > We (the Change owners) discussed this on a meeting today. And we > > > > > agreed on output: > > > > > > > > > > # Automatically converted from old format: GPLv2 > > > > > # TODO convert to correct SPDX identifier > > > > > # See > > > > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > > > > > License: LicenseRef-Callaway-GPLv2 > > > > > > > > > > This is valid SPDX identifier. But not on the list of Fedora's allowed > > > > > licenses, so any QA tool will remind you to check the license. > > > > > > > > > > What do you think? > > > > > > > > I don't understand what is the benefit of doing this at all. Sorry. > > > > > > The benefit I see is that it immediately causes all license tags to > > > conform to the SPDX license expression standard, while also making it > > > very clear what parts of those license expressions are actually legacy > > > elements that have to be examined and replaced. (This assumes we > > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > > > What is the benefit of that outcome? > > > > I understand the benefit of SPDX in general. > > > > I don't understand the benefit of converting everything to custom LicenseRef > > identifiers. > > If you have tools which process SPDX expressions, with a full conversion > of outstanding RPMs to LicenseRef, you would now be able to use these > tools on Fedora specfiles (more) reliably. Another advantage is that it makes it (painfully) obvious when the legacy license tag is used. Instead of a free-style comment in the spec file or having to dig through %changelog to see if it mentions SPDX, the information that the license needs reviewing/updating is available in machine-readable form from the License tag. You can even use repoquery to list all such cases. > Fedora could (should) also apply CI tests that enforce a valid SPDX > expression, as there are almost certainly some accidental errors that > have crept in (I know I've made some). Yeah, I think we'll want to add a linter for this once the conversion is mostly complete. We can't really do that now. > These are small, but still tangible benefits, over having the ill-defined > mixture of SPDX and Callaway expressions live on for more years. > > Fully replacing the LicenseRef-Callaway terms within the expressions > would still remain highly desirable, ongoing work. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 11:47:55AM +0200, Miro Hrončok wrote: > On 26. 06. 24 5:59, Richard Fontana wrote: > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: > > > > > > On 25. 06. 24 22:50, Miroslav Suchý wrote: > > > > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > > > > > > > > > Could you make the comment something like this? > > > > > > > > > ># Automatically converted from old format: GPLv2 > > > > ># TODO check if there are other licenses to be listed > > > > >License: GPL-2.0-only > > > > > > > > We (the Change owners) discussed this on a meeting today. And we agreed > > > > on output: > > > > > > > > # Automatically converted from old format: GPLv2 > > > > # TODO convert to correct SPDX identifier > > > > # See > > > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > > > > License: LicenseRef-Callaway-GPLv2 > > > > > > > > This is valid SPDX identifier. But not on the list of Fedora's allowed > > > > licenses, so any QA tool will remind you to check the license. > > > > > > > > What do you think? > > > > > > I don't understand what is the benefit of doing this at all. Sorry. > > > > The benefit I see is that it immediately causes all license tags to > > conform to the SPDX license expression standard, while also making it > > very clear what parts of those license expressions are actually legacy > > elements that have to be examined and replaced. (This assumes we > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > What is the benefit of that outcome? > > I understand the benefit of SPDX in general. > > I don't understand the benefit of converting everything to custom LicenseRef > identifiers. If you have tools which process SPDX expressions, with a full conversion of outstanding RPMs to LicenseRef, you would now be able to use these tools on Fedora specfiles (more) reliably. Fedora could (should) also apply CI tests that enforce a valid SPDX expression, as there are almost certainly some accidental errors that have crept in (I know I've made some). These are small, but still tangible benefits, over having the ill-defined mixture of SPDX and Callaway expressions live on for more years. Fully replacing the LicenseRef-Callaway terms within the expressions would still remain highly desirable, ongoing work. 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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024, 11:48 Miro Hrončok wrote: > On 26. 06. 24 5:59, Richard Fontana wrote: > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok > wrote: > >> > >> On 25. 06. 24 22:50, Miroslav Suchý wrote: > >>> Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > Could you make the comment something like this? > > # Automatically converted from old format: GPLv2 > # TODO check if there are other licenses to be listed > License: GPL-2.0-only > >>> > >>> We (the Change owners) discussed this on a meeting today. And we > agreed on output: > >>> > >>> # Automatically converted from old format: GPLv2 > >>> # TODO convert to correct SPDX identifier > >>> # See > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > >>> License: LicenseRef-Callaway-GPLv2 > >>> > >>> This is valid SPDX identifier. But not on the list of Fedora's allowed > >>> licenses, so any QA tool will remind you to check the license. > >>> > >>> What do you think? > >> > >> I don't understand what is the benefit of doing this at all. Sorry. > > > > The benefit I see is that it immediately causes all license tags to > > conform to the SPDX license expression standard, while also making it > > very clear what parts of those license expressions are actually legacy > > elements that have to be examined and replaced. (This assumes we > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > What is the benefit of that outcome? > > I understand the benefit of SPDX in general. > > I don't understand the benefit of converting everything to custom > LicenseRef > identifiers. > > We are already making it clear that the expressions are legacy by... being > legacy. > > Clearly, I must miss something. What do we *gain* by causing all license > tags > to conform to the SPDX license expression standard despite actually just > using > the old tag with extra boilerplate? > > I am not trying to fight this decision, I am genuinely confused: What it > is > that makes us hurry this. Why cannot we keep the gradual conversion? > To make managers or scrum masters happy? I don't know either ... Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > Fedora Matrix: 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 > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 26. 06. 24 5:59, Richard Fontana wrote: On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: On 25. 06. 24 22:50, Miroslav Suchý wrote: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? I don't understand what is the benefit of doing this at all. Sorry. The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.) What is the benefit of that outcome? I understand the benefit of SPDX in general. I don't understand the benefit of converting everything to custom LicenseRef identifiers. We are already making it clear that the expressions are legacy by... being legacy. Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: 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: List of long term FTBFS packages to be retired in July
W dniu 25.06.2024 o 23:29, Miro Hrončok pisze: Depending on: libratbag (1) piper (maintained by: vtrefny) piper-0.7-8.fc41.noarch requires libratbag-ratbagd piper-0.7-8.fc41.src requires libratbag-ratbagd Added fix to https://bugzilla.redhat.com/show_bug.cgi?id=2225974 report. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in July
Hello! I'll take care of erlang-hex_core shortly. On Tue, Jun 25, 2024 at 11:30 PM Miro Hrončok wrote: ... > erlang-hex_core @erlang-maint-sig, peter ... > Depending on: erlang-hex_core (85) > erlang-rebar3 (maintained by: @erlang-maint-sig, peter) > erlang-rebar3-3.22.0-4.fc40.noarch requires erlang-hex_core > erlang-rebar3-3.22.0-4.fc40.src requires erlang-hex_core > > elixir (maintained by: codeblock, fnux) > elixir-1.16.2-1.fc41.src requires erlang-rebar3 > > erlang-amf (maintained by: peter) > erlang-amf-0-0.34.20110224git8fea004.fc41.src requires > erlang-rebar3 > > erlang-base64url (maintained by: @erlang-maint-sig, bowlofeggs, peter) > erlang-base64url-1.0.1-15.fc41.src requires erlang-rebar3 > > erlang-basho_stats (maintained by: peter) > erlang-basho_stats-1.1.0-12.fc41.src requires erlang-rebar3 > > erlang-bbmustache (maintained by: @erlang-maint-sig, peter) > erlang-bbmustache-1.12.2-10.fc41.src requires erlang-rebar3 > > erlang-bear (maintained by: peter) > erlang-bear-1.0-11.fc41.src requires erlang-rebar3 > > erlang-bitcask (maintained by: peter) > erlang-bitcask-2.1.0-16.fc41.src requires erlang-rebar3 > > erlang-certifi (maintained by: @erlang-maint-sig, peter) > erlang-certifi-2.9.0-7.fc40.src requires erlang-rebar3 > > erlang-cf (maintained by: @erlang-maint-sig, peter) > erlang-cf-0.3.1-18.fc41.src requires erlang-rebar3 > > erlang-chronos (maintained by: peter) > erlang-chronos-0.5.1-22.fc41.src requires erlang-rebar3 > > erlang-clique (maintained by: @erlang-maint-sig, bowlofeggs, peter) > erlang-clique-0.3.12-8.fc41.src requires erlang-rebar3 > > erlang-cluster_info (maintained by: @erlang-maint-sig, bowlofeggs, > peter) > erlang-cluster_info-2.1.0-14.fc41.src requires erlang-rebar3 > > erlang-cowboy (maintained by: peter) > erlang-cowboy-2.12.0-2.fc41.src requires erlang-rebar3 > > erlang-cowlib (maintained by: peter) > erlang-cowlib-2.13.0-2.fc41.src requires erlang-rebar3 > > erlang-ct_helper (maintained by: peter) > erlang-ct_helper-0-0.1.20240118git395618e.fc41.src requires > erlang-rebar3 > > erlang-cth_readable (maintained by: @erlang-maint-sig, peter) > erlang-cth_readable-1.5.1-10.fc41.src requires erlang-rebar3 > > erlang-cuttlefish (maintained by: @erlang-maint-sig, bowlofeggs, > peter) > erlang-cuttlefish-2.1.1-8.fc41.src requires erlang-rebar3 > > erlang-edown (maintained by: peter) > erlang-edown-0.8.4-10.fc41.src requires erlang-rebar3 > > erlang-eflame (maintained by: peter) > erlang-eflame-0-0.43.20150721gita085181.fc41.src requires > erlang-rebar3 > > erlang-egeoip (maintained by: peter) > erlang-egeoip-1.1-24.20140111git4efda2c.fc41.src requires > erlang-rebar3 > > erlang-emmap (maintained by: peter) > erlang-emmap-2.0.11-1.20230313gitf4a6f82.fc41.src requires > erlang-rebar3 > > erlang-eradius (maintained by: @erlang-maint-sig, bowlofeggs, peter) > erlang-eradius-2.3.1-8.fc41.src requires erlang-rebar3 > > erlang-erlsom (maintained by: lkundrak, peter) > erlang-erlsom-1.5.0-15.fc41.src requires erlang-rebar3 > > erlang-erlware_commons (maintained by: @erlang-maint-sig, peter) > erlang-erlware_commons-1.6.0-12.fc41.src requires > erlang-rebar3 > > erlang-erlydtl (maintained by: peter) > erlang-erlydtl-0.14.0-6.fc41.src requires erlang-rebar3 > > erlang-eunit_formatters (maintained by: @erlang-maint-sig, peter) > erlang-eunit_formatters-0.5.0-17.fc41.src requires > erlang-rebar3 > > erlang-exometer_core (maintained by: peter) > erlang-exometer_core-1.6.1-10.fc41.src requires erlang-rebar3 > > erlang-fast_tls (maintained by: @erlang-maint-sig, bowlofeggs, > jcline, peter) > erlang-fast_tls-1.1.15-8.fc41.src requires erlang-rebar3 > > erlang-fast_xml (maintained by: @erlang-maint-sig, bowlofeggs, > jcline, peter) > erlang-fast_xml-1.1.49-5.fc40.src requires erlang-rebar3 > > erlang-fast_yaml (maintained by: @erlang-maint-sig, bowlofeggs, > jcline, peter) > erlang-fast_yaml-1.0.33-8.fc41.src requires erlang-rebar3 > > erlang-folsom (maintained by: peter) > erlang-folsom-1.0-11.fc41.src requires erlang-rebar3 > > erlang-fuse (maintained by: peter) > erlang-fuse-2.5.0-10.fc41.src requires erlang-rebar3 > > erlang-gen_leader (maintain
