[gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?

[n952162]

Sorry, I have to bitch.

This kept me going for several additional gentoo hours:


!!! All ebuilds that could satisfy
"dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]"
have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8)

The current version of portage supports EAPI '7'. You must upgrade to a
newer version of portage before EAPI masked packages can be installed.
(dependency required by "dev-python/rdflib-5.0.0::gentoo" [ebuild])
(dependency required by
"media-libs/lv2-1.18.2::gentoo[python_single_target_python3_9]" [ebuild])
(dependency required by "media-libs/sratom-0.6.8::gentoo" [installed])
(dependency required by "media-sound/audacity-2.4.2-r1::gentoo[lv2]"
[installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

After realizing that I didn't have the dependency tree to help me debug,
and finally realized I had to remove audacity, world started emerging
(it'll take a day or two to complete - it does every month).

dev-python/isodate?  Isodate???  How can that not be stable?

That was the only ebuild on my system with EAPI 8.

This isn't a distribution, it's a silly toy for some super-intelligent
people to play with, causing idiots like me hours and hours just trying
to maintain stability.

[David Haller]

Hello,

On Mon, 02 Aug 2021, n952162 wrote:
>!!! All ebuilds that could satisfy
>"dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]"
>have been masked.
>!!! One of the following masked packages is required to complete your
>request:
>- dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8)
>
>The current version of portage supports EAPI '7'. You must upgrade to a

^^^^^^^^^^^^^^^^^^^^^^^^^^

>newer version of portage before EAPI masked packages can be installed.

You should read a bit more carefully... It seems your sys-apps/portage
is a bit dated.

Upgrade sys-apps/portage first, then it should work.

HTH,
-dnh

--
printk(KERN_DEBUG "%s: burped during tx load.\n", dev->name)
linux-2.6.6/drivers/net/3c501.c

[n952162]

On 8/2/21 10:10 PM, David Haller wrote:

Hello,

On Mon, 02 Aug 2021, n952162 wrote:

!!! All ebuilds that could satisfy
"dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]"
have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8)

The current version of portage supports EAPI '7'. You must upgrade to a

     ^^^^^^^^^^^^^^^^^^^^^^^^^^

newer version of portage before EAPI masked packages can be installed.

You should read a bit more carefully... It seems your sys-apps/portage
is a bit dated.

Upgrade sys-apps/portage first, then it should work.

HTH,
-dnh

I read that, but I last updated 2 months ago.  So, this update breaks because portage was updated and new ebuilds using that are already being pushed out?  Seems strict to me ... but isodate  being the only one?  I still have a EAPI 4 on my system (1).  Plenty of EAPI 5.  Was there something in isodate that needed to be urgently updated - utilizing the the cutting edge EAPI?

[n952162]

We just had to update portage not so long ago.  I admittedly presumed at first that something else must be wrong, because it didn't occur to me that portage would be so volatile.

Everything in gentoo is so nicely configurable, but I think another dimension should be add: configurable volatility - i.e. a configurable hysteresis for upstream updates.

[cal]

On 8/2/21 10:26 PM, n952162 wrote:
> On 8/3/21 7:20 AM, n952162 wrote:
>> On 8/2/21 10:10 PM, David Haller wrote:
>>> Hello,
>>>
>>> On Mon, 02 Aug 2021, n952162 wrote:
>>>> !!! All ebuilds that could satisfy
>>>> "dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]"
>>>>
>>>> have been masked.
>>>> !!! One of the following masked packages is required to complete your
>>>> request:
>>>> - dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8)
>>>>
>>>> The current version of portage supports EAPI '7'. You must upgrade to a
>>>       ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> newer version of portage before EAPI masked packages can be installed.
>>> You should read a bit more carefully... It seems your sys-apps/portage
>>> is a bit dated.
>>>
>>> Upgrade sys-apps/portage first, then it should work.
>>>
>>> HTH,
>>> -dnh
>>
>>
>> I read that, but I last updated 2 months ago.  So, this update breaks
>> because portage was updated and new ebuilds using that are already

>> being pushed out?  Seems strict to me ... but /isodate/ being the only

>> one?  I still have a EAPI 4 on my system (1). Plenty of EAPI 5.  Was
>> there something in isodate that needed to be urgently updated -
>> utilizing the the cutting edge EAPI?
>>
>
> We just had to update portage not so long ago.  I admittedly presumed at
> first that something else must be wrong, because it didn't occur to me
> that portage would be so volatile.
>
> Everything in gentoo is so nicely configurable, but I think another
> dimension should be add: configurable volatility - i.e. a configurable
> hysteresis for upstream updates.
>
>
>

