IRC channel logs


back to list of 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
<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: <>
<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: <>
<alezost>If you are interested this is my config: <>
<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: <>
<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>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>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
<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>surely somewhere there's a directory full of old guix releases?
<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
<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>precompiled versions of them, I think
<davexunit>I think 2.0.9 is a "bootstrap binary"
<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:
<_`_>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:
<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 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.
<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>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>I'm actually on the verge of having basic user-accessible container support in guix.
<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> 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> 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
<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
<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
<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
<davexunit>this is where Guix comes in.
<xentrac>guix already has a balun for PyPI, right?
<davexunit>is balun a spanish word?
<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.
<tennix>oh, nearly all of the newly languages have their own package managers
<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
<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
<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
<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
<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?
<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
<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>your code would produce a pair of origins
<davexunit>(origin . origin)
<davexunit>which is not a list
<xentrac>emailed, davexunit
<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? :/
<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>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 ?
<xentrac>with patch, I suppose
<paroneayea>davexunit: 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?
<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
<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 ?
<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