13:00:07 #startmeeting Workstation WG 13:00:07 Meeting started Mon Mar 26 13:00:07 2018 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:07 The meeting name has been set to 'workstation_wg' 13:00:09 #meetingname workstation 13:00:09 The meeting name has been set to 'workstation' 13:00:12 #topic Roll call 13:00:12 .hello ryanlerch 13:00:13 ryanlerch: ryanlerch 'Ryan Lerch' 13:00:14 .hello pfrields 13:00:16 stickster: pfrields 'Paul W. Frields' 13:00:29 .hello kalev 13:00:30 kalev: kalev 'Kalev Lember' 13:00:58 #chair ryanlerch juhp[m] kalev mclasen rdieter 13:00:58 Current chairs: juhp[m] kalev mclasen rdieter ryanlerch stickster 13:01:28 .hello petersen 13:01:29 juhp[m]: petersen 'Jens Petersen' 13:01:38 .hello mclasen 13:01:39 mclasen: mclasen 'Matthias Clasen' 13:01:49 .hello rdieter 13:01:50 rdieter: rdieter 'Rex Dieter' 13:02:47 Hi all 13:02:56 morning! 13:03:01 #info Agenda link: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting 13:03:28 #info Overall issues link: https://pagure.io/fedora-workstation/issues?status=Open -- if you see something not covered in agenda that should be, speak up now :-) 13:04:08 https://pagure.io/fedora-workstation/issue/41 maybe as well? 13:04:58 kalev: maybe -- what do we need to decide there? 13:05:14 .hello catanzaro 13:05:15 mcatanzaro: catanzaro 'Michael Catanzaro' 13:05:30 #chair mcatanzaro 13:05:30 Current chairs: juhp[m] kalev mcatanzaro mclasen rdieter ryanlerch stickster 13:05:52 I haven't gotten to try the latest build 13:05:57 In the meantime... let's forge ahead 13:06:03 #topic Cantarell in F28 13:06:10 #link https://pagure.io/fedora-workstation/issue/40 13:06:30 * cschalle hi 13:07:28 #chair cschalle 13:07:28 Current chairs: cschalle juhp[m] kalev mcatanzaro mclasen rdieter ryanlerch stickster 13:08:00 .here otaylor 13:08:21 sorry to be late 13:08:45 I haven't had a chance to test the new version of Cantarell, but given the reduced glyph coverage also, I think reverting is a good idea 13:09:24 * kalev doesn't have strong opinions either way. 13:09:26 .bug 1556854 13:09:28 juhp [m] : Bug 1556854 – Wrong cyrillic font - https://bugzilla.redhat.com/1556854 13:09:40 the new version is a significant improvement, aesthetically. we're making use of the new font weights on the lock screen and it looks great 13:09:56 I don't think coverage can be a strong argument, since cantarell had relatively weak coverage to begin with 13:10:01 Let me add a similar comment to the ticket 13:10:05 unless we loose coverage in en_US 13:10:29 is there a screenshot of spacing issues somewhere ? 13:10:45 I see severe font issues on this system, but it doesn't have the latest cantarell 13:10:57 Dunno how easy it is to fix the spacing issue Adam reported 13:11:11 what is the "spacing issue adam reported" 13:11:14 ? 13:11:22 i'd be interested to see a screenshot too. i haven't seen spacing issues in my testing 13:11:29 Is there a bug? Okay mentioned in the ticket 13:12:14 hm, I think I saw screenshots somewhere, let me try and hunt them down 13:12:18 "many issues with spacing between words" is really too vague without a screenshot 13:12:36 * mclasen will abstain without a way to test this himself 13:12:55 Agreed 13:13:12 aha, found, trying to get a link to the mailing list post now 13:13:15 i've been using the latest version for some time and haven't noticed any significant issues 13:13:22 I think we should wait for more details 13:13:24 (not a font expert though) 13:13:33 I updated to the new .101 and there are some weird things I notice -- like "m" and "n" characters have odd rendering in default weights on the Top Bar 13:13:46 But I'm not on a hiDPI screen here 13:14:21 https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/AF7TZUABMVN2HIV5VPODWSVNURE7PDDO/ has screenshots 13:14:47 https://koji.fedoraproject.org/koji/buildinfo?buildID=1058449 13:15:17 we're under time pressure here, I guess 13:15:36 mclasen: Do you know what Nikolaus meant about subpixel positioning? 13:15:37 FWIW my opinion is that the new version is clearly inferior, based on adamw's screenshots and the lack of Cyrillic coverage, but my inclination is to go with the wishes of the font designer and I presume he wouldn't have released it if he didn't think it was better.... 13:15:39 hm, or at least it claims to have screenshots, I'm not sure how to actually see the new font changes there 13:15:55 otaylor: I assume he means that we have a crippled freetype 13:16:13 WRT hinting? It didn't sound like that, no 13:16:29 Might be good to test the font build on f27 too... 13:16:48 it sounded more like he was designing the font to be rendered with multiple horizontal phases, and Qt was doing that? 13:17:11 https://openqa.fedoraproject.org/tests/204833#step/disk_custom_ext3/11 is a screenshot that shows some issues 13:17:15 (nwould cause a significant glyph cache size increase...) 13:17:31 yes 13:17:32 mcatanzaro: actually no... See his comments in the above bug 13:17:51 some letters are really smooshed together in that screen shot (look at "SP" in "SPACE" at lower left, or the word "Installation" at lower right 13:18:00 mclasen: Would be good to catch up with him, and make sure that our text stack plans and how our default font is being developed are in sync 13:18:27 otaylor: yes, we should try to sit down with him in #gnome-design and figure out what concretely needs to happen 13:18:40 but first I need to see the font on my system 13:18:45 * mclasen should package layer it 13:18:53 stickster: Oy, collisions 13:19:43 INSTALLATION in the upper right shows some bad kerning - would be a test case to compare to see if kerning tables were dropped (as it sounded for what adamw quoted) 13:19:53 * juhp[m] is in a train from the airport... 13:20:09 juhp: It looks like all he says in that bug is "I think it's easier to prepend cantarell to the default font list for supported languages?" 13:20:27 Nikolaus is the Cantarell designer, not Nicolas 13:20:40 Oh wait, that screenshot I'm looking at predates the .101 version 13:20:52 Anyway, the difference is subtle enough that I'm not sure people are going to notice except when comparing screenshots side-by-side, or on the login screen where the letters are huge. 13:21:13 But users with Cyrillic locales are going to notice for sure. 13:21:44 mcatanzaro: i'm not sure "users will notice" is the relevant heuristic here... 13:21:50 if we go with the new cantarell for F28, we'll need to figure out the fallback font changes so that at least cyrillic falls back to noto 13:22:02 aday: But if the font looks *worse* as rendered, then it isn't an improvement 13:22:15 kalev: I think we figured that out 13:22:27 * kalev nods. 13:22:29 Yeah, Akira is around to help with that. 13:22:38 otaylor: sure, unnoticed changes can go in either direction 13:22:40 We just need to follow-up and make sure it happens. 13:22:58 my point was that quality changes aren't always consciously registered 13:23:22 mcatanzaro: sorry I think I meant quotes in the corresponding Pagure ticket, which I just managed to lose 13:24:23 """thanks for the feedback :) cantarell's spacing does indeed look a bit funky... in gtk3 and firefox. that's due to a missing technical detail called "subpixel positioning". Spacing looks more consistent in Qt apps and Chrome. there also isn't any kerning yet, so things like AVA, To, etc. look gap-y""" 13:24:32 I think we need some AB screenshots or text samples and some follow up by mclasen or someone else who deals with the text stack (weirdly not me any more... :-/) for what adamw reported discussing with madigens (Nikolaus) 13:24:35 That doesn't look like a request for us to stick to the old version, though. 13:25:34 Since the difference is subtle, my inclination is to bat this down to the Cantarell developers and let them decide how to handle it. I'm not sure this qualifies as a major issue the WG should have to deal with. 13:25:44 well, it looks like an admission that the new version might not be finished, or might not be optimally working with our text stack compared to the old version. 13:25:51 unless we can somebody with sufficient knowledge of the font stack and time to sit down and sort through the issues this week, I guess reverting to the old version for the beta is the responsible approach 13:26:03 mcatanzaro: perhaps not, but it also doesn't include a plan/ETA for addressing 13:26:12 (nor does it *have* to, but that's something we should care about) 13:26:18 the beta ship has already sailed, I think. this is more about what to do for the final release 13:26:19 and work out the issues in rawhide 13:26:24 kalev: agreed 13:26:28 oh, ok 13:26:30 * mclasen is behind 13:26:36 (hmm can't find that yet: fwiw - https://pagure.io/fedora-workstation/issue/36) 13:27:07 ok, so lets revert for now and if this gets resolved I guess there is little stopping us from doing an post release update bringing the new version back? 13:27:42 cschalle: well, adamw will definitely not be happy if we juggle fonts back and forth from a OpenQA qa-by-screenshot perspective 13:28:17 changing fonts post-release seems dubious to me 13:28:23 the lock screen looks fairly different with the new version, due to the use of the thin weight. could be a surprising change 13:28:28 cschalle: If we revert it, then the new version should wait until F29, especially since it reduces glyph coverage 13:28:40 ok, well I am fine with delaying the new version to F29 too 13:28:51 agreed with that mcatanzaro just said 13:29:15 mcatanzaro: +1 13:29:27 +1 from me too. 13:29:40 I think it's ok to change the font between beta and the final freeze, but not after that 13:29:51 #proposal: Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed. 13:29:51 +1 13:30:15 Right 13:30:15 #proposed Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed. 13:30:24 mcatanzaro: +1 13:30:29 +1 13:30:30 +1 13:30:31 +1 from the working groups perspective, but clearly action now is needed to understand the nature of the regression 13:30:42 does the things in the shell matter if there arent the right weights there though? 13:30:51 1 13:30:55 +1 13:31:09 +1 13:31:28 i.e. will it fall back to afont weight that exists? 13:31:29 Though don't think we need to wait 6 months :) 13:31:30 ryanlerch: i think it should fall back to the old weights if they're not available. not 100% though 13:31:42 (100% sure, i mean) 13:31:50 +1 13:32:16 +1 13:32:25 OK, I think we have consensus 13:32:29 ryanlerch: https://gitlab.gnome.org/GNOME/gnome-shell/issues/45#note_56187 13:32:40 #agreed Revert to old Cantarell for F28 but leave it be in rawhide, revisit in six months to see if regressions are still unaddressed. 13:32:53 mcatanzaro: thanks, my copypasta not fast enough apparently 13:32:53 thanks guys, I'll go and unpush the cantarell update from updates-testing then 13:33:36 #action kalev unpush Cantarell update from updates-testing 13:33:50 otaylor: What else needs to happen for follow-up here, and who should be doing it? 13:33:56 aday: should we have a discussion with madigens to figure out what the situation is with Cantarell vs. GNOME tech? 13:34:01 *jinx ;-) 13:34:29 otaylor: I'd like to be in it too 13:34:29 otaylor: i agree that should happen! not sure what i'd have to contribute though 13:34:52 mclasen: Definitely a good idea to have you there 13:34:53 it'd be good to make sure that jimmac's involved 13:35:15 so, jimmac, rather than you ? 13:35:34 aday: Well, someone from the design side, so we can have a good understanding of what the tradeoffs we're making for visual appearance are. 13:35:48 #action otaylor mclasen aday discuss Cantarell/text-stack issues with madigens, involve and/or jimmac as needed 13:36:18 otaylor: yes, for sure 13:37:34 OK, next up is... 13:37:38 #topic Initial setup redundancy 13:37:46 #link https://pagure.io/fedora-workstation/issue/21 13:38:05 juhp[m]: (or anyone): Where is https://bugzilla.gnome.org/show_bug.cgi?id=794166 at this point? 13:38:48 Well the patch there looks good from a code perspective, but it looks like the developer has not actually tested it yet 13:39:30 adamw also raised a concern that the default input method for Japanese appears to me nothing, so not sure if it will work in all locales. 13:39:43 hm :-\ 13:40:13 Unfortunately I have been traveling this last week - so don't really have anything to update or a chance to test 13:40:23 I'll test the patch and see how it works 13:40:32 I will talk to pay (epico) tomorrow 13:40:34 Are we hoping to pull this in for GA? 13:41:08 Yeah, I'll make sure it gets pulled in for GA *if* the patch is ready in time for that 13:41:09 We have a couple weeks remaining in which to do that, but clearly we don't want to run the clock out if so 13:41:14 mcatanzaro: coolio 13:41:39 OK -- does anyone disagree that we should let juhp[m] look into this with epico and get back with us in the next day or two? 13:41:42 mclasen: Do you want to do a code review as well? Or OK with my comments? 13:41:52 stickster, sounds good to me 13:42:38 mcatanzaro: seems you are doing a fine job there 13:42:44 :-) 13:43:10 #agreed give juhp[m] a few days to look into the g-i-s patch with epico and report back 13:43:21 Okay 13:43:29 #topic All other business (open floor) 13:43:51 Next meeting is Monday April 9. I don't have the meeting chair rotation in front of me but I know it's not me ;-) 13:44:01 Review help is most welcome anyway 13:44:12 However, I can't attend that day since there's a big Fedora hackathon that I'm facilitating all that week 13:44:24 stickster, I filed two tickets for 3rd party software. I think it would be good to discuss those 13:44:49 #info kalev is listed as chair for April 9 13:44:59 cschalle: Sure, drop the link here and we can discuss 13:45:06 Note, we have 15 min left 13:45:34 Nvidia driver - https://pagure.io/fedora-workstation/issue/37 and the the same ticket for Steam is 38 13:46:43 Basically I want to start lining up repos for F28 that we want to include 13:47:13 F28 or F29? 13:47:18 F28 13:47:30 Seems *really* late for F28? *shrug* 13:47:32 * stickster chuckles, this really should be in the Beta but obviously missed to boat 13:47:36 *the 13:47:52 yeah, I was holding off due to waiting for some fixes to the 3rd party support in GNOME Software 13:48:14 on the positive side, it isn't like this stuff is untested these repos are widely used and in operation for years 13:48:23 cschalle: Is this the bit where we have some official Fedora repo showing up as 3rd party? 13:48:31 cschalle: yeah, that's reasonable 13:48:43 we're only talking about something in /etc/yum.repos.d after all 13:48:50 and IIRC disabled by default 13:49:23 stickster, no the way it got implemented in the end is that if you choose to enable 3rd party software it will install the rpm that includes the repo links at that point 13:49:24 For the case of the NVIDIA driver, there is some controversy as to whether we should use Negativo or RPMFusion as the source. Spot is aware and did not complain about RPMFusion, so looks like we have our choice of either one. 13:49:46 mcatanzaro, well Spot agreed that having a single app repo is preferable too 13:50:04 Looks like RPMFusion developers are happy to provide that, though, so that's not a point against RPMFusion 13:50:42 And they're active in the issue thread. I've been trying to get them to explain why we should use their source instead of Negativo's, but I'm having trouble understanding their responses. 13:50:51 mcatanzaro, are they? at first I thought so, but then the discussion seemed to turn into 'we will just put any package you want into this one repo' 13:51:26 * mclasen thinks they are just defending their turf 13:51:37 mcatanzaro, the main argument in rpmfusion favour IMHO is that there is a group of people behind it, so in theory at least it should be less chance of lack of maintenance 13:51:39 *sigh 13:51:43 mcatanzaro, we are a community, simone works is mergeable into ours, but not the other way 13:51:45 It sounds to me like their driver is still expected to break users' computers after kernel updates, which seems unacceptable. But they are saying this is still the case for the Negativo driver as well. I don't pretend to understand. 13:51:52 Hi kwizart! 13:51:55 hi 13:52:14 * rdieter is generally in favor of using rpmfusion whereever possible 13:52:17 mcatanzaro: I thought a comment in this ticket thread specifically says they have the same (or similar) nouveau fallback 13:52:56 stickster, not only the same, but the nouveau fallback was designed by me (after an original idea from hans) 13:53:03 as a sidenote, the Nvidia driver is not the worlds greatest example though as there are efforts to get a NVidia hosted repo set up, so this is intermediate regardless 13:53:08 I even think we have a better iterration 13:54:07 I was kind of under the impression that we were planning to use Negativo mainly because we assumed an RPMFusion-provided repo would be rejected by legal. But it seems like that is not the case? cschalle? 13:54:30 mcatanzaro, no legal doesn't care who provides the repo 13:54:41 a "drivers" repo that contains 'everything good' is going to be tough to get a positive review for 13:54:49 in particular if it is open to random future additions 13:54:55 mcatanzaro, they care more about the policy around the repo. ie no 'surprise' apps showing up there etc. 13:55:04 I think Spot was clear that the preference is for a single-use repo 13:55:05 mclasen: random as in stuff we (WG) specifically ask to be included 13:55:08 Then if RPMFusion provides a repo named nvidia-driver that contains just the NVIDIA driver, it would be fine? 13:55:18 mcatanzaro, yes 13:55:22 *nod 13:55:25 rdieter: still not what we want 13:55:31 kwizart: Sound OK? 13:55:45 mclasen: that's not our call either, imo (that's a legal one or policy one) 13:55:45 separating the repos is a risk-minimization, as explained by cschalle in the ticket 13:55:54 mcatanzaro, sure 13:57:00 just to be fully complete, as a we still at the "service design" step 13:57:37 would (fe-legal) accept on pre-built nvidia kernel module ? I think this is controversial, but worth to ask 13:57:41 Is there a technical reason we couldn't change the repo definition next release? 13:58:09 kwizart, last we asked the answer was no, but I also know there are some discussions around that as part of the discussions for a NVidia hosted repo 13:58:46 stickster, shouldn't be, and the advantage of single app repos here, is that we can switch repos without collateral damage to other applications 13:59:00 cschalle, okay. I know nvidia provides ones for sles, so feel free to forward me anything relevant about this particular issue 13:59:25 * mclasen has to run 13:59:40 Given where things are at the moment, maybe we should be doing this: (1) working specifically on negativo for F28; (2) set a tickler for late August to get with rpmfusion to see if we should swap over 14:00:00 stickster, sorry, but this is again, not acceptable 14:00:09 I'd defer it to F29 so we don't have to switch users from one repo to the other 14:00:18 kwizard: but you don't have a vote in it 14:00:26 It's still a talking point whether we have it now or in the fall 14:00:27 kwizart: are things working and testable now? 14:00:48 kwizart: why not? 14:01:10 How will the transition from one repo to the other work? Do we really want to teach GNOME Software to disable the Negativo repo and enable the RPMFusion one automatically? 14:01:25 stickster, as pointed on the first comment, this is not acceptable to bypass the "community review" process fedora as created to allow a single party 14:01:28 mcatanzaro: as long as rpmfusion is "newer", it should be fine 14:01:34 * mclasen gives a +1 to going with the existing negative solution and runs offf 14:01:44 mcatanzaro, I assume that if we drop one repo in fedora-workstation-repos and put in another which containers a newer version that will automatically happen 14:01:51 cschalle: mcatanzaro: right. 14:02:00 kalev, is that right? 14:02:09 mcatanzaro: can't we just change the URL in the repo file? 😬 14:02:15 kwizart: nonsense 14:02:27 juhp[m]: that would be unwise (fragile) 14:02:28 mclasen, fedora is nonsense ? 14:02:39 kwizart: I thought the community review is by this WG ;-) 14:02:57 cschalle: ^ tell me if I'm misunderstanding how the policy works, it's been a while since I read it 14:03:08 kwizart: Looks like everyone agrees the long-term solution is RPMFusion... that's not what I was expecting! I would be happy with this result if I were you. :) 14:03:16 stickster, this is a general review, not a package review ? was a packager review held by some that was fully understanding the subject ? 14:03:19 no 14:03:48 mcatanzaro: yes, I believe so 14:04:11 I think we (worktation WG) can wash our hands of this, formally vote on accepting rpmfusion if they can provide specifically what is asked-for. 14:04:23 negativo is still conflicting with rpmfusion drivers, that's the point of using rpmfusion in the first step 14:04:42 rdieter, everything is up and running now 14:05:02 Well we're over time 14:05:03 kwizart: rpmfusion has a nvidia-only repo? 14:05:08 mcatanzaro: yes, well so 14:05:09 the conflict is negativo (miss-design), we cannot fix it 14:05:37 Let's take this to #fedora-workstation 14:05:48 I don't think anyone has this room after us, but we are overtime here 14:05:49 sure 14:05:56 ok 14:06:26 #info Need to resolve the question of repo to carry, whether to do for F28/F29, possible update path issues 14:06:32 Thank you for coming everyone 14:06:37 Bye! 14:06:40 #endmeeting