IRC channel logs

<yenda>installing/updating vlc feels like pulling the whole internet

<yenda>and indeed it didn't update the kernel

<caddar>how do i change my shell to zsh on guixsd?

<caddar>and question two: does it make me a scoundrel to do ln -s /run/current-system/profile/bin/env /usr/bin/env? If not, how should I write a python script?

<Steap>caddar: I must say I also wonder about that /usr/bin/env thingy :)

<caddar>i even feel tempted to just go hogwild and ln -s /run/current-system/profile /usr

<tennix>how to install different versions of a package? python2 and python3 for example

<yenda>is it possible to apply a patch for the kernel the way we do for the other packages ?

<alezost>yeah, why not; it's just a usual package

<yenda>ok I'll test it then

<yenda>this patch would be a breeze for all miserable ati gpu user out there trying to run guix http://www.fsfla.org/pipermail/linux-libre/2015-July/003080.html

<rekado->yenda: is this to make the driver work without the firmware blob?

<tennix>can i use dmd without GuixSD

<taylanub>tennix: I'm not sure but I strongly suspect that it's possible. you might want to look into its documentation.

<tennix>dmd is the first process with pid=1, seems impossible to run on other distros

<alezost>tennix: surely you can

<alezost>if you mean to use it as a manager of user services

<yenda->alezost: you remember my problem with an ati radeon ? It seems like there is a fix (not for 3D but for radeon pilot not to crash at least), I have the patch running at home but hydra was so slow I'll see the result when I come back

<tennix>i just installed postgresql with guix on centos and wanted to manage postgres with dmd

<alezost>yenda-: yes, I remember. I hope that patch will fix this issue

<tennix>and i also installed dmd using guix, but there seems no dmdconf.scm file in ~/.guix-profile

<alezost>tennix: at first, if you want to try dmd separately from GuixSD, look at the manual: <http://www.gnu.org/software/dmd/manual/html_node/index.html>

<alezost>tennix: what is "dmdconf.scm"? Why do you think it should be in ~/.guix-profile?

<tennix>the manual says run "dmd --config=/etc/dmdconf.scm.old", as i installed dmd with normal user, i think /etc will be linked to ~/.guix-profile/etc

<tennix>apparently my normal user has no permission to create file in system /etc directory

<amz3>(can you give an exemple of user service please?)

<tennix>at least i have to run dmd as a daemon, and then can run a service using deco command

<tennix>but i don't know how to start dmd, there's no config file to load

<alezost>amz3: There are a couple of examples here: <http://git.savannah.gnu.org/cgit/dmd.git/tree/examples>

<alezost>If you are interested this is my config: <https://gitlab.com/alezost-config/dmd/blob/master/init.scm>

<alezost>tennix: you need to write a config

<tennix>oh, it seems that there's no need to load a config file manually. I just run "dmd" and it just complains that "no such file or directory '~/.dmd.d/run'"

<tennix>and i just create this directory and run "dmd" again, only complains "socket directory setup is insecure"

<tennix>with "-I" option which ignore insecure, can start dmd daemon now

<alezost>amz3: the simplest service: <http://www.gnu.org/software/dmd/manual/html_node/Service-Examples.html#Service-Examples>

<tennix>now, i just wondering what permission should i set to ~/.dmd.d/run directory

<tennix>i'll check the manual for some more details

<alezost>tennix: I have 700 permission on that dir

<amz3>Sorry for the noise. thx, I understand the use of dmd. I was wondering whether there was other use, like a supervisor replacement, but anyway I don't have interest in that feature. I could use it for emacs daemon though.

<tennix>alezost: yes, 700 works, thanks

<tennix>amz3: dmd is similar to systemd/upstart which manage service from system boot

<tennix>systemd is a controversial system service manager, but gradually adopted by more and more distros

<taylanub>of course I hope/believe that dmd will be even greater (being in Guile), but my experience with systemd on Debian was very nice so kudos to them.

<yenda->Is there a plan to give hydra some mirrors (of the susbsitutes rather than more builders) ?

<amz3>I think the plan is to use gnunet for binary distribution

<amz3>I mean, there is a gsoc for that

<amz3>so that's the plan

<taylanub>yenda-: that would probably entail too much synchronization overhead since the packages on hydra change rapidly

<yenda->ok, I hope it will work soon, it took me 2hours to update my system with subsitutes from hydra

<amz3>my understanding is that at least guile gnunet bindings will be finished

<DusXMT>ACTION wonders if there will be a web-like service for gnunet

<amz3>there might be still work to be done to have guix distribution over gnunet

<amz3>DusXMT: what do you mean?

<amz3>something like bittorrrent maelstorm?

<DusXMT>amz3: Something similar to the World Wide Web, with someting similar to web pages

<amz3>maelstrom*

<amz3>yeah that's maelstrom

<taylanub>I thought GnuNet's transfer method is intrinsically high-latency or so, since it's P2P?

<taylanub>well, same with Freenet and yet they have Freesites. and I didn't know of Maelstrom...

<amz3>after discussion with #gnunet and my own understanding there is nothing stopping from doing so.

<amz3>I'm working on something like that

<amz3>but it's more a framework for building networked p2p application. which includes application using the web stack

<amz3>I think gnunet has also messaging

<taylanub>interesting stuff :)

<amz3>web: html5+css+js

<amz3>since you seem interested i'll explain a bit more

<amz3>maybe have feedback

<amz3>my plan is to have a database in guile, that can be easily synced/shared over gnunet

<amz3>making it easy to "push" updates, which is possible with gnunet, but not directly possible in guile right now

<amz3>right now my plan is to keep the P2P spirit, which means an application is not centrally owned.

<amz3>actually i'm not interested in other plans

<amz3>well, my database is more like a long dream I have. It could work with SQLite or other. It's just that I'd like hopefully to lower the barrier of entry for building such p2p apps from guile avoiding sql databases

<amz3>a lot people are interested in this kind of project

<amz3>kfor so it's very likely

<amz3>sorry

<amz3>for some definition of "a lot"

<amz3>so it's likely to be something of next year or next few years

<amz3>there is already gittorrent, which use the bittorrent DHT and allows to keep you git repo in the DHT over P2P

<amz3>this is the same principle that I will use, except through gnunet

<taylanub>I don't know very much about the details of GnuNet and other P2P technologies so I can't give meaningful feedback, but it sounds interesting, thanks for the explanation

<amz3>gnunet use something similar to the DHT of bittorrent and kademlia. Which is a distributed key/value store

<amz3>what you can do with gdbm or bsddb or kyoto cabinet or wiredtiger or even redis can be done with the DHT and gnunet

<amz3>gnunet is database with a specific interface

<amz3>and features.

<amz3>it's shared database

<amz3>that's what my library should make obvious

<xentrac>hi there. I tried to build guix 0.8.3, but it wants Guile 2.0.7 or better, and Debian Stable Guile is 2.0.5+nonsense. where do I find older guix source tarballs? They're not linked on https://www.gnu.org/software/guix/download/

<xentrac>presumably once I have guix 0.8.anything running, I can install current Guile inside of it and build current Guix under Guix

<davexunit>xentrac: you'd be better off installing our binary tarball, if you're open to that.

<davexunit>I could've sworn debian jessie had at least guile 2.0.9

<xentrac>well, I agree that that would be a more expedient solution

<xentrac>this is wheezy

<davexunit>old stable, then. okay.

<xentrac>doh!

<xentrac>surely somewhere there's a directory full of old guix releases?

<davexunit>yes.

<davexunit> http://alpha.gnu.org/gnu/guix/

<davexunit>but I think it would be easier to compile guile 2.0.11 and use it to build the latest guix.

<xentrac>that could very well be; any idea when the guile dependency changed?

<davexunit>but whatever you think is easiest. :)

<davexunit>one sec...

<xentrac>or whether I'm likely to run into other similar roadblocks?

<xentrac>(you could very reasonably argue that wanting to build it with a 2½-year-old release of guile is silly)

<alezost>xentrac: I don't suggest you to try this way

<davexunit>I'm not sure when we bumped the min version for 2.0.5 to 2.0.7.

<xentrac>guix 0.8.1 is satisfied with 2.0.5+debiansilliness

<davexunit>okay

<xentrac>hopefully I can use guix 0.8.1 to build guix 0.8.3

<xentrac>alezost: any particular reason, or just that it's not the best-tested path?

<xentrac>thank you very much, davexunit!

<alezost>xentrac: I think it's not tested at all

<davexunit>it will work, you can get a new guile from that guix

<davexunit>though I worry that we no longer have binaries available for that release.

<davexunit>and xentrac will have to build everything from source.

<alezost>ACTION is sure there are no binaries for that release

<xentrac>building everything from source will make me a happier sentient entity

<davexunit>okay, just "buyer beware". :)

<davexunit>if you're comfortable with it, go for it.

<xentrac>one of the reasons I never installed Vesta was that it was impossible to build it from source

<xentrac>(one of the problems with self-sustaining systems like Vesta and Squeak, I guess)

<davexunit>that's not cool, yo.

<davexunit>yeah, we take care, and so does Guile, to make it possible to bootstrap without needing a previous binary of our software.

<xentrac>well, they had a sort of reasonable excuse for it

