das_j has quit [Remote host closed the connection]
das_j has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-dev
davidtwco has quit [Ping timeout: 252 seconds]
zimbatm has quit [Ping timeout: 264 seconds]
dmj` has quit [Ping timeout: 250 seconds]
chrisaw has quit [Ping timeout: 276 seconds]
scott has quit [Ping timeout: 276 seconds]
chrisaw has joined #nixos-dev
davidtwco has joined #nixos-dev
zimbatm has joined #nixos-dev
scott has joined #nixos-dev
dmj` has joined #nixos-dev
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
tdeo has joined #nixos-dev
tdeo has quit [Changing host]
orivej has quit [Ping timeout: 268 seconds]
init_6 has joined #nixos-dev
init_6 has quit [Ping timeout: 240 seconds]
init_6 has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
init_6 has quit []
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
niksnut has joined #nixos-dev
johanot has joined #nixos-dev
ryantm has quit [Ping timeout: 258 seconds]
<Taneb>
qtscript is broken in 19.09 due to https://bugreports.qt.io/browse/QTBUG-74196 I think, but I don't have the time to fix it right now. There's a fix mentioned in my link
<Taneb>
(is this the right place for this sort of thing?)
<manveru>
probably :)
andi- has quit [Quit: WeeChat 2.6]
andi- has joined #nixos-dev
andi- has quit [Quit: WeeChat 2.6]
andi- has joined #nixos-dev
orivej has joined #nixos-dev
<ddima>
FRidh: Hey. I think the recent bumps of numpy to 1.7.2 have broken scikit-learn, which break quite a bit of downstream python modules - this issue does not seem to be fixed upstream yet either: https://github.com/scikit-learn/scikit-learn/issues/14547
<{^_^}>
scikit-learn/scikit-learn#14547 (by h6197627, 5 weeks ago, open): Scikit-learn 0.21.3 test_lda_predict test failure with Numpy 1.17.0
<ddima>
I'm currently trying it out against the older version to verify, but if there are not too many issues caused by a rollback, one might consider that for 19.09
<FRidh>
ddima: it's just a single test and a matter of tolerance it seems. In other words, that test needs tuning. We could disable that specific test until that's done.
<ddima>
Id be a bit worried about numerical discrepancies though
<ddima>
as in, as a distribution it might be best to not fiddle with such things with libraries that are very wide-spread for statistical applications, compared to a rollback. but thats just my first intuition.
<ddima>
but I did not check yet what the numpy bumps included feature/bugfix wise, so thats a one-sided sentiment.
drakonis has joined #nixos-dev
<FRidh>
yes, every version will have its bugs
<ddima>
At least at first sight "Mismatch: 16.7%" does not shout "obviously harmless"
<FRidh>
often with these types of tests the values are produced, then stored, and later tested against. If it was originally not entirely correct, you would always be testing against that
__monty__ has joined #nixos-dev
<ddima>
yeah, I know, I've sadly have dealt quite a bunch with such tests - but its also a bit of a question of who should be able to make that call. I'll look around for a bit. Just wanted to give you a head up.
drakonis_ has quit [Ping timeout: 276 seconds]
<FRidh>
alright thanks
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<worldofpeace>
Taneb: if you don't have time to fix the issue right now, opening an issue for yourself and others would be a good idea.
<worldofpeace>
that way duplicated efforts don't happen and you can gather the opinions of other people who could help with the issue.
<FRidh>
ok so its not like someone got funded to work on that
<worldofpeace>
srhb: you reproduced that issue in a minimal vm environment right?
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 276 seconds]
pie__ has quit [Ping timeout: 246 seconds]
pie_ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
<Mic92>
FRidh: do you see any real-world advantages of having such a system? I feel like my paranoia level is not high enough to spend time on such a project.
<qyliss>
I might well look into Mes as part of my work.
<qyliss>
My paranoia level is definitely high enough.
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-dev
das_j has quit [Remote host closed the connection]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
__monty_1 has joined #nixos-dev
__monty_2 has joined #nixos-dev
<rycee>
Anybody know how to get a a custom branch build on Hydra? Would like to have a build of https://github.com/NixOS/nixpkgs/pull/67942 to do some tests. It's a bit too heavy for my laptop since it includes an stdenv change…
<infinisil>
rycee: Somebody with the necessary permissions needs to do that
<Mic92>
rycee: domenkozar[m] for example can do that.
drakonis1 has quit [Ping timeout: 264 seconds]
<Mic92>
rycee: do you think a custom branch is required for this one?
<rycee>
Not sure. I'm reasonably confident in the change since I've tried adding the build hook directly to some strategically chosen packages without any issues.
<Mic92>
rycee: I would also say this could go to staging as is.
<infinisil>
Yeah same
<rycee>
So for my purposes I would be happy to have it merged into staging and then doing the tests against a staging build.
<infinisil>
We do have staging for such changes after all
<Mic92>
rycee: you would want a custom branch if you for example upgrade gcc...
<infinisil>
Ah you want to do testing with it, right
<rycee>
infinisil: Yeah, I'd like to set up a whole system that used the new hook and verify that all user systemd services still work OK.
drakonis_ has joined #nixos-dev
<Mic92>
rycee: if you just want to build your desktop with it, zimbatm maybe could give you builder access to the nix-community machine...
<worldofpeace>
jtojnar: that makes me think that unstable should be part of version then. as it conveys a separate versioning from schemes that use dates as versions. and pname should be the upstream software name?
<jtojnar>
worldofpeace: if pname = package name, we could have foo & foo-unstable. That is how I interpret the manual, unstable as a separate package
Cale has quit [Ping timeout: 276 seconds]
<jtojnar>
If we defined pname = project name, then I would agree, but a package manager might not care about project name as much (consider source splitting)
<worldofpeace>
jtojnar: I do recall at some point someone stating that as the reasoning behind that rule. but sometimes the same package gets upgraded to an unstable version, is foo-unstable now completely different from foo and how will others interpret that? I'd say it's just the same package at a different version, the actual attrubute for the package would be the means to separate it.
<jtojnar>
actually, source splitting is a point we should consider
<worldofpeace>
define source splitting?
<jtojnar>
worldofpeace: great point
<jtojnar>
worldofpeace: like gentoo does with gst plugins
<worldofpeace>
jtojnar: ah now I know what you mean.
<worldofpeace>
all of this becomes hard to explain to other people when nix doesn't have a internal abstraction of a package :D
<jtojnar>
yeah
<jtojnar>
could we use attribute names for repology?
<jtojnar>
that would allow us to sidestep this discussion completely
<worldofpeace>
I'm not sure. I don't think any attribute in all-packages.nix can begin with a number, but I guess they could filter that
<worldofpeace>
I think it's possible pname and version can be blessed attributes that are expected to be exposed, and name just becomes an internal thing like you've said
Cale has joined #nixos-dev
<jtojnar>
worldofpeace: the main issue with where to place unstable probably comes from the fact that we use it for two different things
<jtojnar>
a) unstable variants of packages
<jtojnar>
b) main package but unstable version
<jtojnar>
and Nix makes it hard to tell which is which since it does not know any blessed attributes other than name
<worldofpeace>
jtojnar: right, we should mix two distinct concepts like this
<worldofpeace>
* shouldn't
<worldofpeace>
hmm, parseDrvName will actually never consider unstable as part of the version
<jtojnar>
worldofpeace: yup, that's the whole reason I opened the issue in the first place
<jtojnar>
worldofpeace: the only way to fix this is to let nix-env use pname instead of Nix's parseDrvName equivalent
<worldofpeace>
jtojnar: i.e pname rfc 2.0 :D
<jtojnar>
but I would rather drop name support from nix-env altogether
<jtojnar>
attrpath master race
<worldofpeace>
The attr paths are rarely confusing, +1 for them I guess
<jtojnar>
worldofpeace: also another idea: do not list variants in all-packages.nix but expose them through passthru.variants
<jtojnar>
would probably require hydra patch, though
* emily
would prefer only having "unstable" in separate variant packages that are actually expected to be less stable than some stable version
<emily>
I don't think it makes sense to use version = "unstable-YYYY-MM-DD" for stuff whose "main upstream" is a git repo
drakonis has quit [Ping timeout: 258 seconds]
<worldofpeace>
jtojnar: in general having a nice way to expose different build variants would be nice, currently it's just another package
<worldofpeace>
emily: I think in the context of the manual unstable means not a stable release