Hello,
Lx4 ZNVER1 / ROCK (updated)
PLASMA5
IMPOSSIBLE TO INSTALL “GOOGLE EARTH PRO”.
Thanks
it worked for me
in root console
[ruru@omlx4-rolling Downloads]$ su
Password:
[root@omlx4-rolling Downloads]# rpm -ivh --nodeps google-earth-pro-stable-current.x86_64.rpm
Merci zuzu21,
Effectivement, ça passe comme ça !
A tout hasard, c’est quoi la correspondance --nodeps pour ce foutu DNF ?
Thanks for reporting @D27 and the reply @zuzu21.
I don’t think there is a dnf equivalent for ‘rpm --nodeps’ or ‘rpm --force’. I believe that is by design. Installing that way should mean that some dependency is not being installed but if google earth or whatever software you want works that way then I call it good.
What I do know is that right now because of it’s newness and limited testing there will be more packages in znver1 with dependency issues. So we do appreciate all the reports we get.
Speculation by me: I suspect that 3rd party rpms like Google earth pro are not accepting the .znver1 on dependencies. And I don’t know what @bero and other developers have planned for how to deal with this if I am correct.
Post-edit: FWIW: it is also possible I’m wrong. Especially in any of the parts purposely labeled speculation.
Hi.
Please create bug report at issues.openmandriva.org to follow this thread in a more appropriate place. I’ll see what I can do about it. I suspect that this can be done in a way that we managed to install proprietary browsers (chrome, opera, vivaldi and etc) after Google introduced a new dependency (based on the nomenclature from Redhat - if I good remember)
I’m not sure, but I think we will be able to solve this problem.
Hi,
Yes it works 100/100 that way …proving (if necessary) DNF is not as efficient as URPMI!
This last affirmation of mine is not a simple opinion but a fact! I have been struggling with DNF so many hours, I finished abandoning LX4!
My error was to try to install “pysolFC” when only “pysolFC-carsets” is present in the repos.
Following this error, the stupid DNF system refused to work as it is supposed to => No more repos kept in memory-config - No more updates - Permanent message on "pysolFC even after uninstalling the “pysolFC-cardsets” package - No response to some basics commands - etc…
To-day I still have an error reading: “systemd doesn’t exists”(???) every time I use DNF. …And I don’t mention the quasi useless of “dnfdragora” along this period, and “of course”, the fact that “dnfdragora-updater” never worked on my PC.
In the present case, I don’t think the “znver1” repo is (only) questionable.
“GoogleEarthPro” (or not “Pro” previously) has always (for years) needed this “mesa-libGLU” on whatever distribution, since the passage in 64 bits. The problem here, is that another lib “lib64glu1-9.0.0-20.znver1” is conflicting => but I am quite sure if you don’t use “znver1” version repos you will have the same issue.
Try it, yourself.
Beyond all these problems of DNF and incomplete repos, I must admit LX4 ZNVER1 works perfectly here (processor Ryzen5 2400GE with integrated graphic).
After having abandoned it for some time, I note that => for 4 days now using it, I have no “system freezes” when watching streaming fluxes, like happening with other distros I also use.
It has come through my mind -but I need more time to be absolutely certain- that this znver1 version, especially conceived for Ryzen processors, accepts much better the free “amdgpu” driver. A part from no more freezes during the long streamings, I noticed the proc temperature is lower than “ordinaries” (not specially conceived for Ryzen processors) other distros during the above-cited streamings.
I think it will be encouraging for the devs to know about it.
As I said here above, the “problem” of Google Earth and the cited lib is an old story (seems “zuzu21” was also aware of it). Now, if there is a conflict with “lib64glu1-9.0.0-20.znver1” (“znver1” or not) I will not be able to say more, but I don’t use any of the browsers you mentioned (Firefox here since it exists).
What is to note, is that the soft (GoogleEarthPro) perfectly works => independently of the notion of new politics of Google, respecting dependencies based on Red Hat nomenclature, you mentionned.
Thanks
Yes, this problem was on all architectures. It was because I just fixed it.
For 4.0 I just backport simple fix with adding two new virtual provides to satisfy dependencies for Google Earth. Package in testing repo, so to test it you need enable main/testing reopository first.
For Cooker and Rolling im also update libglu to 9.0.1.
It fix issue for me here on cooker. So let me know, if all working fine now.
Sorry but in dnfdragora => all of my repos are znver1 (or 686), and I am absolutely unable to change that!
I tried to mark all cooker, rock, testing, and rolling repos (all “znver1” remember), but no lib64glu1 appears in 9.0.1 version.
I suppose some DNF commands should be able to install other repos (non znver1) but this system is far beyond my understanding, and I don’t want to be newly stuck during months at the faintest error.
Anyone not znver1 can test your new lib.
Thanks anyway
For 4.0 and rolling you need enable testing repo. This package is in testing. So first enable testing and then update system. And for 4.0 glu is in 9.0.0-21
9.0.1-1 is for Rolling and Cooker.
This should be fixed for all supprted archs x86_64, i686, znver1 and arm.
Sorry if I didn’t make myself clear enough, but your “testing” repo => is not existing on my znver1 system, and there is no way, in graphic, to install it!
All “testing-something” repos existing here, are “ZNVER1” version, AND YOUR LIB IS NOT PRESENT ON NONE OF THEM!
Concerning Konsole commands in DNF to install the NORMAL testing repo you speak of, I simply refuse to do that.
Thanks again.
@AngryPenguin many thanks for fixing this.
I believe these are the packages @AngryPenguin is referring you to.
Edit: And OM developers went to considerable effort to do this (thanks @bero):
That is pretty graphical. And I’ll grant that the OM-Repo-Picker is still very new I can verify that for me on x86_64 systems it works just fine. If for some reason it isn’t working in znver1 we’ll certainly want to fix that.
OpenMandriva repos by default are using a mirror list so it can take some time before new packages get to what ever mirror you system is using. That is usually from a few hours to a day.
I know but…
In “my” “Repository Picker” all the repos (Release, Rock, Rolling, Cooker) except “Testing” are marked, but in “dnfdragora” (File/Repos) you can mark or unmark any repo (and then “Apply”)! So what is the use of the “Picker”?
At the moment (trying to help) I have 30 repos marked in dnfdragora => and no 9.0.1 version in the horizon!
I have no “main/testing” repo nowhere!
…Of course if I go through Firefox, I suppose I will find the list you present above, but I cannot get the new lib with dnfdragora …As I said this system is beyond my IQ!
Before you do anything else please read this. The most important thing to get from that is that you do not mix releases. So between release, rock, rolling, and cooker pick one and use only that one always. I’m hoping that you only did this looking for that package, if so no harm done. But whatever your system was using before you should stick to that.
Next I’ll post what I find in dnfdragora.
OK, I’m in a Rock system (x86_64). I open dnfdragora and select the main/testing repo for Rock x86_64.
Notice I left “To Update” selected in dnfdragora:
And the lib64glu package is there ready to install:
So if this is for some reason not working in a znver1 system we really need to know so we can get someone to look in to the problem. But here it is working. And I have verified that I can select testing repos in both Rock and Rolling systems with dnfdragora.
In dnfdragora if you enable a given repo like I did above for the Rock main/testing repo that is only valid for that session and that repo will disable automatically when dnfdragora closes. So the ‘Repositories’ tool in dnfdragora is not a repo manager it only enables repos for one session. That is different from the old rpmdrake. But handy for users like in this situation looking to test one or a few packages for a given purpose like in this thread.
The ‘Software Repository Selector’ aka om-repo-picker edits the .repo file in ‘/etc/yum.repos.d’ and when that file is edited then everything system wide is using what is enabled there. That includes dnfdragora and command line.
There is more explanation of this in the OM-Wiki and the Resources section of this forum. And this is definitely an area where OM needs to improve.
Hi,
At first, I want to present my apologies for the time Ben and Angry Pinguin wasted for me.
And say that, after the whole afternoon trying to understand how DNF, dnfdragora, dnfdragora-updater and the repo-picker work, I made a lot of progresses …but remain stuck by errors, in most of the cases.
I think that, when installing LX4 months ago, I have mixed some cooker packages and Rock ones => BECAUSE THE REPOS ARE INCOMPLETE (no way to install “pysolFC”, or "Gkrellm-plugins/themes, some codecs, and more others I don’t remember), and as a consequence, some errors are blocking the update and remove processes.
I have taken the decision to format and re-install, and, when softs I need will not install by fail of dependencies, inform here.
Then, I want to say I switched my version (from Rock) to rolling to be able to load the lib Angry Pinguin has just updated about Google Earth (remember it was impossible for me to locate the lib on Rock-testing), => and, after uninstalling Google Earth and loading the new lib, could re-install Google Earth successfully.
I underline that no lib was required for this new installation (the sole Google-Earth package was installed), probably because the new lib was already installed… Don’t know.
I owed you these final explanations, and hope you will understand, the way Openmandriva has decided to replace URPMI is not really easy to manage …especially when a simple user cannot install what he was used to …because of the MESS in the repos.
Thank you
