They have been used in some places we know (eg yum) and then there are all
those cases we don't know about.
It's not the message that needs changing, but the idiotic API that emits this
message. But to be able to deprecate that API we need something better first,
which is a long time coming.
Actually there is a way to have the cake and eat it too: once upon a time, rpm
called an external program (gpg back then) to verify signatures. It could do it
again. It would be slower and there would be other compromises to be made no
doubt, but between no security and slow security...
--
@dmnks , in reality these warnings are not the same because the filename
differs. The %patch case is similar: it *really* should print out the line
number + line, it was only made the way it is to allow us to squeeze it into
4.18.
We shouldn't get into a habit of producing bad warning
Absolute symlinks are downright dangerous in combination to chrooted content.
The absolute link okay inside the chroot of course, but have you never, ever
looked at eg /var/lib/mock/ stuff without chrooting into it?
The reason rpm complains about absolute symlinks is that they are problematic
@pmatilai Just noting this - this is an instance where existing versions of
`rpm` will yield a hard failure when reading RPMs built in this way
https://github.com/rpm-software-management/rpm/blob/4afe2d14d33db82ccb41c0a8d5eb1a4db90762fc/lib/rpmlead.c#L98-L105
```
[stderr] + rpm -vv --checksig
This is true even of the "major" file format version number? Of all the
fields, that one seems like it could *eventually* have some potential use?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2368#issuecomment-1461289916
You are
Hmm, this looks like a good candidate for a treatment similar to #2383, i.e.
suppressing these warnings into a single one with a count.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2419#issuecomment-1460429925
You are receiving this
Just for the context, I am working on project to remove bundled assets in
generated RDoc documentation:
https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/
This is going to replace the assets with symlinks and I think the absolute
symlinks is the right choice, because it allows
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2419
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
That's reasonable. Let me dig in to the clang error a bit more here and
restructure things. I will also track down the RPMTAG_NOT_FOUND issue too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2417#issuecomment-1460324651
You are
gpg-pubkey can only be imported through 'rpmkeys --import' or the API
counterpart, which is what eg dnf does. Package scriptlets can't generally do
this, it's blocked by the transaction lock.
And yes, there's potential for treating pubkeys as dependency for signed
packages (that use-case is
Merged #2398 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2398#event-8694448485
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Looks good to me, thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2398#issuecomment-1459797124
You are receiving this because you are subscribed to this thread.
Message ID:
In my original version this also added a %getmem macro with similar arguments.
Left it out to keep things simple and minimal, but would be trivial to add back
if people think that's useful.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
e4d0e62d129569a714ae190b2ffd2fcc1296834d Make build parallelism memory and
address-space aware (#804)
--
View it on GitHub:
Where are we getting RPMTAG_NOT_FOUND as the tag type? That seems like bug to
me, an unknown tag type should be 0, aka NULL type.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2417#issuecomment-1459758064
You are receiving this because
Please make a note of that in the commit message, just for future reference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2408#issuecomment-1459754648
You are receiving this because you are subscribed to this thread.
Message ID:
I would leave the enum itself alone, we have a lot of those around so changing
it all to defines is inconsistent. I wonder if clang ends up considering the
nested #defines to be part of the enum? That nesting is weird and ugly anyhow
and needs to be removed.
--
Reply to this email directly or
@pmatilai pushed 2 commits.
c859ebe35c54e58f689bc3d2097ff0acbe8172fa Make rpmio parallelism memory aware
3353d6a4234dd8e2ead28fc7cffdae9cc68e24b1 Make build parallelism memory and
address-space aware (#804)
--
View it on GitHub:
@pmatilai pushed 3 commits.
28b7237b30ad02ad2babee4d8abb13c96ae360fa Add optional total/proc/thread
arguments to %{getncpus} macro
b09677daadfa7025eb2ff89560c0a886e043302c Make rpmio parallelism memory aware
753763a1f971c0e041f934c442337a012eb7df5b Make build parallelism memory and
See commits for details, but short summary: add optional proc/thread argument
to %{getncpus} macro which consider the available memory and address space,
based on newly added tunables for tasksize.
The goal here is to avoid build failures due to gross overallocation on
constrained systems,
21 matches
Mail list logo
