<globin>
Ericson2314: the splicedPackages.callPackage fixes the cases where the nativeBuildInput is not from in the newScope, that case needs further fixing
<globin>
Ericson2314: although that might have worked before..
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
orivej_ has quit [Ping timeout: 252 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
justanotheruser has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-dev
janneke` is now known as janneke
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Ping timeout: 244 seconds]
drakonis_ has joined #nixos-dev
orivej has joined #nixos-dev
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
hedning_ has joined #nixos-dev
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
layus has joined #nixos-dev
orivej has joined #nixos-dev
drakonis_ has quit [Remote host closed the connection]
drakonis_ has joined #nixos-dev
psyanticy has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
Synthetica has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 264 seconds]
rsa has joined #nixos-dev
justanotheruser has quit [Quit: WeeChat 2.4]
<Ericson2314>
globin: yes that case isn't helped at all bu that change
Cale has quit [Remote host closed the connection]
Cale has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen>
my system's closure onl ydepends upon python2 due to virtualbox, and only for a single path /nix/store/d2hvpyhy90q92vqfa8qgv14is7532g5s-virtualbox-5.2.26/libexec/virtualbox/rdesktop-vrdp-keymaps/convert-map I wonder if VBox supports python3 fully yet or no,
<gchristensen>
sure is a lot of software depending on python3 :/
orivej has quit [Ping timeout: 246 seconds]
<niksnut>
I noticed the other day I have 3 different versions on ffmpeg in my closure
<infinisil>
> ffmpeg.name
<{^_^}>
"ffmpeg-3.4.6"
<infinisil>
For some reason we have ffmpeg_3 as a default
<adisbladis>
I think the main reason is testing a PR to change it is a major headache
<adisbladis>
That's why I didn't change it
<infinisil>
I guess it would be fine to merge without testing everything and fix failures as they get noticed
<infinisil>
(isn't that one of the main points of hydra anyways?)
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis has quit [Ping timeout: 248 seconds]
{`-`} has joined #nixos-dev
orivej has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 252 seconds]
orivej_ has quit [Ping timeout: 250 seconds]
<niksnut>
infinisil: indeed, I think that's fine (especially early in the 19.09 cycle)
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 244 seconds]
<dtz>
i've been using ffmpeg_4 as default for a while (after we chatted about it a few or two ago) and I think only problem I've had so far was an immediate one and it was that gstreamer and such were too old-- but happily that's since been fixed \o/
drakonis has joined #nixos-dev
orivej_ has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 258 seconds]
Melkor333 has joined #nixos-dev
<thoughtpolice>
What exactly is the plan for Python 2 in Nixpkgs, anyway? We're going to Be Bold and just drop it like a hot potato, right?
* thoughtpolice
braces for everybody to get mad at him
<thoughtpolice>
(I'm assuming that, say, 19.09 would be the last release with Python 2 packages available, since it'd be EOL'd by 20.03)
<simpson>
thoughtpolice: I'm hoping to convince people that we should make `python2Packages` alias `pypy2Packages` and kill CPython 2.x entirely.
<gchristensen>
ideally we can drop as much py2 stuff as we can _before_ 19.09
<globin>
I'm currently working on a branch moving everything to py3
<gchristensen>
globin++!
<{^_^}>
globin's karma got increased to 4
<globin>
still only local
<thoughtpolice>
Another unrelated question: what's the policy on nuking old versions of stdenv, like, say, stdenv49? Due to Hysterical Raisins, one of the expressions I maintain is currently the only stdenv49-dependent package. But I'm hoping to drop the versions that require this, effectively making stdenv49 'dead'
<{^_^}>
#61009 (by thoughtpolice, 1 day ago, open): foundationdb: add fdb 6.1 with cmake build [WIP]
<globin>
thoughtpolice: just go ahead and remove stuff like that!
<thoughtpolice>
Hilariously we still have more expressions dependent on stdenv48, for whatever reason...
<thoughtpolice>
Like 10 of them I think
<globin>
we can always bring it back if someone should need it
<infinisil>
People can always use an older nixpkgs version!
<LnL>
we've also dropped old clang versions a while back, we can't keep everything around
<globin>
sometimes I've removed the last packages blocking something like that
<simpson>
thoughtpolice: Anyway, if there's no RFC yet, I can write one up when I get home. All I care about is preserving the nuance that CPython != PyPy != Python.
<globin>
depends on how much it's used and maintained
<adisbladis>
Couldn't we basically sed s/pythonPackages/python2Packages/ and at least make python2 usage explicit for 19.09?
<thoughtpolice>
simpson: Is PyPy planning on maintaining PyPy2 for a while? I guess their PyPy3 support is a little behind, but IDK if they say it's "stable" or not (I think it is considered stable, these days?)
<thoughtpolice>
globin: yeah, I've done the same before. In this case it's unfortunately a hard requirement for older FoundationDBs, but I think the saving grace here is the on-disk database format doesn't change often and hasn't for a while. So dropping the old expressions once the newest version is released shouldn't be too troublesome, a nixos-rebuild switch should make it all "Just Work" in theory.
<simpson>
thoughtpolice: PyPy will support Python 2 indefinitely. https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html "PyPy's own position is that PyPy will support Python 2.7 forever---the RPython language in which PyPy is written is a subset of 2.7, and we have no plan to upgrade that."
<thoughtpolice>
They also require an old version of boost 1.52 lol, but luckily that one's an easy fix
<LnL>
didn't FRidh make a branch or pr to switch to python3 by default at some point?
<gchristensen>
I think Python upstream said "python" should mean python2
<LnL>
yeah it was closed because of something like that
<infinisil>
gchristensen: Let's get rid of python then, such that people will have to use python2 or python3 (-Packages)
<thoughtpolice>
adisbladis: Yes, we could just flip default pythonPackages expression to point to python3Packages, which would fix a bunch of uses. But of course then we still have to maintain python2Packages anyway.
<gchristensen>
I thought about making a PR marking python2 broken and setting it as a blocker for 1909 :)
<thoughtpolice>
Maybe that's alright though, since it's a bit slower.
<qyliss>
my understanding is that upstream say 'python' the executable should mean python2
<gchristensen>
infinisil: maybe keep it as an alias? seems smart
<qyliss>
But that doesn't really apply to us
<qyliss>
I don't think they say anything about package names
<LnL>
gchristensen: hehe
<infinisil>
gchristensen: Yeah definitely
<qyliss>
We got this wrong in my Homebrew days and broke the world
<gchristensen>
infinisil: that is a really great idea
<qyliss>
But then fixed it by making the "python" package install "python3", and the "python2" package install "python".
<adisbladis>
thoughtpolice: I think that's alright? At least that's a step towards dropping things
<thoughtpolice>
qyliss: Yeah, there's nothing about packaging python itself AFAICS, so in theory just having both python3 and python2 point to python would be fine
<infinisil>
gchristensen: Also, I don't think anybody minds typing 1 letter more
<thoughtpolice>
adisbladis: Yeah exactly, we could just tell users the default has switched and to report any bugs, since it will be removed later, etc
<qyliss>
So AIUI there's no reason the "python" package _shouldn't_ be python3
<thoughtpolice>
Which is perhaps better than just nuking everything from orbit at once
<gchristensen>
if someone was bothered by 1 character they'd not be using nix probably
<thoughtpolice>
But not as satisfying or dramatic.
<gchristensen>
infinisil: want to send that PR? :)
<qyliss>
tl;dr I think "pkgs.python" should be Python 3
<LnL>
qyliss: that's currently handled by priorities, if you install both in an environment python2 will get priority so it's python binary will take presedence
<adisbladis>
thoughtpolice: I think I'll do that tonight :)
<infinisil>
gchristensen: Eh, I don't care enough about python for doing it
<gchristensen>
no worries
<infinisil>
Man my todo list is growing by the day, there's so many cool things I wanna code
<thoughtpolice>
In Other Unrelated News: I found recently that by enabling libcxxStdenv and using LTO + LLD, I was able to reduce the size of some closures up to 1/3rd of the original (~220mb -> 70mb). I read recently that GCC's LTO support is moving towards being the intended default for all "release" builds. I wonder how much this would all impact the builders.
<infinisil>
Nice!
<gchristensen>
haha yes 100% infinisil
<thoughtpolice>
If my experiment is anything to go by I got 1/3rd the size at 3x the compile time. I wonder if the binary cache bandwidth is more valuable than builder cycles.
<thoughtpolice>
But given how loaded our builders are already, I think not: the builders delivering objects continuously and reliably, even if they're bigger/a little slower, is more important than their total size. Interesting thing to think about.
<gchristensen>
I agree with that
<thoughtpolice>
I don't know what the plans are for the new default gcc (GCC 9.1?) but 9.1 has a lot of improvements here that would be interesting to experiment with for some expressions
<gchristensen>
it is a bit tricker to get more build resources
<infinisil>
thoughtpolice: So this size decrease only affects C/C++ libraries/executables?
<thoughtpolice>
In FoundationDB's case, I think the compile time going from 3m -> 10m for a 66% reduction is a pretty good tradeoff, personally. But that's just me.
drakonis has joined #nixos-dev
<thoughtpolice>
infinisil: Correct (I don't think we have any of the other GCC languages in major use, but it would otherwise apply to them too, I think)
<thoughtpolice>
Maybe we have some gfortran libs around.
<thoughtpolice>
gchristensen: I wonder how many resources we have comparatively with other projects given our package count. Probably a tough question to ask fairly, considering we don't have a gajillion dollars of Corporate Funny Money to buy hardware like others might (Fedora/CentOS/RHEL/OpenSuSE, etc). They can probably just get some more if they need it...
<qyliss>
OpenBLAS is Fortran
drakonis has quit [Ping timeout: 248 seconds]
boredom101 has joined #nixos-dev
<gchristensen>
thoughtpolice: I also wonder
<thoughtpolice>
I think it'd be interesting to ask (I don't see why any maintainers wouldn't answer?), just drawing many conclusions might be tough.
<thoughtpolice>
globin: Wow, 55+ x86_64-linux builders alone. Pretty sure we pale in comparison to that...
<thoughtpolice>
lol I think they legit have more s390x machines available than we do aarch64. Ah, to have those sweet, sweet Big Blue connections.
<thoughtpolice>
I also find it interesting that Debian is apparently using an array of Nvidia Jetson boards?
<thoughtpolice>
jtk1/jtx1, those are pretty dated at this point. On the other hand, you can now buy Tegra X1's for about $99 and they have 4GB of RAM and a 4 pretty fast cores, in credit card form factor/15w max TDP...
<lopsided98>
Has there been any work on upgrading the default GCC version (even just to 8) ? I can't seem to find anything
<{^_^}>
#60860 (by vcunat, 4 days ago, open): gcc9: init at 9.1.0 (released today)
<thoughtpolice>
I don't think there's any schedule or rule about this, so basically if you're willing to wade through it, you could try updating stdenv yourself and see what happens. Things have surely busted, somehow, somewhere.
<thoughtpolice>
I'd guess someone will (probably) do this before 19.09. GCC 9.2 etc should be out by that point too, I'd think.
<niksnut>
gcc 9 \o/
<niksnut>
would be great to have at least gcc 8 as default in the next release
<thoughtpolice>
Diagnostic improvements look dope, honestly. Maybe I should pull the trigger on #60860 myself and try playing with it...