From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7182796543154454528 X-Received: by 2002:ab0:3817:0:b0:636:d8cd:9c94 with SMTP id x23-20020ab03817000000b00636d8cd9c94mr171011uav.59.1674198052137; Thu, 19 Jan 2023 23:00:52 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a67:d20f:0:b0:3d2:3980:e728 with SMTP id y15-20020a67d20f000000b003d23980e728ls1525010vsi.8.-pod-prod-gmail; Thu, 19 Jan 2023 23:00:51 -0800 (PST) X-Google-Smtp-Source: AMrXdXutZMqpEy5kUoAWzqtM6RjQZCqo+cKx96eVX1Qn3CZkgOzbPl5q9hTc1mhsCW7eRGaqMiVr X-Received: by 2002:a67:e24f:0:b0:3b1:19ba:5025 with SMTP id w15-20020a67e24f000000b003b119ba5025mr9108018vse.23.1674198051245; Thu, 19 Jan 2023 23:00:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674198051; cv=none; d=google.com; s=arc-20160816; b=mhUgGdqq7XeEcPv2o+kxeXrBavgUpuHB1RX+MS6xBRJ9pXQDiEdb1L8JorRxu+7OkW 2GYDMBzG2BOgbXtfcXOLPU5QdTxvYYUiB/uIUhkdr/gCgKRAv6qysU17xXsRjHSpOo2O xTCGDQQ3YrPQxltGRISy9SaDj1MXqpMKdQr6fTW6qPeeDus5OauJT8Z8LVZh3mn98vCG 6aOZ9NbIGREYIEBKST6s7b7zjJFKnUQRlIXWvu/G8d8XCQ+q2802lv7HPFaF73pST160 GIviQd7/dJ9rCHcoU6WFizmdlDmw/ISe8mUlt/R6IA2ri1Yb733L8wk77IAHeDSiz2pt 4YoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=5PP9kSv7/rN0vv+sSfalWN86x9VJIhxtErWbOp4RhAo=; b=Wim+jwdJvW9evCsaRva35OJrYaCBbrgM1ne5nTFv1wki6JeIfI/5MiD2JDFVTEq/oA uiO4fAzcpHZSNTxqNSHySkR7Pbm2FkTWwACf7Q5ERqejv6+HiY2qITvNhlb6s/voYqBF 0c2Vn4mFtJPQ2sQ2/+QY/QqUehijo/C/8Y2zbGx0SY6cleTpQU9LFXO5MVOxcie41OTn mT81nZjBI9tKuqf7zcQUpVxqsPD4ZX0BfYGhQw+CPtC/1Q4OLNnWfduxXydU3EGgRF7/ 8zV40XEdDIOyxu2jozAfXrgkKhVu/egzudQQjZ6BRuCqtXhyeza141J2J/Ty6voW5H4f 1m3w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id p13-20020a67f30d000000b003d04209e4e2si2589877vsf.0.2023.01.19.23.00.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Jan 2023 23:00:51 -0800 (PST) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from hp.localnet (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 30K70lSi001474 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Jan 2023 08:00:48 +0100 From: Uladzimir Bely To: "Moessbauer, Felix" Cc: "isar-users@googlegroups.com" Subject: Re: [PATCH v2 0/3] Improving apt cache Date: Fri, 20 Jan 2023 10:01:24 +0300 Message-ID: <1889300.7Z3S40VBb9@hp> In-Reply-To: References: <20230106064809.10412-1-ubely@ilbers.de> <9466878.eNJFYEL58v@hp> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: En0O/AmS2BPO In mail from =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D0=B0, 20 =D1=8F=D0=BD=D0= =B2=D0=B0=D1=80=D1=8F 2023 =D0=B3. 08:08:03 +03 user Moessbauer, Felix=20 wrote: > On Fri, 2023-01-20 at 07:44 +0300, Uladzimir Bely wrote: >=20 > > In mail from =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 19 =D1=8F=D0= =BD=D0=B2=D0=B0=D1=80=D1=8F 2023 =D0=B3. 17:52:37 +03 user Roberto A. > > Foglietta=20 > > wrote: > >=20 > > > On Thu, 19 Jan 2023 at 08:36, Uladzimir Bely > > > wrote: > > >=20 > > > > I got time to get back to this patches and checked this moment. > > > > And it > > > > really > > > > does not work as I expected. > > > >=20 > > > > Original patch includes the following: > > > >=20 > > > > - --chroot-setup-commands=3D"cp -n --no-preserve=3Downer > > > > ${ext_deb_dir}/ > > > > *.deb -t ${deb_dir}/ || :" \ > > > > + --chroot-setup-commands=3D"ln -Pf ${ext_deb_dir}/*.deb -t > > > > ${deb_dir}/ > > > > 2>/dev/null || :" \ > > > >=20 > > > > This results to to failing "ReproTest" in CI with the following > > > > error (for > > > > libhello, for example): > > > >=20 > > > > sbuild-build-depends-dose3-dummy:armhf : Depends: dose- > > > > distcheck:amd64 but > > > > it > > > > is not installable > > > > E: Unable to correct problems, you have held broken packages. > > > >=20 > > > > To debug it, I removed `2>/dev/null` and found, that hardlinks > > > > simply > > > > don't > > > > work and the following errors are now seen earlier: > > > >=20 > > > > ln: failed to create hard link > > > > '/var/cache/apt/archives/adduser_3.118_all.deb' > > > > =3D> '/home/builder/libhello/rootfs/var/cache/apt/archives/ > > > > adduser_3.118_all.deb': Invalid cross-device link > > > > ... #tons of similar errors... > > > > ln: failed to create hard link '/var/cache/apt/archives/ > > > > zlib1g_1%3a1.2.11.dfsg-2+deb11u2_mipsel.deb' =3D> > > > > '/home/builder/libhello/ > > > > rootfs/var/cache/apt/archives/zlib1g_1%3a1.2.11.dfsg- > > > > 2+deb11u2_mipsel.deb' > > > >=20 > > > > : > > > >=20 > > > >=20 > > > > Invalid cross-device link > > > >=20 > > > > I: Finished running 'ln -Pf > > > > /home/builder/libhello/rootfs/var/cache/apt/ > > > > archives/*.deb -t /var/cache/apt/archives/ || :'. > > > >=20 > > > > So, it works for network builds (when missing packages always can > > > > be > > > > downloaded by apt), but it fails for local builds from apt-cache > > > > (when, at > > > > first network build, sbuild dependencies are simply not exported > > > > to > > > > download > > > > directory due to non-working hardlinks, plus with hidden stderr) > > >=20 > > >=20 > > > Hi, first of all I do not fully understand why we use ln -P instead > > > of ln > > > -Pf in the exporting debs. > > >=20 > > > --finished-build-commands=3D"ln -P ${deb_dir}/*.deb -t > > > ${ext_deb_dir}/ 2>/dev/null || :" \ > > >=20 > > > This code's goal is to build a deb that should be exported > > > otherwise we are > > > continuing using the old package. It seems that breaks things but - > > > again - > > > I did fully not understand what and why but simply accepted the > > > suggestion. > > > Now, I have reverted back to ln -Pf. > > >=20 > > > Second, those lines are supposed to fail - and obviously fail in > > > both > > > directions: import and export - but the following > > >=20 > > > (a) if export fail we will not have the custom packages but we have > > > them > > > (b) removing that lines and the code will always fail > > >=20 > > > These mean that ln -Pf complains to fail but make a difference and > > > make the > > > difference that we want. However, I might not have understood the > > > case in > > > which it fails completely so: > > >=20 > > > mv build/downloads . > > > rm -rf build > > > ./build.sh basic-os (DONE) > > > ./clean.sh isar > > > ./build.sh (DONE) > > > ./clean.sh all > > > ./build.sh (DONE) > > >=20 > > > remove that two lines about ln -Pf that are supposed to do nothing > > > than fail > > >=20 > > > ./clean.sh all > > > ./build.sh (DONE with the same building time) > > >=20 > > > rm -rf build/downloads > > > mv downloads build > > >=20 > > > ./clean.sh isar > > > ./build.sh complete (FAIL) > > >=20 > > > put back those two command lines with ln -Pf and > > >=20 > > > ./clean.sh all > > > ./build.sh (DONE) > > >=20 > > > I do not say you are wrong and I see ln -Pf complains on stderr but > > > nothing > > > that tin my private fork cannot be solved using a stderr > > > redirection to > > > /dev/null > > >=20 > > > However there are some other ways to do this thing: > > >=20 > > > 1. sbuild uses schroot by default, using chroot instead > > > 2. keep the default in schroot, elsewhere it uses upper folder that > > > can be > > > populated in advance > > >=20 > > > I did not make any changes because I did not identified the issue. > > >=20 > > > Best regards, R- > >=20 > >=20 > > I'll try to make things clear. Isar supports local builds from 'base- > > apt' repo=20 > > with. > >=20 > > First build user does as usual. > >=20 > > Second build is done with the following changes (at least): > >=20 > > ISAR_USE_CACHED_BASE_REPO =3D "1" > > BB_NO_NETWORK =3D "1" > >=20 > > In this case every .deb we downloaded from Debian mirrors at first > > build goes=20 > > to local 'base-apt' and second build use it, but not remote mirrors. > >=20 > > That's the reason of using this "cp/ln magic" inside of sbuild. While > > building=20 > > some package, multipe dependencies might be downloaded inside of > > sbuild. And=20 > > we need a way to extract them from "internal" apt-cache in sbuild > > schroot and=20 > > put to the package workdir, where deb-dl-dir export will pass them to > > DL_DIR=20 > > later. > >=20 > > When we replace copying to hardlinks, that actually don't work due to > > different filesystems, we come to the situation, when multiple debian > > packages=20 > > (dependencies of what we are building or some packages that sbuild > > requires=20 > > itself) are not present in DL_DIR. So, second "cached" build from > > local repo=20 > > simply fails. > >=20 > > I see the following possible solutions that allows to save space. > > 1. Since hardlinks don't work, try to use symlinks. >=20 >=20 > If that works, it clearly is the simplest solution. >=20 Yes, approach with symlinks inside sbuild chroot seems to be working, so I'= m=20 going to use it in patchset v3. >=20 > > 2. Don't use import with sbuild at all, but only export. But this has > > a=20 > > drawback, when all packages we build with sbuild might download the > > similar=20 > > dependencies in parallel. >=20 >=20 > A third solution might be to mount the cache into the schroot, similar > to how we handle the sstate cache today. >=20 > Anyways, I would appreciate if we could merge this series even if it > still does not fully solve the quadratic behavior. It is very valuable > and "good enough" even for my biggest layers. >=20 > Felix >=20 >=20 > >=20 > >=20 >=20 >=20