16:00:04 <adamw> #startmeeting F31-blocker-review
16:00:04 <zodbot> Meeting started Mon Sep 30 16:00:04 2019 UTC.
16:00:04 <zodbot> This meeting is logged and archived in a public location.
16:00:04 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:00:04 <adamw> #meetingname F31-blocker-review
16:00:04 <adamw> #topic Roll Call
16:00:04 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:00:05 <bcotton> .hello2
16:00:06 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:00:14 <adamw> ahoyhoy, how's everyone doing today?
16:00:22 * bcotton : now without explosions
16:01:02 <frantisekz> .hello2
16:01:03 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:05 <pwhalen> .hello2
16:01:09 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:01:16 <tablepc> If I can survive an exploding PC you can survive a zodbot explosion
16:01:22 <tablepc> .hello2
16:01:24 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
16:01:34 * coremodule says hello.
16:01:37 <coremodule> .hello2
16:01:39 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:01:43 <adamw> i preferred the old-school bcotton with explosions
16:01:46 <adamw> this new one's far too pc
16:01:57 <bcotton> some people are just never happy
16:02:32 <kparal> .hello2
16:02:33 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:02:38 <cmurf> .hello
16:02:40 <zodbot> cmurf: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:02:47 <cmurf> .hello chrismurphy
16:02:48 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:05:11 <Southern_Gentlem> .hello jbwillia
16:05:13 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:06:26 <adamw> #chair coremodule kparal
16:06:26 <zodbot> Current chairs: adamw coremodule kparal
16:06:36 <adamw> impending boilerplate alert!
16:06:37 <adamw> #topic Introduction
16:06:37 <adamw> Why are we here?
16:06:37 <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:06:37 <adamw> #info We'll be following the process outlined at:
16:06:40 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:40 <adamw> #info The bugs up for review today are available at:
16:06:42 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:44 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:46 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:49 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:06:50 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:06:57 <adamw> #info for F31 Final, we have:
16:06:57 <adamw> #info 12 Proposed Blockers
16:06:57 <adamw> #info 7 Accepted Blockers
16:07:01 <adamw> #info 3 Proposed Freeze Exceptions
16:07:13 <adamw> who wants to secretarialize?
16:07:37 <coremodule> me
16:07:39 <coremodule> i want
16:07:41 <coremodule> give
16:07:43 <coremodule> i take
16:08:10 <bcotton> no volunteers?
16:08:19 <kparal> nobody ever speaks up
16:08:30 <coremodule> me me me me me pick i do
16:09:16 <adamw> anyone? anyone?
16:09:21 <adamw> fine, i guess it'll have to be coremodule, jeez
16:09:26 <adamw> #info coremodule will secretarialize
16:09:31 <coremodule> Whoa, I just looked at the blocker list, it's bigger than it was last I looked, I don't want it anymore.
16:09:36 <adamw> TOO LATE
16:09:42 <coremodule> I think bcotton or kparal might like to do it.
16:09:45 <adamw> #info we'll start with proposed Final blockers
16:09:47 <lruzicka> .hello2
16:09:48 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:09:54 <adamw> #topic (1755813) bios boot partition can't be created at the disk beginning, if a partition already exists in the middle of the disk
16:09:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1755813
16:09:54 <adamw> #info Proposed Blocker, blivet-gui, ASSIGNED
16:10:15 <kparal> lruzicka: that's a great way to spend your PTO, with 4 hours of meetings, right? :)
16:10:17 <frantisekz> +1 , this is going to break MBR installations
16:10:32 <adamw> i am a sad +1 to this, and i invoke the "i told you so" policy for how silly it is that we have two custom partitioning systems :P
16:10:33 <lruzicka> +1
16:10:50 <Southern_Gentlem> +1
16:11:16 <pwhalen> +1
16:11:17 <kparal> +1
16:11:24 <cmurf> adamw you aren't the only one who gets to say "toldja"
16:11:44 <frantisekz> adamw, you know me, I'd drop BIOS support if I was to decide... :) :D
16:11:46 <kparal> well we have a blocker proposed even for the other custom partitioning mode, so they're even :)
16:11:50 <bcotton> +1 :-(
16:11:55 <adamw> heh
16:12:09 <frantisekz> those ancient technologies...
16:12:37 <kparal> (this is not just about biosboot partition, but any partition)
16:12:42 <adamw> proposed #agreed 1755813 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" for installs that require a BIOS boot partition, done via 'advanced custom'
16:13:02 <cmurf> i'm confused
16:13:07 <cmurf> BIOS Boot is a GPT only thing
16:13:12 <adamw> ok, i guess we can edit that a bit
16:13:12 <lruzicka> ack
16:13:22 <adamw> proposed #agreed 1755813 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" for installs done via 'advanced custom'
16:13:36 <kparal> cmurf: hum? I thought the purpose of biosboot is to have enough space for MBR
16:13:45 <cmurf> no
16:13:45 <adamw> kparal: no, cmurf is right
16:13:52 <Southern_Gentlem> ack
16:13:53 <adamw> bios boot partition is needed when doing a BIOS install to a GPT-labelled disk
16:14:09 <adamw> because with GPT there is no space between the disk label and the first partition for the bootloader to use
16:14:19 <cmurf> BIOS Boot is the GPT equivalent of the MBR gap which is the space between the first sector of the drive and the first sector for the first partition
16:14:24 <kparal> alright
16:14:33 <cmurf> both are typically 1MiB by default
16:14:44 <lruzicka> ack
16:14:44 <frantisekz> okay, adding this to today I learned for me
16:14:45 <kparal> the same bug occurs regardless of GPT/MBR disk table
16:14:53 <adamw> so BIOS boot partition is necessary if you're installing to a pre-existing GPT labelled disk and not fully reformatting it, or installing to a 2TB+ disk
16:14:56 <cmurf> ok
16:15:00 <adamw> (because we have to use GPT labelling for 2TB+ disks)
16:15:09 <kparal> it also occurs for any partition filesystem, just with biosboot I thought it's easy to demonstrate a big impact
16:15:17 <adamw> but as kparal says, this is actually a blocker bug even ignoring the BIOS boot wrinkle
16:15:29 <frantisekz> soooo, ack
16:15:30 <cmurf> so the bug might be allowing BIOS Boot to be created for MBR disks without a discreet error but I leave error handling up to Anaconda
16:15:41 <adamw> it's *worse* for the BIOS boot partition case as it means the system doesn't boot, but even just considering the criterion for a 'regular' install, you should be able to put partitions in that space but you can't.
16:15:53 <kparal> right
16:16:27 <kparal> I just expected some fudging in that case, that's why I highlighted biosboot :)
16:16:33 <adamw> a cunning plan
16:16:43 <adamw> i see three acks, so let's proceed
16:16:46 <kparal> that's experience talking
16:16:51 <kparal> ack
16:16:57 <adamw> proposed #agreed 1755813 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" for installs done via 'advanced custom' partitioning
16:17:12 <adamw> #topic (1751103) [abrt] dnf: configure_upgrade(): system_upgrade.py:410:configure_upgrade:TypeError: argument of type 'NoneType' is not iterable
16:17:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751103
16:17:12 <adamw> #info Proposed Blocker, dnf, ON_QA
16:17:17 <frantisekz> adamw
16:17:24 <frantisekz> you have proposed there
16:17:24 <adamw> doh
16:17:25 <adamw> thanks
16:17:27 <adamw> #undo
16:17:27 <zodbot> Removing item from minutes: INFO by adamw at 16:17:12 : Proposed Blocker, dnf, ON_QA
16:17:30 <adamw> #undo
16:17:30 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f93a1c3abd0>
16:17:32 <adamw> #undo
16:17:32 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f93a1c3a990>
16:17:40 <adamw> #agreed 1755813 - AcceptedBlocker (Final) - this is accepted as a violation of "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration" for installs done via 'advanced custom' partitioning
16:17:48 <adamw> #topic (1751103) [abrt] dnf: configure_upgrade(): system_upgrade.py:410:configure_upgrade:TypeError: argument of type 'NoneType' is not iterable
16:17:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751103
16:17:49 <adamw> #info Proposed Blocker, dnf, ON_QA
16:17:52 <adamw> there we go!
16:18:31 <frantisekz> I didn't have time to look into the reposiotry files, but that shouldn't be blocker if user has to have some 3rd party repos
16:18:33 <kparal> so, the fix seems to target some invalid dnf upgrade steps, but it's unknown if it fixes the problem in gnome-software
16:18:43 <frantisekz> or did I miss anything?
16:18:47 <kparal> and I still don't know how people managed to trigger it with gnome-software
16:18:49 <adamw> this seems...slightly vague
16:19:04 <adamw> what is "the problem in gnome software"?
16:19:32 <adamw> oh, 1746346 ?
16:20:02 <kparal> adamw: no, talking about https://bugzilla.redhat.com/show_bug.cgi?id=1751103#c17
16:20:23 <kparal> it says this exact traceback was somehow trigger from gnome-software
16:20:45 <kparal> but Pavla mentions only invalid dnf system-upgrade invocation in https://bugzilla.redhat.com/show_bug.cgi?id=1751103#c20
16:20:48 <adamw> actually
16:21:02 <bcotton> -1 blocker as it doesn't affect the default repos
16:21:12 <adamw> we have this same traceback in three bugs now
16:21:21 <kparal> bcotton: we don't actually know to which repos it is related
16:21:33 <adamw> 1751103, 1749868 and 1746346
16:21:43 <frantisekz> but, all the reporters had some third party non default repos?
16:21:54 <adamw> no, i don't think so
16:22:12 <kparal> hmm, comment 0 shows a copr error where this traceback occurred. I didn't notice that before
16:22:30 <bcotton> our default repos don't disable gpgcheck
16:22:51 <adamw> this isn't about what the state of gpgcheck is in some specific repo
16:23:08 <adamw> it's actually about dnf reading in a state file and not finding a value at all
16:23:23 <adamw> at which point it sets the variable to None, but later code expects it to be an iterable
16:23:33 <adamw> i explained it in https://bugzilla.redhat.com/show_bug.cgi?id=1749868#c22
16:23:41 <bcotton> ooh, interesting
16:24:08 <kparal> so how does gnome-software come into the picture?
16:24:54 <adamw> i'm not sure, but it seems to be involved *somehow*
16:24:58 <bcotton> but regardless of the mechanics, has this been observed with *only* our default repos? i can't tell
16:25:03 <adamw> wait, isn't there another bug about this somewhere...
16:25:10 <lruzicka> that can be a coincidence
16:25:23 <adamw> bcotton: one way to produce it is simply to run 'dnf system-upgrade reboot' *without* doing a 'dnf system-upgrade download' first
16:25:31 <adamw> it doesn't matter what repos you have if you do that
16:25:54 <lruzicka> which is not a supported process, is it?
16:25:58 <kparal> somehow I missed all the updates from bug 1749868. sigh.
16:26:27 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1756105 has more on the gnome-software interaction
16:26:43 <adamw> specifically https://bugzilla.redhat.com/show_bug.cgi?id=1756105#c5
16:27:12 <kparal> I guess we can agree we need the fix stable. Then we'll see if people can still hit all those issues
16:27:52 <adamw> it seems like it can happen just from trying to do a regular GNOME Software update...so on that basis i'd be +1 blocker
16:28:13 <frantisekz> okay, +1
16:28:27 <Son_Goku> +1
16:28:29 <frantisekz> I'll try to trigger the issue / confirm the fix
16:28:31 <bcotton> +1 blocker. i'm not fully convinced but it there's a potential fix in testing already, so....
16:28:48 <kparal> wait, which bug are we now voting on?
16:28:53 <kparal> because 1756105 seems most critical
16:29:01 <kparal> or are we merging all together?
16:29:28 <kparal> ah, it's already a dupe
16:29:56 <kparal> alright, in that case +1
16:30:05 <lruzicka> +1
16:30:14 <pwhalen> +1 blocker
16:31:25 <Southern_Gentlem> +1
16:32:00 <adamw> proposed #agreed 1751103 - AcceptedBlocker (Final) - as reported in one of the dupes (1756105) it seems this can be triggered simply by running a normal GNOME update, causing the update to fail silently, so this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package
16:32:00 <adamw> manager). This includes downloading of packages to be installed/updated."
16:32:02 <adamw> doh
16:32:07 <adamw> proposed #agreed 1751103 - AcceptedBlocker (Final) - as reported in one of the dupes (1756105) it seems this can be triggered simply by running a normal GNOME update, causing the update to fail silently, so this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package
16:32:07 <adamw> manager)..."
16:32:19 <adamw> proposed #agreed 1751103 - AcceptedBlocker (Final) - as reported in a dupe (1756105) it seems this can be triggered simply by running a normal GNOME update, causing the update to fail silently, so this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package
16:32:20 <adamw> manager)..."
16:32:21 <lruzicka> yay
16:32:22 <frantisekz> :D
16:32:29 <adamw> oh fer
16:32:39 <adamw> proposed #agreed 1751103 - AcceptedBlocker (Final) - as reported in dupe 1756105 it seems this can be triggered simply by running a normal GNOME update, causing the update to fail silently, so this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)..."
16:32:42 <frantisekz> it's like writing tweets and trying to fit in... :D
16:32:43 <adamw> THERE we go
16:32:44 <frantisekz> ack
16:32:47 <lruzicka> ack
16:32:48 <adamw> only everyone gets to watch!
16:33:02 <bcotton> ack
16:33:09 <pwhalen> ack
16:34:01 <adamw> #agreed 1751103 - AcceptedBlocker (Final) - as reported in dupe 1756105 it seems this can be triggered simply by running a normal GNOME update, causing the update to fail silently, so this is accepted as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)..."
16:34:12 <adamw> #topic (1757089) /usr/lib64/samba/pdb/ipasam.so: undefined symbol: unixid_from_gid, version SAMBA_PASSDB_0.2.0
16:34:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1757089
16:34:12 <adamw> #info Proposed Blocker, freeipa, ASSIGNED
16:34:28 <adamw> so, this is basically "freeipa breaks on upgrade if Active Directory trust is configured"
16:34:56 <adamw> i'm gonna say -1 blocker +1 FE purely because AD trust is outside the scope of the criteria, and the rule is we block on upgrade bugs that break stuff within the criteria
16:35:05 <adamw> however
16:35:29 <adamw> there's an argument that this is a conditional violation of the criteria because if you happen to have AD trust configured in your FreeIPA install, all the FreeIPA features that *are* in the criteria break on upgrade
16:35:41 <adamw> so, i mean, i guess you could go +1 on that basis. hm
16:35:56 <bcotton> is AD trust the default?
16:35:59 <adamw> no
16:36:04 <lruzicka> yeah, i would, could be nasty
16:36:11 <frantisekz> I'd go with -1 then
16:36:17 <adamw> i guess it's a bit like installing F30 Workstation, turning on some non-default feature, upgrading, and GNOME stops working entirely
16:36:24 <adamw> but if you don't turn on that non-default feature the upgrade is fine
16:36:32 <adamw> it's a bit different from *only* the non-default feature breaking, i guess
16:36:52 <bcotton> -1 blocker, +1 FE. i'm hesitant to give blocker status for non-default configurations because slippery slope, etc
16:37:06 <frantisekz> -1 B / +1 FE & CommongBugs
16:37:11 <frantisekz> CommonBugs
16:37:19 <pwhalen> -1 blocker, +1 FE
16:37:44 <lruzicka> but it seems to me like switching on some distant filesystem support and then being ferked up
16:38:24 <lruzicka> non-default but plausible
16:38:52 <lruzicka> but with my +1 i Stand alone
16:38:59 <adamw> proposed #agreed 1757089 - RejectedBlocker (Final), AcceptedFreezeException (Final) - this is rejected as a blocker as it breaks only if a non-default feature not in the criteria (AD trust) is enabled, but accepted as a freeze exception to help minimize the number of affected upgrades
16:39:10 <frantisekz> ack
16:39:16 <lruzicka> ack
16:39:26 <pwhalen> ack
16:39:30 <adamw> #agreed 1757089 - RejectedBlocker (Final), AcceptedFreezeException (Final) - this is rejected as a blocker as it breaks only if a non-default feature not in the criteria (AD trust) is enabled, but accepted as a freeze exception to help minimize the number of affected upgrades
16:39:40 <adamw> #topic (1754630) Automatic workspaces are seriously broken
16:39:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1754630
16:39:40 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:39:58 <lruzicka> +1
16:40:48 <adamw> yeah...probably +1
16:41:00 <adamw> i'm generally inclined to +1 any vaguely reproducible shell crasher, on the 'data loss' principle
16:41:27 <frantisekz> +1
16:41:58 <frantisekz> (if we had xorg by default, data loss wouldn't apply to most of the shell crashers, but that's for another discussion)
16:42:00 <kparal> I'm concerned here about the crash than the workspaces/apps behaving wrongly
16:42:17 <kparal> *more about
16:42:41 <kparal> we don't have a traceback yet, though
16:42:55 <kparal> and it's hard to trigger it, at least for me
16:43:02 <frantisekz> there seems to be one kparal
16:43:02 <frantisekz> https://bugzilla.redhat.com/show_bug.cgi?id=1754630#c12
16:43:12 <frantisekz> but i didn't check the contents...
16:43:23 <kparal> oh great
16:44:18 <bcotton> +1 blocker
16:44:35 <lruzicka> and we have a winner
16:44:47 <adamw> proposed #agreed 1754630 - AcceptedBlocker (Final) - this is accepted with reference to both "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and "All known bugs that can cause corruption of user data must be fixed or documented at Common F31 bugs" (as any Shell crash on Wayland can cause data loss/corruption)
16:44:59 <lruzicka> ack
16:45:00 <kparal> ack
16:45:00 <pwhalen> +1/ack
16:45:06 <bcotton> ack
16:45:16 <frantisekz> (just for general information, there was some issue with getting backtraces from gnome-shell/mutter, but was fixed recently https://bodhi.fedoraproject.org/updates/FEDORA-2019-94130905d5 )
16:45:19 <frantisekz> ack
16:46:41 <adamw> #agreed 1754630 - AcceptedBlocker (Final) - this is accepted with reference to both "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and "All known bugs that can cause corruption of user data must be fixed or documented at Common F31 bugs" (as any Shell crash on Wayland can cause data loss/corruption)
16:46:47 <adamw> #topic (1755898) numlock handling is seriously broken
16:46:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1755898
16:46:48 <adamw> #info Proposed Blocker, gnome-shell, NEW
16:47:05 <adamw> -1 as only dummies use the numpad :P
16:47:30 <frantisekz> :D
16:47:50 <adamw> i'm a bit on the fence here really
16:47:53 <frantisekz> yeah, I am not sure about this one, probably weak -1
16:48:15 <kparal> I'm not sure either, that's why I proposed it
16:48:16 <frantisekz> because, workaround is pretty simple... turn off your numlock and it's gonna work
16:48:17 <lruzicka> not serious but annoying +1
16:48:23 <kparal> frantisekz: not really
16:48:27 <adamw> definitely commonbugs and +1 FE
16:48:36 <kparal> e.g. with VMs you can't just simply make things work
16:48:39 <adamw> there's an actual workaround posted in one of the upstream bugs
16:48:47 <adamw> (dunno if itworks for kparal)
16:48:56 <kparal> adamw: where is it?
16:49:00 <bcotton> " GNOME Shell overview has inverted numlock status from the rest of the system" strikes me as all elements of the dfault panel must function correctly, etc
16:49:20 <lruzicka> +1, bcotton
16:49:26 <frantisekz> i wouldn't mix vms and numlock, I am on the fence just with that, I would be -1 for combining vms, numlock and blocking on base of that
16:49:46 <kparal> adamw: found it https://gitlab.gnome.org/GNOME/mutter/issues/714#note_614150
16:49:50 <adamw> i wouldn't call this an element of the panel myself
16:49:59 <adamw> there's no numlock state indicator there or anything
16:50:06 <bcotton> i'm a weak +1 on this based on the fact that this is the sort of thing that would get us ripped in reviews (which is not a criterion, but...)
16:50:08 <adamw> that's a handy criterion but we can only stretch it *so* far :P
16:50:11 <kparal> adamw: no, but the keys don't work :)
16:50:21 <lruzicka> adamw, you are cunning :)
16:50:33 <bcotton> but i'm definitely +1 FE & commonbugs if we don't block on it
16:50:44 <frantisekz> yeah, +1 FE/CB
16:50:55 <tablepc> I use numlock all the time and prefer it to work
16:50:56 <adamw> if we want to consider taking this my preference would be to write an actual criterion for it
16:51:01 <adamw> we don't have to criteria judo *everything* :P
16:51:02 <lruzicka> so am I, but I still support +1b
16:51:17 <adamw> it would be fairly simple to just write a requirement that all or some key modifier toggles work
16:51:29 <pwhalen> same as bcotton I'm a weak +1, but definite +1FE
16:51:42 <lruzicka> cant we do it?
16:51:53 <lruzicka> in this release frame?
16:52:07 <adamw> how about this: we accept as FE and punt on blocker to give someone who Really Cares A Lot a chance to propose a criterion for this (and maybe desktop team to give their opinion)
16:52:11 <adamw> lruzicka: yeah, we can, there's precedent for that
16:52:25 <frantisekz> okay, I can live with that
16:52:29 <adamw> if we come across something we strongly believe should be a blocker we can agree to add a criterion
16:52:39 <adamw> viking_ice used to hate it, but the rest of us did it anyway :P
16:53:08 <bcotton> adamw: i can live with that. you can action me to propose the criterion
16:53:40 <adamw> #action bcotton and/or kparal and/or anyone else who feels strongly to propose a criterion for this
16:53:47 <kparal> I'm overall slight +1 to approving that criterion and this being a blocker
16:54:42 <adamw> proposed #agreed 1755898 - punt (delay decision) for blocker status, AcceptedFreezeException (Final) - there's some support for blocking on this but it really doesn't seem to violate any current criterion; we agreed to allow time to propose and discuss a new criterion. In the mean time it's accepted as an FE issue as a prominent bug that can't be fixed fully with an update
16:54:52 <frantisekz> ack
16:54:53 <bcotton> ack
16:54:56 <kparal> ack
16:55:08 <lruzicka> ack
16:55:20 <Southern_Gentlem> ack
16:55:24 <pwhalen> ack
16:55:25 <lruzicka> so Who is going to write it?
16:55:38 * bcotton will
16:55:44 <kparal> bcotton++
16:55:44 <zodbot> kparal: Karma for bcotton changed to 22 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:55:45 <adamw> #agreed 1755898 - punt (delay decision) for blocker status, AcceptedFreezeException (Final) - there's some support for blocking on this but it really doesn't seem to violate any current criterion; we agreed to allow time to propose and discuss a new criterion. In the mean time it's accepted as an FE issue as a prominent bug that can't be fixed fully with an update
16:56:02 <adamw> #topic (1749868) GNOME Software doesn't prepare offline updates
16:56:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1749868
16:56:02 <adamw> #info Proposed Blocker, gnome-software, NEW
16:56:10 <adamw> we're *still* waiting on the dnf rollback here I think :
16:56:14 <adamw> :/
16:56:21 <frantisekz> huh, for the third time this rolls out to the meeting?
16:56:21 <lruzicka> I only have two more battery percent and no outlet on train...
16:56:55 <kparal> lruzicka: enjoy the digital dark... :)
16:56:57 <lruzicka> you did not want to Block on this one
16:57:06 <bcotton> yeah, this seems to be blocked on bz#1752249
16:57:18 <lruzicka> so it is time to let it go?
16:57:57 <adamw> it keeps rolling because we're waiting to check on status after the dnf default is rolled back
16:58:03 <adamw> as long as that doesn't happen we kinda have to keep this around
16:58:09 <kparal> I think this is not worth blocking on right now
16:58:17 <adamw> we could just take it off the list for now
16:58:26 <frantisekz> yep, so, -1 ?
16:58:28 <adamw> and say to repropose it if it turns out to still be a big issue after the dnf default changes
16:58:29 <bcotton> -1 blocker, +1 set it as blocked by 1752249 and once that happens if this is still an issue we re-evaluate
16:58:30 <kparal> also, I can't even verify it after the dnf update is stable
16:58:36 <kparal> because we modified the repos before
16:58:42 <lruzicka> +1 to get rid of it
16:58:50 <kparal> and at least my reproducer is very narrow and doesn't allow to tinker with repos
17:00:20 <adamw> proposed #agreed 1749868 - RejectedBlocker (Final) - we are still waiting to check the status of this with the dnf default changed back, but to avoid it clogging up the list we're going to assume for now that it'll be fine once that change happens; if it turns out still to be a problem it can be re-proposed
17:00:27 <bcotton> ack
17:00:32 <frantisekz> ack
17:00:35 <pwhalen> ack
17:00:50 <coremodule> ack
17:00:50 <bcotton> i'll nudge the dnf team about it in their wednesday morning meeting
17:01:12 <lruzicka> ack
17:01:19 <adamw> #agreed 1749868 - RejectedBlocker (Final) - we are still waiting to check the status of this with the dnf default changed back, but to avoid it clogging up the list we're going to assume for now that it'll be fine once that change happens; if it turns out still to be a problem it can be re-proposed
17:01:22 <adamw> i just poked the bug too
17:01:37 <adamw> #topic (1703700) Newer kernels do not boot and have invalid grub.cfg entries
17:01:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1703700
17:01:37 <adamw> #info Proposed Blocker, grub2, NEW
17:01:50 <adamw> we should edit the topic for this to refer to xen, because...that's what it's about, xen guest installs
17:01:55 <adamw> they seem to have issues ever since the bls stuff landed
17:02:14 <adamw> we don't exactly seem to have a fully clear understanding of the issue yet, though
17:03:13 <kparal> so if this is just xen, we care whether this affects just ec2, right?
17:03:31 <adamw> well...not necessarily, since we didn't complete that criterion change yet
17:03:39 <adamw> but we could hold that we clearly *intend* to do so, i guess
17:03:56 <frantisekz> so, punt?
17:04:03 <lruzicka> punt
17:05:25 <coremodule> punt for now, wait for criteria to officially change, then reconvene on this
17:05:49 <adamw> well
17:06:05 <adamw> for now i wasn't really going to push the criteria change as it's awkward doing them in the middle of release processe
17:06:05 <adamw> s
17:06:13 <adamw> but i guess if it affects this bug, we might want to push it
17:06:38 <adamw> it's a bit complex though as it involves not just changing the criterion but the validation pages and test instructions
17:06:56 <lruzicka> must quit for energy saving reasons, sorry about that.
17:07:03 <adamw> no probs, cya lruzicka
17:08:12 <adamw> i guess it might be good for another person to try and reproduce this cleanly...get an f29 or f30 xen guest install working cleanly, then fiddle around with updating it...
17:09:58 <coremodule> I can try it out
17:10:43 <coremodule> I'll try to reproduce the issue from comment 1
17:11:58 <adamw> proposed #agreed 1703700 - punt (delay decision) - the details of the issue here are not yet entirely clear so it's hard to decide if it's a blocker, also we're not sure yet if we intend to complete the criterion change to block only on ec2 rather than all xen guest functionality
17:12:16 <frantisekz> ack
17:12:32 <coremodule> ack
17:13:01 <bcotton> ack
17:13:11 <pwhalen> ack
17:14:17 <adamw> #agreed 1703700 - punt (delay decision) - the details of the issue here are not yet entirely clear so it's hard to decide if it's a blocker, also we're not sure yet if we intend to complete the criterion change to block only on ec2 rather than all xen guest functionality
17:14:22 <adamw> #topic (1752961) After upgrading to Fedora 31 got a kernel panic loading 5.3.0 kernel
17:14:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1752961
17:14:22 <adamw> #info Proposed Blocker, kernel, NEW
17:14:27 <adamw> this has come up in kernel test week testing
17:14:39 <adamw> seems on some systems boot fails with a TPM-related error sometimes, other times works fine
17:14:59 <adamw> on the one hand if 'just try again' makes it work it's not *that* bad, on the other hand failing to boot always looks bad...
17:15:41 <kparal> I guess we'll need a better estimate of how much hardware is affected
17:15:48 <frantisekz> how do we stand with criterions and TPM
17:16:07 <frantisekz> or we can use that it's failing to boot on huge enough percentage of HW?
17:16:08 <kparal> also, what is the default TPM state? say in Thinkpads?
17:16:25 <kparal> frantisekz: yes, the latter
17:16:30 <frantisekz> i think it was off on mine
17:16:32 <frantisekz> but not sure
17:17:14 <frantisekz> i'd incline to -1 if it's off by default
17:18:07 <adamw> i'm definitely +1 FE at least
17:18:09 <adamw> really hard to judge blocker
17:18:14 <frantisekz> yeah, +1 FE for sure
17:18:24 <adamw> maybe we punt on blocker and hope the fix gets downstream before next week :P
17:18:47 <bcotton> +1 punt
17:18:58 <pwhalen> +1 punt
17:19:00 <frantisekz> okay, +1 punt
17:21:10 <adamw> proposed #agreed 1752961 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - this is clearly worthy of an FE, we're not sure if it will affect enough systems to qualify as a blocker yet
17:21:13 <tablepc> TPM is disabled on my test machine, but I haven't seen the bug either
17:21:23 <frantisekz> ack
17:21:48 <pwhalen> ack
17:21:48 <bcotton> ack
17:21:53 <coremodule> ack
17:21:56 <kparal> ack
17:23:14 <adamw> #agreed 1752961 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - this is clearly worthy of an FE, we're not sure if it will affect enough systems to qualify as a blocker yet
17:23:19 <adamw> #topic (1751646) Images to clipboard don't work, clipboard doesn't contain any data
17:23:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751646
17:23:20 <adamw> #info Proposed Blocker, mutter, NEW
17:24:22 <kparal> I haven't tested it personally
17:24:32 <coremodule> Hmmm...
17:24:33 <frantisekz> hmm, I am not really sure here
17:24:34 <kparal> but going from the report, having a clipboard non-functional for images is pretty bad
17:24:47 <kparal> this is not just screenshots they say
17:25:04 <kparal> "For example try to copy an image in eog or epiphany and paste it into Gimp. That doesn't seem to work at all for me."
17:25:16 <kparal> can somebody quickly try in their F31? I'm still on F30
17:25:23 <adamw> sure...
17:25:30 <frantisekz> I don't think I use clipboard too often
17:25:32 <frantisekz> for images
17:25:54 <adamw> just did it and it worked
17:26:04 <adamw> wonder if this could be like the other clipboard bug though? your 'text wiped from clipboard' bug?
17:26:05 <frantisekz> yeah, worked fine
17:26:11 <kparal> me neither, but if you work with gimp or inkscape every day, you might be of a different opinion on this bug
17:26:48 <kparal> ok, in that case I'd say punt and ask for more details, or reject and ask to repropose if they can find something that affects everyone
17:26:56 <frantisekz> yeah, let's punt
17:27:02 <kparal> adamw: it could be my VM bug, yes
17:27:45 <Son_Goku> I gotta go guys
17:27:58 <Son_Goku> ttyl :)
17:28:07 <adamw> https://gitlab.gnome.org/GNOME/mutter/issues/789 has more detailed reproduction steps
17:28:36 <adamw> "One oddity: the issue only presents itself after copying text from a native wayland application."
17:28:54 <adamw> it seems the bug happens if you try to put image data in the clipboard when it currently contains text copied from a native wayland app
17:28:55 <tablepc> I just tried copying a file from KolourPaint and pasting to GIMP and it did not work
17:28:58 <frantisekz> hmm, sounds like some interaction between wayland/xwayland
17:29:07 <kparal> adamw: ok, try that please?
17:29:26 <adamw> yeah, reproduced
17:29:31 <frantisekz> yep
17:29:36 <kparal> alright
17:29:36 <adamw> gimp says "There is no image data in the clipboard to paste."
17:29:42 <frantisekz> yeah, same
17:29:48 <adamw> so, again...we don't really have a criterion for this..
17:29:56 <adamw> tbh, to me, it's irritating but maybe not release blocker worthy?
17:30:10 <frantisekz> FE imo
17:30:21 <bcotton> 0 blocker, +1 FE
17:30:25 <frantisekz> there should be no app using xorg by default in Workstation
17:30:26 <adamw> thought experiment: what would a criterion that *does* cover this say?
17:30:48 <kparal> we can't have a criterion for everything
17:31:02 <kparal> clipboard is pretty much expected to work by everyone
17:31:14 <adamw> right, but what are the limits of 'work'?
17:31:15 <kparal> but I agree this is somewhat an edge case
17:31:29 <frantisekz> Xwayland apps and their interaction with Wayland and other Xwayland apps must work can be the criterion?
17:31:37 <adamw> that's an awful criterion :P
17:31:41 <frantisekz> (I am not proposing that :D )
17:31:43 <adamw> how do you define 'interaction'?
17:31:59 <frantisekz> anything, vague on purpose :D
17:32:08 <frantisekz> clipboard, drag n drop,....
17:32:14 <adamw> anyhow, yeah, i think i'm weak -1 blocker, +1 FE
17:32:29 <frantisekz> yep, -1 B , +1 FE
17:32:49 <kparal> I'm fine with that
17:32:55 <pwhalen> -1B, +1 FE
17:33:11 <tablepc> Just tried drag and drop onto a GIMP canvas and it worked
17:33:48 <kparal> but this is setting some bad precedent for _my_ clipboard bug
17:33:54 <adamw> proposed #agreed 1751646 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we agreed this is an unfortunate bug but it doesn't clearly violate an existing criterion and we don't think it's serious enough to consider writing a new one. Accepted as an FE as it will affect lives and so cannot be fully fixed with an update
17:34:02 <bcotton> kparal++
17:34:04 <adamw> kparal: well, we'll get there :P
17:34:06 <frantisekz> ack
17:34:12 <bcotton> ack
17:34:21 <kparal> ack
17:35:27 <adamw> #agreed 1751646 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we agreed this is an unfortunate bug but it doesn't clearly violate an existing criterion and we don't think it's serious enough to consider writing a new one. Accepted as an FE as it will affect lives and so cannot be fully fixed with an update
17:35:38 <adamw> #topic (1750123) blivet unable to use all the usable freespace regions
17:35:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750123
17:35:38 <adamw> #info Proposed Blocker, python-blivet, NEW
17:35:44 <adamw> is this the same as the biosboot one?
17:36:53 <kparal> nope
17:36:53 <frantisekz> I dont think so , kparal https://bugzilla.redhat.com/show_bug.cgi?id=1750123#c12 ?
17:37:05 <kparal> this is custom part only
17:37:06 <adamw> ah, k
17:37:20 <kparal> and it says you can't reuse multiple free areas for creating a VG
17:37:40 <adamw> from the description in #c12 i think i'd be -1
17:38:17 <kparal> yeah I see it more like a design problem
17:38:22 <frantisekz> yep, -1
17:38:46 <bcotton> -1
17:38:47 <pwhalen> -1 blocker
17:39:04 <kparal> I wish we could have blockers for terrible UIs, though :)
17:39:25 <adamw> heh
17:39:31 <kparal> but we would never make a new fedora release
17:40:23 <adamw> proposed #agreed 1750123 - RejectedBlocker (Final) - this seems to be more a design limitation in the custom partitioning UI than a clear bug, and is not a regression; it's not really suitable for treatment as a blocker bug. We'll hold that it doesn't violate the criterion as the installer is not "offering" to create the layout in question
17:40:27 <bcotton> ack
17:40:35 <frantisekz> ack
17:40:39 <kparal> as a workaround, blivet-gui allows you to make use of all the free space
17:40:42 <kparal> when it works
17:40:45 <adamw> heh
17:40:46 <pwhalen> ack
17:41:02 <kparal> ack
17:41:13 <adamw> (that is actually a horrible justification but let's hope no-one reads it too closely!)
17:41:16 <adamw> #agreed 1750123 - RejectedBlocker (Final) - this seems to be more a design limitation in the custom partitioning UI than a clear bug, and is not a regression; it's not really suitable for treatment as a blocker bug. We'll hold that it doesn't violate the criterion as the installer is not "offering" to create the layout in question
17:41:22 <adamw> #topic (1755038) VM clipboard integration wipes clipboard contents randomly and frequently (X11 host)
17:41:22 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1755038
17:41:22 <adamw> #info Proposed Blocker, spice-vdagent, NEW
17:41:26 <adamw> so, kparal's bug
17:41:33 <kparal> everyone simply write +1 and we can move on
17:41:41 <adamw> kparal: i tried but my clipboard ate it
17:41:48 <pwhalen> heh
17:41:50 <bcotton> adamw++
17:41:50 <zodbot> bcotton: Karma for adamwill changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:42:05 <kparal> ok, it's on record, adamw wants to block
17:42:23 <adamw> so, again i'll say this doesn't really hit any existing criterion...*but* i'd be more interested in saying we *should* have a criterion for this
17:42:40 <adamw> text is obviously the most common/most important use of the clipboard
17:42:50 <frantisekz> yep, so punt and wait for criterion?
17:43:08 <adamw> well, it's better to have some kind of consensus
17:43:12 <adamw> what does everyone else think here?
17:43:19 <kparal> this is again edge case, it breaks if you have a VM running
17:43:29 <kparal> when I have 2, I have basically no-worky clipboard
17:43:29 <adamw> and on X11
17:43:38 <kparal> sure, all reasonable people use X11
17:43:40 <adamw> heh
17:43:42 <frantisekz> :D
17:44:03 <adamw> so...i think my position is that i would be fairly welcoming to a 'clipboard must work' criterion of some kind
17:44:06 <kparal> wayland is for hipsters
17:44:08 <bcotton> you could stretch the data loss criterion?
17:44:10 <adamw> if we had one, this bug would probably be a borderline case for it
17:44:22 <bcotton> ctrl-x some text, clipboard goes boom, you've lost data
17:44:30 <adamw> yeah, that's a...sustainable position
17:44:40 <adamw> (although in most things you can ctrl-z the ctrl-x, i think)
17:44:50 <kparal> I think it's better to argue that apps like nautilus don't work properly (copying files etc)
17:45:11 <kparal> adamw: as it turns out, hexchat doesn't support ctrl+z, I found out :)
17:45:17 <adamw> fun
17:45:37 <adamw> btw, kparal, jakub just gave you a rebased patch series in the bug
17:45:45 <kparal> so we already have existing criteria to cover this (default app functionality), it just happens if you have a VM running
17:45:55 <kparal> adamw: yeah, I'll try to build it
17:46:23 <frantisekz> anyhow... I feel like +1 here
17:47:01 <adamw> so...let's summarize
17:47:08 <adamw> we can imagine a new 'clipboard must work' criterion
17:47:21 <adamw> or we can consider this as a conditional violation of 'data loss' or 'default app functionality' criteria
17:47:27 <adamw> i feel very 0-y either way, tbh
17:47:28 <kparal> I guess I'll abstain the vote, because my judgment is clearly affected here. I hate this bug with passion :)
17:47:39 <adamw> mainly because of the 'has to be on X11 with a VM running' bit
17:47:49 <adamw> that makes it more susceptible to being documented and fixed with an update in my eyes
17:47:57 <frantisekz> oh, I've missed "has to be on X11 with a VM running" bit
17:48:02 <adamw> oh yeah, i can see that it's very annoying if it hits your workflow right in the yes
17:48:10 <adamw> eyes*
17:48:44 <bcotton> 0 blocker, +1 FE
17:48:50 <frantisekz> 0 blocker, +1 FE
17:49:43 <kparal> it might be a stockholm syndrome talking, but if you make it just a commonbug and -1 blocker, I won't be too mad at you. Or I won't kill you right away, one of that. It is really an edge-case.
17:50:01 <pwhalen> 0 blocker, +1 FE
17:50:03 <kparal> but I'll also have to avoid running F31 VMs for some forseeable future :)
17:50:25 <frantisekz> (so, we might be able to have a release if kparal stops breaking everything)
17:50:28 <frantisekz> :)
17:51:04 <kparal> if you make it a blocker, I'll give you cookies, though
17:51:24 <adamw> * kparal tries to kill everyone
17:51:31 <adamw> * kparal's knife disappears due to a clipboard bug
17:52:04 <kparal> * kparal hits you with a clipboard
17:52:58 <adamw> proposed #agreed 1755038 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we think a bug of this nature could conceivably be a blocker under various criteria, but as this one only manifests when using an X11 session (not default in most cases) *and* running a virtual machine, we agreed it's slightly too limited in impact. Accepted as an FE as it can't be fixed for lives with an update
17:53:53 <pwhalen> ack
17:54:19 <bcotton> ack
17:54:27 <frantisekz> ack
17:54:34 <kparal> no cookies for any of you
17:54:40 <adamw> if people would prefer to punt we can do that, but...i dunno what we'd be punting *for*, so i'm counting 0s as -1s effectively here
17:54:51 <kparal> ack
17:55:30 <adamw> #agreed 1755038 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we think a bug of this nature could conceivably be a blocker under various criteria, but as this one only manifests when using an X11 session (not default in most cases) *and* running a virtual machine, we agreed it's slightly too limited in impact. Accepted as an FE as it can't be fixed for lives with an update
17:55:41 <adamw> #topic (1755733) Gnome Xorg session stuck immediately after login
17:55:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1755733
17:55:41 <adamw> #info Proposed Blocker, xorg-x11-server, NEW
17:55:51 <adamw> this one could do with testing on more hardware, i guess. and input from ajax
17:55:54 <adamw> bit hard to make a call yet
17:56:11 <frantisekz> yeah, for now, it seems limited to older Intel iGPUs
17:56:19 <frantisekz> (by older, I'd bet on pre-SKL)
17:56:30 <frantisekz> so punt?
17:57:30 <adamw> i think punt, and if people could test on any intel adapters they have lying around it'd be great
17:57:37 <adamw> i can send out a call for testing
17:58:28 <frantisekz> I don't have anything older than SKL, KBL works just fine
18:00:32 <adamw> any other votes?
18:01:37 <coremodule> punt for testing, I'll see what I have laying around to test with
18:01:39 <pwhalen> +1 punt
18:01:42 <kparal> punt
18:02:12 <adamw> proposed #agreed 1755733 - punt (delay decision) - so far we can only be sure one system has a problem here; we need to test more systems to assess blocker and FE status
18:02:23 <adamw> #action adamw to send out call for testing on 1755733
18:02:25 <frantisekz> ack
18:02:30 <pwhalen> ack
18:02:58 <coremodule> ack
18:03:49 <kparal> ack
18:03:52 <adamw> #agreed 1755733 - punt (delay decision) - so far we can only be sure one system has a problem here; we need to test more systems to assess blocker and FE status
18:04:07 <adamw> OK, that's all the proposed blockers
18:04:13 <adamw> #topic Proposed freeze exceptions
18:04:20 <adamw> #info moving onto Proposed freeze exception issues
18:04:44 <adamw> #info we already accepted 1757089 earlier
18:04:50 <adamw> #topic (1754875) nm-connection-editor not available in overview
18:04:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1754875
18:04:50 <adamw> #info Proposed Freeze Exceptions, network-manager-applet, NEW
18:05:13 <adamw> hum
18:05:18 <adamw> on the one hand i'd like to see this improved
18:05:30 <adamw> on the other hand i'm not sure the cost/benefit of poking the package during freeze would necessarily be worth it
18:05:43 <adamw> maybe *early* in the freeze...
18:06:13 <frantisekz> yeah, so punt now?
18:07:09 <kparal> we would we wait for?
18:07:35 <frantisekz> how the fix is going to look like and when is it going to arrive
18:07:42 <bcotton> -1 FE. doesn't seem like something we should poke during a freeze and the current behavior is what the WG wants
18:08:01 <kparal> correct me if I'm wrong, but we're not frozen yet, correct?
18:08:09 <frantisekz> yep
18:08:18 <kparal> so they can fix it if they wish, if they're fast
18:08:23 <bcotton> yep, they have a week
18:08:26 <kparal> during final freeze, I'm -1
18:08:52 <adamw> bcotton: there's a proposed change that no-one seems to oppose
18:08:52 <pwhalen> -1 FE
18:09:03 <adamw> split the nm-c-e package so the bit gnome needs and the .desktop file are in separate packages
18:09:13 <adamw> and then don't install the package with the .desktop file by default
18:09:23 <adamw> maybe i should just go do that. :P
18:10:03 <adamw> proposed #agreed 1754875 - RejectedFreezeException (Final) - we're generally agreed that the risk/reward for changing this during a freeze period would not be worthwhile
18:10:44 <bcotton> adamw: sure, but it's not worth doing that during the final imo. it's a different way to get the same user-facing behavior aiui
18:10:45 <bcotton> ack
18:10:48 <frantisekz> ack
18:11:12 <adamw> bcotton: no, it's not the same. the user-facing behaviour would be that if you installed the package containing the .desktop file, the app would show up in the menus
18:11:18 <adamw> right now you can *never* get the app to show up in the menus
18:11:36 <adamw> still, it probably doesn't need an FE, it could go as an update anyway.
18:11:41 <pwhalen> ack
18:11:42 <bcotton> okay, yeah
18:11:47 <adamw> #agreed 1754875 - RejectedFreezeException (Final) - we're generally agreed that the risk/reward for changing this during a freeze period would not be worthwhile
18:11:57 <adamw> #topic (1756024) Qt applications cannot be maximized with double click in title bar
18:11:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1756024
18:11:57 <adamw> #info Proposed Freeze Exceptions, qgnomeplatform, NEW
18:12:35 <adamw> do we include any Qt apps in the live?
18:12:41 <adamw> if not i'd say we could just as well fix this with an updat.e..
18:12:59 <frantisekz> no, there is not anything qt based on workstation live
18:13:31 <frantisekz> significant qt app to note is fedora media writer
18:13:50 <frantisekz> but, this is something that can be fixed by an update without any significant impact
18:14:26 <adamw> yeah
18:14:27 <bcotton> is fedora media writer on the live? i remember some people saying it shoudl be, but i dont' remember if that happened
18:14:47 <tablepc> they said no thanks
18:15:02 <tablepc> Load it if you need it
18:15:03 <frantisekz> bcotton no, it's not there
18:15:06 <adamw> so, -1 for me i think
18:15:09 <frantisekz> -1
18:15:13 <bcotton> cool, then i'm -1
18:15:43 <pwhalen> -1
18:18:47 <adamw> proposed #agreed 1756024 - RejectedFreezeException (Final) - we're not aware of any prominent Qt apps on the Workstation live image, so we think this can be fixed just as well with an update as a freeze exception
18:19:03 <bcotton> ack
18:19:20 <frantisekz> ack
18:19:52 <pwhalen> ack
18:21:07 <adamw> #agreed 1756024 - RejectedFreezeException (Final) - we're not aware of any prominent Qt apps on the Workstation live image, so we think this can be fixed just as well with an update as a freeze exception
18:21:14 <adamw> alright, that's all the proposals
18:21:24 <frantisekz> you sure?
18:21:31 <frantisekz> I think there was some sugar thing
18:21:33 <adamw> oh
18:21:40 <adamw> yeah
18:21:42 <adamw> scrolling helps!
18:21:43 <adamw> #topic (1756771) f31 sugar fails to install
18:21:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1756771
18:21:43 <adamw> #info Proposed Freeze Exceptions, sugar, NEW
18:21:46 <frantisekz> ohh
18:21:51 * satellit_ "two days ago the gstreamer-plugins-espeak package was removed and then re-added" (soas stopped building)
18:23:23 <adamw> yeah hm
18:23:27 <frantisekz> so, I guess this can't be fixed by an update
18:23:41 <frantisekz> and fix of having gstreamer-plugins-espeak back in repo shouldn't affect anything else
18:24:03 <satellit_> everything netinstall also fails due to this
18:24:22 <tablepc> quit: Have a Great Day!
18:24:24 <adamw> in practice
18:24:33 <adamw> i think this will just get magically fixed in the next compose?
18:24:42 <frantisekz> yeah, looks like it should
18:24:51 <adamw> i think 0928.n.0 just happened unluckily during the time the package was retired
18:24:56 <adamw> i'm gonna vote punt
18:25:03 <frantisekz> okay, no issue with that
18:25:21 <adamw> on the expectation this'll just go away with the next compose, but if it doesn't we can look again
18:25:37 <bcotton> wfm
18:27:00 <adamw> proposed #agreed 1756771 - punt (delay decision) - we believe this should be fixed 'magically' with the next compose as the package was unretired. if not, we will re-evaluate next week
18:27:05 <frantisekz> ack
18:27:06 <bcotton> ack
18:27:06 <pwhalen> ack
18:27:14 <satellit_> ack
18:27:42 <adamw> #agreed 1756771 - punt (delay decision) - we believe this should be fixed 'magically' with the next compose as the package was unretired. if not, we will re-evaluate next week
18:27:54 <adamw> #info that's all proposed blockers and FEs
18:27:58 <adamw> #topic Accepted blockers
18:28:14 <adamw> #info most accepted blockers are in a straightforward state - mainly waiting on developers
18:28:25 <adamw> #topic (1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
18:28:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1747408
18:28:26 <adamw> #info Accepted Blocker, distribution, NEW
18:28:43 <adamw> this one seems like FESCo has decided it's a blocker but resolving it is getting the hot potato treatment
18:28:45 <adamw> bcotton, wdyt?
18:29:40 <bcotton> i think you summed it up exactly
18:29:42 <bcotton> :-)
18:30:55 <bcotton> i'll talk to langdon and contyk and see if we can some up with something with the dnf team so that we can actually do a release this fall
18:31:14 <bcotton> because the other resolution i see is for FESCo to say "okay, fine, we'll accept it after all"
18:31:29 <adamw> like all the other modularity blockers
18:31:30 <adamw> le sigh
18:31:43 <adamw> #action bcotton to follow up on 1747408 and try to get some movement
18:31:52 <adamw> #topic (1752249) Revert skip_if_unavailable default back to true
18:31:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1752249
18:31:52 <adamw> #info Accepted Blocker, dnf, ASSIGNED
18:31:59 <adamw> this one again, just want to record it
18:32:14 <adamw> #info this seems fairly straightforward but has been hanging for weeks
18:32:21 <bcotton> adamw: i saw you commented on this to nudge it. i'll bring it up in their meeting on wednesday
18:32:21 <adamw> #action adamw and bcotton to prod dnf team into taking care of this
18:32:29 <adamw> #undo
18:32:29 <zodbot> Removing item from minutes: ACTION by adamw at 18:32:21 : adamw and bcotton to prod dnf team into taking care of this
18:32:35 <adamw> #action adamw and bcotton to prod dnf team into taking care of 1752249
18:32:53 <adamw> i think that's all the ones we need to look at
18:33:00 <adamw> anyone concerned about any others?
18:33:20 <frantisekz> sddm one?
18:33:29 <frantisekz> there doesn't seem to be too much movement around
18:33:51 <frantisekz> 1728240
18:33:58 <adamw> oh ,yeah
18:34:04 <adamw> #topic (1728240) Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
18:34:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1728240
18:34:04 <adamw> #info Accepted Blocker, sddm, NEW
18:34:45 <adamw> #info there is one pretty clear-cut issue here, that sddm simply fails to start when doing a BIOS nomodeset boot, but there doesn't seem to be clear progress towards a resolution
18:35:05 <adamw> i'm not sure what more we can do, though, besides start digging through sddm code ourselves (which i may do this week)
18:35:15 <adamw> rex is on the bug
18:35:41 <frantisekz> okay, feel free to ping if you need me to test anything adamw
18:36:00 <frantisekz> (the other way forward may be trying to report the issue upstream?)
18:36:09 <adamw> yeah, we should do that if it's not already
18:36:23 <frantisekz> okay, I can do that
18:36:24 <adamw> can you do that?
18:36:26 <adamw> heh
18:36:40 <adamw> #action frantisekz to file an upstream report for #1728240
18:36:45 <frantisekz> :D just tomorrow, I don't have any flash drive home...
18:37:42 <adamw> no probs
18:37:44 <adamw> ok
18:37:47 <adamw> #topic Open floor
18:37:50 <adamw> thanks for sticking around, everyone
18:37:57 <adamw> any other f31-y business?
18:38:03 <frantisekz> thanks adamw for leading the way :)
18:39:15 <pwhalen> hrm, one item actually
18:39:21 <pwhalen> this one https://bugzilla.redhat.com/show_bug.cgi?id=1750575
18:39:41 <adamw> looking
18:39:45 <pwhalen> doesnt seem to have moved at all, thoughts on a final blocker? this affects a number of spins
18:39:56 <adamw> ah, that one
18:40:18 <adamw> hum
18:40:31 <adamw> it still seems a bit weak for a blocker since the update *works*, but, i know what you mean
18:40:43 <bcotton> iirc i was like "meh, it's fine for a beta" but i'm less meh for final
18:40:45 <frantisekz> yeah, proposing as final blocker shouldn't hurt anything
18:40:49 <pwhalen> right, I think that was OK for beta, but final
18:40:51 <bcotton> not sure it achieves blocker status
18:41:48 <bcotton> i say propose it as a final blocker and we'll think about it between now and next week :-)
18:42:06 <pwhalen> Ok, will do. thanks
18:43:41 <adamw> heh, works for me
18:43:50 <adamw> we should poke neal about it too
18:44:05 * adamw does
18:44:08 <adamw> alrighty, was that all?
18:44:26 * pwhalen has nothing else
18:45:32 <adamw> okely dokely
18:45:33 <adamw> thanks, everyone
18:45:35 <adamw> #endmeeting