<gchristensen>
I did some quick looking, it looks like 1 in 5 contributions are pushed to abranch instead of merged
<gchristensen>
feels high. I wonder if I did it wrong
Guanin has quit [Remote host closed the connection]
<samueldr>
you're skipping merge commits, right?
orivej has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
<gchristensen>
samueldr: I'm parsing IRC logs :')
<samueldr>
oh
<samueldr>
so, PR merges/push events and not commits volume
<gchristensen>
looking for a push and a merge message from the same actor within a 10 second period
<gchristensen>
right
<samueldr>
tbf, I don't know how it would tip the balance, but commit counts or diff lines may be a better approach
<gchristensen>
yeah
<samueldr>
hmm, not necessarily better, but required for a better understanding
<gchristensen>
I'm thinkign more how many contributions would be impacted by requiring ofborg's +1
<gchristensen>
and 1-in-5 feels high :)
<gchristensen>
okay, bed time
Shados has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.5]
ajs124 has quit [Quit: Gateway shutdown]
jtojnar_ has quit [Quit: jtojnar_]
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
pie_ has quit [Ping timeout: 252 seconds]
FRidh has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
ajs124 has joined #nixos-dev
<sphalerite>
FRidh: python 3.7.4 seems to have broken home-assistant on 19.03, some equality test is failing weirdly in the install tests. Do you know off the top of your head what might cause that?
<das_j>
is there a way to get all derivations used by my system?
<das_j>
like in my system
<das_j>
not with nix-store --query
<etu>
sphalerite: Theory: Even if we fix libyaml on master, my thought is that home-assistant still won't build for the same reasons as on 19.03.
<tilpner>
das_j: Why not with nix-store?
<das_j>
tilpner: We are planning to generate apparmor profiles during the nix build
<das_j>
So we need the packages at buildtime
<tilpner>
Ahh, one second
<das_j>
s/packages/store paths/
<tilpner>
(Or 90)
<tilpner>
Have you seen exportReferencesGraph?
<das_j>
we haven't? silly question but is there any doc on that?
<tilpner>
Probably not, look at closureInfo from build-support
<tilpner>
That's what I used to generate apparmor profiles
<ajs124>
tilpner: we've seen that, but: infinite recursion encountered, at undefined position
<das_j>
so you already have some code? is it public someplace?
<tilpner>
ajs124: Did you use closureInfo or exportReferencesGraph?
<ajs124>
closureInfo
<tilpner>
Yeah, I just mentioned closureInfo for you to look at, because it uses exportReferencesGraph
<tilpner>
das_j: No, I've temporarily™ stopped using that, and it was not in a state I would like to publish (but it did work!)
<das_j>
sounds like 100% of the codebase ajs124 and I am using
<das_j>
*are
<tilpner>
It might be somewhere in my archive, but I currently have no access to that
<das_j>
oh, alright :c
<tilpner>
Is your attempt public?
<tilpner>
You make me want to fix mine
<tilpner>
But I'll need to learn more about build hooks to tell how hard it would be
<tilpner>
Ideally you'd just do nativeBuildInputs = [ apparmorGenHook ]; and you're done, there's a new output or directory with your profiles
<tilpner>
But you need exportReferencesGraph for that to be possible without IFD
<tilpner>
And I have my doubts about build hooks being able to change derivation attributes like that
<tilpner>
So the next best options might be an adaptor, that .overrideAttrs a package to add profile generation
<das_j>
attempt is not public because it's not really working and there's nothing worth sharing yet
<tilpner>
Actually, a generator function might work as well
<das_j>
all of these solutions sound like a rebuild of EVERY package
<tilpner>
I implemented my approach as a generator function, usage was like https://tx0.co/fes
<tilpner>
That used IFD, and ended with me discarding that approach
<tilpner>
But you could probably add the package in question as an input to the profile derivation
<das_j>
it's not supposed to be a single package. it's supposed to be all packages
<tilpner>
Then you could use exportReferencesGraph to get the closure of a different package without IFD, after you filter out the parts of the closure you don't want
<tilpner>
Huh
<das_j>
if every package may read every requisiste of itself, you just need to add read/write permissions to some fhs paths
<das_j>
that way, you can also put your secrets into your store
<tilpner>
You can do that with my approach too
<tilpner>
Every package gets its own profile, applied to all its executables
<tilpner>
And that profile allows reading of all the store items its closure mentions
<tilpner>
But that's per-package, not per-system
<das_j>
nice! but the code is currently lost, as I understand?
<das_j>
or not within reachability
<tilpner>
Yes, and it used IFD from closureInfo, so it was unusable to me
<tilpner>
But! I think it would be possible to eliminate that usage of IFD with clever filtering
<tilpner>
Actually, I'm entirely wrong!
<tilpner>
No need for filtering, I forgot that you can have multiple reference graphs exported
<tilpner>
...
<tilpner>
wow
<tilpner>
I forgot that I did publish it, but don't get your expectations up
__monty__ has quit [Remote host closed the connection]
__monty__ has joined #nixos-dev
ixxie has joined #nixos-dev
<sphalerite>
etu: damn
<thoughtpolice>
Can I get someone to pin a forum thread? I don't know who maintains Discourse
<thoughtpolice>
In related news: the new cache is looking good from some rudimentary stats. Zero 500 errors over the past week, and a p95 latency of ~210ms which I think is going to be a vast improvement over the current one
<thoughtpolice>
gchristensen: I'd be interested in the p95 latency on the current cache, actually, if you get the chance
Guanin has joined #nixos-dev
<simpson>
Do we measure the p99.9 too? I'm not sure p95's sharp enough with the volume of requests we have.
<thoughtpolice>
zimbatm: Do you maintain the discourse instance, I think?
<thoughtpolice>
simpson: No, that's a limitation of ours, unfortunately (otherwise, I would be using it)
<gchristensen>
thoughtpolice: let's identify and take the next step :)
<simpson>
thoughtpolice: Unfortunate but understandable. And that's a fine p95, for sure.
<thoughtpolice>
I'd mainly like to see more traffic, right now, if possible.
<thoughtpolice>
Hence forum thread pins. I guess I can just bump it.
<thoughtpolice>
(The latency is question is more of a curiosity than anything relevant to changes I want to make.)
<thoughtpolice>
gchristensen: I think the best thing right now is just to keep soaking traffic for a little longer if I can get more users, just to make sure nothing goes haywire. It would be nice to get confirmation of IPv6 problems or not (nobody has informed me of any yet).
<thoughtpolice>
The next step actually involving typing anything is probably the Terraform config, but I haven't looked at that.
<timokau[m]>
thoughtpolice: I've seen ryantm do some administration, you can probably ask them
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
<thoughtpolice>
simpson: Oh. Actually we could calculate the 99.9p. We just don't in our UX, is all (it does the calculation client side with the data points from our historical API, I just realized).
ixxie has quit [Remote host closed the connection]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
__monty__ has quit [Quit: leaving]
<simpson>
thoughtpolice: Nice!
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
<zimbatm>
thoughtpolice: maybe make a new "call to arms" thread?
<zimbatm>
graham, ryan, mic92 and me have admin on discourse
<zimbatm>
(and eelco)
drakonis_ has quit [Ping timeout: 272 seconds]
<worldofpeace>
(admin on discourse for worldofpeace might be a good idea for consideration zimbatm)