Re: Rawhide update gating: mass rebuild issues
Hi, Adam! On Tuesday, 25 July 2023 at 19:31, Adam Williamson wrote: > Hi folks! Just wanted to drop a note for anyone who noticed their > Rawhide updates stuck in gating for an unusually long time > yesterday/today. Thanks for the write-up. It shows how much hard work is being done in the background to keep our wheels turning. I appreciate it! [...] > Bad deps in *anything* in the environment can break the tests > because they prevent `dnf update` from succeeding at all, so the > updated packages never get installed Definitely. Any updates that break dependencies should not make it to rawhide or stable repos. Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Wednesday, 26 July 2023 at 06:23, Ralf Corsépius wrote: > Am 23.07.23 um 00:39 schrieb Neal Gompa: > > Actually, why wouldn't this be used everywhere? > > Because fwupd only works on a small set of machines? Define small. :) It works, for example, on any machine that has a Logitech Unifying/ Lightspeed/Nano Receiver. I used it to upgrade firmware on the three or four dongles that I have around with a security fix (that would require finding a Windows box and plugging them in there otherwise). Also, UEFI dbx updates are available through fwupdmgr, which I think affects a large set of machines (all UEFI). Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
Am 23.07.23 um 00:39 schrieb Neal Gompa: Actually, why wouldn't this be used everywhere? Because fwupd only works on a small set of machines? Ralf ___ 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 39 Mass Rebuild
On Wed, Jul 26, 2023 at 01:46:19AM +0200, Sandro wrote: > On 25-07-2023 18:23, Kevin Fenzi wrote: > > On Tue, Jul 25, 2023 at 02:23:00AM +0200, Sandro wrote: > > > On 24-07-2023 20:30, Samyak Jain wrote: > > > > 21426 builds have been tagged into f39, there are currently 1017 failed > > > > builds > > > > that need to be addressed by the package maintainers. FTBFS bugs will be > > > > filed shortly. > > > > > > Will all the Python packages that failed during the Python3.12 mass > > > rebuild > > > and haven't been fixed yet, receive another FTBFS/FTI bug? Or will those > > > be > > > filtered out? > > > > If they already have a FTBFS bug (attached to the tracker) they will not > > get a new bug. If they do not, they will. :) > > Well, the first batch of bugs for the Python3.12 mass rebuild were mostly > FTI bugs, even though some of them turned out to be in fact FTBFS. > > Since FTI and FTBFS use separate tracker bugs, I/we now have two different > bugs pointing at the same issue: > > FTI: https://bugzilla.redhat.com/show_bug.cgi?id=2220504 > FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2226331 Yeah, the ftbfs script doesn't know about the fti bugs. We could extend it, but they are different (but very related) things. > I also noticed that the FTBFS bugs filed after the f39 mass rebuild have log > files attached. While not harmful, wouldn't it be better to just link to the > failed build in Koji, that has all the logs for all the archs stored anyway? > Especially since large log files are truncated. After a while, the logs will get garbage collected and no longer will be available in koji. Of course at this point you can do a scratch (or real) build to get current logs, but the bugs have some logs so you can see what the failure was at the time it happened. ;) We don't attach full logs because some packages have logs that are... crazy large. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild
On 25-07-2023 18:23, Kevin Fenzi wrote: On Tue, Jul 25, 2023 at 02:23:00AM +0200, Sandro wrote: On 24-07-2023 20:30, Samyak Jain wrote: 21426 builds have been tagged into f39, there are currently 1017 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Will all the Python packages that failed during the Python3.12 mass rebuild and haven't been fixed yet, receive another FTBFS/FTI bug? Or will those be filtered out? If they already have a FTBFS bug (attached to the tracker) they will not get a new bug. If they do not, they will. :) Well, the first batch of bugs for the Python3.12 mass rebuild were mostly FTI bugs, even though some of them turned out to be in fact FTBFS. Since FTI and FTBFS use separate tracker bugs, I/we now have two different bugs pointing at the same issue: FTI: https://bugzilla.redhat.com/show_bug.cgi?id=2220504 FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2226331 I also noticed that the FTBFS bugs filed after the f39 mass rebuild have log files attached. While not harmful, wouldn't it be better to just link to the failed build in Koji, that has all the logs for all the archs stored anyway? Especially since large log files are truncated. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora-review workarounds for dnf5
On 25-07-2023 04:47, Michel Alexandre Salim wrote: Once this lands in F38, Fedora Review Service should be fixed, unless I'm missing something. First of all, thanks for bringing fedora-review back. I rely on it quite a bit reviewing my own packages as well as for official reviews. I noticed that in f39 builds in Copr the directory containing the results is now named after the package. Comparing that to the "traditional" fedora-review directory in f38 builds, I miss the `licensecheck.txt` file. The contents of the fedora-review directory ($PACKAGE_NAME) in f39 look more alike to a local fedora-review, which is fine. But `licensecheck.txt` is invaluable for checking licenses of generated files. Just now I finished a review using the f38 build, which detected two additional licenses in generated files, that went unnoticed by the submitter. Can `licensecheck.txt` be added back to f39 fedora-review runs, please? -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-uamqp + python-azure-eventhub
Hey there, I plan to orphan these two packages: python-uamqp python-azure-eventhub They were originally packaged to help with azure-cli packaging, but they are no longer used by the upstream package. I couldn't find any other packages which depend on these two packages. -- Major Hayden ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora-review workarounds for dnf5
Thank you very much Michel for going through the release. It couldn't be easy. There is a reported bug in Bodhi, so it will need some minor fixups but we are close. Really looking forward to it. Jakub On Tue, Jul 25, 2023 at 4:48 AM Michel Alexandre Salim wrote: > > Hi all, > > On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote: > > Like many of you, I have been quite inconvenienced because of > > dnf5-related breakage of fedora-review. I've been monkeying with it > > today and finally got a successful run of fedora-review after making > > the following changes [*]. > > > I'm happy (and relieved) to say that a fixed fedora-review is ready for > testing: > > https://bodhi.fedoraproject.org/updates/?search=&packages=fedora-review&status=pending&status=testing > > This uses Jakub Kadlcik's initial PR to use dnf-3 instead of dnf, so we > don't necessarily commit ourselves to using DNF 5 until the we know for > sure if Fedora 39 will ship with DNF 5 or not. > > Thanks also to Benjamin A. Beasley, Miro Hrončok, Benson Muite, Jitka > Plesnikova, Pavel Raiskup, and Sérgio M. Basto for contributing changes > shipped in this release. > > 0.10.0 was supposed to have gone out 3 months ago, but blocked by > changes in setuptools/distutils causing our release script to generate > an incomplete tarball. I've done a more thorough fix that will hopefully > hold until we rewrite our build process be PEP 517 compliant for the > next release. > > Once this lands in F38, Fedora Review Service should be fixed, unless > I'm missing something. > > Best regards, > > -- > Michel Alexandre Salim > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > ___ > 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 39 Mass Rebuild
On Tue, Jul 25, 2023 at 3:58 PM Fabio Valentini wrote: > > As far as I can tell, the toolchain proposal was announced on the devel / > devel-announce lists on July 7 but never submitted to FESCo for a vote. Looks > like the process broke down somewhere along the way. I think it was actually a couple of days before that, but no matter. In either case it was announced more than a week after it was submitted (which happened to be the date of the deadline). So the problem is two-fold: 1. It sat in "ChangeReadyForWrangler" for a week during a rather time-critical part of the cycle 2. It never made it to FESCo I could be salty about this, but I'll refrain. The point is that altering the schedule wouldn't make a difference here because the schedule isn't the problem. It's that there's not someone whose actual job is wrangling Change proposals. amoloney has done a great job picking up many of my former duties while also doing her full time job, but as that sentence implies, there are capacity issues. Of course, earlier submission is better when possible but I don't know if it was possible in this case and it's not clear it would have helped this specific issue. -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton ___ 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: Restore access to torrent-file-editor package
Access restored. Thanks to all. ___ 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 39 Mass Rebuild
On Tue, Jul 25, 2023, 21:36 Florian Weimer wrote: > * Kevin Fenzi: > > > ok. How big a problem is this? Do we need to schedule another mass > > rebuild (and push back the schedule most likely)? > > > > Or we can/should just rebuild things that failed due to already fixed > > issues? > > I don't think it matters. I raised it mainly for accuracy. > > We should adjust the system wide change proposal deadline for Fedora 40, > though, so that Fesco has plenty of time to review proposals. > As far as I can tell, the toolchain proposal was announced on the devel / devel-announce lists on July 7 but never submitted to FESCo for a vote. Looks like the process broke down somewhere along the way. Fabio > 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 > ___ 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] Fedora 39 Rawhide 20230725.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 39 Rawhide 20230725.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20230722.n.1: anaconda-39.26-1.fc39.src, 20230725.n.1: anaconda-39.26-2.fc39.src python-blivet - 20230722.n.1: python-blivet-3.8.0-2.fc39.src, 20230725.n.1: python-blivet-3.8.0-3.fc39.src pyparted - 20230722.n.1: pyparted-3.13.0-2.fc39.src, 20230725.n.1: pyparted-3.13.0-3.fc39.src parted - 20230722.n.1: parted-3.6-1.fc39.src, 20230725.n.1: parted-3.6-2.fc39.src pykickstart - 20230722.n.1: pykickstart-3.48-2.fc39.src, 20230725.n.1: pykickstart-3.48-3.fc39.src lorax - 20230722.n.1: lorax-39.2-2.fc39.src, 20230725.n.1: lorax-39.2-5.fc39.src pungi - 20230722.n.1: pungi-4.4.0-3.fc39.src, 20230725.n.1: pungi-4.4.1-1.fc39.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/39 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230725.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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: Fedora 39 Mass Rebuild
* Kevin Fenzi: > ok. How big a problem is this? Do we need to schedule another mass > rebuild (and push back the schedule most likely)? > > Or we can/should just rebuild things that failed due to already fixed > issues? I don't think it matters. I raised it mainly for accuracy. We should adjust the system wide change proposal deadline for Fedora 40, though, so that Fesco has plenty of time to review proposals. 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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Tue, Jul 25, 2023 at 10:39 AM Timothée Ravier wrote: > > > Would these messages show up, for example, if they opened the terminal app? > > They only show up on the console / ssh login prompt if I'm not mistaken: > https://github.com/fwupd/fwupd/tree/main/data/motd That means they will show up anywhere that pam_motd is in the session stack. Currently, that's only sshd logins, but that's a discussion we could have. ___ 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
Rawhide update gating: mass rebuild issues
Hi folks! Just wanted to drop a note for anyone who noticed their Rawhide updates stuck in gating for an unusually long time yesterday/today. This is mainly due to the mass rebuild. Merging it in (which was done without sending anything in it through openQA testing) resulted in two separate problems: 1. Some GNOME packages were inadvertently bumped to 45-alpha early, as the changes were checked into git but had not been built; this caused dependency issues, then when we tried building the remaining packages at version 45-alpha to see if things would work OK with a consistent set of packages, we found a bug which made the tests fail and necessitated untagging everything back to 44: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 . 2. The rebuilt PackageKit was broken because of a change in glib, and needed a backport of https://github.com/PackageKit/PackageKit/pull/643 to work properly again. These were complicated by a third problem showing up in the middle: a new build of brltty had some internal dependency issues, and needed to be untagged. All of these issues caused test failures for *every* Rawhide update tested after the mass rebuild was merged (in the first case) or the brltty update landed (in the third case). It took several hours to get them all unpicked and the fixed PackageKit landed, then I re-scheduled the failed tests on all other updates (but I did this a bit wrong for some of them, so they failed again, and I had to re-run them again an hour or so ago). I'm also fighting a bit with Koji giving 404 responses for the f39- build repo more often than it usually does, but I hope to have tests for all updates passing (assuming the update itself has no problems) within the next hour or two. For the next go-round, it might be good to use the relatively new ability we have to schedule openQA tests on a side tag to test the mass rebuild *before* it's merged, I'll check with releng if that is feasible. This is also the second or third time gating has been disrupted by a broken update that wasn't in the critical path and so didn't go through gating itself. I'm considering rejigging the critpath/bodhi/greenwave/openqa industrial complex (again) so we also/instead test everything that goes into the environments openQA tests (Server, Workstation, and KDE), even if it's not "important" in itself. Bad deps in *anything* in the environment can break the tests because they prevent `dnf update` from succeeding at all, so the updated packages never get installed (I actually think dnf-5 may be being more 'strict' than dnf here, too, and exposing problems that were previously not causing test failures, but I'd have to check that). This would be some fairly major surgery, though (and increase the load on openQA). -- 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
Re: packager-dashboard not updating koschei build status
Hey, Thanks for raising the issue. It has been addressed and all the dashboards should now contain up2date data from koschei. Longer answer: The problem was the enablement of EPEL 9 Next in koschei, oraculum (the backend for the Packager Dashboard) isn't ready for these kinds of releases and I had to add filtering of it: https://pagure.io/fedora-qa/oraculum/c/aba10ef932ba894c2000851f4028f4402d6bbcdc?branch=master . On Tue, Jul 25, 2023 at 12:54 AM Mikel Olasagasti wrote: > Hi all, > > I've multiple reports of FTBFS in the packager-dashboard, but I can > see many of the packages are being built fine in koschei/koji. > > Is there a known issue on refreshing koschei data? > > Kind regards, > Mikel > ___ > 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 > -- Best regards / S pozdravem, František Zatloukal Senior Quality Engineer Red Hat ___ 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 August
On 25. 07. 23 17:49, Florian Weimer wrote: * Miro Hrončok: On 25. 07. 23 16:42, Florian Weimer wrote: * Miro Hrončok: glibc32 codonell, fweimer, jakub, mcermak Is this about FTBFS issues? There isn't any recent build failure in Koji, so I don't get why it's on this list? The build currently in Rawhide was done on Fedora 36 which is end of life. Apparently the release engineering team has not rebuilt this package in a mass rebuild at least since Fedora 35. To remove it from the list, build the package on Rawhide please. That's not what the subject line and the policy say, though. The policy requires failing builds and FTBFS bugs in Bugzilla. Please update the policy if you think this is no longer appropriate. IMHO it is what the policy says, quite explicitly: From https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs """ Cca six weeks before the Fedora N mass branching, packages that weren’t successfully rebuilt at least in Fedora N-2 are collected and weekly reminders are sent to affected maintainers and the Fedora devel mailing list. Cca a week before the Fedora N mass branching, packages that weren’t successfully rebuilt at least in Fedora N-2 will be retired assuming there have been at least 5 warnings on the devel mailing list. The bug status has no effect on this retirement. This can be requested via a releng issue. """ When I included glibc32 in the list, it wasn't successfully rebuilt at least in Fedora 37. We could argue what "successfully rebuilt" actually means, but when I wrote that policy, the spirit was "an actual built shipped to Fedora users" rather than "a Koschei rebuild". I see you rebuilt it now, thanks. Should I open a releng ticket to include this package in the next mass rebuild? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
* Peter Robinson: >> Are bootloaders fully treated as firmware and no longer built by Fedora? >> At least the shim package does not come with corresponding source code >> AFAICS. But I expect that there are other 32-bit pre-boot packages that >> we still rebuild. > > There's shim-unsigned* which is built in Fedora, the output of those > are sent off to be signed and then the signed binaries are put into > the final shim packages which don't have source code but they are > still built on Fedora with the source, just in a two step process due > to the out of band signing. I think it's more complicated than that because the shim package can be cobbled together from multiple different shim-unsigned package versions. Anyway, I think Fedora strives to be better than “you can find sources somewhere else if you just look hard enough”. Can't you automatically include all relevant SRPMs in the shim SRPM? 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 39 Mass Rebuild
On Tue, Jul 25, 2023 at 12:47:12PM +0200, Jakub Jelinek wrote: > On Tue, Jul 25, 2023 at 12:40:15PM +0200, Florian Weimer wrote: > > * Samyak Jain: > > > > > - GNU Toolchain Update (gcc 13.2, binutils 2.40, glibc 2.38, gdb 13.2) > > > > This change has not yet been voted on by Fesco, so it's largely not > > included in the rebuild: gcc was still using a 13.1 version, glibc was > > GCC 13.2 isn't out yet either, will be hopefully on Thursday, the mass > rebuild was done using ~ 1 month old GCC 13 branch snapshot, so compared to > what will be in 13.2 lacks that roughly a month of bugfixes. I'll build new > GCC 13.2 into F39 at the end of the week. :( ok. How big a problem is this? Do we need to schedule another mass rebuild (and push back the schedule most likely)? Or we can/should just rebuild things that failed due to already fixed issues? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 39 Mass Rebuild
On Tue, Jul 25, 2023 at 02:23:00AM +0200, Sandro wrote: > On 24-07-2023 20:30, Samyak Jain wrote: > > 21426 builds have been tagged into f39, there are currently 1017 failed > > builds > > that need to be addressed by the package maintainers. FTBFS bugs will be > > filed shortly. > > Will all the Python packages that failed during the Python3.12 mass rebuild > and haven't been fixed yet, receive another FTBFS/FTI bug? Or will those be > filtered out? If they already have a FTBFS bug (attached to the tracker) they will not get a new bug. If they do not, they will. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On Tue, 25 Jul 2023 at 11:54, Josh Boyer wrote: > On Tue, Jul 25, 2023 at 11:44 AM Florian Weimer > wrote: > > > > * Josh Boyer: > > > > > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok > wrote: > > >> > > >> On 25. 07. 23 16:42, Florian Weimer wrote: > > >> > * Miro Hrončok: > > >> > > > >> >> glibc32 codonell, fweimer, > jakub, mcermak > > >> > > > >> > Is this about FTBFS issues? There isn't any recent build failure in > > >> > Koji, so I don't get why it's on this list? > > >> > > >> The build currently in Rawhide was done on Fedora 36 which is end of > life. > > >> > > >> Apparently the release engineering team has not rebuilt this package > in a mass > > >> rebuild at least since Fedora 35. > > >> > > >> To remove it from the list, build the package on Rawhide please. > > > > > > Or we could not, and drop i686 completely. > > > > If we drop glibc32, we can't build any 32-bit code at all because GCC > > will no longer support -m32. In this regardm x86-64 is different than > > the other Fedora architectures which can target bare metal 32-bit even > > from 64-bit-only compilers. > > > > Are bootloaders fully treated as firmware and no longer built by Fedora? > > At least the shim package does not come with corresponding source code > > AFAICS. But I expect that there are other 32-bit pre-boot packages that > > we still rebuild. > > > > We need to fix this GCC build issue for CentOS 10 eventually, and at > > that point, we won't need glibc32 anymore. It's been a constant source > > of annoyance. > > Necessity is the mother of all invention. If you need this solved by > CentOS Stream 10, you really want to solve it now and get that > solution into F39 or F40 at the latest. > > As much as I would like to see the i686 problem dealt with finally, I am not sure what is done with a fundamental change like this after the closing period for such changes for Fedora 39. [It does lead to a funny problem.. if i686 were to get removed after the mass rebuild because a cascade of FTBFS or other reasons.. does FESCO need a change proposal :)] > josh > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- 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: List of long term FTBFS packages to be retired in August
On Tue, Jul 25, 2023 at 4:44 PM Florian Weimer wrote: > > * Josh Boyer: > > > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok wrote: > >> > >> On 25. 07. 23 16:42, Florian Weimer wrote: > >> > * Miro Hrončok: > >> > > >> >> glibc32 codonell, fweimer, jakub, > >> >> mcermak > >> > > >> > Is this about FTBFS issues? There isn't any recent build failure in > >> > Koji, so I don't get why it's on this list? > >> > >> The build currently in Rawhide was done on Fedora 36 which is end of life. > >> > >> Apparently the release engineering team has not rebuilt this package in a > >> mass > >> rebuild at least since Fedora 35. > >> > >> To remove it from the list, build the package on Rawhide please. > > > > Or we could not, and drop i686 completely. > > If we drop glibc32, we can't build any 32-bit code at all because GCC > will no longer support -m32. In this regardm x86-64 is different than > the other Fedora architectures which can target bare metal 32-bit even > from 64-bit-only compilers. > > Are bootloaders fully treated as firmware and no longer built by Fedora? > At least the shim package does not come with corresponding source code > AFAICS. But I expect that there are other 32-bit pre-boot packages that > we still rebuild. There's shim-unsigned* which is built in Fedora, the output of those are sent off to be signed and then the signed binaries are put into the final shim packages which don't have source code but they are still built on Fedora with the source, just in a two step process due to the out of band signing. ___ 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 August
On Tue, Jul 25, 2023 at 11:44 AM Florian Weimer wrote: > > * Josh Boyer: > > > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok wrote: > >> > >> On 25. 07. 23 16:42, Florian Weimer wrote: > >> > * Miro Hrončok: > >> > > >> >> glibc32 codonell, fweimer, jakub, > >> >> mcermak > >> > > >> > Is this about FTBFS issues? There isn't any recent build failure in > >> > Koji, so I don't get why it's on this list? > >> > >> The build currently in Rawhide was done on Fedora 36 which is end of life. > >> > >> Apparently the release engineering team has not rebuilt this package in a > >> mass > >> rebuild at least since Fedora 35. > >> > >> To remove it from the list, build the package on Rawhide please. > > > > Or we could not, and drop i686 completely. > > If we drop glibc32, we can't build any 32-bit code at all because GCC > will no longer support -m32. In this regardm x86-64 is different than > the other Fedora architectures which can target bare metal 32-bit even > from 64-bit-only compilers. > > Are bootloaders fully treated as firmware and no longer built by Fedora? > At least the shim package does not come with corresponding source code > AFAICS. But I expect that there are other 32-bit pre-boot packages that > we still rebuild. > > We need to fix this GCC build issue for CentOS 10 eventually, and at > that point, we won't need glibc32 anymore. It's been a constant source > of annoyance. Necessity is the mother of all invention. If you need this solved by CentOS Stream 10, you really want to solve it now and get that solution into F39 or F40 at the latest. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
* Miro Hrončok: > On 25. 07. 23 16:42, Florian Weimer wrote: >> * Miro Hrončok: >> >>> glibc32 codonell, fweimer, jakub, mcermak >> Is this about FTBFS issues? There isn't any recent build failure in >> Koji, so I don't get why it's on this list? > > The build currently in Rawhide was done on Fedora 36 which is end of life. > > Apparently the release engineering team has not rebuilt this package > in a mass rebuild at least since Fedora 35. > > To remove it from the list, build the package on Rawhide please. That's not what the subject line and the policy say, though. The policy requires failing builds and FTBFS bugs in Bugzilla. Please update the policy if you think this is no longer appropriate. 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: List of long term FTBFS packages to be retired in August
* Josh Boyer: > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok wrote: >> >> On 25. 07. 23 16:42, Florian Weimer wrote: >> > * Miro Hrončok: >> > >> >> glibc32 codonell, fweimer, jakub, >> >> mcermak >> > >> > Is this about FTBFS issues? There isn't any recent build failure in >> > Koji, so I don't get why it's on this list? >> >> The build currently in Rawhide was done on Fedora 36 which is end of life. >> >> Apparently the release engineering team has not rebuilt this package in a >> mass >> rebuild at least since Fedora 35. >> >> To remove it from the list, build the package on Rawhide please. > > Or we could not, and drop i686 completely. If we drop glibc32, we can't build any 32-bit code at all because GCC will no longer support -m32. In this regardm x86-64 is different than the other Fedora architectures which can target bare metal 32-bit even from 64-bit-only compilers. Are bootloaders fully treated as firmware and no longer built by Fedora? At least the shim package does not come with corresponding source code AFAICS. But I expect that there are other 32-bit pre-boot packages that we still rebuild. We need to fix this GCC build issue for CentOS 10 eventually, and at that point, we won't need glibc32 anymore. It's been a constant source of annoyance. 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: Unannounced soname bump: libotf
On Tue, 25 Jul 2023, Scott Talbert wrote: libotf was just bumped from libotf.so.0 to libotf.so.1. $ dnf repoquery --whatrequires 'libotf.so.0()(64bit)' --disablerepo='*' --enablerepo=rawhide emacs-1:28.2-6.fc39.x86_64 emacs-lucid-1:28.2-6.fc39.x86_64 libotf-devel-0:0.9.13-22.fc38.x86_64 m17n-lib-tools-0:1.8.2-1.fc39.x86_64 Please announce soname bumps in advance and coordinate rebuilds in side tags. :) It looks like m17n-lib needs to be rebuilt first and then emacs can be rebuilt. @mfabian, can you please take care of m17n-lib? Scott ___ 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 August
On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok wrote: > > On 25. 07. 23 16:42, Florian Weimer wrote: > > * Miro Hrončok: > > > >> glibc32 codonell, fweimer, jakub, mcermak > > > > Is this about FTBFS issues? There isn't any recent build failure in > > Koji, so I don't get why it's on this list? > > The build currently in Rawhide was done on Fedora 36 which is end of life. > > Apparently the release engineering team has not rebuilt this package in a mass > rebuild at least since Fedora 35. > > To remove it from the list, build the package on Rawhide please. Or we could not, and drop i686 completely. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On 25. 07. 23 16:42, Florian Weimer wrote: * Miro Hrončok: glibc32 codonell, fweimer, jakub, mcermak Is this about FTBFS issues? There isn't any recent build failure in Koji, so I don't get why it's on this list? The build currently in Rawhide was done on Fedora 36 which is end of life. Apparently the release engineering team has not rebuilt this package in a mass rebuild at least since Fedora 35. To remove it from the list, build the package on Rawhide please. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Potential changes to systemd RPM macros
On Tue, Jul 25, 2023 at 10:51:04AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I don't think Fedora would reject those changes, because in general
> we don't reject things unless they really break stuff for other people.
> Nevertheless, I agree with what Daniel P. Berrangé wrote in another reply:
>
> > My concern is about where the solution is applied and divergance from
> > Fedora guidelines.
> >
> > The long term direction of Fedora / RPM has been to reduce the number
> > of scriptlets required to be explicitly listed in package specfiles, by
> > having RPM globally apply script logic for all content in certain given
> > directories. If we're using standard Fedora macros, then we'd not expect
> > to see problems if the macros get changed to adapt to new approaches,
> > but if we're going our own way all bets are off.
> >
> > The current macros we're using are specified in the Fedora packaging
> > guidelines:
> >
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd
> >
> > and their impl is provided by systemd upstream itself:
> >
> > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in
> >
> > The problems described do not appear to be things unique to libvirt.
> >
> > IOW, I think the problem needs to be raised & addressed in context of
> > the Fedora and systemd communities, rather than having libvirt diverge
> > from normal Feora packaging practice.
>
> You're putting in quite a lot of work to create some very specific
> machinery. From the POV of the individual package this may look like
> the most efficient solution, but from the POV of the distro, such
> unique per-package solutions have the downside that they require special
> knowledge and make it harder for other maintainers to understand the
> package and contribute to it.
No disagreement from me here :)
> I think it'd be more effiecient to go with the (slightly ugly, no
> disagreement here) seven line %trigger scriptlet. And and then work
> with upstream to implement a generic solution that can be used by all
> packages. It seems to me that the work put into implementing a custom
> solution in libvirt would be wasted if you want to work with upstream
> on a completely different general solution soon after.
Another way to look at it is that I *already* put all that work in,
and the solution I've proposed for libvirt has been tested quite
thoroughly in a number of install and upgrade scenarios. In order to
adopt the %trigger based solution, I will have to spend more time on
developing and testing another implementation.
I'll give it a shot, but as I mentioned time is not on our side with
this one. My primary concern is having a working solution in place so
that users' deployment don't break on upgrade.
> > Note that systemd-update-helper also doesn't currently support
> > marking services as needs-reload, only needs-restart, so that would
> > have to be added.
>
> So far, the assumption was that almost everything would be restarted
> (because we want the new code to be running). Stuff that cannot be
> restarted is effectively ignored by the packaging macros, we have
> %systemd_postun == %nil. In the general case, for services that do
> not support restarting, it's not clear that they should be reloaded.
> They old code might not support the new configuration format, or some
> of the auxiliary files might not exist in the new version, or even if
> the reload is supported, it's not clear why it should happen.
>
> So packages are generally expected to do the reload, if appropriate,
> on their own. There is really no harm in having
> %postun
> systemctl try-reload foobar.service || :
>
> We *could* wrap this in a macro, but it's trivial and package-specific
> anyway.
I feel that having packages call systemctl directly instead of going
through the %systemd_* macros is an anti-pattern that shouldn't be
encouraged.
The current set of macros already includes both %systemd_postun and
%systemd_postun_with_restart, so adding %systemd_postun_with_reload
or something along those lines doesn't seem like a stretch.
Of course it would be the package's responsibility to choose the
right macro for each unit. The maintainer should know enough about
the services to make the correct call.
> > > > +%post -n kdump-tools
> > > > # Initial installation
> > > > %systemd_post kdump.service
> > >
> > > This one is tricky. %systemd_post presets the service on "first
> > > installation",
> > > which is actually the first the time package is installed. I.e. it
> > > unfortunately
> > > also would execute the preset on upgrades that split out a subpackage,
> > > because
> > > as far as rpm is concerned, this is the initial installation of that
> > > subpackage.
> > >
> > > The righteous way to solve this would be something like this:
> > >
> > > %triggerprein -n kdump-tools -- kexec-tools < 2.0.26-8
> > > touch %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset
> > >
> > > %post -n kdump-tools
> > > rm
Re: List of long term FTBFS packages to be retired in August
* Miro Hrončok: > glibc32 codonell, fweimer, jakub, mcermak Is this about FTBFS issues? There isn't any recent build failure in Koji, so I don't get why it's on this list? 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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
> Would these messages show up, for example, if they opened the terminal app? They only show up on the console / ssh login prompt if I'm not mistaken: https://github.com/fwupd/fwupd/tree/main/data/motd ___ 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: NTFS corruption with Fedora 37 and 38
Am 25.07.23 um 13:29 schrieb Michael Schwendt: Trying to figure out what has changed in Fedora land that causes NTFS corruption for some time. This is with default workstation with GNOME Shell auto-mounting external storage media when plugging them in. A ticket in bugzilla suggests there has been a changed from ntfs-3g to ntfs3: https://bugzilla.redhat.com/2182206 ( udisks switched to kernel ntfs3 driver instead of ntfs-3g for mounting ntfs since the kernel 6.2 update ) The current state of development is highly dangerous. It could be random coincidence[1], but since Sunday (the date I updated kernel-6.4.4), I had 2 serious NTFS corruptions on an external USB-disk. Win11 was able to repair the first one (Fedora was not), but the second one was fatal. Both Linux and Win11 refused any operation on the file system. I resorted to reformating. Ralf [1] I've only sporadically used NTFS, before, but for a couple of weeks, I had to use it more frequently. ___ 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 August
Hi, On 7/25/23 15:52, Mikolaj Izdebski wrote: > On Tue, Jul 25, 2023 at 2:48 PM Hans de Goede wrote: > >>> xmvn-connector-ivymizdebsk >> >> This one has a long long list of deps which will break if it is >> retired and there is a pull-req here fixing the FTBFS: >> >> https://src.fedoraproject.org/rpms/xmvn-connector-ivy/pull-request/2 >> >> Are there any objections against solving it with the rebase to >> a newer git snapshot (it already is a git snapshot) ? >> >> If not then I'll use my proven-packager rights to get this >> pull-request merge and close the FTBFS bug. >> >> Mikolaj any objections against merging the pull-request ? > > I made a new upstream release of version 4.0.0 and updated the package > to the latest version. > Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41256115ad Great, thank you! Regards, Hans ___ 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
Unannounced soname bump: libotf
libotf was just bumped from libotf.so.0 to libotf.so.1. $ dnf repoquery --whatrequires 'libotf.so.0()(64bit)' --disablerepo='*' --enablerepo=rawhide emacs-1:28.2-6.fc39.x86_64 emacs-lucid-1:28.2-6.fc39.x86_64 libotf-devel-0:0.9.13-22.fc38.x86_64 m17n-lib-tools-0:1.8.2-1.fc39.x86_64 Please announce soname bumps in advance and coordinate rebuilds in side tags. :) Scott ___ 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 August
On Tue, Jul 25, 2023 at 2:48 PM Hans de Goede wrote: > > xmvn-connector-ivymizdebsk > > This one has a long long list of deps which will break if it is > retired and there is a pull-req here fixing the FTBFS: > > https://src.fedoraproject.org/rpms/xmvn-connector-ivy/pull-request/2 > > Are there any objections against solving it with the rebase to > a newer git snapshot (it already is a git snapshot) ? > > If not then I'll use my proven-packager rights to get this > pull-request merge and close the FTBFS bug. > > Mikolaj any objections against merging the pull-request ? I made a new upstream release of version 4.0.0 and updated the package to the latest version. Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41256115ad > > Miro can you hold of on retiring xmvn-connector-ivy please ? > > Regards, > > Hans > > > > ___ 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 August
On 25. 07. 23 14:48, Hans de Goede wrote: Miro can you hold of on retiring xmvn-connector-ivy please ? ack -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning jansi-native jansi1 jline2 and bsh
Hi All, jansi-native depends on hawtjni which is unmaintained and will no longer build after the maven2 to moven3 upgrade. Not having jansi-native will also break jansi1 -> jline2 -> bsh all of which are currently maintained by me. I no longer have a need for any of these pkgs so I'm orphaning them. jansi-native and jansi1 have no other packages directly depending on them. jline2 is used by: frysk (cagney) picocli-shell-jline2 (didiksupriadi41) bsh is used by: jmock (didiksupriadi41) maven-invoker-plugin (korkeala) maven-script-interpreter (korkeala) Note this is based on a repoquery on F38 x86_64 and if you want to take over these packages because you depend upon them you will also need to take over and somehow fix hawtjni or maybe you can just drop the jline2 dependency from your packages or from bsh (if posssible). Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
On Tue, Jul 25, 2023 at 8:52 AM Timothée Ravier wrote: > > > Actually, why wouldn't this be used everywhere? I could see this be > > useful when people remote into workstations and apply updates. I know > > of plenty of people that split their desktops between local and remote > > access/administration. > > We could enable it everywhere but we've not reached out to desktop editions > for comments. > > Process wise, that could potentially move this Change from Self Contained to > System Wide. Sure, but it's simple enough that I wouldn't worry about that. There's also the fact that outside of the GNOME and KDE variants, nobody has a graphical firmware update management tool. So what are they supposed to do or use? Would these messages show up, for example, if they opened the terminal app? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
> Actually, why wouldn't this be used everywhere? I could see this be > useful when people remote into workstations and apply updates. I know > of plenty of people that split their desktops between local and remote > access/administration. We could enable it everywhere but we've not reached out to desktop editions for comments. Process wise, that could potentially move this Change from Self Contained to System Wide. ___ 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 August
Hi all, On 7/25/23 14:24, Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 39 approximately one week before branching. > > 5 weekly reminders are required, hence the retirement will happen > approximately in 2 weeks, i.e. around 2023-08-01. > > Policy: > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > The packages in rawhide were not successfully built at least since Fedora 36. > > This report is based on dist tags. > > Packages collected via: > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, > please let me know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > > Package (co)maintainers > > DecodeIR leamas > apache-commons-fileupload jerboaa, jjelen, mizdebsk, spike > avarice lucilanga > burp cicku, kaptk2 > clang12 tstellar > cvise mpolacek > emacs-common-ess alexlan, jamatos > fasttext kenhys > glibc32 codonell, fweimer, jakub, mcermak > golang-github-burntsushi-xgbutil eclipseo, go-sig > golang-github-chifflier-nfqueue fab, go-sig > golang-github-cupcake-rdb eclipseo, go-sig > golang-github-d5-tengo-2 fab, go-sig > golang-github-docker-slim eclipseo, go-sig > golang-github-facebookarchive-inject agerstmayr, go-sig, mgoodwin, > nathans > golang-github-facebookarchive-structtag agerstmayr, go-sig, mgoodwin, > nathans > golang-github-facebookgo-clock eclipseo, go-sig > golang-github-facebookgo-ensure dcavalca, go-sig > golang-github-facebookgo-httpdown go-sig, orphan > golang-github-facebookgo-stack dcavalca, go-sig > golang-github-facebookgo-stats go-sig, orphan > golang-github-fonts-dejavu go-sig, orphan > golang-github-ghemawat-stream eclipseo, go-sig > golang-github-google-tspi go-sig, orphan > golang-github-gorp-3 dcavalca, go-sig > golang-github-haproxytech-models bdperkin, go-sig > golang-github-influxdata-tdigest go-sig, orphan > golang-github-jackc-pgproto3 eclipseo, go-sig > golang-github-jackc-pgservicefile eclipseo, go-sig > golang-github-michaeltjones-walk go-sig, orphan > golang-github-nkovacs-streamquote eclipseo, go-sig > golang-github-phpdave11-gofpdi go-sig, orphan > golang-github-powerman-check eclipseo, go-sig > golang-github-quay-clair-3 eclipseo, go-sig > golang-github-remind101-migrate eclipseo, go-sig > golang-github-tj-buffer go-sig, orphan > golang-github-vmihailenco-msgpack go-sig, orphan > golang-github-vmware-vmw-guestinfo eclipseo, go-sig > golang-github-wsxiaoys-terminal go-sig, orphan > golang-github-x-cray-logrus-prefixed-formatter dcavalca, go-sig > golang-github-zmap-zlint eclipseo, go-sig > golang-github-zmap-zlint-2 go-sig, orphan > golang-go4 eclipseo, go-sig, jchaloup > golang-gopkg-redis-2 go-sig, orphan > golang-gopkg-retry-1 eclipseo, go-sig > golang-gopkg-seborama-govcr-2 go-sig, qulogic > golang-gopkg-sourcemap-1 eclipseo, go-sig, jchaloup > golang-gvisor eclipseo, elmarco, go-sig > golang-k8s-legacy-cloud-providers go-sig, orphan > golang-rsc-qr go-sig, qulogic > golang-sigs-k8s-kustomize dcavalca, go-sig > golang-vitess eclipseo, go-sig > hibernate-jpa-2.1-api jjelen > httping fab > jblas zbyszek > libffi3.1 codonell > libifp konradm > log4c stevetraylen, valtri > mongo-cxx-driver hhorak, mmuzila > mspdebug till > multican jnovy > nom-tam-fits gil, lupinix, zbyszek > opentracker cicku, lbazan > procinfo-ng fab > racket
Re: List of long term FTBFS packages to be retired in August
On 25. 07. 23 14:33, Sandro wrote: On 25-07-2023 14:24, Miro Hrončok wrote: 5 weekly reminders are required, hence the retirement will happen approximately in 2 weeks, i.e. around 2023-08-01. 1 August is exactly 1 week from now... Apologies, I forgot to update the number of weeks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in August
On 25-07-2023 14:24, Miro Hrončok wrote: 5 weekly reminders are required, hence the retirement will happen approximately in 2 weeks, i.e. around 2023-08-01. 1 August is exactly 1 week from now... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: IBus 1.5.29 (System-Wide)
On Wed, Jul 05, 2023 at 03:37:27PM +0100, Sebastian Crane wrote: > > As someone who does not use the Plasma desktop currently, I am a > little confused as to why this is a change proposal. If I'm reading it > correctly, Fedora configured Plasma to run on Wayland, which partially > broke IBus support. Now, IBus has been updated upstream to support > keyboard layout switching on Wayland. What I don't see here is why > upgrading IBus now would be considered a System-Wide change, and what > downsides, if any, this might have. A bit late, but hopefully better late then never ;) I guess that this proposal serves as an announcement. Basically, people who use Plasma Wayland can click on the text and see more details, and not be surprised. 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
NTFS corruption with Fedora 37 and 38
Trying to figure out what has changed in Fedora land that causes NTFS corruption for some time. This is with default workstation with GNOME Shell auto-mounting external storage media when plugging them in. A ticket in bugzilla suggests there has been a changed from ntfs-3g to ntfs3: https://bugzilla.redhat.com/2182206 ( udisks switched to kernel ntfs3 driver instead of ntfs-3g for mounting ntfs since the kernel 6.2 update ) The current state of development is highly dangerous. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 25/07/2023 12:35, Hans de Goede wrote: How do I proceed with this ? Should I run "fedpkg retire" for these 4, or is orphaning them preferred ? Orphaned packages will be retired automatically if no one adopts them after 4 weeks. -- 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: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
On 25/07/2023 10:18, Martin Gansser wrote: that is, remove the jar files from the speed-dreams package and link to the Fedora jar files in the spec file. JAR files must be compiled from sources. Bundled precompiled files must be removed in %prep. -- 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: Potential changes to systemd RPM macros
On Mon, Jul 24, 2023 at 07:36:41AM -0700, Andrea Bolognani wrote: > On Fri, Jul 21, 2023 at 08:20:21AM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 20, 2023 at 07:40:08AM -0700, Andrea Bolognani wrote: > > > Now, since this is clearly not a libvirt-specific issue, I believe > > > this approach should be adopted across Fedora by way of these macros > > > (or comparable ones) being added to systemd. Packages would have to > > > migrate from the old macros over time, and at some point it should be > > > possible to get rid of them entirely. > > > > Systemd macros are maintained upstream. So if you have > > patches/suggestions/etc., they should be filed upstream. > > > > I looked briefly at your links [4,5] but it seems very libvirt-specific and > > it's hard to see the full plan without context. Please file a pull request > > upstream and it'll be easier to discuss there. There're also people from > > other distros there. > > Making this generic enough that it would work with arbitrary > services, and polished enough that I would consider submitting it as > a systemd change, would require a non-trivial amount of additional > work. > > That's work that I'm absolutely willing and intending to do[1], but > even under the most optimistic circumstances I see no chance of it > being completed in time for Fedora 39 and RHEL 9.3, which is when we > would need it in order to avoid breaking users' deployments. > > So what I'm looking for here is validation that the overall approach > is reasonably sound, the current implementation is not completely > broken, and in general Fedora would not reject a libvirt.spec file > that contained those changes. I don't think Fedora would reject those changes, because in general we don't reject things unless they really break stuff for other people. Nevertheless, I agree with what Daniel P. Berrangé wrote in another reply: > My concern is about where the solution is applied and divergance from > Fedora guidelines. > > The long term direction of Fedora / RPM has been to reduce the number > of scriptlets required to be explicitly listed in package specfiles, by > having RPM globally apply script logic for all content in certain given > directories. If we're using standard Fedora macros, then we'd not expect > to see problems if the macros get changed to adapt to new approaches, > but if we're going our own way all bets are off. > > The current macros we're using are specified in the Fedora packaging > guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd > > and their impl is provided by systemd upstream itself: > > https://github.com/systemd/systemd/blob/main/src/rpm/macros.systemd.in > > The problems described do not appear to be things unique to libvirt. > > IOW, I think the problem needs to be raised & addressed in context of > the Fedora and systemd communities, rather than having libvirt diverge > from normal Feora packaging practice. You're putting in quite a lot of work to create some very specific machinery. From the POV of the individual package this may look like the most efficient solution, but from the POV of the distro, such unique per-package solutions have the downside that they require special knowledge and make it harder for other maintainers to understand the package and contribute to it. I think it'd be more effiecient to go with the (slightly ugly, no disagreement here) seven line %trigger scriptlet. And and then work with upstream to implement a generic solution that can be used by all packages. It seems to me that the work put into implementing a custom solution in libvirt would be wasted if you want to work with upstream on a completely different general solution soon after. > > One immediate comment is that systemd macros have been reworked to restart > > everything in %posttrans using a single operation. I.e. various per-package > > macros mark services with "needs-restart", and then in %posttrans > > a single 'systemctl reload-or-restart --marked' does the deed. > > It seems your macros reimplement the previous behaviour of individual > > restarts, and we wouldn't want to go back to that. > > Each service is restarted/reloaded only once, but yeah there's a > separate call to systemctl for each of those reloads/restarts which I > agree is suboptimal. > > For the short-term implementation that lives in libvirt.spec I > thought it would be best to rely as little as possible on external > bits of machinery, such as the call to reload-or-restart, in order to > keep things self-contained and easy to inspect. Especially since the > reload-or-restart bit is part of systemd.spec's %transfiletriggerin, > which at least AFAICT is kind of opaque when looking at an installed > system. > > Note that systemd-update-helper also doesn't currently support > marking services as needs-reload, only needs-restart, so that would > have to be added. So far, the assumption was that almost everything would
Re: Fedora 39 Mass Rebuild
On Tue, Jul 25, 2023 at 12:40:15PM +0200, Florian Weimer wrote: > * Samyak Jain: > > > - GNU Toolchain Update (gcc 13.2, binutils 2.40, glibc 2.38, gdb 13.2) > > This change has not yet been voted on by Fesco, so it's largely not > included in the rebuild: gcc was still using a 13.1 version, glibc was GCC 13.2 isn't out yet either, will be hopefully on Thursday, the mass rebuild was done using ~ 1 month old GCC 13 branch snapshot, so compared to what will be in 13.2 lacks that roughly a month of bugfixes. I'll build new GCC 13.2 into F39 at the end of the week. Jakub ___ 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 39 Mass Rebuild
* Samyak Jain: > - GNU Toolchain Update (gcc 13.2, binutils 2.40, glibc 2.38, gdb 13.2) This change has not yet been voted on by Fesco, so it's largely not included in the rebuild: gcc was still using a 13.1 version, glibc was at a 2.38 pre-release (not much we can do about that given the schedule), and more importantly, the planned changes in the build settings were not included. I believe someone spoke to the proposal owner who encouraged to go forward with the mass rebuild, but this doesn't mean the planned change were included. 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: Orphaned packages looking for new maintainers
Hi all, On 7/17/23 20:48, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2023-07-17.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status > Change > > Zim ohaessler, orphan 0 weeks ago > axc orphan 3 weeks ago > bctoolbox orphan 3 weeks ago > bcunit orphan 3 weeks ago > belcard orphan 3 weeks ago > belr orphan 3 weeks ago > bitstower-markets orphan 3 weeks ago > clblast orphan, trix 1 weeks ago > cmrt kwizart, orphan 5 weeks ago > dlrn epel-packagers-sig, jpena, 0 weeks ago > openstack-sig, orphan > eosrei-emojione-fonts orphan 2 weeks ago > gfbgraph orphan 3 weeks ago > git-subrepo orphan 3 weeks ago > go-bindata go-sig, jchaloup, orphan 0 weeks ago > golang-bitbucket- go-sig, orphan 5 weeks ago > bertimus9-systemstat > golang-contrib-opencensus- orphan 5 weeks ago > exporter-prometheus > golang-contrib-opencensus- go-sig, orphan 5 weeks ago > resource > golang-gitea-lunny-log go-sig, orphan 5 weeks ago > golang-gitea-lunny-nodb go-sig, orphan 5 weeks ago > golang-github-abourget-teamcity go-sig, orphan 5 weeks ago > golang-github-acme-lego go-sig, orphan 5 weeks ago > golang-github-adalogics-fuzz- go-sig, orphan 5 weeks ago > headers > golang-github-aead-chacha20 go-sig, jchaloup, orphan 5 weeks ago > golang-github-aead-poly1305 go-sig, jchaloup, orphan 5 weeks ago > golang-github-agl-ed25519 go-sig, jchaloup, orphan 5 weeks ago > golang-github-akamai- go-sig, orphan 5 weeks ago > akamaiopen-edgegrid > golang-github-akavel-rsrc go-sig, orphan 5 weeks ago > golang-github-alecthomas- orphan 5 weeks ago > kingpin > golang-github-alicebob-gopher- go-sig, orphan 5 weeks ago > json > golang-github-alicebob- go-sig, orphan 5 weeks ago > miniredis > golang-github-aliyun-alibaba- bdperkin, go-sig, orphan 5 weeks ago > cloud-sdk > golang-github-aliyun-oss-sdk bdperkin, go-sig, orphan 5 weeks ago > golang-github-anacrolix- go-sig, orphan 5 weeks ago > envpprof > golang-github-anacrolix- go-sig, orphan 5 weeks ago > missinggo > golang-github-anacrolix-stm go-sig, orphan 5 weeks ago > golang-github-andy-kimball- go-sig, orphan 5 weeks ago > arenaskl > golang-github-antchfx-htmlquery go-sig, orphan 5 weeks ago > golang-github-apache-arrow go-sig, orphan 0 weeks ago > golang-github-apache-thrift go-sig, orphan 5 weeks ago > golang-github-apex-log go-sig, orphan 5 weeks ago > golang-github-apex-logs go-sig, orphan 5 weeks ago > golang-github-apparentlymart- orphan 5 weeks ago > textseg > golang-github-appc-docker2aci go-sig, orphan
License correction for vhostmd: LGPL-2.1-or-later
The vhostmd package was mistakenly tagged as GPLv2+, and has been corrected to LGPL-2.1-or-later during the SPDX conversion. 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: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
Am Di., 25. Juli 2023 um 10:19 Uhr schrieb Martin Gansser : > > Hi, > > i want to package the current version of speed-dreams 2.3.0, but i noticed > that jar files for the trackeditor are included in the package, but they > already exist in the system. Not really, there are two different things going on: > compilation error: > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /home/martin/rpmbuild/BUILDROOT/speed-dreams-2.3.0-1.fc38.x86_64 > error: Installed (but unpackaged) file(s) found: >/usr/bin/bsh-2.0b4.jar >/usr/bin/jdom-1.1.3.jar >/usr/bin/jgoodies-common-1.8.1.jar >/usr/bin/jgoodies-looks-2.5.3.jar This just says that your spec file installs those files as part of the build process (to the BUILDROOT, where check-files found them) but that your spec file does not declare them (in the %files section). > In the file src/tools/trackeditor/CMakeLists.txt from line 181 to line 230 > the jar files are copied as you can see. > https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/src/tools/trackeditor/CMakeLists.txt#l181 And that is why they get installed into the BUILDROOT. I don't think /usr/bin is a good place for jars. > do i have to use the jar files from the fedora packages now ? > > bsh-2.1.0-8.fc38.noarch > jdom-1.1.3-32.fc38.noarch > jgoodies-common-1.8.1-17.fc38.noarch > jgoodies-looks-2.7.0-7.fc38.noarch You should not "bundle" them with speed-dreams if they are available as separate packages. In that sense: Yes. BTW: The jdom package puts its jar into /usr/share/java/ as it should. > that is, remove the jar files from the speed-dreams package and link to the > Fedora jar files in the spec file. speed-dreams should "require" those packages. And you will need to adjust speed-dreams so that it uses them - by setting CLASSPATH if necessary or whatever makes speed-dreams find those jars. If your package comes with tests you might also need to buildrequire the others. Cheers 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: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
I think it is better to do without the track editor for the time being and to use SD with the option -DOPTION_TRACKEDITOR:BOOL=OFF to compile. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 24-07-2023 17:38, Julio Faracco wrote: I also need access to the packager group to claim maintainership. Who could provide it to me? The route you are looking at is described in "Adopting an orphaned or freshly retired package": https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#adopting -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Restricting automounting of uncommon filesystems?
On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote: > On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote: > > If I have a USB flash stick I plug in every day, it shouldn't ask me > > about that after the first time I use it. > > Based on this "threat model" all an attacker has to do then is > snag/modify/replace your existing drive and then they can pwn your > system. That's probably much easier to accomplish than getting you to > insert a previously-unseen device (the latter has a lot of awareness > around it, but the "of course I trust this one, it's mine!" will get you > pwned.) While in-person attackers are real, IMHO that are not the big risk factor for the general populace. I wasn't claiming this was a perfect solution, just that it addresses some easy low hanging fruit, where you have no clue what will be on a new drive you receive (whether purchased online, or as a swag at a trade show, etc). > (Besides, how are you to distinguish the exact stick? Most of the stuff > I have lying around here reports the same generic vendor/product/serial > number. And drive/volume labels are notoriously unreliable.) Yes there are some lame vendors, that don't burn unique serials, which will make it imperfect. IMHO it is still credible to use the vendor/product/serial despite that. > > If I acquire a new USB flash stick I've never plugged in before, I > > don't want it auto-mounting before I can wipe & reformat it. > > Honestly, what makes more sense to me is treat this whole thing purely > as a usability problem. Upon insertion, prompt the user to "mount, > mount reat-only, check, ignore", because at least then we'd get an > really easy method of fscking a disk without having to do the whole > unmount dance. It also provides a mechanism to supply user feedback (eg > showing fsck results, or the XFS case where you _have_ to mount the > filesystem to replay the journal before an fsck can be safely run) If you prompt a user every single time, all that results is training the user to press 'yes' without looking. To be useful the prompts need to only happen in unusual circumstances, that are infrequent enough to avoid training an instinctive response. > Again, let's be realistic about the threat models here -- the > overwhelmingly common situations are accidental corruption due to > improper shutdown/ejection, and malicious files on a well-formed > filesystem (eg ransomware or something that's banking on users having we > passwordless sudo in place, or curl https://url/setup.sh | sudo bash) Accidental corruption is indeed important, and wouldn't be solved by prompting. Protecting against that I think requires taking the libguestfs approach of mounting in an isolated guest OS kernel. In terms of malicious files, I think that not trusting newly seen devices is a valid strategy. There's plenty of documented cases where new devices had malware pre-installed. Re-formatting newly seen devices means the user only needs worry about their own usage from that point onwards, bringing in malware. 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
License correction for strawberry
Hello, The license for strawberry has been corrected and converted to SPDX from "GPLv2 and GPLv3+ and LGPLv2 and ASL 2.0 and MIT and Boost" to "MIT AND Apache-2.0 AND GPL-2.0-or-later AND GPL-3.0-or-later". Refer to the spec file for the license breakdown by source files, which should now correspond to the latest tarball contents. Cheers, Ondrej ___ 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
speed-dreams-2.3.0: how to handle bundled jar files in spec file ?
Hi, i want to package the current version of speed-dreams 2.3.0, but i noticed that jar files for the trackeditor are included in the package, but they already exist in the system. compilation error: Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/martin/rpmbuild/BUILDROOT/speed-dreams-2.3.0-1.fc38.x86_64 error: Installed (but unpackaged) file(s) found: /usr/bin/bsh-2.0b4.jar /usr/bin/jdom-1.1.3.jar /usr/bin/jgoodies-common-1.8.1.jar /usr/bin/jgoodies-looks-2.5.3.jar In the file src/tools/trackeditor/CMakeLists.txt from line 181 to line 230 the jar files are copied as you can see. https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/src/tools/trackeditor/CMakeLists.txt#l181 do i have to use the jar files from the fedora packages now ? bsh-2.1.0-8.fc38.noarch jdom-1.1.3-32.fc38.noarch jgoodies-common-1.8.1-17.fc38.noarch jgoodies-looks-2.7.0-7.fc38.noarch that is, remove the jar files from the speed-dreams package and link to the Fedora jar files in the spec file. Regards Martin ___ 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
