Package Details: libvorbis-aotuv-lancer 1.3.7-3

Git Clone URL: https://aur.archlinux.org/libvorbis-aotuv-lancer.git (read-only, click to copy)
Package Base: libvorbis-aotuv-lancer
Description: The Vorbis library with aoTuV and Lancer patches
Upstream URL: https://hydrogenaud.io/index.php?topic=115774.0
Keywords: codec music sound transcode
Licenses: BSD
Conflicts: libvorbis, libvorbis-aotuv
Provides: libvorbis, libvorbis.so, libvorbisenc.so, libvorbisfile.so
Submitter: Soukyuu
Maintainer: neitsab
Last Packager: neitsab
Votes: 10
Popularity: 0.000036
First Submitted: 2015-09-10 17:56 (UTC)
Last Updated: 2021-05-16 22:57 (UTC)

Dependencies (1)

Required by (542)

Sources (4)

Pinned Comments

neitsab commented on 2021-05-16 23:17 (UTC) (edited on 2022-03-04 15:03 (UTC) by neitsab)

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

Latest Comments

neitsab commented on 2022-03-18 14:31 (UTC)

@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.

arse commented on 2022-03-18 09:56 (UTC)

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

neitsab commented on 2021-05-16 23:17 (UTC) (edited on 2022-03-04 15:03 (UTC) by neitsab)

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

salamander commented on 2021-03-23 10:15 (UTC)

thanks a lot for the update!

neitsab commented on 2021-02-26 23:34 (UTC) (edited on 2021-02-26 23:34 (UTC) by neitsab)

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

prettyvanilla commented on 2021-02-24 03:31 (UTC)

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.

neitsab commented on 2021-02-23 20:11 (UTC) (edited on 2021-02-23 20:32 (UTC) by neitsab)

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

prettyvanilla commented on 2021-02-23 02:59 (UTC)

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?).

neitsab commented on 2021-02-20 04:03 (UTC) (edited on 2021-02-22 19:00 (UTC) by neitsab)

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

salamander commented on 2020-07-06 11:10 (UTC)

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

Soukyuu commented on 2017-11-14 18:41 (UTC) (edited on 2017-11-14 18:42 (UTC) by Soukyuu)

desbma, checksums match for me. Have you deleted your cached copies of the source files? makepkg does not re-download the files if they are already present.

desbma commented on 2017-11-13 15:38 (UTC)

When updating to b6.03-8 I get an error because the hash of libvorbis-aotuv_b6.03_2015-lancer.patch is invalid

Soukyuu commented on 2017-11-11 11:41 (UTC)

My bad, the only other package I maintain is a -git one, so the version takes care of itself. Thanks for reminding me.

gabor_zoka commented on 2017-11-11 01:44 (UTC)

Could you bump up pkgrel? I would like to be in line with official AUR, but the right way is to bump it after every change. I had to bump in my copy otherwise I run into upgrade issues. I maintain several PC-s and I cache old versions to reduce downloads. The issue is that in my repo now I have a new build, but I pick the old versions via cache due to release number did not change. Cheers, Gabor

Soukyuu commented on 2017-10-26 18:00 (UTC)

I've updated the checksum now that the author has fixed the patch to work for both shared and static builds. Compiles and passes tests here.

neitsab commented on 2017-10-18 15:53 (UTC) (edited on 2017-10-18 16:14 (UTC) by neitsab)

After updating the pkgsums to match the update to the first patch done on 20161217 (reason for which I flagged the package out-of-date), I stumbled upon a build error that seems linked to the update: gcc: error: xmmlib.o: No such file or directory However it works if we remove the "--disable-static" option in configure. Problem reported upstream in the reference thread.