IRC channel logs


back to list of logs

<roelj>Oh well
<kyamashita>What is up with guile-wm?
<kyamashita>I got really excited to see a minimal and customizable window manager, but it doesn't work properly on my machine.
<kyamashita>*window manager _in_Scheme!_
<koz_>kyamashita: The codebase is kinda old.
<koz_>Also, hai!
<kyamashita>Wifi dropped :-/
<kyamashita>ACTION is away
***Guest7685 is now known as Digitteknohippie
***Digitteknohippie is now known as Guest7302
<notadrop>Hey, Emacsite.
<notadrop>I tried re-imaging my flash drive with the GuixSD installer image, and GRUB still reports it as an unrecognized filesystem.
<notadrop>Anyone have any ideas?
<notadrop>I used dd, of course. bs=1M
<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
<civodul>Hello Guix!
<jlicht>good afternoon guix
<phant0mas>civodul: from now on we should sign our commits with our pgp key before pushing, right?
<davexunit>phant0mas: correct.
<mthl>quick check: "A derivation contain the following pieces of information"
<mthl>should be "A derivation contains the following pieces of information"
<davexunit>mthl: yeah
<mthl>what about the term "information", is it fine to keep it singular?
<davexunit>information is plural
<davexunit>"piecs of information"
<mthl>davexunit: thanks ;)
<davexunit><plural> of <singular>
<davexunit>you'd never say "informations" in english
<jmd>That's a mistake that many continental europeans make.
<mthl>yeah I am one of them
<mthl>too bad
<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
<davexunit>could be simply "information"
<davexunit>but I don't really care
<davexunit>for fear of building a bikeshed
<jmd>"bike shed"
<davexunit>holy hell
<jmd>Or to be pedantic: "bicycle shed"
<davexunit>ACTION pushed autoconf-archive and mitlm patches
<atheia>Hello #guix
<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>atheia: yeah, something like that.
<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 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
<davexunit>only executable programs
<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/...)
<GNUtoo-irssi>Ah ok, /dev/ is empty, I'll try to boot it anyway
<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.
<iyzsong>Yeah :-)
<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>howdy, atheia!
<atheia>o/ civodul
<civodul>GNUtoo-irssi: for the root fs, don't use /dev/disk/by-uuid; instead, you should use (title 'uuid) etc.
<GNUtoo-irssi>civodul: oh ok
<GNUtoo-irssi>thanks, I'll read it now
<civodul>(because udev isn't started in the initrd)
<GNUtoo-irssi>and devtmpfs doesn't have /dev/disk/by-uuid?
<jmd>I never understood the what signed commits are supposed to achieve.
<civodul>in general, use the 'title field instead of /dev/disk
<GNUtoo-irssi>and mdev isn't integrated either I guess
<civodul>jmd: authentication
<iyzsong>nice! but how do i get the gpg public keys of guix commiters?
<GNUtoo-irssi>devtmpfs seem ot have /dev/disk/by-uuid
<civodul>iyzsong: that's a very good question!
<civodul>it doesn't have a good answer yet :-)
<iyzsong>ah, thanks.
<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))
<cbaines>Any ideas?
<phant0mas>davexunit civodul thank you
<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*
<davexunit>but it's not in a build-side module
<civodul>ah right, we should copy it there someday
<davexunit>for now, I can use something simpler
<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?!
<civodul>davexunit: sounds fun
<davexunit>guix has been very helpful for getting the requisite software.
<davexunit>lots and lots of custom stuff to wrangle
<davexunit>(with broken build systems, too)
<davexunit>ACTION glares at Kaldi
<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>As for pyguile, it is probably what you think it is. I found it here recently and the original developer kindly put it in a Git repository here
<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>cbaines: pyguile looks fun :-)
<civodul>glad you managed to get it working
<random-nick>what's pyguile?
<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>oh, a bug!
<civodul>lemme see
<civodul>cbaines: should be fixed in current master
<mthl>is it me or I don't see often updated?
<cbaines>civodul, great, I've build guix now
<civodul>mthl: yes, this one is not updated very often
<civodul>for obscure reasons
<civodul>mark_weaver: maybe we should get in touch with imgtec to get more MIPS build machines? :-)
<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 ?
<davexunit>see 'guix gc'
<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.
<bavier>rekado_: I'm glad it went well
<davexunit>rekado_: glad to hear it!
<davexunit>did anyone catch the big Nix discussion on HN yesterday?
<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
<davexunit>that seem to not understand the problems
<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>well, it's my goal anyway.
<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>I'm stuck trying to pass #f as an argument to the urandom-seed-service, as suggested in the bug discussion:
<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>festival sure is a bear to build
<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?
<davexunit>I don't know what those are :)
<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?
<davexunit>something like that, yeah
<davexunit>different than a speech synthesizer
<lfam>Speaking of which, I need to pick my espeak package back up
<lfam>We should have a speech synthesizer
<efraim> and
<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>Me too ;)
<lfam>catonano: Can we do this troubleshooting here instead of by email?
<lfam>I just sent a few messages, but this will be faster
<catonano>lfam: why not
<catonano>thank you
<davexunit>cantstanya: use 'guix gc'
<davexunit>guix gc --referrers
<davexunit>'guix gc --help' explains all of the options
<catonano>guix gc --referrers returned the prompt without a blip
<davexunit>catonano: what is the exact command you ran
<catonano>copied from the terminal and pasted: guix gc --referrers
<davexunit>that's wrong
<lfam>You must give as an argument the store path in question
<lfam>guix gc --referrers /gnu/store/...
<davexunit>please read the documentation
<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
<catonano>can I paste them here ?
<lfam>catonano: Please use
<catonano>oh there's a profile among the referrers
<catonano>there are 2 profiles !
<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
<catonano>so thanks
<davexunit>what? you're so close
<lfam>Why throw it out?
<catonano>am I ?
<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
<catonano>I mean:
<catonano>just a minute
<catonano>$ ls /var/guix/profiles/per-user/
<catonano>catonano root
<catonano>I see 2 profiles only
<lfam>And each user only has 1 profile?
<lfam>1 generation of profiles, that is
<davexunit>catonano: those are directories
<davexunit>within there are all the profiles for those users
<catonano>ok, catonano has 3 profiles
<catonano>root has 2
<catonano>the first profile of root is an alias and points to the second one
<catonano>so these profiles are the generations
<catonano>I see
<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>ok just a minute
<catonano>for catonano nothing shows up
<catonano>for root:
<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
<catonano>yes I see
<catonano>thank you people
<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?
<davexunit>roelj: install packages as the root user
<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`?
<roelj>As root
<lfam>Hmm, I don't know. I never went so far as to install my source-built Guix
<roelj>Ok, thanks anyway :)
<civodul>roelj: perhaps the value of $HOME was wrong?
<roelj>civodul: $HOME is set to /root. I think that must be right.
<roelj>Let's strace it..
<civodul>what are $USER and $LOGNAME?
<civodul>see (guix scripts package)
<roelj>Aha! Both are roel.
<roelj>And now it works
<roelj>(I set them to root instead)
<civodul>ok :-)
<davexunit>ACTION built a working festival
<davexunit>it's really hairy
<civodul>heh, cool
<civodul>the schemer's speech synthesis tool!
<lfam>Is it a command-line tool or a library? I'd love to try it out!
<davexunit>lfam: command line tool
<davexunit>it apparently has an emacs mode
<lfam>Awesome, looking forward to the patch!
<davexunit>I've never heard it speak, I'm not sure if it does that
<civodul>it does
<davexunit>oh cool
<civodul>i heard it loooong ago
<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>and by all I mean a few default things
<davexunit>for anything extra, you need to modify the recipe and build anew.
<civodul>not super convenient, indeed
<davexunit>if anyone would like to view the madness, here it is:
<lfam>Wow, that *is* hairy
<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. =)"
<davexunit>heh, I enjoyed that
<davexunit>from technomancy, no less!
<davexunit>he's made a lot of cool stuff for emacs
<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.
<Emacsite>Hey, who packages Artanis for Guix?
<lfam>Emacsite: You should try to use `git blame` on the package module that contains artanis
<lfam>Or check the git log
<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`
<Emacsite>wut does git hav to do with this
<Emacsite>oh wel
<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>location: gnu/packages/guile.scm:278:2
<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>Well, duh.
<Emacsite>I just installed it on Trisquel so I could get up-to-date packages.
<davexunit>a lot of guix users use a git checkout
<davexunit>so they can hack as needed
<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>kristofer: Did you see the post?
<kristofer>ACTION investigates the log
<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
<kristofer>guix environment --ad-hoc artanis; this gets me artanis-0.1.2, and my GUILE_LOAD_PATH is incorrect in this case
<civodul>Emacsite: did you source ~/.guix-profile/etc/profile as explained at ?
<Emacsite>civodul: I believe so. I will provide evidence.