[gentoo-user] Re: Portage detects fake "world file problems" and packages that don't exist
On 08/01/2022 22:44, Nikos Chantziaras wrote: This is weird. When doing: emerge -auDU @world Portage says: !!! Problems have been detected with your world file !!! Please run emaint --check world !!! Ebuilds for the following packages are either all !!! masked or don't exist: media-sound/pavucontrol media-sound/pulseeffects sys-block/gparted Nothing to merge; quitting. It was a bug and it's fixed now: https://bugs.gentoo.org/830881
Re: [gentoo-user] How to degrade Gentoo system with webrsync method?
On 2022-01-09 05:13, gevisz wrote: Yes, masking some new package can work in this case. However, it is not so easy as it may seem because it is not the new version of tensorflow that I should mask in my case as on the day when the tensorflow recompilation failed its version remained the same and only some of its dependencies were supposed to be upgraded. Of course, I may try this approach. However, tensorflow is not considered stable in gentoo tree and it has a lot of dependencies that are also not considered stable and should be unmasked. All this leads to a large number of possible choices on which packages to mask/unmask. So, playing with this is like playing in a casino with about 4 hours of compilation for each bet. So you know the date it last compiled and run successfully? If it was me, I'd build a manual list of dependencies (like Dale indicated), then install genlop and run `genlop -t` for each of the dependencies and the main package. It will tell you the versions that were built, and more importantly, the *date* they were built. You should be able to deduce what package versions were working with each other, but then the hard part: trying to figure out if those versions are still available. `eshowkw ` will tell you what's available in the tree, but if it isn't available, then it gets way harder as you have to try to find the old ebuilds with sources and possibly set up a local repo and pray those packages don't affect other installed packages. Dan
Re: [gentoo-user] Re: tensorflow-2.5.0-r1 compilation failed
> > Thank you for your reply, Mark. > > Unfortunately, you missed my previous message in this thread > where I wrote that I do have Ubuntu 20.04 on the same computer. > However, tensorflow fails to run on it because it is not compiled > to be inconsistent with my videocard. So, Gentoo is my only option > for this hardware. > My apologies. This thread has gone on for a while and I had to review to get caught up. OK, so assuming I understand correctly (please correct me if I do not) then you are talking about ONE computer that uses an AMD Phenom II X4 processor. This computer dual boots, or is a Gentoo machine with an Ubuntu VM. In an earlier response to this thread you showed the flags supported by this processor which did not include the AVX, AVX2 or the FMA3/FMA4 flags. It is my understanding that this processor cannot run the current versions of tensorflow whether you compile it yourself or not, at least in the non-GPU version. WRT to your video card, tensorflow does not require the use of a GPU. There are two versions, tensorflow-cpu and tensorflow-gpu. If you were to build the -cpu version then it is my understanding it would run an a headless machine, presuming the processor has AVX/AVX2/FMA hardware support. If the processor DOES have AVX/FMA support but you were having problems emerging TF in Gentoo then a virtual machine running Ubuntu might have helped you as you could use a precompiled apt or snap package. However I don't think anything gets you past not having AVX/FMA hardware support. I am in the same situation. My big machine is an Intel i7 980 Extreme. I used to be able to run TF but have not been able to since Google raised the CPU requirements. If I am not understanding your hardware setup, or you think there is a path around the AVX/FMA hardware problem please let me know and I'll explore it more deeply with you. Cheers, Mark
Re: [gentoo-user] Re: tensorflow-2.5.0-r1 compilation failed
On 09/01/2022 23:29, gevisz wrote: Unfortunately, you missed my previous message in this thread where I wrote that I do have Ubuntu 20.04 on the same computer. However, tensorflow fails to run on it because it is not compiled to be inconsistent with my videocard. So, Gentoo is my only option for this hardware. Can't you download the Ubuntu version and compile it for your video card there? There should be somewhere you can just download the same version they've built and tweak it for your hardware? Cheers, Wol
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
On Mon, 10 Jan 2022 at 12:28, Arve Barsnes wrote: > > On Mon, 10 Jan 2022 at 11:33, Dale wrote: > > I read in a bug report that this is fixed in a overlay. Makes me wonder > > why this has been going on for a month or so without a 'in tree' fix. > > I'd rather not add a overlay but if it is the only fix, may have too. > > An alternative to adding the whole overlay (and the poly-c overlay is > quite big) is to just copy the ebuild you want to your local overlay. > It looks like poly is involved in the maintenance of this package > normally, so I'm not sure why this is not in the main repo yet, if > there is something weird being worked on. > > The biggest change if you copy it locally, is that you get the latest > released version of seamonkey, and the rust dependency in the ebuild > has been updated to: > > >=virtual/rust-1.34.0 > > That seems to indicate that the current requirement of <1.53 was never > correct? > > Either way, worth a try if you ask me, you're on a newer version, the > rust conflict with firefox will not come up again, and hopefully > eventually, the main gentoo repo will get even newer versions so > you'll get automatically updated without having added a full extra > overlay. Also, the ebuild to copy: https://www.gentoofan.org/gentoo/poly-c_overlay/www-client/seamonkey/seamonkey-2.53.10.2-r2.ebuild Cheers, Arve
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
On Mon, 10 Jan 2022 at 11:33, Dale wrote: > I read in a bug report that this is fixed in a overlay. Makes me wonder > why this has been going on for a month or so without a 'in tree' fix. > I'd rather not add a overlay but if it is the only fix, may have too. An alternative to adding the whole overlay (and the poly-c overlay is quite big) is to just copy the ebuild you want to your local overlay. It looks like poly is involved in the maintenance of this package normally, so I'm not sure why this is not in the main repo yet, if there is something weird being worked on. The biggest change if you copy it locally, is that you get the latest released version of seamonkey, and the rust dependency in the ebuild has been updated to: >=virtual/rust-1.34.0 That seems to indicate that the current requirement of <1.53 was never correct? Either way, worth a try if you ask me, you're on a newer version, the rust conflict with firefox will not come up again, and hopefully eventually, the main gentoo repo will get even newer versions so you'll get automatically updated without having added a full extra overlay. Regards, Arve
Re: [gentoo-user] What is the difference between emerge's --changed-deps=y and @changed-deps?
On 2022-01-10 07:44, Lee K wrote: On Mon, Jan 10, 2022 at 01:59:13AM +0100, Morgan Wesström wrote: Can someone please elaborate on what's going on here, what the difference is between --changed-deps=y and @changed-deps, if that difference is intended and what the recommended update procedure is these days to catch these and other kinds of inconsistencies in Portage? Don't know if it's relevant or not but recently upstream deprecated the "KERNEL" USE flag, resulting in many rebuilds for packages. Thank you, Lee, but that was just a coincidental change. The changed-deps behaviour has been going on since I've started using it in my update routine several years ago. It's a little tiresome when emerge wants to recompile libreoffice and firefox every time I update my system and I'd like to understand in more detail what these parameters do so I can judge the necessity of using them to keep my installation in a consistent state. Regards Morgan
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
Arve Barsnes wrote: > On Mon, 10 Jan 2022 at 08:50, Dale wrote: >> Howdy, >> >> I've been dealing with this for a while. When I do my updates, it >> either omits seamonkey because the rust version installed is to new or >> downgrades rust. I keyworded rust to see if emerge could sort it out >> itself but Seamonkey then complains about the newer version of rust. >> >> I've read some stories about rust and such but this is annoying. Is >> there not a way to make both packages happy? For once, I'd like to be >> able to update and get a clean outcome. Heck, at this point, I'm a bit >> confused. I've went around in circles so much, I feel like a >> professional drunk. :/ >> >> Thoughts? > I would try to remove this dependency in an overlay. I noticed the > release notes for seamonkey 2.53.10.2 mentions fixing something about > rust-1.57, and no mention of rust in any of the versions between the > latest in portage and that one, so I question if there is actually a > dependency on an older rust here. > > Regards, > Arve I read in a bug report that this is fixed in a overlay. Makes me wonder why this has been going on for a month or so without a 'in tree' fix. I'd rather not add a overlay but if it is the only fix, may have too. I might add, Seamonkey and Firefox seem to work fine with both versions of rust. The biggest problem is when both Seamonkey and Firefox want to upgrade at the same time. That creates a major clash. Usually, I upgrade Seamonkey first, let it downgrade rust, then upgrade Firefox which pulls in the newer rust. Both seems happy until I do my weekly updates again. If no one else comes up with a better solution, I may try the overlay. I think it is poly.c or something. Thanks. Dale :-) :-)
Re: [gentoo-user] What is the difference between emerge's --changed-deps=y and @changed-deps?
Am 10.01.22 um 01:59 schrieb Morgan Wesström: On a freshly updated system (emerge -uDN @world): "emerge @changed-deps" wants to reinstall 0 packages. "emerge -u --changed-deps=y" wants to reinstall 24 packages. "emerge -uD --changed-deps=y" wants to reinstall 181 packages. A couple of years ago there was a build breakage in Portage because, as I understood it at the time, some developer changed the dependencies in an existing ebuild without bumping its revision level. The solution was to use --changed-deps=y to catch these occurrences and I've been using it in my regular update routine since then. But as you can see in the third example above, it usually wants to reinstall hundreds of packages that doesn't have any updated versions and I'm wondering if this is working as intended. I have a hard time believing that gentoo devs are pushing changes to existing ebuilds in such numbers on a regular basis without bumping the revision level. Some time ago I became aware that Portage now has a @changed-deps set, which I assumed was accomplishing the same thing, but it doesn't produce the same result as --changed-deps=y - usually just a dozen reinstalls or so. Can someone please elaborate on what's going on here, what the difference is between --changed-deps=y and @changed-deps, if that difference is intended and what the recommended update procedure is these days to catch these and other kinds of inconsistencies in Portage? Regards Morgan On my system most of this is related to build time dependencies. #emerge -Duav --reinstall changed-use --changed-deps=y --with-bdeps=n @world Total: 10 packages (10 reinstalls) #emerge -Duav --reinstall changed-use --changed-deps=y --with-bdeps=y @world Total: 131 packages (131 reinstalls)
Re: [gentoo-user] What is the difference between emerge's --changed-deps=y and @changed-deps?
Am 10.01.22 um 07:44 schrieb Lee K: On Mon, Jan 10, 2022 at 01:59:13AM +0100, Morgan Wesström wrote: On a freshly updated system (emerge -uDN @world): "emerge @changed-deps" wants to reinstall 0 packages. "emerge -u --changed-deps=y" wants to reinstall 24 packages. "emerge -uD --changed-deps=y" wants to reinstall 181 packages. A couple of years ago there was a build breakage in Portage because, as I understood it at the time, some developer changed the dependencies in an existing ebuild without bumping its revision level. The solution was to use --changed-deps=y to catch these occurrences and I've been using it in my regular update routine since then. But as you can see in the third example above, it usually wants to reinstall hundreds of packages that doesn't have any updated versions and I'm wondering if this is working as intended. I have a hard time believing that gentoo devs are pushing changes to existing ebuilds in such numbers on a regular basis without bumping the revision level. Some time ago I became aware that Portage now has a @changed-deps set, which I assumed was accomplishing the same thing, but it doesn't produce the same result as --changed-deps=y - usually just a dozen reinstalls or so. Can someone please elaborate on what's going on here, what the difference is between --changed-deps=y and @changed-deps, if that difference is intended and what the recommended update procedure is these days to catch these and other kinds of inconsistencies in Portage? Regards Morgan Don't know if it's relevant or not but recently upstream deprecated the "KERNEL" USE flag, resulting in many rebuilds for packages. I don't think so. "N" should have taken care of this. from the man: --newuse, -N Tells emerge to include installed packages where USE flags have changed since compilation. [...]
Re: [gentoo-user] Seamonkey and Firefox clash over rust version.
On Mon, 10 Jan 2022 at 08:50, Dale wrote: > > Howdy, > > I've been dealing with this for a while. When I do my updates, it > either omits seamonkey because the rust version installed is to new or > downgrades rust. I keyworded rust to see if emerge could sort it out > itself but Seamonkey then complains about the newer version of rust. > > I've read some stories about rust and such but this is annoying. Is > there not a way to make both packages happy? For once, I'd like to be > able to update and get a clean outcome. Heck, at this point, I'm a bit > confused. I've went around in circles so much, I feel like a > professional drunk. :/ > > Thoughts? I would try to remove this dependency in an overlay. I noticed the release notes for seamonkey 2.53.10.2 mentions fixing something about rust-1.57, and no mention of rust in any of the versions between the latest in portage and that one, so I question if there is actually a dependency on an older rust here. Regards, Arve
