Re: [lmi] Getting rid of the rest of Boost

[Greg Chicares]

On 10/4/21 11:18 PM, Vadim Zeitlin wrote:
> On Mon, 4 Oct 2021 23:07:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 10/3/21 10:13 PM, Vadim Zeitlin wrote:
[...]
> GC> > I've also fixed the problem with
> GC> > the bad ownership of /opt/lmi/local directory, which somehow ended up 
> being
> GC> > owned by root, breaking the MSW cross-build using the official 
> makefiles as
> GC> > it couldn't create gcc-x86_64-pc-linux-gnu subdirectory there.

Having so recently rerun './install_msw.sh' in a way that first calls
'make eviscerate' and then rebuilds everything, I thought I'd search
its output log for a clue. I found this:

+ [ ! -x /opt/lmi/src/lmi/third_party/libxml2/configure ]
+ mkdir --parents /opt/lmi/local/gcc_x86_64-pc-linux-gnu/xml-ad_hoc/libxml2
+ cd /opt/lmi/local/gcc_x86_64-pc-linux-gnu/xml-ad_hoc/libxml2
+ eval echo $libxml2_options

where 'mkdir --parents /opt/lmi/local/gcc_...' is the first command
in that log that creates any '/opt/lmi/local/' directory.

That command seems to be the likeliest culprit. 'install_xml_libraries.sh'
uses autotools, which might somehow know that the real user is root,
even though you use 'setpriv'.

>  FWIW I couldn't reproduce it locally neither, but without the commit
> mentioned above, the CI build failed because the "Check concinnity and
> physical closure" step failed to create the directory.

That's where the problem becomes evident, but presumably the root cause
lies upstream--perhaps when libxml2 is built.

> And debugging this
> (in the CI environment, i.e. by temporarily adding "ls -l" commands to this
> step) showed that it failed because /opt/lmi/local belonged to root,
> somehow.

Do CI builds use the 'lmi_setup*.sh' apparatus? If so, they should
produce logs automatically, and package them in a tarball:

# Copy log files that may be useful for tracking down problems with
# certain commands whose output is voluminous and often uninteresting.
# Archive them for easy sharing.

If you have such a log, please send it to my personal email, and
I'll compare it to my logs.

> But even though I don't know why/how did it happen, I am still
> almost sure that it's specific to the CI environment, which is rather
> special, as I run the commands inside a Debian Docker container using
> /usr/bin/setpriv to ensure that they run with the correct user -- because
> by default everything would run as root, and I didn't want that. Maybe my
> setpriv options are not completely correct, but I remember spending quite
> some time on getting them at least approximately right, so I don't really
> want to change them again, and the workaround is not too bad, so I'm sorely
> tempted to just leave this mystery alone, for once.

That may indeed be an idiosyncratic problem specific to the CI
environment, in which case an idiosyncratic solution is fine.
My concern is that it may be a general problem. I know that there
is some permissions problem on our GNU/Linux server, and that it
has something to do with autotoolized libraries such as libxml2.
I need to solve that problem anyway; perhaps this is related.