| 10 Dec 2022 |
 Artturin | removed 2 of my comments | 02:41:20 |
| Artturin | and unresolved some reviews | 02:41:37 |
| Artturin | and is sending ofborg bad data...
ofborg-eval — Commit not found
| 02:41:56 |
| Artturin | its back now :| | 02:47:42 |
| Artturin | * they're back now :| | 02:47:49 |
 Sandro 🐧 | In reply to @artturin:matrix.org
get email notifications of my comment that contains Rendered yes | 17:30:46 |
| 11 Dec 2022 |
| Artturin | https://github.com/NixOS/nixpkgs/pull/205623 | 11:07:21 |
| 16 Dec 2022 |
 @trofi:matrix.org | A PR for new linuxHeaders-6.1: https://github.com/NixOS/nixpkgs/pull/205851 | 22:15:43 |
| 17 Dec 2022 |
| @trofi:matrix.org | Looks like config.enableParallelBuildingByDefault = true did not actually work: https://github.com/NixOS/nixpkgs/pull/206623 | 22:25:18 |
| 20 Dec 2022 |
|  Pascal joined the room. | 00:26:25 |
| 23 Dec 2022 |
|  luxus joined the room. | 07:01:18 |
| 1 Jan 2023 |
| @trofi:matrix.org | Signal-boosting https://github.com/NixOS/nixpkgs/pull/208478 where I try to collect some details on how bootstrap works today (to tweak it slightly later). | 20:53:53 |
| 2 Jan 2023 |
| @trofi:matrix.org | John Ericson: ^ pinging you here specifically in case you don't look at github review queue :) (do you BTW?) | 17:52:09 |
 John Ericson | trofi thanks! | 22:33:00 |
| John Ericson | yes github notifications are lot | 22:33:06 |
| @trofi:matrix.org | Thank you! I'll get back to you soon with a few more bootstrap tweaks. | 23:53:29 |
| 4 Jan 2023 |
| @trofi:matrix.org | Signal-boosting another potentially disruptive bootstrap tweak: https://github.com/NixOS/nixpkgs/pull/209063
This is an addition of extra gcc build during bootstrap to avoid shipping stale libgcc_so.1. It also happens to build glibc with nixpkgs's gcc (as opposed to previous bootstrapTools gcc).
| 19:09:28 |
| 6 Jan 2023 |
| Artturin | https://github.com/NixOS/nixpkgs/pull/209255 | 01:04:54 |
| @trofi:matrix.org | Just curious: does it fix any real packages or you found it while chasing some other problem? | 05:56:15 |
| Artturin | In reply to @trofi:matrix.org
Just curious: does it fix any real packages or you found it while chasing some other problem? I was looking through the issues and saw https://github.com/NixOS/nixpkgs/issues/208625 and thought it would be better to not fail from the make command | 12:48:38 |
| Artturin | This also makes installPhase consistent with buildPhase if there's no makefile | 12:49:13 |
| @trofi:matrix.org | Aha, makes sense. | 12:52:02 |
 Winter (she/her) | I always found that inconsistency a bit weird. A welcome change IMO. | 14:38:41 |
| 7 Jan 2023 |
| Artturin | https://github.com/NixOS/nixpkgs/pull/144747 | 04:18:21 |
| @trofi:matrix.org | John Ericson: WDYT of https://github.com/NixOS/nixpkgs/pull/209063 ? :) If all of it is too scary I have a few well-isolated changes that should be good to go regardless (all are included in the final PR as well):
- https://github.com/NixOS/nixpkgs/pull/209054
- https://github.com/NixOS/nixpkgs/pull/209055
- https://github.com/NixOS/nixpkgs/pull/209153
| 09:46:01 |
 @vcunat | I don't know. If it's significantly less controversial, we could just upgrade gcc version in aarch64-linux bootstrap tools (say, to 11 or 12). To get around the worst effects for now, probably even for years. (Though I'm not sure about practical availability of the very few people with permissions to upload tarballs; IIRC sometimes it took weeks or more.)
There's quite a general dilemma, too. Having shorter and simpler bootstrap process makes it easier to deal with any stdenv-changing stuff. So we could rotate bootstrap tools faster instead, e.g. yearly - at least for the two main Linux platforms. Some people would instead prefer to have much smaller and basically fixed bootstrap tools (GuixSD does that IIRC). | 10:26:49 |
| @vcunat | * I don't know. If it's significantly less controversial, we could just upgrade gcc version in aarch64-linux bootstrap tools (say, to 11 or 12). To get around the worst effects for now, probably even for years. (Though I'm not sure about practical availability of the very few people with permissions to upload tarballs; IIRC sometimes it took weeks or more.)
There's quite a general dilemma, too. Having shorter and simpler bootstrap process makes it easier to deal with any stdenv-changing stuff. So we could rotate bootstrap tools faster instead, e.g. yearly - at least for the two main Linux platforms. Some people would instead prefer to have much smaller and basically fixed bootstrap tools (GuixSD does that IIRC), even though that makes bootstrapping harder. | 10:27:55 |
| @trofi:matrix.org | Heh, Yeah. Looking at a change history of gcc/libgcc it looks like unwinder and new primitives get added all the time: https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libgcc;hb=HEAD. It depends so much on the rest of the ecosystem: new CPUs, new C types (like float decimals, int128/256), atomics against them. Could be lucky not to break for years, or could get new symbols in veery single release. | 11:06:37 |
| @trofi:matrix.org | WRT bootstrap defined as a sequence of stdenv/pkgs instantiations it feels like recursive definition does not encourage you to keep it lean. If somebody remembers to check if bootstrap got 10 new packages due to fresh automake in coreutils then lucky them. Otherwise it silently gets expanded with a bunch of seemingly auxiliary things. | 11:09:07 |
| 8 Jan 2023 |
| @trofi:matrix.org | * Heh, Yeah. Looking at a change history of gcc/libgcc it looks like unwinder and new primitives get added all the time: https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libgcc;hb=HEAD. It depends so much on the rest of the ecosystem: new CPUs, new C types (like float decimals, int128/256), atomics against them. Could be lucky not to break for years, or could get new symbols in every single release. | 11:50:33 |
