| 20 Oct 2024 |
 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 |
| Emma [it/its] | hm, seems to only happen in an FHSEnv, or something like that
when i run it under steam-run rider, i get that coredump, but when i run it from a regular terminal it's fine | 14:59:27 |
| hexa | are you running anything weird, like the hardened profile? | 15:00:19 |
| Emma [it/its] | not that i know of? not sure if steam-run has anything to do with the issue though | 15:01:01 |
 matthewcroughan | Trying to update a package, but finding this
rcodesign> error[E0282]: type annotations needed for `Box<_>`
rcodesign> --> /build/rcodesign-0.27.0-vendor.tar.gz/time/src/format_description/parse/mod.rs:83:9
rcodesign> |
rcodesign> 83 | let items = format_items
rcodesign> | ^^^^^
rcodesign> ...
rcodesign> 86 | Ok(items.into())
rcodesign> | ---- type must be known at this point
rcodesign> |
rcodesign> = note: this is an inference error on crate `time` caused by an API change in Rust 1.80.0; update `time` to version `>=0.3.35` by calling `cargo update`
| 16:18:31 |
