16:01:22 #startmeeting F28-blocker-review 16:01:22 Meeting started Mon Mar 26 16:01:22 2018 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:22 The meeting name has been set to 'f28-blocker-review' 16:01:22 #meetingname F28-blocker-review 16:01:22 #topic Roll Call 16:01:22 The meeting name has been set to 'f28-blocker-review' 16:01:30 * kparal is here 16:01:30 morning folks! who's around for blocker review fun? 16:01:32 .hello2 16:01:32 * pwhalen is here 16:01:32 frantisekz_: Sorry, but you don't exist 16:01:35 * lbrabec is here 16:01:42 .hello2 16:01:43 sgallagh: sgallagh 'Stephen Gallagher' 16:01:48 .hi lailah 16:01:55 .fas lailah 16:01:55 Lailah: lailah 'Sylvia Sánchez' 16:02:00 * coremodule is here 16:02:05 * Lailah is here 16:02:07 hi! 16:02:12 Hi1 16:02:56 .hello2 16:02:57 frantisekz: frantisekz 'František Zatloukal' 16:03:52 .hello2 16:03:53 puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' 16:04:46 note: blocker review is guaranteed, 'fun' is not 16:05:00 okay 16:05:09 We have been warned 16:05:48 Mis-advertising! 16:07:23 puiterwijk: there was an asterisk and some four point text you couldn't possibly read on your tv! 16:07:26 alrighty 16:07:31 * lruzicka is here, too 16:07:35 #chair sgallagh puiterwijk 16:07:35 Current chairs: adamw puiterwijk sgallagh 16:07:58 Willing to secretarialize! 16:08:49 uhm... 16:08:56 * Lailah looks around 16:09:07 sorry 16:09:15 i started pasting bolierplate into entirely the wrong irc channel :P 16:09:20 can i go back to bed and start monday again please? :) 16:09:21 #topic Introduction 16:09:21 Why are we here? 16:09:21 #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:09:23 #info We'll be following the process outlined at: 16:09:23 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:09:25 #info The bugs up for review today are available at: 16:09:26 #link http://qa.fedoraproject.org/blockerbugs/current 16:09:28 #info The criteria for release blocking bugs can be found at: 16:09:30 #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:09:32 #link https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria 16:09:34 #link https://fedoraproject.org/wiki/Fedora_28_Final_Release_Criteria 16:09:36 we have: 16:09:38 #info 1 Proposed Blocker (Beta) 16:09:42 #info 6 Accepted Blockers (Beta) 16:09:48 #info 10 Proposed Freeze Exceptions (Beta) 16:09:53 #info 12 Accepted Freeze Exceptions (Beta) 16:10:04 #info 6 Proposed Blockers (Final) 16:10:14 #info coremodule will secretarialize 16:10:25 so, let's start with the proposed Beta blocker, obviously... 16:10:30 #topic (1559680) Realm join via kickstart during install fails with 'This computer's host name is not set correctly', but it is 16:10:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1559680 16:10:30 #info Proposed Blocker, anaconda, NEW 16:10:30 hello guys 16:10:33 hi kalev 16:10:36 this one seems like a clear +1 to me. 16:10:38 adamw: +1 blocker on that. 16:10:47 +1 16:10:58 Can I get a second to read it quickly? 16:11:02 Very very quickly 16:11:11 +1 16:11:14 Lailah: sure 16:11:31 Lailah: executive summary: domain enrolment during install using a kickstart fails, criteria say it should work. 16:11:32 * sgallagh voted +1 on BZ as well 16:11:41 * puiterwijk also just voted +1 on the BZ 16:11:59 i mean, i suppose this would work if you happened to have a setup where an appropriate hostname was doled out by DHCP, but we can't really rely on that. 16:12:00 Oh, now I see... 16:12:07 Yes, I'm +1 16:12:12 +1 16:12:13 I asked rvykdal to look into it this morning and he's pretty sure he has a fix 16:12:18 +1 16:12:23 sgallagh: yeah, mkolman is on it. 16:13:13 proposed #agreed 1559680 - AcceptedBlocker (Beta) - clear violation of "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain" (in all cases where a correct hostname is not set via DHCP) 16:13:18 Ack 16:13:20 ack 16:13:24 ack 16:13:25 ack 16:13:26 ack 16:13:27 ack 16:13:45 ack 16:13:53 #agreed 1559680 - AcceptedBlocker (Beta) - clear violation of "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain" (in all cases where a correct hostname is not set via DHCP) 16:14:22 #info moving onto proposed Beta freeze exceptions (as we're close to Beta go/no-go again) 16:14:29 #topic (1551279) authselect pulls in a LOT of extra dependencies than authconfig 16:14:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1551279 16:14:29 #info Proposed Freeze Exceptions, authselect, ON_QA 16:14:49 i've proposed both bugs that the authselect update fixes as FEs, as they both seem like good things to have fixed in beta to me. 16:15:25 (this one, i bet, is also behind at least one of the mysterious size bloats we've had with images lately) 16:15:58 +1 FE 16:15:59 I think that one would be nice to include indeed. +1 FE from me 16:16:02 +1 16:16:07 +1 FE 16:16:08 +1FE 16:16:12 +1 fe 16:16:24 +1 16:16:44 adamw: Though, before it gets pushed stable, I'd like to double-check that they didn't drop anything we might need to add back into comps 16:16:55 sgallagh: yeah, there is that bear trap 16:16:58 #action sgallagh to review the dropped deps 16:17:04 sgallagh: thanks 16:18:09 proposed #agreed 1551279 - AcceptedFreezeException (Beta) - we accept this on the basis that it's desirable to remove the unwanted bits from images, particularly minimal images. sgallagh will verify that comps/kickstarts ensure the necessary packages are pulled into appropriate images without these dependencies 16:18:21 ack 16:18:22 ack 16:18:25 ack 16:18:27 ack 16:18:27 ack 16:18:29 ack 16:18:38 ack 16:18:39 ack 16:19:40 #agreed 1551279 - AcceptedFreezeException (Beta) - we accept this on the basis that it's desirable to remove the unwanted bits from images, particularly minimal images. sgallagh will verify that comps/kickstarts ensure the necessary packages are pulled into appropriate images without these dependencies 16:19:48 #topic (1560046) authselect is missing dependency on dconf package 16:19:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=1560046 16:19:49 #info Proposed Freeze Exceptions, authselect, ON_QA 16:20:09 this is the other thing the update fixed (note, description is slightly wrong, the fix was not to add a dependency on dconf, but to make authselect work OK when it's not present) 16:21:04 Oh, I see 16:21:14 Well, I'm +1 FE on this too. 16:21:21 +1 16:21:24 +1 16:21:25 +1 16:21:28 +1 16:21:46 +1 16:22:26 proposed #agreed 1560046 - AcceptedFreezeException (Beta) - we accept this on the grounds there could be significant install/upgrade-time consequences from authselect not behaving as expected with dconf not present 16:22:46 ack 16:22:47 ack 16:22:47 ack 16:22:51 ack 16:23:02 ack 16:23:08 #agreed 1560046 - AcceptedFreezeException (Beta) - we accept this on the grounds there could be significant install/upgrade-time consequences from authselect not behaving as expected with dconf not present 16:23:18 #topic (1164492) Please drop libvirt 'default' network dependency for F28 GA (also Beta?), disrupts livecd networking 16:23:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=1164492 16:23:18 #info Proposed Freeze Exceptions, gnome-boxes, ASSIGNED 16:23:27 this one should just be grandfathered right into 'accepted'... 16:23:53 same old mess with libvirt's networking interfering with live images that we hit every release, this is the workaround we always wind up with. 16:23:55 I've never really understood what's going on with this bug, but +1 as we've been doing this dance forever :) 16:24:29 * sgallagh waves his hand dismissively 16:24:35 I have seen that this is old as hell. If there is a slight change of getting rid of it .... +1 16:24:35 Is this coming from Fedora 21? 16:24:37 Wow 16:24:40 kalev: basically it's to do with libvirt's default network setup kicking in when you boot the live image in a VM that *is itself a libvirt guest*, so the routes get messed up and connections can never get out. 16:24:59 * kalev nods. 16:25:01 +1 16:25:04 +1 16:25:07 +1 16:25:10 +1 16:25:16 lruzicka: unfortunately no-one's ever managed to figure out a way to 'fix' it properly, so what we do every release is fiddle with the dependencies to avoid the issue happening, then change them back right after release :( 16:25:52 adamw: Oh ... 16:25:53 kalev: iirc we came up with some trick that fixes it for installed systems a while ago, but for handwavey reasons i'd have to go look up, we still can't fix it for lives, or something along those lines. i forget those details. 16:27:07 +1 16:27:27 proposed #agreed 1164492 - AcceptedFreezeException (Beta) - accepted for the same reason this workaround always is, we want to avoid networking on Workstation live boots being broken by this, and we still haven't figured out a permanent fix. 16:27:29 ack 16:27:32 ack 16:27:36 ack 16:27:37 ack 16:27:39 ack 16:27:41 ack 16:27:44 ack 16:28:21 #agreed 1164492 - AcceptedFreezeException (Beta) - accepted for the same reason this workaround always is, we want to avoid networking on Workstation live boots being broken by this, and we still haven't figured out a permanent fix. 16:28:30 * adamw has an awful suspicion the 'ultimate' fix for this is called 'ipv6 16:30:47 #topic (1558648) Can’t remove libvirt-daemon 16:30:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=1558648 16:30:47 #info Proposed Freeze Exceptions, libvirt, ON_QA 16:31:25 owch, yeah, i ran into this one. we should make it an FE for sure. 16:31:28 owwww, this one might even be a blocker, if it's in a default install 16:31:52 i'm ok with just saying FE, since we have the fix already. 16:31:54 and I think it's on Workstation at least 16:31:56 * kalev nods. 16:31:57 +1 FE 16:32:02 +1 fe 16:32:03 +1 FE 16:32:08 +1 FE 16:32:16 I find this one weird... why is not possible to remove libvirt? 16:32:19 Anyway 16:32:21 +1 16:32:35 +1 16:33:05 Lailah: the remove operation always fails because the scriptlet fails 16:33:12 so the package is still 'there' as far as the database is concerned 16:33:15 Ah. 16:33:24 Oh 16:33:31 Okay, got it 16:33:46 Thanks for the explanation adamw 16:33:49 proposed #agreed 1558648 - AcceptedFreezeException (Beta) - running into this bug requires the user to do manual cleanup, so we really should get the broken package out of the stable path ASAP 16:34:32 ack 16:34:32 ack 16:34:33 ack 16:34:37 ack 16:34:38 #agreed 1558648 - AcceptedFreezeException (Beta) - running into this bug requires the user to do manual cleanup, so we really should get the broken package out of the stable path ASAP 16:34:44 #topic (1558510) "Star" feature missing in Nautilus 16:34:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1558510 16:34:45 #info Proposed Freeze Exceptions, nautilus, NEW 16:34:56 so quick ... I was thinking about a patch :) 16:35:16 ack 16:35:28 lruzicka: sorry! 16:35:39 trying to get through the list fast as it's quite long :( 16:35:47 it's ok, no big deal :) 16:35:48 kalev: so is the summary here 'it's working as expected'? 16:36:27 adamw: Which one, the last one? 16:36:34 this one. 1558510. 16:36:46 adamw: yeah, I think so 16:37:02 it did not work for me this afternoon 16:37:06 from the comments, it looks like there may not really be a 'bug' to fix here at all, just the feature doesn't behave as the reporter expected. 16:37:16 * kalev nods. 16:37:27 lruzicka: it's a question of what you mean by 'work'. it seems the feature applies only to "the XDG home directories" 16:37:31 I don't see this as a blocker 16:37:34 which is stuff like ~/Pictures , ~/Music etc 16:38:07 adamw: kalev: True, but even in those directories, I could not star every directory created there. 16:38:28 For example, I created one directory through Nautilus, I could star it 16:38:41 but i could not star a directory created via CLI 16:38:55 and then, I created another with Nautilus, could not star it either 16:39:32 isn't it done based on Tracker data ? 16:39:42 this was the situation in 20180325.0.iso, updated this afternoon (virtual machine) 16:40:03 maybe it would make sense to just remove the feature then altogether, if it's not working well 16:40:19 I'm -1 FE here. Nautilus is too fundamental to the Workstation experience to risk patches that probably touch deep, fundamental code while we're in Freeze 16:40:22 that would make sense - Nautilus can tell Tracker about the new folder but Tracker would not know about a new folder created via CLI (unless it sits on global inotify or something similar) 16:40:30 but I don't see anything right now that warrants an FE, there's nothing to backport to Fedora 16:40:31 Let them fix it post-Beta 16:40:42 -1 FE 16:40:49 agree -1 FE 16:40:58 -1 16:41:00 (but there's certainly issues and I'd suggest to file them upstream at gitlab.gnome.org to get more traction) 16:41:28 -1 16:42:23 -1 16:42:44 -1 16:45:51 proposed #agreed 1558510 - RejectedFreezeException (Beta) - from discussion in-bug and in-meeting, there doesn't really seem to be anything that's clearly a bug here (rather a case of mismatched user expectations), and certainly not something worth changing nautilus for during freeze 16:46:09 ack 16:46:13 ack 16:46:14 ack 16:46:17 ack 16:46:19 ack 16:46:51 ack 16:48:23 #agreed 1558510 - RejectedFreezeException (Beta) - from discussion in-bug and in-meeting, there doesn't really seem to be anything that's clearly a bug here (rather a case of mismatched user expectations), and certainly not something worth changing nautilus for during freeze 16:48:36 #topic (1560209) qt5-qtwebengine: 16 security vulnerabilities 16:48:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=1560209 16:48:37 #info Proposed Freeze Exceptions, qt5-qtwebengine, MODIFIED 16:48:56 +1 FE 16:49:05 +1 FE 16:49:17 +1 fe 16:49:18 dunno, it hasn't yet pushed to any repos and nobody has tested it 16:49:32 Not true, it's in updates-testing already. 16:49:36 ah ok :) 16:50:08 Also, the F27 build has +3 karma and was pushed to stable, the F26 build has +1 karma and was pushed or is being pushed to stable. 16:50:22 +1 FE 16:50:28 kalev: technically, we're voting on whether the *issue* is FE-worthy, not whether the current update fixes it properly. sometimes there's a bit of a grey area there, but the distinction matters. 16:50:45 Kevin_Kofler: fair enough, sounds like it's gotten a fair bit of testing then 16:50:48 definitely +1 FE 16:50:48 * kalev nods. 16:50:51 +1 FE 16:51:10 +1 FE 16:51:44 proposed #agreed 1560209 - AcceptedFreezeException (Beta) - it's obviously desirable to fix multiple security issues in a key package in a release-blocking image (KDE live) 16:51:53 we also have a firefox update in updates-testing, I wonder if that makes sense to pull in as well then? 16:51:53 yup, ack 16:51:55 ack 16:51:56 ack 16:52:00 +1 FE and Ack 16:52:01 ack 16:52:02 ack 16:52:11 kalev: hum, didn't i propose that one? i thought i was going to 16:52:16 (sorry, was still juggling the authselect issue) 16:52:26 it also has security fixes (cansecwest ones), so yeah, we should pull it in 16:52:34 does someone want to find a bug and propose it? 16:52:41 #agreed 1560209 - AcceptedFreezeException (Beta) - it's obviously desirable to fix multiple security issues in a key package in a release-blocking image (KDE live) 16:53:02 adamw: I don't think it's proposed 16:53:09 The bug status MODIFIED was misleading, that's a Bodhi glitch when you add a bug ID when the update is already in updates-testing. 16:53:11 if someone could do that, that'd be great 16:53:17 ack 16:53:21 we can discuss it at the end of the list 16:53:21 #topic (1559531) SELinux preventing gdm from starting 16:53:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=1559531 16:53:22 #info Proposed Freeze Exceptions, selinux-policy, POST 16:53:31 I manually moved the qt5-qtwebengine bug to ON_QA. 16:53:36 +1 for me, it would of course be nice to have working FAW images in the beta. 16:53:42 +1 16:53:43 +1 16:53:44 +1 16:53:44 +1 from me too 16:54:00 Ah, only Atomic Workstation. I was wondering why this wasn't a blocker. 16:54:01 +1 16:54:07 +1 FE 16:54:12 proposed #agreed 1559531 - AcceptedFreezeException (Beta) - this is preventing Atomic Workstation installs from booting, of course we would like these fixed for the Beta 16:54:15 ack 16:54:26 ack 16:54:35 ack 16:54:39 ack 16:54:40 ack 16:54:49 ack 16:55:27 #agreed 1559531 - AcceptedFreezeException (Beta) - this is preventing Atomic Workstation installs from booting, of course we would like these fixed for the Beta 16:55:30 #topic (1559677) SELinux denials for FreeIPA in Fedora 28 16:55:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1559677 16:55:31 #info Proposed Freeze Exceptions, selinux-policy-targeted, ON_QA 16:55:44 none of these seem to prevent the tests actually working, but whatever it is they break, it can't be good. :P 16:56:28 * kalev nods. 16:56:30 +1 FE 16:56:30 +1 16:56:35 +1 FE 16:56:36 +1 16:56:38 +1 FE 16:56:56 +1 FE, considering they will probably get picked up by some blocker policy update anyway 16:57:40 heh 16:58:00 Wow... what happened there? 16:58:21 I'm Lailah BTW 16:58:25 proposed #agreed 1559677 - AcceptedFreezeException (Beta) - it's desirable to avoid SELinux denials to a blocker path function (FreeIPA server), and SELinux policy easing is a very safe activity 16:58:28 +1 FE. And I think that the pki denials are related to performance data so not crucial to working. The gssproxy ones surprise me that they don't break stuff 16:58:33 +1 FE 16:58:35 ack 16:58:40 ack 16:58:41 Kohane: i didn't see anything happen to your other ID... 16:58:55 ack 16:58:56 Well, it suddenly changed 16:59:00 #agreed 1559677 - AcceptedFreezeException (Beta) - it's desirable to avoid SELinux denials to a blocker path function (FreeIPA server), and SELinux policy easing is a very safe activity 16:59:07 ack 16:59:08 Oh... 16:59:09 ack 16:59:40 #topic (1560504) Don't autostart gnome-software on live media 16:59:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=1560504 16:59:40 #info Proposed Freeze Exceptions, spin-kickstarts, NEW 16:59:47 much +1 very yes 16:59:58 So yes. Very +1. 17:00:03 adamw: I was Lailah, I'm there in the list, but for some reason Hexchat says my nick is already in use so it changed to Kohane. Go ad figure... 17:00:08 +1 17:00:11 +1 17:00:12 +1 17:00:14 Oh, yeaah, that one 17:00:15 +1 17:00:15 Kohane: IRC! 17:00:16 +1 17:00:16 +1 17:00:29 Kohane: You got disconnected from IRC and probably rejoined to a different load-balanced server 17:00:38 +1 17:00:43 (OT: I just filed the firefox FE) 17:00:55 proposed #agreed 1560504 - AcceptedFreezeException (Beta) - this obviously causes unnecessary resource usage (especially RAM and bandwidth) during live boots and cannot be fixed with an update 17:00:56 that's why you sometimes see people with _ or __ behind their names 17:01:04 ack 17:01:05 such ack 17:01:07 ack 17:01:08 ack 17:01:13 ack 17:01:16 ack 17:01:16 Kohane: You can switch back to Lailah :) 17:01:17 oh, I see mkolman 17:01:30 the original name should eventually time out in a few minutes 17:01:35 #agreed 1560504 - AcceptedFreezeException (Beta) - this obviously causes unnecessary resource usage (especially RAM and bandwidth) during live boots and cannot be fixed with an update 17:01:36 ack 17:01:47 Or if you're authed, you can /msg nickserv ghost it 17:01:50 #topic (1559629) persistent interface names are wrong for some interfaces 17:01:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=1559629 17:01:50 #info Proposed Freeze Exceptions, systemd, NEW 17:01:56 Oh! Nice... but how do I switch back? 17:02:15 if you are using hexchat, just click on your name on bottom left 17:02:18 I'd actually raise this as a blocker, because this would break network (and therefore package update capability) for a lot of people. 17:02:31 Kohane: Use the /nick command to change it 17:02:33 Kohane: or just type /nick Lailah 17:02:45 There you go 17:02:47 Yay! 17:02:56 +1 FE 17:03:02 +1 FE 17:03:28 +1 FE 17:03:32 do we have any case where this actually breaks networking? 17:03:38 adamw: Do we have any criteria around non-standard networking 17:03:42 Like Bonds and Bridges? 17:03:50 Because those would be likely to be broken by a name change 17:03:51 not really, no. 17:04:12 OK, then I guess I'll go with +1 FE for now. 17:04:15 frantisekz: probably any case where the interface needs more than just DHCP magic to work properly. 17:04:19 At least a fix is already incoming 17:04:23 yeah, was gonna note that 17:04:31 +1 FE (at least) 17:04:32 https://koji.fedoraproject.org/koji/buildinfo?buildID=1060232 is the fix 17:04:50 +1 FE 17:04:53 +1 fe 17:05:00 i could certainly see the blocker argument, but i'm OK with just FE for now, i'll make sure we pull in the fix. 17:05:05 The blocker question is mainly about "what if the fix is wrong?" 17:05:17 Or incomplete, etc. 17:05:40 yeah, i know. 17:05:52 if that's the case, we can revisit 17:05:55 ack 17:05:57 * kalev agrees. 17:06:19 * Lailah agrees too 17:06:29 sgallagh: you can't possibly ack yet. :P 17:06:50 adamw: we can acknowledge that we read your message? :) 17:07:32 proposed #agreed 1559629 - AcceptedFreezeException (Beta) - this could break many network configurations on upgrade, and upgrades use the stable repositories (not updates-testing), so we should get this fixed in stable ASAP 17:07:37 ack 17:07:38 ack 17:07:40 ack 17:07:40 ack 17:07:54 ack 17:07:54 (and, i guess, even fresh installs with pre-canned kickstarts...) 17:08:05 #agreed 1559629 - AcceptedFreezeException (Beta) - this could break many network configurations on upgrade, and upgrades use the stable repositories (not updates-testing), so we should get this fixed in stable ASAP 17:08:34 zbyszek: we just accepted it :) 17:08:52 #topic (1557571) Firefox 59.0.1 available: CVE-2018-5146: Out of bounds memory write in libvorbis 17:08:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=1557571 17:08:52 #info Proposed Freeze Exceptions, firefox, NEW 17:08:56 here's the firefox one 17:09:10 +1 for me - basically new firefox with fixes for multiple security issues showed up since freeze, we should pull it in. 17:09:13 +1 FE 17:09:18 +1 FE 17:09:21 careful when pull this in as a FE, may need an nss update as well 17:09:21 +1 fe 17:09:22 +1 FE 17:09:33 +1 fe 17:09:40 +1 FE 17:09:44 +1 17:09:46 kalev: I think that f28 already had 59.0.0 and there were no other changes 17:09:55 * puiterwijk verifies 17:10:04 +1 FE 17:10:16 adamw: that Anaconda fix: https://bodhi.fedoraproject.org/updates/FEDORA-2018-34ea87ba41 17:10:20 +1 FE if firefox is the ONLY package that needs updating. 17:10:23 no, F28 had firefox-58.0.2-1.fc28 17:10:29 If it involves nss/nspr... NO 17:10:34 * adamw checks too 17:10:49 'koji latest-build f28 firefox' to check 17:11:01 Yep 17:11:03 Looks like just Firefox 17:11:04 OK 17:11:21 [adamw@adam anaconda (master %)]$ koji latest-build f28 firefox 17:11:22 Build Tag Built by 17:11:22 ---------------------------------------- -------------------- ---------------- 17:11:22 firefox-58.0.2-1.fc28 f28 xhorak 17:11:47 but yeah, there is no nss/nspr build alongside the new firefox... 17:11:59 Both 58.0.2 and 59.0 require nss 3.30 17:12:19 * adamw is running firefox-59.0.1-1.fc28 with nss-3.36.0-1.0.fc28.x86_64 and it's working. 17:12:32 So no new NSS or NSPR 17:12:58 proposed #agreed 1557571 - AcceptedFreezeException (Beta) - it's obviously desirable to fix significant security issues in the default browser for most desktops for Beta. Note we have verified no nss/nspr update is required here. 17:13:03 adamw: thanks for checking 17:13:07 Wait, 3.30 or 3.36? 17:13:07 ack 17:13:09 ack 17:13:10 ack 17:13:12 ack 17:13:14 mkolman: thanks! 17:13:21 sgallagh: they require 3.30's API 17:13:26 ack 17:13:28 sgallagh: I understand is 3.30 17:13:29 I'm just looking at the deps 17:13:46 well, hang on 17:13:47 ack 17:13:53 Because 3.36 isn't in stable 17:13:54 i have 3.36.0-1.0... 17:14:08 stable tagged is nss-3.35.0-4.fc28 17:14:09 ah right, nss-3.35.0-4.fc28 is in F28 17:14:21 hold on, i have robots for this. 17:14:31 beep bloop 17:14:48 xD 17:15:20 https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=28&build=Update-FEDORA-2018-3de9cb411f&groupid=2 17:15:24 that all worked fine. 17:15:37 that would've tested current f28 stable packages, plus the updated firefox. 17:15:41 browser worked, freeipa tests worked. 17:15:52 ok 17:16:07 (Forgive me for being paranoid, but NSS has... a history) 17:16:25 yeah, no, i quite agree 17:16:28 yeah, that's understandable 17:16:35 yeah, that's why I flagged nss up as well :) 17:16:51 Better safe than sorry sgallagh 17:17:16 * adamw will double-triple check this before pushing. 17:17:22 but still 17:17:22 adamw: Thanks 17:17:26 #agreed 1557571 - AcceptedFreezeException (Beta) - it's obviously desirable to fix significant security issues in the default browser for most desktops for Beta. Note we have verified no nss/nspr update is required here. 17:18:23 #info Accepted Beta blockers 17:18:35 #info all accepted Beta blockers are ON_QA or VERIFIED except one: 17:18:40 #topic (1558641) cloud-init creates bogus metadata route preventing metadata setup 17:18:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=1558641 17:18:41 #info Accepted Blocker, cloud-init, NEW 17:18:51 bureaucracy note, we are *not* voting on whether this is a blocker 17:18:54 it already si 17:19:00 we are checking in on progress in fixing it 17:19:01 +1 blocker ;-) 17:19:03 so...what's the score? 17:19:07 .fire sgallagh 17:19:07 adamw fires sgallagh 17:19:16 Woohoo! Vacation! 17:19:21 I think the fix for that was clear, as it's part of the cloud-init template. 17:19:28 .hire sgallagh at reduced salary 17:19:28 adamw hires sgallagh at reduced salary 17:19:39 Heh 17:19:41 It just needs to be applied... If the maintainer doesn't do that today, I can look at that 17:19:42 LOL 17:19:46 Ah, he's here 17:20:00 Who? Who's here? 17:20:12 gholms: is the maintainer of cloud-init if I don't misremember 17:20:13 I am swamped with work at $dayjob, so if anyone wants to apply a fix just do it. 17:20:18 Sorry. :( 17:20:20 Okay, will do so today then 17:20:23 thanks for the heads up 17:20:24 Thanks 17:20:35 #info fix for this is clear and just needs to be applied, gholms is busy so puiterwijk will do it 17:20:46 #action puiterwijk to fix #1558641 17:20:53 adamw: So with that... sounds like an RC candidate today? 17:21:03 sgallagh: once i line up all these ducks, yeah. 17:21:12 Careful, some of them bite 17:21:29 Yay, RC 17:21:50 Fedora 29: Bitin' Ducks 17:21:55 How can a duck bite if it has no teeth? 17:22:05 sharp gums 17:22:09 Lailah: you should try it out. It can hurt :) 17:22:11 Ah 17:22:12 ok, let's do final blockers quick 17:22:14 (or so I've been told) 17:22:17 Lailah: Have you hear about teethless bite? 17:22:25 Nope. 17:22:27 #info moving on to proposed Final blockers 17:22:45 #topic (1558027) The network.service failed LSB in Fedora Cloud. 17:22:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=1558027 17:22:45 #info Proposed Blocker, distribution, ON_QA 17:23:51 Sorry, I moved that bug to MODIFIED by mistake. Fixed now. 17:24:08 Uh... 17:24:12 hmmm 17:24:18 Internet is so slow today... 17:24:45 FWIW, https://bodhi.fedoraproject.org/updates/systemd-238-5.fc28 will fix that one too. 17:24:57 is the cloud base image a blocking medium? 17:25:26 Ah, it is. 17:25:40 I tested for this earlier in the week on EC2 and did not see this as an issue... 17:26:33 coremodule: Were you able to reproduce it? 17:26:35 I did see it on my EC2 and openstack tests 17:27:16 we actually fixed this in kickstarts, i believe. 17:27:33 Just FYI: I have no opinion about this one, I don't understand much about Cloud... 17:27:42 https://pagure.io/fedora-kickstarts/c/9a25016bacaf0e9a00fa72a3c93f19632646f1ba?branch=f28 17:27:45 Yeah, I think we did. 17:27:47 rm -f /etc/sysconfig/network-scripts/ifcfg-en* 17:27:56 that's why i put the bug in ON_QA. 17:28:05 of course, merging the systemd fix for the predictable names would also 'fix' this. 17:28:06 Yeah, what adamw said 17:28:18 still, for now the bug is open. i forget, is there a case where this actually breaks networking? 17:28:57 For me, when I discovered this error, networking was still operating. 17:29:11 i think it was openstack where it can break, right? 17:29:14 I don't think so 17:29:21 adamw: no, the breakage was the cloud-init routing 17:29:41 oh, right. and we have a criterion saying cloud-init has to work 17:29:47 The failed network.service was not actually breakin anything, since cloud-init will configure the correct interface 17:29:58 Yes, the cloud-init routing bug is what I'm fixing now 17:30:30 (previous topic) 17:31:16 i guess +1, fine. 17:33:38 I'm +1 based on "no failed services" 17:33:46 +1 17:33:52 +1 17:34:05 so, if it does not break anything, a blocker anyway? 17:34:21 lruzicka: yeah, I think "no failed services with default package set" is a release criteria 17:34:24 And this fails that criteria 17:34:43 criterion? 17:34:45 ok, I know it was a part of criteria. Thats why I proposed 17:34:49 :) 17:34:52 +1 B 17:34:59 +1 17:35:00 +1 17:36:26 proposed #agreed 1558027 - AcceptedBlocker (Final) - accepted as a violation of "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present", for the Cloud base image (which is release-blocking) 17:36:44 ack 17:37:07 ack 17:37:09 ack 17:37:19 ack 17:38:14 #agreed 1558027 - AcceptedBlocker (Final) - accepted as a violation of "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present", for the Cloud base image (which is release-blocking) 17:38:23 #topic (1164492) Please drop libvirt 'default' network dependency for F28 GA (also Beta?), disrupts livecd networking 17:38:24 #link https://bugzilla.redhat.com/show_bug.cgi?id=1164492 17:38:24 #info Proposed Blocker, gnome-boxes, ASSIGNED 17:38:39 this is the one we just reviewed as FE for Beta, i'm also +1 final blocker for it (we usually block final on this) 17:38:46 +1 final blocker 17:38:48 +1 final blocker 17:39:03 +1 Final Blocker 17:39:07 +1 FB 17:39:41 +1 17:40:06 +1 17:41:10 +1 17:42:12 sorry, just finding criterion 17:42:39 +1 Final Blocker 17:43:50 proposed #agreed 1164492 - AcceptedBlocker (Final) - once again accepted as a Final blocker as a violation of all criteria related to networking, in the case of libvirt guests booting/installing from the Workstation live image 17:44:42 ack 17:44:44 ack 17:44:54 ack 17:45:02 ack 17:45:04 ack 17:45:05 ack 17:45:20 #agreed 1164492 - AcceptedBlocker (Final) - once again accepted as a Final blocker as a violation of all criteria related to networking, in the case of libvirt guests booting/installing from the Workstation live image 17:45:30 #topic (1555292) Fedora Workstation Live can't resume after suspend when booted from DVD connected via an external drive 17:45:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=1555292 17:45:31 #info Proposed Blocker, kernel, NEW 17:46:46 I haven't followed the auto suspend mailing list thread at all. Is the current plan to keep auto suspending for F28? 17:47:26 i think last time this came up we agreed we were going to try and reanimate that discussion 17:47:30 and also ping the list for more testing 17:47:34 not sure we did either of those yet 17:47:35 kparal? 17:48:01 I didn't 17:48:18 perhaps we should've assigned an action item 17:48:27 last time I got the impression you want to do it, adamw ;-) 17:48:54 oh, i thought you were going to do it :) 17:48:59 I believe frantisekz is the volunteer here 17:49:04 i'm usually sloppy with the action items in these meetings as there's no process to actually *check* on them 17:49:08 (unlike the qa meeting ones) 17:49:11 * Lailah chuckles 17:49:20 he's the most passionate suspend hater in our team 17:49:25 frantisekz: congratulations for volunteering 17:49:51 (adamw: give him an action item) 17:49:54 thanks ... /me checking what I am volunteering for 17:50:05 =) 17:50:10 so 17:50:45 proposed #agreed 1555292 - punt (delay decision) - status is still as it was in go/no-go meeting, we wish to gather more testing data and also restart the discussion on whether auto-suspend should be disabled on lives before making a decision here 17:51:00 ack 17:51:03 ack 17:51:05 ack 17:51:17 ack 17:51:19 ack 17:51:25 ack 17:51:27 #action frantisekz or kparal or adamw (in that order) to post call for testing of suspend from live environment on test@ and restart desktop@ discussion about whether auto-suspend should be disabled by default on lives 17:51:32 there we go =) 17:51:37 #agreed 1555292 - punt (delay decision) - status is still as it was in go/no-go meeting, we wish to gather more testing data and also restart the discussion on whether auto-suspend should be disabled on lives before making a decision here 17:51:43 #topic (1556132) ppp: FTBFS in F28; DES code needs to be ported to OpenSSL 17:51:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=1556132 17:51:44 #info Proposed Blocker, ppp, NEW 17:51:55 iow, if it doesn't happen, it's adamw's fault, because he was the last link 17:52:00 .fire kparal 17:52:00 adamw fires kparal 17:52:09 Again? 17:52:15 a mail i just read suggests that FESCo has actually *declared* this to be a final blocker 17:52:22 adamw: you can't escape logic! 17:52:23 Lailah: if he doesn't get fired at least three times a day he gets slack 17:52:33 Oh, okay 17:52:34 * adamw runs a tight ship 17:52:50 msekleta said that he couldn't wait any more, and asked me to convey that: 17:53:03 "I talked to Jaroslav and he is working on the port to openssl 17:53:15 #info per https://bugzilla.redhat.com/show_bug.cgi?id=1556132#c1 FESCo has actually declared this to be a blocker, meaning we have nothing to vote on here, it just goes straight to AcceptedBlocker 17:53:26 "over the weekend I tested pppd as pppoe backend (common case in xDSL setups) and current build that is in f28 now seems to work fine against libxcrypt" 17:53:32 Yeah, there's a comment from about an hour ago where Jaroslav said he hopes to get it tomorrow 17:53:43 ack 17:54:08 zbyszek: ah, that's good news. 17:54:28 #topic (1559341) SELinux blocks bluetooth from working 17:54:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=1559341 17:54:28 #info Proposed Blocker, selinux-policy, ON_QA 17:54:34 we just took this as a Beta FE 17:54:44 so probably not worth wasting too much time arguing if it's a final blocker... 17:54:48 but we can waste a few minutes! why not. 17:55:08 Why SELinux is blocking Bluetooth? 17:55:17 My internet is faulty, sorry 17:57:38 it wasn't *supposed* to. 17:57:48 this sort of thing just happens quite often when general tightenings are made to selinux policy 17:57:54 punt and it will go away 17:58:06 they turn out to block things we don't want them to block, so we have to loosen the policy again for those things 17:58:09 it's an eternal process 17:58:34 Doh.. 17:58:49 let's punt and revisit if this doesn't get fixed with the beta FE 17:58:54 Okay, thanks for the explanation 17:59:00 Let's punt then 17:59:05 proposed #agreed 1559341 - punt (delay decision) - it's not really clear whether this should be considered a blocker or not, so instead of arguing about it, we're just going to punt so it magically goes away because the fix is already accepted as a Beta FE 17:59:13 ack 17:59:18 woohoo, due process! 17:59:50 ack 17:59:56 ack 17:59:57 ack 18:00:12 ack 18:00:19 ack 18:00:45 #agreed 1559341 - punt (delay decision) - it's not really clear whether this should be considered a blocker or not, so instead of arguing about it, we're just going to punt so it magically goes away because the fix is already accepted as a Beta FE 18:00:52 alright, last one 18:00:52 #topic (1557655) Failed to start udev Wait for Complete Device Initialization 18:00:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=1557655 18:00:53 #info Proposed Blocker, systemd, NEW 18:01:11 my time is up, have to go now 18:01:14 * kalev waves. 18:01:30 cya kalev, thanks 18:01:34 looks like fcoe install fail, basically 18:02:12 note for folks who aren't aware, 'beaker' is a test system used internally at rh which helps with access to unusual hardware like this 18:02:26 Oh 18:02:31 Yes, thanks 18:02:32 lili is testing this on rh's beaker system so she has access to an fcoe configuration 18:02:35 I didn't know 18:02:36 adamw: so basically openqa with hardware nobody has anymore? 18:03:24 puiterwijk: more or less, i guess? it's sorta between jenkins and openqa but kinda older than both :P it's a system for managing access to hardware resources and scheduling tasks on them, i guess you could call it. 18:03:58 (well, jenkins is really old, but rh has been using beaker way longer than it's been using jenkins) 18:04:10 adamw: yeah, I've played with it once... Never managed to figure it out 18:05:07 in many cases you just use beaker to reserve a machine, so you can test/debug stuff manually 18:05:09 anyway, all that really matters for this bug is it's just a way we could get access to fcoe hardware (which none of us has otherwise) 18:05:15 right, you can just do that 18:05:21 so, either a blocker or we need to reproduce on a different system/by someone else to be sure this is a generic error 18:05:30 that's quite different from how Jenkins is used generally 18:05:43 given the difficulty of access to fcoe hardware i'm fine with accepting this as a blocker so long as it's reproducible by lili on demand, which it seems to be 18:06:00 since the latter is hard to do, probably +1 blocker and re-evaluate if this seems to be not directly related to the criteria 18:06:18 yeah, if new information emerges later that would suggest a revote, we can always revote. 18:06:20 for now i'm +1. 18:06:33 I don't think this can be debugged just with the information that is available now in the bug. 18:06:47 zbyszek: lili should be able to get the additional info now you asked for it 18:06:53 I think so, too, there is a risk that it will not be fixed in time. 18:07:24 note, criteria do explicitly cover fcoe 18:07:30 "The installer must be able to detect (if possible) and install to supported network-attached storage devices... 18:07:30 Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE)" 18:07:51 ok, will remember that now :) 18:07:52 +1 18:08:13 in that case, +1 18:09:08 proposed #agreed 1557655 - AcceptedBlocker (Final) - this is accepted as a blocker as a violation of Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices...Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE)" 18:09:13 ack 18:09:18 ack 18:10:40 ack 18:10:44 #agreed 1557655 - AcceptedBlocker (Final) - this is accepted as a blocker as a violation of Final criterion "The installer must be able to detect (if possible) and install to supported network-attached storage devices...Supported network-attached storage types include iSCSI, Fibre Channel and Fibre Channel over Ethernet (FCoE)" 18:14:54 alrighty 18:14:56 that's all the bugs 18:14:58 #topic Open floor 18:15:10 do we have any other f28-related issues to kick around at this point? missed bugs, etc? 18:15:19 bear in mind we'll likely try and do an RC today 18:15:21 * kparal has nothing 18:15:56 the RC will be a suject to test, right? 18:16:08 s/suject/subject 18:17:16 yeah 18:17:36 validation events are created for *all* successful candidate composes, unconditionally (if that's what you were asking) 18:18:01 yeah, I think so 18:18:04 :) 18:18:44 adamw: So, only thing that is remaining for a RC is that cloud-init bug, right? 18:20:06 i think so, yeah. 18:20:12 but i'd actually like to do a stable push first. 18:20:18 again, once some ducks are lined up. 18:20:33 adamw: Okay and sure, +1 for stable push 18:20:58 coremodule: can you get the secretarialization done asap? i need it for the stable push and compose request 18:23:07 adamw, sure! 18:23:09 no problem 18:23:57 * kparal needs to go. bye 18:24:07 bye, kparal 18:26:29 Do we have anything more to talk about? 18:26:32 * lruzicka does not 18:34:13 adamw, could you close the meeting so the meeting notes will be published? 18:34:19 coremodule: sorry, yes 18:34:22 * adamw multitasking 18:34:25 thanks for coming, everyone 18:34:27 #endmeeting