!kjdutkOsheZdjqYmqp:nixos.org

Nixpkgs / NixOS contributions

1864 Members
NixOS 24.05 Uakari | #review-requests:nixos.org | https://nixos.org/blog/announcements.html#nixos-23.11 | https://hydra.nixos.org/jobset/nixos/trunk-combined | https://reproducible.nixos.org/ | 24.05 RMs: wegank & Mic92410 Servers

Load older messages


SenderMessageTime
21 Oct 2024
@qyliss:fairydust.spaceAlyssa RossIt would be very nice if it was.18:34:22
@hexa:lossy.networkhexaimage.png
Download image.png
18:34:36
@reecertv:matrix.orgReecerTV joined the room.18:54:55
@reecertv:matrix.orgReecerTV set a profile picture.18:59:17
@artur:glasgow.social(artur 'manuel) changed their display name from (lambda (f l) (format nil "~a ~a")) "Artur" "Manuel" to (artur 'manuel).20:04:36
@maka_77x:matrix.orgmaka_77x joined the room.20:05:37
22 Oct 2024
@xyven:matrix.org@xyven:matrix.org left the room.02:02:02
@reckenrode:matrix.orgRandy Eckenrode
In reply to @matthewcroughan:defenestrate.it

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`
fyi https://github.com/NixOS/nixpkgs/pull/350374
03:07:57
@human:nitro.chathuman joined the room.04:49:17
@zarel_it:matrix.org@zarel_it:matrix.org left the room.09:31:33
@raf:notashelf.devraf Is the formatting check failing for nixos/tests/all-tests.nix my fault, or can it be overlooked? Formatting it with nixfmt-rfc-style *really* messes up the structure, so I don't think it's expected to be formatted via nixfmt? 09:32:35
@raf:notashelf.devraf Nvm, it was caused a formatting mistake in the test. 09:38:05
@rnhmjoj:eurofusion.eurnhmjoj joined the room.10:37:25
@niko:nrab.lolniko ⚡️

(Cross-posting from nix discord, figured I’d get a response here faster)

One would think that localSystem and crossSystem overlap horribly with the three *Platforms (buildPlatform, hostPlatform, and targetPlatform; see stage.nix or the manual). Actually, those identifiers are purposefully not used here to draw a subtle but important distinction: While the granularity of having 3 platforms is necessary to properly build packages, it is overkill for specifying the user’s intent when making a build plan or package set.

Okay, but what if that „overkill” is what I want and what I need? Can I manually specify all the 3 platforms? Does our cross infra consider that possibility?

11:36:16
@k900:0upti.meK900Why do you want that? 11:37:39
@k900:0upti.meK900Are you trying to do some sort of Canadian cross setup?11:38:49
@niko:nrab.lolniko ⚡️
In reply to @k900:0upti.me
Are you trying to do some sort of Canadian cross setup?
I’d want to build binutils for build = x86_64-linux-gnu, host = x86_64-linux-musl, target = arm-none-eabi. (Not actually binutils specifically in this case, but close enough) and while this isn’t as bad since I can just say musl is my build, imagine host was arm-linux-musl. Would that mean I have to compile binutils on the arm host?
11:41:45
@k900:0upti.meK900Canadian cross is generally not well supported by, um, anything 11:42:28
@k900:0upti.meK900 But also targetPlatform is kind of a weird implementation detail and ideally we just wouldn't have it at all 11:43:10
@k900:0upti.meK900But it has to exist because the GNU toolchain is silly 11:43:26
@niko:nrab.lolniko ⚡️ So generally one has to assume either build=host or host=target 11:43:55
@k900:0upti.meK900 Ideally the correct way to represent this would be targetPlatform == null 11:44:45
@k900:0upti.meK900 But currently we have targetPlatform == hostPlatform for most packages even though they don't actually care 11:45:27
@niko:nrab.lolniko ⚡️So assuming the ideal world where target = null, something like arm-none-eabi-gcc compiled for x86_64-linux-gnu loses the arm-none-eabi information and it’s not relevant for the cross infra, is that right?11:46:50
@k900:0upti.meK900 No, the packages that do still have one specific target will still have targetPlatform 11:47:48
@k900:0upti.meK900 But something like, I don't know, Qt doesn't have anything that could reasonably be called a targetPlatform 11:48:19
@niko:nrab.lolniko ⚡️ Ah, okay, that’s what you meant, sorry 11:48:20
@niko:nrab.lolniko ⚡️ changed their profile picture.11:49:17
@aktaboot:tchncs.deaktaboot changed their profile picture.12:11:12
@rnhmjoj:maxwell.ydns.eu@rnhmjoj:maxwell.ydns.eu left the room.12:40:06

Show newer messages


Back to Room ListRoom Version: 6