IRC channel logs

<davexunit>bleh, new avr problems

<davexunit>avr-libc now fails to build since the last time I tried doing this

<NiAsterisk>there's maybe lots of traffic in the bugs list, so before going offline, I wanted to point out the rather minor, but sort-of-quality affecting bug#22543 which is about a dead link in one manual section.

<NiAsterisk>If i knew where it should lead to, I could just fix it. I hope the link I guessed is the right one. if so, I'll fix it as soon as somebody can reply.

<lfam> http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html ?

<lfam>NiAsterisk ^

<lfam>Oh, you already mentioned it ;)

<NiAsterisk>so that's it. okay, i'll be off now, but I'll fix the link tomorrow.

<NiAsterisk>g'night

<esteban_>hello, I am currently trying to install GuixSD on a Thinkpad X220 laptop, and I have gotten to the point where I am installing the system to root. First of all the installation has been going for an hour at least. Second, it has stopped at this notification: Starting download of /gnu/store/fzj5j9wrrxca3hya10983inz68sr3lmx-nss3.19.2.tar.gz From ftp...etc etc. What should I do?

***francis7 is now known as sanctuary

<davexunit>esteban_: 'guix pull' and start over

<lfam>esteban_: Can you provide the full URI so that I can test it from my machine?

<lfam>Or that ;)

<davexunit>you're probably building everything from source

<lfam>davexunit: I guess the old nss tarball is no longer available upstream?

<davexunit>which guix tells you about

<davexunit>lfam: 0.9.0 binaries are gone

<esteban_>hold on, let me give the URL

<davexunit>esteban_: if you're using the 0.9.0 release, you need to 'guix pull' before installing

<lfam>davexunit: Yes I know, but that looks like they are downloading the source from upstream and it's timing out.

<lfam>Easily solved by `guix pull`

<davexunit>yeah, just 'guix pull' and move on

<esteban_>ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_19_2_RTM/src/nss-3.19.2.tar.gz...

<lfam>esteban_: I would take davexunit's advice

<lfam>That link just hangs for me too

<esteban_>okay, should I ^C and type guix pull?

<esteban_>okay

<lfam>Yes

<esteban_>ok I will update in a sec

<davexunit>we should add "run 'guix pull' before doing anything" to the MOTD on the installer image

<esteban_>so what I did was install with --fallback option because the installer suggested that after an error

<lfam>We should put it *everywhere*

<esteban_>and so I guess that made everything take an hour, building from source

<lfam>You shouldn't need --fallback after you do `guix pull`

<esteban_>it gave me an error for guix pull

<esteban_>hold on

<esteban_>ok, works now,

<esteban_>I am a newb here, what is 'guix pull' going to do?

<lfam>It's roughly analogous to `apt-get update` if you are familiar with that.

<esteban_>yes I run debian on my this pc :)

<davexunit>esteban_: it updates guix to the latest development version by compiling it from source automatically

<lfam>Guix 0.9.0 was released a few months ago, and we have since deleted the binary substitutes for the packages in 0.9.0. So, you would have had to build *everything* from source.

<davexunit>esteban_: the reason for doing this is because we're currently resource limited in the number of pre-built binaries we can provide. the binaries for the latest stable release have been garbage collected at this point.

<lfam>Also, you would be missing many important security updates

<esteban_>thank you. So after 'guix pull' do I rerun the init command?

<lfam>Yes

<davexunit>I imagine things will still take awhile, but you shouldn't have to build much, if anything, from source.

<davexunit>things download much slower than they ought to, again due to resource limitations.

<davexunit>our userbase has grown beyond what our infrastructure can reasonably support right now.

<esteban_>Got it. Good news and bad news I guess. Is this what the donations are for?

<davexunit>yup

<davexunit>we've received enough to buy new servers

<esteban_>what are substitutes and why does that take a long time to update hydra.gnu.org?

<davexunit>so soon we should have a *much* improved installation experience.

<esteban_>awesome!

<davexunit>esteban_: substitutes are binaries

<davexunit>guix is a source-based distro that will transparently download binaries from a trusted provider, if available.

<davexunit>we call this process "substitution"

<davexunit>because you're substituting your machine for another.

<esteban_>any idea when a stable 1.0.0 will come out?

<davexunit>esteban_: when it's ready, basically. we have a number of things that we'd like to have done before we declare a stable releaes.

<davexunit>release*

<lfam>It's already quite stable, in my opinion.

<davexunit>yeah, it's more about nice features (like LVM support) and more packages (like GNOME)

<lfam>davexunit: How's this for the last line of the MOTD? "Please run `guix pull` before continuing!" Should we explain it at all?

<esteban_>a quick paranthetical should do...

<davexunit>lfam: something like that would be good.

<davexunit>post a patch to the mailing list and see what ludo thinks

<esteban_>is MOTD the 7.1 System Installation page?

<davexunit>esteban_: no, it's the message you see when you login to the installation system

<davexunit>the message that thanks you for being so brave

<lfam>That message is precious

<esteban_>yes, great message! Would you also add the 'guix pull' item to the documentation and the info page on ALT F2?

<davexunit>it should probably be added there, too.

<lfam>Done

<lfam>Sorry, wrong window

<lfam>davexunit: If esteban_ installs GuixSD having `guix pull`-ed in the installation image, will he also need to do `guix pull` again before reconfiguring?

<davexunit>lfam: would be a good idea, yes, because the guix that is installed will necessarily be older.

<lfam>esteban_ ^

<esteban_>roger that

<esteban_>system is still installing

<esteban_>I have to keep running the init command every couple of minutes because of network issue... I wonder if that is just my home network being inconsistent

<calher>davexunit: What's missing in the Mumble recipe?

<davexunit>calher: I don't recall

<davexunit>there were some build failures

<davexunit>I really haven't looked at it in a few months

<davexunit>esteban_: probably not, unfortunately. :/

<calher>davexunit: Could I have a copy of the recipe?

<davexunit>I don't have it on this computer, sorry.

<davexunit>I never uploaded it anywhere. I just hacked on it for a few minutes then gave up.

<esteban_>okay, help needed

<esteban_>I ran out of space

***sanctuary is now known as francis7

<esteban_>so, when I partition, how many partitions should I make

<esteban_>do I make a separate root partition? I just got an error about running out of space

<davexunit>esteban_: its up to you how many partitions you make.

<davexunit>the simplest being one root partition

<lfam>It's really up to your use case to decide how many partitions to make. But /, where /gnu/store lives, should be several gigabytes at least. I'd say no less than 10 if you have the space available.

<davexunit>esteban_: did you run out of disk on that partition or on the ramdisk?

<esteban_>right, I made it 10GB and the error says ... hold on

<davexunit>I suspect that you didn't start the cow-store service like the documentation asks for

<esteban_>I did start the cow-store

<esteban_>guix system: error: copy-file: No space left on device:

<esteban_>is that my root partition /mnt?

