From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6527660707060645888 X-Gmail-Labels: Topic type: DISCUSSION X-Received: by 10.80.146.109 with SMTP id j42mr5744297eda.6.1519840505200; Wed, 28 Feb 2018 09:55:05 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.169.98 with SMTP id m31ls2495363edc.0.gmail; Wed, 28 Feb 2018 09:55:04 -0800 (PST) X-Google-Smtp-Source: AH8x225vkBJdBQGOqhlNWObMOL0xj/iLdW0Kxixl23XW1yhGPXxYcgHdRptOxft5B99XZWfnJDrb X-Received: by 10.80.200.202 with SMTP id k10mr5600245edh.10.1519840504434; Wed, 28 Feb 2018 09:55:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519840504; cv=none; d=google.com; s=arc-20160816; b=YW4bldTpYpyTylvEACbWhA3nOO4R4DcxKgBJ9LIrb69o29vPBEtPIepN/x2g3+bVpq U2nJ2Gsw4vexjwzPliSNeLC6oo9fd1qwuj7iiFiZoCaLk/JcjdJlRRB2qi/NAkpFRdY1 Z4e7pRJSeYVeLxgH4P5OTj96+HS5ramfF5/kq3fWg4DEAtOpiZvV7gLg3Psist0Hmjv6 xtQibYp+/wI34mCiGQ6ol5RaW7C/UGJb8Axw/WUioab9XYr0BVCnypG7xIo6chB/BsKy ZdjmUFOgOAwsNKeVJ6BlGi1/uVLU8DiJA94qYpT9WRm9U38r65x2p+bk7pyzVNhj0rn7 snzQ== 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=SytiWQAHTYL1UZTco2CWhQBmSJgKDEsMCVDuuqYYlgg=; b=SfcepcQXJc05Ko+jrg3uVLL+wA6uiZN0ZT6MRqKKQSFgpTlpLBFdYhpKNjb/H12SF1 1hElANSXP2snb4vQ0i+yRUu/ux4C5QZBI1fjOsHqqKHCo+P6Gdj0+tEbTU/fDPSrBTii zo7Q81ptKZaRJww8wh/eenKjg9a+Yfy/6qlQ/BGqknnsY+rADDgSjbuADnnKAt0Mk8nC qb/n+F90CzBo0I4OJKXOu0K95quOM0/BL6ck5HQ9vUjPjfx/zAVJ7xrVEJF5a71Uh2Cr uuE3EiJXukim3VJn9gPMDBKkN0ra4YuR0L2yuhtXRJO3IbxGXfXk4i/XgtVEerMDZt4L AACQ== 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 t4si135208edt.2.2018.02.28.09.55.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 09:55:04 -0800 (PST) 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 mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w1SHt3dC026176 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Feb 2018 18:55:03 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w1SHt3ZB015788; Wed, 28 Feb 2018 18:55:03 +0100 Subject: Re: bind mount for /downloads not happening To: chombourger@gmail.com, isar-users References: From: Jan Kiszka Message-ID: Date: Wed, 28 Feb 2018 18:55:02 +0100 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 1yy+Dnk6BTQZ On 2018-02-28 18:37, chombourger@gmail.com wrote: > Hi Jan, > > I was in the process of rebasing to the latest Isar/next to discard some of > the local commits we had. > In particular we had a change from Christian to make git trees available to > the build process. > This change should no longer be required thanks to > 9a8b7fe77cbd006b6053f85e593301c60ea0cfbd (Make sure git repos are usable > inside buildchroot) > > It unfortunately did not quite work for me. I believe I understand why and > wanted to run my theory by you to double-check!. > > # > https://github.com/ilbers/isar/blob/next/meta/classes/dpkg-base.bbclass#L44 > do_build() { > mkdir -p ${BUILDROOT} > sudo mount --bind ${WORKDIR} ${BUILDROOT} > > sudo flock ${MOUNT_LOCKFILE} -c ' \ > if ! grep -q ${BUILDCHROOT_DIR}/isar-apt /proc/mounts; then \ > mount --bind ${DEPLOY_DIR_APT}/${DISTRO} > ${BUILDCHROOT_DIR}/isar-apt; \ > mount --bind ${DL_DIR} ${BUILDCHROOT_DIR}/downloads; \ > mount -t devtmpfs -o mode=0755,nosuid devtmpfs > ${BUILDCHROOT_DIR}/dev; \ > mount -t proc none ${BUILDCHROOT_DIR}/proc; \ > fi' > > We check if isar-apt was mounted to mount everything else. OK. > > We however have the following code also mounting isar-apt: > > # > https://github.com/ilbers/isar/blob/next/meta/recipes-devtools/buildchroot/buildchroot.bb#L68 > do_build() { > ... > sudo mount --bind ${DEPLOY_DIR_APT}/${DISTRO} > ${BUILDCHROOT_DIR}/isar-apt > sudo mount -t devtmpfs -o mode=0755,nosuid devtmpfs > ${BUILDCHROOT_DIR}/dev > sudo mount -t proc none ${BUILDCHROOT_DIR}/proc > ... > > If you do a full platform build, isar-apt will get mounted from the > buildchroot recipe and our downloads folder will not be mounted from > dpkg-base.bb (and cause our swiupdate recipe to fail) > > I would be tempted to add a bind mount for downloads in the buildchroot > recipe. The other option would be add a check in dpkg-base.bb for downloads > being mounted (we would then have 2 "if" statements in the code block > passed to flock. > > Thoughts? Good catch. I probably missed this during tests because I didn't check the result of a full rebuild. Let's just quickly add the download mount also to buildchroot.bb. Things should get centralized soon with the switch to debootstrap and Claudius' refactorings along that. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux