<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
<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>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.
<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>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>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)
<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