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
<ekleog> Yes :( also, the fact that AFAIU known gitea hosting isn't actually able to ingest nixpkgs because it's just too big
<ekleog> (don't remember the name of said gitea hosting or of who tried though)
<gchristensen> we want to be well within the normal envelope of users for stuff like that
<samueldr> we're stretching past github-scale though
<ekleog> well, ISTR we're like the 2nd biggest github repo? so we are outside the normal envelope of users for github already
<gchristensen> yes, but we're not the biggest repo and we're not the ones being paged for when we exceed the boundaries
<adisbladis> andi-: Did you try importing nixpkgs into radicle?
<ekleog> (not an argument to get something where we're even more outside the normal envelope, but maybe an argument to say that it's not too bad if we're a bit outside their normal envelope)
<gchristensen> I did
<adisbladis> gchristensen: And?
<ekleog> right, I don't think I could support a solution where we self-host and thus get paged when things break either
<gchristensen> unrelated problems made it not work :)
<adisbladis> Ok =)
<samueldr> ekleog: things break anyway
<samueldr> being able to be paged is a privilege
<adisbladis> Still early days, I'm hopeful
<samueldr> BUT, that's not something I would wish as a volunteer to anyone
<ekleog> ^ this
<adisbladis> This is also why I'm asking about radicle
jonringer has quit [Remote host closed the connection]
<ekleog> also I'm reading about radicle and it looks awesome
<samueldr> in a p2p system, what decides what gets "pushed to master"?
* samueldr should maybe read on it before asking possiblt trivial questions
<ekleog> (though we'd still need some central instance just to make sure everything is always reachable because otherwise gossip usually can end up slow, but even if these few central instances go down things should keep working and that's good)
<adisbladis> samueldr: Orgs are managed in ethereum smart contracts in radicle
<samueldr> :/
<adisbladis> So HEAD is managed on-chain
<ekleog> adisbladis: hmmmmm are they? I seemed to understand that ethereum was opt-in
<samueldr> at least etherum is in the least bads
<adisbladis> ekleog: Yes, it's opt-in
<ekleog> because that'd actually put me quite a bit off radicle :(
<adisbladis> But you need it for orgs
<ekleog> is it not possible to like store the permissions in the gossip protocol with authorization à la matrix?
<samueldr> I don't know ethereum, but to "exec" code on ethereum, don't you need to pay?
<adisbladis> samueldr: For transactions, yes
<adisbladis> So when you merge something you'd pay a transaction fee
<adisbladis> But for local calls, no
<adisbladis> It's free to read the chain, not to make transactions on it
<gchristensen> "requester pays" amazon style
<samueldr> I see
<adisbladis> In this case it would probably be "merger pays"
<samueldr> and that price would be at the market's whim?
<adisbladis> samueldr: Your contract calls consume a certain amount of "gas", and gas has as ether price
<adisbladis> has an ether price*
<samueldr> yeah, so cost in non-eter[eum] is not stable, it follows whatever the exchange rate would be, right?
<adisbladis> samueldr: Yes
<adisbladis> It's not quite that simple
<adisbladis> But roughly
<adisbladis> ekleog: What happens in the case of forks?
<adisbladis> ekleog: I've given this a ton of thought but I haven't been able to figure out how to do this without global consensus
<adisbladis> You need some authoritive HEAD somewhere
<adisbladis> Btw, this is totally my kind of jam
<ekleog> global consensus is a lie, the CAP theorem is a daemon :p and I'm not sure what the link is to forks, unless you mean ethereum forks?
<ekleog> IMO you want something that's C and like 50% A 50% P for a system like this
<ekleog> wait scratch that I brainfarted
<samueldr> Cap? (assuming lowercase is 50% uppercase)
<ekleog> anyway, the matrix solution to that problem is to have the permissions be a CRDT
<ekleog> omg that pun is awesome (and just in case, https://en.wikipedia.org/wiki/CAP_theorem :))
supersandro2000 has quit [Disconnected by services]
<adisbladis> ekleog: The huge difference here is that matrix is federated, not decentralized
supersandro2000 has joined #nixos-dev
<ekleog> so under partition you can see inconsistent results but they'll become consistent again once de-partitioned
<adisbladis> Idk, maybe I need to read more about matrix
<ekleog> (where “inconsistent results” basically means “outdated results”)
<ekleog> well, I'd think CRDTs could be used for any level of decentralization, though the implementation isn't ready yet
<ekleog> (though to be precise, I _think_ one could already run synapse + a tor gateway locally and use that to do decentralized matrix, but that'd literally blow up any personal computer)
<adisbladis> ekleog: Do you have some recommended reading?
<ekleog> hmmmm about matrix or CRDTs?
<adisbladis> Matrix, but why not CRDTs too? :)
<ekleog> hmmmmmm matrix I don't think I have much, it's all campfire knowledge of having to look into wtf matrix does when there's a partition (and at some point there really were a lot of partitions because synapse was very broken, now it's slightly less so there's less need for that)
<ekleog> oooh looks like https://matrix.org/docs/guides/implementing-stateres has even more details than I know, apart from matrix being a big CRDT I didn't really know how things worked
<ekleog> (also, I'm not sure matrix's way of doing CRDTS would work for us, as the big limitation is basically “anyone at the highest power level can't be demoted by anyone apart from themselves”; but it sounds like a reasonable limitation to me)
<ekleog> and for CRDTs, I seemed to remember I had a more technical approach to it but it appears not to be in my browser history, so let's say https://josephg.com/blog/crdts-are-the-future/ is a good article advocating for the concept of it :) (and IMO most things can be made into CRDTs, and all things that can be CRDTs should not be blockchain because the only drawback of CRDTs is compute time anyway
<ekleog> :p)
rajivr has joined #nixos-dev
<ekleog> and https://github.com/matrix-org/matrix-doc/blob/erikj/state_res_msc/proposals/1442-state-resolution.md reads differently about matrix, depending on what you prefer reading (I gave up midway through the above link and found this one)
<ekleog> (and reading through it there's probably flaws in the matrix algorithm, that demoting someone at power level 50 still allows them to promote someone at power level 49 by simulating a fork, but that wouldn't apply to a simpler two-layer “owner”/“committer” crdt)
<ekleog> FWIW, the scheme I'd see is a two-set CRDT for owners and another for committers, where 1. adding an owner needs to be signed by another owner, and demoting an owner needs to be signed by the one being demoted (because there's no sensible way to do CRDTs with ability to demote other owners I think), and 2. adding or removing a committer needs to be signed by an owner. I think such a scheme would
<ekleog> be sound (though it'd probably require some more thinking, or even modelling?), and still be flexible enough to replace the github org structure
<ekleog> (to be precise, the only thing I think could go wrong is an owner signing their own demotion, and after that signing adding another account as owner by simulating the fact that the first event never happened and thus hoping to trick a partitioned-off server, but the hope would be that an owner demoting themselves would not do that for a while [because it was voluntary anyway], and after said
<ekleog> while the network would have propagated the self-demotion to enough places that things in practice should be OK)
<siraben> samueldr: every ethereum transaction has a "gas cost" associated with it, which you pay up front and is consumed in different amounts by different opcodes
<siraben> if you exhaust the gas mid-transaction, the whole thing reverts.
<samueldr> including the payment?
<ekleog> (and like if adding something to enforce that accepting a comment on something can only happen if all state events match, it'd probably be enough to make people subject to such an attack notice by being banned by the network
<siraben> yes
<samueldr> and what if you overpay?
<siraben> "If too much gas is provided, the excess gas is converted to ether and refunded. If too few gas is specified, all the specified gas is forfeited to the miner and the transaction is reverted: just like the contract was never called."
<samueldr> ah, so no, it's not refunded
<siraben> for the gas costs of each opcode, see page 25 of https://ethereum.github.io/yellowpaper/paper.pdf
<samueldr> unless I misunderstand who the miner is
<siraben> the miner is the node actually performing the memory-hard computation and VM so on
<adisbladis> samueldr: But you can calculate the gas cost ahead of time
<samueldr> yeah, I figured
<adisbladis> You can do a local call to your contract and see how much gas it's using up for the execution
<adisbladis> And only then actually submit a transaction
<siraben> tangential but EVM should have been designed with a return stack, you can't even do procedure calls normally and have to hack up some calling convention!
<siraben> it's stack oriented and there's only one stack
<adisbladis> siraben: A fellow ethereum connoisseur :)
<siraben> adisbladis: hehe, i worked with it in the summer two years ago, was helping to create a auction smart contract to run on chain
<adisbladis> Nice :)
<adisbladis> I haven't worked with it in a couple of years, I kinda miss it
<siraben> without libraries we had to implement skip lists in Vyper from scratch >.<
<siraben> V: I'll keep that in mind
<siraben> I'm moving the eWASM thing gets launched soon, because that would greatly improve the ecosystem
<adisbladis> siraben: We implemented secp256r1 in serpent ;)
<siraben> like, Solidity and Vyper are meh for writing smart contracts
<adisbladis> That was horrible, and super expensive to execute
<siraben> looking it up now, oh nice.
<adisbladis> That's not me, but one of my old coworkers
<siraben> adisbladis: a talk i give not too long ago about my assembler for EVM, https://github.com/ActorForth/evm-assembler/blob/master/docs/evm-assembler-talk.pdf
<siraben> s/give/gave
<siraben> bah morning typing
<siraben> adisbladis: sounds interesting, will look
<siraben> Also Vyper is in Nixpkgs as of recently :)
<adisbladis> Cool :)
<siraben> adisbladis: do you think there needs to be a lot better smart contract languages?
<adisbladis> Oh hell yes
<siraben> I also had to patch the Vyper compiler twice because of bloated codegen (55K → 1.6K bytes after my changes), and being written in Python, you can imagine how fun/painful that was to debug
<adisbladis> siraben: Whatever happened to the wasm work?
<siraben> adisbladis: I think it's still ongoing right?
<siraben> "To provide a library and instructions for writing contracts in C" my god please no
<adisbladis> I was more hoping for Rust, but OK
<siraben> they also mention Rust, hehe
<siraben> There's also the concern that smart contracts are far too operational and not declarative enough, could be addressed by total functional languages though
<adisbladis> Idk if that's what you really want
<siraben> depends on how granular you want to be right?
costrouc has joined #nixos-dev
costrouc has quit [Client Quit]
<ekleog> adisbladis: you totally nerd-sniped me, now I'm reading https://arxiv.org/abs/2011.06488
<ekleog> the tl;dr of my evening currently being “giving authorization is easy, revoking it properly is hard”
<adisbladis> :)
<adisbladis> So much to learn
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #nixos-dev
copumpkin has joined #nixos-dev
cole-h has joined #nixos-dev
<ekleog> adisbladis: Ok I think I just found the way to properly CRDT-ify revoking authorization: 1. have each signed event also point to its parent(s), 2. have signing a demotion also sign the last event(s) published by the demoted key. (The (s) being there in case the user uses their key from multiple computers not online at the same time, usually it would probably be just 1) What do you think about
<ekleog> that / do you know radicle people so I could raise that idea there? :)
<cole-h> siraben: Any chance we can move the whitespace changes... anywhere else?
<cole-h> (Sorry if this has already been discussed, just getting back) It'd be a lot easier to "just merge" if there were less than 500 rebuilds
<siraben> Hm, I did whitespace-cleanup on the files that editorconfig complained about and fixupped the old commit
<siraben> how could I find the files with whitespace changes?
<cole-h> ¯\_(ツ)_/¯
<cole-h> sorry
<cole-h> Probably by going through the commit with the whitespace changes
<cole-h> I'd feel much better merging with a red editorconfig check, than staging-level rebuilds (on darwin).
<siraben> Right.
<cole-h> Especially if explicitly called out in a comment "editorconfig will be red because otherwise there will be 500+ rebuilds on darwin"
AlwaysLivid has joined #nixos-dev
<siraben> what was that command to get the location of a package again?
<siraben> hmm I wouldn't want to redo the work again
<siraben> I think I'll move the os-specific changes out
<cole-h> EDITOR=echo nix edit -f. packagename
<siraben> cole-h: after some git-fu I moved the pkgs/os-specific changes to a different branch
<siraben> anyone know how these two lines differ?
<siraben> preBuild = ''export LD_LIBRARY_PATH=`pwd`/dist/build''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH'';
<siraben> preBuild = "export LD_LIBRARY_PATH=`pwd`/dist/build\${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH";
<siraben> well my Matrix client is interpreting them, hm
<siraben> > ''export LD_LIBRARY_PATH=`pwd`/dist/build''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH''
<{^_^}> "export LD_LIBRARY_PATH=`pwd`/dist/build${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
<siraben> > "export LD_LIBRARY_PATH=`pwd`/dist/build\${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
<{^_^}> "export LD_LIBRARY_PATH=`pwd`/dist/build${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
<siraben> evaluates the same
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 264 seconds]
tilpner_ is now known as tilpner
<ekleog> my bet would be there's just one function where the sed failed and then all downstream hashes depend on this one?
mkaito has quit [Quit: WeeChat 3.0]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #nixos-dev
<Profpatsch> qyliss: btw what do you think happened in the beginning of 2018 to cause this dip? https://edef.eu/~qyliss/nix/lib/
<Profpatsch> My best bet is that haskellPackages was gone for a commit or two.
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
jonringer has joined #nixos-dev
<Profpatsch> omg are people serously suggesting putting a blockchain on the “who has authority on what is master” problem.
<Profpatsch> I don’t even
<Profpatsch> If that happens I’m out lol, I want nothing to do with this
<siraben> they were? I was just noticing some blockchain talk so I chimed in
<siraben> ah they were, heh
<Profpatsch> I don’t know somebody mentioned something called radicale (which is a CalDAV server last I checked) and then something about using Ethereum to track what is master
<Profpatsch> And I put 1+1 together, I really don’t want to search for it because I don’t want to get infected.
<siraben> As much as I like blockchain for certain areas, using it to track master seems like a misapplication IMO
<Profpatsch> *insert strong opinions on how Buterin is a con artist and shouldn’t be taken seriously*
<siraben> Buterin?
<Profpatsch> Vitalik Buterin
<Profpatsch> Maybe I scrambled the name, but I also don’t want to search for it realy
<siraben> found him
<siraben> lol what's wrong with searching
<siraben> related #103890
<{^_^}> https://github.com/NixOS/nixpkgs/issues/103890 (by RaghavSood, 8 weeks ago, open): Housekeeping: Improve blockchain stuff organization and consistency
<ekleog> Profpatsch: radicle, https://radicle.xyz/ ;)
<siraben> why do blockchain related projects always have such fancy sites
<siraben> we need more compiler engineers, not web devs!
<ekleog> it works without blockchain until one wants to either make donations to projects via it, or have organizations (and my hope is that they use blockchain for orgs only because they didn't think of my genius idea for making authorization into a CRDT :p)
<ekleog> (well, into a good CRDT*, as opposed to matrix's state resolution being a ~bad CRDT especially for the git use case)
<samueldr> siraben: what if... bear with me... what if, just what if it wasn't a compiler engineer that made the site?
<siraben> samueldr: i mean of course
<ekleog> oh also I'm way more into the compiler dev side of things and I disagree with that statement, especially for nixpkgs we need web engineers more than compiler engineers… and overall I'd say we need web engineers that do useful things and compiler engineers, not web devs that copy a 1000 startup website, but then whatever pays the bills :p
<Profpatsch> tbh, I’d be very happy if nixpkgs would collaborate with people who know what they are doing and have the right mindset, like e.g. the people over at sr.ht to be of that class of person.
<Profpatsch> Think of DDV what you may, he’s one of the few who really know what they are doing
<Profpatsch> Moving to sr.ht would probably benefit both projects, sr.ht would get a client with more than just trivial requirements and nixpkgs would move away from a Microsoft subsidiary.
<siraben> ekleog: half-joking of course, just that the impression I've gotten from some popular smart contract languages
<siraben> Profpatsch: "I’d be very happy if nixpkgs would collaborate with people who know what they are doing and have the right mindset", how would this benefit us? What kinds of problems would they tackle?
<Profpatsch> I haven’t done any research into whether sr.ht is good enough for our purposes yet, so take with a grain of salt.
<Profpatsch> siraben: well for once, it allows us to collaborate with the platform, for github we are just another ticket box in their marketing strategy, not a client
<siraben> DDV called NixOS a cult a few months ago on Mastodon
<siraben> heh
<siraben> Profpatsch: right
<Profpatsch> so Github’s goals are not aligned with ours from the get-go
<Profpatsch> It might have a fancy interface, but in its core it’s a business catering to paying companies
<ekleog> Profpatsch: my recollection of us looking into moving to some public gitea instance was that it just wasn't able to import the repository because it's too big; and from a 2-seconds look at sr.ht it looks to me like it does neither issues nor PRs, which both sound like non-starters for us (also, I'd challenge the assertion that Drew DeVault actually knows what they are doing, but that's off-topic
<ekleog> :p)
<siraben> I think rnhmjoj mentioned this yesterday, that it's a big undertaking to migrate because of all the CI
<Profpatsch> Which translates to stuff like: email notifications are a joke, git send-mail does not work, no contributions without an account etc.
<siraben> Drew finds web interfaces and javascript distasteful, so we'd have to move to mailing lists
<cole-h> I wonder how CI (ofborg specifically) would work on a patch-based email workflow...
<cole-h> s/patch-based email/email-based/
<Profpatsch> siraben: not my impression, sr.ht has a ticket web interface
<Profpatsch> I don’t know about pull requests
<ekleog> oh looks like the issue web interface isn't enabled on all repositories, so I had missed it
<cole-h> todo.sr.ht is more for the maintainer to, well, submit things they need TODO. I'd argue that's not the same as a bug tracker (and I think Drew has said it shouldn't be treated as one).
<Profpatsch> But siraben do you have a source for that?
<siraben> Source for which one?
<Profpatsch> That DDV finds web interfaces distasteful?
<Profpatsch> I mean it’s a bold statement to make without at least a quote backing it up :)
<Profpatsch> siraben: I mean, from skimming the article I don’t disagree with any points made
<Profpatsch> And in general it falls into my “knows what they are doing” category
<ekleog> okay so I was going to suggest we stay away from ad hominem arguments based on Drew DeVault, but upon further thought one non-trivial argument against GitHub is technically ad hominem (well… ad corporationem?)
<Profpatsch> ekleog: ad corporationem should be our holy duty
<ekleog> that said GitHub also has the “vanishes users” issue that isn't ad hominem so we could take that all out of the picture without killing the thread altogether
<siraben> vanishes users?
<ekleog> the way volth mysteriously disappeared along with all issues and PRs, and by rebound made all contributions to said issues and PRs disappear
<Profpatsch> Equating companies with people is what corporation marketing is all about
<Profpatsch> And it’s a disaster that people started believing them
<ekleog> Profpatsch: I'm not arguing against ad corporationem, I'm arguing against ad hominem
<siraben> Ah
<siraben> From having not contributed at all to nixpkgs to being moderately active, I think being on GitHub was a huge motivator
<Profpatsch> siraben: I don’t disagree
<Profpatsch> Which is why it’s so hard to argue for anything else
<ekleog> Anyway, I would be quite surprised if sr.ht did match the requirements for nixpkgs moving to it, but if it does, they are open to hosting us, and their infrastructure can actually hold the load, then it's something that could be investigated further
<Profpatsch> I think a project like nixpkgs needs a good platform to thrive, and mailing lists are not a good platform
<siraben> even just mirroring nixpkgs would be good start
<siraben> Is sr.ht completely mailing list dependent?
<Profpatsch> I don’t know.
<ekleog> I've got quite big hopes for radicle (especially if it can get rid of blockchain for orgs, because that's just bad), but the mere feasability of importing to radicle also stills need TBD
<siraben> Side note: it also sends you a pedantic email if you send HTML
<siraben> to the mailing list
<energizer> has anybody from nixpkgs reached out to github about the various problems nixpkgs is having? that seems like a good next step (after compiling a list of problems)
<siraben> what issues are we having? this is the first time I've heard of it
<ekleog> energizer: I don't know of a list of problems apart from political issues intrinsic to github being github (like the disappearing of volth)
<siraben> What happened with volth disappearing? I'm not familiar with when that happened
<energizer> sounds like it's a pretty minor deal then and people shouldn't spend effort on trying to replace github
<ekleog> making a person and all their contributions disappear was not a minor deal, just today I had to dig in my mail archives to recover some code that was lost due to this fact
<Profpatsch> energizer: It depends on how minor you think somebody disappearing with all their contribution history is
<ekleog> (and I was lucky to actually have it in my mail archive)
<Profpatsch> With no public statement of why or how
<energizer> people delete comments and prs all the time
<siraben> When a GitHub account gets deleted their history is removed?
<energizer> siraben: that doesn't usually happen, this is an unsual case
<ekleog> people doing it on purpose is ok, github doing it for someone is not
<Profpatsch> Which showcases a fundamental flaw in Githus: the PRs and issues don’t belong to the project, they belong to Github
<siraben> energizer: what happened at that time?
<energizer> ekleog: i dont think it matters to nixpkgs why
<energizer> siraben: i dont know
<siraben> Profpatsch: right.
<Profpatsch> And by using the platform the nixpkgs project is agreeing that this is a-ok
<energizer> ekleog: i dont think it matters to nixpkgs why the things are deleted
<siraben> like our existence is intrinsically linked to GitHub's continued existence
<ekleog> it does for reasons of scale, volth was one very significant contributor of nixpkgs and I don't think it would even come to the mind of such a contributor to delete issues & PRs
<Profpatsch> Our feet are under a master’s table who does not care about us
<siraben> well there's also GitLab that could be self-hosted
<siraben> (surprised it hasn't been brought up yet)
<energizer> deleting lots of stuff will happen on any platform (unless deleting things is prevented by the platform's architecture, which has its own problems)
<ekleog> self-hosting is a no-go for lack of people actually wanting to take the responsibility of hosting (which totally makes sense as it's going to be a stressful position to be in)
<Profpatsch> Yes, self hosting is out of the question
<siraben> Ok
<Profpatsch> At least from my perspective
<Profpatsch> But realistically, I think so
<Profpatsch> Even maintaining infra like ofborg is not an easy task, and mostly on the shoulders of a few volunteers
<siraben> Then is decentralization a good idea or would make contributing even harder?
<Profpatsch> Decentralization is a bad idea
<energizer> siraben: distributed systems always make everything harder
<ekleog> AFAIK right now the biggest issue for moving off-github is, I haven't yet heard of any other service or system that could actually take the load of nixpkgs apart from probably gitlab.com, which wouldn't be much better
<Profpatsch> What matters is that the data is controlled by well-meaning actors
<ekleog> As for making contributing harder, I feel like the days of github being a good network effect are mostly over with the way github's PR is spiralling down
<ekleog> so github probably will no longer stay a way for us to lower the contributing bar, though it definitely will have contributed to the current contributor's integration
<Profpatsch> In general you want to be as centralized as possible without stifling contribution
<siraben> What does AUR do?
<ekleog> (okay this is me looking in my crystal ball with zero data to support it :p)
<siraben> Or similarly large package repos
<energizer> Profpatsch: i dont think intentions matter that much. features, manpower, infrastructure matter much more
<Profpatsch> So you want people to devise alternatives if they so desire, and get any big blockers out of the way
<Profpatsch> e.g. if people have to set up a complicated toolchain locally to contribute, that’s a no-go
<ekleog> FWIW I think the sweet spot is in decentralized systems with centralized ways to easily access them (eg. a webui for radicle)
<energizer> (and most especially the raw number of people on the platform)
<Profpatsch> ekleog: Or a web interface for git :)
<siraben> Does AUR use mailing lists?
<ekleog> right, for git data it's the easy problem though, issues&PRs are the hard one, for just git data we could just keep using github and it'd be all good :p
<siraben> it appears they do, also timely someone mentioned packages disappearing because people delete their account: https://lists.archlinux.org/pipermail/aur-general/2020-December/036065.html
<energizer> same thing happened on npm and pypi.
<siraben> but deleting a github account doesn't delete your packages from nixpkgs, right?
<energizer> right
<ekleog> <Profpatsch> e.g. if people have to set up a complicated toolchain locally to contribute, that’s a no-go <-- I'd argue nix is all about people having to set up a complicated toolchain locally, be it from the “make it simpler” side or from the “setting up nix is hard” side :p
<Profpatsch> ekleog: but setting up nix is not hard, it’s curling into a shell script
<ekleog> and having sudo to run it*, which is where things get hard :p
<Profpatsch> HPC wants to have a word
<ekleog> anyway I should have went to sleep like 10 hours ago, so I'm going to go for now, and hope we can find some service or system that can reasonably replace github in features, infrastructure and policy :)
orivej has quit [Ping timeout: 265 seconds]
cole-h has quit [Quit: Goodbye]
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
kalbasit has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
jonringer has quit [Ping timeout: 260 seconds]
<domenkozar[m]> note that according to GDPR you'll always have the case of disappearing content
<domenkozar[m]> no solution will prevent that
<domenkozar[m]> and the right to delete your data is something I think everyone should have
<domenkozar[m]> (and luckily EU agrees)
<domenkozar[m]> Deleting your user account removes all repositories, forks of private repositories, wikis, issues, pull requests, and pages owned by your account. Issues and pull requests you've created and comments you've made in repositories owned by other users will not be deleted - instead, they'll be associated with our Ghost user.
<domenkozar[m]> well that wasn't the case?
<domenkozar[m]> has anyone tried contacting github?
<domenkozar[m]> sent
<supersandro2000> The ghost user is not always there
<supersandro2000> there are some circumstances it is used but now always
<domenkozar[m]> maybe volth got banned?
<supersandro2000> not by its behavior
<supersandro2000> very unlikely
__monty__ has joined #nixos-dev
ddima has quit [Ping timeout: 256 seconds]
ddima has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
orivej has quit [Ping timeout: 246 seconds]
AlwaysLivid has joined #nixos-dev
zarel_ has quit [Ping timeout: 246 seconds]
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #nixos-dev
tv has quit [Ping timeout: 264 seconds]
tv has joined #nixos-dev
kl3 has quit [Quit: leaving]
orivej has joined #nixos-dev
stigo has quit [Ping timeout: 256 seconds]
Jackneill has joined #nixos-dev
stigo has joined #nixos-dev
<gchristensen> yes, volth was banned and removed from github wholesale
<domenkozar[m]> that's not true
<gchristensen> oh?
<domenkozar[m]> github:
<domenkozar[m]> The content is still present in our system, however, the user has been flagged. As a result, all of their issues, comments, and repositories are hidden.
<gchristensen> right
<gchristensen> more like soft-deleted
<domenkozar[m]> Our security and privacy policies prevent us from discussing this any further with any one but the account owner that has been flagged. If you are able to contact that user, they can reach out to us and request that their account be un-flagged.
<domenkozar[m]> it's possible to access the content via api: https://api.github.com/repos/NixOS/nixpkgs/issues/109444/comments
<gchristensen> oh great, we could archive it that way maybe
<domenkozar[m]> is anyone in contact with volth?
<gchristensen> I have been
<domenkozar[m]> I wish there was less FUD about github and someone actually talked to them
<gchristensen> they seemingly intentionally poked a bear which got them flagged
<domenkozar[m]> you can let them know that they can get unflagged
<domenkozar[m]> if they contact github support
<supersandro2000> and we know 100% why they got flagged
<domenkozar[m]> I mean people, you can't ask for code of conduct and then blame a platform for losing the contents, you can pick one or the other
<domenkozar[m]> there's no win-win here
<domenkozar[m]> supersandro2000: so why did you say hours ago that volth "very unlikely" didn't get banned?
cole-h has joined #nixos-dev
<domenkozar[m]> we need to establish some true facts here :D
<gchristensen> volth got an email where they were asked to stop doing a thing, they continued doing the thing, the person who sent that letter sent that letter to github
<domenkozar[m]> ok, but if you want to enforce COC then you shouldn't tweet stuff like https://twitter.com/grhmc/status/1334138105738256389
<gchristensen> how is that related?
<supersandro2000> domenkozar[m]: by his own actions
<domenkozar[m]> gchristensen: it's related that you're asking for censorship due to abuse and that's what happened
<gchristensen> I don't mind that github flagged volth, I am unhappy that their contributions are removed without the project having a chance to get them
<domenkozar[m]> that's what censorship is
<domenkozar[m]> it's pure lies: they didn't disappear, they were reported to abuse and according to github rules were banned
<domenkozar[m]> reported for abusive behaviour*
<gchristensen> I'm going to wander off, I don't see these as incompatible
<eyJhb> domenkozar[m]: I seem to remember (someone said this), that you can only get the personal data removed, and have no right to get the entire account removed. But any personal identifying materials can be
<eyJhb> Had this discussion with someone at KODI I think
<eyJhb> Which would not delete my account......
<domenkozar[m]> eyJhb: are you talking about GDPR?
<eyJhb> Yes sorry, forgot to mention.
<eyJhb> GDPR
<eyJhb> domenkozar[m]: note that according to GDPR you'll always have the case of disappearing content
<eyJhb> Which based on that discussion, isn't entirely true
<domenkozar[m]> this wasn't a GDPR case
<domenkozar[m]> but a violation of guidelines
<eyJhb> Nope, but just in relatino to that comment, GDPR doesn't just mean that you can make everything disappear :)
<gchristensen> it was a legal request
<eyJhb> But how Github handles a violation, could be better...
<domenkozar[m]> do you seriously expect github to go through thousands of comments upon request of abusive content?
<domenkozar[m]> I'd be extremely surprised any platform would do that
<gchristensen> it was a legal request
<eyJhb> gchristensen: A legal request to remove volth?
<gchristensen> to stop volth from impersonating someone
<eyJhb> Couldn't the account just have been frozen, etc.? I am guessing it is more than just a "he took my username" kinda thing
<domenkozar[m]> the account is flaged, which is another way of saying it's frozen
<eyJhb> Flagged + hidden content makes for a lot of weird threads, if the account was active in a community :)
<domenkozar[m]> agreed :)
<eyJhb> So yes, it is hard for a company to do anything, but I would much rather freeze the account or make a ghost user. Then if there are any specific things that should be removed, one should be able to flag the comment, get a review and then it should not just "ghost" away, but rather be marked as removed or something...
<eyJhb> Had a forum that started just doing this (just removing/hiding everything). It was unuseable .....
<domenkozar[m]> that's unfortunately not how the law works in US and once you get lawyers into the game they'll always advise for minimizing the risk
<adisbladis> That's another reason to get out of github
<adisbladis> To get out of the US legal system
<domenkozar[m]> you mean US?
<domenkozar[m]> yeah I can buy that.
<eyJhb> Depends if the extend as GDPR does, but I am guessing not
<adisbladis> eyJhb: I think not unless you have a legal prescence in the US
<eyJhb> All the wonderful, "we do not serve residents of EU" sites nowadays etc..
<eyJhb> Hmm, might be so
<eyJhb> GitLab is also US based I guess....
<adisbladis> Yes
<eyJhb> Are there any EU based at all?
<adisbladis> Not that I know of
<eyJhb> Sad... I am guessing even if you do AWS in EU, you would still be screwed by the US laws?
<domenkozar[m]> not really since they have to operate as an EU company
<eyJhb> Ah, that's true. Still guessing that they mostly "operate"/act like a US one, if it comes to it.
<eyJhb> gchristensen: after the discussion that was started some days ago regarding modules, and having a "module store", I really can't shake that idea off. It would be really cool to see
<siraben> Mic92: good to merge #109455?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/109455 (by siraben, 1 day ago, open): treewide: stdenv.lib -> lib
<eyJhb> Having a solid base of modules, and then just pulling stuff in as needed
<ekleog> domenkozar[m]: There is a significant difference between wanting to enforce our community-decided CoC, and wanting to be at the mercy of GitHub's CoC (which… according to recent news might not be that awesome) — also, breaking the CoC should not mean deleting all previous contributions, just preventing future contributions and deleting previous problematic contributions. I think these are
<ekleog> the points of friction with GitHub in this specific case :)
<domenkozar[m]> ekleog: that's now what the laywer team will tell you
<domenkozar[m]> s/now/not/
<ekleog> Sure, I'm talking exclusively about what we want, not what GitHub wants
<domenkozar[m]> they think about risk as the enemy and will always go and minimizing it
<domenkozar[m]> s/and/with/
<domenkozar[m]> ekleog: my point is mostly that there will never be the perfect host, you're always trading between what you give up
<domenkozar[m]> and the pain you haven't experienced yet is always more appealing
<domenkozar[m]> note that the content is public via the api
<ekleog> That's definitely true too, I'm just reacting to your “ok, but if you want to enforce COC then you shouldn't tweet stuff like […]” message
<domenkozar[m]> that tweet is changing what really happened and putting it into an envelope
<domenkozar[m]> sure it's a white lie, but nevertheless changes the context completely
<ekleog> Well, it is sure presenting the facts from the perspective of the NixOS community, not from the perspective of GitHub, but it seems reasonable to me to expect tweets to present facts as they appear to us because whatever internal GitHub decision-making process ended up with this decision doesn't change what it does for us
<domenkozar[m]> I'm glad we agree it's biased and my point it only that by doing so fuels FUD and doesn't address the real problem underneath
<domenkozar[m]> the real problem is how US law is handled in any company really
<domenkozar[m]> it's not an engineering decision within github, but a legal team made it
<domenkozar[m]> and engineering implemented it
<domenkozar[m]> ekleog the outcome is that you can still access their content via the api
teto has joined #nixos-dev
<ekleog> Interesting, to me the real problem is that nixpkgs is currently at the mercy of GitHub's policy, be it in answering legal matters or in any other policy-related decision. For sure most other companies would certainly react the same way, because companies by definition must seek profit or they're illegal. But not all hosters are companies, and I think it might be reasonable to hope for a hoster
<ekleog> that would actually even just talk with us before disappearing one of our major contributors, though I do not know of a suitable one yet :)
<Mic92> I would like to see a review for this one: https://github.com/NixOS/nixpkgs/pull/109342 (needs experience with C)
<{^_^}> #109342 (by Mic92, 2 days ago, open): nixos/wrappers: fix applying capabilities
<supersandro2000> C is a strange language. If you only know higher languages it makes no sense at all.
<rnhmjoj> another issue with github being operated in the US is that if for some unlucky chance your country goes haywire and the US puts sanctions on it, you'll be losing access to your account
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
<siraben> 161081366433698
<siraben> 161081382731591
<siraben> qyliss: :D
<infinisil> > date.epochToDateTime 1610813664
<{^_^}> { day = <CODE>; hour = <CODE>; minute = <CODE>; month = <CODE>; ms = <CODE>; second = <CODE>; year = <CODE>; }
<infinisil> ,ping
<{^_^}> pong
<infinisil> > :p date.epochToDateTime 1610813664
<{^_^}> { day = 16; hour = 16; minute = 14; month = 1; ms = 0; second = 24; year = 2021; }
<abathur> oh, nice, I've wondered if :p worked there :)
jonringer has joined #nixos-dev
<infinisil> > :p date.prettyDateTime (date.epochToDateTime 1610813664)
<{^_^}> "2021-01-16 16:14:24"
<infinisil> > date.prettyDateTime (date.epochToDateTime 1610813827)
<{^_^}> "2021-01-16 16:17:07"
<gchristensen> it is lucky that unix timestamps aren't the number of seconds since Jan 01 1970 UTC, otherwise this function would be much harder
<infinisil> Hehe yes
<infinisil> > date
<{^_^}> { dateTimeToEpoch = <CODE>; diffDateTime = <CODE>; epochToDateTime = <CODE>; parseDateTime = <CODE>; prettyDateTime = <CODE>; prettyDuration = <CODE>; }
<domenkozar[m]> ekleog unfortunately there's no way to be above the law, but you can pick the law you're required to respect
<ekleog> AFAIK we do not know whether the request against volth was actually following infringement of the law or just GitHub deciding to, in essence, pay the patent troll to not have to go through long legal procedures
<ekleog> And that is the whole point in migrating off companies: they are by nature incentivized to do the simplest thing that keeps them afloat, and disappearing a user is trivial in that regard, independently of whether they actually broke the law
<ekleog> (as my sentence is grammatically poor: I meant that it may have been GitHub deciding to disappear volth because they thought the legal procedures for not doing so, even if volth was doing legal things, would cost them more than them disappearing volth — trying to draw a link with companies paying patent trolls despite GNOME v. some-patent-troll showing that the requests are not actually
<ekleog> legal)
<domenkozar[m]> bbl in 1h
tdeo has quit [Remote host closed the connection]
AtnNn_ is now known as AtnNn
mikroskeem has quit [Quit: WeeChat 3.0]
srk has quit [Remote host closed the connection]
srk has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<supersandro2000> I would appreciate it if someone could take a look at my suggestion in https://github.com/NixOS/nixpkgs/pull/109555
<{^_^}> #109555 (by LeSuisse, 4 minutes ago, open): nmap: 7.80 -> 7.91
<eyJhb> Are there any metrics on the moment, on how "overhead" the many modules add to evaluation?
<supersandro2000> I probably stop building nodejs because it just takes to long...
teto has quit [Ping timeout: 256 seconds]
lassulus has quit [Ping timeout: 256 seconds]
fzakaria has quit [Ping timeout: 256 seconds]
teto has joined #nixos-dev
evanjs has quit [Ping timeout: 256 seconds]
evanjs has joined #nixos-dev
lassulus has joined #nixos-dev
fzakaria has joined #nixos-dev
Thophane[m] is now known as Thophane[m]1
<flokli> supersandro2000: can you prevent your bot from posting to already closed/merged PRs?
<supersandro2000> flokli: everything is possible
<flokli> Also, the "review" wording in the comment might be a bit misleading. Usually, humans using nix-review try to execute the build result and poke with it a bit. Adding a disclaimer that this is no review, but just a "build sanity check" (which might even be done by ofborg) sounds appropriate
<supersandro2000> but I usually just run darwin on closed ones anyway if I care a bit about the package
<flokli> is the code public somewhere? happy to send a PR or open an issue ;-)
<flokli> yeah, I just mean, getting a comment 2 days after a PR is merged kinda isn't very helpful
<supersandro2000> not the ofborg discussion again. It does not build all dependandences and I can't hack things into it
<supersandro2000> not yet. I planned to open it.
<supersandro2000> sometimes I need to restart a command with many PRs multiple times because tensorflow sneacked into it
<supersandro2000> that should be less when I filtered all tensorflow/pytorch/etc packages out
<domenkozar[m]> ekleog note that's quite a dangerous belief, not sure I can challange it though because it requires going quite deep into hwo the world works. I can say that it's a lose-lose game for everyone if you hold that position :)
<domenkozar[m]> challenge*
<supersandro2000> github usually does not suspend accounts for DMCA issues
<supersandro2000> maybe when they repeatedly infringe it
<ekleog> domenkozar[m]: I remember some trial (not sure whether in France or the US though) ending up with in essence “companies must do what is best for their shareholders” that confronted a company with some of its shareholders; so while I'd love for it not to be the case (and a way for it not to be the case is to make sure the shareholders are good, for some definition of good), it is
<ekleog> unfortunately the way a very high number of companies are forced to be by law :/ (and the few companies that actually do avoid that issue I wouldn't call companies as their governance model is vastly different)
kini has quit [Ping timeout: 264 seconds]
kini has joined #nixos-dev
<domenkozar[m]> ekleog: can't comment on that since I don't know the source :)
<domenkozar[m]> status update: I'm working with github to restore volth content, it seems like it might be possible
<samueldr> odd
<samueldr> considering they gave me the cold shoulder
<samueldr> do you have better contacts?
<domenkozar[m]> I only contacted support
<samueldr> that was what I did
<domenkozar[m]> they forwarded me to another team that should help handle this, nothing is yet confirmed or agreed
<ekleog> cool, let's hope :) as for the source, it's been years so I don't have it any longer, and all I remember I already wrote, sorry
<samueldr> in a sentence, they basically could say nothing, and do nothing, since it's another user's account
<samueldr> even though I pleaded that it was a project's data being removed
<samueldr> that they have the "ghost" user for account deletions
<domenkozar[m]> did they tell you it's accessible via the api?
<samueldr> no
<samueldr> and it's not
<samueldr> (or it changed since early december)
<samueldr> >> The only information that I can provide is that the issues are still present, however, the user has been flagged in our system. Flagged users are hidden in our system. Due to privacy and security policies I am unable to discuss this in detail with you.
<samueldr> maybe they meant the same, that the data still is available _for github_
<samueldr> which, duh, it's leaking like a sieve if you know where to look
<domenkozar[m]> well so I was told, I blindly believed the support
<domenkozar[m]> let me check
<samueldr> no worries, I'm hopeful *something* can happen, but I don't actually place any hope here
<domenkozar[m]> you can access the comments at least
<domenkozar[m]> the support event provided me a breakdown how to script to archive everything :D
<domenkozar[m]> even*
<samueldr> only comments not from volth :)
<samueldr> there was an API endpoint (for pull requests) someone dug up ~2 days ago here in this channel that leaks data from disappeared users
<samueldr> I think it was actions related
<domenkozar[m]> ah ok, but at least all of the non-volth content could be recovered
<samueldr> yeah, though sometimes lacking context
<samueldr> e.g. on issues, issue titles...
<samueldr> ... but people subscribing over e-mail still have those though
* colemickens makes me think of the youtube bug last week where you could extract frames from private videos via Google ads
<domenkozar[m]> well let's see if I can get further into resolving this, but it seems volth could have easily responded to github to unflag their account
<samueldr> PR heads can still be fetched
<samueldr> maybe they did, and it's a situation where it cannot be "resolved"?
<domenkozar[m]> so it's more like that volth is holding us hostage than github
<samueldr> no
<samueldr> github's practices have held our data
<samueldr> maybe it's how their legal department interpreted the rules and laws about *something* and maybe they're right under that purview
<samueldr> but still, we're left with incomplete and *broken trust*
<samueldr> we cannot account for all gaps in issues and pull requests
<samueldr> for some we know it's linked to a specific username
<domenkozar[m]> samueldr: where can I contact volth?
<samueldr> I don't know
<samueldr> I have never really interacted with volth except one-or-two times through github
<colemickens> volth has been active on Discourse since GitHub disappeared a bunch of our project info
<energizer> Author: volth <volth@volth.com>
<domenkozar[m]> thanks!
<ekleog> samueldr: I have an archive of all email notifications github sent me since oct. 2018, if that can help in any way :)
<ekleog> (would just have to extract it from my overall email archive)
<samueldr> I think andi- could one-up you a couple of years more ;)
<ekleog> very possible, I have no idea who saves what ^^
<samueldr> and I'm sure some project founders here could too
<samueldr> but yeah, for the time being I was too burned out on the big disappearance issue
<samueldr> I did make a list of all gaps
<domenkozar[m]> shouldn't we just point archive.org to it?
<samueldr> it lacked almost 100% of it
<ekleog> (oh as I wasn't precise, oct. 2018 is the day I watched the repo, so it's all email notifications github sent anyone* — though other people also keeping this kind of backlog is very likely too)
<samueldr> (unless you mean starting today)
<samueldr> I think volth (since they were prolific) contributed ~half of the missing PRs and issues
<domenkozar[m]> yeah I mean as a lesson learned
<samueldr> domenkozar[m]: anyone can do that, and yes :)
<domenkozar[m]> alright I contacted volth and github support, let's see how far that can go
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
<samueldr> what's the URL to look at more details for the machines in hydra?
<samueldr> I want to verify there are some aarch64 builders with big-parallel
<gchristensen> queue-runner-stats I think
<samueldr> one letter off
<samueldr> thanks
<samueldr> (I was able to spot it in Root.pm)
<gchristensen> neat
AlwaysLivid has quit [Ping timeout: 240 seconds]
pmy has quit [Ping timeout: 272 seconds]
pmy has joined #nixos-dev
<supersandro2000> flokli: I am planning to publish the source here soon ™️ https://github.com/SuperSandro2000/nixpkgs-review-checks
<flokli> ok
<supersandro2000> I just finished on of the last features I wanted to get in before: https://github.com/NixOS/nixpkgs/pull/109515#issuecomment-761686592
<supersandro2000> checking for old substituteInPlace
__monty__ has quit [Quit: leaving]
AlwaysLivid has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
<abathur> nice
<aterius> Is there a way to get a more informative error message while debugging a new nixos module?
<aterius> That's with showtrace, so I don't know where in the attribute there's a string
<samueldr> aterius: lib.mkOption missing somewhere?
<samueldr> that's something I sometimes hit, and the error I think is that, or similar
<aterius> Do I have to use mkOption? I'm trying to use the infinisil's RFC as a template
<samueldr> it's walking down the options definition, and hoping to find either a set or a lib.mkOption, but sees something like description = "foo";
<samueldr> I don't know about infinisil's RFC
<samueldr> but I would assume it might
<aterius> This is what I was basing that on:
<samueldr> pretty sure that needs lib.mkOption
<samueldr> line 13
<samueldr> your ".settings" lower down might not, I cannot say
<samueldr> but at 13 I'm pretty sure it does
AlwaysLivid has quit [Ping timeout: 240 seconds]
mkaito has quit [Quit: WeeChat 3.0]
<aterius> Ah I think it was description
<infinisil> aterius: Both description and default are misplaced
<infinisil> description and default are `mkOption` arguments, but you're not passing them to any mkOption here
<aterius> Oh hey 😆
<infinisil> You probably meant to put the default and description within the `settings = lib.mkOption { ... }`
<aterius> Good catch, thanks for looking at it. I did
<infinisil> o/
<aterius> (this is also my first nixos module)
<infinisil> Nice :D
<infinisil> Not the first time seeing such a mistake, I think the error could definitely be improved
AlwaysLivid has joined #nixos-dev
<eyJhb> When writing a script with pkgs.writeScript, is it then encouraged/good to do e.g. ''#!${pkgs.bash}/bin/basn'' at the very top? Or is there something better?
<eyJhb> Guessing `writeShellScript` ?But what shell will that use?
<infinisil> eyJhb: Yeah writeShellScript, just uses bash
<infinisil> Or rather, `pkgs.runtimeShell` iirc, which is also bash
<eyJhb> infinisil: And that is set somewhere in nixpkgs I assume?
<infinisil> Aw man I want ,find reimplemented
<infinisil> ,find trivial-builders.nix
<{^_^}> ,find is temporarily unimplemented
<infinisil> It's in there
<eyJhb> Is there a good way, to include programs in the script? E.g. I want to use git a lot, but having ${pkgs.git}/bin/git a lot, would be.. not nice?
<eyJhb> Haha, thanks! :D
<infinisil> I usually do `export PATH=${lib.makeBinPath [ git ]}` at the beginning
<eyJhb> export PATH=${lib.makeBinPath [ git ]}:$PATH
<infinisil> Or to keep the existing PATH as a suffix, add ''${PATH:-:}$PATH
<eyJhb> Or just the other?
<eyJhb> Hmm, nice. But I am guessing, that makeBinPath will still have the defaults, such as cd, ls, coreutils in general?
<infinisil> Nah, it's really just what you put in there
<infinisil> > makeBinPath [ git ]
<{^_^}> "/nix/store/yxprdzd292y2zhjkhs6wyb5jdisbh1f2-git-2.30.0/bin"
<eyJhb> Oh, then I am guessing adding coreutils would be good :D
<infinisil> Yeah probably :)
kini has quit [Remote host closed the connection]
<infinisil> Or, just don't maintain the previous $PATH
<eyJhb> Thanks infinisil++ :D
<{^_^}> infinisil's karma got increased to 402
<infinisil> (so you notice when you depend on an impure binary)
<infinisil> :)
<eyJhb> Damn, 18 more and you are rolling!
<infinisil> Ayy!
kini has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 240 seconds]