LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Gentoo
User Name
Password
Gentoo This forum is for the discussion of Gentoo Linux.

Notices


Reply
  Search this Thread
Old 12-12-2017, 06:49 PM   #1
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Rep: Reputation: Disabled
Gentoo's upgrade policy


I am using gentoo for over 11 years by now.

A few years ago some moderators and other guys told me at forums.gentoo.org the following.

There is no need anymore to rebuild two times system and than two times the world. It is not needed anymore it's waste of cpu cycles bla bla bla

Guess what the update brings.

I provide the full news for everyone to read.

Quote:
ASUS-G75VW roman # eselect news read new
2017-11-30-new-17-profiles
Title New 17.0 profiles in the Gentoo repository
Author Andreas K. Hüttel <dilfridge@gentoo.org>
Posted 2017-11-30
Revision 1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
This change is mostly relevant to Gentoo developers. It also
means, however, that compilers earlier than GCC 6 are masked
and not supported for use as a system compiler anymore. Feel
free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
executables (PIE) by default. This improves the overall
security fingerprint. The switch from non-PIE to PIE binaries,
however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
profile tree. Now they are moving into the 17.0 profile
as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
. /etc/profile
* Re-emerge libtool
emerge -1 sys-devel/libtool
Then,
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc
* Rebuild your entire system
emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of
GCC 6 to generate PIE executables by default; thus, you need to do
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.
Especially:
Quote:
* Rebuild your entire system
emerge -e @world
Reference for the not gentoo guys: The command above tells the package manager to rebuild every installed package on your box.

The command in question is bad

missing flags
-a for ask for permission to do it
-v verbose to see what its done
--keep-going to let the package manger keeps on building while you are away. A single package which fails, and there are usually around 10 in 1200 packages, because developers of gentoo are just cocky, lazy in my personal experience. I can give you around 20 open bugs which are not fixed in a very long time fashion we talk about many years.
--deep (when you rebuild you should use that too)
-N (when you rebuild you should use that too)

Also no consideration, to cleanup your packages. When you rebuild everything you better start of with system and than check the world what you may want to ditch, what you want to optimize. As you rebuild everything you have a chance to get rid of packages, add functionality or packages.


--

Suggestion

Do as the guide says but instead of rebuilding world first rebuild system subset first.

emerge -e --keep-going -deep -N -av system

check with

/var/log/emerge.log
/var/log/emerge-fetch.log

Read the logfile to see if a package failed, focus on that!

When the system subset is done, you can focus on the world subset.

As you will be rebuilding everything, it is a chance now to

change window managers, as a rebuild is like uninstalling and recompiling the software again anyway.
change use-flags, add functionality you want, remove functionality. Big chance to get rid of certain rat tail packages

check with
equery belongs
euses u

It's also time to sort out config files and old package entries
you should also sort out the world file now

--

I will stop before the rebuilding system stage for this week.
I want to sort out my config files before, and that takes time.
I also want to unmerge lint. As written before, I have now the chance to optimize my box, remove lint, change window managers.

--

That should not hurt my box

I did upgrade from gcc 5.4.0 today. I had the gcc 6.x.x branch hardmasked because It was buggy as hell and now this news had struck me with a new profile and than portage already offered me to go gcc 7.2.0 which compiled on the first attempt quite nice. I was kinda surprised. Some gcc were very demanding to require the previous branch to be compiled. I had gcc 6.x.x in use for a short period of time, more hassle as it was worth it!
I used gcc-config to switch to gcc 7.2.0

Now I am emerging gcc:7.2.0 again with gcc 7.2.0 with an outdated glibc which was build wtih gcc 5.4.0 to get a gcc 7.2.0 with pie flag enabled

This suggestion is flawed as It suggests to use gcc 6.4.0 which may be as stable as gcc 7.2.0 branch.

* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc

--

As someone who realized today that I was a very long time on the stabl e gcc 5.4.0 branch, how comes that I had recently several failed packages? Stable in gentoo means nothing. With stable gcc those packages should have build without any fuss or those packages should have had proper ebuilds to sort out my outdated gcc of course.

--

I prefer gentoo guys would focus their minds on sloted lua, which is more important as some new gcc enforced flag. Those flags are nice, but when you consider I am on an intel platform with a NSA enabled hidden cpu, same applies for amd, so there is no need or requirement now to enforce pie support. Most guys, except myself, run a plain linux box with a filesystem which is not encrypted. Pie is wasted as they did not take the lvm2/luks route which i took several years ago.

--

Gentoo is about choice. OF course, but why will be my 13.0 profile than be removed? why am I forced to switch profiles? use a newer gcc with PIE?

Those PIE, SE linux, hardened are just overrated. When you care for such you choose something else as gentoo linux anyway. Something more stable, more tested, something with developers fixing bugs and not just collecting bugs who collect dust. Most bugs are just answered by other users, the solution is there for a very long time. and even with many forum posts on teh offical forum, they will not accept anything else which does not come from thier point of view. best example was the legacy nvidia-driver and the kernel patch which was than needed. around 10 forums.gentoo.org posts, 3 bugs at bugs.gentoo.org but still in the stage unconfirmed.

Last edited by _roman_; 12-12-2017 at 06:53 PM.
 
Old 12-14-2017, 10:07 PM   #2
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,123
Blog Entries: 3

Rep: Reputation: 180Reputation: 180
Hello _roman_,

I've only been running Gentoo a little over a year off and on. I've had several issues with updating my system since this move to 17.0. I agree with you that Gentoo is supposed to be about choice why are they forcing the switch to 17.0?

I still have issue with certain programs working and someday maybe I'll figure them out. Luckily I have a dd backup of mu hard drive so I can reinstall a working system when things go south.
 
Old 12-15-2017, 06:00 PM   #3
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
Okay I share with you some findings.

Gentoo'S package manager portage is flawed. Or the cocky developers just made the same mistake again as in the past. Which I will explain now.

One thing which happened already in the past and was already reported is the use of an outdated binutils. At least one ebuild did not build because I was using a binutil version which was not available anymore in the past 24 hours! I'd expected that the ebuild would be updated and removed, the binutils link fixed.

Fixed now:

Quote:
ASUS-G75VW /home/roman # binutils-config -l
[1] x86_64-pc-linux-gnu-2.29.1 *
I was using before =sys-devel/binutils-2.29 which was not in the tree anymore. when you want to check the time, it happend at unix seconds 1513312648.

Quote:
1513294180: ::: completed emerge (126 of 812) sys-devel/binutils-2.29.1-r1 to /
1513312648: *** emerge --unmerge =sys-devel/binutils-2.29

Quote:
1513294180: ::: completed emerge (126 of 812) sys-devel/binutils-2.29.1-r1 to /
1513312648: *** emerge --unmerge =sys-devel/binutils-2.29
1513312653: === Unmerging... (sys-devel/binutils-2.29)
1513312656: >>> unmerge success: sys-devel/binutils-2.29
1513312676: *** emerge --unmerge =sys-devel/binutils-2.28.1
1513312681: === Unmerging... (sys-devel/binutils-2.28.1)
1513312683: >>> unmerge success: sys-devel/binutils-2.28.1
1513315522: >>> emerge (99 of 371) sys-libs/binutils-libs-2.29.1-r1 to /
Quote:
ASUS-G75VW /home/roman # equery y binutils
Keywords for sys-devel/binutils:
| | u |
| a a p a n r s | n |
| l m h i p r m m i i s p | e u s | r
| p d a p a p c x m i 6 o s 3 a | a s l | e
| h 6 r p 6 p 6 8 6 p 8 s c 9 s r | p e o | p
| a 4 m a 4 c 4 6 4 s k 2 v 0 h c | i d t | o
-------------+---------------------------------+------------+-------
[M]2.25.1-r1 | + + + + + + + + + ~ + o o + + + | 4 o 2.25.1 | gentoo
-------------+---------------------------------+------------+-------
[M]2.26.1 | + + + + + + + + + ~ + o o + + + | 5 o 2.26.1 | gentoo
-------------+---------------------------------+------------+-------
[M]2.27-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ ~ | 5 o 2.27 | gentoo
-------------+---------------------------------+------------+-------
2.28.1 | + + + + + + + + ~ ~ ~ o o ~ ~ + | 5 o 2.28.1 | gentoo
-------------+---------------------------------+------------+-------
[I]2.29.1-r1 | + + + ~ + + + + ~ ~ ~ o o ~ ~ ~ | 5 o 2.29.1 | gentoo
-------------+---------------------------------+------------+-------
9999 | o o o o o o o o o o o o o o o o | 6 o git | gentoo
I ditched now any binutils which is not [I]2.29.1-r1.

