Re: [blfs-dev] Python multiprocessing checks in chroot
On 3/22/20 9:25 PM, Xi Ruoyao via blfs-dev wrote: On 2020-03-23 01:44 +, Ken Moffat via blfs-dev wrote: On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via blfs-dev wrote: On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote: # mount --bind /run /mnt/lfs/run I think it's dangerous: potentially harmful to the host. Some service running in the LFS chroot may overwrite the runtime directory of the service running on the host. So, you are saying that packages from mozilla should not now be built in chroot ? No. I think we need a better way. But, what do you mean by a service running in chroot ? I assume we are specifically talking of systemd here ? Do services not get started during the boot process ? The systemd instance in chroot has never started, so I assume it will be ineffective and systemd on the host will only care about services described in /etc/systemd ? Maybe that's not a issue. But still, /run contains lots of sockets of running services. That means now we can connect host services from the chroot environment. Even if it's not dangerous to host, it's polluting the new LFS system. Consider /run/initctl. We don't want something in chroot to switch the *host* to runlevel 1 :). What about mount -t tmpfs /run from within chroot? -- Bruce -- 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 checks in chroot
On 2020-03-23 01:44 +, Ken Moffat via blfs-dev wrote: > On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via blfs-dev wrote: > > On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote: > > > > > # mount --bind /run /mnt/lfs/run > > > > I think it's dangerous: potentially harmful to the host. Some service > > running > > in the LFS chroot may overwrite the runtime directory of the service running > > on > > the host. > > So, you are saying that packages from mozilla should not now be > built in chroot ? No. I think we need a better way. > But, what do you mean by a service running in chroot ? I assume we > are specifically talking of systemd here ? Do services not get > started during the boot process ? The systemd instance in chroot > has never started, so I assume it will be ineffective and systemd on > the host will only care about services described in /etc/systemd ? Maybe that's not a issue. But still, /run contains lots of sockets of running services. That means now we can connect host services from the chroot environment. Even if it's not dangerous to host, it's polluting the new LFS system. Consider /run/initctl. We don't want something in chroot to switch the *host* to runlevel 1 :). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- 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 checks in chroot
On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote: > > > # mount --bind /run /mnt/lfs/run > > I think it's dangerous: potentially harmful to the host. Some service running > in the LFS chroot may overwrite the runtime directory of the service running > on > the host. So, you are saying that packages from mozilla should not now be built in chroot ? But, what do you mean by a service running in chroot ? I assume we are specifically talking of systemd here ? Do services not get started during the boot process ? The systemd instance in chroot has never started, so I assume it will be ineffective and systemd on the host will only care about services described in /etc/systemd ? On a sysvinit system I have not encountered a problem, but I have no recent experience of systemd. ĸ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 checks in chroot
On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote: > # mount --bind /run /mnt/lfs/run I think it's dangerous: potentially harmful to the host. Some service running in the LFS chroot may overwrite the runtime directory of the service running on the host. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] The xc directory
Le 22/03/2020 à 22:59, Bruce Dubbs via blfs-dev a écrit : > On 3/22/20 4:47 PM, Ken Moffat via blfs-dev wrote: >> (Bcc to DJ in case he is not following everything on this list) >> >> Prompted by noticing yesterday that someone had a problem while >> trying to build mozjs60 and happened to be building that in the xc >> directory - >> >> In 'Introduction to Xorg-7' we say: >> >> First, you'll need to create a working directory: >> >> mkdir xc && >> cd xc >> >> But we never actually go out of those directories anywhere in the >> book. I have not created an xc/ directory for building in _many_ >> years. >> >> From memory, DJ introduced this directory in the days when Xorg was >> transitioning from the old monolithic "everything in one tarball" to >> the current "many separate packages" approach, perhaps releases 6.8 >> (old-style) and 6.9 (new-style). The purpose was to ensure that >> nothing which was compiled in the old approach had been omitted from >> the new approach. >> >> I think the time to remove the xc directory is long overdue. But as >> always, I might be missing something. comments welcome, >> particularly from DJ. > > I do have my sources in an xc directory, but that only has other directories > within it. For me it's a convenience, but it is certainly not needed in the > book. I'm OK with removing it. > Ok too. Since xc is only mentioned in the Introduction, and not in the packages pages, an automated builder such as jhalfs does not use it. 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] The xc directory
On 3/22/20 4:47 PM, Ken Moffat via blfs-dev wrote: (Bcc to DJ in case he is not following everything on this list) Prompted by noticing yesterday that someone had a problem while trying to build mozjs60 and happened to be building that in the xc directory - In 'Introduction to Xorg-7' we say: First, you'll need to create a working directory: mkdir xc && cd xc But we never actually go out of those directories anywhere in the book. I have not created an xc/ directory for building in _many_ years. From memory, DJ introduced this directory in the days when Xorg was transitioning from the old monolithic "everything in one tarball" to the current "many separate packages" approach, perhaps releases 6.8 (old-style) and 6.9 (new-style). The purpose was to ensure that nothing which was compiled in the old approach had been omitted from the new approach. I think the time to remove the xc directory is long overdue. But as always, I might be missing something. comments welcome, particularly from DJ. I do have my sources in an xc directory, but that only has other directories within it. For me it's a convenience, but it is certainly not needed in the book. I'm OK with removing it. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] The xc directory
(Bcc to DJ in case he is not following everything on this list) Prompted by noticing yesterday that someone had a problem while trying to build mozjs60 and happened to be building that in the xc directory - In 'Introduction to Xorg-7' we say: First, you'll need to create a working directory: mkdir xc && cd xc But we never actually go out of those directories anywhere in the book. I have not created an xc/ directory for building in _many_ years. From memory, DJ introduced this directory in the days when Xorg was transitioning from the old monolithic "everything in one tarball" to the current "many separate packages" approach, perhaps releases 6.8 (old-style) and 6.9 (new-style). The purpose was to ensure that nothing which was compiled in the old approach had been omitted from the new approach. I think the time to remove the xc directory is long overdue. But as always, I might be missing something. comments welcome, particularly from DJ. ĸ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
[blfs-dev] Python multiprocessing checks in chroot
This weekend we had a problem where someone was trying to build mozjs60 in chroot and failed. I've seen this myself on some of the rare occasions I've built desktops in chroot. Key facts: 1. The solution is (as root, on the *host* system) bind /mnt/lfs/run to /run, i.e. # mount --bind /run /mnt/lfs/run 2. Where this is required, the error messages will say OSError: [Errno 38] Function not implemented and a few lines above that will be a mention of multiprocessing. Usually I don't build the desktop in chroot, but maybe a few tiems a year I have found that appropriate for testing. On my current laptop this also seems to be the easiest approach (at least until xfce and network-manager-applet are in place). I first saw this when building firefox 53 in 2017, and I'd assumed it was covered somewhere in one of the books - but now, I don't think it is mentioned. If that is so, I guess it would be useful to add an extra copy member for it, to include in a Note for the affected packages. Something like (using '*' to show things to be emphasised) "If you are building in chroot, on the *host* system you must ensure /mnt/lfs/run in LFS is bind-mounted, otherwise the configuration will report OSError: [Errno 38] Function not implemented and a few lines above that it will mention the python multiprocessing package. Work around this by, *on the host system*, as root, executing: mount --bind /run /mnt/lfs/run " Does that sound ok ? Will it need any massaging to stop jhalfs trying to run it as a matter of course ? If ok, I think the following need it: mozjs60 mozjs68 when it goes in (unless the python devs have completely changed how their multiprocessing module tests the system) node-js firefox seamonkey thunderbird I can do this, but I'm not sure if I've maybe overlooked something that already covers this ? ĸ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] Systemd config info for bridgeutils
Le 22/03/2020 à 21:41, Douglas R. Reno via blfs-dev a écrit : > > On 3/22/20 6:10 AM, Pierre Labastie via blfs-dev wrote: >> Hi, >> Message for systemd devs: There is a "TBA" for bridge-utils configuration in >> the systemd book. Should I create a ticket? Or just remove that section? >> >> Pierre > I'd say remove that section for now. I'm not certain on how to configure > bridging using networkd at the moment Will comment out, so that it can easily be reintroduced later 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] Systemd config info for bridgeutils
On 3/22/20 6:10 AM, Pierre Labastie via blfs-dev wrote: Hi, Message for systemd devs: There is a "TBA" for bridge-utils configuration in the systemd book. Should I create a ticket? Or just remove that section? Pierre I'd say remove that section for now. I'm not certain on how to configure bridging using networkd at the moment -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Systemd config info for bridgeutils
Hi, Message for systemd devs: There is a "TBA" for bridge-utils configuration in the systemd book. Should I create a ticket? Or just remove that section? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
