Re: [lmi] Creating a chroot for cross-building lmi

[Greg Chicares]

On 2016-09-26 01:35, Greg Chicares wrote:
[...archived at
  https://lists.nongnu.org/archive/html/lmi/2016-09/msg00025.html
in case that's handier to read...]
> On 2016-09-25 21:20, Greg Chicares wrote:
[...]
> Here's an update

And here's an update for a 'bullseye' chroot, now that 'bullseye'
is debian 'testing'.

[...snip steps copied from 'README.schroot', which I'm gradually
transforming from a text file of shell snippets into a set of
executable scripts...]

> and then, entering the new chroot as root:
> 
> schroot --chroot=xlmi --user=root --directory=/
[...snip similarly...]
> root@turgon:/# mount -t devpts devpts /dev/pts
> root@turgon:/# mount -t proc proc /proc
> root@turgon:/# apt-get update
> [...snip unremarkable output...]
> root@turgon:/# apt-get --assume-yes install g++-mingw-w64-i686 automake 
> libtool make \
>>  pkg-config git zsh bzip2 unzip sudo wine >apt-get-log 2>&1
> 
> and now, examining that log as a normal user:

Here's a log of 'apt-get install [many packages]', filtered
to remove obviously uninteresting parts:

> /srv/chroot/xlmi[0]$<apt-get-log sed -e'0,/^Preconfiguring/d' 
> -e'/^Preparing\|^Unpacking\|^Configuring\|^Selecting\|^Setting 
> up\|^Processing\|^Adding\|^update-alternatives\|^(Reading database/d'

and further filtered to remove lines previously discussed
in this thread that have proven to be unimportant:

 -e'/^Running in chroot, ignoring request.$/d' \
 -e'/^update-rc.d: warning: start and stop actions are no longer supported; 
falling back to defaults$/d' \
 -e'/^invoke-rc.d: policy-rc.d denied execution of start.$/d' \
 -e'/^Warning: The home dir \/run\/uuidd you specified can.t be accessed: No 
such file or directory$/d' \
 -e'/^Not creating home directory .\/run\/uuidd..$/d' \
 -e'/^No schema files found: doing nothing.$/d' \
 -e'/^[0-9][0-9]* added, [0-9][0-9]* removed; done.$/d' \
 2>&1 |less -S

...leaving only this output:

No diversion 'diversion of /usr/sbin/update-icon-caches to 
/usr/sbin/update-icon-caches.gtk2 by libgtk-3-bin', none removed.
No diversion 'diversion of /usr/share/man/man8/update-icon-caches.8.gz to 
/usr/share/man/man8/update-icon-caches.gtk2.8.gz by libgtk-3-bin', none removed.
Replaced by files in installed package libc6:i386 (2.28-10) ...
Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 
43.
Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket → 
/lib/systemd/system/uuidd.socket.
Setcap worked! gst-ptp-helper is not suid!
Allowing use of questionable username.
Setcap worked! gst-ptp-helper is not suid!
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or 
directory

> Manually supplying context for the interesting parts:

Selecting previously unselected package gtk-update-icon-cache.
Preparing to unpack .../040-gtk-update-icon-cache_3.24.11-1_amd64.deb ...
No diversion 'diversion of /usr/sbin/update-icon-caches to 
/usr/sbin/update-icon-caches.gtk2 by libgtk-3-bin', none removed.
No diversion 'diversion of /usr/share/man/man8/update-icon-caches.8.gz to 
/usr/share/man/man8/update-icon-caches.gtk2.8.gz by libgtk-3-bin', none removed.
Unpacking gtk-update-icon-cache (3.24.11-1) ...

(I guess they're treating gtk2 as so obsolete that there's
no longer anything to divert from.)

Unpacking libc6-i386 (2.28-10) ...
Replaced by files in installed package libc6:i386 (2.28-10) ...

(Apparently an uninteresting name clash.)

Setting up unzip (6.0-25) ...
Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 
43.

(We might invoke 'unzip' directly, when we must; but we
shouldn't be using it via mime.)

invoke-rc.d: policy-rc.d denied execution of start.
Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket → 
/lib/systemd/system/uuidd.socket.

(Looks like a routine systemd message.)

Setting up libgstreamer1.0-0:amd64 (1.16.0-3) ...
Setcap worked! gst-ptp-helper is not suid!

(See:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839618
which discusses suppressing this message as being useless.)

Setting up cvs (2:1.12.13+real-27+b1) ...
Allowing use of questionable username.
Adding group `_cvsadmin' (GID 113) ...
Done.

(Looks unexciting. I use cvs only to manage the savannah
webpages repository, which was still cvs last I checked.)

Setting up ca-certificates-java (20190405) ...
head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or 
directory

(I don't imagine we need to worry about that.)