AFAICR, Canonical had intended to remove 32bit support "Apple-style" (including kernel-level multiarch support), but it faced huge backlash (even from Valve, that threatened to ditch Ubuntu completely) and was forced to maintain limited sub-set of 32bit libraries (how exactly limited? what if the infamous "libssl.so.1.0.0" and "libcrypto.so.1.0.0" will not be among those libraries?). Even if multiarch still exists, there are no guaranties an application will launch due to missing libraries.

It is easier for GOG to just drop Linux support, considering now it has a plausible excuse.
Seriously?
So, are you going this path of denial? Come on!

How many times we urged developers complaining about huge number of distros to just target Ubuntu and users of other distros will just adapt (because they know what they are doing and can manually install missing libraries)?
With Ubuntu all of its offspring (or "flavors") and bastards (like Mint) will sink too because of common kernel and general inability to maintain custom repositories for missing libraries.

And if not Ubuntu, then which is next on the list? Arch? ARCH!!!
A rolling-release "do it yourself" family without any solid "set in time" set of libraries and environment, but with "I use Arch, BTW" community of users with bright personalities and NTSC (Never Twice the Same Configuration).

This is literally the embodiment of production development hell, where by the time a developer releases its product targeting library X said library changes 23 times breaking API in the process and no user is capable of answering a simple question of "What did you update?" after a game that worked yesterday does not work anymore (because of "rolling release").

Using "popular" distros was the pitfall of such approach to begin with. They should use the distro that does the job. Other distors can adjust if needed. Ubuntu doesn't do the job? Use something else, like Debian, openSUSE or whatever else.

hullo, Jasper

It certainly *feels to me* like they already dropped it, just letting it rot along. (if there are some guys in GOG working hard on the linux part, sorry, but I'm describing how it looks from the outside)

To me it looks like they pushed Linux support to some low paid contractors. The Bard's Tale IV release problems were almost anecdotal.

To install the chroot, you can just use a tool like debootstrap (for Debian and Ubuntu chroots). To allow non-root use of the chroot, there's schroot.

Do you have some evidence for you reasoning or are you just throwing out hypotheticals, 'cause fearmongering is always so much fun :/
I'm pretty certain Canonical never said anything about dropping kernel-level support for 32bit. So solutions like flatpak, snaps or other containerization, or 3rd-party repositories for 32bit packages were(are) always still a possible solution.

Your idea that they would declare openssl a nonessential package is frankly absurd.
They also did a decent job in involving the community, re-addeding packages when somebody asked for it.
https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility

Seems total nonsensical to me to make such a panic about it at this point. As far as gaming is concerned, things will largely be the same on 20.04 as they were on 18.04.

There is of course always the chance that some dependency is not available anymore because it's too old and therefore dropped from the repository(32bit & 64bit). But that's not a new problem.
hmm, what exactly are the problems you are having?
I might have a skewed perception of the problem due to my small(ish) library, but for me things work more or a less as good/bad as they always have.
It still is (and always was) a low-level effort, but it still provides me with playable games.
I can't really see a notable drop in quality specific to the linux packaging.

Easy, pal! No need for strong words. I'll let this accusation slip this time, but I didn't like it one bit.

And as for your request for source material… Please, consider this:
1) 20 June 2019: initial news on 32 support dropping;
2) 22 June 2019: Valve's response/threat to Canonical;
3) 24 June 2019: Canonical's desicion to "…build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS".

And I admit that yes, the initial 32bit support removal was ambiguous: Canonical did say there would be other means to restore support via 3rd party effort, but it was left hanging in the air as to which ones. After all, one could just substitute Canonical's 64bit exclusive "mainline" kernel with multiarch-capable patched one. And we won't know this as the plans were postponed for now (at least till 22.04 arrives).

Yes, ignorance is bliss. I was referring to libssl1.0.0_1.0.2n-1ubuntu5_amd64.deb explicitly. An outdated library with "heartbleed" vulnerability. It was expelled from most of the distros, but was still present in Ubuntu 18.04 and you would be surprised how many games on GOG actually require this exact library:
1) "Undertale", "VA-11 Hall-A: Cyberpunk Bartender Action" and other games on this engine;
2) The Red Strings Club
3) Surviving Mars;
4) Hyper Light Drifter;
5) Mable & The Wood (LOL! This one is already for Ubuntu 19.04);
6) Risk of Rain;
…
last one) even "X4: Foundations" requires this (albeit they promised to remove this dependency).
The list goes on endlessly (just google "libcrypto.so.1.0.0 site:https://www.gog.com"). :)

What are the chances Ubuntu will contain 32bit version of outdated and confirmed-vulnerable security library?

right, but the important bit of quote is this: "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."
So the argument that Canonical might be mean to us and simply decide to exclude an important package doesn't really hold much ground I think. well, the same chance they will keep the 64bit version. ==> Zero. Nada. Null. ;)
Upstream support for that branch of openssl ran out in the beginning of the year iirc, so the package got dropped for 20.04.
For 32bit and for 64bit.
This is the problem that I mentioned at the end of my post. But it has nothing to do with the whole discussion about phasing out 32bit support. This problem about closed-source software depending on some outdated, no longer available library is with us since the dawn of time for linux gaming ;)
remember libpng12 ? :p

apologies if my tone put you off, I just find it incredibly irritating and frustrating when people so quickly jump to drastic conclusions. In the end, nothing has really changed so far in practice. It puzzles me how one can come to the conclusion that it would be better to drop linux support altogether.

side note:
i am fairly certain the openssl package(1.0.2n) is young enough to never have been affected by heartbleed. Didn't that only affect the 1.0.1* branch?

For Undertale, I just run the Windows version under WINE; chances are the other games using that engine would also work well that way.

Of course, I question why a single-player game needs an encryption library, especially since it's one of those libraries that has been known to break ABI compatibility.

How can I tell if a game is native or uses wine on the gog store page? Anyone know?

I must respectfully reject the proposal, as I did not pay GOG for a Windows™ game and expect proper support.
Supplying the needed libraries manually seems to be a better idea.

And speaking of WINE…
Normally, it is stated in the "system requirements" part of the game page (see attachment) as is in case of "Flatout 2".

./play.it provides the missing library for Undertale, in addition to dependencies handling and a required workaround to avoid a crash on AMD GPU: Install Undertale on Linux

Sorry, I'm a proud Fedora user, so I must reject your offer also. :) But worry not, I have my 32bit copies of libraries backed up on my RAID1 HDD and know how to use LD_PRELOAD in a script. :D

Besides, I did not give you money for your support for the game, then why it is you who are trying to help customers and not GOG's technical support or Linux packaging department?

Thanks. Also I am assuming anything that mentions things in the "other" section are also wine? For example sometimes it mentions things like libc6:i386, etc

btw do you know how gog determines if they sell a native version vs a wine version?