From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478179128234213376 X-Received: by 10.80.230.12 with SMTP id y12mr2551330edm.6.1508325378842; Wed, 18 Oct 2017 04:16:18 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.170.121 with SMTP id p54ls1721713edc.7.gmail; Wed, 18 Oct 2017 04:16:18 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TuwaHnO8H7TziqEAX1wAbxr3bS0/mUvcw1Bf2iuBl7ctIR6Zs+NLnTpfv6MwxjnV7tIcBL X-Received: by 10.80.230.12 with SMTP id y12mr2551327edm.6.1508325378597; Wed, 18 Oct 2017 04:16:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508325378; cv=none; d=google.com; s=arc-20160816; b=xC7X7wu5nFSMcduGyhfw+WyNc6fnatpbLjSrWTa9Ecw3STCBhmqpEiNipjqOuz35LJ C1F9h6/ZWI810lk7fuF1N/CyDCrEVdqVgxxBJf51oR5E50uApA5cIvUZBSNV85xQSxnb vvZxGBfb0BSzJnzuBr+iYTz9PHcsL6U9b4htivzarmp+SM5QsDFMepBFE9reAE44pN67 Igm1POIB6BW1ahL4Yk+n5zqzvB2JwjDDd+oORtVXhRPrDFL4UpeGbsuBPeGLT+YC3Tb1 KD9BDN0n8XIYNfMG8F1LIZl1AYR5a2jFC9nYpktUjTAqTbU6RsZNWP8gJysX7mU91NrT ye8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=/S7Fyf7Cr2WVJdbFAD/w1NZ/oOLvKtNI0LPuNyC4b58=; b=bqdZ4egCTIbLxwjx42rV8Nt1XvLNr6PkobBSJxovsxrC/bHKxoao6ZAHv7n0xibCmT bcBGVu2nfjshDb9aIiU1EYT3KNUgT7+mSLfZgXKyCnfBmbdmV3KB5XrffZvArGXo+Bt/ t0+hbsLLeu1+QOsNx5K2c/NcZMdDNjDzoXnLSW0fqxoZqhbDze5o8QTrgi0YnN5IOdqY j1Cm0vh3wYQwRYKJgVJV2u8PB+39yJfwLy4o4ldBaDR3PH1WrlDebBIjTY1ixU5YB3jT TNonxeC5s6UwmLSxyWgYu65iZh0+VSzME8C2VLhinVlu+7cf43Te6x+BOeX63Q88lMzF Tz2Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id f9si692488edm.1.2017.10.18.04.16.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 04:16:18 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v9IBGI0T007548 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Oct 2017 13:16:18 +0200 Received: from md1f2u6c.ww002.siemens.net ([158.92.8.8]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v9IBGHFe005890; Wed, 18 Oct 2017 13:16:17 +0200 Subject: Re: Isar fork To: Ben Brenson , isar-users References: <8fe13268-9bfa-4b24-897a-133c9530c188@googlegroups.com> From: Jan Kiszka Message-ID: Date: Wed, 18 Oct 2017 13:16:16 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <8fe13268-9bfa-4b24-897a-133c9530c188@googlegroups.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: s/CQjTqFdW5g 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