phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
orivej has joined #nixos-dev
lopsided98_ has joined #nixos-dev
lopsided98 has quit [Ping timeout: 276 seconds]
goibhniu has joined #nixos-dev
lopsided98_ has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-dev
<srhb>
samueldr: Did something change regarding updating of channels for nixos-18.09? I see three fully complete evaluations since the 16th that ought to have bumped nixos-18.09 by the old rules (tested succesful and evaluation complete,) but we're still on an eval from the 15th. I'm inclined to believe we're actually seeing this on all channels for at least the last month or so.
orivej has quit [Ping timeout: 252 seconds]
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
adamt has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
pie__ is now known as pie_
orivej has joined #nixos-dev
init_6 has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-dev
<samueldr>
srhb: not that I know of
<srhb>
Hm. I would love if someone could investigate this. I don't have the necessary access I'm afraid.
<samueldr>
if it's an hydra thing, I don't have more accesses...
<srhb>
Yeah, I figured. Speaking into the void of the channel. :3
<gchristensen>
srhb: what would you look at first?
<samueldr>
someone (me) did touch the channel scripts recently, something could be failing on the nixos.org server; someone with accesses may check the logs
<srhb>
gchristensen: I would look at the runs of the channel update script
<gchristensen>
link to the evalyou expected to be released?
<srhb>
Those are just the recent (but not too recent) ones, it's been going on for far longer where I couldn't find an "ah, but the eval only finished three days later" explanation
<gchristensen>
right
<srhb>
Of course, I may be missing something, in which case sorry for the noise, but I think investigating now would be prudent. :)
<gchristensen>
seemsto just be impacting 18.09?
<srhb>
Nope, but I gave up on tracking it for 18.03 a while ago. I can start doing that again.
<srhb>
it was just easy to show with 18.09 right now.
<gchristensen>
well 18.03 released yesterday
<srhb>
It's not that there's never a release
<srhb>
It's that there's often not a release when there should have been one,
<gchristensen>
and also, 18.09 does have a legit problem
<samueldr>
as for latest-finished, it points to 389.4bd5b51c3a0, which is "expected", I think
<srhb>
samueldr: Yes, and the channels ought to reflect that. But I think gchristensen just found the issue :)
<samueldr>
yep, I was just finishing the thought I had in case
<srhb>
Thanks for that :D
<samueldr>
that seems like a new thing?
<srhb>
It is
<srhb>
b8ce6a31f555a2e4471880cc4c01b629e7d6d36f
<samueldr>
and it's failing since I think
<gchristensen>
agreed... mysterious why this is failing?
<samueldr>
yeah, three days ago, 15th of september
<srhb>
Yeah I can't see it either. I suspected the weird libc // but I don't see anything obvious
<srhb>
Oh..
<srhb>
libc doesn't have a meta does it
<srhb>
The error message is just super confusing.
<gchristensen>
oh, no
<gchristensen>
the problem is x.elf-header-real.meta.outputsToInstall
<gchristensen>
[ "bin" ]
<srhb>
aaah
<gchristensen>
nix-build . -A elf-header-real.bin
<gchristensen>
error: attribute 'bin' in selection path 'elf-header-real.bin' not found
<srhb>
Great catch!
<samueldr>
this is reproducible locally yeah
<samueldr>
though, uh, could or should hydra catch those somehow and turn the build a shade of red?
<srhb>
Haha, that would be nice for sure..
<gchristensen>
it is tough, I think the failure here is in the building of the program index
<gchristensen>
maybe ofborg could catch it
<srhb>
master has the same problem.
<srhb>
I can't fix this until tonight, but I will check if no one else got it by then. Thanks for looking gchristensen :)
<gchristensen>
:) I wish these logs were publicly accessible
<srhb>
Me too.
<srhb>
I feel pretty confident in my hydra ci and surrounding architecture these days :-P
<gchristensen>
you both have excellent understandings
<gchristensen>
hmm checkMeta should probably validate each outputsToInstall value is present
<srhb>
Yeah that would be great!! :)
<adamt>
Are there any stats for the number of downloads for each package from cache.nixos.org? Just to get an idea about package popularity.
<gchristensen>
not really, no
<adamt>
Aww, but could be a fun side project
<samueldr>
downloads stats wouldn't represent things accurately since 1. the cache could be cached, 2. any customization by the end-user ends-up rebuilding stuff :/ (though doesn't mean it's statistically insignificant to know those things)
<srhb>
samueldr: The cache would probably at least be queried in 2) :)
<samueldr>
right
<adamt>
I know about those caveats. But I'm honestly wondering about whether there are packages that are basically never downloaded.
<Taneb>
I'd be surprised if there weren't
<adamt>
Like, right now I was reminded about an old PR for uprading the zabbix server from 1.8, but the intersection of people who run nixos, people who like zabbix, and people who don't mind running an ancient version of it seem abusmal, so maybe the server should just be removed entirely. :P
<simpson>
adamt: Presumably there is a power-law distribution with a long tail.
<simpson>
And then, as a consequence, *most* packages are more-or-less unused if you round down.
orivej has joined #nixos-dev
<adamt>
Yeah, sure.
<adamt>
But there's also the opposite situation; maybe it would be easier to convince oneself to fix something silly in a pkg, if you knew it was used by a gazillion people. Anyway, I just think the access logs might be interesting. :-)
<simpson>
I bet you would! But I would really like for that data to be anonymized.
<gchristensen>
if no outputs are specified, is `outputs` effectively defaulted to [ "out" ]?
<simpson>
I think so, but it might depend on the derivation builder.
<srhb>
Yes, I think go defaults to "bin" for instance
<gchristensen>
I'm thinking more at the deep down Nix level
<srhb>
Oh, you're literally talking about `outputs` and not outputsToInstall?
<simpson>
I think you're right for `mkDerivation`. That's the kind of assumption I use daily; I've been assured that `outputs` is automatically set up in a good way.
<gchristensen>
right, srhb
<srhb>
Ah
<gchristensen>
in other words, is this valid:
<gchristensen>
expected_outputs = (attrs.meta or {}).outputsToInstall or [];
<gchristensen>
actual_outputs = (attrs.outputs or [ "out" ]);
<gchristensen>
niksnut: w.r.t. the documenting deprecated aliases, what did you think about the option to have a separate varlistentry saying it is deprecated with a reference to the new option?
<niksnut>
gchristensen: yeah sounds good
<LnL>
doesn't it make more sense to replace the old variants in the nixos manual
<gchristensen>
great, will do!
<gchristensen>
LnL: yes, both I think
<gchristensen>
niksnut: would you prefer the "deprecated" entries directly below the current entry, or alphabetically sorted?
<{^_^}>
nix#2428 (by grahamc, 1 day ago, open): Document Aliases
<globin>
since, I haven't done anything with staging in some time and haven't been following the discussions on the new process, where would I push a mass-rebuild change fixing a missing header in texlive? to staging? (samueldr maybe?)