* V
wonders how many months it'll take to get merged at this rate
<andi->
the commit message sounds weird..
<V>
which commit message?
<V>
there's like 10 of them
<andi->
err the PR title
<V>
or do you mean github's patch series summary thing
<andi->
my first impression is that it should be more smaller PRs
<andi->
one at a time
<V>
it's a number of smaller cohesive commits
<andi->
Yeah still
<V>
like I'm not a huge fan of the GitHub flow here
<samueldr>
I'm not sure it _should_ be smaller PRs
<V>
my opinion here is that it'll make it much harder to track
<samueldr>
looking quickly it seems big because of the trivial changes
<V>
and that they don't really make sense on their own
<andi->
Yeah, at a second look it might be good to go in as one. I am a bit worried about the new passthru and how we keep everyone informed that they should set that.
<V>
shellPath's been in there for quite some time
<V>
I think that my change there actually improves the error messages for that, IIRC it was just "package" before
<V>
and now it's "shell package"
<V>
I guess the description field could be fleshed out more
<V>
but the only place these are used (users.defaults), there's documentation regarding those attributes
<andi->
Yeah but I wouldn't think about that when adding an editor
<andi->
while I might read the docs for packaging
<V>
I'd absolutely miss the passthru attribute, though. the docs are pretty badly organised
<V>
and I've read through the entire thing multiple times at this point
<andi->
it is in the stdenv docs of nixpkgs
<andi->
updateScript is mentioned there
<V>
would be better if there were sections on "how to add <X> to nixpkgs"
<andi->
Maybe
<V>
problem with that is that's a whole load more work, and I don't have quite the energy or motivation to write up a bunch of new documentation rn when this module has been sitting around since May
<samueldr>
I wouldn't want to hold up that PR only for a bikeshedding of docs
<samueldr>
not saying that is the case right now though
<samueldr>
adding to the bikeshed: there should be a list of well-known passthru arguments
ris has quit [Ping timeout: 264 seconds]
<samueldr>
the fact that the release notes specifies the new options is good enough as a minimum
<V>
it is a little exhausting going over the entire set of commits there, attempting to test the entire set of editors/etc in nixpkgs, rebasing everything through almost two releases, all before even making the PR; and then having activity on it amount to mild "eh this could be slightly more clear" and then no activity for a week or two until I prod people again, is all ^^'
<V>
that's safe; setting passthru inside of a derivation is equivalent to //ing on an attrset IIRC
<V>
they're the same thing
<samueldr>
yeah, though for that initial part before contributing there's nothing we could do about it :)
<samueldr>
V: yeah, I saw that after saying
<samueldr>
hopefully no one assumes that doing that means merging modules configuration using `//` is fine
<samueldr>
(not that there's much we can do about that)
<V>
mm
<V>
I feel that says more about the state of the module system & the language syntax than it does about that example :p
ris has joined #nixos-dev
<samueldr>
yeah, as I said, not that there's much we can do about that here :)
<samueldr>
could POSIXLY_CORRECT break the system if set that way?
<samueldr>
if so, I would suggest another example, in case someone just blindly follows an example value with "correct" in the name
<V>
oh god
<V>
I wouldn't like to think
<V>
I would like to assume that people wouldn't just blindly fill in things they see in examples
<V>
we could replace it with POSIX_ME_HARDER :p
<V>
do you have any suggestions for something that isn't likely to cause problems if set?
<samueldr>
I think release notes + documentation in option description is enough as a base minimum for documentation for the change
<samueldr>
V: the colour one
<samueldr>
or any of the color ones I guess :)
<V>
uhhhh NO_COLOR? IIRC
<samueldr>
I thought there might have been one more generic
<V>
https://no-color.org/ supposedly but I'm having difficulties connecting since my wifi keeps dissociating every 5 seconds
<samueldr>
not standard per se, but good enough for an example
<V>
it's a miracle that quassel hasn't died throughout talking to you
<samueldr>
much better than accidentally POSIXfying a posixly-incorrect system
<samueldr>
quassel is quite amazing
<V>
ah there we go
<V>
or not
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
teto has quit [Quit: WeeChat 2.9]
rajivr has joined #nixos-dev
risson has quit [Excess Flood]
cole-h has quit [Ping timeout: 260 seconds]
risson has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
ris has quit [Ping timeout: 246 seconds]
<lopsided98>
Could someone take a look at #83904? It fixes a pretty big bug in the sanoid module, and IMO it really just needs someone with the proper permissions to take a quick look and merge.
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
<siraben>
What do people here use to edit the nix documentation? Looks like Emacs doesn't have a more WYSIWYG-type package for docbook
<jtojnar>
I just need tag autoclosing and auto-indenting which works fine for me in ST but if that is not enough, I have packaged https://github.com/NixOS/nixpkgs/pull/95593
kfound has quit [Remote host closed the connection]
FRidh has quit [Ping timeout: 260 seconds]
<Ericson2314>
FRidh: OK I think I read enough to know how to do it for python :)
<Ericson2314>
and I'll to make the process less miserable also :)
<Ericson2314>
globin: ^ that means I'm finally dragging myself to make a `makeScope` for splicing that sucks slightly less. I think i'm getting better about making the perfect not the enemy of the good :)
kalbasit has joined #nixos-dev
tdeo has quit [Remote host closed the connection]
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
<gchristensen>
anyone know why nixos's AMI uses wget instead of curl for fetching metadata?
<gchristensen>
andi-: so, maybe you have some ideas
<gchristensen>
to make that PR merge we need a better http client than busybox wget, because we need to issue a PUT. curl has a 40M closure, the initrd is 12M now
<andi->
printf "PUT /somewhere HTTP/1.0\r\n\r\n$DATA" | nc server 80
<andi->
?
<gchristensen>
:cold-sweat:
<gchristensen>
let's check the docs to see if they officially recommend -L
<gchristensen>
nope ... oh god ...
<andi->
gchristensen: what for do you need the PUT?
<clever>
then it will be easier to know what to strip out
<samueldr>
not saying it'll change anything, but I made the least effort possible, while you made more effort :)
<gchristensen>
would we rather add 40M to initrd, or add a niche curl to the release blockers? (cc worldofpeace )
<gchristensen>
(cc jonringer )
<samueldr>
don't we have a "boot" curl?
<samueldr>
is its closure smaller?
<andi->
I am looking for that right now
<tilpner>
samueldr: Ahh, the difference between du and path-info must be me forgetting to pass --apparent-size
<samueldr>
but you *did* disable things, while I didn't
<LnL>
gchristensen: I think we just rely on nix for fetching initially, but bootstrap tools might have a curl
<clever>
tilpner: nix generally reports the size of the .nar from when it was built (not sparse, not compressed), while du defaults to actual disk usage (rounds up to blocksize, but compression and sparse can also make it smaller)
<clever>
LnL: i think there is also a curl used to fetch curl
<clever>
15 , # The `fetchurl' to use for downloading curl and its dependencies
<clever>
17 fetchurlBoot
<clever>
16 # (see all-packages.nix).
<LnL>
fetchurlBoot uses nix
<tilpner>
clever: Good catch on checking dynamic first
<gchristensen>
I mean, how much of the spec do we need to implement anyway
<clever>
LnL: the comment in the stdenv says to look at all-packages.nix, but it no longer exists there!
<ajs124>
worldofpeace: apparently saturday will finally cross below 0°C around here, so it'll be nice and cold :D
<samueldr>
I don't like how it adds to the system an elf interpreter; testing build outputs on those systems is now not guaranteed
siraben has quit [Ping timeout: 240 seconds]
<infinisil>
samueldr: Hm yeah..
<samueldr>
while I understand the concept and understand why it's needed for many, this puts a big caveat with results
<ajs124>
Mic92: you're famous :O
<gchristensen>
I like the idea, I agree with that and wouldn't want it enabled by default -- but maybe a user command similar to how macos' M1 lets you start programs pretending to be x86
maralorn has quit [Ping timeout: 240 seconds]
<samueldr>
that'd be nice if we had something, let's say, fhs-run ./my-app
<gchristensen>
yea
<samueldr>
like steam-run, you know
<samueldr>
;)
<samueldr>
(what I mean, tongue-in-cheek, is that everything's there already for that)
<aterius>
What are the advantages of this over steam-ruN? I get the approach is different ofc
<worldofpeace>
ajs124: awww. Okay, but like u can still see the sun right? Not like winters in iceland
<samueldr>
it doesn't run in a different context, except for the required environment variable
<samueldr>
while a steam-ran binary runs in a... container?
maralorn has joined #nixos-dev
<infinisil>
probably just a mount namespace
<infinisil>
I'd hope at least
<samueldr>
ajs124: we've had under-zero C temps for a couple of days already :)
<samueldr>
but yeah, that means that processes started from *that* steam-ran process also inherit that weird environment
<samueldr>
while with nix-ld they're in the same environment as normal, except for the inherited env var
<samueldr>
(which could cause unexpected behaviour with running an app through nix-ld through one that already ran through nix-ld I guess)
<aterius>
Makes sense!
<samueldr>
"see, I can run app $foo fine when I started it from $bar, but not from $quux!"
<samueldr>
it'd be interesting to see the same concept use files rather than environment vars to describe depedencies of a binary
<samueldr>
not sure how the file lookup could be done
<samueldr>
on binary hash it would be annoying to update every time, on binary name it could cause conflicts, on binary full path you lose the ability to just put it anywhere... so maybe side-by-side with the executable? e.g. for ./foo, ./foo.nix-ld
<worldofpeace>
overall there's a lot of changes needed
<gchristensen>
worldofpeace: yeah :) needs to go to stable, as right now the AMI doesn't work if you turn on the "be less insecure" option :)
danielrf[m] has joined #nixos-dev
<worldofpeace>
Oh right, I've actually used the AMI's a few times for 20.09
<V>
Arch is actually better than NixOS if you look at the numbers IIRC
<infinisil>
gchristensen: I've had an idea like this a while ago, but it would be really useful for this: Trace the syscalls of a curl call to figure out which paths that exact call needs, and no others
<infinisil>
This should minimize dependencies if in the end you really only do a a single call
<infinisil>
Although, dynamic libraries probably get loaded at the start, even if their symbols aren't strictly needed
costrouc has joined #nixos-dev
<samueldr>
V: it's... more nuanced than that and it can be interpreted in either ways IIRC
<samueldr>
but I can agree that this graph is garbage for either of AUR and nixpkgs
<samueldr>
it lacks context
<V>
so many of the things in nixpkgs and AUR are just packages that were added once and will never be updated, or which happen to have unique names
<samueldr>
yeah
<samueldr>
that's basically the main point of contention imo
<V>
and every time someone pulls that graph out and says that nixpkgs is better than the rest I wince a little
<samueldr>
tbf, it also lacks other context
<samueldr>
e.g. it's lacking a couple of attrsets that are not recursed into
<samueldr>
but that's things that generally are not "packaged" in other distros!
<samueldr>
so you'd need an *area* rather than a point for Nixpkgs
<V>
right, it also contains chunks of other entire package repositories
<gchristensen>
I think the real thrust of the message, to me, is "its fairly big and fairly up to date" and not so much about claims about specifically ofbeing better
<gchristensen>
but thats just what I see in that
<samueldr>
yeah, but you know, stats you can make them say anything
<samueldr>
Nixpkgs is bloated
<samueldr>
Nixpkgs cannot be maintained, it has too many packages
<gchristensen>
yeah
<samueldr>
RubyGems is the perfect distribution sweet spot