IRC channel logs


back to list of logs

<tennix>when i open a guix package file in emacs, i always get an warning: the local variables list in xxx contains values that may not be safe. and a prompt in minibuffer
<iyzsong>tennix: I only got the prompt once, after that a 'safe-local-variable-values' entry added to my init.el.
<mark_weaver>tennix: one of the keys you can press there (maybe '!' ?) will arrange to not warn you about those particular settings henceforth.
<tennix>i just ask this in #emacs channel, they say it's because .dir-locals.el in the root directory of guix.git
<tennix>I find the explanation here
<chipb>xentrac: yeah, it looks like you're fine in that the recent glibc used for guix (and indeed, current trunk glibc) actually supports the oldstable kernel version (3.2). I had to revert back to version 2.19.1 with --enable-kernel=2.6.18
<chipb>I'm pretty sure my instability arises from a compatibility mismatch between the guix libX11 and the X server I'm using.
<chipb>odd flaky hangs with graphical emacs (terminal mode doesn't exhibit issues that I've seen) and the local Xorg, and insta-crash of my NX sessions when I so much as launch graphical emacs in them.
<chipb>not really sure how to go about troubleshooting that sort of issue.
<chipb>ah, I guess I could ltrace to narrow down exactly when the NX crash occurs.
<yenda->if I want a quick and dirty solution to have clojure up and running before going further later what should I do to get the java cacerts in place ?
<yenda->I took them from a debian install
<yenda->I noticed that nss-certs are declared in the global packages in the config.scm so I guess I should def a package that copies the file in /etc/ssl/certs/java and sudo guix package -i java-certs ? or sudo guix system reconfigure config.scm after adding the package there ?
<amz3>héllo :)
<amz3>what is the difference between guile-emacs and guile-for-guile-emacs ?
<amz3>ah ok guile-for-guile-emacs is guile
<ifur>mark_weaver, yenda-: mplayer2 is deprecated, use mpv instead
<ifur>and no reason to use vlc :/
<iyzsong>ACTION use mpv, but think vlc is good in its own way.
<alezost>ACTION uses mpv with EMMS
<ifur>ACTION misses a quick and dirty tutorial for how to monkey patch services in config.scm to start up acpid and wpa_supplicant
<ifur>ACTION need to learn guile and dmd first before making it :/
<yenda->I tried totem but it couldn't read either
<mark_weaver>yenda-: couldn't read? if you mean that it couldn't read patent-encumbered video formats, installing gst-plugins-ugly and setting GST_PLUGINS_PATH may help
<yenda->ok I'll try, maybe it was dropping file just like vlc I'll check tonight
<davexunit>I've noticed that icecat doesn't do patent encumbered video formats
<davexunit>mp4 specifically
<davexunit>would like to resolve that
<yenda->is there an exemple of pacakge that source a local file ?
<amz3>When I install guile-emacs with guix on top of debian and when I start guile-emacs I get a white window with decoration
<taylanub>ifur: I packaged mplayer2 because I was still using it, but on the meanwhile I mostly switched to mpv too, so I guess we should remove mplayer2...
<taylanub>I've been meaning to look into it and possibly solve the crash, but I can't find much time these times :(
<davexunit>ACTION looked at importing java packages from, but they only host binaries
<davexunit>it seems that they don't host the corresponding source code, which makes me feel like they are violating the GPL somewhere
<ifur>taylanub: just rip it out and create a symlink that also warns about it being removed and to move config to .mpvrc?
<ifur>its the responsible thing to do, even if it breaks something... deprecated software is always tricky...
<taylanub>not sure what exactly you mean. the choices I see are 1) fix our mplayer2 recipe so the executable doesn't crash anymore, 2) simply remove mplayer2 from guix.
<ifur>taylanub: the latter is what i mean
<ifur>but inform about mpv... so nobody tries to dig it out of the grave
<amz3>won't happen :)
<taylanub>I see. don't think we have a mechanism for that so far though.
<taylanub>that is, making guix print "you probably want to install X instead" when user tries to install Y or searches for Y.
<taylanub>well, mentioning mplayer2 in the description text of mpv would help when using --search
<taylanub>I might look into doing this later today, currently quite busy...
<yenda->how would you define a package whose sole purpose is to copy a file from one point to another ?
<mark_weaver>davexunit: regarding icecat and encumbered formats: I've noticed the same, and made some modest effort to get it working but no luck so far.
<davexunit>mark_weaver: do you know what the issue is?
<mark_weaver>yenda-: there are some good examples of packages like that in fonts.scm using the trivial-build-system
<davexunit>or what one of the issues are?
<mark_weaver>davexunit: no, I don't know what's going on
<davexunit>mark_weaver: okay
<davexunit>maybe I should ask ruben about it
<mark_weaver>I've never had much luck getting responses from Ruben, but YMMV.
<yenda->mark_weaver: thanks, but how do I source a local file ?
<taylanub>yenda-: what exactly do you intend to do?
<yenda->taylanub: get a cacerts file copied in /etc/ssl/certs/java
<yenda->later compile the certs properly by doing a making a clean package definition for that but first I want to have something running properly
<taylanub>yenda-: installing a package will only ever change the contents of a "profile" directory; it can't just put files into /etc. that would be done with a "system" configuration I think, with which I have no experience so far.
<mark_weaver>taylanub: On GuixSD, /etc/ssl is a symlink to /run/current-system/profile/etc/ssl, so if yenda- installs a package with ./etc/ssl/certs/java in his system profile and reconfigures, it will be there.
<yenda->yes that was my plan
<taylanub>oh, thanks for clearing it up. sorry about the confusion.
<mark_weaver>ACTION is now running GuixSD with Xorg on his Lemote YeeLoong
<mark_weaver>much to my surprise, our version of xorg-server works on the YeeLoong without any modifications
<mark_weaver>(last I checked, a few years ago, it required some ugly non-upstreamable patches)
<bavier`>mark_weaver: that's exciting
<davexunit>looks like the docker folks are starting to address some of their security issues
<davexunit>signed images is a good step
<davexunit>though they are still binaries that require trusting N third parties.
<yenda->don't you trust gcc binaries at some point in guix ?
<davexunit>yenda-: yes.
<davexunit>we build a distro from a small number of bootstrap binaries. you need only trust those. with Docker, you need to trust everyone.
<davexunit>everything, rather.
<mark_weaver>bah, a new set of security flaws and fixes for firefox-esr38, and we still have no GNU icecat for esr38, which means now I have to backport those fixes to esr31 :-(
<yenda->The link to The REPL here is wrong
<yenda->I get a 404 I assume it was meant to be
<yenda->could you tell me why guix tells me "the source expression failed to match any pattern" ?
<davexunit>yenda-: the 'source' field is invalid
<yenda->I went through the chan history and that's how someone said a local file is sourced
<davexunit>I've never ever used that
<alezost>yenda-: I don't think that link may be fixed. IIUC it is automatically generated to be a reference to The source of the manual are .texi files and they don't hardcode any urls. If you read the manual using info system (for example from Emacs), such links will open the proper info pages.
<yenda->alezost: ok thanks
<yenda->from the source in packages.scm I assume a local file should have this pattern : (? string? file)
<yenda->iiuc a string should be ok for source ?
<mark_weaver>yenda-: I think so, if it's an absolute file name.
<mark_weaver>although it's a terrible hack
<yenda->which doesn't seem to work apparently
<davexunit>it hasn't worked for quite some time
<mark_weaver>sorry, I need to focus on backporting fixes to 18 CVEs to our icecat :-(
<alezost>yenda-: I just use a usual 'origin' thing but with "file://" spec: (source (origin (method url-fetch) (uri "file:///tmp/foo") ...))
<yenda->alezost: ah nice thanks !
<alezost>np, don't forget that you also need (sha256 ...) field for the local file as well
<amz3>IIRC you can do (source "/path/to/fun") this avoid the need to (sha256 2015iJAZZ... )...
<davexunit>docker will have user namespaces soon
<amz3>well if you use tarball it's better to use the origin thing
<davexunit>I can't beat them to anything
<amz3>they have yoda with them ;)
<yenda->amz3: I suspected it not to work but apparently that's not the cause of the error
<yenda->I always get source expression failed to match any pattern
<davexunit>amz3: that does not work
<davexunit>yenda-: you cannot set 'source' to a string value at this time
<davexunit>could be a bug, but best move on right now
<mark_weaver>yenda-: I would look at your code, but the URL you provided doesn't work for me.
<yenda->even if I copy the file on git an download it I get this error
<yenda->what is the matter with the link ?
<mark_weaver>yenda-: from emacs eww, I get: "You need a password to access this pad". From GNU IceCat, I get: "An error occured while loading the pad" and "ReferenceError: $ is not defined [...]"
<mark_weaver>can you use ?
<mark_weaver>yenda-: the license field is not within the 'package' form', but rather within the 'define', so the 'define' form is invalid syntax.
<mark_weaver>also, it should (build-system trivial-build-system)
<amz3>yenda, davexunit I can't test it but I have it in a package (source "/path/to/source/")
<mark_weaver>regarding the icecat security updates: so far I've groveled through the mozilla source repository to find 17 patches on the esr38 branch, and 2 on the master branch, that need to be backported to esr31.
<davexunit>amz3: I had (source ".") in some of my dummy packages used only for 'guix environment' but they broke awhile back
<davexunit>so I've changed them to #f
<mark_weaver>interestingly, I noticed that although mozilla claims to have fixed CVE-2015-4487 in esr-38.2, they don't seem to have done so on that branch.
<yenda->ty for the review, the build error wasn't really clear, no I have new errors but it is fixable mark_weaver
<davexunit>mark_weaver: sounds very hairy.
<mark_weaver>I found the fix on their master branch though
<yenda->when I saw this on HN I was 99% sur I'll see davexunit comment in it
<yenda->a bit disappointed you didn't try to ninja-advertize guix though :)
***davi_ is now known as Guest53538
<amz3>yenda do it ;) I upvote you
<yenda->How come IceCat is so far behind Firefox ? I'm having a quick look at the mailing list and I'm "happy" to see I'm not the only one for which the spyblock doesn't work
<yenda->I looks like they try to do too much more than just remove trademarks ?
<yenda->(^this is what wiki says it does)
<remi`bd>hey! do you have some news of the DHCP client?
<yenda->well my java-certs package works but it's still not enough to make java work
<yenda->it might be because now root owns the cert
<davexunit>yenda-: I figured that I shouldn't do that *every* time there's a nix discussion ;)
<yenda->it looks like the other certs don't have the same rights and owner than the java I added
<yenda->but it's a readonly filesystem so I'm stuck
<yenda->can I define the owner and permissions in my package ?
<yenda->nss-certs dont seem to do it that way
<mark_weaver>yenda-: you certainly can't set the owner
<mark_weaver>why would you need to?
<mark_weaver>I would think this is public information
<guixnewbie>I want to install GuixSD, but only USB installation images are available, and I don't have a USB stick at the moment. Can I boot it from a CD somehow instead?
<guixnewbie>Or via some other method?
<mark_weaver>guixnewbie: we don't provide CD images, sorry
<mark_weaver>the other option is to install guix on top of another distro (perhaps using our binary-installer) and then run "guix system init" from that system to create a fresh GuixSD system on another partition.
<guixnewbie>mark_weaver: Thanks! I think I'll give that a try.
<bavier`>I'm having issues with the dynamic linking of "setns" in guix/build/syscalls.scm. I'm guessing my libc is too old. Is there any way around it?
<davexunit>bavier`: what libc and kernel version?
<bavier`>libc-2.11.3 and kernel 3.0.101
<davexunit>setns was introduced in linux 3.0
<davexunit>not sure when a libc wrapper was added for it
<davexunit>why are you running such an outdated kernel?
<bavier`>the workstation I use at work
<davexunit>2.14 introduced setns
<davexunit>glibc 2.11.3 was released on 2010-11-30 according to the timestamp on
<bavier`>davexunit: thanks
<davexunit>if you build guix with guix
<davexunit>you will get the right glibc
<bavier`>davexunit: my problem is that I've had admin rights wrested away from me, so I have no way to install the guix binary
<mark_weaver>davexunit: it would be good to support libc < 2.14
<bavier`>could I build a newer libc, with e.g. GSRC, or would that be dangerous?
<mark_weaver>bavier`: I thought you already had guix installed there, no?
<mark_weaver>davexunit: how hard would it be to cope with a lack of setns in libc?
<bavier`>mark_weaver: I had. Then IT brought down the hammer.
<mark_weaver>so you won't be able to run guix-daemon as root, nor the store in /gnu/store ?
<bavier`>I was able to build guix with a checkout from before the introduction of setns in guix/build/syscalls.scm, so I might be able to rewind and use that prior version to bootstrap master
<bavier`>mark_weaver: correct
<mark_weaver>bavier`: well, I've told people here before that I'm doubtful that it will work
<bavier`>but that's a use-case that's interesting to me in other areas
<mark_weaver>well, I agree, and it could be made to work, but I'm doubtful that it will work now.
<mark_weaver>so, you'll need to build everything from source, which is a lot
<bavier`>mark_weaver: I had to patch two things, and was then able to build guile
<mark_weaver>but the bigger problem is that you'll need to build everything from source outside of any chroot, which means that configure scripts will find things in /usr and probably try to use some of that stuff.
<davexunit>mark_weaver: I'll try to make it work I guess.
<davexunit>but I don't think asking people to use a glibc from october 2011 or after is asking much.
<mark_weaver>with a new enough kernel (>= 3.8), user namespaces could be used to make a build container, but that's not yet implemented in guix-daemon
<mark_weaver>davexunit: well, libc is not something that users can reasonably update. they have whatever they have.
<davexunit>I guess I need an eval-when or similar to avoid evaluating the forms that define setns and friends.
<mark_weaver>(at least not on most distros)
<mark_weaver>some people will be using RHEL or clones, for example
<davexunit>they have to both be running an old distro and not have root.
<bavier`>I'm on SLED 11 (without root)
<mark_weaver>davexunit: how does root help?
<bavier`>davexunit: SUSE Linux Enterprise Desktop
<mark_weaver>we are spoiled on Guix. it is trivial and safe for us to fool around with updating libc.
<mark_weaver>on most distros, updating libc is an extremely dangerous operation
<davexunit>mark_weaver: they can install the guix binary and build their own guix with guix.
<mark_weaver>well, okay, that's true
<davexunit>mark_weaver: anyway, do you know how I'd go about adding a compile-time check for the relevant libc functions?
<mark_weaver>davexunit: use AC_CHECK_FUNCS in the see guile's for an example
<davexunit>mark_weaver: thanks
<mark_weaver>although I wonder if this check needs to be done at compile-time, since we use the dynamic FFI anyway
<davexunit>mark_weaver: I could do it at runtime, but I'm also unsure what the appropriate thing to do is.
<davexunit>I can catch the exception when function lookup fails
<mark_weaver>davexunit: how about just binding setns to #f if the lookup fails?
<mark_weaver>or better yet, to a procedure that raises an error if called.
<mark_weaver>and maybe there could be another boolean variable that indicates whether those functions are available.
<davexunit>mark_weaver: sure.
<mark_weaver>cool, thanks!
<davexunit>bavier`: just fyi, we don't use setns in any released code yet, so feel free to remove it to get rid of the problem on your workstation
<davexunit>it will be used eventually for inserting processes into running containers
<bavier`>davexunit: ok, thanks!
<mark_weaver>bavier`: the entire system can probably be made to work properly without isolated build environments, but it might be a lot of work, dunno.
<mark_weaver>running all of the builds in a build environment that has access to a host system in /usr etc is something that has seen essentially no testing.
<mark_weaver>I had suggested a different solution to civodul a while back, that would allow binary substitutes to still be used on systems where the store had to be in your home directory (for lack of root)
<bavier`>mark_weaver: how would that work? via grafting?
<mark_weaver>it would involve us changing the default store directory from /gnu/store to something longer, so that the builds could be grafted to contain the real store directory later.
<mark_weaver>but civodul seemed reluctant, and I didn't persue it further.
<mark_weaver>feel free to talk to him about it. I would be in favor of such a mechanism, fwiw.
<bavier`>would be interesting
<bavier`>but I could understand that we might want a few convincing use-cases
<davexunit>mark_weaver: I'm interested in rewriting /gnu/store references for the purpose of producing standalone binary distributions of software
<mark_weaver>so, consider a user with an 8-char username who wanted to put the store in their home directory. /home/12345678/g
<mark_weaver>that could be their store directory
<mark_weaver>16 characters
<mark_weaver>so, we could change our store directory to /gnu/store-xxxxx
<davexunit>mark_weaver: aren't we greatly limited by shebang limits?
<mark_weaver>which is the same length
<mark_weaver>davexunit: yes, but I think it would be okay to add 6 more characters
<mark_weaver>s/think/hope/ :)
<davexunit>why there's a 127 (right?) character limit in 2015 is beyond me
<davexunit>and a hard limit at that.
<mark_weaver>yeah, it's pretty insane
<davexunit>I imagine *someone* has proposed that it be changed at this point
<mark_weaver>ACTION goes back to backporting icecat fixes :-/
<davexunit>it concerns me because I know our system is pretty solid, but living so close to the edge of such restrictive limits is very concerning to me.
<mark_weaver>we could increase the limit in our own copy of linux-libre, but of course that won't help users without root
<davexunit>or users using guix on top of another distro
<mark_weaver>bavier`: in the worst case, you could build guix on another box that you have root access to, and then run 'guix publish' on that box so that it can provide substitutes to your IT-dominated system.
<mark_weaver>or, perhaps, run guix within a virtual machine to do the builds.
<bavier`>mark_weaver: getting qemu up and running is actually one of the first things I want guix to help me with on this machine
<osmano807>I'm having a problem, if I uncomment the console-keymap-service, my grub.cfg becomes empty
<osmano807>It's a pretty basic config.scm:
<yenda>are you sure the keymap you request is there ?
<osmano807>It works with loadkeys
<osmano807>yenda: What intrigued me is the blank grub.cfg after enabling the service
<yenda>that is wierd indeed mine isn't and I have keymap service as well
<osmano807>"Service console-keymap has been error: 'waitpid' unexpectedly failed with: "No child processes""
<osmano807>I tried with another keymap and the boot stuck
<yenda>what do you mean the boot stuck ? You mean it worked ?
<yenda>or that you got stucked during boot ?
<mark_weaver>well, this is terrible, I'm unable to backport all of the fixes from firefox esr38 to icecat 31
<osmano807>yenda: stucked during boot
<mark_weaver>I backported the fixes that were within my abilities, but some of the stuff is in code that has changed a *lot* between v31 and v38