Re: Applying code layout optimization to postgresql16 RPMs in Fedora 41 gave a 3%-6% improvement in IPC
On 2/4/25 7:18 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Jan 26, 2025 at 09:20:59PM -0500, William Cohen wrote:
>> 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
Thanks for the suggestions for improvements. I will work those in.
>
> That spec file patch uses a style that is a bit dated.
> Some comments:
>
>> +%bcond_without opt
> '%bcond foo' is a more modern alternative that is easier for humans to
> understand.
> → %bcond opt 1
>
>> +%global layout _opt
>> +Release: 1%{?dist}%{?layout}
> In various places the patch does such indirections… Please kill them, they
> make the diff much more verbose and actually harder to follow.
>
> → Release: 1%{?dist}%{?_with_opt:_opt}
>
> Same for %{call_graph} as alias for %SOURCE12.
The problem being addressed with the %SOURCEnn and %call_graph was that the
call graph needs to be stored in srpm rpm. Those files need to be %sourcenn in
the spec file, just defining %call_graph as the callgraph file is not going to
pull the call graph file into the source rpm. Having the definition of
%{call_graph} is to allow the later boilerplate code to be same between
various spec files.
>
>> +%define _distro_extra_cflags -ffunction-sections -fdata-sections
>> +%define _distro_extra_cxxflags -ffunction-sections -fdata-sections
>> +%define _distro_extra_fflags -ffunction-sections -fdata-sections
> →
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_global_preferred_over_define
>
>> +gv2link < %{call_graph} > %{__global_link_order}
> The redirection op is not a binary operator. There is a long tradition of
> writing it with extra whitespace, but that's just confusing.
> For example, it makes sense to write 'cat /dev/urandom | grep 42' because
> the pipe is a binary operator. But '>', '<', '1>', '2>', '&>', etc, are
> unary operators.
> → gv2link <%{call_graph} >%{__global_link_order}
>
> Zbyszek
-Will
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
bin-sbin merge case of packages which install to hardcoded $DESTDIR/usr/sbin
Hi,
In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
but then use %{_sbindir} in %files, will need to be adjusted."
I did this [1] after the make install, is that correct ?
[1]
%if "%{_sbindir}" == "%{_bindir}"
mkdir -p %{buildroot}%{_bindir}
mv %{buildroot}/usr/sbin/* %{buildroot}%{_bindir}
%endif
Thanks and best regards,
--
Sérgio M. B.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge case of packages which install to hardcoded $DESTDIR/usr/sbin
On Tue, Feb 04, 2025 at 02:54:30PM +, Sérgio Basto via devel wrote:
> Hi,
> In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
> but then use %{_sbindir} in %files, will need to be adjusted."
>
> I did this [1] after the make install, is that correct ?
>
> [1]
> %if "%{_sbindir}" == "%{_bindir}"
> mkdir -p %{buildroot}%{_bindir}
> mv %{buildroot}/usr/sbin/* %{buildroot}%{_bindir}
> %endif
There are different levels of "correct", at your discretion IMHO.
Ideally the app would be honouring the '--sbindir=XXX' arg to configure.
Give your comment though, I assume it does not do that.
My first inclination would be to patch the Makefile.am to make it honour
--sbindir, by using @sbindir@ & re-run autoconf/automake. This would be
a patch that is suitable to submit back to upstream, and hopefully then
you can drop the patch on the next upstream release.
While you're waiting for upstream though, or if you don't want to touch
patches to Makefiles, then your approach of moving stuff after the fact
is not unreasonable.
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
Re: Applying code layout optimization to postgresql16 RPMs in Fedora 41 gave a 3%-6% improvement in IPC
On Sun, Jan 26, 2025 at 09:20:59PM -0500, William Cohen wrote:
> 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
That spec file patch uses a style that is a bit dated.
Some comments:
> +%bcond_without opt
'%bcond foo' is a more modern alternative that is easier for humans to
understand.
→ %bcond opt 1
> +%global layout _opt
> +Release: 1%{?dist}%{?layout}
In various places the patch does such indirections… Please kill them, they
make the diff much more verbose and actually harder to follow.
→ Release: 1%{?dist}%{?_with_opt:_opt}
Same for %{call_graph} as alias for %SOURCE12.
> +%define _distro_extra_cflags -ffunction-sections -fdata-sections
> +%define _distro_extra_cxxflags -ffunction-sections -fdata-sections
> +%define _distro_extra_fflags -ffunction-sections -fdata-sections
→
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_global_preferred_over_define
> +gv2link < %{call_graph} > %{__global_link_order}
The redirection op is not a binary operator. There is a long tradition of
writing it with extra whitespace, but that's just confusing.
For example, it makes sense to write 'cat /dev/urandom | grep 42' because
the pipe is a binary operator. But '>', '<', '1>', '2>', '&>', etc, are
unary operators.
→ gv2link <%{call_graph} >%{__global_link_order}
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: [heads up] mass rebuild for opencv 4.11.0 with soname bump on rawhide
On Tue, 2025-02-04 at 02:00 +, Sérgio Basto via devel wrote: > On Mon, 2025-02-03 at 01:06 +, Sérgio Basto via devel wrote: > > Hi, > > I will start a mass rebuild in a side-tag, very soon , the goal is > > finish and merge it before the mass branch which is scheduled for 4 > > of > > Feb of 2025 > > Started > > Building opencv-4.11.0-1.fc42 for f42-build-side-104797 > > Failures from my tests are : dtkmultimedia alreaady FTBFS , gmic > FTBFS > ? os-autoinst fails only on ppc64le and opentoonz > > Corrections are welcome and you can submit builds to the side tag side tag merged to stable , missing dtkmultimedia, gmic , os-autoinst https://bodhi.fedoraproject.org/updates/FEDORA-2025-8ca0faa87a opentoonz was built successful, later, already in rawhide with the latest fixes Best regards, -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://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 04. 02. 25 13:18, Zbigniew Jędrzejewski-Szmek wrote: That spec file patch uses a style that is a bit dated. Some comments: +%bcond_without opt '%bcond foo' is a more modern alternative that is easier for humans to understand. → %bcond opt 1 This was only updated in our python3.14 specfile: https://src.fedoraproject.org/rpms/python3.14/c/7fc2da03e52a52e09d2ca4aa52f2748f88e55ff7?branch=rawhide -- 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: RFC: Additional checkpoint for major toolchain updates before mass rebuild
Dne 31. 01. 25 v 20:41 Kevin Fenzi napsal(a): On Fri, Jan 31, 2025 at 02:27:28PM +0100, Vít Ondruch wrote: I am advocating for mass-rebuild as we do (i.e. to try to build everything) to be done after stable branch is branched off. For this cycle, the F42 is going to be branched on Tue 2025-02-04, so some time after that (week, month, ...), we would do Rawhide mass rebuild. This would serve the following three purposes: 1) Make sure all packages have fcNN+1 (fc43) dist tag. This can reduce user confusion Sure, but note if we move the mass rebuild to only rawhide after branching, both will have the right dist-tag, but in rawhide it could mean "this built ok 6 months ago" when we next branch. Yes. Maybe to you or me. But "this built ok 6 months ago" is not, with all due respect, what our average user thinks. With some luck, our user understands that they are using Fedora 41 and if there is .fc41 package, it is likely compatible with their system. But frankly, I *hope* that most of our users know that they run *Fedora*, without any specifics, because that would mean we are doing good job (now we could argue about Fedora *Workstation* aiming on above average users, namely "developers and creators" who are more tech savvy, but I would like to imagine that Fedora is for masses, using nice GUI, running browser, looking at videos without understanding details). For me as a Fedora developer, dist tag changes are good indicater that the package built in their recent history. If I see currently .fc41 package, I can understand it (most likely) failed mass rebuild for some reason. But even if the package has .fc42 dist tag, it says only as much as that the package has passed some build since last branching. I don't know how long ago the build was done and if the package passed mass rebuild. Even if the package built during mass rebuild two weeks ago, it does not say anything about its current state. For that purpose, Koschei does much better job. In short, the dist tag provides just a hint that the package was build during certain some period of time. It might be beneficial for advanced users. But it is not strictly needed for anything apart of aesthetic. 2) Make sure that if there were some changes and the targeted mini mass rebuild missed some packages for some reason, such changes are really applied 3) Make sure everything builds. In connection with the 1st point, fcNN tag would make such packages stand out. However, we still have different means to discover something is FTBFS, so this is not that important. All other changes being it GCC or Ruby or sbin or whatever else would be followed up by targetted mini mass rebuild (possibly only looking to identify the FTBFS). We do this anyway. "followed up by" meaning in rawhide and in branched both? Or just in branched? Just in Rawhide. After branching, Fedora is assumed to be in Beta quality and no mass rebuild should be needed. Most of the FTBFS are not critical, most of the possible optimizations are not critical (they will be applied sooner or later). And we have the numbers. For F41, there were 568 failed builds at the time of branching [1] and it did not make any serious troubles in global scale. F42 [2] so far does not look any better. I don't see any benefit doing mass rebuild this late in the cycle. If I am not mistaken, historically some mass rebuild issues resulted in delayed Fedora release. And it makes quite hard to adjust the schedule if needed. But likewise I don't see benifit in doing it before changes needing mass rebuild have landed. I don't think there is or should be some deadline for changes landing in Rawhide. IMHO changes should land in Rawhide "anytime" (considering branching is just NTH). Also this doesn't work for big global changes like rpm payload changes or global packaging changes. Or at least it delays them 6 months. Was there really some feature which would need to be introduced at any specific time and was not possible to introduce it gradually, over time? I don't think that even the "payload" changes were necessary to be introduced at one point of time. It was just self imposed requirement, so we can make some nice release notes entry. And I would be surprised if even at that time we built 100% packages. But even if there were 100% success rate needed (which I argue is not needed for most of the changes), then it should be done as soon as such change is ready and likely not 2 weeks before branching. I don't see what we gain by doing the mass rebuild after branching. My point is that we can do mass rebuild essentially any time. But doing it two weeks before branching is IMHO the worst possible time, because people are going to land their last second changes. With such timing, mass rebuild brings more harm then benefits. All 3 of your points are valid. If the FTBFS isn't critical, you can assign the bug and just wait until you want to fix it? I'd sti
Fedora eln compose report: 20250205.n.1 changes
OLD: Fedora-eln-20250204.n.0 NEW: Fedora-eln-20250205.n.1 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:5 Upgraded packages: 50 Downgraded packages: 0 Size of added packages: 4.70 MiB Size of dropped packages:47.06 MiB Size of upgraded packages: 2.46 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 5.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: tcl8-1:8.6.15-10.eln145 Summary: Tool Command Language, pronounced tickle, version 8 RPMs:tcl8 Size:4.70 MiB = DROPPED PACKAGES = Package: jack-audio-connection-kit-1.9.22-8.eln145 Summary: The Jack Audio Connection Kit RPMs:jack-audio-connection-kit Size:2.03 MiB Package: libicu74-74.2-2.eln145 Summary: Compat package with icu libraries RPMs:libicu74 Size:41.73 MiB Package: python-pyqt6-webengine-6.8.0-2.eln145 Summary: Python bindings for Qt6WebEngine RPMs:python3-pyqt6-webengine Size:313.83 KiB Package: qt6-qtquick3dphysics-6.8.1-2.eln144 Summary: Qt6 - Quick3D Physics Libraries and utilities RPMs:qt6-qtquick3dphysics Size:2.97 MiB Package: rubygem-rack-test-1.1.0-12.eln145 Summary: Simple testing API built on Rack RPMs:rubygem-rack-test Size:17.83 KiB = UPGRADED PACKAGES = Package: ImageMagick-1:7.1.1.43-3.eln145 Old package: ImageMagick-1:7.1.1.43-2.eln145 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-libs Size: 10.81 MiB Size change: 1.04 KiB Changelog: * Sun Feb 02 2025 S??rgio Basto - 1:7.1.1.43-3 - Rebuild on side-tag Package: SDL3-3.2.2-1.eln145 Old package: SDL3-3.2.0-1.eln145 Summary: Cross-platform multimedia library RPMs: SDL3 SDL3-devel Size: 15.11 MiB Size change: 64.30 KiB Changelog: * Mon Feb 03 2025 Neal Gompa - 3.2.2-1 - Update to 3.2.2 Package: ansible-freeipa-1.14.4-1.eln146 Old package: ansible-freeipa-1.14.3-1.eln145 Summary: Roles and playbooks to deploy FreeIPA servers, replicas and clients RPMs: ansible-freeipa Size: 651.18 KiB Size change: 162 B Changelog: * Tue Feb 04 2025 Thomas Woerner - 1.14.4-1 - Update to version 1.14.4 https://github.com/freeipa/ansible-freeipa/releases/tag/v1.14.4 - Fix management of AD objects for ipagroup Package: babel-2.17.0-1.eln145 Old package: babel-2.16.0-3.eln145 Summary: Tools for internationalizing Python applications RPMs: babel babel-doc python3-babel Size: 7.23 MiB Size change: 419.87 KiB Changelog: * Tue Feb 04 2025 Nils Philippsen - 2.17.0-1 - Update to 2.17.0 Package: binutils-2.44-1.eln146 Old package: binutils-2.43.50-12.eln145 Summary: A GNU collection of binary utilities RPMs: binutils binutils-devel binutils-gold Size: 56.90 MiB Size change: 84.16 KiB Changelog: * Mon Jan 20 2025 Nick Clifton - 2.43.90-1 - Rebased to 2.43.90 pre-release tarball. * Mon Jan 27 2025 Nick Clifton - 2.43.90-2 - Enable separate-code by default for the RISC-V target. * Mon Feb 03 2025 Nick Clifton - 2.44-1 - Rebase to official GNU Binutils 2.44 release Package: bootc-1.1.4-7.eln146 Old package: bootc-1.1.4-7.eln145 Summary: Bootable container system RPMs: bootc Size: 10.69 MiB Size change: -2.12 KiB Package: clamav-1.4.2-1.eln146 Old package: clamav-1.4.1-1.eln144 Summary: End-user tools for the Clam Antivirus scanner RPMs: clamav-lib Size: 14.16 MiB Size change: 1.05 MiB Changelog: * Thu Jan 16 2025 Fedora Release Engineering - 1.4.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild * Thu Jan 23 2025 Orion Poplawski - 1.4.2-1 - Update to 1.4.2 Package: cldr-emoji-annotation-47~alpha1-1.eln146 Old package: cldr-emoji-annotation-46.1-2.eln145 Summary: Emoji annotation files in CLDR RPMs: cldr-emoji-annotation cldr-emoji-annotation-dtd Size: 8.49 MiB Size change: 2.14 KiB Changelog: * Wed Jan 29 2025 Takao Fujiwara - 47~alpha1-1 - Bump to release-47-alpha1 Package: curl-8.11.1-4.eln145 Old package: curl-8.11.1-3.eln145 Summary: A utility for getting files from remote servers (FTP, HTTP, and others) RPMs: curl libcurl libcurl-devel libcurl-minimal Size: 7.03 MiB Size change: -3.65 KiB Changelog: * Fri Jan 31 2025 Jan Macku - 8.11.1-4 - TLS: check connection for SSL use, not handler (#2324130#c7) Package: digikam-8.5.0-3.eln145 Old package: digikam-8.5.0-2.eln145 Summary: A digital camera accessing & photo management application RPMs: digikam digikam-libs Size: 73.44 MiB Size change: -14.62 KiB Changelog: * Sun Feb 02 2025 S??rgio Basto - 8.5.0-3 - Rebuild for jpegxl (libjxl) 0.11.1 Package: dovec
Need help with pybind11 c++ compilation warning/error
I'm working on updating libmamba to 2.0.X [1] but hitting the following error: cd /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/redhat-linux-build/libmambapy && /usr/lib64/ccache/g++ -DFMT_SHARED -DMAMBA_USE_INSTALL_PREFIX_AS_BASE -DSPDLOG_FMT_EXTERNAL -DSPDLOG_FWRITE_UNLOCKED -Dbindings_EXPORTS -I/home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings -I/home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmamba/include -isystem /usr/include/python3.13 -isystem /usr/share -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused -Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion -Wnull-dereference -Wdouble-promotion -Wformat=2 -Wunreachable-code -Wuninitialized -Werror -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wuseless-cast -Wno-error=deprecated-declarations -MD -MT libmambapy/CMakeFiles/bindings.dir/src/libmambapy/bindings/legacy.cpp.o -MF CMakeFiles/bindings.dir/src/libmambapy/bindings/legacy.cpp.o.d -o CMakeFiles/bindings.dir/src/libmambapy/bindings/legacy.cpp.o -c /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp: In lambda function: /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp:557:47: warning: ‘mamba::expected_t > mamba::SubdirData::cache_path() const’ is deprecated: since version 2.0 use ``valid_solv_cache`` or ``valid_json_cache`` instead [-Wdeprecated-declarations] 557 | return extract(self.cache_path()); |~~~^~ In file included from /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp:30: /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmamba/include/mamba/core/subdirdata.hpp:135:33: note: declared here 135 | expected_t cache_path() const; | ^~ In file included from /usr/include/pybind11/attr.h:14, from /usr/include/pybind11/detail/class.h:12, from /usr/include/pybind11/pybind11.h:12, from /usr/include/pybind11/functional.h:14, from /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp:11: In function ‘pybind11::detail::collect_arguments<(pybind11::return_value_policy)1, std::__cxx11::basic_string, std::allocator >&, pybind11::detail::accessor, pybind11::arg_v, void>(std::__cxx11::basic_stringstd::char_traits, std::allocator >&, pybind11::detail::accessor&&, pybind11::arg_v&&)pybind11::detail::unpacking_collector<(pybind11::return_value_policy)1>’, inlined from ‘pybind11::detail::object_api >::operator()<(pybind11::return_value_policy)1, std::__cxx11::basic_string, std::allocator >&, pybind11::detail::accessor, pybind11::arg_v>(std::__cxx11::basic_stringstd::char_traits, std::allocator >&, pybind11::detail::accessor&&, pybind11::arg_v&&) constpybind11::object’ at /usr/include/pybind11/cast.h:1823:45, inlined from ‘deprecated(std::basic_string_viewstd::char_traits >, std::basic_string_viewstd::char_traits >)’ at /home/orion/fedora/libmamba/libmamba-2.0.6-build/mamba-2.0.6/libmambapy/src/libmambapy/bindings/legacy.cpp:52:26: /usr/include/pybind11/cast.h:1812:67: error: ‘SR.32262’ may be used uninitialized [-Werror=maybe-uninitialized] 1812 | return unpacking_collector(std::forward(args)...); | ^ /usr/include/pybind11/cast.h: In function ‘deprecated(std::basic_string_view >, std::basic_string_view >)’: /usr/include/pybind11/cast.h:1823:45: note: ‘SR.32262’ was declared here 1823 | return detail::collect_arguments(std::forward(args)...).call(derived().ptr()); | ~^ cc1plus: all warnings being treated as errors gmake[2]: *** [libmambapy/CMakeFiles/bindings.dir/build.make:96: libmambapy/CMakeFiles/bindings.dir/src/libmambapy/bindings/legacy.cpp.o] Error 1 I'm guessing 'SR.32262' is some kind of temporary variable. libmamba has taken the (perhaps admirable?) step of compiling with -Werror so it fails. The pybind11/
Re: FTBFS after mass rebuild (not during!)
Am Mo., 3. Feb. 2025 um 22:40 Uhr schrieb Jerry James :
>
> On Mon, Feb 3, 2025 at 2:22 PM Michael J Gruber
> wrote:
> > So, over at upstream they raised the suspicion that some parts of what
> > I'm linking are compiled with different flags. To recap: I get
> > ```
> > /usr/include/c++/15/bits/stl_vector.h:1262: std::vector<_Tp,
> > _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type)
> > [with _Tp = const char*; _Alloc = std::allocator;
> > reference = const char*&; size_type = long unsigned int]: Assertion
> > '__n < this->size()' failed.
> > Aborted (core dumped)
> > ```
> > in a part of code which basically does:
> > ```
> > FZ_FUNCTION std::vector
> > pdf_choice_widget_options2(fz_context* ctx, pdf_annot* tw, int
> > exportval)
> > {
> > int n = pdf_choice_widget_options(ctx, tw, exportval, nullptr);
> > std::vector opts(n);
> > int n2 = pdf_choice_widget_options(ctx, tw, exportval, &opts[0]);
> > assert(n2 == n);
> > std::vector ret(n);
> > for (int i=0; i > {
> > ret[i] = opts[i];
> > }
> > return ret;
> > }
> > ```
> > Is there anything regarding flags like NDEBUG, GLIBCXX_ASSERTIONS and
> > the like which could make the above throw when the .so is compiled
> > with different flags compared to the code that calls it? Something
> > that appeared with gcc15 or libstdc++ in gcc15?
>
> If n == 0, then &opts[0] is invalid, since opts is an empty vector in
> that case. The invalid access to the nonexistent zeroth element
> triggers an assertion failure inside operator[] when the code is
> compiled with -D_GLIBCXX_ASSERTIONS.
> --
Thanks! I had stumbled upon &opts[0] before, but my poor C
programmer's mind converted that to opts (as in arrays refs "are"
pointers) and expected the c++ compiler to do the same, when indeed it
is different (for an empty vector with zero elements). I converted
this to opts.data() now, and the first mock build in f42 works.
Hooray!
Cheers
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge case of packages which install to hardcoded $DESTDIR/usr/sbin
On Tue, Feb 04, 2025 at 02:54:30PM +, Sérgio Basto via devel wrote:
> Hi,
> In this case: "packages which install to hardcoded $DESTDIR/usr/sbin,
> but then use %{_sbindir} in %files, will need to be adjusted."
>
> I did this [1] after the make install, is that correct ?
>
> [1]
> %if "%{_sbindir}" == "%{_bindir}"
> mkdir -p %{buildroot}%{_bindir}
> mv %{buildroot}/usr/sbin/* %{buildroot}%{_bindir}
> %endif
This happened for udpcast, and lzap ended up patching the upstream
Makefile which seems better to me:
https://src.fedoraproject.org/rpms/udpcast/pull-request/4
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://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 Tue, Feb 04, 2025 at 09:45:19AM -0500, William Cohen wrote:
> >> +%global layout _opt
> >> +Release: 1%{?dist}%{?layout}
> > In various places the patch does such indirections… Please kill them, they
> > make the diff much more verbose and actually harder to follow.
> >
> > → Release: 1%{?dist}%{?_with_opt:_opt}
> >
> > Same for %{call_graph} as alias for %SOURCE12.
>
> The problem being addressed with the %SOURCEnn and %call_graph was that the
> call graph needs to be stored in srpm rpm. Those files need to be %sourcenn
> in the spec file, just defining %call_graph as the callgraph file is not
> going to pull the call graph file into the source rpm. Having the definition
> of %{call_graph} is to allow the later boilerplate code to be same between
> various spec files.
Yes, you need the file to be listed as Source.
My suggestion is to use %SOURCEnn in the "later boilerplate"
(with the number appropriately selected, e.g. the first unused).
This is nicer for the packager, 'cause the packager doesn't care
about the boilerplate being the same between various spec files.
They care about their single spec file being uncomplicated.
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Package review - submitter not responding
On 25-02-03 16:38, Kevin Fenzi wrote: On Mon, Feb 03, 2025 at 09:18:56PM +0100, Łukasz Wojniłowicz wrote: Hi all, according to https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#submitter_not_responding "When the submitter of a review ticket has not responded to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon." That did not happen at https://bugzilla.redhat.com/show_bug.cgi?id=2251506 though. Should this happen automatically? Nope. As far as I know there's no automation. If you would like to submit the same package, just submit your new review and close the stalled one as a duplicate. kevin Thanks. Will do. -- Łukasz -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://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 Sat, Feb 01, 2025 at 05:21:41PM +, Sérgio Basto wrote: > On Sat, 2025-02-01 at 08:50 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jan 31, 2025 at 08:47:16PM +, Sérgio Basto via devel > > wrote: > > > > The first batch: > > > > https://in.waw.pl/~zbyszek/fedora/sysusers_mass_spec_change_v1.diff.html > > I want download the sysusers_mass_spec_change_v3.diff in plain text > format and not in html https://in.waw.pl/~zbyszek/fedora/sysusers_mass_spec_change_v3.diff.txt 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: [rfc] mass package change to introduce sysusers.d configs
On Tue, 2025-02-04 at 10:16 +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Feb 01, 2025 at 05:21:41PM +, Sérgio Basto wrote: > > On Sat, 2025-02-01 at 08:50 +, Zbigniew Jędrzejewski-Szmek > > wrote: > > > On Fri, Jan 31, 2025 at 08:47:16PM +, Sérgio Basto via devel > > > wrote: > > > > > The first batch: > > > > > https://in.waw.pl/~zbyszek/fedora/sysusers_mass_spec_change_v1.diff.html > > > > I want download the sysusers_mass_spec_change_v3.diff in plain text > > format and not in html > > https://in.waw.pl/~zbyszek/fedora/sysusers_mass_spec_change_v3.diff.txt Thank you, patchview give you the list of packages [2] Should I apply it in the packages that I maintain ? for example apt [1] , applies the patch cleanly . [1] cd apt; git pull; patchview ../sysusers_mass_spec_change_v3.diff.txt --include=*apt.spec | patch -p1 [2] $patchview sysusers_mass_spec_change_v3.diff.txt File #1 abrt.spec File #2 avahi.spec File #3 bind9-next.spec File #4 bind.spec File #5 bsd-games.spec File #6 bzflag.spec File #7 ceph.spec File #8 clamav.spec File #9 copr-dist-git.spec File #10dbus-broker.spec File #11dogtag-pki.spec File #12freeipa.spec File #13gnokii.spec File #14groonga.spec File #15jetty.spec File #16knot.spec File #17nfs-utils.spec File #18openarc.spec File #19pcp.spec File #20pulseaudio.spec File #21puppet.spec File #22resalloc.spec File #23rpcbind.spec File #24sblim-sfcb.spec File #25teeworlds.spec File #26tomcat.spec File #27totpcgi.spec File #28trousers.spec File #29uucp.spec File #30virtualbox-guest-additions.spec File #31wesnoth.spec File #32389-ds-base.spec File #33clevis.spec File #34clevis.sysusers File #35dnsconfd.spec File #36ec2-instance-connect.spec File #37pacemaker.spec File #38tog-pegasus.spec File #39addrwatch/addrwatch.spec File #40akmods/akmods.spec File #41amanda/amanda.spec File #42anyterm/anyterm.spec File #43apt/apt.spec File #44asterisk/asterisk.spec File #45autossh/autossh.spec File #46BackupPC/BackupPC.spec File #47bacula/bacula.spec File #48barman/barman.spec File #49beanstalkd/beanstalkd.spec File #50beep/beep.spec File #51bitcoin-core/bitcoin-core.spec File #52boinc-client/boinc-client.spec File #53buildbot/buildbot.spec File #54calypso/calypso.spec File #55ccache/ccache.spec File #56chromium/chromium.spec File #57c-icap/c-icap.spec File #58cjdns/cjdns.spec File #59clamsmtp/clamsmtp.spec File #60cleanfeed/cleanfeed.spec File #61cntlm/cntlm.spec File #62condor/condor.spec File #63copr-backend/copr-backend.spec File #64copr-frontend/copr-frontend.spec File #65copr-keygen/copr-keygen.spec File #66corosync-qdevice/corosync-qdevice.spec File #67crack/crack.spec File #68crossfire/crossfire.spec File #69cyrus-imapd/cyrus-imapd.spec File #70dahdi-tools/dahdi-tools.spec File #71darkstat/darkstat.spec File #72davfs2/davfs2.spec File #73ddclient/ddclient.spec File #74deluge/deluge.spec File #75dhcp-forwarder/dhcp-forwarder.spec File #76dictd/dictd.spec File #77dionaea/dionaea.spec File #78direwolf/direwolf.spec File #79dist-git/dist-git.spec File #80dlt-daemon/dlt-daemon.spec File #81dmapd/dmapd.spec File #82dnsdist/dnsdist.spec File #83domoticz/domoticz.spec File #84ebnetd/ebnetd.spec File #85elfutils/elfutils.spec File #86erlang/erlang.spec File #87etcd/etcd.spec File #88exim/exim.spec File #89fapolicyd/fapolicyd.spec File #90festival/festival.spec File #91firebird/firebird.spec File #92flow-tools/flow-tools.spec File #93frozen-bubble/frozen-bubble.spec File #94galera/galera.spec File #95ganglia/ganglia.spec File #96getdns/getdns.spec File #97gitit/gitit.spec File #98gitolite3/gitolite3.spec File #99gkrellm/gkrellm.spec File #100 glusterfs/glusterfs.spec File #101 gmediarender/gmediarender.spec File #102 gns3-server/gns3-server.spec File #103 golang-github-shopify-toxiproxy/golang-github-shopify-toxiproxy.spec File #104 gr-funcube/gr-funcube.spec File #105 icecast/icecast.spec File #106 icecream/icecream.spec File #107 iguanaIR/iguanaIR.spec File #108 inadyn-mt/inadyn-mt.spec File #109 inn/inn.spec File #110 ipa-hcc/ipa-hcc.spec File #111 ip-sentinel/ip-sentinel.spec File #112 ipsilon/ipsilon.spec File #113 jab
Re: Package review - submitter not responding
On Mon, Feb 3, 2025 at 9:19 PM Łukasz Wojniłowicz wrote: > > Hi all, > according to > https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#submitter_not_responding > > "When the submitter of a review ticket has not responded to comments for one > month, a comment is added to the ticket indicating that the review is stalled > and that a response is needed soon." > > That did not happen at https://bugzilla.redhat.com/show_bug.cgi?id=2251506 > though. > > Should this happen automatically? AFAIK the only thing that happens automatically is that if the ticket has a NEEDINFO on either the submitter or the reviewer for a long time, the ticket is closed or reset. 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 2/4/25 11:22 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Feb 04, 2025 at 09:45:19AM -0500, William Cohen wrote:
+%global layout _opt
+Release: 1%{?dist}%{?layout}
>>> In various places the patch does such indirections… Please kill them, they
>>> make the diff much more verbose and actually harder to follow.
>>>
>>> → Release: 1%{?dist}%{?_with_opt:_opt}
>>>
>>> Same for %{call_graph} as alias for %SOURCE12.
>>
>> The problem being addressed with the %SOURCEnn and %call_graph was that the
>> call graph needs to be stored in srpm rpm. Those files need to be %sourcenn
>> in the spec file, just defining %call_graph as the callgraph file is not
>> going to pull the call graph file into the source rpm. Having the
>> definition of %{call_graph} is to allow the later boilerplate code to be
>> same between various spec files.
>
> Yes, you need the file to be listed as Source.
> My suggestion is to use %SOURCEnn in the "later boilerplate"
> (with the number appropriately selected, e.g. the first unused).
> This is nicer for the packager, 'cause the packager doesn't care
> about the boilerplate being the same between various spec files.
> They care about their single spec file being uncomplicated.
>
> Zbyszek
>
The %{call_graph} alias isn't complicating the spec file. The %{call_graph} as
alias for the source file makes it easier to understand the purpose of the
file. Overtime the source file might be changed. Having the alias right by
the source file localizes any changes that need to be made. The alias will
help people porting this functionality to other spec files as there are fewer
scattered locations to customize for the specific packages.
-Will
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Logs from Tuesday's FESCo Meeting (2025-02-04)
Full logs at: https://meetbot-raw.fedoraproject.org//meeting_matrix_fedoraproject-org/2025-02-04/fesco.2025-02-04-17.00.log.txt = # #meeting:fedoraproject.org: fesco = Meeting started by @nirik:matrix.scrye.com at 2025-02-04 17:00:50 Meeting summary --- * TOPIC: Init Process (@nirik:matrix.scrye.com, 17:01:05) * TOPIC: #3356 Change: Switch to EROFS for Live Media (@nirik:matrix.scrye.com, 17:07:37) * INFO: will defer to next meeting (@nirik:matrix.scrye.com, 17:09:17) * TOPIC: #3358 Change: Deprecate Zezere Provisioning Server (IoT) (@nirik:matrix.scrye.com, 17:09:22) * AGREED: change approved, but note that we would really like a better headless install/story if at all possible (+5,0,0) (@nirik:matrix.scrye.com, 17:33:36) * TOPIC: Next week's chair (@nirik:matrix.scrye.com, 17:34:14) * ACTION: jednorozec will chair next meeting (@nirik:matrix.scrye.com, 17:36:32) * TOPIC: Open Floor (@nirik:matrix.scrye.com, 17:36:42) Meeting ended at 2025-02-04 17:39:50 Action items * jednorozec will chair next meeting People Present (lines said) --- * @nirik:matrix.scrye.com (49) * @zodbot:fedora.im (15) * @sgallagh:fedora.im (12) * @conan_kudo:matrix.org (10) * @humaton:fedora.im (7) * @fale:fale.io (6) * @amoloney:fedora.im (4) * @meetbot:fedora.im (3) * @decathorpe:fedora.im (3) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: WRT "Add explicit BR: libxcrypt-devel"
Hi Gary, > On 3. Feb 2025, at 17:00, Gary Buhrmaster wrote: > > I never bothered to follow all the details > of the issue, but is there not a problem > where libxcrypt is not FIPS compliant? The answer is “it’s complicated”. NIST doesn’t really specify rules for password hashing in the FIPS context, they only cover key derivation from passwords, where they still recommend the dated PBKDF2. Better alternatives in the presence of attackers with GPUs exist. libxcrypt contains a bunch of password hashing implementations that are composed only of primitives that NIST considers acceptable in FIPS, e.g., sha512crypt. However, there’s a simple way to get out of this problem, and that is by defining in your compliance documentation that password hashing is not used for security and that you treat the password hashes as if they were plaintext. From that point of view, all that libxcrypt is doing is essentially equivalent to a base64encode(), and FIPS doesn’t care (*). *) this is not legal advice, I am not a lawyer, do your own research -- Clemens Lang RHEL Crypto Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge rebuild
On Mon, Jan 13, 2025 at 01:46:03PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jan 10, 2025 at 10:13:31AM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jan 10, 2025 at 08:58:32AM +0100, Florian Weimer wrote: > > > * Zbigniew Jędrzejewski-Szmek: > > > > > > > glibc > > > > > > If we rebuild glibc, should we do a second rebuild into your side tag? > > > > Probably… But let's coordinate (here or on Matrix). I hope we can > > avoid duplicate rebuilds. > > The update with the rebuilds has been pushed to stable > (https://bodhi.fedoraproject.org/updates/FEDORA-2025-da0a082e66). > rpm was pushed independently earlier today > (https://bodhi.fedoraproject.org/updates/FEDORA-2025-432932ed60). > > In the buildroot, builds should now see a merged filesystem. > Once the compose goes out, people installing rawhide should > end up with a merged filesystem, and people upgrading rawhide > should see a message like > /usr/sbin cannot be merged, found /usr/sbin/ > Once the mass rebuild goes through, people upgrading rawhide > should see a message like > All files under /usr/sbin are symlinks; linking to ./bin... > Once that's done, the merge is complete on upgraded systems. What's the component / script which prints this message? Is it safe to 'dnf update' an existing Fedora Rawhide installation now? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bin-sbin merge rebuild
On Tue, Feb 04, 2025 at 02:10:53PM +, Richard W.M. Jones wrote: > On Mon, Jan 13, 2025 at 01:46:03PM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jan 10, 2025 at 10:13:31AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Fri, Jan 10, 2025 at 08:58:32AM +0100, Florian Weimer wrote: > > > > * Zbigniew Jędrzejewski-Szmek: > > > > > > > > > glibc > > > > > > > > If we rebuild glibc, should we do a second rebuild into your side tag? > > > > > > Probably… But let's coordinate (here or on Matrix). I hope we can > > > avoid duplicate rebuilds. > > > > The update with the rebuilds has been pushed to stable > > (https://bodhi.fedoraproject.org/updates/FEDORA-2025-da0a082e66). > > rpm was pushed independently earlier today > > (https://bodhi.fedoraproject.org/updates/FEDORA-2025-432932ed60). > > > > In the buildroot, builds should now see a merged filesystem. > > Once the compose goes out, people installing rawhide should > > end up with a merged filesystem, and people upgrading rawhide > > should see a message like > > /usr/sbin cannot be merged, found /usr/sbin/ > > Once the mass rebuild goes through, people upgrading rawhide > > should see a message like > > All files under /usr/sbin are symlinks; linking to ./bin... > > Once that's done, the merge is complete on upgraded systems. > > What's the component / script which prints this message? To answer my own question, it's a Lua script in filesystem.spec. > Is it safe to 'dnf update' an existing Fedora Rawhide installation now? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://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 Sat, Jan 25, 2025, at 4:05 AM, Zbigniew Jędrzejewski-Szmek wrote: > So yeah, having a package with a sysusers file and files owned by the > users or groups defined therein works fine. (This was already possible > before, but required careful creation of a %pre scriptlet. The new > mechanism is much nicer.) Yes, but it is *much* better if you can to avoid having files owned by floating users in packages, because it greatly increases compatibility with image-based update systems. More on this in e.g. https://docs.fedoraproject.org/en-US/bootc/building-containers/#_invoking_useradd_as_part_of_a_container_build If for example you're doing the work to add sysusers right now and you happen to also have e.g. `/var/lib/foo` in your RPM owned by that user, please also take the opportunity to drop that entry (with `%ghost` if you want) and create it via systemd-tmpfiles instead. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
