infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
mbrgm has quit [Ping timeout: 248 seconds]
mbrgm has joined #nixos-dev
orivej has joined #nixos-dev
taktoa has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
orivej_ has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 256 seconds]
<dtz>
yaaaay basic nixos test working on musl! \o/
<dtz>
qemu, systemd+all init-y things. Still lots of cleanup and such but wooooo :D
pie_ has joined #nixos-dev
<ikwildrpepper>
globin: yes, it'll be released asap, had some family stuff that has priority unfortunately
<ikwildrpepper>
tests have run successfully, once release notes are written, i'll push the release
davidlt_ has joined #nixos-dev
MichaelRaskin has quit [Quit: MichaelRaskin]
pie_ has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
xeji has joined #nixos-dev
<vdemeester`>
o/
<vdemeester`>
quick question, did sthg change with nix 2.0 on how channels "work" ?
<vdemeester`>
upgraded to nixos 18.03 (and thus having nix 2.0) and my nix-channel --update now returns 404 so I guess, it's not looking at the same file anymore ?
xeji has quit [Quit: WeeChat 2.0]
obadz has quit [Quit: WeeChat 2.0]
<ikwildrpepper>
vdemeester`: no, what is the contents of ~/.nix-channels?
<vdemeester`>
it used to work before the upgrade but now I'm hitting a 404 although the nixexprs.tar.xz is there (the doc folder is the one published on the github pages)
<ikwildrpepper>
hm, never seen such a setup. i'll skip the question then in this case ;)
goibhniu has joined #nixos-dev
Synthetica has joined #nixos-dev
__Sander__ has joined #nixos-dev
<vdemeester`>
ikwildrpepper: np :P
<vdemeester`>
I'll probably switch to use an overlay anyway, it's cleaner :P
ma27 has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
pie_ has joined #nixos-dev
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
pie_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
davidlt_ is now known as davidlt
<angerman>
How would I generate some random temporary port number? I need some random port to communicate over with a secondary build tool while building a derivation.
<angerman>
I could launch the secondary build tool with a fixed port; but that would prevent building packages in parallel. Random of course could result in some form of collision; a sequential number generator would be even better. Best would probably be a pool of ports that can be marked as used and returned.
orivej has quit [Ping timeout: 256 seconds]
<shlevy>
:o only 20k builds in the hydra queue
zybell has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<gchristensen>
so when does 18.03 become stable?
<shlevy>
Typically just before there is no longer any place on earth in March ;)
<gchristensen>
hehe
<fpletz>
an no critical bugs :)
<gchristensen>
naturally :) I reckon it is about time to switch over to it for me
<gchristensen>
see you on the other side ....
<gchristensen>
Suspicious.
<gchristensen>
Ok there we go. I forgot to update my channel :)
zybell has joined #nixos-dev
<vdemeester`>
gchristensen: did the update yesterday, everything went super smooth :()
<vdemeester`>
(except bluetooth locked somehow)
<gchristensen>
my first boot locked up hard, second boot seems much more proper
<gchristensen>
it looks like the system generally understands HiDPI better, which is cool
<gchristensen>
Hard lock when I plug in my dock. Ok that's enough fun for this morning. I'll try debugging later
<vdemeester`>
gchristensen: oh weird.. which dock ?
<vdemeester`>
(yep same impression on HiDPI)
<gchristensen>
a Delll T*trails off mumbling some model number*
jtojnar has joined #nixos-dev
<gchristensen>
Dell Thunderbot Dock TB16
<vdemeester`>
oh ok
* vdemeester`
has a thinkpad (with the ultra dock), hyper smooth :P
davidlt has quit [Remote host closed the connection]
davidlt has joined #nixos-dev
<domenkozar>
I wished I never bought TB16
<domenkozar>
would be better to travel somewhere for that money
<gchristensen>
really? it works well for me ..
<domenkozar>
keyboard doesn't work at all
<gchristensen>
I don't have that trouble .. :/
<domenkozar>
I have literally paid 400 eur
<domenkozar>
so that I have to plug one cable instead of two
<domenkozar>
:D
<gchristensen>
wow, I paid a lot less than that :o
<gchristensen>
and mine saved me six plugs and got me a high speed ethernet adapter
<domenkozar>
394,80 €
<domenkozar>
well I'd be ok it if was ~100
<domenkozar>
anyway, lessons learned :)
<gchristensen>
mine was $200 USD...
<domenkozar>
ErrorTooManyMiddlemans
JosW has joined #nixos-dev
davidlt has quit [Remote host closed the connection]
davidlt has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
goibhniu has quit [Ping timeout: 252 seconds]
davidlt_ has joined #nixos-dev
zybell has quit [Ping timeout: 256 seconds]
davidlt has quit [Ping timeout: 240 seconds]
zybell_ has joined #nixos-dev
phreedom has joined #nixos-dev
phreedom has quit [Client Quit]
phreedom has joined #nixos-dev
stqism has quit [Remote host closed the connection]
<phreedom>
gchristensen: the earliest i see if 14th mar
<phreedom>
is*
<gchristensen>
cc niksnut -- looks like packages-unstable.json.gz is broken, but I'm able to run `make` in nixos-homepage when my host is running 18.03
<Mic92>
Profpatsch: it something else, but it has to do with our session beeing not delegated
<gchristensen>
a bit annoying that changing the installation code causes a full rebuild of nix
ma27 has quit [Ping timeout: 256 seconds]
<MichaelRaskin>
Hm, I cannot change app.update.channel for the Firefox build… I hoped to do that to disable telemetry, but it doesn't seem to work…
<MichaelRaskin>
(I mean, even app.update.channel stays «default»)
<clever>
gchristensen: i heard that grsecurity? had disabled non-root users having any kind of access to namespaces
<aminechikhaoui>
well it's for Linux < 2.13 in the comment so doesn't really apply here maybe
<Dezgeg>
linux 2.13 doesn't exist though
<Dezgeg>
probably means 3.13
<aminechikhaoui>
huh right :D
<dtz>
ha, actually go check the source code for what's allowed
<gchristensen>
I'm googling SELinux things, let me know if there are any steps I should take to debug :P
<dtz>
I was debugging Nix's clone usage for badness recently and found that clone manpage is very incorrect
<dtz>
not sure if it reflects some standard or what but since I was debugging a problem i was observing and not theoretical inspecting what the kernel does was useful
<Dezgeg>
'getenforce' tells if it's on, but I'd doubt it would return 'Invalid Argument'
<dtz>
in particular regarding what combinations of flags are valid/rejected
<dtz>
most recent pass was recent, and actually I think I discussed it here, so maybe search your logs :)
<gchristensen>
it is enforcing
<dtz>
oh dunno what selinux might add in addition haha :)
<gchristensen>
it isn't causin this (setenforce 0 didn't change the problem)
<Dezgeg>
probably it's the "linux < 3.13" problem mentioned in the source
<aminechikhaoui>
although clone man page doesn't specify that in the EINVAL possible cases
<Dezgeg>
probably nobody has updated the documentation for that
<Dezgeg>
I mean writing troff is probably more painful than writing docbook *runs away*
<gchristensen>
strong agree :P
<aminechikhaoui>
EINVAL One (or both) of CLONE_NEWPID or CLONE_NEWUSER and one (or
<aminechikhaoui>
both) of CLONE_THREAD or CLONE_PARENT were specified in flags.
<aminechikhaoui>
ah wait this explains it right ? ^
<Dezgeg>
yes
<aminechikhaoui>
that was from the manpage, didn't read it carefully first :p
<gchristensen>
recommended fix? :)
<aminechikhaoui>
recent kernel hehe
<aminechikhaoui>
donnow which namespace can be sacrificed
<gchristensen>
welll
<gchristensen>
I guess we can just not support sandboxing here
<shlevy>
Wait, I vaguely remember that manpage and it just being false
<gchristensen>
so the recommended fix can be "turn off sandboxing"
<shlevy>
That you couldn't use those together
<shlevy>
How old is the kernel?
<gchristensen>
its whatever came with the recently-updated-centos-7 box from vagrant
<gchristensen>
I'm heading out for some supper, to play a bit more later
<dtz>
how come I point that out and am told I'm being silly ;). Although I was wanting to fix that based on the man page....;
<ekleog>
turt
<ekleog>
woops
Synthetica has quit [Quit: Connection closed for inactivity]
goibhniu has joined #nixos-dev
xeji has joined #nixos-dev
davidlt has quit [Ping timeout: 276 seconds]
<dtz>
sigh helping new Nix user understand why he has to figure out how to enable sandbox in order to have builds non-broken in the default case :(
<dtz>
#EnableSandboxbyDefault
<dtz>
;)
<niksnut>
builds should not require a sandbox
<Sonarpulse>
niksnut: care to elaborate?
<Sonarpulse>
derivations should work without sandboxing?
<Sonarpulse>
new users should not worry about their machines not supporting sandboxing?
<Sonarpulse>
oh I see
<Sonarpulse>
the rest of what dtz wrote
ma27 has quit [Ping timeout: 260 seconds]
<Sonarpulse>
:/
<Sonarpulse>
yeah they should work either way....
ma27 has joined #nixos-dev
<Sonarpulse>
but that's getting close to saying "programs should work whether the language is dynamically or logically scoped"
<LnL>
I agree, definitively on a nixos like system where builds can't accidentally find system stuff
<dtz>
unfortunately builds get very little testing on non-NixOS w/o sandbox (probably for reasons including this problem) and so builds often break on non-NixOS
<dtz>
which means our users getting their feet wet (have yet to accept Nix as their lord and savior, aka use NixOS :P) are the ones experiencing the most problems
<dtz>
but I mean I do agree it'd be nice if sandboxing was not required
<LnL>
well in those cases sandboxing is more useful/important
<niksnut>
what fails without a sandbox?
goibhniu has quit [Ping timeout: 268 seconds]
<shlevy>
Should systemd failing on aarch64 be a staging merge blocker?
<jtojnar>
what is "0 - backlog" tag for?
<jtojnar>
s/tag/issue label/
obadz has joined #nixos-dev
<gchristensen>
Shlevy probably yes
<Dezgeg>
it will block nixpkgs-unstable from updating, IIRC
<gchristensen>
let's embed ansible in the nix install closure
* gchristensen
says, in jest, clarifying before his commit bit is revoked
obadz has quit [Ping timeout: 240 seconds]
<Sonarpulse>
dtz: "<niksnut> what fails without a sandbox?" ?
obadz has joined #nixos-dev
<thoughtpolice>
I have an example from recently: igbvf, which is a kernel module. This kernel module runs a depmod phase during install that scans /boot, but this fails on a non-sandboxed system as it tries to probe /boot which isn't allowed by the default user, because it finds e.g. System.map and says "I will update that". If you have sandboxing enabled and /boot isn't in the chroot, then it skips over and continues. Why is this important?
<thoughtpolice>
Because I want to build NixOS closures, containing that driver, on non-NixOS...
<thoughtpolice>
In practice non-sandboxed failures are exceedingly annoying to debug and figure out. I would absolutely rather have sandboxing by default, and, relatedly, always install Linux with the build daemon and sandboxing enabled by default, in the Nix binary installer.
<thoughtpolice>
Furthermore, it often masks latent problem, or builds that seem to work but then fail horrifically later due to minor updates, because they pick up all sorts of host artifacts... I can say the only advantage of this being the default setup choice is "I got really good at diagnosing really bizarre failures because they happened frequently". In every other way (user experience, time spent) it was a massive cost.
<thoughtpolice>
Like one ridiculous example I ended up having was something like a build script looking at the symbol information of a .so in its dependency chain to determine how to dlopen it in some cases; of course the build picked up one from /usr/lib on my Fedora system instead of the Nix variant, so it dumped incompatible symbol sets. But this didn't actually make itself clear until far later, when I updated my tool (git revision update)
<thoughtpolice>
and the semantics sublty changed so my existing code which did NOT invoke the dlopen code-path now did. And everything exploded.
<thoughtpolice>
That wasn't fun.
xeji has quit [Quit: WeeChat 2.0]
<thoughtpolice>
Of course the second the sandbox was enabled it picked up the right variant in the store. I didn't care to figure out how to change the lookup ordering; I just never use Non-sandboxed builds in any way if possible, effectively making it mandatory on all my machines and projects anyway...
<gchristensen>
same, thoughtpolice
<thoughtpolice>
Oh, and igbvf is not an exotic module, by the way. It's needed for EC2 VFIO devices for ethernet in some circumstances, and amazon-image.nix enables it IIRC; you only need to try any example of building an EC2 system closure, in an way, without sandboxing, to get a bizarre and latent failure.
<thoughtpolice>
And realistically patching all of it is an incredible burden to fix all the impurties. Plus, if you're a maintainer that's active, the chance of having a sandbox enabled buils is essentially 100% anyway. If you *become* a maintainer (say by fixing a bunch of build impurities because the default install didn't sandbox anything and nobody fixes the failures), you're likely to *turn on sandboxing* to get on with your life.
<thoughtpolice>
It's a really bad situation all around, IMO. I was going to write my own installer script to avoid the one from nixos.org, tbh...
<gchristensen>
perhaps you'd like to address the problems which caused the turn-on-by-default commit to be reverted
<clever>
thoughtpolice: it does the entire nix install inside a user namespace, without the need for root, and its in a uid namespace, so i could potentially get "uid 0" and setup /etc/passwd
<clever>
although you cant nest namespaces, so nix itself cant make more to sandbox things
<MichaelRaskin>
Actually, with some care you can nest namespaces…
<thoughtpolice>
Plus, actually fixing them is a non-negligble cost -- you either go upstream to fix build impurities, or do it in the expression. But many of the build expressions are already exceedingly complicated, with a support matrix like multiple architectures * multiple OSs * multiple compilers, and now * non-sandboxed vs sandboxed builds... ugh. In some of my forks for `$WORK` I have many non-upstreamable patches, because they ignore
<thoughtpolice>
various inputs in this build matrix.
<clever>
MichaelRaskin: without ever getting root?, it failed to run an identical namespace within itself for me
<MichaelRaskin>
unshare?
<thoughtpolice>
The complexity is too much for any packages with non-trivial complexity IMO. I could clearly go on about this forever...
ma27 has quit [Ping timeout: 264 seconds]
<clever>
if (unshare(CLONE_NEWNS | CLONE_NEWUSER) < 0) {
<clever>
MichaelRaskin: this line of code fails, if you try to nest it within itself
<thoughtpolice>
gchristensen: TBF I was under the impression nobody had gotten around to rewriting the install script, but if it was done, and disabled -- yes, I think that's the right thing to do.
<gchristensen>
I mean ... I've rewritten the install script recently ...
<MichaelRaskin>
clever: you skipped one part of the pain
<MichaelRaskin>
User mapping needs to be set up on every step
<gchristensen>
but what does the install script have to do with sandboxing defaults?
<clever>
MichaelRaskin: this program does set it up
<clever>
MichaelRaskin: line 205-210
obadz has quit [Quit: WeeChat 2.0]
<clever>
CLONE_THREAD. Since Linux 3.9, CLONE_NEWUSER also automatically implies CLONE_FS. CLONE_NEWUSER requires that the user
<clever>
ID and group ID of the calling process are mapped to user IDs and group IDs in the user namespace of the calling process
<clever>
at the time of the call.
<MichaelRaskin>
Hm, let me see if telling nsjail to not freeze the groups lets me nest
<thoughtpolice>
gchristensen: It does not enable sandboxing and multi-user daemon by default when installed on non-NixOS, does it not?
<clever>
MichaelRaskin: this is from the unshare() man page, and i believe what i tracked my problems down to
<clever>
thoughtpolice: single-user installs dont even get root by default, so there are no build users and no sandboxing
<gchristensen>
thoughtpolice: the macos one is multi-user by default. sandboxing is disabled by default, but doesn't require a rewrite.
<clever>
thoughtpolice: and if you even try to use it as root, it fails, because nix-daemon assumes uid 0 means it has build users
<gchristensen>
also see my message earlier today, I'm just about done making the linux installer be multi-user on systemd-based linuxes.
<thoughtpolice>
clever: Right, the Linux non-NixOS installer is rather far behind.
<thoughtpolice>
Well or it was, until now!
<clever>
gchristensen: ah, nice, that would help a lot
<thoughtpolice>
gchristensen: 👍
<gchristensen>
a few annoyances left to fix tomorrow :)
<gchristensen>
and then deduping the code that I borrowed from the mac one.
<MichaelRaskin>
clever: I think I managed to do double unshare
obadz has joined #nixos-dev
<gchristensen>
the tricky thing about enabling sandboxing by default in the installer is (apparently) all the very not uncommon kernels which don't support it , and having proper detection
<clever>
gchristensen: using the nix-bundle code i linked above, you could write a c util that test-drives namespacing, and decides yes or no
pie__ has joined #nixos-dev
<gchristensen>
that sounds like a thing I really don't want to do rightt now :P
<Sonarpulse>
how close are we to having nix daemon as non-root, not in unshare
<Sonarpulse>
provided the user has the right capabilities?
<gchristensen>
first: daemon. later, when we're more strategically ready, sandboxing
<Sonarpulse>
+1
<Sonarpulse>
seems fine
pie_ has quit [Ping timeout: 260 seconds]
<clever>
MichaelRaskin: i'll need to test that when ive got some time free
<MichaelRaskin>
Sonarpulse: you mean enough capabilities to perform UID isolation?
<clever>
MichaelRaskin: and investigate what its doing differently
<Sonarpulse>
MichaelRaskin: sure
<Sonarpulse>
though
<Sonarpulse>
if we could just do name spaces
<Sonarpulse>
and not even have build users
<MichaelRaskin>
clever: I do not claim this approach is actually usable exactly for what you want, I just managed to reproduce what I wanted to describe saying that nested namespaces seem to work
<clever>
MichaelRaskin: and you ran all that without root from the start?
<MichaelRaskin>
Yes, it is started as an ordinary UID=1000 user on a system where the list of setuid binaries is «su, fusermount, fusermount3, unix_chkpwd»
<clever>
that should be usable then
<MichaelRaskin>
Sonarpulse: you mentioned capabilities without namespaces — I think having a full-featured daemon there means it is effectively root
<Sonarpulse>
MichaelRaskin: with users, it needs to be able to override the build users + build users group stuff
<Sonarpulse>
but without
<Sonarpulse>
it just needs to setup mount and network namespaces?
<Sonarpulse>
I'm very out of date on the details
<MichaelRaskin>
Yes, that seems perfectly doable.
<MichaelRaskin>
And preferably you only use the store in the namespace
<MichaelRaskin>
To prevent accidental modification…
<clever>
MichaelRaskin: one issue i ran into during testing, the /etc/protocols symlink on nixos points into the store
<clever>
but the new /nix from the namespace lacks that target
<clever>
so my namespaced program doesnt know what udp is!!
<clever>
so i have to merge /etc/resolv.conf from the host, and /etc/protocols from my bundled store
<clever>
and then deal with dbus being weird, where it complains about a missing file, then crashes the program a few seconds later, after other warnings
<clever>
misleading you into thinking the error and warning states are the other way around
<gchristensen>
we need to get 18.03 so I can oggle my docs changes
<Mic92>
dtz: -fomit-frame-pointer by default sounds like a good idea to me
<Profpatsch>
Mic92: Maybe ./configure ... --with-default-hierarchy=legacy will do the trick?
<Mic92>
Profpatsch: you mean meson; time flies
<Mic92>
I am not sure what the current state of cgroup hierachies is
ma27 has joined #nixos-dev
<Profpatsch>
Mic92: Nah, systemd
<Mic92>
Profpatsch: I am also not sure, if that cgroup, that creates the error for you is supposed to be writeable
<Mic92>
it is also weired that the analyze command tries to create a scope
<Mic92>
I probably should test this on arch or fedora