gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat | https://logs.nix.samueldr.com/nixos-dev
<gchristensen> hmmm maybe a better bet to just depend on the ssh. I like the vbox option since there is so much built-in choice
<Dezgeg> gchristensen: here's the approach I implemented some time ago for booting cloud-init images: https://github.com/dezgeg/nixpkgs/commit/e9ad47770063c8a873bbcc504906e0854137c781
<gchristensen> !!! I spent ages looking for official qcow's from fedora/centos/debian and didn't find those!
<Dezgeg> the magic keyword was 'openstack' iirc
init_6 has quit [Ping timeout: 240 seconds]
<Dezgeg> I can't recall exactly what it was but I think most of those vagrant images had something hardcoded such that they would only (easily) boot on virtualbox
* gchristensen deletes a lot of vagrant-to-qcow code
init_6 has joined #nixos-dev
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
<gchristensen> Dezgeg: your commit there has been hugely helpful, thank you :)
erickomoto has joined #nixos-dev
erickomoto has quit [Client Quit]
erickomoto has joined #nixos-dev
lassulus_ has joined #nixos-dev
erickomoto has quit [Client Quit]
init_6 has quit [Ping timeout: 244 seconds]
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ is now known as lassulus
<aszlig> samueldr: oh wow... i can reproducibly read even the passphrase from the old implementation
<aszlig> samueldr: for the new implementation the passphrase just occurs more than once in memory
<samueldr> uh, let's say: glad there aren't regressions?
* samueldr is a bit spooked
<aszlig> the old variant had the password in kernel space
<aszlig> now it's in userspace
<samueldr> ah, so kindo f
<samueldr> I guess the kernel ones aren't avoidable?
<aszlig> samueldr: i stepped through with gdb and radare and it's actually the input buffer for the tty
<samueldr> I like the way it's a nixos test
<samueldr> aszlig: do you know if their assumption was right? > However, AFAIK, with Linux that memory will be zeroed out anyway before being reused by any process after `ash` `exec`s into the next stage
<samueldr> tried a bit of google search but found nothing even remotely close to being relevant
init_6 has joined #nixos-dev
<gchristensen> samueldr: link?
<aszlig> samueldr: okay, i was wrong it's still only once
<{^_^}> #29441 (by oxij, 47 weeks ago, merged): nixos: initrd/luks: allow to reuse passphrases, cleanup
<aszlig> samueldr: maybe i have to do several test runs
<samueldr> aszlig: if I can do anything to help, do ask (though you seem to have more knowledge in the area)
<samueldr> oh, gchristensen, last comment is the assumption I was talking about
<gchristensen> and the nixos test is searching memory for the password?
<samueldr> it isn't currently, but aszlig just wrote one
<aszlig> but already having the passphrase even in kernel memory is something that makes me feel a bit uneasy... i mean what are all those kernel patches to defend against cold boot attacks worth trying to defend against key exposure if the passphrase is simply in memory?
<gchristensen> ahhhh amazing!
<aszlig> samueldr: okay, it's really only once
<aszlig> so that PR at least didn't make things worse
<samueldr> I'll be able to sleep tonight (joking)
<samueldr> though, still worrying how it's apparently in the kernel memory (if I understand correctly)
<samueldr> wondering if there is something other distros do
<aszlig> hm, otoh... this could also be userspace, investigating...
sir_guy_carleton has joined #nixos-dev
<aszlig> (which also wouldn't make sense for the tty input buffer)
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
init_6 has quit [Ping timeout: 244 seconds]
Drakonis has quit [Remote host closed the connection]
erickomoto has joined #nixos-dev
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
init_6 has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
garbas has quit [Ping timeout: 248 seconds]
garbas has joined #nixos-dev
garbas has quit [Ping timeout: 272 seconds]
garbas has joined #nixos-dev
garbas has quit [Ping timeout: 240 seconds]
garbas has joined #nixos-dev
vcunat has joined #nixos-dev
genesis has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
garbas has quit [Ping timeout: 272 seconds]
garbas has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
garbas has quit [Ping timeout: 268 seconds]
garbas has joined #nixos-dev
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-dev
init_6 has quit []
<infinisil> Was it really okay to just remove nix-repl? https://github.com/NixOS/nixpkgs/commit/490ca6aa8ae89d0639e1e148774c3cd426fc699a
vcunat has quit [Ping timeout: 256 seconds]
<gchristensen> I think so?
<infinisil> Minimum nix version is still only 1.11, which doesn't have nix repl
<gchristensen> I think we're going to bump the minnix
<samueldr> last I read (yesterday) it was pushed to 19.03?
<gchristensen> oh
<samueldr> though, nix-repl probably should have been replaced with a stub for all the parts referencing it
<infinisil> Yeah, and it's still not even 18.09. So anybody using not Nix 2.0 wouldn't have a nix-repl until 18.09/19.03
<samueldr> would any of you know if `nix repl` from 2.0 would work with a 1.11 nix-daemon?
<samueldr> let's say the sub was literally `#!/usr/bin/env bash exec nix repl` with the appropriate care for nix paths etc
<samueldr> gchristensen: issue in question → https://github.com/NixOS/nixpkgs/pull/37693
<{^_^}> #37693 (by jtojnar, 20 weeks ago, open): Nix minimal version: 1.11 -> 2.0
<infinisil> I'll make a PR to revert that nix-repl removal
<gchristensen> do it with a revert w/ an explanation in thecommit message please
<infinisil> Yeah
<infinisil> #44903
<{^_^}> https://github.com/NixOS/nixpkgs/pull/44903 (by Infinisil, 18 seconds ago, open): Revert "nix-repl: Remove"
<LnL> yeah, I've received comments on every commit where I forgot to do that (which is really great btw :D)
<gchristensen> :D
<infinisil> Also, this commit was done without discussion: https://github.com/NixOS/nixpkgs/commit/4d1332e507fe55103bc5ddd0a384447dc7833e12
<gchristensen> I'd take the commit message as strong feedback and put it back with a good error message
<samueldr> any opinions about saving the stateVersion in a stateful directory and comparing it for a warning/plain stop?
<samueldr> as many stateVersion-gated things require manual intervention, I feel it's fine to require manual intervention (deleting the stateVersion.lock(?) file)
<samueldr> here, assuming absence is fine
<infinisil> samueldr: Would need to be a runtime thing then
<infinisil> Because build machine != deploy machine
<samueldr> oh, right
<samueldr> (which is why I'm asking!)
<infinisil> But I thought about this before, and if it wasn't for that, I'd prefer such a state file
<samueldr> too many times stateVersion seems to be changed "to upgrade"
<infinisil> Yeah
<infinisil> I think it would be better for it to just be an increasing integer
<infinisil> And every time somebody does a change that requires a state update, they increase the number
<infinisil> E.g. postgres default location upgrade -> increase number
<samueldr> infinisil: this becomes a bit messy, though, with parallel long-lived branches
<infinisil> Oh true
<gchristensen> a number isn't really good either because you may wantto upgrade part but not all the things
<samueldr> yeah
<infinisil> Okay, well it should really be such a state number *per module*
<infinisil> or per service or whatever
<samueldr> though the incrementing number has one advantage: each increase can be documented more plainly
<samueldr> it would become messier, but in the long run, probably much less confusing
<infinisil> If it's per-service, then you don't even have to bother with it if you don't use such services
<samueldr> (for the end-user)
<samueldr> yeah, imagine my media-consumption computer, pretty sure stateVersion there is a no-op
<timokau[m]> Is there a way to mark a package as binary (not built from source)?
<timokau[m]> Asking because o https://github.com/NixOS/nixpkgs/pull/44884
<{^_^}> #44884 (by bachp, 17 hours ago, open): emby: 3.4.1.0 -> 3.5.2.0
vcunat has joined #nixos-dev
<infinisil> timokau[m]: preferLocalBuild might be worth setting
<infinisil> (Or whatever the attr is called)
<infinisil> And/or allowSubstitutes = false (not entirely sure how that differs from preferLocalBuild)
<infinisil> Though)
<vcunat> That does differ.
<vcunat> One is about checking if a substitute exists.
<LnL> that's substituters vs build-remote
<vcunat> And one is about whether the build is distributed.
<infinisil> Ah right
<LnL> most things set both tho
<vcunat> Yes, I can't remember any use case for not keeping them at once :-)
<LnL> aren't sources only dontSubstitute?
<LnL> ie. download from upstream, but do it on a remote builder since it will need to be copied there anyway for the build itself
<vcunat> sources are substituted typically
<vcunat> oh, but not via binary cache :-)
<vcunat> I easily forget about that distinction
<vcunat> but the state is that fetchurl has preferLocalBuild = true;
<vcunat> only!
<vcunat> Anyway, any reason not to mirror (some) sources via the standard binary-cache mechanism?
phreedom has quit [Ping timeout: 250 seconds]
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
Cale has quit [Read error: Connection reset by peer]
timokau has quit [Quit: WeeChat 2.1]
<LnL> I'm not sure why we have the distinction between substituting sources as a build and tarballs.nixos.org
Drakonis has joined #nixos-dev
<vcunat> there's a thread about that somewhere already
lopsided98 has quit [Ping timeout: 255 seconds]
lopsided98 has joined #nixos-dev
timokau has joined #nixos-dev
<LnL> I wouldn't call copumpkin's email a thread, or are you thinking of something else?
<vcunat> Probably, I do remember copumpkin raising that.
<timokau[m]> I feel like there should be a meta variable marking this. I care far more about weather or not the software I installed was build from source than I care about the license
Cale has joined #nixos-dev
disasm has quit [Quit: WeeChat 2.0]
<LnL> that's not really related but yeah that would be cool
<LnL> bootstrap-tools is an interesting case tho :)
vcunat has quit [Quit: Leaving.]
<timokau[m]> Well thats how I started the discussion so kinda related :)
<timokau[m]> Yeah I don't know the details about that but you have to start somewhere. You'd probably need to make an exception for that.
<timokau[m]> But I'm assuming those are as minimal as possible
<LnL> yeah, otherwise it would propagate to everything if you disallowed binary packages :p
<timokau[m]> The best cyber-security policy is still to trash the computer and move to a remote cave
<MichaelRaskin> You forgot to EMP the surroundings of the cave
<MichaelRaskin> There are many compilers, and many of them need binary bootstrap…
<timokau[m]> Are there really that many? I thought most would just bootstrap from c
<clever> ghc cant be compiled from c
<MichaelRaskin> Haskell, Common Lisp, Pascal, Rust…
<timokau[m]> Thats haskell right?
<clever> yeah
<timokau[m]> Huh, I thought rust was bootstrappable without binary
<MichaelRaskin> I think Go bootstrap from C keeps getting more and more stages
<clever> and for extra fun, certain versions of ghc need certain versions of ghc
<timokau[m]> How do they come up with the first version then? Still hand-compiling?
<clever> so you have to compile 3 different ghc's to get the most recent one
<timokau[m]> Its a hard problem, but at least we can automate it
<MichaelRaskin> Well, back in the day some old version was compilable from C
<timokau[m]> MichaelRaskin: Isn't that exactly how bootstrapping works? Compile that old version from C, compile the next version from that...
<timokau[m]> Ideally you won't have to compile every version of course
<infinisil> I don't think boostrapping says anything about where to start
<infinisil> You can go arbitrarily back if you want to, back to compiling gcc with the first version of the C compiler written in assembly or whatever :P
<infinisil> Just not very practical
<MichaelRaskin> With some of the compilers, the last version compiled from other language can even be before the current repository origin
<MichaelRaskin> (or maybe interpreted and used to self-compile)
<timokau[m]> infinisil: Maybe not practical for everyday use, would be very neat to have the option though ^^
<timokau[m]> MichaelRaskin: Well that would suck
<clever> this blog explains how to go from a bare text editor to a compiler
<clever> bare hex editor*
<infinisil> But what did you use to compile the editor??
<timokau[m]> Isn't it just "write tiny compiler", "hand-compile to asm", "write somewhat bigger compiler, compile with last version", repeat?
<timokau[m]> Well real programmers program with butterflies
<clever> infinisil: that blog assumes you have a working hex editor to start with
<clever> timokau[m]: pretty much
<clever> timokau[m]: it starts by incrementally improving the assembler, so you dont have to track opcode sizes by hand
<timokau[m]> I guess for the very first ones someone hard-coded the bits in hardware
<clever> adding in more and more powerful linker type features
<timokau[m]> clever: You could say that the assembler is just the first compiler
<clever> this is also a wiki i found about bootstrapping
<timokau[m]> It would be very cool to be able to go from a couple lines of asm all the way to the latest version of rus
<timokau[m]> If nobody is able to reproduce the current compilers that is a bit sad
<clever> timokau[m]: good luck defining what \n is: https://twitter.com/garblefart/status/938524271135084545
<MichaelRaskin> Better yet, define what \v is
<clever> MichaelRaskin: the rust compiler maps \n to the value of '\n', lol
<clever> so it assumes whatever is compiling the compiler knows what \n is
<MichaelRaskin> \v: the same, in many languages, but not many people remember what the hell this even is
<timokau[m]> clever: Thats amazing / a bit horrifying
<timokau[m]> MichaelRaskin: don't leave us hanging, what the hell is it?
<clever> vertical tab i'm guessing?
<timokau[m]> Where would I use a vertical tab?
<clever> good question, lol
<MichaelRaskin> timokau: obviously if you target a self-compiling compiler, the bootstrap interpreter is destined to have a lot of weird limitations (because you want to get something one-shot quickly)
<MichaelRaskin> The answer is nowhere anymore, because the terminal emulators, unlike programming languages, are way less eager to propagate ^K support
<clever> MichaelRaskin: which would be why the bcompiler.html above started with an assembler that cant even fill in addresses of nearby symbols
<MichaelRaskin> Maybe because they need to do actual work
<simpson> MichaelRaskin: Monte deliberately killed '\v'. We couldn't find any usage of it in Python codebases, other than to propagate Python's support for it.
<MichaelRaskin> And releasing such a tool that never works right except with one specific revision of the compiler codebase…
<MichaelRaskin> simpson: yes, some languages do make a sanity check and then throw away \v
<MichaelRaskin> (Personally, I do have some code using ^K character)
<clever> MichaelRaskin: ive also seen ^L in some codebases
<clever> that tends to screw with auto-complete in vim for some reason
timokau has quit [Quit: WeeChat 2.2]
<clever> timokau[m]: we lost half of you! lol
<timokau[m]> clever: What do you mean you lost half of me?
<MichaelRaskin> ^K I use for some automation logic: if I want to send Tab, I put ^I, and ^K for Shift-Tab
<clever> timokau[m]: timokau disconnected
<timokau[m]> clever: Oh right, thats weechat running on my raspberry pi
<timokau[m]> clever: Before I switched to mostly using matrix, I always used weechat on a always-on rpi as a poor mans solution for persistent logs
<timokau[m]> Now that is still running because why not
<clever> timokau[m]: ive got irssi + screen on an old box
<timokau[m]> And I just restarted the raspberry pi because I'm experimenting with wireguard
<timokau[m]> clever: I had weechat+tmux, thats like the 2nd gen technology version of your solution :D
<timokau[m]> (Not saying that irssi or screen are worse)
timokau has joined #nixos-dev
Jackneilll has quit [Read error: Connection reset by peer]
Jackneilll has joined #nixos-dev
<timokau[m]> Back to topic: generalizing the "is binary" one, something like f-droids anti-features might be nice one day
<Drakonis> that's very ad hoc and could use expansion
<samueldr> timokau[m]: please write an RFC for this, or at least some words on the discourse, but I agree with the general idea
<samueldr> and not even creating a judgement about whether binary is good or not
<samueldr> just documenting it
<timokau[m]> clever: I'm not sure if I care strongly enough for an RFC, maybe I'll do that some time
<timokau[m]> Especially because they tend to end up nowhere anyways
<samueldr> hi, I'm samueldr :)
<timokau[m]> But a discourse thread is little effort and a good idea
<samueldr> which is why I continued with "or at least a thread"
<timokau[m]> samueldr: hi samueldr, I'm timo?
<samueldr> (related to the fact that the tab-completion completed with the wront name)
<timokau[m]> Oh, I messed up the mention
<samueldr> (I personally know how RFCs can be tiring and seem to go nowhere fast, but still believe in the concept)
<gchristensen> +1
<timokau[m]> Yes me too and to be fair I think the RFC process is in a better place now than it was when it started
phreedom has joined #nixos-dev
phreedom has quit [Ping timeout: 250 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
phreedom has joined #nixos-dev