From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6659262894210809856 Date: Tue, 26 Feb 2019 06:23:34 -0800 (PST) From: cedric_hombourger@mentor.com To: isar-users Message-Id: <465e23f7-41bb-4162-af75-63160653425f@googlegroups.com> In-Reply-To: <94924dd9-ae84-4e10-655f-a4afa86842a7@siemens.com> References: <94924dd9-ae84-4e10-655f-a4afa86842a7@siemens.com> Subject: Re: [ANNOUNCE] Upcoming ISAR release MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1209_422193069.1551191014204" X-Google-Token: EOaX1eMFWVS6v64RS5w0 X-Google-IP: 95.176.90.117 X-TUID: 7ZX0/Ie7zbZm ------=_Part_1209_422193069.1551191014204 Content-Type: multipart/alternative; boundary="----=_Part_1210_1043196597.1551191014204" ------=_Part_1210_1043196597.1551191014204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I agree that reproducible builds should be on the list. I have a patch to the dpkg-raw class which I will submit shortly to avoid getting a new timestamp in debian/changelog with every build In other words, there are two parallel tracks / work-packages towards reproducible builds (at least that I see): (1) get fixed content from designated upstream sources (ie what is being delineated below) (2) identify and fix areas where Isar is generating/building content in a non reproducible way It would be really nice if we could come up with some tooling to report differences between two Isar builds (obviously leveraging tools used by the Debian project such as diffoscope) Cedric On Monday, February 18, 2019 at 11:25:06 AM UTC+1, Jan Kiszka wrote: > > On 18.02.19 10:01, Maxim Yu. Osipov wrote: > > Hello everybody, > > > > Last release (v0.6) was made on 1st of October 2018. > > > > We plan to release the next version of ISAR on 1st of March, 2019. > > > > BTW, what do you think about making a 1.0 release? > > At least reproducible build should be solved for that. I think we have > currently > three open issues in that area: > > - switching between cached and non-cached builds on the fly > - cache unconditionally (make related task implicit) > - cache source package (re-)builds > > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > ------=_Part_1210_1043196597.1551191014204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I agree that reproducible builds should be on the list.I have a patch to the dpkg-raw class which I will submit shortly to avoid= getting a new timestamp in debian/changelog with every build
In other words, there are two parallel tracks / work-packages t= owards reproducible builds (at least that I see):

= (1) get fixed content from designated upstream sources (ie what is being de= lineated below)
(2) identify and fix areas where Isar is generati= ng/building content in a non reproducible way

It w= ould be really nice if we could come up with some tooling to report differe= nces between two Isar builds (obviously leveraging tools used by the Debian= project such as diffoscope)

Cedric

On Mond= ay, February 18, 2019 at 11:25:06 AM UTC+1, Jan Kiszka wrote:
On 18.02.19 10:01, Maxim Yu. Osipov wrote:
> Hello everybody,
>=20
> Last release (v0.6) was made on 1st of October 2018.
>=20
> We plan to release the next version of ISAR on 1st of March, 2019.
>=20
> BTW, what do you think about making a 1.0 release?

At least reproducible build should be solved for that. I think we have = currently=20
three open issues in that area:

=C2=A0 - switching between cached and non-cached builds on the fly
=C2=A0 - cache unconditionally (make related task implicit)
=C2=A0 - cache source package (re-)builds

Jan

--=20
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
------=_Part_1210_1043196597.1551191014204-- ------=_Part_1209_422193069.1551191014204--