| 19 Aug 2025 |
 emily | pretty sure there's at least one browser in the reverse closure | 19:25:14 |
| emily | (and out-of-tree users) | 19:25:17 |
 Grimmauld (any/all) | nope, not in pyside: https://github.com/NixOS/nixpkgs/pull/435067#issuecomment-3201937350 | 19:28:51 |
| Grimmauld (any/all) | can't check rcu (paywalled), but i don't expect it there | 19:29:16 |
| Grimmauld (any/all) | and the pyside tools doesn't matter | 19:29:24 |
| Grimmauld (any/all) | the res is all a nope | 19:29:30 |
| Grimmauld (any/all) | * the rest is all a nope | 19:29:36 |
| emily | fair enough, it's the other Python binding stuff that has browsers then | 19:29:48 |
| emily | e.g. qutebrowser | 19:29:49 |
| emily | we can maybe just drop it from PySide then yes | 19:29:54 |
| Grimmauld (any/all) | not sure i agree. Our backport rules say we can backport security-critical patches even if they are technically breaking? I feel this qualifies | 19:31:00 |
| emily | it actually kinda doesn't | 19:31:44 |
| emily | though we usually interpret it to say so | 19:31:48 |
| emily | https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases | 19:31:51 |
| Grimmauld (any/all) | thing is, either the webengine vuln mark is a "break", or the removalof webengine is a "break". Both is technically breaks, and in that case i think we should read the guide in a way that prefers user safety. Which means accepting the potential breaks. | 19:35:16 |
| Grimmauld (any/all) | * thing is, either the webengine vuln mark is a "break", or the removalof webengine is a "break". Both is technically breaks, and in that case i think we should read the guide in a way that prefers user safety. Which means accepting the potential breaks from removing webengine. | 19:35:23 |
| emily | knownVulnerabilities isn't considered a breaking change | 19:37:53 |
| emily | not being a breaking change is kinda its whole point | 19:38:13 |
| Grimmauld (any/all) | hm... | 19:38:34 |
| Grimmauld (any/all) | so you still prefer an explicit .override{ withWebengine = false; } in all users of pyside? | 19:39:25 |
| emily | mostly agnostic on that front. the Python package set isn't super external-consumption-oriented anyway | 19:40:52 |
| Grimmauld (any/all) | so you want the default false only on supercollider? | 19:42:37 |
| Grimmauld (any/all) | i mean i can do that, but i want to understand why before i do | 19:43:10 |
| emily | I'm confused now | 19:43:56 |
| Grimmauld (any/all) | i am too | 19:45:46 |
| Grimmauld (any/all) | there is:
- pyside, where our internal users don't need webengine (and our py packages are not meant for external use)
- subsurface, where our version does not need webengine at all
- supercollider, where webengine is optional
Now what default should those have, and how aggressive can we backport the webengine-less defaults?
| 19:47:54 |
| Grimmauld (any/all) | i'd like to just remove the webengine from stuff and backport all of it, but not sure we can. | 19:51:15 |
| emily | subsurface is definitely backportable | 20:14:11 |
| emily | supercollider we could backport a feature flag but I wouldn't flip the default | 20:14:23 |
| emily | csound-qt is probably a similar situation there | 20:14:45 |
