[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Creating an lmi schroot from scratch [Was: wx-dependent gcc warnin
From: |
Greg Chicares |
Subject: |
[lmi] Creating an lmi schroot from scratch [Was: wx-dependent gcc warnings] |
Date: |
Tue, 9 Jun 2020 20:29:25 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 2020-06-09 15:27, Vadim Zeitlin wrote:
> On Tue, 9 Jun 2020 11:41:24 +0000 Greg Chicares <gchicares@sbcglobal.net>
> wrote:
>
> GC> > And of course it's easy to find all diagnostics that are inhibited
> GC> > by '-isystem' for wx, by moving one line:
>
> BTW, I'm still not sure what exactly should I do to build lmi in its own
> chroot so that it doesn't interfere with anything in my main system (and
> notably doesn't require me to install anything into /opt or anywhere
> outside of my home directory), which is why I hadn't done this myself. I'm
> waiting for the stabilization of the lmi build scripts before trying to do
> it, could you please let me know when should I try to test them?
I think this will work for you:
su
cd /tmp
wget -N -nv https://git.savannah.nongnu.org/cgit/lmi.git/plain/lmi_setup_00.sh
chmod +x lmi_setup_00.sh
time flavor=centos ./lmi_setup_00.sh >/srv/cache_for_lmi/logs/chroot_log_$(date
-u +"%Y%m%dT%H%MZ") 2>&1
It's been my habit to do that as root, but I believe you could just as
well do it as a normal user, adding "sudo" on the last line, e.g.:
sudo flavor=centos ./lmi_setup_00.sh
It doesn't really matter if you run it with 'time' or redirect output.
I assume you've already installed both 'curl' and 'wget'.
The script that's downloaded manually with wget, uses wget to download
other scripts with similar names. If you have files in /tmp that you
want to preserve, with names matching
lmi_setup_*.sh
install_msw.sh
schroot_env
.zshrc
.vimrc
en.utf-8.add
then this script will overwrite them; I think it's reasonable to assume
that's not a problem.
In 'lmi_setup_02c.sh', I wasn't sure how to avoid accidental harm when
obliterating any previously-created centos chroot, so for safety it
just halts for you. Here's the dangerous code:
grep centos /proc/mounts | cut -f2 -d" " | xargs --no-run-if-empty umount
rm -rf /srv/chroot/centos7lmi
rm /etc/schroot/chroot.d/centos7lmi.conf
especially the first line, which destroys any mount containing the
string 'centos'. I could make that more specific--the mounts that this
script would create are:
/srv/chroot/centos7lmi/var/cache/yum
/srv/chroot/centos7lmi/var/cache/bullseye
/srv/chroot/centos7lmi/srv/cache_for_lmi
/srv/chroot/centos7lmi/dev/pts
/srv/chroot/centos7lmi/proc
/srv/chroot/centos7lmi/srv/chroot/lmi_bullseye_2/var/cache/apt/archives
/srv/chroot/centos7lmi/srv/chroot/lmi_bullseye_2/srv/cache_for_lmi
/srv/chroot/centos7lmi/srv/chroot/lmi_bullseye_2/dev/pts
/srv/chroot/centos7lmi/srv/chroot/lmi_bullseye_2/proc
so I suppose I should grep for "centos7lmi" in /proc/mounts instead.
I'll commit that change locally, and provide an omnibus patch below
including any other changes that occur to me while writing this email.
I'm assuming you're using a debian-based system. Probably the script
should check for that before invoking 'apt-get install rinse', but
that should fail safely on a non-debian system (and all these scripts
use 'set -e', so they halt on failure...but for 'lmi_setup_inc.sh'
(see below), I assume without testing that
set -evx
... "e" is enabled here
set +vx
... "e" is still enabled here
right?).
I assume you won't mind that this suite of scripts installs 'rinse'.
or that it creates:
/var/cache/centos_lmi/
/etc/schroot/chroot.d/centos7lmi.conf
/srv/chroot/
/srv/cache_for_lmi
All new directories in system directories contain the substring "lmi"
except in /srv : 'schroot' by default creates a /chroot/ directory
there.
These scripts can create a debian-testing chroot directly on a debian
or redhat system, but I'm suggesting you create a debian-within-centos
chroot ("flavor=centos"). The extra overhead isn't much, and it's
nicely isolated: all the potentially-dangerous stuff happens in the
intermediate centos chroot, and you can see it all in advance by
reading
lmi_setup_00.sh
lmi_setup_00c.sh
and the couple of short and harmless scripts they run directly
(but see the caution on 'lmi_setup_02c.sh' above). Everything else
is done in a chroot, so your base system is pretty well insulated.
Here's a diff with untested changes described above:
----8<----8<----8<----
diff --git a/lmi_setup_00c.sh b/lmi_setup_00c.sh
index e1f03747..52b4b716 100755
--- a/lmi_setup_00c.sh
+++ b/lmi_setup_00c.sh
@@ -31,6 +31,8 @@ assert_not_chrooted
./lmi_setup_02c.sh
+mkdir -p /etc/schroot/chroot.d
+
cat >/etc/schroot/chroot.d/centos7lmi.conf <<EOF
[centos7lmi]
description=centos-7.7
diff --git a/lmi_setup_02c.sh b/lmi_setup_02c.sh
index 4e30dcb3..5e625653 100755
--- a/lmi_setup_02c.sh
+++ b/lmi_setup_02c.sh
@@ -43,7 +43,7 @@ if [ "greg" != "$(logname)" ]; then
exit 1
fi
-grep centos /proc/mounts | cut -f2 -d" " | xargs --no-run-if-empty umount
+grep centos7lmi /proc/mounts | cut -f2 -d" " | xargs --no-run-if-empty umount
rm -rf /srv/chroot/centos7lmi
rm /etc/schroot/chroot.d/centos7lmi.conf
diff --git a/lmi_setup_inc.sh b/lmi_setup_inc.sh
index 5e2b1342..4fa08464 100755
--- a/lmi_setup_inc.sh
+++ b/lmi_setup_inc.sh
@@ -28,7 +28,7 @@
# Variables defined but unused here: this file should only be sourced.
# shellcheck disable=SC2034
-set -vx
+set -evx
CODENAME=bullseye
CHRTVER=2
---->8---->8---->8----
- Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers, Vadim Zeitlin, 2020/06/08
- Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers, Greg Chicares, 2020/06/08
- Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers, Vadim Zeitlin, 2020/06/08
- Re: [lmi] [lmi-commits] master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers, Greg Chicares, 2020/06/08
- [lmi] wx-dependent gcc warnings [Was: master 1372a42 6/7: Use '-isystem' to suppress warnings in third-party headers], Greg Chicares, 2020/06/09
- [lmi] wxPdf-dependent gcc warnings [Was: wx-dependent gcc warnings], Greg Chicares, 2020/06/09
- Re: [lmi] wx-dependent gcc warnings, Vadim Zeitlin, 2020/06/09
- [lmi] Creating an lmi schroot from scratch [Was: wx-dependent gcc warnings],
Greg Chicares <=
- Re: [lmi] Creating an lmi schroot from scratch, Vadim Zeitlin, 2020/06/09
- Re: [lmi] Creating an lmi schroot from scratch, Greg Chicares, 2020/06/09