<kyamashita>quiliro: Is the package broken or the network transfer? <quiliro>guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/5fh6p3ywchsjp4zphyy6vlqpf80i72lz-e2fsck-static-1.42.13.drv' failed <grillon>Yeah!!!!!! My neovim is fully working. But I used virtualenv and the distro-python to achieve this. <quiliro>but many package downloading with --fallback <kyamashita>e2fsck-static works fine when I upgrade. It may be a i686-specific issue if it is not the network. <kyamashita>OriansJ: I have a faint feeling that I've seen this repo before. What type of assembly is this using? <OriansJ>kyamashita: Knight assembly, it is part of the stage0 bootstrap <OriansJ>kyamashita: Every piece is written targeting a platform independent VM that produces identical results on all hardware platforms <OriansJ>it started with just a 280 byte Hex monitor and has grown a text editor, line macro assemblers and other extremely useful bootstrapping programs <kyamashita>OriansJ: It's cool to see projects trying to address the bootstrapping problem. <OriansJ>kyamashita: Actually, since the vm implementation is based upon actual running hardware (made out of TTL logic), it will solve it forever once done <OriansJ>In the mean time, however the VM is only 41KB when stripped to the core or 98KB with all the bells and wishes on linux <OriansJ>For a grand total of only 5039 lines of C code <OriansJ>But for the bells and whistles version using gnu getopt and X11 logic, it is unfortunately bigger :( <OriansJ>(5171 lines of code inside of the stage0 but still) <kyamashita>I'm sure people can eventually code golf the finished implementation. <OriansJ>kyamashita: possibly and the work this week involves building its first compiler <OriansJ>also, I'm waiting on Janneke's feedback on how I can improve my lisp to better bootstrap his MES compiler <kyamashita>Software development is still young, I'm sure we'll make the Maxwell's Equations of Software better over time. Right now, making bootstrappable and reproducible software is difficult enough. <OriansJ>kyamashita: actually it is trivial to do given the constraints of the VM used in Stage0 because it becomes impossible to add any randomness. <OriansJ>You have a program rom, a source file and a destination file and every single instruction is perfectly deterministic <kyamashita>But you started the project with that in mind (and thank goodness you did). Not all projects do that, as many patches in the Guix tree indicate. <OriansJ>kyamashita: sadly true, I honestly can't imagine why people shove things like time stamps and random garbage into their programs <OriansJ>Yeah, I get malloc is slightly faster than calloc and when file systems didn't support time stamps your build system might need to shove it into the binaries <OriansJ>but aside from legacy reasons, could there even be an excuse for that behavior anymore? <kyamashita>I'm not sure, as I am the evern00b. However, I imagine there are plenty of places to stick metadata these days. <OriansJ>kyamashita: you are absolutely right but how much metadata does one really require in a binary program? <kyamashita>Maybe projects could supply a "--build-reprodicibly" flag or something like that if they want metadata in the code by default. <OriansJ>kyamashita: having thought about that for a bit; I don't think there is any valid technical reason, when given a specific compiler, source code and build command that the result shouldn't always be identical. That being said, only defects/variations in the compiler, build command or source code should change the outcome. Since guix allows us to perfectly always use a specific compiler, exact source code and build command, the remaining <OriansJ>reproducibility bugs have to do with the source code interacting with non-deterministic defects in the tools themselves. <OriansJ>The places I most find non-deterministic behavior are: floating point, when malloc is used instead of calloc, using randomness from outside sources (say reading from /dev/urandom) or performing fuzzy optimization tricks (the dumbest idea in the history of compilers if you ask me) for a 1-3% performance boost under ideal conditions. <kyamashita>OriansJ: Interesting that you bring up floating point. I haven't thought about that before. <OriansJ>kyamashita: haven't you noticed that x86 implicitly converts 32 and 64 bit floats to 80 bits and rounds it back for storage? <OriansJ>it is a side effect of the design of the x8087 coprocessor <kyamashita>OriansJ: I read recently about something like that. <kyamashita>I need to read some CPU and instruction set manuals. <OriansJ>kyamashita: There are even weirder rounding rules when you get into IEEE floating point support <efraim>is that why we sometimes have rounding errors in math libraries for non-x86_64 architectures? <OriansJ>There have been cases where minor variations floating point hardware and ordering make results order of magnitude different. <OriansJ>efraim: It could definitely be the cause, as floating point is the best performance way to deal with large/tiny numbers <OriansJ>efraim: Oh yeah, that is a floating point calculation size assumption bug <kyamashita>Darn. Just took a look at some physics, and it looks like infinite-precision real numbers are not physically attainable. <OriansJ>kyamashita: There are few things in this universe that require more than 42 digits of precision and all of them are programs <OriansJ>But honestly, if you are trying to optimize for performance your tests need to be better informed of the reality that not all hardware is x86 <OriansJ>And if you are a compiler writer and you put floats in your code, you should be beaten <kyamashita>I can't find where these timestamps are coming from!!! (hunting through a haskell package-to-be) <OriansJ>kyamashita: Where are the timestamps being written? <OriansJ>If it is in the ELF header, check the compiler <kyamashita>Directly into the binary, but it's not in the ELF header. <kyamashita>They all seem to be after subdirectory names from the source tree though. <kyamashita>Excepting the "--version" flag related code that I've already corrected. <OriansJ>kyamashita: have you tried stubbing functions to find which of them it could be in? <kyamashita>Stubbing functions? Like replacing a function with a "dummy" version? <OriansJ>kyamashita: It is my last ditch solution to finding non-deterministic code. Works every time but is a massive pain for big programs <OriansJ>Basically find the main and start removing trees until it builds reproducibly, then work your way down the tree and repeat until you find the function where it exists <kyamashita>Oh wow. I think I missed an obvious aberration. I thought it was dead code, but apparently not <kyamashita>Time for another reproducibility check. Hopefully the rest of the huge differences between the check builds were downstream from this one. <OriansJ>kyamashita: If the code is dead code, it should be deleted code. If we ever need it back, it can be reverted or studied and reintroduced. <kyamashita>The program is Darcs, and the suspicious code is something like "#define darcsBug(__FILE__,__LINE__,__TIME__,__DATE__)". The file was small and unassuming, but I'm going to... <kyamashita>Definitely not dead code; the build just failed. -_-' <brendyn>Since there are only 3 symbols that are different <efraim>not that I know of for trivial-build-system <brendyn>if i use a let statement outside package, will inherit copy that over, then i can use another let to overshadow it? <brendyn>i suppose it doesn't even matter if it isn't copied over. but i havent seen a let used like that before <kyamashita>brendyn: I see (substitute-keyword-arguments (package-arguments wpa-supplicant-minimal) used in some packages. Maybe you can use that? <efraim>we normally end up with just define for that case, but I think it's fine with that level of substitution <kyamashita>Well, that comes from admin.scm specifically, but that pattern appears. <brendyn>it seems making it a procedure is a mistake? ***jonsger1 is now known as jonsger
<ZombieChicken>Anyone here have experience using menu-entries in grub-configuration? I seem to be having some problems getting it to see another distro's kernel and initramfs <ZombieChicken>Specifically, I'm having a problem with it not accepting it as a list, and I'm not sure where I'm screwing up at ***jonsger1 is now known as jonsger
<marusich>Even though my LANG environment variable is set properly to en_US.utf8, Python seems to think everything is ASCII. :( <marusich>I have no idea why, but the result is that programs like youtube-dl won't save files with non-ASCII characters, which is super dumb because my locale is en_US.utf8 and thus it can support all Unicode characters! <marusich>Does anyone know why something like this might happen? It's very frustrating. <roptat>also 1.0 is not compatible with the gpl, but the software still has a double license <marusich>Regarding my earlier statement, it seems this might be some kind of regression in youtube-dl. <marusich>I still don't quite understand how Python is getting its locale information, but it seems an older version of youtube-dl does not exhibit the problem I'm experiencing, so it must be a regression. <ng0>I finally picked up the kallithea branch again, and I'm fixing up the test suite now <ng0>okay. I can just use it like this... pypi-uri already has a version to use <amz3`>it seems related to what guix pack does or something like ostree not sure <amz3`>except guix pack doesn't handle sandboxing <ofosos1>this problem occurs when i use the mirrors as well as when i directly use hydra. something broken in source code pro? <amz3`>ofosos1: doesn't it mean the mirror is corrupted? <ofosos1>i think so, but it's hydra *and* the mirror <roptat>other packages are also corrupted in the same way <grillon>I have started to read guix manual. seems a very nice package manager. I have spend a day to make neovim pass the checkhealth command but it s worthwhile <efraim>ofosos1: did you try adding --fallback? <ofosos1>efraim: it appears to do it, i'm going to have some ice cream :) <ng0>does someone use gajim here? would you know if there is something not obvious to keep in mind when you install the extensions systemwide with a package manager? is the very obvious thing I fail to see that gajim needs to know about the paths? <ng0>i started with a "catch them all" package for guix as there's a reported upstream bug for the single extension tarballs <ng0>because they are not getting picked up I think there mustr be some way to communicate their store path to the parent package, gajim ***kelsoo1 is now known as kelsoo
<ng0>uh.. funny. the maintainer of cairo-5c just told me its testsuite requires the bitstream vera sans font. iirc we don't have that, right? <alezost>ng0: there is "font-bitstream-vera" package <ng0>oh. okay, I'll try with this <ng0>okay, now the improvement is that this font does not exactly match the one the testsuite wants <rekado_>ng0: I use gajim occasionally. I don’t know about where it looks for plugins, but the source code should give you some hints. <ng0>it's python based, and I've just seen the main application has a wrap phase <ng0>so at least one other distribution is interested in it <rekado_>ng0: we can use a git repository, though. <ng0>it would just be nicer to not have all addons but a selective choice <rekado_>this can be done with “inherit”. You can create one package for one plugin and then inherit from it for all other plugins. <ng0>yeah I don't know if it's worth the lines of code to remove all but the (package-name) folder everytime <ng0>it's like 30 or 40 plugins <ng0>all i wanted was omemo <Azna>i have to manually add 'insmod luks' and 'cryptomount -a' to grub.cfg, and the system hangs while booting <Azna>the file system labels used are checked in /dev/disks/by-label to be correct, as well as the uuids <ng0>i think there's a bug I opened on this <ng0>if you can deal with one partition, and mount the other one later I'd suggest this as a work around <Azna>ng0: could this be done with a service? or do you mean manually? <ng0>eventually someone will fix the bug, but for me it's not grave enough as I can boot from one drive and mount when I need others <Azna>ng0: i'll try that, thanks ***mo is now known as Guest57900
<piotr>I'm trying to boot from the USB stick. I've followed instructions in the manual. Everything goes smoothly and at the end I get a partition named "gnu-disk-image" with flag "boot". Sounds good. When I mount it it's a classical GNU / Linux root however when I reboot the key isn't recognised by my laptop so I'm unable to install it :'( Any ideas how I could solve that? <Gamayun>Could just be a funky bios if everything else looks good. I have a netbook that will only recognise images on about half my usb sticks.. :/ <sapientech>trying to use offload facility, got to `guix offload test ~/.machines.scm` but getting: guix offload: error: failed to load SSH private key from '/home/sapientech/.ssh/id_ed25519': Unable to import a key from the file <sapientech>this is the ssh key i use to connect to the build machine <sapientech>and i only have an ssh key for the user. does this mean i have to make an ssh key for my root account and connect that way? <piotr>Well, I tried with Ubuntu on the same stick and it worked like a charm :/ <piotr>How could I get a iso file from the archive provided by guix? <pmikkelsen>do you know why emacs never can find my fonts after i run guix gc? I'm on guixsd by the way <piotr>Where do you set Emacs font? <sapientech>update: is it because this key is passwd protected? <kyamashita>pmikkelsen: Usually I upgrade my packages after garbage collecting. That tends to resolve the issue for me.