Re: [blfs-support] Issue installing Python2 module for Jinja2-2.10.1

Tue, 17 Sep 2019 05:48:07 -0700

 
 
Sent: Tuesday, September 17, 2019 at 5:59 PM
From: "Jared Stevens via blfs-support" <[email protected]>
To: "BLFS Support List" <[email protected]>
Cc: "Jared Stevens" <[email protected]>
Subject: Re: [blfs-support] Issue installing Python2 module for Jinja2-2.10.1
 
 
On Mon, Sep 16, 2019 at 3:00 AM Christopher Gregory via blfs-support <[email protected]> wrote:


> Sent: Monday, September 16, 2019 at 3:29 PM
> From: "Pierre Labastie via blfs-support" <[email protected]>
> To: [email protected]
> Cc: "Pierre Labastie" <[email protected]>
> Subject: Re: [blfs-support] Issue installing Python2 module for Jinja2-2.10.1
>
> On 16/09/2019 03:14, Jared Stevens via blfs-support wrote:
> > (If I am continuing to top-post still, would someone be able to tell me the
> > proper way to reply to the thread? Currently, I am simply clicking "Reply" in
> > Gmail to the latest email in the thread that I have)
> >
> > Just to provide an update for you all, I uninstalled Python 2 and reinstalled
> > it along with all modules in the book (without pip) with no change.
>
> For me, after installing MarkupSafe 1.1.1 for python2 with the book
> instructions (recently added in trunk, amount to what you have below), Jinja2
> finds it.
>
> >
> > So after digging deeper into the log, I decided to visit Debian's package
> > repository site for their Jessie distribution and downloaded the source
> > tarbell for MarkupSafe-0.23 just for the heck of it.
> >
> > I installed it identically to how the book installs MarkupSafe-1.1.1 except I
> > installed the Python 2 module instead like so:
> >
> > `python2 setup.py build &&
> >
> > python2 setup.py install --optimize=1`
> >
> >
>
> What is the difference with what was in the book (apart from the obvious one
> which is to use python2)? Have you used those instructions for MarkupSafe
> 1.1.1 (with python2, I mean)?
>
> > Afterwards, I attempted the Jinja2 module install again. This time, it was
> > able to "see" the MarkupSafe module and used 1.1.1 to successfully install the
> > Python 2 module.
>
> Could it be that, for some reason, easy-install.pth had not been updated when
> installing MarkupSafe 1.1.1, but got updated when installing 0.23?
>
> >
> > So it appears that installing MarkupSafe-0.23 allows for Jinja2 to find the
> > most recent version of MarkupSafe installed (which is 1.1.1) when building the
> > Python 2 module.
>
> I understand you are building in chroot. Does the network name resolution
> work? Maybe you have to edit /etc/resolv.conf. That may allow resolving the
> name for pypi.
>
> Pierre
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

Hello,

With regards to chroot, if you are using the systemd version of the book, there is no resolv.conf file, as it is a symlink to a differnet directory.  I always remove the symlink and create a proper resolv.conf in /etc and this allows me to use the "host" ineternet connection.

Regards,

Christopher.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
 
(I am attempting the suggested "triple vertical dots" reply in Gmail suggestion-- hopefully this works otherwise I will use a different method of replying.)
 
Thanks all for the suggestions!
 
I believe Bruce's suggested command to fix a possible missed step when building glibc has solved the last issue with QT5WebEngine:
 
`sed -i '/asm.socket.h/a# include <linux/sockios.h>' \
    /usr/include/bits/socket.h`
 
Also, thanks so much Christopher for the resolv.conf in the chroot environment suggestion!
 
I was able to remove the symlink and then simply copy over my local system's existing resolv.conf file and now I can access the network within chroot. You are a lifesaver (or at least a timesaver for sure lol).
 
This time, the build got frustratingly close to the end (11172/12514) before I received yet another fatal error. Apparently, my LFS system ran out of space on the drive while it was creating the thousands of temp files for the build:
 
as: BFD (GNU Binutils) 2.32 assertion fail ../../bfd/elf.c:3103
{standard input}: Fatal error: can't close obj/gpu/command_buffer/service/gles2_sources/gles2_sources_jumbo_2.o: No space left on device
ninja: build stopped: subcommand failed.
make[3]: *** [Makefile.gn_run:353: run_ninja] Error 1
make[3]: Leaving directory '/sources/qtwebengine-everywhere-src-5.13.0/build/src/core'
make[2]: *** [Makefile:82: sub-gn_run-pro-make_first] Error 2
make[2]: Leaving directory '/sources/qtwebengine-everywhere-src-5.13.0/build/src/core'
make[1]: *** [Makefile:78: sub-core-make_first] Error 2
make[1]: Leaving directory '/sources/qtwebengine-everywhere-src-5.13.0/build/src'
make: *** [Makefile:49: sub-src-make_first] Error 2
 
Following this error, the chroot environment is rendered useless as every command returns a bash error. For example:
 
`$ ls /tmp/
bash: ls: command not found`
 
The only solution is to logout of chroot, unmount the disk (had to hard unmount as regular gave "target is busy" message), and remount and open chroot again.
 
Here is the output for `df -h` for my LFS system:
 
`$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdd2       442G  101G  319G  24% /
udev            5.8G     0  5.8G   0% /dev
tmpfs           5.8G     0  5.8G   0% /run`
 
The drive is 500 GB in total size with roughly 480 GB allocated in a partition for root with the remaining drive space dedicated to my EFI vfat partition (500 MB) and the swap partition (16 GB).
 
I am led to believe that the build attempted to create all of the necessary files in the tmpfs filesystem and simply ran out of space out of the given 5.8 GB, but I am not certain. I hope it did not manage to completely fill the root partition of the available 319 GB at the time.
 
I guess my next step would be to increase the total size of the tmpfs filesystem to prevent the build from running out of space, but how would I do that.
 
If this issue with the build running out of space is resolved, I believe the suggested fix above would allow for the build to finally complete as expected.
 
Thanks!
 
Jared Stevens
 
Hello Jared,
 
At this stage I would suggest, that as you have the "base" lfs system installation complete, that you actually try and boot into it, just to make sure that everything is correctly working. 
 
You could install lynx and download a copy of the blfs book and use it locally.  That way you can ensure that nothing weird is happening with regards to disk space.  That really is the safest way when you have multiple os's installed.  Just make sure that you add the lfs kernel line into your existing grub.cfg file on your debian/ubuntu installation.
 
I would suggest editing the grub.cfg file manually rather than using update-grub or such tools.
 
Regards,
 
Christopher.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to