Intel 32bit packages on Ubuntu from 19.10 onwards

RussianNeuroMancer 2019-06-23 00:15:43 UTC #82

But what about old printer and MFP drivers that actually need to interact with hardware for things like printing, scanning, sending/receiving faxes, supporting MFP buttons “scan to PC”, etc.? Even if it’s possible to run those things in containers, how they are going to get there if user double click on binary installer or i386 deb downloaded from vendor’s web-site?

As for Steam - keep in mind that games published there need to interact with 32 bit OpenGL implementation, which means not only providing 32-bit Mesa as container dependency (which is Ok) and keeping it updated in timely manner (because in Linux gaming availability of fresh Mesa version make a difference between working system and GPU hang) but also providing every version of 32 bit Nvidia driver that should match version of kernel driver to be operational.

Honestly, I’m all for dropping i386 repo, but solutions for keeping people’s hardware and software running have be tested in real world and be reliable. At this moment there is no solutions, but only blind assumption, that these solutions could be created (which could be possible, but it’s remain to be seen). Dropping i386 now is like putting the cart before the horse.

vorlon 2019-06-23 02:31:27 UTC #84

I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.

timattrn 2019-06-23 06:12:24 UTC #85

Perhaps it would have been better to at least agree in advance with Valve and Wine about how this may work. As is stands, neither will support 19.10, according to statements by senior developers. I haven’t used a 32 bit 386 machine in a long, long time. But I use Crossover and I have another computer which has Steam, both run Ubuntu. As you must surely realise (now), neither project is very useful without multiarch. I think there are quite a lot of users like me, and we are hearing that the end of our time with Ubuntu is coming fast.

RussianNeuroMancer 2019-06-23 07:16:01 UTC #86

Good to know, so at least no issues with printer/mfp drivers - honestly, this is relief. But, still, what about 32 bit Mesa?

What will happen with 32 bit only PCSX2 package at least in next release? Revert back to 1.4.0 or keeping it 1.5.0 git? Or updating it to newer git snapshot which is actually necessary to fix some regressions introduced by current git snapshot?

YamiYukiSenpai 2019-06-23 08:32:17 UTC #87

What’s gonna happen once 18.04 is dead? Or there’s a newer version of those libraries?

And besides, most Ubuntu users want simple instructions on how to do it because, while some of us would be willing to go to the terminal and set up containers, most won’t want to go through all that hassle.

You might as well include Pop!_OS’s repo on Ubuntu if you want it to continue being recommended to everyone.

vorlon 2019-06-23 09:34:10 UTC #88

32-bit mesa will be available in the Ubuntu 18.04 repository. Note that mesa already gets updates in 18.04 which track the versions from later Ubuntu releases, as part of hardware enablement. If incompatibilities are introduced beyond 20.04 (which is the cutoff for hardware enablement backports for 18.04), we will need to address them on a case-by-case basis.

PCSX2, as the plan stands today, would be available only in the 18.04 repository - so would be available at version 1.4.0. i386-only application packages currently distributed in Ubuntu are strong candidates for being converted to snaps. It looks like there’s been at least one effort already to package PCSX2 as a snap (pcsx2-tabetai).

Can you clarify why you’re interested to know about newer versions of libraries? Because i386 would be treated as “legacy”, it would not get newer library versions. But since the vast majority of i386-only software is also legacy (closed-source, will never be rebuilt), it also does not generally benefit from newer libraries. Do you have something specific in mind?

vorlon 2019-06-23 09:55:49 UTC #90

The most significant collection of affected printer drivers that we’re aware of are those for Brother printers. We’re exploring a number of options regarding how we can support those. If you’re aware of drivers other than Brother that are in this situation, please let us know what they are so we can assess those as well.

We can and should make the 32-bit nvidia drivers available as part of the amd64 packages. These would then be exposed into the 32-bit containers, ensuring that the 32-bit userspace libraries matched the version of the kernel driver, regardless of what other library versions were available as packages within the container.

dfl 2019-06-23 10:06:45 UTC #91

I am not a native English speaker so maybe I missed something but I got the impression that i386 was going to be dropped completely (save for containers and workarounds). Good if it’s not going to be this dramatic.

I’ve read a lot of comments on this and I got a feeling the real issue is not about i386 support but that with this decision (and apparently without involving Valve or Wine developers) Ubuntu is no longer a reliable desktop solutions for those who want to focus on desktop users. One cannot work for the environment where things can break at any time (or not work at all). I hope engineers at Canonical can take this into account at this point and in the future.

It also seems this was an exercise in how not to communicate future plans again without involving other important developers.

Btw, I am very grateful to everyone at Canonical. I would have never become a linux user if there was no Ubuntu and I think the linux userland would be much smaller and poorer without your input.

YamiYukiSenpai 2019-06-23 10:08:08 UTC #92

Mainly graphics, like Vulkan, NVIDIA, Mesa

