IRC channel logs


back to list of logs

<civodul>Hello Guix!
***Rukako_ is now known as Rukako
<civodul>heya Rukako
<catonano>hi civodul !
<pkill9>is there progress being made anywhere on getting KDE desktop environment packaged in guix?
<mbakke>Hi civodul, how was Geneva? :)
<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>mbakke: it was awesome!
<civodul>our host says "hi" to you :-)
<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>civodul: Sounds great! :-)
<mbakke>I heard at least one cluster will be trying out Guix.
<civodul>oh, already?
<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! :-)
<civodul>heh :-)
<mbakke>That's great.
<civodul>castilma: i'd expect the same, FWIW
<civodul>mbakke: did you visit CERN already?
<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>(and serving beers :-))
<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>oh, i can imagine :-)
<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>heya dustyweb!
<civodul>'gsfonts' contains basic fonts
<civodul>well, 'gs-fonts'
<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>thank you civodul
<dustyweb>let's see if that fixes the problems I was having
<dustyweb>I fixed my fonts issue
<dustyweb>it was a fontconfig cache issue
<civodul>dustyweb: woohoo, good!
<dustyweb>not a problem with a package in the store!
<dustyweb>yes, I'm very relieved
<civodul>it's better this way indeed
<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've been finding that to be the case
<dustyweb>from Grub, that is
<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
<jlicht>hi guix
<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>namely, i get things like:
<civodul>does that ring a bell?
<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`>trying to find my notes..
<civodul>cool :-)
<bavier`>civodul: now I recall
<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`>civodul: btw, I have this link in my notes:
<bavier`>^ those env vars may eliminate some sporadic test failures in mpi-using packages
<civodul> & <- on containers and license compliance
<davexunit>that was a funny xkcd
<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>if only there was some other way...
<davexunit>civodul: also, what a cool picture of you and rekado at CERN!
<civodul>davexunit: heheh :-)
<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
<pkill9>ah ok interesting
<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?
<pkill9>i worded that badly
<civodul>pkill9: substitutes are created only after someone asked for them
<civodul>see --cache at
<pkill9>ah ok
<civodul>rekado: did you see ?
<civodul>that's old, actually
<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: ^
<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>that sounds perfect
<vagrantcish>which leads to the next question ... where do i enable --gc-keep-* ?
<vagrantcish>finally found it
<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`>vagrantc: np :)
<vagrantcish>bavier`: yeah, i've been reading that section ...
<bavier`>(extra-options '("--gc-keep-derivations" "--gc-keep-outputs"))
<vagrantcish>heh. i was literrally just trying that :)
<bavier`>yeah, quoted like that, or (list "--gc-..." "...")
<vagrantcish>ah, i had tried 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>pgrep -l -a -f guix-daemon
<vagrantcish>doesn't appear to show either --gc-* option and shows the default --substitutes-url= default
<roptat>you need to reboot first I think
<vagrantcish>you can't just restart the service?
<roptat>no because you restart the old configuration of that service
<vagrantcish>even after reconfiguring to the new system?
<roptat>I think so
<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
<vagrantcish>otherwise i can't build the new one
<vagrantcish>well, i was able to stop guix-daemon
<roptat>but then you can't build anything
<vagrantcish>ok, well, let's see if a reboot works
<vagrantcish>but if i've already built it ...
<vagrantcish>or does switch-generation require guix-daemon
<bavier`>I believe it does
<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
<vagrantcish>er, %desktop-services
<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>that seems involved :)
<vagrantcish>ACTION is not used to rebooting just to restart services
<snape>ACTION neither
<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>what service is it?
<vagrantcish>near the bottom
<snape>hmm the modify-service line seems commented...
<snape>sure it's normal?
<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
<vagrantcish>it's all magic to me at the moment
<roptat>%desktop-services contains %base-services
<roptat>I don't understand why your configuration doesn't work
<snape>oh right
<snape>here is the list
<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?
<vagrantcish>guix-daemon ... --substitute-urls
<vagrantcish>and none of the --gc-* arguments
<snape>And the guix system reconfigure didn't error out?
<mbakke>I don't think the new daemon configuration takes effect before a reboot.
<vagrantcish>i just ran it and can reboot again
<vagrantcish>well, will reboot again...
<vagrantcish>ACTION waves
<vagrantc>ACTION can keep an eye on irc
<vagrantcish>ok, the second reboot worked
<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>it's a feature
<snape>so to avoid breaking services when reconfiguring
<snape>it would be too dangerous
<snape>but yes, there is a plan to improve it
<snape>to add a "reload" feature
<snape>that could be executed during reconfiguring
<vagrantcish>ok, just another one of those quirks
<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
<civodul>yep :-)
<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.
<vagrantcish>ACTION notes that /opt/guix would be even shorter
<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
<ng0>but FHS...
<vagrantcish>filesystem hierarchy standard?
<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>/opt/guix would be pretty compliant with FHS
<zybell>sorry channel seems wrong
<civodul>vagrantcish: though i wonder if user namespaces could allow us to sidestep the whole issue
<civodul>does Debian enable them by default?
<ng0>first result says "compiled in, but disabled by default"
<vagrantcish>civodul: i *think* so ... any quick way to check?
<ng0>grep for "user namespace"
<vagrantcish>civodul: CONFIG_USER_NS=y in the kernel
<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
<zybell>yes channel was wrong
<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
<vagrantcish>ah, added it to sysctl at boot on that machine
<civodul>oh i see
<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
<vagrantcish>or at least require it
<vagrantcish>but then each user would have their own store?
<civodul>not necessarily
<civodul>there could be a global /opt/guix that some command would remap to /gnu/store
<civodul>(through user namespaces)
<snape>zybell: and unless the new daemon runs, I don't know a sure way to check its configuration
<snape>(that is generic)
<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>oh right, these...
<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>yes, see
<civodul>in a way they're treated as "source"
<civodul>although i look forward to the day where we have real source instead
<civodul>ACTION looks at janneke et al. :-)
<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.
<snape>well, yes, but still
<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
<zybell>it goes daemon if all is good
<snape>yes, but it both daemons require the same lock it won't work
<vagrantcish>civodul: right.
<zybell>what does that lock protect?
<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