--

So why did this happen? So why did that happen again?

Its quite simple, the slot number changed, which is as of now 5 o 2.29.1 . The binutils I had set by the system had another slot number, I assume, I did not made now a screenshot, something like "5 o 2.29.0" or " 5 o 2.29 ".
So portage keeps the binutils link to that outdated version. Portage did not notify me about an outdated installed package!

So when you use an outdated binutils, which the developers do not use, you get random build issues. Some ebuilds may build, othes do not.

I reported this several times on forums.gentoo.org and bugs.gentoo.org in the past 11 years.

The proper behaviour should have been hardmasking this binutils before dropping the slot number and the ebuild version.

Gentoo developers are just idiots by dropping a slotted binutils without notifiying the user.

An Idiot in my definition is someone who does the same mistake again. Does not learn from previous events or apply changes which may prevent these.

This is the issue with heavy slotted packages and lazy developers dumping a slot number without hardmasking it.

--

I also cleaned up the world file a lot recently.

Last edited by _roman_; 12-15-2017 at 06:03 PM.
 
Old 12-15-2017, 06:09 PM   #4
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
So when did that happen?

The package sys-devel/binutils-2.29 was first installed on the box @ Emerged at: So Sep 17 20:42:52 2017

The package was bumped to a higher version, named * sys-devel/binutils-2.29.1, around @ Emerged at: Fr Sep 29 00:10:33 2017.

The package was again bumped with a small revision fix, named * sys-devel/binutils-2.29.1-r1, around @ Emerged at: Fr Okt 20 13:05:36 2017. This revision fix usually does not change the slotted number, so this entry should be treated as sys-devel/binutils-2.29. .

-- As you can see between September 17th and September 29th they dirty cleaned up the packages.

Portage is flawed and gentoo's develop working habbit is very flawed.


Quote:
* sys-devel/binutils-2.28-r2

Emerged at: Di Jun 13 16:48:07 2017
Build time: 2 minutes, and 8 seconds

* sys-devel/binutils-2.28.1

Emerged at: Sa Aug 5 23:33:01 2017
Build time: 5 minutes, and 21 seconds

* sys-devel/binutils-2.29

Emerged at: So Sep 17 20:42:52 2017
Build time: 4 minutes, and 27 seconds

* sys-devel/binutils-2.29.1

Emerged at: Fr Sep 29 00:10:33 2017
Build time: 4 minutes, and 36 seconds

* sys-devel/binutils-2.29.1-r1

Emerged at: Fr Okt 20 13:05:36 2017
Build time: 2 minutes, and 5 seconds

Emerged at: Mi Dez 13 01:06:06 2017
Build time: 2 minutes, and 22 seconds

Emerged at: Fr Dez 15 00:27:16 2017
Build time: 2 minutes, and 24 seconds
This is the answer to one bug report I bumped in the past 24 hours. which i did not bother to report back anyway. Because of the previous bugs which are collecting dusts as of now. Wasted efforts to report anything back. I just spam their bugs.gentoo.org with any package which does not build as of now. When I fix it I will not report back!

Last edited by _roman_; 12-15-2017 at 06:10 PM.
 
Old 12-15-2017, 06:16 PM   #5
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
Spidermonkey did only build after I was complete with mostly 99 percent of emerge -e world @ gcc 7.2.0 with PIE and desktop 17 profile.