<davexunit>whereas a lot of new compilers and things self-host and remove the bootstrapping option entirely.

<xentrac>which ones are you thinking of?

<davexunit>haskell is one I can think off of the top of my head

<xentrac>amusingly, the guix 0.8.1 source distribution now seems to be downloading both guile 2.0.11 and guile 2.09

<xentrac>2.0.9

<xentrac>precompiled versions of them, I think

<davexunit>I think 2.0.9 is a "bootstrap binary"

<xentrac>yes

<davexunit>the whole system relies on a very small number of bootstrap binaries

<davexunit>that are changed rarely.

<davexunit>2.0.11 is what you will end up using.

<davexunit>as the end user.

<xentrac>five of them in 0.8.1, apparently.

<xentrac>okay, reading manual now. thanks!

<davexunit>happy hacking

<xentrac>happy hacking :)

<xentrac>hmm, still no Guix for OS X? I might end up having to use Nix so that other people on the project can run the same packages I am... but I'll leave that for later

<davexunit>xentrac: I don't think we have a single developer that actually uses OS X.

<davexunit>I think we'd be happy if someone did the port, provided that it can be done without a nonfree toolchain.

<davexunit>but we need interested in developing *and* maintaining it.

<davexunit>I'm not sure how Nix's build farm handles the darwin stuff

<davexunit>if it builds them on GNU/Linux, then we could do the same, if they use OS X, then we cannot.

<_`_>I doubt they cross compile.

<davexunit>maybe they do. no one really uses OS X for servers.

<davexunit>except crazy people.

<_`_>you still need the xcode sdk I think for most things that help with that

<_`_>and that's just to setup the toolchain

<xentrac>Nix actually has two different ways of compiling for OS X

<_`_>It just seems like too much of a pain instead of just virtualizing it and compiling natively.

<davexunit>_`_: yeah if we need xcode then that's a dealbreaker.

<davexunit>_`_: we also cannot virtualize OS X because it contains a lot of proprietary software.

<xentrac>their "under development" "Pure Darwin stdenv" doesn't use Xcode: https://nixos.org/wiki/Nix_on_OS_X

<_`_>Oh I'm not suggesting any o that

<_`_>s/o /of /

<_`_>(os x should be an afterthought, imo)

<davexunit>xentrac: cool

<xentrac>I don't use OS X either

<davexunit>that sounds promising

<xentrac>but both of my coworkers do

<davexunit>_`_: os x already is an afterthought for us ;)

<davexunit>I have no interest in it, at all.

<xentrac>it doesn't look super active: https://github.com/copumpkin/nixpkgs/tree/pure-darwin

<davexunit>but if someone was, and could port guix without making it nonfree, I would be happy to see it.

<_`_>It sounds like it can only be done natively if this pure-darwin is used

<_`_>most things cross compiling for os x on GNU/Linux seem to require the sdk https://github.com/tpoechtrager/osxcross e.g.

<xentrac>yeah, OS X is a huge problem

<xentrac>I'm going to postpone worrying about it for a while :)

<xentrac>hmm, I'm still trying to figure out how to get 0.8.1 to become runnable. `./configure && make && make install` completed successfully and has created a guix-daemon binary, but did not create /gnu or /usr/local/bin/guix or anything. I guess now I run guix-daemon or something?

<xentrac>I expected `make install` to install a `guix` command

<xentrac>`make check` hasn't finished yet but it seems to be compiling diffutils

<xentrac>yeah, so `make check` finishes and everything passes

<xentrac>INSTALL says to use ./configure && make && make install, but it's just the standard autoconf INSTALL file. there's now a /usr/local/var/guix/daemon-socket/socket

<tennix>yes, guix-daemon will create that socket

<xentrac>if I try to invoke ./scripts/guix, I get a backtrace ultimately saying "ERROR: no code for module (guix ui)"

<xentrac>yes, I created the guix-builder group and users, and launched guix-daemon successfully

<xentrac>but shouldn't there be a guix command to ask guix-daemon to build things for me?

<tennix>is there a guix-real file

<xentrac>`: user@debian:~/pkgs/guix-0.8.1; find -name guix-real` returns no results

<tennix>i install guix through their binary, and guix command is just a script file, last line of it is exec xxxx/.guix-real

<davexunit>xentrac: 'guix build package-name'

<xentrac>davexunit: bash: guix: command not found

<xentrac>is it supposed to be installed by `make install` in /usr/local/bin?

<davexunit>xentrac: whatever you set your prefix too

<xentrac>it installed a bunch of stuff in /usr/local/share/guile, including its bootstrap executables

<davexunit>by default it's /usr/local

<xentrac>yeah, I didn't override it, and that seems to be where it installed the things it did install

<xentrac>yeah, in the Makefile it says `prefix = /usr/local`

<xentrac>hmm, this time it did install a guix in /usr/local/bin

<xentrac>I wonder why it didn't before! But now I am happified!

<davexunit>that's odd... 'make install' certainly works reliably, otherwise we'd have a lot of nondeterminism issues in our package builds

<xentrac>maybe it had a hidden dependency on having run `make check` first

<xentrac>now I will continue reading the manual

<xentrac>meanwhile `guix pull` has decided to compile GCC

<davexunit>xentrac: this is because you haven't authorized a server to provide binaries to you

<davexunit>xentrac: guix is a source based package manager that optionally allows you to download pre-built binaries *if* you authorize a server as trusted.

<xentrac>compiling GCC seems like a reasonable thing to do; it just surprised me

<xentrac>it's also compiling Linux, which may not be as sensible

<davexunit>with guix being an alpha distro with no stable series, expect a lot of rebuilding.

<xentrac>:)

<davexunit>we reduce the amount of rebuilding between releases by having a separate git branch that contains patches that "rebuild the world"

<xentrac>it would be nice if its sandboxed builds could use its own version of the Linux kernel in order to make them more reproducible, but chroot is not that powerful :)

<xentrac>given that I'm going to keep using Debian's kernel, it seems perhaps unreasonable that it's going to build me a new kernel. what does it want to use it for?

<davexunit>guix uses chroot + namespaces to create one of those new-fangled "containers" people like to talk about so much. :)

<xentrac>yes

<xentrac>my coworker said "it would be cool if it could use Docker!"

<davexunit>xentrac: I'm not sure, but it likely needs a header or shared lib or something else that's distributed with it.

<xentrac>I said, "Well, what Docker does is..."

<davexunit>heh

<davexunit>I'm actually on the verge of having basic user-accessible container support in guix.

<xentrac>AWESOME

<davexunit>so yeah, no docker needed, though we would gladly accept a package recipe for it. :)

<xentrac>although, doesn't the ability to write and build a package recipe amount to "basic user-accessible container support" already?

<davexunit>yes, but that's only the build environment.

<davexunit>what about when you actually use the software?

<davexunit>that's what my container implementation, named in Scheme style as 'call-with-container', allows.

<xentrac>what can't you do in the build environment?

<xentrac>hmm, maybe I should finish reading the manual before I ask more questions

<xentrac>heh, now it's building libc :)

<davexunit>yup :)

<yenda->before packaging docker we need to package go

<yenda->codemacs is on it

<davexunit>that's getting close :)

<davexunit>xentrac: the build environment is non-interactive

<yenda->anybody working on packaging clojure ?

<xentrac>and I suppose non-reinvocable

<davexunit>it's very tightly controlled and explicitly for making builds as reproducible as possible. no networking and such.

<xentrac>yeah, no networking would make it difficult :)

<davexunit>what I am after is a way to make containers that run GuixSD, our distro.

<xentrac>it would be useful to be able to run, say, Apache in a container too

<xentrac>or BIND

<xentrac>fucking BIND

<davexunit>yes, that too.

<xentrac>I saw an amusing article about Docker the other day

<tennix>what about vagrant

<davexunit>tennix: we have 'guix system vm' that can be used like a vagrant replacement

<xentrac> http://adamierymenko.com/docker-not-even-a-linker/ basically says that Docker is "a tool to make manual linking easier. More specifically, it's a tool to let you do manual linking and then save your work."

<tennix>In fact i'm running guix in a vagrant vm

<xentrac>not "basically". that's exactly what it says

<davexunit>tennix: care to share your vagrantfile for guix?

<xentrac>yay guixsd vagrantfile!

<tennix>no, not guixsd, just guix

<davexunit>I'm interested in making our VM creation tools cover the necessary things to replace vagrant.

<xentrac>if we believe Adam, than Guix could do automatic linking

<xentrac>what's wrong with vagrant?

<davexunit>of course, this would only be for guixsd vms.

<davexunit>xentrac: there's nothing "wrong", exactly, but it's not very good either.

<tennix>maybe i'll try to build a GuixSD vagrant

<davexunit>the most wrong thing is that it uses virtualbox by default

<davexunit>and virtualbox is non-free now.

<xentrac>really? there's no free virtualbox anymore?

