Hmm, that's indeed strange. I tried to reproduce the same myself (using the
steps you provided, thanks!) but could not - the test passed for me.
Could you try doing this against a new, fresh build of RPM in another directory?
--
Reply to this email directly or view it on GitHub:
Looking at `cpio -t` output is proving more helpful :smile:
This from the Ubuntu-created file:
> [pmatilai︎localhost tmp]$ cpio -tv < out |head -4
6 blocks
drwx-- 1 root root0 Jun 28 2011 ./a/dir
-r 1 root root 15 Jun 28 2011 ./a/file
drwx--
@pmatilai I realize that my suggestion looks a lot like what you were
attempting to do on a per-package basis? Were you trying to (a) create a
template /etc/ld.so.conf which just includes the the fragment directory, and
for the buildroot of the rpm build (b) allow it to parse any fragments that
4.18.2 would be missing at least this: 7ec148c1d61e0b526ae5c917f0ddc2b4a3222146
which could affect it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1909841982
You are receiving this because you are subscribed to
Yup, and the CI running on Ubuntu could indeed have an effect on the checksums.
I can't see any obvious candidates in the tag list but it would be useful if
you could get us the output of `--xml` as @pmatilai suggested above. That way
we could compare it to what we get on a Fedora-built version
My built `rpm` doesn't udnerstand `--xml`:
```
us@alice:/tmp/rpm/rpm/b$ ./rpm -qp --xml
./tests/rpmtests.dir/273/testing/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
rpm: --xml: unknown option
```
Instead I've attached the generated rpm file (found in
Thanks! Meanwhile, I did a build of RPM in an Ubuntu 22.04 LTS container and
got the exact same package as you, the diff follows:
```diff
diff --git a/fedora.xml b/ubuntu.xml
index c4f4df7..6546d2e 100644
--- a/fedora.xml
+++ b/ubuntu.xml
@@ -6,14 +6,14 @@
5925
-
Okay, the headers are otherwise identical so it's the payload that has to
differ then, and that payloaddigest changing throws everything else off too.
And indeed, extracting the rpm2cpio output shows some differences (from `diff
-u -a` output), eg:
```
So this is actually another bug fixed by
a0553eb38a01772254cd48fef7ad116294cf801a
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910075031
You are receiving this because you are subscribed to this thread.
Message
Yes, that possible ld.so.conf fragment in the buildroot needs to be covered.
But, I think the hosts ld.so.conf[.d] needs to be processed as well. The
currently building package could be installing to a subdirectory that some
other package (which would have to be a build-dependency) has declared
No no. What I'm telling you is to script the file section generation. Something
like
```
for n in psych mental; do
cat << EOF > ${n}.txt
%{ruby_libdir}/${n}
%{ruby_libdir}/${n}.rb
%{ruby_libarchdir}/${n}.so
#...
EOF
done
```
...and include from %files with -f. Or make that a spec local macro
> If there was some macro with package name, I think I could simplify this:
>
> %{gem_extdir_mri}
> %dir %{gem_instdir}
> %{gem_libdir}
> %{gem_spec -d}
If you declared these macros in terms including some %{name} then ... you'd
have X number of such identical %files sections, now just even
> Hmm, that's indeed strange. I tried to reproduce the same myself (using the
> steps you provided, thanks!) but could not - the test passed for me.
>
> Could you try doing this against a new, fresh build of RPM in another
> directory?
I did one better, I tried for a fresh Fedora 39 VM :D.
Noarch RPMs that contain EBPF binaries code incorrectly fail with "Arch
dependent binaries in noarch package"
EBPF is really noarch binary.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2875
You are receiving this because you are
When we talk about 1464368 I assume we mean
https://bugzilla.redhat.com/show_bug.cgi?id=1464368
@praiskup When you say "tooling" I expect that between us we need to decide
what we need and why we need it (to document the reason for the feature). Is
there a specific tool you wish you had? What
The above *almost* works. It's just that the ld.so.conf from Fedora causes an
"ldconfig: need absolute file name for configuration file when using -r" error
from ldconfig. Had me scratching hair for a bit because I thought it ws
complaining about the path I was passing in -f which *was*
If you have lots of those with nothing but the name changing, no macros will
help with that. Generate those files manifests programmatically from %install
and include with %files -f.
--
Reply to this email directly or view it on GitHub:
Note that I'm specifically avoiding talking about filtering these dependencies
out because I think in many cases its more useful to turn them into something
else instead.
--
Reply to this email directly or view it on GitHub:
rpmlint also considers ebpf as arch-dependent package.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2875#issuecomment-1909982487
You are receiving this because you are subscribed to this thread.
Message ID:
:monocle_face: seems most appropriate here...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910081323
You are receiving this because you are subscribed to this thread.
Message ID:
> ```
> rpm: --xml: unknown option
> ```
This is because `--xml` is a popt alias and you'd have to set
`RPM_POPTEXEC_PATH` to where the `rpmpopt*` file is installed, similarly to how
`atlocal.in` does it :smile:
--
Reply to this email directly or view it on GitHub:
I think my example was not clear enough. Lets concentrate on the later part:
~~~
%gem_extdir_mri psych}
%dir %{gem_instdir psych}
%{gem_libdir psych}
%{gem_spec -d psych}
~~~
If there was some macro with package name, I think I could simplify this:
~~~
%{gem_extdir_mri}
%dir %{gem_instdir}
If guessing and trying fails, 'runroot rpm -qp --xml
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm' is your friend, one can then diff
the output of that between working and non-working files. We should probably
dump that output anyway to make it more debuggable.
--
Reply to this email directly
> If you have lots of those with nothing but the name changing, no macros will
> help with that.
Since e.g. the `gem_libdir` is macro, it could instead of accepting the
parameter use some macro on background. So the question is can we have such
macro?
> Generate those files manifests
But maybe the `%files` section should be obsolete and replaced by file lists ...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2876#discussioncomment-8245318
You are receiving this because you are subscribed to this thread.
I remember a case or two where the checksums mismatch due to different libmagic
versions producing different strings. I also remember tweaking the test to
avoid relying on libmagic stuff there, but don't remember when exactly. But
yes, it's fragile. Very.
--
Reply to this email directly or
In `ruby` package, there are sections such as:
~~~
%files -n rubygem-psych
%{ruby_libdir}/psych
%{ruby_libdir}/psych.rb
%{ruby_libarchdir}/psych.so
%gem_extdir_mri psych}
%dir %{gem_instdir psych}
%{gem_libdir psych}
%{gem_spec -d psych}
~~~
And as it can be seen, the `psych` argument is there
Please see the last several files section of
[ruby.spec](https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby.spec#_1563-1649).
Granted, there is a lot of similarities between the `%files` sections, but
they are not the same.
On top of that, some of them are also similar to the dual
@pmatilai Just for clarity we are leaving out `DT_RPATH`, environmental
combination of `LD_LIBRARY_PATH` and the search paths (packages that alter
shell defaults and global search paths), `LD_PRELOAD` interposition (similar to
`LD_LIBRARY_PATH` but early loads the SONAME), and `DT_RUNPATH` and
> With the new ME_QUOTED support added end of last year we could make this work
> correctly. So the question is if we want `%-x**` or not.
Speaking of `ME_QUOTED`: On a somewhat related note, am I doing something wrong
or does `%{quote}` seem to not play nicely with `%{**}`?
```console
$ rpm
> 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
Yes, a clean way to discover the system library paths searched by the dynamic
loader would go a long way.
Hmm. I guess this is kinda doable by running `ldconfig -r ` followed
by `ldconfig -r -p` from which you can pull the directories (so
effectively the path) or the files themselves. Just do
32 matches
Mail list logo
