Intel 32bit packages on Ubuntu from 19.10 onwards

Do I understand correctly that you are going to just copy binary i386 packages from the bionic repository to eoan repository?! Are you really sure that it will be easier to maintain this than just continue building i386 packages? You may just drop Chromium, Firefox, Thunderbird, Linux kernel and some other things on i386, all other packages will be buidable with a near to zero maintanance effort.

3 Likes

Whatever excuse you feel like using to feel better. But that is official communication from a Valve developer, not just noise on the internet, which you claimed.

4 Likes

There have been multiple instances of malware being uploaded to the snap store. Nothing has changed. The same attack vectors exist and will continue to exist as long as any user can upload snaps without anyone testing them. But, again, I’d prefer to not derail this topic further.

1 Like

As far as I know there was one instance, and it was removed extremely fast. Also measures have been taken to improve the situation and as far as I know it didn’t even escaped the confinement.

1 Like
2 Likes

Hi, I’m jre, (co-)maintainer of Wine in Debian, and the one who worked to bring our packages to the Ubuntu archives. I was only aware of dropping the i386 images (talked to xnox about this in 2016), but unfortunately not the current plan. AFAIK the same goes for Wine upstream.

Upstream started discussing Ubuntu’s plan here. Please have a look at that discussion and take part in it.

A few points:

Wine heavily relies on i386. Not only for legacy 32-bit software, but also “almost all” 64-bit software uses a 32-bit installer.[1] “It’s practically impossible to implement 32-bit on top of 64-bit”, so that you wouldn’t need i386 at all.[2]. So although Wine will still be available in the Ubuntu archive on amd64, it’ll be basically useless.

To support current features in new Wine releases you need recent versions of a few libraries (e.g. faudio, vulkan-loader and vkd3d, and those require other recent stuff like sdl2, …).[3] If you use our Debian packages also current versions of unicode-data and khronos-api. 18.04 is already too old to fully support current Wine with (all) current features. So the solutions proposed in [4] like containers and snaps based on 18.04 will not fully work. I’m not sure how well Wine (which uses the same libraries from amd64 AND i386) would work with a static /lib/i386-linux-gnu.

Upstream is not planning to ship all dependencies for their OBS build, and will probably just stop to build for 19.10+.[5] This is not to say that they are not interested in working on a solution.

About solutions, can you confirm these assumptions:

  • the kernel will still support 32-bit executables
  • you can’t use i386-PPAs for 19.10+

I’ve been told that users already leave Ubuntu, because our Debian packages are not providing good enough system integration (most notably they don’t install a wine.desktop file, but ship it as example only). The 6-line instructions for upstream’s packages are also frequently criticized as too difficult. With whatever solution whoever comes up with, I fear this would drive even more Ubuntu users away.

[EDIT] I was a new user, so could only post 2 links. Here’s the rest:
[1] https://www.winehq.org/pipermail/wine-devel/2019-June/147874.html
[2] https://www.winehq.org/pipermail/wine-devel/2019-June/147959.html
[3] https://forum.winehq.org/viewtopic.php?f=8&t=32061
[4] https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040348.html
[5] https://www.winehq.org/pipermail/wine-devel/2019-June/147904.html

17 Likes

oh, yes, +1, I have Canon iR2018 and it requires a proprietery driver which has 32 bit components. Note that there is an emitation of source code of that driver, but actually that Makefile packages a blob.

Driver maintainer from Canon can be contacted via email in debian/changelog of their deb packages.

image

2 Likes

i386 will be disabled on Launchpad and there will not be an i386 basesystem to build packages, if Canonical follows the current plan. I would appreciate leaving it possible to build 32 bit packages in PPAs.

Also, I am thinking that, if i386 is dropped in Ubuntu, I will have to rebuild the Ubuntu repository and maintain a seperate i386 repository, because I need to at least:

  • continue using Xerox MFP3400 and Canon iR2018 on home and corporate desktops
  • continue to be able to run 32 bit applications under Wine (e.g. Mathcad or Keycollector) from time to time

I think that it will not be too difficult. If nothing changes, I will probably start writing scripts to automate rebuilding Ubuntu packages and keeping build specs in a git repository to which other people will be able to contribute.

I have setup an empty “organiztion” on Github for these: https://github.com/ubu32
If anyone is interested, you can click “Watch” on Github to keep track. For now I will see what Canonical decides.

1 Like

Wouldn’t the final solution for 32-bit Mesa OpenGL (running in a 32-bit process) be to make calls via interprocess communication to the 64-bit Mesa (running in a different 64-bit process) instead of making direct calls to the Linux kernel?

Wine is to run Windows apps in Linux. If ppl wants/needs to run Windows apps, shouldn’t they run them in Windows?

I never used Wine, for one reason. I run Linux apps in Linux, and if I need to run a Windows app, such as Autocad, which cannot be run natively in Linux, I use Windows. Usually the laptops I bought always came with Windows, and I never throw away something I paid for. Wine, I think gives prominence to Windows apps and in a way advertises it.