<_`_>I'd like a better vm management tool, but I'm mostly fine with just invoking qemu(1) these days.

<davexunit>but vagrant is just another tool with an imperative, stateful model and all the issues that it brings.

<xentrac>(also, should I expect `guix pull` to fill up the 2½G remaining on my SSD?)

<tennix>vagrant support provision

<yenda->no clojure users on guix yet

<davexunit>xentrac: depends on how much software needs to be built. by building everything from source you will bring in considerably more software.

<xentrac>yenda-: how's the JVM?

<xentrac>I guess if virtualbox has become non-free, we should expect the JVM to become non-free too

<tennix>shell by default, and can use chef, puppet and so on

<davexunit>tennix: and 'guix system vm' also provisions vms.

<xentrac>yenda-: I mean, how do you find the current JVM packages in Guix?

<xentrac>are they good?

<yenda->xentrac: icetea ?

<yenda->icedtea sorry

<DusXMT>xentrac: Well, from what I know, the problem with Virtualbox is that there isn't a free compiler for the bios

<tennix>i just build guix from source in archlinux. only invoking ./configure && make && make install. everything goes well

<davexunit>great :)

<xentrac>DusXMT: that's less alarming then.

<xentrac>tennix: thanks!

<tennix>trying to build on a mac. it says 'x86_64-darwin14.4.0' is not a supported platform

<xentrac>yeah, we were talking about that about half an hour ago

<xentrac>about an hour ago

<xentrac> https://nixos.org/wiki/Nix_on_OS_X talks a bit about what's needed to build Nix on OS X, which they have working, and to build it without XCode, which they have more or less working

<xentrac>I'm guessing that this may be relevant if you want to get Guix running on MacOS

<tennix>we can use gnu tool chains

<xentrac>the Nix folks are using clang for whatever reason

<tennix>i have coreutils installed on mac

<davexunit>my knowledge of bootstrapping new systems is practically 0, so I can't really provide much insight into things.

<xentrac>yeah, that's becoming increasingly necessary since Apple acquired its GPLv3 allergy

<davexunit>yeah, it sure is great to use a brand new Mac with a 2007 release of bash!

<xentrac>it offers us some possibility of winning back some hackers who deserted free OSes for MacOS ten years ago :)

<_`_>That's desired?

<davexunit>those folks say "I just use homebrew"

<davexunit>some of whom are convinced that homebrew is better than GNU/Linux package managers!

<xentrac>it's not a very strong argument for them, I'll admit

<xentrac>homebrew does have its benefits. especially if you're comparing it against, say, rpm

<davexunit>it's better than nothing, and it's nice that an unprivileged user can use it.

<davexunit>but it's unsafe.

<xentrac>well, and more to the point, it doesn't provide rollback or isolation

<xentrac>"unsafe" is not a very persuasive argument on its own

<davexunit>yes

<xentrac>in a few minutes I'm going to one of the most dangerous neighborhoods in Argentina. so far nobody has robbed me there but some of my co-volunteers there have been robbed at gunpoint

<davexunit>:/

<xentrac>by comparison, nonfunctional package managers do not seem particularly risky to me

<davexunit>well, of course

<xentrac>but I would like to be able to install a modern version of IPython without worrying that I will irretrievably break booting or audio

<davexunit>but I'm speaking relatively

<tennix>xentrac: programming languages have their own package managers

<davexunit>which is yet another problem :)

<xentrac>tennix: yeah, I think that that's partly a result of the last ten years of hackers using MacOS

<xentrac>but it's also a result of hackers needing things that apt and rpm don't support from package managers

<davexunit>yes

<xentrac>like having different versions of a package installed

<tennix>ipython can be installed using pip

<davexunit>it "solves" that, sort of.

<davexunit>it doesn't solve it generally.

<davexunit>it just adds new package managers you have to use.

<davexunit>and they all have their boundaries in which they can operate

<davexunit>and for the rest you're on your own.

<yenda->when a package needs jdk we give it icedtea as native-input ?

<tennix>it provides their own ecosystem

<davexunit>yenda-: if it uses the compiler, yeah.

<yenda->and for the jvm ?

<xentrac>tennix: yes, and one of the major advantages of that is that I can be using the same library versions as my coworkers are

<xentrac>I'm not sure that's purely a win, but sometimes it is a win

<davexunit>tennix: yes, it has certain advantages but it also has the huge disadvantage that developing and deploying applications is now a complete and utter nightmare.

<davexunit>web applications now need at least 3 package managers typically

<xentrac>heh

<davexunit>this is where Guix comes in.

<xentrac>guix already has a balun for PyPI, right?

<amz3>balun?

<davexunit>is balun a spanish word?

<xentrac>no

<davexunit>we have a PyPI importer.

<davexunit>that can (mostly) generate package recipes for you

<xentrac>a balun is a thing that lets you connect a balanced microphone to an unbalanced input, or vice versa

<xentrac>I didn't remember that it was called an "importer" in Guix

