17:00:49 #startmeeting F26 Beta Go/No-Go meeting 17:00:49 Meeting started Thu May 25 17:00:49 2017 UTC. The chair is jkurik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:49 The meeting name has been set to 'f26_beta_go/no-go_meeting' 17:00:50 #meetingname F26-Beta-Go-No-Go-meeting 17:00:50 The meeting name has been set to 'f26-beta-go-no-go-meeting' 17:00:52 #topic Roll Call 17:00:53 .hello jkurik 17:00:55 jkurik: jkurik 'Jan Kurik' 17:01:09 .hello sgallagh 17:01:10 sgallagh: sgallagh 'Stephen Gallagher' 17:01:13 #chair dgilmore nirik adamw sgallagh roshi mboddu 17:01:14 Current chairs: adamw dgilmore jkurik mboddu nirik roshi sgallagh 17:01:23 .hello adamwill 17:01:25 adamw: adamwill 'Adam Williamson' 17:01:31 we have nothing to ship, so this will be an easy one... 17:01:33 morning 17:01:43 yeah, sadly should be a nice short meeting. ;( 17:01:50 hi everyone 17:02:21 Yeah, shall we just hit the "No-Go" button and call it a day? 17:02:27 dgilmore, mboddu: are you around ? we need someone from releng 17:02:30 well, we could probably do mini blocker review if folks are willing 17:03:06 I will start with some formalities, hopefully releng will join shortly 17:03:17 #topic Purpose of this meeting 17:03:18 #info Purpose of this meeting is to check whether or not F26 Beta is ready for shipment, according to the release criteria. 17:03:26 #info This is determined in a few ways: 17:03:28 #info * No remaining blocker bugs 17:03:29 #info * Release candidate compose is available 17:03:31 #info * Test matrices for Beta are fully completed 17:03:39 #topic Current status 17:03:40 As far as I am aware, the RC for F26 Beta is not yet ready ( https://pagure.io/releng/issue/6808 ) 17:03:52 As such, we do not have test matrices for the RC ( https://fedoraproject.org/w/index.php?title=Category:Base_validation_testing&pagefrom=Fedora+23+Final+RC9+Base#mw-pages ) 17:03:53 The lastest F26 nightly compose is available at https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170523.n.0/ 17:04:02 indeed. 17:04:14 there seem to be some issues in the compose process; both the RC compose attempts got stuck in STARTED state 17:04:37 nirik, are you representing releng? know anything about it? 17:04:56 afaik some builders went down and needed to be restarted, that slowed down the compose 17:05:10 adamw: from looking there may be issues witha libdb update 17:05:41 right... they are hanging in lorax... and several failed in lorax -> libdb 17:05:58 ooh. 17:06:17 there's a libdb blocker fix which is supposed to *prevent* update hangs... 17:06:31 it may be causeing compose hangs 17:06:31 yep. 17:06:32 maybe the fix has problems 17:06:41 can you tell what libdb nevr is involved? 17:06:51 well, maybe we should do this in #fedora-releng... 17:07:04 DEBUG util.py:439: (68/714) libdb-5.3.28-19.fc26.aarch64 17:07:25 mmf, that's the latest one :/ 17:07:30 #info RC for F26 Beta is not yet ready 17:07:32 #link https://pagure.io/releng/issue/6808 17:07:33 #info As we are missing RC there are no Test Matrices for F26 Beta 17:07:39 relevant bug: https://bugzilla.redhat.com/show_bug.cgi?id=1443415 17:07:45 should we cancel the hanging last 3? (2 ppc64's and 1 aarch64) to let the compose otherwise finish? 17:07:47 i'll talk to pkubat 17:08:00 I think a post-mortem here or anywhere is useful 17:08:03 *shrug* i guess 17:08:13 * roshi is here 17:08:16 Is there a reason this happened in the RC compose but wasn't caught in the nightlies? 17:08:21 (sorry, got nerdsniped) 17:08:32 mattdm: becayse nightlies use an older libdb 17:08:35 mattdm: because this libdb is a blocker fix that's being pulled into the compose 17:08:58 okay, that makes sense 17:09:22 Let's do at least Mini-blocker review today 17:09:24 I mean, unfortunate that it's broken, but at least that's a simple cause 17:09:37 roshi, adamw: may I ask you please to chair the mini-blocker review ? 17:09:46 sure thing 17:09:49 #topic Mini-Blocker Review 17:09:50 #link https://qa.fedoraproject.org/blockerbugs/milestone/26/beta/buglist 17:09:51 nirik: we can cancel the running and tehy should let the compose carry on 17:09:58 * nirik does so 17:10:00 This is https://bodhi.fedoraproject.org/updates/FEDORA-2017-a4c41ecc27? 17:10:02 some alt arches will not be very functional 17:10:08 #info 2 proposed blockers for Beta 17:10:09 (sorry, I'm behind the topic. I can wait) 17:10:26 mattdm: yes 17:10:35 first up: 17:10:36 #topic (1450639) [abrt] gnome-shell: operator delete(): gnome-shell killed by signal 6 17:10:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1450639 17:10:41 #info Proposed Blocker, gnome-shell, NEW 17:12:06 I would agree with Comment #12 -> block for final, do not block for beta 17:12:17 s/12/21/ 17:12:18 a few people have run into this, it seems linked to totem perhaps, but i can't see why it should block beta at least 17:12:28 for final it's more debatable but it'd need to affect a lot of people to be a blocker 17:12:36 same here 17:12:53 -1 for beta at the very least, from me 17:12:56 Yeah, I'm -1 to blocking on this 17:13:26 I've been running F26 as my daily driver for weeks and haven't seen this 17:14:02 it's probably hardware related 17:14:09 proposed #agreed - RHBZ#1450639 - RejectedBlocker - This bug doesn't clearly violate any Beta criterion and doesn't seem to affect enough users to justify a special case. Would consider for FE if there's time and a clean fix proposed. 17:14:18 * roshi added the bit about FE, but can take it out 17:14:51 ack 17:14:55 Take it out for now. I'm not willing to risk a slip by adding GNOME patches that aren't blockers. 17:15:01 kk 17:15:07 Too much potential risk 17:15:11 proposed #agreed - RHBZ#1450639 - RejectedBlocker - This bug doesn't clearly violate any Beta criterion and doesn't seem to affect enough users to justify a special case. 17:15:12 +1 on that 17:15:14 ack 17:15:27 #agreed - RHBZ#1450639 - RejectedBlocker - This bug doesn't clearly violate any Beta criterion and doesn't seem to affect enough users to justify a special case. 17:15:36 #topic (1446879) [abrt] gnome-shell: gweather_location_unref(): gnome-shell killed by signal 11 17:15:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=1446879 17:15:42 #info Proposed Blocker, libgweather, MODIFIED 17:18:50 adamw: does -3 fix it for you as well? 17:18:50 so a lil' tale here 17:19:09 * roshi takes a seat and grabs the popcorn 17:19:27 once upon a time there was https://bugzilla.redhat.com/show_bug.cgi?id=1443206 17:19:58 then we sent out an update which was meant to fix that (-2.fc26), but several people -1'ed the update, reporting that they'd run into *this* crash 17:20:03 * mattdm listens 17:20:42 at first i thought it was a consequence of / somehow related to the #1443206 crash, so was treating them as interdependent, but fmuellner said that's not the case, it just happened that people could hit this crash now the other one was out of the way 17:21:03 so i removed the interdependency and proposed this as a blocker in its own right, on the basis that -2 fixed the already-accepted blocker and we should consider this one separately 17:21:29 then in the meantime i found another commit that said it fixed a memory issue upstream, backported that - which is -3 - and it seems to fix everything for everyone 17:21:39 it may also provide free unicorns 17:21:43 sweet 17:21:46 * roshi was running low 17:21:59 well, +1 blocker, even if it's fixed now in -3 17:23:02 this one's not quite as slam-dunk-y as 1443206 was, since cmurf is the only person who claims he still hit an infinitely-repeatable g-i-s crash with -2 , but i'd still be +1 because the impact is pretty bad if you *do* hit this crash, and multiple people hit it 17:23:14 it seems to be reasonable to block, so +1 17:23:18 (like the other one, what happens is the entire Shell crashes, so you lose any open work) 17:25:04 that's +3, right? 17:25:08 yeah 17:26:05 sure, +1 17:26:10 proposed #agreed - RHBZ#1446879 - AcceptedBlocker - This bug is a clear violation of the following criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:26:25 ack 17:26:55 ack 17:27:04 #agreed - RHBZ#1446879 - AcceptedBlocker - This bug is a clear violation of the following criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." 17:27:19 #topic AcceptedBlockers 17:27:34 #info there's 5 accepted for us to go through 17:27:40 #topic (1454897) Release-blocking Cloud base images missing from Fedora 26 composes 17:27:42 * mboddu is here 17:27:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1454897 17:27:46 #info Accepted Blocker, distribution, ON_QA 17:28:15 i believe dgilmore basically fixed this, so it shouldn't be a problem in completed composes 17:28:24 #info the compose process hit a hangup, rel-eng is working to fix it 17:28:33 i'd probably want to get one RC compose with the images present just to verify, before closing 17:28:38 yeah 17:28:40 makes sense 17:28:48 nothing for us to do on this one until then though 17:28:56 and we need to pull in -3 from the last bug as well 17:29:05 so we're already getting another compose 17:29:15 #topic (1443415) [TRACKING] Upgrade f25 to f26 get stuck in Cleanup 17:29:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=1443415 17:29:16 #info Accepted Blocker, dnf, MODIFIED 17:30:34 soooo, should this be negative karma for https://bodhi.fedoraproject.org/updates/FEDORA-2017-a4c41ecc27? 17:30:41 #info This bug is believed to be the source of the compose issues. Work is ongoing to resolve this issue. 17:31:31 roshi: -3 was listed for rc1 (I just called it a 'better fix' for the existing blocker...) 17:31:43 ah 17:31:49 mattdm: i'm going to withdraw the update, right now it seems i can't for some reason (because it's 'pending' maybe) 17:31:57 but i withdrew the 24 and 25 updates 17:32:02 anything else to be done for this bug or should we move on? 17:32:13 the new libdb does seem to fix this actual *bug*, but we obvbiously need to figure out what it's doing to the compose process and fix that 17:32:24 do we have a bug to track that? 17:32:54 * roshi doesn't recall one 17:33:07 and, is there a fast reproducer that doesn't require a full compose to be started? 17:34:36 mattdm: for now i'm just following up in this bug 17:34:46 since it's pretty clearly an issue in the patch for this bug 17:34:51 *nod* ok I'll watch there. that makes sense. 17:34:54 dunno about reproducers 17:35:43 it seems to be hitting runroot tasks for lorax stuff... so perhaps lorax in a mock chroot... 17:36:20 could be that something missing in a mock chroot messes with what it's trying to do, sure 17:37:40 that bug is initially POWER, and most of the comments are about arm... do we know if the hangs were on those arches? 17:37:55 some were on x86_64 17:37:58 but the fix isn't really arch specific 17:38:06 it's basically trying to detect when glibc/libpthread get updated 17:38:14 and recreate some stuff if they are 17:39:00 ok 17:40:20 anything else for this bug, or should we move on? 17:40:30 just 3 more to check in on, then we can get to the vote 17:40:40 nope, move on 17:40:44 I would suggest to move on 17:40:46 #topic (1438046) initial-setup.service: Failed to set up stdin: Inappropriate ioctl for device 17:40:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1438046 17:40:52 #info Accepted Blocker, initial-setup, MODIFIED 17:41:14 pwhalen might know best about this one 17:41:37 there's definitely an *attempt* to fix it (which will be pulled into any RC we actually manage to build) 17:42:04 #info an attempted fix will be pulled into any RC for testing 17:42:36 * roshi skips the gnome-shell crash one because we already talked about that one 17:42:39 #topic (1348688) Anaconda cannot access LVM partitions in a LUKS-encrypted disk partition after decryption 17:42:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=1348688 17:42:45 #info Accepted Blocker, lvm2, ON_QA 17:44:15 again, attempted fix will be pulled into any RC 17:44:20 feedback on the update so far looks OK 17:44:30 (though only one of those is specifically about the bug, i think) 17:44:46 #info attempted fix will be pulled into any RC 17:44:56 that's it for blocker review 17:44:58 well 17:45:02 ? 17:45:06 ? 17:45:07 while we're here, should we grant an FE to the Samba CBE? 17:45:09 CVE* 17:45:29 good point 17:45:31 probibly so yeah 17:45:41 I don't see that in the list 17:45:43 * roshi refreshes 17:45:46 no, i'm just finding it 17:46:05 * roshi lets adamw take over 17:46:36 https://bugzilla.redhat.com/show_bug.cgi?id=1455050 17:46:37 https://bodhi.fedoraproject.org/updates/FEDORA-2017-c729c6123c 17:46:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1455050 17:46:50 #info Proposed Freeze Exception, samba, MODIFIED 17:47:02 grrr 17:47:03 #undo 17:47:04 Removing item from minutes: INFO by adamw at 17:46:50 : Proposed Freeze Exception, samba, MODIFIED 17:47:06 #undo 17:47:06 Removing item from minutes: 17:47:23 #topic (1455050) CVE-2017-7494 samba: Loading shared modules from any path in the system leading to RCE [fedora-all] 17:47:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1455050 17:47:33 #info Proposed Freeze Exception, samba, MODIFIED 17:47:36 there we go 17:47:47 big CVE, obviously shouldn't ship with it vulnerable, +1 17:47:54 yeah +1 17:47:56 +1 17:47:59 +1 FE 17:48:13 (although AIUI SELinux does mitigate. So, yay.) 17:49:32 proposed #agreed - RHBZ#1455050 - AcceptedFreezeException - We'd love to get a fix for this CVE in for Beta. 17:49:41 +1 17:49:41 proposed #accepted 1455050 - AcceptedFreezeException (Beta) - this is a serious and widely-known security issue, we should not ship a Beta vulnerable to it 17:49:46 ack 17:49:47 grr 17:50:02 proposed #agreed 1455050 - AcceptedFreezeException (Beta) - this is a serious and widely-known security issue, we should not ship a Beta vulnerable to it 17:50:09 ack to adamw 17:50:13 ack 17:50:19 ack ack 17:51:09 #agreed 1455050 - AcceptedFreezeException (Beta) - this is a serious and widely-known security issue, we should not ship a Beta vulnerable to it 17:51:29 is that all from the Mini-blocker review ? 17:51:52 think so 17:51:54 roshi, adamw: thanks 17:51:57 #topic Test Matrices coverage 17:52:01 #info As there is no RC yet, Test matrices are not ready as well 17:52:07 #info We are skipping the Test Matrices coverage check 17:52:09 right, our coverage is standing at a nice, round number right now :) 17:52:18 :) 17:52:20 isn't there a 'compose is available' check, anyway? 17:52:24 it's in the preamble 17:52:31 yeah 17:52:34 #info This is determined in a few ways: 17:52:35 #info * No remaining blocker bugs 17:52:35 #info * Release candidate compose is available 17:52:35 #info * Test matrices for Beta are fully completed 17:52:47 seems like we should have a "is there a candidate?" section between the blocker bug section and the matrix check 17:53:25 I just wanted to state in the minutes that we skip this due to unavailable RC 17:53:37 anyhoo, just a process noet 17:53:55 #topic Go/No-Go decision 17:54:00 here we go ... 17:54:05 GO! 17:54:08 No-Go 17:54:10 oh, maybe not 17:54:23 No-Go 17:54:29 lets just reship alpha and see if anyone notices? ;) 17:54:35 it's pretty clear we are no go 17:54:53 No-Go 17:55:07 +1 nirik 17:55:17 slap a coat of paint on it 17:55:24 #info QA votes no-go as there is no candidate. 17:55:27 proposed #info Fedora Project Lead is unsure whether we should ship nonexisting compose 17:55:32 lol 17:56:06 proposed #agreed Due to missing RC for the F26 Beta release and presence of blocker bugs, the decision is “No Go”. We slip the release for one week. 17:56:14 just think - it's guaranteed to have absolutely no bugs at all 17:56:20 patch 17:56:24 the perfect release! 17:56:27 proposed #agreed Due to missing RC for the F26 Beta release and presence of blocker bugs, the decision is “No Go”. We ship the release for one week. 17:56:33 just like the sysadmin's dream of having no users 17:57:01 ack 17:57:13 +1 17:57:43 #agreed Due to missing RC for the F26 Beta release and presence of blocker bugs, the decision is “No Go”. We slip the release for one week. 17:57:52 #action jkurik to publish the Go/No-Go result 17:57:54 #action jkurik to organize second round of Go/No-Go meeting for F26 Beta in one week at the same time 17:58:06 #topic Open floor 17:58:07 anything else to discuss today on this meeting ? 17:58:11 yeah... 17:58:29 Can I do anythin gto help coordinate the libdb bug? 17:58:36 bug fix, I mean? :) 17:59:32 Or is that conversation already happening (adamw I guess) and I'd just add more noise? 18:00:55 sorry 18:00:57 uh 18:01:06 i think it should be ok, the dev's been active on the bug 18:01:12 if we hit any roadblocks i'll let you know 18:01:59 adamw: thanks! I'll do what I can if needed, sit back out of the way otherwise :) 18:02:10 ok, anything else ? 18:03:01 Thanks everybody and see at least some of you in one hour on the Readiness meeting 18:03:10 #endmeeting