<goglosh>the guile-ncurses package may be broken <goglosh>but ERROR: no code for module (ncurses curses) <mark_weaver>what is the output of: find ~/.guix-profile/share -name curses.scm <mark_weaver>and what is the value of the GUILE_LOAD_PATH environment variable? <goglosh>/run/current-system/profile/share/guile/site/2.0 <mark_weaver>what is the output of: guix package -I guile-ncurses <goglosh>gulie-ncurses 1.6 out /gnu/store/<some hash>-guile-ncurses-1.6 <goglosh>maybe if I build instead of download........... <mark_weaver>I'm on a slow machine (Lemote Yeeloong), and it's already busy building something else at the same time, so it may take a few minutes. <mark_weaver>goglosh: okay, I built it, and it contains share/guile/site/2.0/ncurses/curses.scm <mark_weaver>so, if it's installed in your profile, then ~/.guix-profile/share/guile/site/2.0/ncurses/curses.scm should exist <mark_weaver>goglosh: when I asked you to run "guix package -I guile-ncurses", did you run it as your normal user, or as root? <goglosh>which is the user I used to install guile-ncurses <goglosh>yep there it is, in teh path you said <mark_weaver>well, you need to add $HOME/.guix-profile/share/guile/site/2.0 to your GUILE_LOAD_PATH variable <mark_weaver>if 'guile' was installed in your normal user profile, then it would probably be set automatically <mark_weaver>however, if 'guile' is only installed in the system-wide profile, and you install guile packages to your user profile, then I guess the load path doesn't get set properly by default. <mark_weaver>it would be nice to find a good solution to this at some point, but it's not clear how best to do it. <goglosh>man I'm having a hard time understanding this system <goglosh>man I still can't run guile-ncurses :( <mark_weaver>please type that command from the same shell that you are about to run 'guile' from <goglosh>I guess I made some invisible typo before... heh <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. <mark_weaver>goglosh: btw, it would also be good to set GUILE_LOAD_COMPILED_PATH to the same thing as GUILE_LOAD_PATH <mark_weaver>not strictly necessary, but otherwise you will end up auto-compiling those files even though they were already compiled during the build <mark_weaver>but again, this *should* all be taken care of automatically if you install 'guile' in your user profile and then log out and in again. <goglosh>I don't know if I actually installed guile tho <goglosh>oh god it actually told me to manually do the GUILE_LOAD_PATH export <goglosh>I still don't know what I did but I am now using guile-wm, I'm almost inside a lisp machine now <paroneayea>I suspect it never will happen, but I sure wish it would :) <goglosh>I thought I was using guile-wm and I was using windowmaker the whole time <mark_weaver>to run guile-wm, you probably need to create a ~/.xsession script that runs it <mark_weaver>make sure that script has a shebang and is executable <goglosh>I'm a baby I should just go back to ubuntu <goglosh>I like this, even if it gives me headaches. I'm just sorry about flooding the channel with this <mark_weaver>goglosh: no worries, it is useful for us to know about the initial headaches, of which there are several <mark_weaver>fortunately, it seems to be the case that once people go through the pain of getting GuixSD set up initially, it tends to become much more comfortable <mark_weaver>although there are certainly still many missing features and packages <goglosh>well you're right about something. The package management is comfy <goglosh>though, it IS a weird architecture. I still don't know where to put slim.conf for example <goglosh>the whole ~/.guix_profile seems to be a "read-only filesystem" <goglosh>oh I totally forgot there is an /etc/ <rekado>in a meeting people talked about wrapping a workflow in a Docker image to simplify deployment. <rekado>I wonder if there's a more readily usable way to distribute a package closure *without* requiring the other side to use Guix. <rekado>Ideally I'd want something like the Guix binary tarball. <rekado>just unpack the archive and you're ready to use it, as it comes with a self-contained, pre-populated store. <rekado>"guix archive --export" isn't quite enough, I think, as it expects a user to use "guix import". I'd love to have a way to just bundle up tarballs for those who have no intention of using Guix. <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? <civodul>oops, can we choose a different future? <civodul>the key is to be marketing heavy and to put humility aside :-) <davexunit>thankfully, there are some people that know about either Nix or Guix that are questioning Snappy <davexunit>so maybe we can get some good marketting out of it, too ;) <rekado>iyzsong: by removing the isolated output directory. This would work best with a simple means to support a different prefix than "/gnu". <davexunit>rekado: I've thought about writing a script that can "contort" a guix closure into a standalone binary tarball that doesn't require installation into /gnu/store <davexunit>such a script would need to rewrite all store paths to use relative file names so the tarball can just be unpacked anywhere and used <davexunit>but I imagine there are serious complications <iyzsong>maybe ship the closure in an docker XD <davexunit>iyzsong: you know, building something that can run in a guix container isn't the worst idea. <davexunit>but someone wanted to distribute a binary to someone running any ol' distro, it could work. <davexunit>seems too much like proprietary software distribution, though. <rekado>sure, it's not ideal. But I'd rather see people use package closures than docker images. <rekado>maybe they'll get tired of duplication and use Guix proper then. <davexunit>rekado: how you envision it working? with or without guix installed on the host? <rekado>without Guix installed on the host. <davexunit>without that, we need to do some contortions to the closure <rekado>if they had Guix they could just "guix archive --import" or something. <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. <rekado>that's even simpler than docker. <rekado>(disclaimer: I have never used docker.) <davexunit>yeah, though Docker has isolation features that this wouldn't have <davexunit>(unless the binary used call-with-container ;) <rekado>IMO isolation is for "devops" people or "cloud" people. <rekado>the only problem I'm concerned with (and that could be solved easily) is self-contained software installation --- one thing that many people use docker for. <davexunit>that's what it's typically used for, but there also use-cases for "normal" users. <davexunit>I want to run icecat in a container, for instance. <davexunit>with only select directories from $HOME available <rekado>and for *that* feature people would need to make the little effort and install Guix proper. <rekado>but if all they care about is "install all that software in one go; don't make me think" the tarball approach would be sufficient and super convenient. <davexunit>do you think my implementation idea would work? <davexunit>perhaps wrapping a binary or two to set the right paths <rekado>I wonder if there are any problems with max shebang length. <rekado>Here's another thing I was thinking about recently: project-specific profiles. <rekado>with virtualenv or cabal or bundler you can install software in a local directory in the root of the project directory. <rekado>I'd like to use a local .guix-profile instead and have an easy way to .... <davexunit>'guix environment' is the tool already written for virtualenv-like behavior. <Steap>isn't guix environment a bit slow, though ? <davexunit>'guix package -p' can make profiles if you want. <rekado>but the actual contents of the environment change upon invocations of "guix environment" when the underlying guix has changed. <davexunit>Steap: you setup an environment once at the beginning of your hack session and leave it up. it's slightly slow in that it may take a second or two to start. <rekado>I would like to use "guix package -p" more often. <Steap>davexunit: yeah, but even when all packages are built, it seems a bit slow <Steap>Does it do a lot of things ? <davexunit>I use it literally all the time and its not that slow <Steap>Apart from setting environment variables ? <davexunit>yes, it computes a full list of packages to include in the environment <rekado>"guix package -p $PWD/.guix-profile -i all the things" and then spawn an environment from that profile with something like "guix environment .guix-profile" or so. <rekado>and the profile would prevent stuff from being gc'd. <davexunit>it's supposed to be a one stop shop. give it a list of packages and it will build the right thing. <rekado>I'm always sad when I did "guix gc" and the build tools have been collected that I use in "guix environment". <rekado>I'd like to be able to pin these tools in a profile, without needing to explicitly list all these things. <davexunit>oftentimes, I build environments that I want thrown away later. I don't want to get into the business of profile management. <rekado>(I realise that my language is very vague; that's because I don't know how I would want it to be implemented.) <davexunit>maybe there could be a 'guix environment --save' flag or something <davexunit>and a bare 'guix environment' invokation or 'guix environment --load-profile' would load it. <iyzsong>+1 for add 'save' to 'guix environment', write the environment as a guile script, and link it into current directory. <davexunit>'guix environment' needs information from package objects. <davexunit>I don't think a profile would be enough to reconstruct an environment <davexunit>I'm sympathetic to the plight of saving the environment, but I don't want that to compromise the things 'guix environment' was designed to do. <iyzsong>if it's only for the environment, we don't need profile. an environment is a collection of search-paths (information from packages) right? <davexunit>iyzsong: let's say it's not a profile, it still needs to be a GC root. <iyzsong>ah, I don't know how to make a GC root yet :- <mark_weaver>iiuc, anything reachable from /var/guix/gcroots is a chroot, so symlinks are followed, and directory structures are traversed, transitively. <mark_weaver>profiles are handled via the /var/guix/gcroots/profiles symlink <rekado>would that be okay or do you see something that obviously needs changing? <davexunit>mark_weaver: so, would a script that had references to a bunch of store items protect those store items from GC? <davexunit>I'm guessing "yes", but I haven't done my homework on this yet. <mark_weaver>that's the only mechanism that protects various things referenced by grub.cfg such as the font and background image <davexunit>maybe 'guix environment' should have a file format for saving and protecting the necessary store items from GC, then. <mark_weaver>one issue is that normally, only root can add entries to /var/guix/gcroots <mark_weaver>but of course, it would be possible to make per-user directories within <mark_weaver>at present, there is /var/guix/gcroots/profiles/per-user/<user> <mark_weaver>but that's probably not a proper place to add random other things that aren't profiles. <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." <rekado>davexunit: do you have a good response? <davexunit>rekado: I will probably ignore this because it's out of ignorance. <davexunit>to me it's like when people say things like "evolution is just a theory". no response needed. <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. <civodul>rekado, davexunit: in a way, Guix packages are data rather than code <civodul>seen from a live Scheme environment, packages are just objects <civodul>besides, the main security concern is about software that is installed <civodul>sneek: later tell alezost it Would Be Nice to have some sort of org-babel integration; like for R source it would automatically to 'guix environment --ad-hoc r -E R' to run the thing <davexunit>I've been thinking about how to make the various switches to 'guix environment' more composable, curious what your thoughts are. <davexunit>there are times when I want to use 'guix environment' normally like 'guix environment emacs', *but* I want to throw in an ad-hoc package. <davexunit>I can't mix and match packages that I want only the deps from and packages that I want by themselves. <davexunit>example: 'guix environment emacs --ad-hoc guile' <davexunit>Would Be Nice if that took the inputs of Emacs + just Guile itself. <civodul>yes right, i've wanted that a couple of times too <rekado>guix environment -e "'((dev emacs) guile (file "env.scm")) <davexunit>civodul: not sure how to make a nice CLI to express it. <civodul>or: guix environment emacs --ad-hoc guile -l foo.scm <civodul>that is, everything before --ad-hoc is taken to mean "the inputs of that package" <davexunit>the args-fold process will track whether or not we are in "ad-hoc" mode. <rekado>In many cases I find command line arguments confusing and I wished we could evaluate domain-specific sexps for everything. <civodul>rekado: you mean in command-line arguments in general, or those of the guix commands specifically? <rekado>in general. The different precedence rules for different commands trip me up more often than I'd care to admit. <rekado>but maybe I'm just saying this because it's Friday. <wgreenhouse>davexunit: re "security nightmare" I find that response to homoiconicity bizarre <wgreenhouse>davexunit: I guess it may be people shellshocked by eval in js <civodul>i think it's the usual code vs. data debate <civodul>if packages were sexps (pure data), core Guix would have to 'read' them and turn them into <package> objects <civodul>it would make sense if the source of those sexps was not part of the trusted computing base, roughly <civodul>like if we had an on-line service where anyone could paste in package definitions and have them built <taylanub>I haven't heard of Librem being mentioned around much. does the FSF and such have a stance on it yet? any own opinions? <davexunit>it certainly wouldn't pass RYF certification. <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 <mark_weaver>if that stuff doesn't send a shiver up your spine, there's something wrong :-/ <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. ***tschwing_ is now known as tschwinge
<civodul>mark_weaver: i think core-updates is ready to merge later today <mark_weaver>civodul: yes, probably so. Just now I've been restarting some failed builds, and a new evaluation is almost there <civodul>the main limitation being that hydra.gnu.org is not quite blazingly fast <mark_weaver>civodul: after reading your post, I am quite worried about the libc locale issue though <civodul>yeah, it is worrying, i won't lie ;-) <mark_weaver>civodul: oh, that reminds me, glibc-locales is still broken. the patch doesn't apply. <civodul>but really, i think libc should do better <civodul>like apply that damn patch to being with ;-) ***davi_ is now known as Guest40854
<civodul>paroneayea: damn, i see a picture of you at Inria's building in Paris, right? <goglosh>if you could please read it? :) I'd appreciate it <civodul>maybe you could post it to the mailing list? <civodul>that would make it easier to reply and share thoughts with others <civodul>goglosh: just read it and it's useful feedback, so thanks! <goglosh>uh... just let me figure out how that works <civodul>OTOH, if you can manage an HTTP server as above, i'm sure you can send email ;-) <goglosh>but don't worry in no time I'll be a real nix guru :) <francis7>It really pisses me off when people ask about librem and RYF <francis7><taylanub> I haven't heard of Librem being mentioned around much. does the FSF and such have a stance on it yet? any own opinions? <francis7>The thing doesn't even have coreboot, let alone libreboot, and they've recently rebased their "PureOS" on debian instead of trisquel. <goglosh>one more thing, which package provides `poweroff` `shutdown` and so on? <paroneayea>had someone ask if I was willing to do a contracting gig maintaining a mail server for them <paroneayea>told them, not until I get this whole deployability thing sorted out! <paroneayea>good thing I'm working on guixops work next month!? <civodul>ACTION tweaks the offload hook to reduce load on hydra <davexunit>speaking of that, ifur has kindly offered me a GuixSD VM running on his cluster for further experimenting <davexunit>it's pretty awesome. hoping to work on remote system reconfiguration. <civodul>so, time to merge core-updates i think <civodul>meanwhile, hydra peaks at a load of 14 <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 <codemac>I'm saying the file doesn't exist, but I'm providing a default one that includes /gnu/store/.... paths. <codemac>Maybe I'm approaching this all wrong. <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> /gnu/store/c158g4fki606z1g0l240kknprfwdls0a-coreutils-8.24/bin/mkdir -p '/gnu/store/4xqmz0zzkv1n09fqqckql2p8xv30hn1k-guile-2.0.11/share/guile/site/2.0/' <codemac>I should probably just have a separate derivation that generates that default config file <joolean>/gnu/store/c158g4fki606z1g0l240kknprfwdls0a-coreutils-8.24/bin/mkdir: cannot create directory ‘/gnu/store/4xqmz0zzkv1n09fqqckql2p8xv30hn1k-guile-2.0.11/share/guile/site’: Permission denied <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 <civodul>joolean: your package tries to install to GUILE_SITE_DIR, whereas it should install to $prefix/share/guile/site/2.0 <civodul>codemac: generating the file sounds good <joolean>(Although it raises the question: What the heck is GUILE_SITE_DIR for anyway) <joolean>I just had to go through the pain of making it work in a VPATH build <codemac>civodul: yeah - need to work on the best ways of templating files in guile, but that's just learning :) <civodul>joolean: i also usually add a --with-guilemoduledir=DIR option <civodul>mark_weaver: i mean it (used to) return the name of the directory under Guile's $prefix <joolean>mark_weaver: Well, it doesn't honor $prefix, for one thing <civodul>and so if you use that as the default guilemoduledir, it's broke <mark_weaver>civodul: isn't that appropriate on almost every system? how would it take into account guix/nix? <joolean>but Auto(make|conf) don't know about sitedir <mark_weaver>which configure appears to set to $datadir/$PACKAGE_TARNAME/site/$GUILE_EFFECTIVE_VERSION by default <mark_weaver>joolean: well, there's code in guile's configure.ac to set it <joolean>Yeah, but that's sort of an implementation detail of Guile's build that's not accessible to other projects <civodul>the problem is not GUILE_SITE_DIR per se, but rather using its value as the default install location for your project's modules <civodul>because by definition GUILE_SITE_DIR is not under your project's $prefix <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? <civodul>mark_weaver: ah yes, we should probably install .go files in 2.0/site-ccache <civodul>for .scm files yeah, maybe you're right <civodul>though there'll always be subtle API differences i guess