Re: [Rpm-maint] [rpm-software-management/rpm] posix.redirect2null deprecated without replacement (Issue #3192)
You could add a Lua table argument with some sort of encoding of the `posix_spawn` actions. This way, you could extend things further if new actions are added. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3192#issuecomment-2256182847 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] posix.redirect2null deprecated without replacement (Issue #3192)
**Describe the bug** Commit 46bd0ed2a9e70f942e7c58f953f30a66d30a5142 added a deprecation warning to `posix.redirect2null` and others, pointing to `rpm.execute` as a replacement, but `rpm.execute` does not provide a way to suppress output. **Expected behavior** There is a way to run a program with its output suppressed. We'd use this in the Fedora glibc package because we want to suppress the error message from `systemctl daemon-reexec` if systemd is not running. Bash is not necessarily installed at this point. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3192 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add RPM_LD_FLAGS to build environment (PR #2481)
> Ehm, never mind that, this is widely used in Fedora specs. Sigh. Yeah, I came to post this. It's just 180 packages outside of `%changelog` though, so it's not impossible to fix. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2481#issuecomment-1506498873 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] x86-64-v3, x86-64-v3 detection must take XCR0 into account (Issue #2463)
@Vogtinator SSE is part of the baseline spec for x86-64. For 32-bit i386, this was never properly enabled—there isn't a way to check that the SSE context switching support has been wired up properly. Obviously, it doesn't matter at this point because SSE software support is pervasive. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2463#issuecomment-1499044773 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] x86-64-v3, x86-64-v3 detection must take XCR0 into account (Issue #2463)
OSXSAVE only indicates that it's safe to use XGETBV, I think. In glibc, we mask AVX etc. if XCR0 indicates it's not available: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-features.c;h=978eb29f72550deeb237cc76c5cf78c153f0ffb6;hb=7b3d8558d92a123743699c577704aab4a2f3d949#l115 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2463#issuecomment-1494311149 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] x86-64-v3, x86-64-v3 detection must take XCR0 into account (Issue #2463)
The current logic is based solely on CPUID. This is not correct because it does not verify that the software stack (firmware/hypervisor/kernel) supports YMM and ZMM registers. For that, it is necessary to read the XCR0 register using the XGETBV instruction. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2463 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] How to get libb to export liba's symbols?
* Neal H. Walfield: > Hi Florian, > > On Tue, 10 May 2022 12:04:52 +0200, > Florian Weimer wrote: >> * Neal H. Walfield: >> >> > There are two major constraints. Because rpm's OpenPGP API is public, >> > it must be preserved until the next soname bump. And, the OpenPGP >> > backend should be pluggable. >> >> How is this plug-in mechanism supposed to work? Via RPM configuration >> files? > > It is a build-time configuration option. When you configure rpm, you > can do: > > ./configure --with-crypto=sequoia > > to get the Sequoia backend. --with-crypto defaults to libgcrypt, > which uses the internal OpenPGP implementation with libgcrypt. (There > is also --with-crypto=openssl, which uses the internal OpenPGP > implementation with OpenSSL.) That's a very limited form of pluggability. I expect the most portable approach (for ELF targets) is to use a stub shared object that contains all symbols, including those provided by dependencies. (librpmio.so should probably be a linker script referencing the actual object, to prevent accidental loading of librpmio.so via dlopen.) That approach keeps the run-time DT_NEEDED value an implementation detail. I don't know if libtool supports that out of the box. On non-ELF targets, you may need forwarder functions, and the plug-in library cannot use the same symbols. Thanks, Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] How to get libb to export liba's symbols?
* Neal H. Walfield: > There are two major constraints. Because rpm's OpenPGP API is public, > it must be preserved until the next soname bump. And, the OpenPGP > backend should be pluggable. How is this plug-in mechanism supposed to work? Via RPM configuration files? Thanks, Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
* Colin Walters: > On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote: >> * Chris Murphy: >> >>> Fedora 36 seems like a good time to do this. What do you think? >> >> It's a bit odd to locate a database under /usr that isn't pre-built and >> installed. > > Why is that odd? Mentally, I still associate /usr with something that can be mounted read-only from shared storage. >> I guess in theory there could be systems with a read-only >> /usr out there that still allow installation of packages into /opt. >> >> Does it really help to improve the snapshot situation? > > Yes. > > I didn't wake up one day and say "hey you know what, today I'm going > to move the rpm database just for fun". Neither, for that matter did > the OpenSUSE folks. We haven't had this conversation over and over > throughout the years just because it was some minor thing. > > What I *did* wake up one day and say I'm going to do is make upgrades > transactional and offline by default and hence safe. No one should > ever fear starting an operating system upgrade while their laptop is > at 30% battery. Administrators running important servers must be able > to easily roll back when the kernel *or* systemd (or something) else > regresses, because it's software, it regresses all the time despite > our best efforts. I appreciate these efforts. Although transactional-update (as documented below) seems have one major regression: transactional RPM updates now require reboots. 8-( > So yes again, this does matter. And it matters because whether you're > doing "image based upgrades" like ostree or just "client side offline > updates" like the > https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html > thing - it's very important *what data specifically* is > versioned/snapshotted and what isn't. On an ostree system for > example, it's completely normal that there are *two* rpm databases > (one you're running, one that's pending in the new root). > > All the data in the rpmdb is about content that's in `/usr`. That totally ignores Software Collections and packages from ISVs. If the expected future that RPM is going to be an OS-internal software deployment mechanism (and not be used for third-party software), it should not be a side effect of this change, but an explicit decision. Thanks, Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RFC: Relocate RPM and DNF databases to /usr
* Chris Murphy: > Fedora 36 seems like a good time to do this. What do you think? It's a bit odd to locate a database under /usr that isn't pre-built and installed. I guess in theory there could be systems with a read-only /usr out there that still allow installation of packages into /opt. Does it really help to improve the snapshot situation? What about software under /opt? Maybe this needs multiple RPM databases eventually, roughly aligned along file system boundaries. Thanks, Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Please provide source package name to dependency generators (#1736)
As far as I can see, `rpmfcApply` in `build/rpmfc.c` overwrites `%name` with the subpackage name. It would be nice to be able to pass the current source package name to a dependency generator as an argument. This will allow the dependency generator not to run for certain source packages (e.g., for the package that provides the generator but would otherwise trigger it during its own package build). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1736___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Run rpath check in parallel (#1714)
@fweimer-rh commented on this pull request.
> @@ -105,6 +104,7 @@ function check_rpath() {
allow_ORIGIN=1
for j; do
+ lower=$(echo $j | grep -o "$2" | awk '{print tolower($0)}')
I think you can use the `,,` expansion operator here:
```
$ bash -c 'echo ${0,,*}' FOO
foo
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1714#pullrequestreview-688327063___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] check-rpaths-worker script increases build time considerably for some packages (#1713)
Yes, `ET_REL` files can be skipped. If you are changing the file anyway, please also add `-W` to the `readelf` invocations, so that the output does not get truncated. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1713#issuecomment-864776521___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: implement wrapper for posix.fork()+posix.exec() (#389)
It might also be nice to use `posix_spawn`, which can be implemented more efficiently that the usual `fork`/`execve` sequence. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/389#issuecomment-363391402___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
This needs to be gated by an option, in case the command being run doesn't expect any data on standard input and exits before completely reading all input. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/386#issuecomment-361314866___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)
@Conan-Kudo: > Wouldn't that happen during the package build, rather than at runtime? It > seems like that's a package build-time action. I quoted the wrong part (Github doesn't seem to support automated quoting). I was actually referring to this: > I was thinking that it would be better to do it like Debian and generate > those in %post which also reduces the size of rpms and allows it to be noarch -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/144#issuecomment-278350468___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)
@bmwiedemann wrote: > The alternative approach would be to change the macro generating them and > first touch source .py files to set their date to $SOURCE_DATE_EPOCH so that > this gets embedded in .pyc headers I doubt that RPM can do this without delayed script execution because the bytecode generator is not necessarily installed when the %post runs. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/144#issuecomment-277920680___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [PATCH] Extend %changelog to support full timestamps
On 10/06/2016 09:10 AM, Pavlina Varekova wrote: Extend %changelog to support full timestamps The newly accepted date format is Mon Jan 6 09:02:22 CEST 2016 (like output of "date" command). Original format "Mon Jun 6 2016" is still supported. I think it would be better to use ISO 8601 format (perhaps with space instead of 'T' as the date/time separator). The week day information is redundant and only causes consistency issues. Thanks, Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH] Remove anti-cheating protection for --short-circuit
This protection is in the way if the --short-circuit -bb is used to
build packages for testing the effects of complex dependency changes
in a spec file.
diff --git a/build/build.c b/build/build.c
index 04b039c..1bcc436 100644
--- a/build/build.c
+++ b/build/build.c
@@ -265,7 +265,7 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int what)
return rc;
if (((what & RPMBUILD_PACKAGEBINARY) && !test) &&
- (rc = packageBinaries(spec, cookie, (didBuild == 0
+ (rc = packageBinaries(spec, cookie)))
goto exit;
if ((what & RPMBUILD_CLEAN) &&
diff --git a/build/pack.c b/build/pack.c
index f9fb3a0..371d5ea 100644
--- a/build/pack.c
+++ b/build/pack.c
@@ -559,7 +559,7 @@ static rpmRC checkPackages(char *pkgcheck)
return RPMRC_OK;
}
-rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
+rpmRC packageBinaries(rpmSpec spec, const char *cookie)
{
rpmRC rc;
const char *errorString;
@@ -590,10 +590,6 @@ rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
headerPutBin(pkg->header, RPMTAG_SOURCEPKGID, spec->sourcePkgId,16);
}
- if (cheating) {
- (void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
- }
-
{ char *binFormat = rpmGetPath("%{_rpmfilename}", NULL);
char *binRpm, *binDir;
binRpm = headerFormat(pkg->header, binFormat, );
diff --git a/build/rpmbuild_internal.h b/build/rpmbuild_internal.h
index 7dd577f..18ce1df 100644
--- a/build/rpmbuild_internal.h
+++ b/build/rpmbuild_internal.h
@@ -406,11 +406,10 @@ rpmRC processSourceFiles(rpmSpec spec, rpmBuildPkgFlags pkgFlags);
* Generate binary package(s).
* @param spec spec file control structure
* @param cookie build identifier "cookie" or NULL
- * @param cheating was build shortcircuited?
* @return RPMRC_OK on success
*/
RPM_GNUC_INTERNAL
-rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating);
+rpmRC packageBinaries(rpmSpec spec, const char *cookie);
/** \ingroup rpmbuild
* Generate source package.
diff --git a/doc/rpmbuild.8 b/doc/rpmbuild.8
index 1d22913..c2a9d5d 100644
--- a/doc/rpmbuild.8
+++ b/doc/rpmbuild.8
@@ -192,9 +192,8 @@ used standalone, eg. "\fBrpmbuild\fR \fB--rmspec foo.spec\fR").
\fB--short-circuit\fR
Skip straight to specified stage (i.e., skip all stages leading
up to the specified stage). Only valid with \fB-bc\fR, \fB-bi\fR,
-and \fB-bb\fR. Useful for local testing only. Packages built this
-way will be marked with an unsatisfiable dependency to prevent
-their accidental use.
+and \fB-bb\fR. Packages built this way should only be used for local
+testing, and not for production.
.TP
\fB--build-in-place\fR
Build from locally checked out sources. Sets _builddir to current working
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Speeding up XZ processing
RPM currently requests SHA-256 hashing from XZ, which is superfluous for its main operations due to the RPM-based integrity checks. Here are some ways to avoid this overhead: Add an option to liblzma to disable checking on decompression. I'll ask upstream about this. Fix rpm2cpio and rpm2archive so that payload contents is checked against the file hashes in the header during processing. (This would allow adding meaningful signature checking to these tools, too.) When writing RPMs, specify LZMA_CHECK_NONE. Set the PAYLOADFLAGS tag to 2 check=none (or something similar). Update applydeltarpm so that it specifies LZMA_CHECK_NONE if PAYLOADFLAGS has this value. To measure the speed improvement during installation, you can use xzcat and xz -2 --check=none to recompress the payload (after detaching it from the header). In my experiments, about 30% the time related to decompression is spent in SHA-256 hashing. The win for compression is obviously smaller because compression itself takes more time. -- Florian Weimer / Red Hat Product Security ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM 4.12.0 alpha released
On 06/27/2014 04:41 PM, Panu Matilainen wrote: - Support for files over 4GB in packages Is the new payload format documented somewhere? It seems to use the FX index in a pseudo-cpio header instead of duplicating the data from the header, but it would be nice to to see this spelled out explicitly. -- Florian Weimer / Red Hat Product Security ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
