Description of problem: Dependency hell: see Summary. Version-Release number of selected component (if applicable): How reproducible: Trying to install the latest Crossover, it can't install pygtk2.0, then the license app won't run. This could be because Mageia no longer supports python 2, but the package is available. python2dist(numpy) is not. Crossover still requires i586 libraries. Mageia 7 has problems for Crossover as well. I could try to recompile Crossover. Steps to Reproduce: 1. 2. 3.
Crossover is not (I think) our territory, but pygtk2.0-2.24.0-14.mga7 is. I cannot find its Python3 equivalent. Is this really our responsibility? Assigning to Python stack maintainers.
Assignee: bugsquad => python
Good question. Apparently the latest Fedora has python 3 only; no python2 at all. I thought that Mageia had gone the same way. When early Mageia wouldn't run VirtualBox because python 2 had been dropped, the official answer was the same: if the distro doesn't support VB, you will have to do without it. I (and no doubt others,) installed the obsoleted python libraries without any conflicts, and got VB running. I thought that the team's view that a reasonably new distro can tell VB that compatibility was not the distro's problem was a bit conceited. Other distros took the opposite view. Members wanted a mailing list, and were told they had the forum, so those on the Mandriva newsgroup started a Mageia newsgroup. In the early days, resources were stretched and I was patient, but things should be a bit better now. I installed Crossover on Mint with no problems, then copied the license files across to Cauldron, to get it working. It still won't run on Mageia 7, saying that Crossover and others depend on libraries that are older than the installed ones. Steam (another third party program) has issues as well. One regular on the Mageia newsgroup has already moved to Mint, and others are running PCLinuxOS. It is beginning to look as though I should follow him, after about 15 years with Mandrake/Mandriva/Mageia. Mint isn't as customizable, but it works! Crossover should move to 64-bit, but their forum says it would be difficult. The developers of Skype say the same.
in mageia 7 python2 packages are still present, we have started to drop all python2 packages in Cauldron so for future mga8. And as pygtk2 is only python2 yes this one will be dropped. Also VB was ported to python3 in Cauldron.
CC: (none) => geiger.david68210
OK, but my problem is with Crossover Office. Maybe the issue is suimply one of tghe title of the package. python2dist(numpy) doesn't sound like a Mageia RPM. Installed on 7 I have: python2-numpy-1.16.2-1.mga7 python3-numpy-1.16.2-1.mga7 The Debian package for Crossover contains a .spec file. Editing that may be all I need.
I wasn't thinking straight. The error is in the gtk2.0 package. What I am being told is that gtk2.0 needs python2dist(numpy), but the package that exists is called python2-numpy, so there is no match.
Sorry, another senior moment. Crossover needs pygtk2.0 Pygtk2.0 calls python2dist(numpy) There is no package called python2dist(numpy) The dependency in pygtk2.0 is incorrect. Crossover just happened to be the occasion for the conflict to show up.
(In reply to Doug Laidlaw from comment #5) > I wasn't thinking straight. The error is in the gtk2.0 package. What I am > being told is that gtk2.0 needs python2dist(numpy), but the package that > exists is called python2-numpy, so there is no match. Yes there is: urpmf --provides --literal 'python2dist(numpy)' python2-numpy:python2dist(numpy)[== 1.16.2]
CC: (none) => tmb
So, it should all work. The 64-bit packages are in fact, installed. But Crossover wants 32-bit, and there is no 32-bit version of pygtk2.0 showing, only its "devel" packages. To be sure, I rebuilt my RPM database. This raised a distinct error: the command "sudo rpm --rebuilddb" can't delete the old database; I need to do it manually. Should I start a separate bug for that?
I tried to install the 32-bit package from PCLinuxOS, but it is Series 2, and killed everything. It would be unfair, and wrong, to suggest that this bug is an example of the view expressed on DistroWatch, that Mageia is a case of the proverb "An elephant is a mouse built by a committee." The basic problem in this bug has been with us from the earliest days of Linux: "An error message will tell you that you have a problem, but believe at your peril its description of what the problem is." The error message said that I had a dependency problem. What the problem really was, was the missing 32-bit pygtk2.0 package. And that wasted everybody's time here.
pygtk2.0 was dropped from Cauldron repo as all python2 packages! if you need pygtk2.0 you have to use mageia7 the stable release one.
But I AM using Mageia 7 The repo is incomplete. Something else required gcc-c++ whic hasn't in the repo either. I looked for all the variations of the name. "g++" shows as a dependency, but the package is called something like "gcc-c++", as I have found out from 15 years' experience. It didn't exist, by any name. pygtk-2.0 exists for x86-6, but not for i586. It seems that there is more to rewriting apps for 64-bit than simply changing the dependency. Crossover and Skype both say so, although Skype's support for Linux is fairly nominal. You know a lot more about that, than I do. Like Windows, there seems to be a lot more work being put into "bells and whistles" than into making the basic system work. The list of packages to support third-party functions, such as home automation, is really amazing, but there is no 32-bit pygtk2.0. I am not the best person to argue these points. I get frustrated easily. My wife has just almost recovered from a leg injury, and left me with a back injury from trying to lift her. In addition, I have two kinds of depression, one inherited, the other one age-related. Probably, I see Mageia as the "best" distro because it is the only one I know, but objectively, I have found important deficiencies in every other distro I have tried. If the management want to destroy Mageia, go right ahead. For a while, at least, I will follow the exodus I mentioned in Comment 2.
the package is called something like "gcc-c++" or "gcc-cpp." I tried them all.
There is a 32bit pygtk2.0 in mageia7 repo: http://madb.mageia.org/package/show/application/0/name/pygtk2.0
Yes, I know. For some reason, the call from crossover didn't find it, so I installed it separately. I wasn't aware that "Provides" is so versatile, as tmp pointed out, but I would have expected it not to work differently when called by Crossover. That probably concludes this bug report. If the message had been more accurate, I would have solved the problem a lot sooner, but that is Linux, not Mageia. Crossover stills needs several packages obsoleted in Mageia by new ones. Steam does as well. Neither will run under Mga 7. Later releases of each should fix their problems.
Created attachment 11319 [details] Screenshot of excerpt from rpmdrake. Sorry again, Yes, it shows in the AppDB, but not in rpmdrake, which includes i586 (see screenshot.)
Just checked. I hadn't enabled i586 Core, but enasbling it made no difference, pygtk2.0 does not appear in the Cauldron Release repo on ibiblio (7 is taking just as long to load,) but is there in the 7 repo. Trying to install it from the command line gives: "unable to access rpm file [pygtk2.0-2.24.0-14.mga7.i586.rpm] error registering local packages"
To me that is a cryptic message stating two errors at the same time... Did you try to download the rpm first?
CC: (none) => fri
I got that message in response to the command: "sudo urpmi pygtk2.0-2.24.0-14.mga7.i586.rpm." I thought that it might mean that I had the graphical MCC or rpmdrake running. but neither was running. If rpmdrake is up but doing nothing, the database is released, and urpmi can run as usual. The other thing that is weird is that twice, the commands: sudo rm -f /var/lib/rpm/_* sudo rpm --rebuilddb have failed with a message that there was insufficient permission to remove the old database. That has never happened before. I can remove the old database with the command "sudo rm <database name>," so the permission problem is somewhere in the distro's action. Can I quote anything that might help? This report is a bit like an onion; remove one layer, and another shows.
Created attachment 11320 [details] Output of strace. The only diagnostic command I know of is strace. I can't read its output, but here is the output of strace rm -f /var/lib/rpm/_ I see a reference to an "Illegal seek."
CC:ing Mageia tools group for that rpm issue
CC: (none) => mageiatools
Now i really read what you wrote - it seem to be on filesystem level! You should do a file system check.
I was thinking the same. Another one just popped up. I received a suspicious email, so I installed clamav. This was the result: (and now my browser has gone full-screen and I have no window chooser!) something is very wrong. I think that a search for viruses is also required.)
I did a complete reinstall of Mageia, from a USB stick of 7.1 this time. fsck showed nothing, and there were no viruses, either. Comparison: pygtk2.0 for 32-bit is still not showing in rpmdrake. I selected it on my usual mirror and ran "install" from the right-click menu. Doing it that way, the situation in Comment 16 didn't arise. That allowed crossover and steam to be installed and run normally. "rm -f /var/lib/rpm/_* rpm --rebuilddb" run as root, is still unable to remove the old database, which is owned by user and group rpm. That seems to be the only other ongoing problem, and it would happen pretty rarely.
This is a PICNIC error. I had been enabling 32-bit Updates, but not 32-bit Release. As soon as I enabled the Release, the problem went away.
Status: NEW => RESOLVEDResolution: (none) => INVALID