I just installed Debian testing x86_64 on a new machine, and installed current (331.38) Nvidia driver with sgfxi.

It placed 32 bit libraries such as libGL.so in /usr/lib32

Then I installed wine and wine32 (as well as playonlinux which installs local wine versions).

After running some games they complained however, that they load a wrong library:



For some reason on another machine with Debian testing (which was gradually used since even before wheezy times and transitioned from ia32 to multiarch) with current updates from sgfxi everything works just fine.

Do you have any clue what am I missing? Some i386 packages may be?
Back to top

No, I have no clue, if your system is working and the nvidia glx libs installed, and if issues only occur on wine, I have no idea, I don't use or like wine, haven't for years, I found it to always be buggy in terms of actually working to run windows apps.

If standard functionality is present on everything but wine, or even more specfically, on specific games running in wine, then I can't help, that's not really a general problem, if functionality is missing and it can be fixed by installing a package, then let me know what it is and I can add that to sgfxi, but only if it applies to all video functionality, not wine specific that is.
Back to top

I'll try to investigate more, but I noticed that sgfxi proposes to install ia32-libs-i386 for better support of 32 bit games on an x86_64 system. This option however is obsolete on the current Debian testing (since such package doesn't even exist anymore). In the past that packages provided a common set of i386 libraries, and I guess that my older system had them and that was migrated to multiarch. The new one probably misses a bunch, but there is no one metapackage like that anymore, so I have to figure out what's missing.
Back to top

That should not be gone, this was recently updated.

sgfxi offers to install ia32 libs at start for 64 bit nvidia. You should have instlaled those, with the 'i' text on startup, it asks you. If you didn't install that, then you would be missing some functionality. If you didn't see that option, it means you already have them installed, which means this is not related to your issue.

We spent a long time recently updating that and getting it solid, took a fair amount of debugging etc, so I don't think that's deprecated.

There was an old nvidia glx thing but that's been removed from sgfxi for a long time, that was installed post driver install, as an option, but that's been gone a long time.
Back to top

I tried that option, but it can't find the package, since that package actually doesn't exist anywhere besides stable (Wheezy), while I'm working with testing. I think in the next release it won't be present (so accordingly it's missing in testing and Sid).

See packages.debian.org/search?keywords=ia32-libs-i386&searchon=names&suite=all&section=all and note that it's gone in testing and Sid.

So, the practical question is, which packages one needs to pull on an x86_64 testing and Sid to support 32 bit Wine with OpenGL for example? That's what I'm trying to figure out. In the past ia32-libs-i386 helped for that.

sgfxi provides 32 bit Nvidia driver as I wrote above, but something is still missing in the system.

I'll simply make a diff between i386 packages installed on both systems, and will install the missing set on a new one to check if that helps.
Back to top

If that's true, this is extremely annoying, and slightly worrying. The methods sgfxi use for this were totally current only about 6 months ago, and were based on all current documentation on this issue.

For debian to have changed this so profoundly in that short a time is more than worrying to me, it means I cannot trust them to maintain core methods in a consistent manner, which makes 64 bit support even more of a pain than it should be.
Back to top

this is annoying, to an extreme. Not only was this convenient meta package dropped, it was NOT REPLACED!!

So the web is filled with all these references to it then noting it's a transitional package, but not transitioning to anything else, just to multiarch. And no documentation tells you what packages you need to install to replace it. This is a really bad case of fast change with no documentation, and very little forethought, a very bad sign, reeks in my opinion of ubuntu/ canonical devs, who are known for this type of thing.

And this leaves a gaping hole in the knowledge base.

I have no idea which package that ia32-libs metapackage pulled in are required, apparently now all of them have to be installed one by one. As things go, this is pretty lame, and very weak in terms of providing actually usable documentation and options on Debian's part.

I am very disappointed in debian, to put it mildly.



This is so undebian-like, I really cannot understand it, to be honest, debian is my distro of choice precisely because they do not do this type of total bs change for change sake.

So indeed, the question is, what was installed by ia32-libs, what is the actual package set needed, as you note, and why on earth was that not fully documented somewhere so that people depending on a core package are not just screwed and left out to dry, like fedora or ubuntu for example love to do release to release?
Back to top

/var/log/apt/history.log

if you have a system where ia32-libs was installed, check that history.log file and see if you can find what packages were pulled in at the time ia32-libs was installed, maybe you can deduce it and post the results.

Getting an actual answer however is hard because it means you have to test i386 package by package until you find the set that actually fixes the issue, then you have to remove them, double check, then once confirmed, we can generate a list to test/install. Pain in the a#s, but that's how it goes when you get crappy documentation/failure to document from a major distro.

As lame 'solutions' go, this is pretty good, but it's all #debian could offer which means apparently nobody knows or even gave the matter any thought before dropping that metapackage, which is really weird.
Back to top

Through some more totally fruitless questioning, where every answer just loops back to the question, due to debian's failure to actually document the key information, I believe I have found the actual question:

nvidia 64 bit driver required some i386 libs/packages. Nobody knows what those packages were, but we do know they were installed by the ia32-libs-i386 metapackage, which in turn, nobody knows what contained.

No documentation exists, none of the descriptions or wiki entries know.

If you have a 64 bit wheezy system with ia32-libs or ia32-libs-i386 installed, do us all a favor and show: apt-cache show ia32-libs-i386

Or whatever the package was called, it varied, sometimes it was: ia32-libs:i386

Now I see why we had so much trouble getting this feature running back in october 2013 (3 MONTHS AGO!!), debian had no clue what they were doing, and were just changing stuff randomly, ie, there had been no real roadmap I will bet you. And because nobody knew back then really what was happening, nobody documented the key issues.

That's what it looks like to me anyway.

If the package ia32-libs-i386 was not in wheezy, that means that debian actually removed a package from stable, which really really would suck, because that is not supposed to happen.
Back to top

I made a diff between the system which went through all transitions (having ia32-libs-i386 in the past) and a new one (with new one having Wine already installed and may be a few of other installed packages which I know Wine needs, like libasound2-plugins:i386):
pastie.org/8655896
both are current testing systems (I don't have a separate Wheezy install atm).

Installing that full list makes Wine work (if Wine itself is installed with 32 bit dependencies it pulls in of course). But the list is for sure superfluous. What I'll try to do, is to split it in chunks (let's say 10 packages at a time) and install them chunk at a time, checking it it fixes the problem. Then I can narrow it down more out of those 10 which actually work. It can get messy though, if it needs more than one and they'll fall in different chunks... But what can you do %) I'll write the results back here.

This is indeed weird, I never had such experience with Debian before. I can understand the logic behind dropping that metapackage though - it was a tradeoff. Everything in one pile to cover many needs. But it was cluttering. So Debian decided to remove it insisting on something like "install stuff individually, we now have multiarch". The problem is, users have no easy way to figure out what to install! (Like in this very case). To help that, some metapacakges need to be created to address such cases. Something like wine-i386-support or something.
Back to top