Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Sat, Mar 28, 2020 at 08:37:19AM +0100, Pierre Labastie via blfs-dev wrote: > On Sat, 2020-03-28 at 01:48 +, Ken Moffat via blfs-dev wrote: > > On Fri, Mar 27, 2020 at 08:26:39PM +0100, Pierre Labastie via > > blfs-dev wrote: > > > On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > > > > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via > > > > blfs- dev wrote: > > > > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev > > > > > wrote: > > > > > > > I see you are moving away from saying /bin/sh which we have in the > > current firefox note. Are you using dash or zsh on the quiet ? > > (joke/). I can see we don't accomodate tcsh (setenv SHELL /bin/tcsh > > or similar) and certainly not fish (env SHELL=/usr/bin/fish command > > - I guess). > > > > Just wanted to tell that "/bin/bash" can be used. Actually, dash can > certainly be used too (I've come to the conclusion long ago, that > recent dash is perfectly suitable for lfs, but for some reason the > debian maintainer does not want to use recent dash, so lfs fails to > build on debian+dash). > > No experience with zsh, and I guess tcsh might be not enough POSIX > compliant (but not tried either). We do not propose fish in the book, > do we? > > Pierre > I assume that last sentence was a rhetorical question, my comments were intended as a joke. Anyway, I've committed r22928 now, with one paragraph for the common /dev/shm part (the DTD says that xincludes can only contain one paragraph - possibly an included note can contain more paragraphs, , but I want a separate paragraph for the SHELL part, within the same note). For the SHELL part I've kept to /bin/sh because we've used that everywhere until now. The mountpoint command is marked as "nodump". I've probably pissed off someone be commenting the one-line entity for the SHELL note in the js pages, and replacing that with the two-part note. For seamonkey the second part is hardcoded at the moment. The differnece should be that firefox and thunderbird refer to prepending shell to the mach commands (sic, I wasn't clear if both needed it when SHELL has not been exported), seamonkey refers to the first make, and the JS pages refer to the configure command. ĸen -- OMG!!! Ponies!!! -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Sat, 2020-03-28 at 01:48 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 08:26:39PM +0100, Pierre Labastie via > blfs-dev wrote: > > On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > > > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via > > > blfs- dev wrote: > > > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev > > > > wrote: > > > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > > > _exported_. It can be set to /bin/bash without problem. And > > > > for me, it is not exported for _root_ after entering chroot > > > > (but it is set): root [ / ]# echo $SHELL /bin/bash root [ > > > > / ]# env | grep SHELL root [ / ]# Now when doing su - > > > > pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ > > > > env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need > > > > to set/export anything as a user. And SHELL only needs to be > > > > exported as root. Pierre > > > > > > > > > > I'm puzzled by that - if it is not set, the configure breaks. > > > Does SHELL also get queried when root is running the install ? > > > > > > > > > > When it is set, but not exported, it's not set in ./wmach, so not > > found... So I'd just suggest something like: Second, you should > > ensure that the SHELL variable is set and exported to the > > environment, possibly by prepending SHELL= to the > > .mach command. > > > > Pierre > > > I see you are moving away from saying /bin/sh which we have in the > current firefox note. Are you using dash or zsh on the quiet ? > (joke/). I can see we don't accomodate tcsh (setenv SHELL /bin/tcsh > or similar) and certainly not fish (env SHELL=/usr/bin/fish command > - I guess). > Just wanted to tell that "/bin/bash" can be used. Actually, dash can certainly be used too (I've come to the conclusion long ago, that recent dash is perfectly suitable for lfs, but for some reason the debian maintainer does not want to use recent dash, so lfs fails to build on debian+dash). No experience with zsh, and I guess tcsh might be not enough POSIX compliant (but not tried either). We do not propose fish in the book, do we? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, Mar 27, 2020 at 08:26:39PM +0100, Pierre Labastie via blfs-dev wrote: > On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via > > blfs- dev wrote: > > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev > > > wrote: > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > > _exported_. It can be set to /bin/bash without problem. And > > > for me, it is not exported for _root_ after entering chroot > > > (but it is set): root [ / ]# echo $SHELL /bin/bash root [ > > > / ]# env | grep SHELL root [ / ]# Now when doing su - > > > pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ > > > env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need > > > to set/export anything as a user. And SHELL only needs to be > > > exported as root. Pierre > > > > > > > I'm puzzled by that - if it is not set, the configure breaks. > > Does SHELL also get queried when root is running the install ? > > > > > > When it is set, but not exported, it's not set in ./wmach, so not > found... So I'd just suggest something like: Second, you should > ensure that the SHELL variable is set and exported to the > environment, possibly by prepending SHELL= to the > .mach command. > > Pierre > I see you are moving away from saying /bin/sh which we have in the current firefox note. Are you using dash or zsh on the quiet ? (joke/). I can see we don't accomodate tcsh (setenv SHELL /bin/tcsh or similar) and certainly not fish (env SHELL=/usr/bin/fish command - I guess). Maybe: "Second, you should ensure that the SHELL environment variable is set to point to your shell and exported (e.g. for the common case using bash, export SHELL=/bin/sh) or alternatively prepend SHELL= when compiling." But my 'when compiling' can still be misinterpreted - although firefox and thunderbird use ./mach, seamonkey uses the old make -f client.mk and both versions of JS use ../js/src/configure. I picked the word compiling because we tend to say 'Compile by running the following command(s).' And I would really like to use a common xincludes for all the affected mozilla packages. Perhaps three versions (for mach, client.mk, js/configure) is the only way to be accurate. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via blfs- > dev wrote: > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > > > The thread Python multiprocessing checks in chroot is getting > > > long > > > and widening to cover how /dev/shm is treated in LFS. > > > > > > What I'd like to do is put the following note in the BLFS > > > mozilla-derived packages where shm needs to be mounted when the > > > package is configured: > > > > > > - - - > > > If you are compiling this package in chroot you must do two > > > things: > > > > > > First, as the root user, ensure that /dev/shm is mounted: > > > > > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm > > > /dev/shm > > > > > > If you do not do this, configuring will fail with a python > > > traceback > > > report referencing a > > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > > file. > > > > > > Second, as your normal user either ensure the $SHELL environment > > > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > > > - - - > > > > > > Is that acceptable to everyone ? > > > > > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > _exported_. It can be set to /bin/bash without problem. And for me, > > it > > is not exported for _root_ after entering chroot (but it is set): > > > > root [ / ]# echo $SHELL > > /bin/bash > > root [ / ]# env | grep SHELL > > root [ / ]# > > > > Now when doing su - > > > > pierre [ ~ ]$ echo $SHELL > > /bin/bash > > pierre [ ~ ]$ env | grep SHELL > > SHELL=/bin/bash > > pierre [ ~ ]$ > > > > So no need to set/export anything as a user. And SHELL only needs > > to be > > exported as root. > > Pierre > > > > I'm puzzled by that - if it is not set, the configure breaks. Does > SHELL also get queried when root is running the install ? > > When it is set, but not exported, it's not set in ./wmach, so not found... So I'd just suggest something like: Second, you should ensure that the SHELL variable is set and exported to the environment, possibly by prepending SHELL= to the .mach command. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via blfs-dev wrote: > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > > The thread Python multiprocessing checks in chroot is getting long > > and widening to cover how /dev/shm is treated in LFS. > > > > What I'd like to do is put the following note in the BLFS > > mozilla-derived packages where shm needs to be mounted when the > > package is configured: > > > > - - - > > If you are compiling this package in chroot you must do two things: > > > > First, as the root user, ensure that /dev/shm is mounted: > > > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm > > > > If you do not do this, configuring will fail with a python traceback > > report referencing a > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > file. > > > > Second, as your normal user either ensure the $SHELL environment > > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > > - - - > > > > Is that acceptable to everyone ? > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > _exported_. It can be set to /bin/bash without problem. And for me, it > is not exported for _root_ after entering chroot (but it is set): > > root [ / ]# echo $SHELL > /bin/bash > root [ / ]# env | grep SHELL > root [ / ]# > > Now when doing su - > > pierre [ ~ ]$ echo $SHELL > /bin/bash > pierre [ ~ ]$ env | grep SHELL > SHELL=/bin/bash > pierre [ ~ ]$ > > So no need to set/export anything as a user. And SHELL only needs to be > exported as root. > Pierre > I'm puzzled by that - if it is not set, the configure breaks. Does SHELL also get queried when root is running the install ? ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > The thread Python multiprocessing checks in chroot is getting long > and widening to cover how /dev/shm is treated in LFS. > > What I'd like to do is put the following note in the BLFS > mozilla-derived packages where shm needs to be mounted when the > package is configured: > > - - - > If you are compiling this package in chroot you must do two things: > > First, as the root user, ensure that /dev/shm is mounted: > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm > > If you do not do this, configuring will fail with a python traceback > report referencing a > /usr/lib/pythonN.N/multiprocessing/synchronize.py > file. > > Second, as your normal user either ensure the $SHELL environment > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > - - - > > Is that acceptable to everyone ? > > Sorry for arguing again. The problem is that SHELL needs to be _exported_. It can be set to /bin/bash without problem. And for me, it is not exported for _root_ after entering chroot (but it is set): root [ / ]# echo $SHELL /bin/bash root [ / ]# env | grep SHELL root [ / ]# Now when doing su - pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need to set/export anything as a user. And SHELL only needs to be exported as root. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On 3/27/20 11:02 AM, Ken Moffat via blfs-dev wrote: The thread Python multiprocessing checks in chroot is getting long and widening to cover how /dev/shm is treated in LFS. What I'd like to do is put the following note in the BLFS mozilla-derived packages where shm needs to be mounted when the package is configured: - - - If you are compiling this package in chroot you must do two things: First, as the root user, ensure that /dev/shm is mounted: mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm If you do not do this, configuring will fail with a python traceback report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py file. Second, as your normal user either ensure the $SHELL environment variable is set to /bin/sh, or prepend SHELL=/bin/sh. - - - Is that acceptable to everyone ? It seems like the best approach to me. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Python multiprocessing in chroot, proposed note V2
The thread Python multiprocessing checks in chroot is getting long and widening to cover how /dev/shm is treated in LFS. What I'd like to do is put the following note in the BLFS mozilla-derived packages where shm needs to be mounted when the package is configured: - - - If you are compiling this package in chroot you must do two things: First, as the root user, ensure that /dev/shm is mounted: mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm If you do not do this, configuring will fail with a python traceback report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py file. Second, as your normal user either ensure the $SHELL environment variable is set to /bin/sh, or prepend SHELL=/bin/sh. - - - Is that acceptable to everyone ? ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
