IRC channel logs

2015-12-03.log

back to list of logs

<fps>one approach would maybe be to spawn a vm, do the build of it and all its dependencies and their respective tests in it
<fps>afaict that would at least catch the propagated input issue?
<fps>or maybe not all of the dependencies..
<fps>oh, or maybe not
***HeisenbergsDog is now known as Guest70644
***Guest70644 is now known as HeisenbergsDog
<davexunit>ACTION installs GuixSD on his HTPC
<davexunit>so excited to finally be able to do this
<keverets>what was the blocker to installing before?
<keverets>lack of kodi?
<davexunit>yeah
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<davexunit>guixsd is installed :)
<davexunit>now to update to the latest guix master and install kodi
<jin__>hi, do you know how start libreoffice after install in guixsd?
<davexunit>jin__: like you do anywhere else? guess I'm confused
<jin__>after install, i can't find command to start libreoffice
<jin__>may be my profile its wrong
<davexunit>so you did a 'guix package -i libreoffice' ?
<davexunit>what is the output of 'ls $(guix build libreoffice)/bin' ?
<jin__>yes, i installed successfull. but when i try to launch the program calc or other not appear
<davexunit>what do you mean by "not appear"?
<jin__>the output is: soffice
<davexunit>so does running 'soffice' do anything?
<jin__>thanks, soffice is the command correct to start the libreoffice suite
<davexunit>awesome
<davexunit>(I haven't yet used libreoffice on guixsd)
<jin__>i start to test guixsd, installing some programs
<davexunit>great!
<davexunit>I hope you enjoy it and don't mind the current limitations too much
<apa512>i'm trying to ignore configure when building a custom package but the #:phases argument is seemingly ignored. any ideas? here's the package definition: https://gist.github.com/apa512/04e3533f9e19f39ef65d
<apa512>starting phase `configure is still shown when i attempt guix build -L custom-packages-dir -i unibilium
<davexunit>apa512: looks find to me
<davexunit>fine*
<davexunit>perhaps there is a different issue
<apa512>i thought so too. putting some nonsense like `(#:phases aoeu)) will still run the %standard-phases without complaining. misspelling arguments as argumentss doesn't work though, so it's not that the wrong file is used or anything like that.
<efraim>do you need srfi-1 for alist-delete?
<davexunit>efraim: it's re-exported by (guix build utils)
<davexunit>a module included by default in the builders
<davexunit>apa512: I just tried out your recipe.
<davexunit>I had to change the hash of the source code
<davexunit>because it was incorrect
<davexunit>after fixing that, I noticed that the configure phase was indeed skipped
<davexunit>and then there's a build failure when running 'make'
<davexunit>apa512: here's a recipe that builds http://paste.lisp.org/display/163967
<davexunit>I put this code in a file named "unibilium.scm" and ran 'guix build -f unibilium.scm' to build it
<apa512>davexunit thanks for helping out. still the same error unfortunately. it looks like my arch installation (https://aur.archlinux.org/packages/guix/) of guix is broken somehow.
<fps>ok, proceeding with my first bare metal install :)
<fps>and of course hydra is crapping out :)
<fps>ok, chucking on
<gr8>how do I test the Guix install image in virtualbox? It does only support booting from live ISO images. What format is the provided usb installation image?
<gr8>btw. thanks for working on guix, I am so excited to see it improve very fast
<fps>gr8: https://github.com/guix-nonfree/pkgs/wiki/VirtualBox-installation
<fps>gr8: the provided image is a raw imae
<fps>image
<fps>it's a little simpler with qemu btw
<fps> https://github.com/guix-nonfree/pkgs/wiki/qemu-installation
<gr8>the guide doesn't look simpler. But thanks, I think it works!
<gr8>totally unrelated question: what is a Web browser in the spirit of GuixSD that promotes privacy and freedom that you could recommend?
<fps>the second one is just a little more comprehensive ;) the virtualbox one skips all those details
<rabgulo_>hello guix community.
<gr8>I mean, a web browser that is extensible and hackable and gives me freedom
<fps>i don't know if uzbl is packaged yet
<fps>it's not :(
<fps>shouldn't be too hard though
<fps> http://www.uzbl.org/
<fps>it's basically a simple keyboard driven input handler around webkit :)
<fps>somewhat vim like
<fps>multiprocess when tabbed :)
<rekado>gr8: we have icecat packaged.
<rekado>it builds on top of the "mature" firefox releases.
<rekado>it's a GNU project and comes with usually sensible privacy settings.
<fps>and youtube even works on it :)
<rekado>it's a project that deserves more developer power, though.
<fps>i didn't even dare trying, but i was surprised to find it did :)
<rekado>I don't find uzbl very uzbl, to be honest.
<alezost>rabgulo_: hello, if you have questions, you may ask :-)
<rekado>I used it when it just came out and the frequent changes to the config file format made every update annoying
<fps>but uzbl is definitely way more hackable than icecat :)
<alezost>gr8: I use conkeror
<rekado>I'm looking forward to the new Emacs release with widget embedding.
<fps>*shudder* a text editor that is a windowing toolkit?
<fps>if there's a god then he will smite the emacs dev team to the deepest layers of hell :)
<efraim>now where was that blog post with emacs as pid1...
<rekado>emacs is not a text editor.
<rekado>it is my user interface, for everything.
<fps>:)
<fps>everyone is free to choose their own poison :)
<rekado>understanding that Emacs is not a simple editor is the first step to realising its powers.
<fps>i know. i use emacs on and off for 15 years or so
<rekado>I started with vim and laughed at Emacs.
<rekado>now Emacs is the glue between all programmes I regularly use.
<rekado>Emacs is a much better interface than the one-dimensional command line, in my opinion.
<fps>it's a great program
<fps>i just don't like it much
<fps>it has so many quirks you have to get used to
<efraim> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html?repost
<gr8>fps: thanks I'll take a look
<alezost>/me totally agrees with rekado
<alezost>Emacs is my universal interface as well :)
<gr8>what is the current status of Guile Emacs btw?
<fps>hmm, xfce is missing xfce4-power-manager
<fps>let's see
<fps>that shouldn't be too hard to package
<fps>um, will do later :)
<fps>bbiab
<fps>does anyone care to add a section to the manual about setting up git to produce diffs in the right format for sending to the ML?
<fps>or maybe explain it a little to me?
<rekado>git format-patch -1
<rekado>you just commit to your local repository and then format a patch with the above command.
<rekado>ACTION goes afk for a while, will answer questions later
<fps>rekado: ty
<fps>i like to use feature branches locally. i guess that works just fine with that..
<fps>ok, cool..
<fps>my guile-fu is still to weak to parse this error:
<fps> https://pastee.org/y88e6
<fps>this is xfce.scm:
<fps> https://pastee.org/hxpj9
<fps>oh, ok. i should use -L since it's a complete module i suppose
<fps>yay, got xfce4-power-manager running :)
<fps>now guixsd can stay on my laptop's disk ;)
<wingo>what does xfce-power-manager do? :)
<fps>wingo: manage power :)
<fps>wingo: dims the backlight of your screen, etc..
<fps>or _should_ put your system to sleep after an amount of inactivity
<fps>which i haven't got to work yet
<fps>i like to listen to lectures to go to sleep and the laptop should go to sleep after i fell asleep so the fan doesn't give me tinnitus ;)
<fps>ok, now i have two commits and git format-patch only formats the latest commit diff
<fps>and it has no manpage
<fps>hmm
<fps>ohm, they are in a separate package
<rekado>git format-patch -2
<rekado>gives you patches for the last two commits
<fps>rekado: haha, ok :) thanks a bunch.. i thought -1 was a format spec or something
<fps>but that makes sense, too
<rekado>you can also give it a commit id to start from, when you don't want the last few commits.
<fps>and if i want a single patch, then i guess i have to stage the commits?
<rekado>a single patch?
<rekado>I don't understand
<fps>fps@cherry ~/src/guix$ git format-patch 85dce718cb8acaffa8f961a5784588936147debd
<fps>0001-xfce4-power-manager-new-variable.patch
<fps>0002-xfce4-power-manager-new-variable.patch
<fps>that's two patches for two commits i suppose
<rekado>you would use "git format-patch commitid -1" to just get a patch for commitid.
<rekado>each commit gets one patch file.
<rekado>do you have two commits?
<fps>yes
<fps>since i had to correct an error
<rekado>if you want to squash multiple commits into one you need to use "git rebase -i start-commitid"
<fps>ok, thanks
<rekado>to correct an error in the last commit just use "git commit --amend"
<rekado>interactive rebase (git rebase -i) is useful when you need to edit unpublished history
<rekado>e.g. change past commit messages, reorder commits, squash multiple commits into one, etc.
<rekado>the default interface for this is a little quirky.
<rekado>it's a lot more convenient with magit.
<fps>will try that :)
<rekado>"git rebase -i startcommit" opens your editor with a "plan" showing you all commits since "startcommit". Each line represents one action to perform on the commit.
<rekado>you can reorder lines and change the first word into a different command.
<fps>yeah, the default editor "vi" wasn't on my system though.. will try exporting vim as EDITOR
<fps>doesn't vim usually get installed as "vi", too, and then have somewhat different behaviour?
<rekado>I think so, but I'm not sure if this is part of the "make install" target. Could be that it's just something distributors usually do.
<fps>ok
<davexunit>bah, silly order of operations issue in dmd
<davexunit>make-forkexec-constructor has optional arguments for setting the user and group the service should run as
<davexunit>but it runs setuid *before* setgid
<davexunit>so it drops user privileges but then cannot change group
<davexunit>because the user no longer has setgid permissions
<davexunit>oh cool, tiny let's encrypt client: https://github.com/diafygi/acme-tiny
<davexunit>still have to review those 23 patches to get the official client in...
***ttuegel_ is now known as ttuegel
<rekado>I don't understand what's going on here: https://github.com/xianyi/OpenBLAS/issues/703
<rekado>this brada4 person is quite hostile and asserts that our valgrind and bash are broken. And that the R build is wrong.
<rekado>It's hard for me to understand what the claims exactly are.
<davexunit>I can't make sense of it either
<davexunit>I just know that brada4 is kind of a jerk
<davexunit>but the whole discussion is pretty incoherent
<tsyesika>hey, I am trying to see if i can get any further with bug #20433 (http://lists.gnu.org/archive/html/bug-guix/2015-04/msg00062.html) I have checked and the module which makes the keyboard function in trisquel (usbhid) is loaded in guix 0.9.0 but the keyboard doesn't work, does anyone have any what could be going on?
<rekado>tsyesika: what kind of computer are you using?
<rekado>I remember something about problems with Apple hardware.
<tsyesika>macbook (says in theticket)
<tsyesika>macbook air 6,2 to be specific
<rekado>oh, maybe it was just your case that I remembered :)
<tsyesika>it's not a free software issue though, as i said, the keyboard functions out of the box just fine in trisquel, it's a standard internal usb keyboard afaik
<tsyesika>rekado: probably :P
<rekado>tsyesika: is there any additional information you could give us? E.g. relevant excepts from the kernel logs of both systems?
<rekado>it might be that trisquel passes a couple of hid module options when an Apple keyboard is detected.
<tsyesika>i shall have a look
<rekado>another potentially interesting thing is kernel parameters passed when using trisquel.
<davexunit>if it's HID, one would expect it to "just work". I'm quite confused by this one.
<rekado>tsyesika: at what point does it stop working? Is it still working in GRUB and then stops as Linux boots?
<davexunit>tsyesika: could you try running 'sudo modprobe hid-apple' ?
<davexunit>(assuming you have other means to input commands)
<davexunit>I ran 'find /run/current-system/kernel/lib/modules -name "*.ko" | grep apple'
<davexunit>and noticed apple specific modules
<rekado>tsyesika: do *any* of the keys produce characters? Or is all just dead?
<bavier>rekado: I now of an issue in gotoblas dgemv for large problem sizes; the same may be the case in openblas
<bavier>*know
<tsyesika>rekado, davexunit: give me a few minutes, I'm currently getting the dmesg output which took some doing as network didn't work and the mac only had 2 usbs so ended up writing a script, will try what you've suggested and feedback shortly
<piyo>hello my rpi2 crashed and I doubt the fs integrity, is there a way to verify the /gnu/store ?
<bavier>piyo: `guix gc --verify`
<piyo>woo, stay tuned?
<piyo>:-)
<piyo> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix_002dgc.html there is no --verify documented... is a doco problem?
<davexunit>yup!
<bavier>piyo, davexunit: no, piyo, that's an outdated manual page
<bavier> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html#Invoking-guix-gc
<piyo>I got that link from google search on "guix gc --verify" :-/
<piyo>I also see the updated docs, thanks.
<piyo>path `/gnu/store/95cc1szyckd3pipz9z9m0c8y6n9qv9fb-module-import' disappeared, removing from database...
<tsyesika>rekado: well here are the two dmesg's you asked for http://pamrel.lu/121a9/ (guix) and http://pamrel.lu/9dc5a/ (trisquel)
<tsyesika>i shall try loading the apple hid module which i noticed was loaded on trisquel so i bet that'll be it
<lfam>Let's Encrypt is opening their beta program to the public today. It would be nice if someone tested the patch series that provides their client.
<davexunit>lfam: yes, I've been meaning to.
<davexunit>do you have a branch that I could look at?
<davexunit>23 patches is a lot.
<davexunit>lfam: if there's a branch I can pull, I can do the clean up, test, and push upstream.
<lfam>davexunit: I've done a little work to address the questions I asked in my email, specifically the questions about python-3 -> python-2 dependency issues. I keep rereading the Efraim's emails of 2015-11-25 regarding this subject, and I still don't understand the heart of the issue. But when I made "proper" python-2 packages so that the python-2-specific dependencies didn't muddy up the python-3 packages, I had the same kind of problems as
<lfam>Efraim.
<lfam>davexunit: Okay, I will push it now.
<davexunit>oh I wasn't aware of problems here
<lfam>davexunit: Well, my original patch series did things like specify python-setuptools as a native-input for python-zope-event, even though it didn't need it, because python2-zope-event needs it. I was being layz and just used the automatic translation of package-with-python2. When I tried to split them up "properly" it goes awry.
<tsyesika>davexunit, rekado: okay so! keyboard works fine in guix's grub, all the keys are dead, not some of them and doing a modprobe on hid-apple doesn't make the keyboard work
<lfam>davexunit: https://github.com/lfam/guix/commits/wip-lets-encrypt
<lfam>5834a8c is what I submitted to the ML. The next commit is just a version bump from Let's Encrypt. It builds but I haven't tested it. The rest of the commits are fixups that I have not rebased yet.
<tsyesika>(the all the keys are dead comment isn't about grub btw, it's about once i've booted in, rekado asked if all keys were dead)
<lfam>In those "fixup" you see the python-3 -> python-2 problems emerge
<davexunit>tsyesika: hmmmmm
<davexunit>this is very confusing
<davexunit>lfam: thanks!
<lfam>I'm sorry, 5834a8c is not the same as what I sent to the ML. I did rebase some changes in. Specifically, the correct url for the dialog package and a changed commit message for python-parsedatetime
<lfam>But it is functionally the same because the "correct url" does provide the same tarball
<lfam>Be careful about hitting Let's Encrypt per-account and per-domain rate limiting — it was pretty severe as of a week ago. The limits are higher for test certs.
<davexunit>lfam: okay
<davexunit>I don't have time to do a full test, so I'm just rebasing your patches onto the current master
<davexunit>I'm a little annoyed at how let's encrypt works, honestly.
<davexunit>I didn't realize that it forces you to have downtime every 90 days to update certs
<davexunit>unacceptable!
<bavier>how much downtime?
<davexunit>seconds or minutes, I think.
<lfam>About 10 seconds
<davexunit>but it *forces* you to run a web server on port 80 to request a new cert
<bavier>but yeah, that any downtime is required is unfortunate
<davexunit>stop nginx, use new config somehow, start it back up, run let's encrypt, stop nginx, use regular config, start it back up
<davexunit>not my idea of a good workflow
<lfam>Actually, you can use your existing webserver, you don't have to use theirs. I didn't go that route but you put a file in a specific url at the root of the www tree. I'm not sure of the details
<davexunit>so you can just copy a file somewhere without downtime?
<lfam>I mean, they provide short-term DV certs for free. If you can't accept 10 seconds of downtime every 90 days then you probably also can't accept DV.
<davexunit>what is DV?
<lfam>Domain validation. They only validate to your users that they have connected to the right domain. As opposed to EV (extended validation) which validates YOUR identity
<lfam>So, it's not for "enterprise" scenarios
<davexunit>sure, but I expect even my self-hosted stuff to be up all the time
<lfam>The EV stuff is how other authorities justify the cost, because they have to do a whole song and dance of making sure you are who you say you are.
<davexunit>it makes for a complicated workflow, too.
<davexunit>having to stop other daemons and such
<davexunit>I'm not sure how to write a guixsd service that could do this
<lfam>Okay, I get that. I personally don't mind the 10 seconds of downtime every few months. I can do something like "stop nginx && lets-encrypt; start nginx"
<lfam>If it gets more complicated than that, then it's more complicated than that.
<lfam>I swear the Let's Encrypt docs have gotten less comprehensive. I can't find the part that lists the renewal methods
<lfam>Here you go: http://letsencrypt.readthedocs.org/en/latest/using.html#plugins
<lfam>You want the "webroot" method because it doesn't require downtime
<lfam>I assume you'd have to "reload" the server but I guess that depends on what you are running. I'm not sure.
<lfam>Regarding DV vs EV, the real point is that DV is about encryption, and EV is about (ersatz) authentication.
<lfam>I think of Let's Encrypt as a project to raise the cost of total surveillance
<davexunit>lfam: someone just showed me a way to use the client without downtime
<davexunit>via the 'webroot' authenticator method http://letsencrypt.readthedocs.org/en/latest/using.html#webroot
<lfam>Yes, see above ;) I forgot to "call" your name
<davexunit>oh :)
<davexunit>didn't see that
<lfam>I guess I should have put that in my mail. Maybe more people would have tried the patches
<davexunit>sorry for the delay, I think a lot of us are a little overwhelmed with patch review right now.
<davexunit>I can probably can't all the patches cleaned up and merged by the weekend.
<davexunit>s/can't/get/
<davexunit>weird typo
<lfam>I've been thinking about that lately. I can start trying to review some of the simpler patches. What to check? That it lints, builds and the program runs cleanly? Check for basic style errors?
<davexunit>yeah basically that
<lfam>Of course whoever pushes it will have to either trust my review or do some of their own. But it could help as a "sanity check" for the basic stuff.
<lfam>Okay, time to learn how to automatically apply patches from mutt
<davexunit>for frequent contributors, I don't do much in the way of thorough checks, I just check for style issues mostly.
<davexunit>I assume that they have linted and tested that it builds
<lfam>Yeah, the Guix / Nix system is so robust that a bad push is not the end of the world. It's not like Debian where a bad push can break a system so badly that it's faster to reinstall from scratch.
<lfam>I've been thinking about that, too, since I had to reinstall my debian-armhf system :(
<lfam>It's a really concrete way that this model saves tons of human time
<avoine>what could be the cause of: warning: collision encountered: /gnu/store/44m...-xfce-4.12.0/bin/startxfce4 /gnu/store/hn6a...-xfce4-session-4.12.0/bin/startxfce4 ?
<bavier>avoine: did you install both xfce and xfce-session packages?
<avoine>bavier: no only xfce
<bavier>avoine: ok, I see
<avoine>bavier: oh wait I have installed xfce-session manually yeah
<avoine>ill remove it
<lfam>avoine: For some reason both of those packages are in your profile and providing the same-named binary. Guix will choose one at random. You could use the `guix gc --r...` to find out what is propagating the "extra" package
<lfam>Aha!
<lfam>Did you install it to test it out and then forget to remove it? You can use `guix environment --ad-hoc foo` to do that. That way your profiles don't get "polluted" and the garbage collector can remove the unneeded software automatically.
<avoine>no more conflit :P
<bavier>the problem is that xfce provides a symlink to xfce-sessions's startxfce4 while at the same time propagating its xfce-session input
<bavier>but maybe that's not an issue, I haven't tried it myself
<lfam>Is it supposed to do that or is it a bug in the package definition?
<lfam>It's an issue when your terminal gets clobbered by several screens worth of conflict warnings. And sometimes the conflicts are real problems, like with GNU Parallel and joeyh's moreutils' parallel.
<bavier>lfam: sure. we certainly want to minimize unnecessary conflicts
<davexunit>I believe we have a bug open about the absurd amounts of conflicts
<bavier>I'm guessing the symlink was made so that one can do things like `guix build xfce`/bin/startxfce4
<bavier>but one could just as easily s/xfce/xfce-session/
<lfam>It's funny. The thing that finally got me to sit down and install Guix on Debian was GNU Parallel vs moreutils. But the joke was on me: I misunderstood Guix, and the conflict is still an issue ;) Of course, it's much easier to work around the problem in Guix.
<davexunit>lfam: 'guix environment' is good for picking the thing you want.
<lfam>Exactly!
<davexunit>it's also easy to write a new package that tweaks the name of one of those binaries
<lfam>That is also on my todo list: moreutils-minus-parallel
<davexunit>so yeah, all sorts of ways to deal with name conflicts :)
<lfam>Or, moreutils-perpendicular
<lfam>I'm glad to see people complaining about the lets-encrypt dependency graph all over the net.
<lfam>Vindication :)
<davexunit>haha
<lfam>But you are the only person complaining about the circular dependencies. Oh well.
<davexunit>because no one else runs test suites
<davexunit>python, ruby, node, etc. they *all* have this problem
<davexunit>and no one notices because no one else runs each other's test suites.
<davexunit> https://www.openssl.org/news/secadv/20151203.txt
<davexunit>latest OpenSSL security advisory
<lfam>I'm leaving for a while. If there isn't a patch to update openssl in a few hours, I'll send one.
<efraim>python-mock 1.0.1 is apparently "a thing" so when it comes time to update it I think it makes sense to have that as the extra version
<efraim>assuming there isn't a later 1.0.x version
<efraim>also, we should think about updating libssh2 to 1.6.0
<davexunit>efraim: what does 'guix refresh' say about how many rebuilds we'll need?
<efraim>hundreds
<davexunit>damn
<efraim>Building the following 302 packages would ensure 687 dependent packages are rebuilt
<efraim>it could be worse, pkg-config had their 0.29 release :)
<davexunit>is this a security update?
<efraim>i didn't hear anything about either
<efraim>guix lint->cve checker!
<efraim>libssh2 has some long lines, neither report cve-s
<efraim>from mock's readme: "mock is now part of the Python standard library, available as unittest.mock in Python 3.3 onwards."
<fps>sadly i had to take the publish service on fps.io:9999 down, but it'll be back in a couple of days with somewhat clarified traffic constraints :)
<fps>which might turn out to be a couple TB a month
<fps>and possibly a TB of disk or so :)
<fps>i have a related question/feature request
<mark_weaver>bah, the openssl-1.0.2e tarball contains a bunch of invalid symlinks pointing nowhere :-(
<fps>when you configure guix to use different substitute servers, is it possible to make it choose them at random?
<fps>or round robin?
<fps>so the load is distributed among different services?
<fps>i would probably make this a prerequisite for making it truly public
<tsyesika>can anyone suggest a good usb wireless adapter, ideally low in porfile, i don't want something big sicking out my laptop
<fps>i have one here that works with the linux libre kernel and is small
<fps>hold on
<fps>it's called "gembird NICW-U3"
<bavier>tsyesika: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb
<fps>that one is even smaller :) nice
<tsyesika>fps: http://www.amazon.de/Gembird-NICW-U3-Wireless-Lan-Adapter-schwarz/dp/B000WXHUN0 this thing? looks big
<fps>tsyesika: yeah, it's much smaller still than another one i had lying around :)
<fps>sorry, i'm out of the loop ;)
<fps>bavier's suggestion looks good
<fps>bavier: how much are those?
<tsyesika>44 USD apparently
<fps>oh right, once you add it to the cart you get a price
<bavier>$25 I think
<tsyesika>bavier: it's 44 (would work out at 64 USD ish post shipping and VAT)
<tsyesika>for me
<tsyesika>seems pricey
<roelj>How can I become 'root' on a GuixSD installation?
<rekado>roelj: "su"
<rekado>or you log in as root.
<roelj>And what would the password be?
<roelj>I don't think I set it, I only set a password for my regular user
<bavier>roelj: "sudo su -" should work
<mark_weaver>if you didn't set it, there's no password
<roelj>It asks for the password twice, then says "su: authentication failure"
<roelj>Can I (re)set it by booting in single user mode?
<mark_weaver>roelj: have you tried logging in as root from a text console?
<mark_weaver>(i.e. not using su)
<mark_weaver>sneek: later tell lfam: thanks for offering to do the openssl update, but I took care of it. the 'security-updates' branch not contains updates for openssl, libxml2, and pcre.
<sneek>Okay.
<mark_weaver>sneek: botsnack
<sneek>:)
<roelj>mark_weaver: That worked. Thanks
<mark_weaver>roelj: that's good! :)
<tsyesika>so, I don't suppose anyone has any other ideas on my macbook keyboard issue (#20433 - https://lists.gnu.org/archive/html/bug-guix/2015-04/msg00062.html) I'm really at a loss where next to look
<roelj>tsyesika: Does the keyboard work in grub?
<tsyesika>yep