| 20 Apr 2022 |
 Linux Hackerman | I think you typoed C89 | 15:55:39 |
 hexa | might as well do it in PHP then | 15:56:31 |
|  rh joined the room. | 19:00:08 |
| 21 Apr 2022 |
|  An exploring bot joined the room. | 00:49:36 |
| An exploring bot left the room. | 00:49:37 |
 Vladimír Čunát | Perhaps worth considering to drop i686 ISO from the channel since 22.05? It's not the first time when some dependency got broken and people tend to be reluctant about fixing i686 builds. https://github.com/NixOS/nixpkgs/pull/169281#issuecomment-1104468198 | 04:30:28 |
 tomberek | Some unstable floating point calculation?
The difference between step.newTokenBucketRate and retryTokenBucket.T_GetFillRate() is 0.0019530492986188364, which exceeds EPSILON, where
step.newTokenBucketRate evaluates to 3.452226,
retryTokenBucket.T_GetFillRate() evaluates to 3.4502729507013812, and
EPSILON evaluates to 9.9999999999999995e-07.
i'm hesitant to drop i686 because of a failing test like this
| 05:18:12 |
 Mic92 (Old) | Do we know how many users this target has? | 06:10:53 |
| Mic92 (Old) | I would expect that even arm64 exceed this by far. | 06:11:08 |
| Mic92 (Old) | Does anyone know anyone? | 06:11:22 |
|  arno joined the room. | 06:59:00 |
| 22 Apr 2022 |
| Vladimír Čunát | Maybe CDN could have stats on the i686 ISO downloads? | 06:41:02 |
|  Linux Hackerman is moving: @linus:schreibt.jetzt changed their display name from Linux Hackerman to Linux Hackerman is moving: @linus:schreibt.jetzt. | 07:37:30 |
| Vladimír Čunát | Locally I was getting errors earlier during the build, as some of the compiler/linker steps apparently shot over the 4G RAM. Maybe higher --cores or $(nproc) was causing it. | 08:08:33 |
| Linux Hackerman is moving: @linus:schreibt.jetzt left the room. | 07:40:10 |
| Vladimír Čunát | * Locally I was getting errors earlier during the build, as some of the compiler/linker steps apparently shot over the 4G memory limit. Maybe higher --cores or $(nproc) was causing it. | 08:08:49 |
| Vladimír Čunát | * Locally I was getting errors earlier during the build, as some of the compiler/linker steps apparently shot over 32-bit memory limits. Maybe higher --cores or $(nproc) was causing it. | 08:09:09 |
| Vladimír Čunát | Otherwise I'd have just disabled the test(s) on i686. | 08:09:59 |
 Artturin | In reply to @mic92:nixos.dev
Do we know how many users this target has? We could make a gh issue and Pin it | 11:43:38 |
| 23 Apr 2022 |
|  Amit Levy joined the room. | 03:05:44 |
| Vladimír Čunát | So I hacked around it for now (by platform-specific downgrade), and thus it's perhaps easy to keep it for 22.05, but it might be worth considering to drop after forking off (and thus for > 22.05). | 10:53:22 |
| Vladimír Čunát | BTW, having nixos.tests.zfs.installer.i686-linux in channel-blocking set seems really absurd. | 10:55:58 |
| 25 Apr 2022 |
| Mic92 (Old) | Agreed. zfs is not really suited for 32-bit let alone legacy x86 | 07:16:57 |
| 26 Apr 2022 |
| Artturin | Relevant to the release https://github.com/NixOS/nixpkgs/issues/170465 | 23:45:50 |
| 29 Apr 2022 |
|  lovek323 joined the room. | 01:09:17 |
| 30 Apr 2022 |
 cdepillabout | I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump purescript to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. | 04:19:10 |
| cdepillabout | * I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump the top-level purescript attribute to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. | 04:31:36 |
| Vladimír Čunát | In reply to @cdepillabout:matrix.org
I have a question about the release process of 22.05. If I maintain a relatively leaf package (in this case, the PureScript compiler), and a new major version has just been released, am I currently allowed to bump the top-level purescript attribute to the new version in Nixpkgs? From https://github.com/NixOS/nixpkgs/issues/165792, it looks like there are various periods where breaking changes are not allowed, but I wasn't sure which part of this process refers to the leaf packages that have few dependencies. I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. | 06:14:39 |
| cdepillabout | In reply to @vcunat:matrix.org
I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. Ah, thanks. In the Branches Affected column, only staging and staging-next are listed, so I thought that maybe that's only for the "large" changes that affect many packages. | 06:41:09 |
| cdepillabout | In reply to @vcunat:matrix.org
I believe that's the "Restrict all breaking changes" (except desktop managers) tomorrow. After that you could add a new version without switching the default. * Ah, thanks. In the Branches Affected column, only staging and staging-next are listed for "Restrict all breaking changes", so I thought that maybe that's only for the "large" changes that affect many packages. | 06:41:41 |
