Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)
The last time I observed (few years ago in 1464368) the tooling did not seem to exist. Would you mind providing such a tool in glibc-devel? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8241796 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] %caps is undocumented (Issue #2832)
And that seemed to be [4.7.0](http://rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities). Only example ref is [this](https://stackoverflow.com/questions/26898007/making-an-rpm-which-sets-posix-files-capabilities#26898008). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2832#issuecomment-1909328307 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] Safer handling of internal soname dependencies (Discussion #2872)
@pmatilai Can you expand a bit on what you mean by not liking parsing other people's config files? Is it that you would like a clean way to discover the system library paths searched by the dynamic loader? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8236915 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] Testsuite failure with rpm 4.18.2 (Issue #2874)
One thing I noticed is that, in this case, even the payload checksums have changed. An RPM version bump would only affect the header checksums... So there must be something else at play here. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1908567422 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] Testsuite failure with rpm 4.18.2 (Issue #2874)
When you build locally, do you see the same failure also *without* the patch associated with the PR in that CI job? This test has hardcoded checksums to test build reproducibility (with `SOURCE_DATE_EPOCH` clamping) so whenever the RPM version changes in `configure.ac` (or `CMakeLists.txt` in 4.19 and later), the checksums change as well since the RPM version is baked into the header when building packages. We typically adjust these checksums manually as part of a release bumping commit. There probably are other factors that also cause these checksums to change but I can't think of anything right now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1908564570 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] Testsuite failure with rpm 4.18.2 (Issue #2874)
I'm noticing a test suite failure when building 4.18.2. [See this CI
output](https://github.com/rpm-software-management/rpm-sequoia/actions/runs/7612930269/job/20731708038?pr=60#step:9:1521)
```
273. rpmsigdig.at:157: testing rpmkeys -Kv 2 ...
../../rpm/tests/rpmsigdig.at:159:
if ! [ -d testing/ ]; then
cp -aP "${RPMTEST}" .
chmod -R u+w testing/
mkdir -p testing/build
ln -s ../data/SOURCES testing/build/
fi
export RPMTEST="${PWD}/testing"
export TOPDIR="${RPMTEST}/build"
export HOME="${RPMTEST}"
rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
runroot rpm --initdb
runroot rpmbuild -bb --quiet \
--define "optflags -O2 -g" \
--define "_target_platform noarch-linux" \
--define "_binary_payload w.ufdio" \
--define "_buildhost localhost" \
--define "use_source_date_epoch_as_buildtime 1" \
--define "source_date_epoch_from_changelog 1" \
--define "clamp_mtime_to_source_date_epoch 1" \
/data/SPECS/attrtest.spec
for v in SHA256HEADER SHA1HEADER SIGMD5 PAYLOADDIGEST PAYLOADDIGESTALT; do
runroot rpm -q --qf "${v}: %{${v}}\n"
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
done
runroot rpmkeys -Kv /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
--- - 2024-01-22 14:50:58.866214647 +
+++
/home/runner/work/rpm-sequoia/rpm-sequoia/rpm-build/tests/rpmtests.dir/at-groups/273/stdout
2024-01-22 14:50:58.859174628 +
@@ -1,8 +1,8 @@
-SHA256HEADER:
eb512d3d8c282d0249701032591c53ffb5904c54c95de04783028387b224d8fe
-SHA1HEADER: a42c611d67870c1937623f0da2631eabdf33e948
-SIGMD5: 88d1037686ed3f5f6b67618b02cc47ef
-PAYLOADDIGEST:
116ce41ebb72f1877cda3d7dedaf5b78770e202d6389ade4e415d78548d703a8
-PAYLOADDIGESTALT:
116ce41ebb72f1877cda3d7dedaf5b78770e202d6389ade4e415d78548d703a8
+SHA256HEADER:
94d13620f7058c14f24605c1461a9ef89b5b50b80c421a0a0eb7f0c62fe0f638
+SHA1HEADER: 8036a9b66aa7781e4000a441e695bb076acfc450
+SIGMD5: 98d3343d19052974392ed389e121f4f8
+PAYLOADDIGEST:
91438332ac8fe92e4d4fcd45edb64b659323b893d9496a339f8587d19d00531a
+PAYLOADDIGESTALT:
91438332ac8fe92e4d4fcd45edb64b659323b893d9496a339f8587d19d00531a
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm:
Header SHA256 digest: OK
Header SHA1 digest: OK
273. rpmsigdig.at:157: 273. rpmkeys -Kv 2 (rpmsigdig.at:157):
FAILED (rpmsigdig.at:159)
```
I'm seeing the same failure when building locally. (I'm following the
instructions
[here](https://github.com/rpm-software-management/rpm-sequoia#building)).
I'd appreciate any tips on how to debug this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874
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] RFE: file trigger scriptlet arguments (Issue #2755)
> Note that there's no technical reason for _not_ adding the second argument > (the number of triggering packages) to transaction scriplets here, too. It's > the same code path underneath. OK, looking closer, the challenge with transactional file triggers and package counts is that we can't easily obtain the correct value for each involved package since we're iterating through *all files* in the transaction set, as opposed to each transaction element separately (as we do with non-transactional file triggers). This is done for performance reasons (I suppose) so changing it just to add a second argument to transactional file triggers doesn't seem worth it. After all, the original requirements of this ticket explicitly mention non-trans file triggers. I guess @pmatilai knew what he was talking about when filing this ticket, after all :smile: > Whether it's useful or not is another question but I'll probably lean towards > consistency here and include it. So nope, taking it back. Let's stick with the plan and only do this for the non-trans variants. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2755#issuecomment-1908268213 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] Split Perl dependency generators into a separate repo (Issue #2873)
FWIW, I think we should follow the [Python lead](https://github.com/rpm-software-management/python-rpm-packaging) and call it perl-rpm-packaging to allow for all sorts of helper material to live there and not just macros/scripts and the like. A bit of consistency is a nice bonus. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2873#issuecomment-1908146288 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] Split Perl dependency generators into a separate repo (Issue #2873)
Thanks for going forward with this. Can you add Tina (perlpunk) and me to the new repo, so we can continue there? For openSUSE we're way into switching to the proper perl version system (currently all packages with conflict-free updates in the last year are switched) and will start soon switching all packages (causing version conflicts temporary). It would be a major help when we wouldn't need a temporary step with manual provides to do so. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2873#issuecomment-1908107555 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] allow to support perl normal version scheme for rpm compatible versions (PR #2609)
Closed #2609. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2609#event-11584180219 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] allow to support perl normal version scheme for rpm compatible versions (PR #2609)
Thanks for the patch. We've decided to finally go ahead and split these scripts into their own repo, though, so I'm closing this one and adding a note to https://github.com/rpm-software-management/rpm/pull/2609 which tracks the splitting. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2609#issuecomment-1908092389 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 a new perl.prov script to generate normalized module versions (PR #2586)
Closed #2586. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2586#event-11584153608 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 a new perl.prov script to generate normalized module versions (PR #2586)
OK, let's do the splitting part ourselves first, via https://github.com/rpm-software-management/rpm/issues/2873. This PR should then be migrated to the new repo once it exists. I'll close it here and add a note to the splitting ticket. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2586#issuecomment-1908088552 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] Split Perl dependency generators into a separate repo (Issue #2873)
Split the Perl dependency generators into a separate GitHub repository managed by our organization. This will make it far easier for the community to maintain and is in the spirit of https://github.com/rpm-software-management/rpm/pull/1607, and more generally, of https://github.com/rpm-software-management/rpm/discussions/2747. We need to make sure the preserve the git history when migrating it, though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2873 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] "setarch i386 rpmbuild ... " no longer working for building 32-bit packages on x86_64 host (Issue #2850)
Yup, having discussed this with the rest of the team, we have to look at fixing this in RPM after all. It definitely is a regression introduced in 4.19 as `setarch` had always worked before. I'm putting it in our queue now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2850#issuecomment-1908056118 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 build directory auto path to %autosetup step (PR #2859)
@pmatilai commented on this pull request.
> @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn)
return cmd;
}
+/**
+ * Detect if an archive has a single top level entry, and it's a directory.
+ *
+ * @param path path of the archive
+ * @return 1 if archive as only a directory as top level entry,
+ * 0 if it contains multiple top level entries or a single file
+ * -1 on archive error
+ */
+static int singleRoot(const char *path)
+{
+ struct archive *a;
+ struct archive_entry *entry;
+ int r, ret, rootLen;
+ char *rootName;
Yup. This is a common idiom in the codebase.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#discussion_r1464863196
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] "setarch i386 rpmbuild ... " no longer working for building 32-bit packages on x86_64 host (Issue #2850)
Using `--target i386` doesn't help me either. An `%ifarch %ix86` clause is not used, and an `%ifarch x86_64` one is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2850#issuecomment-1908015086 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] "setarch i386 rpmbuild ... " no longer working for building 32-bit packages on x86_64 host (Issue #2850)
Just FTR, I tried this myself in a Fedora 38 and Fedora 39 container, and it worked. Or rather, the `--target i386` override on Fedora 39 resulted in the same outcome as when using `setarch i386` on Fedora 38, which is that rpmbuild attempted to do a 32bit build. That however failed for me (in both cases) with the following GCC error: ``` [...] gcc -O2 -g -march=i386 -mtune=i686 -c -o color.o color.c cc1: error: CPU you selected does not support x86-64 instruction set [...] ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2850#issuecomment-1907850580 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] "setarch i386 rpmbuild ... " no longer working for building 32-bit packages on x86_64 host (Issue #2850)
This is caused by the [x86-64 architecture levels patch](https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847) shipped in 4.19.0. When determining the target architecture internally in `rpmPlatform()`, we use `uname(2)` to obtain the system architecture, however with the above patch, it gets overridden from `i386` (when using `setarch(8)`) to the respective `x86_64` level that's detected. As a workaround, you can use `rpmbuild --target i386` which actually overrides native architecture detection as expected. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2850#issuecomment-1907837201 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] Check date/time for consistently using unsigned ints (#1228)
Static checking in RHEL discovered exactly one place where we still had time_t conversion to signed integers: getBuildTime(). Fixed that in https://github.com/rpm-software-management/rpm/commit/97aa64d8281974fb369c66d5aef8650515b89c52, I think we can consider this done now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1228#issuecomment-1907813791 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] Check date/time for consistently using unsigned ints (#1228)
Closed #1228 as completed via 97aa64d8281974fb369c66d5aef8650515b89c52. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1228#event-11582158266 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] Safer handling of internal soname dependencies (Discussion #2872)
This is one of those topics that gets raised semi-annually at least. To point
out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and
https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and
https://github.com/rpm-software-management/rpm/issues/1227 but there are
certainly more out there.
For some cases like an unfortunately named project starting with lib having a
Python/Perl module, the provide may be mostly harmless if ugly. The far worse
issue is bundled libraries that are incompatible with the system ones and not
even in the path, but create identical provide names which a depsolver may end
up pulling instead of the system level library, and break things quite badly.
The fundamental issue may well be unsolvable, the main focus here is to look
for a solution that makes those bundled libraries less dangerous. If other
problems get solved while we're at it, great.
The common suggestion is to filter out soname dependencies outside the system
library path, but this has multiple problems: filtering them on the rpm
metadata level doesn't make the dependencies go away, and they may well be
needed for sub-packages and so on. What may work better is transforming the
sonames dependencies for libraries outside system path to something else,
perhaps including the parent package name in the name so it can't be mixed with
the system or somebody elses bundled library. For provides one can do this by
parsing /etc/ld.so.conf[.d] but requires seems to require solving, which is
something elfdeps doesn't (and IMO, shouldn't) do. (I don't like parsing other
people's config files either, but that seems unavoidable)
One simple possibility would be giving elfdeps a list/regex of soname prefixes
to match. Eg, passing "libxml2" would cause it to map any dependencies found on
libxml* to some other, internal-suggesting name. Such as %{name}-libxml*. That
list/regex could be set by the packager, but to satisfy the goal of bundled
library safety, it needs to happen automatically for provides. I guess
something like this would do:
1. figure out system library path, considering ld.so.conf[.d] in the buildroot
and everything
2. find out any shared libraries in the buildroot outside that path
3. set the elfdeps mangler (eg %{name}-) to apply to everything
found in 2
4. profit?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872
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
