[gentoo-user] EAPI packages

[hw]

Hi,

I´m trying to upgrade portage because I´m getting a message that it
needs to be able to work with EAPI 6 packages and can only do EAPI 5.

I´m running into merge conflicts when trying to update portage, and
apparently one of the packages (dev-python/cryptography) I could try
to update first to be able to update portage requires a version of
portage that can handle EAPI 6 packages.

How can upgrade portage?


emerge -a portage --newuse --update
[...]
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-apps/install-xattr-0.5
[ebuild N ] dev-python/packaging-15.3-r2 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild U ] dev-python/setuptools-18.4 [7.0] PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"
[ebuild N ] dev-python/certifi-2015.11.20 PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild N ] dev-python/pyxattr-0.5.5 USE="-doc {-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3 (-python3_5)"
[ebuild U ] sys-apps/portage-2.2.28 [2.2.14] USE="xattr*" PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-python/setuptools:0

(dev-python/setuptools-18.4:0/0::gentoo, ebuild scheduled for merge) pulled in by
dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, ebuild scheduled for merge)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/pyxattr-0.5.5:0/0::gentoo, ebuild scheduled for merge)


(dev-python/setuptools-7.0:0/0::gentoo, installed) pulled in by
dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_pypy(-)] required by (dev-python/cryptography-0.6.1:0/0::gentoo, installed)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (dev-python/chardet-2.2.1:0/0::gentoo, installed)


sys-apps/portage:0

(sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)

(sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)

sys-apps/portage[python_targets_python2_7(-)?,python_targets_python3_3(-)?,-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
[...]
emerge -a dev-python/cryptography --newuse --update
[...]
These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! The following update has been skipped due to unsatisfied dependencies:

dev-python/cryptography:0

!!! All ebuilds that could satisfy ">=dev-python/cffi-1.4.1:=[python_targets_python2_7(-)?,-python_single_target_python2_7(-),python_targets_python3_3(-)?,-python_single_target_python3_3(-),python_targets_python3_4(-)?,-python_single_target_python3_4(-),python_targets_python3_5(-)?,-python_single_target_python3_5(-)]" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-python/cffi-1.7.0::gentoo (masked by: EAPI 6)
- dev-python/cffi-1.6.0::gentoo (masked by: EAPI 6)
- dev-python/cffi-1.5.2::gentoo (masked by: EAPI 6)

The current version of portage supports EAPI '5'. You must upgrade to a
newer version of portage before EAPI masked packages can be installed.
[...]


I´m so tired of these stupid conflicts that come up every time I dare
trying to update ... It makes it impossible to keep a Gentoo installation
up to date and seriously needs fixing.

Last time it was perl (on another machine), still unsolved, now it´s portage,
and I can´t even install freeradius because portage insists that it doesn´t
have use flags.

[Azamat Hackimov]

Hello.

Try to install first lower version of cryptography:

emerge -av1 =cryptography-1.1.2

This version require at least cffi-1.2.1, which don't need EAPI 6.

Next try to install portage:

emerge -av =portage-2.2.28

[Neil Bothwick]

On Wed, 10 Aug 2016 12:54:37 +0200, hw wrote:

> emerge -a portage --newuse --update

That tries to updates deps too, try this

emerge -1a portage

or even, if that still fails

emerge -1a --nodeps portage


--
Neil Bothwick

Press button to test: release to detonate.

[Michael Orlitzky]

On 08/10/2016 06:54 AM, hw wrote:
>
> Hi,
>
> I´m trying to upgrade portage because I´m getting a message that it
> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
>
> I´m running into merge conflicts when trying to update portage, and
> apparently one of the packages (dev-python/cryptography) I could try
> to update first to be able to update portage requires a version of
> portage that can handle EAPI 6 packages.
>

Try the other suggestions first -- but as a last resort -- you can
always grab a new stage3 that should contain an updated version of
portage and simply overwrite the portage files on your machine. A
quickpkg from another Gentoo machine (or the liveCD?) would also work.

[Rich Freeman]

A cleaner solution would be to just sync a snapshot of the Gentoo repo
from the past.

Pick snapshots every few months and emerge -u @system, and repeat that
until you're caught up. The only issue is if it needs to download a
patch that is no longer available.

In general Gentoo does not support infrequently updating systems. You
don't need to update every day, or even every month. However, when
you're going more than six months at a time without an update you're
almost certain to have problems.

EAPI6 support was available in stable portage in Jan 2016. The
version of portage you're running predates the git migration which was
a year ago, but fortunately by not a whole lot more than that.

Here is a guide:
cd /usr
mv portage portage-old # for safekeeping - you can go
back to rsync later if you want
mkdir portage
cd portage
git clone --no-checkout https://github.com/gentoo/gentoo.git .
git checkout 56bd759df1d0c750a065b8c845e93d5dfa6b549d # Aug 8 2015
emerge -u @system
git checkout 1e65133983f404ea64079df0933dd820619a9b44 # Nov 1 2015
emerge -u @system
git checkout 47b868a553171134807fc949d2b84c2dc31b0477 # Feb 2 2016
emerge -u @system

By now you're into EAPI6 territory. Hopefully you can get to the
present directly, but I can give you a few more commits if necessary.
I didn't test those out on an old system, so you might still run into
issues. I won't promise that this won't be a bumpy ride.

When you're done you can swap out portage and portage-old.

And try to stay more current with updates... If you really know what
you're doing you can update ancient systems, but it sounds like you
want something that "just works" and on Gentoo this is not something
that just works.

--
Rich

[hw]

Neil Bothwick schrieb:

> On Wed, 10 Aug 2016 12:54:37 +0200, hw wrote:
>
>> emerge -a portage --newuse --update
>
> That tries to updates deps too, try this
>
> emerge -1a portage
>
> or even, if that still fails
>
> emerge -1a --nodeps portage
>
>

emerge -1a portage
[...]

Calculating dependencies... done!
[ebuild N ] sys-apps/install-xattr-0.5
[ebuild N ] dev-python/packaging-15.3-r2 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"

[ebuild N ] dev-python/setuptools-18.4 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"

[ebuild N ] dev-python/certifi-2015.11.20 PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild N ] dev-python/pyxattr-0.5.5 USE="-doc {-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3 (-python3_5)"
[ebuild U ] sys-apps/portage-2.2.28 [2.2.14] USE="xattr*" PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-apps/portage:0

(sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)

(sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)

So portage cannot be installed because portage is installed?

When I use --nodeps, portage might not work at all anymore and I would be
totally screwed. And 'emerge -1a --newuse --update portage' gives the
same result.

[hw]

Michael Orlitzky schrieb:

I´m trying to update a production server here. If I overwrite the whole
system, who knows what might break. I can take it down for a few
hours in the evening unless I want to work over night, which is not
really an option.

There must be a way to update a Gentoo installation without breaking it.
As wonderful as it otherwise is, updating Gentoo is always a nightmare which
makes me very seriously consider not to use it anymore. Updating needs to
be easy and flawless and not something you always run into weird issues
with.

Did they recently make a new liveDVD?

[Jeroen Mathon]

Is it perhaps an idea to mask the gentoolkit package when updating portage?


On 12-08-16 14:42, Neil Bothwick wrote:

> On Fri, 12 Aug 2016 14:16:25 +0200, hw wrote:
>
>> sys-apps/portage:0
>>
>> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge)
>> pulled in by sys-apps/portage (Argument)
>>
>> (sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
>> sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)]
>> required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)
>>
>>
>> So portage cannot be installed because portage is installed?

> Rather it looks like portage can't be updated because of the version of
> gentoolkit that is installed. Try uninstalling gentoolkit, updating
> portage and then reinstalling gentoolkit.
>
> It may also help to know the USE flags used for gentoolkit and the
> *current* portage install.
>
>

[Neil Bothwick]

On Fri, 12 Aug 2016 14:16:25 +0200, hw wrote:

> sys-apps/portage:0
>
> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge)
> pulled in by sys-apps/portage (Argument)
>
> (sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
> sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)]
> required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)
>
>
> So portage cannot be installed because portage is installed?

Rather it looks like portage can't be updated because of the version of
gentoolkit that is installed. Try uninstalling gentoolkit, updating
portage and then reinstalling gentoolkit.

It may also help to know the USE flags used for gentoolkit and the
*current* portage install.

--
Neil Bothwick

He who asks a question is a fool for a minute,
He who doesn't ask is a fool for a lifetime.

[hw]

PS: Sorry, I tried it in a container. Here´s what I get on the host:


emerge -1a portage
[...]

[ebuild N ] sys-apps/install-xattr-0.5
[ebuild N ] dev-python/packaging-15.3-r2 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild U ] dev-python/setuptools-18.4 [7.0] PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"
[ebuild N ] dev-python/certifi-2015.11.20 PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild N ] dev-python/pyxattr-0.5.5 USE="-doc {-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3 (-python3_5)"
[ebuild U ] sys-apps/portage-2.2.28 [2.2.14] USE="xattr*" PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-python/setuptools:0

(dev-python/setuptools-18.4:0/0::gentoo, ebuild scheduled for merge) pulled in by
dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, ebuild scheduled for merge)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/pyxattr-0.5.5:0/0::gentoo, ebuild scheduled for merge)


(dev-python/setuptools-7.0:0/0::gentoo, installed) pulled in by
dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_pypy(-)] required by (dev-python/cryptography-0.6.1:0/0::gentoo, installed)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (dev-python/chardet-2.2.1:0/0::gentoo, installed)


sys-apps/portage:0

(sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)

(sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)

sys-apps/portage[python_targets_python2_7(-)?,python_targets_python3_3(-)?,-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)

Neil Bothwick schrieb:

> On Wed, 10 Aug 2016 12:54:37 +0200, hw wrote:
>
>> emerge -a portage --newuse --update
>
> That tries to updates deps too, try this
>
> emerge -1a portage
>
> or even, if that still fails
>
> emerge -1a --nodeps portage
>
>

emerge -1a portage
[...]

