IRC channel logs


back to list of logs

<anthk_>is guix-web available?
<civodul>it's super available:
<civodul>davexunit and rekado know more about the current status
<ijp>any chance of getting guix.el in elpa or marmalade?
<davexunit>it's not useful without the rest of guix
<ijp>okay, then secondary question. is it supposed to be installed when you use the binary installation of guix
<davexunit>if guix is in your profile, yeah.
<davexunit>you just need to set the emacs load path as needed
<ewemoa>hmm...phantomjs seems to use some bundled bits...
<davexunit>ooh, good additions to the manual about 'guix environment'
<davexunit>glad that civodul is good at explaining things. I always have such a hard time with it.
*davexunit is having trouble implementing 'eval-in-container'
<ewemoa>rekado: regarding help(read.csv) in R, AFAICT, the Renviron that gets installed in the store leads to PAGER being set to 'false' if one doesn't have PAGER or something appropriate set up in one's own .Renviron -- so setting PAGER or configuring .Renviron seem to be work-arounds...
<rekado_>ewemoa: I just tried it with R 3.2.1 on my workstation in an Emacs shell-mode buffer.
<rekado_>help(read.csv) prints pages full of documentation.
<ewemoa>rekado_: i will build 3.2.1 and test again
<ewemoa>rekado_: but i suspect that if /gnu/store/*r-3.2.1/lib/R/etc/Renviron has the line: PAGER=${PAGER-'false'} and the user has no ~/.Renviron and doesn't have PAGER set in their environment, they may experience the same problem
<rekado_>in Emacs my PAGER is set to "cat". I don't have ~/.Renviron
<ewemoa>rekado_: originally, i didn't have ~/.Renviron and didn't have PAGER set in my shell -- so with that set up, even via M-x shell in emacs, help(read.csv) lead to just a prompt showing
<rekado_>I can reproduce this when starting R with "PAGER= R"
<rekado_>but I don't think that's a problem with the R package.
<rekado_>It's a problem with R (or the environment in which it is run).
<ewemoa>rekado_: FWIW, R's configure leads to filling in Renviron that gets stored in the store -- in at least one other distribution, the default fall-back value for the pager is less -- while what happens for the R package now is the fall-back value is false -- that doesn't seem very friendly to me
<ewemoa>by 'default fall-back value for the pager' i mean specifically what happens via Renviron
<rekado_>I see.
<rekado_>I find this a little odd. "R.home()" shows me that the output's "lib/R" directory is considered to be the R root. That's correct. On startup it should look for R_HOME/etc/Renviron
<rekado_>This file does exist.
<rekado_>is it actually loaded?
<rekado_>it is, but PAGER defaults to "false" there if unset.
<rekado_>./etc/ contains @PAGER@ --- I'll look around to see if it can be set somewhere.
<rekado_>ewemoa: apparantely, passing PAGER=cat at build time should be sufficient. I'm rebuilding.
<rekado_>I think it makes sense to default to a pager that prints *something* rather than "false"
<ewemoa>rekado_: yes, that makes more sense to me too
<rekado_>since cat is always there I think it's a reasonable default pager.
<ewemoa>rekado_: FWIW, here less is /run/current-system/profile/bin/less -- is that not there by default too?
<ewemoa>ah, may be that's not sensible for non-guix sd systems
<rekado_>"find /gnu/store/ -name less" doesn't return anything on this fedora system with guix as package manager.
<ewemoa>cat is sounding more reasonable now :)
<zacts>I acidentally posted something on #guile, that I meant to post here. anyway, yeah...
<rekado_>hmm, matplotlib isn't working for me.
<rekado_>it fails attempting to initialise Gtk.
<rekado_>"RuntimeError: Gtk couldn't be initialized"
<rekado_>I have GI_TYPELIB_PATH set to $HOME/.guix-profile/lib/girepository-1.0
<rekado_>any ideas how to fix this?
<rekado_>oh, apparently I need to build (and install?) the gtk+ package..
<rekado_>hmm, even after installing gtk+ into the profile it fails to load up :(
<rekado_>when I do "import matplotlib.pyplot as plt" I get this error:
<rekado_>Failed to load shared library '/gnu/store/sc5wj39hcn3gxcrwc8q1rss11gqh20g8-gtk+-3.16.3/lib/' referenced by the typelib: cannot open shared object file: No such file or directory
<rekado_> exists; it's a symlink to the actual so.
<rekado_>this one is also failing: "from gi.repository import Gdk"
<rekado_>"RuntimeError: Gdk couldn't be initialized"
<rekado_>confusingly, this does work on my workstation, but does not work on the cluster.
<rekado_>blerg, I should have used "ssh -X"...
<rekado_>ewemoa: about your patch for installing info files for R -- I could apply it for you, but I'd like to know how I should credit you.
<civodul>Hello Guix!
<davexunit>hey civodul
<civodul>davexunit: i pushed a tests and bug fix for 'guix environment' in wip-environment
<civodul>your feedback is welcome :-)
<civodul>i'd also like to add --system and --target switches
<civodul>anyway we can discuss it later on the list
<davexunit>civodul: sounds good to me. I'll review it later on.
<davexunit>been hacking on eval-in-container
<civodul>we'll see which one of us will commit first, since we both touched that file :-)
<davexunit>quite a tricky thin!
<davexunit>getting the list of output paths to bind-mount is tricky
<davexunit>seems I have to pre-compute the module derivations that gexp->script will make.
<davexunit>I'm happy to see people hacking on 'guix environment'. :)
<Steap>davexunit: oh, btw
<Steap>one can run "guix environment guile" to have an environment with all the dependencies of the "guile" package
<Steap>but is it possible to have an environment with guile actually installed ?
<Steap>(I mean, without creating a "meta-package" that would depend on Guile)
<davexunit>Steap: I added an option for this recently: --ad-hoc
<davexunit>'guix environment --ad-hoc guile -E guile' will launch a guile REPL
<davexunit>it's good stuff ;)
<davexunit>I'm really feeling the enormous power that comes with being able to manipulate environments so easily.
<davexunit>even more so when I can jail processes within a container.
<ewemoa>rekado_: at least from this end, credit is not necessary -- fwiw, the change is pretty much a copy-paste of a portion of qemu-headless
<civodul>davexunit: BTW, we'll have to think about running GuixSD services in containers
<civodul>it might be useful in some cases
<civodul>and it comes for free :-)
<davexunit>civodul: yes!
<davexunit>take that, everyone else!
<davexunit>I've been wondering how many knobs we'll want to tweak for this stuff.
<davexunit>like maybe some services don't want a separate network namespace or something
<civodul>that's what i thought
<civodul>like ntpd, etc.
<civodul>so call-with-containers would need a keyword argument or something
<davexunit>of course, they could be made to work in the network namespace via a bridge
<Steap>davexunit: I'm trying to replace tox (a Python tool to run tests and manage virtual environments) with something guix-based
<Steap>and guix environment is the perfect tool for that!
<davexunit>civodul: #:key (namespaces '(user mnt ipc uts net pid))
<davexunit>or rather (define %namespaces '(user mnt ipc uts net pid))
<davexunit>#:key (namespaces %namespaces)
<civodul>davexunit: yes, that would be perfect
<davexunit>(call-with-container ... #:namespaces (delete 'net %namespaces))
<davexunit>cgroups will be important, too, but that's a whole different feature set that I haven't even started to build.
<davexunit>I don't think it will be tooo hard to do. netlink will be more difficult.
<davexunit>help!! :)
<civodul>Steap: it would be nice to see how it can be made convenient/intuitive/wonderful for people used to tox/virtualenv
<davexunit>Steap: blog post requested!
<civodul>i think the intersection between Guix and Pythonistas is non-empty, so something should be done about it :-)
<Steap>civodul: I managed to write a recipe to test a single OpenStack package yesterday
<Steap>but that is not very easy to do
<Steap>you need to write a recipe etc.
<Steap>I think one can re-use tox by removing the "virutalenv" part and writing a "guix" part instead
<Steap>davexunit: actually, civodul suggested that I go to PyconFR in a few months, and my company might pay for the trip, so even better than a blog post :)
*Steap needs a proof-of-concept first
<davexunit>oh wow! yay!
<davexunit>I'd like to figure out how to get myself to some important conference to talk about guix stuff
<davexunit>provided there's not much travelling involved. I don't like planes.
<Steap>davexunit: don't you like planes, or airports ? :p
<davexunit>planes scare me.
<Steap>Planes are fun, I wish I could fly without having to go through airport fasci^W security
<civodul>i think it's challenging but fruitful to talk about Guix before "foreign" audiences
<davexunit>I live in Boston, which is a tech hub, but it seems like there's never that many cool conferences around here.
<davexunit>I guess because it isn't San Francisco.
<Steap>civodul: yeah well, feel free to spend time in the Five Eyes, in religious countries, etc.
<davexunit>civodul: yeah, I want to introduce Guix to more people. some people won't be open minded, but it always piques someone's interest.
<Steap>Wouldn't feel safe there :)
<davexunit>someone is bound to "get it"
<civodul>Steap: by "foreign", i meant people like Pythonistas, Dockerists, etc. who may be "skeptical" by default
<civodul>as opposed to talking at a GHM etc.
<Steap>yeah I thought "geographically" :D
<civodul>no, that doesn't really matter to me
<davexunit>yeah, I want to talk to those people, too.
<davexunit>and prepare some presentation targeted towards them.
<Steap>civodul: well, it is a good thing that it got out of Talence, isn't it ? :p
<civodul>sure :-)
<civodul>i was at an intro to Vagrant this morning
<civodul>i think we want to talk to those people who look into Vagrant :-)
<Steap>oh, where was that ?
<Steap>I used to use Vagrant
<davexunit>we should find ways to talk to Docker and Vagrant users, definitely.
<civodul>Steap: it was at "JDEV", next to the office
<davexunit>the problem is that a lot of these people use an OS X host system
<civodul>yeah, true
<Steap>davexunit: they usually have a GNU/Linux VM :D
<Steap>civodul: you know, there is a JUG in Bordeaux, right ?
<civodul>"J" as in "Java", right?
<Steap>and also people do meetups at the
<Steap>civodul: yeah, but they might need guix as well :)
<civodul>right, so that's less obvious to me how to talk to them, so to speak
<Steap>they are found of Docker I think
<Steap>just like the JS people from the
<Steap>because they like what is hype.
<civodul>well we should try to get a slot there this summer
<Steap>"Like good shit, not shit that is hype"
<civodul>i see what you mean, but i don't think that's the right way to get people to adhere ;-)
<zamnedix>hey, i just got guix up and running on debian/kfreebsd with some (very minimal) patching
<zamnedix>how would i go about getting the compatibility pushed upstream?
<mark_weaver>zamnedix: did you successfully build anything with it?
<mark_weaver>e.g. "guix build hello" ?
<mark_weaver>I don't see how it could work, honestly.
<mark_weaver>unless statically linked binaries for Linux work on kFreeBSD.
<zamnedix>mark_weaver: let me try, not sure what its done so far honestly, new to GUIX
<zamnedix>mark_weaver: does it use that much kernel specific code? kfreebsd does use glibc
<mark_weaver>the issue is that Guix builds all software starting from bootstrap binaries that we provide.
<mark_weaver>and we don't provide any bootstrap binaries compiled for kFreeBSD.
<DusXMT>mark_weaver: The FreeBSD kernel does have linux compatibility support, at least the last time I checked
<zamnedix>mark_weaver: could /i/ provide such binaries?
<zamnedix>yeah but its not very good/modern dusxmt
<zamnedix>not good enough for guix anyway, already tried
*DusXMT nods
<mark_weaver>well, the other thing is, this is almost certainly going to result in a *lot* of packages broken all over the tree.
<mark_weaver>it will add significantly to our maintenance burden
<mark_weaver>I'm not sure we want to take that on.
<zamnedix>basically id have to do it all
<mark_weaver>We do not have a goal to be portable to all systems.
<mark_weaver>our primary purpose is to create the GNU system.
<mark_weaver>but civodul is really the person to ask...
<DusXMT>But GNU/kFreeBSD is a possible approach at a GNU system...
<zamnedix>ooh here we go
<zamnedix>make check fails a bunch of tests
<mark_weaver>if you want to start working on it on your own branch, then look at the "porting" section of the manual.
<zamnedix>i will definitely check it out
<nully>hey zam :D good to i r c you here.
<zamnedix>hi nully
<mark_weaver>hey nully!
<mark_weaver>did you hear that the KFSN4-DRE is now officially supported by Libreboot?
<davexunit>oh cool!
<mark_weaver>zamnedix: well, I'd encourage you to try porting and see how many things break.
<mark_weaver>maybe it won't be as bad as I fear.
<mark_weaver>to make it really usable for people in practice, we'd need some kFreeBSD build slaves for our build farm also.
<zamnedix>mark_weaver: i am definitely going to at least try
<zamnedix>would love to be able to bootstrap guix in a jail
<mark_weaver>so there's code in nix/libstore/ that creates an isolated container for builds. search in there for CHROOT_ENABLED
<mark_weaver>you'll need to implement the kFreeBSD equivalent
<mark_weaver>zamnedix: ^^
<zamnedix>mark_weaver: got it, thanks
<zamnedix>well crap it seems kfreebsd still cant jail sysv ipc
<zamnedix>only disable it entirely in jails
<zacts>mark_weaver: is the reason for gnu su to not have a feature to deny non-wheel users still useful today?
<zacts>and I'm assuming that this means that guix doesn't have wheel users?
<zacts>^ the bottom section
<zacts>I mean I guess I agree with rms there, but I've also found practical use for a wheel group on some of my ssh servers
<zacts>in that I could host a public ssh box, and know that users couldn't log in as my normal admin user...
<zacts>I don't know if su logs attempts like sudo does
<zacts>so if su doesn't log attempts, then I guess password crackers could be a potential, but I personally use long random sha512 summed passwords anyway usually
<zacts>so I'm actually asking because I don't know
<efraim>zacts: from my logwatch, su attempts are logged
<efraim>wait, successful ones are logged, i'll search through my old emails to see if unsuccessful ones are too
<efraim>Jun 30 20:21:57 debian-netbook su[17668]: pam_authenticate: Authentication failure
<efraim>Jun 30 20:21:57 debian-netbook su[17668]: FAILED su for root by efraim
<efraim>so it is logged (in debian) in /var/log/auth.log
<civodul>efraim: the default syslogd.conf in GuixSD doesn't do that, but it should
*civodul gets hydra to build wip-diet ->
<rekado>yay for wip-diet!
<davexunit>I second that yay
<rekado>today I heard that matplotlib comes with a default backend called "Agg", so we may not necessarily need to build the gtk+ backend.
<civodul>rekado: dunno but we need to fix that bug that Fede reported
<civodul>it doesn't look hard
<absorto>Hello! so I used the bare-bones template and installed, then based a new config file off the desktop template and did a guix system reconfigure. It worked!
<absorto>So far so good. So: is there sort of a meta-package that will install better X11 fonts?
<civodul>absorto: no, you have to install gs-fonts and something like font-dejavu in your profile
<civodul>font-terminus is also popular
<civodul>thanks for the success report, BTW :-)
<absorto>nah, thank you guys, it's been all fun and learning.
<civodul>good to hear!
<absorto>so can I run several guix package --install concurrently? does it lock and unlock appropiately or something like that?
<davexunit>the result will not be what you want, I don't think.
<davexunit>given that the operations are atomic
<absorto>so I see!
<davexunit>so, the result will *not* be a destroyed profile, but it will not be a combination of all the concurrent processes.
<absorto>right, so that's why after the longer install finished it seemed the shorter one wasn't done!
<absorto>oh yes, much nicer fonts!
<mark_weaver>zacts: yes, su failures are logged
<mark_weaver>zacts: what is the practical use for the wheel group?
<mark_weaver>if the password is can be found by brute force attack, then you should use a better password, I say :)
<mark_weaver>the GNU system doesn't have the 'wheel' group concept. that's a BSD concept.
<zacts>mark_weaver: not being a security expert myself, I personally don't know
<zacts>the practical use though on BSDs
<zacts>is that you can deny certain users to become root ever via a normal su / sudo password logon
<mark_weaver>you can deny them access to root by not giving them the password, and using a good enough password that it cannot be brute forced.
<zacts>although, this obviously doesn't include security / kernel vulnerabilities
<zacts>I guess I personally don't see how security by obscurity is effective, and perhaps wheel uses this obscure method
<zacts>Perhaps, I'll try to search some old BSD / UNIX mailing lists on wheel as a mini-research project
<zacts>mark_weaver: I don't know enough about OS / kernel terminology, but doesn't the Hurd use something called capabilities?
<zacts>also, I think plan9 had some ideas on security, let me find a PDF
<mark_weaver>you should ask on #hurd about that, my knowledge of hurd is weak, although I'd like to learn more.
<davexunit>zacts: Linux has a concept called "capabilities", too.
<zacts>ah ok
<zacts>I'll ask on Hurd
<zacts>#hurd :-P
<civodul>mark_weaver: is there anything special about "wheel" in GNU?
<mark_weaver>civodul: I don't think so, and I don't think I've ever seen a 'wheel' group on any of my GNU systems either.
<mark_weaver>but it's possible that some programs treat it specially, dunno.
<civodul>in GuixSD it's advertized as "the group of sudoers", which is what our default sudo config does
<civodul>i think i got that from the sudo manual or something
<davexunit>it's not special, there just happens to be some GNU documentation written by RMS denouncing it. ;)
<mark_weaver>well, last I knew, the 'su' program on BSD systems would only allow users in group 'wheel' to become root.
<civodul>oh, ok
<mark_weaver>that is the traditional meaning of the 'wheel' group.
<mark_weaver>but yeah, RMS was against it and it was never adopted in GNU.
<civodul>but what GNU package is really concerned with this?
<davexunit>none on a technical level, that I know of.
<civodul>and there's a 'su' in Coreutils and one in the Hurd
<mark_weaver>'su' as part of a GNU package until recently.
<civodul>and... we all use that of util-linux :-)
<civodul>it's still in coreutils, but no longer built by default
<mark_weaver>ah, okay.
<zacts>oh interesting
<zacts>so we don't usually even use su from coreutils?
<zacts>we use the util-linux su?
<civodul>a couple of years ago the maintainers of util-linux and those of coreutils agreed to favor the 'su' of util-linux
<civodul>something like that
<civodul>BTW, not related but was accepted for
<civodul>so we'll be talking about Guix there end of August :-)
<davexunit>we need to get someone to one of those big conferences like StangeLoop sometime
<mark_weaver>civodul: nice!
<mark_weaver>interestingly, attempting to download it with 'wget' results in 403 Forbidden.
<mark_weaver>but I was able to download it with IceCat
<mark_weaver>anyway, it's not terribly important.
*davexunit remembers that our icecat still cannot do WebGL
<mark_weaver>davexunit: it's interesting, because I see these preprocessor macros in several compile commands in the IceCat build log from Hydra: -DMOZ_WEBGL='1' -DMOZ_WEBGL_CONFORMANT='1' [...] -DGL_PROVIDER_GLX='1'
<mark_weaver>I'm not sure what's going wrong
<davexunit>mark_weaver: yeah I'm not sure what's going on either. I looked briefly but compiling icecat on my computer takes too long.
<mark_weaver>it takes even longer on mine :-P
<mark_weaver>and yet I seem to have become the defacto icecat maintainer in Guix :)
<davexunit>I need my own build farm to throw this stuff at ;)
<davexunit>maybe once we have hydra-service
<mark_weaver>I see this in the web console when trying one of the mozilla webgl demos:
<mark_weaver>Error: WebGL: Can't get a usable WebGL context
<mark_weaver>"THREE.WebGLRenderer" "69"
<davexunit>yeah that's what I see
<davexunit>I'm pretty sure our icecat recipe includes mesa
<mark_weaver>I know very little about WebGL, so I'm probably not the best person to debug this.
<mark_weaver>I'm almost entirely ignorant of GL as well, for that matter.
<mark_weaver>(I mean to rectify this at some point)
<davexunit>my guess is that it can't load
<mark_weaver>sure, you could try attaching to icecat with 'strace' while it tries to get the GL context.
<davexunit>I'll try to do that sometime
<davexunit>when I have some extra time
<mark_weaver>if that's the problem, it might solvable by a wrapper that sets LD_LIBRARY_PATH
<mark_weaver>or better yet, patch the source where it does the dlopen
<mark_weaver>as for the long compile times, my suggestion is to leave it compiling overnight.
<mark_weaver>it is indeed trying to find and failing to find it
<davexunit>mark_weaver: nice! now to find out where to patch it.
<mark_weaver>well, that doesn't seem to be the only problem
<mark_weaver>or maybe its some other extension I'm running that's causing problems.
<mark_weaver>but it finds now anyway.
<mark_weaver>I worked around that problem by running LD_LIBRARY_PATH=$(guix build mesa)/lib icecat
<mark_weaver>anyway, I have to go afk now...
<mark_weaver>oh wait, that did fix it.
<davexunit>I've gotta now, too. see ya!
<mark_weaver>it was LibreJS that was blocking me.
<mark_weaver>okay, bye!
<zacts>what is LibreJS?
<zacts>is that the mozilla plugin, or is it a new node.js or something?
<zacts>oh I see
<zacts>yeah the former it seems
<Steap>I have a package that depends on python-flake8
<Steap>but when I install it, python-flake8 is not automagically installed
<Steap>what am I doing wrong ?
<Steap>oh, it was not propagated
<Steap>I see