supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
rajivr has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
teto has quit [Ping timeout: 246 seconds]
ris has quit [Ping timeout: 256 seconds]
angerman has quit [Excess Flood]
angerman has joined #nixos-dev
<__red__>
Greetings
<samueldr>
__red__: there are release-specific staging branches
<__red__>
glibc bump for nixos-20.09.
<__red__>
ahh ha!
<__red__>
oh - so staging and staging-next are for master then?
<__red__>
there isn't a "staging-next" equivalent for 20.09
<gchristensen>
but even still, after the release I usually think to skip staging for release branches
<__red__>
so should I just base it off nixos-20.09 then?
<__red__>
I promise that one day I won't be so high maintainence ;-0
<samueldr>
there wouldn't be a need for staging-xx.yy-next, if staging is used to keep mass rebuilds from making small updates go through quickly
<samueldr>
as there is no "work" in staging-xx.yy; only a buffer of changes
<cole-h>
__red__: Not nixos-20.09, but release-20.09
<samueldr>
but as gchristensen alludes to, it's not always used, and might be problematic in the end as there is no one tasked with making staging merge into the release branches
<__red__>
I can't think of many other packages that are likely to trigger as many rebuilds as glibc
<__red__>
owait
<__red__>
release-20.09?
<__red__>
have I been branching off the wrong branch for the last X PRs?>
<cole-h>
nixos-20.09 is the branch that results from a successful Hydra build+eval
<__red__>
ohcrap
<__red__>
I guess I need to rebase all of those
<__red__>
I have to repush all those cherry-picks don't I
<__red__>
I can't just change it in the UI
<__red__>
righht?
<samueldr>
you can change it in the UI
<__red__>
*phew*
<samueldr>
and "branching-off" you can branch-off of any parent
<__red__>
I better go review all the ones I've done recently
<samueldr>
to change the branch a PR targets, edit its title
<__red__>
thank you
lopsided98_ is now known as lopsided98
jonringer has quit [Ping timeout: 240 seconds]
maljub01 has quit [Ping timeout: 240 seconds]
<__red__>
Okay - so I may have bitten off more than I can chew here
<__red__>
I've opened a PR against staging-20.09
<__red__>
but looking at other logs - thjere are numerous packages that needed updates due to the glibc change
<__red__>
Should I also cherry-pick those into the same PR?
<__red__>
Should I do a separate PR for all of those ?
<gchristensen>
the glibc issue being security related?
<__red__>
yes it is
<gchristensen>
ouch
<__red__>
CVE-2020-6096 CVSSv3=8.1
<__red__>
otherwise I wouldn't touch it with a 10ft barge-pole
<gchristensen>
yeah include those in the same pr
<gchristensen>
thans
<hexa->
8.1 on armv7 :)
<gchristensen>
it seems the plasma ISO doesn't work well for hidpi screens, and changing the scale is ineffective since the scale takes effect at next boot
<gchristensen>
even when selecting the hidpi boot option
stoile has quit [Ping timeout: 256 seconds]
stoile has joined #nixos-dev
maljub01 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
<worldofpeace>
aargh, can't find the issue but I think the exact thing is on github
<worldofpeace>
gchristensen: so, overall the GNOME3 desktop is in a much more working state in nixpkgs and it actually has wayland support. Updates seem to have a lot less fallout, we don't have the difficult situation like qt has as much in the glib/gtk world I think
<gchristensen>
aye
<worldofpeace>
I think discussing on discourse is not really going to be a good idea
<gchristensen>
what do you think about recommending the gnome iso by default?
<worldofpeace>
this is a marketing, release managers, and the desktop maintainers discussion. It will likely get hijacked to not be productive.
<worldofpeace>
gchristensen: I would
<gchristensen>
yeah, I think that is a concern
<worldofpeace>
like, the PR for wayland support for plasma has been open for really long time now without progress. Upstream wayland session support came from gnome focused nix devs, overall if you look at the release notes there's a lot of enduser consideration there as well. It would be a good choice and I'd be happy to invest more fixes into stable
<worldofpeace>
--- gchristensen so that's my stance 😸
<worldofpeace>
thx, I'll crosspost my comments and ping Jan Tojnar
<worldofpeace>
on github seems to be the way to go
<ryantm>
We could make a Discourse section that only allows certain people to post.
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<worldofpeace>
True, but I think this particular topic isn't a big topic
<jtojnar>
yeah, GNOME is much more actively maintained at the moment
<jtojnar>
we have a team, whereas Plasma only has Thomas AFAICT
AlwaysLivid has quit [Read error: Connection reset by peer]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 265 seconds]
AlwaysLivid has joined #nixos-dev
FRidh has quit [Remote host closed the connection]
alp has quit [Ping timeout: 272 seconds]
stigo has joined #nixos-dev
<worldofpeace>
exactly. that really is enough motivation 🤣 Having a team makes things much much easier
FRidh has joined #nixos-dev
<domenkozar[m]>
evening
orivej has joined #nixos-dev
kalbasit has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
alp has joined #nixos-dev
<Mic92>
jtojnar: should the graphical installer maybe switch to that?
<Mic92>
Having a not well maintained KDE in the installer might look bad.
<Mic92>
Ah. This is what the discussion is about
<Mic92>
I am not using either of them but I tested both and our GNOME has less bugs than KDE.
<Taneb>
The other solution is get more people to help with KDE (this is not me volunteering)
<Mic92>
Taneb: not quite sure if that works. I feel more people want to work on KDE, more people would work on KDE>
jonringer has joined #nixos-dev
<Mic92>
The entry bar is quite low, one just need to make a pull request.
<michaelpj>
FWIW I use KDE in nixos and have considered helping with it, but the QT stuff seems to be very hard to get right, lots of PRs with people doing it wrong, reverting each other, etc. It's intimidating
<{^_^}>
#98141 (by jerith666, 8 weeks ago, closed): KDE "Switch User" menu item and lock screen button no longer present after systemd 246 update
<NinjaTrappeur>
basically, a systemd dirty hack has been introduced to deliver 20.09, we'd like either pull a proper KDE fix for that either warn upstream some KDE parts are broken with systemd 246
<Gaelan>
Nothing like discovering you accidentally gc'd a gcc build
<Gaelan>
(to be fair, at least it wasn't llvm)
<drakonis>
Mic92: its a bummer that kde is increasingly lagging behind the live releases now
<drakonis>
qt broke for like a month
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
JJJollyjim has joined #nixos-dev
<JJJollyjim>
:(
<drakonis>
theming broke that is
<drakonis>
it bothers me a little bit, sadly, because kde is really nice
alp has quit [Ping timeout: 272 seconds]
<drakonis>
hmm, i swapped to gnome and it didn't even get to gdm, bummer, so back to kde
<worldofpeace>
The infrastructure around KDE/QT actually seems to be pretty good. And I'm saying the after having packaged several DE's, this one is for sure difficult to have in nixos because of FHS'ism etc
<worldofpeace>
the issue is, there's downstream patches that are essential to it working properly in nixos
<worldofpeace>
Some of which I'm not sure can be upstreamed
<worldofpeace>
I think the modality for why gnome works sucessfully'ish, though there's still some things in the glib crowd pertaining to global state that's annoying, is trying to upstream patches? For pantheon I've submitted probably 50+ patches and they're pretty happy with accepting them, I just wish GNOME could be open to like... having something other than fedora in their CI
<worldofpeace>
A goal for sure is to have NixOS in CI, on GitLab not so easy atm... but github actions has the work from cachix and I hope pantheon can CI with NixOS on at least select projects. Stuff like this is really what will get situations to improve etc. I've read Thomas say that maybe the only optimal way to have Qt/Plasma is through a compatibility layer...
<drakonis>
how'd a compatibility layer work here?
<gchristensen>
it would be interesting to have major subsystems of nixos have people working to get nixos in those subsystem's CIs :)
<gchristensen>
ZFS was interested in doing that
<drakonis>
nixos being one of the frontrunner zfs consumers in linux space
<drakonis>
hard to see why they wouldnt do that
cole-h has joined #nixos-dev
<FRidh>
gchristensen: I think we need to have a good description then on how to setup such system, possibly even providing certain infra
<gchristensen>
yeao
<gchristensen>
that'd be good
<FRidh>
for example, with gh actions use the nix action, and then a remote builder from say nixbuild.net
<FRidh>
imo the issue with kde/qt is how it finds its dependencies. Its quite like Python in that sense, which means you need to organize that well or you will end up in trouble
alp has joined #nixos-dev
<worldofpeace>
FRidh: Absolutely that as well. propagatedBuildInputs from hell
<{^_^}>
#102613 (by FRidh, 1 week ago, open): WIP: Python: wrap and patch using `requiredPythonModules` instead of `propagatedBuildInputs`
<FRidh>
initially I dropped it partially, now I have most of it running entirely without propagatedBuildInputs. Instead, it uses some "custom" propagation.
<FRidh>
with qt I think propagation was dropped in many parts as well
<worldofpeace>
FRidh: Ah yeah, I saw that PR a bit ago. Wow, it seems you've done like the whole thing 😸 No more propagatedBuildInputs! Yeah, it was dropped in lots of parts, I think around the time of wrapQtAppsHook