drakonis_ has quit [Read error: Connection reset by peer]
drakonis1 has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
cole-h has quit [Ping timeout: 264 seconds]
johnny101m has quit [Ping timeout: 265 seconds]
pie_[bnc] is now known as pie_
pie_ is now known as pie__
pie__ is now known as pi^e
pi^e is now known as pi^e_
pi^e_ is now known as pie_[bnc]
johnny101m2 has joined #nixos-dev
lopsided98 has quit [Ping timeout: 250 seconds]
<ehmry>
is there a version of hydra available that supports adding new users?
<ehmry>
hydra-create-user is broken for every version I've tried
nocent has joined #nixos-dev
<andi->
Someone should probably poke the hydra machine `e05744a2` as that has been stalling jobs for >21h on `sending inputs`.
<ma27[m]>
ehmry: are you using the Hydra package from nixpkgs or from the `nixos/hydra` repo?
<ehmry>
ma27[m]: tell me which one to use
<ma27[m]>
`pkgs.hydra` from nixpkgs should work since the vm test covers creating a user and I last checked yesterday :)
<ehmry>
yea, the test works
<ehmry>
DBIx::Class::Storage::DBI::_prepare_sth(): DBI Exception: DBD::SQLite::db prepare_cached failed: no such table: users [for Statement "SELECT me.username, me.fullname, me.emailaddress, me.password, me.emailonerror, me.type, me.publicdashboard FROM users me WHERE ( me.username = ? )"] at /nix/store/x3h798hj44mvkky0cgany45g6rz9chm5-hydra-2020-02-10/bin/.hydra-create-user-wrapped line 58
<niksnut>
fwiw, sqlite is no longer supported
<niksnut>
make sure HYDRA_DBI points at a postgres db
<ma27[m]>
hmm, isn't this dropped for a while now? (IIRC since the notification feature with postgres was introduced last year)
<ehmry>
this is the default behavior, if I enable hydra fresh I get this error
<ma27[m]>
which `dbi` did you set?
<ehmry>
I didn't, its taking a default
FRidh has joined #nixos-dev
<FRidh>
jtojnar: could you merge master into staging-next? There are some gnome related merge conflicts
<jtojnar>
FRidh: on it
<jtojnar>
FRidh done. thanks for letting me know
<FRidh>
thanks
<ehmry>
ma27[m]: why is it still using sqlite?
<ehmry>
this seems like there is some effect outside of services.hydra that is breaking things
<ma27[m]>
gchristensen: I'm aware of that. I just asked this question because Hydra picks the proper db by default
<gchristensen>
ma27[m]: I know :) sorry
<ma27[m]>
currently looking further :)
<gchristensen>
turns out it was just a fish thing
<ma27[m]>
ohh I see, haven't read that far.
<ma27[m]>
thanks! :)
<gchristensen>
thank you!
justanotheruser has quit [Ping timeout: 260 seconds]
__monty__ has joined #nixos-dev
<worldofpeace>
So I've done some cursory re-looking into those i915 issues for the 5.4 kernel (trust I have no idea what I'm doing) and it seems at least in manjaro they don't have the issue anymore https://gitlab.manjaro.org/packages/core/linux54/issues/5 (maybe that one is fixed and we don't need to warn to use 4.19 anymore?). I tried looking at the ubuntu kernel
<ma27[m]>
gchristensen: I've seen though that hydra still has a sqlite dependency. Will prepare a PR now to fix this. Although the issue wasn't a hydra bug, the error message was quite misleading though :)
justanotheruser has joined #nixos-dev
<worldofpeace>
samueldr: I remember you were one of the first to comment about this in the 4.19 -> 5.4 thread. Any ideas with graphics stack for i915? (or do I need to find NeQuissimus)
<gchristensen>
ma27[m]: ahh nice
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 265 seconds]
aranea has joined #nixos-dev
abathur has quit [Quit: abathur]
abathur has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 256 seconds]
mkg20001 has quit [Ping timeout: 246 seconds]
mkg20001 has joined #nixos-dev
<gchristensen>
seriously major bug: our aspell/hunspell dicts don't think NixOS is a word.
<{^_^}>
hydra#737 (by Ma27, 1 minute ago, open): Get rid of dependency to SQLite
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
cole-h has joined #nixos-dev
lassulus has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
lassulus has joined #nixos-dev
<Emantor>
worldofpeace: AFAIR 5.4 should be fixed.
drakonis has quit [Ping timeout: 264 seconds]
<disasm>
worldofpeace: nope... very manual process :(
<samueldr>
Emantor: from mainline? do you have links about that?
<Emantor>
let me refresh my stbale tags :-)
<worldofpeace>
disasm: this is in response to "mark as broken" right? I can see how it would be that way, though
<samueldr>
I haven't tried it, I still assumed the issue was present
<worldofpeace>
same
<samueldr>
and since there is no clear reproduction steps, I assumed "testing" is hard
<samueldr>
from that manjaro issue, it looks like they added patches
<samueldr>
not ideal :/
<worldofpeace>
samueldr: it looks like they added ubuntu patches, then removed them
<Emantor>
Ugh, looks like backports of all fixes haven't hit stable. Arch Linux just moved on, 5.6. is definitely fixed.
<worldofpeace>
ugh, Emantor how sad. (I personally would want those patches, but given I have no idea...) I believe that means the note can stay in the release notes
<Emantor>
If Manjaro is fixed, latest 5.4. stable should be fixed as well. They are carrying only a backport of 19f8fb273193a282403b0d14298aaa540d89c2eb from stable AFAICS
drakonis has joined #nixos-dev
<Emantor>
Yes, they are not even applying the patch inside of the PKGBUILD, it just sits lonely in the repo…
<Emantor>
worldofpeace: I revert my old statement and promptly state that 5.4 stable should be fixed.
<samueldr>
let's have a couple peeps with i915 tell us if it's fixed in the latest I figure
<samueldr>
I'll try updating during the day
<Emantor>
I'll switch my laptop over to stable.
<worldofpeace>
same
drakonis1 has quit [Ping timeout: 260 seconds]
<aristid>
what's up with firefox 75 timing out after 10 hours?
<aristid>
on hydra
<samueldr>
which firefox?
<aristid>
ah wait i'm looking at aarch64
<samueldr>
and... the answer, which you'll dislike, is that it's because it took more than 10 hours to build
<aristid>
i don't care about aarch64 :D
<Emantor>
Found a great way to test, I showed extreme tux racer to my girlfriend and she is now playing on the laptop :D
<Valodim>
Emantor: I see it didn't take you long to end up participating here ;)
<Emantor>
Valodim: switchted over the laptop like a month ago, desktop is now also on NixOS. Nothing bars my participation now :-)
<Valodim>
Sweet, so I'll be able to cash in my commission for sure
* Valodim
heads over to #nixos-ponzi
domenkozar[m] has quit [*.net *.split]
b42 has quit [*.net *.split]
roberth has quit [*.net *.split]
matthewbauer has quit [*.net *.split]
abbradar[m] has quit [*.net *.split]
bachp has quit [*.net *.split]
Ox4A6F has quit [*.net *.split]
Dandellion has quit [*.net *.split]
emily has quit [*.net *.split]
nbp has quit [*.net *.split]
cocreature has quit [*.net *.split]
misuzu has quit [*.net *.split]
claudiii has quit [*.net *.split]
lightbulbjim has quit [*.net *.split]
b42 has joined #nixos-dev
domenkozar[m] has joined #nixos-dev
tdeo has joined #nixos-dev
abbradar[m] has joined #nixos-dev
cocreature has joined #nixos-dev
roberth has joined #nixos-dev
misuzu has joined #nixos-dev
emily has joined #nixos-dev
Ox4A6F has joined #nixos-dev
Dandellion has joined #nixos-dev
matthewbauer has joined #nixos-dev
bachp has joined #nixos-dev
nbp has joined #nixos-dev
lightbulbjim has joined #nixos-dev
claudiii has joined #nixos-dev
<kraem>
manveru: i've been searching through lots of issues because i'm trying to use bundix to fetch private github repos.the issues are everything from 1-4 years old. what i've been able to gather is that the underlying problem is nix-shells can't access the gitconfig + ssh agent of the calling user. am i missing something? the hacks i've seen suggesting to solve the issue haven't worked/wen't over my
<kraem>
head. as of now, there's no solution to this? thanks!
orivej has quit [Ping timeout: 264 seconds]
nbp has quit [Ping timeout: 240 seconds]
nbp has joined #nixos-dev
jared-w has quit [Ping timeout: 246 seconds]
dtz has quit [Ping timeout: 246 seconds]
jared-w has joined #nixos-dev
dtz has joined #nixos-dev
abathur has quit [Ping timeout: 240 seconds]
<manveru>
kraem: yeah, you need to use https and netrc i think
<manveru>
unless you want to hardcode credentials in your Gemfile
<manveru>
admittedly i haven't done any private repo stuff in 2 years or so... not certain if there was another way as well :)
<qyliss>
Doesn't Bundix do the fetching?
<manveru>
bundix does the hashing
<qyliss>
It's been a long time for me as well, but I seem to recall I would run Bundix, which would download all the stuff over SSH, and then it would be in the store for my Nix builds.
<manveru>
using nix-prefetch-*
<manveru>
well, yeah, it ends up in the store, but that doesn't help if you try to run it elsewhere later :)
<qyliss>
Well, you could nix-copy-closure it, or run Bundix over there as well
<manveru>
at that point you can just make it a fixed-output-derivation ...
<manveru>
i probably should've done it from the start, nobody complains about rust and go builds doing it :P
<worldofpeace>
disasm: I proclaimed a go in the meeting
<niksnut>
\o/
<cole-h>
Woo!
<Emantor>
FWIW regarding i915, I'll let my laptop run WebGL over night and report back tomorrow. Maybe we can get this removed from the release highlights :-)
<LnL>
yay
<qyliss>
!!!!
<cole-h>
disasm++ worldofpeace++
<qyliss>
worldofpeace++
<{^_^}>
disasm's karma got increased to 17, worldofpeace's karma got increased to 104
<{^_^}>
worldofpeace's karma got increased to 105
<qyliss>
disasm++
<{^_^}>
disasm's karma got increased to 18
<xfix>
disasm++ worldofpeace++
<{^_^}>
disasm's karma got increased to 19, worldofpeace's karma got increased to 106
<Valodim>
worldofpeace: I think you mixed me up with Emantor in the meeting summary. You talked to him about the 5.4 kernel gpu issue :)
<worldofpeace>
darn
<samueldr>
looks like it's mainly time-outs causing dependency failures
<worldofpeace>
Valodim: fixed
<cole-h>
I also saw a couple dying by signal 9...
<cole-h>
At least, on the original jump to 8k failing
<worldofpeace>
llvm_9 timed out taking most of the things in the tested
<cole-h>
llvm... >:(
<worldofpeace>
but it's fine now restarted
<rnhmjoj>
so it's just a transient issue?
<worldofpeace>
rnhmjoj: I think so. but I'm not exactly one to know (tbh, I'm just restarting stuff here)
<gchristensen>
possibly unrelated, but e05744a2 is sorta busted. I'm going to kick it over and see if that helps
<kraem>
manveru: thanks. that's exactly what i've found - the credentials get stored in the Gemfile if i'm using the `BUNDLE_GITHUB__COM` var. i'll have to read up on
<kraem>
netrc and https
<kraem>
would that work with 2FA for github?
<Ericson2314>
gchristensen: this biting you, or you are just wondering for the release?
<gchristensen>
Ericson2314: worldofpeace is concerned about it w.r.t. release
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
<kraem>
i've tried setting ` nix.sandboxPaths` to the dir which contains the netrc file and passing `NIX_CURL_FLAGS` but can't get nix-prefetch-git inside of bundix to read it
<disasm>
gchristensen: sorry, completely forgot to put a reminder on my cal for the cal today
drakonis has quit [Read error: Connection reset by peer]
<worldofpeace>
hmm. it was one of our todo's to have an ical. next release I guess when it's documented:D
drakonis has joined #nixos-dev
<ryantm>
worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 109
ixxie has quit [Quit: Lost terminal]
ixxie has joined #nixos-dev
__monty__ has quit [Quit: leaving]
dongcarl has quit [Ping timeout: 260 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis2 has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis2 has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
<infinisil>
I'm just thinking, how would the ideal automatic deployment flow look like for things that involve private keys?
<infinisil>
Like ssh, wireguard, etc.
<infinisil>
Generating the private key on the machine that needs it certainly
drakonis has quit [Client Quit]
drakonis1 is now known as drakonis
drakonis_ has quit [Ping timeout: 260 seconds]
<infinisil>
But the public key should also be known by other machines during evaluation already
<infinisil>
So how about this: A two-stage deployment. The initial stage sets up all services to generate private keys. Then all public keys get transferred to the central deployment machine, which then does another evaluation, this time including the public keys
<infinisil>
gchristensen might be interested in these kind of thoughts ^
<infinisil>
Such multi-stage deployments would essentially represent evaluation depending on runtime results
<infinisil>
Oh! Another use for this concept would be generation of hardware-configuration.nix
<gchristensen>
the danger to avoid is a case where you just have to keep deploying until thinsg are consistent
<gchristensen>
(something that rings in my head is "there are only 3 numbers in computer science, 0, 1, and infinity")
<infinisil>
Hehe
<infinisil>
Reminds me of LaTeX, which sometimes needs many rebuilds until the document is unchanging
<gchristensen>
exactly
<infinisil>
But they actually have a similar problem: Which content ends up on which page depends on the content, but the content itself contains the page numbers
<gchristensen>
this is "the chef problem" and "the puppet problem" and "the ansible problem". a hint we've become dot declarative. so then the question is how do we push this problem "out of the tool" and "in to the runtime"
<gchristensen>
a hint we've become not declarative*
<infinisil>
Hm, that's actually also similar to how these many foo2nix tools exist
<gchristensen>
one option is to have the deploy tool know about keys, and have it be part of the "create" process. before beginning the evaluation phase, go to the machine and create a wireguard private key ahead of time and extract the public key of that private key before even doing the eval
<gchristensen>
then you never have a moment of "we don't have that key yet"
<infinisil>
Hmm.. I was thinking more of a "initially deploy everything except the parts that depend on runtime generation"
<infinisil>
But then you have to worry about things that might depend on those parts
<gchristensen>
exactly
<gchristensen>
try instead thinking about private keys as a property of the machine itself
<gchristensen>
it might be interesting for you to spend a week (or more?) using Chef and an Ubuntu box
<infinisil>
Hehe maybe
<gchristensen>
a lot of my thinking here is inspired by the sheer pain of using those tools. that is, indeed, how I came to be a NixOS user
<infinisil>
Oh, alternate idea
<infinisil>
Instead of considering "our" machine the evaluation host and the other machine the one we want to deploy to
<infinisil>
We consider both as one machine complex
<infinisil>
And somehow make Nix evaluation work across the network border
<infinisil>
This sounds like a bad idea somehow
<infinisil>
Oh but you still need to generate keys and such
<infinisil>
Never mind that!
ixxie has quit [Quit: Lost terminal]
<infinisil>
Okay yeah so the deployment tool doing an "ssh wg-genkey .." and copying the resulting public key back over, then starting evaluation might be the best idea
<infinisil>
And it's rather simple
<infinisil>
Similar should work for e.g. hardware-configuration.nix
<gchristensen>
one way could be defining a list of wireguard tunnels to create keys for statically network wide
<gchristensen>
like `network.wg-tunnels = [ "wg0" "admin" "database" "foo" ]; and then just go machine to machine generating keys for each of those, and copying back the public key as part of the machine's expression
<gchristensen>
they don't all get to participate necessarily, but you have keys for them if they want to
<gchristensen>
and none of the machines needed to be evaluated at all to know you needed them
abathur has joined #nixos-dev
<infinisil>
Not getting that last sentence
<infinisil>
But that sounds like an idea
<gchristensen>
another method would be defining them like ... `machineX.deployment.wgkeys = [ "wg0" "admin" ];` and then creating those keys ahead of time
<gchristensen>
but then you have to guarantee things like `deployment.wgkeys` can be simply evaluated
justanotheruser has quit [Ping timeout: 240 seconds]
<infinisil>
`machineX.deployment.preDeploy.wg0-key.script = "wg genkey > pri; wg pubkey < pri > pub"`. Then `machineY.networking.wireguard.interfaces.wg0.peers.X.publicKeyFile = nodes.machineX.deployment.preDeploy.wg0-key.resultDir.pub` to set the key
<infinisil>
Maybe it could look like this ^
<infinisil>
Maybe with a module that does this kind of thing automatically based on the wgkeys idea of yours
<gchristensen>
probably nicer to have that sort of state be explicitly part of the "runtime" instead of the declarative expression
<infinisil>
How do you mean?
ixxie has joined #nixos-dev
<gchristensen>
arbitrary effects in the preDeploy thing is scary to me :)
<gchristensen>
instead making it part of the "runtime" (ie: a plugin of sorts to the deploy tool) makes it feel nicer to me I guess? not sure
<infinisil>
Ah, you mean something users wouldn't be able to declare themselves without changing the deployment tool
<gchristensen>
right
<infinisil>
gchristensen: I'm thinking this script could be run in a heavily restricted sandbox. Only the final directory it produces would be exported somewhere
<gchristensen>
instead if you make it a part of the tool, it becomes a thing you can share with other deployments
<{^_^}>
nixops#1189 (by cleverca22, 34 weeks ago, open): plan for supporting custom partition layouts and custom FS's on any backend
<infinisil>
Which builds a minimally working system in an initial phase iirc
<gchristensen>
a bit, though you'd probably want to be able to generate more keys over time
<infinisil>
Yeah
<infinisil>
Scratch that then
<gchristensen>
(you've got good ideas, btw)
<infinisil>
(thx!, and you give good feedback)
<infinisil>
So then the question becomes: What kind of things can we rely and assume and require in and from such a script that runs before the deploy
<gchristensen>
yeah, right
<clever>
infinisil: i recently had another idea related to the above ticket
<gchristensen>
and it may be that you could just define some baselines ("for this to work, it needs to be NixOS 20.03 or later")
<clever>
infinisil: if you just do a single-user nix install on the remote machine, you can use `nix copy --to` like in the above ticket, to copy nixos to /mnt/ on a remote (non nixos) box
<clever>
infinisil: after that, you simply need to run `switch-to-configuration boot` under a chroot, and your done
<infinisil>
gchristensen: Ideally it should be as independent as possible from the underlying system
<gchristensen>
I think trying to have your tool go from anythnig -> something is maybe not realistic
<clever>
infinisil: the kexec will be as independant as possible
<infinisil>
clever: Sounds like a good plan
<clever>
infinisil: and there are variants, like putting the kexec kernel+initrd onto /boot with grub instead
<gchristensen>
("here's my Slackware install from 1995, good luck")
<clever>
all depends on what the cloud provider offers
<infinisil>
gchristensen: I mean with Nix it wouldn't be that hard: Tell it the platform the target system runs at and Nix can (potentially cross) compile a script that generates a directory
<clever>
gchristensen: ive converted a gentoo install to nixos, in minutes, with just wifi access
<clever>
gchristensen: without kexec or any usb media
<gchristensen>
yeah but how much of that depends in the deploy tool, vs. a preconditioning tool
<gchristensen>
s/depends/belongs/
<clever>
infinisil: for the above nixops issue, i was thinking that for baremetal, you boot the nixos installer somehow (your problem, not nixops's), and then just give nixops the ip&pw
<infinisil>
I guess the kernel config might play a role
<infinisil>
For e.g. sandboxing the script
<clever>
infinisil: for aws, it could be an AMI that contains the kernel+initrd, skip the kexec step
<clever>
infinisil: for packet.net, tftp+pxe boot it
<clever>
for other cloud providers, rescue boot, kexec
<gchristensen>
all of these different options andmethods are what makes me think it belongs more in a preconditioning tool
<infinisil>
clever: Yeah, thought of that too, separating the deployment tool from the initial setup would make things a lot simpler
<clever>
gchristensen: i was thinking the backend code in nixops, would deal with that
<infinisil>
A separate project could then collect things for going from provider to initial installer
<clever>
gchristensen: so, the nixops-packet code, would deal with booting nixos via pxe, and then hand it off to a shared module
<gchristensen>
yeah, but the maintainers of nixops aren't going to be experts in tftp, pxe, aws, kexec, and on
<gchristensen>
ah
<gchristensen>
yeah
<clever>
gchristensen: each backend for a service provider, will need to implement it differently
<gchristensen>
cool
<clever>
to suit what that provider can handle
<clever>
for existing providers, this would be an optional provisioning mode
<clever>
so you can either boot the existing nixos ami, or boot this custom ami, and then get zfs on aws for ex
<clever>
and once the code is in place, it would make it much simpler to add more providers that lack AMI like features
<clever>
you just need code to provision hardware, boot into a rescue env, scp a file to the box, and run a shell command
ixxie has quit [Quit: Lost terminal]
<clever>
and then its in a state that the common code can handle