Package Details: dunst-git 1.6.1.r13.g3acffdb-1

Git Clone URL: https://aur.archlinux.org/dunst-git.git (read-only, click to copy)
Package Base: dunst-git
Description: Lightweight and customizable notification daemon
Upstream URL: https://dunst-project.org/
Licenses: BSD
Conflicts: dunst, dunstify
Provides: dunst, dunstify, notification-daemon
Submitter: None
Maintainer: mackilanu
Last Packager: mackilanu
Votes: 60
Popularity: 1.20
First Submitted: 2011-09-08 20:54
Last Updated: 2021-04-02 14:33

Required by (59)

Sources (1)

Latest Comments

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

mikau commented on 2021-01-25 21:00

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

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

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

/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

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.

CyberShadow commented on 2018-01-17 15:18

Foxboron: please take the time to understand the problem. -git or no -git, your PKGBUILD still broke the versioning scheme, which is affecting pacman, not the AUR helper.

Foxboron commented on 2018-01-17 15:15

This is a -git package. A propper AUR helper should be checking the git repo for new revisions. If that isn't the case, the responsibility to update -git packages falls on the user. An epoch is not going to be added.

CyberShadow commented on 2018-01-11 03:03

Hi,

I noticed that the pkgver scheme changed recently.

Before: 1.2.0.103.953.ga257556-1

After : 1.2.0.r223.gf7cf5b6-1

Unfortunately, the new scheme seems to be "older" than the old one, as far as pacman's version comparison algorithm goes. So, AUR helpers will think that new packages are older than old ones.

You may want to address this by using a new epoch in the PKGBUILD: https://wiki.archlinux.org/index.php/PKGBUILD#epoch

TrialnError commented on 2018-01-06 21:07

Upstream repo contain tags, but the pkgver is chosen for tagless repos?

Nevertheless, the reason why I wanted to comment: Upstream dropped gtk3 hard dep and relies instead on gdk-pixbuf

Edit: Oh, and there seems now a libxrandr dependency

haawda commented on 2017-12-20 09:33

I fixed the pkgver, and I orphan this package. The guideline is too stupid.