<davexunit>did you actually mount the file system?

<davexunit>how big is the partition?

<esteban_>yes, the partition is 9.1G

<esteban_>and yes, I mounted it.

<esteban_>so df -h says it is indeed completely full.

<esteban_>I think I may start from scratch with a 20 G root partition, 2G swap and the rest /home. Will that work?

<lfam>Are you installing with lots of packages in your system declaration file? That does seem excessive...

<esteban_>I used the desktop.scm file with xfce4 and ratpoison? I think

<lfam>The example from the manual? I don't believe that should require so much space.

<lfam>I wonder if the space is being used by your first attempt, before you ran `guix pull`.

<esteban_>hmmm maybe because I used --fallback mode? Or that I almost did a whole install before doing guix pull and then essentially retrying the install

<esteban_>probably.

<esteban_>I will try again

<esteban_>thanks for the help, I think my next attempt from scratch should theoretically work

<lfam>My experience installing GuixSD has been pretty minimal and smooth, so I don't know enough to really troubleshoot it. If it was me, I'd start over. Some other people would want to help you work through it... but I guess they aren't around ;)

<davexunit>esteban_: you're gonna fill up that root partition very quickly

<esteban_>is 20G not enough?

<davexunit>not for long.

<davexunit>when you use guix, it keeps the generations of your system/package profiles

<lfam>I guess my sense of it is miscalibrated since I don't have a graphical environment.

<davexunit>so unless you aggressively remove generations and garbage collect, you'll go through 20G soon enough.

<esteban_>okay so I will make the whole drive /?

<davexunit>20G will last you some amount of time, I'm using 31G right now.

<davexunit>because I don't run garbage collection often.

<lfam>It's a real PITA to garbage collect when you are working on packaging or hacking Guix itself

<davexunit>I like keeping old stuff around for awhile so I only gc rarely

<esteban_>ok

<marusich>Wow, you guys use a lot of storage! My laptop is using 4 GiB of space, 2.6 for / and 1.4 for /dev/mapper/home. Clearly I am not using Guix enough!

<lfam>Heh, how many packages do you have installed?

<marusich>Probably not as many as you.

<marusich>guix --list-available=. | wc -l?

<lfam>Also, once your Guix installation "lives through" an upgrade of something glibc or gcc, it tends increase rather quickly.

<marusich>"guix package --list-available=.| wc -l" says 3081 packages available

<marusich>and there are 3039 entries in /gnu/store

<lfam>Somebody tried to install them recently. Their profile collisions list was tens of thousands of lines long IIRC

<lfam>install them *all*

<marusich>Yeah, I probably am not building stuff very much

<lfam>There's a lot of things in the store that aren't packages. Like derivations and sources

<marusich>I see

<marusich>So how would you find out how many packages you have installed on the machine, not necessarily just in your profile?

<marusich>according to "guix package --list-installed" I have 35

<lfam>I have 35 packages in my profile and 10332 directories in the store

<marusich>:D

<lfam>I'm not sure how you'd figure that out. You could definitely use Unix text processing tools if you really wanted to know, but I'm sure there's a Guile way

<davexunit>marusich: you can't see the number of packages exactly, because packages are just one type of thing that appear in the store.

<marusich>I see, that makes sense.

<davexunit>and packages may create many store directories

<marusich>Is it correct to say that each directory in /gnu/store is a the build output of a single derivation?

<davexunit>marusich: no.

<davexunit>a derivation may have many outputs.

<marusich>I see. Thanks for the clarification.

<esteban_>after copying files, the instalation writes: populating '/mnt' and then an error: failed to evaluate directive: (directory "/var/lock"

<esteban_>guix system: error: chown: No such file or directory

<esteban_>I call it quits. I guess I will try another day

***francis8 is now known as francis7

<civodul>Hello Guix!

<Jookia>o/

<calher>francis7: I don't need Windows 8 when I got francis8.

<calher>civodul: Who was the guy who made up the name "geeks" for Guix?

<civodul>calher: me; it comes from "Guile" + "Nix", hence the pronounciation

<calher>civodul: I can see that. Sometimes I slip and I say /gIks/ instead of /gi:ks/.

<calher>That is, /giːks/ becomes /gɪks/

<civodul>not fully fluent in IPA, what does it sound like?

<civodul>like in "bike"?

<calher> http://b.1339.cf/ivqhovg.ogg

<calher>Sound Recorder is buggy on T7; had to use Audacity.

<alezost>ACTION can always hardly distinguish the difference between /iː/ and /ɪ/

<Jookia>i like to pronounce it you-icks

<Jookia>yeeks is also cool

<civodul>alezost: same here, i can hear the difference, but i cannot really pronounce these two things differently

<alezost>a proper pronunciation is a feature of native speakers :-)

<sneek>Welcome back alezost, you have 1 message.

<sneek>alezost, civodul says: make sure to close #22550 if it's done

<alezost>civodul: how can I do it?

<alezost>I mean as I'm not the one who opened it, will sending a message to <22550-done@debbugs.gnu.org> work?

<civodul>yes

<civodul>or from M-x debbugs-gnu, you can hit C on the bug

<Jookia>emacs has a mode for everything, huh? ;)

<alezost>I've just installed it using "M-x guix-packages-by-name RET emacs-debbugs" and RET on "Install" button :)

<calher>Jookia: How on Earth does one get /j/ from G?

<calher>civodul: I think I've heard Parisians say /ɪ/, and I've certainly heard Quebecers say it.

<calher>/ɪ/ is in the word "poutine".

<Jookia>calher: magic

<calher>I think the pronunciation /guːɪks/ souns cool, but it's not official.

<calher>/guːɪks/ sounds Unixy.

<Jookia>mark_weaver: One noticable advantage of the Novena (or most ARM platforms) over things like Intel chips is the CPUs aren't as buggy

<NiAsterisk>to make changes to the manual, I don't edit .texi , I edit .1 files, right? I ran make clean and make clean-go and make clean-recursive and .texi is still there. I don't know much about what's going on in /doc/ although I've seen a make file.

<davexunit>NiAsterisk: no, you edit the texi files.

<davexunit>that's the source code.

<NiAsterisk>oh. okay. so .1 files are for the GNU manual as in man guix

<NiAsterisk>or how does it all come together?

<davexunit>yeah, those are built from the texinfo source using a special tool

<NiAsterisk>okay

<NiAsterisk>thanks

<davexunit>next time you run 'make' watch for output related to this

<alezost>NiAsterisk: man pages are build from help commands (like "guix build --help"), so if you want to modify man pages, you need to modify the source of .scm file, e.g. 'show-help' proc in (guix scripts build) module

<NiAsterisk>same thing for all source code applies, add the name even if I oly change a link which produced a 404 error before I assume.

<NiAsterisk>ah

<davexunit>ACTION feels the pain of the new magit

<alezost>ACTION is updating magit to a more new version :-)

