<mark_weaver>JeanLouis: "guix gc -d" can be used to remove specific paths from the store, but it will only do that if it cannot see any references to those paths from other places in the store (or /var/guix/gcroots)
<JeanLouis>I was expecting if I do -i emacs -- to get binary emacs, not the ony that was compiled without gdk-pixbuf incorrectly
<mark_weaver>JeanLouis: what do you mean by "that was compiled without gdk-pixbuf incorrectly" ?
<JeanLouis>I did not really try to build, guix did that automatically.
<JeanLouis>if I try to remove it, it won't work. I am thinking in equivalent to apt-get purge package
<mark_weaver>if you run "guix gc -R /gnu/store/...-emacs-24.5" it will print out all the things that it references, directly or indirectly. if gdk-pixbuf in that list?
<JeanLouis>I have gdk-pixbuf. Now I got emacs-no-x at least is that one solution, that I don't need to use -nw flag
<mark_weaver>anyway, if you want to delete the package from /gnu/store, you first need to delete all other references to it in the store (e.g. any profile generations that include it), and then you can run "guix gc -d /gnu/store/...-emacs-24.5"
<JeanLouis>too hard to understand. I am testing guix to learn to use it for long time later. I rather not work by hand.
<JeanLouis>ok going to bed, never mind... tomorrow is the next day.
<suitsmeveryfine1>I used rain1's configuration with encrypted /home (/dev/sda2) and made this interesting observation: with a bare-bones config I can type in the LUKS password and log in normally, but with a desktop configuration the keyboard doesn't work when I'm asked for the /dev/sda2 password.
<mark_weaver>suitsmeveryfine1: you might have used two different versions of guix to create those two systems
<mark_weaver>it's worth noting that every version of guix includes an older version of itself
<suitsmeveryfine1>yes, that seems to be the case because the newer version had an older kernel (4.4.4 (alpha).
<suitsmeveryfine1>I ran `guix pull` and I'm reconfiguring again based on the same desktop definition.
<mark_weaver>so, if you don't run 'guix pull' (or equivalent) as root, then every time you "update" your system with "guix system reconfigure", your version of guix will get older with each iteration.
<mark_weaver>I can imagine some hacks to work around this problem, but I'm not sure it's worth it, because really you need to update your system anyway. staying in the same place is not much better than going backwards. you need to keep up-to-date because security holes are being publicized all the time.
<Acou_Bass>my laptop is a bit too slow to compile BIG things reasonably but if its fairly small ill be happy to test it hehe
<Jookia>Acou_Bass: For testing? Hmm, it depends. You just need to recompile GTK and an application to test to see if it fixes the issue. Though if you were to use the patch for all your desktop you'd need to recompile basically everything that relies on GTK
<mark_weaver>"I’ve been in touch with Midori, but they say they don’t have the resources to fix it, since it would require rewriting large portions of the code base in order to be able to use the fixed webkit."
<mark_weaver>but I would say that no one in their right might should use a web browser that's stuck on the old webkitgtk, because that's a case where the engine is being exposed to potentially hostile network data all the time.
<NiAsterisk>speaking of webbrowsers: idk if I was thinking out loud about this on the weekend, but I looked into torbrowser vs icecat vs iceweasel, and I think I can do a torbrowser fitting for GuixSD, it looks easy enough but I can't guesstimate when I could be done
<mark_weaver>NiAsterisk: it would need to avoid at least as many bundled libraries as our IceCat package does, and also avoid suggesting that the user install nonfree software (e.g. media codecs or plugins/extensions), to comply with the GNU FSDG.
<mark_weaver>I would much prefer to have something that complies with the FSDG added to Guix itself.
<dmarinoj>I like mark_weavers idea, it would be nice to have it in the repo
<NiAsterisk>my plan is to use torbrowser (not compatible to the version of ESR icecat uses according to what I read) and patch it in comparasion to what I find out about licenses etc. the ideal case is the essential basics don't break when I patch out the non compatible add ons
<rain1>I just don't think you can expect cooperation by those people..
<rain1>as you are aware any patches you do may decrease it's anonmity
<mark_weaver>in what way is it not compatible? my recollection is that torbrowser is based on Firefox ESR, just like IceCat
<NiAsterisk>of course I would talk to other people with torbrowser packaging experience I know and see if my packaging is reliable
<mark_weaver>rain1: but on the other hand, there's also a risk that torbrowser is based on Debian, which has a long history of things like individual developers uploading binaries compiled on their own machines
<NiAsterisk>mark_weaver: which is why I said, I will check, let other people check on what I produced to not only rely on my judgement, and then include a statement in the description
<NiAsterisk>I'm not going into this blind and just publish :)
<dmarinoj>rain1: I do not think this will be an issue, I think the only reason that torbrowser-launcher is in debian contrib is because they fech the updated package directly from the torproject website
<NiAsterisk>the talk Snowden gave in the BCC in berlin had something weird.. like a floating image above people at the conference, speaking against surveillance etc all in a building constrcuted in times when Stasi used to be around in east.
<NiAsterisk>also what we did in gentoo (not portage) was a post-install message like: "this patched firefox build is _NOT_ recommended by Tor upstream but uses the exact same sources. Use this only if you know what you are doing!" etc etc
<NiAsterisk>paroneayea: I will package powwow-chat later as some kind of powwow which just changes defines.h:#define CMDSEP ";" to "§" so this could be better used for telnet only chat, just in case you are curious.
<NiAsterisk>my initial description assumed that lynX did almost no changes and provided only a config for psyced.org use.
<mark_weaver><rain1> if you aim for anonimity then you may have to compromise on things like free software compliance
<NiAsterisk>dmarinoj: okay, looking at packages.debian.org and debians policy on "contrib" archive area, I just have to assume that it is compatible.
<lfam>Also, for python-cryptography, looks like my local update to python-hypothesis is triggering the rebuild (it's a build-time dependency for testing). But it didn't show up with `refresh -l` so I didn't expect it.
<lfam>mark_weaver: Does that mean we are really getting to the next release?!
<mark_weaver>I think we don't have nearly enough disk space on hydra, and possibly also that our current methods for choosing which things to remove from the gcroots is not sufficient in a case where we haven't done a core-updates cycle in a long time, as is the case now
<mark_weaver>the recent stream of security updates has caused us to postpone core-updates for an unusually long time, and I think this is exposing problems in our retirement strategies on hydra
<lfam>Do you mean that we can't provide substitutes for a wide enough range of our git history?
<lfam>Because I definitely have the problem locally ;)
<mark_weaver>the bigger problem may be that we are retiring substitutes that haven't been built in over 60 days, and that in this case that might include some core packages that are needed by current master.
<mark_weaver>historically, we've done core-updates cycles more often than every 60 days, I think.
<lfam>Oh, I was thinking that we would be leaving new 0.9.0 users behind before releasing 0.9.1. But if we are GC-ing parts of current master, that's too bad
<mark_weaver>but I think for the first time that I can recall, we've not done a core-updates cycle in a long time, because of all the security-updates churn
<lfam>Is substitutes storage limited by our current hydra.gnu.org front-end VM, or is storage delegated to the build machines?
<mark_weaver>well, I've restarted the builds on hydra, including the security-updates branch (which eliminates grafts in the hopes that 0.9.1 can be graft-free), so I guess that may end up rebuilding things that have been lost and are still needed.
<mark_weaver>substitutes storage is limited by the master machine, hydra.gnu.org
<lfam>Well, soon there will be a new release, and then a new machine! Things can only get better, right? :)
<mark_weaver>our storage requirements have been steadily increasing over the last year, but our disk on hydra has remained fixed
<lfam>efraim: See, this is why I bring it up in public ;) I've never built that
<Acou_Bass>can i ask a slightly dumb question? whats the 'recommended' way of updating the core system, is it just guix pull and then guix system reconfigure mything.scm?
<phant0mas>can someone that runs linux on a x86_64 machine try to build avr-libc and tell me what happens?
<lfam>Acou_Bass: Yes, that's the recommended way. Since each user has their own copy of Guix, you will have to run `guix pull` as root in order to reconfigure with the new changes. You'll probably also want to `guix pull` as your regular user as well.
<lfam>suitsmeveryfine: Do you see the line in the icedtea-6 package definition where the path to `strip` is provided? I'm suggesting you try something similar for OpenTTD. It has nothing to do with Java.
<suitsmeveryfine>lfam: no, sorry, I can't find it, and I only see icedtea 2.6.4 and icedtea 1.13.10.
<lfam>On git commit 03422bf83444f, it's line 351 of java.scm
<lfam>You might have to fetch the latest from git. I pushed that commit a couple of hours ago.
<lfam>No, that line is setting the variable named STRIP with the value of `which strip`. That is, with the path to `strip`.
<lfam>You'll need to figure out how you can pass this value to the configure script. Maybe `./configure --help` will tell you that there is some variable. Or, you might want to augment $PATH. I'm not sure, it really depends on OpenTTD's build system.
<suitsmeveryfine>Okay, but I don't believe that I have strip installed in the first place
<rain1>would you like to paste your package so far?
<suitsmeveryfine>rain1: I'm not writing a package definition but simply try to build the software in my home directory.
<lfam>suitsmeveryfine: Okay, then you'd want to set the value of --with-system-zlib to the path to zlib, in #:configure-flags. You can look at the package definition of dvtm for an example of something similar. In that case, the value of PREFIX is being set in #:make-flags, but the mechanism is basically the same