IRC channel logs


back to list of logs

*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>civodul: I'll check out union-build
<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>is this on the whole Guix system?
<davexunit>haven't tested there yet.
<davexunit>noticed it on my debian system.
<davexunit>not sure if I should expect it to work
<civodul>it should work, but make sure to "killall pulseaudio" before starting it
<civodul>normally, the program will start pulseaudio by itself
<civodul>or via dbus-launch, i forgot
<davexunit>oh cool
<davexunit>I'll try that, thanks.
*davexunit tries to figure out union-build
<davexunit>looks like something I call in builder code
<civodul>yes, it's build code
<civodul>an example is 'gcc-toolchain', in commencement.scm
<davexunit>I'm not sure where the output directory would be, in my case.
<davexunit>yeah, I'm reading that.
<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?
<davexunit>guix is so neat.
<davexunit>always finds new ways to impress me.
<civodul>i think you actually already pushed the Ruby update :-)
<civodul>but that's fine anyway
<davexunit>civodul: andreas said it looked okay
<davexunit>so I figured it was safe
<civodul>yes, it's definitely safe, so np!
<civodul>and HACKING says it's fine anyway :-)
*civodul -> zZz
<civodul>good night/day!
<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>wow already at 0.8
<zacts>nice progress!
<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> #include "k/init.c"
<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?
<nkar>like C_INCLUDE_PATH
<nkar>(I'm just guessing...)
<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.
<davexunit>ah, cool, though.
<davexunit>that's progress.
<davexunit>I'm very excited for an ARM port.
<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
<jmd>ijp: Mine isn't
<davexunit>is it hardcoded to use /tmp?
<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.
<jmd>ijp: The community.
<ijp>which community
<davexunit>jmd: I was wishing for that today.
<davexunit>I had to chown everything first
<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.
<ijp>that's what I said
<jmd>ijp: Then we are in agreement.
<jmd>We need to have some guideline for projects which don't do "releases".
<davexunit>1) pester them to 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.
<davexunit>users, too, I think.
<davexunit>users benefit from a supported version.
<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>it's a big IF
<ijp>at least 72pt
<jmd>ijp: Which if?
<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.
<mark_weaver>if sounds like you haven't done the research yet.
<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.
*mark_weaver goes afk