| View previous topic :: View next topic |
| Author |
Message |
Shibotto
Apprentice
Joined: 19 Jun 2015
Posts: 156
Location: CET/CEST
|
 Posted: Tue Jan 30, 2018 7:50 am Post subject: |
 |
|
So putting the rants aside, what is the correct way to upgrade as of 2018-01-30? I couldn't do it for about a month so it came as a surprise (as in not a word in eselect news) this morning.
Right now I have both LINGUAS and L10N set. |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jan 30, 2018 8:34 am Post subject: |
|
|
| Shibotto wrote: | | Right now I have both LINGUAS and L10N set. |
My recommendation is: Do nothing (except the regular update procedure), keeping them both set.
However, the official recommendation must be to remove your definition of LINGUAS from make.conf.
The difference is: In the former case, many packages will install only the translation for the languages from LINGUAS, but this is intransparent to portage now (causing e.g. problems with binary packages since a package will not be recognized as different if it is built with a different value of LINGUAS); not setting LINGUAS in make.conf will usually install all translations, avoiding the mentioned problems at the cost of harddisk space. (The official reason is that you can use INSTALL_MASK to mitigate the latter problem; but in practice it is not possible to give an INSTALL_MASK which works for all packages correctly, because the exact effect of LINGUAS depends on the package.) |
|
| Back to top |
|
|
Shibotto
Apprentice
Joined: 19 Jun 2015
Posts: 156
Location: CET/CEST
|
| Posted: Tue Jan 30, 2018 10:00 am Post subject: |
|
|
| Thank you. So I also shouldn't be needing to set USE="... linguas_it ..." right? I think I read this in the bug report. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jan 30, 2018 11:18 am Post subject: |
|
|
| Shibotto wrote: | | USE="... linguas_it ..." right |
This USE-flag doesn't exist anymore in any ebuild from the gentoo repository. So setting it has no effect. |
|
| Back to top |
|
|
noci2
n00b
Joined: 14 Jan 2018
Posts: 10
|
| Posted: Sun Feb 04, 2018 3:52 pm Post subject: |
|
|
| asturm wrote: | | rosomak wrote: | I saw the same with KDE guys - they also knew better and treated every polite remark as an attack to their dignity.
Brave new world ... |
If what you so conveniently chose to omit from quoting was a polite remark by your standards, then brave new world indeed. Also good job slandering yet another group of devs without participation in this thread. Alas, just another post to fan the flames. |
I agree partly with you asturm this wasn't needed, then again computer users do face some problems on the road to the better world. There is a lot of breakage, i know this is the new adagium in software.
Recently:
opening another session (same screen, difference user) doesn't work anymore.. SDDM, Kscreenlocker, X..?? , no errors logged, the switch button returns to the currently logged on user. This is very anoying... it used to work without problems until KDE 5.x
So i do understand where complaining users come from and when does one discover this..., when things "that used to work" (tm) dont only at an inconvenient moment. (in stead of switching between 2 sessions now logout, login acnt#2, logout, login acnt#1 , ... a few times just to get the job done).
And no sudo doesn't help to switch accounts in this case.
Last edited by noci2 on Sun Feb 04, 2018 8:20 pm; edited 1 time in total |
|
| Back to top |
|
|
noci2
n00b
Joined: 14 Jan 2018
Posts: 10
|
| Posted: Sun Feb 04, 2018 8:17 pm Post subject: |
|
|
Sorry for the delay..
| ulm wrote: | | noci2 wrote: | And an advise about the most efficient way to upgrade was given. I think in this instance the advice could have been:
Select new gcc, emerge @system, select new release (aka upgrade to 17.0) and emerge @system, emerge @world.....
Would have saved a few days of compiling. |
And it would have resulted in a system with inconsistent libraries, part of them compiled with PIE and part without. Therefore, the 17.0 news item leans on the safe side, rather than giving advice that may save compilation time at the cost of potential breakage. |
I didn't and still dont claim this would be the best way.... obviously you are in a better position to judge.
But is installing gcc 6.4 as given + release of profile 17.0 (with presure to act within weeks) a week later as given a better way of handling this? Probably coordinating the release of 6.4 with profile 17.0 would be the optimal way. (rebuilding systems only once).
And the linguas could have been done in one go with the profile 17.0.
Last edited by noci2 on Sun Feb 04, 2018 8:43 pm; edited 1 time in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Feb 04, 2018 8:36 pm Post subject: |
|
|
| noci2 wrote: | | But is installing gcc 6.4 as given + release of profile 17.0 (with presure to act within weeks) a week later as given a better way of handling this? Probably coordinating the release of 6.4 with profile 17.0 would be the optimal way. (rebuilding systems only once). |
6.4.0 hit the tree on August 30, three months before profile 17.0 It was marked stable eleven days before profile 17.0 was announced.
My only objection is the demise of 13.0, essentially forcing everyone onto hardened. |
|
| Back to top |
|
|
Shibotto
Apprentice
Joined: 19 Jun 2015
Posts: 156
Location: CET/CEST
|
| Posted: Mon Feb 05, 2018 11:05 am Post subject: |
|
|
| mv wrote: | | This USE-flag doesn't exist anymore in any ebuild from the gentoo repository. So setting it has no effect. |
I also had to switch to 17, so it took a lot of time. Anyway everything went fine, than you for your help  |
|
| Back to top |
|
|
noci2
n00b
Joined: 14 Jan 2018
Posts: 10
|
| Posted: Wed Feb 07, 2018 12:08 am Post subject: |
|
|
| Tony0945 wrote: | | noci2 wrote: | | But is installing gcc 6.4 as given + release of profile 17.0 (with presure to act within weeks) a week later as given a better way of handling this? Probably coordinating the release of 6.4 with profile 17.0 would be the optimal way. (rebuilding systems only once). |
6.4.0 hit the tree on August 30, three months before profile 17.0 It was marked stable eleven days before profile 17.0 was announced.
My only objection is the demise of 13.0, essentially forcing everyone onto hardened. |
hm. I only run stable (for most stuff), and don't run updates daily, so 11 days comes down to a week for me, even then a short period.
It wasn't i needed gcc 6.4.0..., it was rather rather strongly pushed, with profile 17 short after.
I had the impression hardened was a lot more than just pie on/off on gcc. (selinux + extra patchset that were lost a year ago). |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Wed Feb 07, 2018 12:19 am Post subject: |
|
|
Yes, hardened is more than that.
There was no way around a hard switch to gcc-6.4.0. Profile 17 also provided an opportunity to mask away all issues related to >=ICU-59 with <GCC-6, broken Qt4 with ICU etc... the reason why 13 must be dropped, it is impossible to support. |
|
| Back to top |
|
|
|
Portage & Programming
