Hey, sorry for the last-minute request but something I ran into just now:
please include 37b963fa51d6ad31086a6e345ce6701afda5afff (and why not the rest
of the rpm2archive fixes too).
This is actually in preparation for v6 where rpm2cpio as we know it no longer
works, so we need to start nudging
The local build probably needs to go eventually, but lets leave this alone for
now. We need to move to other challenges...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2748#issuecomment-1803250894
You are receiving this because you
Merged #2748 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2748#event-10909092084
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2679 as completed via #2756.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2679#event-10909088872
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2756 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2756#event-10909088643
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Forced pushed to move the backported GH actions commit to its proper
chronological place (as per the master branch).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2744#issuecomment-1802293518
You are receiving this because you are
Commit 11132fc21fb01ed63c621d852bc081a914d4f021 assumed that the value of 0 is
never used in practice and thus used it to indicate disabled,
however that assumption has turned out to be wrong because ostree uses
precisely that value as mtime in inodes, which in turn breaks existing
workflows
It does not @pmatilai, but many people are uncomfortable with situations where
reporting a bug via the proper channels (public GitHub issue) means publicizing
a 0day vulnerability in their own product. They would prefer if security
problems in their product caused by upstream bugs were
Splitting this from #2655 as this is a clearly separate thing that should be
doable without massive redesign of the whole thing:
- First argument should reflect the triggered package count
- Non-trans scriptlets have should get a second argument reflecting the
triggering package count
--
@pmatilai converted this issue into discussion #2754.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#event-10899590184
You are receiving this because you are subscribed to this thread.
Message ID:
> If you say so, but I find the notion of the host affecting something inside
> the Dockerfile (or vice versa) more than just a little mind-bending
I do find it ugly and hacky, too, don't get me wrong. It violates the very
principle of a Dockerfile being immutable. It's only done so that the
Closed #1210 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1210#event-10898744601
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is one of those items that have gotten solved by letting time pass.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1210#issuecomment-1801562962
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1298 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1298#event-10898734548
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The `%doc` directive really is just a convenience directive meant to abstract
away the details of "where do I put the doc files?". Cherry-picking them into
separate subpackages based on the resulting absolute paths using `%exclude`
seems to go against the very idea. At that point, you're better
@pmatilai converted this issue into discussion #2753.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1193#event-10898660507
You are receiving this because you are subscribed to this thread.
Message ID:
The reason I'm asking you to triage your own ticket :smile: is: did this
situation change with the recent test-suite oci image stuff?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2592#issuecomment-180150
You are receiving this
OK, "fixed" might be an overstatement, given that the original request was more
about the ability to extract the plain version from a string containing a tilde
(AIUI) than about adding primitives to be able to do that (which #2181 does).
In any case, something similar is being discussed here:
@ffesti pointed out that a fitting terminology for this would be file-level
obsoletes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1296#issuecomment-1801480657
You are receiving this because you are subscribed to this thread.
After some consideration, we'll consider this a request to enhance the Python
bindings API to allow selectively dealing with extension vs raw header data
like the C API can. Besides letting the tag die of old age, that's the only
concrete thing we can do without breaking some usecase or the
Closed #1120 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1120#event-10898285096
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Well, we already have `%pretrans` scriptlets which allow the packagers to do
arbitrary stuff. We don't need a second mechanism like that. Labeling the files
needing special treatment is a possible solution for the symlink problem but is
not something we need a separate ticket for. Closing
--
Have templates for at least Bug Report and RFE. Point to the Discussions in the
later.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2752
You are receiving this because you are subscribed to this thread.
Message ID:
23 matches
Mail list logo
