From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6788114222392803328 Date: Tue, 7 Apr 2020 02:37:26 -0700 (PDT) From: vijai kumar To: isar-users Message-Id: <7fe4e9fe-0576-4c1b-93eb-46f5e8e8685f@googlegroups.com> In-Reply-To: <20200331194729.4aa48e53@md1za8fc.ad001.siemens.net> References: <20200326134325.8672-1-henning.schild@siemens.com> <20200327071126.muwgzwsgjkkhldjl@yssyq.m.ilbers.de> <20200327120115.0e00c0b1@md1za8fc.ad001.siemens.net> <20200330202443.7vaqklykvt6xbhv2@yssyq.m.ilbers.de> <20200331194729.4aa48e53@md1za8fc.ad001.siemens.net> Subject: Re: [PATCHv8 00/29] base-apt-rework MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2195_1561651442.1586252246677" X-Google-Token: ENaTsfQFYavGD099sJE0 X-Google-IP: 192.94.34.34 X-TUID: PY6VbJVEmkSt ------=_Part_2195_1561651442.1586252246677 Content-Type: multipart/alternative; boundary="----=_Part_2196_1045648633.1586252246678" ------=_Part_2196_1045648633.1586252246678 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tuesday, March 31, 2020 at 11:17:32 PM UTC+5:30, Henning Schild wrote: > > On Mon, 30 Mar 2020 22:24:43 +0200 > Baurzhan Ismagulov > wrote: > > > On Fri, Mar 27, 2020 at 12:01:15PM +0100, Henning Schild wrote: > > > > Thanks, my first two builds succeeded. Your #158 failed due to > > > > timeout executing the images, possibly due to nightly builds > > > > starting (on the old server, we needed up to -t 960). I've > > > > enabled log timestamps for your job. > > > > > > I had a look at 158 and decided to ignore the "failure". > > > > I don't think that blocks your series, either. The question was > > rather what to do to avoid false failures in the future. I've > > increased the timeouts from 300 s to 600 s, also for your project. > > > > Applied to next, thanks. > > Cool, thanks! > > Finally got this off my shoulders, now waiting for follow-up complaints > ... hopefully not too many ;). > Hi Henning, Quick question. Though it does not affect any existing functionality, I see that all the debs are cached inside ${DEBDIR}/${DISTRO} directory. When {HOST_DISTRO} != {DISTRO} shouldn't we ideally cache the relevant bootstrap packages in their appropriate {DEBDIR}/{HOST_DISTRO} directory? One applicable case is rpi-stretch. Thanks, Vijai Kumar K > Henning > > > With kind regards, > > Baurzhan. > > > > ------=_Part_2196_1045648633.1586252246678 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, March 31, 2020 at 11:17:32 PM UTC+5:30= , Henning Schild wrote:
On Mon,= 30 Mar 2020 22:24:43 +0200
Baurzhan Ismagulov <i...@radix50.net> wrote:

> On Fri, Mar 27, 2020 at 12:01:15PM +0100, Henning Schild wrote:
> > > Thanks, my first two builds succeeded. Your #158 failed = due to
> > > timeout executing the images, possibly due to nightly bu= ilds
> > > starting (on the old server, we needed up to -t 960). I&= #39;ve
> > > enabled log timestamps for your job. =C2=A0
> >=20
> > I had a look at 158 and decided to ignore the "failure&q= uot;. =C2=A0
>=20
> I don't think that blocks your series, either. The question wa= s
> rather what to do to avoid false failures in the future. I've
> increased the timeouts from 300 s to 600 s, also for your project.
>=20
> Applied to next, thanks.

Cool, thanks!

Finally got this off my shoulders, now waiting for follow-up complaints
... hopefully not too many ;).

Hi Henning,

Q= uick question. Though it does not affect any existing functionality, I see = that all the debs are cached inside ${DEBDIR}/${DISTRO} directory. When {HO= ST_DISTRO} !=3D {DISTRO} shouldn't we ideally cache the relevant bootst= rap packages in their appropriate {DEBDIR}/{HOST_DISTRO} directory? One app= licable case is rpi-stretch.=C2=A0


= Thanks,
Vijai Kumar K


Henning

> With kind regards,
> Baurzhan.
>=20

------=_Part_2196_1045648633.1586252246678-- ------=_Part_2195_1561651442.1586252246677--