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.163677
First Submitted: 2015-09-10 17:56
Last Updated: 2021-05-16 22:57

Dependencies (1)

Required by (518)

Sources (4)

Pinned Comments

neitsab commented on 2021-05-16 23:17

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](https://hydrogenaud.io/index.php?PHPSESSID=hua8eqsp85v6idv7u7gps1e7i4&topic=115774.msg994173#msg994173) 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

1 2 Next › Last »

neitsab commented on 2021-05-16 23:17

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](https://hydrogenaud.io/index.php?PHPSESSID=hua8eqsp85v6idv7u7gps1e7i4&topic=115774.msg994173#msg994173) 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

thanks a lot for the update!

neitsab commented on 2021-02-26 23:34

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

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

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

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

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

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

Soukyuu commented on 2017-11-14 18:41

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

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