Re: Re: Re: [gentoo-user] upgrading (profiles, too)

[Jack]

On 2019.05.31 11:49, n952...@web.de wrote:

> Gesendet: Freitag, 31. Mai 2019 um 00:02 Uhr
> Von: "Dale" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: Aw: Re: [gentoo-user] upgrading (profiles, too)
>
> Mick wrote:
> > On Thursday, 30 May 2019 02:18:01 BST Dale wrote:
 to do. 
>
> If I recall correctly, I did a merge -e world when I switched to  
17.0. 

> There are some things that I'd rather rebuild everything just to be
> sure.  When it is winter time, why not, I need the heat anyway.   
;-) 

>
> Dale
>
> :-)  :-) 
>
>


Compiling is not the problem.  Knowing what USE and KEYWORD flags to  
set is what scares me.  At least those.  I get all these dire  
warnings from the system and I don't know what I did wrong.  I'm  
certainly not in the experimental class.  I try to do the most  
standard, stable things.
You may not have done anything wrong.  How dire an emerge warning is is  
up to interpretation.  One way I sometimes deal with an update that  
throws lots of warnings and requests to change masks or keywords or use  
flags is to look carefully at the list of packages that would be  
updated, and pick one, and just try to update that one.  I even  
sometimes find it easier to just "emerge -1 package" (instead of -u)  
because that seems less likely to try to include updates not needed for  
the package you selected.


Also - I don't think you ever said which (or at least how many)  
packages you already have in packages.keyword.  Often, having one  
package in that file (especially if it is not for a single version)  
will want testing versions of dependencies, so you either have to add  
those, or not use the testing version of the first package.


Portage asking for changes to USE flags is likely far less of an issue  
- sometimes packages are changed so that a dependency now requires a  
particular use flag setting which is not the default (or may be  
affected by some USE flag you have set (or unset) in make.conf.

Aw: Re: Re: [gentoo-user] upgrading (profiles, too)

[n952162]

> Gesendet: Freitag, 31. Mai 2019 um 00:02 Uhr
> Von: "Dale" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: Aw: Re: [gentoo-user] upgrading (profiles, too)
>
> Mick wrote:
> > On Thursday, 30 May 2019 02:18:01 BST Dale wrote:
 to do. 
> 
> If I recall correctly, I did a merge -e world when I switched to 17.0. 
> There are some things that I'd rather rebuild everything just to be
> sure.  When it is winter time, why not, I need the heat anyway.  ;-) 
> 
> Dale
> 
> :-)  :-) 
> 
> 


Compiling is not the problem.  Knowing what USE and KEYWORD flags to set is 
what scares me.  At least those.  I get all these dire warnings from the system 
and I don't know what I did wrong.  I'm certainly not in the experimental 
class.  I try to do the most standard, stable things.

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Mick]

On Friday, 31 May 2019 15:20:01 BST Rich Freeman wrote:
> On Thu, May 30, 2019 at 6:02 PM Dale  wrote:
> > Given that is going to involve quite a bit of changes, and it appears
> > the OP has a outdated system, going in steps may be a good idea.  At
> > least that way if something breaks, it may be easier to fix since the
> > steps are smaller.
> 
> ++
> 
> I would never attempt a profile change unless I had a system running
> on a repo that was completely up to date, with no pending updates.
> That is, if you run emerge --sync and emerge -uD world nothing happens
> (well, aside from the random one package that just happened to
> change).
[snip ...]

If I were to install a new system presently and wanted to go straight to a 
17.1 profile, is there some particular stage tarball I could/should be 
downloading to by-pass all this lib (un)linkage goodness?

In the same vane I wonder if the OP's problems would be resolved by a 
reinstall of Gentoo, while retaining the same world file and perhaps /etc?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Rich Freeman]

On Thu, May 30, 2019 at 6:02 PM Dale  wrote:
>
> Given that is going to involve quite a bit of changes, and it appears
> the OP has a outdated system, going in steps may be a good idea.  At
> least that way if something breaks, it may be easier to fix since the
> steps are smaller.
>

++

