ia32-libs-multiarch:i386 is not installable

This is likely related to #900483

These are also missing: gsettings-desktop-schemas:i386 mime-support:i386 winbind:i386 oss-compat:i386.

Status changed to 'Confirmed' because the bug affects multiple users.

Daniel, the current version of ia32-libs-multiarch in precise doesn't depend on any of those packages.

In any case, the uninstallability of ia32-libs in precise is known. It is not a bug in ia32-libs, it is an in-progress conversion of the dependent packages to multiarch.

While I can understand a transition in progress, the net result is that the precise upgrade fails. And even when I can recover the machine, I can't do any further testing or work.

Wouldn't it have been better to approach this bottom up? With a bottom up approach, everything would continue to work right up to and through the conversion, no?

On Tue, Dec 06, 2011 at 01:41:32AM -0000, teamnoir wrote:
> While I can understand a transition in progress, the net result is that
> the precise upgrade fails. And even when I can recover the machine, I
> can't do any further testing or work.

> Wouldn't it have been better to approach this bottom up? With a bottom
> up approach, everything would continue to work right up to and through
> the conversion, no?

Bottom-up was what we did last cycle and it resulted in almost no effort
being put into the conversion. The ia32-libs package needs to get
completely converted this cycle; this is the way to force the issue.

To test precise given that ia32-libs is not upgradable, you should be able
to put the package on hold by running:

$ echo ia32-libs hold | sudo dpkg --set-selections
$ echo ia32-libs-multiarch:i386 hold | sudo dpkg --set-selections

That should let you upgrade from oneiric to precise for the rest of the
packages while holding ia32-libs back.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

If this is a known problem with a known workaround then it needs to get into user's hands before they start the upgrade. I think that means in the announcements and such.

In either case, this ticket represents a failure to install and as such, I think it should stand until the problem is rectified. It is valid and it's going to bite a lot of people, (at least during development).

When tray to install google-talkplugin_current_amd64.deb (google talk) or Skype (skype-ubuntu_2.2.0.35-1_amd64.deb), then occurs the bug.

Steve, this isn't about uninstalling stuff. It's about not being able to install ia32-libs.

Why invalid when it's a real problem?

$ sudo apt-get install ia32-libs-multiarch
[...]
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ia32-libs-multiarch:i386 : Depends: ibus-gtk:i386 but it is not going to be installed
                            Depends: libcanberra-gtk-module:i386 but it is not going to be installed
                            Depends: libcap2:i386 but it is not going to be installed
                            Depends: libgphoto2-2:i386 but it is not going to be installed
                            Depends: libgphoto2-port0:i386 but it is not going to be installed
                            Depends: libsane:i386 but it is not going to be installed
                            Depends: libpam-winbind:i386 but it is not going to be installed

It's a real problem, but it's not a bug in the ia32-libs package, which should not change between now and the precise release. The real bug is in the library packages which are not yet cross-installable because they haven't ben converted for multiarch, but it's not useful to track these libraries as bug reports because although we're getting close to the end of this list, we don't know exactly which packages are left to be converted because each installable package may mask other issues. So creating a bug report with tasks for 20 library packages would just be a waste of effort which doesn't help users our developers track the actual progress on the issue.

Two points.

First, ia32-libs is broken. The problem may be inherited. And the -fix- may but elsewhere, but the presenting issue, the visible symptom, happens when we attempt to install ia32-libs.

As user/tester, it's my job to report that symptom to the ia32-libs developer. If the developer has no code changes to make, (that may well be the case, I don't know, I trust your word here), then the task becomes one of reporting the problem to the developers of the underlying packages and pointing to this ticket as reference for the symptom and as a test case to demonstrate the problem.

If ia32-libs developers simply throw up their hands and say, "not my problem", then the problem may never be fixed as the developers for the underlying packages may not be aware of the issue, the necessary changes, nor their responsibilities in this. This ticket helps create that explanation.

Second, those 20 other tickets do help us. They help -me- track what has been done, what needs to be done, what I should spend time testing, perhaps who I should check in on, and maybe, just maybe, if it bugs me enough, those tickets might tell me which packages I should go hack in order to move things forward. Without those other tickets, I'm going to keep bugging you. And as you say, there may not be much you can do directly to move this forward.

