worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
<pie_[bnc]> re the whole documentation discussion...
<pie_[bnc]> has anyone talked to any archwiki people about how they have such a good wiki?
<mdash> pie_[bnc]: simple, arch attracts people who don't like systems that work all the time
<pie_[bnc]> you lost me :p
<samueldr> this is not the place to do unprovoked swipes
justanotheruser has quit [Ping timeout: 240 seconds]
<mdash> well it's not like I entirely do either, which is why i use unstable instead of 19.09
<pie_[bnc]> i just dont get what this has anything to do with documentation...
<pie_[bnc]> (need more docs if everything is broken??)
<MichaelRaskin> I guess the story is that people who are not afraid to experiment are doing experiments that are hard enough not to write them u;
<mdash> pie_[bnc]: i think it has to do with people fooling around with trying to get the most out of their hardware/environment as a hobby rather than it being a nuisance to overcome on the way to other interesting things
<mdash> just a guess
<pie_[bnc]> meanwhile, does anyone know if theres some magic env var I can set or something to start a process without window decorations?
* pie_[bnc] still working on wxpython tests
<nix-build> firing: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 260 seconds]
<gchristensen> flokli: turned out adding the rev pushed the description length too long (but I solved it) ning: description is over 140 char; truncating: "nix-instantiate --arg nixpkgs { outPath=./.; revCount=999999; shortRev=\"84f720d\"; rev=\"84f720d9a40aae4307ab40c877864f975012b2f9\"; } ./pkgs/top-level/release.nix -A darwin-tested"
<gchristensen> but mehhhh annoyin :)
orivej has joined #nixos-dev
orivej_ has quit [Ping timeout: 258 seconds]
v0|d has quit [Read error: Connection reset by peer]
v0|d has joined #nixos-dev
justanotheruser has joined #nixos-dev
<ryantm> nixpkgs-update has a new source of versions thanks to jonringer: Pypi
<ryantm> Here's the first PR https://github.com/NixOS/nixpkgs/pull/83818
<nix-build> #83818 (by r-ryantm, 7 minutes ago, open): you-get: 0.4.1410 -> 0.4.1432
<gchristensen> oh cool!
teto has quit [Ping timeout: 272 seconds]
Jackneill has quit [Ping timeout: 250 seconds]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
<gchristensen> took like a week's time to get it all working together right after I decided to stop storing state on the build host :x
<drakonis> awesome
<drakonis> how's the stats?
<gchristensen> we'll find out in some number of hours :)
<drakonis> nice.
<gchristensen> it'll publish to here: https://r13y-com.s3.amazonaws.com/index.html and once it does I'll update r13y.com to refer to those files
<gchristensen> and given the stats already there ... https://gsc.io/snaps/1b19bd88-0a66-4fea-a9a7-d650492d2418.png
Jackneill has joined #nixos-dev
init_6 has joined #nixos-dev
init_6 has quit []
<ryantm> I didn't know 20.03 was going to be such a minimal release.
<gchristensen> haha
<julm> why 6 paths only?
<julm> it's building?
<gchristensen> because it is much faster to iterate and test when it builds 6 paths than 1,580 paths
<gchristensen> so I reduce it to an ultra-minimal set while I do that, and then expand it to the larger set
<julm> ah ok
<julm> ooooh ok :)
<nix-build> firing: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
<nix-build> resolved: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
drakonis has quit [Quit: WeeChat 2.7.1]
avn has quit [Read error: Connection reset by peer]
avn has joined #nixos-dev
lovesegfault has quit [Ping timeout: 252 seconds]
lovesegfault has joined #nixos-dev
Cale has quit [Ping timeout: 256 seconds]
rsa has quit [Ping timeout: 256 seconds]
<julm> while I'm at writing a fix to nixos/modules/services/backup/sanoid.nix (which generates a bogus configfile) I'm wondering if there is a rationale for using CamelCase for options which are direct mapping to sanoid options which use snake_case? eg. use_template becomes useTemplate in NixOS. I'd personnaly prefer to stick to the original, but what's the policy?
Cale has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
cole-h has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
__monty__ has joined #nixos-dev
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
lassulus has quit [Ping timeout: 258 seconds]
lassulus has joined #nixos-dev
lovesegfault has quit [Ping timeout: 272 seconds]
<flokli> gchristensen: I assume it'll be too long if it were all zeroes too :-D
niksnut has quit [Remote host closed the connection]
<rnhmjoj> julm: if it's not too late.. i know at least of the matrix-synapse module, which keeps the original snake_case names. there are also the module.settings options from RFC 0042. personally i don't like having different options styles but keeping the original also has value.
<julm> rnhmjoj: thanks!
<julm> I'll try to justify to keep the original names because it makes the code simpler (no mapping to be done before supplying the attrset to toINI)
<rnhmjoj> julm: if you are doing a 1:1 map of options, yes, i would keep the original names
rsa has joined #nixos-dev
<jtojnar> can we deploy https://github.com/NixOS/hydra/commit/76299b9174d7cba06427220166dc4707b43d407d now that it has been merged?
niksnut has joined #nixos-dev
<jtojnar> niksnut^
<niksnut> ?
<tilpner> niksnut: jtojnar wants to deploy https://github.com/NixOS/hydra/commit/76299b9174d7cba06427220166dc4707b43d407d , now that it has been merged
<tilpner> jtojnar: niksnut only joined after your message, but you probably can't see that on Matrix
<jtojnar> Matrix for some reason does not see Eelco's IRC account
<jtojnar> hmm, I have him in ignored users for some reason
teto has joined #nixos-dev
<niksnut> tilpner: done
<niksnut> I also upgraded the server to 20.03
<tilpner> jtojnar: ^
<niksnut> Segmentation fault
<niksnut> $ sudo -i
<niksnut> weird
Guest62967 has quit [Changing host]
Guest62967 has joined #nixos-dev
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 246 seconds]
Mic92 has quit [Quit: WeeChat 2.7.1]
Mic92 has joined #nixos-dev
teto has quit [Ping timeout: 246 seconds]
teto has joined #nixos-dev
mjsir911 has quit [Quit: Goodbye, World!]
mjsir911 has joined #nixos-dev
FRidh has joined #nixos-dev
FRidh2 has quit [Ping timeout: 256 seconds]
<rnhmjoj> niksnut: now i'm scared of upgrading
<gchristensen> fwiw I had bash trip an assert on 19.09 yesterday, and no such problems on 20.03 :P
<Ericson2314> niksnut: https://github.com/NixOS/nix/pull/3455#discussion_r400535408 made the other changes you requested but wasn't sure on the names. Want to go with one of those anyways? Or do the `FileHash` thing right away in this PR rather than a future one? Also, I'm happy to extend my offer of merging master back into flakes after one of those PRs to after any of them.
<niksnut> rnhmjoj: I think it's related to pam_ssh_agent-auth
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 256 seconds]
johnny101 has joined #nixos-dev
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-dev
das_j has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
lovesegfault has joined #nixos-dev
cole-h has joined #nixos-dev
drakonis has joined #nixos-dev
<jtojnar> thanks Eelco.
<jtojnar> Though I still do not see why is https://hydra.nixos.org/jobset/nixpkgs/staging-next#tabs-errors failing
<jtojnar> Perhaps `error: unexpected EOF reading a line` is really the issue
<samueldr> also looking, that's weird
<samueldr> it does affect -small too, which may help in figuring out
ixxie has joined #nixos-dev
<samueldr> alright, so it looks like 9157ff4e746140960ff554ccd6fd4cf4284dba4a, current tip of master recently, does evaluate on my setup...
<samueldr> I'm confused
<lovesegfault> Is hydra still borked for trunk-combined?
<drakonis> ah, r13y has only improved by 0.02%
bgamari_ has quit [Ping timeout: 240 seconds]
abathur has quit [Ping timeout: 260 seconds]
<samueldr> :/ I really can't reproduce the failure for unstable-small
FRidh has joined #nixos-dev
FRidh2 has quit [Ping timeout: 256 seconds]
__monty__ is now known as SirJection
SirJection is now known as __monty__
<pie_[bnc]> So I'm workin on a PR and I've got some weird python issue; deeplabcut depends on a version of opencv compiled with ffmpeg, which nixpkgs doesnt do by default, so I do buildInputs = [ ... opencv3.override { enableFfmpeg = true; } ];
<pie_[bnc]> deeplabcut imports cv2, and if it doesnt have ffmpeg, an open call will fail and a test will fail with a None error
<pie_[bnc]> but the override doesnt work, i have to use an overlay to get it to work properly, and I cant figure out why orthogonal dependencies would influence this
<pie_[bnc]> which is to say, i figure the overlay is overriding opencv in other dependencies too, but afaict the other dependencies shouldnt influence this error
<pie_[bnc]> if nothing else, anyone have any ideas what direction I should look in?
<pie_[bnc]> this is where the failure originates https://github.com/AlexEMG/DeepLabCut/blob/bcef8c961ed27a5fc8f947ef97b29a466e3f371a/deeplabcut/create_project/new.py#L156 (but the actual error happens later)
<pie_[bnc]> (hmm... i wonder if it looks like the same error but isnt)
<pie_[bnc]> (yep its the same error...)
<pie_[bnc]> FRidh: so yeah we figured out the probable fix (re packageOverrides), but I don't understand why it's broken in the first place
<andi-> Are the tests in the nixops-hetzner repo supposed to be executable via the provided `dev-shell`?
<gchristensen> probably ideally yes, and let's make it that way, and also if it can be done -- let's find a way to run them in CI automatically -- I can help with an account and a way to run them
<andi-> Yeah, I was thinking about that but right now I don't even know how that dev environment is supposed to work. It seems to require nixops.statefile which is obviously not part of that repo
<gchristensen> it has possibly not worked since the pluginification
<gchristensen> andi-: maybe you could test my poetry docs? :)
<andi-> gchristensen: link?
<gchristensen> looking
<gchristensen> andi-: https://github.com/NixOS/nixops/blob/c87dae789babbe4e08ea61a2175c891bf39186d1/doc/plugins/authoring.rst the one change is point to nixops = {git = "https://github.com/adisbladis/nixops.git", rev = "poetry2nix-plugins"}
<andi-> gchristensen: alright, gonna give it a try
<gchristensen> yay!
bgamari has joined #nixos-dev
<andi-> gchristensen: argh, this was a trick! I now also have to migrate it to python3 :P
<gchristensen> it shouldn't be too hard!
<gchristensen> use mypy, let mypy guide you
<gchristensen> andi-: I can help!
<andi-> gchristensen: I'll let the force^Wmypy guide me ;)
<gchristensen> besides once its py3 we can test it with the new statefile backend PR... :)
<andi-> One step at a time ;)
<andi-> gchristensen: > Because nixops-hetzner depends on nixops (*) which doesn't exist, version solving failed. with a basically a copy of your example and s/neatcloud/hetzner/
<gchristensen> you used nixops = {git = "https://github.com/adisbladis/nixops.git", rev = "poetry2nix-plugins"} instead of NixOS/moster and rev = "master" right?
<andi-> m(
<gchristensen> "moster"
<andi-> I have enlarged my IRC terminal.. It was breaking lines in all weird ways.. I blame that ;)
<gchristensen> :D
<gchristensen> adisbladis: ^ suckering another in to this
bgamari has quit [Ping timeout: 256 seconds]
<gchristensen> s/suckering/...
<pie_[bnc]> ok I think I kind of figured out (again) my python problem. the python infra puts everything in pythonpath and if you have multiple versions of a package the first one in the path wins
<andi-> adisbladis, gchristensen: while the locking works the fetcher fails since it is not on the master branch and probably fetchGit isn't told the branch name?
<andi-> I'll just set an override for now
<jtojnar> is it okay if I try to hydra-eval-jobs on the arch64 community box?
<gchristensen> ah adisbladis has a patch for that in poetry2nix master, but probably hasn't landed in your rev
<gchristensen> jtojnar: of course :)
<adisbladis> gchristensen: Moster == aunt (on the moms side) in swedish :)
<gchristensen> nice
<andi-> gchristensen: I think it kinda works.. minus all the overrides I had to apply to nixops: format = "pyproject" & adding poetry to the buildInputs
<andi-> adisbladis: ^
<adisbladis> [git rev patch]: I pushed that to nixpkgs master on friday, so very possible andi- doesn't have it
<adisbladis> andi-: Yeah that's a UX wart :/
<andi-> I am using latest poetry2nix from the community repo
<adisbladis> I don't know what the solution is
<gchristensen> ie: as documented?
<gchristensen> or differently?
<andi-> gchristensen: exactly like that.. I should have read the entire doc first :D
<gchristensen> oh man okay
<gchristensen> cool
<gchristensen> can you make sure you didn't have to do anything else to succeed?
<gchristensen> ie if you'd followed it step by step, would it have worked?
<adisbladis> andi-: gchristensen: I'm open to suggestions how to obviate the need
<adisbladis> FRidh: I'd really like it if we didn't have to pass `format = "pyproject"`
<andi-> adisbladis: shouldn't poetry know what type the project is when locking?
<andi-> s/type/format/
<adisbladis> andi-: Nope. In fact when you publish an sdist tarball with poetry it generates a setup.py
<adisbladis> So it's generally not required
<andi-> gut in this case as it isn't a proper sdist
<andi-> *but
<andi-> complicated :/
<adisbladis> I think we could make nixpkgs auto-detect setuptools/pyproject instead of having them as completely separate things
<adisbladis> I'd love it if FRidh could chime in =)
<andi-> Can't we have a setupHook in poetry that generates the setup.py if it doesn't work?
<andi-> s/work/exists/
bgamari has joined #nixos-dev
<adisbladis> Possibly :) Interesting idea.
<adisbladis> Though poetry is not the only thing using pyproject, so it wouldn't be universally applicable
<adisbladis> A git dependency does could use another build system like flit
<adisbladis> (Man python is a mess)
<andi-> I just wanted to hack a bit on adding proper v6 support to nixops.. This is a big rabbit hole..
<adisbladis> andi-: Just add some overrides for now and let me worry about it
<andi-> Yeah, that is what I did
<adisbladis> Don't go too deep down this rabbit hole :) It's seemingly endless
<gchristensen> yeah, let's stick to nixops ^.^
<andi-> well I only have like 2h left so can't got that deep :P
<gchristensen> I bet you can't get nixops-hetzner all pluginified and py3'd by the end of that ( o_o)
<andi-> I'll try to get this cleaned up on a way that I feel not as bad opening a PR with the current state ;)
<flokli> gchristensen: are you challenging andi- here? ;-)
<adisbladis> Hm, I wonder if we actually can't _always_ use pipBuildHook
<adisbladis> And get rid of setuptoolsBuildHook
<gchristensen> andi-: :D
<adisbladis> pip already uses setuptools behind the scenes by default and does the right thing in regards to PEP-517 (pyproject.toml)
<gchristensen> flokli: who, me? haha
<andi-> if flokli wouldn't be quarking in my ears that would be more feasible :P
<flokli> andi-: fixed that for you
<andi-> m(
<gchristensen> andi-: also feel free to `black` nixops-hetzner :)
<andi-> gchristensen: soon(tm), double checking the nix setup works as expected
<gchristensen> cool
<andi-> the tests look kinda useless :/
<gchristensen> oh?
<andi-> at least the python tests, haven't opened the nix files there yet
<andi-> gchristensen: https://github.com/andir/nixops-hetzner/commit/a857c3f5df2ab8f1a8c5082b21f093ecc5bff438 now to the "fun" part with black etc..
<gchristensen> nice!
<andi-> Is there a nice way to use github actions through nix without touching yaml? :D
drakonis has quit [Ping timeout: 240 seconds]
klys has quit [Quit: Lost terminal]
<gchristensen> andi-: nice, green tests :D
<andi-> gchristensen: 0/0 = 100%, right ? :)
<gchristensen> surrre
<worldofpeace> Jan Tojnar: what changes are needed exactly for https://github.com/NixOS/nixpkgs/pull/83245 ? I don't know C++ at all
<adisbladis> andi-: Something something the best kind of correct
<matthewbauer> has anyone else noticed the macOS builders occasionally garbage collect active inputs:
<matthewbauer> ? They work after a retry, but somehow Nix must not be registering those locks correctly.
<gchristensen> I _think_ those macs might still be using min-free max-free, which has a bug there
<matthewbauer> ah ok
ixxie has quit [Ping timeout: 256 seconds]
<gchristensen> matthewbauer: can you open a PR to nixos-org-configurations removing them?
<LnL> hmm, is that a known issue? I'm only aware of problems related to IFD
<gchristensen> we had to disable it on other builders I think
<gchristensen> clever knowsn the details I'm sure
<matthewbauer> we also run out of space a lot, so who know which is safer
<gchristensen> we do?
<matthewbauer> at least the mac's used to, maybe the new ones have bigger driver
<gchristensen> last week we were running out of space a couple macs a day, but I think that has been fixed
<gchristensen> actually the macs run with an artificially small hard disk available to them, like 128G vs. the full 256 or even 512G
<clever> gchristensen: when min-free base collection starts, it computes how much to delete until it reaches max-free, then begins the gc
<FRidh> adisbladis: my intention when I rewrote buildPythonPackage as hooks was that longer term we would not have any default, that is, one would always have to include one of the build hook. Although if long-term pyproject is accepted widely it could maybe become the default.
<clever> gchristensen: the gc then grabs a file-lock for gc, and begins its work
<FRidh> I don't like heuristics, I think this should be declarative.
<LnL> the advantage of min-free/max-free it that it runs when necessary
<clever> gchristensen: the biggest bug in this region, is that a second gc cycle can compute the same number of bytes needing to be deleted, then start a 2nd gc, which blocks on the same lock
<clever> LnL: which results in N GC's being queued up, that all want to delete M bytes
<niksnut> I think I fixed the min-free/max-free bug
<gchristensen> clever: it seems, though, that in-progress builds are having its dependencies GC'd out from under them?
<niksnut> maybe the macs have an old nix version?
<gchristensen> niksnut: oh cool, what rev was the first ones to have the fix?
<clever> gchristensen: ah, ive rarely seen that, it hasnt happened recently
<gchristensen> ah
<niksnut> e349f2c0a370e4dfd09ae51c2cae4db08a834ad5
<gchristensen> oh!
<gchristensen> right, that one
<matthewbauer> gchristensen: here's the pr https://github.com/NixOS/nixos-org-configurations/pull/108
<nix-build> nixos-org-configurations#108 (by matthewbauer, 26 seconds ago, open): Remove min-free and max-free from darwin configuration
<matthewbauer> noticed that shrb has one for enablning it everywhere: https://github.com/NixOS/nixos-org-configurations/pull/61, probably a good idea once the fix is in (and I much prefer having linux and darwin to just darwin)
<nix-build> nixos-org-configurations#61 (by srhb, 1 year ago, open): Automatic GC if we drop low. Limits debatable...
<gchristensen> ahh the macs are pinned to 2.2.2 right now. matthewbauer before I merge that, let's test a newer verion
<FRidh> adisbladis: and about pipBuild versus setuptoolsBuild. Yes, I think it may indeed be possible to use pipBuild, but should check the passing in of arguments for setuptools whether that still functions. There was a PR regarding that that got merged before the rewrite but I don't think I considered that anymore when rewriting.
<FRidh> also, I was thinking of getting rid of a default checkPhase as well considering fewer and fewer packages use that method
<matthewbauer> gchristensen: ok
<matthewbauer> LnL: btw, i wondered if you had an idea for how to fix https://hydra.nixos.org/build/114708338/nixlog/1/tail. I was wondering if https://github.com/NixOS/nixpkgs/blob/a3ee24b2ff0ccf8026fa84d5f7a9f8b3675b248a/pkgs/development/compilers/gcc/builder.sh#L252-L260 may not be necessary anymore. Otherwise we need to check for stubs apparently
<gchristensen> matthewbauer: I don't suppose you could look in to the issue preventing a 20.03-darwin channel from being created?
<LnL> gchristensen: not having the macs run down to 0% from time to time might also partially explain the stability of the builders
<gchristensen> LnL: hmm, what do you mean?
<matthewbauer> gchristensen: ugh unfortunately not very well, my macbook is back in nyc
<matthewbauer> gchristensen: is it caused by this: https://hydra.nixos.org/build/115579797/nixlog/1/tail
<LnL> the hangs, etc. darwin doesn't like running out of disk space
<gchristensen> ack
<gchristensen> ah
<samueldr> stating my observations
<samueldr> unstable-small fails on hydra
<samueldr> on my machine the hydra evaluator passes
<LnL> gchristensen: I think it's just this one https://github.com/NixOS/nixpkgs/pull/74942
<nix-build> #74942 (by burke, 16 weeks ago, open): itstool: fix double-shebang issue on macOS
<gchristensen> ehh nixops deploy -d buildfarm --include mac3 --build-only --show-trace -> error: stack overflow (possible infinite recursion)
<samueldr> I... had that on a mobile nixos build... then it went away o.O
<samueldr> I did pull nixos-unstabl when it went away
<samueldr> but I don't know what revision of nixpkgs it was that failed that way
<samueldr> did a pull and *then* it went away**
<srhb> Is it the unclean git repo thing? With respect to construction of the version suffixes and stuff?
<srhb> That always gets me
<gchristensen> srhb: say more? :) not sure ...
<LnL> matthewbauer: that's pretty old so might not be needed anymore if proper install_names are set now, otherwise try fixDarwinDylibNames
<LnL> matthewbauer: if should already filter those out properly IIRC
<matthewbauer> LnL: ok, I’ll give it a try next time I have a chance
<srhb> gchristensen: Oh sorry, this is not nixpkgs. Probably not relevant. It usually happens to me with nixpkgs working copy, I have to stick some arbitrary string in .version or .version-suffix to get it to go away, I don't recall exactly.
<gchristensen> ah
<matthewbauer> LnL: does mic92’s fix the shared mime info thing?
<matthewbauer> On #74942
<nix-build> https://github.com/NixOS/nixpkgs/pull/74942 (by burke, 16 weeks ago, open): itstool: fix double-shebang issue on macOS
<gchristensen> niksnut: would you mind taking a look at the stack overflow on bastion from «nixops deploy -d buildfarm --include mac3 --build-only --show-trace»? I'm looking in to an ofborg problem
<LnL> matthewbauer: haven't really looked at it, I assume that avoids double wrapping which would be that way to go rather than using env IMHO
FRidh has quit [Quit: Konversation terminated!]
<niksnut> try ulimit -s 50000
<niksnut> gchristensen: ^
<nix-build> nix#3462 (by edolstra, 11 hours ago, open): Stack overflow in Derivation::unparse()
<gchristensen> niksnut: that got me further, but I got "unexpected end-of-file" while evaluating the attribute 'buildCommand' of the derivation 'options-docbook.xml' at
<niksnut> yes, that's the daemon segfaulting on the same issue
<gchristensen> heh nice
<niksnut> oh, other workaround: set documentation.nixos.enable = false;
<gchristensen> testing
<gchristensen> cool, looks to be working, thanks!
<samueldr> since it doesn't fail on unexpected EOF on my build machine, can I give store paths to things to help figure out the issue?
<samueldr> sounds like the nix daemon running may be relevant
<samueldr> if it is, /nix/store/nk4px4bjp0kiss27n5dyrwsj9xgflwhp-nix-2.3/bin/nix (be back soon)
<gchristensen> mac3.........> waiting for the machine to finish rebooting...[down].................................
<gchristensen> samueldr: I am sorry that I don't know how to help you debug this :/
<gchristensen> nixops deploy -d buildfarm --include mac{1,2,4,5,6,7,8,9} --force-reboot
abathur has joined #nixos-dev
<samueldr> (sorry, had to run an errand)
<samueldr> I'm trying to figure out the issue that's currently halting evals
<infinisil> Oh damn, steam is broken in 20.03, because of https://github.com/NixOS/nixpkgs/issues/33106
<nix-build> #33106 (by srhb, 2 years ago, open): chrootenv: breaks when root contains broken symlink
<samueldr> now I'm thinking I should try and run using nix-2.4pre20200330_3e7aab8 as nix-daemon to see if it reproduces
<infinisil> Steam is used by so many people, I want to mark is as a blocker
<infinisil> Well actually not exactly that issue
<infinisil> Huh, there was https://github.com/NixOS/nixpkgs/pull/83486 a couple days ago, seemingly indicating that steam works for nyanloutre
<nix-build> #83486 (by nyanloutre, 4 days ago, merged): Steamrt update
<infinisil> But when I run steam I get `** (process:16767): ERROR **: 22:12:58.081: bind: g_dir_open: No such file or directory[1] 16763 trace trap (core dumped) result/bin/steam`
<rnhmjoj> what happened to ofBorg? the pulls tab is so dull without all the colored tags
<infinisil> It works with the change in https://github.com/NixOS/nixpkgs/pull/55973, which switches to bwrap (as a resolution for https://github.com/NixOS/nixpkgs/issues/33106)
<nix-build> #55973 (by illegalprime, 1 year ago, open): build-fhs-userenv: change to using bubblewrap over chrootenv
<nix-build> #33106 (by srhb, 2 years ago, open): chrootenv: breaks when root contains broken symlink
<infinisil> It works *for me*
<cole-h> rnhmjoj: gchristensen is looking into it
<cole-h> or was
<gchristensen> still am, sorry
<cole-h> All good, just didn't want to misrepresent
<ryantm> and nixpkgs-update has been dutifully waiting 17 hours for OfBorg to be ready :)
__monty__ has quit [Quit: leaving]
<gchristensen> thansk ryantm
<gchristensen> _sigh_ annoying problems are annoying :P
<rnhmjoj> also the hydra evaluations are failing.. today is a bad day for nixos
edwtjo has quit [Ping timeout: 250 seconds]
<gchristensen> a bit of a messy day :)
<rnhmjoj> it's a reminder of how important ofBorg is for nixos development. thank you, graham for making it
<qyliss> gchristensen++
<nix-build> gchristensen's karma got increased to 243
<cole-h> gchristensen++
<nix-build> gchristensen's karma got increased to 244
<rnhmjoj> gchristensen++
<nix-build> gchristensen's karma got increased to 245
justanotheruser has quit [Ping timeout: 256 seconds]
<julm> gchristensen++
<nix-build> gchristensen's karma got increased to 246
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
evanjs has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
<ryantm> gchristensen++
<gchristensen> thanks :)
<nix-build> gchristensen's karma got increased to 247
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
klys has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Client Quit]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<gchristensen> okay ofborg now labels issues with ofborg-internal-error like this: https://github.com/NixOS/nixpkgs/labels/ofborg-internal-error if it can't make progress, as a last resort. all problems are reported as github commit status markers, but if it can't do that for some reason, it sets thsi label
<ekleog> gchristensen: about ofborg labelling, got a second for reading https://github.com/NixOS/ofborg/issues/368 ? :°
<nix-build> ofborg#368 (by Ekleog, 41 weeks ago, open): Build passthru.tests automatically along with the package
<ekleog> (shameless plug)
<gchristensen> this PR was causing a crash in ofborg, at some point ofborg was setting a status a zillion times on this PR until it couldn't set any more due to github API limitations, and then once it hit that limit, ofborg would panic any time it tried to evaulate the PR. that meant at least one worker was always trying to work on this PR, gumming up the works and preventing progress
<nh2> Is Hydra not building master currently?
<ekleog> wait I wanted to link the PR at https://github.com/NixOS/ofborg/pull/410 ; sorry
<nix-build> ofborg#410 (by Ekleog, 22 weeks ago, open): nixpkgs-rs: build .passthru.tests too
<gchristensen> sorry ekleog, I'm 2h late for dinner, I will try and take a look soon
<nh2> is the Hydra stop https://github.com/NixOS/nixpkgs/issues/83647 ? I can't quite tell
<nix-build> #83647 (by FRidh, 2 days ago, open): Evaluation error is blocking jobsets
<ekleog> gchristensen: no problem, and thank you for all you do already! :D
orivej has joined #nixos-dev
<cole-h> gchristensen++ When one single PR can bust the entire eval infra... :(
<nix-build> gchristensen's karma got increased to 248
<gchristensen> cole-h: my biggest regret in writing ofborg (my first _real_ rust project) is being lazy with errors an using .expect() and .unwrap() a lot of places, insted of returning errors up the chain properly. that makes it hard to add them later, and really makes it hard to improve. that is why such a simple fix took a few hrs :) I've learned a lot about rust since
<cole-h> Is removal of expect and unwrap something that would be helpful? I have a little bit of Rust experience I could toss your way if that's the case...
<gchristensen> if you could do very small improvements along those lines at first, that would be helpful
drakonis has joined #nixos-dev
<cole-h> 👍 I'll give it a shot. Would a tracking issue for removal/replacement of all unwraps/expects be helpful?
<gchristensen> cool
<cole-h> "all"
<gchristensen> up to you :)
<gchristensen> another thing that would be helpful is using slog for logging instead of the badness that is there now. if you need an example of how to set that up, lorri uses slog (also #nixos-borg is a channel :)) once I get some dinner going, I'm going to bring up a few more evaluators to work through the backlog
* cole-h adds -borg to autojoins
<cole-h> Can't guarantee any speed, but I'll do some investigation/etc on this
<gchristensen> any cleanup PRs you send would be appreciated :)
<cole-h> (and will file a tracking issue so others can help out if they're bored as well)
teto has quit [Ping timeout: 272 seconds]
<Profpatsch> gchristensen: slog does not play well with some environments (e.g. eshell), though I guess that’s not a problem wtih ofborg
<cole-h> I wonder if that's something that upstream should be notified of (if they aren't already aware)?
<gchristensen> aye, probably not :) though slog has a bunch of backends, there are probably eshell-compatible outputs
<Profpatsch> I guess it comes down to: is your logging output so much that a simple printf syscall influences the speed of your program
<gchristensen> eh?
<Profpatsch> slog does some jumping around with mutexes in order to avoid logging every record immediately
<Profpatsch> at least that was my impression
<gchristensen> heh, that must be the async output backend. there are some direct output backends
<gchristensen> afaik
<cole-h> I think (after familiarizing myself a little bit) I'll try to rip out unwraps/expects on a file-by-file basis. Should make it slightly easier to review, if not to parallelize contributions
<gchristensen> cole-h: sounds good. whatever works for you works for me. try to focus on making the changes as easy to review as possible :)
* cole-h adds spaghetti code
teto has joined #nixos-dev
ekleog has quit [Quit: WeeChat 2.7.1]
orivej has quit [Ping timeout: 265 seconds]
<gchristensen> okay, not 1 PR, but 2-3 PRs :P
ekleog has joined #nixos-dev
<adisbladis> I think I managed to remove the need for `format = "pyproject"` :)
<gchristensen> nice!
<gchristensen> how?
<adisbladis> With some customisations to pipBuildHook I no longer need to default to setuptools
orivej has joined #nixos-dev
<gchristensen> nice
<nix-build> nix-community/poetry2nix#79 (by adisbladis, 38 minutes ago, open): Automatically build most packages without passing format param
<gchristensen> cool :D
<andi-> gchristensen, adisbladis: Any recommendations on how to setup mypy (in a shellHook?) so it is happy about all the nixops typings? So far I did set MYPYPATH manually but that does feel so wrong and throws me back years when I battled that before..
<gchristensen> oh! ys
<adisbladis> andi-: That was fixed by https://github.com/NixOS/nixpkgs/pull/82453
<nix-build> #82453 (by adisbladis, 2 weeks ago, merged): Python: introduce NIX_PYTHONPREFIX in order to set site.PREFIXES
<gchristensen> nix-shell, poetry install, poetry shell, mypy nixops
<gchristensen> nix-shell, poetry install, poetry shell, mypy nixops_hetzner
<adisbladis> In the case of virtualenv (poetry shell) that always worked, but with NIX_PYTHONPREFIX it also works with mkPoetryEnv (python.withPackages)
<andi-> interesting.. I am on 3320a06049fc259e87a2bd98f4cd42f15f746b96 (~26th of march) and it just complains even within the nix-shell
<gchristensen> maybe I don't setup nix-shell right in my docs?
<andi-> I'll call it a day anyway, I pushed a few f-stringifying things to the branch as as well as some typing that wasn't too painful to figure out
<gchristensen> nice :D way to go, thank you andi-! I'll take a look
<andi-> the CI is still missing a mypy stage but that is just a matter of figuring this issue out