On Sat, Jul 03, 2021 at 04:03:07PM +0300, Peter Pentchev wrote: > Control: tag -1 confirmed upstream patch pending > > On Sat, Jul 03, 2021 at 01:39:49PM +0200, xiscu wrote: > > Package: kakoune > > Version: 2020.01.16-2 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > i'm currently unable to use kakoune as it gives a Permission denied error > > on start > > (reinstalling the package hasn't solved the problem). The programm worked > > for me, > > but currently i get: > > > > Fatal error: unable to bind listen socket '/run/user/1000/kakoune/3781950': > > Permission denied > > Hi, > > Yes, you did stumble into an upstream kakoune bug that is fixed in > a later upstream release that is not in Debian yet. The problem is that > Kakoune determines the name of a "user-specific directory to put some > stuff in" using your desktop environment's idea of a "user-specific > directory to put some stuff in", i.e. the XDG_RUNTIME_DIR environment > variable that is set upon the start of your GUI session. However, if you > *first* run `sudo kak something` (and you have told sudo to preserve > the environment variables!) or `su kak something` (and su, by default, > does preserve the environment variables), as the first thing you do > after restarting your computer, before running Kakoune as yourself, > then Kakoune will create its own directory while running as root, and > the directory will not be writable by your actual user account. > So if later you run it from your user account, it will not be able to > put stuff into that directory. This has happened with other tools, too, > and this is actually part of the reason why sudo does NOT preserve all > the environment variables by default. (Note: I'm not saying "don't use > su, use sudo!"; I'm just saying "su does some weird things by default, > sudo tries to prevent some problems by doing *other* weird things by > default, and it is not always the better choice, but it does help > prevent *some* problems") > > I will test and adapt the patches for this problem...
FTR, just to have it out there before I upload the bugfix version, the patches in question are: https://github.com/mawww/kakoune/commit/7751c7e188bfc7b2f7e4a70e33032677d84597e5 https://github.com/mawww/kakoune/commit/db9ef82398a08bdf985ff26bfb230fb0cd1221a5 > ...but in the meantime, > a short-term solution for your current situation is: > > 1. Make sure the problem is what I think it is: > > ls -ld /run/user/1000/kakoune > > ...and check that it is owned by "root", not by your user account > > 2. Change its owner to your user account: > > sudo chown "$(id -un):$(id -gn)" /run/user/1000/kakoune > > or, if using su: > > su -c "chown '$(id -un)' /run/user/1000/kakoune" ...arrgh, *of course* this should have been: su -c "chown '$(id -un):$(id -gn)' /run/user/1000/kakoune" Sorry about that! Although it would work with just the username, too, since Kakoune would still be able to write into an owner-writable directory. > ...of course, you can put your account's username and groupname > directly instead of the "$(id -un):$(id -gn)" construct :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
