16:01:31 <tflink> #startmeeting f20alpha-blocker-review-1
16:01:31 <zodbot> Meeting started Wed Aug 21 16:01:31 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:31 <tflink> #meetingname f20alpha-blocker-review-1
16:01:31 <tflink> #topic Roll Call
16:01:31 <zodbot> The meeting name has been set to 'f20alpha-blocker-review-1'
16:01:40 * kparal 
16:01:41 <adamw> ahoyhoy
16:01:46 <tflink> kparal: what are you stirring?
16:01:55 * mkrizek is here
16:01:56 * pwhalen is here
16:01:57 <nonamedotc> i am going to hang around as well! :D
16:02:00 <kparal> tflink: the meeting
16:02:18 <tflink> kparal: I was wondering where that gigantic wooden spoon came from :)
16:02:48 * nonamedotc wants to say 'here' as well.
16:02:50 <kparal> .moar tflink chilli
16:02:50 <zodbot> here chilli, have some more tflink
16:02:55 <kparal> heh
16:03:07 * tflink prepares to defend with his shield of +3 blocker rejection :)
16:03:10 * pschindl is here
16:03:35 <tflink> or would it have to be -3 for rejection?
16:03:51 <kparal> right, the cursed shield of blocker rejection
16:03:57 <kparal> can't take it off
16:04:05 * jreznik is around (just not feeling very well, maybe will sound a bit crazy :D)
16:04:27 <kparal> jreznik: we're used to it, no worries
16:05:54 <tflink> kparal: that sounds more like the "cursed gauntlets of blocker review meeting leadership"
16:06:06 <tflink> they won't go away!
16:06:27 <tflink> anyhow, I think we have enough people to get the party started with some always-exciting boilerplate
16:06:29 <adamw> the amount of chickens i had to sacrifice to pass them on to you
16:06:44 <tflink> adamw: so that's how it happened
16:06:55 * tflink searches craigslist for chickens
16:06:59 <tflink> #topic Introduction
16:07:06 <tflink> Why are we here?
16:07:06 <tflink> #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 freeze exception bugs.
16:07:11 <tflink> #info We'll be following the process outlined at:
16:07:11 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:17 <tflink> #info The bugs up for review today are available at:
16:07:17 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:25 <tflink> #info The criteria for release blocking bugs can be found at:
16:07:25 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:07:30 <tflink> #info Up for review today, we have:
16:07:58 <tflink> #info 5 Proposed Blockers
16:07:58 <tflink> #info 0 Accepted Blockers
16:07:58 <tflink> #info 0 Proposed Freeze Exceptions
16:07:58 <tflink> #info 0 Accepted Freeze Exceptions
16:08:21 <tflink> since we only have proposed blockers to cover today, we'll "start" with those :)
16:08:28 <tflink> topic (901917) rescue a fedora system mode doesn't recognize luks installation
16:08:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=901917
16:08:32 <tflink> bah
16:08:34 <tflink> #undo
16:08:34 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x27454b90>
16:08:36 <tflink> #undo
16:08:36 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x27e1c0d0>
16:08:39 <tflink> #info Proposed Blocker, anaconda, NEW
16:08:43 <tflink> #topic (901917) rescue a fedora system mode doesn't recognize luks installation
16:08:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=901917
16:08:49 <tflink> #info Proposed Blocker, anaconda, NEW
16:09:20 <adamw> per the criteria this should be beta
16:09:28 <adamw> alpha says "The rescue mode of the installer must start successfully and be able to detect and mount an existing default installation."
16:09:42 <adamw> beta says "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations."
16:09:58 <tflink> yeah, not a default install
16:10:09 <tflink> +1 FE, +1 beta blocker
16:10:20 <pschindl> yes. I'm +1 for beta and +1 FE
16:10:28 <mkrizek> +1 beta blocker
16:10:34 <adamw> same
16:10:45 <jreznik> same as adamw
16:10:50 <kparal> yep
16:11:29 <tflink> proposed #agreed 901917 - RejectedBlocker (alpha) AcceptedFreezeException (alpha) AcceptedBlocker (beta) - Violates the following F20 beta release criterion: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations."
16:11:47 <kparal> ack
16:11:48 <mkrizek> ack
16:11:49 <pschindl> ack
16:12:02 <tflink> #agreed 901917 - RejectedBlocker (alpha) AcceptedFreezeException (alpha) AcceptedBlocker (beta) - Violates the following F20 beta release criterion: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations."
16:12:10 <tflink> #topic (997690) SizeNotPositiveError: bytes= param must be >=0
16:12:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=997690
16:12:10 <tflink> #info Proposed Blocker, anaconda, POST
16:12:45 <tflink> oh, any volunteers for secretary duty?
16:13:18 * tflink looks at kparal, mkrizek and pschindl
16:13:43 <kparal> hmm, okay
16:13:58 <kparal> do we have a template? :)
16:14:22 <tflink> I don't think so, I think adam usually makes it up as we go
16:14:33 * adamw is doing it
16:14:45 <adamw> yeah, the template lives in my head i'm afraid
16:15:00 <kparal> no problem, I'll have a look at the old blockers
16:15:11 <adamw> really all it is is "Discussed at $DATE blocker review meeting: <meetbot link>"
16:15:18 <adamw> everything after that is freeform
16:15:41 <adamw> refer to the relevant release criterion in all cases, try to provide comprehensive explanation of the decision
16:16:17 <adamw> kparal: i've done this bug but i'll gladly hand off to you for the rest :)
16:16:29 <kparal> adamw: deal
16:16:54 <tflink> it sounds like this is a showstopper in a default install from livecd
16:17:13 <adamw> yup, seems that way. the good news is the patch fixes it, so it just needs pushing.
16:17:25 <tflink> +1 blocker
16:17:28 <adamw> +1
16:17:33 <pschindl> +1
16:17:58 <kparal> +1
16:18:04 <jreznik> +1
16:18:05 <mkrizek> +1
16:18:24 <tflink> proposed #agreed 997690 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation to a single disk using automatic partitioning."
16:18:44 <kparal> ack
16:18:45 <pschindl> ack
16:19:05 <adamw> ack
16:19:07 <mkrizek> ack
16:19:08 <tflink> #agreed 997690 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation to a single disk using automatic partitioning."
16:19:18 <tflink> #topic (985342) illegal instructions with glibc-2.17.90 on armv7hl
16:19:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=985342
16:19:23 <tflink> #info Proposed Blocker, glibc, ASSIGNED
16:20:37 * tflink doesn't understand arm well enough to say if this is a blocker
16:20:49 <adamw> i believe this bug is preventing rawhide working on trimslices, if i've got it straight
16:20:53 <adamw> pwhalen: ?
16:20:54 <tflink> installing to a chroot doesn't seem like blocker material to me
16:21:01 <pwhalen> adamw, right, only the trimslice is affected
16:21:10 * tflink found a new person to chide about not justifying blocker proposals
16:21:17 * kparal looking for a list of blocking arm arches
16:21:27 * tflink wonders if this is why his trimslice has been randomly locking up
16:21:49 <pschindl> kparal: I think I've seen somewhere that it is blocking one.
16:21:53 <pwhalen> tflink, you would receive a complaint during install
16:21:54 <kparal> so, https://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms says "supported"
16:21:55 <adamw> kparal: arm team is debating the supported platform list for f20, when they decide on it it'll be up at the URL linked in the criteria i believe
16:22:13 <adamw> oh yeah, dgilmore threw one together for us
16:22:16 <tflink> pwhalen: no, install runs fine - it just locks up completely and garbles the screen after running a while
16:22:30 <tflink> but that is a discussion for another channel/time
16:23:07 <pwhalen> we're not sure what we can support in f20, I'd like that as soon as possible and we'll talk about it in todays meeting
16:23:10 <tflink> what criterion would we use for this? is the install not starting?
16:23:21 <tflink> or just not finishing
16:23:54 <pwhalen> the armhfp image which should be used for the trimslice will kernel panic on boot
16:24:00 <kparal> are we talking about anaconda, when we talk about ARM installs?
16:24:24 <tflink> I don't think so
16:24:33 <kparal> so, we're talking about the image creation process
16:24:36 <tflink> the arm images boot into initial-setup
16:24:43 <tflink> no, it's initial boot
16:24:48 <tflink> the "firstboot" criterion?
16:25:03 <adamw> tflink: are you actually testing f20?
16:25:10 <tflink> "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."
16:25:22 <tflink> adamw: no, I was getting F19 "working" first
16:25:32 <tflink> for a very liberal definition of working
16:25:42 * tflink is not a huge fan of his trimslice
16:25:52 <pwhalen> adamw, I've been testing the arm images
16:26:04 <tflink> I can start testing them, though
16:26:17 <tflink> I have a pandaboard and a trimslice - both of which are likely to be supported for F20
16:26:41 <tflink> I don't think there are images for the beaglebone yet, though
16:26:44 <tflink> but I digress
16:26:57 <adamw> pwhalen: so you'd expect that f19 would be ok for tflink?
16:27:11 <tflink> does that sound like an appropriate criterion w/ note that it's only the trimslice?
16:27:17 * nirik has a BBB which he will bring up as soon as there is support and also make available as a test machine for packagers/qa
16:27:21 <adamw> assuming we can trust the information that this bug is causing f20 on trimslice to be doa, i'm +1
16:27:24 <pwhalen> so this bug is glibc is using a capability it shouldnt (neon), so anything with it will not work.. tegra2
16:27:37 <pwhalen> *without it
16:27:50 <pwhalen> adamw, f19 should work with no issues, I would be happy to help
16:27:55 <adamw> tflink: that and/or the one after it, sure.
16:28:14 * tflink is ok with either
16:28:17 <adamw> pwhalen: sure, i'm just clarifying that tflink's experience doesn't question the interpretation of the bug report
16:28:33 <adamw> tflink: me too, doesn't matter which - it violates both of them and the one above, really. :)
16:29:16 <tflink> proposed #agreed 985342 - AcceptedBlocker - Violates the following F20 alpha release criterion for trimslice (and potentially others): "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."
16:29:48 <tflink> no firstboot references for F20 :)
16:30:16 <tflink> ack/nak/patch?
16:30:27 <pwhalen> ack
16:30:28 <adamw> ack
16:30:29 <adamw> tflink: yeah, i finally fixed that :P
16:30:36 <kparal> ack
16:30:42 <pschindl> ack
16:30:42 <mkrizek> ack
16:30:43 <tflink> #agreed 985342 - AcceptedBlocker - Violates the following F20 alpha release criterion for trimslice (and potentially others): "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."
16:30:53 <tflink> #topic (979174) initial-setup-text.service does not run on console
16:30:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=979174
16:30:59 <tflink> #info Proposed Blocker, initial-setup, NEW
16:31:56 <adamw> so this affects you if you're installing the minimal arm image, accessing the installed system via a serial console other than ttyS0, if I read it right
16:32:05 <pwhalen> correct
16:32:12 <tflink> is this limited to ARM?
16:32:12 <adamw> that seems like a fairly specific configuration, but dgilmore is worried about it...
16:32:37 <adamw> tflink: i don't know, but it'd be somewhat less serious on x86 as you'd at least have a chance to set a root password during install
16:32:38 <tflink> it sounds like anything w/o serial console
16:32:44 <tflink> true
16:33:07 <tflink> I think this would hit any of the arm servers, though
16:33:21 * tflink can't remember the name off the top of his head, caldexa?
16:33:39 <adamw> calxeda
16:33:43 <pwhalen> it affects the minimal images if not using the right console
16:34:10 <tflink> pwhalen: is using the right console a possible workaround?
16:34:27 <adamw> i don't think you can control the name of the serial console.
16:34:30 <pwhalen> tflink, no, would be specified by the hardware
16:34:35 <tflink> ok
16:34:36 <adamw> well, the kernel presumably?
16:34:37 <pwhalen> there are two suggested fixes on that
16:34:49 <adamw> yeah, i saw them. i like the custom target. seems more robust all around.
16:35:12 <adamw> anaconda and fedup already use custom targets with pretty good success.
16:35:30 <pwhalen> adamw, I would agree
16:35:57 <tflink> the criterion that jumps out at me first is "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:36:20 <tflink> w/ headless arm boxes
16:36:56 <adamw> yes, that's the intended one here.
16:37:12 <adamw> i-s is the only "working mechanism" for arm disk image deployments.
16:37:18 <pwhalen> prevents setting the root password
16:37:47 <adamw> pwhalen: i think i put 'user account' in the criteria because you can use a user account with root privileges instead of a root pw if you like
16:37:56 <adamw> but anyhow, it covers teh case
16:37:57 <pwhalen> makes sense
16:38:41 <adamw> oh hey, here's a thing
16:38:42 <tflink> proposed #agreed 979174 - AcceptedBlocker - Violates the following F20 alpha release criterion for headless arm installs that don't always have ttyS0: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
16:38:47 <adamw> nack, for now
16:38:50 <tflink> ok
16:38:59 <adamw> we only actually require serial console to work at beta, as things stand
16:39:10 <adamw> "The installer must be able to complete an installation using the serial console interface." is a Beta criterion
16:39:35 <tflink> this is gonna get confusing with arm and its installation methods
16:39:52 <tflink> I'd argue that it affects koji builders
16:39:57 <adamw> well, not really, you can do an ARM deployment with a keyboard and monitor connected just like a PC one.
16:40:12 <tflink> but I'm not sure that's enough to justify special treatment
16:40:31 <adamw> the argument would have to be that serial console deployment is now sufficiently more common overall on our primary arches that it must move to alpha.
16:40:51 <pwhalen> the koji builders would be installed via kickstart and not affected by this one
16:41:07 <tflink> so this is just one-off installs to headless boxes?
16:41:14 <pwhalen> this would only affect the minimal disk images
16:41:38 <adamw> yeah, 'minimal' installs to headless boxes
16:42:03 <adamw> although...you need some kind of graphics-capable connection to do a non-minimal install to a headless box i guess
16:42:07 <pwhalen> ideally, if the desktop images had no display connected, it would display the initial-setup on the console
16:42:24 <adamw> when we say it 'works' for non-minimal i guess we mean it 'works' in that graphical i-s is displayed
16:42:45 <pwhalen> right
16:43:00 <pwhalen> or should be in an ideal world
16:43:17 <tflink> wait, is caldexa OMAP?
16:43:26 <pwhalen> no, calxeda is highbank
16:43:28 <tflink> or is there more affected HW than just OMAP
16:43:33 <adamw> this isn't hw-dependent
16:43:44 <adamw> it's just an issue with how the running of i-s is implemented
16:44:03 <tflink> adamw: the blockery-ness is, not all hw will use something other than ttyS0
16:44:05 <adamw> to make it actually appear we have the .service file say 'run this service before a tty appears anywhere', more or less
16:44:28 <adamw> the problem is that in specifying that we only considered serial consoles on ttyS0, not anywhere else, so if your serial console is anywhere else, a tty shows up on it, nerfing i-s
16:44:42 <dgilmore> most arm systems use some device other than ttyS0 for serial
16:44:50 <adamw> tflink: from the bug it sounds like just about all arm systems use something else...yeah.
16:45:00 <tflink> ok, I only saw OMAP mentioned specifically
16:45:01 <adamw> so, it sounds like there isn't really a 'workaround' for this unless you have graphical remoting
16:45:27 <pwhalen> right
16:45:31 <tflink> the next question is whether it blocks alpha
16:45:34 <adamw> so the ultimate question is: are we OK shipping alpha such that you can't do an install on most headless ARM boxes? given that by the criteria we've always been OK with shipping x86 Alpha that way?
16:45:37 <dgilmore> adamw: the workaround i did for f19 final was to extend the list to all the known ones
16:45:50 <dgilmore> i did it with a sed in the kickstart
16:45:57 <adamw> dgilmore: egads
16:46:03 * Viking-Ice catches up
16:46:06 <adamw> ahoy viking
16:46:15 <dgilmore> a short term workaround would be to add them in the package
16:46:20 <adamw> dgilmore: sure, we can certainly fix the bug
16:46:32 <adamw> we're now into a philosophical blockeriness debate, which is so much more fun :P
16:46:42 <dgilmore> longer term we probably want systemd to be smarter
16:46:49 * adamw doesn't really know how much more common headless is on ARM
16:47:06 <adamw> are people who want to run f20 alpha on ARM going to really expect to be able to do it headless and be really sad if they can't?
16:47:15 <dgilmore> adamw: so really its a beta criteria today, but i think maybe we need it for alpha
16:47:17 <pwhalen> adamw, I think quite a few use them headless
16:47:23 <adamw> or will they just say 'eh, it's an alpha, that's fine' and plug in a keyboard?
16:48:02 <dgilmore> adamw: if they can
16:48:27 <pwhalen> for an alpha in notes we could also describe how to 'unlock' the root acct
16:48:28 <dgilmore> adamw: im not sure initial-setup runs at all
16:48:39 <pwhalen> dgilmore, as of todays rawhide, no
16:48:45 <dgilmore> there is two workarounds
16:49:00 <dgilmore> adamw: workaround one is to unlock root
16:49:02 <adamw> dgilmore: i don't mean 'plug in a keyboard after booting', i just mean 'plug in a keyboard and do it again'.
16:49:20 <adamw> dgilmore: when you say 'workarounds' do you mean 'workarounds for users' or 'workarounds for devs'?
16:49:25 <dgilmore> workaround two is to edit the service file
16:49:35 <dgilmore> adamw: for users
16:49:35 <adamw> because we don't need workarounds for the devs. it's easy enough to just do the same fix you did for f19. we can do that in five minutes.
16:49:53 <adamw> dgilmore: you mean editing the image file before deploying it?
16:50:01 <dgilmore> adamw: we can just do that as well
16:50:09 * adamw wondering if we're starting to spend more time discussing the blockeriness of this bug than it would take to just fix it
16:50:20 <dgilmore> adamw: yeah
16:50:20 <tflink> :)
16:50:32 <adamw> okay, how about for now we just take it as an FE and beta blocker and fix the damn thing so we can forget about it
16:50:42 <tflink> yeah, that sounds prudent
16:50:48 <Viking-Ice> hmm agetty running on something other then tty in systemd
16:50:54 <dgilmore> adamw: so its not a alpha blocker with todays critera but is sucky
16:51:06 <adamw> dgilmore: right. effectively what we're debating now is whether to change the criteria.
16:51:13 <adamw> but we can probably do that out of the meeting and move on.
16:51:18 <Viking-Ice> well arguably we should be defaulting to empty root password ( mail for that later on
16:51:21 <Viking-Ice> )
16:51:31 <dgilmore> yeah. lets note it for later discussion
16:51:34 <adamw> Viking-Ice: yeah, i think that's probably off-meeting topic too :)
16:52:06 <tflink> proposed #agreed 979174 - RejectedBlocker (alpha) AcceptedFreezeException (alpha) AcceptedBlocker (beta) - Violates the following F20 beta release criterion for many headless minimal arm installs: "The installer must be able to complete an installation using the serial console interface."
16:52:34 <adamw> ack for now - kparal might want to make a passing note that we can consider changing the criteria when updating the bug
16:52:35 <dgilmore> ack
16:52:37 <Viking-Ice> ack
16:52:42 <pwhalen> ack
16:52:53 <kparal> ack
16:52:59 <adamw> er
16:53:04 <adamw> oh well, let it pass.
16:53:21 <tflink> proposed #agreed 979174 - RejectedBlocker (alpha) AcceptedFreezeException (alpha) AcceptedBlocker (beta) - Violates the following F20 beta release criterion for many headless minimal arm installs: "The installer must be able to complete an installation using the serial console interface."
16:53:26 <tflink> bah
16:53:46 <tflink> #agreed 979174 - RejectedBlocker (alpha) AcceptedFreezeException (alpha) AcceptedBlocker (beta) - Violates the following F20 beta release criterion for many headless minimal arm installs: "The installer must be able to complete an installation using the serial console interface."
16:53:47 <adamw> swing and a miss
16:53:52 <tflink> strike 1
16:54:02 <tflink> #topic (997149) task systemd-udevd:757 blocked for more than 120 seconds.
16:54:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=997149
16:54:07 <tflink> #info Proposed Blocker, kernel, MODIFIED
16:54:34 <adamw> so...this is the 'anaconda hangs on returning from partitioning spoke' bug
16:54:37 * Viking-Ice notes uhum Violates the following F20 beta <--- release
16:55:04 <adamw> Viking-Ice: yes, it was rejected as alpha blocker, accepted as beta blocker. so that's appropriate
16:55:24 <adamw> bcl figured this bug was ultimately due to a kernel issue, but now it's looking like the kernel issue's been fixed and anaconda's still broken, sadly
16:55:24 <Viking-Ice> ah yes just look the tail
16:55:56 <Viking-Ice> the underlying cause in this bug is about educated guess-ess right ;)
16:55:57 <tflink> Viking-Ice: I'm not seeing the issue
16:56:08 <tflink> nvm, being slow today
16:56:25 <adamw> Viking-Ice: it seems like it's one of those "difficult to pin down" bugs :(
16:56:29 <Viking-Ice> punt for more data
16:56:35 <adamw> well, it's a clear +1 blocker
16:56:58 <adamw> Viking-Ice: it's clearer if you read the dupe bug - https://bugzilla.redhat.com/show_bug.cgi?id=983319
16:57:22 <adamw> we're not very sure what's going wrong or how to fix it, but the bug itself is very obvious: so far as I know no-one who's tried an F20 install has dodged it, it seems to be a complete showstopper
16:57:44 <adamw> we might want to un-dupe 983319 and consider it instead of this one
16:57:52 <Viking-Ice> yeah this is a blocker
16:58:05 <adamw> in fact can I propose that? it should make things much clearer.
16:58:14 <pschindl> +1 one for 983319. It should be reopen if the kernel isn't the issue
16:58:23 <Viking-Ice> agreed
16:58:30 <adamw> ok, let me do the bureaucracy
16:59:14 <tflink> are we moving the proposal around, then?
17:00:03 <adamw> tflink: yeah, i've dropped 997149 as a proposed blocker, and re-opened 983319
17:00:06 <adamw> so can we switch to that bug?
17:00:58 <tflink> #info the blocker proposal was transferred to 997149 when 983319 was closed as a dupe - that bug has been re-opened and the proposal for release blocking status moved back
17:01:32 <Viking-Ice> has this been reproduced on physical hw ?
17:02:11 <tflink> #topic (983319) Install gets stuck returning from Installation Destination spoke
17:02:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=983319
17:02:16 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:02:45 <adamw> Viking-Ice: let me check
17:03:00 * Viking-Ice brb
17:03:14 <tflink> do we want to use "The installer must be able to complete an installation using any supported locally connected storage interface." ?
17:03:25 <kparal> VM bugs are also Alpha blockery, aren't they?
17:03:31 <kparal> so +1 blocker
17:03:37 <pschindl> +1 blocker
17:04:08 <adamw> not sure what bcl's testing on
17:04:13 <adamw> but i know others than he and I have seen it
17:04:19 <adamw> +1 for now, i'll try and test this on metal in a bit
17:05:00 <tflink> proposed #agreed 983319 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation using any supported locally connected storage interface."
17:05:36 <pschindl> ack
17:05:37 <adamw> ack
17:07:02 * tflink gets out the many-tailed stick of ultimate poking
17:07:11 <tflink> kparal, Viking-Ice - ack/nak/patch?
17:07:19 <kparal> ack
17:07:23 <tflink> #agreed 983319 - AcceptedBlocker - Violates the following F20 alpha release criterion: "The installer must be able to complete an installation using any supported locally connected storage interface."
17:07:26 * adamw dding a live image
17:07:39 <tflink> OK, that's all of the bugs I have on my list for today
17:08:11 <tflink> assuming that no more were proposed since we started, it's time for ...
17:08:15 <tflink> #topic Open Floor
17:08:30 <tflink> Is there anything that should be brought up in-meeting today?
17:09:43 <tflink> I assume that silence == nothing to bring up
17:09:44 <adamw> nothing specific, but we really need to get the showstopper fixed and do a tc1 :/
17:09:51 <adamw> we have no idea what's lurking behind the showstopper and no way to find out
17:10:02 <dgilmore> first branched compose is about to land
17:10:05 * tflink needs to get some sd cards ordered
17:10:44 <Viking-Ice> ack
17:11:43 <tflink> if there's nothing else ...
17:11:44 <adamw> i'll yell in the bug if the showstopper doesn't happen on metal
17:12:00 <Viking-Ice> roger
17:12:02 * tflink sets the patent-pending quantum fuse for [0,5] minutes
17:12:37 <Viking-Ice> did we  switch to extra time travel fuse this release cycle
17:13:05 <tflink> we applied for the patent during f19, I think
17:13:21 <tflink> started using the fancy fuses during 17 or 18
17:14:07 * Viking-Ice wonders how long the quantum fuse runs in alternative universe
17:15:00 <tflink> Viking-Ice: we could test this, but we have a lack of hardware
17:15:03 <adamw> oh, it's blown up countless alternative universes
17:15:06 <adamw> the casualties are huge
17:15:07 <tflink> and it's not part of the release criteria :)
17:16:09 <Viking-Ice> no funding an alternative universe door from ebay
17:16:14 <Viking-Ice> for an
17:16:26 <tflink> not yet, anyways :)
17:16:44 <tflink> Thanks for coming, everyone!
17:16:50 * tflink will send out minutes shortly
17:16:52 <tflink> #endmeeting