Here's a test image for ubuntu trusty. I decided to go with that, since debian testing has been moving in and out of a broken state for the last few weeks.
http://next.openpandora.org/ubuntu/pyra-ubuntu-trusty.tgz
It doesn't come with a full installer, it's basically just a rootfs that needs to be placed on an sd card with a working boot partition. (just rm *-rf/reformat an working sd card's rootfs partition, and extract the archive to it, as root)
You can edit /pyra-ubuntu-config.sh to set up a username/password/root password/hostname (defaults to root:root, and pyra:pyra for now)
On the first boot, it will run all the config scripts for the installed packages (takes quite a while, same as the pandora firmware. I recommend installing the rootfs on a usb or sata drive to speed things up), and set up some basics (which should be handled by a dedicated first-run-wizard later on).
You will see a few error messages, but they're not serious (it's mostly dpkg giving an error when a package has already been configured)
The only thing going wrong in this version is nfs-common not beeing configured properly (I just added that to the dependencies, I'll have to dig around for a fix)
A kernel/modules aren't included, so you'll have to add those to /lib/modules for whatever kernel you're booting (config script takes care of running depmod), although most kernels should run fine without modules installed (in fact, the one im using gives a lot more problems when I tries to load the alsa modules)
What I need now is a kernel + source with working sgx modules/libs/xorg config.
Lists of extra packages that should be installed, custom versions that need to be compiled, or config files that need changing to get all the hardware working are also welcome, so I can turn them into proper packages and add them to the list of dependencies.
Currently the image is built based on these meta packages:
Package: pyra-meta-base Depends: net-tools, nano, openssh-server, apt, apt-utils, dialog, kmod, sudo, wpasupplicant, wireless-tools, man-db, manpages, netbase, wget, usbutils, cpufrequtils, alsa-base, alsa-utils, less Description: Minimal requirements for the pyra firmware (meta-package)
Package: pyra-meta-desktop-base Depends: pyra-meta-base, xorg, desktop-base, fonts-liberation, xfonts-terminus Description: minimal requirements for a graphical pyra firmware (meta-package)
Package: pyra-meta-develop Depends: build-essential, u-boot-tools, kernel-package, libncurses5-dev, git-buildpackage, cowbuilder, pbuilder, ccache, eatmydata, dh-make, debhelper, multistrap Description: Dependencies for pyra firmware and application development (meta-package)
Package: pyra-meta-extra Depends: ntpdate, lm-sensors, htop, tmux, hdparm, rsync, nfs-common Description: useful, but not essential extra packages for pyra (meta-package)
Package: pyra-meta-xfce Depends: pyra-meta-desktop-base, xfce4, xfce4-goodies, network-manager-gnome, slim, firefox Description: XFCE desktop for pyra (meta-package)
pyra-meta-kde also exists, which just depends on pyra-meta-desktop-base and kde-standard, but that isn't used for this image (and is untested)
Any ideas for additional meta packages are welcome too of course.
Am 22.08.2014 um 00:15 schrieb aTc:
Here's a test image for ubuntu trusty. I decided to go with that, since debian testing has been moving in and out of a broken state for the last few weeks.
http://next.openpandora.org/ubuntu/pyra-ubuntu-trusty.tgz
It doesn't come with a full installer, it's basically just a rootfs that needs to be placed on an sd card with a working boot partition. (just rm *-rf/reformat an working sd card's rootfs partition, and extract the archive to it, as root)
You can edit /pyra-ubuntu-config.sh to set up a username/password/root password/hostname (defaults to root:root, and pyra:pyra for now)
On the first boot, it will run all the config scripts for the installed packages (takes quite a while, same as the pandora firmware. I recommend installing the rootfs on a usb or sata drive to speed things up), and set up some basics (which should be handled by a dedicated first-run-wizard later on).
You will see a few error messages, but they're not serious (it's mostly dpkg giving an error when a package has already been configured)
The only thing going wrong in this version is nfs-common not beeing configured properly (I just added that to the dependencies, I'll have to dig around for a fix)
A kernel/modules aren't included, so you'll have to add those to /lib/modules for whatever kernel you're booting (config script takes care of running depmod), although most kernels should run fine without modules installed (in fact, the one im using gives a lot more problems when I tries to load the alsa modules)
What I need now is a kernel + source with working sgx modules/libs/xorg config.
I am in the middle of making a 3.17-rc1 kernel work (device tree adaptations). But I can't tell if sgx will be supported.
Lists of extra packages that should be installed, custom versions that need to be compiled, or config files that need changing to get all the hardware working are also welcome, so I can turn them into proper packages and add them to the list of dependencies.
Maybe we should add (don't know exactly if they are already part of ubuntu base or to which meta they should belong to) because I sometimes use them:
i2c-tools, uboot-envtools, fbset, evtest, dosfstools, rfkill, iptables
Currently the image is built based on these meta packages:
Package: pyra-meta-base Depends: net-tools, nano, openssh-server, apt, apt-utils, dialog, kmod, sudo, wpasupplicant, wireless-tools, man-db, manpages, netbase, wget, usbutils, cpufrequtils, alsa-base, alsa-utils, less Description: Minimal requirements for the pyra firmware (meta-package)
Package: pyra-meta-desktop-base Depends: pyra-meta-base, xorg, desktop-base, fonts-liberation, xfonts-terminus Description: minimal requirements for a graphical pyra firmware (meta-package)
Package: pyra-meta-develop Depends: build-essential, u-boot-tools, kernel-package, libncurses5-dev, git-buildpackage, cowbuilder, pbuilder, ccache, eatmydata, dh-make, debhelper, multistrap Description: Dependencies for pyra firmware and application development (meta-package)
Package: pyra-meta-extra Depends: ntpdate, lm-sensors, htop, tmux, hdparm, rsync, nfs-common Description: useful, but not essential extra packages for pyra (meta-package)
Package: pyra-meta-xfce Depends: pyra-meta-desktop-base, xfce4, xfce4-goodies, network-manager-gnome, slim, firefox Description: XFCE desktop for pyra (meta-package)
pyra-meta-kde also exists, which just depends on pyra-meta-desktop-base and kde-standard, but that isn't used for this image (and is untested)
Any ideas for additional meta packages are welcome too of course.
BR, Nikolaus
On 08/22/2014 10:14 AM, Dr. H. Nikolaus Schaller wrote:
What I need now is a kernel + source with working sgx modules/libs/xorg config.
I am in the middle of making a 3.17-rc1 kernel work (device tree adaptations). But I can't tell if sgx will be supported.
Official support seems to end at 3.12, so it won't work without modifying the module source a bit.
Also, i'd be really interested in the demo image that was used at gamescom, having a known working base system makes things slightly easier.
Lists of extra packages that should be installed, custom versions that need to be compiled, or config files that need changing to get all the hardware working are also welcome, so I can turn them into proper packages and add them to the list of dependencies.
Maybe we should add (don't know exactly if they are already part of ubuntu base or to which meta they should belong to) because I sometimes use them:
i2c-tools, uboot-envtools, fbset, evtest, dosfstools, rfkill, iptables
I'll find a place for those, at this stage changing around some stuff doesn't affect thousands of installs anyway :)
Am Fri, 22 Aug 2014 16:58:35 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
first of all, thanks for your work :) I want to concentrate on getting the OS to work now.
The image we used is Debian Jessie (so testing) with some fixes, which is also still what we want to use for the OS.
It's nice that you got Ubuntu working, but our image (a simple Debian rootfs with some minor fixes and added packages) works fine.
notaz explained bootstrap to me again. Basically, it pulls the minimal Debian rootfs and then you chroot into it and install all the packages / run the scripts you need to run to make it fit for you. Did I understand correctly?
If that's it, then I'll use the Debian image I got on my devboard and only need to get automatic compilation for debian GIT packages to work as well as a setup to automatically create our image with predefined packages via debootstrap.
notaz will take care of some of the packages on our GIT server (xorg, SGX driver, etc.) and I want to create meta packages to define what should be installed on our rootfs.
aTc, can you give me step-by-step guides (or provide me with scripts) to set everything up like that on my devboard?
Thanks :)
On 08/22/2014 10:14 AM, Dr. H. Nikolaus Schaller wrote:
What I need now is a kernel + source with working sgx modules/libs/xorg config.
I am in the middle of making a 3.17-rc1 kernel work (device tree adaptations). But I can't tell if sgx will be supported.
Official support seems to end at 3.12, so it won't work without modifying the module source a bit.
Also, i'd be really interested in the demo image that was used at gamescom, having a known working base system makes things slightly easier.
Lists of extra packages that should be installed, custom versions that need to be compiled, or config files that need changing to get all the hardware working are also welcome, so I can turn them into proper packages and add them to the list of dependencies.
Maybe we should add (don't know exactly if they are already part of ubuntu base or to which meta they should belong to) because I sometimes use them:
i2c-tools, uboot-envtools, fbset, evtest, dosfstools, rfkill, iptables
I'll find a place for those, at this stage changing around some stuff doesn't affect thousands of installs anyway :) _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 2014-08-24 05:13:20 -0700, Michael Mrozek wrote:
The image we used is Debian Jessie (so testing) with some fixes, which is also still what we want to use for the OS.
I don't think I've spoken up much here before, but would love to offer help on integration work for the Pyra on Debian.
Simply using the OpenPandora during the Debian conference (which just started yesterday) has piqued curiosity in a handheld platform that's possible to run Debian, let alone one that might run Debian by default. There are surely other Debian developers who would be interested!
So, I keep meaning to take a look at the kernel tree; given that that's probably the biggest blocker. If it was at all feaible, a patchset that applied to linux 3.16.x would be good to target jessie, as that's the version that will ship with jessie.
I've privately maintained the OpenPandora patchset against wheezy's 3.2 linux source package and it's been relatively easy to keep in sync with security updates and such.
Not sure where to dive in exactly, but will get to it at some point.
live well, vagrant
On 08/24/2014 02:13 PM, Michael Mrozek wrote:
Am Fri, 22 Aug 2014 16:58:35 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
first of all, thanks for your work :) I want to concentrate on getting the OS to work now.
The image we used is Debian Jessie (so testing) with some fixes, which is also still what we want to use for the OS.
It's nice that you got Ubuntu working, but our image (a simple Debian rootfs with some minor fixes and added packages) works fine.
It works fine *now* .. the thing with testing is that you should be prepared for it to break at any moment, and that it can stay like that for a few weeks. I just got annoyed with testing breaking on me (mostly package dependencies dissapearing, so image building fails), so I went the slightly more stable ubuntu lts :) All the different debian and ubuntu flavours work pretty much the same when you're dealing with them on a package level. Moving from one to the other only requires some very minor changes.
notaz explained bootstrap to me again. Basically, it pulls the minimal Debian rootfs and then you chroot into it and install all the packages / run the scripts you need to run to make it fit for you. Did I understand correctly?
Yes, as with anything debian, there's about 50 different methods to get things done. And, as before, moving from one to the other is pretty trivial (if you follow the debian rules). I just went with multistrap because that doesn't need to run on native hardware to generate the rootfs. All the image building and configuring is done through packages that drag in dependencies, doesn't matter which program you use to install those.
If that's it, then I'll use the Debian image I got on my devboard and only need to get automatic compilation for debian GIT packages to work as well as a setup to automatically create our image with predefined packages via debootstrap.
notaz will take care of some of the packages on our GIT server (xorg, SGX driver, etc.) and I want to create meta packages to define what should be installed on our rootfs.
aTc, can you give me step-by-step guides (or provide me with scripts) to set everything up like that on my devboard?
I'll throw some stuff together later today.
Am Mon, 25 Aug 2014 04:16:37 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
The image we used is Debian Jessie (so testing) with some fixes, which is also still what we want to use for the OS. It's nice that you got Ubuntu working, but our image (a simple Debian rootfs with some minor fixes and added packages) works fine.
It works fine *now* .. the thing with testing is that you should be prepared for it to break at any moment, and that it can stay like that for a few weeks.
Well, I've been using testing on one of my desktop PCs for quite a while, and it never really broke for me.
The only real issue seems to be moving from sysinit to systemd, but that already happened.
I just got annoyed with testing breaking on me (mostly package dependencies dissapearing, so image building fails), so I went the slightly more stable ubuntu lts :)
These are exactly the issues I always had with Ubuntu, not with Debian ;)
I had multiple PCs that killed itself after an Ubuntu upgrade, even when running stable. But none with Debian so far. But that might've been bad luck.
I don't like Ubuntu and it doesn't seem to like me :D
All the different debian and ubuntu flavours work pretty much the same when you're dealing with them on a package level. Moving from one to the other only requires some very minor changes.
Okay. I'd like to try to setup everything with Debian testing. If it really turns out to be unstable within the next few months, we can still change to Ubuntu then.
Yes, as with anything debian, there's about 50 different methods to get things done. And, as before, moving from one to the other is pretty trivial (if you follow the debian rules). I just went with multistrap because that doesn't need to run on native hardware to generate the rootfs. All the image building and configuring is done through packages that drag in dependencies, doesn't matter which program you use to install those.
Okay, so basically...
1. We got git-package repos. The EVM will download and compile and upload it into the repo.
2. The build-server grabs a rootfs and includes our own compiled packages as well.
aTc, can you give me step-by-step guides (or provide me with scripts) to set everything up like that on my devboard?>
I'll throw some stuff together later today.
I've now setup the GIT environment + issues tracker. http://dev.pyra-handheld.com/
I've setup a GIT for the build-scripts as well. Could you send me your public key so I can give you git access? And then you can start pushing these scripts setup into the GIT, so I can use my server to build the rootfs.
Thanks!
On 08/31/2014 03:46 AM, Michael Mrozek wrote:
Okay. I'd like to try to setup everything with Debian testing. If it really turns out to be unstable within the next few months, we can still change to Ubuntu then.
Fine with me. Just be prepared for a lot of update/upgrading :)
Okay, so basically...
- We got git-package repos. The EVM will download and compile and
upload it into the repo.
- The build-server grabs a rootfs and includes our own compiled
packages as well.
aTc, can you give me step-by-step guides (or provide me with scripts) to set everything up like that on my devboard?>
I'll throw some stuff together later today.
ah, deadlines...
I've now setup the GIT environment + issues tracker. http://dev.pyra-handheld.com/
I've setup a GIT for the build-scripts as well. Could you send me your public key so I can give you git access? And then you can start pushing these scripts setup into the GIT, so I can use my server to build the rootfs.
key is attached.
Also, i could really use any info on patches/config files/packages that are needed, that way i can begin setting up the packages. Setting up that stuff does take a bit of effort, but once that's done it's really easy to see how things work, and to make changes.
It's probably best to set up a mail address that can be used inside the package as the author/maintainer, something like dev@pyra-handheld.com that ends up on the mailinglist (or just the mailinglist address if that accepts mail from non-subscribers). It's also needed for the package signing later on.
Am Sun, 31 Aug 2014 17:23:38 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
did you try to push your build-scripts yet? I can't see anything on the GIT.
I'd really like to get a working base OS build-system within the next 2 - 3 weeks.
Thanks.
Okay. I'd like to try to setup everything with Debian testing. If it really turns out to be unstable within the next few months, we can still change to Ubuntu then.
Fine with me. Just be prepared for a lot of update/upgrading :)
Okay, so basically...
- We got git-package repos. The EVM will download and compile and
upload it into the repo.
- The build-server grabs a rootfs and includes our own compiled
packages as well.
aTc, can you give me step-by-step guides (or provide me with scripts) to set everything up like that on my devboard?>
I'll throw some stuff together later today.
ah, deadlines...
I've now setup the GIT environment + issues tracker. http://dev.pyra-handheld.com/
I've setup a GIT for the build-scripts as well. Could you send me your public key so I can give you git access? And then you can start pushing these scripts setup into the GIT, so I can use my server to build the rootfs.
key is attached.
Also, i could really use any info on patches/config files/packages that are needed, that way i can begin setting up the packages. Setting up that stuff does take a bit of effort, but once that's done it's really easy to see how things work, and to make changes.
It's probably best to set up a mail address that can be used inside the package as the author/maintainer, something like dev@pyra-handheld.com that ends up on the mailinglist (or just the dev@mailinglist address if that accepts mail from non-subscribers). It's also needed for the package signing later on.
On 09/05/2014 03:10 PM, Michael Mrozek wrote:
Am Sun, 31 Aug 2014 17:23:38 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
did you try to push your build-scripts yet? I can't see anything on the GIT.
I'd really like to get a working base OS build-system within the next 2
- 3 weeks.
I just tried to push something to the git, and it failed, probably because i was pushing to git://git.openpandora.org/pyraos-build.git. So i created an account (aTc) and found out the git@git.openpandora.org:pyraos-build.git url.. and pushing to that failed too, probably because that account isn't linked to any repo yet, and it didn't have my pubkey either of course.
Anyway, i can't even check out stuff from that url now, might have been blocked after failing a few password.
So it would be nice if you could set up everything for that aTc account, including the creation of new repos, since i need a few more than what's currently there (like a place for the meta packages).
Hi,
We've got a basic rootfs building setup pushed to the git (thanks to aTc): http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/
The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM). Multistrap doesn't like relative paths though, so if you want to set it up on your server, be sure to use absolute paths.
What we need to do now is to automatically create debian packages for additional stuff we need.
aTc and me looked around a bit, and it seems the easiest methode to do that is to include the debian-directory in our sources and setup a script on the EVM that downloads, compiles and creates the package and then reuploads it to our own repository.
The files inside the debian-directory can mostly be created using the dh_make command (it's a one-time setup for each sourcecode).
Here is a working example of how to do it: http://xenomai.org/2014/06/building-debian-packages/ http://git.xenomai.org/xenomai-2.6.git/tree/?id=v2.6.3
The GIT has the normal sourcecode including a debian directory, whereas the first link explains how to automatically create a debian package from the GIT.
This is pretty similar to what we did with recipes for OE as well.
notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
Some more indepth-information about Debian packaging can be found here: https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en....
On 2014-09-07 10:14:42 -0500, Michael Mrozek wrote:
We've got a basic rootfs building setup pushed to the git (thanks to aTc): http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/
The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM).
You can also use qemu-debootstrap from the qemu-user-static package to bootstrap a chroot on a foreign architecture. It's essentially a simple wrapper around debootstrap that handles the --foreign and --second-stage parts transparently.
The files inside the debian-directory can mostly be created using the dh_make command (it's a one-time setup for each sourcecode).
Be sure to remove all the *.ex and *.EX cruft it creates, if it still does. Most of the files dh_make produces (or at least used to) isn't really needed for packages that have build systems that "do the right thing".
A minimal debian dir merely needs:
changelog compat control copyright rules
and if you're lucky, the rules file can be a two-liner:
#!/usr/bin/make -f
%: dh $@
Here is a working example of how to do it: http://xenomai.org/2014/06/building-debian-packages/ http://git.xenomai.org/xenomai-2.6.git/tree/?id=v2.6.3
The GIT has the normal sourcecode including a debian directory, whereas the first link explains how to automatically create a debian package from the GIT.
I do generally like the debian packaging integrated with upstream, though ideally in a separate branch. i.e. Merge new upstream into the debian packaging branch, but don't merge the debian packaging branch into upstream.
This is pretty similar to what we did with recipes for OE as well.
notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
I'd be happy to help create and review packaging, and put some time into getting whatever's relevent into Debian.
I filed a request for packaging bug for the fbturbo driver (which would be useful on arm in general):
https://bugs.debian.org/760025
And gave a quick run-through on what's needed for packaging.
live well, vagrant
Am Sun, 07 Sep 2014 11:04:39 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Hi,
http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/ The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM).
You can also use qemu-debootstrap from the qemu-user-static package to bootstrap a chroot on a foreign architecture. It's essentially a simple wrapper around debootstrap that handles the --foreign and --second-stage parts transparently.
Ah, thanks for the information. Is there any difference to multistrap, except for that it already preconfigures the packages?
The files inside the debian-directory can mostly be created using the dh_make command (it's a one-time setup for each sourcecode).
Be sure to remove all the *.ex and *.EX cruft it creates, if it still does. Most of the files dh_make produces (or at least used to) isn't really needed for packages that have build systems that "do the right thing".
Okay!
A minimal debian dir merely needs: changelog compat control copyright rules and if you're lucky, the rules file can be a two-liner: #!/usr/bin/make -f %: dh $@
Nice :) That's not that much then.
The GIT has the normal sourcecode including a debian directory, whereas the first link explains how to automatically create a debian package from the GIT.
I do generally like the debian packaging integrated with upstream, though ideally in a separate branch. i.e. Merge new upstream into the debian packaging branch, but don't merge the debian packaging branch into upstream.
That's a good idea, actually. It would also allow us to change the sourcecode, do some testings and then update the debian packaging branch when it's ready. (If I understood correctly ;))
This is pretty similar to what we did with recipes for OE as well. notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
I'd be happy to help create and review packaging, and put some time into getting whatever's relevent into Debian.
Sure, thanks :) If you send me your public key via mail, I'd give you GIT access so you could create what's needed for packaging here.
Also, if you know a way to use qemu to compile and create the packages from GIT (so we won't need to do it on an EVM but can do that directly on the server), it would be great if you could help me set it up :)
I filed a request for packaging bug for the fbturbo driver (which would be useful on arm in general):
https://bugs.debian.org/760025
And gave a quick run-through on what's needed for packaging.
True, thanks :)
Am 07.09.2014 um 19:14 schrieb Michael Mrozek:
Am Sun, 07 Sep 2014 11:04:39 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Hi,
http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/ The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM).
You can also use qemu-debootstrap from the qemu-user-static package to bootstrap a chroot on a foreign architecture. It's essentially a simple wrapper around debootstrap that handles the --foreign and --second-stage parts transparently.
Ah, thanks for the information. Is there any difference to multistrap, except for that it already preconfigures the packages?
The files inside the debian-directory can mostly be created using the dh_make command (it's a one-time setup for each sourcecode).
Be sure to remove all the *.ex and *.EX cruft it creates, if it still does. Most of the files dh_make produces (or at least used to) isn't really needed for packages that have build systems that "do the right thing".
Okay!
A minimal debian dir merely needs: changelog compat control copyright rules and if you're lucky, the rules file can be a two-liner: #!/usr/bin/make -f %: dh $@
Nice :) That's not that much then.
The GIT has the normal sourcecode including a debian directory, whereas the first link explains how to automatically create a debian package from the GIT.
I do generally like the debian packaging integrated with upstream, though ideally in a separate branch. i.e. Merge new upstream into the debian packaging branch, but don't merge the debian packaging branch into upstream.
That's a good idea, actually. It would also allow us to change the sourcecode, do some testings and then update the debian packaging branch when it's ready. (If I understood correctly ;))
This is pretty similar to what we did with recipes for OE as well. notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
I'd be happy to help create and review packaging, and put some time into getting whatever's relevent into Debian.
Sure, thanks :) If you send me your public key via mail, I'd give you GIT access so you could create what's needed for packaging here.
Also, if you know a way to use qemu to compile and create the packages from GIT (so we won't need to do it on an EVM but can do that directly on the server), it would be great if you could help me set it up :)
In my experience so far (maybe someone knows better) qemu also needs the right kernel that matches the user space. In our case an armhf capable kernel and some cortex-a9.
If it helps (at least for starting this work), here is a Debian Wheezy image incl. armhf kernel to simulate an "arm-cortex-a9 vexpress" by quemu:
http://download.goldelico.com/gta04/debian/qemu-wheezy-vexpress/
The "start.sh" script should simply download what is needed and run the machine. You can then access it through the console or (better because it does not abort on ctrl-C) ssh:
ssh -o StrictHostKeyChecking=no -p 22222 root@localhost
The image has a 30 GByte SD card to boot from which should be enough for most needs. You should be able to install it once and upgrade to whatever you need (and then make a snapshot of wheezy.img and/or rename it to be able to do a save restart).
What I have not yet managed is to easily share files between the guest and host except by scp.
I filed a request for packaging bug for the fbturbo driver (which would be useful on arm in general):
https://bugs.debian.org/760025
And gave a quick run-through on what's needed for packaging.
True, thanks :)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 2014-09-07 12:14:59 -0500, Michael Mrozek wrote:
Am Sun, 07 Sep 2014 11:04:39 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/ The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM).
You can also use qemu-debootstrap from the qemu-user-static package to bootstrap a chroot on a foreign architecture. It's essentially a simple wrapper around debootstrap that handles the --foreign and --second-stage parts transparently.
Ah, thanks for the information. Is there any difference to multistrap, except for that it already preconfigures the packages?
I find qemu-debootstrap easier to configure than multistrap, but it lacks multistrap's multiple repository support. For a fairly mature architecture like armhf, multiple repositories shouldn't really be necessary for bootstrapping a base image, and you can add multiple repositories and packages later with apt.
This is pretty similar to what we did with recipes for OE as well. notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
I'd be happy to help create and review packaging, and put some time into getting whatever's relevent into Debian.
Sure, thanks :)
If you send me your public key via mail, I'd give you GIT access so you could create what's needed for packaging here.
Will do.
Also, if you know a way to use qemu to compile and create the packages from GIT (so we won't need to do it on an EVM but can do that directly on the server), it would be great if you could help me set it up :)
Recent versions of schroot/sbuild support foreign builds using qemu-user-static, although qemu-user-static doesn't support some builds well (i.e. java) due to lacking system calls and maybe other mising/broken features (pthreads?). Works fine for quite a variety of packages, though... I use it all the time.
Using qemu-user-static is not particularly fast, of course, but faster than full system emulation with qemu.
live well, vagrant
On 09/08/2014 12:50 AM, Vagrant Cascadian wrote:
On 2014-09-07 12:14:59 -0500, Michael Mrozek wrote:
Am Sun, 07 Sep 2014 11:04:39 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
http://dev.pyra-handheld.com/index.php/p/pyraos-build/source/tree/master/ The debootstrap method is to be used on the EVM (it pre-configures the packages already) while the multistrap method can be used on any system (doesn't need to be ARM).
You can also use qemu-debootstrap from the qemu-user-static package to bootstrap a chroot on a foreign architecture. It's essentially a simple wrapper around debootstrap that handles the --foreign and --second-stage parts transparently.
Ah, thanks for the information. Is there any difference to multistrap, except for that it already preconfigures the packages?
I find qemu-debootstrap easier to configure than multistrap, but it lacks multistrap's multiple repository support. For a fairly mature architecture like armhf, multiple repositories shouldn't really be necessary for bootstrapping a base image, and you can add multiple repositories and packages later with apt.
Multistrap is a lot faster than debootstrap, (although its pretty close if you include the extra configure stage on the target hardware), but both methods have their advantages and disadvantages. Biggest disadvantage of both is that they don't cache the downloaded packages. Since all the work is done through (meta) packages, it doesn't really matter which method you use. (Although you do have to take care with deboostrap that you have to reconfigure some packages on the target again, like ssh)
This is pretty similar to what we did with recipes for OE as well. notaz, could you take a look at it and try to create a debian directory for the packages you wanted to provide?
I'd be happy to help create and review packaging, and put some time into getting whatever's relevent into Debian.
Sure, thanks :)
If you send me your public key via mail, I'd give you GIT access so you could create what's needed for packaging here.
Will do.
Most complex package will probably be the kernel. Especially getting it installed and set up to work from uboot. Have there been any plans yet for which uboot setup it's going to use ? And will uboot require a package to install/update as well ?
Im using a slightly more recent uboot on my board that can just load a zImage, instead of having to go through that uImage stuff, so that is also something to watch out for.
(ah, and about the kernel, a slight hint on which branch/tag/defconfig/dtb is actually the one to use would be nice)
We'll also need a place to put the packages, so any recomendations for repo software are welcome too. I was looking mostly at using reprepro. (although even the lazy method of just running dpkg-scanpackages in a dir of .debs works fine for the amount of packages we have now :)
Also, could you create a pyra-meta project on the git, so I have a place to push the "source" of those. (Unless anyone can think of a better name, the dependency packages are now called pyra-meta-base/desktop/xfce, etc. , there isn't really a naming standard for these type of packages)
Also, if you know a way to use qemu to compile and create the packages from GIT (so we won't need to do it on an EVM but can do that directly on the server), it would be great if you could help me set it up :)
Recent versions of schroot/sbuild support foreign builds using qemu-user-static, although qemu-user-static doesn't support some builds well (i.e. java) due to lacking system calls and maybe other mising/broken features (pthreads?). Works fine for quite a variety of packages, though... I use it all the time.
Using qemu-user-static is not particularly fast, of course, but faster than full system emulation with qemu.
I did try a qemubuilder setup a while ago, but didn't spend too much time on it because qemu would crash on a lot of configure scripts. Might have been that qemu was not configured properly for armhf though.
Building on the EVM was a lot faster anyway (especially with a sata hd and -j2 :)
Hi,
Am 08.09.2014 um 02:31 schrieb aTc:
(ah, and about the kernel, a slight hint on which branch/tag/defconfig/dtb is actually the one to use would be nice)
We have an older 3.8-something kernel that was used for the Gamescom demos.
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=shortlog;h...
branch: master (is the latest one) defconfig: omap2plus_defconfig dtb: omap5-pyra*.dtb (there are different .dtb files for different panels and a script that changes them)
From my view it should now be retired in favour of the GTA04-3.17++ kernel since that one much better tracks mainline (I just updated to 3.17-rc4) and the GTA04 team is already working on upstreaming it:
git: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=summary or http://git.goldelico.com/?p=gta04-kernel.git;a=summary branch: 3.17-rc4 (we currently have one branch per release) defconfig: gta04_defconfig dtb: omap5-pyra.dtb (different panels are not yet integrated)
There are also prepacked debs (by my kernel build script):
http://download.goldelico.com/gta04/unstable/quantumstep-linux-gta04-kernel_...
They install the uImage to /boot and the modules to /lib/modules
For the boot system I simply have taken some uboot and MLO binaries and crafted a boot.scr. This is pulled together onto the FAT partition of an SD card by a makesd script:
http://download.goldelico.com/gta04/unstable/pyra/
Things will become different if we install a system in eMMC.
What's the rationale behind this? The long-term target behind the "GTA04" work is to make it a Distribution for multiple devices, including the Pyra but not tied to it.
A distribution that allows to choose different user spaces, e.g. Replicant or QtMoko or QuantumSTEP but use an universal boot system and kernel.
ED has a different approach: make one system optimized for the Pyra (only). So sometimes these goals might be in conflict and lead to different solutions. We should take care of that not to duplicate too much work.
BR, Nikolaus
On 2014-09-07 19:31:58 -0500, aTc wrote:
On 09/08/2014 12:50 AM, Vagrant Cascadian wrote:
On 2014-09-07 12:14:59 -0500, Michael Mrozek wrote:
Am Sun, 07 Sep 2014 11:04:39 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Multistrap is a lot faster than debootstrap, (although its pretty close if you include the extra configure stage on the target hardware), but both methods have their advantages and disadvantages. Biggest disadvantage of both is that they don't cache the downloaded packages.
I would recommend using a caching proxy, such as squid-deb-proxy, approx, or apt-cacher-ng.
Since all the work is done through (meta) packages, it doesn't really matter which method you use. (Although you do have to take care with deboostrap that you have to reconfigure some packages on the target again, like ssh)
I wouldn't recommend installing ssh with either; seems like something to install with apt later in the process...
Most complex package will probably be the kernel. Especially getting it installed and set up to work from uboot. Have there been any plans yet for which uboot setup it's going to use ? And will uboot require a package to install/update as well ?
Im using a slightly more recent uboot on my board that can just load a zImage, instead of having to go through that uImage stuff, so that is also something to watch out for.
Yeah, all of the platforms I've dealt with recently in Debian's u-boot support zImage. I've also added support for a few boards to use Debian's (poorly named) flash-kernel to generate bootscripts for u-boot, which hooks into the kernel package postinst.
Haven't yet massaged the u-boot packaging into upgrading the installed u-boot, but it's in the back of my mind...
We'll also need a place to put the packages, so any recomendations for repo software are welcome too. I was looking mostly at using reprepro. (although even the lazy method of just running dpkg-scanpackages in a dir of .debs works fine for the amount of packages we have now :)
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Using qemu-user-static is not particularly fast, of course, but faster than full system emulation with qemu.
I did try a qemubuilder setup a while ago, but didn't spend too much time on it because qemu would crash on a lot of configure scripts. Might have been that qemu was not configured properly for armhf though.
qemubuilder uses full system emulation, and is a good deal harder to set up in my experience... but it's been a long time since I tried...
The workflow I use involves squid-deb-proxy for caching packages, qemu-debootstrap to create the working dir, and configuring schroot to use it:
export http_proxy=http://apt.lan:8000 qemu-debootstrap --variant=minbase sid /srv/schroot/sid-armhf
And a few configuration customizations:
==> /srv/schroot/sid-armhf/etc/apt/apt.conf.d/10norecommends <== // for clean build environments, recommends need to be explicitly // installed as build-depends APT::Install-Recommends "false";
==> /srv/schroot/sid-armhf/etc/apt/apt.conf.d/10notranslations <== Acquire::Languages "none" ;
==> /srv/schroot/sid-armhf/etc/apt/apt.conf.d/30proxy <== acquire::http::proxy::apt.lan DIRECT; acquire::http::proxy "http://apt.lan:8000";
==> /srv/schroot/sid-armhf/usr/sbin/policy-rc.d <== #!/bin/sh
echo "$0: not starting" exit 101
==> /etc/schroot/chroot.d/sid-armhf <== [sid-armhf] aliases=sid-armhf-ccache description=sid-armhf groups=sbuild,root root-groups=root,sbuild type=directory union-type=aufs directory=/srv/schroot/sid-armhf
Then, to build a package from the source dir:
sbuild -d UNRELEASED -c sid-armhf
or to build a debian source package:
sbuild -d UNRELEASED -c sid-armhf foo_1.2.3-4.dsc
Maybe that seems like a bit much, but (other than the qemu hooks), is pretty similar to Debian's buildd infrastructure.
Building on the EVM was a lot faster anyway (especially with a sata hd and -j2 :)
Depends on your build hardware... :)
live well, vagrant
Am Mon, 08 Sep 2014 09:44:45 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Hi,
Multistrap is a lot faster than debootstrap, (although its pretty close if you include the extra configure stage on the target hardware), but both methods have their advantages and disadvantages. Biggest disadvantage of both is that they don't cache the downloaded packages.
I would recommend using a caching proxy, such as squid-deb-proxy, approx, or apt-cacher-ng.
Is there a setup guide for that somewhere?
It sounds like debootstrap with qemu is the better way for us?
We'll also need a place to put the packages, so any recomendations for repo software are welcome too. I was looking mostly at using reprepro. (although even the lazy method of just running dpkg-scanpackages in a dir of .debs works fine for the amount of packages we have now :)
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Okay... I'll try to setup that within this week.
The workflow I use involves squid-deb-proxy for caching packages, qemu-debootstrap to create the working dir, and configuring schroot to use it:
Do you think you could set that up on our server? I could give you SSH user login.
On 2014-09-08 20:38:31 -0500, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 09:44:45 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Multistrap is a lot faster than debootstrap, (although its pretty close if you include the extra configure stage on the target hardware), but both methods have their advantages and disadvantages. Biggest disadvantage of both is that they don't cache the downloaded packages.
I would recommend using a caching proxy, such as squid-deb-proxy, approx, or apt-cacher-ng.
Is there a setup guide for that somewhere?
apt-get install squid-deb-proxy export http_proxy=http://127.0.0.1:8000
approx requires some configuration of /etc/approx/approx.conf to specify which mirrors it uses, and then pointing to approx as the mirror, typically running on port 9999.
Haven't tried apt-cacher-ng in many years, but I suspect it's similar.
It sounds like debootstrap with qemu is the better way for us?
Overall, debootstrap or multistrap doesn't matter a whole lot.
qemu-user-static works for many packages, but there may be some you may have troubles with; it really depends on the package set you end up wanting to use it with.
I am presuming the build environment is also a Debian install running a standard Debian kernel... ?
We'll also need a place to put the packages, so any recomendations for repo software are welcome too. I was looking mostly at using reprepro. (although even the lazy method of just running dpkg-scanpackages in a dir of .debs works fine for the amount of packages we have now :)
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Okay... I'll try to setup that within this week.
Manual install is fairly easy, getting automatic installs will take a bit more configuration.
The workflow I use involves squid-deb-proxy for caching packages, qemu-debootstrap to create the working dir, and configuring schroot to use it:
Do you think you could set that up on our server? I could give you SSH user login.
Sure. It would require installing a few packages, and running debootstrap as root. You may need to give certain users limited root-like privledges for sbuild to work.
live well, vagrant
Am Mon, 08 Sep 2014 23:20:14 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Sorry for the late reply, I was stuffed with other work, so I couldn't take care of that yet.
On 2014-09-08 20:38:31 -0500, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 09:44:45 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Multistrap is a lot faster than debootstrap, (although its pretty close if you include the extra configure stage on the target hardware), but both methods have their advantages and disadvantages. Biggest disadvantage of both is that they don't cache the downloaded packages.
I would recommend using a caching proxy, such as squid-deb-proxy, approx, or apt-cacher-ng.
Is there a setup guide for that somewhere?
apt-get install squid-deb-proxy export http_proxy=http://127.0.0.1:8000
approx requires some configuration of /etc/approx/approx.conf to specify which mirrors it uses, and then pointing to approx as the mirror, typically running on port 9999.
Haven't tried apt-cacher-ng in many years, but I suspect it's similar.
Okay, which of the two do you suggest?
The server I'll run that with will be our normal webserver. So it runs apache with tons of virtual domains already.
Is that an issue with that proxy setup?
It sounds like debootstrap with qemu is the better way for us?
Overall, debootstrap or multistrap doesn't matter a whole lot. qemu-user-static works for many packages, but there may be some you may have troubles with; it really depends on the package set you end up wanting to use it with. I am presuming the build environment is also a Debian install running a standard Debian kernel... ?
Yes, the server runs a standard Debian: Linux kronos.dragonbox.de 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux
So, should I use debootstrap with qemu or qemu-user-static?
Is there a step-by-step guide for setting either up?
We'll also need a place to put the packages, so any recomendations for repo software are welcome too. I was looking mostly at using reprepro. (although even the lazy method of just running dpkg-scanpackages in a dir of .debs works fine for the amount of packages we have now :)
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Okay... I'll try to setup that within this week.
Manual install is fairly easy, getting automatic installs will take a bit more configuration.
Do you have a good guide for reprepro as well?
The workflow I use involves squid-deb-proxy for caching packages, qemu-debootstrap to create the working dir, and configuring schroot to use it:
Do you think you could set that up on our server? I could give you SSH user login.
Sure. It would require installing a few packages, and running debootstrap as root. You may need to give certain users limited root-like privledges for sbuild to work.
Could we meet in IRC sometime so we can set that up together? Or any other messenger?
Thanks :)
Well, this turned into a long email with detailed configuration... probably should write this up somewhere. :)
On 2014-09-29 07:18:22 -0700, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 23:20:14 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
On 2014-09-08 20:38:31 -0500, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 09:44:45 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Okay, which of the two do you suggest?
I'd recommend squid-deb-proxy, as it's easiest to configure, though you'll need to enable wheezy-backports in sources.list:
deb http://http.debian.net/debian/ wheezy-backports main
And then install it:
apt-get update apt-get install squid-deb-proxy # maybe you'll need to add --target-release wheezy-backports
You may want to adjust the size and/or location of the cache in /etc/squid-deb-proxy/squid-deb-proxy.conf:
cache_dir aufs /srv/squid-deb-proxy 5000 16 256
The server I'll run that with will be our normal webserver. So it runs apache with tons of virtual domains already.
Is that an issue with that proxy setup?
Should be fine, squid-deb-proxy runs on port 8000 by default, though it's configurable. So any firewalling will need to allow port 8000 at least to/from localhost.
So, should I use debootstrap with qemu or qemu-user-static?
Is there a step-by-step guide for setting either up?
Those don't require configuration, simply installing them should work:
apt-get install debootstrap qemu-user-static
If that doesn't pull in binfmt-support, you'll also need to install that.
Then, you can create a cross-architecture chroot with:
export http_proxy=http://127.0.0.1:8000 # use squid-deb-proxy qemu-debootstrap --arch=armhf jessie /srv/schroot/jessie-armhf http://ftp.de.debian.org/debian chroot /srv/schroot/jessie-armhf dpkg --print-architecture
For the build configuration:
apt-get install sbuild schroot
create a configuration for...
/etc/schroot/chroot.d/jessie-armhf:
[jessie-armhf] aliases=jessie description=jessie-armhf groups=sbuild,root root-groups=root,sbuild type=directory union-type=aufs directory=/srv/schroot/jessie-armhf
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/10norecommends:
APT::Install-Recommends "false";
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/10notranslations:
Acquire::Languages "none" ;
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/30proxy:
acquire::http::proxy::127.0.0.1 DIRECT; acquire::http::proxy "http://127.0.0.1:8000";
/srv/schroot/jessie-armhf/usr/sbin/policy-rc.d:
#!/bin/sh # mark as executable # don't run any startup services in the chroot
echo "$0: not starting" exit 101
Now you should be able to add a user to group sbuild (note, this effectively gives root access to the system) and run sbuild/schroot:
sbuild -c jessie -d jessie-pyra foo_1.2.3-1.dsc
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Okay... I'll try to setup that within this week.
Manual install is fairly easy, getting automatic installs will take a bit more configuration.
Do you have a good guide for reprepro as well?
Create a repository dir (example using ~/public_html/debian for the repository):
mkdir -p ~/public_html/debian/conf
Drop the following in ~/public_html/debian/conf/distributions:
Codename: jessie-pyra Architectures: i386 amd64 armhf source Components: main udebComponents: main Description: Packages for DragonBox Pyra #signwith: KEYID Tracking: all
Then start adding packages:
reprepro --verbose --basedir ~/public_html/debian include jessie-pyra foo_1.2.3-1_armhf.changes
You can also add individual .deb or .dsc files for quick testing, though I'd recommend sticking with the full .changes files in the long-term:
reprepro --verbose --basedir ~/public_html/debian includedeb jessie-pyra foo_1.2.3-1_armhf.deb reprepro --verbose --basedir ~/public_html/debian includedsc jessie-pyra foo_1.2.3-1.dsc
That's the basics for a personal unsigned repository. Signing will require generating a GPG key (preferrably with subkeys, so you store the primary key somewhere secure). For setting up an upload queue with an incoming dir, it requires a bit more. The reprepro manpage has some information about that, and I'd be happy to help further with that.
I'm sure there's something I've forgotten... but at least that's a start. :)
live well, vagrant
Am Thu, 02 Oct 2014 08:04:27 -0700 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Hi,
okay, I set that all up and it seems to work so far. As repo directory, I've chosen packages.pyra-handheld.com
So that brings me to the follow-up question:
How do we get the GIT (e.g. http://dev.pyra-handheld.com/index.php/p/xserver-xorg-video-fbturbo/source/t...) into a compiled package into the repo?
That needs to be setup as a script somehow.
And second:
How can I build an image with all the packages we want and need included?
Once we got these scripts running, everything should be ready :)
Well, this turned into a long email with detailed configuration... probably should write this up somewhere. :)
On 2014-09-29 07:18:22 -0700, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 23:20:14 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
On 2014-09-08 20:38:31 -0500, Michael Mrozek wrote:
Am Mon, 08 Sep 2014 09:44:45 -0500 hat Vagrant Cascadian vagrant@debian.org geschrieben:
Okay, which of the two do you suggest?
I'd recommend squid-deb-proxy, as it's easiest to configure, though you'll need to enable wheezy-backports in sources.list:
deb http://http.debian.net/debian/ wheezy-backports main
And then install it:
apt-get update apt-get install squid-deb-proxy # maybe you'll need to add --target-release wheezy-backports
You may want to adjust the size and/or location of the cache in /etc/squid-deb-proxy/squid-deb-proxy.conf:
cache_dir aufs /srv/squid-deb-proxy 5000 16 256
The server I'll run that with will be our normal webserver. So it runs apache with tons of virtual domains already.
Is that an issue with that proxy setup?
Should be fine, squid-deb-proxy runs on port 8000 by default, though it's configurable. So any firewalling will need to allow port 8000 at least to/from localhost.
So, should I use debootstrap with qemu or qemu-user-static?
Is there a step-by-step guide for setting either up?
Those don't require configuration, simply installing them should work:
apt-get install debootstrap qemu-user-static
If that doesn't pull in binfmt-support, you'll also need to install that.
Then, you can create a cross-architecture chroot with:
export http_proxy=http://127.0.0.1:8000 # use squid-deb-proxy qemu-debootstrap --arch=armhf jessie /srv/schroot/jessie-armhf http://ftp.de.debian.org/debian chroot /srv/schroot/jessie-armhf dpkg --print-architecture
For the build configuration:
apt-get install sbuild schroot
create a configuration for...
/etc/schroot/chroot.d/jessie-armhf:
[jessie-armhf] aliases=jessie description=jessie-armhf groups=sbuild,root root-groups=root,sbuild type=directory union-type=aufs directory=/srv/schroot/jessie-armhf
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/10norecommends:
APT::Install-Recommends "false";
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/10notranslations:
Acquire::Languages "none" ;
/srv/schroot/jessie-armhf/etc/apt/apt.conf.d/30proxy:
acquire::http::proxy::127.0.0.1 DIRECT; acquire::http::proxy "http://127.0.0.1:8000";
/srv/schroot/jessie-armhf/usr/sbin/policy-rc.d:
#!/bin/sh # mark as executable # don't run any startup services in the chroot
echo "$0: not starting" exit 101
Now you should be able to add a user to group sbuild (note, this effectively gives root access to the system) and run sbuild/schroot:
sbuild -c jessie -d jessie-pyra foo_1.2.3-1.dsc
I recommend reprepro, as it handles signed repositories and it produces a repository with a standard repository layout out of the box.
Okay... I'll try to setup that within this week.
Manual install is fairly easy, getting automatic installs will take a bit more configuration.
Do you have a good guide for reprepro as well?
Create a repository dir (example using ~/public_html/debian for the repository):
mkdir -p ~/public_html/debian/conf
Drop the following in ~/public_html/debian/conf/distributions:
Codename: jessie-pyra Architectures: i386 amd64 armhf source Components: main udebComponents: main Description: Packages for DragonBox Pyra #signwith: KEYID Tracking: all
Then start adding packages:
reprepro --verbose --basedir ~/public_html/debian include jessie-pyra foo_1.2.3-1_armhf.changes
You can also add individual .deb or .dsc files for quick testing, though I'd recommend sticking with the full .changes files in the long-term:
reprepro --verbose --basedir ~/public_html/debian includedeb jessie-pyra foo_1.2.3-1_armhf.deb reprepro --verbose --basedir ~/public_html/debian includedsc jessie-pyra foo_1.2.3-1.dsc
That's the basics for a personal unsigned repository. Signing will require generating a GPG key (preferrably with subkeys, so you store the primary key somewhere secure). For setting up an upload queue with an incoming dir, it requires a bit more. The reprepro manpage has some information about that, and I'd be happy to help further with that.
I'm sure there's something I've forgotten... but at least that's a start. :)
live well, vagrant
Building on the EVM was a lot faster anyway (especially with a sata hd and -j2 :)
Depends on your build hardware... :)
I tried copying my cowbuilder setup to my desktop machine (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz), and copying qemu-arm-static in it. It's a lot slower, and some bits of the configure script just lock up or segfault.
msgmerge[20007]: segfault at ffffffffc603af18 ip 0000000060007e42 sp 00007fff44caa570 error 5 in qemu-arm-static[60000000+2b6000]
testing was done using the mc_4.8.12-1.dsc package.
1: first run 2: second run with ccache filled
devboard:
1: real 5m57.710s user 5m31.310s sys 0m44.480s
2: real 4m6.673s user 2m46.350s sys 0m31.540s
qemu:
1: real 26m54.438s user 25m56.957s sys 0m40.737s
2: real 15m54.446s user 15m0.077s sys 0m35.067s
On 2014-09-10 14:14:52 -0500, aTc wrote:
I tried copying my cowbuilder setup to my desktop machine (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz), and copying qemu-arm-static in it. It's a lot slower, and some bits of the configure script just lock up or segfault.
msgmerge[20007]: segfault at ffffffffc603af18 ip 0000000060007e42 sp 00007fff44caa570 error 5 in qemu-arm-static[60000000+2b6000]
testing was done using the mc_4.8.12-1.dsc package.
1: first run 2: second run with ccache filled
...
qemu:
1: real 26m54.438s
...
2: real 15m54.446s
I got similar results running this on an i5 laptop running with DEB_BUILD_OPTIONS=parallel=2 using sbuild and qemu-user-static (2.1+dfsg-4) with a jessie chroot.
No segfault for me, though. Wonder what caused that for you.
Overall, sounds like if you could set up build environments on your EVM boards, it would definitely be faster. I've typically done native armhf builds on a wandboard quad with sata, which is typically noticeably faster than my i5 laptop, but not nearly as dramatic as the numbers you were showing for your above tests.
Packages that only produce arch:all (such as many meta-packages packages) don't need to be built on the native architecture, though, so it might make sense to save the native builds only for packages that need it.
live well, vagrant
We still need to set up/agree on a name/email address to use for the various copyright/maintainer/uploader/changelog entries in the packages.
Something like Pyra Dev pyra-dev@pyra-handheld.com that ends up in mailinglist/place that everyone involved can read.
Am Thu, 11 Sep 2014 02:15:29 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
what about pyra-os@pyra-handheld.com?
That would include anything about the OS.
So readonly for everyone, and write access after registering?
We still need to set up/agree on a name/email address to use for the various copyright/maintainer/uploader/changelog entries in the packages.
Something like Pyra Dev pyra-dev@pyra-handheld.com that ends up in mailinglist/place that everyone involved can read.
Firmware mailing list Firmware@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/firmware
On 2014-09-29 07:13:12 -0700, Michael Mrozek wrote:
Am Thu, 11 Sep 2014 02:15:29 +0200 hat aTc atc@k-n-p.org geschrieben:
what about pyra-os@pyra-handheld.com?
That would include anything about the OS.
So readonly for everyone, and write access after registering?
It should probably be an address that can receive mail from abitrary people... if unknown users can get moderated through, that's probably fine. If people have questions regarding the licensing, bugs, etc. it shouldn't auto-discard unknown emails...
We still need to set up/agree on a name/email address to use for the various copyright/maintainer/uploader/changelog entries in the packages.
Something like Pyra Dev pyra-dev@pyra-handheld.com that ends up in mailinglist/place that everyone involved can read.
live well, vagrant
Hi,
Also, could you create a pyra-meta project on the git, so I have a place to push the "source" of those. (Unless anyone can think of a better name, the dependency packages are now called pyra-meta-base/desktop/xfce, etc. , there isn't really a naming standard for these type of packages)
Created.