IRC channel logs


back to list of logs

<zimoun>This week-end, I have been to an exhibition about The ancient Art of Japanese Carpenters. There is one principle that resonates for me: if you cut a tree of hundred years, then you must build something with it that will stay more than hundred years. Sadly, that’s not the case with the world of computations…
<civodul>indeeed, interesting thoughts…
<rekado>it’s an old statement on sustainability. Modern capital theory as used to justify weak sustainability would frame it more liberally as “the sum of all forms of capital must not be diminished”. I do prefer the admonishment to only destroy when that is in the service of converting it into more value.
<zimoun>Well, one can easily measure “stay for X time”. Hum, what is “value“ may highly depend, no? Other said, how do you measure the “value”? The good ol’ carpenters made a one-to-one, which somehow removes the question, IMHO.
<zimoun>BTW, it is really interesting the knowledge they had for rock-solid connecting two pieces of hoods. I have been impressed by the precision of their cut. And their number of tools.
<rekado>yes, “last for X years” is easier to measure than value. But within the context of sustainability the value of a tree is more than the volume of its usable wood, so it’s not an exact conversion.
<rekado>joinery is awesome. I always sigh when I see pretty furniture and discover that it’s all bolted together instead of using joinery.
<zimoun>Well, I do not know if it is correct: I have read that Japanese carpenters developed such joinery because they had few iron and other metals. Keeping secret these techniques, transmitted from master to student over many generations. Then, once Japan had access to various metals (more or less one hundred years ago), all these techniques had almost been lost. What is instead it was not secret but as “free
<zimoun>software”? :-)
<rekado>it’s an interesting subject and relates to guilds, and the tangle of benefits and downsides that came with trade associations
<rekado>sorry, there are again 2000+ queued builds due to R upgrades:
<rekado>these packages hadn’t been updated for a long time due to a mistake in the importer/updater
<civodul>i’ll have to tell the bosses that we desperately need more hardware
<rekado>the more of these packages are moved to Guix proper the more this becomes an MDC problem :)
<civodul>we’ll end up begging Amazon to let us use a few VMs
<civodul>and display their logo on the web site
<civodul>and wear AWS t-shirts
<rekado>as long as the shirts are comfortable
<civodul>ah, see? they won already
<civodul>each of the 3 workers consumes more than 20 GiB per 12h
<civodul>it can’t be just R packages, right?
<civodul>i wonder if there are colleagues using the monolithic texlive package or something like that
<zimoun>civodul: I bet your colleagues produce “pack” :-)
<civodul>not on guix.bordeaux!
<zimoun>ah, so these 20 GiB are indeed unexpected
<zimoun>civodul: About the failure of old Python 3.7 (v1.0.0), are you running on AMD or Intel?
<civodul>but it’s a time trap
<civodul>i have WIP to make it easier to build in the past
<civodul>it’s already taken 10x more work than i expected though…
<zimoun>Even resetting the time in the past, one test fails.
<zimoun>Not for you?
<civodul>dunno yet
<civodul>we should take note of things of the past that fail to build, a keep track of when it failed
<zimoun>Hum, I have quick handwritten notes. And <> contains some usual culprits; for example, openssl, in the post at 1.1.1g and today I also hit a time bomb for the older 1.0.2p, twice even.
<zimoun>Ahah! Perfect timing with <> :-D
<rekado>weirdly enough I said something similar today in a group meeting at work
<rekado>(I showed guix-bioc and the question was about having the same for all of pypi, which triggered comments on the Python culture as it is reflected in artifacts on pypi and in the quality of dependency tracking)
<efraim>you'd have to sort also for only packages which support a given version of python, I've come across some in the past that were for python1
<zimoun>civodul: now I have Python 3.7.0. It just requires this one-line patch
<zimoun>There is no mechanism for patching “guix time-machine” right?
<civodul>zimoun: not for that, because it would then lead to different results
<civodul>we should investigate why that thing built in the past and no longer does
<civodul>make sure to keep track of all this! :-)
<civodul>our future: fixing past builds
<zimoun>yes for sure, it will be different. But for the case of Python, it cannot be the same. Without the patch, it cannot build because; as explained by their bug tracker <>. At least from my understanding.
<zimoun>Therefore, the only way is to apply the patch.
<zimoun>Well, what is not clear for me about this bug is: is it only some low-level kernel stuff? Or is it also because some chipset stuff?
<zimoun>civodul: <>
<zimoun>Well, I have just applied the patch (add it in v1.0.0 Guix checkout) and magically Python 3.7 just builds. :-)
<zimoun>Then, I have an ugly stacktrace about ui and Scheme time difference.
<civodul>zimoun: re XSAVE: 😱
<zimoun>Other Python similar bug report: <>.
<rekado>this looks like ENOSPC:
<rekado>“write error during file append”
<rekado>I think guix-bioc broke
<civodul>i think it’s just workers that run out of space very quickly
<civodul>and they sit idle when there’s too little free space
<civodul>is there something that might take space, like data packages?
<civodul>or stuff that depends on ‘texlive’?
<civodul>it would seem we’re consuming ~20G/6h in total