<kyamashita>I got really excited to see a minimal and customizable window manager, but it doesn't work properly on my machine. <koz_>kyamashita: The codebase is kinda old. ***Guest7685 is now known as Digitteknohippie
***Digitteknohippie is now known as Guest7302
<notadrop>I tried re-imaging my flash drive with the GuixSD installer image, and GRUB still reports it as an unrecognized filesystem. <notadrop>I found it odd that the image had no file extension, like .img or .iso <notadrop>And I did image the drive with the disk image, not the compressed image <phant0mas>civodul: from now on we should sign our commits with our pgp key before pushing, right? <mthl>quick check: "A derivation contain the following pieces of information" <mthl>should be "A derivation contains the following pieces of information" <mthl>what about the term "information", is it fine to keep it singular? <jmd>That's a mistake that many continental europeans make. <jmd>In the above example, I would simply have said "A derivation contains the following information" <jmd>"peices of information" is correct, but inelegant IMO <jmd>Or to be pedantic: "bicycle shed" <davexunit>ACTION pushed autoconf-archive and mitlm patches <atheia>I have a question relating to Perl packaging and propagated inputs. <atheia>I'm, on the fly (well… it's taken me a day so far), packaging the Catmandu toolkit for Perl. <atheia>It has tons of depencies, which I guess should be propagated. <atheia>I've finally gotten to a stage where catmandu builds, but running catmandu -h <atheia>complains about missing modules. <atheia>It seems none of the propagated inputs are available to it… <atheia>I don't quite understand why this is the case, and I'm at the end of my Guix knowledge here — can anyone here think of what might be going on? <davexunit>atheia: the system isn't magic. is PERL_PATH or whatever configured properly? <davexunit>have you created a wrapper script that sets the load path? <davexunit>I don't know Perl, so someone else would have to help you with specific details <davexunit>but I imagine there are other Perl packages that you can snarf code from <atheia>aha, no I have not — so am I right in thinking that the wrapper would do something like: for each input, take its lib directory and add it to the PERL_PATH (or PERL5LIB)? <davexunit>that's the usual way of dealing with executables written in dynamic programming languages <davexunit>I'm not sure what code has already been written for wrapping perl programs <davexunit>if you can't figure it out, writing to help-guix@gnu.org will get more eyes on your problem <GNUtoo-irssi>hi, the "limitations" says: "Support for the Logical Volume Manager (LVM) is missing. ", can I indicate /dev/disk/by-uuid/<the-uuid> as the rootfs? <GNUtoo-irssi>(I bringed up the LVM thing because I suppose that more than that might be missing) <atheia>davexunit: OK, thanks for the pointers. I'll check out python, as I can't see anything in perl or guile modules. <davexunit>note that wrapping is not something you would do for libraries <GNUtoo-irssi>Right now it didn't compile much when bootstraping from the livecd (which is good), then I'm stuck inside the initramfs <atheia>OK, so that sounds like it would not be part of the build system. <GNUtoo-irssi>I indicated the rootfs in the .scm like mentioned above (/dev/disk/by-uuid/...) <iyzsong>atheia: with perl and all the propagated-inputs in profile, PERL5LIB should be set in ~/.guix-profile/etc/profile. then you can run the program to be sure, and wrap it like icon-naming-utils in gnome.scm. <atheia>I don't really want to force people to install all the propagated-inputs into their profile. But looking at icon-naming-utils is good about wrappers. <GNUtoo-irssi>It seem to be some race condition, the usb disk appears after loading the initramfs and looking for it, doing ctrl+d once it's found, and ajusting the path to /dev/sda1(not sure if the later is necessary) did the trick <civodul>phant0mas: yes, commits should be signed now <civodul>still accepting unsigned commits, but not for too long hopefully ;-) <civodul>GNUtoo-irssi: for the root fs, don't use /dev/disk/by-uuid; instead, you should use (title 'uuid) etc. <civodul>(because udev isn't started in the initrd) <jmd>I never understood the what signed commits are supposed to achieve. <civodul>in general, use the 'title field instead of /dev/disk <iyzsong>nice! but how do i get the gpg public keys of guix commiters? <civodul>iyzsong: that's a very good question! <civodul>it doesn't have a good answer yet :-) <cbaines>I'm trying to use pyguile, and guix as a guile library at the same time, but having some problems <cbaines>When using guile from Debian, I can add pyguile to the LD_LIBRARY_PATH and GUILE_LOAD_PATH, and load it fine, but I don't have guix <cbaines>When using guile from Guix, I have guix as a guile module, but I get ;;; ERROR: In procedure dynamic-link: file: "libpyguile", message: "file not found" when trying to (use-modules (pyguile)) <davexunit>civodul: do we have a guile equivalent of 'readlink -f' in guix? my search hasn't turned up anything. <davexunit>and now that I've mentioned this... I found readlink* <civodul>ah right, we should copy it there someday <civodul>cbaines: most likely libpyguile is not in LD_LIBRARY_PATH <davexunit>ACTION dusted off his festival speech-tools package <davexunit>it's a complicated build script, but damn it I think I have it working! <civodul>cbaines: actually, you should strace it to see what's going on <davexunit>I've been learning how to run the scripts to train a "language model" for speech recognition at work <civodul>what's pyguile BTW? it is what i think it is?! <davexunit>guix has been very helpful for getting the requisite software. <cbaines>civodul, thanks, I think I may have managed to link the shared library against something in the store, which was garbage collected... <cbaines>I'll try recompiling now, to see if that fixes it <cbaines>It does work to some extent, although I'm still only doing very simple things <cbaines>I also have not tried python3 with it yet <civodul>Guile bindings to CPython, see above :-) <cbaines>civodul, not quite, I was having some issues running guix, so decided to rebuild that also, and now I can't get make to run... <cbaines>make[3]: *** No rule to make target '../../gnu/packages/texlive.scm', needed by 'guix-packages.pot-update'. Stop. <civodul>cbaines: should be fixed in current master <mthl>is it me or I don't see POTFILES.in often updated? <civodul>mthl: yes, this one is not updated very often <ifur>i tend to stay away from potfiles if possible as the scientist really should take care of that <cbaines>I think I'm having problems, as it can't find the libpython library... I might try creating a package for pyguile, so that its just in the store <catonano>I built a broken package. Now I'd like to eliminate it from the store. Is this possible ? <rekado_>catonano: you can use "guix gc -d /gnu/store/..." to delete an item from the store. <rekado_>it will fail if it is installed in an active profile generation. <catonano>rekado_: yes, thank you, I was reading this in the manual right now <rekado_>Guix workshop went well. So many questions and a couple of interesting suggestions. <rekado_>there were even a couple of people who stayed longer to get a quick intro to Guile and packaging. <davexunit>for me it was a good example of things that we should try to be better at messaging about <davexunit>there's a few people arguing in favor of Docker over Nix <cbaines>I think Docker could work well using Guix/Nix instead of other OS's (e.g. Debian, ...) <cbaines>This might also the best introduction that people could get to Guix <cbaines>especially as I think it would be easy to make it work on all platforms where docker is supported, which is to say lots <davexunit>I think we may have no choice but to provide some interop with Docker, but our goal is to replace Docker entirely. <davexunit>I don't need Docker to make containers. Guix does it for me. <cbaines>I don't think that is a great way of putting it <cbaines>I can see how Guix could provide all the functionality offered by Docker <cbaines>(and I think that is what you mean by "replace Docker entirely"?) <davexunit>there will be no reason to use Docker once Guix has a comparable container implementation. <cbaines>However, I think using Guix within Docker, might be especially beneficial for those stuck using proprietary platforms like MacOSX, which have good support for using Docker <davexunit>yeah, it could help there, which is why I think we'll have to have interop, like Nix does. <davexunit>that interop will act as a bridge to get new people involved <davexunit>and hopefully ditch Docker altogether once they've come to understand the features of Guix <lfam>Trying to build a vm against it gives me: Wrong number of arguments to #<procedure urandom-seed-shepherd-service () <lfam>I'm a little out of my depth (for now, I hope!) <davexunit>it wants you to have a pre-built version of the edinburgh speech tools source tree in the parent directory you are building in. <efraim>have you looked at mycroft or smarty mcsmartpants? <efraim>s/smarty mcsmartpants/parsey mcparseface <davexunit>I'm just building the software that I need to build some stuff at work <efraim>mycroft is working on an open source speech -> intent system <davexunit>yeah I'm pretty ignorant of all the tools in this space <efraim>parsey mcparseface is google's sentence parser that they just licensed MIT? <lfam>Speaking of which, I need to pick my espeak package back up <lfam>We should have a speech synthesizer <roelj>lfam: Thanks for your pre-push hook! <lfam>roelj: You're welcome! It could be adapted to selectively block pushes to specific remotes, but I didn't bother. <roelj>lfam: I think this is fine.. :) <roelj>lfam: In fact, this is precisely what I was looking for. <lfam>catonano: Can we do this troubleshooting here instead of by email? <lfam>I just sent a few messages, but this will be faster <davexunit>'guix gc --help' explains all of the options <catonano>guix gc --referrers returned the prompt without a blip <catonano>copied from the terminal and pasted: guix gc --referrers <lfam>You must give as an argument the store path in question <lfam>guix gc --referrers /gnu/store/... <lfam>To be fair, I found the `guix gc --r...` options confusing at first <lfam>I had to spend some time learning the system before I could grok them <catonano>ok, gc --referrers returned a bunch if things <lfam>catonano: Please use paste.lisp.org <catonano>oh there's a profile among the referrers <lfam>This is making me think about cider... first hot day of the year here :) <catonano>ok, this is the content of one of those profiles <catonano>but I swear I erased ALL the generations ! <catonano>well, look. I think this troubleshooting is too clunky. I think I'll throw away this /store and /var/guix and start fresh <catonano>I didn't know about the --referrers switch though <lfam>And, why so much concern about this file? <davexunit>yeah, there's obviously a profile hanging around <catonano>there's a profile hanging around. But I can't see it <lfam>And each user only has 1 profile? <lfam>1 generation of profiles, that is <davexunit>within there are all the profiles for those users <catonano>the first profile of root is an alias and points to the second one <lfam>Yes, they are what you see when you do `guix package -l` <davexunit>running 'guix package --list-generations | grep cider' for each user should reveal who has the reference to cider <catonano>[root@xps catonano] # guix package --list-generations | grep cider <catonano>the reason why I am concerned about these relics of a build of cider <lfam>Earlier, you used `guix gc --referrers` to see that the file in question is referred to by two profiles. You should figure out who owns those profiles and then remove the profiles <roelj>I installed Guix from Git, and have one "per-user" profile for my own user account. Now I would like to add a profile for "root".. How would I do that? <efraim>the instructions for the binary install basically include `sudo guix package -i guix` and symlinking it to /usr/local/bin/guix <roelj>I was afraid of this. It errors with: error: directory `/usr/local/var/guix/profiles/per-user/roel' is not owned by you <roelj>(Yes, I ran it as root, not roel) <roelj>I don't see how it connects root to roel. <lfam>Did you run it as root, or with `sudo`? <lfam>Hmm, I don't know. I never went so far as to install my source-built Guix <civodul>roelj: perhaps the value of $HOME was wrong? <roelj>civodul: $HOME is set to /root. I think that must be right. <roelj>(I set them to root instead) <civodul>the schemer's speech synthesis tool! <lfam>Is it a command-line tool or a library? I'd love to try it out! <lfam>Awesome, looking forward to the patch! <davexunit>I've never heard it speak, I'm not sure if it does that <davexunit>the project I'm involved in that uses it just generates phonemes with it <davexunit>I was pleasantly surprised to find a python script that generates and parses s-expressions with string concatenation/splitting <davexunit>unfortunately, festival doesn't seem to support a load path environment variable <davexunit>so I had to just unpack all the additional lexicons and voices into it. <davexunit>for anything extra, you need to modify the recipe and build anew. <davexunit>I feel like guix is turning me into an awful build system wizard <lfam>We do it so nobody else has to :) <davexunit>despite your best effort to make the worst build system imaginable, I'll find a way to make it build and install where I want it to be installed. <davexunit>I won't be submitting these patches for some time. I think the additional data files have some files that are generated from their scheme source files. <davexunit>so I'd want to figure out how to build completely from source. <lfam>From that recent HN thread about Nix: "Luckily guix is a better UX for nix. =)" <lfam>I didn't recognize any of the names, except yours of course <civodul>davexunit: it doesn't look *that* bad :-) <davexunit>civodul: it certainly took a long time to unwrangle. the comments help make some sense of the mess. <lfam>Emacsite: You should try to use `git blame` on the package module that contains artanis <lfam>Emacsite: Do this to figure out what file (package module) artanis is in: `guix package --show=artanis` <lfam>And then, do `git log $file` <lfam>Git will tell you who maintains that package <lfam>If you don't know how to use git, I can do it for you <Emacsite>cal@leela:~$ git log gnu/packages/guile.scm <Emacsite>fatal: Not a git repository (or any parent up to mount point /home) <Emacsite>Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). <davexunit>lfam: Emacsite isn't working from a git checkout <Emacsite>I just installed it on Trisquel so I could get up-to-date packages. <lfam>I don't know how to use artanis, so I can't check if the packaging is broken, which I'd like to do before filing a bug report on our tracker. Can anyone confirm the artanis package is broken? <kristofer>I've been tinkering with artanis, it works fine <Emacsite>davexunit: Oh, well I don't hack Guix... <Emacsite>lfam: I just followed the manual. The link to the manual entry on how to do what I did is in that mailing list message. <lfam>I wonder if your GUILE_LOAD_PATH is set correctly? Does it have a value? <Emacsite>lfam: cal@leela:~$ echo $GUILE_LOAD_PATH <Emacsite>cal@leela:~$ echo $GUILE_LOAD_COMPILED_PATH <Emacsite>/gnu/store/dcyh6ahxhaswl6r6jcjk49fiqvifyfp4-profile/lib/guile/2.0/ccache <kristofer>guix environment --ad-hoc artanis; this gets me artanis-0.1.2, and my GUILE_LOAD_PATH is incorrect in this case <Emacsite>civodul: I believe so. I will provide evidence.