https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-wi...
A user has already asked about this on the forum. https://forum.winehq.org/viewtopic.php?f=8&t=32565
The immediate question for me is whether to even bother trying to package Wine for Ubuntu 19.10 and up. The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions.
I could build pure 64 bit Wine packages for Ubuntu. We've been telling users for 10 years that pure 64 bit Wine is not supported, but with so many systems going 64 bit only, perhaps it's time to reconsider that policy. There are certainly more 64 bit Windows apps now than there used to be, so it wouldn't be completely useless. The downside of doing that is that we will spend a lot of time explaining to users that pure 64 bit Wine will not run 32 bit programs, no matter how many places we plaster that information. The upside is that if we change that policy, I'm ready to go with pure 64 bit CentOS 7 packages.
Thoughts? Perhaps this should be discussed at WineConf?
Rosanne DiMesio dimesio@earthlink.net wrote:
https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-wi...
A user has already asked about this on the forum. https://forum.winehq.org/viewtopic.php?f=8&t=32565
The immediate question for me is whether to even bother trying to package Wine for Ubuntu 19.10 and up. The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions.
I could build pure 64 bit Wine packages for Ubuntu. We've been telling users for 10 years that pure 64 bit Wine is not supported, but with so many systems going 64 bit only, perhaps it's time to reconsider that policy. There are certainly more 64 bit Windows apps now than there used to be, so it wouldn't be completely useless. The downside of doing that is that we will spend a lot of time explaining to users that pure 64 bit Wine will not run 32 bit programs, no matter how many places we plaster that information. The upside is that if we change that policy, I'm ready to go with pure 64 bit CentOS 7 packages.
Thoughts? Perhaps this should be discussed at WineConf?
Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.
I personally would be very interested if there was a WineConf slot to talk about this. Last time I heard about the schedule from Aric there were still quite a few open spots.
Thanks, Anna
On 6/20/19 8:16 AM, Dmitry Timoshkov wrote:
Rosanne DiMesio dimesio@earthlink.net wrote:
https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-wi...
A user has already asked about this on the forum. https://forum.winehq.org/viewtopic.php?f=8&t=32565
The immediate question for me is whether to even bother trying to package Wine for Ubuntu 19.10 and up. The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions.
I could build pure 64 bit Wine packages for Ubuntu. We've been telling users for 10 years that pure 64 bit Wine is not supported, but with so many systems going 64 bit only, perhaps it's time to reconsider that policy. There are certainly more 64 bit Windows apps now than there used to be, so it wouldn't be completely useless. The downside of doing that is that we will spend a lot of time explaining to users that pure 64 bit Wine will not run 32 bit programs, no matter how many places we plaster that information. The upside is that if we change that policy, I'm ready to go with pure 64 bit CentOS 7 packages.
Thoughts? Perhaps this should be discussed at WineConf?
Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.
Many 64-bit applications still use either a 32-bit installer or some 32-bit components. In comparison 64-bit Windows will support 32-bit (probably) forever.
Make that almost all applications. It's very unusual for a program to have a 64-bit installer, because it won't be able to control what happens when a user runs the installer on 32-bit Windows.
In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb.
Reading more carefully: their suggestion is to use a containerized 18.04 environment (snaps) to run Wine on a 19.10 system. This would use the 18.04 packages. But since there's no expectation of long term support for the environment containing 32-bit packages, I can't see any point in putting much effort into this temporary solution.
Nor do I see much point in packaging a 64-bit-only Wine on our end. It's such a niche case for 64-bit-only Wine to be useful at all. If those few people for whom it's useful need the latest development version, they can build it themselves.
On Thu, 20 Jun 2019 at 17:17, Rosanne DiMesio dimesio@earthlink.net wrote:
https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-wi...
A user has already asked about this on the forum. https://forum.winehq.org/viewtopic.php?f=8&t=32565
The immediate question for me is whether to even bother trying to package Wine for Ubuntu 19.10 and up. The suggestion from Ubuntu is to use the 32 bit libraries from 18.04, which will be supported until 2023. It's theoretically possible for me to build the 32 bit side on the OBS using the libraries from 18.04, but that would lead to a mismatch in library versions the 32 and 64 bit sides were built against. Apt requires the i386 and amd64 versions of packages match or it will refuse to install them, so unless that changes, users of 19.10 and up will be unable to install the 32 bit libraries they need to run Wine, unless they downgrade a significant part of their system to the 18.04 versions.
I could build pure 64 bit Wine packages for Ubuntu. We've been telling users for 10 years that pure 64 bit Wine is not supported, but with so many systems going 64 bit only, perhaps it's time to reconsider that policy. There are certainly more 64 bit Windows apps now than there used to be, so it wouldn't be completely useless. The downside of doing that is that we will spend a lot of time explaining to users that pure 64 bit Wine will not run 32 bit programs, no matter how many places we plaster that information. The upside is that if we change that policy, I'm ready to go with pure 64 bit CentOS 7 packages.
Thoughts? Perhaps this should be discussed at WineConf?
I think not building packages for Ubuntu 19.10 would be the only practical option. It would probably be good to have a small explanation on the download page though.
As I understand it, it would still be possible to run 32-bit executables on the Ubuntu 19.10 kernel, but we'd have to build and ship all our dependencies ourselves. I don't think we want to go there just yet.
On Thu, 20 Jun 2019 18:47:23 +0430 Henri Verbeet hverbeet@gmail.com wrote:
I think not building packages for Ubuntu 19.10 would be the only practical option. It would probably be good to have a small explanation on the download page though.
And a sticky on the forum.
As I understand it, it would still be possible to run 32-bit executables on the Ubuntu 19.10 kernel, but we'd have to build and ship all our dependencies ourselves. I don't think we want to go there just yet.
I definitely don't.
FYI, openSUSE Leap went to 64-bit only releases several versions ago, but still continues to provide all the 32 bit baselibs needed to build and run Wine. I use it myself without any problems. Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it.
On Thu, Jun 20, 2019 at 09:59:27AM -0500, Rosanne DiMesio wrote:
FYI, openSUSE Leap went to 64-bit only releases several versions ago, but still continues to provide all the 32 bit baselibs needed to build and run Wine. I use it myself without any problems. Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it.
Yes, I agree. From the FAQ it doesn't seem like they understand Wine's needs.
Ubuntu ships their own Wine package, right? What are they planning to do with that package? Maybe we should get in touch with their Wine maintainer, and whoever is driving this i386 retirement, and confirm that they 1) understand what Wine actually needs and, 2) don't want to provide that going forward.
If they don't, then I have a suggestion for our packages: use the Steam runtime. I see a lot of upsides: They've already solved this problem; we don't need to re-invent this wheel. Ubuntu is already working with them to support the use-case. The project is open-source, well-funded, and has a clear motivation to continue being updated and functional for the long-term. And people are already building and running Wine in the runtime today.
We would need to build a couple more packages than we do now, but not many. Based on the Proton build system, I think we would need to build bison, FAudio, gstreamer (and all of its dependencies, notably glib2), and vkd3d. Build those against the runtime, package and ship the runtime itself, and I think we should be in good shape without having to build and maintain a bunch of 32-bit packages ourselves.
Andrew
On Thu, 20 Jun 2019 13:55:02 -0500 Andrew Eikum aeikum@codeweavers.com wrote:
We would need to build a couple more packages than we do now, but not many. Based on the Proton build system, I think we would need to build bison, FAudio, gstreamer (and all of its dependencies, notably glib2), and vkd3d. Build those against the runtime, package and ship the runtime itself, and I think we should be in good shape without having to build and maintain a bunch of 32-bit packages ourselves.
You would also need to find someone to build and maintain all those packages. I am not interested in the job.
On 20.06.19 20:55, Andrew Eikum wrote:
On Thu, Jun 20, 2019 at 09:59:27AM -0500, Rosanne DiMesio wrote:
FYI, openSUSE Leap went to 64-bit only releases several versions ago, but still continues to provide all the 32 bit baselibs needed to build and run Wine. I use it myself without any problems.
Quite similar, when I talked to one of the Ubuntu guys about their i386 plans 3 years ago, they only planned to drop the i386 installer, but not the whole suite. I'm also flabbergasted by yesterday's announcement.
Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it.
I still need to skim through all of this in detail.
Ubuntu ships their own Wine package, right? What are they planning to do with that package? Maybe we should get in touch with their Wine maintainer
That would mainly be me. There are two Ubuntu developers who worked with me on the transition to Debian's Wine packages. I'll contact them, and everyone else I can think about, later.
Ubuntu has our (Debian) packages. These also work on amd64-only, of course without 32-bit support. I don't see us (Debian maintainers) changing anything in or for Ubuntu about i386.
Debian has no plans to retire i386 for now. I'm only aware of one discussion about retiring it in Debian /sometime/ in the future. But even then I bet it would still be available as a semi-official debian-port for years to come. So if anyone plans to work on Ubuntu/i386, then this is still possible to be based on the Debian packages.
, and whoever is driving this i386 retirement, and confirm that they 1) understand what Wine actually needs and, 2) don't want to provide that going forward.
Please do. I'll try to join everyone once I have a better grip on this.
Greets jre
On 20.06.19 22:49, Jens Reyer wrote:
, and whoever is driving this i386 retirement, and confirm that they 1) understand what Wine actually needs and, 2) don't want to provide that going forward.
Please do. I'll try to join everyone once I have a better grip on this.
I posted in their discourse thread, pointing them to this thread here, and trying to summarize the issue:
https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-wi...
Hi everyone,
good news:
https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-a...
"Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed. [...] We will also work with the WINE, Ubuntu Studio and gaming communities to use container technology to address the ultimate end of life of 32-bit libraries; it should stay possible to run old applications on newer versions of Ubuntu. Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term. [...] It has always been our intention to maintain users’ ability to run 32-bit applications on 64-bit Ubuntu – our kernels specifically support that. [...]"
All the best, Robert
On Thu, 20 Jun 2019 at 19:55, Andrew Eikum aeikum@codeweavers.com wrote:
On Thu, Jun 20, 2019 at 09:59:27AM -0500, Rosanne DiMesio wrote:
FYI, openSUSE Leap went to 64-bit only releases several versions ago, but still continues to provide all the 32 bit baselibs needed to build and run Wine. I use it myself without any problems. Unfortunately, based on what the Ubuntu article says, I don't have any confidence that they even understand what Wine needs, let alone plan to provide it.
Yes, I agree. From the FAQ it doesn't seem like they understand Wine's needs.
...
If they don't, then I have a suggestion for our packages: use the Steam runtime. I see a lot of upsides: They've already solved this problem; we don't need to re-invent this wheel. Ubuntu is already working with them to support the use-case. The project is open-source, well-funded, and has a clear motivation to continue being updated and functional for the long-term. And people are already building and running Wine in the runtime today.
...
Andrew
FYI https://twitter.com/Plagman2/status/1142262103106973698
So Valve are officially recommending users don't migrate to Ubuntu 19.04. Since Canonical's solutions seem to all revolve around using 18.04 (in some form) - that's not really viable in the long-term.
Personally I don't really use Debian-based (including Ubuntu) distributions much at all... But I'll probably install MX-Linux (as part of my multi-boot setup) to test if that offers a reasonable alternative for new Linux/Wine users... After all there is probably going to be a flood of new issues being raised, in the autumn, on the WineHQ forums...
Robert
On Thu, 20 Jun 2019 18:47:23 +0430 Henri Verbeet hverbeet@gmail.com wrote:
I think not building packages for Ubuntu 19.10 would be the only practical option. It would probably be good to have a small explanation on the download page though.
We've now had a forum user ask "Why is it not possible for 64-bit Wine to run 32-bit programs? I know that 32-bit Wine run 16-bit programs, so why not 32-bit on 64-bit? I bet it would be a lot of work, but I don't see why it wouldn't be possible to make Wine use 64-bit system libraries for 32-bit programs if y'all tried to do so."
This has come up before and I expect to get that question a lot from Ubuntu users. I'm not qualified to explain the technical issues, beyond saying Wine does it the same way as Windows (WoW64). I need help framing an answer in terms a typical Ubuntu user can understand that I can put in the FAQ and on the forum.
On Fri, Jun 21, 2019 at 6:41 AM Rosanne DiMesio dimesio@earthlink.net wrote:
... I'm not qualified to explain the technical issues, beyond saying Wine does it the same way as Windows (WoW64). I need help framing an answer in terms a typical Ubuntu user can understand that I can put in the FAQ and on the forum.
Well, part of the problem is that we don't implement WoW64 the exact same way Windows does. All the 32-bit Windows routines have thunks that transition to 64-bit code, call the 64-bit API equivalent, and then transition back to 32-bit code. Our 32-bit libraries call the 32-bit Linux equivalents, since this is massively easier and "just works". I vaguely remember a conversation a number of years ago where someone talked about doing similar thunking to Windows and there was concern that it is too hard to get this thunking correct for every API call, but I don't remember the details as to why that's the case.
Best, Erich
"Erich E. Hoover" erich.e.hoover@gmail.com wrote:
On Fri, Jun 21, 2019 at 6:41 AM Rosanne DiMesio dimesio@earthlink.net wrote:
... I'm not qualified to explain the technical issues, beyond saying Wine does it the same way as Windows (WoW64). I need help framing an answer in terms a typical Ubuntu user can understand that I can put in the FAQ and on the forum.
Well, part of the problem is that we don't implement WoW64 the exact same way Windows does. All the 32-bit Windows routines have thunks that transition to 64-bit code, call the 64-bit API equivalent, and then transition back to 32-bit code.
That's probably true only for low level things like ntdll, user32, gdi32 and ws2_32, but everything else that doesn't need to access kernel level OS functionality (like gdiplus/windowscodecs) don't need to perform the 32-bit to 64-bit transition.
Our 32-bit libraries call the 32-bit Linux equivalents, since this is massively easier and "just works". I vaguely remember a conversation a number of years ago where someone talked about doing similar thunking to Windows and there was concern that it is too hard to get this thunking correct for every API call, but I don't remember the details as to why that's the case.
win16 is very small in comparison with win32, so it was relatively easy to implement it on top of 32-bit code, it's practically impossible to do the same thing to implement 32-bit on top of 64-bit.
On Fri, Jun 21, 2019 at 9:03 AM Dmitry Timoshkov dmitry@baikal.ru wrote:
"Erich E. Hoover" erich.e.hoover@gmail.com wrote:
On Fri, Jun 21, 2019 at 6:41 AM Rosanne DiMesio dimesio@earthlink.net wrote:
... I'm not qualified to explain the technical issues, beyond saying Wine does it the same way as Windows (WoW64). I need help framing an answer in terms a typical Ubuntu user can understand that I can put in the FAQ and on the forum.
Well, part of the problem is that we don't implement WoW64 the exact same way Windows does. All the 32-bit Windows routines have thunks that transition to 64-bit code, call the 64-bit API equivalent, and then transition back to 32-bit code.
That's probably true only for low level things like ntdll, user32, gdi32 and ws2_32, but everything else that doesn't need to access kernel level OS functionality (like gdiplus/windowscodecs) don't need to perform the 32-bit to 64-bit transition.
That's my understanding as well, I was trying to give a quick summary - "all" was probably a poor choice of words.
Our 32-bit libraries call the 32-bit Linux equivalents, since this is massively easier and "just works". I vaguely remember a conversation a number of years ago where someone talked about doing similar thunking to Windows and there was concern that it is too hard to get this thunking correct for every API call, but I don't remember the details as to why that's the case.
win16 is very small in comparison with win32, so it was relatively easy to implement it on top of 32-bit code, it's practically impossible to do the same thing to implement 32-bit on top of 64-bit.
I would assume that we would keep as much as possible as 32-bit and, like Windows, only transition to 64-bit in places where we absolutely have to (such as when we need to call system libraries). Don't get me wrong, this is still a _ton_ of work, but I believe that when someone brought this up before that there was a technical limitation that prevented us from doing this at all and I've forgotten what was said.
Best, Erich
On 6/21/19 6:03 PM, Dmitry Timoshkov wrote:
"Erich E. Hoover" erich.e.hoover@gmail.com wrote:
On Fri, Jun 21, 2019 at 6:41 AM Rosanne DiMesio dimesio@earthlink.net wrote:
... I'm not qualified to explain the technical issues, beyond saying Wine does it the same way as Windows (WoW64). I need help framing an answer in terms a typical Ubuntu user can understand that I can put in the FAQ and on the forum.
Well, part of the problem is that we don't implement WoW64 the exact same way Windows does. All the 32-bit Windows routines have thunks that transition to 64-bit code, call the 64-bit API equivalent, and then transition back to 32-bit code.
That's probably true only for low level things like ntdll, user32, gdi32 and ws2_32, but everything else that doesn't need to access kernel level OS functionality (like gdiplus/windowscodecs) don't need to perform the 32-bit to 64-bit transition.
Yeah it only applies to low level components. As a simple case, the syswow64 directory contains the (non-SxS) 32-bit libraries and its size is pretty large by itself, and so are the 32-bit libraries under winsxs. If it were just thunks it would be very small on Windows but that's not the case.
In theory, it's possible to thunk calls to external dependencies, but other than just a pretty severe performance loss, it will require a lot of work especially when it involves pointers. And callbacks from said libraries would be *really* problematic.
Well, part of the problem is that we don't implement WoW64 the exact same way Windows does. All the 32-bit Windows routines have thunks that transition to 64-bit code, call the 64-bit API equivalent, and then transition back to 32-bit code.
That's probably true only for low level things like ntdll, user32, gdi32 and ws2_32, but everything else that doesn't need to access kernel level OS functionality (like gdiplus/windowscodecs) don't need to perform the 32-bit to 64-bit transition.
Those examples also demonstrate an important difference between Wine and Windows. On Windows, both of those libraries are implemented based on lower-level dll's and can work the same way as an application's 32-bit dll's. In Wine, that's true for gdiplus (and in fact, on current Wine gdiplus is being built as a PE dll), but windowscodecs needs to access native Linux libraries like libpng and libjpeg. So for Wine, it's not just a few low-level libraries that would need thunking. It's any dll that needs to use a Linux library.
Our 32-bit libraries call the 32-bit Linux equivalents, since this is massively easier and "just works". I vaguely remember a conversation a number of years ago where someone talked about doing similar thunking to Windows and there was concern that it is too hard to get this thunking correct for every API call, but I don't remember the details as to why that's the case.
win16 is very small in comparison with win32, so it was relatively easy to implement it on top of 32-bit code, it's practically impossible to do the same thing to implement 32-bit on top of 64-bit.
In fact this was attempted with the hangover project: https://github.com/AndreRH/hangover
The README explains that it currently doesn't work very well, and it goes into a lot of detail about the technical challenges of this approach.
There are other possible approaches, but they all pose similar challenges, and no solution for running 32-bit applications without 32-bit host libraries is ready for users yet.
CodeWeavers is working on a solution for MacOS, which will soon be dropping its 32-bit libraries. LIke hangover, this is not ready for users, and it's not targeting Linux. We don't expect it to have the same level of compatibility or performance that 32-bit Wine has today.
On Freitag, 21. Juni 2019 18:11:39 CEST Vincent Povirk (they/them) wrote:
also demonstrate an important difference between Wine and Windows. On Windows, both of those libraries are implemented based on lower-level dll's and can work the same way as an application's 32-bit dll's. In Wine, that's true for gdiplus (and in fact, on current Wine gdiplus is being built as a PE dll), but windowscodecs needs to access native Linux libraries like libpng and libjpeg. So for Wine, it's not just a few low-level libraries that would need thunking. It's any dll that needs to use a Linux library.
On a sitenote, will macOS still support 32bit code at all? Because if not, those would be quite different challenges. On Linux you can atleast still switch between 32bit and 64bit code.
Regards, Fabian Maurer
чт, 20 июн. 2019 г. в 14:47, Rosanne DiMesio dimesio@earthlink.net:
Thoughts?
There seems to be a trend where applications are distributed with all their runtime dependencies bundled, libraries, compatibility layers, etc. With a filesystem that has built-in compression this may not take up that much more space on disk.
To support this with Windows applications, I imagine having conversion tools like: msi2rpm, msi2deb, msi2snap, msi2flatpak or maybe a generic tool for all installers. (Maybe such tools could even be ran on Windows and download extra things they need.)
I have seen Windows applications distributed in such a way before (with a bundled Wine version), but I am not aware of any tools to automate the creation of such packages. Maybe such tooling could become part of the Wine project?
Another thing I'm wondering about is what would happen if Windows builds of libraries like GStreamer would be used by Wine instead. Could this reduce the need for some libraries to be provided by the host system?
Best regards, Julius
On Sat, 22 Jun 2019 at 13:15, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
There seems to be a trend where applications are distributed with all their runtime dependencies bundled, libraries, compatibility layers, etc.
Also sometimes referred to as "vendoring". Please don't do that.
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work. The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Henri
On Sat, 22 Jun 2019 14:34:47 +0430 Henri Verbeet hverbeet@gmail.com wrote:
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work.
I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages.
The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Other than the part about Debian being the obvious choice, that's basically what our forum sticky for CentOS/RHEL/Scientific Linux 7 users has been saying for 5 years.
On Sat, 22 Jun 2019 at 15:42, Rosanne DiMesio dimesio@earthlink.net wrote:
I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages.
Sure.
----- On Jun 22, 2019, at 1:12 PM, dimesio dimesio@earthlink.net wrote:
On Sat, 22 Jun 2019 14:34:47 +0430 Henri Verbeet hverbeet@gmail.com wrote:
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work.
I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages.
Since most Launchpad PPA´s provide the needed orig.tar.xz files, along with .dsc and -debian.tar.xz, it is not impossible to re-build those packages on the OBS for use as a dependency. It is not there the work lies i guess.
Dunno if *buntu maintaners plan on creating any wine-release on Launchpad at all, but if they do, it is not really impossible to maintain OBS as a kind of "backup" of Launchpad to use for -devel and -staging.
Will be interesting to see how this is solved on Launchpad, cos dependencies is a hornets nest on top of a anthill, and once main repo´s start dropping deps it´s a huge undertaking to unwind.
Sveinar
The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Other than the part about Debian being the obvious choice, that's basically what our forum sticky for CentOS/RHEL/Scientific Linux 7 users has been saying for 5 years.
-- Rosanne DiMesio dimesio@earthlink.net
On 29.06.19 10:31, Sveinar Søpler wrote:
----- On Jun 22, 2019, at 1:12 PM, dimesio dimesio@earthlink.net wrote:
On Sat, 22 Jun 2019 14:34:47 +0430 Henri Verbeet hverbeet@gmail.com wrote:
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work.
I can't use PPAs to satisfy build dependencies on the OBS. Packages have to either be in the Ubuntu standard, update, or universe repositories, or on the OBS itself. The latter is what we're doing for FAudio. That works fine, other than the whining from Ubuntu users about the tremendous difficulty of copying and pasting the command to add another repository. So if Ubuntu users do decide to go the PPA route, they should also plan on building their own Wine packages.
Since most Launchpad PPA´s provide the needed orig.tar.xz files, along with .dsc and -debian.tar.xz, it is not impossible to re-build those packages on the OBS for use as a dependency. It is not there the work lies i guess.
tldr: No, unfortunately I'm quite sure you are wrong here. But fortunately that doesn't matter now because Ubuntu changed its plans for 19.10/20.04.
Doing this for the *complete* i386 dependency chain of Wine is lot of work, even if you manage to automate it for the initial setup and subsequent permanent updates. Even though most packages are based on Debian and thus already work for i386, there will be some packages that need specific fixes and adjustments. This is most probably not a job winehq can do. But it might work, if you've got a community which has knowledge about Debian packaging - people discussed doing this in this discourse thread [1]. The work should be based directly on the Ubuntu archive then, not some random PPAs.
[1] https://discourse.ubuntu.com/t/would-a-community-supported-i386-repo-be-viab...
Dunno if *buntu maintaners plan on creating any wine-release on Launchpad at all, but if they do, it is not really impossible to maintain OBS as a kind of "backup" of Launchpad to use for -devel and -staging.
Winehq/Rosanne is on OBS only. Debian/me is only working in the official archive. I'm not aware of any other maintainers for Ubuntu packages, of course that hopefully changes for the time after 20.04.
Will be interesting to see how this is solved on Launchpad, cos dependencies is a hornets nest on top of a anthill, and once main repo´s start dropping deps it´s a huge undertaking to unwind.
As I understand the old plans there is no solution on launchpad: i386 would've been gone, and not possible to build on launchpad.
But (and I assume you missed that): Ubuntu has changed its plans and will do the work for Wine's dependency chain until 20.04. AIUI all we have to do is to nag them, if some packages are missing.
Then, for the time after 20.04, they (Ubuntu) announced to contact us (Wine) to work out a permanent solution.
Greets jre
On 22.06.19 12:04, Henri Verbeet wrote:
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work. The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Henri
It's probably quite safe to say that the kernel itself will continue to support 32-bit executables, else Ubuntu's recommended solution of relying on the older 32-bit libs (or using runtimes) probably wouldn't work.
Creating some kind of PPA (doesn't have to necessarily be an "official" PPA on launchpad though, since they require packages to be source-built) is a good idea, it may be possible as well to just fetch the libs from Debian and putting them into the PPA.
Another solution aside from a PPA would be to just use the Debian repositories and pin the packages that are needed from there. This has been a solution to installing openjdk7 on Ubuntu >16.04, and it doesn't require maintaining a seperate PPA (relevant AskUbuntu answer outlining the process: [1]). However, while reducing the maintaining effort compared to a PPA, this would only be a better solution, if all the packages can be used directly from Debian without conflicts or other issues.
[1] https://askubuntu.com/a/803616/702964 ("Option 2: Automatic Installation")
Tim
On 22.06.19 12:04, Henri Verbeet wrote:
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work. The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Henri
It's probably quite safe to say that the kernel itself will continue to support 32-bit executables, else Ubuntu's recommended solution of relying on the older 32-bit libs (or using runtimes) probably wouldn't work.
Creating some kind of PPA (doesn't have to necessarily be an "official" PPA on launchpad though, since they require packages to be source-built) is a good idea, it may be possible as well to just fetch the libs from Debian and putting them into the PPA.
Another solution aside from a PPA would be to just use the Debian repositories and pin the packages that are needed from there. This has been a solution to installing openjdk7 on Ubuntu >16.04, and it doesn't require maintaining a seperate PPA (relevant AskUbuntu answer outlining the process: [1]). However, while reducing the maintaining effort compared to a PPA, this would only be a better solution, if _all_ the needed packages can be used directly from Debian without conflicts or other issues.
[1] https://askubuntu.com/a/803616/702964 ("Option 2: Automatic Installation")
Tim
On 22.06.19 13:58, Tim Schumacher wrote:
Creating some kind of PPA (doesn't have to necessarily be an "official" PPA on launchpad though, since they require packages to be source-built) is a good idea, it may be possible as well to just fetch the libs from Debian and putting them into the PPA.
My first thought also was PPA. However, AIUI, it will not be possible to have an i386 PPA on Ubuntu/Canonical infrastructure, since they remove support for it completely. Also I'm quite sure that uploading binary-i386-packages to e.g. an amd64-PPA can not work.
i386 and amd64 multiarch libraries usually have to be completely in sync. So you can't "just" install the i386 libraries from Debian.
To provide 32-bit Wine as regular package I can't imagine any solution which doesn't involve maintaining a large part of the Ubuntu archive for i386, and providing the infrastructure to build and distribute it.
In Debian you have this done by very few, but dedicated people for the unofficial "ports" for e.g. m68k, or hurd and kfreebsd. Given that Debian still supports i386 this would be much easier for Ubuntu.
Greets jre
Le samedi 22 juin 2019 à 14:34 +0430, Henri Verbeet a écrit :
On Sat, 22 Jun 2019 at 13:15, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
There seems to be a trend where applications are distributed with all their runtime dependencies bundled, libraries, compatibility layers, etc.
Also sometimes referred to as "vendoring". Please don't do that.
Provided the Ubuntu kernels will continue to support 32-bit executables, and provided there's interest in the Ubuntu community to continue running Wine, I imagine it should be possible for a bunch of people in the Ubuntu community to get together and provide 32-bit builds of the required packages as a PPA or something. Although hardly ideal, I don't think there's a reason such an approach wouldn't work. The much easier option of course would be for the affected users to switch to a distribution that cares about Wine, Debian perhaps being the most obvious choice.
Henri
Hello,
I imagine a guest 32-bit (or 64-bit for WoW64) Debian (or any supported distro) could be installed in a (s)chroot environment, with all 32-bit dependencies, and use the graphical display provided by the host to run Wine. I guess it would still require 32-bit support on the kernel host though. Has anyone tried this with an existing 64-bit limited distro?
Unless there is a straightforward way to add 32-bit built-in emulation to Wine for everyone at once (it doesn't seem to be), it is obvious to me that, whatever the solution is, it should be maintained by the affected distros communities.
Regards.
-
Andrew Eikum -
Anna Lasky -
Bob Wya -
Dmitry Timoshkov -
Erich E. Hoover -
Fabian Maurer -
Gabriel Ivăncescu -
Henri Verbeet -
Jens Reyer -
Julius Schwartzenberg -
Olivier F. R. Dierick -
Rosanne DiMesio -
Sveinar Søpler -
Tim Schumacher -
Tim Schumacher -
Vincent Povirk (they/them)