It sounds like you would be more satisfied with a distribution that has
releases. You are fighting a losing battle to use a rolling-release
distribution on a machine you intend to update infrequently.

Keeping old software working in a rolling release ecosystem is a pain,
doubly so if you have to maintain the newer version in parallel. What
you ask for is more difficult than you think.

[n952162]

Well, what you say is likely true, but does "old software" really need
to be kept working?  Couldn't problems necessarily  only be dealt with
in the newest versions?

Yes, a release distribution would be one end of the configuration
spectrum I'm thinking of.   That works for other distibutions.

My problem is, I want a source distribution.  Maybe there's something
about source distributions that dictates a rolling strategy?  I don't
see it, but it might be there.

I've raised this issue before and someone mentioned a derivative of
gentoo, which sounds promising, but I'm not convinced by that one
implementation.

[cal]

Old software does not exist in a vacuum. Old software has old
dependencies; those dependencies get updated in ways that are
incompatible, or stop working, or a new version of Python is released
with which the old version of the software is incompatible; etc. Or as
you've noticed with Portage, the old version of the software may not
work compatibly with newer packages, so now you have to maintain older
versions of those packages as well...

>
> Yes, a release distribution would be one end of the configuration
> spectrum I'm thinking of.   That works for other distibutions.
>
> My problem is, I want a source distribution.  Maybe there's something
> about source distributions that dictates a rolling strategy?  I don't
> see it, but it might be there.

I don't think there is any particular reason this must be dictated; it
is probably a coincidence of the Venn diagram of people who prefer
source distributions and people who prefer rolling release.

Many binary distributions do also have tools for building packages from
source, which could be a solution if there are only specific packages
you wish to customize, but the experience is not as pleasant as Portage.

[n952162]

Intuitively, i.e. from vague experience, I know you're right, but I
can't think it through ... a release would be a snapshot of a working
configuration at a point in time.

Ah, perhaps the problem is ... in my case, I could make a distribution
out of what I emerge every month and distibute that - an intermediate
level of hysteresis.  But that's just the system as I require it.  A
Ubuntu makes all those decisions for all supported packages, an effort
that doesn't interest me...

[Neil Bothwick]

On Tue, 3 Aug 2021 07:20:47 +0200, n952162 wrote:

> I read that, but I last updated 2 months ago.  So, this update breaks
> because portage was updated and new ebuilds using that are already being
> pushed out?

You should have seen a message from emerge --sync telling you that a new
version of portage was available and to run emerge -1au portage before
updating anything else.


--
Neil Bothwick

If such a program has not crashed yet, it is waiting for a critical moment
before it crashes.
-- Murphy's Computer Laws n\xB06

[n952162]

On 8/3/21 12:52 PM, Neil Bothwick wrote:
> On Tue, 3 Aug 2021 07:20:47 +0200, n952162 wrote:
>
>> I read that, but I last updated 2 months ago.  So, this update breaks
>> because portage was updated and new ebuilds using that are already being
>> pushed out?
> You should have seen a message from emerge --sync telling you that a new
> version of portage was available and to run emerge -1au portage before
> updating anything else.
>
>

I find no informational messages containing "portage", "emerge", or
"-1au" in any of the 3 sync runs I captured into one log file. I did
double check news beforehand, but didn't find anything there.

[Neil Bothwick]

On Tue, 3 Aug 2021 15:35:41 +0200, n952162 wrote:

> > You should have seen a message from emerge --sync telling you that a
> > new version of portage was available and to run emerge -1au portage
> > before updating anything else.

> I find no informational messages containing "portage", "emerge", or
> "-1au" in any of the 3 sync runs I captured into one log file. I did
> double check news beforehand, but didn't find anything there.

I don't see them when syncing from a cron script, when all output is
captured and emailed, but do when running sync on a shell. It seems you
only see this when running sync interactively.


--
Neil Bothwick

Unsolicited advice is the junk mail of life

[n952162]

Okay.  A good example of why silently ("automatically") mucking with the
stdout device is a bad  idea.  I wish gentoo wouldn't do that.  When I
want colorization, I write a vim file.

[Arve Barsnes]

