Hi,
Vagrant has helped me to setup building the packages and putting them into the repository, and he suggested one small change for out GIT-Packages:
debian/source/format should be set to "3.0 (native)" debian/changelog should have the version without the "-1" at the end.
aTc, could you please fix that for the packages you already pushed?
Thanks :)
On 2014-10-07, Michael Mrozek wrote:
Vagrant has helped me to setup building the packages and putting them into the repository, and he suggested one small change for out GIT-Packages:
debian/source/format should be set to "3.0 (native)" debian/changelog should have the version without the "-1" at the end.
Well, to be clear, I mostly suggested that as a quick and dirty hack to get to testing the apt repository setup and build environment configuration. I'd recommend actually doing proper versioning with a separate upstream tarball in the long-term...
live well, vagrant
On 10/08/2014 08:58 PM, Vagrant Cascadian wrote:
On 2014-10-07, Michael Mrozek wrote:
Vagrant has helped me to setup building the packages and putting them into the repository, and he suggested one small change for out GIT-Packages:
debian/source/format should be set to "3.0 (native)" debian/changelog should have the version without the "-1" at the end.
Well, to be clear, I mostly suggested that as a quick and dirty hack to get to testing the apt repository setup and build environment configuration. I'd recommend actually doing proper versioning with a separate upstream tarball in the long-term...
Almost had me worried there :) Native packages are something that should be avoided, especially for things that could potentialy go back to debian.
They're really meant for stuff that only exists in/for debian. It's fine for meta packages and config files that would be useless on other distros.
The way the packages are currently set up on the repo are more built around the git-buildpackage method I'm using, it might not be ideal for a raw sbuild. gbp takes care of generating all the needed files from the git repo before it's sent to be built.
Luckily its very easy to set up the complete system. I'll write that up in my next post, after I've done some more kernel fighting.
On 2014-10-08, aTc wrote:
The way the packages are currently set up on the repo are more built around the git-buildpackage method I'm using, it might not be ideal for a raw sbuild. gbp takes care of generating all the needed files from the git repo before it's sent to be built.
I suspect "gbp --git-builder='sbuild -d jessie-pyra -c jessie-armhf'" might work to use sbuild with bit-buildpackage, or something similar...
live well, vagrant
Okay, so should I change that in the script and test it?
It's just one command line to change?
On 8 October 2014 23:40:22 CEST, Vagrant Cascadian vagrant@debian.org wrote:
On 2014-10-08, aTc wrote:
The way the packages are currently set up on the repo are more built around the git-buildpackage method I'm using, it might not be ideal
for
a raw sbuild. gbp takes care of generating all the needed files from
the
git repo before it's sent to be built.
I suspect "gbp --git-builder='sbuild -d jessie-pyra -c jessie-armhf'" might work to use sbuild with bit-buildpackage, or something similar...
live well, vagrant
Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 2014-10-13, Michael Mrozek wrote:
On 8 October 2014 23:40:22 CEST, Vagrant Cascadian vagrant@debian.org wrote:
I suspect "gbp --git-builder='sbuild -d jessie-pyra -c jessie-armhf'" might work to use sbuild with bit-buildpackage, or something similar...
Okay, so should I change that in the script and test it?
It's just one command line to change?
You'll also need git-buildpackage installed. I just pieced that together From reading the git-builpackage manpages and having a rough idea how it and sbuild work, so experimentation will prove useful. :)
live well, vagrant
Am Mon, 13 Oct 2014 14:58:30 -0700 hat Vagrant Cascadian vagrant@debian.org geschrieben:
I installed git-buildpackage, but I don't have a gbp command.
Only:
gbp-clone gbp-create-remote-repo gbp-pq gbp-pull
Which package is that in?
On 2014-10-13, Michael Mrozek wrote:
On 8 October 2014 23:40:22 CEST, Vagrant Cascadian vagrant@debian.org wrote:
I suspect "gbp --git-builder='sbuild -d jessie-pyra -c jessie-armhf'" might work to use sbuild with bit-buildpackage, or something similar...
Okay, so should I change that in the script and test it?
It's just one command line to change?
You'll also need git-buildpackage installed. I just pieced that together From reading the git-builpackage manpages and having a rough idea how it and sbuild work, so experimentation will prove useful. :)
live well, vagrant
On 10/16/2014 09:03 PM, Michael Mrozek wrote:
Am Mon, 13 Oct 2014 14:58:30 -0700 hat Vagrant Cascadian vagrant@debian.org geschrieben:
I installed git-buildpackage, but I don't have a gbp command.
Only:
gbp-clone gbp-create-remote-repo gbp-pq gbp-pull
Which package is that in?
none, it doesn't exist in the version in debian stable yet.
I'll create a debian stable x64 chroot and see if i can get the stuff going in there.
Building on real arm hardware is so much easier :) (and git-buildpackage has better support for pbuilder/cowbuilder than sbuild to begin with)
On 10/16/2014 09:56 PM, aTc wrote:
I'll create a debian stable x64 chroot and see if i can get the stuff going in there.
getting cowbuilder going with it was quite easy, so here's the quick way to set that up:
download http://next.openpandora.org/base-testing-armhf.tar.xz
apt-get install ccache eatmydata qemu-user-static git-buildpackage
create ~/.gbp.conf with: [default]
[git-buildpackage] export-dir = ~/export builder = ARCH=armhf DIST=testing git-pbuilder -I -i -j2
(replace -j2 with the number of cores you want to use compiling. ARCH and DIST should probably be set somewhere else, but since we're not changing them that much this is fine for now)
and create a ~/.pbuilderrc with: COMPONENTS="main contrib non-free" export LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}/usr/lib/libeatmydata/libeatmydata.so" export CCACHE_DIR="/var/cache/pbuilder/ccache" export PATH="/usr/lib/ccache:${PATH}" BINDMOUNTS="${CCACHE_DIR}" EXTRAPACKAGES="ccache eatmydata"
cp ~/.pbuilderrc /root/ (because it runs sudo, it sometimes only reads the config file from the root user, this makes things slightly more bullet proof when updating, or when running cowpoke)
cd /var/cache/pbuilder/ tar Jxvf base-testing-armhf.tar.xz
and done :)
building a package :
gbp-clone git://git.openpandora.org/xserver-xorg-video-fbturbo.git cd xserver-xorg-video-fbturbo git-buildpackage
everything ends up in ~/export (defined in ~/.gbp.conf)
Building is already a slow process, and using qemu makes it even slower, even with cowbuilder,ccache and eatmydata.
building fbturbo: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz : real 5m55.992s user 5m41.207s sys 0m7.683s
omap5432: real 2m0.723s user 1m21.860s sys 0m14.210s