<civodul>uh, the SourceForge mirror URLs we have no longer work it seems <civodul>i manage to successfully download stuff only via their web interface ***sankey1 is now known as sankey
<bavier`>wow, it takes a looong time to graft texlive-texmf on my netbook <civodul>there's a preliminary patch by mark_weaver to improve that <bavier`>civodul: thanks for looking at my clang patches <bavier`>I'll push them when I have access to my gpg key again <riaqn>Hello, nix user here. I want to know any advantages of guix over nix? <sneek>Welcome back myglc2, you have 1 message. <sneek>myglc2, alezost says: re "Autodoc not available": this warning (it's harmless) happens when you work with a scheme file and did not started Geiser REPL. Guix REPLs are used only for/by "M-x guix-..." commands; they do not interfere with your usual editing of scheme files <jmd>riaqn: I've not used nix, but I understand that guix has stronger isolation of packages. Another plus is that one doesn't have to learn a new language when hacking on guix. <myglc2>riaqn: I like the use of lisp instead of yet another custom language and the leverage of emacs which I already use. I tried Nix for a month or so and switched to Guix. Have not regretted the move. <riaqn>jmd: "stronger isolation" - can you elaborate? <riaqn>how is the support for haskell? <jmd>From what I understand, when packages are being built on nix, there is potential leaks from the host. guix has its own container like environment when creating packages. <jmd>There is a lot of haskell stuff, but I have never used it myself. <riaqn>jmd: any reference about the "container"? <myglc2>riaqn: I don't use Haskell either. There are 999 hits for 'haskell' on guix-commits@gnu.org and 450 on guix-devel@gnu.org. You could search those lists to get an idea or contact a committer. <lfam>riaqn: I think we have one big advantage, and that is the use of Guile Scheme. By embedding our domain specific language (the Guix DSL) in a general purpose language (Scheme) it is very easy for us to extend the DSL as necessary. I hadn't used Scheme before finding Guix but I find the Guix / GuixSD Scheme system to be a very pleasant place to spend time :) <riaqn>myglc2: thanks! I think haskell support on guix is not as good as it's on nix. <riaqn>myglc2: but that's not a big problem as I can use nix on any distribution. <riaqn>lfam: yeah, that's what I think a big advantage of using lisp. <lfam>I also think that our command-line interface is much easier to pick up and more consistent than Nix's. <riaqn>Also, I think the init system is quite cool! <riaqn>(is there another channel for guixsd?) <lfam>Yeah, we are making the whole system in Scheme :) <lfam>No, Guix and GuixSD are developed together, in the same code base <riaqn>yeah, then it make sense to discuss guixsd here. :) <lfam>So, they share the IRC channel, mailing list, bug tracker, etc <riaqn>I 'm kind of tired of systemd. :) <lfam>My primary machine is Debian with Guix. I actually like systemd, but I think it's very good that we are working on something else. <jmd>Yeah I think Debian have shot themselves in the foot with systemd <lfam>If anything, the fact that Debian has made such a big change to their system is a very good sign for the health of the Debian project. It shows that they have the will and the capacity to make fundamental changes to the OS. <lfam>In my opinion, that is independent of whether or not systemd is good for Debian. It means they can change again if they want to <jmd>I agree with that principle ... but not with the direction in which they applied it. <lfam>For example, they could replace dpkg / apt with Guix ;) <riaqn>lfam: you mean you installed guix on debian? <lfam>riaqn: Yes, it's my primary machine <lfam>I'd like to use GuixSD but there are still a few things missing for me, such as simple support for a fully encrypted disk <riaqn>lfam: hmm, so you are not using that init system? <jmd>Has anyone tried Guix on the Raspberry Pi? I have heard that it "can't be done" - but nobody has told me why not. <lfam>riaqn: I use GuixSD on a home server and I also do some development in QEMU (Guix has excellent QEMU integration) <lfam>jmd: The first Pi is an architecture that not many distros suport (ARMv6). Later Pis and most of the popular ARM boards are ARMv7 <lfam>I don't see why it can't be done, but somebody has to want to do it. The first Pi is slow and pretty bad from a "freedom" perspective <riaqn>lfam: so all configuration is done by scheme? <riaqn>lfam: and if the configuration does not provide the interface(to do full-disk encryption), you just can't <riaqn>despite the fact that your kernel supports it? <lfam>riaqn: Define "all" ;) I don't configure, for example, MPD on GuixSD with Scheme. I use a regular MPD configuration file. <jmd>Sure it's "slow" - but fast enought to do normal tasks. From a freedom point of view, it's no worse than any laptop from your local shop. <lfam>jmd: Like I said, somebody has to want to do it. Maybe you want to give it a shot? <jmd>Well maybe I will. I just wanted to find out if it was a non-starter first. <riaqn>lfam: on nixos, all these things is done by a nix-syntax configuration. <lfam>riaqn: Check out the manual sections 7.2 System Configuration to get an idea of how much of the system can currently be configured with Scheme <riaqn>lfam: but the packager can never provide all interface of that program <riaqn>so you can only do limited things by such interface. <riaqn>so they end up doing stupid things like embbeding nginx.conf as a string in nix config. <lfam>riaqn: I use NixOS too, and I find the configuration system somewhat limiting. In my opinion, if we are going to abstract some 3rd party program's configuration with Scheme, we must also provide an "escape hatch" where users can use the program's normal configuration system. <mark_otaris>If options are just added as packages are added, I'm sure it's possible for almost everything to be configurable in Scheme. <riaqn>to do things to really want(but not provide by nix interface). <lfam>riaqn: I actually wouldn't use NixOS at all if I couldn't put nginx.conf in the NixOS configuration. <lfam>Our users will never get support from Nginx if they can't show Nginx maintainers their configuration files in the normal format <lfam>And they will have difficulty migrating to GuixSD and back out <mark_otaris>Maybe providing specific options directly in Scheme isn't the best idea, then <mark_otaris>If it can be deterministic without that, there's no reason it absolutely has to be in Scheme <riaqn>my point is that, if you finally will need to write the original nginx.conf, then why bother abstracting it into nix options? <lfam>I think it's valuable to do it to a certain degree, but we should provide escape hatches <mark_otaris>as long as you can still have declarative system configuration <lfam>riaqn: Because many users only need a few basic options, so it might be possible to provide the necessary abstractions for most use cases <lfam>Check out our manual section 7.2.7 to see what we offer in that area <lfam>A firewall is a good example. I don't think it's reasonable to ask all users to learn iptables. NixOS's abstraction is good for most use cases. <riaqn>I saw these things on openwrt too. <lfam>Right, another good example <mark_otaris>I'd just like a way to have a version controlled repository with the entire system configuration in it that I can give to Guix. There's no reason that can't be done with the original nginx.conf, or torrc, or other configuration file. But that means Guix does need to support a way to put the configuration file in the right location... <riaqn>and their configuration interface is uci. <mark_otaris>So it doesn't work if I just put it myself in /etc/tor/torrc, for exampl <mark_otaris>So maybe the configuration files should just be in the store <lfam>mark_otaris: We are working towards this. We have it for several core packages. Help wanted :) <mark_otaris>and the package manager could add symlinks to them in /etc <lfam>That's what we do in GuixSD, and I believe NixOS works similarly <mark_otaris>I want to switch to GuixSD and start contributing packages at one point <lfam>mark_otaris: Feel free to ask for help or advice :) <riaqn>yeah, that's exactly what nix does. <riaqn>so there is not much difference between nix and guix. :) <lfam>Well, the person that started Guix was a Nix developer for some years. So, we had a good start! <riaqn>So I 'm reading the guixsd doc and well, all so similar to nixos... <riaqn>makes me wonder why we re-invent a nixos...only in lisp.. <sturm>Darn it, now I'm going to have to go through and try out all these cool new packages. How am I supposed to get any work done? <sturm>ACTION loves Trisquel, but misses that novelty feeling of tracking new packages flowing into Debian Testing. <riaqn>quick question: why firefox in guix so old? <riaqn>so icecat 26 is newer than firefox 26? <riaqn>so, icecat 38 is most similar to which firefox version? <mark_otaris>But yes, I wish IceCat would track regular stable instead. <riaqn>but then I don't get those fancy features.. <riaqn>I find many packages in guix quite out-of-date. <riaqn>basically several weeks behind nix equivalent. <riaqn>also, the diversity is not satisfactory... many packages I can find at all. <riaqn>a result of insufficient contributers, I guess. <mark_otaris>riaqn: Those are all valid complaints, but on the plus side it is easy to update packages, since it is usually just changing a hash and increasing a number. <mark_otaris>I only use Guix on top of another distribution currently, in part because of the number of packages available. <riaqn>mark_otaris: adding new packages is not changing a version number. <lfam>riaqn: Anything critical we need to update? <riaqn>lfam: nop, just plain complain. :) <mark_otaris>I'm sure it would be possible to largely automate package updates, and I think that's already possible for those made with the import command <mark_otaris>But then some updates will break things, and that will require work to fix anyway. <riaqn>mark_otaris: yeah, a script monitoring the software site... <mark_otaris>Currently it's just a cli command for Guix. Which works as well <riaqn>mark_otaris: that's actually not hard. An unstable branch full of auto generated packages, welcoming brave users to test. <riaqn>and these packges go into stable branch automatically after say, one month. <riaqn>yeah, that's basically the idea. <riaqn>which is why I don't understand the old versions. <riaqn>I have some kind of Obsessive-compulsive disorder about the version of packages. <mark_otaris>there are also cross-distribution projects like openSUSE's Open Build Service and openqa, release-monitoring.org, reproducible-builds.org <riaqn>automated packaging is especially helpful in guix's situation, namely the lack of contributors. <riaqn>at least save some contributors changing version numbers all the time. <mark_otaris>Or maybe use openqa for automated tests so that testing and unstable releases can be done automatically <lfam>Incrementing the version and updating the hash do not take much time. What takes time is reviewing new packages and updates. I hope all our contributors are actually reviewing their patches before they send them. <mark_otaris>Hydra makes sure the packages can build, but it would be useful to be able to know that before the patches are merged <lfam>Yes, I think that is a good idea <mark_otaris>openqa is able to do functionality tests, like booting a system and actually doing things to make sure that things work as expected beyond just the packages being able to build <mark_otaris>Right, I actually read that and managed to forget about it <lfam>I also have that skill ;) <mark_otaris>Hm, let's say I had a server (I don't). It could look for messages to the mailing list, and, if they contain patches, use the git commands to apply patches to the GuixSD repository <mark_otaris>then it could find the packages modified or added and try to build them with Guix <mark_otaris>and it could send back a message to the list with the build results <riaqn>mark_otaris: yeah, that could save another several contributors. <mark_otaris>riaqn: It's the most obvious thing I see right now that can be automated. <riaqn>But I really want to try out the init system. Installing guixcd is not an option. <mark_otaris>Hm, I'd actually like to be able to use systemd with GuixSD. <riaqn>mark_otaris: are you implying its init system sucks? <mark_otaris>Being able to configure services in Scheme is nice, but systemd has features I want <mark_otaris>riaqn: I haven't used Shepherd, I very much doubt it sucks. <mark_otaris>It's not really the systemd init system I care so much about <mark_otaris>for that Shepherd might be better since it allows me to configure things in Scheme <riaqn>I don't have to tail -f /var/log/xxx anymore. <lfam>You can run Shepherd on its own. Some people use it on other distros <lfam>You can use it just for your user <riaqn>so how do you read log on shepherd? <lfam>I don't know what it does in that case. System logs on GuixSD go to /var/log/messages. It would be cool to make something like journalctl for it <riaqn>I really like reading logs for a specific service. <riaqn>also, how is the service control like? <riaqn>mark_otaris: yeah, makes sense. <riaqn>I suspect journalctl is just a big grep. <mark_otaris>For example, if you run containers with systemd-nspawn, systemd in the container can communicate with systemd on the host and you can get the container logs on the host with journalctl --machine=containername <mark_otaris>There are systemd components that can be used without the init system, but I don't know which <mark_otaris>I really like systemd-boot, systemd-nspawn, systemd-networkd, for example <mark_otaris>and ConsoleKit isn't maintained anymore, so I want systemd-logind. mainly because I want to use Wayland if possible, and that can't work with the unmaintained ConsoleKit <mark_otaris>and I think moving the virtual consoles to user space is a good idea, so I'd like systemd-consoled too if it was still being worked on <mark_otaris>in general I'm just in favor of moving everything from the kernel to user space <riaqn>hmm, you must be fans of hurd. <mark_otaris>I think there was a port of Hurd to L4 at some point, but it isn't being worked on <mark_otaris>I would probably actually use Hurd if it was based on L4 instead of Mach. <riaqn>despite its poor performance? <riaqn>Hi, where 's the guix scripts? I want to read them. <riaqn>I mean, the location on my computer. <nikola_i>will guix have a separate repository of proprietary packages similar to AUR in ArchLinux <efraim>A number of people have packages that either can't be upstreamed or are modifications of current packages <rekado>nikola_i: such a repository would not be part of the Guix project and we would not encourage its use. <rekado>nikola_i: Guix respects the GUIX_PACKAGE_PATH environment variable and looks for package definitions in any of the provided directories. <rekado>nikola_i: this means you can use other people’s package definitions by dropping them in a directory that’s on your GUIX_PACKAGE_PATH. <rekado>however, there won’t be a single “official” unofficial repository for proprietary packages, as this is against the Guix project’s goals. <rekado>nobody stops you from starting such a project yourself, but we don’t want to see it advertised on the #guix IRC channel or the mailing lists. <rekado>nikola_i: I hope this answers your question. I’ve been using GUIX_PACKAGE_PATH at work for many months now and it’s more flexible and granular than the AUR. It is very easy for users to have their own collection of packages this way. <ng0>The problem would be that I don't have the threat scenario to test it with (great firewall of china) <ng0>I could only test runtime functionality <phant0mas>hey civodul rekado, if you are okay with it, I will rebase core-updates-next and sign the 7 commits just for this time <phant0mas>and then we can find a more appropriate way to handle this in the future, without being in a hurry :-) <rekado>phant0mas: I have no objection to this. <efraim>wait, gegl also uses babl, need to change that one too <efraim>this test update would be easier if I just stuck it in gimp.scm :) <jlicht>hmm for me --with-source gives me the following message: guix build: warning: transformation 'with-source' had no effect on ... <civodul>make sure the source basename matches the package whose source you want to override <jlicht>it seems that symlinks to directories don't work <civodul>rekado: could you look at the Clojure patches, when time permits? <jlicht>exactly why does the basename have to match for --with-source? Is this just a sanity check? <civodul>jlicht: if you do "guix build foo bar --with-source=baz.tgz", the thing wouldn't be able to determine which package source is being overridden <ng0>I have some questions regarding the first service I am writing (git): <jlicht>civodul: so you can also use with-source for one of the dependent packages? <ng0>1) record-types in services. I almost understand which purpose they serve there, and why they are needed, but could someone go into (non-technical) details about them, explaining in which case of service they are required, maybe with an example of a config file base service and a service with just switches? second question: I tried various variations of the service I sent in as a patch and applied what ricardo <ng0>suggested but I still end up with <git-configuration> being a problem. This is related to the first question somehow. <efraim>jlicht: you can use --with-input=old=new, and i put --with-input=old=$(guix build new --with-source=newer-source) <riaqn>ng0: hope I can help. I 'm china citizen but live in Canada now. <ng0>no, I just found it through subscription of the mailinglist link I posted <riaqn>a quick question: where is the package definitions(declarations) on my file system? <riaqn>ng0: I 'm glad that people around the world are concerned about GFW. <ng0>you mean the guix git checkout? <ng0>I'm just looking at one of my checkouts to see where package puts it <riaqn>ng0: I mean, how does guix find packages when I want to install them? <ng0>I find cloudflare and friends more concerning as gfw can be circumvented but cloudflare is much harder <ng0>currently guix pull downloads a tarball of the latest master <ng0>this gets unpacked, built, and you have the definitions then <ng0>I can tell you once i found this dir <myglc2>riaqn: did you find the location of the scripts you were looking for <ng0>it ends up in the gnu store dir, in *hash*-guix-source <ng0>i haven't lookd at the code of it <riaqn>/gnu/store/<hash>-guix-0.10.0/share/guile/site/2.0/gnu/packages/fcitx.scm <ng0>riaqn: for xx-network or what it was I'm mostly interested in the license (looks like I have to open an issue on github for that, it's not clear to me) and the problem being that I maybe might not be able to fully test it <riaqn>ng0: I guess it's mostly GPL, or bsd. <ng0>and it shares it priority with many other things I'm doing, below the gnunet guix roadmap i work on. i do preparing bits and pieces and add to code I find solutions for. <ng0>so I'll open an issue for it, I don't want to guess about licenses <riaqn>ng0: you 're welcome. Let's beat the GFW. <rekado>civodul: re Clojure patches: done! Thanks for the reminder. <riaqn>Yesterday we were talking about automated packaging. <riaqn>then I occurs to me that, haskell packages are the most automate-able. <riaqn>really, basically no manual intervention. <rekado>riaqn: we have importers to generate Guix package expressions automatically. <rekado>I’m using the CRAN importer very often and it usually requires only adjustments to the description. <rekado>riaqn: I haven’t looked at the insides of the hackage importer yet, but I think it parses the cabal files. <rekado>I used that to package pandoc with its many dependencies. <rekado>it made everything a lot simpler. <rekado>for the CRAN I wrote an extension to automatically recurse over all dependencies. <rekado>I’ll try to generalise it somewhat and then submit a patch. <rekado>riaqn: guess we don’t have so many users of Haskell software here. <rekado>I normally just package what I use. <Xe>riaqn: why bother packaging haskell software in the OS when cabal exists? <riaqn>But considering the ease of adding them, it's worth-doing. <rekado>riaqn: you are welcome to package a few for Guix :) <kyamashita>Xe: Same reason we package Emacs packages, npm packages, etc. <riaqn>Xe: I was told many times about cabel hell. <rekado>Xe: because then you get all the benefits of using Guix packages (e.g. environments, reproducibility, etc) <rekado>Xe: cabal is not a package manager. <riaqn>rekado: yeah, my point is that, it's not very hard to write a bot that generate thousands of haskell packages from cabal index, and push to guix repository, right? <rekado>riaqn: we still want some quality control <rekado>so there won’t be any automatic pushing to the repo <rekado>the descriptions should be helpful; non-free software (if exists) should be removed; etc <riaqn>rekado: do we have unstable branch? <ng0>one could write a batch import script, but quality checks and testing still needs to happen <rekado>riaqn: I’m actually sitting on a stash of 7000+ packages from CRAN. <riaqn>by free, you mean free as in GPL rather than say, in BSD? <rekado>but it takes time to go through them and fix them up <kyamashita>rekado: I meant to ask you on the mailing list: What do you do about Unicode and find-files? Is there a workaround? <rekado>both licenses are free software licenses <rekado>this is a common misunderstanding, and I wonder where it comes from <rekado>GPL is copyleft and BSD is not. But both are free software licenses and both are welcome. <riaqn>hmm, sorry but, isn't all haskell packages open-soruced? <alezost>riaqn: "open source" does not equal "free software" <rekado>it also happens that free software contains bits that are non-free, such as the Linux kernel. <riaqn>but then, there's a license field in each haskell packages's .cabal file. <riaqn>so filtering license is very easy. <rekado>I was actually talking about cases like “shogun”. <rekado>it’s free software but it includes bindings to non-free libraries. <rekado>just looking at the license file (which often is frustratingly misleading) would not have helped. <riaqn>but for most packages, either it's free, or it's not. <rekado>we cannot automatically import stuff and clean up when people complain. <riaqn>yeah, I think we need the licence field in .cabal to be more informative. <rekado>we would fail our duty as distro maintainers <rekado>“GPL” is which version? With or without automatic upgrade to the latest version? <rekado>these things are not always easy to figure out. <rekado>that said, I do welcome an effort to import all of hackage and review the packages. <rekado>just like I hope we can do this for all of Bioconductor and CRAN soon. <ng0>I fear the n of 7000 thread. I hope it comes in consumable pieces <rekado>it’s not going to be one big thread <ng0>You have seventhousand new messages <rekado>but my goal is to make R and Guix a very good fit. Then write a short paper about it. <rekado>Guix is really great for reproducible research and I want more people in bioinfo to use it. <ng0>can someone comment on my question I had earlier about services? <riaqn>Hmm, does guix has support for repository that's a function? <riaqn>that is, the function returns a repository. <jlicht>using (inherit ...) in a package definition, is it possible to change one tiny teensy thing in the `arguments' field of the package, without having to copy and modify the `arguments' field of the package we inherit from <riaqn>If so, I can write a function that, read cabal index, and returns the repository on the fly. <riaqn>and I can share this function(instead of a huge repositroy of 7k packges). <jlicht>riaqn: what do you mean with repository here? <rekado>ng0: we use these records to keep service stuff together. <riaqn>jlicht: a bag containing packages definitions. <rekado>ng0: the “type” is like a label, which allows users to modify the service when using “modify-services” but also to construct the service graph. <rekado>ng0: i.e. the dependencies between services. <riaqn>In emacs we have these things everywhere. <riaqn>say, in the place of a font name, we use a function, that accept some argument, returns a font name. <riaqn>which bring more flexibility. <rekado>riaqn: you are describing an importer <rekado>our importers produce package expressions from online info. <riaqn>I guess we can do in guix too, especially with lisp 's s-exp, it's very easy to generate a repository in a function. <ng0>rekado: specifically i wonder why when other services are constructed equally to mine, I still run into the same problem which I think comes from the (git) part in the records <riaqn>rekado: on the fly? or first into .scm files which are read by guix? <jlicht>rekado: IMHO what riaqn is trying to ask is why guix has these written out package definitons, instead of abstracting <jlicht>over some of the commonalities between package defintions and thus generating them _in the source_ <rekado>ng0: just for fun: have you tried renaming stuff? Just to be sure you’re actually using the right values? <ng0>i know that for the resulting git daemon i use the correct switches <riaqn>jlicht: yeah, that's basically what I want. <ng0>and accounts is also most likely correct <rekado>ng0: I don’t mean switches. I mean Scheme values. <rekado>ng0: it complains about something being a configuration when it really wants a package, right? <rekado>riaqn: the package definitions give us a chance of reproducibility. <rekado>riaqn: the package expressions are just scheme values. <ng0>guix/packages.scm:638:21: In procedure package-transitive-propagated-inputs: <ng0>guix/packages.scm:638:21: In procedure %package-propagated-inputs-real: Wrong type argument: #<<git-configuration> git: #<package git@2.9.0 gnu/packages/version-control.scm:113 2f229c0> base-path: "/var/git/repositories" port: 9418> <rekado>riaqn: taken together they span a graph of dependencies. <ng0>i applid your changes already <ng0>and i checked the file <riaqn>rekado: well, what I want to express is not that big. <ng0>if there's something to find, it's not obvious to a beginner in scheme <rekado>ng0: yeah, so how does a git-configuration end up in “package-transitive-propagated-inputs”? <riaqn>say, in guix 's source, it load repository like: repo = eval(read(REPO_PATH)) <riaqn>now I would prefer it loads repo like: repo = eval(read(REPO_PATH))() <ng0>some small parts i sourced from other services and altered them <riaqn>that is, treat the repo as a function that returns packages definitions. <jlicht>riaqn: export GUIX_PACKAGE_PATH=/path/to/guix-custom <rekado>ng0: I’ll try take a look at this tonight, but I cannot promise anything. Could you send me a patch that applies to latest master? <jlicht>combined with your very own scm files that do whatever it is you want (in this case, generate lots of valid package definitions) <riaqn>jlicht: I guess that's not gonna work, it will treat my source as list of packages, no? <ng0>there are 3 occurences of git-configuration.. okay, that would be be great :) or just some pointers on what you think or why. When there's little to compare with it's slow to get started <jlicht>riaqn: is that a problem? you wanted to programmatically generate these packages, right? <ng0>I'll send an updated patch <riaqn>jlicht: yeah. I get your point. <riaqn>jlicht: I will try that out. <rekado>I once posted an idea here that was similar. It would allow installing packages from upstream repos that are supported by our importers. In the background it would fetch the upstream info recursively, create package expressions, cache them in a file for later review, and then install the packages. <rekado>for a user it would look like “guix package --install-via=bioconductor genomation” <jlicht>rekado: it would be nice to have a server do that automatically, and keep a (web accessible) review queue of automatically built packages. <jlicht>although exposing it like this to a user might lead to people installing non-free software <riaqn>Also, I hope the guile can be lazy. <riaqn>That would be very helpful if 7k packages were generated on-the-fly. <ng0>i think i can also look at the current dropbear service to see if it gives me further insight ***boegel is now known as boegel|afk
<myglc2>just switched to origin/master and 'guix environment guix' stopped working <davexunit>myglc2: ludovic noted that recent commits have caused the ABI to change which requires rebuilding from scratch. have you done so? <frerbst>Hi! I'm interested in GNU Guix and would like to try it in a VM first. I read that there's already a feature for generating QEMU VMs. But what about the bootloadernand file system specifications in the configuration file? Are they ignored? <davexunit>frerbst: the bootloader is ignored, but I'm not exactly sure what happens with the file systems. <frerbst>davexunit: Ok, I'll just try it then ;) <davexunit>I need a refresher on that part of the code. I read it some time ago, but I've been out of the loop lately. <guixuser>can we expect support for proprietary software and hardware drivers in guix? <guixuser>eg. intellij idea, nvidia proprietary drivers <ifur>well, likely to be supported, but not officially by GNU of course <adfeno>guixuser: Perhaps so. I'm not since I'm not a developer. Besides: I can't speak for the Guix and/or GuixSD projects. <ifur>nothing stopping Nvidia to support guix, they already have rpm's <davexunit>guixuser: guix itself will never provide support for such software. <adfeno>People or non-free software redistributors would have to make their own recipes for Guix/GuixSD, but the projects (Guix/GuixSD) won't accept these recipes in the official repositories. <davexunit>guix is free software, of course, and users can develop and maintain packages for whatever software they wish, but the packages that ship with guix itself will be exclusively free software. <davexunit>adfeno: nor will we promote such third-party repos <guixuser>i guess we'll have something like AUR in ArchLinux for such recipes <davexunit>it's trivial to set GUIX_PACKAGE_PATH to point to one or more directories with custom package recipes <ifur>yeah, non-issue for guix, so can ignore every and all common practices by traditional distros <guixuser>a central repo of user contributed recipes would benefit the community a lot. not every one would be willing to write custom recipes from scratch <davexunit>guixuser: we encourage users to submit those recipes to us <davexunit>it's much easier to get packages into guix than other distros <guixuser>yea but Guix wont accept recipes for proprietary drivers correct? <adfeno>Guix (package manager) will do so. <adfeno>That is: If you make a recipe for a non-free functional data to be installed with Guix on your system, and you ask Guix to read the recipe, it'll read it normally. <frerbst>Well, but you won't be able to use these drivers with Linux libre, right? <davexunit>but you should just use free software instead. <adfeno>frerbst: Yes, but it must be noted that, according to Alexandre Oliva, one of the contributors of Linux-libre, this is actually a bug, not a feature. <davexunit>yeah, I think there's a technical limitation of some sort <adfeno>Look for the question that starts with "Is there anything that the project wants to do". <adfeno>I have received many invitations to go to an event about Docker software-container-manager... I personally, don't like this kind of software, but the invitation was sent to a mailing list... :( <paroneayea>adfeno: well, docker isn't explicitly evil, though some of us are not fans here :) <paroneayea>though I think docker does encourage methodologies that end up with a lot of evil, in practice <adfeno>I heard some Docker containers have freedom issues, althought I have only heard, I don't proof. <paroneayea>probably *most* docker containers have freedom issues <davexunit>it's hard to tell since docker isn't the most transparent system <adfeno>ACTION jumps like a scared cat, from the chair to the ceil. <davexunit>but I would agree with paroneayea that there's a good chance that most container images have freedom issues <paroneayea>the Linux Mint "compromising a popular image" thing has made me wonder a lot how many non-auditable docker/etc containers out there <paroneayea>that's just a suspicion, but yeah, I'm suspicious <davexunit>I'm seeing a lot of tools come out now that scan images for security issues <davexunit>which feels to me like a solution in the wrong direction <davexunit>if the system you built were auditable to begin with, you wouldn't need to use some crazy heuristic to attempt to tease out potential security issues <davexunit>how could the tool know that you built nodejs statically linked against a vulnerable bundled openssl? <davexunit>maybe there's a way, but that seems awfully difficult compared to examining the full system's dependency graph <paroneayea>once we solve the halting problem, finding every possible security issue on a built image will be pretty easy though ;) <davexunit>when I encounter an infinite loop, telling the computer "hold your horses" usually resolves it. <ng0>o.O has kyotocabinet been adopted by cloudflare for further development?no release of it of FAL Labs since 2011 or so, and there's now an active kyotocabinet repo of cloudflare on github <paroneayea>that only works if the loop is sufficiently strange #vaguejokes <ng0>also no announcement of stopped work at FAL <ng0>i misread the 4 in 2014 for a 6 <ng0>this happens when you only look at 3/4 of the horizontal page <rekado>later tell riaqn “<riaqn> [18:33:21] Also, I hope the guile can be lazy.” <– Guile has “delay” and “force”. <rekado>sneek later tell riaqn “<riaqn> [18:33:21] Also, I hope the guile can be lazy.” <– Guile has “delay” and “force”. <ng0>sneek: the cake is a lie <sneek>Last time I checked the cake is a lie <ng0>sneek: why is the cake a lie? <myglc2>davexunit: thank you, that fixed my problem. <efraim>wow, forgot I was so close to getting onionshare built <ng0>pybitmessage is not very responsive in bugtickets. <pankaj_>is it possible to use guix as a package manager in ubuntu? if so, is there any documentation that i could follow? <ng0>well, it's only 1 week without a reply to the 2 tickets <ng0>the manual should have guidelines :) <efraim>you can use guix on top of ubuntu, but it's not set up to install software system-wide the way apt-get does <pankaj_>so i wouldn't gain much by using it on ubuntu. <pankaj_>my primary reason for using it in ubuntu is to use the mainline kernel. is it possible to change kernel in guixsd right now? <efraim>you'll have to write your own kernel package, and then I believe its something like (kernel my-kernel) in the config.scm for guixsd <ng0>rekado: i'll send an updated patch on top of the one I did sent.. I'll try to rule out some more mistakes now <efraim>good news for onionshare: it does check port 9050 and not just 9150 so no substitute* magic to make it work <ng0>:) that makes one package less from our Gentoo overlay to transition to Guix. <ng0>why is it that we don't build the manual for git-daemon? or is it in a doc output? <davexunit>ng0: if its not in a doc output then it's likely just an oversight <ng0>there's no :doc .. i'll fix it soon. <ng0>rekado: ha :) success. or at least I am over syntax error <rekado>ng0: great! Do you still need me to look over the patch or do you think you can manage from here? <ng0>Things are building for now, I think I can take it from here. I think I arrived at the point where for some deeper understanding of the few things I do not understand in detail in syntax I need to consult guile documentation. <ng0>the patch i sent is no longer relevant as i rewrote maybe 20% or so <civodul>rekado: thanks for the Clojure patches, that was fast! <atheia>Hello, since commit 1929fdba80ab2432d0a9c27633c94a79fb3bb170, my ./pre-inst-env guix {lint,environment} fail with… <atheia>In procedure struct-ref: Argument 1 out of range: 10 <atheia>I gather this might be to do with the removal of the 'imported-modules' field. <atheia>Has anyone come across this issue? <rekado>ng0: okay, cool. If you have related Guile questions feel free to ask them here or on #guile. <atheia>My current theory is that I would need to run a later version of guix-daemon, which takes that commit into account; i.e. a guix system reconfigure; but not 100% sure about this. <rekado>atheia: that’s an ABI change and you need to run “make clean-go && make” <rekado>I had the same issue today in the morning after upgrading. <atheia>rekado: cheers, will try that now. <civodul>rekado: what monitoring tool do you use at work? what would you recommend? <rekado>civodul: we now use checkmk, which is just a beefed-up variant of nagios. <rekado>in China we used icinga, a fork of nagios. <rekado>I can’t really recommend any monitoring tool. <rekado>their usefulness depends a lot on how they are configured. <rekado>right now I get about 500 emails a day, sent out automatically by these systems. <rekado>really needs to be tuned to reasonable thresholds, or else this is all just noise.