<mark_weaver>brendyn: that will be a somewhat older version of guix than the one in your git checkout. typically the newest 'guix' package within guix will be bound to the 'guix-devel' variable in gnu/packages/package-management.scm
<brendyn>Ok, so do you have to do something special when you commit new versions of guix? like make a commit with a real change, then make another commit with nothing but the hash changed so guix can package it's self with only the minimal hash change?
<mark_weaver>having said that, I can think of various ways to work around this issue, but it's a bit messy and I haven't gotten around to implementing it.
<mark_weaver>brendyn: as long as you have the ~/.config/guix/latest symlink pointing to your working tree, it doesn't matter
<brendyn>Unless you make changes to the wrapper script?
<mark_weaver>look at the actual 'guix' script, in scripts/guix (guix.in for the true source file)
<mark_weaver>it looks for that symlink, and if it exists, it sets the load paths accordingly before running any other guix code.
<mark_weaver>so, in practice, the 'guix' script will use the code pointed to by the symlink.
<mark_weaver>brendyn: I don't understand your comment "<brendyn> Unless you make changes to the wrapper script?". the wrapper script is in /gnu/store, which must never be mutated in any way.
<brendyn>Ok so effectively the wrapper script is so simple it will never be updated?
<mark_weaver>the wrapper scripts are automatically generated to refer to the precise store paths, as part of building the package in guix.
<mark_weaver>brendyn: it would help to understand why you are motivated to think about changing the wrapper script. what problem are you trying to solve?
<brendyn>Ok but suppose I've just finished running `make', guix isn't yet in the store.
<brendyn>I don't want to modify it, I'm just trying to figure out what is actually running on my computer
<brendyn>For example, I still have an old version of the daemon running, but it has had no issues yet
<mark_weaver>brendyn: when guix is not installed, you can run both 'guix' and 'guix-daemon' by prefixing the command with ./pre-inst-env
<brendyn>So I run guix package -u and presumably that finally puts my version of guix into the /gnu/store
<mark_weaver>brendyn: when you install or upgrade the 'guix' package, it will use the latest version of 'guix' that is in your available package definitions. and typically that's the package bound to the 'guix-devel' variable in gnu/packages/package-management.scm, which we only update very occasionally.
<mark_weaver>so, that 'guix' will use old packages, *but* only in the absense of ~/.config/guix/latest
<brendyn>Ok, so by default guix will know that there has been no change
<mark_weaver>when ~/.config/guix/latest exists, the 'guix' script arranges to use the code from there, which in this case will be your guix repo.
<brendyn>That is, the /gnu/store/.../guix script arranges that
<mark_weaver>right, the 'guix' package will not need to be rebuilt very often
<brendyn>Would it be better to have guix output the --help output when `guix' is called with no arguments?
<kingcons>Hey folks. Did a system reconfigure and happily have wifi going. :)
<kingcons>The pulseaudio package is installed systemwide now but doesn't seem to be running. I couldn't find any documentation about a service that needed to be installed. Is there some documentation I misesd?
<kingcons>The only other problem I'm having is that XFCE login only works for the root account, not my added user. Passwd has been set and login with my user works in a tty. ¯\\_(-.-)_/¯
<lfam>kingcons: I don't really know how pulseaudio works but, for me, it gets started on demand when I play something in MPD
<lfam>And, can you send a message to email@example.com about the XFCE issue?
<kingcons>Hmm. Yeah, I need to turn in but I'll send a message tomorrow morning.
<kingcons>One other question lfam, do you know if many folks manage config files with guix or just git and copy dotfiles here and there?
<brendyn>Is there a way to have "optional" dependancies of a package? Is this done with outputs?
<mark_weaver>brendyn: we have no concept of optional dependencies, but sometimes we provide more than one variant of a package, e.g. emacs-minimal vs emacs-no-x vs emacs-no-x-toolkit vs emacs, or qemu-minimal vs qemu, etc.
<mark_weaver>and typically we use the 'inherit' mechanism to reduce the duplication between the package descriptions
<brendyn>mark_weaver: Hmm ok, I'm packaging duplicity and it has a lot of options like python-dropbox
<mark_weaver>outputs can be used to reduce the amount of stuff a user needs to install when using binary substitutes
<brendyn>It seens that rsync shouldn't need to be a dependancy since it's just using it like via POSIX calls or something like that?
<mark_weaver>but when actually building the package from source, all outputs are always produced.
<brendyn>Quite a lot. Most people will only use one or two. Why structure do you recommend? Just make people install everything?
<mark_weaver>however, in order to help ensure that if a program works today, it will continue working tomorrow and be relatively insensitive to the other packages you have installed in your profile, etc, we often prefer to add explicit inputs and to arrange for programs and libraries to find their dependencies by absolute file name in /gnu/store/...
<mark_weaver>what I know is this: if a program tries to find other programs by searching in PATH, then guix makes no guarantees that the program it looks for will be there, and we try to avoid this mode of programs finding other programs.
<mark_weaver>if program A accesses program B by absolute file name in /gnu/store, then guix will *ensure* that program A cannot exist in the store without program B being there as well.
<bavier>but if it rebuilds libreoffice, it should maybe go on core-updates?
<davexunit>I'm checking if libreoffice even builds currently
<davexunit>I've never been able to successfully install it
<davexunit>it builds on x86_64 only, according to hydra.
<bavier>so, I tried adding -DBUILD_SHARED_LIBS=TRUE to cmake-build-system's default configure flags
<janneke>ACTION finally gets vm boot messages to console/emacs shell buffer :-)
<bavier>mostly it helps output size of llvm, clang, allegro-4, and bullet
<bavier>but... it breaks blender, ctl, minetest, aseprite, conky, and withershins
<bavier>for llvm and clang, output size is reduced by 80%
<bavier>I think most of the other 115 packages that use cmake-build-system default to shared libs on their own
<davexunit>bavier: maybe jsut add that flag to llvm and clang for now?
<davexunit>btw, I don't know if I publicized this much here, but my company is now using Guix to build and deploy some complicated software on production servers.
<davexunit>and so far it's been a big success. server build times are down from an hour to ~10 minutes because the complicated custom software is now being built and served from another build machine running 'guix publish' rather than being built from source on each node.
<davexunit>the consultants we are working with try to make us use ATLAS
<davexunit>but I got everything to work with OpenBLAS instead. yay for determinism.
<bavier>davexunit: ATLAS is in most cases vastly inferior
<davexunit>there was just one gotcha with openblas. we had to set an environment variable so that it wouldn't use multithreading in an already multithreaded application
<davexunit>we saw big performance problems and profiling revealed that those problems didn't exist with the atlas version built without guix, so I got worried that all of my work was going to be thrown away.
<bavier>davexunit: sure. There's a build option to disable multithreading if that would be more useful
<davexunit>the environment variable was nicer, I think, because you don't need a separate build.
<lfam>davexunit: That's awesome! 1 hour to ~10 minutes!
<janneke>davexunit: nice! i'm in the process of transferring to guix builds in my company after having used it myself
<davexunit>lfam: of course, using .deb packages would have accomplished the same goal, but the tools for making and building packages are comparatively terrible
<davexunit>and this software is complicated. using guix made it soooo much easier to have a reproducible build.
<lfam>Right, there are lots of ways to avoid building everything from source every time, but Guix is a pretty good way!
<davexunit>I should be able to upstream a few things from this, like packages for Kaldi and OpenFST
<lfam>Festival looks really interesting: "it offers full text to speech through a number APIs: from shell level, though a Scheme command interpreter, as a C++ library, from Java, and an Emacs interface."
<davexunit>bougyman: like Guix, it is also written in Guile Scheme.
<brendyn>alezost: Well I just have the issue that when I try to build a package I get things like license:gpl2 possibly undefined, and so I have to go round looking for scm files definining them and run geiser-eval-buffer untill I finally have every available to compile my package
<alezost>brendyn: ah, you are trying to build your package from a file which does not define module, right?
<brendyn>alezost: It has a define module. maybe it lacks all the needed use-module ? guix build <package> works file but C . b often doesn't
<alezost>brendyn: is it your module? what is its name?
<alezost>brendyn: try this: "M-x run-guile" and ",use(<your-module>)" there
<brendyn>Infact even the command line version is odd. guix build --check --rounds=3 par2cmdline only compiles once.
<catonano>brendyn: it takes some time. I understand your frustration
<catonano>finishing the SICP is a good idea indeed
<brendyn>catonano: yep. I want to make basic usage of guix as simple as pacman.
<catonano>as for the interaction between Emacs and Guile, I messed around with Emacs-Live (or maybe it's called Overtone) for a while. It's an Emacs layer for interacting with clojure
<catonano>the fundamental ways of interacting with an "inferior" interepreter are the same but are better illustrated in the clojure community
<brendyn>I've looked at Clojure but not really got into it. Decided I'd rather make software on the guile vm than Java vm
<catonano>right. I see the attractiveness. I was just illustrating a learning path.
<brendyn>But at the same time it's like there are all these theoretical advantages that I've yet to actually figure out how to use, like stepping through code. and guile error messages are difficult because it'll be like "clusterfuck in ice-9, you suck"
<janneke>davexunit: OK...packaging is probably most of the job
<janneke>although if you do all that effort to package it and not use it yourself...just wondering
<bavier>efraim: thanks; I can push that part of the patch series; I was wanting to write some tests for the "tomb" package before pushing that
<demotri>janneke: Sorry, thought you are willing to add a new package, if it's worth it. And didn't know that it is no longer in Debian. When I used to use Debian and I had a modem, it definitely was there :-)
<janneke>demotri: np, i am considering it. currently i'm using squid on ubuntu, but i'm not too happy with that and hesitant to package it.
<bavier>I wonder if debian thought wwwoffle was dead
<janneke>demotri: i'd rather not package something new esp. if we already have better alternatives.
<bavier>just a 3.5 year stretch between last two releases
<janneke>ACTION has some ambivalent feelings about the > 4000 cheers
<demotri>It was the first time since years that I was on Bischop's site again and was surprised that after years there is a new release.
<davexunit>I realize that I take guix for granted a lot now
<davexunit>there are many things that I can just do easily that I would have never attempted before
<ng0>i think big studios and projects know why unbundling is good.. haven't looked closely at all of it yet, but for example the dependency produced by ILM does unbundle itself into modules. :)
<ng0>I'll probably leave it up to one of the people with more knowledge in licenses to figure out what we have to drop and cut out.. and then to figure out if the end product, USD, is still usable. how free is their free ;)