sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
sir_guy_carleton has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.4]
Synthetica has quit [Ping timeout: 248 seconds]
Synthetica has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
emily has quit [Remote host closed the connection]
emily has joined #nixos-dev
emily has quit [Remote host closed the connection]
emily has joined #nixos-dev
<Synthetica> Could someone take a look at #62675?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/62675 (by Synthetica9, 2 days ago, open): waybar: 0.6.6 -> 0.6.7
<nbp> niksnut: There is a JavaScript package managment war going on … The NixOS Foundation should fight to make Nix a distribution medium for JavaScript, even on Windows, and even if we do not yet have the same safety as we have on Linux-es.
<nbp> niksnut: Not suggesting yet another package manager, but provide integration for the best package manager solutions.
<nbp> https://2019.jsconf.eu/videos/ 50% of these presentations are about distributing packages … with different solutions.
<niksnut> nbp: the foundation has no ability to do that...
<manveru> nbp: we don't have a good alternative either, only tools that enable building the packages with nix, but none that handle dependency resolution (afaik)
orivej has joined #nixos-dev
init_6 has joined #nixos-dev
<niksnut> yes, also I don't see the JS community embracing a non-JS tool
<nbp> niksnut: The foundation has a word on where to allocate money, and potentially intentions.
<nbp> niksnut: I am sure that if you are sending a message to find a solution among the Nix community, you will get some momentum.
<nbp> One interesting avenue of development, would be to offer Nix bindings in Node.
<nbp> Such that these package managers could handle build outputs in Nix.
<nbp> Then exporting these lock-files as Nix expression would be a plus for integrating it in NixOS, and simplifying the distribution aspect.
emily has quit [Quit: Updating details, brb]
emily has joined #nixos-dev
v0|d has quit [Ping timeout: 245 seconds]
arianvp has joined #nixos-dev
<Profpatsch> nbp: I just hope that my yarn2nix tools won’t be outdated in half a year :)
<Profpatsch> gchristensen: Should we remove the -f #nixos-unregistered flag from this channel?
<gchristensen> sure
<Profpatsch> I don’t think there have been many spam attacks recently.
<gchristensen> there have been a couple, but this channel is much smaller than #nixos
<Profpatsch> gchristensen: You have the op flag, right?
<gchristensen> yeah
<Profpatsch> cool
<ekleog> is FRidh reachable over IRC or similar? I just wanted to have a chat about potential improvements to our python architecture with them
<ekleog> (ie. the “trying to use sys.meta_path to get static linking to python and get rid of python.withPackages and propagatedBuildInputs” idea I was raising here the other day)
<LnL> he's in #nixos sometimes
drakonis_ has quit [Ping timeout: 248 seconds]
<LnL> I would also love to change the way propagated inputs and PYTHONPATH currently work, it completely breaks with multiple interpreter versions
drakonis_ has joined #nixos-dev
<ekleog> right now I'm thinking we can get RPATH into the python world by using enough “sys.meta_path” hackery
<ekleog> (which would require to patch python to include one “nixos” sys.meta_path entry, that'd read the store path to figure out the directories to check)
<ekleog> if we can get that, then we can stop using propagated inputs for python and be forever happy
<ekleog> also, thank you, I'll go check over #nixos from time to time to try and speak with him about it :)
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
ma27 has joined #nixos-dev
init_6 has quit []
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
Jackneill has quit [Remote host closed the connection]
avn_ has quit [Ping timeout: 258 seconds]
avn_ has joined #nixos-dev
drakonis has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
<matthewbauer> niksnut: have you looked at this issue: https://github.com/NixOS/nix/issues/2636 ? lots of debian users hit it, and there's not clear guidance for users
<{^_^}> nix#2636 (by thomasjm, 20 weeks ago, open): Can't install Nix 2.2.1 on clean Ubuntu 18.04 (error: cloning builder process: Operation not permitted)
<matthewbauer> niksnut: at least it would be good to have some guidance when "unshare" fails on how to fix (for debian you can run `sysctl -w kernel.unprivileged_userns_clone=1`)
<niksnut> we should probably fall back to not using a user namespace
<matthewbauer> yeah that makes sense. tbh i don't think anyone would mind if we just set kernel.unprivileged_userns_clone for them. the fact that debian disables user namespaces seems bad
<niksnut> no I don't think we should mess with kernel settings
<catern> matthewbauer: unprivileged user namespaces have had a lot of kernel vulns in the past, it's died down a bit now but it's very reasonable to disable it by default
<catern> just fyi on Debian's motivations
<niksnut> dammit, nixos doesn't even have kernel.unprivileged_userns_clone so that makes it harder to test
<matthewbauer> catern: there's tons of kernel features that *could* have vulnerabilities though, singling out a very useful one like userns, seems like a weird decision
<matthewbauer> but maybe there is more in consideration
<niksnut> I mean, the nature of user namespaces makes them inherently risky
<aminechikhaoui> I think I've seen the same issue in CentOS as well, they do disable userns by default as well
<matthewbauer> it's weird it's not upstreamed to linux? at least with the default set to on
<aminechikhaoui> centos for instance does things differently https://github.com/NixOS/nix/issues/2632#issuecomment-481701310
<matthewbauer> yeah there's a bunch of these patches floating around
<matthewbauer> ugh and centos doesn't even give EPERM!
<LnL> adding a nice error message around it would help a lot
<catern> matthewbauer: re: upstreaming, see https://lwn.net/Articles/673597/ for some color on tha
<catern> t
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 252 seconds]
drakonis has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
<emily> matthewbauer: it's a very useful feature that lets unprivileged users be uid 0, which the kernel is historically terrible at not taking to mean ultimately privileged
<emily> so it's also a feature with a massive vulnerability surface
<samueldr> correct my assumption, but it looks like the only reason it's run in a VM is because of that assumption, which can be done in another way
<samueldr> hm, maybe not, there's the switch-to-configuration call
<samueldr> (which could be done in a boot step like sd-image does I guess)
<samueldr> hm, except for bootloader which would mean more glue code
jtojnar has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]