[gentoo-user] how to recover a portage that wasn't in use for very long time

[gentoo-user] how to recover a portage that wasn't in use for very long time

[Alexey Luchko]

Hi!

I have a gentoo installed, but I wasn't updating it since late 2007, I  
suppose.
Today I've run emerge --sync. It worked! It's great ;)

But then I've got the following collision. Obviously, a portage update  
is required. But it is confused by dependencies:
colinux ~ # emerge portage --pretend --tree

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
[ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% - 
plugins%"
[ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
[ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
[ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
[ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
[ebuild  N    ]  app-admin/eselect-news-20080320
[ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
[ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
[blocks B     ] <sys-apps/portage-2.1.5 (is blocking app-shells/ 
bash-3.2_p39)
colinux ~ #


How to get it out?


Regards,
Alexey.

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

On Sun, 10 May 2009 03:58:41 +0300
Alexey Luchko <luchik@gmail.com> wrote:

> But then I've got the following collision. Obviously, a portage update  
> is required. But it is confused by dependencies:
> colinux ~ # emerge portage --pretend --tree
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% - 
> plugins%"
> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> [ebuild  N    ]  app-admin/eselect-news-20080320
> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking app-shells/ 
> bash-3.2_p39)
> colinux ~ #
> 
> 
> How to get it out?

Try masking newer bash which blocks older portage, unmasking it after
the newer portage is in place.

If you have app-portage/gentoolkit installed, you can find out which
specific versions of bash it depends on using the following command:

  equery depgraph --depth 1 portage | grep bash

Otherwise you can use "portage --tree" or just look for DEPEND and
RDEPEND vars in the ebuild itself, which can be found in /var/db/pkg.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Sun, 10 May 2009 07:54:34 +0600
Mike Kazantsev <mike_kazantsev@fraggod.net> wrote:

> Otherwise you can use "portage --tree" or just look for DEPEND and
> RDEPEND vars in the ebuild itself, which can be found in /var/db/pkg.

I mean "emerge --tree", of course ;)

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Stroller]

On 10 May 2009, at 01:58, Alexey Luchko wrote:
> ...
> But then I've got the following collision. Obviously, a portage  
> update is required. But it is confused by dependencies:
> colinux ~ # emerge portage --pretend --tree
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% - 
> plugins%"
> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> [ebuild  N    ]  app-admin/eselect-news-20080320
> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim- 
> syntax%"
> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking app-shells/ 
> bash-3.2_p39)
> colinux ~ #

Hi there,

I have done some similar kinds of updates. Once stuff has been removed  
from the tree it becomes a bit painful. I have had success, however,  
reading the blocked ebuilds to find which versions of dependency  
ebuilds are required, and then getting them from Gentoo's CVS "attic" <http://sources.gentoo.org/ 
 >. You can place these in your local overlay and then `emerge  
=category/package-version` to overcome the blocker.

This is probably a fair bit of work - one machine here is so old that  
I accept I'll never get it updated (and a reinstall will be required,  
when I get around to it), on another the work is not complete. On that  
latter machine I have successfully updated some important packages to  
the latest version (previously updated September 2007) by using this  
method, but it required at least 2 or 3 blockers manually resolved  
this way, and it did "feel" ugly. I suggest frequent use of `revdep- 
rebuild`, `python-updater` and whatever else you can think of.

`emerge -pv --update world` on that machine still shows 202 packages  
in need of updating, so this will need repeating a number of times.

I think a number of people here would tell you that this isn't  
worthwhile, to back up /home directories & config files and to  
reinstall, but personally I'm reluctant to do that in the case of a  
working system on which users depend. So it _does_ appear possible to  
upgrade using this tedious method.

In your case, I think you would first try to emerge =sys-apps/ 
portage-2.1.5, in order to unblock app-shells/bash-3.2_p39. This will  
(surely) result in another blocker - resolve that first, then emerge  
=sys-apps/portage-2.1.5 then try again to upgrade to the latest portage.

Good luck!

Stroller.

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Alan McKinnon]

On Sunday 10 May 2009 02:58:41 Alexey Luchko wrote:
> Hi!
>
> I have a gentoo installed, but I wasn't updating it since late 2007, I
> suppose.
> Today I've run emerge --sync. It worked! It's great ;)
>
> But then I've got the following collision. Obviously, a portage update
> is required. But it is confused by dependencies:
> colinux ~ # emerge portage --pretend --tree
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% -
> plugins%"
> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> [ebuild  N    ]  app-admin/eselect-news-20080320
> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking app-shells/
> bash-3.2_p39)
> colinux ~ #

Once you sort that out, there's a whole host of other stuff to fix as well - 
expat, latest xorg and many more - all stuff that everyone else fixed a while 
ago and since forgot.

If you've never done this before, it's a good learning experience to do it 
(but only once). Thereafter, just reinstall - the pain of upgrading after 18 
months just isn't worth it

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Francesco Talamona]

On Sunday 10 May 2009, Alan McKinnon wrote:
> Once you sort that out, there's a whole host of other stuff to fix as
> well - expat, latest xorg and many more - all stuff that everyone
> else fixed a while ago and since forgot.

Yes, beware of mktemp/coreutils too.
I don't remember of other dangers, maybe pam...

Ciao
	Francesco

-- 
Linux Version 2.6.29-gentoo-r3, Compiled #2 SMP PREEMPT Sat May 9 
18:15:29 CEST 2009
Two 2.9GHz AMD Athlon 64 Processors, 4GB RAM, 11653 Bogomips Total
aemaeth

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Nick Fortino]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

Alexey Luchko wrote:
> Hi!
>
> I have a gentoo installed, but I wasn't updating it since late 2007, I 
> suppose.
> Today I've run emerge --sync. It worked! It's great ;)
>
> But then I've got the following collision. Obviously, a portage update 
> is required. But it is confused by dependencies:
> colinux ~ # emerge portage --pretend --tree
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% 
> -plugins%"
> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> [ebuild  N    ]  app-admin/eselect-news-20080320
> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking 
> app-shells/bash-3.2_p39)
> colinux ~ #
>
>
> How to get it out?
>
>
> Regards,
> Alexey.
>
>
>
>
I worked on this a couple months back to make it possible. The key is to 
download binary packages of portage and a few dependencies to break the 
block. Once portage is upgraded, it's smart enough to figure things out 
now. An original script an discussion can be found at 
http://blog.jolexa.net/2009/03/25/gentoo-tips-to-upgrade-your-really-old-installation/

A slightly modified version is here inline. I would recommend against 
running it as a script, but rather do the steps individually (also, if 
you aren't running amd64, be sure to change the architecture of the 
binaries you are downloading).

Read this line as typical warnings of your mileage may very etc.

Nick

[-- Attachment #2: upgrade_guide.txt --]
[-- Type: text/plain, Size: 3771 bytes --]

#Version 0.2, written by Nick Fortino 
#April 03, 2009
#This is known to work on systems younger than 2006.1, and suspected to fail
#on anything older due to <glibc-2.4 incompatibility.

#This is an experimental guide on how to upgrade an old system to get to
#portage 2.1.6.7. Once this state is achieved, portage can do the rest, with
#decent dependency resolution. 

###########################################################################
#Between the first tar command and the success of 'emerge -K ...', the
#true state of the system, and the state according to portage are different.
#This is rather unsafe, so be sure you understand what you are doing.
#Consider this your big red warning to backup important files before attempting
#an update, and consider a re-install if possible.
###########################################################################

#It may be wise to use the default make.conf, as we would like to rebuild
#as few packages as possible before the toolchain has been updated, and use
#flags will bring in a bunch of dependencies.

#Update the symlink to an existing profile
unlink /etc/make.profile
ln -s ../usr/portage/profiles/default/linux/amd64/2008.0 /etc/make.profile

#Fetch and forcefully upgrade python, bash, and portage with prebuilt sources
#The naming of the directory All is important, as we are going to use /root
#as binary package source later on
mkdir All
cd All
wget http://tinderbox.dev.gentoo.org/default-linux/amd64/dev-lang/python-2.5.2-r7.tbz2
wget http://tinderbox.dev.gentoo.org/default-linux/amd64/app-shells/bash-3.2_p39.tbz2
wget http://tinderbox.dev.gentoo.org/default-linux/amd64/sys-apps/portage-2.1.6.7.tbz2
cd /
tar xfpj root/All/python-2.5.2-r7.tbz2
tar xfpj root/All/bash-3.2_p39.tbz2
tar xfpj root/All/portage-2.1.6.7.tbz2

#emerge these packages, so that portage is informed as to what is going on
PKGDIR="/root" emerge -K --nodeps python bash portage

#See what will be upgraded, there should be no unresolved blockers
emerge -puDNv system

#Unfortunately, on anything except a stage3 only build, there could be
#This is due to the fact that we aren't updating all of world
#Run emerge -pvuDN world, if that has no blockers, there is a 
#rather simple solution. If that has blockers, your on your own.
#Read the text of the blockers, figure out which additional packages 
#need upgrading to make everything work, and append them to the command. 
#An example:
#emerge -pvuDN system hal mit-krb5

#Perform the update, this command will likely make good progress, and then fail
emerge -auDN system

############
#Known failures and solutions
############

#Python updater and python split, creating a confilct, resolve by removing
#the old file
rm /usr/sbin/python-updater
emerge -a1 python-updater
emerge -a1 python
#Cracklib is  wants -unmerge-orphans
FEATURES='-unmerge-orphans' emerge -a1 cracklib
#continue the upgrade
emerge -auDN system


############
#Cleanup
############

#Update the current terminal
env-update
source /etc/profile
#Deal with the many /etc files which need updating
emerge gentoolkit
dispatch-conf

#At this point, the toolchain has been rebuilt, which likely involved an upgrade
#of gcc. Follow http://www.gentoo.org/doc/en/gcc-upgrading.xml to finish the 
#upgrade. A lot of what is requested there has likely been done automatically,
#so in summary:

#Check that gcc-config is using the correct compiler, if not, follow the above
#guide
gcc-config -l

#Replace your make.conf/update to whatever profile you choose/etc.
#Rebuild the system with the new toolchain, and custom settings
emerge -eav system
#Rebuild and update world with new toolchain and settings
emerge -eav world

#Finally, remove any old packages which still survived the process
emerge --depclean -a

Re: [gentoo-user] how to recover a portage that wasn't in use for very long time

[Alexey Luchko]

Nick Fortino wrote:
> Alexey Luchko wrote:
>> I have a gentoo installed, but I wasn't updating it since late 2007, I 
>> suppose.
>> Today I've run emerge --sync. It worked! It's great ;)
>>
>> But then I've got the following collision. Obviously, a portage update 
>> is required. But it is confused by dependencies:
>> colinux ~ # emerge portage --pretend --tree
>> These are the packages that would be merged, in reverse order:
>> [cut]
>> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking 
>> app-shells/bash-3.2_p39)
>> colinux ~ #
>>
> I worked on this a couple months back to make it possible. The key is to 
> download binary packages of portage and a few dependencies to break the 
> block. Once portage is upgraded, it's smart enough to figure things out 
> now. An original script an discussion can be found at 
> http://blog.jolexa.net/2009/03/25/gentoo-tips-to-upgrade-your-really-old-installation/ 
> 
> A slightly modified version is here inline. I would recommend against 
> running it as a script, but rather do the steps individually (also, if 
> you aren't running amd64, be sure to change the architecture of the 
> binaries you are downloading).
> 
> Read this line as typical warnings of your mileage may very etc.

I decided to try this way first.

I've got a problem on the way and hopefully restored the system.
The problem appeared after downloading and extracting new bash:
wget 
http://tinderbox.dev.gentoo.org/default-linux/x86/app-shells/bash-3.2_p39.tbz2
tar xfpj root/All/bash-3.2_p39.tbz2

Every next execution of bash (and sh also) gave me:
colinux ~ # sh
sh: /lib/libc.so.6: version `GLIBC_2.4' not found (required by sh)

I didn't get through it, but rather restored the partition from backup.
By the way, does one know a windows tool, that can write a partition directly?

If one is interested, I managed to get this way:
I had the backup on the windows host system.
I replaced my root's shell with /usr/bin/python and wrote a script that did 
what "cat > /dev/cobd/4" would do if it was available.
The I restored the system running the following:
$ gzip -d < /z/inst/colinux/colinux20090512.img.gz | ssh root@colinux -C 
'execfile("cat.py"); cat("/dev/cobd/4")'

It's really funny, but writing these lines I've understand that I had mounted 
host file system, and I could have restored the backup through it.


Have a nice time ;)
Alexey.

[gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Alexey Luchko]

Alexey Luchko wrote:
> colinux ~ # emerge portage --pretend --tree
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done!
> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% 
> -plugins%"
> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> [ebuild  N    ]  app-admin/eselect-news-20080320
> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking 
> app-shells/bash-3.2_p39)
> colinux ~ #

Hi!

Thank every one for your help.

Finally I got it out this way:
first  emerge --nodeps bash
then  emerge portage  upgraded portage to the latest version
and then, of cause,  emerge -uDN system -pvt
it had blocked packages
[blocks B     ] <sys-apps/man-pages-3 ("<sys-apps/man-pages-3" is blocking
sys-apps/man-pages-posix-2003a)
[blocks B     ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is blocking
sys-libs/e2fsprogs-libs-1.41.3-r1)
[blocks B     ] sys-apps/mktemp ("sys-apps/mktemp" is blocking
sys-apps/coreutils-7.1)
[blocks B     ] sys-libs/com_err ("sys-libs/com_err" is blocking
sys-libs/e2fsprogs-libs-1.41.3-r1)
[blocks B     ] <sys-apps/util-linux-2.13 ("<sys-apps/util-linux-2.13" is
blocking sys-apps/coreutils-7.1)
[blocks B     ] sys-libs/ss ("sys-libs/ss" is blocking
sys-libs/e2fsprogs-libs-1.41.3-r1)

I unmerged them, and then  emerge -uDN system  had been working fine until
sys-libs/e2fsprogs-libs-1.41.3-r1 compilation failed with
../../lib/libuuid.so: undefined reference to `___tls_get_addr'

I had no separate uuid package installed
colinux ~ # emerge --search uuid | less
Searching...
[ Results for search key : uuid ]
[ Applications found : 4 ]
*  dev-libs/ossp-uuid [ Masked ]
       Latest version available: 1.6.2
       Latest version installed: [ Not Installed ]
*  dev-perl/Data-UUID
       Latest version available: 1.148
       Latest version installed: [ Not Installed ]
*  dev-python/uuid [ Masked ]
       Latest version available: 1.30
       Latest version installed: [ Not Installed ]
*  dev-ruby/uuidtools
       Latest version available: 1.0.7
       Latest version installed: [ Not Installed ]


It claimed on
/usr/tmp/portage/sys-libs/e2fsprogs-libs-1.41.3-r1/work/e2fsprogs-libs-1.41.3/lib/libuuid.so

I checked whether the name tls_get_addr exists and found nothing
colinux e2fsprogs-libs-1.41.3 # pwd
/usr/tmp/portage/sys-libs/e2fsprogs-libs-1.41.3-r1/work/e2fsprogs-libs-1.41.3
colinux e2fsprogs-libs-1.41.3 # grep tls_get_addr `find . -iname '*.c'`

