subject:"\[gentoo\-user\] EAPI packages"

On Tue, Aug 16, 2016 at 11:43 AM, Peter Humphrey  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

Re: [gentoo-user] EAPI packages

2016-08-16 Thread Michael Mol

On Tuesday, August 16, 2016 11:19:27 AM Rich Freeman wrote:
> On Tue, Aug 16, 2016 at 11:02 AM, Michael Mol  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.

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*

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

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

Re: [gentoo-user] EAPI packages

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

pgpf2Ot3uSnGm.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages

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.


pgpA8OlYbqV3f.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages

2016-08-16 Thread 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

Re: [gentoo-user] EAPI packages

On Tue, Aug 16, 2016 at 11:02 AM, Michael Mol  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

Re: [gentoo-user] EAPI packages

2016-08-16 Thread Michael Mol

On Tuesday, August 16, 2016 04:29:45 PM hw wrote:
> 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.

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

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

Re: [gentoo-user] EAPI packages


james schrieb:

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.


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

Re: [gentoo-user] EAPI packages


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

Re: [gentoo-user] EAPI packages

2016-08-16 Thread Daniel Frey

On 08/16/2016 07:29 AM, hw wrote:
> 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.
> 
> 

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

Re: [gentoo-user] EAPI packages


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.

Re: [gentoo-user] EAPI packages

On Tue, Aug 16, 2016 at 8:13 AM, hw  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

Re: [gentoo-user] EAPI packages

2016-08-16 Thread 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.mckin...@gmail.com

Re: [gentoo-user] EAPI packages

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.

pgp_U5MhI3a8P.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages

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.

pgpv3ahtPTu78.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages


Rich Freeman schrieb:

On Sat, Aug 13, 2016 at 10:08 AM, hw  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?

Re: [gentoo-user] EAPI packages

On Tue, Aug 16, 2016 at 7:23 AM, hw  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

Re: [gentoo-user] EAPI packages


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.

Re: [gentoo-user] EAPI packages


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.

Re: [gentoo-user] EAPI packages

2016-08-15 Thread 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

Re: [gentoo-user] EAPI packages

2016-08-15 Thread 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-

Re: [gentoo-user] EAPI packages

2016-08-14 Thread 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.

Re: [gentoo-user] EAPI packages

2016-08-14 Thread 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

Re: [gentoo-user] EAPI packages

2016-08-13 Thread Rich Freeman

On Sat, Aug 13, 2016 at 10:08 AM, hw  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

Re: [gentoo-user] EAPI packages

2016-08-13 Thread 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.

pgpWwiOEZ3v52.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages

2016-08-13 Thread 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.

pgpkzPnn71WOG.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] EAPI packages

2016-08-13 Thread 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

Re: [gentoo-user] EAPI packages

2016-08-13 Thread james

On 08/13/2016 10:22 AM, hw wrote:

james schrieb:

On 08/12/2016 07:26 AM, hw wrote:

Michael Orlitzky schrieb:

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.

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.

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.

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.

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=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

Re: [gentoo-user] EAPI packages

2016-08-13 Thread 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.

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

Re: [gentoo-user] EAPI packages

2016-08-13 Thread 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

Re: [gentoo-user] EAPI packages


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 ...

Re: [gentoo-user] EAPI packages


james schrieb:

On 08/12/2016 07:26 AM, hw wrote:

Michael Orlitzky schrieb:

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.




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.


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.


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.

Re: [gentoo-user] EAPI packages


Michael Orlitzky schrieb:

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.


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

Re: [gentoo-user] EAPI packages


Rich Freeman schrieb:

On Wed, Aug 10, 2016 at 10:45 AM, Michael Orlitzky  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.

Re: [gentoo-user] EAPI packages