[gentoo-user] Re: problem dropping Python 2.7
On 9/12/19 10:13 AM, Nikos Chantziaras wrote: As for getting around the first 3, you need to uninstall everything that depends on them and then unmerge them. I don't know how feasible that is, because some important packages probably depend on LLVM? Not sure. Right now, Python 2.7 is required for a useful desktop machine because important packages like Mesa probably depend on something that in turn uses Python 2.7. For a minimal system without X11 though you can probably do it. Even on headless systems it's not completely possible at the moment. At least spidermonkey aka mozjs is required by polkit and only builds with python-2.7, thanks to their own !"§$% home-grown build system. Mozilla are working on it and it should be fixed "by the end of the year". Same for llvm-8 which still has a hard dependency on 2.7 as well. The pending llvm-9 release will supposedly work with 3.x. -h
Re: [gentoo-user] Re: problem dropping Python 2.7
190912 Nikos Chantziaras wrote: > On 12/09/2019 07:36, Philip Webb wrote: >> I've been trying to eliminate Python 2.7 >> & have dropped the 'TARGETS' lines from 'make.conf', leaving only 3.6 , >> but it seems that a number of pkgs still require it : > Uninstall all packages that require Python 2.7. > Some packages might have a "python" USE flag > that disables functionality that needs python, so try that first. I had 'python' in the 'USE=" in 'make.conf' for whatever reason, so i deleted it & that removed some of the outstanding problem pkgs. I'm now left with 5 problem pkgs : llvm-7.1.0 fetchmail-6.3.26-r4 qtwebkit-5.212.0_pre20180120 spidermonkey-60.5.2_p0-r2 firefox-60.8.0 the former 3 all have in their ebuilds PYTHON_COMPAT=( python2_7 ) the latter 2 are said to require python 2.7 : 2.7 [ncurses sqlite ssl threads] I don't understand the list in square brackets, which are USE flags : they aren't set in 'make.conf' or elsewhere AFAIK. Can anyone explain (1) how to get around the 1st 3 ebuilds or (2) what the problem is with the 2nd 2 examples ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: problem dropping Python 2.7
On 12/09/2019 10:56, Philip Webb wrote: I'm now left with 5 problem pkgs : llvm-7.1.0 fetchmail-6.3.26-r4 qtwebkit-5.212.0_pre20180120 spidermonkey-60.5.2_p0-r2 firefox-60.8.0 the former 3 all have in their ebuilds PYTHON_COMPAT=( python2_7 ) the latter 2 are said to require python 2.7 : 2.7 [ncurses sqlite ssl threads] I don't understand the list in square brackets, which are USE flags : they aren't set in 'make.conf' or elsewhere AFAIK. Can anyone explain (1) how to get around the 1st 3 ebuilds or (2) what the problem is with the 2nd 2 examples ? The square brackets tell portage that the package needs python emerged with those USE flags set on the python ebuild. As for getting around the first 3, you need to uninstall everything that depends on them and then unmerge them. I don't know how feasible that is, because some important packages probably depend on LLVM? Not sure. Right now, Python 2.7 is required for a useful desktop machine because important packages like Mesa probably depend on something that in turn uses Python 2.7. For a minimal system without X11 though you can probably do it.
[gentoo-user] Re: gdb build failure: tui/tui-win.o: undefined reference to symbol 'keypad'
On 2019-09-11, Grant Edwards wrote: > This morning the build of gdb failed during a routine update: > > [...] > CXXxml-tdesc.o > CXXinit.o > CXXLD gdb > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > tui/tui-win.o: undefined reference to symbol 'keypad' > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status I'm still beating my head against the wall on this one. I've got a handfull of systems where gdb builds fine, and one where I suddenly started getting the above error. I've re-emerged ncurses (both with and without the tinfo USE flag). I've verified that the USE flags for ncurses and gdb are the same as on systems where gdb builds OK. The gcc and binutils versions are also the same. revdep-rebuild seems to be happy. -- Grant Edwards grant.b.edwardsYow! Didn't I buy a 1951 at Packard from you last March gmail.comin Cairo?
[gentoo-user] Re: gdb build failure: tui/tui-win.o: undefined reference to symbol 'keypad'
On 2019-09-12, Grant Edwards wrote: > On 2019-09-11, Grant Edwards wrote: > >> This morning the build of gdb failed during a routine update: >> >> [...] >> CXXxml-tdesc.o >> CXXinit.o >> CXXLD gdb >> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: >> tui/tui-win.o: undefined reference to symbol 'keypad' >> /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: >> /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line >> collect2: error: ld returned 1 exit status > > I'm still beating my head against the wall on this one. I give up. I went into the build directory and manually added "-ltinfo" to the link options in the Makefile and did a "make". It then compiled and linked just fine. After that, doing 'ebuild gdb-8.3.ebuild preinst/install/qmerge' worked and I have a functional gdb again. When I have a spare day I guess I'm going to have to fall back on the old MS-Windows solution: wipe the disk and install from scratch. -- Grant Edwards grant.b.edwardsYow! Now KEN and BARBIE at are PERMANENTLY ADDICTED to gmail.comMIND-ALTERING DRUGS ...
[gentoo-user] Re: gdb build failure: tui/tui-win.o: undefined reference to symbol 'keypad'
On 2019-09-11, Grant Edwards wrote: > This morning the build of gdb failed during a routine update: ... > CXXxml-tdesc.o > CXXinit.o > CXXLD gdb > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > tui/tui-win.o: undefined reference to symbol 'keypad' > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:1893: gdb] Error 1 You can no longer install gdb if you have sys-libs/libtermcap-compat installed. If you have libtermcap installed, the gdb ebuild will decide to link against libtermcap instead of libtinfo, and you get the failure above. However, uninstalling libtermcap proved to be difficult. After unmerging it, I got the expected warnings about preserved libs, but doing the emerge as recommended faild. I tried revdep-rebuild, and it insisted on emerging the same packages over and over again — each time resulting in files that still depended on the preserved termcap libraries. I finally had to unmerge a bunch of packages that were using the termcap libraries, manually remove the termcap libraries, and then run revdep-rebuild to try to repair things. Now gdb builds again. Hopefully, I'll be able to reinstall the packages I removed... -- Grant Edwards grant.b.edwardsYow! INSIDE, I have the at same personality disorder gmail.comas LUCY RICARDO!!
Re: [gentoo-user] Re: slow MTP in Thunar, was fine in Gnome
On Wed, 11 Sep 2019 18:08:23 - (UTC), Grant Edwards wrote: > >> Though it might be tricky to get the mount to happen automagically > >> when the phone's USB cable is plugged in... > > > > It should be possible with a udev rule. > > Yes, I would think so. At least for me, writing udev rules is about as > tricky as it gets in Linux. I've done it many times, but there's > still always a fair bit of trial and error involved. Sacrificing a chicken can help! -- Neil Bothwick Top Oxymorons Number 40: Same difference pgpZ2l5SLxsO_.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: problem dropping Python 2.7
190912 Holger Hoffstätte wrote:
> At least spidermonkey aka mozjs is required by polkit and only builds
> with python-2.7, thanks to their own !"§$% home-grown build system.
> Mozilla are working on it and it should be fixed "by the end of the year".
What about Firefox ?
-- trying to unmerge Python-2.7 tells me that Firefox-60.8.0 requires
"python 2.7.5-r2:2.7[ncurses sqlite ssl threads]".
That Firefox ebuild does indeed require those flags,
but it also contains "PYTHON_COMPAT=( python3_{5,6,7} )".
What is telling Portage that Firefox needs Python-2.7 ?
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatchassdotutorontodotca
