IRC channel logs

<m_kim>Hello, I writed shepherd service like in <https://nixos.org/wiki/NixOS:extend_NixOS>. Can anyone explain why variant with "cut" on line 73 fails <https://github.com/mnd/guix-mnd-pkgs/blob/master/mnd/services/irssi.scm>?

<kyamashita>Has anyone packaged a calendar package that looks for zone.tab

<kyamashita>GNOME's calendar has no references to zone.tab, and it still crashes.

<kyamashita>Here's my recipe. http://paste.lisp.org/display/315651

<kyamashita>Fixing this issue would allow orage (XFCE's calendar) and GNOME calendar to be packaged.

<ajgrf>guix search cron

<ajgrf>sorry wrong window

<kyamashita>ajgrf: You might try "guix package -s cron"?

<ajgrf>kyamashita: nope, i have a function in my bashrc that wraps guix

<kyamashita>ajgrf: Nice! The joys of typing in the wrong window. :)

<ajgrf>yeah, if it keeps happening i will need to cook up some elisp to delay my irc messages a few seconds and let me cancel just in case

<calher>ajgrf: mcron?

<ilit>Getting soft lockup during 'guix system init' https://imgur.com/a/IT3Xc Any idea on how to fix/avoid? Thx.

<ilit>(inside virtualbox)

<z0d>ilit: I managed to install Guix in Vbox. what are your VM parameters?

<ilit>z0d: I'm trying to install GuixSD as a whole, 4096MB RAM, 4CPUs(AMD), PAE/NX enabled, Para. Default, Nested Paging enabled; Controller IDE PIIX4...

<ilit>followed instructions from here: https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation

<z0d>I left most things on default.

<z0d>Enable VT-x is on

<z0d>Chipset is PIIX3.

<z0d>IDE controller is PIIX4, just as yours

<ilit>PIIX3 for me too

<z0d>Virtualbox 5.0.16

<ilit>5.0.20

<z0d>I used 2 CPUs

<ilit>You're on an Intel though? (unsure if VT-x means that)

<z0d>yes

<z0d>it's the same as AMD-v

<ilit>got it

<ilit>z0d: the thing is, on host I've to boot into 4.5_rc7 (not any 4.6 kernels) else virtualbox crashes with guru meditation

<z0d>guru meditation :-D

<ilit>unsure if this is due to some CPU bug or something else

<ilit>but at least this following CPU bug I've handled (which affects chromium for me) https://bugs.chromium.org/p/chromium/issues/detail?id=599899

<z0d>wow

<ilit>unfortunately, since I can't get GuixSD to go past this hang, I'll have to go back and try NixOS :'-(

<fhmgufs>Every time I open any Guix sources in Emacs I first get a message concerning some unsafe local variables. What's the problem here?

<civodul>Hello Guix!

<efraim>hai!

<taylan>fhmgufs: you can permanently mark them as safe

<taylan>by hitting ! when it asks, IIRC

<efraim>my GSoC tax form was rejected, most likely because I forgot to sign it

<fhmgufs>taylan: Yes, I already have done that, thanks anyway. :)

<fhmgufs>But why are they "unsafe"?

<taylan>emacs being overly careful I guess

<taylan>or not being able to deduce the safety

<fhmgufs>Ok, no problem then.

<jmd>Why is it that when I do command like guix build, I often get _multiple_ messages like substitute: updating list of substitutes from 'http://mirror.hydra.gnu.org'... 100.0%

<efraim>i believe some of them are recursing further up/down the dependency tree

<jmd>I think they should be consolodated into one.

<jmd>(if they refer to the same server)

<civodul>jmd: yeah, the fact that they are not coalesced comes from grafts

<civodul>this is a known limitation

<jmd>Ahh.

<civodul>efraim: re GSoC, what impact does it have?

<efraim>I signed my name, scanned it back in and sent if off again

<civodul>good

<efraim>I also misspelled the name of my school the first time and had to resubmit my proof-of-studentness twice

<jmd>Seems reasonable! I would be suspicious if someone claimed to be a student but was unsure of the name of their institution.

<efraim>it gets better, I misspelled it on their online form, so I fixed that first and then uploaded the exact same document a second time

<z0d><-:

<civodul>heh

<jmd>We have over 3000 packages now. I know that Ludo is sceptical, but I think guix is going to need some kind of "tagging" or "categorisation" scheme in the not-to-distant future.

<civodul>ACTION is skeptical :-)

<jmd>civodul: I'm glad we agree on that then!

<civodul>:-)

<civodul>i wonder if we could make "GNOME Software" work with Guix somehow

<jmd>Or scrape categories from directory.fsf.org

<civodul>yeah, that could work

<z0d>+1

<civodul>i think categories would be more useful/practical than tags

<z0d>I think tags would work if you stick to a few

<jmd>I'm not sure what the difference between categories and tags are in your book.

<jmd>To me the difference is, that a package can belong to more than one "tag", but can be a member of only one "category".

<z0d>we're on the same ship then

<z0d>some packages are hard to categorize

<jmd>z0d: That is true. and much comes from the user's perspective.

<z0d>is Emacs an editor or an IDE? or something else?

<jmd>How about this idea then, which I think is a first:

<jmd>How about a tagging/categorisation ssystem using fuzzy logic.

<jmd>Thus, emacs has 0.5 membership in editor 0.6 in IDE, 0.1 in shell...

<z0d>how do you display it?

<z0d>for users it might be weird to see numbers

<jmd>I wouldn't normally attempt to. But it would mean that one could make search functions which (hopefully) would retrieve pkgs which the user was looking for.

<jmd>That way, a search for "shell and editor" would return a list with emacs at the top, but a search just for "shells" would have emacs right at the bottom.

<z0d>sounds good, but you need to have a solid implementation then

<jmd>... like everything ...

<z0d>I like the idea

<jmd>But you are right. An uncontrolled proliferation of tags/categories would be a bad thing.

<civodul>IMO we should think in terms of how UIs would present the extra info, and how users would take advantage of it

<civodul>that's why i mentioned "GNOME Software": AFAIK it categorizes stuff

<jmd>I don't know that.

<ilit>I managed to make GuixSD work in virtualbox (set many settings at once including only 1 CPU core) but now I realize I should've specified somewhere in config.scm that my root is btrfs not ext4. Do I have to reinstall as ext4 ?

<ilit>(since on boot it won't find my root)

<ilit>Or, there's a way to tell config.scm to expect root to be btrfs ? and rebuild from config.scm whilst booted from installcd

<z0d>doesn't Guix only support ext4 as of yet?

<ilit>z0d: I kind read that in the manual to be yes, but unsure

<ilit>kinda*

<ilit>But I don't see any good reason for it to be so

<z0d>probably someone here knows the answer

<iyzsong>GuixSD doesn't support btrfs as root yet. I think add btrfs.fsck (which is just `true' and does nothing) to the initrd may help, also more work is needed for subvolumes.

<ilit>For the record, diff-ing *.vbox{,-prev} I want to mention what I changed(all at once) that made GuixSD not hang(as I've mentioned before): cpu count from 4 to 1, HardwareVirtExNestedPaging to false, PAE to false, Chipset from PIIX3 to ICH9, AudioAdapter controller="AC97" driver="Pulse" from true to enabled="false" and StorageController(IDE, host i/o cache on) from PIIX4 to ICH6

<ilit>iyzsong: thanks, I'll reinstall with ext4 (it took 113mins with btrfs btw :D)

<z0d>have you tried with 2 CPUs without changing the other parameters?

<ilit>z0d: nope, I changed them all at once :D

<ilit>aka I wanted to be sure

<ilit>But I can experiment now, if you're interesting in finding out (like I am) what was the culprit, z0d

<z0d>I'd be interested in seeing if using 1 or 2 CPUs solves the problem

<z0d>if you have the extra time

<ilit>Btw, is there a non-hacky way of getting vboxsf compiled while booted from the usb install image? it seems useful for backup up and inserting my config.scm from host

<ilit>z0d: since I've to install on ext4 I'll be redoing everything, so I'll try with 2 CPUs + my former virtualbox config

<ilit>Ok, I want to be sure, so I'm reproducing the issue with *.vbox-prev and THEN switching to 2 CPUs ;-)

<ilit>(grrr, I got owned, exiting Virtualbox before backing up *.vbox-prev only to realize it overwrote it with the new!)

<ilit>(doing it manually then)

<z0d>oh yeah, I know that feeling

<ilit>This duplication https://imgur.com/kPuE6tV seems to be because it spans 2 lines instead of one

<ilit>it seems to me it wouldn't duplicate the line if the % would fit in one line as expected

<ilit>What do you guys use(presumably not zile) in order to be able to look in your config.scm and be like take me to the definition of THIS function ?

<ilit>(about duplication: also this https://imgur.com/h1OTY0u which makes more obvious what I said above )

<ilit>and unresponsive(only Enter works): https://imgur.com/a/0OOXT Next, switching to 2 cores

<efraim>i used zile when i set up guixsd, but otherwise I use vim

<efraim>I didn't realize until later i could've just guix package -i vim and been right at home

<z0d>isn't it blasphemy to use vim on the Emacs of distros?

<calher>z0d: It's not a sin to use a free version of vi, it's a penance.

<civodul>probably we should add elvis or some similarly small vi clone in the installation image

<calher>why not nvi

<civodul>or nvi, dunno

<calher>I'm getting back into Vim again.

<calher>Still loyal to Emacs, though.

<ilit>efraim: thanks for that command (guix package) - I haven't read that far into the docs yet and I could've used it to get emacs(perhaps). Maybe a mention of this in the install info on Alt-F2 would've been great

<ilit>wish someone would fix the duplication of lines though :D I would, if I knew where to grep

<ilit>z0d: system hang with 2 cores too, just now

<ilit>z0d: https://imgur.com/Za6g6Ep

<ilit>not even Enter works(currently)

<ilit>(trying 1 core next)

<ilit>one thing I notice with 1 core, is that the 'adding groups' at boot do not take 2 sec each, but rather 200ms or something aka faster - odd(?)

<z0d>it's probably not the cores then. it worked fine with 2 cores for me

<civodul>yeah, this should take no more than a few 100ms

<civodul>i recommend using QEMU, see https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html

<calher>civodul: i couldnt get it to work on libreboot x200

<ilit>civodul: I guess the "advantage" with using virtualbox is that I would see any bugs that I would get if running on bare-metal since it's (apparently) using my own CPU not an emulated one. (+I don't have that qemu image(and ability to create it yet) and seems unavailable in Download section on website)

<civodul>QEMU is free software whereas VirtualBox requires non-free software to be built, and i think you'll find more people with experience with QEMU here

<random_nick>ilit: qemu pretty much uses the host cpu too

<rekado>looks like the xwidgets feature of Emacs 25 requires webkitgtk-2.4.

<ilit>random-nick: alright, my superficial assumption is probably flawed. I'll try qemu as soon as I can make the .qcow image(need guix). Meanwhile, with 1 CPU it didn't hang yet ( z0d ) and my guess is that it won't(it went on for too long already)

<efraim>not 2.10?

<ilit>(uptime: 1h31min, with 1 CPU core in Virtualbox, no hang; hangs with 2 and 4 cores)

<ilit>(this during: guix system init /mnt/etc/config.scm /mnt booted from usb media)

<z0d>giving too many cores to a VM isn't usuallt a good idea anyways

<ilit>(kernel: 4.5.0 )

<z0d>usually*

<ilit>z0d: well, I've not experience anything like this before, tried manjaro, gentoo and nixos - maybe they have different kernels?

<ilit>(in Virtualbox, always 4 cores)

<z0d>I'm just saying the you probably just slowing down your VM with 4 cores

<ilit>z0d: you're probably right, I didn't look into this; however that 'adding group' is definitely slower than with just one core

<ilit>What if that is true only for the Libre kernel ? :D (just a random thought)

<z0d>the number of cores? I think it's a quite universal rule as the hypervisor has to keep them in sync

<ilit>All done(one core): https://imgur.com/Z8hyL91

<ilit>z0d: but does that equate with slower overall performance? than just using 1 core

<ilit>(oh I meant the slower with >1 cores being true only on Libre kernel)

<z0d>yes, usually. depends on your workload, of course

<ilit>Alright, I was assuming heavy compiling. Anyway, after a guix system init can I change config.scm and run some guix command to update what the former command did?

<ilit>z0d: you were right, 1 core is faster than 4 cores, 64sec vs 132 sec (uptime) Tested while compiling chromium on host, but still!

<ilit>(that was uptime while booting a now broken nixos installation; broken because database malformed lol dang out of space!)

<ilit>So yeah, I stand corrected in my wrong assumptions ;-)

<ilit>(and ignorance)

<civodul>the lib/python2.7/test directory in python takes 25 MiB; anyone knows if it can be safely removed?

<civodul>Steap maybe?

<Steap>hum

<Steap>is it in the source, or built during installation ?

<civodul>it's installed, but it corresponds to Lib/test in the source

<civodul>that really looks like unit tests, dunno why it's installed

<efraim>does it test python2.7 or is it used during testing of python programs?

<civodul>Nixpkgs leaves test_support.py* and removes the rest

<civodul>efraim: these are tests of Python itself

<Steap>civodul: yes, I believe they are unit tests

<efraim>perhaps a pre-install phase with (delete-recursively "/test/[!test_support.py]"

<Steap>is it also an issue in Py3 ?

<Steap>Because Python 2 should disappear in 2020

<efraim>almost there!

<Steap>maybe we can just wait and let the issue solve itself.

<efraim>before or after we remove i686?

<Steap>hehe

<Steap>Just imagine the nice patch that removes all that Py2 crap

<Steap>we still find i686 machines, I think :/

<efraim>debian is about to remove i586 support

<Steap>what is i586?

<efraim>the early pentium generations of x86 iirc

<civodul>ACTION tries that

<civodul>i think Py3 has the issue too

<Steap>damn

<Steap>efraim: I don't think I've ever known that

<efraim>/r/debian or /r/linux linked to a debian mailinglist post mentioning it, I don't really know that much about where the generation splits are

<joshuaBPman>hello, I'm using a macboox 7,1, and am having trouble getting guix to install. I used `sudo dd if=/path/to/guiximage of=/dev/sdb` to burn the image onto my usb stick. But I could not boot into it like I normally do (press the option key and then select the usb image).

<joshuaBPman>right now I'm in the grub command line trying to get it to boot from my usb stick.

<joshuaBPman>I'm really not sure how to do that though. Can anyone help me?

<cbaines>Hey joshuaBPman, are you following the instructions here https://www.gnu.org/software/guix/manual/html_node/USB-Stick-Installation.html#USB-Stick-Installation ?

<joshuaBPman>cbaines: yes.

<cbaines>If so, check that you remembered to decompress the image, and run sync before you unplugged it (to make sure all the data has actually been written).

<joshuaBPman>I've used those same instruction for the debian image, and was able to boot into the debian image fairly easily.

<joshuaBPman>I did actually uncompress the image, I did do the ddd command, but what do you mean to run sync?

<joshuaBPman>dd*

<cbaines>Are you using GNU/Linux to run dd?

<joshuaBPman>yes.

<joshuaBPman>I am running parabola to run that command.

<cbaines>sync is a program that will force cached writes out to the actual device

<cbaines>So just run sync (as root) after the dd command finishes

<joshuaBPman>ok I'll try it.

<joshuaBPman>cbaines: I ran the dd command again, ran sync as root afterwards, but still can't find the usb in my bios to boot from it. Now I'm trying to use grub to force a boot from the usb stick.

<joshuaBPman>wooo hoo!!! I figured it out!!!!

<cbaines>Great :)

<joshuaBPman>for anyone else who might run into this issue, when you see grub press "c", on the command line run these 3 commands `set root=(hd1)` `chainloader +` `boot`

<adfeno>joshuaBPman: Wheren't you able to make your BIOS boot the live media directly?

<adfeno>Because, as far as my newbie experience goes, it should be possible to do so by doing: sudo dd if="guixsd_image" of="/dev/main_device_block_without_numbers"; sudo sync

<joshuaBPman>adfeno: I was not able to boot from the usb image directly.

<joshuaBPman>I run a macbook 7,1 , and for some reason it did not see that I could boot from the usb.

<joshuaBPman>BUT it does let me boot that way from a debian image.

<adfeno>Hm....

<joshuaBPman>hello, anyone know how to boot from a usb stick if all you have is grub rescue?

<joshuaBPman>nevermind I think I'm going to boot from an arch install image, re-install grub and start again

<joshuaBPman>hello, I'm trying to install gnu guix and I just ran the command `hurd start cow-store /mnt`

<joshuaBPman>I am getting the error message "herd exception caught while executing 'start' on service 'cow-store' error in procedure rmdir: device or resouce busy

<joshuaBPman>anyone have any tips how I can fix this?

<efraim>sounds like there's something wrong with the mount point

<efraim>is everything mounted correctly?

<joshuaBPman>I believe so.

<joshuaBPman>I've got / mounted on /mnt

<joshuaBPman>and /home mounted on /mnt/home

<joshuaBPman>I've ran makeswap and swapon /dev/sda3

<efraim>do you already have a /mnt/gnu/store maybe?

<efraim>I haven't done a lot of debugging of installs

<joshuaBPman>efraim: I do not have a /mnt/gnu/store.

<joshuaBPman>hmmm.

<joshuaBPman>I didn't have a problem with this command the last time I tired it.

<joshuaBPman>I do have a /mnt/guix-inst

<joshuaBPman>should I remove that directory and try again?

<joshuaBPman>there's nothing inside of it.

<efraim>sure, try that

<joshuaBPman>sorry

<joshuaBPman>it's actually /mnt/tmp/guix-inst/

<joshuaBPman>bummer no dice.

<joshuaBPman>maybe I already ran that command once. My 'mount' command just showed a bunch of unionfs stuff. So maybe it did work already...

<joshuaBPman>so in my config.scm is (device "/dev/sda") ok? or does it need to be (device "/dev/sda1") for the grub-configuration?

<cbaines>joshuaBPman, just /dev/sda

<joshuaBPman>thanks cbaines!

<lfam>Do we have 'websvn'? http://seclists.org/oss-sec/2016/q2/257

<joshuaBPman>well I just ran guix system init /path/to/config /mnt

<joshuaBPman>I'll let ya'll know if a bit if I'm successful in installing guix

<efraim>don't think we have websvn, and it doesn't look like an output of subversion

<lfam>efraim: That's what I thought

<ilit>Guys, what's wrong with the fonts on GuixSD? comparison with NixOS https://imgur.com/a/pyugX

<wingo>please don't assume we're all guys. tx :)

<davexunit>ilit: we'd all appreciate it if you'd be more constructive.

<davexunit>fwiw, my xfce fonts look like the first image.

<ilit>guys is actually gender neutral, at least in that context

<joshuaBPman>with respect, I agree with ilit

<davexunit>I've *never* seen that font used in my windows on GuixSD>

<joshuaBPman>even though wingo is pretty much a B.A.

<mark_weaver>guys is not gender neutral. I'm with wingo on this.

<ilit>heh

<mark_weaver>please let's keep this space a comfortable place for women

<ilit>well, from what I've learned / picked up (and what I meant) guys refers to 'all you people' and definitely includes women

<joshuaBPman>With respect gentlemen, it's not an insult to women to use the phrase guys. In classic English the masculine form is the default form to include both genders.

<joshuaBPman>mankind for instance refers to men and women

<ilit>+1

<joshuaBPman>"one small step for man, one small step for mankind."

<ilit>Anyway, I've no explanation why the font is that way on GuixSD...

<joshuaBPman>there's nothing offensive or anti-woman about that phrase.

<mark_weaver>as a rule, geeky men are usually terrible judges of what is comfortable for women.

<ilit>Maybe some Xresources settings?

<davexunit>perhaps it's a regression

<davexunit>I've really never seen this font

<ilit>or could it be missing fonts and defaults to some weak one?

<joshuaBPman>ilit: I've no idea. why the fonts look weird. I'm actually trying to install gnu guix for the first time now. It looks like it compiling all of the packages...

<davexunit>pasting the OS config and the guix commit you built it with would allow someone to try to reproduce

<davexunit>joshuaBPman: did you run 'guix pull'?

<ilit>cool joshuaBPman, I've actually just installed it for the first time (ext4, btrfs wouldn't boot but I tested that)

<davexunit>joshuaBPman: if it's compiling everything then it's a good sign that you are out-of-date and should stop and figure out what's wrong.

<joshuaBPman>also for people who like free speech stuff: https://www.youtube.com/watch?v=trRdlNTbe0k

<ilit>davexunit: I'll try to figure out how to paste that

<mark_weaver>ilit: you might try installing the 'font-dejavu' package.

<ilit>mark_weaver: will do, thanks!

<joshuaBPman>davexunit: I'm following the directions here: https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation

<davexunit>joshuaBPman: I'd like for this discussion to stop and go back to talking about Guix.

<davexunit>the MOTD should mention that you should run 'guix pull'

<joshuaBPman>I used the herd to start "cow-start"

<davexunit>the manual should, too, so that's an omission.

<joshuaBPman>created config.scm

<davexunit>run 'guix pull' to get the latest version of guix.

<joshuaBPman>then ran guix system init /mnt/etc/config.scm /mnt

<joshuaBPman>it appears to still be installing.

<ilit>davexunit: when you said I should be more constructive, did you mean the comment in the image or my initial question? thx

<davexunit>ilit: both. it seemed very "fix this for me", which is not how we operate.

<joshuaBPman>so no I have not run guix pull, because it looks like guix is still setting up initials packages.

<ilit>davexunit: you're right, I was actually complaining/frustrated/annoyed. For what is worth, I apologize.

<davexunit>joshuaBPman: because you ran 'guix system init' to install the system.

<davexunit>what I'm saying is that you should stop that process

<davexunit>and run 'guix pull'

<davexunit>ilit: it's okay.

<davexunit>ilit: if you post your config file, someone here might be able to build it in a VM and see if they see the same font issue

<ilit>davexunit: I ran that too. Which MOTD is saying that about guix pull? (I did miss it if it's the one on the bootable USB image)

<ilit>davexunit: thanks, I'll post it, just a sec.

<davexunit>I thought such a message was added prior to the 0.10 release.

<davexunit>I remember reading a discussion about this because people come here all the time and complain that guix is compiling everything.

<davexunit>so I really thought we addressed this in the instructions somewhere.

<ilit>I'll recheck if MOTD says so

<ilit>(it might, but I just missed it)

<davexunit>I could be wrong. I haven't used the installer in quite some time.

<joshuaBPman>davexunit: will something bad happen if I stop the build process?

<joshuaBPman>I've already been waiting about 30 min-40 min. I'm afraid C-c C-C will break something and I'll have to install all over.

<davexunit>joshuaBPman: no, that's one of the features of guix.

<ilit>joshuaBPman: for me it took like 86min

<joshuaBPman>davexunit: I hope you don't care if I just let it compile everything like ilit just said. I'm already about half way through and I'm not doing anything important. Also I'll run guix pull after if you think I should.

<davexunit>there will be no point afterwards

<davexunit>but you should know that you are installing a system with known security vulnerabilities

<ilit>joshuaBPman: btw, I commented out the gnome part

<joshuaBPman>davexunit: what security vulnerabilities?

<joshuaBPman>ilit: too late. I'm building gnome too. haha.

<joshuaBPman>installation finished! no error reported.

<davexunit>joshuaBPman: you can 'guix pull' and update your system after you boot into the new system for the first time.

<mark_weaver>on the 'gnome-updates' branch, hydra has failed to build 'jemalloc' on i686 four times in a row. http://hydra.gnu.org/build/1188729

<joshuaBPman>davexunit: ok I'll do that. I'll re-read the install instructions in a bit. I'm assuming now I just umount everything and reboot.

<joshuaBPman>but thanks for the help.

<davexunit>yeah you can reboot now

<ilit>davexunit: running reconfigure for the first time I am reminded to run guix pull

<davexunit>ilit: oh it does that? cool

<ilit>yeah, it's great!

<ilit>(it's a "warning:")

<ilit>My /etc/config.scm http://dpaste.com/3EYPY1D.txt (I had added wget and curl to it) for the current state of fonts (I'll try adding package 'font-dejavu' next)

<ilit>davexunit: this is how the 'guix pull' warning looks like during 'reconfigure' (I wanted to show you earlier but wasn't easy to copy/paste then.): http://dpaste.com/20SXWT9.txt But worth noting that those substitute lines quickly scrolled it up and I would've missed it if I didn't manually scroll back :D

<davexunit>ilit: ah, cool. thanks!

<mark_weaver>ilit: you need to run "guix pull" as root as well. "guix pull" only updates guix for the user that runs it.

<mark_weaver>since "guix system reconfigure" is run as root, it uses root's copy of guix.

<mark_weaver>this is a very common confusion

<ilit>mark_weaver: that's great to know Mark! I appreciate it.

<mark_weaver>if you would prefer to have 'root' use the same version of guix as your normal user, then you could make /root/.config/guix/latest be a symlink pointing to ~user/.config/guix/latest

<mark_weaver>basically, "guix pull" builds a copy of guix from the latest git sources and makes ~/.config/guix/latest be a symlink pointing to it.

<mark_weaver>and "guix" uses the copy of guix in ~/.config/guix/latest, if that symlink exists.

<joshuaBPman>that's pretty cool!

<mark_weaver>so you can make those symlinks point to other user's symlinks (or to a built git checkout, as we developers often do)

<ilit>Nice1!

<mark_weaver>(in my case, I have both /root/.config/guix/latest and ~mhw/.config/guix/latest pointing to my built git checkout)

<mark_weaver>(and I never run "guix pull", instead I "git pull" and then make)

<ilit>That is something I would prefer to have too...

<z0d>re

<ilit>re

<davexunit>I do the same, because I hack on things so often.

<davexunit>I wonder if a 'guix clone' tool would be helpful for making it real simple for new users to clone the upstream git repo

<joshuaBPman>+1

<mark_weaver>davexunit: what would it do?

<davexunit>mark_weaver: this is not even half baked, but it could at the very least clone the git repo and maybe use 'guix environment' to setup the build environment.

<davexunit>maybe 'guix clone' wouldn't be the right name

<mark_weaver>the thing is, they'd still need to set up the environment, without the clone, the next time they want to update

<davexunit>but something like that might help lower the barrier to entry.

<mark_weaver>I'm not sure we can avoid having the user/developer do some steps. not sure if we should try to make this easier.

<davexunit>mark_weaver: this would literally clone the repo for them to hack on in the current working directory

<mark_weaver>ACTION goes afk

<davexunit>mark_weaver: right, that's valid.

<davexunit>I'm not sure either. :)

<joshuaBPman>hello, So I've just installed gnu guix! at the moment I can only log in as root. using qwerty, but my layout is dvorak. haha lots to learn.

<civodul>davexunit: yeah, some way to make it easier to get started would be nice

<civodul>joshuaBPman: cool :-)

<civodul>joshuaBPman: the first time you log in in GuixSD, only root can log in, with an empty password

<civodul>the other passwords need to be initialized with the 'passwd' command

<joshuaBPman>so `passwd USERNAME PASSWORD`

<joshuaBPman>?

<ilit>just: passwd USERNAME

<ilit>then enter it :D

<joshuaBPman>ilit: ok. I did that. My only problem is that when I log in the layout is qwerty. I'd prefer it to be dvorak. Do i just change my configure.scm from (locale "en_US.UTF-8") to (locale "dvorak_US.UTF-8") ?

<ilit>joshuaBPman: I don't think that's the way, I don't currently know to change that (loadkeys?)

<joshuaBPman>that'll work, but only after I log in.

<ilit>see here: https://www.gnu.org/software/guix/manual/guix.html and search for loadkeys, apparently you need to invoke console-keymap-service function on the dvorak file?

<ilit>procedure*

<joshuaBPman>I did just find this: https://www.gnu.org/software/guix/manual/html_node/Locales.html#Locales

<ilit>file should be here /run/current-system/profile/share/keymaps

<joshuaBPman>but I'm not sure where in the configure.scm that thing should go. And i'm afraid of messing with that file I'll crash something really easily

<ilit>joshuaBPman: I'll try a test on my config, brb

<joshuaBPman>ok. don't break anything haha.

<ilit>joshuaBPman: this seems to work(although it's currently in progress: within 'guix system reconfigure') http://dpaste.com/0MY45HR.txt see where I put the 'console-keymap-service' line

<ilit>(fails with bash-static 504 gateway timeout)

<civodul>console-keymap-service doesn't take an absolute file name

<ilit>oops

<joshuaBPman>ok. So that doesn't work??

<joshuaBPman>ok.

<civodul>see the example in the current manual (not on line)

<civodul>(console-keymap-service "dvorak")

<ilit>thanks!

<civodul>yw :-)

<joshuaBPman>ok, I'll have to try that then.

<ilit>davexunit: I finally got around to looking at the MOTD of the install USB image (no 'guix pull' mention): https://imgur.com/Ak8LHVh

<ilit>mark_weaver: that fixed the fonts Mark! Thanks a lot! (that is, installing 'font_dejavu' package - note: without 'guix pull', I've yet to run this)

<lfam>I just joined the channel. If you've never run `guix pull` since installing GuixSD 0.10.0, then you are vulnerable to a lot of publicly disclosed security vulnerabilities.

<lfam>For example, vulnerabilities were recently disclosed in openssl, imagemagick, and wpa_supplicant, libtasn1, icecat, mysql, icedtea (java), and several more

<lfam>So, I recommend you upgrade :)

<joshuaBPman>thanks for the tip lfam!

<lfam>Also, git

<ilit>thanks lfam!

<ilit>This is how it looks now with font_dejavu https://imgur.com/LaEA0Qd (I've also updated the original images link with the fix in the image description)

<ilit>(in case anyone stumbles upon that - for google/history reasons, who knows)

<lfam>If you want to know which vulnerabilities, you can get a rough idea by searching our git log for 'CVE'. Sometimes we patch things before a CVE is issued, or we upgrade packages without knowing about the CVE, but that search will at least give you a sense of what bugs were fixed. And there are a lot.

<ilit>nice

<ilit>man I really love guix pull https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-pull (reading that is so satisfying for some reason)

<lfam>Is it clear that if you want to upgrade your installed packages (that is, the packages in your profile), that you must run `guix package --upgrade .` afterwards? `guix pull` updates your copy of Guix, including package definitions, but it doesn't upgrade your packages themselves.

<lfam>Btw, the '.' is intentional. It's a regex.

<ilit>lfam: it isn't clear for me: "On completion, guix package will use packages and package versions from this just-retrieved copy of Guix." - I read that to mean the packages are upgraded too (it seems to be doing that right now too, eg. downloading bash etc.). It's unclear that it doesn't update the packages themselves hmm...

<lfam>ilit: That text refers to `guix package`, which is a command. It means that `guix package` will use 'package versions from this just-retrieved copy of Guix.'

<ilit>so, the package definitions

<lfam>The bash you are downloading is likely required to download and deploy the new version of Guix.

<lfam>Exactly. Are you familiar with Debian? If so, `guix pull` is very roughly analogous to `apt-get update`

<ilit>oh...

<ilit>right, got it!

<lfam>Sometimes, `guix pull` will need a new version of tar, to unpack the tarball, etc

<ilit>and of file, gawk, bison :D

<ilit>glibc-bootstrap /:)

<lfam>Heh, I guess the first time is rather "heavy"

<lfam>I found it shocking to learn how big dependency graphs really are

<ilit>I believe you

<lfam>Although bison is surprising to me... Are you getting substitutes from hydra? Or is it trying to build everything from source?

<ilit>Someone(probably me?) needs to fix this spam: https://imgur.com/T1vJHa0 I suggest showing the first line before download starts and then only refresh the starts on a the second line (instead of reprinting the whole line which gets split on two lines and thus spam happens)

<ilit>lfam: hydra yes, gcc-bootstrap is downloading now lol

<ilit>starts=stats*

<lfam>ilit: I think we fixed that spam recently

<lfam>I *think*

<lfam>It manifests when the terminal is too narrow

<ilit>sweet then, I'll see after guix pull :D erm, actually, after the --upgrade *oops

<ilit>yeah

<ilit>(like the text mode terminal during install)

<lfam>Relevant bug report: http://bugs.gnu.org/22536

<lfam>Nope, not fixed yet :(

<ilit>rofl "and I... object to it in priciple. "

<lfam>I also found that funny

<lfam>This bug is in the "help wanted" column

<wingo>:)

<ilit>I'm going to have to take some time reading the manual(and what else) before delving in - else I would be doing everyone a disservice :D

<civodul>lfam: is it really not fixed?

<civodul>i thought it was

<civodul>it's just that dannym made additional requests, no? :-)

<lfam>When I do `guix build -S libreoffice` in a very narrow terminal, a new line is created serveral times per second

<lfam>Let me make sure I am up to date :)

<civodul>daemon side in particular

<civodul>and whether you use substitutes or not makes a difference

<lfam>So, do `guix pull` as root and restart the daemon? Anything else I should do?

<lfam>I do use substitutes

<civodul>'guix pull' does not update the daemon, so you need to update it in some other way

<lfam>`guix package -u guix` as root?

<civodul>yes, for example

<civodul>or 'guix system reconfigure'

<civodul>so, just tried, and indeed, there's a problem if the terminal is super narrow

<ilit>80cols narrow?

<lfam>Okay, I was about to report the same thing

<civodul>~50 columns or less for "guix build -S vim"

<lfam>After quadruple-checking my setup :)

<civodul>:-)

<lfam>I thought Danny submitted a patch for this, but I didn't follow it too closely

<ilit><=50 isn't bad

<civodul>still, not great

<civodul>ACTION -> zZz

<civodul>good night/day!

<lfam>Good night!

<ilit>about ~35 chars it seems it would need to always update

IRC channel logs

2016-05-09.log