I think I initially wanted to add a sane API for these and then have rpmkeys
use that, and when that seemed painful I gave up. But the user wont care *how*
it's achieved if it works in a meaningful manner. And, for the user this is far
saner than 'rpmkeys --import -> rpm -q -> rpm --erase'.
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
Maybe delete this comment while at it? :smile: A fine example of why comments
are so bad - they don't get updated along with the
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
case MODE_DELKEY:
+ struct rpmInstallArguments_s * ia =
+ ARGV_t gpgargs = argvNew();
+ for (char * const * arg
Forward-looking defaults aside...
Do you agree with the idea that there should be a single macro to set the
buildtime source (clock/macro/source_date_epoch), and then have a separate flag
for clamping mtimes to buildtime, or am I again missing some finer detail here?
I've nothing against
This feels a bit too quick and dirty. Comments welcome.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#issuecomment-1956047845
You are receiving this because you are subscribed to this thread.
Message ID:
This is a bit of a hack as it manipulates the parsed cli parameters to
to the right thing and then calls rpmcliQuery and rpmErase.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2921
-- Commit Summary --
* Add
(and fwiw, pulling that path change into 4.19.x makes no difference whatsoever
because the translations should NOT be updated in the branches, and hence
there's no reason to do so)
--
Reply to this email directly or view it on GitHub:
So with the submodule update done, this can be closed. Sorry @dmnks for
stealing your ticket :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956028313
You are receiving this because you are subscribed
Closed #2899 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#event-11871913923
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Well yeah, *ideally* you'd have an official string freeze period with
translation notifications for major releases. And ideally you'd also have
per-release branches for translations because over time they grow different so
you can't safely pull updated translations to stable releases.
Why we
And here they are. I update the lockfile format with items `checksum` and
(file) `size`. There is also an expansion in the header (two new records:
`lockfileVendor` and `lockfileType` - that distinguishes between _rpms.in.yaml_
and _rpms.lock.yaml_).
--
Reply to this email directly or view it
> Oh, and just to clarify, in the case of 4.19.1.1, we did _not_ intend to
> update the translations in that release at all, which is why this issue
> wasn't caught yet.
Just FTR: updating translations should be be part of the (pre)release process.
Email addresses taken from each .po files
Because in rpm < 4.18, we have this silly check in there:
```
if (lead->major < 3 || lead->major > 4) {
*msg = xstrdup(_("unsupported RPM package version"));
return RPMRC_FAIL;
}
```
Putting 6 in the otherwise unused lead would render v6 packages unreadable by a
huge
Why can't 6 go there?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8530347
You are receiving this because you are subscribed to this thread.
Message ID:
___
Oh, and just to clarify, in the case of 4.19.1.1, we did *not* intend to update
the translations in that release at all, which is why this issue wasn't caught
yet.
--
Reply to this email directly or view it on GitHub:
This is already fixed in the rpm-l10n repo, in the commit
https://github.com/rpm-software-management/rpm-l10n/commit/b4dc72f4b92489f77de9b0ae0bed754875d37ece,
we just need to update the `po` submodule in the main repo to pull that change.
> IMO It would be hoof to add excutinh that target at
Figuring out what to do with this is one of the next things on my plate.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529580
You are receiving this because you are subscribed to this thread.
Message ID:
There's now also a draft PR that implements mosts of this draft, as far as
package generation goes:
https://github.com/rpm-software-management/rpm/pull/2920
--
Reply to this email directly or view it on GitHub:
> proper multiarch dependencies (instead of ()(64bit) markers)
As a reminder, I took a stab at this in #360 and later #1038. The big change
since then is the introduction of subarches for both ARM and x86_64, and I
still expect that to happen for RISC-V too. What are we thinking for this now?
@pmatilai pushed 2 commits.
30d352e1c188a68fdeb97fd1737d3eba891a19ee Don't populate os and arch in the
lead structure
01df85ccec5c00ebd46802a67fcc53f8274926a3 Bump the rpm version in the lead to 4
for v6 packages
--
View it on GitHub:
We didn't even do this with the Autotools build scripts, I don't think we
should make it so strict in the CMake build script either.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1954138148
You are receiving this
This should fairly closely reflect the latest v6 draft just published at
https://github.com/rpm-software-management/rpm/discussions/2919
The focus here is on the generation of v6 format packages, asserting various
aspects of the format is mostly a post 4.20 topic.
You can view, comment on, or
There's now what should be much closer to final (but isn't yet, certainly)
draft with clarified scope and compatibility info at
https://github.com/rpm-software-management/rpm/discussions/2919
Closing this topic as it has served its purpose and is getting too cluttered to
follow.
Thanks
Closed #2374 as resolved.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Based on the feedback on the [initial
draft](https://github.com/rpm-software-management/rpm/discussions/2374) and
work in the background, here's a major update to the v6 package format draft.
Starting a new topic as the original one is getting bogged down in details that
are no longer
I wonder if you would be open to backport the support for [spec local file
attributes and
generators](https://github.com/rpm-software-management/rpm/pull/2911) into
stable RPM. This would allow us to drop the rpm-local-generator-support package
from Fedora and migrate the current downstream
Fedora also used Mirror Manager, therefore the explicit URLs (in the original
example) are going against that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8528588
You are receiving this because you are
Coming back to this: to avoid gratuitious compatibility breakage, we can't put
either 0 or 6 in there.
The best we can do is put 4 in there because all of rpm 4.x used 3 as the major
version for alleged LSB compatibility, so it at least differentiates it a bit.
It's not such a terrible lie even
@pmatilai commented on this pull request.
> @@ -21,6 +21,11 @@
#define ALLOWED_CHARS_EVR ALLOWED_CHARS_VERREL "-:"
#define LEN_AND_STR(_tag) (sizeof(_tag)-1), (_tag)
+enum parseStages {
+SPECFILE,
+BUILDSYS,
+GENERATED,
Use some unique prefix on the enum names, makes it easier
@pmatilai commented on this pull request.
> + if (stage == GENERATED) {
+ switch (tag) {
+ case RPMTAG_SOURCE:
+ case RPMTAG_PATCH:
+ case RPMTAG_NOSOURCE:
+ case RPMTAG_NOPATCH:
+
Just a random observation: Fedora is being used as the example here, but Fedora
does NOT preserve the updates history in the repository, only the first (in the
base repo) and the last are kept. So any of this basically requires maintaining
a local mirror which never deletes packages. And with
Right, RPM does not have any concept of repos. As it mostly does not care about
URLs and generally does not care about where the RPM comes from. But let me
explain what I mean.
This lock file (based on your initial example, and sorry if I don't have the
YAML syntax right) in the simplest form
NVR does not uniquely identify a package. URL neither, but it's good enough if
you trust the server the URL points to. Full identification only guarantees a
checksum (and event that has theoretical collisions).
--
Reply to this email directly or view it on GitHub:
Just to keep this in sync what was discussed via a private channel, package
checksums (in some form) will need to be introduced to the format.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527603
You are
> maybe ignoring the full URL just focusing on NVR
@voxik There are use cases where you cannot rely on packages residing in a
repo, e.g. a single 3rd party package hosted on a page somewhere in which case
you need a URL to get it.
--
Reply to this email directly or view it on GitHub:
> Building a container for multiple architectures is single use-case, actually
> a use-case that will be more and more common because x86_64 arch domination
> is shifting (wide adoption of ARM, rise of RISC) so multi arch builds are
> must have and consistency between arches is desired. I don't
RPM checks dependencies, doesn't it? Then I don't see why RPM should not allow
only the dependencies as specified in some lock file, maybe ignoring the full
URL just focusing on NVR
--
Reply to this email directly or view it on GitHub:
37 matches
Mail list logo
