This is useful to silence output in forked programs:
https://bugzilla.redhat.com/show_bug.cgi?id=1287918
Tested with the following scriptlet:
```
%post -p
pid = posix.fork()
if pid == 0 then
assert(posix.exec("/bin/sed"))
elseif pid > 0 then
posix.wait(pid)
end
pid = posix.fork()
if pid
Followup for d636ab1.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/62
-- Commit Summary --
* Fix option parsing in pythondistdeps
-- File Changes --
M scripts/pythondistdeps.py (2)
-- Patch Links --
Sure, an option for "default" syntax or something like that would be nice.
Those macros could then be adapted to use this syntax. I still think this is a
good temporary fix, since the expansion of those macros to empty is causing
quite a few hard-to-diagnose problems in rawhide.
--
You are
Almost nobody uses them, so the
"Relocations : (not relocatable)" line is a waste of screen estate.
Just output the line if there's something interesting to show.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/532
-- Commit
Various other tags (Bugurl, etc) are shown conditionally, so I don't see why
this should not be.
I'd love to see the same change for Group, but afaics, current syntax does not
allow conditional expansion based on value.
--
You are receiving this because you are subscribed to this thread.
In Fedora the removal of /usr/bin/python in favour of explicit
/usr/bin/python2 and /usr/bin/python3 is happening now. Unless
python-unversioned-command.rpm is installed, /usr/bin/python does not
exists. This means that packages use
%python_{sitelib,sitearch,version}, they get a warning in the
keszybz requested changes on this pull request.
> @@ -1,4 +1,4 @@
%__python_provides %{_rpmconfigdir}/pythondeps.sh --provides
%__python_requires %{_rpmconfigdir}/pythondeps.sh --requires
-%__python_path
keszybz commented on this pull request.
Nice!
> @@ -45,6 +45,20 @@ int rpmvercmp(const char * a, const char * b)
continue;
}
+ /*
+* Handle caret separator. Concept is same as tilde, except if one of
+* strings ends (base version), another considered
I think switching to a better build system is a worthwhile goal. Every switch
to meson that I have seen has worked out well and was definitely worth the
work. Apart from the speed and number-of-lines benefits that Igor listed, there
are less tangible but important benefits that come from a
An alternative approach: let's accept the fact that %_bindir=/usr/bin is here
to stay. Using a macro for "system binaries directory" is a legacy of old times
and we can just as well use the fixed path of "/usr/bin" for that everywhere.
(Using a macro for "where should I install my binaries",
> it is only some specific cases where this needs to be used.
Yeah, we used to pull in systemd much more often. Nowadays, most packages
should not pull in systemd, and install time ordering also doesn't matter. But
that's largely irrelevant here, since systemd was only used as an example here.
> But why? If a package contains a config is /usr/lib/sysusers.d/, why not to
> ensure that it is installed after systemd-sysusers binary is present and so
> the scriptlet which creates users can be executed?
Yes, in that case the dependency is warranted.
> If there is just a scriptlet which
FWIW, I think that deprecation+eventual removal is the way to go in this case.
If the macro was exposed, but not *actually used*, it'd be OK to quickly yank
it out. But clearly it is in use, and we know that the removal breaks packages
that are out there. I appreciate the desire to make a clean
> Would it make sense to change `%check` as the PR here does, and at the same
> time also add a `%check_buildroot` or something that's the equivalent of the
> current `%check` and runs after `%install`?
IMHO, no. Rpm is not just the handful of packages in Fedora dist-git. It's also
suse and
> Most packages execute their %check in the build directory, following the
> spirit of autotools "make check" target.
Quotation needed. Who uses autotools these days anyway?
Many many packages go to a big effort to test files from the %buildroot.
This change would significantly break
> it would be useful to clamp the ownership of the files to root:root--though
> this will necessitate ensuring that the applications which work with RPM
> input/output respect this clamping and change the permissions if a user
> extracts or installs it. (Namely, we don't want a user to install
Yeah, it seems that `%_buildhost` might be enough. I'm just starting to work on
this again, so I didn't have time to figure out the details.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1779525256
You are receiving
Please correct me if I got something wrong. My understanding is the following:
- rpmbuild will generate `Provides: user(foo) = ` and `Provides:
group(foo) = ` (??, see below) for packages which have sysusers.d files
- rpmbuild will generate `Requires: {user,group}(foo)` or `Recommends:
@keszybz commented on this pull request.
> +
+printf 'Installed-Build-Depends:\n' >> "$BUILDINFO"
+rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}\n' \
+| LC_ALL=C sort -t: -k2 \
+| sed -e 's/^(none)://; /\.(none)$/d; s/^/ /' >> "$BUILDINFO"
+
+printf
@keszybz commented on this pull request.
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY
> RIGHTS. IN
+# NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
+# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+# OTHERWISE,
@keszybz commented on this pull request.
> +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY
> RIGHTS. IN
+# NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
+# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+# OTHERWISE,
A different approach, which wouldn't require calling into `rpm` and dealing
with multiple rpms, would be to:
1. change the existing Provides generator for SONAME to use a version:
`libcurl.so.4()(64bit)` → `libcurl.so.4()(64bit) = 4.8.0`. I think this would
be backwards compatible: because the
@keszybz commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)\n"
Oh, one more caveat: if the shared library uses symbol versioning, exclude it
from the new generator.
This is important because of at least one important package: `glibc`. Without
this, every build would depend on the latest version of `glibc`. `glibc` spends
a lot of effort making sure that
What "config management tools" are that? Maybe they need to be warned that the
output will change and then the output in rpm adjusted after a while. Short gpg
ids are widely known to be a bad idea at least since 2011 [1]. Is the idea to
set every mistake that was ever made in stone?
[1]
Copied over from https://bugzilla.redhat.com/show_bug.cgi?id=2174373:
Description of problem:
(Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=2170878.)
Short gpg key ids are easy to spoof and generally should not be used [e.g. 1].
rpm prints them in various messages:
```
warning:
Well, anything which parses this output and makes use of it is broken. I
shouldn't be using short ids for *anything*, particularly not in a script. So I
think it's entirely reasonable to just change the output.
Also, I'm not sure if too many things would break. I'd expect that even sloppy
> Yup. Perhaps the bigger question is, should rpm _always_ use just the local
> passwd/group files?
Yes, nothing else is useful.
> I'm not sure if rpm needs to take into account nsswitch.
I don't think so. Firstly, it's not well defined what that would even mean. The
host's nsswitch is
@keszybz commented on this pull request.
> + if [ "-" = "$fn" ]; then
+ parse <&0
+ else
+ [ -r "$fn" ] || continue
+ parse <"$fn"
Indentation is strange, also in other places.
> +[ -e "$ROOT"/etc/passwd ] || touch "$ROOT"/etc/passwd
+[ -e
`rpm` embeds the build time and host into output headers. This is very useful
to figure out when and where the build was done. But when trying to trying to
reproduce an earlier rpm build, we want to override those to the value that was
used in the previous build.
Please add something like
Hi Simon,
To achieve build reproducibility, you must have the same versions of
dependencies. In particular, the compiler, linker, and compressors, python if
you write .pyc files, but also various helper programs that process
documentation files, etc. So generally the only feasible approach is
Please default to `C.UTF-8`, this is generally correct setting. An option can
be provided to override for the fringe cases that need it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2587#issuecomment-1665577795
You are receiving
Maybe I misunderstood what you mean by "reproducible". I meant exact
reproducibility in the sense of https://reproducible-builds.org/. If you just
want to "roughly recreate" a build, then what you say is applicable. I would
suggest retitling the issue to something like "Record macros defined
> I'm also aware that if you run `rpmbuild -bs .spec` there's no binary
> build process going on so I'd guess it's quite possible that macro
> definitions and installed package lists may not actually be useful. However,
> if you build source and binary packages together, which I'd assume is
> As far as BUILDHOST goes, rather than using a default value, it would be
> better to just disinclude the tag IMO.
That is certainly an option. But people consider both BUILDTIME and BUILDHOST
very useful for figuring out where/when/who exactly build a package. For
example, even in Fedora
Please reconsider.
The current behaviour is just not useful. The tooling that relies on this, if
any, should be adjusted. This part of behaviour is not useful, and in fact we
go to large efforts to work around it, for example by buiding srpms on all
architectures and checking that they are
Actually, srpm are *almost* arch-independent. I know of two issues: the ARCH
tag, and BuildRequires. But Fedora packaging guidelines actually forbid archful
BuildRequires
(https://docs.fedoraproject.org/en-US/packaging-guidelines/#_buildrequires_and_isa,
"SRPMs need to be architecture
> You can do many nasty things with %ifarch, e.g. not include some patch on an
> architecture. (But is is probably against the packaging guidelines of any
> distribution.)
Exactly. You *could* do this, but it doesn't make sense. Fedora packaging
guidelines strongly forbid this, and probably so
> One could imagine a "bare source rpm" format that basically only carries the
> name, version and release and the source file metadata in its header
OK, can we do this and then switch the Fedora ecosystem to this?
--
Reply to this email directly or view it on GitHub:
Beautiful!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2797#issuecomment-1840394162
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
> Save the packagers some typing
I generally agree with the rest of the discussion, but I want to reply to this
point in particular:
I very much disagree that those macros make things easier. Typing `/usr/bin` is
not any harder than typing `%{_bindir}`. The original form is shorter and also
When %autosetup -S git is used, a bunch of git commits are created. Without an
override, their metadata will include the current time. Many projects include
the git hash of HEAD in the build information, which means that the build
result is not reproducible. Since were creating a scratch repo
I read this proposal when the ticket was initially created, and I didn't find
it convincing, and now, a few weeks later, I still don't.
This is a very complex solution to a very specific problem. It is very narrowly
tailored to the specific details of the build system and package delivery
Another case which becomes reproducible with this patch: podman, and presumably
any go package. Go builds include `vcs.revision=…` `vcs.time=…` somewhere in
binary file metadata and with this patch (plus a few others to remove
intentional randomness), `podman-5.0.0~rc3-3.fc41.x86_64.rpm`
> I'd rather use rpm's buildtime here
buildtime is not clamped? We had a discussion about this in
https://github.com/rpm-software-management/rpm/issues/2603 and it was
explicitly rejected.
--
Reply to this email directly or view it on GitHub:
@keszybz commented on this pull request.
LGTM too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903483241
You are receiving this because you are subscribed to this thread.
Message ID:
I changed the patch to use $RPM_BUILD_TIME as fallback, as suggested by Neal.
But I think $SOURCE_DATE_EPOCH must remain the primary source for this. When it
is set, then we set various mtimes and other stuff to it, and it would be very
strange to use something different for the repo commits.
@keszybz pushed 1 commit.
1fac2eab0fd823817b52b53891f27d6cf2aacf43 Set git commit dates based on
$SOURCE_DATE_EPOCH or $RPM_BUILD_TIME
--
View it on GitHub:
@keszybz commented on this pull request.
> @@ -476,6 +476,25 @@ If the main section exists, it must come first to avoid
> ambiguity.
Otherwise, append and prepend can be used in any order and multiple
times, even if the corresponding main section does not exist.
+During the execution of
"Implementation detail". The important part is to get the payload and
significant metadata to be identical. Once we have that, we can do
optimizations to handle comparisons efficiently. One option is to strip fields
and hash that. Another option, for example, would be to define a hash method
If we could drop OPTFLAGS, that'd be great.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8623707
You are receiving this because you are subscribed to this thread.
Message ID:
I think the signature must give the real date of when the signature was
actually made. Setting a fake date would be very very icky, undermining the
trust in the signing process and the holders of the signing key used in such a
manner. At the more technical level, keys have a creation time, e.g.
> > A signed rpm build can never be "reproducible" according to their current
> > definition.
>
> Theoretically you could just ensure that the RPM signature uses the same
> `SOURCE_DATE_EPOCH` timestamp rather than the current time
I generally assume that the private key used for signing is
Yes, I think both are worthwhile. But they must be opt-in.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643884
You are receiving this because you are subscribed to this thread.
Message ID:
> @DemiMarie suggested a while back that if the non-signature aspects of the
> package are reproducible, then you can combine the signature of the original
> package with rebuilt package, and _that_ should be able to reproduce the
> package.
Yes, in principle you could. But it still wouldn't
> Oh, wouldn't we need these fixups for all the VCS backends, not just Git?
Theoretically, yes. In practice, nobody cares. I have never seen any of the
other macros used. Once we have a version that is acceptable, I'd be happy to
submit a follow-up that extends the same logic to other systems,
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2933#issuecomment-1967314022
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
> a coherent (re)design for reproducible builds, where you basically just flick
> it on and be done with it
I agree that the current set of options is a bit ad-hoc. But I think it's
completely unrealistic to achieve a single switch, because different build
systems and ways of managing the
I wrote a longer reply in
https://github.com/rpm-software-management/rpm/issues/2894… But even ignoring
the discussion there, I think SOURCE_DATE_EPOCH is **exactly** the field that
should be used here. That variable says when the sources were last modified, so
if we do a fake commit when
That spec was written by Debian maintainers and it's heavily slanted towards
some Debian concepts and needs some adaptation to the rpm world. In particular,
their definitions are incompatible with embedded signatures. A signed rpm build
can never be "reproducible" according to their current
> Wait, what? If those differ then the packages do differ, so its not actually
> bit-per-bit identical. Which is what _I've_ assumed reproducability to mean.
> This just goes to point out how completely different expectations people
> have. No wonder having a meaningful discussion about
Cool, thanks. We'll give this a go in Fedora as soon as it becomes available by
doing some rebuilds of official koji builds. I hope it works as expected, and
if not, we can always adjust.
--
Reply to this email directly or view it on GitHub:
I don't think that a custom "rpmhash" tool is the problem. We have to "trust"
the tools anyway… A tool that deletes signatures is as much an opaque binary as
the tool that calculates some hash.
I think it would a reasonable compromise to say that the hypothetical "rpmhash"
tool must give a
Yeah, I think that `SPEC` tag may actually be quite useful for rebuilds. There
are at least two problematic variables in the spec file: the full build paths,
e.g. `cd '/builddir/build/BUILD'`. But if the build is done in mock, the path
is always the same, so this doesn't cause a problem. A
Also fix some typos and add punctuation.
Follow-up for 44afd5b49c5375dee1892845c2ee873425728138.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2953
-- Commit Summary --
* docs: mention systemd-standalone-sysusers
--
Ah, OK, thanks for the clarification.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2654#discussioncomment-8721879
You are receiving this because you are subscribed to this thread.
Message ID:
Ideally, the NEVRA would indicate the vendor via the `%_dist` suffix. Fedora,
ELN, RHEL, SuSE mostly use unique suffixes. Of course this doesn't help when
derivates rebuild using the same suffix. But I think with this, we're getting
into the territory of SBOMs. Any reasonable SBOM should be
According to Wikipedia,
> The ZIP format has no notion of time zone, so timestamps are only meaningful
> if it is known what time zone they were created in.
rpm-uncompress uses the current (local) time zone, leading to irreproducibility
in builds.
```console
$ fedpkg clone xz-java && cd
@keszybz commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
> I don't think bumping the changelog for rebuilds is actually important, but I
> do think that this is still the wrong way to solve it, because we're
> presuming that _a rebuild is important_. When rebuilds happen every day for
> whatever reason due to dependency churn, they are no longer
I think proposal 2 is more extensible. With proposal 1 we assume that no policy
except clamping would be wanted, but people are clearly interested in other
approaches. So I'd go with 2., even if initially there are no plans to provide
non-clamping choices.
--
Reply to this email directly or
@keszybz commented on this pull request.
Looks nice.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built
An idea was floated on fedora-devel to remove tests from packages altogether. I
empathetically disagree with that, but maybe it'd be useful to "sandbox" the
tests a bit. The test code is often of lesser quality and less reviewed.
The basic idea is to make sure that the `%check` section
> For rolling distributions were no consistent snapshot is used for building
> there is the need for an archive of all previous builds and a tool that
> selects the correct versions from the archive as the buildinfo says.
How is this handled in Debian? I know that they report certain
I'm trying to add a scriptlet to filesystem.rpm, and rpm fails like this:
```console
$ sudo rpm --root=/var/tmp/inst3 --reinstall
x86_64/filesystem-3.18-8.fc41.x86_64.rpm
...
filetriggerin
table: 0x55b04c8b4590
will return
PANIC: unprotected error in call to Lua API (attempt to index a number
Thank you for the quick response. I can confirm that when `return 0` is
removed, things seems to work again.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3029#issuecomment-2047559681
You are receiving this because you are subscribed
Actually, this is probably not the right tracker for this bug.
The problematic definition is from
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_302,
so maybe it'd be better to file a bug against the package.
--
Reply to this email directly or view it on GitHub:
I have a package with the a few file triggers:
```console
$ rpm -q --filetriggers filesystem|grep -w using -A1
filetriggerin scriptlet (using ) -- /usr/bin
print('FILETRIGGERIN start')
--
filetriggerpostun scriptlet (using ) -- /usr/bin
print('FILETRIGGERPOSTUN /usr/bin start')
--
Hmm, maybe this only happens if `--reinstall` is used?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3048#issuecomment-2064164044
You are receiving this because you are subscribed to this thread.
Message ID:
> %install should run with a read-only build directory
I don't think this is going to work. E.g. autotoolz-based systems (something in
the autotools, automake, libconf stack) do final preparation steps in the
install target. I think this is inelegant, but not really "wrong". Old meson
versions
> Only with --short-circuit we "poison" the produced packages to prevent people
> from distributing them (accidentally or otherwise).
It is a misfeature. It means that the produced packages cannot be compared and
tested properly. In particular, `--short-circuit` is very often used to test
81 matches
Mail list logo
