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

Re: Fwd: New bali-phy version

Hi Andreas,

On 05/05/2018 05:41 PM, Andreas Tille wrote:
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

% 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
This might depend on git config push.default .  I think if the value is "simple", then you need --all to push the pristine-tar and upstream branches.
which pushes branch master, upstream and pristine-tar.  Moreover, I'd
recommend to use

This is helpful.  Currently, this is not calling the hook scripts, so I used cowbuilder to run the hook scripts, and then gbp-buildpackage to build a full package.  I have modified /etc/pbuilder/buildd-config.sh to set HOOKDIR=/var/cache/pbuilder/hooks, and added a hookfile C10_something to /root/.pbuilder/hooks and /home/bredelings/.pbuilder/hooks and /var/cache/pbuilder/hooks but gbp-buildpackage is still not calling the hooks on failure.

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.
Hmm... I somehow have a hard time using the debian-med policy as a guide, whereas other documentation like the new maintainer's guide is easier to follow.

It feels like the debian-med policy is aimed at people who already understand debian packaging.  For example, it says "set the devscripts variables DEBEMAIL and DEBFULLNAME", but does not say that this means editting ~/.devscripts to set environment variables. 

The "git tips" section also feels like it is full of lots of pieces of information that I have a hard time connecting.  My apologies for being slow at this!

In general, I think learning how to package for Debian is a confusing process, because there are so many different documents one needs to read, and they all have a different style for managing packages.  As a result, I think being able to ask questions in person has been very helpful.

1. For the debian-med policy, would it be possible to generate the HTML version so that the section headings are numbered?  I think this would make the structure more clear.

2. The git tips section has many little tips, but perhaps it could be organized into (a) an overview of setting up and updating package repos and (b) an FAQ-type section.  I mostly need part (a).  This could maybe be chronologically organized into (a.1) setting up config files (a.2) creating a new local git repo, and (a.3) updating the repo for a new version.

3. There is a nice sequence of commands for "To create a new local git repository" (a.2).  Can we add a recommended sequence of commands for "Adding a new upstream release to the repo"? (a.3) Maybe it would look a little bit like this?

% uscan --verbose --force-download
% gbp import-orig --pristine-tar ../PKG_VERSION.orig.tar.xz
% gbp dch
<edit debian/control>
<maybe run git clean -x -d -i to delete files left behind from a build>
% gbp-buildpackage    // run pbuilder to build in a chroot
% git push --all
% git push --tags

I think it is very helpful to have a basic working set of commands like this.  People can then play around with these command, read the man pages, etc.  Right now the policy doesn't say anything about uscan, and that is a big time-saver.

However, it does seem like you have to set up a number of config files for gbp-buildpackage to actually work, and also probably run 'pbuilder --create --distribution sid' first, or something like that.

4. I suspect that some of this chould go upstream to the new maintainers guide.  The workflow there probably works fine.  But this stuff about using uscan and gbp is entirely missing from section 8.3 "New upstream release", which could more accurately be called "New upstream release (without git)". 

5. It might be worth mentioning the pbuilder hook for debugging build problems.  pbuilder has a large learning curve, and it wasn't immediately clear what the hooks were for.  So, it could have taken me a very long time to figure this out.

Anyway, I hope I am not causing trouble, and I hope these comments from a beginner are helpful.

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 
# 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 "

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

I think you can find more examples in /usr/share/doc/pbuilder/examples.
This was extremely helpful!

(BTW, if you are on vacation, I am not expecting a quick response!)


Kind regards


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

Reply to: