[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: New bali-phy version



Hi Benjamin,

On Sat, May 05, 2018 at 02:56:56PM +0200, Benjamin Redelings wrote:
> > 
> >      uscan --verbose --force-download
> >      gbp import-orig --pristine-tar bali-phy_3.1+dfsg.orig.tar.xz
> > 
> > since the pristine-tar branch was not populated.  Either you forgot the
> > import-orig step or you did not pushed.
> 1. Hmm... yes I think I only pushed master.  My workflow notes now look like
> this:
> 
> % uscan --verbose --force-download
> % gbp import-orig --pristine-tar ../bali-phy_<version>+dfsg.orig.tar.xz
> % gbp dch
> <edit debian/changelog to get correct version>
> % git push origin --all
> % debuild -S
> % cd ..
> % sudo pdebuild --update
> % sudo pdebuild --build bali-phy_version.dsc
> 
> Does this look right?

This does not look wrong but it is not needed to force `git push --all`.
I only use

    gbp clone ...
    git push

which pushes branch master, upstream and pristine-tar.  Moreover, I'd
recommend to use

    gbp-buildpackage

instead of

    sudo pdebuild --build

in any case the sudo should not be needed here.  May be you re-read
Debian Med policy about how to use gbp.  Please also let us know if this
documentation is not really helpful - than we need to enhance it to make
it better.
 
> > FileNotFoundError: [Errno 2] No such file or directory: '/build/bali-phy-3.1+dfsg/tests/run-tests.py': '/build/bali-phy-3.1+dfsg/tests/run-tests.py'
> > FAILED: meson-test
> > /usr/bin/python3 -u /usr/bin/meson test --no-rebuild --print-errorlogs
> > ninja: build stopped: subcommand failed.
> > dh_auto_test: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1
> > make: *** [debian/rules:12: build] Error 1
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > ...
> > 
> > Can you please get a fresh clone and check the potential diff?
> 2. This is strange.  I can reproduce the error, but I don't understand it. 
> The file really should be there.  Also, this does not happen if I just use
> debuild instead of using pbuilder.
> 
> Um, pbuilder seems quite good at cleaning up after itself.  Is it possible
> to log in with the build directory untouch and figure out where the errors
> are coming from?  I haven't managed to figure this out yet...

You might like to check out pbuilder hooks[1].

I'm using the following:


 $ cat /var/cache/pbuilder/hooks/C99_failed_build 
#!/bin/bash
# https://lists.debian.org/debian-mentors/2015/02/msg00066.html

echo -n 'Installing convenience apps: '
for p in mc less bash-completion ; do
        apt-get install -y --force-yes --no-install-recommends $p &> /dev/null
        echo -n "$p "
done
echo

/bin/bash -i </dev/tty > /dev/tty 2> /dev/tty


I think you can find more examples in /usr/share/doc/pbuilder/examples.

Kind regards

        Andreas.


[1] https://wiki.ubuntu.com/PbuilderHowto#Running_a_Shell_When_Build_Fails_.28Intro_to_Hook_Scripts.29
    https://wiki.debian.org/PbuilderTricks 

-- 
http://fam-tille.de


Reply to: