<francis7><davexunit> now I want to see an official GNU laptop: grub + libreboot + guixsd :) <francis7>btw, it surprises me that RMS isn't using guix. he uses trisquel at the moment <davexunit>francis7: rms probably isn't too keen on using an experimental distro <davexunit>I would love it if he used guix, but it's a big change and he's very set in the way he does his computing, it seems. <francis7>well they use fai at fsf to it makes sense <lfam>I think he must at least appreciate GuixSD, considering his interest in lisp. <Demosthenex>i didn't see on the about page, is guix infected with systemd too? <kori>infected... interesting wording <lfam>kori: Yeah, I agree. Some people really don't like systemd! <kori>lfam: I'm somewhat one of those but I'm not an extremist <lfam>kori: I like having some real service supervision built into the OS, and I really like the cgroups integration. Binary logs are a tradeoff. <kori>lfam: that's fine and I respect your opinion :) it's a good reason for using it <kori>if it works for you, more power to you! <lfam>kori: I'm no authority. I just find those things convenient. I get why people don't like it. <paroneayea>I might get lent some openstack resources to test out guixsd deployment temporarily <codemac>man packaging golang is going to be the end of me. <codemac>libgcc_s still is not propagated correctly, so anything using cgo breaks. <codemac>but luckily for silly me, I don't use cgo, so 1.5 is good enough now for personal usage (but not really releasable :/) <lfam>codemac: Is your current attempt available anywhere? I'd like to give a try since I would like to get Syncthing packaged. <lfam>Ah, that's come a long way since the last time I looked :) <xd1le>lfam: of course i'm not sure if that's current <xd1le>lfam: and also see the go.scm under build-system <lfam>export HOME="/homeless-shelter" ;) <xd1le>has RMS actually given an opinion on guix/guixsd? <xd1le>i know guixsd is fsf approved, but i'm not sure if RMS was a part of that. <efraim>on the gnu-software? mailing list in december 2012 he gave congratulations, from before there was a guix-devel mailinglist <xd1le>efraim: yeah the distribution and just the guix project in general <xd1le>omg i remember reading about what to name guixsd <xd1le>and people wanted to name it gsd and all that, sorry! <xd1le>wow i easily forgot all that <efraim>i wouldn't have known except I looked at it last week :) <rekado>how come hydra is rebuilding so many packages right now? There are no substitutes for python2-pip available for example. <efraim>don't know, doesn't look like anything was changed that would cause a big rebuild <piyo>hello how can add configure-flag "--enable-color256" to the guix recipe for GNU screen? (screen.scm) Do I copy screen.scm to my GUIX_PACKAGE_PATH and edit that copy? <taylan>piyo: yes, and probably change the name of the package <piyo>then after that do I type cd $GUIX_PACKAGE_PATH && guix package -f screen.scm ? <taylan>if using the -f argument, you can put it anywhere I think, needn't be in GUIX_PACKAGE_PATH <taylan>I've never used this feature so I may be off <piyo>i will rename screen.scm to screen-piyo256.scm and give guix package -i screen-piyo256 a try <taylan>oh and you want to change the name of the module too <taylan>e.g. (define-module (piyo screen) ...) <rekado>piyo: you can inherit from the "screen" package. <rekado>there is no need for a specific module. You could have a module containing all your overrides. <piyo>not (define-module (gnu screen-piyo256) ...)? <rekado>the module name is really up to you. <rekado>it only needs to match path and file name. <rekado>e.g. (my packages stuff) would have to be a file in $GUIX_PACKAGE_PATH/my/packages/stuff.scm <iyzsong>yeah, many ways. but I'd just edit the screen.scm (if using git checkout), and send a patch, because it sound will be useful for other too! <piyo>iyzsong: yeah, that would be good, but first i want to use guix like "stow" <rekado>(note that we do have a "stow" package in Guix ;)) <rekado>piyo: (define-public my/screen (package (inherit screen) ...)) <piyo>its symbolic links all the way down ... :-) ? <piyo>rekado: I know of the inherit concept, but I would like to take baby steps for some reason. <piyo>btw, I am running a "foreign distro", Debian testing + guix-0.9.0 on both x64 and armhf <rekado>piyo: with "inherit" you don't need to duplicate the whole recipe for screen. You're free to do that, of course, but with inherit it's much clearer for your future self to see why you did it. <rekado>I should say, though, that adding this configure flag to the "screen" recipe in Guix as iyzsong suggested is a good idea anyway. <piyo>Yeah ultimately I would like that as a default too. <piyo>Still, there must be a reason why it is "--enable-color256". <piyo>what is the "pastebin" for this channel? <piyo>ACTION sees my/packges/screen.scm in guix package -A screen ... :-) <piyo>Unfortunately, guix package -i screen picks up the default and not my $GUIX_PACKAGE_PATH/my/packages/screen.scm which has (define-module (my packages screen) ... ) <piyo>help? am I missing something? <davexunit>piyo: does it warn about an ambiguous package? <Demosthenex>ok, so the site's a bit light on detail. hurray that it isn't infected with systemd. i'm currently using ubuntu on my laptop, server edition with just a handful of X packages, no user crap. i'm seriously considering moving to freebsd because i'm sick of systemd and the duct taped together linux world. why might i consider guix? <roelj>I'm running 'guix lint <my-package>' and it crashes with: 'ERROR: unsupported URL mirror kind alpha.gnu.org ...' <davexunit>piyo: differentiate with a version number or naming the package differently <roelj>The url is specified as "mirror://alpha.gnu.org/..." <piyo>davexunit: hm this workaround is getting me somewhere... compilation is working etc. <mthl>roelj: there is no mirror for alpha I think <roelj>mthl: Should I then use 'http://' instead? <mthl>roelj: you can look at artanis or guix package since they use alpha.gnu.org <piyo>davexunit: The changes: Filename is now my/packages/screen-piyo256.scm, (define-module (my packages screen-piyo256) ...) (define-public screen-piyo256 (package (name "screen-piyo256") ...) ...) and it compiles with guix package -i screen-piyo256 <mthl>roelj: “ftp://alpha.gnu.org/gnu/...” <piyo>As a workaround I can live with this for now. <roelj>mthl: Thanks, artanis seems to use FTP. <davexunit>Demosthenex: there are similarities, yes, but hopefully it's clear that guix does much more. <rekado>piyo: the module name is not used on the command line. "guix package -i" expects a package name only. <rekado>there's a way to reference a variable directly, but I forgot how this would work with "guix package -i". <rekado>referencing a variable explicitly in guile is (@@ (the module name) variable-name) <rekado>but renaming the package variable/name is better anyway. <rekado>Demosthenex: guix is a very nice package manager. GuixSD is a system built around the package manager (because thanks to functional package management guix knows about dependencies all the way down to kernel headers and bootstrap binaries). <piyo>rekado: I don't understand those concepts yet. <rekado>piyo: it's not important. As you can see from my handwaving: neither do I ;) <piyo>rekado: I appreciate your enthusiasm tho. <davexunit>paroneayea: this talk is *really* good. best yet, I think. <piyo>my next question is using guix behind a http proxy... I found the workaround about injecting the http_proxy environment variable into guix-daemon. My question is, is there any downsides to using ~root/.guix-profile/bin/guix-daemon as the daemon to start? for example what happens when I do guix package -u guix as root? <davexunit>that upgrades the guix package in the root user's profile <piyo>I assume ~root/.guix-profile/bin/guix-daemon is updated as well? <davexunit>you can verify for yourself by reading the links <piyo>I am more concerned about the semantic change, is this a recommended upgrade procedure and at the same time a recommended guix-daemon running procedure? <davexunit>it's a typical way to manage guix on a foreign distro <davexunit>in guixsd, the global system config has the guix stuff. <piyo>So piyo user has say guix-0.x, and root had guix-0.x but after the above, now has guix-0.y. I should now restart the guix-daemon so that ~root can call guix-0.y correctly. I should now also guix package -u guix as piyo so that piyo uses the "right" guix-daemon? <davexunit>your piyo user account is connecting to whatever guix daemon is running, it doesn't run its own. <davexunit>so if the daemon you run is in root's profile, all you need to do is update guix in root's profile and restart the daemon. <davexunit>each user is free to user whichever version of guix they would like. <piyo>So as long as there is no breaking guix change from calling interface to root's guix-daemon from a user's guix tool, the above update procedure is correct? <davexunit>the guix daemon's API hasn't changed in all the time I've been using guix. <piyo>So to sum up, when auto-starting guix-daemon via my own shell script which will define http_proxy, I don't have to worry about breaking changes (knock on wood). Therefore I can start the guix-daemon using the path "~root/.guix-profile/bin/guix-daemon". <mark_weaver>piyo: everything guix-daemon needs and uses is in the immutable directories in /gnu/store. updating root's profile only changes one symlink, so it will not affect anything that the running daemon needs. <mark_weaver>(the daemon doesn't care about that symlink; it will only be used when you launch it via the path you gave) <piyo>yes mark_weaver but I was concerned about the situation where a newer .../bin/guix tool could not call a running guix-daemon because of a API change or otherwise. <mark_weaver>ah, I see. no, the guix-daemon API is very stable, as davexunit said. it's never been an issue in the years I've been using guix. <mark_weaver>I suspect a guix-daemon from two years ago would work with the current guix client <piyo>Since I am using guix-0.9.0 on Debian Jessie, my /etc/systemd/system/guix-daemon.service will call my http_proxy-defining shell script. I want to take advantage of my squid cache. <davexunit>a coworker of mine is interested in trying to port guix to powerpc <piyo>I use powerpc (MPC832) at work... I'm kinda interested to see if guix can work on sh4, actually. <piyo>There was a webpage about Guix which had a graph of all the packages need for bootstrapping, somehwere? <piyo>I dunno, I just conquered a "hello world" problem today. Bootstrapping should be next week. ;-) <davexunit>was hoping the new guix talk would get some traction on hn <piyo>I read all these stories today. <andreoss>the binary packages are not used by the default? <piyo>paroneayea: I'm at 15minutes now <rekado>andreoss: do you have an example? <rekado>the build farm hydra.gnu.org currently still has 180 packages in the master branch to build. <rekado>so it's possible that the package you want currently doesn't have a substitute on hydra. <andreoss>started deamon. guix package -i bash # downloads bunch of sources, gcc included <rekado>andreoss: hmm, substitutes for bash are available on all platforms. Are you using the latest version of guix? <andreoss>>substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <andreoss>how do i add a new profile for non-root user (on foreign distro)? <bavier>andreoss: just use `guix package' with the non-root user <bavier>the default profile is put in "~/.guix-profile" <alezost>andreoss: you can use --profile option: "guix package -i foo -p /tmp/p1" <andreoss>under root i have /root/.guix-profile/bin/guix <andreoss>basically how do i make initial .guix-profile for non-root user? <alezost>andreoss: just "guix package -i anything" <andreoss>LD_LIBRARY_PATH=/root/.guix-profile/lib LD_LIBRARY_PATH=/root/.guix-profile/guix .... <rekado>as a user you can do "guix pull" to get the latest version of guix. <rekado>there is no reason why guix should only be available for the root user. <andreoss>rekado: i don't have guix executable as a user <alezost>andreoss: did you use "Binary installation" method? <alezost>“Make the ‘guix’ command available to other users on the machine ...” <davexunit>andreoss: what I meant earlier is that substitutes from hydra.gnu.org are *not* enabled by default. <rekado>I'm confused about installing packages in R. <rekado>with Guix R I cannot install packages from the command line on a non-GuixSD system when the package builds a native library. <rekado>I guess it's because the built library is linked against the system glibc which clash with the glibc that Guix R is built against. <rekado>so I'd have to install gcc-toolchain and let R use that to build native stuff. <keverets>"guix pull" seems to be a much heavier process than "apt-get update"; I was used to doing an apt update daily... how often do people "guix pull"? <rekado>however, our gcc-toolchain package doesn't play nice with gfortran (they have lots of conflicts). <rekado>keverets: I do it never. I use a git checkout instead. <rekado>"guix pull" compiles all package modules (not the packages themselves) from scratch, and that takes time. <keverets>rekado: ah. The guix manual seems to recommend doing "guix pull" to get the latest software versions available (which then need to be installed by "guix package -u"). Perhaps a git checkout is lighter weight, but similar outcome? <python476>hello, question (duh), is guix available standalone ? (like nix) <davexunit>python476: yes, you can use guix on top of a foreign distro. <dmcp>hi guys! I did't use guix nor guix sd yet, but I saw some infos on the webiste and I liked very much! I'll install guix on my machine soon just to see it in action and I intend to install guixsd at least on a v.m. some day :) <dmcp>and I have a doubt about the way y'all work: your are all vonluteers? Or some of you are working full time on this project? <dmcp>I'm working on a (still) proprietary project but I'm convincing the partners to work on free software license and would like to know how some projects works how they are organized in general <bavier>dmcp: all volunteers as far as I know <bavier>do let us know what you think when you get a chance to give guix a testdrive <dmcp>cool! congratulations for the effort! how many time do you work per week in average? <dmcp>(if it's not ask too much :P) <andreoss>does guix utilize static linking in any sense? <efraim>wakatime has me at 10-15 hours a week, but some of that is spent staring at the screen while its compiling <python476>dmcp: I use base arch, I plan to try guix too <davexunit>nothing stops anyone from running build processes that do things differently, of course, but we prefer dynamic linking. <dmcp>cool python476! I like arch very much .. I just installed manjaro to give a try and I approved because it uses pacman and yaourt .. so it works just like arch in the end with an easier install <python476>I ran manjaro but it duplicates arch repository, well anyway, if you get guix running, write about it so I can copy you :) <davexunit>what I like about guix is that it has the thing I like about arch, mostly up-to-date packages, without the downsides. <davexunit>if bleeding edge software breaks my system, guix allows me to easily roll back. <efraim>python2-setuptools is what's causing a whole bunch of failures on hydra right now <efraim>I did some work on opam and smalltalk, but they still need more love <efraim>our opam is at 1.1.1, upstream is at 1.2.2, with some new dependencies <efraim>something happened in the beginning of june to make it stop building <efraim>its almost not worth fixing and just upgrading, but I don't know if I want to immerse myself that much in ocaml <andreoss>>eval-buffer: Cannot open load file: no such file or directory, magit-popup <andreoss>do i need some specific version of magit? <alezost>sneek: later tell andreoss: magit-popup comes with magit 2.1.0 or later <andreoss>/home/andreoss/.guix-profile/bin:/home/andreoss/.guix-profile/sbin <sneek>Welcome back andreoss, you have 1 message. <sneek>andreoss, alezost says: magit-popup comes with magit 2.1.0 or later <andreoss>alezost: somehow magit which comes from elpa (magit-2015) is not what guix.el needs, i've installed version from github and now it works <alezost>andreoss: magit from melpa is surely new enough <alezost>andreoss: I don't believe you :-) there is no 'magit-2015' version on melpa <alezost>andreoss: "magit-20150516.412" sounds like melpa; perhaps you just hadn't updated your packages for a long time <andreoss>probably it was some time ago, so it explains why the package didn't update ***dmcp_ is now known as dmcp
<alezost>andreoss: there is no magit on ELPA; so it's tromey apparently (I've never heard about it) ***dmcp is now known as doug
***doug is now known as dmcp
<alezost>andreoss: hostname is from inetutils; hexdump is from util-linux ***dmcp_ is now known as dmcp
<andreoss>seems that was missing ln -s /gnu/store/83i08dbrdka7l65nk7yb6zqk7hxiwrnc-xorg-server-1.16.4/bin/Xorg /gnu/store/f2xzvwvgvl1blyhxwpdr1l18mbfp8wgd-xinit-1.3.4/bin/X <davexunit>you didn't actually run that 'ln -s' command, did you? <lfam>It seems that nix is packaging the whole thing for python2, which screwed me up for a while (their python defaults to python2). <lfam>My major issue now is figuring out why the test phase of lets-encrypt can't find python2-pythondialog. That is driving me nuts. And there are a few dependent libraries that aren't building properly. <lfam>I rebased your big commit into a bunch of little commits. Lesson learned: I should have "duplicated" your big commit and then rebased the dupe. As it is, I broke history with you. <davexunit>"wip" branches are free to be rebased anytime <lfam>Cool. I don't have commit access anyways so it's not a big deal. <lfam>Weird, there is a pumpio.go in my local source tree. <lfam>Is pump.io secretly packaged? <lfam>Of course if I cp template.scm pumpio.scm then I won't see that pumpio.scm used to contain useful data ;) <lfam>Well I'm going to take a crack at pump.io <davexunit>and we haven't even begun to untangle the mess that is npm <lfam>Ah, I didn't realize that npm wasn't there yet. You are right, I am not interested in pushing that boulder up the mountain. <lfam>And I think you have a lot more experience and knowledge than me <lfam>What is the nature of the relationship between node.js and npm? <lfam>So when pump.io says that it's only dependencies are node.js, npm, graphicsmagick, and a db (I'd use redis, probably), they are papering over a whole mess of dependencies that would come through npm? <rekado>bleh, tbb fails on mips but the test failures are simply ignored. <davexunit>lfam: it's like saying your application depends on dpkg or yum <taylan>ugh, I really need to continue working on that propagated input checker