16:59:57 <itchka_> #startmeeting
16:59:57 <chwido> Woof! Let's start the meeting. It's Wed Jan  4 16:59:57 2017 UTC. The chair is itchka_. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:59:57 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:57 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:59:57 <chwido> Have a good meeting, don't bark too much!
17:00:19 * jbj is here
17:00:21 <bero> woof!
17:00:56 <Son_Goku> meep
17:01:08 <itchka_> good we have some core here :)
17:02:09 <itchka_> I have couple of items from ben79 who can't be here today.
17:02:38 <itchka_> Lets start with this one.
17:02:42 <itchka_> 2. What is status of Long Term support for 2014? What will/won't be
17:02:43 <itchka_> updated going forward?
17:03:02 <itchka_> #item 1
17:03:28 <bero> I'd say only major bugfixes...
17:03:38 <itchka_> #topic What is status of Long Term support for 2014? What will/won't be updated going forward.
17:03:41 <bero> No point in updating applications for the "I don't want anything that isn't a decade old" crowd
17:04:40 <Son_Goku> I'd kill it with fire as soon as possible
17:04:45 <Son_Goku> 3.0 has been out long enough, imo
17:05:00 <Son_Goku> most of the software in 2014 is no longer maintained upstream
17:05:32 <itchka_> I'd agree but for the fact that Lx3.0 is not really stable and Lx3.1 is even worse.
17:06:16 <bero> I disagree about that
17:06:22 <itchka_> Before we reduce support there should be something stable to replace it.
17:06:30 <bero> there's tons of bugs fixed since 2014
17:08:32 <itchka_> Yes that's true but these days I'm coming across all sorts of issues with devel packages not installing. It's a right pain.
17:08:58 <Son_Goku> itchka_: but we literally can't maintain 2014
17:09:02 <bero> such as?
17:09:41 <itchka_> I'll generate thios mornings lot, hang on.
17:10:09 <bero> I use cooker, so not really sure about 3.x - but I haven't seen any problems with devel packages even when cooker and 3.x were pretty much identical
17:11:16 <Son_Goku> my only issues I've had with development in 3.x/cooker have been clang related
17:11:22 <Son_Goku> but ehh, I usually work them out
17:11:44 <itchka_> This is what happened when I tried to build Calamares locally on 3.1
17:11:47 <Son_Goku> occasionally, I have a few other glitches, but it's mostly fine
17:11:47 <itchka_> The following packages can't be installed because they depend on packages
17:11:49 <itchka_> that are older than the installed ones:
17:11:51 <itchka_> lib64elfutils-devel-0.166-1
17:11:52 <itchka_> lib64gl-devel-13.0.2-3
17:11:54 <itchka_> lib64qt5gui-devel-5.6.2-3
17:11:55 <itchka_> lib64Qt5WebEngine-devel-5.6.2-2
17:11:57 <itchka_> lib64qt5quick-devel-5.6.2-3
17:12:21 <itchka_> It's certainly much better with the modesetting driver
17:12:53 <itchka_> and I have tracked down the black screen bug
17:16:36 <itchka_> I've had other build efforts fail with similar issues and not always the same files.
17:16:54 <bero> Hmm, that looks weird, by any chance, do you have any i586 devel packages installed?
17:17:21 <itchka_> I may do for wine stuff..I'll check
17:19:35 <itchka_> rpm -qa | grep '.*i586.*'
17:19:37 <itchka_> libsigsegv2-2.10-14-omv2015.0.i586
17:19:38 <itchka_> m4-1.4.17-16.2-omv2015.0.i586
17:19:58 <itchka_> is that regex ok?
17:24:55 <itchka_> Dunno how they got there
17:24:56 <bero> hmm, libsigsegv2 i586 is ok, that's a library
17:25:07 <bero> but you certainly shouldn't have an i586 m4 on an x86_64 system
17:25:44 <bero> but that shouldn't affect what other stuff gets installed
17:25:55 <bero> might just be another symptom of the same root cause though
17:26:19 <itchka_> rebuild the rpm db?
17:26:36 <bero> no, that won't affect it at all
17:29:17 <itchka_> This install is only a week old the only major addition has been to set it up as an ABF slave
17:37:46 <itchka_> Well this kind of thing is the reason I'd like to see a 3.0 or 3.1 which is a bit more stable. It's truethere's been progress but there's already a move to push a 3.2 and my concern is that this kind of problem may get worse if we don't seek some sort of stability standard before releasing something else. After all that is why we have cooker so all the dosgy stuff doesn't impinge on users.
17:39:04 * ben79 Here now.
17:39:29 <ben79> Maybe bear in mind that users don't see things as developers do.
17:41:02 <ben79> Many users see 3.0  as less stable more problems than 2014.
17:42:00 <ben79> From users standpoint itchka's idea about a 'stability' standard would be an excellent idea.
17:42:13 <bero> who decides?
17:42:20 <bero> I'd say 3.0 is far more stable than 2014
17:42:26 <ben79> Also 'stability' standard seems to me would be good quality control.
17:42:30 <bero> because I know hundreds of bugs that have been fixed between those releases
17:42:48 <bero> obviously some others disagree
17:44:02 <ben79> Bero: For you it is,but when users see freezes, lockups, screen flashing, it is difficult to believe that 3.0 could be more stable than 2014.
17:44:29 <ben79> And I have seen recently all of that freezes, lockups, scren flashing.
17:44:41 * bero has yet to see a single freeze, lockup or screen flashing
17:44:52 <itchka_> I don't think it's quite like that. There have been hundreds of bugs fixed but the average Joe user doesn't see all that stuff because most of it is "under the hood". It's the really visible bugs that users get upset about and judge (misjudge) the stability by.
17:44:53 <bero> probably that's things only nvidia users can see?
17:45:13 <ben79> *Maybe* modesetting driver is a solution. Or disabling C-state in BIOS.
17:45:37 <ben79> Bero: No it isn't just nvidia, I don't have nvidia only intel.
17:46:13 <ben79> Bero: Then what about your system is different from what the rest of us are getting?
17:46:59 <bero> good question
17:47:16 <ben79> We've been going in a circle on this issue for a long time
17:47:35 <bero> maybe Qt 5.8 fixes it, I'm on cooker (and Qt 5.8 is the only difference between 3.01 and cooker that I can see being relevant)
17:47:46 <ben79> developers say it's great, users say I have problems, why is that?
17:47:53 <bero> or maybe it only happens on specific CPU or GPU types
17:48:07 <bero> My Intel GPUs are Skylake on the laptop and Broadwell-E on the desktop
17:48:21 <bero> on the other desktop I have a Radeon R9
17:48:42 <King_InuYasha> I've only seen plasma-shell lock up a couple of times
17:48:55 <bero> would be good to know if it's fixed for someone who does see the issue if they update to cooker
17:48:55 <King_InuYasha> but updates to Plasma 5.8 seem to have made them go away for me on all distributions I use
17:49:39 <bero> or maybe it's triggered by running an application I don't use
17:49:52 <ben79> Qt 5.6 here.
17:51:11 <itchka_> The modesetting driver fixes the issue for me it was really bad with nouveau. It locked up every few minutes
17:51:18 <ben79> Also I'm trying to report on behalf of users I interact with on Forum as well as my own experience.
17:51:37 <bero> possibly it only happens on low resolutions (I'm in 3840x2160 on my laptop and 2048x1536 on my desktops)
17:51:43 <bero> hard to tell...
17:51:51 <bero> the only thing I know for sure is I'm not seeing any of it
17:52:04 <bero> regardless of whether I use intel or modesetting
17:53:13 <King_InuYasha> it seems to happen more often if I use 3 x 1080p screens
17:53:21 <King_InuYasha> two screens or fewer doesn't trigger it
17:53:47 <bero> that would explain why I'm not seeing it, I don't have any multi-screen setups
17:53:57 <bero> but I think some people are seeing it with 1 or 2
17:54:00 <itchka_> I think the point here is that the plasma lockup and the black screen problem with some installs have given a perception that Lx3.0 is unstable which to be fair it is not.
17:54:09 <itchka_> I have two screens
17:54:11 <ben79> I don't have multi screen either.
17:54:38 <King_InuYasha> I suspect that my issues on my Fedora workstation went away because of Qt 5.7.x updates
17:54:50 <King_InuYasha> on Mageia, I'm not sure what fixed things
17:55:03 <King_InuYasha> I do not experience the issue on omdv, as I don't have multiscreen omdv systems
17:55:57 <ben79> Monday evening I did 2 things, switch to modesetting driver on 1 system AND disabled C-states in BIOS,
17:57:26 <ben79> since I've seen nothing so *maybe* one or both of those are a factor or Plasma 5.8 or Qt newer than 5.6 or all, I don't know.
17:58:09 <ben79> or Qt newer than 5.6: well not that for me yet as I'm still on Qt 5.6...
17:58:24 <King_InuYasha> Mageia Cauldron is on Qt 5.6 as well
17:58:34 <King_InuYasha> so... *shrugs*
17:58:57 <bero> maybe they've backported a patch or something
17:59:05 <bero> I'm on 5.8-rc here
17:59:06 <itchka_> However one looks at it for nouveau at least the modesetting driver not only fixes it for me but also gives better FPS
17:59:24 <ben79> I certainly don't know but I have an excuse, I'm a computer dumb ass compared to everyone here.
17:59:27 <bero> probably we should backport 5.8 to 3.x as soon as 5.8 final is released and then see if the problem goes away for those seeing it
18:00:06 <ben79> What I think should be addressed are 2 things:
18:00:22 <ben79> 1. Should we have a stability standard?
18:00:52 <ben79> 2. Should there be more awareness that developers and users see things differently.
18:01:47 <ben79> 2a. While reminding my self that my view is colored by forum interaction, forums do get malcontents, and those who shoot themselves in the foot.
18:02:36 <itchka_> There's certainly no shortage of that stuff!!
18:02:59 <bero> 1. -- yes in general but it's hard to do given obviously not everyone even runs into the same problems
18:03:16 <bero> it's virtually impossible to debug those lockups for me given I can't reproduce them
18:03:21 <ben79> and I try to be positive through it but do I ever want to unload sometines!
18:03:42 <bero> and we can't guarantee every piece of hardware will always be supported
18:04:57 <King_InuYasha> I think it's important to also recognize we have limits when it comes to figuring this stuff out
18:04:59 <ben79> bero: I think debuging lockups has been difficult everywhere.
18:05:10 <King_InuYasha> there's obviously an upstream problem, we just don't know where
18:05:52 <ben79> And again there is the difference so many users see 3.0 lockups, ect. 2014 none.
18:06:00 <ben79> I see the same
18:06:14 <King_InuYasha> the thing is, 2014 was KDE 4
18:06:24 <King_InuYasha> and prior to Plasma 5.8, we didn't have this problem in Plasma 5
18:06:34 <King_InuYasha> I know this because I've been running Plasma 5 since 5.3
18:07:27 <ben79> Oh I had it prior to 5.8 so have a lot of others, it's been reported since 3.0 was first in development.
18:07:52 * bero suspects it's related to Qt 5.x making way more use of OpenGL than 4.x
18:08:03 <bero> so bugs in graphics drivers are more likely to be exposed
18:08:39 <bero> there's a good chance the problem has been around forever, and just wasn't triggered because nothing made use of the driver features that can make things go bad
18:09:00 <itchka_> Perhaps we should extend _TPG's email about setting up the modesetting driver to the forums or even provide a short script to do the job. We could make bit of a thinh of it in the blog.
18:09:09 <ben79> And lockups, ect are reported at kde.org and opensuse as well
18:09:12 <King_InuYasha> I would tend to agree
18:09:23 <King_InuYasha> itchka_: modesetting doesn't fix it on my multiscreen systems
18:09:28 <King_InuYasha> it makes it worse, actually
18:09:35 <HisShadow> what exactly is locking up? kde plasma?
18:09:44 <King_InuYasha> plasma-shell and chrome/chromium
18:09:49 <christann> Hi all,
18:09:51 <itchka_> Really? How bizarre
18:10:03 <King_InuYasha> only fix is switching VT and switching back
18:10:08 <King_InuYasha> it reloads state and continues to work
18:10:15 <ben79> I *think* modestting video drivers should be considered 'testing' but it needs a good test with as many users as possible
18:10:44 <christann> Modesetting driver is working well for me.
18:11:04 <ben79> HisShadow: for users plasma desktop locking up is what we see, what it really is I don't know
18:11:33 <HisShadow> heh, it's 2017 and KDE 5 and there are still problems with plasma
18:12:07 <ben79> Yeah, and there was just a post about it on openSUSE forum a few days ago...
18:12:22 <King_InuYasha> it's basically everywhere
18:12:45 <King_InuYasha> like bero suggested, I suspect that it's because now Qt and KF5 defaults to using GLX way more for even basic things
18:13:00 <King_InuYasha> Plasma stresses the graphics stack a bit more than what GNOME does
18:13:26 <ben79> and Plasma5 does so more than KDE4
18:13:44 <ben79> apparantly a good bit more
18:14:12 <King_InuYasha> well, Plasma also lacks the intelligent fallback mechanism that GNOME has
18:14:22 <itchka_> Maybe off topic but where is Wayland in all this?
18:14:23 <King_InuYasha> where it will, at the first sight of issues, automatically disable most OGL stuff
18:15:14 <bero> wayland uses mesa as well
18:15:25 <bero> so chances are it will behave a lot like X with the modesetting drive
18:15:26 <bero> r
18:16:39 <King_InuYasha> it behaves EXACTLY like Xorg with modesetting
18:16:44 <King_InuYasha> because it uses the same codepath
18:17:21 <itchka_> King_InuYasha: So for you that would be broken too.
18:17:29 <King_InuYasha> it is broken for me
18:17:49 <King_InuYasha> though it also suffers from generally being in bad shape right now in Plasma
18:18:48 <itchka_> So the only possible releif is to backport Plasma 5.8
18:19:00 <itchka_> relief
18:19:40 <christann> What problems will plasma 5.8 cause?
18:20:22 <itchka_> Theroetically less than 5.6 ? :)
18:20:41 <bero> probably none... cooker is on 5.8.5 and I'm not seeing any problems there
18:20:51 <bero> but then again I didn't see them either when we were on 5.6
18:21:02 <King_InuYasha> this is honestly what I suspect fixed the issue for me in Mageia
18:21:35 <christann> I see that I am running 5.8.5 and all is okay here. No freezes recently.
18:22:32 <bero> So I'd suggest to wait for qt 5.8 final (should be released this month) and then backport all the Qt/KDE related packages
18:25:07 <itchka_> There's talk of Lx3.2 would it not be better in there.
18:28:44 <King_InuYasha> things are getting merged from cooker/master to 3.0 branch anyway
18:29:01 <King_InuYasha> it makes sense to build in cooker/master and then merge back into 3.0
18:30:44 <itchka_> I'm thinking more of users re-installing. The whole of KDE is a pretty big update to do after installtion.
18:31:20 <itchka_> A working iso is a cleaner way forward.
18:33:51 <itchka_> Either way are we decided that Plasma 5.8 holds the best hope for a complete fix.
18:35:17 <King_InuYasha> yes
18:35:29 <King_InuYasha> even leaving with Qt 5.6, Plasma 5.8 holds the best chance
18:35:52 <itchka_> I'll file an action then.
18:36:06 <bero> IMO it wouldn't even be a bad idea to build a 3.2 release from the cooker tree
18:36:43 <bero> lots of progress with not all that much risky stuff right now
18:38:37 <itchka_> what was all that stuff about musl :)
18:40:20 <bero> we haven't done any of that yet
18:40:23 <bero> just talked about it
18:41:02 <bero> so before starting to experiment with that would actually be a good time to branch off another release tree
18:41:30 <itchka_> Why not do a cooker iso for QA to play with if it looks ok then wait for Plasma 5.8 and then do it as 3.2.
18:41:51 <bero> sounds like a good plan IMO
18:42:59 <ben79> And what about:
18:43:06 <ben79> 2. What is status of Long Term support for 2014? What will/won't be
18:43:06 <ben79> updated going forward?
18:44:35 <King_InuYasha> no LTS for 2014
18:44:47 <King_InuYasha> I'd want to cut it off at the knees sooner rather than later
18:45:08 <itchka_> We come back unfortunately to the same problem we need a to offer a release that is "perceived" as stable by users before we can say 2014 will receive minimal support.
18:45:30 <King_InuYasha> the fundamental problem with 2014 is that it's not maintainable
18:45:39 <ben79> If we drop 2014 right now it's likely we will lose quite a few users
18:46:24 <ben79> Why isn't 2014 maintainable, I WILL be asked about this on the forum
18:46:53 <ben79> So factual answers would be extremely helpful
18:47:39 <bero> 2014 is essentially a collection of software that has been abandoned upstream
18:47:44 <bero> (e.g. anything KDE 4.x)
18:48:16 <bero> so unless we move it to plasma 5 (in which case people might as well move to 3.x), upstream will not release updates anymore
18:48:28 <King_InuYasha> and much of the stack in 2014 is completely different
18:48:40 <King_InuYasha> from what we have in cooker and 3.x
18:48:40 <ben79> What about other stuff, for instance if vbox isn't kept updated it makes it difficult for 2014ers to try 3.x
18:48:41 <bero> so either it remains on abandoned versions or we have to fix everything ourselves
18:48:54 * King_InuYasha shrugs
18:49:01 <King_InuYasha> the whole thing is a giant catch-22 then, isn't it?
18:49:16 <King_InuYasha> at some point, you have to throw your hands in the air and call it done
18:49:37 <bero> the stack is rather different (different compilers and all), so backporting from cooker or 3.x to 2014.x is much more work than backporting from cooker to 3.x
18:49:54 <ben79> I don't know but it would be worth finding out if there are any distros that still maintain a KDE4 branch, don't think suse does
18:50:15 <King_InuYasha> we don't have the same level of extreme difference in Mageia 5 vs Mageia Cauldron/6, but it still has the same problem
18:50:30 <King_InuYasha> CentOS 7 is the only living branch of KDE 4 I know of
18:50:37 <King_InuYasha> and Mageia 5, I guess
18:50:42 <ben79> FWIW: I get what Y'all are saying I'm just trying to be prepared for the whiners
18:50:53 <King_InuYasha> pretty much everyone else has migrated to Plasma 5
18:51:02 <bero> Debian Stable maybe
18:51:20 <King_InuYasha> I said "living" remember?
18:51:27 <King_InuYasha> Debian doesn't count as that :P
18:51:34 <bero> well, "on life support" ;)
18:51:39 <ben79> good ole debian stable... yesteryears packages top to bottom... but rock solid!
18:51:43 <King_InuYasha> ehhh
18:51:46 <King_InuYasha> no
18:51:58 <bero> except it won't even install on any hardware that isn't decades old
18:52:04 <King_InuYasha> ^
18:52:29 <bero> If I want that type of "stable", might as well install DOS
18:53:00 <bero> Or just use a C64
18:53:15 <ben79> Apple II
18:53:21 <King_InuYasha> Apple Lisa
18:53:43 <itchka_> Mandrake 9.1
18:53:56 <HisShadow> I used to have Mandrake 9.0 CD somewhere
18:54:04 <HisShadow> complete with 2.6.9 kernel and gcc 3 something
18:54:05 <King_InuYasha> anyway, the point is, the architecture is fundamentally different between omdv 2014 and omdv 3.x
18:54:28 <King_InuYasha> backporting across that much of a difference can be quite problematic
18:55:01 <King_InuYasha> between the compiler switch, pkg-config->pkgconf, and KDE4->KDE5, and switch of default Python, it's much harder
18:55:12 <bero> I think I still have that stack of 86 floppies from which I first installed Slackware back in the mid-1990s
18:55:13 <ben79> So even doing same version of VirtualBox for 2014 is different form doing it for 3.0?
18:55:22 <King_InuYasha> yes
18:55:44 <King_InuYasha> because VirtualBox requires kernel integration, is a compiled program, and depends on libraries
18:55:58 <bero> yes -- it's possible, but a lot more work because the build scripts and all have to deal with old versions of stuff, different compilers etc
18:56:02 <itchka_> bero: You must have the patience of a saint!!!
18:56:03 <ben79> So if users ask I can tell them 2014 is in bug fix only status for now
18:56:18 <ben79> any idea how much longer until it's dropped?
18:56:22 <bero> VirtualBox also contains kernel modules, so that makes it even more tricky than most other things
18:56:45 <King_InuYasha> well, I'd probably give a couple of months of support, since we've not announced anything before
18:56:47 <itchka_> and security I would think.
18:56:56 <King_InuYasha> but I'd kill it by the end of Q1'17
18:57:03 <bero> I'd like to drop it ASAP, but "P" of course means "as soon as people won't scream too loudly"
18:57:49 <ben79> Then we need to start a process including communicating this to the community, get ready to move forward or:
18:57:51 <King_InuYasha> for example, in Mageia, we drop support for the preceding release as soon as the current release is 3 months old
18:57:56 <ben79> no updates ever
18:58:38 <ben79> Maybe we should put 3 months on it as soon as who ever needs to agrees?
18:59:08 <King_InuYasha> I'd suggest adopting the same policy
18:59:19 <bero> good addition to make people stop whining: "Alternatively, step up and maintain it - this is a volunteer project after all"
18:59:20 <King_InuYasha> since successive releases in omdv tend to be drastically different anyway
18:59:22 <ben79> And make an official announcement, with a ceramony with the Grand Poohbah?
18:59:54 <King_InuYasha> we have a Grand Poohbah?
19:00:02 <ben79> For 2014 step up and maintain it an appropriate response IMHO
19:00:04 <itchka_> If we could sort out this rolling release business we could move it quietly to legacy as justy a part of the scheme of things.
19:00:15 * King_InuYasha shrugs
19:00:15 <HisShadow> bero: nah, judging from experience that addition never works
19:00:18 <King_InuYasha> rolling is hard
19:00:48 <bero> HisShadow: It "works" as in "nobody screems too loudly because that could be seen as stepping up, and nobody wants to do that" ;)
19:01:35 <HisShadow> then you'll have to put it somewhere so that everyone sees it all the time to reminds them
19:08:47 * ben79 Debian no longer distributes KDE binaries
19:08:54 * ben79 https://www.debian.org/News/1998/19981008.en.html
19:10:00 <King_InuYasha> KDE has been distributed by Debian since KDE 3
19:14:16 <ben79> Hm, I guess they do:
19:14:21 <ben79> https://pkg-kde.alioth.debian.org/
19:14:50 <itchka_> I feel we should wait until we have assessed the state of Plasma 5.8 if it's good we can say it's a stable replacement which right now we can't really say that for anything we are shipping.
19:18:03 <christann> Plasma 5.8.5 is in the 3.0 testing repo now.
19:19:03 <itchka_> is it complete?
19:20:55 <christann> task-plasma is at 5.8.5.
19:22:02 <itchka_> I'll try it then. I've been debugging some basic 3.1 stuff on a new install and haven't updated in a week.
19:24:06 <itchka_> Guys I have to go and feed the troops. I'll add you as chair bero and you can close things down if you finish before I get back.
19:24:15 <itchka_> #chair bero
19:24:15 <chwido> Current chairs: bero itchka_
19:37:33 <King_InuYasha> is there anything else to talk about?
19:44:49 <ben79> Prolly not today
19:45:00 <ben79> Could bero close meeting?
19:54:08 <bero> #endmeeting