<a_e>In my case, it does nothing. No error. <JeanLouis>guix package: error: mutt: extraneous argument <rain1>i've worked out the right environment to build this program in <rain1>but to build i have to cd into a subdir then use make -f <rain1>I've found an example of using make -f <rain1>but I don't know how I would put cding into a subdir in a package definition, anyone know? <bavier>rain1: use modify-phases to insert a phase that do a (chdir ...) <bavier>rain1: there are a lot of examples in gnu/packages/bioinformatics.scm <bavier>must be popular in that realm :) <rain1>I can't work out how ot put in the sourceforge link <rain1>yeah it bounces about 5 times <rain1>i'll just ask the guys to not use sf :) <JeanLouis>rain1: ok, and are you defining packages.scm? <JeanLouis>I would like to understand how to install package from file on the disk <Jookia>Woo with my hacking I got my fully encrypted LUKS+LVM Libreboot setup to only ask for a password *once* (at GRUB) to get to the Xfce desktop! <rain1>will that also apply to non libreboot? <francis7>Jookia, send a patch for libreboot docs saying how you did that <francis7>also, since this is probably guix, could you write a full disk encryption guide for guix with libreboot?>asn I understand it, suitsmeveryfine was/is also working on that, so you could work with that person too <suitsmeveryfine>As soon as Jookia's patch has been merged GuixSD should be fully compatible with encrypted / <Jookia>francis7: It's not possible for a while <Jookia>Basically FDE with Libreboot will need some MAJOR refactoring <rain1>I might try it out in qemu at some point then <Jookia>suitsmeveryfine: Absolutely not, it's terrible <Jookia>I'll do some more terrible hacks and put it up on the mailing list as a DONTMERGE <Jookia>Just so people can have something broken in the meantime <JeanLouis>Jookia: there shall be option to mount the system after boot too, as if anyone is searching laptop, like police or courts, they find encrypted disk, and this may have implications for the person. <Jookia>suitsmeveryfine: Yeah, but the patch needs to get 'working' FDE with bells and whistles actually breaks the API <Jookia>Actually, I could fix that so it's not breaking the API but still hacky <suitsmeveryfine>I guess there are other urgent problems with GuixSD that need attention <Jookia>Well, this is an 'urgent' problem for me <Jookia>But I can bandaid it for a while <Jookia>There's also EFI support, but I don't have an EFI machine. I suppose I could try to make some patches that would kind of work <rain1>I think once FDE is sorted guix will start to get a bunch of new users <JeanLouis>yes, that way, nobody can see in the system itself, that there is disk to be mounted. <JeanLouis>for example if login password is stolen, it still works, but they don't see files, as that was not mounted. <Jookia>I estimate to do 'proper' FDE, with LUKS, LVM, etc you'd need to refactor the way block devices are handled and also patch GRUB to allow unencrypted /boot <JeanLouis>if laptop is stolen or seized by the court -- and they see encrypted partititon, it makes implications for the owner <JeanLouis>if nobody see encrypted partition, one can safely provide password, enter, and see just plain normal files (as encrypted one was not mounted yet) <Jookia>JeanLouis: Deniable encryption is difficult, could you give a concrete use case? <rain1>I noticed a very funny service here <Jookia>Does anyone have an EFI system here? <suitsmeveryfine>Jookia: Yes, but I would only be able to test a live USB on it since it's not my own computer <Jookia>suitsmeveryfine: That's no good. :( <Jookia>suitsmeveryfine: Actually, it might be <Jookia>Can you reconfigure the live USB? <Jookia>Also can you boot in to it from legacy BIOS <rain1>should I install lsh as root rather than as user? <Jookia>rain1: Isn't it a service that goes in the system profile? <rain1>I was thinking of running this command: lsh-make-seed <rain1>maybe I don't need to even do that? <Jookia>That's cool, you can always test it. :) Do you have an existing Guix system? <Jookia>Ah cool! You could always just build a USB image using patches I send you <Jookia>Well, maybe something good to do would be to build some USBs <suitsmeveryfine>How hard would it be to create a USB installer that doesn't require an internet connection= <Jookia>What do you mean doesn't require an internet connection? Doesn't it just use it to pull? <Jookia>It should be able to install itself <suitsmeveryfine>I've never tried because the manual says that one of the first things you should do is to setup an internet connection <Jookia>Well, try it- you should be able to at least use a guix system to install itself. I think. <JeanLouis>Jookia:when system is stopped and asking for password, other users know there is something hidden. <suitsmeveryfine>I guess I should. Now it's getting too late though. Anyway: I'd be happy to try a USB installer that works on EFI and test patches for you Jookia. <Jookia>JeanLouis: Well, how else would you boot it? <rain1>how does one get a root terminal in guix? <suitsmeveryfine>Jookia: I've seen on the lists that other people have installed GuixSD on macbooks that don't run libreboot. Doesn't this mean that GuixSD already works with EFI boot firmware? <Jookia>suitsmeveryfine: Hmm, I'm not sure. <Jookia>rain1: You can't do su? What about sudo? <rain1>sudo lets me run one command but i want a root terminal session <Jookia>suitsmeveryfine: I'm guessing there's some BIOS support or they installed EFI manually <Jookia>I nearly have a HACK 'patch' ready so you too can live the dream and have full disk encryption with LVM+LUKS+Libreboot+one password <Jookia>suitsmeveryfine: Decrypting GRUB, autologin with SLIM if you want <suitsmeveryfine>Jookia: but I would still need to enter the same password twice, right? <Jookia>Once in libreboot's GRUB, then optionally at the login prompt <rain1>i found this problem: last: cannot open /var/log/wtmp: No such file or directory <rain1>what do you think? no way to see whose logging in on guix? ***samis is now known as CompanionCube
<Jookia>afk for a few hours. patch posted to mailing list (oops double post), outlines why it's a bad idea to use it (i'm probably actually not going to use it) <iyzsong>JeanLouis: in guixsd, neither, it's under /run/setuid-programs. a normal package (even root) install can't have setuid bits. <rain1>I think this, as root, is enough to solve the problem <rain1>I was thinking about the 'last' command <iyzsong>never mind, i reply a message without read the former discuss. <rain1>I did guix pull, then guix package -u <rain1>and then I reconfigured my system <rain1>but now when I tried to install one package, it seems like it's reinstalling every package <iyzsong>rain1: they're grafting (if no build happend to you) to fix security issues 'quickly'. <hyperreal>mark_weaver: I'm on Xfce and connected to the Internet, but for some reason I can't get the correct date and time. <hyperreal>It started at time zero for Unix, Dec 31, 1969. <lfam>hyperreal: Are you using libreboot? There was some change in the kernel that had that effect for libreboot users. I think that is the reason we have kept around version 4.1 of the linux-libre kernel: so those users don't have this clock issue <lfam>Can you check your hwclock? <hyperreal>I'm not sure how to check my hardware clock though <lfam>You can use `hwclock -r` <hyperreal>so what is the best way to resolve this? use kernel 4.1 or change my hardware clock (if possible)? <hyperreal>lfam: forgive my lack of knowledge about the hwclock command. I've been using Linux for 5 years and I don't recall ever needing that command, so I was unaware of it lol <hyperreal>but yes, the command output says Wed 31 Dec 1969, etc. <lfam>The bug report should help you figure out if this is your bug, and there is also a solution described at the end (use linux-libre 4.1) <lfam>I only learned about `hwclock` from that bug ;) <hyperreal>lfam: That bug report describes exactly my problom. I'm running GuixSD with Libreboot on a Thinkpad X200. <hyperreal>Thank you very much. I will downgrade to linux-libre 4.1 <paroneayea>hyperreal: it's easy, in your system config do this: <paroneayea>kernel-arguments will stop "guix system vm" from crashing your computer :) <paroneayea>hyperreal: so do "sudo system reconfigure your-file.scm" <hyperreal>by the way, paroneayea: In that bug report above, I noticed someone mentioned you're sharing your home directory with two different versions of gnome (one for Debian, one for Guix). I'd like to help out with getting gnome working on Guix. is there a recommended way to install it on GuixSD? I presume I'd have to include the gnome package module. Does it have a meta-package? <lfam>hyperreal: The name of the meta-package is 'gnome' <hyperreal>when i try to run guix system reconfigure /etc/config.scm, I get Unbound variable: linux-libre-4.1. I'm learning guile syntax as I go along. And I do have the linux package module included. <lfam>hyperreal: It works for me with this line in my system configuration: (kernel linux-libre-4.1). Perhaps you haven't updated your system with `guix pull` since linux-libre-4.1 was added? What does `guix package --show=linux-libre` offer? <hyperreal>lfam: guix package --show=linux-libre shows version 4.4.4 and 4.1.19 <lfam>hyperreal: That shouldn't be necessary if you have the 4.1 version printed out by --show <lfam>And, you did --show as root (since only root can reconfigure)? <hyperreal>lfam: I'm not sure why it's not working. It behaves as if the linux package module wasn't included, which it is. <lfam>So, the 4.1 version is definitely available to the root user? <hyperreal>lfam: Aha! No it is not. So I should run guix pull as root user? <lfam>This is one difference from other systems. Each user has their own list of available packages <lfam>It's a little strange when you are used to the other way. <hyperreal>lfam: so I am now using linux-libre-4.1. But ntpd still doesn't seem to work. <hyperreal>Were there any other steps after installing the kernel? <hyperreal>paroneayea: were there any other steps after installing linux-libre-4.1? ntpd still doesn't seem to work. <efraim>new version of nss but its a dependency of qt5 <efraim>bind-utils updated, also isc-dhcp, we're good now from those two CVEs <efraim>bind and isc-dhcp updated for bind's CVEs <efraim>almost filled up the coffee maker with baby formula <robsyme>Hi all. Another quick question about writing package definitions. I'm writing a definition for a tool that includes two binaries. One is a compiled C++ program and the other is a python script. When I include (native-inputs `(("python", python-2))), the hashbang in the script is automatically converted to a python version in /gnu/store. When I include (native-inputs `(("python", python))), the bashbang remains as #! <robsyme>/usr/bin/python. The script doesn't have a strict requirement for python2, so it seems unnecessary to specify python-2 in the native-inputs, but I want to make sure that the script is run with python from guix. Which native-inputs should I include? <civodul>robsyme: the 'python' package (Python 3) does not have a 'python' binary, only 'python3' <civodul>that's why the shebang does not get patch <efraim>python-wrapper has python3 and python <civodul>robsyme: so presumably you should use python-wrapper <robsyme>civodul: Ah, thanks! (I have obviously not done much with python3)... ***kelsoo1 is now known as kelsoo
<alezost>robsyme: also use comma just before a symbol: ("python" ,python), not ("python", python). This is called "unquoting": ,foo is the same as (unquote foo) <roelj>I have a package A that is only three cpp files. Which compiles to a program. Now, another package B includes all (three) cpp files from A and compiles it into its own programs. I would like to package A, and then extract the source code of A into package B. Is there a way to reference the source tar ball of A in package B? Or should I create a separate "source" target in package A, so that I can put specifically the source code of <roelj>with "target", I mean "package output". <alezost>roelj: yes, you can add a package source of A to inputs of B: (inputs `(("A" ,(package-source A)) ...) as it is done in emacs package, for example <roelj>alezost: Oh great. Let me look at Emacs. <robsyme>I'm writing a package definition for a tool that, for some invocations, shells out to a non-free binary (SignalP). Is there a way to flag that the user must download this non-free program themselves and ensrure that it is in $PATH? <rekado>robsyme: what do you mean by "flag"? <rekado>note that packages that recommend or require non-free stuff cannot be added to Guix upstream. <rekado>you'd have to use GUIX_PACKAGE_PATH or similar for that. <rekado>there is no way to display a notice after installation or so. <rekado>you could add a phase that wraps the programme in a shell script that first checks if the needed binary is available. <rekado>or add a notice to the description. <robsyme>rekado: The main tool (CodingQuarry) itself doesn't have any problems, but it does include an optional shell script that acts as a wrapper - calling a couple of other included scripts and the SignalP (non-free) binary. Perhaps the CodingQuarry binary can be included in Guix upstream if I leave out the optional wrapper script? <JeanLouis>is there a way to download binary directly? Because I cannot easily compile gdk-pixbuf <roelj>JeanLouis: There's a gdk-pixbuf package in Guix that compiles it for you. <JeanLouis>roelj: it fails in compiling and takes hours. Is there way to get gdk-pixbuf by guix in binary? <roelj>JeanLouis: So, you could use Hydra, which gives you a binary.. <JeanLouis>roelj: yes, how to use it? I tried with this guix build emacs --substitute-urls=hydra.gnu.org -- but no go <roelj>JeanLouis: Have you authorized hydra.gnu.org with guix archive --authorize? <roelj>It's at the end of section 2.1 in the Guix manual: To use substitutes from hydra.gnu.org (see Section 3.4 [Substitutes], page 26), authorize them: guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <roelj>JeanLouis: Al right, then simply guix package --install=gdk-pixbuf should query hydra to download it from there instead of compiling it. But, if I understand correctly, in your case, that is not working? <JeanLouis>it goes on with installing, compiling CC.... <roelj>How should I specify the version of a package that has no formal releases, only git commits? <civodul>JeanLouis: what does "guix build gdk-pixbuf -n" report? <JeanLouis>I could just release myself from full block, during compiling <JeanLouis> /gnu/store/bz23rfcckdd43cfpzirvb1904rz07vl3-gdk-pixbuf-2.32.1.drv <rekado>roelj: see the section "Version numbers" in the manual. <rekado>there's an example: 2.0.11-3.cabba9e <roelj>rekado: I must not have the latest version of the manual, just a sec. <roelj>rekado: So it has no release whatsoever. Does that imply 0-<git commit tag>? <rekado>the "1" is our internal revision <rekado>needed in case there's a new commit that's lexicographically smaller than the previous one. <rekado>by increasing the internal revision number we can force the new version number to be considered "greater" <alezost>JeanLouis: gdk-pixbuf-2.32.1 is an old version; I think you need to do "guix pull" <alezost>JeanLouis: you have some old version of guix code (including package recipes), so you are trying to build the packages that do not have substitutes on hydra anymore. Run "guix pull" and try again <JeanLouis>I have just followed binary installation from guix website. <iyzsong>JeanLouis: as users, running 'guix pull' as root only update it for root, you can link every user's ~/.config/guix/latest to /root/.config/guix/latest to share one. <iyzsong>or better link to a git checkout out of guix, if you plan to contribute ;-) <NiAsterisk>I am doing last fixes before leaving for berlin and have a question: " `(("gnunet-svn" ,gnunet-svn) " in (inputs), should this rather be "gnunet-svn" ,gnunet so the application knows that guix input gnunet-svn should be recognized as gnunet ? <rekado>NiAsterisk: depends on what value you want to use there. <NiAsterisk>everything works, big patch incoming, but there is one issue I need to fix in gnunet-gtk-fs :) <rekado>Is "gnunet-svn" a variable that's defined somewhere? <NiAsterisk>I want to be sure that gnunet-gtk-svn uses gnunet-svn as gnunet internally (in configure build etc) <rekado>this is regular Scheme unquoting <rekado>this is a quoted list with two symbols: hello and world <rekado>this is a quasiquoted list with the same two symbols <rekado>"world" here is unquoted, so it will be considered a value. <rekado>(let ((world 'earth)) `(hello ,world)) <rekado>this creates an environment in which the name "world" is bound to the symbol 'earth. <rekado>then a list is created that contains the values "hello" and whatever "world" evaluates to. <rekado>in this case this would be the list '(hello earth) <NiAsterisk>thanks :) then I need to rephrase my question.. one moment <rekado>arguments are defined as a quasiquoted expression in which we can unquote values. <NiAsterisk>what is the practical (for the build system) difference between `(inputs (("python" ,python-2)("some" ,some)) and `(inputs (("python-2" ,python-2)("some" ,some)) and does it matter for the configure and build system at all? <NiAsterisk>in gnunet.scm, gnunet exists and gnunet-svn now. I should choose "gnunet-svn" ,gnunet-svn probably? <rekado>the first thing is just a label. <rekado>you can use that to refer to an input <rekado>e.g. by doing (assoc-ref inputs "python-2") <rekado>this will give you whatever input was labelled "python-2". <NiAsterisk>okay. I will try and read up on scheme as soon as I can, it will definitely help. <rekado>the label can be any string, but to avoid confusion it's usually the same characters as the name of the package variable. <NiAsterisk>thanks for your help :) I Need to pack some things before I leave, could be that I still manage to send the patch today <NiAsterisk>there's this other issue I currently search for in the /svn/gnunet-gtk/ ... was this what you experience in 0.10.1 as well, that gnunet-gtk-fs is black? I have an error message on this, put the needed things in inputs but it's still black <NiAsterisk>NiAsterisk [01:33] (gnunet-fs-gtk:15348): GLib-GIO-ERROR **: No GSettings schemas are installed on the system <NiAsterisk>but maybe you experience this before with some other application? <rekado>I don't know about gnunet-gtk-fs <NiAsterisk>this is in inputs now ("gsettings-desktop-schemas" ,gsettings-desktop-schemas) and still the same <rekado>I only saw that the GUI was basically unusable (either nothing shown or segfault). <roelj>rekado: Thanks for the ant-build-system update. <rekado>roelj: sorry it took me so long. hamcrest-core really tripped me up. <NiAsterisk>I'll just search around some more. next step for me after this patch is system service integration. thanks rekado :) <roelj>rekado: Well, I find it hard to package anything Java.. For things like Picard we need openjdk-1.8.0, and I haven't gotten icedtea8 to work (even with your patch) <- the download link for that patch works for me btw. <roelj>rekado: I'm not even at that point, because I have trouble getting guix to recognize there is a newer version of icedtea. <rekado>note that we do this: (define-public icedtea icedtea-7) <rekado>so you'd need to explicitly use "icedtea-8" <roelj>Yes, well I'm using a local package dir for things not upstream. <rekado>but I guess we'd need to add a parameter to the ant-build-system to override the version of icedtea <roelj>So I ended up renaming it to icedtea-8 as a stand-alone package. <roelj>I agree, we need to be able to specify which version of icedtea should be used. <rekado>roelj: it's a tiny change. Everything was already in place; I just forgot to expose #:jdk and #:ant as valid arguments. <rekado>will send an updated version to the ml <roelj>After I untangled freebayes, I'm going to try again on icedtea-8, and attempt to build maven. <roelj>But I'm going really slow with it <JeanLouis>will it be possible to run most of GuixSD on Debian, except booting, and few of daemons? <NiAsterisk>more or less solved, but as I lack the experience with ratpoison: (gnunet-fs-gtk:6344): GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is not installed how do I provide org.gtk.Settings.FileChooser in ratpoison? install any gtk based filemanager? <roelj>NiAsterisk: Possibly you need gsettings-desktop-schemas <NiAsterisk>the error changed, gsettings now exists, now it is this one <NiAsterisk>I hate to stick to rapoison for now, but without ratpoison I would probably not encounter this error, which is good :) <NiAsterisk>this is cool. I now can book an external spamfilter for calls for my phone, using one of the biggest databases here <NiAsterisk>not that I currently need it, but in the past I had this situation <rgrau>ooops, just sent a couple of packages with errors on them (my fault, obviously). I'm gonna resend them in minutes (In case you are about to review them.... don't :/ ) <NiAsterisk>so as #ratpoison was useless: can anybody with more experience in X11 and gtk tell me what *might* provide org.gtk.Settings.FileChooser ? Just a vague application range is enough <NiAsterisk> i'll try to install gconf in profile and see if the situation changes <NiAsterisk>i think ratpoison, my setup is pretty empty, is set to not include $prefix/share in XDG_SHARE_DIR <rekado>roelj: I need to update the icedtea-8 package. The drops have been changed since I wrote the patch. <roelj>rekado: Any chance of submitting it to the Guix master as well? :) <Jookia>rekado: Did my bad patch get caught in your spam filter? <Jookia>I wonder how hard it'd be to add permissions to Guix's store <Jookia>Basically have the store as no permissions for anyone then if they evaluate a derivation directly or indirectly they get permission to access it <Jookia>civodul: Thoughts on store permissions? <civodul>Jookia: store permissions would be impossible to add, in short <Jookia>Secret derivations as in /gnu/store/secrets/<username>/derivation ? <civodul>there have been discussions about that among the Nix folks <Jookia>In short, without this feature we won't have auto unlocking of encrypted disks after you enter the password at GRUB <civodul>although i guess we could always hack something out-of-band <Jookia>I like the idea of /gnu/store/secrets/username/ ... which derivations refer to <Jookia>But the problem is, unfortunately, that initramfs would have to be a secret <Jookia>Since it copies a secret in to it <Jookia>I can't think of a way around that <Jookia>I mean, I don't see why it couldn't be a secret <cehteh>thats extremely insecure, since someone could tamper with your boot stuff and initrd to steal your secrets and you wont even notice that <cehteh>(well thats almost always possible, sadly) <Jookia>Well, /gnu/store is readonly so they'd only need the keyfile in the initramfs to do this <Jookia>If initramfs were a secret that probably wouldn't be possible <rain1>Roughly what is the threat model? <Jookia>non-root reading the initramfs + keyfile <Jookia>most distros solve this by chmodding initramfs+keyfile to root-read-only <rain1>why can't guixsd do that too? <Jookia>Because the initramfs+keyfile is in /gnu/store, which is world-readable <rekado>roelj: when I download directly from icedtea.classpath.org I get this error: "ERROR: Bad qstring header component: 1457143719.0" <rekado>that's why in my patch I'm using a local copy <rain1>hmm I don't really understand <rekado>roelj: yes, because the Guile HTTP client is stricter. <roelj>rekado: Aha. Then mine will probably fail too, but I never got to that phase. I will check this though. <roelj>rekado: I'm almost ready with uncoupling the submodules from freebayes. <roelj>Is there a specific reason why perl-regexps are disabled in Guix's grep? I get this warning from grep: support for the -P option is not compiled into this --disable-perl-regexp binary. <rain1>I had a search with find command it seems like the only things in /gnu/store that aren't readable are broken symlinks <rain1>what sort of permissions does guix require of /gnu/store and why? <Jookia>rain1: Not sure 'require', but everything in the store is readable to everyone, so you can't put secrets in it <rain1>I wonder what will happen if i try to make a package that has a only root readable file in it <civodul>ownership and permissions are canonicalized <roelj>This package inheritance is really cool! <roelj>I wonder if it's possible to use this to capture package updates, so that the older versions stay available, without needing the git history. <civodul>it is, there are a few examples of that <civodul>but in general we don't want to maintain many versions in Guix proper <civodul>users can always do that in $GUIX_PACKAGE_PATH, though <rekado>roelj: I use this to provide a couple of variants for bioinfo tools in a local repository <roelj>rekado: And icedtea versions.. <roelj>(that's where I took the idea from) <roelj>But why don't we want to maintain many versions in Guix proper? <roelj>Isn't that a really nice feature that comes almost for free in Guix? <civodul>for some packages it's easy, you only need to change the source <civodul>and so if you want to make sure each of them works, that's more work <civodul>also, older packages may have unfixed security vulnerabilities <rekado>older versions of boost for example require many changes in build phases. <roelj>For some the security vulnerabilities weigh less than a reproducible build ;) <rain1>would other packages use secret derivations? <roelj>But if we had the older version of boost, we already had those changes in build phases. We have to write the changes anyway to get newer versions. <rain1>(or would it only be initramfs) <NiAsterisk>yep, fixed when I run gnunet in xfce... I think I file a bug on this and will publish the patch on tomorrow or whenever I find enough time to rebase and a freifunk spot <rekado>roelj: sometimes newer versions require much fewer hacks. Inheritance makes it more difficult to figure out what hacks are really needed. <rekado>I avoid inheritance where it is possible. <rekado>not sure if using inheritance for the icedtea packages was a good idea. <Jookia>rain1: secrets would be very nice for things like VPN configuration <roelj>If I have package A that extracts the sources of other packages into its build environment with ,(package-source B), and then I want to extract the complete source of A into C. Is that possible? <roelj>So in short, will ,(package-source A) also extract B? <Jookia>civodul: Do you think a solution is to simply let some derivations be marked as only root-readable? <Jookia>I wonder if guix container would break that <civodul>Jookia: yes, that seems to be more or less what the github link above talks about <rekado>hmm, the pre-release of icedtea-8 has version "3.0.0pre09". That's bigger than just "3.0.0". What version number should I give it instead to satisfy "version>?"? <Jookia>civodul: Do you think it'd be worth manifesting all filesystems+block devices as shepherd services? Is this how it already works, even in initramfs? <wingo>mark_weaver: i don't have access to that bug unfortunately <wingo>np, thanks for the security work :) <civodul>Jookia: it's how it works, except for needed-for-boot? things; see "herd status" <civodul>or "guix system sherperd-graph your-config.scm | dot -Tpdf > t.pdf" <wingo>fwiw i am pretty skeptical of the icecat project from a security pov; given limited resources it's better in practice (again only from security pov) to follow the latest stable (not ESR) branch <civodul>ESR is supposed to get security fixes as well, no? <wingo>or with epiphany + latest webkitgtk <Jookia>ESR gets security patches doesn't it? <civodul>then IceCat may be lagging behind Firefox ESR, but that's another story <wingo>civodul: supposed to, but i don't trust even firefox esr; too many vulnerabilities, and many can be silently fixed <mark_weaver>wingo: firefox doesn't comply with the FSDG, unfortunately <wingo>in many ways the best way to defend yourself is to keep moving rather than try to lock down a dead snapshot <civodul>i think we simply need to run this in a container, at least <mark_weaver>I like the idea of switching to epiphany, except that I don't know how to get the equivalent functionality of No <davexunit>AFAIK you can't really get that without writing/porting it yourself, since no one really uses epiphany. <mark_weaver>and I consider avoiding most JavaScript code to be useful from a security (and privacy) perspective <mark_weaver>I cannot abide how many cookies I end up with on epiphany <rekado>I'd need something like KeySnail (for Emacs-like keybindings) <wingo>rekado: called "extensions", yes, but not many <mark_weaver>wingo: is there anything for epiphany that allows whitelisting of sites for Javascript and cookies? <NiAsterisk>Jookia: regarding icecat and torbrowser, my intention for maybe 05-2015 is to look at torbrowser, compare it to icecat and the modification of it parabola implements. <rekado>well, I guess I'll just switch to epiphany and see if I can port the extensions I need. <mark_weaver>that's actually pretty much the only thing that's keeping me off epiphany <NiAsterisk>that way I could potentially provide a patched torbrowser <davexunit>is the attack surface really much smaller with epiphany? <davexunit>AFAIK it's webkit, and we all know that webkit sucks. <wingo>davexunit: i don't think webkit sucks in any significantly different way than other browser engines <wingo>but, i work with many people who work full-time on webkit, so *shrug* <davexunit>so I guess I'm wondering why Epiphany is seen as safer. <NiAsterisk>palemoon was nice too. forgot it on my packaging wishlist :) <wingo>davexunit: i think it is of equivalent safety to firefox stable. more safe than icecat i think because it uses webkitgtk which makes more frequent releases which benefit from upstream webkit security work. <wingo>and, the multi-process work in webkit is closer to having containerized web and network processes <wingo>which is the feature which puts chromium head-and-shoulders above the competition in this regard <mark_weaver>I like the fact that epiphany and webkit don't bundle a bunch of other project sources, afaict. <wingo>i think containerizing the browser as a whole is probably not the right thing from a system perspective. <wingo>you do want to be able to upload and download files <davexunit>I am not big on the whole in-browser sandbox thing <NiAsterisk>alright, I'll be afk now, off to berlin. have a nice day o/ <mark_weaver>(e.g. when the graphite2 security updates came along, I had to patch the copy in icecat separately) <davexunit>mark_weaver: ah, I didn't realize that firefox bundles libraries. that's a shame. <davexunit>I know Chromium bundles the entire world, I imagine Firefox is a bit better. <civodul>wingo: the container could selectively share things like ~/Downloads <Jookia>I think bundling can be thought of as a sickness <mark_weaver>davexunit: It bundles a *lot* of stuff. I've made an effort to unbundle as many as I can, but there are still many bundled things, some customized, that I can't avoid using <wingo>civodul: it's not always what you want tho. the problem is in the content process (the web renderer etc). having the epiphany shell mediate access to your file system is fine IMO <wingo>or the chromium shell, or whatever <davexunit>civodul: this is the exact sort of thing I'm interested in. Give the browser access to its config directory and Downloads directory and that's it. <wingo>it's a not-large amount of auditable code that's not under attack from an ABI perspective. <civodul>wingo: right, we need a "power box", but the thing is that most of the web browser should run with limited privileges <davexunit>then I don't have to rely on each application being sure not to touch stuff it isn't supposed to touch. <wingo>civodul: that's what the in-browser sandbox gives you. <civodul>but technically it still runs as the same user, right? <wingo>of course there are always degrees; we are far from an ocap system :) <wingo>civodul: yes but in a container and without the ability to even open(2) a file <mark_weaver>I very much like the idea of sandboxing the browser, but I'm skeptical of how good the isolation is going to be for anything that has functionality such as webgl and webrtc <wingo>mark_weaver: there are numbers on this. chromium does really well. <civodul>wingo: but seccomp is so restricted that there's probably still a lot going on outside of the seccomp'd process <Jookia>You probably shouldn't use WebGL or WebRTC anyway. They're both insecure <civodul>but then they'll use the BPF think with seccomp <mark_weaver>wingo: what numbers would speak against what I'm suggesting? <Jookia>Insecure here meaning vectors for fingerprinting/deanonymization <davexunit>wingo: I wish Chromium was actually packageable, but unfortunately they are in crazy land. <wingo>mark_weaver: i mean, escaping the chromium sandbox is really hard <wingo>vulnerabilities in the web process are common, but it is very rare that they escape the sandbox. <wingo>gl gives interesting side-channels between iframes and tabs <wingo>which is probably an even more important security attack surface than the file system <wingo>but that's unrelated to this question i think <Jookia>How did we even get to this point of having virtual machines to read text <wingo>that's a really ignorant thing to say, Jookia :) <wingo>a web browser does many many many things <mark_weaver>I don't think the problem is so much web browsers themselves, but the way that javascript is massively overused <rekado>a web browser is to many people what emacs is to many of us <mark_weaver>I'd like to be able to read most web sites without running any code that the site asks me to run <Jookia>I legitimately forgot that you can do other things with web browers than read text <civodul>rekado: except that fundamentally people cannot/do not touch the code that comes to them via their browser <rekado>it would be nice if one could "install" or "freeze" web applications <civodul>JeanLouis: is it building things or downloading? <rekado>I like dotjs and I wonder if one could disable code execution from the web and exclusively use scripts from ~/.js <Jookia>Yeah I can see web browsers being a pretty interesting system then. I don't actually have the processing power to do anything more than read text on them anymore <rekado>I'd really like to have a more Emacs-like browser. <bishopj>If I wanted to convert a debian system with Guix installed on top, how would I go about converting it to a GuixSD system? <mark_weaver>rekado: the hard problem is that web site administrators expect to be able to change their Javascript code whenever they wish and expect that users will immediately start using their new version. <davexunit>rekado: Chef seems better, but not much better. <bishopj>They all seem to attempt to do the exact same thing, make sure these files with these hashes are located at these places and everything I don't exactly specify do the default thing <mark_weaver>one could view 'youtube-dl' as an example of trying to effectively replace the code that we need to run to watch youtube videos. <mark_weaver>and we see that it needs to be updated very frequently <rain1>I implemented your suggestions for password generator (using /dev/random, char sets) made it a lot better :) <davexunit>mark_weaver: the problem there is that these sites don't have a public HTTP API, so youtube-dl is left to scrape web pages. <mark_weaver>right. what's needed, I think, is a change of culture among web site creators, to support stable APIs that allow effective use of the site without running their javascript code <rain1>A similar program to youtube dl is get_iplayer <rain1>there was a bit of interesting discussion going on about free software/open formats relating to it, and the author gviing up on it <davexunit>mark_weaver: for dynamic web applications, I agree. <JeanLouis>how can I add new version of packages? for example postgresql. Can I simply change database.scm? <JeanLouis> "08ba951nfiy516flaw352shj1zslxg4ryx3w5k0adls1r682l8ix") -- how do I get this string for verifiation? <bavier>JeanLouis: `guix hash <tarball>` <JeanLouis>bavier: but that means, if new version was not patched by guix properly, maybe it won't work straight, right? <bavier>JeanLouis: what verification are you wanting to do? <JeanLouis>not quite verification, sometimes sources are patched by guix, and if there is anything new... it would break guix <JeanLouis>and if I cannot compile pwgen package on 1.7GB /tmp, I don't know how will I succeed with postgrsql <bavier>JeanLouis: the base32 hash applies to the unpatched source tarball <JeanLouis>yes, have chosen new version of unpatched source tarball. <bavier>and yes, any patches used might need to be adjusted for new versions of the package source; it depends on the nature of the patches <JeanLouis>I only hope that patches work on new version <bavier>guix-daemon honors TMPDIR as far as I know <JeanLouis>bavier: aha yes? oh, that makes everything different. <roelj>Can I use the 'install-file' function when using the trivial-build-system? <JeanLouis>and I don't see any patches for postgresql in database.scm -- so it might work simply <JeanLouis>rain1: yes I got pwgen, tried: guix package -u pwgen, it took me few hours, and broke, too little space on /tmp <bavier>roelj: sure, it's not build-system dependent <rain1>oh I thought you were writing a package for it <roelj>bavier: Where is it defined / what module do I need to import to be able to use it? <rain1>does it upgrade the whole system? <JeanLouis>rain1: it seems it upgrade so many packages, looks not necessary to me ***Digit is now known as digit_
***digitteknohippie is now known as Digit
***digit_ is now known as digitteknohippie
<bavier>JeanLouis: upgrading a package requires having its dependencies in place/upgraded also, whether or not those upgraded packages are updated in your profile <JeanLouis>rain1: my plan is to build /gnu, use guix archive, put stuff on USB, install Guix, take stuff from USB, and run <JeanLouis>bavier: yes, it looks like many are being upgraded <roelj>Is there an example package that downloads a tarball containing a few scripts, and install it by copying these scripts to the output directory? (And does nothing else) <bavier>roelj: many of the packages in (gnu packages fonts) do that currently <JeanLouis>bavier: thank you TMPDIR is working with guix, I am running it now on /tmp-guix instead on /tmp which is encrypted and probably anyway slower <JeanLouis>you saved me, I was thinking it must be on /tmp <bavier>JeanLouis: great. are you not using substitutes? <roelj>bavier: I hadn't thought of looking there. Thanks, again! <JeanLouis>and if I use substitute-urls with guix package -i -- it simply starts compiling <JeanLouis>I understand substitutes shall be downloaded as binaries <JeanLouis>anyway it is good that I can compile myself, so I will give it time <mark_weaver>JeanLouis: "guix archive --authorize < hydra.gnu.org.pub" might be the step that you missed. you shouldn't need to pass --substitute-urls="http://hydra.gnu.org", that's the default anyway <JeanLouis>mark_weaver: I did authorize many times, how shall substitute downloading look like? Does it run "configure && make" etc? Or not <mark_weaver>JeanLouis: no, when substituting a package, it just downloads it. <JeanLouis>I have read info/docs, I guess it should be, but never observed it. <bavier>yes, substitutes are downloaded, pre-built packages <bishopj>How would I go about downloading all of the source packages and redirecting all future build requests to use the local packages? <JeanLouis>I think my packages were "old" version, that is why nothing downloaded from hydra.gnu.org <mark_weaver>it's important to stay up-to-date, for security updates <bavier>bishopj: I'm assuming with local compilation? There's `guix build --sources=transitive <foo>...`, but you'd need to apply that to all packages you'd be interested in, and maybe also with the --no-substitutes flag <JeanLouis>mark_weaver: my goal is to make system myself, and later install basic GuixSD -- copy from USB/CD to system, and done. you think it is possible? <mark_weaver>JeanLouis: I guess maybe "guix system disk-image" might be what you're looking for? <mark_weaver>see section 7.2.13 (Invoking 'guix system') in the manual <JeanLouis>mark_weaver: oh yes something like that, exactly. <bishopj>bavier: correct I am planning on creating my own local hydra repo on my own personal server and I would like to ensure Full sources are locally stored and built locally. <bavier>bishopj: in that case, it might be easier to ensure that guix-daemon is started with the --no-substitutes flag <mark_weaver>for now, I've worked around the problem by using 'get-bytevector-n!' instead <mark_weaver>on my X60, it substitutes texlive-texmf in about 12 minutes <civodul>mark_weaver: oooh, that bug is still there, right <mark_weaver>if we wanted to make it faster, I could implement the same algorithm as a C program, but maybe this is good enough. <davexunit>I may have found a situation where I can make a push for Guix at work. <davexunit>got a pretty complicated piece of software to build from source with a bunch of specially patched dependencies. <tg>is there any guixsd installer for arm? <davexunit>the issue is figuring out how to work it in so that it can coexist with everything else. <davexunit>tg: GuixSD is currently not supported on ARM. <civodul>"I may have found a situation where I can make a push for Guix" sounds like this is a hopeless endeavor ;-) <tg>davexunit: any idea what's missing? <civodul>look, you could say it as: "I found another great opportunity to use Guix at work!" <civodul>it's the salesperson in me that speaks ;-) <davexunit>tg: there's a few major issues. the biggest issue is that right now we only use GRUB as the bootloader, which doesn't have an official ARM-supporting release. second to that, each ARM board is a bit of a special snowflake. often they require kernel/bootloader forks in order to work. <davexunit>civodul: the trick will be to see if I can reasonably port an entire Ruby web application into Guix. <davexunit>I think I can do it. this application is on the smaller side as far as Ruby dependencies go. specifically, it doesn't use Rails. :) <civodul>good if there are fewer dependencies <civodul>i guess that's the main showstopper otherwise <davexunit>I think this one is really feasible. especially given the specialized dependency tree AKA guix's bread and butter. <mark_weaver>civodul: "hopeless" doesn't just mean "very difficult", it means that it seems impossible <bavier>does anyone know if there's a way from inside a makefile to get the value of the -j parameter given to make? <janneke>$(shell cat /proc/self/cmdline) ? *grin* <janneke>JeanLouis: you want to build everything from source? <JeanLouis>I tried using, it does not get it,maybe it will work in future <JeanLouis>I understood GuixSD is to build from source, mostly, and there are substitutes <janneke>JeanLouis: conceptually, you specify every install from source <JeanLouis>but I think it compiles gcc. and all the GNU basics <JeanLouis>and I am compiling too IceWM to see how to include it in GuixSD <janneke>JeanLouis: because guix has dependable builds, you can use binaries built by someone else, e.g. the central build system <JeanLouis>janneke: sure, that is what I tried, but I was advised, that my sources are maybe too old in comparison with those that are built. <mark_weaver>I've been using it on my primary machine for well over a year <JeanLouis>I was thinking it is not working yet.I am just 4-5 days here. I want to run GNU, official <mark_weaver>"guix pull" only updates Guix for the user who ran it. so if you run "guix pull" as root, only root will be using that updated guix. <janneke>we really need a `recommended usage guide' <JeanLouis>And I see lines like: gcc-4.9.3/libstdc++-v3/testsuite/26_numerics/ <JeanLouis>patch-shebang, I know, but that is what I see, and configure running... <JeanLouis>to me it looks like guix pull is compiling itself <JeanLouis>bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../gcc-4.9.3/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../gcc-4.9.3/gmp -DOPERATION_`echo sec_add_1 | sed 's/_$//'` -g -c -o sec_add_1.lo sec_add_1.c <mark_weaver>JeanLouis: "guix pull" downloads the *source* for guix and compiles it <paroneayea>hyperreal: I'm not using two different versions of gnome... I'm running gnome/stumpwm on debian and xfce on GuixSD :) <mark_weaver>and for that, it also needs the prerequisites for compiling guix itself <paroneayea>where I can access the same guix store between debian and guixsd <JeanLouis>mark_weaver: are prerequisits listed with guix package -I or not shown in that list? <mark_weaver>although it sounds like you're compiling gcc itself, which is surprising <JeanLouis>yes, it looks to me, whatever package I wish to install, gcc compiling starts, <mark_weaver>JeanLouis: did you run "guix pull" successfully as root recently? <JeanLouis>mark_weaver: yes I remember, it downloaded and finished <mark_weaver>JeanLouis: as a temporary hack, you could make ~/.config/guix/latest a symlink that points to ~root/.config/guix/latest <mark_weaver>and then your normal user will just use the results of the "guix pull" that root ran. <JeanLouis>when I made it, I saw on mailing list, there is now 0.9.1 <JeanLouis>but -- if I use GuixSD -- can I still, install various stuff in my /home without being removed? <fhmgufs>I finally decided to buy an used Libreboot supported notebook for GuixSD. I <fhmgufs>would like to use the X60. Has somebody experiences with it? Will GNOME 3 run <fhmgufs>on the X60? And, how much disk space and RAM is recommended for GNOME on <mark_weaver>fhmgufs: I'm typing this on a Libreboot X60 running GuixSD with GNOME 3 right now :) <JeanLouis>mark_weaver: I read that GuixSD will remove from /usr /var etc. anything that was not installed by GuixSD <mark_weaver>fhmgufs: there are still some remaining problems with GNOME 3 on GuixSD, e.g. when attempting to wake from suspend-to-ram it gets stuck, always going back into suspend immediately. <mark_weaver>at the moment, Xfce and wicd is what works reasonably well <fhmgufs>Yes, if there were no problems, there would be nothing to solve. <mark_weaver>I don't know whether the problem is in recent libreboot itself, or recent kernels, or what <mark_weaver>e.g. switching from X to text console sometimes just gets stuck and I need to power cycle <mark_weaver>the Libreboot X200 worked much better in my experience, but at the moment my X200 has hardware problems so I'm back to the X60 for now. <fhmgufs>X200 is better of course. Is this hardware flashing difficult? <mark_weaver>fhmgufs: I would be very surprised if the stability problems are related to Guix. I strongly suspect it has to do with the fact that Guix has the latest versions of things, and developers aren't testing the latest code on older machines like the X60. <mark_weaver>fhmgufs: the Libreboot X200 is the best thing we have at the moment, for users who want a free initialization and no remote-access backdoors :) <fhmgufs>Ok, you mean the product "Libreboot X200"? <mark_weaver>minifree and libiquity sell them already liberated, or you can flash it yourself and replace the wireless card with an atheros. <davexunit>x220, x230, etc. are hopeless for libreboot support <janneke>ACTION does not believe in the concept of blame <janneke>mark_weaver: ouch...thanks. i was not aware <davexunit>well they have deliberately made it impossible to remove things like AMT from newer boards <janneke>davexunit: intel is totally free to do that <janneke>it is my unawareness that puts me in this spot, i create my own reality <mark_weaver>fhmgufs: btw, the X60 has worked more reliably for me in the past. it might be that it would run more reliably on an older kernel and/or older version of libreboot <davexunit>janneke: we'll have to agree to disagree here. <davexunit>I don't think you are to blame for Intel's maliciousness. <davexunit>they shouldn't be selling this stuff in the first place. <janneke>i don't believe in the concept of blame, especially not in blaming myself :-) <janneke>davexunit: they can try to sell whatever they like <davexunit>I think this sort of thing should be made illegal. <janneke>just like trump can want to be president <davexunit>janneke: that's a flawed assertion, but I don't want to get into it. <janneke>it's sad that media don't report such things <janneke>i do not believe in illegal or punishment ;-) <janneke>i am drifting off-topic, the libreboot thing inspired me!! <davexunit>in other news, ATLAS is a complete nightmare. <davexunit>and it's unsubstitutable because it optimizes itself for the machine it is built on. <bavier>davexunit: I would suggest using openblas if possible <bavier>I can't imagine kaldi would need specifically atlas, just any blas/lapack implementation <bavier>many projects still speak of atlas because at the time of writing it was the only widely available and fast linear algebra library, but the landscape has changed somewhat recently <davexunit>bavier: OpenBLAS does the same shenanigans as ATLAS :( <lfam>Hooray for HTTPS delivery of substitutes! <lfam>What's the right way to escape double-quotes inside of strings? The string is being used in substitute* <lfam>It seems like \\ should work, but it's not, so maybe my problem is somewhere else <lfam>That's what I thought. There must be some other problem with my code :) <mark_weaver>lfam: you can always load up (guix build utils) and try running 'substitute*' manually on a test file <lfam>mark_weaver: Okay, I will give that a shot. I need to get more fluent in the REPL <lfam>Here's a newbie question. From the top level of the Guix source tree, I start Guile, and then try to do ',use (guix build utils)', but I get the error 'no code for module (guix build utils)'. Same for ',use (gnu)', which I could have sworn worked in the past. My knowledge here is really thin... <mark_weaver>lfam: the issue is what modules are in the guile load path. ./pre-inst-env takes care of that for you <mark_weaver>within guile, there's %load-path and %load-compiled-path. when guile starts, it consults the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables <lfam>I did the substitution from the REPL. Pretty magical :) <lfam>I see, that makes sense. I *was* wondering how Guile was supposed to find the modules in my source tree. I guess I totally forgot how I did it last time. <davexunit>rekado: why do we specify NO_LAPACK=1 in our openblas make flags? <lfam>How about escaping parens? When I use \\( then I get "illegal character in escape sequence: #\\(". When I use \\\\(, the substitution takes effect, but there is a stray \\ inserted before the paren in the result <lfam>And when I use \\\\\\(, I get the same error about "illegal character..." <mark_weaver>lfam: use \\\\( in the pattern and just plain ( in the replacement <mark_weaver>the reason is that ( is a regexp meta-character, so the regexp machinery needs to see a \\ before the ( <mark_weaver>and the way to make a single \\ in a string is to put \\\\ <lfam>It makes sense that the replacement string is handled differently <mark_weaver>there are two levels of escaping that's needed: one to escape characters like \\ and " in a scheme string literal, and ther second layer (needed only for the pattern, not the replacement) is escaping regexp meta-characters. <mark_weaver>escaping is terrible, but it seems to be the way things are done <lfam>Along with environment variables, I think that string escaping must be one of the great problems of computer science ;) <suitsmeveryfine>Hi! I've tried to install GuixSD maybe five times today using the USB installer. It fails every time for one reason or another. Does everyone else experience the same? <mark_weaver>suitsmeveryfine: it depends on the details of the failure. can you share the details? <mark_weaver>but it's certainly true that the initial install is very unforgiving <mark_weaver>the good news is that after the initial install, future mistakes are much more easily recovered from <mark_weaver>and on any given machine, you should only have to do the initial install once :) <suitsmeveryfine>mark_weaver: often the error message is that the connection is bad, sometimes there are missing dependencies and other times something goes wrong with grafting <suitsmeveryfine>mark_weaver: yes, I know: I'm trying to install on a second machine :) <mark_weaver>network connection failures are a common problem, and the solution is just to restart the command <mark_weaver>as for the other problems you mentioned (missing dependencies, something goes wrong with grafting), can you share more details? <efraim>also some of the download urls changed since 0.9.0 was released <suitsmeveryfine>mark_weaver: I can restart the installer and report the issues again if you want. <mark_weaver>suitsmeveryfine: because hydra currently doesn't build grafting replacements <mark_weaver>you shouldn't turn off grafting, because if you do, you'll have security holes in your system <mark_weaver>at present, that includes a potential remote code execution vulnerability in openssl <suitsmeveryfine>mark_weaver: OK, but it would be good to be able to complete "guix system init" at least <suitsmeveryfine>I can alway keep trying to install GuixSD. It's almost become a ritual. <lfam>The Perl build fails for you? <suitsmeveryfine>now I seem to have gotten past the perl build and have network issues instead <lfam>In retrospect, that Perl change should have probably gone to security-updates or a similar branch. <lfam>At least we got a chance to *really* test out the grafting mechanism :/ <davexunit>lfam: looked at that microca.st link. I'm unconvinced that we should copy nix-shell in this way. <Jookia>What comes to mind is people just writing Guile shell scripts using Guix environment as a module <lfam>davexunit: Yeah, I just thought it was relevant to share. It seems like the resulting environment would not be "uncontrolled" <davexunit>I've long wanted 'guix environment' integrated into emacs <bavier>davexunit: like guix-mode command that would launch eshell with everything set up? <davexunit>bavier: I'd like to do an environment excursion so that I could run arbitrary elisp in a new environment. <lfam>Has anybody started using the https URLs for our substitutes servers? I ran `guix pull` and updated the --substitute-urls in my invocation of the daemon, but I still get the backtrace from http://bugs.gnu.org/22937 <rain1>lfam, I tested it and so do i <efraim>i saw ludo cleared his cache first <rain1>guix environment is amazing for perl scripts <efraim>I wanted to rip a CD, so I dusted off my external cd drive, plugged it in, and ran `guix environment --ad-hoc abcde -- abcde` <davexunit>efraim: love seeing success stories like this. :) <suitsmeveryfine>No finally I got the build failure. "some substitutes for the outputs of deriviation '...geoclue...' failed (usually happens due to networking issues) <rain1>if you redo the command it might go futher <suitsmeveryfine>but everything needs to be downloaded and built again? It's not a question of resuming? <rain1>suitsmeveryfine, I think this is the biggest problem with guix <paroneayea>davexunit: I'd love to talk to you about "persistent profiles for environments" or etc <davexunit>I can only talk for 5-10 minutes before I have to run <paroneayea>davexunit: no worries, maybe we can talk later today or next week <suitsmeveryfine>I don't expect it to work flawlessly, but it takes a lot of my time to just keep trying to install. <paroneayea>it would improve my quality of life a lot now that I use guix environment every day ;) <bavier>suitsmeveryfine: not everything needs to be downloaded again, just the package that failed to download <bavier>any other successful downloads would still be in the store <bavier>yeah, we just don't have resumable downloads for individual substitutes, ala wget <lfam>paroneayea: How about linking the environment's profile into /var/guix/gcroots? Does that work in the meantime? <bavier>JeanLouis: See 'Invoking guix package' in the manual <lfam>I thought the question was "Which version of GCC?" <bavier>basically, list the version after the package name: `guix package -i gcc-4.8.5` e.g. <bavier>though you'll probably want to install gcc-toolchain instead <JeanLouis>bavier: thanks, yes, I will try like that to ask for versions <paroneayea>cwebber@oolong:~$ ls /var/guix/gcroots/profiles -l <paroneayea>lrwxrwxrwx 1 root root 22 Dec 20 21:31 /var/guix/gcroots/profiles -> /mnt/var/guix/profiles <paroneayea>I wonder if I did something terrible in my debian + guix setup :) <JeanLouis>bavier: thanks, I just needed to learn about versions <lfam>paroneayea: Does it work? ;) <paroneayea>but as for the profiles symlink, well it doesn't seem to be breaking anything, but it goes nowhere <lfam>I meant do you profiles get protected from the garbage collector despite the broken link? <paroneayea>lfam: my user's profile doesn't seem to be gc'ed... <lfam>And the old generations? <paroneayea>lfam: where does /var/guix/gcroots/profiles go on your machine? <lfam>It goes to /var/guix/profiles <lfam>This is not GuixSD, just Guix on Debian <paroneayea>lfam: that seems like the correct place for it to go... <JeanLouis>guix package --show=gcc-5.3.0 -- this does not work to show the package by version number <lfam>JeanLouis: How about gcc@5.3.0 ? <bavier>JeanLouis: interesting, without the version number should work; it will just show all available versions <bavier>but my guix might be slightly out-of-date, lfam's suggestion might work 