<davexunit>hope they didn't completely break the UI again.

<davexunit>ACTION is growing tired of magit, but knows nothing better

<civodul>glad i'm not the only one complaining about it :-)

<davexunit>F F

<davexunit>doesn't pull

<davexunit>okay...

<civodul>yes, that's one of the funny things

<davexunit>F u

<civodul>P P doesn't push either

<davexunit>interesting choice...

<civodul>you'll like it :-)

<davexunit>oh, and where the hell is branch manager?

<davexunit>b v

<davexunit>nothing

<davexunit>and no replacement binding

<civodul>it's y

<davexunit>oh good it's still there

<davexunit>thanks

<mark_weaver>sneek: later tell jchmrt FYI, it turns out that all you needed to type at the initramfs guile REPL was: (system* "fsck.ext4" "/dev/XXX"). I'm sorry that I wasted your time with all those long commands, heh.

<sneek>Okay.

<civodul>for a week you'll be confused and angry

<civodul>then it goes better

<davexunit>I'm afraid my muscle memory will cause me to accidentally do something harmful

<mark_weaver>BTW, in case it wasn't already known: all of the FOSDEM talks in the Guile dev room that had no sound have been fixed. Just download them again and it's all good.

<davexunit>I watched a good number of them.

<davexunit>really good stuff in there!

<mark_weaver>indeed!

<davexunit>bummer the earlier talks got lost, but I'm thankful that there's *something*

<davexunit>civodul's talk in the distro dev room is also available

<alezost>davexunit: there is a page about restoring old keys: <https://github.com/magit/magit/wiki/Restore-pre-v2.4-key-bindings>

<rekado>is this still the old new magit or is there another new new magit?

<rekado>I've been using Magit 20150803.337 for a long time now.

<NiAsterisk>hm.. @xref{Guile Preparations, how to install theGnuTLS bindings for Guile,, gnutls-guile, GnuTLS-Guile}. where is the cross reference url? do I just search for an earlier occurence of gnutls-guile in guix.texi?

<efraim>with the tests disabled, python-2.7.11 is a drop-in replacement

<efraim>only 6 tests failed for me, so I'm seeing if I can disable them

<NiAsterisk>i think I won't fix this today. I don't understand the file enough to not break something, and I wanted to finish the other texts I am working on.

<rekado>there's something about the way Python installs are handled in Guix that makes me uncomfortable.

<rekado>can't really put my finger on it.

<NiAsterisk>see you 'll later o/

<rekado>When the default Python 2 is set to 2.7.11, would I have to reinstall modules that were built with Python 2.7.10 or earlier?

<rekado>Or are they really compatible?

<rekado>another thing that really bothers me is propagated inputs.

<rekado>it is annoying to figure out that a new installation of some additional Python module somehow conflicts with stuff in the profile, because both pull in propagated packages.

<alezost>rekado: I think 20150803 is a Magit2 epoch, so your version is not so old. Since then there were many changes but not so crucial as for 1.4 → 2.1 switch. We are talking about 2.4 which reorganized keybindings for fetching/pulling/pushing (there are no "P P", "F F" and other things anymore by default)

<rekado>I don't like that even just dependent Python modules are affecting the whole profile in unexpected ways.

<davexunit>I'm having this weird problem where an avr-libc package I'm hacking on doesn't think it's building on a 64 bit machine

<davexunit>__x86_64__ isn't defined

<rekado>davexunit: have you made any changes to avr-libc?

<rekado>I rebuilt it just the week after FOSDEM and I didn't notice any problems.

<rekado>(did this on x86_64)

<davexunit>rekado: yes, I have a branch that I am reviving that uses a slightly customized avr-gcc and avr-binutils

<davexunit>this used to build

<davexunit>I was trying to rebuild and recreate the problem I was having a few months ago

<rekado>alezost: oh, no more "P P" and "F F" sounds like my muscle memory will have to be invalidated again :-/

<alezost>rekado: it can be returned as described at <https://github.com/magit/magit/wiki/Restore-pre-v2.4-key-bindings>

<rekado>davexunit: I have a modified version on my machine, but I didn't get far in testing it.

<rekado>one really good thing about magit is that key bindings are trivially discoverable.

<rekado>that's also what I like about M-x guix

<davexunit>yeah

<davexunit>that's a bonus

<davexunit>except I couldn't find branch manager, but I didn't C-h b in the magit-status buffer.

<davexunit>rekado: here's the entirety of my changes: http://paste.lisp.org/display/306801

<davexunit>I added search path specifications for avr-gcc, that's about it.

<rekado>hmm.

<davexunit>here's a snippet of the log: http://paste.lisp.org/display/306802

<davexunit>so it's using avr-gcc to compile these things, but tries including stuff from glibc

<davexunit>such as gnu/stubs-32.h

<davexunit>this file is not in my glibc

<rekado>I had a similar issue with my cross-compiler for ARM. I forgot how I fixed it.

<davexunit>gnu/stubs.h was a line like # if !defined __x86_64__

<davexunit>where it then includes stubs-32.h

<rekado>I think I only had this issue when I forgot to apply the proper patches that added the CROSS_* environment vars.

<rekado>it really should not be using glibc, should it?

<davexunit>should avr-gcc be using *anything* from glibc?

<davexunit>heh

<davexunit>you beat me to it

<mark_weaver> "http://dbus.freedesktop.org/releases/dbus/dbus-1.10.0.tar.gz" redirects to "https://dbus.freedesktop.orgreleases/dbus/dbus-1.10.0.tar.gz". Note the missing slash after the host name. oops!

<rekado>:(

<rekado>:)

<rekado>ACTION has no control over facial expressions, it seems

<mark_weaver>ACTION changes our dbus source URI to use https

<davexunit>rekado: maybe I need to add a special phase that clears some env vars?

<rekado>I really don't know. I find this rather confusing. Are CROSS_LIBRARY and CROSS_CPATH set?

<davexunit>environment variable `CROSS_LIBRARY_PATH' set to `/gnu/store/kvfmywl7f9jdmksa2vig1ydhggkigc81-avr-binutils-2.25.1/avr/lib'

<davexunit>environment variable `CROSS_CPATH' unset

***MatthewAllan93 is now known as TuxNinja

<davexunit>environment variable `C_INCLUDE_PATH' set to

