| 16 Jan 2024 |
 samueldr | did you offer just an eval or is there a build following on? | 03:53:44 |
 raitobezarius | it was just a nix-eval-jobs :P | 03:53:56 |
| samueldr | (no worries either way) | 03:54:00 |
| raitobezarius | dispatching them to the builder would be kinda annoying tbh | 03:54:09 |
| raitobezarius | I'd need to push the curses and I'm not confident they would carry onto the build | 03:54:18 |
| raitobezarius | (because hydra will have a different way of doing the evaluation) | 03:54:29 |
| raitobezarius | don't hesitate to poke me later if you need stuff | 03:55:36 |
|  jshcmpbll joined the room. | 07:18:48 |
| 17 Jan 2024 |
| samueldr | I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns of that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenvwtih whatever workarounds that implies using | 21:17:41 |
| samueldr | * I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns of that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenv with whatever workarounds that implies using | 21:17:52 |
| samueldr | is there anything in there that sounds incorrect? | 21:18:25 |
| samueldr | * I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns off that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenv with whatever workarounds that implies using | 21:20:26 |
| 25 Jan 2024 |
|  @axolotl:the-apothecary.club joined the room. | 05:52:37 |
| 27 Jan 2024 |
|  Jack changed their display name from Jack to Jackoe. | 01:59:36 |
|  @lehmanator:gnulinux.club removed their profile picture. | 16:53:48 |
| @lehmanator:gnulinux.club removed their display name Sam Lehman. | 16:59:53 |
| @lehmanator:gnulinux.club left the room. | 17:03:37 |
| 29 Jan 2024 |
|  Sam Lehman joined the room. | 11:00:10 |
| Sam Lehman set a profile picture. | 11:06:01 |
| 30 Jan 2024 |
|  @erremilia:matrix.org left the room. | 19:55:32 |
| 31 Jan 2024 |
|  @federicodschonborn:matrix.org changed their profile picture. | 03:36:44 |
| @federicodschonborn:matrix.org changed their profile picture. | 06:22:20 |
| 2 Feb 2024 |
 p14 | is gettext meant to have bash in its buildInputs? (Should it not be a nativeBuildInput?) Under pkgsStatic, it gets propagated. So if you do something like nix build --dry-run nixpkgs#pkgsStatic.gettext, it fetches bash-dev, because under cross, the buildInput becomes a propagatedBuildInput for some reason. I noticed because I was puzzled that bash ended up as a dependency. | 19:38:40 |
 Alyssa Ross | Yes, because it installs bash scripts that need to have their shebang patched. | 19:45:32 |
| Alyssa Ross | IIRC | 19:46:16 |
| p14 | Nothing crossOverlays = [(self: super: { gettext = super.gettext.override { bash = super.buildPackages.bash; }; })]; can't fix I suppose... 🤫 | 19:50:51 |
| 3 Feb 2024 |
|  Tanja (Old; I'm now @tanja:catgirl.cloud) joined the room. | 02:52:59 |
|  @networkexception:chat.upi.li changed their profile picture. | 11:49:19 |
| 6 Feb 2024 |
 rhelmot | Not particularly exotic but - somehow while messing with nixpkgs for FreeBSD I broke llvm tests on Linux. The failing test case seems to complain about the dot executable not being in the path? I can’t find any evidence of this having ever been a dependency or a disabled test, so what could have gone wrong? | 02:40:11 |
| rhelmot | The change that broke it had nothing to do with llvm - I changed a var that should be a no-op on Linux for bison | 02:41:42 |
