| 13 Sep 2025 |
 raitobezarius | Hm surprising | 21:44:01 |
| 14 Sep 2025 |
 aloisw | Hm maybe the * in the code owners file doesn't work, and on 2.93 where there are no owners it falls back to the core team? | 06:55:38 |
| aloisw | https://github.com/NixOS/nixpkgs/pull/435108#issuecomment-3289131700 did they fix the Ubuntu sandbox breakage on the other side of the fork? | 07:03:46 |
|  Federico Damián Schonborn (he/they) changed their profile picture. | 07:26:43 |
| raitobezarius | by sandbox breakage, are you thinking of the apparmor shaped things? | 12:15:25 |
| aloisw | Yes, precisely. The nix builds succeed per that comment so they must be doing something differently. | 12:37:13 |
 emily | https://github.com/NixOS/nixpkgs/pull/443012 would be good if someone could check my work (haven't verified the build) | 22:08:00 |
| 15 Sep 2025 |
 jade_ | yup. i think we might want to just throw a * into the codeowners of maintenance branches | 06:45:34 |
| aloisw | Well that doesn't seem to work at all per the behaviour observed by Marie. | 07:02:24 |
| jade_ | right, the codeowners plugin is set up in our configuration to fail closed | 07:49:58 |
| jade_ | we need to introduce an OWNERS file on the maintenance branches that just allows anyone with +2 to +2 anything because they're just maintenance branches | 07:50:28 |
| jade_ | i didn't see a CL to put an OWNERS file on release-*, which is probably why it is jacked | 07:51:06 |
| jade_ | or we could also add an exclusion in the config of release-* from codeowners entirely | 07:51:18 |
| jade_ | i think that might be the most simple way | 07:51:27 |
| jade_ | this: https://android-review.googlesource.com/plugins/code-owners/Documentation/setup-guide.html#optOutBranches | 07:52:49 |
| jade_ | let me just Do That | 07:52:52 |
| jade_ | and then go to bed | 07:52:54 |
| jade_ | okay, that configuration has been yote | 07:57:50 |
| jade_ | codeowners should no longer hassle you on release branches | 07:58:05 |
| aloisw | In reply to @jade_:matrix.org
right, the codeowners plugin is set up in our configuration to fail closed That's not the entire problem as I understood it. Main branch has * as owners for meson.build but Marie didn't get any owners shown there. | 14:39:06 |
| emily | fyi lixStatic has linking issues on Darwin
Undefined symbols for architecture arm64:
"_libiconv", referenced from:
_psl_str_to_utf8lower in libpsl.a(libpsl_la-psl.o)
_mem_cd_iconveh_internal in libunistring.a(libunistring_la-striconveh.o)
(maybe you meant: __libiconv_version)
"_libiconv_close", referenced from:
_psl_str_to_utf8lower in libpsl.a(libpsl_la-psl.o)
_libunistring_iconveh_open in libunistring.a(libunistring_la-striconveh.o)
_libunistring_iconveh_close in libunistring.a(libunistring_la-striconveh.o)
"_libiconv_open", referenced from:
_psl_str_to_utf8lower in libpsl.a(libpsl_la-psl.o)
_libunistring_iconveh_open in libunistring.a(libunistring_la-striconveh.o)
ld: symbol(s) not found for architecture arm64
not sure whether a Meson problem or a pkg-config files omitting -liconv on static problem
| 16:00:23 |
|  laurents joined the room. | 16:05:59 |
 Qyriad | I thought stdenv automatically handled iconv now…? | 16:15:00 |
| Qyriad | hmm | 16:15:02 |
| raitobezarius | I remember aloisw knew things about this, but I'm so out of my depth on this topic | 16:17:23 |
| laurents | Hello! I am packaging a service for nixos, and I just hit https://git.lix.systems/lix-project/lix/issues/970 which completely prevents me from moving forward. (short of spending weeks trying to convince the upstream team to get rid of submodules) So I thought I'd try to fix that bug in lix. I write code for a living, but not C/C++, and I'm far from being a nix guru. Any thoughts on how unconscious it is of me to want to tackle it? | 16:17:56 |
| Qyriad | if no one has figured it out by Friday make an issue and assign it to usyo | 16:18:05 |
| Qyriad | In reply to @laurents:fsfe.org
Hello! I am packaging a service for nixos, and I just hit https://git.lix.systems/lix-project/lix/issues/970 which completely prevents me from moving forward. (short of spending weeks trying to convince the upstream team to get rid of submodules) So I thought I'd try to fix that bug in lix. I write code for a living, but not C/C++, and I'm far from being a nix guru. Any thoughts on how unconscious it is of me to want to tackle it? wait, why do you need self submodules for an upstream repo? | 16:19:14 |
| raitobezarius | I suppose it's an upstream repo that contains a flake.nix which use self submodules implicitly | 16:20:14 |
| Qyriad | I'd probably see if you can just consume the upstream repo with flake = false | 16:21:29 |
