15:00:02 <stickster> #startmeeting Workstation WG
15:00:02 <zodbot> Meeting started Wed Dec  9 15:00:02 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:02 <zodbot> The meeting name has been set to 'workstation_wg'
15:00:06 <stickster> #meetingname workstation
15:00:07 <zodbot> The meeting name has been set to 'workstation'
15:00:10 <stickster> #topic Roll call
15:00:12 <stickster> .hello pfrields
15:00:13 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
15:00:48 <kalev> hello
15:01:29 <stickster> Hi Kalev! I have regrets from mcatanzaro with apologies, but he will be back to being here after 1st of the year per normal
15:01:36 <stickster> and from juhp, because TZ ugh
15:02:10 <stickster> Maybe we should consider trying to move this meeting earlier in the day.
15:02:29 * stickster waits for mclasen rdieter_work otaylor and anyone else
15:02:51 * mclasen is here
15:03:13 <stickster> #chair kalev mclasen rdieter_work
15:03:13 <zodbot> Current chairs: kalev mclasen rdieter_work stickster
15:04:13 <stickster> So it looks unlikely we'll have quorum but we don't have anything controversial on the agenda either
15:04:23 <stickster> cschaller is out as well
15:04:36 <stickster> Let's start with the easy stuff
15:04:46 <stickster> #topic Holiday schedule
15:05:34 * mclasen is gone on the 23rd, back on the 6th
15:06:05 <stickster> I'll be gone from Dec 19 - Jan 3.  The next scheduled meeting is Dec 23.  Given the proximity to holiday, should we simply cancel now, and meet on the 6th on schedule?
15:06:36 <kalev> I'm gone from 20th to 27th
15:07:08 <mclasen> 23 seems a lost cause
15:07:17 <mclasen> lets just go for 2016
15:07:30 <stickster> +1 (in case that wasn't clear)
15:07:56 <kalev> +1
15:08:25 <stickster> #action stickster propose to list that we cancel Dec 23, meet 2016-Jan-06 as scheduled
15:09:17 <stickster> #topic File triggers and package guidelines update
15:09:20 <stickster> rolling right along
15:11:04 <stickster> mclasen: kalev: Can either of you summarize what needs to happen here in guidelines, and to what extent a new guideline could address Rex's concern about cross-desktop?
15:11:45 <mclasen> kalev: can you ? because I don't really know what the concern was
15:12:24 * rdieter_work waves, sorry late
15:12:38 <stickster> Hi rdieter_work!
15:13:00 <kalev> so, the discussion on the list was where to put the deps, should they be in the packages that use the functionality or in comps or in low level libraries
15:13:07 <mclasen> as for the guidelines, some of the information in https://fedoraproject.org/wiki/Packaging:ScriptletSnippets is obsoleted by the file triggers
15:13:37 <kalev> I think what we have right now is pretty much working, so if there's going to be any changes it's not necessary to do them immediately
15:13:48 <stickster> mclasen: So IIUC, the file triggers mean that we don't have to include those scriptlets to rebuild mime handling (& maybe some other stuff) when new packages are installed
15:13:54 <stickster> mclasen: Is that basically right?
15:13:58 <mclasen> yes
15:14:14 <mclasen> spec files get simpler, and we run less random shell code as root every time you update
15:14:15 <kalev> I've been holding back with killing off the scriptlets because I wanted to wait for the koji builders to get updated to f23
15:14:23 <rdieter_work> are triggers viable for this case?  don't they run unconditionally? not just for packages that contain .desktop files containing MimeTypes= key ?
15:14:26 <kalev> ... which happened very recently now so I think it should be fine to start killing the scriptlets
15:15:21 <mclasen> rdieter_work: they get triggered by files in certain locations (hence the name...)
15:15:24 <rdieter_work> in fairness, update-desktop-databaes is pretty fast
15:15:41 <stickster> rdieter_work: By unconditionally, I'm assuming you mean for any package that drops something into e.g. /usr/share/mime-info
15:15:49 <rdieter_work> in contrast to update-mime-database, which is way slow
15:16:09 <mclasen> it gets run only once  though
15:16:10 <rdieter_work> stickster: we're talking about packages that drop .desktop files under /usr/share/appilcations here
15:16:15 <stickster> Ah OK
15:16:19 <mclasen> per transaction, I mean
15:16:30 <mclasen> as opposed to once per %post
15:16:35 <mclasen> so there's some win there too
15:16:35 <stickster> *nod
15:17:08 <rdieter_work> fwiw, when on fpc I'd argued these should also be %posttrans, but that was shot down since update-desktop-database is fast anyway
15:17:21 <stickster> rdieter_work: So I'm trying to understand the cross-desktop concern I think you raised on the list...
15:17:35 <stickster> And ultimately we need to figure out who's writing the guidelines update
15:17:46 <rdieter_work> stickster: I didn't raise that point, but kalev argued that since workstation installs this by default, it's ok
15:18:05 <rdieter_work> stickster: then someone (mswhendt) argued about what about non-workstation
15:18:26 <rdieter_work> which is a valid concern
15:19:08 <rdieter_work> *something* should depend on update-desktop-database, but I think it unwise to be adding deps to it everywhere too
15:19:42 <stickster> Currently xdg-utils among other things
15:19:53 <rdieter_work> right, the list was actually pretty small
15:19:57 <rdieter_work> (surprisingly)
15:20:06 * mclasen only added the dependency to enusure *new enough* utils
15:20:12 <rdieter_work> the current list of things depending on desktop-file-utils
15:21:24 <rdieter_work> following mclasen's example, deps would be added to all packages providing .desktop files
15:21:37 <rdieter_work> so we'd trade dropping scriptlets, for adding deps
15:21:49 <rdieter_work> then kalev thought that could be automated
15:22:18 <rdieter_work> which I'm open to, if it works :)  (to only conditionally add the dep if MimeType= key is present)
15:23:20 <stickster> rdieter_work: kalev: Would that be done in... rpm via its deps calculations?
15:23:30 <kalev> sure
15:23:31 <stickster> like via some macro change?
15:23:35 <kalev> yep
15:24:21 <kalev> I'm strongly opposed to anything that adds more copy and paste stuff to individual spec files
15:24:25 <mclasen___> sorry, experiencing some rawhide instability recently
15:24:33 <kalev> but this can be nicely automated
15:25:28 <stickster> kalev: OK, so what do we need? Something like a /usr/lib/rpm/macros.d/<blah> in xdg-utils?
15:25:38 <kalev> anyway, I think this is all orthogonal to the file triggers
15:25:58 <rdieter_work> stickster: no, desktop-file-utils would add some rpm magic (.attr files maybe)
15:26:32 <rdieter_work> or .attr magic added *somewhere*, doesn't necessarily have to be there, but I think having it in the same pkg makes sense
15:26:51 <rdieter_work> (eventually could be upstreamed to rpm itself)
15:26:56 * kalev nods.
15:27:50 <stickster> It sounds like you guys know what to do here... rdieter_work would you be inclined to write up some guideline change as needed, and coordinate the tech side with kalev?
15:28:02 <rdieter_work> ok
15:28:15 * stickster goes back to being a lackey scribe :-)
15:28:44 <rdieter_work> kalev: lemme know when you have something testable
15:28:57 <stickster> #info rdieter_work and kalev understand that some .attr magic may be needed in d-f-u to address, and will work together on it
15:29:11 <stickster> #action rdieter_work create guidelines change to run through FPC
15:29:22 <kalev> anyway, my plan is to start agressively dropping scriptlets from individual packages when next gnome development release comes in
15:29:44 <kalev> I was waiting for f23 to hit the builders so that the triggers would work on builders as well
15:29:47 <kalev> which we have now
15:30:23 <stickster> kalev: So to help that, we'll also want to notify (at the appropriate time) e.g. devel@ list, so packagers can go ahead and do that too?
15:30:51 <kalev> stickster: I think the FPC is already working on the guidelines update and they'll do the announcing
15:31:04 <stickster> Oh! That's news
15:31:19 <kalev> but what we could help with is coming up with a few more triggers, I think the ldconfig one is missing for example
15:31:38 <stickster> kalev: Do you have a URL for that discussion (or page) I can note for the minutes?
15:31:43 <kalev> and then the FPC can just basically say that all the scriptlets can go now, starting with F24 :)
15:31:47 <kalev> sure, let me find it
15:32:04 <kalev> https://fedorahosted.org/fpc/ticket/566
15:32:52 <kalev> I think a good course of action would be to try and make this work with the Workstation subset of packages and then FPC can doublecheck all the work and then announce widely
15:33:03 <stickster> #undo
15:33:03 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3a339cd0>
15:33:11 <stickster> oh sorry kalev !
15:33:16 <stickster> #link
15:33:19 <stickster> argh
15:33:21 <stickster> I suck at this
15:33:28 <stickster> #link https://fedorahosted.org/fpc/ticket/566
15:34:00 <stickster> #info rdieter_work may be able to ignore previous action :-)
15:34:45 <stickster> kalev: OK, agreed. As long as there is time to get any cross-desktop/package-universe stuff reasonably done for F24 too
15:34:55 <stickster> It shouldn't be a problem, honestly; it's only December
15:35:01 <stickster> Famous last words :-)
15:35:14 <kalev> oh the cross-desktop thing should work fine already, nothing has changed in that regard
15:35:52 * mclasen is feeling his meeting participation is hampered by SIGBUS
15:35:54 <kalev> if it worked in f23 it will keep working for f24; the discussion on the mailing list we had wrt the dependencies wasn't really tied to the new file trigger stuff
15:36:34 <stickster> mclasen: I thought you were just dazzled by the wit
15:36:36 <kalev> you know how mailing list discussions go, someone mentions one thing and then another person points out a small details that they noticed and then everything centers around the new thing :)
15:36:43 <stickster> :-)
15:37:25 <stickster> OK, do you guys think we can move on in that case?
15:38:08 <stickster> before mclasen gets hit by the SIGBUS again'
15:38:17 <kalev> yes, let's move on
15:38:23 <stickster> #topic Wayland by default
15:39:03 <stickster> #info Kevin Martin posted a "big plan" email to the list, and we already have some substantial QA input from Kamil
15:39:57 <mclasen> it is appreciated, but also a bit duplicative - everybody has their own list of issues
15:41:06 <stickster> mclasen: There are a lot of things to fix, for sure. One thing in the wiki page that might help is some idea of priorities -- since it's fair to say everything on the list probably won't be completely solved for all time by F24
15:41:58 <stickster> maybe that's guided in part by Kamil's input, or other folks'... as well as the technical level of effort/difficulty and common sense
15:42:38 <mclasen> I can put some more information in the page, certainly
15:43:07 <mclasen> while trying to keep the duplication limited
15:43:13 * stickster was thinking of responding to thread with that idea -- with the small group Kevin mentioned (probably includes mclasen) making the ultimate call. I think that would be helpful to indicate to people around the community
15:44:05 <kalev> I think it was a good call making it the default for rawhide
15:44:10 <stickster> agreed
15:44:11 <kalev> I know it at least forced me to use wayland :)
15:45:00 <stickster> I believe F23 is getting most (?) of the wayland work too and we're supposed to be able to test there
15:45:18 <kalev> when I was wrangling the last gnome megaupdate, 3.18.2 for F23
15:45:34 <kalev> it got tons of feedback in bodhi, mostly of things that were wayland regressions
15:45:53 <kalev> but we cleared all those out before putting 3.18.2 into stable
15:46:16 <kalev> from that, it seemed that people on F23 are testing wayland quite a lot already, which is great
15:46:19 * mcatanzaro looks up, realizes he is missing the meeting he had planned to attend despite having sent regrets, shuts up and begins reading....
15:46:24 <stickster> OK, I don't think there's anything for us to specifically decide here (nor should we, really, with only 4 of us in the house)
15:46:31 <stickster> oh! mcatanzaro makes 5 :-) but still
15:46:41 <mcatanzaro> Do we need to vote on somethnig?
15:46:47 <stickster> not really.
15:47:34 <stickster> we're just sort of ack'ing there's a plan on the list, and general consensus that it should be prioritized somehow -- mclasen I believe is in the small group Kevin mentioned of people who can intelligently do that
15:48:44 <stickster> If there's any follow up it's probably just for me to make that suggestion on list... maybe it's just obvious, but a list for the community so we can set expectations for F24 would help
15:48:54 <stickster> mclasen: Does that sound reasonable?
15:49:11 <mclasen> more or less
15:49:46 * stickster looks forward to new Wayland overlords, but also knows there will be some pain involved and we need to start managing those expectations or else risk a bunch of "waaah this sucks" press for F24 without any other context
15:49:54 <kalev> do we need to do any Qt work too or does Qt keep on working with the X11 backend under GNOME Shell wayland session?
15:49:57 <stickster> mattdm ^ might be interested in the last few minutes here
15:51:29 <stickster> rdieter_work: ^^ maybe you know Qt state?
15:51:48 <kalev> I hope we can do Qt switching independenctly at a later time, so that we don't get hit with both GTK+ and Qt bugs simultaneously :)
15:53:20 <stickster> #action stickster make suggestion of prioritizing the F24 Wayland feature list so we can set expectations for state of F24, subject to change as developers dive in of course
15:54:04 <stickster> OK, it sounds like things are quieting... kalev, I suggest taking the Qt question to the list, and we can close up here, I guess.
15:54:16 <kalev> sure
15:54:44 <stickster> #action kalev take Qt/Wayland status discussion to list
15:54:47 <stickster> #topic All other business
15:55:41 <stickster> On a personal note, I hope everyone has a fabulous holiday. It's been a really productive year in the Workstation, with so much good stuff to make computing easy and enjoyable :-)
15:56:19 <stickster> kalev: rdieter_work: mclasen: mcatanzaro: *: See you here in 2016! :-)  (sound of jingle bells)
15:56:47 <mclasen> kalev: I've talked to jadahl about qt5 apps crashing under mutter/wayland
15:56:57 <mcatanzaro> *holiday cheer*
15:57:12 <mclasen> they don't support xdg-shell, and their wl_shell implementation is buggy, from what I hear
15:57:22 <mclasen> but jadahl is going to look into handling it gracefully
15:57:34 <kalev> mclasen: ahh, I wonder if a solution would be to make them run with the X11 backend for F24?
15:57:57 <stickster> oops, there's always a bug waiting  :-D
15:59:08 <mcatanzaro> last minute point: please read http://arstechnica.com/information-technology/2015/12/fedora-23-review-skip-if-you-want-stability-stay-to-try-linuxs-bleeding-edge/ if you haven't already
15:59:48 <stickster> Thanks mcata
15:59:48 <mcatanzaro> It's a fair review but I am disappointed that the headline still portrays us as "bleeding edge" and skippable
15:59:56 <stickster> +1
16:00:15 <stickster> OK, thanks for coming everyone :-)
16:00:18 <stickster> #endmeeting