IRC channel logs


back to list of logs

<civodul>Hello Guix!
<mark_weaver>good morning civodul!
<civodul>heheh, still around? :-)
<mark_weaver>heh :)
<youlysses>civodul: Early morning. o/
<youlysses>Has a wrapper for texinfo documents been written yet?
<civodul>a wrapper?
<civodul>what do you mean?
<youlysses>civodul: Probably wrong terminology, my brain is some-what fried at this point... a system in-which a local-user can read texinfo files by default. Maybe it was just an odd/non-configured thing in NixOS, but while the packages for various bits of documentation was there, they didn't default there.
<youlysses>Possibly just an info/emacs info problem too?
<Arne`>If I have a file called mercurial.scm in some folder, with (define-module (mercurial) … and (define-public mercurial…, what is the exact guix call to install the mercurial package?
<Arne`>guix package -e "(@ (mercurial) mercurial)" does not work…
<civodul>youlysses: you need to set INFOPATH to point to ~/.guix-profile/share/info
<civodul>now, the 'dir' file doesn't get updated, currently
<civodul>Arne`: more details please :-)
<Arne`>civodul: I adjusted the version-control.scm file and copied it to ~/
<Arne`>(as mercural.scm)
<Arne`>to experiment with building packages
<Arne`>(with a package I know)
<civodul>can you paste the error and the file?
<civodul>does it compile?
<Arne`>I get this guix package: error: failed to evaluate expression `(@ (vcs mercurial) hg)': (wrong-type-arg "module-variable" "Wrong type argument in position ~A (expecting ~A): ~S" (1 "module" #f) (#f))
<Arne`>currently I tried this: $ guix package -e "(@ (vcs mercurial) hg)"
<Arne`>guix package: error: failed to evaluate expression `(@ (vcs mercurial) hg)': (wrong-type-arg "module-variable" "Wrong type argument in position ~A (expecting ~A): ~S" (1 "module" #f) (#f))
<civodul>what does this do: guile -c '(@ (vcs mercurial) hg)' ?
<Arne`>I get a backtrace
<Arne`>here’s the file:
<Arne`>civodul: does that show what I did wrong?
<civodul>Arne`: what about guile -c '(use-modules (vcs mercurial))' ?
<Arne`>ERROR: In procedure scm-error:
<Arne`>ERROR: no code for module (vcs mercurial)
<civodul>ok, so there's no such module
<civodul>remember that the file must be called vcs/mercurial.scm
<civodul>and that 'vcs' dir must be in Guile's search path
<civodul>IOW, $GUILE_LOAD_PATH must be set appropriately
<Arne`>oh, ok
<Arne`>so there are already filesystem categories
<Arne`>I removed the vcs prefix and call it like this: $ GUILE_LOAD_PATH=. guix package -e '(@ (mercurial) hg)'
<Arne`>now something happens
<Arne`>(downloads and such)
<Arne`>why is it necessary to give the (name "…") additionally to the package name in (define-public PACKAGENAME?
<civodul>nice :-)
<civodul>so the 'name' field is what the command-line tools show
<civodul>whereas the variable name is, well, the variable name
<civodul>often they're the same, but not always
<civodul>for instance because sometimes there are several variants of a given package
<Arne`>civodul: could the 'name' field be made optional? That should save 1 line for most packages…
<Arne`>civodul: Is there a way to skip the strip phase in the python-build-system?
<Arne`>it *seems* to be failing.
<Arne`>(I get File format not recognized)
<Arne`>… wait, no. That succeeded (just didn’t strip the files).
<Arne`>I got this backtrace:
<Arne`>last line: guix/serialization.scm:49:4: In procedure bv-u32-ref: Wrong type argument in position 1 (expecting bytevector): #<eof>
<civodul>the "File format not recognized" is harmless
<civodul>the other thing looks like a bug
<civodul>are you using 0.3 or Git?
<Arne`>(besides: guix pull does not work for me)
<civodul>i think it'll work if you run the "guix package" a second time...
<Arne`>I installed 0.3, and that’s what guix --version still reports.
<Arne`>installed, yepp: Thanks!
<civodul>could you report the bug nonetheless?
<civodul>it seems to happen when installing something not built yet
<civodul>i thought i had fixed it, but maybe not
<Arne`>bug sent
<Arne`>civodul: should I also file a bug-report for making the (name) optional?
<civodul>hmm, no :-)
<civodul>because that's no really doable: package objects exist regardless of whether they're bound to a variable
<Arne`>argn, too late…
<civodul>np ;-)
<Arne`>isn’t define-public a macro, which does get the variable name?
<civodul>it's a macro, yes
<Arne`>so couldn’t it check whether there is a (name) field, and if not, just add it?
<civodul>so we could have define-package, define-public-package, etc.
<civodul>'define-public' boils down to 'define', and 'define' knows nothing about 'package' objects
<Arne`>so this is an implementation details which (currently?) requires an explicit name?
<civodul>yes, that's one way to say it
<Arne`>so I guess the wish is implementable in the infrastructure. It might not be high-priority, but it can be done at some point.
<Arne`>(hopefully does not require changes deep down)
<Arne`>besides: Mercurial now installed.
<Arne`>You’ll get a patch for version-control.scm
<Arne`>patch for basic Mercurial support in guix:
<civodul>welcome on board ;-)
<civodul>can you send it to guix-devel?
<Arne`>Do I need to register for that?
<civodul>no, it's a GNU list
<civodul>it can also be accessed via Gmane
<Arne`>(damn, forgot to note that the package is pretty rough…)
<Arne`>it’s essentially just a stripped down copy of the bazaar package with a new uri…
<Arne`>…and description
<civodul>well, as long as it's usable, that's fine
<Arne`>it works for me :)
<Arne`>can I remove a package from a file? Something like the inverse of -e '(@ …)'
<Arne`>never mind: -r <name> works
<Arne`>I like being able to swapping packages this quickly.
<Arne`>why does guix pull always get the full guix-master.tar.gz snapshot?
<civodul>Arne`: ideally we'd have server support to only fetch diffs (or use rsync), but we don't have that currently
<civodul>that's why it pulls all of the tarball
*civodul goes for lunch
***ae is now known as Guest29481