From mdomonko at redhat.com Tue Mar 14 11:27:14 2023 From: mdomonko at redhat.com (Michal Domonkos) Date: Tue, 14 Mar 2023 12:27:14 +0100 Subject: RPM 4.18.1 released! Message-ID: This is a bug fix release addressing a number of regressions and other issues. Highlights include: * Preserve packages bit-by-bit when adding and then removing signatures * Fix install of block and character special files * Disable debuginfod server lookups during package builds * Plugin fixes (fapolicyd and selinux) * Various OpenPGP and macro parser fixes Details and download info at https://rpm.org/wiki/Releases/4.18.1 -- Michal Domonkos / RPM dev team / Red Hat, Inc. From mhroncok at redhat.com Tue Mar 14 11:54:05 2023 From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=) Date: Tue, 14 Mar 2023 12:54:05 +0100 Subject: RPM 4.18.1 released! In-Reply-To: References: Message-ID: <0779c3c6-396a-01c2-5afa-557e0a0e340d@redhat.com> On 14. 03. 23 12:27, Michal Domonkos wrote: > This is a bug fix release addressing a number of regressions and other issues. > Highlights include: > > * Preserve packages bit-by-bit when adding and then removing signatures > * Fix install of block and character special files > * Disable debuginfod server lookups during package builds > * Plugin fixes (fapolicyd and selinux) > * Various OpenPGP and macro parser fixes > > Details and download info at > > https://rpm.org/wiki/Releases/4.18.1 Hello. > Restore BuildRequires check in rpmbuild -bp (regression in 4.15.0) Does this mean I cannot run rpmbuild -bp (and hence e.g. fedpkg prep in Fedora) without installing all the build dependencies? Or did I understand that wrongly? > Issue a deprecation warning on %patchN syntax Is there a timeframe for actual removal? There are ~10k such lines in ~3.3k Fedora Rawhide packages. > Don?t embed CPU count of build system in packages (#2343) I worry that the way this was fixed is probably a breaking change. Packages out there use e.g. SPHINXOPTS='%{?_smp_mflags}' (~50 Fedora packages) which will turn into SPHINXOPTS='-j${RPM_BUILD_NCPUS}' which will not work. -- Miro Hron?ok -- Phone: +420777974800 IRC: mhroncok From anymouseprophet at gmail.com Thu Mar 16 22:08:04 2023 From: anymouseprophet at gmail.com (Michael Peters) Date: Thu, 16 Mar 2023 15:08:04 -0700 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild Message-ID: Hi. I suspect these issues are with MY system and not RPM itself. First observed with 4.18.0 but also present with 4.18.1 No earlier version was tried. Linux From Scratch (LFS) 11.3 system I built at beginning of march and am RPM bootstrapping. It's currently a very minimal system with just the LFS stuff plus cURL and it's dependencies (using GnuTLS) and RPM and it's dependencies. x86_64 system but it's not multiarch (so I am setting %_lib to lib and %_libdir to /usr/lib) Big issue: RPM removes the execution bit on shared object files. First package I built was glibc and of course installing the resulting RPM broke the system because the shared libraries were not executable. I noticed when I add /bin/false at the end of the %install section - the installed library and object files have the execution bit - it's one of the post scriptlets leaving them non-exucatable. Workaround is to explicitly set %attr(0755,root,root) on shared object files in the %files section but obviously I want to fix why this happens. Interestingly it does NOT remove the execution bit from executable binaries, only shared objects (shared libraries and plugins) --- Second issue - everything I build gives a warning of missing build-id. So I suspect either there is an undocumented dependency I am missing, or a tool-chain compile-time option that wasn't used when compiling the toolchain. Any ideas as to what is causing that? elfutils is installed (0.188) with eu- prefix on the elfutils binaries. Thank you for any suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.andrews at columbus.rr.com Thu Mar 16 23:24:37 2023 From: scott.andrews at columbus.rr.com (Scott Andrews) Date: Thu, 16 Mar 2023 19:24:37 -0400 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: References: Message-ID: <54fdce52-69b4-ab49-98f0-1bc1a6f4f3a8@columbus.rr.com> I am not a developer of associated with rpm.... Just a user. On 3/16/23 18:08, Michael Peters wrote: > Hi. I suspect these issues are with MY system and not RPM itself. > First observed with 4.18.0 but also present with 4.18.1 > > No earlier version was tried. > > Linux From Scratch (LFS) 11.3 system I built at beginning of march and > am RPM bootstrapping. Yikes.... > It's currently a very minimal system with just the LFS stuff plus cURL > and it's dependencies (using GnuTLS) and RPM and it's dependencies. > > x86_64 system but it's not multiarch (so I am setting %_lib to lib and > %_libdir to /usr/lib) I don't do that rpm -E %_lib lib rpm -E %_libdir /usr/lib > > Big issue: RPM removes the execution bit on shared object files. First > package I built was glibc and of course installing the resulting RPM > broke the system because the shared libraries were not executable. > > I noticed when I add /bin/false at the end of the %install section - > the installed library and object files have the execution bit - it's > one of the post scriptlets leaving them non-exucatable. > > Workaround is to explicitly set %attr(0755,root,root) on shared object > files in the %files section but obviously I want to fix why this happens. > > Interestingly it does NOT remove the execution bit from executable > binaries, only shared objects (shared libraries and plugins) > I build a scratch built os's for raspberry pi armv7l-unknown-linux-gnueabihf and aarch64-unknown-linux-gnu I have not seen this error on any of my builds rpm --version RPM version 4.18.0 %files -f %{_builddir}/filelist.rpm %defattr(-,root,root) From working system..... ls -hal usr/lib/crt* -rw-r--r-- 1 root root 6.9K Feb 14 02:14 usr/lib/crt1.o -rw-r--r-- 1 root root 2.3K Feb 14 02:14 usr/lib/crti.o -rw-r--r-- 1 root root 1.9K Feb 14 02:14 usr/lib/crtn.o ls -hal usr/lib/ -rw-r--r--? 1 root root? 21M Feb 14 02:21 libc.a -rw-r--r--? 1 root root? 257 Feb 14 02:14 libc.so -rwxr-xr-x? 1 root root 1.5M Feb 14 02:22 libc.so.6 -rw-r--r--? 1 root root 275K Feb 14 02:21 libresolv.a lrwxrwxrwx? 1 root root?? 14 Feb 14 02:21 libresolv.so -> libresolv.so.2 -rwxr-xr-x? 1 root root? 66K Feb 14 02:22 libresolv.so.2 -rwxr-xr-x? 1 root root 196K Feb 14 02:22 ld-linux-armhf.so.3 > --- > > Second issue - everything I build gives a warning of missing build-id. > > So I suspect either there is an undocumented dependency I am missing, > or a tool-chain compile-time option that wasn't used when compiling > the toolchain. > > Any ideas as to what is causing that? add this to .rpmmacro in the user home directory where you are building It turns off build ides %_unique_build_ids 0 %_build_id_links none > > elfutils is installed (0.188) with eu- prefix on the elfutils binaries. from my spec file: %prep %setup -q -n elfutils-%{version} # remove failing test due to missing glibc debug package sed -e 's/run-backtrace-native.sh//g' -i tests/Makefile.am autoreconf -fiv %build _options=(--prefix=/usr ?? ?--sysconfdir=/etc ?? ?--program-prefix=eu- ?? ?--enable-deterministic-archives ?? ?--disable-debuginfod ?? ?--disable-libdebuginfod) ./configure "${_options[@]}" %{make_build} %install %{make_install} > > Thank you for any suggestions. > > _______________________________________________ > Rpm-list mailing list > Rpm-list at lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-list From pmatilai at redhat.com Mon Mar 20 08:42:40 2023 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 20 Mar 2023 10:42:40 +0200 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: References: Message-ID: On 3/17/23 00:08, Michael Peters wrote: > Hi. I suspect these issues are with MY system and not RPM itself. > First observed with 4.18.0 but also present with 4.18.1 > > No earlier version was tried. > > Linux From Scratch (LFS) 11.3 system I built at beginning of march and > am RPM bootstrapping. > It's currently a very minimal system with just the LFS stuff plus cURL > and it's dependencies (using GnuTLS) and RPM and it's dependencies. > > x86_64 system but it's not multiarch (so I am setting %_lib to lib and > %_libdir to /usr/lib) > > Big issue: RPM removes the execution bit on shared object files. First > package I built was glibc and of course installing the resulting RPM > broke the system because the shared libraries were not executable. > > I noticed when I add /bin/false at the end of the %install section - the > installed library and object files have the execution bit - it's one of > the post scriptlets leaving them non-exucatable. > > Workaround is to explicitly set %attr(0755,root,root) on shared object > files in the %files section but obviously I want to fix why this happens. > > Interestingly it does NOT remove the execution bit from executable > binaries, only shared objects (shared libraries and plugins) Most shared libraries are NOT executable, and should not be packaged as such. Which is why rpm automatically strips the executable flags from those deemed only shared libraries via brp-elfperms script after the install stage. glibc (ld*.so rather) being the special case of course. Rpm is supposed to leave those *actually* executable libraries alone, but this isn't working as intended, I can reproduce it here. A bit surprising it hasn't been reported on any of the major distros, but perhaps they do have those explicit permissions set. I'd actually recommend just setting those explicit permissions with %attr(), that makes the critically important special case stand out and serves as a protection against other mishaps too. That said, those brp scripts can be disabled as well, for this particular, put this in the spec needing override: %define brp_elfdeps %{nil} > > Second issue - everything I build gives a warning of missing build-id. > > So I suspect either there is an undocumented dependency I am missing, or > a tool-chain compile-time option that wasn't used when compiling the > toolchain. > > Any ideas as to what is causing that? AIUI it means that the compiler/linker didn't generate a proper build-id for binaries. I suppose this would be a configure option to gcc or such, at least in Fedora gcc adds build-ids automatically to all builds. Being early in bootstrapping you might just want to disable as Scott suggested. - Panu - > > elfutils is installed (0.188) with eu- prefix on the elfutils binaries. > > Thank you for any suggestions. > > _______________________________________________ > Rpm-list mailing list > Rpm-list at lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-list From fweimer at redhat.com Mon Mar 20 09:13:49 2023 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 20 Mar 2023 10:13:49 +0100 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: (Panu Matilainen's message of "Mon, 20 Mar 2023 10:42:40 +0200") References: Message-ID: <87lejru6nm.fsf@oldenburg.str.redhat.com> * Panu Matilainen: > Most shared libraries are NOT executable, and should not be packaged > as such. Which is why rpm automatically strips the executable flags > from those deemed only shared libraries via brp-elfperms script after > the install stage. glibc (ld*.so rather) being the special case of > course. Huh. We need to install all shared objects as executable, otherwise Linux security modules (e.g., SELinux with certain policies) will not allow mapping them as PROT_EXEC, and nothing will work. The ELF backend i binutils ld had a long-standing bug where it did not set the ELF entrypoint to 0 on shared objects by default (marking them as not directly executable). This bug has been fixed. However, the kernel does not yet refuse to execute ELF shared objects which have no ELF interpreter and entry point 0. That bug remains to be fixed. These are the issues that need to be fixed to avoid confusing crashes. Removing the executable bit is not the right approach. Thanks, Florian From pmatilai at redhat.com Mon Mar 20 09:37:16 2023 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 20 Mar 2023 11:37:16 +0200 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: <87lejru6nm.fsf@oldenburg.str.redhat.com> References: <87lejru6nm.fsf@oldenburg.str.redhat.com> Message-ID: On 3/20/23 11:13, Florian Weimer wrote: > * Panu Matilainen: > >> Most shared libraries are NOT executable, and should not be packaged >> as such. Which is why rpm automatically strips the executable flags >> from those deemed only shared libraries via brp-elfperms script after >> the install stage. glibc (ld*.so rather) being the special case of >> course. > > Huh. We need to install all shared objects as executable, otherwise > Linux security modules (e.g., SELinux with certain policies) will not > allow mapping them as PROT_EXEC, and nothing will work. > > The ELF backend i binutils ld had a long-standing bug where it did not > set the ELF entrypoint to 0 on shared objects by default (marking them > as not directly executable). This bug has been fixed. However, the > kernel does not yet refuse to execute ELF shared objects which have no > ELF interpreter and entry point 0. That bug remains to be fixed. > > These are the issues that need to be fixed to avoid confusing crashes. > Removing the executable bit is not the right approach. Huh indeed. This is the first I ever hear about *any* of that. I've only seen and heard various attemps by distros to avoid having to unnecessarily set executable bits on libraries. It's not a bad day when you learn something new... So this would largely be Linux specific, and I guess LSM specific at that. Seems the executable stripping is a "build root policy" for a reason... and I realize now why none of the big distros have seen this before: they all override rpm's default brp set and presumably haven't been updated to run brp-elfperms at all. I was just looking at this and found no way to persuade eu-elfclassify to consider ld-*.so as an executable, which breaks it for what I thought was the primary usecase. But clearly I'm missing more than a little in the big picture here... - Panu - From fweimer at redhat.com Mon Mar 20 09:42:54 2023 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 20 Mar 2023 10:42:54 +0100 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: (Panu Matilainen's message of "Mon, 20 Mar 2023 11:37:16 +0200") References: <87lejru6nm.fsf@oldenburg.str.redhat.com> Message-ID: <87cz53u5b5.fsf@oldenburg.str.redhat.com> * Panu Matilainen: > I was just looking at this and found no way to persuade eu-elfclassify > to consider ld-*.so as an executable, which breaks it for what I > thought was the primary usecase. But clearly I'm missing more than a > little in the big picture here... We can teach eu-elfclassify to look at the entry point address. That's going to rely on the binutils fix, of course. Thanks, Florian From pmatilai at redhat.com Mon Mar 20 09:51:57 2023 From: pmatilai at redhat.com (Panu Matilainen) Date: Mon, 20 Mar 2023 11:51:57 +0200 Subject: Two (possibly related) issue w/ 4.18.x rpmbuild In-Reply-To: <87cz53u5b5.fsf@oldenburg.str.redhat.com> References: <87lejru6nm.fsf@oldenburg.str.redhat.com> <87cz53u5b5.fsf@oldenburg.str.redhat.com> Message-ID: <929b6744-bf04-31df-5d05-1ab1e1fec0e2@redhat.com> On 3/20/23 11:42, Florian Weimer wrote: > * Panu Matilainen: > >> I was just looking at this and found no way to persuade eu-elfclassify >> to consider ld-*.so as an executable, which breaks it for what I >> thought was the primary usecase. But clearly I'm missing more than a >> little in the big picture here... > > We can teach eu-elfclassify to look at the entry point address. That's > going to rely on the binutils fix, of course. There's not much point if stripping "unnecessary" executable bits is as misguided as it seems. - Panu - From mdomonko at redhat.com Thu Mar 23 11:36:48 2023 From: mdomonko at redhat.com (Michal Domonkos) Date: Thu, 23 Mar 2023 12:36:48 +0100 Subject: RPM 4.18.1 released! In-Reply-To: <0779c3c6-396a-01c2-5afa-557e0a0e340d@redhat.com> References: <0779c3c6-396a-01c2-5afa-557e0a0e340d@redhat.com> Message-ID: Hi Miro, Apologies for the late reply, I somehow managed to completely miss your email. On Tue, Mar 14, 2023 at 12:54:05PM +0100, Miro Hron?ok wrote: > > Restore BuildRequires check in rpmbuild -bp (regression in 4.15.0) > > Does this mean I cannot run rpmbuild -bp (and hence e.g. fedpkg prep in > Fedora) without installing all the build dependencies? Or did I understand > that wrongly? Yes, that's correct. It's a bugfix of a regression in 4.15 where it was accidentally broken in a refactoring. More details here: https://github.com/rpm-software-management/rpm/pull/2271 If -bp is desired on a system without the build deps installed, and the package doesn't require any of those for %prep, then one can simply issue the --nodeps flag to rpmbuild. In fact, fedpkg prep does exactly that, it uses --nodeps (you can check that by running fedpkg --verbose prep). So in practice, fedpkg isn't even affected by this change and can still fail if a package requires a build dependency in %prep. > > Issue a deprecation warning on %patchN syntax > > Is there a timeframe for actual removal? There are ~10k such lines in ~3.3k > Fedora Rawhide packages. I'm not aware of any specific plans here but it has to be a major release where this happens, and 4.19 (this year's Q3) would perhaps be too early, which means 4.20 (next year's Q3) at the earliest. > > Don?t embed CPU count of build system in packages (#2343) > > I worry that the way this was fixed is probably a breaking change. Packages > out there use e.g. SPHINXOPTS='%{?_smp_mflags}' (~50 Fedora packages) which > will turn into SPHINXOPTS='-j${RPM_BUILD_NCPUS}' which will not work. Oh, this may indeed be an issue. There seems to have been an assumption that the %_smp_mflags macro never includes any shell variables that need to be expanded at build time. This assumption has now changed with 4.18.1. In any case, there doesn't seem to be a reason for the macro to be single-quoted in SPHINXOPTS. In that sense, it's a packaging issue that needs to be addressed in the affected packages. That said, we might as well take into consideration the fact that this is a *stable* update of RPM. Panu, any thoughts on this? -- Michal Domonkos / RPM dev team / Red Hat, Inc. From Tim.Mooney at ndsu.edu Fri Mar 24 04:32:11 2023 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Thu, 23 Mar 2023 23:32:11 -0500 (CDT) Subject: directory conflicts between packages Message-ID: <906ec8f6-84e8-1946-7e16-caf317f315db@ndsu.edu> All- It seems the rpm 4.16.1.3 that's part of RHEL 9 behaves differently from previous versions of RPM with regard to multiple packages that claim the same directory. This particularly impacts perl modules, where two unrelated perl modules may both want to install files into a subdirectory. For example, perl-Test-A and perl-Test-B may not have any dependency relation between them, but they may both deliver files into %{perl_sitelib}/Test For years, under previous versions of RPM, the recommendation was that both packages should claim a directory with %dir. Based on my reading of the Fedora perl packaging guidelines, that's *still* the recommendation: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_directory_ownership At least on RHEL 9, though, with rpm 4.16.1.3, that's treated as an error: Error: Transaction test error: file /usr/local/lib64/perl5/5.32/auto/Test from install of perl-Test-Exception-0.43-1.x86_64 conflicts with file from package perl-Test-Pod-1.52-1.x86_64 file /usr/local/share/perl5/5.32/Test from install of perl-Test-Exception-0.43-1.x86_64 conflicts with file from package perl-Test-Pod-1.52-1.x86_64 With that error in mind, what's the modern recommendation for packaging directories that may be used by multiple unrelated packages? Thanks, Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology / 701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 From mhroncok at redhat.com Fri Mar 24 09:35:09 2023 From: mhroncok at redhat.com (=?UTF-8?Q?Miro_Hron=c4=8dok?=) Date: Fri, 24 Mar 2023 10:35:09 +0100 Subject: directory conflicts between packages In-Reply-To: <906ec8f6-84e8-1946-7e16-caf317f315db@ndsu.edu> References: <906ec8f6-84e8-1946-7e16-caf317f315db@ndsu.edu> Message-ID: <8799e2d7-7e70-c795-871d-0c9bd99eb9c3@redhat.com> On 24. 03. 23 5:32, Tim Mooney wrote: > > All- > > It seems the rpm 4.16.1.3 that's part of RHEL 9 behaves differently from > previous versions of RPM with regard to multiple packages that claim the > same directory. > > This particularly impacts perl modules, where two unrelated perl modules > may both want to install files into a subdirectory.? For example, > perl-Test-A and perl-Test-B may not have any dependency relation between > them, but they may both deliver files into > > ????%{perl_sitelib}/Test > > For years, under previous versions of RPM, the recommendation was that > both packages should claim a directory with %dir.? Based on my reading > of the Fedora perl packaging guidelines, that's *still* the > recommendation: > > ????https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_directory_ownership > > At least on RHEL 9, though, with rpm 4.16.1.3, that's treated as an error: > > ????Error: Transaction test error: > ? file /usr/local/lib64/perl5/5.32/auto/Test from install of > perl-Test-Exception-0.43-1.x86_64 conflicts with file from package > perl-Test-Pod-1.52-1.x86_64 > ? file /usr/local/share/perl5/5.32/Test from install of > perl-Test-Exception-0.43-1.x86_64 conflicts with file from package > perl-Test-Pod-1.52-1.x86_64 > > With that error in mind, what's the modern recommendation for packaging > directories that may be used by multiple unrelated packages? Are you 100 % sure the path is a directory in both packages? Not a file, not a link? -- Miro Hron?ok -- Phone: +420777974800 IRC: mhroncok From Tim.Mooney at ndsu.edu Fri Mar 24 20:01:56 2023 From: Tim.Mooney at ndsu.edu (Tim Mooney) Date: Fri, 24 Mar 2023 15:01:56 -0500 (CDT) Subject: directory conflicts between packages In-Reply-To: <906ec8f6-84e8-1946-7e16-caf317f315db@ndsu.edu> References: <906ec8f6-84e8-1946-7e16-caf317f315db@ndsu.edu> Message-ID: In regard to: directory conflicts between packages, Tim Mooney said (at...: > At least on RHEL 9, though, with rpm 4.16.1.3, that's treated as an error: > > Error: Transaction test error: > file /usr/local/lib64/perl5/5.32/auto/Test from install of > perl-Test-Exception-0.43-1.x86_64 conflicts with file from package > perl-Test-Pod-1.52-1.x86_64 > file /usr/local/share/perl5/5.32/Test from install of > perl-Test-Exception-0.43-1.x86_64 conflicts with file from package > perl-Test-Pod-1.52-1.x86_64 I figured this out, and the error was mine. It's still fine (AFAICT) for perl modules to share directories when needed, and for each of them to claim a directory like %{perl_sitelib}/Test Where the problem happens is if one of the packages specifies different permissions for that directory. In my case, our local perl-Test-Pod was specifying an incorrect group on that directory. We've historically used %define OWNER root %define GROUP local at the top of our local spec files and then %defattr(-,%{OWNER},%{GROUP}) in the %files section, along with managing permissions as needed. The problem is that %{GROUP} became a pre-defined macro based on the Group: tag with rpm in RHEL 8, and some of our spec files haven't been updated to change our conflicting %{GROUP} to something else. perl-Test-Pod was one of them. Once I fixed that, the problem went away. Sorry for the noise. Tim -- Tim Mooney Tim.Mooney at ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology / 701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164