<gchristensen>
it is a bit weird. github uses the login for a lot of things, but it creates a race condition
<gchristensen>
I can't add a person to a team by ID
<aanderse>
oh...
<aanderse>
:\
drakonis_ has quit [Ping timeout: 245 seconds]
<gchristensen>
right. so I've built this tool to add github IDs to the maintainer list, and part of that is fetching the commit from github's API to see what github login *they* think is associated with that commit. that is wehre that tilpner / sterfield confusion comes in - tilpner corrected their entry :)
<tilpner>
Oh, hi
<tilpner>
sterfield wasn't a maintainer at all, just sent a closed PR a while ago
<gchristensen>
yeah so that is fine, just a demonstration of assorted problems with github logins as keys
<tilpner>
I don't understand the issue yet
<tilpner>
(Neither sterfield nor me were changing names AFAIK)
<gchristensen>
yes, but how does the automation know that?
<gchristensen>
that is the problem, taking teh github names whichmay or may not be correct and confidently deciding yes that is the same user to day as it was then
<tilpner>
Oh, so the problem is just that I'm not the person I added, okay
drakonis1 has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<gchristensen>
and again it isn't really a problem :)
<domenkozar[m]>
niksnut: currently diskcache in Nix clears out periodically, but that's not precise enough (also a bit misleading as setting negative cache to 0, it will actually remove entries just each day. Why not just delete entries as they are retrieved?
<domenkozar[m]>
)
<niksnut>
yes, that's to prevent doing a lot of work purging the cache
<niksnut>
you don't want every nix invocation to have to do a full scan of the table
<domenkozar[m]>
it's not a full scan if you use an index
<domenkozar[m]>
and the table won't end up being huge (millions+ rows) since it's constantly purged
<niksnut>
yes, but then you need to maintain an index
<domenkozar[m]>
I mean: CREATE UNIQUE INDEX idx_nars ON NARs (hashPart, cache)
<domenkozar[m]>
so here's the situation right now that happens to me from time to time
<domenkozar[m]>
1. want to build something
<domenkozar[m]>
2. theres no narinfo in caches
<domenkozar[m]>
3. ah crap! I was too fast, wait 2min
<domenkozar[m]>
4. want to build again
<domenkozar[m]>
5. it's in cache, but Nix says it's not
<domenkozar[m]>
then there's no way to recover rather than nuke sqlite db
<domenkozar[m]>
that's because the purging only happens every 24h, I guess it would suffice to expose a diskCache.purge() and then a cli option to invoke that
<domenkozar[m]>
but I think it would be better to use an SQL index and just invalidate on cache hit
<niksnut>
ehm
<niksnut>
the TTL is supposed to be checked even for entries that are in the cache
<niksnut>
"select present, namePart, url, compression, fileHash, fileSize, narHash, narSize, refs, deriver, sigs, ca from NARs where cache = ? and hashPart = ? and ((present = 0 and timestamp > ?) or (present = 1 and timestamp > ?))"
<niksnut>
which checks the timestamps against ttlNegativeNarInfoCache and ttlPositiveNarInfoCache
<domenkozar[m]>
hmm, then maybe it's not applied correctly
<domenkozar[m]>
ok I'll investigate.
<niksnut>
btw if you have a long-running process, you also have to worry about the in-memory cache
<niksnut>
pathInfoCache
<niksnut>
that one doesn't have any TTL
v0|d has joined #nixos-dev
<domenkozar[m]>
and there's one for each substituter
<v0|d>
anybody has an ppc installer or should I throw the old machine away and forget 'bout it?
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
evanjs- has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
<gchristensen>
samueldr: I'm going to be doing some docs stuff today
<samueldr>
nice
<disasm>
I'm planning on hitting PR review pretty hard today. If anyone has anything in particular they want me to look at ping me here.
averell has joined #nixos-dev
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
<gchristensen>
yay disasm
orivej has joined #nixos-dev
evanjs has quit [Ping timeout: 246 seconds]
<infinisil>
I'm a bit lost here, peti made a PR with a bunch of commits, which I reviewed. At that point however he already pushed parts of the PR's commits to master directly. Then he opens a new PR rebased on top of those changes, which he merges without my review
<infinisil>
Him being a nixpkgs committer for much longer than me makes me doesn't help
<gchristensen>
aye, some old-school contributors are not thrilled about using PRs
<NinjaTrappeur>
Anybody knows why nix is ignoring the unreadable key files? https://github.com/NixOS/nix/blob/master/src/libstore/crypto.cc#L118 . It has an annoying side effect: if nix can't read a public file, he won't sign the distributed NARs and won't warn about that.
<samueldr>
while it doesn't count for nothing, I think the authority by seniority shouldn't be played in that situation
<NinjaTrappeur>
r/public file/keyfile
<gchristensen>
NinjaTrappeur: it should probably not ignore it :)
<gchristensen>
seems like a major bug
<NinjaTrappeur>
right :)
<NinjaTrappeur>
That's good: I started writing a fix and feared I missed something obvious
<niksnut>
it's as the comment says: keys are generally unreadable to non-root users
<infinisil>
gchristensen: samueldr: I guess I'll tell him that nowadays the consensus is to not push anything to master directly unless it's an emergency or so
<gchristensen>
infinisil: mind if I post that?
<aanderse>
gchristensen++ samueldr++ infinisil++
<{^_^}>
gchristensen's karma got increased to 145, infinisil's karma got increased to 130, samueldr's karma got increased to 110
<infinisil>
gchristensen: No feel free to
<emily>
I assume the long-term intention is to have only a bot be able to push to master, Rust-style?
<gchristensen>
I think overall a lot of people would like that
<gchristensen>
but also some of the long time contributors are not thrilled
<aanderse>
most places you work people who have been around forever are slow to accept change
<aanderse>
there is value in striking a balance
<emily>
I mean, the trust model gets pretty unpleasant if there's billions of people who can arbitrarily force-push at any time
<emily>
even Debian is finally forcing people to not upload their own binaries these days
<gchristensen>
finally
<gchristensen>
thank goodness we haven't ever(?) done that
<simpson>
emily: I think that the long-term intention includes flakes as a method of decentralizing maintainership. Perhaps some maintainers will have to take on a role as integrator.
<emily>
*nod* more decentralization sounds nice in theory, though part of what I find so valuable about nixpkgs is it being a unified monorepo containing Every Piece of Build Infrastructure you could want in a (vaguely) coherent and (vaguely) consistent fashion
<aanderse>
emily++
<{^_^}>
emily's karma got increased to 4
<aanderse>
monorepo makes it easy to grok
<adisbladis>
Is there really any point to being able to push to master right now?
<adisbladis>
I mean.. I do it too on occasion but I'd like for it to disappear.
<emily>
looks like the response was to push to master again >.>
<gchristensen>
fwiw, peti isn't going to stop pushing to master today and it probably won't help much to be further annoyed about it
<emily>
I definitely worry about version incompatibility and things getting out of sync with the flakes approach
<emily>
but then those happen in nixpkgs too sometimes, so eh...
<infinisil>
gchristensen: Great.. peti fixes his mistake by pushing to master..
<simpson>
infinisil: There *is* something to be said for honor and legacy; when somebody's done something in a certain way for over a decade, don't expect change overnight. (Wasn't there an RFC for the PR model?)
<simpson>
One day you, too, will realize that you've been pushing to master on a shared repo for years without considering others' workflows.
<gchristensen>
(or doing the equivalent)
<infinisil>
It's just that we *just* called him out on it
<gchristensen>
he doesn't see it as a bad thing
<infinisil>
And I was'nt even finished with my review, I just left another comment a minute ago
<gchristensen>
this has been part of why I've been so slow with ofborg to develop its features, to help support and nudge towards more idealized workflows with honey
<gchristensen>
largely it has worked, but some long-time contributors don't always see it
<simpson>
Align the incentives. Why should they change? What benefit will they see?
<gchristensen>
exactly
drakonis has quit [Quit: WeeChat 2.5]
<hyperfekt>
Can anyone point me to where the Nix evaluator handles derivations it comes across?
<infinisil>
hyperfekt: Look at the prim_derivationScript function
drakonis has joined #nixos-dev
<hyperfekt>
infinisil: Oh sorry, not for creating them but instantiating them when used.
orivej has quit [Ping timeout: 245 seconds]
<infinisil>
hyperfekt: Then probably opRealise in nix-store.cc
<infinisil>
Oh wait that's realising, not instantiating
<infinisil>
You mean the process that creates the .drv files?
<infinisil>
(which is called instantiating, building the derivation is called realising)
drakonis_ has quit [Ping timeout: 264 seconds]
<hyperfekt>
infinisil: Say I evaluate '(import (fetchurl {url=... sha256=...}) {}).hello', Nix will instantiate and realise the fetchurl derivation to be able to evaluate the attribute, no?
evanjs- has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
<infinisil>
Correct
evanjs has joined #nixos-dev
<hyperfekt>
That's the part I'm looking for, not the instantiation or realization itself.
<gchristensen>
you mean the handling of import from derivation?
<hyperfekt>
gchristensen: Not quite, 'readFile [derivation]/examplefile' would be just as good an example. I've been looking through eval.cc and I can't find any derivation type.
<infinisil>
If it's not instantiation, not realisation and not IFD, I'm not sure what it could be that you're looking for
drakonis_ has joined #nixos-dev
<hyperfekt>
Ah, these must be two separate mechanisms. So I would be looking for import-from-derivation and derivation to string/path coercion respectively, I guess?
<gchristensen>
I think derivations have a __toString
<hyperfekt>
Thanks for the help, I'll see how far I can get with that later :) ++infinisil ++gchristensen
<hyperfekt>
haha infinisil++ gchristensen++
<{^_^}>
gchristensen's karma got increased to 146, infinisil's karma got increased to 131
ixxie has joined #nixos-dev
<hyperfekt>
I'm trying to implement a nix-instantiate flag that gives derivations used at eval time so I can protect them from GC.
<{^_^}>
nix#719 (by wizeman, 3 years ago, open): Nix garbage collects too much
<infinisil>
hyperfekt: I think IFD is implemented in nix-instantiate.cc, e.g. there's --read-write-mode which you can use to enabled IFD for --eval commands
<infinisil>
And coercing derivations to strings works with the outPath attribute
<infinisil>
Relevant is probably also the notion of context
<infinisil>
,context
<{^_^}>
Nix strings can have a context representing a set of derivations this string depends on. E.g. "foobar ${pkgs.hello}" has the hello derivation in its context, "foobar" doesn't have any context.
harrow has quit [Ping timeout: 258 seconds]
harrow has joined #nixos-dev
evanjs- has joined #nixos-dev
hyperfekt has quit [Quit: hyperfekt]
hyperfekt has joined #nixos-dev
evanjs- has quit [Ping timeout: 245 seconds]
evanjs has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs has joined #nixos-dev
andi- has quit [Remote host closed the connection]
evanjs- has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs- has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
drakonis has joined #nixos-dev
<ashkitten>
__monty__, samueldr: (im assuming this is the best place to discuss the idea) do you know in what part of the code nix decides how to start builders? i'm guessing i need to override that to not care whether a dependency has been built yet or not
ddima has joined #nixos-dev
<__monty__>
ashkitten: Ah, I'm not the best person to ask. I'm just a poser, haven't actually done any nixos-dev yet : )
<ashkitten>
lol, valid
<ashkitten>
also cc gchristensen since you had the silly idea initially
__monty__ has quit [Quit: leaving]
evanjs- has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs- has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
<drakonis>
is the office hours recording up yet?
qyliss has joined #nixos-dev
evanjs- has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
evanjs- has joined #nixos-dev
evanjs has quit [Killed (hitchcock.freenode.net (Nickname regained by services))]
evanjs- is now known as evanjs
evanjs- has joined #nixos-dev
valebes has joined #nixos-dev
valebes has quit [Quit: Quit]
valebes has joined #nixos-dev
valebes has quit [Client Quit]
orivej has joined #nixos-dev
ixxie has quit [Quit: Lost terminal]
drakonis__ has joined #nixos-dev
<ma27[m]>
.... and I missed it again :/
<ma27[m]>
next time I'll set a reminder to ensure that I don't forget about this as I actually like the idea :D
Guanin has quit [Remote host closed the connection]