<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
<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: https://github.com/NixOS/nixpkgs/issues/83266
<{^_^}>
#83266 (by LEXUGE, 59 minutes ago, open): Unable to setup keyfile LUKS with `nixos-install`
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]>
https://opencollective.com/nix-errors-enhancement 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>
https://hydra.nixos.org/machines 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]
<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 https://hydra.nixos.org/queue-runner-status
<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 hydra.nixos.org works, but it doesn't seem an ideal solution.
<vcunat>
Using just binary cache (cache.nixos.org) 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
<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: https://github.com/NixOS/hydra/issues/725 and adding a systemd job to run the hydra-backfill-id program after hydra-init
<{^_^}>
#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
<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
<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
<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>
.. 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 ?
<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
<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 matrix.org 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