worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
ixxie has quit [Ping timeout: 264 seconds]
<samueldr> the machines we lost were x86_64, right?
<samueldr> like we had machines stuck in "copying inputs"
<samueldr> though what do I know, I can't seem to really make sense of the dashboard
<jtojnar> worldofpeace added the throws
<jtojnar> I am considering just merging it to staging soon, tired of waiting 😁️
<samueldr> (I was looking at why there was no channel bump on unstable since 3 days ago)
<samueldr> (looks like the queue is sizeable, that's all)
abathur has quit [Ping timeout: 256 seconds]
<worldofpeace> Jan Tojnar: I probably should QA pantheon, last time there were issues at runtime that could only be found like that
<jtojnar> worldofpeace will try that too
Guest30 has joined #nixos-dev
<jtojnar> worldofpeace .wingpanel-wrap[1278]: Settings schema 'io.elementary.desktop.wingpanel.bluetooth' is not installed
<jtojnar> getting a wingpanel crash
<jtojnar> though it does not sound like something that could be caused by our upgrade
* jtojnar uploaded an image: Screenshot from 2020-03-24 02-59-28.png (34KB) < >
<jtojnar> ugh, geary is ugly
<jtojnar> another crash (desktop panel in system settings): Settings schema 'io.elementary.desktop.wingpanel' is not installed
<jtojnar> "Settings schema 'apps.light-locker' is not installed" in security panel
drakonis has quit [Quit: WeeChat 2.7.1]
<jtojnar> Settings schema 'io.elementary.dpms' is not installed in power
justanotheruser has quit [Ping timeout: 246 seconds]
Guest30 has quit [Ping timeout: 264 seconds]
<{^_^}> firing: BuildsStuckOverTwoDays:
drakonis has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-dev
orivej_ has quit [Ping timeout: 264 seconds]
<worldofpeace> Jan Tojnar: huh, on master it's like that too
<worldofpeace> it should have failed though since it checks if its running
abathur has joined #nixos-dev
<jtojnar> did we change anything?
<worldofpeace> maybe a backport went bad
<worldofpeace> So it could crash from loading a certain indicator
abathur has quit [Ping timeout: 264 seconds]
<worldofpeace> Jan Tojnar: I think maybe how we changed wrapGAppsHook broke my hackery
<jtojnar> worldofpeace postBuild too soon?
<worldofpeace> Jan Tojnar: I think it's because we need to run gappsWrapperArgsHook
<jtojnar> oh, symlinkjoin is just a runcommand
<jtojnar> yeah, running the hook manually will be needed
<worldofpeace> I'm not sure if I could switch from using symlinkJoin
<jtojnar> yeah, we are not really running a build so runcommand-based builder makes sense
<jtojnar> but at the same time we want to use the infrastrucure we have in generic builder
<worldofpeace> Jan Tojnar: I could do linkedWingpanel = symlinkJoin ... and then just throw that into a stdenv.mkDerivation and wrap it there
<jtojnar> also need to do same for the swichboard wrapper
<jtojnar> worldofpeace at that point I would just use lndir in mkDerivation
evanjs has quit [Ping timeout: 265 seconds]
<worldofpeace> Jan Tojnar: I did that exactly
evanjs has joined #nixos-dev
<{^_^}> elementary/switchboard-plug-about#116 (by jtojnar, 2 hours ago, open): Failed to open file “/sys/block//queue/rotational”:
<worldofpeace> Jan Tojnar: huh, the about section looks messed up in a qemu vm right?
* jtojnar uploaded an image: Screenshot from 2020-03-24 06-25-26.png (93KB) < >
<worldofpeace> weird
<worldofpeace> Jan Tojnar: Here's my PR fixing them
<{^_^}> #83265 (by worldofpeace, 52 seconds ago, open): Fix wingpanel and switchboard
julm has quit [Ping timeout: 240 seconds]
<jtojnar> clicking though all the apps and switchboard panels, it seems to work
julm has joined #nixos-dev
<jtojnar> except for camera, which crashes on startup (possibly the same issue as Cheese has in VM)
<worldofpeace> Jan Tojnar: I should probably create some sort of test for switchboard that just does that eventually
<jtojnar> and Geary looking ugly as hell
<danderson> another wild nixos use case appears at work! We need to spin up networks of VMs to do horrific NAT traversal testing and find bugs in the linux kernel. Looks likely we'll use nixos-generators to plop out qemu images for a variety of configs
<danderson> it'd be even cooler if we could reuse nixos's test libraries, which already take care of bringing up networked VMs, but not sure how separable they are
drakonis has quit [Quit: WeeChat 2.7.1]
lovesegfault has quit [Quit: WeeChat 2.7.1]
<cole-h> jtojnar: Is the pipewire 0.2.7 -> 0.3.1 sha256 valid? I've never seen one in that format before
<worldofpeace> cole-h: that's me making a commit with truely tired hands weeks ago :D
<cole-h> worldofpeace: :D So I take it that isn't a valid hash? Or is that a "SRI" hash that I've read about here and there?
<worldofpeace> cole-h: ooh, I thought you meant the commit message, which is right now. That is an SRI hash
<cole-h> Oh, OK. Just seemed since I don't think I've seen any SRI hashes in nixpkgs until now
<cole-h> (using "in" loosely)
<worldofpeace> cole-h: Oh no, I'm wrong again. It's just base64 encoded
<cole-h> worldofpeace: Should I make a note of all the commits introducing those? Or does it not matter
orivej has joined #nixos-dev
<{^_^}> firing: BuildsStuckOverTwoDays:
* cole-h did it anyways
cole-h has quit [Quit: Goodbye]
lovesegfault has joined #nixos-dev
abathur has joined #nixos-dev
lovesegfault has quit [Ping timeout: 260 seconds]
abathur has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
Guest30 has joined #nixos-dev
<Guest30> Would extraInitrd path `/foo` be correctly interpreted as `/mnt/foo` under nixos-install?
<Guest30> I tried it with key file and it doesn't work well. I think this should be a issue with interpretation of path in extraInitrd. Here is my report:
<{^_^}> #83266 (by LEXUGE, 59 minutes ago, open): Unable to setup keyfile LUKS with `nixos-install`
<makefu> with the move to the new host it seems that the mail archives broke:
orivej has quit [Ping timeout: 258 seconds]
Guest30 has quit [Remote host closed the connection]
lovesegfault has joined #nixos-dev
__monty__ has joined #nixos-dev
FRidh has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
orivej has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
<domenkozar[m]> has reached phase 1, Ben has already started work. Second phase crowdfunding is about plumbing existing errors to use the error reporting in existing codebase. If your company wants to support improving Nix ergonomics let me know if you have any questions.
<domenkozar[m]> Ericson2314++ for hacking on Nix lately
<{^_^}> Ericson2314's karma got increased to 3
vcunat has joined #nixos-dev
<vcunat> gchristensen: some key jobs are stuck on Hydra for days, and the situation doesn't seem like it will disappear. Right now mainly release-19.09-small is blocked by that. Their steps weren't ran even a couple days ago when x86* queue was empty - some are in a bad state, apparently. Another case seems chromium build in 20.03.
<vcunat> If I could, I would try to simply restart the queue runner. I think it's helped similar situations in past.
<vcunat> also shows some builds "running" for a few days, but those don't appear to be blocking these critical things.
<vcunat> Unfortunately I can't see what's wrong, but at least we could kick it to get channels going again. 19.09-small is waiting for security updates, and it's a week old now.
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
{`-`}_ has joined #nixos-dev
{`-`} has quit [Ping timeout: 246 seconds]
phreedom_ has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
<niksnut> vcunat: I've restarted the queue runner
<{^_^}> resolved: BuildsStuckOverTwoDays:
orivej has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 265 seconds]
<srk> looks like ppc64le is missing bootstrap files - pkgs/stdenv/linux/bootstrap-files/ppc64le.nix': No such file or directory
<srk> this commit adds most of the stuff but these two are missing
<{^_^}> #45340 (by CrystalGamma, 1 year ago, merged): [RFC] ppc64le enablement
<srk> s/commit/pr
<srk> looks good on hydra as well
<vcunat> Well, you can start testing with that. I pinged the old thread:
<vcunat> Thanks Eelco. I hope the queue now just needs more time to recover, as it still doesn't seem good when I look at runnable counts in
<srk> yep, will try, I don't have power, helping a friend who wants to try nixos on it
<srk> vcunat: btw what's the reason for hosting hydra tarballs on tarballs.nixos?
<srk> so they won't get gced or performance?
<vcunat> I actually don't know how exactly downloading through works, but it doesn't seem an ideal solution.
<vcunat> Using just binary cache ( has the disadvantage that changing /nix/store location changes the hashes.
<vcunat> (So those outliers could not download it from there.)
phreedom_ has quit [Remote host closed the connection]
<vcunat> GC might be a risk, but I'm not sure about that.
<srk> np, just curious
phreedom has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
<jtojnar> cole-h: I ju use base64 hashes since that is what Nix unstable prints for me on mismatch
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
abathur has joined #nixos-dev
<rnhmjoj> what do you do when you are testing something that will cause a mass rebuild on every new change you make? is there a trick to only partially rebuild?
<gchristensen> what are you testing? usually the answer is "get a big system to play with"
<rnhmjoj> i'm trying to let python libraries propagate their wrapper arguments up to the final python wrapper, so that stuff that has runtime dependencies like Qt and GTK works in the interpreter
<gchristensen> ouch :)
<LnL> we should split up the bootstrap python
<rnhmjoj> yeah, there's no chances i'm going to rebuild qtwebengine every time i change a line
<gchristensen> lol.
orivej has joined #nixos-dev
<rnhmjoj> ok, i think i've found a way to only rebuild on package i need to test. basically i've duplicated the builders i modified
<jtojnar> rnhmjoj I usually create two copies of the setup hook and add an argument to switch between them and only switch it in top-level
<rnhmjoj> that's pretty much what i did
zarel_ has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<gchristensen> ma27[m]: available?
<ma27[m]> yes
zarel_ has joined #nixos-dev
zarel has quit [Ping timeout: 264 seconds]
<gchristensen> ma27[m]: I'm thinking let's update hydra on 19.09, 20.03, and master to the version in phase 1 here: and adding a systemd job to run the hydra-backfill-id program after hydra-init
<{^_^}> hydra#725 (by grahamc, 1 hour ago, open): Two-Step Jobset ID Migration
<gchristensen> and then wait 1 month, and then update to the version in Phase 2, what do you think?
<Ericson2314> niksnut: is there an easy way to run the install checks without installing?
justanotheruser has quit [Ping timeout: 246 seconds]
<ma27[m]> oh I just realized that in part 2 the columns aren't nullable anymore
<ma27[m]> I'm wondering if a 1month window is sufficient
ixxie has joined #nixos-dev
<gchristensen> I don't know
<gchristensen> ma27[m]: but they can roll back
<ma27[m]> shouldn't we provide both versions and select a default one based on the state version? (so similar to
<{^_^}> #82353 (by Ma27, 1 week ago, open): nixos/nextcloud: fix upgrade path from 19.09 to 20.03
<gchristensen> ma27[m]: sa at worst the deploy fails and they figure out how to roll back
<domenkozar[m]> gchristensen: I'd expect stable branches not to break backwards compatibility
<gchristensen> we can only move 19.09 up to the phase 1, then
<gchristensen> and possibly 20.03 I suippose
<ma27[m]> not sure about 20.03 then: when we backport a newer hydra after the release it's technically a breaking change, right?
<gchristensen> yep
<gchristensen> if we get the phase-1 update in to 19.09 right away, then there will be an opportunity for users to get the migration and backfiller running before 20.03 is out
<domenkozar[m]> couldn't the module have two packages and restart itself and pick the correct one?
<ma27[m]> also, is it safe to rollback hydra despite schema changes? I only see upgrade scripts in src/sql
<gchristensen> phase 2's migrations will not execute if the backfiller has not run
<gchristensen> so rolling back from a failed phase-2 deploy to phase-1 or before is fine, but somebody who is post-phase-2 cannot roll back to before phase 2
<ma27[m]> I think that's the safest approach and did this e.g. for nextcloud already ( :)
<{^_^}> #82353 (by Ma27, 1 week ago, open): nixos/nextcloud: fix upgrade path from 19.09 to 20.03
<gchristensen> that sounds good
<ma27[m]> I actually had a long discussion with fpletz about two weeks ago regarding nextcloud, the notes we gathered may be helpful for hydra as well:
<gchristensen> so in this case, what we're thinking is: push an update to each branch (master, 20.03, 19.09) with the phase-1 revision and the hydra-backfill-ids as a systemd job after hydra-init
<ma27[m]> If everyone is fine with this, I could file a PR tonight or tomorrow :)
<gchristensen> and then at some point after that, but before 20.03 is released, pushing the phase-2 revision to (master, 20.03) ?
<gchristensen> sounds good to me, ma27[m] :)
<niksnut> Ericson2314: no
<ma27[m]> why not add both rn? and select the default package in the module on the state version and ensure with a warning (if phase-1 hydra is used) that users should upgrade to phase-2 after deploying phase-1 hydra.
<Ericson2314> niksnut: I suppose recursive nix is the hope, then
<niksnut> we should remove hydra from nixpkgs. it was always a mistake to have it there (duplicating the nixos module, etc.)
<gchristensen> ma27[m]: the stateVersion cannot easily be changed, because so many things hook in to it. the reality of stateVersion is it is a pin until we can think of an actually viable upgrade path, I think
<niksnut> Ericson2314: hm, what's relation with recursive nix?
justanotheruser has joined #nixos-dev
<Ericson2314> niksnut: a way to run the tests without waiting for a full rebuild
<ma27[m]> niksnut: I'll agree with this as soon as flakes are out (also -1 package for me to maintain :p). Right now I think it's easier to provide the package and an upgrade path within nixpkgs.
<ma27[m]> gchristensen: I'm only talking about the default. After phase-1 hydra is deployed, one would have to set e.g. `services.hydra.package = pkgs.hydra-phase2` explicitly
<gchristensen> ma27[m]: having them both packaged sounds like a great idea, it will make it easier for users to fix their deployment
<ma27[m]> the condition which package to select, can be wrapped in a `mkDefault`
<gchristensen> sure
<gchristensen> niksnut: unfortunately, hydra is released software in unreleased software's clothes :P
<gchristensen> does icetan come around IRC?
<tilpner> They're on Matrix, that might be quicker than waiting for them here
<gchristensen> cool
teto has quit [Ping timeout: 246 seconds]
<ryantm> r-ryantm/nixpkgs-update logs are now automatically available
orivej has joined #nixos-dev
<gchristensen> nice!
<gchristensen> ryantm++
<{^_^}> ryantm's karma got increased to 10
teto has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
<jtojnar> the evals in can be cancelled now, the branch has been merged to staging
cole-h has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace:
<clever> gchristensen: after 3 days, the python ffi thing i restarted passed without issues, working up the dep tree...
<worldofpeace> Jan Tojnar: yay gnome 3.36 🎊
<Profpatsch> gchristensen: what do you think about a @NixOS/mentors team that people (possibly with merge-rights) can add themselves to, to be pinged if there’s no maintainer or code-owner for a PR?
<Profpatsch> (not automatic pings, rather a sentence in the PR template to ping that team if there is nobody more specific that can be pinged
<gchristensen> it'd be good to first get some numbers on how many PRs that would be triggered on
<gchristensen> a more balkanized approach would be more sustainable I think
<Profpatsch> If it stays under 10 pings/week I think it should be fine. If contributors are abusing the mention, it can be handled socially.
<gchristensen> right, so getting these numbers would help show if it is viable
<Profpatsch> How would you get numbers without implementing it if it’s not going to be automated.
<MichaelRaskin> And «anybody more specific» is probably what will need to be documented first? Newcomers complain that figuring this out is not easy
<Profpatsch> Well, if nobody is code owner or pinged by ofborg, there is nobody.
<MichaelRaskin> Well, distribution of time-to-first-reply might be useful
<gchristensen> how many of the first 50 PRs have no requested reviewer, for example
<MichaelRaskin> Ah, it's usually complicated about new packages
<Profpatsch> Feel free, I’m not gonna run any numbers here, anectodal evidence of people complaining about non-existent reviews is enough for me.
<gchristensen> I'm not debating that something is needed to make it better
<Profpatsch> And who is going to review new packages by people without merge rights (usually a few people do it for a while and then get burned out so nothing happens)
<gchristensen> I want to ask these questions to know if that method is viable
<Profpatsch> So your question is: even if maintainers are pinged, are they still not responding?
<Profpatsch> Because if nobody is pinged, by definition nobody is responding.
<Profpatsch> Except for a few heroes that burn out after a while.
<gchristensen> no my question was how many of the newest 50 open PRs have no requested reviewer
<gchristensen> maintainers who don't reply is a different problem I think
<Profpatsch> if the answer was 40/50, what would be different if the answer was 5/50 instead?
<gchristensen> 40 potential pings in 4 days is a lot more than 5 pings in 4 days
<Profpatsch> Well, that can be influenced by how much it is advertised and how the PR template would be phrased.
<gchristensen> I don't think "hoping people who need it don't use it much" is a good strategy, when there are quite likely additional ways we could think through this problem and come up with ideas -- ideas which would probably be influenced based on how many we're talking about
<Profpatsch> There’s also the case where a maintainer has no merge bit
<gchristensen> and again, I like the idea and agree with the concept -- but it is important to make sure the solution fits the scope of the problem
<gchristensen> and some basic data gathering is an important part of this
<gchristensen> I bet you could solve this in 50 lines of execline with curl and jq
<Profpatsch> I bet it’s fastest to just open 50 tabs …
<Profpatsch> :)
<gchristensen> I'll leave that up to the author
vcunat has quit [Ping timeout: 240 seconds]
<Profpatsch> I wouldn’t even count code owners like infinisil or niksnut, because I’m certain they get ten times the notifications they can review already
<gchristensen> I agree
<infinisil> Hehe kinda
<infinisil> I still like the idea of reviewing PRs randomly to bring down average waiting time
<infinisil> ,random-pr
<{^_^}> (by bignaux, 2 weeks ago, open): pysolfc: 2.6.4 -> 2.8.0
<infinisil> What's the easiest way to check out a PR's branch so I can push to it?
<jtojnar> gh pr checkout #xxx
<Profpatsch> lol, there’s PRs like which are not package related and don’t even CC anybody
<{^_^}> #83249 (by bennofs, 18 hours ago, open): nixos/release-combined.nix: fix tested/supportedSystems (master version of #82886)
<Profpatsch> I’m 100% there won’t be a review.
<gchristensen> I don't disagree with your problem statement, or even the solution
<infinisil> jtojnar: gh is from?
<cole-h> infinisil:
<jtojnar> infinisil yup.
<infinisil> Ah nice
<Profpatsch> Okay, I count 17/50 in the last 24 hours, 3 are by ryantm-bot
<rnhmjoj> i have an alias to checkout PRs:
<jtojnar> infinisil you might need to config your git if you use it over ssh
<Profpatsch> So this could be as much as 10/day.
<gchristensen> okay, that is probably too high for that approach then
<infinisil> Cool, I'll see if it works in a bit (once I fixed up that PR)
<gchristensen> Profpatsch: what if instead ofborg picked a random member of that team, if no other maintainers were identified?
<gchristensen> we can make the team open to join, so people can sign up as interested
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
<ryantm> I was thinking some ideal approach would be assigning a case worker, with the case worker saying how much they can handle. Automatically assigning a new case worker due to inactivity would be pretty great too.
<ryantm> or maybe in keeping with our RFC terminology, a PR shepherd.
<rnhmjoj> so, i think i have a way to handle the wrapping of python libraries. basically i added a hook that writes the wrapper arguments of the package to /nix-support/make-wrapper-args. then in the buildEnv i read and collect the arguments from this file for each path in the environment and finally call makeWrapper. what do you think?
<infinisil> jtojnar: Yup that worked (with the git config thing), thanks :D
<infinisil> This probably also works with my existing PR checkout workflow (a git fetch && git checkout of the PR branch)
<infinisil> (a small script for that)
<jtojnar> infinisil does fetch & checkout correctly set the branch remote?
<Profpatsch> gchristensen: sounds reasonable, but in order to not die of bus factor I’d pick two.
<gchristensen> might be good
<gchristensen> I like ryantm's idea of monitoring responsiveness
<Profpatsch> And always make sure that ofborg requests two people.
<Profpatsch> It could randomly pick from the pool if a package only has one maintainer.
<Profpatsch> monitoring responsiveness sounds like a lot more work to implement
<infinisil> Request another person every week of inexistant reviews :P
<gchristensen> one step at a time
<infinisil> jtojnar: Ah no it doesn't
<jtojnar> now my problem shifted to garbage collection of git branches
<srk> declarative git needed
<infinisil> jtojnar: Could do a `git clone` from the local nixpkgs repo into a temporary directory for every PR
<infinisil> And use --reference and --dissociate to speed it up
<infinisil> Or maybe not needed
<infinisil> Oh yeah, needed if done as `git clone
<infinisil> .. wait I'll test this first, that was a preliminary sending
<jtojnar> I used `git branch --merged master | grep -v "\* master" | xargs -n 1 git branch -d` in the past but then I ran it outside of master and it deleted it :P
<MichaelRaskin> I think there are quite a few topics where waiting four or five days for the person who knows the area might be preferable to talking a randomly assigned person to figure out what is going on. So maybe if there is someone assigned, it's better to not immediately pick a random extra person…
<infinisil> Hm yeah this isn't as straightforward as I thought, never mind thatt
v0|d has quit [*.net *.split]
tilpner has quit [*.net *.split]
b42 has quit [*.net *.split]
MichaelRaskin has quit [*.net *.split]
m1cr0man has quit [*.net *.split]
cptchaos83 has quit [*.net *.split]
b42 has joined #nixos-dev
v0|d has joined #nixos-dev
m1cr0man has joined #nixos-dev
<FRidh> rnhmjoj: that fits with my idea on declarative wrappers
cptchaos83 has joined #nixos-dev
<FRidh> but I intended to wait with that until we have structured attributes in our standard environment
<worldofpeace> niksnut: could you review the perl part of #78648 ?
<{^_^}> (by mkg20001, 8 weeks ago, open): users-groups: add skel support via environment.etc.skel
<rnhmjoj> FRidh: would you accept that as a stopgap solution? i think it's a pretty serious problem that should be solved as soon as possible.
<FRidh> rnhmjoj: if there's no regressions :)
FRidh has quit [Quit: Konversation terminated!]
<rnhmjoj> Fridh: hopefully it shouldn't be too problematic. i'll finish this up and make a PR. thank you!
<{^_^}> firing: RootPartitionLowDiskSpace:
<gchristensen> hrm
tilpner has joined #nixos-dev
<jtojnar> rnhmjoj is that intended to that allow us to get rid of propagating the python dependencies?
<rnhmjoj> Jan Tojnar: what i'm trying to do is making python libraries that are using Qt and GTK working when running from a standard python interpreter. the primary example is matplotlib that has Qt or GTK backends to show plots in a window.
<worldofpeace> rnhmjoj: structured attributes is actually a good thing to wait for, but I do agree this issue is a serious problem that I also wanted to somehow handle/fix for 20.09
<worldofpeace> I believe we're now tracking this thing in, or maybe I missing some context of this discussion
<{^_^}> #78792 (by worldofpeace, 7 weeks ago, open): do not invoke wrapProgram directly, make a wrapProgramsHook
<worldofpeace> (btw, I also believe structured attributes should be a serious priority to get into 20.09 as early as we can)
<gchristensen> sgtm
<rnhmjoj> worldofpeace: thank you, i was about to ask you. i forgot about that issue
<rnhmjoj> yes, the way wrapper are currently implemented is far from ideal
<worldofpeace> rnhmjoj: I'd say it's causing pain at this point (especially for me as a dev)
<worldofpeace> hmm, we need a label like "high priority" so those tickets PRs can stick out in the 20.09 milestone
<rnhmjoj> pinning would be excessive?
<worldofpeace> rnhmjoj: oh wait you can pin in the milestone right?
<worldofpeace> oh no, you can order
<rnhmjoj> that would still be ok
vcunat has joined #nixos-dev
<jtojnar> there were some voices other parts of the structuredAttrs should go through RFC process too
<jtojnar> like the env attribute
MichaelRaskin has joined #nixos-dev
<{^_^}> firing: RootPartitionLowDiskSpace:
orivej has joined #nixos-dev
drakonis has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
<pie_[bnc]> I would like to bring this to attention
<{^_^}> nix#2981 (by yorickvP, 37 weeks ago, open): replace in-memory nar caching with on-disk nar caching when >256MB
abathur has joined #nixos-dev
<pie_[bnc]> can we just get someone that just merges yorick's PRs when from the point they get ignored
<yorick> I dunno, they often make things worse
<yorick> like the json fiasco
<pie_[bnc]> at that point maybe they wont be ignored anymore :P
<domenkozar[m]> it's extremely out of date
<yorick> it wasn't at some point
<yorick> I think a lot of the conflicts are the big string_viewening
<domenkozar[m]> I added a comment
<pie_[bnc]> domenkozar[m]: does it say "this is out of date."? :P
<pie_[bnc]> (jk)
<gchristensen> asciidoc from adisbladis! 👀
<{^_^}> firing: RootPartitionLowDiskSpace:
<Ox4A6F> Nyanloutre++
<domenkozar[m]> > Building nixpkgs docs takes well under a second - even on my laptop
<{^_^}> undefined variable 'Building' at (string):292:1
<Ox4A6F> adisbladis: ++
<domenkozar[m]> seems like all three bad things are about the conversion
<Nyanloutre[m]> hello
<Nyanloutre[m]> [0x4A6F]: What do you want ?
<Ox4A6F> Thanking you for the usb_modeswitch fixes.
<cole-h> adisbladis++
<{^_^}> adisbladis's karma got increased to 40
<{^_^}> firing: RootPartitionLowDiskSpace:
<{^_^}> firing: RootPartitionLowDiskSpace:
<domenkozar[m]> sigh
<domenkozar[m]> let's switch to discord :D
<tilpner> Please don't joke about that c.c
<domenkozar[m]> it's not a joke :)
<tilpner> D:
<domenkozar[m]> it has really seamless audio & video
<domenkozar[m]> I'd love to have an easy way to chat about a topic ad hoc
<domenkozar[m]> and it frigging works
<samueldr> let's use microsoft office for docs next!
<tilpner> And add opt-out analytics to Nix?
ixxie has quit [Ping timeout: 240 seconds]
<gchristensen> and ads
ixxie has joined #nixos-dev
<domenkozar[m]> samueldr: let's have docs first :)
<domenkozar[m]> ok ok, I'll be fine with slack then
<domenkozar[m]> I think a lot more folks would join the chat if it was easier
<tilpner> And a lot of people would leave and never come back, if it was a terrible platform like Discord
<domenkozar[m]> why is it terrible?
<srk> I value my memory too much to run these web based text rendering clients
* tilpner still hasn't coped with the Rust move, if it wasn't obvious
<srk> where did they move? :D
<tilpner> ._.
<drakonis> there's already a nixos discord mind you
<clever> drakonis: havent seen that one yet
<drakonis> still not a fan of how everyone consolidated on discord
<domenkozar[m]> I couldn't find one via search
<clever> drakonis: i prefer slack over discord, but i can see how discord's idea of all servers in one thing is a little better
<drakonis> this is the invite
<domenkozar[m]> glad I'm not the first one thinking about this
<drakonis> i'd prefer to use irc though
<tilpner> domenkozar[m]: We can't default to allowUnfree = false, and then recommend something horrible like Discord
<drakonis> discord's issue is that if it disappears, a lot will be lost
<clever> domenkozar[m]: heh, and discord is already calling you OP
<srk> aah, Mozilla server shutdown
<drakonis> i have an account but i'm not into it for this kind of usage
<domenkozar[m]> tilpner: you can use it with OSS firefox :D
<tilpner> But I'll be banned if I create my own client
<drakonis> the service is not OSS
lovesegfault has joined #nixos-dev
<domenkozar[m]> if that's stallman bullshit I'm not reading it
<drakonis> its not stallman bullshit
<domenkozar[m]> ok
<drakonis> it doesnt recommend irc as an alternative to discord
<domenkozar[m]> Regardless of whether or not you are the kind of person who mocks or ridicules people—you should be able to use your communications tools to mock and ridicule people, if you so wish.
<drakonis> it does mention mattermost
<domenkozar[m]> alright I'm stop reading this
<drakonis> aight
<drakonis> i didnt se ethat
<drakonis> see that one
<domenkozar[m]> I'll*
<drakonis> that's a dumb one
<tilpner> Do read the next sentence
<tilpner> *paragraph
<domenkozar[m]> > These are normal, acceptable things to do in society.
<{^_^}> error: syntax error, unexpected ',', expecting ')', at (string):292:17
<domenkozar[m]> this one?
<tilpner> No, "The point of bringing this up is not that you should tolerate these things in your group. The point is that the place to deal with these is in your group’s own culture and internal rules, not a legal agreement that everyone is forced to be bound by simply to participate."
<domenkozar[m]> do we have to debate if mocking people is ok
<tilpner> We didn't agree to any ToS before joining #nixos, and yet it's a civil place
<abathur> I've been working with a project that uses zulip
<tilpner> No, it's obviously not okay
<tilpner> But the article is making a point about why it should be not okay
<domenkozar[m]> I'm kind of glad these rules exist, people on twitter have been calling for such actions for a decade
<tilpner> The problem is that now instead of community moderators, some random employee has to decide what is inappropriate
<domenkozar[m]> that's great, we don't emotionally drain our community
<MichaelRaskin> Like that time GitHub shadowbanned a random contributor?
<MichaelRaskin> Not sure it was not a drain…
<domenkozar[m]> well there are going to be false positives whatever banning process you use
<gchristensen> (and that user is back)
vcunat has quit [Quit: Leaving.]
pie_[bnc] has quit [Quit: No Ping reply in 180 seconds.]
<MichaelRaskin> Was it confirmed that GitHub just failed at keeping a DB during new-notifications rollout?
<MichaelRaskin> Or is it still unclear what is going on?
pie_[bnc] has joined #nixos-dev
<gchristensen> hard to know :(
<MichaelRaskin> That feeling when GitHub being bad at handling data consistency is the optimistic interpretation
<gchristensen> heh
<domenkozar[m]> systems fail :)
* domenkozar[m] looks outside
<gchristensen> hehehe
<domenkozar[m]> oh rust switched to discord?
<domenkozar[m]> seems like we're following as with the rest in a year then :P
<tilpner> Mozilla switched to Matrix
<tilpner> And Matrix is pretty usable (shiny if you want), if you don't use it to interface with IRC
<domenkozar[m]> I guess they'll get some hard focus
<MichaelRaskin> I think they already got some?
<domenkozar[m]> Matrix is such crap
<MichaelRaskin> The point was that they listed the choice criteria, then there was some amount of box-ticking
<domenkozar[m]> there's no software that makes me more anxious
<MichaelRaskin> Matrix is fine, as long as you don't touch as homeserver
<domenkozar[m]> it takes me 3min just to figure out how to private message someone
<tilpner> Which domenkozar[m] is
<tilpner> Every time?
<domenkozar[m]> yeah because I forget in 3 days
<tilpner> You don't have to use Riot if you don't like it
<tilpner> Unlike other platforms, it's an open protocol
ixxie has quit [Ping timeout: 256 seconds]
<gchristensen> anyone want to review my fairly simple (but long) PR?
<{^_^}> nixops#1263 (by grahamc, 3 hours ago, open): script_defs: open state files and deployments with a context manager
<{^_^}> firing: RootPartitionLowDiskSpace:
<abathur> I'm not fully enamored with zulip, but it's threaded history can be nice
<abathur> *its
<gchristensen> okay fine {^_^} I'll fix it
<{^_^}> resolved: RootPartitionLowDiskSpace:
<gchristensen> oh it is resolved ...
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
__monty__ has quit [Quit: leaving]
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
abathur has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-dev
abathur has joined #nixos-dev
abathur has quit [Client Quit]
<{^_^}> firing: RootPartitionLowDiskSpace:
<gchristensen> droeunthaosnuthsou
<clever> shal we play a game?, cat or password? ^^
<gchristensen> or graham frustrated by this error :P
<clever> lol