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.

Re: [gentoo-user] problem with emerge @preserved-rebuild

[Mick]

On Friday, 31 May 2019 20:08:45 BST allan gottlieb wrote:
> A few weeks ago I did an eix-sync but (with final exams coming) I did
> not do an emerge --update @world.
> 
> The semester is over so I tried the emerge --update @world (still based
> on the old eix-sync).  Specifically
> 
> emerge --update --newuse --with-bdeps=n  --exclude 
> sys-kernel/linux-firmware --exclude systemd --exclude grub --keep-going
> --deep @world
> 
> It emerged ~55 packages and when finished printed
> 
> !!! existing preserved libs:
> >>> package: app-misc/tracker-2.1.8
> 
>  *  - /usr/lib64/libtracker-sparql-1.0.so.0
>  *  - /usr/lib64/libtracker-sparql-1.0.so.0.1204.0
>  *  used by /usr/lib64/grilo-0.2/libgrltracker.so
> (media-plugins/grilo-plugins-0.2.17) *  used by
> /usr/lib64/nautilus/extensions-3.0/libnautilus-tracker-tags.so
> (gnome-extra/nautilus-tracker-tags-1.12.4) *  -
> /usr/lib64/tracker-1.0/libtracker-common.so.0
>  *  - /usr/lib64/tracker-1.0/libtracker-common.so.0.0.0
>  *  - /usr/lib64/tracker-1.0/libtracker-data.so.0
>  *  - /usr/lib64/tracker-1.0/libtracker-data.so.0.0.0
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> However emerge @preserved-rebuild fails, with output
> 
> emerge: there are no ebuilds to satisfy
> "media-plugins/grilo-plugins:0.2". (dependency required by
> "@preserved-rebuild" [argument])
> 
> eix shows
> 
> [?] media-plugins/grilo-plugins
>  Available versions:  (0.3) 0.3.7 ~0.3.8
>{chromaprint daap dvd examples flickr freebox
> gnome-online-accounts lua subtitles test thetvdb tracker upnp-av vimeo
> +youtube} Installed versions:  0.2.17(0.2)(02:51:05 AM 03/25/2016)(dvd
> gnome-online-accounts tracker upnp-av vimeo youtube -daap -flickr -freebox
> -lua -subtitles -thetvdb) 0.3.7(0.3)(10:24:17 PM 04/18/2019)(dvd
> gnome-online-accounts tracker upnp-av youtube -chromaprint -daap -examples
> -flickr -freebox -lua -subtitles -test -thetvdb -vimeo) Homepage:  
>  https://wiki.gnome.org/Projects/Grilo Description: A collection of
> plugins for the Grilo framework
> 
> So one of my currently installed grilo-plugins is not in the tree.
> 
> What should I do?  The system currently is running fine.
> 
> thanks in advance,
> allan

I would resync and update world.  Then emerge --depclean, followed by 
@preserved-rebuild.  If the problem persists you can remove the obsolete 
version and see if @preserved-rebuild brings in the new version which is in 
the tree - it will if it is a needed dependency.

-- 
Regards,
Mick

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

[gentoo-user] problem with emerge @preserved-rebuild

[allan gottlieb]

A few weeks ago I did an eix-sync but (with final exams coming) I did
not do an emerge --update @world.

The semester is over so I tried the emerge --update @world (still based
on the old eix-sync).  Specifically

emerge --update --newuse --with-bdeps=n  --exclude  
sys-kernel/linux-firmware --exclude systemd --exclude grub --keep-going --deep 
@world

It emerged ~55 packages and when finished printed

!!! existing preserved libs:
>>> package: app-misc/tracker-2.1.8
 *  - /usr/lib64/libtracker-sparql-1.0.so.0
 *  - /usr/lib64/libtracker-sparql-1.0.so.0.1204.0
 *  used by /usr/lib64/grilo-0.2/libgrltracker.so 
(media-plugins/grilo-plugins-0.2.17)
 *  used by 
/usr/lib64/nautilus/extensions-3.0/libnautilus-tracker-tags.so 
(gnome-extra/nautilus-tracker-tags-1.12.4)
 *  - /usr/lib64/tracker-1.0/libtracker-common.so.0
 *  - /usr/lib64/tracker-1.0/libtracker-common.so.0.0.0
 *  - /usr/lib64/tracker-1.0/libtracker-data.so.0
 *  - /usr/lib64/tracker-1.0/libtracker-data.so.0.0.0
Use emerge @preserved-rebuild to rebuild packages using these libraries

However emerge @preserved-rebuild fails, with output

emerge: there are no ebuilds to satisfy "media-plugins/grilo-plugins:0.2".
(dependency required by "@preserved-rebuild" [argument])

eix shows

[?] media-plugins/grilo-plugins
 Available versions:  (0.3) 0.3.7 ~0.3.8
   {chromaprint daap dvd examples flickr freebox gnome-online-accounts 
lua subtitles test thetvdb tracker upnp-av vimeo +youtube}
 Installed versions:  0.2.17(0.2)(02:51:05 AM 03/25/2016)(dvd 
gnome-online-accounts tracker upnp-av vimeo youtube -daap -flickr -freebox -lua 
-subtitles -thetvdb) 0.3.7(0.3)(10:24:17 PM 04/18/2019)(dvd 
gnome-online-accounts tracker upnp-av youtube -chromaprint -daap -examples 
-flickr -freebox -lua -subtitles -test -thetvdb -vimeo)
 Homepage:https://wiki.gnome.org/Projects/Grilo
 Description: A collection of plugins for the Grilo framework

So one of my currently installed grilo-plugins is not in the tree.

What should I do?  The system currently is running fine.

thanks in advance,
allan

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: [gentoo-user] Re: upgrading (profiles, too)

[Jack]

On 5/31/19 9:13 AM, Peter Humphrey wrote:

On Thursday, 30 May 2019 16:32:01 BST »Q« wrote:


The 17.1 profiles are soon to be marked stable, so I went ahead and
migrated a little over a week ago, following the draft news item Michał
Górny recently posted to -dev.  FWIW, the migration seemed to go
smoothly and I haven't noticed anything breaking except
app-office/kmymoney won't build, apparently because the ebuild expects
something to be in /lib which isn't there any more.  But one dev said
it builds fine on his 17.1 test system, so I dunno.  I filed a bug,
.

Encouraged by this, I tried the migration this morning. I followed the enews
item that Mick quoted - I even printed it to keep myself straight.

Before the start:
$ eselect profile show
Current /etc/portage/make.profile symlink:
   default/linux/amd64/17.0/desktop/plasma

I went through the migration, step by step, but after step 7, "unsymlink-lib
--finish", I found 110 files still in /lib and /usr/lib (list attached), of
the >3000 before the migration attempt, and /usr/local/lib still a symlink.
This can't be right, can it?


It's perfectly OK for there to still be stuff under /lib /usr/lib 
/usr/local/lib.  These are supposed to be things which are arch 
independent, such as config stuff and scripts.  However, I'm pretty sure 
none of them should still be a symlink.  What's the link pointing to?  
I'd be tempted to revert the unsymlink.  Did you check the output of 
"unsymlink-lib --analyze" first?

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

[Peter Humphrey]

On Thursday, 30 May 2019 16:32:01 BST »Q« wrote:

> The 17.1 profiles are soon to be marked stable, so I went ahead and
> migrated a little over a week ago, following the draft news item Michał
> Górny recently posted to -dev.  FWIW, the migration seemed to go
> smoothly and I haven't noticed anything breaking except
> app-office/kmymoney won't build, apparently because the ebuild expects
> something to be in /lib which isn't there any more.  But one dev said
> it builds fine on his 17.1 test system, so I dunno.  I filed a bug,
> .

Encouraged by this, I tried the migration this morning. I followed the enews 
item that Mick quoted - I even printed it to keep myself straight.

Before the start:
$ eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/17.0/desktop/plasma

I went through the migration, step by step, but after step 7, "unsymlink-lib 
--finish", I found 110 files still in /lib and /usr/lib (list attached), of 
the >3000 before the migration attempt, and /usr/local/lib still a symlink. 
This can't be right, can it?

