IRC channel logs


back to list of logs

<a_e>Okay, time to go. Good luck with your packages!
<mark_weaver>good night a_e!
<zacts>ok, thanks
<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.
<gzg>Inputs got weirdly formatted somehow on the paste, but they look "proper" in the actual expression; FYI.
*mark_weaver looks
<davexunit>I got the guix daemon running, but I can't build anything :(
<davexunit>I'm going to go back to the 0.4 release and try from there
<mark_weaver>gzg: first of all, in (guix packages pkg-config) "guix" should be replaced by "gnu". ditto for bison and flex
<mark_weaver>I'm not sure how you managed to run 'make' without it catching that.
<gzg>Oh wow -- that's an oversight on my end. :^U
<mark_weaver>did you add gnu/packages/network.scm to ?
<mark_weaver>I'm not sure how you even got it to start building, to be honest.
<gzg>Queer; It seemed to make no difference...
<mark_weaver>davexunit: tell me about the problem you're having.
<mark_weaver>gzg: when you ran 'make' in the top-level guix directory, did you see it compile network.scm ?
<gzg>mark_weaver: Yup.
<mark_weaver>gzg: are you prefixing your guix commands with ./pre-inst-env ?
<gzg>mark_weaver: Yup.
<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>(they are mostly european)
<gzg>mark_weaver: No problem; I'm in no real rush. :^)
<davexunit>mark_weaver: I was getting match errors with the code from master
<davexunit>I just checked out v0.4 and rebuilt and now things are building.
*gzg still needs to do kbd.scm eventually -- so he can use dvorak on the darn vm. :^)
<mark_weaver>hmm, interesting.
<mark_weaver>gzg: sounds good! :)
<zacts>almost done with my build
<zacts>how does guix handle redundancy of already installed packages during builds?
<zacts>does it ever rebuild packages that it doesn't need to rebuild?
<gzg>Oh, that's weird ... the patch phase tries to find "./doc/utf/??????" and (I'd think of course) "No such file or directory". :^/
<gzg>This is on my kbd expression, btw.
<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/
<mark_weaver>gzg: or did you not try to add a patch?
<mark_weaver>if not, it might be due to bizarre filenames.
<gzg>mark_weaver: I haven't even attempted a patch -- I'm just, at this moment, curious to where/what the deal with this file and/or directory is.
<zacts>darn it's building gcc, this will take forever..
<mark_weaver>ah, there is indeed a very strange filename in doc/utf: ♪♬
<gzg>How would one handle that -- is this even something at my very low skill-level, could begin to tackle?
<mark_weaver>hmm, this will require some thought.
<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 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)
<mark_weaver>gzg: I'm trying to build it now.
<gzg>mark_weaver: Ah -- corrected.
<mark_weaver>gzg: for me, it found bison, flex, and pkg-config.
<mark_weaver>gzg: and in fact the entire libnl build worked for me. not sure if the library works, but it built.
<gzg>mark_weaver: I'm not sure man -- but on my end, still problems. :^P
<mark_weaver>gzg: what happens?
<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?
<gzg>mark_weaver: I don't believe so.
<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?
<gzg>mark_weaver: It's just in gnu/packages/
<mark_weaver>gzg: does it still say (guix packages pkg-config) in the file you've been trying to use?
<mark_weaver>okay, how about this: I'll send you the file I have that works on my system.
<mark_weaver>we'll see if it works on yours and take it from there.
<gzg>mark_weaver: Nope, changed that when you first mentioned it -- to (gnu packages pkg-config)
<davexunit>so I'm at the v0.4 tag and I'm trying to add a new package.
<gzg>Sounds good to me, though I could paste it somewhere if you'd like.
<davexunit>in the oggvorbis.scm file.
<zacts>gcc was not too bad it's done already..
<mark_weaver>I'm sorry, I have to go afk for a while.
<davexunit>there are no exports here, so I just defined a new package there.
<davexunit>guix cannot find it.
<gzg>mark_weaver: Np, I'll probably end up doing some chores I put off for awhile anyways, in a sec or two. :^J
<mark_weaver>gzg: well, my version that works for me is at
<mark_weaver>sorry to leave you all with problems, but I have to go offline for a while. good luck!
<davexunit>oops. didn't see that define-public was there. problem solved!
<davexunit>see ya mark_weaver
<gzg>mark_weaver: o/
<zacts>ok, my zsh build is asking for a libncurses
<zacts>how does guix track dependencies, do I need to manually do this?
<zacts>or does it gather this information from the ./configure files
<gzg>zacts: Are you packaging this?
<zacts>gzg: I'm trying to yes
<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'
<zacts>that was the specific error
<zacts>"No terminal handling library was found on your system"
<zacts>zsh configure error
<zacts>I think I figured it out
<zacts>(gnu package ncurses)
<zacts>nope same problem
<gzg>zacts: Did you add it as an input?
<zacts>gzg: what do you mean exactly?
<gzg>zacts: Do you have, say "(inputs `(("ncurses" ,ncurses)))" in your expression?
<zacts>I added the lines: #:use-module (gnu packages ncurses)
<zacts> #:use-module (gnu packages readline)
<gzg>zacts: Yup, that loads the module -- now you need to actually "call" it via inputs.
<zacts>ah I see
<zacts>now I think I know what to do
<zacts>now it's working
<zacts>let's see if the build succeeds
<zacts>configure: error: no controlling tty \\n Try running configure with --with-tcsetpgrp or --without-tcsetpgrp
<zacts>I guess I'll try what it says
<gzg>zacts: Do you know how to add argument, config flags?
<zacts>from reading bash.scm
<zacts>darn, I need to git checkout master again
<zacts>I messed up my entire branch
<zacts>I'll try this again tomorrow. maybe for now I'll port a simple utility
<davexunit>I'm working on packaging libsdl
<davexunit>I want to use the gnu build system, but skip the `make check` phase
<davexunit>since there is no such task in sdl.
<davexunit>is this possible? do I need write a new build system?
<zacts>davexunit: would you mind pasting into a pastebin what your libsdl.scm looks like?
<davexunit>zacts: this is what I have so far:
<zacts>let me check it out
<zacts>davexunit: is there a configure flag you can pass to disable make check?
<davexunit>I'm not sure
<zacts>when I rebuild my guix I'll try it out
<zacts>but I'm sure someone who knows for sure will help out soon.
<zacts>I'm afk. (homework)
<civodul>Hello Guix!
<mark_weaver>good morning, civodul!
<civodul>what's up on the MIPS front? :-)
<mark_weaver>it's going very well! slowly, but well :) here's a list of what I've built so far:
<mark_weaver>civodul: is there any provision for multiple versions of the bootstrap tarballs?
<mark_weaver>sorry, that was unclear. let me try again.
<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?
<civodul>nice :-)
<civodul>upgrading the bootstrap tarballs leads a full rebuild
<civodul>that rarely needs to happen though
<civodul>for instance the bootstrap tarballs on i686+x86_64 date back to January
<civodul>when we do need to update them, we can do it in the 'core-updates' branch
<civodul>along with other core updates
<mark_weaver>More specifically, I'm curious what happens if I replace my current set of cross-compiled MIPS N32 bootstrap tarballs with a native-build of the same derivations.
<civodul>you have to rebuild everything
<civodul>unless they happen to be bit-for-bit identical
<civodul>i can imagine how frustrating it is ;-)
<mark_weaver>so the hashes of the bootstrap derivations are derived from the hashes of the tarballs?
<civodul>the hashes are those of all the inputs of the build process, recursively
<civodul>we should really address that getcwd/MS_PRIVATE issue, BTW
<mark_weaver>I dunno, there must be a lot of other similar issues.
<mark_weaver>this particular one wasn't very serious. there's an easy workaround, and it only has to happen when bootstrapping on a new architecture.
<mark_weaver>actually, I'm quite impressed how easy and relatively painless this process has been.
<civodul>heh :-)
<civodul>"relatively painless" ;-)
<mark_weaver>I think we should warn people that cross-built bootstrap tarballs might have some problems like this.
<civodul>there's a very vague warning in the manual like "it may not work"
<mark_weaver>and we should consider cross-built bootstrap tarballs inferior, and only useful for the first-stage bootstrap to a new arch.
<civodul>not sure if we can really be more specific ;-)
<mark_weaver>despite the fact that it will set me back a few days, I intend to build new bootstrap tarballs for MIPS N32, natively, and then reboot from there.
<civodul>yes, that's probably a good idea
<mark_weaver>and a reboot has to be done anyway, because the new boot should be of core updates.
<mark_weaver>well, maybe. not sure on that last one.
<civodul>well Gnulib modules (among others) will behave better when building natively
<civodul>so that's one good reason to do that
<mark_weaver>anything autoconf related, really.
<civodul>OTOH, you'll probably get (almost) bit-identical results anyway
<civodul>because the bootstrap tarballs don't have much influence on the rest of the process
<civodul>as long as they "work"
<mark_weaver>civodul: on another matter: it seems that something in the patch phase fails to deal gracefully with UTF-8 filenames.
<mark_weaver>*non-ASCII filenames.
<mark_weaver>kbd-1.15.3 contains a file doc/utf/♪♬
<civodul>how does that end up being encoded by 'tar xvf'?
<civodul>locale-dependent i suppose?
<civodul>what if the locale is C?
<mark_weaver>well, all filenames in POSIX are really just byte sequences.
<mark_weaver>and the same is true in tar files
<civodul>i know
<mark_weaver>so tar doesn't even have to think about it, except for printing purposes.
<civodul>but what's the encoding used in the tar itself
<civodul>and what does tar do with that, if anything?
<mark_weaver>well, it all works here. I unpack with 'tar' and 'ls' and the file is shown correctly.
<mark_weaver>and if I use 'tar' to unpack with the C locale, it still works.
<mark_weaver>however, if I pass the -v option to tar, with it set to the C locale, then it prints the filename incorrectly, of course.
<mark_weaver>of course, if they unpack onto a system with the locale set to something else, the filename will be incorrect.
<mark_weaver>personally, I'm sympathetic to the use of UTF-8 in filenames, even in tar files for general distribution. it seems a shame to limit everyone to ASCII and english.
<viric>I remember as if pax required utf-8
<viric>spurious comment :)
<mark_weaver>pax specified that the filenames were to be interpreted as UTF-8?
<mark_weaver>I guess I'm tempted to say that the guile session that runs the build process should have its locale set to UTF-8, even though its subprocesses should probably be C by default.
<mark_weaver>or maybe it should be all UTF-8.
<viric>pax specified that the filenames had to be in utf-8 in the archive, I think
<viric>as storage format. Instead of a simple array of bytes. I may be wrong though; I remember something like that.
<mark_weaver>viric: I thought that PAX predated UTF-8.
<mark_weaver>viric: well, I see that the PAX POSIX std is relatively new, and indeed you're probably correct.
<viric>I don't remember the details.
<viric>I can't discuss POSIX much, I'm not a lawyer
<taylanub>Looks like it supports several charsets:
<mark_weaver>that same document says "The extended header records shall be encoded according to the ISO/IEC 10646-1:2000 standard (UTF-8)."
<mark_weaver>I think viric is correct
<mark_weaver>oh wait, I'm looking at a different version:
<mark_weaver>both versions include that statement about UTF-8.
<civodul>then tar is supposed to convert from UTF-8 to the current locale encoding upon extraction
<civodul>because file names are in locale encoding, as silly as it is
<viric>you talk about gnu tar, isn't it?
<taylanub>Pax seems to have an option to enforce non-interpreted binary, if that's useful perhaps tar can do the same ? Well I don't know about the portability of sophisticated tar options ...
<viric>I mean... is that kbd stored in gnu tar format, or in pax?
<taylanub>Does Guix depend on GNU tar ?
<civodul>GNU tar (the implementation) supports several format
<mark_weaver>civodul: I guess you're right, but even if tar were fixed, we'd still run into trouble using the C locale for the builds.
<gzg>mark_weaver: i actually was just about to mention this.
<civodul>taylanub: yes
<taylanub>Ah OK then, no crazy portability issues at least.
<viric>I remember linux tarballs are released in pax format, but that's unusual I think
<civodul>mark_weaver: BTW, kbd is not in the distro, is it?
<mark_weaver>gzg wanted to package it. that's how this issue arose.
<taylanub>viric: It's the standard archiver .. as opposed to the traditional. Difficult matter I guess. :)
<taylanub>(Tar is not in POSIX, funnily.)
<gzg>civodul: It's not, I was trying to work on it earlier when I ran into said road bump. :^P
<viric>posix only has pax. gnu tar can generate pax files, but it's not the default, I think
<mark_weaver>personally, I support the standardization of UTF-8 for POSIX byte strings. I don't see any other sane way to internationalize POSIX.
<civodul>gzg: could you post the failing build log to the list?
<civodul>so we can investigate
<gzg>civodul: Yeah, give me like 10 minutes.
<civodul>no rush, i'm at work anyway
<viric>why is utf-8 a build problem, btw?
<viric>are people required to have utf-8 in the locale, to build kbd?
<civodul>viric: if you use C programs, no problem, because C only knows about byte strings
<civodul>if you use a sane language ;-), things may go wrong
<civodul>as you had once reported with libchop
<civodul>in Guile a string is a sequence of Unicode code points, not a sequence of bytes
<viric>and are filenames strings, or sequences of bytes?
<taylanub>AFAIK they're byte-sequences in the filesystem/kernel level, and user-level applications can interpret them as they wish ?
<taylanub>At least with Linux and its typical FSs.
<civodul>but command-line arguments are strings
<civodul>and file names are typically passed on the command line
<mark_weaver>civodul: what do you think about running the entire build process in the UTF-8 locale?
<civodul>the result of readdir(2) & co. is interpreted in the current locale encoding
<civodul>mark_weaver: that's probably what we'll have to do
<viric>maybe command-line arguments should be byte sequences
<civodul>mark_weaver: i just wanted to see the log to make sure i understand what's going on
<civodul>viric: maybe not: how would you pass "Lluís" on the command line? :-)
<taylanub>viric: Well your keyboard sends characters and not bytes ...
<viric>civodul: strings are between bash and the terminal, not between bash and the filesystem :)
<viric>don't take as if I had a clear position. hehe
<taylanub>Well is ARGV really made of strings, or the byte-sequences which the shell turns its input into ?
<viric>byte sequences
<viric>noone interprets argv according to locale
<viric>that yes would be a mess
<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>anything else will be a terrible mess, I think.
<taylanub>To be specific, UTF-8 that encodes Unicode, right ? (Don't know if anything ever uses UTF-8 for anything else than Unicode.)
<viric>yes, unicode
<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.
<taylanub>Ah OK
<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.
<civodul>chicken-and-egg problem
*taylanub thinks it should all be Lojban. :P
<gzg>Okay sent.
<gzg>taylanub: That's actually my new-years goal, to learn a sufficient amount of Lojban. :^)
<viric>mark_weaver: ĉu ankaŭ vi parolas esperanton? :D
<mark_weaver>taylanub: fair enough, that might well be better, but then it would be even less realistic :)
<viric>civodul: kiel vi sukcesas logi tiom da esperantistoj?
<viric>I'm an esperanto opposer, though :)
<mark_weaver>viric: A few years ago I could have responded to that somewhat, but I never reinforced what I learned enough, and stopped practicing, and now I'm quite rusty.
<mark_weaver>it's embarrassing. I need to take up learning again.
<viric>I think that esperanto, due to its easiness, if popular, it would have devastated cultural differences
<civodul>what?! :-)
<viric>I think that the complication of English helped preserve the cultural diversity.
<civodul>that's a weird argument
*gzg has entertained the idea of eventually writing a scheme implementation around lojban in 3 or-so years.
<viric>I'm quite strong in that position
<civodul>we'll have to discuss this later ;-)
<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
<civodul>could be a few hours or so
*taylanub has yet to be enlightened on the benefits of connection to one's culture. Maybe because ey grew up in three different cultures: Turkish, German, Internetian
<gzg>taylanub: Where have you spent a majority of your life?
<taylanub>On BBS forums and IRC.
<gzg>taylanub: :^P IRL
<taylanub>:D Turkey
<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>mark_weaver: well, civil wars don't have language troubles, yet they exist.
<mark_weaver>I said "reduce", not "eliminate".
<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.
<viric>at least, not so relevant
<viric>that lack of communication can be forced by media, or all that, regardless of language similiarities or differences
<viric>I mean that I don't think that having a more spread international language usage would have a big role in that.
<viric>but we move in the field of forecasts; I can't prove much :)
<mark_weaver>indeed, these are difficult questions.
<viric>it's important that we all know the point of view of each other.
<viric>I think that in esperanto world there is too much propaganda, all too much biased to optimistic results
<viric>and I feel I've to balance that.
<viric>I mean it's not like the GNU thing. I agree that the more GNU, the better. hehe
<mark_weaver>indeed! :)
<mark_weaver>viric: for what it's worth, I'm sympathetic to the argument you're making. I certainly support diversity of thought and culture.
<viric>I've seen too much esperanto propaganda, in the lines of "throw away your language learning books! all will be easier with esperanto!"
<mark_weaver>I continue to believe that cross-cultural communication would prevent many wars from happening (but not all), and that this is more important.
<mark_weaver>but reasonable people may disagree :)
<viric>Against wars, I promote General Semantics learning :)
<viric>wars, quarrels, ..
<viric>which I consider *absolutely imprescindible* for life
<mark_weaver>I confess I'd never heard of General Semantics. I will have to educate myself on that.
<viric>read on the lines of Korzybski's works
<viric>some people derived from GS to NLP (Neurolinguistic Programming), which I consider an abomination
<viric>(for me, NLP means the usage of insights about how we function, for manipulation)
<viric>for abuse, not for teaching others and let them be protected against those problems.
<viric>People seem to learn NLP to abuse the lack of awareness, instead of providing awareness to others. All teaching of NLP goes in those lines.
<mark_weaver>very interesting
<viric>I even don't remember the wikipedia pages being fiar to General Semantics
<viric>but wikipedia articles change along time. There is no way to judge it ;)
<viric>I even wrote a program to check that wikipedia people don't modify *its history*. I can't trust those admins! I only found that they *removed latest versions*, never middle versions.
<viric>they should be using crypto to be protected against that, at the style of git or alike. But they don't.
<gzg>My list post still isn't up there ... but I'll let it run it's course and if not I'll try again 6 or-so hours, after some sleep.
<civodul>gzg: lemme check
<civodul>gzg: i've manually accepted it, so it should appear RSN
<civodul>normally that happens automatically, but i don't know at what frequency
<davexunit>a_e: hey, I took your advice re: libtheora
<davexunit>unfortunately, I only see requirements for ogg when I grep Requires *.pc
<davexunit>I moved libvorbis to inputs, as recommended.
<gzg>civodul: I'm not sure how soon, real soon is -- but 30 minutes after, I don't see it on the mailing list still. :^P
*gzg is going to nap/sleep a good 4 hours; He'll be back and go from there.
*gzg is AFK.
<davexunit>when I run guix build, will it use anything that I've installed via apt-get?
<davexunit>my machine already has everything needed for sdl via apt-get and I want to make sure that my build is completing successfully despite that.
<Steap>davexunit: no, Guix will not use stuff installed through apt-get
<davexunit>okay, I suspected so, but I wanted to make sure.
<civodul>gzg: this one: ?
<davexunit>libsdl built without any inputs... I don't quite know why.
<civodul>davexunit: yeah, it's completely safe-contained
<civodul>so if you want SDL, say, you must add it as an input to your package
<davexunit>oh great. then my package is almost done. :)
<civodul>sounds good :-)
<davexunit>did you mean the build was self-contained, or that SDL is self-contained?
<civodul>davexunit: the distro is self-contained
<civodul>so build processes only use what's in the distro, and specifically what is listed as inputs
<viric>what is the first videogame in guix? :)
<davexunit>viric: I'm not sure if any games have made it in, yet.
<civodul>davexunit: BTW, congrats on your first package :-)
<civodul>looks good to me, and a_e's comments make sense
<davexunit>thanks. :)
<viric>I wonder what videogames does RMS play.
<viric>can it be? none?
<viric>it sounds like saying that he does not watch any porn
<davexunit>okay okay, he's an obsessive nethack player.
<viric>that makes more sense :)
<davexunit>perhaps M-x tetris is more up his alley, though.
<Steap>viric: what Free video games do you play ? :p
<viric>I love neverball and xmoto
<gzg>civodul: You drug it out of me... :^) But no, it was to bug-guix about the kbd.scm issue with utf.
<civodul>gzg: bug-guix is a different thing since there's debbugs behind it
<civodul>so i don't think it can make things faster anyhow
<civodul>but it's only for the first post, so don't worry
<viric>civodul: a catalan saying: Guix i calç, tapen molts de mals. chalk and lime, cover lots of bad things.
<atheia>Guix is Catalan for lime?
<viric>for chalk
<atheia>(and I assume lime plaster/stone, rather than the fruit?)
<atheia>A I see
<atheia>yeah. Cool.
<viric>no fruit. is lime a fruit? :)
<atheia>Aren't they the green lemons? the small ones used for ceviche (for instance)?
<viric>and the plural of guix is guixos (wink wink).
<viric>atheia: ah. maybe.
<davexunit>how can I force guix to rebuild a package?
<a_e>If the inputs have not changed, there is usually no need.
<davexunit>I want to just start over completely.
<a_e>It will rebuild automatically with "guix build" and create a second package with a different hash.
<a_e>You can force as follows:
<a_e>$ guix build libtheora
<a_e>will output something like
<davexunit>it doesn't do the full build when I did that.
<a_e>Delete this with
<a_e>$ guix gc -d /nix/store/abcde...-libtheora-...
<a_e>It will only work if it is not used anymore, that is, not installed in a user profile.
<a_e>Then do a new
<a_e>$ guix build libtheora
<jeffrin>hello all
<jeffrin>is t possible to get stable release using git
<jeffrin>anyone here ?
<jxself>There is a tag for 0.4
<jxself>My thought would be : Yes.
<jeffrin>what do you mean by tag
<civodul>jeffrin: there are releases on, see
<civodul>it's better to start from a tarball than from a checkout
<jeffrin>i have compiled tar ball .. but i am trying to apply a workaround patch from latest git
<civodul>there's more info on building from a checkout in HACKING
<jeffrin>civodul : thanks
<jeffrin>jxself : thanks
<davexunit>I screwed up my /nix/store pretty bad
<davexunit>and now it won't build my sdl package at all.
<civodul>davexunit: can you post the error message?
<davexunit>guix build: error: build failed: getting attributes of path `/nix/store/7vx89qnvx748k9xnp1j61kv01mnqq64f-libsdl1.2-1.2.15-guile-builder': No such file or directory
<davexunit>in my desperation, I deleted a directory that I shouldn't have.
<civodul>which one? :-)
<davexunit>every one with libsdl in it
<davexunit>in /nix/store
<civodul>thou shall never do that :-)
<civodul>i don't think we have a simple way to recover from that
<davexunit>the more I know.
<davexunit>but I just couldn't get libsdl to rebuild.
<civodul>yes, because the SQLite db about that store has become stale
<civodul>so you could fiddle with it manually, to change its knowledge of the valid paths
<davexunit>sdl builds just fine without any inputs, but I suspect that it is disabling many features because of this.
<civodul>but that's not quite convenient
<civodul>because of what?
<civodul>does "guix gc" succeed?
<davexunit>civodul: because of not specifying the right combination of inputs.
<davexunit>yes, that succeeded
<davexunit>but then trying the build again failed
<davexunit>for the same reason
<a_e>In this case, I would simply delete all of /nix/store and the database (or more drastically, the directory in which you installed guix) and start from scratch.
<a_e>civodul: Is this too radical?
<a_e>davexunit: You should look at the screen output during the configure phase; it might tell you that configure looked for possible inputs that it did not find.
<davexunit>a_e: that's why I'm rebuilding :)
<davexunit>I think I fixed my error.
<davexunit>I deleted rows from ValidPaths for libsdl
<davexunit>in the nix db
<davexunit>looks like that worked :)
<davexunit>easy enough to fix my meddling.
<davexunit>time to go enjoy this nice fall day.
<civodul>a_e: apparently davexunit successfully fiddled with the db, so that's even better :-)
<davexunit>hey everyone
<davexunit>still working on my libsdl package
<davexunit>I found the nixpkgs version
<jxself>You're an X Unit named Dave?
*jxself looks
<davexunit>jxself: I'm not sure, honestly.
<davexunit>I made this internet handle when I was in 8th grade... and I stuck with it.
<davexunit>but yeah, that SDL package. I'm essentially trying to port it to guix.
<davexunit>it looks like I'll need to package libpulse first, though.
<jxself>Hehe. Those comments are interesting. Someone doesn't like OSS, it seems.
<jxself>It does seem that way, yes.
<davexunit>I'm not sure what configure flags I should maintain
<davexunit>I suppose I'll do the minimal amount of customization first
<a_e>davexunit: I suppose libpulse is part of pulseaudio.
<a_e>guix package -A pulse
<davexunit>a_e: oh. I guess I'm on too old of a version of guix
<davexunit>I'm on the v0.4 tag because I had problems with master.
<gzg>davexunit: Have you tired just pulling from stable, to the latest?
<davexunit>gzg: does that work well for development?
<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")'.
<davexunit>guix package -i <any-package> throws this
<davexunit>or guix build <any-package>
<a_e>Can you try HEAD again?
<davexunit>a_e: that's the result ^
<davexunit>not sure why v0.4 works just fine.
<a_e>Then run ./bootstrap ; ./configure ; make ; make install
<davexunit>maybe time for some git bisect
<mark_weaver>Hello Guix!
<davexunit>a_e: same thing
<davexunit>note that this error happens even when using an invalid package name: guix package -i totallydoesntexist
<a_e>Very strange.
<davexunit>going on a bisecting adventure.
<bavier>if my message to guix-devel doesn't show up in the archive, can I assume it didn't go through?
<gzg>bavier: How long ago did you send it?
<bavier>about 2 hours ago
<mark_weaver>mails from non-subscribers get delayed somewhat, I believe.
<jxself>That makes sense, to avoid spam from bots that aren't smart enough to first subscribe (and those exist.)
<bavier>mark_weaver: that might be it
<bavier>I'm subscribed at my work address, but sent from my home address
<mark_weaver>oh well. the fallout from spam is unpleasant...
<davexunit>did some git bisecting. bad commit: ac10e0e17e366d354ad8b3f91e03c1bdeddc7632
<a_e>It looks like you are mixing compiled old and new files.
<a_e>You did a "make clean" and a "bootstrap" and so on when switching to HEAD?
<civodul>davexunit: BTW the libtheora looks good to me, except for the missing commit log
<civodul>*libtheora patch
<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?
<a_e>The line number is not the same, though.
<a_e>In any case, it is not postgresql any more!
<civodul>a_e: i'll try to investigate further
<alip2890>when I search for dbus: guix package -s dbus; only dbus-glib shows up. why?
<mark_weaver>alip2890: that only lists packages in your current profile. maybe you want guix package -A dbus
<alip2890>that indeed works as expected. thanks! maybe the --help message should be made more clear
<mark_weaver>alip2890: yeah, I confess that it is quite unclear.
<civodul>alip2890: actually no, --search search all the available packages
<civodul>but it searches in the synopsis and description, not in the name
<civodul>so "guix package -s d-bus" works
<civodul>maybe that's a bug?
<mark_weaver>oh, interesting.
<mark_weaver>ah, it's because -s only searches the synopsis and description, not the package name.
<mark_weaver>and 'dbus' is not found in the synopsis or description of that package.
<mark_weaver>well, actually 'GDBus' does appear in the second line of the description.
<mark_weaver>oops, I retract that last statement.
<mark_weaver>but I guess maybe we should make -s search the package names as well.
*davexunit updated libtheora patch
<civodul>mark_weaver: yeah, probably a good idea
<alip2890>yay, xfconf tests pass!
<civodul>i know that feeling :-)
<civodul>what's xfconf?
<alip2890>the configuration backend for xfce
<civodul>ooh, neat!
<alip2890>it needed dbus
<civodul>BTW, do you know anything about GSettings?
<alip2890>I never played with it much
<civodul>i don't get what happens with Evince
<alip2890>what happens?
<civodul>alip2890: see the message on the list; basically it aborts because of some GSettings issue
<davexunit>civodul: thanks! no copyright assignment for guix?
<civodul>easy, warm, and friendly
<davexunit>I suppose the licensing is already as it needs to be.
<civodul>yes, GPLv3+
<civodul>the "+" means it'd be easy to upgrade anyway
<davexunit>unlike that one kernel...
<civodul>jxself: AGPLv3+, GPLv4(?), etc.
<jxself>That kernel could be upgraded. It's mostly a lack of desire, not lack of ability.
<civodul>jxself: though it would be very difficult in practice
<civodul>contacting all the copyright holders, etc.
<jxself>I once did some research into that and most can already be upgraded.
<jxself>It was either under a permissive license and already compatible, or was GPLv2+ already or no license was specified and any version could be used.
<civodul>oh, interesting
<jxself>The v2-only stuff was certainly the minority but I don't have the numbers anymore.
<civodul>ah right, because they usually don't put any license header
<jxself>It would take some work, sure. Everything does.
<civodul>so GPLv2+
<davexunit>self-contained builds = crazy long build time for SDL :P
<bavier>have user-facing package categories been considered for guix?
<civodul>bavier: not really
<civodul>we have it for GNU packages, but not for the rest
<civodul>and i'm not sure how to exploit it in UIs
<civodul>IOW, suggestions welcome :-)
<bavier>UIs are difficult
<bavier>we could include categories as a form of meta-data in package recipes for the time-being
<civodul>yes, but another question is: should it be categories, or generic tags?
<civodul>the latter seems more flexible
<alip2890>the module could already be considered a category
<civodul>yeah, but a package often falls into several categories
<bavier>generic tags would be cool
<alip2890>ah, I was thinking in terms of gentoo packaging, e.g. "gnome/evince"
<bavier>tags can get messy though if they're abused
<civodul>good night/day!