Calculating dependencies... done!
[ebuild N ] sys-apps/install-xattr-0.5
[ebuild N ] dev-python/packaging-15.3-r2 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"

[ebuild N ] dev-python/setuptools-18.4 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"

[ebuild N ] dev-python/certifi-2015.11.20 PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild N ] dev-python/pyxattr-0.5.5 USE="-doc {-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3 (-python3_5)"
[ebuild U ] sys-apps/portage-2.2.28 [2.2.14] USE="xattr*" PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-apps/portage:0

(sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) pulled in by
sys-apps/portage (Argument)

(sys-apps/portage-2.2.14:0/0::gentoo, installed) pulled in by
sys-apps/portage[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (app-portage/gentoolkit-0.3.0.9-r2:0/0::gentoo, installed)

So portage cannot be installed because portage is installed?

[Michael Orlitzky]

On 08/12/2016 08:26 AM, hw wrote:
>>
>> Try the other suggestions first -- but as a last resort -- you can
>> always grab a new stage3 that should contain an updated version of
>> portage and simply overwrite the portage files on your machine. A
>> quickpkg from another Gentoo machine (or the liveCD?) would also work.
>>
>
> I´m trying to update a production server here. If I overwrite the whole
> system, who knows what might break. I can take it down for a few
> hours in the evening unless I want to work over night, which is not
> really an option.
>

Not the whole system, only portage. It should still be your last resort,
but on the bad-idea scale it's only a 1 or a 2.

[james]

When I run gentoo as a critical server, I always have a second,
redundant system pretty much identical, on stanby. I upgrade the stanby
first and run it a few days, then the production system. It makes
reliability extraordinarily high. But, the again, I do a version of the
same thing with all critical systems, or I do not work on them. Granted,
as successful consultant, I have that luxury.

>
> Did they recently make a new liveDVD?

A few months ago.

https://wiki.gentoo.org/wiki/Project:RelEng/LiveDVD/20160514

Perhaps a better solution is to make a stage-4, of your current gentoo
(production) system, verify that the stage-4 works by using it to
install a similar system, test and deploy. And then hack or fix the
production system, during the daytime, at your leisure?

Stage-4 gentoo systems have been around a long time. Documentation
varies and most have their own 'home spun' approach to stage-4 replicant
systems, backups etc etc.

hth,
James

[Fernando Rodriguez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
> Is it perhaps an idea to mask the gentoolkit package when updating portage?

Since that version of gentoolkit doesn't depend on a specific version of portage
but does depend on portage with the same python_targets use flags, I think the problem
is that you're trying to emerge portage and gentoolkit with different python_target_XXX
flags, So just make sure they're the same.

- --

Fernando Rodriguez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXri1wAAoJEPbOFX/5Ulwczi0P/1bcpxZs0atjCHKxi17OMbB/
TXhWEibey7ukIMBzXuWJREUURfKlWWnQDrz+b8pW7S9oMMpHSb9ClXWvsItgdojg
D6J+akRmkNqnwvfAwdKf8vX03LFrWP/SB8wbdZt/boXyXW6qvrVjjl4dfSITTA2C
e7eYrNhx6n120phQxFjQlzZjrZuX6BjmfxT+yOmdkYFsy0lOOQtsJPRBgMSmXj2w
9gz03V7zYs8D59R72HWZm97SINRDSwJ6BII3JiGP+gpWDzjxqv12Pr5qgU2K4F9M
09m53gNZrGk7Cm1MFaqcaI8d+dhvCLOk7ZsFl7rZBhS6DYonrWku1XGc65EGnH85
Ab9qeIIlNrKJ8z45HM8rOYxH2Nn+e/FWCpF90yxr/B6ZIqv3E2xotwFU7f8Ebw4b
GekYFTIwwH88SNnWwCgimWXC0M4hSzICz3f2AfnIaYJYF3rMshJ8EWpDGugXweWO
1BEaWvJkhsUpHWa2dKYNvOkUUDGn35N50rI7FUAiK7xIQcY33kw1BQD9FfY4eR/B
eQQOPOiVYIG/52UUqOsOCQixQJg0OWpvWGokOgghYIrabIs7F8CmjH4ES3cUk/4W
xE93vflWWOuFVm09xUzfobpqR1ikVb0sfyNS3CXrseEFb56TeylIWku2tx2Bly2g
umtuSGZ5+gFsPgyII8uC
=Pcvt
-----END PGP SIGNATURE-----

[Andreas K. Hüttel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw:
> Hi,
>
> I´m trying to upgrade portage because I´m getting a message that it
> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
>
> I´m running into merge conflicts when trying to update portage, and
> apparently one of the packages (dev-python/cryptography) I could try
> to update first to be able to update portage requires a version of
> portage that can handle EAPI 6 packages.
>
> How can upgrade portage?
>

If you see this now, your production server hasn't been updated for a long
time...

As a last resort, you should be able to run a "non-installed" portage version
to update your system once. Manually download and unpack a recent portage
tarball somewhere temporary and then run as root something like

porto tmp # ./portage-2.3.0/bin/emerge -uDNav world

This can update your system to the newest state, including updating the
installed portage. Afterwards you won't need the temporarily unpacked portage
anymore.

Disclaimer: I haven't tested this for a while. It may delete your data, kill
kittens or turn the sun into a nova. No guarantees made.

- --
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilf...@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXryAhAAoJEHRrah2soMK++mAP/jnoaJUkdcBpew/pBb6D+d6w
WScLqqz5k7cJj9ufJxUb8HeiqcHavVNnQx1Jk8xRwuGXL9vwTI/Og+/5SHhW+uva
ViT0YniLrfOWvloPqJmnRhkXn3sU81KxPhP4SOz8GcImzBrgnbqJ3kD/kNOXUE2E
c3LleaQINRQWVlfcKLelhhCvmXOfQ5JZtcRz2vnRzzH580T1ICOwNFFuvWVlls1L
kUemcjhmHBPXb979Ls69tSqdDm75IIBY92uxNqjy36zn8gFPnNM3BrER+xZ92E9L
L36LKwSeDL+mkJE/um48IQJJ4t2IW9bKwK8TFp4Bp9otc6+hBJmtwRjKnFbrx4DQ
Oh+sZBXuewmC/T/xLUxyGxV+QT9oKSqmMy7CYhHnfhpIkqK4Upk4oWgzu6mBs89L
ozr4vdy4d4/FY2TMHOFz4Xx/gJF2IVG02jUyg2yT2VZrUk75faeq2Ga6DlyUVpw0
T64lEU/r29KrvexYsLtdzlNC6Emui37LTU0YQWrKZoJGTLDeygBC/rupz1xFfI5d
3KPozxzyE6AiJlYil4Ffiac1WiwBK5PgI1UhYmNpPFo+McDp52jxZKsnwCvUccze
s9+3g0N7N1g5+iovLjLpQo5a0D60Mvz127CaM9q+u/qBNt3Je7oGLlr7IikM8eXY
F+gWcnEgqzmh0oHiPCj0
=Vt2D
-----END PGP SIGNATURE-----

[hw]

Fernando Rodriguez schrieb:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
>> Is it perhaps an idea to mask the gentoolkit package when updating portage?
>
> Since that version of gentoolkit doesn't depend on a specific version of portage
> but does depend on portage with the same python_targets use flags, I think the problem
> is that you're trying to emerge portage and gentoolkit with different python_target_XXX
> flags, So just make sure they're the same.

I have removed gentoolkit, and it still fails:

emerge --ask --update --newuse portage
[...]
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-apps/portage:0

(sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) conflicts with
sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)


When I try to remove webapp-config, it says no packages can be removed:


emerge --ask --depclean app-admin/webapp-config

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed: 659
Packages in world: 85
Packages in system: 44
Required packages: 659
Number removed: 0


So try to update it:


emerge --ask --update --newuse app-admin/webapp-config

[...]
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-apps/install-xattr-0.5
[ebuild N ] dev-python/packaging-15.3-r2 USE="{-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"

[ebuild U ] dev-python/setuptools-18.4 [7.0] PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

[ebuild N ] dev-python/certifi-2015.11.20 PYTHON_TARGETS="python2_7 python3_4 (-pypy) (-pypy3) -python3_3 (-python3_5)"
[ebuild N ] dev-python/pyxattr-0.5.5 USE="-doc {-test}" PYTHON_TARGETS="python2_7 python3_4 (-pypy) -python3_3 (-python3_5)"
[ebuild U ] sys-apps/portage-2.2.28 [2.2.14] USE="xattr*" PYTHON_TARGETS="python3_4* -python3_3* (-python3_5)"

[ebuild U ] app-admin/webapp-config-1.54-r1 [1.52-r1] PYTHON_TARGETS="python3_4%* (-pypy) -python3_3*"

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-python/setuptools:0

(dev-python/setuptools-18.4:0/0::gentoo, ebuild scheduled for merge) pulled in by
dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, ebuild scheduled for merge)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/pyxattr-0.5.5:0/0::gentoo, ebuild scheduled for merge)


(dev-python/setuptools-7.0:0/0::gentoo, installed) pulled in by
dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_pypy(-)] required by (dev-python/cryptography-0.6.1:0/0::gentoo, installed)

dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_3(-)?,python_targets_python3_4(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-)] required by (dev-python/chardet-2.2.1:0/0::gentoo, installed)

Now try to update cryptography:


emerge --ask --update --newuse dev-python/cryptography
[...]

!!! All ebuilds that could satisfy ">=dev-python/cffi-1.4.1:=[python_targets_python2_7(-)?,-python_single_target_python2_7(-),python_targets_python3_3(-)?,-python_single_target_python3_3(-),python_targets_python3_4(-)?,-python_single_target_python3_4(-),python_targets_python3_5(-)?,-python_single_target_python3_5(-)]" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-python/cffi-1.7.0::gentoo (masked by: EAPI 6)
- dev-python/cffi-1.6.0::gentoo (masked by: EAPI 6)
- dev-python/cffi-1.5.2::gentoo (masked by: EAPI 6)

