jonringer has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
jonringer has joined #nixos-dev
justanotheruser has quit [Ping timeout: 276 seconds]
justanotheruser has joined #nixos-dev
<abathur>
working on something that analyzes an arbitrary ${package}/bin/* and saves the result to $out, but I'd also like to be able to ~override the result for some packages (ex: synthesizes something like the result for multi-binary coreutils even when the package is single-binary coreutils)
<abathur>
if you've done something like this, curious what you think about approaches; I imagine having a directory of scripts, and selecting them based on at least package name; less sure where to go from there
justanotheruser has quit [Ping timeout: 260 seconds]
<abathur>
I guess an obvious answer is selecting the first-found and using a few properties from most to least specific, but anything that required more than the package name would end up being a lot of upkeep
<abathur>
for something that won't really be changing much unless individual executables are added/removed or significantly revised
supersandro2000 has quit [Killed (kornbluth.freenode.net (Nickname regained by services))]
supersandro2000 has joined #nixos-dev
tdeo has quit [Read error: Connection reset by peer]
tdeo has joined #nixos-dev
tdeo has quit [Ping timeout: 276 seconds]
tdeo has joined #nixos-dev
tdeo has quit [Excess Flood]
tdeo has joined #nixos-dev
jonringer has quit [Ping timeout: 276 seconds]
cole-h has quit [Ping timeout: 240 seconds]
evanjs has joined #nixos-dev
asymmetric has quit [Changing host]
asymmetric has joined #nixos-dev
orivej has joined #nixos-dev
urkk has left #nixos-dev [#nixos-dev]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<domenkozar[m]>
gchristensen++ for merging abathur++ work on macOS installer
<{^_^}>
nix#4635 (by roberth, 7 weeks ago, open): Unsmudge fetchGit for reproducibility and security
<das_j>
roberth: So to make fetchgit pick up changes we need to commit the changes?
<das_j>
(In a local repo)
<roberth>
das_j: it still works the same from the user perspective
<qyliss>
roberth++
<{^_^}>
roberth's karma got increased to 7
<das_j>
whew
<roberth>
das_j: it does create a temporary commit for technical reasons
<das_j>
Ahh I see. Great because that would have been highly annoying for rapid testing ;)
<roberth>
100%
ScottHDev has joined #nixos-dev
<ScottHDev>
Hello, do you know if such a stdenv adapter like overrideCC exists for the c++ compiler
<ScottHDev>
?
<sterni>
C and C++ compiler are always bundled afaik
<ScottHDev>
I tried building an instrumented libX11 with clang, but it didn't work : https://gist.github.com/SCOTT-HAMILTON/71106840b28087cd24e2f7e6aae9c85f. It uses gcc's cpp binary for compiling C++, which fails because it doesn't support clang's instrumentation flags : `cpp: error: unrecognized command-line option '-fcoverage-mapping'`
<eyJhb>
But... I am unsure if it makes the most sense to have it in the `bindZoneOptions.config { name = mkDefault name; }`, or `bindZoneOptions.options.name = { default = name; }` <- Which I guess is the actual question
<eyJhb>
infinisil: You are also free to answer if config vs. options default is better :p (if my question makes sense)
<infinisil>
eyJhb: I'd go for config
<eyJhb>
Is there any reason? Or just because it becomes more visible?
<infinisil>
Hm actually, how does the options version render in the manual?
<infinisil>
I guess it would be something like `default: <name>`, which I then think is better than using `config`, since with `config` you won't know the default from the manual
<lukegb>
ScottHDev: it turns out libX11 seems to do some complicated things that end up dragging in buildPackages.stdenv
<ScottHDev>
Yes, I had to make an ugly patch on the configure script to make it use clang
<eyJhb>
infinisil: I have no clear example of something that uses `default`. But yes, if it does that, it would make sense.
<lukegb>
I mean, if it renders "wrong" then fixing it with defaultText is also fine, right?
<lukegb>
but also I was mostly wondering whether we should be more structured about the config and enforce that the attribute name is the name of the zone
<gchristensen>
https://nixos.wiki/index.php?diff=5631&oldid=5007&rcid=5823 this adds "One advice is that if you have systemd services depending on Consul via <code>After=consul.service</code>, you may want to switch consul service type no <code>notify</code>, to make sure that dependent services don't try to run until Consul is ready to accept connections:" -- shouldn't we just ... fix our systemd module to be
<gchristensen>
of type notify?
<lukegb>
probably
<lukegb>
if it already has systemd integration then, err, yes
<eyJhb>
lukegb: Hmm.... I like the flexibility of having a different value. I just had some annoyance with wireguard yesterday, where you cannot specify the name of the interface, but you are forced to use `interfaces.<name>....`, which is.. really annoying
<__monty__>
If you'd really like to identify the zone by a different name you could always use `let myAwesomeZone = {...} in zones.myBoringZone = myAwesomeZone`, right?
<__monty__>
Yeah ok, that doesn't escape the local scope.
<lukegb>
I guess the biggest question is really: a) how hampering is it, and b) how well will we cope with non-unique zones
<eyJhb>
lukegb: It is more how well bind9 will deal with it. NixOS does not care :)
<lukegb>
That's a pretty defeatist attitude :P
<eyJhb>
As the "current" one has a listOf submodule, which can have the same name as any other.
<eyJhb>
So this will only be more strict and limiting. There might be usecases where you would like the same name maybe?
<lukegb>
Sure, but if we're changing it _anyway_ then we should at least consider improving the situation
<eyJhb>
True.
<eyJhb>
But, I am unsure if it makes sense to have multiple "zone" in a Bind9/named config?
<lukegb>
It might if you're doing split-horizon DNS?
<eyJhb>
( infinisil , you know this? )
<lukegb>
Ah, except we currently don't support split-horizon DNS like that anyway
<lukegb>
since it would need to be nested inside a view, and it's at the top level in our generated config
<infinisil>
eyJhb: Hm I don't think it makes sense to have the same zone in the same bind config, but multiple different zones does make sense
<eyJhb>
Got an answer from the bind community. It does not make sense in the same view, ie. the global view that we are in
<eyJhb>
So the only advantage is to name it something, that isn't the same as the actual zone name
<infinisil>
eyJhb: The only advantage to a name option instead of just using the attribute name?
<eyJhb>
Also __monty__ , then I would have to do some hackery. The example you gave would assume I have the domain "myBoringZone"
<eyJhb>
infinisil: The only advantage of not using mkForce, would be to name it something, and use that name
<eyJhb>
(which I quite like??)
<lukegb>
I don't mean use mkForce here, I meant just set it to a thing (which would require the user to use mkForce to override it)
<eyJhb>
Oh... Hmm... That I would be OK with :) But I am not sure if it is a big win?
<eyJhb>
BUT! I don't have the strongest opinion about this. :) So that could be done lukegb :)
<lukegb>
It's certainly not worth bikeshedding *too* hard about. :^)
<eyJhb>
Just a _little_ :D
<eyJhb>
But it would be really nice with a standard way of doing such things. :) But it does put _some_ limitation somewher, at some point, with a big maybe.
<eyJhb>
s/big/_BIG_/g
<eyJhb>
Are there anyone against dropping `mkDefault`, which would result in the user having to use `mkForce` to change it? infinisil ?
<ris>
yyyyyyyyyyeah but i wonder if all that would do is give people "stop energy"
<ris>
if you make any proposal to a group of people about 2 in 10 will disagree, almost no matter how good the idea is
<ris>
and hearing that "no don't bother" might stop people picking up tools for something that could be quite good
<ris>
but what do i know
<infinisil>
If people do non-ideal things, we need to let them know at some point
<infinisil>
I don't really want to merge PRs that go in the wrong direction
<MichaelRaskin>
infinisil: Nixpkgs PRs are not the only thing lacking officially separating that, and yes
<infinisil>
And it's better to let them know early in the review process, than having 3 different people review for formatting and correctness first, and then letting them know
<MichaelRaskin>
There are no ideal things, but then there is the question for what share of people this is the wrong direction
<infinisil>
Yeah, but I think that's a separate issue
<infinisil>
Whether or not something is a good idea is orthogonal to when this discussion should be had
<Dandellion>
aminechikhaoui: You're the only one I can find that has experienced "hydra-eval-jobs returned exit code 99:"
<Dandellion>
Do you remember if you did anything to fix it?
<MichaelRaskin>
Things are quite often not good ideas for everyone, and very rarely not an improvement for submitter…
<MichaelRaskin>
So «good idea» is definitely a question of «good idea for whom»
rj has quit [Ping timeout: 240 seconds]
rj has joined #nixos-dev
* infinisil
nods
<abathur>
I've idly wondered if there's a cunningham's law gamification/hack like: when there's general agreement about <problem> or <objective>, we agree to merge any working PR that ~plausibly addresses it within <N days> unless someone submits a PR with an approach we agree is better (in which case, the timer resets)
<MichaelRaskin>
abathur++
<{^_^}>
abathur's karma got increased to 29
<MichaelRaskin>
And I think I have proposed something similar today, I don't remember in which channel
<abathur>
re infinisil and deciding phase: if 1) there was a well-known opt-in process (i.e., do X to get buy-in on your proposal before wasting your time) and 2) the queue was cleared quickly, people would voluntarily use it for more ~architectural changes
<abathur>
but I'm less sure about how to get to the well-known opt-in? if PRs worked like issues a template might be a good funnel; could have some bot command but I suspect the people who need it most won't realize it exists
<infinisil>
Hm yeah
<abathur>
by PR-template time it seems like it's too late? unless maybe there's an opt-in checkbox on the template that can actually drive a process that discourages anyone else from nit-picking it until there's a general approval
<abathur>
I guess that doesn't really affect whether it is too late, but it'd still be an improvement over present
<ekleog>
wouldn't the opt-in process approximately be RFCs? (IMO we should re-enable the issues on the RFCs repo so people feel more at ease posting quick ideas without all the bloat of a full RFC, and then depending on the early feedback move on with either a PR or an actual RFC)
<MichaelRaskin>
Maybe create a separate RFC-ideas repository with _only_ issues then?
<abathur>
I mean, yes/no/maybe?
<aminechikhaoui>
Dandellion I didn't remember it at first but looking at the irc logs I commented that it was due to builtins.trace usage somehow
<abathur>
the nice thing about actual PRs, I guess, is that they get you on the other side of the "ideas are cheap" firehose
<abathur>
and you're only having to cope with people who were willing to implement something
<MichaelRaskin>
Also, GitHub cannot into categories, so if you something of a vastly different weight category, put it into separate… oh, the only separation is repo, so repo it is
<abathur>
the downside: wasted that person's time
<MichaelRaskin>
abathur: well, a convincing spec is not always cheaper than the code
<MichaelRaskin>
But a bit easier to do cross-cutting changes than during PR review
<ekleog>
MichaelRaskin: I'm curious, what would be the point of splitting one issue-only repo and one PR-only repo?
<abathur>
so if an ideas repo had a very good agree->PR ratio it would probably be a net positive, but if that ratio was very bad, it'd probably just waste more time?
<MichaelRaskin>
Subscribing to all new PRs in the fleshed one without getting the more numerous notifications from the smaller one?
<ekleog>
abathur: I mean even if the agree -> PR ratio is bad at least it would give a list of ideas for improvements that anyone can take at any time
<MichaelRaskin>
I mean, if it is _known_ to have low ratio, then it becomes a watercooler
<MichaelRaskin>
Which is fine as long as expectations are aligned
<MichaelRaskin>
ekleog++ also that
<{^_^}>
ekleog's karma got increased to 14
<abathur>
in theory yes, but if it is a graveyard the smart knowledgeable we need making sound judgement about whether a change rows in the wrong direction will stop wasting their time
<ekleog>
(the rust rfcs repo's issues have a very low ratio, at least for the issues I'm involved in I think it has like less than 5% of issue -> RFC, though I think that RFC -> PR is more like 90-95%)
<abathur>
and if you can't get to a decision quickly, the person who was interested will lose interest
<ekleog>
MichaelRaskin @ notifications : oh yes it makes sense, would be cool if github allowed to watch a repo for PRs but not issues :/
<abathur>
(i.e., I feel like I'd rather waste 3 hours on one day on a PR that goes nowhere than 1 hour on a proposal that never gets a comment or never gets any conclusive feedback)
<ekleog>
abathur: in practice what I've seen happen on the rust rfc issues is basically it's a first filter of feedback, and then either people get told “it should be uncontroversial enough, go on and implement”, or the result is “let's not debate on this issue and actually draft an RFC because there's no obvious answer)
<abathur>
maybe we are just imagining different change scopes; perhaps infinisil can clarify whether these are things that could/should be RFCs, or if this is more like "we could spare a lot of rowing if certain kinds of change were getting a gut-check from people who know where we're trying to go"?
<infinisil>
Yeah I just thought of a gut-check
<MichaelRaskin>
I think we might want «RFC ideas», and we might have «half-RFC scale ideas go/no-go»
<MichaelRaskin>
Below I guess it makes more sense to play with PR template
<abathur>
elevator pitches? but I also don't know if infinisil means more wrt to the goal of the change or the implementation
<abathur>
if the latter, PR template much more plausible
rajivr has quit [Quit: Connection closed for inactivity]
rj has quit [Quit: rj]
* lukegb
tries to figure out how to ducktape Rust onto buildPythonPackage
<lukegb>
I actually did an awful thing with duktape and Python
<samueldr>
what if you "duktape"'d rust onto python through that interpreter?!
<lukegb>
I extended dukpy so you could pass Python objects into JS and JS objects into Python
<lukegb>
and call methods and stuff
<lukegb>
--> -chat, anyway
<samueldr>
:)
<Dandellion>
aminechikhaoui: oh. hmm I don't think it's the same then, sorry for ping!
rj has joined #nixos-dev
rj has quit [Client Quit]
rj has joined #nixos-dev
rj has quit [Client Quit]
rj has joined #nixos-dev
rj has quit [Client Quit]
rj has joined #nixos-dev
<samueldr>
any reasons it wouldn't be worth it to backport changes to Nix "next" (master) into Nix "current" to produce e.g. Nix 2.4?
<samueldr>
I'm sure there are improvements that are all around good to get out
<samueldr>
anything that's not experimental changes, I guess
<samueldr>
though I also don't have an exhaustive list of changes that this would include
<niksnut>
samueldr: problem is that there have been some significant changes to the code that make backporting a lot of work
<samueldr>
are those significant changes not worth "backporting", maybe a nix 3.0 without the experimental stuff?
<samueldr>
so that when the time comes to get the new features out of the gate, there is less testing of the significant changes that needs to be done, but mainly the new experimental stuff
<niksnut>
I'm talking about refactorings like the build.cc split
<niksnut>
they make it hard to cherry-pick changes from master
<samueldr>
yeah, I'm talking aobut cutting a "non-flakes" release out of master, in a way, but didn't want to single out a single experimental feature
<puck>
i would love it if nix-build --store $binary_cache somehow got backported; i looked at it but it was somehow so much code
<niksnut>
flakes are a relatively isolated feature
<niksnut>
well, except for the nix CLI changes
<samueldr>
not sure if there are other experimental features
<niksnut>
but CA is very intertwined with the build / store API changes
<samueldr>
I fear that Nix development is accumulating changes into a big ball that's only becoming harder to get out of the door for a next release
<samueldr>
so improvements aren't available to end-users
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
Mindavi has joined #nixos-dev
<Mindavi>
I'm trying to test the experimental ca-derivations feature, but I keep running into an error that says to enable it with --experimental-features ca-derivations. I already have that in the command line but it still fails
<Mindavi>
In the end I've added it to the config file, which does work, but I'd expect the command line to pick it up as well
<samueldr>
Mindavi: multiple "--experimental-features" flags given on the CLI?
<samueldr>
not sure if that was reported/fixed, but IIRC only the latter one takes effect?
<Mindavi>
For reference: `nix-build --experimental-features 'ca-derivations' -A rtl_433` with the __contentAddressed = true in the rtl_433 package
<samueldr>
(at least at some point in the past)
<Mindavi>
I was trying to do multiple, but I just fell back to the old nix cli to prevent having multiple flags there
<Mindavi>
Still didn't work :(
<andi->
Mindavi: define it in the nix.conf
<Mindavi>
Yeah, that's what I did in the end
<Mindavi>
That worked :)
<Mindavi>
But the application is explictly saying to add it to the arguments, only then failing to actually pick it up somehow
<jonringer>
Am I going crazy, or is there no staging-next PR right now?
<Mindavi>
So I thought that I maybe did something wrong, who knows
<andi->
Mindavi: no, there is already a Nix issue about that.
<gchristensen>
ris: :)
<Mindavi>
jonringer: I can't see anything open
<qyliss>
i noticed that yesterday
<ma27[m]>
niksnut: in case you haven't seen it, there's also https://discourse.nixos.org/t/improving-flakes/12831 . My impression is that the (current) problem for a lot of people (in this thread) is that it's not really clear where the entire flakes topic is currently going. I guess it may help if you could give some context there (just in case you currently have time&energy for that, of course!)
<regnat[m]>
Mindavi: At a guess I’d say that it’s because you’d need to pass the flake to the nix daemon and not just the client
<regnat[m]>
(If that’s the case, then that indeed makes a rather unfortunate user experience)
<drakonis>
it would help to have a roadmap for the nix ecosystem beyond flakes
<drakonis>
its somewhat nebulous and uncertain
<Mindavi>
Regnat[m]: Oh, that could well be possible. I already found an issue describing that you need to be a trusted user for the daemon for this feature, but that didn't seem to be the issue
<drakonis>
knowing the direction nix is taking is fairly important for evangelizing it to people that want nix but misses something that could be in the near future
Jackneill has quit [Read error: Connection reset by peer]
<jtojnar>
jonringer: I think we are doing the GNOME PR now
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
supersandro2000 has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
julm has quit [*.net *.split]
dotlambda has quit [*.net *.split]
justanotheruser has quit [Ping timeout: 246 seconds]
supersandro2000 has joined #nixos-dev
julm has joined #nixos-dev
ajs124 has joined #nixos-dev
dotlambda has joined #nixos-dev
aminechikhaoui has joined #nixos-dev
<jonringer>
jtojnar: ah, makes sense, wouldn't want to do another mass rebuild if one landed. I'll prioritize reviewing your PR then
<jonringer>
I was mostly wondering because ZHF will begin at the end of the week, we would essentially need to start the staging-next PR now, if we wanted to have it potentially merged by then
<jtojnar>
it is mostly ready
<jtojnar>
unfortunately, it seems to be currently stuck on upstream bug with gdm
<jonringer>
Yea, I see that, thanks for all the hard work :)
<jonringer>
jtojnar++
<{^_^}>
jtojnar's karma got increased to 72
<jtojnar>
it would help if we had someone familiar with pam
<cole-h>
I wonder why it's using /merge instead of /head
<cole-h>
maybe it's because there's a merge conflict that it's failing? idk
<cole-h>
maralorn: try resolving the conflict and force-pushing the PR, maybe?
hax404 has joined #nixos-dev
rj has quit [Quit: rj]
rj has joined #nixos-dev
rj has quit [Client Quit]
orivej has joined #nixos-dev
supersandro2000 is now known as Guest35175
Guest35175 has quit [Killed (card.freenode.net (Nickname regained by services))]
supersandro2000 has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<jonringer>
jtojnar: if we get most of the builds working, how do you feel about finishing the remaining items on master? I'm assuming most of the remaining items are application or service specific?