IRC channel logs
2014-01-25.log
back to list of logs
<civodul>jmd: does the fltk patch depend on the libxrender patch? <jmd>If the libxft does not propagate libxrender then all packages which use libxft will have to also list libxrender as an input. <jmd>So far as I can see, libxft cannot be used without libxrender <civodul>because it linking libfltk.so otherwise gives an "unresolved symbol" error, right? <jmd>Its not visible to the user. But thats what pkg-config gets, and then pkg-config thinks that libxft is not installed. <civodul>jmd: but xrender.pc does not "Require:" Xft <civodul>maybe it's just that fltk needs libxft as an input, no? <jmd>xft.pc requires xrender <jmd>or it should do. I didn't check. <jmd>fltk already has libxft as an input. Adding libxrender as an input would also work. But why do it that way? <jmd>Right now I'm struggling with a wierd problem. <jmd>I have a makefile which has this rule: <jmd>libaegis/aer/report.gen.cc libaegis/aer/report.gen.h: \\ <jmd> libaegis/aer/report.y <jmd> @echo Expect 2 reduce/reduce conflicts. <jmd> $(YACC) -d libaegis/aer/report.y <jmd> sed -e 's/[yY][yY]/aer_report_/g' -e '/<stdio.h>/d' -e \\ <jmd> '/<stdlib.h>/d' -e '/<stddef.h>/d' y.tab.c > \\ <jmd> libaegis/aer/report.gen.cc <jmd> sed -e 's/[yY][yY]/aer_report_/g' -e \\ <jmd> 's/Y_TAB_H/aer_report_TAB_H/g' y.tab.h > \\ <jmd> libaegis/aer/report.gen.h <jmd> rm -f y.tab.c y.tab.h <jmd>In the chroot YACC returns 0 but does not create the y.tab.c (it does create the y.tab.h) <jmd>Consequently sed fails. <civodul>what's the value of YACC in config.log? <civodul>so it could be that for some reason this package expects an older one <jmd>Oddly it works fine when I run make from /tmp/nix-xxxx <civodul>after sourcing 'environment-variables'? <civodul>or could it be a parallel make issue? <jmd>Oh perhaps you are right. <jmd>if the y.tab.c is getting deleted by another rule <jmd>y.tab.c is a global!! <jmd>Where does the #:parallel-build? #f go ? <jmd>In (arguments) I presume <jmd>That would also explain why it worked for me once. <jmd>I think it has fixed the problem. Thanks for catching that one! <jmd>I'm surprised Peter Miller made that mistake. <civodul>the Peter Miller of "Recursive Make..."? <jmd>guix package doesn't accept the --target= option. How can I install packages targeted at other systems? <civodul>jmd: that's a weird thing to do ;-), but you can do: guix package -i $(guix build --target=foo ...) <jmd>Not all that wierd. I have my fileserver mounted from machines with different architectures. <jmd>It would be good to allow: guix package -i --target=foo <jmd>But it should then default to the profile_dir .guix_profile_foo <civodul>actually, i was thinking that when we support several kernels, then it would be great if users could end up have ~/.guix-profile point to a version of the profile for the current kernel <civodul>so you could boot into the Hurd, or Linux-Libre, and things would just work <civodul>BTW, i should probably put a message on planet.gnu.org saying that Guix will be at FOSDEM <civodul>so we have more chances to meet interested people <jmd>Sound like a good idea. <jmd>I've got some tests which are writing to $HOME is it safe to set it in the test phase? <civodul>yes, you'll have to set $HOME to a writable directory <jmd>Can I use a glob pattern in substitute* ? <civodul>the first argument can be either a file name, or a list of file names <civodul>so you can use the 'find-files' procedure to list files matching a given regexp (recursively) <davexunit>hey #guix, I want to write a package for guile-sdl. there's a module for guile and module for sdl. where should it go? <civodul>davexunit: i'd say guile-sdl, but either way is fine