<davexunit>`/gnu/store/343spy51132fq9am5v0akjrbl4b8s8rk-avr-gcc-4.9.3/include:/gnu/store/mpgci6nb800ckc8cyi3vhm9i8h17zm2l-bzip2-1.0.6/include:/gnu/store/kz4vzwnm7vdnxbfb3ygc91iv68rjsfmm-xz-5.2.2/include:/gnu/store/iw4xjh2fx7lbil7m7yghz7yyrf6ks8pq-file-5.25/include:/gnu/store/c2ci62qwp62rcpbh9qgmmlyvgszvf8yn-gawk-4.1.3/include:/gnu/store/l1iq0lhklsiw7q7jhlw9cgdkcm6axd38-make-4.1/include:/gnu/store/dki0v5cvf1mhfz571k622xvzi1nyinl2-binutils-2.25.1/include:/gnu/stor

***TuxNinja is now known as MatthewAllan93

<davexunit>rekado: I tried unsetting C_INCLUDE_PATH and now it's compiling

<davexunit>weeee

<rekado>yay!

<davexunit>but I think we still have the problem of avr-gcc not having built all of the libgcc.a files

<davexunit>though the configure script for avr-libc confirms that our avr-gcc supports nearly every AVR variant

<rekado>shouldn't we also build avr-gcc with avr-libc?

<rekado>your avr-gcc is just the cross-gcc sans libc, but with search paths.

<davexunit>rekado: the official documentation doesn't mention that www.nongnu.org/avr-libc/user-manual/install_tools.html

<davexunit>but sure enough: avr-ld: cannot find crtusb162.o: No such file or directory

<davexunit>avr-ld: skipping incompatible /gnu/store/dymbyab9f16fc5dwacpgqxka4ikg2qiw-avr-libc-1.8.1/avr/lib/libm.a when searching for -lm

<davexunit>avr-ld: skipping incompatible /gnu/store/343spy51132fq9am5v0akjrbl4b8s8rk-avr-gcc-4.9.3/lib/gcc/avr/4.9.3/libgcc.a when searching for -lgcc

<davexunit>etc.

<rekado>manolis said something about the avr-gcc retaining the wrong paths, and that building it in multiple stages like a real cross-compiler would be in order.

<rekado>bbl

<rekado>re "cannot find crtusb162.o": last time I had to copy a file like that to the current working directory

<rekado>but "skipping incompatible.*" is worrying.

<davexunit>rekado: yeah that first can be worked around as you said, but for gcc those files simply aren't there.

<davexunit>libgcc, libm, etc.

<davexunit>I'm not sure how to build gcc a second time to get a better result

<davexunit>working from home with my GuixSD workstation. feels nice.

<civodul>davexunit: you're able to work from home now?

<davexunit>civodul: under certain circumstances. Boston is being slammed with a blizzard right now.

<davexunit>we're expecting about a foot (silly imperial measurement, I know) of snowfall

***MatthewAllan93 is now known as TuxNinja

<davexunit>and I can do pretty much everything I need to do via SSH

***TuxNinja is now known as Tux_Ninja

<civodul>oh, snow

<davexunit>yup

***Tux_Ninja is now known as MatthewAllan93

<civodul>interesting: running the daemon in a container under 3.16.0, and the clone(2) call in libstore/build.cc fails with:

<civodul>guix pull: error: build failed: cloning builder process: Operation not permitted

<civodul>(EPERM)

<davexunit>rekado: I did a completely naive rebuild of avr-gcc by blindly adding avr-gcc0 and avr-libc as native inputs. needless to say, nothing changed. ;)

<davexunit>safe to say that I have no idea what I'm doing.

<civodul>oh, the thing doesn't have CAP_SYS_ADMIN

<davexunit>civodul: what type of container?

<civodul>dunno!

<civodul>it's provided by others at work, no idea what's going on there

<davexunit>ah

<davexunit>you'll need a user namespace to get CAP_SYS_ADMIN within that container

<davexunit>(unless the containerized process already is root, which doesn't seem to be the case)

<civodul>yes, i just checked and the environments made by call-with-container do have CAP_SYS_ADMIN

<davexunit>yeah, by default they have it because of the new user namespace.

<civodul>bah, user namespaces unavailable there

<davexunit>lame.

<civodul>ACTION tries --disable-chroot and mails the admins

<rekado>davexunit: I used "(cross-gcc ...)" with the additional libc argument (and also added a fake linux-headers input to satisfy cross-gcc-arguments ... but I'm also not sure what I should get out of all this.

<rekado>I didn't take the time to actually think this through yet.

<davexunit>oh no we don't have an nmap package

<davexunit>is it part of a larger suite of tools?

<rekado>(somewhat similar issues plague my ARM cross-compiler, which seems to have a subtly broken linker)

<davexunit>rekado: :/

<davexunit>I'm never going to be able to hack on my microcontrollers at this rate.

<rekado>manolis said he'd be interested in fixing it (time permitting)

<rekado>I thought I could beat him to it, but I clearly don't know what I'm doing :)

<davexunit>I can't even figure out what I need to figure out in order to fix this.

<esteban_>Hello all, I tried installing guixsd on my thinkpad x220 yesterday. After all the files were downloaded and copied, the message was: populating /mnt. Then, there was an error. /var/lock was not found and there was some error with chown. Anyone have any idea of this. I was here yesterday and cleared up somethings but I still can't get the system to install. Thank you in advance for help!

<fhmgufs>esteban_: Do you use the default GuixSD image, what's your operating system declaration?

<esteban_>yes default. OS declaration, do you mean the config.scm file? I used the bare_bones.scm.

<esteban_>I think I will try installing again today. I will write down the exact error.

<mordocai>It looks like pkg-config's tarball url needs to be updated to be https. At least from my machine, it is being redirected to https.

<mordocai>Which causes the error where gnutls is not loaded

<paroneayea>mark_weaver: http://blog.talosintel.com/2016/02/vulnerability-spotlight-libgraphite.html

<fhmgufs>What exactly does GuixSD to create the users environment?

<fhmgufs>I wonder why there are two shell profile files - /etc/profile created when /etc is populated and the users etc/profile file in the profile. When I use Guix on top of a foreign distro I can only use the one in my profile. Shouldn't the environment variables defined in the /etc/profile file (gnu/system.scm) be defined in the users profile (guix/build/profiles.scm)?

<pecg>Hello. maybe I'm guessing right now that the only part root is still needed for guixsd is for managing the daemons of the system, am I right?

<davexunit>pecg: yeah, that's basically it.

<pecg>davexunit: Besides that, all non-daemon programs will be able to be installed in isolated environments for each user.

<pecg>So user foo could have version emacs22.1 and user bar could have version emacs28, without them interfering against each other

<davexunit>yes, exactly.

<pecg>Same applies for dependencies I guess

<davexunit>each user can manage their own package profile(s)

<pecg>I guess it also applies for individual package using different versions of a dependency.

<pecg>In a same user profile.

<fhmgufs>Well, you can install only one version of a package of course.

<pecg>fhmgufs: But the situation I mentioned is also possible (I know it sounds a little stupid to do so)

<fhmgufs>But you can easily switch your profile forward and backward.

<davexunit>pecg: two applications in your profile could link against, say, two different versions of libjpeg and that would be OK

<fhmgufs>pecg: Ah, you meant package*s*

<davexunit>you couldn't install, say, emacs 24 and emacs 25 into the same profile without conflicts.

<pecg>davexunit, fhmgufs: Exactly

<davexunit>but it's possible to maintain arbitrarily many profiles and even create ad-hoc, temporary environments.

<pecg>I'm eager to find out how this thing works, I mean studying the source code

<pecg>davexunit: And is also possible to test the new package configuration without installing it

<davexunit>without polluting a profile, yes.

<mark_weaver>paroneayea: thanks for that link. bah, it never ends!!!

<paroneayea>mark_weaver: you're welcome / sorry!

<paroneayea>btw, tsyesika sent me a screenshot of her guixsd powered desktop, and I think it's the nicest guixsd desktop screenshot I've seen yet

<paroneayea> http://tsyesika.se/guix-desktop.png

<paroneayea>maybe we should put that on the guixsd screenshot list

<paroneayea>on th guixsd homepage

***wgreenhouse is now known as grinhaus

<davexunit>paroneayea: wow it's beautiful!

<fhmgufs>paroneayea: Wow.

<davexunit>get that on the home page ASAP! :)

<fhmgufs>What's that window manager?

<fhmgufs>Again: I wonder why there are two shell profile files:

<fhmgufs>When I use Guix on top of a foreign distro I can only use the one in my profile.

<fhmgufs>Shouldn't the environment variables defined in the /etc/profile file (gnu/system.scm)

<fhmgufs>be defined in the users profile (guix/build/profiles.scm)?

<mark_weaver>I don't know, I think it's cleaner for the profile one to contain only the variables that are specific to the packages in that profile, derived from the package definitions themselves.

<paroneayea>fhmgufs: bspwm

<mark_weaver>the ones in /etc/profile can be added to .bash_profile if you want them, and may not necessarily be appropriate on a Guix-on-top-of-another-distro situation.

<paroneayea>tsyesika: see? ^^ I'm not the only one who really likes it! :)

<tsyesika>hum

<tsyesika>oh :)

<tsyesika>glad you all like it

<mark_weaver>for example, /etc/profile includes many occurrences of /run/current-system/..., which only exists on GuixSD

<mark_weaver>and /run/setuid-programs

<tsyesika>yeah it's bspwm (window manager), sxhkd (hotkey daemon) and lemonbar (not yet packaged but i probably should submit one for it)

<mark_weaver>and /etc/environment/ which probably won't do the right thing on a non-GuixSD system

<paroneayea>tsyesika: ah yeah, get lemonbar in there then I'll submit a patch to the website

<paroneayea>. o O (... where is the website repo again?)

<davexunit>paroneayea: http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/

<paroneayea>oh it's in the guix-artwork repo, I see

<davexunit>I take a look at http://git.savannah.gnu.org/cgit for the full list of repos

<davexunit>and yeah, then I just guessed that it was in the artwork repo

<paroneayea>I guess my talks in the guix/guile room weren't recorded

<paroneayea>oh wellll

<paroneayea>unless they're still appearing

<davexunit>paroneayea: they were lost. :( I checked

<paroneayea>ah

<davexunit>I think they lost all the talks prior to noon on Saturday, in many rooms.

<davexunit> https://video.fosdem.org/2016/k3201/lost_talks.txt

<jchmrt>mark_weaver: re the shorter command: no problem, thanks for your help. I'll remember that command for next time (if there is one)

<sneek>jchmrt, you have 1 message.

<sneek>jchmrt, mark_weaver says: FYI, it turns out that all you needed to type at the initramfs guile REPL was: (system* "fsck.ext4" "/dev/XXX"). I'm sorry that I wasted your time with all those long commands, heh.

<pecg>paroneayea: When I have mine guixsd installation working I would share and screenshot of the WM I'm currently using

<pecg>paroneayea: I like how it looks yours

<pecg>paroneayea: I'm using bspwm also

<pecg>(pardon my english writing skills have some rough edges)

<paroneayea>pecg: that one is not mine, it is tsyesika's

<paroneayea>no worries about your english :)

<paroneayea>pecg: I'd love to see your screenshot!

<pecg>paroneayea: I'm running gentoo right now, so the only reason I would share is to show how I use bspwm

<pecg>paroneayea: If you want to I can still share it

<fhmgufs>Sorry, had some connection problems. Did I miss sth?

<paroneayea>pecg: ah cool, well I might like to see just because I'm curious about how it looks! :)

<pecg>paroneayea: Well, hold on

<pecg>paroneayea: http://pecg.site/screenshot.png

<davexunit>I always like the screenshots of tiled window managers, but I have realized that my workflow never really fits it.

<davexunit>I basically only ever want 1 of these 3 things fullscreen at any time: emacs, terminal, web browser

<pecg>davexunit: I always prefer tiling. At least one terminal and emacs, maybe mosh running close, but that's it

<mordocai>davexunit: I use tiling window managers mainly for those occaisonal times I want split windows. Most of the time i'm like you, full screen emacs, web browser, and terminal.

<pecg>davexunit: I have been seriously thinking in moving to a complete console based experience, but there are other important things to do right now

<davexunit>if I had infinite time, I'd fix up guile-wm enough to be a daily driver and use that.

<efraim>does python-minimal run tests?

<fhmgufs>mark_weaver: Shouldn't the non GuixSD things go into the profile's profile?

<efraim>looking at the screenshots I realize I need a larger screen

<pecg>davexunit: guile-wm seems promising also, it is on my TODO list

<pecg>Big one I must say

<fhmgufs>mark_weaver: Is this, what the /etc/profile looks like on GuixSD? https://pastee.org/j27ku

<efraim> http://flashner.co.il/~efraim/screenshot.jpg

<davexunit>pecg: the problem with it is that it's unmaintained. I was able to upstream a couple patches, though.

<mordocai>efraim: Did not realize until your screenshot that a guix nonfree community had already started

<davexunit>but I ran into a bug that I couldn't pin down that would force me to kill X.

<mordocai>I anticipated it would exist, but didn't realize it did already

<efraim>oh oops

<pecg>davexunit: Needs some working. My plan is to reimplement a lighter approach, something like wmutils

<pecg>mordocai: guix nonfree? Think I'm lost

<pecg>mordocai: Now i'm not

<davexunit>pecg: what I would do is create a purely functional API on top of guile-xcb a la xmonad

<pecg>davexunit: Exactly.

<pecg>davexunit: xmonad brings me back so many memories, it was the first tiling WM I tried

<pecg>mordocai: I guess that the maintainer should choose a different name for things like guix-nonfree

<pecg>It could potentially make newcomers thing that it is part of the GuixSD project, like the non-free repo in debian

<pecg>*think

<mordocai>pecg: Good point. I'm not sure what would be good for both parties though. Obviously the whole point for the non-free people is that it is using guix so they'd like guix somewhere in the name.

<pecg>mordocai: I mean, people that makes others easier to install non-free packages in distros certainly have the necessary knowledge to understand the difference between free and proprietary, but at least they should make look for a way to make things clear

<pecg>Starting by changing the naming of their non-free projects or initiatives. That's the main reason we have Iceweasel, IceCat, Parabola, Trisquel, etc.

<mordocai>pecg: Yeah, i'm agreeing. I'm just trying to think of something to suggest that might be accepted without argument.

<mordocai>Also, it it says the licensing is "to be discussed" so bringing to their attention any issues they might have trying to license their package files under something besides the GPL might be a good thing too (i'm not well versed enough to be sure of the ramifications in this particular case)

<pecg>mordocai: I certainly doubt they could license a repository containing proprietary software

<pecg>mordocai: They would have to indicate the EULA or whatever nasty thing the original programmers chose to use for every specific binary or non-free source code

<mordocai>pecg: Well so far at least the proprietary software itself is nowhere in the repo, just guile package files to build them. I think you are correct that they need to handle EULAs with the package files somehow though.

<CompanionCube>*cough* pragmatism *cough*

<mordocai>idk, that's definitely just their problem. The name is #guix's problem too though

<pecg>mordocai: That's my point

<mordocai>CompanionCube: The only issue anyone has brought up so far is that the name could lead people to think it is an official guix thing like debian's non-free.

<mordocai>Well, that and the EULA thing that is their problem not ours.

<pecg>mordocai: Very well resumed

<CompanionCube>good points

<paroneayea>nice pecg

<paroneayea>ACTION finally sees the screenshot

<pecg>mordocai: To make a better point and avoid wrong arguments, the linux-libre naming convention doesn't apply (in case someone from guix-nonfree points that to #guix), because linux is already free software, the -libre is to tell people that it is linux without blobs

<pecg>paroneayea: Thanks, I specially like the font

<mordocai>pecg: Indeed.

<pecg>mordocai: By the way, do you know who the maintainer of guix-nonfree is?

<pecg>fps? Right?

<mordocai>pecg: yeah, looks like it

<pecg>mordocai: I'll mail him asking to make something about this

<mordocai>pecg: Sounds good, thanks.

<pecg>mordocai: No problem. This things need to be addressed as soon as they start to happen

<Sleep_Walker>am I right that these files are not needed after compilation? http://sprunge.us/NSUG

<Sleep_Walker>(scenario installing Guix on top of another distribution)

<pecg>mordocai: Done, I hope he answers back with a new name

<Sleep_Walker>davexunit, mark_weaver ^^ ?

<davexunit>Sleep_Walker: I'm not totally sure, I think that at least the binaries for your platform may be necessary

<Sleep_Walker>I feel like cheating and using system's binaries as symlinks

<davexunit>that is very bad.

<davexunit>that will invalidate everything.

<Sleep_Walker>hmmm, maybe

<pecg>I haven't read anything from the manual, but I guess there is an easy way to override variables from *.scm to remove/add features from specific packages.

<Sleep_Walker>the thing is that after bootstrapping is done it should be possible to clean up, shouldn't it?

<pecg>Like having emacs-pecg.scm to custom building certain features from emacs.scm

<pecg>ACTION sorries if his questions confuse others

<mordocai>Sleep_Walker: Are you looking for guix gc maybe? (is not sure of the context of that directory)

<Sleep_Walker>I'm afraid that these files are not in store

<Sleep_Walker>so I don't expect `guix gc' to have effect on that

