<mark_weaver>hmm, so bison is available to build the first bash during the early bootstrap? ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | things to package: http://libreplanet.org/wiki/Group:Guix/Wishlist | hackathon TODAY: http://libreplanet.org/wiki/Group:Guix/Hackathon-09-2014'
<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 :/ <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. <civodul>pjotrp: guix gc --references $(guix build emacs) <a_e>I am still busy with my household chores, but will join in the afternoon. <a_e>Pjotrp: Nice you got it running! <pjotrp>I am trying to learn emacs, org mode, guile, lisp and guix at the same time. Target is a Ruby package. <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>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>Calinou: translations of the messages in general you mean? *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 <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>however, there were issues with upgrading parted <civodul>mark_weaver and i reported issues on bug-parted a while back <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>@ build-succeeded /gnu/store/y7b1wvjvc7hvi7ihvs9mcc757yqr3qg8-ruby-2.1.2.drv - <pjotrp>/gnu/store/yb9z2y7ndzra9r3x7l3020zjpds43yyc-ruby-2.1.2 <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>geiser lacks context. How do I start the equivalent of ./pre-inst-env guil <bavier>pjotrp: I've also been meaning to get more acquainted with geiser <pjotrp>found this (setq-default geiser-guile-load-path '( ... "~/src/guix" ...)) <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! <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' <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 <civodul>pjotrp: if you look at the videos on gnu.org/s/guix, you'll find coding sessions that might give you a hint <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>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 <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 <pjotrp>civodul: I should have tried that! <davexunit>pjotrp: now to package the ruby gems in guix! <davexunit>yes indeed. I anticipate it being a bit easier than with pypi <davexunit>having trouble applying this patch with git am <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>but won't update ~/.guix-profile/bin <pjotrp>testing in a terminal without the path set :( <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' <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 <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. <pjotrp>needed to patch Makefile.in for /bin/sh <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>(and all of the 1000 libraries it depends on) <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? <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: nitpick: the commit message should read "gnu: Add Ruby." <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 <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>next step is to get bundler working, I suppose <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>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 <davexunit>a-ha. so guix has a facility for dealing with these native search paths. <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>there's something called "native-search-paths" <Steap>davexunit: are you working on integrating your PyPI script into "guix import" ? <davexunit>well, I will be. right now I'm talking about ruby. :) <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 <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 <davexunit>well, I think the solution for multiple rubies is a bit different <pjotrp>Ah, ok, you are tying this to a profile <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. <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. <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 :) <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 <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>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" <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>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 <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 <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 :) <bavier>I think I just figured out the subversion test failures caused by new sqlite in python <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>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>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 <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. <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) *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 :) <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>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. <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. <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>I'm still factoring out the nix specific stuff. <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. <keptagon>The gnu.org 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>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://git.savannah.gnu.org/guix.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." <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 gnu.org/software/guix 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>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. <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 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>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 <davexunit>you can also tweak the install config file to add packages that you would like to have *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 <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 <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>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. <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>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>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. <ecelis>yes, thank you, but I was thinking more in terms of going right to the install process <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. <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`
<isd>So feh is MIT licensed (this thing: http://mit-license.org/) -- 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? <isd>davexunit: okay, thanks. <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 <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"))) ***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. <civodul>alezost: yes, perhaps it should be changed to "expat" <civodul>davexunit: thanks for the nice patch! :-) <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>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? <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>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>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