| 11 Oct 2024 |
 K900 | But nix-daemon reaps build processes after refscanning | 14:41:07 |
| K900 | So you can end up with a zombie process just sitting there for a while | 14:41:18 |
 Linux Hackerman | I just opened https://git.lix.systems/lix-project/lix/issues/544 -- I'll try to make and send a fix this evening. I'm a bit confused about the stack trace though -- I'm building with meson build -C build (having run meson setup build) then running build/src/nix/nix and the stack trace looks pretty much the same (barring file paths). Any ideas why more of the frames can't be resolved into symbols? | 14:47:25 |
| Linux Hackerman | ok, found it without the computer telling me where the exception comes from: https://gerrit.lix.systems/c/lix/+/2057 | 15:25:38 |
 V. 🏳️⚧️ | In reply to @jade_:matrix.org
can either of you please file an issue on lix mentioning this so that someone can find it in the future Done | 15:43:20 |
| V. 🏳️⚧️ | In reply to @kfears:matrix.org
Regarding Flake lockfiles: I think we can solve the long-term issue by taking the same approach as OpenTofu:
https://opentofu.org/docs/intro/whats-new/#override-files-for-opentofu-keeping-compatibility
We can create flake.lix.lock or flake.ice or flake.lixfile or whatever that CppNix will for sure never read, and then we change Lix to read this new lockfile instead. If it doesn't exist, we copy the flake.lock to new lockfile and read the new lockfile. That way, after a few releases, we can remove the fallback behavior and introduce changes to the lockfile format, like having semver versions instead of int versions flake.lick is right there | 16:06:09 |
| K900 | lewd | 16:06:29 |
 KFears (tragedy arc) | Very memorable, though | 16:10:22 |
| KFears (tragedy arc) | One issue: i and o are adjacent on qwerty keyboard | 16:10:39 |
| K900 | The true multiverse brain would be to then rename flakes to flicks | 16:11:41 |
| K900 | So the filename is flick.lick | 16:11:47 |
| K900 | (or, if we really want to mess with people, flick.lock) | 16:12:02 |
| KFears (tragedy arc) | drop.kick | 16:21:12 |
 oli | In reply to@vigress9:matrix.org
flake.lick is right there mmm tasty ice cream | 17:07:37 |
 delroth | 
Download image.png | 17:14:16 |
| KFears (tragedy arc) | Pushed another patchset for lix-installer. I guess the next one is the receipt.json obliteration, finally | 22:01:58 |
| KFears (tragedy arc) | That's gonna be a big one | 22:02:02 |
| KFears (tragedy arc) | Also, re: CI
For MacOS, there's something called "Apple Virtualization Framework", which is vendorlocked to MacOS of course, but it uses Objective-C or Swift to write code. It doesn't look too bad (link), but it appears to be aarch64-only
The better solution seems to be Tart, which already did the heavy lifting and uses this Virtualization Framework under the hood. They have some Packer stuff, but it seems it's just bootstrapping VM images, and it's unusable with plain Packer. So we'll have to use Tart CLI in some scripts or idk. The licensing is fairly nice, it's free for orgs using less than 100 CPU cores which is us | 22:18:09 |
| KFears (tragedy arc) | If Buildbot is anything like Jenkins and can run shell commands on the host, maybe we can run Tart in Buildbot installed on MacOS hardware? lol | 22:20:58 |
| KFears (tragedy arc) | Also Tart is also aarch64-only because it's built on virtualization framework, and there's basically no chance of x86_64 support | 22:21:56 |
 just1602 | I've a CL which tests are failling with the following error: note: build failure may have been caused by lack of free disk space
Is buildbot cleaning up itself or someone need to go in and make some space? :/
| 23:08:59 |
| just1602 | * I've a CL which tests are failling with the following error: note: build failure may have been caused by lack of free disk space
Is buildbot cleaning up itself or someone need to go in and make some space?
| 23:09:14 |
| 12 Oct 2024 |
|  Federico Damián Schonborn changed their profile picture. | 00:31:08 |
 raitobezarius | In reply to @just1602:systemli.org
I've a CL which tests are failling with the following error: note: build failure may have been caused by lack of free disk space
Is buildbot cleaning up itself or someone need to go in and make some space?
normally, GC runs | 10:15:37 |
| raitobezarius |
/dev/sdb1 512G 39G 474G 8% /nix
| 10:15:55 |
| 13 Oct 2024 |
| raitobezarius | https://git.lix.systems/lix-project/buildbot-nix/src/commit/ea08a7f4a17f638c35f3afdbc1600fe99e4c4958/buildbot_nix/init.py#L903 this is it | 16:47:23 |
| raitobezarius | expected builder check was always failing | 16:47:33 |
| raitobezarius | because build properties values are (value, source) | 16:47:45 |
| raitobezarius | ffs | 16:47:46 |
| raitobezarius | i'm finishing tests and if it's good, I may switch Lix to it soonish | 16:48:20 |
