16:05:31 <adamw> #startmeeting F29-blocker-review 16:05:31 <zodbot> Meeting started Mon Sep 24 16:05:31 2018 UTC. 16:05:31 <zodbot> This meeting is logged and archived in a public location. 16:05:31 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:05:31 <zodbot> The meeting name has been set to 'f29-blocker-review' 16:05:31 <adamw> #meetingname F29-blocker-review 16:05:31 <adamw> #topic Roll Call 16:05:31 <zodbot> The meeting name has been set to 'f29-blocker-review' 16:05:55 * coremodule is here, ready to act as secretary. 16:06:36 <adamw> who's around for blocker review fun? 16:07:02 * kalev can't stay today, sorry. 16:07:16 * cmurf is super spacey so that's a maybe 16:07:29 <adamw> kalev: ok 16:07:47 * jlanda travelling on train, so just reading 16:07:49 <adamw> kalev: there are quite a lot of proposed GNOME blockers...know if anyone else can come by? or do we have notes in-bug? 16:08:49 <Southern_Gentlem> .hello2 jbwillia 16:08:50 <zodbot> Southern_Gentlem: Sorry, but you don't exist 16:09:02 <Southern_Gentlem> .hello jbwillia 16:09:03 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com> 16:09:21 <kalev> adamw: hm, maybe mclasen is around? 16:09:35 <mclasen> kalev: whats the question ? 16:09:37 <bcotton> .hello2 16:09:38 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 16:10:04 <kalev> mclasen: I told adamw that I can't stay around for the blocker review meeting and he asked if I know anyone else from gnome who could be here 16:10:10 <kalev> mclasen: and I said maybe you :) 16:10:17 <mclasen> i can be 16:10:24 <kalev> awesome, thanks 16:11:33 <mkolman> ls 16:12:00 * mkolman thinks: hmm, dir seems empty ;-) 16:12:33 <adamw> thanks mclasen 16:12:38 <adamw> we'll ping your for the gnome bugs as they come up 16:12:52 <adamw> mkolman: i think that means you accept responsibility for all the blocker bugs, right? :P 16:13:08 <adamw> #chair coremodule bcotton 16:13:08 <zodbot> Current chairs: adamw bcotton coremodule 16:13:10 * mkolman runs away 16:14:34 <adamw> alrighty, boilerplate time 16:14:43 <adamw> #topic Introduction 16:14:43 <adamw> Why are we here? 16:14:43 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 16:14:43 <adamw> #info We'll be following the process outlined at: 16:14:45 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:14:45 <adamw> #info The bugs up for review today are available at: 16:14:47 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:14:49 <adamw> #info The criteria for release blocking bugs can be found at: 16:14:51 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:14:53 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria 16:14:57 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria 16:14:59 <adamw> #info 9 Proposed Blockers 16:15:01 <adamw> #info 8 Accepted Blockers 16:15:03 <adamw> #info 1 Accepted Previous Release Blockers 16:15:05 <adamw> #info 3 Proposed Freeze Exceptions 16:15:07 <adamw> (that's what we have, for Final) 16:15:16 <adamw> #info coremodule will secretarialize 16:15:26 <adamw> #info starting with proposed Final blockers 16:15:30 <adamw> #topic (1625645) selinux prevents loading of anything inside /etc/cron.d 16:15:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625645 16:15:30 <adamw> #info Proposed Blocker, cronie, ASSIGNED 16:17:38 <cmurf> well it's clearly a problem that for Server is worth blocking on, but no criterion 16:18:06 <cmurf> maybe punt and see if it gets fixed? 16:18:22 <Southern_Gentlem> well that means the system cant sync time which can be an big issue 16:18:40 <adamw> i'd be OK with the same decision as last week 16:18:41 <cmurf> or escalate to fesco sooner than later and they can just make it a blocker? 16:18:55 <adamw> it kinda implies that someone should propose a criterion, if we're gonna block on this 16:19:00 <adamw> if kparal were around i'd ask if he wanted to do it 16:19:06 <Southern_Gentlem> +1 blocker if we can find a reason if not +1FE 16:19:42 <cmurf> fesco can make it a blocker with a simple vote in the issue if that's what's needed to make sure it gets fixed 16:20:42 <cmurf> Southern_Gentlem: pretty sure time sync is not done by any chron for a long time now, it's been a systemd service of some sort, usually chrony 16:23:35 <adamw> sgallagh: around, at all? 16:23:55 <sgallagh> Sort of. What's up? 16:24:23 <sgallagh> eep, cron doesn't work at all? 16:25:07 <sgallagh> Or only /etc/cron.d specifically? 16:25:09 <jlanda> not for jobs from /etc/cron.d 16:25:17 <adamw> yeah 16:25:24 <adamw> was just wondering if you had Thoughts(tm) 16:26:05 <sgallagh> Do we have any criteria around log rotation? 16:26:10 <adamw> uhhh 16:26:38 <adamw> don't think we have anything specific, no 16:27:10 <sgallagh> Or RAID health? 16:27:42 <sgallagh> We don't really use cron for much anymore, since systemd timers are much smarter. 16:28:10 <sgallagh> Checking for RAID health and rotation of logs are the only holdouts, so far as I am aware 16:28:40 <bcotton> yeah, but cron still seems like a pretty core daemon for users, particularly in server land 16:28:41 <sgallagh> I mean, end-users may drop stuff in there and it would stink if that didn't work, of course 16:28:44 <sgallagh> yeah 16:29:19 <jlanda> users expect a working /etc/cron.d dir, not a useless one :P 16:29:31 <adamw> i think that stuff that happens daily or less often would actually work OK, too 16:29:38 <sgallagh> I suppose it probably SHOULD be proposed as a criterion for Final: "Cron must work for system-installed and user-installed tasks" 16:29:42 <adamw> as /etc/cron.daily , weekly , monthly are handled by /etc/crontab 16:29:50 <adamw> only cron.hourly is handled by a file in /etc/cron.d 16:29:56 <adamw> and anything else that's actually installed direct to /etc/cron.d 16:30:09 * sgallagh nods 16:30:23 <adamw> probably be worth checking what's actually in /etc/cron.d on an install of server with all blocking bits in it, i guess 16:30:29 <adamw> (freeipa and postgres) 16:30:33 <sgallagh> I'd think people would tend to use root's user crontab rather than cron.d though. 16:30:37 <sgallagh> But I'm splitting hairs 16:31:17 <bcotton> i tend to use cron.d for the theoretical benefits of config management and backup 16:31:27 <jlanda> I tend to use use cron.d when I have a lot of tasks to set, it's easyer to maintain 16:31:32 <sgallagh> adamw: opendnssec uses it too, apparently 16:31:44 <sgallagh> So that'll likely break DNSSEC for FreeIPA 16:31:49 <adamw> ok, so... 16:31:53 * sgallagh just checked the F29 IPA install he had handy 16:31:56 <cmurf> i don't have /etc/chron.d at all on my Fedora 28 Server 16:32:06 <cmurf> And I didn't delete it 16:32:07 <adamw> it doen't have an h in it. 16:32:08 <sgallagh> cmurf: Spell it correctly, maybe? :) 16:32:13 <cmurf> LOL 16:32:45 <cmurf> 0hourlyl and raid-check that's it 16:32:46 <adamw> proposed #agreed 1625645 - punt (delay decision) - no criterion has yet been proposed that would cover this, but we are still a bit concerned about it and willing to give it another week for further investigation and potential criteria proposals before rejecting 16:32:58 <adamw> cmurf: that implies anything in /etc/cron.hourly , so include anything in there 16:32:59 <cmurf> s/hourlyl/0hourly 16:33:12 <adamw> (0hourly is what runs the things in /etc/cron.hourly) 16:33:15 <sgallagh> FWIW, if this came to FESCo, I'd vote to block. But I do think we want a proper criterion to test against int he future 16:35:25 * Southern_Gentlem been on this for 20 minutes and getting nowhere 16:36:08 <jlanda> for whole cron jobs? (/etc/ root's cron, users' cron)? 16:36:56 * bcotton is +1 to adamw's proposal 16:37:08 <Southern_Gentlem> +1 punt 16:37:17 <Southern_Gentlem> ack 16:37:44 <adamw> #agreed 1625645 - punt (delay decision) - no criterion has yet been proposed that would cover this, but we are still a bit concerned about it and willing to give it another week for further investigation and potential criteria proposals before rejecting 16:37:52 <adamw> #topic (1631002) gnome-control-center stuck and starts consume memory abnormally if I try to change the background or lock screen image. 16:37:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1631002 16:37:52 <adamw> #info Proposed Blocker, gnome-control-center, NEW 16:37:53 <cmurf> ack 16:38:46 <cmurf> I'm leaning toward +1 on this 16:39:19 <cmurf> it's not unreasonable for ~/Pictures to contain thousands of items, and that's not the user's fault if the background panel can't parse 16:40:40 <bcotton> what's the criterion, though? 16:41:23 <Southern_Gentlem> desktop apps should run as expected 16:41:38 <adamw> i'd at least like for someone else to reproduce it first 16:42:00 <adamw> and i'm still kinda not sure it reaches the blocker threshold even then 16:42:07 <Southern_Gentlem> +1 punt 16:42:08 <adamw> bug that needs fixing? sure. does it really have to block the release? ehhh. 16:42:25 <cmurf> having 1000+ images in ~/Pictures is not a condition upon default installation 16:42:31 <adamw> so, potential criteria: 16:42:34 <adamw> "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." 16:42:40 <adamw> "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use." 16:43:04 <adamw> (this is a bit fuzzy as you can sort of see the Control Center as an app *or* as part of the panel...we should probably redraft those criteria a bit) 16:43:15 <jlanda> thousands of photos is a typical use? that's the main fact 16:43:24 <cmurf> ~/Pictures having 1000+ images is entirely within the range suggested by "typical" 16:45:11 <cmurf> but sure it's reasonable to have a reproducer and understand the conditions under which it fails 16:45:47 <cmurf> like, is it really that there's a single raw image in ~/Pictures and it's actually puking on that? or something else? 16:45:54 <adamw> right. 16:46:10 <adamw> i'm probably -1 on this for now, open to revoting in future if we get data suggesting this might be a widespread issue. 16:46:45 <Southern_Gentlem> +1 punt 16:47:04 <Southern_Gentlem> to see if we can get a reproducor 16:47:27 <bcotton> +1 punt 16:48:03 <Southern_Gentlem> of course tomorrow beta is released we may seeing more or a update fixes it waiting for the freeze to be lifted 16:48:24 <adamw> i don't think there's any fix pending for this. 16:48:51 <adamw> mclasen: you have any thoughts on this one? 16:48:59 <Southern_Gentlem> but i am sure there are some gnome updates waiting 16:49:06 * mclasen looks up 16:49:11 <adamw> there are, yes. but i don't think any of them have anything to do with this. 16:49:39 <adamw> (unless i missed something) 16:50:02 * Southern_Gentlem being optomistic 16:50:41 <mclasen> I have complained about the background panel locking up my system before, to no avail 16:51:47 <adamw> same kinda situation? do you have a lot of images? 16:52:11 <mclasen> I don't know, it just locks up. Yes, I have some images 16:52:26 <mclasen> anyway, a fix has not appeared despite me complaining about the issue 16:52:30 <mclasen> so blocking on it seems risky 16:54:23 <adamw> thanks 16:54:48 <adamw> well, so far, we have -1 from me, 'leaning towards +1' from cmurf, punt from gentleman and bcotton 16:54:51 <adamw> any other votes? 16:55:01 <cmurf> +1 punt 16:55:15 <cmurf> i'll test it see if I can find the edges 16:56:39 <adamw> ok, so let's call it punt, then 16:57:23 <adamw> proposed #agreed 1631002 - punt (delay decision) - this one is a bit marginal as to whether it's bad enough to violate the default application or panel criteria. we will delay the decision to allow time for some more testing by other people to 'find the edges' 16:58:37 <cmurf> ack 16:58:45 <Southern_Gentlem> ack 16:59:49 <Southern_Gentlem> bcotton, ping 16:59:49 <zodbot> Southern_Gentlem: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings 17:00:20 <adamw> #agreed 1631002 - punt (delay decision) - this one is a bit marginal as to whether it's bad enough to violate the default application or panel criteria. we will delay the decision to allow time for some more testing by other people to 'find the edges' 17:00:22 <adamw> two acks it is! 17:00:29 <adamw> #topic (1625142) In Gnome Wayland, forward-key-event does not work well, breaks space key completely 17:00:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625142 17:00:29 <adamw> #info Proposed Blocker, gnome-shell, NEW 17:00:44 <bcotton> oops, sorry 17:01:02 <cmurf> what's the criterion? 17:01:15 <cmurf> and is ibustypingbooster enabled by default? 17:02:02 <Southern_Gentlem> +1 block 17:02:51 <Southern_Gentlem> breaking input devices is a definite blocker to me 17:03:22 <adamw> i'm trying to find out about typing booster 17:03:29 <adamw> i usually test with japanese, i don't think it's used for that 17:03:53 <cmurf> i've used typing booster but I had to enable it 17:04:13 <Southern_Gentlem> works in X, but borked in wayland 17:04:34 <adamw> ibus-typing-booster is in the workstation package set... 17:04:58 <adamw> let's see if we can get a hold of mfabian 17:05:00 <mclasen> not installed by default, though ? I hope 17:05:08 <adamw> mclasen: it is 17:05:17 <adamw> but i dunno if that means it's *used* by default 17:05:30 * mclasen rolls eyes 17:05:38 <adamw> it's in the workstation-product group 17:05:44 <adamw> without a 'type', which means it's mandatory 17:06:30 * adamw pinging mfabian 17:06:49 <adamw> if we can't get him, i'd vote punt on this one, to ask for more details about whether typing-booster is used by default for any language 17:07:56 * mclasen would suggest that the fix is to make it not installed, or at least not used, by default 17:09:11 <adamw> that would be an option, sure. 17:09:17 <adamw> welp, mfabian doesn't seem to be around 17:09:19 <adamw> so i vote punt 17:09:21 <adamw> any other votes? 17:09:46 <bcotton> +1 punt 17:10:00 <coremodule> +1 punt 17:10:19 <bcotton> independently of blocker status, do we want to re-vote on FE? 17:10:29 <adamw> i think we can skip it, since we're not frozen 17:10:34 <adamw> fe status is a bit pointless outside of a freeze 17:10:56 <cmurf> +1 punt 17:10:58 <cmurf> fix it 17:11:21 <bcotton> sure. just thinking it might be good to pre-bless it so that folks feel like they won't hit the freeze if they're not done in time. it's more of a cosmetic vote at this point :-) 17:12:11 <adamw> ehhh, i don't think that's gonna be a problem, it's not like a fix couldn't go out as an update 17:12:23 <cmurf> exactly 17:12:26 <bcotton> worksforme 17:12:32 <adamw> proposed #agreed 1625142 - punt (delay decision) - we'd like some more information on exactly when this happens, and particularly if ibus-typing-booster is used by default for any language, before making a decision 17:12:46 <Southern_Gentlem> ack 17:12:47 <adamw> so after an hour we have punted three bugs, fine work everyone :P 17:13:05 * bcotton goes to brew another pot of coffee 17:13:07 <coremodule> ack 17:13:10 <cmurf> ack 17:13:24 <bcotton> ack 17:14:23 <adamw> #agreed 1625142 - punt (delay decision) - we'd like some more information on exactly when this happens, and particularly if ibus-typing-booster is used by default for any language, before making a decision 17:14:29 <adamw> #topic (1629409) switching to tty2 then back to gdm results in hang, gdm must be restarted 17:14:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1629409 17:14:29 <adamw> #info Proposed Blocker, gnome-shell, NEW 17:14:50 <cmurf> this is a nasty bug and I'd like it to block but I don't know what criterion would apply 17:15:04 <cmurf> it's sort of a basic functionality fail, even though switching itself is not an application 17:15:18 * satellit FYI my cinnamon / wks f28 install goes to 100% usage and have to reboot to recover..... sorry to be out of order here 17:16:20 <cmurf> i'm not even sure of the cause still because there's nothing terribly useful in the journal 17:17:08 <adamw> sigh, so many bugs that aren't straightforward to decide. 17:17:27 <adamw> well, hans seems to think he knows what the cause is. 17:18:06 <cmurf> ok well +1 punt and maybe it just gets fixed 17:18:27 <adamw> i think the 'default application' criterion would require the least bending, of the criteria we have, it's reasonable to apply it to something like gdm, and arguably 'keep working on vt switch' is pretty basic functionality for gdm... 17:18:53 <cmurf> i can definitely vote +1 for that too 17:19:43 <coremodule> I'm with the idea to punt since the fix is here, but this is a nasty bug that ought to block based on the above criteria adamw stated, with minor bending... if we don't punt, I'm +1 blocker on that criteria 17:21:43 <adamw> mclasen: another GNOME one, wdyt? 17:22:31 <mclasen> seems like halfline and hansdegoede should get it worked out. In favor of blocking 17:23:36 <bcotton> +1 block 17:23:39 <adamw> ok 17:23:43 <adamw> a decision! an actual decision! 17:23:45 * adamw is proud 17:24:02 <aday> 👏👏👏 17:25:15 <adamw> proposed #agreed 1629409 - AcceptedBlocker (Final) - we consider this to be infringing "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", with gdm treated as an 'application' and "surviving a VT switch" as "basic functionality" 17:25:18 <cmurf> ack 17:25:45 <bcotton> ack 17:25:56 <Southern_Gentlem> ACK 17:26:17 <coremodule> ack 17:27:53 <adamw> #agreed 1629409 - AcceptedBlocker (Final) - we consider this to be infringing "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", with gdm treated as an 'application' and "surviving a VT switch" as "basic functionality" 17:28:09 <adamw> #topic (1630899) unmounting ISO in Nautilus crashes gnome-shell and kills a wayland session 17:28:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630899 17:28:09 <adamw> #info Proposed Blocker, gnome-shell, NEW 17:30:14 <Southern_Gentlem> +1 17:31:15 <bcotton> +1 17:31:51 <cmurf> +1 17:33:12 <adamw> proposed #agreed 1630899 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", unmounting a device seems like 'basic functionality' for nautilus 17:33:21 <adamw> though...it'd be nice if someone else could reproduce this, too... 17:33:23 * adamw hasn't tried yet 17:33:35 <Southern_Gentlem> ack 17:33:50 <cmurf> ack 17:34:37 <coremodule> ack 17:34:54 <adamw> #agreed 1630899 - AcceptedBlocker (Final) - this is accepted as a violation of "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", unmounting a device seems like 'basic functionality' for nautilus 17:35:06 <adamw> #topic (1630943) laptop with lid closed and external monitor can't log in to wayland session 17:35:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630943 17:35:06 <adamw> #info Proposed Blocker, gnome-shell, NEW 17:35:19 <adamw> oh, i guess i should keep pinging mclasen for these 17:35:24 <adamw> as they're all gnome 17:36:19 <cmurf> leaning toward +1 but more info would be nice if it affects a greater range of hardware 17:36:28 <adamw> logical_monitor being null seems to be the problem here, i guess? 17:36:30 <adamw> anyhoo 17:36:36 <mclasen> no input on this from me 17:36:48 <cmurf> yeah actually in this case it's a single display, external - not a dual display 17:36:57 <cmurf> and also it works under X 17:36:58 <adamw> backtrace seems a bit incomplete 17:37:05 <cmurf> and it's apparently a regression from F28? 17:37:16 <adamw> so yeah, it'd be good to see if this reproduces on other laptops and monitors...but does seem worrying 17:37:33 <Southern_Gentlem> +1 punt 17:37:33 <adamw> laptop closed, external monitor connected is a pretty standard setup 17:37:43 <cmurf> yes 17:37:57 <bcotton> +1 punt 17:38:01 <Southern_Gentlem> we need more info 17:38:04 <cmurf> so I'm +1 block, but still want more info 17:40:48 <adamw> i'll vote punt to see how reproducible it is 17:40:51 <adamw> so, that's +3 punt 17:41:19 <adamw> proposed #agreed 1630943 - punt (delay decision) - we think this is potentially a blocker, but would like some more data on how common it is first (i.e. tests with other laptops and monitors) 17:41:22 <cmurf> ack 17:41:29 <Southern_Gentlem> ack 17:43:10 <coremodule> ack 17:43:15 <bcotton> ack 17:44:00 <adamw> #agreed 1630943 - punt (delay decision) - we think this is potentially a blocker, but would like some more data on how common it is first (i.e. tests with other laptops and monitors) 17:47:13 <adamw> #topic (1626862) Broken Fedora/Windows dualboot 17:47:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626862 17:47:13 <adamw> #info Proposed Blocker, grub2, NEW 17:48:27 <cmurf> still not enough info 17:48:29 <cmurf> works for me 17:48:31 <bcotton> doesn't look like we have the new information we wanted last week 17:49:13 <cmurf> it might be useful to head this off by asking pjones if he has any ideas what it might be or how to get more info from GRUB for this particular failure? 17:49:49 * cmurf notes there are frequent user reports on ask.fedora about dual boot problems 17:49:54 <adamw> yeah, by CCing him on the meeting announce i was hoping he might contribute, but i guess he's too busy so far 17:50:05 <adamw> i mean, dual boot's one of those things that's never likely to wokr perfectly. 17:50:13 <cmurf> right 17:50:15 <cmurf> lots of bugs 17:50:19 <Southern_Gentlem> +1 punt 17:50:21 <cmurf> lots of firmware bugs 17:50:46 <bcotton> +1 punt. is there someone we should NEEDINFO? 17:51:02 <cmurf> i think fwupd has helped with this 17:51:25 <cmurf> (helped improved things, that is) 17:51:32 <Southern_Gentlem> i will try to test this tomorrow in a VM 17:52:04 <adamw> bcotton: yeah, we should needinfo pjones 17:52:16 <adamw> and maybe lukas too 17:52:20 <adamw> i'll take a look later 17:52:25 <adamw> or coremodule will 17:54:11 <adamw> proposed #agreed 1626862 - punt (delay decision) - as this bug seems to be system-specific in some way, we need more information to make a decision. we will ask pjones how lruzicka can proceed from here to figure out what the problem is 17:54:23 <adamw> gah 17:54:24 <adamw> patch 17:54:31 <adamw> proposed #agreed 1626862 - punt (delay decision) - as this bug seems to be system-specific in some way, we need more information to make a decision. we will ask pjones how frantisek can proceed from here to figure out what the problem is 17:54:38 <adamw> i do not know why i keep mixing those two up. 17:54:39 <Southern_Gentlem> ack 17:54:43 <cmurf> ack 17:54:54 <bcotton> ack 17:55:48 <adamw> #agreed 1626862 - punt (delay decision) - as this bug seems to be system-specific in some way, we need more information to make a decision. we will ask pjones how frantisek can proceed from here to figure out what the problem is 17:55:57 <adamw> #topic (1631533) dnf and packagekitd can crash when libdnf swdb is locked by another process 17:55:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1631533 17:55:57 <adamw> #info Proposed Blocker, libdnf, NEW 17:56:08 <adamw> i'm not really sure if we need to block on this, but figured it's worth discussing at least 17:56:34 <cmurf> i'm more inclined to block on update components that crash 17:56:37 <adamw> so far I don't *think* it can cause a broken transaction or inconsistent rpm db, it's just an ugly behaviour, but it's possible i'm wrong. 17:56:38 <cmurf> they shouldn't crash 17:56:51 <cmurf> ok 17:57:00 <adamw> (the correct behaviour would be to either exit cleanly or to just wait for the db to become available) 17:57:10 <cmurf> yes 17:57:56 <cmurf> what do dnf/rpm/packagekit folks think? 17:59:40 <adamw> don't have feedback from them yet, besides the 'triaged' marker 18:00:34 <bcotton> does packagekitd restart on its own/via systemd? or does it stay dead until manually restarted? 18:02:15 <cmurf> i think it dies based on the service file 18:02:28 <cmurf> i just killed packagekit on my laptop and it's not restarting 18:04:04 <bcotton> i was hoping you wouldn't say that 18:04:29 <bcotton> that makes me lean +1 block 18:05:05 <adamw> i think gnome-software can start it up again, but i'm not 100% sure of the interactions there. 18:05:14 <cmurf> good point 18:05:16 <cmurf> hold on 18:05:24 <adamw> (there's actually a whole in PK recently where it sort of turns itself off after it hasn't done anything for five minutes) 18:05:29 <adamw> whole thing* 18:05:54 <adamw> but yeah, it's a good point that packagekitd crashing can cause problems for front ends 18:06:15 <adamw> i was mainly focused on reproducing the crash, so i didn't look at what happens to gnome-software or the KDE updater if this happens 18:06:21 <cmurf> yes it does restart packagekitd 18:08:19 <adamw> so, not sure about this one. what do people think? 18:08:46 <cmurf> i would say inclined to +1 block, but actually punt and needinfo 18:09:39 <bcotton> well if the daemons get restarted, then i'm a -0.5 or so. it's a crappy bug, but it seems like somewhat uncommon use case (or not?) and if the daemons restart, it's annoying but doesn't break anything 18:09:48 <cmurf> i just don't like crashes in the update system - unless the stake holders say something like yes, messy, but blocking won't help get us where we need to be 18:09:51 <cmurf> or something like that 18:10:00 <cmurf> or it'll be fixed soon 18:10:20 <cmurf> well just packagekitd is restarted, if dnf is crashing that's still not cool 18:10:22 <adamw> bcotton: i don't think the use case is very uncommon 18:10:46 <adamw> bcotton: it's quite easy to do a 'dnf (something)' while gnome-software or the kde updater are doing something at the same time... 18:10:50 <cmurf> lotsa people go back and forth between dnf and PK/gnome-software 18:10:53 <adamw> or other variations on the theme 18:11:02 <cmurf> and that too 18:11:16 <bcotton> yeah, that makes sense 18:11:26 <adamw> there are also apparently people who knowingly run multiple dnf's at once because they know it has locking and figure it should be fine (though i didn't know that until recently) 18:11:39 <bcotton> huh. that one's new to me :-) 18:11:45 <adamw> i actually found this bug from george goffe's report in another bug, that seems to be what he does 18:12:13 <adamw> but, i'd be ok with -1 so long as nothing's actually getting *damaged*, i guess. 18:12:25 <adamw> if we find out that this can actually cause a permanent issue, i'd wanna revisit it. 18:12:41 <cmurf> ok i'll go along with that for now 18:13:40 <cmurf> sidenote: I'm seeing updates in triplicate listed in gnome-software when clicking on the detail view 18:13:40 <adamw> any other thouhgts? 18:13:51 <bcotton> i can get behind that, adamw 18:15:17 <adamw> proposed #agreed 1631533 - RejectedBlocker (Final) - for now, this doesn't seem to actually cause any permanent problems or really impair the system's ability to install software, it's just a transient ugly error. if we find it can cause permanent issues we'll revisit 18:15:36 <bcotton> ack 18:15:44 <cmurf> ack 18:18:16 <adamw> #agreed 1631533 - RejectedBlocker (Final) - for now, this doesn't seem to actually cause any permanent problems or really impair the system's ability to install software, it's just a transient ugly error. if we find it can cause permanent issues we'll revisit 18:18:38 <adamw> #topic (1630367) gnome session crashes after a VT switch (on X11 with multiple monitors) 18:18:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1630367 18:18:38 <adamw> #info Proposed Blocker, xorg-x11-server, NEW 18:19:39 <cmurf> I'm +1 blocker for the same logic/reasoning as the other VT bug 18:20:08 <bcotton> +1, ditto 18:20:29 <Southern_Gentlem> +1 18:20:47 <adamw> ehh...if it's gnome plus x11 plus multi monitors only... 18:21:02 <adamw> that's getting into pretty specific territory 18:22:05 <bcotton> hm, that's a good point 18:22:06 <adamw> i'm a bit -1y at that point 18:23:00 <bcotton> gnome with multi monitors seems like a pretty common setup these days, though 18:23:19 <cmurf> yeah i'd be in fits if I couldn't reliably use multiple displays 18:23:31 <Southern_Gentlem> and i have seen people in f28 having issues with this as well 18:23:45 <cmurf> although we don't have an explicit criterion for multiple displays 18:24:00 <adamw> sure, but wayland is default 18:24:00 <cmurf> i don't know that there must be for this to be a blocker bug though 18:24:11 <cmurf> that is true 18:24:14 <adamw> by the time you're talking multiple monitors *and* switching to x11...do we really block the relase for that? 18:24:15 <cmurf> the other one was wayland 18:24:18 <cmurf> this one is X 18:24:34 <Southern_Gentlem> -1 block 18:24:36 <bcotton> okay, adamw has convinced me. i'm -1 now 18:24:38 <adamw> i mean, it sucks if you need to use X11 for some reason and you have multiple monitors, sure 18:24:42 <cmurf> there are still people who can only run X 18:24:45 <cmurf> due to hardware 18:24:49 <cmurf> in particular multiple displays 18:25:08 <Southern_Gentlem> now if this was on kde i would block 18:25:09 <cmurf> e.g. on my now dead mac, which is dual headed GPU, it is ONLY X when the radeon GPU is in dual display mode 18:25:23 <adamw> that sounds weird. 18:25:31 <cmurf> *shrug* the way it goes 18:25:35 <adamw> mclasen: any thoughts on this one? 18:26:26 <mclasen> no, its between jadahl and ofourdan 18:26:28 <cmurf> maybe I'm wrong but I think Wayland is best effort and still improving on the multiple display use case; whereas on X it's supposed to work 18:26:51 <cmurf> wayland is rock solid for me on i915 and dual displays 18:29:04 <adamw> mclasen: thoughts on the blockeriness at all? the x vs. wayland question? 18:30:10 <mclasen> we ship wayland by default, so if it is a wayland issue its more blockerworthy than if not 18:30:21 <adamw> it's x11 only, per the report 18:31:08 <cmurf> I can't tell from the report if they're getting the automatic fallback to X though 18:31:40 <adamw> given that the report says "it works on wayland", i'm gonna say not. 18:31:49 <cmurf> fair enough 18:31:54 <adamw> and "This does not happen on Wayland session at all." 18:31:59 <adamw> so...i stand by -1 for now 18:32:02 <adamw> we can always revisit later 18:33:03 <cmurf> no concensus, punt and need more testing to see how widespread it is? 18:33:05 <adamw> last call for votes? 18:33:16 <adamw> everyone revote, if we have enough votes for anything we'll do that, otherwise punt 18:34:06 <bcotton> -1 blocker 18:35:43 <adamw> Southern_Gentlem: cmurf: vote? 18:36:21 <Southern_Gentlem> -1 18:36:52 <mclasen> ah, I misread about x vs wayland 18:37:30 <adamw> so, we have -3 18:37:53 <cmurf> +0 :P 18:38:35 <cmurf> you've brought me back from +1 but I can't go to -1 with available info 18:38:51 <adamw> proposed #agreed 1630367 - RejectedBlocker (Final) - as this is specific to X11 and multiple monitors, it seems like it won't be commonly-enough encountered to constitute a blocker. we will revisit if new information emerges 18:38:55 <cmurf> ack 18:39:14 <Southern_Gentlem> ack 18:40:21 <cmurf> proposal: a super abbreviated accepted blocker review? I gotta goooo 18:40:42 <adamw> that was the last proposed blocker 18:40:54 <adamw> so yeah, let's blow through accepted quickly 18:40:59 <adamw> cmurf: any particular one you wanted to chime in on? 18:41:27 <Southern_Gentlem> yeah i need to run as well 18:41:33 <adamw> #topic End of proposed Final blockers 18:41:39 <adamw> #info that's all the proposed Final blockers 18:41:45 <adamw> #info moving onto accepted blockers 18:41:52 <adamw> (i used a #topic there as it's clearer in the logs) 18:42:24 <adamw> eh, if we're losing everyone, let's call it here 18:42:30 <cmurf> yeah that's fine 18:42:31 <bcotton> works for me 18:42:31 <adamw> i'll go through the accepted blockers and ping where appropriate 18:42:47 <adamw> #info folks are out of time, so we will skip the accepted blocker review for this week, adamw will look through them after the meeting 18:42:53 <adamw> #topic Open floor 18:42:56 <adamw> any other business? 18:43:04 <cmurf> not for me 18:43:11 * bcotton has nothing 18:43:46 <adamw> alrighty, thanks for coming then, folks 18:44:28 <adamw> #endmeeting