<ng0>I'm pretty sure nix originally is jiddisch <ng0>1780-90; < German: variant of nichts nothing <jlicht>this is getting ridicilous: `(define public node-babel-plugin-transform-decorators-legacy' <efraim>I have my aarch64 bootstrap tarballs, now I need to trim down the isl patch from 1.2MB to a minimum of necessary changes <efraim>autoreconf -vfi made a ton of changes, all to add aarch64 support <ng0>We have no arm64 support yet, only armhf. So I don't need to include that aspect in building firefox, do I? <efraim>i wouldn't worry about it at this point <ng0>ok, so i guessed right. thanks <efraim>i still have to stick it in my arm64 boards <civodul>maybe you can test the binaries with QEMU <efraim>and my patch against isl is just autoreconf, i'm trimming it down now to just adding aarch64 <efraim>I should try that, that'll be a fun test to bring my machine to its knees :) <wingo>are there aarch64 server boards now? <efraim>phant0mas_: I'm about to bump your patch on the mailinglist, that was a big help <ng0>it feels stupid to use guix in a bash script to get a name - hash list of languages.. but you have to start somewhere ***pksadiq` is now known as pksadiq
***kelsoo1 is now known as kelsoo
<rekado>ng0: what do you mean by “name - hash list of languages”? <rekado>for most things you could probably also just use Guile directly <ng0>still learning guile, so a shell script in bash using the guix binary in the end is good for a start <ng0>you can always rewrite later <rekado>why would you need to use Guix in there? <ng0>"based on" was wrong <ng0>I want to automate the process of guix download $xpi-uri so that the results can be put into corresponding packages <rekado>FWIW I find it easiest to learn things by just doing them and failing. <ng0>me too, but for now I want to use bash. the weather is just not very friendly for continuing with learning by doing <ng0>i think a practical approach could also be to extend guix download.. guix mozilla-download $product to get all languages and the hashes of the individual files of a mozilla product. <ng0>that script would be useful for icecat too, it's just lang: en at the moment? <rekado>I don’t think we should extend Guix for a particular product. That’s what Guile can be used for, using Guix as a library. <ng0>I wonder, can this be done at package runtime, or do we need to have static hashes? <ng0>before buildtime i mean <ng0>batch downloading works.. but the hashes <ng0>it could be a function in the firefox/whatever.scm, which then gets called in the firefox package <ng0>but otoh, having someone who checks the shasums and not just a script would be prefered. <ng0>but the iso languages are so many. <ng0>for 45.2.0esr: ach af an ar as ast az be bg bn-BD bn-IN br bs ca cs cy da de dsb el en-GB en-US en-ZA eo es-AR es-CL es-ES es-MX et eu fa ff fi fr fy-NL ga-IE gd gl gn gu-IN he hi-IN hr hsb hu hy-AM id is it ja kk km kn ko lij lt lv mai mk ml mr ms nb-NO nl nn-NO or pa-IN pl pt-BR pt-PT rm ro ru si sk sl son sq sr sv-SE ta te th tr uk uz vi xh zh-CN zh-TW <ng0>things are so much easier with everything in one dir and not the folder tree view one level above that one <ng0>temporarily, as a local solution, this could be a one line wget + run guix hash on that afterwards script, or a curl with range + guix download on the cat of that. <ng0>and i thinx guile would be shorter and smarter. <ng0>oh. no wildcards in http supported. grml <phant0mas>efraim: when we get the all good from civodul, I will push the cross-gcc patch to core-updates-next <efraim>I pared my isl patch down to just the aarch64 changes, now have to build out to the bootstrap tarballs again :( <efraim>its not the end of the world, I still need to free up my external hdd for the arm64 boards and actually install an OS on them, so I have some more prep to do <ng0>i dislike this solution with wget -r, many cd's, rm's, and a final for f in... guix hash ***pksadiq` is now known as pksadiq
<efraim>in my isl patch I left in code for big-endian aarch64 ***pksadiq` is now known as pksadiq
<yoosty>question regarding your E-mail and "The problem is that these files are included in the manual, so it would seem awkward IMO to give the section name here." <yoosty>not sure I understand that.. would a URI be more appropriate or is there some logic error that I'm not seeing? <yoosty>also, that one-liner seems pretty useful, would that be appropriate in the manual somewhere? (e.g. guix.html#Using-the-Configuration-System ) <civodul>yoosty: what i meant is that i make the (optimistic) assumption that people read the manual <civodul>in that case, they see the example configuration inlined and surrounded with explanations <civodul>it would be awkward, while you're reading "Using the Configuration System", to see a comment say "See 'Using the Configuration System'", wouldn't it? :-) <civodul>davexunit: what have you been doing? ;-) <ng0>o_O i just built a software which only functions in gdb and segfaults outside of it <orbea>i hate that, build debugging symbols just to find it only segfaults outside of gdb... <sankey>if i specify guix package --no-substitutes , does it make sense that the script will still update the list of substitutes? <Steap>Hum, I cannot push on ssh://steap@git.sv.gnu.org/srv/git/guix.git , is this a known issue? <rekado>phant0mas: do you happen to have an idea about why my arm cross-compiler isn’t quite working? <rekado>I looked at the changes to the AVR toolchain for inspiration, but nothing seems to apply. <rekado>phant0mas: I first thought that the reason why my binaries didn’t work was because I didn’t use the exact same version of the toolchain. <rekado>it’s also a good way for me to *see* whether the binary will work or not. <rekado>some binaries are bit for bit the same. <rekado>others (those that don’t work) are not. <ozzloy>sneek later tell thomasd yeah! i'm a big fan of steven pinker <ng0>rendering the the full graph with full dependencies of libreoffice and their dependencies brings cairo to its limits. I was curious about the limits.