Hi Jan,
yes you are right, the baseline of the isar fork is quiet old.
We had to implement some features quiet fast to get a first image build working.
Combined with the open source agreement, we forked this repository  and started developing.

Since a lot of the codebase has changed, related to 25 May, a little bit of effort is required to work out some patches, but I will try do handle this.
The first feature I intent to post, would be the chroot related stuff, because the most changes are related to the bitbake core itself, which should be at the same state as
my repository.

So adding this feature won't force Isar to make use of them, but the possibility of using them may be available after.
So I think I will start with that feature, by submitting patch series.

The other features will dive very deep into isar, and the codebase differs a lot now.
This fact never offered the possibility of frequently rebasing against upstream.
So rebasing now against the main repository will be a time consuming job, but is required :-(

May be rebasing the current Isar features against my repo will be much easier to handle,
but doesn't that miss the goal of getting my features mainlined into current mainline Isar?


Regards,
Benedikt
 

Am Mittwoch, 18. Oktober 2017 13:16:18 UTC+2 schrieb Jan Kiszka:

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