IRC channel logs
2016-08-29.log
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". <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>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>from the proceeding with the install section of the guix documentation <twotwenty>all the commands are lost in the running profile <ng0>icecat ff 45 beta is out for testing upstream :) <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 <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 <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 ? <jmd>Not even a heuristic ? <jmd>Now I wonder how I could download those sources into my /gnu/store ? <civodul>jmd: guix build -S `guix package -A | cut -f1` <efraim>otherwise it backtraces on #:source? #f <civodul>though that should be mostly equivalent if you consider all the packages <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. <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? <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. <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 :) <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 <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 <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 127.0.0.1 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>maybe I've been doing it wrong all the years, but I have a 127.0.0.1 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 <jmd>ng0: Some services break if the dns for "localhost" does not resolve exactly to "127.0.0.1" <jmd>similarly, reverse dns for 127.0.0.1 must come back as "localhost". <jmd>Otherwise - bad things can happen. <ng0>well i add localhost after 127.0.0.1 / ::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 127.0.0.1 .. which is beleriand.n0.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>$static-ip domain.name <jmd>I'm looking at what other oses do. I think a common option is to have <jmd>127.0.0.2 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" ? <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>/tmp/guix-build-praat-6.0.19-1.51c7b7b.drv-4/source/praat <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 <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 <ng0>then try using instal-file... like in (install-file lispf4 bin) <ng0>then try using instal-file... like in (install-file "lispf4" bin) <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 <ng0>try changing copy-file to install-file <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>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? <ng0>OSS? Isn't this deprecated for a long time? <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>Maybe it is something that can be set with pkg-config? <ng0>you can try that first of course <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. <ng0>it was also about Gentoo running Guix / Nix instead of GuixSD/NixOS because the systems are not yet 100% reproducible <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>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>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>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 <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>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>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 <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>C++! (never thought I'd be happy about this) <davexunit>GPLv3 replacement for something like Dropbox <davexunit>and peer-to-peer rather than needing a centralized storage system <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. <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 ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.27.1.tar.bz2 - ? <malthe>is it possible to provide a mirror? <civodul>malthe: did you disable substitutes? <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>fun, someone posted an sshd service a while back <efraim>who is doing the kde packaging? they actually know what they're doing, I was just seeing what built :) <davexunit>always been exciting, but the velocity now is great <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. <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 <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? <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 :) <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 <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. <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>or rather that the problem is not actually a problem. <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 <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. <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>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 <OrangeShark>it seems like most computing devices are moving away from that model with things like app stores <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>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 <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: paste.lisp.org won't block Tor users. <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? <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 <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 <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 <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>you upgraded your profile or did other installations/removals <davexunit>you deleted the generation of the profile that had the guile that you built guix with <jmd>I think your guess is right. <jmd>I will know better than to run gc in the future. <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 <jmd>davexunit: So guix system reconfigure /etc/config.scm ; reboot didn't fix the problem. What do you suggest? <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 <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? <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>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>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>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 <davexunit>note that the new guix will surely produce a different hash than the old guix <efraim>isn't that guix build foo --sources=transitive? <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>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>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>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 llvm.org/bugs to browse open bug tickets. silly. <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>istr putting arch ids in comments towards the end of files... dark, dark days <efraim>oh more fun, jsoncpp uses cmake build system, can't be a cmake input <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