<Sleep_Walker>at the same time it looks weird that tar, mkdir, bash and xz will be used forever from this location

<a_e>pecg: You can simply inherit from other package recipes and add your own mdofications. Look for "inherit" in recipes.

<pecg>a_e: perfect

<pecg>a_e: That's what I was looking for

<a_e>Good!

<pecg>This is why I love programming, and lisp specially

<paroneayea>lol

<paroneayea>ACTION looks at packaging xscreensaver

<paroneayea>configure: error: Your system doesn't have "bc", which has been a standard part of Unix since the 1970s. Come back when your vendor has grown a clue.

<paroneayea>we have bc, but I thought that error message was funny / over the top

<lfam>I'd bet that error message is probably a couple decades old, too :)

<bavier>I've seen other messages along the lines of "braindead system"

<lfam>jwz is very outspoken :)

<bavier>I'm sure the authors never had conceived of something like functional package management

<rekado>is anyone here familiar with conda?

<lfam>rekado: No, but I saw you mentioned it the other day. Your workplace is going to use it?

<davexunit>never heard of it

<rekado>lfam: we're working on a bioinformatics pipeline and it should be available in the Galaxy system, which now happens to use conda for package management.

<rekado>(Galaxy is a system to wrap bioinfo command line tools, allowing users to wire them up similar to how a modular analogue synthesiser is wired.)

