Orphaned rubygem-rack-restful_submit
I have decided to orphan rubygem-rack-restful_submit for multiple reasons: * It would need adjustments for Rack 3.x (which will come to Fedora together with Ruby on Rails 8). * Upstream has long abandoned this package (have not accepted the fixes for Rack 2.x [1]) * I have no use for this package. Vít [1]: https://github.com/martincik/rack-restful_submit/pull/6 OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remove openh264?
Leigh Scott wrote: > x264 is superior for playback, Playback in the FFmpeg/libx264 stack is actually done by a builtin decoder in FFmpeg, NOT by libx264. FFmpeg has no builtin H.264 encoder. libx264 has no decoder. So they have to be used together. (But both are actually more featureful than the corresponding half of OpenH264.) > Most users would be better served using gstreamer1-plugins-ugly and > ffmpeg-libs from rpmfusion. And so you also need gstreamer1-plugin-libav (which is actually built against FFmpeg, not the libav fork) in addition to gstreamer1-plugins-ugly. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Remove openh264?
The whole topic would have been much easier if we didn't decide to remove hardware de/encoders a few releases ago. The number of users needing openh264 would shrink significantly. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
On 10. 06. 25 8:46, Leigh Scott wrote: The new macros are unlikely to work for nemo-extensions. What makes you assume that? https://src.fedoraproject.org/rpms/nemo-extensions/pull-request/7 I will probably end up defining my own macros in it's spec file. If your custom macros will use python setup.py install, they will beak when setuptools removes that. We will not be removing the deprecated macros before then, so defining your own macros has no point. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
Miro Hrončok wrote: > On 10. 06. 25 8:46, Leigh Scott wrote: > > The new macros are unlikely to work for nemo-extensions. > > What makes you assume that? > https://src.fedoraproject.org/rpms/nemo-extensions/pull-request/7 I couldn't figure out how to use the new macros with the multiple python sources. Thank you for the PR. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Inquiry About Fedora Models
Hi everyone, Will there be a version similar to this one: https://huggingface.co/RedHatAI for Fedora? Thank you! Best, - Lee -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 43 Python 3.14 mass rebuild status
Hello, The Python 3.14 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3682 out of 4259 source packages, with 577 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.14, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.14 tracking bug. You can verify your package builds with Python 3.14 via a scratch build: $ koji build --scratch f43-python or $ fedpkg build --scratch --target f43-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f43-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. Karolina Maintainers by package: APLpysergiopr DisplayCAL jistone ngompa Mayavi orion ansible-lint pnemade ara dmsimard asv qulogic audiotubethunderbirdtr avogadro2-libs sagitter awscli2 davdunc nforro azure-clijcline bandit mikelo2 misc binwalk ajax swt2c blender design-sw ignatenkobrain luya music slaanesh bodhi-server abompard humaton lenkaseg borgbackup fschwarz bout++ davidsch buildbot besser82 ignatenkobrain limb ngompa radez buildstream atim jjardon calibre chkr kevin zbyszek cantera fuller sic capstone rebus ret2libc certbot nb cfn-lint music chirpjskarvad cjdnssdgathman conda-build orion copr-backend frostyx msuchy praiskup cozy suve criu adrian rstoyanov cura churchyard diceware kushal did lzachar psss diffoscope zbyszek distro-info suraia dlib principis thunderbirdtr dolfin zbyszek duplicitylimb dxf2gcodedwrobel electrum js emacs-jedi melmorabity eric yselkowitz fastapi-cli music pwouters rominf fawltydeps gui1ty fedrqgotmax23 fontmake music gingasergiopr git-filter-repo asn salimma glances aekoroglu jonathanspw gnofract4d yselkowitz go-vendor-tools gotmax23 go2rpm alexsaezm eclipseo gotmax23 mikelo2 google-api-python-client limb mbaldessari mikelo2 gr-air-modes jskarvad gr-funcube jskarvad gr-hpsdr jskarvad gr-iqbal jskarvad gr-osmosdr cottsay jskarvad gr-rds jskarvad sharkcz grpc defolos neil httpie churchyard mikelo2 ikiwiki thm input-remapper alexpl kittyatim jonathanspw solopasha zawertun kiwi-boxed-pluginngompa kmymoney rdieter vascom kurchu ngompa kvircnucleo libarcus churchyard libpeas amigadave kalev libunity rdieter lilv nphilipp tartina linode-cli cicku mikelo2 nb liquidctlsuve lutris bunnyapocalypse farchord mailman3 ngompa salimma mailman3-fedmsg-plugin abompard matrix-synapse dcallagh v02460 mirrormanager2 abompard mkdocs-material dcavalca monkeytype dcavalca salimma mopidy girst mopidy-mpd girst mrchem jussilehtola mu churchyard kushal muse oget myst-nb jjames nanopb topazus nordugrid-arcellert novelwriter fed500 nvme-stastbzatek ocrmypdf qulogic odcs cqi hlin lsedlar qwan onnx aalvarez dherrera openapi-python-client dogukancagatay opencv hhorak jkucera jridky kwizart openms sagitter openvino aekoroglu packit lachmanfrantisek lbarczio mfocko mmassari nforro nikromen ttomecek paraview orion sagitter patool eclipseo pcp agerstmayr fberat jkurik lchilton nathans samfeifer wcohen pcs cfeist idevat mlisik mpospisi omular tojeline petscsagitter picard alexlan cicku gbcox poezio orphan protobuf adrian jonathanspw mizdebsk orion salimma psi4 jussilehtola pychess bruno dcavalca pychromecast pbrobin
Re: Packaging sccache – collaborator request!
On 10 June 2025 20:15:25 CEST, "Marcus Müller" wrote: > - the spec generated by rust2rpm doesn't tell me much; an rpmbuild of the >result lists about 100 missing dependencies of the kind "crate(base64/default)" Most dependencies are actually already packaged, but upstream is outdated (see rust-base64 version for example). Maybe start by trying to resolve most of the dependabot PRs upstream. Although upstream's head CI is broken, so it seems it will be a journey. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging sccache – collaborator request!
On Tue, Jun 10, 2025, 20:41 Cristian Le via devel < devel@lists.fedoraproject.org> wrote: > > > On 10 June 2025 20:15:25 CEST, "Marcus Müller" wrote: > > - the spec generated by rust2rpm doesn't tell me much; an rpmbuild of > the result lists about 100 missing dependencies of the kind > "crate(base64/default)" > > Most dependencies are actually already packaged, but upstream is outdated > (see rust-base64 version for example). Maybe start by trying to resolve > most of the dependabot PRs upstream. Although upstream's head CI is broken, > so it seems it will be a journey. > There is an in-progress package review for sccache already: https://bugzilla.redhat.com/show_bug.cgi?id=2362051 It's currently being built with a few features disabled because they would pull in a lot more dependencies, but those can get enabled piece by piece as needed later. 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 > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
On 10. 06. 25 13:59, Cristian Le via devel wrote: I believe some clarification for this proposal is in order What kind of clarification do you think is needed? On 2025/06/07 14:49, Aoife Moloney wrote: Old: %build %py3_build New: %build %pyproject_wheel The %py3_build expands to `python3 setup.py build` [1] which is the interface that is being removed. %pyproject_wheel expands to `pip wheel` [2], which will read setup.py and build (presumably without calling the removed interface). More or less, yes. It might not read setup.py if pyproject.toml says otherwise. But for 99.9 % packages that worked with %py3_build, this is the case, yes. Do you believe such technical detail needs to be in the proposal? That's why changing the interface to %pyproject_wheel would be enough, as long as pip would be working properly with the new setuptools (should not give a deprecation warning if run currently). Well, that's not enough, because then you *also* need to use %pyproject_buildrequires and %pyproject_install. (As shown in the example in the proposal.) But using the 3 macros (and updating the %files section from egg-info to dist-info) instead of the removed 2 is indeed enough, yes. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No FESCo meeting today
Hi! We have nothing on the agenda. Also no tickets to announce here. And many people are travelling to DevConf.cz. The meeting is cancelled today. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning rubygem-shoulda-matchers
Current version of rubygem-shoulda-matchers will get broken by Ruby on Rails 8 and it would need updated. But because nothing else depends on this package anymore, I have decided to orphan in instead. Cheers, Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20250610.n.0 changes
OLD: Fedora-Rawhide-20250609.n.0 NEW: Fedora-Rawhide-20250610.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:0 Upgraded packages: 58 Downgraded packages: 0 Size of added packages: 45.84 KiB Size of dropped packages:0 B Size of upgraded packages: 1.30 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -149.52 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: perl-Config-Onion-1.007-2.fc43 Summary: Layered configuration, because configs are like ogres RPMs:perl-Config-Onion Size:25.72 KiB Package: perl-Dispatch-Class-0.04-1.fc43 Summary: Dispatch on the type (class) of an argument RPMs:perl-Dispatch-Class Size:20.12 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alglib-4.05.0-1.fc43 Old package: alglib-4.04.0-3.fc43 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 10.61 MiB Size change: 317.89 KiB Changelog: * Mon Jun 09 2025 Sandro Mani - 4.05.0-1 - Update to 4.05.0 Package: backintime-1.5.5-1.fc43 Old package: backintime-1.5.4-1.fc43 Summary: Simple backup tool inspired from the Flyback project and TimeVault RPMs: backintime-common backintime-plugins backintime-qt Size: 892.86 KiB Size change: -508 B Changelog: * Mon Jun 09 2025 Johannes Lips - 1.5.5-1 - update to latest upstream release Package: bpftrace-0.23.5-1.fc43 Old package: bpftrace-0.23.0-1.fc43 Summary: High-level tracing language for Linux eBPF RPMs: bpftrace Size: 8.58 MiB Size change: 39.77 KiB Changelog: * Mon Jun 09 2025 Augusto Caringi - 0.23.5-1 - Rebased to version 0.23.5 Package: bwping-2.6-2.fc43 Old package: bwping-2.5-7.fc42 Summary: Measure bandwidth and response times using ICMP RPMs: bwping Size: 89.11 KiB Size change: -813 B Changelog: * Mon Jun 09 2025 Alessio - 2.6-1 - Update to 2.6 * Mon Jun 09 2025 Alessio - 2.6-2 - Update to 2.6 Package: cups-filters-1:2.0.1-6.fc43 Old package: cups-filters-1:2.0.1-5.fc43 Summary: OpenPrinting CUPS filters for CUPS 2.X RPMs: cups-filters cups-filters-driverless Size: 934.40 KiB Size change: 1.65 KiB Changelog: * Mon Jun 09 2025 Zdenek Dohnal - 1:2.0.1-6 - CUPS restart has to happen after universal filter is gone for good (in posttrans) (fedora#2370978) Package: fedora-upgrade-42.2-1.fc43 Old package: fedora-upgrade-42.1-1.fc43 Summary: Upgrade Fedora to next version using dnf upgrade (unofficial tool) RPMs: fedora-upgrade remove-retired-packages Size: 41.31 KiB Size change: 85 B Changelog: * Mon Jun 09 2025 Miroslav Such?? 42.2-1 - do not check if F42 is prerelease Package: frama-c-30.0-11.fc43 Old package: frama-c-30.0-10.fc43 Summary: Framework for source code analysis of C software RPMs: frama-c frama-c-doc frama-c-emacs Size: 888.91 MiB Size change: -1017.79 KiB Changelog: * Mon Jun 09 2025 Jerry James - 30.0-11 - Rebuild for why3 1.8.1 Package: frescobaldi-4.0.3-1.fc43 Old package: frescobaldi-4.0.2-1.fc43 Summary: Edit LilyPond sheet music with ease! RPMs: frescobaldi Size: 6.98 MiB Size change: -8.22 KiB Changelog: * Wed Jun 04 2025 Python Maint - 4.0.2-2 - Rebuilt for Python 3.14 * Mon Jun 09 2025 Gwyn Ciesla - 4.0.3-1 - 4.0.3 Package: golang-github-elliotchance-orderedmap-3.1.0-1.fc43 Old package: golang-github-elliotchance-orderedmap-2.0.1-9.fc42 Summary: An ordered map in Go with O(1) for Set, Get, Delete and Len RPMs: golang-github-elliotchance-orderedmap-devel Size: 19.54 KiB Size change: 2.81 KiB Changelog: * Mon Jun 09 2025 Julien Rische - 3.1.0-1 - Rebase to version 3.1.0 Resolves: rhbz#2124117 Package: gram_grep-0.9.8-1.fc43 Old package: gram_grep-0.9.7-1.fc43 Summary: Search text using a grammar, lexer, or straight regex RPMs: gram_grep Size: 2.08 MiB Size change: 19.25 KiB Changelog: * Sun May 11 2025 Benjamin A. Beasley - 0.9.8-1 - Update to 0.9.8 Package: kbd-2.8.0-1.fc43 Old package: kbd-2.7.1-3.fc42 Summary: Tools for configuring the console (keyboard, virtual terminals, etc.) RPMs: kbd kbd-legacy kbd-misc Size: 3.73 MiB Size change: -61.95 KiB Changelog: * Mon Jun 09 2025 Vitezslav Crhonek - 2.8.0-1 - Update to kbd-2.8.0 Resolves: #2369419 Package: kryoptic-1.2.0-1.fc43 Old package: kryoptic-1.1.0-1.fc43 Summary: PKCS #11 software token written in Rust RPMs: kryoptic kryoptic-tools Size: 4.39 MiB Size change: 141.91 KiB Changelog: * Mon Jun 09 2025 Jakub Jelen - 1.2.0-1 - kryoptic-1.2.0-1 (#2371228) Package: libeconf-0.7.9-1.fc43 Old package
Re: Dropping i686 from NodeJS build architectures
On Tue, Jun 10, 2025 at 03:17:56PM +0200, Jan Stanek wrote: > Hello everyone! > Recently, we tried to enable the upstream test suite to be run when > building NodeJS packages, and we ran into a Y2038 bug (see [1] for the > moment we noticed it). There are also some upstream issues [2] related > to this problem on 32-bit architectures. > > [1]: > https://src.fedoraproject.org/rpms/nodejs22/pull-request/10#comment-251188 > [2]: https://github.com/nodejs/node/issues/45906 > > After discussing with upstream, it turns out that they do not provide > i686 builds, and they generally do not seem to support 32-bit > architectures any more. In light of this revelation, I would like to > propose dropping the i686 architecture from the `%nodejs_arches` macro > and thus consequently from the builds of all NodeJS related software. > > While the general rebuild can be hopefully handled by me or my team in > a side-tag, I know that nodejs is used in builds of other software > (Firefox comes to mind as an example). If you are a consumer of nodejs > in any way, would the drop affect you in any way? If so, do you have > an idea what we can do to help alleviate the problems? It'd help a lot to compile a list of affected packages using repoquery… Without that it's hard to give any definite answers. FWIW, firefox is not compiled for i386 [1]. [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2722308 Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inquiry About Fedora Models
You can run vllm, instructlab, etc on Fedora. It just won't be bundled together and won't be tightly coupled with Red Hat's other offerings in the way that it would be on RHEL AI. There is a Fedora AI SIG: https://fedoraproject.org/wiki/SIGs/AI-ML As well as a Matrix channel: #ai-ml:fedoraproject.org On Tue, Jun 10, 2025 at 9:23 AM Josh Boyer wrote: > On Tue, Jun 10, 2025 at 5:32 AM Lee Thomas Stephen > wrote: > > > > Hi everyone, > > > > Will there be a version similar to this one: > > https://huggingface.co/RedHatAI for Fedora? > > I am not aware of any Fedora community projects around creating, > tuning, distilling, or otherwise optimizing models, so it's unlikely. > > josh > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
On 10. 06. 25 15:15, Cristian Le via devel wrote: Could also document that a minimal pyproject.toml can be added as ``` [build-system] requires = ["setuptools"] build-backend = "setuptools.build_meta" ``` I've seen those around, but I don't know if it actually makes a difference in these context. Adding such pyproject.toml has no benefit. It's more or less the same as not having it (except the default backend in that case is setuptools.build_meta:__legacy__, but I don't think it's any different). -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
I believe some clarification for this proposal is in order On 2025/06/07 14:49, Aoife Moloney wrote: Old: %build %py3_build New: %build %pyproject_wheel The %py3_build expands to `python3 setup.py build` [1] which is the interface that is being removed. %pyproject_wheel expands to `pip wheel` [2], which will read setup.py and build (presumably without calling the removed interface). That's why changing the interface to %pyproject_wheel would be enough, as long as pip would be working properly with the new setuptools (should not give a deprecation warning if run currently). [1]: https://src.fedoraproject.org/rpms/python-rpm-macros/blob/rawhide/f/macros.python3#_46 [2]: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/pyproject_wheel.py#_46 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dropping i686 from NodeJS build architectures
Hello everyone! Recently, we tried to enable the upstream test suite to be run when building NodeJS packages, and we ran into a Y2038 bug (see [1] for the moment we noticed it). There are also some upstream issues [2] related to this problem on 32-bit architectures. [1]: https://src.fedoraproject.org/rpms/nodejs22/pull-request/10#comment-251188 [2]: https://github.com/nodejs/node/issues/45906 After discussing with upstream, it turns out that they do not provide i686 builds, and they generally do not seem to support 32-bit architectures any more. In light of this revelation, I would like to propose dropping the i686 architecture from the `%nodejs_arches` macro and thus consequently from the builds of all NodeJS related software. While the general rebuild can be hopefully handled by me or my team in a side-tag, I know that nodejs is used in builds of other software (Firefox comes to mind as an example). If you are a consumer of nodejs in any way, would the drop affect you in any way? If so, do you have an idea what we can do to help alleviate the problems? Looking forward to any feedback! Best regards, -- Jan Stanek Software Engineer Red Hat IM: @jstanek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inquiry About Fedora Models
On Tue, Jun 10, 2025 at 5:32 AM Lee Thomas Stephen wrote: > > Hi everyone, > > Will there be a version similar to this one: > https://huggingface.co/RedHatAI for Fedora? I am not aware of any Fedora community projects around creating, tuning, distilling, or otherwise optimizing models, so it's unlikely. josh -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Packaging sccache – collaborator request!
Hi everyone, I've been using sccache [1] as wrapping compiler cacher, not unlike `ccache`, but with more storage backend options, and at least the option to do what `distcc` has classically been used for, but with auto-distribution of toolchains (!). It's what mozilla uses for their software builds, and supports C, C++, and Rust. Now, to make my life easier and to get the ick out of installing sccache, I'd like to package that as Fedora package. As far as license is concerned, I think that should be fine – it's Apache-2.0-licensed. Thing that I'm not clear about is how to approach packaging software like that for Fedora: - It's rust, and cargo pulls down a host of dependencies for the build. - No idea how make it use things as packaged by fedora when available, and how to make a license SBOM for the rest. - the spec generated by rust2rpm doesn't tell me much; an rpmbuild of the result lists about 100 missing dependencies of the kind "crate(base64/default)" - it exists in different "configurations" (with the distributed compilation agent, and without) It seems to be a solvable problem; debian testing does ship the current release. Now, I'm not a Rust dev, but I'll happy to do the RPM, care about updates, sort the occasional bug, etc. But putting me as sole maintainer would probably be a misjudgement of my own capabilities. Would someone want to share this burden with me? Best regards, Marcus [1] https://github.com/mozilla/sccache -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal: Deprecate RPM Macros for setup.py-based Python Builds (self-contained)
On 2025/06/10 15:08, Miro Hrončok wrote: On 10. 06. 25 13:59, Cristian Le via devel wrote: I believe some clarification for this proposal is in order What kind of clarification do you think is needed? Not necessarily in the change proposal, but for the people who were confused in this email thread. On 2025/06/07 14:49, Aoife Moloney wrote: Old: %build %py3_build New: %build %pyproject_wheel The %py3_build expands to `python3 setup.py build` [1] which is the interface that is being removed. %pyproject_wheel expands to `pip wheel` [2], which will read setup.py and build (presumably without calling the removed interface). More or less, yes. It might not read setup.py if pyproject.toml says otherwise. But for 99.9 % packages that worked with %py3_build, this is the case, yes. Could also document that a minimal pyproject.toml can be added as ``` [build-system] requires = ["setuptools"] build-backend = "setuptools.build_meta" ``` I've seen those around, but I don't know if it actually makes a difference in these context. Do you believe such technical detail needs to be in the proposal? Your call on this, if you expect that you need to clarify the point later on as well, or if the clarification in this mailing list is sufficient. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
