IRC channel logs

2016-01-31.log

back to list of logs

<lfam>You never did `guix pull`? That would update the package definitions and cause you to rebuild everything if you were not using substitutes.
<Jookia>I didn't, I'm using a pinned Git version of Guix
<lfam>Then you'd better wait for someone smarter and more experienced than me to respond ;)
<Jookia>That's fine
<Jookia>I'll just read the slides and geek out about FOSDEM
<davexunit>it *must* be different.
<davexunit>if the derivation hashes are different, then something is different.
<lfam>Speak of the devil ;)
<davexunit>we merged our core-updates branch recently.
<davexunit>which is a "rebuild the world" change
<Jookia>davexunit: My pre-inst is based on a Git revision with one change- to have the Guix package use the same Git revision. Installing Guix should give it the same Git revision installed, minus the change
<Jookia>davexunit: What I'd expect to see when installing Guix using an installed Guix is a version downgrade, not a world rebuild
<davexunit>there has to be more to the story.
<davexunit>this simply cannot happen unless there's more going on.
<Jookia>davexunit: I'm willing to try to recreate it in a container and provide the steps I'm using to bootstrap the system manually on aptosid
<Jookia>siduction*
<davexunit>Jookia: are you using master?
<davexunit>or is there a specific commit?
<Jookia>davexunit: There is a specific commit I have pinned, let me dig it up
<davexunit>how did you verify that what you were running is exactly the same as before?
<davexunit>Jookia: did you configure with the correct localstatedir?
<Jookia>localstatedir is /gnu, yes?
<davexunit>no
<davexunit>it's /var
<Jookia>I haven't changed it
<davexunit>ACTION just did something that made a whole ton of text print out on his ERC buffer and is hoping he didn't spam the channel with it.
<davexunit>Jookia: does /var/guix exist? where has your localstatedir been?
<davexunit>how have you been using guix before building it from git?
<Jookia>Oh!
<Jookia>/var/guix doesn't exist, it's /usr/local/var/guix
<Jookia>Would symlinking it out of /usr/local fix this?
<Jookia>And I've only used Guix through building it from Git
<Jookia>Or perhaps I need to rebuild with a better localstatedir
<davexunit>Jookia: well, if you've been using /usr/local/var/guix this whole time then its fine
<Jookia>Could it be that the installed Guix is looking for /var/guix rather than /usr/local/var/guix?
<davexunit>no, because it should throw an error
<davexunit>I don't know what you mean by "installed guix", though
<davexunit>you said you've only used guix from a git checkout
<Jookia>I've built Guix from a git checkout, then with the pre-inst-env, used that Guix to install Guix
<davexunit>that guix package is definitely built with localstatedir=/var/guix
<davexunit>so 'guix package -i guix' doesn't trigger a rebuild?
<davexunit>that version of guix should yell that it cannot connect to the build daemon
<Jookia>"./pre-inst-env guix package -i guix" doesn't trigger a rebuild, "guix package -i guix" with PATH set to the root profile does trigger a rebuild, both with their respective daemons running when run (not at the same time)
<Jookia>It does yell 'error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory' if I try to run the installed Guix with the pre-inst-env daemon
<davexunit>Jookia: respective daemons? only one daemon can be running!
<davexunit>otherwise you will corrupt your store.
<davexunit>because they will both be writing to /gnu/store, but each daemon that's using a different localstatedir will not know what stuff the other has built.
<Jookia>When I run the first command ("./pre-inst-env guix package -i guix") I run "./pre-inst-env guix-daemon ...", when I run "guix package -i guix" with the root profile in my PATH, I close the first daemon and run the second daemon using "guix-daemon ..."
<davexunit>Jookia: this explains exactly why you are rebuilding anything.
<davexunit>that second daemon has a completely different state directory
<davexunit>I bet you have a /var/guix directory now
<Jookia>Yes I do
<davexunit>there you have it.
<davexunit>mystery solved.
<Jookia>How would I move the state to /var/guix ?
<davexunit>you have move the old directory there.
<davexunit>you can*
<davexunit>and then reconfigure your git checkout to use it
<Jookia>Ah, good. I was hoping there wasn't some hardcoded state.
<davexunit>./configure --localstatedir=/var
<davexunit>and just run a single daemon. there's no reason to switch between daemons.
<davexunit>the RPC API is very stable.
<Jookia>I see, I was switching daemons because it wasn't working and I didn't read the message (derp)
<Jookia>I'm glad to hear it's stable
<davexunit>you can use a single daemon with many different versions of the guix client
<davexunit>my daemon is always quite a bit older than my client.
<davexunit>and that's OK
<Jookia>Thanks so much for your help :)
<davexunit>you're welcome.
<davexunit>glad we've solved that.
<Jookia>I'll make sure to follow-up in the thread
<davexunit>great!
<davexunit>I've gotta go afk now
<Jookia>Have fun
<myglc2>I'm getting 'X11 forwarding request failed on channel 0' but '7.2.7.2 Networking Services' says ... '[#:x11-forwarding? #t]'. Is there something else I need to do?
<eiro>hello
<Jookia>hello!
<jin_>hi, i have this message when try to compile a package: No package 'gnome-desktop-2.0' found
<davexunit>jin_: need more details. what exactly did you do?
<jin_>i trying to compile eel package,
<jin_>i add gnome-desktop in input field of my package definition
<jin_>and when i built ' ./pre-inst-env guix build eel' send message: No package 'gnome-desktop-2.0' found
<davexunit>jin_: okay, so this is a new package. can you send the expression?
<davexunit>I'm sure it's a simple mistake, but without all of the relevant details I can't help you.
<jin_>this is http://paste.debian.net/377719
<jin_>and it's the last part of error message: http://paste.debian.net/377720
<davexunit>jin_: oh okay. this isn't a guix problem.
<davexunit>this is the eel build system not being able to find gnome-desktop
<OrangeShark>jin_: looks like EEL requires specifically gnome-desktop-2.0 while guix has gnome-desktop 3.18.1
<davexunit>yeah
<davexunit>that's it
<myglc2> any idea why all my guixSD emacs INFO pages have a "?" everywhere they should have a "'"?
<jin_>i read that nautilus require eel library to compile
<jin_>thanks davexunit, OrangeShark, i will keep looking for
<OrangeShark>jin_ ya, it does say nautilus require latest release of eel
<jin_>then i need the last version of eel
<OrangeShark>jin_ I am looking at nautilus 3.19.2 and it seems to include eel in the source code
<OrangeShark>there is a subdirectory called eel, looks like they are now together?
<jin_>yes i see the directory
<OrangeShark>hmm, looks like in nautilus 2.25.2 they merged eel
<Jookia>myglc2: Perhaps it's a Unicode character?
<jin_>OrangeShark, i will check again the nautilus dependences
<myglc2>I don't know. I have two identical physical servers. One has Debian 8 installed, the other guixSD. I ssh into both the same way, but the guixSD box has all these "?". Would guixSD be using a different default encoding than debian?
<lfam>myglc2: Do you have a unicode font in your guix profile?
<OrangeShark>jin_: good luck, I tried looking for any text files that has any instructions for dependencies and I can't seem to find any
<lfam>For example, font-gnu-unifont (make sure to select the right output, since the different font formats are split into different outputs)
<OrangeShark>jin_: this might help, they have a build tool called jhbuild which list the dependencies. https://github.com/GNOME/jhbuild/blob/e7f9cb5988df62ebd55b89abbf39b91efba433d8/modulesets/gnome-suites-core-3.18.modules#L788
<OrangeShark>hope this helps
<myglc2>lfam: I don't see any fonts in '/run/current-system/profile/share/info'. But would matter if I'm using tty (iTerm2 on a mac). I guess I could go over to the console in the other room and see if the '?' are there too?
<jin_>good, thanks again OrangeShark
<lfam>myglc2: Yeah, I'm not sure if it should make a difference or not. It's just an idea.
<lfam>I need the console fonts from font-gnu-unifont to view unicode characters in my unicode aware terminal emulator.
<myglc2>lfam: I checked the console, which is an actual vga display plugged into the server. No annoying extra "?"'s there.
<myglc2>lfam: I have (operating-system ... ((locale "en_US.UTF-8"))) in my config.scm, but the "locale" program is not installed, maybe that needs to be done?
<lfam>mygcl2: Instead of "locale" I think it would be "glibc-utf8-locales".
<myglc2>lfam: I'm not seeing "glibc-utf8-locales" in '/run/current-system/profile/share/info'
<lfam>Then try installing it or adding it to the global packages.
<lfam>myglc2: It would be under "lib/locale", not "share/info"
<myglc2>lfam: Thanks, I'll do that.
<myglc2>Yeah, thanks, that was dumb, eh. Anyway, I looked at everything under /run/current-system/profile/ and the only thing I see are some utf8 man pages.
<lfam>Did it work?
<myglc2>lfam: I got distracted trying to understand all the utf8 stuff. I guess in guix one should just try something instead of studying so hard, eh?
<lfam>I say do both :)
<myglc2>lfam: Ok, now I have 'locale -> /gnu/store/7zzd7a15nhgpfy5wh7vk441ga40azgf5-glibc-utf8-locales-2.22/lib/locale' in '/run/current-system/profile/lib/', and ... I still have all the "?";s
<lfam>myglc2: Then I'm stumped :)
<myglc2>lfam: Thanks for giving it a shot. I'll just ignore the"?" for a while. Heck, I might even come to like them :)
<lfam>What?s the big deal anyways'
<myglc2>Exactly...
<mark_weaver>myglc2: the font is the problem, not the locales
<mark_weaver>install 'font-dejavu' and use it
<mark_weaver>well, at least that's my guess
<mark_weaver>what is the output of "echo $LANG" ?
<myglc2>en_US.UTF-8
<mark_weaver>and the question marks are showing up where?
<myglc2>You are talking about an X11 font right?
<mark_weaver>well, a truetype font
<mark_weaver>is this within X or within a text console? what program?
<myglc2>So you think the problem is the font I am using in my terminal emulator (iTerm2)?
<lfam><myglc2> I don't know. I have two identical physical servers. One has Debian 8 installed, the other guixSD. I ssh into both the same way, but the guixSD box has all these "?". Would guixSD be using a different default encoding than debian?
<mark_weaver>yes, or maybe it's a problem with the terminal emulator itself.
<mark_weaver>I use gnome terminal, and that renders UTF-8 correctly.
<myglc2>Sorry, yeah a tty session running from my Mac desktop to the headless server.
<lfam><myglc2> any idea why all my guixSD emacs INFO pages have a "?" everywhere they should have a "'"?
<mark_weaver>myglc2: ah... so, within the iTerm2, while logged into the Guix server, "echo $LANG" from that shell on Guix says "en_US.UTF-8" ?
<mark_weaver>I'd also like to know what the output of "echo $LANG" is while logged into the Debian 8 server via iTerm2
<myglc2>en_US.UTF-8
<mark_weaver>from both?
<myglc2>Yup
<mark_weaver>well, I'm stumped. can you email bug-guix@gnu.org about it?
<myglc2>Sure, thanks. I just noticed that when I ssh to guixSD from the Debian box echo $LANG gives a blank line.
<mark_weaver>myglc2: one more question: in the emacs running on GuixSD, do you see "-UUU" on the left side of the modeline?
<mark_weaver>myglc2: wait, when you ssh from debian, LANG is unset/blank, but when you ssh from your Mac, LANG is "en_US.UTF-8" ?
<myglc2>Hmmm. On guixSD I see '-UUU:**-...', on Debian I see 'U:**-...'
<myglc2>Yeah. When I ssh from Mac to debian to guixSD, LANG is unset/blank. When I ssh from Mac directly to quixSD LANG is "en_US.UTF-8"
<mark_weaver>myglc2: when Emacs is run from a text terminal, it should show more characters than that before the ':'. when running it from Debian, is emacs actually running in text mode within the iTerm2, or is it opening a new window via X11 forwarding?
<mark_weaver>section 1.3 (The Mode Line) of the Emacs manual talks about what's in the mode line.
<myglc2>OOPS, I lied. I am sorry. I'm actuall in X11 on debian. Let me switch to tty.
<mark_weaver>run "emacs -nw" to force it to run in text mode. I'd be curious what happens if you run that on Debian from your iTerm2
<myglc2>OK now I have '-UUU:%%-...' on the mode line in Debian
<mark_weaver>and do you see the same problem with '?' ?
<mark_weaver>with the question marks in place of the apostrophes?
<mark_weaver>my suspicion is that your iTerm2 is not actually configured to expect UTF-8
<myglc2>No, on debian in a tty the is no problem with '?'
<mark_weaver>okay, I give up. email bug-guix@gnu.org about it please
<myglc2>e.g. the "'" are "'", not "?"s
<myglc2>OK thank you. Will do, tomorrow AM.
<mark_weaver>thanks!
<Jookia>Is there a reason why Guix doesn't build two derivations at once?
<efraim_>on guixsd or on a foreign distro?
<Jookia>foreign distro
<efraim_>I think it has something to do with the kernel config, but I haven't looked into it
***efraim_ is now known as efraim
<Jookia>Oh dear
<Jookia>It also seems one of the tests I'm running eats all of my 2G of RAM
<efraim>that sounds like fun
<Jookia>It's certainly 'fun' in the sense of 'I need to find RAM that works with both Libreboot and my T400'
<efraim>or a large swap
<Jookia>I have a large swap all ready for it (8G) and it's chewing through it happily, unfortunately earlier for whatever reason the machine died during these tests
<efraim>I have a VM with 512 MiB of ram and I think it tried to swap out the kernel last month
<Jookia>Haha wow
<Jookia>I certainly hope I can figure out parallel builds by the time I try Guix on my Novena
<alezost>cajg: your locale should be "en_GB.utf8", not "en_GB.UTF-8". See (info "(guix) Locales")
<Phlogistique>hello there
<Phlogistique> http://sprunge.us/fidH I get a lot of warnings when installing guix from guix
<Phlogistique>is this expected?
<Phlogistique>(also, it downloaded some substitutes, but still builds Guix and Guile)
<alezost>Phlogistique: I think this warnings are harmless. Guix and Guile are probably compiled because you didn't do "guix pull"
<alezost>ACTION goes away
<Phlogistique>OK!
<Jookia>When will Guix implement EFI bricking through the rm command? https://github.com/systemd/systemd/issues/2402
<Phlogistique>so it looks like I have the libc locales problem
<Phlogistique>so every guix-installed program prints
<Phlogistique>warning: failed to install locale: Invalid argument
<Phlogistique>which is annoying but not a big problem
<Phlogistique>however "guile --language=wisp" crashes
<Jookia>phogg: Is this in Guix or GuixSD?
<Phlogistique> http://sprunge.us/fQBT
<Phlogistique>Jookia: Guix
<Jookia>Phlogistique: What locale are you on?
<Phlogistique>fr_FR.UTF-8
<Jookia>Do you have glibc-locales installed
<Phlogistique>guix's glibc-locales?
<Jookia>Yes
<Jookia>guix package -i glibc-locales
<Phlogistique>I'm installing it
<Jookia>Then run 'export GUIX_LOCPATH="/root/.guix-profile/lib/locale"' or replace /root/ with whatever user you're installing the locales in
<Phlogistique>oh, cool!
<Phlogistique>thanks
***the_ktosiek is now known as ktosiek
<cajg>thanks to alezost I have now made four corrections, and am now getting a less informative error on calling guix init:
<cajg><unknown location>: error: source expression failed to match any pattern
<cajg>I may give up and start again in case I have lost track somewhere
***joehillen_ is now known as joehillen
***quigonjinn` is now known as quigonjinn
<janneke>yay, i have guixsd running
<efraim>yay!
<NiAsterisk>first time fosdem was interesting. brussels too, because I forgot for a moment it's dual language with french, good thing I refreshed french just enough to understand and have dialogues in french where I replied in english because after all these years forming sentences in french felt weird to me.
<efraim>anyone who reads this between now and when I update/fix wayland:
<efraim>dealers choice: add graphiz as a dependancy, or disable documentation?
<efraim>I'm leaning to disable documentation
<NiAsterisk>there's only one or the other, efraim?
<efraim>I don't think it needs graphiz for running, but I could be wrong
<NiAsterisk>checked gentoo source definitions for it, https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/wayland/wayland-1.9.0.ebuild and graphiz is inside the dependency definition for the optional flag setting "doc", I would read it as: documentation requires graphiz
<NiAsterisk>if you add documentation, you might as well try a build with graphiz and one without and see what happens?
<janneke>how do you chroot into a partition that hold guix? (there is no /bin/bash)
<NiAsterisk>have you tried /bin/sh ?
<janneke>NiAsterisk: that helps...now to find how to set a sane PATH
<NiAsterisk>if it helps, my $PATH is: ~/.guix-profile/bin:~/.guix-profile/sbin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin where you should replace ~ with /home/your-username no idea what you are trying to do though.
<janneke>ah, this helps: . /etc/profile
<janneke>NiAsterisk: i have installed guix on a partition, then switched back to ubuntu
<NiAsterisk>ah
<janneke>now i am running guix in kvm and am installing emacs via ssh
<NiAsterisk>oh. for a moment I thought you tried working on dualbooting with guixsd :)
<janneke>i want to dabble in the ro-mounted /guix partition
<janneke>NiAsterisk: yes, I am dualbooting
<NiAsterisk>installing software with npm is such a pain :/ why does this even reset my network connection. urgh. upgrade, yay let's pull it all again.
<davexunit>this FOSDEM talk seems interesting: https://fosdem.org/2016/schedule/event/distros_rethinking/
<NiAsterisk>slides look nteresting
<NiAsterisk>'npm install' with brave browser pulls in 928 dependencies.. even if it won't be fully free (backend), I'd like to get some people get rid of this pain.
<davexunit>NiAsterisk: 928, wow! You'll have to see how many of those are duplicates
<NiAsterisk>many babelfishes
<davexunit>npm prior to version 3 did massive duplication
<NiAsterisk>it's npm 5.5 iirc
<NiAsterisk>woops. still running 3.3.12
<NiAsterisk>i wanted to upgrade to 5.5
<davexunit>I thought the latest npm was in the 3.x series
<davexunit>you may be confusing node and npm
<NiAsterisk>actually, yes
<NiAsterisk>node
<NiAsterisk>not npm
<xd1le>good to see guix getting some love big and centre here (at fosdem): https://twitter.com/bsdlme/status/693807456330326016
<xd1le>:)
<davexunit>woo!
<NiAsterisk>nodejs 5.5: 951 dependecies with latest brave browser checkout :D challenge accepted to trim this down if possible.
<kqb>what parts of nix did guix change?
<kqb>does guix JUST add a guile EDSL and different default system packages when used as an OS? Or is there more?
<NiAsterisk>most of it should be obvious through the website and documentation. for example nix has a more "relaxed" view on software whereas guixsd is a GNU faif distribution.
<kqb>I read the motivation/general-design part of the documentation, I am interested in an overview of the technical details underneath. There is an option - I believe it is "import" - that allows guix to use nix packages. Where can I find documentation on that?
<NiAsterisk>ACTION wonders why orangewebsite adds more than 100% to the price of .is domains. this seems so surreal, I have to get an reply from them
<NiAsterisk>hm.. i don't know, others might
<NiAsterisk>`info guix import`
<NiAsterisk>if you happen to run guix already. the technical details are not where I could share further insight (yet)
<kqb>Is anyone already working on a common-lisp interface to guix?
<mark_weaver>kqb: guix is mostly original work. it is not merely a scheme interface on top of nix.
<NiAsterisk>there's an emacs interface, kqb
<kqb>(not (= 'elisp 'common-lisp))
<mark_weaver>on the daemon side, it is a slightly modified nix-daemon, that's true.
<mark_weaver>on the client side, which includes all of the code that builds packages, it's completely original.
<mark_weaver>see the "Additional Documentation" section of https://gnu.org/software/guix/help/
<NiAsterisk>oh, i just found a very demotivating post by cwebber about npm based software in guix :/
<mark_weaver>the first paper is a bit out of date, but a good overview of the rationale, design, and implementation of Guix
<mark_weaver>kqb: the entire client side of guix is written in pure guile scheme. I guess it would be difficult to write a common-lisp interface for it, because I'm not aware of any existing interfaces to allow calling guile procedures from common lisp.
<mark_weaver>also, unless the common lisp implementation in question used the BDW-GC garbage collector, they would be two separate garbage collectors in the same process, and that's likely to be a huge pain, to say the least.
<kqb>from what I gather guile has a c-interface; alternative: crank guix/guile out of common-lisp
<mark_weaver>the most likely approach would be to run guix in a separate process and talk over sockets.
<mark_weaver>kqb: what does "crank" mean in this context?
<kqb>print
<mark_weaver>I don't understand what you're suggesting.
<mark_weaver>it's true that guile has a nice C interface, though, so C could in theory be a bridge between the two worlds, if the garbage collection issues could be dealt with.
<mark_weaver>what is it that you wish to be able to do from common lisp?
<kqb>from what I read (I spent a year just reading) scheme traded macro-simplicity for namespace-simplicity (lisp-1 and lisp-2 being the two different approaches). Sadly Let over Lambda costs money. It gave me some insight into macro-programming
<mark_weaver>if the number of operations you need to expose to common lisp is limited, then it would be feasible to do it over a socket.
<kqb>maybe it is possible to just compile the guile-source with sbcl
<kqb>In the short term I just want to be able to use syntax-quote and macros to produce guix-packages
<mark_weaver>kqb: I don't understand. What do you think that Scheme traded away in the area of macros? Scheme has hygienic macros, and Guile has procedural hygienic macros with the ability to bypass hygiene where explicitly desired. I see them as strictly superior to CL macros.
<mark_weaver>kqb: running Guix, or any other non-trivial Guile code within a common lisp implementation is going to be a *major* project.
<kqb>I understand that point of view, but I consider that to be to much overhead for my *personal* code
<mark_weaver>kqb: Guile even has a 'defmacro' macro for those who don't want to deal with hygiene.
<mark_weaver>(although we strongly discourage its use, because of problems with unintended variable capture)
<mark_weaver>I also don't know what you mean by "Let over Lambda costs money". Can you explain?
<mark_weaver>kqb: can you tell me what you wish to do, and how your existing "personal code" fits into it? if I understood your goals, I might be able to suggest the easiest way forward.
<mark_weaver>"In the short term I just want to be able to use syntax-quote and macros to produce guix-packages" is too terse. Can you elaborate?
<kqb>I was unable to find a free copy of Doug Hoyte: Let over Lambda. I ended up going to a library.
<mark_weaver>oh, I see
<mark_weaver>in Guix, packages are first-class objects. they can be created programmatically using procedures or macros.
<mark_weaver>there are several examples of this already. we have several procedures that accept packages as arguments and use them to create new packages as return values.
<kqb>I am relatively new to lisp and some macros like Graham: On LISP "aif" sound interesting. They use intended variable capture. The way I learned to write code unintended variable capture was never a problem (I managed to write CLEAN "GOTO" code in a BASIC dialect). Most "features" to clean up code, just waste my time, because I do not need the constructs. When I give my code to others I put them in, because not everybody wants
<kqb>that much work into code.
<mark_weaver>guile uses the 'syntax-case' macro system, which allows variable capture where intended, while doing things hygienically by default.
<mark_weaver>if you want to write macros like that create guix packages, by *far* the easiest course of action is to learn the syntax-case system. all of the other solutions you're thinking of would be major projects.
<kqb>ok. I don't have a problem switching between LISPs, but if I have the option I prefer CL.
<mark_weaver>understood, but obviously the Guix project has chosen Scheme and written about 200 thousand lines of it.
<mark_weaver>I can explain how to write macros like 'aif' in syntax-case, but #guile would probably be a better place to discuss that.
<myglc2>mark_weaver: You remember the UTF-8 "?" for "'" problem I was having last night? Looking at this again this AM I noticed that '/run/current-system/locale/2.22' has en_US.utf8 and en_US.UTF-8. So I changed the line in my config.scm that reads '(locale "en_US.UTF-8")' (inherited from in bare-bones.scm) to read ... (locale "en_US.utf8") and the "?" in emacs info are fixed. So now I am a happy camper. However, ssh from debian box to guixSD
<myglc2>box and 'echo $LANG' returns blank line, which does not bother me but seems odd. Do you want me to email bug-guix@gnu.org re this discovery?
<mark_weaver>kqb: here's a chapter of a textbook that describes the syntax-case system: http://www.scheme.com/tspl4/syntax.html
<mark_weaver>'datum->syntax' is used for intended variable capture. on that page, search for 'datum->syntax' and it will show a 'loop' macro that introduces a 'break' binding unhygienically.
<mark_weaver>myglc2: ah, that's interesting! thanks for the report.
<mark_weaver>I guess we should change our example configs. *.utf8 does seem to be the preferred form nowadays, but my system has (locale "en_US.UTF-8" and somehow I've not run into problems, so this is interesting.
<mark_weaver>myglc2: regarding ssh from debian to guixSD losing the LANG variable, that's interesting. probably worth an email to bug-guix@gnu.org, yes.
<myglc2>OK I will do that. Got to run out now, will be back later if there is anything else you need on this.
<mark_weaver>myglc2: okay, thanks!
<kqb>mark_weaver: sounds good, thanks!
<mark_weaver>kqb: you're welcome. feel free to ask questions as they arise. #guile is probably the best place to ask about questions regarding Guile scheme that aren't specific to #guix.
<mark_weaver>(e.g. regarding how to write Scheme macros)
<kqb>question relating to guix: I did a binary install on an arch system today. I followed http://www.gnu.org/software/guix/manual/guix.html and https://github.com/pjotrp/guix-notes/blob/master/INSTALL.org#install-in-conjunction-with-another-package-manager. I installed guix to the entire system and then set it up for my unpriviledged user as well. I had the impression that it did not use the derivations already in the store. How d
<kqb>that?
<mark_weaver>kqb: that binary install image is old, from the 0.9.0 release. since then, we've updated some core packages that forced the rest of the system to be rebuilt. assuming you ran 'guix pull' (which is a good idea, to get the latest updates, some of them security updates) then you're now downloading the new "versions" of those packages, even if the version number didn't change.
<kqb>I executed "guix pull" for root and for the unpriviledged user.
<mark_weaver>in cases where the version number of a given package didn't change and you need to download a new one, it's because some library that it uses (or some package that was needed to build it) was updated.
<kqb>I seems very unlikely - although not impossible - that such an update would occur while I was switching between users.
<mark_weaver>ah, you ran these commands close together in time?
<mark_weaver>*these "guix pull" commands
<mark_weaver>if you want root to always use the same version of guix as your normal user, you can make ~root/.config/guix/latest a symlink pointing to ~YOU/.config/guix/latest
<mark_weaver>"guix pull" compiles a fresh copy of guix from our git repo (master branch) and makes ~/.config/guix/latest a symlink pointing to it.
<kqb>what breaks if I link the local user to the root build?
<mark_weaver>and all "guix" commands use the copy of guix referenced by that symlink, if it exists.
<mark_weaver>kqb: these symlinks won't break anything. just beware that running "guix pull" will update the $HOM/.config/guix/latest symlink
<mark_weaver>$HOME
<mark_weaver>so, if you make ~root/.config/guix/latest a symlink to ~foo/.config/guix/latest, then running "guix pull" as user "foo" will effectively update guix for both root and foo. running "guix pull" as "root" would overwrite that symlink you made and now they'll be independent of each other again.
<mark_weaver>and if the symlink is pointing the other way, then you should "guix pull" as root to effectively update the guix packages for both foo and root.
<mark_weaver>does that make sense?
<kqb>yes. Just wanted to make sure. If I link root to something in foo's control, that might compromise root...
<mark_weaver>*nod* that's a good point
<mark_weaver>in my case, I develop guix itself as my normal user, and I want root to use my development copy, so I can't easily avoid this issue. but your situation is likely to be different.
<mark_weaver>In my case, I actually make ~/.config/guix/latest a symlink to my built git checkout of guix
<mark_weaver>and I never run "guix pull"
<mark_weaver>(a good setup for guix developers)
<kqb>*nod*
<davexunit>NiAsterisk: we need to ford the npm river at some point. ;)
<davexunit>ain't gonna be easy, as cwebber's blog post has shown.
<NiAsterisk>I'm curious in all the wrong things to get an easy start :D maybe eventually I can contribute more when I figured out all the high level issues I experience and have to learn about.
<efraim>NiAsterisk: I started contributing by looking at the programs I used and updating them and their dependancies
<efraim>then from there I started attacking the packages that failed to build and somehow ended up trying to keep more of our python packages up to date
<NiAsterisk>I have a list of software I use and want to get into guix. but some of it is a bit complex for the beginning. lispf4 seems to work out, but that's the easiest package. everything was easy though when it was just ebuilds. I also want to see if I can bring up enough pro-arguments to get a vote on the test systems used with the EDN project, where I am not that much involved but it would make perfect sense to aim
<NiAsterisk>for an guixsd based system or at least guix as a package manager.
<mark_weaver>bah, the openssl security update has caused perl-io-socket-ssl's test suite to fail, and for someone like me who hasn't used perl for anything non-trivial in about 20 years, it's proving quite difficult to debug this :-(
<mark_weaver>it doesn't help that the problem only happens within the isolated build container
***ttuegel_ is now known as ttuegel
<janneke>how do i add an entries to grub.cfg and fstab (dual boot with ubuntu for now)
<mark_weaver>janneke: see the "GRUB Configuration" and "File Systems" sections of the Guix manual, both within GNU Distribution > System Configuration.
<janneke>mark_weaver: thanks
<NiAsterisk>does the hostlist accept things like mimageads*.googleadservices.com to capture 1,2,3,4,5,6,... for everything which could fit into the space behind mimageads? I started working on a proposal addition to the hosts service.
<NiAsterisk>the tl;dr will be: why stop at facebook with hostblocking options.
<mark_weaver>NiAsterisk: can you post to guix-devel@gnu.org about it?
<NiAsterisk>ok
***Digitteknohippie is now known as Digit
<Jookia>Congrats FSF staff and members at hitting 450k :)
<mark_weaver>\\o/
<lfam>The email on the list about making sure that iptables shows up for `guix package -s firewall` leads me to wonder: Does GuixSD have declarative iptables configuration yet?
<mark_weaver>lfam: if it does, it's news to me. I guess that would be best done as an iptables-service.
<CompanionCube>you know what might be an interesting feature? an option to confirm the resulting download/build before it executes
<lfam>CompanionCube: What do you mean?
<CompanionCube>lfam, basically after the 'following derivations/files will be downloaded/built' it'd be nice to be able to review the list before going ahead
<NiAsterisk>CompanionCube: or to have an interactive dialoge (maybe it's already possible)
<NiAsterisk>yes/no
<lfam>Oh right. I have had the same thought occasionally. But IMO it would have to be a setting that is turned on, since the default must be non-interactive.
<Jookia>--dry-run is pretty good
<CompanionCube>Jookia, indeed it is
***necronian_ is now known as necronian
<CompanionCube>but it'd be nice to not have to run 2 commands
<NiAsterisk>before I knew about dry-run.. i wondered, is this too intrusive? people who want the update will update and can review it with guix package -l afterwards. but what if they are low on bandwith, diskspace, time and just are curious about what's there to update?
<CompanionCube>NiAsterisk, or if they don't want to compile anything big without knowing
<lfam>I never noticed --dry-run. It seems to me a sufficient solution.
<NiAsterisk>does dry-run show size downloaded and disk space used?
<Jookia>I don't think so
<CompanionCube>it's tempting to see if I can move my ruby and & gems over to a consistent set of guix packages in my profile
<CompanionCube>what is the current state of ruby/gem packaging in guix?
<lfam>CompanionCube: https://fosdem.org/2016/schedule/event/guixmodules/ <-- Presentation on Ruby, Python, and R packaging in Guix
<janneke>how do i switch to a previous system generation (or roll back the last)
<lfam>janneke: Reboot and select an earlier generation in the GRUB menu
<lfam>You can use `guix system list-generations` to see what's available beforehand
<janneke>lfam: yeah, i like to get rid of the last (at least until i get my handwritten extra menu-entries working)
<CompanionCube>now the difficult bit: replicating my previous gem install in guix
<NiAsterisk>re:iptables oh. thanks for the hint in the direction of GNU change logs. I'll read into it and change things. no idea how I could not know about this.
<lfam>NiAsterisk: I also noticed your comment about names. It's not necessary to use your "legal" name if you prefer not to.
<lfam>Also, I did not know about GNU change logs before doing things for Guix. No big deal!
<NiAsterisk>no, it's okay. I am sorting some things out, and some projects I contribute to with pseudonym, some with an abstract of my name and some with the full name.
<lfam>Okay, I just wanted to make sure you knew that
<NiAsterisk>okay, thanks though :)
<lfam>I'm working on a package for nmap. Overall the build system is very easy to use. However, it bundles all of its dependencies in case you don't provide them. And some of its dependencies bundle their dependencies...
<lfam>ACTION groans
<Jookia>Ah, the google way
<NiAsterisk>but, guix specific: don't you include the location of the file in the commit message? gnu/packages/file.scm seems to be more exact to me then just file.scm.. give it some more years and there could be a case where suddenly there's file.scm in n places. okay, commits with git solve this problem iirc, but is this okay?
<Jookia>Well, you can look at the actual commit to figure out what's going on
<lfam>See this commit for an example: 16414017f30f944cfe964f1d9141bdcbf56be857
<NiAsterisk>ah, i see.
<NiAsterisk>okay, understood.
<NiAsterisk>q
<NiAsterisk>urgh
<NiAsterisk>sorry for keyboard dancing misshap
<CompanionCube>hm
<CompanionCube>is there a nice way to create packages for ruby gems not already packaged?
<Jookia>guix import I think
<CompanionCube>does bundler still work when using guix ruby
<CompanionCube>because guix import will result in me having to repeatedly run it for the damned dependency graph. do not want.
<Jookia>You might want ;) Maybe there's a way to script it? And I think it does
<lfam>Diffoscope HTML reports are nice :)
<CompanionCube>grr. It seems bundler installed some stray packages directly into /gnu/store
<davexunit>what? it shouldn't be able to write there unless you are root.
<davexunit>on GuixSD it wouldn't work even if you were root
<davexunit>don't run bundler as root.
<alezost>mark_weaver: "en_US.UTF-8" works because it is a special case, for the rest locales only "utf8" works. Look at http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/locale.scm#n155
<CompanionCube>davexunit, not root
<Jookia>"building of `/gnu/store/hsaqbkh9x95lpv0gyrwx4c8ccz59mv57-gdk-pixbuf-2.32.3.drv' timed out after 3600 seconds of silence" hmm- it seems the tests of gdk-pixbuf are either crashing my machine or timing out
<davexunit>CompanionCube: then what you say isnt true
<CompanionCube>because a set of gems spontaneously appeared in the stored ruby
<mark_weaver>alezost: myglc2 reported that when using (locale "en_US.UTF-8") in the OS config of his headless server, logging in remotely from a Mac running iTerm2 and running Emacs info, all of the directional apostrophe's showed up as question marks.
<mark_weaver>and he reported that by changing it to (locale "en_US.utf8"), the problem was fixed.
<lfam>Jookia: You can change the --max-silent-time of `guix build`. But that's probably not the real problem
<Jookia>lfam: Yeah :\\ I'm not sure what's happening, perhaps the system runs out of RAM.
<lfam>Jookia: Check the logs on hydra.gnu.org to see if its unique to you
<lfam>If it was out of RAM the kernel would kill the builder
<Jookia>Is there a command to grab the log from hydra.gnu.org?
<lfam>Jookia: I think there is in guix.el but I don't know how to use it. Usually I go to the web-based guix package list, find the package, and click on the architecture I'm interested in. It's stupid but it's faster than waiting for hydra.gnu.org's web interface which I don't really understand.
<lfam>Oh, in some cases `guix build --log-file` will download hydra's log
<lfam>If the built artifact is from hydra
<Jookia> http://hydra.gnu.org/build/962656/log#line-1245 This is the last line I have, hmm
<alezost>mark_weaver: no idea why it happened; I just reacted to your phrase that you have no problems having (locale "en_US.UTF-8") in your system: any other "xx_XX.UTF-8" wouldn't work at all, but you know it apparently :-)
<lfam>Jookia: Is your machine reasonably powerful, or could hydra's 13 minutes turn into > 1 hour?
<Jookia>lfam: It's a T400, so perhaps it could. I'm not sure
<lfam>I don't know what hydra's x86_64 build machines are, so I can't say
<Jookia>I can't run the tests with the failed build either, it just gives me error messages :(
<lfam>Well, you could increase the max-silent-time and go to a movie ;)
<lfam>Yes, I would expect that to not work
<Jookia>Is there a way to debug the tests?
<lfam>I would enter the failed build directory, source the environment-variables file, and run them manually. You may need to elevate your privileges if they want to write. I'm happy to hear a better suggestion!
<alezost>cajg: most likely there is an error in your config. If you paste it, people here may tell what's wrong
<lfam>alezost: cajg did share their config eventually
<lfam>cajg> okay, here 'tis: http://paste.lisp.org/display/306215
<Jookia>lfam: I'm not sure what I'm suppose to run though :( I've complained about the lack of debugging tools in Guix before so it's not that useful- sourcing the environment-variables and running 'make check' complains about missing test plans
<alezost>lfam: it had several (many) errors, and I don't know what was fixed and what left