<samueldr>
so, gchristensen, that was with a dangling /bin/sh that things worked?
<gchristensen>
yep
<gchristensen>
lol
<qyliss>
that's... interesting
<samueldr>
that's fun!
<qyliss>
but good!
<samueldr>
yes!
<gchristensen>
no systemd services failed even
<samueldr>
/bin/sh-less nixos when?
<samueldr>
(now apparently)
<gchristensen>
I was *stunned* to realize my /bin/sh was nerfed and still managed to mostly-work lol
<qyliss>
Yeah that's extremely surprising
<samueldr>
though yeah, system() alone is going to be an issue I figure
<gchristensen>
yea
<gchristensen>
anyway, I rolled back to set it to dash and try again
<qyliss>
Now I really want a No /bin/sh RFC
<qyliss>
It sounds like it might be much easier than any of us thought to replace it with a store path everywhere
<gchristensen>
I'm not looking forward to glibc -> a decent bash bash dependency management
<qyliss>
hmm?
<gchristensen>
it might have an awkward bootstrapping cycle
<qyliss>
Could we build a static Musl sh early in the bootstrap?
<qyliss>
For example
<gchristensen>
not sure
<qyliss>
Alternatively, we could build it with bootstrap bash and replaceReferences later
<gchristensen>
:o
<qyliss>
Does the sandbox have /bin/sh?
<gchristensen>
yeah
<qyliss>
Presumably that doesn't point to system /bin/sh?
<gchristensen>
depends per-system I think, it is a config option: sandbox-paths = /bin/sh=/nix/store/kaifg8ak63mlp4vqkmhjzmgdi1rlclmn-busybox-1.30.1/bin/busybox
<gchristensen>
(nix show-config)
<qyliss>
Oh that's cool
<qyliss>
So it's already not bash
rajivr___ has joined #nixos-dev
<qyliss>
Do we think a no binary bootstrapped Rust would be likely to get merged?
<qyliss>
I'm tempted to have a go, but don't want to bother if it's likely to be rejected due to compile times or too many versions.
<gchristensen>
how many steps does it take?
<qyliss>
12
<qyliss>
at present
<gchristensen>
I doubt it, he
<qyliss>
The latest version of Rust supported by mrustc is 1.29
<qyliss>
Guix has bootstrapped Rust
<samueldr>
do we bootstrap from a nix-bootstrapped rust binary or from a third-party rust binary?
<qyliss>
samueldr: third-party
<qyliss>
We also bootstrap other compilers, like Crystal
<samueldr>
is there value in meeting halfway, relying on a binary we produced through nix?
<qyliss>
I think it's sad if we can't have proper pure (i.e. bootstrapped) builds due to build times
<qyliss>
Can a Hydra wizard tell me how long it takes Hydra to build Rustc + Cargo?
<qyliss>
The more I think about this the more I feel it's important.
Drakonis__ has joined #nixos-dev
<samueldr>
qyliss: you want do know for an attribute part of nixpkgs?
<qyliss>
I want to know how long pkgs.rustc takes to build
<samueldr>
I'm not an hydra wizard, but if it's already part of what's being built I can tell
<simpson>
qyliss: Your feelings are valid. Here's my question, which I want to add to and not replace yours with: As a language implementor, what does "bootstrapped" even *mean* and how can I do more of it in the future?
<qyliss>
Bootstrapped means there's a path to building your Foo compiler without first needing a Foo compiler
<samueldr>
clicked through a couple builds on that page and seems to be ballpark 1h
<qyliss>
One common-ish way to do this is to provide a simple compiler (slower, less efficient, whatever) written in C or C++ or some other common language
<qyliss>
Another is to just build every version of your compiler with the previous version, going back to the last one that was not self-hosting.
<simpson>
qyliss: And the reasoning for this is that, while one might be able to theoretically audit a pile of Foo source code, there's no hope of auditing machine code, right?
<qyliss>
Yeah
<qyliss>
I don't like that there are blobs anywhere in my build process
<qyliss>
At least more than absolutely required
<qyliss>
Bootstrapped builds are the thing I envy Guix for the most
<qyliss>
And I think it would be good for us to compete on that.
<qyliss>
I'm wondering now if 12h for something that has to go to staging anyway is a big deal.
<qyliss>
Or, well, upgrading Rust would still only be 1h
<qyliss>
It would be if one of rustc's dependencies changed.
<simpson>
Sure. I guess I'm wondering both about, say, PNG files that *are* the source code, and are readable using an image viewer; and also high-level bytecode that decompiles to extremely readable text. (I am maybe not a good language designer.) To me, a blob is only a blob because of what we're viewing it with, not some sort of essence.
<qyliss>
I quite like the FSF's definition of "source code" meaning "preferred form for modifications"
<simpson>
For Rust, it's not hard to imagine that the mid-level build products ("unlinked modules" maybe? I don't know Rust terms) are neither reusable in the store nor reusable for bootstrapping builds.
<qyliss>
So a PNG can either be source code or not depending on whether that's how it's designed to be modified
<simpson>
Ah! That's a nice bright line. And at some point I suppose it recedes into the distance, as we get down to whatever C compiler serves as our fixpoint. Or maybe the Guile compiler, for Guix.
<qyliss>
(We can assume for this discussion that a given artifact is either source code or a blob)
<simpson>
They are also machine-readable, but this is the form that I think I'd prefer them in. I can't imagine that the raw matrix is going to be more readable.
<Drakonis__>
speaking of guix, their custom init is a fun and exciting thing
<simpson>
qyliss: I have just one more wonder. It sounds like bytecode, ala OCaml or Python, wouldn't be suitable for bootstrap source code, because although it decompiles to readabile text, we have no easy way to *prove* that the bytecode matches the bootstrap. But what if?
<qyliss>
I think that still wouldn't be quite good enough, because the bytecode still wouldn't decompile to the original source
<qyliss>
I'm assuming comments and whitespace are stripped
<qyliss>
And that means it becomes hard to verify that the original source code corresponds to bytecode
<qyliss>
Unless you have it as part of your bootstrap chain
<simpson>
This makes sense to me. So, in E and Monte, we have "auditor" objects; in these languages, an object can elect to be "audited" by an auditor object; the auditor gets access to the electee's AST and type bindings, but not its live values.
<gchristensen>
that is cool
<simpson>
Hypothetically(!), I can imagine an auditor which takes a module and a hunk of bytecode, and proves that the module's AST compiles down to the given bytecode.
<qyliss>
that's interesting
<simpson>
I don't have more questions, because qyliss is a delightful mind-reader. But I want Monte to integrate well with Nix, and that includes thinking about stories like this. It would be nice to prove that the Monte bootstrap bytecode is honest.
<qyliss>
well, jury's sort of out on whether Nix does care about bootstrappability.
evanjs has joined #nixos-dev
<gchristensen>
yikes
<simpson>
Fair. I feel that nixpkgs cares, if for nothing else than managing closure sizes.
<qyliss>
I'm not sure closure size is an advantage to bootstrappability?
<qyliss>
I'd expect runtime closures to be much the same, and build closures to balloon
<qyliss>
Because you don't get to cheat and skip half the build process
<simpson>
Hm. Can't we reach fixpoints? I don't know much about this corner of Nix.
<qyliss>
What do you mean by fixpoints?
<simpson>
I think I have some of my wires crossed, because I'm thinking about compile-three-times bootstrapping, which is something different, right?
<qyliss>
sort of but not really
<qyliss>
it's the same idea -- you start with a bad compiler that you can compile with what you have, and then iterate until you have a good compiler
<qyliss>
hey now here's an idea
<qyliss>
I wonder if we could use stage1 or stage2 Rust to compile the next version
<qyliss>
If current Rust is three stages (which I think it is but haven't checked), that would mean n/3+2 stages to bootstrapping from C++, rather than 3n
<qyliss>
n+2 stages, sorry
<qyliss>
I'm getting quite tired
<gchristensen>
you should go to bed
<simpson>
It's all good. I want to say "Futamura" but I think that going to bed is a good idea.
<qyliss>
So building Rust all the way from 1.29 might be more like 5 full compiler builds, not 12.
* gchristensen
is indeed watching Futurama
<qyliss>
But yes, I should od to bed.
<qyliss>
Is there something special happening with Futurama??
<gchristensen>
no, I just watch Futurama on a fairly regular basis
<drakonis>
no, but there's the good place's series finale soon
<qyliss>
I watched Futurama for the first time a few months ago
<simpson>
No worries. With my luck, it would have been one of the sad episodes.
<gchristensen>
and?
<gchristensen>
did you like it?
<qyliss>
oh it was fantastic
<qyliss>
I watched the whole thing for the first time, to be clear
<qyliss>
I'd seen a couple of episodes prior
<gchristensen>
ah
<gchristensen>
okay, new finding in "why did stuff break and nobody knew?"
<gchristensen>
prometheus-alertmanager-irc-notifier.service was stopped during the database migration and never started again. maybe a timer should exist to start it every day? additionally, a failure in a git gc several days ago ,rfc39 sync stopped managing to run. also Due to https://github.com/NixOS/nixos-channel-scripts/pull/25 wasn't deployed yet, breaking channel updates for unstable. also the disk was
drakonis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
<drakonis>
there's a missing build feature here, the ability to produce multiple packages from a single build, ie: curl itself can produce a package including the binary and library or just the library
<drakonis>
that gets rid of duplicate builds for variations of a same process
drakonis_ has joined #nixos-dev
<drakonis>
its pretty much package splitting
drakonis has quit [Read error: Connection reset by peer]
drakonis_ is now known as drakonis
<drakonis>
reduce closure sizes by only using pieces of packages
lovesegfault_gro is now known as lovesegfault
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
simpson has quit [Ping timeout: 248 seconds]
simpson has joined #nixos-dev
mingc has quit [Ping timeout: 248 seconds]
thonkpod has quit [Ping timeout: 250 seconds]
mingc has joined #nixos-dev
thonkpod has joined #nixos-dev
orivej has joined #nixos-dev
<adisbladis>
drakonis: Sounds like multiple output derivations.
Jackneill has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
<drakonis>
adisbladis: a little bit, but offers more ways to produce multiple outputs
<drakonis>
t
<drakonis>
the existing method doesnt appear to allow scripting the split into multiple pieces
<clever>
drakonis: you just set `outputs = [ "out" "dev" ];` on your derivation, and the installPhase (a script!) must then copy things to $out and $dev
<ekleog>
qyliss: there's a systemd.tmpfiles.rules for /var/rss2email ; as for the why not /var/lib/rss2email, I can't remember -- probably just was the way it was done in the docs I used for installing
<drakonis>
clever: i mean, what if the build generates a wayland and a x11 binary, do i just cook up a whole new build for that or offer all of them in bin?
<clever>
drakonis: i would make them different derivations
<clever>
drakonis: maybe a flag you set with .override
<drakonis>
doesnt quite solve it, as it generates extra builds
<clever>
drakonis: if you want fewer builds, make one package with outputs = [ "x11" "wayland" ]; for ex
<clever>
and then install .x11 or .wayland
<drakonis>
right
<clever>
drakonis: but now all of the wayland guys have to build x11 still, because the package depends on both
<clever>
(or download both if cached)
<drakonis>
not an improvement either
<drakonis>
matters only when building
<drakonis>
but fair enough
andi- has quit [Ping timeout: 272 seconds]
<__monty__>
Why wouldn't laziness prevent building X11?
<clever>
__monty__: if the package depends on both wayland and x11 at the same time, and produces 2 outputs when building, it will need both inputs
<clever>
at build time
<Taneb>
I guess the proper thing to do would be split into foo-core, foo-with-X11, foo-with-wayland derivations but that's not always possible
<{^_^}>
#10003 (by gebner, 4 years ago, merged): qutebrowser: youtube support
<genesis>
faultServiceProvider::requestService(): no service found for - "org.qt-project.qt.mediaplayer"
<genesis>
but it seems to be fix for qt5.qtmultimedia, and pyqt5_with_qtmultimedia seems to depend on qtmultimedia, but wrapping with wrapQtApp i dont get the qtmultimedia plugins
<jtojnar>
genesis even with wrapQtAppsHook?
<jtojnar>
Hmm
<genesis>
i didn't try
_ris has joined #nixos-dev
<genesis>
hum that is what i use, wrapQtApp
<genesis>
perharps i need a better qtWrapperArgs+=(--prefix QT_PLUGIN_PATH : "${qt5.qtmultimedia}/lib/")
<jtojnar>
I wonder why it says service
<jtojnar>
Maybe it needs some systemd/D-Bus service
<jtojnar>
Try looking into the qtmultimedia output tree
<jtojnar>
If there are any such things
Drakonis__ has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
lovesegfault has joined #nixos-dev
Drakonis__ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<genesis>
i tried qutebrowser 1.9 , working on youtube, it succeed cascading wrapping