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.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<{^_^}> #21309 (by pGarlick, 1 year ago, open): `nix-instantiate --strict --eval` not terminating
jtojnar has quit [Quit: jtojnar]
<Mic92> gchristensen: v4l is single core
<Mic92> but my laptop is running out of battery
<gchristensen> ah
<worldofpeace> ugh I don't know what to do with these issues #51059 :D and the other 83
<{^_^}> https://github.com/NixOS/nixpkgs/issues/51059 (by coretemp, 2 days ago, open): Package update required: Teamviewer 13 -> Teamviewer 14
<samueldr> worldofpeace: are they technically valid?
<samueldr> those that are valid and not open-ended, and those that are actionable I think should be kept, no?
<worldofpeace> samueldr: Well there's a lot of package requests that actually have pr resolving them. I'll help merge those. Some of them I'm not sure
<gchristensen> the anser is, I think, treat them nomrall
<gchristensen> normally
<samueldr> right
<worldofpeace> Yep will do that :)
<worldofpeace> I'll just mentally separate them from the reporter with that techincal focus
<gchristensen> sounds perfect
<ekleog> any idea why hydra's setting to send mails to maintainers when a build fails has never been turned on again after it was turned off? (cc gchristensen as someone with full hydra access)
<gchristensen> no idea, I wonder if it has to do with "nrNotificationsPending" : 628450,
<samueldr> wasn't it because a failure in something like stdenv sent mail to *everyone*?
<gchristensen> we created a new channel jobset and then a lot of stuff failed "for the first time"
<samueldr> on march 11th
<ekleog> maybe it'd make sense to drop all pending notifications and turn it on again? was kind of helpful
<gchristensen> it was
<gchristensen> maybe open n issue on nixos-org-configurations?
<{^_^}> nixos-org-configurations#51 (by timokau, 16 weeks ago, open): Re-enable email notifications
<gchristensen> mind bumping it? :P
<ekleog> done :)
drakonis has joined #nixos-dev
<yl[m]> LnL: can you update https://github.com/NixOS/nixpkgs/pull/33203 I'd like to review it and get it merged
<{^_^}> #33203 (by LnL7, 47 weeks ago, open): vim-plugins: don't override default phases
<yl[m]> is staging clear? I'd like to merge https://github.com/NixOS/nixpkgs/pull/51122
<{^_^}> #51122 (by dtzWill, 1 day ago, open): networkmanager: 1.12.2 -> 1.14.4
<yl[m]> it looks like there are eval errors on staging https://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations
<yl[m]> mostly unfree and unsupported but unsure if that meets the criteria of "clean"
<yl[m]> https://hydra.nixos.org/eval/1491993 I guess it's not
pie___ has quit [Remote host closed the connection]
pie___ has joined #nixos-dev
pie___ has quit [Remote host closed the connection]
pie___ has joined #nixos-dev
<gchristensen> there have been forever
<yl[m]> gchristensen: but it says `Newly failing jobs (5559)` in comparison to the previous job
<yl[m]> smells fishy to me
<gchristensen> I mean, eval errors around unfree / unsupported
<yl[m]> oh I see. yea make sence
* yl[m] can never spell sense
<gchristensen> if you're in to stats and stuff, https://status.nixos.org/prometheus/graph?g0.range_input=1h&g0.expr=hydra_machine_type_runnable&g0.tab=0 hydra_* is a bunch of hydra stats in prom.
drakonis has quit [Quit: WeeChat 2.2]
disasm has quit [Ping timeout: 240 seconds]
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
emily has quit [Ping timeout: 252 seconds]
emily has joined #nixos-dev
hedning has quit [Quit: hedning]
worldofpeace has quit [Ping timeout: 246 seconds]
pie___ has quit [Remote host closed the connection]
pie___ has joined #nixos-dev
<andi-> gchristensen++
<{^_^}> gchristensen's karma got increased to 46
<andi-> Very nice
<LnL> gchristensen: oh, that's public now
<LnL> gchristensen++
<{^_^}> gchristensen's karma got increased to 47
<ckauhaus> heh
<ckauhaus> periklis++
<ckauhaus> oops, not online
<ckauhaus> pkg security fix hero :)
<globin> samueldr, ekleog: would you be up for shepherding https://github.com/NixOS/rfcs/pull/36 ?
<{^_^}> rfcs#36 (by globin, 6 days ago, open): Improving the RFC process
__Sander__ has joined #nixos-dev
Synthetica has joined #nixos-dev
init_6 has joined #nixos-dev
<delroth> https://github.com/NixOS/nixpkgs/issues/51221#issuecomment-442792789 opinion from people who care about Darwin?
<delroth> tl;dr: apple's implementation of ranlib makes file timestamps go backwards on APFS
<qyliss^work> woww
<init_6> NixOS support linux-4.4, 4.9, 4.14, 4.18, 4.19 kernels?
<tilpner> > deepEval [ linux_4_4.name linux_4_9.name linux_4_14.name linux_4_19.name ]
<{^_^}> error: undefined variable 'deepEval' at (string):7:1
<tilpner> > [ linux_4_4.name linux_4_9.name linux_4_14.name linux_4_19.name ]
<{^_^}> error: undefined variable 'linux_4_4' at (string):7:3
<tilpner> Okay, guess not
<tilpner> But they exist
<srhb> init_6: This is probably a question for #nixos but I think the term "support" should probably be "has packages for"
<init_6> srhb: yes.
<init_6> and thx srhb tilpner
orivej has quit [Ping timeout: 250 seconds]
<infinisil> Ahhh
<infinisil> I always mess everything up with the bot
<tilpner> infinisil - Did you see my ping about c++ incrementing "c" karma?
<{^_^}> c's karma got increased to 7
<infinisil> Yeah, need to fix that too
<infinisil> > deepEval [ linux_4_4.name linux_4_9.name linux_4_14.name linux_4_19.name ]
<{^_^}> [ "linux-4.4.165" "linux-4.9.141" "linux-4.14.84" "linux-4.19.5" ]
pie__ has joined #nixos-dev
pie___ has quit [Remote host closed the connection]
Lisanna has joined #nixos-dev
Lisanna has quit [Client Quit]
<infinisil> tilpner: Okay c is now blacklisted
<tilpner> c++ infinisil++
<{^_^}> infinisil's karma got increased to 46
<infinisil> Karma strategy: break bot, then fix it, profit :P
<Synthetica> Gotta get graham's stickers
Jackneill has quit [Ping timeout: 260 seconds]
<init_6> I have a few fun patches for all linux kernel versions. first it`s updated cko https://www.linuxpages.org/cko_en.php second zen-kernel based - additional kernel logos plus show random available logo. logos can see there https://init-6.bitbucket.io/content/2017/01/Очередное-обновление-bentoo-sources/ and finally patch which adds ISO-Latin-1 font used in apple`s XNU kernel ported with
<init_6> permission of the author of this font mr. Ka-Ping Yee to linux. how he looks can be seen there https://init-6.bitbucket.io/content/2010/10/ka-ping-yee-iso-latin-1-font-in-linux-kernel/
<gchristensen> LnL: it doesn't have quite all the same stats yet, but most of 'em yeah :D
<init_6> I'm trying to add these patches to default nixos kernel
<Synthetica> init_6: "Kernel logos?" On boot you mean? Maybe we shouldn't be providing art from random other distros and anime girls? (Plus, if I understand correctly, which isn't guaranteed, because it's in Russian(?), the same can already be achieved with `boot.plymouth.logo`)
Jackneill has joined #nixos-dev
<init_6> Synthetica: "On boot you mean?" yep. all logos from zen-kernel + old kernel logos like Tasmanian devil from 2.6.29
<init_6> there is a lot of stuff
<gchristensen> init_6: I'm not sure those patches would be accepted in to nixpkgs
<init_6> Ok for now all stuff there https://bitbucket.org/redeyeteam/patches/src/master/ All patches after 4.14 _NOT_ _TESTED_.
<init_6> plus about font - kernel side ^ there is patch + simple terminal font sources there https://bitbucket.org/redeyeteam/iso-latin-1
jtojnar has joined #nixos-dev
<ekleog> globin: up for it :)
<globin> ekleog: nice!
<gchristensen> ekleog++ wooooo
<{^_^}> ekleog's karma got increased to 5
<ekleog> woooo for you, you're the ones who wrote that RFC :p
<gchristensen> yeah but you got the harder job :)
<gchristensen> great picks, globin
<globin> gchristensen: now only have to incorporate all the comments this afternoon/evening :)
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
worldofpeace has joined #nixos-dev
<timokau[m]> Just reiterating that I really think ekleog ought to have commit access, he's one of the more active community members right now (way more active than a lot of people with access) :)
<gchristensen> domenkozar: ^
<ekleog> timokau[m]: actually got it a few days ago :°
<gchristensen> nice
<timokau[m]> Oh, didn't notice
<timokau[m]> Congrats then :) Very good to have you
<ekleog> :)
<ekleog> (and thank you for the recommendation!)
<ekleog> gchristensen: fwiw, the mac-guest are not at 100% disk but the mac-host are at 100%disk, and both -guest and -host are at 100% inodes… can't remember whether you already deployed the auto-gc stuff?
<ekleog> ce=mac8-guest&var-instance=mac8-host&var-instance=mac9-guest&var-instance=mac9-host&var-machine=All
<ekleog> (well, technically stable at 99.98%, I assume it's equivalent to 100%)
<gchristensen> "free" :)
<ekleog> oooh
* ekleog should learn how to read
<ekleog> :D
<gchristensen> :D <3
<gchristensen> ekleog: using zfs makes those appear a bit funny :)
<ekleog> hmm? I know nothing about zfs
<gchristensen> well there is no specific inode limit beyond "is there enough space on the disk to write another inode?"
<ekleog> oh ok :)
<gchristensen> and also the way the VM is stored (as a ZFS "vdev" device) it doesn't take up space on the / filesystem
<gchristensen> so from there the only thing on the / is enough of a nixos system to run qemu, which is not very much
<ekleog> nice :)
<ekleog> btw, do you know the right prometheus|grafana query to know the number of build jobs queued on darwin? there's a rebuilding since like ~27hrs, it's getting almost weird that it's still not started
<ekleog> +queued
Profpatsch has quit [Ping timeout: 246 seconds]
* ekleog waiting for rustc.x86_64-darwin to complete to trigger an ofborg build (a)
<gchristensen> so... the data in prometheus is data I haven't worked with before. when I imported it in to my personal prom, it was in a different format. let me see ...
<simpson> What are you trying to learn/graph? That's the question I ask myself when I'm at the Prom console.
<gchristensen> it also throws away a good bit of data as part of converting it from the JSON to prom -- happy to have that improved https://github.com/NixOS/nixos-org-configurations/blob/bc53abb25ad5b7a658b5961cf4aa4e79dca04fe9/delft/prometheus/hydra-queue-runner-reexporter.py
<simpson> Oh, you wrote your own. Nice. Did you consider the other JSON exporter? https://github.com/kawamuray/prometheus-json-exporter
<simpson> I suppose that it really does depend on what you want to measure.
<gchristensen> I didn't look at it :X
orivej has joined #nixos-dev
Profpatsch has joined #nixos-dev
* ekleog has 0 prometheus experience, it's kind of confusing how the data “doctype” appears to be completely hidden from the interface
<gchristensen> ekleog: http://status.nixos.org:9200/
<ekleog> oh so it's just not on status.n.o/prometheus :)
<simpson> ekleog: It's doing the right thing; you can also check /metrics
<ekleog> hmm wait, there is no hydra_builds_queued in this list
<simpson> gchristensen: Looking great! One thing to know about that isn't yet a problem: You have to pay for each *label* used, not each *dimension* declared. Another way to look at it is that scrapes have a CPU cost that is linear in the /metrics size.
<simpson> So hopefully the number of build hosts, jobsets, and machine types is very slow-growing.
<gchristensen> simpson: right, jobsets is for sure -- build hosts we might have a several thousand over six months
<gchristensen> but I think that is desirable information to record
<gchristensen> simpson: there is _much_ more information I'd like to collect -- you can see the source here: http://hydra.nixos.org/queue-runner-status -- if you have advice, I'd love it ... even better would be a PR :P
<simpson> Of course! Just a heads-up. IP addresses are one of those thing that are risky to store as labels.
<simpson> How are you estimating S3 cost, out of curiosity?
<gchristensen> hydra does it :)
<simpson> (FWIW my free advice is probably worth more, both in $$ and in usefulness. I hate writing exporters; that's why I like reusing the community code.)
<simpson> Ah. Probably not a model I can immediately borrow, then. But still worth looking into.
<simpson> Ha, awesome.
<gchristensen> that is one of the only "calculated" metrics I re-exported from the json since I'm definitely not going to reimplement that as a prom query. :)
<qyliss^work> gchristensen: fyi, I just did a multi-user Darwin install in a VM. `nix-channel --list; sudo nix-channel --list` outputs nothing
<qyliss^work> I think there's definitely something wrong there
<gchristensen> must be, I can't look in to it now, sorry :/
<qyliss^work> no worries
<simpson> Precalculation of stuff like that makes sense, too, since it results in fewer metrics exported and scraped.
<qyliss^work> Was mostly just looking for confirmation that I was right about something being wrong
<qyliss^work> Ah, I was wrong anyway
<qyliss^work> You can't do `sudo nix-channel --update` because it uses HOME
<qyliss^work> Which is preserved by sudo
<qyliss^work> That's fairly unintuitive, though... wonder if that's how it should be
<gchristensen> qyliss^work: I wonder how it "should" be too. maybe the user who installs it is in "charge" of the system, ie has the "root" profile
<gchristensen> (by "root" I mean the nix daemon comes from this user, however the profile is still named after their user)
<qyliss^work> I wonder if maybe the user who installs it should just get nixpkgs added to their own profile?
<qyliss^work> You end up with two profiles, but I think that's what I would expect from a multi-user install - one for root and one for the user?
<gchristensen> for linux yes, but for macos not sure
<gchristensen> the root account files gets blown away periodically, making it not at all a good pick
<qyliss^work> I don't think the installer should make the user who installed "special"
<qyliss^work> What is root's profile even used for?
<qyliss^work> (I don't really use profiles at all, but am motivated to try to get them to work for people coming to Nix)
<gchristensen> the nix daemon comes from it, and the profile script referenced in /etc/bashrc, and also the default NIX_PATH
<qyliss^work> The default NIX_PATH doesn't include a user's own channels ,right?
<LnL> yeah only nix-env finds those because it has weird behaviour and doesn't honor NIX_PATH
<qyliss^work> Should it?
<qyliss^work> It seems very strange that a multi-user install is actually more of a "root" install, and every user uses root's stuff.
<gchristensen> probably the thing to do is describe what it should do, see if people agree, and then implement :)
<qyliss^work> Maybe I'll write a Discourse post
<gchristensen> yes please!
<qyliss^work> I almost said "RFC" until I remembered that RFC about how RFCs don't get accepted :P
<gchristensen> let's see how the new RFC edits happen
__Sander__ has quit [Quit: Konversation terminated!]
<globin> WRT the RFC improvement RFC, I'm inclined to add the following, any comments?
<globin> " The author and co-author cannot be part of the Shepherd
<globin> Team, half of the Shepherd Team or less can also be part of the RFC Steering
<globin> Committee.
<globin> especially ping niksnut, gchristensen, zimbatm, flokli, ekleog, Ericson2314, samueldr, domenkozar, Mic92, sphalerite? ^
<domenkozar> cannot -> can also
<domenkozar> that seems a weird connection
<domenkozar> maybe just "can be part"
<domenkozar> besides nitpicking, sounds good
<globin> ah yeah makes sense
<ekleog> Same here, the idea is good but the wording weird, maybe something like “The author and co-author cannot be part of the Shepherd Team. In addition, at most half of the Shepherd Team can be part of the RFC Steering Committee”?
<globin> sounds even better, thank you!
<ekleog> :)
<Ericson2314> +1 new wording too
<gchristensen> globin: "author nor coauthor"?
<gchristensen> "neither the author or coauther can be part of ..."
<gchristensen> other part seems good!
<globin> might become obsolete if I can decide to ditch the co-author
<shlevy> Do we want to add anything about an author (or coauthor, if we keep those) recusing themselves from steering committee decisions relating to their PR?
<shlevy> (haven't seen the thread here, just saw the commit pushed)
<globin> hmm, since nomination by steering committee has to be unanimous I don't think it's necessaryy
<shlevy> Fair
init_6 has quit [Ping timeout: 250 seconds]
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
hedning has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
<globin> Please re-review https://github.com/NixOS/rfcs/pull/36 everyone! I've tried to incorporate the discussion and improve the RFC
<{^_^}> rfcs#36 (by globin, 1 week ago, open): Improving the RFC process
orivej has joined #nixos-dev
<thoughtpolice> gchristensen: Just want to thank you for ofborg, just helped me quickly find and fix a Darwin failure (I hope!)
<gchristensen> yay!
<gchristensen> LnL will be very delighted to hear that :)
<LnL> I'm not sure how you did that with the current state of master, but yay :D
<LnL> gchristensen: btw, sometime around nixcon somebody opened up a wip pr and pushed about 20 commits to fix a darwin build!
<gchristensen> :o :D
<LnL> not sure how I should feel about it, but that's some dedication
<gchristensen> I've been thinking about this, if your vm can be made disposable (daily?) and also protect your internal network, it'd be nice to open up darwin to everyone
<LnL> I use the machine to build other stuff from time to time, but I'm down for that if the load is reasonable
<LnL> for cases where I want the compute to test something I already reset it and disable the daemon for a bit
<gchristensen> nice
<gchristensen> :/ I can't find my mac on my network.
<LnL> heh
<LnL> ideally the credentials would even be rotated so it doesn't contain any long living secrets
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 250 seconds]
lassulus_ is now known as lassulus
orivej has quit [Ping timeout: 268 seconds]
<LnL> who aborted all of these trunk jobs https://hydra.nixos.org/eval/1492431
<LnL> and why are they queued in the first place?
wladmis has quit [Ping timeout: 268 seconds]
init_6 has joined #nixos-dev
init_6 has quit []
jtojnar has quit [Quit: jtojnar]