The current version of portage supports EAPI '5'. You must upgrade to a
newer version of portage before EAPI masked packages can be installed.

So how do I update portage?? Apparently, it´s impossible to update portage
before updating cryptography, and cryptography cannot be updated before
portage has been updated. I would say that this is a bug.

I added 'python_target3_4' to the global use flags before doing this.

emerge --version
Portage 2.2.14 (python 2.7.9-final-0, default/linux/amd64/13.0/no-multilib, gcc-4.8.3, glibc-2.19-r1, 3.17.8-gentoo-r1 x86_64)

It´s not possible to install gentoolkit now, so I can´t tell which USE flags
are used for emerge.

[hw]

Rich Freeman schrieb:

> On Wed, Aug 10, 2016 at 10:45 AM, Michael Orlitzky <m...@gentoo.org> wrote:
>> On 08/10/2016 06:54 AM, hw wrote:
>>>
>>> Hi,
>>>
>>> I´m trying to upgrade portage because I´m getting a message that it
>>> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
>>>
>>> I´m running into merge conflicts when trying to update portage, and
>>> apparently one of the packages (dev-python/cryptography) I could try
>>> to update first to be able to update portage requires a version of
>>> portage that can handle EAPI 6 packages.
>>>
>>
>> Try the other suggestions first -- but as a last resort -- you can
>> always grab a new stage3 that should contain an updated version of
>> portage and simply overwrite the portage files on your machine. A
>> quickpkg from another Gentoo machine (or the liveCD?) would also work.
>>
>
> A cleaner solution would be to just sync a snapshot of the Gentoo repo
> from the past.
>
> Pick snapshots every few months and emerge -u @system, and repeat that
> until you're caught up. The only issue is if it needs to download a
> patch that is no longer available.
>
> In general Gentoo does not support infrequently updating systems. You
> don't need to update every day, or even every month. However, when
> you're going more than six months at a time without an update you're
> almost certain to have problems.

I infrequently update Gentoo because I´m *always* running into problems
like this. 'Infrequently' means about every 3 months at home, and not
since, IIRC, 2015-02 here at work. The last update at home got stalled
because perl cannot be updated, and I haven´t had the time to look into
that to finish it.

The other reason is that it takes time to update the kernel when a new
one comes along, so updating like every week is not feasible. And I
don´t want to reboot all the time.

Besides, I don´t want to update too frequently because there may issues
with new versions of software.

If you say that you need to update more frequently than every 3 months
for not to have problems with the update process itself, I can only
conclude that Gentoo is entirely unsuited for servers --- and for home
use as well other than for test machines perhaps.

> EAPI6 support was available in stable portage in Jan 2016. The
> version of portage you're running predates the git migration which was
> a year ago, but fortunately by not a whole lot more than that.
>
> Here is a guide:
> cd /usr
> mv portage portage-old # for safekeeping - you can go
> back to rsync later if you want
> mkdir portage
> cd portage
> git clone --no-checkout https://github.com/gentoo/gentoo.git .
> git checkout 56bd759df1d0c750a065b8c845e93d5dfa6b549d # Aug 8 2015
> emerge -u @system
> git checkout 1e65133983f404ea64079df0933dd820619a9b44 # Nov 1 2015
> emerge -u @system
> git checkout 47b868a553171134807fc949d2b84c2dc31b0477 # Feb 2 2016
> emerge -u @system
>
> By now you're into EAPI6 territory. Hopefully you can get to the
> present directly, but I can give you a few more commits if necessary.
> I didn't test those out on an old system, so you might still run into
> issues. I won't promise that this won't be a bumpy ride.
>
> When you're done you can swap out portage and portage-old.

Thanks, I'll have to see next week if this is an option. I might end
up setting another server with Centos or Debian instead, despite I
don´t like either of them.

> And try to stay more current with updates...

I would gladly do that if there weren´t always issues when trying to
update a Gentoo installation, and if I had the time to do it.

> If you really know what
> you're doing you can update ancient systems, but it sounds like you
> want something that "just works" and on Gentoo this is not something
> that just works.

That machines can be kept up to date without running into weird issues
like I always do with Gentoo is a requirement. That probably leaves
Debian as the only distribution that could be used when you don´t want
to remain in the past too far as you likely would with Centos :(

That creates a problem because ZFS is somewhat questionable with either,
and I don´t trust btrfs to keep the data save yet.

[hw]

Michael Orlitzky schrieb:

And how would I know which of all the files affect only portage and nothing
else, and what about the dependencies of portage?

[hw]

james schrieb:

This isn´t really an option because the problem is with the updating
itself, not with something not working after the update has been
performed.

> Granted,
> as successful consultant, I have that luxury.

It´s time consuming ...

>> Did they recently make a new liveDVD?
>
> A few months ago.
>
> https://wiki.gentoo.org/wiki/Project:RelEng/LiveDVD/20160514

Cool, the old one was really getting old.

> Perhaps a better solution is to make a stage-4, of your current gentoo
> (production) system, verify that the stage-4 works by using it to install a similar system, test and deploy. And then hack or fix the production system, during the daytime, at your leisure?
>
> Stage-4 gentoo systems have been around a long time. Documentation varies and most have their own 'home spun' approach to stage-4 replicant systems, backups etc etc.

It might be a way to try and see if upgrading from older states step by
step until the installation is current would work. But how do I do that?

Considering how much time and effort it might take and that the update
problems aren´t going to go away, I have to wonder whether it´s better to
install Debian or Centos on another machine and to migrate the services.
Doing so would allow to make some improvements and to consolidate several
physical machines into one.

Either way, it sucks.

[hw]

Andreas K. Hüttel schrieb:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw:
>> Hi,
>>
>> I´m trying to upgrade portage because I´m getting a message that it
>> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
>>
>> I´m running into merge conflicts when trying to update portage, and
>> apparently one of the packages (dev-python/cryptography) I could try
>> to update first to be able to update portage requires a version of
>> portage that can handle EAPI 6 packages.
>>
>> How can upgrade portage?
>>
>
> If you see this now, your production server hasn't been updated for a long
> time...

About 1.5 years --- not really a long time.

> As a last resort, you should be able to run a "non-installed" portage version
> to update your system once. Manually download and unpack a recent portage
> tarball somewhere temporary and then run as root something like
>
> porto tmp # ./portage-2.3.0/bin/emerge -uDNav world
>
> This can update your system to the newest state, including updating the
> installed portage. Afterwards you won't need the temporarily unpacked portage
> anymore.
>
> Disclaimer: I haven't tested this for a while. It may delete your data, kill
> kittens or turn the sun into a nova. No guarantees made.

Interesting idea :) I´d be afraid that this version of portage might
find files of the regular installation and get confused and kill the
kittens ...

[Peter Humphrey]

On Saturday 13 Aug 2016 16:26:21 hw wrote:
> Andreas K. Hüttel schrieb:

> > If you see this now, your production server hasn't been updated for a
> > long time...
>
> About 1.5 years --- not really a long time.

Au contraire. In a Gentoo world, this is comparable with the age of the
universe. And leaving it that long almost guarantees that you'll have
problems. (I update my system daily, but that's because I don't have
anything more useful to do with my time. :) )

> > As a last resort, you should be able to run a "non-installed" portage
> > version to update your system once. Manually download and unpack a
> > recent portage tarball somewhere temporary and then run as root
> > something like
> >
> > porto tmp # ./portage-2.3.0/bin/emerge -uDNav world
> >
> > This can update your system to the newest state, including updating the
> > installed portage. Afterwards you won't need the temporarily unpacked
> > portage anymore.
> >
> > Disclaimer: I haven't tested this for a while. It may delete your data,
> > kill kittens or turn the sun into a nova. No guarantees made.
>
> Interesting idea :) I´d be afraid that this version of portage might
> find files of the regular installation and get confused and kill the
> kittens ...

That's the idea, isn't it? You need it to root out the out-of-date bits and
substitute new ones. It sounds like a rational scheme to me, especially if
you quickpkg portage to keep some kittens wrapped up in the warm.

--
Rgds
Peter

[Andreas K. Hüttel]

Am Samstag, 13. August 2016, 16:26:21 schrieb hw:
>
> Interesting idea :) I´d be afraid that this version of portage might
> find files of the regular installation and get confused and kill the
> kittens ...

Well this is essentially how portage team (to my knowlegde) tests git HEAD
version of portage and its development (have a git checkout of portage code
and run it from there).

I've used the method a few times, but mainly to test repoman.

[james]

If you have an identical, second system, then you can test whatever you
want on trying to complete your upgrade. Get the second system up and
running. Disconnect the ethernet on one and upgrade the other. If you
fail, then just switch the ethernet cable. Sometimes you can just
reassign the ethernet on one, so you can ssh into it and look around,
while working on the other. (2) indentical systems allow you to work on
one and keep the other stable, until the upgrade is finished.

>
>> Granted,
>> as successful consultant, I have that luxury.
>
> It´s time consuming ...
>
>>> Did they recently make a new liveDVD?
>>
>> A few months ago.
>>
>> https://wiki.gentoo.org/wiki/Project:RelEng/LiveDVD/20160514
>
> Cool, the old one was really getting old.
>
>
>> Perhaps a better solution is to make a stage-4, of your current gentoo
>> (production) system, verify that the stage-4 works by using it to
>> install a similar system, test and deploy. And then hack or fix the
>> production system, during the daytime, at your leisure?
>>
>> Stage-4 gentoo systems have been around a long time. Documentation
>> varies and most have their own 'home spun' approach to stage-4
>> replicant systems, backups etc etc.
>
> It might be a way to try and see if upgrading from older states step by
> step until the installation is current would work. But how do I do that?
>

In normal times, you could just make a stage 4. It's like a complete
backup that installs. Like most other similar approaches, I always test
them out to ensure they install and populate as needed. If you google,
for gentoo : stage-4 you'll find lots of examples with slightly
different steps.

Here's an old one, translated::

