Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]
+++ Ross Gammon [2014-03-01 23:37 +0100]: Now you have all helped me to realise that I can spam with 'debian/rules build' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to go all the way to a 'deb' which I can try installing. (And very usefully, just retry the packaging step without doing the whole build again (can save a lot of time)). But if I don't want to install all the build dependencies on the machine I am using, how can I pass these commands to pbuilder? Or can I override gbp buildpackage (with pbuilder as an option) in some way so that it ignores the fact that there are altered files? Just do the builds in a chroot. One of the coolest things about schroot is that by default your home dir is mounted inside the chroot so you get the exact same veiw inside and outside. So you issue the dpkg-buldpackage, or fakeroot debian/rules binary or whatever build commands inside the chroot. Thereby testing the build in a stable (fairly) clean environment, and not filling your main machine with build-deps. Meanwhile you do do other stuff on the codebase from outside the chroot using all your favourite tools too. Just avoid operations that are suite-specific. Hoping someone can solve a regular frustration of mine. The above is how I do it. Regards, Ross -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53126122.1060...@the-gammons.net Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302111636.gf18...@stoneboat.aleph1.co.uk
Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]
On Sun, 02 Mar 2014 08:38:06 +0100, Ross Gammon wrote: 'gbp buildpackage' fails because it detects altered files in the source code. Ah, here it is in the manpage: --git-export=treeish Thanks Gregor, but I was already aware of --git-export=WC --git-ignore-new. I have used this when I wanted to test changes to e.g. d/rules before committing the fix. Ok. What I was probably not clear about, was that I meant changes made outside the debian directory. Ah, indeed, I had not realized this; and I hadn't thought about this issue because ... dpkg-source: info: building gramps using existing ./gramps_4.0.3+dfsg.orig.tar.gz dpkg-source: info: local changes detected, the modified files are: gramps-4.0.3+dfsg/setup.py dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/gramps_4.0.3+dfsg-3.diff.8Ha2F5 dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -b gramps-4.0.3+dfsg gave error exit status 2 ... it's dpkg-source here failing, and not gbp :) (Well, indirectly and later gbp can't go on as well.) But anyway, studying this error a bit harder with a clear head in the morning, and then studying the man page for dpkg-source, I solved it. Adding the option -i.* to gbp successfully got passed to dpkg-source, and it built. I usually create a quick quilt patch (manually or by following the advive from the error: you can integrate the local changes with dpkg-source --commit) in this case. Or I just try the changes in the chroot (with running debian/rules $target manually there; cf. also Wookey's ideas). Works with cowbuilder as well with the C10shell hook (which can also be triggered by a exit 1 in debian/rules in the desired override_*). Note that this local changes detected error only happens with source format 3.0 quilt, and is generally considered an advantage (to avoid unintentional changes in the upstream code). But yes, during experimenting it can be a bit annoying. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Joan Baez: Ghetto signature.asc Description: Digital signature
Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]
On 03/01/2014 10:46 PM, Vincent Cheng wrote: On Sat, Mar 1, 2014 at 12:18 AM, Mikhail Morfikov mmorfi...@gmail.com wrote: Pbuilder also supports that using hooks, e.g.: # ln -s /usr/share/doc/pbuilder/examples/C10shell /var/cache/pbuilder/hooks/C10shell ...and the next time your build fails, pbuilder will dump you in the chroot with a shell. I checked this solution, but I'm wondering how to resume pbuilder after it dumps me in the chroot? Let's say I fixed everything that should be fixed, and what next? If you want to continue fixing issues as you go along, just keep spamming 'fakeroot debian/rules binary' in your shell (assuming your end goal is to produce binary .deb packages). You can of course try running other targets in d/rules to narrow down and solve specific issues that you want to fix. Regards, Vincent Thank you all, this has been a useful thread for me. But it hasn't yet given me the exact answer I needed (but some clues!). And maybe my question will also be useful to others. Many times I have used 'gbp pq import' to create a patch queue and try out some crazy patches to the source code there. I have used the options to tell gbp where the debian upstream branches are, but 'gbp buildpackage' fails because it detects altered files in the source code. I have tried several times to find solution in the man pages for gbp, pbuilder and dpkg-buildpackage etc. Now you have all helped me to realise that I can spam with 'debian/rules build' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to go all the way to a 'deb' which I can try installing. But if I don't want to install all the build dependencies on the machine I am using, how can I pass these commands to pbuilder? Or can I override gbp buildpackage (with pbuilder as an option) in some way so that it ignores the fact that there are altered files? Hoping someone can solve a regular frustration of mine. Regards, Ross -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53126122.1060...@the-gammons.net
Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]
On Sat, 01 Mar 2014 23:37:22 +0100, Ross Gammon wrote: 'gbp buildpackage' fails because it detects altered files in the source code. Or can I override gbp buildpackage (with pbuilder as an option) in some way so that it ignores the fact that there are altered files? Yes, you can: == excerpt from ~/.gbp.conf == [buildpackage] ... export = WC Ah, here it is in the manpage: --git-export=treeish Instead of exporting the current branch head, export the treeish object treeish. The special name INDEX exports the current index whereas the special name WC exports the current working copy as is. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Don McLean: The Carnival Is Ended signature.asc Description: Digital signature
Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]
On 03/02/2014 12:38 AM, gregor herrmann wrote: On Sat, 01 Mar 2014 23:37:22 +0100, Ross Gammon wrote: 'gbp buildpackage' fails because it detects altered files in the source code. Or can I override gbp buildpackage (with pbuilder as an option) in some way so that it ignores the fact that there are altered files? Yes, you can: == excerpt from ~/.gbp.conf == [buildpackage] ... export = WC Ah, here it is in the manpage: --git-export=treeish Instead of exporting the current branch head, export the treeish object treeish. The special name INDEX exports the current index whereas the special name WC exports the current working copy as is. Cheers, gregor Thanks Gregor, but I was already aware of --git-export=WC --git-ignore-new. I have used this when I wanted to test changes to e.g. d/rules before committing the fix. What I was probably not clear about, was that I meant changes made outside the debian directory. For example, make a simple change to a working package by adding #Ross is a berk to setup.py. gbp buildpackage with the pbuilder option and --git-export --git-ignore-new still fails: dpkg-source: info: building gramps using existing ./gramps_4.0.3+dfsg.orig.tar.gz dpkg-source: info: local changes detected, the modified files are: gramps-4.0.3+dfsg/setup.py dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/gramps_4.0.3+dfsg-3.diff.8Ha2F5 dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -b gramps-4.0.3+dfsg gave error exit status 2 gbp:error: Couldn't run 'git-pbuilder': git-pbuilder returned 2 But anyway, studying this error a bit harder with a clear head in the morning, and then studying the man page for dpkg-source, I solved it. Adding the option -i.* to gbp successfully got passed to dpkg-source, and it built. Cheers, Ross PS: now I had better remove that change before I forget ;-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5312dfde.3060...@the-gammons.net
