<mbakke>pkill9: I know Hartmut Goebel has done some work on KDE. Perhaps you can ask on guix-devel?
<castilma>hey folks: I would expect sh to print only files starting with uppercase letters in $ echo [A-Z]*; (at least dash on debian does), but our sh(bash) doesn't care about the case. is that correct sh behaviour?
<dustyweb>I'm not sure if it's a problem with my hard drive or just a bug or some screwup on my end (again)
<dustyweb>also, another question! I started running gnome again, and I found that the screen brightness change tool asks me for my password every time I try to change the brightness
<dustyweb>I wonder if anyone has figured out how to make that not the case ;)
<janneke>dustyweb: i'm using emacs-wm ... to change brightness i write an integer to /sys/class/backlight/intel_backlight/brightness ... but that only works if i did a chmod 666 /sys/class/backlight/intel_backlight/brightness since reboot
<mbakke>dustyweb: I've never seen such an error from GRUB (reading outside hd0).
<mbakke>I use `xbacklight` to change brightness (in i3).
<dustyweb>mbakke: yes my fear is that the reading outside hd0 one really might be a hardware problem
<dustyweb>it's hard to imagine what else it could be
<dustyweb>mbakke: xbacklight weirdly seems to do nothing on this machine... not sure why
<snape>roptat, vagrantcish: if the service configuration file is /etc/something.conf, then you can reconfigure without stopping it, and restart it later, /etc/something.conf will be changed and the service will apply the new configuration. But! If the service reads the configuration as in service -c /gnu/store/something.conf, then it won't work and you'll need to stop it before reconfiguring.
<vagrantcish>and then, even after rebooting, i'v eclearly just botched the configuration.
<snape>? you rebooted and the configuration doesn't apply?
<ng0>I have a mixture of "proper" DMs using their own way to set brightness, and my brightness script, which just writes the brightness as integer.
<ng0>civodul: nix and guix have both 3 letters for the leading part of the store-path. in theory 5 letters wouldn't lead to too many problems with path lengths I think? I've only hit this once when I gave gnunet versions unfornate long names and package-versions
<zybell>snape:daemon reload:Isnt it better the new daemon would start 'unconfigured' , read the config (Problem->exit),connect to 'configured' daemon, talk for switch,go 'configured'. So even an update of the daemon is possible.
<zybell>jtojnar:plugin:as I analyse it you need 3 (small) packages per extension point: 1) path package,provides a symlink into /run for link to package 3. 2) contract package,depends on 1,provides an output that explains the way the packages are linked,computer readable (script or lib),human readable good to have,all expanders depend on it. 3)point package, depends on 2) and 1), imports the list of all *reverse* dependecies of 2) as deps into a
<zybell>dir.sets the /run link to that dir and provides (via its dep on (1) )a way to access that plugin dir in the hosts. The hosts depend on 3).
<ng0>whatever 3 letters. yes. sorry, last week was hard.
<vagrantcish>though, there are some non-bootstrappable things in debian that require previous versions of itself and such ... so ... maybe that's not a blocker
<vagrantcish>ACTION also looks forward to the mescc bootstrapping
<zybell>snape:the 'unconfigured' daemon should not run like a normal daemon,only after switch to 'configured' the new daemon handles clients the way the old one would have. But after that switch,the old one is out of the pic, because it is informed of the switch and goes exit after redirecting its clients to the new one (or having none by not accepting conns anymore).
<civodul>vagrantcish: yeah i'm thinking Rust, OpenJDK, etc.
<civodul>it's just less visible or more commonly overlooked in these cases
<snape>zybell: but you can't be sure the new one works unless you run it right? And you can't run it unless you stop the other one... So there must be a short period of time with no daemon running.
<vagrantcish>civodul: so, once you have guix, can you build the next guix without the bootstrap binaries?
<snape>or maybe I don't understand how the unconfigured daemon would run
<zybell>Oh 'unconfigured' and 'configured' are run states, not fs states.
<snape>You can imagine a daemon that needs a exclusive access to a database (/var/run/database). Two daemons can't access it at the same time, so only one can run.
<snape>zybell: so what you say might work for some daemons, but not for all. So it's not really generic.
<zybell>snape:the old daemon needs the lock till switch,till switch the new daemon accesses the db through the old daemon. After switch the old daemon accesses the db through the new daemon and the new daemon has exclusive xs. And the idea was for nix-daemon only not generic.
<snape>oh, I thought you were talking about generic mechanism
<snape>I believe the solution has to be work for all daemons, because guix-daemon isn't the only one to have this "issue".
<zybell>no update for guix daemon running its *service* whole time. But it could be made generic too, now that you made me think about it.