On 07/05/2017 09:12 PM, Vagrant Cascadian wrote:
On 2017-07-03, Michael Mrozek wrote:
And finally, we need to think about the OS development.
Image creation
At the moment, aTc somehow creates images out of somewhere... but not anywhere public.
So everything for that needs to be setup on our GIT as well.
aTc, now that you have more experience with building the Debian stuff, maybe you could let me know here how many gits and what gits we need.
I already created a public packages group on dev.pyra-handhelds.com , and pushing my git stuff to it (slowly, have to check everything and do a few cleanups in places).
I currently build/maintain them with gbp
Basically, it should be similar to the old Pandora OS, where I can just trigger an OS image creation process on the server and a few minutes later, we have a brand new, fresh image.
Ideally, the build process should update all gits, compile and add the kernel, etc.
It seems like image creation should largely just build the image out of Debian packages that are included in a "staging" apt repository, rather than recompiling everything every time you build an image.
Yes, Openembedded was more designed so that you had everything in a single tree you had complete control over, with packages you all built yourself. With Debian you just have packages that some package maintainer puts on a repo, and you grab the latest versions to assemble your image.
OE was also designed to do everything with a crosscompiler and on a different env than the target hardware. Debian sort of expects to be running on arm hardware when you're installing arm packages/images.
Here's a rough sketch of a repository structure used to build images and run updates on systems in the wild:
You could have a "staging" apt repository where new package builds go, and trigger a new package build based on some criteria (manually, signed vcs tag, post-commit hook, etc.), which then uploads to the staging repository if the build succeeds.
Once a package has been vetted (manually or programatically), it can be promoted to another repository, such as "development" and once you feel it's ready for the wide world to adopt, have a "stable" repository...
I usually use reprepro for smallish repositories. I've also been meaning to explore mini-buildd which might be useful in an automated build configuration:
https://packages.debian.org/unstable/reprepro https://packages.debian.org/unstable/mini-buildd
With three different repositories, you could trigger different image builds that are targeted at automated builds with the latest untested stuff, development builds that have been somewhat tested, and builds targeted at the end-user.
I could do with some help setting up the repo that way. I've currently got just a basic single stable repo reprepro setup where i can dput a package to, and then manually run processincomming to get everything online.
There are a number of different tools in Debian to do image builds; the Debian project now uses vmdebootstrap to create official live images (although not officially for ARM systems, though it does have some support). That said, the original upstream developer of vmdebootstrap has already moved on to a rewrite, vmdb2:
https://blog.liw.fi/posts/2017/06/04/vmdb2_first_alpha_release_debian_disk_i...
I currently use multistrap (with a few hook scripts) to generate the images. Although i've also made a debootstrap based script. Since everything (where possible) is configured by the packages themselves, any method should work.
And having lots of tools to do the same thing seem to be the Debian way :)