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         | tzaf...@jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzaf...@cohens.org.il |                    |  best
tzaf...@debian.org    |                    | friend
_______________________________________________
git-buildpackage mailing list
git-buildpackage@lists.sigxcpu.org
http://lists.sigxcpu.org/mailman/listinfo/git-buildpackage

Reply via email to