bgamari has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 272 seconds]
bgamari has joined #nixos-dev
alp has joined #nixos-dev
<emily>
wow, does that firmware just contain an entire embedded OS distribution or something
_e has quit [Quit: WeeChat 2.7.1]
_e has joined #nixos-dev
tilpner has quit [Quit: tilpner]
hexa- has quit [Quit: WeeChat 2.7.1]
hexa- has joined #nixos-dev
terrorjack has joined #nixos-dev
_e has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
<xfix>
emily: i wouldn't be too surprised
<xfix>
of course, it's different models and all that sum up to 140MB
alp has joined #nixos-dev
<gchristensen>
cole-h: I just want to call out how much I appreciate your involvement, interest, and care lately. It has made a difference to the project and me personally, thank you for it. Things have felt a bit less "alone" in some ways -- and it is nice to have help on my "not me, team" project
<cole-h>
:D
<LnL>
cole-h++
<{^_^}>
cole-h's karma got increased to 43.00000000000000004
<cole-h>
<3 gchristensen Happy to help. I've always wanted to be involved in larger open-source projects, so I feel like I've "graduated" in a way, now :^)
<{^_^}>
gchristensen's karma got increased to 287
<pie_>
wait what <{^_^}> cole-h's karma got increased to 43.00000000000000004
<cole-h>
infinisil: Added some spice to the karma messages for "rare" occasions
<pie_>
;p
<infinisil>
I swear I didn't! It's these damn floats again!
<gchristensen>
lmao
<adisbladis>
Where did cole-h come from? Recently
<adisbladis>
I've never head of this person, now produces awesomeness all over the place
<cole-h>
adisbladis: lol :D gchristensen was soliciting Rust help here a few months ago I think
<cole-h>
Something about making errors better (because we use/d a whole lot of expects and unwraps which are runtime panics)
<cole-h>
(Which I still haven't done lol)
<gchristensen>
+1
<cole-h>
I started by picking up LnL's old Rust 2018 PR (because 2015 edition, while it wasn't bad, is annoying to write), making opinionated changes, and then it kinda spiraled from there
ixxie has joined #nixos-dev
<pie_>
is there a reason we dont have a current-stable channel?
<pie_>
or metadata somewhere that points to what the current release is?
orivej has joined #nixos-dev
<adisbladis>
pie_: !!
<adisbladis>
I need this
<adisbladis>
I have software I consider supported on unstable + "current stable"
<adisbladis>
But have to manually bump branches on CI to follow what stable is
<pie_>
adisbladis: im not volunteering to implement it :(
<pie_>
but i would like this
<pie_>
currently cole-h has suggested the following; 'xD
<pie_>
TBH I could even argue for something like it being the default, but because of possible breakages across releases, it's probably not reasonable overall.
<abathur>
the other day I re-ran an old CI job that succeeded 2 years prior and it failed; I've had a back-of-mind curiosity since about if/how others occasionally run CI against moving targets like channels/branches
<cole-h>
I use niv to pin stuff (:
<cole-h>
I imagine that will be solved (or at least alleviated) by flakes
<abathur>
well, right, but it'd still be nice to know when breaks are popping up
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
<cole-h>
How do you mean breaks?
<abathur>
any new dep/build/test failure at a project commit that previously succeeded but starts failing as nixpkgs rolls on into the future?
<cole-h>
Got it.
<cole-h>
Running CI for your previously-run CI runs?
<abathur>
well, I was revisiting an early phase project I haven't had time to touch for 2 years, and the tests weren't running--but they ran clean the last time I ran CI
<abathur>
so I was re-running it as a sanity check
<abathur>
and have had a little percolating thought since that it'd be nice to have a feedback drip of some sort there
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
<abathur>
I think at least in the case of travis-ci I could set up a branch with recurring cron jobs to handle the Nixpkgs fraction of that, but sometimes I'm also building an explicit version/ref of a dependency; might be nice to let them drift and get feedback
<abathur>
I guess it can also be a little bit of both if I'm specifying a rev in an override and in theory package behavior could change under it
* julm
just saw that there is a Mumble for talking about Nix: mumble://mumble.nix-community.org
<drakonis>
ah how nice, when did nix-community gain a website?
<infinisil>
Regarding the discussion on getting statistics on packages in #nixos-chat, I have the following idea
<infinisil>
I have a patch to nixpkgs that allows derivation expressions to know which nixpkgs attribute path they came from
<infinisil>
So pkgs.haskellPackages.xmonad.__nixpkgsAttrPath would be [ "haskellPackages" "xmonad" ]
<infinisil>
Now we could make use of this information by changing Nix itself to (when opted-in), automatically upload stats on these attribute paths of all built derivations
<infinisil>
s/built/realized
<clever>
infinisil: nix-index works by just re-evaling the whole <nixpkgs> and then checking that against a list of storepaths
<clever>
infinisil: to map a pack backwards to an attr
<infinisil>
Yeah but that won't help here I'm pretty sure
<infinisil>
With Nix submitting these attribute paths, we would only expose what *nixpkgs* packages people use, not internal company ones
<infinisil>
And it wouldn't include which store path exactly, only the attribute path, without any version
<infinisil>
gchristensen: sphalerite: ^ Thoughts on this?
<arianvp>
I've re-read this section 5 times and i still dont understand
<arianvp>
> Nixpkgs is now structured so that each depsFooBar is automatically taken from pkgsFooBar
<{^_^}>
undefined variable 'Nixpkgs' at (string):309:1
<arianvp>
this part I dont understand
<arianvp>
if I have
<sphalerite>
"In short, each list of dependencies for "host → target" of "foo → bar" is called depsFooBar, with exceptions for backwards compatibility that depsBuildHost is instead called nativeBuildInputs and depsHostTarget is instead called buildInputs."
<arianvp>
nativeBuildsInputs = [ pkgs.foo ]; is this somehow magically rewritten to pkgs.pkgsBuildHost.foo ?
<arianvp>
how?
<sphalerite>
so buildInputs and nativeBuildInputs is right
<sphalerite>
that bit I don't understand :)
<arianvp>
that sounds totally like black magic to me
<clever>
i'm also interested in how nativeBuildsInputs magically rewrites
<arianvp>
and i dont understand
<arianvp>
im very happy this section exists now!! used to be all undocumented. but it's still very difficult and im not sure if it's without errors