<davexunit>'guix import pypi'

<xentrac>are there importers for npm, bower, gem, etc.?

<davexunit>npm and rubygems are in the works

<xentrac>sweet :)

<davexunit>I have written a ruby build system, and I'm trying to untangle the complete and utter madness of the node build system.

<davexunit>but I did write a naive npm importer.

<xentrac>:)

<tennix>oh, nearly all of the newly languages have their own package managers

<davexunit>yes

<davexunit>because package management sucks right now.

<yenda->davexunit: is there a jvm ?

<davexunit>yenda-: I think so. I haven't used it.

<tennix>do you plan to make importer for each language pkg manager

<davexunit>for each one that I'm personally interested in, yeah.

<davexunit>I want to to make it as easy as possible to use only Guix.

<tennix>and some languages have more than one pakcage managers, python of course

<davexunit>yenda-: icedtea6 and icedtea7 are the ones I think.

<davexunit>the standard output should have the jvm, and the 'jdk' output has the jdk stuff.

<davexunit>'guix package -A icedtea'

<xentrac>C and Java are probably the worst languages in terms of package manager count

<davexunit>tennix: but all the data is hosted on pypi.python.org

<davexunit>all that matters to us is that there's an API that we can query to get metadata about packages

<davexunit>to greatly reduce the boilerplate needed to write new packages for those languages

<tennix>some languages like golang has no centeralized repos

<davexunit>yes, each language has its own quirks

<davexunit>Go, IMO, is one of the most nonsensical of them all.

<davexunit>from what I can tell, everyone just bundles all of their dependencies in their repo

<xentrac>Is that the nonsensical part?

<davexunit>and the resulting Go binaries are *always* statically linked

<tennix>haha, me too

<davexunit>both of those parts are problems.

<taylanub>I thought Go explicitly favors static linking.

<davexunit>taylanub: yes.

<davexunit>you have no choice but to statically link, AFAIK.

<xentrac>Yeah, 6g/8g doesn't have dynamic linking AFAIK

<xentrac>presumably gccgo does

<tennix>i remember that go support dynamic link now

<davexunit>knowing these things, I don't want to touch Go with a ten foot pole.

<davexunit>tennix: well that sounds promising, then.

<xentrac>yeah, it ran me out of disk space

<taylanub>well, static linking has its advantages...

<davexunit>yes, but the disadvantages are too great.

<xentrac>what should I move to a bigger disk in order to get the build to not fail? /gnu/store?

<davexunit>xentrac: yes

<davexunit>also, builds happen in /tmp

<xentrac>thanks!

<davexunit>so that should have enough space to handle large builds

<tennix>yes, when deploying applications, there's no dependency hell

<xentrac>real /tmp or chrooted /tmp?

