| 8 Dec 2025 |
 Aijokey | waiting for lock on '/nix/store/v1flrsxkmbb3darbh3qassma3if4yn83-app.cash.sqldelight.gradle.plugin-2.1.0.pom'...
waiting for lock on '/nix/store/7m50sgfypkh0as0b5r1d89nnwpcykdq2-app.cash.licensee.gradle.plugin-1.13.0.pom'...
| 14:56:27 |
| Aijokey | I have lock that not fixing by reloading | 14:56:47 |
 raitobezarius | ah so you have a lock that stuck | 14:57:03 |
| raitobezarius | https://wiki.lix.systems/books/lix-users/page/debugging-a-stuck-lix-invocation use step 5 to determine who is holding the lock, then kill the holder, then resume | 14:57:39 |
| Aijokey | Unstuck | 14:57:40 |
| Aijokey | 100 974 100 974 0 0 7395 0 --:--:-- --:--:-- --:--:-- 7378
waiting for lock on '/nix/store/v1flrsxkmbb3darbh3qassma3if4yn83-app.cash.sqldelight.gradle.plugin-2.1.0.pom'...
waiting for lock on '/nix/store/7m50sgfypkh0as0b5r1d89nnwpcykdq2-app.cash.licensee.gradle.plugin-1.13.0.pom'...
error: opening directory '/nix/store/lhczw64kd1l2w1832ncgll6b4by5zd65-oss-parent-34.pom': Too many open files
Command 'nix-build '<nixpkgs/nixos>' --attr config.system.build.toplevel --no-out-link' returned non-zero exit status 1.
| 14:57:42 |
| raitobezarius | i'm trying to see if i can reproduce this | 14:58:32 |
| raitobezarius | you are manipulating two channels in your system at the same time hm | 14:58:53 |
| Aijokey | always stable and unstable | 14:59:24 |
| raitobezarius | I have to step out for 30 minutes or so | 15:01:23 |
| raitobezarius | It seems you have Java applications, what happens if you comment them and rebuild? | 15:01:46 |
| Aijokey | and it helps | 15:38:10 |
| Aijokey | but also i found out something using kotlin and some android tools during building, even after I comment all android/jave pkgs | 15:39:18 |
| raitobezarius | In reply to @aijokey:matrix.org
but also i found out something using kotlin and some android tools during building, even after I comment all android/jave pkgs What is the something? | 15:42:20 |
 crop | https://git.lix.systems/lix-project/lix/issues/1069 | 15:42:24 |
| Aijokey | I dont know | 15:42:35 |
| Aijokey | maven? | 15:42:58 |
| Aijokey | But it also just dependencie not in my config | 15:43:44 |
 goldstein | (feel free to redirect me to the dev channel if it’s more appropriate there)
hi! I’ve found a divergence in behaviour between Lix and CppNix. when using fetchTree with git flakeref + ?ref=refs/tags/something, Lix and CppNix set the resulting .rev differently: Lix sets it to the hash of the tag itself, while CppNix sets it to the hash of the commit behind the tag. on the first glance, CppNix behaviour seems more sensible to me, since rev is usually the commit hash, but I’d like to know if it’s intentional. if it’s not, I’ll try to fix it. | 17:00:28 |
 Rutile (Commentator2.0) feel free to ping | this is known: https://git.lix.systems/lix-project/lix/issues/520 | 17:07:19 |
| goldstein | thanks for the link! | 17:07:45 |
| Rutile (Commentator2.0) feel free to ping | you're welcome ^^ | 17:07:54 |
| goldstein | not sure if it’s the same issue though? this talks about representing locked inputs via ref vs. rev. I’m talking about getting different rev’s from fetchTree. | 17:09:42 |
| goldstein | I’ll try to make an example | 17:09:48 |
| Rutile (Commentator2.0) feel free to ping | oh | 17:10:02 |
| goldstein | e.g.
Lix 2.95.0-pre20251128-dev_d5d03cd
Type :? for help.
nix-repl> (builtins.fetchTree { type = "git"; url = "https://codeberg.org/golds
tein/nix-tag-fetch-demo"; ref = "refs/tags/tag"; }).rev
"047e5dffbba66b5eb0c1d8db04f661997fb825af"
vs
Nix 2.31.2
Type :? for help.
nix-repl> (builtins.fetchTree { type = "git"; url = "https://codeberg.org/goldstein/nix-tag-fetch-demo";; ref = "refs/tags/tag"; }).rev
"7e6de55d9af75b3647c91f7e939107fcb3c8f196"
| 17:12:22 |
| goldstein | 047... is the hash of the tag object, 7e6... is the hash of the tagged commit | 17:18:36 |
 KFears (burnt out) | AFAIK flake lockfiles and fetchTree are basically the same thing and the same codepath, so this might very well be the same issue | 17:33:40 |
 aloisw | In the linked issue, it's rev/ref though, not different hashes. | 17:34:54 |
| goldstein | I’m not sure I follow. it is the same codepath, but the divergences seem different: the linked issue is whether Lix chooses to emit ref or rev, while my example is which rev gets returned | 17:35:00 |
