worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced https://discourse.nixos.org/t/nixos-20-03-beta/5935 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
<worldofpeace> Jan Tojnar: that is rather helpful.
<jtojnar> but when I tried overriding flatpak with p11-kit 0.23.18.1, it still seemed to fail (maybe I forgot to restart some service)
<jtojnar> and worse, it should be fixed in 0.23.20 but we can reproduce it on systems with 0.23.20
<cole-h> Somebody with w+, I think this should get the security tag, please: https://github.com/NixOS/nixpkgs/pull/84273
<{^_^}> #84273 (by mmilata, 4 hours ago, open): gnutls: 3.6.12 -> 3.6.13 [security]
justan0theruser has joined #nixos-dev
bgamari has quit [Quit: ZNC 1.7.5 - https://znc.in]
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.
<b42> ls
<b42> oops
<{^_^}> fedora-modularity/libmodulemd#466 (by jtojnar, 50 seconds ago, open): overridesdir detection is unreliable
<jtojnar> would need to have two different options (per python version), so trying to fix the script instead
<worldofpeace> Jan Tojnar: oh, I think that's why I didn't submit the patch. Thanks for the issue
bgamari has joined #nixos-dev
<emily> worldofpeace: hi, you broke ibus. nixos/modules/i18n/input-method/ibus.nix line 79 should say config.xdg.portal.enable :)
<emily> (can PR if you'd prefer)
<worldofpeace> emily: hedning already has
<emily> oh, sorry ^^
<emily> should have checked master
<worldofpeace> it seems ofborg having problems is making these messups worse (mine)
<worldofpeace> emily: But I think it was to staging-next
<emily> hm, I can't find it on staging-next, but I might be grepping wrong
<cole-h> Is ofborg still having problems? I think it's been fairly consistent (today, at least)
<jtojnar> worldofpeace having both python3 and python2 triggers importerror, so the except branch is chosen and it installs correctly 🤣️
<emily> cole-h: thanks ^^
hexa- has quit [Quit: WeeChat 2.7.1]
hexa- has joined #nixos-dev
hexa- has quit [Client Quit]
hexa- has joined #nixos-dev
<gchristensen> cole-h: want access to ofborg's logs to help future debugging? :)
<cole-h> Sounds like fun, count me in.
<gchristensen> email?
<cole-h> cole.e.helbling@outlook.com
<gchristensen> PM'd you a thing
<gchristensen> https://grafana.com/docs/grafana/latest/features/datasources/loki/ how to use that Explore link I senty ou
<cole-h> gchristensen++ Thankee kindly
<{^_^}> gchristensen's karma got increased to 253
teto has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Ping timeout: 260 seconds]
lovesegfault has joined #nixos-dev
lovesegfault has quit [Client Quit]
drakonis has quit [Quit: WeeChat 2.7.1]
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> although this blog post kind of is a pre-rfc, at least it explains why I think we should adopt it: https://nixos.mayflower.consulting/blog/2020/01/20/structured-attrs/
<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 has joined #nixos-dev
erictapen has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
<aanderse> > ugh, qt depends on postgresql
<aanderse> Jan Tojnar: we could always remove that dependency... https://github.com/NixOS/nixpkgs/issues/66547
<{^_^}> error: syntax error, unexpected ',', expecting ')', at (string):293:4
<{^_^}> #66547 (by aanderse, 33 weeks ago, open): QSql drivers missing
<jtojnar> I wish projects would not try to support everything and be more modular
orivej has quit [Ping timeout: 256 seconds]
<globin> FRidh2: wrt env.* only allowing scalar types is because bash arrays not being possible to be exported
teto has joined #nixos-dev
<globin> see the blog post for more details :)
<FRidh2> yes but env is preprocessed, not?
<FRidh2> so list of strings could be joined
* gchristensen is looking in to why the ofborglog viewer isn't working right
<gchristensen> it seems some change to nginx has caused it to break
<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
<m1cr0man> Yeah ok, interesting
<m1cr0man> My timers have all gone into n/a status
<clever> m1cr0man: theres also `systemctl list-timers`
<m1cr0man> Yeah I see that too clever, also shows n/a
<m1cr0man> but systemctl status shows the Active: line which in my case says active (running) on the timer
<m1cr0man> lassulus' timer says active (waiting)
<m1cr0man> I'll share the output one sec
<clever> m1cr0man: what about the journal for the timer, like `journalctl -f -u zfs-snapshot-monthly.timer` ?
<m1cr0man> Oh zfs timers are working fine
<clever> m1cr0man: just an example, substitute in your .timer for acme
<m1cr0man> Nothing unfortunately, logs have been cleared
<m1cr0man> oh my logstash might have them one sec
<m1cr0man> lassulus: what is the status of the related service? is it active (exited)?
<m1cr0man> inactive (dead) right
<lassulus> this is on 19.09 btw
<m1cr0man> lassulus: oh right yes, that's not using lego
<m1cr0man> lassulus: sorry to keep asking for things, but could you do a systemctl cat acme-lassul.us.service ?
<m1cr0man> Thanks :)
<m1cr0man> Yeah, yeah... I think it's the fact that we have RemainAfterExit in the lego .service
<m1cr0man> Will test...
<m1cr0man> Yeah this is absolutely it damn https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Description see the last line of the description wrt RemainAfterExit
<m1cr0man> Fortunately there's a big old comment on why that was added https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Description I believe I pulled that over from the "other" branch when adding DNS-01
<emily> RemainAfterExit should probably be kept
<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)
<m1cr0man> I'll create an issue on gh for this
orivej has joined #nixos-dev
erictapen has joined #nixos-dev
<clever> gchristensen: could ofborg detect this kind of problem? https://hydra.nixos.org/build/116132269/nixlog/1
<gchristensen> clever: hrm. I thought it did... :/
<clever> gchristensen: https://github.com/NixOS/nixpkgs/pull/84325 ofborg wasnt poked any, so only the fully automatic checks would have caught it
<{^_^}> #84325 (by euank, 8 hours ago, merged): k3s: init at 1.17.3+k3s1
<gchristensen> I'm a bit surprised that FRidh2 merged it :)
justan0theruser has quit [Ping timeout: 272 seconds]
<clever> gchristensen: how does https://github.com/NixOS/nixpkgs/pull/84369 look?
<{^_^}> #84369 (by cleverca22, 21 minutes ago, open): k3s: fix https://hydra.nixos.org/build/116132269
justan0theruser has joined #nixos-dev
<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"
<gchristensen> it could be that!
<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
<LnL> yes, but what do you compare it with?
<LnL> who _should_ have signed what?
<clever> [root@amd-nixos:~]# nix copy-sigs --all -s https://cache.nixos.org
<clever> which can catch if you already have sudo, and now cache.nixos.org has a conflicting sig
<clever> LnL: this will also go over the entire nix store, and re-download the sigs from the cache
<LnL> right, but that's too late
<LnL> and assumes that what you need trust for will be cached, which is not necessarily the case
<erictapen> clever: cole-h: $(out) didn't work out in this case, but I figured, that I can just omit it: "-DGLOBAL_CONFIG_DIR=etc" Thanks!
<erictapen> clever++ cole-h++
<{^_^}> clever's karma got increased to 375, cole-h's karma got increased to 17
<cole-h> Did you try `${placeholder "out"}`? That should work.
<clever> anything you build locally, is a big un-answered question
<clever> yeah
<LnL> you'd almost have to whitelist paths or something, but that's not really workable
<clever> gchristensen: updated https://github.com/NixOS/nixpkgs/pull/84369
<{^_^}> #84369 (by cleverca22, 1 hour ago, open): k3s: fix https://hydra.nixos.org/build/116132269
<domenkozar[m]> infinisil: all of the above you mentioned is on TODO for cachix :)
<domenkozar[m]> proxy caches are quite on the top of the list
<domenkozar[m]> but they will be enforced at the service level rather than user configuration
<domenkozar[m]> because that's the only way to make it consistent
<domenkozar[m]> those will be called proxy caches
<domenkozar[m]> and the speed improvement will be done with a single query to cachix but ordering the caches as a list
<domenkozar[m]> (this could be fixed by tweaking Nix to give more information, but I've given up on that)
<clever> domenkozar[m]: had a look at https://github.com/cleverca22/cachecache/ before?
<clever> its a binary cache cache, and has multiple upstream caches
<clever> so its both caching and proxying
<domenkozar[m]> I have it starred :)
<infinisil> domenkozar[m]: Nice!
<domenkozar[m]> the general setup will be
<domenkozar[m]> nixpkgs -> company public cache -> company private cache
<domenkozar[m]> that covers 99% of what people need :)
<domenkozar[m]> infinisil: proxy caches are 6th in the backlog, most of what's in beforehand is about a day of work :)
<domenkozar[m]> but great feedback as always I'm glad it lines up with what I have in plans :D
asbachb has quit [Remote host closed the connection]
FRidh has joined #nixos-dev
FRidh2 has quit [Ping timeout: 265 seconds]
FRidh has quit [Client Quit]
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
<ryantm> Thank you gchristensen for merging the exactly-one-rebuild label OfBorg PR!
<ryantm> gchristensen++
<{^_^}> gchristensen's karma got increased to 255
<drakonis> that's a interesting choice for a label
<gchristensen> :)
<drakonis> can trivial rebuilds be automerged?
<gchristensen> thank you for the PR!
<cole-h> No
<gchristensen> no, I don't think that is ever appropriate
<cole-h> I don't think we'll ever let anything be automerged
<cole-h> ^
<drakonis> that's fair.
<gchristensen> nice
abathur has quit [Quit: abathur]
<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 = ./.;
<domenkozar[m]> you need to use builtins.path { name = "foo"; src = ./.; }
<ryantm> Ah, okay! I thought that was okay because of the developPackage thing auto cleaning source files, but I guess that's a different issue.
<ryantm> Yeah, that seems to have solved it. Thank you!
<ryantm> domenkozar[m]: I'd appreciate it if you could look at https://github.com/ryantm/nixpkgs-update/issues/179#issuecomment-609481154
<domenkozar[m]> nix-shell -p nix-diff --run "nix-diff a.drv b.drv"
<ryantm> How do I get access to the .drv inside the cachix-cation?
<domenkozar[m]> that one is tricky :)
<ryantm> I would have already diffed it if I knew how :)
<domenkozar[m]> did you grep for `./.` around the codebase?
<domenkozar[m]> usually that's the reason for these differences
<domenkozar[m]> (and use of gitignore)
<ryantm> Okay, I'll try to fix all these "./."s.
<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.
<cole-h> Might be wrong, but I think they were referring to gitignore.nix: https://github.com/hercules-ci/gitignore.nix ? (Which you don't seem to use anyways)
<domenkozar[m]> the other source is <nixpkgs>
<domenkozar[m]> but that one seems to be fixed
<ryantm> I noticed niv has a ./. in it's machinery but I replaced it with `throw "blah"` and it still built.
<domenkozar[m]> I think there's two ways to check:
<domenkozar[m]> NIX_PATH= nix-instantiate ...
<domenkozar[m]> and the other one is to rename parent directory of the root
<domenkozar[m]> so if that gives a different drv then the problem is in one of the Nix functions
<ryantm> All of those changes yielded the same .drv file.
<domenkozar[m]> cabal2nix --compiler=ghc-8.8.3 --system=x86_64-unknown-linux-gnu --sha256= "/nix/store/4hnck3p81xg7fb0jdddm7nah5qfh10zzfvwqx1dwkql4gznnhp104yz5v9-nixpgks-update-src" > "$out/default.nix"
<domenkozar[m]> seems to be this line
<domenkozar[m]> so sources differ
<domenkozar[m]> ah, it's the .git
<domenkozar[m]> is my bet :)
<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
<samueldr> mkdir: cannot create directory '/lib': Permission denied
<samueldr> I followed the build https://hydra.nixos.org/build/115994466
<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]
drakonis has quit [Quit: WeeChat 2.7.1]
justan0theruser has joined #nixos-dev
<ryantm> domenkozar[m]: cole-h: Figured it out! https://github.com/cachix/cachix-action/issues/36
<{^_^}> cachix/cachix-action#36 (by ryantm, 45 seconds ago, open): Reproducibility broken by store-path-pre-build
<cole-h> Ooo! Nice sleuthing!
<cole-h> Sans that last `H`
<cole-h> :P
drakonis has joined #nixos-dev
erictapen has quit [Ping timeout: 240 seconds]
erictapen has joined #nixos-dev