Re: strawman proposal: homed directories for users
On Fri, Oct 04, 2024 at 11:20:48AM -0400, Neal Gompa wrote: > When this was first explored a few years ago, the main problem that > came up was that homed is functionally incompatible with centralized > login systems (SSSD to FreeIPA/AD, OIDC, etc.). If this has changed, > then it would make sense to revisit. homed is about self-contained definitions of users. So obviously those users cannot be defined centrally… I think it's compatible in the sense that both kinds of users can be used on the same machine. Is there some more specific problem? 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
strawman proposal: homed directories for users
Hi folks, I was recently doing a bunch of test reinstalls of Fedora [1], looking to see if it's complicated to retain the user directories during a reinstall. The answer is, sadly, that it's possible only with some manual tinkering. This is a known problem [2]. With a little bit of trickery, Anaconda will let the "home" subvolume be and install the system to a new "root" subvolume, so user data is preserved. But then after a reboot a new user will be created, because the old user is not hooked up into /etc/passwd. We actually have a partial solution for this: systemd-homed. With systemd-homed the information about the user is maintained in the user directory/subvolume/partition, e.g. /home/username.homedir. After a reinstall, ideally nothing needs to be done and the user account is ready to be used. The primary purpose of systemd-homed is to use per-user encryption using loopback devices. This still has various problem related to resizing and suspend. Work is being done [see 3,4 for recent developments], but it's not at a point where we can recommend it. But systemd-homed has a mode where the user "home" is just a normal directory or btrfs subvolume with some metadata stored in files [5]. Some work would be needed [6] to make this work smoothly, but it doesn't seem like too much. (Mostly filing down some rough edges in systemd-homed and adding pam_home_systemd and nss_systemd in various authselect profiles.) Thus the question: would this be something worth looking into? [1] https://discussion.fedoraproject.org/t/feedback-anaconda-web-ui-partitioning/108995/65 [2] https://discussion.fedoraproject.org/t/its-difficult-to-reformat-a-btrfs-partition-subvolume-in-the-installer/89052 [3] https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFY3BB/ [4] https://www.youtube.com/watch?v=3e3IhBBU0JY [5] https://systemd.io/HOME_DIRECTORY/ [6] When I tested this today, this actually doesn't work. systemd-homed does a misguided check that break reinstalls. We'd need to figure out some solution here. Most likely just conditionalize that part of the code. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Wed, Sep 04, 2024 at 11:23:34AM +0200, Marcin Juszkiewicz wrote: > On 3.09.2024 10:08, Leigh Scott wrote: > > > You have some other issue as all those rpmfusion dep issues are bogus. > > Thanks for pointing it out. Sorted out rpmfusion issues. > > Two problems left: > > Problem 1: package alizams-1.9.10-2.fc41.x86_64 from fedora requires > libITKCommon-4.13.so.1()(64bit), but none of the providers can be installed > - package alizams-1.9.10-2.fc41.x86_64 from fedora requires > libITKStatistics-4.13.so.1()(64bit), but none of the providers can be > installed > - package alizams-1.9.10-2.fc41.x86_64 from fedora requires > libITKTransform-4.13.so.1()(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires > libtiff.so.5()(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires > libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires > libtiff.so.5()(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires > libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed > - problem with installed package alizams-1.9.9-2.fc40.x86_64 > - libtiff-4.6.0-2.fc40.x86_64 from @System does not belong to a > distupgrade repository > - alizams-1.9.9-2.fc40.x86_64 from @System does not belong to a > distupgrade repository > > Problem 2: problem with installed package > InsightToolkit-4.13.3-15.fc39.x86_64 > - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires > libtiff.so.5()(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from @System requires > libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires > libtiff.so.5()(64bit), but none of the providers can be installed > - package InsightToolkit-4.13.3-15.fc39.x86_64 from fedora requires > libtiff.so.5(LIBTIFF_4.0)(64bit), but none of the providers can be installed > - cannot install both libtiff-4.6.0-6.fc41.x86_64 from fedora and > libtiff-4.6.0-2.fc40.x86_64 from @System > - package libtiff-devel-4.6.0-6.fc41.x86_64 from fedora requires > libtiff(x86-64) = 4.6.0-6.fc41, but none of the providers can be installed > - problem with installed package libtiff-devel-4.6.0-2.fc40.x86_64 > - libtiff-devel-4.6.0-2.fc40.x86_64 from @System does not belong to a > distupgrade repository The first problem is caused by the second. The second is because InsightToolkit-4.13.3-15.fc39 was the last successful build. We need to either build it or retire: 2260959 InsightToolkit: FTBFS in Fedora rawhide/f40 2300545 InsightToolkit: FTBFS in Fedora rawhide/f41 2301800 F41FailsToInstall: InsightToolkit Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Tue, Sep 03, 2024 at 07:52:47AM +, Dridi Boukelmoune wrote: > Error: > Problem 1: package ghc-foldable1-classes-compat-0.1-4.fc40.x86_64 from > @System requires libHSarray-0.5.4.0-ghc9.4.5.so()(64bit), but none of the > providers can be installed Already resolved, https://bugzilla.redhat.com/show_bug.cgi?id=2315865. > Problem 3: package dolphin-emu-5.0.21460-3.fc41.x86_64 from fedora > requires libfmt.so.10()(64bit), but none of the providers can be installed dolphin-emu-2407-1.fc41 was built and resolved the issue. > Problem 4: package python3-fb-re2-1.0.7-18.fc41.x86_64 from fedora > requires libre2.so.9()(64bit), but none of the providers can be installed > - problem with installed package python3-fb-re2-1.0.7-15.fc40.x86_64 > - re2-1:20220601-19.fc40.x86_64 from @System does not belong to a > distupgrade repository > - python3-fb-re2-1.0.7-15.fc40.x86_64 from @System does not belong to a > distupgrade repository Someone else reported a problem with re2, but it seems to have been resolved already. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Mon, Sep 02, 2024 at 11:37:04AM -, Kanitha Chim wrote: > Error: > Problem 1: package cdn-utils-1.162-1.fc40eng.noarch from @System requires > python(abi) = 3.12, but none of the providers can be installed > Problem 2: package engproduct-cli-1.36-1.fc40eng.noarch from @System > requires python3.12dist(requests), but none of the providers can be installed > Problem 3: package pub-client-0.104.0-1.fc40eng.noarch from @System requires > python3.12dist(decorator), but none of the providers can be installed > Problem 4: package pulp-utils-1.27-1.fc40eng.noarch from @System requires > python3.12dist(python-dateutil) >= 1.4.1, but none of the providers can be > installed > Problem 5: package python-cdn_definitions-3.1.0-1.fc40eng.noarch from > @System requires python3.12dist(frozendict), but none of the providers can be > installed > Problem 6: package python-pubtools-1.3.0-1.fc40eng.noarch from @System > requires python3.12dist(pluggy), but none of the providers can be installed > Problem 7: package python-pubtools-pulplib-2.38.1-2.fc40eng.noarch from > @System requires python3.12dist(attrs), but none of the providers can be > installed > Problem 8: package python-pushcollector-1.3.0-1.fc40eng.noarch from @System > requires python3.12dist(jsonschema), but none of the providers can be > installed > Problem 9: package python-pushsource-2.41.0-1.fc40eng.noarch from @System > requires python3.12dist(kobo), but none of the providers can be installed > Problem 10: package python-ubiconfig-3.1.1-1.fc40eng.noarch from @System > requires python3.12dist(pyyaml), but none of the providers can be installed > Problem 11: package rcm-pa-tool-0.0.42-2.fc40eng.noarch from @System > requires python3.12dist(iniparse), but none of the providers can be installed > Problem 12: package rcm-repoquery-1.10-1.fc40eng.noarch from @System > requires python3.12dist(six), but none of the providers can be installed > Problem 13: package rhsm-tools-1.119-1.fc40eng.noarch from @System requires > python3.12dist(defusedxml), but none of the providers can be installed 'fc40eng' is not a fedora dist tag. Those packages are from somewhere else. > Problem 14: package python3-3.12.3-2.fc40.x86_64 from @System requires > python3-libs(x86-64) = 3.12.3-2.fc40, but none of the providers can be > installed > - package python-exodus_config-1.1.3-1.fc40eng.noarch from @System requires > python(abi) = 3.12, but none of the providers can be installed This does not seems to be a problem in Fedora. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Mon, Sep 02, 2024 at 01:25:35PM +0200, Cristian Le via devel wrote: > On my system I get an exiv2/krita issue and a re2 issue: > > ``` > Error: > Problem 1: problem with installed package krita-5.2.2-7.fc40.x86_64 > - package krita-5.2.2-11.fc41.x86_64 from fedora requires I have krita-5.2.3-1.fc41.x86_64 here, so this seems to have been resolved. > Problem 3: cannot install both exiv2-libs-0.28.2-5.fc41.x86_64 from fedora > and exiv2-libs-0.27.6-7.fc40.x86_64 from @System This is caused by krita, seems resolved now. > Problem 2: package python3-fb-re2-1.0.7-18.fc41.x86_64 from fedora requires > libre2.so.9()(64bit), but none of the providers can be installed > - problem with installed package python3-fb-re2-1.0.7-15.fc40.x86_64 > - re2-1:20220601-19.fc40.x86_64 from @System does not belong to a > distupgrade repository > - python3-fb-re2-1.0.7-15.fc40.x86_64 from @System does not belong to a > distupgrade repository I have re2-20240702-19.fc41.x86_64 here, so that seems to have been resolved too. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Mon, Sep 02, 2024 at 11:08:58AM -, Artur Frenszek-Iwicki wrote: > I have three machines running F40; here are the results: > > #1 > Error: > Problem 1: package module-build-service-3.9.2-9.fc41.noarch from fedora > requires python(abi) = 3.12, but none of the providers can be installed Will add to fedora-obsolete-packages. > #2 > Error: > Problem: package ghc-foldable1-classes-compat-0.1-4.fc40.x86_64 from @System > requires libHSarray-0.5.4.0-ghc9.4.5.so()(64bit), but none of the providers > can be installed That's already handled in https://bugzilla.redhat.com/show_bug.cgi?id=2315865. > I also had issues with some wxGTK3 packages leftover from F37, but I guess if > there was a time these should have been obsoleted, it was back in F38 days. It's possible that they didn't cause problems until now. Please report them so we can add them to f-o-p. 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
No FESCo Meeting today (2024-10-01)
Hi, We only have one not-very-urgent item for today (#3271 [F41 blocker] Ensure that all packages with dead.package are removed from repos) and it doesn't seem worth holding meeting for that, so the meeting today is cancelled. I'll chair the meeting the next week. = Discussed and Voted in the Ticket = #3269 Re-evaluate ban on pre-compiled CSS https://pagure.io/fesco/issue/3269 APPROVED (+7, 0, 0) -- Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning csound
On Tue, Oct 01, 2024 at 03:24:26AM +0200, Hans Ulrich Niedermann wrote: > I have orphaned the csound package, hopefully preventing csound from > getting into F41. That's unlikely to be successful. Packages are retired after 6 weeks of being orphaned, and F41 will almost certainly be released earlier. And it cannot be retired after GA. If the current build is unusable in F41, and nobody picks it up to fix it, then it'd be better to retire it before the F41 final freeze. > The csound package has been non-trivially FTBFS for some time now and > every time I fix ne issue at least one other issue come up just to put > me off of working on it. > > As I see it, csound requires a nontrivial amount of upstream work, not > just packaging, and I cannot spend that much effort on csound at this > time. > > I have enough other packages to occupy my time. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning csound
On Tue, Oct 01, 2024 at 11:51:20AM +0200, Miro Hrončok wrote: > On 01. 10. 24 11:10, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Oct 01, 2024 at 03:24:26AM +0200, Hans Ulrich Niedermann wrote: > > > I have orphaned the csound package, hopefully preventing csound from > > > getting into F41. > > > > That's unlikely to be successful. Packages are retired after 6 weeks > > of being orphaned, and F41 will almost certainly be released earlier. > > And it cannot be retired after GA. > > Also, they are only retired on rawhide (after beta freeze). > > > If the current build is unusable in F41, and nobody picks it up to fix > > it, then it'd be better to retire it before the F41 final freeze. > > I plan to retire all orphaned packages with failed Python 3.13 rebuild > before the final freeze. csound is one of them. Good to hear that, there's a bunch of those. Then everything is fine here, and just orphaning is enough. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: problem with python-docopt and python-docopt-ng
On Mon, Sep 30, 2024 at 10:24:03AM -0400, Neal Gompa wrote: > On Mon, Sep 30, 2024 at 10:20 AM Zbigniew Jędrzejewski-Szmek > wrote: > > $ fedrq wr -F name -s python3-docopt-ng > > kiwi > > kiwi-boxed-plugin > > > > Dunno, those package that require python3-docopt are not very widely > > installed, > > but a conflict like this is quite annoying. (And very confusing to users if > > they encounter this somewhere in the dependency chain.) > > > > Should we switch kiwi to use python3-docopt for now? > > > > I switched kiwi and kiwi-boxed-plugin to docopt-ng because I thought > the plan was to switch everything else to docopt-ng... Yeah, that was the plan. The plan was also to do piecemeal upgrade. But if the packages are not coinstallabe, this doesn't work. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
problem with python-docopt and python-docopt-ng
Hi, we have two packages python-docopt and python-docopt-ng and they declare Conflicts. This is reasonable: they don't actually conflict at the file level, but because they both provide the docopt module, it could be unclear which one is loaded. Unfortunately some dependent packages switched to the new dep, but not all, so during upgrades and installs dnf becomes quite unhappy: Problem: conflicting requests - package python3-kiwi-10.1.13-1.fc41.noarch from updates-testing requires python3.13dist(docopt-ng) >= 0.9, but none of the providers can be installed - problem with installed package - installed package python3-docopt-1:0.6.2-3.fc41.noarch conflicts with python3-docopt provided by python3-docopt-ng-0.9.0-4.fc41.noarch from fedora ... $ fedrq wr -F name -s python3-docopt liquidctl python-bioread python-doxytag2zealdb python-grip python-hdfs python-jedi python-num2words python-odml python-parso python-pykwalify python-vconnector python-vevents python-vpoller stomppy udiskie $ fedrq wr -F name -s python3-docopt-ng kiwi kiwi-boxed-plugin Dunno, those package that require python3-docopt are not very widely installed, but a conflict like this is quite annoying. (And very confusing to users if they encounter this somewhere in the dependency chain.) Should we switch kiwi to use python3-docopt for now? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package updates missing in Fedora 41 but present in Fedora 40
On Sat, Sep 28, 2024 at 12:12:20PM +0200, Peter Hanecak wrote: > Hello, > > On 9/27/24 13:13, Fabio Valentini wrote: > > - tipcutils-0:3.0.6-1.fc40 > tipcutils-0:3.0.4-11.fc41 > > > > Package was updated to 3.0.6 on Rawhide, Fedora 40, 39, and EPEL 9, > > but Fedora 41 was missed. > > IIRC i686 build failed for this one[1]. Since I did not had time for that > back then, so I've postponed that. > > Apart from doing usual package update (which implies waiting for new > upstream release), can I push same build for F41 again? Advice welcome. A build that fails for one architecture fails altogether. And a failed build can be repeated. Thus, the appropriate course of action would be: - if the i386 is a fluke and you want to retry the build hoping that it passes this time, just do 'fedpkg build' again - if the i386 build is not needed, which is likely, then drop the i386 arch and rebuild. See https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval for details. - or you can do some updates to how the package is built, and push that and then build as usual. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Canceled] Schedule for Tuesday's FESCo Meeting (2024-09-24)
On Mon, Sep 23, 2024 at 04:50:13PM -0700, Kevin Fenzi wrote: > The only topic pending tomorrow's FESCo meeting is the issue > "#3271 [F41 blocker] Ensure that all packages with dead.package > are removed from repos" > and they are already all blocked. > > Since that was the only issue, the FESCo meeting Tuesday at 17:00 UTC > in #meeting:fedoraproject.org is canceled. > I can't chair the next meeting on Tuesday, October 1st, so > if another FESCo member could take that on, that would be great. I'll do the next week. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review Swap - some python, others
On Wed, Sep 11, 2024 at 02:25:17PM -0400, Neil Hanlon wrote: > tinyows - https://bugzilla.redhat.com/show_bug.cgi?id=2307815 I took this one. Please https://bugzilla.redhat.com/show_bug.cgi?id=2311104 in exchange. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Adopting and repurposing muon
On Tue, Aug 13, 2024 at 03:59:56PM -0600, Jerry James wrote: > On Tue, Aug 13, 2024 at 11:21 AM Link Dupont wrote: > > I noticed that the up-and-coming meson-compliant build tool muon[1] is not > > currently available in Fedora. While searching around, I found that a > > dist-git repository[2] titled "muon" already exists, and used to contain a > > KDE Plasma utility. It has been orphaned for a very long time (April 2016). > > I'm considering submitting muon[1] to Fedora, and I'd like to solicit the > > community opinion on how to reconcile the package names. I can think of a > > few approaches to take. > > > > 1) Adopt muon[2], package muon[1] and push it to rawhide. YOLO. > > 2) Adopt muon[2], package muon[1], submit a New Package Review and > > reconcile the existing dist-git repository with releng when the Review is > > approved. > > 3) Package muon[1] under a new package name (muon-build), submit a New > > Package Review, etc. Include a "Provides" to keep the "muon" name. > > > > Are there any better approaches to take here? > > > > ~link > > > > 1: https://github.com/muon-build/muon > > 2: https://src.fedoraproject.org/rpms/muon > > I agree with Marcus that (1) should not be done. You can't do (1) in > any case. The package has been retired for so long that a review is > required to reactivate the Rawhide branch. See > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming. > > On the other hand, I prefer (2) in this case. The original package > with that name has been gone for so long that I don't see any harm in > repurposing it. That would keep the package name and the upstream > name in sync. Yep, (2) is the best option. After the review is approved, have releng give ownership of the repo to you, and just do a commit that replaces the existing contents. (We have a general rule that commits in dist-git cannot be removed. Thus, the existing content needs to be preserved.) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Valter Nazianzeno
On Thu, Aug 08, 2024 at 01:57:01AM -, Valter Nazianzeno wrote: > Hi all, > > My name is Valter Nazianzeno, and my history with Linux is quite extensive, > though I'll spare you the details. However, I've been interested in Fedora > for > quite some time now. I've been using Fedora as one of my main OS on many of > my > computers, and I would like to give back to the project by contributing some > packages I am involved with. > > Currently, I work as a freelance programmer and in DevOps. > > I have one package pending review: > https://bugzilla.redhat.com/show_bug.cgi?id=2303600 Hi Valter, Welcome to Fedora! Zbyszek > If anyone would be willing to sponsor me as a package maintainer, that would > be > great! -- ___ 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: sbin-merge: what to do?
On Fri, Jul 26, 2024 at 11:09:22PM -0700, Adam Williamson wrote: > On Wed, 2024-07-17 at 16:20 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > The current plan is to wait for the f41 branching, and try again after > > that. > > To be clear: do you mean try again for F41, or try again for F42? For F42. (After f41 is branched, try again in the rawhide branch that will eventually become f42.) > If the latter, the Change should be formally deferred to F42 I adjusted the Wiki page and the tracker bug. > as currently folks are seeing this as planned for F41, e.g. > https://fosstodon.org/@Linux@kitty.social/112856419312942208 . Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2024-07-30)
On Tue, Jul 30, 2024 at 06:06:07AM +, Jednorozec wrote: > #3256 Change: ROCm 6.2 > https://pagure.io/fesco/issue/3256 > DECISION (+2, 0, -0) > > #3257 Change: PyTorch 2.4 > https://pagure.io/fesco/issue/3257 > DECISION (+2, 0, -0) > > #3258 Change: LXQt 2.0 > https://pagure.io/fesco/issue/3257 > DECISION (+2, 0, -0) Those proposals are not (yet) approved according to the voting rules. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2024-07-23)
On Wed, Jul 24, 2024 at 03:27:01AM +0200, Kevin Kofler via devel wrote: > Am Mittwoch, 24. Juli 2024 02:52:44 CEST schrieb Gary Buhrmaster: > > On Tue, Jul 23, 2024 at 10:38 PM Kevin Kofler via devel > > wrote: > > > > > And this one is yet another case of FESCo rubberstamping a change without > > > even any dissenting vote despite loads of negative mailing list feedback. > > > > How can one determine "loads"? Since the > > feedback itself is opt-in, no statistically > > valid conclusion can be reached based on > > the feedback received(*). FESCo needs to > > review the feedback that was received, > > and use their best judgement as to whether > > to approve or disapprove, and no one > > should expect there to be a dissenting > > vote just because of negative feedback. > > I would actually expect FESCo to unanimously vote against the feature if the > feedback on the mailing list is overwhelmingly negative. Or at least a > majority of FESCo, if it is controversial. But unanimous approval shows that > the feedback on the mailing list has been completely ignored, making the > feedback process entirely useless. There are many strange assumptions and logical gaps in this… 1. The feedback was generally _positive_. For example, check the "straw poll" on discourse [1]. 75% in favour, 21% opposed. 2. Even if there _is_ negative feedback, you expect that _some_ FESCo members would vote against. But each member evaluates the issue independently, and it's quite usual that they each individually think that the positives outweigh the negatives. (Or in other words, even if the proposal is not a "slam dunk" and each of the people voting consider the decision as hard, the outcome of the vote can still be unanimous.) 3. FESCo vote is not just based on feedback. It's also based on the evaluation of the feature. I look at the feedback, but I don't just count the voices, but try to evaluate each opinion on merit. And even if there were no feedback, I would still research and evaluate the proposal before voting. 4. Saying that the feedback was ignored is disingeneous. V2 of the proposal is significantly changed in response to feedback provided. Dunno, I have the feeling that the vote did not follow _your_ opinion, and you just cannot accept that people came to different conclusions than you did. [1] https://discussion.fedoraproject.org/t/f42-change-proposal-opt-in-metrics-for-fedora-workstation-system-wide/124325/2 Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM build warning
On Tue, Jul 23, 2024 at 04:31:31PM -0400, Steve Dickson wrote: > Hello > > I've got the following warning > > RPM build warnings: > source_date_epoch_from_changelog set but %changelog is missing > > The spec file definitely has a %changelog section. > What is it the warning about? What package? Link to build? Fedora sets %source_date_epoch_from_changelog globally, and that requires the changelog to have at least one entry. 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
Summary/Minutes from today's FESCo Meeting (2024-07-23)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-23/fesco.2024-07-23-17.00.html Meeting summary --- * TOPIC: Init Process * TOPIC: #3230 Mass license change * INFO: Votes in the ticket: (+5, 0, 0) * AGREED: All old license strings shall be converted to SPDX format. For licenses where a 1:1 mapping exists from the legacy Fedora tag to SPDX, the normal SPDX tag shall be used. For licenses where the old license tag maps to more than one possible license in the SPDX database, a tag in the form of LicenseRef--* where * is the old Fedora identifier shall be used. In both cases, a comment shall be included in the spec file to indicate that the conversion was done automatically and review is warranted. For the second case, the comment should also indicate that the maintainers should update to normal SPDX tags after review. (+7, 0, 0) * TOPIC: #3235 Change: Fedora KDE Plasma Mobile * AGREED: APPROVED (+8, 0, -1) * ACTION: Change owners to document which hardware this is for * LINK: https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/ * TOPIC: #3248 Git Forge Evaluation FESCo Rep(s) * INFO: Stephen Gallagher volunteered to be the rep * AGREED: Stephen Gallagher is approved as FESCo rep for the Git Forge Evaluation project (+8, 0, 0) * TOPIC: Next week's chair * ACTION: jednorozec will chair the next meeting. * TOPIC: Open Floor * INFO: The session in two weeks will most likely be moved to the live "Meet your FESCo" panel during Flock. * LINK: https://cfp.fedoraproject.org/flock-2024/talk/9VEHJX/ Action items * Change owners to document which hardware KDE Plasma Mobile spin is for * jednorozec will chair the next meeting. -- ___ 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
Schedule for Tuesday's FESCo Meeting (2024-07-23)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-07-23 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3242 Change: Opt-In Metrics for Fedora Workstation https://pagure.io/fesco/issue/3242 APPROVED (+6, 0, 0) #3243 Change: IPU6 Camera Support https://pagure.io/fesco/issue/3243 APPROVED (+8, 0, 0) #3244 Change: Retire Python 2.7 https://pagure.io/fesco/issue/3244 APPROVED (+8, 0, 0) #3245 Change: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t https://pagure.io/fesco/issue/3245 APPROVED (+7, 0, 0) = Followups = #3230 Mass license change https://pagure.io/fesco/issue/3230 Latest proposal: All old license strings shall be converted to SPDX format. For licenses where a 1:1 mapping exists from the legacy Fedora tag to SPDX, the normal SPDX tag shall be used. For licenses where the old license tag maps to more than one possible license in the SPDX database, a tag in the form of LicenseRef--* where * is the old Fedora identifier shall be used. In both cases, a comment shall be included in the spec file to indicate that the conversion was done automatically and review is warranted. For the second case, the comment should also indicate that the maintainers should update to normal SPDX tags after review. #3235 Change: Fedora KDE Plasma Mobile https://pagure.io/fesco/issue/3235 = New business = #3248 Git Forge Evaluation FESCo Rep(s) https://pagure.io/fesco/issue/3248 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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 Mass Rebuild 41 has completed
On Mon, Jul 22, 2024 at 11:32:03PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 23, 2024 at 01:19:27AM +0200, Miro Hrončok wrote:
> > On 23. 07. 24 1:07, Zbigniew Jędrzejewski-Szmek wrote:
> > > I noticed the following when comparing packages after the rebuild:
> > >
> > > │ │ │
> > > -{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> > > │ │ │
> > > +{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> > >
> > > It seems the info in os-release hasn't been updated so the
> > > package notes embedded in the binaries are off.
> >
> >
> > package-notes has:
> >
> > %build
> > sed "s|@OSCPE@|$(cat /usr/lib/system-release-cpe)|" %{SOURCE0}
> > >redhat-package-notes
> >
> > But the last build before the mass rebuild happened on Fedora 40.
> >
> > To prevent this situation in the future, package-notes needs to be rebuilt
> > right after branching.
>
> You are right, that's really a bug in package-notes.
> I think we could replace the static string with a read of
> /usr/lib/system-release-cpe.
I forgot that the latest implementation uses the linker spec file
"language" to insert the note. After banging my head against the screen
and keyboard for an hour, I couldn't figure out any way to make this
happen. It seems that we can only substitute variables, but not read
an arbitrary file.
The only solution I can think of is to set $RPM_OS_RELEASE_CPE along
with other variables in the rpm setup, and use that via getenv in
/usr/lib/rpm/redhat/redhat-package-notes.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Mass Rebuild 41 has completed
On Tue, Jul 23, 2024 at 01:19:27AM +0200, Miro Hrončok wrote:
> On 23. 07. 24 1:07, Zbigniew Jędrzejewski-Szmek wrote:
> > I noticed the following when comparing packages after the rebuild:
> >
> > │ │ │
> > -{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> > │ │ │
> > +{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
> >
> > It seems the info in os-release hasn't been updated so the
> > package notes embedded in the binaries are off.
>
>
> package-notes has:
>
> %build
> sed "s|@OSCPE@|$(cat /usr/lib/system-release-cpe)|" %{SOURCE0}
> >redhat-package-notes
>
> But the last build before the mass rebuild happened on Fedora 40.
>
> To prevent this situation in the future, package-notes needs to be rebuilt
> right after branching.
You are right, that's really a bug in package-notes.
I think we could replace the static string with a read of
/usr/lib/system-release-cpe.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Mass Rebuild 41 has completed
I noticed the following when comparing packages after the rebuild:
│ │ │
-{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
│ │ │
+{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
It seems the info in os-release hasn't been updated so the
package notes embedded in the binaries are off.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
On Mon, Jul 22, 2024 at 05:12:44PM +0200, Clemens Lang wrote: > Hi, > > > On 22. Jul 2024, at 16:32, Fabio Valentini wrote: > > > > On Mon, Jul 22, 2024 at 4:28 PM Clemens Lang wrote: > >> > >> Hi Neal, > >> > >> > >>> On 22. Jul 2024, at 15:01, Neal Gompa wrote: > >>> > >>> The CentOS approach isn't a deprecation, it's flat out removal. It's a > >>> completely different change. > >> > >> This isn’t correct. The headers are removed, but the ABI is still present > >> in CentOS Stream, so it is not flat out removal. > > > > This is arguing about semantics, but probably the difference is that > > packages in Fedora really MUST be kept in a state where they can be > > rebuilt at any time, and removing the headers breaks that. It doesn't > > break existing packages, but as soon as any changes need to be made to > > any package that depends on those headers (or just a plain rebuild for > > some other change in the distribution, or a mass rebuild), it *is* > > equivalent to a removal. > > There are three cases: > > (1) packages that are broken now because they don’t yet depend on > openssl-devel-engine and do not set OPENSSL_NO_ENGINE. > (2) packages that have been fixed by adding -DOPENSSL_NO_ENGINE to CPPFLAGS > (3) packages that have been fixed by adding a dependency on > openssl-devel-engine > > If we change OpenSSL to define OPENSSL_NO_ENGINE by default, with an override > available, that affects these three cases as follows: > > (1) now (hopefully, unless it’s an upstream bug) automatically don’t use > ENGINEs, build should be fixed > (2) no change, continues to build > (3) continues to build, but stops using ENGINEs (but the maintainer would get > a bug ticket about that from me, and then can set > -DFEDORA_OPENSSL_STILL_USE_ENGINES) > > > At no point would a package move to a state where it doesn’t build. > > > (1) and (2) improve the situation for package maintainers. (3) is some extra > work, but it’s also not fail-silent due to the ticket. > > The alternative is doing nothing, which means packages in (1) stay broken and > need to be fixed by somebody, and everybody else gets to keep the > -DOPENSSL_NO_ENGINE define or dependency on openssl-devel-engine in their > specfiles. At this point, this sounds like the best approach. The problem is well understood and the build failures are trivially resolved by adding a single BuildRequires line or a single define. If we start changing things again, some packages will already adapted will need to adapt again, and overall there'll much more confusion. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
On Mon, Jul 22, 2024 at 01:34:39PM +0200, Dmitry Belyavskiy wrote: > So I wonder if it's worth changing the engine deprecation mechanism in > Fedora to the one we have in CentOS and if yes, what is the mechanism > for such a change. Does is make sense at this point? The mass rebuild is (almost?) finished and I would expect that packages that needed to be updated for this already were. Do you have any statistics about how many packages still fail to build because of the lacking header file? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nbdkit -> openssl-devel-engine build dependency
On Fri, Jul 19, 2024 at 12:06:21PM +0100, Richard W.M. Jones wrote: > Zbigniew (correctly) added this patch to nbdkit: > > > https://src.fedoraproject.org/rpms/nbdkit/c/6b18b74749efbe1f618ea4bc010b56277157b0ac?branch=rawhide > > I was wondering what it was for because we don't use openssl at all. > However when I rebuild nbdkit without the BuildRequires, it fails [see > below]. > > It seems the _real_ problem may be that either boost-devel or > rb_libtorrent-devel should runtime Requires: openssl-devel-engine? > > However I'm not confident enough to say for sure if I should file a > bug in those packages (or which one to open a bug against). I also > have no idea what openssl "engine" is. > > Can anyone help on this? > > Rich. > > Failed build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=120734527 > > /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I../../../plugins/torrent -I../.. -I../../../include -I../../include > -I../../../common/include -I../../../common/utils -I.-pthread > -fexceptions -DTORRENT_LINKING_SHARED -DBOOST_ASIO_ENABLE_CANCELIO > -DBOOST_ASIO_NO_DEPRECATED -DTORRENT_USE_OPENSSL -DTORRENT_USE_LIBCRYPTO > -DTORRENT_SSL_PEERS -DOPENSSL_NO_SSL2 -O2 -flto=auto -ffat-lto-objects > -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security > -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -c -o nbdkit_torrent_plugin_la-torrent.lo `test > -f 'torrent.cpp' || echo '../../../plugins/torrent/'`torrent.cpp > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../plugins/torrent -I../.. > -I../../../include -I../../include -I../../../common/include > -I../../../common/utils -I. -pthread -fexceptions -DTORRENT_LINKING_SHARED > -DBOOST_ASIO_ENABLE_CANCELIO -DBOOST_ASIO_NO_DEPRECATED -DTORRENT_USE_OPENSSL > -DTORRENT_USE_LIBCRYPTO -DTORRENT_SSL_PEERS -DOPENSSL_NO_SSL2 -O2 -flto=auto > -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall > -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 > -march=x86-64 -mtune=generic -fasynchronous-unwind-tables > -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -c > ../../../plugins/torrent/torrent.cpp -fPIC -DPIC -o > .libs/nbdkit_torrent_plugin_la-torrent.o > make[3]: Leaving directory > '/builddir/build/BUILD/nbdkit-1.39.10-build/nbdkit-1.39.10/build_native/plugins/torrent' > In file included from /usr/include/boost/asio/ssl/context_base.hpp:19, > from /usr/include/boost/asio/ssl/context.hpp:23, > from /usr/include/boost/asio/ssl.hpp:18, > from /usr/include/libtorrent/ssl.hpp:67, > from /usr/include/libtorrent/tracker_manager.hpp:69, > from /usr/include/libtorrent/alert_types.hpp:69, > from ../../../plugins/torrent/torrent.cpp:48: > /usr/include/boost/asio/ssl/detail/openssl_types.hpp:26:11: fatal error: > openssl/engine.h: No such file or directory >26 | # include > | ^~ > compilation terminated. /usr/include/boost/asio/ssl/detail/openssl_types.hpp has #if !defined(OPENSSL_NO_ENGINE) # include #endif // !defined(OPENSSL_NO_ENGINE) so it looks like boost-devel itself is fine with openssl-devel-engine not being installed, so I don't think the package add the dependency. Similarly, it seems that rb_libtorrent does't specifically care about openssl engines in any way, so I don't think the package add the dependency. Thus, it seems that it's up to the "leaf" package including those headers to decide whether to include with openssl engine headers enabled. And to "decide", each package must either opt-in by pulling in openssl-devel-engine or define OPENSSL_NO_ENGINE. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sha1 policy not updated in rawhide
On Thu, Jul 18, 2024 at 08:00:05PM +0200, Miro Hrončok wrote: > On 18. 07. 24 19:52, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 18, 2024 at 03:49:11PM +0200, Alexander Sosedkin wrote: > > > On Thu, Jul 18, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > We recently noticed in systemd upstream that sha1 signing is _not_ > > > > failing in rawhide. And indeed, the default crypto policy has > > > > not been updated to disallow sha1 signatures in rawhide yet. If this > > > > is supposed to happen for F41, it should have happened before the mass > > > > rebuild so that we don't get unexpected build failures later on. > > > > > > As for why I've only landed it now --- unlucky timing. > > > First (from Jun 25) I was waiting for the ticket to be assigned, > > > in accordance to the changes policy, > > > > I think this is a misunderstanding. Once something is approved by FESCo, > > it's fine to push the changes. > > The FESCo ticket says: > > """ > Owners, do not implement this work until the FESCo vote has explicitly ended. > The Fedora Program Manager will create a tracking bug in Bugzilla for this > Change, which is your indication to proceed. > """ > > See https://pagure.io/fesco/issue/3229 (or any other change ticket) > > It took 2 weeks form approval to tracking bug creating, and there is no > Fedora Program Manager any more. > > If we want to avoid such delays, the template needs to be updated to mention > a different "indication to proceed". /cc Aoife -- ___ 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: sha1 policy not updated in rawhide
On Thu, Jul 18, 2024 at 03:49:11PM +0200, Alexander Sosedkin wrote: > On Thu, Jul 18, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek > wrote: > > We recently noticed in systemd upstream that sha1 signing is _not_ > > failing in rawhide. And indeed, the default crypto policy has > > not been updated to disallow sha1 signatures in rawhide yet. If this > > is supposed to happen for F41, it should have happened before the mass > > rebuild so that we don't get unexpected build failures later on. > > As for why I've only landed it now --- unlucky timing. > First (from Jun 25) I was waiting for the ticket to be assigned, > in accordance to the changes policy, I think this is a misunderstanding. Once something is approved by FESCo, it's fine to push the changes. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sha1 policy not updated in rawhide
On Thu, Jul 18, 2024 at 03:37:13PM +0200, Alexander Sosedkin wrote: > Did your testing include this update from yesterday? > https://bodhi.fedoraproject.org/updates/FEDORA-2024-1f014d035e It didn't. So it seems all good, thanks. (I think this update didn't make it out into a compose yet, but it'll be visible for the rebuilds in koji, which is what matters.) 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
sha1 policy not updated in rawhide
Hi, We recently noticed in systemd upstream that sha1 signing is _not_ failing in rawhide. And indeed, the default crypto policy has not been updated to disallow sha1 signatures in rawhide yet. If this is supposed to happen for F41, it should have happened before the mass rebuild so that we don't get unexpected build failures later on. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: fedora-repoquery tool (self-contained)
On Thu, Jul 18, 2024 at 07:09:18PM +0800, Jens-Ulrik Petersen wrote: > On Thu, Jul 18, 2024 at 7:02 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Wed, Jul 17, 2024 at 09:49:36PM +0100, Aoife Moloney wrote: > > > Wiki - https://fedoraproject.org/wiki/Changes/fedora-repoquery_tool > > > Discussion Thread - > > > > > https://discussion.fedoraproject.org/t/f41-change-proposal-fedora-repoquery-tool-self-contained/126066 > > : > > > Oh, fedrq vs. fdrq. I expect that this is going to cause endless > > confusion. People will think it's a typo, not a separate project. > > (I just read this text, looked at the review request, and I > > immediately wanted to ask why 'fedora-repoquery' creates a symlink as > > 'fdrq', won't that conflict with the existing package? But of course > > it doesn't.) > > > > Did you consider giving it some completely different name? > > > > Thanks, I am thinking... there have already been some related comments in > Discourse. Oh, I didn't look there. I see now. > People can use the long alias "fedora-repoquery" of course. > I would like to have a short name too though: since the long name is far > too long for me. > I am open to ideas/suggestions I suppose. > > Today I thought "frq" might be a more distinct name than fdrq. I agree with the comments on discourse: not better ;) Maybe take a leaf out of dracut's and wayland's book and just invent a random name or use the name of a place you like? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: PyTorch 2.4 (self-contained)
On Wed, Jul 17, 2024 at 10:00:52PM +0100, Aoife Moloney wrote: > Wiki - https://fedoraproject.org/wiki/Changes/PyTorch2.4 > Discussion Thread - > https://discussion.fedoraproject.org/t/f41-change-proposal-pytorch-2-4-self-contained/126069 > == Scope == > * Proposal owners: Update base to 2.4 when upstream releases. Any details on when that'll happen? We need to know how this aligns with the Fedora release dates… Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: fedora-repoquery tool (self-contained)
On Wed, Jul 17, 2024 at 09:49:36PM +0100, Aoife Moloney wrote: > Wiki - https://fedoraproject.org/wiki/Changes/fedora-repoquery_tool > Discussion Thread - > https://discussion.fedoraproject.org/t/f41-change-proposal-fedora-repoquery-tool-self-contained/126066 > == Detailed Description == > fedora-repoquery (fdrq for short) has been in development for a while, > and with the 0.6 release now > should be polished enough now to be included in Fedora for broader usage. > See the [https://github.com/juhp/fedora-repoquery#readme readme] file > for usage examples. > > I am aware of fedrq which is somewhat similar to fedora-repoquery, but > has a different design and emphasis. > The biggest difference being that fedora-repoquery supports easily > querying different OS release versions, > and also tells you by default in which specific repo a partcular package > lives. Oh, fedrq vs. fdrq. I expect that this is going to cause endless confusion. People will think it's a typo, not a separate project. (I just read this text, looked at the review request, and I immediately wanted to ask why 'fedora-repoquery' creates a symlink as 'fdrq', won't that conflict with the existing package? But of course it doesn't.) Did you consider giving it some completely different name? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Privacy-conscious policy for Fedora Linux [was Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)]
On Thu, Jul 18, 2024 at 11:01:37AM +0100, Daniel P. Berrangé wrote: > On Thu, Jul 18, 2024 at 09:48:21AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jul 17, 2024 at 02:13:12PM -0500, Michel Lind wrote: > > > On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote: > > > > On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote: > > > > > That said, it is not sufficient to reject adding Fedora downstream > > > > > spyware. > > > > > Fedora also needs a policy that upstream "telemetry" spyware is not > > > > > allowed > > > > > and needs to be disabled at compile time or patched out. We have > > > > > several > > > > > packaged applications wanting to "phone home" for this kind of > > > > > "anonymized > > > > > usage statistics". This should not be allowed in a privacy-concious > > > > > distribution. > > > > > > > > I'm not convinced that that's the exact policy we want, but I do agree > > > > that > > > > we should have a stated policy. There was some work on a "privacy > > > > policy for > > > > the OS" a while ago, but that basically ran aground in the choppy > > > > waters of > > > > legal statements -- and I think a similar attempt would run into the > > > > same > > > > problems. But, we could have a policy that _isn't_ a legal statement; > > > > basically a packaging guideline. > > > > > > > I'd be happy to help with that - should Council look at this first or > > > should this go straight to either FESCo or FPC? > > > > Hi, > > > > a long time ago I wanted to propose a more formal policy for privacy > > behaviours and I wrote this draft [1]. My idea was that we'd first > > create and approve such a policy, and then add the conformance to this > > policy to the packaging guidelines. Maybe this draft can be useful. > > If a policy is created, I'd like to participate in the process. > > > > [1] > > https://in.waw.pl/~zbyszek/fedora/fedora-privacy-policy-draft-20210531.md > > FWIW, that could have a "debuginfod" section added, since that transmits > info about software you're debugging to Fedora infra - IIUC even if it is > not Fedora built/distributed software Good point! This text was written in 2021, when debuginfod still wasn't a thing. That, and the now-approved Workstation metrics are prominent omissions. I also see that flatpaks/flathub are not mentioned… Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Privacy-conscious policy for Fedora Linux [was Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)]
On Wed, Jul 17, 2024 at 02:13:12PM -0500, Michel Lind wrote: > On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote: > > On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote: > > > That said, it is not sufficient to reject adding Fedora downstream > > > spyware. > > > Fedora also needs a policy that upstream "telemetry" spyware is not > > > allowed > > > and needs to be disabled at compile time or patched out. We have several > > > packaged applications wanting to "phone home" for this kind of > > > "anonymized > > > usage statistics". This should not be allowed in a privacy-concious > > > distribution. > > > > I'm not convinced that that's the exact policy we want, but I do agree that > > we should have a stated policy. There was some work on a "privacy policy for > > the OS" a while ago, but that basically ran aground in the choppy waters of > > legal statements -- and I think a similar attempt would run into the same > > problems. But, we could have a policy that _isn't_ a legal statement; > > basically a packaging guideline. > > > I'd be happy to help with that - should Council look at this first or > should this go straight to either FESCo or FPC? Hi, a long time ago I wanted to propose a more formal policy for privacy behaviours and I wrote this draft [1]. My idea was that we'd first create and approve such a policy, and then add the conformance to this policy to the packaging guidelines. Maybe this draft can be useful. If a policy is created, I'd like to participate in the process. [1] https://in.waw.pl/~zbyszek/fedora/fedora-privacy-policy-draft-20210531.md Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sbin-merge: what to do?
On Mon, Jul 15, 2024 at 11:53:38PM -, Frank R Dana Jr. wrote: > I do not envy you this work. The documentation fallout alone... a quick and > dirty scan of only the man pages that happen to be *currently installed* on > my F40 system reveals that 487 / 2673 man pages in section 8 contain the > string 'sbin' somewhere in the troff source. All those paths will continue to work and there is no pressing need to adjust them. In fact, the first example you quoted shows this nicely: > sys-utils/rtcwake.8.adoc This page talks about "/sbin/shutdown", which has really been "/usr/sbin/shutdown" for ~14 years on Fedora systems. At some point it'll actually be "/usr/bin/shutdown", but the man page remains as valid as it was. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sbin-merge: what to do?
On Tue, Jul 16, 2024 at 09:19:24AM -0700, Kevin Fenzi wrote: > On Tue, Jul 16, 2024 at 11:51:28AM GMT, Neal Gompa wrote: > > On Tue, Jul 16, 2024 at 11:13 AM Adam Williamson > > wrote: > > > > > > On Tue, 2024-07-16 at 08:08 +0100, Daniel P. Berrangé wrote: > > > > On Mon, Jul 15, 2024 at 05:07:57PM -0700, Kevin Fenzi wrote: > > > > > On Mon, Jul 15, 2024 at 08:23:05AM GMT, Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > > > > > > So… the question now: should I pull the plug on the change for F41, > > > > > > dump the side tag, and try again for F42? Or wait for some of the > > > > > > patches > > > > > > above to be merged? The mass rebuild is supposed to start in two > > > > > > days… > > > > > > > > > > How hard would it be to move back to the old state? > > > > > Does that mean a bunch of reverts and rebuilds? or ? > > > > > > > > Assuming there was nothing impactful outside of the mentioned side tag, > > > > then no rebuilds should be required, just abandon the tag, and do > > > > dist-git reverts. > > yes, but... that has to happenright now or the mass rebuild will > just build all those things again and it will land in rawhide anyhow. FTR: I reverted (*) the changes in dist-git for rpm and filesystem. All other changes are either appropriate independently of the merge or conditionalized on %_sbindir==%_bindir, so they didn't need to be touched. The current plan is to wait for the f41 branching, and try again after that. The failure on ostree systems was discussed in the bootc group meeting and the tentative agreement is to: - add a virtual Provides:merged-sbin to filesystem - add code to the ostree tooling to create /usr/sbin symlink if the filesystem package has it. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: the sad state of installability tests
On Mon, Jul 15, 2024 at 08:55:03AM -0400, Stephen Gallagher wrote: > This seems like overkill. Wouldn't the simplest valid installability > test just be to test whether each subpackage *individually* could be > installed? That's a really nice idea. > If we have 20 subpackages, just launch 20 separate minimal containers > and see if `dnf install subpackageN` succeeds. Then it doesn't matter > if there are conflicts; we know that at least installing that package > directly will work. (Dependency resolution may pull in other > subpackages of course, which is proving that it works properly.) I'm not sure if we actually want a container. Because if it's a container, then we need _some_ packages inside. But that creates a problem for some packages like cannot be just installed, but need to be swapped with other packages. (systemd-standalone-*, coreutils-single, etc.) I think it'd be more reliable to do something like dnf install --enablerepo=/path/to/repo/with/updates --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package1.rpm dnf install --enablerepo=/path/to/repo/with/updates --sysroot=/var/tmp/inst-package1 /path/to/repo/with/updates/package2.rpm ... And to make this work reliably, the invocation of dnf should be wrapped in 'bwrap' to set up /dev, /proc for the invocation. This should be quick and more reliable than the current tests, even with no config. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: the sad state of installability tests
On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote: > V Mon, Jul 15, 2024 at 08:45:53AM +0000, Zbigniew Jędrzejewski-Szmek > napsal(a): > > On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > > > I guess the test does not take RPM Conflicts into account. It's overly > > > optimistic when populating a system by installing all tested packages > > > together > > > instead of creating a new system for each test seperately. Or by adding > > > --allowerasing to "dnf install" invocations if the CI wants to reuse > > > the system. > > > > Yes and no. The test does not look at the package metadata at all, it just > > tries to install all the packages that were part of the update. > > In the case above, coreutils.srpm builds coreutils.rpm and > > coreutils-single.srpm, > > which have Conflicts on one another, and cannot be installed at the same > > time. > > > > The test which (I think) we really want is to install the combined set > > of packages from the update, so we exercise the situation that will occur > > on end-user systems, but exclude the packages from this set which are known > > to be not co-installable. > > > Maybe I conflate installability tests with rpmdeplint tests. We need both: > A test which checks that each package is separately installable. And a test > which tcgecks that wanted combinations of packages can be installed together. > > I cannot see how "exclude the packages from this set which are known > to be not co-installable" can be achieved automatically. Either the test will > examine package metadata for Conflicts to exclude the conflicting packages, or > someone will have to maintain the good set of combinanations. Yes, I think those sets would need to be declared. The natural place for this declaration would be in dist-git of the package. For example for systemd: ci.ini: [InstallationGroups] group = *-standalone-* group = ~*-standalone-* For fedora-release: ci.ini: [InstallationGroups] group = fedora-release-common fedora-release*-basic group = fedora-release-common fedora-release*-budgie group = fedora-release-common fedora-release*-budgie-atomic group = fedora-release-common fedora-release*-cinnamon group = fedora-release-common fedora-release*-cloud group = fedora-release-common fedora-release*-compneuro group = fedora-release-common fedora-release*-container group = fedora-release-common fedora-release*-coreos group = fedora-release-common fedora-release*-designsuite group = fedora-release-common fedora-release*-i3 group = fedora-release-common fedora-release*-iot group = fedora-release-common fedora-release*-kde group = fedora-release-common fedora-release*-kinoite group = fedora-release-common fedora-release*-lxqt group = fedora-release-common fedora-release*-matecompiz group = fedora-release-common fedora-release*-mobility group = fedora-release-common fedora-release*-server group = fedora-release-common fedora-release*-silverblue group = fedora-release-common fedora-release*-snappy group = fedora-release-common fedora-release*-soas group = fedora-release-common fedora-release*-sway group = fedora-release-common fedora-release*-sway group = fedora-release-common fedora-release*-toolbx group = fedora-release-common fedora-release*-workstation group = fedora-release-common fedora-release*-xfce (I don't really care about the syntax. Just something that is easy to write and understand. And that the syntax is extensible to allow us to configure some other stuff in the future.) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: the sad state of installability tests
On Mon, Jul 15, 2024 at 10:39:37AM +0200, Cristian Le via devel wrote: > Hi Zbyszek, > > On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote: > > I'm looking for a solution which doesn't just skip the installability > > tests altogether. > > On PRs with zuul or FedoraCI automation, the same instability tests that are > done for Bodhi are performed. But what would help is to make these tests as > required to pass unless they are manually waved. Manually that can be done > by setting `gating.yaml`. There was some discussion on making some of these > tests as gating by default. > > Another issue specific to installability is that the issue is often further > down the stream, particularly with the SELinux test. Definitely these need > to be tracked down and fixed. I fully agree. But a test that just does 'dnf install rpms-from-update/*.rpm' will predicatably fail. > > A second problem is that when the tests fail, it's just s hard to > > find out why they failed.From the bodhi status page, one has to > > go to the Jenkins status page, guess that it's useful to look at > > Console Output, scroll over a few pages of incomrehensible JSON > > gibberish, guess that it's worth clicking on Testing Farm Artifacts URL, > > click that, scroll pages of output to see > > "guest setup failed: Test environment installation failed: Install > > packages". > > Weird, when the test is finished, you should have only the final > testing-farm results page. Here's an example [1]. Maybe in your case it > encountered an internal failure? > > [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-57f489c90d Maybe I'm doing things wrong. I'd be happy to learn. I do the following: 1. Look at the bodhi update page (https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8) 2. Click on 'Automated Tests' (There seems to be no URL for the view. This means that it's always and extra click after every page load or reload.) 3. I click on one of the pinkish lines, e.g. the first one. (Another usability problem here is that the click open a new page in new tab/window. Why, oh why? I want to use left-click to open a link in the existing tab, and middle-click to open a new tab. The current UI breaks navigation.) 4. I switch to the new tab and see https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/398487/ (BTW, I mentioned unrelated scary-looking warnings in my OP. Here: The following steps that have been detected may have insecure interpolation of sensitive variables (click here for an explanation): httpRequest: [TESTING_FARM_API_KEY] ) 5. Click on 'Console Output' 6. Click on 'Testing Farm Artifacts URL: https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb' 7. Click on 'build installation' (https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb/guest-setup-09b7edc6-0b7e-431b-ae68-afac2527fbb1/artifact-installation-09b7edc6-0b7e-431b-ae68-afac2527fbb1) 8. Click on 60-Install-packages.txt So 8 steps to get to the actual result… Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: the sad state of installability tests
On Mon, Jul 15, 2024 at 10:31:06AM +0200, Petr Pisar wrote: > Yes. Installability is a very basic test and it should be reliable. My > feeling is that broken dependencies are the most common packaging bug. > > > Or if it's not possible to make them work, disable them? In the > > current state we just waste everybody's time and teach packagers to > > ignore CI results. > > > As far as I know, installability tests are not required to pass gating by > default. Correct. > I think the problem is that the tests are run even if nobody asks for them. Well, I think it'd be fine if they were enabled by default _if_ they were reliable. > > one of them (60-Install-packages.txt) shows: > > Failed to resolve the transaction: > > Problem 1: package coreutils-9.5-4.fc41.x86_64 from @commandline > > conflicts with coreutils-single > > provided by coreutils-single-9.5-4.fc41.x86_64 from > > @commandline > > - conflicting requests > > I guess the test does not take RPM Conflicts into account. It's overly > optimistic when populating a system by installing all tested packages together > instead of creating a new system for each test seperately. Or by adding > --allowerasing to "dnf install" invocations if the CI wants to reuse > the system. Yes and no. The test does not look at the package metadata at all, it just tries to install all the packages that were part of the update. In the case above, coreutils.srpm builds coreutils.rpm and coreutils-single.srpm, which have Conflicts on one another, and cannot be installed at the same time. The test which (I think) we really want is to install the combined set of packages from the update, so we exercise the situation that will occur on end-user systems, but exclude the packages from this set which are known to be not co-installable. > > A third problem is that the output is full of things that _look_ like > > errors: > > > > Warning: Permanently added '3.14.151.22' (ED25519) to the list of known > > hosts. > > > > egrep: warning: egrep is obsolescent; using grep -E > > > > :36: (WARNING/2) Bullet list ends without a blank line; > > unexpected unindent. > > > > :9: (WARNING/2) Definition list ends without a blank line; > > unexpected unindent. > > > > This makes those jobs look semi-abandonded. It also makes it hard to > > look for the real error, because one has to consider each of those > > lines and answer the question "is this the error I'm looking for?". > > Yes, I've opened many issues regarding Fedora CI. I think the problem is that > the CI maintainer is not a regular packager and thus does not observe CI > reults in real life. On the other hand, package maintainers do not have accces > to the CI system and need to rely on the CI people. Or a CI person?!. The head > count is probably another problem. If there's one "CI person", then that is AdamW. He's doing great work (also in the update I linked in my original post). IIUC, AdamW's focus is on the 'update.*' tests, and those are fine, they generally pass. The bodhi results page says: For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team. For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team. For help debugging failed openQA tests (update.*), contact the Fedora Quality team, ... I added c...@lists.fedoraproject.org in CC. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Enable Drm Panic (system-wide)
On Sat, Jul 13, 2024 at 10:20:53AM -0500, Chris Adams wrote: > Once upon a time, Javier Martinez Canillas said: > > In other words, a user should still be able to log into a VT and fbcon is > > still attached to an (DRM emulated) fbdev. The only difference is that the > > kernel messages are not going to the VT. > > This still seems like a big step back for anything not running a > graphical desktop, e.g. servers. No more kernel messages on the > standard console by default is IMHO not good. > > It'd be a lot better if this was runtime configurable (like a kernel > command-line option) rather than compile-time. Yeah. If we could make the choice on the kernel command line (e.g. by having drm.panic_screen automatically disable kmsg output to the console), then this change would be more palatable. There's just so many different and special ways in how people hook up console logging from VMs and other systems. Disabling VT_CONSOLE at compile time is hard to defend. 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
sbin-merge: what to do?
Hi! I've been trying to implement the sbin-merge for F41 [1]. Side tag f41-build-side-92231 was created and about 80 packages were rebuilt there. This is enough to implement the merge on "normal" end-user systems and in buildroots for packages in mock and koji. The current status is that the pending bodhi update [2] from the side tag is blocked on failing tests. The tests in the CI caught a number of issues: 1. Installability tests (*.functional) are generally busted and can be ignored. I wrote a mail about that yesterday [3]. 2. Images built with lorax are missing a bunch of executables. It turns out that lorax templates filter executables by path, so we end up with images that don't have /usr/bin/losetup, /usr/bin/mkswap, but OTOH have various binaries that were supposed to be removed but are now in /usr/bin. [3] should fix the issue. This is a fairly simple change, so I imagine it _could_ be merged and pushed out quickly. (I'll note on the side here that that filtering seems to be generally busted. In the image I looked at, the rpm database was present, as was the dnf installation, but /usr/bin/rpm was not. That doesn't make any sense, since the rpmdb is not really useful without rpm, and dnf won't do anything without rpm either. And this is all not related to the sbin merge, since /usr/bin/rpm and /usr/bin/dnf haven't moved… IMO, the approach taken by mkosi-initrd, i.e. using packages to build the image, and fixing packaging to be more granural in cases where we need more granularity is a better approach. Filtering paths by glob will always be ineffective (because the binary is removed, but not everything else it pulled in), fragile (because binaries move, gain and lose dependencies, or new binaries are added), wasteful (because we need to reimplement similar filtering in multiple places (lorax, dracut, container builds, custom images), and inefficient to implement or change (the template is embedded in code).) 3. rpm-ostree builds are broken because they create the basic filesystem setup in a custom way, not using filesystem.rpm, so we end up with neither the compat symlink from /usr/sbin→bin nor the individual compat symlinks /usr/sbin/*→../bin/* when individual packages that were rebuilt in the new worldview are used to build ostree images [4,5]. I don't have a good understanding of the extent of this bug (i.e. if all or only some images are affected) and how hard it'll be fix. As a partial workaround, I've been submitting pull requests to remove full paths from scriptlets. This helps with the ostree images, but is the is the right thing to do in any case [6,7]. With this, the ostree images would be good enough to pass CI, but it's not a full solution. 4. The tests install a mix of old and new packages, and uncovered the following failure mode: package A with files in sbin is rebuilt with merged-sbin, but no other package has Requires on paths in package A, so we didn't need to add compat Provides to A, so it doesn't have any Requires on the new filesystem package, so rpm will happilly install it on a system with old filesystem rpm. The compat symlinks are not created. Rpms work, but scripts that call the old path with /usr/sbin will fail. To hit this, one has to do partial upgrade, but of course this is supported and must work. To avoid this, I want to add a rpm fileattr generator that will generate 'Requires: filesystem(unmerged-sbin-symlinks)' for packages which have files in /usr/bin that previously were in /usr/sbin, meaning that those packages when rebuilt in the new worldview will require an updated filesystem.rpm to be installed too. There's hundreds of such packages, so having one generator is nicer than adding the requirement explicilty to individual packages. The generator would be added to filesystem subpackage [8] that would be pulled in via redhat-rpm-config [9]. So… the question now: should I pull the plug on the change for F41, dump the side tag, and try again for F42? Or wait for some of the patches above to be merged? The mass rebuild is supposed to start in two days… Zbyszek [1] https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin [2] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW2YGOMR5UAXV2CHWOJWGPNLWDRRNO43/ [3] https://github.com/weldr/lorax/pull/1409 [4] https://github.com/coreos/fedora-coreos-tracker/issues/1714#issuecomment-2223100778 [5] https://gitlab.com/fedora/bootc/tracker/-/issues/29 [6] https://src.fedoraproject.org/rpms/selinux-policy/pull-request/448 [7] https://src.fedoraproject.org/rpms/cifs-utils/c/934e038df9023177535e7cda564624ce773f0f0a [8] https://src.fedoraproject.org/rpms/filesystem/pull-request/15 [9] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/308 --
the sad state of installability tests
CI for Bodhi updates has a bunch of tests like fedora-ci.koji-build.tier0.functional fedora-ci.koji-build./plans/public.functional that routinely fail. In fact, they are designed in a way where they _must_ fail for many important packages: systemd, fedora-release, coreutils, and anything else which has conflicting subpackages. (Example: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8) This is particularly annoying for multi-package updates, because the test will fail if _any_ of the packages are like this. Package installability is the most basic test. This should never fail. Can we please make this not fail? Or if it's not possible to make them work, disable them? In the current state we just waste everybody's time and teach packagers to ignore CI results. I'm looking for a solution which doesn't just skip the installability tests altogether. For zuul, we can set install_repo_exclude with a list of subpackage names in .zuul.yaml. That's an acceptable solution, but this configuration should not be specific to zuul, but should be picked up automatically by everything that tries to install the build outputs. (Maybe, in some distant future, maybe even 'mock --postinstall' could understand it? That currently fails for those packages in exactly the same way as the CI tests…) (Ideally, it would be possible to test installation of all subpackages. Those excluded subpackages may have bugs like any other package. A solution where we can specify which packages to install in groups would be great. But I guess that's hard. I'd settle for a half-solution like with zuul.) -- A second problem is that when the tests fail, it's just s hard to find out why they failed. From the bodhi status page, one has to go to the Jenkins status page, guess that it's useful to look at Console Output, scroll over a few pages of incomrehensible JSON gibberish, guess that it's worth clicking on Testing Farm Artifacts URL, click that, scroll pages of output to see "guest setup failed: Test environment installation failed: Install packages". Why? Oh, maybe it's time to click on random links. And yes, under "build installation" there is 80 links to text files, and one of them (60-Install-packages.txt) shows: Failed to resolve the transaction: Problem 1: package coreutils-9.5-4.fc41.x86_64 from @commandline conflicts with coreutils-single provided by coreutils-single-9.5-4.fc41.x86_64 from @commandline - conflicting requests ... Maybe if somebody is using the CI every day, they can memorize those magical pathways, but for a Joe Random Packager like me, it's takes way more time than it should to find the actual failure. Right now we show the debug logs for the CI pipelines and hide the actual test output. Can we instead make those 10 lines of actual test failure immediately visibile? -- A third problem is that the output is full of things that _look_ like errors: Warning: Permanently added '3.14.151.22' (ED25519) to the list of known hosts. egrep: warning: egrep is obsolescent; using grep -E :36: (WARNING/2) Bullet list ends without a blank line; unexpected unindent. :9: (WARNING/2) Definition list ends without a blank line; unexpected unindent. This makes those jobs look semi-abandonded. It also makes it hard to look for the real error, because one has to consider each of those lines and answer the question "is this the error I'm looking for?". Again, a time drain and a source of confusion for packagers who don't use the system every day. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPAM LOW]Re: Home made tutorial to help beginners into packaging
On Sun, Jul 14, 2024 at 03:23:56PM +0200, Sébastien Le Roux wrote: > > Cool! > Thanks ! > > On page 40, 'cc_args =' is not going to work, that's a syntax error. > > But a bigger problem is that there's no need to play with -O and -g > > like that… Meson has builtin -D buildtype=… and it's beter to use that. > > It also has built-in support e.g. for lto, so it's better to push user > > to use those standard interfaces. > I actually think it will work, see how I use cc_args and fc_args in the > exectuable () instruction, 'foo =' is not a valid statement. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: whatcanidoforfedora.org is stale
On Fri, Jul 12, 2024 at 12:20:57PM +0100, Ankur Sinha wrote: > On Fri, Jul 12, 2024 09:49:45 GMT, Zbigniew Jędrzejewski-Szmek wrote: > > Should we just put a huge redirect on whatcanidoforfedora to > > https://fedoraproject.org/wiki/Welcome? > > > > I edited https://fedoraproject.org/wiki/Welcome to have the nice > > "Welcome to Fedora!" banner at the top. The page was a bit cool without > > any graphics. > > Thanks for that, looks much better. :) > > There's also this page in the docs: > https://docs.fedoraproject.org/en-US/project/join/ > > Perhaps we incorporate the banner to this docs page and make both wcidff > and the wiki page redirect to it (so that we have one central page to > point folks to and maintain)? https://pagure.io/Fedora-Council/council-docs/pull-request/229 adds the banner. Yeah, I think it'd make the redirects. The wiki page as soon as the above is merged. wcidff is nobody steps up to update it in two weeks ;) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Home made tutorial to help beginners into packaging
On Sun, Jul 14, 2024 at 11:50:28AM +0200, Sébastien Le Roux wrote: > Hello, > go figured but the past days have been intense for me (on the meson side of > things), > after your email I decided to give a look to meson, and then discovered > something > really interesting that pushed me to try and move my project to meson, to > give it a try, > and then I figured that I could add the meson part to my tutorial ... after > all ... and I did ... > So against my previous thoughts meson is now officially part of the manual > ... not sure yet but > I might be really grateful that you pointed me towards it, so thank you > really ! Cool! On page 40, 'cc_args =' is not going to work, that's a syntax error. But a bigger problem is that there's no need to play with -O and -g like that… Meson has builtin -D buildtype=… and it's beter to use that. It also has built-in support e.g. for lto, so it's better to push user to use those standard interfaces. In "Declaring project sources", it'd be better to use files(). Then meson immediately knows that the string is a file and will complain if the file is not found. You say "complete list of source file(s) must be provided": - "file(s)" is the formatting used in DOS messages, and it's a … bad idea. Just say "sources files". - Actually, only not all source files, because headers (and other files that are transitively included) do not need to be listed. This is not obvious, but it's a nice simplification not to have to list header files. Overall, looks good. This is a reasonable introduction to Meson. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Fri, Jul 12, 2024 at 04:04:52PM -0400, Stephen Gallagher wrote: > On Fri, Jul 12, 2024 at 3:18 PM Kevin Fenzi wrote: > > > > On Fri, Jul 12, 2024 at 09:11:49AM GMT, Stephen Gallagher wrote: > > > > > > Well, one thing that we ALSO lost in the conversion to Matrix was that > > > the minutes used to include links to the full text (in both text and > > > HTML formats) on meetbot.fedoraproject.org > > > In that case, the summary was enough to at least let people know 1) > > > what was discussed and 2) if a decision was made. If they wanted more, > > > a handy link was available to get the full logs. > > > > > > I have been trying to remember to manually add those links back when I > > > chair, but I'm inconsistent (at best). > > > > If something is missing that was there before, please do file a RFE on > > it. > > > > https://github.com/GregSutcliffe/maubot-meetings/issues > > > > or do you mean the web interface? > > https://github.com/fedora-infra/mote > > > > Possibly https://github.com/fedora-infra/mote/issues/684 ? > > ^^ This is exactly what I'm referring to. https://github.com/fedora-infra/mote/pull/712 has been up since April. Let's push it over the finishing line! Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Enable Drm Panic (system-wide)
On Fri, Jul 12, 2024 at 01:21:41PM -0400, Neal Gompa wrote: > On Fri, Jul 12, 2024 at 1:12 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Jul 12, 2024 at 05:53:25PM +0100, Aoife Moloney wrote: > > > In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the > > > kernel > > > > The idea for DRM_PANIC is nice, but I worry about the impact of disabling > > VT_CONSOLE. Plymouth is not used everywhere, e.g. what about cloud images > > and such? Also, when debugging boot troubles, removing 'rhbg' and 'quiet' > > are the often first steps. > > > > I cannot actually recall the last time when I had a kernel crash > > on any of my machines… It seems like we might be sacrificing debugability > > for a feature which would be used very rarely. > > > > Do we lose the serial console as part of this? Or is there a serial > console "thing" somewhere still? I think the serial console is not affected. The kernel Kconfig says: config VT_CONSOLE bool "Support for console on virtual terminal" if EXPERT depends on VT default y help The system console is the device which receives all kernel messages and warnings and which allows logins in single user mode. If you answer Y here, a virtual terminal (the device used to interact with a physical terminal) can be used as system console. This is the most common mode of operations, so you should say Y here unless you want the kernel messages be output only to a serial port (in which case you should say Y to "Console on serial port", below). If you do say Y here, by default the currently visible virtual terminal (/dev/tty0) will be used as system console. You can change that with a kernel command line option such as "console=tty3" which would use the third virtual terminal as system console. (Try "man bootparam" or see the documentation of your boot loader (lilo or loadlin) about how to pass options to the kernel at boot time.) If unsure, say Y. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Enable Drm Panic (system-wide)
On Fri, Jul 12, 2024 at 05:53:25PM +0100, Aoife Moloney wrote: > In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the > kernel The idea for DRM_PANIC is nice, but I worry about the impact of disabling VT_CONSOLE. Plymouth is not used everywhere, e.g. what about cloud images and such? Also, when debugging boot troubles, removing 'rhbg' and 'quiet' are the often first steps. I cannot actually recall the last time when I had a kernel crash on any of my machines… It seems like we might be sacrificing debugability for a feature which would be used very rarely. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Thu, Jul 11, 2024 at 01:46:04PM -0400, Josh Boyer wrote: > I'm saying the thing they > are doing today is not really valuable for a consumer base that wasn't > in the meeting. If they want to make it better, AI is a tool that is > actually pretty simple to use to do that without a ton of effort. If > they don't want to make it better, then maybe just stop publishing the > summary emails entirely and save themselves and others time. The > meeting logs will still be there. Meh, that's throwing out the baby with the bathwater. The idea of the summary is very simple: the text consists of a series of # ticket , do this and that → resolution: APPROVED/REJECTED (+x, ±y, -z) optionally: links or additional infos link to minutes link to full log When this is implemented correctly, it is enough for the interested parties to get a general idea of what happened in the meeting. Sometimes we mess things up, but there is no reason why this summary wouldn't be useful when done correctly. (The case that doesn't work well is when there is no clear decision and we don't record anything. We should make it a habit to at least record '!info We will return to this next week' to make the summary more useful.) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-07-09)
On Thu, Jul 11, 2024 at 11:33:07AM -0400, Josh Boyer wrote: > I just want better summaries than what zodbot is currently providing I agree that the summaries aren't great. The formatting is worse than what we had on IRC. This is something that we should improve. > (which aren't reviewed either afaics...) They are. When I send out the summary, I'll go over it to remove duplicate lines (the new zodbot doesn't implement !undo yet) and add clarifications if something is not clear without context. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: whatcanidoforfedora.org is stale
On Fri, Jul 12, 2024 at 09:57:56AM +0100, Ankur Sinha wrote:
> Hello,
>
> On Fri, Jul 12, 2024 07:03:57 GMT, Zbigniew Jędrzejewski-Szmek wrote:
> > I looked at the page today, and it advertises:
> > - modularity
> > - in the python section:
> > - abrt (attention here would be welcome, but isn't the project mostly
> > dead?)
> > - dnf (not in Python anymore…)
> > - portingdb ("a dynamic database of Python 2 packages needing to be
> > updated to Python 3")
> >
> > Rust is not mentioned. Neither are other new(ish) things…
> >
> > I think the page was/is a nice idea, but right now it's as likely to
> > discourage and confuse as to help somebody.
>
> It's been outdated for a while. I agree. It was a nice idea but unless
> it's kept regularly up to date, it's better not to have it.
>
>
> We do have the "Welcome To Fedora" process that seems to work well:
> https://pagure.io/fedora-join/WelcomeToFedora
Should we just put a huge redirect on whatcanidoforfedora to
https://fedoraproject.org/wiki/Welcome?
I edited https://fedoraproject.org/wiki/Welcome to have the nice
"Welcome to Fedora!" banner at the top. The page was a bit cool without
any graphics.
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
whatcanidoforfedora.org is stale
I looked at the page today, and it advertises:
- modularity
- in the python section:
- abrt (attention here would be welcome, but isn't the project mostly dead?)
- dnf (not in Python anymore…)
- portingdb ("a dynamic database of Python 2 packages needing to be updated
to Python 3")
Rust is not mentioned. Neither are other new(ish) things…
I think the page was/is a nice idea, but right now it's as likely to
discourage and confuse as to help somebody.
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
PSA: sbin-merge in progress, do not rebuild packages in the side tag
The rebuilds for https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
are in progress in f41-build-side-92231. (Or more precisely, the builds are
done, but we're trying to figure out CI failures before merging the side tag.)
If your package was built in the side tag, please do not build it outside
until the tag is merged.
The builds have changelog entries like 'Rebuilt for the bin-sbin merge'
or similar. The full list is below:
$ koji list-tagged --latest f41-build-side-92231
Build Tag Built by
bind-9.18.26-2.fc41 f41-build-side-92231 zbyszek
chkconfig-1.28-2.fc41 f41-build-side-92231 zbyszek
coreutils-9.5-4.fc41 f41-build-side-92231 zbyszek
cyrus-sasl-2.1.28-26.fc41 f41-build-side-92231 zbyszek
device-mapper-multipath-0.9.9-2.fc41 f41-build-side-92231 zbyszek
device-mapper-persistent-data-1.0.12-2.fc41 f41-build-side-92231 zbyszek
dmidecode-3.6-2.fc41 f41-build-side-92231 zbyszek
dosfstools-4.2-12.fc41f41-build-side-92231 zbyszek
e2fsprogs-1.47.1-2.fc41 f41-build-side-92231 zbyszek
efibootmgr-18-6.fc41 f41-build-side-92231 zbyszek
esmtp-1.2-25.fc41 f41-build-side-92231 zbyszek
exim-4.97.1-9.fc41f41-build-side-92231 zbyszek
filesystem-3.18-16.fc41 f41-build-side-92231 zbyszek
fping-5.2-2.fc41 f41-build-side-92231 zbyszek
glibc-2.39.9000-31.fc41 f41-build-side-92231 zbyszek
glusterfs-11.1-5.fc41 f41-build-side-92231 zbyszek
gnupg2-2.4.5-2.fc41 f41-build-side-92231 zbyszek
hdparm-9.65-5.fc41f41-build-side-92231 zbyszek
httpd-2.4.61-2.fc41 f41-build-side-92231 zbyszek
initscripts-10.25-2.fc41 f41-build-side-92231 zbyszek
iproute-6.8.0-4.fc41 f41-build-side-92231 zbyszek
iptables-1.8.10-12.fc41 f41-build-side-92231 zbyszek
iputils-20240117-5.fc41 f41-build-side-92231 zbyszek
kexec-tools-2.0.28-11.fc41f41-build-side-92231 zbyszek
kmod-31-6.fc41f41-build-side-92231 zbyszek
libcap-2.70-3.fc41f41-build-side-92231 zbyszek
libguestfs-1.53.5-2.fc41 f41-build-side-92231 zbyszek
libreswan-4.15-3.fc41 f41-build-side-92231 zbyszek
libselinux-3.7-4.fc41 f41-build-side-92231 zbyszek
lm_sensors-3.6.0-19.fc41 f41-build-side-92231 zbyszek
lvm2-2.03.24-4.fc41 f41-build-side-92231 zbyszek
msmtp-1.8.25-2.fc41 f41-build-side-92231 zbyszek
msr-tools-1.3-25.fc41 f41-build-side-92231 zbyszek
nbdkit-1.39.8-2.fc41 f41-build-side-92231 zbyszek
net-tools-2.0-0.70.20160912git.fc41 f41-build-side-92231 zbyszek
nfs-utils-2.6.4-0.rc6.fc41.1 f41-build-side-92231 zbyszek
nilfs-utils-2.2.11-2.fc41 f41-build-side-92231 zbyszek
ntpsec-1.2.3-6.fc41 f41-build-side-92231 zbyszek
ocfs2-tools-1.8.8-4.fc41 f41-build-side-92231 zbyszek
opensmtpd-7.5.0p0-2.fc41 f41-build-side-92231 zbyszek
pciutils-3.13.0-4.fc41f41-build-side-92231 zbyszek
policycoreutils-3.7-2.fc41f41-build-side-92231 zbyszek
postfix-3.9.0-5.fc41 f41-build-side-92231 zbyszek
ppp-2.5.0-12.fc41 f41-build-side-92231 zbyszek
procps-ng-4.0.4-3.fc41f41-build-side-92231 zbyszek
psmisc-23.7-2.fc41f41-build-side-92231 zbyszek
rpcbind-1.2.6-5.rc3.fc41 f41-build-side-92231 zbyszek
rpm-4.19.92-3.fc41f41-build-side-92231 zbyszek
sanlock-3.9.3-3.fc41 f41-build-side-92231 zbyszek
sendmail-8.18.1-2.fc41f41-build-side-92231 zbyszek
shadow-utils-4.15.1-7.fc41f41-build-side-92231 zbyszek
smartmontools-7.4-5.fc41 f41-build-side-92231 zbyszek
systemd-256.2-2.fc41 f41-build-side-92231 zbyszek
tcpdump-4.99.4-8.fc41 f41-build-side-92231 zbyszek
util-linux-2.40.2-3.fc41 f41-build-side-92231 zbyszek
v4l-utils-1.26.1-5.fc41 f41-build-side-92231 zbyszek
xfsprogs-6.8.0-3.fc41 f41-build-side-92231 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/proje
Re: [Fedora Update] [CRITPATH] [comment] bind-9.18.26-2.fc41, chkconfig-1.28-2.fc41, and 55 more
adamwill wrote: > 2. [KDE live image build > fails](https://openqa.fedoraproject.org/tests/2723244#step/_live_build/49) > because of a file conflict - /usr/bin/fsck.hfs conflicts between hfsutils and > hfsplus-tools Hi maintainers of hfsutils and hfsplus-tools, This is about the bin-sbin merge (https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin). As noticed by AdamW, right now we have /usr/bin/fsck.hfs from hfsutils, and /usr/sbin/fsck.hfs from hfsplus-tools. This worked so some extent before, but when /usr/sbin and /usr/bin become one, the packages are not coinstallable. My proposal: drop /usr/bin/fsck.hfs symlink from hfsutils. It have no opion on which is better, but /usr/sbin is in the default $PATH for root earlier than /usr/bin, so if both are installed, /usr/sbin/fsck.hfs would normally be used. Another option would be to make the packages Conflict, but that wouldn't solve the KDE live image build fail, because it wants to install both packages. https://src.fedoraproject.org/rpms/hfsutils/pull-request/2 implements my proposal. The problem wasn't noticed before, but now it's blocking the packages rebuilt for the merge from being pushed to rawhide, so we'll need to figure out something quickly. If I don't hear otherwise, I'll merge my PR to unblock things in rawhide. Sorry about the urgency, but this wasn't noticed before and _some_ solution is needed quickly. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Home made tutorial to help beginners into packaging
On Sun, Jul 07, 2024 at 12:09:21PM +0200, Sébastien Le Roux wrote: > https://github.com/Slookeur/OPEN Hi Sébastien, This is a very impressive introduction to Autotools and Cmake (and other things). In teaching there's the technique of listing things that the reader will "know" and be able to do after following the tutorial. In the introduction you say that this tutorial is for people who want to make their programs available as open source, and then your describe how to add Autotools configuration. I find this iffy — IMO Autotools should not be used for anything new. It just doesn't make sense to even hint to anyone new to the subject of packaging of trying that. And by describing it first and in detail you implicitly give the message that it's a useful technique. Later you talk about CMake. I like that you describe a workflow that uses pkgconfig; the declarative style of CMakeLists.txt in your example is nice and modern. FWIW, I think that a Meson config would be even better. It would be great to have a the same project configured with CMake and Meson to be able to compare the two approaches. Zbyszek PS. From the section about git: > git commit -m "Program [V-$version] `date`" This is not useful. A git commit contains a date. -- ___ 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: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Mon, Jul 08, 2024 at 02:28:09PM -0500, Michael Catanzaro wrote: > On Mon, Jul 8 2024 at 01:51:07 PM -04:00:00, Przemek Klosowski via devel > wrote: > > At the same time, I ask the proponents to confirm that there will be no > > way to re-aggregate the data by any means (timestamps, Fedora account > > cookies, load factor on the server, etc). > > Good question! I *think* timestamps are no longer a problem. It does store > precise timestamps alongside a hash of the full submission, but it doesn't > actually store the full submission itself anymore, and the first few tables > of metrics I've checked do not any contain timestamps. But we do need to > audit and make sure that if timestamps are stored anywhere else, we must > reduce their granularity to prevent them from being matched up with > timestamps from other records. It's probably more than sufficient to know > that a metric was submitted on a given day, for example; there's just no > need to know that a record was submitted at any given second. Anyway, that's > an easy problem. > > Then there are two other problems I can think of: > > 1. You might be able to guess that records are from the same user based on > the order of the rows in the database. I'm not sure what will be the final > solution for this. Randomizing the position of new rows would surely avoid > this problem, but could possibly have performance impact at scale? I'm not > sure. We'll need to do something about this to keep our promise that it > should not be possible to correlate records. Does the table store counts or separate entries? I would guess that if it just stores disaggregated values, then the values repeat often, and it's natural to store the count in the table. And then the order doesn't matter, because it'll be different in different tables. > 2. Another problem is that malformed records are kept in their entirety so > the problem can be investigated. A human looking at a malformed record would > see the aggregated data for a particular user. This should theoretically > only happen in the event of a bug, but bugs happen. ;) I could also > hypothetically imagine a system's hardware being so broken as to corrupt > metrics, yet still somehow manage to boot, for instance. What to do about > this is an open question. The safest option would be to discard rather than > store malformed records, at the cost of being unable to investigate and fix > this class of bugs. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
On Wed, Jul 03, 2024 at 06:50:02PM +0800, Jens-Ulrik Petersen wrote: > > > > > Country where device is physically located (this will need discussion) > > > I think I would be more interested in locale info than country. Yeah, I think locale info would be quite relevant. We have translations into hundreds of locales, but some of them are most likely almost unused. OTOH, I'm sure there are some locales with a bunch of users who are not visible on our English-dominated forums. It'd be good to direct some of the i18n efforts into fonts and translations in such locales. With some statistics we wouldn't need to guess. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge planned for next week
On Wed, Jul 03, 2024 at 12:09:39PM +0200, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > What will happen next week: > > > > 0. I'll create a side tag for the builds described below. > > Where are we in this process? Has the side tag been created? Do builds > for testing already exist? Hi, I haven't started this yet. I was planning to start over the weekend, but there were some koji infra troubles and other stuff and it didn't seem like the best moment. And also I'm taking Thursday and Friday off this week. So at this point I'm aiming for Monday 8th. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Fri, Jun 21, 2024 at 12:27:25PM -0400, Stephen Smoogen wrote:
> On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
> > So what is the reason to not treat x86_64_v2 as different arch then
> > x86_64_v{1,3}. Why we keep having this discussion instead of fire one
> > more build? Users would need to choose v1 / v2 / v3 ISO but what else?
>
> I can think of three problems which would need to be dealt with
>
> 1. Resource limitations in infrastructure hardware. You are going to
> add to the amount of builds on 1 set of hardware which is already
> doing x86_64 and i686. You are going to add to the storage issues that
> Fedora Infrastructure has to juggle on the maximum 100TB koji
> partition (with 90TB causing some amount of degradation) due to extra
> packages and composes.
> 2. Resource limitations in infrastructure staff. Fedora Infra is doing
> more with less and each additional architecture and focus increases
> that load.
> 3. Resource limitations on packagers. Packagers will need to add yet
> another bug set to cover and determine "is it only on VX" or not.
Another reason: is it actually useful at all?
Benchmarking so far hasn't been mention in this thread. But it was
discussed fairly extensively in previous interations on fedora-devel,
and the results were … not impressive.
The first consideration is that many packages already employ multiple
versions of functions and select the optimal version _at runtime_. In
that case, there is no "baseline architecture", the program works on
all µarchitectures, just faster or slower. This includes various BLAS
libraries, but also very importantly glibc itself with IFUNCS, some
compression libraries, etc. This means that for many programs the
heavy number crunching is already optimized, and raising the
µarchitecture level will have negligible effect on performance.
The second consideration is that many packages are not CPU-bound at
all, or don't perform the kind of processing where AVX and other
instructions make a difference.
So overall, there _might_ be some programs which would benefit from
higher µarchitecture requirements. Before starting a huge effort to
recompile the distro, it'd be prudent to do some local compilations
and benchmarking.
But OK, let's jump forward and we identified a subset of Fedora that'd
benefit. For those programs, a runtime approach based on IFUNCS or
equivalent is the most powerful. Only the hot paths need to be
targeted, delivering the same benefits as raising the baseline for the
whole program, while being transparent to the user. Also, this
approach can be more flexible, because it's OK to have many different
variants, rather than just targeting four µarchitecture levels. It
also requires much less resources, because we don't deliver multiple
versions of the package, but instead a few versions of the hot
functions, all in the same binary.
Only for programs where there is potential benefit, but we cannot do
IFUNCS, compiling with a higher baseline is a useful approach.
Overall, I think that we _should_ have more software optimized
for newer CPUs, but the solutions should be targeted at the right
packages and the right parts of the code. Just compiling everything
multiple times is IMO a waste of resources.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Strange error building on Rawhide
On Thu, Jun 27, 2024 at 08:27:00AM +0300, Panu Matilainen wrote: > On 6/26/24 20:03, Stephen Smoogen wrote: > > On Wed, 26 Jun 2024 at 10:32, Ron Olson wrote: > > > > > > Hey all- > > > > > > I’m trying to build Swift 6 on Rawhide and it looks like it gets to the > > > very end, to the %install section, then errors out with: > > > > > > + /usr/bin/add-determinism --brp -j4 > > > /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT > > > Error: Path "/home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT" > > > is outside of $RPM_BUILD_ROOT > > > error: Bad exit status from /var/tmp/rpm-tmp.EbjPHr (%install) > > > > > > Never, ever seen that particular message. I’m assuming the RPM build > > > tools on Rawhide are newer and perhaps there’s something I should be > > > adding to my spec file that I’m not aware of, as often is the case. :\ > > > > > > > Does it happen to any spec rebuild or just this one? And if this one > > what is the spec file? > > The /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT is > > outside of the buildroot as that should be > > /home/rolson/rpmbuild/BUILDROOT/ so I could see a bad definition > > somewhere trying to set up a copy to the wrong destination > > /home/rolson/rpmbuild/BUILD/swift-lang-6.0-build/BUILDROOT is the new-style > buildroot path in rpm >= 4.20 and so is actually expected in rawhide. It'd > only be outside if this was somehow mixed with an older rpm and I don't see > how that could happen. add-determinism has a check that when called via the rpm macros, it requires that $RPM_BUILD_ROOT is defined, not empty, and all the path arguments are below it. I thought it prudent to add such a check in case I mess something up in the definitions ;) I also remember considering whether to print out the value of $RPM_BUILD_ROOT in that error message and thinking "oh, this should never trigger, no need". I added the printing of RPM_BUILD_ROOT now [1], but I can't push it to rawhide because dist-git is broken [2]. In the meantime, can you post the full build log somewhere? (As a work-around, you can do '%undefine __brp_add_determinism' in the spec file or '--undefine __brp_add_determinism' on the commnand line to skip that step.) [1] https://github.com/keszybz/add-determinism/commit/36401dbb22bf1034b2791bd7d56172b0a6ee4db7 [2] https://pagure.io/releng/issue/12181 Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024 at 11:22:15AM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 26, 2024 at 11:47:55AM +0200, Miro Hrončok wrote: > > On 26. 06. 24 5:59, Richard Fontana wrote: > > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: > > > > > > > > On 25. 06. 24 22:50, Miroslav Suchý wrote: > > > > > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > > > > > > > > > > > Could you make the comment something like this? > > > > > > > > > > > ># Automatically converted from old format: GPLv2 > > > > > ># TODO check if there are other licenses to be listed > > > > > >License: GPL-2.0-only > > > > > > > > > > We (the Change owners) discussed this on a meeting today. And we > > > > > agreed on output: > > > > > > > > > > # Automatically converted from old format: GPLv2 > > > > > # TODO convert to correct SPDX identifier > > > > > # See > > > > > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > > > > > License: LicenseRef-Callaway-GPLv2 > > > > > > > > > > This is valid SPDX identifier. But not on the list of Fedora's allowed > > > > > licenses, so any QA tool will remind you to check the license. > > > > > > > > > > What do you think? > > > > > > > > I don't understand what is the benefit of doing this at all. Sorry. > > > > > > The benefit I see is that it immediately causes all license tags to > > > conform to the SPDX license expression standard, while also making it > > > very clear what parts of those license expressions are actually legacy > > > elements that have to be examined and replaced. (This assumes we > > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > > > What is the benefit of that outcome? > > > > I understand the benefit of SPDX in general. > > > > I don't understand the benefit of converting everything to custom LicenseRef > > identifiers. > > If you have tools which process SPDX expressions, with a full conversion > of outstanding RPMs to LicenseRef, you would now be able to use these > tools on Fedora specfiles (more) reliably. Another advantage is that it makes it (painfully) obvious when the legacy license tag is used. Instead of a free-style comment in the spec file or having to dig through %changelog to see if it mentions SPDX, the information that the license needs reviewing/updating is available in machine-readable form from the License tag. You can even use repoquery to list all such cases. > Fedora could (should) also apply CI tests that enforce a valid SPDX > expression, as there are almost certainly some accidental errors that > have crept in (I know I've made some). Yeah, I think we'll want to add a linter for this once the conversion is mostly complete. We can't really do that now. > These are small, but still tangible benefits, over having the ill-defined > mixture of SPDX and Callaway expressions live on for more years. > > Fully replacing the LicenseRef-Callaway terms within the expressions > would still remain highly desirable, ongoing work. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2024-06-25)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-25/fesco.2024-06-25-17.01.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-25/fesco.2024-06-25-17.01.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-25/fesco.2024-06-25-17.01.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-25/fesco.2024-06-25-17.01.html Meeting summary --- * TOPIC: Init Process (@zbyszek:fedora.im, 17:01:33) * TOPIC: #3229 Change: Make OpenSSL distrust SHA-1 signatures by default (@zbyszek:fedora.im, 17:06:11) * INFO: https://mailarchive.ietf.org/arch/msg/dnsop/HFg5PHXmCJ7Psz2jWmjyVRJmEWI/ (@zbyszek:fedora.im, 17:06:32) * AGREED: APPROVED: Accept the Change and disallow SHA-1 by default. Mitigations exist for individual applications to re-enable it if absolutely necessary (+7, 0, -1) (@zbyszek:fedora.im, 17:18:49) * TOPIC: Next week's chair (@zbyszek:fedora.im, 17:19:37) * INFO: The next meeting will be in two weeks. (@zbyszek:fedora.im, 17:21:12) * ACTION: Josh Stone will chair the meeting in two weeks (@zbyszek:fedora.im, 17:21:59) * TOPIC: Open Floor (@zbyszek:fedora.im, 17:22:06) Meeting ended at 2024-06-25 17:25:06 Action items * Josh Stone will chair the meeting in two weeks People Present (lines said) --- * @zbyszek:fedora.im (34) * @zodbot:fedora.im (19) * @simo:fedora.im (15) * @salimma:fedora.im (13) * @sgallagh:fedora.im (10) * @nirik:matrix.scrye.com (10) * @dbelyavs:fedora.im (7) * @decathorpe:fedora.im (6) * @jistone:fedora.im (6) * @dcantrell:fedora.im (3) * @meetbot:fedora.im (3) * @hkario:fedora.im (2) * @humaton:fedora.im (1) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Schedule for Tuesday's FESCo Meeting (2024-06-25)
Please note that the MEETING HAS BEEN MOVED 22 h later. Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-06-25 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3224 Change: Golang 1.23 https://pagure.io/fesco/issue/3224 APPROVED (+7, 0, 0) #3222 Change: Make Tuned the Default Power Profile Management Daemon https://pagure.io/fesco/issue/3222 APPROVED (+7, 0, -1) #3221 Change: Removing network-scripts package https://pagure.io/fesco/issue/3221 APPROVED (+6, 0, 0) #3220 Change: LLVM 19 https://pagure.io/fesco/issue/3220 APPROVED (+8, 0, 0) #3219 Change: Anaconda as native Wayland application https://pagure.io/fesco/issue/3219 APPROVED (+7, 0, 0) = Followups = = New business = #3229 Change: Make OpenSSL distrust SHA-1 signatures by default https://pagure.io/fesco/issue/3229 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: bin-sbin merge planned for next week
On Wed, Jun 19, 2024 at 10:34:26AM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi folks, > > it's this time of the year, we should do some major filesystem surgery! > > The preparations for > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin have been > put in place and I want to do the rebuild of filesystem.rpm rpm.rpm, > and other packages that will effectuate the merge. > > What has happened so far: > > 1. The selinux policy has been updated to treat make /usr/sbin >equivalent to /usr/bin. This is necessary to avoid selinux becoming >very unhappy when paths are changed [0,1]. > > 2. I prepped a pull request for filesystem.rpm to do the merge [2]. >This is described in detail below. The patches have been tentatively >acked, so I want to merge & build them, after another round of >testing. Doing this will be the real beginning of the merge. > > 3. [3] is the counterpart for rpm; it makes rpm report that >%_sbindir==%_bindir. > > 4. Over the last two months I submitted a bunch of dist-git pull >requests with titles like "Fix build when %_bindir==%_sbindir" >[e.g. 4] and "Add compat sbin Provides" [e.g. 5]. Both types are >written in a way that it's safe to merge them at any time. The >maintainers of those packages got notifications and a bunch got >merged. > > 5. As a remnant of the usr-merge transition, we had a packaging rule >that packages MUST use pre-usr-merge paths. It turns out that >almost no packages got this right. The rule was removed in [6]. > > 6. The packaging guidelines have been updated for the sbin-merge [7]. > > Big thanks to everyone who responded to the patches, made reviews and > merges! > > What will happen next week: > > 0. I'll create a side tag for the builds described below. > > 1. When filesystem.rpm with the patch [2] is built, new installations >with that package will have /usr/sbin as a symlink. This includes >buildroots. The patch for rpm [3] will we merged and built right >afterwards, so that the declaration by rpm macros matches reality >on disk. > > 2. Some packages (of those that have files in /usr/sbin) will start to >FTBFS in a buildroot with merged-sbin. For example, when they >cannot move %_sbindir/foo to %_bindir/foo or the other way. Patches >like "Fix build when %_bindir==%_sbindir" [4] fix those cases. It's >not necessary to merge them immediately, but only if the package >actually needs to be rebuilt. > > 3. Some packages will start to FTI in an merged-sbin installation. >The error looks like this: > Transaction failed: Rpm transaction failed. >- file /usr/sbin/sestatus conflicts between attempted installs of > policycoreutils-3.6-5.fc41.x86_64 and > policycoreutils-3.6-5.fc41.x86_64 >- file /usr/sbin/named-checkzone conflicts between attempted installs > of > bind-utils-32:9.18.26-1.fc41.x86_64 and > bind-utils-32:9.18.26-1.fc41.x86_64 >(I guess rpm/dnf could do a slightly better error message here…) > >Those packages need to rebuilt ASAP. I'll rebuild them in the side >tag too, with a commit title "Rebuilt for the bin-sbin merge". In >many cases, the patches to fix FTBFS will need to be applied >first. In those cases, I'll merge the "Fix build" pull requests. > > 4. We have packages which use filepath Requires on paths in %_sbindir. >Such packages will FTI when the _providing_ package is rebuilt with >the new value of %_sbindir. To keep those packages working, I made >a list of all such filepath dependencies in Fedora and prepared >patches for the provider packages to add a virtual Provides for the >old name, e.g. [5]. This means that the provider package has >Provides:/usr/sbin/foo before the merge and >Provides:/usr/bin/foo,/usr/sbin/foo when rebuilt after the merge. > >I'll rebuild all packages that need to add the virtual Provides in >the side tag too. > >(In case anyone is wondering, why like this, the answer is that >there are few different ways the transition could be handled, but I >think this one the least painful. Dependent packages will remain >installable in pre-merge and post-merge systems. This means we >don't have a flag day when everything needs to be rebuilt. Also, >there are many more "consumer" than provider packages so the total >number of required changes is relatively small. Also, if we learn >about third-party packages or other uses on the filepath provides, >we can add more Provides to make the transition ea
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Thu, Jun 20, 2024 at 10:24:44AM -0600, Jilayne Lovejoy wrote: > On 6/19/24 6:07 PM, Richard Fontana wrote: > > Relatedly, I have had some misgivings and mixed feelings about these > > mass conversions, because I have worried that the resulting situation > > will make people complacent regarding the correctness of the license > > tag. That is, they may assume that a converted license tag has some > > sort of implied stamp of approval. However, I've mostly gotten > > comfortable with the piecemeal > > mass conversions over time. I accept that we'll (still) have many > > inaccurate license tags, under our current documented standards, and > > we'll just have to gradually try to improve them. > +1 I also had a lot of misgivings. In addition to Richard's comments, I > think I've come to thinking that complacency is an issue no matter what and > any amount of auto-conversion is not likely to make that worse or better. > > > > I'm not sure it's really better to stick with Callaway license tags > > for some longer period of time in the hope that the *first* attempt to > > convert a package license tag to SPDX expressions will be relatively > > accurate. I do worry that if everyone is complacent about this, Fedora > > could become yet another project using SPDX expressions > > inappropriately. > really don't want that! > > In any case, Miro, I appreciate your observations and concerns. I think in > the long run, putting in place more specific advice and better tooling for > license review that is maybe even part of the packaging process would be > better. Even for the packages that were diligently updated to SPDX ids won't > stay up-to-date over time as packages change their licenses, etc. +1 for continuing the (imperfect) convertion to SPDX. For me the argument that the non-simplified licenses have to be periodically adjusted anyway to not become outdated is fairly convicing. I think we're better off having a possibly-incomplete SPDX format license than a possibly-incomplete-in-the-same-way Spot format license. We'll be better off having the whole distro converted to a consistent format, even if some of the tags still need to expanded later. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge planned for next week
On Thu, Jun 20, 2024 at 02:19:57PM +0200, Miro Hrončok wrote:
> On 19. 06. 24 12:34, Zbigniew Jędrzejewski-Szmek wrote:
> > 4. We have packages which use filepath Requires on paths in %_sbindir.
> > Such packages will FTI when the_providing_ package is rebuilt with
> > the new value of %_sbindir. To keep those packages working, I made
> > a list of all such filepath dependencies in Fedora and prepared
> > patches for the provider packages to add a virtual Provides for the
> > old name, e.g. [5]. This means that the provider package has
> > Provides:/usr/sbin/foo before the merge and
> > Provides:/usr/bin/foo,/usr/sbin/foo when rebuilt after the merge.
> >
> > I'll rebuild all packages that need to add the virtual Provides in
> > the side tag too.
>
> So, recently I saw this:
>
> Requires(post): %{_sbindir}/alternatives
> Requires(postun): %{_sbindir}/alternatives
>
> And I checked the alternatives package (chkconfig component). It does not
> manually provide /usr/sbin/alternatives. There is no open pull request.
> Your email made it sound like this is all ready, but I don't see it.
A general clarification: for packages that were or will be "fixed" to have
the new Provides, the Provides are conditionalized on %_sbindir==%_bindir,
so they are NOT visible until rebuilt in a build root with the merge.
So at this point in time there should be no such provides in any
(binary) packages.
In the particular case of alternatives.rpm, the pull request was
https://src.fedoraproject.org/rpms/chkconfig/pull-request/13,
which then became https://github.com/fedora-sysv/chkconfig/pull/131.
> So, what is the list of the packages and the prepared patches?
From the snipped part:
> I'll prepare an updated list and send it out with a CC to
> maintainers sometime this week.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
On Mon, Jun 17, 2024 at 12:44:53PM +0100, Aoife Moloney wrote: > What we're doing this time is using mokutil to create a key for the > user to self-sign the drivers. When installing the drivers, the user > is asked to provide a password for the key. On the next reboot the > user is presented with the mokutil interface to enroll the key. It's not clear to me which steps are done once only. I.e. is the user supposed to self-sign each updated version of the driver? Is the enrolled MOK key reused for future versions of the driver too? 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
bin-sbin merge planned for next week
Hi folks, it's this time of the year, we should do some major filesystem surgery! The preparations for https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin have been put in place and I want to do the rebuild of filesystem.rpm rpm.rpm, and other packages that will effectuate the merge. What has happened so far: 1. The selinux policy has been updated to treat make /usr/sbin equivalent to /usr/bin. This is necessary to avoid selinux becoming very unhappy when paths are changed [0,1]. 2. I prepped a pull request for filesystem.rpm to do the merge [2]. This is described in detail below. The patches have been tentatively acked, so I want to merge & build them, after another round of testing. Doing this will be the real beginning of the merge. 3. [3] is the counterpart for rpm; it makes rpm report that %_sbindir==%_bindir. 4. Over the last two months I submitted a bunch of dist-git pull requests with titles like "Fix build when %_bindir==%_sbindir" [e.g. 4] and "Add compat sbin Provides" [e.g. 5]. Both types are written in a way that it's safe to merge them at any time. The maintainers of those packages got notifications and a bunch got merged. 5. As a remnant of the usr-merge transition, we had a packaging rule that packages MUST use pre-usr-merge paths. It turns out that almost no packages got this right. The rule was removed in [6]. 6. The packaging guidelines have been updated for the sbin-merge [7]. Big thanks to everyone who responded to the patches, made reviews and merges! What will happen next week: 0. I'll create a side tag for the builds described below. 1. When filesystem.rpm with the patch [2] is built, new installations with that package will have /usr/sbin as a symlink. This includes buildroots. The patch for rpm [3] will we merged and built right afterwards, so that the declaration by rpm macros matches reality on disk. 2. Some packages (of those that have files in /usr/sbin) will start to FTBFS in a buildroot with merged-sbin. For example, when they cannot move %_sbindir/foo to %_bindir/foo or the other way. Patches like "Fix build when %_bindir==%_sbindir" [4] fix those cases. It's not necessary to merge them immediately, but only if the package actually needs to be rebuilt. 3. Some packages will start to FTI in an merged-sbin installation. The error looks like this: Transaction failed: Rpm transaction failed. - file /usr/sbin/sestatus conflicts between attempted installs of policycoreutils-3.6-5.fc41.x86_64 and policycoreutils-3.6-5.fc41.x86_64 - file /usr/sbin/named-checkzone conflicts between attempted installs of bind-utils-32:9.18.26-1.fc41.x86_64 and bind-utils-32:9.18.26-1.fc41.x86_64 (I guess rpm/dnf could do a slightly better error message here…) Those packages need to rebuilt ASAP. I'll rebuild them in the side tag too, with a commit title "Rebuilt for the bin-sbin merge". In many cases, the patches to fix FTBFS will need to be applied first. In those cases, I'll merge the "Fix build" pull requests. 4. We have packages which use filepath Requires on paths in %_sbindir. Such packages will FTI when the _providing_ package is rebuilt with the new value of %_sbindir. To keep those packages working, I made a list of all such filepath dependencies in Fedora and prepared patches for the provider packages to add a virtual Provides for the old name, e.g. [5]. This means that the provider package has Provides:/usr/sbin/foo before the merge and Provides:/usr/bin/foo,/usr/sbin/foo when rebuilt after the merge. I'll rebuild all packages that need to add the virtual Provides in the side tag too. (In case anyone is wondering, why like this, the answer is that there are few different ways the transition could be handled, but I think this one the least painful. Dependent packages will remain installable in pre-merge and post-merge systems. This means we don't have a flag day when everything needs to be rebuilt. Also, there are many more "consumer" than provider packages so the total number of required changes is relatively small. Also, if we learn about third-party packages or other uses on the filepath provides, we can add more Provides to make the transition easier.) Those Provides can be removed after the transition is fully complete. I think we shouldn't hurry with that, they can stay around for a few years. We still have virtual Provides for the usr-merge in many packages after all. 5. After the side tag is merged, the merge is on for users. As mentioned above, any new installations will have /bin, /sbin, and /usr/sbin symlinks to /usr/sbin. This means that paths /bin/foo, /sbin/foo, /usr/sbin/foo, and /bin/foo all point to the same file. This is the target state. On existing installations, we'll have a bunch of packages with files and symlinks in directory /usr/sbin.
Re: Schedule for Monday's FESCo Meeting (2024-06-17)
On Tue, Jun 18, 2024 at 12:30:23PM -0400, Josh Boyer wrote: > On Tue, Jun 18, 2024 at 8:25 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Jun 18, 2024 at 03:20:07PM +0300, Otto Liljalaakso wrote: > > > Stephen Gallagher kirjoitti 17.6.2024 klo 23.07: > > > > = > > > > # #meeting:fedoraproject.org: fesco > > > > = > > > > > > > > Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05 > > > > > > > > Meeting summary > > > > --- > > > > * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31) > > > > * TOPIC: #3222 Change: Make Tuned the Default Power Profile > > > > Management Daemon (@sgallagh:fedora.im, 19:12:35) > > > > * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59) > > > > * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, > > > > 19:53:23) > > > > * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30) > > > > * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away > > > > from ODCS (@sgallagh:fedora.im, 20:04:29) > > > > > > > > Meeting ended at 2024-06-17 20:06:17 > > > > > > > > On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher > > > > wrote: > > > > > = New business = > > > > > > > > > > #3222 Change: Make Tuned the Default Power Profile Management Daemon > > > > > https://pagure.io/fesco/issue/3222 > > > > > > This creates the impression that you did not decide anything regarding > > > #3222. Checking from logs, I see that that is not the case: > > > > > > > #agreed FESCo approves the Change to use tuned as the default > > > power-management tool for desktop installs. P-P-D remains in the > > > distribution as an alternative that can be manually installed. (+7, 0, -1) > > > > > > Is the meetbot somehow broken, or was that just wrong syntax or something? > > We forgot to say '!agreed …'. > > I would love for someone to tweak zodbot to use generative AI to > actually make it useful. It served us well for a very long time, but > the published summaries aren't useful for those just wanting to follow > along and the need to remember what was agreed on with implicit > commands is cumbersome. It wouldn't be that hard to just pipe the > logs through an LLM to produce a much better summary and auto-generate > the agreements and decisions. A human would need to review before > sending it out, but I think end consumers would benefit much more. I think this is one of the rare occasions where we forgot to invoke the right commands. We almost always remember to do that. Sometimes it's useful to edit the summary a bit, I usually do that before sending it out. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-06-17)
On Tue, Jun 18, 2024 at 03:20:07PM +0300, Otto Liljalaakso wrote: > Stephen Gallagher kirjoitti 17.6.2024 klo 23.07: > > = > > # #meeting:fedoraproject.org: fesco > > = > > > > Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05 > > > > Meeting summary > > --- > > * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31) > > * TOPIC: #3222 Change: Make Tuned the Default Power Profile > > Management Daemon (@sgallagh:fedora.im, 19:12:35) > > * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59) > > * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, > > 19:53:23) > > * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30) > > * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away > > from ODCS (@sgallagh:fedora.im, 20:04:29) > > > > Meeting ended at 2024-06-17 20:06:17 > > > > On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher > > wrote: > > > = New business = > > > > > > #3222 Change: Make Tuned the Default Power Profile Management Daemon > > > https://pagure.io/fesco/issue/3222 > > This creates the impression that you did not decide anything regarding > #3222. Checking from logs, I see that that is not the case: > > > #agreed FESCo approves the Change to use tuned as the default > power-management tool for desktop installs. P-P-D remains in the > distribution as an alternative that can be manually installed. (+7, 0, -1) > > Is the meetbot somehow broken, or was that just wrong syntax or something? We forgot to say '!agreed …'. 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
2FA policy for provenpackagers is now active
Proven packagers, we changed [2,3] the FESCo policy document [1] for provenpackagers to say: "Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts." This is not enforced or checked, but please take steps to conform to the policy if you haven't yet. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186 Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: GIMP Version 3 (self-contained)
On Sun, Jun 16, 2024 at 05:24:10PM +0100, Aoife Moloney wrote: > This new version involves substantial changes to the technologies > used, which in turn means that third party plugins have to be ported > to be compatible. Therefore, this change will add the new version as a > new package gimp3 which can be installed side-by-side > with the existing version 2.x package, so people can continue working > on existing projects with the old gimp version and its plugins. The naming of the srpm / dist-git repos is fine. But please call the binary rpm with the new version 'gimp' and the binary rpm with the old version 'gimp2' in F41+. We want users to be upgraded to gimp-3 when they update the system. It's fine if they then install gimp-2 for compat reasons. But the upgrade should be automatic. Also, the new version should carry normal appinfo metadata so it shows up in the graphical search, etc. > In order to make upgrades seamless for users (and avoid having to go > through an exception process for a “new” gimp2 package > needing Python 2.x), the existing package will remain named > gimp and it plus gimp3 will obsolete the > version 2.x packages from Fedora Linux <= 40 in version 41. This statement is dubious. As you wrote yourself in the earlier thread, there is an automatic exception to the review process for compat packages. The guidelines indeed don't say anything explicitly about compat packages depending on deprecated packages, but it seems reasonable to assume this does not introduce the requirement of a FPC review. (Consider: you can certainly keep gimp==2 and add gimp3==3 without review. But if instead gimp2==2 is added and gimp is updated to 3, no new dependency on the deprecated package is introduced. So nothing changes for the distro, and this should be treated the same.) The guidelines [1] say this: > other packages in Fedora MUST NOT add a dependency on a deprecated > package (that includes Requires, BuildRequires, Recommends, > Suggests, etc.). This applies both for updates of existing packages > and new packages added to Fedora. Those submitting new packages, > along with package reviewers, MUST check to see if any dependencies > of the package they are submitting or reviewing have been > deprecated. (It is, however, acceptable for a deprecated package to > be renamed.) I'm not sure what this last sentence is trying to say. It is a non-sequitur to the earlier text, *unless* the intent was actually to say something different: "It is, however, acceptable for a package requiring a deprecated package to be renamed." ?? Either way, I think we should clarify the guidelines to allow this. Please drop this para from the Change page. People are already confused about requirements for compat packages, and I think this paragraph is not needed and will only cause additional confusion. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_consequences_of_a_package_being_deprecated > == Feedback == The gimp3 package in F40 has: /usr/bin/gimp-2.99 /usr/bin/gimp-console-2.99 /usr/bin/gimp-script-fu-interpreter-3.0 /usr/bin/gimp-test-clipboard-2.99 Please make this 'gimp3' and 'gimp3-console' (so that the users can use stable names. This is the style of naming of binaries that compat python versions use.) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Wed, May 15, 2024 at 10:27:33AM +0200, Vít Ondruch wrote: > > Dne 13. 05. 24 v 23:22 Nils Philippsen napsal(a): > > On Mon, 2024-05-13 at 14:58 +0200, Vít Ondruch wrote: > > > Why would you push Gimp 3 into Fedora <= 40? > > Why wouldn’t I? It’s technically feasible without really jumping > > through hoops, and I don’t want to force users to upgrade the OS – or > > wait for Fedora 41 to be at a level of stability acceptable to them – > > before they can use the new version. > > > I am not against Gimp 3 in F40 and older per se. But the issue is that it > drives you towards `gimp3` for compatibility reasons. IOW I think that it > would be perfectly fine to have Gimp 2 (gimp package) as default in F40 and > Gimp 3 (still gimp package) in F41+. Because while they might be > substantially different, the change happens with major Fedora version and > users should be prepared for such changes. > > IOW situation would be much easier if `gimp` package was Gimp 2 up until F40 > and Gimp 3 since F41. Optionally, it would also make sense to provide > `gimp2` package in F41 for backward compatibility. That is all true, but this approach is still compatible with the way that the repos and srpms are named. It's entirely fine to build gimp.srpm → gimp.rpm and gimp3.srpm → gimp3.rpm in F40, and gimp.srpm → gimp2.rpm and gimp3.srpm → gimp.rpm in F41+. This is similar to how python3.rpm is currently build from python3.12.srpm in F40 and python3.13.srpm in F41. 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
No FESCo meeting today
There is nothing on the agenda for the meeting today so the meeting is cancelled. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
In https://fedoraproject.org/wiki/SHA1SignaturesGuidance: > At the moment, we don't provide a public API to enable SHA-1 signature > support in OpenSSL programmatically. We ask you to respect the system > administrator's configuration choice on this. We're planning to work > with OpenSSL upstream to introduce a more suitable API in the future Any news on this? Being able to make this policy configurable at application level would make things _much_ easier. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 41 Python 3.13 rebuild in a side tag has now started
On Fri, Jun 07, 2024 at 08:48:03AM +0200, Karolina Surma wrote: > Hello, > > We have just started the Python 3.13 mass rebuild in the side tag for Fedora > 41 with Python 3.13.0b2. > > Please, follow the original instructions when planning to build your Python > packages. > We'll let you know when we'll plan to merge the side tag. > > If you'd like to build a package after we already rebuilt it, you should > > be able to build it in the side tag via: > > > > on branch rawhide: > > $ fedpkg build --target=f41-python I built rust-add-determinism-0.2.0-11.fc41 in the side tag. It drops the dependency on python3-libs and marshalparser and provides an internal reimplementation of marshalparser. Subsequent builds of python packages should have the pyc handler active. I sincerely hope this doesn't interrupt the rebuild in any way! Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
Hi,
I think all the issues wrt. sysusers in systemd and setup have been
resolved.
On Tue, May 14, 2024 at 11:34:51AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:
> > On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> > > > I outlined the migration process last year in
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> > > > but failed to follow-up, so I'm glad to see this getting revisited.
> > >
> > > I started looking into this, and I think we need to start at the
> > > bottom, i.e. in the setup package.
> > >
> > > It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
> > > and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
> > > but some of the groups listed in sysusers are not listed in the /etc
> > > files.
> > > IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
> > > automatically, and the file provided by setup will be ignored.
> > > (It's specified as %config(noreplace).)
I was confused here. setup generates its two sysusers files from the
passwd/groups file that it distributes, so they will always match.
We added the missing group defintions that systemd-udev relies on to
default groups file distributed by setup (in setup-2.15.0-3). The next
build of systemd (256~rc4-1) will drop its sysusers.d/basic.conf file.
Please carry on with the enablement of rpm sysusers handling ;)
Zbyszek
P.S. While at it, Martin Osvald and I implemented a move of the
content from the the "upstream" setup repo (https://pagure.io/setup/)
into the dist-git repo (https://src.fedoraproject.org/rpms/pagure).
The "upstream" was only used by a single "downstream", managed by the
same people, and the separation was just generating busywork.
setup >= 2.15 has all the content in dist-git.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RPM_* env variables vs macros
On Thu, Jun 06, 2024 at 09:53:48AM +0300, Panu Matilainen wrote:
> On 6/5/24 18:22, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Jun 04, 2024 at 09:31:47AM +0200, Vít Ondruch wrote:
> > >
> > > Dne 04. 06. 24 v 9:27 Vít Ondruch napsal(a):
> > > >
> > > > Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):
> > > > > On 6/3/24 17:18, Eike Rathke wrote:
> > > > > > Hi Panu,
> > > > > >
> > > > > > On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:
> > > > > >
> > > > > > > or better yet, ${RPM_BUILD_ROOT}.
> > > > > >
> > > > > > Why better?
> > > > >
> > > > > In general, the RPM_* environment variables available to build
> > > > > scriptlets are what should be used instead of macros. Because,
> > > > > macros are processed while parsing the spec, which is different from
> > > > > actually *building* it. For one, using the environment improves srpm
> > > > > reproducibility because the local gunk like number of CPUs, the
> > > > > concrete path of %buildroot etc are only visible the scriptlets
> > > > > where actually used.
> > > > >
> > > > > It's a subtle thing, took me 10+ years with rpm to grok the
> > > > > recommendation I'd seen long, long, long ago.
> > > > >
> > > >
> > > > I wish this nugget was captured somewhere on more prominent place.
> > > > Because what you say does not really correspond with what we have in
> > > > guidelines:
> > > >
> > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags
> > > >
> > > >
> > > > And I have not checked the RPM documentation
> > >
> > >
> > > There is this section:
> > >
> > > https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets
> > >
> > > also recommending RPM_ macros for scriptlets:
> >
> > I acknowledge what Panu wrote, but I think there are also countervailing
> > reasons
> > to prefer the macro:
> > - it is shorter and generally more consistent with the rest of the spec
> > file,
> >which will have many many macros and only occasionally a shell variable,
> >so the macro is more aesthetic.
> > - but the big thing is that the macro is safe wrt. typos, while the variable
> >not so much. It's just too easy to make a stupid typo in the variable
> > name
> >and do bad things™ in a local build.
> >
> >${RPM_BUILD_ROOT:?} would be a better way to spell the variable
> > reference,
> >but that's too long expect people to use it.
>
> Yeah the thing is those macros can and will never go away because everybody
> instinctively prefers them for consistency within the spec, shorter to type
> and all.
>
> >
> > So maybe we should have a macro that would expand to the env var:
> >%global BUILDROOT ${RPM_BUILD_ROOT:?}
> > and recommend that people use that instead?
>
> That'd be a third variant of the same thing, probably causing even more
> confusion, and specs using that would be incompatible with everything else.
> Let's not.
>
> Making the macros expand to the corresponding environment variables is a is
> a sound strategy though, and what we're doing with %_smp_mflags already:
>
> %_smp_mflags -j${RPM_BUILD_NCPUS}
>
> It can cause some breakage though so care needs to be taken. And just now,
> we've already rocked the boat more than is entirely healthy for a single
> release, so further experiments in this area will have to wait for some
> other time.
I don't think we could ever change %buildroot to be ${RPM_BUILD_ROOT:?},
because the variable may be used in context where shell variable expansion
is not supported… (E.g. a trivial "find '%{buildroot}' -name '*.a' -delete")
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RPM_* env variables vs macros
On Tue, Jun 04, 2024 at 09:31:47AM +0200, Vít Ondruch wrote:
>
> Dne 04. 06. 24 v 9:27 Vít Ondruch napsal(a):
> >
> > Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):
> > > On 6/3/24 17:18, Eike Rathke wrote:
> > > > Hi Panu,
> > > >
> > > > On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:
> > > >
> > > > > or better yet, ${RPM_BUILD_ROOT}.
> > > >
> > > > Why better?
> > >
> > > In general, the RPM_* environment variables available to build
> > > scriptlets are what should be used instead of macros. Because,
> > > macros are processed while parsing the spec, which is different from
> > > actually *building* it. For one, using the environment improves srpm
> > > reproducibility because the local gunk like number of CPUs, the
> > > concrete path of %buildroot etc are only visible the scriptlets
> > > where actually used.
> > >
> > > It's a subtle thing, took me 10+ years with rpm to grok the
> > > recommendation I'd seen long, long, long ago.
> > >
> >
> > I wish this nugget was captured somewhere on more prominent place.
> > Because what you say does not really correspond with what we have in
> > guidelines:
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags
> >
> >
> > And I have not checked the RPM documentation
>
>
> There is this section:
>
> https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets
>
> also recommending RPM_ macros for scriptlets:
I acknowledge what Panu wrote, but I think there are also countervailing reasons
to prefer the macro:
- it is shorter and generally more consistent with the rest of the spec file,
which will have many many macros and only occasionally a shell variable,
so the macro is more aesthetic.
- but the big thing is that the macro is safe wrt. typos, while the variable
not so much. It's just too easy to make a stupid typo in the variable name
and do bad things™ in a local build.
${RPM_BUILD_ROOT:?} would be a better way to spell the variable reference,
but that's too long expect people to use it.
So maybe we should have a macro that would expand to the env var:
%global BUILDROOT ${RPM_BUILD_ROOT:?}
and recommend that people use that instead?
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
Summary/Minutes from today's FESCo Meeting (2024-06-03)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-03/fesco.2024-06-03-19.01.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-03/fesco.2024-06-03-19.01.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-03/fesco.2024-06-03-19.01.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-03/fesco.2024-06-03-19.01.html Meeting summary --- * TOPIC: Init Process (@zbyszek:fedora.im, 19:02:23) * TOPIC: #3203 Change: Replace Redis with Valkey (@zbyszek:fedora.im, 19:07:14) * AGREED: approved (+8, 0, 0) (@zbyszek:fedora.im, 19:13:40) * TOPIC: Next week's chair (@zbyszek:fedora.im, 19:15:13) * ACTION: jednorozec will chair the next meeting (@zbyszek:fedora.im, 19:17:18) * ACTION: Josh Stone will chair the meeting after that (@zbyszek:fedora.im, 19:17:33) * TOPIC: Open Floor (@zbyszek:fedora.im, 19:17:48) * ACTION: Conan Kudo to do another whenisgood poll for meeting time (@zbyszek:fedora.im, 19:20:36) Meeting ended at 2024-06-03 19:20:48 Action items * jednorozec will chair the next meeting * Josh Stone will chair the meeting after that * Conan Kudo to do another whenisgood poll for meeting time -- ___ 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
Schedule for Monday's FESCo Meeting (2024-06-03)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-06-03 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3214 Request for Updates Policy Exception: maui-mauikit https://pagure.io/fesco/3214 APPROVED (+3, 0, 0) = Followups = #3203 Change: Replace Redis with Valkey https://pagure.io/fesco/issue/3203 = New business = = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: updates for "Change: Replace Redis with Valkey"
On Mon, Jun 03, 2024 at 04:09:51AM -0500, Jonathan Wright wrote: > I think it is time to get this discussed (and hopefully approved) in the > meeting. Valkey is the clear leader in my opinion, seems to be gaining the > most traction, and is well on the way to making improvements with their > first major release of 8.0 due later this year. Thanks. I'll send out the meeting agenda with this item in a sec. 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
updates for "Change: Replace Redis with Valkey"
Hi, For https://fedoraproject.org/wiki/Changes/Replace_Redis_With_Valkey in FESCo ticket https://pagure.io/fesco/issue/3203 we didn't make a decision and decided to wait for the situation to clarify. Has the status changed? Can we now say that Valkey is going to be the default replacement that most people will want to switch to? (If there's a clear answer, we'll want to finalize the rubberstamping of the Change Proposal. If not, we can let it sit some more.) Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On Wed, May 29, 2024 at 04:35:57PM +0200, Michal Domonkos wrote: > On Wed, May 29, 2024 at 12:38:31PM +0100, Richard W.M. Jones wrote: > > It failed right at the end with this mysterious error: > > > > GenericError: srpm mismatch for > > /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: > > (none) (expected ocaml-5.2.0-1.fc41.src.rpm) > > OK, this should be fixed now: > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-0cdd01deef Thanks! Do you plan to submit rebuilds for the failed packages are should packagers do that individually? 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
No FESCO meeting today
Hi, We have Memorial Day in the USA and no new topics on the agenda, so I'm cancelling today's meeting. See y'all next weeek! Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, May 22, 2024 at 09:06:07AM +0200, Vitaly Zaitsev via devel wrote: > On 17/04/2024 09:20, Zbigniew Jędrzejewski-Szmek wrote: > > In some ways, that'd be nice, because we wouldn't have to install > > additional tools in the buildroot. But OTOH, those tools are rather > > small and bash/find/etc probably need to be installed anyway. > > It doesn't seem to work properly without the marshalparser Python package > installed: > > + /usr/bin/add-determinism --brp -j48 > /builddir/build/BUILDROOT/nheko-0.11.3-11.fc41.x86_64 > Cannot initialize handler pyc: ModuleNotFoundError: No module named > 'marshalparser' Yes. The plan is to pull in the marshalparser module from python3-devel (conditionalized on python not being bootstrapped). The lack of the marshalparser module means that the program doesn't handle .pyc files, but otherwise works. > Also, is it possible to suppress these "Bye!" messages? Yeah, I left in the debugging message to have more clarity if things are working. They'll be gone in the next version. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
On Tue, May 21, 2024 at 01:19:24PM +0200, Miro Hrončok wrote: > On 21. 05. 24 12:29, Fabio Valentini wrote: > > On Mon, May 20, 2024 at 2:42 PM Michal Sekletar wrote: > > > > > > On Fri, May 17, 2024 at 6:14 PM Michal Sekletar > > > wrote: > > > > > > > > Hi everyone, > > > > > > > > We have had a plocate as a drop-in replacement for mlocate for quite a > > > > while now. My intention is to retire the mlocate package next week in > > > > order to prevent duplication and so that we can focus only on plocate > > > > going forward. > > > > > > > > > mlocate is now retired in Rawhide. > > > > > > https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide > > > > Thanks for the heads-up! > > Should the package also be added to fedora-obsolete-packages so that > > it is - if installed - removed on upgrade to Fedora 41? > > If a specific replacement exists (plocate), I think it should Obsolete it > explicitly. It already does. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Mon, May 20, 2024 at 10:55:58AM +0200, Petr Pisar wrote: > V Sat, May 18, 2024 at 08:20:53PM +0200, Sandro napsal(a): > > On 16-05-2024 13:14, Petr Pisar wrote: > > > A workaround could be rpm-build or mock to register rpm-build package in > > > /etc/dnf/protected.d configuration files. Packages listed there are > > > prevented > > > from removal no matter of --allow-erasing. > > > > A bit late to the party, but I was wondering if making `add-determinism` and > > `add-determinism-nopython` require `rpm-build` would also achieve > > `rpm-build` being protected from removal as a workaround. > > > > If either package requires it there should only be one way forward, if my > > understanding of the issue is correct. > > > That's also a possible way. Many times defining the reverse dependendency can > be justified as (add-determinism) being a plugin (of rpm-build). It also helps > cleaning useless plugins (add-determinism) when the framework (rpm-build) is > uinstalled. > > A drawback is creating dependency loop. Thank you for the suggestion. I think that with the current state things are good, so I don't plan to change things, unless we discover some breakage. FWIW, add-determinism is fully functional without rpm-build… I expect that most people who use it would have rpm-build installed, but I think it's better to not create dependency loops to keep things flexible. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Fri, May 17, 2024 at 12:19:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> > On Thu, 16 May 2024 10:52:29 +
> > Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > > This looks like you're putting the resolver between a rock and a
> > > > hard place. :thinking:
> > > > I don't think I've ever seen packages being *removed* when
> > > > installing BuildRequires on top of the minimal buildroot ...
> > > >
> > > > Would it be possible to adapt the packages so that add-determinism
> > > > and add-determinism-nopython are parallel-installable, and have the
> > > > macro fall back to the add-determinism-nopython executable if the
> > > > add-determinism executable is not available?
> > > > That way BuildRequires are additive and wouldn't force package
> > > > removal from the buildroot, and the rich dependency could be
> > > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > > without Suggests or else branch.
> > >
> > > Yeah, I think this is the most reasonable approach.
> > > I'll push a build that does this shortly.
> > >
> > > (I tried to test this locally with mock, with the additional packages
> > > in a local repo. When I install everything in one go, things work as
> > > expected. Why I try to check the original issue, and install packages
> > > piecemeal, mock downgrades packages to fall back to the koji version
> > > without dependencies, instead of installing the additional deps. In
> > > koji, it'll only have one version of the package available, so
> > > hopefully it'll pick addition instead of removals.)
> >
> > Not sure how this is supposed to work: add-determinism-nopython seems
> > to install %{_bindir}/add-determinism.nopython but the macro only seems
> > to look for %{_bindir}/add-determinism, resulting in this when only
> > add-determinism-nopython is installed:
> >
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)
>
> Oh, this is embarrasing. I added two patches but they didn't get
> applied because %setup not %autosetup. :(
> I'll push a fixed build in a moment. Sorry for breaking the builds.
perl-Finance-Quote-1.6200-1.fc41:
https://koji.fedoraproject.org/koji/taskinfo?taskID=117804013
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Fri, May 17, 2024 at 09:43:22AM +0100, Paul Howarth wrote:
> On Thu, 16 May 2024 10:52:29 +
> Zbigniew Jędrzejewski-Szmek wrote:
>
> > On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote:
> > > This looks like you're putting the resolver between a rock and a
> > > hard place. :thinking:
> > > I don't think I've ever seen packages being *removed* when
> > > installing BuildRequires on top of the minimal buildroot ...
> > >
> > > Would it be possible to adapt the packages so that add-determinism
> > > and add-determinism-nopython are parallel-installable, and have the
> > > macro fall back to the add-determinism-nopython executable if the
> > > add-determinism executable is not available?
> > > That way BuildRequires are additive and wouldn't force package
> > > removal from the buildroot, and the rich dependency could be
> > > simpler - i.e. `Requires: (add-determinism if python3-libs)`,
> > > without Suggests or else branch.
> >
> > Yeah, I think this is the most reasonable approach.
> > I'll push a build that does this shortly.
> >
> > (I tried to test this locally with mock, with the additional packages
> > in a local repo. When I install everything in one go, things work as
> > expected. Why I try to check the original issue, and install packages
> > piecemeal, mock downgrades packages to fall back to the koji version
> > without dependencies, instead of installing the additional deps. In
> > koji, it'll only have one version of the package available, so
> > hopefully it'll pick addition instead of removals.)
>
> Not sure how this is supposed to work: add-determinism-nopython seems
> to install %{_bindir}/add-determinism.nopython but the macro only seems
> to look for %{_bindir}/add-determinism, resulting in this when only
> add-determinism-nopython is installed:
>
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=117791675)
Oh, this is embarrasing. I added two patches but they didn't get
applied because %setup not %autosetup. :(
I'll push a fixed build in a moment. Sorry for breaking the builds.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote: > Proper solution is actually minimazing content of the minimal build root Most of the packages in the buildroot are libraries, pulled in via dependencies. @buildsys-build group is: Mandatory packages : bash # basic shell env : bzip2 # source extraction : coreutils # basic shell env : cpio # source extraction : diffutils # source extraction : fedora-release-common # rpm environment : findutils # basic shell env : gawk # basic shell env : glibc-minimal-langpack # we want this to avoid other langpacks : grep # basic shell env : gzip # source extraction : info : patch # source extraction : redhat-rpm-config # rpm environment : rpm-build # rpm environment : sed # basic shell env : shadow-utils : tar # source extraction : unzip # source extraction : util-linux# basic shell env : which # basic shell env. (command -v is more portable, but meh.) : xz# source extraction Out of this list, I see only three candidates for removal: 1. info. This is presumably present for /usr/sbin/install-info. It's a small package (360kB) and probably not worth the hassle to remove. On my system, 472 rpms provide info files, and if we remove it from the default set, we'd need to patch a huge amount of packages to add it back to make the builds work. 2. util-linux. This could be replaced by util-linux-core. This has a bunch of deps too, so it'd save some. util-linux has 95 binaries, and while _most_ of them have little use in a constrained build environment, probably a few are used somewhere. So this would need some investigation. 3. shadow-utils. It was added in: commit 79e1728c1b9e9e98d2e38b1286d90d596f233a56 Author: Jesse Keating Date: Tue Jan 15 15:31:27 2008 + Make sure shadow-utils makes it into a buildroot, or else mock will fail It's been a while, and I doubt we actually need it. Maybe we could drop that? Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 11:09:01AM +0200, Fabio Valentini wrote: > This looks like you're putting the resolver between a rock and a hard > place. :thinking: > I don't think I've ever seen packages being *removed* when installing > BuildRequires on top of the minimal buildroot ... > > Would it be possible to adapt the packages so that add-determinism and > add-determinism-nopython are parallel-installable, and have the macro > fall back to the add-determinism-nopython executable if the > add-determinism executable is not available? > That way BuildRequires are additive and wouldn't force package removal > from the buildroot, and the rich dependency could be simpler - i.e. > `Requires: (add-determinism if python3-libs)`, without Suggests or > else branch. Yeah, I think this is the most reasonable approach. I'll push a build that does this shortly. (I tried to test this locally with mock, with the additional packages in a local repo. When I install everything in one go, things work as expected. Why I try to check the original issue, and install packages piecemeal, mock downgrades packages to fall back to the koji version without dependencies, instead of installing the additional deps. In koji, it'll only have one version of the package available, so hopefully it'll pick addition instead of removals.) 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
rich deps result in packages being uninstalled from buildroot
Hi, I've been trying to get 'add-determinism' deployed in buildroots. This has been unsuccessful because of the following issue. The dependency chain is: redhat-rpm-config has Requires build-reproducibility-srpm-macros and build-reproducibility-srpm-macros has Requires:(add-determinism if python3-libs else add-determinism-nopython) Suggests:add-determinism-nopython (The idea is that we install 'add-determinism-nopython' which is self-contained, but if python3 is installed into the buildroot, we pull in the heavier version which has a dependency on python3-libs.) This works well enough when installing packages using dnf on a test system. But, in koji and mock builds, this results in rpm-build being unistalled (!). For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626 and root.log there: first rpm-build is installed along with a bunch of other packages expected in the buildroot, but then cargo-rpm-macros is requested (presumably via %generate_buildrequires), which depends on python3 and python3-libs. Dnf5 realizes that to satisfy all bounds, it can either: a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and remove add-determinism-nopython b) install cargo-rpm-macros, python3, python3-libs, and remove build-reproducibility-srpm-macros, rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other packages. and picks option b). Without rpm-build installed, the build immediately faceplants. (This can be reproduced by calling 'mock -i redhat-rpm-config' and later 'mock -i cargo-rpm-macros'. It reproduces with both dnf5 and dnf, so it's not a dnf5-related regresion.) How to make this not happen, i.e. how to prevent rpm-build and other packages that were explicitly pulled in via the @buildsys-build group from being uninstalled? I think this is a general problem, not just limited to the case described above. We now have hundreds of rich Requires deps declared in packages, and each one creates the possibility that dnf might opt to uninstall the package involved in the rich dep, rather than installing the deps, if there is no mechanism to prevent previously-explicitly-requested packges from being removed. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:
> On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> > > I outlined the migration process last year in
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> > > but failed to follow-up, so I'm glad to see this getting revisited.
> >
> > I started looking into this, and I think we need to start at the
> > bottom, i.e. in the setup package.
> >
> > It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
> > and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
> > but some of the groups listed in sysusers are not listed in the /etc files.
> > IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
> > automatically, and the file provided by setup will be ignored.
> > (It's specified as %config(noreplace).)
> >
> > Should be drop the static /etc/{passwd,group} from setup?
>
> The static files aren't harmful as long as they're not duplicated in other
> packages.
Harmful — no, but unnecessary and confusing. If we go decide to switch
to the rpm sysusers mechanism, then I think we should go all-in on it.
It doesn't make sense to ship a file in setup that would never be installed.
> I seem to recall seeing systemd-sysusers error out if those files were not
> present, but I might be misremembering and/or it might've changed since
> then. The default mechanism uses useradd/groupadd though, I don't know if
> those support non-existent /etc/{passwd,group}.
There might have been bugs for some specific cases, but in general
sysusers was always intended for starting with empty /etc. We certainly
test that case in our tests.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Enabling RPM based sysuser handling
On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:
> I outlined the migration process last year in
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
> but failed to follow-up, so I'm glad to see this getting revisited.
I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.
It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)
Should be drop the static /etc/{passwd,group} from setup?
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
