<gzg>Okay, I'll deal with dhcpcd tomorrow or later this week... right now I want to know why my expression for libnl isn't finding flex, bison, and pkg-config -- while they're both inputs and too were called as modules. http://paste.lisp.org/+2ZL7
<gzg>Inputs got weirdly formatted somehow on the paste, but they look "proper" in the actual expression; FYI.
<gzg>"./pre-inst-env guix build libnl" and the module is already obviously loaded.
<mark_weaver>well, on my system I get: guix build: error: gnu/packages/network.scm:12:2: package `libnl-3.2.22' has an invalid input: ("pkg-config" (unquote pkg-config))
<mark_weaver>and to be honest, I'm not sure what that's about (I'm still a relative guix newbie myself). but I'm baffled at what you're reporting. how it could work at all with (guix packages pkg-config), I cannot explain.
<mark_weaver>it may be that you need to wait for the real guix experts to return.
<mark_weaver>gzg: see m4.scm for an example of patching. you need both #:patches passed in the arguments, and also entries for each patch in the inputs. the patch files themselves should be in gnu/packages/patches/
<gzg>mark_weaver: Would you like to see a paste of the package and related error?
<mark_weaver>probably guix itself ought to be fixed to cope with such strange filenames.
<mark_weaver>gzg: can you please send those things to email@example.com? that will automatically generate a ticket in the bug tracking system, and civodul will look into it.
<mark_weaver>and you can also include my observation that there's a strange filename in there with unicode characters.
<mark_weaver>gzg: oh, I see why I was getting "invalid input" on the libnl package. the single quote in front of the list of inputs should be a backquote (`), because of the unquotes deeper in (the commas)
<gzg>It just doesn't find them in the configure stage, then asks me to rerun ./configure, but the build does that everytime, right, or...?
<mark_weaver>gzg: I still don't understand how the network.scm module even compiled properly with (guix packages pkg-config) in there. that should have caused it to fail before it even tries to build the software.
<mark_weaver>gzg: did you run 'make install' at some point after you added network.scm? is it possible there's more than one version floating around your system?
<mark_weaver>at this point, I'd be tempted to introduce an obvious syntax error into that file (like a bunch of open parentheses near the beginning) to make sure it's even reading the file you think it's reading.
<gzg>mark_weaver: Should it be the file, or the expression? Because I have a whole bunch of network tools via said file. :^P
<mark_weaver>gzg: can you paste your entire network.scm file somewhere I can see?
<mark_weaver>but again, you should have been getting errors, not just because of the (guix packages pkg-config), but also because of the single-quote instead of the backquote.
<mark_weaver>something very strange is going on, that's for sure.
<mark_weaver>I assume that you're editing the files in the guix source tree, and not in the installed directories, right?
<gzg>mark_weaver: I changed the latter; Should I just strike out the pkg-config entirely then?
<davexunit>sent a patch for libtheora to the devel list
<gzg>zacts: Unless libncurses ships with ncurses, you need to package it yourself. Typically you'd add the module containing such an expression so "#:use-module (gnu packages ncurses)" and then you'd add in to your inputs -- "(inputs `(("libncurses" ,libncurses)))".
<zacts>'This is probably a library called 'curses' or 'ncurses'. You may'
<mark_weaver>two questions: (1) if the bootstrap tarballs are updated, does that change the hash of all derivations that follow? and (2) what is the process for upgrading the bootstrap binaries without disrupting users of an older version of Guix?
<mark_weaver>it's a good question, and you can ask the same question of any POSIX byte string, whether it be in ARGV, or in an environment variable, or the name of an environment variable, or the hostname, etc.
<mark_weaver>of course, most of the system software treat these things as sequences of bytes.
<mark_weaver>but humans think of these things as strings, and I think that's important.
<mark_weaver>I'd like to see all of these things universally agreed upon to be in UTF-8.
<mark_weaver>I think we should think of them as strings, and represent them as strings in Guile.
<mark_weaver>UTF-8 implies unicode. Yes, the technique of encoding large numbers compressed could be used more generally, but when the numbers mean something different that wouldn't strictly-speaking be UTF-8.
<viric>mark_weaver: I'm happy to see a US citizen caring about locale :)
<viric>some thing I see often, is "I failed in some attempt long ago to prepare my system for my locale, so I learnt only the us keyboard layout and I have ascii everywhere". Sad!
<viric>I see that specially in non-english countries, I mean ;)
<mark_weaver>yeah, I'm not sure how I got to feel so passionately about this, but I really don't like the fact that english is used for virtually all free software work. it really should all be esperanto.
<mark_weaver>well, I'm not seriously suggesting it. I know that in practice it probably wouldn't work out so well, because so few programmers know esperanto or want to learn it.
<mark_weaver>but I wish that esperanto were widely used enough that we could use it for free software.
<mark_weaver>well, it would certainly enable a lot more cross cultural communication, but I don't buy that it would necessarily result in the "devastation" of cultural differences. people's minds are not so easily changed.
<viric>I think that too much people is ready to give up about its language, and go for the easiest and most practical solution (a succesful international language). If that is English, it's harder than if it is esperanto.
<gzg>How long should it take for a submitted/sent message to be up on lists?
<viric>Parents are ready not to convey their language to children, if they think that will make the child life more succesful. I know "modern" parents that talk in English to their children, they not being English at all
<mark_weaver>gzg: not long, but if you're not subscribed to guix-devel, maybe it's hung up in moderation.
<mark_weaver>civodul: what does guix-devel do with mails from non-subscribers?
<gzg>viric: "Modern parents" aren't most parents though -- I know parents that are teaching their kids Esperanto even some Lojban, but I know a lot more who just stick with the norm because they don't see that value. :^P
<civodul>mark_weaver: it accepts them (like all GNU lists), but usually there's a delay for the first post
<taylanub>And they're quite nationalistic. I caught some of it; a national anthem or historical story on a war Turks fought can manage to make me emotional, but on a conscious level I don't hold such feelings very high.
<gzg>taylanub: My parents (midwest US) have a neighbor that is super "nationalist" -- for the irish. There is a tremendous amount of pride he has, but he's never even been to Ireland...
<taylanub>Hehehe, I think some Turks in Germany are similar.
<viric>gzg: I think all would be worse, with esperanto being a popular business thing for life success.
<viric>I don't mean how bad it is now, I mean that I forecast all being worse. :)
<viric>I can't prove it. But I think that the harder the 'current arbitrary international language', the better chance for other languages to stand.
<gzg>viric: Well for business and international communication, I think it is preferable -- but as a "universal language" that would replace others, yeah -- but I don't think that's the goal of such languages. :^P
<viric>I think each language has its own way of modeling reality, and if that standed until tdoay, it's quite worth.
<mark_weaver>I sympathize with your concerns, but I think it's far more important to promote cross-cultural communication. That could very well reduce the amount of war considerably.
<viric>gzg: it doesn't matter "the goal of the language". what matter's is what people will do with the languages at their disposal :)
<viric>I understand. :) But I still think that with an easy international language, all would be worse. I don't think that the problem now sits in the lack of cross-cultural communication, now.
<mark_weaver>it's much easier for the powerful interests to convince their populations to support war against another nation, when the local population has very little understanding or communication with the people on the other wise.
<a_e>davexunit: If you want to develop, you should use git HEAD.
<davexunit>a_e: I agree, but I was having some issues. I'll try again.
<gzg>davexunit: Yeah, ideally -- if you were to be a regular contributor; Git would be ideal. That being said, till the issues are worked out, assuming guix will let you pull to the latest (I sometimes have issues doing so), then it's a "good enough" solution, for the time being at least. :^P
<davexunit>I'm using the git repo, just not the latest HEAD.
<davexunit>guix/packages.scm:484:16: In procedure expand-input:
<davexunit>guix/packages.scm:484:16: Throw to key `match-error' with args `("match" "no matching pattern")'.
<civodul>davexunit: ac10e0e17e366d354ad8b3f91e03c1bdeddc7632 introduces an ABI incompatibility
<civodul>which means you have to run 'make clean && make'
<civodul>(basically the layout of <origin> records changes)
<mark_weaver>glib on MIPS N32 fails one test: 'signals' in gobject/tests. In the log file: GLib-GObject:ERROR:signals.c:667:all_types_handler: assertion failed (ui == G_MAXUINT - 42): (4294967253 == 4294967253)
<mark_weaver>but those numbers look the same to me, so something fishy is going on.
<davexunit>civodul: oh okay. I guess that's what my problem is.
<a_e>civodul: Actually, this is the current error message on hydra. Maybe we also need to do a "make clean" there?