I would never attempt a profile change unless I had a system running
on a repo that was completely up to date, with no pending updates.
That is, if you run emerge --sync and emerge -uD world nothing happens
(well, aside from the random one package that just happened to
change).

If you try to do the migration on a tree that is many months old with
old system packages on it, there is no guarantee that all the critical
packages on your system support the new profile.  We ensure all that
stuff gets fixed before we tell people to change profiles, but if
you're running a system that predates all the fixes then you're going
to run into all the old bugs that were already fixed.

The profile change isn't super-urgent. First get all the /etc/portage
cruft fixed, then get the system to cleanly update.  Then sync to a
new repo and run updates again.  Once you have a completely fresh
system the profile update should be fine, though this change is more
impactful than most.

The 17.0 update is much lower risk, and that is many months old, so
there is much less risk of running into issues.  Even so I wouldn't do
it with pending updates on the system.

Really the guiding principle here is to not accumulate technical debt.
When you don't sync very regularly you're accumulating technical debt.
When you leave unmerged config files lying around you're accumulating
technical debt.  When you don't update profiles, you get the
picture...

Any one of these issues on their own might not cause immediate
problems, but as you accumulate these issues you can find yourself
suddenly hitting a wall at full speed and just getting error after
error and having no idea which of your 47 accumulated issues is
causing which of the 150 lines of portage error output.  Then you're
stuck just going through and trying to clean everything up with half
the system not working.

If you deal with issues as they come up so that at any time only one
thing at a time is changing, then you're less likely to get hit with
an update where the system wants to update 500 packages at one time
and it is impossible to deal with all the issues that come up as a
result.  You can even run into upstream issues when you update
infrequently as they might not support doing 3 upgrades at one time
and nobody at Gentoo will have tested this...

-- 
Rich

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Dale]

Mick wrote:
> On Thursday, 30 May 2019 02:18:01 BST Dale wrote:
>
>> I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
>> 17.0 and wait until 17.1 is released. 
>>
>> Dale
>>
>> :-)  :-) 
> The 17.1 profile does away with separate /lib directories as explained here:
>
> https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
>
> <<>
>
> 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.
> =
>
> HTH.


Given that is going to involve quite a bit of changes, and it appears
the OP has a outdated system, going in steps may be a good idea.  At
least that way if something breaks, it may be easier to fix since the
steps are smaller. 

As usual tho, it depends.  It may be easy enough to go to 17.1 but then
again, it could create a mess.  I guess it is up to the OP which route
to go and how much compiling he wants to do. 

If I recall correctly, I did a merge -e world when I switched to 17.0. 
There are some things that I'd rather rebuild everything just to be
sure.  When it is winter time, why not, I need the heat anyway.  ;-) 

Dale

:-)  :-) 

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Mick]

On Thursday, 30 May 2019 02:18:01 BST Dale wrote:

> I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
> 17.0 and wait until 17.1 is released. 
> 
> Dale
> 
> :-)  :-) 

The 17.1 profile does away with separate /lib directories as explained here:

https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout

From the relevant enews item:

===
2017-12-26-experimental-amd64-17-1-profiles
  Title Experimental amd64 17.1 profiles up for testing
  AuthorMichał Górny 
  Posted2017-12-26
  Revision  3

A new set of 17.1 amd64 profiles has been added to the Gentoo
repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require explicit migration as described below. They
are considered experimental at the moment, and have a fair risk
of breaking your system. We would therefore like to ask our users to
test them on their non-production ~amd64 systems.

In those profiles, the lib->lib64 compatibility symlink is removed.
The 'lib' directory becomes a separate directory, that is used
for cross-arch and native non-library packages (gcc, clang) and 32-bit
libraries on the multilib profile (for better compatibility with
prebuilt x86 packages).

Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, please read the news item for 17.0 upgrade first
and enable gcc 6.4.0 or newer first as explained there.

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes. If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system and see if it still boots. Check if important
   programs work. In particular, check if e.g. 'emerge --info' works
   (but do not install anything). If you hit any serious problems,
   you can use 'unsymlink-lib --rollback' to revert the changes
   and return to step 3.

