Arch Linux User Repository

I would recommend against --skipinteg, it can be unsafe in case you accidentally get the wrong file (well, it's rare but...). Better is to download manually, check the hash(es) and edit hashes in PKGBUILD too.

If the .exe fails to download, you can manually edit the foobar version in PKGBUILD (with --menuedit and --mflags --skipinteg ; use at own risk!) to match the one on the official foobar2000 download page.

You may need to manually create ~/.local/share/wineprefixes/ if it does not exists.

If you can trust me, a user who has access to the server hosting the download:

fe7d84599c07fcf5bee099e89f78fba2942f612f06617ab203f80c9d9631db75  foobar2000_v1.6.3.exe

Hello, I'm getting the following error when trying to make the package:

➜  makepkg -si
==> Making package: foobar2000 1.6.3-1 (Fri 22 Jan 2021 08:29:45 GMT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found foobar2000_v1.6.3.exe
  -> Found LICENSE
  -> Found foobar2000.sh
  -> Found foobar2000.png
  -> Found foobar2000.desktop
==> Validating source files with sha256sums...
    foobar2000_v1.6.3.exe ... FAILED
    LICENSE ... Passed
    foobar2000.sh ... Passed
    foobar2000.png ... Passed
    foobar2000.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!

Where can I find the sha256sum for the latest version?

Checksum codes:

sha256
e5f983c12b2eda9c1e0bc6de95413005b61953be9bd1401398c5ba72713f23fd
foobar2000_v1.5.5.exe

sha256
ebf5582c2aee5819058e0d2df0ca0696dd2215d42a855b82eb136221ad74a8a2
foobar2000_v1.6_beta_5.exe

Doesn't work because this package assumes/requires v1.5.4 but in fact it does download v1.5.5 which somehow doesn't fit the directory structure and therefore breaks.

It's a pity because not only is that a great music program but also it installs WINE as a dependency in a way that allowed me to run Ableton Live 10 out of the box.

Sure, I get the reasons for it.

I just would've liked it to be optional, as you suggested (I think it was a good suggestion!). Or at least been a bit of a smoother transition.

This's borked my installation, and I've had to manually create the prefix to get it working, as well as go by someone else's chosen directory structure. Pretty annoying. This's the only thing I regularly use wine for, so--

Using unique prefixes per application is already good advice and frequently recommended by many wine using packages and launchers. Using a single default prefix for everything you install is a great way to find yourself frequently reinstalling everything.

I don't think hardcoding a path for the wine prefix is a good idea. Nor do I think forcing the use of a unique prefix is a good idea (it was suggested as optional).