| 24 Oct 2025 |
|  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 |
 Vladimír Čunát | 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 |
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 | 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 |
| Vladimír Čunát | 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 | we didn't build this on hydra before, it if it was marked unfree | 17:19:04 |
| hexa | we started building this once it was changed to sintel | 17:19:17 |
| hexa | so more likely just hundreds of copies 😄 | 17:19:31 |
| Vladimír Čunát | 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 |
| Vladimír Čunát | With FOD you have a problem to force rebuilds. | 17:51:56 |
| Vladimír Čunát | Normally FODs don't get rebuilt. | 17:52:05 |
| Vladimír Čunát | 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 |
| emily | someone participating in a public torrent swarm is asking a public database (torrent tracker) to offer their IP to the general public in order for people to access services (downloading chunks / peer exchange / …) from it | 17:58:21 |