7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

 eselect profile set --force default/linux/amd64/17.1/desktop

[at this point you can start using emerge again]

9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles,
   rebuild sys-devel/binutils and sys-libs/glibc afterwards.

10. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:

  emerge -1v /lib32 /usr/lib32

Alternatively, if you are switching from one of the 13.0 profiles
you can rebuild all packages as detailed in the 17.0 news item.

11. Once the last 32-bit package is rebuilt, your package manager
should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
does not happen, remove them manually.

For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.

For more information on the layout, please see the wiki article
on AMD64 multilib layouts [2].

[1]:https://bugs.gentoo.org/506276
[2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
==


BTW, the OP may want to read the enews item for upgrading to 17.0 profile 
first, just in case he needs to make any changes to his gcc and rebuild his 
toolchain:

==
2017-11-30-new-17-profiles
  Title New 17.0 profiles in the Gentoo repository
  AuthorAndreas K. Hüttel 
  Posted2017-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, har

Aw: Re: Re: [gentoo-user] upgrading (profiles, too)

[n952162]

that's a good libk, too

> Gesendet: Donnerstag, 30. Mai 2019 um 03:04 Uhr
> Von: "Adam Carter" 
> An: gentoo-user@lists.gentoo.org
> Betreff: Re: Re: [gentoo-user] upgrading (profiles, too)
>
> On Thu, May 30, 2019 at 8:41 AM  wrote:
>
> > > Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
> > > Von: "Dale" 
> > > I've done upgrades that skip quite a ways using make oldconfig.  I've
> > > never had any issues.  If it were me, I'd just make the jump but make
> > > sure to keep the old kernel around just in case something doesn't work.
> > > At least that way one can boot it and fix it.
> >
> > good idea!
> > Is the kernel enough?  Don't you have to have the initrd, and the modules
> > list and all the modules and and and?
> >
> >
> https://wiki.gentoo.org/wiki/Kernel/Upgrade should help.
>
>
> >
> > > ...  Switch to the
> > > new17.1 profile, run emerge -puDN world and see if the changes look OK.
> > > If you don't like or it breaks something, switch to 17.0 and run emerge
> > > -puDN world and see what it looks like.  Pick the one that you feel
> > > safest with.  ...
> >
> > I haven't a clue what unsafe is...
> >
> > Pick the one that most closely matches your requirements.
>

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Dale]

n952...@web.de wrote:
>> Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
>> Von: "Dale" 
>> I've done upgrades that skip quite a ways using make oldconfig.  I've
>> never had any issues.  If it were me, I'd just make the jump but make
>> sure to keep the old kernel around just in case something doesn't work. 
>> At least that way one can boot it and fix it.
> good idea!
> Is the kernel enough?  Don't you have to have the initrd, and the modules 
> list and all the modules and and and?
>


If you have one, yes you need to save that too.  The biggest thing, make
sure the entry is still in whatever bootloader you use.  I use grub and
it picks them up automatically when I run the updater. 


>> ...  Switch to the
>> new17.1 profile, run emerge -puDN world and see if the changes look OK. 
>> If you don't like or it breaks something, switch to 17.0 and run emerge
>> -puDN world and see what it looks like.  Pick the one that you feel
>> safest with.  ...
> I haven't a clue what unsafe is...
>
>


I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
17.0 and wait until 17.1 is released. 

Dale

:-)  :-) 

Re: Re: [gentoo-user] upgrading (profiles, too)

[Adam Carter]

On Thu, May 30, 2019 at 8:41 AM  wrote:

> > Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
> > Von: "Dale" 
> > I've done upgrades that skip quite a ways using make oldconfig.  I've
> > never had any issues.  If it were me, I'd just make the jump but make
> > sure to keep the old kernel around just in case something doesn't work.
> > At least that way one can boot it and fix it.
>
> good idea!
> Is the kernel enough?  Don't you have to have the initrd, and the modules
> list and all the modules and and and?
>
>
https://wiki.gentoo.org/wiki/Kernel/Upgrade should help.


