16:00:35 <roshi> #startmeeting F23-blocker-review
16:00:35 <zodbot> Meeting started Mon Jul 27 16:00:35 2015 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:35 <roshi> #meetingname F23-blocker-review
16:00:36 <zodbot> The meeting name has been set to 'f23-blocker-review'
16:00:36 <roshi> #topic Roll Call
16:00:45 <roshi> who's around for some blockery goodness?
16:01:05 * garretraziel is lurking
16:02:07 <roshi> #chair adamw garretraziel
16:02:07 <zodbot> Current chairs: adamw garretraziel roshi
16:02:31 * pschindl is here
16:02:37 * brunowolff is here
16:03:05 <roshi> #chair pschindl brunowolff
16:03:05 <zodbot> Current chairs: adamw brunowolff garretraziel pschindl roshi
16:03:16 <adamw> ahoy
16:03:25 <roshi> I suppose we can get started :)
16:03:26 <roshi> #topic Introduction
16:03:26 <roshi> Why are we here?
16:03:26 <roshi> #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:30 <roshi> #info We'll be following the process outlined at:
16:03:33 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:03:35 <roshi> #info The bugs up for review today are available at:
16:03:38 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:03:40 <roshi> #info The criteria for release blocking bugs can be found at:
16:03:43 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria
16:03:46 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Beta_Release_Criteria
16:03:49 <roshi> #link https://fedoraproject.org/wiki/Fedora_23_Final_Release_Criteria
16:03:52 <roshi> apologies for not getting the announce sent
16:04:03 <roshi> today we've got 3/3/2 proposals to work through
16:04:16 <roshi> #topic (1219638) DNF doesn't use xml:base in repodata
16:04:16 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1219638
16:04:16 <roshi> #info Proposed Blocker, dnf, NEW
16:04:30 <brunowolff> Every once in a while I still see something weird on my i915 laptop, but not consistent enough to allow someone else to reproduce and not annoying enough to be considered a blocker.
16:06:47 <pschindl> -1
16:06:49 <brunowolff> Well if this is blocking composes I think that qualifies as a blocker.
16:07:03 <adamw> well, we got a TC2, so presumably things have moved on from this.
16:07:06 <adamw> i don't know the details, though.
16:07:12 <adamw> let me try and rouse a dgilmore
16:07:24 <roshi> if it breaks compose, then I'm +1 - otherwise -1
16:07:43 <brunowolff> It may be the compose process will be easier to fix than dnf in the short run.
16:08:04 <pschindl> ah sry. I misread Adam's comment. If it blocks compose then I'm +1
16:09:03 <dgilmore> hey all
16:09:04 <adamw> hi dgilmore, thanks for stopping by
16:09:15 <roshi> thanks dgilmore
16:09:19 <dgilmore> so i applied the patch from dmach to get things moving
16:10:16 <adamw> er, what patch is that?
16:10:29 <dgilmore> the attitude in the bug from the dnf guys is less than helpful
16:10:56 <dgilmore> http://pkgs.fedoraproject.org/cgit/dnf.git/commit/?h=f23&id=85b88dbcae49712956c869dd27b09fdbf9fa5ec3
16:11:04 <dgilmore> it is only applied to f23
16:12:30 <adamw> so you've patched the dnf package on f23 branch?
16:13:46 <dgilmore> adamw: yes
16:14:34 <adamw> hmm. in that case we should technically close the bug, but it sounds like you still need to fight about it with dnf.
16:14:42 <adamw> perhaps an issue in dnf github or wherever they have upstream atm?>
16:15:11 <dgilmore> adamw: yeah. I have left it open because dnf needs to do more
16:15:39 <dgilmore> but I do not know what or how to have them engage in a useful manner
16:15:45 <adamw> that kinda leaves us with a process problem, though, as it's an open blocker; we can 'unnominate' it as a blocker but that seems inappropriate. would it be OK to close it and open an issue upstream?
16:16:17 <roshi> that makes sense to me
16:16:18 <dgilmore> adamw: we can, though I do not know where that is
16:16:29 <dgilmore> and if its github I am unable to do anything
16:16:46 <adamw> seems it's github. i can file it if you can't
16:16:47 <adamw> https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting
16:17:12 <adamw> oh, no, it isn't. they use bz.redhat.com as their upstream bug reporting system. well, that's a problme.
16:17:24 <kushal> roshi, hello
16:17:33 <roshi> welcome kushal
16:17:42 <adamw> i guess we'll just have to drop the blocker status, in that case.
16:20:18 <roshi> proposed #agreed - 1219638 - Drop Alpha - Dropping the blocker status of this bug since it's fixed for our purposes but more work needs to be done upstream.
16:20:22 <roshi> that sound ok?
16:21:17 <pschindl> ack
16:21:24 <garretraziel> ack
16:22:18 <adamw> best we can do, yeah
16:22:18 <roshi> #agreed - 1219638 - Drop Alpha - Dropping the blocker status of this bug since it's fixed for our purposes but more work needs to be done upstream.
16:22:25 * adamw will secretarialize
16:22:35 <roshi> awesome, thanks
16:22:38 <roshi> #topic (1247220) Docker packages are missing for i686 and armv7hl architectures
16:22:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1247220
16:22:44 <roshi> #info Proposed Blocker, docker, NEW
16:23:29 <dgilmore> +1 blocker
16:23:52 <kushal> bugzilla is way too slow for me tonight :(
16:24:03 <kushal> but from the subject, +1 as blocker.
16:24:08 <pschindl> +1
16:24:12 <pwhalen> +1
16:24:37 <garretraziel> +1
16:26:15 <roshi> proposed #agreed - 1247220 - AcceptedBlocker Alpha - This bug is a clear violation of the following Alpha criterion: "All release-blocking images must boot in their supported configurations."
16:26:29 <roshi> to be clear though, this is a blocker because it blocks Server
16:26:44 <roshi> not because of issues with Docker - this bit is just required by Server
16:27:01 <adamw> ack
16:27:13 <pschindl> ack
16:27:28 <pwhalen> ack
16:27:39 <roshi> #agreed - 1247220 - AcceptedBlocker Alpha - This bug is a clear violation of the following Alpha criterion: "All release-blocking images must boot in their supported configurations."
16:27:50 <roshi> #topic (1235323) efibootmgr fails when creating or deleting boot items randomly
16:27:53 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1235323
16:27:56 <roshi> #info Proposed Blocker, efibootmgr, NEW
16:28:23 <adamw> so this is a bit tricky since we have the fallback path trick
16:30:01 <brunowolff> Does this affect lots of UEFI systems or just a few?
16:30:56 <adamw> well, it looks like it affects many or most
16:31:07 <adamw> but the system will often succeed in booting because of the fallback path trick
16:31:34 <roshi> which trick is that?
16:31:36 <adamw> i guess i'd be inclined not to block alpha on it, probably see it more as a final or possibly beta blocker.
16:31:52 <kushal> adamw, beta blocker +1
16:32:04 <adamw> roshi: we do this rather clever thing where we install our bootloader to the fallback location and have it wired up to recreate the 'proper' boot menu entry if it detects that it booted from the fallback path
16:32:20 <roshi> ah, nice
16:32:25 <adamw> roshi: so basically in many cases even if the efibootmgr entry creation fails during install, the installed system will boot and fix itself
16:33:18 <roshi> +1 beta then, don't see a need to block alpha for it
16:33:23 <roshi> unless the trick stops working
16:33:25 <adamw> there's some cases where that won't work - multiboot i guess is an obvious one - but often it will.
16:33:39 <pwhalen> i hit it last week on one of the nightlies, i can try again on tc2
16:33:58 <adamw> pwhalen: if the problem is in efivar as it sounds like, i'd expect it's still bad, because the updated efivar still hasn't been built for 23/rawhide
16:34:07 <Pharaoh_Atem> I've seen EFI fail on boot targets consistently in F22 and F23 TCs
16:34:29 <pschindl> +1 beta works for me. I saw it on 2 machines (from 2 uefi capable machines I use for testing)
16:35:02 <pwhalen> pschindl, did they boot after?
16:35:09 <Pharaoh_Atem> I actually haven't been able to install UEFI Fedora in quite a while
16:35:18 <pschindl> pwhalen: no, they didn't
16:35:30 <roshi> do we want to use a beta criteria for this then? All release-blocking images must boot in their supported configurations
16:35:52 <pschindl> But running the same command which fails again solved the issue.
16:36:20 <pwhalen> ok, i just tried the drive I installed to, not booting. so the fallback doesnt seem to be working
16:36:33 <adamw> roshi: no, because again, that criterion is for *images*, not installed systems.
16:36:51 <adamw> pwhalen: like i said, it's not 100% reliable.
16:37:10 <adamw> you can see in the bug report that it worked for kparal but not pschindl.
16:37:27 <adamw> whether it works is going to depend a bit on details of the system configuration and firmware implementation of fallback (there's some ambiguity in the spec)
16:37:38 <pwhalen> he says 'might', iiuc?
16:37:43 <adamw> so basically, we can say this will stop *some* machines from booting the installed system properly. hard to speculate on how many.
16:37:51 <roshi> all this cloud stuff messing with my head, because there an image *is* and installed system
16:37:57 <adamw> roshi: heh
16:38:03 <roshi> internal equivocation for the lose :(
16:38:32 <adamw> pwhalen: he says 'might' in #c10. in #c3 he's clear that it worked for him.
16:38:52 <pwhalen> adamw, gotcha. ok
16:38:53 <pschindl> As I said you can run efibootmgr with the same parameters again when this happens and then it boots as usually
16:39:12 <pwhalen> fair enough, easy to document for alpha
16:40:37 <roshi> proposed #agreed - 1235323 - AcceptedBlocker Beta - This bug violates the following Alpha criterion, "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.", but doesn't happen reliably enough to block Alpha for. However, we want to get this fixed before we release Beta.
16:40:38 <adamw> i guess on balance i'd vote beta. be good to fix it for alpha though, asking pjones about it now.
16:40:50 <adamw> ack (i'll include a note about the workaround)
16:41:00 <brunowolff> ack
16:41:52 <garretraziel> ack
16:41:57 <pschindl> ack
16:41:59 <roshi> #agreed - 1235323 - AcceptedBlocker Beta - This bug violates the following Alpha criterion, "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.", but doesn't happen reliably enough to block Alpha for. However, we want to get this fixed before we release Beta.
16:42:20 <roshi> that's all for Alpha
16:42:27 <roshi> first Beta proposal coming up
16:42:39 <roshi> #topic (1245191) AttributeError: 'MDBiosRaidArrayDevice' object has no attribute '_currentSize'
16:42:42 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245191
16:42:44 <roshi> #info Proposed Blocker, anaconda, NEW
16:43:57 <roshi> seems a clear +1 to me
16:44:03 <kushal> +1 from my side.
16:44:11 <garretraziel> looks like clear blocker to me
16:44:12 <brunowolff> +1
16:44:13 <garretraziel> +1
16:45:01 <roshi> proposed #agreed - 1245191 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:45:09 <adamw> ack
16:45:21 <Pharaoh_Atem> clear blocker
16:45:25 <garretraziel> ack
16:45:41 <roshi> #agreed - 1245191 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "The installer must be able to detect and install to hardware or firmware RAID storage devices."
16:45:43 <adamw> just for the record, it's not the same as 1234097 , they look like two different bugs (this one is further fallout from some size checks that were added recentlyish)
16:45:53 <brunowolff> ack
16:46:01 <roshi> kk
16:46:02 <roshi> #topic (1245838) Upgrade to F23 crashes early in upgrade boot
16:46:02 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245838
16:46:02 <roshi> #info Proposed Blocker, fedup, NEW
16:48:25 <garretraziel> yeah, that one's nice. fedup doesn't work and there currently isn't replacement
16:48:26 <adamw> so it seems like we're going to wind up with a new upgrade mechanism out of this, but until all that's actually implemented, i'm still +1 blocker on this. at least it keeps the issue on the agenda.
16:48:40 <adamw> garretraziel: well, there sort of is: https://github.com/wgwoods/dnf-plugin-fedup
16:48:41 <brunowolff> This one looks worrisome.
16:48:55 <garretraziel> adamw: yes, proof-of-concept only
16:49:04 <garretraziel> or isn't it?
16:49:14 <adamw> it just needs to be improved from being a proof of concept, packaged for fedora, reviewed by all the flavors etc, documented, publicized and tested
16:49:22 <adamw> we've got three months, it'll be easy! (sigh)
16:49:32 <garretraziel> adamw: "just"
16:49:33 <brunowolff> Just?
16:50:11 <garretraziel> anyway, as for the bug, +1 blocker to me
16:50:12 <roshi> it's a Fedora "just" - so it's ok :p
16:50:20 <roshi> +1 blocker
16:50:26 <adamw> i thought the sarcasm was implied. :P
16:50:52 <roshi> :)
16:51:40 <brunowolff> It might be worth mentioning this at the council meeting later. If we stick to keeping this a blocker, it could cause a big slip.
16:51:58 <roshi> proposed #agreed - 1245838 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
16:52:49 <pschindl> ack
16:52:56 <garretraziel> ack
16:53:02 <brunowolff> ack
16:53:02 <adamw> ack
16:53:08 <roshi> #agreed - 1245838 - AcceptedBlocker Beta - This bug is a clear violation of the following Beta criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
16:53:15 <adamw> brunowolff: it's already on fesco's radar (see the links in the bug), not sure about the council
16:53:23 <roshi> upgrade testing is going to be fun this time around...
16:53:28 <adamw> do we have a security council and a commission too? should we notify them? :)
16:53:36 <roshi> heh
16:53:52 <roshi> #topic (1245219) Device type RAID can't be set in custom partitioning
16:53:55 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1245219
16:53:57 <roshi> #info Proposed Blocker, python-blivet, MODIFIED
16:55:17 <adamw> this one's fixed in TC2, openqa sez so.
16:55:19 <garretraziel> adamw: as far as I know, RAID test isn't failing on OpenQA anymore, is it?
16:55:31 <adamw> garretraziel: right, i just didn't get around to closing all the bugs yet.
16:55:40 <adamw> (before bodhi gets turned on we still have to close out bugs manually.)
16:56:04 <roshi> -1 then, if it's fixed
16:56:05 <garretraziel> it had failed in boston, due to bad DPI (you have fixed it today AFAIK) on confirm dialog
16:56:11 <garretraziel> yup, -1
16:56:21 <roshi> I say just close it and we'll move on
16:57:02 <adamw> it doesn't need to be -1
16:57:07 <adamw> right. i've already closed it. next bug.
16:57:15 <garretraziel> oh, ok
16:57:15 <roshi> #topic (1246252) Gnome doesn't notify for available updates
16:57:16 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1246252
16:57:16 <roshi> #info Proposed Blocker, gnome-session, NEW
16:57:36 <adamw> we're onto Final now, right?
16:57:59 <adamw> sounds like a +1, i haven't looked at this myself yet but looks like we have a confirmation
16:58:22 <roshi> yeah, we're onto final
16:58:24 <pschindl> +1 final
16:59:05 <roshi> proposed #agreed - 1246252 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:59:27 <brunowolff> ack
16:59:41 <garretraziel> ack
16:59:41 <adamw> ack
16:59:43 <roshi> #agreed - 1246252 - AcceptedBlocker Final - This bug is a violation of the following Final criterion: "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image."
16:59:50 <roshi> #topic (1240802) Can't unlock an encrypted root partition using caps lock key
16:59:53 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1240802
16:59:56 <roshi> #info Proposed Blocker, systemd, NEW
17:00:25 <adamw> oh whoops, we were supposed to re-test this, weren't we.
17:00:33 <roshi> yeah
17:00:34 * adamw was busy with other stuff last week
17:00:37 <adamw> did anyone else look at it?
17:00:38 <roshi> I haven't tested it
17:00:45 <brunowolff> I think it is easy enough to work around this one, that it isn't worth being a blocker.
17:01:24 <brunowolff> Most people are not going to use capslock in preference to a shift key.
17:01:39 <roshi> depends on keyboard layout I think
17:01:41 <adamw> my intuition is that it's not a blocker, but i'd kinda like to know exactly what's going on
17:01:54 <roshi> en_US, for sure capslock is a useless key
17:02:03 <adamw> it can be a bit tricky divining what's really going on with encryption passphrases, and a symptom like this could possibly indicate a bigger problem
17:02:12 <roshi> true
17:03:22 <roshi> I guess just punt and we try to actually test it this week :p
17:05:17 <adamw> yep
17:05:49 <roshi> proposed #agreed - 1240802 - Punt Final - This bug still needs some testing. We'll test it and vote next Blocker Review meeting.
17:05:57 <brunowolff> ack
17:06:09 <adamw> ack
17:06:22 <roshi> #agreed - 1240802 - Punt Final - This bug still needs some testing. We'll test it and vote next Blocker Review meeting.
17:07:26 <roshi> #topic Open Floor
17:07:36 <roshi> that's it, anybody have anything for Open Floor?
17:08:06 <adamw> do we have any proposed alpha FEs?
17:08:09 <adamw> we're fairly close to freeze now
17:08:24 <adamw> (i.e. it's tomorrow)
17:08:25 * roshi checks
17:08:32 <roshi> one
17:08:38 <roshi> #topic (1240354) SoaS live x86_64 20150706 does not login from live system user
17:08:41 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1240354
17:08:43 <roshi> #info Proposed Freeze Exceptions, sugar, NEW
17:10:16 <adamw> sure. showstopper for a non-blocking spin = FE.
17:10:43 <roshi> +1 FE
17:11:19 <roshi> proposed #agreed - 1240354 - AcceptedFreezeException - We'd take a fix for this during freeze since it's a showstopper for a spin.
17:11:25 <adamw> ack
17:11:55 <dgilmore> ack
17:11:55 <garretraziel> ack
17:12:03 <roshi> #agreed - 1240354 - AcceptedFreezeException - We'd take a fix for this during freeze since it's a showstopper for a spin.
17:12:38 <roshi> anything else?
17:12:42 * roshi sets the fuse
17:12:49 <roshi> 3...
17:13:08 <roshi> 2...
17:13:51 <adamw> nothin' from me
17:14:05 <roshi> 1...
17:14:17 <roshi> thanks for coming folks!
17:14:21 <roshi> #endmeeting