After seaching tls_get_addr on http://www.google.com/codesearch I decided to
update glibc first:
colinux ~ # emerge glibc -pvt

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild     U ] sys-libs/glibc-2.8_p20080602-r1 [2.3.6-r4] USE="-debug% -gd%
-glibc-omitfp (-hardened) (-multilib) -nls* -profile (-selinux) -vanilla%
(-build%) (-erandom%) (-glibc-compat20%) (-nptl%) (-nptlonly%)" 0 kB [?=>0]

Total: 1 package (1 upgrade), Size of downloads: 0 kB
Portage tree and overlays:
  [0] /usr/portage
  [?] indicates that the source repository could not be determined

  * IMPORTANT: 1 news items need reading for repository 'gentoo'.
  * Use eselect news to read news items.

colinux ~ # emerge glibc

  * i386 CHOSTs are no longer supported.
  * Chances are you don't actually want/need i386.
  * Please read http://www.gentoo.org/doc/en/change-chost.xml

Here I've decided to make yet another backup and tried to remount / readonly.
And found the mount missing. I'm guessing that util-linux is the package 
containing mount and it depends on e2fsprogs-libs-1.41.3-r1.


Here I am now ;)
Any advice is welcome!


Alexey.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Alan McKinnon]

On Wednesday 13 May 2009 12:03:40 Alexey Luchko wrote:
> Alexey Luchko wrote:
> > colinux ~ # emerge portage --pretend --tree
> >
> > These are the packages that would be merged, in reverse order:
> >
> > Calculating dependencies... done!
> > [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> > [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples%
> > -plugins%"
> > [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
> > [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
> > [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
> > [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
> > [ebuild  N    ]  app-admin/eselect-news-20080320
> > [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim-syntax%"
> > [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
> > [blocks B     ] <sys-apps/portage-2.1.5 (is blocking
> > app-shells/bash-3.2_p39)
> > colinux ~ #
>
> Hi!
>
> Thank every one for your help.

[snip long sad story of portage blockers]

> Here I am now ;)
> Any advice is welcome!

Why are you doing this? Is it to learn how to cope with such things?

If not, you are really wasting time that you will never get back. The last 18 
months has seen much activity in the tree, lot's of it from large packages 
being split into smaller ones, and blockers installed.

You've already come across mktemp/coreutils and e2fsprogs. You still have to 
deal with bash/python then that delicious recent cock-up with wget, expat and 
you have to decide if you want com_err or not. And plenty more. This all 
happened so long ago I forget the details (lucky for you it's all in the mail 
archives!).

Trust me, if this is not a learning exercise, just unmount your data volumes 
and reinstall the machine. The pain is not worth it. Really. Especially if 
glibc decides it doesn't like your headers, then you really are up the creek 
if you didn't quickpkg critical apps in the system set first :-)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Stroller]

On 13 May 2009, at 11:17, Alan McKinnon wrote:
> ...
> Why are you doing this? Is it to learn how to cope with such things?
>
> If not, you are really wasting time that you will never get back. ...
>
> Trust me, if this is not a learning exercise, just unmount your data  
> volumes
> and reinstall the machine. The pain is not worth it. Really. ...

I'm inclined to disagree with you here. Obviously, it depends on the  
user - as I've undertaken this, I knew not to bother asking here  
because I knew I'd receive exactly this response. I examined ebuilds  
to see the blockers & looked up compatible versions in the portage  
attic, and I did my own searches when I came to problems like this  
one. And so far I've been ok.

In my case, reinstallation would be a huge pain. I would be massively  
worrying about which services on the machine I need to configure  
again, and whether everything I needed had been backed up properly. I  
have forgotten the original procedures I followed setting up many of  
these services, and it could easily take a week to set the machine up  
from scratch.

If I upgrade the "obsolete portage" incrementally, I know that  
everything is still working, and I update the machine without  
disruption to the users who depend upon the machine. If a service  
fails during the procedure, then it is only ONE service that I have to  
fix, not several. As I upgrade a package & run etc-update I can back  
up the original config files, and if I find the new ones are vastly  
different then I can refer to the originals &/or diff them in.

If this upgrade procedure is undertaken cautiously, then it is no  
worse or different than it was when the changes originally entered the  
portage tree. One can `emerge -pv world` and then emerge the first  
package with --oneshot, rinse & repeat. Sure, this is potentially time- 
consuming, but I can leave packages compiling whilst I'm doing other  
things - reinstalling from scratch a base Gentoo installation isn't  
too bad (hardware, logger, housekeeping), but once you add in a number  
of services then I'm going to need to dedicate some time to the job.

I'm not reading Alexey too clearly, but it seems to me that he is  
saying he has a full system backup. In this case one can restore to  
that in minutes if something goes hosed badly during an emerge or if  
the users come in the next morning & complain that $facility isn't  
working.

I'm NOT saying that this procedure is for everyone, but equally I  
don't think it's fair to say there's NEVER any justification for it.

Stroller.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Alan McKinnon]

On Wednesday 13 May 2009 16:16:10 Stroller wrote:
> In my case, reinstallation would be a huge pain. I would be massively  
> worrying about which services on the machine I need to configure  
> again, and whether everything I needed had been backed up properly. I  
> have forgotten the original procedures I followed setting up many of  
> these services, and it could easily take a week to set the machine up  
> from scratch.

But whether you reinstall (backing up and replacing old configs then runnign 
diff of course) or incrementally upgrade, and $SERVICE breaks, either way you 
equally do not know about it till $USER complains.

It's just that I remember all too well what it took to get through those many 
various blockers. More often than not I was once of the first to run into them 
- I sync and update daily - but I'd hate to do it all again all in one go, 
especially when all my buddies here have forgotten the procedure.

Horses for courses I guess.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Stroller]

On 13 May 2009, at 11:03, Alexey Luchko wrote:

> Alexey Luchko wrote:
>> colinux ~ # emerge portage --pretend --tree
>> These are the packages that would be merged, in reverse order:
>> Calculating dependencies... done!
>> [nomerge      ] sys-apps/portage-2.1.6.11 [2.1.2.2]
>> [ebuild     U ]  app-shells/bash-3.2_p39 [3.1_p17] USE="-examples% - 
>> plugins%"
>> [ebuild     U ] sys-apps/portage-2.1.6.11 [2.1.2.2]
>> [ebuild     U ]  dev-python/pycrypto-2.0.1-r6 [2.0.1-r5]
>> [ebuild     U ]  sys-apps/sandbox-1.6-r2 [1.2.17]
>> [ebuild  N    ]   app-arch/lzma-utils-4.32.7  USE="-nocxx"
>> [ebuild  N    ]  app-admin/eselect-news-20080320
>> [ebuild     U ]   app-admin/eselect-1.0.11-r1 [1.0.7] USE="-vim- 
>> syntax%"
>> [ebuild     U ]  app-misc/pax-utils-0.1.19 [0.1.15]
>> [blocks B     ] <sys-apps/portage-2.1.5 (is blocking app-shells/ 
>> bash-3.2_p39)
>> colinux ~ #
>
> Hi!
>
> Thank every one for your help.
>
> Finally I got it out this way:
> first  emerge --nodeps bash
> then  emerge portage  upgraded portage to the latest version
> and then, of cause,  emerge -uDN system -pvt
> it had blocked packages
> [blocks B     ] <sys-apps/man-pages-3 ("<sys-apps/man-pages-3" is  
> blocking
> sys-apps/man-pages-posix-2003a)
> [blocks B     ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is  
> blocking
> sys-libs/e2fsprogs-libs-1.41.3-r1)
> [blocks B     ] sys-apps/mktemp ("sys-apps/mktemp" is blocking
> sys-apps/coreutils-7.1)
> [blocks B     ] sys-libs/com_err ("sys-libs/com_err" is blocking
> sys-libs/e2fsprogs-libs-1.41.3-r1)
> [blocks B     ] <sys-apps/util-linux-2.13 ("<sys-apps/util- 
> linux-2.13" is
> blocking sys-apps/coreutils-7.1)
> [blocks B     ] sys-libs/ss ("sys-libs/ss" is blocking
> sys-libs/e2fsprogs-libs-1.41.3-r1)
>
> I unmerged them, and then  emerge -uDN system  had been working fine  
> until
> sys-libs/e2fsprogs-libs-1.41.3-r1 compilation failed with
> ../../lib/libuuid.so: undefined reference to `___tls_get_addr'



Alexey,

I think `emerge --nodeps bash` was the cause of your problem. You need  
to resolve each and every dependency - often sequentially or  
incrementally - before you go on to the next package. --nodpes is just  
asking your system to break.

I gave you advice in my previous message - you should have emerged  
earlier versions of packages in order, for the reason to avoid  
blockers. The Gentoo devs had a GOOD REASON when they declared  
bash-3.2_p39 as blocking the current portage. If you had tried to  
emerge the earlier bash you would probably have found it blocked by an  
earlier portage &/or mktemp &/or com_err &/or util-linux &/or sys-libs/ 
ss. If you had resolved each dependency in turn you would have  
eventually been able to upgrade to the latest versions.

I know this, because last month I did this myself. A system last  
upgraded in August or September 2007 now has bash-3.2_p39 and  
portage-2.1.6.4 installed on it.

If you don't have the patience for this, then do as Alan says &  
reinstall the whole system.

If you don't understand what I wrote, then just ask.

If you want to upgrade this system then you're going to have to do a  
lot of work yourself. You WILL need to get older intermediate package  
versions from the CVS attic <http://sources.gentoo.org/> and you will  
need to Google & read the list archive to see the correct procedure  
for resolving the mktemp, com_err, util-linux & sys-libs/ss problems.  
But that really is pretty straightforward - it is clearly documented  
on the list "emerge version X of this, then version Y of that".

Stroller.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Stroller]

On 13 May 2009, at 15:27, Alan McKinnon wrote:
> ...
> It's just that I remember all too well what it took to get through  
> those many
> various blockers. More often than not I was once of the first to run  
> into them
> - I sync and update daily - but I'd hate to do it all again all in  
> one go,
> especially when all my buddies here have forgotten the procedure.

I think it does help if one upgrades a week or two after everyone  
else. I upgrade my main systems only every 4 - 12 weeks, and whenever  
I have a problem I look in the list archives and a clear upgrade  
procedure has most always been described.

I upgraded a 2007 system to current only a few weeks ago, and I  
encountered ALL the portage, mktemp, com_err, util-linux & sys-libs/ss  
problems. Honestly, it was not so bad. All these problems were clearly  
documented on the list - perhaps by yourself! - and I was able to  
overcome all of them in the course of an afternoon. The system was  
down for a couple of hours because I was hasty & impatient at one  
point, but in my case the significant cause of delays was that the  
machine is an old Duron 800mhz & took time with its compilation. With  
a faster machine I could perhaps have done all these upgrades within  
an hour.

Grabbing old versions of ebuilds from the attic is a bit of a pain,  
you wget them, rename them, copy them into /usr/local/portage, create  
the manifest and it's only when you try to emerge them that you find  
you also need a .patch file. But all these blockers are overcome just  
by upgrading the various packages in a straight-forward order.

I reread Alexey's post after replying to yours, and the reason he's  
having problems is because he's being careless. If you break the  
system, it's obviously a gamble whether you'll get your ass out of the  
problem you created for yourself. If you want to be sure of not  
breaking the system then you have to be cautious, resolve EACH and  
EVERY dependency in turn and not just go "fukkit, i don't know what  
that package does so, i'll ignore or unmerge it, upgrade this other  
package to the latest version and hope everything resolves".

Stroller.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Alan McKinnon]

On Wednesday 13 May 2009 16:49:52 Stroller wrote:
> I reread Alexey's post after replying to yours, and the reason he's  
> having problems is because he's being careless. If you break the  
> system, it's obviously a gamble whether you'll get your ass out of the  
> problem you created for yourself. If you want to be sure of not  
> breaking the system then you have to be cautious, resolve EACH and  
> EVERY dependency in turn and not just go "fukkit, i don't know what  
> that package does so, i'll ignore or unmerge it, upgrade this other  
> package to the latest version and hope everything resolves".

Very true. I see he's got the bash/portage mutual blocker one as well.

Nasty one that - only by close study of the ebuilds did I manage to figure out 
that
- upgrade bash to interim version in the tree
- upgrade portage to latest
- upgrade bash to latest
was the only way through. In those days we didn't have automatic blocker 
resolution in portage either.

And yes, if Alexey is being careless then portage is going to bite his ass.

Alexey, if you read this:

Do not unmerge bash, portage, wget or python without first making a quickpkg. 
Otherwise you will be left with an unusable system and no way out of it - 
portage uses those packages directly and cannot function without them. 

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Paul Hartman]

On Wed, May 13, 2009 at 10:00 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Wednesday 13 May 2009 16:49:52 Stroller wrote:
>> I reread Alexey's post after replying to yours, and the reason he's
>> having problems is because he's being careless. If you break the
>> system, it's obviously a gamble whether you'll get your ass out of the
>> problem you created for yourself. If you want to be sure of not
>> breaking the system then you have to be cautious, resolve EACH and
>> EVERY dependency in turn and not just go "fukkit, i don't know what
>> that package does so, i'll ignore or unmerge it, upgrade this other
>> package to the latest version and hope everything resolves".
>
> Very true. I see he's got the bash/portage mutual blocker one as well.
>
> Nasty one that - only by close study of the ebuilds did I manage to figure out
> that
> - upgrade bash to interim version in the tree
> - upgrade portage to latest
> - upgrade bash to latest
> was the only way through. In those days we didn't have automatic blocker
> resolution in portage either.
>
> And yes, if Alexey is being careless then portage is going to bite his ass.
>
> Alexey, if you read this:
>
> Do not unmerge bash, portage, wget or python without first making a quickpkg.
> Otherwise you will be left with an unusable system and no way out of it -
> portage uses those packages directly and cannot function without them.

buildsyspkg in FEATURES (make.conf) can be a life saver too :)

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Graham Murray]

Paul Hartman <paul.hartman+gentoo@gmail.com> writes:

> buildsyspkg in FEATURES (make.conf) can be a life saver too :)

But it does not (IMHO) save binaries for enough packages. For example,
it saves a binary for portage but not for python. I think it would be
good if it saved a binary package for everything which would be built
in stage-1, which would provide a much better 'get out of jail free' if
a critical package gets corrupted or fails to run.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Paul Hartman]

On Wed, May 13, 2009 at 10:30 AM, Graham Murray <graham@gmurray.org.uk> wrote:
> Paul Hartman <paul.hartman+gentoo@gmail.com> writes:
>
>> buildsyspkg in FEATURES (make.conf) can be a life saver too :)
>
> But it does not (IMHO) save binaries for enough packages. For example,
> it saves a binary for portage but not for python. I think it would be
> good if it saved a binary package for everything which would be built
> in stage-1, which would provide a much better 'get out of jail free' if
> a critical package gets corrupted or fails to run.

That's true, I didn't think of that before. Thankfully I have never
needed to use it, but I keep it enabled as a security blanket.

Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

On Wed, 13 May 2009 16:30:09 +0100, Graham Murray wrote:

> > buildsyspkg in FEATURES (make.conf) can be a life saver too :)  
> 
> But it does not (IMHO) save binaries for enough packages.

Then use buildpkg.


-- 
Neil Bothwick

It's only a hobby ... only a hobby ... only a

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]