***jonsger1 is now known as jonsger
<ryanwatkins>Hey guys, I have two questions. First, has the new guix talks at fosdem been uploaded? Second, is there a good vnc package available for guixsd? <rekado>ryanwatkins: we have already received review links for the recordings of Guix talks at FOSDEM. <rekado>ryanwatkins: we need to watch the videos, adjust start and end time, and then inform the video team that the recordings are good to be encoded at a better rate. <rekado>this is going to take a few more days. <Apteryx>Any recommended general purpose audio player to use as the backend of EMMS? <Apteryx>buenouanq: Is mpv better than mplayer? Why the preference? Is seems that mplayer is supported out of the box by EMMS. <Apteryx>There's at least the license. gpl2+ instead of gpl2 <buenouanq>Apteryx: mpv takes from mplayer and mplayer2, cleans them up and culls some bloat, and offers a simple minimal thing that just works <buenouanq>the lua scripting is also cool if you can into that ***brandon is now known as bldtg
<efraim>$out is normally (assoc-ref %outputs "out"), I'm not sure if it has to go somewhere special in that case though <bldtg>efraim: I'm not sure I understand. What does (assoc-ref %outputs "out") do? Like what does it return? <efraim>$out is the DESTDIR, its the location in /gnu/store that the program gets installed into <efraim>Assoc-ref... is another way to programatically refer to it <bldtg>efraim: Oh ok, that makes sense. <bldtg>I am way in over my head here. This package is taking a long time. <bldtg>efraim: What would I put in place of ${xfce4panel.out}? <efraim>Based on the nix definition I dont know if just regular 'out' works, it might need gtk-or-glib build system <efraim>I havent packaged a lot of software like that <bldtg>efraim: Well I think I'll work on it tomorrow; I have to get some sleep. Thanks for the help. <rekado>buenouanq: we have a package for the mpv player for EMMS. <rekado>sneek later tell bldtg They are replacing a reference to the binary “xfce4-panel” with its actual location in the panel package. It seems that by default it would use the current package’s prefix and look for the binary there. <efraim>I think I'm going to submit my lumina package to the mailinglist as is. I cant get slim to pick up lumina which makes it hard to test. Actually I take it back, I'll have to remove slim from my test vm and launch it manually <efraim>Interesting. Python-waf is the actual output, its not inside a directory <slyfox>efraim: how to do it properly? send an email to bug-guix@ ? <efraim>Yeah, I'm pretty sure its bug-guix <efraim>ACTION has to go, they're closing the airplane door ***jonsger1 is now known as jonsger
<rekado>I can reproduce the “guix environment mpv” error. <rekado>before the error I see this: grafting '/gnu/store/had60lhj181vcb5h912apk8anm02dn17-python-waf-1.9.5' -> '/gnu/store/i1139n4ab0fn9v4bwkvqzp6sw3w66mqr-python-waf-1.9.5'... <rekado>and then it fails because it doesn’t find the grafted directory. <rekado>but it also fails when adding “--no-grafts”. In this case it will try to use /gnu/store/had60lhj181vcb5h912apk8anm02dn17-python-waf-1.9.5, which also fails. <slyfox>how does guix know that file name should be 'waf'? <slyfox>when one installs python-waf it should appear as 'bin/waf', right? ***jonsger1 is now known as jonsger
<rekado_>slyfox: guix does not know that there’s a file by the name of “waf”. <rekado_>slyfox: every package has its own prefix under which all build artifacts are stored. <rekado_>slyfox: when creating the build environment guix computes the union tree for all these prefixed trees. <rekado_>i.e. all packages’ directories will be unified, including “bin” <rekado_>the PATH is updated to refer to the union’s “bin” directory. <rekado_>when running “waf” in the build environment it’s a regular lookup in the PATH. <rekado_>what happens in the case of “guix environment mpv” is very odd as it fails to build the union. <slyfox>oh, so it's probable that it's a bug in waf package instead of creating file named ${prefix}/bin/waf it creates file named ${prefix}? <rekado_>the way I interpret the error message is that for some reason the output directory of python-waf doesn’t end up in the environment. <rekado_>guix knows of all the store items’ directories that have been declared as inputs <rekado_>but it seems to be unable to access the python-waf output at this point. <rekado_>I’ve never seen an error like this before. I’d have to take a closer look at it. <efraim>rekado_: take a look at waf itself, there's no bin dir, its 'out' is waf itself <rekado_>I’m confused about “guix build --check”; I’m trying to test a reproducibility patch for R but running “guix build --check r” doesn’t build R, it just grafts R. With “--no-grafts” it only spits out the directory of the R store item. <rekado_>is this a regression or am I not using it right? <enderby>hi, for a while now i've been getting a "guix: offload: command not found" when doing a 'guix pull'. I saw there were some channel logs back in December regarding this, but I'm not able to resolve the issue after having un/installed guile-ssh, running 'guix environment guix --no-build-hook' <enderby>if anyone has a suggestion please lmk, thnx <bavier`>rekado_: it looks like you're using it right, I've used --no-grafts that way with --check before and it seemed to do what I expected <sankey>i managed to cause guix to leave a dangling lockfile, and now i just get this: <sankey>"waiting for locks or build slots... <sankey>i'm curious where that lockfile might be, so i can delete it <Apteryx>How (un)safe is running an SSH server at home and opening port 22 in the nat/firewall for remote access? <braunr>if you keep your system up-to-date and you have decent passwords, quite safe <Apteryx>Should I install some other tools to monitor unwelcome access attempts? <OrangeShark>Apteryx: there is things like fail2ban that can help <Apteryx>OrangeShark: Right! I know fail2ban was useful for a SIP server... I should look into what it can do for an SSH daemon. Thanks. <Apteryx>Another curious question: Is there any way to declare my service as to be run inside a "container"? <davexunit>Apteryx: not currently, but it would be nice. <davexunit>it would be nice to have a good control groups interface so you could also restrict system resources on a per-service basis <davexunit>but I haven't had time for much hacking these days and no one else has stepped up to improve the container implementation yet <janneke>Apteryx: Didn't civodul show how to do that? <Apteryx>davexunit: Agreed. Time is annoying. <davexunit>janneke: you can write your own services that do this <janneke>civodul showed a `world premiere' i think using (start #~(make-forkexec-constructor/container iso make-forkexec-constructor <Apteryx>janneke: Was this on the guix-devel mailing list? <Apteryx>OK! Thanks! I'll wait for the videos then :) <janneke>Apteryx: possibly there are slides already ;-) <janneke>but i'm not sure where make-forkexec-constructor/container lives (or if i remember the name wrong) <adfeno>Apteryx: Also, consider setting UsePAM, PasswordAuthentication, PermitRootLogin and ChallengeResponseAuthentication to "no". <Apteryx>adfeno: OK! PermitRootLogin to false is the default for both lshd and sshd. I'll shut password authentication and use key-based access only. As for UsePam/ChallengeResponseAuthentication, I'll have to see what the defaults are! Thanks for the recommendations. <Apteryx>lshd/sshd guix services, I should have specified. <adfeno>Apteryx: ChallengeResponseAuthentication is like the password authentication, although some security speciallists (not my case, of course) say that leaving one or another enabled isn't enough. You must tweak both to same state. <janneke>fosdem was awesome, some many people from all over the world <rekado_>the Hurd talk was also great, recommended! <rekado_>actually, both of them were great (the one in the Guile devroom and the other in the microkernels room) <jonsger>rekado_: where can I find the slides of the other presentations in the guile devroom? <davexunit>ooh I want that relocatable stuff that civodul and pjotr presented <janneke>in the future of guix panel all agreed we need `something like that' <davexunit>I want to use it for distributing games easily <davexunit>I have to make package variants of everything I want <davexunit>and compile the library without store references <davexunit>it's not a bad compromise to say that the user needs to unpack into $HOME/opt <janneke>something that works is great, as far as i'm concerned <davexunit>because it's up to the program interpreting the string to determine what "~" means <janneke>if it needs to be improved on, let's do so <rekado_>speaking of the fog-panel: we discussed some more concrete solutions to our patch situation at dinner. More details are to follow at a later point. This will need some exploratory work, but the goal is a little clearer and the path towards that goal seems to be not as steep as previously thought. <bavier`>omg, those who assert the autotools have a "difficult to comprehend architecture" as compared to cmake <janneke>bavier`: autotools need to be phased out and fixed <davexunit>autotools has plenty of bad, but cmake isn't an improvement <davexunit>the problem is that autotools has a crappy developer API, but it has the right philosophy and user interface <janneke>if you choose to use cmake, you are beyond any help <davexunit>'./configure && make && make install' is a great interface for users <davexunit>so a rewrite should just fix the developer api <bavier`>my current gripes are that I cannot adjust per-object compiler flags or run a unit test without reconfiguring the entire project <bavier`>well, part of the developer API is m4 and its quirks, so a rewrite would have to undo that <bavier`>providing a transition path would be nice too <davexunit>yeah I have no idea what the right implementation details are <janneke>i wonder about caching on the filesytem <janneke>and also about separating configure from make ***kelsoo3 is now known as kelsoo
<nliadm>I've somehow managed to get two different instances of the same version of 'file' into this environment <jmd>nliadm: It's not uncommon to have a native version and a target version of file in the build environment. <nliadm>I think something is propigating it and I'm also adding it explictly as an input <nliadm>I'm not sure which one is getting selected <nliadm>or why there are two different hashes <rekado>nliadm: you could try “guix graph” to see the dependency graph. <nliadm>will that work if I just have a package definition I've been using via '-l'? <rekado>“guix graph” expects a package name. I suppose it wouldn’t work right away in your case unless you made this a module and added it to GUIX_PACKAGE_PATH <adfeno>slyfox: Well... I also ask same question <slyfox>did you get the answer by chance? :) <adfeno>I'm not a expert on computers, nor developer, so I don't know how to look for this one. <slyfox>looks like guix really likes texinfo <slyfox>gc removes it all the time and next operation pulls it in <skaria>i have the nss-certs package installed and these env vars in my bashrc: http://ix.io/1SAZ - why am i still getting cert errors?