@rphibel pushed 1 commit.
8a7cd8139b759d1711273839a6502333e3c0f914 Create content handler plugin hook
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416/files/5965d2be5b80eea738b767a5b48c5bff50c87da3..8a7cd8139b759d1711273839a6502333e3c0f914
You are receiving this
I referenced this effort in
https://marc.info/?l=linux-fsdevel=167794198604510=2 - my PoV is that the
rpm-cow effort makes some sense. I thought a lot though about hard requiring
reflinks for ostree though and determined it was not viable. There are too
many people that use e.g. ext4. And
@rphibel pushed 1 commit.
5965d2be5b80eea738b767a5b48c5bff50c87da3 Create content handler plugin hook
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416/files/82b6cfe2cfdc981cc7fcda4ecd473c8729aa6920..5965d2be5b80eea738b767a5b48c5bff50c87da3
You are receiving this
I ran in to a problem with some versions of clang building rpm where the value
of RPM_MASK_TYPE (0x) triggered an overflow error. Per the C standard,
the underlying type of the enum is implementation defined. It should be an int
unless the values of the enum cannot fit in an int or
probably not `tar`, but why not `pax`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5230414
You are receiving this because you are subscribed to this thread.
Message ID:
So reading through
https://github.com/rpm-software-management/rpm/commit/68c7cf80d7b763498d0077daa91f649bc209e7ae
the new format is 'stripped cpio' or did I completely misread that patch. [I
guess moving to pax or tar would be a bridge too far :scream_cat: ]
--
Reply to this email directly or
@socketpair commented on this pull request.
> @@ -273,8 +273,16 @@ static int runGPG(sigTarget sigt, const char *sigfile)
if (pipefd[1])
close(pipefd[1]);
-(void) waitpid(pid, , 0);
OK
--
Reply to this email directly or view it on GitHub:
@socketpair commented on this pull request.
> @@ -402,7 +402,19 @@ static int getOutputFrom(ARGV_t argv,
reap:
/* Collect status from prog */
-reaped = waitpid(child, , 0);
+
+do {
+ reaped = waitpid(child, , 0);
+} while (reaped == -1 && errno == EINTR);
+
+//
@socketpair pushed 1 commit.
8cb5c6a31a475067d41923b8306f8625dde4a71f Fix ignoring exit code of child
scripts in case of EINTR
--
View it on GitHub:
> What tooling/versions is giving this error? I don't doubt that Py_hash_t is
> the more proper type here, just that I've never seen the compiler complain
> about this.
clang16+
--
Reply to this email directly or view it on GitHub:
Ah, so to be clear the payload is still a CPIO archive, just with the metadata
stripped and stored in a within the RPM header?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5229948
You are receiving this
Maybe a bit too late of an addition, but since #2396 was merged today (thank
you!), I wondered if it could also make it into this release, with it being a
fix for a regression and all. It would really help us out, thank you!
--
Reply to this email directly or view it on GitHub:
Along with that unconventional issue, the user is probably left with an
unknown: _How to determine how or by who the Red Hat GPG/DSA key was imported?_
Could it be me that imported a such package?
```
$ rpm -qa --scripts gpg-pubkey* --qf '%{version}-%{release} %{packager}\n'
5323552a-6112bcdc
> GCC's __builtin_cpu_supports does unfortunately not support all features
> needed to detect these levels properly.
Looks like since GCC 12.2 it actually can do
`__builtin_cpu_supports("x86-64-v3")`:
@pmatilai Is it an option to use `fgetpwent()` and `fgetgrent()` to circumvent
glibc's caching? I'm not sure if rpm needs to take into account nsswitch. If it
doesn't, using those two functions could be an option.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -273,8 +273,16 @@ static int runGPG(sigTarget sigt, const char *sigfile)
if (pipefd[1])
close(pipefd[1]);
-(void) waitpid(pid, , 0);
rpmfc lives in a separate library (librpmbuild) which isn't available to
librpmsign, but I
Yep, the actual issue here (there *is* one) is that we're calling those keys
gpg-anything, when they should be openpgp-pubkey. But renaming would break a
lot of 3rd party tooling, and we'd really rather get rid of those entries in
the package db to begin with.
--
Reply to this email directly
Merged #2412 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2412#event-8685139800
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I'll just take your word on it :see_no_evil:
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2412#issuecomment-1458082079
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai commented on this pull request.
> @@ -402,7 +402,19 @@ static int getOutputFrom(ARGV_t argv,
reap:
/* Collect status from prog */
-reaped = waitpid(child, , 0);
+
+do {
+ reaped = waitpid(child, , 0);
+} while (reaped == -1 && errno == EINTR);
+
+// It's
Closed #2382 as completed via be950eabb84a88e5773e096435c37b92e3d47ebb.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2382#event-8685024651
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1326 as completed via #2396.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1326#event-8685024394
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2396 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2396#event-8685024179
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
What tooling/versions is giving this error? I don't doubt that Py_hash_t is the
more proper type here, just that I've never seen the compiler complain about
this.
--
Reply to this email directly or view it on GitHub:
Closed #2409.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2409#event-8684890900
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Thanks for the backport, but we generally only accept PR's on master branch,
backports are cherry-picked at the time of release-creation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2409#issuecomment-1458038219
You are receiving this
There are multiple differences between v3 and v4 packages on the "metadata"
level, but perhaps the single most important thing is v4 having immutable
header regions. Related to that, v4 has header-only digests and signatures
whereas v3 digests and signatures are always on header+payload.
The
### Description
This change creates a new `content_handler` plugin hook. This hook can be used
by plugins to claim responsability for the package payload. The plugin will
then be responsible for:
- reading the payload
- verifying it
- installing the files
The main motivation for this change is
@lnussel mentioned in
https://github.com/rpm-software-management/rpm/discussions/2277#discussioncomment-4145964
that openSUSE already generates user and group provides from systemd-sysusers
files. This should be upstreamed.
--
Reply to this email directly or view it on GitHub:
29 matches
Mail list logo
