| 20 Oct 2024 |
 mj | so I'm looking to maintain/introduce a package to NixOS which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:17 |
| mj | * so I'm looking to maintain/introduce a package to Nix which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:33 |
| mj | * so I'm looking to maintain/introduce a package to nixpkgs which has multiple output binaries. Is it still best practice to write it into pkgs/by-name/*? | 05:11:43 |
| mj | it's a platform | 05:12:54 |
| mj | for managing / developing related things | 05:13:13 |
 emily | by-name doesn't have anything to do with the package's contents | 05:16:50 |
| emily | assuming it is one package | 05:16:52 |
| mj | yes it's just got a central gh repository | 05:17:06 |
| mj | weird how I missed that, thanks | 05:23:52 |
|  hexadecimal_dinosaur joined the room. | 05:49:47 |
 K900 | @Tomodachi94 what's the end goal here? | 06:08:49 |
 Tomodachi94 | @k900:0upti.me: removing all usages of qt5.mkDerivation, per https://github.com/NixOS/nixpkgs/issues/180841. Not sure if it's worth the time though, Qt5 has been EOL for quite some time and emilazy mentioned it might be on its way out in Nixpkgs
| 06:49:31 |
| emily | it's only EOL in 2025 FWIW (and KDE people apparently plan to keep it alive past that point, though for e.g. WebEngine that will certainly not be sufficient) | 06:49:57 |
| K900 | Yes but like, why | 06:50:10 |
| emily | I lean towards thinking that removing unmaintained Qt 5 stuff is a better use of time | 06:50:26 |
| K900 | qt5.mkDerivation mostly causes issues on cross, which is already extremely broken for Qt5 | 06:51:30 |
| K900 | So I don't really see why we need to write tooling to get rid of it | 06:51:57 |
| Tomodachi94 | In reply to @emilazy:matrix.org
I lean towards thinking that removing unmaintained Qt 5 stuff is a better use of time I agree :) I'll focus my energy on that
| 06:58:15 |
| Tomodachi94 | Do you think it'd be worth it to lib.warn when qt5.mkDerivation is used? I'm not familiar with when it's appropriate to use that
| 06:59:12 |
| emily | can't do that, warnings are forbidden by CI in Nixpkgs | 07:00:10 |
| K900 | Yeah, the warnings in nixpkgs are intended to be user facing | 07:02:10 |
|  fredrikr set a profile picture. | 08:09:12 |
| fredrikr changed their display name from fredrikr79 to fredrikr. | 08:09:24 |
 Emma [it/its] | not sure if this is a me issue or not, but i get this when i try launching a vm made with nixos-rebuild build-vm: [1] 3933577 segmentation fault (core dumped) ./result/bin/run-matrix-vm
latest nixpkgs | 14:43:59 |
 hexa | coredumpctl debug | 14:49:10 |
| Emma [it/its] | seems its coredumping in linux-vdso.so.1 | 14:50:07 |
| Emma [it/its] | (it is bash itself coredumping, can reproduce by just running bash directly) | 14:50:38 |
| Emma [it/its] | Signal: 11 (SEGV)
Command Line: /nix/store/717iy55ncqs0wmhdkwc5fg2vci5wbmq8-bash-5.2p32/bin/bash -x ./result/bin/run-matrix-vm
Executable: /nix/store/717iy55ncqs0wmhdkwc5fg2vci5wbmq8-bash-5.2p32/bin/bash
Storage: none
Message: Process 3937622 (bash) of user 1000 dumped core.
Stack trace of thread 3937622:
#0 0x00007fe36cc5b140 __vdso_clock_gettime (linux-vdso.so.1 + 0x1140)
#1 0xb27e158d48ffffe2 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Coredump entry has no core attached (neither internally in the journal nor externally on disk).
ommitted some info like UIDs etc for brevity, coredump part is complete | 14:52:05 |
| Emma [it/its] | its odd that the stacktrace is that short though | 14:53:00 |
| Emma [it/its] | but yeah, its consistently coredumping at __vdso_clock_gettime | 14:53:37 |
