<ng0__>i think having that many packages on my host system does not help debugging guix on it.. i have resolved a bit by rewriting PATH, but it's still far from usable (plus 450 out of 1800 packages are still recompiling) with some applications ***fkz is now known as Guest34625
<efraim>i locally disabled libitm for aarch64, gcc-cross-sans-libc-aarch64-linux-gnu actually built and now its continuing on <efraim>i should look around more (I'M LOOKING AT YOU LINARO) and figure out how others built it without disabling libitm <efraim>one thing I haven't tried yet is building the cross compiler with only c and not c++ support <phant0mas>efraim: I had to disable "--disable-libitm" "--disable-libvtv" and "--disable-libsanitizer" as well for Hurd <phant0mas>this happens because c++ is enabled and the libc is not present <phant0mas>I have sent a patch to the list a long time ago <efraim>for aarch64 I could try pretending its just arm8-a, but I don't think thats the right way to do it <phant0mas>efraim: considering the problem is present in both aarch64 and Hurd we should disable libitm <efraim>i disabled it in gcc.scm as a configure flag <efraim>libcilkrts is disabled twice in cross-base <efraim>ah I missed the close-bracket on the first one <efraim>I'll let this finish building through, I think it's almost done, and then I'll move --disable-libitm from gcc.scm to cross-base.scm and see how that works out <efraim>and then cross build everything to test :/ <efraim>I really need to get offloading working <phant0mas>when you finish cross-building report it to the list <phant0mas>maybe then we can get the "--disable-libitm" "--disable-libvtv" and "--disable-libsanitizer" patch to be pushed <efraim>the best I have for a speed test is `guix pull', on my netbook its almost 12 minutes, on a 2007 macbook its 5.5 minutes <efraim>I should set up my overheating laptop, that should be much faster if it doesn't overheat and shut off <efraim>when I go to test the cross-building, i should go to bootstrap-tarballs or another target? <efraim>i see the thread now, it looks like it got dropped/forgotten a while ago <efraim>i bet it'd also speed up the cross building to have fewer libraries <efraim>i'll try it out with your patch and see how it goes <janneke>did you find any clue wrt the mingw-cross build failure rebased on master? <ng0>hm... when do you expect to merge current core-updates into master? <ng0>i was just wondering if it's a short enough (2 months or so) timeframe which is okay for not being able to use ed25519 keys.. so i can move the laptop also to guixsd. <janneke>ng0: what's keeping you from cherry-picking what you need from core-updates? <efraim>i think we aim for a core-updates merge once a month or so, this is very unusual to take so long <ng0>not being sure if I don't break things in the future when I run from git checkout.. i'm a bit uncertain in my own abbilities even if I know how this is not true :) <ng0>but i think i'll just try that. <ng0>more risk more fun.. and after all I want to toy around with extending the pull etc this year :) <ng0>having guix on gentoo is simply not fun. others can keep trying, i know it works, but rebuilding the host system, extrem case though when going from a hardened profile to a amd64/desktop profile, took almost 2 days for ~1800 packages <ng0>only reason for gentoo now: torbrowser. <ng0>and that should be doable in the future on guix. <janneke>phant0mas: i'm curious how you manage to gain insight on it, some things are opagque to me <phant0mas>lot's of caffeine and persistence to understand what's going on :-) <galex|713>janneke: why did you say guix isn’t ready yet for guildhall to be useless? I thought it worked? <janneke>guix needs an importer for guildhall, possibly to make guildhall obsolete <janneke>if you want to share a package directly with guix, you can do so and don't need guildhall. <janneke>i'm not sure what the preferred way forward here is <galex|713>janneke: do you think then guix could be used to automagically package stuff in debian? <janneke>in my view, guix is the end-all of all package managers, but then it would need to import from all other sources <galex|713>at least for unstable (I think they get automatically into testing after some time) <janneke>if you want packages *in* debian, you'll have to create .deb packages <galex|713>janneke: like you only need to know how guix work to have your package packaged into debian because it will do the job for you <janneke>if you package something with guix, you can install it wherever you have the guix package manager <galex|713>janneke: so either you get someone becoming debian maintener for all guix packages, either for some “groups” of packages in guix, either one debian maintener per guix package <efraim>phant0mas: gcc-sans-libc and gcc-cross both built with the patch, waiting now for it to compile on to aarch64 binary tarballs <janneke>galex|713: not sure where you're going... <janneke>guix is "just" another distribution, like debian <janneke>if your end target is debian, it makes little sense to go through guix <galex|713>But it *can* be linked to other distributions since you said on #guile it could import from pip, npm, etc. <galex|713>janneke: debian doesn’t automate stuff with scheme… <janneke>you can run the guix package manager on debian, just like you can run RPM on debian <galex|713>so most of stuff is shell scripts using C binaries using libs and when making anything you have to figure out if you make a shell script, write a C program or even a C library or in what proportion do the three, while with scheme you don’t have this problem <janneke>however, guix packages are entirely independent of its host <galex|713>janneke: also rpm is usually to use with a whole distribution while guix can be a lot more flexible than that (it could build stuff according debian binaries and even maybe in the future share binary packages between people) <janneke>galex|713: i said on #guile that guix wants to import from npm, pipi etc, it's being worked on <OriansJ>I just added another platform to the list of Stage0 systems <OriansJ>janneke`: The full trusted path bootstrap that I am working on, with the only binary required being a sub 512 Byte stage0_monitor which is able to self host itself written in commented hex. <OriansJ>The resulting binary could be written directly to a floppy disk and boot on any x86 system that was written to spec and be able to compile and run itself or other programs also written in hex. <OriansJ>In short I am trying to make the trusted base be only 512Bytes or smaller in size, then provide all of the bootstrapping functionality required to boostrap a proper assembler and C compiler such that one would be able to Compile GCC and thus make the trust chain provably correct <OriansJ>combined with a sub 64KB vm, we can reduce the total work for bootstrapping new platforms and expanding the space for detecting issues. <janneke`>so what platform did you add, and why -- i'd think if you have gcc on any platform, you can bootstrap any other? <OriansJ>The Knight architecture [With two paper tape drives :D], the idea being is that no single platform or hardware needs to be trusted or depended upon as all other hardware platforms should be able to check other systems' results. <OriansJ>In short, I am attempting to expand the problem space for a trusted trust attack to have to incorporate ALL hardware platforms ever made or could be made. [Including third party TTL designs] thus making it practically impossible. <OriansJ>And by explictly only allowing simple and well commented hex, assembly and C programs; I should have provided a simple pattern for others to follow if they wish to independently bootstrap their own version and independently verify any/all of the work I have done thus far. <janneke`>yes, I saw that one and ran it, pretty cool <OriansJ>The vm has a trivial build process, gcc -Os vm_instructions.c vm.c vm.h -o vm, I'm planning on trying to get people with weird hardware to verify some of the assumptions I have made. <OriansJ>It actually preserves the relationship between the produced Hex and the assembly instructions to make auditing trivial :D <janneke`>500 lines for an assembler is pretty nice...however that's going to be quite a program already in hex <OriansJ>Sadly true, but I do hope the code I wrote is trivial to understand. Anything that isn't trivially obvious is a bug that I need to correct. <janneke`>Yeah, it's not criticism, just an an observation of how quickly this `problem' can become tricky <OriansJ>janneke`: Actually, I enjoy informational criticism about my work. <OriansJ>Although I am considering to simply write a C compiler that produces assembly with its corresponding C code as comments. <OriansJ>It'll be extremely inefficient and produce poorly performing programs as a result but that isn't actually a problem for trusted bootstrap development. <efraim>phant0mas: I ran into this problem in the past with isl <efraim>isl-1.11 doesn't know what to do with aarch64 <OriansJ>janneke`: anything to make the bootstrapper's job easier. <efraim>now the fun part is trying isl up to 1.17.1 and cloog up to 0.18.4 to see if any of those combinations work <efraim>but the best might be to create a patch against isl-0.11.1 <efraim>i'm not actually considering it, but using the bundled isl in cloog would be the easiest option <efraim>First, CLooG is a LGPL software and library <efraim>oops, that'll have to be changed in our definition ***avph_ is now known as avph
<efraim>everything fails, even cloog with bundled isl, so i'm going to try cloog with gmp@6.0 <efraim>... and I just read the comment on gmp6.0.0a <rekado_>I just finished some soldering work on my X200s to make flashing libreboot easier. <rekado_>next week I'll try to replace the BIOS with libreboot. <rekado_>I wonder if I can still use my encrypted disk + LVM as is or if I need to do something before flashing. <rekado_>when using full disk encryption with libreboot the disk is unlocked before GRUB is reached, right? <rekado_>has anyone here switched to Libreboot *after* installing Guix? Or would it be better to reinstall Guix after flashing? <efraim>can I autoreconf as part of a snippet? <Sleep_Walker>do you use pinentry-curses, emacs in terminal, sign your commits and commit from magit? <Sleep_Walker>when I'm in this situation, I need to kill pinentry-curses and renew gpg-agent cache in another window... <mark_weaver>snippets are mainly for removing things from the source, like non-free things or large things that we don't want in our patches <efraim>isl-0.11.1 was released too long ago for its configure to recognize aarch64 <efraim>checking host system type... Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized <mark_weaver>efraim: I suggest adding a phase after 'unpack' that runs "autoreconf -vfi". we have many packages that do this. <efraim>as long as it doesn't affect the bootstrap process <lfam>mark_weaver: I tried cherry-picking onto master that grafting commit that you suggested, but it there was a merge conflict. So, I'll wait for your branch to be merged :) <mark_weaver>ACTION pushed a security graft for libxslt. get your updates! <lfam>Thank you mark_weaver! I was just reading that security advisory. <efraim>looks like automake needs isl to already be built, if I still can't get isl updated I may need to try patching config.sub and config.guess <mark_weaver>efraim: you shouldn't need config.guess, because we pass --build=<triplet> to configure by default <efraim>i think it helps parse some of the config options <efraim>it looks like that's where it would know what to do with aarch64 or not <mark_weaver>hmm, I wonder if civodul would prefer to graft the libxslt update in core-updates, or do a graft-free rebuild <lfam>mark_weaver: Did you notice 28b33172c (libxslt: Update to 1.1.29.) on core-updates? <mark_weaver>I'll do another merge of master into core-updates now, while it's fresh in my mind that I'll need to drop that patch. <lfam>Yes, I was going to say, "Add it to the check list" :) <mark_weaver>lfam: I rebased 'wip-graft-improvements' on current master ***lewo_ is now known as lewo
***mark-otaris is now known as mark_otaris
<sneek>civodul, you have 1 message. <sneek>civodul, wingo says: yes i do ***Ulrar_ is now known as Ulrar
<lfam>civodul: Do you think we should revert the bdb update for now? <lfam>Or, create a variant with the old version for openldap? <daviid>civodul: wingo has a copy of guile-sqlite3 git repo <daviid>the bot answered here a quizz quizzed on #guile yesterday ... <lfam>There was a newer version of the old series of bdb than what we upgraded from. We could do 5.3.21 -> 5.3.28, and let openldap try that <lfam>While keeping the latest bdb as well <lfam>I'll send a patch adding bdb-5.3.28 <mark_weaver>civodul: I see that efraim pushed an openldap update to core-updates since the last evaluation <lfam>He also added bdb-5.3.28 and made openldap use that <lfam>So, hopefully that works <mark_weaver>yes, it definitely looks aimed at addressing the openldap build failure <civodul>mark_weaver: could you eventually start a core-updates evaluation?