http://translate.google.com/translate?prev=/language_tools&u=http%3A%2F%2Fgentoo-wiki.gentoo.ru%2Fwiki%2FStage4

There are better stage-4 guides, so just google for them::


http://www.tutorials.chymera.eu/blog/2014/05/18/mkstage4-stage4-tarballs-made-easy/

https://github.com/TheChymera/mkstage4/blob/master/README.md

http://gentoo-en.vfose.ru/wiki/Custom_Stage4

http://gentoo-en.vfose.ru/wiki/Custom_Stage4#Installing_from_Stage4


Exercise some caution here. This is something that should be done and
tested before you get in 'hot water'. Still, if you can duplicate what
you have working (and test it) then you can experiment on the second
indentical server, with out fear of corrupting the only one you have
working.

How you proceed is up to you. so be *careful*!!!

> Considering how much time and effort it might take and that the update
> problems aren´t going to go away, I have to wonder whether it´s better to
> install Debian or Centos on another machine and to migrate the services.
> Doing so would allow to make some improvements and to consolidate several
> physical machines into one.

Either way, you should back up your data /etc/ /var/lib/portage/world
and any other info files you have or have modified, regardless of which
OS you end up running on. Think about all the mods and installs and
critical software you have customized on the system (iptables?).
Back all of that up too.

>
> Either way, it sucks.

System admin requires routine attention to systems, including backups
and a total failure plan for critical systems, files, configs and other
valuable information. Being in the fox-hole taking on water and low on
ideas, hopefully will motivate you to have a more robust plan next time
around.


Good luck,
hth,
James

[james]

On 08/10/2016 06:54 AM, hw wrote:
>

> Hi,
>
> I´m trying to upgrade portage because I´m getting a message that it
> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
>
> I´m running into merge conflicts when trying to update portage, and
> apparently one of the packages (dev-python/cryptography) I could try
> to update first to be able to update portage requires a version of
> portage that can handle EAPI 6 packages.
>
> How can upgrade portage?

You might want to read these docs on how to upgrade an old system, in
steps, not all at once::


http://blog.siphos.be/2013/12/upgrading-old-gentoo-installations/

http://dev.gentoo.org/~swift/snapshots/

https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Upgrading_from_older_systems


Yet another approach.


hth,
James

[Neil Bothwick]

On Sat, 13 Aug 2016 16:26:21 +0200, hw wrote:

> > If you see this now, your production server hasn't been updated for a
> > long time...
>
> About 1.5 years --- not really a long time.

You're kidding, right? You're running a production server without the
last 18 months' worth of security updates?


--
Neil Bothwick

Despite the cost of living it remains popular.

[Neil Bothwick]

On Sat, 13 Aug 2016 16:08:34 +0200, hw wrote:

> infrequently update Gentoo because I´m *always* running into problems
> like this.

Every time, or is that just hyperbole?

> 'Infrequently' means about every 3 months at home, and not
> since, IIRC, 2015-02 here at work. The last update at home got stalled
> because perl cannot be updated, and I haven´t had the time to look into
> that to finish it.

Problems like this are usually resolved quickly. Syncing and updating a
couple of days later would probably have sorted it.

> The other reason is that it takes time to update the kernel when a new
> one comes along, so updating like every week is not feasible. And I
> don´t want to reboot all the time.

You don't need to boot into every new kernel that hits portage. As long
as your current kernel has no security issues you can stick with it.
Plenty of people use Gentoo with only the LTS kernels.

> Besides, I don´t want to update too frequently because there may issues
> with new versions of software.

If you use the stable arch, you don't get brand new versions. Packages
are normally a month old before they hit stable.

> If you say that you need to update more frequently than every 3 months
> for not to have problems with the update process itself, I can only
> conclude that Gentoo is entirely unsuited for servers --- and for home
> use as well other than for test machines perhaps.

It may be more a case of Gentoo being unsuited for you, your
expectations and your preferred way of working. In fact, any rolling
release distros sounds like it won't be right for you.


--
Neil Bothwick

Failure is not an option...it is integrated with every Microsoft product.

[Rich Freeman]

On Sat, Aug 13, 2016 at 10:08 AM, hw <h...@gc-24.de> wrote:
>
> I infrequently update Gentoo because I´m *always* running into problems
> like this. 'Infrequently' means about every 3 months at home, and not
> since, IIRC, 2015-02 here at work. The last update at home got stalled
> because perl cannot be updated, and I haven´t had the time to look into
> that to finish it.

You're probably always running into problems like this because you
infrequently update Gentoo.

If you ran it every day you'd probably only run into issues every
couple of months, and when you did you'd have it immediately narrowed
down to a few packages since that is all that has changed.

>
> If you say that you need to update more frequently than every 3 months
> for not to have problems with the update process itself, I can only
> conclude that Gentoo is entirely unsuited for servers --- and for home
> use as well other than for test machines perhaps.
>

If you're looking for a distro designed to just work with no hands-on,
then you should probably look elsewhere.

Put it another way, why are you using Gentoo instead of Debian or
CentOS in the first place?

Gentoo is useful when you want to mess with the configuration of the
distro itself, not when you just want to throw a few files in
/var/www/htdocs and be done with it.

Gentoo can be made to work rather well on servers, but you have to
know what you're doing. You can't just run emerge -u world on a
production server that hasn't been touched in a year and expect to
work. However, you certainly could set up your own local repository,
pull in updates as needed (certainly including frequent security
updates), build binary packages and deploy to your test environment,
make sure everything is good, and then deploy those binary packages to
your production servers. You can accomplish a lot of things that way
that you couldn't accomplish with CentOS or Debian.

However, if all you want is the same binaries Debian already gives
you, then just run Debian. It isn't like apache runs better just
because you compiled it yourself. Gentoo is about tweaking things.
And if you're going to tweak things in an enterprise environment then
you need to be doing QA.

If you really want to be deploying updates into production without any
testing then you ought to stick with the likes of CentOS/RHEL. That's
basically their entire value-add. Debian stable would be another
option.

--
Rich

[David Haller]

Hello,

On Sat, 13 Aug 2016, Andreas K. Hüttel wrote:
>Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw:

>> I?m trying to upgrade portage because I?m getting a message that it

>> needs to be able to work with EAPI 6 packages and can only do EAPI 5.

[..]

>If you see this now, your production server hasn't been updated for a long
>time...
>
>As a last resort, you should be able to run a "non-installed" portage version
>to update your system once. Manually download and unpack a recent portage
>tarball somewhere temporary and then run as root something like
>
>porto tmp # ./portage-2.3.0/bin/emerge -uDNav world
>
>This can update your system to the newest state, including updating the
>installed portage. Afterwards you won't need the temporarily unpacked portage
>anymore.

Yep. BTDT. I had a then 4-4.5 year old gentoo quite broken by being
partly updated until portage/emerge broke and much else didn't work
anymore (gcc/make/python/emerge). So, I booted something else, mounted
gentoo somewhere (say /mnt), unpacked a fresh stage3 _into_ that
mountpoint into /stage3 (i.e. "/mnt/stage3"), chrooted there (with the
usual /sys, /proc, /dev bind-mounts) and then ran stuff from the
/stage3/ tree[1] until the basic stuff (mainly above mentioned 4) was
fixed. From then on it mostly went "smooth", by the "textbook",
considering. Yeah, lots of conflicts and whatnot because of moves,
renames and new deps etc.pp. It was a bit tedious, but not difficult.

And this general tip came out of it: unmerging stuff helps to break
tangles. Like slashing the Gordian Knot ;)

Before you yourself get stuck in the same tangles that emerge did,
be bold, take note and switch to a "unmerge + reemerge" strategy!
I.e. take one offender, note it down (textfile and/or paper), unmerge
it, try a re-emerge of that offender or a @world without it. Keep
adding to the "offenders" list until emerge comes up "clean". Then try
re-emerging the offenders one by one.

It's one of the first things I do when weird stuff/conflicts crop up.
Before I mess with useflags and masks and whatnot, I unmerge both
tangled packages (and keep track of anything I unmerge in a textfile
or so!) and then try to merge only those (with '--pretend --tree' at
first). Emerge IMO handles the "install" case much better and the
conflicts are often much clearer, "obsolete" deps can be ignored
and/or handled later by "emerge @preserved-rebuild".

And once I've figured out what's going on, it often is just one
useflag, or one (un)mask or something else in /etc/portage/package* to
clear it all up.

And finding that is much easier doing it one-by-one.

Of course, you can't unmerge stuff like gcc/make/python/portage just
like that, that's when an unpacked /stage3 comes into play. But you
should not need that until your system is _way_ outdated (as was
mine).

Anyway: so, yes, you can use a unpacked up-to-date /stage3 for
bootstrapping an update once your system is so (ridiculously) outdated
that a normal update breaks, and not only for installing a new system
:) Of course, you'll have to deal with new/renamed/moved/gone packages
and such stuff, but that's to be expected[3]. And IIRC that strategy
had me upgrading quite smoothly to the new perl-5.24 (from 5.20 or
.22?) just recently. At times, emerge _does_ get somewhat stuck. And
it's output gets confusing to match.

