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] Re: --depclean wants to remove openrc. Yikes!
On Tue, 03 Aug 2021 07:45:27 -0400, Alec Ten Harmsel wrote: > >$ emerge --ask --depclean | less > > > > did not work when tested with a single package to be removed: the > > output from "emerge" was displayed on less than a single screen > > causing "less" to just terminate due to my setting of environment > > variable "LESS", but "emerge" never issued the question whether or > > not to continue nor did it accept an answer. I had to kill it with > > "^C" from the shell. > > Depending what desktop environment/terminal emulator, there are a few > options. You could use a terminal like gnome-terminal, konsole, etc. > which have scroll so you can run `emerge -ca' and scroll to view the > results. I run urxvt in i3 (not sure whether it scrolls or not), and I > always run emerge inside of a tmux and use tmux's scroll to view all > the output before making a decision, so you could also use tmux or > screen. Or you could use a different pager, most does not exhibit this behaviour. There is probably a less setting to change this too. -- Neil Bothwick Linux like wigwam. No windows, no gates, Apache inside. pgp2qrKTLH_yQ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Mon, Aug 2, 2021, at 09:33, Dr Rainer Woitok wrote: > What I'm trying to solve is reading the > output from "emerge --depclean" one screen full at a time and at the end > being asked whether or not I really want to unmerge all packages listed. > And just running > >$ emerge --ask --depclean | less > > did not work when tested with a single package to be removed: the output > from "emerge" was displayed on less than a single screen causing "less" > to just terminate due to my setting of environment variable "LESS", but > "emerge" never issued the question whether or not to continue nor did it > accept an answer. I had to kill it with "^C" from the shell. > Depending what desktop environment/terminal emulator, there are a few options. You could use a terminal like gnome-terminal, konsole, etc. which have scroll so you can run `emerge -ca' and scroll to view the results. I run urxvt in i3 (not sure whether it scrolls or not), and I always run emerge inside of a tmux and use tmux's scroll to view all the output before making a decision, so you could also use tmux or screen. Hope this helps, Alec
Re: [gentoo-user] emerge --sync keeps failing
On Tuesday, 3 August 2021 11:49:23 BST Neil Bothwick wrote: > On Tue, 03 Aug 2021 09:55:46 +0100, Michael wrote: > > Anyhow, I recall using git to sync a live ebuild - from some repo > > and portage started downloading gigabytes of cruft. Presumably whole > > decades of old commits I didn't need or have space for. I subsequently > > discovered I had to set "EGIT_CLONE_TYPE=shallow" in make.conf, but I > > can't find this variable in the man page now. I suppose/hope portage > > using git will only download more recent commits? > > It does, you get just the current state of the tree by default, it's just > orders of magnitude faster, even compared with using rsync with a local > mirror. And I don't have to worry abut syncing too often and upsetting > infra as I'm syncing from github. I see, thanks Neil. Does it now check sigs of downloaded data, like rsync does? signature.asc Description: This is a digitally signed message part.
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] emerge --sync keeps failing
On Tue, 03 Aug 2021 09:55:46 +0100, Michael wrote: > Anyhow, I recall using git to sync a live ebuild - from some repo > and portage started downloading gigabytes of cruft. Presumably whole > decades of old commits I didn't need or have space for. I subsequently > discovered I had to set "EGIT_CLONE_TYPE=shallow" in make.conf, but I > can't find this variable in the man page now. I suppose/hope portage > using git will only download more recent commits? It does, you get just the current state of the tree by default, it's just orders of magnitude faster, even compared with using rsync with a local mirror. And I don't have to worry abut syncing too often and upsetting infra as I'm syncing from github. -- Neil Bothwick Talk is cheap because supply exceeds demand. pgpeCI718v3Nf.pgp Description: OpenPGP digital signature
Re: [gentoo-user] emerge --sync keeps failing
On Tuesday, 3 August 2021 02:28:09 BST John Covici wrote: > On Mon, 02 Aug 2021 18:42:29 -0400, > > Michael wrote: > > > > On Monday, 2 August 2021 22:17:35 BST Neil Bothwick wrote: > > > On Mon, 02 Aug 2021 13:01:40 +0100, Michael wrote: > > > > > I have this problem every month. Why does it fail? Is it just a > > > > > timeout because my network is slow? Can that be tweaked? > > > > > > > > I get this problem over here, but on rare occasions. Leaving it for > > > > half a day usually fixes it. Have you tried a different rsync mirror? > > > > You can use 'mirrorselect -i -r' for this task. > > > > > > I used to see this from time to time, but then I switched to using git > > > instead of rsync and haven't seen it again. There's the added bonus that > > > syncing is MUCH faster too. > > > > Last time I looked at git for portage it was not not using gpg to verify > > the downloaded data - has this feature been added since then? > > I don't know when you last looked, but I see it checking the signature > when downloading from git. It was some inordinate time ago - can't recall when exactly. It was after portage started using gpg with rsync and quarantined any fetched files after they were downloaded until their signatures were validated. As I understood at the time the difference with using git was it would only check the top commit in the repository had a valid signature, but not what eventually landed at the local PC. Also, even to do this check it required you have enabled "sync-git-verify-commit-signature = yes" - but according to 'man portage' it defaults to "no". Anyhow, I recall using git to sync a live ebuild - from some repo and portage started downloading gigabytes of cruft. Presumably whole decades of old commits I didn't need or have space for. I subsequently discovered I had to set "EGIT_CLONE_TYPE=shallow" in make.conf, but I can't find this variable in the man page now. I suppose/hope portage using git will only download more recent commits? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)
Am Tue, Aug 03, 2021 at 07:10:03AM +0800 schrieb William Kenworthy: > >> Keep in mind that both repos have the same ID - you should also rsync > >> the cache and security directories as well as they are now out of sync > >> (hence the warning). > > That thought crossed my mind recently but I was unsure how to store the > > cache. But since the repo is a monolith, it should suffice to rsync > > the whole cache directory to the backup drive (or do it as a tar). > > > > The only problem is the temporal sequence: > > 1. Host A runs borg and gets a current cache. > > 2. Host B runs borg on the same repo and gets a current cache. > > 2a. Host A now has an outdated cache. > > > > Usually, Host B uses Host A via ssh as remote location of the repository. > > So I could simply run a borg command on Host A to update the cache somehow. > > > >> Be very careful on how you do this - you are one step away from losing the > >> while repo if the cache gets out of sync. The docs warn against rsyncing > >> two repos and then using them at the same time for a good reason. > > I won’t use them at the same time. It will always be one direction: > > Hosts --[borg]--> Main backup drive --[rsync]--> secondary backup drive > > > You could delete and rebuild the cache each time (or I think there is a > way to do without it). If the cache can be easily rebuilt, then there’d be no need to store it at all. At least that’s what I hoped, but was shown otherwise; I deleted the whole cache, wanting to clean it up from cruft, and then the next run took hours due to complete re-hash. > There are quite a few threads on the borg lists about this in the past > (usually people trying to recover trashed repos) I’ll give them a read in a quiet hour. > - you might ask there if there is a way to deal with changing the ID now? Why would I need to change the ID? As already explained, I will only ever borg to the primary backup disk and mirror that to another disk with rsync. And when the primary fails, I use the secondary as drop-in replacement. -- Grüße | Greetings | Qapla’ Please do not share anything from, with or about me on any social network. Sometimes the fingers are faster then grammar. signature.asc Description: PGP 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] emerging package with rR?
On 8/3/21 7:13 AM, n952162 wrote: Hello, can someone explain why rR? [ebuild rR ] virtual/perl-Pod-Parser-1.630.0-r8::gentoo 0 KiB Why would this be happening? r reinstall (forced for some reason, possibly due to slot or sub-slot) R replacing (remerging same version) I had 181 packages to install. It completed, but with one restart, so I re-ran the emerge to make sure everything was done: + emerge --getbinpkg n -v --tree --deep --update --noreplace --changed-use --binpkg-changed-deps=n --binpkg-respect-use=n --verbose-conflicts --keep-going --with-bdeps=y --backtrack=100 @world Now there's 177 packages to install (no --sync in between). Most ar rR. Okay, it seems to have at least gone fast, without rebuilds.
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.
