Any volunteer to enhance Debian Med policy ... and move it away from alioth(!) (Was: New bali-phy version)
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
Reply to: