Sender | Message | Time |
---|---|---|
13 Dec 2021 | ||
Do we have a PR in nixpkgs already? | 15:48:44 | |
Doesn't look like it | 15:49:53 | |
We are just using their binary distribution anyway: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/instant-messengers/element/element-web.nix#L16 /o\ | 15:52:53 | |
I'll spent a few minutes on a "proper" source build before just bumping the version and hashsum... | 15:58:26 | |
Only an issue so far https://github.com/NixOS/nixpkgs/issues/150552 | 16:02:16 | |
How does anyone us Nix >=2.4... it is utterly useless. The build logs are silent by default even on the "legacy" (stable) commands... Yesterday it was unable to verify store integrity as it is too strict while doing that and tripped over itself.... Please hold the line while I scream for a second before continuing with the work. | 16:09:49 | |
instead of it streaming me the build log I've to use the nix log thing which doesn't work well with tools that constantly rewrite the same line. 😱 | 16:11:26 | |
there goes the idea of doing a proper source build. | 16:12:55 | |
At least the cinny upgrade was just a npins update cinny for a new source build. | 16:16:49 | |
Deployed a new cinny and element-web version. | 16:23:53 | |
andi-: nix build -L is actually quite nice because it also shows the package that the log line is associated with. | 16:44:40 | |
I think nix build -L should be default because it's better than both nix build and nix-build | 16:45:09 | |
but if I build a single attribute and a single derivation I'd like to be able to see the log like it used to be. | 16:45:14 | |
You can also use it for a single derivation, but often enough even a single derivation can trigger the build of another derivation i.e. fetching source | 16:45:49 | |
And I am no longer willing to open issues on the Nix repo or PRs. It just doesn't have any impact on the development. | 16:45:56 | |
I this one was quite needed: https://github.com/NixOS/nix/pull/5747 | 16:46:53 | |
* I think this one was quite needed: https://github.com/NixOS/nix/pull/5747 | 16:47:45 | |
Yeah but Eelco will either comment that it isn't needed in the new CLI (which is experimental...) or that it doesn't cover enough cases or just merge it in a few weeks without a single comment. | 16:48:20 | |
I also found contributing to nix a bit frustrating, which is why I focused more on building tools around it. | 16:48:24 | |
I rather send messages to the LKML than contribute to Nix. The experience is a ton better. | 16:48:46 | |
The problem is just that the nix upgrades are kind of forced upon us at some point. | 16:49:07 | |
It's a bit hit and miss on LKML as well. | 16:49:15 | |
Oh yeah but at least there is someone to talk to and someone replies. | 16:49:28 | |
My qemu patch was also ignored completyly | 16:49:30 | |
* My qemu patch was also ignored completely | 16:49:44 | |
And having to read all emails in a thread in order to find out what the merge state of a patch is, is also exhausting. | 16:50:53 | |
There are some projects that just suck regardless of platform. I had a terrible experience trying to contribute to GRUB. Only after I pinged a co-worker of one of the maintainers on IRC I received feedback. | 16:50:54 | |
Any idea why patchwork does not show my patch here? https://patchwork.kernel.org/project/qemu-devel/list/?series=&submitter=200979&state=&q=&archive=&delegate= | 16:52:55 | |
subject: hw/i386: fix phys-bits on cpus with AMD SEV/SMD | 16:53:09 | |
https://patchwork.kernel.org/project/qemu-devel/list/?series=&submitter=200979&state=*&q=&archive=both&delegate= | 16:54:28 |