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