lopsided98 has quit [Remote host closed the connection]
mbrgm has quit [Ping timeout: 248 seconds]
lopsided98 has joined #nixos-dev
mbrgm has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
drakonis has quit [Remote host closed the connection]
orivej has joined #nixos-dev
__Sander__ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
zarel has joined #nixos-dev
zarel has quit [Ping timeout: 248 seconds]
zarel has joined #nixos-dev
<Mic92_>
How does haskell maintainers handle backports in nixpkgs?
<Mic92_>
*do
<Mic92_>
I am asking because we might want to reconsolidate how rust crates are handled.
<Mic92_>
If we have one large crate set we build our rust application from, we might loose the ability to cherry-pick updates.
s33se has joined #nixos-dev
<gchristensen>
I'm feeling there are a lot of expectations on me, and I can't satisfy them all. anyone have ideas on what I could pass off to people, and who I could pass things off to, in order to not be a blocker for people?
<MichaelRaskin>
Can any of other ofborg committers deploy config changes?
<MichaelRaskin>
Maybe there should be an ofborg-runners team (with builder operators included), so that «what the hell is ofborg doing» doesn't default to going towards you
<gchristensen>
a great idea
<gchristensen>
I'll need to commit some stuff, figure out how to use git-crypt, and then I could add some people
<gchristensen>
are you interested in being Member #1?
<MichaelRaskin>
There are issues where your judgement is sought (you have made yourself quite a name as a diplomat, I guess), and there are technical issues which are blocked on you because you own the server with a critical thing, and then there are things that should go to a wide team of qualified people.
<MichaelRaskin>
I would prefer being #2 — after LnL
<gchristensen>
:D
<MichaelRaskin>
I mean, I have no commit rights and I have only contributed documentation to the repo
<gchristensen>
yeah, I quite like being involved in all three of those things, and like pushing as much in to the third category as possible
<MichaelRaskin>
I guess ekleog has read much more ofborg code than me, too
<gchristensen>
it is a balance of people who know the code but also more importantly that I trust to not bankrupt me by accidentally making a lot of expensive servers
<MichaelRaskin>
Well, ofborg-experts, ofborg-committers, ofborg-builder-operators and ofborg-full-admins could be different sets
<gchristensen>
yeah truee
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
<MichaelRaskin>
I think ofborg cannot provision itself, so the financial risk comes only around admin access
<LnL>
I've not really used my commit bit yet, since it's currently sill a bit more of a merge + deploy workflow
<gchristensen>
ok well we should do that then
<MichaelRaskin>
I am not sure I should get full access before actually writing some Rust code for ofborg (in the sense of being able to debug my own mistakes in case of… something)
<MichaelRaskin>
And I don't do that much stuff around Nixpkgs for the last, dunno, year or so
<gchristensen>
well let's get to where ever we need to be to do it :P
<gchristensen>
also it doesn't have to be you two. it could be other people
<NinjaTrappeur>
gchristensen, is there anything non-trusted member could do to offload you a bit?
<gchristensen>
I don't know :')
<MichaelRaskin>
Yes
<MichaelRaskin>
If you create a team ofborg-questions, explaining new contributors the gotchas and limitations of ofborg could go to a team
* gchristensen
delegates delegation to MichaelRaskin
<gchristensen>
that is a great idea
<MichaelRaskin>
I think any ofborg-related teams still have to be created or requested by gchristensen
<MichaelRaskin>
I just notice pings about ofborg behaviour, and often I can easily answer them. But I don't read _all_ the GH updates for Nixpkgs
<NinjaTrappeur>
MichaelRaskin, Alright, I'll dive in ofborg a bit first, I don't really know how it operates.
<gchristensen>
LnL: what would it take for you to feel comfortable deploying ofborg? (do _you_ feel overloaded?)
<MichaelRaskin>
I don't know too much of the internals either
<MichaelRaskin>
NinjaTrappeur: if you are ready to dive inside, you could try to make ofborg fuly nix-buildable, and maybe even script a mock deployment for tests — that seems needed eventually, the changes will require a lot of review, but this review is still less work than debugging
<MichaelRaskin>
I think right now the process goes «I want to contribute to ofborg» → «gchristensen spends half an hour giving a brief overview of how to test the changes»
<LnL>
gchristensen: I wouldn't mind that, but the rabbitmq parts are still a bit scary for me
<gchristensen>
yeah that sucks, MichaelRaskin
<gchristensen>
LnL: the worst thing that happens with rabbitmq is the messages get lost
<MichaelRaskin>
NinjaTrappeur: full nix-buildability shouldn't even require setting up the test environment (and is a prerequisite to some nice things)
<gchristensen>
fwiw, it is nix-buildable. the deployment is done via nix-build
<MichaelRaskin>
Is the «cargo build» part of builder operator manual obsolete?
<NinjaTrappeur>
MichaelRaskin, alright, sounds good. I'll finish my ongoing work on the nix parser (https://github.com/NixOS/nix/issues/1374) and will jump on that. I'll probably start that by next Monday.
fpletz1 is now known as fpletz
<gchristensen>
hmm possibly so ...
<NinjaTrappeur>
oh
<LnL>
gchristensen: but getting to the point where a few people can deploy eg. known_users is a good first step
<gchristensen>
ok, cool
<gchristensen>
do I have a GPG key for you?
<MichaelRaskin>
Is there a good tool to imitate GitHub in tests or is it a good topic to ask NinjaTrappeur to survey?
<gchristensen>
good topic!
<MichaelRaskin>
I believe there must be one somewhere, no idea how to search for it
<gchristensen>
ekleog: let's get you merge access
<NinjaTrappeur>
MichaelRaskin, you mean a tool to mock GH in ofborg tests?
<MichaelRaskin>
Yes
<NinjaTrappeur>
Alright, got it. I'll dive in that.
<MichaelRaskin>
I wonder if I should switch to fully nix-built ofborg
<srhb>
Looks like evaluation is blocked on releas-18.03 with: hydra-eval-jobs returned signal 6: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS -- we've seen this before but I'm not sure if anyone did something or it just resolves on its own: https://github.com/NixOS/hydra/issues/549
clever has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
clever has joined #nixos-dev
obadz has quit [Ping timeout: 255 seconds]
tilpner has quit [Quit: :wq]
obadz has joined #nixos-dev
tilpner has joined #nixos-dev
obadz- has joined #nixos-dev
obadz has quit [Ping timeout: 248 seconds]
obadz- is now known as obadz
vcunat has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
vcunat has quit [Ping timeout: 256 seconds]
vcunat has joined #nixos-dev
jtojnar has joined #nixos-dev
fpletz has quit [Ping timeout: 256 seconds]
fpletz has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
Lisanna has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
obadz- has joined #nixos-dev
obadz has quit [Ping timeout: 240 seconds]
obadz- is now known as obadz
jtojnar has joined #nixos-dev
<Sonarpulse>
shlevy: I think we just got bit my my native workaround redoubling flags alover the place
<Sonarpulse>
I'm going to make that crossConfig -> strictDeps change I talked about hahaha
<Sonarpulse>
srhb: ^
zybell has quit [Remote host closed the connection]
zybell has joined #nixos-dev
zybell has quit [Client Quit]
zybell has joined #nixos-dev
<copumpkin>
is niksnut back from vacation?
zybell has quit [Ping timeout: 240 seconds]
<srhb>
Sonarpulse: Yay \o/
<srhb>
Though at some point I fear we need to do something to avoid env explosion regardless, at least in haskellPackages. Once people start hitting the environment limit even once, we might be getting close to what we can sensibly pass through env vars at all.
<copumpkin>
niksnut: ever seen kernel panics on NixOS M5 instances? :) I have!
<niksnut>
not that I remember
zybell has joined #nixos-dev
orivej has joined #nixos-dev
<copumpkin>
niksnut: seems to be intermittent if you start up an m5.xlarge that you'll get kernel panic at startup
<copumpkin>
sounds like it might just be an AWS thing, but I haven't seen reports to other distros so dunno
<copumpkin>
(on both 17.09 and 18.03)
<gchristensen>
maybe a kernel version issue?
<copumpkin>
sorry, "start up an m5.xlarge with a large root volume"
<copumpkin>
we've been using 200GB
<copumpkin>
and yeah, no idea, my colleague is trying to pin down more detail
<copumpkin>
how can I change sysctls like that in the initrd?
<copumpkin>
oh, in grub config
<copumpkin>
well, gchristensen , niksnut , what's the recommended place for me to change that in nixos modules?
<copumpkin>
is it a boot.kernelParams thing?
<gchristensen>
hmm
<gchristensen>
you need it in grubcfg?
<copumpkin>
not really sure, all I can tell is that paragraph in that page above
<copumpkin>
but for us it's failing in the initrd saying "waiting for device /dev/disk/by-label/nixos to appear" and then times out and crashes
<vcunat>
gchristensen: have you read some private IRC message from me during the last few days? (It's OK not to respond; I just wanted to make sure it didn't get completely lost.)
<copumpkin>
so it seems like that's probably the problem :)
<gchristensen>
vcunat: yeah, I just keep trying to reply when you're offline :D
<copumpkin>
guessing that a huge EBS volume might take a while to appear (probably needs to get wiped before getting passed to customer)
<vcunat>
gchristensen: I'd better use e-mail next time :-/
<ekleog>
<gchristensen> ekleog: let's get you merge access <-- thanks for the thought! just, before that, is the “gchristensen spends half an hour giving a brief overview of how to test the changes” the “how to run cargo test” speech, or are there other tests I missed?
<gchristensen>
copumpkin: boot.initrd.preLVMCommands maybe would do it
<copumpkin>
hmm
<gchristensen>
that is in stage2 prior to looking at disks
<thoughtpolice>
copumpkin: Hmmm, we use F1 instances that fail to come up sometimes and I've wondered if a kernel panic is to blame, though the EC2 kvm screenshot thing never seemed to reveal much. :|
<copumpkin>
thoughtpolice: the textual console log is much more useful IME
<copumpkin>
thoughtpolice: does F1 also use the new NVME stuff?
<thoughtpolice>
I don't think they have NVMe, actually, I was just more thinking out loud (since ours do occasionally fail to boot; otoh amazon has had some problems which I imagine just come down to HW issues on their side)
<copumpkin>
yeah, they aren't 100% reliable in general