But! Usually, when your system is not too much out of date, emerge
does a _very_ good job, it's output is a bit hard to read though,
something IIRC the devs are the first to admit, but as Neil and others
prove here often (I'll try to get more into helping too), you can get
used to it and pinpoint the actual reason for emerge barfing tons of
text on you.

-dnh

[1] IIRC by adjusting PATH and LD_LIBRARY_PATH until I got the tools.

Once that was done, I (rebooted and?) re-emerged those "natively"
from the actual gentoo with "/stage3" "removed" from PATH.

PS: I've done similar stunts with other distros... install only a
64bit kernel/glibc/rpm[2] while the repos still pointed to i586
because you updated the repos to the new version but not the
repo-config to x86_64? Bad idea! But "fun"! (boot something, mount
target as /mnt and an ISO under /ISO) and then
cd /ISO/../x86_64/;
rpm --root=/mnt --test -ivh package_manager.rpm \
more_and_more_rpms ../noarch/even_some_more_rpms
until the package_manager ran. Much like emerge in my gentoo case.

And yes, I still run both systems, updated since then quite a bit,
everything checks out, I even got rid of leftover i586 packages on
that at-first-fouled-up-switch-to-x86_64 system.

[2] or the other way round? Anyway: basically nothing but the kernel
itself ran. So, boot something else, and ...

[3] and which is why I like stable stuff like TeX, WindowMaker, mutt,
tin, mc, joe, (X)Emacs, lynx/links/w3m or even netscape/seamonkey
that does not get incompatibly rewritten from scratch every couple
of years. I'm gazing at you KDE! Since KDE2 in it's early betas!

--
Oh, naturally - I'm not a cruel man. A viciously vindictive grudge-
bearing wee Bastard, yes, but not cruel. -- J. C. 'Jim' Andrew

[Michael Orlitzky]

On 08/13/2016 10:09 AM, hw wrote:
>>
>> Not the whole system, only portage. It should still be your last resort,
>> but on the bad-idea scale it's only a 1 or a 2.
>
> And how would I know which of all the files affect only portage and nothing
> else, and what about the dependencies of portage?
>

equery f portage

Chances are, portage will be happy with whatever dependencies you
already have installed. If not, you can repeat the process on those
dependencies. Booting into a liveCD on another machine and making a
quickpkg would save you from having to overwrite the files manually.

But, I think Andreas's was the best suggestion so far.

[Fernando Rodriguez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/13/2016 09:40 AM, hw wrote:
> Fernando Rodriguez schrieb:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
>>> Is it perhaps an idea to mask the gentoolkit package when updating portage?
>>
>> Since that version of gentoolkit doesn't depend on a specific version of portage
>> but does depend on portage with the same python_targets use flags, I think the problem
>> is that you're trying to emerge portage and gentoolkit with different python_target_XXX
>> flags, So just make sure they're the same.
>
> I have removed gentoolkit, and it still fails:
>
> emerge --ask --update --newuse portage
> [...]
> WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
>
> sys-apps/portage:0
>
> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) conflicts with
> sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
>
>

Now it's app-admin/webapp-config it has the same dep on portage (sys-apps/portage[${PYTHON_USEDEP}]) only when the portage use flag is enabled.

You're trying to build portage with a new python target when everything else is built for a different
python version. Either change portage's to the same as everythhing else or remerge all packages that depend
on portage first.

- --

Fernando Rodriguez
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIbBAEBCAAGBQJXsb/LAAoJEPbOFX/5UlwcNXYP90frLRuF6wdEiagkMJys40Bo
CTqdEpBlFmVRxqKFORspK6cnqqOQwpUII58nGkITp7XoNSK0FfQRtZH7ANvW9VL4
s4C54VjMzd8avjxlf06nV0VSdLD/Et8UzqXwYrKMKwJtXDVzVBUEgqSsz2CoPDoi
295PFoLRhlShJ+MXZGOTCwc3U+WJ1NJmotgzQkwprKLifAZLQguXyZW1yEVfrT2E
1Q+boC5gcCat6DkSsMFoQd/GMlXabeoiHUowFD5bbv8hyDOdQokmDbIuSJkF3miO
6UJ7LC7CWezqxl7X7u2ZDc6jntTQO3j+CkRyNkvNeJEpLpuNgi1NWgSFwEJBS22P
X+X0wEpakyUTokV/IEZ++l7Z78qkn+Bspqokqp0vkMU/5QEu9EgPMe2zdfoX+BRy
NRjX0Ntgf850uzDlvjTKcDVdThW+W0o7hhBOTrd6C0jIZp6htL2RUb79b/qbIeg3
r7/XGip7Iq9ehWIwRui/Uj4k5vHVporXVE+zFcnBrvoME0DZfVI5OuhVv040V+Nj
P64pDr9edgCWxuIqesAITbtaHH5Fjc8zTx5+67uqUb+wwn0aVn3ptKQjJqy5364r
o38VEZ5a/Uypxf1Q03NL/mJgVswLv21D1tURosE7p9oduGa4LGszPnBDSi9oIkh1
lYV7vHU1nyy0vGY9M+E=
=7ftw
-----END PGP SIGNATURE-----

[Fernando Rodriguez]

On 08/15/2016 09:12 AM, Fernando Rodriguez wrote:
> On 08/13/2016 09:40 AM, hw wrote:
>> Fernando Rodriguez schrieb:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
>>>> Is it perhaps an idea to mask the gentoolkit package when updating portage?
>>>
>>> Since that version of gentoolkit doesn't depend on a specific version of portage
>>> but does depend on portage with the same python_targets use flags, I think the problem
>>> is that you're trying to emerge portage and gentoolkit with different python_target_XXX
>>> flags, So just make sure they're the same.
>
>> I have removed gentoolkit, and it still fails:
>
>> emerge --ask --update --newuse portage
>> [...]
>> WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
>
>> sys-apps/portage:0
>
>> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) conflicts with
>> sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
>
>
>
> Now it's app-admin/webapp-config it has the same dep on portage (sys-apps/portage[${PYTHON_USEDEP}]) only when the portage use flag is enabled.
>
> You're trying to build portage with a new python target when everything else is built for a different
> python version. Either change portage's to the same as everythhing else or remerge all packages that depend
> on portage first.

Actually rebuilding everything that depends on python won't work because the --newuse would've pull
them if it was a global change. You must've changed just for portage on package.use at some point.
What is the output of "equery uses app-admin/webapp-config sys-apps/portage"?



--

Fernando Rodriguez

[hw]

Fernando Rodriguez schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 08/13/2016 09:40 AM, hw wrote:
>> Fernando Rodriguez schrieb:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
>>>> Is it perhaps an idea to mask the gentoolkit package when updating portage?
>>>
>>> Since that version of gentoolkit doesn't depend on a specific version of portage
>>> but does depend on portage with the same python_targets use flags, I think the problem
>>> is that you're trying to emerge portage and gentoolkit with different python_target_XXX
>>> flags, So just make sure they're the same.
>>
>> I have removed gentoolkit, and it still fails:
>>
>> emerge --ask --update --newuse portage
>> [...]
>> WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
>>
>> sys-apps/portage:0
>>
>> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) conflicts with
>> sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)] required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
>>
>>
>
> Now it's app-admin/webapp-config it has the same dep on portage (sys-apps/portage[${PYTHON_USEDEP}]) only when the portage use flag is enabled.
>
> You're trying to build portage with a new python target when everything else is built for a different
> python version. Either change portage's to the same as everythhing else or remerge all packages that depend
> on portage first.

Since someone said I should use the same python target for everything,
I set one globally. Why wouldn´t that target be used?

Even if that would work, I can´t update portage before it´s updated to
a version which can work with EAPI 6 packages, and it can´t be updated
before it can work with EAPI 6 packages.

So the only way to update would be step by step. I´m probably willing
to try that, but I expect other problems when doing that, like with
updating perl. And I can´t do that because it is required that perl
works when the updating is done.

[hw]

Neil Bothwick schrieb:

> On Sat, 13 Aug 2016 16:08:34 +0200, hw wrote:
>
>> infrequently update Gentoo because I´m *always* running into problems
>> like this.
>
> Every time, or is that just hyperbole?

every time

>> 'Infrequently' means about every 3 months at home, and not
>> since, IIRC, 2015-02 here at work. The last update at home got stalled
>> because perl cannot be updated, and I haven´t had the time to look into
>> that to finish it.
>
> Problems like this are usually resolved quickly. Syncing and updating a
> couple of days later would probably have sorted it.

That´s what I was hoping, but the problem remained. I can´t try it now
because I don´t have internet at home atm.

>> The other reason is that it takes time to update the kernel when a new
>> one comes along, so updating like every week is not feasible. And I
>> don´t want to reboot all the time.
>
> You don't need to boot into every new kernel that hits portage. As long
> as your current kernel has no security issues you can stick with it.
> Plenty of people use Gentoo with only the LTS kernels.

Probably, yes, but who knows if everything works fine with an older kernel?
New versions of some software might require a sufficiently recent kernel.

>> Besides, I don´t want to update too frequently because there may issues
>> with new versions of software.
>
> If you use the stable arch, you don't get brand new versions. Packages
> are normally a month old before they hit stable.

That doesn´t mean that things might stop working, and besides replacing the
software itself, there might be some updating procedure that needs to be
followed.

>> If you say that you need to update more frequently than every 3 months
>> for not to have problems with the update process itself, I can only
>> conclude that Gentoo is entirely unsuited for servers --- and for home
>> use as well other than for test machines perhaps.
>
> It may be more a case of Gentoo being unsuited for you, your
> expectations and your preferred way of working. In fact, any rolling
> release distros sounds like it won't be right for you.

Who can afford to run into problems every time they update when they need
to keep things working? Problems with the very update process itself is
something you shouldn´t have to expect at all.

[Rich Freeman]

On Tue, Aug 16, 2016 at 7:23 AM, hw <h...@gc-24.de> wrote:
> Neil Bothwick schrieb:
>>
>> On Sat, 13 Aug 2016 16:08:34 +0200, hw wrote:
>>
>>> infrequently update Gentoo because I´m *always* running into problems
>>> like this.
>>
>> Every time, or is that just hyperbole?
>
> every time

Keep in mind that your reaction to problems with updates seems to be
to avoid updates and run them less frequently. However, this is the
sort of thing that is likely to make updates even more complicated to
resolve.

