<davexunit>rekado: that paper you co-authored with civodul is great. <mark_weaver>so that just needs to be patched to be an absolute path, I think. <mark_weaver>davexunit: but first, can you verify that "LD_LIBRARY_PATH=$(guix build mesa)/lib icecat" has working WebGL for you? <mark_weaver>the one thing I'm not sure about is whether the absolute path will be handled correctly. it actually doesn't call dlopen from there, it uses something from NSPR to load libraries, so I'm not sure if it works the same. <mark_weaver>if the mesa that you download now is linked to a different shared library than what icecat is linked to, there will be trouble. <mark_weaver>LD_LIBRARY_PATH=$(guix build mesa)/lib $(guix build icecat)/bin/icecat <mark_weaver>one of the webgl demos on mozilla's site worked for me, anyway. ***wtheaker is now known as aaalive
<civodul>it's similar to the one you disabled <civodul>ewemoa: i think at that time there was something inheriting from QEMU and not having Texinfo as an input <civodul>at least that's the only valid reason for doing this <ewemoa>rekado: here is a revised patch for the info files for r: https://pastee.org/mf9r6 -- some lines above in the irc log, you may find some comments from civodul regarding checking for texinfo :) <civodul>the .info file isn't in the source tarball of R? <ewemoa>civodul: the info file is made via make info <civodul>yes, i see, but i was wondering whether they ship it in the tarball <civodul>normally the GNU standards say to do so, but some packages don't <ewemoa>civodul: i freshly uncompressed a tarball for the latest R and i don't see any files that have names ending in .info -- may be they can be convinced to ship appropriate info files :) <civodul>in the meantime your patch is welcome! <ewemoa>civodul: :) on a separate note, i am trying to use dmd as a non-root user -- IIUC, the info file here suggests that starting dmd w/o specifying a config file should cause ~/.dmdconf.scm to be loaded -- but that doesn't appear to be what happens here (though explicitly specifying --config=$HOME/.dmdconf.scm seems to work) -- am i doing something wrong? <civodul>.dmdconf.scm was replaced by ~/.dmd.d/init.scm some time ago <civodul>but maybe the on-line manual isn't up-to-date <rekado_>I'm thinking about trying incron to keep the local /gnu and the NFS /gnu in sync by watching inotify events. Are new directories under /gnu/store created atomically? <rekado_>looking at strace output it looks like stuff is installed to /gnu/store/.links first and then moved/linked to the final location at /gnu/store/<hash>-<name>-<version> <rekado_>I would like to just watch /gnu/store for new directories and individually copy those to the public NFS share. <rekado_>localstatedir is small enough to sync as a whole every minute with rsync. <civodul>rekado_: are you really sure you cannot have /gnu and the machine that runs the daemon, and have it export it by itself? <civodul>it would be much less troublesome than syncing things <civodul>and syncing would not be atomic, so there would be windows during which users see incomplete directories etc. <rekado_>I cannot touch the fileserver (it seems nobody can for ... erm ... reasons, I'm sure) and I cannot guarantee availability of this builder VM, so it's not the right place for publishing an NFS share. <civodul>well what you describe might work, it just sounds can-of-wormy ;-) <rekado_>it's unfortunate, but I don't see any way around syncing. <civodul>heh, make sure management acknowledges that ;-) <rekado_>as long as it works(TM) and it remains on our (virtual) machines everything is permitted. <rekado_>now I just need to ... make it work. <Steap>civodul: well, this might be because that does not work so well <Steap>as usual, I'm only showing what works <Steap>a little trick I learnt while working in the field of reasearch in computer "science" :) <Steap>discovered some fantastic stuff <Steap>gonna be flooding davexunit with questions about guix env this afternoon <Steap>it's quite differetn from the usual virtualenv backend <Steap>because you do not create/update a guix env <Steap>you just start it, and PYTHONPATH is automagically set <Steap>I just have to manually set the PATH <Steap>also, since we launch bash, it reads .bashrc <Steap>so the env is not exactly "pure" <civodul>the default is to launch /bin/sh; if /bin/sh is Bash, it doesn't read .bashrc <Steap>just added "export LOL=42" to my .bashrc <Steap>$ make && ./pre-inst-env guix environment --pure python-flake8 <civodul>maybe ~/.profile or /etc/profile sources ~/.bashrc? <Steap>but that fucks up the "--pure" thing, doesn't it ? <civodul>since it's not a login shell, they're not suppose to fiddle with $PATH, $CPATH, etc. <Steap>well .bashrc usually exports PATH <civodul>Steap: this should go to .bash_profile actually <rekado_>jackdaniel: thanks for feeding sneek. It was getting restless already. <Steap>civodul: yeah well, people in the real world put it in .bashrc :) <Steap>might have a hard time selling them guix if we cannot have a real "--pure" option :p <civodul>we could have an option to use system* (i.e., fork + exec) instead of system <Steap>wouldn't we end up reading .bashrc anyway ? <civodul>Steap: my idea was to have something like "guix environment foo -E bar --forkexec" where 'bar' would be executed via fork+exec instead of system(3) <civodul>but i think it's good to use the shell by default *civodul adds a footnote about .bashrc vs. .bash_profile <alezost>davexunit: hi, do you prefer to have <davet@gnu.org> in AUTHORS file? <alezost>(I'm going to clean up the AUTHORS and to add .mailmap) <alezost>amz3: hi, are you Amirouche Boubekki? <Steap>He has a right to anonymity. <alezost>well, I need to know what to put in AUTHORS: amz3 or Amirouche Boubekki, and <amirouche.boubekki@gmail.com> or <amirouche@hypermove.net> ***necronian_ is now known as necronian
***rvernon is now known as Rastus_Vernon
***breton_ is now known as breton
<Steap>davexunit: would it make sense for guix environment to return the return value of the command specified with --exec ? <davexunit>Steap: yes, I've been meaning to add that. :) <Steap>davexunit: I don't know whether that should be the default behaviour <Steap>or something that is turned on using an option <Steap>(I need that for guix-tox :p) <davexunit>the whole point of 'guix environment' is to run a subprocess, so I think it ought to return its status code <Steap>hum, funny ls /TMP returns 2 on my machine, but if run inside guix env, it returns 512 <Steap>oh, it needs status:exit-val *davexunit begins to polish gnu/build/linux-container.scm <davexunit>actually, I will resume my code clean up. :)