<andi->
gchristensen: since you commented on the bind issue: there used to be a disable flag for atomics or at least I vaguely remember that. Probably better then disabling. Can check later tonight back home.
<gchristensen>
ah cool
<gchristensen>
r13y.com updated last night (and I think I fixed the bug causing it to not update) -- 1280 / 1297 (98.69%)
<MichaelRaskin>
This is single-machine single-kernel reproducibility?
<gchristensen>
not exactly
<gchristensen>
r13y's builds do a single build of everything required to build iso_minimal, and compares it to what Hydra produced
<gchristensen>
and this build is done on a different machine with a different kernel than the hydra builders
<gchristensen>
is it time to move to disorderfs + multiple builders? :)
<ekleog>
a single disorderfs builder would likely already show most of what can be shown
<gchristensen>
yeah
<gchristensen>
maybe I can setup disorderfs on that machine
<ekleog>
:3
<gchristensen>
hrm?
<ekleog>
just being happy
<infinisil>
(continuing from #nixos-security)
<infinisil>
MichaelRaskin: What do you mean by rfcs#42 doesn't say anything about escaping quality standard?
<infinisil>
Ah just that people can still write shitty modules probably
<MichaelRaskin>
Not even shitty, just assuming that everything author can imagine in five minutes should be straightforward, and the rest is user's responsibility
<infinisil>
MichaelRaskin: Not sure what you mean by that
<MichaelRaskin>
Well, most module have reasons to believe that if their parameters are passed by an adversary, the game is already over.
<MichaelRaskin>
The parameters come from the same place that lists setuid binary list, after all!
<infinisil>
So people should not worry about it?
<MichaelRaskin>
There are tradeoffs and choices to make. I would reserve «shitty» for cases where input look natural and safe, but have dangerous implications
<pie_>
(i say "its not really a problem" isnt a reason to not design out bugs)
<MichaelRaskin>
Well, there are a lot of interesting problems, a lot of bottlenecks, and a lot of problems that bite everyone from time to time. Fixing the escaping corner cases around trusted input is boring, complicated, and doesn't bring much utility to people…
<pie_>
i dont see it as escaping trusted input, but maybe youre right about the rest
<pie_>
actually no
<pie_>
but maybe there are more important things
<MichaelRaskin>
What is your model for considering system configuration untrusted input?
<MichaelRaskin>
I can actually imagine quite a few, but they would be niche≤
<pie_>
my "ok its not about untrusted input" is bugs
<pie_>
weird filenames, idk?
<MichaelRaskin>
That's why I said that there is a question whether the problems are in situations that look safe
<pie_>
the system should not break on arbitrary unenforced safe character conventions, it will, but it shouldnt
<MichaelRaskin>
Right now weird filenames in store would cause a ton of interesting effects
<MichaelRaskin>
The most annoying implication is that the store with a space in the store root path will not work…
<pie_>
we could just use that one filesystem thing that forbids unsafe characters (cant find it right now)
<pie_>
MichaelRaskin, unquoted $out or deeper problem?
<MichaelRaskin>
Mere unquoted out can be fixed by quoting it
<MichaelRaskin>
But we pass buildInputs as space-separated environment variable…
<pie_>
anyway, i was on about shellchecking everything yesterday, im trying to think of blanket solutions in the back of my mind
<pie_>
MichaelRaskin, well :p
<gchristensen>
(a common myth is that $out is always safe, but this is not true if the nix store prefix is not "/nix"
<MichaelRaskin>
gchristensen: it actually _is_ safe, I give you less than 25% chances to make stdenv work with space-containing path to store
<pie_>
gchristensen, havent heard that myth yet, i just figured its not broken because noone would dare use /root with spaces lol/
<pie_>
MichaelRaskin, lol
<pie_>
safest code is the one that doesnt run right
<gchristensen>
haha
<MichaelRaskin>
It's not noone would dare use, it's the people who know enough to consider trying know that some problems would take just too much effort to fix
sphalerite has quit [Quit: reboot time!]
<Profpatsch>
I think we can assume as a precondition that the prefix will always be /nix/store/
<Profpatsch>
Else it’s not nix anymore
<Profpatsch>
e.g. guix uses /gnu/store
<gchristensen>
nah, can't assume that
<MichaelRaskin>
That's a harmful assumption
<Profpatsch>
We can make it a precondition of nixpkgs
<Profpatsch>
And de-facto it is
<MichaelRaskin>
It is not really
<Profpatsch>
So we should specify it
<gchristensen>
we really can't
<MichaelRaskin>
As long as there are no spaces, stuff generally works
<Profpatsch>
So there is a precondition
<MichaelRaskin>
And this is _useful_
<Profpatsch>
For what exactly?
<Profpatsch>
Is there any useful application of changing your store path to something that is not /nix/store?
<gchristensen>
having stores outside of /nix
<Profpatsch>
That’s what bind-mounting is for
<MichaelRaskin>
Cross-compiling to places where you have executable /home/user/ but root access is more complicated?
<Profpatsch>
The name does not change in that case
<Profpatsch>
That’s also for bind-mounting
<gchristensen>
can't bind mount on macOS
<MichaelRaskin>
No, bind-mounting requires root or nonparanoid kernel config
<pie_>
^i was about to ask
<Profpatsch>
Do we support it with nixpkgs?
<gchristensen>
to some degree, yeah
<Profpatsch>
Do we *want* to support it with nixpkgs?
<gchristensen>
not sure why we wouldn't
<pie_>
there were issues about wanting it but not being able to do it yet
<pie_>
theres no technical reason we couldnt to my very limited knowledge
<pie_>
its an engineering problen
<infinisil>
Profpatsch: Having the nix store be in /home/alice/nix is the only guaranteed way to have nix work without root privileges
<Profpatsch>
Meh, I’ll be quiet now. I think it doesn’t make sense.
<Profpatsch>
Because of recompilation of the world, mainly.
<pie_>
i think infinisil's use case is the immediate one and itd be nice
<MichaelRaskin>
Yes, so what?
<Profpatsch>
It breaks all of our infrastructure, for minimal gain
<pie_>
well yeah
<MichaelRaskin>
Recompulation is cheap
<Profpatsch>
Recopulation :)
<MichaelRaskin>
Come on, a few days from zero to LibreOffice
<Profpatsch>
^ spotted the Gentoo user
<gchristensen>
iso_minimal in only 6 hours on a laptop
<pie_>
@ recompilation. on that note, i dont know how to find the github issues for this right now. but could we just use one of those rpath varibles to get it to work?
<pie_>
Profpatsch, lol
<gchristensen>
NixOS has the title of "most recompilations" tbh
<MichaelRaskin>
I tried Gentoo for less than a day, it's bullshit
<pie_>
:D
<MichaelRaskin>
I tried it after A/B LFS, though
<gchristensen>
we rebuild way more often than the gentoo people :)
<pie_>
gentoo was nixos before nixos was cool?
<MichaelRaskin>
Yep
<MichaelRaskin>
That was about rebuilds
<pie_>
:P
<MichaelRaskin>
No, before NixOS was there, there was A/B LFS
<MichaelRaskin>
(Automated + Beyond Linux From Scratch)
<pie_>
oh
<gchristensen>
nice
<MichaelRaskin>
It still exists, actually
sphalerite has joined #nixos-dev
<clever>
i ran LFS on my router for a year or 2
<gchristensen>
haha
<MichaelRaskin>
I ran A/B LFS on my laptop for a couple of years
<MichaelRaskin>
Three installations: plain one, installation with make_uninstall, and an installation with Funionfs for splitting actual files per-package
<gchristensen>
(...responsibilityunfs...)
<MichaelRaskin>
Yes, switch to NixOS was a decrease in complexity (I did go through Debian unstable in between)
<ekleog>
Profpatsch: a friend of mine has been using nix on a centos (no userns) cluster where they're not root
<ekleog>
(to be precise for this particular case there is also a strong limitation in disk space * kept time, which means they ended up with using proot for nix, and… basically it kind of works kind of not works, afair)
<Profpatsch>
ekleog: nix or nixpkgs?
<ekleog>
nix and nixpkgs
<pie_>
Profpatsch, why artificially limit the portability of nixpkgs? P: *COUGH*
<ekleog>
(using nix without nixpkgs is kind of a PITA, as it implies re-doing bootstrapping of the compilers)
<MichaelRaskin>
I have used Nix with non-default root to cross-compile various tools from Nixpkgs to a moderately weak device with Linux and user application support but problems with full root access
<pie_>
(why have buildroot when you can nixpkgs)
sphalerite has quit [Quit: WeeChat 2.2]
sphalerite has joined #nixos-dev
<andi->
gchristensen: can you free up some space on the aarch64 community box? ^^ Preferably without a reboot.. I think I have a solution for the bind issue.
<gchristensen>
have you tried a simple GC?
<gchristensen>
if yes I can go do more GC :)
<andi->
did that just now
<andi->
8GB free again
<andi->
should be enough..
<gchristensen>
looks like 404G free?
<andi->
I just told me that it was out of space during building
<gchristensen>
oh
<andi->
tmpfs 63G 63G 43M 100% /
<clever>
ncdu -x /
<pie_>
clever, oh that looks nice
<gchristensen>
ok 34g free
<andi->
thanks
jtojnar has quit [Ping timeout: 258 seconds]
jtojnar has joined #nixos-dev
{^_^} has quit [Remote host closed the connection]
<arianvp>
Is there a way to stop nixos-test-driver from spitting out logs whilst you're using it interactively?
<arianvp>
Im trying to debug why a service keeps restarting, but my prompt keeps disappearing because journald is spitting out restart logs
<arianvp>
which means I need to type all the perl commands blindly
{^_^} has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
justanotheruser has joined #nixos-dev
<flokli>
arianvp: I guess you could tweak the cmdline when running to not log to console
<gchristensen>
r13y.com is harder than I anticipated. sometimes hundreds will fail and I don't catch that as an anomoly
<tilpner>
"519 / 1297 (40.02%) are reproducible!" D:
<gchristensen>
yeah I should really just fail if some are unbuildable
justanotheruser has quit [Ping timeout: 258 seconds]
<MichaelRaskin>
Well, if a build cannot be reproducibly run…
<MichaelRaskin>
ENOSPC?
<gchristensen>
they fail the first time
<gchristensen>
which means they failed to substitute
<gchristensen>
just added more logging
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
<samueldr>
thanks aszlig for the manual build fix :)
<aszlig>
samueldr: that was ages ago :-D
<samueldr>
hours!
<samueldr>
oh, or much more than hours, I didn't look at the timezone :) was looking at the failure in hydra and preparing to fix
init_6 has quit [Ping timeout: 246 seconds]
<niksnut>
urgh, what the hell happened to meta.platforms?
<samueldr>
niksnut: details?
<niksnut>
try 'nix-env -qaA nixos.geeqie --json'
<niksnut>
and you get all this crap about ABIs and kernels
<samueldr>
yes!
<niksnut>
and floating point formats and executable formats
<samueldr>
I was about to ask if it was about how they're now those weird object
<samueldr>
the packages listing on the site is broken since this was added
<samueldr>
well, platforms listing in the packages listing
drakonis has quit [Ping timeout: 264 seconds]
<niksnut>
we should revert this
<niksnut>
especially since the thing that actually matters (e.g. "x86_64-linux") is missing!
drakonis has joined #nixos-dev
<infinisil>
Hmm.. could nix-env be changed to display this better maybe?
<niksnut>
no
<niksnut>
because it's pointless to include this info
<niksnut>
what's the use case?
<samueldr>
and some are too "primitive" to show up as something like x86_64-linux, iirc
<samueldr>
at least, I couldn't find any way to make them go from their complex types to the user-friendly ones
<infinisil>
samueldr: I'm thinking to go through a list x86_64-linux, darwin and aarch, it could check whether each of them are covered by meta.platforms (with the meta checks we have), and then build a list from that
<infinisil>
Like filter checkMeta [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" ]
<infinisil>
checkPlatform*
<infinisil>
But yeah that doesn't really work for nix-env -qaA --json :/
<pie_>
fwiw I have run into lib functions I expected not to exist but they did, and I was like "yay", and then "wow that implementation is pretty trivial..."
<pie_>
ah, sorry for the spam "Worth noting that Swift ultimately decided against isEven and isOdd (still not sure that was right, but we can revisit it), in favor of the more generic isMultiple(of:)."
<pie_>
MichaelRaskin, Profpatsch gchristensen , accidentally found what i was looking for in one of my tabs: https://lwn.net/Articles/686789/ Safename: restricting "dangerous" file names