A new entry in package mask for =app-editors/nano-2.9.1 because it did not build after many attempts. The previous version which was also used at gcc 5.4.0 did build fine. I assume the code has some bugs.

#sys-libs/libstdc++-v3, #sys-cluster/libdlm do not build at all

The package mask for >=sys-kernel/gentoo-sources-4.14.0 was verified as nvidia-drivers still does not support 660m GTX with current x server on ASUS g75vw hardware.

Nvidia drivers failed to build which is a nasty undocumented bug.
To build nvidia-drivers you need to bump the localversion of your kernel. Than you need to rebuild that kernel, set it active and boot from it. Than you can build nvidia-drivers again. I found this after half an hour searching on the gentoo forum. Is also an undocumented well known bug, which is as of now well known but not very well communicated by the developers!

--

Direct Rendering is as of now broken on gcc 7.2.0. X server tho works.

Quote:
roman@ASUS-G75VW ~ $ glxinfo
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig

roman@ASUS-G75VW ~ $
I assume it is

Quote:
roman@ASUS-G75VW ~ $ fbconfig
bash: fbconfig: command not found
roman@ASUS-G75VW ~ $
This has less priority as the prerequirement for lvm2 which is #sys-cluster/libdlm and did not build in many many many build attempts.

libdlm does not build with static, does not build with bfd, does not build as anything else with gold.

I ended up wasting my harddrive space by now by pulling in another slotted gcc named sys-devel/gcc-6.4.0::gentoo.

My box had only issues with gcc 6.3.x, so I hardmasked it and stayed at gcc 5.4.0 for a very long time. With an outdated binutils, because the package manager did not told me that it was outdated.

I do not run emerge --depclean, because it ruins more that it benefits.

--

My attempt is now to try building libdlm with gcc 6.4.0 which is marked stable as of now

Last edited by _roman_; 12-15-2017 at 06:21 PM.
 
Old 12-15-2017, 06:24 PM   #6
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
As expected. Same error. Does not build stable libdlm on stable gcc 6.4.0 with new enforced 17 desktop profile

No surprise.

Quote:
ASUS-G75VW /home/roman # gcc-config -l
[1] x86_64-pc-linux-gnu-6.4.0
[2] x86_64-pc-linux-gnu-7.2.0 *
ASUS-G75VW /home/roman # gcc-config 1
* Switching native-compiler to x86_64-pc-linux-gnu-6.4.0 ...
>>> Regenerating /etc/ld.so.cache... [ ok ]

* If you intend to use the gcc from the new profile in an already
* running shell, please remember to do:

* . /etc/profile

ASUS-G75VW /home/roman # source /etc/profile
ASUS-G75VW /home/roman # emerge libdlm
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-cluster/libdlm-3.2.0::gentoo
* cluster-3.2.0.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking cluster-3.2.0.tar.gz to /var/tmp/portage/sys-cluster/libdlm-3.2.0/work
>>> Source unpacked in /var/tmp/portage/sys-cluster/libdlm-3.2.0/work
>>> Preparing source in /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm ...

Configuring Makefiles for your system...

Checking tree: nothing to do
Completed Makefile configuration

