IRC channel logs


back to list of logs

<goglosh>the guile-ncurses package may be broken
<mark_weaver>goglosh: tell me more
<mark_weaver>what did you try, and what happened?
<mark_weaver>(I haven't tried it myself)
<goglosh>I just installed it
<goglosh>and entered the repl
<goglosh>(use-modules (ncurses curses))
<goglosh>just as I did in my old system
<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?
<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
<mark_weaver>I'm building it now
<goglosh>maybe if I build instead of download...........
<mark_weaver>it shouldn't make a difference.
<mark_weaver>I just want to see for myself
<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>normal user
<goglosh>which is the user I used to install guile-ncurses
<goglosh>yep there it is, in teh path you said
<mark_weaver>so why didn't by 'find' command find it?
<goglosh>i have no idea
<mark_weaver>well, you need to add $HOME/.guix-profile/share/guile/site/2.0 to your GUILE_LOAD_PATH variable
<goglosh>I typed it just like you told me
<goglosh>okay.... where do I do that?
<goglosh>in my .profile maybe?
<mark_weaver>if 'guile' was installed in your normal user profile, then it would probably be set automatically
<mark_weaver>(the next time you log in, anyway)
<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
<mark_weaver>there's a bit of a learning curve
<goglosh>man I still can't run guile-ncurses :(
<goglosh>I exported the load path
<mark_weaver>from the same shell that you run 'guile' from?
<mark_weaver>what is the output of "echo $GUILE_LOAD_PATH"
<mark_weaver>please type that command from the same shell that you are about to run 'guile' from
<goglosh>nvm nvm
<goglosh>I guess I made some invisible typo before... heh
<mark_weaver>ah, okay :)
<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.
<goglosh>I'm currently using bash actually
<mark_weaver>ah, okay
<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>since it comes built in
<goglosh>I'll do it
<goglosh>oh god it actually told me to manually do the GUILE_LOAD_PATH export
<goglosh>brb, switching to my reconf
<goglosh>ACTION hugs mark_weaver 
<goglosh>I still don't know what I did but I am now using guile-wm, I'm almost inside a lisp machine now
<goglosh>the happy marriage of unix and lisp
<goglosh>ACTION throws rice
<paroneayea>goglosh: mark_weaver: a friend of mine says he wants to build a tiling window manager some day that's written in a lisp and roughly resembles a big virus of screens attached by organic tendril things
<paroneayea>like in that video
<paroneayea>I suspect it never will happen, but I sure wish it would :)
<goglosh>ACTION cries
<goglosh>I thought I was using guile-wm and I was using windowmaker the whole time
<goglosh>no wonder it felt weird
<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>shebang pointing where?
<goglosh>I guess /bin/sh will do
<paroneayea>goglosh: haha
<goglosh>my god
<goglosh>I'm a baby I should just go back to ubuntu
<goglosh>it works now, you can stop worrying
<mark_weaver>that's good!
<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>and quite dependable
<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.
<civodul>Hello Guix!
<davexunit>on front page of HN
<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
<rekado>I don't like serious.
<rekado>can't they be more cheerful?
<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>though in general we'd never want it.
<davexunit>but someone wanted to distribute a binary to someone running any ol' distro, it could work.
<davexunit>but if*
<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>ah okay
<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
<rekado>but that's okay.
<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.
<rekado>or VMs.
<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>rewriting store references
<davexunit>perhaps wrapping a binary or two to set the right paths
<rekado>yes, I think this would work.
<rekado>I wonder if there are any problems with max shebang length.
<davexunit>I'm hoping to avoid that issue, somehow
<davexunit>shebangs will need special treatment
<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.
<davexunit>'guix environment'
<rekado>I'd like to use a local .guix-profile instead and have an easy way to ....
<rekado>right, but more permanent
<davexunit>I don't see the point.
<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.
<davexunit>then 'guix environment' should go away.
<davexunit>these things conflict.
<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.
<Steap>davexunit: oh, right
<davexunit>'guix environment' doesn't use profiles.
<davexunit>and I don't see how it could.
<rekado>I know.
<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".
<davexunit>the ephemeralness is a feature.
<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>I don't know how it would actually work
<davexunit>if it even could work
<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 :-
<davexunit>but perhaps we need to use gexps for this
<davexunit>make a script
<davexunit>and make it a gc root
<davexunit>and provide a way to gc it
<iyzsong>yes, that's clear.
<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>dear people, I'd like to push these three simple patches for R packages:
<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>davexunit: yes
<mark_weaver>for example, grub.cfg is protected this way
<mark_weaver>note the /var/guix/gcroots/grub.cfg symlink
<davexunit>mark_weaver: ah, thanks!
<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.
<davexunit>then maybe rekado and wingo will be happy.
<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>this will require more thought, then.
<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"?
<davexunit>I guess so?
<davexunit>I haven't looked closely.
<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>it's clearly a waste of time.
<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>rekado: hehe okay :)
<davexunit>I hope Sly can work well enough for that
<civodul>rekado, davexunit: in a way, Guix packages are data rather than code
<civodul>seen from a live Scheme environment, packages are just objects
<davexunit>civodul: that's a good point
<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
<sneek>Will do.
<davexunit>civodul: now that would be awesome
<davexunit>I've been thinking about how to make the various switches to 'guix environment' more composable, curious what your thoughts are.
<civodul>like which switches?
<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>but it's all or nothing right now.
<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"
<civodul>that could work
<davexunit>good idea.
<davexunit>I'll try that sometime
<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.
<davexunit>that's what the guile api is for :)
<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.
<civodul>yeah that certainly helps ;-)
<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
<civodul>that's not the case here
<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>taylanub: tl;dr - it sucks
<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>yeah, it's kind of absurd
<mark_weaver>Libreboot X200 is the best thing we have for now
<mark_weaver>and it works quite well in my experience
<mark_weaver>taylanub: for more details
<mark_weaver>if that stuff doesn't send a shiver up your spine, there's something wrong :-/
<civodul> is also quite enlightening
<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.
<civodul>yeah, frightening
***tschwing_ is now known as tschwinge
<civodul>mark_weaver: i think core-updates is ready to merge later today
<paroneayea>ACTION just pushed up which mentions guix a-plenty
<civodul>oh oh! :-)
<mark_weaver>civodul: yes, probably so. Just now I've been restarting some failed builds, and a new evaluation is almost there
<civodul>i'm "trying" to upgrade my profile
<civodul>the main limitation being that is not quite blazingly fast
<civodul>guix-devel now builds, BTW
<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>mark_weaver: fixed it!
<mark_weaver>ah, good
<civodul>we'll have to think about locales
<civodul>but really, i think libc should do better
<civodul>like apply that damn patch to being with ;-)
<civodul>ok, ttyl!
***davi_ is now known as Guest40854
<civodul>paroneayea: damn, i see a picture of you at Inria's building in Paris, right?
<civodul>oh indeed, fun
<paroneayea>civodul: yes, though I wasn't there :)
<paroneayea>Jessica was, though!
<paroneayea>ok, off to lunch!
<mark_weaver>bah, our gvfs recipe depends on patchelf
<civodul>that needs to be fixed
<civodul>paroneayea: nice status report!
<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>yeah I should use the mailing list
<goglosh>uh... just let me figure out how that works
<goglosh>see, I'm a big newbie to technology
<civodul>send an email to
<civodul>OTOH, if you can manage an HTTP server as above, i'm sure you can send email ;-)
<goglosh>it's not mine
<goglosh>but don't worry in no time I'll be a real nix guru :)
<goglosh>or guix guru, perhaps
<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.
<paroneayea>civodul: :)
<goglosh>one more thing, which package provides `poweroff` `shutdown` and so on?
<mark_weaver>goglosh: dmd has 'reboot' and 'halt'
<mark_weaver>halt powers off
<goglosh>i'll begone now
<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>paroneayea: really?
<civodul>that'd be awesome!
<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.
<davexunit>time permitting and such.
<davexunit>I won't have any hack time this weekend.
<civodul>so, time to merge core-updates i think
<civodul>mark_weaver: ↑
<civodul>meanwhile, hydra peaks at a load of 14
<civodul>a rant on the Nix tooling/DSL:
<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
<civodul>using 'origin'
<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>ah good point
<civodul>hey, joolean!
<civodul>joolean: your package tries to install to GUILE_SITE_DIR, whereas it should install to $prefix/share/guile/site/2.0
<joolean>Hey civodul! Long time no see.
<joolean>Okay, I can do that.
<civodul>yep :-)
<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
<civodul>that m4 macro was (is?) broken
<joolean>Ah, well.
<joolean>Thanks for the tip!
<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
<mark_weaver>civodul: the macro is broken? what's wrong with it?
<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?
<mark_weaver>joolean: oh, it doesn't honor $prefix?
<mark_weaver>ACTION looks at the code
<mark_weaver>it works by running pkg-config --variable=sitedir
<mark_weaver>which comes from @sitedir@
<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 to set it
<joolean>Yeah, but that's sort of an implementation detail of Guile's build that's not accessible to other projects
<mark_weaver>this is the @sitedir@ from guile's configuration
<civodul>which is a problem
<mark_weaver>well, I'll defer to civodul's expertise here :)
<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>Look at the unfortunate workarounds people are attempting: (search for "$GUILE_SITE")
<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?
<mark_weaver>IMO anyway
<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
<mark_weaver>thanks. I have to go afk for a while...