Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ configure.ac rpm/m...

2011-09-06 Thread Jeff Johnson
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

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ configure.ac rpm/m...

2011-09-06 Thread devzero2000
On Tue, Sep 6, 2011 at 4:43 PM, Jeff Johnson 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 that isn'

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ configure.ac rpm/m...

2011-09-06 Thread Jeff Johnson
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 AM,

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/macros/ ruby.in

2010-10-18 Thread Jeff Johnson
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" o

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ macros.in

2008-12-18 Thread Anders F Björklund
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 flip-

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ macros.in

2008-12-18 Thread Jeff Johnson
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 sectio

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ macros.in

2008-10-19 Thread Anders F Björklund
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

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c rpm/ macros.in

2008-10-19 Thread Jeff Johnson
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 c

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-22 Thread Michael Jennings
On Thursday, 21 June 2007, at 12:56:21 (-0500), Mark Hatle wrote: > Apply the patch isn't the problem. :) It's changing the sources and > generating new patches without the user ever having to go to the command > line thats the issue. (Unfortunately there are folks who haven't > figured out how

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-21 Thread Ralf S. Engelschall
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 remappin

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-21 Thread Jeff Johnson
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 encode

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-21 Thread Mark Hatle
Jeff Johnson wrote: > > 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 buttl

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-21 Thread Jeff Johnson
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 oth

Re: [CVS] RPM: rpm/ CHANGES rpm/build/ parsePrep.c

2007-06-21 Thread Mark Hatle
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 woul