<mark_weaver>Sleep_Walker: you should try to keep lines < 80 chars, so the way you did it in elf is better. <mark_weaver>toothbrush0: what do you mean? we already have boost in guix. <toothbrush0>well, i don't quite know how it's supposed to work, and a package i'm building requires it, but claims not to be able to find the required library ("checking for main in -lboost_filesystem-mt... no <toothbrush0>mark_weaver: section 5.1 of the page i linked to talks about "Boost binaries" <mark_weaver>we have libboost_filesystem, but not libboost_filesystem_mt. that might have to do with multi-threading support. maybe we are missing some needed flags in our boost package. <toothbrush0>yeah i have absolutely no idea what's going on there. <mark_weaver>debian's boost-filesystem1.55-dev package doesn't have the '_mt' suffix on that library name either. <mark_weaver>ah, but old versions of boost had variants both and without the _mt suffix. <mark_weaver>my wild guess is that long ago, boost made separate libraries for multi-thread and single-thread, and now they just have the multi-thread ones.. <toothbrush0>i wonder if i could try some kind of search-and-replace from filesystem_mt -> filesystem.... *iyzsong will package font-adobe-source-han-sans, for my name's sake ;-) ***tschwing_ is now known as tschwinge
<rekado>I'm having trouble wrapping solfege; I can use wrap-program to wrap the executable such that PYTHONPATH is set to include pygtk, but pygtk has propagated inputs pycairo and gobject which also need to be in the PYTHONPATH. <rekado>I'm not sure I'm doing this right. <rekado>how can I access the propagated inputs of an input in a build phase? <rekado>or is this something I shouldn't want to be doing? <rekado>even if I add pycairo and gobject as direct inputs to solfege (to make it easier to add their paths to PYTHONPATH with wrap-program) I'm missing dependencies. <rekado>it really feels like I'm doing something I should not be attempting to do. <rekado>I would like to be able to just add all python inputs and their inputs to the PYTHONPATH, so that I can wrap "/bin/solfege". <mark_weaver>rekado: I think the way this is supposed to work is that the 'native-search-path' specification for PYTHONPATH in the python and python-2 packages is supposed to ensure that PYTHONPATH is automatically set in the 'set-paths' phase to the right thing. <mark_weaver>but I suppose that's looking through native inputs, not normal inputs. <mark_weaver>maybe best to wait for civodul to answer your questions. my knowledge of this area is too weak, and it's late here. <rekado>I'll try to just use wrap-program with (getenv "PYTHONPATH") if it's set in the set-env phase already. <toothbrush0>Silly question time: how do i set environment variables when calling (system* ..) ? <toothbrush0>I'm not good at finding this sort of thing in TFM :/ <toothbrush0>How should i handle packaging the (apparently absent) "mpc", which is the command-line client to Music Playing Daemon, since its name conflicts with multiprecision? <iyzsong>I don't know too, but many distro have one named 'libmpc' to avoid conflict. <taylanub>toothbrush0: best to ask the mailing list <taylanub>toothbrush0: environment variables can be set like (setenv "CC" "gcc"). they will be carried on to the rest of the build process I think, i.e. including all remaining build phases. <davexunit>really liking the new artwork that greets me <davexunit>since $HOME/.bashrc is generated by guix and read-only, should I configure it via my OS config file? <civodul>davexunit: it's not supposed to be read-only, that's a bugg <civodul>i guess that's because useradd preserves the permissions of skeleton files <civodul>mark_weaver: i'll push the (setenv LC_ALL ...) patch i posted along with my other core-updates changes <davexunit>civodul: oh okay, so the skeletons are just examples, basically? <civodul>davexunit: more than examples; these are the files that useradd installs for new accounts <civodul>so new user accounts are usable out of the box <rekado_>I think the python build system should pass make-flags to the build phase, so that things like "--compiler=gcc" can be passed. <rekado_>I'm testing a change to this effect right now. <rekado_>For some reason it's looking for "cc" when distutils.ccompiler is used and it won't be persuaded by the CC environment variable. <davexunit>civodul: okay, I'm just thinking about how to reconcile my version controlled dotfiles that I carry with me to all of my machines and these auto-generated files <davexunit>WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files <civodul>i have this warning but it's not fatal *rekado_ uses Emacs for PDFs. <davexunit>I tried opening the pdf with emacs and it didn't do anything <rekado_>davexunit: do you have ghostscript installed? Emacs uses ghostscript (or mupdf) to convert the pages to images. <civodul>davexunit: it's not on GuixSD, is it? <davexunit>I'm working from home today from my guixsd machine <civodul>i don't have gs installed in my profile, so that must be something else <civodul>could you just get a backtrace? it might give an idea <davexunit>I can try to debug later, I just don't have the time now. <davexunit>doing some research for libreplanet atm and noticed that guix doesn't have an icecast package yet. I will fix this soon, I hope. <davexunit>civodul: thanks for the feedback on those search path patches. hoping to work out that last remaining issue soon and add test cases. :) <civodul>i wonder why they put binaries in this obscure place <davexunit>I guess because all gem data goes to the same place. <rekado_>I just contacted the author of the GPL software that's included in an MIT licensed package after the author of the package has not responded via email nor via github issue tracker. <rekado_>people don't really seem to care about licenses. <davexunit>(setenv "GEM_HOME" (assoc-ref outputs "out")) <davexunit>regardless, I think that it's useful for packages to add to $PATH :) <davexunit>or for more than one package to specify the same search path variable <davexunit>rekado_: ah, I already set GEM_HOME in the build system <davexunit>I might be able to specify a special /bin directory <davexunit>because I still want the rest of the gem stuff to be in /lib/ruby/gems <civodul>hmm my Gnus doesn't have Federico's GHC and libedit messages <mark_weaver>davexunit: to view PDFs in emacs, you need to install one of several pdf renderers in your PATH. the one I'm using now is 'mupdf', which works well. <mark_weaver>davexunit: in theory, we could add all of the things that emacs might use as inputs, but the number of inputs would be huge. <davexunit>mark_weaver: okay, that sounds reasonable then. <mark_weaver>civodul: it may be that our 'substitute*' and any other similar phases that do substitutions should be using latin-1 as the encoding. <mark_weaver>ultimately this should probably be fixed by supporting a permissive UTF-8 encoding in guile, along the lines of what emacs does. <mark_weaver>(although I continue to think that it should be strict by default) <civodul>mark_weaver: for now i think we can leave substitute* as is, i.e., strictly expecting locale encoding <mark_weaver>civodul: I'm worried that the automatic phases that go through a huge number of files doing substitutions will cause damage that we might not notice right away. perhaps we should at least configure it to raise decoding errors instead of silently changing things to question marks? <civodul>mark_weaver: decoding errors may be better yes <civodul>OTOH, if we don't notice the damage, it's not really damage :-) <mark_weaver>damage could for example be in the form of an error message that is rarely printed. <civodul>yeah we should enable hard decoding errors at least in substitute* <mark_weaver>I would advocate enabling hard decoding errors for the entire guile builder process. <mark_weaver>if we are munging some characters somewhere, we ought to know about it *mark_weaver dislikes silently corrupting data by default <civodul>i wonder if we'd uncover weird things <civodul>(i also wonder why Guile defaults to 'substitute) <mark_weaver>if it had been me, I would have made Guile raise errors by default. but maybe there was a good reason, dunno. <effa``>civodul: should I resend the patches for ghc and libedit? <mark_weaver>effa``: do you have a way to build ghc without starting from binaries at all? I wasn't quite sure I understood what you wrote in the email concerning my proposal for self-hosted compilers. <civodul>effa``: i don't know, it's probably just me <mark_weaver>is it starting from automatically generated C code, or something? <civodul>effa``: somebody else will have review them :-) <mark_weaver>compiling from generated C code that's not actually source code and is quite hard to read is not much (if any) better than starting from binaries. <mark_weaver>okay, given what I just wrote above, I don't see compiling from generated C as much very helpful to the problem I'm trying to solve anyway. <mark_weaver>generating C and then compiling from it is probably the right method for porting to a new platform, however. <mark_weaver>regarding the multiple-steps problem: it's not a problem if you trust binaries from hydra, and if the proposed solution to that problem is to simply trust binaries from upstream, I don't see how that helps (unless you trust upstream more than hydra) <effa``>mark_weaver: What I was trying to say in my email is that my recipe for GHC downloads, on top of the source code, a pre-compiled version which is used to bootstrap the proces and build GHC. <effa``>The uncompressed archive is quite huge. For this reason I unpack it locally into the build environment without creating a separate package. <effa``>The bootstrap binaries are therefore delted at the end of the intallation of the newly created GHC. <effa``>The fact that we create a hash for the bootstrap binaires guaranteey that we will always obtain the same binary tarball. <effa``>If it is already corrupted when we create the hash, then it is actually useful to update to a new version which will likely not also be corrupted. <mark_weaver>the thing is, most people are not going to build ghc on their own machine; they will instead get binaries from hydra. <mark_weaver>regarding the hash preventing corruption: the problem is that every time we need to update the bootstrap binaries, we have to trust upstream all over again. even if today's bootstrap binaries are good, if the upstream build system gets compromised at some point in the future, we will eventually pick up that malware the next time we update. <mark_weaver>that's why I think it's preferable to maintain our own bootstrap binaries, and to update them (as rarely as reasonable) using deterministic build processes that can be independently verified. <mark_weaver>the upstream build process probably isn't done in a way that could be independently verified. <mark_weaver>effa``: I think you may have just missed several messages directed at you. <effa```>Ooops, I just reconnecte. Not sure if my messare passe through <mark_weaver>well, I have to go afk for a while anyway, so we'll have to continue this discussion later. <effa```>OK. I'm not sure I will be around later, but we may continue on the ML. <effa```>I think that there are many scenarios and, depending on which one you pick, having fix bootstrap binaires may be better or worse. <mark_weaver>sirgazil: did you use ./pre-inst-env to launch guix-daemon as well? <civodul>you would get this error if you didn't install and ran ./guix-daemon from the build tree <civodul>running "./pre-inst-env guix-daemon" would fix that <mark_weaver>civodul: btw, did you notice that 'grep' for x86_64 failed a test on core-updates? <mark_weaver>and the mips64el problems are just "lsh timed out" related to an issue on my end. I have to keep restarting those builds manually. <mark_weaver>(related to a malfunctioning router that my horrible ISP forces me to use) *mark_weaver restarts dependency failed builds for the sake of MIPS <civodul>mark_weaver: i see "PASS: max-count-overread" here <davexunit>icecast fails to build if I don't also add zlib as an input, because icecast wants to link against it, due to libxslt-config output the '-lz' flag <civodul>davexunit: if libxslt-config says "-lz", then yes <davexunit>it looked like a problem with their configure script <civodul>and then they ridiculed you because you're using this exotic package manager ;-) <davexunit>civodul: they did ask me what distro I was using <davexunit>civodul: and yeah, docker machine was posted on HN yesterday <davexunit>and someone said "no thanks, I'll keep using NixOS/NixOps" <davexunit>and then someone asked if they checked out guix <davexunit>nix works well, so those already using it have no reason to look elsewhere. <davexunit>I mean, I *wish* they would check out guix, but the activation energy required for that reaction is high. <davexunit>'xslt-config --libs' outputs these additional libs: -lxml2 -lz -ldl -lm <civodul>so libxml2 needs to be propagated as weell <davexunit>civodul: libxml2 is an input to libxslt, both of them have -lz in their .pc files. should zlib be propagated in both packages? <a_e>I would say yes, unless libxml2 is already propagated in libxslt. <davexunit>which makes me unsure if I should be explicit about the propagated zlib <a_e>Okay, I see. Then I think it is not necessary to make zlib an input to libxslt at all. Because it will be there automatically. <davexunit>would it be okay to remove zlib as an input from all packages that use libxml2? <a_e>If it is propagated, I should think so. <davexunit>alright, I'll make a patch set that fixes libxml2 and libxslt and then trims the inputs from other packages using them. <a_e>Sounds like a patch for core-updates. <a_e>But please try it out on an example package first in case I am giving bad advice. I may have misunderstood how things work.