15:00:37 #startmeeting kde-sig 15:00:37 Meeting started Tue Oct 6 15:00:37 2015 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:40 #meetingname kde-sig 15:00:40 The meeting name has been set to 'kde-sig' 15:00:43 #topic roll call 15:00:51 hi all, friendly kde-sig meeting here, who's present today? 15:02:39 Present. 15:02:46 may be a short meeting :) 15:03:31 Well, looks like Firefox is affected by 2 critical bugs. 15:03:38 hola 15:03:43 So that's technical grounds for reconsidering. 15:03:56 1. This one is back: 15:04:01 .bug 1226465 15:04:02 Kevin_Kofler: Bug 1226465 GTK applications (sometimes?) do not scroll correctly, lacks focus? - https://bugzilla.redhat.com/1226465 15:04:12 Kevin_Kofler: only on f22 15:04:33 because I dropped the workaround 15:04:41 (trusting that it wasn't needed anymore) 15:04:55 Without the workaround, scrolling is broken in other ways. 15:05:03 but looks like that was wrong 15:05:12 we can certainly put the workaround back 15:05:13 And 2., for the hangs: 15:05:15 here 15:05:15 https://bugzilla.redhat.com/show_bug.cgi?id=1264486#c12 15:05:22 "Notice that most of my issues are either with Firefox or Konsole." 15:05:58 (hi, sorry) 15:06:11 #info rdieter dvratil Kevin_Kofler heliocastro tosky present 15:06:14 #chair dvratil Kevin_Kofler heliocastro tosky 15:06:14 Current chairs: Kevin_Kofler dvratil heliocastro rdieter tosky 15:06:24 pino said he'd be a few minutes late 15:06:30 #topic agenda 15:06:43 Kevin_Kofler mentioned firefox 15:06:48 anything else to discuss today? 15:07:55 I guess I can give a brief update on plasma-5.4.2 status 15:08:00 Hmm, I had no idea that firefox scroll thing would possibly be KDE related. 15:08:17 tibbs|w: well, strictly speaking, it's a gtk3 issue 15:08:40 General GTK+ 3 scrolling FUBAR. 15:08:43 but kwin exposes it 15:08:52 There's a workaround that then exposes other regressions. 15:09:12 And there was a fix in upstream gtk3 that got reverted because of, again, you guessed it, regressions. 15:09:13 (collective aargh.) 15:09:43 #topic firefox/gtk3 15:10:12 ok, so looks like my dropping gtk3 workaround was premature, I'll put it back asap 15:10:40 This shows why doing such a major change to the spin after Feature Freeze was a very very bad idea. 15:11:03 Sure, Firefox is used on other spins. But the other spins don't expose the issues we are having with GTK+ on KDE. 15:11:18 (which are becoming more and more over time, to the point where eliminating the last GTK+ apps ought to be a priority) 15:11:28 only if the bug were blocker-worthy, which it isn't. 15:11:34 (We need to be prepared for the day where GTK+ becomes entirely unusable. It must be close.) 15:12:51 User feedback for the change is also ~90% negative (see the mailing list). 15:13:03 So it's time for a revert, urgently. (Final Freeze in 1 week!) 15:13:26 we discussed this last meeting, I thought we agreed you'd make a proposal onlist 15:13:33 am I mis-remembering? 15:14:18 Why on the mailing list? It's a slow medium and time is short! 15:14:20 if you use that percentage from the list as feedback, using the same process we should conclude that the fedora community is a flaming place, so I disagree on that percentage 15:14:49 I was letting the statistic slide, since I figured it was obvious, but, tosky +1 15:15:18 Kevin_Kofler: fine, make a proposal, and we can vote (again), and move on 15:15:27 it's just for the future readers of the logs 15:16:06 (but really, this is getting silly, imo) 15:16:17 Proposal: The late F23 default KDE browser change will be reverted for Final (i.e. ASAP!) due to bugs and negative user feedback. 15:16:22 +1 (obviously) 15:16:26 -1 15:16:34 -1 15:16:34 zodbot find #openstack-stackalytics 15:16:41 Re bugs, see also https://bugzilla.redhat.com/show_bug.cgi?id=1264486#c12 15:17:00 If Firefox is triggering this bug, it likely means that it's managing to crash KWin or Plasma! 15:17:04 -1 15:17:25 (Yes, it's possible for a GTK+ app to crash KWin, I've seen it happen with GIMP.) 15:17:38 pretty sure we don't have quorum, so you'll likely have to take it onlist regardless 15:17:48 (though only with my Quarticurve window decoration, which is why I'm not fingerpointing GIMP yet) 15:17:50 the bug talks also about konsole 15:18:06 tosky: Yeah, but removing Konsole is not an option. :-) Removing Firefox is! 15:18:09 and it says about "issues with LibreOffice 5 due to KDE3 libs being on my system" 15:18:35 And both LibreOffice and kdelibs3 are already NOT on the spin. 15:18:39 there's a lot of unsubstantiated/unverified claims in that bug report, cannot be taken seriously (yet) 15:19:07 heliocastro: for completeness, care to vote on the proposal for the record? 15:19:34 -1 15:19:55 #info proposal is (+1,-4) so far 15:20:02 Same as i did last times anyway 15:20:12 #info Proposal: The late F23 default KDE browser change will be reverted for Final (i.e. ASAP!) due to bugs and negative user feedback. (Kevin_Kofler) 15:20:19 heliocastro: thx 15:21:18 So now, not only are we ignoring our users, but also critical bugs? 15:21:19 proposal rejected (so far), but Kevin_Kofler can take it onlist to find +4 more votes, if he so chooses 15:21:44 This is getting more and more ridiculous! 15:21:55 I'm totally fed up of this Firefox tyranny! 15:21:58 #action rdieter will re-instate gtk3 scrolling workaround in kde-settings asap 15:22:21 All Fedora rules are getting bent for that crappy browser that "our users want", except they don't! 15:22:44 rdieter: That will introduce the other bug. 15:23:03 (the one because of which you removed the workaround) 15:23:12 There is no fix other than removing gtk3. 15:23:20 Kevin_Kofler: I'm not privy to the details of "the other bug", would you argue it's worse than the original symptom(s)? 15:23:33 in short, which is least bad? 15:23:42 I don't know which is worse. 15:23:48 I just know that both settings are broken. 15:23:54 then let's go with the devil we know 15:24:10 So gtk3 apps need to go away, especially Firefox that heavily relies on scrolling! 15:24:27 yes, thanks, I think your position on the matter is quite clear 15:24:40 moving on... 15:24:49 #topic status updates 15:24:59 It's not a POSITION, it's a FACT! 15:25:06 initial plasma-5.4.2 builds are now in -testing 15:25:21 One that you refuse to acknowledge because you'd rather ship an unusable final release than admit you made a mistake! 15:25:33 found and fixed a recently-introduced regression in startkde (it failed to source environment variables) 15:25:50 rdieter: thanks for doing the update! 15:25:53 Fo th record, the other bug: 15:25:56 .bug 1226465 15:25:57 Kevin_Kofler: Bug 1226465 GTK applications (sometimes?) do not scroll correctly, lacks focus? - https://bugzilla.redhat.com/1226465 15:26:03 *For the record 15:26:47 Ah, no, that's the original bug, the one the workaround fixes. 15:27:23 There's one bug for both issues, what a mess. 15:27:23 the startkde bug is what (I think) caused some users to report that installed-systems didn't use fedora wallpaper 15:27:59 it's because updated systems no longer used configs under /usr/share/kde-settings, due to env vars XDG_CONFIG_DIRS And XDG_DATA_DIRS not getting set properly in plasma session 15:28:05 The startkde bug also only happened because my change to use our own startkde.cmake was undone. 15:28:07 * jgrulich is here and totally forgot about the meeting 15:28:18 #info jgrulich present 15:28:21 hi 15:28:24 #chair jgrulich 15:28:24 Current chairs: Kevin_Kofler dvratil heliocastro jgrulich rdieter tosky 15:28:35 So now we're again prey to all these startkde regressions, which is why I had decided to ship a custom startkde.cmake to begin with. 15:28:41 We've had enough of those during KDE 4 packaging. 15:29:21 in fairness, but the time you'd used a static startkde, kde4 was quite mature, and the odds of startkde changing (for new features) any were slim at that point 15:29:25 Wasn't there another startkde regression recently as well? Even if not, the first major update after we switched back to a patch and wham! Regression! 15:29:28 s/but the/by the/ 15:30:07 I'm fed up of all the useless garbage upstream is putting in that script. 15:30:19 Kevin_Kofler: no other recent regressions that I'm aware of (not since switching to patched startkde anyway) 15:30:27 See also the XDG_* environment variable munging that does not belong there either. 15:30:34 the startkde.patch has only 2 commits. the initial creation, and my recent fix 15:31:00 * heliocastro want to push the modular startkde just after f23, too soon and too dangerous to do that in this cycle 15:31:00 (even though that one is harmless, as long as XDG_* gets set correctly anyway) 15:31:23 heliocastro: Sorry, but I no longer think modularizing it is going to solve the issues. 15:31:25 heliocastro: +1, thanks again for working on that 15:31:27 heliocastro: how is it going the upstream discussion? (I don't follow plasma-devel@ too much) 15:31:34 The script does too much and changes too much. 15:31:44 It should just start Plasma, nothing more. 15:31:52 tosky: We stopped in the need for two startkdes, one for wayland other for x11 15:32:07 And once we have a working script, it should stay that way and NOT pick up upstream regressions. 15:32:14 heliocastro: I think Martin had a proposal for some common parts and a separate one 15:32:26 tosky: Exactly, but there's a ctach 15:32:29 catch 15:32:40 The script order need be different 15:32:52 So the regular number shell proposal would not be direct 15:33:08 And of course improvements for the real world (X11) get blocked on support for that Wayland crackpot dream. 15:33:19 What could work is something similar like old sysv 15:33:27 we have a common repository of scripts 15:33:35 and two directories for each boot 15:33:36 heliocastro: yes, right, I was going to say it 15:33:49 And we do symlinking in the order we need 15:33:51 heliocastro: what did it stop from creating a set of symlinks? 15:33:55 So after systemd reinventing the world, now KDE reinventing systemd? 15:34:11 tosky: Stop reading my ming 15:34:14 mind !! 15:34:28 This is another thing 15:34:30 heliocastro: well, that or a set of wrapper functions for the common code 15:35:11 I would like to use systemd for that as well, but then, there's bsd and other linuxes that not use systemd 15:35:48 tosky: The idea is avoid this amount of "if wayland" do that, or to the other 15:35:52 , I'd love to be able to use proper session units too 15:36:01 heliocastro: no, I'm not saying that 15:36:35 heliocastro: no symlinks, but a set of common functions, and two scripts which just calls the functions in the right order 15:36:40 is symlinks with no symlinks 15:36:40 IMHO, there should just be a completely separate script for Wayland (and both should be much smaller, all the crap that we rip out in Fedora needs to go away). 15:36:45 sorry, I was in the server room working on $STUFF 15:37:22 tosky: Yes, i thought that too, this is indeed more simple and allow distros to have their own set 15:37:24 #info danofsatx present 15:37:26 danofsatx: hi 15:37:49 greetings 15:38:04 Always diffucult to make Trojans and Greeks ( and Kevin ) pleased anyway 15:38:15 danofsatx: fwiw Kevin_Kofler offered a proposal earlier, Proposal: The late F23 default KDE browser change will be reverted for Final (i.e. ASAP!) due to bugs and negative user feedback. 15:38:34 danofsatx: care to offer a vote? currently we're at (+1,-4) 15:38:49 let me go back and read... 15:38:50 heliocastro: did you discuss about those two proposal on the list/IRC, or are they just at the planning state? 15:38:51 * pino|work was here btw... 15:39:14 #info pino|work present 15:39:16 On the IRC and one the mail list 15:39:17 hi 15:39:22 rdieter: -1 for reverting that change 15:39:23 #chair pino|work danofsatx 15:39:23 Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich pino|work rdieter tosky 15:39:28 But stalled last month 15:39:46 jgrulich: thx 15:40:03 My fault, but $LIFE had a crazy last month 15:40:06 pino|work: ^ 15:40:19 I also find it sad that this needs to be filed as a new proposal and require a new majority to pass. There needs to be a policy for reopening votes (for some reasonable time frame – in this case, until the F23 release). The status quo is what we shipped in previous stable releases, so this should be the fallback if there is no consensus, not the Branched or Rawhide status quo. 15:40:21 * pino|work notes -1 on reverting the change of firefox as default 15:40:55 ok, at -6, looks like it formally fails now 15:40:56 But then again, I count -6 to my proposal, so it wouldn't matter anyway. :-( 15:41:19 Thanks for caring about our users and fixing critical regressions caused by your late changes! 15:41:36 We will be shipping a browser with broken scrolling! 15:41:41 This is totally unusable. 15:42:47 oh, and update since last meeting, finally poked ximion and we got appstream fixed (for muon-discover) 15:43:25 naughty hughsie for adding stuff to appstream-data that's not in documented specs, which made appstream validation fail 15:43:51 Typical GNOME crap, everything gets polluted with proprietary GNOME extensions. 15:43:56 M$-style embrace&extend. 15:44:12 * Kevin_Kofler is in a really bad mood today, as you might have noticed. ;-) 15:44:44 but ximion made appstream not completely bail out on validation failures (which is definitely better behavior) 15:45:55 FWIW, I'm +1 to the proposal, as I was -1 to switching to FF in the first place. 15:46:05 If KDE adds something non-standard, we immediately get some GLib-based validator yelling at us and failing our build. If GNOME adds something non-standard, all the OTHER software has to bend over backwards to support the crap. 15:46:25 I also backported 2 screen-related qt5-qtbase commits to our packaging 15:46:46 should theoretically help cases of monitors connecting/disconnecting 15:46:48 what are you yelling about ? 15:46:51 * mclasen__ just mildly curious 15:47:07 mclasen__: Nonstandard stuff in AppStream XML files. 15:47:24 rdieter: Do you have a bug ID or discussion or anything where this is documented? 15:47:47 Kevin_Kofler: in fairness, it was also ximion who didn't think documenting webapps was worth it (iirc) 15:47:50 It was something about some enumerated key being set to a value that is not in the AppStream spec. 15:48:42 mclasen__: not worth worrying about imo 15:48:48 * mclasen__ recommends talking to hughsie about it and getting the spec or the implementation fixed 15:49:40 good news, is that stuff is fixed and just-works again, as intended 15:50:42 not directly kde-related, but xdg-utils got another upstream maintainer (from debian?), and has done a great job and made new releases (better and faster than I ever was) 15:51:31 Good. 15:53:11 any one else have anything note-worthy to report from this past week? 15:53:47 danofsatx: thx for vote 15:53:52 dolphin doesn't work in a dnf upgrade to 23 15:53:52 rdieter: Yes: 15:54:05 #info proposal at (+2,-6) 15:54:05 I still need to verify this, though 15:54:12 Calamares 1.1.3 is now in Fedora (stable), upstream released 1.1.4.2 since, I'll be updating it shortly. 15:54:34 (Time to replace Anaconda!) 15:55:07 ok, we can definitely add it as an install option initially 15:55:19 I assume that's doable? 15:56:08 Should be doable, yes, though I'm not sure shipping both would be all that great from a support point of view. 15:56:14 (both on the same spin) 15:56:26 I'm just saying let's treat it as a tech-preview for now, and see how well it works 15:56:31 I'd rather have ONLY Calamares on the KDE spin for F24. 15:56:47 Kick out all the GTK+ stuff! 15:57:14 By the way, even GTK+-based distributions are switching from Anaconda to Calamares. 15:57:29 and from a support pov, we need someone to help test this... qa tests anaconda extensively, who and how is calamares going to be tested? 15:57:40 (e.g. Rogentos/Kogaion, a Romanian GNOME/MATE/Xfce distro) 15:58:00 so dropping anaconda is premature, at best. Let's try it and see 15:58:16 (pretty known distro...) 15:58:56 any objections to adding calamares to f24 kde spin as a tech-preview/experimental-installer ? 15:59:11 (leaving anaconda untouched for now) 15:59:34 pino|work: There are bigger ones, too. 16:00:47 Tanglu, Sabayon, Manjaro, KaOS etc. already using it, PCLinuxOS and OpenMandriva about to switch. 16:01:05 (I think it's no objections for adding as tech-preview/experimental installer) 16:01:11 distros with lots of users, indeed 16:01:25 how does it work with an alternative installers? Different entry at boot time? 16:01:44 Both on the desktop. 16:01:56 tosky__: you'd click/run something different than the usual 'install fedora' anconda link on live image 16:01:58 But I guess that only works if we label BOTH of them with something saying what the installer actually is. 16:02:26 Right now you'd have "Install to hard drive" and "Install to hard disk drive" (and that's only because I added "disk" so that I have SOME way to figure out :-) ). 16:02:55 I could ship Calamares as "Calamares", but if you have an icon that says "Install to hard drive" and one that says "Calamares", which one would you click if you want to install? 16:03:07 Kevin_Kofler: , calamares should be clearly labeled differently, something like: Calamares experimental installer (or use 'alternative' rather than experimental) 16:03:21 (This is why I'm not happy with shipping both.) 16:03:25 "Install to hard drive (using Calamares)" 16:03:52 When you log into GNOME for the first time, you are greeted with a pop-up window that, for lack of a better term, introduces you to GNOME. 16:04:08 any label that includes "Calamares" and "alternative/experiemental" (or equivalent) works for me 16:04:14 Could we do something along the same lines for liveuser that would explain the differences between the two? 16:04:32 and maybe even use it as an advertisement platform listing all the new features of F23? 16:04:42 danofsatx: certainly, iirc, upstream was already working on such a thing, but I'm not privy to details 16:04:44 It's using Anaconda on Plasma that is the experiment, given the current state of gtk3. 16:04:53 Calamares just works 16:04:58 (or was it *us*, ltinkl?) 16:05:28 Kevin_Kofler: that's the terms for inclusion for now, I would object otherwise 16:05:33 danofsatx: I think we're really talking about F24 here, not F23. :-) 16:06:03 that gnome welcome screen stuff is quite nice 16:06:07 I'm all for Calamares, but it's way too late on F23. I can't at the same time complain about Firefox being added late and then add a new installer weeks later. ;-) 16:06:31 whoops, wrong one ;) 16:06:36 you cannot really compare a browser with a whole installer 16:06:47 , I was assuming we're talking on context of f24 here too 16:07:00 Of course note, the browser is used all the time, the installer only once! 16:07:05 So the browser is the much larger change. 16:07:07 [10:58] any objections to adding calamares to f24 kde spin as a tech-preview/experimental-installer ? 16:07:09 ^^ 16:07:30 * danofsatx hasn't had nearly enough coffee yet. Please pardon the misdirection. 16:07:32 Still, I think it's too late to consider Calamares for F23, and I'm the one that proposes Calamares to begin with. :-) 16:07:51 no objection from me. 16:08:23 Kevin_Kofler: ok, looks like you have our blessing to add it somewhere 16:08:29 anything else for today? 16:08:35 Well, I have to object to the plan because I don't see why it needs to have tech preview status and why that Anaconda bloatware still needs to be on the spin. 16:08:38 (looks like we're already slightly over time) 16:08:51 We have 6 months to fix the blockers. 16:09:05 So all the efforts should be spent on that (e.g. adding "secure boot" / shim support). 16:09:13 Not on more gtk3 duct tape. 16:09:27 Kevin_Kofler: feel free to make an alternative proposal then (full disclosure, I will -1) 16:09:31 I'm not sure gtk3 will even still work under Plasma AT ALL by the time of F24 GA. 16:09:42 It keeps getting worse. 16:10:44 but I'm against any plan that removes anaconda without first thoroughly testing calamares 16:11:23 We have 6 months for that testing (and adding missing features). 16:11:45 then testing should go great, and then, and *only* then, we can consider more 16:11:56 * mclasen__ listens and would like to know what is getting worse 16:11:57 I could also use a list of things that MUST be added. For me, Calamares works right now, but some people think "secure boot" is a requirement, some think LUKS is, etc. 16:12:22 yes, LUKS would be a must 16:12:23 LUKS should be coming in 2.0.0 that will be the next release (current master is headed towards 2.0.0 and first alphas are out). 16:12:26 , agreed, a list of requirements is essential 16:12:51 part of why using this exclusively *now* would be premature 16:12:59 Shim ("secure boot") has no definite upstream plans, but should be relatively easy to add (a few lines of python in the bootloader module). 16:13:09 (and they'll definitely take a pull request for that) 16:14:07 There is also other stuff like LVM etc. that some people consider blockers. 16:14:15 that too, yes 16:14:29 No definite status there, I think (not sure). 16:14:56 Some stuff already works, by the way, such as SELinux. (I never tried it, but a couple other Fedora users did and it worked.) 16:15:20 (which is nice because there's zero SELinux code in there as far as I know) 16:15:41 (Well, rsync preserves xattrs, I fixed that one.) 16:15:54 (one command-line switch) 16:17:08 ok, let's wrap thing up, definitely over time now 16:17:24 thanks everyone 16:17:27 #endmeeting