<rekado>conda is a package manager / environment management system.

<rekado>and it seems to have a lot of traction among bioinfo people.

<rekado>(maybe because of Galaxy)

<lfam>rekado: Like the interface of Pure Data?

<rekado>lfam: yeah, kind of like that.

<rekado>I find it hard to advocate for Guix, especially because lesser package managers have a lower barrier to entry

<lfam>As an outsider, it seems that "write once, deploy forever" is pretty important for reproducing experiments. Does conda offer that?

<davexunit>rekado: I hear you, Guix is a hard sell.

<davexunit>ACTION is upgrading a bunch of servers provisioned with Chef right now

<rekado>lfam: well, I don't know enough about conda to say how it compares.

<rekado>it does seem to greatly simplify environment management.

<rekado>it's like it comes with support for environment modules.

<rekado>i.e. you can name environments

<rekado>and keep track of them and switch between them

<rekado>I find multiple profiles a little difficult to use in practise.

<rekado>maybe it would be simpler if there was an interface in Guix to switch to another profile.

<lfam>Agreed. It's not easy to learn how to "export" and "import" profiles as a Scheme novice.

<rekado>you know, without having to re-export environment variables yourself..

<rekado>much like "guix environment" works.

<rekado>"guix env activate ~/path/to/profile" -- or something like that.

<cbaines>Does anyone know if guix system init is save to stop, and then start again? I am running it (to install guix) and it seems to have got stuck (trying to download something).

<lfam>cbaines: Did you run `guix pull` before initializing?

<lfam>Yesterday, a user had that issue, and the process got stuck trying to download NSS from Mozilla's FTP servers.

<rekado>also, conda makes it easy to serialise environments. Do we have a way to turn a profile or environment into a manifest from the command line?

<rekado>here's more about conda's env management features: http://conda.pydata.org/docs/using/envs.html

<lfam>rekado: That is a missing feature. I had to "steal" the manifest format from davexunit's git repos ;)

