<aminb>civodul: ha, i was thinking of GuixOS (so we'd have Guix and GuixOS like Nix and NixOS) but not sure how different that'd be <aminb>re guix.gnu.org, i see. i *might* be able to help with that if there's more concrete info on what it is exactly we're looking to have <aminb>(if not me, certainly someone else) <aminb>civodul: also, out of curiosity, do you know whether or not anyone from the project owns guix.org? <civodul>aminb: thanks for the offer, hopefully others can comment on the web site issue <civodul>aminb: guix.org seems to be squatted by someone, dunno <civodul>i'd prefer to keep guix.gnu.org as the primary thing, with other domains redirecting to it <aminb>no problems :) in that case i'll keep an eye on guix-devel to see if anything comes up regarding website. i might chime in with the offer <aminb>yeah i think i'd prefer guix.gnu.org too <aminb>i should probably reply on the ML with a gist of what i said here (e.g. about the website setup, the GuixSD name, ...) <civodul>well, the name is not the most important item ;-) <aminb>but might as well bring it up, just in case anyone else wants to chime in <snape>ACTION did a typo in a commit message :'( <mange>The phases are quoted, and are evaluated elsewhere. You need to unquote references that don't exist in the build environment. You can use , to do so (so ,elogind-hook-script in the format call). You can see the same thing has been done with phases as the first argument to modify-phases. <pkill9>yess my elogind sleep hook worked <Dedalo>Hi guys, I'm new to Guix and GuixSD in particular. I didn't install it, but I'm trying to understand the difference with NixOS (and Nix). I have a lot of question but I would start three in particular: 1) I'm switching from macOS and I will need some proprietary software like Skype, Spotify, etc. Can I install this software on GuixSD. If yes, how? 2) I will need (since I'm a dev) to install stuff from source, using make && <Dedalo> make install. Is that something that I can do, out of the box? 3) I will install the distro on a Lenovo X1 Carbon, and I'm worried about the kernel drivers. What do you suggest? <mange>I think the main differences between Guix and Nix are that Guix is fundamentally a free software distribution, and that it uses Guile Scheme to define packages instead of the Nix language. There are other differences, but I think they're the big ones. <mange>That means for your first question: you can run proprietary software like Skype/Spotify/etc., but it's not necessarily straightforward, and there is no official support for doing so, and support should not be sought through official channels. <mange>For your second question, the preferred way to install things in Guix is from source! The distribution is made up of packages which specify how to build packages from source. You may find that you would rather write a package definition (which will call make && make install) to have Guix manage your installation (allowing for easy rollbacks, dependency isolation, etc.). <mange>For the third question: Guix doesn't officially support running a non-free Linux with binary drivers. It is possible to run a non-free kernel, but it is not documented or encouraged. I don't know whether that computer would work with the Linux-libre kernel that is the default in GuixSD. <Dedalo>In relation to your second answer, I think is cool that I can create a package. The main drive to use one of these distros is that they support rollback and many version of the same packages. But what about the fact that both GuixSD and NixOS don't use FHS but they have their own hierarchy? Is this going to be a problem? I'm thinking especially to the packages that are using hard paths, which is not a good practise but <Dedalo>In relation to your third answer (and the first one as well) my question is: ok, it's not officially supported and I shouldn't ask on the official channels, but is that something easy or not? I have seen a screenshot of a guy running GuixSD on a Mac, so I'm sure is possible. :-) <mange>It does pose some problems for some things. Usually if you're compiling from source things are okay, and you can patch the source to fix assumptions about paths. For pre-compiled binaries it's much more of a problem. <mange>GuixSD makes writing a new kernel definition quite easy. <Dedalo>Thank you, one last question for tonight, then I will leave you alone. :-) Which is, in your opinion the advantage of GuixSD over NixOS? <mange>GuixSD's service composition model for assembling a system makes more sense to me than the NixOS mechanism of changing settings in one big system settings object. I remember being really confused about NixOS and how I would add my own settings, whereas in GuixSD it was quite easy for me to work out. <mange>I also think Guix just feels more approachable, and flexible. All the power of Guix is available to me as a Guile Scheme library, so I can do a lot of things with that. <mange>For example, I used to generate my Emacs configuration by getting Guix to query elpa/melpa to pull down recipes for my Emacs packages, then it would assemble a Guix profile containing all of the packages that I wanted, at their most recent version. I could only do that because all the pieces were exposed in Guile. <jackhill>+1 for the whole OS being embedded in Guile. That's pretty big for me. <Dedalo>So you can basically write a bunch of scheme files and have a system that can be completely initialised from that file, more or less like you do with a Dockerfile to create a container? <Digit>i wish guix documentation came in pill form... so i could just swallow a pill, and know all of guix. #lazylearner <mange>Dedalo: Similar, but different. You can write arbitrary code, but the end result is a declarative configuration. Dockerfiles are a series of instructions to get the machine into the right state, but with Guix/Nix you're creating a specification, and then the Guix/Nix internals put the system into that state. <mange>My Emacs configuration thing would check elpa/melpa, but then what it actually put together was a list of Emacs packages and versions which Guix would then instantiate in my ~/.guix-profile/ directory to create an Emacs with all the packages that I use. It was pretty cool being able to do that. <iqubic>How hard is it to switch from NixOS to GuixOS? <brendyn>not very i guess. you could install guix ontop of nixos, and then reconfigure to make it in to a guixsd system <iqubic>But would that remove all the nix depedencies? <iqubic>Oh, wait, the distro is called GuixSD, and not GuixOS? <mange>I'd say about as difficult as switching from Mint to Debian. <iqubic>Would you guys recommend that I switch? <mange>You're asking in the #guix channel, so with no other context, of course! But I'm sure there are factors that weigh into that decision for you that we don't know. <iqubic>The main reason I want to switch is because I prefer to Guile over the Nix expression language when configuring software <mange>It might be worth trying it in a VM before installing it on bare metal. <iqubic>mange: That's what people told me about NixOS. I didn't listen to them. I jumped in cold turky. <brendyn>It would not delete the /nix directory <brendyn>i think it'll just insert the directories it needs but wont actively delete anything. it will need to put stuff in /etc too i guess <iqubic>brendyn: Yeah, and I'd still have to use nix for main system configuration stuff too. <brendyn>although i dont know how to use it much, i use firefox from it <brendyn>we haven't packaged firefox yet because it's difficult <brendyn>mostly free. we use icecat instead which patches a bunch of stuff. <brendyn>firefox is difficult because of the inclusion of Rust. we have to find a solution for packaging rust programs. I don't know much about it, but I think the sources contain hashes which we have to recompute because we also need to modify hashbangs <mange>Icecat is based on Firefox 52, which is close to being unsupported from what I understand. There's a thread on guix-devel about it at the moment. <iqubic>Do you have a good system for packaging programs in other languages? <brendyn>Guix has build systems which you will find interesting to read about <brendyn>for example gnu-build-system contains all the code to setup a package and do the typical ./configure; make; make install etc <brendyn>cmake-build-system is loads in gnu-build-system and modifies it to use cmake as well, etc <brendyn>there is even a font-build-system for automating the typical routine tasks of unpacking and installing font files. <iqubic>brendyn: All of the things you just described are possible to do in Nix too. <mange>Yep, you'll find that Nix and Guix are fairly similar in many capabilities. Which makes sense, given their shared history. <iqubic>You know, I don't think I need to switch. <iqubic>If I switch I'd be spending a few months learning a new syntax just to be able to do everything I can already do with Nix. <iqubic>It would be a step backwards for me, not a step forward as I initially thought. <mange>I think the main distinguishing things are: the implementation language, using the full power of Guile Scheme instead of the Nix language; and the system configuration style, using service composition rather than Nix's system object approach. <brendyn>I just started with guix and never really touched nix so I don't know too much about the differences <mange>The reason I suggested using a VM would be to see whether you liked the feel of Guix more than Nix. I found that Guix made a bit more sense to me than Nix, so I decided to use it instead of Nix. <iqubic>And why did you call Nix's method <iqubic>What do you mean when you say Nix has an object approach? <mange>In Nix you have one big "system" object, which you set values and flags on. So to enable awesome as your window manager you set a particular value in a sub-object, and that might result in some other values getting modified elsewhere (and so on until it reaches a fixpoint). At least, that's it from memory. <mange>Whereas in Guix you specify service objects, each of which can act on the system in some way. <mange>And services can also invoke other services. <mange>It has nicer composition semantics (no need to loop until a fixpoint), and it means that you can have a better idea of how much a given service affects the system. <mange>Because a service has to pre-register the ways that it can modify the operating-system object. <mange>Whereas in Nix, it's a lot more free form. <iqubic>How about specifying what packages you want on your system? <mange>You can add packages into the "package" field on an operating-system, or install them to a user profile, or keep them in a separate profile/environment. <iqubic>Is there like one main file that Guix reads to figure out what system configuration. <mange>The options are fairly similar to Nix. <iqubic>Those three options you just specified are available on Nix too. <mange>When you run "guix system init" or "guix system reconfigure" you provide a file that Guix evaluates. That file should return an operating-system object which specifies the desired operating system. <mange>Yeah, again, Nix and Guix have very similar capabilities. <mange>They are two very close points in the design space, that are very far away from all the other ways of doing package management. <iqubic>What if I want to do coding in a particular langauge, like say... Python. How easy would it be to manage python libraries? <mange>Guix isn't revolutionary over Nix, it's just a bit different. <iqubic>Does it have a good way to manage libraries for when I do coding tasks? <mange>Running "guix environment --ad-hoc python python-flask" will drop you into a shell with python 3 and flask, ready to go. <mange>If you want them to always be available, just run "guix package -i python python-flask" instead, and you can run them in any shell you open. <mange>The story for other languages/environments is very similar. <iqubic>Can I create a file that describes the environment I want for a specific project and pass that to guix environment? <mange>Yep, in two different ways. You can write a package definition for the project that tells Guix how to build it, then run "guix environment -f my-package.scm" to get into a shell, ready to build it. <iqubic>brendyn: What do you want to do with inherit? <mange>Or you can write a manifest, and create a local profile for it using "guix package --profile=my-profile --manifest=project-dependencies.scm", then source it into your shell with ". my-profile/etc/profile". <iqubic>brendyn: What do you think inherit would do in Nix? <iqubic>let's make sure we are talking about the same thing here. <mange>Anyway, I need to go AFK for a bit, so I'm going to stop responding now. I think Guix is really worthwhile, but it is differnet to Nix. I would advise you to try it out in a VM to see whether you like it or not. <brendyn>like if you want to package two versions of linux, you can just inherit the main one, change the version number and hash <brendyn>there are many packages defined that way in guix <mange>You won't necessarily be able to do much "new" stuff with Guix, but you might enjoy the way you can do it in Guix. Exposing the full power of Guix as a Guile library is something we haven't even touched on, but that is really useful, too. <iqubic>Oh, I'm not sure if you can do that in Nix. I was thinking about the keyword nix has called "inherit" <iqubic>Which is something else entirely different. <brendyn>i think i saw something like overwridederivation <iqubic>Alright, I think I'm going to stick with NixOS. <mange>Not a customer, but a potential user. That's okay, though. They were happy with Nix, so that's good for them! <mange>Guix is awesome, but it's not the answer to every problem and situation. :) <brendyn>I'm hoping it will become the main package manager that gnu/linux distros will use to create their own distros <brendyn>like how debian is used as a base for many distros <brendyn>to do that it needs to be able to handle basically any situation <efraim>almost 6 hours for the monero test suite on my fast aarch64 box ***Gamayun_ is now known as Gamayun
<g_bor[m]>snape: Did you follow the discussion regarding creating a stable branch? <snape>hi g_bor[m]! Yes I've seen that it involved ad-hoc Cuirass support <g_bor[m]>snape: yes, i've also seen that. Do you think we can make this more generic? Does it worth? <vagrantc>i'm struggling to create a new arm-trusted-firmware- variant, but it builds and installs a 4GB file, mostly padded with zeros that isn't actually needed ... i'm trying to figure out where to insert a (delete-file "...") <efraim>that would be a massive firmware file <vagrantc>if you use (modify-phases %standard-phases) with something which has inherrited from another definition... will %standard-phases include the inherited phases, or will it reset it to the default %standard-phases and then modify that <efraim>%standard-phases doesn't include the inherited phases <vagrantc>i know i've done this before, but i don't have access to that machine with me <efraim>you'll want to look for substitute-keyword-arguments <efraim>(arguments (substitute-keyword-arguments (package-arguments foo) ((#:phases phases) (modify-phases ,phases <efraim>I think its ((#:phases , and I think i left out a back tick <efraim>yeah, ((#:phases and `(modify-phases ,phases <rekado>snape: I could deploy the new cuirass. Do I need to take special precautions? <snape>rekado: I don't think so, there is no database change <snape>maybe you'll want to have a look <snape>it's a bit unconsistent because / points to Cuirass while /index.html doesn't <snape>I just didn't know what the route should be for that index.html file <g_bor>rekado: it seems to me that switching ant to ant/java8 broke antlr3. I will have a look at that later. <snape>g_bor, I think it would be worth it, although I don't know how to implement that yet <g_bor>I only have this locally yet, but I will soon push a new wip-java8 with the ant changes. <snape>Cuirass would need write access to savannah <g_bor>Or maybe we could separate repository handling, and make cuirass use a local one? <snape>Actually, it would be better that the savannah write operation is done by an external script, that would be called by Cuirass <g_bor>Actually it does not even have to be called by cuirass. <snape>when it detects that the 'master' packages are a superset of the 'stable' packages <g_bor>I mean to have a local copy of the repository on the machine running cuirass, and write to that. Then we can allow cuirass to write there, and an external service could watch this for writes, adn push to savannah when a change occurs? <snape>yes, but calling a script is easier than pushing a branch <snape>(and handling a local repo etc...) <g_bor>snape: I have came across a notice in the web writeup by Danny. It goes like whenever a new change is pushed an evaluation starts, assuming certain conditions met. <snape>rekado: maybe we could merge index.html with Cuirass' '/' route <g_bor>This seems like a generic pattern: When something happens, and certain conditions met, make something else happen. Do we have somthing like this in cuirass? <snape>by allowing to add an "html" field in the Cuirass config <snape>g_bor: right now, Cuirass 'git pulls' all inputs of all specs every n seconds, and whenever an input's HEAD commit has changed, it re-evaluates the corresponding specification. <snape>This happens before the jobs are built, so it's probably not the good place to add such a hook <g_bor>snape: This seems to be a very special case of what I described. Would it worth to have a more generic approach, or we should keep adding things ad-hoc? <snape>g_bor: I see what you mean. But finding the correct abstraction isn't easy :-) <g_bor>snape: Yes, you are right. It would worth to check the functions needed, and see if they fit the proposed abstraction. <snape>Actually, when BUILD-PACKAGES returns, it means the jobs are built. So we could add a hook there. <g_bor[m]>snape: I think it is a very good place to add a hook. If we can trigger a hook when a jobs are built, that would be also nice for other purposes. <g_bor[m]>vagrantc: I think you are missing a name. <vagrantc>ACTION thought make-arm-trusted-firmware set that <vagrantc>(define* (make-arm-trusted-firmware platform #:optional (arch "aarch64")) <vagrantc> (name (string-append "arm-trusted-firmware-" platform)) <g_bor[m]>vagrantc: You might be right, haven't tried that. <vagrantc>i don't know why i'm even working on this platform; can't test it for a couple more weeks at best <g_bor[m]>vagrantc: also, does it find the next package? <efraim>i'd go with name, 'guix package' finds packages by name, otherwise you need '-e' <vagrantc>easy enought to just add it ... seems the other ones do <vagrantc>g_bor[m]: it doesn't find the next package <g_bor[m]>vagrantc: most of the time it is caused by something is not properly closed. I will have a closer look. <g_bor>vagrantc: ok, first observation: seems to work without the arguments. <g_bor>I will have a look at that next. <vagrantc>g_bor: i've gotta head out for now, but thaks for taking a look at it! :) <g_bor>sneek: later tell vagrantc: It seems that you are missing a closing parenthesis after ((#:phases phases , but it was balanced at the end, causing no immediate syntax error, but leaving the syntax form open. I've sent you a mail with the correct patch. (Please notice that I did not build it, did not check the copyright lines, and did not made the modification to the ovmf package). <rekado>snape: what do you mean by merging “index.html” and “/”? What customization do you have in mind? <snape>rekado: you would pass a (local-file "index.html") to the Shepherd Cuirass configuration, and it would add it to the '/' page <snape>so that one can add custom html to that page <rekado>ACTION runs “guix pull” on berlin <rekado>snape: I see. Sounds like a good idea. Maybe even support an SXML expression as the hpcguix-web service does. <rekado>I reconfigured berlin, but I still need to change nginx to forward requests to localhost:8081. <snape>you just need to stop nginx and reconfigure <g_bor>rekado: Do you have any idea how updating ant can break atlr3-bootstrap? <rekado>snape: ah, right, the maintenance repo. <g_bor>yes, I do. Actually two errors. Will have a look in a minute. <g_bor>rekado: I get: panic cannot find importVocab file 'ANTRLTokeTypes.txt'. Then a backtrace telling that antlr exited with exit code 1. Arguments were: "-o org/antlr/tool" "org/antlr/tool/serialize.g". <g_bor>This is antlr3-bootstrap@3.5.2. It builds fine on master, and also on staging where we already use icedtea-8 as icedtea. <rekado>does the file exist (use “guix build -K”)? Can you reproduce this outside of the build container? <rekado>snape: the Cuirass web interface is now available on berlin.guixsd.org (I removed the index.html for now) <efraim>is there a quick way to check if a specific gnu project requires copyright assignment? <g_bor>rekado: It seems that the file really does not exists. <rekado>g_bor: could you share the complete build log? <g_bor>I will, but first I will have a look if I can reproduce outside the build container. <brendyn>I don't really understand what the interface does. it just shows some job numbers and timestamps <g_bor>rekado: when I run the last command in the kept tree in an environment and sourcing environment-variables I get exactly the same error. <rekado>g_bor: good. Can you figure out how this file should be created? Can you find its name in the build.xml or similar? <g_bor>Also, how should I share the build log? <g_bor>I have a crazy idea, I will try it :) <g_bor>ok, I will return to that. So far it is not working. <snape>brendyn: it's still basic, but it gives you an idea of the build status <snape>g_bor: FYI when you reply to emails, you add '>' before each lines, so your reply appears as quoted stuff <snape>rekado: it shows that Berlin can't keep up, doesn't it? <snape>it seems to build only 30% of the jobs at each evaluation <rekado>on problem we had was that texlive would not be built because of a bug in Guix. <rekado>but I don’t know why all of the past evaluations are like that. <rekado>it would be helpful to see if the scheduled but not executed jobs have anything in common. <rekado>it’s certainly not for lack of build nodes. We have a lot of nodes. <rekado>I’d also like to see a plot of node utilisation. <roptat>I'm working again on some new java packages that will be required if we want a maven-build-system that actually builds something <roptat>I'm on a branch of the maven-plugin-plugin dependency tree, which itself is required to build plugins that maven can recognise <roptat>and if there is a free implementation <rekado>roptat: Wikipedia says its a proprietary JVM. Why would we need it if we already have OpenJDK <roptat>it seems to be a dependency, but I could remove the dependent file <sailor_cat>but sometimes you need exact JVM and exact version of exact JVM to work with <roptat>the file in question is org/aspectj/weaver/loadtime/JRockitAgent.java <roptat>it looks like a runtime thing you only need when running on JRockit though, so removing the file feels safe <snape>rekado: it looks like when you restart Cuirass, it tries to build ~300000 derivations. <snape>that's a lot. Maybe we should discard the old ones, so that it can focus on the recent ones <snape>rekado: it may be building the same software 20 times too <snape>and that's actually a problem, because it's inherently inefficient <rekado>snape: how come it’s building the same software 20 times? <snape>say libreoffice failed at evaluationi 1,2,3,4 and you restart cuirass <snape>it will try, at the same time, to build those 4 derivations <snape>that means 4 libreoffice builds in the same time... <rekado>do we not invalidate derivations of older evaluations? <snape>could you give me a copy of the database? <rekado>it’s 463MB; I could copy it somewhere. <roptat>spring-framework-aop -> jamonapi -> spring-framework-context -> spring-framework-aop <snape>rekado: I can't find any code that would invalidate derivations <snape>except that CANCEL-OLD-BUILDS function... that isn't called :-) <snape>that's kind of a proof that it wasn't marked as "stale" <snape>evaluation 1 is from 4 days ago, so I guess the database was reset then. Imagine with one month history <efraim>I found a typo in a manpage for parallel, I'm almost 3 hours into proofreading all their *.pod files <efraim>I'd better not dream about 'filename' vs 'file name' and 'Perl' vs 'perl' <brendyn>efraim: do you change file name to filename or filename to file name? <efraim>'git grep -i -c' of them both shows filename is more prevelant <Hydro>Hello ! New to GuixSD... just did a "guix system reconfigure..." but it failed near the end, trying to [re]install Grub, cause had I forgoten to mount /boot/efi. Now, i could try to re-install Grub manually, but it is unclear to me, yet, how this could affect "generations" and this kind of "guixy" things ?! <brendyn>cant you just run reconfigure again after mounting it? <Hydro>sure... it's just... it takes time and appears to download lots of things i allready have... but i could of course <Hydro>k, ill try to do that and do some reading after that, to get a better understanding of guix. Thanks Brendyn <cryptocat1094>In GuixSD, how do service updates work? Are the programs running as services considered to be running from root's profile? <rekado>in the configuration of the services the package used at runtime can be specified. <cryptocat1094>So there's no `guix package -u` like updating? What about security updates? Does that mean you should periodically run `system-reconfigure` so grafts are pulled in? <rekado>to update the system you need to reconfigure. <brendyn>The root user just has a profile like every other user <kballou>I'm trying to build an updated package definition, but I get `guix build: error: #<unspecified>: not something we can build`. Is there a way to get more information about this? <cryptocat1094>Is there such a thing as `--delete-generations` for `guix system` and `guix pull`? <brendyn>You'll have to show exactly what you've done that resulted in that error <brendyn>--delete-generations for system profiles is a feature on the TODO list to be done before 1.0 <kballou>brendyn: I think I will move it to the mailing list then... <brendyn>not sure about guix pull. guix pull was also revamped recently and still has more work to be done, so it might not have it either <brendyn>Is there a way I can close a bug I opened? <brendyn>I'm a novice hacker and I've got nearly 40 patches in <rekado>kballou: how do you build the package? I’m guessing that you use “guix build -f”. <brendyn>cryptocat1094: The easiest way to contribute is by updating and adding new packages <rekado>brendyn: you can close a bug by sending email to <number>-done@debbugs.gnu.org <brendyn>cryptocat1094: try setting up guix, and then finding a program you want but isnt already in and then package it. ask for help in this channel when you are stuck, then email the patch to guix-patches@gnu.org <kballou>rekado: correct, I'm using `guix build -f gnu/packages/admin.scm anisble`. I'm trying to update ansible to 2.5.7... I may be doing something incorrectly. I'm drafting an email with the patch details. <rekado>kballou: that’s not how “guix build -f” should be used. <rekado>kballou: the file that you pass to “guix build -f” must end with a package value. <rekado>if you are working on a git checkout simply run “guix build ansible” <rekado>sorry, ./pre-inst-env guix build ansible <rekado>“pre-inst-env” lets Guix use the (modified) modules in the git checkout. <cryptocat1094>brendyn: I very well might. Guix is one of the few distros that seem to be getting anywhere with reproducible builds. <kballou>rekado: I'm trying the `./pre-inst-env ...` now, I get a lot of notes about newer source files than what is compiled, but that's to be expected though, yeah? <brendyn>cryptocat1094: It's very much a community effort. Guix just has a much better design that facilitates reproducible builds <brendyn>I think you're right to say Guix, not GuixSD <mbakke>kballou: You can compile the source files by typing "make". Add -j <number-of-cores> to speed things up. <mbakke>That will make evaluation much faster, and get rid of the warning. <kballou>mbakke: but that's only compiling the local source tree? Why is guix checking against the compiled files on the system installed version of guix? is it a search path thing? <mbakke>Yes, I think it's a search path thing indeed. <kballou>rekado: that seems to be it, it looks like it's building correctly in the `./pre-inst-env`. ~However, I still don't understand why what I was doing was wrong?~ Oh, I see. `--file` doesn't mean what I thought. Thank you for the clarification. <kballou>snape: I've killed my system with `-j`... compiling the Linux kernel with `make -j` brought a 2 core machine to a load average of about 90 before I killed it. <snape>it shouldn't. '-j' takes the number of cores <kballou>I know, that's why I was so confused... Out of habit, I usually always specify a number now :| <kballou>some man page reading become enlightening? I'm curious now... <snape>with '-j' there is no limit on the number of job slots <snape>kballou, are you using emacs? <kballou>snape: yeah, I was just deep in some other info page, so `m, make` wasn't working... <kballou>I'm not an expert of the info system <snape>to get back to the first page <snape>I find it way quicker to get info there than on a browser <kballou>yeah, now I need to figure out why my guix info pages are all in French... <snape>a well-known bug, actually :-) <snape>yes. It forced all Guix users to learn French, and then there was no good reason to switch back <snape>but as a workaround, you can do: C-u C-h i <kballou>I've been looking for that command for a while... ugh <cryptocat1094>> It forced all Guix users to learn French, and then there was no good reason to switch back | lol <iqubic>How hard is it to install GuixSD in a VM? <snape>iqubic: GuixSD doesn't support systemd-boot <snape>If systemd-boot doesn't depend on systemd, it could very well be supported by GuixSD if someone ports it <snape>but it's a bit weird that it's called systemd-boot if it doesn't depend on systemd <pkill9>how do you typically run a guix service as a user? <pkill9>basically any daemon you would run as a user <cryptocat1094>I think pkill9 means to use their service much in the same way qemu can be made to run as an arbitrary user ('qemu' by convention) rather than root. <cbaines>I think some people use the shepherd to run services as their user, but I haven't heard of anyone using Guix services directly for this purpose <iqubic>What is the right way to install GuixSD in a VM? <cryptocat1094>iqubic: Whichever you feel like. The provided image works, but you can just as well install it from ISO (I've done so) <iqubic>but should I use virtualbox or not? <iqubic>Isn't there some stigma around non-free software? <cryptocat1094>Ah, you can use any virtualization driver you want. I would recommend Qemu/KVM or Xen before VirtualBox as the latter is partly non-free. <snape>pkill9: there was a work in progress about user services a year ago or so <cryptocat1094>snape: That would be daemons running as some arbitrary user, right? <snape>user services are services that are managed by the user :-) <cryptocat1094>Oh right. I heard of it from systemd... and I guess have been using it via display-managers. <amz31>Land of reproducible science/software/bugs, hello :] <snape>Shepherd run as user would do the job, what's missing is GuixSD integration if I understand clearly ***d1rewolf_ is now known as d1rewolf
<amz31>some knows the reproducible channel exact name on freenode? <g_bor[m]>snape: I've read your message. Do you see this in all of my e-mails? Or only in a specific one? <snape>amz31: #reproducible-builds channel on irc.oftc.net. <rekado>iqubic: re VMs, you can also build a VM image for GuixSD from plain Guix. <efraim>There's also #bootstrappable on freenode <rekado>iqubic: that feature is available via “guix system”. <amz31>I am very excited to see how it's done :] <rekado>iqubic: that’s fine. You can install Guix on NixOS. <amz31>will 'guix init' on another distro be supported in 1.0.0? <snape>g_bor[m]: your emails from 02:14:25 and 08:04:56 CEST <snape>02:14:25 pm and 08:04:56 am CEST <g_bor[m]>I've seen something strange. Guix modular failed on i686 on berlin... <snape>g_bor[m]: it may be the guile bug <g_bor[m]>snape: ok, I've checked those mails. You are right. <g_bor[m]>Actually I did not notice this as my mail client shows me a nice vertical line. <snape>Yes, the text part is buggy, but not the html part it seems <g_bor[m]>snape: I've noticed that some java packages are broken on architectures I don't have at hand. Can I somehow test a package for another architecture as the build machine? <efraim>Do you need an actual i686 or would --system=i686-linux work well enough? <snape>g_bor[m]: x86_64-linux systems can emulate i686-linux, as said efraim with the -s/--system option to 'guix build' <snape>but it won'd work with other systems <g_bor[m]>snape: ok, thanks. The I will be able to check that one at least. <snape>ah yes, but it will be slow :-) <pkill9>is the guile bug possibly the reason gst-plugins-base fails for i686-linux? <g_bor[m]>I guess I will try to contact someone here before resorting to that though... <snape>the guile bug is supposed to be fixed :-) <pkill9>oh yeah that's pretty old, thought it was a new bug <snape>and ludo said "the problem appears to be gone." <amz31>snape: inlining the request handler `define' inside the `match doesn't scale <amz31>snape: inlining the request handler `define' inside the `match' doesn't scale <amz31>the file ins only 306 sloc in the end <amz31>the file is only 306 sloc in the end <amz31>cuirass is the biggest guile-fibers application <snape>amz31: I'm unsure what you mean, what 'match' are you talking about? <snape>hehe, I like guile-fibers, it's pretty cool <amz31>below and upward is the code about handling the different path routes <amz31>for instance, I try to avoid big piece of codes, the lines between 220 and 247 would have been at least another procedure <snape>spliting this into small chunks of code would be great <amz31>it works on a property (or key of the alist) basis <amz31>reviewing seems easy, I am not sure what the right path is for the project itself <amz31>there is also positive things in the code <amz31>snape: a thing a i do a lot nowdays, is have a /api/status path to point to some analytics like a weather thing <amz31>snape: even if right now it only reply 'OK' <snape>amz31: this is interesting. So you'd like to use your shallow validation stuff to validate the requests? <snape>there is also positive things in the code -> haha <snape>amz31: I'm sure you want to contribute. Why don't you send patches? :-) <amz31>snape: yes, because it comes from the outside of the application is must not be trusted <amz31>deep validation means in practice starting to interpret the data and check if doesn't violate an invariant like user login uniqueness against a database or password check <snape>amz31: I only have 8 commits in Cuirass btw. I'm a newcommer too ;) <amz31>snape: I see the API is read only since only GET is allowed <amz31>the buttons with numbers, where should they lead to? <snape>right now they don't lead anywhere <snape>I think the red one should lead to a list of failed builds... <amz31>oh ok prolly gray means waiting or not rebuilt? <amz31>hey, I could read the code :) <amz31>one good thing, cuirass does is that it doesn't mix domain logic with templating <amz31>like variables are ready before translation into html <amz31>everyting timeout on my side <snape>yes, it's a known bug I think <snape>probably there is a long-running SQL request <amz31>isn't the machine under load or it's deeper issue <snape>that blocks the Fibers scheduler <snape>I plan to fix this this week <amz31>i mean client/server model means you will move sqlite out to another service or that you will another database <snape>by serializing all SQL queries in a Linux thread <amz31>do you want an alternative that is more involving but would avoid the other thread? <amz31>I did not mention it's unstable afaik <amz31>there is distributed database (but works standalone like postgres) that is free and ACID like sql and has asynchronous drivers albeit not in guile <amz31>me rambling on database stuff <snape>yes, but changing the database would be waaaay too much work <snape>there are many other priorities <snape>so for now we need to stick with SQLite <snape>its simplicity is an advantage, too <amz31>that way you will send the sql to the sqlite thread? <amz31>I think that what wingo told me to do, it's called delegation iirc <snape>the advantage is that the blocking stuff would be contained in the thread <snape>and it would not annoy the scheduler anymore <snape>we already do this for the url handler actually <snape>that's exactly what 'with-critical-section' does <snape>I just want to replace 'with-database' with 'with-critical-section' everywhere <snape>except that it's in a fiber, not in a thread <snape>ACTION is testing the gitolite service <amz31>exactly what I try to achieve with python, pipenv, pyenv, lxc and ubuntu <snape>you mean, the critical section stuff <amz31>that said, it seems to me containers are less useful in guix land <snape>yeah I know, it's the sudden topic change :p 