| 24 Oct 2025 |
|  ⛧-440729 [sophie raven] (it/its) changed their display name from ⛧-440729 [sophie] (it/its) to ⛧-440729 [sophie raven] (it/its). | 06:21:19 |
|  Daniel Fahey joined the room. | 11:59:13 |
| 27 Oct 2025 |
 emily | TIL Hydra downloads and presumably partially seeds a Sintel torrent on every channel bump | 16:27:48 |
 vcunat | I'm not sure that it's a good thing to test all the time. Shown e.g. here:
https://hydra.nixos.org/eval/1819642?filter=fetchtorrent | 17:07:22 |
 hexa (signing key rotation when) |
This unfortunately increases the closure size of the tests: Sintel is
124MB, compared to 54MB for the Wired CD. This was the smallest torrent
I could find that both had a free license and was sufficiently well
seeded to be useful for testing.
| 17:15:55 |
| hexa (signing key rotation when) | https://github.com/NixOS/nixpkgs/pull/432091 | 17:17:00 |
| emily | haha, it was Warez before? | 17:17:25 |
| emily | I'm having to fix it because of dropping Transmission 3 breaking it. or well, "having to", I could just mark it broken. | 17:17:42 |
| emily | I was surprised Hydra is running it. | 17:17:48 |
| vcunat | Ah, so we end up with thousands copies of Sintel video in the S3. | 17:18:00 |
| emily | but I suppose it's not really any different from fetchurls, mostly. I expect it can't actually receive connections through the firewall. | 17:18:06 |
| emily | probably a tiny contributor to cache growth compared to ISOs etc. in fairness 🙃 | 17:18:30 |
| hexa (signing key rotation when) | we didn't build this on hydra before, it if it was marked unfree | 17:19:04 |
| hexa (signing key rotation when) | we started building this once it was changed to sintel | 17:19:17 |
| hexa (signing key rotation when) | so more likely just hundreds of copies 😄 | 17:19:31 |
| vcunat | So far. | 17:19:41 |
| emily | another consideration is that with Transmission 4 it starts logging things like
source-salted-fym81xbq7b5j> [2025-10-27 17:23:14.340] Sintel: [66.56.81.6]:32243 [qBittorrent 5.1.0]: got unrequested piece 364:49152->16384
| 17:28:37 |
| emily | I am not sure what the GDPR implications of temporarily recording the IP addresses of torrent swarm peers in public Hydra logs are | 17:28:57 |
| emily | I'd guess that publicly announcing your IP to serve data to anyone who asks via a tracker means that your IP is no longer personal information | 17:29:22 |
| emily | but I am not a lawyer… | 17:29:29 |
| emily | anyway, if there is a strong feeling about not running these on Hydra I can adjust it in my drop PR | 17:37:02 |
| emily | otherwise I'll leave the status quo | 17:37:05 |
| emily | fwiw, I assume that a postFetch could turn these into zero-byte FODs | 17:37:45 |
| emily | although of course it would still be downloading Sintel like 6 times per platform on every staging-next, just not pushing it to cache | 17:38:04 |
| vcunat | With FOD you have a problem to force rebuilds. | 17:51:56 |
| vcunat | Normally FODs don't get rebuilt. | 17:52:05 |
| vcunat | i.e. it wouldn't be testing anything beyond a single attempt. Not even on stdenv rebuilds, basically never. | 17:52:45 |
 tgerbet | In reply to @emilazy:matrix.org
I'd guess that publicly announcing your IP to serve data to anyone who asks via a tracker means that your IP is no longer personal information Not really you still need explicit consent to process/expose the information.
We have had a case a few years ago in France that ended up at the CJEU. The processing of the IP addresses have been accepted for this specific case but only because it was the only way for rightholders to detect/report infringements.
It might be OK for the Hydra use case but it is likely not something we want to test in court 😅
https://torrentfreak.com/disclosure-of-pirates-identities-compatible-with-eu-privacy-laws-230929/ | 17:57:24 |
| emily | do you need consent to publish google.com's IP? | 17:57:39 |
| emily | it's offered in a public database (DNS) to the general public in order for people to access services from it | 17:57:51 |
