16:02:44 <adamw> #startmeeting F29-blocker-review 16:02:44 <zodbot> Meeting started Mon Sep 17 16:02:44 2018 UTC. 16:02:44 <zodbot> This meeting is logged and archived in a public location. 16:02:44 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:44 <zodbot> The meeting name has been set to 'f29-blocker-review' 16:02:44 <adamw> #meetingname F29-blocker-review 16:02:44 <adamw> #topic Roll Call 16:02:44 <zodbot> The meeting name has been set to 'f29-blocker-review' 16:02:47 <adamw> cmurf: this is unpossible 16:02:52 <frantisekz> .hello2 16:02:53 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com> 16:02:55 <lbrabec> .hello2 16:02:56 <adamw> who's around for some blocker review? 16:02:56 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com> 16:03:47 * coremodule is here, ready to act as secretary. 16:03:52 <bcotton> .hello2 16:03:53 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 16:04:05 <coremodule> .hello2 16:04:06 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com> 16:04:30 <contyk> .hello psabata 16:04:31 * pwhalen is here 16:04:32 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com> 16:06:01 <adamw> hi folks, thanks for coming 16:06:07 <adamw> #chair lbrabec bcotton coremodule 16:06:07 <zodbot> Current chairs: adamw bcotton coremodule lbrabec 16:06:27 <adamw> incoming boilerplate alert! 16:06:28 <adamw> #topic Introduction 16:06:28 <adamw> Why are we here? 16:06:28 <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:31 <adamw> #info We'll be following the process outlined at: 16:06:31 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:32 <adamw> #info The bugs up for review today are available at: 16:06:33 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:06:35 <adamw> #info The criteria for release blocking bugs can be found at: 16:06:37 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:06:39 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria 16:06:41 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria 16:06:43 <adamw> we have, for Beta: 16:06:45 <adamw> #info 4 Proposed Blockers 16:06:47 <adamw> #info 1 Accepted Blockers 16:06:49 <adamw> #info 3 Proposed Freeze Exceptions 16:06:51 <adamw> #info 14 Accepted Freeze Exceptions 16:07:26 <adamw> we also have: 16:07:29 <adamw> #info 8 Proposed Final Blockers 16:07:31 <adamw> if we get to those. 16:07:34 <adamw> who wants to secretarialize? 16:07:51 * coremodule will do it. 16:09:36 <adamw> #info coremodule will secretarialize 16:09:43 <adamw> #info starting with proposed Beta blockers... 16:09:51 <adamw> #topic (1629378) Trying to start dnfdragora causes an error in dnfdaemon and the program cannot continue 16:09:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1629378 16:09:51 <adamw> #info Proposed Blocker, dnfdaemon, NEW 16:10:33 <pwhalen> just hit this while attempting to update xfce 16:10:38 <cmurf> seems like a clear blocker, even t hough I've never heard of dnfdragora 16:11:09 <sgallagh> It’s the primary package manager for KDE 16:11:26 <adamw> xfce, isn't it? 16:11:33 <adamw> kde has its own update thing 16:11:44 <contyk> of course it does 16:11:51 <Son_Goku> :/ 16:11:55 <cmurf> ok and xfce is a release blocking DE for arm right? 16:11:57 <i_dont_lock_pc> .hello2 16:11:58 <zodbot> i_dont_lock_pc: Sorry, but you don't exist 16:12:07 <pwhalen> cmurf, yes 16:12:09 <sgallagh> Yes (RE: ARM) 16:12:10 <cmurf> is the problem fixed with the pile of dnf updates in u-t? 16:12:10 <Son_Goku> .hello2 16:12:11 <zodbot> Son_Goku: Sorry, but you don't exist 16:12:14 <Son_Goku> .hello 16:12:14 <zodbot> Son_Goku: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1". 16:12:17 <Son_Goku> .hello ngompa 16:12:18 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com> 16:12:35 <frantisekz> :) 16:12:39 <lruzicka2> :) 16:12:47 <Son_Goku> I had just seen this issue earlier today myself 16:12:47 <pwhalen> cmurf, updating now, will update the bz if it is fixed after the update 16:13:30 <Son_Goku> I'm hoping the new dnf update fixes it, but I'll check with the dnf team to see if there's something that needs to change in dnfdaemon for dnf3 (... again) 16:13:54 <Son_Goku> oh, right, I'm the upstream developer for dnfdaemon ;) 16:13:55 <cmurf> and also if the fix can be backported rather than accepting such a big dnf update 16:14:04 <Son_Goku> well, if they changed the API, it'd be tricky 16:14:11 <cmurf> *sigh* 16:14:34 <adamw> when you say 'the big dnf update', you mean 3.5.1? 16:14:36 <adamw> as that's already in rc3 16:14:41 <Son_Goku> oh welp 16:14:44 <Son_Goku> I'm being bitten by the removal of python-librepo in usage in DNF 16:14:58 <Son_Goku> they no longer expose a useful repo API of any kind from python-dnf 16:15:08 <cmurf> adamw: oh really 16:15:13 <Son_Goku> so I'm going to need a new API for it 16:15:17 <adamw> yeah. we included it as an FE> 16:15:21 <cmurf> oops 16:15:32 <adamw> Son_Goku: i think you're meant to use python-libdnf ? 16:15:36 <Son_Goku> I guess so 16:15:42 <adamw> so...hm 16:15:45 <Son_Goku> there's just no generated docs for what that provides, so I have no idea what to do 16:15:56 <adamw> is this something that was *broken* by updating to dnf 3.5.1? did it work with 3.2.0? do we know? 16:16:15 <Son_Goku> it probably worked with 3.2.0 16:16:20 <cmurf> yeah 16:16:22 <Son_Goku> because dnf still used python-librepo then 16:16:42 <Son_Goku> and exported a repo API 16:16:53 <cmurf> better to revert on an FE fix than block 16:17:39 <adamw> yeah... 16:17:49 <adamw> only then we lose fixes for several other things... 16:18:12 <Son_Goku> adamw: this PR broke me: https://github.com/rpm-software-management/dnf/pull/1111 16:18:17 <Son_Goku> it was merged in DNF 3.4.0 16:18:22 <Son_Goku> which we didn't have 16:18:49 <Son_Goku> however, I know the API change I need to make now 16:19:00 <adamw> ok, so 16:19:02 <Son_Goku> as it's right in the diff 16:19:05 <adamw> let's not solve this now 16:19:08 <adamw> Son_Goku: how hard is it? 16:19:10 <frantisekz> sigh, I'll solve other blockers and then we can decide if we are going to slip, we might be able to solve this without reverting dnf to 3.2.0 16:19:15 <frantisekz> yeah... :D 16:19:21 <Son_Goku> adamw, looks like it might be ~5-10 lines 16:19:22 <adamw> anyway, i'm +1 16:19:31 <adamw> Son_Goku: ok, that'd be good. maybe we can do that. 16:19:50 <adamw> although dnf 3.5.1 isn't in *stable* it is in rc3, so we should take this as a blocker 16:20:00 <cmurf> yep +1 beta blocker, how it gets fixed isn't material to blockeryness 16:20:07 <frantisekz> +1 16:20:08 <pwhalen> +1 16:20:16 <sgallagh> +1 16:20:20 <contyk> +1 16:20:31 <adamw> proposed #agreed 1629378 - AcceptedBlocker (Beta) - this clearly violates Beta criterion "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)" for Xfce, which is a release-blocking desktop for 32-bit ARM 16:20:32 <lruzicka2> +1, 16:20:36 <pwhalen> ack 16:20:38 <cmurf> ack 16:20:41 <frantisekz> ack 16:20:43 <lruzicka2> ack 16:20:44 <contyk> ack 16:20:53 <adamw> #agreed 1629378 - AcceptedBlocker (Beta) - this clearly violates Beta criterion "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)" for Xfce, which is a release-blocking desktop for 32-bit ARM 16:21:01 <adamw> #topic (1629628) Default F29 Wallpaper is Solid Black on XFCE/ARM 16:21:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1629628 16:21:01 <adamw> #info Proposed Blocker, f29-backgrounds, NEW 16:21:03 <adamw> -1 blocker, +1 FE. 16:21:08 <contyk> :)) 16:21:12 <adamw> srsly why is this so hard 16:21:15 <frantisekz> +1 FE :) 16:21:23 <sgallagh> -1 blocker, +1 FE 16:21:24 <contyk> well, is solid black different from f28? 16:21:29 <frantisekz> yep :D 16:21:29 <lbrabec> yepyep, -1 blocker, +1 FE 16:21:33 <coremodule> +1FE 16:21:36 <lruzicka2> -1 blocker, +1 FE 16:21:40 <pwhalen> this must be hw specific 16:21:43 <adamw> we can put a man on the moon, we can't change the desktop background without a full-on Yakety Sax routine every damn six months 16:21:51 <Son_Goku> much sad about boring background on ARM though 16:22:03 * nirik has not seen this because it's not filed against Xfce... sigh. 16:22:11 <sgallagh> Less processor intensive though! 16:22:19 <Son_Goku> haha 16:22:37 <contyk> unless it's svg with thousands of black squares 16:22:38 <frantisekz> maybe it's plan for Fedora on ARM optimization stuff going on.... :D 16:22:56 * pwhalen is looking at the right background in xfce 16:23:04 <adamw> odd 16:23:12 <pwhalen> Beta 1.3 16:23:13 <adamw> oh well, we can figure it out later 16:23:16 <pwhalen> what hw frantisekz? 16:23:21 <frantisekz> rpi2 16:23:50 <pwhalen> ok, must be specific to the hw. The background is correct 16:23:57 <frantisekz> If I chose that wallpaper from settings, it worked then 16:24:07 <frantisekz> it just wasnt on by default 16:25:06 <adamw> how did you deploy? 16:25:18 <pwhalen> hrm , not tested the rpi2, but its definitely correct on a vm 16:25:18 <frantisekz> fedora-arm-installer to SD 16:25:41 <adamw> how about this, my vote is +1 FE if pwhalen decides there's a real problem 16:25:50 <pwhalen> the rpi's can be finicky 16:27:04 <pwhalen> I'll test the rpi2, but it seems hw specific 16:27:15 <cmurf> +1 beta freeze exception 16:28:22 <adamw> proposed #agreed 1629628 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - we agree this does not violate the criteria as a black background is "different" from previous stable. We accept it as a freeze exception issue assuming pwhalen and frantisekz can figure out exactly what's going on 16:28:25 <nirik> it's definitely set to /usr/share/backgrounds/images/default.png by default. ;( 16:28:39 <frantisekz> ack 16:28:43 <lbrabec> ack 16:28:44 <pwhalen> ack 16:28:52 <lruzicka2> ack 16:29:50 <adamw> #agreed 1629628 - RejectedBlocker (Beta), AcceptedFreezeException (Beta) - we agree this does not violate the criteria as a black background is "different" from previous stable. We accept it as a freeze exception issue assuming pwhalen and frantisekz can figure out exactly what's going on 16:30:05 <adamw> #topic (1629340) PackageKit update crashes at end of transaction with "TransactionItem state is not set: grub2-tools-1:2.02-57.fc29.x86_64" 16:30:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1629340 16:30:05 <adamw> #info Proposed Blocker, PackageKit, NEW 16:30:29 <adamw> i found this over the weekend, seems 100% reproducible with current repo state (-57 in stable and RC3, -58 in u-t) 16:30:47 <adamw> any attempt to update from grub2 -57 to -58 with packagekit seems to cause packagekitd to crash 16:30:50 <adamw> doing with dnf works ok 16:31:19 <frantisekz> I would be -1 blocker if we can get grub -58 to stable/rc 16:32:11 <adamw> i'd still be +1, tbh, this is clearly a bad bug. 16:32:30 <cmurf> packagekit is the default upgrade method for Workstation, so I am +1 beta bocker 16:32:33 <pwhalen> +1 16:32:40 <cmurf> if it can be fixed by rolling in grub -58, fine 16:32:54 <adamw> but it'd be nice to get input from someone who knows what's going on 16:33:10 <cmurf> but still that seems like a screwy work around for a likely actual bug in packagekit 16:35:05 <adamw> proposed #agreed 1629340 - AcceptedBlocker (Beta) - this seems a clear violation of Beta criterion "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)" for Workstation, with current repo state 16:35:17 <pwhalen> ack 16:35:22 <lruzicka2> ack 16:35:24 <adamw> oh sorry, there were only a couple of votes so far 16:35:26 <adamw> thought there were more 16:35:30 <adamw> consider voting still open 16:35:50 <contyk> well, ack 16:36:12 <adamw> i'll count an ack as a combined +1/ack 16:36:13 <frantisekz> +1 (i would like to be able to write something like +0.5.... :D ) 16:36:30 <adamw> frantisekz: you can! the voting software is very sophisticated 16:36:35 <adamw> (because it's entirely in my head) 16:36:41 <frantisekz> :D 16:37:58 <cmurf> but ack 16:38:17 <adamw> sgallagh: ? 16:38:25 <cmurf> shoulda put a ! on that 16:38:31 <cmurf> but ack! 16:40:29 <adamw> cmurf: i see you double acking 16:40:39 <adamw> oh, well 16:40:39 <adamw> #agreed 1629340 - AcceptedBlocker (Beta) - this seems a clear violation of Beta criterion "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)" for Workstation, with current repo state 16:40:48 <adamw> #topic (1628495) In UEFI mode, Fedora 29 cannot be installed in Safe Graphics Mode 16:40:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628495 16:40:48 <adamw> #info Proposed Blocker, xorg-x11-server, NEW 16:41:16 <adamw> hum. ajax said he was either going to update the bug for this or come to the meeting, but i don't see either 16:41:35 <lruzicka2> +1 blocker, seems that the safe mode does not work for Live ISO at all. 16:41:36 * adamw pings him 16:41:55 <adamw> ajax seemed to think this might possibly only affect hardware that would always work OK with 'not-safe' mode 16:41:59 <adamw> if that's the case i'd be -1 16:42:05 <adamw> but, it'd be good to hear from him 16:42:14 <Son_Goku> welp, my laptop battery is dead, so I'm signing off for now 16:42:14 <frantisekz> yep, if it's the case, -1 16:42:20 * Son_Goku waves 16:44:34 <cmurf> yeah so punt, need more info 16:45:02 <adamw> yeah, i was waiting for ajax, but seems he's not around 16:45:24 <cmurf> but if it only affects hardware that always works with modeset, I'd be -1 blocker as well 16:45:44 * pwhalen is with the rest of you 16:48:23 <adamw> proposed #agreed 1628495 - punt (delay decision) - ajax has suggested this may only affect hardware that works fine with a native driver, which would make it likely not a blocker, but he is not here and we're not 100% sure on that, so we will delay the decision 16:48:49 <frantisekz> ack 16:48:53 <lruzicka2> ack 16:48:55 <lbrabec> ack 16:49:21 <contyk> ack 16:49:52 <adamw> #agreed 1628495 - punt (delay decision) - ajax has suggested this may only affect hardware that works fine with a native driver, which would make it likely not a blocker, but he is not here and we're not 100% sure on that, so we will delay the decision 16:49:55 <adamw> #topic (1629935) freeipa-server cannot be installed on aarch64 16:49:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1629935 16:49:55 <adamw> #info Proposed Blocker, pki-core, MODIFIED 16:49:58 <pwhalen> ack 16:50:01 <adamw> so lied about the proposed blocker count 16:50:11 <adamw> actually i proposed this 20 minutes ago :P 16:51:00 <adamw> noticed this in the openqa tests yesterday, there was a mess with aarch64 support being turned off in pki-core which is resolved with an update that missed the freeze, so in rc3 freeipa-server can't be installed on aarch64 :/ 16:51:06 * sumantro is here 16:51:12 <adamw> aarch64 is a release-blocking arch for Server now, so this is a pretty clear blocker 16:51:40 <lruzicka2> ok, +1 16:51:53 <frantisekz> +1 16:51:54 <sumantro> +1 16:52:02 <lbrabec> +1 16:52:11 <pwhalen> +1 16:52:28 <contyk> +1 16:53:01 <adamw> proposed #agreed 1629935 - AcceptedBlocker (Beta) - this clearly violates all the FreeIPA-related criteria for aarch64, which is a release-blocking arch for Server 16:53:12 <frantisekz> ack 16:53:13 <lruzicka2> ack 16:53:14 <lbrabec> ack 16:53:24 <sumantro> ack 16:54:18 <contyk> ack 16:54:26 <adamw> #agreed 1629935 - AcceptedBlocker (Beta) - this clearly violates all the FreeIPA-related criteria for aarch64, which is a release-blocking arch for Server 16:54:37 <adamw> OK, that's all the proposed blockers 16:54:50 <adamw> let's move onto proposed FEs 16:54:53 <adamw> #info onto proposed FEs 16:55:32 <adamw> #topic (1622312) golang 1.11 breaks snapd compilation on s390x 16:55:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1622312 16:55:32 <adamw> #info Proposed Freeze Exceptions, golang, MODIFIED 16:55:58 <adamw> it seems neal is now asking us to push both golang and snapd... 16:56:06 <adamw> don't really know how i feel about this one. 16:56:10 <cmurf> what's the risk 16:56:23 <cmurf> ATM i'm kinda turned off by FE's :D 16:57:31 <cmurf> are golang and snapd on actual installation media for s390x? 16:57:50 <adamw> well, golang is, you know, go 16:57:58 <adamw> if we push it stable it affects builds of anything else go-y, i gues 16:58:05 <adamw> dunno if either is on install media 16:58:17 <cmurf> off hand i'm like, go get an update after you install 17:00:08 <adamw> it's ultimately an upgrade ftbfs bug 17:00:41 <adamw> snapd needs the rebuild to be upgradeable 17:00:47 <adamw> i guess i can go +1 for that 17:01:30 <frantisekz> +1 17:02:02 <sumantro> +1 17:02:04 <lruzicka2> +1 17:02:43 <pwhalen> +1 17:02:50 <adamw> proposed #agreed 1622312 - AcceptedFreezeException (Beta) - accepted as a freeze exception to resolve snapd upgrade path issues 17:03:10 <frantisekz> ack 17:03:15 <sumantro> ack 17:03:53 <lruzicka2> ackity 17:04:23 <adamw> #agreed 1622312 - AcceptedFreezeException (Beta) - accepted as a freeze exception to resolve snapd upgrade path issues 17:04:30 <adamw> #topic (1628462) input method cannot commit any strings in gnome-terminal with multiple Tabs 17:04:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628462 17:04:30 <adamw> #info Proposed Freeze Exceptions, gtk3, NEW 17:05:02 <adamw> this sounds pretty inconvenient as described, so i'd be +1 for a reasonably safe fix 17:05:06 <adamw> mclasen: around? thoughts? 17:05:29 <mclasen> fix is incoming upstream 17:06:44 <adamw> how messy is it? 17:07:15 <mclasen> not at all 17:07:45 <adamw> ok 17:07:49 <adamw> so, +1 17:07:57 <sumantro> +1 17:08:03 <lruzicka2> +1 17:08:13 <pwhalen> +1 17:08:15 <frantisekz> +1 17:08:32 <nb> +1 17:10:38 <adamw> proposed #agreed 1628462 - AcceptedFreezeException (Beta) - this is inconvenient for users of input methods in the Workstation live and would benefit from a fix in the compose 17:10:54 <sumantro> ack 17:10:56 <lbrabec> ack 17:11:03 <pwhalen> ack 17:11:24 <adamw> #agreed 1628462 - AcceptedFreezeException (Beta) - this is inconvenient for users of input methods in the Workstation live and would benefit from a fix in the compose 17:11:31 <adamw> #topic (1628263) wifi doesnt connect from the drop down in live WS F29 Beta 1.1 17:11:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628263 17:11:31 <adamw> #info Proposed Freeze Exceptions, NetworkManager, NEW 17:11:47 <adamw> +1 for this, too, it's the 'natural' way people will try to use wifi in the live 17:11:54 <adamw> pretty prominent bug 17:12:00 <lbrabec> +1 17:12:02 <sumantro> +1 17:12:02 <lruzicka2> +1 17:12:08 <frantisekz> +1 17:12:48 <contyk> +1 17:14:07 <adamw> proposed #agreed 1628263 - AcceptedFreezeException (Beta) - this is a prominent bug in the Workstation live, it's the natural way for people to try and use wifi, so fixing it would be desirable 17:14:11 <sumantro> ack 17:14:52 <pwhalen> +1/ack 17:15:02 <lruzicka2> ack 17:16:30 <adamw> #agreed 1628263 - AcceptedFreezeException (Beta) - this is a prominent bug in the Workstation live, it's the natural way for people to try and use wifi, so fixing it would be desirable 17:17:07 <adamw> #info that's all proposed FEs, a quick look at the accepted blocker: 17:17:09 <adamw> #topic (1628355) F29 Beta RC1 does not boot on Raspberry Pi 17:17:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628355 17:17:09 <adamw> #info Accepted Blocker, spin-kickstarts, VERIFIED 17:17:28 <adamw> as this is confirmed ok on rc3, i believe we can close it 17:18:22 <pwhalen> adamw, agreed 17:18:36 <adamw> #info this seems resolved in RC3, we will close it 17:19:05 <adamw> ok, so, we've got time to make a start on the proposed Final blockers... 17:19:10 <adamw> #info moving onto proposed Final blockers 17:19:23 <adamw> #topic (1585036) there isn't 'switch user' option in the list 17:19:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1585036 17:19:23 <adamw> #info Proposed Blocker, accountsservice, NEW 17:20:48 <adamw> i think we intentionally don't cover user switching in the criteria... 17:20:59 <adamw> it is mentioned in the test case, but i don't think it's in the criteria 17:21:13 <cmurf> i'm not finding it 17:21:38 <frantisekz> also, I believe you can switch user from lock screen 17:21:44 <adamw> the footnote lnie mentioned - "Switched layouts when unlocked encrypted storage" - does not have anything to do with this 17:21:57 <adamw> so, -1 blocker for me 17:22:02 <cmurf> -1 blocker 17:22:03 <frantisekz> -1 17:22:13 <lruzicka2> -1 17:22:26 <sumantro> -1 17:22:36 <pwhalen> -1 17:22:42 <lbrabec> -1 17:22:56 <adamw> doesn't seem worth a beta FE either, post-release update would be fine 17:23:05 <frantisekz> yep 17:23:16 <adamw> proposed #agreed 1585036 - RejectedBlocker (Beta) - the criteria intentionally do not cover user switching, so this is not violating any of them 17:23:20 <adamw> er 17:23:21 <adamw> patch 17:23:26 <adamw> proposed #agreed 1585036 - RejectedBlocker (Final) - the criteria intentionally do not cover user switching, so this is not violating any of them 17:23:36 <lruzicka2> ack 17:23:40 <sumantro> ack 17:23:50 <lbrabec> ack 17:23:55 <frantisekz> ack 17:24:13 <adamw> #agreed 1585036 - RejectedBlocker (Final) - the criteria intentionally do not cover user switching, so this is not violating any of them 17:24:19 <adamw> #topic (1627757) The installer failed to use an iscsi target create by targetcli 17:24:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1627757 17:24:19 <adamw> #info Proposed Blocker, anaconda, NEW 17:25:03 <adamw> so, this seems to depend a bit on the nature of the iscsi target, but even so, seems general enough to be +1 for me so far 17:25:46 <sumantro> +1 17:25:56 <frantisekz> +1 17:26:02 <lbrabec> +1 17:26:25 <lruzicka2> +1 17:26:27 <pwhalen> +1 17:26:53 <adamw> proposed #agreed 1627757 - AcceptedBlocker (Final) - this seems to violate Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices", iSCSI is a 'supported' network-attached protocol. we will look further into when this does and does not happen 17:27:01 <frantisekz> ack 17:27:04 <lbrabec> ack 17:27:31 <lruzicka2> ack 17:29:01 <pwhalen> ack 17:29:33 <adamw> #agreed 1627757 - AcceptedBlocker (Final) - this seems to violate Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices", iSCSI is a 'supported' network-attached protocol. we will look further into when this does and does not happen 17:30:27 <adamw> #topic (1625645) selinux prevents loading of anything inside /etc/cron.d 17:30:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1625645 17:30:27 <adamw> #info Proposed Blocker, cronie, ASSIGNED 17:31:13 <adamw> hmm, this seems a bit awkward 17:31:28 <adamw> there isn't really a criterion for it, unless something critical to server is pre-installed in /etc/cron.d and doesn't work... 17:32:33 <frantisekz> yeah, but releasing Fedora with broken cron... sounds scary a little 17:33:39 <adamw> yeah, ikwym 17:33:44 <pwhalen> +1 blocker 17:33:46 <adamw> be good if someone else can reproduce too 17:34:01 <adamw> i'd like anyone voting +1 to cite a criterion, since that's part of the process and no-one's identified one yet 17:34:14 <adamw> or else, propose at least vaguely what a new criterion *should* say, and get others to buy into that 17:34:55 <pwhalen> not sure about criteria, but think its something we should fix before release 17:35:38 <frantisekz> we can punt the decision, final is still pretty far, and invent a criterion before release :) 17:35:46 <bcotton> what frantisekz said 17:36:17 <pwhalen> or just fix it 17:36:49 <cmurf> punt and get it fixed before unpunting 17:38:22 <adamw> =) 17:39:07 <adamw> proposed #agreed 1625645 - punt (delay decision) - this doesn't seem to be violating any existing criteria, but the group was fairly worried about it on merit. we will delay the decision to investigate further and to provide an opportunity for someone to propose a new criterion if they want to 17:40:50 <cmurf> ack 17:40:53 <pwhalen> ack 17:41:07 <lruzicka2> ack 17:41:14 <adamw> #agreed 1625645 - punt (delay decision) - this doesn't seem to be violating any existing criteria, but the group was fairly worried about it on merit. we will delay the decision to investigate further and to provide an opportunity for someone to propose a new criterion if they want to 17:41:44 <adamw> #topic (1596827) DNF 3 crashes with "UNIQUE constraint failed" for comps_environment_group.groupid or trans_with.trans_id 17:41:44 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1596827 17:41:44 <adamw> #info Proposed Blocker, dnf, NEW 17:41:48 <adamw> oh look a bug in dnf 17:41:50 <adamw> that's unpossible! 17:42:50 <cmurf> too late already possible 17:45:04 <cmurf> if there's still this reliable reproducer, +1 blocker, it's gotta work 17:45:30 <adamw> this seems to be a crash related to history file shenanigans, more or less 17:45:48 <adamw> i do have george's history file in my inbox somewhere, i should upload that... 17:47:09 <adamw> i'd sort of like an evaluation from dnf folks before a definite vote on this one, but i'd lean towards +1 at least 17:47:54 <adamw> so, either punt and needinfo dmach, or +1 i guess 17:48:55 <pwhalen> +1 17:50:28 <cmurf> +1 17:50:34 <frantisekz> +1 17:50:38 <adamw> ok 17:50:41 <sumantro> +1 17:50:48 <cmurf> but also needinfo dmach 17:51:26 <adamw> proposed #agreed 1596827 - AcceptedBlocker (Final) - on the face of it, a reproducible crash in normal dnf operation seems a sufficient violation of Basic criterion "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type" to block Final. we will ask dnf team for more investigation of this 17:51:36 <frantisekz> ack 17:51:40 <lruzicka2> ack 17:51:49 <cmurf> ack 17:52:18 <sumantro> ack 17:52:24 <pwhalen> ack 17:52:44 <adamw> #agreed 1596827 - AcceptedBlocker (Final) - on the face of it, a reproducible crash in normal dnf operation seems a sufficient violation of Basic criterion "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type" to block Final. we will ask dnf team for more investigation of this 17:52:53 <adamw> #topic (1628255) glibc: Sticky EOF for fgetc/fread breaks stream concatenation via dup2 17:52:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628255 17:52:53 <adamw> #info Proposed Blocker, glibc, NEW 17:53:06 * adamw translates the bug description 17:53:09 <adamw> "WORDS WORDS WORDS WORDS WORDS" 17:53:20 <cmurf> yeah no kidding 17:53:24 <cmurf> i can't parse this 17:53:30 <adamw> "This bug breaks printing over network for many printers, thus have a big impact on users." 17:53:34 <adamw> okay, that's easier to understand. 17:53:39 <adamw> we don't have a criterion for it, though. 17:53:41 <adamw> so i'm -1. 17:54:14 <cmurf> we don't have a criterion yeah 17:54:16 <cmurf> -1 blocker 17:54:27 <frantisekz> -1 17:54:28 <sumantro> -1 blocker 17:54:28 <cmurf> fix it, and if it's not fixed ask for FE review 17:54:46 <lruzicka2> -1 17:54:55 <adamw> proposed #agreed 1628255 - RejectedBlocker (Final) - this is obviously an annoying bug for some, but release criteria don't cover printing in any way, never mind network printing 17:55:02 <lruzicka2> ack 17:55:02 <cmurf> ack!ack!ack!ack! 17:55:04 <frantisekz> acl 17:55:06 <frantisekz> ack* 17:55:13 <sumantro> ack 17:55:21 <pwhalen> -1 blocker, hope for a FE 17:55:31 <pwhalen> ack 17:55:49 <cmurf> (Mars Attacks!) 17:56:02 <lruzicka2> cmurf, Mars Acks! 17:57:45 <adamw> #agreed 1628255 - RejectedBlocker (Final) - this is obviously an annoying bug for some, but release criteria don't cover printing in any way, never mind network printing 17:57:54 <adamw> #topic (1628244) gnome-documents will not start 17:57:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628244 17:57:54 <adamw> #info Proposed Blocker, gnome-documents, ON_QA 17:57:57 <adamw> +1 17:58:02 <frantisekz> +1 17:58:04 <lruzicka2> +1 17:58:06 <sumantro> +1 17:58:08 <pwhalen> +1 17:58:18 <lbrabec> +1 17:59:17 <adamw> proposed #agreed 1628244 - AcceptedBlocker (Final) - clear 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" 17:59:23 <frantisekz> ack 17:59:29 <sumantro> ack 17:59:30 <lruzicka2> ack 18:00:18 <pwhalen> ack 18:00:29 <lbrabec> ack 18:00:40 <adamw> #agreed 1628244 - AcceptedBlocker (Final) - clear 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" 18:00:45 <adamw> #topic (1626862) Broken Fedora/Windows dualboot 18:00:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1626862 18:00:45 <adamw> #info Proposed Blocker, grub2, NEW 18:00:50 <adamw> this one still seems a bit mysterious 18:00:53 <cmurf> yes 18:00:56 <frantisekz> yep :( 18:00:59 <adamw> i'd like more of an idea what's going on, given that it's reported to work on another system... 18:01:01 <cmurf> punt and collect more info 18:01:19 <lruzicka2> +1 18:01:33 <cmurf> if reporter could narrow down what bug version broke this, that might help pjones figure out what change broke it 18:01:46 <pwhalen> +1 punt and collect more info 18:02:19 <cmurf> is this BIOS or UEFI? 18:02:27 <cmurf> UEFI 18:02:27 <adamw> proposed #agreed 1626862 - punt (delay decision) - this is a potential violation of the dual-boot criterion, but it seems a little unclear what's going on and if it's somehow system-specific. we will delay the decision to try and gather more info 18:02:31 <cmurf> ack 18:02:36 <sumantro> ack 18:02:39 <frantisekz> ack 18:02:44 <lbrabec> ack 18:02:54 <pwhalen> ack 18:03:05 <lruzicka2> ack 18:04:09 <adamw> #agreed 1626862 - punt (delay decision) - this is a potential violation of the dual-boot criterion, but it seems a little unclear what's going on and if it's somehow system-specific. we will delay the decision to try and gather more info 18:04:16 <adamw> #topic (1628263) wifi doesnt connect from the drop down in live WS F29 Beta 1.1 18:04:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1628263 18:04:16 <adamw> #info Proposed Blocker, NetworkManager, NEW 18:04:26 <frantisekz> +1 blocker imo 18:04:28 <adamw> i'm +1 for this, seems a sufficient violation of the 'advanced panel functionality' criterion 18:04:36 <cmurf> +1 final blocker 18:04:37 <sumantro> +1 18:04:52 <lruzicka2> +1 18:04:57 <pwhalen> +1 18:05:13 <lbrabec> +1 18:06:56 <adamw> proposed #agreed 1628263 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" 18:07:05 <cmurf> ack 18:07:10 <sumantro> ack 18:07:11 <frantisekz> ack 18:07:20 <pwhalen> ack 18:07:20 <lruzicka2> ack 18:07:27 <lbrabec> ack 18:08:07 <adamw> #agreed 1628263 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" 18:08:16 <adamw> and that's all the proposed final blockers 18:08:20 <adamw> fine work, everyone 18:08:31 <lruzicka2> |:) 18:08:39 <sumantro> :) 18:08:45 <frantisekz> thanks for leading it as always adam :) 18:09:29 <coremodule> Thanks adamw 18:09:39 <sumantro> thanks adamw :) 18:09:58 <adamw> now let's go and bravely delay the release some more! 18:10:02 <adamw> forward, QA legions 18:10:04 <lruzicka2> tanx everyone, see you 18:10:09 <adamw> #topic Open floor 18:10:14 <adamw> any other release-related business? 18:10:38 <lruzicka2> not from me :) afaik 18:10:51 <sumantro> https://bugzilla.redhat.com/show_bug.cgi?id=1628859 came out 18:11:03 <sumantro> does it look like a blocker to anyone? 18:12:04 <lruzicka2> I need to go, long travel home. Have a nice time, everyone. Sorry. 18:12:38 <adamw> sumantro: that's a known issue, iirc 18:12:54 <adamw> anaconda can actually only reconfigure the combo for X 18:12:58 <adamw> so it doesn't work on workstation live 18:13:07 <adamw> it's annoying, but i think we decided before it wasn't a blocker issue 18:13:27 <adamw> ah yeah, parag linked to the previous report 18:15:48 <sumantro> adamw yes parag linked it to something that got closed EOL :P 18:15:59 <adamw> i reopened it. 18:16:43 <sumantro> :) 18:17:03 <adamw> alrighty, guess that's all 18:19:02 <adamw> thanks for coming, folks 18:19:04 <adamw> #endmeeting