<mekeor>what are you, OriansJ`` and janneke working on? <OriansJ``>mekeor: we are solving the bootstrap problem by reducing it down to a single 280Byte hex monitor <OriansJ``>so literally starting with just that single binary, build EVERYTHING required to bootstrap GCC and guix, etc <OriansJ``>mekeor: thus far, we have built all the way up to a rather nice forth (thank you reepca) and a compacting garbage collected lisp <mekeor>how many binaries do we currently use/require to build GuixSD? <OriansJ``>MESCC is itself going to be bootstrapped by stage0 <OriansJ``>stage0 is going to have only 1 required binary (280bytes in size but trivial to reproduce with a hex assembler) <OriansJ``>mekeor: and every step is bit for bit reproducible by default <OriansJ``>we don't even need an operating system for stage0 and different cpu architectures (arm, alpha, MIPS, SPARC, etc) all produce identical results too <mekeor>i can't really imagint that actually <OriansJ``>and with bank switching a 6502 can also verify every step <ng0>wow, the rust testsuite is long <ng0>finally I'm back to compiling what I wanted to compile in the first place <ng0>huh <- why yak shaving? <catonano>ng0: it's a way to say I heard in Berlin. When you start doing a task and you realize there are defects in the libraries, the compilers, so you start doing something absolutely unrelated to your original task: yak shaving <ng0>I thought you meant something I was doing <ng0>I know what yak shving is :) <catonano>OriansJ``: I am impressed by your feats ! But I was referring to one of the questions on the page of that incredible board that you linked <catonano>I made the decision to use guile-bytestructures in my guile-freexl and I feel relieved <catonano>tonight, I made some progress and I'm elated :-) <OriansJ``>catonano: personally I'm annoyed that gcc doesn't have proper Big/Little Endian data or output support <OriansJ``>because sprintf only outputs in BigEndian order <catonano>OriansJ``: I see. But you decided to go through this all by yourself :-) <OriansJ``>catonano: I do what I must to solve the trusting trust attack problem in our infrastructure. <catonano>OriansJ``: I used to play with a c64 and that moster thing is moving me <OriansJ``>rain1: the really nice thing about janneke's recent commits is by enabling ELF sections to work with HEX2, he also enabled them for M0 as well. So we are going to have excellent support for x86/amd64 <OriansJ``>as you can see, it is trivial to add new instructions (a simple DEFINE) <OriansJ``>so, assuming you don't screw up the encoding (definitely possible with x86 weirdness) of the Definitions, we have the simplest x86 assembler in existence that also supports all x86 instructions <rain1>this is a perfect way to get off the ground <rain1>I was looking into amber, it only depends on an assembler and linker (no libc or high level languages) <rain1>and it builds up to a very reasonable high level language (something that would be fine to implement a mini-guile in) <rain1>but hacking it to emit our assembly instead of the gcc assembly syntax seems like too much hard work <OriansJ``>rain1: well we already have a lisp and a forth that are very straight forward to implement <OriansJ``>but in all likelihood, I'll probably end up having to implement another program to fill the gap but I'm not worried about it. This entire project is enormous amounts of fun. <rain1>it's great, i think this is a very solid foundation <OriansJ``>rain1: My view is the foundation isn't done until we can build gcc, linux, binutils and grub <rain1>yes there is a very long way to go <OriansJ``>mind you, this assembly is good enough for me to hand write a garbage collecting/compacting lisp or a reasonable forth <OriansJ``>or with about 5 months of effort, a C compiler at the level of C500 <jamesrichardson>I installed libreoffice earlier today, I think it ended up compiling it. When the app opens all the letters look like boxes. Is this a font issue, locale issue, compile issue or user issue? Don't really know where to start troubleshooting. <reepca>Presumably for non-libreoffice stuff you see non-box characters? <reepca>I'll try installing it and see what happens after I update <OriansJ``>sneek: later tell janneke he can still use gdb to debug the MESCC_Tools hex.M0 prototype. Simply readelf -h test/results/test1-binary to get the entry address, b *0x600078 and layout asm should allow you with stepi/nexti to single step the assembly in a reasonable fashion. I can provide more if he wants. <boskovits>I am trying to get guixsd in a vm since sunday. <boskovits>It seems however, that linux-libre 4.4.47 xz tarball was removed. <boskovits>I tried to change the url to the lz one, but lzip is not installed, so that is not working. <boskovits>Next I tried to use the installer image, but in the guix system init phase I get substitute: updating list of substitutes ... all the time. <reepca>boskovits: we actually heard about that linux-libre issue just earlier today, check the logs for more information <reepca>out of curiosity, have you tried running the command that generated that linux-libre error recently? <boskovits>I once let it run overnight to see if it is making any progress, but it filled up the device with log and failed with no space left on device. <boskovits>ok i will check it out if it still persist, last night I did a run, and there was a problem then. <boskovits>It seemd xz tarballs were removed up to 4.4.62 from upstream when I last checked. <boskovits>I'd also like to know, why the efi partition comes to the second place in images. <boskovits>It is difficult to resize the vm image this way... <sneek>Welcome back janneke, you have 2 messages. <sneek>janneke, OriansJ`` says: that I have a present for him. (a hex assembler written in M0 for AMD64) <sneek>janneke, OriansJ`` says: he can still use gdb to debug the MESCC_Tools hex.M0 prototype. Simply readelf -h test/results/test1-binary to get the entry address, b *0x600078 and layout asm should allow you with stepi/nexti to single step the assembly in a reasonable fashion. I can provide more if he wants. <janneke>that's very good news, very cool OriansJ`` <reepca>Question, in the guile code, when we say "pairs", do we mean ("key" . "value") or ("key" "value")? <efraim>I've been told the first is called 'a dotted pair' so it could be both options <janneke>reepca: i think it rather means: (car . cdr) than "key" "value" <jsierles>i'm trying to get guix working again after the recent issue with 'guix package' hanging forever. I followed instructions from the bug report, which suggested to download and build guix without substitutes. however the build consistently fails: building of `/gnu/store/k5zxs6rfyqsx292i1vzl1y3k3jwnlcj4-python-3.5.3.drv' timed out after 3600 seconds of <jsierles>not sure why it needs python and ghostscript. is there another way I can get guix working again? <janneke>jsierles: you must build without substitutes? that's unfortunate, what's the bug report? <rekado>jsierles: is this still a problem? <rekado>jsierles: civodul said that “guix publish” hung, which may have caused this substitute error. <jsierles>rekado: you mean downloading substitutes? <rekado>have you been able to figure out which substitute(s) it is hanging on? <rekado>e.g. by strace -p the-substitute-pid <jsierles>strace is the same I posted in the bug report <jsierles>not sure how to see which substitute though. <rekado>have you tried removing the substitute cache? <jsierles>yup working now. thanks! i guess then there was an issue with publish, so i got some corrupt substitute? <jsierles>is there a way to know why a grafting was required? <jsierles>and curious why a package would be built locally, for example r-minimal-3.4.0 for which there seems to be a substitute available remotely. <reepca>jsierles: there's a flag for some derivations that indicates that they should be built locally (LOCAL-BUILD?) <reepca>although "offloading" and "substitutes" might be separate concepts now that I think about it <reepca>they do sound very related, though. Anyway, that flag in particular is for "small derivations where the costs of data transfers would outweigh the benefits". <jsierles>building R doesn't seem to have that flag <jsierles>just wondering if there's a way to directly check whether package would be built and not downloaded. <jsierles>i see --dry-run tells me which would be built. <jsierles>but not why it would be built instead of substituted. <civodul>jsierles: if it's built that's because there are no substitutes <rekado>jsierles: grafting is always done locally. <civodul>thanks for pushing the xmonad update that mekeor[m] had posted <civodul>i must have borked something back then <efraim>i sent my updated glibc patch to the bugs maillinglist <civodul>efraim: awesome, thanks for working on it <civodul>i see mark_weaver also pushed a kernel fix to increase the stack-guard page <efraim>And I'm pretty sure we're safe from the sudo one <jsierles>civodul: ok - how can I check if a substitute exists or not? <civodul>jsierles: "guix build foo -n" should do <efraim>Unless there's grafts, in which case you need <efraim>civodul: just saw 81e3485c0d012e29d4e551107fc31c0da89b0006, that seems obvious in retrospect <efraim>civodul: looks like master's broken ERROR: ERROR: Wrong type to apply: #<syntax-transformer manifest-entry-dependencies> <reepca>OriansJ``: Next on the list of things I might get around to is fixing CREATE. <OriansJ``>reepca: that certainly would make it more ANS compliant <jsierles>why is everything in the store set with unix epoch creation time? <sneek>Welcome back ng0_, you have 1 message. <sneek>ng0_, reepca says: It seems that the radeon hd 6450 does not work with linux-libre. Firmware fails to load, no 3D acceleration, one display output only, and a very messed up one at that. On the bright(?) side, I get to write a strongly-worded letter now. ***ng0_ is now known as ng0
<jsierles>sorry, i mean does the daemon need to also set specific permissions on files in the store? <jsierles>i'm having an issue mounting the store into a docker container, so looking to see if it's related to that <jsierles>is there a package that provides a ca-certificates.crt? <jsierles>i have some issues using the built-in julia package installer. it has various deps of course to compile. one of them is zlib. I've installed this but guessing julia needs a path set somewhere to find it. <rekado>jsierles: for the record: nss-certs provides certificates and bundles. <rekado>jsierles: I have never used the built-in julia package installer. <rekado>but I would be surprised if it used cmake <rekado>(I should update our julia package) <rekado>looks like the gajim tarball has been changed in place :( <mekeor>rekado: are you sure about the gajim tarball having been changed in place? if so, i could write them an e-mail saying that that's not nice for reproducible package managers <rekado>mekeor: I got a hash mismatch for it. I will try again. <ng0>rekado: no problem here <mekeor>what does this mean?: "guix package: error: profile contains conflicting entries for xmonad:out" <rekado>mekeor: do you also get this when using “guix package -u ghc-xmonad-contrib”? <rekado>with a recent change Guix tries to anticipate conflicts before installing. <rekado>installing a package that you already have in your profile would be detected as a conflict <rekado>(even though Guix chooses to upgrade rather than install) <mekeor>rekado: cool, works, thank you :) <mekeor>rekado: "guix package -i ghc-xmonad-contrib" and "guix package -u ghc-xmonad-contrib" both work. but adding --dry-run makes it fail <rekado>adding “--dry-run” makes “-u” fail as well? <efraim>I got a conflict for gzip when I ran 'guix environment guix -- make' <civodul>efraim: ah, now it's getting interesting :-) <efraim>guix environment: error: profile contains conflicting entries for gzip:out <efraim>From Guix GC --referrers the second is all guix-latest and profile <efraim>The first is actual guix builds, profiles, and a few packages I've built <civodul>efraim: the problem is that 'guix' has a direct dependency on gzip, but it also has an implicit dependency on gzip <civodul>and those two gzips are not the same <efraim>I generally git pull and then guix env guix -- make <quiliro>2 days ago I left a core 2 duo machine installing with guix system init /mnt/etc/lightweight-desktop.scm /mnt --fallback <efraim>I can try guix env guix on my other aarch64 machine too <quiliro>I checked today (but I understand that yesterday the installation stoped) <efraim>I wonder if 'guix environment --ad-hoc glibc' would conflict between glibc and glibc-final <quiliro>error (ignored) cannot close compressed log file (BZip2 error = -6) <efraim>The other board gave me the same error, with the same paths <civodul>quiliro: could you paste the whole command and its output? <quiliro>guix system: error: build failed: writing to file: No space left on device <quiliro>I cannot paste...I just typed it manually <quiliro>you mean I copy what I just typed on a single paste? <quiliro>the exact command was 'guix system init /mnt/etc/lightweight-desktop.scm /mnt --fallback' <efraim>'Guix env --ad-hoc glibc' didn't give me any problems <quiliro>and df -h shows that /mnt has 102GB free <civodul>quiliro: i think we already discussed this a couple of days ago, but i don't have any more clues :-/ <efraim>How much space is left on the device you're installing from? <civodul>efraim: i pushed a hot fix for 'guix environment' <ng0>we should do something with which <ng0>WARNING: (gnu packages version-control): `which' imported from both (guix build utils) and (gnu packages base) <efraim>Sorry, I think that was me when I fixed CVS-fast-import for aarch64 <ng0>cool. I'll check later <rekado>tried updating Julia to 0.6, but the documentation requires some Julia packages. <rekado>so I’ll probably disable building the documentation until we have a way to build Julia packages <rekado>I have a question about input rewriting <rekado>I want to install propeller-development-suite but with propeller-gcc@4 <rekado>I tried “--with-input=propeller-gcc=propeller-gcc@4” but I always end up with the latest propeller-gcc. <civodul>rekado: with inputs rewrites dependencies, but no the leaf itself <quiliro>grub-install: error: /gnu/store/...-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory. <quiliro>guix system: error: failed to install GRUB on device '/dev/sda' <dadinn_>I am trying to bootsrap guix on in pristine empty root directory, but my issue is that there is no bash in the initial root profile to chroot into <quiliro>if you do not have have bash, you must have another shell <dadinn_>quiliro: I see certtool, geiser-racket, gnutlscli, guix, guix-daemon, idn, nettle-hash,ocsptool,srptool binaries <dadinn_>the hash of the root profile I se is 6dyps02rrsyjy76lyqfvw5w5h... <dadinn_>ahh, I see there is a newer one already <dadinn_>quiliro: was this any issue then, and fixed by now? Sounds a bit unlikely to me... <civodul>dadinn_: by default the profile at /run/current-system/profile has Bash <dadinn_>with version 0.13 i am getting an error during signature verification <dadinn_>it says "Can't check signature: public key not found" <dadinn_>before that I fetched the signature wich seems it was successful <dadinn_>actulaly it says unchanged, therefore the one I had before for 0.12 must have been the same <dadinn_>if I do gpg --list-keys BCA589B63655... <dadinn_>it will list pub and sub: pub is 2048R/235FACAC, while sub is 2048R/B8BFFBE5 <mekeor>Q: how do you close a bug on debbugs? <dadinn_>I am not much of a gpg-ninja unfortunately :/ <quiliro>why do I get 'grub-install: error: /gnu/store/...-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.' <dadinn_>civodul: what is worrying is what i am doing works perfectly for 0.12 but not for 0.13 <dadinn_>civodul: ok, it seems to me that the gpg signing key has been changed between version 12 and 13 <dadinn_>13: 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 <dadinn_>12: BCA689B636553801C3C62150197A5888235FACAC <dadinn_>ahh, it seems the key for 13 verifies both 12 & 13 <quiliro>how to define EFI partition on boot-configuration? <rekado>BCA689B636553801C3C62150197A5888235FACAC <dadinn_>civodul: back to the problem of sh/bash... how do you have /run/current-system/profile? guix only has too directories at /var/guix and /gnu... there is no /run/anything if you chroot into it <dadinn_>chroot /mnt/instroot/ /bin/sh ... this fails too with no command '/bin/sh' <rekado>mekeor: you close a bug by sending email to 1234-done@debbugs.gnu.org <rekado>dadinn_: these directories exist when you boot into GuixSD <dadinn_>rekado: my problem was that I was experimenting if I could bootsrap guix like debootstrap <dadinn_>I wanted to chroot int a root environment without relying on a host system <dadinn_>rekado: but there are no bash/sh binaries in the root profile <dadinn_>obviously even if that worked it was a question whether there are necessary kernel/grub/cryptsetup/luks/zfs/etc packages available to install and set up the system to be bootable... but that's another question, I suppose the answer is no at the moment <dadinn_>rekado: but that was my intent, reason i am looking for a shell to chroot into at least <dadinn_>janneke: i mean literally /bin/sh link to /gnu/store definitely doesn't exist <rekado>dadinn_: if you have *booted* into GuixSD these directories will be created. <rekado>dadinn_: in the /gnu/store you may have a *-system/ directory <rekado>it should contain everything you need <rekado>and you might get there more easily through /var/guix/profile/system <dadinn_>rekado: 0.13.0 only has /var/guix/profile/per-user/root directory <mekeor>rekado: are bugs reopened automatically when you send another mail to 123@debbugs.gnu.org (where 123 is the bug id of a closed bug) ? <dadinn_>rekado: in /gnu/store i do see a bash-static-4.4.12 <dadinn_>rekado: what's the difference between bash and bash-static? <dadinn_>janneke: actually i got it with `chroot /mnt/myroot /gnu/store/...-bash-4.4.12/bin/bash <quiliro>'bootloader (grub-configuration (device "/dev/sda") (grub grub-efi)))' and 'bootloader (grub-configuration (grub grub-efi) (device "/dev/sda")))' don't work...replaced them with: '(bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (device "/dev/sda")))' <quiliro>the first two options need ( at the start <quiliro>i used them when testing but i did not type them on my comment <quiliro>'(bootloader (grub-configuration (device "/dev/sda") (grub grub-efi)))' and '(bootloader (grub-configuration (grub grub-efi) (device "/dev/sda")))' don't work...replaced them with: '(bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (device "/dev/sda")))' <dadinn_>janneke: I have another problem still though, that the root profile does not contain most necessary binaries like ls, ln, mkdir, etc <janneke>dadinn_: if you want those, you need to install coreutils in the root profile <dadinn_>janneke: while the binary install manual refers to setting up the root profile amoung the first steps, but even creating the symlink to it is impossible without ln <janneke>if you boot guixsd, those are part of the system profile, which has %base-packages <dadinn_>janneke: ok guix is in the root profile, so I can use that <dadinn_>ahh, but the guix-daemon will not work <dadinn_>untill i can create the buildusers and group <civodul>looks like Inkscape fails to build on master <quiliro>with the example EFI configuration file on that link <quiliro>(bootloader (grub-configuration (grub grub-efi) (device "/dev/sda1"))) <quiliro>(file-system (device "/dev/sda1") (mount-point "/boot/efi") (type "vfat")) <quiliro>should I guix pull befor guix system init? <quiliro>In proceedure module-lookup: Unbound variable: grub-efi <quiliro>(bootloader (grub-configuration (grub grub-efi) (device "/dev/sda1") )) <rain1>janneke: how do i try to compile 8cc using mes? <janneke>../mes/guile/mescc.scm -I . -I ../mes/mlibc/include cpp.c <dadinn_>janneke: still struggling with the chroot issue. I would have to create the guixbuild group and the buildusers before I could chroot into the fresh guix install to install coreutils <earthfail22>hello guys, I'm new to guixsd like I'm today installing it and it failed a couple of time but now it is installing but taking alot of time is it normal? <janneke>dadinn_: what about adding /gnu/store/*-coreutils-*/bin to PATH? <dadinn_>janneke: is it intentional that this works differently from debootstrap which with it is possible to configure a whole system by chrooting into it? <civodul>earthfail22: it can take some time, depending on the config you're installing <rain1>janneke: okay! So it says ./8cc.h:312: parse failed at state 326, on input "va_list" <rain1>I could try to remove va list from the code then <rain1>does that sound like a reasonable thing to try? <janneke>rain1: va_list is not really supported yet by mescc, but printf is supported, see mlibc/libc-mescc.c <janneke>rain1: printf has va_list special-cased <rain1>so building 8cc would get us a new c compiler that supports valist and anonymous unions <janneke>how many functions use va-list? if only 1 or 2 you could steal from printf <janneke>otherwise we'll have to think about upgrading printf's hack to real va_list <civodul>earthfail22: is it building things instead of downloading pre-built binaries? <rekado>earthfail22: do you see it printing a lot of lines? <rekado>earthfail22: that would indicate that it’s compiling things rather than downloading binaries. <quiliro>is there some suggestion to my error? <mekeor>"In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f" <mekeor>i got it with "guix package -u" and "guix system reconfigure …" <rekado>mekeor: if you’re using Guix from git try “make clean-go && make” <rain1>this is tricky, im not suer i can apply the hack in this case <rain1>i also considered unrolling it to create f0 f1 f2 f3 f4 <rain1>but that may not be enough, they can have different types