Package Details: deadbeef-git r11790.7d26d35fc-2

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: zlib, GPL-2.0-or-later, LGPL-2.1-or-later
Conflicts: deadbeef
Provides: deadbeef
Submitter: archtux
Maintainer: ToadKing
Last Packager: ToadKing
Votes: 122
Popularity: 0.022490
First Submitted: 2009-08-21 13:16 (UTC)
Last Updated: 2025-03-31 06:46 (UTC)

Required by (45)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »

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.

Vaporeon commented on 2021-12-20 02:14 (UTC)

Would it not make sense to just drop the libblocksruntime dependency in this package?

MountainX commented on 2021-09-30 23:37 (UTC)

@MithicSpirit-thank you. I learned a few things. I didn't elaborate on my specific issue but I'm attempting to build this package in a clean chroot and the script I'm using for that must be making an incorrect assumption... I'll sort out my issue. But I actually asked the question because I saw a discussion by others having a problem with this package for this exact reason. I thought I knew what their issue was. Now I see I was wrong. Thanks for taking the time to help me learn.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »