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