| 23 Oct 2024 |
 happysalada | In reply to @julius:mtx.liftm.de
happysalada: Thanks for bumping+fixing vector.
Btw, one thing I noticed while looking at the package def is that even when enableKafka is disabled, the features setup of vector still enables the rdkafka feature (e.g. transitively through sinks or sources). So to circument the ? issue, you could just add rdkafka/gssapi-vendored to the default feature list and get rid of that confusing parameter, I think. (Personally, I'd remove the parameters entirely, the feature set is insanely complex and whoever wants to touch it anyway can do so through .overrideAttrs.) This sounds good to me, if you have time for a PR, happy to merge it. Otherwise I'll try to have a look at this this weekend | 10:50:31 |
 gabyx | Somebody knows if agenix can also be used nicely with passphrase protected SSH keys?
agenix -e mysecret.age -> no password entry needed. My login keyring works with ssh without asking me for a password.
| 13:54:24 |
| gabyx | * Somebody knows if agenix can also be used nicely with passphrase protected SSH keys?
agenix -e mysecret.age -> would like no password prompt. My login keyring works with ssh without asking me for a password.
| 13:54:46 |
 Winter | ask in #users:nixos.org | 15:40:01 |
 emily | - pkgs/by-name/op/openjfx: File package.nix at line 51 contains the path expression "./${featureVersion}/source.json", which is not yet supported and may point outside the directory of that package.
infinisil: anything I can do to work around this?
| 16:08:17 |
 Daniel Fahey | I edited a PR title to correct a typo after it was merged (and after I had deleted my branch). This led to the GitHub Action (Codeowners workflow run) failing https://github.com/NixOS/nixpkgs/actions/runs/11483745454 I've now restored my branch, so if it can run again it should succeed. Don't think I have permissions to re-run it / maybe it's not a big deal? | 16:27:24 |
| emily | it's fine | 16:30:26 |
| emily | In reply to @emilazy:matrix.org
- pkgs/by-name/op/openjfx: File package.nix at line 51 contains the path expression "./${featureVersion}/source.json", which is not yet supported and may point outside the directory of that package.
infinisil: anything I can do to work around this?
I'm not sure why ./${foo}/x is banned when as far as I can tell ./. + "/../x" is allowed (though I haven't actually tried it yet, just skimmed the code). | 18:05:30 |
 ma27 | In reply to @emilazy:matrix.org
I'm not sure why ./${foo}/x is banned when as far as I can tell ./. + "/../x" is allowed (though I haven't actually tried it yet, just skimmed the code). I think it's because Nix 2.3 should still be able to evaluate nixpkgs? | 18:06:32 |
| ma27 | I'm pretty sure the feature got introduced in Nix 2.4. | 18:06:42 |
 aloisw | Yeah 2.3 didn't have it. | 18:06:56 |
| emily | huh, really? I was focused on the "may point outside the directory" part. | 18:07:05 |
| emily | which seems spurious. | 18:07:10 |
| emily | but TIL. | 18:07:11 |
| emily | I thought "not yet supported" meant, like, in nixpkgs-vet, not in Nix 2.3 :) | 18:07:43 |
| aloisw | Lol that may be a reason too, and the check not catching the addition variant is just a weakness then. | 18:08:00 |
| emily | well… | 18:08:11 |
| emily | a kind of unavoidable weakness | 18:08:14 |
| emily | I don't think that's a property you can reasonably statically lint | 18:08:25 |
| emily | if we want to absolutely enforce that by-name rule we need interpreter support | 18:08:41 |
| aloisw | Or you can err on the side of outlawing too much, like the interpolation check already does. | 18:09:13 |
| emily | right. I just mean I'm not sure you can possibly outlaw enough | 18:09:26 |
| emily | builtins.readFile (builtins.readFile ./foo) | 18:09:31 |
| aloisw | You can just forbid that too… | 18:09:51 |
| emily | I would be shocked to see a linter for this rule that doesn't just outlaw file operations entirely that I couldn't think of a way to get around. | 18:09:55 |
| emily | In reply to @aloisw:kde.org
You can just forbid that too… forbid readFile entirely, or? | 18:10:06 |
| emily | I guess "no readFiles without literal arguments" is viable. | 18:10:18 |
| aloisw | No, readFile on everything the static analyzer doesn't recognize. | 18:10:26 |
| aloisw | Like literals or very simple expressions it can resolve. | 18:10:37 |
| emily | right. | 18:10:57 |