On Tue, 3 Aug 2021 at 15:58, Neil Bothwick <ne...@digimed.co.uk> wrote:
> I don't see them when syncing from a cron script, when all output is
> captured and emailed, but do when running sync on a shell. It seems you
> only see this when running sync interactively.

I see these messages in the output from my cron "script". I use
"/usr/sbin/emaint sync -a", and it regularly shows the message about
new portage versions.

The message might not be generated by the sync itself, but from the
postsync 'eix-update' which would maybe show messages like this.

Regards,
Arve

[Peter Humphrey]

I sync daily via git, and every time a new version of portage is included I
see a prominent warning to update it before anything else. Portage has done
this for many years, apart from a few months a year or two ago.

--
Regards,
Peter.

[n952162]

On 8/3/21 5:54 PM, Peter Humphrey wrote:
> On Tuesday, 3 August 2021 15:51:15 BST Arve Barsnes wrote:
>> On Tue, 3 Aug 2021 at 15:58, Neil Bothwick <ne...@digimed.co.uk> wrote:
>>> I don't see them when syncing from a cron script, when all output is
>>> captured and emailed, but do when running sync on a shell. It seems you
>>> only see this when running sync interactively.
>> I see these messages in the output from my cron "script". I use
>> "/usr/sbin/emaint sync -a", and it regularly shows the message about
>> new portage versions.
>>
>> The message might not be generated by the sync itself, but from the
>> postsync 'eix-update' which would maybe show messages like this.

> I sync daily via git, ...


Then you probably build a lot more than I do.

I synced, like yesterday or the day before, and then, on a second
machine, I synced today, in order to update from the first machine,
using a binary update, and, in fact, I was able to get thunderbird, but
llvm AND clang, both huge builds, had to be rebuilt!  Oh man.  Bad
luck?  No, life with gentoo.


(sorry, Peter, for the direct email, apparently a mis-click)




> ... and every time a new version of portage is included I

[Rich Freeman]

On Tue, Aug 3, 2021 at 2:03 AM n952162 <n95...@web.de> wrote:
>
> Well, what you say is likely true, but does "old software" really need
> to be kept working? Couldn't problems necessarily only be dealt with
> in the newest versions?
>

I think you are misunderstanding what actually went wrong in your
situation. Nothing broke in your existing software.

You're using an old version of portage. It will continue to work as
it always has.

However, you wanted to use it with a newer version of the software
repository. This contained a package that wasn't compatible with old
versions of portage. The version of portage you're using detected
this, and refused to install it, so as to not randomly break your
system. Your system continued to work as it always had. You just
couldn't install that particular package, or anything that depends on
it.

Generally we try to maintain a reasonably sane upgrade path going back
maybe six months or so. You just needed to update portage first.

If your system is more than a month or two out of date just running
emerge -uD world or whatever blindly is more likely to run into a
problem. It shouldn't break your system unless you go adding random
options to the command line to override safety features, but it might
involve a few steps (like updating portage, @system, and so on before
trying to update everything).

It usually isn't unmanageable, but Gentoo is definitely not an
LTS-oriented distro. If you want to only get security fixes for three
years and then update everything in one go, then stick with something
like RHEL, Ubuntu LTS, or debian stable. Those distros deliver
exactly that sort of experience, and really there isn't as much
benefit to something like Gentoo if you're just going to update it
every other year anyway.

--
Rich

[n952162]

On 8/6/21 2:16 PM, Rich Freeman wrote:
> On Tue, Aug 3, 2021 at 2:03 AM n952162 <n95...@web.de> wrote:
>> Well, what you say is likely true, but does "old software" really need
>> to be kept working? Couldn't problems necessarily only be dealt with
>> in the newest versions?
>>
> I think you are misunderstanding what actually went wrong in your
> situation. Nothing broke in your existing software.
>
> You're using an old version of portage. It will continue to work as
> it always has.
>
> However, you wanted to use it with a newer version of the software
> repository. This contained a package that wasn't compatible with old
> versions of portage. The version of portage you're using detected
> this, and refused to install it, so as to not randomly break your
> system. Your system continued to work as it always had. You just
> couldn't install that particular package, or anything that depends on
> it.

I think that doesn't characterize my point quite.

I was complaining, mostly, that isodate had to be the thing that was
incompatible with my configuration.  Maybe there is a unavoidable reason
that that package had to move to the newest EAPI, or maybe it was just a
sense that it's cool to be with the cutting edge.  It seems to me that
isodate (which is actually tied, perhaps indirectly, to clearly slow
United Nations rule-making) must be pretty stable.

