IRC channel logs


back to list of logs

<joshuaBPMan>maybe this is a issue that is cause by dual booting and sharing /home with both arch and guixSD.
<cbaines>very possibly,
<cbaines>as with many things in guix, follow the symlinks
<cbaines>where does ~/.guix-profile point to?
<joshuaBPMan>.guix-profile -> /var/guix/profiles/per-user/joshua/guix-profile
<cbaines>ok, and are you using GuixSD at the moment, or Arch?
<joshuaBPMan>GuixSD at the moment.
<joshuaBPMan>My current guix install is about 43 days old.
<cbaines>so, I'm imagining that /var/guix isn't shared between the two systems?
<joshuaBPMan>"/home" is the only way they are shared.
<cbaines>do you share /gnu/store between the two systems?
<cbaines>ah ok
<joshuaBPMan>they both have different root partitions.
<joshuaBPMan>I'll can write out my /etc/fstab if you want.
<cbaines>so... as your profiles are stored in /var/guix ... and in the store, I'd expect that you'd get different profiles when booting in to the different OS's
<joshuaBPMan>actually I only have guix installed on GuixSD. I don't have guix installed on Arch.
<joshuaBPMan>My arch root directory is only 20GB and it's about 70-80% full already.
<joshuaBPMan>I had guix installed on it before, but it took up too much room after I installed packages.
<joshuaBPMan>so now Arch does not have guix.
<cbaines>ok, does /usr/local/var/guix exist on your GuixSD system?
<joshuaBPMan>actually no...
<cbaines>that's good
<cbaines>I've got confused between the two in the past (as in /var/guix and /usr/local/var/guix) which has caused profile wieidness
<joshuaBPMan>ok. I'll remove bash from my /etc/config.scm, after my guix pull finishes, then I'll try reconfiguring.
<joshuaBPMan>then I'll see if I still have my old packages.
<cbaines>I'm pretty sure that your user profile should survive doing guix system reconfigure, but I'm not sure why it doesn't, perhaps when it's empty again, try and do some debugging or ask in IRC
<cbaines>with the new guix, you might get a better error message, so you might want to try with bash still in your profile
<Apteryx>OK, to answer my interrogations about what are the new buttons about "hide buttons and reveal hidden elements", those are caused by the newly integrated add-on in Icecat "Reveal hidden HTML". The usefulness of this add-on is to reveal parts of sites which would have been left hidden because of Javascript blocked by LibreJS. In other words, unless you are using LibreJS, this add-on is probably more annoying than
<joshuaBPMan>ok. reconfigure worked. I'm rebooting.
<joshuaBPMan>ok I guess I was wrong. It seems that my user profile of packages are still there after a reconfigure.
<joshuaBPMan>That's always good.
<oriansj>I really think we should add some functions to guixsd that would allow a user with a broken guix to recover reasonably. (say the ability to import a program pack made by guix)
<joshuaBPMan>not to be a debbie downer, but have ya'll heard about the recent gnome programs that are switch to the meson build system only?
<joshuaBPMan>I don't believe that guix supports that build system yet...right?
<davexunit>is it just me or is really slow right now?
<davexunit>it's like it's on a dial-up connection
<davexunit>downloading at a blazing 23KiB/s
<happy_gnu[m]>davexunit: I am downloading at 344kib/s
<davexunit>ah okay
<davexunit>I only needed one thing so it wasn't too bad to deal with
<happy_gnu[m]>ooh ok
<happy_gnu[m]>I am getting fom ~350 to ~800 depends on the size of the package I guess
<Apteryx>davexunit: have you tried yet?
<davexunit>didn't realize it was available
<Apteryx>it was made available by rekado!
<davexunit>oh awesome :)
<Apteryx>Here's an example for your operating-system config:
<davexunit>thank you!
<davexunit>ooh and bayfront is new, too
<Apteryx>The server public keys are already trusted by the default Guix daemon.
<Apteryx>yes but it's not doing very well so far (contrary to berlin),
<davexunit>oh :(
<Apteryx>I think the machine strives to be free (like free bios/coreboot) but unfortunately hasn't proven very stable.
<Apteryx>oh, and that %default-substitute-urls part needs to be made available using the (guix store) module at the top of your config.scm file.
<davexunit>I'll add this to my config next time I update
<davexunit>thanks again
<efraim>sneek: later tell joshuaBPMan there's a meson-build-system work in progress so we should be ready soon for the GNOME switch
<sneek>Got it.
<efraim>sneek: botsnack
<ng0>sneek: later tell happy_gnu[m]: I have a wip'ish package for searx, delayed for maybe about 1.5 years at this point because of an optional two-level python module check or something
<ng0>sneek: later tell happy_gnu[m]: I can create an up to date patch in about 10 hours or so and send it to the list, so that you have a reference
<sneek>Will do.
<happy_gnu[m]>ng0: hello
<sneek>Welcome back happy_gnu[m], you have 2 messages.
<sneek>happy_gnu[m], ng0 says: I have a wip'ish package for searx, delayed for maybe about 1.5 years at this point because of an optional two-level python module check or something
<sneek>happy_gnu[m], ng0 says: I can create an up to date patch in about 10 hours or so and send it to the list, so that you have a reference
<happy_gnu[m]>ng0: I am still compiling guixSD :( is been almost 24 hours :/ thats why I haven't even started with searx, so this is very interesting
<ng0>happy to know someone else wants something I work on :)
<happy_gnu[m]>you already have the package :)
<happy_gnu[m]>Yeah I installed searx on parabola, and then I said, I should look for it on guix, and it wasn't so I started installing a virtual machine
<ng0>I have an idea how it could look like, it's not a functional package because of socks['#:blafoo'] or something.. the idea is to have a service afterwards, so that one can run searx locally, not necessarily on a headless server
<happy_gnu[m]>I am learning scheme and dustyweb suggested me to package things for guix
<happy_gnu[m]>I know a little python and javascript but not much so my first real programming language is guile :)
<Apteryx>happy_gnu[m]: that's cool!
<ng0>I'm not really sure wether I can link my git here or not as one repository contains non-free instructions for guix.. but the indirect way, if you have much time on your hands and are impatient, go to and you'll find a link to my git. I have to leave soon
<happy_gnu[m]>ng0: ok I will read it. Tomorrow we can talk :)
<happy_gnu[m]>Apteryx: Is your name related to Asterix ? :)
<ng0>it's either in 'packages' 'pre_packages' or one of the many branches of 'guix'. But I will send a patch when I'm back home
<happy_gnu[m]>ng0: thanks I will look at it
<ng0>I'll be off now. bye
<happy_gnu[m]>Apteryx: I am still compiling though :( 24 hours
<happy_gnu[m]>I have 4 cores used for the VM and 4gb of ram :/
<efraim>i had to fix my build script, `./pre-inst-env guix package -A | cut -f1,2 | sed -e 's/\\t/@/' | shuf | parallel --jobs 1 ./pre-guix-env guix build`, changed cut from 'cut -f1', took out 'sort -u' for sed
<pmikkelsen>good morning guic
<cbaines>good morning pmikkelsen :)
<jherrlin>godmorning folks!
<cbaines>hey jherrlin :)
<jherrlin>could someone recommend a decent Emacs config for working with GuixSD/Guix, what i am mostly interested in at the moment is goto definition
<cbaines>Have you tried Geiser? I think that supports jumping to definitions for example.
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, dustyweb says: I'm not sure if Guile needs this, but I found that I did
<sneek>civodul, dustyweb says: er, Guix
<civodul>nice, i think we haven't had a need for number->canonical-sexp so far
<civodul>yeah GNU COBOL is in the house!
<jonsger>civodul: your comment on the patch was nice. I had to lough... :P
<pmikkelsen>It would be nice if guix could tell that packages form circular dependencies, instead of just hanging
<civodul>pmikkelsen: agreed
<civodul>though i must say that never happened to me :-)
<civodul>with Guile 2.2 it's not just hanging, i think it expands the stack too
<pmikkelsen>It does, i had to restart my pc because I made a mistake in the haskell module :) The test suites of haskell often have tests which depends on other test suites, which forms a loop.. :p
<civodul>i sympathize :-)
<efraim>It happened to me with the glibc graft, I found if I pass --no-substitutes to the build then I know its 'thinking' and not waiting on substitute servers
<wingo>i have a kaby lake laptop with intel graphics and with SNA acceleration, i still experience that Emacs display corruption issue
<wingo>but with SNA off, the display is really slow. makes this machine feel slow.
<wingo>like, scrolling is mega-janky
<wingo>and i've tried updating the intel driver to see if they fixed the SNA issue but apparently not.
<wingo>now, apparently the upstream solution is to move towards what's called the "modesetting" driver
<wingo>away from xorg-video-intel
<wingo>and to this more standard modesetting driver.
<civodul>do you have a rotated display?
<wingo>does anyone know more about this? i guess we should use it
<wingo>no, my display is fine
<civodul>that started being unsuably slow recently
<wingo>it is a hidpi display, but that shouldn't affect things too badly
<wingo>i mean, more pixels, more bandwidth, but no rotation or anything like that
<civodul>i have a hidpi display with the intel thing here, and it works fine
<wingo>yes mine works. just slow to scroll.
<wingo>e.g. open evince, scroll pdf -> really janky.
<civodul>i mean mine isn't slow
<wingo>are you running gnome-shell, civodul ?
<wingo>could be related
<wingo>so, no compositor for you then? or are you using some other compositor
<civodul>no compositor
<wingo>ok, could be that then
<civodul>everything like in the old days ;-)
<wingo>didn't know debian had already switched to modesetting
<wingo>civodul: do rotated displays not work with the modesetting driver?
<wingo>or were you just noting that perf got bad recently
<civodul>the latter, perf got really bad starting with 4.12
<civodul>i physically rotate my screen to work around the problem
<civodul>which is sad, i like vertical screens
<wingo>interesting, does 4.13 fix things?
<wingo>or is it just bad
<civodul>i haven't tried
<wingo>interestingly fedora and debian keep using the intel driver for i915 and earlier chipsets:
<wingo>the reason is in that thread; apparently the approach used by modesetting doesn't work on those cards
<wingo>so we would have to keep both around anyway then
<wingo>i guess some x61 or x200 users might still have these cards
<wingo>i wonder if this patch is upstream now... seems like the sort of thing you wouldn't want to have every distro patching
<civodul>wingo: if it's not upstream, we can apply it to xorg-server
<civodul>it _seems_ to make sense :-)
<wingo>maybe i will have a go at it today
<jherrlin>cbaines thanks for the tips, will look at geiser!
<pmikkelsen>What do we usually do when packages become deprecated upstream? If I remove them, I will have to remove some other packages that depend on them too, but if I don't, then we will have to have and old version of a library around?
<civodul>pmikkelsen: i would raise the issue on guix-devel
<civodul>we rarely remove packages, but we've done so a couple of times in the past i think
<pmikkelsen>civodul: allright, I will figure out how many 'old' libraries we will have to keep around, and if it is just a single or two, then I think it is ok to keep it
<ng0>would anyone know if it's by design or by grave mistake that you can get anything into without even merging the Pull Request?
<ng0>read the website, section Linux-Systems or something
<ng0>and now this open PR:
<ng0>and the git log doesn't include the commit/PR
<ng0>there's "only" 20 Mate packages missing, I'll do this over the next free days, including a service we'll need then for caja probably.
<pmikkelsen>ng0: That is really strange :/
<ng0>as long as you have git to roll back and to blame, you could have a website which works like this
<ng0>but I guess it's a mistake
<jonsger>ng0: this would be also a place where guix should be present :)
<ng0>I'll do it eventually maybe, if you are not faster
<ng0>where do we have "gksu"?
<ng0>seems like we don't
<ng0>have it
***bmpvieira_ is now known as bmpvieira
<dustyweb>btw, the un-vettedness of language package managers leading to security holes comes up again
<brendyn>"SK-CSIRT identified malicious software libraries in the official Python package
<brendyn>repository, PyPI, posing as well known libraries"
<dustyweb>brendyn: beat you to it by 2 minutes! ;)
<dustyweb>pretty scary tho
<brendyn>ya. guix devs should be careful when trying to find add random dependencies they need.
<yoosty>civodul: howdy! o/
<yoosty>the room has grown in the past year ;)
<civodul>hello yoosty!
<civodul>surely :-)
<Apteryx>dustyweb: not surprised a bit by it. PyPI doesn't exerce any filtering or control on the packages it hosts. It contains lots of fake packages that were uploaded once just to see how it'd goes.
<Apteryx>In Guix we have systems tests. Do we also have unit tests?
<davexunit>guix has many unit tests
<Apteryx>Great! I will look into these. Thanks.
<civodul>Apteryx: don't miss :-)
<Apteryx>civodul: OK :)
<happy_gnu[m]>Hello \\o/
<happy_gnu[m]>Damn and pipe requires sudo :/
<happy_gnu[m]>How is this posible :/
<happy_gnu[m]>civodul: how are you
<civodul>i'm fine :-)
<Apteryx>civodul: I just finished reading your GPCE paper; it was surprinsingly easy to follow and useful to my comprehensions of gexps and how they came to be; great work! Enjoy Vancouver next month!
<civodul>Apteryx: thanks, glad you found it useful!
<happy_gnu[m]>Yesterday I lost all my Guix SD VM :( My house lost power :/ when it came back VM didn't work
<happy_gnu[m]>Back to compile :) haha
<Apteryx>happy_gnu[m]: compile? Try the new substitute servers if you want a great speed-up!
<happy_gnu[m]>Apteryx: should I do "locate"
<happy_gnu[m]>And use that file
<happy_gnu[m]>Or should I download a different file
<Apteryx>The servers I'm referring to are and and
<Apteryx>You could pass those to the guix daemon with the --substitute-urls option.
<Apteryx>or to any guix command.
<happy_gnu[m]>This is before I install but after I do partitions right?
<Apteryx>Inside the installer, it would be at the step when you run: guix system init /mnt/etc/config.scm /mnt
<happy_gnu[m]>Apteryx: let me try it now :)
<Apteryx>So the command would look like this instead guix system init /mnt/etc/config.scm /mnt --substitute-urls="" I think.
<happy_gnu[m]>Ah great
<happy_gnu[m]>Documentation says I should "add its public key to the access control list (ACL) of archive imports, " Do I need to this or just the URL will be enough?
<Apteryx>Those servers keys are already trusted by default, so it should just work.
<civodul>you can remove bayfront though (it's not building much currently)
<happy_gnu[m]>so, I wanted to use ssh to connect to qemu for the installation
<happy_gnu[m]>but when I use passwd
<happy_gnu[m]>it says command not found :/
<happy_gnu[m]>useradd also says command not found :/
<nextos>hi how do i list the set of keys currently authorized (by guix archive --authorize)?
<civodul>happy_gnu[m]: see the manual on how to manage user accounts on GuixSD
<civodul>nextos: "sudo cat /etc/guix/acl" would do
<civodul>though it gives you the raw list of keys
<nextos>civodul: thanks, so no keys are provided by default and i should authorize gnu's hydra if i want binaries right?
<happy_gnu[m]>civodul: but the manual says to use passwd :/
<civodul>nextos: exactly:
<happy_gnu[m]>You would normally leave this field to #f, initialize user passwords as rootwith the passwd command, and then let users change it with passwd. Passwords set with passwd are of course preserved across reboot and reconfiguration.
<nextos>civodul: thanks. One last question, I should guix pull often to be able to get binaries right? If my package definitions are old, i won't be able to pull matching binaries from hydra?
***Piece_Maker is now known as Acou_Bass
<civodul>nextos: the main reason to run "guix pull" frequently is to get security updates
<nextos>civodul: yes, of course
<civodul>so once per week you'd run "guix pull && guix package -u"
<nextos>civodul: but was my reasoning right? I mean if i dont guix pull after my initial guix install, hydra wont contain matching binaries? It's just for me to understand how guix works. I know I should update often.
<civodul>nextos: keeps binaries for a couple of months at least
<civodul>so normally you won't have this kind of problem
<nextos>civodul: aha, ok
<Apteryx>Is the new 'guix pull' smart enough to only recompile files which were modified in the git cache? Or does recompiles everything everytime?
<happy_gnu[m]>oh i solved it
<happy_gnu[m]>i find passwd and executed it
<happy_gnu[m]>it was on /gnu/store/f4-reallyLongString/bin/passwd
<nextos>I did guix pull, but somehow now guix reconfigure crashes (error: (config.scm: Any ideas why my configuration is outputting that error?
<nextos>Links again, just in case your ERC messes up with parentheses (error: ) (config.scm: ).
<cbaines>nextos, I think you need to use something like (grub-configuration (bootloader grub-bootloader) (target "/dev/sda"))
<cbaines>it's not obvious to me why Guix is crashing, but perhaps the above might work
<nextos>cbaines: has the syntax changed? my config.scm is a verbatim copy of the docs
<Apteryx>nextos: check the latest docs; yes it has changed
<cbaines>I think it changed at some point
<Apteryx>although the old way should still work for the time being
<cbaines>you might be using an older copy of the docs? I think the ones online are for the latest release
<nextos>are those the latest ones?
<Apteryx>nextos: if you did guix pull this is not latest enough.
<nextos>Apteryx: ok, where do i get to see the cutting edge docs then?
<Apteryx>the docs online corresponds to the snapshot of 0.13 or whatever latest release at the time it was made.
<nextos> (bootloader grub-bootloader) (target "/dev/sda")) doesn't seem to work either
<nextos>i get an invalid field specifier error for that
<cbaines>Ok, you can see a full example here if that helps
<Apteryx>it's a bug that the docs don't get updated when we do 'guix pull'; so for now you don't have much choice but to git clone guix somewhere and build it. the docs will appear under guix/doc. You can then info -f guix/doc/ or C-u h i in emacs
<Apteryx>alternatively add something like: INFOPATH=/home/$USER/src/guix/doc to your ~/.bash_profile
<nextos>Apteryx: ok, i still get exactly the same error as in
<nextos>when using the template in
<Apteryx>can you repost your modified operating-system config?
<Apteryx>hmm. Is "guix" a label?
<nextos>yes, this configuration was running fine with the old bootloader syntax
<nextos>till i guix pull-ed
<Apteryx>Seems you've omitted the (title 'label) part from the file-system definition. Not sure if it's the default or not.
<Apteryx>Mine looks very close but with that label part and a different label name:
<Apteryx>I remember someone having an issue because their label name started by "guix" or something. This was supposedly fixed but just to stay on the safe side you might want to rename your label to something else.
<buenouanq>wow, that's a silly/awful bug that would seem to indicate potentially much worse problems if true
<nextos>Apteryx: ok, i'll give it a try
<nextos>Apteryx: ive ran out of time but i will try tonite
<Apteryx>nextos: title defaults to device if omitted
<Apteryx>so thats your problem
<Apteryx>you must use (title 'label) if you are to use "guix" as a label.
<Apteryx>good luck!
<nextos>ok so i literally need (title 'label) or (title 'guix)?
<Apteryx>(title 'label) as part of your (file-system ... definition. See 6.2.3 File Systems in the manual.
<CompanionCube>so I installed the ikiwiki package to try it out
<CompanionCube>but it seems it's missing a perl module
<oriansj>sneek: later tell rain1 to message me as I have some important news.
<sneek>Will do.
<oriansj>sneek: botsnack!
<CompanionCube>what's the best way to deal with this (and any other missing modules)?
<bavier`>CompanionCube: as a stopgap you could install the missing module alongside ikiwiki
<cbaines>CompanionCube, sending a patch to add the missing module would be great
<cbaines>what module is missing?
<CompanionCube>bavier`: I've added the package to my profile
<CompanionCube>but it didn't change anything
<CompanionCube>cbaines: 'Can't locate HTTP/ in @INC (you may need to install the HTTP::Request module)'
<CompanionCube>it's provided by the perl-http-message package i think
<bavier`>CompanionCube: is your profile directory included in PERL5LIB?
<CompanionCube>I haven't explicitly added it, but it doesn't look like Guix sets it automagically in the profile's etc/profile
<cbaines>You might need to also install perl in your profile for the search path to be setup
<CompanionCube>(the reason i'm using guix for this is most likely something you've heard a million times)
<marusich>CompanionCube, it would be better if the ikiwiki package "just worked" without requiring you to install a perl module into your profile. Ideally, software deployed via Guix (or Nix) should not require "extra steps" like installing a second package; although it is a common practice with other package managers, it runs against the spirit of functional package managers like Guix and Nix.
<marusich>Because the software will not work if you do not also install the extra thing you need, the deployment of the software is "incomplete". That is one of the problems that Guix and Nix specifically aim to solve.
<marusich>Unless there's a good reason to do otherwise, either the module should be a propagated input of the pacakge (not so great because it introduces the possibility of conflicts with other packages installed in your profile), or (better) the package definition should be changed so that the software which is failing to find the module will find it. Foe example, if a script or program is being run which expected the module to be available, one solution
<marusich>might be to wrap it in a launcher script that correctly sets up the PERL5LIB environment variable so that perl will find the module.
<marusich>There are helper procedures to accomplish that; look for existing package definitions which use "wrap-program" if you are curious.
<cbaines>the ikiwiki package is already setup to wrap the scripts with the PERL5LIB to include the inputs, if there is indeed a missing input, just adding it to the list of inputs should be sufficient
<marusich>Well, there you go :-)
<marusich>An interesting question is whether or not this particular module was intended to somehow be "optional"
<marusich>I'm not sure if there's a widely accepted approach for selecting optional features of pacakges in Guix and Nix. It can be done by defining new packages, of course.
<CompanionCube>marusich: i believe nix has a feature for that
<davexunit>making package variants *is* the feature for that
<marusich>I think they do, but I don't know if their feature is easy to use from the command line. I suspect (but don't know for sure) that the user would have to define their own package to do it.
<davexunit>guix lets you do some package manipulation from the CLI, but it will always be limited compared to what you can do in code.
<marusich>davexunit, sure, but that requires you to define a new package. You can't just say "guix package -i my-software --with-option redWidget"
<marusich>which is fine.
<marusich>Do you know if it's the same in Nix land?
<davexunit>there's no reasonable way to implement --with-option, though
<davexunit>there are so many build systems
<marusich>Yeah, I also think it would probably not be helpful. It'd be almost like running ./configure via the CLI, which seems silly.
<davexunit>some people want guix to be more like gentoo, but I just don't think it's a good fit.
<CompanionCube>I imagine this is a particularly sore point for software like ikiwiki, which I know has a broad list of shipped plugins
<marusich>I agree that being able to define (and then use) your own package variants is probably fine.
<CompanionCube>which have their own dependencies and may or may not be enabled for any given site
<davexunit>but they all have to be chosen at compile time? sounds like a bad plugin system
<CompanionCube>not really
<CompanionCube>they just have to be found when you run the thing
<davexunit>it would be bad if I had to choose all my emacs extensions at compile time.
<davexunit>well that can be done easily with guix
<Apteryx>is anyone running a user emacs server service with GuixSD? I'd be curious to see a sample config.
<davexunit>Apteryx: yeah, one sec
<davexunit>make-system-constructor and make-system-destructor are custom helpers
<davexunit>(as an aside, I think shepherd should probably provide things like this by default, like how systemd has different service types like oneshot, forking, etc. Haven't made a patch, though)
<Apteryx>that's a treasure trove of a dot file, thanks
<Apteryx>How does it get hooked into shepherd though?
<CompanionCube>two modules down, now i've hit the one i was mostly expecting
<davexunit>Apteryx: I run a separate shepherd process
<davexunit>as my own user
<davexunit>and I have GNOME start it automatically when I login
<Apteryx>OK. And that init file can be read and executed by shepherd directly?
<davexunit>you put it in ~/.config/shepherd/init.scm
<davexunit>shepherd will read it from there automatically
<Apteryx>neat! Thanks for sharing.
<civodul>those in the EU, consider signing
<civodul>and spread the word!
<bavier`>is that letter only for EU citizens? why are there non-EU countries listed in the dropdown menu?
<civodul>it's possible for non-EU citizens to sign, but i guess FSFE will not go lobby at parlamients outside of EU :-)
<civodul>it's great to show support from everywhere anyway!
<joshuaBPMan>hello, does guix provide an easy way to specify an alternate keyboard layout at the login manager? ie: dvorak? Perferably this would be an easy way to make X provide the same layout as well.
<sneek>Welcome back joshuaBPMan, you have 1 message.
<sneek>joshuaBPMan, efraim says: there's a meson-build-system work in progress so we should be ready soon for the GNOME switch
<bavier`>civodul: yup. Signed!
<oriansj>joshuaBPMan: well the ability to switch keyboard layout at login is entirely determined by what login manager you use.
<bavier`>joshuaBPMan: I assume you mean SLiM?
<oriansj>now if someone were to finish the lxde port by adding lxdm, that would satisfy your requirement joshuaBPMan
<joshuaBPMan>I thought that slim was the only login manager that guix provides...
<joshuaBPMan>I'll have to check into the lxde port some time later...Night ya'll.
<bavier`>joshuaBPMan: I think you can use 'xorg-configuration-file' passing '("Option \\"XkbLayout\\" \\"foo\\") in #:extra-config
<bavier`>too slow...
<bavier`>it's probably more complicated that that
<civodul>this Xorg service really needs love
<CharlieBrown>Hey, where's mattl? I haven't seen him in a while.