Strange compile error with math.h for 42
Hey all-
I’m trying to fix build failures for swift-lang on F42 and while
I’ve fixed a number of places where wasn’t explicitly
defined, I’m now getting a strange compile error regarding math.h and
cmath that I can’t reproduce outside of a full build:
```
54 | #if __has_include()
55 | #include
| `- note: in file included from
/builddir/build/BUILD/swift-lang-6.0.3-build/usr/lib/swift/_FoundationCShims/_CStdlib.h:55:
56 | #endif
57 |
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:11:
note: in file included from
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:
34 | #define _GLIBCXX_MATH_H 1
35 |
36 | # include
| `- note: in file included from
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:
37 |
38 | using std::abs;
/usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/cmath:100:3:
error: redefinition of 'acos'
98 | #ifndef __CORRECT_ISO_CPP_MATH_H_PROTO
99 | inline _GLIBCXX_CONSTEXPR float
100 | acos(float __x)
| |- error: redefinition of 'acos'
| `- note: previous definition is here
101 | { return __builtin_acosf(__x); }
```
https://koji.fedoraproject.org/koji/taskinfo?taskID=128439616
What I don’t get is that it built fine before on F42/Rawhide (and uses
the previously built swift rpm as part of its build process), so I guess
I don’t know what changed.
Thanks for any help!
Ron--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [rfc] mass package change to introduce sysusers.d configs
On Sun, Jan 26, 2025 at 11:08 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jan 25, 2025 at 04:32:54PM +, Gary Buhrmaster wrote: > > On Sat, Jan 25, 2025 at 11:05 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > Updated diff: > > > > > Zbyszek > > > > I have a preference for seeing packages follow > > the current packaging guidelines (that I can find) > > that say: > > > > Create a .sysusers file with the user definition and > > add it to the specfile as a source. > > > > The current diff mostly just inlines the creation of > > a sysusers file, which (while there are always > > special cases) does not seem to follow the > > guidelines. If we are going to make a mass > > change, should we not try to follow the > > guidelines? Or are the guidelines going to > > be changed to recommend not using > > separate .sysusers files? > > The latter: https://pagure.io/packaging-committee/pull-request/1436. > > The reason for the separate source file was to make the > %sysusers_create_compat > macro work. The new solution in rpm is _much_ nicer and works just > fine with either a separate source file or creation in %prep and also > a file in the upstream tarball. In my patches, I used the inline creation > because the definitions often used macros. In the long term, maintainers > could just push those files upstream and we can drop our creation again. Wouldn't the config-file-as-separate-source-file approach would be more or less backwards compatible, whereas creating the config snippet in-line is only compatible with F42+? Naively, I would think that the more-or-less-backwards-compatible approach would be easier to conditionalize so changes can continue to be cherry-picked or even merged to stable branches. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal for vendoring/bundling golang packages by default
On Sun, Jan 26, 2025 at 1:03 AM Jan Drögehoff wrote: > > Fabio Valentini wrote: > > On Fri, Jan 24, 2025 at 10:23 PM Jan Drögehoff sentrycraft...@gmail.com > > wrote: > > > I'm generally in favor of this, especially since it would establish a > > > status quo that could benefit other languages where the usual way of > > > dealing with dependencies is incompatible with distributions. > > > You are aware that 1) this request is explicitly targeting Golang > > packages only, and 2) building with vendored dependencies is *already* > > allowed (regardless of language ecosystem) when not doing so would > > place an undue maintenance burden on the packager? > > yes to 1, I think I know what you are talking about with 2 but as I read the > main guidelines you are allowed to vendor dependencies but it is very much > discouraged, though I am unsure where you got the burden part from. It is discouraged, yes, but it is already *allowed* so long as you handle it correctly. The change proposed here for Go is only about changing the default approach from "try to build without vendoring dependencies" to "build with vendored dependencies". I'm not sure what it is that you're actually arguing against 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: Applying code layout optimization to postgresql16 RPMs in Fedora 41 gave a 3%-6% improvement in IPC
On 12/5/24 09:45, Miro Hrončok wrote:
> On 04. 12. 24 20:32, William Cohen wrote:
>> On 11/21/24 17:32, Miro Hrončok wrote:
>>> On 21. 11. 24 23:11, William Cohen wrote:
Sediment has been designed to work with the RPM build process.
Currently, one needs to use modified RPM macros. These can be created
quickly by writing the output of the sediment make_sediment_rpmmacros
command into ~/.rpmmacros. One will also need to define set the pgo
macro to 1 for the rpmbuild process. The rpm spec file has minimal
modifications. It has the callgraph files stored as a source file and
a defines the global call_graph to the source file that holds the call
graph.
>>>
>>> Hey Will,
>>>
>>> let's say I wan to try this for Python. Where do I start? The README on
>>> https://github.com/wcohen/sediment is not very helpful.
>>>
>>> This is what I did based on your email:
>>>
>>> $ sudo dnf --enable-repo=updates-testing install sediment
>>> ...
>>> Installing sediment-0:0.9.3-1.fc41.noarch
>>>
>>> I run make_sediment_rpmmacros, it gives me some macros. Now I am supposed
>>> to put those to ~/.rpmmacros. Exccept I never build Python loclly, I use
>>> Koji or mock. I can probably amend this to use %global and insert it to
>>> python3.14.spec. But what else I need to do? Do you have a step by step
>>> kind of document I can follow?
>>>
>>
>>
>> Hi Miro,
>>
>> The tooling doesn't yet fit your work flow of building packages in
>> koji and mock. I am looking into ways of addressing that issue.
>>
>> I an earlier email I mentioned the important thing was have good
>> profiling data. Do you have suggestions on some benchmarks that would
>> properly exercise the python interpreter? I have used pyperformance
>> (https://github.com/python/pyperformance) to get some call graph data
>> for python and added that to a python3.13 srpm available at
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=126526066. Note
>> Koji is NOT building code layout optimization. One would still need
>> to build locally python3.13-3.13.0-1.fc41.src.rpm with sediment-0.9.4
>> (https://koji.fedoraproject.org/koji/buildinfo?buildID=2596791)
>> installed and ~/.rpmmacros following steps:
>>
>> make_sediment_rpmmacros > ~/.rpmmacros
>> rpm -Uvh python3.13-3.13.0-1.fc41.src.rpm
>> cd ~/rpmbuild/SPECS
>> rpmbuild -ba --define "pgo 1" python3.13.spec
>>
>> The notable difference in the python3.13.spec file is the addition of:
>>
>> # Call graph information
>> SOURCE12: perf_pybenchmark.gv
>> %global call_graph %{SOURCE12}
>>
>> The perf_pybenchmark.gv was generated with steps:
>>
>> python3 -m pip install pyperformance
>> perf record -e branches:u -j any_call -o perf_pybenchmark.data
>> pyperformance run -f -o fc41_x86_python_baseline.json
>> perf report -i perf_pybenchmark.data --no-demangle
>> --sort=comm,dso_from,symbol_from,dso_to,symbol_to > perf_pybenchmark.out
>> perf2gv < perf_pybenchmark.out > perf_pybenchmark.gv
>>
>> Added the file to the python srpm:
>>
>> cp perf_pybenchmark.gv ~/rpmbuild/SOURCES/.
>> # edit ~/rpmbuild/SPECS/python3.13.spec to add call graph info
>> The improvements were mixed between the code layout optimized python
>> and the baseline version of the pyperformance benchmarks. This can be
>> seen in the attached python_pgo.out generated by:
>>
>> python3 -m pyperf compare_to fc41_x86_python_baseline.json
>> fc41_x86_python_pgo.json --table > python_pgo.out
>>
>> It looks like a number of the benchmarks are microbenchmarks that are
>> unlikely the benefit much for the code layout optimizations.
>>
>> Are there other python performance tests that you would suggest that
>> have have larger footprint and would better gauge the possible
>> performance improvement from the code layout optimization?
>>
>> Are there better python code examples to collect profiling data on?
> Hey Will,
>
> thanks for looking into this.
>
> For your question: Upstream is using this for PGO:
>
> $ python3.14 -m test --pgo
>
> Or:
>
> $ python3.14 -m test --pgo-extended
>
> In spec, this can be used:
>
> LD_LIBRARY_PATH=./build/optimized ./build/optimized/python -m test ...
>
> ---
>
> What is the blocker to run this in Koji/mock?
>
> You do `make_sediment_rpmmacros > ~/.rpmmacros`.
>
> What's the issue with %defining such macros at spec level?
>
Hi,
I have reworked the technique to avoid using a .rpmmacros file and have
everything in the spec file. The upstream sediment documentation page has been
updated to describe how to do this:
https://github.com/wcohen/sediment/blob/master/docs/pop.rst#providing-compiler-and-linker-options-in-a-rpm-spec-file
There is an example patch for the python3.13.spec file at :
https://github.com/wcohen/sediment/blob/master/docs/examples/python_layout.patch
The modified SRPM was successfully built as a scratch build on Fedora's koji:
https://koji.fedoraproject.org/koji/taskinfo?taskID=128437060
That s
Re: Fedora Linux f42 Mass Rebuild is finished
Were the FTBFS bugs filed differently this time? It appears that there were actually two FTBFS bugs filed against Audacity (https://bugzilla.redhat.com/show_bug.cgi?id=2339522 and https://bugzilla.redhat.com/show_bug.cgi?id=2339913) that both reference the same Koji task, but then the first bug was marked as a duplicate of the later one by releng shortly after its creation? Also, it appears that the FTBFS bugs for the mass rebuild have been linked to the FTBFS tracker from F41 (https://bugzilla.redhat.com/show_bug.cgi?id=2260875), can this be fixed so there is a FTBFS tracker for F42 separate from F41? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [rfc] mass package change to introduce sysusers.d configs
On Sun, Jan 26, 2025 at 2:27 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Jan 26, 2025 at 12:36:33PM +0100, Fabio Valentini wrote: > > Wouldn't the config-file-as-separate-source-file approach would be > > more or less backwards compatible, > > whereas creating the config snippet in-line is only compatible with F42+? > > Naively, I would think that the more-or-less-backwards-compatible > > approach would be easier to conditionalize so changes can continue to > > be cherry-picked or even merged to stable branches. > > Probably. But there are many options how to do conditionalization, so > I'm just providing a basic approach that works cleanly in F42, which > is something that I can reasonably do myself. The maintainers can use > that as a starting point and adjust to their preferences if they wish. > > (FWIW, I don't think such conditionalization would be terribly useful. > The approach with %sysusers_create_compat was cumbersome so I think > it's fine to leave older branches as they were.) Thanks for clarifying! Makes sense, I suppose. 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: Inadvertent mass-rebuild triggered soname bump in libnfs
Fabio Valentini wrote: > On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher wrote: > > It's possible that I'm in the minority here, but I honestly don't think > > anything should be pushed to dist-git unless it's intended to be built more > > or less immediately. Yes, even changes without an immediate functional > > impact like the SPDX changes. > > > > That said, I agree with Kevin that we should have the compose reports list > > anything in the compose whose state is "The commit at the HEAD of the > > `rawhide` branch does not match the commit used for the latest build in > > Rawhide" and treat that as a bug (ideally, we'd open one automatically) > > that must be resolved prior to the next mass-rebuild (either by getting a > > build done or tagging the bug in some way that indicates that it's okay for > > the mass-rebuild to build it). Anything still on the list when the > > mass-rebuild is ready to start should be skipped and the bug should be > > marked as a blocker for Beta (to make sure it gets looked at). Detecting > > this should be fairly easy, albeit adding a bit to the Koji API load. > > I agree. I don't think anything should be pushed into dist-git that > isn't built for rawhide for like ... maybe > 3 weeks (or built in > side-tags and not submitted to bodhi in a similar time-frame). Mass > changes like the SPDX migration shouldn't be a special case here - > after all, the spec file changes will never end up in repositories if > they're pushed but never built. If I correct a typo in a comment, I should bump the release and cause churn on build servers and mirrors, even though nothing at all changes in the binary package? Björn Persson pgpXQg2hJ2PCS.pgp Description: OpenPGP digital signatur -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inadvertent mass-rebuild triggered soname bump in libnfs
On Sun, Jan 26, 2025 at 10:40:09AM -0500, Stephen Gallagher wrote: > > It's possible that I'm in the minority here, but I honestly don't think > anything should be pushed to dist-git unless it's intended to be built more > or less immediately. Yes, even changes without an immediate functional > impact like the SPDX changes. > > That said, I agree with Kevin that we should have the compose reports list > anything in the compose whose state is "The commit at the HEAD of the > `rawhide` branch does not match the commit used for the latest build in > Rawhide" and treat that as a bug (ideally, we'd open one automatically) I don't think we should be that aggressive on it. It often happens that you need to rebuild things in a side tag and have to coordinate with other maintainers about it, so instantly filing a bug would be kinda anoying, especially if there already is one. > that must be resolved prior to the next mass-rebuild (either by getting a > build done or tagging the bug in some way that indicates that it's okay for > the mass-rebuild to build it). Anything still on the list when the > mass-rebuild is ready to start should be skipped and the bug should be > marked as a blocker for Beta (to make sure it gets looked at). Detecting > this should be fairly easy, albeit adding a bit to the Koji API load. Well, that would need a new Beta critera I guess? I'm not sure blocking beta on some random package not being rebuilt is a good idea. Anything that actually doesn't _work_ should be caught by testing no? kevin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inadvertent mass-rebuild triggered soname bump in libnfs
On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher wrote: > > > > On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok wrote: >> >> On 24. 01. 25 22:13, Adam Williamson wrote: >> > Note that side tags aren't the only issue. Sometimes a maintainer >> > commits a bump to git but doesn't build it in a side tag or rawhide, >> > for whatever reason. Sometimes a package is*built*, but gated from >> > Rawhide by automated tests, but then the mass rebuild effectively >> > overrides the gating (we found several cases like this). Just checking >> > side tags isn't gonna catch everything. I really think the appropriate >> > check is 'was the build most recently tagged into fXX built from the >> > current git commit? if not, don't rebuild this package, yell for manual >> > intervention'. >> >> Generally, this sounds like a good idea. >> >> However, note that is is not uncommon for (proven)packagers to commit stuff >> that will only eventually get built. We might discover that the number of >> packages that we yell at for no good reason is too high. >> >> As an example of a big chnage, I think the SPDX commits were pushed but not >> built. >> > > It's possible that I'm in the minority here, but I honestly don't think > anything should be pushed to dist-git unless it's intended to be built more > or less immediately. Yes, even changes without an immediate functional impact > like the SPDX changes. > > That said, I agree with Kevin that we should have the compose reports list > anything in the compose whose state is "The commit at the HEAD of the > `rawhide` branch does not match the commit used for the latest build in > Rawhide" and treat that as a bug (ideally, we'd open one automatically) that > must be resolved prior to the next mass-rebuild (either by getting a build > done or tagging the bug in some way that indicates that it's okay for the > mass-rebuild to build it). Anything still on the list when the mass-rebuild > is ready to start should be skipped and the bug should be marked as a blocker > for Beta (to make sure it gets looked at). Detecting this should be fairly > easy, albeit adding a bit to the Koji API load. I agree. I don't think anything should be pushed into dist-git that isn't built for rawhide for like ... maybe > 3 weeks (or built in side-tags and not submitted to bodhi in a similar time-frame). Mass changes like the SPDX migration shouldn't be a special case here - after all, the spec file changes will never end up in repositories if they're pushed but never built. 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
Fedora eln compose report: 20250127.n.0 changes
OLD: Fedora-eln-20250126.n.0 NEW: Fedora-eln-20250127.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 12 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 890.63 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.42 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: boost-1.83.0-12.eln145 Old package: boost-1.83.0-11.eln145 Summary: The free peer-reviewed portable C++ source libraries RPMs: boost boost-atomic boost-b2 boost-build boost-chrono boost-container boost-context boost-contract boost-coroutine boost-date-time boost-devel boost-doc boost-doctools boost-examples boost-fiber boost-filesystem boost-graph boost-graph-mpich boost-graph-openmpi boost-iostreams boost-json boost-locale boost-log boost-math boost-mpich boost-mpich-devel boost-mpich-python3 boost-nowide boost-numpy3 boost-openmpi boost-openmpi-devel boost-openmpi-python3 boost-program-options boost-python3 boost-random boost-regex boost-serialization boost-stacktrace boost-static boost-system boost-test boost-thread boost-timer boost-type_erasure boost-wave Size: 147.64 MiB Size change: 91.02 KiB Changelog: * Sun Jan 26 2025 Wolfgang St??ggl - 1.83.0-12 - Add boost-1.83-fix-no-member-named_that_error.patch Package: dav1d-1.5.1-1.eln145 Old package: dav1d-1.5.0-3.eln145 Summary: AV1 cross-platform Decoder RPMs: libdav1d Size: 1.74 MiB Size change: 35.11 KiB Changelog: * Sun Jan 26 2025 Fabio Valentini - 1.5.1-1 - Update to version 1.5.1; Fixes RHBZ#2338924 Package: gcc-15.0.1-0.4.eln145 Old package: gcc-15.0.1-0.3.eln145.1 Summary: Various compilers (C, C++, Objective-C, ...) RPMs: cpp gcc gcc-c++ gcc-gfortran gcc-offload-amdgcn gcc-offload-nvptx gcc-plugin-annobin gcc-plugin-devel libasan libatomic libatomic-static libgcc libgccjit libgccjit-devel libgfortran libgomp libgomp-offload-amdgcn libgomp-offload-nvptx libhwasan libitm libitm-devel liblsan libquadmath libquadmath-devel libstdc++ libstdc++-devel libstdc++-docs libstdc++-static libtsan libubsan Size: 545.56 MiB Size change: 1.03 MiB Changelog: * Sat Jan 25 2025 Jakub Jelinek 15.0.1-0.4 - update from trunk - PRs c/118639, c++/105440, c++/107522, c++/107741, c++/115769, c++/116417, c++/116568, c++/116756, c++/117153, c++/117397, c++/117602, c++/117775, c++/117827, c++/118047, c++/118049, c++/118101, c++/118124, c++/118139, c++/118147, c++/118199, c++/118214, c++/118225, c++/118245, c++/118255, c++/118278, c++/118355, c++/118390, c++/118396, c++/118454, c++/118486, c++/118509, c++/118513, c++/118523, c++/118525, c++/118528, c++/118532, c++/118534, c++/118582, c++/118590, c++/118604, d/114434, d/115249, d/116373, d/117115, d/118438, d/118448, d/118449, d/118584, fortran/71884, fortran/81978, fortran/96087, fortran/107122, fortran/118321, fortran/118359, fortran/118441, fortran/118613, gcov-profile/116743, ipa/116068, ipa/118400, jit/117886, libfortran/118406, libfortran/118536, libfortran/118571, libstdc++/5, libstdc++/100249, libstdc++/109849, libstdc++/118158, libstdc++/118185, lto/118238, middle-end/112779, middle-end/113904, middle-end/114596, middle-end/114877, middle-end/118140, middle-end/118273, middle-end/118472, modula2/118010, modula2/118589, objc++/118586, rtl-optimization/109592, rtl-optimization/113994, rtl-optimization/117868, rtl-optimization/118067, rtl-optimization/118562, rtl-optimization/118591, rtl-optimization/1180167, sarif-replay/117670, target/80813, target/110901, target/113257, target/113560, target/114442, target/116256, target/116308, target/116593, target/117079, target/117726, target/118154, target/118170, target/118182, target/118270, target/118329, target/118357, target/118489, target/118497, target/118501, target/118510, target/118511, target/118512, target/118531, target/118560, target/118609, testsuite/116448, testsuite/117958, testsuite/118451, tree-optimization/92539, tree-optimization/102705, tree-optimization/115494, tree-optimization/115777, tree-optimization/115895, tree-optimization/116010, tree-optimization/117668, tree-optimization/117875, tree-optimization/118012, tree-optimization/118077, tree-optimization/118224, tree-optimization/118348, tree-optimization/118360, tree-optimization/118384, tree-optimization/118430, tree-optimization/118456, tree-optimization/118483, tree-optimization/118487, tree
Retiring rdist and rssh in Rawhide
Hi, this is just a quick message that I'll be retiring rdist package in Rawhide. The Upstream of rdist is long gone and it has been recently hit with the GCC15 and is currently in the state of FTBFS. The only package that depends on it is rssh, I already spoke to Huzaifa and he agreed to remove it as well. If anyone still cares about rdist (or rssh), let me know and you can take the maintenance under your own wings. Regards, Michal Ruprich -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: 20250127.n.0 changes
OLD: Fedora-Rawhide-20250126.n.0 NEW: Fedora-Rawhide-20250127.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 5 Dropped packages:1 Upgraded packages: 182 Downgraded packages: 0 Size of added packages: 6.45 MiB Size of dropped packages:272.29 KiB Size of upgraded packages: 3.85 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -19.36 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250127.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20250127.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: python-ckzg-2.0.1-1.fc42 Summary: An implementation of the Polynomial Commitments API for EIP-4844/7594 RPMs:python3-ckzg Size:471.88 KiB Package: rust-cargo_metadata0.18-0.18.1-1.fc42 Summary: Structured access to the output of cargo metadata RPMs:rust-cargo_metadata0.18+builder-devel rust-cargo_metadata0.18+default-devel rust-cargo_metadata0.18+derive_builder-devel rust-cargo_metadata0.18+unstable-devel rust-cargo_metadata0.18-devel Size:60.28 KiB Package: rust-gix-shallow-0.2.0-1.fc42 Summary: Handle files specifying the shallow boundary RPMs:rust-gix-shallow+default-devel rust-gix-shallow+serde-devel rust-gix-shallow-devel Size:29.80 KiB Package: rust-pulldown-cmark0.11-0.11.3-1.fc42 Summary: Pull parser for CommonMark RPMs:rust-pulldown-cmark0.11+default-devel rust-pulldown-cmark0.11+gen-tests-devel rust-pulldown-cmark0.11+getopts-devel rust-pulldown-cmark0.11+html-devel rust-pulldown-cmark0.11+pulldown-cmark-escape-devel rust-pulldown-cmark0.11+serde-devel rust-pulldown-cmark0.11+simd-devel rust-pulldown-cmark0.11-devel Size:185.97 KiB Package: rust-tokei12-12.1.2-19.fc42 Summary: Count your code, quickly RPMs:rust-tokei12+all-devel rust-tokei12+cbor-devel rust-tokei12+default-devel rust-tokei12+hex-devel rust-tokei12+serde_cbor-devel rust-tokei12+serde_yaml-devel rust-tokei12+yaml-devel rust-tokei12-devel tokei Size:5.72 MiB = DROPPED PACKAGES = Package: xconvers-0.8.3-34.fc41 Summary: Ham radio convers client similar to IRC for X/GTK RPMs:xconvers Size:272.29 KiB = UPGRADED PACKAGES = Package: OpenImageIO-3.0.0.3-2.fc42 Old package: OpenImageIO-2.5.16.0-3.fc42 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 16.84 MiB Size change: -1.17 MiB Changelog: * Tue Nov 26 2024 Richard Shaw - 3.0.0.3-1 - Update to 3.0.0.3. * Thu Jan 16 2025 Fedora Release Engineering - 3.0.0.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild Package: apache-commons-exec-1.4.0-1.fc42 Old package: apache-commons-exec-1.3-33.fc42 Summary: Java library to reliably execute external processes from within the JVM RPMs: apache-commons-exec apache-commons-exec-javadoc Size: 241.93 KiB Size change: 16.26 KiB Changelog: * Sun Jan 26 2025 Mohamed El Morabity - 1.4.0-1 - Update to 1.4.0 Package: beesu-2.7-50.fc42 Old package: beesu-2.7-47.fc41 Summary: Graphical wrapper for su RPMs: beesu Size: 97.37 KiB Size change: -607 B Changelog: * Thu Jul 25 2024 Miroslav Such?? - 2.7-48 - convert license to SPDX * Thu Jan 16 2025 Fedora Release Engineering - 2.7-49 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild * Mon Jan 27 2025 Wolfgang Ulbrich - 2.7-50 - fix building of beesu in f42 Package: boost-1.83.0-12.fc42 Old package: boost-1.83.0-11.fc42 Summary: The free peer-reviewed portable C++ source libraries RPMs: boost boost-atomic boost-b2 boost-build boost-chrono boost-container boost-context boost-contract boost-coroutine boost-date-time boost-devel boost-doc boost-doctools boost-examples boost-fiber boost-filesystem boost-graph boost-graph-mpich boost-graph-openmpi boost-iostreams boost-json boost-locale boost-log boost-math boost-mpich boost-mpich-devel boost-mpich-python3 boost-mpich-python3-devel boost-nowide boost-numpy3 boost-openmpi boost-openmpi-devel boost-openmpi-python3 boost-openmpi-python3-devel boost-program-options boost-python3 boost-random boost-regex boost-serialization boost-stacktrace boost-static boost-system boost-test boost-thread boost-timer boost-type_erasure boost-url boost-wave Size: 354.02 MiB Size change: 103.65 KiB Changelog: * Sun Jan 26 2025 Wolfgang St??ggl - 1.83.0-12 - Add boost-1.83-fix-no-member-named_that_error.patch Package: c-icap-0.6.2-3.fc42 Old package: c-icap-0.6.2-2.fc41 Summary: An implementation of an ICAP server RPMs: c-icap c-icap-devel c-icap-libs Size: 1.83 MiB Size change: -8.65 KiB Changelog: * Thu Jan 16 2025 Fedora
Re: [rfc] mass package change to introduce sysusers.d configs
On Sat, Jan 25, 2025 at 04:32:54PM +, Gary Buhrmaster wrote: > On Sat, Jan 25, 2025 at 11:05 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > Updated diff: > > > Zbyszek > > I have a preference for seeing packages follow > the current packaging guidelines (that I can find) > that say: > > Create a .sysusers file with the user definition and > add it to the specfile as a source. > > The current diff mostly just inlines the creation of > a sysusers file, which (while there are always > special cases) does not seem to follow the > guidelines. If we are going to make a mass > change, should we not try to follow the > guidelines? Or are the guidelines going to > be changed to recommend not using > separate .sysusers files? The latter: https://pagure.io/packaging-committee/pull-request/1436. The reason for the separate source file was to make the %sysusers_create_compat macro work. The new solution in rpm is _much_ nicer and works just fine with either a separate source file or creation in %prep and also a file in the upstream tarball. In my patches, I used the inline creation because the definitions often used macros. In the long term, maintainers could just push those files upstream and we can drop our creation again. 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: Inadvertent mass-rebuild triggered soname bump in libnfs
On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok wrote: > On 24. 01. 25 22:13, Adam Williamson wrote: > > Note that side tags aren't the only issue. Sometimes a maintainer > > commits a bump to git but doesn't build it in a side tag or rawhide, > > for whatever reason. Sometimes a package is*built*, but gated from > > Rawhide by automated tests, but then the mass rebuild effectively > > overrides the gating (we found several cases like this). Just checking > > side tags isn't gonna catch everything. I really think the appropriate > > check is 'was the build most recently tagged into fXX built from the > > current git commit? if not, don't rebuild this package, yell for manual > > intervention'. > > Generally, this sounds like a good idea. > > However, note that is is not uncommon for (proven)packagers to commit > stuff > that will only eventually get built. We might discover that the number of > packages that we yell at for no good reason is too high. > > As an example of a big chnage, I think the SPDX commits were pushed but > not built. > > It's possible that I'm in the minority here, but I honestly don't think anything should be pushed to dist-git unless it's intended to be built more or less immediately. Yes, even changes without an immediate functional impact like the SPDX changes. That said, I agree with Kevin that we should have the compose reports list anything in the compose whose state is "The commit at the HEAD of the `rawhide` branch does not match the commit used for the latest build in Rawhide" and treat that as a bug (ideally, we'd open one automatically) that must be resolved prior to the next mass-rebuild (either by getting a build done or tagging the bug in some way that indicates that it's okay for the mass-rebuild to build it). Anything still on the list when the mass-rebuild is ready to start should be skipped and the bug should be marked as a blocker for Beta (to make sure it gets looked at). Detecting this should be fairly easy, albeit adding a bit to the Koji API load. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [rfc] mass package change to introduce sysusers.d configs
On Sun, Jan 26, 2025 at 12:36:33PM +0100, Fabio Valentini wrote: > Wouldn't the config-file-as-separate-source-file approach would be > more or less backwards compatible, > whereas creating the config snippet in-line is only compatible with F42+? > Naively, I would think that the more-or-less-backwards-compatible > approach would be easier to conditionalize so changes can continue to > be cherry-picked or even merged to stable branches. Probably. But there are many options how to do conditionalization, so I'm just providing a basic approach that works cleanly in F42, which is something that I can reasonably do myself. The maintainers can use that as a starting point and adjust to their preferences if they wish. (FWIW, I don't think such conditionalization would be terribly useful. The approach with %sysusers_create_compat was cumbersome so I think it's fine to leave older branches as they were.) 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: Inadvertent mass-rebuild triggered soname bump in libnfs
On Sun, Jan 26, 2025 at 7:26 PM Björn Persson wrote: > > Fabio Valentini wrote: > > On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher > > wrote: > > > It's possible that I'm in the minority here, but I honestly don't think > > > anything should be pushed to dist-git unless it's intended to be built > > > more or less immediately. Yes, even changes without an immediate > > > functional impact like the SPDX changes. > > > > > > That said, I agree with Kevin that we should have the compose reports > > > list anything in the compose whose state is "The commit at the HEAD of > > > the `rawhide` branch does not match the commit used for the latest build > > > in Rawhide" and treat that as a bug (ideally, we'd open one > > > automatically) that must be resolved prior to the next mass-rebuild > > > (either by getting a build done or tagging the bug in some way that > > > indicates that it's okay for the mass-rebuild to build it). Anything > > > still on the list when the mass-rebuild is ready to start should be > > > skipped and the bug should be marked as a blocker for Beta (to make sure > > > it gets looked at). Detecting this should be fairly easy, albeit adding a > > > bit to the Koji API load. > > > > I agree. I don't think anything should be pushed into dist-git that > > isn't built for rawhide for like ... maybe > 3 weeks (or built in > > side-tags and not submitted to bodhi in a similar time-frame). Mass > > changes like the SPDX migration shouldn't be a special case here - > > after all, the spec file changes will never end up in repositories if > > they're pushed but never built. > > If I correct a typo in a comment, I should bump the release and cause > churn on build servers and mirrors, even though nothing at all changes > in the binary package? Do you expect to need to correct typos dozens of times per day? If not, I don't think that would be a problem ;) Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inadvertent mass-rebuild triggered soname bump in libnfs
On Sun, Jan 26, 2025 at 6:26 PM Björn Persson wrote: > If I correct a typo in a comment, I should bump the release and cause > churn on build servers and mirrors, even though nothing at all changes > in the binary package? I do worry about server/storage usage, but in my more innocent years I have made a change to a comment (which included a new type of typo error) and that resulted in build breakage. I learned that even a small (of what I thought was an) innocuous change might itself cause issues, and learned that just adding building to every change was the safest way forward. Those that never make typos when fixing the typos they first typed probably do not have the same experience or concerns. If you are worried about storage usage on mirrors, a scratch build at least strongly suggests that the package will likely build in the next (mass) rebuild. CI can mean different things to different organizations, but building on every commit can certainly be useful to catch some issues early. I think I have previously suggested that every push should (by default) trigger a scratch-build (with overrides for full build or no build for packages/packagers with special needs), so that the project is less likely to have surprises much later in the process. Identifying the push but no build case in a different way can also work. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: 20250126.n.0 changes
OLD: Fedora-Rawhide-20250125.n.0 NEW: Fedora-Rawhide-20250126.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 2 Dropped packages:6 Upgraded packages: 59 Downgraded packages: 0 Size of added packages: 131.63 KiB Size of dropped packages:1.14 MiB Size of upgraded packages: 1.01 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -27.87 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250125.n.0.iso = ADDED PACKAGES = Package: image-garden-0.1.1-1.fc42 Summary: Tool for creating test virtual machines RPMs:image-garden Size:26.81 KiB Package: nginx-mod-headers-more-0.38-1.fc42 Summary: This module allows adding, setting, or clearing specified input/output headers RPMs:nginx-mod-headers-more Size:104.83 KiB = DROPPED PACKAGES = Package: rust-pyo3-build-config0.21-0.21.2-3.fc42 Summary: Build configuration for the PyO3 ecosystem RPMs:rust-pyo3-build-config0.21+abi3-devel rust-pyo3-build-config0.21+abi3-py310-devel rust-pyo3-build-config0.21+abi3-py311-devel rust-pyo3-build-config0.21+abi3-py312-devel rust-pyo3-build-config0.21+abi3-py37-devel rust-pyo3-build-config0.21+abi3-py38-devel rust-pyo3-build-config0.21+abi3-py39-devel rust-pyo3-build-config0.21+default-devel rust-pyo3-build-config0.21+extension-module-devel rust-pyo3-build-config0.21+resolve-config-devel rust-pyo3-build-config0.21-devel Size:111.33 KiB Package: rust-pyo3-ffi0.21-0.21.2-4.fc42 Summary: Python-API bindings for the PyO3 ecosystem RPMs:rust-pyo3-ffi0.21+abi3-devel rust-pyo3-ffi0.21+abi3-py310-devel rust-pyo3-ffi0.21+abi3-py311-devel rust-pyo3-ffi0.21+abi3-py312-devel rust-pyo3-ffi0.21+abi3-py37-devel rust-pyo3-ffi0.21+abi3-py38-devel rust-pyo3-ffi0.21+abi3-py39-devel rust-pyo3-ffi0.21+default-devel rust-pyo3-ffi0.21+extension-module-devel rust-pyo3-ffi0.21-devel Size:156.45 KiB Package: rust-pyo3-macros-backend0.21-0.21.2-3.fc42 Summary: Code generation for PyO3 package RPMs:rust-pyo3-macros-backend0.21+default-devel rust-pyo3-macros-backend0.21+experimental-async-devel rust-pyo3-macros-backend0.21-devel Size:73.65 KiB Package: rust-pyo3-macros0.21-0.21.2-3.fc42 Summary: Proc macros for PyO3 package RPMs:rust-pyo3-macros0.21+default-devel rust-pyo3-macros0.21+experimental-async-devel rust-pyo3-macros0.21+experimental-declarative-modules-devel rust-pyo3-macros0.21+multiple-pymethods-devel rust-pyo3-macros0.21-devel Size:45.92 KiB Package: rust-pyo3_0.21-0.21.2-8.fc42 Summary: Bindings to Python interpreter RPMs:rust-pyo3_0.21+abi3-devel rust-pyo3_0.21+abi3-py310-devel rust-pyo3_0.21+abi3-py311-devel rust-pyo3_0.21+abi3-py312-devel rust-pyo3_0.21+abi3-py37-devel rust-pyo3_0.21+abi3-py38-devel rust-pyo3_0.21+abi3-py39-devel rust-pyo3_0.21+anyhow-devel rust-pyo3_0.21+auto-initialize-devel rust-pyo3_0.21+chrono-devel rust-pyo3_0.21+chrono-tz-devel rust-pyo3_0.21+default-devel rust-pyo3_0.21+either-devel rust-pyo3_0.21+experimental-async-devel rust-pyo3_0.21+experimental-declarative-modules-devel rust-pyo3_0.21+experimental-inspect-devel rust-pyo3_0.21+extension-module-devel rust-pyo3_0.21+eyre-devel rust-pyo3_0.21+full-devel rust-pyo3_0.21+gil-refs-devel rust-pyo3_0.21+hashbrown-devel rust-pyo3_0.21+indexmap-devel rust-pyo3_0.21+indoc-devel rust-pyo3_0.21+inventory-devel rust-pyo3_0.21+macros-devel rust-pyo3_0.21+multiple-pymethods-devel rust-pyo3_0.21+nightly-devel rust-pyo3_0.21+num-bigint-devel rust-pyo3_0.21+num-complex-devel rust-pyo3_0.21+pyo3-macros-devel rust-pyo3_0.21+rust_decimal-devel rust-pyo3_0.21+serde-devel rust-pyo3_0.21+smallvec-devel rust-pyo3_0.21+unindent-devel rust-pyo3_0.21-devel Size:715.92 KiB Package: rust-standback-0.2.17-11.fc42 Summary: New standard library, old compiler RPMs:rust-standback+default-devel rust-standback+std-devel rust-standback-devel Size:60.09 KiB = UPGRADED PACKAGES = Package: 389-ds-base-3.1.2-2.fc42 Old package: 389-ds-base-3.1.1-6.fc42 Summary: 389 Directory Server (base) RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp cockpit-389-ds python3-lib389 Size: 20.50 MiB Size change: 1.11 MiB Changelog: * Thu Jan 16 2025 Fedora Release Engineering - 3.1.1-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild * Mon Jan 20 2025 Fedora Release Engineering - 3.1.1-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild * Fri Jan 24 2025 Viktor Ashirov - 3.1.2-1 - Update to 3.1.2 * Sat Jan 25 2025 Viktor Ashirov - 3.1.2-2 - Replace python3-magic with python3-file-magic Package: adobe-source-sans-pro-fonts-3.052-6.fc42 Old package: adobe-source-sans-pro-fonts-3.052-4.fc41 Summary: A set of OpenType fonts designed for user interfaces RPMs
