<OriansJ>Based on previous input on the level of assumption made by my last attempt at lower level bootstrap binaries, I present a bootstrap that only requires basic 8086 system with IBM compatible BIOS <OriansJ>It supports line comments and with only bios level calls, it should be a reasonable base <ajgrf>OriansJ: nice! i don't even know enough assembly to understand it but i'm very excited about your project <ajgrf>OriansJ: what does stage 0 get you once you've run it? <OriansJ>a simple hex monitor that supports line comments and runs the hex code you typed when you press Ctrl-d <OriansJ>For example if you were to type 68007cc3 it would load in the instructions push 7c00 and ret which would jump to the address that the bios loaded the mbr in this case this program <OriansJ>I'm currently using it as a basis of a bigger version that writes those bytes to a second floppy disk, thus allowing a true bootstrap capability <OriansJ>Which I'll end up extending until it provides the features required for a barebone C compiler ***imrekt is now known as imr
<grpala>I stumbled upon guix after reading some articles about nixos. Even though I've been using nixos for like a year, but I've only just barely managed to survive in it, haven't had the time to invest time in learning nix for real, though I have in my TODO list for when I do have the time. Anyway, it wouldn't hurt to ask how do you guys compare guix to nix (first thing that I noticed (and I liked) is the s-exp <grpala>syntax. Nix's syntax always puts me off. <grpala>s/to invest time in/to invest into/ <mark_weaver>OriansJ: fwiw, I would go further and avoid requiring a BIOS, since that is another rather large pile of compiled code that you must trust. <mark_weaver>I was thinking of starting with a coreboot payload, and I would call that stage 1 (or perhaps even a higher number), with the idea being that coreboot itself is stage 0 <mark_weaver>so that would take care of gnarly things like raminit <mark_weaver>stage 1 would talk directly to the hardware, and specifically to a serial port <mark_weaver>serial port hardware is typically extremely easy to drive, and there's also very few serial chips in active use. <mark_weaver>and serial terminal devices can be made very simply as well, without even using a CPU. <mark_weaver>and this way to avoid requiring things like video drivers, keyboard drivers, USB drivers, etc. <mark_weaver>those can come later, after we have the ability to write code in a semi-decent language <janneke>OriansJ: how much work would it be to write a minimal lisp compiler in hex? <mark_weaver>janneke: OriansJ seems to have chosen to start with a C compiler <janneke>it would be nice if scheme could be bootstrapped without c, do it the other way around <janneke>i really like what you're doing, OriansJ! ***kelsoo1 is now known as kelsoo
<calher>I notice something. The third 'alternative' does NOT do what the explanatory text says: " Run the daemon, __and__ set it to automatically start on boot." <alezost>I guess you mean that "manually" doesn't mean "automatically". As for me the explanation is clear, but the patches to improve the documentation are always welcome :-) <efraim>building out to hello on core-updates, testing out an update to isl and cloog <efraim>hopefully with those updated we can also get aarch64-linux-gnu bootstrap-tarballs <efraim>now that I've figured it out it seems obvious, but I updated isl to the version cloog bundles instead of testing every version out there <OriansJ>janneke: well I don't know, since I have never written my own lisp before but it sounds like something fun I could also do <janneke>OriansJ: I find it so fun and inspiring what you're doing that I'm looking into a minimal lisp interpreter now <OriansJ>mark_weaver: Question, have you considered the possibility of a low level virtual machine in the bootstrap process. Since we would gain the ability of all hardware platforms to perform identical work and run the exact same binaries. Thus even if we didn't trust the bios or other low level functionality, we would still be able to compare its results with that produced by trusted hardware? <janneke>i've downloaded your hex* and put it in an archive on gitlab, fun! <OriansJ>janneke: please don't forget to include that all my code is under the GPLv3 or later <LnL>I would like to make some changes to one of the importers, but I'm not sure how I can test that <LnL>guix environment -L . guix fails for me :( <rekado>In about one month I'll have the chance to replace the BIOS on my X200s with Libreboot. <rekado>after flashing Libreboot will GuixSD continue to just work or will I need to reinstall GRUB? <kristofer>I need libpurple to build a pidgin plugin; using guix environment --ad-hoc pidgin doesn't give me libpurple headers :-/ <kristofer>I'm doing it wrong, but what is the correct way? <kyamashita>rekado: You should be able to configure Libreboot to load GuixSD's grub configuration file. That's what I do right now. <kyamashita>rekado: What kernel version are you running on your X200s? <rekado>kyamashita: currently it's 4.5.0 <rekado>I've never played with Libreboot before. Do I need to configure this before flashing? <rekado>or is this some configuration file that's read at runtime? <kyamashita>rekado: I think you would need to configure the grub.cfg in the image using the Libreboot utitilies. <kyamashita>rekado: Also, you should know that I've had issues with suspending my X200 on recent kernel versions (at least on GuixSD). <roelj>I can't seem to download libpthread-stubs. Is there an alternative mirror for this? <kyamashita>If your computer is powerful enough, you can use the "--no-substitutes" flag to build the software locally. <roelj>I am trying to rebuild everything from source, and that's the problem.. I cannot fetch the source code <roelj>Does anyone have it? So I can use that? <kyamashita>roelj: Wow! Xorg's copy is not downloading for you? <roelj>No.. let me check which locations it tries.. <efraim>haven't checked if it has the same hash <kyamashita>roelj: The hash is the same, so you should be able to use the "--with-source=" flag with efraim's link. <efraim>preliminarily it looks like the xorg mirrors need X11R7.7/src/ added to the end and the urls need to be trimmed one path length <efraim>but then they'd all need to be updated to the latest release simultaneously, so adding X11R7.7/src/ in place of the foo in mirror://xorg/foo/ might be better <roelj>I have a similar problem with perl-uri ***digitteknohippie is now known as Digit
<roelj>But they seem to have removed the version 1.67 <roelj>Oh, and I've installed libpthread-stubs succesfully now, but when installing python, it still wants to download libpthread-stubs.. <kyamashita>roelj: Perhaps you can clone a guix tree, apply efraim's patch and build from within the tree. <kyamashita>If there is a simpler way to do this, please let me know. <roelj>Can I copy the tarball to the exact location in the store? <kyamashita>roelj: I wouldn't try to mutate the store directly like that. I think you can use guix download and supply the link from before to do that. <kyamashita>roelj: I hope that does what we think it does. :-P <roelj>Does anyone have the source for perl-uri for version 1.67? <roelj>Shouldn't we have a solution for disappearing source code? <roelj>Could Hydra serve the source tarballs as well? <efraim>it does, but only if you enable substitutes <kyamashita>efraim: That is, Hydra only gives you the source tarballs if you enable substitutes? Hydra counts its source tarballs as substitutes for the upstream tarballs? <roelj>Is there an option to download the source tarball then? <efraim>don't know what happened with that one <efraim>make sure to submit bugs for all the sources you can't download <efraim>i checked the source for the package and then tried to see if the path changed <kyamashita>efraim: CPAN apparently isn't hosting that version anymore. <roelj>efraim: Right, I'll try to find other packages myself :) <efraim>so that one might be fixed with adding cpan.metacpan.org to the perl mirrors <efraim>feel free to ask for more if you have trouble finding them <roelj>efraim: I'm not sure if that's a durable solution.. Maybe they remove it there tomorrow <roelj>Hmm.. I cannot find a replacement for libxcb-1.11 either. <roelj>They seem to have moved the xcb directory, but it is a dead link. <roelj>ng0: Ah, Gentoo to the rescue :) <kyamashita>roelj: xcb.freedesktop.org/dist/libxcb-1.11.tar.gz ***frafra_ is now known as frafra
<efraim>/gnu/store/cj5jfwgvkpqf2kvcfnjjvzl9z8mjbzbv-hello-2.10/bin/hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, not stripped <habs>Hi,my connection got interrupted while downloading emacs and now I get this error when trying to install it again: http://sprunge.us/UKMT What can be done to fix this? <lfam>kristofer: I read the channel log. Did you figure out that you need to omit the '--ad-hoc' part? That's assuming that pidgin contains libpurple <lfam>--ad-hoc means "put this package in my environment". Without --ad-hoc means "give me a development environment for the package" <lfam>habs: Hm, a failure during package download *shouldn't* cause any problems later. The process is supposed to be atomic. <lfam>habs: Can you do `guix gc --verify`? <habs>lfam:I can, it succeeds without error however I tried installing emacs again after and I get the same error. What does the error indicate? <lfam>habs: The output of your --verify is okay. <lfam>I'm not sure what's going on. Hopefully somebody with more knowledge than me will take a look. <lfam>habs: Have you ever installed emacs? You could do something like `echo /gnu/store/*-emacs-* | tr ' ' '\\n'`, and then if there is some abortive emacs package, do `guix gc -d path/to/bad/package`. But first, I would submit a bug report to bug-guix@gnu.org. <lfam>The system should be robust against this sort of failure <lfam>Also, have you ever run `guix pull` since installing Guix? <lfam>habs: I ask because there have been some changes to guix/ui.scm since 0.10.0 was released, and your problem seems to be in that code