<glosh>um I can't find this in the manual but... <glosh>whenever I install it all goes into ... /root/.guix_profile and i can't get in there from the regular user <glosh>I mean I COULD export the PATH but I'd rather have guix install packages in the global environment <mark_weaver>sneek: later tell glosh: run "guix package -i" as your normal user, not root. <mark_weaver>sneek: later tell glosh: "guix package -i" installs the programs in the profile of whatever user ran that command <mark_weaver>sneek: later tell glosh: to install packages in the "global" environment, which is only possible in GuixSD, add them to the 'packages' field of your OS configuration and re-run "guix system reconfigure ..." <goglosh>welp I thing I got this thing running now <goglosh>ACTION sucessfully installed guixSD and got it running the way he likes it <sneek>Welcome back davexunit, you have 1 message. <sneek>davexunit, daviid says: I did not start to work on guild init yet, but will do, I have to get guile-clutter 1.12.2 our first <goglosh>what still bothers me is how I am going to put shebangs at the beginning of my files? <goglosh>even a symlink seems inappropiate when everything is on a local .guix_profile/ <mark_weaver>goglosh: I put /run/current-system/profile/bin/bash (or whatever) in the shebangs <mark_weaver>ultimately, the best solution would be to make it easy to import scripts into guix as real packages, and have guix rewrite the shebangs as part of that. <davexunit>seems to be the only way to write a portable script <goglosh>well one way could be, as I said, a symlink <davexunit>mark_weaver: you wouldn't want this for scripts managed with guix <davexunit>but how about a little script I kept in my home directory, or a script from someone else's git repo? <mark_weaver>goglosh: I'm not sure I understand your suggestion. where would the symlink be located, where would it point, and what would be in the shebang? <davexunit>I don't really think we should have a /usr directory, though. <mark_weaver>davexunit: we use software from people's git repos all the time. why is a simple script different? <goglosh>and put there a symlink to $(which bash) <goglosh>of course it won't work if you have several users <davexunit>mark_weaver: for my projects, I use autotools to generate the shebangs for scripts to refer to absolute file names of interpreters, but a lot of other people don't do that. <goglosh>or /root/.guix_profile/{path to env} and give it chmod a+x <davexunit>sometimes there's just a simple script hanging around somewhere, and I can't run it without modification. <davexunit>goglosh: well env is already part of coreutils <mark_weaver>davexunit: we could make a very easy way to import a single script as a package, which just rewrites the shebang and adds it to the store. <davexunit>perhaps a new guix command could make this easy <goglosh>I guess for my setup I can go by just making symlinks in /usr/bin tho <mark_weaver>that's the lazy solution, and it will mean sacrificing the reproducibility, reliability, and roll-back features of guix. <mark_weaver>and it will also mean that you may write a package for guix and it seems to work for you, and then you submit it to us and it doesn't work for anyone else because it depends on those links. <davexunit>er, I guess my command needs to include the interpreter, so maybe: guix script python ./foo.py <goglosh>but in such case it'd only affect me <mark_weaver>ours is not the easy road, but it has significant advantages <mark_weaver>but actually, this particular problem would not be hard to solve in a satisfactory way with very little work. <goglosh>anyway who's in charge for this project? <mark_weaver>goglosh: obviously you should do what you want with your own system. I'm sorry if I sometimes come off as overbearing. <goglosh>mark_weaver: no, you're kinda right, I mean, if I find I want to package, idk, stumpwm or vimb which aren't readily available <goglosh>installed xinit and xorg-server, what am I missing? <ArneBab_>sneek: later tell civodul: the reason for running setlocale in wisp is that it must use utf-8 and the default locale in guile can differ (which would throw off the parsing. As far as I know the alternative would be using fluids which would make the code harder to understand — at least for me). But I agree that it should handle errors gracefully instead of dieing. <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, ArneBab_ says: the reason for running setlocale in wisp is that it must use utf-8 and the default locale in guile can differ (which would throw off the parsing. As far as I know the alternative would be using fluids which would make the code harder to understand — at least for me). But I agree that it should handle errors gracefully instead of dieing. <hubot666>What is the best way to connect to a wpa2 wifi network from the guix usb installer? <civodul>unfortunately this is not very convenient <hubot666>Okay I am trying that now. Also is there a way to disable ipv6? <civodul>for IPv6, i think there's a knob in /sys or /proc <hubot666>civodul, Thanks. I've ended up getting wifi working. Now going to try and install with dm-crypt on an old eeepc 701 4g. <hubot666>It seems that there is no pvcreate lvcreate in guix to setup encrypted root. Or am I missing something? <rekado>for encrypted stuff you'll also need "cryptsetup" in the "cryptsetup" module. <hubot666>Cryptsetup seems to already be in the USB installer. I'll research lvm2. Thanks rekado <hubot666>My next stage. I need to put a /boot partition on sda1 and a / root partition on /dev/mapper/cryptvg. No swap <hubot666>I am looking at this paste for guidance: Does it look like a good template in my case? <hubot666>For clarity for those just joining I am trying to install guix with encrypted LVM on an eeepc 701. <hubot666>Oops. Correction. The root should be /dev/mapper/cryptvg-root. <civodul>hubot666: for an encrypted root you'll need a USB image created with current Git master <alezost>define-record-type† is a bit extravagant IMHO :-) <alezost>I mean '†', but I like the macro itself <davexunit>I'm unsure if that syntax is worth the price. <davexunit>civodul is very aware of the cost, given the comment in the source, but I just don't know... <davexunit>I like to be able to search the codebase and guarantee that I can find the definition point of a symbol. <davexunit>'define-record-type' already does an unhygienic definition of a GOOPS wrapper class. <davexunit>which is magic that you definitely don't expect to happen <civodul>yes it really costs me to add that macro <civodul>but really, i think we'll have to get over it ;-) <civodul>with the wip-service-refactor, we almost need one record type per daemon configuration <civodul>when wingo & i met samth a few years ago i told him that their 'struct' form is unhygienic, like define-record-type† <civodul>and samth said "yeah but that's a special situation" <davexunit>a record type per daemon feels wrong, but I don't yet have a concrete reason why. <civodul>we have config records for maybe a third of the services currently <civodul>OOP sounds like the ultimate insult on this channel ;-) <rekado>in Haskell having a new type for things is normal. I don't mind having one record type per service. <davexunit>I can foresee cases where a user who is trying to familiarize themselves with the code will search in vain for a procedure name they won't find in the source. <civodul>and a strong proponent of hygienic macros <civodul>well this sounds like argument by authority now ;-) <davexunit>well there are exceptions to most every rule. <civodul>in <package> we use lists for build-system arguments rather than objects <civodul>but this is mostly to save space since most objects have an empty argument list <civodul>otherwise there could be <gnu-build-system-settings> and so on ***y is now known as exio4
<davexunit>maybe I've misunderstood the purpose of "one record type per child" <davexunit>rekado: yeah, Haskell has a lot of types. I do not like Haskell. :) <davexunit>ACTION presents sacrificical offering to the Great Type Checker <rekado>davexunit: you can also have an Any type and do nasty stuff there. <rekado>but I must admit to being a worshipper of the great type checker. <rekado>(and I secretly wish for a Typed Guile variant) <rekado>ACTION shows himself to the door <taylanub>ACTION wonders how R6RS records would compare to Guix's ad-hoc implementation of record type subtyping... <davexunit>I can appreciate the compile-time guarantees that static types can give, but I'm not very interested in "static" things. <davexunit>of course Haskell is much more advanced, but this footnote from SICP still applies pretty well: "In Fortran or Basic, one typically combines data elements by assembling them into arrays—but one cannot form arrays whose elements are themselves arrays. Pascal and C admit structures whose elements are structures. However, this requires that the programmer manipulate pointers explicitly, and adhere to the restriction that each field of a <davexunit>structure can contain only elements of a prespecified form. Unlike Lisp with its pairs, these languages have no built-in general-purpose glue that makes it easy to manipulate compound data in a uniform way." <davexunit>tl;dr: Haskell programmers must "adhere to the restriction that each field of a structure can contain only elements of a prespecified form." <civodul>davexunit: another option would be to use alists for configuration <civodul>i don't think it would be much better though <davexunit>I think record types are fine for configuration. I think I got mixed up by what you were suggesting. <davexunit>I thought that there was going to be some sort of type hierarchy where each service is of a different type <rekado>(i.e. you could suspend type checking and do it at runtime, but you lose assurance from the compiler.) <rekado>ACTION stops talking about Haskell on #guix now. <davexunit>looking at that, it seems like a lot of added syntax and complexity for something that is trivial in Lisp. <davexunit>of course, static typing is non-trivial in Lisp. <davexunit>perhaps I'm just bitter because the functional programming community is being beaten over the head with the static typing stick lately. <davexunit>to the point that "functional programming" implies static typing to a lot of people. <civodul>i think we must show the kind of FP we can do with Scheme <civodul>sometimes borrowing ideas from static languages <civodul>sometimes coming up with different solutions <civodul>obviously each approach has problems that the other doesn't have <rekado>I actually really miss the reassuring nod of a compiler (that I get when I write correct Haskell code) when writing in Guile. I tend to make really stupid mistakes that manifest themselves as runtime errors. <davexunit>static typing greatly restricts how one writes programs, with the advantage that the compiler can check for things that it otherwise couldn't in a dynamic language, but how possible is it to do "REPL driven development" in Haskell? <davexunit>that reassuring nod comes at too high of a cost to me. <rekado>do you have a good example of REPL driven development? I usually just use the REPL to test little snippets. I never actually grow programmes in the REPL. <davexunit>there's a short video (though too slow-paced because I made it up on the fly) in which I grow a "game" at the REPL. <civodul>in the same vein, wingo did live web server hacking at FOSDEM a few years ago <civodul>the Smalltalk people are also very good at that <davexunit>I'd love to give a talk about Guile in which I write a well-known game clone at the REPL. <taylanub>REPL aside, something like Emacs might be a good example where dynamic-everything shines. though your static typed compiler could also refrain from using the static knowledge of other modules' contents to optimize the module currently being compiled, so that you avoid the need to recompile trees of modules when you want to make a change to a single one at run-time... <civodul>Emacs or operating systems in general <civodul>these are things where you want to dynamically compose things <davexunit>static languages can do "hot swapping", which is great... for people that aren't familiar with REPLs. <taylanub>davexunit: what is this hot swapping and how does it differ from what one can do with a REPL? BTW Haskell has a REPL IIRC; the question would be whether a REPL can be hooked into a big system and allow changing parts of the system from the REPL <davexunit>also, why is it that new dynamic functional languages like Elixir (http://elixir-lang.org/) can just show up and suddenly companies start using and hiring for Elixir programmers, while proven languages that have been around for decades don't get any love? <davexunit>Scheme is laughed at, and Elixir/Clojure/etc. is taken seriously. I just don't understand. <taylanub>(really I think the REPL per se is a red herring; e.g. in Emacs you don't need IELM (the Elisp REPL) to do your stuff; C-M-x and C-x C-e are interfaces one could say analogous to a REPL without being a REPL.) <davexunit>it's still using the REPL, even if you aren't at a prompt <davexunit>much like how Geiser still uses the REPL, even if you aren't at the prompt. <rekado>davexunit: thanks for the video. (Why is there no "sly" package in Guix? I want to write games!) <taylanub>hmm, in those two cases it could be that they leverage the popularity of the Erlang VM and JVM respectively... <davexunit>rekado: Sly is a meandering project with no official release. <davexunit>rekado: you can be sure that if/when I release it, a patch for Guix will arrive. <davexunit>rekado: Sly poses a lot of challenges given the constraints under which I've chosen, namely purely functional game logic. <rekado>I love FRP; I never liked the clunky frameworks in Haskell, though. <rekado>so having an FRP framework for Guile is just lovely. <rekado>(I actually played with elm for a while, because it was more fun than the many Haskell FRP thingies I tried.) <taylanub>davexunit: strictly speaking C-M-x etc. don't use a REPL AFAIK. I understand what you mean though. I just wouldn't use the term "REPL" to refer to the concept of inspection, replacing parts dynamically, etc., because then people will just point out that $language offers a REPL too somehow even if it's one that can't be jolted onto a full application in $language to make the application live <davexunit>game state is just a 'fold' over the previous state <taylanub>sadly it was just some amateur musings and I don't have anywhere near the skill to work on realizing the ideas proposed there. (still not after two years, though I might start speeding up my learning soon...) <paroneayea>gotta write a blogpost and email donors (sigh! so behind) but then I'm going to start on my Guix talk <davexunit>I had a meeting with some contractors that do "devops" stuff yesterday, and as we were discussing all this Chef stuff I wanted to ask "How about NixOps?" ;) <paroneayea>I think I'm going to try to also hammer out some nice demos for the guix talk today <davexunit>civodul's talks have several demos that you can pick through <davexunit>I'm curious what you come up with on that front <paroneayea>which means starting VMs with prebuilt system configurations for now <paroneayea>I might need to get my port forwarding patch working again <paroneayea>I also might want to see if I can get an nginx service written <davexunit>services are getting overhauled, so don't invest much time learning the current way. <davexunit>we've discovered many limitations and civodul has proposed a new implementation that overcomes them. <paroneayea>davexunit: I'm assuming that discussion is on-list? <davexunit>there's a branch as well that has the base services converted <davexunit>paroneayea: for your demo, and maybe this is too much, but I have an idea: <davexunit>one machine builds a system config with 'guix system build os.scm' <davexunit>a second machine uses the first machine for substitutes <davexunit>and runs 'guix system reconfigure the-same-os.scm' <davexunit>which effectively deploys the pre-built system on the remote machine <paroneayea>oh more games, MARS shooter... cool things today <davexunit>it's a far cry from the automated deployments we really want, but it does show how the system needs to be built but once. <davexunit>and the "image" i.e. closure can just be copied over the network to all the nodes of a cluster. <paroneayea>I've been playing a lot of freedoom with prboom lately <davexunit>I want to package Xonotic, but it's a tough one. <davexunit>fast-paced, Quake-style twitch shooters are a lot of fun, and Xonotic has the mechanics down. <paroneayea>too bad we don't have a counterstrike equivalent <paroneayea>there's one based on Cube/Saurbrauten but it sucks <paroneayea>which confuses me because it's based on the quake engine <paroneayea>ah, it's the "do mods for Quake have to be under the GPL discussion" <davexunit>I feel like the obvious answer is "yes", but I guess it's more nuanced than that. ;) <paroneayea>I think I heard bkuhn and karen reference this one? <paroneayea>this service refactoring could help my eventual Evil Plans (TM) for Guix a LOT <paroneayea>one of the problems I'd like to address is how there's shared configuration requirements between different processes on the system, and I thought a lot about this when I was sketching out opstimal <paroneayea>and how you'd want to be able to propagate what domain you're using to both nginx and mediagoblin, and you'd want mediagoblin's definition to be able to propagate the things it needs to share to set up nginx <paroneayea>basically, I don't want people to have to repeat themselves <paroneayea>especially not if I'm making a friendly GUI on top of all this <davexunit>I haven't looked closely at the new design, but it seems like it might enable that. <paroneayea>this is the very reason I got interested in learning how to write a DAG in the first place... <davexunit>the basic issue of differnt config files needing the same things is solvable via ordinary procedures <paroneayea>davexunit: yes, that's true, though once you get to the point where you're presenting the users with a bunch of options <paroneayea>and you need to resolve how that composes the configuration together... <paroneayea>if the users are writing the configurations in scheme themselves, sure <paroneayea>civodul: I am really excited about your service refactoring branch now! <paroneayea>davexunit: okay, so say I've presented you with a web UI to install various things... you pick mediagoblin, which requires both a MTA and a web server like apache/nginx <paroneayea>the user configures some of the MTA settings and etc <davexunit>but the underlying implementation would probably include procedures that generate service objects according to user settings <paroneayea>and they also set up mediagoblin to have the foosnarf plugin, which means that some special foosnarf assets need to be provided as well <davexunit>so I don't really see how it's all different, but then again I haven't thought much about this. <paroneayea>well maybe I'm wrong and overthinking things or not <davexunit>but perhaps this DAG structure will be useful <paroneayea>I thought a bunch about this a while ago and I was sure I needed it when I analyzed it then <paroneayea>and the thing civodul is proposing roughly approaches what I was looking for, it seems from first read? <davexunit>I've thought about similar things with regards to cluster management <davexunit>the web server needs to know the IP of the DB server <davexunit>I just don't understand all the new service stuff yet. need to do my homework. <davexunit>hopefully the design will apply to 'guix deploy' <paroneayea>in case that also gives you a better indication of what kinds of interface I'm also eventually building on top of Guix :) <civodul>i've been thinking about this as well <civodul>useful for FreedomBox-style use cases <civodul>ideally² the UI would be more transparent, to invite users to learn and hack the thing <civodul>as opposed to being limited by a fancy high-level GUI <paroneayea>civodul: I'm thinking the UI might be like blender <paroneayea>any tooltip you hover over shows you the python equivalent of that command :) <paroneayea>that kind of emacs-like self documenting behavior, but aiming the UI at someone who isn't a programmer <paroneayea>but giving them the entry point into becoming one <paroneayea>as such, Blender has turned many artists into coders, which I think is pretty cool! <davexunit>paroneayea: after reading your post, now things are more clear to me. I think the new service API will do what you want. <davexunit>things could offer up nginx vhost configs and the nginx service will gather them and generate the right config <davexunit>that's an immediately actionable change we can make to the nginx service once the refactor is done. <paroneayea>I was already going to explain in my talk about "the userops system I'm seeking" and why it lead me to guix as a platform for building that <paroneayea>now I can mention that one more piece is on its way towards that <zacts>mark_weaver: have any patches for Full Disk Encryption made it in yet? <davexunit>though I don't understand why GNOME is investing so much energy in their own package manager and IDE <davexunit>GNOME, you make it hard to approve of you sometimes. <civodul>it's not explicitly mentioned as such in the announcement <davexunit>and there's also WIP stuff that isn't in GNOME yet <civodul>oh, i didn't see the video in emacs-w3m :-) <davexunit>their experimental package manager is taking the "bundle everything" disk image approach of Docker, IIRC. <davexunit>civodul: "Firmware updates through Software" <civodul>i was like "hmm where's the package manager" <davexunit>oh yeah, they also have their own distro I guess... <mark_weaver>civodul: fwiw, I agree with davexunit about 'define-record-type†'. I'm not sure it's worth the cost of abandoning hygience and not being able to search the code base for a procedure like 'foo-bar' <zacts>civodul: what is the issue with LVM? <mark_weaver>civodul: I think I might prefer using alists to this. <mark_weaver>(might prefer it if you are defining so many record types that you feel compelled to abandon hygiene) <mark_weaver>I should also point out that, from the point of view of implementing the macro expander, supporting 'datum->syntax' causes many complications. <mark_weaver>I still don't know how to correctly support 'datum->syntax' with separate compilation without introducing non-determinism in the macro expander output. <mark_weaver>and, it has the effect of *greatly* bloating up the size of the expander output. <mark_weaver>I don't know how to avoid that either, with 'datum->syntax'. <civodul>we can always do without define-record-type† if it would avoid a riot :-) <civodul>now running 'guix system build desktop.tmpl' <zacts>davexunit: do you have a tutorial or guide on how you got notmuch configured with gnus? <zacts>so should the notmuch doc be enough to get me started with it? <zacts>or are there any quirks I should be aware of? <goglosh>anyone here knows where slim initially loads it's config files? <davexunit>goglosh: not sure, but the slim-service code should provide insight <civodul>davexunit: nginx has its *own* implementation of JS?! <civodul>another of those startup mysteries (to me) <civodul>i find it suprising that there can be a conference around nginx <civodul>in the old days i don't think there were conferences about Apache httpd for instance <davexunit>I thought you were talking about the config file :) <davexunit>yeah they have entire conferences around a single piece of software now <civodul>Build the Future of the Modern Tape Archive <civodul>"Dicover how to deliver your sites with tape archives." <civodul>maybe we could arrange with sirgazil and Sergey (tar maintainer) to prepare a fancy web page ;-) <rekado>re GNOME: I feel that GNOME is not as closely aligned with the GNU project as the name suggests. I wonder why that is. <civodul>basically it's a separate project with its own agenda and goals <civodul>it's largely backed by corporate interests too <rekado>maybe the project needs more GNU people. <mark_weaver>rekado: that would be great. to make progress on that goal, we'd first need to update the guile-gnome bindings to GNOME 3, but I think a further step would be needed: to write an interesting GNOME program in Guile, and have it both work very well and be written in such a nice way that the superiority of this approach would be apparent even to those averse to lisp syntax :) <rekado>I'd write a Guix frontend for GNOME; of course in Guile, not JavaScript. <daviid>rekado: you can already do that, sng guile-gnome 2.16.3 <rekado>we don't have a Guix package for that yet. <rekado>daviid: would you be willing to create a package? <daviid>mark_weaver: no need to wait for gnome 3 bindings, which I will get, 1 day... I'm slow now but there were some 'infrastructure' problems with our bindings, most are solved now <rekado>is there a way to write GTK applications in FRP style? <rekado>last time I looked at any toolkit it was all strictly imperative <daviid>and I beleive Kisê is a very good example, it is small, use glade... <daviid>rekado: won't build a package atm, no knowledge and no time, I'm working on our bindings and webpages for guile-clutter [as well] <mark_weaver>daviid: my suggestion was a response to the idea that it would be good to try to influence the GNOME people to use "more <mark_weaver>I don't think we'll have much luck convincing the GNOME people to use more Guile if we haven't even updated our bindings to GNOME 3. <daviid>mark_weaver: ah ok, that is going to be hard imo <daviid>ACTION still need to write a webpage note about how to use glade [which version we support] with guile-gnome <daviid>it's not because I wrote it, but it is the best example we have so far :) <daviid>rekado: you can see on screenshot it perfectly intergrtes in gnome 3, although it uses gtk2 still ... so you can start working on guixfe [frontend?] :) right now! I'll help you of course <davexunit>daviid: having guix package(s) for guile-gnome would be cool to help people get up and running more quickly. <davexunit>I'd like to try out guile-gnome, but I just don't have much time in which to try new things, so I prioritize other things. but guile-gnome is very important. <daviid>davexunit: thanks! It is very important yes. Wrt guix, I can't do it right now: I follow a strict plan of actions to get us out of the 'dark' wrt guile-gnome and guile-clutter, which is a 'titanic' work. I'm sure one of you guys will package guile-gnome and soon guile-clutter in a 'couple of clicks', if nobody beats me in a couple of months I'll do it, but don't hold your breath <daviid>yeah, can't be everywhere, I really woud like to develop and use guix, but, 24h in a day ... <daviid>and you're many, I'm alone :) I can't even hope to get simple and fast responses to my quizz, beleive me, this guile-gnome trip is 'amazonian': let's just hope I don't get 'Degue' in the way haha! <daviid>'Dengue' [a tropical mosquitow desease] <daviid>I bet paroneayea will package guile-gnome! He already wants to do it, time ... is the key for all of us <paroneayea>daviid: probably won't get around top packaging guile-gnome for a while if I do it, but who knows? <paroneayea>daviid: it does seem like an important project though <daviid>paroneayea: yes, very important: I'm a bit surprised nobody here picked it up to package it after I relesed 2.16.3 <daviid>it needs guile-cairo, guile-lib and g-wrap, so not a peice of cake either <daviid>you's first have to package these, then guile-gnome, and last guile-clutter <daviid>[ which I'm working on right now ] <daviid>also, guile-cairo must be build from source code, just to be complete in case someone is interested and read the backlog... <mark_weaver>and still many packages yet to build, even on x86_64 <civodul>indeed, i'll have to do a pass on those <mark_weaver>civodul: btw, I changed maxconcurrent to 4 for all 4 platforms, for now. <mark_weaver>for now, I think the total number of concurrent builds should be kept to 16 <mark_weaver>feel free to play more with those settings as you think best... <mark_weaver>ACTION looks into the emacs-dash build failure. magit depends on it. <mark_weaver>civodul: commit b7c7c03eb5e37fc3455e4e17b0898ffc4bca29c3 seems to have left 'package-name-version->elpa-name-version' in a very broken state <mark_weaver>(strip-store-file-name name-ver) appears twice in that procedure, but 'name-ver' doesn't include the store name. <mark_weaver>in one case, the result of that is bound to 'name', which is then unused. <mark_weaver>I'm not really sure what this procedure is supposed to be doing. <mark_weaver>ah, I see. before that commit, 'package-name-version->elpa-name-version' used 'store-directory->name-version' in a hacky way, making assumptions about how it did the job. <mark_weaver>it used to work by stripping everything up to (and including) the first '-' in the string. <mark_weaver>and so 'package-name-version->elpa-name-version' then used it in other cases where it wanted to strip everything up to the first '-'.