I tend to run most of my updates daily. Usually I run into no
problems, but occasionally I do (let's say once a month as a guess).
When I do run into a problem there are typically only a few packages
to be updated, so it is fairly obvious where the problems are coming
from. Usually somebody has already posted on a list or forum about
the issue, or there is a bug. If I end up fixing it myself it is a
lot easier to ID the issue when only a few packages are in scope.

However, if I ran an update once a year then I'd end up getting a list
of 500 packages to update, and probably about 12 different issues. I
wouldn't know which of those 500 packages are causing those 12 issues,
and I'd have to fix all 12 before the whole bolus is updated. I might
also run into circular dep issues since packages would have been
introduced to the tree, become dependencies, then been removed in the
time since my last update.

There are ways to do these kinds of updates but they're going to
require a lot of effort on your part to make them possible. You'd
probably want to set up your own repo to sync your production servers
from, and serve binary packages to reduce the build-time dependency
load. Plus, you probably don't want production machines building
packages anyway.

--
Rich

[hw]

Rich Freeman schrieb:

> On Sat, Aug 13, 2016 at 10:08 AM, hw <h...@gc-24.de> wrote:
>>
>> I infrequently update Gentoo because I´m *always* running into problems
>> like this. 'Infrequently' means about every 3 months at home, and not
>> since, IIRC, 2015-02 here at work. The last update at home got stalled
>> because perl cannot be updated, and I haven´t had the time to look into
>> that to finish it.
>
> You're probably always running into problems like this because you
> infrequently update Gentoo.

Every three months is not infrequently.

> If you ran it every day you'd probably only run into issues every
> couple of months, and when you did you'd have it immediately narrowed
> down to a few packages since that is all that has changed.

Seriously, update every day?

>> If you say that you need to update more frequently than every 3 months
>> for not to have problems with the update process itself, I can only
>> conclude that Gentoo is entirely unsuited for servers --- and for home
>> use as well other than for test machines perhaps.
>>
>
> If you're looking for a distro designed to just work with no hands-on,
> then you should probably look elsewhere.
>
> Put it another way, why are you using Gentoo instead of Debian or
> CentOS in the first place?

Gentoo seems better suited when you want to use ZFS and doesn´t come with
as much bloat as Centos or Debian, and I don´t want systemd.

Besides, the installer Centos comes with failed to partition the disks, and I
didn´t have time and wasn´t inclined to mess with that. Both Centos and Debian
can leave you with rather ancient software, and Centos might not be updatable
at all. On top of that, Debian left users stranded with non-working systems
with their brokenarch and no fix in sight, at which time I replaced it after
over 15 years of using it, and it became deprecated. If it wasn´t for that,
I wouldn´t use Gentoo or consider Centos.

So after all, Gentoo seemed the least-bad choice with some arguments for it.
Now it turns out that you can´t update it without running into problems all
the time, and currently not at all.

> Gentoo is useful when you want to mess with the configuration of the
> distro itself, not when you just want to throw a few files in
> /var/www/htdocs and be done with it.
>
> Gentoo can be made to work rather well on servers, but you have to
> know what you're doing. You can't just run emerge -u world on a
> production server that hasn't been touched in a year and expect to
> work. However, you certainly could set up your own local repository,
> pull in updates as needed (certainly including frequent security
> updates), build binary packages and deploy to your test environment,
> make sure everything is good, and then deploy those binary packages to
> your production servers. You can accomplish a lot of things that way
> that you couldn't accomplish with CentOS or Debian.
>
> However, if all you want is the same binaries Debian already gives
> you, then just run Debian. It isn't like apache runs better just
> because you compiled it yourself. Gentoo is about tweaking things.
> And if you're going to tweak things in an enterprise environment then
> you need to be doing QA.
>
> If you really want to be deploying updates into production without any
> testing then you ought to stick with the likes of CentOS/RHEL. That's
> basically their entire value-add. Debian stable would be another
> option.

This is an entirely different issue: Does the new version of the software
work? It´s beside the point, which is: Is the distribuiton updateable?

Gentoo and Fedora don´t classify as updateable, and since Fedora doesn´t,
Centos doesn´t either (even only the latest version of Centos claims to be
probably updateable, previous versions weren´t at all). Debian used to be
updateable, yet the leaps were so big that you were better off running testing
all the time to avoid them until it became too messed up.

Unfortunately, that doesn´t really leave any good choices. And what is the
advantage of Gentoo supposed to be when you can´t even update it to be able to
do your testing to see if it works?

[Neil Bothwick]

On Tue, 16 Aug 2016 14:13:16 +0200, hw wrote:

> > You're probably always running into problems like this because you
> > infrequently update Gentoo.
>
> Every three months is not infrequently.

It is considered so for Gentoo.

> > If you ran it every day you'd probably only run into issues every
> > couple of months, and when you did you'd have it immediately narrowed
> > down to a few packages since that is all that has changed.
>
> Seriously, update every day?

Why not? If you're running stable, most days there won't be anything to
update, but when there is it is only a few packages, making problems less
likely to occur and easier to deal with if they do.


--
Neil Bothwick

We are upping our standards - so up yours.

[Neil Bothwick]

On Tue, 16 Aug 2016 13:13:38 +0200, hw wrote:

> Since someone said I should use the same python target for everything,
> I set one globally. Why wouldn´t that target be used?

It will, unless overridden per-package, but existing software will still
be installed with the old settings.

> Even if that would work, I can´t update portage before it´s updated to
> a version which can work with EAPI 6 packages, and it can´t be updated
> before it can work with EAPI 6 packages.

Which EAPI6 packages does the latest portage require? If it really
requires EAPI6 to upgrade from EAPI5, this is a bug, but one that would
have been reported and dealt with swiftly.

> So the only way to update would be step by step. I´m probably willing
> to try that, but I expect other problems when doing that, like with
> updating perl. And I can´t do that because it is required that perl
> works when the updating is done.

Forget your Perl experience, that was a completely different issue.


--
Neil Bothwick

Weird enough for government work.

[Alan McKinnon]

On 16/08/2016 14:13, hw wrote:
> So after all, Gentoo seemed the least-bad choice with some arguments for
> it.
> Now it turns out that you can´t update it without running into problems all
> the time, and currently not at all.

No, that is absolutely not true.

You have to understand that you must accept Gentoo on it's own terms and
realize what it is.

Here are some things that Gentoo IS NOT:

- A replacement for Debian/Centos with the same ease of maintenance
- A trouble-free distro
- A distro with assurances that the devs won't break it
- Suitable for production use without a QA system behind it




Gentoo is not for any of those cases. Gentoo is built by people who want
to customize or build a system that no-one else offers and you as the
user have to take that mindset as well.

With Gentoo, you own a race-car. It needs constant fiddling to keep it
happy and if you leave it in the garage for 6 months it complains very
very loudly.

I've been reading this thread all along, and one thing is clear to me:

Gentoo is not for you (unless you change your expectations), it does not
do what yu want and likely never will. You need a binary distro.



--
Alan McKinnon
alan.m...@gmail.com

[Rich Freeman]

On Tue, Aug 16, 2016 at 8:13 AM, hw <h...@gc-24.de> wrote:
>
> Every three months is not infrequently.
>

>...
>
> Seriously, update every day?
>

As Neil has mentioned, there seems to be a mismatch in expectations.
Every day updates are probably fairly typical for Gentoo users. I
don't update all my containers every day, but a typical container is
@system, a few convenience applications (screen, vim, atop, etckeeper,
cfg-update, nullmailer), and a single real application. And those get
updated monthly (and from having updated my host daily issues that
come up tend to be repeats).

By Gentoo standards updates every three months is fairly infrequently.
And the system you're having issues with at the moment is a few times
older than that.

Remember, this isn't a binary distro where the only thing you need
working to do an upgrade is tar, gzip, and stuff like glibc. Gentoo
updates require working build systems and those tend to be fussy. The
list of dependencies is MUCH larger, and when you factor in USE flags
the configuration space is huge. This makes portage slower than a
typical binary package manager, and updates are more failure-prone.

If you want something that "just works" I fully get that, but it just
isn't Gentoo. Our developers and most of our users would not want to
sacrifice some tweakability just to make emerge die less often.

I do sympathize that the other distros aren't quite meeting your
needs. Gentoo can do just about anything, but it comes at the cost of
tinkering. It sounds like you want Arch minus systemd, but you'll
probably need to start your own distro for that. Unfortunately
distros require a certain critical mass and there are only so many
permutations of the binary distros out there.

--
Rich

[hw]

Neil Bothwick schrieb:

> On Sat, 13 Aug 2016 16:26:21 +0200, hw wrote:
>
>>> If you see this now, your production server hasn't been updated for a
>>> long time...
>>
>> About 1.5 years --- not really a long time.
>
> You're kidding, right? You're running a production server without the
> last 18 months' worth of security updates?

What can you do when you don´t have the time to do the updates, especially
when you know that they will give you trouble and can take all day or even
longer.

[Daniel Frey]

I run a half a dozen gentoo servers to do some tasks in our environment.
I typically *make time* to update at least four times a year. I
generally do not have any problems or blockers to deal with. Each of
those instances are specific and don't have any unnecessary cruft to
deal with (i.e. no GUI or anything. Base environment + tool needed.)

Ironically I am updating as we speak and while it does take some
unattended time to finish (I don't have to sit there and watch it)
starting and confirming the update list took all of about a minute.
After it's done I habitually run perl-cleaner, python-updater, then
--depclean it and revdep-rebuild them. There may be a kernel update but
I do not do major kernel updates unless there is a need, but incremental
updates I apply.

When I go update each one it probably takes 20 minutes to do them all,
and I do it at the same time I wind up applying Windows server patches.

I did drag a really old gentoo installation at work after 2.5 years of
updates not applying. Yes, it took a day, and would have been faster to
reinstall from scratch. I chalked it up to my own damn fault and since
then update four times a year and haven't had any major issues since.

Dan

[hw]

David Haller schrieb:

> Hello,
>
> On Sat, 13 Aug 2016, Andreas K. Hüttel wrote:
>> Am Mittwoch, 10. August 2016, 12:54:37 schrieb hw:
>>> I?m trying to upgrade portage because I?m getting a message that it
>>> needs to be able to work with EAPI 6 packages and can only do EAPI 5.
> [..]
>> If you see this now, your production server hasn't been updated for a long
>> time...
>>
>> As a last resort, you should be able to run a "non-installed" portage version
>> to update your system once. Manually download and unpack a recent portage
>> tarball somewhere temporary and then run as root something like
>>
>> porto tmp # ./portage-2.3.0/bin/emerge -uDNav world
>>
>> This can update your system to the newest state, including updating the
>> installed portage. Afterwards you won't need the temporarily unpacked portage
>> anymore.
>
> Yep. BTDT. I had a then 4-4.5 year old gentoo quite broken by being
> partly updated until portage/emerge broke and much else didn't work
> anymore (gcc/make/python/emerge). So, I booted something else, mounted
> gentoo somewhere (say /mnt), unpacked a fresh stage3 _into_ that
> mountpoint into /stage3 (i.e. "/mnt/stage3"), chrooted there (with the
> usual /sys, /proc, /dev bind-mounts) and then ran stuff from the
> /stage3/ tree[1] until the basic stuff (mainly above mentioned 4) was
> fixed.

How would it fix the system you chrooted from? Doesn´t it remain limited
to the chrooted environment?

> From then on it mostly went "smooth", by the "textbook",
> considering. Yeah, lots of conflicts and whatnot because of moves,
> renames and new deps etc.pp. It was a bit tedious, but not difficult.
>
> And this general tip came out of it: unmerging stuff helps to break
> tangles. Like slashing the Gordian Knot ;)

When I unmerge stuff, that stuff doesn´t work anymore, so I´d have to
do that at night.

And now I cannot emerge gentoolkit after unmerging it, which isn´t useful
at all.

> Before you yourself get stuck in the same tangles that emerge did,
> be bold, take note and switch to a "unmerge + reemerge" strategy!
> I.e. take one offender, note it down (textfile and/or paper), unmerge
> it, try a re-emerge of that offender or a @world without it. Keep
> adding to the "offenders" list until emerge comes up "clean". Then try
> re-emerging the offenders one by one.
>
> It's one of the first things I do when weird stuff/conflicts crop up.
> Before I mess with useflags and masks and whatnot, I unmerge both
> tangled packages (and keep track of anything I unmerge in a textfile
> or so!) and then try to merge only those (with '--pretend --tree' at
> first). Emerge IMO handles the "install" case much better and the
> conflicts are often much clearer, "obsolete" deps can be ignored
> and/or handled later by "emerge @preserved-rebuild".
>
> And once I've figured out what's going on, it often is just one
> useflag, or one (un)mask or something else in /etc/portage/package* to
> clear it all up.
>
> And finding that is much easier doing it one-by-one.

Still it is extremely tedious.

> Of course, you can't unmerge stuff like gcc/make/python/portage just
> like that, that's when an unpacked /stage3 comes into play. But you
> should not need that until your system is _way_ outdated (as was
> mine).

IMO, it´s a silly bug that portage cannot be updated because it cannot
deal with packages it needs to deal with in order to update it. Someone
created this problem, and they should have thought about what they were
doing and have created a way for the package management to handle this
problem.

> Anyway: so, yes, you can use a unpacked up-to-date /stage3 for
> bootstrapping an update once your system is so (ridiculously) outdated
> that a normal update breaks, and not only for installing a new system
> :)