<cbaines>lfam, No I did not, was I meant to (I can't see it listed here https://www.gnu.org/software/guix/manual/guix.html#Proceeding-with-the-Installation )

<cbaines>and it has indeed got stuck trying to download NSS

<lfam>cbaines: I actually proposed making these changes in the manual yesterday. They aren't "done" yet ;)

<lfam>`guix pull` will update you to the latest version of Guix, including the lastest package definitions. The problem is that you are trying to download a version of NSS that Mozilla has apparently stopped distributing at that URI.

<lfam>I believe that you will also want to do it after the system has been installed, before you reconfigure for the first time. Otherwise, the reconfigure might take you back in time. I could be wrong about that, but I'm sure somebody else will correct me. Howver, AFAICS, there is no harm in running `guix pull` unnecessarily.

<davexunit>wow, the Bournish shell is an awesome hack.

<cbaines>so to continue the installation, I would need to stop guix system init, and then run guix pull, and then guix system init again?

<lfam>cbaines: Basically, yes. Yesterday's user's store had filled with many downloaded sources, and they actually did not have enough space to complete the installation. To be honest I don't know much about the installation environment. My "stupid" course of action would be to start the whole thing over.

<lfam>Does anyone have any better advice?

<lfam>And of course, that depends on the size of the partition that contains your store, and how many packages you are trying to install with.

<lfam>At the very least, I'd do `df -h` and see what you think.

<cbaines>I did try using the desktop configuration, I guess I could try again using the bare system, and once I have that working, try and install more packages

<cbaines>I am installing on a 500GB SSD, so space should not be an issue

<lfam>Oh, indeed!

<lfam>Yesterday's user had a 9 gigabyte /, and they ran out during the second attempt to initialize.

<cbaines>Is there a way to check is NSS is part of the bare configuration?

<Jookia>cbaines: it's not IIRC

<lfam>After you run `guix pull`, you should be updated to fetch an available version of NSS. I'm not sure if it's in the bare-bones example or not. It's _really_ bare-bones.

<cbaines>Is there anything special, or do I just need to run guix pull?

<cbaines>Is that updating the installer, such that the installed system will contain newer packages?

<lfam>Just `guix pull`, and then start again where you left off.

<lfam>Yes, you will get updated package definitions.

<davexunit>and important security fixes.

<cbaines>Cool, trying that now

<lfam>*many* of those

<alezost>rekado: I thought all you need to switch to another profile is just: "eval $(guix package --search-paths --profile=...)", no?

<davexunit>I think these UI issues can be solved.

<davexunit>if this was the biggest complaint someone had about Guix, we'd be in good shape.

<lfam>I thought the biggest complaint was the lack of /usr/bin/env ;)

<rekado>alezost: I don't know if this is sufficient.

<rekado>When using Guix on top a foreign distribution there are other env variables you want to keep

<rekado>as you won't be using the contents of a profile exclusively.

<davexunit>'guix environment' augments without damage

<rekado>right. I would like something like "guix environment" for existing profiles.

<davexunit>there's a branch in which I've made 'guix environment' use profiles

<davexunit>that has yet to be merged

<rekado>because the environment that "guix environment" creates is not reproducible.

<davexunit>this fixes some existing implementation issues, and lays the foundation for stashing environments.

<davexunit>the goal is to be able to do something like 'guix environment --save foo'

<davexunit>rekado: the environments are 100% reproducible.

<davexunit>use the same guix version, get the same environment.

<Jookia>Is it possible to have a command to add ad-hoc packages to an environment from within it? Mutable environments, if you were building

<davexunit>Jookia: you create a new environment.

<Jookia>I could I suppose

<davexunit>guix environment --ad-hoc guile

<davexunit>oh, I wanted python, too

<davexunit>guix environment --ad-hoc python

<davexunit>that way it's additive

<davexunit>or you can exit the existing environment and build the full thing you want

<rekado>davexunit: but that's the point. Profiles don't change when the version of Guix changes.

<alezost>rekado: but your "other env variables" are kept, as --search-paths changes only the variables that are "defined" by profiles

<davexunit>rekado: OK, then this is what my work on 'guix environment' will give you.

<davexunit>we just need to write it.

<Jookia>Environments are additive? Doesn't that cause some kind of recursion?

<davexunit>Jookia: I don't understand.

<mordocai>I've managed to break my guix daemon somehow it seems. ;(

<mordocai>Oh well, i'll look at it later

<davexunit>you can nest as many sub-shells as you want

<lfam>How's that?

<lfam>mordocai ^

<Jookia>Ah, neato. I thought that'd mess things up somehow

<rekado>alezost: the command you specified above would overwrite PATH, would it not?

<mordocai>lfam: The systemd service just instantly dies and when I start it in the shell and background it the client says connection refused to the socket

<davexunit>Jookia: at your terminal, you can type 'bash' and spawn a new bash

<mordocai>I'm sure I just messed some config or another up

<davexunit>'guix environment' is no different.

<davexunit>by default, it spawns your shell

<alezost>rekado: you can use --search-paths=prefix to append it a profile's PATH to the existing PATH

<rekado>alezost: right, but then switching profiles would grow the PATH.

<lfam>mordocai: I'm not familiar with manually backgrounding systemd services. Are you not just doing, as root, "systemctl start guix-daemon"?

<rekado>it wouldn't return to the previously defined PATH

<davexunit>rekado: so you'd want a sub-shell here.

<rekado>I think so.

<rekado>my point is just that it's very raw.

<davexunit>'guix environment' + profile sounds like precisely the thing you need.

<rekado>and it's easy to do *right now* with other tools.

<alezost>rekado: ok, I'm not going to convince you :-)

<davexunit>I've never seen another tool beyond Nix able to do this well.

<mordocai>lfam: Sorry, as far as manually background I meant running the guix-daemon myself with &. Like guix-daemon --build-users=guixbuild&

<rekado>that's a bad spot for me to be in as I cannot convince others, you know

<mordocai>That seems to "work" as in the process stays up but then guix can't connect

<davexunit>I guess I don't understand the use-case, then.

<davexunit>we're working on environment profiles for pretty much exactly this reason, I thought.

<lfam>mordocai: Did you build from source? In which case, did you configure the localstatedir to be /var?

<davexunit>reproducible environments that can be saved for later.

<rekado>I'm not arguing against environment profiles

<rekado>maybe I'm not expressing myself clearly.

<davexunit>what more needs to be added?

<davexunit>I find it hard to believe that there's something conda can do that we couldn't do.

<mordocai>lfam: Yes and yes. Though the first time I didn't and I had to go back to it so its possible that messed something up.

<rekado>it's not about conda being able to do something we couldn't possibly do. It's about that conda does something and offers a simple interface for it now, and we don't have anything on the same level of ease.

<lfam>Does it say which socket is refusing the connection?

<lfam>mordocai ^

<lfam>It's possible the client and daemon where configured with different localstatedirs, which would probably result in something like this.

<lfam>*were*

<rekado>the biologist users here probably won't learn to first start a sub-shell, then "eval $(guix ...)", etc.

<mordocai>lfam: /var/guix/daemon-socket/socket. Owner root:root, permission 666

<rekado>but they know how to use environment modules.

<rekado>Pjotr wrote somewhere that he's offering environment modules that enable Guix software for cluster users, and I think that's a neat idea.

