***Rukako_ is now known as Rukako
<pkill9>is there progress being made anywhere on getting KDE desktop environment packaged in guix? <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? <civodul>we had a good time, interesting discussions with the IT folks, and a great visit of the datacenter <civodul>i had already visited datacenters, but this one is like no other i think :-) <mbakke>I heard at least one cluster will be trying out Guix. <civodul>one of the people we talked too looked very interested, but i wasn't sure they'd try it right away :-) <civodul>but regardless, people knew the issues around deployment very well, they had experience with various other tools, and so we had a "common language" <mbakke>You must have made some impression! :-) <mbakke>civodul: Yes I've been there once. Snuck in at their hostel, heh. <mbakke>Fun place to roam around at night! Everything is open once inside.. <civodul>i had a good impression of a lively & friendly place <civodul>with the cafeteria open till midnight <civodul>plus people coming from all around the world <mbakke>Yeah I got the same impression. Seems like a great place to work. <civodul>although Geneva prices must be hard to deal with <mbakke>Coming from Norway, it's just like home! :P <civodul>rekado: did you make it back home? :-) <dustyweb>I asked in here earlier but gonna re-ask... <dustyweb>does anyone know where the "Monospace" and friends fonts come from? <civodul>and then font-dejavu, font-gnu-freefont-ttf <civodul>mbakke: did you look into making a gcc@8 packaeg? <mbakke>civodul: I think efraim is on the case. <efraim>Sorry, I haven't been able to take a good look at it <efraim>One of the patches didn't apply cleanly and I didn't get a chance to look at it yet <civodul>we could send relocatable packs of gcc@8 so the whole world can try it out right away <dustyweb>let's see if that fixes the problems I was having <dustyweb>not a problem with a package in the store! <dustyweb>btw, a question to others booting from a fully encrypted disk: <dustyweb>do you sometimes have problems where it says it tries to read outside of hd0 or whatever and just fails and you have to retry a few times? <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 <efraim>Clearly the answer is to switch to enlightenment, we (I) have working brightness! <janneke>efraim: why increase brightness when you have enlightenment? <civodul>bavier`: i was looking at updating Open MPI to 3.0 <civodul>however test suite of packages that use it fail, unless "ssh" is in $PATH <civodul>adding OpenSSH as a dependency solves it, but it doesn't sound right <bavier`>civodul: oh, nice! I had planned on looking at that next week. <bavier`>hmm, I have seen something similar before <bavier`>I think there are some environment variables that can be set to adjust behavior <bavier`>civodul: I ran into the same issue a while back during an attempt to upgrade openmpi to the the 2.* series <bavier`>adding openssh "solves" the problem, but the real issue is that the previous behavior no longer works. <bavier`>i.e. openmpi in 1.* seems to not require ssh or rsh when running on the local machine <bavier`>^ those env vars may eliminate some sporadic test failures in mpi-using packages <civodul>bavier`: wait, the "oversubscribe" var disables use of ssh? <pkill9>does anyone find the berlin build server a little temperamental in offering substitutes? <bavier`>civodul: no, that's another thing, sorry <pkill9>often guix will start buildign from source, then a bit later (without completing the build process) it gets substitutes <davexunit>license compliance certainly is an issue when you just mash together a bunch of disk images! <davexunit>civodul: also, what a cool picture of you and rekado at CERN! <civodul>pkill9: "without completing the build process" sounds unlikely :-) <bavier`>maybe we should more aggressively advertise GuixSD as a container-based distro <civodul>pkill9: what happens though is that 'guix publish' "bakes" substitutes on the first request <pkill9>civodul: i mean i cancel the build process <civodul>so that's what i had in mind: you cancel the build process, and in the meantime 'guix publish' is done preparing the substitute you asked before, so you can download it <civodul>given enough users that's unlikely to happen to any given person, i think, but it can always happen <civodul>or it can happen for less popular packages, etc. <civodul>bavier`, davexunit: i couldn't resist so i posted a comment there <civodul>i'm glad people are thinking about the issue <pkill9>does it build everything that's updated, and then reprioritise on the fly when a request is recieved for a substitute? <civodul>pkill9: substitutes are created only after someone asked for them <vagrantcish>is there a simple way to have "guix gc" not remove transitive dependencies for all the live objects? <bavier`>vagrantc: there's a daemon option for that <bavier`>vagrantcish: `guix-daemon --gc-keep-derivations=yes --gc-keep-outputs=yes` <vagrantcish>bavier`: and that marks them to not be used for garbage collection until the depending packages are garbage collected? <bavier`>until the corresponding outputs are dead <vagrantcish>which leads to the next question ... where do i enable --gc-keep-* ? <vagrantcish>does %desktop-services effectively include %base-services? <vagrantcish>i'm struggling with what to pass to guix-configuration ... <vagrantcish>(guix-configuration (extra-options "--gc-keep-derivations=yes --gc-keep-outputs=yes")) <vagrantcish>/home/vagrant/config/config.scm:106:69: Wrong type to apply: "--gc-keep-derivations=yes" <bavier`>vagrantcish: what you pass to 'extra-options' should be a list <bavier`>vagrantcish: see e.g. it's use under "system services" in section 6.2.1 of the manual <vagrantcish>so, to ask the most rudimentary beginner question ... how do you pass it as a list? :) <bavier`>(extra-options '("--gc-keep-derivations" "--gc-keep-outputs")) <bavier`>yeah, quoted like that, or (list "--gc-..." "...") <vagrantcish>seems to have worked ... now there are numerous other guix-configuration options i've been meaning to set <vagrantcish>is it possible to retroactively mark, say, the current system build and all it's inputs as not garbage-collectible? <bavier`>vagrantcish: see the '--root' option for 'guix system build' <vagrantcish>i was able to run guix system reconfigure with the new configuration, but guix-daemon doesn't seem to be running with the new arguments <vagrantcish>even after herd stop guix-daemon ; herd start guix-daemon <vagrantcish>if i try to configure guix-configuration from %desktop-services, it builds the system fine, but the daemon doesn't actually pick up the options. <vagrantcish>if i try to enable it as part of %base-services , i get a huge traceback <bavier`>vagrantcish: how are you checking that the new options are being honored? <vagrantcish>doesn't appear to show either --gc-* option and shows the default --substitutes-url= default <roptat>you need to reboot first I think <roptat>no because you restart the old configuration of that service <vagrantcish>that is certainly confusing, but i guess i've seen it work for other things <roptat>sometimes it can reload the service but I don't fully understand what the conditions are <roptat>when I change a service configuration, I stop the service before the reconfigure, and it restarts with the new configuration <roptat>it doesn't do it if the service is running <roptat>but that may depend on the service <roptat>anyway you can't stop guix-daemon <roptat>but then you can't build anything <vagrantcish>for the record, "herd stop udev" is yet another way to crash your system <vagrantcish>after a reboot, the daemon is still using the default subsistutes <vagrantcish>given that i have very minimal understanding of this, it's entirely possible i'm configuring this entirely wrong... <vagrantcish>the example from Base-Services for configuring udev apparently edits the %desktop-configuration <bavier`>vagrantc: have you tried a 'guix build' or similar command to see which substitute urls are queried? <vagrantcish>yes, and it's not using the substitutes i think i've configured <snape>roptat, vagrantcish: well, you can stop guix-daemon, and start one manually <snape>and after reconfiguring, you stop the one manully started... <snape>on my computer it's faster than rebooting :p <vagrantcish>ACTION is not used to rebooting just to restart services <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? <snape>hmm the modify-service line seems commented... <vagrantcish>well, it should be applying to the %desktop-services in that case <vagrantcish>but no, i am not sure if i can apply it to %desktop-services <vagrantcish>i have very little understanding of what is normal, in this context :) <snape>it's not part of %desktop-services <snape>let's find the list of %desktop-services :p <vagrantcish>when i try to use %base-services, it goes very badly. oddly enough, the udev rule, which appears to be documented in base-services, works when applied against %desktop-services <roptat>%desktop-services contains %base-services <roptat>I don't understand why your configuration doesn't work <vagrantcish>even when i specify "guix build --substitute-urls= ..." sometimes it still downloads *some* things from the default substitutes <snape>vagrantcish: does ps auxww | grep guix-daemon return the correct command? <snape>And the guix system reconfigure didn't error out? <mbakke>I don't think the new daemon configuration takes effect before a reboot. <snape>or the first reconfigure failed :p <vagrantcish>or i ran system build instead of reconfigure ... or a few other problems. <vagrantcish>is there a bug about being able to restart guix-daemon without rebooting? that's really non-intuitive <snape>so to avoid breaking services when reconfiguring <snape>but yes, there is a plan to improve it <snape>that could be executed during reconfiguring <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 <civodul>it'd be only two more letters, indeed <civodul>but i don't expect us to change said letters in the near future :-) <ng0>I know^^ I'm asking for my side of things. so both 3 letters were just a coincidence :) <ng0>keep it short, anyways <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. <civodul>vagrantcish: it would be a good solution for Guix on Debian too, but... <ng0>vagrantcish: it's not a simple change, and after the code is changed, basically everything has to be rebuild. <bavier`>ACTION feels they're missing some context <vagrantcish>ACTION gets the impression nearly everything gets rebuilt pretty often <vagrantcish>civodul: but yeah, that was the main thing i was thinking ... if it's ever going to have support on Debian out of the box, /opt seems an appropriate place for it. <ng0>sorry, not everything. bootstrapp binaries are without store references iirc <ng0>vagrantcish: Whonix asked me the same, if we couldn't just switch to /opt <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. <civodul>vagrantcish: though i wonder if user namespaces could allow us to sidestep the whole issue <ng0>first result says "compiled in, but disabled by default" <ng0>grep for "user namespace" <civodul>"Debian disables unprivileged user namespaces by default." says the DSA above <civodul>vagrantcish: there's a /sys knob in addition to the build-time option <vagrantcish>i was definitely using user namespaces for lxc on a debian system at one point <civodul>it could be that installing lxc turns it on or something <snape>zybell: but running two daemons in the same time is sometimes impossible <vagrantcish>civodul: even if it's not enabled by default, it's a single-line configuration-file change to enable that feature <civodul>right, so a Debian package for Guix could do that i suppose <civodul>there could be a global /opt/guix that some command would remap to /gnu/store <snape>zybell: and unless the new daemon runs, I don't know a sure way to check its configuration <civodul>vagrantcish: a big hacky i admit, but hey! <vagrantcish>last i looked, there were a few blockers from making a package available in Debian ... guile-git and maybe guile-ssh <civodul>a handful of packages may be missing <vagrantcish>when building from git, does it still require the bootstrap binaries? <ng0>those are always required. <civodul>in a way they're treated as "source" <civodul>although i look forward to the day where we have real source instead <vagrantcish>yeah, i think that might also be a blocker for inclusion in Debian officially <ng0>works for other systems though <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. <civodul>vagrantcish: it's not Guix itself that depends on the bootstrap binaries, it's the packages that Guix builds <zybell>snape:I want to run it but not as (nix)daemon <civodul>vagrantcish: to put it differently, the whole package graph needs to have a root, and bootstrap binaries are that root <snape>zybell: but that might be impossible in some cases <snape>yes, but it both daemons require the same lock it won't work <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. <zybell>ACTION is afk for a bit, explains later <snape>ACTION is going to sleep because he is exhausted