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 | |
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
Re: EPEL9 updates obsoleted
On Sun, Apr 7, 2024 at 10:10 PM Fabio Valentini wrote: > > On Sun, Apr 7, 2024 at 7:06 PM Antonio T. sagitter > wrote: > > > > Hi all. > > > > Can this update be re-activated or i have to rebuild everything? > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab > > I'm not sure how the update got into the "obsoleted" state without > being obsoleted by ... *something*? > It should have been "unpushed", which should allow you to to un-unpush > it, but de-obsoleting doesn't seem to be possible. > > Since the update was created from a side tag, you can't just remove > all builds from the update and add them to another one ... > But tagging the builds into a fresh side tags won't work either (IIUC) > because there already exists and update for these builds :( > > Not sure how this update got into this weird state, but I don't think > there's a way around rebuilding things in a fresh side-tag. > (People who know better than me, please correct me if that is incorrect.) Oh! One thing you *could* try is to untag the builds from the side-tag for the obsoleted update, edit the update to refresh the list of builds, and save an "empty" update. Not sure if that will work though ... Then it would be possible to tag the builds into a fresh side-tag. 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: EPEL9 updates obsoleted
On Sun, Apr 7, 2024 at 7:06 PM Antonio T. sagitter wrote: > > Hi all. > > Can this update be re-activated or i have to rebuild everything? > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab I'm not sure how the update got into the "obsoleted" state without being obsoleted by ... *something*? It should have been "unpushed", which should allow you to to un-unpush it, but de-obsoleting doesn't seem to be possible. Since the update was created from a side tag, you can't just remove all builds from the update and add them to another one ... But tagging the builds into a fresh side tags won't work either (IIUC) because there already exists and update for these builds :( Not sure how this update got into this weird state, but I don't think there's a way around rebuilding things in a fresh side-tag. (People who know better than me, please correct me if that is incorrect.) 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 Sun, Apr 7, 2024 at 9:22 PM Leon Fauster via devel wrote: > > Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek: > > Hi everyone, > > > > I'm revisting the topic of rpmautospec because I was doing some work > > on various packages, and it's annoying that some packages are using > > rpmautospec and others are not. > > > > All my packages have been converted, so in day-to-day work, I don't > > even think about %changelog. When working with other packages, I'll > > forget to update the Relase and/or %changelog. Today I was rebasing > > some pull requests in pagure, and the _only_ conflicts that I had were > > about Release and %changelog. > > > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > >(e.g. when they want to push some fix or separately from other > > work) > > - people submitting pull requests against src.fp.o MAY also > >include a conversion in the pull request and packagers SHOULD > >merge it. > > > > (FTR, 'rpmautospec convert' does the conversion, incl. the commit > > to dist-git. Manual conversion should not be used.) > > > IIRC - EPEL8 is not ready for this? It is. I have been building rpmautospec-enabled packages for EPEL8 for a while. Here's an example that hasn't been garbage collected yet, and you can see intact changelog: https://koji.fedoraproject.org/koji/buildinfo?buildID=2338209 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 Sun, Apr 7, 2024 at 5:48 PM Tom Hughes via devel wrote: > > On 07/04/2024 16:15, Zbigniew Jędrzejewski-Szmek wrote: > > > I think it's time to switch to rpmautospec completely. > > Thus, the proposal: > > - new packages MUST use rpmautospec > > - packagers SHOULD convert their packages > > - provenpackagers MAY convert existing packages > >(e.g. when they want to push some fix or separately from other > > work) > > - people submitting pull requests against src.fp.o MAY also > >include a conversion in the pull request and packagers SHOULD > >merge it. > > -1 for existing packages certainly - none of my git commit logs > are written with the expectation that they will double as package > changelogs so doing so may break the changelog. > > I don't really want it for new packages either but at least > there I would know I needed to use the commit log in that way. It looks like there's a misunderstanding about how "rpmautospec convert" works. The existing changelog (i.e. the contents of %changelog) is moved to a "changelog" file (and replaced with %autochangelog). And only commits made *after* the "changelog" file is created and / or changed are used for generating *new* changelog entries. Changelog entries that predate the rpmautospec conversion are preserved and remain unchanged. All commits that change the "changelog" file cause "stop generating changelog entries starting from this commit", so this mechanism can also be used to amend changelog entries - generate the changelog, fix things, move it into the "changelog" file. 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] dracut update 060 coming to Fedora Rawhide
On Wed, Mar 20, 2024 at 3:23 PM Pavel Valena wrote: > > Hello, > > please $SUBJ, test if you can: > https://src.fedoraproject.org/rpms/dracut/pull-request/54#comment-190538 > > Any feedback is appreciated. I see that this update was now also submitted to Fedora 40, and will likely ship as a zero-day update. Was this intentional (given $SUBJECT)? Not sure if shipping an update for a critical component like this as a zero-day update is a good idea. 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 Sat, Apr 6, 2024 at 12:42 PM Björn Persson wrote: > > Fabio Valentini wrote: > > - Installing rust-*-devel packages on your local system (i.e. outside > > of ephemeral build environments) is not supported. > > - The "rust-*-devel" packages are build system implementation details, > > if you want to say it like that. > > - They are not shipped to users and are not useful for Rust developers. > > - They are *only* intended to be installed in temporary chroots (like > > those set up by mock). > > I don't know enough about Rust to understand how the perfectly normal > usecase of installing libraries as RPM packages has been made so > problematic. I'll just state my strong opinion that packages that > aren't meant for software development should not have "-devel" in their > names. Bascially, this is because of limitations of cargo. It has no support for looking up dependencies in multiple places, only *one* source of dependencies is configurable. By default, dependencies are downloaded from crates.io. We override the "crates.io" source with the directory where Rust crates are packaged for Fedora. Using vendored dependencies works similarly - there, the "crates.io" source is overridden with the directory that contains vendored sources. But there is *no way* to specify *look here, and if it's not there, look elsewhere". If dependencies are not present in the one configured source, cargo just fails. So using packaged Rust crates for development is difficult - since you can't configure cargo to "use dependencies from "/usr/share/cargo/registry" and fall back to downloading from crates.io for things that aren't available". (Side note: The train for using a different suffix than "-devel" has left the station a decade ago. Changing this now is impractical, so the naming bikeshedding is not helping.) 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 Sat, Apr 6, 2024 at 4:45 AM Scott Schmit wrote: > > This perhaps explains why my efforts to use these packages did nothing > but waste my time for days. > > It sounds like you've wasted others' time as well. That's not very > Friendly, and playing nitpicky language lawyer games doesn't change > that, and is also unFriendly. This is about more than just you. Other > people are trying to do things, and you're sitting here saying "too bad, > I don't care, it doesn't work and that's not my problem." If that's not > your intent, that's how it's coming across. > > That's an unacceptable attitude, and I think you need to rethink how > you're approaching this conversation and re-read > https://docs.fedoraproject.org/en-US/project/ from top to bottom. I'm sorry about that. I don't want anybody to feel like they're wasting their time. I really am trying to do my best here, but there are some constraints that I need to work within - both from the upstream cargo side and the RPM packaging reality. I inherited the way we do Rust packaging from my "predecessor" when he stopped contributing to Fedora, I didn't invent things this way. Since I took over maintenance of most Rust packages in Fedora (and the tooling we use to create and maintain them), I tried to push many improvements that make things better for package maintainers. However, we're working with an upstream project that is either indifferent or entirely hostile towards distribution packaging (rust / cargo). Almost all improvements and / or bug fixes that we have asked for in the past years have been either ignored or dismissed as "not our problem". As frustrating as this is, I need to work with what I have, and sometimes that leads to less than ideal outcomes - but please don't blame me for that. > It does not clearly state *anything* you've just now dropped on us. > Also, all RPMs are packages, not all packages are RPMs. For all I know, > "package" could be another way of saying "crate." And just because it's > "intended" to do something doesn't mean "it won't work for anything > else" or "it's not supported if you try to use it for anything else." You are right, this could be stated more clearly. > And I question whether making packages like that is acceptable for > Fedora. The way Rust packages work (and Go packages work very similarly) was signed-off on by FESCo and / or the Packaging Committee, multiple times. If you have a problem with how things work, take things up with those decision bodies. Again, I'm trying to make something that works well here, but I'm trying to do my best given the constraints that we're working within. > The naming convention for packages for the last 25 years as far as I've > ever known has established that "foo-devel" packages provide programming > support files that will allow *me* to build *my own* software using > conventional build tools. > > The way you've described it, they shouldn't be "foo-devel" packages at > all, because they're useless for routine development. Admittedly, the > packaging guidelines don't address this, but I assume this is because > this principle is so obvious that nobody thought it needed to be said. > I mean, it's in the mission statement! The distinction between "-libs" and "-devel" subpackages doesn't really make sense for languages like Rust or Go. There *are* no separately distributed header / development files. The source code *is* the thing that is redistributed for development. I'm not sure if there's a better name for them than "-devel" packages. > It seems to me that these not-"devel" packages should be named > "foo-mock-build-support-for-internal-use-only-and-you-are-on-your-own-if-you-try-to-use-it-for-anything-else". > That would be a whole lot clearer. We can even consider the > ridiculously-long name a feature. Sorry, but this isn't helpful. > You've already said there's no support for using them, so it sounds to > me like they're ineligible for inclusion in RHEL (which involves paid > support), so who cares if it works well in RHEL? You've already said > they don't work well in Fedora either. We support these packages *for building other packages*. The Rust stack is one of the most well-maintained large language stacks in Fedora, with consistently very low numbers of packages that have issues like broken builds or broken dependencies. But RHEL does not include packages for Rust crates *at all* and uses vendored dependencies unconditionally. Which is not an acceptable solution for Fedora for multiple reasons. > > 1. We don't want Rust applications to vendor their dependencies > > I'm trying to write my own software, so what business do you have > telling me what I can do with it? Where's my Freedom? Insert the > Fedora mission statement here (again). ??? I really don't understand what you want to say here. The Fedora rule against bundling packages' dependencies whenever possible has been there for decades (predating Rust as a language). You can do
Re: "fedpkg local" builds fail for rust packages
On Fri, Apr 5, 2024 at 3:16 PM Emanuel Lima wrote: > > I'm not sure this helps, but I maintain a Rust and Go package that builds > fine with fedpkg local. If you want to take a look at the spec: > > https://src.fedoraproject.org/rpms/kata-containers/blob/rawhide/f/kata-containers.spec This is a particularly bad example for a Rust package for two reasons: "fedpkg local" only works because you build with vendored sources (without following the bundling guidelines, i.e. declaring bundled dependencies). The package also builds in a way that does not respect default Fedora compiler flags (see https://bugzilla.redhat.com/show_bug.cgi?id=2167235). 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 Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber wrote: > > So you're saying that those packages are in the repos for everyone but > not meant to be installed by anyone (besides mock chroots), and that is > how and why they are packaged. Yes. That is the best we can do given how cargo + Rust work. > `This package contains library source intended for building other packages > which > use the "xyz" crate.` So the description matches what I said? > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg > mockbuild` it. Does a rebuild from `fedpkg srpm` even work? > > Wow! Sorry to burst your bubble, but "fedpkg local" is an ugly hack (independent of Rust peculiarities). And I am not interested in adding workarounds to the Rust packaging toolchain to support it. "fedpkg mockbuild" and "fedpkg srpm" all work as expected ... > Is there any other set of packages which we package like that? Probably golang ... maybe Haskell, OCaml? > If that is how you do things for the rust eco-system, those "devel" > packages should be clearly distinguished from real development packages, > come with a huge boiler plate "do not install" - or, really, be in a > separate repo if installing them is both worthless and misleading for > any "real" user. CRB for Fedora material. You just pasted the package description above. What more do you want? It clearly states that the purpose of the packages is to build other packages. Also, Fedora won't do split repos (been there, done that), and stuff like it doesn't even work that well in RHEL (and causes all sorts of issues). While I agree that the situation is not ideal, I still think this is the best that we can do: 1. We don't want Rust applications to vendor their dependencies 2. Rust can only do static linking (for now) -> Dependencies can only be shipped as source code, not as compiled artifacts. And while you *can* use packaged Rust crates for local development if you really want, it's not really a supported use case. 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: Planning retirement of rust-cpython and rust-python3-sys
Hello Rustaceans and Pythonistas, The "cpython" and "python3-sys" crates provide Rust bindings for CPython, but the project is no longer actively maintained [0], and it does not support CPython 3.12+ due to ABI / API changes. Programs that use the "cpython" bindings for building against CPython 3.12+ crash at runtime. The upstream project recommends projects to move to the PyO3 bindings, which are much more popular now, are actively maintained, and which have been adding support for new versions of CPython pretty quickly over the past few years. The only package in Fedora that depends on the "cpython" bindings is mercurial, which uses them for building the "mercurial-rust" extensions. These extensions do not work on Fedora 39+ due to the aforementioned changes in Python 3.12+. I reported this as an issue half a year ago [1], but got no response from the mercurial maintainers. My recommendation would be to disable building the mercurial-rust extensions on Fedora 39+ (where they already don't work!) until mercurial upstream moves to PyO3 to properly support CPython 3.12+. I am planning to retire the "rust-cpython" and "rust-python3-sys" crates next week. Fabio [0]: https://github.com/dgrunwald/rust-cpython/commit/e81 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2249383 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel wrote: > > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote: > > > > The short answer is: No, "fedpkg local" is not expected to work for > > > > Rust packages, and probably won't ever work as expected for Rust > > > > packages. > > > > > > > > I am not really interested in adding the "--allow-dirty" flag (not > > > > sure if it would even work in this case), since building Rust packages > > > > with "fedpkg local" is not working for other reasons. Primarily, > > > > "fedpkg local" does not support dynamically generated BuildRequires - > > > > this is only supported when building in mock. > > > > > I don't know what you mean? For me after patching the macro locally > > > local builds work as expected. Maybe I'm overlooking something? > > > > You might be lucky and just tried to package a Rust crate with no > > dependencies? > > Dependencies on other Rust crates are only resolved dynamically at build > > time, which "fedpkg local" does not support. So it works "by accident" for > > Rust crates with no crate dependencies, but in general, it can't work. > > That would have been extremely lucky, but no, I'm building crates with > dependencies. And the build generates the requires list just fine. > > What is not possible is installing build dependencies directly from a > spec file from a fresh clone, if that is what you mean? But in this case > running a local build generates a `.buildreqs.nosrc.rpm` file with the > correct dependencies, which can be passed to `dnf builddep`. > > And since a local build does not manage build dependencies themselves, > rather relies on them just being there, I don't really see an issue in > that? If you really don't mind jumping through multiple hoops just because you want to use "fedpkg local" instead of "fedpkg mockbuild", then I guess I can't stop you. All I *can* do is tell you that you're not going to like the experience: - Using "fedpkg local" is not supported for Rust packages, and I won't be adding workarounds to the Rust macros for it. - Installing rust-*-devel packages on your local system (i.e. outside of ephemeral build environments) is not supported. - The "rust-*-devel" packages are build system implementation details, if you want to say it like that. - They are not shipped to users and are not useful for Rust developers. - They are *only* intended to be installed in temporary chroots (like those set up by mock). - They don't get "Obsoletes" or "Provides" in case there are dropped subpackages and / or incompatible updates. This is not an issue because they are only ever *installed*, but never supposed to be *upgraded* in-place. Any issues you get by installing them on your host system are your own. 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 Thu, Apr 4, 2024, 00:54 Philip Matura via devel < devel@lists.fedoraproject.org> wrote: > On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote: > > On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel > > wrote: > > > > > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro - > > > from the top of my head this should not break anything, but I'm not > > > sure. There does not seem to be a general "ignore-git" option for > cargo. > > > > > > Or are there other ways to get this to work? > > > > The short answer is: No, "fedpkg local" is not expected to work for > > Rust packages, and probably won't ever work as expected for Rust > > packages. > > > > I am not really interested in adding the "--allow-dirty" flag (not > > sure if it would even work in this case), since building Rust packages > > with "fedpkg local" is not working for other reasons. Primarily, > > "fedpkg local" does not support dynamically generated BuildRequires - > > this is only supported when building in mock. > > I don't know what you mean? For me after patching the macro locally > local builds work as expected. Maybe I'm overlooking something? > You might be lucky and just tried to package a Rust crate with no dependencies? Dependencies on other Rust crates are only resolved dynamically at build time, which "fedpkg local" does not support. So it works "by accident" for Rust crates with no crate dependencies, but in general, it can't work. Fabio > Philip Matura > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > 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: "fedpkg local" builds fail for rust packages
On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel wrote: > > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro - > from the top of my head this should not break anything, but I'm not > sure. There does not seem to be a general "ignore-git" option for cargo. > > Or are there other ways to get this to work? The short answer is: No, "fedpkg local" is not expected to work for Rust packages, and probably won't ever work as expected for Rust packages. I am not really interested in adding the "--allow-dirty" flag (not sure if it would even work in this case), since building Rust packages with "fedpkg local" is not working for other reasons. Primarily, "fedpkg local" does not support dynamically generated BuildRequires - this is only supported when building in mock. I wonder if "fedpkg local" shouldn't just error out when attempting to build spec files that use %generate_buildrequires ... 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: Reminder: F40 final freeze starts next week (2024-04-02)
On Tue, Apr 2, 2024 at 6:08 PM Sandro wrote: > > On 26-03-2024 22:15, Adam Williamson wrote: > > On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote: > >> On 26-03-2024 16:25, Kevin Fenzi wrote: > >>> So, please take this time to do any last minute testing and bugfixing > >>> and make sure any packages you expect to be in the final f40 base > >>> repositories are pushed stable before next Tuesday (2024-04-02). > >> > >> I was just wondering, and someone else with me, if today's updates would > >> still make it in time? > >> > >> If not, I thank you for the reminder nonetheless, but would also like to > >> ask to have it sent in time for updates to still be able to land in the > >> release before freeze happens. > >> > >> Of course, there's always the option of going around begging for > >> (instant) karma ... > > > > You still have a week until next Tuesday, so...yes. > > We are one week down the road. I've submitted an update a week ago > shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze > is now in effect and the update[1] has *not* made it to stable. It's > still in testing. > > Luckily, this update can wait until after freeze. I'm glad I decided to > ask for karma for another update submitted earlier the same day. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45 Yes, 7 days between end of beta freeze and start of final freeze is not enough to land an update that has autotime=7days. Which is really annoying. Maybe next time we can make the non-freeze period last like 8-9 days? One week (especially if that week contains the Easter holiday) 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: Look for help: how to package Rust project
On Fri, Mar 22, 2024 at 3:26 PM Ming Lei wrote: > > I love this easy way. > > But when I try to build in this way, I got the following failure: > > Problem 1: nothing provides requested (crate(ilog/default) >= 1.0.1 > with crate(ilog/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libublk/default) >= > 0.3.0 with crate(libublk/default) < 0.4.0~) > Problem 3: nothing provides requested (crate(qcow2-rs/default) >= > 0.1.2 with crate(qcow2-rs/default) < 0.2.0~) > Problem 4: nothing provides requested (crate(shared_memory/default) > >= 0.12.4 with crate(shared_memory/default) < 0.13.0~) > Problem 5: nothing provides requested (crate(smol/default) >= 1.3.0 > with crate(smol/default) < 2.0.0~) > > I guess it is because that all above crate aren't packaged in Fedora, > can you share how to > deal with this issue? Yes, these error messages represent all the crate dependencies that cannot be resolved from Fedora repositories. They will need to be packaged separately if you want to submit this as an official package for Fedora. Or if you want a "quick and dirty" solution for unofficial packages, you can use "rust2rpm --vendor". 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: Look for help: how to package Rust project
On Thu, Mar 21, 2024 at 9:25 AM Richard W.M. Jones wrote: > > On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote: > > Hello Richard and Guys, > > > > I plan to package rublk to Fedora, and it is one Rust project. > > Hi, I'm on holiday at the moment, but please do look at how we > packaged libblkio in Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=2124697 > > > Can you provide a little guide about how to do that? such as, > > where can I find the guide doc? And is it github or crates which > > should be used as source for Fedora packaging? > > Everything has to start with a source tarball, so normally github > would be the best source. > > > [1] https://github.com/ublk-org/rublk > > [2] https://crates.io/crates/rublk If the project is a single "crate" (i.e. one compilation unit) and will continue to be published on crates.io, I would recommend using the sources published there instead of GitHub sources. Using files distributed via crates.io makes packaging a bit easier and avoids some work that is necessary for non-crate Rust packages. I would recommend reading the Rust packaging guidelines for this case: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_rust_crates You should get a working spec file by just running "rust2rpm -s rublk". 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 - Book Smugglers edition
On Wed, Mar 20, 2024 at 2:53 PM Tomasz Kłoczko wrote: > > On Sat, 16 Mar 2024 at 10:03, Miroslav Suchý wrote: >> >> Hot news: >> >> The last phase has been announce >> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will >> proceed when approved with FESCO. > > > I think that generally you are wasting your man/hours posting such statistics. > The same time could be used better by going with a few grep. sort, sed > oneliers to co update and align all packages License: fields and commit all > those changes across all per packages repos in a few minutes. > Some of the proven packagers with RW access to all packages repos can apply > necessary changes in a few tenths of minutes. > Subject of SPDX migrations are already IIRC active since July 2022 (soon it > will be two years anniversary). > All those changes should not be applied relying on each package maintainers > because that change is from Trival™️ class. While I agree with some of what you're saying here, the problem is that it is, in fact, *not trivial* in many cases. Migrating the License tag from Callaway to SPDX identifiers is only the "easy" part of the transition. Re-reviewing package contents and re-classifying licenses is the non-trivial part, and that definitely can't be scripted. 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: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé wrote: > > On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote: (...) > > As I understand, upstream is going to remove engines but it wouldn't happen > > before OpenSSL 4.0 > > That makes sense, as it solves the ELF ABI / SONAME change > issue with removing the APIs. > > > I don't think Fedora should wait for that. We definitely want to land > > no-engine in RHEL10 so Fedora should be ready for that. > > Fedora shouldn't neccessarily be rushed into something just because > RHEL wants to do it prematurely due to RHEL's long lifecycle. I fully agree here. Just because something is desirable for RHEL x+1 doesn't mean that it's desirable for Fedora y+1. Also, hasn't CentOS Stream 10 already been branched off of ELN-is-Fedora-40, meaning it would be too late if done in Fedora 41 anyway? Or is this just about OpenSSL maintainers not wanting to have to keep maintaining Engine support in Fedora while it will be phased out in RHEL sooner? 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: ld: error: triggering the generation of an executable stack
On Wed, Mar 20, 2024, 01:28 Orion Poplawski wrote: > With a recent update, plplot is failing to build with: > > cd > /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran > && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt > --verbose=1 > /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed > -Wl,-z,pack-relative-relocs -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 > -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe > -Wall -Wno-complain-wrong-lang -Werror=format-security > -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -frecursive > CMakeFiles/x16af.dir/x16af.f90.o -o x16af > -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > > ../libplfortrandemolib.a > ../../bindings/fortran/libplplotfortran.so.0.2.0 > > -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the > generation of an executable stack (because it has an executable > .note.GNU-stack section) > /usr/bin/ld: failed to set dynamic section sizes: No such file or directory > > I have no idea what is up here. > Isn't this what this change was about? https://fedoraproject.org/wiki/Changes/Linker_Error_On_Security_Issues Fabio > Seems to have started with: > > gcc 14.0.1-0.7.fc41 > glibc 2.39.9000-3.fc41 > util-linux 2.40-0.9.rc1.fc41 > binutils 2.42.50-4.fc41 > > and lots of others, but that seems the most likely. > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > 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: Follow up for bash-completion pkgconfig file packaging change
On Mon, Mar 18, 2024 at 5:22 PM Dan Horák wrote:
>
> On Mon, 18 Mar 2024 17:07:08 +0100
> Fabio Valentini wrote:
> > I wonder why these packages rely in pkg-config and don't just install
> > to `%{bash_completions_dir}`?
>
> because it hasn't always exist? Or it's mentioned in some guidelines?
Likely, yes. They've been around for ~2 years.
They are available on all current branches of Fedora and on EPEL 9.
The effort to document them in the packaging guidelines seems to have stalled:
https://pagure.io/packaging-committee/issue/1202
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: Follow up for bash-completion pkgconfig file packaging change
On Mon, Mar 18, 2024 at 4:33 PM Mamoru TASAKA wrote:
>
> Hello, all:
>
> After investigating the recent Fedora-Security-Live livespin compose failure
> on F-41, it is found that this is caused because:
>
> - Recently on F-41, bash-completion packaging changed so that pkgconfig file
>is moved into -devel subpackage: (bash-completion-2.11-15.fc41)
>
> https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide
>
> - A package (lynis) installing bash-completion file into the directory
>$(pkg-config --variable=completionsdir bash-completion), had
> "BuildRequires: bash-completion",
>but did not have "BuildRequires: pkgconfig(bash-completion)".
>
> - So after the above bash-completion side packaging change, the above command
> line was
>expanded to the empty string, so the completion file was installed into
> the wrong directory,
>which caused conflict with filesystem rpm.
>
>
> So on F-41(rawhide), the packages
>
> * trying to install bash-completion file using $(pkg-config
> --variable=completionsdir bash-completion)
> * which have "BuildRequires: bash-completion", but do NOT have
> "BuildRequires: pkgconfig(bash-completion)"
>
> may be installing completion file into wrong directories after rebuild.
> (At least, I tried rebuilding cowsay and actually it installs completion file
> into the wrong
> directory).
I wonder why these packages rely in pkg-config and don't just install
to `%{bash_completions_dir}`?
This macro is defined in the default buildroot, regardless of
BuildRequires, and always expands to the correct location for
installing bash completions.
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: Why can't I add karlowich as co-maintainer of this package?
On Mon, Mar 18, 2024 at 1:51 PM Richard W.M. Jones wrote: > > On Mon, Mar 18, 2024 at 10:14:38AM +, Richard W.M. Jones wrote: > > On Mon, Mar 18, 2024 at 10:05:42AM +, Daniel P. Berrangé wrote: > > > On Mon, Mar 18, 2024 at 09:57:58AM +, Richard W.M. Jones wrote: > > > > > > > > https://src.fedoraproject.org/rpms/xnvme/adduser > > > > > > > > I try to add karlowich > > > > (https://accounts.fedoraproject.org/user/karlowich/) > > > > but his name doesn't appear in the username field even though he's > > > > in the packager group. Why? > > > > > > If they were only recently granted packager status, they might need login > > > to 'src.fedoraproject.org' to (re)sync group membership perhaps ? > > > > Thanks everyone, I'll have him try this. > > No luck. He's apparently tried logging out / in a few times and > doesn't appear in the list. Is there something else he needs to try? It appears that src.fp.o does not know about him *at all*: https://src.fedoraproject.org/user/karlowich Note that the logging out / back in needs to happen on src.fedoraproject.org, not with any other Fedora service. For me, sometimes opening "src.fedoraproject.org" in an incognito browser window and logging in there has helped. 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: PHP no 32 bit / PHP 64-bit only (self-contained)
On Tue, Mar 12, 2024, 15:16 Marcin Juszkiewicz
wrote:
> W dniu 8.03.2024 o 21:50, Aoife Moloney pisze:
> > == Detailed Description ==
> > PHP is not a library, so is not multilib.
> > 32-bit consumes builder CPU/time, but nothing is shipped in the
> repositories.
> >
> > A lot of projects don't have 32-bit CI, so this may raise FTBFS (10 in
> > F40 Mass Rebuild)
> >
> > Add for all extension packages:
> >
> > '''ExcludeArch: %{ix86}'''
>
> Recently I was wondering when Fedora will do opposite. Disable 32-bit
> x86 builds for all packages and leave it explicitly enabled for those
> packages which are used for multilib purposed.
I have thought about this when proposing the Change to make dropping
support for i686 easier. What you suggest is probably not as easy as you
think - the packages that are required for multilib purposes change over
time, and in turn the packages that are necessary to *build* those packages
are also not constant. It would be easy to end up in a situation where some
packages that are needed on i686 can no longer be built there because they
start requiring other packages that were already dropped from i686.
Worst case scenario (if too many things were to be dropped at some point),
a re-bootstrapping of i686 might be necessary to get things into a working
state again (and I'm pretty sure at that point we might as well just turn
it off entirely because it would not be worth the effort).
I'm hoping that we can get there in a different way: The cases where
multilib support is actually needed are going away.
- I think koji now supports a setup where "noarch" packages are never built
on i686.
- Wine looks like it will support running 32-bit Windows applications
without needing any i686 libraries.
- Steam still requires 32-bit libraries to be present I think, but this is
increasingly anachronistic and I'm not sure what's holding them back from
just making their Linux client 64-bit only. But even this is not as big of
a problem as it used to be, since the Steam flatpak works just fine.
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: perl segfault in F40
On Mon, Mar 11, 2024, 15:34 Sérgio Basto wrote: > > pkgconf had a big update from 1.9.5 to 2.1.0 > > https://src.fedoraproject.org/rpms/pkgconf/commits/rawhide Yes, but the soname did not change. So it looks like this ABI change (if it is an ABI change? it looks like it) was not intentional. 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: perl segfault in F40
On Mon, Mar 11, 2024, 04:07 Jerry James wrote:
> On Sun, Mar 10, 2024 at 10:38 AM Orion Poplawski wrote:
> > I'm starting to see this building perl-Alien-CFITSIO in F40 (not
> rawhide):
> >
> > + cd Alien-CFITSIO-v4.4.0.1
> > + perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
> > Alien::Build::Plugin::PkgConfig::Negotiate> Using PkgConfig plugin:
> > PkgConfig::LibPkgConf
> > RPM build errors:
> >
> > I can't reproduce it locally except in mock. Even in mock though if I
> > enter the chroot with a shell and run rpmbuid it works, so I'm guessing
> > its tty related.
> >
> > Is anyone else seeing this?
>
> Yes. GDB says:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
> Downloading source file
> /usr/src/debug/glibc-2.39-2.fc40.x86_64/libio/iofclose.c
> 48if (fp->_flags & _IO_IS_FILEBUF)
> (gdb) bt
> #0 0x77a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
> #1 0x76f690db in XS_PkgConfig__LibPkgConf__Client_DESTROY
> (my_perl=, cv=)
> at
> /usr/src/debug/perl-PkgConfig-LibPkgConf-0.11-17.fc40.x86_64/LibPkgConf.xs:311
> #2 0x77d1288a in Perl_pp_entersub (my_perl=0x92a0)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_hot.c:
> #3 0x77d03718 in Perl_runops_standard (my_perl=0x92a0)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
> #4 0x77c484da in Perl_call_sv (my_perl=0x92a0,
> sv=, flags=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:3150
> #5 0x77d1b9cf in S_curse
> (my_perl=my_perl@entry=0x92a0, sv=sv@entry=0x57dba810,
> check_refcnt=check_refcnt@entry=true) at
> /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7144
> #6 0x77d1c1c0 in Perl_sv_clear
> (my_perl=my_perl@entry=0x92a0,
> orig_sv=orig_sv@entry=0x57dba810)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:6685
> #7 0x77d16482 in Perl_sv_free2 (my_perl=0x92a0,
> sv=0x57dba810, rc=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7244
> #8 0x77d4d025 in Perl_leave_scope
> (my_perl=my_perl@entry=0x92a0, base=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/scope.c:1429
> #9 0x77d52658 in Perl_dounwind (cxix=,
> my_perl=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1669
> #10 Perl_dounwind (my_perl=my_perl@entry=0x92a0, cxix=10)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1658
> #11 0x77d52b19 in Perl_die_unwind (my_perl=0x92a0,
> msv=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1901
> #12 0x77ce0b8b in Perl_croak_sv (my_perl=0x92a0,
> baseex=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1861
> #13 0x77ce0b9d in Perl_die_sv (my_perl=,
> baseex=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1780
> #14 0x77d61061 in Perl_pp_die (my_perl=0x92a0)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_sys.c:509
> #15 0x77d03718 in Perl_runops_standard (my_perl=0x92a0)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
> #16 0x77c47899 in S_run_body (oldscope=,
> my_perl=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2807
> #17 perl_run (my_perl=0x92a0) at
> /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2727
> #18 0x5342 in main (argc=, argv= out>, env=)
> at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perlmain.c:127
>
> Frame 1 is this code:
>
> void
> DESTROY(self)
> my_client_t *self;
> CODE:
> if(self->auditf != NULL)
> {
> fclose(self->auditf);
> self->auditf = NULL;
> }
> pkgconf_client_deinit(>client);
> SvREFCNT_dec(self->error_handler);
> Safefree(self);
>
> and indeed, self->auditf != NULL, because it is equal to 1, so it is
> passed to fclose, triggering the segfault. Setting a hardware
> watchpoint to catch the transition to the value 1 turns up this:
>
> Old value = (FILE *) 0x0
> New value = (FILE *) 0x1
> pkgconf_cache_add (client=0x57f4cd70, pkg=0x57f4d320) at
> libpkgconf/cache.c:136
> Downloading source file
> /usr/src/debug/pkgconf-2.1.0-1.fc40.x86_64/libpkgconf/cache.c
> 136 client->cache_table =
> pkgconf_reallocarray(client->cache_table,
> (gdb) bt
> #0 pkgconf_cache_add (client=0x57f4cd70, pkg=0x57f4d320) at
> libpkgconf/cache.c:136
> #1 pkgconf_cache_add (client=client@entry=0x57f4cd70,
> pkg=pkg@entry=0x57f4d320) at libpkgconf/cache.c:123
> #2 0x76f5c6af in pkgconf_pkg_find (client=0x57f4cd70,
> name=name@entry=0x55c01240 "cfitsio")
> at libpkgconf/pkg.c:825
> #3 0x76f692fc in XS_PkgConfig__LibPkgConf__Client__find
> (my_perl=, cv=)
> at
> /usr/src/debug/perl-PkgConfig-LibPkgConf-0.11-17.fc40.x86_64/LibPkgConf.xs:324
> #4 0x77d1288a in Perl_pp_entersub
Re: google-re2 pacakge update and facebook vs google python bindings ?
On Sat, Feb 24, 2024 at 5:15 PM Fabio Valentini wrote: > > On Sat, Feb 24, 2024 at 11:49 AM Michael J Gruber > wrote: > > > > Am Sa., 24. Feb. 2024 um 03:37 Uhr schrieb Adam Williamson > > : > > > > > > On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote: > > > > On Wed, 7 Feb 2024, Ben Beasley wrote: > > > > > > > > > Subject: Re: google-re2 pacakge update and facebook vs google python > > > > > bindings > > > > > > > > I haven't heard back from any of the maintainers. > > > > > > > > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the > > > > first step towards getting python-google-re2 working. > > > > > > > > https://src.fedoraproject.org/rpms/re2/pull-request/6 > > > > > > You now seem to have just built re2 for Rawhide without any of the > > > deps: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d > > > > > > that's not how you're supposed to do things, these days. You should > > > build re2 on a side tag and then get all the deps rebuilt on the same > > > side tag, then create a combined update. The update failed tests > > > because of this. > > > > > > The best thing to do at this point would be to create a side tag, bump > > > re2 and do a new build on the side tag, then ask maintainers of > > > dependencies and/or provenpackagers to rebuild the dependencies on the > > > side tag. > > > -- Since this update was stuck and obviously broken, with no response from Paul in over a week (either here or on the bodhi update), I've used my provenpackager rights to revert the commits in dist-git and unpush the stuck update (it failed gating tests, so it never made it to rawhide repos). This should prevent the broken update from accidentally getting pushed to Rawhide again, and it gives an opportunity to re-do the conversion to rpmautospec correctly (i.e. "rpmautospec convert" to preserve the old changelog) if that is desirable. 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: libxslxwriter (misspelled package) in zombie state
On Mon, Mar 4, 2024 at 10:45 AM Vít Ondruch wrote: > > It should also be marked as "retired" / "unmaintained" in Pagure and > there should be no owner which is not the case. And this is not the only > package in this state. I have reported it here: > > > https://pagure.io/releng/issue/11994 As Miro noted in this ticket, "retired" and "orphaned" are different things. It is a valid state for a package to be "retired" in rawhide but not "orphaned" (i.e. still maintained in stable branches). Packages are only moved to the "orphan" user automatically when they are no longer present in any currently active branches of Fedora or EPEL. 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: Update gumbo-parser to 0.12.1/libgumbo SONAME bump
On Sat, Mar 2, 2024, 09:06 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > > On Friday, March 1st, 2024 at 20:27, Jason Tibbitts wrote: > > > > > > > > Adam Williamson adamw...@fedoraproject.org writes: > > > > > Honestly, we could really use more automation here, but it's a fairly > > > hard thing to do reliably and there just isn't anybody specifically > > > tasked with it so it doesn't happen. > > > > > > So sure, we could use something but it doesn't have to start out as some > > complex fully automatic system. (Would be nice, but...) > > > > Can we agree that we'd be at least half of the way there if we just had > > a well defined way to: > > > > * Know what package depend on the one you're updating > > > > * Easily bump and chain-build all of that in a side tag > > > > Surely there's a reopquery or fedrq command line that will find at least > > most of what needs to be rebuilt. It doesn't have to be absolutely > > perfect but it can't be that hard to get close. I know there's a > > distinction between build and runtime dependencies and rich/conditional > > dependencies complicate things a bit, but those much smarter than I am > > must have already figured out how to get something that's at least > > somewhat useful. > > > > Once you have the package list, maybe it needs some kind of sorting > > before you can just bump and chain-build things, but I think in many > > cases it doesn't. So, yes, a 100% tool would be really hard but the 80% > > tool really shouldn't be that bad, and almost any tool would really help > > people out. > > > > My idea was to write a Python script based on libdnf APIs and third party > python modules to create a dependency tree of packages, so that also Mass > Rebuilds can be run by the tree levels instead of alphabetically. However, > I had no time to further develop the idea, as I also learn how to fetch > data from libdnf (and if that is possible at all). > The problem with this idea is that the dependency tree is not a "tree", but a graph that is *not* acyclic. So you just *cannot* make a linearized version / topographic sort without some amount of "bootstrap" changes to break (or ignore) some of the involved dependencies. Fabio > Mattia > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Podman v5 breaking changes
On Wed, Feb 28, 2024 at 11:33 AM Peter Robinson wrote: > > On Mon, 26 Feb 2024 at 20:59, Gursewak Singh wrote: > > > > In Fedora 40, Podman has undergone a major version upgrade to v5 [1], > > introducing some breaking changes. Notably, CNI networking support has been > > discontinued in favor of Netavark, and cgroups v1 support has been > > deprecated in favor of cgroups v2. > > > > To know whether your nodes are affected, you can use podman info and look > > for the cgroupVersion and networkBackend keys. > > > > If you're using cgroups v1, migrating to cgroups v2 is strongly > > recommended, as a future Podman version will no longer support cgroups v1. > > Kernel arguments can be adjusted to use cgroups v2 with rpm-ostree kargs > > [2]. > > > > If you're using CNI networking, transitioning to Netavark requires running > > podman system reset --force, leading to the deletion of images, containers, > > and custom networks. Depending on your setup, it may be preferable to > > reprovision the entire machine from the latest images to allow for Ignition > > to bring up containerized applications from scratch. > > > > If you have any feedback or encounter issues related to the aforementioned > > changes, please don't hesitate to participate in the upstream issue > > discussion [3]. > > Sounds like a change of this size should have been a System Wide change. Technically, it was ... it was approved 2 months ago: https://pagure.io/fesco/issue/3126#comment-890379 > transitioning to Netavark requires running podman system reset --force, > leading to the deletion of images, containers, and custom networks However, this was not explicitly mentioned in the Change Proposal, only some vague sentence about "upgradability": https://fedoraproject.org/wiki/Changes/Podman5#Upgrade/compatibility_impact So I'm not sure if FESCo was aware of this issue when the Proposal was voted on. 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: rpmbuild problem with rust code
On Mon, Feb 26, 2024, 22:25 Steve Grubb wrote: > Hello, > > I've run across a strange problem building a package that has some rust > files > in it. The build goes fine until the end when it starts to check for > shebangs. > It ends like this: > > > /usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/src/ > lib.rs has shebang which doesn't start with '/' ([no_std]) > > When I check the file, I find this: > #![no_std] > > #[macro_use] > mod allocated_memory; > mod stack_allocator; > mod allocated_stack_memory; > > Not being a rust programmer, I have no good idea what the code is doing. I > can't patch this code to move it off the first line because it's vendored > code. > > Is there a way to tell rpmbuild not to worry about this? > The solution should be simple - remove stray +x permissions from all *.rs files. Some editors see a file that starts with "#!" and think "hey, this looks like a script! let me mark the file as executable!" even though this is Rust syntax for global attributes, not a shebang. Fabio > -Steve > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > 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: koji news and 1.34.0 upgrade
On Sat, Feb 24, 2024 at 7:27 PM Neal Gompa wrote:
>
> On Sat, Feb 24, 2024 at 12:59 PM Otto Liljalaakso
> wrote:
> >
> > Kevin Fenzi kirjoitti 22.2.2024 klo 1.43:
> > > Greetings. After the outage that just completed, koji has been upgraded
> > > to 1.34.0 plus a few patches from upstream. Some highlights:
> > >
> > > * A patch has been added allowing us to set 'noarch_arches' on build
> > > tags. This allows us to specify what arch builders will do noarch
> > > builds. Without any setting it's any arch, but this presents problems
> > > for noarch packages that have some dependencies that have dropped i686.
> > > For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> > > (ie, excluding i686). If this works well we can extend it to other build
> > > tags.
> > What does this mean in practice for packagers? Can I now stop adding
> > `ExcludeArch: %{ix86}` to noarch packages in Rawhide, or should I still
> > keep doing that until we know "if this works well"?
>
> You should no longer need to do that.
With one caveat:
> For f41 / rawhide, this has been set to "aarch64 x86_64 ppc64le s390x"
> (ie, excluding i686). If this works well we can extend it to other build
> tags.
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: google-re2 pacakge update and facebook vs google python bindings ?
On Sat, Feb 24, 2024 at 11:49 AM Michael J Gruber wrote: > > Am Sa., 24. Feb. 2024 um 03:37 Uhr schrieb Adam Williamson > : > > > > On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote: > > > On Wed, 7 Feb 2024, Ben Beasley wrote: > > > > > > > Subject: Re: google-re2 pacakge update and facebook vs google python > > > > bindings > > > > > > I haven't heard back from any of the maintainers. > > > > > > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the > > > first step towards getting python-google-re2 working. > > > > > > https://src.fedoraproject.org/rpms/re2/pull-request/6 > > > > You now seem to have just built re2 for Rawhide without any of the > > deps: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d > > > > that's not how you're supposed to do things, these days. You should > > build re2 on a side tag and then get all the deps rebuilt on the same > > side tag, then create a combined update. The update failed tests > > because of this. > > > > The best thing to do at this point would be to create a side tag, bump > > re2 and do a new build on the side tag, then ask maintainers of > > dependencies and/or provenpackagers to rebuild the dependencies on the > > side tag. > > -- > > Also, the commit introduced a switch to autochangelog, which should be > the maintainer's decision, and is best done in a separate commit > before the bump. Besides, the changelog file was not committed to > dist-git. Did this just erase all changelog history from the rpm? Yes, this was done incorrectly (both the uncoordinated non-side-tag build *and* the conversion to rpmautospec) ... I would suggest somebody revert the two commits in git for 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: Feedback wanted - pruning old rawhide chroots in Copr
On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber wrote:
>
(snip)
>
> I see this somehow connected to the discussion about signing keys that
> we had recently. A radical solution would be: branch rawhide, not from
> rawhide. So, at the "F40 branch point we had last week", we would:
> - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> - rename rawhide chroots to f40 in copr
> - set up new rawhide chroots ("follow [up] fedora branching")
>
> In most cases, "forked" packages in copr are misleading - they are in
> a chroot without having been built against any version of it.
>
> copr users would have to hit "rebuild", which should be OK.
I like this idea. Move things that were built for "rawhide" into the
"fedora-40" chroot, and start Rawhide empty, requiring fresh builds of
things.
Since there is no equivalent to the mass rebuild in COPR, that would
also solve the problem of "stale" packages in Rawhide chroots.
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: Proposing a Fedora SIG for the upcoming COSMIC desktop environment
On Sat, Feb 17, 2024 at 4:15 AM Michel Lind wrote: > > Hello and welcome! > > On Fri, Feb 16, 2024 at 08:59:49PM -, Ryan Brue wrote: > > Hello all! This is my first time using a mailing list, but I want to do > > this more often in the future :) > > > > > > If you happen to like rust, or are simply excited to see another desktop > > environment join the space, share your interest! > > If there is enough interest, I would suggest we then create a matrix group, > > similar to what the Fedora KDE SIG has. I believe the KDE SIG uses an IRC > > bridge as well, for those interested in using IRC. > > Happy to join the Matrix room when it's created! Can't commit to being > that involved, but it seems like there's going to be a lot of overlap on > the packaging side with the Rust SIG I'm already in (Rust crates in > Fedora are all co-maintained by the SIG) so feel free to drop in and ask > questions at #rust:fedoraproject.org I'm looking forward to COSMIC as well. I wanted to wait until there's an actual alpha release with trying to package things, so I hadn't looked to closely at it yet :) Also, I agree with Michel, there is probably going to be a lot of overlap with the Rust SIG, so it would be great to have you in the Rust matrix room to coordinate first steps :) 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] update to jpegxl-0.9.2 with soname bump in rawhide
On Wed, Feb 14, 2024 at 7:00 PM Sérgio Basto wrote: > > On Wed, 2024-02-14 at 16:41 +0100, Fabio Valentini wrote: > > On Wed, Feb 14, 2024 at 2:53 PM Sérgio Basto > > wrote: > > > > > > On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote: > > > > Hi, > > > > I will start a mass rebuild [1] in a side-tag, very soon , the > > > > goal > > > > is > > > > finish and merge it before branch of Fedora 40, please let me > > > > know we > > > > have any objection that prevent to proceeding. > > > > > > > > > > As we already have the new branch f40, I started the rebuild for > > > f41. > > > > > > I added `%global build_type_safety_c 0` to gimp.spec and > > > workaround > > > modern C and build gimp > > > > > > but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build > > > [1] > > > > > > webkitgtk just failed on i686 , should I processed to F40 ? > > > > webkitgtk is a critical package that would likely cause composes to > > fail. > > I don't think the side tag should be merged unless this package is > > fixed and can be rebuilt. > > > side-tag for rawhide (f41) was pushed before I started to write > > but webkitgtk also FTBFS in F40 without any modification : > > cd webkitgtk > git checkout f40 > fedpkg scratch-build --arch=i686 That doesn't really matter, but now it also will fail to *install* in addition to failing to build (which is *not good*) ... -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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] update to jpegxl-0.9.2 with soname bump in rawhide
On Wed, Feb 14, 2024 at 2:53 PM Sérgio Basto wrote: > > On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote: > > Hi, > > I will start a mass rebuild [1] in a side-tag, very soon , the goal > > is > > finish and merge it before branch of Fedora 40, please let me know we > > have any objection that prevent to proceeding. > > > > As we already have the new branch f40, I started the rebuild for f41. > > I added `%global build_type_safety_c 0` to gimp.spec and workaround > modern C and build gimp > > but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build [1] > > webkitgtk just failed on i686 , should I processed to F40 ? webkitgtk is a critical package that would likely cause composes to fail. I don't think the side tag should be merged unless this package is fixed and can be rebuilt. 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto wrote: > > On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote: > > We are not banning nor deleting anything. We are not _supporting_ it. > > > you are removing X11 from the builds deliberately , when > many people , members of Fedora on devel mailing list, express that > they want have X11 , in fact we have many people that defend keep X11 . One thing that seems to be overlooked in many of the posts on this thread: Nobody can *force* the KDE Plasma maintainers to do *anything*, just like nobody can force *any* packager to do anything. Fedora a volunteer-run project. We're mostly doing this "for fun" (or at least, some definition of "fun"). So if the KDE Plasma maintainers / the KDE SIG decides that they do not want to keep supporting the Plasma / X11 session, that is their choice. However, I am not sure whether I like it or not that there's an ongoing effort to add this functionality back with separate packages. For me, the only acceptable way to do this would be in a way that does in no way make maintaining the Plasma / Wayland packages more difficult or burdensome, since the original intent of dropping the Plasma / X11 session was to *lower* the maintenance burden. Adding back the Plasma / X11 session with separate packages might cause additional overhead for the KDE SIG (for example, needing to update kwin-x11 whenever there is a kwin update). That would be the "usual" way to handle this according to Fedora policies. However, that would be counter to the original purpose of dropping the functionality from the packages maintained by the KDE SIG. But again, nobody can *force* package maintainers to support something they don't want to support. So in this case, I think it would be good to have something like a clarification to the Updates Policy (and / or other policies, as necessary) for this case to resolve the contradiction - something like "updates for KDE Plasma packages are not required to be coordinated with packages for the Plasma / X11 session". I'm also unsure how handling bug reports would best work in this situation. People *will* report bugs against the wrong components, causing additional work for the KDE SIG. (Hell, I'm getting bug reports filed against elementary / Pantheon packages, and there's not even a usable Pantheon session in Fedora 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: bodhi push error
On Tue, Feb 6, 2024 at 3:12 AM Christoph Junghans wrote: > > Hi, > > Has anybody seen this error before: > FEDORA-2024-310c0537ac ejected from the push because "Cannot find > relevant tag for gromacs-2023.4-1.fc39. None of ['f39-updates', > 'f39-updates-pending'] are in ['epel9-next-testing', 'epel7-testing', > 'eln-updates-testing', 'epel8-testing', 'epel9-testing', > 'epel8-next-testing', 'f40-container-updates-testing', > 'f38-modular-updates-testing', 'f38-flatpak-updates-testing', > 'f40-updates-testing', 'f38-updates-testing', > 'f38-container-updates-testing', 'f39-updates-testing', > 'f39-container-updates-testing', 'f39-flatpak-updates-testing']." Known issue, already reported to releng: https://pagure.io/releng/issue/11932 Will hopefully be sorted out soon. 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: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available
On Tue, Feb 6, 2024 at 1:42 PM Dan Horák wrote: > > On Tue, 6 Feb 2024 13:11:55 +0100 > Sandro Mani wrote: > > > > > On 06.02.24 8:50 AM, Marc-André Lureau wrote: > > > Hi > > > > > > On Mon, Feb 5, 2024 at 8:52 PM Daniel P. Berrangé > > > wrote: > > >> On Mon, Feb 05, 2024 at 05:34:06PM +0100, Dan Horák wrote: > > >>> Hi, > > >>> > > >>> could someone in the mingw team look at mingw-libgsf / libgsf (please > > >>> see the bug forwarded below)? If I see right, then the standalone > > >>> mingw-libgsf package should be retired as there are mingw builds from > > >>> the regular libgsf package, which seems to be regularly updated. > > >> Copying Marc-André who added the mingw sub-RPMs to the native > > >> package. > > >> > > >> The mingw-libgsf should have been retired on rawhide, as soon > > >> as the libgsf native had a successful build with mingw packages. > > >> > > >> At this point I guess it'll need retiring on both rawhide > > >> and f39 > > > Correct, I missed that. Geg, Sandro, can you retire the mingw-libgsf > > > package? > > > > > I've retired the package, but not sure if it worked 100% as I'm not > > listed as package admin. > > I suspect it hasn't finished the retiring, mingw-libgfs is still active > in koji and in pagure ... Likely it needs either Greg (who seems to be > inactive) or a releng ticket. No, processing package retirements happens during the compose process, so it takes up to 24 hours. 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 review ticket status change after approval
On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel wrote: > (snip) > > That said, I'd like to make a request and maybe make all reviewers aware > of a feature which was implemented some time ago. I've noticed many > reviewers change the ticket status from ASSIGNED to POST when they flag > the package as approved: I'd like to request to not do that. > > The Package Review Tracker webpages make a distinction between packages > approved (fedora-review flag set to +) and packages approved AND being > built in Fedora. That distinction relies on the ticket status change to > POST, which is automatically set when the repository is created in src.fp.o. Hum ... am I missing something here? The bot that creates the dist-git repos does *NOT*, in fact, set the bug status to POST: https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5 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: A reminder: you cannot just "revert" package version bumps
On Tue, Jan 30, 2024 at 1:00 AM Sérgio Basto wrote: > (snip) > yes rawhide user should use dnf distro-sync not dnf upgrade It is better, yes, but it is not *required*. > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily This is a completely different problem. Package updates that don't build in Rawhide but build on stable branches are permissible as long as the package update will be submitted to Rawhide *eventually*. > you may do a new build with lower EVR No, you may not. That is exactly what Adam's email is about. 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: AusweisApp2 build failed on rawhide/x86_64 (unsupported reloc 43)
On Sat, Jan 20, 2024 at 2:41 PM Jakub Jelinek wrote: > > On Sat, Jan 20, 2024 at 02:27:58PM +0100, Julian Sikorski wrote: > > AusweisApp2-2.0.3 build failed on rawhide/x86_64 with unsupported reloc 43 > > errors [1]. Other architectures have built fine, similarly to released > > branches. Is this a problem with rawhide ld.gold? > > I thought reloc 43 (aka R_X86_64_CODE_4_GOTPCRELX) is a relocation for APX > code (i.e. when an instruction uses %r16-%r31 registers and needs GOTPCREL), > it surprises me a package in the distro would use it so quickly. > > In any case, ld.gold is an unmaintained linker for years, just use ld.bfd > instead. It looks like this is a problem in the latest binutils build actually: https://bugzilla.redhat.com/show_bug.cgi?id=2259333 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, Jan 16, 2024 at 2:43 PM Dridi Boukelmoune wrote: > > > This is also a valid approach. This is the first alternative proposal > > which makes me say "hmm, this would also work". It is possibly even > > simpler than setting the $PATH. A very small disadvantage is that the > > wrapper would need to do its work every time the binary is called. > > But the wrapper could be trivially implemented in shell or it could be > > a compiled binary, making the wrapper very cheap. > > > > Hmm, what do other people think? > > With my computer user hat on, I would much prefer this approach. If > the supposed "dozen" of relevant packages can be built with several > binaries variants, then let's pack them all in the same RPM and use > this mechanism. I'm sure that if successful it would extend to more > packages, including packages on the critical path. I'm fine with that > eventual outcome with this scheme. > > This way, if I ever need to take my drive out of a fried laptop and > USB-boot from it on my spare laptop from 2013, then I'm not painting > myself into a corner with binaries too recent for that hardware. I was > happy to be able to do that last summer, and hope to still be able to > in the future (but also hope not to ever need it again). And yes, > Fedora (Xfce) works just fine on that decade-old laptop. But ... you would be able to do this if the proposal was implemented as-is, as well? The "non-optimized" variant would still be installed, and PATH would be set appropriately to fall back to it if you stick the hard drive into an old machine (unless I misunderstand the proposal, or your argument here). Just to give my 2¢ here as well, I was skeptical about the "systemd sets the $PATH appropriately for the hardware it's booting on", but I actually like that approach now. Using symbolic links smells too much like using alternatives, and those have always been a bit brittle. 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
EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package
Hi all, I've been made aware that there has been a cascade of packages that dropped i686 support in Rawhide, most of them referencing my EncourageI686LeafRemoval Change Proposal, but none of which *actually are* leaf packages: https://src.fedoraproject.org/rpms/composefs/c/b95af99 https://src.fedoraproject.org/rpms/ostree/c/af0a269 (correctly scoped to RHEL>=10) https://src.fedoraproject.org/rpms/flatpak/c/9e4df49 (correctly scoped to RHEL>=10) https://src.fedoraproject.org/rpms/xdg-desktop-portal/c/93310f7 https://src.fedoraproject.org/rpms/gdm/c/940885b https://src.fedoraproject.org/rpms/sssd/c/e0023ec It looks like at least some of these changes were mistakenly pushed to Rawhide while they should only apply to ELN / RHEL>=10? I suspect that these packages dropping i686 support will cause a ton of build failures during the upcoming mass rebuild. As the author of the EncourageI686LeafRemoval Change Proposal - please **DO NOT DO IT THIS WAY**. The Change Proposal was about dropping i686 builds from packages that are **LEAF PACKAGES**, not packages that are somewhere deep in the distro's dependency tree. 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: side-tag with GCC 14.0.1 snapshot for Fedora 40
On Mon, Jan 15, 2024 at 2:15 PM Sérgio Basto wrote: > > On Mon, 2024-01-15 at 14:01 +0100, Jakub Jelinek wrote: > > Hi! > > > > The f40-build-side-81394 side-tag contains new > > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be > > tagged into rawhide shortly before the mass rebuild. > > > > If there is anything you'd like to rebuild against it before the mass > > rebuild (such as packages depending on Ada which like every year > > bumped > > sonames of its shared libraries), please do so soon. > > > I'd like bump soname of libjxl [1] and opencv > > [1] > https://src.fedoraproject.org/rpms/jpegxl These are unrelated to gcc, please handle them separately, preferably after the mass rebuild is finished. 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: Update to dav1d v1.3.0 including soname bump coming to rawhide
On Fri, Jan 12, 2024 at 7:04 PM Fabio Valentini wrote: > > On Thu, Jan 4, 2024 at 5:23 PM Fabio Valentini wrote: > > > > Hi all, > > > > I am planning to push the update for dav1d v1.3.0 to rawhide. It > > involves an soname bump from libdav1d.so.6 to libdav1d.so.7 due to > > minor ABI changes. According to the release notes, there are were no > > actual breaking changes to existing APIs, so the update should be > > safe: > > > > https://code.videolan.org/videolan/dav1d/-/blob/1.3.0/NEWS > > > > As far as I can tell, the following packages will need to be rebuilt: > > > > - ffmpeg > > - firefox > > - libavif > > - libheif > > - seamonkey > > - vlc > > - xine-lib > > > > The builds will be handled in a side-tag by me, other provenpackagers, > > or multimedia-sig members. > > I did some test builds in COPR, and they showed no regressions. So I > am running the dav1d v1.3.0 build and necessary rebuilds now, in the > side tag f40-build-side-81354. I will submit an update from the builds > in the side tag as soon as all builds have finished, which should be > later today (or at worst, tomorrow morning, depending on how long the > builds take). All builds are now done, and I have submitted the bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ae65daded4 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: Update to dav1d v1.3.0 including soname bump coming to rawhide
On Thu, Jan 4, 2024 at 5:23 PM Fabio Valentini wrote: > > Hi all, > > I am planning to push the update for dav1d v1.3.0 to rawhide. It > involves an soname bump from libdav1d.so.6 to libdav1d.so.7 due to > minor ABI changes. According to the release notes, there are were no > actual breaking changes to existing APIs, so the update should be > safe: > > https://code.videolan.org/videolan/dav1d/-/blob/1.3.0/NEWS > > As far as I can tell, the following packages will need to be rebuilt: > > - ffmpeg > - firefox > - libavif > - libheif > - seamonkey > - vlc > - xine-lib > > The builds will be handled in a side-tag by me, other provenpackagers, > or multimedia-sig members. I did some test builds in COPR, and they showed no regressions. So I am running the dav1d v1.3.0 build and necessary rebuilds now, in the side tag f40-build-side-81354. I will submit an update from the builds in the side tag as soon as all builds have finished, which should be later today (or at worst, tomorrow morning, depending on how long the builds take). 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] evolution-data-server libecal-2.0 soname version bump in rawhide
On Mon, Jan 8, 2024 at 11:06 AM Milan Crha wrote: > > On Mon, 2024-01-08 at 10:34 +0100, Milan Crha wrote: > > I'll handle those I've commit rights for, which is most of them. > > > > ... > > > >fedpkg build --target=f40-build-side-80962 > > > Hi, > the leftover packages to be done, for which I do not have commit > rights, are: > >elementary-calendar >evolution-chime (which is part of pidgin-chime) >gnome-panel >phosh > > Any help appreciated. elementary-calendar is now rebuilt in the side tag. 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
Update to dav1d v1.3.0 including soname bump coming to rawhide
Hi all, I am planning to push the update for dav1d v1.3.0 to rawhide. It involves an soname bump from libdav1d.so.6 to libdav1d.so.7 due to minor ABI changes. According to the release notes, there are were no actual breaking changes to existing APIs, so the update should be safe: https://code.videolan.org/videolan/dav1d/-/blob/1.3.0/NEWS As far as I can tell, the following packages will need to be rebuilt: - ffmpeg - firefox - libavif - libheif - seamonkey - vlc - xine-lib The builds will be handled in a side-tag by me, other provenpackagers, or multimedia-sig members. 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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On Mon, Dec 18, 2023 at 10:08 AM Pavel Raiskup wrote: > > On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote: > > Hello maintainers! > > > > Let me announce a new release of Mock Core Configs v39.3, aka > > the configuration files for Mock, the chroot build environment manager > > for building RPMs. > > > > The notable change in this release is that we are switching the default > > package_manager from DNF4 to DNF5, according to the F40 change: > > https://fedoraproject.org/wiki/Changes/BuildWithDNF5 > > Full release notes: > >https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3 > > > > We plan to push this update into Fedora Copr to get some early testing > > next week. Then, depending on the releng team, we might push this into > > Koji soon. The Bodhi updates links are here: > > > > F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0 > > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930 > > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40 > > EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053 > > EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46 > > > > Note that we **will not** push these updates into Fedora stable earlier > > than on Monday 2023-12-18 (but very likely we'll wait till the next > > year, depending on the feedback). > > And the push eventually happened, despite that I did not want it to > happen, yet. I probably messed up the Bodhi updates (I thought I > disabled the stable-by-time feature). Sorry, folks. We're now in the weird situation where this update is stable in F38, EPEL9, and EPEL8, but not stable in F39. Since it's already stable on the most stablest branches, can we get it stable in F39 too please? Having the latest and greatest Fedora release lag behind EPEL is weird. 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 clone subpackages during koji build stage
On Wed, Dec 13, 2023 at 4:57 PM Julio Faracco wrote: > > Hi everybody! > > Koji mocks does not access the internet during the build stage. > What are the recommendations when my project has some content inside > CMake to clone subrepos to compile my code? > > Do you have any guidelines for this? Honestly, I tried to google it, > but I'm not finding something useful or a real example. This situation can be handled by either 1. un-bundling subprojects (i.e. packaging them as separate packages and depending on them for the build), or 2. providing the sources for subprojects as separate tarballs and unpack them where expected during %prep step and usually Option 1 is preferred in Fedora, but it will depend on the exact circumstances and what kinds of subprojects you're dealing with. 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: Change of cronie and crontabs CIS compliance
On Wed, Dec 6, 2023 at 11:17 AM Ondrej Pohorelsky wrote: > > Hi everyone, > > For F40 I would like to change file permissions of few files that are > provided by cronie and crontabs and swap deny list for allow list. I'm not > really sure if I should make a change proposal. I figured I'll send an email > first and see the feedback. > > The driving force of this change is feedback from RHEL customers, that they > would like to have cronie and crontabs CIS compliant out of the box. Which > means changing some of the file permissions and swapping `cron.deny` for > `cron.allow`. As it stands now, they have to run their own scripts or dnf > plugin (post-transaction-actions) to ensure that each update doesn't > overwrite the file permissions they manually set. Just out of curiosity - what does CIS even stand for? The linked Red Hat docs don't expand the acronym, and googling for it obviously yields results for something entirely different 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 bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12
On Fri, Nov 17, 2023 at 1:34 AM Kevin Fenzi wrote: > > On Mon, Nov 13, 2023 at 07:25:10PM +0100, Fabio Valentini wrote: > > > > Yup, I've mentioned that in the bug I filed for python-bcrypt - > > It might be as simple as bumping the dependency on pyo3 from v0.15 to v0.19. > > I've made an attempt here: > https://src.fedoraproject.org/rpms/python-bcrypt/pull-request/9 All dependent packages have now moved off of pyo3 v0.15 to at least pyo3 v0.19.2+ or the latest v0.20, both of which should be fine with Python 3.12. Thank you all for your help! I will retire the packages for pyo3 v0.15 from rawhide now. Fabio -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12
On Fri, Nov 17, 2023 at 1:34 AM Kevin Fenzi wrote: > > On Mon, Nov 13, 2023 at 07:25:10PM +0100, Fabio Valentini wrote: > > > > Yup, I've mentioned that in the bug I filed for python-bcrypt - > > It might be as simple as bumping the dependency on pyo3 from v0.15 to v0.19. > > I've made an attempt here: > https://src.fedoraproject.org/rpms/python-bcrypt/pull-request/9 All dependent packages have now moved off of pyo3 v0.15 to at least pyo3 v0.19.2+ or the latest v0.20, both of which should be fine with Python 3.12. Thank you all for your help! I will retire the packages for pyo3 v0.15 from rawhide 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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks
On Fri, Nov 24, 2023 at 12:08 PM David King wrote: > > The latest released versions of libxml2 have a couple of important > changes in header files that have unintentionally caused some packages > to fail to build without modification, including: > > * several functions now accept or return a const xmlError struct > * cyclic dependencies in header files were fixed (by dropping some >includes) Sorry if the answer to this question is obvious - but shouldn't breaking changes like these cause an soname bump? I realize the whole "unintentional" part - but if these changes also affect ABI (the first sounds like it might do that), dependent packages would need to be rebuilt either way, wouldn't they? 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
Planned un-retirements of Pantheon DE related packages
Hi all, With elementary OS / Pantheon desktop upstream having made progress with supporting newer versions of GNOME (i.e. support for newer versions of libsoup, webkitgtk, gcr, etc.), it is now again possible to build the Pantheon desktop components on Fedora 38+ (after I had retired them from Fedora 37+). I am currently working on package re-reviews and un-retirements. I still have a sliver of hope that future releases of GNOME will be less disruptive than past ones, and that it might indeed be possible *some day* to have an official Pantheon Spin of Fedora (finally). 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 (2023-11-09)
On Thu, Nov 16, 2023 at 1:30 AM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > * AGREED: Fedora explicitly declines to support the LSB 5.0 or > > earlier. Packagers will remove any information that implies > > otherwise. No implementation of an LSB package may expressly state > > or offer compliance for any LSB module that Fedora does not or > > cannot comply with. (+6, 0, 0) (Son_Goku, 17:59:18) > > So Fedora has completely discarded any notion of backwards compatibility. > Sad. There's a difference between *claiming* LSB compliance (what you refer to as backwards compatibility ?) and actually *achieving* it. Claiming it (the thing we objected to) without achieving it (i.e. the status quo for many Fedora releases) is a lie that helps nobody. 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 bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12
On Mon, Nov 13, 2023 at 11:51 AM Neal Gompa wrote: > > On Sun, Nov 12, 2023 at 12:35 PM Fabio Valentini wrote: > > > > On Tue, Aug 1, 2023 at 5:43 PM Fabio Valentini wrote: > > > > > > There are applications in Fedora that still rely on *ancient* versions > > > of PyO3, potentially affected by this: > > > > > > - cpython: mercurial > > > - pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography > > > - pyo3 v0.16: python-y-py > > > - pyo3 v0.17: unused compat packages, will be retired > > > - pyo3 v0.18: matrix-synapse > > > > Hello again. > > > > It is now three months later, and three packages have moved to the > > latest available version of pyo3: > > > > - python-cryptography > > - python-y-py > > - matrix-synapse > > > > That leaves two packages that are stuck on pyo3 v0.15: > > > > - fapolicy-analyzer > > - python-bcrypt > > > > I have now filed bugs against both packages that they need to move to > > pyo3 v0.19.2+ ASAP on both Fedora 39 and Rawhide. > > Due to ABI changes in Python 3.12, they are not guaranteed to even > > work correctly on Python 3.12. > > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2249378 > > - https://bugzilla.redhat.com/show_bug.cgi?id=2249381 > > > > The mainline git version of python-bcrypt has already been adapted for > python 3.12, they just haven't made a release yet, it seems? > > https://github.com/pyca/bcrypt > > That said, it doesn't look like it needed code changes to make that > work, so it should be possible to just bump things? Yup, I've mentioned that in the bug I filed for python-bcrypt - It might be as simple as bumping the dependency on pyo3 from v0.15 to v0.19. It's not that easy for fapolicy-analyzer as far as I can tell, since it was affected by API changes between v0.15 and v0.19, last I checked. But there is now also an upstream PR for bumping the pyo3 version. 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 bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12
On Tue, Aug 1, 2023 at 5:43 PM Fabio Valentini wrote: > > There are applications in Fedora that still rely on *ancient* versions > of PyO3, potentially affected by this: > > - cpython: mercurial > - pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography > - pyo3 v0.16: python-y-py > - pyo3 v0.17: unused compat packages, will be retired > - pyo3 v0.18: matrix-synapse Hello again. It is now three months later, and three packages have moved to the latest available version of pyo3: - python-cryptography - python-y-py - matrix-synapse That leaves two packages that are stuck on pyo3 v0.15: - fapolicy-analyzer - python-bcrypt I have now filed bugs against both packages that they need to move to pyo3 v0.19.2+ ASAP on both Fedora 39 and Rawhide. Due to ABI changes in Python 3.12, they are not guaranteed to even work correctly on Python 3.12. - https://bugzilla.redhat.com/show_bug.cgi?id=2249378 - https://bugzilla.redhat.com/show_bug.cgi?id=2249381 The packages for v0.16 and v0.18 of pyo3 are now unused in Fedora Rawhide - I will retire them later today. The packages for pyo3 v0.15 will be retired in about *ONE WEEK*, but no earlier than Monday, Nov 20. They are known to be problematic and broken with Python 3.12, so no packages should use them. That leaves the cpython crate and its only dependent package - mercurial. The upstream project for the cpython crate has been marked as no longer actively maintained, and recommends users to switch to pyo3 instead: https://github.com/dgrunwald/rust-cpython/commit/e81 I've now also filed a bug against mercurial: https://bugzilla.redhat.com/show_bug.cgi?id=2249383 Fabio ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rust bindings for Python (pyo3 versions <0.19, cpython) broken with Python 3.12
On Tue, Aug 1, 2023 at 5:43 PM Fabio Valentini wrote: > > There are applications in Fedora that still rely on *ancient* versions > of PyO3, potentially affected by this: > > - cpython: mercurial > - pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography > - pyo3 v0.16: python-y-py > - pyo3 v0.17: unused compat packages, will be retired > - pyo3 v0.18: matrix-synapse Hello again. It is now three months later, and three packages have moved to the latest available version of pyo3: - python-cryptography - python-y-py - matrix-synapse That leaves two packages that are stuck on pyo3 v0.15: - fapolicy-analyzer - python-bcrypt I have now filed bugs against both packages that they need to move to pyo3 v0.19.2+ ASAP on both Fedora 39 and Rawhide. Due to ABI changes in Python 3.12, they are not guaranteed to even work correctly on Python 3.12. - https://bugzilla.redhat.com/show_bug.cgi?id=2249378 - https://bugzilla.redhat.com/show_bug.cgi?id=2249381 The packages for v0.16 and v0.18 of pyo3 are now unused in Fedora Rawhide - I will retire them later today. The packages for pyo3 v0.15 will be retired in about *ONE WEEK*, but no earlier than Monday, Nov 20. They are known to be problematic and broken with Python 3.12, so no packages should use them. That leaves the cpython crate and its only dependent package - mercurial. The upstream project for the cpython crate has been marked as no longer actively maintained, and recommends users to switch to pyo3 instead: https://github.com/dgrunwald/rust-cpython/commit/e81 I've now also filed a bug against mercurial: https://bugzilla.redhat.com/show_bug.cgi?id=2249383 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: Didn't get an email about a new merge request on a package
On Wed, Nov 8, 2023 at 1:03 PM Richard W.M. Jones wrote: > > On Wed, Nov 08, 2023 at 06:49:19AM -0500, Neal Gompa wrote: > > On Wed, Nov 8, 2023 at 6:39 AM Richard W.M. Jones wrote: > > > > > > Normally I get an email when someone creates a merge request on a > > > Fedora package that I'm (co-)maintaining. However I don't seem to > > > have got an email about this specific request: > > > > > > https://src.fedoraproject.org/rpms/libguestfs/pull-request/8 > > > > > > and I wonder why. (Checked filters etc already.) > > > > > > One thing that did happen recently is we moved the libguestfs mailing > > > list to a new host, and that meant dropping the old email address > > > (libgues...@redhat.com) but AFAIK I don't think that email address is > > > involved here. > > > > > > Also: > > > > > > > > > https://src.fedoraproject.org/rpms/libguestfs/settings#publicnotifications-tab > > > -> "Pull-requests notifications" > > > > > > the field is empty. I don't recall ever encountering this field or > > > setting it for any Fedora project. I checked a few other projects I > > > maintain and they are also empty. > > > > Do you have notifications configured in > > notifications.fedoraproject.org? I believe no notifications are > > configured by default. > > It says: > > My Rules > > No Rules > [Create a Rule] > > I don't recall ever touching this. That's the new notifications system, where everybody started off with a clean slate. Apparently migrating settings from the old notifications system to the new one was not feasible. However, the old notifications system is *not* decommisioned yet, so the fact that you've not set up the new one does not matter (yet). So to me this sounds like there was just some hiccup somewhere that resulted in the email not being sent. 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: Wrong branch built into side tags, what to do?
On Mon, Nov 6, 2023 at 6:28 PM Julian Sikorski wrote: > > Am 06.11.23 um 17:17 schrieb Michael J Gruber: > > > > > > Am Mo., 6. Nov. 2023 um 17:12 Uhr schrieb Fabio Valentini > > mailto:decatho...@gmail.com>>: > > > > On Mon, Nov 6, 2023 at 5:09 PM Julian Sikorski > <mailto:beleg...@gmail.com>> wrote: > > > > > > Hello, > > > > > > I have accidentally built f39/rawhide branch of gnumeric and > > > gnome-chemistry-utils for f38 and f37 side tags (f39 too but > > rawhide and > > > f39 are the same commit). Can this be fixed? Or is the effort not > > worth > > > it? Thanks. > > > > Are the contents of the package the same except for the changelog > > entries / Release field? > > Then I would not bother trying to fix it. > > > > It is kind of unfortunate that koji does not have guardrails in place > > to prevent building branch X against target Y!=X, but that's probably > > something that actually needs to work for Modularity or other > > configurations ... > > > > Fabio > > > > The spec files differ in content (as far as flatpaks are concerned). But > > since this package uses separate branches without forwards/merges but > > cherry-picks only, i.e. clearly separates branches in git, it would be > > surprising not to care about the branch now ... I guess git branches are > > still somewhat foreign to how we drive our dist. > > > > Michael > > > > Hello, > > for gnome-chemistry-utils, the differences are only with release field > and changelog. For gnumeric, f37 has a slightly different > desktop-file-install call in addition. > I would prefer to fix it properly. Due to fewer mass rebuilds older > gnome-chemistry-utils branches should have lower release than the newer > ones. If the problem remains unfixed, I would have to bump the release > to make sure the numbers don't go backwards. For gnumeric this is a bit > less of a problem since there are new versions still being released so > release number would reset soon-ish anyway. > I tried untagging the erroneous builds with > $ koji untag-build > While it worked, I was not able to rebuild from correct branches because > koji was complaining that a build already exists: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=108660999 > https://koji.fedoraproject.org/koji/taskinfo?taskID=108661023 > > Can I request to have the builds removed so that they can be rebuilt > from correct branches? No, NVRs for successful builds are unique in koji. The only way to resubmit something that already succeeded is to bump release. 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
