IRC channel logs

2016-03-10.log

back to list of logs

<a_e>In my case, it does nothing. No error.
<JeanLouis>a_e: guix package -f mail.scm mutt
<JeanLouis>guix package: error: mutt: extraneous argument
<JeanLouis>what was your command line?
<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>*does
<rain1>ah thanks, ill try that!
<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
<JeanLouis>rain1: is it redirecting to a mirror?
<rain1>yeah it bounces about 5 times
<rain1>i'll just ask the guys to not use sf :)
<rain1>maybe they'll switch..
<JeanLouis>rain1: ok, and are you defining packages.scm?
<rain1>i was trying yeah
<JeanLouis>yes, I want too
<JeanLouis>can you show me your file?
<JeanLouis>I would like to understand how to install package from file on the disk
<JeanLouis>as: guix edit package.scm cannot be saved
<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>Jookia, sweet :D
<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>Hi francis7
<francis7>o/
<suitsmeveryfine>As soon as Jookia's patch has been merged GuixSD should be fully compatible with encrypted /
<suitsmeveryfine>francis7: Here is the working draft installing GuixSD with encryption: https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00925.html
<Jookia>francis7: It's not possible for a while
<Jookia>rain1: Yes kinda
<Jookia>Basically FDE with Libreboot will need some MAJOR refactoring
<rain1>I might try it out in qemu at some point then
<Jookia>I've just hacked my way there
<suitsmeveryfine>Jookia: are you not happy with the solution?
<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
<suitsmeveryfine>Well, my GRUB was broken until I got your patch
<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>JeanLouis: Mount it after boot?
<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
<rain1>guixsd i mean
<JeanLouis>yes, that way, nobody can see in the system itself, that there is disk to be mounted.
<Jookia>JeanLouis: What do you mean?
<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)
<JeanLouis>so please think when making a patch on that
<Jookia>JeanLouis: Deniable encryption is difficult, could you give a concrete use case?
<rain1> https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#Networking-Services
<rain1>I noticed a very funny service here
<rain1>nullrouting facebook
<rain1>maybe could merge in much more things to block from here http://surf.suckless.org/files/adblock-hosts
<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
<johndau>sp
<Jookia>suitsmeveryfine: That's no good. :(
<Jookia>suitsmeveryfine: Actually, it might be
<Jookia>Can you reconfigure the live USB?
<suitsmeveryfine>I've never done it before but I guess I could try
<Jookia>Also can you boot in to it from legacy BIOS
<Jookia>setting
<suitsmeveryfine>no, it's a macbook
<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>yeah
<rain1>I was thinking of running this command: lsh-make-seed
<rain1>maybe I don't need to even do that?
<Jookia>Don't think so
<Jookia>suitsmeveryfine: That's no good
<suitsmeveryfine>OK. Then I guess someone else will need to help you.
<Jookia>That's cool, you can always test it. :) Do you have an existing Guix system?
<suitsmeveryfine>Me?
<suitsmeveryfine>Yes.
<Jookia>Ah cool! You could always just build a USB image using patches I send you
<suitsmeveryfine>Yes, I can do that.
<suitsmeveryfine>I'd actually like to experiment on building installers.
<suitsmeveryfine>I get constant build failures on the T60
<Jookia>Well, maybe something good to do would be to build some USBs
<suitsmeveryfine>it "usually happens due to networking issues"
<suitsmeveryfine>How hard would it be to create a USB installer that doesn't require an internet connection=
<suitsmeveryfine>considering the frustrating network problems
<suitsmeveryfine>It sometimes takes two--three days to finish `guix system init`
<Jookia>What do you mean doesn't require an internet connection? Doesn't it just use it to pull?
<suitsmeveryfine>Do you mean that the 0.9 USB installer isnt a net-installer?
<suitsmeveryfine>and that it works without `guix pull` and no internet connection
<Jookia>I don't know, does it?
<Jookia>It should be able to install itself
<Jookia>ie make another installer
<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>suitsmeveryfine: Thanks!
<Jookia>JeanLouis: Well, how else would you boot it?
<rain1>how does one get a root terminal in guix?
<rain1>i cannot do: su
<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>sudo -i
<rain1>ooh thanks!
<suitsmeveryfine>Maybe macbook EFI is special
<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
<suitsmeveryfine>Wow!
<suitsmeveryfine>Jookia: why would it be just 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>No
<Jookia>If you're on Libreboot, that is
<suitsmeveryfine>once in libreboot's GRUB
<Jookia>Once in libreboot's GRUB, then optionally at the login prompt
<suitsmeveryfine>ah, nice
<Jookia>Instructions nearly done
<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?
<Jookia>rain1: Not sure
***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)
<suitsmeveryfine>Jookia: nice. I'm going to bed now
<JeanLouis>sudo is installed as user or root?
<iyzsong>JeanLouis: in guixsd, neither, it's under /run/setuid-programs. a normal package (even root) install can't have setuid bits.
<rain1>touch /var/log/wtmp
<rain1>I think this, as root, is enough to solve the problem
<iyzsong>oh, I'm out of the topic ;-)
<rain1>sorry iyzsong
<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>and rebooted
<rain1>but now when I tried to install one package, it seems like it's reinstalling every package
<rain1>so many...
<rain1>is that supposed to happen?
<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>I have ntpd running.
<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>lfam, yes I am using libreboot.
<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
<lfam>I would read this bug report on the subject: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22274
<hyperreal>but yes, the command output says Wed 31 Dec 1969, etc.
<hyperreal>thanks, I'll check out the bug report
<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
<lfam>hyperreal: Very good :)
<hyperreal>lfam: how do I downgrade the kernel?
<paroneayea>davexunit: check yer email re: talks
<paroneayea>hyperreal: :)
<paroneayea>hyperreal: it's easy, in your system config do this:
<paroneayea> http://pamrel.lu/89875/
<paroneayea>and obviously the rest of your definition
<paroneayea>just kernel and kernel-arguments
<paroneayea>are the important ones
<paroneayea>hyperreal: ^^
<paroneayea>kernel-arguments will stop "guix system vm" from crashing your computer :)
<davexunit>paroneayea: thanks!
<paroneayea>hyperreal: so do "sudo system reconfigure your-file.scm"
<paroneayea>and you should be gold
<hyperreal>paroneayea: awesome, thanks!
<paroneayea>:)
<paroneayea>davexunit: yup!
<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>ok
<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
<hyperreal>I have that exact line in my configuration
<hyperreal>I'll run guix pull again though
<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>Yes, that should do it
<hyperreal>:)
<lfam>This is one difference from other systems. Each user has their own list of available packages
<hyperreal>yes, I keep forgetting that
<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>hello civodul!
<civodul>hey efraim!
<efraim>bind and isc-dhcp updated for bind's CVEs
<efraim>almost filled up the coffee maker with baby formula
<civodul>baby formula?
<efraim>like for making milk for a baby http://assets.inhabitots.com/wp-content/uploads/2012/05/baby-formula.jpg
<civodul>ooh
<civodul>i see :-)
<civodul>ACTION goes get real coffee
<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>exactly
<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>A in the inputs of B?
<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.
<roelj>alezost: I see. Thanks!
<alezost>yw!
<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?
<robsyme>*ensure
<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: Fixing gdk-pixbuf would be the preferred way of going about it. But it seems to build fine in Hydra: http://hydra.gnu.org/job/gnu/master/gdk-pixbuf-2.32.3.x86_64-linux
<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
<JeanLouis>I did that at beginning, yes
<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>guix build gdk-pixbuf -n
<JeanLouis> /gnu/store/bz23rfcckdd43cfpzirvb1904rz07vl3-gdk-pixbuf-2.32.1.drv
<JeanLouis>/gnu/store/632msbms2yaldfnlrb5lbnlnmn9yjisw-guix-0.9.0/bin/guix-daemon --build-users-group=guixbuild --substitute-urls="http://hydra.gnu.org"
<JeanLouis>that is how my daemon runs
<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>roelj: 0-1.$commit
<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>alezost: like user?
<JeanLouis>or as root?
<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 ;-)
<remi>join #guile
<remi>Oops no
<roelj>rekado: Thanks
<roelj>rekado: again :)
<resu>hello
<resu>PING 1457609151.000000
<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 :)
<NiAsterisk>hm
<rekado>Is "gnunet-svn" a variable that's defined somewhere?
<rekado>if so, do you want to use it?
<rekado>these are not arbitrary names.
<NiAsterisk>I want to be sure that gnunet-gtk-svn uses gnunet-svn as gnunet internally (in configure build etc)
<NiAsterisk>gnunet-svn exist
<NiAsterisk>*s
<NiAsterisk>what I need to understand is how mapping works
<rekado>there is no mapping.
<rekado>this is regular Scheme unquoting
<NiAsterisk>okay, then what does this do?
<NiAsterisk>ah
<rekado>'(hello world)
<rekado>this is a quoted list with two symbols: hello and world
<rekado>`(hello world)
<rekado>this is a quasiquoted list with the same two symbols
<rekado>`(hello ,world)
<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>in arguments we do the same
<rekado>arguments are defined as a quasiquoted expression in which we can unquote values.
<rekado>same in inputs.
<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")
<NiAsterisk>ah, i understand :)
<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
<rekado>no hurry :)
<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>i'm currently searching for a switch
<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
<NiAsterisk>okay
<rekado>I only saw that the GUI was basically unusable (either nothing shown or segfault).
<NiAsterisk>ah, okay. then I fixed more than this already^^
<rekado>yay :)
<NiAsterisk>I/jookia and me/
<NiAsterisk>i'm just fixing last parts and descriptions etc
<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.
<rekado>roelj: does it not compile?
<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>huh? works for me.
<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.
<roelj>Cool
<rekado>will send an updated version to the ml
<roelj>Great. Thanks a lot!
<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
<roelj>(all things Java)
<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> have it in my profile
<NiAsterisk>*i
<roelj>Sorry, then I don't know
<NiAsterisk>the error changed, gsettings now exists, now it is this one
<NiAsterisk>okay, thanks
<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 :/ )
<Jookia>o/
<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
<Jookia>sounds like a gconf thing
<Jookia>though that might be gnome
<NiAsterisk> i'll try to install gconf in profile and see if the situation changes
<NiAsterisk>not directly.
<NiAsterisk>but I'll do some more searches later
<NiAsterisk>something with gvfs
<NiAsterisk>ha
<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: Ok.
<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?
<NiAsterisk>Jookia: it ended up on the list, in gmane
<Jookia>Ah, okay
<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
<civodul>let's encrypt! http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22937#17
<Jookia>Woo!
<civodul>at last...
<Jookia>civodul: Thoughts on store permissions?
<civodul>now we only miss $https_proxy
<Jookia>https_proxy, the dream :D
<civodul>Jookia: store permissions would be impossible to add, in short
<Jookia>Eugh
<civodul>what did you have in mind?
<civodul>secrets and such?
<Jookia>Yeah
<Jookia>Secret derivations as in /gnu/store/secrets/<username>/derivation ?
<civodul>yeah that's a common use case
<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>quite possible
<civodul>although i guess we could always hack something out-of-band
<Jookia>It has to go in the initramfs
<Jookia>And initramfs is a derivation
<civodul> https://github.com/NixOS/nix/pull/329
<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
<civodul>yeah, not great
<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
<roelj>rekado: And a wget works?
<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.
<rekado>roelj: nice!
<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
<civodul>it's all that will happen :-)
<rain1>ah its part of the system
<roelj>This package inheritance is really cool!
<civodul>of course it is! :-)
<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>precisely: it's not for free :-)
<civodul>for some packages it's easy, you only need to change the source
<civodul>but most packages vary over time
<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
<civodul>tracking that is too much work
<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
<NiAsterisk>also I can talk to cg about this at logan cij
<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>rekado: Ok.
<rain1>I see!
<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>?"?
<civodul>you'll have to be imaginative :-)
<civodul>2.99.99?
<rekado>too bad.
<civodul>rekado: if/when the brilliant proposal at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22628#11 is implemented, that'll be an easy solution
<rekado>nice!
<mark_weaver>wingo: I'm trying to find the fix for CVE-2016-1958, mozilla bug 1228754 (Displayed page address can be overridden) in mozilla-esr38. alas, I see no references to that bug number in the commit logs of that branch, and https://bugzilla.mozilla.org/show_bug.cgi?id=1228754 refuses me access. can you help?
<mark_weaver>maybe you have access?
<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
<mark_weaver>wingo: okay, thanks for trying
<wingo>np, thanks for the security work :)
<civodul>Jookia: it's how it works, except for needed-for-boot? things; see "herd status"
<Jookia>Ah, I see.
<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
<davexunit>+1 for icecat in a container
<mark_weaver>I like the idea of switching to epiphany, except that I don't know how to get the equivalent functionality of No
<mark_weaver>NoScript and Cookie Monster
<davexunit>AFAIK you can't really get that without writing/porting it yourself, since no one really uses epiphany.
<NiAsterisk>schroedingers icecat :)
<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
<wingo>ACTION uses epiphany :)
<rekado>I'd need something like KeySnail (for Emacs-like keybindings)
<civodul>Conkeror
<rekado>does epiphany have plugins?
<Jookia>wget
<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?
<wingo>mark_weaver: lemme check
<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.
<Jookia>Nice!
<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>mark_weaver: https://webkit.org/blog/3476/content-blockers-first-look/
<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>i.e. when compared to ESR.
<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
<davexunit>okay
<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>ok
<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 :)
<civodul>yeah :-)
<wingo>civodul: yes but in a container and without the ability to even open(2) a file
<wingo>because of seccomp
<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
<civodul>*thing
<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.
<davexunit>so it's a no-go.
<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>and gl is sandboxed too
<mark_weaver>I don't doubt that it's a major improvement
<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>God web browsers are terrible
<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 :)
<Jookia>Oh?
<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
<Jookia>Oh, right
<davexunit>ACTION was about to make an emacs analogy
<mark_weaver>I'd like to be able to read most web sites without running any code that the site asks me to run
<wingo>rekado++
<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
<rekado>civodul: right.
<JeanLouis>I have guix package -u -- and is running for hours, although I have only 24 packages, http://lpaste.net/154415 --does that need so long time? My laptop is good one
<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
<Jookia>Even videos are unplayable
<JeanLouis>civodul: I see it is building
<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?
<davexunit>Guix got a few mentions on this HN discussion of "Ansible vs. Chef" https://news.ycombinator.com/item?id=11256021
<rekado>bleh, I'm stuck with puppet :(
<rekado>inheritance is a curse.
<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.
<mark_weaver>but I agree that it's an important problem
<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.
<civodul>JeanLouis: make sure to enable substitutes, https://www.gnu.org/software/guix/manual/html_node/Substitutes.html
<mark_weaver>and we see that it needs to be updated very frequently
<rain1>hello
<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
<mark_weaver>but that's a tall order :)
<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
<rain1>can read about that here http://linuxcentre.net/get_iplayer-dropped-in-response-to-bbcs-lack-of-support-for-open-source
<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>base32
<JeanLouis> "08ba951nfiy516flaw352shj1zslxg4ryx3w5k0adls1r682l8ix") -- how do I get this string for verifiation?
<bavier>JeanLouis: `guix hash <tarball>`
<JeanLouis>alright
<JeanLouis>thaks
<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
<civodul>JeanLouis: make sure to read https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
<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
<rain1> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/password-utils.scm#n49
<rain1>here is pwgen
<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
<rain1>why -u not -i ?
<JeanLouis>-i worked, I was testing "upgrade"
<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
<bavier>roelj: (guix build utils)
<roelj>bavier: Thanks
***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!
<bavier>np
<JeanLouis>bavier: I would like to, but how?
<JeanLouis>that is why I am trying this
<bavier> https://www.gnu.org/software/guix/manual/html_node/Substitutes.html
<JeanLouis>/gnu/store/632msbms2yaldfnlrb5lbnlnmn9yjisw-guix-0.9.0/bin/guix-daemon --build-users-group=guixbuild --substitute-urls="http://hydra.gnu.org"
<JeanLouis>and if I use substitute-urls with guix package -i -- it simply starts compiling
<JeanLouis>I understand substitutes shall be downloaded as binaries
<civodul>and you authorized the key etc.?
<JeanLouis>anyway it is good that I can compile myself, so I will give it time
<JeanLouis>yes yes civodul
<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>like wget or something?
<JeanLouis>and package is already compiled?
<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>JeanLouis: that could explain it
<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>civodul: fyi, I finally tracked down the problem with my new fast grafter. it used 'get-bytevector-n', and I was bitten by <http://bugs.gnu.org/17466>
<mark_weaver>for now, I've worked around the problem by using 'get-bytevector-n!' instead
<bishopj>bavier: Thank you :D
<mark_weaver>on my X60, it substitutes texlive-texmf in about 12 minutes
<civodul>mark_weaver: oooh, that bug is still there, right
<civodul>terrible
<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.
<rekado>yay
<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.
<davexunit>help wanted :)
<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?
<davexunit>hopeless?
<civodul>hmm wait
<civodul>i meant terribly-difficult endeavor
<civodul>i think i'm mixing words
<davexunit>oh okay :)
<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: hehe ;)
<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>yeah.
<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
<mark_weaver>literally "without hope"
<civodul>ok, i see :-)
<civodul>ACTION goes afk, ttyl!
<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>something like...
<JeanLouis>how many people use GuixSD with X running?
<JeanLouis>as I will need some days, if not weeks to make it: http://rcdrun.com/images/upload/tmp/2016-03-10-18:41:28.jpg
<bavier>JeanLouis: I think most do
<davexunit>JeanLouis: you should use substitutes
<janneke>JeanLouis: ?
<davexunit>so that you don't have to build everything
<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
<davexunit>you've configured it wrong, then.
<mark_weaver>bavier: what are you trying to do?
<JeanLouis>I did exactly step by step as on https://gnu.org/software/guix/manual/html_node/Binary-Installation.html
<JeanLouis>and I am only making "pwgen"...
<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.
<JeanLouis>so I don't know.
<JeanLouis>but you run GuixSD with X?
<mark_weaver>JeanLouis: I run GNOME 3 on GuixSD
<mark_weaver>I think most GuixSD users are using X
<mark_weaver>JeanLouis: did you run "guix pull" ?
<JeanLouis>I did, as root
<JeanLouis>but I think it uses 0.9.0, not 0.9.1
<JeanLouis>so GuxSD is usable?
<mark_weaver>I've been using it on my primary machine for well over a year
<mark_weaver>several of us do
<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.
<JeanLouis>aha
<janneke>we really need a `recommended usage guide'
<janneke>including ~/.config/guix/latest etc
<JeanLouis>I have latest only not latest version
<JeanLouis>I am doing now guix pull
<JeanLouis>And I see lines like: gcc-4.9.3/libstdc++-v3/testsuite/26_numerics/
<JeanLouis>some kind of unpack
<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
<JeanLouis>like this
<JeanLouis>is it supposed to simply download?
<paroneayea>hyperreal: I don't use ntpd :)
<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 :)
<paroneayea>hyperreal: but I *do* have a dual booting setup
<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: ok so I am good I guess
<paroneayea>and the same home directory!
<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?
<paroneayea>wow! looks like it's time to update icecat :)
<JeanLouis>mark_weaver: yes I remember, it downloaded and finished
<JeanLouis>guix pull --verbose
<JeanLouis>I have it in my command history
<mark_weaver>JeanLouis: as a temporary hack, you could make ~/.config/guix/latest a symlink that points to ~root/.config/guix/latest
<JeanLouis>the version 0.9.0 is not recent I guess
<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
<mark_weaver>JeanLouis: no, 0.9.1 is not yet released
<JeanLouis>aha ok
<JeanLouis>but -- if I use GuixSD -- can I still, install various stuff in my /home without being removed?
<mark_weaver>without what 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
<fhmgufs>GuixSD?
<mark_weaver>fhmgufs: I'm typing this on a Libreboot X60 running GuixSD with GNOME 3 right now :)
<fhmgufs>Great!
<JeanLouis>mark_weaver: I read that GuixSD will remove from /usr /var etc. anything that was not installed by GuixSD
<fhmgufs>So, it runs well?
<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>and network manager doesn't work for me yet.
<efraim> https://github.com/libcheck/check/releases any suggestion on which to download?
<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>heh :)
<fhmgufs>But, what processor are you using?
<mark_weaver>also, the system is not as stable as I'd like.
<mark_weaver>I don't know whether the problem is in recent libreboot itself, or recent kernels, or what
<mark_weaver>but this system crashes fairly frequently
<fhmgufs>Oh :(
<mark_weaver>e.g. switching from X to text console sometimes just gets stuck and I need to power cycle
<fhmgufs>But that's not Guix related, right?
<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.
<fhmgufs>Yes, Ok.
<fhmgufs>So what would you recommend?
<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.
<fhmgufs>That's what I would do.
<mark_weaver>the process is documented on libreboot.org
<fhmgufs>Ok, thanks.
<mark_weaver>and there's #libreboot here on freenode for suport
<mark_weaver>*support
<janneke>fhmgufs: x200, is that tp x230 too?
<davexunit>janneke: no
<fhmgufs>No, I don't think so.
<davexunit>x220, x230, etc. are hopeless for libreboot support
<janneke>OK, too bad, thanks
<mark_weaver>janneke: https://libreboot.org/faq/#intel
<davexunit>you can blame intel for that
<janneke>ACTION does not believe in the concept of blame
<janneke>;-)
<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: yes, i can see that
<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 people buy such stuff
<janneke>it's sad that media don't report such things
<janneke>i do not believe in illegal or punishment ;-)
<janneke>i believe in informed choice
<janneke>i am drifting off-topic, the libreboot thing inspired me!!
<davexunit>in other news, ATLAS is a complete nightmare.
<davexunit>I've been building it for *hours*
<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
<davexunit>and unfortunately it's a dependency of Kaldi http://kaldi-asr.org/
<davexunit>bavier: is it a drop-in replacement?
<bavier>I can't imagine kaldi would need specifically atlas, just any blas/lapack implementation
<davexunit>bavier: I'll try with openblas then
<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 :(
<davexunit>unsubsitutable packages make me sad.
<davexunit>it certainly builds way faster, though.
<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
<davexunit>\\"
<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
<mark_weaver>(from the guile REPL)
<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...
<davexunit>lfam: ./pre-inst-env guile
<lfam>Ah
<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..."
<lfam>BTW, discussion of features related to scripts in Guix and Nix: https://microca.st/clacke/note/-sNe2UQDR-S63VFLgZ0Sdw
<mark_weaver>lfam: use \\\\( in the pattern and just plain ( in the replacement
<lfam>Ah, thank you!
<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 \\\\
<mark_weaver>emacs has the same regexp escaping issues
<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>s/ther /the /
<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: okay, sounds good
<suitsmeveryfine>mark_weaver: how come perl still needs to be built locally?
<mark_weaver>suitsmeveryfine: because hydra currently doesn't build grafting replacements
<suitsmeveryfine>I see. Is there a way to turn of grafting?
<mark_weaver>you shouldn't turn off grafting, because if you do, you'll have security holes in your system
<mark_weaver>but, if you want security holes, --no-grafts
<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 don't want remote holes though
<suitsmeveryfine>I can alway keep trying to install GuixSD. It's almost become a ritual.
<lfam>The Perl build fails for you?
<suitsmeveryfine>Ifam: sometimes, yes
<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 :/
<suitsmeveryfine>Sometimes I also get a suspisous ownership error
<suitsmeveryfine>Let's see if that one will show up tonight.
<davexunit>lfam: looked at that microca.st link. I'm unconvinced that we should copy nix-shell in this way.
<davexunit>and we of course wouldn't use /usr/bin/env
<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"
<lfam>I mean, "would be"
<davexunit>I've long wanted 'guix environment' integrated into emacs
<davexunit>that would be a big boost to my workflow
<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.
<davexunit>like spawn a guile repl
<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
<lfam>That didn't help me
<paroneayea>I ran into problems, but did not clear my cache
<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`
<efraim><3 guix environment
<rain1>yeah :D
<davexunit>efraim: love seeing success stories like this. :)
<suitsmeveryfine>ABC was a great band
<suitsmeveryfine>No finally I got the build failure. "some substitutes for the outputs of deriviation '...geoclue...' failed (usually happens due to networking issues)
<suitsmeveryfine>*Now
<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>oh that sucks
<suitsmeveryfine>yep, it's close to uninstallable
<paroneayea>hey davexunit
<davexunit>hey paroneayea
<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>paroneayea: sure
<suitsmeveryfine>rain1: GuixSD is beta software
<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
<rain1>??
<suitsmeveryfine>I don't expect it to work flawlessly, but it takes a lot of my time to just keep trying to install.
<paroneayea>I'm very interested in adding it, basically.
<davexunit>paroneayea: cool :)
<paroneayea>it would improve my quality of life a lot now that I use guix environment every day ;)
<davexunit>I'll probably be back online in 4-5 hours.
<bavier>suitsmeveryfine: not everything needs to be downloaded again, just the package that failed to download
<suitsmeveryfine>bavier: oh, is that so?
<suitsmeveryfine>In that case it's much less bad than I had thought.
<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
<suitsmeveryfine>need to go AFK
<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
<paroneayea>lfam: maybe..
<paroneayea>also, what
<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>but there is no /mnt/var/guix...
<paroneayea>I wonder if I did something terrible in my debian + guix setup :)
<paroneayea>that lead to this
<JeanLouis>bavier: thanks, I just needed to learn about versions
<bavier>JeanLouis: np
<lfam>paroneayea: Does it work? ;)
<paroneayea>lfam: haven't tried adding to /var/guix/gcroots
<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: still around!
<paroneayea>I think...
<paroneayea>let me double check :)
<paroneayea>yup
<paroneayea>how does this even work still? ;)
<lfam>Weird ¯\\_(ツ)_/¯
<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...
<paroneayea>I wonder if I should re-symlink...
<paroneayea>before something crazy happens!
<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>JeanLouis: it works for me
<bavier>but my guix might be slightly out-of-date, lfam's suggestion might work
<suitsmeveryfine>a_e: do you happen to be around?