Dismiss me if you like. I have no authority here. My interest is in getting this fixed ASAP so that I can be running my work on precise as a sort of burn in testing, (I manage a modest pile of servers doing automated builds of my company's products, (which we have just announced will be open sourced soon)). I do this because I have servers I can allocate, I can debug, and it is in my company's interest that precise work in our environment on the day that it is released. Ime, if an Ubuntu release doesn't, then it will never be fixed and we have either a headache managing or own local fixes or we must skip a release, either of which are non optimal. I'm not writing this to demand that you make my world work. I'm writing to explain that I have both motivation and ability to help, but that I'm currently blocked. And I'm sure that I'm not alone.

How can I help?

teamnoir, you appear to be laboring under a number of misapprehensions.
Please allow me to set the record straight.

On Sun, Dec 18, 2011 at 08:13:48PM -0000, teamnoir wrote:

> As user/tester, it's my job to report that symptom to the ia32-libs
> developer. If the developer has no code changes to make, (that may well
> be the case, I don't know, I trust your word here), then the task
> becomes one of reporting the problem to the developers of the underlying
> packages and pointing to this ticket as reference for the symptom and as
> a test case to demonstrate the problem.

> If ia32-libs developers simply throw up their hands and say, "not my
> problem", then the problem may never be fixed as the developers for the
> underlying packages may not be aware of the issue, the necessary
> changes, nor their responsibilities in this. This ticket helps create
> that explanation.

There are no "ia32-libs developers" and "developers of the underlying
packages" here. There is only one set of Ubuntu developers who are
responsible for the packaging of Ubuntu as a whole - and I am one of them.
So when I say that trying to file bugs against all of the dependent
libraries is not an exercise that helps the developers, I am speaking from
first-hand knowledge.

The raison d'être for this bug tracker is to document bugs in packages so
that the developers know what needs to be fixed. Now, it's a fully open bug
tracker in part so that users and testers know what the status of a given
issue is, and don't waste their time reporting already-known issues; but if
the primary purpose is not met by a bug report - documenting an issue in a
package that should be fixed by the developers - it should not be an open
bug report.

> Second, those 20 other tickets do help us. They help -me- track what
> has been done, what needs to be done, what I should spend time testing,
> perhaps who I should check in on, and maybe, just maybe, if it bugs me
> enough, those tickets might tell me which packages I should go hack in
> order to move things forward. Without those other tickets, I'm going to
> keep bugging you.

No. There is no straightforward way to get a comprehensive list of the
affected packages, so any list would be *partial*, meaning those bugs would
be completely useless for actually tracking the status of fixing
ia32-libs-multiarch. The only way to find the affected packages is for a
developer to dig down through the dependencies one by one, and the most
effective way to do that is by simply fixing the packages. Furthermore, it
would take nearly as much time for a developer to file these bugs as it
would to just fix the issues. And since I'm already working on fixing these
issues, any time spent filing those bugs is time taken *away* from working
on the actual packages.

Transitions like this simply cannot be effectively tracked via bugs.

> And as you say, there may not be much you can do directly to move this
> forward.

That is certainly not anything that I said, and I really have no idea how
you got that impression.

> My interest is in getting this fixed ASAP

Yes, that's my interest as well.

--
Steve Langasek Give me a lever long enough...

I have the same question, and I found this post: http://j.mp/TasvUv
It solve my problem.

You need to remove bluez first then re-install ia32-libs-multiarch:i386 and ia32-libs.

As we just found out, testing a new server, this has not yet been fixed. The solution mentioned by elleryq doesn't work, we have no ia32 or bluez packages on this machine.

This is causing issues with a special java install that we use. We will probably just switch this machine to CentOS. I'm surprised, and quite disappointed, that such a major issue has remained unsolved, a year later. Even the most cursory googling indicates that it's a common issue, with no confirmed universal fix on a release that is supposd to be LTS.

There is no universal fix because there's not a bug here. The ia32-libs packages are installable.

I'm with Scott. Marking this bug as invalid and saying "there's not a bug here" is simply maddening for a user who's just installing Precise and finding that ia32-libs simply don't work - they can't be installed. This breaks Crossover and Lotus Notes, on an LTS release.

It's been a year. Is a fix expected?

Thanks for your efforts - we do appreciate them.

I found a workaround, at least in precise: install ia32-libs_20090808ubuntu26_amd64.deb, from oneiric: http://packages.ubuntu.com/oneiric/amd64/ia32-libs/download. In my precise installation, this version installs and runs fine, once the libraries it depends on are also installed. All of those are available in the precise repositories.

quantal - the bug still exists

Contrary to what I wrote in #16, I now agree with Steve that this isn't a bug in ia32-libs or ia32-libs-multiarch.

I created a new virtual machine, installed a virgin copy of Quantal in it, updated, and then installed ia32-libs. It installed with no problems, bringing ia32-libs-multiarch with it. This implies that when those packages won't install, it's because of a configuration problem on the host.

Back on my precise host where I had this problem, after investigating I found that I had some pinned packages installed that were incompatible with ia32-libs in precise. Once I uninstalled those, I was able to install ia32-libs, and ia32-libs-multiarch with it, from the precise repository.

If you can find the problem on your host, maybe the workaround I posted in #17 will help.

I had this issue with a fresh install of Ubuntu Server 12.10. It turns out, dbus must be running in order for bluez to configure successfully.

# service dbus start
dbus start/running, process 24551
# dpkg --configure bluez
Setting up bluez (4.101-0ubuntu6) ...
# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up bluez-alsa:i386 (4.101-0ubuntu6) ...
Setting up ia32-libs-multiarch (20090808ubuntu36) ...