Suggest: A warning period before EAPI/similar break overlays

[mmogilvi]

I use the wine overlay to install an older slotted version of wine, since 7.x causes CD check failures in an older game I like to play (Warcraft 2 BNE).

Today I did a full update (both main and wine overlay), and started getting a ton of major error messages about EAPI=6 no longer supported (plocale.eclass?), stemming from the wine overlay. As a user, this contrasts poorly to when a package is last-rited, where at least there is a period of a month or two when emerge warns about the masked package, but it is still trivial to temporarily work around it with an unmask while you determine a longer-term solution. I vaguely remember similar breakage of official overlays and/or my own self-maintained ebuilds in the past.

I realize it isn't practical to keep supporting old EAPI's, eclasses, etc indefinitely. But could developers at least provide something like a "last rite" type transition period before disabling an API or eclass completely, particularly if it is likely to be used by official and/or non-official overlays? Perhaps temporarily add a visible but ignorable "eerror" to the relevant eclass/EAPI case for a month or two first, instead of suddenly just leaving an unconditional "die"? Then overlay users have some time to alert the overlay maintainer and/or help update ebuilds and/or decide on other solutions, instead of suddenly the ebuilds are completely non-functional...

[Ionen]

Note the wine overlay is dead, as such nothing will get fixed on it. The repo is just kept for historical purposes.

Edit: Also, while I generally agree for dropping e.g. EAPI=7 from a general use eclass, EAPI=6 is a different story because it's been deprecated for ~1.5 years now (causing warnings with pkgcheck and such), people may not act on it but can't say haven't been warned. Dropping support for something that's deprecated isn't something to be surprised about.

[rab0171610]

As an experiment, you could also consider modifying the ebuild yourself and bringing it up to date, keep a copy in your local repository (not your gentoo repository), and install it that way. In one circumstance, simply changing EAPI=6 to EAPI=8 was enough. However, it was a simple ebuild that only copied a file to the system, so that may not be sufficient in your case. You can also have a look at:
https://devmanual.gentoo.org/eclass-ref ... index.html
I haven't read the particular ebuild you are referring to, but maybe you can modify it to add the relevant plocale stuff if it is complaining that it is missing from the ebuild. It would be interesting to experiment with at least. You might learn something in the process.

Read an up-to-date ebuild for wine and compare the two. If both ebuilds use the variable ${PV} correctly and download from the same wine git repo for example, it might be as simple as renaming the newer ebuild to download an older version of wine, instead of the most recent.
https://wiki.gentoo.org/wiki/Creating_a ... _an_ebuild

[Ionen]

In-tree up to date wine ebuilds were rewritten from scratch and won't have much in common with the older ones (old ones are also incompatible with current eselect-wine). Actually had pondered using these to restore wine-6, but the dependencies and options are rather different from 7 given a major move to PE files and ended up leaving it alone. wine-7.0.1 will be kept likely for as long as it works after wine-8 is out though.

