IRC channel logs
2014-02-27.log
back to list of logs
<JoshuaBranson>hello, I'm trying to build gtypist with guix. I've written a recipe for it, downloaded the tarball with "guix download <https://path_to_gtypist.tar.gz>". I added the output of that comand (the hash) into the recipe. I don't know what to do next. The recipe is in ~/programming. And the downloaded tarball is in "/nix/store/blah...blah...blah...gtypist.2.9.4.tar.gz". What do I do next? How do I build gtypist? <ph4nt0mas>mark_weaver: before I package glibc for hurd <ph4nt0mas>I managed to crossbuild it the normal way so I will prepare now a recipe for that <ph4nt0mas>I think I have understood what I need to do to make everything work <oiuuiu>civodul: I think I should be able to send a preliminary patch that would allow Guix to parse the Signature field of NAR info files today. <oiuuiu>civodul: I've been working on it for some time. And I'm currently writing the tests. <oiuuiu>civodul: I think I could use some help with Hydra since I don't speak Perl. Especially, if we're in a hurry. But I can try to do it myself; it shouldn't be too difficult. <civodul>i don't really speak Perl either you know ;-) <civodul>we can discuss if there are specific things that are not clear <oiuuiu>Let's postpone that until I have something concrete. <oiuuiu>Do you know when the recording of your FOSDEM talk become available? <oiuuiu>I checked yesterday; it wasn't there. <manolis1>civodul: the last few days I found out what I need to build glibc for hurd, and tomorrow I will probably send the patch for the hurd headers which glibc needs along with the mach ones <manolis1>but I have a problem with gnu mach.Its recipe builds successfully only If I invoke guix build with system=686 <oiuuiu>manolis1: I know nearly nothing about Hurd, but I seem to recall that it works only on i686. Is it correct? <manolis1>but I managed to build it the normal way in a 64 bit machine <manolis1>but I had to set some envs before calling config <manolis1>currently from what I know hurd doesn't support mips <oiuuiu>I suspect it would be very hard. <civodul>manolis1 & phant0mas are the same person right? :-) <civodul>so GNU Mach should build fine on x86_64 provided it has --build=i686-gnu in its configure flags, no? <manolis1>but the point is to manage to crossbuild the bootstrap files for hurd <manolis1>and for glibc I will have to use git-fecth <civodul>yes, using the libc repo at sv.gnu.org <manolis1>tschwinge is helping me a bit on that at #hurd <oiuuiu>manolis1: I wonder whether we should spend time on mips64el at all. I doubt that a lot of people use YeeLoongs. And the FSF endorse x86 laptops from Gluglug instead of them. I'm not saying we should concentrate on x86 either. If nothing weird happens, I suspect that ARM will become the next x86 in terms of adoption. More important, it seems that ARM can be used without any non-free software at all (search for the Novena project). <civodul>well, as long as there's interest in using and maintaining the mips port, that's fine <civodul>oiuuiu: dunno what's going on with the FOSDEM videos :-/ <civodul>they posted a call for help on fosdem.org <civodul>so it sounds as if nothing will happen if we don't volunteer :-( <oiuuiu>Sure. I'm just trying to say that time is a valuable resource. (And you have to think about the future in order to keep up.) <oiuuiu>WRT to the video, I'll try to figure out what's going on. <manolis1>the thing with mach on mips is that it used to work on it till one version <manolis1>so that could be a start for somebody to work on it <oiuuiu>You mean the previous version works on MIPS? <civodul>manolis1: really, it's not reasonable to even think about getting Mach running on mips <civodul>there's much more important work to do on the Hurd <civodul>like getting the x86_64 user space to work <manolis1>it was just something I was discussing with mark a week ago <manolis1>right now hurd needs as much help as it can get <oiuuiu>civodul: How can I "catch" 'leave'? It doesn't raise an error; instead it calls 'format' and 'exit'. <oiuuiu>Can it be done with Guile's 'catch'? <oiuuiu>Ideally, I'd like to be sure that I'm "catching" a particular 'exit' call, not all of them. But it may be tricky since 'leave' simply uses (exit 1), so I can't match on the status. <civodul>calls to 'primitive-exit' cannot be caught, but we don't normally use it <oiuuiu>Are the error keys enumarated somewhere? Until now, I've been aware only of 'system-error and 'misc-error. <civodul>i think they are documented in the relevant sections of the manual, but not in a single central place <oiuuiu>civodul: Is there a limitation for string constants in Guile? <oiuuiu>I'm keep getting the "end of file in string constant" error. <oiuuiu>Presumable because the string is too long. <civodul>oiuuiu: i think here it just means that there's no closing double-quote <civodul>there's a limitation in compiled files i think, but it's like 2^16 <oiuuiu>Why do the modules in 'tests' are prefixed with 'test-'? I can't import them with ,m presumable because the filenames don't match the module names. <oiuuiu>For now, I've simply replaced (test-my-module) with (tests my-module), but I'd still like to know the rationale. Is it needed to avoid polluting the namespace? <civodul>oiuuiu: yeah, i considered it safer this way <civodul>and i don't usually import them from the REPL <civodul>i sometimes have them from Geiser though <oiuuiu>But is there a way to import them from the REPL? <civodul>but it's easier from Geiser, although you sometimes have to comment out top-level format that try to directly connect to the daemon, stuff like that <oiuuiu>I don't use Geiser, sadly. I tried to make it work multiple times but always failed. <oiuuiu>Yeah, I can't jump to definitions, which is a pain. <civodul>normally the only thing needed to set it up is to set geiser-guile-load-path from ~/.emacs <civodul>and then you visit a Guile file, hit C-c C-k to compile it, and from there you have access to on-line doc, M-., etc. <civodul>sometimes jumping to the definition doesn't work correctly, because Guile 2.0 doesn't provide detailed source info for variables whose value is not a procedure <oiuuiu>Yeah, but when I was working on Guix modules, it couldn't find some of them. I had to visit each file myself and compile it. <oiuuiu>I have no idea what was causing the problem. <oiuuiu>I even reported it but didn't get a reply, IIRC. <civodul>well, it doesn't know about modules that haven't been compiled directly or indirectly <oiuuiu>Well, I assume that it can compile modules recursively, can't it? <oiuuiu>So, it failed to do so in my case. <civodul>so if you compile (guix base32), it doesn't know about other Guix modules, because this module is a "leaf" <civodul>however, if you compile (guix packages), then it knows about most other Guix modules <civodul>because they are compiled indirectly <oiuuiu>Is there a difference by compiling via C-c C-k or using 'make'? <oiuuiu>IOW, if I run 'make', will Geiser know about all the modules? <oiuuiu>(Just to make it clear, I understood your "leaf" example.) <civodul>well, until recently Geiser didn't set %load-compiled-path, so it didn't use pre-compiled files <oiuuiu>OK, I'll try it again. Hopefully, it'll work this time. <oiuuiu>civodul: How can I get the private key from the result of 'generate-key', so I could pass it to, say, 'sign'? <civodul>oiuuiu: 'generate-key' returns a "canonical sexp" containing both the public and private key <civodul>so you can then extra the private part using find-sexp-token <civodul>see 'generate-key-pair' in guix/scripts/archive.scm <oiuuiu>civodul: Should Guix be installed system-wide in order for Geiser to work? <oiuuiu>What's the smallest key length that's allowed by libgcrypt? <oiuuiu>I've seen "Fatal: can't generate a prime with less than 16 bits" <oiuuiu>And "ERROR: Throw to key `gcry-error' with args `(536870962)'." for "2:32". <civodul>i think i had problems below 1024 bits or so <civodul>that's why the test has a 1024-bit key, actually <kindahero>I am trying to install guix on Debian weezy. <kindahero>configure.ac:9: error: possibly undefined macro: AM_INIT_AUTOMAKE <kindahero>Copyright (C) 2013 Free Software Foundation, Inc. <kindahero>This is free software: you are free to change and redistribute it. <kindahero>There is NO WARRANTY, to the extent permitted by law. <kindahero>I had installed autoconf,automake in my home directory <mark_weaver>you configured them with a --prefix in your home dir, and installed them? <mark_weaver>well, it's obviously not looking in the right places for its macros. <mark_weaver>fwiw, I also built guix on wheezy, and I didn't have to install my own autotools. <kindahero>yes, I thought that. do I need to set any environmental variable? <mark_weaver>I probably installed a new automake from sid or experimental, though. <mark_weaver>automake doesn't have any other dependencies. it doesn't even have anything arch-specific, so it doesn't suffer from the usual problems of pulling in a bunch of other stuff. <kindahero>can we install desired packages from sid or experimental on wheezy. <oiuuiu>Well, it's probably a bad idea to fetch things over http. <oiuuiu>Even if nothing happens this time, it may happen in the future. <mark_weaver>fair enough. there's a better way and I don't have time to research it right now. <kindahero>Okay no I on my laptop (on which I am typing on) which has testing <mark_weaver>but I suspect that he downloaded the sources for automake and compiled them without checking the sigs anyway. <civodul>kindahero: alternately, you could try installing from guix-0.5.tar.gz (you don't need autotools in that case), and then install Automake & co. from that <kindahero>@mark yes i downloaded sources, as you expected didn't check the sig <kindahero>@civodul I will install from 0.5 source as you suggested. <oiuuiu>Depends on the definition of "update." <civodul>kindahero: it can update itself with "guix pull" <civodul>but you'll need to work from a Git checkout sooner or later <mark_weaver>(and "guix pull" doesn't do any signature checking either) <kindahero>actually I cloned guix, was trying from head <mark_weaver>but yes, anyone who intends to contribute to Guix will need a git checkout at some point. <oiuuiu>Good, civodul also uses magit IIRC. <mark_weaver>kindahero: if you intend to contribute to Guix, then IMO you might as well skip the step of building guix 0.5 from tarball and just install automake from debian jessie or sid for now. <kindahero>Yes, I remember installing firefox with pinning (from mint repos) <kindahero>just to let you know, I am not experienced user of IRC, apologies if I <kindahero>I will go and try to install guix first. Thanks. <mark_weaver>okay, good luck! let us know if you run into any problems. <mark_weaver>oiuuiu: I agree with you that we should encourage good security habits, and so I guess I should admit that I gave sloppy advice there, but otoh if you don't remind everyone to avoid using 'guix update' and to always run the daemon with --no-substitutes, then it's no better. <mark_weaver>in my own practice, I'm being much more careful about this kind of thing lately, but at present I have no good basis for security, I'm afraid. <oiuuiu>Don't take it personally, though. (I expect that you don't, but it's good to mention this anyway.) <mark_weaver>when I download tarballs that are signed, I now make a point of downloading the associated key from a keyserver and checking the sig, but I have no way of knowing that the key I downloaded is actually the right key. <mark_weaver>we're going to need to build a much more connected web of trust to improve this situation. <mark_weaver>and even something as security-minded as GNUnet, uses SVN instead of GIT, so if their subversion repo is compromised they probably won't even notice. <mark_weaver>we have a very long way to go before we have any hope of decent security, I'm afraid. <oiuuiu>Moreover, most people (myself included) have terrible security habits. Even if you're sure that the key belongs to Joe, you can't be sure that Joe's key is kept in secret. <oiuuiu>How many people rotate their keys or use smartcards? <mark_weaver>yes, good point. I was going to mention that, but I could go on for hours about this and need to stop somewhere :) <mark_weaver>most developer machines are probably not particularly secure at all. I'm sure the NSA can get into at least 99% of them, if they choose to do so. <mark_weaver>so we can't trust the signing keys anyway, and even if we could, they are signing code that mostly just came from the repo. they don't have time to audit all of the code before every release. <mark_weaver>with the scale of software today, it's obviously not even close to feasible. <oiuuiu>Yeah, I wanted to make this point but deleted the message. <mark_weaver>hence, the Kremlin has switched back to using typewriters, which is very wise. <oiuuiu>I think the discussion has gone into the wrong direction since security is about the threat model. If you're being targeted, there's very little you can do. <mark_weaver>well, unfortunately they are targetting everyone nowadays. <mark_weaver>I need to think about these things, because I'm in the position where I'll likely be setting up build machines that produces binaries that many people will use. <oiuuiu>By "being targeted" I meant something like acoustic cryptanalysis. <mark_weaver>and I occasionally build bootstrap tarballs, as so on. <mark_weaver>so I suppose it would make sense for them to target me, so that they can then ensure that a large set of machines that use the binaries I build (directly or indirectly) are compromised. <mark_weaver>I don't know, I get depressed whenever I think about this stuff. <oiuuiu>Indeed. But as viric says (paraphrased), "It's important to be in a good mood." <oiuuiu>So don't get depressed; approach the problems one by one. <oiuuiu>For instance, you could start by securing your communications as much as you can. <mark_weaver>I've been putting effort into this recently. you may have noticed I've upgraded a bunch of crypto-related packages in guix recently. I've also started using tor for more things, including web browsing and chat (notice the output of /whois mark_weaver) <oiuuiu>It's a shame that Freenode requires users to register in order to use it. <mark_weaver>but you don't have to tie the identity to anything in the real world. I don't see a problem here. they have to cope with the fact that they are under frequent ddos attacks and the like. <oiuuiu>There is a solution, though. You could try to pay for a VPS anonymously which you'd access through Tor. Then you could access Freenode from the VPS. <oiuuiu>Indeed, but in order to register you have to provide an email address, which is an additional complication. <mark_weaver>so instead of registering with freenode, you're effectively registering with a VPS. <oiuuiu>Have you tried to create one while using Tor? <oiuuiu>You could go to an internet cafe or something. An additional complication, again. <mark_weaver>well, it's a one-time thing. once you've registered the account that way, you can then use it from wherever you like. <oiuuiu>Sure, but there are other problems. For instance, it's trivial to gather who's hiding behind a "virtual" identity if you have enough data. <civodul>oiuuiu: well, for instance, i know who you are :-) <mark_weaver>I don't think it's really feasible to hide who you are. the best you can hope for is to make it harder to find out where you're connected from. <civodul>in practice we're not trying to hide who we are, because that'd make collaboration harder <civodul>we could use pseudonyms though, and some people do <oiuuiu>I'm not using a pseudonym because I don't think that people should be afraid to speak up. <civodul>oiuuiu: it's more that it would allow you to decouple (say) your Guix activities from other activities <civodul>like you could be contributing to Trisquel under a different name ;-) <oiuuiu>mark_weaver: It's still possible to guess your location based on the pre-Tor logs if you don't travel too frequently. <oiuuiu>Anyway, I seen on point of discussing this further. <oiuuiu>Since each of us is aware of the mentioned problems. I'd rather talk to people who aren't. <mark_weaver>I don't really care about my own anonymity, fwiw. I'm a very public person. I only do this to create more cover traffic for those who legitimately need anonymity. <mark_weaver>well, not just cover traffic, but to make more people who they would have to put extra effort to spy on. <ph4n70m4s>if I use --system=i686-linux it builds just fine <ph4n70m4s>if I don't even though I am passing --build=i686-gnu <ph4n70m4s>in order to build it normally in my 64 bit machine I had to set some env vars before calling configure <ph4n70m4s>I tried passing them as cflags, cppflags and ld flags <civodul>ph4n70m4s: could you paste the build logs? <ph4n70m4s>but I managed to fix it by setting CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' <civodul>hmm, did you forward it to #hurd already? :-) <civodul>the full log, including configure parameters *civodul posts a news item to recruit GSoC students <ph4n70m4s>civodul: tschwinge gave me some hints, looking into them now <ph4n70m4s>civodul: I will package the hurd headers now <dsfsdfs>waxysubs: FYI, the bootstrap tarballs are being fetched via http. <dsfsdfs>civodul: ^ alpha.gnu.org supports https. <civodul>davexunit: BTW, cool that you got mpd packaged! <davexunit>civodul: thanks! now I need to get some clients packaged. <davexunit>just haven't had the time. work is crazy and so is everything else I have to do before I get to hack. <ph4n70m4s>civodul: glibc needs the headers from mach and hurd <ph4n70m4s>so I should start with this so we can bootstrap guix for debian-hurd for now <civodul>i think the first milestone should be to get cross-compilation to GNU/Hurd running <civodul>being able to test on Debian will be cumbersome, and won't buy much anyway <ph4n70m4s>so I should first package everything to build <ph4n70m4s>right now I am studying a old cross build script from tschwinge <ph4n70m4s>if we make glibc work for hurd we will be able to boostrap guix <civodul>actually we want to "cross-bootstrap" <civodul>meaning cross-building Guix's bootstrap binaries, with "guix build --target=i686-gnu bootstrap-binaries" <civodul>so that means also adjusting cross-base.scm (the cross build core) so that it knows which libc to use, etc. <civodul>cool, sorry for repeating myself then :-) <civodul>ph4n70m4s: when you're done with the Hurd headers, please check with youpi et al. how the Hurd's libpthread must be handled these days <civodul>i think it's a glibc add-on now, but wasn't when i did the Nixpkgs thing <teythoon>i'm curious how you plan to procede once you have hurdish bootstrap binaries <civodul>that is, we cross-build statically linked binaries for GNU/Hurd <civodul>when we have those binaries, we can "inject them" to proceed with native builds on a GNU/Hurd machine <civodul>i think ph4n70m4s will have to bother you some more before we get there ;-) <teythoon>though i know nothing about building the libc *tschwinge does... More than he ever wanted to. ;-) <civodul>the main thing that worries me is that libpthread add-on, since i haven't followed since that change was made <tschwinge>Yes. That is high priority to get resolved. Well, high priority "in theory"... <civodul>that may actually simplify the whole process <tschwinge>Anyway, not tonight. I just wanted to look in and say hello. Now that ph4n70m4s has bugged us "enough" in #hurd. ;-)