Hi Benjamin, I wonder whether somebody could try to work out the issues mentioned by Benjamin in our policy. Even more urgently needed is a move away from Alioth. Debian Science team has found a solution on Salsa - I'd also check Debian Perl, Debian GIS and Debian Astro which I also expect to have found some non-Alioth solution.
It would be *really* appreciated if somebody would step in here. Thanks Andreas. On Sun, May 06, 2018 at 06:24:55PM +0300, Benjamin Redelings wrote: > > > 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 > > > > gbp-buildpackage > 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 > > #!/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. > This was extremely helpful! > > (BTW, if you are on vacation, I am not expecting a quick response!) > > Thanks, > -BenRI > > > 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