jonringer has quit [Remote host closed the connection]
<infinisil>
I guess that's fine :)
* cole-h
sighs in relief
<infinisil>
The dynamic uids are mostly meant for services, since so many of them are being added
<cole-h>
Ah, I see
<infinisil>
Though I am debating whether dynamic uids were the right decision in the end
<infinisil>
There are some problems with it
<infinisil>
(though there's also problems with static uids)
<infinisil>
The main problem with dynamic uids is that different machines can have different uids for the same services, meaning that when you transfer files between them, you need to adjust uids of the files
tilpner_ has joined #nixos-dev
<infinisil>
Hmmm... Maybe a solution for that is to somehow ensure all of your machines use the same dynamic uid mapping
<infinisil>
Maybe the dynamic uid mapping should be generated at eval time, instead of runtime
<ekleog>
was the end of ids.nix ever acted? my recollection of the statu quo was it was something like “if you can use DynamicUser, if not if no state is expected to be transferred across machine let nixos auto-pick a uid, and if state is expected to be transferred across machines use ids.nix”
<infinisil>
So you could have an /etc/nixos/ids.json where every time you add a service, you need to run some command for assigning it a uid
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
<ekleog>
(though I don't know whether we ended up running out of uids there since I last had a look)
<infinisil>
ekleog: The transferring data between machines isn't a problem in most cases, because the transfer protocol usually takes care of rewriting uids. It only doesn't work for filessytem-level block-level transfers or the like
<infinisil>
So in the RFC I believe I discouraged ids.nix in general, only to be used in special cases on an individual basis
<ekleog>
right, or disk-level backups (which is why I never actually understood why the policy once was focused on state transfer across machines)
<ekleog>
hmm which RFC? there's no mention of `ids` in the nixos module config options RFC
<siraben>
We need `{share,lib}/pkg-config` to be `lib/pkgconfig` right?
<V>
oh, and also case-insensitive
<siraben>
`{share,lib}`*
<V>
uh.... where is that
<siraben>
I mean
<siraben>
ag "lib/pkgconfig" but I did a naive substitution
<V>
I find no references to lib/pkg-config?
<siraben>
Yeah I mean lib/pkgconfig
<V>
but your original question, though. where are you finding {share,lib}/pkg-config?
<V>
because that sounds like a typo
<siraben>
Oops that was because I performed a treewide sed
<infinisil>
Hmm, maybe I should write a program like `nix-name-replace pkgconfig pkg-config`, which does what you would expect, without any false positives (by parsing Nix as an AST and doing the replacement there)
<V>
omg
<siraben>
Hmmm I should split this into smaller commits/PRs
<V>
<V> siraben: next time you do find+replace, drop a \b after the lib
<V>
<V> and maybe blind find+replace isn't the best option :p
<V>
I feel vindicated
<V>
also there's filenames and such that contain "pkgconfig"
<V>
so unless you're also renaming the files you'll also break that
<siraben>
I was supposed to do `git ls-files | grep pkgs | xargs sed -i '' -E "s/pkgconfig\b/pkg-config/g"`?
* siraben
performs git restore .
<V>
no, the \b isn't relevant here
<V>
I'm just saying that naïve search+replace will break things in more ways than you'd expect
<siraben>
Right.
<V>
happens to me every time, even when I think I've covered everything
<siraben>
I usually always try out stuff in pkgs/games since it's smaller than the rest
<abathur>
hmm
<abathur>
I don't expect it to exist (though it wouldn't *shock* me), but some sort of similarity-chunking edit-review tool might be another nice lever for cases like this?
stigo has quit [Remote host closed the connection]
stigo has joined #nixos-dev
<siraben>
yay rebuild 0, for now
<abathur>
siraben: not certain; imagining a tool to process `git diff` after you run some treewide sed command that computes some sort of similarity metric (maybe something generic like edit-distance? maybe something specific working on the AST?) on the patches (not sure if with/without context?) to cluster similar edits so that you can review each chunk by itself
<abathur>
(ideally, well enough that all of the semantically-identical edits get clustered together?)
<siraben>
abathur: another good way is to replicate the treewide change locally and diff with the PR to see if anything manual has been done
<abathur>
hmm
<abathur>
I mean more like a tool for validating that your treewide edit applied like you meant
<siraben>
I see. Hm.
<abathur>
rather than ~7500 heterogenous changes, n chunks/clusters of highly-similar changes
<abathur>
"I analyzed the diff and found 13 distinct edit clusters. I'll help you review each cluster individually..."
<aterius>
infinisil: How do you refer to options you've defined later in the derivation?
<aterius>
I think I'm going to update the wiki once this is over 😆
<aterius>
I would have expected cfg.options to work similair to config.settings
<V>
infinisil: did you see the conversation yesterday(? or the day before?) where I was talking about semantic replacements & Profpatsch wrote something using hnix to make a large change?
<siraben>
Now we're up to 673 files changed, oof to reviewers
<siraben>
that's why I'm breaking it up into commits
<V>
siraben: did you actually look through this yourself
<siraben>
V: for each commit yes I paged down the diff
<V>
anyway ajs124 ^ this is why there are still lots of instances
<siraben>
it was similar enough that I could rely on color for a quick glance, though ofborg will have the final say
<siraben>
the changes were similar enough*
<V>
the rebuild 0 tag is a huge boon
<aterius>
Ah nvm, I made a stupid mistake
<infinisil>
aterius: Not sure what you mean
<infinisil>
V: Nope, but that sounds nice :o
<aterius>
I didn't want to tag you again haha
<cole-h>
infinisil: aterius probably forgot to `let cfg = config.......`
<siraben>
changing pkgs/os-specific and pkgs/development hasn't been done yet (the latter has over 30K occurences of stdenv.lib)
<V>
yup, I was even thinking of instances like that
<V>
I remember seeing one of those when grepping and deciding that performing treewide sed would be hell b/c of it
<infinisil>
Oh also, AST based replacement can detect whether `lib` is even in scope
<infinisil>
Because in a bunch of cases that won't be the case
<V>
yes
<V>
that's what I was saying + advocating for
<infinisil>
Oh yeah, just mentioning it, not trying to argue against you :)
<V>
was mentioning b/c I didn't know if you'd seen the conversation yet
<siraben>
infinisil: heh, mine relies on evaluation errors
<infinisil>
Hehe, naughty
<V>
TL;DR I brought up the idea to write a tool that allows us to do AST-based refactoring since edge-cases were making treewide changes so time-consuming
<infinisil>
I see
<siraben>
A more complex change would be moving cmake into nativeBuildInputs, of which there were only a few hundred instances so I did it manually
<siraben>
Including when the inputs were split across lines
<infinisil>
I wonder how such a tool would be used, how its interface would look like
<siraben>
Prolog style rewrite rules?
<V>
tree-based changes are nice b/c they don't care how many lines your code is across :)
<infinisil>
I think it would have to be programmatic. A CLI would be hard
<siraben>
Does any other package repo have this?
<V>
infinisil: indeed. it may need to be done via little scripts
<infinisil>
siraben: I don't know prolog, but that sounds nice
<V>
I think I mentioned one of go's refactoring tools (cannot remember the name) which has a limited version of this
<V>
just for renaming things, but it's more intelligent than a plain find+replace
<siraben>
Maybe the Guix people know something
<V>
I've been wondering what they have, if anything
<ekleog>
is nix syntax close enough to c syntax for coccinelle to work on nixpkgs?
<siraben>
Eh, not quite.
<ekleog>
(I've always been surprised by the languages on which coccinelle works, so who knows?)
<V>
siraben: there's so many different things; you should really take a look
<V>
guix is what happened when a bunch of smart nixos devs from the gnu project went off and built a new package manager + distro based on the same basic concepts
<siraben>
I actually used Guix SD briefly before NixOS but it wasn't suitable as a daily driver because of their policy of unfree software :(
<V>
indeed
<siraben>
Like sure I agree but I can't exactly just buy new hardware to run your distro
<siraben>
anyways
<ekleog>
I haven't actually used it yet, but from reading documentation, Guix is Nixpkgs, technically better, but politically so extreme that only its devs can actually use it
<V>
when I discovered these distros initially I decided I didn't want to touch NixOS b/c of the state of it, and realised that Guix was a no-go b/c of the adherence to the GNU project's principles, and then ignored both of them for ages until a NixOS dev prodded me into trying it out
<aterius>
Better insofar as guile is a nicer language to work in than nix? Or you think the core guix package manager is better than nix?
<aterius>
I assumed I could just pass that into my systemd service
<aterius>
Oh
<aterius>
that does work
<aterius>
So I need to pass a TLS cert and key to dendrite when it first starts, but I know it's technically a bad idea to store secrets/keys in the nix store, and I'm having trouble finding an example of a module that does this (without regenerating the key on each startup)
<V>
why not just generate on first run?
<V>
look at the *File options
<siraben>
ekleog: what about Guix that makes it technically better than Nix?
<aterius>
V: I need to generate from the binaries provided by the package
<V>
and generatePrivateKeyFile, etc
<V>
how do you mean "from the binaries"
<aterius>
Oh nice
<V>
do you mean using the programs to generate them?
<aterius>
wireguard is what I'm looking for
<siraben>
Does Guix have CAS?
<siraben>
Oh I also recall the Emacs integration being better
<aterius>
I don't think so, and they don't have a flakes equivalent
<adisbladis>
siraben: How is it better?
<V>
they abbreviate the store part
<adisbladis>
They don't even have packages for most of the ecosystem?
<siraben>
adisbladis: like you can explore the package graph in Emacs and so on
<V>
so it's /nix/store/[...]-foo-1.3/blah
<V>
er, /gnu/store
<siraben>
But I'm curious what other parts it's better as well
<V>
but same difference
<adisbladis>
Right
<ekleog>
siraben: it has a real language that thus has tooling, GuixSD's service system looks to me much better designed than the NixOS module system, for the two I can pull off the top of my hat
<V>
there's so many, I couldn't think of them all off the top of my head
<adisbladis>
Tbh I wasn't too impressed with Guix last time I tried it
<aterius>
Yeah emacs can be used as a pseudo graphical package manager with guix
<adisbladis>
I think `guix import` is a _massive_ mistake
<siraben>
Yeah, why did Eelco decide to make a new untyped, lazy, purely functional language instead of using, say, Haskell?
<V>
NIH syndrome is the perpetual desire by nerds to make their own X instead of using a preexisting one
<V>
I think most of us are guilty of it
<V>
I certainly am
<siraben>
Heh one day we might get a nix2nickel tool
<ekleog>
Nix does have arguments in its favor, though, dynamically typed lazy languages are not legion
<siraben>
mass migrate nixpkgs
<cole-h>
nicpkgs
<V>
shake doesn't seem to have had any issues with just using haskell
<ekleog>
(AFAIK lisp dialects like the one used by guix is the only kind of well-known such languages)
<ekleog>
I'd love it so much if we were able to type nixpkgs overnight <3
<siraben>
Yeah, a gradual type system would be a great start. Even if it's not perfect there so much redundant code in Nixpkgs and typing large parts of it would be useful
<V>
I've been thinking about gradual typing a fair bit recently, wondering if there's any people who have done a study on it and know how effective it is in practice
<ekleog>
well, at least it'd help avoid inverting the argument order of elem or elemAt
<ekleog>
(most of the time)
<ekleog>
(though it wouldn't help avoid using elem instead of elemAt I guess)
<V>
ugh, I hate some of the lib function argument ordering
<V>
there's a couple that are completely backwards to what you'd expect
<siraben>
it helps that quite a few functions are intuitively named like the Haskell equivalents
<aterius>
But I'm getting an error with the config file from the settings that I'm passing in
<aterius>
`Jan 17 02:30:35 nixos dendrite-monolith-server[743]: time="2021-01-17T02:30:35Z" level=fatal msg="Invalid config file: open dendrite.yaml: no such file or directory"`
<aterius>
I defined the config in accordance with infinisil's RFC
<samueldr>
though you have to handle the diffing yourself
<aterius>
Anddd it works
<aterius>
key permissions + bad error messages = not a fun time debugging systemd units
nyaanotech has joined #nixos-dev
nyanotech has quit [Disconnected by services]
nyaanotech is now known as nyanotech
kini has quit [Remote host closed the connection]
kini has joined #nixos-dev
srk has quit [Remote host closed the connection]
srk has joined #nixos-dev
<siraben>
cole-h, samueldr Ah I see
jonringer has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
cole-h has quit [Ping timeout: 246 seconds]
jared-w has quit [Ping timeout: 258 seconds]
sorear has quit [Ping timeout: 264 seconds]
sorear has joined #nixos-dev
jared-w has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
kini has quit [Remote host closed the connection]
kini has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Client Quit]
orivej has quit [Ping timeout: 246 seconds]
<Profpatsch>
abathur: infinisil V: hnix is not very good for source spans unfortunately, because it only has them for each subexpression, but e.g. in { lib, stdenv }: expr there’s only one span around everything and around expr, so you can’t refer to the span of lib or stdenv
<Profpatsch>
I’m working on a solution, which is: use the tree-sitter-nix parser instead. tree-sitter has a concept of anonymous nodes, which contains this stuff.
<siraben>
anyone have more ideas for treewide PRs?
<siraben>
Well, all that misplacement of things in buildInputs is a good candidate
<siraben>
removing stdenv from buildInputs, moving automake to native, etc.
kini has quit [Remote host closed the connection]
kini has joined #nixos-dev
rajivr has joined #nixos-dev
<supersandro2000>
siraben: I would be for a pkgconfig -> pkg-config and make the old alias error because then I could stop nitting people about it and just tell them CI requires that now
<supersandro2000>
and such treewide changes are the main reason I ask people to not use weird things constructs which are not very common but still valid nix
<siraben>
Makes sense
<siraben>
supersandro2000: people get angry about pkgconfig → pkg-config?
<supersandro2000>
in some PRs I have the feeling I am holding their great minds off from changing the world with such comments
<supersandro2000>
If you have a mission critical changes use an overlay or fork
<siraben>
I see
<supersandro2000>
Also some people seem to think that my manual review comments are automated
<supersandro2000>
If I could write such software I would just create PRs automatically
<supersandro2000>
*if I had the time. I could certainly do it but not in a reasonable amount of time.
<siraben>
packaging stuff for Nix is sometimes repetitive to the point where it could be automated entirely
<supersandro2000>
certainly often true for python, Go, and rust
<supersandro2000>
siraben: Not sure if the correct PR got linked but I assume ofborg does not check the plugin by default because eval did not break
<supersandro2000>
not sure how to handle this correct
<supersandro2000>
After the next staging merge we have some cool new feature for pytestCheckHook: You can ignore test files with disabledTestFiles instead of adding --ignore=... to pytestFlagsArray.
<symphorien[m]>
<siraben "Or is it ok to rewrite stdenv.cc"> No I think it resolves to the libc
<V>
indeed
<V>
it's something else entirely
<V>
I'm currently trying to figure out where it's defined exactly, but wherever you see that it's because the derivation is trying to include libstdc++
<V>
siraben: stdenv.cc.cc.lib is just lib.getLib stdenv.cc.cc
<V>
it's just the 'lib' output of your C compiler
<V>
BTW, I found another way stdenv.lib is referenced: inherits
<V>
those will be a lot more difficult to find, I imagine
orivej has joined #nixos-dev
<siraben>
qyliss: ok so that should be excluded from the regex
<siraben>
hm what's the best way to even regex this anymore
<siraben>
rg '[sS]tdenv.*.lib\b'
<siraben>
er, `rg '[sS]tdenv.*\.lib\b' pkgs/servers` (my client escaped)
<siraben>
V: something like, `inherit (stdenv).*lib` should reveal it, no?
<siraben>
Ultimately the best way to find out is to delete where stdenv.lib is defined and see the evaluation errors
<V>
siraben: across multiple lines?
<V>
indeed
<siraben>
Yeah, muliline is an issue
<siraben>
multiline
<V>
however, AIUI not everything in nixpkgs is evaluated by ofborg/hydra
<V>
<siraben> er, `rg '[sS]tdenv.*\.lib\b' pkgs/servers` (my client escaped) ← why the extra stuff? you just want the single stdenv.lib, nothing inbetween
<siraben>
bah, ok it'll be an incremental process, we've already removed over 13K occurences
<symphorien[m]>
https://github.com/NixOS/nixpkgs/pull/108725 wants to introduce a kernel patch and adds an option to enable it. Is it possible to add it to the package search instead so that people can "just" do `boot.kernelPatches = pkgs.foo` ? I assume that nix-env -q will not list anything that isn't a derivation, but what about the online package search ?
<aterius>
supersandro2000: When I run nixpkgs-review, I'm not seeing the test failure you noted on the dendrite PR. Did you do anything special?
<aterius>
I did get this random error `getting attributes of path '/usr/lib/libSystem.B.dylib: No such file or directory` but that seems to be a nixpkgs-review thing
<aterius>
And it looks like it still builds
<domenkozar[m]>
niksnut: how much work would it be to use in-memory cache for narinfos instead of disk cache?
<Mic92>
domenkozar[m]: is it a bottleneck?
<domenkozar[m]>
it's not a bottleneck but another huge pain for beginners
<Mic92>
domenkozar[m]: well. I also would like to have more control over the cache
<Mic92>
supersandro2000: I wonder if I should disable the sandbox for darwin
<Mic92>
it seems to do some weird stuff like returning EPERM instead of ENOENT when a directory in outside the sandbox is accessed (that does not exists)
<domenkozar[m]>
Mic92: what do you mean with that?
<Mic92>
domenkozar[m]: I mean it's not just a pain for beginners
<domenkozar[m]>
yeah
<domenkozar[m]>
but we at least know how to recover
<clever>
Mic92: your not permitted to even know if it exists or not
<Mic92>
clever: but this breaks build systems and tests unecessarily. I had django tests that were checking if a timezone database exists and they failed for the same reason
<Mic92>
and it is also not how the nix sandbox on Linux works
<Mic92>
in the django example it would fallback if the database did not exists
<clever>
yeah
<clever>
its a limitation of the darwin sandbox, its more of an ACL then a chroot
<supersandro2000>
Mic92: yeah it does weird things like that
<supersandro2000>
but without it you easily link against system libs
<Mic92>
supersandro2000: I would prefer the darwin one to be just a chroot.
<supersandro2000>
so if you really want that I am not posting you reviews on closed PRs you could add it with gh and the API
rajivr has quit [Quit: Connection closed for inactivity]
<flokli>
supersandro2000: I didn't say I'd code it. I can open an issue.
<flokli>
I just said I'm somewhat annoyed/concerned by too much spamming
<flokli>
and yes, this is partly because I think CI should do more of that
<srk>
+1, I was suprised to recieve two more comments on merged PR saying that it passed a build, since ofborg already built everything and even passthru tests
<niksnut>
domenkozar[m]: we already have an in-memory cache
copumpkin has quit [Quit: Hmmm]
copumpkin has joined #nixos-dev
copumpkin has quit [Ping timeout: 272 seconds]
<domenkozar[m]>
niksnut: so this would involve only then removing the disk cache?
<niksnut>
yes, but we're not going to
<niksnut>
you can already disable it in nix.conf
Baughn has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
BaughnLogBot has joined #nixos-dev
<domenkozar[m]>
niksnut: what's the common use case where negative caching provides a significant speedup?
<qyliss>
i'd love to see negative disk caching removed also
<qyliss>
i lost hours to it
<domenkozar[m]>
yeah I don't see how it's useful to save seconds of machine time for hours of human time
<domenkozar[m]>
but maybe it saves more than that, I'd like to understand in what cases
<qyliss>
404 Not Found doesn't mean "will never be here", but Nix interprets it as that
<domenkozar[m]>
yeah it's not even respecting http
<qyliss>
the only case where it's correct to do that for HTTP is 410 Gone
<domenkozar[m]>
my thinking is that Nix would request narinfo when building something so most of the time that means negative cache is useless, since it now has that path built
<domenkozar[m]>
in case it doesn't build (let's say the user cancels or whatever) it could mean that they expected binaries to be there or because something failed
<domenkozar[m]>
rebuilding a failure over and over again shouldn't be too common without changing hashes
<domenkozar[m]>
so I really don't see a case where it would be useful for a month
<niksnut>
not sure what you're talking about
<niksnut>
the negative ttl defaults to 1 hour
<domenkozar[m]>
ah sorry, the positive cache is 30 days
<domenkozar[m]>
I mixed it up, anyway same question applies :)
<domenkozar[m]>
niksnut: so back to my original question of when does negative caching save time
<niksnut>
for instance if you do nix-build --dry-run followed by nix-build
<qyliss>
it should be way less than an hour
<qyliss>
maybe a few minutes would be okay but even then i think it's a stretch
<domenkozar[m]>
ok, in that case it can shove off a few seconds from the second invocation
<domenkozar[m]>
I don't see anyone complaining about that missing
<domenkozar[m]>
it's most likely marginal from the whole build time if you're doing --dry-run
<qyliss>
maybe other people use Nix differently, but I use --dry-run extremely rarely
<domenkozar[m]>
I never use it but who knows
<domenkozar[m]>
lots of assumptions here
<qyliss>
if it's configurable, we could default it to 0 and advanced users who have a real need for negative caching could opt in
<domenkozar[m]>
so the way I see it is: the amount of time this would save enough time to be really beneficial is close to 0, while every Nix user I know has been burned by negative cache
<domenkozar[m]>
I myself many times
<qyliss>
it was especially horrible when I was setting up my own binary cache
<qyliss>
because occam's razor there told me I must have misconfigured the server somehow
<domenkozar[m]>
yeah everyone defaults to impostor syndrome
<qyliss>
at least if I was using some existing cache or caching service I would have had a bit more faith that it wasn't broken on their end
<domenkozar[m]>
niksnut: anyway I'd be really happy if you consider this, worst case we bring it back
<supersandro2000>
srk: ofborg does not necessarily build everything and the tests are also grey so they are often missed
<supersandro2000>
also ofborg is almost all the time overworked for darwin
<niksnut>
there is also nix-env -qa --prebuilt-only, which will do 10000s of binary cache lookups, many of which will be negative
<niksnut>
s/--prebuild-only/--status/
<supersandro2000>
and I still don't think it is very productive to tell me that CI should do that. ofborg is not easily expandable for me and I rather code something 30 minutes in bash than getting ofborg to work
<domenkozar[m]>
niksnut: but isn't that the problem regardless of negative cache?
<domenkozar[m]>
I wouldn't expect someone to run that many times
<domenkozar[m]>
but the first time they do it's gonna take a while
<domenkozar[m]>
takes 90s on my machine
<srk>
supersandro2000: fair, you could improve the script to check if review or build is really needed, but you can't expect people to contribute to your 30m adhoc bash script. I would suggest to improve ofborg but as you say, getting it running is like a trade secret (hiding in plain sight at https://github.com/ofborg/infrastructure)
<srk>
supersandro2000: ryan^tms bot was rewritten from bash to haskell by jtojn^ar at some point iirc :)
<hexa->
supersandro2000: the amount of pointless notificantions you are creating disencourages me from taking any action that subscribes me to pull requests
<gchristensen>
ofborg's notifications and status reports are really carefully designed to not give misleading information, to not train people to ignore failures, and to not give gratuitous notifications (it used to do that ... a lot)
<hexa->
unfortunately the only course of action from my end would be to ignore you on github to gain back my sanity
<hexa->
also nixpkgs-review results *after* a pr was merged for hours
<gchristensen>
it'dbe great to expand ofborg (or use github actions) to support whatever workflows we need to do good work
<hexa->
indeed
<hexa->
instead of the foundation buying fancy aarch64-darwin machines, let's invest into ofBorg, to support the daily workflow of everyone
<gchristensen>
to be fair, I don't think I've asked the foundation for macs for ofborg
<hexa->
sure, but people high up think supporting darwin is worth the effort
<gchristensen>
+1
<hexa->
but many of us lack the tooling to verify *anything* about darwin
<adisbladis>
It _is_ worth the effort
<gchristensen>
it may be possible to run illegitimate macs, but I really hesitate to do that since I don't want to get on the bad side of apple
<adisbladis>
For sure, one does not exclude the other
<hexa->
adisbladis: I don't dispute that
<hexa->
but we need ofBorg support then
<gchristensen>
+1
<adisbladis>
Absolutely
<adisbladis>
(I think there is an RFC in here)
<adisbladis>
Or maybe it ties in to the platform support tiers
<hexa->
| Is the platform normally tested by the tools like ofBorg? Is it possible to get something tested with a reasonable effort?
<supersandro2000>
srk: we should probably port the parts we really enjoy to main nixpkgs-review
<supersandro2000>
hexa-: That is one for darwin and one for linux. I could stop posting the ones that did not build anything.
<hexa->
supersandro2000: pretty please.
<qyliss>
I wouldn't bother to post if you're going to merge straight away either
<hexa->
and also stop posting if it's merged and everything is fine
<qyliss>
yeah like, unless it's actionable to someone, there's no point posting it
<hexa->
^
<qyliss>
"everything is fine" is only actionable if you aren't going to merge it
<supersandro2000>
posting nothing it everything still fails and everything is fine gives you zero information if something is fine
<qyliss>
does that matter if you merge it straight away?
<qyliss>
like, we can infer from context that you didn't merge something known to be broken
<supersandro2000>
If people merge while I run something I would need to check if the PR is still open
<supersandro2000>
didn't do that yet
<V>
supersandro2000: follow rules 11 and 12 of the Unix philosophy :)
<V>
(Well, and 13, but that's implicit here)
<supersandro2000>
People already merged broken things and I rather post an extra comment than merging broken stuff
<qyliss>
what does posting the comment have to do with not merging broken stuff?
<supersandro2000>
that you know that I did not merge it broken
<supersandro2000>
if I just merge it no one knows if it was broken or fine or whatever
<hexa->
you have commit access, I kinda expect you not to merge stuff that is broken.
<qyliss>
(at least not very often -- mistakes happen!)
<supersandro2000>
I expect that from other people, too but they did
<supersandro2000>
at least once today
<supersandro2000>
not global eval failure but the package was broken
<gchristensen>
really I just expect people to try their best
<supersandro2000>
I should probably just add a blocklist for people who are annoyed by it and just skip them entirely
<gchristensen>
let's change the question
<gchristensen>
how do we improve our tools so *every* PR gets closer examination by default?
<supersandro2000>
also other people do the same as I do but if they do it isn't a problem
<supersandro2000>
not calling names
<supersandro2000>
gchristensen: make ofborg hard fail if it fails, give it darwin machines, build depending packages
<supersandro2000>
*more darwin
<gchristensen>
like if a package is not marked as broken, and doesn't have a dependency makred as broken on that arch, fail the buidl?
<supersandro2000>
and it fails to build make the check red
<gchristensen>
maybe we're ready for that
<supersandro2000>
also if I comment that ofborg should build X I also create a notification which is even more pointless to everyone else
<supersandro2000>
and I need to wait 10 minutes to sometimes 2 hours to have a result about which I don't get notified
<supersandro2000>
and it is grey...
<gchristensen>
what would you do if it was red?
<supersandro2000>
Not merge the PR
<supersandro2000>
let the author figure it out and maybe add a comment If I care about the PR
<gchristensen>
I'm not sure that is universally true, and I'd worry about training people to ignore X's
<supersandro2000>
but you don't get any notifications if checks fail
<supersandro2000>
so we are back to square one
<supersandro2000>
I could figure out how to edit comments but is that worth the time to do? idk
<gchristensen>
that has been a fundamental tenet of the strategy since the beginning
<supersandro2000>
so I see the main problem right now: I review to many PRs and you get to many notifications. I will try to reduce them if they are not necessary but it will happen and the easiest solution for me would be to just ignore people that complain about it.
<supersandro2000>
*the main problem I see right now
* andi-
ignores ss2000 on GH to fix his personal issues
<supersandro2000>
then do it like others do
<supersandro2000>
and close your PRs if I ask a question about it
<supersandro2000>
its not like I ask people to order their inputs when they update a package
<gchristensen>
something that is making me pause here, supersandro2000, is that several long-term contributors are asking for something to change about how you're reviewing these PRs -- so I guess I'd like to think about what that is and then find a better way to do it
<supersandro2000>
please tell me if it is something I can actually change
<qyliss>
you've been told several things you could change already
<supersandro2000>
one of them was repeatedly to learn rust, learn ofborg and add big new features to a project that is not easily testable
<supersandro2000>
I don't see myself improving ofborg without breaking it for everyone at least once
<qyliss>
i'm not talking about improving ofborg
<supersandro2000>
I guess I can just merge things without commenting anything
<qyliss>
and singling that out when you know full well you've been told other things that are easily within your powers and abilities is really bad faith arguing imo
<hexa->
20:41 <supersandro2000> also other people do the same as I do but if they do it isn't a problem
<hexa->
the fact this is coming up is due to the volume of noise you are creating
<hexa->
nixpkgs-review was a useful tool to build a pr and drop yourself into an env to test it
<hexa->
you reduced it to a buildtime tool with no runtime testing
<supersandro2000>
I am currently working on some checks to post less things
<qyliss>
that's great news -- thank you!
justanotheruser has quit [Quit: WeeChat 2.9]
justanotheruser has joined #nixos-dev
<infinisil>
supersandro2000: How do you have so much time for nixpkgs btw?
<V>
being young, presumably
<V>
either that or they are in possession of a time machine
tom39291 has quit [Ping timeout: 260 seconds]
tom39291 has joined #nixos-dev
<lukegb>
V: maybe a) as a result of b)
<V>
:o
<supersandro2000>
I don't know
<infinisil>
supersandro2000: Like, student with spare time and motivation? Or working for an employer that doesn't mind? Or something else?
<supersandro2000>
more like a student that has a lot of time
<infinisil>
I see :)
cole-h has joined #nixos-dev
page has quit [Ping timeout: 265 seconds]
Jackneill has quit [Ping timeout: 256 seconds]
<supersandro2000>
qyliss: whats your github handle?
<qyliss>
alyssais
lassulus has quit [Remote host closed the connection]
lassulus has joined #nixos-dev
<supersandro2000>
anyone else wanting on the as little as possible comments on PRs they authored?
<qyliss>
supersandro2000: fwiw I don't mind having review comments!
<qyliss>
just not the noisy ones like that everything is fine immediately before a merge
<supersandro2000>
thats what I meant
<supersandro2000>
I am trying to only give review comments that are worth something
<supersandro2000>
like sorting inputs or phases I gave up on
<supersandro2000>
not worth it
<adisbladis>
supersandro2000: You're making something opt-out?
<adisbladis>
Opt-out by default things are pretty annoying
<adisbladis>
And tbh behaviour shouldn't be author dependent
<supersandro2000>
yes, people requested it
Jackneill has joined #nixos-dev
<supersandro2000>
I think it gives new contributors a bit more confidence in their changes
<supersandro2000>
we can move the bikesheet tomorrow to another place but not today
<__monty__>
supersandro2000: One observation. I don't think the "everything builds fine" comments add value. If you merge the PR then it must've built and if you don't then you probably have a build error to report. Only difference would be PRs that build fine but you don't merge, in which case ofborg'll probably eventually build it and confirm it's fine and since you're not merging it you don't have to wait for
<__monty__>
ofborg.
AlwaysLivid has quit [*.net *.split]
srk has quit [*.net *.split]
<supersandro2000>
they add value for darwin because ofborg usually does not build it intime