That mock does something is not a reason to not improve rpmbuild security and
package/packaging sanity enforcement. A test-suite modifying what gets packaged
is simply *horribly wrong*, even if it's by accident. If we can catch that,
then we should. That's a no-brainer to me.
--
Reply to this
Reopened #2004.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#event-12337884161
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing
This somehow slipped my radar. The "time" used in rpm is not supposed to be the
key creation time, but the last time the key was changed. I don't think you
should break this.
--
Reply to this email directly or view it on GitHub:
Merged #3012 instead
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2034120680
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Closed #2995.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#event-12338936477
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Doubly more embarrassing as you mentioned that in the ticket description
:laughing:
Will fix.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034411616
You are receiving this because you are subscribed to this
Maybe not the greatest example but at least something:
https://github.com/rpm-software-management/rpm/commit/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034434069
You are
@ffesti pushed 2 commits.
1e4e9648b114131b8a872878ef8c5cc5739efaf9 Re-Word User / Group handling a bit
81acc230b3b7c84b519e4bca4aee13bdbf9952b2 Add support for sysusers group
membership lines
--
View it on GitHub:
Thanks.
I noticed the `BuildOption(prep)` documentation was not updated in that PR.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034393793
You are receiving this because you are subscribed to this thread.
Message
...since the keyring changes done in 2008. I'm so out of touch with rpm...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034700620
You are receiving this because you are subscribed to this thread.
Message ID:
Oh, thanks for pointing that out! I didn't even remember we have that in the
documentation (although it was written by me, so ... age doesn't come alone as
they say around here)
--
Reply to this email directly or view it on GitHub:
OK, fixed the issue in the code and made sure the test cases actually checks
for group membership. Added a bit to the docs and the commit message.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2990#issuecomment-2034875120
You are
OTOH rpm only looks at the keyid to check if the key is already present since
some time...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034511695
You are receiving this because you are subscribed to this thread.
Closed #2557.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2557#event-12335587655
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Apologies for this not progressing anywhere, but the time in between has
confirmed that something like this will need a general purpose use-case in rpm
itself so that it can be regularly tested.
We'll be exploring this area in the future, but this isn't the time, we need to
focus on v6. I'm
Closed #2416.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416#event-12335589169
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Apologies for this not progressing anywhere, but the time in between has
confirmed that something like this will need a general purpose use-case in rpm
itself so that it can be regularly tested.
We'll be exploring this area in the future, but this isn't the time, we need to
focus on v6. I'm
And, once we do, revive https://github.com/rpm-software-management/rpm/pull/3011
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3014#issuecomment-2033713203
You are receiving this because you are subscribed to this thread.
Message ID:
After a bit of pondering, filed
https://github.com/rpm-software-management/rpm/issues/3014 instead, we'll
revisit the aliases with this is fixed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8995444
You
Closed #3011.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3011#event-12336023902
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Coming to the conclusion that it's just not worth the trouble right now. I'll
revive this once we've fixed the order (filed a ticket for that)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3011#issuecomment-2033714434
You are receiving
You really should use Sequoia for digesting. It makes no sense to use
openssl/libgcrypt in rpm and something else in sequoia. If it's not already
exposed, can you please add expose digesting functionality in Sequoia?
--
Reply to this email directly or view it on GitHub:
Sources and patches are stored in a singly linked list with front insertion in
the spec parser, and this implementation detail leaks into packages and rpmspec
queries: PATCH and SOURCE tags are in reverse order.
Technically changing the order *could* break somebody's carefully crafted
script
Closed #3007.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3007#event-12335494693
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
I thought I made it pretty damn clear in
https://github.com/rpm-software-management/rpm/pull/2378#issuecomment-1411912184:
this is not functionality that we want to see or maintain in rpm. Period.
Copy-on-write is an interesting technology in itself and we'll be exploring
that in the future,
The thought crossed my mind too, I'm a bit torn on this all.
Sure, reverting the order in the aliases would be safe. But, it seems like a
bug that we're storing them in reverse order in the package in the first place,
and something we should fix instead. But, that'd break it for the alleged
@pmatilai commented on this pull request.
> @@ -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 rpms
-#
@pmatilai commented on this pull request.
>
-/* Limit the maximum date to SOURCE_DATE_EPOCH if defined
- * similar to the tar --clamp-mtime option
- * https://reproducible-builds.org/specs/source-date-epoch/
- */
-if (srcdate &&
I.e. pgpDigParamsCreationTime() is somewhat misnamed, it does not the key
creation time.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2033982940
You are receiving this because you are subscribed to this thread.
It needs to get a new release when the key us updated, otherwise the rpm
--import will just do nothing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034037416
You are receiving this because you are subscribed to
I know the split is somewhat painful this way, but it was the least painful (or
only) way I could see to accomplish this within reasonable time/effort.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034208979
You are
Closed #2961.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2961#event-12336249093
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
After a few nights sleep - sorry but no. It'd be this strange macro you can
never use because something else might be relying on it. Just like you
shouldn't be overriding %_fixperms for your use because it breaks other things.
The idea of a pre/post action slots for macros and whatnot is not a
Merged #3002 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3002#event-12337492048
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2998 as completed via #3002.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#event-12337492251
You are receiving this because you are subscribed to this thread.
Message ID:
___
The sole reason for this exercise is to be able to build rpm *without*
rpm-sequoia.
rpm-sequoia doesn't support external digest, and wouldn't make much sense for
it to do so.
--
Reply to this email directly or view it on GitHub:
Ah, I missed that. Then please ignore me ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034198154
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2819 as completed via dc47a50c6345a25b861305d8aa8ae464098834ff.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2819#event-12338919876
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3012 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3012#event-12338919518
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Why wouldn't it make sense? Sequoia needs to do digesting anyway to verify the
signatures, it might as well expose the functionality. Securitywise it is bad
design if two implementations are used.
--
Reply to this email directly or view it on GitHub:
Oh and update (some of) the tests to use the new macros, optimally add a new
one for the clamp_to_buildtime behavior.
The above nits aside, I'm not going to say no to a reproducible builds patch
that appears to have consensus from everybody :sweat_smile:
--
Reply to this email directly or
Oh, I guess I wasn't clear: sure rpm-sequoia supports and exports all the
digest functionality rpm needs. What I mean is that it does NOT support using
libgcrypt/openssl from rpm side to do that.
libgcrypt/openssl digest support in rpm is only for the case where rpm-sequoia
is not available.
> we're running the entire test-suite as root.
I believe this is not true. I see no code in rpmbuild that would elevate UID to
root. Nor any consolehelper. Nor setuid bits.
--
Reply to this email directly or view it on GitHub:
As far as I know, the blocking issue here is simply a decision about where to
get the version of the library. Among others, options include:
1: the rpm version of the package that owns the library. Not a good solution
because I think the maintainers don't want elfdeps to access the RPM DB
What I mean is rpm's own test-suite:
https://github.com/rpm-software-management/rpm/blob/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d/tests/mktree.oci#L53
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2035694448
You are
> One possible disadvantage: you wouldn't be able to e.g. dnf downgrade xz*
I think it's important to differentiate the real binary dependencies from RPM's
knowledge of those dependencies.
In Fedora 40, it was safe to downgrade xz because libsystemd had been built
before xz 5.6. If it had
I opened https://github.com/rpm-software-management/rpm/issues/3015, which I
believe will be much easier to implement. And will gain the same benefit.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2035392608
You are
That's currently possible and can lead to various subtle runtime failures
instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035405478
You are receiving this because you are subscribed to this thread.
Message
One possible disadvantage: you wouldn't be able to e.g. `dnf downgrade xz*`
without also downgrading everything that was built against xz. (You might also
consider that an advantage, but most users probably wouldn't.)
--
Reply to this email directly or view it on GitHub:
@ffesti pushed 1 commit.
8558a2c2bf06c4b89a4ea59b50cedb80b00c6d87 Add support for sysusers group
membership lines
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2990/files/81acc230b3b7c84b519e4bca4aee13bdbf9952b2..8558a2c2bf06c4b89a4ea59b50cedb80b00c6d87
You are
We can `--short-circuit` to almost any phase. But we cannot short circuit
directly to `%check` phase.
This should be trivial to implement and would allow to implement isolation of
`%check` phase in Mock
https://github.com/rpm-software-management/mock/issues/1352
--
Reply to this email
@pmatilai commented on this pull request.
> @@ -25,6 +25,9 @@ user/group allocation altogether by using
## Dependencies
+Explict group membership (m) will create a dependency on both the user
+and the group name.
It's a bit weird to have this as the first thing in this section. I'd put it
52 matches
Mail list logo
