IRC channel logs


back to list of logs

<emyles>Hi, on Arch Linux, just upgrading glibc to 2.23 and locale-gen
<emyles>does: en_GB.UTF-8...cannot create temporary file: /run/current-system/locale/2.22/locale-archive.YWtNZZ: No such file or directory
<emyles>why is that?
<paroneayea>not a lot of things being pulled down via substitutes right now it seems...
<lfam>Gah, I built a bunch of packages against the grafted libarchive yesterday, and then I rebuilt after rebasing on master before pushing, but now libarchive fails to build. The sparse_basic test fails.
<mark_weaver>lfam: it builds for me, fwiw
<mark_weaver>on both i686 and mips64el
<lfam>mark_weaver: Okay, that's good. I wonder what is going on for me?!
<mark_weaver>might be a non-deterministic failure
<lfam>Yes, but it just happened 4 times in a row.
<lfam>After pushing, I did `guix pull` and then `guix package -u .` But, I ran out space so I had to stop and `guix gc`. `guix gc --verify` succeeds.
<mark_weaver>well, I confess that on my mips machine, I actually cherry-picked your libarchive patch on top of my rather old private branch
<lfam>I'm going to try building without today's commits
<mark_weaver>and on my i686, I'm also running a bit of a strange private branch with gnome-updates and some of my unsubmitted patches
<mark_weaver>so I haven't actually tried building it on pristine master
<lfam>Huh, I can build it on another x86_64 machine. Waiting on the third...
<lfam>I decided to transfer the libarchive closure from a machine that could build it to this one
<z0d>git.savannah is down?
<wingo>ACTION wonders what guix + bubblewrap would look like
<wingo>it's a setuid helper that runs a subprocess in a container with new namespaces
<wingo>i wonder if we could deliver applications to foreign distros and run them via bubblewrap
<roelj>Do you think we could run guix-daemon in unprivileged user mode with bubblewrap?
<alezost>z0d: at least something is happening with savannah: I can't commit to :-(
<jlicht>Am I missing some kind of service announcement, or are the repos not working?
<alezost>jlicht: not working for me too; I don't think there are any announcement of this kind
<jlicht>Is there any semi-official mirror?
<jfc>Can't help but notice 'git pull' gets the master.tar.gz over http and https is broken somehow OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
<jfc>*guix pull
<jlicht>jfc: Maybe this ties into the git clone troubles for that same domain?
<jfc>jlicht: I don't know about those... but I'm somewhat concerned that I'm stuck getting the master snapshot via http ....
<rekado>I'm still having git fetch problems after IT re-opened the ports here, though I'm not sure if this really fixed it.
<jlicht>maybe it would make sense to have a default setting that refuses to download guix sources over http?
<wingo>roelj: i don't think so because the daemon needs to chroot
<jfc>jlicht: but then how are you going to download them since https isn't working (as I mentioned above)
<wingo>i am more interested in how to run guix programs on foreign distros as a normal user
<rekado>user namespaces?
<wingo>user namespaces is one option
<rekado>and radical patching another?
<wingo>bubblewrap is a suid helper that uses mount namespaces
<jfc>jlicht: seems that savannah needs to update their https
<wingo>rekado: requiring the user to have an installed suid helper is the other one was thinking of
<jlicht>jfc: indeed
<jfc>jlicht: I expect this would happen in the next 3 years... /s
<ng0>If at some point I were to work on getting features of hardened gentoo, like grsec, selinux, rsbac,IMA/EVM, etc, into guix - knowing that this will mean a long time testing and debugging because it's the complete base of guix - are some of those technologies not necessary with guixsd?
<ng0>leaving aside licenses for a moment, just a mere "what if"
<rekado>selinux is hard to get right with Guix, I think.
<rekado>I have packaged some of the tools already.
<rekado>you'd need to tag all files in the store and make sure they have the right types.
<rekado>then develop a policy from scratch that would work in spite of having files installed to /gnu/store/hash-*
<ng0>I have only minimal, but growing knowledge of selinux and grsec. wouldn't that be doable in advance and provide certain policies devliered with guix?
<rekado>this means that pretty much all of the default rules would not work.
<rekado>as far as I remember SELinux rules apply to file path patterns.
<ng0>GRsec was a bit different, right?
<ng0>I'd like to look into that once I've debugged gnunet-gtk for gentoo.
<rekado>and you'd have to modify all files by labelling them.
<rekado>I don't know about GRsec.
<rekado>SELinux isn't bad, but it would be a lot of work to get it right.
<rekado>I also wonder how we would handle policies.
<rekado>we probably shouldn't install rules for each package.
<rekado>so we'd have packages named *-selinux providing rules
<rekado>and a service that acts on these rules to label files
<rekado>but relabling a system on boot wouldn't be feasible
<rekado>and we cannot store pre-labelled files in the store
<ng0>maybe that's what we can consider for roadmap for $muchlater and have a group or some individuals working on it, for policies etc. I'll have to get more familiar with grsec etc and when I have guixsd back, I would like to test this over an undefined timespan
<rekado>we could also try this on just a single package: the browser.
<rekado>then figure out the details as we go.
<ng0>which one of the browsers?
<rekado>I'd start with icecat.
<ng0>I also wonder about this, because of hardened toolchain features you can build with firefox and other applicaitons in general
<rekado>I'm not sure I understand this sentence
<rekado>in the easiest case a user would label only their own files. System files would not be labelled at all.
<ng0>hardened gcc, and also musl or uclibc are part project:hardened in gentoo. selinux isn't my only focus.
<rekado>then we'd have a rule that permits tasks with a certain label to access files with a particular label, and refuse access on all other files.
<rekado>I understand
<rekado>I don't know much about hardening, but I have some experience with SELinux.
<jfc>I cannot use guix anymore: Please consider hosting your git repo. on something that supports https, like (since presumably not github)
<rekado>if someone wants to bring SELinux to GuixSD I'd be happy to help with the effort.
<ng0>rekado: I'd like to come back to this conversation when I have more time :) It looks like there's definitely potential for adding functionalities.
<rekado>ng0: yeah, currently I'm also out of time for exploratory stuff like this :-)
<ng0>I'm doing exploratory stuff with gnunet-gtk debuuging :/ did it break due to libgcrypt-1.7? was it some other part on this system? I'm setting up many VMs now to look for differences in build
<ng0>if I finish the ebuild before july, it only took me 3-5 months for the whole packaging process, when I started in july 2015
<ng0>oh, grammar broke in that sentence.
<roelj>Are there any GTK2 themes I can propagate with a GTK2 package, so it looks a bit more decent?
<davexunit>someone won't use guix because they can't clone over https?
<davexunit>why the hell would a gnu project host on just doesn't make any sense.
<ng0>did I miss something?
<ng0>#23504 ?
<davexunit>I was just reading the backlog
<roelj>No #22883
<davexunit>one of those users that just complains even though we acknowledge and work on addressing the issues
<ng0>older than 2 weeks, hard to find without grep in Maildir. possibly not worth the effort.
<ng0>explanation: I get >=250-400 emails average in 2 weeks and I gave up sorting. I wanted to look into the thread, but I'll just use the debuggs/patches website
<rekado>roelj: I would advise against propagating GTK themes.
<rekado>unless you mean propagate as in propaganda.
<rekado>bah, I still get "Timeout, server not responding." :(
<roelj>So, it's a GTK2 program (Dia), and it seems to run without a GTK theme.
<rekado>do you mean that it doesn't *use* the theme you have configured for all other GTK applications?
<roelj>Well, that's the problem.. I don't have any theme configured, other than what Fedora does by default.
<roelj>I guessed the GUIX_GTK3_* variables won't work on GTK2 things.
<rekado>I see.
<roelj>Can I just expect that it will run with a theme when someone installs it?
<ng0>the joy of halfway modern computers: watching star trek while 2 virtual machines compile the world and your base system also compiles world updates
<rekado>I think you can configure GTK2 stuff with a gtk2rc (?) file.
<roelj>Right. So it's up to the user to do that?
<rekado>I think so.
<rekado>I don't see a dia package.
<roelj>No, I'm trying to package it ;)
<rekado>Well, I have a Fedora workstation here at work, so I could try that.
<roelj>Shall I paste the package definition somewhere?
<rekado>not sure if it will work for me as I haven't updated the git checkout in a while (and I cannot do it right now for some reason), but I can give it a try
<roelj>Only if you have the time for this ;)
<davexunit>I think we may need to identify and revert some commits on master
<davexunit>I seem to be compiling nearly everything from source whilst trying to do a system update
<davexunit>which leads me to suspect that a commit was pushed that should've been for core-updates instead
<rekado>oops, I think I have a broken Guix since "guix gc" again...
<roelj>Broken how? I thought "guix gc" only removes the dead stuff :)
<rekado>which includes things I forgot to register after "guix environment guix".
<rekado>;;; ERROR: missing interface for module (gnutls)
<rekado>or it could be my recent Fedora upgrade :-/
<roelj>Oh, on Fedora, you can install gnutls-guile, which should fix that error.
<davexunit>rekado: we'll fix this in the future. we'll make the profiles that 'guix environment' generates into gc roots
<roelj>(And then it uses Fedora's gnutls guile module)
<davexunit>at least for now you only have to manually register a single profile
<rekado>davexunit: yeah, it's no problem.
<rekado>I only forget about this too often...
<davexunit>I'm trying to think about what a good UI for this would be.
<davexunit>it probably shouldn't register a gc root by default, because that makes the throwaway environment use-case more difficult, and most of the time that's what I want to make.
<davexunit>maybe a --save flag or some better name
<davexunit>then of course transactional upgrades and rollbacks would be the next step ;)
<rekado>is anyone here using slurm from Guix?
<rekado>I'm trying it right now (for the very first time) and it looks like slurmctld looks for /etc/slurm.conf in the store.
<davexunit>never heard of that program, sorry.
<rekado>ah, never mind, need to set SLURM_CONF.
<rekado>it's a scheduler or process manager.
<rekado>hmm, our slurm package isn't quite working.
<rekado>or it's the munge package.
<rekado>localstatedir defaults to the store, but munge tries to create socket files there at runtime.
<bavier>rekado: I'm glad you're testing it
<foobarry>rekado: you know we chatted last week about someone who had module wrappers for guix? was that someone called pjotor?
<foobarry>wondered how i could get hold of him
<roelj>join #genenetwork if you want to reach Pjotr.
<foobarry>many thx
<roelj>I keep getting the following error when evaluating a (define-module ...) that uses guix modules:
<roelj>guix/download.scm:211:2: In procedure module-lookup: Unbound variable: plain-file
<roelj>plain-file is exported by (guix gexp).
<roelj>What could be wrong?
<rekado>does anyone know how to get bluetooth to work?
<rekado>I installed bluez and started btmon as root.
<rekado>"rfkill list" shows me the local bluetooth device, but "hcitool dev" does not.
<rekado>there also is no device node.
<davexunit>I have never used a bluetooth anything so I'm afraid I'll be of no help.
<rekado>I have a bluetooth card in this laptop. Don't see any deblobbed messages, so I assume it works with linux-libre
<kyamashita>So the Tor Browser Bundle looks like it could be runnable on Guix with some ELF patching.
<kyamashita>Also a tiny bit of sed magic.
<ng0>oh? my plan was to just wait for 6.0.5 release and use the more recent firefox esr they use to build on, like we do now for a while for gentoo
<davexunit>kyamashita: that would lead me to believe that it's not reproducible
<rekado>ah, needed to run "sudo hciconfig hci0 up" first to enable the internal bluetooth device.
<kyamashita>davexunit: True. But I never said reproducible. ;-)
<ng0>s/my plan/my idea
<kyamashita>ng0: That sounds pretty good.
<davexunit>kyamashita: well if you want to run that on your own, go for it. ;)
<davexunit>could never be in guix proper, though.
<ng0>ebuilds orient around what torproject does for building, so it's inofficial.
<ng0>*the ebuilds
<davexunit>speaking of this topic of supposedly "secure" applications, see;
<davexunit>"secure" is in scare quotes because freedom is sacrficed in the process.
<ng0>that'sbehind great firewall of cloudflare, but i'll work around that.
<ng0>oh. it loaded anyway
<ng0>ah, the moxie story... -.-
<kyamashita>davexunit: I would never! It was a theoretical realization. Patching each of the libraries and constantly searching through the store doesn't sound like fun.
<kyamashita>ng0: Indeed. I was hearing about this on GNU Social.
<ng0>we were discussing this for the last 2 days in psyced.
<ng0>also, if you are interested in fixing up torbrowser, do it. from what I've looked at it's doable without any license issues, I had no time for further checking. if you want to, you can get the code from or what the searchengine was, or look at and get the youbroketheinternet-overlay, check www-client/torbrowser/ directory for an orientation on how this can work. it pulls patches
<ng0>for versions from a gentoo devs userspace, so those would have to be adjusted.
<davexunit>isn't it not possible to compile the tor browser from source and have a usable result?
<ng0>i don't know, i have always done it this way
<davexunit>does it build from source?
<ng0>gentoo, we have not written a torbrowser-bin so far
<ng0>I can try in some days in one of the VMs if torbrowser can build just from source of torbrowser
<davexunit>my understanding, without having ever used it, was that if the hash of the binary changed at all the application wouldn't work.
<davexunit>or would do something that would negate its benefits.
<ng0>torbrowser is just firefox-esr of some version + torbrowser addons + torbrowser source adjustments
<ng0>of course there's more, but they track firefox esr
<ng0>pull in firefox esr, patch the sources according to the distro you are on, apply torbrowser repository, build
<ng0>from memory at least.
<kyamashita>ng0: ebuilds look like they do something close to that.
<ng0>of course there's stuff like EAPIs and eclasses, but that should be easy to get with guix, maybe even shorter than the ebuild
<kyamashita>ng0: Yeah. I'm not familiar with emake and its friends. I never got too in depth with Portage.
<ng0>if you feel like you can make most of it, but need help with translating EAPI and eclasses or understandin them, I can help you
<kyamashita>ng0: I'll see what I can do this weekend assuming I'm not busy. :)
<kyamashita>ACTION is momentarily afk
<ng0>I don't get all of it to the core of the functions, but I know my way around EAPI4,5 and 6 and some eclasses I'd say
<kyamashita>ACTION is back
<lumidragon>Hi everyone, is there a license option for when packages have no license? or do u just use '#f'?
<ng0>no license at all?
<ng0>what's the packages name?
<lumidragon>I check the repo for for one I'm packaking now didn't see one. And the name is envstore
<davexunit>lumidragon: in order to submit a package upstream to us, there needs to be a valid free software license applied to the source code.
<davexunit>no license means "all rights reserved"
<kyamashita>lumidragon: I see WTFPL...
<ng0>lumidragon: do you have an url to a website and/or sourcecode?
<lumidragon>yup just a min
<lumidragon>oh kk which license variable does that corrspond to?
<ng0> see header
<ng0>maybe grep for license in the whole repo
<jlicht>what use is the 'environment-variables' file that is created after failing building a guix package /w --keep-failed?
<kyamashita>ng0: non-copyleft, perhaps?
<ng0>idk, i don't store licenses in my head. use the fsf / page :)
<ng0>or the license file in guix.git
<kyamashita>ng0: non-copyleft is a generic license type in guix/licenses.scm that allows you to point to a URL of the specific license.
<kyamashita>*URI, no URL. Almost the same thing.
<ng0>oh, derf. derf is someone from around the region where I live I think, chaosdorf düsseldorf :)
<lumidragon>kyamashita: I should add a license for the wtfpl then?
<ng0>lumidragon: if it is copyleft
<ng0>or compatible or whatever
<lumidragon>oh kk, guess I'll have to research that. thanks.
<kyamashita>lumidragon: (license:non-copyleft ""))
<efraim>wikipedia helps with figuring out if a license is copyleft or not
<kyamashita>WTFPL is a non-copyleft license.
<lumidragon>oh kk thanks. guess I can't submit that then.
<kyamashita>lumidragon: You can! There is another package that uses it.
<kyamashita>lumidragon: Non-copyleft does not necessarily mean nonfree.
<lumidragon>oh kk.
<lumidragon>what's the name of the package using the wtfpl?
<kyamashita>lumidragon: It's part of the r-dt package in gnu/packages/statistics.scm.
<ng0>cd $your-git-checkout-of-guix/gnu/packages/ ; grep "wtfpl" *
<lumidragon>I grep for and didn't find anything. Only realized I had a typo sry.
<ng0>oh, okay:)
<ng0>Ijustthought you did not know about grep or awk
<lumidragon>ah I know my way around grep, awk and sed.
<lumidragon>ah -> nah*
<lumidragon>should prb use ag since the repo is so big.
<ng0>ah found it
<lumidragon>it's search command caching abilities
<ng0>yeah, this one
<lumidragon>oh kk cool, emacs projectile has a pakage or mode for it. goes nicely with helm :D
<ng0>provides binary ag
<lumidragon>oh while I'm on emacs, where should the emacs packages installed by guix go?
<lumidragon>I see some go to site-lisp
<lumidragon>and other site-lisp/guix.d
<ng0>weird. you can get the hacker magazine phrack in gentoo by emerging it
<ng0>found it while searching for ack
<lumidragon>weird indeed.
<ng0>you can get the magazine archives: SRC_URI="${MY_P}.tar.gz"
<lumidragon>is the emacs packaging a sore point? or the location doesn't really matters as long as it's under the emacs directory?
<lumidragon>ng0: will note that ty.
<ng0>sorry for writing so much, I'm just watching star trek while waiting for systems to be usable
<ng0>gentoo VMs. need to debug something
<lumidragon>yikes, I remember those days. Loved gentoo, but some packages take forever to build from source -_-
<lumidragon>oh another question, since no takes on the emacs thing.
<ng0>bloatware takes long to prepare everywhere. everything else is max 30 minutes, average here for me is maybe 10 minutes maximum.
<bavier>lumidragon: what do you mean "emacs packaging"?
<ng0>I'm not happy with setting up the VMs, now that I know guixsd, but it is mainly gentoo packaging it is for.
<lumidragon>when developing packages do I need to run the guix-daemon under ./pre-inst-env ?
<lumidragon>bavier: I was asking if emacs packages should go un site-lisp or site-lisp/guixd.d
<lumidragon>ng0: oh kk.
<bavier>lumidragon: the guix-daemon doesn't need pre-inst-env in most cases
<bavier>I think guixd.d is the preferred, but alezost would know more
<lumidragon>kk thanks something I get an error when the package link is https. so was wondering.
<lumidragon>sry meant guix.d, and kk noted.
<ng0>this is also halfway guix related, as the new, on hold, gnunet-gtk package might be adjusted after I have results on what I am currently doing :)
<lumidragon>ohhhhh :)
<ng0>also I learned about some more optional dependencies, so gnunet-svn will be adjusted.
<lumidragon>intersting, would have figured you do that with NixOS.
<ng0>I don't know NixOS enough to use it but I know Gentoo enough and package for it so that's the natural choice.
<lumidragon>makes sense.
<lumidragon>I started looking at go (for packagin), but my gosh 0_0. Why didn't they use gnu build tools. :(.
<lumidragon>with a couple sed the build runs okay, but when u get to the test it's a nighmare.
<ng0>eg I don't know if I can test some package / entire system to compile with musl, uclibc and its hardened variants (I only know them in gentoo hardened existing) in NixOS.
<lumidragon>oh quick question can nix package manager be installed along side guix on guixsd?
<lumidragon>just curious
<bavier>I think its possible, but I've never done it personally
<bavier>IIRC there's at least one other here who has such a setup
<lumidragon>was wondering about cause two tools I use docker and peco are both built in golang.
<lumidragon>and rkt too.
<bavier>lumidragon: have you read up on the golang efforts on the ML?
<kyamashita>ACTION is afk again
<lumidragon>ML = mailing list?
<bavier>yes, sorry
<lumidragon>I only recently join the list like 3-4 days ago.
<bavier>lumidragon: the archives are searchable
<lumidragon>so doubt I have it in my maildir
<ng0>you can get archives on the mailman site for it, or
<lumidragon>oh right forgot most mailing list do that thinks.
<lumidragon>thanks eh :)
<kyamashita>ACTION is back
<alezost>lumidragon: Our Emacs searches for packages both in "site-lisp" dir and in "site-lisp/guix.d/<package>" subdirs. None is preferred. The former is where GNU Build System usually puts elisp files, and the latter is where our emacs-build-system puts them; both are fine.
<alezost>I personally hate "guix.d" name; I think we should get rid of it and just use "site-lisp/<package>"
<mthl`>alezost: I don't like it either. However After seeing what is done in Debian testing currently I guess It might be interesting to not put everything directly in site-lisp
<mthl`>Debian is using "elpa-src" subdirectory for "elpa-XXX" packages
<mthl`>and then the emacs package installed via apt appeared in M-x list-packages
<alezost>mthl`: I agree!! No one seems to see my point, I don't suggest to put all *.el files in "site-lisp", but in "site-lisp/<package>" instead of the current "site-lisp/guix.d/<package>"
***kelsoo1 is now known as kelsoo
<mthl`>yes that's what I meant
<alezost>then I don't understand, what's the problem with "site-lisp/<package>/*.el"?
<jlicht>alezost: Is there actually a technical issue with this as well, or are we really discussing the aesthetics of the extra 'guix.d'?
<mthl`>There is no problem for me, I was just pointing that maybe the extra directory could provide a useful feature if we were doing it the way debian does it
<mthl`>I don't know if it is feasible
<alezost>jlicht: there is no technical issue. AFAIU both "site-lisp/<package>" "site-lisp/guix.d/<package>" can be used equally, so I just don't like an extra "guix.d" level
<alezost>also I don't care what debian does :-)
<mthl`>even if it is convenient?
<alezost>mthl`: sorry, I don't understand what convenience and "useful feature" you mean
<alezost>could you explain?
<mthl`>packages installed via apt appears as read-only in list-package so they you can share dependencies between GNU Elpa/Melpa and Debian packages.
<alezost>oh, you mean appearing in "M-x list-packages"! I don't see the point since these packages can't be upgraded/removed as they are installed globally
<mthl`>the point is that you might want to install unstable version from MELPA and you can share the dependency with the packages installed globally
<alezost>mthl`: btw I don't think Debian does anything special, there is `package-directory-list' variable, so IIUC they just put the packages there, so they appear in the package list
<mthl`>OK, I don't know
<mthl`>Anyway it is quite new in Debian
<alezost>I guess if we rename "guix.d" to "elpa", the packages will also appear in the package list
<mthl`>yes of course
<mthl`>in debian the directory is name elpa-src
<alezost>is it added to `package-directory-list' variable?
<jlicht>does anyone see any use for a '--with-patch[es]=' package transformation option?
<mthl`>alezost: not directly
<alezost>jlicht: I don't have a need in it, but you can propose it on guix-devel, perhaps it will be useful for someone
<mthl`>They put '/usr/share/emacs/VERSION/site-lisp/elpa' in `package-directory-list'
<mthl`>and this directory contains the subdirectory for Emacs packages which then contains symlinks to the files in "/usr/share/emacs/site-lisp/elpa-src/PACKAGE/..."
<alezost>I think it's one of the default element of package-directory-list
<alezost>ah, I see, thanks for the explanation!
<mthl`>Anyway I ar
<mthl`>... agree with you than the name "guix.d" is confusing
<jlicht>heh, TIL that `#:parallel-build? #f` could have saved me quite some headaches XD
<bavier>jlicht: yes, those issues are sometimes difficult to diagnose
<jlicht>is there some way in which to somehow apply `#parallel-build #f` only to a subset of make targets?
<bavier>jlicht: you'd need a custom build phase for that
<jlicht>that is probably more of a hassle than it might potentially be worth then ;-)
<bavier>jlicht: or patch the makefile ;)
<jlicht>bavier: for my specific situation, it could potentially shave some 2 mintues off a build that takes about 31 minutes in total ;-)
<lumidragon>alezost: hi sry was away.
<lumidragon>and thanks for the emacs info.
<joshuaBPman>hello. So I did a completely stupid thing just now. I had installed guix with a seperate / and /home partitions. Well I downsized my /home partition w/o downsizing the filesystem. I've already ran mkfs.ext4 on my /home partiton again. So there's no way to salvage it. do I need to completely re-install guix? Or can I run reconfigure and be ok?
<cbaines>joshuaBPman, what is the current state of your system? e.g. does it still boot? can you login as root?
<joshuaBPman>cbaines: I cannot log in a my normal user. I am currently logged in as root. (running gnome as root with a terminal open).
<cbaines>If you are trying to use reconfigure to repopulate the lost files, it might work, and I see no harm in trying
<joshuaBPman>sounds good.
<joshuaBPman>well. I ran `sudo guix system reconfigure` and rebooted. and it didn't work. But I supposed that only reconfigured stuff for root. hmmm. I might just have to reinstall.
<cbaines>joshuaBPman, I don't think reinstalling is necessary yet
<cbaines>does your users home directory exist
<joshuaBPman>cbaines: yes.
<cbaines>Ok, I guess that is not sufficient to allow logging in as them?
<joshuaBPman>I guess not. :(
<joshuaBPman>My normal user home directory does not have a .guix-store dir.
<cbaines>The shadow package contains useradd, that might be able to help
<cbaines>I'm just looking at the documentation at the moment
<joshuaBPman>I can try that.
<cbaines>Another option that might work, would be to delete the user (using userdel), and then run reconfigure
<cbaines>If the account does not exist, and the home directory does not exist, then reconfigure might work?
<joshuaBPman>well after installing shadow, I still could not run useradd. So I'll try deleting /home/joshua and then rerunning `sudo guix system reconfigure /etc/config.scm'
<joshuaBPman>yeah. It didn't create the /home/joshua. I'm just going to reinstall. Won't be too hard. I'll remember to run guix pull before running guix system init
<cbaines>Did you try running userdel?
<joshuaBPman>guix didn't see that command on my system
<jsgrant>Does GuixSD support UEFI now? I'm thinking of jumping back into it all, sooner than later.
<jsgrant>Don't see anything explicity specifying this on cursory inspection; I'll go NixOS for now knowing it works, and maybe retrograde in that direction later.
<joshuaBPman>so I am re-installing guix. I just ran guix pull (before guix system init) and guix pull failed. It said no cod efor module (gnu packages asciidoc). so I guess I'll install an outdated version of guix. And then later update.
<mthl`>(gnu packages asciidoc) has recently be moved to (gnu packages documentation)