IRC channel logs


back to list of logs

<mark_weaver>civodul: ah good, thanks!
<mark_weaver>hmm, so bison is available to build the first bash during the early bootstrap?
<civodul>see you tomorrow!
<mark_weaver>oh,I see you added it.. nvm.
<civodul>Hello Guix!
***civodul changes topic to 'GNU Guix | | things to package: | hackathon TODAY:'
<civodul>hackathon! :-)
<pjotrp>Guix 0.7 is running smoothly on Debian - just installed guile-2.0.11 and emacs-24.3
<pjotrp>may not seem like much, but it is the first time :/
<civodul>hey pjotrp
<civodul>good to hear!
<pjotrp>how do I get a path list of dependencies for emacs, for example? I am looking at package and archive, but can't find that.
<pjotrp>nix-env had such a feature
<civodul>pjotrp: guix gc --references $(guix build emacs)
<civodul>that will list the direct deps
<pjotrp>cool! I am making notes.
<a_e>I am still busy with my household chores, but will join in the afternoon.
<a_e>Pjotrp: Nice you got it running!
<civodul>hey, a_e!
<pjotrp>I am trying to learn emacs, org mode, guile, lisp and guix at the same time. Target is a Ruby package.
<civodul>Ruby isn't packaged actually
<a_e>That sounds like a lot at the same time! I think you could get there more slowly.
<civodul>pjotrp: ISTR you tried packaging Ruby some time ago, and then forgot, no? :-)
<pjotrp>I have a prototype Ruby package
<pjotrp>xemacs was my primary editor ages ago, and I have done some Lisp. Main thing is to get acquainted with the ecosystem of Guix.
<Calinou>hi, where can I help for translations
<pjotrp>This is cool: guix gc --requisites
<civodul>hi Calinou
<civodul>Calinou: translations of the messages in general you mean?
<civodul>that part is handled by the Translation Project:
<civodul> gives some info on how you can help
<Calinou>CA is required, no thanks
*Calinou holds a grenade for 4 seconds
<Calinou>copyright assignment (which they call “disclaimer”)
<civodul>this could be relaxed for Guix, since Guix copyright itself isn't assigned to the FSF
<civodul>but i don't know, maybe i'm overlooking something
<Calinou>but the translation platform you use (which sucks by the way) does
<civodul>unpleasant behavior
<pjotrp>that is putting it mildly ;)
<pjotrp>compiling: ./pre-inst-env guix build -K -e '(@ (gnu packages ruby) ruby)
<pjotrp>almost. I upgraded to Ruby latest (2.1.3). Got to testing phase and './ruby is not found.'. Not too bad.
<pjotrp>So far, I have been running in a terminal. Maybe I should switch to emacs?
<pjotrp>I realise the build issue is not related to that question ;)
<a_e>I am updating a few packages, because it is almost a background activity, but requires a bit of waiting for the builds. I suppose that I should not update parted in master, nor help2man (which induces a rebuild of grub)?
<pjotrp>Is it better to build in degraded mode when developing packages?
<civodul>a_e: help2man and parted are OK
<civodul>however, there were issues with upgrading parted
<civodul>test failures and such
<civodul>mark_weaver and i reported issues on bug-parted a while back
<civodul>pjotrp: "degraded mode"?
<civodul>guix-daemon must always be running
<civodul>or did i misunderstand?
<pjotrp>so when a build fails I need to change ownership on the -K dir to be able to compile by hand
<pjotrp>and see if I can the compilation
<civodul>-K is useful to understand what's going on, and also to see if it's related to the chroot environment
<pjotrp>so yes, now I switch to the dir, change ownership (as root), and try compilation by hand. Is this what you do?
<pjotrp>at the moment I am getting make[2]: Circular ruby <- ruby dependency dropped.
<pjotrp>this is new, probably a make 4.0 thing
<pjotrp>I am trying to find a development cycle that is efficient...
<pjotrp>hmm. Reading up on make and find it has guile built-in ...
<pjotrp>interesting developments :)
<pjotrp>@ build-succeeded /gnu/store/y7b1wvjvc7hvi7ihvs9mcc757yqr3qg8-ruby-2.1.2.drv -
<pjotrp>that is a start.
<pjotrp>the circular dependency got removed after patching for sh.
<pjotrp>civodul: do we have any recommended documentation on how to debug packages including the package compilation cycle?
<pjotrp>I am clear about the Guix/scheme side, but what approach do you have for hacking compilation errors?
<pjotrp>just installed geiser
<pjotrp>geiser lacks context. How do I start the equivalent of ./pre-inst-env guil
<bavier>Hello Guix!
<bavier>pjotrp: I've also been meaning to get more acquainted with geiser
<pjotrp>found this (setq-default geiser-guile-load-path '( ... "~/src/guix" ...))
<a_e>@bavier: Hello!
<pjotrp>yes, adding (setq-default geiser-guile-load-path '("~/src/guix")) to ./emacs allows M-x geiser followed by ,use (guix)
<a_e>Concerning updates, there were also problems with xnee. And I think I tried gnunet and octave some time ago with problems. Just for the record if someone feels like investigating!
<bavier>a_e: I could look at octave
<a_e>Ah, and autogen also did not upgrade out of the box.
<a_e>As well as mit-scheme.
<civodul>pjotrp: re recommendations, nothing particular; you could look at "Defining Packages" in the manual, and "The Perfect Setup" in 'HACKING'
<civodul>hello, bavier!
<pjotrp>I have read those.
<pjotrp>civodul: it would be so helpful if you could show how you work
<pjotrp>maybe post a video about going through the steps of adding a package using emacs/geiser and all that. Fix a few bugs, build and submit patch?
<pjotrp>now I am grappling and second guessing - I am sure I am not the only one
<pjotrp>anyway ruby 2.1.3 builds fine
<pjotrp>I'll submit a patch
<davexunit>morning #guix!
<a_e>Night! ;-)
<bavier>davexunit: morning!
<civodul>pjotrp: if you look at the videos on, you'll find coding sessions that might give you a hint
<civodul>howdy, davexunit
<pjotrp>ah, ok
<pjotrp>is it possible to install a package from the path, e.g. guix package -i /gnu/store/bi3f7criw81pb2r5xx8qfa6bdhh52sk9-ruby-2.1.3
<davexunit>pjotrp: ooh you're working on ruby? that's great. I got stuck trying to make a ruby package. their build scripts are odd.
<bavier>pjotrp: if the build recipe hasn't changed, you should be able to do `guix package -i ruby` and it will pick up the latest version from the store
<pjotrp>I am building in the source tree with ./pre-inst-env guix package -i ruby
<pjotrp>guix package -i ruby gives guix package: error: ruby: package not found
<davexunit>pjotrp: does running 'make' complete without errors/
<pjotrp>davexunit: yes
<pjotrp>The following package will be upgraded:
<pjotrp> ruby 2.1.3 -> 2.1.3 /gnu/store/bi3f7criw81pb2r5xx8qfa6bdhh52sk9-ruby-2.1.3
<pjotrp>on ./pre-inst-env guix package -i ruby
<davexunit>that looks right
<pjotrp>Problem is that my ~/.guix-profile/ is not updated by the latter.
<pjotrp>nix-env used to be able to install from the store path
<davexunit>I imagine that you can with guix, too. civodul?
<pjotrp>anyway, ruby patch on the mailing list. Please try it.
<civodul>pjotrp: yes, it's possible to run, say: guix package -i $(guix build ruby)
<pjotrp>I just installed my first gem :)
<civodul>it's not completely equivalent to "guix package -i ruby", though
<civodul>wo0t! :-)
<pjotrp>civodul: I should have tried that!
<davexunit>pjotrp: now to package the ruby gems in guix!
<civodul>and to code up a "gem" importer :-)
<davexunit>yes indeed. I anticipate it being a bit easier than with pypi
<davexunit>gemfiles seem more structured.
<davexunit>having trouble applying this patch with git am
<davexunit>"patch does not have a valid email address"
<pjotrp>just patch the tree, I don't need the credits.
<pjotrp>./pre-inst-env guix package -e '(@ (gnu packages ruby) ruby)'
<pjotrp>The following package will be upgraded:
<pjotrp> ruby 2.1.3 -> 2.1.3 /gnu/store/bi3f7criw81pb2r5xx8qfa6bdhh52sk9-ruby-2.1.3
<pjotrp>nothing to be done
<pjotrp>but won't update ~/.guix-profile/bin
<pjotrp>what am I missing?
<civodul>what does "guix package -I" say?
<pjotrp>I am an ass
<pjotrp>testing in a terminal without the path set :(
<pjotrp>that is what it should say!
<civodul>that happens :-)
<pjotrp>Anyway, thanks everyone. I finally have a nice Ruby installation. This should get rid of rvm for once and for all!
<civodul>make sure to run "guix lint ruby", check doc about coding conventions in 'HACKING'
<civodul>and then post the patch!
<pjotrp>I did try lint. It does not complain about ruby, but it does complain about bash
<civodul>everyone complains about Bash these days
<pjotrp>If you want me to use git make-patch, tell me how I should merge all commits into one.
<civodul>arf, git rebase --interactive or use Magic in Emacs
<pjotrp>there is nothing wrong with bash, there is nothing wrong with bash. It is just how you handle it ;)
*civodul goes meat a_e & Steap
<pjotrp>I thought rebase was evil ;)
<bavier>the evilness of rebase is relative to project tastes
<davexunit>pjotrp: good riddance to rvm! I hated using it at my last job
<davexunit>but yeah, use git rebase --interactive to squash all the commits together
<a_e>pjotrp: Your indentation is a bit weird - no new line after an opening '('.
<davexunit>I am eager to test out this ruby package. it's interesting that you didn't run into the problems that I did when trying this.
<davexunit>I got weird Makefile issues.
<pjotrp>needed to patch for /bin/sh
<pjotrp>rvm is a mess.
<davexunit>it takes over 'cd'! the horror
<davexunit>I'm working on a 'bundler' replacement
<davexunit>that works like nix-shell
<pjotrp>if you get it right we could move the Ruby communty over ;).
<davexunit>they'd probably choose nix because nix has a lot of OS X users.
<davexunit>need to convert ruby gems to guix packages now.
<davexunit>if we could get rails packaged...
<davexunit>(and all of the 1000 libraries it depends on)
<pjotrp>that is pretty daunting ;)
<pjotrp>I'll start with a few of my CLI tools that have few dependencies - I would like to get Guix going in CloudBiolinux
<pjotrp>davexunit: did the ruby patch work for you?
<davexunit>pjotrp: I couldn't get it to apply. do you the command I should run?
<davexunit>I'm used to running git am < foo.patch
<pjotrp>try the latest on the ML
<davexunit>oh cool, didn't see that mail come in. :)
<bavier>so, I added sqlite to python's inputs. Now subversion builds are failing :P
<bavier>apparently before the subversion tests suite was halting early when it reaslized there is no sqlite3 module in python
<davexunit>pjotrp: building ruby now
<davexunit>pjotrp: nitpick: the commit message should read "gnu: Add Ruby."
<pjotrp>ok ;)
<pjotrp>Typical case of second guessing
<davexunit>you can also remove the commented lines for importing the trivial build system and the patch-flags
<pjotrp>Anyway, I achieved installing guix building a package today and working with guile and emacs
<davexunit>that's great!
<bavier>pjotrp: yay!
<davexunit>pjotrp: ruby works!
<pjotrp>there you go. Let the baby fly :)
<davexunit>pjotrp: are you interested in cleaning up the nitpicky details today? I can send an email with my comments.
<pjotrp>not today
<pjotrp>but feel free
<pjotrp>next step is to get bundler working, I suppose
<davexunit>I'll leave the comments, then.
<pjotrp>at the moment 'gem env' is pointing to the wrong places - I am thinking of forcing an install path that contains the HASH, e.g. ~/.gems/bi3f7criw81pb2r5xx8qfa6bdhh52sk9-ruby-2.1.3/
<davexunit>where does gem env point?
<davexunit>do we need to set environment variables?
<davexunit>despite programming in ruby for 2 years, I don't how the gem stuff really works
<pjotrp>yes, you have GEM_PATH and GEM_HOME
<pjotrp>that is what rvm manipulates
<davexunit>a-ha. so guix has a facility for dealing with these native search paths.
<davexunit>what should these values be?
<pjotrp>Whatever we like :)
<pjotrp>That is why I am thinking of the HASH
<pjotrp>that allows for clean $HOME installation of gems
<pjotrp>Only for system-wide I think we need to opt for guix packages.
<pjotrp>anyway, I'll have a think about it and maybe play a bit tomorrow. At least we can bootstrap ruby now.
<davexunit>pjotrp: check out gnu/packages/python.scm
<davexunit>there's something called "native-search-paths"
<Steap>davexunit: are you working on integrating your PyPI script into "guix import" ?
<davexunit>Steap: yes
<Steap>ok :p
<davexunit>well, I will be. right now I'm talking about ruby. :)
<pjotrp>I meant: ok
<pjotrp>keyboard challenged sometimes ;)
<davexunit>pjotrp: I think we just need to add the right relative directories to search in, and guix can output the full path for whichever profile a user happens to use
<pjotrp>sounds good
<davexunit>I guess we can set both GEM_HOME and GEM_PATH to that
<davexunit>civodul: how do you want the interface to 'guix import' to look? 'guix import pypi foo' or 'guix import --pypi foo'?
<civodul>for the command line, either way is fine with me
<davexunit>I don't really know how to implement the former, but I like it better.
<pjotrp>we should not use lib/ruby/gems/2.1.0
<pjotrp>it may used by other rubies - it is one of the real problems we have
<pjotrp>that is why I would like to inject the HASH
<pjotrp>no sharing!
<davexunit>well, I think the solution for multiple rubies is a bit different
<davexunit>you will want a new profile entirely
<pjotrp>Ah, ok, you are tying this to a profile
<pjotrp>that may work
<davexunit>so you could have a profile with ruby 1.9.3 and one with ruby 2.1.x
<davexunit>and different versions of different gems can be installed.
<pjotrp>as long as you guarantee that no two rubies share gems, I am fine
<davexunit>eventually, we'll have the equivalent of nix-shell that won't require profiles.
<davexunit>pjotrp: I think that will work. only one version of ruby can be installed at a time in a profile. installing a different version of ruby will replace the other.
<pjotrp>that way we rock
<davexunit>for building gems, we will need a ruby-build-system, like we have a python-build-system.
<pjotrp>davexunit: if you can do the next step, I'll have another go tomorrow.
<davexunit>I can try, but I'm primarily focused on another task. if I have time I'll give it a go.
<Steap>davexunit: I tried pypi2guix, here's a simple fix:
<davexunit>Steap: heh, thanks for fixing that silly error.
<davexunit>I'm currently figuring out how to generalize guix import to accept multiple backends.
<Steap>davexunit: I thought of passing a "--nix" or "--pypi" switch
<Steap>seemed like the simplest interface :)
<davexunit>yeah, I should probably just do that...
<davexunit>I was trying "guix import pypi"
<Steap>because different backends may require different number of arguments, etc.
<davexunit>where I delegate based on the first arg, like the main guix script does
<Steap>yes, that also makes sense
<davexunit>I think either way I need to do that
<davexunit>because arg lists need to be parsed differently
<Steap>then it's probably a piece of cake to just call the right backend
<davexunit>I'm factoring out all the nix-specific stuff
<davexunit>to guix/scripts/import/nix.scm
<davexunit>once that works, I'll add the pypi backend.
<davexunit>Steap: are you also working on python stuff today?
<civodul>davexunit: perhaps that could go to (guix snix) or (guix import nix)?
<Steap>There are also a few "bugs" still in pypi2guix
<Steap>I tried packaging "python-novaclient" and it's packaged as "python-python-novaclient"
<davexunit>Steap: yeah, I haven't handled that case yet.
<Steap>also, some packages should probably not be referred to as "python-foo", such as "youtube-dl"
<Steap>but it's harder to detect
<davexunit>well perhaps there should be a flag to control the naming
<davexunit>we can easily detect when a name begins with "python-", but we can also have a flag to disable prepending "python-" for things like youtube-dl
<Steap>yes, maybe
<Steap>but well, it's not what matters the most right now :)
<davexunit>civodul: there's also the UI stuff. I didn't really want to move arg parsing to (guix snix)
<davexunit>would that be okay? right now I have a guix/scripts/import and guix/import directory. separating the UI from the mechanism.
<Steap>I'll try to see whether we can detect the requirements using requirements.txt
<Steap>Not sure if a lot of packages use that
<civodul>davexunit: oh right, makes sense
<davexunit>Steap: a bunch of them do. detecting requirements is tricky business because there's more ways than that to specify dependencies in python packages.
<davexunit>civodul: yeah, so (guix snix) is now (guix import snix)
<davexunit>I need to factor out the newline-rewriting-port stuff.
<inquiryqueue>Aloha! I've got a couple of server things I need to take care of, but then I'm on board for hackathon things today.
<davexunit>I'm about to stop for a bit though. taking the kid to the playground for awhile.
<davexunit>I'll be back in a couple of hours for more hacking.
<Steap>davexunit: yes, but if there is a requirements.txt file, we can use that
<Steap>the goal is to automate as many things as possible, even though we'll still need to dive into the package's internals
<civodul>inquiryqueue: cool, welcome!
<civodul>davexunit: ok!
*davexunit goes afk
<inquiryqueue>civodul: I have some Scheme experience but no experience packaging things for package managers.
<bavier>inquiryqueue: there are plenty of examples to work from :)
<civodul>hey, mthl! :-)
<mthl>hey civodul :)
<civodul>it's quiet here
<civodul>how's the hack?
<bavier>I think I just figured out the subversion test failures caused by new sqlite in python
<civodul>oh cool
<bavier>it wasn't propogating the environment to repository hooks, so things like `ls` from libtool wrappers weren't working correctly
<civodul>non-trivial invetigation i suppose ;-)
<bavier>yes, aggravating
<bavier>is there any way to get the number of current build threads available?
<mark_weaver>bavier: civodul may have a better answer, but guile has (current-processor-count) and (total-processor-count). the first of those might be appropriate here.
<mark_weaver>civodul: regarding my earlier outline here of how grafts could be done, I should have emphasized that if package A has an input B, and B has an input C which is grafted, then B is also implicitly grafted, so the hash substitutions for A must include not only rewrite rules for C, but also for B.
<civodul>hello mark_weaver
<civodul>re grafts, yes, definitely
<civodul>i'm not there yet, because the build-system stuff needs to be adjusted
<civodul>same kind of problem that davexunit was having
<civodul>so currently i'm scratching my head with that
<civodul>and debating with a_e as well ;-)
<mark_weaver>oh, are you together with a_e in person?
<a_e>Hello Mark!
<bavier>I'm just now reading back on the "graft" discussion. Is the idea that we'd be able to apply security updates to packages without changing their hashes, so that they could be used without needed to rebuild packages that depend on them?
<mark_weaver>bavier: no, the hashes of everything would still change, everything would technically still have to be rebuilt, but the rebuilds would mostly only require making copies of the existing build outputs with hashes rewritten.
<bavier>I see
<bavier>yes, that would be useful
<mark_weaver>e.g. if package A depends on core package C, and then C is updated to C2 with a security fix applied, then A2 will be rebuilt from the outputs of A by replacing references to C with equivalent references to C2 (notably in the rpaths used to find shared libraries)
<inquiryqueue>mark_weaver: That makes sense.
*davexunit is back to hacking
<isd>ui gripe with the usb installer: the boot process doesn't give you a prompt until you hit enter; I was waiting for it to "finish booting" for a minute or two before I poked it and discovered it was done.
<isd>Also, I will glady fix this when/if I find the relevant source.
<bavier>isd: thanks for the willingness :)
<mark_weaver>isd: there actually is a prompt before you hit enter, but then more kernel messages are printed _after_ the prompt, so it gets lost. I agree it would be nice to improve this somehow :)
<civodul>+1 :-)
<isd>mark_weaver: might make sense to actually start a login prompt, and just put a sufficiently descriptive message in /etc/issue
<civodul>that's what happens, but other things are printed after the prompt is up
<civodul>so the prompt on tty1 ends up being hidden behind those
***inquiryqueue is now known as keptagon
<isd>Anyway, I'll poke around and see what I can figure out.
<isd>Also: is there any work on an iso, rather than just a usb?
<civodul>isd: currently not
<civodul>it didn't seem very useful, actually
<mark_weaver>the other thing we need is support for booting on UEFI systems.
<mark_weaver>which I guess requires changes to the grub configuration and the creation of an EFI boot partition.
<mark_weaver>(some part of grub would be in that boot partition)
<civodul>yeah, i don't know exactly
<isd>civodul: I have a handful of cases where an iso would be useful
<isd>anyway, going to grab lunch, be back in a bit.
<Steap>davexunit: I've got a working POC that gathers requirements from requirements.txt and test-requirements.txt
<Steap>I'll try to add it to guix import once you've merged your work on PyPI
<davexunit>Steap: awesome. in the meantime you could open a merge request against my pypi2guix repo?
<davexunit>I'm just getting back to writing code. have a fussy 4 year old in the house.
<mark_weaver>hehe :)
<davexunit>I guess I should install nix to make sure that I'm not breaking the nix importer...
<Steap>davexunit: I'm having a bit of trouble actually writing the inputs into the package definition
<Steap>but civodul told me not to worry about that since the code might change a bit
<Steap>so all I really have is a function that, given a tarball, outputs the potential dependencies :)
<davexunit>that's just fine :)
<davexunit>the code will likely change, yeah.
<davexunit>I'm still factoring out the nix specific stuff.
<Steap>There's no hurry anyway :)
<davexunit>I want to have something to show by the end of the day
<davexunit>I stubbed the nixpkgs->guix-package procedure for testing purposes :)
<Steap>when exactly is the end of the day for you ? :p
<davexunit>I'm on the east coast USA, it's only 2:42PM here.
<Steap>well, plenty of time
<keptagon>The manual seems to lack instructions for setting up just the package manager without the GNU distribution.
<keptagon>I'm going to go look at documentation on github.
<davexunit>keptagon: it has those instructions
<keptagon>davexunit: What section are they in?
<davexunit>guix isn't on github unless someone hosts a mirror there
<davexunit>that will allow you to build and install guix on your system
<isd>keptagon: the git repo is at git://
<keptagon>I read that page. The documentation lists requirements, then 2.1 jumps to setting up the daemon with the assumption that things are already installed.
<davexunit>"The build procedure for Guix is the same as for other GNU software, and is not covered here. Please see the files README and INSTALL in the Guix source tree for additional details."
<keptagon>Ok, thanks!
<davexunit>if you have the prerequisites, you can run: autoreconf -vif, ./configure, make
<davexunit>keptagon: good luck! let us know if you have other problems.
<keptagon>It might be useful to have the #Installation section link to the actual download page rather than the top level page.
<isd>So I'm doing a usb install, and realized I didn't do the -L when formatting the drive - I'd like to use labels, do I need to do anything to undo the cow filesystem setup or can I safely just umount and try again?
<davexunit>isd: when I screwed up installs, I would just rebuild the filesystem on the partition I was installing to and try again.
<isd>Yeah that was the plan - I just did a deco stop before unmounting, hopefully that is the right thing.
<davexunit>I haven't actually used the OS in awhile. I'm currently running guix atop debian.
<davexunit>I need a spare computer to use for installations.
<isd>Seems to still think it's busy -- I'll just reboot
<isd>davexunit: I'm using a vm
<isd>Which is actually makes it a little annoying to do a usb install.
<isd>but I'm managing
<davexunit>thanks for hanging in there
<isd>the bootloader on the installer is intermittently hanging at "Welcome to GRUB" - not seeing a pattern to it yet.
<isd>Not necessarily a guix bug, like I said usb installs in vms are annoying.
<davexunit>something I've been wondering after packaging a bunch of python libs: why isn't python-setuptools an implicit input to the python build system? I think it ought to be.
<ecelis>isd: what kind of VM are you running guix into? qemu?
<civodul>davexunit: not sure, Steap would know, for sure :-)
<isd>davexunit: it didn't always exist, that's probably why
<isd>ecelis: yes, via libvirt.
<ecelis>I see, I'm trying to install the usb image into VirtualBox
<ecelis>has anyone have done it before? any tips or tricks I should know?
<bavier>davexunit: there are a number of python packages that don't need python-setuptools
<isd>Okay, it's not actually hanging, it's just sitting there for a really long time.
<davexunit>bavier: a lot of them do, though.
<isd>I'm trying to set up the package manager on my existing system in parallel, and make is giving me an error about a missing requirement called "dot" which is not mentioned in the readme. I don't know what that is?
<mark_weaver>isd: it's part of the 'graphviz' package
<mark_weaver>isd: it's just for rendering a sample dependency graph for the manual. in the past, I've sometimes just used 'touch' to create the file it's trying to build using 'dot', and it only means you have a missing graph in your manual.
<isd>That should probably be documented.
<isd>It should also be something you can disable via an option to configure.
<mark_weaver>well, you don't need it unless you're building from git. the tarballs include it pre-generated.
<isd>Ah, you're right it does mention graphviz
<isd>would still be nice to be able to disable it.
<mark_weaver>dunno, it only affects developers, and we can't generate the manual properly without it.
<isd>I suppose.
<isd>So... it would be nice if I had access to something like wget or curl in the install environment
<davexunit>isd: you can install packages in the install env
<isd>good to know
<davexunit>you can also tweak the install config file to add packages that you would like to have
<bavier>hmmm... no python-pygtk
<civodul>you mean, "not yet"!
<bavier>that right!
*davexunit has a working 'guix import pypi' :)
<bavier>davexunit: I should probably try that before I do pycairo and pygtk by hand ;)
<davexunit>it would probably be more efficient to write them by hand, for now.
<davexunit>unless those libraries have tons of other python dependencies
<civodul>heheh, cool still
<davexunit>then the time wasted with boilerplate starts to add up.
<fdgsfdgfd>civodul: I'm getting "no code for module (ice-9 readline)" when trying to build dmd-0.2
<civodul>hey, fdgsfdgfd
<civodul>long time no see ;-)
<davexunit>I'll have patches to send to the list shortly.
<civodul>fdgsfdgfd: dmd doesn't depend on readline AFAIL
<davexunit>tidying up, adding command line options, etc.
<civodul>what's the context exactly?
<civodul>davexunit: neat!
<civodul>you've been more productive than me :-)
<fdgsfdgfd>civodul: I'll paste the backgrace in a second
<mark_weaver>fdgsfdgfd: do you have a .guile that loads readline?
<civodul>davexunit: i'm looking at adding an "intermediate representation", where build systems first "lower" packages to "makers", which are then compiled to derivations
<civodul>fdgsfdgfd: oops indeed, it actually depends on readline, dunno why
<civodul>the fix is to build Guile with Readline support
<davexunit>civodul: that sounds good. I was wishing that there was a form between packages and derivations.
<mark_weaver>looks like there's no good reason for the hard dependency on readline. dmd just activates readline when run with --socket from a terminal.
<mark_weaver>fdgsfdgfd: the dependency could be easily removed by commenting out two lines in dmd.scm: the #:use-modules (ice-9 readline) and the call to (activate-readline) further down.
<fdgsfdgfd>gonna try that
<fdgsfdgfd>mark_weaver: thanks, it worked
<mark_weaver>fdgsfdgfd: you're welcome!
<mark_weaver>we might consider simply removing that automatic readline activation from dmd. users can activate it themselves if they want it.
*mark_weaver goes afk for a while
<isd>So, I'm doing the install, and when I try to run guix system init, I get this error message:
<isd>my config.scm looks like:
<isd>I don't know what to make of that error. any thoughts?
***isd_ is now known as isd
<ecelis>I booted the guix usb image in VirtualBox, now I'm stuck at editing config.scm
<ecelis>to make the install
<ecelis>neither nano or sile work in my system, since my seta key and left CTRL are dead
<ecelis>VirtualBox takes right CTRL key for his own purposes
<ecelis>I'll edit the file using sed and then install vi
<ecelis>it will be nice to have vi or ed at least available in the intaller image
<isd>ecelis: that's what I said ~15 min ago.
<isd>you can install it
<isd>guix package -i vim
<ecelis>yes, thank you, but I was thinking more in terms of going right to the install process
<ecelis>sed works just fine
<isd>I see feh on the list of things to package -- is that still up for grabs? it feels like a nice getting-started task
<davexunit>isd: I'm pretty sure it is. run 'guix package -A feh' to make sure
<isd>I did, nothing there.
<davexunit>go for it :)
<alezost>isd: yes it is definitely in the wishing list: I've packaged giblib a couple of days ago which should be a dependency for feh
<fdgsfdgfd>what should I put into the dmd config? should it be a list of service defintions?
<fdgsfdgfd>civodul: I've created an empty file ~/.dmd/dmdconf.scm. Now, it's complaining about missing ~/.dmd.d/run. Am I doing it wrong?
***Basstard1 is now known as Basstard`
<paroneayea>hello #guix
<paroneayea>how's the sprint goin?
<isd>So feh is MIT licensed (this thing: -- I don't see anything by that name in the licenses module, is x11 what I want or is that not exactly the same one?
<davexuni`>isd: expat is the name
<davexuni`>commonly referred to as MIT
<isd>davexunit: okay, thanks.
<alezost>isd: AFAIK feh was written by the same guy who wrote scrot and giblib and the license is probably the same. If so, it should be x11-style I think; see this thread:
<civodul>uh, yet another one:
<isd>So, another question: feh doesn't have a configure script, but instead you pass options like --prefix= as PREFIX= to make -- I can tell it not to run the configure phase, and I can pass arguments to make via one of the keyword arguments, but what should I specify as the prefix?
<civodul>davexunit, isd: or i think it's "x11"
<civodul>isd: you can use #:make-flags for that, and also remove the 'configure' phase
<civodul>see lout.scm, for example
<davexunit>civodul: oh no.
<civodul>oh you're right, it's "expat"
<isd>civodul: yeah, I got that, just wasn't sure what to actually pass in -- PREFIX=what?
<isd>civodul: lout doesn't seem to actually use that argument - it's also impressively complex
<civodul>isd: something like: #:make-flags '(list (string-append "PREFIX=" (assoc-ref %outputs "out")))
<civodul>yeah, maybe not the best example
***fefe` is now known as fefe
<isd>civodul: Is there an api reference somewhere that documents things like %outputs ?
<civodul>isd: i'm afraid the build-side API isn't very well documented :-/
<isd>civodul: is there a place where it should be documented that I can add to?
<alezost>civodul: so should the licenses for scrot and giblib be changed to expat as well?
*davexunit sent patch to the list
<davexunit>I'm sure there are a multitude of small issues to fix. :)
<davexunit>in the meantime, time to research a ruby build system.
<a_e>alezost: For the packages with additional clauses, I think it should remain x11-style.
<alezost>a_e: feh, scrot and giblib have the same COPYING (which was attached in, so I just want to be sure should it be "expat" or "x11-style"
<civodul>alezost: yes, perhaps it should be changed to "expat"
<civodul>alezost: could you double-check against ?
<civodul>davexunit: thanks for the nice patch! :-)
<davexunit>civodul: :)
<davexunit>heh, I should add tests, though it will be hard to test this properly because it uses the network.
<davexunit>I could stub that, though, with a bit of effort.
<isd>I'm getting a cryptic error message that sounds like it's happening within the bowels of a macro:
<alezost>civodul: it's almost the same except a little difference in the second paragraph:
<isd>One thing that wasn't clear to me from the docs: do things like #:make-flags go inside of the build-system clause, or are all of them outside in an arguments clause?
<isd>Any thoughts?
<civodul>alezost: hmm ok, perhaps i'd leave it x11-style then
<alezost>isd: arguments should look like this: (arguments '(#:phases ...)) not (arguments #:phases ...)
<isd>alezost: okay, thanks.
<alezost>civodul: ok, then feh should also be x11-style (as it has the same COPYING)
<civodul>alezost: yes
<civodul>isd: things like #:make-flags go in the arguments clause, yes
<civodul>they are arguments to the build system
<alezost>isd: change the license to x11-style please :)
<isd>alezost: noted.
<isd>I don't suppose there's documentation somewhere about how to specify the hash? there's the example in the manual, but it doesn't seem to like my idea of base32.
<alezost>isd: Indeed it shouldn't be (sha1 (base16) ...). It should be (sha256 (base 32) ...)
<isd>alezost: yeah, I assumed that wouldn't work but was just getting started -- I changed it to 256/32, and converted the string, but it's giving me errors about invalid characters (things like the letter o)
<isd>wait, I think I figured it out
<davexunit>could someone test if this works for them?
<davexunit>./pre-inst-env guix download
<davexunit>download fails for me