bind mount (and anything invoking mount) requires root privilege, except for fusemount and some removable medium use cases - even that is often disabled based on site policy. Using proot-me seems to be no better than the original poster's - depending on a peculiar way of doing things maintained by a small set of individuals... The sort of thing that the initial poster tries to do, is to use a combination of docker / CI on github and other free-hosting dev platform with docker CI runners, or something like that. https://github.com/actions/runner-images
I personally use docker against the ubuntu runner to grab a fefora linux docker image, and build fedora stuff there inside a fedora container running on a ubuntu host: https://github.com/HinTak/Qt6WE-OT-SVG/blob/10937a258aa3bd90533f4b9d6f67b0c61ca435e4/.github/workflows/ci.yml#L14 And here is arch linux's: https://github.com/archlinux/archlinux-docker And please stop posting links on the academic papers and promoting your papers. Not interested... On Friday, 3 May 2024 at 18:38:53 BST, Matsumura, George <gm960...@ohio.edu> wrote: Greetings, I hope this is relevant and not besides the point, but I was thinking that you may be able to use proot to bind mount your shell to /bin/sh without root privileges: https://proot-me.github.io/ Hopefully this would also be useful in other situations where the SHELL environment variable is not used. Regards, George On 5/3/24 06:37, Mohammad Akhlaghi wrote: >> But you still doesn't show us an *exact* recipe or log files that >> demonstrates the problem you encounter. > > Below you can see the error: (the Readline library that '/bin/sh' needed > was more recent than our custom Readline installation; so '/bin/sh' > could not find the function it needed within our closed environment) > > /bin/sh: symbol lookup error: /bin/sh: undefined symbol: > rl_trim_arg_from_keyseq > > In our general build system for GNU-based builds (including FreeType), > we have an 'export SHELL=/path/to/custom/bash' just before calling the > './configure' script; and they would all take the 'SHELL' environment > into account during the build; so the error above didn't happen for > them. But in FreeType, we noticed that the only way we could ask it to > use our custom shell was through the 'GNUMAKE' variable. > > It would be great if the configure script can let the user specify the > shell to be used for the build in the standard way (through the 'SHELL' > environment variable). > >> Reproducibility is not equal to determinism. > > All terms and goals are precisely defined in the paper (here is the > arXiv link of the paper with no non-free Javascript): > https://arxiv.org/abs/2006.03018 > >> I dare say your problem does not happen to thousands of Arch Linux >> users who try to compile freetype. > > This problem would happen to anyone who used older versions of > https://maneage.org/. It is independent of the operating system (we build > FreeType at a time that the Maneage environment is fully closed-off from > the host). > >> you are aware that GNU Bash itself behaves differently, depending >> on what you call the binary, right? > > Thanks for the reminder on this ;-). But that is not the problem because > as mentioned before '/bin/sh' fails to link/execute at all (see error > message that is quoted above). > >> You are basically trying to do what another project "Linux from >> Scratch", tried to do 10+ years ago > > We did indeed get a lot of help from the wonderful documentation of > Linux From Scratch for the very low-level tools (we also build GCC and > GNU Binutils for example). But I would say it that Maneage is more > similar to Gentoo or GNU Guix, since it executes the scripts to build > the custom software from source automatically: no manual intervention is > necessary. Its core difference with Gentoo or GNU Guix is that it > doesn't build the Kernel and does not need root permission. This is > fully described in the paper: > https://arxiv.org/abs/2006.03018 > >> randomly changing LD_LIBRARY_PATH and other environment variables > > Nothing is random in the changes we make! > >> ... a lot of requests to the community of the form of: "I want to >> build your software my funny way, why doesn't it work?" > > My original comment was not saying this! I found the fix with a > non-standard way and there is no more problem on the Maneage side. The > reason I contacted you was that the standard solution (to set the > 'SHELL' environment variable) worked on +100 other software, it was only > FreeType and two or three other packages that need some non-standard fix. > >> The typical Linux system has thousands of packages... (last I >> count, 9000+ on fedora). Have fun going through the rest.. > > Maneage is not meant to be a full operating system! Only a closed > environment for batch (non-interactive and non-GUI) scientific > operations. Here are the current list of software that we build: > > https://git.maneage.org/project.git/tree/reproduce/software/config/versions.conf > > Cheers, > Mohammad > > >
