<mbowcutt>Any ideas or known reason why running guix commands sends a SIGPOLL and disconnects the user session?
<brendyn>I discovered that the issue with file managers showing all the system mounts disappears when I run the program with dbus-launch. It also fixes my problem where evince doesn't remember the last page I was on for documents
<efraim>Interesting, would be nice to make it permanently like that
<g_bor[m]>Does shepherd have anything like systemd daemon reexec?
<efraim>looks like my fdroidserver package depends on python-pyqt, which makes `guix size fdroidserver' more than 2GB
<brendarn>That's one thing i've wondered about guix with regards to reprocible builds in science. If someone builds an environment in guix in 2018, then i try to reproduce it in 2020, i'm actually going to make an updated version of the environment, if possible, unless they archive a tarball of all the binaries they had and I have a way of instatiating it.
<mbakke>rekado: I think the main problem with the original 'rebuild bytecode' phase was that you forgot to set PYTHONHASHSEED!
<jlicht>brendarn: you would need to use the same guix commit in that case
<brendarn>jlicht: which makes me wonder if we can produce some way of getting back to that old commit
<efraim>mbakke: any feedback on removing/replacing the python-updates branch?
<jlicht>vagrantc: I do like the /PACKAGE/VERSION/HASH thing though, if only because it would mean that pressing <TAB> in emacs when navigating /gnu/store/... would not cripple my laptop that much anymore
<jlicht>it does not seem insurmountable indeed :-)
<daviid>ACTION also thinks using guix as a repo 'prefix' would be better then gnu
<snape>I don't remember anyone else said it would be better ;)
<daviid>snape: someone suggested guix earler, but I can drop the also if that's a problem :)
<brendarn>I'm happy implicitly supporting the GNU project with it
<daviid>brendarn: but in the store, you'll find free s/w that are not part of gnu ... to me, /guix or /opt/guix if for debian inclusion would be better, but nothing 'really' important, sorry I did shim in ... back to work now
<brendarn>daviid: I was thinking of also suggested changing the package names from hash-name-version to name-version-hash but maybe that's just causing too much trouble :p
<pkill9>brendarn: the reason the hash is first is so you can autocomplete to the hash easier
<brendarn>pkill9: I thought it'd be nice to be able to type emacs and tab to show all versions of emacs in the store
<brendarn>nice with echo. i tried ls but it would show me the contents of the directory too
<wigust->brendarn: ‘ls’ has a ‘-d’ option to show the directory itself.
<kahiru>hey, is there an ETA on LVM support in mapped-devices?
<mbakke>kahiru: No one is working on it, so "future" is my best estimate :)
<kballou>mbakke: what would it take? the service? anything defined in file-system? I've only been poking around and those are the two that standout to me...
<mbakke>kahiru: I've tried working on it (briefly), the main obstacle was that the static LVM package is broken (it depends on lots of things). Another is that the mapped-device interface somewhat ironically does not map well to the device-mapper command.
<mbakke>None of these are insurmountable, but it will take considerable effort. You up for the challenge? :)
<kballou>kahiru: sorry to hijack, but I've been curious about the same thing
<kahiru>kballou, not problem, glad to see there's someone else interested
<kballou>mbakke: we'll see, I'm still trying to dig in :)
<kballou>mbakke: I probably need to submit some bug reports or help messages since guix on gentoo-hardened doesn't seem to be entirely working :|
<mbakke>kballou: Oh, what seems to be the problem on gentoo-hardened?
<mbakke>Speaking of which, we could use some hardening efforts in Guix too!
<kballou>mbakke: I get some backtrace errors with ice-9 with most commands, `guix pull`, `guix refresh`, `guix lint`... `guix package` seems to be working, so, the main one works ;)
<mbakke>kballou: Oh no! Did you compile guix from source using the hardened toolchain, or are you using the binary tarball?
<kballou>mbakke: I don't think a non PIC exception has been made... that might fix somethings but I haven't thought to test it yet
<kballou>mbakke: but that seems like a poor solution...
<mbakke>kballou: I suspect a proper fix would have to dig deep into the Guix toolchain, since Guix "replaces itself" once you've `guix pull`-ed.
<mbakke>Anyway a starting point could be to see if Gentoo has any hardening flags for Guile and try to adapt them to our package.
<kballou>mbakke: it probably doesn't help that guile moves fairly slowly in gentoo, IIRC. I will look what's available there, maybe try disabling some of the hardening to test. I've been avoiding this because I thought I would have to recompile my entire profile...
<bavier>the tests/pack.scm test requires either substituting or building a significant number of packages in order to complete.
<bavier>currently for me it's so far bootstrapped glibc and is now working on gcc-5.5.0
<ecbrown>i'm considering adding a number of options to openssh configuration, akin to x11-forwarding? such as gateway ports. before embarking on this, i thought i would check in since its a central service and there might be strong opinions.
<nee`>I can't figure out this missing <stdlib.h> error with openrct2. So if anyone else want's have a try upgrading it, go ahead, I probably won't.
<snape>ecbrown: feel free to send a patch per option, and make sure to set the default values as they are upstream, unless you have a good reason not to do so
<ecbrown>snape: right, that's exactly what I'm doing. i will make some small changes to ssh.scm and the documents and send it it for review.
<snape>great, I'm looking forward to reviewing them!
<kballou>has anyone done some customization for emacs and `guix environment`? I would like to keep the same emacs server running, and just be able to associate `guix environment`s with a projectile or similar... or are the nix-modes going to work for this?