Re: Zlib-ng rebase from 2.1.* to 2.2.* version
On Mon, Sep 30, 2024 at 11:26 AM Lukas Javorsky wrote: > > Hi, > > As part of the Zlib-ng Fedora Change [1] we're rebasing the Zlib-ng to a new > major release 2.2.*. > > This release brings quite a lot of new optimizations to the zlib-ng which > could be seen in the Fedora Change notes. > > After the first reviews, I started to doubt if the change was even necessary > for this as the soname wasn't bumped and there is no API/ABI diffs (discussed > with the upstream [2]). > > Either way, it's better to be safe than sorry, so I'm announcing this change > here and if a FESCO decides that the change can be dropped we'll do so. > > [1] https://fedoraproject.org/wiki/Changes/ZlibNG-2.2 > [2] https://github.com/zlib-ng/zlib-ng/discussions/1796 For the record, I don't think a Change proposal for a relatively "minor" (pun intended) update like is necessary. But if you want to go through the Change Process (for example, to make this change more visible / public), then that's fine too. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package updates missing in Fedora 41 but present in Fedora 40
On Fri, Sep 27, 2024 at 1:13 PM Fabio Valentini wrote: > > Hi all, > > It's that time of the year again - pointing out packages that are at a > lower version in Fedora 41 (branched) than Fedora 40 (stable). > For those that are just obviously missing unintentionally, I plan to > submit the missing builds and bodhi updates later today. > > As for those updates that are handled by packit and which are missing > Rawhide and / or Fedora 41 builds -- not sure what can be done here, > but packit should be better than that. > > Fabio New status one week later: 13 downgrades instead of 20 (some removed, some added). Downgraded packages (ignoring Release): (13) - fedora-license-data-0:1.57-1.fc40 > fedora-license-data-0:1.56-1.fc41 This one has the corresponding update for Fedora 41 in "pending → testing", so this will be resolved by tomorrow. - fluent-bit-0:3.0.4-1.fc40 > fluent-bit-0:2.2.2-1.fc41 - gedit-control-your-tabs-0:0.4.1-1.fc40 > gedit-control-your-tabs-0:0.4.0-7.fc40 These two packages fail to build on Fedora 41 and Rawhide. - gimp3-0:2.99.19^20240927git771dd219f6-1.fc40 > gimp3-0:2.99.19^20240824git74bbe26918-2.fc41 It looks like this package was accidentally de-retired by merging something into the wrong git branch. I merged the PR to restore the `dead.package` file, it should hopefully be gone from the repos by tomorrow. - libmanette-0:0.2.9-1.fc40 > libmanette-0:0.2.7-2.fc41 The 0.2.9 update was initially missed from Fedora 41, but submitted today, so this should be resolved by tomorrow. - mrack-0:1.19.0-1.fc40 > mrack-0:1.18.0-5.fc41 Packit forgot to submit this one to rawhide (before the f41 branch point). I cherry-picked the 1.19.0 update to rawhide and f41 branches and built the update, so this will be resolved by tomorrow. - neomutt-6:20241002-1.fc40 > neomutt-6:20240425-2.fc41 This update was missed for Fedora 41 yesterday, but submitted today, so this will be resolved by tomorrow, too. - phosh-0:0.41.1-1.fc40 > phosh-0:0.41.0-5.fc41 This looks like a case of "forgot to build for f41 too", but the package fails to build now, so I couldn't resolve this. - picard-0:2.12.1-1.fc40 > picard-0:2.12.0-4.fc41 This one was likely caused by a race condition during the mass branching of f41. I've asked releng to fix it, so hopefully the update should be correctly available by tomorrow. - qm-0:0.6.7-1.fc40 > qm-0:0.6.4-2.fc41 Packit "forgot" to merge this update to f41 and submit it. I did that now. - renderdoc-0:1.34-1.fc40 > renderdoc-0:1.33-3.fc41 This one was also missed from f41 entirely. I submitted the missing build today. - sdrangel-0:7.22.0-1.fc40 > sdrangel-0:7.21.4-4.fc41 This one looks like it failed to build when the 7.22.0 update was originally pushed, but it builds OK now. I resubmitted the failed builds. - shapelib-0:1.6.1-1.fc40 > shapelib-0:1.6.0-3.fc41 This is another case of "forgot to update f41". I have submitted the missing build. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 Fri, Sep 27, 2024 at 4:13 PM Miro Hrončok wrote: > > On 27. 09. 24 13:13, Fabio Valentini wrote: > > - gimp3-0:2.99.19^20240916gitca9d57a417-1.fc40 > > > gimp3-0:2.99.19^20240824git74bbe26918-2.fc41 > > > > Looks like Fedora 41 has an older snapshot. > > The package was retired in Rawhide, but not in Fedora 41, so the fact > > that it's still in Fedora 41 is likely unintentional. > > https://src.fedoraproject.org/rpms/gimp3/pull-request/1 Thanks - I merged your PR since it's pretty clear that not having the gimp3 package retired in f41 is a mistake. Looks like the new retirement automation didn't pick that up, though - the package isn't getting blocked in koji: $ koji list-pkgs --show-blocked --package gimp3 Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Package updates missing in Fedora 41 but present in Fedora 40
On Fri, Sep 27, 2024 at 4:23 PM Sérgio Basto wrote: > > On Fri, 2024-09-27 at 13:13 +0200, Fabio Valentini wrote: > > Hi all, > > > > It's that time of the year again - pointing out packages that are at > > a > > lower version in Fedora 41 (branched) than Fedora 40 (stable). > > For those that are just obviously missing unintentionally, I plan to > > submit the missing builds and bodhi updates later today. > > > > In https://bodhi.fedoraproject.org/updates/new if you search for fc41 > you will see a huge list of packages, the problem is some packages can > be to not update , can be old builds and others things Yes, that is not helpful. I actually compared repository contents to determine the list I posted, and manually checked that all issues were valid (and not caused by race conditions with some f40 update landing a few hours earlier than the corresponding f41 update). Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Package updates missing in Fedora 41 but present in Fedora 40
Hi all, It's that time of the year again - pointing out packages that are at a lower version in Fedora 41 (branched) than Fedora 40 (stable). For those that are just obviously missing unintentionally, I plan to submit the missing builds and bodhi updates later today. As for those updates that are handled by packit and which are missing Rawhide and / or Fedora 41 builds -- not sure what can be done here, but packit should be better than that. Fabio Here's the list of downgrades (ignoring Release): Downgraded packages: (20) - calls-0:47.0-1.fc40 > calls-0:47~beta.0-1.fc41 This was updated on Fedora 40 and in Rawhide, 41 was missed. - chordpro-0:6.060-2.fc40 > chordpro-0:6.050-4.fc41 This was updated on Fedora 40, 39, and in Rawhide, 41 was missed. - fluent-bit-0:3.0.4-1.fc40 > fluent-bit-0:2.2.2-1.fc41 Looks like this one was missed for Fedora 41 and Rawhide, not sure why. The Mass Rebuild build failed too, but koschei is green now. - gedit-control-your-tabs-0:0.4.1-1.fc40 > gedit-control-your-tabs-0:0.4.0-7.fc40 Looks like this one fails to build on Fedora 41+. - gimp3-0:2.99.19^20240916gitca9d57a417-1.fc40 > gimp3-0:2.99.19^20240824git74bbe26918-2.fc41 Looks like Fedora 41 has an older snapshot. The package was retired in Rawhide, but not in Fedora 41, so the fact that it's still in Fedora 41 is likely unintentional. - haruna-0:1.2.0-1.fc40 > haruna-0:1.1.2-3.fc41 This one was built for Fedora Rawhide and 40, but not 41. Should get fixed when / if the ffmpeg 7 rebuild lands. - keycloak-httpd-client-install-0:1.3-1.fc40 > keycloak-httpd-client-install-0:1.1-23.fc41 Looks like the 1.3 update was pushed to the f41 branch in dist-git, but never built. - matrix-synapse-0:1.111.1-1.fc40 > matrix-synapse-0:1.110.0-2.fc41 There's newer versions in Rawhide and F40, but not built for F41. Not sure why. - mrack-0:1.19.0-1.fc40 > mrack-0:1.18.0-5.fc41 Here, packit didn't submit updates for Fedora Rawhide and 41. - nest-0:3.8-1.fc40 > nest-0:3.7-5.fc41 Package was updated to 3.8 on Rawhide, Fedora 40, and 39, but Fedora 41 was missed. - nwchem-0:7.2.3-1.fc40 > nwchem-0:7.2.2-7.fc41 Package was updated to 7.2.3 on Rawhide, Fedora 40, and 39, but Fedora 41 was missed. - phosh-0:0.41.1-1.fc40 > phosh-0:0.41.0-5.fc41 Package was updated to 0.41.1 on Rawhide and Fedora 40, but Fedora 41 was missed. - picard-0:2.12.1-1.fc40 > picard-0:2.12.0-4.fc41 There *is* an update of 2.12.1 for Fedora 41, but it's not tagged correctly: https://bodhi.fedoraproject.org/updates/FEDORA-2024-95f1285d8f - python-rstcheck-core-0:1.2.1-1.fc40 > python-rstcheck-core-0:1.1.1-5.fc41 This one was updated to 1.2.1 only on Fedora 40, not Rawhide or Fedora 41. - qm-0:0.6.7-1.fc40 > qm-0:0.6.4-2.fc41 Another packit victim. Updates were pushed for Rawhide, Fedora 40, 39, and EPEL 9, but not Fedora 41. - renderdoc-0:1.34-1.fc40 > renderdoc-0:1.33-3.fc41 Package was updated to 1.34 on Rawhide and Fedora 40, but Fedora 41 was missed. - samba-2:4.20.5-1.fc40 > samba-2:4.20.4-1.fc41 This update is stuck in "pending" on Fedora 41, looks like the builds are not getting signed: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e331cd53ac - sdrangel-0:7.22.0-1.fc40 > sdrangel-0:7.21.4-4.fc41 This one was updated to 7.22.0 only on Fedora 40 and 39, not Rawhide or Fedora 41. - shapelib-0:1.6.1-1.fc40 > shapelib-0:1.6.0-3.fc41 Package was updated to 1.6.1 on Rawhide and Fedora 40, but Fedora 41 was missed. - 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. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Mock change - not installing documentation files in buildroot
On Wed, Sep 25, 2024 at 1:30 PM Miroslav Suchý wrote: > > In Mock upstream we are right not discussing > > https://github.com/rpm-software-management/mock/pull/1462 > > Here is the summary: > > > Config files that uses DNF now contains `tsflags=nodocs` that tells RPM to > not > > install documentation files. > > This results to smaller buildroot. For fedora-rawhide, with only minimal > set of > > packages, this is reduction from 260MB to 246MB. > > We are not sure if this would/may affect some packages. If this can affect > you, or you have any comment about it, I will > welcome a feedback. We semi-frequenstly get bug reports for Rust packages because of tsflags=nodocs, for example, when people build inside containers instead of mock. It's not an uncommon pattern for Rust packages to #include the contents of README.md as a documentation annotation at build-time. Since we mark README.md as %doc (correctly, I think), builds that use these libraries fail when %doc files are excluded from installation. As such, I would be against a change to set tsflags=nodocs in mock by default. It would create a not insignificant amount of work for us, and it's not clear to me how to solve that in a way that both 1) works and 2) is compliant with packaging guidelines. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [EPEL-devel] Re: FailsToInstall bugs, can we have it enable on EPEL branches ?
On Tue, Sep 24, 2024 at 6:19 PM Troy Dawson wrote: > > While that is getting done, I have got my will-it-install page back up and > working for epel10 > https://tdawson.fedorapeople.org/epel/willit/epel10/status-wont-install.html > > It's only updating once a day, at least until I get Diego's changes > backported. Great, this is useful, thank you! Good to know that my own checks are confirmed by yours (the only Rust packages that currently have issues are blocked by the missing zlib-ng headers in RHEL 10). Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SONAME BUMP] ffmpeg upgrade from v6 to v7
On Tue, Sep 24, 2024 at 12:31 AM Leigh Scott wrote: > > Did you forget to merge the pr? > > https://src.fedoraproject.org/rpms/cantata/pull-request/4#request_diff Yes ... well, no, I didn't forget, but I had assumed that all necessary PRs had already been merged. We'll try again after rebasing the pending PRs. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SONAME BUMP] ffmpeg upgrade from v6 to v7
On Mon, Sep 23, 2024 at 5:17 PM Fabio Valentini wrote: > > I see some failures that I need to look at, but possibly at least some > of them might be caused by "I just submitted things alphabetically and > not in the correct order". Quick update: Most packages built fine, but it appears that either 1) we missed adapting some packages when preparing the update, or 2) the packages *did* build fine with ffmpeg 7 in the past, but no longer do. These packages are still missing from the side-tag because they fail to build due to ffmpeg API changes: - blender - cantata - guacamole-server (only due to -Wdeprecated?) - obs-cef - pianobar - qt6-qtwebengine (curiously, qt5-qtwebengine built fine) - xpra The following rebuilds are blocked because of qt6-qtwebengine: - digikam - goldendict-ng - k3b And obs-studio is blocked because of obs-cef. Additionally, wf-recoder doesn't seem to build at all because a patch in the package fails to apply. We have not yet attempted to build chromium or vlc. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SONAME BUMP] ffmpeg upgrade from v6 to v7
On Fri, Sep 20, 2024 at 6:28 PM Neal Gompa wrote: > > Hey folks, > > The Fedora Multimedia SIG is beginning the effort to upgrade to ffmpeg > v7 in Rawhide. So far, this is what I've determined to be the list of > reverse dependencies: > > alsa-plugins-1.2.12-2.fc41.src.rpm > aqualung-1.2-7.fc41.src.rpm > atomes-1.1.14-3.fc41.src.rpm > attract-mode-2.7.0-12.fc41.src.rpm > audacious-plugins-4.4-4.fc41.src.rpm > blender-4.2.1-3.fc42.src.rpm > cantata-2.5.0-5.fc41.src.rpm > chromaprint-1.5.1-18.fc41.src.rpm > chromium-128.0.6613.137-1.fc42.src.rpm > digikam-8.4.0-3.fc41.src.rpm > ffmpeg-6.1.2-1.fc42.src.rpm > ffmpegthumbnailer-2.2.2-2.20240105git1b5a779.fc41.src.rpm > ffmpegthumbs-24.08.0-1.fc42.src.rpm > goldendict-ng-24.05.05-3.fc41.src.rpm > gpac-2.4.0-3.fc42.src.rpm > gstreamer1-plugin-libav-1.24.7-1.fc42.src.rpm > guacamole-server-1.5.5-2.fc41.src.rpm > guvcview-2.1.0-3.fc41.src.rpm > haruna-1.2.0-1.fc42.src.rpm > indi-3rdparty-drivers-2.0.9-1.fc42.src.rpm > k3b-24.08.0-1.fc42.src.rpm > kf5-kfilemetadata-5.116.0-3.fc41.src.rpm > kf6-kfilemetadata-6.6.0-1.fc42.src.rpm > kpipewire-6.1.90-1.fc42.src.rpm > libcamera-apps-1.5.0-3.fc41.src.rpm > libopenshot-0.3.3-3.fc41.src.rpm > minidlna-1.3.3-8.fc41.src.rpm > mlt-7.28.0-1.fc42.src.rpm > mpv-0.38.0-3.fc41.src.rpm > mpv-mpris-1.1-4.fc42.src.rpm > musescore-4.3.2-13.fc41.src.rpm > neatvnc-0.8.1-1.fc41.src.rpm > notcurses-3.0.9-4.fc41.src.rpm > obs-cef-5060^cr103.0.5060.134~git20231010.17f8588-6.fc41.src.rpm > obs-studio-30.2.2-1.fc41.src.rpm > opencv-4.10.0-1.fc41.src.rpm > pianobar-2022.04.01-9.fc41.src.rpm > python-torchvision-0.19.0-2.fc42.src.rpm > qmmp-2.1.9-1.fc41.src.rpm > qmmp-plugin-pack-2.1.2-1.fc41.src.rpm > qmplay2-24.06.16-2.fc41.src.rpm > qt5-qtwebengine-5.15.17-9.fc42.src.rpm > qt6-qtmultimedia-6.7.2-2.fc41.src.rpm > qt6-qtwebengine-6.7.2-3.fc41.src.rpm > retroarch-1.19.0-5.fc41.src.rpm > rsgain-3.5.2-1.fc41.src.rpm > siril-1.2.4-1.fc42.src.rpm > squeezelite-2.0.0.1486-5.20240508gitfd4a82e.fc41.src.rpm > timg-1.6.0-5.fc41.src.rpm > unpaper-7.0.0-10.fc41.src.rpm > vlc-3.0.21-7.fc42.src.rpm > waypipe-0.9.1-2.fc42.src.rpm > wf-recorder-0.4.0-6.fc41.src.rpm > wxsvg-1.5.25-2.fc41.src.rpm > xine-lib-1.2.13-16.fc41.src.rpm > xpra-5.0.6-4.fc42.src.rpm > xscreensaver-6.09-2.fc41.src.rpm > > The Multimedia SIG will be building everything in the > f42-build-side-96586 side tag. I have already addressed the > ffmpeg->chromaprint->ffmpeg bootstrap cycle in the side tag, so now > it's just building the rest of them. > > We hope to have this all done over the coming days. :) I've submitted rebuilds for most of the packages that hadn't been rebuilt yet - with the exception of chromium (I don't want to touch that one) and vlc (has an open PR to fix issues with ffmpeg 7, but it doesn't build). I see some failures that I need to look at, but possibly at least some of them might be caused by "I just submitted things alphabetically and not in the correct order". Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automated Packit onboarding for new packages
On Fri, Sep 20, 2024 at 10:02 PM Maxwell G wrote: > > On 9/20/24 10:33 AM, Nikola Forró wrote: > > Hi, > > Thanks for the announcement and the informative Flock talk! > > > based on a discussion after Packit talk [1] at Flock, to ease Packit > > onboarding [2], we are planning to automatically open pull requests > > with autogenerated Packit configuration file in newly created projects > > at src.fedoraproject.org, along with a description and instructions > > on how the automation works and how it can be adjusted. > > Have you considered filing a Change Proposal after the plan for the > opt-out/configuration mechanism you mentioned is more concrete? This > way, it can get wider feedback and formal FESCo approval before being > rolled out and packagers won't get surprised by the automated PRs. > > > We want to give package maintainers the option to opt-out or to tweak > > the defaults (for example disabling certain jobs or adjusting default > > permissions). It probably makes sense to do that per maintainer, > > i.e. FAS username, however we would like to know what you think would be > > the best way to handle it - ideas are welcome. > Yeah, I definitely think some sort of configuration per package type > (one for all golang-* packages, one for rust-* packages, one for > python-* packages, etc.) is important here. For example, Rust crates > will need a configuration that regenerates the specfile with rust2rpm > each time. Other package types may be ill-suited for Packit and need to > be opted out entirely. Making this a Change Proposal (or something similar) sounds like a good idea. Speaking for Rust, the default configuration of packit *will* result in broken packages, so filing PRs for those would be actively harmful without some kind of special handling. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: chicken-and-egg scenario with EPEL 10
On Thu, Sep 19, 2024 at 11:16 PM Ron Olson wrote: > > That sounds a lot easier than what I’ve been trying to do; do you happen to > have an example, or a script that shows your process so I can use it as a > starting point? I’ve never created any side tags before so the whole process, > as you described it, is new to me. :\ These are the steps I would use in a situation like this: - switch to branch: `fedpkg switch-branch epel10` - request side-tag: `fedpkg request-side-tag` (this gives you something like `epel10.0-build-side-12345`) - tag build(s) you need: `koji tag-build epel10.0-build-side-12345 ` - push + build packages in the side-tag: git push, `fedpkg build --target epel10.0-build-side-12345` - untag build(s) you needed only for bootstrapping: `koji untag-build epel10.0-build-side-12345 ` - submit update to bodhi via Web UI (side-tag selector is a popup in the upper right-hand corner of the "Crate update" page) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: chicken-and-egg scenario with EPEL 10
On Thu, Sep 19, 2024 at 5:20 PM Stephen Smoogen wrote: > > > > On Thu, 19 Sept 2024 at 11:07, Ron Olson wrote: >> >> Hi all- >> >> I’m trying to get Swift packaged for EPEL 10 but have an interesting >> situation that I presume has been seen before, so am hoping for some >> guidance. >> >> Since 5.9 Swift has required a previous version of Swift to build; 5.8 is >> the last version that builds by itself. Now I’d like to package Swift 6 for >> EPEL 10, but because no previous version of Swift exists, I think what I >> have to do is build 5.8, while also applying new patches because of versions >> of things like Python that weren’t an issue when 5.8 was originally built. >> Once 5.8 is hopefully built and available on EPEL 10, then I can build Swift >> 5.10, then build Swift 6. >> >> Am I doing this workflow correctly? When packages depend on previous >> versions of the package do folks do what I’m doing and basically go back to >> the beginning and move forward until the latest version can be built? And >> would I have to start all over again with EPEL 11, 12, etc.? > > > In the past, there are a couple of ways to bootstrap a software language: > 1. Do the work the long way like you list and build a bunch of things over > and over from scratch until you get the one you need. Do this in a sidetag(?) > so it doesn't affect (infect?) the main release. > 2. Work with releng to set up the appropriate 'side area' in koji which will > check in the version of swift from Fedora 39 or 40 which meets your needs. > Use this to build your first level of bootstrap. Have that version 'checked > out' and rebuild the bootstrap to make sure it is viable. Then build the > final one with the bootstrap. > 3. Use various rpm tricks to build a bootstrap of a language compiler which > can be used as a minimal viable compiler. This is dependent on the language > but some will allow you to build something which is just enough to rebuild > itself at a later stage.. put in the rules so that a 'bootstrap' flag can be > sent and it will build that version. Use that to build the next stages. > 4. Combine 1,2,3 because the language is so special it needs all of them. [I > see you older versions of Rust] I don't know if this would be applicable to swift too, but the way I handled bootstrapping the Rust crate stack in EPEL 10 was by - creating a side-tag for epel10 - tag rawhide builds into the side-tag as necessary to resolve the bootstrap problem - rebuild things from the epel10 branch - untag all tagged-in rawhide builds again - submit side-tag as update via bodhi Unless I miss something (like, is the swift package fundamentally different on EPEL?), that should work here, and it would involve many fewer steps than the other solutions. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Request for help for packaging new potential Workstation default apps
On Tue, Sep 17, 2024 at 1:20 PM Neal Gompa wrote: > > Hey folks, > > The Fedora Workstation WG is considering replacing several preloaded > apps with alternatives: > > * Rhythmbox -> (gnome-music + Decibels[1]) or Amberol[2] > * Evince -> Papers[3] > * Totem -> Showtime[4] > > Of these apps, only Papers has a currently active package review[5]. > The Fedora Workstation WG would like some help from interested Fedora > Workstation users to contribute to the success of the Fedora > Workstation offering by packaging these applications in Fedora. > Members of the Working Group can help review packaging by anyone who > takes this on to package the applications in a manner consistent with > the Fedora packaging guidelines and general practices. > > If anyone is interested, please let us know and we can work out > arrangements to assist new contributors. :) I can help with Rust packaging (Amberol) if needed. I already maintain the Rust bindings for GStreamer and GTK4 so I might as well. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust review swaps (for Taskwarrior 3 update)
On Tue, Sep 17, 2024 at 12:43 PM Ankur Sinha wrote: > > On Tue, Sep 17, 2024 12:35:21 GMT, Fabio Valentini wrote: > > On Tue, Sep 17, 2024 at 11:23 AM Ankur Sinha wrote: > > > > > > Hi folks, > > > > > > I have a few rust packages that need to be reviewed for Taskwarrior v3. > > > Would anyone like to swap reviews please? > > > > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2307663: > > > rust-google-cloud-auth > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2307668: > > > rust-google-cloud-storage > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2309375: > > > rust-taskchampion > > > > Why don't these show up on the "Reviewable" package review dashboard? > > If they did, I'd have reviewed them already. > > I'm not sure. I don't see anything in the reviews that pops out to > me. Does the dashboard take the fedora-review-service build status into > account perhaps? These wouldn't build before because they depended on > packages that were also in review (the ones you had previously reviewed :)). Yeah, I see now why. They're blocked by bugs that are not CLOSED, even though the packages were already imported. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust review swaps (for Taskwarrior 3 update)
On Tue, Sep 17, 2024 at 11:23 AM Ankur Sinha wrote: > > Hi folks, > > I have a few rust packages that need to be reviewed for Taskwarrior v3. > Would anyone like to swap reviews please? > > - https://bugzilla.redhat.com/show_bug.cgi?id=2307663: > rust-google-cloud-auth > - https://bugzilla.redhat.com/show_bug.cgi?id=2307668: > rust-google-cloud-storage > - https://bugzilla.redhat.com/show_bug.cgi?id=2309375: > rust-taskchampion Why don't these show up on the "Reviewable" package review dashboard? If they did, I'd have reviewed them already. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-09-10)
On Wed, Sep 11, 2024 at 5:09 PM Vít Ondruch wrote: > > > Dne 11. 09. 24 v 16:41 Fabio Valentini napsal(a): > > Doing line-wrapping by hand instead of letting my mail client do this > > would be a lot of work. > > I'd appreciate if *my* email client had a chance to do the work and wrap > as / if needed. If the formatting of your email client would be > superior, I'd probably not complained, though. I'll try to make the plain-text formatting better next time I run the meeting, but no promises. > > I agree that it could look better ... but I don't know how to achieve > > that without making it more work for the person who runs the meeting. > > > Not wrapping it when posting would be sufficient for me. I don't think GMail lets me do that. When set to "Plain-text mode", it always wraps at 72 columns, from what I can tell. > > Here's the link to the pretty-formatted HTML minutes, they might be > > more to your liking: > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-09-10/fesco.2024-09-10-17.02.html > > Nice, but opening external links is not what I am up to. But yes, at > least my browser can wrap the lines if needed. They are not wrapped in > the original. As I said, I have no option to *not* send it with wrapped lines ... sorry about that. > But as I can see your reply, it is also wrapped similarly to the > original summary, so I am not sure. But looking into history, it seems > that there is ~ 50:50 split between FESCo members who wrap and don't > wrap summaries. Probably related to who uses GMail / Google Workspace and who doesn't? :) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: No matching package to install: 'pkgconfig(xorg-macros) >= 1.8
On Wed, Sep 11, 2024 at 5:26 PM Ron Olson wrote: > > > Hey all, I’m trying to get bdftopcf built for EPEL 10 but it’s failing with > the aforementioned error (No matching package to install: > 'pkgconfig(xorg-macros) >= 1.8). I guess I don’t understand what kind of > package this is, and who to contact to see what can be done; I’ve dealt with > regular packages but this seems to be a special package type. > > Thanks for any info, It's not a special package type. It's something called "virtual Provides". In this case, they are automatically generated by RPM for packages that ship pkg-config files. For pkgconfig(xorg-macros), the package that provides this (in rawhide) is xorg-x11-util-macros, and it appears not to be in EPEL 10 yet: $ dnf (--args to make it query rawhide) repoquery --whatprovides 'pkgconfig(xorg-macros) >= 1.8)' xorg-x11-util-macros-0:1.20.1-2.fc41.noarch Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Summary/Minutes from today's FESCo Meeting (2024-09-10)
On Wed, Sep 11, 2024 at 10:26 AM Vít Ondruch wrote: > > Can these reports not be wrapped to 80 lines or wrapped in a way the > wrapping respect the nesting? The wrapping makes them hard to read. > > Thank for considering. I assume you mean 80 columns, not 80 lines? In fact, the email as it was sent by me *was* automatically line-wrapped (looks like 72 columns): https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7VPWY72SYBMNURE7KNEMEK3RKPBV27X5/ Doing line-wrapping by hand instead of letting my mail client do this would be a lot of work. I agree that it could look better ... but I don't know how to achieve that without making it more work for the person who runs the meeting. Here's the link to the pretty-formatted HTML minutes, they might be more to your liking: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-09-10/fesco.2024-09-10-17.02.html Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2024-09-10)
= # #meeting:fedoraproject.org: fesco = Meeting started by @decathorpe:fedora.im at 2024-09-10 17:02:11 Meeting summary --- * TOPIC: Init Process (@decathorpe:fedora.im, 17:02:34) * TOPIC: #3264 Incomplete Changes Report for Fedora Linux 41 (@decathorpe:fedora.im, 17:11:15) * INFO: Reviews for TaskWarrior 3 are in progress. The package can land after Beta. (@zbyszek:fedora.im, 17:13:48) * TOPIC: Switch to dnf5 (@zbyszek:fedora.im, 17:14:05) * INFO: dnf5daemon was postponed to F42. Gnome-software will continue to use PackageKit + libdnf4. Tracker bug is ON_QA. (@zbyszek:fedora.im, 17:20:15) * TOPIC: IPU6 Camera Support (@zbyszek:fedora.im, 17:21:49) * INFO: Change is feature complete, but with some open bugs. (@zbyszek:fedora.im, 17:23:51) * TOPIC: Make Tuned the Default Power Profile Management Daemon (@zbyszek:fedora.im, 17:24:09) * INFO: The change seems mostly done, but there's some integration work missing. We'll revisit after Beta. (@zbyszek:fedora.im, 17:29:30) * TOPIC: #3266 Fedora 41 Beta Blocker: require the updates-testing repository (@decathorpe:fedora.im, 17:32:15) * INFO: The request to designate active state of updates-testing repo in F41 Beta as a FESCo blocker is withdrawn. (@decathorpe:fedora.im, 17:40:23) * TOPIC: #3267 wolfssl imported to Fedora after skipping MUST policy requirements for new crypto libraries (@decathorpe:fedora.im, 17:41:06) * AGREED: WolfSSL is immediately retired from Fedora. The maintainers may file a new package review request when WolfSSL respects the crypto system policy. This review request must be presented to the FPC, who must approve it before it is added back to the repositories. (+5, 0, -0) (@decathorpe:fedora.im, 17:50:40) * TOPIC: Open Floor (@decathorpe:fedora.im, 17:54:06) * TOPIC: Next Week's Chair (@decathorpe:fedora.im, 17:54:27) * ACTION: nirik to chair next week's meeting (@decathorpe:fedora.im, 17:57:38) * TOPIC: Open Floor (@decathorpe:fedora.im, 17:57:49) * TOPIC: Create fedora/fedora-netboot repo on quay.io (@decathorpe:fedora.im, 18:04:47) * LINK: https://pagure.io/fedora-infrastructure/issue/12152 (@decathorpe:fedora.im, 18:04:53) * AGREED: FESCo would like to see a Change Proposal for better visibility of the change and to invite public discussion. (+5, 0, -0) (@decathorpe:fedora.im, 18:11:42) * TOPIC: Open Floor (@decathorpe:fedora.im, 18:12:38) Meeting ended at 2024-09-10 18:14:30 Action items * nirik to chair next week's meeting People Present (lines said) --- * @decathorpe:fedora.im (88) * @zbyszek:fedora.im (71) * @nirik:matrix.scrye.com (31) * @sgallagh:fedora.im (25) * @zodbot:fedora.im (19) * @conan_kudo:matrix.org (15) * @humaton:fedora.im (15) * @adamwill:fedora.im (6) * @meetbot:fedora.im (3) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 Today's FESCo Meeting (2024-09-10)
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-09-10 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 = N/A = Followups = #3264 Incomplete Changes Report for Fedora Linux 41 https://pagure.io/fesco/issue/3264 #3266 Fedora 41 Beta Blocker: require the updates-testing repository to be active https://pagure.io/fesco/issue/3266 = New business = #3267 wolfssl imported to Fedora after skipping MUST policy requirements for new crypto libraries https://pagure.io/fesco/issue/3267 = 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: Non-responsive maintainer check for huzaifas (Huzaifa S. Sidhpurwala)
On Mon, Sep 9, 2024 at 9:57 AM Alexander Ploumistos wrote: > > On Mon, Sep 9, 2024 at 3:30 AM Huzaifa Sidhpurwala > wrote: > > > >> > > Great, can you pls ask for permissions there? I can approve it. > > Are you sure it can work this way? For the packages I'm the > maintainer, there is a settings panel which allows me to add users or > groups and grant them admin access. I don't see a button or whatever > to request access on the pages of goffice or gnumeric. Yup, there hasn't been a "ask for permissions" button anywhere since pkgdb2 was sunset like a decade ago. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning harvey
On Fri, Sep 6, 2024 at 12:48 PM Ben Beasley wrote: > > On 9/5/24 12:06 PM, Przemek Klosowski via devel wrote: > > > Do you think that is a technical decision, based e.g. on dependencies > > they need, or a business decision to use the app store? It's their > > right to choose, but I'm curious whether it reflects the broader > > developer sentiment towards flatpaks. > I have no idea. I don’t believe the Fedora package has any technical > defects in practice. In this case, I was willing to follow upstream’s > request without further investigation into their motives, and I’m not > drawing any broader conclusions. In fact, I still maintain Fedora > packages for a few other programs that are distributed in the > ElementaryOS AppCenter but developed by different people. In my experience (as the original Fedora packager of many of these "Made for elementary" apps that are now distributed via the elementary flatpak remote), there's often no technical problems with building them for Fedora. The only "real" issue some of them had is that parts of their UI looked very broken if they weren't used with the elementary GTK theme, especially if they used custom widgets and / or heavily relied on widgets that are part of Granite. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to create a rpm-autospec based package
On Thu, Sep 5, 2024 at 12:01 PM Michael J Gruber wrote: > > Hello, > > Martin Gansser venit, vidit, dixit 2024-09-05 11:41:04: > > Hello, > > > > I have created a new package pyliblo3.spec [1] and would like to know how to > > create a rpm-autospec` based package from it. > > welcome to the club :) > > > If I use the following command > > > > [martin@fc40 SPECS]$ rpmautospec convert pyliblo3.spec > > Converted to %autorelease and %autochangelog. > > > > then these two lines are changed in the spec file. > > > > Release: %autorelease > > > > %changelog > > %autochangelog > > > > and a changelog file is created. > > Perfect! There is nothing else to do besides committing the changes. For new packages, do not commit a "changelog" file. It is *only* there to preserve historical changelog entries for packages that have history *before* being converted to rpmautospec. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F40 to F41
On Mon, Sep 2, 2024 at 12:21 PM Miroslav Suchý wrote: > > Do you want to make Fedora 41 better? Please spend 1 minute of your time and > try to run: > > dnf --releasever=41 --enablerepo=updates-testing --assumeno distro-sync > > This command does not replace `dnf system-upgrade`, but it will reveal > potential problems. > > You may also run `dnf upgrade` before running this command. > > > The `--assumeno` will just test the transaction, but does not make the actual > upgrade. > > > In case you hit dependency issues, please report it against the appropriate > package. > > Or against fedora-obsolete-packages if that package should be removed in > Fedora 40. Please check existing reports against fedora-obsolete-packages > first: > > https://red.ht/2kuBDPu > > and also there is already lots of "Fails to install" (F40FailsToInstall) > reports: > > http://bit.ly/3TcO0Ng > > > One note: > > * you may want to run the same command with dnf5 to help test new dnf. Do not > forget to add --best otherwise DNF5 hides all problems. > > > For convenience here is the relevant part of Fedora Guidelines on renaming > and replacing packages: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages The only issues I see on my system are these: ``` Downgrading: httpd x86_64 2.4.61-3.fc41fedora 47 k httpd-corex86_64 2.4.61-3.fc41fedora 1.4 M httpd-filesystem noarch 2.4.61-3.fc41fedora 12 k httpd-tools x86_64 2.4.61-3.fc41fedora 80 k mod_lua x86_64 2.4.61-3.fc41fedora 58 k perl-Regexp-Pattern-License noarch 3.11.1-5.fc41fedora 112 k wpa_supplicantx86_64 1:2.11-2.fc41fedora 1.7 M ``` The http downgrade is weird - the 2.4.62-2 update corresponding to what I currently have on f40 should already be in the f41-updates-testing repos since a month ago, but apparently it's not? The perl-Regexp-Pattern-License and wpa_supplicant downgrades appear to be just NVR downgrades with Release number not having been synced / bumped correctly between branches. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM dependency generator sanity check
On Sun, Sep 1, 2024 at 5:31 PM Dridi Boukelmoune wrote: > > > I made the scripts end with something written to stderr followed by an > > explicit "exit 1", and I can see the error message, but then it just > > succeeds. So my question is how to make RPM register that a dependency > > generator failed and in turn fail the build? > > I tried following the rpmdeps code but I gave up after one indirection > too many. I'm unfortunately unfamiliar with the RPM code base. I also > tried to use the %error macro using parametric macros for my > generators. I was able to get an error message but it wouldn't fail > the build either. Eventually, I accidentally found a nasty dirty trick > to fail the build: > > echo '!error: something went wrong!' > > In the logs I get this: > > > RPM build errors: > >Dependency tokens must begin with alpha-numeric, '_' or '/': !error: > > something went wrong! > > I can't say I'm proud of this hack but at least, the error message > shows up to give a clue. I can finally add some error handling to my > dependency generators. Yes, currently the exit code is ignored, and the only way to break the build is to generate a line that does not parse as a valid RPM dependency. The Rust dependency generator does something similar, and the Python generator does too, AFAIK. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change - batch #2 of all remaining packages
On Sun, Aug 25, 2024 at 9:18 AM Miroslav Suchý wrote: > > Here is the second batch of changes for 1000 packages > (golang-github-danwakefield-fnmatch to perl-Image-Xbm) > > https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-normal-diff.txt > > Shorten version without the context is here: > > https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-small-diff.txt > > I will appreciate a review. If there will be no issue I will commit and push > this to dist-git in a week. And then I will post another (larger) batch for a > review. The parsec-tool conversion looks a bit strange. It's a Rust package, its License string should be trivially constructible from SPDX identifiers. It looks like it hasn't been updated in a while though, so it might predate the switch of defaults from old to new identifiers rust2rpm ... Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages with problematic license tag (for SPDX conversion)
On Tue, Jul 30, 2024 at 4:08 PM Miroslav Suchý wrote: > > As the SPDX Change slowly finishes I focused on the license that I regularly > report as: > > warning: not valid neither as Callaway nor as SPDX, please check (snip) I was finally able to set aside some time to look at this. > rust-btrddcavalca Filed a PR for GPL-3.0 → GPL-3.0-only and fixed the second invalid license (overlooked FIXME): https://github.com/danobi/btrd/pull/20 > rust-dutree kalev Project looks dead upstream. Might want to remove it from Fedora. > rust-ifcfg-devname jamacku This expression looks correct in the latest spec file. > rust-nettle decathorpe Filed a PR upstream to move away from deprecated identifiers: https://gitlab.com/sequoia-pgp/nettle-rs/-/merge_requests/45 > rust-nettle-sys decathorpe Filed a PR upstream to move away from deprecated identifiers: https://gitlab.com/sequoia-pgp/nettle-sys/-/merge_requests/47 > rust-rav1e decathorpe This one seems to be a false positive, similarly to oxipng. It uses a macro to de-duplicate the license string between different subpackages. > rust-rpick bowlofeggs Filed a PR upstream to move away from deprecated identifiers: https://github.com/bowlofeggs/rpick/pull/372 > rust-ybaas decathorpe Filed a PR upstream to move away from deprecated identifiers: https://github.com/bowlofeggs/ybaas/pull/103 > rust-yubibombdecathorpe Filed a PR upstream to move away from deprecated identifiers: https://github.com/bowlofeggs/yubibomb/pull/44 > rust-zbase32 decathorpe This uses a deprecated SPDX identifier, but the project is dead upstream. The only dependent package (rust-sequoia-chameleon-gnupg) will likely migrate to a different one, so it will probably be removed from Fedora in the future. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to contact Fedora Security Team
On Sun, Aug 18, 2024 at 5:23 PM Andrew Bauer wrote: > > Thanks everyone for the great responses. > > I'll certainly check out the Matrix room if I have to, but I was hoping I > could do this in a way that allows me to directly reference any responses I > get via link in the following new package request: > https://bugzilla.redhat.com/show_bug.cgi?id=2302646 > > The Netatalk project is moving from OpenSSL -> WolfSSL. Hence there is a need > to add WolfSSL package to Fedora repos. > > It has already gone through the normal approval process, but the question was > raised whether this needs an additional approval from the Fedora Security > Team, since this is a crypto library. I raised this question due to this section in the packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/#_new_crypto_libraries > New crypto libraries must comply with the crypto policies to enter Fedora, > unless an exception has been granted by Fedora packaging committee, after > consulting with Fedora security team. The question whether wolfssl complies with system crypto policies hasn't been answered, as far as I can tell, so I don't appreciate that the package was already imported to Fedora regardless. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: poppler soname bump in Rawhide
On Mon, Aug 19, 2024 at 4:33 PM Marek Kasik wrote: > > Hi, > > I've fixed this issue and rebuilt Inkscape. > > Unfortunately, I have issues with some other packages due to the > unannounced soname bump of re2. qt5-qtwebengine needs to be rebuilt due > to that but it fails. I watch the > https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/18#request_diff > and I'm trying to fix the issue with undefined references. I think the issue with undefined references on aarch64 should be fixed? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upcoming libpkgconf soname bump in Rawhide
On Wed, Aug 7, 2024, 10:28 Neal Gompa wrote:
> Hey all,
>
> pkgconf 2.3.0 just released and the jump from 2.1.1 to 2.3.0 brings
> with us a soname bump. I will be updating pkgconf and rebuilding
> dependents in a side-tag, and hopefully get everything done later
> today.
>
> The identified packages are:
> * build2
> * perl-PkgConfig-LibPkgConf
>
> I identified them with the following commands:
> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf.so.4()(64bit)"
> * dnf rq --qf "%{SOURCERPM}" --whatrequires "libpkgconf"
>
> If there are any I missed, please let me know and I will add it to my
> list of packages to build.
>
I might be misremembering, but weren't odd-numbered minor releases
"unstable" and shouldn't be packaged because they might break ABI? Which
was a problem with 2.1 when we added that version?
Fabio
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
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: Rustc version
On Wed, Jul 24, 2024 at 8:04 PM Emanuel Lima wrote: > > It's kata-containers. It works from 1.75 to 1.78 but not with 1.79. > > I opened an issue upstream: > https://github.com/kata-containers/kata-containers/issues/10067 You can't (and really shouldn't) want to build with an older Rust version just because of a warning-turned-error. The default compiler flags in Fedora don't do this (it would be a lot of error noise for no good reason, it would be equivalent to having "-Werror" in the default CFLAGS), it looks like kata-containers *still* doesn't respect the default flags from Fedora and hard-codes its own ones. You should just drop -Dwarnings from the flags. (And ideally respond to my ancient bug report about kata-containers not honoring our default compiler flags). Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora rawhide (to be f41) and openssl engines
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. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Java related] packaging Italian ID card middleware
On Fri, Jul 19, 2024 at 8:57 PM Kilian Hanich via devel wrote: > > Hello, > > I am just following this discussion out of interested and this is kinda > off-topic, but I have a question: Why is that? > > Am 19.07.24 um 11:05 schrieb Marián Konček: > > Gradle is not a preferred build system in Fedora due to various problems > > with its distribution. Gradle as a project is almost entirely not packageable for Fedora in an acceptable way (*), and the upstream developers are in no way interested in changing or improving this. (*) Last time anybody looked at it, it was not possible to build gradle from source without internet access and without pulling in specific versions of pre-compiled dependencies. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On Thu, Jul 18, 2024 at 9:40 AM Miro Hrončok wrote: > > On 18. 07. 24 1:30, Neal Gompa wrote: > > You are conflating license tag conversion with a license audit. Tag > > conversion is explicitly*not* an audit exercise. > > No, I state the old GPL tags and the new GPL identifiers have different > meanings. > > > This is not an audit, and we have never offered a guarantee of > > accuracy. If you want the tags to be accurate, you need to evaluate > > the package every time it is updated. And I know you do it for your > > stuff, but we know not everyone does. And we do not have tooling to > > help people audit their packages properly. We also do not have tooling > > to validate audits in place either. The change to SPDX identifiers is > > *not* coupled to the "no effective licensing" thing. Those were > > separate updates that happened at roughly the same time, but are > > *still* not coupled to each other. > > I don't want to have this conversation here again. I won't change your mind. > > However, I say that what FESCo approved is not what you are acting as-if FESCo > approved. Do you at least see that? I agree that the conversation in the meeting and what was finally approved was slightly confusing, and I already feared that we were not thinking it meant the same thing when we approved it (one of the reasons why I voted 0). Some FESCo members seem to think that we approved "trivial license conversions to SPDX are OK", others seem to think that we approved "licenses that cannot be trivially converted to SPDX must use LicenseRef--". The proposal voted on matches the latter statement, but it does *not*, IMO, imply the first statement. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libqalculate soname bump
On Fri, Jul 5, 2024 at 7:45 PM Mukundan Ragavan wrote: > > I am updating libqalculate to v5.2.0 which bumps the soname version. I > will rebuild the following packages that depend on libqalculate. > > plasma-workspace > step > cantor > qalculate-kde Looks like you forgot to rebuild these packages and just submitted the update as-is? https://bodhi.fedoraproject.org/updates/FEDORA-2024-944fd900df Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libdisplay-info soname bump
On Wed, Jul 3, 2024 at 6:17 AM Aleksei Bavshin wrote: > > On 6/29/24 6:56 PM, Aleksei Bavshin wrote: > > Greetings, > > > > I'm planning to update libdisplay-info to 0.2.0[1] in rawhide next week. > > > > Affected packages: > > > > * dxvk-native > > * gamescope > > * hyprland > > * kwin > > * kwin-x11 > > * mutter > > * wlroots > > > > I'll take care of wlroots and gamescope and will send a PR for > > dxvk-native. The rest are trivial rebuilds. > > > > As I don't have access to the remaining packages, I'll need help from > > the maintainers (CCd). In a few days I'll set up a side-tag and ask you > > to bump the release and rebuild your packages. > > All the prep work has been finished and the side-tag is ready. > Please, rebuild your packages with 'fedpkg build > --target=f41-build-side-91835'. > > I'm planning to merge it either when all the builds are complete or by > Sunday on the condition that the critical path packages (mutter, kwin) > are done. > > Thanks in advance for your help! Let me know if you need provenpackager help with rebuilds. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Oddness detecting new versions of ocamlbuild
On Thu, Jul 4, 2024 at 9:37 AM Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1992935 > > A new version of ocamlbuild (Fedora: ocaml-ocamlbuild) was found. > However the version isn't 4.02.3, but 0.15.0: > > https://github.com/ocaml/ocamlbuild > > and upstream-release-monitoring didn't reopen the bug (maybe for the > same reason that it found the "new" version is the same as the "old" > version so it didn't need to open it?) > > Ideas here? It looks like the GitHub repo has some old tags (for a different versioning scheme?): https://github.com/ocaml/ocamlbuild/tags?after=0.10.1 Those are larger versions than the "latest". release-monitoring doesn't sort them by date but by rpm-version-sort. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)
On Wed, Jul 3, 2024 at 4:52 PM Vít Ondruch wrote: > > The system which I was dealing with is older and upgraded to more recent > Fedora. But if I remember correctly, the Flatpack runtimes were part of > the reason why it was for a while stuck with older Fedora version, > because the runtimes consumed so much space that it prevented system update. > > And I still think that having some quota for system and user home to > prevent these kind of issues is still good idea, no matter if Btrfs or > other FS is used. > > The deduplication would actually talk in favor of user installation, > because otherwise one of the reasons for system installed Flatpack could > be the space savings. If by "Flatpack" you mean "Flatpak but 14.2857% bigger" , then maybe that's the cause of your problem? 🤭 Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unannounced soname change: libmutter-14 -> libmutter-15
Hi all, In another installment of the semi-annual event, mutter got updated to an alpha version, and changed its soname in Rawhide without the prerequisite notification. This broke at least the gala and wingpanel packages (and elementary-greeter, which is currently stuck in package review). I'll have to put further work on packaging the Pantheon DE packages on hold until this is resolved in some way. (No, just rebuilding them for the new soname is not enough.) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Receiving BZ Outstanding Requests for orphaned package
On Fri, Jun 28, 2024 at 1:32 PM Sandro wrote: > > On 28-06-2024 13:23, Christiano Anderson wrote: > > I have orphaned the buildstream package some time ago, but I may not > > have removed myself from the Bugzilla Assignee option. > > > > I am receiving outstanding request notifications related to this > > package. I couldn't find a way to take myself off the Bugzilla Assignee. > > > > Was there a step in the orphaning process that I missed? How to fix it? > > It looks like you might need to clear the needinfo flag on > https://bugzilla.redhat.com/show_bug.cgi?id=2252071. > > I believe those are not handled by orphaning a package, but remain open > as is. Correct. Additionally, you will remain in the CC of existing bugs, unless you remove yourself. Only *new* bugs will not be associated with you. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Wed, Jun 26, 2024, 11:48 Miro Hrončok wrote: > On 26. 06. 24 5:59, Richard Fontana wrote: > > On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok > wrote: > >> > >> On 25. 06. 24 22:50, Miroslav Suchý wrote: > >>> Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): > > Could you make the comment something like this? > > # Automatically converted from old format: GPLv2 > # TODO check if there are other licenses to be listed > License: GPL-2.0-only > >>> > >>> We (the Change owners) discussed this on a meeting today. And we > agreed on output: > >>> > >>> # Automatically converted from old format: GPLv2 > >>> # TODO convert to correct SPDX identifier > >>> # See > https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ > >>> License: LicenseRef-Callaway-GPLv2 > >>> > >>> This is valid SPDX identifier. But not on the list of Fedora's allowed > >>> licenses, so any QA tool will remind you to check the license. > >>> > >>> What do you think? > >> > >> I don't understand what is the benefit of doing this at all. Sorry. > > > > The benefit I see is that it immediately causes all license tags to > > conform to the SPDX license expression standard, while also making it > > very clear what parts of those license expressions are actually legacy > > elements that have to be examined and replaced. (This assumes we > > wouldn't use `LicenseRef-Callaway-` for any other purpose.) > > What is the benefit of that outcome? > > I understand the benefit of SPDX in general. > > I don't understand the benefit of converting everything to custom > LicenseRef > identifiers. > > We are already making it clear that the expressions are legacy by... being > legacy. > > Clearly, I must miss something. What do we *gain* by causing all license > tags > to conform to the SPDX license expression standard despite actually just > using > the old tag with extra boilerplate? > > I am not trying to fight this decision, I am genuinely confused: What it > is > that makes us hurry this. Why cannot we keep the gradual conversion? > To make managers or scrum masters happy? I don't know either ... Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > Fedora Matrix: mhroncok > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Exiv2 0.28.2
On Mon, Jun 17, 2024 at 10:29 AM Mattia Verga via devel wrote: > > Il 17/06/24 07:15, zebo...@gmail.com ha scritto: > > This is still in progress in f41-build-side-91095 > > ```todotxt sort:priority:desc sort:status:asc > x calligra > x darktable > digikam > x exiv2 > geeqie > gegl04 > x gerbera > gimp-lensfun > x gnome-commander > gpscorrelate > x gthumb > x gwenview > x hugin > immix > kde-runtime > x kf5-kfilemetadata > x kf6-kfilemetadata > koko > kphotoalbum > krename > krita > libextractor > x libgexiv2 > x libkexiv2 > luminance-hdr > merkaartor > mythtv > nomacs > x pcmanfm-qt > x pdf2djvu > x photoqt > x phototonic > x python3-exiv2 > x qgis > x qimgv > x rawstudio > x rawtherapee > x siril > stellarium > x taglib-sharp > x ufraw > x viewnior > ``` > > My next day off is Sunday, so it might take a moment to go through the > remaining. > > > Can I help you in some way? Is there anything specific other than trigger a > new build in the side tag and check the result? Is this still ongoing? Is there anything we can do to help move this forward? Keeping side tags open for so long often creates merge issues ... Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License changes of some Rust crates
Hi all, There were some minor license changes and / or corrections in recently updated packages for Rust crates: - databake / databake-derive: corrected from Unicode-DFS-2016 to Unicode-3.0 - enum-iterator / enum-iterator-derive: relicensed from MIT to 0BSD by upstream The databake crate is a build-time-only dependency, so it does not have any effect for dependent packages. The enum-iterator change from MIT to 0BSD *does* affect dependent applications, but I don't think switching to a more permissive license should cause problems here. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reverse dependency query
On Mon, Jun 24, 2024 at 11:28 PM Jerry James wrote: > > On Mon, Jun 24, 2024 at 3:19 PM Miro Hrončok wrote: > > This seems like the traditional "the SRPM was built on i686" problem. > > If I click through to the buildSRPMFromSCM task, I arrive here: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=118928877 > > which says that task was executed on > buildvm-a64-24.iad2.fedoraproject.org, which is aarch64. Are we using > that SRPM for the build only, then picking some random SRPM from the > build to promote? Yes, it looks like the initial investigation in the linked koji RFE is wrong. The SRPM is not the one from the buildSRPMfromSCM task, but a random one from the buildArch task outputs. > > 3-year-old RFE for Koji: https://pagure.io/koji/issue/2726 > > Thanks for the pointer. So ... yeah. Repository metadata is not as useful for queries as it ought to be, because it doesn't reflect architecture-specific BuildRequires correctly. Both because it collects the SRPM file from a random architecture, and because there is only one "-sources" repo that is shared by *all* architectures. This is the *only* reason why there is a manually curated list of "overrides" for false positive "broken dependencies" in the FailsToInstall checker: https://github.com/ironthree/repochecker/blob/main/overrides.json And it's the reason why "leafdrop" results are not always accurate: https://pagure.io/leafdrop/blob/main/f/leafdrop#_9-14 Having truly architecture-independent SRPM files would be really really awesome - it would help both with making repoqueries more accurate, and it would make SRPM files actually reproducible. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reverse dependency query
On Mon, Jun 24, 2024 at 10:48 PM Jerry James wrote:
>
> I want to see what packages depend on antlr4.
>
> $ fedrq wr antlr4
> antlr4-maven-plugin-4.10.1-15.fc41.noarch
> azure-cli-2.61.0-2.fc41.src
> coq-8.18.0-7.fc41.src
> golang-github-google-cel-0.12.4-7.fc40.src
>
> And repoquery agrees:
>
> $ dnf --repo=rawhide --repo=rawhide-source repoquery --whatrequires
> antlr4 --alldeps
> antlr4-maven-plugin-0:4.10.1-15.fc41.noarch
> azure-cli-0:2.61.0-2.fc41.src
> coq-0:8.18.0-7.fc41.src
> golang-github-google-cel-0:0.12.4-7.fc40.src
>
> Except that's incomplete. The sympy package was omitted. From sympy.spec:
>
> %ifarch %{java_arches}
> BuildRequires: antlr4
> %endif
>
> The most recent build was on 12 June 2024:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2469158. Look
> at the x86_64 root.log, for example, and antlr4 is there:
>
> DEBUG util.py:463: antlr4 noarch
> 4.10.1-15.fc41 build2.6 MiB
>
> Is there a query that shows sympy in the result?
It looks like the problem is actually on the sympy side, not with your query.
The latest "sympy.src" package does not have a dependency on antlr4:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=38863151
Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On Thu, Jun 20, 2024 at 12:47 AM Miro Hrončok wrote: > > On 19. 06. 24 23:32, Miroslav Suchý wrote: > > Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a): > >> > >> How do you know the License tag is not supposed to be e.g. "GPL-2.0-only > >> AND > >> MIT" or similar? > >> > >> Converting "GPLv2" (which could mean any number of "weaker" licenses are > >> hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" > >> (which > >> means all the code is exactly GPL 2.0 only) cannot be done automatically. > >> > >> > > I don't know. But it seems like the best option. > > Not to me. > > When we decided to do the SPDX thing, we also decided to do the "no effective > license analysis" and "list all the licenses". I don't have an opinion whether > that decision is good or bad, but it is that way. We cannot automatically > convert GPLv2 to GPL-2.0-only (or similarly with other variants and versions). > > If we do this, we are effectively saying "OK, we agreed on a set of rules, but > we decided to ignore them for a sake of..." what exactly? Completeness? > Closure? That does not make sense to me. I agree. I thought the transition to SPDX identifiers *also* meant that packages *should* be reevaluated wrt/ their licenses. Doing an automatic conversion makes it *look* like that reevaluation was done when in fact it was not. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson wrote: > > On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski > wrote: > > > > On Wednesday, 19 June 2024 at 17:17, drago01 wrote: > > > [...] at some point we need to do the cut and not being held back by old > > > / ancient hardware forever. > > > > What do you mean by "being held back"? What's being prevented by not > > requiring x86-64-v2 for all packages while allowing few select ones to > > have higher arch requirements? And why do "we need to"? > > > > As Neal said, rpm allows building for target x86_64_v2, so... let's do > > that for those packages that require it? > > That may mean having two versions of the same package, one built > against v1 and one v2, you're then doubling the workload for a whole > lot of contributors for the sake of old hardware. > > We had the same discussions on i686 and the first few times it was > proposed it didn't get traction, but it eventually did. There was a > i686 SIG which ultimately went nowhere. > > To put this a different way, would you be prepared to do the work to > maintain the old v1 packages if maintainers don't want to maintain 2 > versions? IIUC this wouldn't require maintaining a separate package, but just adding x86_64-v2 as a separate build *target* for the same package. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change GPL+ to GPL-1.0-or-later
On Mon, Jun 17, 2024 at 4:24 PM Miroslav Suchý wrote: > > Dne 15. 04. 24 v 8:53 dop. Miroslav Suchý napsal(a): > > > > I am going to do the mass change of the license from GPL+ to > > GPL-1.0-or-later > > > Done. It appears that your script had issues. There are a lot of packages that were rebuilt without pushing any changes to them, for example: https://src.fedoraproject.org/rpms/thunar-sendto-clamtk See also: https://pagure.io/releng/issue/12167 Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Mon, Jun 17, 2024 at 2:37 PM Chris Adams wrote: > > Once upon a time, Daniel P. Berrangé said: > > I think I've convinced upstream to change their approach to make their > > recent changes a compile-time opt-in, to allow build time choice of the > > non-optimized code, rather than forcing it on everyone. So hopefully > > we don't need todo anything in Fedora now. > > Since this seems to be performance related, any chance Fedora can > provide both a baseline and a x86-64-v2 version, maybe with a wrapper to > automatically choose the correct verion? You mean ... like this? https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Fri, Jun 14, 2024 at 5:04 PM Ian McInerney via devel wrote: > > > Fabio Valentini venit, vidit, dixit 2024-06-14 16:25:56: > > > > Julia comes from a mindset or background where reproducibility is > > important. Think of data science where you distribute both analysis and > > code and want your code to always support your analysis ;-) > > > > Now, one thing is enabling that (via explicit requirements, bundling, > > containerizing and such), another thing is basically inhibiting > > unbundling. > > > > Julia users might be best served by not packaging Julia as rpm any more. > > This implies not packaging it as Fedora flatpak either. > > > > I would not phrase this as "Fedora does not support Julia", though. > > Rather, "Julia does not support distribution packaging" but also "Fedora > > supports containerized workflows" such as those preferred by and > > supported by Julia. In fact, Fedora/RHEL are *the* base for > > containerized workflows, of course! > > The better way to use Julia is through juliaup > (https://github.com/JuliaLang/juliaup), which will install it from versions > compiled by the upstream project and hosted on their infrastructure - and > also allow for installation of multiple versions side-by-side (since there > are both long-term support versions like 1.6 and the current stable version). > I had a look at packaging it before, but never followed up on that yet, just > due to not having enough time yet. (I think it should just need to be a > rust2rpm package, with one or two extra dependencies that need packaging). Oh, I didn't expect this to be written in Rust. If that is indeed a better way to manage local Julia installations, then I can look into packaging it and / or putting it on the Rust package wishlist. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Mon, Jun 10, 2024 at 11:57 PM Adam Williamson wrote: > > On Mon, 2024-06-10 at 20:57 +0200, Fabio Valentini wrote: > > On Mon, Jun 10, 2024 at 8:52 PM Fabio Valentini > > wrote: > > > > > > On Mon, Jun 10, 2024 at 8:49 PM Colin Walters wrote: > > > > > > > > Worth a bit of wide distribution as I'm sure I'm not the only one who > > > > got burned: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 > > > > > > The build of Julia that has this has been unpushed from > > > f40-updates-testing already: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 > > > > > > Not sure why these changes landed in the f40 branch only, but not in > > > rawhide. > > > > Side note: The commits that are on the f40 branch *only* definitely > > look suspicious: > > https://src.fedoraproject.org/rpms/julia/commits/f40 > > > > Looks like Julia is bundling LLVM, libuv, libunwind, gmp, curl (!), > > libssh2 (!), and mbedtls (!) ... > > https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources > > Back story is in https://bugzilla.redhat.com/show_bug.cgi?id=2274270 . > Not really suspicious, just an upstream terminally inhospitable to > downstreams. It kinda looks like we should just ditch the package, to > me. You are right - I meant to say it was suspicious that these commits were only done in the f40 branch, but are not present in rawhide. Usually packages are worked on in rawhide *first* and then changes are merged or backported to stable branches. Reading up on the bug, the situation with Julia does indeed sound like a major clusterf***. If Julia only supports running on top of the same versions of libraries that it was built against, maybe it needs to be rebuilt any time any of those libraries change? It also sounds like Julia packages are distributed as pre-compiled binaries? That seems like a major security issue if Julia is just downloading pre-compiled binaries from somewhere and running them ... Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging podlet?
On Thu, Jun 13, 2024 at 2:27 PM Richard Shaw wrote: > > Forgot the link in my first email: > > https://github.com/containers/podlet I took a quick look. It's a standard Rust project, so the spec file is almost entirely boilerplate. There's a few missing dependencies that would need to be packaged though (4 libraries + any missing dependencies). If people are interested in having podlet available as a tool in Fedora, I can take care of that. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Thu, Jun 13, 2024 at 11:44 AM Ben Cotton wrote: > > On Wed, Jun 12, 2024 at 10:51 PM Gary Buhrmaster > wrote: > > > > On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel > > wrote: > > > > > But it is the ONLY approach that is compatible with Fedora policies, and > > > as > > > such should be required. ESPECIALLY for a package like QEMU that many > > > people > > > are using. > > > > Please provide your audited (by a 3rd party) data that shows > > that MANY (i.e. significant percentage of) people on x86_64-v1 > > users have a need for qemu. > > > > Those without actual data are simply offering an opinion, > > and should be dismissed without further consideration. > > > > We will all wait for your 3rd party validation of your data. > > This isn't a constructive way to have the conversation. As you pointed > out in an earlier message, no one has this data, so all of us are left > to take our best guess at it. Let's be respectful to each other about > it. > > For myself, I think it's reasonable to conclude there's a non-trivial > amount of people using QEMU on that hardware in some fashion. Much of > that is probably from podman as opposed to running large virtualized > environments at this point, but the podman use case is important for a > lot of people. > > From the previous times the baseline conversation has happened, I > suspect that I am more open to raising it than Kevin is, but I agree > with his general direction here. Absent reliable data, I tend toward a > conservative approach to dropping hardware support. But there's no > easy answer here. If QEMU upstream is *really* set on unconditionally raising their required x86_64 ISA version, and cannot be convinced that this course of action would be painful for distributions like Fedora, then I think we should at least have a self-contained change for the QEMU update that introduces this change. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 5:47 PM Daniel P. Berrangé wrote: > > On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote: > > This never made it to the packaging guidelines, but FESCo made a relevant > > decision a few years ago: > > > > Libraries packaged in Fedora may require ISA extensions, however any > > packaged application must not crash on any officially supported > > architecture, either by providing a generic fallback implementation OR by > > cleanly exiting when the requisite hardware support is unavailable. > > > > https://pagure.io/packaging-committee/issue/1044 > > Wow, that is incredibly *loosely* written. That allows for glibc to > build itself with '-march=x86-64-v2', or for systemd to build itself > with '-march=x86_64-v2 -mneeded', at the discretion of the maintainer. > This would effectively reverse the entire decision to reject the > x86-64-v2 baseline feature proposal for. > > Surely that is not what they meant to permit ? Surely this exception > was only intended to be scoped more narrowly ? Perhaps to non-critical > path libraries, or only packages outside the default release media ? It has been some time since I was part of this discussion (IIRC both in FPC and FESCo at the time), and yes, I don't think your interpretation matches our intentions, even though it *could* be read that way. IIRC this was mostly about adding *new* packages that have higher ISA requirements than x86_64-v1 (the current Fedora baseline). I don't think we considered that existing packages might want to push their requirements, too. But as I said, it's been some time, so I might mis-remember. So in the situation with QEMU, IMO it would be best to do detection of AVX2 (or whatever x86_64-v2 features are required) at *runtime* and provide a slower fallback code path. Alternatively, patch the build system to build without the assumption that x86_64-v2 instructions are available. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Mon, Jun 10, 2024 at 8:52 PM Fabio Valentini wrote: > > On Mon, Jun 10, 2024 at 8:49 PM Colin Walters wrote: > > > > Worth a bit of wide distribution as I'm sure I'm not the only one who got > > burned: > > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 > > The build of Julia that has this has been unpushed from > f40-updates-testing already: > https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 > > Not sure why these changes landed in the f40 branch only, but not in rawhide. Side note: The commits that are on the f40 branch *only* definitely look suspicious: https://src.fedoraproject.org/rpms/julia/commits/f40 Looks like Julia is bundling LLVM, libuv, libunwind, gmp, curl (!), libssh2 (!), and mbedtls (!) ... https://src.fedoraproject.org/rpms/julia/blob/f40/f/sources Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: heads up: julia has a bunch of incorrect Provides (bug 2291191)
On Mon, Jun 10, 2024 at 8:49 PM Colin Walters wrote: > > Worth a bit of wide distribution as I'm sure I'm not the only one who got > burned: > https://bugzilla.redhat.com/show_bug.cgi?id=2291191 The build of Julia that has this has been unpushed from f40-updates-testing already: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a00986001 Not sure why these changes landed in the f40 branch only, but not in rawhide. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Fri, May 31, 2024 at 7:47 PM Stephen Gallagher wrote: > > On Fri, May 31, 2024 at 1:22 PM Fabio Valentini wrote: > > > > On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher > > wrote: > > > > > > > Looking forward to EPEL 10! More work for me, yay! > > Just a few questions - I would have looked them up in the meeting log, > > but it's not linked. > > > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-31/eln.2024-05-31-16.01.txt > > I'm not sure why that wasn't part of the "minutes" output. Probably > worth looking into... > > > > * AGREED: All packages currently included in ELN Extras will have > > > an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51) > > > > Is there a list of these packages available somewhere? > > > > https://tiny.distro.builders/view--view-eln-extras.html > > > > * AGREED: We will mass-create empty branches for EPEL 10 and will > > > work towards a better solution for EPEL 11 (@sgallagh:fedora.im, > > > 16:51:54) > > > > I hope you will not create epel10 branches for *all* packages in Fedora. > > Which packages *will* get an epel10 branch auto-created? > > > > This was the result of a discussion as to whether we should > pre-populate the branch contents. We settled on creating them as > empty. It's the same list as above. > > > > * INFO: Investigation topic: Drop ELN Extras in favor of starting > > > EPEL 11 soon after EPEL 10, backed by ELN until branching. > > > (@sgallagh:fedora.im, 16:56:06) > > > > This sounds great! ELN Extras has always been confusing to me. > > > > The idea behind ELN Extras was to get an early preview of stuff that > people want in the next EPEL release. During the discussion today, we > decided that it might be easier to essentially just create EPEL N+1 > earlier and take advantage of the ELN tooling and tagging. I'm going > to work up a proposal over the next week or so and send it out for > discussion. Great, thank you for the quick response! Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher wrote: > Looking forward to EPEL 10! More work for me, yay! Just a few questions - I would have looked them up in the meeting log, but it's not linked. > * AGREED: All packages currently included in ELN Extras will have > an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51) Is there a list of these packages available somewhere? > * AGREED: We will mass-create empty branches for EPEL 10 and will > work towards a better solution for EPEL 11 (@sgallagh:fedora.im, > 16:51:54) I hope you will not create epel10 branches for *all* packages in Fedora. Which packages *will* get an epel10 branch auto-created? > * INFO: Investigation topic: Drop ELN Extras in favor of starting > EPEL 11 soon after EPEL 10, backed by ELN until branching. > (@sgallagh:fedora.im, 16:56:06) This sounds great! ELN Extras has always been confusing to me. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS-UP] Upcoming Rust SIG mini-mass-rebuild
On Mon, May 20, 2024 at 9:29 PM Fabio Valentini wrote: > > Hi all, > > As discussed in the Fedora Rust channel on Matrix, I am planning to do > a mini-mass-rebuild of all Rust applications (that are co-maintained > by the Rust SIG), likely by the end of this week. I estimate that it > will involve just shy of 200 packages per branch. This is now done. The updates are in bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2024-c4bf73eb40 https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce2936b568 https://bodhi.fedoraproject.org/updates/FEDORA-2024-40ee18b2e7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-74745ddb2a I have included some additional (non rust-*) packages, including some GNOME applications (gnome-tour, snapshot, loupe, librsvg2). The EPEL9 builds have only picked up security fixes but not the better debuginfo, since that change has not yet landed in RHEL 9's Rust toolchain. A quick check shows that debuginfo seems to be 10-15 MB larger after the toolchain changes that landed in the package for Rust 1.78 in Fedora. So it looks like debuginfo should indeed be more complete now - and hopefully backtraces should now be on par with backtraces generated by binaries that were built with the "official" upstream Rust toolchain. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon
On Sat, May 25, 2024 at 12:18 PM Fabio Valentini wrote: > > Hi all, > > The Multimedia SIG has been working on rebasing GStreamer from 1.22 to > 1.24 in Fedora 40. The update has now been submitted to bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aa4a3bbf0 I've set high limits for stable karma to make sure the update doesn't get pushed to stable too quickly. Please let us know if there are any GStreamer-related issues. The Multimedia SIG and some GStreamer upstream devs are in #multimedia:fedoraproject.org on matrix. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon
Hi all, The Multimedia SIG has been working on rebasing GStreamer from 1.22 to 1.24 in Fedora 40. We requested an exception to the Updates Policy, which was granted by FESCo: https://pagure.io/fesco/issue/3204 This ticket also has more background why updating from 1.22 to 1.24 is desirable. The builds for GStreamer 1.24 itself are already done in a side-tag, and I will handle the necessary rebuilds (apparently things need to be rebuilt for the gstreamer-plugins-bad 1.22 -> 1.24 update): - caja-extensions - cheese - fractal - gnome-sound-recorder - gnome-subtitles - gtk4 - libva-nvidia-driver - nheko - pitivi - qt5-qtmultimedia - qt5-qtwebkit - qt6-qtmultimedia - snapshot - webkit2gtk4.0 - webkitgtk - wxGTK Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to unretire and rename pyftpdlib
On Fri, May 24, 2024 at 2:48 PM Kevin Kofler via devel wrote: > > Sandro wrote: > > I was probably overthinking this. In practice it will turn out to be a > > new package submission indeed. Moreover, the last remaining active > > branch of the retired package (F38) is now EOL. > > > > I've submitted the review [1] without any Obsoletes. > > Since we support upgrades from Fedora n to n+2, there SHOULD be Obsoletes in > place until at least the F40 EOL. I would recommend just keeping the > Obsoletes forever. Why? The only thing that is being renamed as part of the unretirement is the *source* package. Obsoletes and Provides have zero effect for those. So not adding them is correct here. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
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? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS-UP] Upcoming Rust SIG mini-mass-rebuild
Hi all, As discussed in the Fedora Rust channel on Matrix, I am planning to do a mini-mass-rebuild of all Rust applications (that are co-maintained by the Rust SIG), likely by the end of this week. I estimate that it will involve just shy of 200 packages per branch. The motivation for a mini-mass-rebuild is two-fold: 1. Until very recently, the Rust standard library (shipped as a static archive by the "rust" package) was accidentally shipped with stripped debuginfo, which resulted in Rust applications that linked the standard library to have incomplete debuginfo - and as a result, they produced incomplete backtraces for any stack traces that involved the Rust standard library. This has been fixed since rust 1.78, but applications need to be rebuilt to pick up this improvement. 2. I regularly rebuild applications for "major" / "high priority" security issues in Rust crates, but there are a few accumulated "minor" / "low priority" security issues where I didn't yet have the time to rebuild the affected applications against the library versions that contain the necessary fixes. A mini-mass-rebuild would take care of all of these at the same time. I plan to only rebuild Rust applications that are associated with the Rust SIG (i.e. packages "rust-*"), but no other packages (for example, firefox, thunderbird, or librsvg2). If any maintainers of packages that contain Rust code but that are not co-maintained by the Rust SIG would like their packages to be included in the mini-mass-rebuild as well, just let me know and I'll add them to my list. Fabio PS: Packages that build with vendored Rust dependencies (there are a handful of them, and most are not co-maintained by the Rust SIG) would only benefit from better debuginfo / backtraces, but not from security updates (that would require manually updating the vendor tarball), which is why I will not include them in the mini-mass-rebuild. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: [Input Requested] Ending support for i686 builds of Node.js
On Thu, May 16, 2024 at 4:24 PM Stephen Gallagher wrote: > > On Tue, May 14, 2024 at 3:47 PM Fabio Valentini wrote: > > > > On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher > > wrote: > > > > > > Do you think that's worth a separate Change from the Node.js 22 Change > > > I already filed? I can amend that (and ask FESCo to re-vote based on > > > new information). > > > > I think the change is significant enough, yes. > > Having a separate change would lead to more visibility, but I think > > just amending the existing Change and having FESCo re-approve would be > > fine too. > > > > Looks like we can avoid this question for a bit longer. Node.js 22.2.0 > appears to have fixed the incompatibility with i686 builds. Phew. Even better! Thank you for looking into it. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek wrote: > > 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). 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. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrading Xwayland to version 24.1.0 in Fedora 40
On Wed, May 15, 2024 at 6:23 PM Leigh Scott wrote: > > > On Wed, May 15, 2024 at 4:31 PM Olivier Fourdan > wrote: > > > > Not directly related, but hopefully not entirely off-topic: > > Are there plans to update the xorg-x11-server package itself to the > > new stable branch too? > > > > It's been stuck on the 1.20.14 release for a long time (on the last > > release from the 1.20 branch from 2021 - admittedly, with a lot of > > backports). > > But the last stable release of xorg-server (21.1.13) was just a month ago. > > > > Fabio > > Updating the xorg abi would mean retirement for nvidia 340xx and 390xx. Does this mean "I'm against it" or "it would involve retiring two legacy NVidia driver packages"? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Wed, May 15, 2024 at 2:02 PM Miro Hrončok wrote: > > On 15. 05. 24 13:31, Vít Ondruch wrote: > > I am saying that Python is bad example and nobody should follow it. > > I respectfully disagree. The LLVM maintainers think it is a good example worth > following. So did the NodeJS maintainers. Name-versioning all the components > makes things so much easier for the maintainers. Right - IMO the Python stack is the *best* example of how to provide multiple versions of something in Fedora, and for how transitions to new major versions are handled in Rawhide. (And any remaining Python vs. Python 3 confusions are an orthogonal problem.) Being able to use both newer and older versions of Python on different branches of Fedora is *awesome*, for example for running tests against different Python versions with tox. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrading Xwayland to version 24.1.0 in Fedora 40
On Wed, May 15, 2024 at 4:31 PM Olivier Fourdan wrote: > > Hi all, > > Today was released Xwayland 24.1.0, a new stable branch of Xwayland. Not directly related, but hopefully not entirely off-topic: Are there plans to update the xorg-x11-server package itself to the new stable branch too? It's been stuck on the 1.20.14 release for a long time (on the last release from the 1.20 branch from 2021 - admittedly, with a lot of backports). But the last stable release of xorg-server (21.1.13) was just a month ago. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher wrote: > > Do you think that's worth a separate Change from the Node.js 22 Change > I already filed? I can amend that (and ask FESCo to re-vote based on > new information). I think the change is significant enough, yes. Having a separate change would lead to more visibility, but I think just amending the existing Change and having FESCo re-approve would be fine too. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Tue, May 14, 2024 at 9:33 PM Stephen Gallagher wrote: > > On Mon, May 13, 2024 at 8:21 AM Fabio Valentini wrote: > > > > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher > > wrote: > > > > > > Upstream Node.js has not supported the i686 architecture officially > > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > > > that v8 will no longer build at all on that architecture. > > > > > > I'm not particularly willing to go to any great lengths to keep it > > > alive on i686, but I want to know if there's anyone out there who is > > > *desperately* in need of it in Fedora. > > > > Most (all?) nodejs "library" packages were retired, right? > > > > And even if there are still some of them around, most of them should > > be "noarch"? In that case, they shouldn't need adaptations, since koji > > now no longer schedules noarch builds to run on i686. > > But those nodejs packages that are not noarch (however many of them > > are still in Fedora) will need ExcludeArch: i686. > > > > However, another problem might arched non-nodejs packages that need > > nodejs at build-time. It looks like there's a bunch of packages that > > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, > > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these > > still build on i686, but some might not be able to disable the nodejs > > BR, so they would need to stop building on i686 too. > > > > I've looked through most of these and they generally seem to be either > noarch or else using one of %nodejs_arches or %java_arches for their > BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude > i686 and %java_arches already does so. That sounds good to me, but it doesn't really answer my question: Those packages dropping i686 might cause follow-up issues in *their* dependent packages, and so on. If they are leaf packages, that's not an issue, but dropping architecture support is a breaking change that needs to be coordinated. So what you're *really* saying is that you will drop i686 from %nodejs_arches? I think that has a big enough (and possibly ill-defined) scope that it would qualify as a Change. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Mon, May 13, 2024 at 8:38 PM Vitaly Zaitsev via devel wrote: > > On 13/05/2024 13:24, Nils Philippsen wrote: > > If I’m not off track, renaming the existing version to “gimp2” would at > > least make people install it as an update to “gimp-2.10.x” without any > > real benefit to them. And it would make ”gimp” jump to version 3 which > > is wildly different > > Fedora is a bleeding edge distribution. All packages should be updated > to the latest releases. > > > and would probably go against package > > compatibility guidelines if done in Fedora <= 40 > > Major updates in stable Fedora releases are prohibited by the Updates > Policy[1]. > > [1]: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ This is why the current "gimp version 3 is a new package" approach works better for stable branches: Existing users don't get the update, but can manually opt-in for testing. For rawhide (at least as soon as it's reasonable to do so), the thing can be reversed - package gimp v3 as "gimp" and move v2 to a "gimp2" package, so that users *do* get the upgrade at some point. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: gdk-pixbuf removing several icon loaders
On Mon, May 13, 2024 at 8:36 PM Michael Catanzaro wrote: > > Hi, > > gdk-pixbuf 2.42.11 has dropped support for several uncommon image > formats. This is causing several applications to crash in Fedora > rawhide [1][2]. (The change also got backported to F40 and F39, but > I've reverted it there.) > > Benjamin Gilbert has proposed reenabling the removed loaders [3], but > this is not likely to be accepted upstream. So he's currently planning > to package the removed loaders for Fedora in a separate package. You'll > be able to depend on these if needed to avoid crashing, but please do > so only if you really need to, since the goal of removing the extra > loaders is to reduce attack surface. (Unfortunately gdk-pixbuf is a > fairly risky dependency: many applications require it, but it's not > very safe.) Most applications should use modern image formats instead. Just out of curiosity, would glycin be a better mechanism than gdk-pixbuf for loading "untrusted" images / "unsafe" image formats? Its loaders are sandboxed via SECCOMP and support for most image formats is implemented in Rust (except HEIF and JPEG-XL - they use the C reference implementations). (It looks like the Rust "image" crate doesn't - yet - support some obscure image formats like XPM, so it wouldn't help in this particular case, though.) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On Fri, May 10, 2024 at 11:29 AM Miro Hrončok wrote: > > On 10. 05. 24 10:55, Miroslav Suchý wrote: > > Hot news: > > > > SPDX v3 has been published. The biggest change for us is that license > > expression allows lowercase operators (and, or, with). This got into the > > specification because of your (Fedora maintainers) feedback! > > So we can now have packages with uppercase AND/ORs and packages with lowercase > and/ors and we can no longer quickly recognize SPDX expression by observing > uppercase AND/ORs? > > That does not sound like improvement to me :/ I agree, this is just making things more confusing. Can we at least still recommend to use the AND / OR / WITH capitalization for Fedora license tags, even if the lower-case ones are technically considered valid now? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On Mon, May 13, 2024 at 3:23 PM Vít Ondruch wrote: > > > Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a): > > * Switch to python-style compat/main packages. In order to make the > packaging more > consistent between the main package (e.g. llvm) and the compat package (e.g. > llvm18), > we would retire the un-versioned dist-git for llvm, and create a new > versioned dist-git > for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then > designate one > of these as the 'main version', and that version would produce binary rpms > that look > like the current main package (i.e. llvm-libs instead of llvm19-libs). > > Ehh? I guess? I don't think this buys us that much. > > * Invert the order of compat/main packages. Instead of having the compat > package be > the old version, and the main package be the new version, we would have the > compat package > be newer and the main package be older. This would allow us to introduce a > new version of > llvm without impacting other packages that depend on the main version of LLVM. > > I don't like this idea, it makes things harder to reason about and > doesn't actually solve any problems. > > > I concur with Neal here. > > I we were living in ideal world, we would have just one `llvm` package. Since > we are not living in ideal world, it makes sense to have some compat > versions. But we should try to get as close as possible to ideal world. > Versioning packages by default goes against that goal, because it encourages > sticking to some specific version for no particular reason. For the special case of LLVM, I disagree here. Some projects are just not compatible with newer LLVM versions until upstream moves first, and that can take time. So I don't think that counts as "sticking to some specific version for no particular reason", it's "upstream doesn't support LLVM X at all yet, they only support LLVM X-1 for now". I have never seen a Fedora package that uses an LLVM compat package "for no particular reason". Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Input Requested] Ending support for i686 builds of Node.js
On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher wrote: > > Upstream Node.js has not supported the i686 architecture officially > since Node.js 10.x (released in 2018). As of Node.js 22, it appears > that v8 will no longer build at all on that architecture. > > I'm not particularly willing to go to any great lengths to keep it > alive on i686, but I want to know if there's anyone out there who is > *desperately* in need of it in Fedora. Most (all?) nodejs "library" packages were retired, right? And even if there are still some of them around, most of them should be "noarch"? In that case, they shouldn't need adaptations, since koji now no longer schedules noarch builds to run on i686. But those nodejs packages that are not noarch (however many of them are still in Fedora) will need ExcludeArch: i686. However, another problem might arched non-nodejs packages that need nodejs at build-time. It looks like there's a bunch of packages that "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird, RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these still build on i686, but some might not be able to disable the nodejs BR, so they would need to stop building on i686 too. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On Mon, May 13, 2024, 12:34 Daniel P. Berrangé wrote: > On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote: > > On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski < > > domi...@greysector.net> wrote: > > > > > On Monday, 13 May 2024 at 01:00, Neal Gompa wrote: > > > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto > wrote: > > > > > > > > > > > > > > > > > > > > https://src.fedoraproject.org/rpms/gimp3 > > > > > > > > > > > > > What the heck? This should have been gimp2 for the old version, not > > > > gimp3 for the new version... > > > > > > Also, how did this pass review? > > > > > > License:LGPLv3+ > > > > > > And I'll answer myself: it hasn't or at least I can't find any review > > > ticket. > > > > > > Nils, could you explain how this package ended up in Fedora? > > > > Standard procedure, everything seems to be in order: > > > > https://pagure.io/releng/fedora-scm-requests/issue/62152 > > > > The review exception is valid because it's an alternative version of an > > existing package, and Nils is also the maintainer of the existing > package. > > It that exception automatic ? I thought it had to be explicitly > requested from FPC ? eg in > > > https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure > > It says: > > "The FPC can grant exceptions to the normal package review process. >This may happen, for instance, if a large number of similar packages >are being submitted at once or if a package is being updated to a >new major version while the old version is being kept in the >distribution with a different name. >.. >Just file a ticket here, set the component to "Review Process Exception" >and explain (with detail) why you're requesting the exemption and the >committee will consider it in the next meeting. " > > So gimp3 falls under the 2nd example documented there, but still sounds > like an FPC ticket was needed ? > The wiki is outdated. All documentation from FPC has been moved to docs.fp.o. The exceptions are documented here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process These cases are treated as "automatically approved" and don't need package review nor FPC approval. Fabio > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Monday, 13 May 2024 at 01:00, Neal Gompa wrote: > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto wrote: > > > > > > > > > > > > https://src.fedoraproject.org/rpms/gimp3 > > > > > > > What the heck? This should have been gimp2 for the old version, not > > gimp3 for the new version... > > Also, how did this pass review? > > License:LGPLv3+ > > And I'll answer myself: it hasn't or at least I can't find any review > ticket. > > Nils, could you explain how this package ended up in Fedora? > Standard procedure, everything seems to be in order: https://pagure.io/releng/fedora-scm-requests/issue/62152 The review exception is valid because it's an alternative version of an existing package, and Nils is also the maintainer of the existing package. While most people prefer that alternative versions carry a "compat" suffix (i.e. the new version is the one without the suffix, and the old version has the suffix), this is - contrary to popular belief - not actually required or even mentioned in the packaging guidelines. Fabio > Regards, > Dominik > -- > Fedora https://fedoraproject.org > Deep in the human unconscious is a pervasive need for a logical universe > that > makes sense. But the real universe is always one step beyond logic. > -- from "The Sayings of Muad'Dib" by the Princess Irulan > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 swaps
On Tue, Apr 23, 2024 at 1:10 AM Kan-Ru Chen wrote: > > Hi all, > > I have 3 packages awaiting reviews. I'm happy to exchange. > > First is a new IBus input method (code includes bits of C and Python): > > ibus-array: https://bugzilla.redhat.com/show_bug.cgi?id=2275556 > > The other two are trivial rust packages that I need for upcoming libchewing > release: > > rust-xflags-macrios: https://bugzilla.redhat.com/show_bug.cgi?id=2276537 > rust-xflags: https://bugzilla.redhat.com/show_bug.cgi?id=2276539 Hello! I see now that you have withdrawn the two Rust package reviews. Do you no longer need them? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Is glibc32 retired?
On Fri, May 3, 2024, 09:34 Florian Weimer wrote: > I didn't have a dist-git token for fedpkg, so retiring failed after > doing some work the first time. Is the package actually retired? > It looks like the retirement was successful The dist-git token is only necessary for one API call - disabling the "monitoring" setting. But that was already disabled for this package, so it wouldn't have changed anything. > This command > > koji list-history --package=glibc32 > > does not show any recent activity. I would expect something to untag it > from the buildroot. > This should happen when the retirement is processed during the next rawhide compose. > (Bonus question: can we retire the package from Fedora 40, too?) > No. Retirements can only happen until the start of the final freeze. Fabio > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
On Mon, Apr 29, 2024 at 1:28 PM Richard W.M. Jones wrote: > > On Sat, Apr 27, 2024 at 10:41:59PM +0200, Julian Sikorski wrote: > > Hello, > > > > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > > mame-0.265-1.fc41 is already built against it so I only need to > > build mame-0.265-1.fc40.1. Can it be done using %autorelease? > > I don't think anyone answered your actual question which is ... > > Release: %autorelease -e 1 No, this will make a Release like 2.1.fc40 - which is not what's needed (which would be 1.fc40.1). So it doesn't work because -e adds a component *before* the dist-tag, *and* because the main number is still incremented. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
On Mon, Apr 29, 2024 at 11:17 AM Kevin Kofler via devel
wrote:
>
> Michael J Gruber wrote:
> > A minor bump (as in %{?dist}[.]) only comes into play
> > if a "lower" branch needs to move forward without creating a version
> > ahead of a "higher" branch. And (independent of autorelease) you cannot
> > do that unless you use divergent git branches and cherry-picks in
> > dist-git, in which case "version" makes sense per branch only anyways.
>
> But Release MUST maintain the upgrade path from one release to the next.
No, that's just wrong.
The "upgrade path" (wrt/ NVRs) is no longer enforced across release boundaries.
AFAIK, all supported release-upgrade methods now use distro-sync or
something equivalent, so NVR-based "upgrade path" is just not
important any more.
Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
On Sat, Apr 27, 2024 at 11:51 PM Sandro wrote: > > On 27-04-2024 22:41, Julian Sikorski wrote: > > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > > mame-0.265-1.fc41 is already built against it so I only need to build > > mame-0.265-1.fc40.1. Can it be done using %autorelease? > > Make an empty commit: > > git commit -m 'Rebuild for mame' --allow-empty This is not the answer to the question. It will cause a normal Release bump. AFAIK using rpmautospec, it's not possible to do post-dist.tag .1 bumps. But it's also not really important either, since release-upgrades do distro-syncs. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Heads-up] More spring cleaning: orphaning bamf
On Mon, Apr 22, 2024 at 11:12 PM Michel Lind wrote: > > Dear all, > > I've been maintaining bamf for... quite some time, and don't actually have a > need for it anymore. > > It's pretty much in maintenance mode upstream as well. > > I've built the last stable version in Rawhide to close > https://bugzilla.redhat.com/show_bug.cgi?id=2055853 > > but will probably not build for stable releases, I'll let the new > maintainer(s) > handle that. > > Right now it looks like only plank actually uses it; its maintainer is cc:ed > > $ fedrq whatrequires bamf > bamf-daemon-0.5.5-8.fc40.x86_64 > bamf-devel-0.5.5-8.fc40.i686 > bamf-devel-0.5.5-8.fc40.x86_64 > plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 > plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 > > So if you use plank, or otherwise have a need for this, feel free to take > this over. The story with plank is a bit weird ... The last release was in 2019, and elementary OS forked it some years later, because upstream development was pretty much dead. At that point, I was a (co-)maintainer of the plank package, and switched the package to build from the elementary fork, because it had fixes and support for some new stuff. However, elementary has been developing their own dock from scratch (with eyes on eventual Wayland support), and the plank project on launchpad actually looks more active again :| So maybe the package should be switched back to the original upstream when / if the new elementary Dock is ready (it's not yet) ... Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 10:43 PM Fabio Valentini wrote: > > On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz > wrote: > > > > You're welcome. rust-appdirs got in and I believe is waiting to be > > available in the repositories. > > No, it's waiting for *you* to actually import the package. :) > Just getting the package review ticket approved does nothing on its own. Sorry, I just saw that you imported and built the package for Rawhide. Congratulations for getting your first package into Fedora then! :) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz wrote: > > You're welcome. rust-appdirs got in and I believe is waiting to be > available in the repositories. No, it's waiting for *you* to actually import the package. :) Just getting the package review ticket approved does nothing on its own. > Meanwhile, I try to get another dependencies in at: > https://bugzilla.redhat.com/show_bug.cgi?id=2276462 > https://bugzilla.redhat.com/show_bug.cgi?id=2276290 I will try to get to those soon, but I can't promise when I will have the time to do so. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Mon, Apr 22, 2024 at 5:13 PM Peter Robinson wrote: > > I am aware of a few of the above I'm listed against that my deps no > longer requre (eg passwd) but I hadn't got around to working out what > else depended on them to retire without possibly breaking something > else, overall happy for them to be retired as part of the mass > retirement if there's no other deps. Whoops, sorry about that - I constructed the "packages per maintainer" list manually, apparently I was too tired to check that everybody included in the table is also included in the per-maintainer lists :( > There's also some that are deps on things still in progress like > rust-rustls-pki-types (rhbz 2272351 has dep details), not sure how to > tag those so I don't have to do more work to repackage them. Thanks for checking! FYI, rustls-pki-types is no longer a leaf package since I updated rustls / reqwest to newer versions. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Fri, Apr 19, 2024 at 5:37 PM Davide Cavalca wrote: > > On 2024-04-11 06:26, Fabio Valentini wrote: > > - dcavalca (33): rust-base-x, rust-benfred-read-process-memory, > > rust-cap, rust-combine, rust-concolor, rust-cpc, > > rust-curve25519-dalek, rust-custom_error, rust-escape_string, > > rust-esphome, rust-exitfailure, rust-gmp-mpfr-sys, rust-hyperlocal, > > rust-local-encoding, rust-local_ipaddress, rust-madvr_parse, > > rust-memcached-rs, rust-minimad, rust-names, rust-netstat2, > > rust-os-release, rust-pathsearch, rust-random, rust-rusttype, > > rust-serde_bser, rust-smallstr, rust-rust-strict, rust-subprocess, > > rust-temp_testdir, rust-termwiz, rust-tokio-compat, rust-typed-builder > > Some of these (e.g. rust-cpc, rust-names) publish binaries; it'd > probably be good to exclude those from leaf cleanup (or bucket them > separately, as it's not uncommon for packages with binaries to be > leaves). The rest are part of various in-progress packaging efforts > (e.g. termwiz is for wezterm) and I'd rather keep them around for > another cycle while these move forward. Thanks! Sorry about that, I thought I had excluded all packages that provide applications, but apparently I missed some. Though I don't think cpc and names were specifically packaged for their executables, but as dependencies for something else? As for termwiz / wezterm, do you plan to reopen / resubmit the package review requests that have been stalled out? Thanks, Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning my packages: elvish, git-delta & dependencies
On Fri, Apr 19, 2024 at 9:06 PM Janet Black wrote: > > Hi, I do not have the time to contribute packages to Fedora these days. > > I am orphaning the following packages under my maintainership: > - golang-github-elves-elvish > - golang-github-xiaq-persistent > - rust-box_drawing > - rust-git-delta I'll take the two Rust packages for now. Thank you for the notification! Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024 at 3:10 PM Zbigniew Jędrzejewski-Szmek wrote: > > > Because this is written in Rust instead of Python, you will need a > > build variant for *every* Python interpreter shipped in Fedora. > > No, just one one, at any given time. Assuming that the marshalparser package can parse pyc files from newer Python versions, I don't think this is necessary. > Or in other words, it's the same as any application using Python in > Fedora: it is built against some version of Python, usually the > default one. > > (pyo3 has support for linking to the stable python abi, which > theoretically would allow the program to be able to run with python > versions newer than the one against which it was built. I didn't look > at the details, so I don't know what would be needed to link it like > that and whether that'd actually make things better for us.) The functionality for building + linking only with the stable / limited "abi3" CPython ABI is only relevant for *extension modules*, i.e. Python modules that contain a native extension written in Rust. This is not the case here - it's a Rust program that calls into CPython (as opposed to the Python interpreter loading a native extension module, which is effectively a "plugin" which is not linked to libpython directly). add-determinism is linked *directly* to libpython3.x.so, so it is only ever compatible with the major version of the Python interpreter that it was built against. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Wed, Apr 17, 2024, 08:45 Tim Landscheidt wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > > […] > > >> - use dynamic buildrequires to detect what plugins are needed > > > My problem is that the binary is linked to the libpython3.12.so shared > > library… The detection part is easy, the hard part is how to have the > > binary work when the shared lib is not installed. > > Quick 'n' dirty: Have two binaries, unconditionally call > add-determinism-python for *.pyc files, either from > add-determinism or the BRP macro (which essentially should > be called when %__brp_python_bytecompile is called?), rely > on the packager to build-require add-determinism-python or > require that from python3-devel (the missing binary should > fail the build otherwise). > Something like this could be even made automatic. - split Python-specific functionality into a separate binary and subpackage of add-determinism - add only add-determinism to the default buildroot - add "Requires: (add-determinism-python if python3)" to add-determinism That way the pyc processing functionality would only be pulled in iff python3 is already getting installed by something else. Fabio > Tim > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek wrote: > > Yes. But actually I think Rust is the optimal choice here. Writing > this in Python would be possibly slightly nicer, but we don't want > to pull the interpreter and packages into the buildroot. Python > also has the problem (challenge?) that it needs to be bootstrapped > once per year. The less packages are involved in the bootstrap, the > easier it is. And if the brp was written in Python, we'd need to > deal with that, and it would probably increase the number of builds > which are done without the cleanup. Having this as an indepedent > binary avoids some of the issues with bootstrap. I think Rust *would* be a good choice here ... BUT add-determinism uses pyo3 to link to CPython, so it pulls in python3-libs anyway. So you get the downsides of pulling in Python without the upsides of using Rust ... Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Rust] Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 9:09 PM Michel Lind wrote:
>
> > | rust-atomic-traits | 2022-09-02 | 587 | salimma
> >|
> Still trying to package mmtk, please keep this one for now
Then please follow up, the review request for mmtk was closed due to inactivity:
https://bugzilla.redhat.com/show_bug.cgi?id=2040994
> > | rust-signal | 2023-02-23 | 413 | salimma
> >|
> Not sure about this one. Looks like psutil depends on it, and ytop
> depends on psutil, but ytop is almost 4 years old... probably retire it
https://bugzilla.redhat.com/show_bug.cgi?id=2048155
Looks like pipewire bindings version < 0.7 depended on this, but
dropped the dependency with v0.7.
> > | rust-sptr| 2023-03-28 | 380 | salimma
> >|
> This is needed by portable-atomic which is needed by pyo3, right?
sptr is a dev-dependency for portable-atomic only, and portable-atomic
tests can no longer be run from the published tarbals.
It might be ok to drop sptr.
> > | rust-xcb | 2023-05-10 | 337 | salimma
> >|
> We can kill this I guess. Death to X
Looks like this used to be a dependency of x11-clipboard <0.7, but no
longer is as of v0.7.0.
> > | rust-powierza-coefficient| 2023-06-16 | 300 | salimma
> >|
> I wonder what used it in the past. crates.io now only lists kn ... so
> yeah kill it
This was packaged for nu-command, but the dependency has since been dropped:
https://bugzilla.redhat.com/show_bug.cgi?id=2211278
> > | rust-wayland-commons | 2024-01-02 | 100 | salimma
> >|
> Looks like wayland-{client,server} no longer needs this (since > 0.29).
> Kill.
Agree, this crate seems to have been dropped from wayland-rs.
> > | rust-nom-supreme | 2024-01-04 |98 | salimma
> >|
> Can't find what's actually using it, maybe kill
This was packaged for wax:
https://bugzilla.redhat.com/show_bug.cgi?id=2174116
And was was packaged for nu-command:
https://bugzilla.redhat.com/show_bug.cgi?id=2174146
But wax no longer depends on nom-supreme as of v0.6.0.
> > | rust-vec1| 2024-01-04 |98 | salimma
> >|
> Ditto - not sure what I needed this for, probably dropped upstream
Same here:
https://bugzilla.redhat.com/show_bug.cgi?id=2174097
This used to be a dependency of wax, but it was dropped as of v0.6.0
> > | rust-rlimit | 2024-01-17 |85 | salimma
> >|
> Ditto
Can't tell - the review request isn't marked as blocking anything.
https://bugzilla.redhat.com/show_bug.cgi?id=2258271
At least it's a dependency of "bsdutils":
https://crates.io/crates/bsdutils
So maybe it was part of the coreutils dependency tree for some of the
missing uu_* tools?
> > | rust-base32 | 2024-01-20 |82 | salimma
> >|
> rbw needs this, still in progress
Noted, thank you for checking!
Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Rust Stack Spring Cleaning - 2024 Edition
On Thu, Apr 11, 2024 at 7:45 PM Ben Beasley wrote: > > The rust-circular-buffer crate was packaged as a dependency for bpftop, > https://github.com/Netflix/bpftop. > > I won’t necessarily be packaging bpftop myself, but I know several > parties are interested in doing so, and I expect it will happen soon one > way or the other. Thanks! I forgot about that, it's good to have this in writing. > A few existing dependencies still need to be updated first: > > Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 > with crate(anyhow/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libbpf-rs/default) >= > 0.23.0 with crate(libbpf-rs/default) < 0.24.0~) > Problem 3: nothing provides requested (crate(libbpf-sys/default) >= > 1.4.0 with crate(libbpf-sys/default) < 2.0.0~) > Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with > crate(ratatui) < 0.27.0~) > Problem 5: nothing provides requested (crate(ratatui/crossterm) >= > 0.26.1 with crate(ratatui/crossterm) < 0.27.0~) > Problem 6: nothing provides requested (crate(tui-input/default) >= > 0.8.0 with crate(tui-input/default) < 0.9.0~) I can update anyhow tomorrow, that should be a simple update. Michel said he'll be looking at libbpf-rs / libbpf-sys soon. ratatui can be updated too, though it might require a compat package for the current version tui-input seems to be a new dependency. Thank you for checking, Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rust Stack Spring Cleaning - 2024 Edition
Hello Rust packagers, I'm continuously working on reducing unnecessary accumulation of cruft in the Rust package stack in Fedora, and I have been keeping track of unused library packages for almost three years now. Some of these packages have been unused leaves for over two years! I will again start being more proactive with orphaning / retiring affected packages where I am the primary maintainer, starting incrementally from the packages which have been unused for the longest time - unless I know of a reason to keep a specific package, for example: - something that depends on the package is still going through package review - the package was updated to a "breaking" release and a compat package was created, and now the "main" package is not depended on while the compat package is in use If you know of a reason why a leaf package where I am the primary maintainer should not be retired, please let me know, and I will exclude it from the list. For packages where I am *not* the primary maintainer, I need help: - Is this package still required for something that I don't know about, or can it be dropped? - Was it added as a dependency for something else, but packaging this "something else" was abandoned? - Was it needed at the time, but is the library no longer needed now? Keeping unused packages around only makes maintenance of the Rust stack more difficult due to the more "dense" dependency graph that needs to be considered when pushing "breaking" changes. Over the past year or so, the number of Rust packages in Fedora has grown by almost 50% from about 2200 to over 3000, which is making this issue worse. Full report included below (view in monospace font for correct formatting). Thank you for your help, Fabio +--++---+--+ | Package | Leaf since | Leaf days | Maintainer | +--++---+--+ | rust-curve25519-dalek| 2021-11-18 | 875 | dcavalca | | rust-gstreamer-editing-services | 2021-11-18 | 875 | atim | | rust-gstreamer-player| 2021-11-18 | 875 | atim | | rust-rand_jitter | 2021-11-18 | 875 | jistone | | rust-rand_os | 2021-11-18 | 875 | jistone | | rust-tower-test | 2021-11-18 | 875 | decathorpe | | rust-tower-util | 2021-11-18 | 875 | decathorpe | | rust-partial-io | 2022-02-06 | 795 | decathorpe | | rust-minimad | 2022-02-18 | 783 | dcavalca | | rust-libhandy| 2022-02-20 | 781 | decathorpe | | rust-tiger | 2022-02-20 | 781 | decathorpe | | rust-rand_hc | 2022-02-21 | 780 | jistone | | rust-benfred-read-process-memory | 2022-02-27 | 774 | dcavalca | | rust-custom_error| 2022-02-27 | 774 | dcavalca | | rust-madvr_parse | 2022-02-27 | 774 | dcavalca | | rust-os-release | 2022-02-27 | 774 | dcavalca | | rust-strict | 2022-02-27 | 774 | dcavalca | | rust-subprocess | 2022-02-27 | 774 | dcavalca | | rust-libxml | 2022-04-07 | 735 | decathorpe | | rust-snake_case | 2022-04-25 | 717 | decathorpe | | rust-openat-ext | 2022-04-28 | 714 | walters | | rust-log-mdc | 2022-05-05 | 707 | decathorpe | | rust-cargo-manifest | 2022-05-06 | 706 | laiot| | rust-digest_auth | 2022-05-06 | 706 | laiot| | rust-binascii| 2022-05-10 | 702 | saluki | | rust-inlinable_string| 2022-05-10 | 702 | decathorpe | | rust-ubyte | 2022-05-10 | 702 | decathorpe | | rust-email-encoding | 2022-05-17 | 695 | saluki | | rust-tabular | 2022-05-23 | 689 | jbtrystram | | rust-async-mutex | 2022-06-01 | 680 | decathorpe | | rust-awc | 2022-06-01 | 680 | decathorpe | | rust-infer | 2022-06-15 | 666 | decathorpe | | rust-escape_string | 2022-07-08 | 643 | dcavalca | | rust-actix | 2022-07-18 | 633 | decathorpe | | rust-envsubst| 2022-07-18 | 633 | jlebon | | rust-esphome | 2022-07-18 | 633 | dcavalca | | rust-fail| 2022-07-18 | 633 | jlebon | | rust-fn-er
Re: convert everything to rpmautospec?
On Thu, Apr 11, 2024 at 12:39 PM Leon Fauster via devel wrote: > > Am 08.04.24 um 08:01 schrieb Miro Hrončok: > > On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote: > >> > >> Not all commits correspond with a new release downstream, and not all > >> commit messages are relevant to the end user to be part of the change > >> log. For example, commits related with increasing gating test coverage > >> efforts, or setting up gating.yaml itself. Another example is linting > >> setting and/or configurations. How is that handled with autochangelog? > >> Can we tell it to skip certain commits? Or should we include it all? > > > > Put [skip changelog] in the commit message. > > > > https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries > > > > May be an [add rpmchangelog] would be more appropriate for some > scenarios, where branching and merging or whatever would clutter > the git log. Would lead to a more curated rpm changelog. Still, > not ideal. As far as I know, merge commits are already excluded automatically. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Tue, Apr 9, 2024 at 6:58 PM Neal Gompa wrote: > > On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote: > > > > > > Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a): > > > > And we already have a significant fraction of packages using > > > > rpmautospec, > > > > > > > > > Actually, could you quantify the "significant fraction"? > > > > 7399 / 23912 = 31%. > > > > How much of it is non-Rust and non-Go? There's ~3000 Rust packages, 99.9% of which use rpmautospec, so you can subtract about 3000 from that number. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: "fedpkg local" builds fail for rust packages
On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch wrote: > > Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a): > > Packaged Rust crates work *fine* for local development as long as you > > are willing to cut yourself off from crates.io. Unlike *every other > > language package manager*, Cargo does not support multiple concurrent > > indexes. This is ultimately the bottleneck, and there's been very > > little interest in resolving this upstream. > > > > Upstream issue: https://github.com/rust-lang/cargo/issues/4883 > > > OTOH, there does not seem to be linked any PR implementing this RFE. All people involved with Rust packaging in Fedora seem to be very disillusioned wrt/ getting stuff upstreamed into cargo. As far as I know, all of us have had very frustrating experiences when trying to work with cargo upstream. Spending a lot of time working on feature development only to be told "we're not interested" is not a good way to spend our (limited) time. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On Mon, Apr 8, 2024 at 3:28 PM Iñaki Ucar wrote: > > So someone wanted to use rpmautospec and was willing to do the work, putting > things together as an opt-in feature. Perfect. > > Now, I don't see any problem if some time later someone revisits the topic > and proposes to go further. I don't see anything unfriendly here. Everything > was set or decided at some point, and nothing could ever be changed if we > don't allow ourselves to change our minds and be free to make new proposals. > > That said, we are also free to reject those proposals, and I'm -1 here. As of > today, I think it's fine as an opt-in feature, and I'm even using it for some > small uncomplicated packages. But I don't think it should be the default with > an opt-out. It is already supposed to be default / preferred since this Fedora 38 Change: https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