<taylanub>davexunit: what disadvantages do you have in mind? (genuinely curious, I don't have an opinion on the matter yet)

<xentrac>am I going to be sad about storing my /gnu/store on an NTFS partition?

<davexunit>tennix: so rather than fixing the problem, peopele take the worst possible approach from a security and maintenance perspective.

<xentrac>hmm, I think so, yes

<xentrac>since no hardlinks

<xentrac>I guess I'll create a 10GB loop-mounted ext4fs on my ntfs, sigh

<yenda->I'm a bit confused about the way nix packages leiningen https://github.com/NixOS/nixpkgs/blob/0761f81da71fc6a940c7f51129b6c7717db78e87/pkgs/development/tools/build-managers/leiningen/default.nix

<davexunit>yeah we use both hard and symbolic links

<yenda->they have src and jarsrc, do we have that too ?

<_`_>taylanub: static linking breaks aslr I think

<tennix>because disk is getting cheaper and network faster now, developers prefer statically links instead of dealing with complicated dependencies

<davexunit>and users and admins suffer.

<tennix>i don't think so

<davexunit>because now they have N versions of a library that has been discovered to contain a vulnerability, and they are now dependent upon the maintainers of *each* application that statically linked that library to update their application.

<davexunit>and even discovering which applications statically link a compromised library can be difficult.

<tennix>oh, in that sense, it is

<davexunit>Guix solves the issue of wanting to use whatever version of a dependency you want without clashing with the rest of the system

<davexunit>*and* without resorting to static linking

<yenda->can we have more than one source ?

<davexunit>yenda-: yes

<davexunit>sorry, I'm not too familiar with the clojure stuff

<davexunit>and Nix language things

<davexunit>but yeah, you can have multiple sources

<davexunit>though I've never used that

<davexunit>there should be an example of two around, though.

<yenda->I'm not familiar either I would usually just install the leiningen package :D

<yenda->worst case scenario I'll go on #emacs and ask technomancy for help :D

<davexunit>hehe

<yenda->do you know what the syntax would look like ?

<davexunit>a list of <origin> objects

<tennix>i'm just trying to build guix on mac

<yenda->^ an hero

<yenda->how is it going ?

<tennix>getgrouplist function seems not compatible

<xentrac>okay, this is not okay

<xentrac>guix pull: error: build failed: `/gnu/store' is not a directory

<xentrac>: user@debian:~/pkgs/guix-0.8.1; ls -Ldl /gnu/store

<xentrac>drwxrwxr-t 40 root guix-builder 49152 Aug 7 12:56 /gnu/store

<xentrac>it's a symlink to a directory though!

<xentrac>I guess I can mount the partition directly there...

<davexunit>xentrac: I don't think it can be a symlink

<taylanub>xentrac: maybe file a bug report, if you're sure it links to a valid directory, e.g. if you can run "ls /gnu/store" just fine

<xentrac>davexunit: apparently not

<taylanub>or maybe it's explicitly disallowed?

<davexunit>for technical reasons around how build environments are constructed

<xentrac>taylanub: well, you can see that it does above, no?

<taylanub>ok

<davexunit>I don't know if a /gnu/store that is a symlink would play nice with the bind mounts that need to be done in the build container

<xentrac>davexunit: oh, it's not just an oversight?

<davexunit>I'm not certain.

<davexunit>I'd report to bug-guix@gnu.org

<davexunit>and someone who knows will either fix it or confirm that it isn't a bug

<taylanub>and maybe add that it would be nice to have the error message mention the limitation, if it's an intentional limitation

<yenda->davexunit: so (cons* (origin...) (origin...)) ?

<davexunit>'list'

<davexunit>your code would produce a pair of origins

<davexunit>(origin . origin)

<davexunit>which is not a list

<xentrac>emailed, davexunit

<davexunit>thanks

<xentrac>taylanub: that's a good idea; too bad I didn't see your comment before emailing

<xentrac>do you think 10GB will be enough?

<xentrac>hmm, apparently it's going to recompile gcc again because the last guix pull ran out of disk space while recompiling tar

<xentrac>that's a little annoying

<taylanub>you're building everything from source? :/

<xentrac>aye

<taylanub>any particular reason?

<xentrac>I like building things from source

<taylanub>ok :D

<davexunit>look, guix supports a diverse userbase! ;)

<xentrac>I'm not building *everything* from source actually

<taylanub>FWIW my /gnu/store is 5 GB already. I could say I have a moderate amount of stuff installed.

<xentrac>davexunit: even insane people!

<xentrac>thanks, taylanub!

<davexunit>building everything from source is perfectly reasonable.

<davexunit>it's an important use-case for us.

<davexunit>no single point of trust.

<xentrac>it's still using the five bootstrap binaries though

<davexunit>well of course

<davexunit>there's no getting around that

<xentrac>couldn't it use tar and xz from my Debian system?

<davexunit>that would be non-deterministic

<davexunit>it wouldn't solve anything

<xentrac>only the first time

<xentrac>I mean, you could use the three-stage GCC bootstrapping process

<taylanub>IIRC there was a plan to create fixed-point bootstrap binaries (and I have a vague idea of what that means and how it solves the trust issue but don't expect me to be able to explain it...)

<xentrac>it's already using the kernel from my Debian system

<davexunit>yes, that's one impurity.

<xentrac>it doesn't completely solve the trust issue without diverse double-compiling

<xentrac>but it's progress

<davexunit>we don't claim to solve the trust issue.

<davexunit>but there is a section in the manual about computing a fixed point

<xentrac>fixed-point bootstrap binaries are binaries that don't change when you use them to build themselves

<davexunit>but anyway, the point is that *everyone* use the *exact* same bootstrap binaries.

<davexunit>so that we can achieve bit identical builds

<xentrac>right

<xentrac>okay, I'm going off to go see the addicts. if this build runs out of space I'm going to be sad, you guys :)

<tennix>mac has getgrouplist(const char *name, int basegid, int *groups, int *ngroups)

<tennix>while linux uses gid_t which is unsigned int

<tennix>can't convert unsigned int* to int*, that's the problem

<xentrac>hmm, it failed again in GCC because /tmp was full

<xentrac>after 13'

<xentrac>(so maybe it was actually gcc that failed last time?)

<xentrac>so, now I have 7.7GB available in /tmp, which will hopefully be enough

<yenda->davexunit: it looks like source doesn't like to be fed a list of origins

<davexunit>yenda-: there is some way to do it.

<davexunit>look at libreoffice

<davexunit>that might have something, IIRC

