Could you push all these changes back to the rpm-5_4 branch
too please? That's where the buildbot's are running, and
I am active.
Otherwise these changes are gonna reside on HEAD until
a ROADMAP or participation exists, and that isn't likely
soon.
Thanks!
73 de Jeff
On Sep 6, 2011, at 10:41
On Tue, Sep 6, 2011 at 4:43 PM, Jeff Johnson n3...@mac.com wrote:
Could you push all these changes back to the rpm-5_4 branch
too please? That's where the buildbot's are running, and
I am active.
Otherwise these changes are gonna reside on HEAD until
a ROADMAP or participation exists, and
On Sep 6, 2011, at 11:05 AM, devzero2000 wrote:
Done : lzip and lrzip support are in HEAD and in the 5_4 Branch. Tomorrow i
will
search if there are some my patch that live only in HEAD and i will merge in
5_4 as well.
Best Regards
BTW, the buildbot master is now running at
Instead of adding sparkly rubt gem's, you ought to teach
%setup to unpack from *.src.rpm's by adding a rpm2cpio layer and
recursing through the unpacked %prep in the *.spec.
The other approach is with rpm -q --yaml onto the *.src.rpm, one
would need to expand the %setup there. But --yaml works
It sure would be nice to have %patch as a macro rather
than flip-flopping and jiggering up Yet More Complicated
Silly Stuff, all forcing rpm rpm be recompiled.
I haven't a clue anymore (because of the number of flip-flops)
how patches are applied by rpmbuild.
Can the
#ifndef DYING
Jeff Johnson wrote:
It sure would be nice to have %patch as a macro rather
than flip-flopping and jiggering up Yet More Complicated
Silly Stuff, all forcing rpm rpm be recompiled.
The change was supposed to be to macros (and %patch)...
I haven't a clue anymore (because of the number of
Jeff Johnson wrote:
Fussing with --fuzz opens up a world of pain and voids the warranty
of %patch macros.
Right, so that's why I left the default as -1 (which translates to 2)
rather than changing the default to the stricter 0 as done elsewhere.
If you want pain, try
#%patchN
in spec
Fussing with --fuzz opens up a world of pain and voids the warranty of
%patch macros.
If you want pain, try
#%patchN
in spec files.
I'm unable to convince myself that burying New Fangled Secret Sauce
Switches internally
to the rpmbuild parser is in anyone's interest whatsoever.
There
This brings up something we've discussed here at Wind River. Would it
be possible to make %setup and/or %patch into macros (perhaps using
lua?) (I'm thinking for rpm5 - HEAD, not 4_5.)
The reason we're interested is that we have mechanisms that track
patches being applied (think quilt), and
On Jun 21, 2007, at 12:42 PM, Mark Hatle wrote:
This brings up something we've discussed here at Wind River. Would it
be possible to make %setup and/or %patch into macros (perhaps using
lua?) (I'm thinking for rpm5 - HEAD, not 4_5.)
Why ask for a buttload of legacy pain? Just use names
While there's nothing wrong withe your patch, there's simply
no reason not to just pass *all* patch options directly to
patch. That dumps a bunch of silly code from rpmbuild.
The reason for the parsePrep.c jiggery pokery is transparently remapping
ancient patch's CLI option change that was
On Thu, Jun 21, 2007, Jeff Johnson wrote:
While there's nothing wrong withe your patch, there's simply
no reason not to just pass *all* patch options directly to
patch. That dumps a bunch of silly code from rpmbuild.
The reason for the parsePrep.c jiggery pokery is transparently remapping
12 matches
Mail list logo
