IRC channel logs
2013-10-24.log
back to list of logs
<Steap>can I see how much of a file has been downloaded already ? <mark_weaver>doesn't it show the download progress? it always has for me. anyway, if you can find the PID of the download process, then you should be able to see where the file is in /proc/<PID>/fd/ and then look at how big it is. <mark_weaver>the download process will be running guile, of course. <Steap>mark_weaver: no, because I use guile 2.0.5 <a_e>This is the source of the erroneous uri: I downloaded the tarball using wget and installed it in the store manually... <mark_weaver>sometimes I get a very slow mirror. it would be nice if the mirror was chosen more intelligently, or if people could easily configure which mirrors to use. <a_e>How about you copy-paste the url and use wget or curl? <Steap>can I just copy that to the store at /nix/store/hash.tar.gz then ? <Steap>and after that, run guix build ? <a_e>No, then you execute "guix download file:qt...tar..z" . <a_e>I think it also needs to be registered in the sqlite database, which is done by "guix download". <Steap>Or well, I could edit the recipe <Steap>to have the url point to /home/cyril/whatever <a_e>"guix download" also puts the file into /nix/store/...; so then you build normally, "guix build qt-4.8.5". <a_e>mark_weaver: Guile 2.0.9 is compiled on my mips machine. Wish me luck with guix... <Steap>I think I'll send the patch to Nikita <Steap>and if it does, well, what the hell, we'll push it <Steap>Anyway, everything is already broken :D <a_e>Steap: A perfect occasion to repair pulseaudio first ;-) <Steap>a_e: yeah, looks like one test is failing <a_e>mark_weaver: Building guix finished successfully! <a_e>But I think you forgot to register the patches in dist_patch_DATA in gnu-system.am. <a_e>They are found with ./pre-inst-env, but not when invoking guix after "make install". <a_e>Leaving now, good night or day! <a_e>I must be one of the rare people who do a "make install"! <a_e>So far, I compiled glibc and binutils, and now I am in gcc. <a_e>If everything goes well, we should apply the necessary patches to core-updates! <a_e>How many hours are forever? <mark_weaver>I don't know. it makes me wish that timestamps were printed as part of the "@ build-started" (etc) lines. <a_e>And we compile several of them, right? <mark_weaver>I tried to figure it out from the output of "ls -ltr $PREFIX/var/log/nix/drvs/*/*", but that didn't seem to work, for some reason that I don't understand. <a_e>By the way, did you advance with your goal of natively built bootstrap binaries? <a_e>I think these will be the ones we would like to reference in core-updates/ <mark_weaver>oh, nevermind, I was thinking about it the wrong way. based on the timestamps of the logs, I guess gcc takes a little under 22 hours. <mark_weaver>a_e: these bootstrap binaries that we're both using are natively built. <a_e>Okay, then I can stop it now as well. I will need to turn off the machine tomorrow morning. <mark_weaver>first, I produce cross-built bootstrap tarballs, which had some issues. and I used those to build native bootstrap tarballs. so this is my second time bootstrapping. <a_e>Good, so these are already the "final" bootstrap binaries. <mark_weaver>oh, well, I just hibernate the machine in the middle of compiles. <mark_weaver>in fact, that calls into question that time estimate. <mark_weaver>I don't know how much of the machine was off during those ~22 hours. <a_e>Right, one can restart, the pleasure of make files! <mark_weaver>hibernate while it's in the middle of building, and when you resume it continues from where it left off. nothing special needed. <a_e>I am connecting to the machine from my laptop, which I need to carry to work and back. <a_e>So I need to log off, which seems to stop the daemon also. <a_e>I could use screen, probably. <mark_weaver>run everything within 'screen' and then detach the session. <a_e>Sorry, I am not concentrated. Without screen, I need to do it all in one go. <mark_weaver>ah, my 22 hour estimate was indeed pessimistic. I see another gcc built where it took much less. closer to 18 hours. <mark_weaver>I hibernated my computer quite often during the builds. <viric>mark_weaver: use the world famous 'ts' <viric>I can't use a computer without it. Since years :) <viric>I didn't add it. I haven't contributed yet <viric>but for a guix master, it should be a one minute addition <viric>I queue tasks all the time. wget downloads, builds, video conversions, ... <gzg>virtualenv, imaging, and cssselect builds. I need to get lxml working before mediagoblin is ready. *gzg isn't exactly the sure with python-lxml, but it won't build with Cython. <Steap>gzg: I think we already have libxml, and it builds the Python bindings <Steap>a_e: can you confirm this ? Iirc, you packaged libxml <Steap>gzg: I can confirm this myself :) Take a look at gnu/packages/xml.scm <Steap>it probably does not build with Cython because it's not Python3-compatible <gzg>Steap: Oh cool; But the expressions I have force python2. :^P <Steap>well anyway, you don't need to package python-libxml <Steap>oh, lxml and libxml are 2 different things <Steap>I got mixed up between those 2 <gzg>Steap: Do we have Cython packaged? And yes, sec. <gzg>Doesn't look like it is. <Steap>gzg: yeah, but it seems like this can be built without Cython <Steap>I think the errno occurs because the Python script might be trying to use a path like '/usr/bin/whatever' instead of /nix/store/... <Steap>you should try and print the whole command that is executed <gzg>Steap: The whole log? <Steap> File "/tmp/nix-build-python-lxml-3.2.3.drv-0/lxml-3.2.3/setupinfo.py", line 275, in run_command <Steap> stdout=subprocess.PIPE, stderr=subprocess.PIPE) <Steap>take a look at what happens in setupinfo.py <Steap>a command is run using the 'subprocess' module <Steap>but this command probably cannot be found *gzg really needs to stop starting things, when he's on the verge of passing out... <Steap>Yeah, it looks for xslt-config <Steap>one way to solve this would be to call setupinfo.py with '--with-xslt-config=/path/to/xslt-config' <Steap>or set the XSLT_CONFIG environment variable <gzg>Added it as a note, I'll get to it eventually. :^I <a_e>gzg: Concerning filenames, if you build a library for python 2 and not python 3, it should be called python2-libraryname. <a_e>See chapter 6.3.4 of the documentation. <a_e>Steap: Yes, libxml2 contains the python bindings. <gzg>a_e: Okay, I'll changed that before I forget -- thanks. <a_e>gzg: It looks like with your packaging, you double the number of packages in the distribution ;-) <a_e>How about sending them to guix-devel to get them included? <gzg>a_e: Oh, relative to Python? <a_e>No, altogether. Well, just joking. <a_e>But I remember you mentioning lots of packages here. <gzg>a_e: Yeah, I've been starting a lot -- and probably shouldn't wait so long to dump them. :^P <a_e>Even if it is just a helper package for something you really want, it would probably be useful to have them in the distribution; and motivating; and getting feedback also helps for the next package. <gzg>Yeah, I get you -- I'll try to be better about that and upload some patches this weekend, then. <a_e>Sounds nice, looking forward to them!