<stikonas>not sure if sudo works with others though... <fossy>we are already running as root <fossy>the problem is its running in a container itself that probably dosent allow chroot <stikonas>in the meantime I've rebased my PRs on top of perl <stikonas>(there was a small merge conflict, resolved now) <stikonas>it's actually not chroot, but mounting inside docker <fossy>yeah cause cirrus uses docker <fossy>What are we even mounting inside docker though <stikonas>with perl merged, I think I can try to build latest automake and also latest texinfo <fossy>yeah I think adding -no-tmpfs is best <stikonas>fossy: have you noticed how much faster it is.... <stikonas>although, maybe that's because of gcc and not perl itself <fossy>stikonas: not rly, whats fast about it? Automake and co? <stikonas>it's probably also because automake is not that big piece of software, so automake on itself runs fast too <oriansj>ekaitz: congrats on the almost hex0-seed. one minor problem that really matters at such a low level is writing to stdout in a shell that doesn't support > redirection means it can't actually build anything. <oriansj>oops it looks like you had that too; a little clunky but it would work. <oriansj>just missing one piece (use hex0 to make your initial hex0-seed binary from your hex0 sources and check it in) and then I will merge it into bootstrap-seeds as the first part of the RISC-V port ***illegal is now known as V
***lfam is now known as zebracloud
***orionwl is now known as laanwj
<amirouche>hello, re past bootstrap attempt that relied on forth. A) Why did it not succeed? B) What forth implementation did you use? <siraben>amirouche: ooh, oriansj would be able to answer that ***NieDzejkob_ is now known as NieDzejkob
<oriansj>amirouche: A) because it failed to be a useful and/or productive environment for bootstrapping anything more than having a FORTH environment. B) we used multiple for development and even wrote our own from scratch https://github.com/oriansj/stage0/blob/master/stage2/forth.s but ultimately if we wanted to do anything serious; FORTH just kept being more pain than it was worth. In short we achieved more progress in a weekend with cc_x86 (a <oriansj>minimal C compiler written in assembly that supports structs, unions, gotos and inline assembly) than we did in 6 months of FORTH. Oh and the C compiler took less time to write too... (Heck the garbage collecting Lisp we wrote in assembly took less time to write than the FORTH) <oriansj>So it isn't to say that someone couldn't do something useful in FORTH for bootstrapping; I am just saying we haven't seen it yet. <oriansj>Because writing a C compiler (cc_* type) in assembly takes 24 hours. <amirouche>24h is surely when you know what you are doing ^^' <fossy>yeah that would be when you know what youre doing <amirouche>it took me more time to find an off-by-one error this week-end. <fossy>i certinaly couldn't do it in 24 hrs <oriansj>amirouche: with a full and proper parser <oriansj>actually it took 24hours knowing assembly but once I knew what I was doing I did a speed run of 4 C compilers in assembly in only 2 hours <amirouche>I window shopping a project, that boils down to a bootstrappable Scheme/Kernel system, but I would like it to be somewhat portable across hardware and OS (linux/netbsd), and eventually have its own OS kernel. <oriansj>amirouche: then use C if you want portable code <amirouche>I wonder what would be the best target a forth or gnu lightning. <amirouche>My C knowledge is weak, and I do not want to improve it ^^' <oriansj>amirouche: that is fine. It doesn't need to be strong. Only read a byte and write a byte, loop and conditional <amirouche>it would be a separate bootstrap path wrt to guix/guile/mes <amirouche>I can not start ex-nihilo, but having both performance constraints and portability makes the thing seems impossible. <oriansj>if you need portable *AND* fast, C is pretty much the only option <oriansj>or go or Rust depending on your preferences <oriansj>C as a language is elegant if used correctly <oriansj>It is that last part where most of C's sins were born. <amirouche>it is complex to explain, but I prefer to keep the number of programming language syntax and programming concepts to a minimum. One way to see it, is that it is a whole stack Scheme/Kernel system (wanna-be). So, if I rely on forth, it will need some s-expr syntax. <amirouche>I follow that principle: "If a system must serve the creative spirit, it must be entirely comprehensible by a single individual." <oriansj>amirouche: just do everything in scheme if you want, that is fine <amirouche>so mixing C semantic with Scheme, and hardware architecture specifics make the whole system brittle IMO <oriansj>amirouche: just only mix scheme and assembly and it will not be brittle but portable. <oriansj>It'll be slightly slower than C but it'll run reasonably fast on modern hardware. <oriansj>amirouche: If you wanted to do a scheme compiler written in scheme; I know a piece that could use your help ^_^ <oriansj>the hope is to have it extended enough to compile mescc <oriansj>as compiled scheme is much faster than interpreted scheme <stikonas>you'll have to build guile eventually though <stikonas>if you want to bootstrap the whole system <amirouche>ah yes you are right, guile is not self-hosted. <oriansj>amirouche: guile's C isn't the simplest thing to build either <oriansj>and we had mihi spend a bunch of time to solve the psyntax.pp bootstrapping issue (not sure how many more might exist) <oriansj>hence the desire for a lower in the bootstrap scheme compiler <oriansj>and mescc but that is a C compiler and not a scheme compiler <stikonas>but I think stuff like autogen actually needs guile <stikonas>although, maybe some other scheme implementation would work too if it's sufficiently complete <oriansj>stikonas: yeah. hence why GCC got bootstrapped far easier than guile. <stikonas>well, we skipped part of the GCC build system because it needed autogen <stikonas>but with a bit more work GCC was compiled and we'll use that GCC to build guile <amirouche>so, if understand correctly, if I can write a forth interpreter in assembly, than can interpret scheme or kernel code, that is self-hosted, I will have a bootstrap path for my system <stikonas>well, basically anything can work, the problem is just doing the work <amirouche>I could also code a scheme interpreter in assembly but that looks more complex. <amirouche>And a scheme interpreter in forth, is not given either. <amirouche>re doing the work is a problem, but a bigger problem is doing the "good" work. <stikonas>so at the moment we have basically two variants of bootstrap: 1) guix bootstrap which uses some pre-generated files, and some external automation driver (guile). 2) live-bootstrap which does not use any pregen files, drives the whole process with just kaem-optional-seed (757 bytes) but stops at around GCC 4.0.4 for now <amirouche>good work, I mean following the principle that I will be able to understand the whole system. <stikonas>so if you want some further changes, you can pick one component from there and try to bootstrap it some other wya <amirouche>stikonas: ah thanks, that should be on a page at bootstrappable.org. I was looking for that. <stikonas>(a bit more is done in a branch of guix that starts from hex0 although it will still use guile) <amirouche>so there is branch of guix that starts from hex0, but is not completly finished? <amirouche>oh ok I think I get it, it is working from kaem as seed toward hex0 <amirouche>I am not sure why I am interested by this bootstrapping stuff. <stikonas>guix branch starts from hex0 seed and uses guile as automation driver <stikonas>but also uses guile to run some stuff like gash and bootar <stikonas>that runs directly and process is driven by kaem <amirouche>stikonas: why are you interested in bootstrappable <stikonas>well, I also had used Gentoo for some time, so compiled stuff from source <stikonas>building it form just source seems natural extention <siraben>but I think it has a lot of potential because the subset of Haskell it supports is good enough to be compiled with GHC for double-checking <siraben>(see README about plans for writing Scheme in Haskell) <siraben>someone had questions on a nixos issue regarding making the stdenv bootstrappable, how would reproducibility get affected? <siraben>AFAIK live-bootstrap is supposed to be quite deterministic <Melg8>siraben yes it supposed to be deterministic for all files (except logs/temp files maybe) <stikonas>at least all binary files in live-bootstrapped are checksummed <stikonas>in some cases might be even more deterministic than nixos packages <stikonas>we apply a few fixes to remove non-deterministic issues due to e.g. old kernels or CPUs <stikonas>we don't checksum non-binary files right now, but I think that will come eventually, maybe once bauen1 finishes his work <siraben>our bootstrap is 130 MB uncompressed o.O <Melg8>siraben so you try to build everything using stdenv? <siraben>Melg8: everything uses stdenv in Nixpkgs, pretty much <siraben>change stdenv, change it all, tens of thousands of packages <siraben>this question occurred to me when packaging up the bootstrappable tools in Nix <siraben>I looked at the build closures and was surprised and why they were so big <siraben>runtime of course is just the binaries themselves, but we care about the entire build-time closure <Melg8>you want to replace make-bootstrap-tools part of boostrap in nix? or replace usage of those tools? <siraben>I want to replace the standard environment for packages in Nix <Melg8>because initial boostrap uses it's own thisStdenv instead of default one <siraben>this basically provides things like, a C compiler, bash, perl, and all of the transitive dependencies <siraben>Melg8: oh, great, you already have initial work underway! <stikonas>lkdedihnirtrrgfkfnguefrjkfttvdlvlnlfugfeghvn <Melg8>im stuck with my own idea to be backward compatible with live-bootstrap approach.. which is to build everything without nix seeds at all <Melg8>siraben so my initial idea was to use nix to do two things - load github repos and unpack them into store. Than use kaem as runner and just generate kaem scripts with paths from nix store. + use nix to add some extra supporf of different arches - just by replacing parts of text with needed flags/ destinations <siraben>Melg8: oh I notice you are on matrix as well, the r13y channel is another good place to bring this up <Melg8>i was asking if any want to do this in matrix/irc/discord) but finally find you here) <Melg8>only problem with nix that i found is - nix wants outputs out of derivation. and initial kaem doesnt know how to track env variables, so i delayed package until kaem from c is ready, and just than copy binaries to out <Melg8>i just doesn't want to bother with creating new git repo for that- because started as experiment, and i have already nix stuff there) but ofc if it grow to something - should be moved in proper place (nixpkgs xD) <siraben>Melg8: ok, wow, writing raw derivations <siraben>kaem-optional-seed won't track env vars? <Melg8>it just can send them to it;s childs <Melg8>but it cant use them by itself <siraben>once this is all done we need to bootstrap Nix in the first place heh, it's written in C++ though <Melg8>siraben i want to warn you that i relatively new to nix, so that all crappy code, and i need somebody to have more experience for example, to push this ideas to nixpkgs <stikonas>kaem-optional-seed can only exec applications with arguments, that's it (well, and parse .kaem files) <siraben>You seem to have quite good knowledge of Nix already (writing raw derivations is usually an advanced topic) :) <siraben>How far does this bootstrap in Nix go? <Melg8>but it's not hard to get all the way - to anything from live-bootstrap from there. i've stuck with idea of nix making cleared tree with no nix involved <Melg8>siraben if you want we can collaborate to do something sane for nixpkgs) although i think we need some extra input from community - to how this all can fit without breaking hydra and without affecting build time to much. <siraben>Melg8: yeah, it's something I would want, I don't know anyone else in the NixOS community familiar with the bootstrappable work (or even the names of the stages like kaem and m2-planet) <siraben>we can also ask for our own hydra jobset <siraben>Ah, cool, are you participating in summer of Nix? <stikonas>Melg8: yeah, I think we briefly looked at it and also busybox <Melg8>siraben idk, too shy to write them, but i'm intrested in topic , so i've started to prepare stuff) <stikonas>(note that first coreutils are built with mes libc) <siraben>Melg8: Ah, I see. AFAIK it would likely be packaging work, and probably not making stdenv bootstrappable <siraben>So stdenv consists of bash/coreutils/gcc and what other things? <siraben>I need to refresh my memory on the stages <stikonas>Melg8: it's probably not super surprising, mes libc was written to be just good enough to build bash/binutils/gcc-2.95.3 <Melg8>stikonas yea, i see. One day we would be able to cut some corners) if some of mes libc get upgraded <siraben>Melg8: ah, thanks. Yeah, it looks like we'd want to replace make-bootstrap-tools with bootstrappable's one <siraben>Melg8: another thing I was thinking about maybe as a good beginning, is create a new stdenv variant, stdenvMinimal <stikonas>well, we already (mostly pder) pushed some patches into mes libc that live-bootstrap needed <siraben>stdenvNoCC isn't even minimal enough <Melg8>yes, i think that would be better than on "client" side - because less people would be affected, although - make-bootstrap-tools already use full nixpkgs stuff <stikonas>most importantly ability to have more than 255 command line arguments <Melg8>siraben my own - smallest possible goal were - to provide coreutils - from bootstrap - and not build with large binary seeds of gcc and so on. <siraben>Yes, coreutils would be pretty well-defined, right? <siraben>I think SuperSandro2000 did something regarding uutils-coreutils <siraben>coreutils being bootstrapped sounds like another great goal <Melg8>yea, at least i know the path (thanks to live-bootstrap) and proved to myself that nix can handle initial struggle, rest is just adapting scripts/choosing directions and implementations. But idk if community want this to be as pure as i would like it to be. (using stdenv and bash from host makes things more sane/ but less trusted) although nix <Melg8>itself if present - is huge. <Melg8>siraben if you can - spread this issue in some chats/discussions, or with some of stakeholders on nixpkgs, so it at least get proper discussion with all interested parties involved. But from my personal experience bootstrapping story is not very popular in nix community ;( <lfam>I am wondering if this is the new "official" bootstrappable IRC channel? If so, we'll update the reference in the Guix manual <siraben>Melg8: bootstrapping (in general) was recently mentioned in the reproducibility channel on Matrix, I would really want to see Ercison2314 on it as well <siraben>I think he's quite familiar with the stdenv and cross stuff <xentrac>lfam: yeah, it is. the Leenode channel got shut down (by oriansj I think) before leenode started punishing such dissent <qyliss>I think that was done at a conf and not pursued further <oriansj>lfam: well the final official vote for where our final stopping place is this week. <oriansj>Which everyone here gets an equal vote <lfam>Is the freenode channel even open? I tried to join it but I'm banned for some reason <lfam>Our manual points people to #bootstrappable on freenode <oriansj>(correction oftc.net, Libera.Chat and matrix:#bootstrappable) <oriansj>So everyone here has until sunday (failure to vote just means Obstain for all 3 options). Post with the text: My Vote and a link to your vote in that format. <oriansj>Thus far no votes have been posted. (let alone the 25vote majority needed to end the voting early) <lfam>I will leave the vote to the people who are doing the work :) We will update our manual accordingly <siraben>yikes, so said we got attacked on Leenode :() <siraben>we shut down voluntarily before it happened <jackhill>like lfam, I'd like to leave the decision to those doing the actual work, so I've abstained, but I voted in case that helps judge engaguement on the topic :) <bandali>it might be worth noting that last i checked, verifying a nick on OFTC requires running nonfree js (google recaptcha) <Noisytoot>bandali, that is correct, but you can ask an ircop to manually verify it (like I did) <bandali>ah i see, it's nice that they offer that option. i just wish they wouldn't expose people to the captcha by default to begin with ***Hagfish_ is now known as Hagfish
<jackhill>roptat: I haven't used any of them, but `guix search matrix-client` turns up some. My main experience is connecting via xmpp. <roptat>jackhill, thanks, most of them are not clients, but libraries, but I see nheko and quaternion indeed <roptat>I was under the impression they would depend on a qtwebengine or something, but looks like I was wrong, so consider I have no objection now :) <roptat>mh, although nheko crashes at startup... <jackhill>:) well … like I said, I hadn't tried any <roptat>[qml] [critical] Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) (:0, ) <roptat>so I am a bit concerned about being able to use Matrix :) <roptat>(I can use it on my phone, and use the web interface of course, but none of these options are very practical) <jackhill>well, I guess you don't need to change you vote then. <oriansj>jackhill: that is why we give people a week to decide and openly debate, discuss and champion their preferred choice. <oriansj>For example I certainly would have objections regarding to the default process being non-free javascript for OFTC <oriansj>Or the lack of usuable matrix clients in Emacs 