<rekado>even though it isn't very refined.

<davexunit>well let's write something.

<rekado>I think that having a simple way to switch between stable environments is a neat feature.

<davexunit>that doesn't sound particularly hard when we already have profiles.

<davexunit>it's just another frontend.

<rekado>well, before writing it I'd like to tark it through.

<rekado>right.

<rekado>ACTION wrote "tark" but meant "talk"

<rekado>ACTION senses a wee bit of hostility, but maybe imagines things

<lfam>I think we all want to see Guix serve this use case

<mordocai>rekado: davexunit is in at least two convos that I can see, he's probably just being terse

<lfam>mordocai: Is there any output when the systemd service dies?

<rekado>yeah, I guess I'm just tired. Long day, spent too much time banging heads with a conda and Python fan (which somehow translated to "functional anything is for academics; we are pragmatics"), ...

<davexunit>for me, Guix not being able to do remote deployments to N servers prevents me from advocating for it at my workplace.

<rekado>I just want to make things less intimidating but I don't know how.

<lfam>rekado: That sounds frustrating.

<davexunit>we'll get there, but we need time.

<mordocai>lfam: Nothing to the terminal. It is important to note that I am running on top of debian testing so that could be a factor. Here's systemctl status guix-daemon http://lpaste.net/151912 (the weird thing to me there is it says it was killed by TERM).

<lfam>Some people just can't imagine that things could ever get *that* much better

<davexunit>some people won't be satisfied with anything unless it is *exactly* like what they already know and love

<lfam>mordocai: That's the same system I'm using. Can you share the service file?

<davexunit>rekado: could you perhaps create a guix extension that provides a UI that closely resembles what conda does?

<mordocai>lfam: Possible source of the problem there, I forgot but I modified it to point to the git repo using pre-inst-env. Paste here: http://lpaste.net/151913

<davexunit>maybe the reality is that Guix just can't reasonably replace conda right now.

<davexunit>unfortunate, but with time we can include the tools to eat conda's lunch.

<davexunit>just like I intend to eat Chef and Docker's lunches.

<lfam>:)

<mordocai>lfam: Do you know if that would cause problems or not?

<rekado>davexunit: I could draft something, I guess.

<davexunit>even coming up with a proposed command-line syntax could make the goals more clear

<lfam>mordocai: It depends on the value you gave for localstatedir when you configured and built from your git checkout.

<rekado>what bothers me a little is that other package managers really do seem "simpler" (maybe because they really *are* simpler in that they have a smaller scope and are less principled).

<Jookia>rekado: well, most package managers only handle installing/removing a fixed set of packages- they don't handle the configuration of your system or bootstrapping to other systems

<lfam>I think that the basic UX of querying, installing, and removing packages with Guix is the simplest one I've found. Although I've only used "system" level package managers, and never something domain specific like Conda.

<rekado>it makes it harder to sell Guix when the main use case ("I want packages installed and don't make me think") is already covered.

<lfam>That's fair

<davexunit>right, it's hard to make people think about the greater issues that Guix solves well that others don't.

<lfam>The really special stuff is not so dead-simple yet

<davexunit>I bet conda relies on stuff assumed to be provided by the host distro

<davexunit>which makes it simpler

<rekado>I'm hoping for more blog posts and articles that show-case what Guix can do really well

<rekado>right, it sits on top of the host system -- and that has implications for reproducibility.

<Jookia>try reproducing a debian install

<mordocai>lfam: It should be /var, is there a way to check after the fact?

<rekado>Jookia: "easy! Download this Docker image! It's 100% the same as the one I downloaded earlier."

<davexunit>rekado: right, so either people will care about these problems or not. if they don't care, I'm not sure what can be done.

<davexunit>Docker, in particular, is something that we'll have to continue "fighting" against.

<davexunit>because it's reproducible enough for almost everyone, apparently.

<Jookia>rekado: "What if I want to do security updates?" ":|"

<lfam>Give it a few years. When nobody at a business can remember how to create their snowflake Docker image...

<mordocai>Jookia: Roll a new docker container! IMMUTABLE INFRASTRUCTURE! BUZZWORDS HERE!

<rekado>¯\\_(ツ)_/¯

<davexunit>I like to point out that Docker doesn't compose well. it only does containers.

<davexunit>if you learn Guix, you can apply your knowledge of Guix to every type of environment, virtualized or not.

<Jookia>Fantastic!'

<davexunit>but some people won't be convinced by that, they'll think Guix is "bloated" and talk about the "unix philosophy"

<davexunit>moral of the story: haters everywhere, man.

<rekado>davexunit: I really like how we can use containers with "guix environment". Thanks again for that!

<davexunit>:)

<davexunit>and that needs improvement too!

<Jookia>The UNIX philosophy, so good the creators moved to Plan 9 then Inferno

<davexunit>it doesn't do networking!

<davexunit>can't compete with Docker without that!

<rekado>when I get time to hack I'd like to play with it to see if we can build a faux-Debian container and do "Debian things" in there.

<davexunit>should be able to

<davexunit>brb switching computers

<rekado>i.e. binding all packages to their expected global locations and run apt-get inside of it

<rekado>"see, you don't need Docker for lightweight virtualisation*" (*conditions apply)

<lfam>The sell will harder since Debian disables the features required for Guix containers out-of-the-box

<lfam>will *be harder

<Jookia>so doeseth arch

<civodul>rekado: could you email wishlist items to bug-guix for good ideas we could still from Conda, like env var management etc.?

<rekado>lfam: is this a runtime thing or a kernel config setting?

<Jookia>rekado: kernel

<lfam>I believe you can change it at runtime by writing to the sysfs, although I'm not sure.

<Jookia>oh! on debian it might be runtime, on arch it's disabled for security reasons

<rekado>civodul: yes! I'll try to do this tomorrow --- if I'm able to constructively articulate my vague grumpiness then :)

<civodul>sure :-)

<rekado>ACTION signs off

<rekado>happy hacking!

<Jookia>o/

<myglc2>davexunit: You said, "if you learn Guix, you can apply your knowledge of Guix to every type of environment, virtualized or not." Forget re-applying knowledge, my plan is to never waste another minuite looking at a distribution or build or config or container system again (er, once I am done "wasting" time on guix ;)

<lfam>myglc2 +

<lfam>1

<Jookia>From what I can see to get an icon set working in GTK you have to create an icon package, you can't just put icons in your home folder

<Jookia>Is this true

<lfam>Here is a thread about that: http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00645.html

<davexunit>myglc2: :)

<davexunit>let's hope it works out

<myglc2>davexunit: You are well along the way, IMHO.

<davexunit>:)

<davexunit>alright, time to chip away at the ongoing blocker for remote guix deployments: establishing a guix-daemon connection over ssh

<Jookia>that sounds really cool

<civodul>davexunit: guile-ssh's dist modules should help; otherwise 'socat' as a first approach?