Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Fri, Aug 6, 2021 at 2:41 PM n952162 wrote: > > On 8/6/21 8:22 PM, Rich Freeman wrote: > > On Fri, Aug 6, 2021 at 8:37 AM n952162 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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 8:22 PM, Rich Freeman wrote: On Fri, Aug 6, 2021 at 8:37 AM n952162 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Fri, Aug 6, 2021 at 8:37 AM n952162 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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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? :) :-)))
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 2:37 PM, n952162 wrote: On 8/6/21 2:16 PM, Rich Freeman wrote: On Tue, Aug 3, 2021 at 2:03 AM n952162 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 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/6/21 2:16 PM, Rich Freeman wrote: On Tue, Aug 3, 2021 at 2:03 AM n952162 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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Tue, Aug 3, 2021 at 2:03 AM n952162 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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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 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 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Tuesday, 3 August 2021 15:51:15 BST Arve Barsnes wrote: > On Tue, 3 Aug 2021 at 15:58, Neil Bothwick 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, 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On Tue, 3 Aug 2021 at 15:58, Neil Bothwick 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
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/3/21 3:58 PM, Neil Bothwick wrote:
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.
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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 pgpPOwYwOElxt.pgp Description: OpenPGP digital signature
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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 pgp4EwhT3b5tL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/3/21 8:29 AM, cal wrote: On 8/2/21 11:03 PM, n952162 wrote: On 8/3/21 7:37 AM, cal wrote: 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. 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? 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... 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...
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/2/21 11:03 PM, n952162 wrote: > On 8/3/21 7:37 AM, cal wrote: >> 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. >> > > 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? 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. > > 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
On 8/3/21 7:37 AM, cal wrote: 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. 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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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?
Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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
[gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?
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.
