AUR (en) - deadbeef-git

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: deadbeef-git r10944.4469d86c7-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/deadbeef-git.git (read-only, click to copy)
Package Base:	deadbeef-git
Description:	A GTK+ audio player for GNU/Linux (devel branch)
Upstream URL:	https://deadbeef.sourceforge.io/
Licenses:	GPL2, zlib, LGPL2.1
Conflicts:	deadbeef
Provides:	deadbeef
Submitter:	archtux
Maintainer:	ToadKing
Last Packager:	ToadKing
Votes:	117
Popularity:	0.44
First Submitted:	2009-08-21 13:16 (UTC)
Last Updated:	2022-09-29 03:49 (UTC)

rekman commented on 2022-09-18 11:08 (UTC) (edited on 2022-09-18 11:11 (UTC) by rekman)

Since the 1.4.0 update to the flac package the artwork and flac plugins need to be rebuilt. Arch now provides libflac.so.12 instead of libflac.so.8. Run make clean in the plugin/artwork and plugin/flac directories in the source tree then makepkg again.

rekman commented on 2022-08-23 13:50 (UTC)

@dreieck

Is it guaranteed that the upstream author increments the 1.8.8-774, which is returned by git describe --long --tags every time, by e.g. either incrementing the 774-part, or incrementing the version number and setting the 774-part to zero?

Yes, this is exactly what git describe ensures. The 1.8.8 means the last tag reachable from this commit is 1.8.8. The 744 means we are 744 commits ahead of that tag. This is calculated fully automatically from the git history. It is not a manually set counter. Why the hell would it be? It requires no further work on the part of the author apart from tagging. As long as tags are monotonically increasing this version number will be, too.

ToadKing commented on 2022-03-03 05:14 (UTC)

@Riedler Fixed, forgot to put it in makedeps.

Riedler commented on 2022-03-02 21:03 (UTC)

Could you please use ffmpeg 4.4 to build the ffmpeg plugin until ffmpeg 5.0 is supported? Thanks.

ToadKing commented on 2022-02-17 00:01 (UTC)

When I talked with the deadbeef dev, his opinion that the master branch should not derive any specific version number. So I'm probably gonna keep the PKGBUILD as it is. I'll bump up the provides version on official releases.

dreieck commented on 2022-02-16 23:19 (UTC) (edited on 2022-02-16 23:22 (UTC) by dreieck)

Dear FabioLolix,
thanks for your comments!

I have some understanding questions regarding your last post:

@dreieck the for a pkgver that use git tags can be simply used:

git describe --long --tags | sed 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

Which give:

pkgver=1.8.8.r760.ge2d06eb99

Does that guarantee monotoneously increasing version numbers?

Just right now, the thing above would give 1.8.8.r774-gc7aba967e, while git rev-list --count HEAD gives 10828.

That means, that there are currently 10828 commits in the history. That's much larger than 774. Is it guaranteed that the upstream author increments the 1.8.8-774, which is returned by git describe --long --tags every time, by e.g. either incrementing the 774-part, or incrementing the version number and setting the 774-part to zero? The author can forget just one time, and then all that version numbering stays the same, the git commit hash changes, but this is random so a newer "version" can have a lower $pkgver. That's why I always add the commit count.

Is that not needed? What guarantuess that the output of git describe --long --tags is always monotoneously increasing with every commit?

provides=("deadbeef=${pkgver}")

Adding =${pkgver} is pointless, (@MithicSpirit $pkgver will be resourced at every build)

I am courious why! I see packages that have version restrictions in their dependencies (a constructed example: depends=('deadbeef>=1.8'), and the =${pkgver}-part would make this dependencies resolve correctly.

But I noticed that recently the AUR web pages do not display the version of the provides anymore even when this is added. Could it be that nowadays pacman does implicitly assume some =${pkgver}?

Don't forget to increment $epoch when changing the versioning scheme.

No, epoch= need to be incremented when the builded package have an inferior version, which is not happening in this case.

You are right, thanks!

FabioLolix commented on 2022-02-12 18:46 (UTC)

@dreieck the for a pkgver that use git tags can be simply used:

git describe --long --tags | sed 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

Which give:

pkgver=1.8.8.r760.ge2d06eb99

See https://wiki.archlinux.org/title/VCS_package_guidelines#Git

provides=("deadbeef=${pkgver}")

Adding =${pkgver} is pointless, (@MithicSpirit $pkgver will be resourced at every build)

Don't forget to increment $epoch when changing the versioning scheme.

No, epoch= need to be incremented when the builded package have an inferior version, which is not happening in this case

MithicSpirit commented on 2022-02-12 18:38 (UTC)

@dreieck Wouldn't changing the provides to that make it always use the hardcoded pkgver variable (currently r10008.c87e3e11a) rather than the output of the function? Or does makepkg have a way of re-sourcing the PKGBUILD while filtering out the pkgver variable?

Other than that seems like a good change.

dreieck commented on 2022-02-12 17:47 (UTC) (edited on 2022-02-12 17:56 (UTC) by dreieck)

Actually, the official software version can easily be retrieved in pkgver().

So, according to the VCS packaging guidelines, I suggest changing the pkgver() function such to provide it.

As an example, here is mine:

pkgver() {
  cd "$srcdir/deadbeef"

  _ver="$(git describe --tags | sed 's|^[vV]||' | sed -E 's|\-g+[0-9a-f]*||' | tr '-' '+')"
  _rev="$(git rev-list --count HEAD)"
  _date="$(git log -1 --date=format:"%Y%m%d" --format="%ad")"
  _hash="$(git rev-parse --short HEAD)"

  if [ -z "${_ver}" ]; then
    error "Version could not be determined."
    return 1
  else
    printf '%s' "${_ver}+r${_rev}.${_date}.${_hash}"
  fi
}

which currently produces 1.8.8+760+r10814.20220212.e2d06eb99.

Having applied such change, you could also change the provides entry to the following automatic:

provides=("deadbeef=${pkgver}")

Don't forget to increment $epoch when changing the versioning scheme.

Thanks for maintaining!

ToadKing commented on 2021-12-20 02:29 (UTC)

libblocksruntime is required to run deadbeef, and although not possible in AUR currently you can technically use libblocksruntime without libdispatch. Any issues with dependency resolution should be handled by the other packages IMO.

Arch Linux User Repository