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.
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.
Also, what else do we need? Do we need one GIT for each debian package we build and provide? (for example, meta-packages, our own config setups and daemons, the gl-wrapper, etc.) or can that be handled with one GIT where we have subdirectories for the packages?
What would be better and cleaner?
What do you need me to do to set it up properly? Anyone who wants to help (and can help) aTc here?
Issues tracker / organization -----------------------------
As our OS has nothing to do with the Letux setup, I'd like to use our own system (GitLab?) and issues tracker on our server.
I guess more devs can help with stuff for the OS (optimized configs, daemons, etc.) than for the kernel as well.
--- Mit freundlichen Grüßen,
Michael Mrozek
----------------------- OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt ----------------------- eMail: mrozek@openpandora.org
Replying in mail.
2017-07-04 2:18 GMT+02:00 Michael Mrozek EvilDragon@openpandora.org:
Do we need one GIT for each debian package we build and provide? (for example, meta-packages, our own config setups and daemons, the gl-wrapper, etc.) or can that be handled with one GIT where we have subdirectories for the packages?
That's how debian is working, see : https://anonscm.debian.org/cgit I'm guessing that's the way to go.
Anyone who wants to help (and can help) aTc here?
I dont know if I can (since I failed at helping on this side for the pandora angstrom next project), but I'm willing to try to help ;) Luckyly I know debian way more than angstrom :P
sebt3
Am Tue, 4 Jul 2017 09:11:44 +0200 hat Sébastien Huss sebastien.huss@gmail.com geschrieben:
Hi,
Do we need one GIT for each debian package we build and provide? (for example, meta-packages, our own config setups and daemons, the gl-wrapper, etc.) or can that be handled with one GIT where we have subdirectories for the packages?
That's how debian is working, see : https://anonscm.debian.org/cgit I'm guessing that's the way to go.
Ah - I'm not quite sure yet... is that one git with subdirectories? It more looks like a main git with links to various other gits...?
How does that work?
Anyone who wants to help (and can help) aTc here?
I dont know if I can (since I failed at helping on this side for the pandora angstrom next project), but I'm willing to try to help ;) Luckyly I know debian way more than angstrom :P
That's great :) You can certainly help then setting up GITs for our own packages.
On 2017-07-05, Michael Mrozek wrote:
Am Tue, 4 Jul 2017 09:11:44 +0200 hat Sébastien Huss sebastien.huss@gmail.com geschrieben:
Do we need one GIT for each debian package we build and provide? (for example, meta-packages, our own config setups and daemons, the gl-wrapper, etc.) or can that be handled with one GIT where we have subdirectories for the packages?
That's how debian is working, see : https://anonscm.debian.org/cgit I'm guessing that's the way to go.
Ah - I'm not quite sure yet... is that one git with subdirectories? It more looks like a main git with links to various other gits...?
That's all the git repositories hosted on debian's git infrastructure (some may be hosted elsewhere).
In Debian, typically there is one VCS repository for each source package (there are exceptions, as each package maintainer can decide their own workflow, or the limitations of other VCSes used). A source package may contain several binary packages (e.g. linux source builds linux-image-*, linux-base, linux-headers-*, linux-doc-*, etc.).
I'd recommend sticking with one git repository for each source package, at least for things building actual .deb files. In many cases, you may be able to simply merge Debian's git branch for a given package, which makes it easier to merge in future changes (e.g. security updates). Although there are tools such as "gbp import-dscs" that can make merging work as well, if the package maintainer in Debian isn't consistant with your preferred workflow.
Hopefully there won't be a lot of divergence from Debian, which should make life a lot simpler all around... :)
Anyone who wants to help (and can help) aTc here?
I've mostly just been lurking lately, but could probably help a bit. I've got many years of Debian packaging experience working within Debian, although there are some types of packages I tend to keep at a safe distance.
live well, vagrant
Am 04.07.2017 um 02:18 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
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.
The alternative would be to have one image with access to Pyra specific package server and do an apt-get upgrade during first boot (provided that there is network access).
Ideally, the build process should update all gits, compile and add the kernel, etc.
For Debian packaging this means to add a 'debian/' subdirectory with stuff for the build process. This can include such things and definitions of the package name etc.
Also, what else do we need? Do we need one GIT for each debian package we build and provide? (for example, meta-packages, our own config setups and daemons, the gl-wrapper, etc.) or can that be handled with one GIT where we have subdirectories for the packages?
What would be better and cleaner?
I think the usual way is to have separate git repos for each separate function block.
But the Debian packaging process can create multiple packages from one repo. So I think both options are available.
I also know from analyzing the QtMoko project that there can be one git repo and multiple git submodules.
What do you need me to do to set it up properly? Anyone who wants to help (and can help) aTc here?
Issues tracker / organization
As our OS has nothing to do with the Letux setup, I'd like to use our own system (GitLab?) and issues tracker on our server.
I guess more devs can help with stuff for the OS (optimized configs, daemons, etc.) than for the kernel as well.
Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Wed, 05 Jul 2017 02:30:22 +0200 hat Linux-SWAT openpandora@free.fr geschrieben:
Hi,
Anyone who wants to help (and can help) aTc here?
I can give a hand here, shell, zenity, OS stuff. Still have my devboards waiting.
Thanks :) I know you're familiar with Slackware, but are you also familiar with debian packages and the setup?
15 years using Slackware and 2 for Debian at work should be ok as a starting point.
LS
Le 2017-07-05 19:53, Michael Mrozek a écrit :
Am Wed, 05 Jul 2017 02:30:22 +0200 hat Linux-SWAT openpandora@free.fr geschrieben:
Hi,
Anyone who wants to help (and can help) aTc here?
I can give a hand here, shell, zenity, OS stuff. Still have my devboards waiting.
Thanks :) I know you're familiar with Slackware, but are you also familiar with debian packages and the setup?
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
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.
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.
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.
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...
Hope that's helpful...
live well, vagrant
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 :)
Am Thu, 6 Jul 2017 01:09:38 +0200 hat aTc atc@k-n-p.org geschrieben:
Hi,
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
Notice: As mentioned in one of the mails, I've currently switched to GitLab on dev.pyra-handhelds.com, so it's empty right now, as I need to know which projects and subprojects I need to create.
So we should restart the GITs there from scratch, in my opinion.
Do you have everything you need or should I switch back to Indefero for the moment?
You should register at dev.pyra-handhelds.com, then I can add you to the group and you can create and manage all the needed gits yourself.
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.
Okay. So we simply update the debian packages once we updated them and the image creation tool should automatically pull in the new packages as well. Understood.
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.
Yes, it would be nice to have unstable, testing and stable (or at least unstable and testing/stable, so users can also test last-minute patches).
Am Thu, 6 Jul 2017 14:17:21 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
ah, just noticed you already created projects on GitLab :) Nice, that means it's properly working :D
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
Notice: As mentioned in one of the mails, I've currently switched to GitLab on dev.pyra-handhelds.com, so it's empty right now, as I need to know which projects and subprojects I need to create.
Even cloning from github works : http://dev.pyra-handheld.com/sebt3/pyraRepo
2017-07-06 14:36 GMT+02:00 Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 6 Jul 2017 14:17:21 +0200 hat Michael Mrozek EvilDragon@openpandora.org geschrieben:
Hi,
ah, just noticed you already created projects on GitLab :) Nice, that means it's properly working :D
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
Notice: As mentioned in one of the mails, I've currently switched to GitLab on dev.pyra-handhelds.com, so it's empty right now, as I need to know which projects and subprojects I need to create.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-
aTc -
H. Nikolaus Schaller -
Linux-SWAT -
Michael Mrozek -
Sébastien Huss -
Vagrant Cascadian