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
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
alp_ has quit [Ping timeout: 272 seconds]
immae has joined #nixos-dev
rajivr has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
kalbasit_ has quit [Ping timeout: 240 seconds]
Ericson2314 has quit [Ping timeout: 244 seconds]
ris has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
marek has quit [Ping timeout: 246 seconds]
marek has joined #nixos-dev
m1cr0man has quit [Quit: G'luck]
Jackneill has quit [Ping timeout: 246 seconds]
m1cr0man has joined #nixos-dev
Jackneill has joined #nixos-dev
alp_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
saschagrunert has joined #nixos-dev
teto has joined #nixos-dev
sgo has joined #nixos-dev
stigo has quit [Ping timeout: 260 seconds]
sgo is now known as stigo
FRidh has joined #nixos-dev
stigo has quit [Ping timeout: 246 seconds]
pmy has joined #nixos-dev
<pmy> I sent a PR to NixOS/nixpkgs 6 months ago. Finally the PR received a reply two days ago asking me to solve merge conflicts. I did. But nothing else happened. It seems the reply is from a merge conflict detection bot. Is there any human here actually willing to review code? The PR is #87735.
<{^_^}> https://github.com/NixOS/nixpkgs/pull/87735 (by pmeiyu, 28 weeks ago, open): Add ibus-engines.rime
stigo has joined #nixos-dev
<supersandro2000> I am not a bot!
<supersandro2000> and please stop spam mention me
<pmy> Really?
<supersandro2000> I have 1682 GitHub notifications currently
<etu> supersandro2000++
<{^_^}> supersandro2000's karma got increased to 0o22
<etu> {^_^}: troll
<supersandro2000> also I have currently like 50 other tabs to review open. I slowly go through them but I am in no rush
<pmy> Are you actually going to review the code? If not, you are actually spamming me.
<pmy> The PR receives no reply for six months. If there is another six months wait period. I guess the next reply will also be merge conflicts.
<etu> pmy: Don't complain about that someone started to care about your PR ;)
<supersandro2000> I can't test if it actually builds when there is a merge conflict
<supersandro2000> and I started to filter those PRs so if you have another PR that is like this I won't actually reply to it anytime soon
<pmy> I have tested it and have run it on my computer for a year.
<pmy> The merge conflict is caused by a minor change to maintainer-list.nix. I thought only a bot will be confused by that. I searched PR history and found you replied to many PR with a single line "please solve the merge conflict". Threfore I thought you are a bot. Sorry. I was wrong.
<eyJhb> supersandro2000: *beep beep*
FRidh has quit [Ping timeout: 272 seconds]
<eyJhb> I can only say, that it builds for me. Not really sure if I can test the PR..
<lukegb> pmy: I understand it's frustrating but please don't take it out on people :( - there are a lot of pull requests to review, so there's a need to lean quite heavily on things like GitHub saying "this won't merge cleanly"
FRidh has joined #nixos-dev
cole-h has quit [Ping timeout: 256 seconds]
__monty__ has joined #nixos-dev
<supersandro2000> also GitHub does not calculate this all the time correct
<supersandro2000> I run nixpkgs-review, do something else, come back 10 minutes later and then merge conflict
<supersandro2000> also if it would be a bot I would use SuperSandroBot
FRidh has quit [Ping timeout: 246 seconds]
<lukegb> whenever I see your nick I can't help but wonder if there will be a SuperSandroXP, SuperSandroVista, etc.
FRidh has joined #nixos-dev
<supersandro2000> Why is this marked broken here https://github.com/NixOS/nixpkgs/pull/105543#issuecomment-736329805 ?
<supersandro2000> I don't understand it. It works when building manually...
<supersandro2000> lukegb--
<supersandro2000> think about the console in older Windows.
<pmy> I have heard from my friends that they refuse to submit PR to NixOS becaued they have to wait months before getting a reply. This is a serious problem for an open source project. I wonder what's your guys opinion and what has been done to address the problem?
<lukegb> supersandro2000: hmm, does the same thing happen if you run nixpkgs-review again? meta.broken definitely _seems_ to be false
<lukegb> oh, nvm, I see it
<supersandro2000> pmy: there are just to many open PRs and bots could really help churn through them if they remind people to fix their PRs if they get merge conflicts, have common issues, are already included in master etc
cole-h has joined #nixos-dev
<lukegb> pmy: If you're interested in helping, more reviewers would be appreciated :)
<lukegb> Knowledgable people to review PRs, even without the commit bit, is useful because the maintainers don't have broad knowledge of every piece of software that exists
thibm has joined #nixos-dev
<lukegb> supersandro2000: so nixpkgs-review sets 'checkMeta = true;' which means evaluation will fail if there are unknown meta attributes - it might be worth setting that in your local nixpkgs config, at least when building things to test them
<supersandro2000> lukegb: thanks for digging this up
<supersandro2000> this should also fail when manually building
<supersandro2000> just add checkMeta = true to nix.conf?
<lukegb> no, in your nixpkgs config (e.g. where you have allowUnfree, maybe)
<lukegb> you might not have allowUnfree :)
<supersandro2000> I do
<supersandro2000> I am searching the man page for it
* lukegb looks
<lukegb> this doesn't actually seem to be documented anywhere
<lukegb> copumpkin was planning to default it to true ~3y ago but that never happened
<supersandro2000> {
<supersandro2000> }
<supersandro2000> checkMeta = true;
<supersandro2000> allowUnfree = true;
<supersandro2000> that does not work...
<eyJhb> pmy: I think that most don't really ping maintainers as well. I think the longest I have waited for is like 1-2 weeks
<eyJhb> But then when you ping, one should ensure that it builds, merge cleanly, etc... But yeah, there is a ton of PRs
<supersandro2000> and now I can't delete the build nix store file...
<eyJhb> Also why I wondered if we have any good guidelines for what to do. I have access to some nice stuff while at UNI, so I could run a bunch of tests while there...
red[evilred] has joined #nixos-dev
<red[evilred]> yeah - lots of PRs
<red[evilred]> sometimes it takes a bit of patience
cole-h has quit [Ping timeout: 256 seconds]
<supersandro2000> eyJhb: I can't really build anything that rebuilds the gtkwebrendere (?) and above 100 packages
<lukegb> there are some efforts to improve things - I think in particular the efforts on BORS and trying to give maintainers more power over their packages without involving someone with the commit bit
* lukegb is building chromium for the 4th time
<lukegb> I just wanted to test my pulseaudio PR on an actual system :(
<eyJhb> For now at least, not sure how long it lasts, I have access to a VM with 32 cores and 256 GB ram, so I can build quite some stuff...
<eyJhb> Would still be cool with a Nix community builder that maintainers etc. could use
<red[evilred]> lukegb (IRC): that would help a lot I think
<lukegb> at the moment the maintainers list is a bit arbitrary in terms of semantic meaning imo :P
<red[evilred]> lukegb (IRC): is there a thread tracking that? I'd love to see the progress on it
<lukegb> look for "SIG Workflow automation"
<red[evilred]> thanks luke
<red[evilred]> I'll quieue that up for the morning
<red[evilred]> later@
<red[evilred]> it's only 04:36 and I have meetings that start at 09:00 :-(
<pmy> eyJhb: I reported bug #93230 four months ago. Mentioned the responsible maintainer of pkgs.cacert. Zero reply since then.
<{^_^}> https://github.com/NixOS/nixpkgs/issues/93230 (by pmeiyu, 19 weeks ago, open): security.pki.caCertificateBlacklist is broken
<supersandro2000> red[evilred]: go to sleep and don't miss it
<eyJhb> pmy: But sometimes it makes sense to ping it in here as well
<eyJhb> Or mention in here :D Because as supersandro2000 states, maintainers sometimes have too many notifications
<supersandro2000> it is not only nix but about 25% I guess
<supersandro2000> if you want to merge something fast write me **one** message on IRC
<supersandro2000> if I miss it ask about it a couple of days later
<pmy> But this seems like a priviledge and is unfair to other PR/Bug Report waiting in line.
<lukegb> pmy: can you test with #105568?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105568 (by lukegb, 20 seconds ago, open): cacert: fix certificate denylist
<lukegb> I should go do $JOB now.
<pmy> lukegb: I will test it.
<pmy> lukegb: What's the best pratice to build and test a commit?
<lukegb> That... I can't really answer. A lot is dependent on how you're set up - if you're using channels it's a bit tricky, I think
<supersandro2000> pmy: thats why I started to look at PRs which are open since a long time, have no label with marge conflicts and are no drafts.
<supersandro2000> Can't you overwrite a specific module with a file? Then you could clone the repo, checkout the PR and change the module location
<lukegb> It's the package definition, really, not the module. But yeah, a nixpkgs overlay should do.
<pmy> I am using nixpkgs.config.packageOverrides. pkgs.cacert caused a rebuild-the-world. Still waiting.
<lukegb> pmy: yeah, maybe better to wait until it lands then... sorry.
sphalerite is now known as L1nuxH4ckerm4n
L1nuxH4ckerm4n is now known as sphalerite
orivej has joined #nixos-dev
alp_ has quit [Ping timeout: 272 seconds]
FRidh has quit [Ping timeout: 246 seconds]
FRidh has joined #nixos-dev
alp_ has joined #nixos-dev
mkaito has joined #nixos-dev
<lukegb> andi-: re #105568 do you have better suggestions for writing a test for the override knob? I kinda want to ensure that there's actually a CA present with those names (probably just grep) in the input set but not the output set but I'm reluctant to add more arguments just to make that all work
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105568 (by lukegb, 2 hours ago, open): cacert: fix certificate denylist
<andi-> lukegb: just make it an attribute set passthru.tests.test-whatever = cacert.override…
<andi-> ohh, now I got your question..
<andi-> mhm
<lukegb> I guess I could make it more strict in general and add a checkPhase that makes sure that all the entries from blacklist actually exist
<andi-> lukegb: I'll write you a comment on the PR
<lukegb> thanks
mkaito has quit [Quit: WeeChat 2.9-dev]
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
mkaito has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
v0|d has quit [Ping timeout: 240 seconds]
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
<FRidh> unstable channel blocker https://github.com/NixOS/nixpkgs/issues/105581
<{^_^}> #105581 (by FRidh, 19 seconds ago, open): vm-test-run-misc fails, blocking nixos-unstable(-small)
<eyJhb> supersandro2000: You can merge #105562 if you want to :)
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105562 (by ju1m, 5 hours ago, open): arduino-mk: wrap python scripts
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
saschagrunert has quit [Quit: Leaving]
<Mic92> supersandro2000: since you started as a maintainer, open prs decreased from 2.6k to 2.2k
<Mic92> wow 800prs a week: https://github.com/NixOS/nixpkgs/pulse
<Mic92> I remember we used to have around 500
<gchristensen> yeah...
<eyJhb> Looking forward to it hittinc close to o0
<eyJhb> to 0*
<gchristensen> lol
<eyJhb> The issues are however harder to bring down :p
<Mic92> not sure if that is required
<Mic92> there is always work-in-progress prs
<gchristensen> and PRs that are nice ideas but not really going to merge, but nobody wants to close
<eyJhb> Yeah of course, but there are a lot of PRs that can be merged
<Mic92> gchristensen: yeah, we are not good at disaggreeing.
<eyJhb> And I have a sneaking feeling, that we could get down to 500-1000
<gchristensen> yeah, it is hard :)
<gchristensen> but remarkably we make progress
<Mic92> eyJhb: when I started we had 500 open PRs and we were unhappy about that.
<gchristensen> we don't grow all that quickly. a few PRs each month
FRidh has quit [Ping timeout: 260 seconds]
<eyJhb> That might be the goal then, back to 500 open PRs and be unhappy!
FRidh has joined #nixos-dev
<Taneb> ...could there be a label for "PRs that are nice ideas but not really going to merge, but nobody wants to close"?
<Taneb> Maybe phrased slightly less intensely
red[evilred] has joined #nixos-dev
* red[evilred] handwaves some more
* red[evilred] gestures at his list of PRs, five of the six are ready to roll...
<lukegb> I kinda wanted to export PR information into prometheus
<gchristensen> what kind of PR data?
<lukegb> the same sort of stuff that's in pulse
<lukegb> yeah, that kind
<gchristensen> neat
<red[evilred]> but on that subject - I know this is certainly true for the security issues - but when you have a large block of stuff, it's difficult to navigate around so you spend more of your time context switching than actually doing the work.
<eyJhb> Taneb: Would be nice, so they could have a category
<lukegb> although... representing nixpkgs and nix on the same graph seems funky
* lukegb nods
<gchristensen> lukegb: I can make you an admin on the grafana, you can improve it
<lukegb> well, I can try
<Taneb> On a mostly unrelated note, what are the criteria for getting merge rights?
<lukegb> I'm "status.nixos.org@lukegb.com" :P
<lukegb> Taneb: there's a PR for that
<Taneb> I remember seeing it and forgetting where it is
<lukegb> #101806
<{^_^}> https://github.com/NixOS/nixpkgs/pull/101806 (by unode, 5 weeks ago, open): docs: Add 'how to request merging rights'
<lukegb> it references the issue for that, #50105, but broadly "contribute and people will nominate you"
<{^_^}> https://github.com/NixOS/nixpkgs/issues/50105 (by Infinisil, 2 years ago, open): New nixpkgs committers requests
<gchristensen> lukegb: you're an editor
<lukegb> thanks, I'll mess with a new dashboard
<gchristensen> samueldr: you're an editor now too
<Taneb> Not having written any NixOS modules so far I think I fall short for now :(
<gchristensen> Taneb: probably the most important thing is knowing your own limits
<red[evilred]> Taneb (IRC): I feel the same way and don't stress it. There's still plenty of other opportunities to contribute until you do feel comfortable.
<red[evilred]> for example - I chewed down the security issues queue by more than 50% over the last week and a bit. Most of them were either old or already fixed with a PR but someone forgot to close the issue
<gchristensen> Taneb: I don't think there would be any objections to you being added, I pinged domen
<eyJhb> red[evilred]: doing the lords work
<Taneb> gchristensen: thanks
<eyJhb> Only 13 security PRs open now
__red__ has joined #nixos-dev
<red[evilred]> yup and many of them are ready to go and have gone through review from multiple people
<red[evilred]> but I guess haven;t found a committer that feels comfortable / empowered? to commit them
<red[evilred]> (the fact that 3 of my 5 are all for cassandra probably means that when the right committer finds them then all 3 will likely merge at once)
<lukegb> can someone add the needs-backport tag to #105568 for me
<{^_^}> https://github.com/NixOS/nixpkgs/pull/105568 (by lukegb, 5 hours ago, open): cacert: fix certificate denylist
<hexa-> done
pmy has quit [Ping timeout: 240 seconds]
pmy has joined #nixos-dev
<eyJhb> Thanks supersandro2000
<lukegb> hexa-++
<{^_^}> hexa-'s karma got increased to 16
<red[evilred]> This is perhaps a stupid question - but I'm going to ask anyways.
<red[evilred]> in order to compile for darwin... if everything is sandboxed in hydra / nix
<red[evilred]> what are the strong / absolute limitations on it having to run on OSX
<red[evilred]> ELF format & linking I'm guessing
<red[evilred]> anything else?
<Taneb> The link to the source on search.nixos.org is broken :( it's adding an extra /source/
<eyJhb> How come nix not like int as strings? E.g. I have a attrset with "2019" as a key, but I do `nix-build -A "2019.web-awesome-calculator.build"`, but I can change it to foo, and it will work ("2019" -> "foo")
FRidh has quit [Ping timeout: 240 seconds]
saschagrunert has joined #nixos-dev
<cransom> eyJhb: ints as keys aren't supported. the general practice is to prefix with a _ if you have something that starts with a number.
<eyJhb> Guessing I will just rename it to challenges2019 then :) Is there any good place to read about scopes? I have something like test = config: let ... in { config ? config }: funcname "string" config;
alp_ has quit [Ping timeout: 264 seconds]
<__red__> cransom: I sent you a PM earlier - I figured it was the politest way to say "Hi" and stuff
<__red__> cransom: I don't like spamming people with github notifications so hit you up there instead
<__red__> can you take a peek please?
kalbasit has joined #nixos-dev
<thibm> eyJhb: cransom: int as keys are not supported, but "strings containing int" obviously work.
<thibm> > { "a" = 0; "1" = 2; }
<{^_^}> { "1" = 2; a = 0; }
<thibm> But that is tricky to use from the command line.
<gchristensen> > { ${0} = "hi"; }
<{^_^}> value is an integer while a string was expected
<thibm> they are* supported. (correct me if I'm wrong)
<gchristensen> neat
<lukegb> > { "1" = 2; }.1
<{^_^}> attempt to call something which is not a function but a set, at (string):440:1
<thibm> (no they are not. raah)
<thibm> > { "1" = 2; }."1"
<{^_^}> 2
<lukegb> yeah
<thibm> I think had a trick to use it from command line but I don't remember
<thibm> Found it: `nix-build -E 'with import ./. {}; "2019".web-awesome-calculator.build`
<thibm> instead of `nix-build -A "2019.web-awesome-calculator.build"`
<thibm> eyJhb: ^
<lukegb> I end up falling back to, err, things like `nix-build -E '((import ./. {}).foo.bar.baz)'`
<lukegb> yeah
<lukegb> Yours is more elegant :P
<thibm> It's not elegant but it works with int-as-strings without the shell interfering
<thibm> with the quotes
<thibm> :q
<thibm> (gasp). And `(import ./. {}).` is better than `with`
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
saschagrunert has quit [Quit: Leaving]
<eyJhb> thibm: yeah, the command line does not make it fun. But I it makes sense why it works that way I guess
<infinisil> thibm: nix-build -A '"2019".web-awesome-calculator.build'
<infinisil> Works
<thibm> That what I was trying to test, there's no reason it doesn't work.
<thibm> Something strange: take this file: http://ix.io/2GaO and run nix-build. You only get the gcc output.
<thibm> nix-build -A '"1"' does not work
<gchristensen> one complicating factor here is that nix-build takes integers for indexing lists
<gchristensen> let pkgs = import <nixpkgs> {}; in [ pkgs.hello pkgs.bat ]
<gchristensen> nix-build ./test.nix -A 1 -> bat
<LnL> huh, you can do that?
<thibm> oh. nix-build -A '"1"' -> bat too
<thibm> that explains the `the selection path '"1"' should be a list but is a set`, thanks.
<gchristensen> yes and it nests too let pkgs = import <nixpkgs> {}; in [ [] [ pkgs.hello pkgs.bat ] ] -> 1.1
mkaito has quit [Quit: WeeChat 2.9-dev]
rajivr has quit [Quit: Connection closed for inactivity]
alp_ has joined #nixos-dev
ris has joined #nixos-dev
<supersandro2000> What do you think about a shellcheck github action?
<gchristensen> to check changes to .sh files?
<gchristensen> we have about 500 of them, that sounds good
<infinisil> Would probably miss many since they're embedded in Nix multiline strings
<infinisil> And by many I mean most, since pretty much every derivation uses shell scripting
<infinisil> But nevertheless, I think checking some is still better than none
<gchristensen> yeah but if you look at the .sh files we have, they're imo the important ones
<gchristensen> the shell embedded in to derivations is largely trivial
<infinisil> Hehe, and we'd get a million "unquoted variable" errors
<gchristensen> supersandro2000: I'm super +1 on this, however, I think it would require some planning on how to do it
<gchristensen> how many of our 490 shell scripts will fail, and how can we fix them all before applying the check? (important: red X's should never be ignored)
<V> so, there's already the editorconfig check, which just fails on files touched by a PR?
<gchristensen> right, do we expect people to fix editorconfig fails? (imo yes : red X's should never be ignored)
<V> well, that's what I've been doing so far
<V> I think that's a reasonable way to encourage cleanup
<V> if it fails, I just add the whitespace changes/etc in another commit
<gchristensen> there are a bunch of files in here that I wouldn't want some random PR to be required to fix
<V> well, the PR would only have to clean up the file it touched, no?
<V> if that's not reasonable, I think the editorconfig check should be changed to fail on everything, with a huge cleanup commit
<V> (for consistency)
<gchristensen> no, editorconfig is whatever, less likely to be major
<gchristensen> but like stdenv? I don't want some trivial fixup there to cause someone out of their element to "fix" it
<gchristensen> does that seem weird?
<V> you could just fix the stdenv files and leave the rest to random people
<lukegb> my honest position is if we can automatically fix all of these problems in a single PR then we should just fix them
<gchristensen> yeah a sprinting through might be feasible
<V> I don't think there's a way to do it automatically, but it's definitely feasible to run through them manually
<lukegb> I think that's more feasible with editorconfig; shellcheck is probably a little more tricky
<V> like there are cases where you will want to apply shellcheck exceptions
<gchristensen> we could make this in to a to-do issue
alp_ has quit [Ping timeout: 272 seconds]
<lukegb> can we have a github action that checks that there are *fewer* shellcheck errors in modified files than there were before?
<lukegb> and then have a todo issue :P
<gchristensen> nice ratchet
<lukegb> I was wondering about doing it diff-based on changed lines, but... I think a ratchet is probably easier and has ~the same effect at lower cost
<lukegb> well, fewer-or-same-number
<gchristensen> lukegb: would you like to write a github action for a ratcheting shellcheck?
<lukegb> I can give it a shot at least
<lukegb> the mypy one is a good template
<gchristensen> that would satisfy my main annoyance: that stage-1 and stage-2 and other highly critical shell scripts aren't checked
cole-h has joined #nixos-dev
mkaito has joined #nixos-dev
<supersandro2000> infinisil: you can configure everything about shellcheck globally
<supersandro2000> I would just let it run on changed files anyway
<supersandro2000> if we don't want to fix it ignore it or add a TODO and a shellcheck disable for now
<supersandro2000> disables can be done in the cli tool globally, per file or per line
<gchristensen> I'd prefer fix them than ignore or disable
<gchristensen> and I think lukegb is right that we can organize a fixup party
<supersandro2000> there are certainly false positives
<supersandro2000> like prefer command over which
<qyliss> which isn't in stdenv, is it?
<qyliss> I'm sure I've had to add that as a nativeBuildInput before
<supersandro2000> qyliss: in nix command is fine to use
<qyliss> exactly?
<qyliss> so how would "prefer command over which" be a false positive?
<supersandro2000> but I replace a lot of stuff with functions in my bashrc and command takes a function as a valid binary no matter if it actually works
<supersandro2000> eg I replace grep with rrg and cat with bat
<supersandro2000> *rg
<supersandro2000> and I add some default commands to things and so on
<supersandro2000> so grep checks if rg is there but rg is also a function and command would always trigger it even if I do not have rg installed
<supersandro2000> and rg was also an alias to ripgrep
<supersandro2000> Is it fine to add new packages relying on electron 4? https://github.com/NixOS/nixpkgs/pull/103027
<{^_^}> #103027 (by scalavision, 3 weeks ago, open): cerebral-debugger: init at 3.1.0
alp_ has joined #nixos-dev
drakonis has quit [Quit: ZNC 1.8.2 - https://znc.in]
pmy has quit [Ping timeout: 272 seconds]
pmy has joined #nixos-dev
lassulus has joined #nixos-dev
andi- has quit [Ping timeout: 244 seconds]
andi- has joined #nixos-dev
m1cr0man has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-dev
Jackneill has quit [Ping timeout: 272 seconds]
thibm has quit [Quit: WeeChat 2.6]
orivej has quit [Ping timeout: 260 seconds]
Jackneill has joined #nixos-dev
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
mkaito has quit [Quit: WeeChat 2.9-dev]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ is now known as lassulus
pmy has quit [Ping timeout: 260 seconds]
pmy has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
pmy has quit [Ping timeout: 272 seconds]
pmy has joined #nixos-dev
orivej has joined #nixos-dev
__monty__ has quit [Quit: leaving]
orivej has quit [Ping timeout: 240 seconds]
pmy has quit [Ping timeout: 265 seconds]
pmy has joined #nixos-dev
mkaito has quit [Quit: WeeChat 2.9-dev]