Yup, there's a RH bug on it too:
https://bugzilla.redhat.com/show_bug.cgi?id=1693212
I had a look or two on it last year, it'd be easy to fix if we let -i add
erasure elements but tricky otherwise. I kinda like the definition that an
install operation cannot erase anything, but then the
duplicate of #1190 caused by github incident.
--
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/1191#issuecomment-617316732___
Closed #1191.
--
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/1191#event-3257228317___
Rpm-maint mailing list
`rpm -i --replacepkgs` will not add an erasure element for an identical
installed package. This makes the dependency check see the installed package
and report an error even though the package will be removed later on.
I've stumbled over this in another bug report. I don't mind if it does not
`rpm -i --replacepkgs` will not add an erasure element for an identical
installed package. This makes the dependency check see the installed package
and report an error even though the package will be removed later on.
I've stumbled over this in another bug report. I don't mind if it does not
This is a regression caused by commit 75ec16e660e784d7897b37cac1a2b9b135825f25.
The provides added to the source rpms will be checked against the dependencies
of the installed packages. Because of this you will get an error if you try to
build an rpm where the package name matches a conflict of
Thanks for the feedback.
I also noticed `readFilesManifest()` as being one potential source of problems
here. Indeed, with a dirty patch that I'm currently testing out, I got a few
random crashes (possibly due to that).
However, in those cases where it worked, the build time of a kernel on
Merged #1163 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/1163#event-3255862156___
Rpm-maint mailing list
Thanks for the patches!
--
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/1163#issuecomment-617131507___
Rpm-maint mailing list
Based on a quick look, much of it does in fact appear thread-safe. There are
grues in the darker corners though :eyes:
One certain problem is the global macro space, readFilesManifest() does
push/pop on %license which is probably harmless, but further down the call
chain there's
Closed #1099.
--
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/1099#event-3255642011___
Rpm-maint mailing list
Okay I suppose its become clear this is not the way to go, closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'll rebase and clean it up :)
--
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/1163#issuecomment-617097701___
Rpm-maint mailing
Meh, GH's "fix conflicts" creates this strange merge commit that we don't want.
Thought I'd fix it as its kinda my fault the conflict exists, but this only
makes it worse... Care to do a rebase to clean it up? Thanks, and sorry about
the mess.
--
You are receiving this because you are
@pmatilai pushed 1 commit.
dcf93d92f2b324eb1faf40f8ff25949c2e59bad4 Merge branch 'master' into parametric
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai approved this pull request.
--
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/1163#pullrequestreview-397200156___
> I have tested it on my system, yes. With quite a few examples.
Ack, good.
> Just one things which I noticed when I was looking into this again... Any
> reason you did not use %{basename} for the redhat-rpm-config patch? I mean, I
> could use the same lua code here in one place.
Mostly just
> I assume you have manually tested all these to produce same results as
> before? The test-suite does not cover any of them.
I have tested it on my system, yes. With quite a few examples.
Just one things which I noticed when I was looking into this again... Any
reason you did not use
Having now looked at these a bit more carefully... while there's no particular
*need* to convert these (except maybe for debuginfo), I suppose these do serve
as fine examples of what you can do what you can do with parametric generators
(eg just how many silly grep's you can save etc :grinning:
@pmatilai requested changes on this pull request.
Please drop the second commit: it has nothing to do with rpmdeps options, the
description is inadequate and we really don't care about translation updates
via patches, they should go through the translation service (Zanata for the
time being).
Like noted above, this looks like glibc hasn't been properly stripped off
debuginfo which is then leaking elsewhere. Fix glibc packaging and it should go
away.
Looking for non-stripped debuginfo would make for a reasonable sanity check in
rpmbuild though.
--
You are receiving this because
Closed #1156.
--
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/1156#event-3255469834___
Rpm-maint mailing list
Closed #1045 via #1180.
--
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/1045#event-3255406673___
Rpm-maint mailing list
Merged #1180 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/1180#event-3255406654___
Rpm-maint mailing list
@pmatilai approved this pull request.
--
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/1180#pullrequestreview-397157468___
@dmnks pushed 1 commit.
7ab76d425d3660a3bfc83009f7cd77096bdb8881 fixup! build: prioritize large
packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Good point on the backwards loop; it really shouldn't scream "look ma, reverse
loop for no obvious reason, go figure out yourself!".
Instead, I'll just make the reverse ordering explicit by simply inverting the
`compareBinaries()` function, and push a fixup commit right away.
--
You are
Merged #1187 into rpm-4.14.x.
--
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/1187#event-3255002643___
Rpm-maint mailing list
@pmatilai approved this pull request.
--
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/1187#pullrequestreview-397077067___
@ffesti pushed 1 commit.
1f7f8e413fdabbc1e45d2127b4d56dce27dbaf9c Bump version to 4.14.3 final
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Good catch on the size tag, totally managed to miss that.
Looks fine by me, just one thing for consideration: since we want them largest
first, might as well sort them that way too so the second for-loop doesn't need
to walk backwards, which looks a bit more special than it actually is. Not that
31 matches
Mail list logo
