<worldofpeace>
Cole Mickens: what do you mean exactly?
<colemickens>
I had thought the meetings had gone ad-hoc for a bit while they were go/no-go meetings? but maybe I was mistaken
<colemickens>
idk, I had shown up a couple times at what I thought was the usual time and there was no meeting
<colemickens>
that was some weeks ago tho
<worldofpeace>
prior to the public go/no-go meeting disasm and I would try to meet twice a week.
<worldofpeace>
but we haven't been doing like a NixOS Dev update meeting weekly (and public). that would be a good idea for someone to run though
<cole-h>
What about office hours, how often does that stuff happen? I only showed up for one, last month-ish
<worldofpeace>
every other week friday 3:00pm America/New York time
<cole-h>
Oh. I guess I should join that channel then. I just remember seeing somebody post about it in here/#nixos and joining off of that
<worldofpeace>
#nixos-officehours
<worldofpeace>
I kinda forgot the rotation because we've missed a few (because things have been busy), but I believe it should be this upcoming friday
<worldofpeace>
tbh, need to generate an ical, or nixos needs a calendar suite at nixos.org :D
<cole-h>
:D
<gchristensen>
:/
<gchristensen>
The option `security.acme.certs.flexo.gsc.io.plugins' does not exist.
<cole-h>
That... doesn't sound good?
<gchristensen>
seems the change from simp_le to lego changed this. figuring out if I can continue using security.acme :)
<gchristensen>
I think yes
<gchristensen>
scary, though
<cole-h>
Scary indeed.
<gchristensen>
it seems it was set to plugins = [ "cert.pem" "fullchain.pem" "full.pem" "key.pem" "account_key.json" "account_reg.json" ]; and those are generated by default
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
<colemickens>
worldofpeace: you're not in that room, right? or is it not bridged correctly?
<worldofpeace>
Cole Mickens: I am in that room, so probably matrix being a pain or something
<worldofpeace>
well proper, the matrix irc bridge struggling to bridge all of freenode :D
<colemickens>
that's what I'm supposedly in. Jan Tojnar and some others are there with me too it seems
<worldofpeace>
Cole Mickens: yeah, not sure what that's about but it doesn't appear to bridge with the actual channel
peelz_ has quit [Quit: Leaving]
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
rsa has joined #nixos-dev
drakonis has joined #nixos-dev
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
<Irenes[m]>
what always works for me is to go to my DM with "Freenode IRC Bridge" and type "!join #nixos-officehours" or whatever
<Irenes[m]>
and then it invites me to the proper channel
<Irenes[m]>
that has even worked for a couple channels where people otherwise haven't been able to join them
<worldofpeace>
Irenes: yep, same. that seems to be the most reliable way
<colemickens>
I wonder if I should part the bad room first
justanotheruser has joined #nixos-dev
peelz has quit [Ping timeout: 258 seconds]
peelz has joined #nixos-dev
peelz has quit [Ping timeout: 244 seconds]
peelz has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
aranea has quit [Ping timeout: 265 seconds]
Scriptkiddi has quit [Ping timeout: 260 seconds]
ajs124 has quit [Ping timeout: 260 seconds]
das_j has quit [Ping timeout: 260 seconds]
hexa- has quit [Ping timeout: 265 seconds]
aranea has joined #nixos-dev
hexa- has joined #nixos-dev
ajs124 has joined #nixos-dev
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
<Irenes[m]>
in my experience it won't matter either way
<Irenes[m]>
the bad room is unrelated to the good room
<Irenes[m]>
except for having the name that the good room is supposed to have but somehow doesn't
<Irenes[m]>
it's kind of amusing that several people independently joined it
FRidh has joined #nixos-dev
<cole-h>
How often does status.nixos.org update? I've seen a few channels "advancing" over in #nixos, but the status page seems to still be saying everything is last updated 3+ days ago.
<xfix>
channel check time is... interesting to say the least
<xfix>
there were no channel checks for two days or so
<cole-h>
That might explain why there have been no updates to the status page 🤔
<cole-h>
It's dead Jim D:
<srk>
status of status :D
<srk>
so meta
<xfix>
but then we would need status of status of status
<cole-h>
Status pages all the way down
<cole-h>
status.status.nixos.org
<LnL>
I did notice that the hydra:9300/metrics timed out, not sure since when but the data could be coming from there
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
<Profpatsch>
Can’t you do a recursive thing?
<srk>
fix! :D
<Profpatsch>
status1.nixos.org checks status2.nixos.org and the other way around, both run on different deployments :)
<Profpatsch>
The Google SRE books probabaly have a chapter on that topic :)
<MichaelRaskin>
And AWS apparently doesn't! Although maybe it does now
<LnL>
isn't the AWS idea to just show a static page with green checkmarks?
alp has joined #nixos-dev
<MichaelRaskin>
No, they make sure the page is not completely static! This does not include connecting it to any status checks, though
peelz has quit [Remote host closed the connection]
ashkitten has quit [Ping timeout: 272 seconds]
peelz has joined #nixos-dev
ashkitten has joined #nixos-dev
peelz has quit [Remote host closed the connection]
peelz has joined #nixos-dev
obadz has quit [Quit: WeeChat 2.8]
obadz has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has quit [Ping timeout: 244 seconds]
__monty__ has joined #nixos-dev
peelz has quit [Remote host closed the connection]
<andi->
You have to add random load delays to simulate the "real" experience ;)
Jackneill has joined #nixos-dev
qyliss has joined #nixos-dev
<qyliss>
Suppose I had discovered some Nix code that, when evaluated, would permanently break garbage collection until manual intervention by a system administrator
<qyliss>
That would be bad, wouldn't it?
<Profpatsch>
niksnut: ^
<clever>
qyliss: nixexpr gc or store gc?
<qyliss>
store gc
<xfix>
what would breaking GC mean, out of curiosity?
<qyliss>
Running nix-collect-garbage will no longer recover any disk space
<xfix>
adding a GC root is not hard, in fact you can use nix-store --add-root, and of course any path that is being referred to by a running process cannot be GCed, this is an intended feature
<xfix>
if this could be done, say with what GrahamcOfBorg can do, then it sounds like a possible vulnerability, and you may want to report that
<xfix>
specifically, if nix-build without out-link could cause issues with GC, then it sounds like a security vulnerability, not a big one, but still
<xfix>
(without out-link means --no-out-link)
<niksnut>
qyliss: make an issue please
<qyliss>
niksnut: you reckon a public issue is okay? that's what I wanted to check.
<niksnut>
sure
<gchristensen>
qyliss: I'm excited to see it :o :D
<qyliss>
like, I think this could be used against ofborg etc
<qyliss>
i'll come up with a patch
<qyliss>
at least
zarel has quit [Ping timeout: 246 seconds]
<niksnut>
DoS nix (or linux is general) isn't hard, there are an infinite ways to do that
<qyliss>
okie
<niksnut>
fill up the disk, fork bomb...
zarel has joined #nixos-dev
obadz has quit [Quit: brb]
obadz has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
obadz has quit [Quit: brb]
alp has joined #nixos-dev
obadz has joined #nixos-dev
<qyliss>
You can mitigate those with ulimits, disk quotas, automatic GC, etc, though
<qyliss>
there's no mitigation for this
evils has quit [Remote host closed the connection]
<Profpatsch>
ryantm: For the bot to discover a new version and build it in a package, what information does it need? Does it look at the position of the `meta` field to find the file?
<Profpatsch>
I read through the readme, but I didn’t find a description of what it takes to make the bot pick up a package.
<jtojnar>
Profpatsch it uses nix edit
<Profpatsch>
jtojnar: Ah, thank, I suspected that.
<Profpatsch>
Then I need to make my packages nix editable I guess
<jtojnar>
it should pick up every package that it can pick up as outdated on repology (or github)
<jtojnar>
unless blacklisted
<Profpatsch>
jtojnar: I moved the meta block to the shared build-support function, so that’s obviously pointing to the wrong thing.
<Profpatsch>
jtojnar: do you know how it finds the hash? Just a literal sed?
<Profpatsch>
s/literal/dumb/
<Profpatsch>
Also, how does it find the version definition? It could be factored in a let, right?
<Profpatsch>
That’s what I get for not copy-pasting enough :)
<jtojnar>
it did dumb replacement when I ported it to Haskell but it was probably improved since then
<cole-h>
Options lgtm as well, but packages lost expression links again, it seems.
<worldofpeace>
cole-h: everyone in nixpkgs-maintainers now has triage permissions
<cole-h>
worldofpeace++ I just noticed, thanks :) Hope people don't abuse it...
<{^_^}>
worldofpeace's karma got increased to 158
<eyJhb>
Uhhhhh, worldofpeace !
<gchristensen>
if they do, we'll have to address that
<eyJhb>
*unsure if I am*
<cole-h>
I still hope it doesn't happen :)
<eyJhb>
Isn't it just labeling issues?
<gchristensen>
closing PRs too
<eyJhb>
Ohhhh yeeeeesss
<worldofpeace>
and issues
<cole-h>
And requesting reviews, and closing issues/PRs, and milestones, and assignees
<qyliss>
ris: :D
<eyJhb>
^ x2
<eyJhb>
Getting better and better
<eyJhb>
Tbh. I would be too scared to close any issues
andi- has quit [Ping timeout: 240 seconds]
<cole-h>
It can't be abused to cause a ton of damage (like w+ for maintainers would... 👀), but it can certainly become annoying...
<gchristensen>
we count in so may ways on people doing the thing they think is right
<gchristensen>
if someone isn't acting in good faith, well, should they be a maintainer
<cole-h>
Good point.
<eyJhb>
Nixpkgs should still have a duplicate PR bot tbh
<worldofpeace>
I think it will be fine, it'll sure save me some time doing those things for people :D
<eyJhb>
Or, this is a outdated version bot
<cole-h>
True, I don't have to ping you or gchristensen every time GitHub breaks ofborg, now :D
<hyperfekt>
i'm not a core contributor but i think that's probably a wise choice. given the size of nixpkgs it's pretty important for more people to make it their own and take responsibiity if they are able, or we'll get things left yb the wayside and people getting burnt out
<gchristensen>
:)
<gchristensen>
cole-h: now I just need to let you log in to ofborg prod
<cole-h>
lol
<gchristensen>
or a buildkite button of "restart some stuff"
<cole-h>
Yeah, I was gonna suggest that -- would be cool if there was a buildkite button that could restart each service individually
<worldofpeace>
hyperfekt: totally. The next thing is a merge bot for maintainers 💖
<cole-h>
No need for "keys to the kingdom" if that happens
<hyperfekt>
worldofpeace: that seems like it would totally transform things :ooo
<cole-h>
It would be nice if every corner of nixpkgs had a maintainer or codeowner, e.g. NixOS modules (though people are starting to add themselves as a maintainer recently)
<MichaelRaskin>
re: maintainer merge — and then we need to be slightly careful to make sure nothing gets merged in python-packages.nix …
<cole-h>
Why's that? Does it break things?
<MichaelRaskin>
Well, the question is what is «merge by maintainer»
<MichaelRaskin>
We have the list of files touched. We have a list of packages rebuilt, which is actually only a partial walk
<hyperfekt>
cole-h: definitely. i've avoided adding myself as a maintainer so far because i'm not great at taking up responsibilities so it would be making a promise the breaking of which wouldn't be very far to others
<hyperfekt>
*very fair to others
<cole-h>
MichaelRaskin: I figured it meant when a maintainer approves a PR, even without w+, the proceedings for committing would start (or would just be auto-merged under x y and z circumstances)
<MichaelRaskin>
For single-package files, saying that all the maintainers of the packages known to be rebuilt need to sign off, and for each file in the list of changes a maintainer of a package defined there needs to sign off does exactly what is expected
<hyperfekt>
it would be nice if things only got automerged if they don't break master. i keep thinking about the uber build pipeline paper and how something like that would be great for nixpkgs
<MichaelRaskin>
But for changes to larger files, it might be hard to say what is the correct set of maintainers
phreedom has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
hyperfekt: building all pushes to all PRs — a _ton_ of buildpower, more than a binary order of magnitude away from the total of ofBorg + Hydra builds
phreedom has joined #nixos-dev
<hyperfekt>
MichaelRaskin: what about attribute-level instead of file-level maintainer data?
<MichaelRaskin>
Well, the point is: we do have changes that need review and cause 0 rebuilds
<gchristensen>
designing for the 80% is okay though
<MichaelRaskin>
gchristensen: well, it is OK to design 80% reasonable 20% reported.
<gchristensen>
yea
<cole-h>
MichaelRaskin: Ah, I hadn't thought of needing "packages that will be rebuilt" permission as well. A good point
<hyperfekt>
MichaelRaskin: well, you would not have to build all pushes, just the ones to be merged. i feel like we perform a majority of those builds already, just after merging instead of before (how often is a derivation changed more than once between two atempts of hydra building it?)
<MichaelRaskin>
80% reasonable 10% reported 10% prompts a person to confirm merge of the things nobody expects them to be able to commit — that needs very careful documentation
tokudan has quit [Remote host closed the connection]
<MichaelRaskin>
gchristensen: the problem is not a refactor with 0 rebuilds, the problem is a refactor with 1 rebuilds and 1000 refactored files only changed for cross-build
<gchristensen>
right right
<MichaelRaskin>
hyperfekt: what does it mean «to be merged» though?
__Sander__ has quit [Ping timeout: 256 seconds]
tokudan has joined #nixos-dev
<MichaelRaskin>
And there is no clear-cut notion of master building
<hyperfekt>
MichaelRaskin: well, at some point maintainers decide a PR should be merged, at which point they instruct the mergebot. that's the only point at which an integration build would be done
<MichaelRaskin>
I wrote this very explicitly in rfcs#46 for conflicts between platforms, but we also have «critical update for nixos-small vs less breakage on nixos-unstable»
<hyperfekt>
MichaelRaskin: that's a good point, but in practice it would mean it cannot break the trunk jobset
<MichaelRaskin>
hyperfekt: note that this will cause active complaints from anyone encountering two related PRs.
<MichaelRaskin>
hyperfekt: yep, this agreement will survive till next heartbleed
<MichaelRaskin>
Because nobody will care about trunk jobset then a fix needs to be rolled out already
<hyperfekt>
MichaelRaskin: we'll always need escape hatches i suppose. but it would be a very different default to the one we have right now
alp has joined #nixos-dev
<MichaelRaskin>
hyperfekt: scrape unstable builds, find new failures, bisect _evaluations_, create PRs for reverting the PRs probably causing breakage.
<MichaelRaskin>
Note that this does not require special access, so a bot does not even need formal approval
phreedom_ has joined #nixos-dev
phreedom has quit [Quit: No Ping reply in 180 seconds.]
<MichaelRaskin>
Sometimes the revert PR will happen to be a mess. Will probably be an obvious mess, though — and the build-then-merge approach would be quite likely to also make a mess in such a case
lassulus has quit [Ping timeout: 250 seconds]
lassulus has joined #nixos-dev
<infinisil>
> maintainers.asymmetric.email
<{^_^}>
"lorenzo@mailbox.org"
<infinisil>
domenkozar[m]: ^
andi- has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<asymmetric>
hello
aszlig has quit [Ping timeout: 250 seconds]
aszlig has joined #nixos-dev
andi- has quit [Ping timeout: 244 seconds]
alp has quit [Ping timeout: 265 seconds]
andi- has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
noonien has joined #nixos-dev
justanotheruser has joined #nixos-dev
<jtojnar>
does anyone recall why we pass -isystem flags to CC wrapper instead of setting C_INCLUDE_PATH?