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
