<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?
<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
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
<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
<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]>
(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: 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
<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
<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
<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?
<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
<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 :/
<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
<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
<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
<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
<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..
<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