The %patch -P leak was fixed differently in commit
29d70efb1d9b2161f3fcdbdf71945d6c7308432d already, for the rest I submitted PR
#1041 to deal with them all in one go.
Sorry for the slow process and thanks for the patch!
--
You are receiving this because you are subscribed to this thread.
@pmatilai Ah, oops.
--
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/873#issuecomment-544452654___
Rpm-maint mailing list
Dropping opt_P doesn't mean dropping %patch -P. If you look at the code, you'll
notice that the opt_P variable is entirely unused, the values are obtained via
other means - opt_P couldn't supply multiple values of -P at any rate.
--
You are receiving this because you are subscribed to this
@pmatilai unfortunately `%patch -P` is pretty heavily used. I've seen several
examples of it in SUSE packages, not the least of which is the SUSE package for
`rpm` itself...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, I noticed that it still leaks on multiple uses, and there may be better
solutions these days. I chose to stop here for an entirely selfish reason -
using -b twice is clearly wrong to do, with only invoking it once, that leak is
chaff that shows up when I'm running valgrind to check my
The other alternative would be just dropping opt_P entirely.
It also still leaks if multiple -b, -z, -d etc are passed. Unlike -P it doesn't
make sense but it's not prevented either.
I remember seeing these kinds of leaks but shrugging them off as a popt issue
based on an ancient comment to
While debugging something else, I noticed that when I run rpmbuild,
valgrind says:
==189844==
==189844== HEAP SUMMARY:
==189844== in use at exit: 12,088 bytes in 45 blocks
==189844== total heap usage: 61,336 allocs, 61,291 frees, 28,975,297 bytes
allocated
==189844==
==189844== 24 bytes in
