| 26 Mar 2025 |
|  Tanya joined the room. | 17:24:07 |
|  Marie joined the room. | 19:02:19 |
|  nim65s joined the room. | 21:06:03 |
| nim65s changed their display name from Guilhem to nim65s. | 21:06:15 |
| 27 Mar 2025 |
|  jappie joined the room. | 07:35:58 |
|  Simon Hauser joined the room. | 11:07:18 |
 raboof | with the 24.05 release coming up, I'm fairly optimistic that we can have a reproducible minimal installation iso again: there's one fix in flight on staging (https://github.com/NixOS/nixpkgs/pull/384987) and one fix PRed to staging (https://github.com/NixOS/nixpkgs/pull/393724) | 13:39:38 |
| raboof | we used to have the Gnome ISO as our next target, but since recently (https://github.com/NixOS/nixpkgs/pull/355893) we have one 'graphical' ISO with both Gnome and KDE. Nice improvement, but challenge for us 😃. It doesn't look like this added too many issues (https://reproducibility.nixos.social/reports/nixos-graphical-25.05pre56789.gfedcba-x86_64-linux.iso (still populating), https://github.com/orgs/NixOS/projects/30) | 13:42:38 |
| raboof | * with the 25.05 release coming up, I'm fairly optimistic that we can have a reproducible minimal installation iso again: there's one fix in flight on staging (https://github.com/NixOS/nixpkgs/pull/384987) and one fix PRed to staging (https://github.com/NixOS/nixpkgs/pull/393724) | 13:48:42 |
| 28 Mar 2025 |
 tessyjames | Hello, good day everyone. Please am a new contributor and this is my first time on OpenSource. I am investigating arandr package and need guidance.
For context:
After running diffoscope for "arandr" non deterministic build, I noticed the issues is coming from 3 files. All related to manpage generation. The first files holds a record of arandr dist-info and the issue stem from the generation of different hash for two files:
../share/man/man1/arandr.1.gz and ../share/man/man1/unxarandr.1.gz.
This two files also made up the remaining two files that's causing non deterministic build and the issues for both are the generation of different timestamp. For instance:
original file => Thu Mar 27 04:19:55 2025
.check file => Wed Mar 19 12:48:04 2025
The goal here is to generate the .1.gz file without timestamp. While working on kitty (which by the way I didn't succeed as the package was bigger than me), about 50 files was having same manpage timestamp issue which after using SOURCE_DATA_EPOCH led to the generation of .html documentation files which cause non-deterministic build. So it won't work here. Since kitty package had similar issue and this arandr too, I believe resolving this might here reduce files after with non-deterministic build in the packages having issues (my opinion though).
So my research online shows that when compressing file using Gzip, it stores timestamp and other metadata which causes it to generate different hash for the compressed files. Which the RECORD file is facing. I also noticed the use of docutils for document generation which can store timestamp and other metadata during compression.
We need a way to tell the gzip to omit the timestamp. I also read about filename as part of it too. something about mtime=0 and the use of gzip -n. While researching the repo, I found the compression file and this line below supposed to append -n to ensure timestamp is omitted:
''
wrapProgram $out/bin/gzip
--add-flags "''${GZIP_NO_TIMESTAMPS:+-n}"
'';
However, I don't know why it's still generating different timestamp during manpage generation. Please I need guidance because when I tried to do it on my own, I learnt a great lesson.
Thanks everyone | 03:16:25 |
| raboof | Thanks for sharing your learnings so far! Have you identified yet where in the build process the manpages are gzipped? | 05:58:11 |