May want to try if any of the current wine versions work better before messing with old versions (a lot of the old ones are broken with current glibc and/or gcc too), not sure which "7" you tried but 7.0.1 and 7.22 are rather different (7.22 is essentially wine-8 that's about to come out), app-emulation/wine-proton could potentially fare better too.

[rab0171610]

Another thing to consider would be using Bottles as a flatpak. If you are skilled enough you can install some of the dependencies from source and build it yourself. Otherwise, the flatpak version should work for most use cases. It is basically just a GTK wine front end. All dependencies (vcredist, d3dx9, d3dcompiler, etc) can be installed easily in the GUI, as well as various runners (wine, wine-ge, proton versions etc.) It is easy to use and there is nothing that I have not been able to run in it from Red Dead 2, GTA, and small freeware games from 20+ years ago. You can pick which version of windows and then change it easily. You might need the abi_x86_32 global use flag in your make.conf. I have been able to get everything running in 64 bit gaming prefixes with almost no additional configuration, including all 32bit programs. You don't need any wine package installed on the gentoo system because it is done through the application.
If you would rather not use flatpak and wanted to build it from source, be aware that it is only officially supported as a flatpak for some reason. The benefit of tthe flatpak is the sandboxing from the system.
I got a general sense of the runtime and build dependencies as well as the build instructions from reading the PKGBUILD file from the Arch linux community repo bottles package, which is not a flatpak. The packages that were not in the gentoo repos, I just built from source.
Something to consider.

[mmogilvi]

I just tried wine-vanilla-7.22 and wine-proton-7.0.5, but they still cause Warcraft 2 to fail the CD check. I had previously tried vanilla 7.0, 7.0.1, 7.9, and 7.13 without success. My old install of wine-vanilla-6.0.2 from the overlay still works for now, but who knows for how long, especially given all the dependencies wine has...

I described the problem last July in an upstream forum at https://forum.winehq.org/viewtopic.php? ... 368e8a99eb, but the single reply was not useful.

I'm not aware of any version older than 7 that didn't work; the game had been working in wine for well over a decade. It might be nice to try a few larger minor versions of 6 to try to narrow down when it broke, but now with the EAPI=6 thing, that does not appear to be easy.

I guess I'll either need to give up on this game, or dig a lot deeper into debugging what changed in handling CD iso files in 7, or figuring out how to update an old very large ebuild to EAPI=8, or some other solution (flatpack?).

----

Kind of late now, but what is the best strategy to be notified about things like no-longer-maintained overlays (I hadn't realized until today that the wine overlay was considered dead), or unknowingly still using features like EAPI=6? I happened to already accidentally "know" EAPI=6 was being slowly retired by stumbling over comments in bugs and forums when looking for other things, but haven't seen an "official" announcement or actual timeframes/plans, nor do I know the best practice for scanning / discovering if there is an imminent problem looming ahead of time for any out-of-tree ebuilds I happen to be using... Are there suggestions documented somewhere? (Hence the suggestion I started this thread with.)

In the case of the wine overlay, it doesn't help that https://github.com/gentoo-mirror/wine still seems to be getting new commits every couple of weeks; the latest was just two days ago (on the Dec 27th), and I sometimes saw such updates when doing "emerge --sync". Maybe some automated process is still blindly trying to keep it synchronized with the main gentoo tree or something? Also, the 2017-11-21 "eselect new" item about old wine versions moving to the overlay is still present when other many similarly aged news items have been removed, although I probably wouldn't have noticed it missing unless it had went missing before I needed old versions. I noticed the game failing this last July, just a month or two before the commit that added some text to overlay.xml's description about it no longer being updated, which I didn't notice until today. (I vaguely assumed that at some point wine-6 ebuilds might disappear from the overlay when/if they became too difficult to keep, rather than the overlay being abandoned completely. I was hoping that if that happened, there would still be enough lead time to dig deeper, if newer versions still didn't work...)

[rab0171610]

Dig a lot deeper. Many people claim to play this very old game without a cd. "How to play Warcraft 2 WITHOUT CD" returns a lot of results. Maybe do a little research and see what you come up with.

[Hu]

Bypassing the game's copy prevention is not the point of this thread. The copy prevention happens to be the motivating problem, but it could as well have been "Game hangs when starting a map." Either way, OP wants to keep the game working either by being able to continue to use the known-good Wine version indefinitely, or by finding and getting fixed the problem that makes newer Wine versions bad.

Typical advice for a readily reproducible problem like this would be to git bisect the offending program to identify a specific bad commit (not just a bad release) - though that assumes you can actually build all the versions you want to test, which may not be the case yet.

[rab0171610]

I wrongly assumed it was abandoned software. I was wrong. The good news is the game only cost 7.99 these days. Maybe consider it a small investment and get an updated downloadable version that is not CD based. Maybe it is worth the investment vs. the time spent troubleshooting wine versions? Obviously, you would want to first research if people can successfully play it on more recent releases of proton/wine, etc.

[diem]

I agree with the OP about emerge providing a warning ahead of time (or perhaps a news article?) of an EAPI deprecation/removal. I ran my weekly emerge update today and suddenly have two packages spitting errors because they rely on EAPI 6 & 7 respectively. I don't use pkgcheck so didn't get a warning that way. I'm not complaining BTW - both packages are in overlays that see only occasional maintenance - but it was still a bit of a surprise

[mmogilvi]

For the wine/game problem I went ahead and bisected and further analyzed the underlying problem and some possible solutions, which I've written up in an upstream bug report: https://bugs.winehq.org/show_bug.cgi?id=54243.

For debugging wine in gentoo specifically, in case anyone else wants to bisect and track down their own regressions, here are some quick tips:

• Be sure to read and understand https://wiki.winehq.org/Building_Wine.
• Install a similar version of wine normally with emerge, just to get the dependencies.
• Copy and customize the script below, which can help with consistently following the multi-step build procedure every time you change something.
• No need to "install" the build(s); just invoke "/PATH/TO/b32-SUFFIX/wine PROGRAM" (if using something like my script).
• Wine probably has a lot of debugger and logging options. I didn't quickly find any documentation for how to configure and use them, so I just fell back on using the "FIXME()" printf-like function for quick-and-dirty debugging, which seems to be enabled by default. The debugstr_*() functions use a kind of round-robin buffer internally, rather than a single static buffer, so it is generally fairly safe to use them multiple times in one print statement...

The script:

Code: Select all

#!/bin/sh

die()
{ echo "ERROR: $*" 1>&2
  exit 1
}

condPause()
{
  echo "$1"
#  read wait
}

#################

skipCfg=
suffix=
while [ x"$1" != x"" ] ; do
  case "$1" in
    --skipCfg )
      skipCfg=1
    ;;
    -* | "" )
      die "Usage: $0 SUFFIX"
    ;;
    * )
      suffix="$1"
    ;;
  esac
  shift
done

if [ x"$suffix" = x"" ] ; then
   die "Missing suffix argument"
fi