Three months is not "ridiculously outdated", yet the update doesn´t work.
1.5 years isn´t "ridiculously outdated", either --- maybe a bit old, but
what´s the problem?

> Of course, you'll have to deal with new/renamed/moved/gone packages
> and such stuff, but that's to be expected[3].

Perhaps you can do that when you´re an expert user of the packagage
management and have lots of time on your hands. I just need to update.

> And IIRC that strategy
> had me upgrading quite smoothly to the new perl-5.24 (from 5.20 or
> .22?) just recently. At times, emerge _does_ get somewhat stuck. And
> it's output gets confusing to match.

There was a version in between, and the update failed. The output of
emerge is very confusing and doesn´t tell me much, if anything, and
I haven´t had the time to finish the update yet. That´s going on
for a month or two now, and it´s still not updated.

> But! Usually, when your system is not too much out of date, emerge
> does a _very_ good job, it's output is a bit hard to read though,
> something IIRC the devs are the first to admit, but as Neil and others
> prove here often (I'll try to get more into helping too), you can get
> used to it and pinpoint the actual reason for emerge barfing tons of
> text on you.

It would already be much easier if emerge wouldn´t print darkblue on black,
which makes it even harder to read the output ... The messages are cryptic,
and you have to guess what they are trying to tell you.

[Michael Mol]

My workstation updates on a cron job every day at 6PM. I check my email in the
morning to see if it ran into any trouble, correct whatever it complained
about, and let it try again the next evening.

Now, I wouldn't do that on a server...but I *would* orchestrate server updates
with Gentoo, albeit it would take a significant amount of smarts in my
automation efforts, and lots of integration testing and a couple manual steps.

--
:wq

[hw]

james schrieb:

Thanks --- if I update, I´ll probably try this step-by-step method. It
seems to be the most promising way.

[Rich Freeman]

On Tue, Aug 16, 2016 at 11:02 AM, Michael Mol <mik...@gmail.com> wrote:
>
> My workstation updates on a cron job every day at 6PM. I check my email in the
> morning to see if it ran into any trouble, correct whatever it complained
> about, and let it try again the next evening.
>

I think you're better-off building binary packages at night and
installing them during the day. I'm not really keen on having Portage
do whatever it wants. It doesn't happen all that often but sometimes
I end up with a proposed downgrade that I'd prefer that it not do.

I can't tell you who I stole this script from (one of the lists):

#!/bin/sh

LIST=$(mktemp);

emerge -puD --changed-use --color=n --columns --quiet=y --changed-deps
--with-bdeps=n world | awk '{print $2}' > ${LIST}

for PACKAGE in $(cat ${LIST});
do
printf "Building binary package for ${PACKAGE}... "
emerge -uN --quiet-build --quiet=y --buildpkgonly ${PACKAGE};
if [[ $? -eq 0 ]];
then
echo "ok";
else
echo "failed";
fi
done

It can only get one level deep when there are dependencies. So, if
you have a KDE update you'll still do a lot of building during the
day. But, at least you won't be building kdelibs. And this is really
nice when chromium comes along with an update.

--
Rich

[Peter Humphrey]

On Tuesday 16 Aug 2016 16:58:20 hw wrote:

> Three months is not "ridiculously outdated", yet the update doesn´t work.

Three months *is* a dangerously long time to leave a Gentoo system, whether
you like it or not, and just asking for trouble. Eighteen months is worse
than ridiculous - it's impossible to work with.

> 1.5 years isn´t "ridiculously outdated", either --- maybe a bit old, but
> what´s the problem?

You aren't listening. You've already had several answers. Just go back and
read them - and be prepared to admit that you might be mistaken here and
there.

Several of the world's most highly qualified experts on running Gentoo
systems have offered you their advice. I submit that it would be arrogant to
ignore it or repudiate it.

--->8

> It would [...] be much easier if emerge [didn't] print dark blue on black,

> which makes it even harder to read the output ...

I dislike that colour combination too. Two possibilities: either specify
nocolor, or select the dark text with the mouse to show it in what we used
to call reverse-video.

> The messages are cryptic, and you have to guess what they are trying to
> tell you.

*Guess?* Good God, man. You don't guess - you use your experience and your
logical reasoning to deduce likely cause and effect.

If you aren't prepared to learn how to maintain it, to put it bluntly Gentoo
is not for you. You've been told that several times too.

I'm sure none of us want to drive you away, but you make it clearer each day
that you don't want to adapt to Gentoo. You may argue that the machine
should adapt itself to the human, not vice versa, but that requires you to
choose a setup that tries to do so. Gentoo is not that system. Full stop.

--
Rgds
Peter

[Neil Bothwick]

On Tue, 16 Aug 2016 16:58:20 +0200, hw wrote:

> Perhaps you can do that when you´re an expert user of the packagage
> management and have lots of time on your hands. I just need to update.

This is what makes us think Gentoo is not the right choice for you.

> It would already be much easier if emerge wouldn´t print darkblue on
> black, which makes it even harder to read the output ...

man color.map


--
Neil Bothwick

Obscenity is the crutch of inarticulate motherfuckers.

[Neil Bothwick]

On Tue, 16 Aug 2016 16:29:45 +0200, hw wrote:

> >> About 1.5 years --- not really a long time.
> >
> > You're kidding, right? You're running a production server without the
> > last 18 months' worth of security updates?
>
> What can you do when you don´t have the time to do the updates,

On a *production* server? You either find or buy the time. The
alternatives are much worse.

> especially when you know that they will give you trouble and can take
> all day or even longer.

You've got yourself into a loop here. You won't update often because you
get problems when doing so, but those problems occur because you don't
update often enough.


--
Neil Bothwick

Q: What's the proper plural of a 'Net-connected Windows machine?
A: A Botnet

[Michael Mol]

So, here's my crontab entry. It's not necessarily the most efficient, but since I'm not around to wait on it, I don't really care; it works.

 

0 18 * * * /usr/bin/eix-sync >/dev/null; /usr/bin/glsa-check --list ; /usr/sbin/perl-cleaner all ; /usr/sbin/python-updater ; /usr/sbin/haskell-updater ; /usr/bin/emerge -uDN @wor
ld && emerge @preserved-rebuild && revdep-rebuild && emerge --depclean && revdep-rebuild

The eix-sync, when backed by git, is really, really, really noisy, so I >/dev/null it. There's a ridiculous amount of stuff in the output every night. Though that may be because of my EMERGE_DEFAULT_OPTS:

 

EMERGE_DEFAULT_OPTS="--tree --with-bdeps=y --keep-going --quiet-build=y --deep --unordered-display --load-average 3 --jobs=3 --rebuild-if-new-slot y"

In the end, it's been working for me for quite a long time. I've been doing this (or something like it) for well over a year without it hosing my system. I even have it rolling updating KDE Plasma, KDE Applications, KDE Frameworks and Qt, though that takes about 450 lines in packages.accept_keywords.

 

If I were to automate something for servers, it'd be a much more intense process, with tight constraints on versioning, integration with application unit tests and further integration tests at each step. (Something I'd absolutely *love* to do, but no way I'm going to have time for setting that up right now. So it's yum-cron on non-critical servers, and manual zoned rolling updates on critical ones.)

 

--

:wq

[Rich Freeman]

On Tue, Aug 16, 2016 at 11:43 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote:
> On Tuesday 16 Aug 2016 16:58:20 hw wrote:
>
>> The messages are cryptic, and you have to guess what they are trying to
>> tell you.
>
> *Guess?* Good God, man. You don't guess - you use your experience and your
> logical reasoning to deduce likely cause and effect.
>

Well, on this one I have to admit I sometimes feel like I'm breaking
on the divining rods when I get errors from portage. I don't think
anybody is really satisfied with them. The devs have been doing what
they can to improve this but I think the issue is that portage often
realizes that something is wrong, but it can't really tell what.
Often this is the result of poor developer practices. Just as often
adding --backtrack to the options fixes it.

--
Rich

[Mick]

> *0 18 * * ** */usr/bin/eix-sync >/dev/null; /usr/bin/glsa-check --list ;
> /usr/sbin/perl-cleaner all ; /usr/sbin/python-updater ;
> /usr/sbin/haskell-updater ; /usr/bin/emerge -uDN @wor*

>
> The eix-sync, when backed by git, is really, really, really noisy, so I
> >/dev/null it. There's a ridiculous amount of stuff in the output every
> night. Though that may be because of my EMERGE_DEFAULT_OPTS:
>

> *EMERGE_DEFAULT_OPTS*=*"--tree --with-bdeps=y --keep-going --quiet-build=y
> --deep -- unordered-display --load-average 3 --jobs=3 --rebuild-if-new-slot
> y"*

>
> In the end, it's been working for me for quite a long time. I've been doing
> this (or something like it) for well over a year without it hosing my
> system. I even have it rolling updating KDE Plasma, KDE Applications, KDE
> Frameworks and Qt, though that takes about 450 lines in
> packages.accept_keywords.
>
> If I were to automate something for servers, it'd be a much more intense
> process, with tight constraints on versioning, integration with application
> unit tests and further integration tests at each step. (Something I'd
> absolutely *love* to do, but no way I'm going to have time for setting that
> up right now. So it's yum-cron on non-critical servers, and manual zoned
> rolling updates on critical ones.)

+1 for building binary packages offline in a VM/container and updating your
production server once you've tested all works as intended. Keeping previous
versions of binary packages also means you can revert back to a working
combination if you need to.

The longest I've taken to update a server was around 6 months - I was planning
to retire it, but plans changed. If anything it tested my memory, because I
came across each and every problem I had come across when I was updating my
other systems in the previous 6 months. ;-)

