IRC channel logs
2015-11-09.log
back to list of logs
<fps>hmm, interesting. there's a gcc-4.9.3 package in the store, but also a gcc-4.9.3-lib <fps>where does that come from? <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, civodul says: re PyPi vs. Github, it is best to choose the most complete tarball (the one that includes test, for instance) <lfam>I tried running `python test_configobj.py`. There was no output and $? was 0. I don't know Python well enough to know how to call the tests. <davexunit>where we split things up amongst many store items <lfam>If someone could tell me how to invoke the tests, I can alter the build process to make that invocation <fps>davexunit: oh, interesting. ty <davexunit>lfam: setup.py doesn't have the instructions to do this? <lfam>davexunit: I wish. Grepping setup.py for "test" returns nothing. And nixpkgs uses the PyPi tarball which does not include test <lfam>"Grepping" looks wrong. grep should not be capitalized ;) <lfam>I meant to edit the commit message to indicate that it's WIP. It will fail due to missing tests. <lfam>Also, I should have generated that patch off of master. It might not apply properly in that state. <davexunit>you should contact the maintainer or something <davexunit>and see how you're supposed to run the tests <lfam>Alright, I figured I'd see if I was missing something obvious. If not, I'll go ask upstream <fps>and what's with the commas to the right (inputs '("foo" ,foo)) instead of ("foo", foo)? <lfam>What are the guidelines for capitalization of package names? For example, there is a package whose upstream name is pyRFC3339. For Guix, is that python-pyRFC3339, or python-pyrfc3339? <marusich>the manual says all lower case; check the packaging guidelines section <lfam>Yes, I've read those, although it's good to review them in times of confusion ;) This seems like an unusual case. But I will proceed to lower the caps. <marusich>Yeah that's kind of an odd name to begin with. My reading of the manual is that "python-pyrfc3339" would be right, but maybe you should get the opinion of someone who has actually packaged something before :) <fps>scheme is an interesting language. let's say i'd like to use find-packages-by-name to save me (and others) from manually importing the corresponding module <lfam>I think it's a minor issue. If there are no strong opinions here I will let the patch review process decide. <fps>i suppose i could extract somehow in what module the package variable is defined <fps>but then i'd have to modify the scheme program that is the system config itself <lfam>marusich: It IS an odd name. <fps>i guess my only option would be macros? <lfam>fps: Maybe try a language specific channel like #guile? <fps>lfam: yeah, if noone's interested in the question here i will. <lfam>I think it's interesting but I don't know the language well enough <marusich>fps, regarding the question of the commas, I believe that is "un-quoting" <fps>marusich: interesting. because ("foo", foo) worked, but once i used ("foo", foo, lib) it failed and i had to resort to ("foo" ,foo ,lib) <fps>marusich: will check in #guile, too <marusich>fps, not sure what your code is because that page you linked is not l oading for me <fps>marusich: hmm, interesting :) <fps>oh well.. i'm tired anyways. nn <lfam>How does the python-build-process look for things? Let's Encrypt's tests can't find python2-pythondialog (packaged on my end) even though it is a propagated-input. The environment-variables in the failed build tree have python2-pythondialog in the LIBRARY_PATH but not the PYTHON_PATH. Is that correct? <davexunit>inspect python2-pythondialog's store item to see if it has the right stuff <davexunit>not being in PYTHON_PATH seems to indicate that the needed directory was missing <lfam>I think that it needs to lose the 'lib/' level of the hierarchy <lfam>No, I always get confused looking at store trees. Of course that "lib/" gets mixed in with all the other packages' "lib/"s. <zacts>does gnu guix support linux-libre firmware for any of the thinkpenguin usb wifi devices? <_`_>there's an ath9k-htc-firmware package <lfam>zacts: I can't say for sure but aren't the thinkpenguin devices all Atheros ath9k? That's like the archetypal open source driver <zacts>but they require firmware along with the driver <zacts>I just didn't know if guix provides the firmware by default, or if I would have to manually add this <_`_>The list of packages shows a ath9k-htc-firmware package <zacts>it could affect if I install guix tonight or tomorrow <marusich>I put an "add-to-list" expression like the one suggested into my ~/.emacs file, but emacs complains that the variable geiser-guile-load-path is bad: "Symbol's value as variable is void: geiser-guile-load-path" <marusich>With or without that procedure invocation (before the add-to-list) in my ~/.emacs, Emacs still complains that "Symbol's value as variable is void: geiser-guile-load-path" <marusich>I'd like to get my guix checkout onto the geiser-guile-load-path. <lfam>davexunit: I just finished splitting your wip-lets-encrypt "bunch of stuff" commit into one commit per package definition. Still working on the other dependencies and some circular dependencies in zope (?!). <davexunit>to deal with that, I pick something to disable the tests for. <rekado>catern: yes, you can send requests to a guix-daemon on the network, but you'd need a little bit of socat glue to expose the daemon's socket to the network, and to make the local guix command connect to that socket when trying to talk to the daemon, <rekado>It's the kind of setup I will be using on our cluster once IT has okayed an rw export of the profile directory. <efraim>rekado: have you done a full writeup of how it works all put together? <fps>ok, it's much simpler :) <fps>no manual module loads anymore as long as the first result of find-packages-by-name is what you want :) <fps>and wow, that default indentation style is so butt ugly :) <efraim>you might want to change line 30 <fps>omg, don't gender-assumption-trigger me! ;) <efraim>oh, I just didn't think you had a sibling named Bob :) <fps>in my dreams i am bob's little sister <fps>but seriously; this still has drawbacks. it gives you the _first_ package that is found for the name given <fps>so if that's bad, be more precise and import the module manually <fps>but it's good enough for me.. ;) <fps>we can do the same thing for services maybe. let's see <fps>so if you use "xmonad" there it should give you the first package that this command would find; <fps>fps@potato ~/guix-system-config$ guix package -A "^xmonad$" <fps>xmonad 0.11.1 out gnu/packages/wm.scm:188:2 <fps>if i got my regex-fu still in check <efraim>for xmonad, is there a chance you would end up with ghc-xmonad-contrib? <fps>no, see the difference between <fps>guix package -A xmonad <fps>guix package -A "^xmonad$" <fps>find-package-by-name uses the exact package name <efraim>ok, so that would take care of that part <fps>efraim: or maybe i still didn't quite understand you right <efraim>i mean without defining find-guix-package, if you just said you wanted xmonad, would you end up with ghc-xmonad-contrib <fps>in that case you'd do someting like: <fps>(packages (cons* xmonad htop %base-packages)), right? <fps>in that case you'd use the xmonad variable which you got from (use-modules gnu packages wm) for example <fps>no chance of getting xmonad-contrib either.. <efraim>so then if there were two versions you'd have to specify the version number you wanted <fps>which didn't yet have the definition for find-guix-package? <fps>it's equivalent. it's just that the procedure was factored out for more pwetteehness <efraim>I've hardly spent any time configuring systems, mostly just with packaging so far <fps>it's pretty cool though that you can do that without caring about configuring systems :) <efraim>package definitions stand on their own mostly <efraim>gotta get the software in before I switch my laptop over <fps>yeah, next thing i'm gonna try is to load firmware for my wifi :( <fps>oops, i hope i didn't non-free-trigger the channel again <fps>ACTION runs and hides <rekado>efraim: no full write-up exists at this point. The information needed to set this up is spread across bug reports. <rekado>I've been meaning to write something for the manual but haven't been able to do so yet. <fps>tidbit for the qemu users: if you want sound in qemu try: QEMU_AUDIO_DRV=alsa qemu-kvm ... -soundhw hda <fps>works decently with buffer sizes around 4096 <andreoss>/home/andreoss/local/sbin/guix-register: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/andreoss/local/sbin/guix-register) <mark_weaver>andreoss: guix-daemon requires a C++ toolchain/library that supports C++11. it may be that the one on your system is too old. <andreoss>which library in particular should i update? <andreoss>also it's strange that it complied against non-present library without any complain <mark_weaver>if you are avoiding our binary installation method because you don't want to trust our binaries, you should know that even if you compile everything from source in Guix (which takes a long time), you still must start from our "bootstrap binaries". <mark_weaver>so there's no way to use guix without trusting some of our binaries <mark_weaver>at least no documented way. in theory, a set of suitable bootstrap binaries could be produced in another way, but it's not trivial and so far no one has done it. <mark_weaver>but to answer your question, the library that needs updating is libstdc++, and that probably requires updating your gcc as well <mark_weaver>it's quite rare and dangerous to update C/C++ libraries on most distros. <mark_weaver>(without updating to a major new release of the distro) <andreoss>why binaries are shipped in source distribution? <mark_weaver>there's no way to compile anything without starting from somewhere <mark_weaver>I agree that it would be nice to document a way to cross-compile bootstrap binaries from an arbitrary system, but it hasn't been done yet and there are many more pressing things to do right now. <mark_weaver>guix is designed to perform builds in a controlled environment unaffected by the particular machine you're on or the host OS. using the host OS libraries and compiler to start would defeat that goal. <mark_weaver>all builds done in guix are in a container where only components from guix are visible. <roelj>Why are the package expressions compiled when running "make" on the git repo? <roelj>And why is it downloading guile versions that are not for my architecture anyway? <mark_weaver>roelj: good questions. as for the latter question, I'm sure that could be improved, but downloading only the one for your current architecture wouldn't be right in the case of x86_64, because on that architecture you can also run and build i686 binaries, and so you'd need to download i686 as well. <rekado>roelj: they are compiled for improved performance. <mark_weaver>and actually, if you have offloading set up with machines of a different architecture, then it is actually possible to build binaries for any architecture that you have a build slave for. <mark_weaver>but again, that only works if you have the bootstrap binaries available locally. <mark_weaver>as for why we compile all the package recipes: when you ask to compile a package, it needs to look not only at that package, but also the entire set of packages that would be needed to build that package, all the way back to the bootstrap binaries. that's a fairly large set of packages. having them all compiled probably makes a significant difference. <mark_weaver>and commands that have to look up packages by name, e.g. "guix package" or "guix build", need to load *all* of the package modules first, which is quite a bit faster if they're compiled. <roelj>mark_weaver: I see. Thanks for the clarification. In theory, this wouldn't be needed, would it? It's just an optimization for speed, right? <mark_weaver>in fact, you can run guix without the package modules being compiled ahead of time. it works, it's just slower. <roelj>I see that gtk.scm contains a definition for Cairo as well. What if I want to add a package that only needs Cairo? <roelj>Can I then simply #:use-module (gnu packages cairo)? <rekado>roelj: use-module is used to make variables from the named module available in the current module. <paroneayea>davexunit: what's that docker ssl bundling vulnerability thing you linked me to? <rekado>roelj: to declare a package as a dependency / input you need to reference the package variable by name. <fps>fyi, a little helper function to find the module automatically at the top.. <fps>(packages (append (find-guix-packages '("htop" "wget)) %base-packages) <fps>was simpler than thought.. <paroneayea>wingo: wrote a bit too-long of a reply to your latest blogpost ;) <mark_weaver>roelj: the 'cairo' is defined in the gtk.scm, and no where else. if you want to use it, you must import the (gnu packages gtk) module. importing (gnu packages cairo) won't work, because there is no such module. <paroneayea>which is unfortunate because I was *really* excited about the guile/guix room <roelj>mark_weaver: Thanks. I was a bit confused for a moment that it would also drag in the GTK dependencies, but these are just package definitions. It's not like apt or rpm dependencies.. <mark_weaver>right, importing a module just makes available the exported variables from that module. in this case, 'cairo' is a variable exported by the (gnu packages gtk) module. that variable is bound to a package object. <roelj>When compiling my package definition (guild compile name-of-package.scm), It tells me "no code for module (guix utils)". I believe I'm missing something obvious.. <mark_weaver>roelj: it's missing the guile load paths needed to find (guix utils). normally when adding packages that might be submitted upstream, the right thing is to put the file directly in the git repo, add it to gnu-system.am, and then run 'make'. Otherwise, I would not bother compiling it. having just that one file interpreted will not make much difference. <rekado>I have never used guild compile for any of my external package definitions. <roelj>Where should I put the file so that Guix can find it? <roelj>And what is the right way to compile it? <rekado>do you intend to add the package definition to Guix itself? Then I suggest working on a git checkout and adding the package to an existing module. <rekado>alternatively, you can set GUIX_PACKAGE_PATH and point it at the directory containing your custom modules. <mark_weaver>right, and I would add that the directory containing your custom modules shouldn't have anything else in it. (e.g. don't make it your home directory :) <rekado>if the package name is (my custom stuff) the file stuff.scm is expected to be in $GUIX_PACKAGE_PATH/my/custom <mark_weaver>because actually guix will recursively scan the entire directory and load all of the *.scm files in there. <roelj>Is GUIX_PACKAGE_PATH empty by default? <roelj>So it's really for custom packages only? <mark_weaver>I don't think I've ever set that variable, for example :) <mark_weaver>I always run guix out of a git checkout, and I make modifications and add packages there. <paroneayea>google released its machine learning software as free software under apache v2 <roelj>What's the policy about adding packages to Guix? <mark_weaver>that method also allows making arbitrary custom modifications to any part of guix, by working in a private branch of git, and easily incorporating upstream work into your private branch. <roelj>paroneayea: Is TensorFlow really Python-only? <mark_weaver>roelj: see the "Packaging Guidelines" and "Contributing" sections of the guix manual. <paroneayea>roelj: it looks like it has a python api but I'm not sure it's the only language possible <roelj>mark_weaver: Well, I wrote a package definition for a program no one will probably use in the Guix community. It is a GNU package though. Would it be useful to add it to upstream Guix, or should I just leave it at my personal package definitions? <roelj>paroneayea: It looks cool. I hoped to find a C or C++ version of the library. <mark_weaver>roelj: if it's a GNU program, then we certainly want it. ditto for any program that is free and complies with the requirements of the GNU Free System Distribution Guidelines. <mark_weaver>well, the ditto part is a slight exaggeration I suppose. there are many tiny one-off programs we wouldn't want. but if it's generally useful, we want it. <paroneayea>ACTION packages a bunch of starter hello world programs he's written over the years ;) <roelj>Ok! Then I will submit a patch soon. <roelj>mark_weaver: Thanks for your help. <taylan>"If TensorFlow is so great, why open source it rather than keep it proprietary?" that's asking it the wrong way around :\\ <roelj>How do I get the right hash for a package? I used guix download <the-link-to-the-package>. And then used guix hash /gnu/store/<the-package-filename>.tar.gz. <rekado>guix download prints the hash as well as the path to the item in the store <roelj>Can I then (sha256 <the returned hash>) in the package description? <roelj>Hm, I removed my package from the /gnu/store directory (rm -f) so I could redownload it and view the hash. Now running guix download <package-link> results in "guix download: error: open-file: Nu such file or directory: "<path-inside-store>". <roelj>I guess I shouldn't have manually messed with the store.. <roelj>How can I recover from this? <roelj>TensorFlow has a C++ API too. That's cool! <rekado>to delete items from the store use "guix gc -d /path/to/store/item". <rekado>it will tell you if the item is still referenced and refuse to remove it in that case. <roelj>For the future, can I get the hash at a later time after 'guix download' as well? <rekado>(how to recover: don't know. There's no automatic or safe way to restore the item. You might have to mess a little more with the store to make it forget about the item.) <roelj>Well, it seems that guix gc -d "<the old path>" worked. <wingo>probably the sqlite file that knows what the roots into the store are still referenced your path <wingo>ACTION has not had to run guix gc yet <roelj>What's the difference between "(license license:gpl3+)" and "(license gpl3+)"? <wingo>roelj: it is usually the same <rekado>"license:" is a prefix to differentiate between variables that are named the same as licenses. <rekado>e.g. "expat" exists as a package and as a license name. <rekado>so we usually import licenses with the "license:" prefix. <wingo>in guile names are resolved in a scope to determine their meaning. we assume that gpl3+ is bound to a license object that is indeed the gplv3+ :) but you'd have to do more analysis to know that for sure. the source of the binding is usually in (guix licenses) where you can see all the licenses <wingo>so yeah as rekado says sometimes the (guix licenses) module is imported in such a way that every name that is imported gets the license: prefix added on <roelj>Is it preferred to do it that way? <roelj>I suppose that would be '#:use-module ((guix licenses) #:prefix license:)' and then use '(license license:gpl3+)'. <rekado>it is annoying to have to change all license fields once it becomes necessary to add the prefix. <roelj>Does the order of the #:use-module stuff matter? <rekado>it does not, but for (gnu packages ...) we like to keep them in alphabetic order. <rekado>I usually just copy the header of another module and edit it. <roelj>packaging for Guix is pretty easy <roelj>much less involved than creating RPMs or DEBs.. <alezost>marusich: re "add-to-list" error: this happens because `geiser-guile-load-path' doesn't exist on emacs start (as geiser is not loaded yet). A usual emacs way is to wrap such settings in `eval-after-load' or `with-eval-after-load'. So it should be: (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/src/guix")) <marusich>alezost, thank you. That makes sense, and what you suggest seems to have fixed the issue in the way I wanted. <alezost>actually I don't modify `geiser-guile-load-path'; instead I set my GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables <fps>roelj: just to chime into the previous discussion about buiding custom packages: most guix tools also have a -L parameter, so if you have in your home ~/guix-custom with custom packages in it you can do e.g. guix package -L ~/guix-custom -A search_term or guix package -L ~/guix-custom -i your-package-name <fps>if you don't want to commit to setting an environment variable <roelj>fps: Thanks, that is very useful <roelj>I have a package defined as '(define-module (gnu packages inklingreader) ...)' and a function defined as '(define-public inklingreader (package ..))'. Now when I invoke 'guix package --list-installed | grep inkling' I get: "guix package: warning: failed to load '(gnu inklingreader)': ERROR: no code for module (gnu inklingreader)" <davexunit>roelj: where does that file live on the load path? <davexunit>it should be in gnu/packages/inklingreader.scm <roelj>So, when I forgot a dependency, the build should fail, right? <davexunit>and whether some code runs that can detect the issue <roelj>It's an autotools-based project. I wonder how I should deal with optional dependencies (like texinfo). <roelj>What is expected from a package? <roelj>A minimum set of dependencies to build it, or everything it can possibly depend on? <fps>roelj: also can you pastee.org your file? <fps>you sorted it out already <roelj>I'm installing the package now. See how that goes. <efraim>pkg-config normally goes in native-inputs <efraim>in description, 2 spaces after a period <roelj>Wouldn't it be great to have some way to automatically convert the description of an Autotools-based project into a Guix package expression? <efraim>not automatic, but I sometimes grab the description from debian <fps>i guess you could write a little tool that scans existing repos from other distris and offers you to collect tidbits from here and there and then write an initial package file <fps>a little care should be taken about attribution <roelj>Maybe it'be cool to have an "easy" way to generate packages (RPMs, DEBs, PKGs) from the Guix builds. Then when people use Guix to build packages for other distros, they can be automatically added to Guix as well. <roelj>A nice user interface could lure them in. <roelj>I realise that would be a lot of work.. <fps>otoh writing packages for guix is so little work compared to others <fps>dunno about gentoo though or arch. they are pretty streamlined, too, i hearf <roelj>fps: Yes I've seen the descriptions of Arch packages, and that looks very good. <fps>what i'd really like to see is the going away of the central build service. distributed data stores for the win! <roelj>I'm wondering if we could make a conversion tool. <fps>i build a package, store it, publish it, you get the choice of building or trusting my derivation <roelj>fps: Yes that would give users more freedom to customize. <fps>someone else builds it and can compare the hash, reinforcing the store [depending on dds implementation] <fps>there was a slight issue of builds depending on the guix version though.. hmm, so only builds from the same guix version could be shared this way <fps>dunno yet if that's good or bad <fps>the basic idea of dds's like morphis is really simple :) sadly it's been pretty much abandoned by its main author. ipfs shares many properties though <roelj>What is DDS? Do you have a link to something I can read? <fps>read the original kademlia paper <fps>ipfs and morphis both build on it and extend/modify it somewhat <fps>the file content basically defines its adress <fps>by way of hashing it <fps>so if i give you a file hash <fps>you can download it from the dds <fps>and you know that the file hashes to the given hash <fps>if you don't trust the net you can rehash the result, too <mark_weaver><fps> i build a package, store it, publish it, you get the choice of building or trusting my derivation <mark_weaver>fps: we already support that. see "guix publish" and "guix challenge" <fps>mark_weaver: but it's centralized? <mark_weaver>what's centralized now is the hydra.gnu.org build farm, but you don't have to use it. <mark_weaver>also, the longer term plan is to distribute binary substitutes via gnunet <fps>is that like freenet, just more gnu? <mark_weaver>there was a gsoc project about that, although I don't remember how much progress was made <fps>when i tried freenet it was dog slow compared to morphis/ipfs at least.. <fps>but it's been a while.. <fps>mark_weaver: ah, it's "centralized" in the sense that someone has to provide those http servers.. hmm.. <mark_weaver>I don't know enough about freenet to make a good comparison, but at least superficially they seem similar in their goals. <mark_weaver>fps: http is not centralized. anyone with a public IP address can run an http server. <fps>oh, gnunet uses kademlia, too <rekado>fps: how is it centralised when anyone can run "guix publish"? It's not pseudonymous but certainly not centralised. <fps>mark_weaver: sure. the thing about distributed data stores is that you don't have to care much about that though :) <fps>everyone who runs a node is part of the store <mark_weaver>"don't have to care much about that"? what do you mean? <mark_weaver>there's also "guix archive" if you prefer something lower-level where you just pass files around somehow. <fps>mark_weaver: ok, here's a use case with e.g. morphis. 1] run morphis client 2] upload file to store 3] give you hash 4] you run morphis client, 5] retrieve the file by hash <fps>so by having a dds node instance run on your box you automatically become part of the store.. <efraim>the example in the manual for guix archive shows passing the file directly through ssh to another guix installation <mark_weaver>and by running "guix publish" you automatically become able to serve substitutes to anyone with your URL. <mark_weaver>I don't really understand the distinction you're making between the two. <fps>hmm, i guess it's a paradigm shift.. sure, they are similar in the same sense that two languages that are turing complete are similar <efraim>or just have everyone run tahoe-lafs and store the packages there <fps>but compare scheme with assembler :) <fps>sure, it's the same :) <mark_weaver>well, anyway, I think the gnunet option, which we're working toward, is probably along the lines of what you want. <fps>awesome, then i don't have to do it.. if i can help though, let me know <rekado>I'm thinking about adding a new phase to the python-build-system that changes all import statements to point at exact paths in the store. <fps>i suppose one could do a little hackery on top of guix archive and gnunet :) <rekado>it's annoying that I'm forced to install programmes into separate profiles or upgrade my profile only because they have inputs that propagate numpy. <rekado>would be nicer to do without propagation. <mark_weaver>fps: I haven't been following that project very closely (not for lack of interest, just too busy), but I would suggest learning about gnunet, searching guix-devel for past discussions about the gnunet support, and then when you feel ready to contribute, post something to the ML about it. <fps>mark_weaver: ye.. i have to get my wifi working first, though ;) <mark_weaver>yes, of course. I wouldn't be happy either without my wifi :) <fps>so much to do, so little time <rekado>ACTION still has no wifi; need to replace the lenovo BIOS with libreboot soon. <rekado>someone in the local FSFE group may soon have a serial programmer that I could borrow. <rekado>a little more difficult than the x200, but should work with some patience and the right tools. <mark_weaver>yeah, and I've found the folks in #libreboot to be quite helpful <davexunit>now I want to see an official GNU laptop: grub + libreboot + guixsd :) <roelj>What's the difficulty with gnome-shell fox Guix? <mark_weaver>gnome is challenging to package, especially on a system that doesn't put things in the standard filesystem locations. <efraim>re:wifi, I was thinking of just tethering an old phone to my laptop <davexunit>and there was some systemd stuff that had to be worked out. <mark_weaver>but I think we're getting close. we just recently got gnome-session and mutter. <davexunit>can't wait to be back to my usual environment. <efraim>i haven't used gnome in almost 3 years, too much for my laptop :) <roelj>I'd love to look into getting gnome-shell to work as well. Though I have some way to go to learn Guix. <davexunit>but it's really interesting to think that GNU could actually realistically provide computers running tons of GNU stuff: the boot firmware, init system, package manager, desktop environment, etc. <mark_weaver>packaging gnome for guix is quite challenging. not recommended for starting out. <davexunit>maybe try packaging Cheese. I want it for testing out my webcam :) <mark_weaver>davexunit: you can test your webcam with this command: gst-launch-1.0 v4l2src ! xvimagesink <roelj>I'll have a look after my first package builds.. It takes a long time now..! <mark_weaver>but cheese would still be nice to have, of course :) <davexunit>oh btw, I don't have official official confirmation, but I asked to speak about Guix at the local Boston Linux users groups and was offered a spot in January, a bit before FOSDEM. <efraim>someone take a video this time! :) <davexunit>I've never been to one of their meetups because I never have time to go to meetups on weeknights, but I'm hoping it will be useful. <davexunit>I don't know how many people attend on average or anything. <davexunit>but they meet at MIT so hopefully it will be fun. <rekado>efraim: re wifi: that's how I do it when I'm not near a cable. <roelj>I installed Guix from Git sources, and I didn't install any package. Then I ran 'guix install' with the --no-substitutes option. Does that result in Guix building every dependency package from source? <roelj>Brilliant. How long does something like that take, normally? <davexunit>a very long time if you're building the first thing <davexunit>the entire dependency graph will be bootstrapped from the bootstrap binaries. <roelj>I guess that's what the substitutes are for.. <roelj>Can I somehow safely cancel the process and restart without --no-substitutes? <efraim>it won't save your progress on partially downloaded or built packages, but anything finished won't be substituted when you rerun guix install <roelj>So if I decide to not install something while it's compiling. Can I garbage-collect whatever isn't used (the already-compiled dependencies) using guix gc? <roelj>Does Guix integrate nicely with COW filesytems, like BTRFS? <davexunit>provided it supports symbolic and hard links <roelj>Does it create (sym)links for everything that hasn't changed? <roelj>Let's say I update Emacs, and only ~20% of the files have changed. <roelj>A new derivation of Emacs is available in the store. <roelj>but the old one can be used as well <davexunit>hard links are used in some places for deduplication <roelj>Does it link to the files that haven't changed since the 'older' version of Emacs? <efraim>I don't believe so, but I've never checked something like that <davexunit>I believe the GC does the compacting, as it reports to you how much space is currently being saved due to hard links. <roelj>Not sure if it's desired though. It makes things rather complex. <efraim>1.2 million items in /gnu/store, lets see if I can see anything with ncdu <efraim>ok, so I think every single item is hashed and a hardlink is created from every item to its hash in .links, and that's where the deduplication takes place <efraim>or the other way around, if that makes more sense from a garbage collection after deletion point of view <roelj>That would be a very effective deduplication technique. <efraim>I can't immediately think of how to check that nothing points back to the item in .links <efraim>the 1.8GiB of texlive is 'H' in /gnu/store and 'H' in .links <roelj>ERROR: In procedure module-lookup: Unbound variable: make-session <roelj>Is it something I did wrong in my package expression? <roelj>I don't need cmake directly for my package, maybe some dependency needs it. <roelj>I thought gtk+ was autotools-based as well. <roelj>The 'guix download' leads to the same error: ERROR: In procedure module-lookup: Unbound variable: make-session <roelj>I copy-pasted the link you gave me <efraim>it was fixed in the git repo about a week ago <roelj>Hmm, was it that long ago I checked out the repo? Probably.. <alezost>roelj: I think "guix pull" will fix this issue <fps>is there a way to find out what package provides a binary executable? <keverets>the equivalent of a "dpkg -S" would be very handy <fps>and is there a wa to pass in a string from the package definition to the builder g-exp? <fps>inputs seems to refer only to packages? <alezost>fps: I didn't get it, what string do you mean? <fps>let's say i put together some variables for assembling different parts of the source name. e.g. archive-adress "http://foo/bar, "archive-base-name "foobar", and archive-uri (string-append archive-address archive-basename ".zip) <fps>and i'd like to refer to them from withing the trivial builder's #:builder argument <fps>the (inputs ...) field of the package definition is available as %build-inputs <alezost>fps: yes, you can wrap package definition in a (let ...) <fps>alezost: that's what i do. hmm, maybe i messed something else up <fps>oh, i just noted: there's a missed oppportunity of parallelism: you could download a package's source while the required inputs are still downloading <fps>once the build inputs and the source have been dl'ed the build can start <fps>"unbound variable: archive-base-name" <fps>will sleep over it... <alezost>fps: I mean to use it like this: (argument `(#:builder (... ,archive-base-name ...))) <fps>alezost: yeah, that's what i tried, too. i got invalid input <fps>gave it a name and used assoc-ref <fps>alezost: i'll try again tomorrow <alezost>fps: ok, you can reference to such variable the same way as to 'version' or 'name' (for example, as in 'font-ubuntu' package) <fps>alezost: ok, cool. taking a look <roelj>alezost: Thanks for your solution. I had done git pull; make; sudo make install; already and it seems to work as well. <alezost>roelj: oh, great; I didn't think you use guix from git directly <alezost>oh, "make install", not directly then :-) <roelj>alezost: What's the difference between 'guix pull' and 'git pull'. I remember doing 'guix pull' about a year ago when I last touched Guix. <alezost>"guix pull" downloads the latest guix source, and compiles its guile code, so when you run "guix ..." commands, you use this new code. If you use 'git pull' and make, then you don't need to run "guix pull" <roelj>alezost: Thanks for the explanation.