IRC channel logs


back to list of logs

<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
<efraim>so now I don't feel as bad :)
<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>against cross-base.scm ?
<phant0mas>but it's not pushed
<phant0mas>Ludo disagreed
<phant0mas>let me find it
<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
<phant0mas>did it fail even with libc present?
<efraim>libcilkrts is disabled twice in cross-base
<phant0mas>that's because Hurd does not support it
<phant0mas>but maybe I will need to move it to gcc.scm
<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>it will save you a lot of time!
<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
<phant0mas>efraim: :-D
<janneke>hi phant0mas!
<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?
<janneke>ng0: before 0.11?
<janneke>ACTION is just guessing
<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.
<phant0mas>janneke: not yet, I was working on Hurd
<phant0mas>soon :-)
<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 :-)
<janneke>haha :-)
<galex|713>janneke: why did you say guix isn’t ready yet for guildhall to be useless? I thought it worked?
<janneke>guildhall is still a TODO
<janneke>works beautifully in theory
<galex|713>janneke: you mean guildhall or guix?
<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>not sure what you mean by that?
<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>no, it's not like that...
<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
<efraim>now building bash minimal
<janneke>galex|713: not sure where you're going...
<janneke>guix is "just" another distribution, like debian
<galex|713>I know
<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
<janneke>ACTION goes afk for a bit
<efraim>isl won't build for aarch64 :(
<OriansJ>I just added another platform to the list of Stage0 systems
<janneke`>OriansJ: what does that mean?
<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>for example:
<OriansJ>if you were to write a simple hex compiler or just use this one:
<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`>stage0 is your hex assembler?
<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.
<OriansJ>It honestly is alot of fun, the creation of the ELF version for linux was what ultimately got me hooked.
<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>And even though it is still at the prototype stage, the example assembler is rather simple:
<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.
<janneke`>annotated assembly, that could work
<phant0mas>efraim: at all, or because my patch?
<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
<phant0mas>maybe it's time we update those :-)
<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...
<Sleep_Walker>but maybe you know some better way...
<mark_weaver>efraim: why would you want to do that in a snippet?
<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.
<mark_weaver>IMO, that doesn't belong in a snippet
<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>so only config.sub then?
<mark_weaver>I don't remember what the role of that file is
<efraim>i think it helps parse some of the config options
<efraim>or some of the returned values
<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>oh, great!
<mark_weaver>that's perfect, thanks :)
<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
<civodul>uh openldap fails to build on core-updates:
<sneek>civodul, you have 1 message.
<sneek>civodul, wingo says: yes i do
<civodul>you do what? :-)
<civodul>sneek: botsnack
***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
<mark_weaver>maybe related
<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>ah, good
<civodul>mark_weaver: could you eventually start a core-updates evaluation?
<mark_weaver>civodul: will do
<civodul>thank you