supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
alp_ has quit [Ping timeout: 272 seconds]
immae has joined #nixos-dev
rajivr has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
kalbasit_ has quit [Ping timeout: 240 seconds]
Ericson2314 has quit [Ping timeout: 244 seconds]
ris has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
marek has quit [Ping timeout: 246 seconds]
marek has joined #nixos-dev
m1cr0man has quit [Quit: G'luck]
Jackneill has quit [Ping timeout: 246 seconds]
m1cr0man has joined #nixos-dev
Jackneill has joined #nixos-dev
alp_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
saschagrunert has joined #nixos-dev
teto has joined #nixos-dev
sgo has joined #nixos-dev
stigo has quit [Ping timeout: 260 seconds]
sgo is now known as stigo
FRidh has joined #nixos-dev
stigo has quit [Ping timeout: 246 seconds]
pmy has joined #nixos-dev
<pmy>
I sent a PR to NixOS/nixpkgs 6 months ago. Finally the PR received a reply two days ago asking me to solve merge conflicts. I did. But nothing else happened. It seems the reply is from a merge conflict detection bot. Is there any human here actually willing to review code? The PR is #87735.
<supersandro2000>
I have 1682 GitHub notifications currently
<etu>
supersandro2000++
<{^_^}>
supersandro2000's karma got increased to 0o22
<etu>
{^_^}: troll
<supersandro2000>
also I have currently like 50 other tabs to review open. I slowly go through them but I am in no rush
<pmy>
Are you actually going to review the code? If not, you are actually spamming me.
<pmy>
The PR receives no reply for six months. If there is another six months wait period. I guess the next reply will also be merge conflicts.
<etu>
pmy: Don't complain about that someone started to care about your PR ;)
<supersandro2000>
I can't test if it actually builds when there is a merge conflict
<supersandro2000>
and I started to filter those PRs so if you have another PR that is like this I won't actually reply to it anytime soon
<pmy>
I have tested it and have run it on my computer for a year.
<pmy>
The merge conflict is caused by a minor change to maintainer-list.nix. I thought only a bot will be confused by that. I searched PR history and found you replied to many PR with a single line "please solve the merge conflict". Threfore I thought you are a bot. Sorry. I was wrong.
<eyJhb>
supersandro2000: *beep beep*
FRidh has quit [Ping timeout: 272 seconds]
<eyJhb>
I can only say, that it builds for me. Not really sure if I can test the PR..
<lukegb>
pmy: I understand it's frustrating but please don't take it out on people :( - there are a lot of pull requests to review, so there's a need to lean quite heavily on things like GitHub saying "this won't merge cleanly"
FRidh has joined #nixos-dev
cole-h has quit [Ping timeout: 256 seconds]
__monty__ has joined #nixos-dev
<supersandro2000>
also GitHub does not calculate this all the time correct
<supersandro2000>
I run nixpkgs-review, do something else, come back 10 minutes later and then merge conflict
<supersandro2000>
also if it would be a bot I would use SuperSandroBot
FRidh has quit [Ping timeout: 246 seconds]
<lukegb>
whenever I see your nick I can't help but wonder if there will be a SuperSandroXP, SuperSandroVista, etc.
<supersandro2000>
I don't understand it. It works when building manually...
<supersandro2000>
lukegb--
<supersandro2000>
think about the console in older Windows.
<pmy>
I have heard from my friends that they refuse to submit PR to NixOS becaued they have to wait months before getting a reply. This is a serious problem for an open source project. I wonder what's your guys opinion and what has been done to address the problem?
<lukegb>
supersandro2000: hmm, does the same thing happen if you run nixpkgs-review again? meta.broken definitely _seems_ to be false
<lukegb>
oh, nvm, I see it
<supersandro2000>
pmy: there are just to many open PRs and bots could really help churn through them if they remind people to fix their PRs if they get merge conflicts, have common issues, are already included in master etc
cole-h has joined #nixos-dev
<lukegb>
pmy: If you're interested in helping, more reviewers would be appreciated :)
<lukegb>
Knowledgable people to review PRs, even without the commit bit, is useful because the maintainers don't have broad knowledge of every piece of software that exists
thibm has joined #nixos-dev
<lukegb>
supersandro2000: so nixpkgs-review sets 'checkMeta = true;' which means evaluation will fail if there are unknown meta attributes - it might be worth setting that in your local nixpkgs config, at least when building things to test them
<supersandro2000>
lukegb: thanks for digging this up
<supersandro2000>
this should also fail when manually building
<supersandro2000>
just add checkMeta = true to nix.conf?
<lukegb>
no, in your nixpkgs config (e.g. where you have allowUnfree, maybe)
<lukegb>
you might not have allowUnfree :)
<supersandro2000>
I do
<supersandro2000>
I am searching the man page for it
* lukegb
looks
<lukegb>
this doesn't actually seem to be documented anywhere
<lukegb>
copumpkin was planning to default it to true ~3y ago but that never happened
<supersandro2000>
{
<supersandro2000>
}
<supersandro2000>
checkMeta = true;
<supersandro2000>
allowUnfree = true;
<supersandro2000>
that does not work...
<eyJhb>
pmy: I think that most don't really ping maintainers as well. I think the longest I have waited for is like 1-2 weeks
<eyJhb>
But then when you ping, one should ensure that it builds, merge cleanly, etc... But yeah, there is a ton of PRs
<supersandro2000>
and now I can't delete the build nix store file...
<eyJhb>
Also why I wondered if we have any good guidelines for what to do. I have access to some nice stuff while at UNI, so I could run a bunch of tests while there...
red[evilred] has joined #nixos-dev
<red[evilred]>
yeah - lots of PRs
<red[evilred]>
sometimes it takes a bit of patience
cole-h has quit [Ping timeout: 256 seconds]
<supersandro2000>
eyJhb: I can't really build anything that rebuilds the gtkwebrendere (?) and above 100 packages
<lukegb>
there are some efforts to improve things - I think in particular the efforts on BORS and trying to give maintainers more power over their packages without involving someone with the commit bit
* lukegb
is building chromium for the 4th time
<lukegb>
I just wanted to test my pulseaudio PR on an actual system :(
<eyJhb>
For now at least, not sure how long it lasts, I have access to a VM with 32 cores and 256 GB ram, so I can build quite some stuff...
<eyJhb>
Would still be cool with a Nix community builder that maintainers etc. could use
<red[evilred]>
lukegb (IRC): that would help a lot I think
<lukegb>
at the moment the maintainers list is a bit arbitrary in terms of semantic meaning imo :P
<red[evilred]>
lukegb (IRC): is there a thread tracking that? I'd love to see the progress on it
<pmy>
lukegb: What's the best pratice to build and test a commit?
<lukegb>
That... I can't really answer. A lot is dependent on how you're set up - if you're using channels it's a bit tricky, I think
<supersandro2000>
pmy: thats why I started to look at PRs which are open since a long time, have no label with marge conflicts and are no drafts.
<supersandro2000>
Can't you overwrite a specific module with a file? Then you could clone the repo, checkout the PR and change the module location
<lukegb>
It's the package definition, really, not the module. But yeah, a nixpkgs overlay should do.
<pmy>
I am using nixpkgs.config.packageOverrides. pkgs.cacert caused a rebuild-the-world. Still waiting.
<lukegb>
pmy: yeah, maybe better to wait until it lands then... sorry.
sphalerite is now known as L1nuxH4ckerm4n
L1nuxH4ckerm4n is now known as sphalerite
orivej has joined #nixos-dev
alp_ has quit [Ping timeout: 272 seconds]
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
alp_ has joined #nixos-dev
mkaito has joined #nixos-dev
<lukegb>
andi-: re #105568 do you have better suggestions for writing a test for the override knob? I kinda want to ensure that there's actually a CA present with those names (probably just grep) in the input set but not the output set but I'm reluctant to add more arguments just to make that all work
<red[evilred]>
but on that subject - I know this is certainly true for the security issues - but when you have a large block of stuff, it's difficult to navigate around so you spend more of your time context switching than actually doing the work.
<eyJhb>
Taneb: Would be nice, so they could have a category
<lukegb>
although... representing nixpkgs and nix on the same graph seems funky
<Taneb>
Not having written any NixOS modules so far I think I fall short for now :(
<gchristensen>
Taneb: probably the most important thing is knowing your own limits
<red[evilred]>
Taneb (IRC): I feel the same way and don't stress it. There's still plenty of other opportunities to contribute until you do feel comfortable.
<red[evilred]>
for example - I chewed down the security issues queue by more than 50% over the last week and a bit. Most of them were either old or already fixed with a PR but someone forgot to close the issue
<gchristensen>
Taneb: I don't think there would be any objections to you being added, I pinged domen
<eyJhb>
red[evilred]: doing the lords work
<Taneb>
gchristensen: thanks
<eyJhb>
Only 13 security PRs open now
__red__ has joined #nixos-dev
<red[evilred]>
yup and many of them are ready to go and have gone through review from multiple people
<red[evilred]>
but I guess haven;t found a committer that feels comfortable / empowered? to commit them
<red[evilred]>
(the fact that 3 of my 5 are all for cassandra probably means that when the right committer finds them then all 3 will likely merge at once)
<lukegb>
can someone add the needs-backport tag to #105568 for me
<red[evilred]>
This is perhaps a stupid question - but I'm going to ask anyways.
<red[evilred]>
in order to compile for darwin... if everything is sandboxed in hydra / nix
<red[evilred]>
what are the strong / absolute limitations on it having to run on OSX
<red[evilred]>
ELF format & linking I'm guessing
<red[evilred]>
anything else?
<Taneb>
The link to the source on search.nixos.org is broken :( it's adding an extra /source/
<eyJhb>
How come nix not like int as strings? E.g. I have a attrset with "2019" as a key, but I do `nix-build -A "2019.web-awesome-calculator.build"`, but I can change it to foo, and it will work ("2019" -> "foo")
FRidh has quit [Ping timeout: 240 seconds]
saschagrunert has joined #nixos-dev
<cransom>
eyJhb: ints as keys aren't supported. the general practice is to prefix with a _ if you have something that starts with a number.
<eyJhb>
Guessing I will just rename it to challenges2019 then :) Is there any good place to read about scopes? I have something like test = config: let ... in { config ? config }: funcname "string" config;
alp_ has quit [Ping timeout: 264 seconds]
<__red__>
cransom: I sent you a PM earlier - I figured it was the politest way to say "Hi" and stuff
<__red__>
cransom: I don't like spamming people with github notifications so hit you up there instead
<__red__>
can you take a peek please?
kalbasit has joined #nixos-dev
<thibm>
eyJhb: cransom: int as keys are not supported, but "strings containing int" obviously work.
<thibm>
> { "a" = 0; "1" = 2; }
<{^_^}>
{ "1" = 2; a = 0; }
<thibm>
But that is tricky to use from the command line.
<gchristensen>
> { ${0} = "hi"; }
<{^_^}>
value is an integer while a string was expected
<thibm>
they are* supported. (correct me if I'm wrong)
<gchristensen>
neat
<lukegb>
> { "1" = 2; }.1
<{^_^}>
attempt to call something which is not a function but a set, at (string):440:1
<thibm>
(no they are not. raah)
<thibm>
> { "1" = 2; }."1"
<{^_^}>
2
<lukegb>
yeah
<thibm>
I think had a trick to use it from command line but I don't remember
<thibm>
Found it: `nix-build -E 'with import ./. {}; "2019".web-awesome-calculator.build`
<thibm>
instead of `nix-build -A "2019.web-awesome-calculator.build"`
<thibm>
eyJhb: ^
<lukegb>
I end up falling back to, err, things like `nix-build -E '((import ./. {}).foo.bar.baz)'`
<lukegb>
yeah
<lukegb>
Yours is more elegant :P
<thibm>
It's not elegant but it works with int-as-strings without the shell interfering
<thibm>
with the quotes
<thibm>
:q
<thibm>
(gasp). And `(import ./. {}).` is better than `with`
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
saschagrunert has quit [Quit: Leaving]
<eyJhb>
thibm: yeah, the command line does not make it fun. But I it makes sense why it works that way I guess
<infinisil>
thibm: nix-build -A '"2019".web-awesome-calculator.build'
<infinisil>
Works
<thibm>
That what I was trying to test, there's no reason it doesn't work.
<thibm>
Something strange: take this file: http://ix.io/2GaO and run nix-build. You only get the gcc output.
<thibm>
nix-build -A '"1"' does not work
<gchristensen>
one complicating factor here is that nix-build takes integers for indexing lists
<gchristensen>
let pkgs = import <nixpkgs> {}; in [ pkgs.hello pkgs.bat ]
<gchristensen>
nix-build ./test.nix -A 1 -> bat
<LnL>
huh, you can do that?
<thibm>
oh. nix-build -A '"1"' -> bat too
<thibm>
that explains the `the selection path '"1"' should be a list but is a set`, thanks.
<gchristensen>
yes and it nests too let pkgs = import <nixpkgs> {}; in [ [] [ pkgs.hello pkgs.bat ] ] -> 1.1
mkaito has quit [Quit: WeeChat 2.9-dev]
rajivr has quit [Quit: Connection closed for inactivity]
alp_ has joined #nixos-dev
ris has joined #nixos-dev
<supersandro2000>
What do you think about a shellcheck github action?
<gchristensen>
we have about 500 of them, that sounds good
<infinisil>
Would probably miss many since they're embedded in Nix multiline strings
<infinisil>
And by many I mean most, since pretty much every derivation uses shell scripting
<infinisil>
But nevertheless, I think checking some is still better than none
<gchristensen>
yeah but if you look at the .sh files we have, they're imo the important ones
<gchristensen>
the shell embedded in to derivations is largely trivial
<infinisil>
Hehe, and we'd get a million "unquoted variable" errors
<gchristensen>
supersandro2000: I'm super +1 on this, however, I think it would require some planning on how to do it
<gchristensen>
how many of our 490 shell scripts will fail, and how can we fix them all before applying the check? (important: red X's should never be ignored)
<V>
so, there's already the editorconfig check, which just fails on files touched by a PR?
<gchristensen>
right, do we expect people to fix editorconfig fails? (imo yes : red X's should never be ignored)
<V>
well, that's what I've been doing so far
<V>
I think that's a reasonable way to encourage cleanup
<V>
if it fails, I just add the whitespace changes/etc in another commit
<lukegb>
I think that's more feasible with editorconfig; shellcheck is probably a little more tricky
<V>
like there are cases where you will want to apply shellcheck exceptions
<gchristensen>
we could make this in to a to-do issue
alp_ has quit [Ping timeout: 272 seconds]
<lukegb>
can we have a github action that checks that there are *fewer* shellcheck errors in modified files than there were before?
<lukegb>
and then have a todo issue :P
<gchristensen>
nice ratchet
<lukegb>
I was wondering about doing it diff-based on changed lines, but... I think a ratchet is probably easier and has ~the same effect at lower cost
<gchristensen>
lukegb: would you like to write a github action for a ratcheting shellcheck?
<lukegb>
I can give it a shot at least
<lukegb>
the mypy one is a good template
<gchristensen>
that would satisfy my main annoyance: that stage-1 and stage-2 and other highly critical shell scripts aren't checked
cole-h has joined #nixos-dev
mkaito has joined #nixos-dev
<supersandro2000>
infinisil: you can configure everything about shellcheck globally
<supersandro2000>
I would just let it run on changed files anyway
<supersandro2000>
if we don't want to fix it ignore it or add a TODO and a shellcheck disable for now
<supersandro2000>
disables can be done in the cli tool globally, per file or per line
<gchristensen>
I'd prefer fix them than ignore or disable
<gchristensen>
and I think lukegb is right that we can organize a fixup party
<supersandro2000>
there are certainly false positives
<supersandro2000>
like prefer command over which
<qyliss>
which isn't in stdenv, is it?
<qyliss>
I'm sure I've had to add that as a nativeBuildInput before
<supersandro2000>
qyliss: in nix command is fine to use
<qyliss>
exactly?
<qyliss>
so how would "prefer command over which" be a false positive?
<supersandro2000>
but I replace a lot of stuff with functions in my bashrc and command takes a function as a valid binary no matter if it actually works
<supersandro2000>
eg I replace grep with rrg and cat with bat
<supersandro2000>
*rg
<supersandro2000>
and I add some default commands to things and so on
<supersandro2000>
so grep checks if rg is there but rg is also a function and command would always trigger it even if I do not have rg installed
<supersandro2000>
and rg was also an alias to ripgrep