***codemac` is now known as codemac
***ruukasu is now known as ploopkazoo
<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. <rekado->I'm sorry I don't remember the details. <egrep>rekado-: It's okay. I'll remain hopeful. :) <davexunit>has anyone tried using our newly added ansible package? <davexunit>that's pretty exciting, from a guix migration standpoint. <bavier>any reason we didn't name the package just "ansible" <bavier>ACTION feels silly asking now, having not reviewed the patch <bavier>should maybe also have been put somewhere other than python.scm <davexunit>bavier: feeling motivated to write the patch? :) <bavier>I have a bunch of my own patches that need to be cleaned up <bavier>so I'd be glad to let others take the job <alezost>ACTION doesn't even understand what "ansible" is <bavier>ACTION just recently learned about ansible <yenda>I added ansible in python because someone told me in the patch that python stuff goes in python <yenda>I can take it out later today <bavier>yenda: the "python-" prefix is meant for packages whose primary purpose is to provide python modules <bavier>for a complete tool/application like ansible the prefix may be left off. <bavier>and placed in any suitable gnu/packages/*.scm <bavier>my apologies for not looking at the ML patch <yenda>so admin.scm ? ansible.scm ? <bavier>yenda: admin.scm seems appropriate to me <rekado_>about the r-build-system patches: I'll be on vacation from Wednesday on, so I'll be late to apply any changes if requested. <yenda>shoudln't all .go files be gitignored ? <Steap>yenda: git status does not show them <yenda>after a make I always get some untracked .go files <amz3>maybe you need to add it to some global .gitignore file <Steap>yenda: "some" ? As in "not all of the .go files" ? <Steap>yenda: there is "*.go" in .gitignore <yenda>only thos who are of the for *.go.* <yenda>I don't know, they appear when I change a file and "make" guix <mark_weaver>the compiler writes the .go files as *.go.* initially, and doesn't rename them until they are completely written. <mark_weaver>that's important so that another process doesn't try to read an incomplete .go file <mark_weaver>if the compiler dies for some reason (e.g. if killed), then the *.go.* gets left <Jynxy>so it has come to my attention I am not allowed to modify my config.scm without A. upgrading packages, and B. using ntpd/mdns <Jynxy>does this pass as secure these days? <Jynxy>me thinks anyone who used this distro <Jynxy>is as stupid as the people who designed it <Jynxy>anyone care to defend the atrocity that is mdns <Jynxy>or why you would have a modifiable config screen where.... <mark_weaver>Jynxy: the statements you make above are false, but your attitude makes me not want to waste time on you. go away. <yenda>why "they" ? you think he's not alone in his head ? <yenda>Is there a particular sorting criteria for the packages in the .scm files ? <davexunit>yenda: I don't know their gender so I used "they" <bavier>I did at one point sort the packages in perl.scm alphabetically <Steap>yenda: I'd love to do this alphabetically <bavier>many others get new packages appended at the end <bavier>sometimes new packages are placed next to related packages <bavier>I'm under the impression that geiser makes searching for definitions much easier, in which case the order isn't as important <yenda>for nomw I just grep grep grep <bavier>but I've not yet figured out how to use geiser effectively <bavier>yenda: 'guix package --show=...' can also be helpful <davexunit>ordering package definitions alphabetically in files doesn't sound useful <yenda>guix edit yourpackage is better <yenda>so I'll make a patch to put ansible into admin.scm <bavier>I forgot about the recent 'guix edit' <yenda>it's wierd ln -s ~/guix ~/.config/guix/latest tells me the symlink already exists <yenda>yet I don't have access to my local packages <davexunit>yenda: that means a symlink is there, not that it's the same symlink <davexunit>yes, you have to delete the directory first before you can create a new file with the same name. <yenda>patch submitted, have to go bye. ***davi_ is now known as Guest71341
<phant0mas>mark_weaver: glibc-hurd-disable-fix.patch sounds okay? <mark_weaver>phant0mas: it would be nice to know what fix is being disabled, but unfortunately I can't tell from youpi's commit message <phant0mas>it disables the fix from commit 779a2514a61d103a9a1479478ad15d2ca9478d6c from glibc-hurd <mark_weaver>don't forget to add it to gnu-system.am and the glibc/hurd package. <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>There's nothing in particular stopping GUIX from being run on any UNIX-like system, such as a BSD, is there? <davexunit>mechanical: there's no reason guix couldn't run on BSD, someone would just need to do the port. <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. <mechanical>Would you mind telling me the proper venue I should go to help with that, davexunit? <davexunit>ah yes, that's a very important detail, mark_weaver <davexunit>mechanical: here is good. also the guix-devel mailing list for long running discussion <codemac>mark_weaver: hi! I got go to fully build (but fails some tests) :) now I want to package it non-stupid. <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>so each set of bootstrap binaries are for an architecture/linux combination, by necessity <mark_weaver>and they are initially created by cross-compilation, and we have tools to do that. <mark_weaver>see the "porting" section of the Guix manual. you'd have to start by cross-compiling from an existing Guix installation on Linux. <mechanical>I'm almost done with the manual. Thank you for your help. <mark_weaver>my main concern is that it might involve a lot of patching all over the tree to fix things. I'm not entirely sure we want to take on that maintenance burden. <mark_weaver>our goal is primarily to build the GNU system, not to be portable to every system. <mechanical>I want to clarify that the only reason I was concerned with BSD was the absence of GuixSD on mips64el. I'm going to try and pursue porting GuixSD to mips64el, rather than to BSD. <mechanical>Would you happen to know the other fellow who is concerned with GuixSD on mips64el? <mechanical>Oh, well okay then. How is the progress of GuixSD on mips64el and how can I help? <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>Well, I'll start trying to help soon. Thank you. <bavier>mark_weaver: did you see my question earlier about the HummingBoard? <mark_weaver>so right now, I'm using linux-libre-3.14.x, with the loongson-community patches, compiled with gcc 4.7.x <mark_weaver>and that mostly works, with one annoying issue: after hibernation, the internal wireless is no longer usable. <mark_weaver>bavier: yes, thanks, I need to look at it more closely. <mark_weaver>the lack of SATA is suboptimal, but maybe it would be okay to use a networked filesystem. <bavier>the model I was looking at has M.2 <mark_weaver>but the biggest question I have is: does it work with a fully-free initialization firmware? <bavier>the iMX6 SOM's have a "security" core <bavier>looks like they come in sizes up to 512GB <mark_weaver>we could make do with 1/10 of that. it's disk bandwidth and latency that I'm worried about. <mark_weaver>mechanical: GNewSense has ancient software, whereas we have cutting edge software. <mark_weaver>and it would probably cause problems to use a vastly different version of X on our mips port. <mark_weaver>since there are so many other packages that might be affected by it. <mark_weaver>really, we need the latest Xorg working on the Yeeloong. <mark_weaver>mechanical: the first step would be to install Guix on top of another GNU/Linux distro that works on the Yeeloong. <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. <codemac>mark_weaver: will gnu-build-system detect random c code with ld-linux-x86-64.so and rewrite them? <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 <mark_weaver>but we'll also need something more general to handle when another package compiles something in go and links with a library from some other package. <codemac>There's a few tests that fail right now (depending on /bin/sh and crap) but that's because I'm not using gnu-build-system's phases. <mark_weaver>I'd encourage you to take a look at ld-wrapper.in and think about how something analogous could be done for the go linker. <codemac>ok thanks for all your help mark_weaver ! <mark_weaver>codemac: can you tell me about the environment variable approach to setting rpaths? <codemac>GO_LDFLAGS=-r "gcclib:glibclib" -extldflags "-Wl,-rpath,gcclib -Wl,-rpath,glibclib" <codemac>needs to be set during the ./all.bash <mark_weaver>so Go has it's own linker? it doesn't use GNU binutils? <codemac>no it does not, yea, they use a linker that ken thompson wrote <mark_weaver>okay, if the go compiler runs 6l from PATH, then it might be as simple as making a 6l-wrapper package <codemac>yeah, that's what I'm thinking. My nervousness is that go 1.5 comes out in august, and they're redoing the whole toolchain in Go <codemac>so we need to have 1.4.2 packaged for bootstrapping most likely. <codemac>but a 6l-wrapper may be overkill as they're moving away from it ? I dunno, it probably deservers some kind of "wrapper" to be correct in the interim <codemac>I'm only packaging this crap because I use it all day at work, and man, guix is too good to not have for my work workspaces as well :D <mark_weaver>building anything in guix requires that rpaths are inserted for all shared library references <mark_weaver>so we really need something like ld-wrapper, or else those rpaths would have to be inserted manually *every* time to compile anything in go. <codemac>well that's another go-ism. go compiles everything statically so it may not be necessary except for the compiler/runtime itself which uses pthread_cancel from libgcc_s. <mark_weaver>well, if most everything is linked statically, then I guess it's not an issue at all. <codemac>Yeah maybe? Trying to get their test suite to pass will actually prove it :) If not, I'll go the 6l-wrapper route <mark_weaver>gnu-build-system sets LIBRARY_PATH to the */lib directories of all build inputs, so as long as the Go toolchain honors that variable, I guess maybe that's all that's needed. <codemac>I'm also converting this package to use gnu-build-system just minus lots of random phases <codemac>a go-build-system may be needed for things like docker, but maybe not. that's a later problem. <mark_weaver>do Go programs tend to link with other mainstream libraries written in C/C++, or is it completely its own world? <codemac>almost completely it's own world, which is unfortunate. <mark_weaver>okay, well, the good news is that we probably don't need anything like ld-wrapper, then :) <codemac>they have "cgo" which is their cbindings, but due to it's runtime and lack of real "threads" it's a little confusing. <codemac>yeah, there may be a few specific go libraries that need some wrangling, but mostly people don't use cgo