-- 
Regards,
Peter.
/lib:
total 3.7M
lrwxrwxrwx 1 root root   12 May  7 11:28 cpp -> /usr/bin/cpp
drwxr-xr-x 4 root root 4.0K May 19 09:43 firmware
drwxr-xr-x 2 root root 4.0K May  7 00:20 gentoo
-rwxr-xr-x 1 root root 164K May  7 02:52 ld-2.29.so
lrwxrwxrwx 1 root root   10 May  7 02:51 ld-linux.so.2 -> ld-2.29.so
-rwxr-xr-x 1 root root  18K May  7 02:52 libanl-2.29.so
lrwxrwxrwx 1 root root   14 May  7 02:51 libanl.so.1 -> libanl-2.29.so
-rwxr-xr-x 1 root root  14K May  7 02:52 libBrokenLocale-2.29.so
lrwxrwxrwx 1 root root   23 May  7 02:51 libBrokenLocale.so.1 -> 
libBrokenLocale-2.29.so
-rwxr-xr-x 1 root root 1.9M May  7 02:52 libc-2.29.so
-rwxr-xr-x 1 root root  42K May  7 02:52 libcrypt-2.29.so
lrwxrwxrwx 1 root root   16 May  7 02:51 libcrypt.so.1 -> libcrypt-2.29.so
lrwxrwxrwx 1 root root   12 May  7 02:51 libc.so.6 -> libc-2.29.so
-rwxr-xr-x 1 root root  18K May  7 02:52 libdl-2.29.so
lrwxrwxrwx 1 root root   13 May  7 02:51 libdl.so.2 -> libdl-2.29.so
-rwxr-xr-x 1 root root 818K May  7 02:52 libm-2.29.so
-rwxr-xr-x 1 root root  18K May  7 02:52 libmemusage.so
lrwxrwxrwx 1 root root   12 May  7 02:51 libm.so.6 -> libm-2.29.so
-rwxr-xr-x 1 root root  98K May  7 02:52 libnsl-2.29.so
lrwxrwxrwx 1 root root   14 May  7 02:51 libnsl.so.1 -> libnsl-2.29.so
-rwxr-xr-x 1 root root  38K May  7 02:52 libnss_compat-2.29.so
lrwxrwxrwx 1 root root   21 May  7 02:51 libnss_compat.so.2 -> 
libnss_compat-2.29.so
-rwxr-xr-x 1 root root  38K May  7 02:52 libnss_db-2.29.so
lrwxrwxrwx 1 root root   17 May  7 02:51 libnss_db.so.2 -> libnss_db-2.29.so
-rwxr-xr-x 1 root root  26K May  7 02:52 libnss_dns-2.29.so
lrwxrwxrwx 1 root root   18 May  7 02:51 libnss_dns.so.2 -> libnss_dns-2.29.so
-rwxr-xr-x 1 root root  54K May  7 02:52 libnss_files-2.29.so
lrwxrwxrwx 1 root root   20 May  7 02:51 libnss_files.so.2 -> 
libnss_files-2.29.so
-rwxr-xr-x 1 root root  22K May  7 02:52 libnss_hesiod-2.29.so
lrwxrwxrwx 1 root root   21 May  7 02:51 libnss_hesiod.so.2 -> 
libnss_hesiod-2.29.so
-rwxr-xr-x 1 root root  14K May  7 02:52 libpcprofile.so
-rwxr-xr-x 1 root root 150K May  7 02:52 libpthread-2.29.so
lrwxrwxrwx 1 root root   18 May  7 02:51 libpthread.so.0 -> libpthread-2.29.so
-rwxr-xr-x 1 root root  86K May  7 02:52 libresolv-2.29.so
lrwxrwxrwx 1 root root   17 May  7 02:51 libresolv.so.2 -> libresolv-2.29.so
-rwxr-xr-x 1 root root  38K May  7 02:52 librt-2.29.so
lrwxrwxrwx 1 root root   13 May  7 02:51 librt.so.1 -> librt-2.29.so
-rwxr-xr-x 1 root root  22K May  7 02:52 libSegFault.so
-rwxr-xr-x 1 root root  43K May  7 02:51 libthread_db-1.0.so
lrwxrwxrwx 1 root root   19 May  7 02:51 libthread_db.so.1 -> 
libthread_db-1.0.so
-rwxr-xr-x 1 root root  14K May  7 02:52 libutil-2.29.so
lrwxrwxrwx 1 root root   15 May  7 02:51 libutil.so.1 -> libutil-2.29.so
drwxr-xr-x 2 root root 4.0K May  7 00:49 modprobe.d
drwxr-xr-x 5 root root 4.0K May 31 09:13 modules
drwxr-xr-x 4 root root 4.0K May  7 00:32 netifrc
drwxr-xr-x 8 root root 4.0K May  7 04:34 rc
drwxr-xr-x 4 root root 4.0K Mar 13 17:02 systemd
drwxr-xr-x 4 root root 4.0K May 21 09:28 udev

/usr/lib:
total 7.1M
drwxr-xr-x 2 root root 4.0K May  7 02:52 audit
drwxr-xr-x 3 root root 4.0K Mar 31 04:56 clang
drwxr-xr-x 2 root root 4.0K May  7 04:26 clc
drwxr-xr-x 3 root root  12K May 31 13:43 cmake
lrwxrwxrwx 1 root root   19 May  7 02:38 consolekit -> /usr/lib/ConsoleKit
drwxr-xr-x 4 root root 4.0K May 31 13:43 ConsoleKit
-rw-r--r-- 1 root root 1.0K May  7 00:41 cracklib_dict.hwm
-rw-r--r-- 1 root root 240K May  7 00:41 cracklib_dict.pwd
-rw-r--r-- 1 root root  13K May  7 00:41 cracklib_dict.pwi
-rw-r--r-- 1 root root 1.5K May  7 02:52 crt1.o
-rw-r--r-- 1 root root 1.1K May  7 02:52 crti.o
-rw-r--r-- 1 root root  440 May  7 02:52 crtn.o
drwxr-xr-x 3 root root 4.0K Mar  7 23:10 gcc
drwxr-xr-x 2 root root  12K May  7 02:52 gconv
-rw-r--r-- 1 root root 2.1K May  7 02:52 gcrt1.o
drwxr-xr-x 2 root roo