These days I update every week or two, depending on the system in question. I
wouldn't leave it longer than 3 weeks. I think 3 months could be pushing it,
depending if any major changes happened in between and if you know what you're
doing.

The scripts provided above will help you automate the process, although TBH it
only takes a few minutes to run these yourself.

Just my 2c's.
--
Regards,
Mick

[Michael Orlitzky]

On 08/16/2016 10:58 AM, hw wrote:
>
> Three months is not "ridiculously outdated", yet the update doesn´t work.
> 1.5 years isn´t "ridiculously outdated", either --- maybe a bit old, but
> what´s the problem?
>
>> Of course, you'll have to deal with new/renamed/moved/gone packages
>> and such stuff, but that's to be expected[3].
>
> Perhaps you can do that when you´re an expert user of the packagage
> management and have lots of time on your hands. I just need to update.
>

Since everyone is telling you that three months is too long, I've been
perfectly happy updating our systems about once every three months.

Here's what happened: you got unlucky. You waited a long time to update,
and we happened to release a new EAPI right at the beginning of that
time, and someone didn't notice that they were breaking the portage
upgrade process a year later when they updated an ebuild to EAPI=6. It
sucks, but a few people have posted easy solutions.

You're not going to break the system even if you trash portage. Try to
download a snapshot of portage from git and run that. Once you have a
portage that works with EAPI=6, all of the other errors get a lot
simpler. Work your way through the list of packages to be installed
(say) twenty at a time to keep the output readable. Start with the
@system stuff, have some coffee on hand, and remember -- you haven't
been doing anything for a year and a half so you have a lot of time to
waste before you're in the red =P

[Alan McKinnon]

I've trained my brain to recognize familiar output and mentally map what
occurred the last time to the present time :-)

I have also noticed that very often the bit that looks like an error is
actually just info (think --verbose) and the real cause is often
obscured inside a longer sentence.

Practice I guess.

--
Alan McKinnon
alan.m...@gmail.com

[Alan McKinnon]

On 16/08/2016 20:04, Mick wrote:
> The longest I've taken to update a server was around 6 months - I was planning
> to retire it, but plans changed. If anything it tested my memory, because I
> came across each and every problem I had come across when I was updating my
> other systems in the previous 6 months. ;-)

I went three years once. But I got lucky, if you recall portage
development speeded up a lot 2 years or so ago and was far less busy
before that. I did that update at the tail end of the less busy period.
Took about 2 weeks :-)

And I did come across all the same problems you mention. I did it mostly
to prove to myself I still have what it takes, but it sure wasn't worth
it for any other reason. The box gets updated about monthly now - it has
a small number of routine arch packages found on a LAN, and updates
maybe 20 or so packages a month.

--
Alan McKinnon
alan.m...@gmail.com

[Stroller]

On 16 Aug 2016, at 17:24, Michael Mol <mik...@gmail.com> wrote:

So, here's my crontab entry. It's not necessarily the most efficient, but since I'm not around to wait on it, I don't really care; it works.

 

0 18 * * * /usr/bin/eix-sync >/dev/null; /usr/bin/glsa-check --list ; /usr/sbin/perl-cleaner all ; /usr/sbin/python-updater ; /usr/sbin/haskell-updater ; /usr/bin/emerge -uDN @wor
ld && emerge @preserved-rebuild && revdep-rebuild && emerge --depclean && revdep-rebuild

The eix-sync, when backed by git, is really, really, really noisy, so I >/dev/null it. There's a ridiculous amount of stuff in the output every night. Though that may be because of my EMERGE_DEFAULT_OPTS:

 

EMERGE_DEFAULT_OPTS="--tree --with-bdeps=y --keep-going --quiet-build=y --deep --unordered-display --load-average 3 --jobs=3 --rebuild-if-new-slot y"

In the end, it's been working for me for quite a long time. I've been doing this (or something like it) for well over a year without it hosing my system. I even have it rolling updating KDE Plasma, KDE Applications, KDE Frameworks and Qt, though that takes about 450 lines in packages.accept_keywords.

Your terminal colours are gopping!

Now I've expressed my distaste, can we all go back to plain text email, please?

Mr Mol has been posting in HTML the last week, too - I have yet to update my glasses' prescription, and his font is far too small for me (or, I hope really, for my Retina™ screen).

Stroller.

[David Haller]

Hello,

On Tue, 16 Aug 2016, hw wrote:
>David Haller schrieb:
[..]

>> Yep. BTDT. I had a then 4-4.5 year old gentoo quite broken by being
>> partly updated until portage/emerge broke and much else didn't work
>> anymore (gcc/make/python/emerge). So, I booted something else, mounted
>> gentoo somewhere (say /mnt), unpacked a fresh stage3 _into_ that
>> mountpoint into /stage3 (i.e. "/mnt/stage3"), chrooted there (with the
>> usual /sys, /proc, /dev bind-mounts) and then ran stuff from the
>> /stage3/ tree[1] until the basic stuff (mainly above mentioned 4) was
>> fixed.
>

>How would it fix the system you chrooted from? Doesn?t it remain limited
>to the chrooted environment?

The chrooted-to was the gentoo to be updated. I just booted something
else with a recent enough kernel. So, it was:

/ = <bootsys>
/mnt = Gentoo-/
/mnt/stage3 = current Gentoo-stage-3

Then the usual bindmounts of /proc, /sys, /dev and chroot into /mnt.

So, I was in / of Gentoo with /stage3 the unpacked stage3-tarball.

Then some "magic", by setting PATH and LD_LIBRARY_PATH to use stage3
for the first stuff until I got glibc, gcc, python, portage etc.
in / itself up-to-date.

export PATH=/stage3/sbin:/stage3/usr/sbin:/stage3/bin:/stage3/usr/bin:$PATH
export LD_LIBRARY_PATH="/stage3/lib64:/stage3/usr/lib64"
and IIRC
export PYTHONPATH"/stage3/usr/lib64/python2.7:/stage3/usr/lib/python2.7:$PYTHONPATH"

If I typed 'which emerge' it showed to be the current version from
stage3 and could handle the updated portage-tree and new EAPI.

I thought this easier than the way shown in the wiki where you chroot
to the stage3. Actually, I guess I'm wrong when you just do an

alias emerge='/usr/bin/emerge --root=/mnt/host --config-root=/mnt/host'

after you chrooted to the /stage3 as per
https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Updating_old_systems

>> From then on it mostly went "smooth", by the "textbook",
>> considering. Yeah, lots of conflicts and whatnot because of moves,
>> renames and new deps etc.pp. It was a bit tedious, but not difficult.
>>
>> And this general tip came out of it: unmerging stuff helps to break
>> tangles. Like slashing the Gordian Knot ;)
>

>When I unmerge stuff, that stuff doesn?t work anymore, so I?d have to
>do that at night.

Well, when it's just one or two packages, that usually doesn't take
that long.

>There was a version in between, and the update failed. The output of

>emerge is very confusing and doesn?t tell me much, if anything, and
>I haven?t had the time to finish the update yet. That?s going on
>for a month or two now, and it?s still not updated.

IIRC that was because modules were moved into perl-core, i.e.
disappeared as seperate modules and stuff might have still had them
as deps.

-dnh

--
I'm broken. Please show this to someone who can fix can fix
-- A message in a TeX system
(Kudos to H J Haataja for the sig)