>
> Generally we try to maintain a reasonably sane upgrade path going back
> maybe six months or so. You just needed to update portage first.

My update was two months late.

>
> If your system is more than a month or two out of date just running
> emerge -uD world or whatever blindly is more likely to run into a
> problem. It shouldn't break your system unless you go adding random
> options to the command line to override safety features,

I don't have the expertise to do something like that.

> but it might
> involve a few steps (like updating portage, @system, and so on before
> trying to update everything).

>
> It usually isn't unmanageable, but Gentoo is definitely not an
> LTS-oriented distro. If you want to only get security fixes for three
> years and then update everything in one go, then stick with something
> like RHEL, Ubuntu LTS, or debian stable. Those distros deliver
> exactly that sort of experience, and really there isn't as much
> benefit to something like Gentoo if you're just going to update it
> every other year anyway.

Those distros are not source distros.  I'm making an argument that
there's a large space between binary distributions and source
distributions that pass every upstream change down in realtime. Gentoo
is in the best position to service that space



>

[n952162]

I see that that begs the question of why someone would be interested in
a source distribution.

With a binary distribution, you fly on trust.  With a source
distribution, you do, too, given the size of the code base.

The difference is, with a source distribution, there's a "paper trail"
that can be followed back if that trust was abused.

That's just about impossible with a binary distro.

[Peter Humphrey]

On Friday, 6 August 2021 12:58:59 BST n952162 wrote:

> (sorry, Peter, for the direct email, apparently a mis-click)

It's easily forgiven. For who among us has never misclicked?

:)

--
Regards,
Peter.

[n952162]

On 8/6/21 5:09 PM, Peter Humphrey wrote:
> On Friday, 6 August 2021 12:58:59 BST n952162 wrote:
>
>> (sorry, Peter, for the direct email, apparently a mis-click)
> It's easily forgiven. For who among us has never misclicked?
>
> :)
>

:-)))

[Rich Freeman]

On Fri, Aug 6, 2021 at 8:37 AM n952162 <n95...@web.de> wrote:
>
> I was complaining, mostly, that isodate had to be the thing that was
> incompatible with my configuration. Maybe there is a unavoidable reason
> that that package had to move to the newest EAPI, or maybe it was just a
> sense that it's cool to be with the cutting edge. It seems to me that
> isodate (which is actually tied, perhaps indirectly, to clearly slow
> United Nations rule-making) must be pretty stable.
>

it is generally encouraged that packages use the latest EAPI - there
are a lot of reasons for doing so. The main ones that get held back
are packages that would interfere with updating portage and the
toolchain, since those are what are most needed when somebody does an
update.

All you need to do in order to resolve an incompatible EAPI issue is
update portage. We don't really provide support for running
out-of-date versions of portage itself. There really isn't much
reason to run an old version of portage - it is unlikely that updating
portage is going to cause incompatibilities on your system as almost
nothing uses portage except the distribution itself.

It might not hurt if that error message included the suggestion to run
"emerge -u portage" to update it. It does say that the solution is to
update portage - it just doesn't explicitly tell you how to do so.

>
> Those distros are not source distros. I'm making an argument that
> there's a large space between binary distributions and source
> distributions that pass every upstream change down in realtime. Gentoo
> is in the best position to service that space
>

There may be a nice for a release-based source-based distribution, and
nothing is stopping anybody from adding releases to Gentoo (a trivial
way to do this would be to just fork the repository and update it in
releases). I just don't think there is THAT much interest among the
community in doing so, and even if such a thing were created I'm
pretty skeptical that they wouldn't at least keep portage and the
EAPIs cutting-edge, as it doesn't really hurt anything to do so.

If you want to kick something like that off though feel free. All you
need to do is clone the Gentoo repository, and use some
branches/tags/etc to manage it. You could pull in whatever you want
in whatever branch you want, and curate releases. Really the only
hard part would be the curation and QA. If you wanted somebody to run
the CI tools against your repo and file bugs for you I wouldn't be
surprised if infra was willing to do so. It would still be a fair bit
of work, and I'm really skeptical that it would get much use.

To address your follow-up email, many popular binary distros have been
working on reproducible builds, so if your main concern is fear of
what might be bundled inside packages, I'd think that would mitigate a
lot of it.

--
Rich

