Package Details: dunst-git 1.9.0.r3.g1ef38e5-1

Git Clone URL: https://aur.archlinux.org/dunst-git.git (read-only, click to copy)
Package Base: dunst-git
Description: A highly configurable and lightweight notification daemon
Upstream URL: https://dunst-project.org/
Licenses: BSD
Conflicts: dunst
Provides: dunst, notification-daemon
Submitter: None
Maintainer: pmattern
Last Packager: pmattern
Votes: 60
Popularity: 0.30
First Submitted: 2011-09-08 20:54 (UTC)
Last Updated: 2022-07-28 14:47 (UTC)

Required by (75)

Sources (1)

Latest Comments

1 2 3 4 5 6 .. 8 Next › Last »

xlucn commented on 2021-11-20 06:13 (UTC)

For *-git packages, there usually is a pkgver function that decides the package name from the latest commit information. The makepkg command will change the pkgver variable in PKGBUILD every time it's executed. So the version we see in this page is what the maintainer had when he updated last time, that doesn't prevent users to update to the latest git commit with makepkg command. It's quite common in AUR's git packages.

MithicSpirit commented on 2021-10-26 19:21 (UTC)

@JohnTheCF (replying to out-of-date flag) since this is a -git package it always pulls from the latest git commit, so the version reported is not the one that will be built by makepkg. If you wish to update, just clean up the folder and run makepkg -si again to pull the latest commit and rebuild.

That said, it would be nice if the version was updated to something such as latest or 0 in order to make it clearer.

TrialnError commented on 2021-10-20 18:45 (UTC)

The PKGBUILD needs to set SYSCONFDIR to fix the behaviour reported by MithicSpirit.
Also the make dunstify isn't needed anymore as dunstify is built per default since some months.

MithicSpirit commented on 2021-09-20 23:31 (UTC)

AFAIK the dunstrc template file should be in /etc/xdg/dunst/dunstrc rather than /usr/etc/xdg/dunst/dunstrc (dunst is the only program that owns /usr/etc/xdg/ on my system, while a myriad own /etc/xdg/).

frebib commented on 2021-06-25 21:36 (UTC)

This package is missing a makedepends on pod2man

==> Starting pkgver()...
==> Updated version: dunst-git 1.6.1.r52.g9f4f110-1
==> Sources are ready.
==> Making package: dunst-git 1.6.1.r52.g9f4f110-1 (Fri 25 Jun 2021 22:34:22 BST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting pkgver()...
==> Starting build()...
pod2man --name=dunst -c "Dunst Reference" --section=1 --release=v1.6.1-52-g9f4f110 docs/dunst.1.pod > docs/dunst.1
/bin/sh: line 1: pod2man: command not found
make: *** [Makefile:131: docs/dunst.1] Error 127
==> ERROR: A failure occurred in build().
    Aborting...
error making: dunst-git

mikau commented on 2021-01-25 21:00 (UTC)

libxdg-basedir should only be a make dependency, as it is not needed at runtime. It's not mentioned under the "Dependencies" section of the README, and checking with ldd reveals that it really isn't used.

alecmev commented on 2018-01-25 22:12 (UTC) (edited on 2018-01-25 22:17 (UTC) by alecmev)

Had the same issue with /usr/local/bin/dunst being invoked instead of /usr/bin/dunst after an upgrade, fixed by running systemctl --user daemon-reload. Why was it /usr/local in the first place? No clue, probably some now-addressed problem in the Makefile, which was previously resulting in the PREFIX override being ignored, and now isn't.

Foxboron commented on 2018-01-22 07:54 (UTC)

It is correct. I don't know what package you are using but i have built this thrice with makepkg and chroots after the initial report and the path is correct.

johnchen902 commented on 2018-01-22 04:32 (UTC)

/usr/lib/systemd/user/dunst.service contains the line

ExecStart=/usr/local/bin/dunst

which is clearly wrong. git show master:dunst.systemd.service.in shows

ExecStart=##PREFIX##/bin/dunst

so we should probably add PREFIX=/usr in build(), just like [community] dunst.

eschwartz commented on 2018-01-17 15:25 (UTC) (edited on 2018-01-17 15:26 (UTC) by eschwartz)

Technically this is fixing an old mistake :p by correctly delimiting the revision count as "not part of the version tag".

But it is true that this (by design) is incompatible with the old version scheme. There are two (sic) solutions:

1) Use an epoch

2) Wait until a new release before adding the "r".

3) Expect users to attempt to rebuild the git package, and manually "downgrade" the package when a different (but not new) version is built.

I've opted elsewhere to remove the "r" again, until pacman-git 5.1.x comes out.

1 2 3 4 5 6 .. 8 Next › Last »