gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat | https://logs.nix.samueldr.com/nixos-dev
Lisanna has joined #nixos-dev
mbrgm has quit [Ping timeout: 252 seconds]
mbrgm has joined #nixos-dev
drakonis has quit [Ping timeout: 245 seconds]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
{^_^} has joined #nixos-dev
gchristensen has quit [Ping timeout: 276 seconds]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
gchristensen has joined #nixos-dev
Lisanna has quit [Remote host closed the connection]
aszlig has quit [Quit: Kerneling down for reboot NOW!]
aszlig has joined #nixos-dev
ixxie has joined #nixos-dev
taktoa has quit [Remote host closed the connection]
Lisanna has joined #nixos-dev
peti has quit [Ping timeout: 248 seconds]
ixxie has quit [Ping timeout: 248 seconds]
Lisanna has quit [Remote host closed the connection]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
peti has joined #nixos-dev
taktoa has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
<peti> What is the difference between a "package" and a "metapackage" on repology.org?
<peti> Ah, https://repology.org/api has an explanation.
<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
<ixxie> its not :)
ixxie has quit [Ping timeout: 240 seconds]
<jcrben> sounds like repology metapackages means something much different than https://help.ubuntu.com/community/MetaPackages which is an unfortunate naming clash
aristid has joined #nixos-dev
<aristid> does packaging count as "development"? :)
<aristid> LnL said in #nixos that he wants to look at it, but here goes for the record:
<aristid> firefox has diverged quite a bit between master and 18.03, and 18.0.3 is much more up-to-date
<LnL> aristid: f4152ea6edd43bb0325eb8b00270f785a3efafe4
<LnL> it's in staging and staging has not been merged back yet
<aristid> LnL: that updates firefox-bin, not firefox
<aristid> LnL: but let me check the status of staging
<LnL> it's multiple commits, f2b3cdd9502e535e203fcd8adbe9a817453d21c6
<aristid> LnL: seems like taku0 kept staging up-to-date indeed
<aristid> but there's no reason for firefox commits to only be in staging
<aristid> it doesn't cause mass rebuilds
<aristid> or do i miss something?
<MichaelRaskin> Maybe they depend on something in staging?
<aristid> hmm, might be i guess
<aristid> when do you think staging will be merged to master?
<aristid> MichaelRaskin: although at least the 59.0.2 to 59.0.3 update should not require anything from staging?! :)
<MichaelRaskin> Is it an NSS bump, maybe?
<LnL> we should really spend some effort on merging staging tho
<aristid> hmm, a lot of important stuff is failing in staging hydra
<LnL> I know
<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]
aminechikhaoui has joined #nixos-dev
FRidh has joined #nixos-dev
<FRidh> The latter is essentially master.
<aristid> 17 commits remaining in the rustc bisect
<aristid> 3
Lisanna has joined #nixos-dev
FRidh has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
<MichaelRaskin> Just for fun, it seems rustc passed on my buildbox after the staging-to-master merge…
<aristid> so i found the commit that broke rustc
<aristid> afc439d57b3866cb499fe68b94f969079aba7963
<MichaelRaskin> How come after-merge master rustc got built fine for me?
<aristid> MichaelRaskin: i will try after-merge, too
<aristid> MichaelRaskin: too bad my build box "only" has 8 cores :D
<MichaelRaskin> My has 4 dual-threaded cores
<aristid> rustc seems a complex beast for sure
<MichaelRaskin> Well, its reference class is C++ compilers, I guess
<aristid> hah
<MichaelRaskin> Of course the world would be better if people just used Free Pascal Compiler for stuff where it fits.
<aristid> anyways, clickable link for the offending commit: https://github.com/NixOS/nixpkgs/commit/afc439d57b3866cb499fe68b94f969079aba7963
<aristid> the diff seems dubious
<aristid> why does he always apply a weird aarch64 patch now
<MichaelRaskin> Well, we do aim to achieve aarch64 first-class support…
<aristid> yes but it's applied on non-aarch64 platforms too
<aristid> maybe i just don't understand the reason :)
<MichaelRaskin> Erm, the commit message does explain that multi-target tools need this patch.
<MichaelRaskin> What did you check for bisecting?
<MichaelRaskin> build failure, or hash change?
<MichaelRaskin> Do you have a link to failing build logs, by the way?
<aristid> MichaelRaskin: build failure
<MichaelRaskin> Hm, test failure
<MichaelRaskin> test_inherit_env
<MichaelRaskin> Let me guess: it is nondeterministic
<aristid> MichaelRaskin: i have the log file, let me try to put it in a gist
<MichaelRaskin> (I looked up the Hydra failure)
<aristid> i will do it anyways
<aristid> then you can compare to hydra
<aristid> and see if it's the same :D
<MichaelRaskin> Yeah, comparing might be interesting
<MichaelRaskin> Well, you can grep test_inherit_env first
<aristid> MichaelRaskin: http://termbin.com/7tgx
<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…
<MichaelRaskin> gchristensen: not 2x, there are binary cache hits sometimes on master
<MichaelRaskin> aristid: that's true
<MichaelRaskin> Less reliable evidence, but still
<aristid> MichaelRaskin: i will try your suggestion anyways, don't worry :)
<aristid> well, if it's done fast enough because i need to work tomorrow so can't spend all night on this :D
<MichaelRaskin> Well, I might try it too when I finish another build
<LnL> is there a reason for things in nixpkgs to use overrideAttrs? seems weird
<MichaelRaskin> Well, we don't always have a better override mechanism
<LnL> but... it's in the same file
<LnL> n/m but still
<MichaelRaskin> OK, same file does sound like a case for extra arguments
Mic92 has quit [Quit: WeeChat 2.1]
<niksnut> gchristensen: it's not really necessary for ofborg to build master. It can get the current closure size from the hydra db
<gchristensen> oh cool, is there an API endpoint for that?
<niksnut> looks like it's not included in the /build endpoint
<niksnut> however, you can do curl -H 'Accept: application/json' https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.docker.x86_64-linux/closure-sizes
<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
<niksnut> lib/libopencv_core.so.3.4.1: …iler: /nix/store/gqg2vrcq7krqi9rrl6pphvsg81sb8pjw-gcc-wrapper-7.3.0/bin/g++ (ver…
<aristid> gchristensen: that's a big faq, where do you want me to look? :D
<gchristensen> Ctrl-F runtime
<aristid> gchristensen: ok i would consider libstdc++ to be the c++ runtime
<aristid> but w/e
<aristid> i can call it rust stdlib
<gchristensen> yeah I guess there is some, at any rate it is compiled in
<LnL> aristid: nix-store -qR $(command -v rg)
<LnL> aristid: glibc + ripgrep
<LnL> so no
<aristid> LnL: oh, the stdlib is linked statically?
Lisanna has quit [Ping timeout: 252 seconds]
<gchristensen> a bit off topic of "how do we fix the closure size"
<LnL> don't know the details of the implementation
<LnL> :)
<aristid> gchristensen: sorry :P
<gchristensen> no worries
<aristid> MichaelRaskin: so, after reverting the binutils change, rustc now fails with a different error
<aristid> in the test suite
<MichaelRaskin> inherit-env test?
<aristid> MichaelRaskin: no i can't find that in the log
<aristid> MichaelRaskin: http://termbin.com/4bi4
<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?
<MichaelRaskin> Argh it will rebuild gmp etc.
contrapumpkin has joined #nixos-dev