Re: [lmi] debian chroot in redhat

[Greg Chicares]

On 2019-09-25 01:15, Vadim Zeitlin wrote:
> On Fri, 20 Sep 2019 19:01:10 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-09-20 18:45, Greg Chicares wrote:
> GC> > On 2019-09-20 17:40, Vadim Zeitlin wrote:
> GC> [...]
> GC> >> Of course, there is always the "when all you have is
> GC> >> Debian, any Linux looks like an OS where you can install it in a 
> chroot"
> GC> >> approach, i.e. you could use debootstrap to create a chroot of Buster 
> on
> GC> 
> GC> Bullseye now. I may be a parochial debian fan, but I do upgrade
> GC> from time to time. Right now, I'm using buster as my main system,
> GC> because 'stable' means "stable", but I'm doing my lmi work in a
> GC> bullseye chroot.
> GC> 
> GC> >> this machine and just do everything inside it with minimal drawbacks 
> (a few
> GC> >> hundred of extra MiB of disk consumption).
> GC> > 
> GC> > Is that feasible? If so, it sounds like an excellent idea.
> 
>  I, or rather Ilya, who has tested this, can confirm that this is indeed
> feasible and _almost_ works -- there is just one mysterious problem
> remaining.
> 
>  The installation was pretty straightforward:
> 
>       # rpm -ivh 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
>       # yum install -y debootstrap.noarch
> 
>       # mkdir -p /srv/chroot/debian-stable
>       # debootstrap stable /src/chroot/debian-stable 
> http://deb.debian.org/debian/
> 
> (note that you need to have "curl" and "ca-certificates" packages installed
> for this to work, but this should already be the case on any normal RHEL
> system, even though it wasn't in my minimal CentOS installation).

Thanks--it would have taken me many hours to figure that out myself.

>  I've unfortunately forgotten to ask Ilya to test Bullseye, but I don't
> think there would be any problems with installing it in the same way
> neither.

Beware of this, if you're trying to follow the chroot-creation
instructions that I'm still developing:

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
Reading package lists...
Building dependency tree...
Package bsdtar is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  libarchive-tools:i386 libarchive-tools

E: Package 'bsdtar' has no installation candidate
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

I think replacing bsdtar with libarchive-tools will just work.

>  Of course, you also need to install the required packages into the new
> Debian chroot, but the upcoming Linux installation script will take care of
> this.

Making progress.

>  Finally, the mysterious problem mentioned in the beginning of this message
> is a failure in install_msw.sh, which somehow doesn't create
> test_coding_rules.exe, even though make log doesn't contain any errors.
> We'll look more into this, but this should definitely be fixable and, for
> now, just manually linking test_coding_rules.exe allows the build to finish
> and the resulting lmi binary happily runs under Wine.

Once I've got those 'lmi_install*.sh' scripts working well
on debian, I'll try them in a debian chroot within a centos
chroot, and see if I can reproduce this anomaly.

The log of my 20190924T2306Z run of 'install_msw.sh' contains:

  PERFORM=wine /opt/lmi/src/lmi/test_coding_rules_test.sh
  Testing 'test_coding_rules'.

once for each triplet. I'm using a proprietary set of taboos,
in a directory that the makefiles specify with 'vpath' to
override this dummy:
  https://git.savannah.nongnu.org/cgit/lmi.git/tree/my_test_coding_rules.cpp
but if there's an error in that public file, you'd probably
have noticed it.

>  So the conclusion is that it is indeed possible to work in a Debian chroot
> inside a RHEL system. This adds one more level of indirection, i.e. you
> need to enter the chroot before doing anything else, but could still be the
> most convenient way to build lmi, finally.

That's enormously encouraging. If I can get that working on
our server, then I don't have to worry about finding current
versions of tools (MinGW-w64 g++ especially); instead, I'll
have exactly the same tools on the server as on my own
computer.