justanotheruser has quit [Ping timeout: 260 seconds]
<Profpatsch>
sphalerite: fantastic, looking forward to it. If you write an RFC, I’ll be sure to take a look.
<Profpatsch>
I guess the first step would be to describe the current implementation semantics
<Profpatsch>
And then to optimize along one or more axes
<Profpatsch>
There’s probably trade-offs involved, so the very best solution would make it possible to customize the behaviour.
<Profpatsch>
that is more than just --builder can do
<Profpatsch>
e.g. sometimes you want to have the intermediate build result (but you probably don’t want the remote build to block on the download in any case)
<Profpatsch>
and by “have” I mean download them into your local store.
<Profpatsch>
sphalerite: do you plan on making it more optimal for multiple build machines working on the same query? Because I guess synchronizing between them could become hairy, especially if they should push build artifacts directly to each other’s stores.
bhipple has quit [Remote host closed the connection]
<cole-h>
infinisil: Does your checked maintainers PR do anything when a package has no maintainer, or is that still something that needs to be caught in a manual review?
<cole-h>
My real question is: how does it (or we) handle orphaned packages, e.g. somebody leaving Nixpkgs for whatever reason and removing themselves as sole maintainer of all their packages
FRidh has joined #nixos-dev
avn has quit [Ping timeout: 256 seconds]
sogatori has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
Jackneill has joined #nixos-dev
<jtojnar>
Weird GDM is failing in QEMU with "systemd-logind: failed to take device /dev/dri/card0: Operation not permitted"
<jtojnar>
ugh, qt depends on postgresql
<jtojnar>
s/qt/qtbase/
<yorick>
jtojnar: better than the other way around :)
__monty__ has joined #nixos-dev
<FRidh>
jtojnar: looks like structured attrs are mostly building now. It's some core packages of darwin that needs fixing now. Am I right?
<jtojnar>
FRidh sorry, I did not look at it in a long time
<FRidh>
according to the latest jobset there's 5000 failing linux packages
<FRidh>
although some already build now
<jtojnar>
Fridh I think globin wanted to hear some opinions about the env attribute, maybe even open a RFC
<jtojnar>
since it was not really discussed anywhere and is kind of orthogonal
<FRidh>
jtojnar: right I recall something similar. In my opinion it's an understandable change. Yes its backwards incompatible, but at some point (such as in this kind of big change) I am of the opinion its worthwhile. The only alternative I see is another stdenv
<globin>
FRidh: it needs a lot more work first, I'll write an RFC when the language infrastructures and the most important things are fixed (nix itself needs some work, all passAsFile usages aren't working, there is at least one more change I have to do in stdenv/setup.sh etc.)
<globin>
and I haven't had any look at darwin/aarch64 so far
<FRidh>
globin: so I take it there's more backwards incompatible changes. Would it be reasonable to have the stdenv at least support both but with a flag, so we can deprecate the old one?
<FRidh>
recalling what changes were needed I doubt so
<globin>
no, one would have to duplicate it completely, I'm trying to keep as much backward-compatible as possible and eval error on everything that isn't possible
<FRidh2>
error: attribute 'tests' in selection path 'iproute.passthru.tests' not found
<gchristensen>
I don't think so, it automatically discards them
<gchristensen>
the aarchh64 and x8664-linux builds it also tried to build them but decided it couldn't
<FRidh2>
ok
<LnL>
pretty sure I've seen builds with Can build: foo, Can't build: foo.tests so should be fine
<LnL>
yeah: Can build: 'mariadb', Cannot build: 'mariadb.passthru.tests'
<globin>
FRidh2: i wanted to make it explicit that they can only be strings/numbers, you can always `toString` it before passing it into env
<globin>
otherwise we have magically concating strings with ' ' again
<FRidh2>
oh right using toString here indeed be fine
<FRidh2>
concatenation would only be done while we're migrating and deprecating the old stdenv
<globin>
well `env` is new anyway so we can just do it correctly right away :)
<ehmry>
is there a function to shift the platform offset of a package, like what is done with nativeBuildInputs?
<gchristensen>
okay cool so I fixed one thing and broke another :')
<gchristensen>
it sure seems I'm either seeing major changes in nginx's behavior, or the nginx's module's behavior
<gchristensen>
not sure.
<gchristensen>
fyi: ofborg's log viewer isn't broken anymore, afaik. if it is, lmk :)
FRidh has joined #nixos-dev
FRidh2 has quit [Ping timeout: 260 seconds]
<gchristensen>
woohoo, no issues with the internal error label. maybe things have stabilized.
<gchristensen>
oh it is the weekend. they probably stopped deploying breaking changes for a couple days.
<flokli>
hrm, seems the manual currently is broken on master
<flokli>
intermediate.xml:5651: parser error : Opening and ending tag mismatch: interface line 5649 and para
<flokli>
is there any nice way to debug this? can I produce intermediate.xml somehow for inspection? maybe through the nix-shell in nixos/doc/manual?
<flokli>
^ gchristensen
<gchristensen>
yeah
<gchristensen>
in that nix-shell run xmloscopy
<flokli>
and what are the parameters here?
<gchristensen>
uhhh one sec
<gchristensen>
run `make debug`
<flokli>
yeah nope. I just get the same error as if I'd build the manual
<flokli>
I tried hacking nixos/lib/make-options-doc/default.nix to xmllint $optionsXML, because I assumed this to be the culprit
<flokli>
but it seems to be fine
<flokli>
and it got broken after piping it through xsltproc :-/
<gchristensen>
interestign
<gchristensen>
is there an intermediate.xml in the directory tree somewhere?
greizgh has quit [Quit: greizgh]
<flokli>
so, it's the first xsltproc run in the optionsDocBook command that's failing
<flokli>
the one that's supposed to create intermediate.xml
greizgh has joined #nixos-dev
<gchristensen>
so this is failing inside of a nix build
<flokli>
if I run xmllint on $optionsXML before, it doesn't complain
<flokli>
yes
<flokli>
I just hacked some debug statements inside nixos/lib/make-options-doc/default.nix, and did nix-build nixos/release.nix -A manual.x86_64-linux on master
<gchristensen>
how about --keep-failed and xmloscopy --docbook5 ./path/to/the/busted/file.xml ? is thath possible?
<gchristensen>
(making breakfast, so can't look too hard right yet)
<flokli>
I used --keep-failed, and manually xmllinted the intermediate.xml, which got me to 2c7f8d56dce12ae9f890d627766764c36f371b06, which uses "<interface>" in a string
<flokli>
will prepare a fix. I'll think about how to make the debug cycle a bit easier
<gchristensen>
nicce
<gchristensen>
thanks, flokli
<flokli>
have a good breakfast!
<gchristensen>
let's also issue a build on the manuals for each PR that has the "has: docs" label
<flokli>
master is fixed again
<gchristensen>
flokli++ thanks for debuging and fixing
<{^_^}>
flokli's karma got increased to 10
<gchristensen>
flokli++ thanks for debuging and fixing
<{^_^}>
flokli's karma got increased to 11
<flokli>
gchristensen: be careful, you're getting in the sticker range ;-)
<gchristensen>
=)
<flokli>
"has: documentation" won't be enough
<gchristensen>
I guess we could just trigger one for every PR :P
<flokli>
this was a module option description update, which will also get baked into the manual
<flokli>
yes
bhipple has joined #nixos-dev
<gchristensen>
would you like to PR that? ideally the nixos and nixpkgs manual
<gchristensen>
as 2 different builds
<gchristensen>
no worries if you'd rather not, I think I can do it this afternoon
<flokli>
I think tasks/eval/nixpkgs.rs already does try to build the manual
<gchristensen>
I think it just instantiates the manual
<gchristensen>
we'd also need to create a build job for the attributes
<flokli>
yeah, it's Instantiate
<flokli>
I'll flip it with Build
<flokli>
we want to build the manual
<flokli>
in fact, we want to be able to build the manual on every commit hitting master anyways.
<gchristensen>
we probably want to do both instantiate and issue a build
<flokli>
okay
<gchristensen>
failing builds don't currently fail the PR
<flokli>
hm. the manual obviously also depends on the architecture (it's manual.$currentSystem). I might need some more rubberducking to PR this properly. LMK when you're back
<gchristensen>
cool, sounds good, thanks
erictapen has quit [Ping timeout: 256 seconds]
erictapen has joined #nixos-dev
sogatori has quit [Remote host closed the connection]
<sphalerite>
Profpatsch: yes, I plan to investigate along a number of axes. I'll digitalise my notes so far and share them Soon™ :)
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
cole-h has joined #nixos-dev
<m1cr0man>
Anyone got a system with an ACME cert that has been automatically renewed at least once?
<m1cr0man>
I'm looking to find the status of the timer, in particular what the trigger is when you run systemctl status acme-mydomain.timer
<emily>
I had to add it to the acme-dns stuff to get it working properly for various reasons
<emily>
(™)
<m1cr0man>
So the reason that line is there is to trigger a service restart when permissions-oriented settings are changed. Surely this is now redundant as per https://github.com/NixOS/nixpkgs/pull/81371 ?
<{^_^}>
#81371 (by mweinelt, 5 weeks ago, merged): nixos/acme: renew after rebuild and on boot
erictapen has quit [Ping timeout: 264 seconds]
asbachb has joined #nixos-dev
<m1cr0man>
emily: I can't see a way to use a systemd timer with RemainAfterExit, their docs explain quite clearly that it's not a supported combination
<emily>
oh, on the timer itself, sorry; I misunderstood
<emily>
I guess the explicit renewal should catch it, mhm
<emily>
the .services not having RemainAfterExit does weird things to dependency ordering though
<m1cr0man>
Ah right, yes...Well I guess we could add some sort of middle man service on the timer, or just an ExecStart of some form on it to restart the service (start is not sufficient)
<FRidh2>
gchristensen: need to test the CI every once in a while ;)
<cole-h>
lol
<gchristensen>
:P
<gchristensen>
lnl has a good fix suggestion which I'll try out in a bit :)
<gchristensen>
clever: nice, though (nit) the first line should probably be broken up in to a few lines
<LnL>
I can also look at it if you want
<clever>
gchristensen: yeah, it was getting rather long
<gchristensen>
LnL: please! :)
drakonis has joined #nixos-dev
<infinisil>
What if derivations themselves could configure preferred Nix caches
<infinisil>
And the user would have to approve their use interactively
<infinisil>
E.g. meta.preferredCaches = [ "https://cache.nixos.org" ], which when built will first ask "Do you trust the cache at cache.nixos.org?" before attempting to fetch the derivation from it
<infinisil>
Oh and the public key would have to be specified somewhere too
<gchristensen>
say you have A which depends on B and C; A and B are in cache.nixos.org, and C is in cache.malicious.attacker
<gchristensen>
then a package in cache.nixos.org depends on C
<gchristensen>
do you have to approve the malicious cache for every item in the closure?
<gchristensen>
I think it would be hard to communicate to the user that pulling those paths from a malicious cache might taint paths you would otherwise in the future pull from cache.nixos.org
<erictapen>
has anybody seen cmake create a directory which is literally $out? like ./result/\$out/lib?
<infinisil>
gchristensen: I don't really get what you're saying. Caches would be approved once yeah, but I don't see how that's problematic, because you already trust the Nix code that specifies the caches
<clever>
erictapen: which string did you put $out in, at the nix level?
<LnL>
yeah, having unofficial caches like cachix is great but I find it rather scary to actually use if you don't control it yourself
<infinisil>
Actually doing it this way would make it less scary
<erictapen>
clever: only in cmakeFlags, like this: "-DGLOBAL_CONFIG_DIR=$out/etc"
<gchristensen>
infinisil: as a user it is tempting to say "I trust foocache to provide paths for fooproject, but I don't want to trust foocache for anything else."
<cole-h>
erictapen: Maybe try `$(out)`
<infinisil>
Because stuff from nixpkgs couldn't suddenly be fetched by some cachix, since that's not in its meta.preferredCaches
<clever>
erictapen: thats the problem then, it wasnt parsed by bash at any stage, so it remained as a literal $out
<infinisil>
(maybe it should be "allowedCaches")
<LnL>
not really, like what gchristensen is talking about
<gchristensen>
infinisil: but in reality, this is impossible, because it is perfectly feasible for the user to fetch compromised paths from foocache which are later used by the system
<clever>
erictapen: builtins.placeholder is one option, $(out) sometimes works, or you can `preConfigure = ''export cmakeFlags="$cmakeFlags -DGLOBAL_CONFIG_DIR=$out/etc"''` so it goes thru bash
<LnL>
nix does store the cache signatures however
<erictapen>
cole-h: clever: I will try that, thanks!
<infinisil>
gchristensen: How is that any different than what people are currently doing?
<LnL>
so in theory it could validate that the closure was built locally or signed by the same cache
<cole-h>
(I would personally try `$(out)` first, then `"${placeholder "out"}..."`, then cry)
<infinisil>
Currently people add *.cachix.org to their trusted caches, which in the future allows any derivations to be fetched from it
<gchristensen>
infinisil: for example, fooproject could depend on the openssh store path from the very tip of master, and do a timing attack of convincing people to fetch their compromised version before it is in cache.nixos.org, thereby compromising their system when their system depends on that store path
<clever>
[root@amd-nixos:~]# sqlite3 /nix/var/nix/db/db.sqlite -header -column "select path,sigs,narSize/1024/1024,datetime(registrationTime,'unixepoch') from ValidPaths where narSize > (1024*1024*256) and path not like '%qdyq1pwk3j2s6znr9n036iks58cpmy4j%' order by narSize desc limit 30;"
<infinisil>
gchristensen: Hmm I see
<clever>
LnL: this is a query i had written, to list all storepaths, sorted by size, including when they got registered
<clever>
LnL: and i just tossed sigs into the list, so it now also shows all signatures
<gchristensen>
the difference is in the expectations of the user: setting foocache as a trusted cache vs. suggesting that the store can be subdivided based on this per-derivation cache specification
<gchristensen>
when in reality it cannot be
<infinisil>
Hmm what if it could though: Store paths could be registered as "verified by caches X and Y"
<infinisil>
And if a derivation is evaluated that only has Y as allowedCaches, but the current store path is only verified by X, it would fetch it again from Y and verify the results
<clever>
infinisil: you can already query that, via the sigs column in the query i pasted
<gchristensen>
infinisil: then, presumably error asking the user to choose which cache to use?
<infinisil>
Hmm..
<infinisil>
Maybe yeah
<infinisil>
If they don't match
<gchristensen>
or maybe a policy of "prefer cache.nixos.org above all else"
<gchristensen>
(or cache.bigcorp.com)
<infinisil>
If this were supported I think it would increase both security and convenience without much complexity
<gchristensen>
that is a nice idea
<clever>
gchristensen: thats sort of already available, the priority in nix-cache-info, but any cache can choose to be more important then cache.nixos.org
<infinisil>
Oh and also speed: Currently having 10 cachix's in your trusted caches makes it query all of them for all store paths you build
<clever>
the problem is more, a race condition in the attack
<clever>
what if i look at an upcoming mass-rebuild PR, and i compute the new path for sudo
<gchristensen>
infinisil: yeah that is miserable lol
<clever>
then i pre-compile a trojan'd sudo, put it onto my binary cache, and make my random util depend (but not use) the trojan'd sudo
<clever>
you now download the trojan'd sudo, before hydra.nixos.org has built the real one
<clever>
my cache was the only one with a copy, no contention
<infinisil>
clever: With above idea it would verify each path with the derivations allowedCaches
<clever>
a week later, the channel updates, and now nixos-rebuild wants that sudo, "oh, i already have it"
<LnL>
I'm not sure how you'd tie what comes from where tho
<LnL>
in theory you could mark eg. your nixos system to come from cache.nixos.org and have it's tree verified
<LnL>
but in practice people will probably want to mix and match stuff so that doesn't really work
<clever>
LnL: db.sqlite does keep track of who signed what
<ryantm>
I have a reproducibility/caching issue that I'm hoping someone might have a suggestion for how to solve. https://github.com/ryantm/nixpkgs-update/issues/179 Basically, if I download nixpkgs-update via the GitHub master archive or the commit hash archive, it produces a different drv file, and requires recompilation. Even when the archives are the same contents.
<{^_^}>
ryantm/nixpkgs-update#179 (by ryantm, 15 hours ago, open): cachix-action does not produce the same drv path as archive tarball
<domenkozar[m]>
ryantm: usually it's because of src = ./.;
<ryantm>
cole-h: That file shouldn't be being used for anything except local development, but I'll delete it to see. Maybe cabal2nix needs to be fixed to not generate `src = ./.`.
<cole-h>
Ah, OK. I was just looking around for other `./.` :)
<ryantm>
domenkozar[m]: I wouldn't think gitignore would be in play, because I'm just talking about the GitHub archive vs cachix action, is there something related to gitignore I'm not thinking of?
<ryantm>
Deleting that cabal2nix-generated file did not fix the issue.
<domenkozar[m]>
so either delete .git on github actions
<domenkozar[m]>
or use gitignore.nix :)
<ryantm>
gitignore.nix sounds great, so I'll try that.
<domenkozar[m]>
alright :) going to bed now, let me know if you managed to get it to work
<teto>
Any reason for the "Cached failure" on https://hydra.nixos.org/build/116153899 ? I am trying to work on structured-attrs and I get to recompile gcc while it looks available in cache
<globin>
teto: there is a newer full rebuild which isn't evaluated
<globin>
I have another one nearly ready that's why i'm not triggering it
__monty__ has quit [Quit: leaving]
<teto>
globin: ok cool. I wanted to check my qt fixes. I noticed in setup.sh you rolled back the concatenation of arrays configureFlags+=("XXX") to configureFlags=("XXX" "c{onfigureFlags[@]}"). any reason ?
<globin>
teto: depends on the ordering of the flags
<jtojnar>
etu: the nixos-combined now fails to evaluate: error: aggregate job 'tested' references non-existent job 'nixos.tests.php.x86_64-linux'
justan0theruser has quit [Ping timeout: 265 seconds]