13:00:30 #startmeeting Workstation WG 13:00:30 Meeting started Mon Oct 23 13:00:30 2017 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:30 The meeting name has been set to 'workstation_wg' 13:00:33 #meetingname workstation 13:00:33 The meeting name has been set to 'workstation' 13:00:35 #topic Roll call 13:00:37 .hello pfrields 13:00:38 stickster: pfrields 'Paul W. Frields' 13:00:46 .hello catanzaro 13:00:49 mcatanzaro: catanzaro 'Michael Catanzaro' 13:01:04 cschalle: juhp: ryanlerch: howdy guys 13:01:14 #chair mcatanzaro cschalle juhp ryanlerch 13:01:14 Current chairs: cschalle juhp mcatanzaro ryanlerch stickster 13:01:25 * cschalle hi 13:01:32 * stickster gives a minute or two to see if others get here 13:02:05 .hello ryanlerch 13:02:06 ryanlerch: ryanlerch 'Ryan Lerch' 13:02:19 .hello petersen 13:02:20 juhp_: petersen 'Jens Petersen' 13:03:26 OK, that's at least quorum :-) Here's our current agenda link: 13:03:29 #link https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting 13:03:44 We should probably try to cut that down, I think a few of these things are resolved and just haven't been cleaned up 13:03:58 #topic Colo(u)r emoji 13:04:06 #link https://pagure.io/fedora-workstation/issue/30 13:04:49 ok, so this is an issue of not including the correct font in the comps group? 13:05:01 ryanlerch: noto color emoji are in current F27 Live 13:05:22 I found https://pagure.io/fedora-comps/blob/master/f/comps-f27.xml.in#_6603 -- which says that google-noto-emoji-fonts are being included in Workstation (and Live) at this point -- that's a required package in the @workstation comps group 13:05:48 Oh wait, it's not the *color* font 13:05:53 ^ ryanlerch is that the issue? 13:05:53 I think it would be good to add google-noto-emoji*-fonts to comps though 13:05:58 .hello otaylor 13:05:59 otaylor: otaylor 'Owen Taylor' 13:06:00 it is now afaik 13:06:07 sorry to be late! 13:06:19 #chair otaylor 13:06:19 Current chairs: cschalle juhp mcatanzaro otaylor ryanlerch stickster 13:06:31 stickster: i assume so -- i just did a fresh install of beta today, and noticed that the emoji werent colour 13:06:44 hey 13:07:16 I summoned hadess because mclasen is not here. They are our color emoji experts. 13:07:22 didnt get a chance to dig deeper, so just filed this one so people smarter then me could confirm my assumtion that is was because the packages wernt being included 13:07:54 ryanlerch: I installed nightly the other day 13:08:17 Should we have these included in @workstation, or @fonts? 13:08:25 #link https://pagure.io/fedora-comps/blob/master/f/comps-f27.xml.in#_6603 13:08:43 I suggest @fonts 13:09:07 can anyone fill me in with what we're discussing? 13:09:15 stickster: It's already in workstation-product, which is the right place for Workstation-specific stuff, but fonts would probably be a better place I guess. 13:09:30 I have a F27 upgraded machine and here I see the package google-noto-emoji-color-fonts-20170928-1.fc27.noarch (I did not elect to install it) 13:09:34 hadess: https://pagure.io/fedora-workstation/issue/30 13:09:36 mcatanzaro: the color fonts aren't in there, just the standard emoji font. 13:09:55 cschalle: yes I think ibus-typing-booster pulls it in 13:09:57 Aaah 13:10:06 ah ok 13:10:08 eosrei-emojione-fonts is dragged in by (/me looks) 13:10:09 they are now afaik 13:10:11 ha, interesing 13:10:25 So the problem apparently is that we have some Google Noto Emoji fonts, but not the color fonts (right?) <-- hadess 13:10:36 I think we should list them explicitly instead though 13:10:49 But I think hadess wants Emoji One instead. 13:10:53 no, the eosrei-emojione-fonts is already dragged in, i'm checking by which package (the same that drags cantarell) 13:10:54 (Why?) 13:11:14 hadess: Apparently something is not working on the lives. 13:11:20 Noto has better Unicode coverage 13:11:35 "Not sure if this has been fixed, but i recently installed a Fresh Fedora 27 Beta, and the colour emoji were not working. As far as i can tell, neither the Noto Colour Emoji (google-noto-emoji-color-fonts) or the EmojiOne packages (eosrei-emojione-fonts) are installed by default in Workstation Beta." 13:11:47 it's in gnome-themes-standard: http://pkgs.fedoraproject.org/cgit/rpms/gnome-themes-standard.git/tree/gnome-themes-standard.spec#n21 13:11:52 * ryanlerch only tested on the beta, but neither noto-color or the emojione package was there. 13:12:22 and done in f27 as well: http://pkgs.fedoraproject.org/cgit/rpms/gnome-themes-standard.git/commit/?h=f27&id=a03dbaf54977fdbdc42f2e7ba2b83521e4d0ab3f 13:12:50 it's stuck in updates-testing apparently 13:12:58 It was added as a requires to gnome-themes-standard on September 11, but beta freeze was September 5 13:13:16 * juhp_ boots up Fedora-Workstation-Live-x86_64-27-20171017 13:13:26 So it's expected it didn't make it into beta, but it should have been flushed into stable after beta... if it's still stuck in updates-testing we'll need a freeze exception 13:13:51 Well updates will bring it in, no? 13:14:10 This is one of those things that would be good to have by default IMO. 13:14:16 I mean, on the lives. 13:14:43 mcatanzaro: +1 -- it is something we advertised even in the beta release announcement 13:14:54 it has +9 of karma but never made it to stable because of those warnings: https://taskotron.fedoraproject.org/artifacts/all/48e4df98-970c-11e7-8df6-525400817a8f/task_output/gnome-themes-standard-3.22.3-5.fc27.log 13:14:59 it's pushed to stable now 13:15:53 (rpmlint warnings don't disable karma autopush) 13:16:09 "Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe." 13:16:27 mcatanzaro: please give me a bodhi link 13:16:29 #link https://bodhi.fedoraproject.org/updates/gnome-themes-standard-3.22.3-5.fc27#comment-659428 13:16:35 Beta is already a bit old anyway 13:16:41 mcatanzaro: the negative karma is from a silly automated test 13:16:43 pwalter has a point, this is the sort of thing we normally put in comps 13:16:57 "pwalter: This should go to comps, and not be a hard dep here" 13:17:06 must have been a different failure. I'll file a RFE for bodhi to announce which test case failed 13:17:11 The negative karma is from pwalter :) 13:17:32 The problem with comps is that will do nothing for upgrades 13:17:56 urgh 13:18:00 ok, so not a taskotron issue after all. it was manual negative karma 13:18:03 So what we normally do is put it in comps, add a Requires somewhere minimally-inappropriate, and make a note to remove the Requires after a year or two. 13:18:40 We should probably add it to the @fonts group in comps as well. But then that begs the question: why have both Noto and Emoji One in comps? 13:18:42 cantarell is a hard req for that package, it made sense to require the emoji font at the place 13:18:53 hadess: I guess it's OK. I don't care too much.... 13:19:19 the noto vs emoji one discussion already happened downstream on the fontconfig list 13:19:57 hadess: So should we remove the Noto fonts from comps? 13:20:27 is the noto font installed by default in workstation? because it shouldn't be 13:20:52 hadess: The non-color Noto Emoji is in @workstation-product 13:20:58 that's fine 13:20:59 google-noto-emoji-fonts is, yes 13:21:08 hadess: well some people disagree about that 13:21:15 juhp_: about what? 13:21:16 OK, so it's fine to have the non-color version, you just don't want the color version... (weird?) 13:21:25 or why shouldn't it be? 13:21:37 mcatanzaro: right 13:21:55 hadess: Noto has better Unicode coverage 13:22:29 qemu keeps crashing on me :( 13:22:36 juhp_: it's also used by other OSes/desktop environments 13:22:37 🤨 13:22:46 heh, so meta 13:23:00 juhp_: if the kde or other variants want to default to noto, it just need to be installed 13:23:28 the gnome upstream made the decision to use emoji one, and hopefully emoji two in the future 13:23:43 hadess: it doesn't mean Fedora has to follow 13:24:00 juhp_: given that it's the same people doing the work, i'd hope so at least 13:24:35 hadess: what is wrong with Noto emoji? 13:24:48 I don't want to re-litigate the rationale here, but can someone summarize why one over the other for those who haven't been on those other lists/discussions? 13:24:49 it's android's default font 13:25:00 so what? 13:25:22 it's part of the visual design, which makes android identifiable 13:25:43 so goes contrary to making gnome and distributions based on it recognisable 13:25:48 I see 13:26:15 hadess, on the other hand it feels wrong to use a less complete font to stand out, as it might make you stand out for the wrong reason 13:26:42 cschalle: cantarell was less complete for how long? and it still falls back 13:27:08 what does "falls back" mean in the case of emoji and/or Unicode here? 13:27:21 hadess, and we have had a million discussions about ditching cantarell for that exact reason 13:27:37 cschalle: I agree 13:27:49 i would say we can revisit in a year's time if we didn't manage to get traction with emoji two builds, which are going to have better coverage than emoji one 13:28:08 Unicode is a moving target 13:28:30 note too that going forward emojione is no longer freely licenced anymore... 13:28:38 right 13:28:44 ryanlerch: which is why we want to move to emoji two 13:29:46 can someone tell me how big the coverage gap is? are we talking 2 emojis or 200? 13:30:45 I emojione is Unicode 7 or 8? whereas Noto is 9 or 10 - I need to check - dozens I believe 13:30:52 I would need to check 13:30:58 I see one person committing to EmojiTwo for some months now 13:31:07 I think * 13:31:25 * stickster looks at contribution data 13:32:42 Well, not much diff with Noto, although I do see behdad in there too :-) 13:33:34 (Okay I stand corrected it is not F27 WS Live) 13:33:47 I guess some update pulled it in 13:33:54 juhp_: EmojiTwo is aiming to cover Unicode 10 according to their site. 13:33:56 juhp_: it will be in the next nightly 13:34:00 stickster: great 13:34:27 So what do we need to decide/do here? 13:35:11 "No further action required" I guess 13:35:13 Should we just follow upstream then? 13:35:24 It sounds like the immediate issue of "have color emoji font in the WS" is covered thanks to the dep, but what about moving that elsewhere in a year? 13:35:35 (i.e. after need to cover upgrades passes) 13:36:33 Let's add it to either @fonts (affects everyone) or @workstation-product (affects only us) in comps, in case we ever decide to remove it from gnome-themes-standard? 13:36:36 I think we should like the default emoji fonts in @fonts 13:36:42 when discussions like this come up, /me can't wait for atomic workstation 13:37:06 s/like/list/ 13:37:08 mcatanzaro: @fonts sounds right 13:37:22 juhp_: Can you submit a PR for that to fedora-comps please? 13:37:26 okay 13:37:41 Not sure whether we "need" this fixed in F27, but you should submit for master at least. 13:37:49 okay 13:38:09 #info long discussion on temporary use of emojione vs. later emojitwo for better coverage 13:38:19 juhp_, and if we want to consider switching the default emoji font I suggest you file a separate working group ticket for that which includes some coverage statistics 13:38:26 right 13:38:34 Yes sounds good 13:38:35 #info will need to revisit this ~F29 time to get rid of gnome-themes-standard dep on the font 13:38:50 ^ should we file a Bugzilla for that and just let it sit? 13:38:58 stickster: why is the dep a problem? installing noto will override it 13:39:25 hadess: We are not generally fond of adding extra Requires to packages. (It could become a Recommends, for instance.) 13:39:53 For now it's fine, since it's needed for upgrades (at least, I don't know if upgrades respect Recommends. probably not) 13:40:11 I don't think it does 13:40:27 But in a year or two, it would be nice if it was possible to have gnome-themes-standard and be able to remove the emoji font 13:40:53 Anyway, I think we have made our preferences clear on that. Perhaps there are other items on the meeting agenda. :) 13:41:09 i really don't see the point, but *shrug* 13:41:27 #action juhp_ submit PR to add color font to @fonts in comps 13:42:15 hopefully next agenda item will be less emojitonal :) 13:42:18 #topic lol 13:42:21 #undo 13:42:21 Removing item from minutes: 13:42:48 #topic Update frequency policy 13:42:49 #link https://pagure.io/fedora-workstation/issue/28 13:43:50 I think mclasen left updates in this ticket -- and that our problem is mainly solved now by bodhi policy/process 13:44:28 since there's still a daily check by gnome-software, there's no danger of truly urgent updates going many days extra without notifying the user 13:44:44 ok sounds like an easy ticket to resolve then :) 13:44:49 while non-urgent updates will only be seen following bodhi's weekly, coordinated push 13:45:32 mcatanzaro: ^ sound right? 13:46:30 Maybe? :) 13:46:51 Looks good 13:46:52 I'll complain in the future if these daily "updates available" notifications don't go away 13:46:54 * stickster will close ticket since he thinks so. If something looks awry in the F27 release, we can revisit. 13:46:56 I think the only possible issue is that urgent issues will delay notification of the weekly push. Could be argued that that is *correct* - if you rebooted for a security update on monday, you probably would consider the Tuesday mass update to be an annoyance 13:47:22 otaylor: Yes, but only if all the updates are actually pushed out on Monday... which is not what will happen now. 13:47:43 mcatanzaro: When you are doing that, can you check to see if they are system updates or flatpak nightly updates. 13:47:46 I mean, on Monday only the security updates will go out 13:48:26 otaylor: There are flatpak nightly updates every single day (which would be fine as long as it didn't bother me about them). I think there are also system updates usually, but not always. 13:48:42 #action stickster close ticket 13:49:02 * stickster notes 7 min left before he has to go prep for a different meeting 13:49:04 mcatanzaro: what I'm saying is, let's not conflate the two things. gnome-software vs. flatpak nightly updates seems to be a purely upstream thing. 13:49:05 +1 stickster, we can reopen the ticket if this is still a problem in a month or two 13:49:13 agreed 13:50:05 otaylor: If Software is notifying daily for flatpak notifications (as I suspect) then I would expect that to be fixed as part of this ticket. Maybe we shouldn't close this ticket, then. 13:50:10 *for flatpak updates 13:51:08 mcatanzaro: I don't see why we need a workstation working group ticket for that... i'ts something to discuss with hughsie in bugzilla unless you think there's something that you think we might need to override as a matter of workstation policy 13:51:45 otaylor: I think we should continue to use the Workstation meetings to track upstream issues that significantly affect our user experience. ;) 13:51:46 also there's the question of whether Fedora will complement flatpak production and pass them through Bodhi? 13:52:06 stickster: In that case, the updates would follow a schedule that we control, though. 13:52:14 mcatanzaro: but I think find it confusing if you are saying "I'm always getting update notifications, this is really annoying for our users" and the case is (as I suspect) limited to users that have nightly flatpaks installed 13:52:27 which would presumably make them follow the same rules/policy that (hoepfully) fixes this 13:52:47 If they're nightly flatpaks, I would think I as a user assumed to want a nightly firehose 13:53:04 stickster: But not a nightly annoyance 13:53:19 stickster: flatpaks from Fedora builds will eventually follow the Bodhi pipeline (details tbd) 13:53:22 one way to fix that: "don't ask me again" 13:53:26 #action mcatanzaro to talk to hughsie about nightly flatpak update notifications 13:54:03 I was going to try to get to the langpacks, juhp_, but running out of time. 13:54:11 Let's leave the issue open, untag the meeting keyword; I'll post an update there based on the discussion with hughsie 13:54:37 stickster: it's okay I don't really have any updates there yet 13:54:54 juhp_: OK, next time then? 13:54:58 yes 13:54:58 mcatanzaro: done 13:55:09 All right. I'm going to close out, then. 13:55:17 Thanks for coming and for the good discussion, everyone. 13:55:21 #endmeeting