|
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:
Quote:
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. |
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. ;) |
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:
Quote:
Quote:
Quote:
-- 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. |
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:
|
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:
Quote:
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 |
As expected. Same error. Does not build stable libdlm on stable gcc 6.4.0 with new enforced 17 desktop profile
No surprise. Quote:
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. |
When you want to unmerge hole sets, or cleanup world, use something like this for example
Quote:
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. |
Quote:
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 |
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:
Quote:
I am quite certain I need to hack it to remove PIE and set it to some older compiler probably. |
revdep rebuild bugs me a lot
Quote:
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 |
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. |
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:
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:
-- 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 |
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 |
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 |
Quote:
Quote:
|
| All times are GMT -5. The time now is 11:50 PM. |