{^_^} has quit [Remote host closed the connection]
tetdim_ has joined #nixos-dev
evanjs has joined #nixos-dev
{^_^} has joined #nixos-dev
<infinisil>
andi-: It actually almost works already with security.acme.certs
<infinisil>
E.g. by saying services.syncplay.domain = "foo.bar" it could automatically use security.acme.certs."foo.bar"
<infinisil>
.directory + "cert.pem" etc.
<gchristensen>
that feels like a lot of coupling that I would rather not have
<gchristensen>
maybe instead something like services.syncplay.cert = config.security.acme.certs."foo.bar"
<gchristensen>
but this is not necessarily sufficient, since different services require different cert types which sometimes require tweaking the acme config
<infinisil>
We could have a generic security.certs.* instead
<infinisil>
Not tied to acme
<infinisil>
And if acme is enabled for a domain it automatically sets that
<infinisil>
And it would have options for key,cert,chain,etc.
<infinisil>
As in, `security.certs.*.key` is a path to the key, or null
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
kalbasit_ has joined #nixos-dev
tilpner_ has joined #nixos-dev
tetdim has joined #nixos-dev
srhb_ has joined #nixos-dev
manveru_ has joined #nixos-dev
tetdim_ has quit [Ping timeout: 256 seconds]
manveru has quit [Ping timeout: 256 seconds]
grfn has quit [Ping timeout: 256 seconds]
grfn has joined #nixos-dev
srhb has quit [Ping timeout: 256 seconds]
jkkm has quit [Ping timeout: 256 seconds]
kalbasit has quit [Ping timeout: 256 seconds]
cbarrett has quit [Ping timeout: 256 seconds]
srhb_ is now known as srhb
manveru_ is now known as manveru
copumpkin has quit [Ping timeout: 256 seconds]
kalbasit has joined #nixos-dev
jkkm has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
cbarrett has joined #nixos-dev
copumpkin has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
kalbasit has joined #nixos-dev
kalbasit_ has quit [Ping timeout: 256 seconds]
evils has quit [Ping timeout: 260 seconds]
evils has joined #nixos-dev
justanotheruser has joined #nixos-dev
kalbasit_ has joined #nixos-dev
tgamblin-llnl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 260 seconds]
kalbasit_ has quit [Ping timeout: 260 seconds]
kalbasit_ has joined #nixos-dev
kalbasit[m] has joined #nixos-dev
kalbasit[m] has joined #nixos-dev
kalbasit[m] has joined #nixos-dev
kalbasit[m] has quit [Changing host]
kalbasit[m] has quit [Quit: authenticating]
kalbasit[m] has joined #nixos-dev
kalbasit[m] has quit [Client Quit]
kalbasit[m] has joined #nixos-dev
kalbasit[m] has quit [Client Quit]
midchildan has joined #nixos-dev
kalbasit[m] has joined #nixos-dev
contrapumpkin has joined #nixos-dev
kalbasit_ has quit [Ping timeout: 264 seconds]
kalbasit has quit [Ping timeout: 260 seconds]
qyliss- has joined #nixos-dev
grfn` has joined #nixos-dev
qyliss has quit [Ping timeout: 256 seconds]
grfn has quit [Ping timeout: 256 seconds]
grfn` is now known as grfn
copumpkin has quit [Ping timeout: 256 seconds]
qyliss- is now known as qyliss
<simonpe^^>
ehmry: regarding the llvm discussion yesterday: I got no version of llvm to work, and some combos of nixpkgs/llvm produce different error messages. It seems to boil down to libcxxabi every time though, sometimes it's warnings about shadowed variables and sometimes its this undefined PHASE1 something define
<siraben>
How could I find out what the status of building certain packages (e.g. Firefox) on i686 is?
<simonpe^^>
I can try to reproduce it and start a PR but today I have birthday so I'm not going to work :D
tgamblin-llnl has joined #nixos-dev
tgamblin-llnl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 268 seconds]
saschagrunert has joined #nixos-dev
cole-h has quit [Ping timeout: 272 seconds]
tom39291 has quit [Quit: WeeChat 2.9]
tom39291 has joined #nixos-dev
<andi->
infinisil: assigning a string value doesn't seem like what I'd like. That is one step of magic too much. I'd rather manually assing services.syncplay.certificate = config.security.certs."foo.bar" instead. Passing attrsets instead of magic strings that somehow work. This also gives us an immediate escape hatch if you want to configure it manually *just for that service* without having to use the
<andi->
security.certs stuff at all.
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-dev
teto has quit [Ping timeout: 264 seconds]
teto has joined #nixos-dev
__monty__ has joined #nixos-dev
kini has quit [Ping timeout: 264 seconds]
kini has joined #nixos-dev
thonkpod has quit [Ping timeout: 244 seconds]
nyanotech has quit [Ping timeout: 244 seconds]
thonkpod has joined #nixos-dev
nyanotech has joined #nixos-dev
Jackneill has joined #nixos-dev
<infinisil>
andi-: Hmm I think strings would be better, because then you don't have to duplicate the certs.*.* options all over the place
<infinisil>
It will just be `domain = mkOption { type = str; }`, whereas with an attribute set it would have to be `domain = mkOption { type = types.submodule { options.keyPath = ...; options...; }; }`
<infinisil>
I guess you could do `domain = mkOption { type = options.security.certs.type.function bla bla; }` or so, but that feels a bit odd
<infinisil>
Kind of like: With `security.certs.<name>` we define a node named <name>, and we can refer to that node by its name whenever we need it
<infinisil>
Feels cleaner
__monty__ has quit [Quit: leaving]
AlwaysLivid has joined #nixos-dev
<andi->
I disagree. I would only accept this if we add the ability to also add non-acme certs to the secruity.certs and we make it clear that domian name != certificate name, they just might be the same for ACME.
justanotheruser has quit [Ping timeout: 264 seconds]
tetdim has quit [Ping timeout: 256 seconds]
tetdim has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<gchristensen>
I'm planning on deploying updates to Hydra which involve a handful of migrations
<gchristensen>
it might take a couple hours to complete the migrations. any in-flight security patches or other high priority channel bumps we're waiting for?
<gchristensen>
I'm going to start in about 30 minutes unless I hear anything else :)
<Taneb>
gchristensen: hmm, I don't think the sudo thing has been fixed in nixos-unstable but that has a build problem
<gchristensen>
unstable-small has it also, in case someone is looking for it
<{^_^}>
#104594 (by FRidh, 9 weeks ago, open): GitHub Actions needed for in Nixpkgs
<infinisil>
supersandro2000: Ah yeah that sounds good. I had in mind for the bot to automatically cherry-pick to the release branch, without going through a human-reviewed PR
<infinisil>
(which I wouldn't want)
kraem has quit [Quit: outta here]
contrapumpkin is now known as copumpkin
kraem has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 268 seconds]
copumpkin has quit [Quit: Bye!]
copumpkin has joined #nixos-dev
kraem has quit [Quit: outta here]
kraem has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
justanotheruser has quit [Ping timeout: 272 seconds]
<mjlbach>
gchristensen: Is there a way to get a full manifest from hydra of build successes/failures without querying every individual package?
<gchristensen>
hmm can you be somewhat more specific about what you're trying to do?
<mjlbach>
I'm trying to cross-reference marked broken and packages that fail to build on hydra to repology for a project I'm working on
<mjlbach>
And I'd like to get a daily dump of hydra to a sql database I host
<gchristensen>
a full dump? or do you want data about, like, a single evaluation?
<mjlbach>
If by single evaluation you mean single package, I can get that currently
<mjlbach>
I mean a full dump of the latest evaluation
<gchristensen>
no, the whole evaluation of nixpkgs -- so you'd get data about ~40,000 builds
<mjlbach>
Yes, that would be ideal
<gchristensen>
but you wouldn't get the historic information, which would be 130,000,000 builds
<mjlbach>
Right, that's fine
<mjlbach>
This is also useful for another project I'm working on, which runs a query against this hosted database before bumping a flake
<mjlbach>
So you can bump to the latest hydra eval conditional on only the packages you've defined having succeeding builds
<gchristensen>
cool
<gchristensen>
and are you looking for this from hydra.nixos.org,
<gchristensen>
and are you looking for this from hydra.nixos.org, or from your own hydra?
<mjlbach>
I was piloting on my own hydra, but I was looking for it on hydra.nixos.org
<mjlbach>
I assumed it didn't exist, or hydra-check would likely be using it haha
<gchristensen>
yeah it is a good question ... I've been spelunking lately ...
<gchristensen>
whew
<gchristensen>
is this going to be open source, mjlbach?
<mjlbach>
Of course!
<mjlbach>
The projects are in very early stages
<gchristensen>
okay, well, maybe there is a way to convince hydra's web UI to do it, but the other thing is if you author a query for it, I could run it as part of https://github.com/grahamc/hydra-pg-load-dump -- executing a query and uploading the result for you to fetch (look around line 105 of dump.sh)
<mjlbach>
Ahh perfect, I can look into writing the query and test on my local hydra instance
<mjlbach>
That curl command is failing for me with `{"error":"Parameter not defined!"}`
<gchristensen>
yeah I intentionally left out the remaining parameter because it is a bit heavy of a call and I didn't want anybody's clients to hurt hydra :P
<gchristensen>
btw as of this migration you can see the evaluation errors for previous evaluations
<mjlbach>
Ahh got it
<mjlbach>
It's still eval-ing :P
<mjlbach>
*downloading
<gchristensen>
how many did you ask for?
<mjlbach>
Just one
<gchristensen>
hah
<mjlbach>
This is why offloading to a database would be useful lol
<mjlbach>
Then we could query the database without impacting hydra
orivej has quit [Ping timeout: 240 seconds]
<mjlbach>
Why are there multiple ids/timestamps for a given job (kwin-5.18.5) for example has > 10 on trunk-combined?
<gchristensen>
how many are you asking for?
<gchristensen>
it is giving you a list of recent builds, not necessarily builds for a given evaluation
<gchristensen>
mjlbach: that API endpoint isn't giving you *exactly* what you want, but it is a rough aproximation
<mjlbach>
Got it
<gchristensen>
if you take the most recent per job it should get you essentially the right thing
<mjlbach>
Ah yes, I can parse it no problem (that's what I'm doing) but the json is about 10-20x bigger than it should be
<mjlbach>
(300 mb)
<gchristensen>
O . O how many are you asking for?
<gchristensen>
since there are only like 40k jobs, asking for, say 45k should be enough to get a roughly total view
<mjlbach>
oh
<mjlbach>
wow
<mjlbach>
Hahah I misinterpreter what the param was and fed in the eval number 😆
<gchristensen>
hahaha
<mjlbach>
misinterpreted*
<gchristensen>
poor hydra
<mjlbach>
😢
<gchristensen>
it'll be fine probably
<mjlbach>
Is there a way to query the nixpkgs revision as well?
<gchristensen>
getting a bit tricky, you'd have to read the code to see if something did that
<mjlbach>
No worries, time to brush up on my perl
<gchristensen>
same
<mjlbach>
I think I can just cheat and pick and random build and use that to fetch the nixpkgs version