[n952162]

On 8/6/21 8:22 PM, Rich Freeman wrote:
> On Fri, Aug 6, 2021 at 8:37 AM n952162 <n95...@web.de> wrote:
>> I was complaining, mostly, that isodate had to be the thing that was
>> incompatible with my configuration. Maybe there is a unavoidable reason
>> that that package had to move to the newest EAPI, or maybe it was just a
>> sense that it's cool to be with the cutting edge. It seems to me that
>> isodate (which is actually tied, perhaps indirectly, to clearly slow
>> United Nations rule-making) must be pretty stable.
>>

> ...

> It might not hurt if that error message included the suggestion to run
> "emerge -u portage" to update it. It does say that the solution is to
> update portage - it just doesn't explicitly tell you how to do so.

The way out of my dilema would be first to emerge portage and then
emerge @world?


>
> ...

>
> To address your follow-up email, many popular binary distros have been
> working on reproducible builds, so if your main concern is fear of
> what might be bundled inside packages, I'd think that would mitigate a
> lot of it.
>

I will look into reproducible builds, thank you.

[Rich Freeman]

On Fri, Aug 6, 2021 at 2:41 PM n952162 <n95...@web.de> wrote:
>
> On 8/6/21 8:22 PM, Rich Freeman wrote:
> > On Fri, Aug 6, 2021 at 8:37 AM n952162 <n95...@web.de> wrote:
> >> I was complaining, mostly, that isodate had to be the thing that was
> >> incompatible with my configuration. Maybe there is a unavoidable reason
> >> that that package had to move to the newest EAPI, or maybe it was just a
> >> sense that it's cool to be with the cutting edge. It seems to me that
> >> isodate (which is actually tied, perhaps indirectly, to clearly slow
> >> United Nations rule-making) must be pretty stable.
> >>
> > ...
> > It might not hurt if that error message included the suggestion to run
> > "emerge -u portage" to update it. It does say that the solution is to
> > update portage - it just doesn't explicitly tell you how to do so.
>
>
> The way out of my dilema would be first to emerge portage and then
> emerge @world?

In this case that would probably fix it. Some update issues can get
messy if you don't update often, but usually for EAPI issues you just
need to update portage itself.

--
Rich

[antlists]

On 06/08/2021 19:41, n952162 wrote:
>> It might not hurt if that error message included the suggestion to run
>> "emerge -u portage" to update it. It does say that the solution is to
>> update portage - it just doesn't explicitly tell you how to do so.
>
>
> The way out of my dilema would be first to emerge portage and then
> emerge @world?

Probably. If you've left it that long you might find you still have a
few problems.

If you find you have trouble once portage is updated, I've found that
the following often works ...

First do a --update @system (NO deep, no changed use, no nothing like
that). If that succeeds, the remaining steps will be hassle but nothing
serious.

Then try the same with @world.

Finally update @world with deep, newuse etc.

If emerge keeps giving up with too many blocks, just do a oneshot emerge
of a bunch of stuff it says it *can* emerge, and you'll likely find
after a couple of shots of that that it suddenly works. The other trick
I try is, IFF @system was successful, just do a oneshot delete of any
blocking packages and again it should suddenly start working.

Cheers,
Wol

[n952162]

On 8/6/21 11:07 PM, antlists wrote:
> On 06/08/2021 19:41, n952162 wrote:
>>> It might not hurt if that error message included the suggestion to run
>>> "emerge -u portage" to update it. It does say that the solution is to
>>> update portage - it just doesn't explicitly tell you how to do so.
>>
>>
>> The way out of my dilema would be first to emerge portage and then
>> emerge @world?
>
> Probably. If you've left it that long you might find you still have a
> few problems.

That long!

>
> If you find you have trouble once portage is updated, I've found that
> the following often works ...
>
> First do a --update @system (NO deep, no changed use, no nothing like
> that).  If that succeeds, the remaining steps will be hassle but
> nothing serious.
>
> Then try the same with @world.
>
> Finally update @world with deep, newuse etc.
>
> If emerge keeps giving up with too many blocks, just do a oneshot
> emerge of a bunch of stuff it says it *can* emerge, and you'll likely
> find after a couple of shots of that that it suddenly works. The other
> trick I try is, IFF @system was successful, just do a oneshot delete
> of any blocking packages and again it should suddenly start working.
>
>

Yes, this last is the step I've finally accepted is the way out of a
dead-end.