I was able to reproduce the problem with rpm-4.14.1 as well, so not a recent
regression.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The case of generating run-time dependencies from non-installed files is a
separate case that deserves a ticket of its own.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> @@ -1229,6 +1229,17 @@ static const struct rpmlibProvides_s rpmlibProvides[]
> = {
{ "rpmlib(FileDigests)", "4.6.0-1",
(RPMSENSE_EQUAL),
N_("file digest algorithm is per package configurable") },
+#ifdef
pmatilai requested changes on this pull request.
Please ask for at least a reservation for the GOST algorithms in OpenPGP RFC, I
don't see this being acceptable otherwise.
The other option would be detaching the digest algorithm enumeration used by
rpm for non-PGP purposes from the OpenPGP
All timestamps in rpm packages are 32bit and will roll over on 2038, and at
least some APIs are also affected. As Enterprise distro lifespans are 10+
years, this is something that needs to be addressed in the near future.
Within rpm this can be relatively easily done using a similar approach as
Hmm, actually the timestamps are uint32_t so they should be good until 2106,
but this does need a proper investigation, and ultimately, move to 64bit types.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Right, that should be fixed already in commit
7cb8ebdf92f7f3d42a12afb9720e142284e71810 (and the mess behind it)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #624.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/624#event-3065344766___
Rpm-maint mailing list
This should've been closed by commit ddbf30cf96a33319805b362b01d8a6fdfe7dea9c
but GH doesn't recognize the Resolves: tag used in the message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As a rule of thumb, %package can and is free to use everything that is in the
main preamble, that's always been the case and that's why there's no special
documentation about it. The "obvious" exception to the rule is Name: which is
handled via %package argument.
Buildrequires is no different,
Closed #1083.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1083#event-3064428501___
Rpm-maint mailing list
Doh, certainly didn't intend to close but just comment and then merge.
Been multiple such mistakes from me in the last week or so, wonder if some
button order or such on GH changed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Closed #1071.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1071#event-3064556636___
Rpm-maint mailing list
Reopened #1071.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1071#event-3064556851___
Rpm-maint mailing list
Okay so there was more than meets the eye... thankfully caught by the
test-suite.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As it's not entirely clear from the report: is this reported as a regression in
4.15.x or just a new finding that was simply reported on the version where
tested?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, I set it up at some point. IIRC you push to specific tag and it runs
build... Florian might still remember how to do it
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yep. Jeff had enabled it on the project using his account for about a year, I
think? I saw some of the reports during that time. He used Coverity with rpm5
and turned it on for rpm too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
What I meant by detaching is declare a separate RPMHASHALGO_FOO enumeration
that is free of PGP constraints and then adjust the entire codebase to use that
as appropriate, but that seems like quite a bit of busywork and churn.
Please try to get GOST included in OpenPGP officially, that's what
> We used to have coverity scans running on rpm
Did we? That would be news to me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
OTOH maybe I just need to adopt a merge first strategy to avoid embarrassing
accidental closures...
Anyway, thanks for the nice cleanups.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> RPM 5 did it: https://abf.io/soft/rpm5/blob/master/rpmio/rpmiotypes.h#lc-204
> Will the same approach be acceptable in rpm4?
Well, rpm5 compatibility is an explicit _non-goal_, so it's not likely to sway
anyone on this...
--
You are receiving this because you are subscribed to this thread.
Yup, like already noted in the above, "if we do this then we'd really want to
export options natively to Lua too".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1071 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1071#event-3064645142___
Rpm-maint mailing list
Merged #1081 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1081#event-3064699495___
Rpm-maint mailing list
pmatilai approved this pull request.
I thought I actually removed the ts as an argument to rpmalCreate() back
somewhen as part of overall efforts to minimize what has access to the full
transaction set, but seems that's not the case. Anyway, I can live with that,
it does of course simplify the
> The other option would be detaching the digest algorithm enumeration used by
> rpm for non-PGP purposes from the OpenPGP values
If to make values out of the range specified by the OpenPGP RFC (e.g. 250 and
251 or whatever else), they will still be called `PGPHASHALGO_*`, but may it
break
RPM 5 did it: https://abf.io/soft/rpm5/blob/master/rpmio/rpmiotypes.h#lc-204
Will the same approach be acceptable in rpm4?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oh and to clarify, what I mean by "getting into OpenPGP" is at least try to get
a reservation for the algorithm(s). There are any number of such reservations
in the RFC and one would think that it wouldn't require jumping through *too*
many hoops.
--
You are receiving this because you are
Pushed a saner implementation of the thing, but options not done yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Adding options as another table, accessed via option name as the key isn't hard.
BUT.
This uses global tables for local arguments, which means that such macros could
not nest, which seems like a bit of a showstopper...
--
You are receiving this because you are subscribed to this thread.
Reply
31 matches
Mail list logo
