<infinisil>
Is the `dbi:Pg:` prefix always the same or can this be something else?
<gchristensen>
abort abort
<infinisil>
Introducing a workaround for a problem that only arises because of another problem isn't really my thing you see :P
<sterni>
infinisil jumping on any excuse to write a parser in nix very relateable
<infinisil>
(workaround being a warning when application_name is set, problem being application_name overriding, another problem being dbi's value not being overridable)
<gchristensen>
I'm just doubtful that such a PR would merge, and I don't want you to invest effort in to a pr that probably won't merge
justanotheruser has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
<infinisil>
I see
supersandro2000 has joined #nixos-dev
<infinisil>
Then I think a warning isn't necessary
<infinisil>
As the use case for this seems very rare, and it only influencing the logs
evanjs has quit [Read error: Connection reset by peer]
<sterni>
puck: I assume ansi escape sequences are filtered to avoid taking over a tty, but bell is a normal ascii character right?
<sterni>
wait some ansi escape sequences are allowed though
<puck>
it's worse than that though
<puck>
the ansi escape filtering in nix is incorrect
<sterni>
oh I see
<puck>
so i think this escape code just borks the filtering
<gchristensen>
whoa the nixos test framework's driver interface got wicked fancy
orivej has quit [Ping timeout: 245 seconds]
<gchristensen>
whoa, has it always started a VNC session per VM?
orivej has joined #nixos-dev
tazjin_ is now known as tazjin
<gchristensen>
interesting: target # qemu-system-x86_64: warning: 9p: degraded performance: a reasonable high msize should be chosen on client/guest side (chosen msize is <= 8192). See https://wiki.qemu.org/Documentation/9psetup#msize for details.
orivej has quit [Ping timeout: 276 seconds]
tetdim has quit [Read error: Connection reset by peer]
p01ar_ has joined #nixos-dev
p01ar has quit [Read error: Connection reset by peer]
<abathur>
anyone have longer-term perspective on how often shellcheck is broken in master? I used shellcheck + resholve in the bashup-events package(s) and the last two times I've gone to update resholve I've had longish waits for eventual via nixpkgs-review just because shellcheck is broken (in turn, I think both were because dependencies of pandoc were broken)
<supersandro2000>
qemu is starting vnc by default IIRC
<supersandro2000>
abathur: pandoc wasn't broken, ghc just wasn't cached and you can't build it on every platform
<supersandro2000>
and I never encountered a shellcheck failure in the last months
<abathur>
ok
<abathur>
I'm getting annoyed with it and am tempted to drop the dep, but I don't want to make a hasty decision if it's just a fluke
<supersandro2000>
let me take a look at shellcheck in master rn
<abathur>
I got a test failure in /nix/store/cmdrdcmnjkyx1i9r28sfy373gwz8v9r4-python3.8-requests-2.25.1.drv
<abathur>
which seems to be in via sphinx
<abathur>
the whole stack is really big, so I'm not super sure about what the whole graph looks like beyond bashup-events > shellcheck > pandoc
<supersandro2000>
You are on current master? I am currently building ShellCheck and requests was probably cached already
<supersandro2000>
also bashup-events44 builds for me
<sterni>
abathur: I'll try to remember to talk to peti usually we try to check these kinds of packages when doing the haskell update to make sure they are not broken
<sterni>
or was it broken by something else unrelated to the haskellPackages update?
<abathur>
it's possible this is also a mac thing, idk
<sterni>
I think we should make a list of important haskellPackages we check every friday
<sterni>
sounds possible
<abathur>
well the actual break I saw was in python38 requests
<sterni>
how does it depend on python38 requests o_O
<abathur>
I think the tree here, without having tried to render it, is something like shellcheck > pandoc > *? > sphinx > *? > requests
<gchristensen>
I'm fighting a NixOS test where in early boot the machine gets an IP in the 10.0.2 range: "initiatorRootTargetName # udhcpc: lease of 10.0.2.15 obtained, lease time 86400" but later on in startup the machine's other interface gets a 192.168.x.x IP address. anyone know where in the test framework the 10.x.x.x is coming from?
<gchristensen>
duh. "The DHCP server assign addresses to the hosts starting from 10.0.2.15."
Jackneill has quit [Ping timeout: 260 seconds]
Jackneill has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
<gchristensen>
I would love to be automatically formatting new bash scripts with shfmt
<rmcgibbo[m]>
abathur: I think the problem with r-rmcgibbo there is that it timed out, and for some reason that wasn't properly detected when making the report (it should tell you that it timed out or even just not comment, rather saying it failed to build)
<abathur>
perhaps because it built the target package and is just failing on other rebuilds?
<rmcgibbo[m]>
It looks like building bashup-events required building a really long chain of other rebuilds.
<abathur>
anyways, I don't think it's particularly the bot's problem; I'm seeing issues like this just running `nixpkgs-review rev HEAD` locally
<rmcgibbo[m]>
So it's not totally surprisingly that it would timeout when it needed to aparently rebuild like 50 drvs
<supersandro2000>
abathur: tell that rmcgibbo not me :)
<abathur>
just telling you because we were discussing it earlier and you guessed it was just ghc not being cached (I'm not sure if this supports or refutes that?)
<rmcgibbo[m]>
Maybe somethings blocked or failing on hydra? It's a bit unexpected that bumping a leaf package would trigger so many rebuilds.
<abathur>
and not telling rmc because I doubt it's actually the bot's fault when I'm seeing similar if not identical results local
<supersandro2000>
it was an accident and now we just wait until it is cached again
<abathur>
oh
<supersandro2000>
setuptools-rust causes a ghc rebuild
<rmcgibbo[m]>
ah already. sounds like you have it figured out. i will try to make the bot be a little bit more informative when it fails due to a timeout.
<rmcgibbo[m]>
sorry, didn't finish my thought. "ah already" was supposed to be "ah, it seems like you already figured out why there were so many rebuilds (ghc/setuptools-rust)".