And everything that Wine & Steam needs for 32-bit support

Using 18.04 in a container as a base seems to be only a band-aid solution in a massive hole that was created. I was skimming through Wine’s mailing list, and it seems that while you are working with Valve on making sure none of our games from Steam break, they stopped recommending and supporting Ubuntu.

And we need those 32-bit libraries for legacy applications and games.

Say we run Steam and Wine in a container, and we purchased a new, unreleased as of now, Radeon GPU that most likely won’t be supported in 18.04’s kernel, like Radeon RX 5700. IIRC, even the latest AMD GPUs, like Radeon VII, don’t even work well with 18.04. What happens then? Would we still be able to run our games and applications there? What happens when 18.04’s support ends?

I was also reading the Ubuntu Developer mailing list, and it seems that this will negatively affect flavors, like Ubuntu Studio.

henk717 2019-06-23 10:20:33 UTC #93

For me personally this all seems way to much, much to soon.
I totally understand why the Ubuntu team wants to implement this change and i support them in their vision, it is totally unnessesary to be maintaining a large 32-bit repo if most software is also available in the 64-bit repo. We do not need a 32-bit vim if you can also use a 64-Bit vim.

However as we have seen many people still depend on 32-bit support, which is why i suggest keeping a 32-bit repository with the new requirement that before a package is accepted it has to be documented why this package is required on a 64-bit system. This way we can keep the essential packages / programs that have buggy or inferior 64-bit packages while simultaniously keeping the repo’s at a much smaller more maintainable size.

YamiYukiSenpai 2019-06-23 11:54:27 UTC #94

I agree with this suggestion. There are a lot of packages in the repo that don’t need a 32-bit version, like VLC, Vim, Plasma, etc. Those can be removed since Ubuntu doesn’t have i386 distros anymore.

Remove the unnecessary packages and leave the ones a lot of us need behind. That way, you won’t have to maintain too many i386 packages.

Using LXD to get 32 bits applications/steam to work on an amd64 only systems

ipkh 2019-06-23 12:57:40 UTC #95

The Faq and some replies lack some crucial details.
Where does the 1% user base come from? Is this 32bit installs or does this track 64bit installs that install 32bit libraries?
If I as a user try to install a package that depends on a 32bit library what happens? Does it just fail outright? Does it offer the workaround if enabling the 18.04 repo for 32bit libraries? How does this change get communicated to the end user?

How does this change affect Bug #1? This appears on the surface to be a significant regression in regards to bug #1.

I understand dropping 32 bit only images from the distribution, but cannot fathom a really good reason to drop the common multiarch support that defines linux distributions in general.

superian 2019-06-23 14:44:02 UTC #96

As I understand it, the original proposal was to stop doing i386 releases. There’s an argument for that, even though it leaves >1% of your userbase in the lurch.

However, as someone else says…

… is two very different things and that this was what was being proposed was not made at all clear at the start of the process we’re apparently now at the end of.

Users: who needs 'em, eh?

superian 2019-06-23 14:47:08 UTC #97

It is taken from the 98.something% of installs of 18.04 LTS using the amd64 version, I suspect.

So… not people using libraries that are going to be killed off.

Or any of the light distros that are based on Ubuntu.

aaronfranke 2019-06-23 15:10:45 UTC #98

Vorlon, has the Ubuntu team considered just showing warnings when running 32-bit applications before discontinuing support, similarly to what Apple is doing?

This would serve as a transition period, giving a strong incentive for developers to update their apps, and informing users about legacy apps that may not work in the future.

mattcrews 2019-06-23 15:23:54 UTC #99

How do you intend to resolve the version mismatching issue with dpkg and apt? They both require that the i386 and amd64 versions of packages have the same version number, do they not?

How do you ensure that device driver vendors (namely, nVidia) play nice?

diogoconstantino 2019-06-23 15:51:16 UTC #100

There should be a tool to handle this as automagically as possible.

diogoconstantino 2019-06-23 16:00:16 UTC #101

I don’t understand why are you supposing that the burden to setup lxd would be on users, instead of tools that would do it automagically…

diogoconstantino 2019-06-23 16:02:54 UTC #102

Yes it was a guy that doesn’t maintain distros.

einherjar123 2019-06-23 16:06:14 UTC #103

I think you are really causing big problems with your approach. Finally, there must be a solution that “just works” for everything that works now.

If you have not enough ressources, for maintaining Ubuntu with Multiarch, please consider the following ideas:

1. Team up with the dev from the unofficial flavors and do the work together! Some of them mentioned, they want to provide multiarch.
Shouldn’t be that hard, to help each other instead of harming your userbase and the whole Linux Ecosystem.

2. Start a crowdfunding for that and pay devs to do the work, by the money funded

3. Initiate an “Full 32 Bit support” project with volunteers to get help.

In the future you should really do a much better communication work. It does simple not work, to discuss things in forums or mailinglists, to get the attention that is needed for such a big thing.