16:00:05 <adamw> #startmeeting F22-blocker-review 16:00:05 <zodbot> Meeting started Mon Apr 20 16:00:05 2015 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:05 <adamw> #meetingname F22-blocker-review 16:00:05 <adamw> #topic Roll Call 16:00:05 <zodbot> The meeting name has been set to 'f22-blocker-review' 16:00:16 <adamw> ahoyhoy folks, who's here to review some blockers? 16:00:25 * pschindl is here 16:00:51 * tonghuix is here 16:01:10 * satellit_e listening 16:01:57 <adamw> dgilmore: nirik: pwhalen: sgallagh: tflink: ping 16:02:06 * pwhalen is here 16:02:07 <sgallagh> pong-ish 16:02:14 <sgallagh> Having a busy day, so I may be distracted 16:02:31 <adamw> DISTRACTION IS NOT ACCEPTABLE 16:02:36 * nirik is also in another meeting and trying to catch up on emails 16:02:46 <adamw> #chair pwhalen satellit_e 16:02:46 <zodbot> Current chairs: adamw pwhalen satellit_e 16:02:49 * pschindl is willing to do secretarialization (or how it is spelled). 16:02:53 <adamw> awesome, thanks 16:02:58 <adamw> #info pschindl will secretarialize 16:03:16 <adamw> #topic Introduction 16:03:16 <adamw> Why are we here? 16:03:16 <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:03:16 <adamw> #info We'll be following the process outlined at: 16:03:17 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:03:18 <adamw> #info The bugs up for review today are available at: 16:03:20 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:03:21 <adamw> #info The criteria for release blocking bugs can be found at: 16:03:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria 16:03:25 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria 16:03:29 <adamw> #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria 16:03:50 <adamw> #info 18 Proposed Blockers 16:03:51 <adamw> #info 6 Accepted Blockers 16:03:51 <adamw> #info 0 Proposed Freeze Exceptions 16:03:51 <adamw> #info 1 Accepted Freeze Exceptions 16:03:54 * danofsatx is here 16:04:16 <adamw> that's an awful lot of proposed blockers (we sorta forgot the plan to review all milestones as we went along :<) so this meeting might wind up hitting the 3-hour limit and need to be continued tomorrow 16:04:19 <adamw> but let's do as much as we can! 16:04:50 <adamw> everyone ready for the first bug? 16:05:12 <adamw> #topic (1209460) Use langtable for console font information 16:05:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209460 16:05:13 <adamw> #info Proposed Blocker, anaconda, NEW 16:06:03 <adamw> so aiui, the impact of this is that if you install in a language that uses Arabic, Cyrillic or Hebrew script, native characters won't show up in the console, you'll get the good old character-not-found box. 16:07:20 <adamw> it's a bit hard to find an exact criterion this could be held to violate, but it does seem unfortunate 16:07:47 <adamw> and it's a bit feature-request-y, as we've always just had *one* console font before, aiui 16:07:51 <adamw> er, one default. 16:08:36 <dgilmore> adamw: running the releng meeting, but will try follow along 16:09:04 <adamw> any thoughts? 16:09:17 <pschindl> as long as ascii characters works (and I think that they have to use them for normal console work) I think it's more FreezeException. 16:10:31 <pwhalen> id agree with FE, be nice if it works 16:10:47 <pschindl> hmm. But yum and dnf uses translations in output. And another programs. 16:11:03 <adamw> yeah, it's a bit tricky. 16:11:05 <pschindl> So users wouldn't know what was the cause of some problem. 16:11:33 * adamw asks in #anaconda 16:14:08 <adamw> i can't really come up with a criterion for this (except very conditional one) and suspect it'd get handwaved if it was the final blocker, so i guess i'm a weak -1/+1 16:14:35 <pwhalen> +1 FE 16:15:55 <adamw> other votes? 16:17:29 <pschindl> -1/+1 16:18:16 <roshi> -1/+1 16:18:28 <roshi> I think it'd probably get handwaved at final as well 16:18:54 <adamw> proposed #agreed 1209460 - RejectedBlocker AcceptedFreezeException - we agreed this looks like a significant issue for users of affected languages, but it didn't quite seem to cross the threshold to violating any of the release criteria. We would very much like to see it fixed however 16:19:08 <roshi> ack 16:19:09 <pschindl> ack 16:20:02 <danofsatx> https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Installer_translations 16:20:32 <adamw> danofsatx: not really the same thing. 16:20:39 <adamw> although...hum, i wonder how the text install looks in Russain. 16:20:43 <adamw> also, Russian. 16:21:02 <danofsatx> ok, sorry....had an inpromptu $DAYJOB meeting and was only half paying attention 16:21:02 <adamw> though fixing this for *the installer itself* and the installed system would probably be two different problems. 16:22:38 <adamw> #agreed 1209460 - RejectedBlocker AcceptedFreezeException - we agreed this looks like a significant issue for users of affected languages, but it didn't quite seem to cross the threshold to violating any of the release criteria. We would very much like to see it fixed however 16:22:46 <adamw> #topic (1209563) Many strings not translated in live installation 16:22:46 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209563 16:22:46 <adamw> #info Proposed Blocker, anaconda, POST 16:22:54 <pwhalen> ack, sry 16:22:58 <adamw> this is a pretty icky situation to fix, but the bug's pretty bad. 16:25:14 <roshi> seems a pretty clear +1 to me 16:25:55 <tonghuix> that's true 16:26:00 <tonghuix> for chinese 16:26:11 <pschindl> +1 16:26:33 <danofsatx> +1 16:26:55 <adamw> proposed #agreed 1209563 - AcceptedBlocker - this violates "The installer must correctly display all sufficiently complete translations available for use." 16:27:03 <pschindl> ack 16:27:26 <roshi> ack 16:27:34 <danofsatx> ack 16:28:16 <adamw> #agreed 1209563 - AcceptedBlocker - this violates "The installer must correctly display all sufficiently complete translations available for use." 16:28:24 <adamw> #topic (1210003) "installation destination" gui becomes unresponsive after a cancel on "reclaim space" 16:28:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210003 16:28:25 <adamw> #info Proposed Blocker, anaconda, MODIFIED 16:28:36 <danofsatx> clear +1 16:29:27 <adamw> can someone cite a criterion here? conditional violation of the reclaim-space criterion i guess? 16:29:43 * danofsatx digs 16:30:48 <pschindl> adamw: you can't finish installation. You have to reboot. Not sure if it's enough to block. 16:31:13 <adamw> pschindl: we can call it a conditional violation of a storage criterion, i think, the condition being you need to back out and change your decision. 16:31:24 <danofsatx> https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Installation_interfaces 16:31:25 * adamw brb, call of nature 16:31:51 <danofsatx> "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. " 16:34:26 <adamw> sure, or a more storage-y one, but whatever 16:34:56 <adamw> guess i can be a weak +1 16:35:42 <adamw> any other votes? 16:36:10 <pschindl> Because I was +1 for 'go back to installation destination' I'm +1 here too. 16:36:14 * danofsatx missed if anyone is secretary today 16:36:36 <adamw> pschindl's doing it. 16:36:41 <danofsatx> roger 16:37:15 <adamw> proposed #agreed 1210003 - AcceptedBlocker - conditional violation of "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces.", the condition being you need to cancel out of this screen. 16:37:32 <danofsatx> ackish 16:38:29 <pschindl> ack 16:39:07 <adamw> heh 16:39:11 <adamw> #agreed 1210003 - AcceptedBlocker - conditional violation of "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces.", the condition being you need to cancel out of this screen. 16:39:19 <adamw> #topic (1210254) re-using partitions inside LUKS automatically checked for encryption 16:39:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210254 16:39:19 <adamw> #info Proposed Blocker, anaconda, MODIFIED 16:41:24 <danofsatx> I'm not clear on this one - is it essentially creating nested LUKS partitions? 16:42:25 <adamw> yeah, me either - i think it's something like that, but i'm not entirely sure' 16:43:32 <adamw> as you say i think what it does is encrypt the LVs within the encrypted VG (or PV or whatever, i'm not sure what bit is actually considred to be 'encrypted' in that case) 16:45:08 <adamw> on this particular one, probably -1/+1 16:45:34 <adamw> though it seems a bit moot as the fix is related to https://bugzilla.redhat.com/show_bug.cgi?id=1208979 which is already an accepted blocker 16:45:50 <danofsatx> I don't see a problem. It may impact performance on underpowered systems, but I see nothing in the bug that says it doesn't work. I'm -1. 16:47:05 <adamw> well, the layout created isn't really what you asked for. i dunno if it leads to double-jeopardy in entering passphrases or whatever. 16:47:06 <pschindl> -1/+1 16:48:48 <adamw> proposed #agreed 1210254 - RejectedBlocker AcceptedFreezeException - as described there's nothing here that really violates the criteria, the installed system seems to be operable, though not what would be reasonably expected, so accepted as a freeze exception issue. 16:49:04 <danofsatx> yak 16:49:12 <pschindl> ack 16:51:39 <adamw> #agreed 1210254 - RejectedBlocker AcceptedFreezeException - as described there's nothing here that really violates the criteria, the installed system seems to be operable, though not what would be reasonably expected, so accepted as a freeze exception issue. 16:51:49 <adamw> #topic (1212206) System doesn't boot with LVM data volume on iSCSI 16:51:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212206 16:51:49 <adamw> #info Proposed Blocker, anaconda, ASSIGNED 16:51:53 <adamw> oh, iscsi, why must you. 16:53:01 <danofsatx> +1 16:53:11 <adamw> yeah, per the criteria, +1/ 16:53:26 <pschindl> +1 16:53:32 <dgilmore> +1 16:54:24 <adamw> proposed #agreed 1212206 - AcceptedBlocker - violates "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)." 16:55:07 <danofsatx> yak 16:55:20 <pschindl> ack 16:55:59 <adamw> #agreed 1212206 - AcceptedBlocker - violates "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)." 16:56:09 <adamw> #topic (1209941) upgraded system does not reboot automatically, ctrl+alt+del is needed: Failed unmounting /sysroot/proc 16:56:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209941 16:56:09 <adamw> #info Proposed Blocker, fedup-dracut, NEW 16:57:18 <adamw> kamil's justification for this, from #c7: "If the system doesn't reboot automatically, it makes upgrading servers and other remote machines very problematic. And that is exactly the common use case for minimal installs." 16:58:10 <danofsatx> it's not just minimal installs. 16:59:00 <danofsatx> And it isn't fixed yet....I ran fedup Friday night, and it stopped at "Failed to unmount /proc" 16:59:13 <adamw> well, sure, if it was fixed it wouldn't be marked NEW. 16:59:20 <pschindl> +1 17:00:33 <danofsatx> actually, it was /sysroot/proc and /dev/hugepages 17:00:37 <danofsatx> +1 17:01:05 <adamw> it's slightly marginal, for me, but it *is* a significant annoyance for remote systems, if you have no out-of-band especially 17:01:21 <danofsatx> This last machine I hit it on was an ancient Optiplex 755, Core II duo 2.3Ghz with 8GB DDR2 666MHz RAM. 17:01:32 <danofsatx> so it doesn't appear to be a race condition 17:03:11 <adamw> races aren't *necessarily* hardware-related. 17:03:16 <danofsatx> true.... 17:03:29 <adamw> but we clearly don't know for certain what the bug is. 17:04:40 <adamw> proposed #agreed 1209941 - (tentatively) AcceptedBlocker - it's clear we don't have all the information here, but upgrade apparently fairly commonly failing to reboot is considered a conditional violation of the 'upgrade requirements' criterion, due to the remote system scenario cited in comment #7 17:06:49 <pschindl> ack 17:07:01 <danofsatx> Well, fedup takes so damned long that I tend to walk away while it is working, and check periodically with ssh to see if it's rebooted. 17:07:05 <danofsatx> ack 17:07:44 <adamw> #agreed 1209941 - (tentatively) AcceptedBlocker - it's clear we don't have all the information here, but upgrade apparently fairly commonly failing to reboot is considered a conditional violation of the 'upgrade requirements' criterion, due to the remote system scenario cited in comment #7 17:07:51 <adamw> #topic (1210047) [abrt] gnome-contacts: _g_log_abort(): gnome-contacts-search-provider killed by SIGTRAP 17:07:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210047 17:07:52 <adamw> #info Proposed Blocker, gnome-contacts, NEW 17:09:01 <adamw> hum, i don't recall whether i saw this in my tests... 17:09:02 <adamw> aynone else? 17:09:07 <danofsatx> +1 based on roshi's comment #12 17:09:20 * danofsatx hasn't tested this specifically 17:09:48 <danofsatx> I didn't get a crash, but I did see AVCs 17:10:51 <adamw> well, that's clearly not the same thing... 17:11:03 * adamw kicks off a workstation netinst 17:11:05 <pschindl> This happened to me while ago 17:11:38 <pschindl> I don't know what caused it. But the abrt message seems to be very similar. 17:12:32 <adamw> roshi: are you here? did you set up any online accounts in g-i-s, by chance? 17:14:50 <adamw> unless folks want to sit around while my install runs, i vote we punt this to make sure whether it's reproducible 17:15:09 <danofsatx> I'll hold the ball, who's kicking? 17:15:55 <adamw> you're gonna pull a Peanuts on me, aren't you 17:16:08 <danofsatx> ssshhhh.....don't tell adamw 17:16:42 <pschindl> punt 17:17:53 <adamw> proposed #agreed 1210047 - punt, request further testing - we're not yet sure whether this is reproducible or a one-off thing, so we'll ask for further testing to find out 17:18:17 <pschindl> ack 17:20:08 <adamw> #agreed 1210047 - punt, request further testing - we're not yet sure whether this is reproducible or a one-off thing, so we'll ask for further testing to find out 17:20:13 <adamw> #topic (1208526) [abrt] gnome-shell: xkb_keymap_unref(): gnome-shell killed by SIGSEGV 17:20:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1208526 17:20:14 <adamw> #info Proposed Blocker, gnome-shell, NEW 17:20:58 <adamw> seems a reasonable +1 here. 17:22:18 <danofsatx> I can't even figure out how to add a source to test it. 17:23:35 <adamw> it's under Region & Language. 17:24:29 <danofsatx> silly place to put it 17:24:45 <adamw> not really, that's the main reason for multiple input sources. 17:24:48 <adamw> there is a link from keyboard, too. 17:25:00 <danofsatx> ohhhhh..... _input_ sources. 17:25:03 * danofsatx blushes 17:25:13 <adamw> oh, you were thinking pacakge sources? nope. 17:25:18 <danofsatx> I thought it was software sources for packagekit 17:28:58 <adamw> any more votes? 17:30:04 <pschindl> I tried to add new input source on beta live and nothing happened. Everything seems to work fine. Has somebody reproduced this? 17:32:09 <danofsatx> +1 17:32:32 <adamw> according to the upstream bug, it's only on wayland... 17:32:34 <pschindl> well +1, I reproduced it on my working laptop :) 17:32:51 <pschindl> without wayland (gdm on wayland). 17:33:11 <adamw> oh, but it's gdm that's crashing, which is running on wayland. hm 17:33:39 <pschindl> gnome-shell crashed, not gdm 17:34:08 <adamw> gdm these days *is* gnome-shell 17:34:15 <adamw> it's just a custom shell mode, more or less 17:35:06 <adamw> still, it's just a crash notification, right? nothing actually breaks 17:35:09 <adamw> on that basis i'm probably -1/+1 17:35:21 <adamw> i guess i got the idea something was actually *broken* 17:36:09 <danofsatx> I can go with that....ammended -1/+1 17:36:43 <pschindl> when it crashed I was thrown into gdm. But after I re-logged in I had previous session working. 17:37:49 <pschindl> -1/+1 too. It's true that it doesn't mean loss of data or work. 17:38:09 <adamw> hrm, that's somewhat bad if it does that. 17:38:31 <adamw> i suspect if you just did ctrl-alt-f2 you'd have found your session there too, but if it's more than just a crash notification popping up... 17:38:36 <adamw> still, can be fixed with an update. 17:38:49 <adamw> eh, we're spending a lot of time on it, for something that's probably fixed already 17:38:52 <adamw> lemme throw a proposal at it 17:39:33 <adamw> proposed #agreed 1208526 - RejectedBlocker AcceptedFreezeException - this doesn't appear to violate any criterion and seems fixable with an update, the impact is annoying but not critical, by the description 17:39:49 <pschindl> ack 17:40:39 <danofsatx> ack 17:40:42 <adamw> we can always revisit it if turns out not to be fixed and the impact sucks. 17:40:46 <adamw> #agreed 1208526 - RejectedBlocker AcceptedFreezeException - this doesn't appear to violate any criterion and seems fixable with an update, the impact is annoying but not critical, by the description 17:41:58 <adamw> #topic (1211887) Newly created menuentry title is nonsense 17:41:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1211887 17:41:58 <adamw> #info Proposed Blocker, grubby, ON_QA 17:43:19 <danofsatx> I haven't seen this one. I'm assuming it's fixed. 17:43:20 <danofsatx> -1 17:43:49 <adamw> danofsatx: the update was updated. 17:44:08 <adamw> probably -1 on procedural grounds, for me (if it'd ever gone stable I'd be +1) 17:45:09 <pschindl> the grubby which caused the problem was taken back. 17:45:22 <pschindl> So everything probably should be ok now. 17:45:26 <pschindl> -1 17:46:01 <adamw> proposed #agreed 1211887 - RejectedBlocker - as the affected grubby build never went stable, there is no need to treat this bug as a release blocker. 17:46:20 <pschindl> ack 17:47:33 <adamw> #agreed 1211887 - RejectedBlocker - as the affected grubby build never went stable, there is no need to treat this bug as a release blocker. 17:47:33 <danofsatx> ack 17:47:45 <adamw> #topic (1206862) Hotkeys not functional on Asus X550ZE 17:47:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1206862 17:47:45 <adamw> #info Proposed Blocker, kernel, NEW 17:47:51 <danofsatx> -1 17:47:58 <pschindl> -1 17:49:10 <adamw> yeah, not seeing any reason to treat this as a blocker 17:49:44 <adamw> proposed #agreed 1206862 - RejectedBlocker - this is hardware-specific (model or manufacturer) and in non-blocking functionality in any case 17:49:56 <danofsatx> fwiw, I drive an ASUS laptop with the same firmware, and it works fine. 17:50:50 <pschindl> ack 17:51:00 <danofsatx> ack 17:51:11 <adamw> #agreed 1206862 - RejectedBlocker - this is hardware-specific (model or manufacturer) and in non-blocking functionality in any case 17:51:17 <adamw> #topic (1207366) Fedora 21 as an IPv6 tunnel endpoint (sit) gives severely crippled download speed over the tunnel 17:51:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1207366 17:51:18 <adamw> #info Proposed Blocker, kernel, NEW 17:51:26 * danofsatx realizes that 'ack' works much better in the correct window 17:51:35 <danofsatx> -1 17:52:14 <danofsatx> and the votes in the bug prety much say the same thing. call it and move on. 17:52:22 <pschindl> -1 17:52:43 <adamw> yeah, i'm not quite seeing this one either 17:52:59 <adamw> using a tunnel is a common enough thing to do to experiment with IPv6, but not sure it makes sense to block our release on it. 17:53:15 <danofsatx> no, it's not. 17:53:34 <adamw> danofsatx: it's certainly what I see recommended all the time for people who don't have native IPv6. 17:54:11 <danofsatx> yeah, it is - I was agreeing that it doesn't make sense to block on it 17:54:18 <pschindl> Maybe FE? 17:54:20 <adamw> ah I see 17:54:33 <adamw> pschindl: ehhhh. not sure we'd want to be futzing around in the kernel during freeze to fix this., 17:54:45 <adamw> at least i'd want to make that call when we had a fix to look at. 17:54:54 <adamw> proposed #agreed 1207366 - RejectedBlocker - there's no criteria violation here, and we think it's correct there's no criteria covering this area of functionality, it is too much of a niche concern to block the release. 17:55:00 <danofsatx> sorry, I was only typing with one hand on account of a rather *too* juicy apple in the other 17:55:29 <pschindl> ack 17:55:34 <danofsatx> ack 17:57:15 <adamw> #agreed 1207366 - RejectedBlocker - there's no criteria violation here, and we think it's correct there's no criteria covering this area of functionality, it is too much of a niche concern to block the release. 17:57:23 <adamw> #topic (1166650) [abrt] liveusb-creator: connection.py:651:call_blocking:DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist 17:57:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1166650 17:57:23 <adamw> #info Proposed Blocker, liveusb-creator, NEW 17:57:40 <adamw> so this is the 'luc fails on the first attempt' bug, right? 17:57:54 <danofsatx> it appears so.... 17:58:07 <adamw> it'd be a 'special' blocker i supposie 17:58:15 <danofsatx> under what criteria? 17:58:20 <danofsatx> the handwavy one? 17:58:20 <adamw> the usb one.\ 17:58:27 <adamw> nothing handwavey about it. 17:58:36 <adamw> " 17:58:36 <adamw> Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods. 17:58:36 <adamw> " 17:58:50 <adamw> (alpha) 17:58:52 <adamw> erf 17:58:52 <adamw> beta 18:00:07 <pschindl> +1 18:00:13 <danofsatx> that's rather conditional....the image will boot from a USB stick. The problem here is getting the image _on_to_ the stick using Live USB creator 18:01:41 <adamw> yeah, there is some wiggle room, but it's basically intended that 'writing usb sticks with the supported methods ought to work'. 18:02:42 <adamw> i suppose i'm an unenthusiastic +1 for this (as a special blocker, i.e. it doesn't block image compose as it's a bug in luc itself) 18:02:49 <danofsatx> I'm firmly against this, but I'll abstain to keep the vote unanimous 18:03:54 <danofsatx> If we had a criteria specifically for using luc to create the image, then I'd be ok with it. 18:05:08 <adamw> that's definitely what that criterion is about. 18:05:24 <adamw> 'officially supported methods' is a link to the 'how to create USB sticks' page, which documents the supported methods, of which luc is one. 18:06:07 <adamw> proposed #agreed 1166650 - AcceptedBlocker - violates "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods." (from Beta criteria), note this is a 'special blocker' as the bug is in luc itself, it is resolved when an update is issued for F20/F21 and Windows (or luc is taken out of the list of 18:06:07 <adamw> 'supported methods') 18:06:13 <adamw> hum, bit long 18:06:31 <adamw> proposed #agreed 1166650 - AcceptedBlocker - violates "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods." (Beta), this is a 'special blocker' as the bug is in luc itself, it is resolved when an update is issued for F20/F21 and Windows (or luc is taken out of the list of 'supported methods 18:06:31 <adamw> ') 18:06:34 <adamw> close enough. 18:06:56 <danofsatx> ack 18:07:01 <pschindl> ack 18:07:16 <adamw> #agreed 1166650 - AcceptedBlocker - violates "Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods." (Beta), this is a 'special blocker' as the bug is in luc itself, it is resolved when an update is issued for F20/F21 and Windows (or luc is taken out of the list of 'supported methods') 18:07:32 <adamw> #topic (1212180) Window is blank / doesn't load fully or draw properly or something 18:07:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212180 18:07:32 <adamw> #info Proposed Blocker, liveusb-creator, ASSIGNED 18:07:55 <adamw> -1 on this, as it's only going to affect 22, and writing a USB stick for 22 from 22 isn't really an important case. 18:08:05 <adamw> (it'd be an *F23* Beta blocker, for me.) 18:08:11 <danofsatx> -1 18:08:35 <adamw> heck, we can actually make it an f23 beta blocker if we like, that tracker exists already. :P 18:08:49 <danofsatx> gofer it 18:09:38 <danofsatx> first F23 blocker review meeting is in, what, July? 18:09:52 <adamw> i don't know, i expect i'll have drunk myself to death by then 18:09:56 <adamw> :P 18:10:08 <pschindl> +1 18:10:18 <danofsatx> what's your address? I'll send you some beer. 18:10:28 * danofsatx is gunning for adamw's job 18:10:38 <adamw> good lord, why 18:10:44 <pschindl> eh, I wanted to say -1 18:10:56 <danofsatx> so I can stay home. I'm tired of driving. 18:10:56 <adamw> pschindl: how bout 23 Beta blocker? :) 18:11:05 <pschindl> +1 :) 18:11:25 <pschindl> That's +2 for F23BetaBlocker :) 18:11:32 <danofsatx> +1 18:11:55 <danofsatx> erm, +3 18:13:08 <adamw> proposed #agreed 1212180 - RejectedBlocker (22 Final) AcceptedBlocker (23 Beta) - bugs in the USB creation tools are considered most important for *subsequent* releases, so this is a 23 Beta blocker under the footnotes of "All release-blocking images must boot in their supported configurations." in the Beta criteria 18:13:18 <danofsatx> isn't it fixed, though? lmacken is looking for testers, isn't he? 18:13:39 <danofsatx> ack 18:13:45 <adamw> pschindl: 'F23BetaBlocker' is the bug. 18:13:55 <adamw> danofsatx: the UI rewrite isn't landed yet, and I don't know if it actually does anything about this bug. 18:14:33 <pschindl> ack 18:14:47 <adamw> #agreed 1212180 - RejectedBlocker (22 Final) AcceptedBlocker (23 Beta) - bugs in the USB creation tools are considered most important for *subsequent* releases, so this is a 23 Beta blocker under the footnotes of "All release-blocking images must boot in their supported configurations." in the Beta criteria 18:15:06 <adamw> only 5 to go! looks like we mgiht make it 18:15:07 <adamw> #topic (1212009) network sometimes doesn't start, on both installed system and netinst 18:15:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1212009 18:15:08 <adamw> #info Proposed Blocker, NetworkManager, NEW 18:16:56 <adamw> i dunno, i'd kinda like more detail (and more affected cases) here to make this a blocker 18:17:28 <pschindl> I've seen it few time. 18:17:43 <adamw> always on that particular laptop model? 18:19:01 <sgallagh> I have a T540p and haven't experienced this. 18:19:15 <sgallagh> I have *other* network issues of course... 18:19:29 <pschindl> we tried it with two different T540p and it happened on both. 18:19:57 <sgallagh> /me is running on a T540p at this very moment. I can try to reboot and reproduce it if you like. 18:20:03 <adamw> might be related to the network it's on too? 18:20:07 <pschindl> But still I don't think it's bad enough for blocker. 18:20:32 <adamw> i think the type of bug it is certainly *potentially* could, but i'd kinda expect to have more reports if it was affecting many cases 18:20:35 * pschindl is running on a T540p and it's true that it doesn't happen with my installed system 18:20:39 <adamw> whether to bz or to the ml 18:20:49 <adamw> it'd be useful to know if you can 'fix' it from the GUI too 18:21:06 <adamw> that's an OK workaround for a bug like this, for me, if it 's possibl 18:21:13 <danofsatx> -1 18:21:38 <adamw> i think i'd rather give a provisional -1 than punt this, as i'm not sure what we'd be punting for 18:21:38 <pschindl> I'm -1. If we gather more information we can always re-propose it. 18:21:40 <adamw> yeah 18:21:55 <adamw> i'm gonna say -1, with a note to re-propose if further research seems to indicate it'd be worthwhile 18:22:02 <danofsatx> ack 18:22:18 <sgallagh> sure 18:22:29 <sgallagh> I'll burn the netinst and try it out here as well. 18:22:43 <adamw> propose #agreed 1212009 - RejectedBlocker - this is a provisional rejection: as we haven't seen any other reports of this it seems like it might be a very unusual case (perhaps related to both the hardware and the router?) and so not worthy of blocker status, it can be re-proposed if further research suggests it's more common than we thought 18:22:46 <sgallagh> kparal: That was wired networking I presume? 18:24:13 <pschindl> ack 18:24:14 <danofsatx> that's the way I read it 18:25:05 <pschindl> sgallagh: I saw it on wired net. and haven't tried with wireless. 18:25:54 <adamw> ack/nack/patch? 18:26:35 <danofsatx> ack 18:26:48 * danofsatx thought he did that 18:27:42 <adamw> #agreed 1212009 - RejectedBlocker - this is a provisional rejection: as we haven't seen any other reports of this it seems like it might be a very unusual case (perhaps related to both the hardware and the router?) and so not worthy of blocker status, it can be re-proposed if further research suggests it's more common than we thought 18:27:50 <adamw> #topic (1160424) MDRaidError: name_from_md_node(md126p1) failed 18:27:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1160424 18:27:50 <adamw> #info Proposed Blocker, python-blivet, ASSIGNED 18:27:58 <adamw> so this one seems to come up kinda intermittently in fw raid testing 18:28:12 <adamw> i think the anaconda devs are theorizing that udev is causing a partprobe which is messing things up, or smth 18:28:34 <danofsatx> I'm leaning +1 on this one. 18:29:11 <adamw> i think it might be worth a punt for at least one week, as we seem to be getting new info on it quite regularly 18:30:51 <danofsatx> I could lean that way, too. 18:30:57 <pschindl> +1 punt 18:31:08 <danofsatx> then again, I can barely f'n walk today.... 18:31:53 <adamw> heh 18:32:26 <danofsatx> so, +1 punt 18:32:38 <adamw> proposed #agreed 1160424 - punt for information - this is at least potentially a blocker, but it depends how commonly it occurs (it does not affect *all* firmware RAID installs). New information seems to be arriving quite often, so we will check in next week and see if this is clearer then. 18:34:43 <pschindl> ack 18:35:03 <danofsatx> ack 18:35:24 <danofsatx> three to go! 18:35:38 <danofsatx> next one is Roshi's, I say we skip it. 18:35:57 <adamw> #agreed 1160424 - punt for information - this is at least potentially a blocker, but it depends how commonly it occurs (it does not affect *all* firmware RAID installs). New information seems to be arriving quite often, so we will check in next week and see if this is clearer then. 18:35:57 <adamw> heh 18:36:05 <adamw> #topic (1210045) AVC Denials after i386 Workstation netinst 18:36:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1210045 18:36:05 <adamw> #info Proposed Blocker, selinux-policy, ASSIGNED 18:36:30 <danofsatx> punt, need moar inpho 18:36:35 <adamw> i don't seem to have this today either 18:36:44 <adamw> and yeah, actual AVCs (fr'instance) would be useful 18:37:11 <danofsatx> who taught him how to file a bug, anyhow? 18:37:32 * danofsatx likes picking on roshi when he can't defend hisself 18:38:45 <adamw> my test install from earlier didn't have this 18:38:56 <adamw> so, i guess punt to give roshi a chance to provide more info 18:39:30 <pschindl> +1 for punting it 18:40:44 <adamw> propose #agreed 1210045 - punt - adamw couldn't reproduce this today and the report is short on detail, let's give roshi a chance to provide more info 18:42:57 <pschindl> ack 18:43:03 <danofsatx> ack 18:43:16 <adamw> #agreed 1210045 - punt - adamw couldn't reproduce this today and the report is short on detail, let's give roshi a chance to provide more info 18:43:26 <adamw> #topic (1200559) [abrt] totem: browse_cb(): totem killed by SIGABRT 18:43:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1200559 18:43:27 <adamw> #info Proposed Blocker, totem, NEW 18:43:48 <danofsatx> I don't get an abrt for totem, but it doesn't work. 18:44:15 <danofsatx> It opens, but none of the predefined "channels" work. I don't have any local videos to test it on. 18:45:08 <adamw> plays videos OK here (just in the wrong aspect ratio, which i've got a bug open on somewhere...) 18:45:12 <pschindl> It seems to work only when you have some history of played songs. 18:45:30 <adamw> the blip.tv channel works 18:45:37 <adamw> (ut yeah, this is all in my installed system) 18:45:41 <pschindl> when I tried to start totem from activities on freshly installed system, it crashed. 18:46:01 <danofsatx> ok, blip works 18:46:21 <adamw> seems like i can recreate the bug on a clean install, yeah 18:46:30 <adamw> so, +12 18:46:30 <adamw> +1. 18:46:31 <danofsatx> MPEG-4 AAC decoder, H.264 decoder are required to play the file, but are not installed. 18:46:31 <adamw> i'm not 12 people. 18:46:36 <adamw> danofsatx: that's expected. 18:46:38 <pschindl> it works fine in my installed system too. But doesn't on freshly installed. It plays when you specify video by argument (in console) 18:47:11 <pschindl> danofsatx: you have to try it with some ogg. That should work. 18:47:24 <danofsatx> I ain't got one of those 18:47:39 <pschindl> you can download big bug bunny :) 18:47:47 <sgallagh> Yeah, by default totem can't play any patent-encumbered format 18:47:55 <sgallagh> Because laws. 18:48:21 <adamw> that's a side issue, though. the bug is it crashes, on a fresh install. which it does. thus +1. 18:49:43 <pschindl> +1 18:50:11 <danofsatx> ok then, +1 if you must 18:51:07 <adamw> proposed #agreed 1200559 - AcceptedBlocker - clear violation of criterion "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:52:11 <pschindl> it doesn't work on live too. 18:52:15 <pschindl> ack 18:52:22 <danofsatx> ack 18:53:05 <adamw> #agreed 1200559 - AcceptedBlocker - clear violation of criterion "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:53:20 <adamw> last proposed blocker! just as we reach the end of the time 18:53:20 <adamw> #topic (1201877) xorg-x11-drv-qxl is FTBFS on aarch64 18:53:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1201877 18:53:20 <adamw> #info Proposed Blocker, xorg-x11-server, NEW 18:54:05 <danofsatx> I'm just gonna go with peer pressure on this one...what say y'all? 18:54:52 <adamw> i don't see how this rates as a release blocker. 18:54:58 <adamw> is it failing to build for a primary arch? nope. 18:55:20 <adamw> so, -1. 18:55:38 <pschindl> -1 18:56:13 <pschindl> but if it blocks secondary architecture then it is probably FE, isn't it? 18:56:40 <danofsatx> -1 then 18:56:49 <adamw> sure, could be FE 18:56:58 <danofsatx> aarch64 isn't primary? 18:57:01 <adamw> nope. 18:57:03 * danofsatx thought that was arm 18:57:05 <adamw> only armv7hl atm. 18:57:22 <danofsatx> k 18:57:31 <adamw> https://fedoraproject.org/wiki/Architectures 18:57:38 <danofsatx> 3 minutes....are we gonna make it? 18:57:47 <adamw> (where they're somewhat inaccurately referred to as "ARM" and "ARM AArch64", but hey. 18:58:19 <adamw> propose #agreed 1201877 - RejectedBlocker - this appears to be an issue in a secondary architecture, and cannot possibly block the release. 18:58:26 <pschindl> ack 18:58:26 <danofsatx> ack 18:58:52 <danofsatx> no proposed FEs. methinks we're done. 18:59:42 <adamw> #agreed 1201877 - RejectedBlocker - this appears to be an issue in a secondary architecture, and cannot possibly block the release. 18:59:49 <adamw> indeed 18:59:52 <adamw> just on time 18:59:55 <adamw> #topic Open floor 19:00:00 <adamw> any other business, in two seconds? 19:00:02 <adamw> no? 19:00:04 <adamw> very good! 19:00:04 <adamw> :P 19:00:05 <danofsatx> close floor 19:00:08 * adamw sets fuse 19:00:13 <adamw> (srsly if you have anything, yell) 19:00:14 <danofsatx> *BOOM* 19:00:51 <adamw> fire in the hole! 19:00:56 <adamw> thanks for coming folks, sorry for the long meeting 19:01:02 <adamw> and thanks for secretarializing, pschindl! 19:01:17 <pschindl> adamw: de nada :) 19:01:24 <adamw> #endmeeting