| 23 Nov 2024 |
 emily | ideally it'd use an old FFmpeg too | 04:50:33 |
 Tomodachi94 (they/them) | And maybe vendor Ant | 04:50:45 |
| emily | and be broken on Darwin because of bad Linux assumptions | 04:50:47 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
And maybe vendor Ant I'm wondering how many packages think they use our Ant package but actually use an Ant JAR that was shoved into VCS | 04:51:34 |
| Tomodachi94 (they/them) | nix-index time! :3 | 04:51:45 |
| Tomodachi94 (they/them) | Quite a few include Ant in their $out, which is... probably not good if it's just for the build system | 04:54:53 |
| Tomodachi94 (they/them) | (nix run 'github:nix-community/nix-index-database -- --regex '(lib|share)/.ant(-.|)jar$' | wc -l` says 407 paths) | 04:57:49 |
| Tomodachi94 (they/them) | (nix run 'github:nix-community/nix-index-database -- --regex '(lib|share)/.*ant(-.*|)jar$' | wc -l says 407 paths) | 04:57:56 |
| Tomodachi94 (they/them) | (nix run 'github:nix-community/nix-index-database -- --regex '(lib|share)/.*ant(-.*|)\.jar$' | wc -l says 444 paths) | 04:58:38 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
I wonder how feasible it would be to make a script that automates most of the process involved with dropping an insecure package I drop a lot of packages, so I might make something more general at some point. We'll see 🙂) | 05:01:26 |
| Tomodachi94 (they/them) | * (I drop a lot of packages, so I might make something more generally for dropping packages at some point. We'll see 🙂) | 05:01:36 |
| emily | you might want to look at the Gentoo last rites stuff | 05:02:27 |
| emily | I think they have automation | 05:02:29 |
| emily | I feel I've corrupted you into the package-dropping life, though. | 05:02:48 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
I feel I've corrupted you into the package-dropping life, though. Nope, I have a history of dropping things that goes before I joined this channel: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+author%3Atomodachi94+drop&type=commits&s=committer-date&o=asc | 05:04:48 |
| Tomodachi94 (they/them) | I... did this to myself | 05:06:31 |
| Tomodachi94 (they/them) | Being a founding member of the Java team certainly didn't help | 05:06:50 |
| emily | :'( | 05:06:52 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
(I drop a lot of packages, so I might make something more generally for dropping packages at some point. We'll see 🙂) I have a prototype for closing issues based on a human feedback loop. I'll post future updates elsewhere | 06:26:54 |
|  Kamilla 'ova joined the room. | 13:19:03 |
| Tomodachi94 (they/them) | Does anyone know how this would affect refactoring the Maven build story to use hooks? https://github.com/NixOS/nixpkgs/pull/313152 | 18:13:07 |
| Tomodachi94 (they/them) | I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them after a Maven update is merged | 18:22:45 |
| Tomodachi94 (they/them) | (Probably would be easiest once the Maven build story uses hooks) | 18:23:17 |
| Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them one-by-one after a Maven update is merged | 18:23:37 |
| Tomodachi94 (they/them) | We would absolutely need to script those updates though | 18:24:41 |
| Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml but not pinned, updating them one-by-one after a Maven update is merged | 18:26:16 |
 Morgan (@numinit) | I've gotta figure out a way to automatically build gradle.lock with gradle2nix and the sandbox off | 18:33:24 |
| Morgan (@numinit) | Since gradle feels the need to resolve dependencies lazily, you basically need to run the build before you can run the build 😩 | 18:34:29 |
| Tomodachi94 (they/them) | (Everything would be so much simpler if these build systems just used proper lockfiles 💔) | 18:35:14 |
| Morgan (@numinit) | I tried gradle's lock format and it wasn't proper by any extent, lol. No hashes, no URLs | 18:35:37 |
