| 28 Oct 2021 |
 moritz.hedtke | Don't think so | 17:59:05 |
| moritz.hedtke | * Don't think so (https://raw.githubusercontent.com/NixOS/nixpkgs/da1f24822928ad74741d41526a2914231500b21d/pkgs/top-level/all-packages.nix) | 17:59:12 |
 das_j | No, it has not | 18:01:41 |
| das_j | I was told (I don't know by who) to wait for the next staging cycle so we can get this merged first without more breakages | 18:02:03 |
| moritz.hedtke | In reply to @janne.hess:helsinki-systems.de
I was told (I don't know by who) to wait for the next staging cycle so we can get this merged first without more breakages I think the reasoning was because the hydra darwin workers are not working well | 18:02:35 |
 Sandro | In reply to @hexa:lossy.network
you mean merge conflicts? yeah. Not sure if this can be done easily | 18:13:08 |
| moritz.hedtke | Fix git :D. Just add a custom merge algorithm that takes generated files into account :D | 18:13:44 |
| Sandro | you can actually do such things in git already but I don't fully know how and it surely does not work on GitHub | 18:17:40 |
 Ryan Burns | In reply to @moritz.hedtke:matrix.org
Fix git :D. Just add a custom merge algorithm that takes generated files into account :D just! | 18:18:56 |
| moritz.hedtke | In reply to @r-burns:matrix.org
just! I think the main problem would be that the ways files are generated in the repository is not clearly specified in a machine-readable form. Otherwise I assume this would be not too hard | 18:20:26 |
| Sandro | the problem is rather which entry wins | 18:21:12 |
| moritz.hedtke | Oh I mostly meant the machine-generated files where you could probably just regenerate. For other conflicts there may be special cases like sets (unordered lists) where you could merge in any way. But I thought about the whole thing and I think it's not super easy with the current model of code. If code would be stored as AST it would be way easier | 18:22:16 |
| Sandro | even if it would be stored as AST we would need to know which files behave like this or that but that is going really OT from staging | 20:32:11 |
| moritz.hedtke | In reply to @sandro:supersandro.de
even if it would be stored as AST we would need to know which files behave like this or that but that is going really OT from staging yes it would need close interaction between the language and the version control but this is really offtopic | 20:32:47 |
| moritz.hedtke | still the regeneration of generated files would probably be feasible and solve some pain-points | 20:33:26 |
| moritz.hedtke | * still the automatic regeneration of generated files would probably be feasible and solve some pain-points | 20:33:34 |
| Sandro | not sure if that would solve more problems than it would create. | 20:38:56 |
| moritz.hedtke | In reply to @sandro:supersandro.de
It would be really grateful if there would be a good way to prevent this things other than keeping track which packages changed on which branch already I'm not knowledgeable with the exact processes but probably you're right and your original point is the best idea. | 20:40:32 |
| Sandro | 🤔 github already has a feature where it shows you which PRs also modify your current file. I think it is broken on nixpkgs for obvious reasons but that for PRs would be nice.
but that is out of reach for us because GitHub would probably need to add new API endpoints for it | 20:45:36 |
| 30 Oct 2021 |
| Ryan Burns | Seems like it would be fairly low-overhead to add a PR action which attempts to locally merge the PR into staging. If the merge would be nontrivial, notify the staging crew. | 01:30:05 |
| Sandro | Or let it fail or something. | 07:47:57 |
| moritz.hedtke | https://github.com/NixOS/nixpkgs/pull/143800 others please also comment I don't want to "decide" this in my own especially as I'm not really knowledgeable in that area. Das_j seems to have thumbsupped so I assume that's agreement but still | 13:18:20 |
|  fabianhjr joined the room. | 15:32:12 |
 hexa | ping darwin maintainers and pray | 19:05:42 |
| 31 Oct 2021 |
| Ryan Burns | Looks like the libdazzle dependency is blocking some user-facing gnome/pantheon applications, but I couldn't reproduce its test failure | 22:39:23 |
| 1 Nov 2021 |
 VladimÃr ÄŒunát | If a test is flaky, it's usually best to just disable it. (or at least make it non-blocking somehow) | 06:51:00 |
| VladimÃr ÄŒunát | That is, assuming that the failures don't indicate some real problem that could affect functionality. | 06:51:47 |
| hexa | sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and resulting socket collisisons | 14:15:29 |
| hexa | * sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and a resulting socket collisisons | 14:15:38 |
| hexa | * sphinx on x86_64-darwin had a transient error due to a lack in network sandboxing and a resulting socket collisison | 14:15:40 |
