<{^_^}>
nixos-weekly#75 (by domenkozar, 5 days ago, open): Call for Content: 2019/02
<domenkozar>
if we get one more, I'll send it out!
eadwu has joined #nixos-dev
<ekleog>
niksnut: my thoughts are that nixpkgs is currently cluttered with these issues, and closing by saying “please open an RFC on this topic” would end up ,in quite a few cases where noone is motivated enough for it, in previous discussion being lost and hard to find again… but I'll let you discuss that in the next committee meeting, so long as the idea is considered it's OK with me :)
<gchristensen>
I think it is probably ok for them to die at that stage
<ekleog>
I'd agree with you, but then someone else has the same idea, opens up a new thread, and the discussion starts all over again, losing everyone's time, and no one is able to find previous discussion because there's just too many nixpkgs issues :/
<gchristensen>
we can have a needs-rfc tag
<gchristensen>
then it would have the same effect
<ekleog>
indeed, but then why not just put them (or a link to them) on the RFC repo? it'd be the first place people would think of looking for
<gchristensen>
because they're effectively dead until they choose to take extra effort, so propagating the dead issues over doesn't seem useful -- just gives the RFC issue a ton of zombies
<ekleog>
I guess it's just a disagreement on whether we want those zombies and if so, where we want them :) My position is “I do, on the RFCs repo”, and I'm not really sure whether yours is “I don't” or “I do, on nixpkgs”, but anyway it sounds like we're starting from quite different a point of views :)
<gchristensen>
I think having them labeled in nixpkgs is a good idea -- it adds metadata and enables discovery. I think copying something over to the RFC repo just adds clutter.
<gchristensen>
if the goal is prevent discussions from being lost, then a label accomplishes that just the same, no?
<ekleog>
well, it means that then when looking for prior art one needs to search in both the RFC repo and the nixpkgs repo (with a label), which IMO reduces discoverability / intuitiveness
<ekleog>
now, hopefully all further RFC issues/PRs will be redirected to the RFC repo as soon as they happen, so it should be only a problem for historic discussions
obadz has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 250 seconds]
obadz has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<gchristensen>
niksnut: should `kvm` been part of the default set of Nix features for the local builder?
<gchristensen>
niksnut: nevermind! I found my answer!
worldofpeace has quit [Remote host closed the connection]
tilpner has quit [Quit: WeeChat 2.3]
eadwu has quit [Quit: WeeChat 2.3]
eadwu has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis1 has quit [Client Quit]
Phillemann has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
Lingjian has joined #nixos-dev
eadwu has quit [Ping timeout: 250 seconds]
<infinisil>
Already, time flies!
<sphalerite>
arianvp: what's the state of your resolved work? Still just intentions or have you started on it somewhere? #50316 is relevant I suppose, which is already merged so it'll make it into 19.03 anyway
<sphalerite>
Mic92: C.UTF-8 instead of en_US.UTF-8 by default?
<gchristensen>
this won't cause the same catastrophy 18.03 -> 18.09 caused, will it?
<Mic92>
sphalerite: yes
<Mic92>
sphalerite: I mean C.UTF-8 should be by default in our glibc package, what nixos configures by default is a different story
<Mic92>
gchristensen: I think there the problem was incompatible locale archives.
<Mic92>
In that sense no.
<gchristensen>
feel free to tell me to go off and learn on my own, but why go from en_US.UTF-8 to C.UTF-8?
<sphalerite>
yeah +1 for that question really
<Mic92>
gchristensen: we currently don't do en_US.UTF-8 by default in stdenv, because you have this large locale archive package. This causes pain when doing python and also causes trouble in other applications that expect utf-8 locales. It is also a bummer in containers, where it add 60mb for no good reason.
<gchristensen>
oh, I suspect I'm missing the crux of what you want to change
<Mic92>
Yeah, I should elaborate my explanation there
<sphalerite>
ah so generate the locale for C.UTF-8 in the glibc package itself, and set the env var in stdenv?
<Mic92>
sphalerite: yes.
<gchristensen>
got it
<sphalerite>
sounds good :)
<gchristensen>
thanks, Mic92
<sphalerite>
Mic92: Have you started on this at all by any chance? or is it just a matter of intention so far?
<gchristensen>
Mic92: I'm not inclined to merge my secureboot PR unless *at least* one more person uses it for a few weeks
<Mic92>
gchristensen: How likely is it brick a device like this?
<gchristensen>
not very likely, you can always just turn off secureboot
<Mic92>
sphalerite: glibc is one these libraries where the binary is sometimes more clearer then the code itself.
<Mic92>
especially with radare's new pseudo code support
<Mic92>
sphalerite: ok. so all we need to do is to place a small generated locale-archive in $out/lib/locale/locale-archive and glibc will used instead of the $LOCALE_ARCHIVE one.
<Mic92>
not instead but as fallback if the first one is not found
<sphalerite>
gchristensen: ooooh secure boot would be awesome!