Package Details: dwm 6.5-1

Git Clone URL: (read-only, click to copy)
Package Base: dwm
Description: A dynamic window manager for X
Upstream URL:
Keywords: dynamic tiling windowmanager wm X11
Licenses: MIT
Submitter: Foxboron
Maintainer: thule
Last Packager: thule
Votes: 38
Popularity: 0.039145
First Submitted: 2017-11-20 15:37 (UTC)
Last Updated: 2024-05-31 18:36 (UTC)

Latest Comments

1 2 3 4 Next › Last »

thule commented on 2024-06-02 11:53 (UTC) (edited on 2024-06-02 13:19 (UTC) by thule)

@ilf0 Thank you, it is my pleasure.

@AlgoJerVia That's OK we are all here to learn.

But I don't understand what you mean by that it should be done in vanilla upstream.

It means that anything that the main project (dwm) deals with via external patches is not supported here neither in the source code nor in the scripts. The reasons for this are the ones that me and @ilf0 explained below.

My main concern as a maintainer is to provide something that works always reliably (and in the same way). Adding support to the patches means loosing some of this control in ways that can be unpredictable (e.g. you might apply patches in a different order from me and what works for you doesn't for me and vice versa).

Let me know if you have further concerns on the topics, happy do address them.



AlgoJerViA commented on 2024-06-02 08:22 (UTC)

@ilf0 @thule To be honest I have not given this as much thought as you have. I guess for a more mainstream program than DWM the patches would be modules that would be compiled as their own packages so another AUR package is probably reasonable.

But I don't understand what you mean by that it should be done in vanilla upstream. As far as I understand it, the intention with the patches on the DWM page is not that they should ever be merged into the vanilla source (like we would expect from most other projects) since there is a philosophy of keeping the source small for the sake of smallness.

ilf0 commented on 2024-06-01 11:33 (UTC)

@thule: Thanks for taking over as maintainer, and thanks for providing 6.5!

@AlgoJerViA: I agree that having the option for patches is nice-to-have. But I agree with thule that the AUR package should not do this.

The very first Arch Principle sais:

Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided.

It is absolutely legitimate to patch dwm. But that can and should be done in vanilla upstream sources, or a second AUR package - not this one.

thule commented on 2024-06-01 07:58 (UTC) (edited on 2024-06-01 07:58 (UTC) by thule)


Ok, I still stand by my reasons I explained in my previous post. But if there is enough consensus feel free to propose a patch, I am happy to consider it.



AlgoJerViA commented on 2024-05-31 19:41 (UTC) (edited on 2024-05-31 19:41 (UTC) by AlgoJerViA)


The code I posted was just what I'm using right now without to much thought put into to. What would be optimal is if PGKBUILD would look for patches added manually by the user, perhaps in an optional sub folder.

Thus if someone just downloads the PKGBUILD and don't do anything else no patches would be applied. Only if the user goes the extra step to manually add patches somewhere.

Sure, I and I think most other people that want's to apply patches has no problem solving it but it would just be for convince. I think it is a very common scenario in the same way as having the custom config.h.


thule commented on 2024-05-31 18:48 (UTC)

Updated to 6.5-1. It seems working well.

Please let me know,


thule commented on 2024-05-28 10:25 (UTC) (edited on 2024-05-28 10:42 (UTC) by thule)

@AlgoJerVia: Thank you for your suggestion.

I considered adding a mechanism for automatic patching but then decided against proposing it for the following reasons:

  • Patches are optional as per suckless philosophy.

  • There is no guarantee that patches for dwm work nicely together (some of them require manual intervention) hence any automation would potentially result in people requesting support here for inconsistent behaviors of the installation script.

  • Support the widest possible audience as per Arch philosophy and there are people who do not use patches at all (minor: and that do not want to execute extra code to build the package).

Said that, the approach I am personally using to keep track of patches is to have a git repository that tracks upstream on which I applied the patches I use and a script that uses yay to install the package and then replaces the source with the one in my personal repo (using dwm-git is better, you can use git remote add, git rebase) and rebuilds the package. Let me know if you are interested, I can clean the script up and share it.



AlgoJerViA commented on 2024-05-28 05:55 (UTC)

I would like the person taking charge of this to add the possibility of adding patches. Perhaps something like this:

prepare() { local file cd "$pkgname-$pkgver"


for file in "${patches[@]}"; do if [[ "$file" == .h ]]; then cp "$srcdir/$file" . elif [[ "$file" == .diff || "$file" == *.patch ]]; then echo "Applying patch $(basename $file)..." patch -Np1 <"$srcdir/$(basename $file)" fi done }

I was planing on doing it myself but since you want the ownership I suggest it here.

thule commented on 2024-05-23 09:23 (UTC) (edited on 2024-05-23 13:49 (UTC) by thule)

I mailed the mainteiner 3-4 weeks ago and raised a request almost 2 weeks ago to orphan this package and dwm-git.

I am thinking to step up as a maintaner for both the packages if no one claims them.

I am on holiday at the moment but I have a local patch that updates dwm to 6.5. My plan is to send it out next week once I get back home.

Please let me know if this works for you.

ilf0 commented on 2024-05-23 09:14 (UTC)

Upstream released 6.5 two months ago:

I mailed the maintainer and the three contributers. The email address Contributor: Grigorios Bouzakis <> does not exist any more.