>>> Source configured.
>>> Compiling source in /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm ...
make -j8 -C libdlm
make: Entering directory '/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm'
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fomit-frame-pointer -Wall -I/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/make -DDEFAULT_CONFIG_DIR="/etc/cluster" -DDEFAULT_CONFIG_FILE="cluster.conf" -DLOGDIR="/var/log/cluster" -DSYSLOGFACILITY=LOG_LOCAL4 -DSYSLOGLEVEL=LOG_INFO -DRELEASE_VERSION="3.2.0" -fPIC -I/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm -I/usr/include -I/usr//include -D_REENTRANT -c -o libdlm.o /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c
x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fomit-frame-pointer -Wall -I/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/make -DDEFAULT_CONFIG_DIR="/etc/cluster" -DDEFAULT_CONFIG_FILE="cluster.conf" -DLOGDIR="/var/log/cluster" -DSYSLOGFACILITY=LOG_LOCAL4 -DSYSLOGLEVEL=LOG_INFO -DRELEASE_VERSION="3.2.0" -fPIC -I/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm -I/usr/include -I/usr//include -c -o libdlm_lt.o /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c
cat /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.pc.in | \
sed \
-e 's#@PREFIX@#/usr#g' \
-e 's#@LIBDIR@#/usr/lib64#g' \
-e 's#@INCDIR@#/usr/include#g' \
-e 's#@VERSION@#3.2.0#g' \
> libdlm.pc
cat /var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm_lt.pc.in | \
sed \
-e 's#@PREFIX@#/usr#g' \
-e 's#@LIBDIR@#/usr/lib64#g' \
-e 's#@INCDIR@#/usr/include#g' \
-e 's#@VERSION@#3.2.0#g' \
> libdlm_lt.pc
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'open_control_device':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:376:7: error: called object 'minor' is not a function or function pointer
minor(st.st_rdev) == minor) {
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:363:13: note: declared here
int i, rv, minor, found = 0;
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'find_udev_device':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:420:36: error: called object 'minor' is not a function or function pointer
if (stat(udev_path, &st) == 0 && minor(st.st_rdev) == minor)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:402:56: note: declared here
static int find_udev_device(const char *lockspace, int minor, char *udev_path)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:442:8: error: called object 'minor' is not a function or function pointer
if (minor(st.st_rdev) != minor)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:402:56: note: declared here
static int find_udev_device(const char *lockspace, int minor, char *udev_path)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'open_control_device':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:376:7: error: called object 'minor' is not a function or function pointer
minor(st.st_rdev) == minor) {
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:363:13: note: declared here
int i, rv, minor, found = 0;
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'find_udev_device':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:420:36: error: called object 'minor' is not a function or function pointer
if (stat(udev_path, &st) == 0 && minor(st.st_rdev) == minor)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:402:56: note: declared here
static int find_udev_device(const char *lockspace, int minor, char *udev_path)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:442:8: error: called object 'minor' is not a function or function pointer
if (minor(st.st_rdev) != minor)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:402:56: note: declared here
static int find_udev_device(const char *lockspace, int minor, char *udev_path)
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'dlm_release_lockspace':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:1404:20: warning: implicit declaration of function 'minor' [-Wimplicit-function-declaration]
release_lockspace(minor(st.st_rdev), flags);
^~~~~
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c: In function 'dlm_release_lockspace':
/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm/libdlm.c:1404:20: warning: implicit declaration of function 'minor' [-Wimplicit-function-declaration]
release_lockspace(minor(st.st_rdev), flags);
^~~~~
make: *** [/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/make/cobj.mk:6: libdlm_lt.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/make/cobj.mk:2: libdlm.o] Error 1
make: Leaving directory '/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm/libdlm'
* ERROR: sys-cluster/libdlm-3.2.0::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=sys-cluster/libdlm-3.2.0::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-cluster/libdlm-3.2.0::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-cluster/libdlm-3.2.0/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-cluster/libdlm-3.2.0/temp/environment'.
* Working directory: '/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm'
* S: '/var/tmp/portage/sys-cluster/libdlm-3.2.0/work/cluster-3.2.0/dlm'

>>> Failed to emerge sys-cluster/libdlm-3.2.0, Log file:

>>> '/var/tmp/portage/sys-cluster/libdlm-3.2.0/temp/build.log'
Rant: Not only nano the system wide editor does not build, even a basic requirement for lvm2 does not build. My root is on luks / lvm2. Because I use linked binaries to an older gcc I can still use lvm2. For a fresh install, my box would be not able to boot at all. Because lvm2 can not build when libdlm can not build

with or without
echo "sys-cluster/libdlm static-libs" >> /etc/portage/package.use

it fails for both, it has only one useflag, fails on both, on any allowed gcc with desktop 17 profile

as my system is now offically PIE, this is kinda annoying.

--

Next step is to emerge again k3b, gimp, vlc.

I ripped out on purpose some junk which causes issues and slows down the update process
Now I have to reemerge it

--

vlc did not build at all because of the useflag responsible for video cds. Than I checked google and found it was some standard for cds with the size of around 700MB, and much lower resolution, around half of 640x480 and mpeg 1 audio or so. You definitely do not want video cds in these days. I do not own any, so I could safely drop the useflag and build vlc.

Last edited by _roman_; 12-15-2017 at 06:34 PM.
 
Old 12-15-2017, 06:30 PM   #7
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
When you want to unmerge hole sets, or cleanup world, use something like this for example

Quote:
241 qlist -Iv net-wireless
242 emerge --deselect $(qlist -I net-wireless)
243 emerge --deselect $(qlist -I net-misc)
244 emerge --deselect $(qlist -I sci-libs)
245 emerge --deselect $(qlist -I media-sound)
There is no requirement to have those in @world anyway.
Put the end application in there like vlc, gimp, k3b

I cleaned up world before I did my upgrade. Unmerge k3b, any kde, gimp, and such.
K3b pulls in bad maintained kde packages which pulls in qt 3 / 4 / 5 or a subset of those. This changed over the years. You do not want that rat tail to be pulled in only for k3b when you change gcc.

--

No idea why i kept DSDT, iasl, seabios and such. All ditched.

A safe countermeasure is to create a new entry in package.mask. So even when portage pulls it in, or it was pulled in in the meantime you did optimise your box, portage will complain on every emerge that a masked package is installed or required.

--

I did not touched ruby / python versions or lua.

There is no requirement to keep every version of ruby / python / and ofc lua should be slotted too.

I had python 27 and python 35 in the past. It was the bare minimum which was required. Maybe they managed to support python 36 for many packages so i could drop python 35 now.

--

I ditched the manpages. I have no idea why those manpages are required by system? No ones need manpages anyway. Google finds em much faster. you can search faster those.

Last edited by _roman_; 12-15-2017 at 06:42 PM.
 
Old 12-15-2017, 06:47 PM   #8
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by lazydog View Post
Hello _roman_,

I've only been running Gentoo a little over a year off and on. I've had several issues with updating my system since this move to 17.0. I agree with you that Gentoo is supposed to be about choice why are they forcing the switch to 17.0?

I still have issue with certain programs working and someday maybe I'll figure them out. Luckily I have a dd backup of mu hard drive so I can reinstall a working system when things go south.
They think PIE make such big difference.

In my point of view, PIE is worthless because you run in on a NSA Platform with spyprocessor. Intel calls it the intel management engine, amd has another name for it. + my qualcom card is also affected. Qualcom is also a strategic nsa partner. so what.

The platform is in my point of view not secure. We are not like in china to get benefits for being a good citizen, but we are close to that. Serious that is no joke about China and getting points for being a good citizen. Anyway I am sorry for the slight derail on politics. Just made my point why In my point of view PIE is wasted efforts. I think it's soon time for freebsd as they are against any blob software in their operating system, which makes sense
 
Old 12-15-2017, 08:40 PM   #9
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
No direct rendering as the nvidia drivers fails to build.

=> cc1: error: incompatible gcc/plugin versions <=

Won't fix, and I know the gentoo developers attitude towards the nvidia binary blob.

I have a working X server but no glx. So no games for myself.

Quote:
-c -o /var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/kernel/nvidia/.tmp_nv-gpu-numa.o /var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/kernel/nvidia/nv-gpu-numa.c
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./scripts/gcc-plugins/randomize_layout_plugin.so
make[2]: *** [scripts/Makefile.build:303: /var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/kernel/nvidia/nv-gpu-numa.o] Error 1
make[1]: *** [Makefile:1512: _module_/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/kernel] Error 2
make[1]: Leaving directory '/usr/src/linux-4.13.16-gentoo'
make: *** [Makefile:84: modules] Error 2
* ERROR: x11-drivers/nvidia-drivers-387.34::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=x11-drivers/nvidia-drivers-387.34::gentoo'`,
* the complete build log and the output of `emerge -pqv '=x11-drivers/nvidia-drivers-387.34::gentoo'`.
* The complete build log is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/temp/environment'.
* Working directory: '/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/kernel'
* S: '/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/work/'

>>> Failed to emerge x11-drivers/nvidia-drivers-387.34, Log file:

>>> '/var/tmp/portage/x11-drivers/nvidia-drivers-387.34/temp/build.log'
Quote:
[ 27.498] (**) NVIDIA(0): Enabling 2D acceleration
[ 27.498] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 27.498] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
[ 27.498] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
[ 27.498] (EE) NVIDIA(0): you continue to encounter problems, Please try
[ 27.498] (EE) NVIDIA(0): reinstalling the NVIDIA driver.
[ 27.729] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
I can not fix my X server when the nvidia driver does not build with PIE.
I am quite certain I need to hack it to remove PIE and set it to some older compiler probably.
 
