Re: [blfs-book] Awaiting the demise of python2
On Mon, 2019-12-16 at 20:37 +, Ken Moffat via blfs-book wrote: > Following on from my earlier posts on JS60 (mozjs), I've now > completed my build of those parts of my normal desktop which will > build with python -> python3 and python-config to python3-config. > > Usable it is not. > > I had seen gradual progress on various mozilla meta-bugs and hoped > that our builds might now be achievable, but that hope was misplaced. > > For people who read my earlier thread about problems in JS60 : the > code using python2 was because I'd been testing on a 9.0 system but > had forgotten to hide python2. With that addressed, JS60 then > failed during its configure with a syntax error in one of the items > I'd copied from the 52.4 patch. Gave up on that, came back to the > latest python3-only system to see what I could establish. > > Summary - > > The good: > > > Libreoffice-6.3.3.2 seems to build correctly with system python 3.8. > I guess this is because fedora/redhat pay a developer to work on LO. > > The bad: > --- > > Mozilla packages - none of JS60 nor firefox-68.3.0|71.0|72.0b6 will > build with python3. I had seen there were still some items > outstanding in their meta tickets, but I'd hoped that our build > method without tests might now complete. It doesn't, I'm now > dubious that firefox-68.4.0esr will be an adequate basis for > spidermonkey (mozjs) with python3. It seems unlikely that either > seamonkey or thunderbird will compile without python2 in the near > future. > > QtWebengine - even with 5.14.0 python2 (>= 2.7.5) is required. > Without that none of the webengine components ("modules") wil lbe > compiled, so the attempt to build it separately from Qt itself > stops. > > So, for the first time in many years I've now "completed" a desktop > system where links is the only available browser. > > Node - in theory v12.13.1 has experimental support for python3. The following 3 patches helps v12.13.1 build with python3 https://github.com/nodejs/node/commit/be926c7e21ddf0e24e26b7a74aabda66e91a9da5.patch https://github.com/nodejs/node/commit/b2ccbb27dc98dfd771d7d5592e139e2001baa56c.patch https://github.com/nodejs/node/commit/3a076bae9c256a830353cf47170599d30baa6c1b.patch Wayne. > > In > practice the configure script still requires (only) 2.7. v13.3.0 > (more bleeding edge - I suggested some time ago that we could stick > to the stable verison) _does_ compile and passes its tests with the > same one failure, but since none of the available fireofx source > versions will compile without python2 this is not exactly an urgent > problem. > > Consequential damage from spidermonkey not compiling: polkit cannot > be compiled, therefore anything using that (e.g. colord) fails. And > usermode xorg fails - for this run I went back to suid xorg. > > I'm fairly sure that things using webkitgtk will pull in polkit, and > therefore spidermonkey, so it looks as if graphical browsers will > all continue to require python2. > > The ugly: (things known to need python2 until next release) > > > gimp-2.10 - it looks as if there are now maintainers for the (few) > python modules used by gimp. When gimp-3 is released (whenever the > devs decide it is ready) it will use python3 (2.99 has done for > several months). In the meantime there is an option to configure > without python, but none of the python2 scripts will work if you do > that. > > inkscape-0.92 - I did not even try this, all the development is on > 1.0 which is approachine a release and should work with python3. > > Summary: > --- > > What is it about End of Life that python programmers do not > understand ? /me remembers the vast amount of work needed on > mainframe systems for Y2K, and the ongoing Y2038 work. > > ĸen > -- > We've all got both light and dark inside of us. > What matters is the part we choose to act on. > -- Sirius Black -- http://lists.linuxfromscratch.org/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-book] r19353 - in trunk/BOOK: . introduction/welcome x/lib
On Sun, 2017-10-22 at 13:02 -0500, DJ Lucas via blfs-book wrote: > > On 10/22/2017 12:32 PM, Armin K. via blfs-book wrote: > > On Sun, 2017-10-22 at 12:18 -0500, Bruce Dubbs wrote: > > > DJ Lucas via blfs-book wrote: > > > > > > > > > > > > On 10/22/2017 04:05 AM, Armin K. via blfs-book wrote: > > > > > > > > > > -make > > > > > > +meson --prefix /usr $PWD build && > > > > > > +cd build && > > > > > > +ninja > > > > > > > > > > > > > > > > Make these two into "ninja -C build", same for install cmd. > > > > > > > > Will do, thanks. > > > > > > Actually, I'd rather not. It only removes one line at the expense > > > of > > > making two lines slightly more complex. What we have now is similar > > > to cmake. > > > > > > If we want to make things more consistent, we would be better off > > > with: > > > > > > mkdir build > > > cdbuild > > > meson .. > > > ninja > > > ninja install > > > > > >-- Bruce > > > > > > > Actually, I like this one more. It's what I use on my end. I would not > > say it's slightly complex, after all it's just 9 extra chars (including > > whitespaces)! > > > > Actually, it's one less character and I like it better aesthetically as > well, but just discussed with Bruce in PM. After said discussion, I'm > leaning toward Bruce's thinking. Consistency with other parts of the > book and simplicity vs the slightly shorter command line. Look at it > this way: > > meson $PWD build && ninja -C build && ninja -C build install > vs. > mkdir build && cd build && meson .. && ninja && ninja install > > Now, it is three commands vs five, but muscle memory has the advantage > with Bruce's syntax. We are really picking nits here, though. > > -- DJ > I'll just put my two cents worth. The first option does not require a $PWD. The following should work just as fine: meson build && ninja -C build && ninja -C build install I've been personally doing the following: meson build && cd build && ninja && ninja install The other question should be meson --prefix /usr vs meson --prefix=/usr Personally, I've been doing the later as it is more consistent with the other build systems. I noticed that currently in the book, you have no equals for systemd and an equals for fuse3. Regards, Wayne. -- http://lists.linuxfromscratch.org/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-book] [BLFS Trac] #5379: Add efibootmgr 0.12
On Fri, 2016-10-14 at 17:50 -0500, Bruce Dubbs wrote: > nullity.resea...@gmail.com wrote: > > not only used to dual boot to Windows. efitools is used to manipulate > > uefi boot parameters. if you compile two kernels with efistub, you can > > choose which kernel to boot from efitools, just place them on your efi > > boot partition and create entries in your efi boot table using the > > program. > > > That's what grub does and grub is easier. > > -- Bruce > > > I too do not have Windows. Infact I don't even have efi hardware. The reason I need it are for my VM builds which do use efi. (I wanted to learn how efi works.) The VMs boot up with grub. I have a script which creates a new blank VM disk with the lfs tools chain. One of the commands in this script is grub-install. grub-install requires efibootmgr being present when constructing a x86_64-efi target. As a side note, when I build grub, I build it twice for the two targets that I use, i386-pc and x86_64-efi. Regards, Wayne, -- http://lists.linuxfromscratch.org/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page