<efraim>I'm working on packaging fossil, and the default configure flags include --enable-fast-install that causes configure to fail. can I remove that one specifically or do I need to specify all the other flags?
<mark_weaver>efraim: specifying the other flags won't work, because gnu-build-system will add it to the flags you specified. in cases like this, we normally replace the configure phase.
<mark_weaver>for example, see the 'bitlbee' package in messaging.scm
<egrep>Well, I decided to see if I could install guix on my Macbook Pro... GRUB shows up, it starts out fine, it logs in, everything seems to be going great, and then the apple keyboard doesn't work. Best I can think of right now is an external keyboard, but I don't have one with me at the moment... any other options?
<rekado->egrep: other people using Apple hardware reported something like that. It may be that a particular kernel module needs to be loaded to make it work.
<phant0mas>normally in debian glibc PAGE_COPY_FWD_MAYBE was expanding to nothing
<phant0mas>but because of a mistake, commit 779a2514 ended up to the master branch
<phant0mas>which defined PAGE_COPY_THRESHOLD, which when defined would make glibc use a different PAGE_COPY_FWD_MAYBE
<phant0mas>that's why perl was working with debian's glibc but not ours
<mark_weaver>if the patch is from upstream and it fixes perl, that's good enough for me, without having to understand the details.
<mark_weaver>although the idea that this is "disabling a fix", when that "fix" was actually a mistake, seems like a strange way to say it.
<mark_weaver>but since that's the way it's described in the upstream commit, and I don't have time to look more closely right now, it's fine. I don't want to distract you from the more important work on this :)
<phant0mas>and I have almost ready the commencement patches :-)
<mechanical>I ask because there doesn't seem to be a GuixSD port for mips64el. Would you be able to tell me if that's true or if I merely haven't looked well enough? All of the mips64el discussion on the mailing list seems to be for Guix and not GuixSD from what I recall.
<davexunit>mechanical: that's correct. we have package builds for mips64el, but the distro cannot be used at this time.
<davexunit>I only know of 1 person that uses guix on mips64el, so it hasn't exactly been high priority
<mark_weaver>mechanical: I should clarify that if Guix were ported to BSD, it would only be to its kernel. Guix always uses its own toolchain and userland for everything above the kernel level, and that will always be GNU based.
<daviid>off topic quizz: can't connect to irc.gnome.org since yesterday, no matter what :) [I'm following #clutter], any idea tip? I can not find anything on the web and I don't have a clue why and how to debbug ...
<mark_weaver>mechanical: to clarify further: guix always builds everything in isolated build environments that include only software from guix. at the beginning, that starts with bootstrap binaries provided by us.
<mark_weaver>ah, okay. well, the main annoyance is the fact that it requires non-upstreamable patches to the kernel and X.
<mark_weaver>and also, last I tried (admittedly a while ago), I had problems getting linux-libre to work on the YeeLoong when compiled with newer versions of GCC, and of course it would have to be a kernel specific to a particular YeeLoong model.
<mark_weaver>and also the X server required some ugly patches that could never be upstreamed and makes it specific to the YeeLoong.
<mark_weaver>and the last time I tried to port those old patches to recent versions of Xorg, I also remember it being non-obvious.
<mark_weaver>to be honest, I've mostly stopped using my YeeLoong now that I've switched to the Libreboot X200 (and the X60 before that), so I've lost motivation to do much more than prevent the mips port from regressing.
<mark_weaver>but if you're interested in picking that up, that would be most welcome!
<mechanical>So what I'm hearing is the yeeloong port needs someone to get a working kernel and X running for it and to keep it updated?
<mark_weaver>also, the part of "guix system ..." that sets up grub would either have to be generalized to deal with pmon, or better yet, get grub working on the YeeLoong.
<mechanical>I think GNewSense may be keeping the kernel and X for those platforms updated, so I should look into that.
<mechanical>The issue is that none are very good, but gNewSense is probably the best available.
<mark_weaver>and then use our mips binary-install option, since it would be hard to compile Guix from source code on gNewSense (too old)
<mark_weaver>and then you'd basically just be using the kernel and X from gNewSense, and everything else from Guix, and then maybe start working on getting our xorg-server package from Guix working on the Yeeloong.
<mechanical>Okay. I'll go afk for a while and come back when I have that done. Thank you for helping to walk me through this. I'm not very familiar with Guix yet.
<mark_weaver>codemac: okay, I have a few minutes now. I'm not sure I understand your question though. what we have is something called 'ld-wrapper' which means that the 'ld' program in the build environment is actually a script that searches for libraries on the link command line and inserts options to set the rpaths appropriately.
<codemac>mark_weaver: the go build compiles it's own c compiler, linker, and assembler, and then uses those. they have custom rpath options that I set in an environment variable
<mark_weaver>you can see the script itself (before substitutions) in gnu/packages/ld-wrapper.in
<mark_weaver>codemac: okay, we'll probably need to make something like ld-wrapper for their linker.
<codemac>mark_weaver: and the source code for those (6c, 6l, 6g) reference `/lib/ld-linux.so` directly.
<mark_weaver>because the same issue will arise whenever you build another package using go.
<codemac>I just called substitute* on the C files where they're referenced