<toothbrush0>argh, this is rather frustrating: there's a package which depends on sdl-image, which builds fine outside of Guix, but when i try to package it using Guix, it fails on configure, saying that SDL_image.h does not exist
<toothbrush0>anyone know where i can start to figure out what the problem is?
<remi`bd>toothbrush0: how are you compiling this specific packages that depends on SDL_image ?
<toothbrush0>it's using the Haskell build system, but the configure step fails
<toothbrush0>i think i've found something, but i'm not sure, i'll explain
<toothbrush0>on my host os (Arch) it works when i install sdl and sdl_image, which both place their files in /usr/include/SDL
<toothbrush0>but in Guix of course the files are spread out in the store
<toothbrush0>but the configure stage pkg-config comes up with SDL_LIBS=-L/gnu/store/p5ksjfcs8pa87hnpfliqhlpz7dvgxvpp-sdl-1.2.15/lib -lSDL_image
<toothbrush0>rekado: yeah, i thought of that idea indeed, but i'm worried a patch will be accepted "by accident", since we can't expect everyone to keep a taboo-list in mind of which are core libraries
<civodul>we could add (properties '(#:haskell-platform? #t)) to those packages?
<toothbrush0>and i guess we'll just have to hope that before submitting patches, people will make an effort to build all dependent packages. because that's really the risk we're guarding against: non forward-compatibility in dependency tree roots.
<toothbrush0>bavier: we should actually, probably, use Stackage as a source, instead of Hackage.
<iyzsong>a build of debian (and archlinux) source package can produce multiple packages, they have different meta data (name, description, depends). and I think the ability to having different meta data for different outputs useful for us too.
<toothbrush0>So when i'm using Magit, i like to use rebase to reorder patches, but really frequently, it doesn't manage to apply a small "fixup" patch right after the patch that introduces a given term. Anyone have tips for these situations? I usually resort to dropping the fixup patch, and manually editing the original patch, which sucks.
<mark_weaver>recently, someone here on channel (karhunguixi?) ran into that issue, where a 'module-import-compiled' store item had zero length, and had to be manually removed in order to get things working again.
<davexunit>my stick has the same number of buttons, a joystick, and the same exact usb port.
<cehteh>forstner bits dont work well in thin material and you need some skill for them, good people can easily make big freehand holes in wood, but if it tears out or you tilt it accidentally it gets very hot
<davexunit>I know this is off-topic from guix... sorry about that.
<cehteh>hehe you may come over to ##woodworking . .not exactly the place for that but we talk there sometimes about such stuff too
<davexunit>I don't want to derail another IRC channel ;)
<davexunit>I learned to solder so I could assemble my arcade stick. since I'm good at programming it was easy to hack the firmware sources to do what I wanted. but I've completely failed trying to build an enclosure.
<francis7-awol>colud be RYF, with a lot of work. I'm not focussing on that at the moment. My priority now is adding every other rk3288 laptop to libreboot from coreboot (there are many, mostly in google's branch of coreboot, which need upstreaming in coreboot)