Package Details: deadbeef-git r11509.b6c2bc326-1

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: 121
Popularity: 0.085666
First Submitted: 2009-08-21 13:16 (UTC)
Last Updated: 2023-11-11 22:15 (UTC)

Required by (41)

Sources (1)

Latest Comments

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

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.

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.

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