<yenda->davexunit: libreoffice itslef has a tarball in its inputs

<yenda->which is defined above and contains an origin only

<davexunit>oh okay

<davexunit>maybe that's what I was thinking of and you can't include multiple sources.

<davexunit>I don't have time to look into it.

<davexunit>allowing only a single source tarball makes sense to me

<xentrac>hmm, actually it seems like I'm having a reproducibility failure already:

<xentrac>Comparing stages 2 and 3

<xentrac>warning: gcc/cc1-checksum.o differs

<xentrac>warning: gcc/cc1plus-checksum.o differs

<tennix>Oops, it's almost 1 o'clock in the morning

<xentrac>are you in China?

<xentrac>but it seems like Guix is proceeding anyway

<yenda->any idea how i could apply this nix patch to the source ?

<yenda-> https://github.com/NixOS/nixpkgs/blob/0761f81da71fc6a940c7f51129b6c7717db78e87/pkgs/development/tools/build-managers/leiningen/lein-fix-jar-path.patch

<xentrac>with patch, I suppose

<paroneayea>davexunit: https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/ get that container stuff polished so I can start running browsers in containers! ;)

<xentrac>but to what file?

<davexunit>yenda-: <origin> objects have a 'patches' field

<davexunit>see other examples in gnu/packages/

<yenda->davexunit: but when I put it there it says it's trash

<yenda->"Only garbage was found in the patch input.

<yenda->source is under 'bultitude'"

<davexunit>not familiar with that error message

<davexunit>either the patch doesn't apply, or it can't find the file

<davexunit>or something like that

<yenda->right, if forgot to add the patch in gnu-system

<yenda->it still says it's garbage, I wonder if it's because the patch doesn't look like a git patch

<yenda->you can't import nixpackage with guix without installing nix ?

<yenda->well nvm I noticed its packaged, awesome

<davexunit>paroneayea: yeahhhh that's not good

<davexunit>mark_weaver: have you seen this? https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

<sprang>this might be a naive question: why is the input hash a prefix rather than a suffix? I know this was inherited from nix.

<davexunit>paroneayea: I just turned icecat off for now. maybe I should disable JS until it is fixed.

<davexunit>sprang: I'm not sure.

<yenda>I tried to patch linux-libre but the build failed and I don't understand the error http://paste.lisp.org/display/153215

<davexunit>yenda: the patch is invalid for that version of the linux-libre source

<yenda>but we are at 4.1.4 just like the patch

<davexunit>are you apply to apply that patch using the 'patch' tool manually?

<davexunit>the error is clear: the patch doesn't apply.

<yenda>is there some guix specific changes to the kernel ?

<yenda>davexunit: what do you mean ? Currently i added the patch to the package definition

<yenda>davexunit: ok I compared the patch to the source and some off the changes were already applied hence the error. I got a better one to try out from jxself

<davexunit>yenda: nice!

<yenda>While the kernel recompiles I have other questions :)

<yenda>I'm trying to import package definition from nix with guix import

<yenda>I installed nix with guix, downloaded nix packages repo and still I can't get it to work

<davexunit>I haven't used that importer.

<davexunit>what error do you see?

<yenda>what is needed exactly to be able to import from nix ? this would deserve a more complete documentation

<davexunit>I have no idea.

<davexunit>I didn't write it, nor have I used it.

<davexunit>and I'm not in a position to setup nix and nikpkgs

<yenda>I'm asking to anyone who would have make it work, it would actually be of great help to have it easely usable because they have tons of packages

<davexunit>ludovic wrote it and is honestly probably the only person that has used it.

<yenda>The error I get is Nix database directory ‘/nix/var/nix/db’ is not writable: No such file or directory

<davexunit>does that file exist?

<davexunit>you must be missing some nix setup

<yenda>exist where ? not in /

<yenda>I just did guix package -i nix

<davexunit>you still have to setup nix

<davexunit>nix has a daemon that needs to be configured and started, like guix.

<yenda>and you need to create a nixbld group

<yenda>I suppose you do that by adding it to the system configuration and doing system reconfigure ?

<davexunit>yeah

<yenda>well I hope it will work. I'll do that after the kernel patching is done

<davexunit>create the group and do whatever else you have to do to setup nix.

<davexunit>it would be cool to have a nix-service pre-built for folks to use :)

<yenda>davexunit: do you have an exemple of how to add a group ?

<davexunit>(user-group (name "foobar"))

<davexunit>in your OS config:

<davexunit>(operating-system ... (groups (cons (user-group (name "foobar")) %base-groups)))

<davexunit>you'll want to cons extra groups onto %base-groups, which includes a bunch of system groups

IRC channel logs

2015-08-07.log