<mark_weaver>goglosh: I just remembered that you're a zsh user, so I guess ~/.bash_profile isn't appropriate. basically, you want to set environment variables within a dot file that gets loaded *only* for login shells.
<mark_weaver>if you set them in dot files that are loaded by *every* interactive shell (e.g. ~/.bashrc or the zsh equivalent), then 'guix environment' won't work properly and there may be other problems as well.
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, artyom-poptsov says: Thanks! If you're interested you may check out the Guile-SSH master branch -- I fixed some bugs and added handling of multiple values to 'with-ssh' after the 0.8.0 release.
<davexunit>it's like Canonical has been willfully ignorant of Nix and Guix.
<davexunit>they managed to build a system that has some key similarities, but with an inferior implementation.
<iyzsong>rekado: I agree to distribute packages witouch Guix as binary tarball is useful, but then without guix and the 'state' db, how to remove those packages cleanly?
<rekado>I would like some really simple mechanism. Right now the barrier to using Guix is not very high, but it still requires thought. I like how thoughtless I can be using the Guix binary installation method.
<rekado>I didn't have to learn anything new; just unpack and go.
<davexunit>rekado: feel free to investigate this should you feel motivated
<rekado>this is why I thought we could be using profiles for this purpose. "guix package -p $PWD/.guix-profile <the environment for this package>" -- and "enable" it by spawning a shell with the environment variables tweaked to reference the local profile.
<davexunit>but I don't know if a profile has enough information
<rekado>It only needs this information at profile creation time, no?
<rekado>and at that point it comes from package information, i.e. the current state of guix.
<davexunit>I haven't looked closely at the profile format
<davexunit>but 'guix environment' needs to be able to set the proper search paths, and in the case of 'guix environment --container' it needs to be able to bind-mount the closure of all environment inputs into the container.
<rekado>don't we get search paths from profiles, too? "guix package -p the-profile --search-paths"?
<iyzsong>davexunit: I think 'add-indirect-root' does what we want. it add a symlink to /var/guix/gcroots/auto, and when the symlink is broken, it can be GC.
<davexunit>iyzsong: thanks. i think a profile may be sufficient here.
<davexunit>and 'guix environment' can use a default profile name in $PWD to reduce typing for the user.
<rekado>I think there isn't so much missing here. Just a way to mean "the environment for this package" that "guix package" can understand, and a script to "enable" a local profile by spawning a shell in which all search paths (as per "guix package --search-paths" magic) are set to whatever the selected profile contains.
<davexunit>'guix environment' would of course still do the search path setting
<davexunit>it would just optionally read from a profile instead of getting package arguments
<davexunit>sigh... too often I see this kind of response when I tell people that Guix packages are code: "Sounds like a security nightmare."
<davexunit>(though I take the bait on too many other things)
<rekado>I *always* swallow the bait when evolution is involved. I don't get an opportunity to explain it in extraordinary detail often enough. I don't do it online, though.
<rekado>but in conversations it's a great filler for any slow evening.
<rekado>actually, I had an idea yesterday night for an educational game about the "simple-minded world of single celled organisms", where random mutation with non random selection is a key game mechanism. I may have to ask you a little more about Sly on #guile when I get started.
<davexunit>the BIOS is proprietary, it has Intel AMT in it, etc.
<mark_weaver>taylanub: Librem requires a huge non-free blob in its firmware, namely the Intel firmware support package, which includes things like AMT
<mark_weaver>which is basically a complete independent proprietary OS running on an independent CPU in the Intel chipset, which has direct access to the BIOS settings, system RAM, and the network (communication in both directions without any knowledge of the main CPU, even when the computer is "off"), etc.
<taylanub>ugh, and then they boast their hardware kill-switches
<taylanub>oh well, I'll continue using my T420 for the time being, but certainly no further Intel devices in the future...
<davexunit>Intel AMT "runs entirely out-of-band with the main CPU. It has DMA access to the entire system memory and can access the networking adapters in a way transparent to the OS (separate MAC and IP)."
<davexunit>nice summary of why AMT is so scary in a couple of short sentences.
<codemac>Suggestions about best way to package a source file like a default config file or something that doesn't exist in the tarball but is something you'd normally package? Right now I'm using a scheme string, but it's filled with backslashes and sadness.
<civodul>how does one fill a string with sadness? :-)
<civodul>seriously though, if the file exists elsewhere, you could just refer to its upstream location
<joolean>Hello, guix folk. I'm trying to get my package to build with guix, and I'm running into an issue. My package installs (among other things) some Guile Scheme modules, and it's failing when it tries to do that:
<joolean>Makefile:360: recipe for target 'install-nobase_dist_pkgguile_siteDATA' failed
<mark_weaver>civodul: regarding the core-updates merge, I guess I'd be inclined to wait a bit longer for hydra to finish building it out. there are still a bit over 100 queued jobs left to build on intel, e.g. libreoffice is not yet built
<mark_weaver>but I don't feel strongly; if you want to do it sooner, that's okay
<joolean>I copied that guy's solution but didn't feel good about it
<joolean>Anyway, I came here for Guix help, and I got it. Thanks! And nice continued work on Guile, civodul and mark_weaver. I haven't been very vocal on the mailing list recently, but you guys are doing good stuff.
<mark_weaver>joolean: thank you for the kind words. I've actually been rather overloaded lately, and not doing as much in guile land as I should.
<mark_weaver>civodul: there's one thing that I think guix is doing wrong, regarding guile module installation: it's installing .go files in the same directory (in 'share') where the .scm files are installed, but that's not right because that's supposed to be an architecture-independent directory.
<mark_weaver>guile installs its .go files in $prefix/lib/guile/2.0/ccache, which seems better
<mark_weaver>and %load-compiled-path contains $prefix/lib/guile/2.0/site-ccache by default
<mark_weaver>it seems like that's where we should be installing .go files, no?
<mark_weaver>and another thing: I think it's a mistake to install *.scm files in a directory that contains "2.0" in the name, because in most cases, the same code can be used in multiple versions of guile, especially with the help of 'cond-expand'.
<mark_weaver>I think this is going to be a huge pain when 2.2 comes out. is every guile package supposed to install files in site/2.0, site/2.2, site/2.4, etc?