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