<Irenes[m]>
is there any plausible way to make the notifications less spammy?
<Irenes[m]>
and does anybody have a link where I can see what it's doing
<Irenes[m]>
purely out of curiosity
bennofs_ has joined #nixos-dev
<ekleog>
Does the bot send a message after each push, or only on the first one?
<rmcgibbo[m]>
- One thing that was discussed was for me to change r-rmcgibbo to "merge" the two comments it often make (one for aarch64-linux and one for x86_64-linux) into one comment by having it edit its previous commit if it sees that it's already commented
<rmcgibbo[m]>
- Another thing was to start using the Github Checks API to display either build successes, build failures, or both. There's some uncertainty about how the suggestions should or should not get incorporated into the Checks API that requires some experimentation.
<rmcgibbo[m]>
- Another thing that was discussed is if the bot could post a "review" rather than a comment, although personally I think it's more spammy.
<Irenes[m]>
those all seem worth investigating
<rmcgibbo[m]>
Right now r-rmcgibbo runs nixpkgs-review only after the initial creation of the github PR, not after each push to the PR. But in general it does run twice, once for each arch it has support for.
<rmcgibbo[m]>
(Although it doesn't post it's review for a given architecture if anyone else has already posted a nixpkgs-review review on the PR for that architecture or if the PR modifes only 1 attr and ofborg already built it)
<ekleog>
Hmm then at least option 1 and ideally option 2 (which would make it run once after each push) sound like the best option(s) to me too — one message per new PR is OK-ish, but it'd be better if the information were updated on each push IMO
<rmcgibbo[m]>
And the super-near-term-like-right-now fix for this is that if you tell me that you don't want me to post notifications for "build successes" on your PRs and you give me your GH username, I can add you to the "block list" and it will take effect within the next 10 minutes.
<supersandro2000>
I don't think we need after each push
bennofs__ has quit [Ping timeout: 272 seconds]
<supersandro2000>
ofborgs evals are then enough and if not you can manually run it to maybe check a thing or two
<supersandro2000>
abathur: thanks for linking that
<supersandro2000>
rmcgibbo[m]: I think I have another suggestion for nixpkgs-hammering if you are open to it
<supersandro2000>
no-flags-array should probably not complain about buildFlagsArray
<Irenes[m]>
yeah it seems like that stuff should go in the check output if at all possible
<supersandro2000>
even tho it is valid
<hexa->
whats the point of automatically reviewing r-ryantm pull requests?
<rmcgibbo[m]>
Can you file a ticket with Jan Tojnar for that, Sandro?
<supersandro2000>
rmcgibbo[m]: I can do that
<Irenes[m]>
it's clear that the checks API supports detailed reports because some of the existing checks produce them
<rmcgibbo[m]>
@hexa-: Well, IMHO it gives the maintainers who should be reviewing the update some information about the fact that it continues to build on a second architecture.
<hexa->
rmcgibbo[m]: ah fair, but a second x86-64 check wouldn't make sense
<rmcgibbo[m]>
As well as flagging if updating that package breaks any downstream packages on a second architecture.
<rmcgibbo[m]>
That's right, and I've already added a feature to the bot so that it doesn't post a second x86-64 check.
<hexa->
nice
<rmcgibbo[m]>
It only posts for architectures that nobody has nixpkgs-review'd for already.
<rmcgibbo[m]>
(In the PR body or a previous comment)
<supersandro2000>
you probably grep the comments for that, right?
<supersandro2000>
so it will most likely break with my modified one. Maybe we should add a hidden string if thats the case
<hexa->
maybe we should invest more in ofBorg though
<rmcgibbo[m]>
supersandro2000: I'm grepping the prior comments for `NEEDLE = f"run on {system} [1](https://github.com/Mic92/nixpkgs-review)"`, so far I don't think there have been any false negatives from that.
<abathur>
can't speak for the bot-makers, and I may not be in the know, but I've been interpreting the bot efforts as a sign that there's a missing <automation-incubator>
<supersandro2000>
well I heard it can't be easily tested which is not ideal
<supersandro2000>
rmcgibbo[m]: that will only work for newer nixpkgs-reviews. Older ones are missing that and I think the one on 20.09 did not receive that change as a backport
<rmcgibbo[m]>
Okay, I'll keep an eye out for false positives and can add another search string no problem. I think that's a minor point though.
<Irenes[m]>
I think automated lint rules and tests are certainly important
<Irenes[m]>
it is also important to be mindful of developer experience
<Irenes[m]>
I have no particular authority or anything, I'm just expressing my personal opinions. I'm not a particularly active contributor either, or I'd say thank you for making the bot
<Irenes[m]>
I do hope there are ways to make it less of an interruption and more of advice that's there when you need it
<rmcgibbo[m]>
Yeah, 100%
<supersandro2000>
I think part of the issue could be blamed on GitHub by providing a very strict set of tools which do not fulfill all our needs
<rmcgibbo[m]>
Jan Tojnar: Maybe this weekend, I/we should test out the checks API.
<Irenes[m]>
I do think that the "checks" functionality meets all the needs, yeah
<Irenes[m]>
oh I see, three bullet points
<Irenes[m]>
I think checks clearly meet need (1) and honestly, I'd consider using them for (2) and (3) as well
<Irenes[m]>
the thing about comments is that it co-mingles programmatic output with human output
<Irenes[m]>
and makes it harder to see just the human stuff
<Irenes[m]>
even aside from notifications, it makes it harder to catch up on the issue
<Irenes[m]>
I've worked in environments where there was a lot of stuff like that, it was really important to have tools for cutting through the clutter
<Irenes[m]>
I think if you don't want to make an X that's fine, it can be "check succeeded but please read" or something
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<rmcgibbo[m]>
Yeah, my concern about the checks API -- and maybe this is completely wrong because I just haven't experimented with it and I'm under as misimpression -- is that you can either throw up a red X, a green check mark, or a yellow "in progress" bullet.
<rmcgibbo[m]>
And I'm not yet sure if this gives a compelling way to show information that kind of has a "middle ground" quality to it, like a suggestion that you may or may not want to follow or a build failure that could have been due to my infra being flaky.
<rmcgibbo[m]>
But that's why I need to experiment with the checks API. Maybe it's perfect.
<supersandro2000>
you can also set the status to grey
bennofs__ has joined #nixos-dev
<rmcgibbo[m]>
Another thing to think about specifically for posting build failures using the checks API for me is that the check will then be tied to a specific commit sha, and so the existence of the failure will kind of "go away" if the PR author posts another commit to the PR that doesn't actually fix the build failure (e.g. because they're addressing a cosmetic suggestion or something), and that might mean I probably should
<rmcgibbo[m]>
switch to re-building every commit to the PR which is going to be more expensive. Not a big deal, just something to think about.
<ryantm>
rmcgibbo: One reason to do the x86_64 build again on r-ryantm PRs is you could detect reproducibility issues.
bennofs_ has quit [Ping timeout: 240 seconds]
<supersandro2000>
Do reproducibility issues normally propogate?
<ryantm>
I think so, so maybe not so useful.
<rmcgibbo[m]>
(@ryantm: I am actually running them on x86 even for r-ryantm, I am just stopping right before posting. I could start posting them if they show a failure, or if some other condition is met)
<ryantm>
Probably need to wait until reproducibility is more normal.
rajivr has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
mkaito has quit [Quit: WeeChat 3.0]
disasm has quit [Quit: WeeChat 2.0]
disasm has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
abathur has joined #nixos-dev
charukiewicz has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 3.0]
lovesegfault has joined #nixos-dev
bennofs__ has quit [Ping timeout: 265 seconds]
<srk>
I'm wondering why 'systemctl reload postgres' sometimes hangs when used in acme postRun. for nginx there's systemd.services.nginx-config-reload with comment `# postRun hooks on cert renew can't be used to restart Nginx since renewal runs as the unprivileged acme user.` but as of 67a5d66 it runs as root so I'll fix that comment
bennofs_ has joined #nixos-dev
<srk>
reload service looks like a better idea anyway. nixos-mailserver does systemctl reload nginx/postfix/dovecot2 in postRun tho
<srk>
not even sure if reload which triggers config reload is enough for postgres to load new certificates
bennofs_ has quit [Ping timeout: 265 seconds]
bennofs_ has joined #nixos-dev
jonringer has quit [Ping timeout: 260 seconds]
bennofs_ has quit [Ping timeout: 272 seconds]
saschagrunert has joined #nixos-dev
bennofs_ has joined #nixos-dev
orivej has joined #nixos-dev
charukiewicz has quit [Quit: charukiewicz]
charukiewicz has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
<roberth>
does anyone use a metasyntax for function parameters? Seems like a useful way to briefly mention them in documentation
<roberth>
for example mkDerivation:buildInputs
teto has joined #nixos-dev
<roberth>
perhaps mkDerivation{buildInputs}
__monty__ has joined #nixos-dev
<sterni>
but don't all functions taking an argument set have so many args that a short hand notation just gets exploded
<infinisil>
> generators.toPretty evalModules
<{^_^}>
value is a function while a set was expected, at (string):472:1
bennofs_ has quit [Quit: No Ping reply in 180 seconds.]
bennofs_ has joined #nixos-dev
bennofs_ has quit [Remote host closed the connection]
bennofs_ has joined #nixos-dev
bennofs_ has quit [Ping timeout: 240 seconds]
bennofs_ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
bennofs_ has quit [Quit: No Ping reply in 180 seconds.]
bennofs_ has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
bennofs__ has joined #nixos-dev
bennofs_ has quit [Read error: Connection reset by peer]
jonringer has joined #nixos-dev
bennofs__ has quit [Ping timeout: 240 seconds]
bennofs_ has joined #nixos-dev
<nbp>
hum … this is not reassuring, when you notice that your system depends on 2 openssl: /nix/store/wmhdjm0x0n4ffqh908gkhah3zr1d29fd-openssl-1.1.1i and /nix/store/xivj0vwm0pjpmwsjrc8qcca9fcfyxm4b-openssl-1.1.1i
<nbp>
nix-store -qR /var/run/current-system | sort -t- -k2 | less
<nbp>
Ok coreutils depends on *4b-openssl-1.1.1i, and the rest on the other.
<nbp>
Sounds like a staging artifact.
pmy has quit [Quit: WeeChat 3.0.1]
pmy has joined #nixos-dev
vcunat has joined #nixos-dev
<vcunat>
Hydra seems down. I hope it won't remain that way over the whole weekend...
cole-h has joined #nixos-dev
<aminechikhaoui>
hm looks like the database server run out of disk space
<aminechikhaoui>
well I don't know much about the zfs setup there. gchristensen around ?
mkaito has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
<supersandro2000>
DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI connect('dbname=hydra;host=10.254.1.9;user=hydra;','',...) failed: could not connect to server: Connection refused
<supersandro2000>
that almost leaked credentials
rajivr has quit [Quit: Connection closed for inactivity]
<hexa->
on a private network
<supersandro2000>
There are probably hydras which are on a public network and could leak things this way.
<supersandro2000>
or maybe it always cuts the password. Just wanted to raise the question.
<cransom>
i *think* that the password is configured in a .pgpass file and the debug string you see is the selector for db/host/user to select that password. i don't think it can be logged, at least not from perl
<cransom>
and if i look at my hydra, yes, the DBI string host/user/db/dbname. the password is tucked away in pgpass.
<supersandro2000>
that sounds not to bad
<hexa->
the only language i know that leaked credentials was php
orivej has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
Synthetica has joined #nixos-dev
<Synthetica>
What's going on with hydra.nixos.org?
<hexa->
Synthetica: check the backlog
<siraben>
this package has no maintainers but I got pinged, probably because of git blame #112929
<samueldr>
siraben: in the issue body, it's the user that added this, so yeah, maybe they looked at the history of the file :)
<samueldr>
but nothing automated
<siraben>
heh, right.
<srk>
siraben: I'm using it, will take a look
<siraben>
srk: thanks
<worldofpeace>
<qyliss "worldofpeace: should #112879 be "> there are a few things but I wouldn't consider it a draft. I don't really need to care about apparmor at all, I think that's just relevant if we want to default to it, because we'd have to mention that if you used dbus apparmor before you'll need to disable dbus-broker
<supersandro2000>
I am not sure. If we can find a consensus we can remove curlFull.
<supersandro2000>
I wanted to add a http3 flag but it either requires boringssl or a patches openssl. Skipping that for now
<hexa->
well, most people use curl for http/https, so brotli and idn are probably in scope, ldap and gss feels weird
<supersandro2000>
fully agree with you
<samueldr>
remember that curl is the library too
<supersandro2000>
just wanted to keep the disruption low
<supersandro2000>
I think right now it only enables new things and does not break anything
<supersandro2000>
rmcgibbo[m]: jtojnar: what do you think about nixpkgs-hammering asking people to check if hardeningDisable is really required?
<rmcgibbo[m]>
that sounds good. to the extent that we can discourage hardeningDisabled that seems like it would benefit everyone
<qyliss>
please don't do that
<qyliss>
in many cases it is required, and you'll just add to the noise
<adisbladis>
What qyliss said
<gchristensen>
I don't think it is a good idea to make it a goal to get rid of curlFull
<gchristensen>
there is probably an 80/20 rule that applies to featureset and user need
<gchristensen>
and a 16M growth is fairly significant in the face of probably almost no users needing it
<samueldr>
if it was possible to detect that a comment explaining the need for each hardeningDisabled values, it'd be more acceptable, but we don't have a way to properly "annotate" I guess
<samueldr>
is missing*
<qyliss>
samueldr: that comment would go out of date, and we'd end up in the same predicament we're currently in
<qyliss>
where then we start asking people to check the comment is up ot date
<samueldr>
at least there would be an indication as to why it was added
<qyliss>
hardeningDisabledLastChecked = version :P
<samueldr>
verifying the comment is still needed is a different issue
<samueldr>
here I assumed it was about *introducing* new hardening
<samueldr>
new disables*
<samueldr>
but if it's about all the time... there's no way it's sustainable :)
<qyliss>
I'm assuming this is a conversation of the issue I raised in #nixos-security that almost every instance of hardeningDisable appears to be unnecassry (builds succeed without them, at least)
<samueldr>
in my experience, a chunk of issues happen at runtime
teto has quit [Quit: WeeChat 3.0.1]
<samueldr>
(which makes this a really annoying issue to gauge!)
<samueldr>
and if there is no explanation as to why it was added, it's hard to tell whether it is still an issue or not :/
<qyliss>
yeah
<qyliss>
what I've been doing so far is checking out the commit where it was added, and checking if the build would have failed if it wasn't added
<qyliss>
if that's the case, I assume it's safe to remove now, and otherwise I leave it alone
<qyliss>
I think that should be pretty bulletproof as a strategy but it's a bit slow and manual
<samueldr>
sounds good enough when there is a known failure at build originally yeah
<jtojnar>
supersandro2000, rmcgibbo: I think it would be nice to add warning if it builds without it and there is no comment
<jtojnar>
need a third category of checks (build in addition to eval and syntax) and multi-modal checks first, though