#################

PATH="/usr/lib/mingw64-toolchain/bin:$PATH"

base="$(dirname "$0")"

( b="b64-$suffix"
  d="$base/$b"

  CROSSCC="x86_64-w64-mingw32-gcc"
  export CROSSCC

  if [ ! -d "$d" ] ; then
    mkdir "$d" || die "mkdir $d"
  fi
  cd "$d" || die "cd $$d"
  statFile=errorCode.$$
  if [ x"$skipCfg" = x"1" ] ; then
    if [ ! -r "config.status" ] ; then
      die "$d has not been created/configured"
    fi
  else
    #condPause "Press enter to configure $d"

    ( ../wine-src/configure --enable-win64 2>&1
      echo "$?" > "$statFile" ) | tee "../${b}.cfgOut"
    if [ x"$(cat "$statFile")" != x"0" ] ; then
      die "configure in $d"
    fi
  fi

  condPause "Press enter to build $d"

  ( make -j6 2>&1 ; echo "$?" > "$statFile" ) | tee "../${b}.bldOut"
  if [ x"$(cat "$statFile")" != x"0" ] ; then
    die "make in $d"
  fi
) || die "build 64"

( b="b32-$suffix"
  d="$base/$b"

  CROSSCC="i686-w64-mingw32-gcc"
  export CROSSCC

  if [ ! -d "$d" ] ; then
    mkdir "$d" || die "mkdir $d"
  fi

  cd "$d" || die "cd $d"

  statFile=errorCode.$$
  if [ x"$skipCfg" = x"1" ] ; then
    if [ ! -r "config.status" ] ; then
      die "$d has not been created/configured"
    fi
  else
    condPause "Press enter to configure $d"

    ( ../wine-src/configure --with-wine64=../b64-$suffix 2>&1
      echo "$?" > "$statFile" ) | tee "../${b}.cfgOut"
    if [ x"$(cat "$statFile")" != x"0" ] ; then
      die "configure in $d"
    fi
  fi

  condPause "Press enter to build $d"

  make -j6 2>&1 | tee "../${b}.bldOut"
  ( make -j6 2>&1
    echo "$?" > "$statFile" ) | tee "../${b}.bldOut"
  if [ x"$(cat "$statFile")" != x"0" ] ; then
    die "make in $d"
  fi
) || die "build 32"

----

With that, the main thing that remains for this thread is the original question: What is the best way to (notice/detect/be alerted) ahead of time that you are unknowingly using things (overlays, EAPI's, eclass's, etc) that are planned to stop working "soon", before they actually stop working? (Of course, you can't do much about "unplanned" breakage.)

[rab0171610]

I can't speak to specifics of your last question. I have not had any issues except for a notice that one package I depend on will be dropped from the gentoo repo soon as it is using EAPI 6, has not been updated in several years, and is not widely used.

In the case of the wine overlay, my understanding is that version of wine in question, while older, is still supported by the Gentoo Wine project.
The ebuilds in the wine overlay were initially said to still be supported by the project in the original notice sent out on 11-21-2017:

To reduce the burden on main Gentoo repository, older versions of Wine
will be available only in the wine overlay. These ebuilds will still be
fully supported by the Gentoo Wine Project.

I would consider contacting them regarding the wine version in question and the outdated ebuild that is depreciated. The contact details are available here:
https://wiki.gentoo.org/wiki/Project:Wine

[Ionen]

In the case of the wine overlay, my understanding is that version of wine in question, while older, is still supported by the Gentoo Wine project.
The ebuilds in the wine overlay were initially said to still be supported by the project in the original notice sent out on 11-21-2017

It's not, that news item was removed, I removed the overlay from repositories.xml listing, and the overlay's last commit marked it deprecated and also notes it's no longer being updated.

There may still be some outdated information to be found, but there's not currently anyone willing to maintain such a large amount of ebuilds in the wine project and will just stick to keeping a few major versions in the main repo to handle regressions (albeit as mentioned in an earlier post, unlikely will revisit <wine-7 given rather different to handle and won't work with current ebuilds, it'd also need backports for a few fixes as some USEs are known broken by now).

[rab0171610]

. . .but there's not currently anyone willing to maintain such a large amount of ebuilds

I think that is completely understandable.
Thank you for the clarification re: the wine overlay.

[Hu]

For the wine/game problem I went ahead and bisected and further analyzed the underlying problem and some possible solutions, which I've written up in an upstream bug report: https://bugs.winehq.org/show_bug.cgi?id=54243.

Well done. With regard to the content of the bug report, I believe that other Blizzard games (Diablo, Starcraft) have as part of their CD check that the free space on the "CD" drive must be exactly 0, or it will not be considered a valid CD. I expect Warcraft 2 has the same requirement, so your step 6 / step 7 in the bug report seem correct to me. If Wine returns filesystem information for the filesystem containing the ISO, rather than the filesystem from inside the ISO, then it will almost certainly report free space greater than 0, causing the game to fail the test.