worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
rajivr has joined #nixos-dev
jonringer has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
dhess has quit [Remote host closed the connection]
m1cr0man has joined #nixos-dev
cole-h has joined #nixos-dev
ris has quit [Ping timeout: 256 seconds]
<hexa-> supersandro2000: your EOL message could use a more friendly tone
<hexa-> please thank the respecitve author for their contribution and explain that due to $issues it couldn't be merged in time and unfortunately 20.03 is now EOL.
<hexa-> :)
<hexa-> other than that, thanks for taking care of closing stuff
<infinisil> Btw github has a "saved replies" feature, where you can save replies for easy reuse
<infinisil> Also, you can search for "base:release-20.03 is:open" to find any remaining 20.03 PRs :)
<infinisil> Also, supersandro2000++ for banging out those reviews and merges recently!
<{^_^}> supersandro2000's karma got increased to 16
<hexa-> indeed, totally worth it
andi- has quit [Remote host closed the connection]
andi- has joined #nixos-dev
orivej has joined #nixos-dev
<supersandro2000> hexa-: I can't copy this message like it is?
<supersandro2000> also the two PRs where backports which do not matter anymore.
<supersandro2000> infinisil: I am not closing all of them. I just stumbled over two very old and thought why not.
<supersandro2000> the mass close should be done by someone with a script or I go crazy
<supersandro2000> there are 5 more... lol
<supersandro2000> closed them with a friendly comment :)
<hexa-> supersandro2000: copy which message?
<hexa-> your latest message sounds totally fine
abathur has quit [Quit: abathur]
marek has quit [Ping timeout: 260 seconds]
abathur has joined #nixos-dev
marek has joined #nixos-dev
<supersandro2000> > due to $issues it couldn't be merged in time and unfortunately 20.03 is now EOL.
<{^_^}> error: syntax error, unexpected $undefined, expecting ')', at (string):437:8
<hexa-> copy whatever you like
<supersandro2000> I mean with $issue
<supersandro2000> not swapping it out
alp has joined #nixos-dev
<Ericson2314> lopsided98: I'm trying to gauge whether I have time to embark on the journey to the holly grail of buildRustCrate-ing rustc and the standard library (the latter via -X build-std) :)
<Ericson2314> I think I mentioned that to you before?
cole-h has quit [Ping timeout: 246 seconds]
<lopsided98> Yes, I think that's a great idea.
<lopsided98> I'd be glad to review anything you work on, but I'm not planning to start on it myself in the near future.
<lopsided98> Ericson2314: Although I'd think the biggest benefit would come from just focusing on std so we can support multiple targets with one rustc. It seems like using buildRustCrate for all of rustc might just be a bigger maintenance burden.
<Ericson2314> lopsided98: that's a good point
<Ericson2314> But also I think buildRustCrate for rustc will be comparatively easy 🙂
<lopsided98> Ok, I'm not really familiar with the rustc build process. I was just thinking that there seemed to be a lot of crates involved :)
<Ericson2314> lopsided98: well a lot of crates, but i don't think any funny IO or other externalities
<Ericson2314> except for maybe the ones linking LLVM
<Ericson2314> but there's always cranelift
<lopsided98> Would you use crate2nix, or do it all by hand?
<Ericson2314> lopsided98: crate2nix
<Ericson2314> i think that's the way to justify the maintainability
<lopsided98> Ericson2314: ok, yeah, that shouldn't be too hard to maintain
alp has quit [Ping timeout: 272 seconds]
<Ericson2314> fingers crossed!
<samueldr> [01:49:12] <supersandro2000> is it cool to just revert a commit to fix a package or should I do it as a part of a package upgrade?
<samueldr> there is no straight unambiguous answer
<samueldr> as it all depends on the specifics
<supersandro2000> #94856
<{^_^}> https://github.com/NixOS/nixpkgs/pull/94856 (by dguibert, 16 weeks ago, open): wpsoffice: 11.1.0.9505 -> 11.1.0.9615
<supersandro2000> I just amended it
<supersandro2000> the upgrade requires it, not that it broke something before
<samueldr> right, so no revert needed
alp has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
tilpner has joined #nixos-dev
alp has joined #nixos-dev
jonringer has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
marek has quit [Ping timeout: 260 seconds]
marek has joined #nixos-dev
alp has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
AlwaysLivid has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
marek has quit [Ping timeout: 240 seconds]
marek has joined #nixos-dev
alp has joined #nixos-dev
* lukegb sighs
<lukegb> staging is, predictably, broken :P
<FRidh> what isbroken?
<lukegb> FRidh: https://github.com/NixOS/nixpkgs/pull/105355 (cmake 3.19.0 breaks libressl's build, which appears to break nixos tests)
<{^_^}> #105355 (by lukegb, 1 minute ago, open): cmake: 3.19.0 -> 3.19.1
<lukegb> just rerunning the tests I was trying to run with that cherrypicked :P
<lukegb> perhaps I'm being a little over-diligent with https://github.com/NixOS/nixpkgs/pull/105275
<{^_^}> #105275 (by lukegb, 16 hours ago, open): pulseaudio: 13.0 -> 14.0
<siraben> Are there hydra jobs testing cross-compilation of packages?
<siraben> I'm under the impression that many compilers do not cross-compile atm
<srk> some, for nixos-mobile iirc
ris has joined #nixos-dev
<FRidh> ah yes I saw that failure
__monty__ has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
mkaito has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<siraben> ryantm: I opened #105364
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105364 (by siraben, 2 minutes ago, open): doc/stdenv/cross-compilation: convert to markdown
<lukegb> hmm
<lukegb> I wonder if we could make a GitHub Action that does a test deploy somewhere if people touch doc/ or nixos/doc/
<lukegb> thoughts? can probably whip something up with netlify :P
<siraben> Yeah, sounds useful since it currently appears the build has to be done manually by the authors and reviewers
<gchristensen> docs are tricky because it could be a mass rebuild, take hours to build, and then fail -- but should not be a red X
<siraben> Hm the PRs I've tested and modifications I've done to the docs haven't taken long to build
<MichaelRaskin> But if you also do a stdenv change…
<MichaelRaskin> And document it…
<lukegb> Hrm, yeah
<infinisil> The docs could always be built against a stable pkgs
<MichaelRaskin> Unless you update the docs and bump the toolchain to fix a bug uncovered by the change to docs?
<lukegb> It depends what the goal is :P
<gchristensen> or create a tool that you want to use with the docs
<lukegb> You can get 99% of the way there quickly, or 100% of the way there slowly
<infinisil> `import <nixpkgs/doc> { pkgs = pkgsStable; }`
<infinisil> A bit trickier for nixos dos probably
<MichaelRaskin> By now I have no idea what the goal of the docs is, as any discussions of purpose are structure have been moved aside to finish the format transition to better support the unstated goals of docs
<lukegb> haha
<infinisil> I'm kind of hoping we can just wipe the docs and restart fresh, with clear goals
<infinisil> Of course, ain't nobody got time for that though
<MichaelRaskin> I would prefer resetting Nix to the state currently documented by the Nix manual
<infinisil> Hehe
<infinisil> Are flakes documented?
<MichaelRaskin> Definitely not well
<lukegb> They shouldn't be, they're experimental! *bonk*
<MichaelRaskin> echo '"qwe"' > direct.nix; nix-shell -p nixUnstable --run 'nix-instantiate --eval-only --pure-eval direct.nix'
<siraben> I would use flakes if they were documented more
<MichaelRaskin> It is unclear to me why _this_ behaves like it does from Nix manual, so let's roll back to before that mess and follow the crrent manual
<siraben> Even after seeing Eelco's talk and others, it's not totally clear
<infinisil> MichaelRaskin: "access to path '/home/infinisil/test/direct/direct.nix' is forbidden in restricted mode"?
<MichaelRaskin> Yes
<infinisil> Ah yeah, that's pure eval mode, you can't access arbitrary paths anymore
<infinisil> ,pure-eval
<{^_^}> Pure evaluation was introduced in Nix 2.0, it makes Nix evaluation completely reproducible, see https://github.com/NixOS/nix/commit/d4dcffd64349 for details
<MichaelRaskin> It is not _arbitrary_
<infinisil> Read that commit message for explanation
<MichaelRaskin> It fails to access the only path given on the command line
<lukegb> "Thus 'nix build -f ./foo.nix' is not allowed."
<lukegb> Working as documented-in-commit-message? :P
<MichaelRaskin> Yes, this is not clear from manual, and it is bad
<MichaelRaskin> Having a whitelist of permitted VCS is bad
<FRidh> ohh fun, python packaging, having introduced support for multiple build systems, is now a pain to bootstrap
<lukegb> Because you have to build all of the build systems?
<FRidh> they depend on each other
<lukegb> D'oh.
<FRidh> and a bunch of packages in between
<lukegb> I'm currently trying to run some nixos tests at staging+my PR
<lukegb> which is going about as well as you'd imagine
<FRidh> at some point setuptools and pip released versions not vendoring their deps...all hell broke loose...and so it got reverted
<lukegb> I'll let you know once it's finished compiling all of NixOS
<FRidh> https://github.com/pypa/packaging/issues/363 wasn't the first to notice one package changing backend breaking building for everyone
<{^_^}> pypa/packaging#363 (by ahesford, 9 hours ago, open): Reliance on flit makes packaging incompatible with Void, Arch and Alpine Linux package systems
<infinisil> If I were to create a label for PR's that are interesting or novel, what name would you give that label? Some examples of PR's that would be labeled with it: #105319 #101127 #87661 #91724
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105319 (by rissson, 9 hours ago, open): nixos/pam: rework of the entire module
<{^_^}> https://github.com/NixOS/nixpkgs/pull/101127 (by deviant, 5 weeks ago, open): nixos/defaults: init
<{^_^}> https://github.com/NixOS/nixpkgs/pull/87661 (by dasJ, 28 weeks ago, closed): nixos/systemd-sandbox: A generic sandboxing module
<{^_^}> https://github.com/NixOS/nixpkgs/pull/91724 (by Luis-Hebendanz, 22 weeks ago, open): Firefox nix addon support
<infinisil> Also kind of PR's that a lot of effort was put into in order to make major improvements
<infinisil> The kind of PR's you don't want to get lost in the sea of PR's
<FRidh> Is the focus interesting/novel, or generally human labour intensive?
<infinisil> interesting/novel
<infinisil> Because you can have huge amounts of work for relatively simple changes that don't end up improving anything by much in the end
<FRidh> then I think you have your label. Note however interesting is personal.
<infinisil> Hm I just came up with "interesting" and "novel" on a whim, but maybe those are good at describing this
<infinisil> I like "novel" more than "interesting" though
<infinisil> Unfortunately many of these PR's don't end up getting merged, which is kind of sad..
<infinisil> E.g. I think #87661 would have been a great idea, and I don't agree with its closing statement
<{^_^}> https://github.com/NixOS/nixpkgs/pull/87661 (by dasJ, 28 weeks ago, closed): nixos/systemd-sandbox: A generic sandboxing module
<ryantm> Please self nominate as shepherd for https://github.com/NixOS/rfcs/pull/80 we want to get it through as quickly as is reasonable so we can minimize uncertainty.
<{^_^}> rfcs#80 (by jonringer, 7 hours ago, open): [RFC 0080] Change NixOS releases to YY.05,YY.11
red[evilred] has joined #nixos-dev
<red[evilred]> oooh
<red[evilred]> infinisil (IRC): It's kinda sad too so see that branch deleted - a lot of good work in there that could be useful in the future
cole-h has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
sorki has joined #nixos-dev
sorki has quit [Remote host closed the connection]
sorki has joined #nixos-dev
jonringer has joined #nixos-dev
alexarice[m] has quit [Quit: Idle for 30+ days]
sorki has quit [Remote host closed the connection]
sorki has joined #nixos-dev
<infinisil> Left a comment in #87661 arguing for it
<{^_^}> https://github.com/NixOS/nixpkgs/pull/87661 (by dasJ, 28 weeks ago, closed): nixos/systemd-sandbox: A generic sandboxing module
<MichaelRaskin> infinisil: I guess stuff that is old and _not_ deleted is an easier starting point for idea necromancy
cole-h has quit [Ping timeout: 256 seconds]
euandreh has quit [Remote host closed the connection]
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
alp has joined #nixos-dev
<risson> infinisil: what not add a label containing both "interesting" and "novel"
<infinisil> I think I'll go with "novel" only, that sounds less subjective
rajivr has quit [Quit: Connection closed for inactivity]
kalbasit has joined #nixos-dev
mkaito has quit [Quit: WeeChat 2.9-dev]
FRidh has quit [Quit: Konversation terminated!]
alp__ has joined #nixos-dev
alp has quit [Ping timeout: 260 seconds]
sorki has quit [Remote host closed the connection]
sorki has joined #nixos-dev
alp__ has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 256 seconds]
<V> infinisil: what about "impactful", if the intent is to convey significance of some kind?
<infinisil> Oh nice, yeah that kinda sounds better
<MichaelRaskin> I am not sure impactful is what you want to assign to PRs you want to see merged in reasonable time
<V> reasoning being? I don't expect it to increase bikeshedding, there's plenty of that by default
<MichaelRaskin> Impactful sounds like it actually has a large blast area
<MichaelRaskin> Pretty often novel PRs providing new solutions do not change old stuff
<V> that's not a connotation I have for the word
<V> generally I'd just take it to mean "has significant impact and/or is very effective"
<gchristensen> for prior art on that consider the 1998 foundational classic starring Robert Duvall, Deep Impact
<MichaelRaskin> Two most frequent contexts for impact in Nixpkgs issues: amount of rebuilding, and change in the closure sizes
<V> ¯\_(ツ)_/¯
ChanServ has quit [shutting down]
ChanServ has joined #nixos-dev
supersandro2000 has quit [Ping timeout: 260 seconds]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
<infinisil> MichaelRaskin: This isn't about having PR's merged in a reasonable time
kalbasit has quit [Ping timeout: 256 seconds]
alp__ has joined #nixos-dev
orivej has joined #nixos-dev
maljub01 has quit [Quit: Ping timeout (120 seconds)]
maljub01 has joined #nixos-dev
supersandro2000 has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
justanotheruser has quit [Ping timeout: 265 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner_ has joined #nixos-dev
tilpner_ has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
kalbasit has joined #nixos-dev
<risson> Who wants to debug some infinite recursion in submodules x)
<infinisil> risson: I can't promise anything, but I consider myself pretty good at that :)
<risson> any hint is much appreciated
<risson> the problem I'm facing is described in https://github.com/NixOS/nixpkgs/pull/105319#issuecomment-735474918
<infinisil> risson: And the error is?
<risson> `infinite recursion`
<risson> In the options part of my submodule
<infinisil> Well yes
<infinisil> But I want to see the full error, with a stack trace
<infinisil> risson: Got a command to reproduce it?
<risson> nix-build nixos/tests/krb5 --show-trace
<risson> On the branch of the PR, with the patch applied
MichaelRaskin has quit [Quit: MichaelRaskin]
<infinisil> risson: Um, and how do I apply that patch? `curl https://bin.lama-corp.space/raw/qsnwnE9V3xCs0YClgU5zI | git apply` doesn't work
<infinisil> "corrupt patch at line 115"
<risson> commenting stuff out and just leaving `modules.${name} = mkModuleOptions...` in the modified lib.nix file still produces the error