IRC channel logs


back to list of logs

<roelj>Is there a way to detect all places where profiles reside for the current user?
<jmd>roelj: ls /var/guix/profiles/per-user/$USER
<roelj>jmd: What if the user creates extra profiles with --profile=/some/custom/directory?
<jmd>Well if you consider those to be the user's profile, the the answer to your question is probably "no".
<roelj>Right. Thanks
<jmd>But I may be wrong about that - perhaps the gc has some way of finding out ...
<catonano>ng0: ehy how did it go with your attempt to obtain a core dump from the gnunet build ? I was away and got back a while ago
<kyamashita>Hello to all!
<kyamashita>Has anyone here had problems getting GuixSD to install on their machine? Something to the tune of "waiting for 'my-root' to appear" when booting?
<brendyn>This package uses ` install -Dm755' insead of `make install' How do a implement that in arguments?
<twotwenty>I am trying to install guixsd on a old computer and as soon as I use the command
<twotwenty>"herd start cow-store /mnt"
<twotwenty>from the proceeding with the install section of the guix documentation
<twotwenty>all the commands are lost in the running profile
<twotwenty>and cant even use ls or guix commands
<twotwenty>its like the path is lost
<ng0>icecat ff 45 beta is out for testing upstream :)
<civodul>Hello Guix!
<jmd>civodul: Hi
<efraim>civodul: do you want to try setting gcc-6.2.0 as default GCC on core-updates and see if it works on arm?
<efraim>Seems like the best option to dealing with GCC 4.9.4 and 5.3.0
<ng0>now that we have musl, i started working on packaging uclibc-ng.. so when that's done we have the major libcs out there
<civodul>efraim: why not, would you like to try? :-)
<civodul>that gcc bootstrapping issue on ARM is intimidating
<ng0>are hydra's build structure/machines cross-compiling or compiling native only?
<efraim>civodul: I can push the commit to change the default toolchain but I can't make hydra build
<efraim>I also haven't signed up for an arm vps yet :)
<civodul>efraim: if you have an ARM machine it'd be best to test it locally first
<civodul>ah :-)
<efraim>One of these days I'll get around to doing it
<civodul>i think we should try locally, somehow
<brendyn>Hi civodul, may I bother you with a question that is probably in the manual but I can't see it: The package I'm definion doesn't have a `make install' phase, rather it just uses install -Dm755..., how can I implement that in Guix?
<ng0>you can use system* for that
<ng0>grep for something like replace 'install
<brendyn>ok let me see
<ng0>(zero? (system* install -Dm77)) inside the replace phase.. something like that
<ng0>of course "" everywhere.. my client ignores " withput escape
<brendyn>Righto, I have to learn these procedures
<brendyn>I'm kinda learning Scheme, Guile, Guix, and emacs all at the same time
<efraim>scaleway is out of arm servers atm :(
<jmd>Is there a way of telling how much disk space is occupied by *sources* on hydra ?
<civodul>jmd: not really
<jmd>Not even a heuristic ?
<efraim>rough guestimate was ~75 GB?
<jmd>That's not too bad.
<efraim>runabove has armv8 machines
<jmd>Now I wonder how I could download those sources into my /gnu/store ?
<civodul>jmd: guix build -S `guix package -A | cut -f1`
<civodul>should mostly work :-)
<efraim>not --sources=transitive?
<civodul>even, yes
<efraim>otherwise it backtraces on #:source? #f
<civodul>though that should be mostly equivalent if you consider all the packages
<efraim>like texlive
<civodul>interesting way to work around the bug :-)
<jmd>Now the source derivations occupy a lot of disk, but are not often accessed. Wheras, the build derivations are frequently accessed. I wonder if it would be possible to have them on different disks?
<ng0>make... -r, --no-builtin-rules Disable the built-in implicit rules. what does this do if an application sets this?
<ng0>I suspect it ignores everything I try to pass as makeflags, right?
<brendyn>guix refresh is extremely slow and dies after downloading a few package definitions. slowly making progress...
<ng0>what do you run guix refresh for?
<ng0>bah. stupid question probably, but as musl seems to use 'musl-gcc', will the CC for building with uclibc-ng be CC=uclibc-gcc ? sinit (sample package I use) failed.
<ng0>failed for another reason. nvm
<jmd>ng0: No. make -r Disables implicit rules hard coded in make itself.
<jmd>Such as %.o: %c
<brendyn>Hmm, there don't seem to be any other packages that use insall -Dm755, that seems to indicate it's not the right solution
<jmd>brendyn: What are you trying to do?
<brendyn>jmd: The mundane task of installing a file
<brendyn>This program is simply one single binary once compiled
<brendyn>so I need to (replace 'install ... with the appropriate procedure to put it in guix store
<jmd>So the binary needs to be copied to (assoc-ref %outputs "out") "/bin"
<brendyn>is % needed? The "cereal" package doesn't have that
<jmd>I think it is needed, yes.
<ng0>can you post the package?
<brendyn>bin or usr/bin ?
<ng0>I had to install lispf4 manually.. it's in lisp.scm
<ng0>maybe that gives you some clue
<brendyn>after the (add-before ... I'm adding a (replace 'install
<alezost>brendyn: cereal's 'install' phase have 'outputs' key. If you do the same, then % is not needed, but if it is not inside a phase (in #:make-flags, for example, as it is done in 'btar' package), then % is needed
<brendyn>Ok I'm unfamiliar with such things. No idea which way I should do it
<jmd>brendyn: Have a look in bioinformatics.scm
<jmd>In the package "couger" there is a similar hack.
<ng0>just a question, what's in the commit that can not be used?
<brendyn>Well I didn't realise that file existed, haha
<brendyn>I will change the package to use that
<ng0>okay.. fixing up the build process is priority, you could change the source afterwards :)
<brendyn>Nearly finished I think
<ng0>What is so bad about defining upstream name when the name differs?
<alezost>ng0: it's not a problem, it's just that we don't do this for other packages
<ng0>also, can someone give me input on as I just realized I started packaging uclibc-ng because I have 0 clue on how to finish my git-service?
<brendyn>So the binary file compile is not going to be in the source directory as if I'd done it manually?
<ng0>thanks for reviewing the emacs packages alezost, i'll update them later today
<brendyn>This results in "praat" file not found :
<ng0>woah... first bitrot in my music archive after almost 20 years :/
<alezost>ng0: sure; about git-service: I don't have a clue on your VM question. But IIUC the git daemon is running, right? Then what's the problem? Can you test it without VM?
<alezost>brendyn: I think it's from 'copy-file': "praat" file is probably not in the root source directory
<ng0>no. because my system is not setup like that and probably never will be. That's why I need the qemu ports-forwarding
<brendyn>That's where it is when I compile it manually
<brendyn>I used -K so I should be able to investigate?
<ng0>the service is running, I only need to test a real life situation.. somehow
<alezost>brendyn: I think so, it is somewhere in /tmp
<ng0>if someone feels brave I can post an updated patch
<alezost>ng0: I've never used git daemon, and I don't have a wish to learn how to do it :-) But sure, please send a patch; if there will be no comments, I think it can be just pushed since the daemon is running
<alezost>sooner or later someone will try it and complain if it's not working properly, ISTR we have a couple of not-working services (network manager, maybe, I'm not sure)
<ng0>well it is rather easy to use. so damaged use will be visible early.
<ng0>how does one use network manager in guixsd? I've tried just adding it, but it conflicts with desktop-services
<alezost>ng0: I think it conflicts because %desktop-services already contain another service providing 'networking' (wicd)
<brendyn>ok so it's at /tmp/guix-build-praat-6.0.19-1.51c7b7b.drv-4/source/praat
<ng0>brendyn: but that's not a path you use in the package.
<alezost>ng0: so you need to delete 'wicd-service' at first, but actually I'm not sure if network manager is in a working shape
<brendyn>Yeah, what is the proper way to copy that file to $out/bin/
<jmd>I think gnu/system.scm is wrong where it dumps host-name in the entry in /etc/hosts.
<ng0>i'm not sure but try removing the trailing /
<brendyn>It makes me anxious that I'm trying to do something so trivial but it seems I'm doing it differently to every other package >.>
<ng0>why jmd?
<ng0>maybe I've been doing it wrong all the years, but I have a entry on all the hosts in /etc/hosts followed by the domain name
<ng0>and one for the static ip
<ng0>no, you're doing it good brendyn. that's nothing unusual.
<brendyn>I'm looking at packages in bioinformatics.scm and the look the same as mine
<brendyn>they just copy-file "file" ...
<brendyn>Maybe I need mkdir-p
<jmd>ng0: Some services break if the dns for "localhost" does not resolve exactly to ""
<jmd>similarly, reverse dns for must come back as "localhost".
<jmd>Otherwise - bad things can happen.
<ng0>well i add localhost after / ::1 and then the domain name + aliases
<jmd>ng0: and what do you get if you type "hostname" ?
<ng0>how should this be solved in guix then in your opinion?
<ng0>on one of the hosts, i get the first name which is defined after .. which is in that case
<jmd>then your system is misconfigured. What do you get if you type "hostname -f" ?
<brendyn>I see the difference. These other packages are just taking files out of the source directory
<ng0>localhost is the last name in a chain of names.
<ng0>i find system administration annoying and boring, so that might be wrong but it works
<jmd>It'll work for *some* services. Kerberos will definitely break on your system however. I think postgres has issues too. - some other services probably.
<ng0>what is the correct way then?
<ng0> localhost
<ng0>::1 localhost
<jmd>I'm looking at what other oses do. I think a common option is to have
<jmd> myhost-name.mydomain myhost-name
<ng0>i can look at my nixos and gentoo later.
<jmd>ng0: also, what do you get if you type "uname -n" ?
<ng0>same value
<jmd> ?
<jmd>Yeah that's going to cause networking issues.
<ng0> /me shrugs. works for me.
<jmd>Lots of things work for me too, but it doesn't make them correct.
<ng0>this was not guixsd btw.
<ng0>for guix one of the commands returns loclahost
<brendyn>Ok so I'm still completely stumped about how to refer to the build dir.
<ng0>look at the failed build dir, where is the binary located in there?
<brendyn>I cannot find in the manual where to refer to this location
<ng0>praat is a dir or a binary?
<brendyn>maybe the solution is on guix build utils
<ng0>that's because this is the build location... /source/ is '.' at the time of building
<jmd>Usually the build dir is the current dir.
<ng0>do you have some error messages for us on what fails?
<brendyn>ERROR: In procedure copy-file: No such file or directory
<ng0>did you change the package after last time you pasted it?
<jmd>put in a (system "ls -l")
<ng0>isn't let* wrong when there is only one let?
<ng0>sorry, had the old paste
<ng0>you have a syntax error
<ng0>(target string-append out /bin)) must be (target (string-append out /bin))
<ng0>just imagine i put in " because my echo to the out i write irc to removes them when it is not escaped ;)
<brendyn>Ok, it'll take a few minutes to compile...
<ng0>I see some more corrections, but they are not influencing the build.
<brendyn>ERROR: In procedure copy-file: Is a directory
<brendyn>I guess I need to append /praat ?
<ng0>if something is in inputs and it is not only needed in build, you do not need it in native-inputs.
<ng0>try adding a (mkdir-p (string-append out /bin) or something
<brendyn>I already have that
<ng0>then try using instal-file... like in (install-file lispf4 bin)
<ng0>then try using instal-file... like in (install-file "lispf4" bin)
<ng0>damn you fifo
<brendyn>Ok I'm still trying to grock inputs and native-inputs
<ng0>no stress.. it's difficult to get it all right at first :)
<brendyn>"The distinction between native-inputs and inputs is necessary when considering cross-compilation. When cross-compiling, dependencies listed in inputs are built for the target architecture; conversely, dependencies listed in native-inputs are built for the architecture of the build machine. "
<brendyn>It's bothering me that I haven't specified anything at all about architecture
<ng0>usually you don't.. you either know it, can read up on it or see a failed build on hydra and adjust accordingly. the default is to not specify anything architecture specific and assume that it just works
<brendyn>So what do I need to change?
<ng0>try changing copy-file to install-file
<brendyn>I mean with the inputs
<brendyn>I can't understand your sentence.
<ng0>i assume.. not knowing about praat.. that you can remove the gtk in native-inputs and also the other duplication on native-inputs
<brendyn>@ build-succeeded /gnu/store/a94gfy9amps6d68ypp61y00k70f0qb57-praat-6.0.19-1.51c7b7b.drv -
<brendyn>ACTION hugs ng0
<ng0>yw :)
<brendyn>But the work is not over! I should be able to fix the source to be the tarball
<ng0>when you send a patch to the list later today it's easier for me to comment. I have to make some changes now myself on pakcages
<brendyn>This still seems useful though, since it is essentially a praat-git package
<brendyn>ng0: Are you still working on gnunet-fs?
<ng0>it's a long road to the top.. it will probably come after getting psyced on guix etc.. there are multiple things I'm working on. understanding guix services is not so easy as OpenRC sadly.
<ng0>i also try to apply some of the things I learn and package to Nix (packaging and running process of everything psyced/gnunet/secushare), sometimes it would be better if I could just split myself.
<ng0>i just realized this was no clear answer.. yes i do.
<brendyn>Currently each package defines how to download a package. Would it be better to define arbitrary download methods so that the user can select which one?
<ng0>okay, I will make the git-service a bit nicer, add some more explanations etc and than I will send the patch, alezost
<brendyn>Hmm, praat works fine, but tries to use OSS by default. If I set it to ALSA in the preferences it works, but this should be default. I guess I would want to make a patch?
<brendyn>Or also upstream to do it?
<ng0>OSS? Isn't this deprecated for a long time?
<brendyn>Some things refuse to die
<ng0>Can you patch it with the substitute* function in the package? And fixing upstream sounds like a good idea
<brendyn>Well, there are a zillion files to look through. I'll see what I can do
<ng0>If it is no major blocker, you can send the package in, maybe provide a comment in the file which points out that bug/feature, and fix the OSS->ALSA later
<brendyn>It isn't a problem really, just makes the program a little ugly
<brendyn>Audio sucks enough as it is
<brendyn>Maybe it is something that can be set with pkg-config?
<ng0>you can try that first of course
<brendyn>Actually it is "ALSA via PortAudio"
<efraim>linux-pam-1.3.0 broke shishi (a dependant of cmake) on core-updates. I got it worked out
<efraim>I should probably file a bug upstream with shishi
<rekado_>I'd like to make the CRAN importer more robust. I see that other importers don't print a backtrace when you try to import a package that doesn't exist, but the CRAN (and bioconductor) importers both do.
<rekado_>at what point are we supposed to catch download failures?
<rekado_>my instincts tell me: "where they happen", i.e. wrapping http-fetch
<rekado_>but other importers don't seem to do this.
<rekado_>also: I'd like to have this all wrapped in an Either monad, so that we don't need to take care of these things.
<rekado_>I could wrap the body of "fetch-description" in false-if-exception, but that seems like an application of the diaper anti-pattern.
<ng0>There is a question I want to answer in plain english for a readme file for the part which describes the guix ebuild. Is it nonsense to compile Guix instead of to just use the build binaries? Bootstrapping is explained, but the question I got from someone was more about security and reproducibility issues.
<davexunit>ng0: I don't think it's nonsense. I mean, Guix itself has Guix packages that compile Guix.
<roelj>If you want to have any guarantee that the code you can see corresponds to the binary that you run, then it makes sense to compile it yourself.
<davexunit>yeah, and we certainly encourage that. :)
<ng0>it was also about Gentoo running Guix / Nix instead of GuixSD/NixOS because the systems are not yet 100% reproducible
<davexunit>I don't follow this part.
<davexunit>could you elaborate/
<roelj>Does "the systems" refer to Gentoo here?
<ng0>it's not my own question.. the persons understanding is that Guix and Nix are not yet 100% reproducible and require some however insecure / not reproducible parts. no, the systems means NixOS/GuixSD in this case
<davexunit>gnu guix is discussed here at around the 45 minute mark:
<davexunit>the person does a pretty good explaining guix
<ng0>ok, thanks i will pass it on
<davexunit>ng0: sorry this wasn't directly about your question
<davexunit>I just found this and was sharing with everyone
<davexunit>sorry for the confusion
<davexunit>ng0: that particular question doesn't make a lot of sense to me. Gentoo isn't 100% reproducible either
<davexunit>so the security implications of that seem moot
<davexunit>guix provides much more tools for reproducibility
<ng0>yeah, not my reasoning
<davexunit>seems that there's some misunderstanding
<davexunit>can probably be cleared up if the question can be clarified more
<ng0>the person is one of those rejecting irc, so I pass questions and answer on
<ng0>I'll hand over more questions soon :)
<ng0>civodul: I like the better -> now slide :D
<davexunit>can't wait to see the video that goes with those slides
<rekado_>what slides are you refering to?
<ng0>ghm slide
<rekado_>do you have a URL?
<davexunit>found on
<ng0>is this clearer? 'of course gentoo isnt reproducible, that's why it isn't even distributed with binaries. guix and nix however provide binaries of which most are reproducible, but not all . we would like to recompile those that cannot be rebuilt and would therefore make a good place for backdoors.'
<davexunit>ng0: this person is very confused.
<davexunit>they misunderstand what reproducible builds are.
<davexunit>gentoo doesn't have a guarantee that builds are bit-identical on different machines.
<davexunit>in fact, pretty much every user has different builds because of use flags.
<davexunit>I think it will take some careful discussion to clear up this confusion.
<rekado_>what do you think about making the recursive importer try different archives? Bioconductor packages often depend on plain CRAN packages.
<rekado_>when starting the recursive importer on a bioconductor package it often fails midway when it encounters a dependency that's not on Bioconductor but on CRAN.
<rekado_>at that point I'd want the importer to try the other archive.
<davexunit>rekado_: sounds fine
<davexunit>sounds like what users would expect
<davexunit>oooh, a new version of mesa may allow us to use opengl 4.5 on intel graphics chips
<civodul>davexunit: the comments on this video are pretty good indeed
<davexunit>someone on this show has been following our project
<davexunit>so that's good!
<civodul>better than the LWN article, which was a bit Phoronixish this time ;-)
<davexunit>I'm actually still listening to the show, they've had some good commentary about other cool software
<davexunit>like this
<davexunit>has anyone tried it?
<davexunit>or packaged it? ;)
<davexunit>please don't be written in Go...
<davexunit>please don't be written in Go...
<davexunit>C++! (never thought I'd be happy about this)
<civodul>looks interesting
<davexunit>GPLv3 replacement for something like Dropbox
<davexunit>and peer-to-peer rather than needing a centralized storage system
<civodul>i'm a fan of Tahoe-LAFS
<davexunit>never tried that
<civodul>seems like the Right Thing to me
<davexunit>pretty ignorant in this space
<civodul>(apart from the language choice ;-))
<ng0>wasn't one of us based in/around berlin? maybe there's an event where a guix talk + such questions could be answered better. Passing on messages is not really productive or helpful.
<rekado_>I'm in Berlin.
<ng0> ' <-- is this procedure reproducible on computers with the same set of packages?'
<davexunit>anyone can run that, yes.
<davexunit>whether it's bit-reproducible is unknown
<davexunit>but that's really besides the point with this Gentoo thing
<davexunit>does gentoo have packages for any other package manager?
<davexunit>if you have node then you have npm, which will download unreproducible blobs, as will many other package managers.
<davexunit>so I don't see why Guix is targeted for not having solved the bit-reproducibility problem which no one has solved but we have made great progress towards.
<malthe>what to do if `guix` hangs trying to download - ?
<malthe>is it possible to provide a mirror?
<civodul>malthe: did you disable substitutes?
<civodul>this tarball is also available at
<malthe>civodul: nope - but maybe I need to specify an explicit connection timeout to "activate" substitutes?
<malthe>e.g. timeout=30 seconds, then it'll attempt a substitute instead
<civodul>no, substitutes are "at a higher level"
<davexunit>what's the best practice for packages that need Qt these days?
<davexunit>are there modular packages that I should use?
<ng0>rekado_, what's your position on giving a short introduction talk to guix somewhere in berlin (cbase? onionspace? onionspace is something where people are often) and solving afterward questions which go beyond what's currently covered in the documentation? I feel very sad for the misinterpretations of each others side I read now and refuse to continue to play 'stille post'
<civodul>davexunit: i think so
<civodul>efraim knows better :-)
<civodul>fun, someone posted an sshd service a while back
<davexunit>heh, noticed that overlap.
<efraim>who is doing the kde packaging? they actually know what they're doing, I was just seeing what built :)
<malthe>civodul: works, thx a bunch
<davexunit>guix sure is exciting these days.
<davexunit>always been exciting, but the velocity now is great
<bavier>civodul: welcome back!
<davexunit>isn't there some licensing issue with using openssl in GPL programs?
<kyamashita>davexunit: Yes. We had a conflict with openssl being required somehow by curl in GNU Octave.
<davexunit>kyamashita: ah okay. do you know of a good reference for this general problem?
<davexunit>I found a well-intentioned piece of software that is GPLv3 licensed but depends on openssl
<davexunit>so I would like to bring it to their attention so that they can fix it.
<kyamashita>This is the link that brought my attention to it:
<davexunit>kyamashita: thank you!
<kyamashita>You're welcome! :)
<davexunit>alright, reported the issue. hopefully they can swap in gnutls without much trouble.
<paroneay`>civodul: heh, I just commented on that overlap on-list
<paroneay`>I guess I can be ignored :)
<brendyn>Can we invent a format so people can publish their own software independently like you can on Windows?
<retroj>brendyn: guix package definitions already do that
<kyamashita>brendyn: Very good question. Guix, Nix, Snappy, Flatpak, Docker, etc. all try to address that problem differently.
<brendyn>What I want is for Guix to facilitate people publishing software independantly of caring about us who are posting package definitions to a single git repo
<civodul>anyone knows how to apply a send by "git send-email" but with a MIME attachment, from Gnus?
<brendyn>If a package requires a particular version of a program, won't it fail to for when a new version of that program comes out and the GNU package definition is updated?
<brendyn>fail to install*
<retroj>brendyn: a package can be installed from an arbitrary package definition - it doesn't have to be in guix's main repo. it's possible to distribute a package definition however you want to
<kyamashita>brendyn: Guix can do that! Just write your own definitions for the needed version and reference your code. Then publish the Guile code so other Guix users can use it.
<brendyn>So that requires duplicating a lot of package definitions. If a developer could rely on them being in Guix, then they could simply only publish the definition for their program
<brendyn>kyamashita: In my mind, I'm thinking of facilitating non-programmers using Guix without knowing it exists
<brendyn>I mean, what is the goal for GuixSD? World domination right?
<paroneayea>brendyn: world domination, for me, is a secondary goal for Guix :)
<paroneayea>someone else can be #1 and that's ok.
<kyamashita>LOL :p
<kyamashita>brendyn: So like a double-click-to-install sort of thing?
<paroneayea>as long as we're good enough for all guix users' needs, and free, then I think world domination will come :)
<brendyn>But I want to get Free Software into schools so kids can stop being given Windows
<brendyn>Triquel is kinda ok but not that exciting
<brendyn>paroneayea: You sound so careless?
<davexunit>brendyn: you are forgetting that the version of guix the user is running is a critical component to reproducing the package you made.
<davexunit>you seem to be proposing something where you don't have to care, but that's impossible.
<davexunit>builds can vary between guix versions even if (hyptothetically) not a single package recipe has changed
<brendyn>I just want to build an operating system that actually works
<davexunit>someone could change gnu-build-system or something.
<brendyn>Well I assume that will stabalise over time, right?
<davexunit>it's important that we continue to evolve these things
<davexunit>the interface might not change but the implementation may change, which would affect all builds.
<davexunit>my point is that it's a mistake to think about a package recipe as somehow isolated from the rest of guix.
<davexunit>it's all one big whole.
<OrangeShark>brendyn: are you asking maybe for some sort of stable set of package definitions?
<davexunit>if you want someone else to be able to build *exactly* what you built, they need to use the same guix.
<brendyn>I'm just scared that this is going to hinder scalability
<davexunit>it enables scalability because we can change any part of the system that we need to.
<brendyn>I don't want exactly the same thing at all, I just want it to work
<davexunit>the only way to be *sure* that it will work is to use the same guix
<davexunit>in practice, I have my own custom package recipes that tend to keep working as-is despite all of the changes in guix
<brendyn>I'm not being picky for myself, I'm planning to go talk to teachers and principals about installing GNU/Linux, so we need a solution. Parabola doesn't seem all that viable to build something end-user friendly, and trisquel 8 is off to a slow start
<davexunit>my point is there's no solution.
<davexunit>or rather that the problem is not actually a problem.
<brendyn>So we just give up and use Windows?
<paroneayea>brendyn: if you were deploying at a school
<paroneayea>you could very easily deploy the same thing to all users from a central location
<paroneayea>build it in one place, copy the closure over to all systems
<paroneayea>bam, you just rolled out an update
<davexunit>any large-scale deployment of software consists of homogenizing the software environment so that it's the same everywhere. guix would be no different.
<brendyn>That's what I'm thinking
<davexunit>the feature that we're currently missing is a large-scale deployment tool
<brendyn>Yes, but on Windows there is a core OS and then people go to Mozilla to find Firefox etc. That way it's open ended
<davexunit>so that we can scale up to managing more than a single machine at a time.
<davexunit>brendyn: that model is inherently broken.
<paroneayea>well, at the very least
<paroneayea>it's not guix :)
<davexunit>it contributes a good deal to the security issues on windows systems
<paroneayea>guix was designed for total reproducibility, and not one-click-binaries. If you want something like that, and you're not convinced of guix's goals
<paroneayea>there are other free distros out there
<brendyn>Yes it's terrible
<OrangeShark>it seems like most computing devices are moving away from that model with things like app stores
<davexunit>OrangeShark: moving away from what model?
<davexunit>"app stores" are essentially exactly what Windows has already been doing, just curated.
<OrangeShark>downloading software from a website, like going to mozilla to download firefox
<rekado_>I just explained the difference between Guix and flatpak to my boss.
<davexunit>android apps bundle all sorts of libraries, iOS is the same
<davexunit>you just don't go directly to the developer's website anymore.
<brendyn>So what do I recommend to a school to install today?
<davexunit>which is more user-friendly and potentially safer, but the technical issues remain.
<rekado_>Guix could also provide "runtime environments" on top of which other programs are built, ... but what's the point?
<davexunit>brendyn: guix is a little young for widespread adoption at schools
<brendyn>Yes but I was wondering if it would grow into something like that
<davexunit>it certainly can
<davexunit>we have most of the parts
<davexunit>but to maintain a large deployment you need a team of folks who are comfortable with the software, and not many are comfortable with guix.
<brendyn>Because I want to recommend schools to install Free Sofware and then send money towards the developers of the software they use
<kyamashita>brendyn: Free software is already usable in schools provided they have the resources to administer it. See
<kyamashita>Also take a look at
<kete>Just installed GuixSD—my normal user can log in but not into X. I had to make home dir and move /etc/skel files into it.
<retroj>kete: will you patebin your system configuration?
<kyamashita>retroj: kete: Just a heads up: won't block Tor users.
<paroneayea>hi kete!
<kete>hey paroneayea :)
<kete>thanks kyamashita
<kete>retroj, I needed to change the perms from root:root to kete:users. thanks
<kyamashita>kete: I pretty sure I've hit that installer bug, too. You didn't happen to use LUKS encryption, did you?
<retroj>kete: perms of what?
<kyamashita>retroj: If this is the bug I suspect, I would assume the /etc/skel files and kete's home dir that they were moved to.
<kete>kyamashita, yes, I did encrypt the home partition.
<kete>yes, ls -al /home/kete—everything was root:root because I made them after the installation.
<kete>I had the partition opened and mounted at /mnt/home during the installation, kyamashita
<kyamashita>kete: Yep. Sounds like the bug I had, too.
<kyamashita>If only I had the skill to fix it!
<catonano>I think this is relevant for those who ask why scheme rather than the Nix language ?
<davexunit>catonano: good find!
<catonano>davexunit: glad you like it ;-)
<civodul>indeed :-
<jmd>I was about to look at packaging bind.
<jmd>I wondered why nobody had, and now I know.
<jmd>I started to download the source a few minutes ago, and came back to see how is was going.
<jmd>By browser says: "9.2 MB / 17 EB 1082 months left"
<retroj>jmd: what do you attribute this to? other OSes have bind
<kyamashita>ACTION watches as jmd downloads the internet
<jmd>retroj: Guix is relatively young.
<retroj>jmd: i mean why do you think that this download isn't working?
<jmd>I think its some crappy proxy on their end or something.
<brendyn>I get this when I try using C-c . l in Emacs: ERROR: no code for module (guix monad-repl)
<davexunit>catonano: finally watching the talk. it's great.
<davexunit>paroneayea: I recommend the talk catonano posted above. lots of fun poked at Puppet and Ansible
<davexunit>jinja templates and all
<paroneayea>davexunit: ooh
<paroneayea>will look
<jmd>I'm getting this error: ~/guix [env]$ ./pre-inst-env guix build bind
<jmd>./pre-inst-env: /home/john/guix/scripts/guix: /gnu/store/r65nfyicmkr8pq2g608qjx2b6m3i9p8h-profile/bin/guile: bad interpreter: No such file or directory
<ng0>the gentoo package on bind reads like it's not easy
<jmd>ng0: Yeah I suspect you're right.
<davexunit>jmd: well, does /gnu/store/r65nfyicmkr8pq2g608qjx2b6m3i9p8h-profile/bin/guile exist?
<ng0>uclibc-ng also read like it's no walk in a park, i've got a quarter of a package with that already^^
<davexunit>my best is that you ran the garbage collector
<jmd>davexunit: I think you are right. Was that the wrong thing to do?
<davexunit>jmd: no, it just sounds like you need to re-configure
<jmd>I don't understand why reconfigure would be necessary after gc
<jmd>gc should only remove those things not in use.
<davexunit>how could guix know that you used it in a shebang in some file?
<davexunit>profiles, on the other hand, are registered as garbage collector roots and thus protected.
<davexunit>here's my guess about what happened:
<davexunit>you installed guile into your user profile
<davexunit>built guix
<davexunit>you upgraded your profile or did other installations/removals
<davexunit>and got a new guile
<davexunit>you deleted the generation of the profile that had the guile that you built guix with
<davexunit>you ran the gc
<jmd>I think your guess is right.
<jmd>I will know better than to run gc in the future.
<davexunit>no no no
<davexunit>that's not the point
<davexunit>the gc is a good thing, of course.
<davexunit>but you need to be aware of what is protected from the gc and what isn't
<jmd>Right. I suppose I need to think about that a little.
<davexunit>the configure script for guix searches $PATH for the absolute path to the guile binary
<davexunit>and uses that as the shebang for the guix script
<davexunit>so if you have a new guile now, simply running ./configure will detect it and write the new shebang
<davexunit>do you install guix dependencies in your profile or use 'guix environment guix'?
<davexunit>because 'guix environment' won't protect those packages from the gc
<jmd>Yes. I was using guix environment
<davexunit>that explains it then
<jmd>davexunit: So guix system reconfigure /etc/config.scm ; reboot didn't fix the problem. What do you suggest?
<davexunit>jmd: nooooooooooooooo
<davexunit>run the configure script!
<jmd>Oh that configure
<davexunit>rebuilding your system doesn't change the fact that you have a git repo that has a script with the wrong shebang in it
<ng0>nooo a texlive rebuild x.x
<ng0>buildmachine will be occupied so long
<jmd>davexunit: Right. I understand (I think)
<davexunit>in the future, I want to provide the option for 'guix environment' to register the profile it generates as a GC root
<davexunit>so the user can manage this a little better
<jmd>good idea
<ng0>the talk of tom hall is nice
<jmd>ng0: Maddog? I saw him talk many years ago. He's a very technically savvy person. But I don't think he really cares about free software.
<ng0>the video posted earlier
<ng0>how can I just retrieve the texlive-texmf sources and not build them, so that offloading later has them available?
<davexunit>ng0: guix build -S texlive-texmf
<ng0>oh, thanks
<ng0>apparently this doesn't work
<ng0>guix build: error: texlive-texmf: package not found for version 2016
<davexunit>sounds like you are adding a version specification
<ng0>even the one without didn't work
<davexunit>there is no package named texlive-texmf
<davexunit>I had assumed based on what you asked above that there was
<davexunit>perhaps it's a package object not publicly exported?
<ng0>Downloading ivf445...-texlive-texmf-2016 (3.94GiB installed)...
<davexunit>it's not exported
<davexunit>are you aware of how guile modules work?
<davexunit>and how guix determines the list of packages?
<davexunit>only publicly exported symbols in the (gnu packages ...) namespace are directly available for use at the CLI
<davexunit>'guix build' has a -e switch that you can use to evaluate an arbitrary Scheme expression that returns a package object
<davexunit>guix build -S -e '(@@ (gnu packages tex) texlive-texmf)'
<ng0>more or less yes. and I know that this is not kept on hydra for a reason. guess i wanted something which does not work for this - download source for easier build on the build machien which does not block the current machine
<davexunit>the '@@' macro allows you to reference a private variable within a module
<davexunit>the reason that texlive-texmf is private, IIRC, is so that users never accidentally install this package into their profile
<davexunit>I did that once, and it was a mistake :)
<davexunit>feature request: a switch for 'guix build' to download the source for a package and all of its dependencies, recursively.
<retroj>how would i go about installing an old version of a package?
<ng0>hm. i think what i do then is to exclude texlive from update and build it afterwards from source
<davexunit>retroj: using an old guix, or port an old recipe to a new guix
<retroj>ok, thanks
<davexunit>note that the new guix will surely produce a different hash than the old guix
<davexunit>so you're not building the exact same thing
<retroj>shouldn't be a problem
<efraim>isn't that guix build foo --sources=transitive?
<davexunit>efraim: !
<davexunit>you are so right
<efraim>don't forget --no-grafts
<davexunit>I love when the thing I'm thinking of is already implemented
<jmd>When running guix build, then build process has its own net namespace, right?
<ng0>i dislike that i can never offload the texlive builds
<davexunit>jmd: yes, this is how we disallow network access.
<jmd>davexunit: That's great.
<jmd>Now how can I become root in that namespace?
<davexunit>you can't
<davexunit>user namespaces are not currently used
<davexunit>when you configure the guix daemon you provide a pool of a unprivileged users for it to perform builds with
<davexunit>I think that using user namespaces in the future would be good.
<jmd>But if its in a namespace the builders need not be unprivileged. Provided they only have privileges over that namespace.
<davexunit>but without a user namespace that user is unprivileged
<davexunit>the guix daemon creates new namespaces since it runs as root and then drops privileges to one of the build users
<jmd>make check for bind needs to have alias addresses set on the loopback interface.
<davexunit>those tests would have to be disabled
<davexunit>we can imagine a world in which we use user namespaces and performing privileged actions on the loopback device would be possible
<davexunit>there are other things that I wish I had root in the container for, as well.
<jmd>It'd be great if we could do more than just imagine it.
<davexunit>but some things might be solvable without root privileges. like, perhaps /etc/hosts could be a file writable by the build user.
<davexunit>that should be possible.
<davexunit>could even be possible now, but I don't know.
<davexunit>but most likely they couldn't write outside their build and output directories.
<davexunit>our nginx build could be improved if the builder could create directories like /var/log/nginx
<ng0>fixing my way around that atm
<efraim>oh that would've been fun. I was going to add jsoncpp to cmake, but it hasn't maade its way from master to core-updates yet
<ng0>updated patch of git-service is out.. whoever feels like trying it
<bavier>glad there's other users of --sources=transitive :)
<efraim>it was great when my internet was out
<bavier>one needs an account on to browse open bug tickets. silly.
<paroneayea>what's up with ";;; foo.scm ends here" anyway
<paroneayea>like, I usually know I'm at the EOF..
<bavier>maybe for people who like to read program code with cat
<wingo>i think it's related to some old tool that ttn wrote
<wingo>not sure really
<wingo>istr putting arch ids in comments towards the end of files... dark, dark days
<wingo>i seem to recall
<efraim>oh more fun, jsoncpp uses cmake build system, can't be a cmake input
<efraim> as reference for submitting requests to change long long int to int64_t
<efraim>is there a use case for 128 bit integers?
<bavier>we can reduce the disk space of our llvm@3.8 build from 481M to 73M by building shared libs
<bavier>only one cmake flag and a small hack required
<bavier>majority of the savings in linked binaries, which llvm has a lot of
<efraim>edi (not packaged yet) can take llvm as an input to provide syntax hilighting, but it nearly doubled the closure size