IRC channel logs


back to list of logs

<Sleep_Walker>quick question - - what is prefered way of indentation around tarball URL? like in efl or like in emotion-generic-players
<mark_weaver>Sleep_Walker: you should try to keep lines < 80 chars, so the way you did it in elf is better.
<toothbrush0>Gaah, i don't suppose anybody has dared do anything with Boost Library binary stuff? <>
<mark_weaver>toothbrush0: what do you mean? we already have boost in guix.
<mark_weaver>what do you mean by "binary stuff" ?
<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 looks
<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.
<mark_weaver>boost has a very unusual build system
<toothbrush0>yeah i have absolutely no idea what's going on there.
<toothbrush0>thanks for the pointer though
<toothbrush0>i hadn't made the connection
<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>e.g. in boost 1.42
<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....
<mark_weaver>that might be the right thing, dunno.
*mark_weaver goes afk
*iyzsong will package font-adobe-source-han-sans, for my name's sake ;-)
***tschwing_ is now known as tschwinge
<mark_weaver>iyzsong: ah, good! :)
<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>heh, okay.
<rekado>I'll try to just use wrap-program with (getenv "PYTHONPATH") if it's set in the set-env phase already.
<Sleep_Walker>mark_weaver: ok!
<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>Ah, nvm.
<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?
<effa`> /bye
<iyzsong>I don't know too, but many distro have one named 'libmpc' to avoid conflict.
<taylanub>toothbrush0: maybe mpc-player
<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>I finally updated my dedicated guix machine
<davexunit>really liking the new artwork that greets me
<civodul>Hello Guix!
<davexunit>hey civodul
<davexunit>since $HOME/.bashrc is generated by guix and read-only, should I configure it via my OS config file?
<davexunit>I want to set my $PS1 and such
<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
<civodul>it should be fine
<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>does anyone know how to make evince work
<davexunit>I see this:
<davexunit>WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
<davexunit>and then it exits
<civodul>i have this warning but it's not fatal
<civodul>try "export DBUS_FATAL_WARNINGS=0"
*civodul goes afk a bit
<davexunit>hmm, wonder why it segfaults then...
<davexunit>I'll just use xpdf for now
*rekado_ uses Emacs for PDFs.
<davexunit>I tried opening the pdf with emacs and it didn't do anything
<davexunit>so I imagine I have to setup something else
<rekado_>davexunit: do you have ghostscript installed? Emacs uses ghostscript (or mupdf) to convert the pages to images.
<davexunit>oh okay, that must be it.
<davexunit>perhaps the input should be propagated?
<civodul>davexunit: it's not on GuixSD, is it?
<civodul>that Evince segfaults
<davexunit>it is
<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. :)
<davexunit>glad to see that I wasn't totally off-base.
<davexunit>now Ruby programs should "just work"
<civodul>i wonder why they put binaries in this obscure place
<davexunit>I guess because all gem data goes to the same place.
<davexunit>maybe there's something I can tweak
<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>rekado_: maybe GEM_HOME will do it
<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
<civodul>dunno what happened
<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.
<mark_weaver>evince works for me without crashing. strange.
<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>civodul: I disagree with that last claim :)
<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>IMO anyway
*mark_weaver dislikes silently corrupting data by default
<civodul>yes probably
<civodul>i wonder if we'd uncover weird things
<civodul>(i also wonder why Guile defaults to 'substitute)
<mark_weaver>yeah, I wonder that too.
<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 :-)
<civodul>not sure if it's still accurate
<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 looks
<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>s/much //
<mark_weaver>generating C and then compiling from it is probably the right method for porting to a new platform, however.
<mark_weaver>(although probably more is needed)
<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> says "In general, we support building with the previous 2 major releases"
*mark_weaver goes afk
<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>effa``: okay, thanks for clarifying.
<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>or at least that's my assumption
<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>effa```: see to find anything you missed
<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.
<sirgazil>Hi, I'm trying to use Guix from a git checkout with ./pre-inst-env on a Debian system, but I'm getting an error when I try to install a package:
<civodul>hi sirgazil!
<mark_weaver>sirgazil: did you use ./pre-inst-env to launch guix-daemon as well?
<mark_weaver>well, I'm just guessing; civodul would know better
<civodul>sounds like a good guess
<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>interestingly, things seem to be going well on i686
<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>"FAIL: max-count-overread"
*mark_weaver restarts dependency failed builds for the sake of MIPS
<sirgazil>mark_weaver: no, I'll try that then.
*mark_weaver goes afk
<civodul>mark_weaver: i see "PASS: max-count-overread" here
<civodul>on the page you linked
<davexunit>question about propagating inputs:
<davexunit>libxslt depends on zlib
<davexunit>icecast depends on libxslt
<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
<davexunit>should zlib be propagated?
<davexunit>(sounds like a word problem in math class)
<civodul>davexunit: if libxslt-config says "-lz", then yes
<civodul>mention it in a comment next to it
<davexunit>yeah, it does.
<davexunit>spent some time troubleshooting in #icecast
<davexunit>it looked like a problem with their configure script
<davexunit>but it was all zlib's fault :)
<civodul>and then they ridiculed you because you're using this exotic package manager ;-)
<civodul>davexunit: BTW, seen on #nixos:
<davexunit>civodul: they did ask me what distro I was using
<davexunit>"one you haven't heard of!"
<davexunit>civodul: and yeah, docker machine was posted on HN yesterday
<civodul>oh, ok
<davexunit>and someone said "no thanks, I'll keep using NixOS/NixOps"
<davexunit>and then someone asked if they checked out guix
<davexunit>and they said no :(
<davexunit>which makes sense
<civodul>sounds like a déjà vu ;-)
<davexunit>nix works well, so those already using it have no reason to look elsewhere.
<civodul>yes, to some extent
<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
<davexunit>are these *really* needed?...
<civodul>so libxml2 needs to be propagated as weell
<civodul> is really impressive
<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>a_e: libxml2 will be a propagated input.
<davexunit>it currently isn't, but I'm fixing it.
<davexunit>the .pc file has -lxml2 and -lz
<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>yeah, that's true.
<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.