>
> > ...  Switch to the
> > new17.1 profile, run emerge -puDN world and see if the changes look OK.
> > If you don't like or it breaks something, switch to 17.0 and run emerge
> > -puDN world and see what it looks like.  Pick the one that you feel
> > safest with.  ...
>
> I haven't a clue what unsafe is...
>
> Pick the one that most closely matches your requirements.

Aw: Re: [gentoo-user] upgrading (profiles, too)

[n952162]

> Gesendet: Donnerstag, 30. Mai 2019 um 00:20 Uhr
> Von: "Dale" 
> I've done upgrades that skip quite a ways using make oldconfig.  I've
> never had any issues.  If it were me, I'd just make the jump but make
> sure to keep the old kernel around just in case something doesn't work. 
> At least that way one can boot it and fix it.

good idea!
Is the kernel enough?  Don't you have to have the initrd, and the modules list 
and all the modules and and and?


> ...  Switch to the
> new17.1 profile, run emerge -puDN world and see if the changes look OK. 
> If you don't like or it breaks something, switch to 17.0 and run emerge
> -puDN world and see what it looks like.  Pick the one that you feel
> safest with.  ...

I haven't a clue what unsafe is...

Re: [gentoo-user] upgrading (profiles, too)

[Dale]

Michael Jones wrote:
>
>
> On Wed, May 29, 2019 at 2:46 PM  > wrote:
>
> Hi,
>
> I'm currently at 4.14.65-gentoo and I understand my cheap hp
> laptop's amdgpu could finally get better support if I upgrade to
> 4.16 or 4.17.1.
> Can I just do that, or would it be better (or even possible) to go
> in smaller increments?
>
> Also, something's always complaining to me about my profile,
> default/linux/amd64/13.0/desktop, being out-of-date.  Should I
> upgrade to 17 at the same time?  I've seen lots about the
> differences between different types of profiles but not about the
> differences between different versions of a profile type.  What's
> different?
>
> Thanks for any thoughts.
>
>
> You can change kernel versions in any way you see fit. You're unlikely
> to run into any significant issues from upgrading by 2 or 3 releases
> at once.

I've done upgrades that skip quite a ways using make oldconfig.  I've
never had any issues.  If it were me, I'd just make the jump but make
sure to keep the old kernel around just in case something doesn't work. 
At least that way one can boot it and fix it.


>
> My personal recommendation is to conduct the profile update as a
> separate task from the kernel update, simply because they are not
> really related to each other.
>

I would do them separately as well.  I'm not sure if it matters but I
might would do the profile upgrade first.  I'm not sure why but my brain
is making me think that may be a better way.  Generally, profile changes
don't change a whole lot.  Also, I think 17.1 is coming soon and 17.0
will be leaving.  If one feels safe doing it, it may be worth going
straight to 17.1.  That way one wouldn't have to do the same thing again
soon-ish.  It's marked as dev but this is what I'd do.  Switch to the
new17.1 profile, run emerge -puDN world and see if the changes look OK. 
If you don't like or it breaks something, switch to 17.0 and run emerge
-puDN world and see what it looks like.  Pick the one that you feel
safest with.  Just keep in mind, 17.1 is coming at some point.

Just my thoughts.

Dale

:-)  :-) 

Re: [gentoo-user] upgrading (profiles, too)

[Michael Jones]

On Wed, May 29, 2019 at 2:46 PM  wrote:

> Hi,
>
> I'm currently at 4.14.65-gentoo and I understand my cheap hp laptop's
> amdgpu could finally get better support if I upgrade to 4.16 or 4.17.1.
> Can I just do that, or would it be better (or even possible) to go in
> smaller increments?
>
> Also, something's always complaining to me about my profile,
> default/linux/amd64/13.0/desktop, being out-of-date.  Should I upgrade to
> 17 at the same time?  I've seen lots about the differences between
> different types of profiles but not about the differences between different
> versions of a profile type.  What's different?
>
> Thanks for any thoughts.
>
>
You can change kernel versions in any way you see fit. You're unlikely to
run into any significant issues from upgrading by 2 or 3 releases at once.

My personal recommendation is to conduct the profile update as a separate
task from the kernel update, simply because they are not really related to
each other.