Arch Linux User Repository

This was a somehow tricky update, as what was described as a simple bugfix update to the patches turned out to also include a stealth update to aoTuVb.03, leading to quite a few packaging changes that were not immediately clear.

Most notably, since the patch maintainer updated them without changing the file names, I had to find a way to force a redownload of the files for all users. I did it via a custom variable using the date of the latest patch update, using it to rename the files.

I suggest that this package move to enzo1982's Github repo as upstream so as to simplify maintenance, however that means either:

1. moving to a -git package, since he doesn't really make new releases (see also this post for why I hadn't done it so far; however I think this should not really be a problem with Arch VCS packages), or
2. doing a bit like libvorbis in the official repos, but using a specific commit ref as source instead of a tag. This could be an easy transition plan, although then we are then indeed subject to the risk of a force push for 1.3.8...

What do people here think about this issue?

Cheers

@arse More specifically, the key has expired:

==> Verifying source file signatures with gpg...
    libvorbis-1.3.7.tar.gz ... Passed (WARNING: the key has expired.)
==> WARNING: Warnings have occurred while verifying the signatures.
    Please make sure you really trust them.

However it is still the same one key that signed the source tarball (see the green checkmarks or the Verified label here).

Since it builds for me in a clean chroot and libvorbis from the official repo still contains the same key, I guess nothing will change until a potential future update. If you're not happy, you can just comment/delete it in your local PKGBUILD.

libvorbis-1.3.7-aotuv-b6.03-lancer-2021-05-10.patch ... FAILED

==> ERROR: One or more files did not pass the validity check! -> error making: libvorbis-aotuv-lancer

This was a somehow tricky update, as what was described as a simple bugfix update to the patches turned out to also include a stealth update to aoTuVb.03, leading to quite a few packaging changes that were not immediately clear.

Most notably, since the patch maintainer updated them without changing the file names, I had to find a way to force a redownload of the files for all users. I did it via a custom variable using the date of the latest patch update, using it to rename the files.

I suggest that this package move to enzo1982's Github repo as upstream so as to simplify maintenance, however that means either:

1. moving to a -git package, since he doesn't really make new releases (see also this post for why I hadn't done it so far; however I think this should not really be a problem with Arch VCS packages), or
2. doing a bit like libvorbis in the official repos, but using a specific commit ref as source instead of a tag. This could be an easy transition plan, although then we are then indeed subject to the risk of a force push for 1.3.8...

What do people here think about this issue?

Cheers

thanks a lot for the update!

Wow, thanks. I don't know how I could let one that slip. Of course we have to include the base package name in provides when we offer a modded version... This is not my first AUR package and I'm pretty sure I actually have already stumbled on that situation in the past, but for some reason this time it completely escaped me. I must be rusty :D

Anyway, thanks for your clarification, you are entirely right and I withdraw everything I said.

Cheers

Thanks for re-adding the dependency. Of course the official libvorbis package wouldn't explicitly provide itself, there would be no point. So just like -git-packages provide the name of the base package they are a development version of, the same needs to go for other variants.

I don't know offhand inhowfar it is intended that all depending packages should depend on the library names, currently at least gst-plugins-base, libcanberra and a few others don't. But as said that would be a different issue.

Hi @prettyvanilla, thanks for your report! I've just pushed an update which re-adds libvorbis to the provides array.

In my overhaul of this package I tried to get as close as possible to libvorbis in [extra], where they don't include it.

Which packages are affected/preventing the installation? Since the official package is configured this way (and has been for quite some time apparently), I'd expect packages depending on it to have either been fixed or discarded. If that's not the case, then please open a bug report for the concerned packages.

As this is really not something to nitpick over and seeing that it was included before I've re-included it, but those packages better get fixed before the next update comes in a few years ;)

Cheers

Thanks for the update!

Removing plain libvorbis from the provides prevents the resulting package from being installable unfortunately, as not all the (repo) packages have moved to depending on the .so-library names only (yet?).

I am working on an updated PKGBUILD but so far check() segfaults in test 4. See https://hydrogenaud.io/index.php?topic=115774.50

edit: it's been fixed with upstream, package update pushed and everything works now. Enjoy

1.3.7 patches avaiable here: https://hydrogenaud.io/index.php?topic=115774.0