Regarding all those 32bit Windows apps (games etc) that would still run on Windows would depend on Windows itself, not Linux, or even Wine. I don’t play games, so can’t say much about them, but I have a Windows 10 device that runs a 32 bit Windows 10. It, of course has a 64 bit processor. Now, this device has only System32, and as it is running the 32bit OS, that System32 has only 32bit software. In another device, which has the 64 bit Windows 10 has the system folder System32, which actually ha only 64 bit software, and there’s another system folder called SysWow64, which has only 32 bit software. The 32 bit OS device doesn’t have SysWow64 folder.

Now, one day, MS would say, end of support for 32bit software and even the 32bit Windows 10, just like it did with Windows RT. No one is going to create apps for Windows RT, would they? Like that, one day, all these 32bit app/games developers would have to start creating 64bit apps/games or lose business. That OS dictates the terms, doesn’t it.

I am keeping that 32bit Windows 10 device, just to see how long it would have support. No one is going to keep on supporting 32 bit devices and software.

Let them eat cake, you mean?

Even if you were offering to pay for the licences, telling people that they can no longer run (looks) about 4,800 programs with no problems and another 4,000 with some tweaking via WINE is unlikely to go well.

Especially as you can’t run some of them on Windows any more, because Microsoft removed stuff from it.

1 Like

Why? Updating the dependencies of proprietary software that will never be released again is very useful. It allows to remove security bugs, add hardware support, etc.

It is why SDL added that fancy “dynamic-dispatch-even-if-statically-linked” layer recently and why they ask developers not to static link to it or disable that layer, so that games can be kept working for a long time.

2 Likes

I’ve always (since 14.04) used the libraries mentioned in this link for a variety of Xerox printers, or 32-bit drivers: http://douglask.fog.org/home/xerox-phaser-6010n
They seem to work, so how does this discussion of specific printers impact these libraries?

1 Like

Looking at the mailing list where this was decided, I see that it was known over a year ago that “On the list of known blockers for removing the i386 port are Steam and Wine (sic).” (https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html)

So what actually happened in the past year?

Why is this apparently news to Steam and WINE?

3 Likes

A post was merged into an existing topic: Dropping 32 bit support (i.e. games support) will hurt Ubuntu. Big time

I read that thread about three months ago, and while removing i386 support was clearly mooted there, nothing appears to have been decided in that particular discussion. In fact, the thread ends in a question.

Some of the posters in that thread are also confused about what exactly it is that is proposed. Much of the talk is about hardware (supporting 32-bit CPUs), and at one point a poster asks what exactly it is that is being proposed.

Wine is to run Windows apps in Linux. If ppl wants/needs to run Windows apps, shouldn’t they run them in Windows?

I would rather not. All my personal computers run only Ubuntu. And if I needed to run one or a couple of windows applications I would rather run them on Ubuntu.

Windows licenses cost money, there’s something called the Ubuntu promise, which is that Ubuntu is and will always be for free. The reason behind it is that Ubuntu objective is to help people and not all have money for a windows license, and some more people may have the money but more important things to spend it on like medicine, education, etc…

Ubuntu is a liberation platform, its stated mission is to bring the best of Free Software to the people, however, that doesn’t mean that this is enough for everybody, sometimes, people still have to use some applications that are not Free Software and that sometimes are not even Linux applications. It may happen (it really does) that somewhere in the world States demand their citizens to use a windows application in order to take for of some mandatory bureaucracy. Going back again to human values behind Ubuntu, we can also read on the Code of Conduct, that we should be mindful of others, so we should also take the best of Free Software even to those that sometimes are forced to used windows applications, but that want for the most of the time just use Ubuntu and Free Software.

All this should also be seen within the realms of what is indeed practical or not. Some times they were practical for some time, and stop being after a while due to external changes and evolution.

1 Like

In order to run Steam in LXD and maintain nvidia compatibility between the host and guest container, the container would need to bind mount the nvidia userspace drivers from the host.

1 Like

Indeed, LXD has a nvidia.runtime key that does this for you.

I just wrote a blog post on running Steam and Wine on Ubuntu 19.10 (no 32-bit on the host), with an NVidia GPU.
I did not use nvidia.runtime in my case, just to make it a bit more explicit what is going on.

https://blog.simos.info/i-am-running-steam-wine-on-ubuntu-19-10-no-32-bit-on-the-host/

I should have shortly a fresh CS:GO screenshot from Steam running in a LXD container :-).

2 Likes

xalt7x and mikhailnov provided few examples.

Good to know this is also covered.

By the way I do the same due to bunch of unresolved snap issues, such as application startup time and snap folder in home directory that looks like odd one, because other folders in home directory is localized, while this one is not and should not be there in first place (at least in my opinion).

1 Like