> Well, I stuck to the names that were in the code...
I know. My not-so-thoroughly thought up names from 10+ years ago, and a fine
example of why not to leave such half-assed pieces laying around in the
codebase :laughing:
> It also uses "--delete" while rpm itself uses "--erase". Not sure if
Heh, I didn't remember the workaround for 3.x, that's pretty funny. That
would've been added by a rather green me, probably in 2007 or so, thinking this
checking is a good thing. And then nobody thought to update the name when the
new payload format was added years later. It's annoying how much
@pmatilai commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld =
>this cannot be reflected in PAYLOADFORMAT as that would be a gratituous
>compatibility break
Ironically dropping the tag entirely would work fine, because of the backwards
compatibility backflips already in place to deal with v3 packages.
@dralley commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld =
> lockfileType - that distinguishes between rpms.in.yaml and rpms.lock.yaml)
I think this field is largely irrelevant since `rpms.in.yaml` is definitely
completely out of scope for this discussion (as this is just the basis for the
actual `rpms.lock.yaml`) as well as because it doesn't really
> If I did rpm -I vim-enhanced-10.0.038-1.fc38.x86_64.rpm, the command would
> fail, because the NVR does not match the lock file. If I did rpm -I foo, this
> wold also fail, because foo package is not listed in the lock file. But doing
> rpm -I vim-enhanced-9.1.031-1.fc38.x86_64.rpm would
@ffesti pushed 1 commit.
109d770953bb47582727bc33def7df064a92f080 Add --list and --delete to rpmkeys
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921/files/44709043703d3f0e0f3f0534e05a3fcb3df8ea93..109d770953bb47582727bc33def7df064a92f080
You are receiving this
Well, I stuck to the names that were in the code...
but it turns out the "keys" in in the name of the utility already and we don't
need to repeat that in the cli parameter. It also uses "--delete" while rpm
itself uses "--erase". Not sure if that is good because it is a slightly
different
Thinking more about it, the shared BUILDROOT use case might actually be
impossible to achieve because of the fact that RPM checks for unpackaged files
in there when building a single package (see the recent discussions around
excludes).
--
Reply to this email directly or view it on GitHub:
To summarize my above comments a bit, from a higher-level perspective:
In the context of the shared `%_topdir`, an RPM package doesn't necessarily
have to correspond to a single program or piece of software. It's a way to
distribute a "snapshot" or "sub-tree" of the root filesystem. In that
Which makes me think - couldn't the shared BUILDROOT be useful for actually
building container images? I'm not sure about the advantages over just grabbing
pre-built RPMs to compose the final root filesystem tree, but it does seem like
you'd save a number of redundant steps if you were building
@ffesti pushed 1 commit.
44709043703d3f0e0f3f0534e05a3fcb3df8ea93 Add --list and --delete to rpmkeys
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921/files/20e8342f76425d1085138973e2f4a7837c8dcb87..44709043703d3f0e0f3f0534e05a3fcb3df8ea93
You are receiving this
One thing to keep in mind here is that we'll be getting rid of a shared
BUILDROOT. I've always wondered what the purpose of that (or the shared
`%_topdir` workspace in general) was, but I can think of one use case:
You wish to deploy a common set of packages and/or configuration (a *suite*) to
I know that this option is not mentioned anywhere in documentation however IMO
it should be present to be able not only define from command line macro using
`--define foo` but as well undefine it if it is present in global or spec
macros.
So this is I've decided to raise this not as RFE but
Oh, RPMSIGTAG_FILESIGNATURELENGTH needs to be dropped because it's just broken.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8543365
You are receiving this because you are subscribed to this thread.
Since I was tagged in here and for some reason people think I don't care about
reproducibility, let me be clear, I do care about it. However, neither Fedora
nor openSUSE suffer from the problems Debian has that necessitated reproducible
builds, and the nature of the RPM format vs the Debian
Clamping the mtime to buildtime has its own negative consequence too, because
it makes it harder to reason reproducibility and it invalidates reproducibility
in practice because every build will be different due to a variable clamp
rather than an immutable clamp.
--
Reply to this email
One of the reasons for the knobs is that not all of these settings are fully
useful for "reproducibility" and some of these harm traceability and debugging.
For example, forcing the build host to `reproducible` does not provide much
value if you are able to do comparisons while
Closed #2811 as completed via 126b7ab7af60f79fe1912dec19c865f2ea74965a.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2811#event-11874943984
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2890 as completed via #2906.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2890#event-11874927944
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2906 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2906#event-11874927721
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I wont claim to have digested all that, but just a high level confirmation:
what I really would like to see is a coherent (re)design for reproducible
builds, where you basically just flick it on and be done with it, whereas the
existing flags reflect the organic growth process over the years
I think @pmatilai meant having %source_buildtime with constants of either
`SOURCE_DATE_EPOCH`, `SOURCE_DATE_EPOCH_MTIME`, `macro` or `clock`? I'm ok with
that.
My preferred way would be as few macros or settings, but that is not as
backwards compatible. Only reproducible builds. Build host
Closed #2833 as completed via b2638067fce9a32cba03f5c0198ea50a33ff6d3d.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2833#event-11874285931
You are receiving this because you are subscribed to this thread.
Message ID:
### Discussed in https://github.com/rpm-software-management/rpm/discussions/2872
Originally posted by **pmatilai** January 24, 2024
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
We have open-build-service (OBS) that uses obs-worker to call obs-build to call
rpmbuild.
The current way documented in [our
wiki](https://en.opensuse.org/openSUSE:Reproducible_Builds) is to add a
project-conf in OBS
```
Macros:
%source_date_epoch_from_changelog 1
> With our build system, passing constants into a build is much easier than
> passing in a variable %_buildtime.
Sorry but I have no idea this means. What are these "constants" and how are
they being passed to a build?
(a %_buildtime macro could be set either via rpmbuild command line --define
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
+ }
+ ARGV_t query = argvSplitString("gpg-pubkey", " ", ARGV_NONE);
It's a bit creative way to initialize an argv... I
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
I think it should (take optional arguments), actually. It could be useful for
eg checking whether a particular key is imported,
I think dropping this from the 4.20 milestone makes sense. This is a fair
amount of work, and I don't currently have the time or resources to do it well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1956125784
You
> %clamp_mtime_to_buildtime seems sensible to me, at least if it replaces
> %clamp_mtime_to_source_date_epoch. If you care about source_date_epoch, then
> you'll surely set buildtime to it, right?
With our build system, passing constants into a build is much easier than
passing in a variable
Hum, forgotten to close this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1240#issuecomment-1956106945
You are receiving this because you are subscribed to this thread.
Message ID: ___
Closed #1240 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1240#event-11872482217
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I don't see this happening in 4.20, dropping from the milestone.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1956097606
You are receiving this because you are subscribed to this thread.
Message ID:
@ffesti pushed 2 commits.
1fcfcb58c1025a36b8b44d13c688f3e70ae779fd Don't advertise rpm -qa gpg-pubkey*
in man page
20e8342f76425d1085138973e2f4a7837c8dcb87 Add --list-keys and --delete-key to
rpmkeys
--
View it on GitHub:
36 matches
Mail list logo