Old 12-15-2017, 08:48 PM   #10
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
revdep rebuild bugs me a lot
Quote:
>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

!!! existing preserved libs:
>>> package: sys-libs/db-4.8.30-r2
* - /usr/lib32/libdb-4.8.so
* used by /usr/lib32/sasl2/libsasldb.so.3.0.0 (dev-libs/cyrus-sasl-2.1.26-r11)
* - /usr/lib64/libdb-4.8.so
* used by /usr/lib64/sasl2/libsasldb.so.3.0.0 (dev-libs/cyrus-sasl-2.1.26-r11)
* used by /usr/sbin/saslauthd (dev-libs/cyrus-sasl-2.1.26-r11)
* used by /usr/sbin/sasldblistusers2 (dev-libs/cyrus-sasl-2.1.26-r11)
Use emerge @preserved-rebuild to rebuild packages using these libraries

* IMPORTANT: config file '/etc/logrotate.d/pm-utils' needs updating.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
ASUS-G75VW /home/roman # man sed

ASUS-G75VW /home/roman # rm /usr/lib32/libdb-4.8.so
ASUS-G75VW /home/roman # rm /usr/lib64/libdb-4.8.so
as I have rebuild cyrsus sasl several times and it does not want to get rid of it, I just nuked (= removed) it.
I got a lot of complaints and critism in the past for such an approach.

