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
bhipple has joined #nixos-dev
madjar has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
lovesegfault has joined #nixos-dev
drakonis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
cole-h has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 255 seconds]
bhipple has quit [Ping timeout: 272 seconds]
cole-h has quit [Ping timeout: 260 seconds]
_ris has quit [Ping timeout: 246 seconds]
<genesis> derivation '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' may not be deterministic: output '/nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12' differs
<genesis> error: build of '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' failed
<genesis> i'm testing gcc breakage that would be the explanation of jack client not working anymore
<genesis> i did : nix-build . --check -A samplv1 , i imagine i should have lauch it as root.
<genesis> can i fix https://nixos.wiki/wiki/FAQ#How_can_I_force_a_rebuild_from_source_even_without_modifying_the_nix_expression.3F adding as root to avoid the error of non deterministic output ?
<genesis> (i've same error as root anyway)
sphalerite has quit [Quit: WeeChat 2.6]
<genesis> btw , rebuilding zynaddsubfx makes it working. so we have our culprit.
sphalerite has joined #nixos-dev
madjar has joined #nixos-dev
sphalerite has quit [Quit: WeeChat 2.7.1]
sphalerite has joined #nixos-dev
sphalerite has quit [Client Quit]
sphalerite has joined #nixos-dev
__monty__ has joined #nixos-dev
<domenkozar[m]> hmm:
<domenkozar[m]> /run/current-system/sw/bin/vim: /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6: version `GLIBC_2.30' not found (required by /nix/store/2n66ha7fnk87jr0yq6ihnl8czwa7iknw-systemd-243.4-lib/lib/libsystemd.so.0)
<domenkozar[m]> /run/current-system/sw/bin/vim: /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6: version `GLIBC_2.28' not found (required by /nix/store/2n66ha7fnk87jr0yq6ihnl8czwa7iknw-systemd-243.4-lib/lib/libsystemd.so.0)
<domenkozar[m]> that doesn't look good
<genesis> how to really force with nix-build and ignore output differ ? i need to fix instruction to let people try to fix jack client and close bug
<genesis> some nix-store --delete but i'm not an expert here.
puck has quit [Ping timeout: 272 seconds]
puck has joined #nixos-dev
roberth has quit [Quit: Idle for 30+ days]
<genesis> i quite fix all jack bugs.
<infinisil> genesis: remove the `result` symlink (not needed if nix-build was called with --no-out-link), then `nix-store --delete $path-out-pointed-to`
<infinisil> path-out-pointed-to can be gotten by assigning `out=$(realpath result)` beforehand
<infinisil> Or with `nix-store -q --binding out $(nix-instantiate -A foo)`
<infinisil> genesis: Although why would a rebuild of the same derivation suddenly work? Because Nix only gives that output differ error if the same derivation (this means the exact same build steps) produces something different
<infinisil> If something truly was fixed with some derivation, the build steps would differ
<genesis> because it links to another libstdc++
<genesis> i donno
<infinisil> A libstdc++ outside of /nix/store?
<genesis> no
<infinisil> If it's a libstdc++ provided by Nix, the derivation should differ for a different libstdc++
<genesis> let me have some checks.
<infinisil> Oh, I'm not sure what that comment means with "rebuild" exactly, because a rebuild of NixOS by itself shouldn't change much, only an upgrade + rebuild should
<infinisil> But doing a `nix-build --check` or similar again certainly is not it
<genesis> i'd change the derivation to force it to build
<genesis> and build with nix-env, that's why i ask to understand how fix instruction in the wiki to have a real rebuild.
<genesis> btw i think people have to force update more the rebuild, to have the cache rebuilded package.
<__monty__> genesis: infinisil is right if something was built with a different gcc version the hashes would most certainly differ.
vcunat has joined #nixos-dev
orivej has joined #nixos-dev
<genesis> __monty__ : sure and it differs, that the goal :D
<__monty__> If it differs there can't be a need to delete something from the store.
<genesis> error: build of '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' failed <- i think it failed because for the same derivation it produice different output
<__monty__> Then the derivation's broken, no?
<genesis> no i rebuild it changing something useless
<__monty__> What do you mean? If it's the same derivation how can it be different?
<genesis> because it use updated toolchain ?
<genesis> i build against the nix in nixpkgs
<__monty__> Do you have the full error?
<__monty__> And infinisil's instructions didn't work?
<genesis> no , even if i force delete with --ignore-liveness i have same error.
<__monty__> Does that store path still exist after deleting? (I wouldn't risk force deleting, way too easy to mess up your DB.)
<genesis> yes it exists
<genesis> seems it recreates by nix-build
<genesis> copying path '/nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12' from 'https://cache.nixos.org'...
<__monty__> I meant before running the build.
<genesis> no, it properly deleted
<genesis> so --check need it to check, i understand it normal to fetch it
<__monty__> Wait, so it's getting a cached output *and* evaluating something that results in an output with the same hash but different contents?
<__monty__> Why is it even building something if the output is already in the store?
<__monty__> What did you actually do? I feel like we're just heaping confusion on top of confusion.
<genesis> that's the purpose of --check ?
<genesis> i try to force rebuild of package that have old libstdc++
<genesis> since it break with new compiled libjack2
<genesis> to close #55574
<{^_^}> https://github.com/NixOS/nixpkgs/issues/55574 (by magnetophon, 1 year ago, open): cadence doesn't see jack
<__monty__> So you override that input for the package? Or you changed the expression? What did you do?
<genesis> i want to rebuild without change the expression, i did change the expression to force rebuild and it fix my stuff
<genesis> so i search the right way to force rebuild of a same expression to close #55574
<{^_^}> https://github.com/NixOS/nixpkgs/issues/55574 (by magnetophon, 1 year ago, open): cadence doesn't see jack
<genesis> #74742
<{^_^}> https://github.com/NixOS/nixpkgs/issues/74742 (by bcaccia, 12 weeks ago, open): Jack Audio does not present any valid output devices
<genesis> but the bug is to mix user and system content, user synth software like samplv1 who have been compiled with different libjack2 will not be able to connect
<genesis> due to ABI breakage and don't find the right symbol
<__monty__> Oh, I think I see the problem. If the expression you want to rebuild properly depends on the other expression you changed then it shouldn't result in the same hash.
<genesis> check is not the right option imao to do that.
<genesis> so question is still , How_can_I_force_a_rebuild_from_source_even_without_modifying_the_nix_expression.
<jtojnar> I still do not understand why would you need to force the rebuild
<jtojnar> If you change libstdc++, you are modifying the expression
<__monty__> jtojnar: I think the confusion is they believe the expression they want to rebuild is unchanged, because they didn't touch it but only a dependency of it.
<genesis> i don't want the cache version.
<__monty__> genesis: The problem is the expression you're trying to rebuild is depending on the old version of the dependency you changed rather than the new one.
<jtojnar> --check is used if the package is bit-for-bit reproducible
<jtojnar> But it does not matter for regular usage of it is not
<jtojnar> s/used if/used to check if/
<genesis> i'm confusing, it seems i'm not able to explain a simple breakage that need recompile jack clients against same gcc toolchain and need no modification in the derivation
<__monty__> Guess I was wrong then. Sounds like it really is a non-deterministic expression.
<__monty__> genesis: GCC is an input of expressions, through stdenv, if it changes the derivation *does* change.
<genesis> i agree with that
<__monty__> Then why don't you see your claim makes no sense? "no modification in the derivation"
<genesis> because i speak of the nix expression i guess
<__monty__> The weird thing is that `--check` tries to compare a build of something to the cached version (afaiu). And you *are* getting different outputs for the same hash. So the expression must be non-deterministic.
<genesis> it seems to be yes.
<genesis> i can diff the check directory and cache one to see the diff
<__monty__> And, afaiu, that could be a problem. Some non-determinism is harmless but it could prevent something from being cacheable.
<genesis> # LANG=C diff -rq /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12 /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12.check/
<genesis> Files /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12/share/man/man1/samplv1.fr.1.gz and /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12.check/share/man/man1/samplv1.fr.1.gz differ
<genesis> Files /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12/share/man/man1/samplv1.1.gz and /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12.check/share/man/man1/samplv1.1.gz differ
<jtojnar> Well if you change the derivation, the package will get rebuild. Nix does not care whether your touched the expression or not, just what it evaluates to
<__monty__> jtojnar: Yes, but if the derivation were changed the hashes would differ no? And --check is reporting different output for the same hash?
<jtojnar> And most non-determinism should not matter, it is often just timestamps in the manual pages
<jtojnar> Yes, the hashes are computed from the result of the evaluation IIRC
<genesis> if i don't touch the expression, i've to find how to rebuild it without it takes from cache
<jtojnar> Well it will always take it from the cache if it evaluates to the same hash
<__monty__> jtojnar: It sounds to me like the non-determinism matters in this case because with a trivial change to the expression, to change the hash, genesis is saying it works. While the cached version doesn't work.
<genesis> jtojnar : if stdenv has changed, it shouldn't
<genesis> no i don't say that __monty__ , i say since i'm not able to rebuild without change the expression, i did change it and so it changed the derivation
<genesis> and fix the issue.
<jtojnar> If stdenv has changed, it will evaluate to a different derivation and thus a different hash
<jtojnar> And will need to be built if the hash is missing from cache
<__monty__> genesis: Why are you passing `--check` actually?
<__monty__> genesis: So what *did* you change in your nixpkgs checkout?
<genesis> the pb is using a system and user different cache
<genesis> broken cache when i use system /nix/store/7l573r73dqfisf6mjngsyg2xg3dsfvc9-zynaddsubfx-3.0.5/bin/zynaddsubfx
<genesis> and working stuff in cache too /nix/store/sqb7cjb0gjv503k8nrpqjz0fi11r6qgq-zynaddsubfx-3.0.5/
<__monty__> pb? PR? "a system"? "user cache"?
<genesis> problem/issue
<genesis> on my system nixos https://nixos.org/channels/nixos-19.09
<genesis> on my user nixpkgs https://nixos.org/channels/nixpkgs-unstable
<genesis> so mixing different clients /Server compiled against differents libjack2 make them incompatible
<genesis> i think that's the issue.
<pie_[bnc]> genesis: oh hi im deliciouslytyped
<genesis> hi pie_[bnc] :)
<genesis> i'm still working on pie_[bnc] , i think i get the main issue on jack, and explain why some people have working setup for some stuff and not for other
<__monty__> genesis: Ok, and how do you expect to fix that problem? You can't force a user to use the system channel.
<pie_[bnc]> genesis: good luck. it wasnt clear to me from your github comment what the problem is. things need to be compiled with a new version of gcc?
<pie_[bnc]> hm <__monty__> jtojnar: It sounds to me like the non-determinism matters in this case because with a trivial change to the expression, to change the hash, genesis is saying it works. While the cached version doesn't work.
<pie_[bnc]> ill have to go back and read the scroll at some point..
<__monty__> pie_[bnc]: I was mistaken the diff genesis shared shows that it's probably just differing timestamps in manpages.
<genesis> i say my nixos cache version of a client like zynaddsubfx is not compatible with my jackdbus depending on my own cadence expression
<genesis> but the nixpkgs zynaddsubfx works
bhipple has joined #nixos-dev
<pie_[bnc]> I wonder if this stuff works in a build-vm
<pie_[bnc]> might be possible to make a full repro
<pie_[bnc]> (probably unnecessary)
evils has quit [Ping timeout: 265 seconds]
<genesis> i'll update my comment and i think the nixos update will fix things __monty__
<genesis> since if i understand, all is rebuild against same stuff.
<genesis> pie_[bnc] : if you have an example of something not working, you can make some test.
bhipple has quit [Remote host closed the connection]
<genesis> i just tested with yoshimi, same things, it works .
<srk> 29+6
<genesis> next (lash)
<pie_[bnc]> hmm
<jtojnar> But the same derivation would have the same ABI
genesis has quit [Remote host closed the connection]
genesis has joined #nixos-dev
<genesis> nixos's qjackctl with nixpkgs jackdbus just crashed my dbus
<genesis> nixpkgs qjackctl => works fine.
<jtojnar> Well if you refer to qjackctl derivation from nixpkgs-unstable and nixos-unstable channels respectively, those might be different
<infinisil> I was actually able to fetch a nixpkgs and evaluate it with proper IFD (so no fetchTarball!)
<gchristensen> neat!
<infinisil> However there's a problem
<gchristensen> uh oh
<infinisil> You need to either provide the hash of the tarball, and I think github doesn't make those deterministic
<infinisil> like the tarball itself, not the unpacked result
<gchristensen> tarballs yes I think, zips no
<infinisil> Oh then this might not be too bad
<gchristensen> fetchFromGithub learned a "private" option :(
<infinisil> gchristensen: This is how it looks, pretty raw: https://paste.infinisil.com/AteA3spV_A.nix
<gchristensen> intense :)
<infinisil> Oh wait, remove the outputHash stuff
<infinisil> infinisil: Do it yourself, it's your paste damnit
<gchristensen> hehe
<infinisil> There :)
<infinisil> gchristensen: Also fetchFromGitHub can do submodule fetching and all other things fetchgit can
<gchristensen> that one seems fine
<gchristensen> a bit weird, but fine. the `private` option, though ...
<infinisil> Hm yeah that's a bit of a different beast
<infinisil> But with the approach I'm using here any of those won't work as easily
<infinisil> This is more of just a fetchTarball replacement
<gchristensen> is this just for experiments / testing?
<infinisil> I want to see if this still gets GC'd
<gchristensen> cool
<infinisil> E.g. if you build hello from it, then do a GC with keep-outputs true
<infinisil> Lemme see..
<gchristensen> oh no, emacs is crashing
<infinisil> stable emacs?
<gchristensen> definitely not
<infinisil> Heh
<gchristensen> it is the pgtk branch from https://github.com/masm11/emacs from somerandom point in time
<infinisil> Idea: Let's enable debugging symbols and coredumps and other debugging things for unstable, allowing easy debugging of all kinds of things. Turned off on stable then
<gchristensen> could be nice
<jtojnar> Core dumps are enabled, are not they?
<gchristensen> one thing about separate debugging symbols is the channel update tooling has to take an explicit step for them afaik, and that tooling is probably not up to the task of all of the packages having separate debug symbols all of a sudden
<infinisil> Oh, yeah seems to be the case jtojnar
<gchristensen> yeah coredumps are definitely enabled
<infinisil> Oh yeah and the IFD experiment above still makes GC collect the I'd D's
<gchristensen> heh
<infinisil> Which I guess I should have expected from https://github.com/NixOS/nix/issues/719
<{^_^}> nix#719 (by wizeman, 4 years ago, open): Nix garbage collects too much
<gchristensen> I always wanted to have lorri implement this part, but we've not gotten there. the idea of lorri is to experiment with these ideas and implement / backport / improve Nix as much as possible in the end.
<infinisil> Can somebody with nix permission bits change the title of that issue to e.g. "Nix GC collects derivations used for IFD"?
<infinisil> gchristensen: Nice, that would be awesome
<domenkozar[m]> sure
<domenkozar[m]> done
<infinisil> Thanks :)
<gchristensen> Thanks :)
<gchristensen> TIL: `nix-shell`'s `--exclude` option
<infinisil> TIL
<gchristensen> yesterday while playing with my `exactSource` function, I was thinking about differentiating data variables from function variables with camelCase vs. snake_case
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<domenkozar[m]> haskell all the things!
* domenkozar[m] ducks
<gchristensen> I get the impression domenkozar[m]'s Matrix gateway may be delayed :)
<domenkozar[m]> heh
<gchristensen> that or I'm not understanding what your Haskell comment was about :x
<domenkozar[m]> as haskell enforces that naming differentiation
<gchristensen> ah cool
<gchristensen> I didn't know that
<domenkozar[m]> well, only the first char case, but still noone would be Camel_Casing
<gchristensen> oh you just wait
<gchristensen> :P
<domenkozar[m]> there's always someone isn't it :D
<emily> domenkozar: hm? there's no convention for function vs. non-function typed variables in haskell
<emily> the function is for types/"meta level things" vs. data, which isn't what gchristensen meant (afaict?)
<emily> I think gchristensen means some_string, someFunction
<emily> which personally just seems like a regression to me in a higher-order functional language
<domenkozar[m]> I understand those inputs as newtypes with a constructor, but then since there are no static types it's hard to compare much
Willi_Butz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
<emily> fair enough
<infinisil> > isn't = x: ! x
<{^_^}> isn't defined
<infinisil> > isn't true
<{^_^}> false
<infinisil> > yesn't = select [ false true ]
<{^_^}> yesn't defined
<infinisil> > yesn't
<{^_^}> false
<emily> ;w;
<emily> i didn't know nix allowed apostrophes too
<gchristensen> infinisil: no
<infinisil> gchristensen: Hm you make a point, yesn't isn't just yes or no, it's a quantum state between the two. I shall commence to implement a quantum computer simulation in Nix
<gchristensen> now you're cooking :D
<infinisil> :D
<Profpatsch> gchristensen: do it like all fp programmers that have reached Nirvana and call your functions f g h, your arguments x y z and your type variables a b and c: )
<Profpatsch> if it’s a list, xs is the way to go :P
<gchristensen> lol
<emily> hey the s suffix for lists is a legitimately good convention that I miss in other languages :p
<emily> at the limit haskell naming conventions turn into a kind of pseudo hungarian notation
<emily> it's cursed but convenient
<gchristensen> naming things is an affordance to people anyway
<vcunat> gchristensen: 20.03-small is stuck for a week but Hydra has been looking fine all the time. Generally, is there a way how I/someone can help with that?
<vcunat> I poked around https://status.nixos.org/ (grafana, prometheus), but I could find nothing useful for this situation.
<vcunat> It's nothing that needs an "immediate" fix, I think.
<gchristensen> there was an issue with the revCount calculation being improper and needing fixing, causing a "back-in-time" issue. I'll take a look in a few minutes -- but I'm hoping it is that?
<vcunat> But I see this occasionally happening, and it might be nice if there are ways people can help with the more common blockers.
<gchristensen> +1
<gchristensen> https://status.nixos.org/prometheus/alerts and https://status.nixos.org/grafana/d/fBW4tL1Wz/scheduled-task-state-channels-website?orgId=1&refresh=10s are going to be helpful there, and it would be nice to have even more tools public
<gchristensen> tools & data
<vcunat> I saw those, but 20.03-small isn't shown as abnormal in there, as far as I can see.
<gchristensen> yeah it isn't
<gchristensen> since https://status.nixos.org/grafana/d/fBW4tL1Wz/scheduled-task-state-channels-website?orgId=1&refresh=10s shows regular execution, and doesn't list it as failed it must mean it is not actually failing to execute -- and something else is wrong. let's dig!
<vcunat> I'd look into logs of that task.
<vcunat> (if I could)
orivej has quit [Ping timeout: 255 seconds]
<gchristensen> I really regret "fixing" the revCount thing.
<gchristensen> vcunat: I think I can disable that check for one run, and fix it.
<vcunat> Yes, that's it.
* emily is trying to fix pypy openssl, fwiw: https://github.com/NixOS/nixpkgs/pull/81300
<{^_^}> #81300 (by emilazy, 1 minute ago, open): pypy: use openssl_1_1
<emily> (since it breaks icestorm which I maintain. just mentioning in case anyone else is also working on it)
<emily> not sure if even the aarch64 ofborg builder will be able to bootstrap pypy before timing out, but I'm running it on my server too
<vcunat> It has lots of cores, but I can't remember if that helps a lot in pypy* case.
<niksnut> I thought I fixed the revCount thing
<gchristensen> hmm
<niksnut> and it did update after that
<niksnut> or so I thought
<niksnut> trying again...
<gchristensen> niksnut: hold up
<gchristensen> aminechikhaoui: ping?
<samueldr> maybe we can't use SRI hashes right now? https://github.com/NixOS/nixpkgs/pull/81211#issuecomment-592491223
<gchristensen> let's fix fetchpatch? :)
<samueldr> what's weird is that... it worked?
<emily> vcunat: only for building both pypy and pypy3 simultaneously
<samueldr> I built firefox, so I'm wondering what's the difference in thefloweringash's setup
<emily> vcunat: it's a compute-bound single-process Python program, aka the worst
<emily> oh, and it doesn't even build on aarch64 in the first place :(
<vcunat> At least the build has beautiful log output.
<gchristensen> lol
<emily> you don't get the colours on ofborg :3
<gchristensen> want to PR a terminal-colors -> HTML thing to the log viewer?
<emily> haha
<emily> totally worth it just for pypy
<gchristensen> it'll take some back-end work, but we can do it!
<emily> I might take a look at it... I'm a bit allergic to both js ecosystem dev and ANSI terminal codes though
<emily> the latter from too much experience
<gchristensen> alas
<gchristensen> it would be a GREAT improvement.
<emily> setting up a pty to even get stuff to give you colours can be a bit fussy I think
<gchristensen> Nix handles that automatically
<gchristensen> ofborg explicitly strips them out because the log viewer doesn't handle them
<samueldr> gchristensen: if the bytes are not munged before being sent over the queue, it's probably trivial enough to do
<samueldr> oh
<gchristensen> easy enough to fix
<thefloweringash> samueldr: it’s a minor I’m incompatibility in fetchpatch. You should be able to reproduce by removing the FOD from the store and trying to recreate it with nix-build
<thefloweringash> Uh, s/I’m //
<thefloweringash> The hash is still equivalent at the nix layer, so if you build with the base32 hash and then revert to the sri hash it will still be available to build Firefox.
<gchristensen> that is ... interesting ...
<gchristensen> maybe, then, nix should internally normalize it
<thefloweringash> I’m not sure you can. Hmm. It passes through fetchpatch before nix gets a chance to see it.
<gchristensen> right
<samueldr> thefloweringash: I never built with the base32 hash... and built using nix-build... though I did build with a 52i0 tofu
<samueldr> or let me rephrase, I used a base32 tofu hash, nix gave me an SRI hash
<thefloweringash> I think that’s sufficient to sidestep the issue. FOD builds with hash mismatches produce valid store paths under the correct hash. (Right?)
<gchristensen> vcunat: updated, thanks
<samueldr> I think so
<aminechikhaoui> gchristensen pong
<gchristensen> aminechikhaoui: I had a question for you, but I think I managed to answer it just acouple minutes ago:) thanks
<samueldr> what I don't know is which hash representation is used, and why
<aminechikhaoui> :-)
<vcunat> gchristensen: thanks :-)
<gchristensen> thank you, and thank niksnut :)
cole-h has joined #nixos-dev
<thoughtpolice> Curious, but is there any ETA on Nix 2.4? Wondering if there's anything still planned or if things are just cooking like usual, just wanted to try recursive nix but was just thinking out loud...
drakonis has joined #nixos-dev
ixxie has joined #nixos-dev
psyanticy has joined #nixos-dev
mkg20001 has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 240 seconds]
bennofs[m] has quit [Ping timeout: 240 seconds]
Nyanloutre[m] has quit [Ping timeout: 256 seconds]
dtz has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
mkg20001 has joined #nixos-dev
madjar has quit [Quit: Connection closed for inactivity]
Nyanloutre[m] has joined #nixos-dev
bennofs[m] has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
vcunat has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-dev
_ris has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
lovesegfault has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
evils has joined #nixos-dev
<cole-h> Posted this in #nixos, but figured it might be better suited here
<cole-h> I think borg is broken. The recent `haskell-updates` merge marked ShellCheck as broken leading to https://gist.github.com/GrahamcOfBorg/08b50d20a8ab34e93e22843a396a736e
<gchristensen> cole-h: ofborg is not broken, marking shellcheck as broken broke the evaluation of NixOS.
<cole-h> Oh, I see. I conflated two different things, sorry ^^;
<gchristensen> no worries :)
<gchristensen> though hopefully someone fixes shelcheck being broken!
<gchristensen> either by revert or a fix
<cole-h> https://github.com/koalaman/shellcheck/issues/1778 Too bad there haven't been any new releases
<{^_^}> koalaman/shellcheck#1778 (by peti, 9 weeks ago, open): Setup.hs is broken with Cabal 3.x
<gchristensen> cole-h: maybe leave a comment?
<cole-h> On that issue, asking for a new release? Sure, what have I got to lose :P
<gchristensen> also please comment on the commit fdrom peti updating / breaking things and let him know the problem
<cole-h> I'll do that first
<gchristensen> thanks
<cole-h> Guess it's time to be That Guy™
<cole-h> Hope they don't take offense
<cole-h> If anybody wants to chime in with better wording or more information, same link as above: https://github.com/koalaman/shellcheck/issues/1778
<{^_^}> koalaman/shellcheck#1778 (by peti, 9 weeks ago, open): Setup.hs is broken with Cabal 3.x
orivej has quit [Ping timeout: 240 seconds]
drakonis_ has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 255 seconds]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
<jtojnar> emily: we can do it in haskell-modules/configuration-common.nix
<jtojnar> see for example the bustle fix
drakonis_ has joined #nixos-dev
<jtojnar> and rm Setup.sh in postPatch
<jtojnar> and run ./manpage in postBuild
<jtojnar> ^cole-h
phreedom_ has quit [Ping timeout: 240 seconds]
phreedom has joined #nixos-dev
<cole-h> How does one limit fetchpatch to a specific file?
<jtojnar> cole-h using includes argument
<cole-h> Just found it in its default.nix -- thanks.
<cole-h> jtojnar: Thanks for the pointers. Building now, PR up soon
<jtojnar> cole-h++
<{^_^}> cole-h's karma got increased to 3
<cole-h> (btw, also needed manpage in the includes since we want to run it :P)
<cole-h> jtojnar++
<{^_^}> jtojnar's karma got increased to 32
<jtojnar> right
<cole-h> Does it matter where I put the override? Because the file doesn't appear to be sorted alphabetically...
<jtojnar> I usually stick it to the largest cluster of attrs starting with the same letter
<jtojnar> that would still put it somewhat correctly
<jtojnar> the issue is all-packages is partly split into categories
<cole-h> (This is haskell-modules/configuration-common.nix I'm talking about :P)
<jtojnar> there are category header comments in all-packages.nix
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
<jtojnar> grep for ^ ###
<cole-h> Hmm, adding `manpage` to the includes doesn't appear to create it...
ixxie has joined #nixos-dev
<jtojnar> right, not only cannot fetchpatch delete files, it cannot create them either
<jtojnar> but it looks like the manpage was not installed previously either so we can ignore it
<cole-h> lol :D
<cole-h> Could also just copy the script into postBuild as-is
drakonis_ has quit [Read error: Connection reset by peer]
<jtojnar> also will need pandoc in buildTools
<cole-h> Nah, that's too smart (lol yeah, a better idea)
<lovesegfault> What's the process to bump systemd?
<lovesegfault> We're behind one version
<lovesegfault> and apparently we use a fork?
<cole-h> Very hard because we use a fork with non-upstreamable patches (or so I've heard)
drakonis1 has quit [Quit: WeeChat 2.7.1]
__monty__ has quit [Quit: leaving]
<cole-h> If I fetchurl the manpage script and try to execute it, I get permission denied. Did I forget something?
<jtojnar> chmod +x?
<cole-h> Not allowed. Apparently I need to set `recursiveHash = true;`. https://nixos.org/nix-dev/2016-January/019269.html
<cole-h> Oh wait, apparently there's an executable arg for fetchurl
<cole-h> Or rather, there WAS one, in 2016
<jtojnar> it is still there
<cole-h> Oh, I'm blind and cannot type. I was Ctrl+F'ing for "exectuable" :D
<jtojnar> also it has /bin/sh as shebang (not available in sandbox) so you will need to run it using runtimeShell or something
drakonis has joined #nixos-dev
<cole-h> It appears to work fine without using runtimeShell. Maybe I'm not actually sandboxed
<jtojnar> maybe I misremembered and it is just /usr/bin/env that is not available in sandbox
<cole-h> Looks like jonringer beat me to it :D https://github.com/NixOS/nixpkgs/pull/81334/
drakonis_ has joined #nixos-dev
<jtojnar> but in-tree patch, eugh
<cole-h> :D
<cole-h> I could send in a follow-up, fetching from the repo and enabling manpage generation if he merges without that
<jtojnar> also will likely need to install -D -t $out/share/man/man1/ shellcheck.1 in postinstall
<cole-h> I should also probably check out the real attr and see if I need to avoid clobbering the post* stuff
<cole-h> How nice, it appears it doesn't have that stuff.
<gchristensen> multun: ping?