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

Dependencies (55)

Required by (45)

Sources (1)

Latest Comments

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

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.

MithicSpirit commented on 2021-09-30 23:28 (UTC) (edited on 2021-09-30 23:32 (UTC) by MithicSpirit)

@MountainX Just did some testing with a localrepo+docker and pacman does manage this correctly, so the issue you're experiencing is likely with your AUR helper. The results are as follows:

  • If I attempt to directly install deadbeef-git then pacman does installs libdispatch and not libblocksruntime (no error);
  • If I install libblocksruntime first, then deadbeef-git pacman gives me the following prompt :: libdispatch and libblocksruntime are in conflict. Remove libblocksruntime? [y/N]. Responding "n" errors and exits (as expected), and responding "y" removes libblocksruntime before installing deadbeef-git and libdispatch (no further warnings/errors);
  • If I attempt to install both libblocksruntime and deadbeef-git at the same time pacman states warning: removing 'libblocksruntime' from target list because it conflicts with 'libdispatch' and continues installing deadbeef-git and libdispatch but not libblocksruntime (no further warnings/errors).

MithicSpirit commented on 2021-09-30 23:08 (UTC) (edited on 2021-09-30 23:08 (UTC) by MithicSpirit)

As far as I know, if the libblocksruntime pkg was removed from AUR, it would give your PKGBUILD a dependency which cannot be satisfied, right? So either way, this PKGBUILD, in its current form, is going to give an error.

~@MountainX

If you're using makepkg (which is the official way to install stuff from the AUR) then it will always give a warning since it does not check the AUR for dependencies afaik. As for AUR helpers, it will depend on whether or not that specific helper checks the provides array when looking for dependencies; in the case that it does check provides, it will find that libdispatch does provide libblocksruntime and likely not run into an error.

Also, I just checked your output again and it doesn't seem like it was necessarily an error and rather just a prompt on whether you want to remove the other package (if it did error out maybe you need to pass/unpass a flag to allow interactive input).

ToadKing commented on 2021-09-30 23:00 (UTC)

@MountainX The dependencies can still be satisfied without the libblocksruntime package. libdispatch provides libblocksruntime so all the dependencies will still work. The version of the runtime it builds is in the libdispatch source: https://github.com/apple/swift-corelibs-libdispatch/tree/main/src/BlocksRuntime

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