<peti>
Now I wonder why Nixpkgs has so many metapackages. 38113 meta packages in nixpkgs-stable doesn't sound correct.
<MichaelRaskin>
Doesn't sound impossible that it would be the total number of metapackages represented in Nixpkgs, if they include some part of python packages
<MichaelRaskin>
Or TeXLive
ixxie has joined #nixos-dev
<ben>
im reading this as metapackages being a repology concept that groups other people's non-meta packages
<ben>
so 38113 packages in nixpkgs are referenced by repology metapackages?
<ixxie>
I think a package is software packaged in a particular way on a particular repo, and a metapackage is more like 'all the firefox packages' in any repo in any version
<ixxie>
interesting we are now topping the lists!
<ixxie>
I was checking a month ago and we were not even there
<ixxie>
weird
<ixxie>
but this is more like the number of packages DOUBLED
<ixxie>
this must be an artifact of something but I am curious what
<aristid>
LnL: i'm happy to help if there's anything simple to be done :)
<aristid>
lol, now that's a silly reason for a build to fail: "cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]"
taktoa has quit [Ping timeout: 276 seconds]
<aristid>
seems like the main issue is that llvm 6.0.0 does not build?
FRidh has joined #nixos-dev
FRidh has quit [Read error: Connection reset by peer]
FRidh has joined #nixos-dev
<LnL>
there are a bunch of llvm/clang changes on staging IIRC
<FRidh>
LnL: I merged and pushed to master.
<FRidh>
darwin users are likely not going to like it though, considering the rebuilds left
<LnL>
hmm? merged what
<FRidh>
staging into master
<FRidh>
rustc is failing though
<MichaelRaskin>
Ouch
<MichaelRaskin>
That means a Firefox problem, right?
<FRidh>
firefox? hmm, I think you;re right..
<FRidh>
at least when its on master people will notice and typically fix :)
<LnL>
FRidh: that's why I created the pr, to fix important stuff first
<FRidh>
LnL: it's good showing that things need to be fixed on staging, but aside from that I don't see how a pr helps (unless it of course includes the actual fixes)
<LnL>
well it's a place to the fixes since staging keeps moving forward
<LnL>
also there's still a 24k queue for the latest eval
<FRidh>
yes, that's mostly arm64 and darwin. At least the latter can't keep up with a diverging master and staging.
FRidh has quit [Ping timeout: 245 seconds]
<aristid>
a lot of things seem to depend on rust now
<MichaelRaskin>
(from computing history encyclopedia from 25th century) Mozilla: An influential early-21st-century project dedicated to rethinking of low-level programming. Sometimes rumored to have a weird fixation on testing out new features in browser engines few people used.
<LnL>
well..., I canceled all staging builds since those are pointless now
* aristid
is bisecting rustc to see which commit broke it :D
* aristid
loves his git-bisect
aminechikhaoui has quit [Ping timeout: 256 seconds]
<aristid>
MichaelRaskin: it doesn't find test_inherit_env
<aristid>
MichaelRaskin: and i still get the same "hread 'main' panicked at '" error even in master
<aristid>
MichaelRaskin: let me try reverting afc439d57b3866cb499fe68b94f969079aba7963 and see if that fixes it
<MichaelRaskin>
Compiler segfault
<MichaelRaskin>
Nya
<aristid>
great fun
<MichaelRaskin>
Which is usually either nondeterministic, or CPU-dependent, not sure which case is more annoying
<MichaelRaskin>
Both cases are !!FUN!! of course
<aristid>
MichaelRaskin: the fact that the error messages has "thread" in it is FUN too
<aristid>
not that needs to mean much, i guess
<MichaelRaskin>
You mean «thread main» in the end? Smoke and mirrors
<MichaelRaskin>
GCC segfault, though, is a real deal.
<MichaelRaskin>
How long did it take? Does a rebuild just to check for indeterminism sound like too much pain?
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<aristid>
MichaelRaskin: i think it takes about 30 mins
<aristid>
MichaelRaskin: i want to first try my current experiment (of reverting afc43), then try for indeterminism
<aristid>
-first try+first finish
<niksnut>
damn, NixOS closure sizes are really getting out of control
<MichaelRaskin>
What got included this time? Or just a thousand cuts?
<niksnut>
my home pc went from 4.4 GiB in 17.09 to 5.7 GiB in 18.03
<niksnut>
and, iirc, 17.09 was already a gigabyte increase over 17.03
<MichaelRaskin>
Oh, that's full desktop closures
<niksnut>
a quick look reveals something called noto-fonts-2017-10-24-phase3-second-cleanup which is ~300 MB
<niksnut>
go, for some reason
<MichaelRaskin>
Something got built locally? Of all things, go seems to be something to produce static executables…
<niksnut>
binutils, which went from 26 MB to 208 MB
<MichaelRaskin>
Right, multitarget support
<gchristensen>
:/
<niksnut>
apparently docker now has go in its closure
<MichaelRaskin>
Argh
<niksnut>
we should probably require people to include the old and new closure sizes of packages in PRs
<LnL>
go is really bad about making references to the compiler
<niksnut>
3 versions of qt
<niksnut>
bazaar, for some reason
<gchristensen>
bizarre
<niksnut>
oh, also in docker's closure
<gchristensen>
ofborg could build master, then the PR, and report closure size diffs
<LnL>
go depends on all version control packages for go get
<MichaelRaskin>
Good: you could have two versions of glibc 2.5 (different thread models) without conflict. Bad: you end up with multiple Qt versions for noe reason.
<aristid>
gchristensen: of just the package in the PR?
ixxie has joined #nixos-dev
<niksnut>
docker's closure is 1.2 GiB
<gchristensen>
aristid: "just the package in the PR" is a hard question to answer, but whenever ofborg builds now, it would build 2x
<niksnut>
so much for lightweight containers ;-)
<aristid>
MichaelRaskin: i think if reverting the binutils commit doesn't fix it, that would also point to nondeterminism
<aristid>
gchristensen: how does ofborg determine what to build? :)
<MichaelRaskin>
docker — go : go get — bzr is a fun dependency chain…
<aristid>
niksnut: i know it's not meant as a human link, but if i click this i get "Please come back later"
<aristid>
lol with austrian translation
<ixxie>
loool
<aristid>
MichaelRaskin: the build seems to get much further with my revert... which also means i need to wait longer to try out your suggestion
<gchristensen>
hmmm cool niksnut
<gchristensen>
I'll make a ticket
<MichaelRaskin>
Russian translation doesn't use ё and uses е instead. Pity. (It is formally acceptable and a subject of an everlasting flamewar, where I am on the side of using separate letters as they do have different pronounciation).
<gchristensen>
MichaelRaskin: you could send a patch to Catalyst
<aristid>
but why do i get the "please come back later"?
<aristid>
:D
<LnL>
content type
<aristid>
LnL: i would expect a different error?
<LnL>
dunno, it's the default error of the framework I think
<niksnut>
the closure size of kdenlive doubled from ~700 MB to 1400 MB
<aristid>
niksnut: due to a dependency, or just kdenlive itself?
<niksnut>
well, in part because mlt's closure went up from 326 to 934 MB
<aristid>
what is mlt?
<aristid>
niksnut: probably mlt requires go, java and c# all at the same time now
<niksnut>
opencv went from 292 to 528
<MichaelRaskin>
aristid: you forgot Rust
<aristid>
MichaelRaskin: but you need rust for firefox anyways
Mic92 has joined #nixos-dev
<MichaelRaskin>
But the point was about a closure that doesn't include Firefox
<LnL>
yeah, everything niksnut is talking about is runtime closure
<aristid>
LnL: rust does have a runtime component, no?
<gchristensen>
don't think so?
<aristid>
MichaelRaskin: i thought it was about the total desktop closure size
<aristid>
gchristensen: i mean, most languages have a runtime
<niksnut>
aristid: no, but it does have gcc in its closure now, as well as binutils which became 10x bigger
<LnL>
no and if it did it would be in a separate output
<aristid>
niksnut: why is gcc in the runtime closure?
<niksnut>
dunno
<LnL>
(hopefully)
<niksnut>
gcc-wrapper, even
<aristid>
LnL: rust has no runtime?! i don't buy that
<aristid>
now i will try rebuilding from the exact commit from origin/master that it failed with a compiler segfault last time
<MichaelRaskin>
Wow
<MichaelRaskin>
It is a completely different test failure
<MichaelRaskin>
(hygienic macros related?)
<aristid>
MichaelRaskin: oh wait, i just noticed that it segfaulted WHILE LINKING TESTS
<aristid>
linker segfaulting is scary
<MichaelRaskin>
Let me guess: my build passed because I have 16GiB RAM and it was basically uncontested, and under memory pressure it tries to be smart and fails
<clever>
aristid: i once had trouble linking firefox on a 32bit machine, because ld needed over 3gig of ram
<aristid>
MichaelRaskin: my build server has 32 GB RAM
<aristid>
but it also tries to build with 16 threadss
<aristid>
i'm also not building anything else on the machine
ixxie has quit [Ping timeout: 264 seconds]
<aristid>
MichaelRaskin: now the rustc build seems stuck doing nothing for 10+ minutes (0% cpu load on my server)
<MichaelRaskin>
How, hm, diverse.
<aristid>
you could say that.
* aristid
cancels and tries again, to see how it fails now
<aristid>
although i probably won;t be able to see results until tomorrow evening, it being late and all
<MichaelRaskin>
I would say that it is a source of high-entropy randomness, but bits-per-second is actually pretty bad
<aristid>
a good addition to rdrand
<MichaelRaskin>
Well, hashing unplugged audio input over a few minutes will give you more random data, and the quality will be quite good… Especially if you hash it via something that does aim to be a PRNG
<LnL>
aristid: what stage?
<aristid>
LnL: i killed the build so it seems there is no log
<aristid>
:(
<MichaelRaskin>
I guess what killed the log is the restart…
<MichaelRaskin>
But maybe not, I don't understand the buffering of Nix logs
<aristid>
hmm, maybe
joachifm has quit [Remote host closed the connection]
<MichaelRaskin>
OK, I can launch rustc build
<MichaelRaskin>
afc439d57b3866cb499fe68b94f969079aba7963 should fail, right?