I see it as lint, which the package manager can not deal with it.

Broken => emerge @preserved-rebuild
Because the libaries are not fixed

Last edited by _roman_; 12-15-2017 at 08:49 PM.
 
Old 12-16-2017, 01:48 AM   #11
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,123
Blog Entries: 3

Rep: Reputation: 180Reputation: 180
Wow, I was not aware of all these problems. I'm in the process of trying to update my desktop now. I've tried a few different things but nothing seems to work correctly. I use nVidia drivers for my systems so if the drivers are not building I'm going to be in trouble when I reboot.

I see you have the Asus G75VW. I have this laptop also but I'm running Sabayon instead of Gentoo.
 
Old 12-16-2017, 07:00 AM   #12
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
Glx, means direct rendering is broken now with profile 17 desctop, both gcc 6.4.0 and gcc 7.2.0

--

I wanted to add a bug with data, and I get

Quote:
Request Timeout

Server timeout waiting for the HTTP request from the client.
Apache Server at bugs.gentoo.org Port 443
Means my bugs.gentoo.org account is banned, or the server just died there now.

Well I was not friendly at all recently but who cares
--

Germans also have issues

http://www.gentooforum.de/artikel/22...tml#post156520

Same error I get
Quote:
cc1: error: code model kernel does not support PIC mode
and sadly no glue how to fix

--

Temporarily workaround:

No GLX.

Stay on the kernel you are running with the kernel module you build in the past

I tried to build a new kernel, localversion set to test. Emerged nvidia-drivers, rebuild kernel. booted that kernel as usual. nope. only CLI mode, means init 3 only available

--

lazy approach is to sit it out.

Wait ~2 Weeks and hope they fixed that crap.
I assume in 2 weeks most had already moaned and they may fix nvidia-drivers and libdlrm

The errors I get are definitely coding errors, wrong data types and such. so it is more an issue there is no patch for a newer gcc. and nvidia-drivers will probably be a no fix issue. maybe worth looking into nouveau status for my 660m gtx

I still have 2 backups so i could revert to a running gentoo.

time to download open or freebsd, one of those two supports nvidia-drivers. I have 1 TB HDD which I can utilize for other OS

Last edited by _roman_; 12-16-2017 at 07:14 AM.
 
Old 12-16-2017, 07:08 AM   #13
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by lazydog View Post

I see you have the Asus G75VW. I have this laptop also but I'm running Sabayon instead of Gentoo.
Are you running the gpu mod bios? I am a bit scared to flash that mod bios. The 660m GTX could run 200 mhz faster.

I repaste the thermal paste past few days. The gpu is now at 45 degress centigrade. much cooler as before.

I'm just scared on reflashing the bios, when I do not really know on how to read out the bios before. i need another computer and need to buy a beagle bone black with special adapters. It is too risky, and i am too scared to trash 500 euro device.

Only cons about this notebook is on how awful it is to disassemble it to repaste the thermal paste, to access RAM modules behind the keyboard, clean the fans.

On the other hand, i doubt the 200 mhz on the gpu will make muhc a difference with the outdated 660m gtx

The asus g70sg, which I had before, my first ROG notebook, was much easier to disassemble. Well that had a LVDS cable issue because the cable was a few milimeters too short in my point of view
 
Old 12-18-2017, 03:37 AM   #14
_roman_
Member
 
Registered: Dec 2017
Location: _Austro_Bavaria_
Distribution: SLACKWARE 96 -> SUSE 6.2 & REDHAT -> Gentoo & ARCH-Linux & Linux-Mint
Posts: 290

Original Poster
Rep: Reputation: Disabled
GLX error solved.

For some reason the working kernel config in regards of frame buffer devices does not work anymore with gcc 7.2.0

I did several different test kernels to sort out this issue and solved it.

I consider this as a bug of the upgrade. A working kernel config should work with higher gcc and PIE also. It seems i hit something untested which is kinda hardly used anymore in regards of framebuffers.

--

still around 10 packages which refuse to build. They are still linked to old gcc with non PIE
 
Old 12-18-2017, 09:56 PM   #15
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,123
Blog Entries: 3

Rep: Reputation: 180Reputation: 180
Quote:
Originally Posted by _roman_ View Post
Are you running the gpu mod bios? I am a bit scared to flash that mod bios. The 660m GTX could run 200 mhz faster.
No I have not flashed the bios on this system.


Quote:
I repaste the thermal paste past few days. The gpu is now at 45 degress centigrade. much cooler as before.

I'm just scared on reflashing the bios, when I do not really know on how to read out the bios before. i need another computer and need to buy a beagle bone black with special adapters. It is too risky, and i am too scared to trash 500 euro device.

Only cons about this notebook is on how awful it is to disassemble it to repaste the thermal paste, to access RAM modules behind the keyboard, clean the fans.

On the other hand, i doubt the 200 mhz on the gpu will make muhc a difference with the outdated 660m gtx

The asus g70sg, which I had before, my first ROG notebook, was much easier to disassemble. Well that had a LVDS cable issue because the cable was a few milimeters too short in my point of view
This was my first ROG laptop and I really like it.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Configure my Redhat directory server password policy and account lockout policy arunplanet Linux - Newbie 4 10-06-2012 09:59 AM
Fedora 16: Could not downgrade policy file (selinux-policy-targeted) coreychch Fedora 1 06-29-2012 03:33 AM
GENTOO - problem running 'make load' for selinux policy Snerkel Linux - Distributions 3 09-22-2006 12:30 AM
GENTOO - problem running 'make load' for selinux policy Snerkel Linux - Software 1 01-24-2005 01:29 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Gentoo

All times are GMT -5. The time now is 01:23 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration