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: 1.08
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 .. 12 Next › Last »

dreieck commented on 2023-09-23 10:25 (UTC)

using only the revision numbers is fine, it has been discussed here before with you https://aur.archlinux.org/packages/deadbeef-git?O=10#comment-852214

OK!, since it seems to be the wish of upstream developers.

Regards!

FabioLolix commented on 2023-09-22 19:42 (UTC)

@dreieck using only the revision numbers is fine, it has been discussed here before with you https://aur.archlinux.org/packages/deadbeef-git?O=10#comment-852214 (in my personal pkgbuild instead I have 1.9.5.r136.g1d9fd5abf now)

Your pkgver (1.9.5+136.r11421.20230915.1d9fd5abf) is IMO over-engineered, tag+revs + total revs + date, not what is suggested to do

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

Don't seem useful for this pkgbuild

Also sorry for not replying to previous 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?

git describe --long --tags [...] is enough until upstream badly mess with tags, then bumping epoch and moving on is fine

dreieck commented on 2023-09-22 19:27 (UTC) (edited on 2023-09-22 19:39 (UTC) by dreieck)

Ahoj,

the ↗ Arch Linux VCS packaging guidelines say that when a VCS software has an official version number available, then that should be used in the first part of $pkgver:

It is recommended to have following version format: RELEASE.rREVISION [...]. If there are public releases but repository has no tags then the developer should get the release version somehow e.g. by parsing the project files.

deadbeef-git has a "RELEASE" version available (1.9.5+136 or 1.9.6 currently, depending on the source):

  • grep -m1 -E '^[[:space:]]*[Vv]ersion[[:space:]]+[0-9]+' ChangeLog | awk '{print $2}': 1.9.6
  • git describe --tags: 1.9.5-136-g1d9fd5abf

So can you please change pkgver() to reflect that?

e.g.:

pkgver() {
  cd "${srcdir}/deadbeef"

  _ver="$(git describe  --tags | sed 's|^vV||' | sed 's|-g[0-9a-fA-F]*$||' | tr '-' '+')"
  # _ver="$(grep -m1 -E '^[[:space:]]*[Vv]ersion[[:space:]]+[0-9]+' ChangeLog | awk '{print $2}')"
  _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 yields 1.9.5+136.r11421.20230915.1d9fd5abf (of course you can also skip the .${_date} part, then the suggested pkgver() would yield your current versioning scheme, prepended with the upstream version. Latest commit date is only a convenience to easily see how old the currently installed version is.).

After having done so, you can also use an automativally always correctly versioned provides entry:

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

Regards and thanks for maintaining!

rekman commented on 2023-08-18 07:00 (UTC)

deadbeef provides tests, so it would be prudent to add a check(). the following will run the tests.

check() {
    cd "$srcdir/deadbeef"
    ./travis/download-linux-static-deps.sh
    ./scripts/test.sh
}

FabioLolix commented on 2023-07-12 14:31 (UTC)

Please add libpipewire to makedepends and optdepends https://aur.archlinux.org/packages/deadbeef#comment-909093

MarsSeed commented on 2023-06-03 12:52 (UTC)

Please kindly remove optdepend libsidplay.

The libsidplay v1.36.59 package has been deleted from the repos and not added to AUR.

But DeaDBeeF needs libsidplay2 as per configure.ac.

And the source tree includes the project's own fork of libsidplay v2:

The build process builds the internal libsidplay v2, even if libsidplay v1 is installed on the system.

MithicSpirit commented on 2023-04-02 19:39 (UTC)

automake is in base-devel, which is an implied dependency of all AUR packages.

Riedler commented on 2023-04-02 19:38 (UTC)

./autogen.sh: line 4: aclocal: command not found

please add automake to the makedeps

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.

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