public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
To: "roberto.foglietta@gmail.com" <roberto.foglietta@gmail.com>,
	"ubely@ilbers.de" <ubely@ilbers.de>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: [PATCH v2 0/3] Improving apt cache
Date: Fri, 20 Jan 2023 05:08:03 +0000	[thread overview]
Message-ID: <d28cc40f4400ad146c1568c89f87061006c83374.camel@siemens.com> (raw)
In-Reply-To: <9466878.eNJFYEL58v@hp>

On Fri, 2023-01-20 at 07:44 +0300, Uladzimir Bely wrote:
> In mail from четверг, 19 января 2023 г. 17:52:37 +03 user Roberto A.
> Foglietta 
> wrote:
> > On Thu, 19 Jan 2023 at 08:36, Uladzimir Bely <ubely@ilbers.de>
> > wrote:
> > > I got time to get back to this patches and checked this moment.
> > > And it
> > > really
> > > does not work as I expected.
> > > 
> > > Original patch includes the following:
> > > 
> > > -        --chroot-setup-commands="cp -n --no-preserve=owner
> > > ${ext_deb_dir}/
> > > *.deb -t ${deb_dir}/ || :" \
> > > +        --chroot-setup-commands="ln -Pf ${ext_deb_dir}/*.deb -t
> > > ${deb_dir}/
> > > 2>/dev/null || :" \
> > > 
> > > This results to to failing "ReproTest" in CI with the following
> > > error (for
> > > libhello, for example):
> > > 
> > > 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.
> > > 
> > > To debug it, I removed `2>/dev/null` and found, that hardlinks
> > > simply
> > > don't
> > > work and the following errors are now seen earlier:
> > > 
> > > ln: failed to create hard link
> > > '/var/cache/apt/archives/adduser_3.118_all.deb'
> > > => '/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' =>
> > > '/home/builder/libhello/
> > > rootfs/var/cache/apt/archives/zlib1g_1%3a1.2.11.dfsg-
> > > 2+deb11u2_mipsel.deb'
> > > :
> > > 
> > > Invalid cross-device link
> > > 
> > > I: Finished running 'ln -Pf
> > > /home/builder/libhello/rootfs/var/cache/apt/
> > > archives/*.deb -t /var/cache/apt/archives/ || :'.
> > > 
> > > 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)
> > 
> > Hi, first of all I do not fully understand why we use ln -P instead
> > of ln
> > -Pf in the exporting debs.
> > 
> >         --finished-build-commands="ln -P ${deb_dir}/*.deb -t
> > ${ext_deb_dir}/ 2>/dev/null || :" \
> > 
> > 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.
> > 
> > Second, those lines are supposed to fail - and obviously fail in
> > both
> > directions: import and export - but the following
> > 
> > (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
> > 
> > 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:
> > 
> > mv build/downloads .
> > rm -rf build
> > ./build.sh basic-os (DONE)
> > ./clean.sh isar
> > ./build.sh (DONE)
> > ./clean.sh all
> > ./build.sh (DONE)
> > 
> > remove that two lines about ln -Pf that are supposed to do nothing
> > than fail
> > 
> > ./clean.sh all
> > ./build.sh (DONE with the same building time)
> > 
> > rm -rf build/downloads
> > mv downloads build
> > 
> > ./clean.sh isar
> > ./build.sh complete (FAIL)
> > 
> > put back those two command lines with ln -Pf and
> > 
> > ./clean.sh all
> > ./build.sh (DONE)
> > 
> > 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
> > 
> > However there are some other ways to do this thing:
> > 
> > 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
> > 
> > I did not make any changes because I did not identified the issue.
> > 
> > Best regards, R-
> 
> I'll try to make things clear. Isar supports local builds from 'base-
> apt' repo 
> with.
> 
> First build user does as usual.
> 
> Second build is done with the following changes (at least):
> 
> ISAR_USE_CACHED_BASE_REPO = "1"
> BB_NO_NETWORK = "1"
> 
> In this case every .deb we downloaded from Debian mirrors at first
> build goes 
> to local 'base-apt' and second build use it, but not remote mirrors.
> 
> That's the reason of using this "cp/ln magic" inside of sbuild. While
> building 
> some package, multipe dependencies might be downloaded inside of
> sbuild. And 
> we need a way to extract them from "internal" apt-cache in sbuild
> schroot and 
> put to the package workdir, where deb-dl-dir export will pass them to
> DL_DIR 
> later.
> 
> When we replace copying to hardlinks, that actually don't work due to
> different filesystems, we come to the situation, when multiple debian
> packages 
> (dependencies of what we are building or some packages that sbuild
> requires 
> itself) are not present in DL_DIR. So, second "cached" build from
> local repo 
> simply fails.
> 
> I see the following possible solutions that allows to save space.
> 1. Since hardlinks don't work, try to use symlinks.

If that works, it clearly is the simplest solution.

> 2. Don't use import with sbuild at all, but only export. But this has
> a 
> drawback, when all packages we build with sbuild might download the
> similar 
> dependencies in parallel.

A third solution might be to mount the cache into the schroot, similar
to how we handle the sstate cache today.

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.

Felix

> 
> 


  reply	other threads:[~2023-01-20  5:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06  6:48 Uladzimir Bely
2023-01-06  6:48 ` [PATCH v2 1/3] Clean apt cache from debootstrapped rootfs dirs Uladzimir Bely
2023-01-06  6:48 ` [PATCH v2 2/3] Use hardlinks in deb-dl-dir functions Uladzimir Bely
2023-01-06  6:48 ` [PATCH v2 3/3] Changes for a faster build using less disk space Uladzimir Bely
2023-01-06 15:58   ` Henning Schild
2023-01-06 17:38     ` Uladzimir Bely
2023-01-06 17:52       ` Roberto A. Foglietta
2023-01-06 18:11       ` Henning Schild
2023-01-09  6:32 ` [PATCH v2 0/3] Improving apt cache Moessbauer, Felix
2023-01-09  7:39   ` Uladzimir Bely
2023-01-19  7:36     ` Uladzimir Bely
2023-01-19 14:52       ` Roberto A. Foglietta
2023-01-19 16:30         ` Roberto A. Foglietta
2023-01-20  4:44         ` Uladzimir Bely
2023-01-20  5:08           ` Moessbauer, Felix [this message]
2023-01-20  7:01             ` Uladzimir Bely
2023-01-20  7:12               ` Roberto A. Foglietta
2023-01-20  7:23                 ` Uladzimir Bely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d28cc40f4400ad146c1568c89f87061006c83374.camel@siemens.com \
    --to=felix.moessbauer@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=roberto.foglietta@gmail.com \
    --cc=ubely@ilbers.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox