| 30 Nov 2024 |
 p14 | Off topic: I enabled ipv6 to prove that this brings the builds into alignment (which it does), and immediately firefox is now hanging with 'firefox is not responding, force quit?', immediately making me remember why I had ipv6 disabled in the first place :( | 12:11:14 |
 atemu12 | Uh, huh, check whether your network's IPv6 configuration is actually correct. I once had a rogue WAP announcing a prefix for instance which caused massive issues (though not FF hanging O.o) | 12:38:30 |
| atemu12 | I wonder how a program in the sandbox would even know that IPv6 is disabled | 12:38:49 |
| atemu12 | How did you disable that? | 12:38:52 |
| p14 | Kernel command line ipv6.disable=1 | 12:39:03 |
 raboof | In reply to @atemu12:matrix.org
I wonder how a program in the sandbox would even know that IPv6 is disabled configure.sh does if (socket(AF_INET6, SOCK_STREAM, 0) < 0) | 12:39:58 |
| p14 | I don't know for sure that firefox hanging relates to ipv6 being enabled but it is suspicious since I've not otherwise observed that, and it happened pretty quickly after enabling it. But that's also my experience of ipv6 being enabled: random stuff stops working properly in tricky to diagnose ways | 12:40:16 |
| atemu12 | p14: Do you also get super slow page loading times? | 12:40:45 |
| raboof | definitely a good idea to ask upstream. for nixpkgs we definitely want to build with ipv6 support even if the build machine doesn't have it enabled, so we might want to add --enable-ipv6 in the mean time? | 12:41:01 |
| p14 | And I have a good technical ISP who provides good ipv6 support, but I have it disabled at the router. | 12:41:02 |
| p14 | In reply to @raboof:matrix.org
definitely a good idea to ask upstream. for nixpkgs we definitely want to build with ipv6 support even if the build machine doesn't have it enabled, so we might want to add --enable-ipv6 in the mean time? I've not dug into the build script but would it still do the config test? | 12:41:30 |
| raboof | https://github.com/RsyncProject/rsync/blob/master/configure.ac#L379-L407 I'm not too good with automake, not sure | 12:44:00 |
| p14 | In reply to @raboof:matrix.org
https://github.com/RsyncProject/rsync/blob/master/configure.ac#L379-L407 I'm not too good with automake, not sure Tested it here, it looks like enabling it does skip the test. | 12:47:31 |
| p14 | And confirmed that it produces the same executable as output. | 12:50:34 |
| p14 | Is enabling ipv6 in rsync a change to target staging, or master? | 12:51:05 |
| raboof | depends on the number of rebuilds, I'd target master and wait for ofborg to tell you | 12:52:56 |
| p14 | Fix: https://github.com/NixOS/nixpkgs/pull/360414
I'll leave it as draft until the checkers are happy. | 12:58:38 |
| raboof | ofborg confirms it should target staging :) | 14:05:07 |
|  @midirhee12:tchncs.de joined the room. | 18:58:04 |
| @midirhee12:tchncs.de left the room. | 18:59:41 |
| 1 Dec 2024 |
|  shawn8901 left the room. | 00:08:09 |
| shawn8901 joined the room. | 00:11:07 |
| 2 Dec 2024 |
|  dish [Fox/It/She] changed their profile picture. | 19:59:07 |
| 3 Dec 2024 |
|  femsci joined the room. | 05:01:10 |
|  @statecode47:unredacted.org joined the room. | 15:40:54 |
| @statecode47:unredacted.org | Does anyone here know how to remove the signature from ARM64 Linux kernel images so that two kernel images (official and reproduced) can be compared by diffoscope without the signatures differing?
Sad that I can't find anything regarding removing signatures from ARM64 Linux kernel images, and they are probably nothing like the x86_64 Linux kernel EFI images. I am not familiar with ARM64 Linux kernels at all.
Its file type is Linux kernel ARM64 boot executable Image, little-endian, 4K pages.
| 15:42:10 |
 Moritz Sanft | Module signatures, or which signatures do these have exactly? | 15:43:18 |
| @statecode47:unredacted.org | In reply to @msanft:matrix.org
Module signatures, or which signatures do these have exactly? For the *.ko modules, I successfully removed their signatures with strip, since the modules are simply ELF.
But the ARM64 kernel boot Image itself is more challenging and I really don't know how to remove the signatures before being able to compare the images.
| 15:45:53 |
| Moritz Sanft | In reply to@statecode47:unredacted.org
For the *.ko modules, I successfully removed their signatures with strip, since the modules are simply ELF.
But the ARM64 kernel boot Image itself is more challenging and I really don't know how to remove the signatures before being able to compare the images.
You can also specify CONFIG_MODULE_SIG=n for that | 15:46:31 |
| Moritz Sanft | You can also specify CONFIG_MODULE_SIG=n for that. As for ARM-specific signatures, I'm unaware. | 15:46:56 |
