*davexunit sends patch to update ruby *davexunit tries to figure out how to union SDL libs so guile-sdl will build <civodul>davexunit: you can use 'union-build' for that <civodul>if it's a common use case, perhaps make it a package? <davexunit>I need to resubmit my minetest package, too. my patch for guix compatibility was finally accepted upstream. <davexunit>the only thing I'm not sure about with that patch set is OpenAL, I get no sound in minetest because OpenAL can't connect to pulse <civodul>it should work, but make sure to "killall pulseaudio" before starting it <civodul>normally, the program will start pulseaudio by itself *davexunit tries to figure out union-build <civodul>an example is 'gcc-toolchain', in commencement.scm <davexunit>I'm not sure where the output directory would be, in my case. <civodul>if you make a special package, say 'sdl-union', then the output directory would be the "out" of that package <davexunit>so, would I essentially be creating a derivation that's a union of the SDL packages, and then passing that as an input to guile-sdl? <civodul>i think you actually already pushed the Ruby update :-) <civodul>and HACKING says it's fine anyway :-) <davexunit>of course I forget to mention the variable name in the commit log! gahhhh <davexunit>from now on, I will always wait for civodul's approval to avoid more embarrassing mistakes. <zacts>I should add my shell to guix ***Sveta is now known as Svetlana
*davexunit continues to struggle with guile-sdl <davexunit>sdl.c:183:20: fatal error: k/init.c: No such file or directory <davexunit>ugh. that's one of guile-sdl's source files. why can't it be found? <nkar>davexunit: maybe it needs some env variable, no? <davexunit>I haven't been able to set the right magic env var <davexunit>it should just work, because it's in the source tree <davexunit>I don't know why it cannot include a file via a relative path like that <nkar>perhaps there are packages which also rely on header files and you can check how things are done there <davexunit>someone recently packaged this library for nix and didn't have to do anything strange to get it to build. <davexunit>compiling guix takes a lot longer than it used to. <jmd>I'm thinking of using Guix to build for Arm. Would hydra have the capacity to take an extra architecture? <davexunit>jmd: not sure, but I think there's other problems to overcome before worrying about hydra. <davexunit>that said, I really want an arm port since I'll be getting a Novena in a few months. <jmd>Oh I haven't found any fundamental ones yet. What problems do you anticipate? <davexunit>there's a thread on the ML about the issues, I don't recall what they wre. <davexunit>I think there was an issue around the bootloader <jmd>Oh. I haven't got as far as booting. <jmd>Just cross-compiling things right now. <jmd>I really wish we could get the daemon to build somewhere other than /tmp <jmd>I've been building libreoffice all day, and I think it is about to run out of space on /tmp <ijp>and /tmp means ram these days <davexunit>I feel like there has to be an option to change that <ijp>jmd: every system is a unique snowflake, but tmpfs is really common <jmd>davexunit: I think you can set a variable, but of course one has to stop the deamon and restart it. <jmd>ijp: I thought that was a discredited practice these days. <davexunit>well, once the daemon is rewritten in guile, you'll be able to attach a REPL and set! a variable :) <ijp>jmd: discredited by whom? <jmd>Also I wish that when building with -K the daemon would change the ownership to me whenthe build fails. <ijp>there is literally nothing ever conceived that I can't find two people who disagree about it <jmd>ijp: You can always find someone who disagrees if you look hard enough. <jmd>ijp: Then we are in agreement. <jmd>We need to have some guideline for projects which don't do "releases". <davexunit>I pester the Tox folks about it from time to time. because I want libtoxcore in guix, but they won't make official release tarballs. <jmd>In defence of them. I understand their point of view. <davexunit>I don't understand it. maybe you can explain. <jmd>I think there is little need for "releases" today. It is largely a marketing device used by proprietary software companies. <davexunit>a release gives developers, package maintainers, etc. something to target. <jmd>I take that point. But then the "release" is primarily for the benefit of maintainers/developers not users. <jmd>Every commit can be a "release". (and legally speaking it is). <davexunit>it is not in the user's best interest to be told to run master HEAD <davexunit>and then there's issues of compatibility between versions <jmd>Well it might be. It depends on commit policy. <davexunit>and a release is not just the source code as-is <jmd>Admittedly, git is not the best tool to use, if you want to run a project like that. <jmd>I think it is fine, if a project wants to say that "commit X" we consider stable - all others at your own risk. But I also think it good (perhaps better) if a project says that ALL commits to the repository are an improvement and self consistent. <jmd>Professional tools such as aegis can help with such management. <ijp>if ALL commits to a repository are an improvement and self consisent <jmd>ijp: Oh right. That's why I said a tool such as Aegis would be usefull for such projects. <mark_weaver>jmd: I haven't read the whole backlog, but what variant of ARM are you targetting? I was thinking of doing the same as Debian's armhf port. <jmd>mark_weaver: Well I have a thing which is an arm7 <jmd>I dunno what armhf is, but I think it is the same. <mark_weaver>jmd: I haven't done the necessary research yet, but I'm also fairly clueless here, but I can tell you that the performance on ARM depends crucially on which set of features you assume when compiling the code. <jmd>I do research by experimentation. <mark_weaver>that sounds like a poor way to go about the ARM port. <mark_weaver>there's a good chance you'll end up with something that works but is much slower than it could be. <jmd>You may well be right. But that will be better than something which doesn't work at all. <mark_weaver>well, my Novena should arrive in about a month, and then I'll look into it.