Arch Linux User Repository

The package is now updated to 6.8. Please let me know if everything works correctly. Thanks!

Ah and Enjoy! ^__^

The package is now updated to 6.8. Please let me know if everything works correctly. Thanks!

Ah and Enjoy! ^__^

Upstream released version 6.8, 2026-01-30

Upstream released version 6.7 three weeks ago: https://dl.suckless.org/dwm/dwm-6.7.tar.gz

Would be great to get this into AUR. The patch is pretty simple (just the incremented version number and the checksum).

Thanks!

Seems the extra config.h in the sources here is not needed because that file is created in the Makefile by copying the config.def.h . I ran into this while trying out one of the alt tab patches.

The package is now updated to 6.6.

Enjoy!

@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.

Thanks,

Thule

@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.

@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.

https://wiki.archlinux.org/title/Arch_Linux

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.

@AlgoJerViA

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.

Thanks,

Thule

@Thule

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.

//AlgoJerViA