On Mon, Nov 16, 2015 at 09:05:38AM +0100, Guido Günther wrote: > On Tue, Dec 30, 2014 at 11:16:37AM +0100, Tzafrir Cohen wrote: > > On Sun, Dec 28, 2014 at 02:27:51PM +0100, Tzafrir Cohen wrote: > > > On Sun, Dec 28, 2014 at 01:22:27PM +0100, Guido Günther wrote: > > > > > > > ====================================================================== > > > > ERROR: test suite for <class > > > > 'tests.component.rpm.test_pq_rpm.TestPqRpm'> > > > > > > Speaking of tests, I think that the following should also be included in > > > the branch (unless I missed it elsewhere): > > > > > > > > > http://git.tzafrir.org.il/cgit/git-buildpackage.git/commit/?id=b2d8fa3bdb750ddf974cb605de4e5f0c9b4281cb > > > > > > That repo also has a brute-force rebase of buildpackage-rpm on top of > > > 0.6.22 (just that command. Others are still missing). > > > > On top of that I now have an initial version of --git-mock - using mock > > as a chroot builder for rpm packages. I basically copied the way > > pbuilder is used (created a separate git-mock and used it as a builder). > > Mock is already installed by default with its own permission elavtion > > handler. > > > > http://git.tzafrir.org.il/cgit/git-buildpackage.git/commit/?h=buildpackage-rpm&id=03e38ad87c882d62ce9f54709fcf8c535edc36fa > > > > (I finally have clone URLs listed, but this is a single commit) > > > > Basic usage: > > > > gbp buildpackage-rpm --git-mock --git-dist=epel-6 > > > > Some notes: > > * It runs mock twice. Once for generating the srpm and once for > > generating the package from that. This is because some packages have > > platform-dependent macros that may be expanded at srpm-build time. > > > > Avoiding that and using rpmbuild directly would have been faster. > >
> > * I currently (for the sake of simplicity) avoid interpreting any > > define-s sent in the command line and just assume the spec will be in > > ./SPECS, sources in ./SOURCES, place the SRPM under ./SRPMS (I > > consider it temporary). > > > > * I don't have a good default for the resulting files. Currently I place > > the results under ./results/<dist>/<arch> > > > > What do you think? > > I've cleaned up the patch a little and applied it to current git. I > think assuming that the above directory layout is fine. > Thanks, > Avoiding a full build for the SRPM would be nice though, did you make > any progress on that one? I could do that (and this is what I did originally), but it means I have to provide correct defaults for various system-related defines. I suspect it should work in many cases but fail (or even fail silently, or produce incorrect results) in others. Maybe provide an option for both? Any opinions from other people? -- Tzafrir Cohen | [email protected] | VIM is http://tzafrir.org.il | | a Mutt's [email protected] | | best [email protected] | | friend _______________________________________________ git-buildpackage mailing list [email protected] http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage
