public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Ben Brenson <benbrenson89@googlemail.com>,
	isar-users <isar-users@googlegroups.com>
Subject: Re: Isar fork
Date: Wed, 18 Oct 2017 13:16:16 +0200	[thread overview]
Message-ID: <f88ebeb5-784c-d41e-5e57-6c136831357b@siemens.com> (raw)
In-Reply-To: <8fe13268-9bfa-4b24-897a-133c9530c188@googlegroups.com>

On 2017-10-18 11:23, 'Ben Brenson' via isar-users wrote:
> Hi,
> 
> I am doing further development on Isar for several months now. This work
> was done on behalf of Siemens for creating reproducible images.
> There are several new features, I have implemented and maybe you are
> interested in a few of them.
> The main new features are:
> 
> * Running chroot tasks and define them as simple bitbake shell tasks:
> Defining bitbake tasks, which should run as chroot tasks, offers the
> advantage of -append and -prepend those tasks in different layers, and
> therefore
> offers much more flexibility and modularity.
> 
> * Debianizing of non debian-compatible source code repositories:
> Since Isar follows the strategy, to only produce deb packages, source
> code which is not debian compatible but should also be able to build,
> must first be debianized.
> The main work is done within the debianize.bbclass.
> After inheriting the debianize class you can define (by overwriting the
> tasks defined in debianize.bbclass) simple makefile tasks within your
> recipe.
> Those tasks are parsed and bitbake will then create the required debian
> rules makefile.
> This also gives the possibility of layering/overwriting those tasks
> within other layers.
> 
> * Cross compile support:
> This feature is not completely finished yet and the implementation might
> change in the future.
> The idea is very similar to the isar's *-dpkg-cross branch. But there
> are some problems we discovered, so there has to be a more generic and
> proper way of
> cross compile packages.
> A third buildchroot (cross-buildchroot) is created, and source code is
> build with the cross compiler within.
> I think this feature is very important, since qemu user emulation
> suffers under very poor performance and slows down development progress
> a lot.
> 
> The following repositories are available on github now:
> https://github.com/benbrenson/isar.git
> https://github.com/benbrenson/meta-amazon.git
> https://github.com/benbrenson/meta-sunxi.git
> https://github.com/benbrenson/meta-swupdate.git
> https://github.com/benbrenson/meta-unittest.git (refers to company
> internal repositories, which are not open source yet)
> 
> For now, only the isar repository itself is better documented. The
> user_manual.md was therefore modified.
> 
> TODOS:
> * Add support for incremental builds
> * Cache debian binaries for creating reproducible images, with
> persistent versions of all packages (I saw, there is already discussion
> about that on this forum).
> * Add support for more hardware (rpi, beagle bone, i.MX6 platforms,
> odroid, allwinner platforms etc.)
> * Add support for qemu images (not tested on isar fork, yet)
> 
> The main cause, why I'm writing so late, is just because we have been
> waiting until the customer gave the permissions for releasing this
> project on github.

Thanks for posting this. To move technically forward, we will need
factored out patch series against upstream, eventually posted here. Are
you looking for suggestion what to present first, and how? Or what are
your plans to consolidate the code bases?

Given that your baseline of Isar is rather old (25 May?), how do the
latest feature addition to upstream relate to what you addressed? Can
you imagine rebasing on top of those features, reusing them, or are
there fundamental differences in the approaches?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2017-10-18 11:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  9:23 Ben Brenson
2017-10-18 11:16 ` Jan Kiszka [this message]
2017-10-18 11:56   ` Ben Brenson
2017-10-18 12:09     ` Jan Kiszka
2017-10-18 11:56 ` Claudius Heine
2017-10-18 12:11   ` Ben Brenson
2017-10-18 12:52     ` Claudius Heine
2017-10-18 14:02       ` Ben Brenson
2017-10-18 14:19         ` Henning Schild
2017-10-18 14:22         ` Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f88ebeb5-784c-d41e-5e57-6c136831357b@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=benbrenson89@googlemail.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox