17:00:06 <jlaska> #startmeeting F16 Alpha Blocker Review
17:00:06 <zodbot> Meeting started Fri Jul 22 17:00:06 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:11 <jlaska> #meetingname F16-blocker-review
17:00:11 <zodbot> The meeting name has been set to 'f16-blocker-review'
17:00:17 <jlaska> #topic Roll Call
17:00:22 <jlaska> let's get this party started!
17:00:27 * tflink is present
17:00:30 * athmane is here
17:00:35 * bcl waves
17:00:42 <athmane> but doing other stuff
17:00:49 <jlaska> athmane: gotcha, thanks for joining
17:00:56 <jlaska> hi tflink bcl
17:01:07 * pjones dances a jig
17:01:16 * jlaska activates webcam
17:01:19 * robatino here
17:01:55 * nirik is lurking.
17:02:13 <jlaska> hey robatino nirik
17:02:13 * adamw checking in from a somewhat dodgy wifi connection on a train between bellingham and seattle
17:02:44 <jlaska> welcome high-speed adamw
17:03:02 <adamw> let me know if i get too laggy and i'll shut up
17:03:11 <jlaska> k
17:03:23 <jlaska> #topic Basic information
17:03:26 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:03:30 <jlaska> #link https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
17:03:35 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:03:43 <jlaska> I think that about covers it ...
17:04:10 <jlaska> okay, I'm going to start with the proposed Alpha blockers
17:04:29 <jlaska> before we do ... anyone want to volunteer to secretize?
17:04:38 <tflink> I can
17:04:44 * jlaska hearts tflink
17:04:47 <jlaska> thank you :)
17:05:13 <jlaska> okay, let's start off we a few proposed anaconda blockers ..
17:05:29 <jlaska> think of it as calisthenics
17:05:36 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=722963
17:05:37 <buggbot> Bug 722963: medium, unspecified, ---, dlehman, POST, TypeError: %d format: a number is required, not str
17:05:46 <jlaska> #info TypeError: %d format: a number is required, not str
17:06:09 <jlaska> look at this, tflink and adamw have already discussed this one
17:06:33 <jlaska> "I'm thinking -1 alpha blocker and +1 final
17:06:34 <jlaska> blocker."
17:07:15 <jlaska> I'm still not sure what the reproducer is
17:07:32 <jlaska> but I agree with tflink and adamw that if this isn't something you can hit on the first partition screen ... not alpha
17:07:40 <tflink> it sounded like a mistake made in manual partitioning
17:07:57 <adamw> "This occurs when the user tries to create a new partition that is not within
17:07:57 <adamw> the size limits for the type of formatting selected."
17:08:00 <adamw> yeah
17:08:10 <jlaska> yeah, which seems unusual
17:08:12 <jlaska> err, not common
17:08:24 <jlaska> I think we had a vote for final in the bz
17:08:31 <pjones> looks pretty easy to fix
17:08:32 <jlaska> which is our catchall for reasonable partition scenarios
17:08:35 <adamw> yeah, it seems clearly final, not alpha
17:08:47 <adamw> pjones: right, i think a patch is already in actually  - bug's in POST
17:09:01 <jlaska> sooner the better, but we'll only hold up the final for this one it seems ...
17:09:02 * rbergeron slinks in
17:09:44 <jlaska> proposed #agreed 722963 - AcceptedBlocker for F16Final - appears to involve manual partition scenarios where the partition is not within the size limits for the format selected
17:09:50 <adamw> ack
17:10:00 <tflink> ack
17:10:04 <pjones> adamw: huh... it doesn't *look* fixed
17:10:27 <jlaska> oh did this get incorrectly moved to POST?
17:10:36 <jlaska> if no other votes ... I'll ack it
17:10:56 <jlaska> looks like dlehman moved it to POST, maybe by accident
17:11:02 <jlaska> (if it's not out for review on anaconda-devel)
17:11:08 <bcl> adamw: POST means a patch has been posted to the list for review
17:11:20 <bcl> MODIFIED means it has been pushed
17:11:22 <adamw> yeah, that's what i meant by 'in', sorry to be vague
17:11:26 <pjones> yep, patch on the list looks fine
17:11:31 <jlaska> #agreed 722963 - AcceptedBlocker for F16Final - appears to involve manual partition scenarios where the partition is not within the size limits for the format selected
17:11:45 <jlaska> #info Patch out for review on anaconda-devel, likely will be fixed well before F16Final
17:11:56 <jlaska> anything else to discuss on this one?
17:12:00 <adamw> nope
17:12:02 <pjones> no
17:12:03 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723144
17:12:04 <buggbot> Bug 723144: unspecified, unspecified, ---, dlehman, ASSIGNED, anaconda 16.12 crashed after the partition process
17:12:09 <jlaska> #info anaconda 16.12 crashed after the partition process
17:12:13 <jlaska> Argh!   LVM
17:12:37 <jlaska> so accepting all default options, this will crash in current anaconda
17:12:49 <jlaska> b/c we still have "[X] Use LVM?" selected by default
17:13:05 <jlaska> I think this still fits the spirit of the existing Alpha partitioning release criteria ...
17:13:09 <adamw> +1 alpha blocker, then.
17:13:13 <jlaska> "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled "
17:13:17 <pjones> yeah, definitely
17:13:28 <jlaska> I'd like to adjust the criteria for F16 to accomodate toggling LVM now
17:13:38 * jlaska would like to propose it includes whether LVM is enabled or disabled for Alpha
17:13:46 <jlaska> (but exclude any custom/manual partitioning)
17:13:51 <jlaska> as we already do
17:14:09 <adamw> yeah, we can look at ways of re-wording it
17:14:15 <jlaska> okay, post-meeting of course
17:14:34 <jlaska> #action jlaska will propose rewording Alpha release criteria for paritioning to include [X] Use LVM?
17:14:42 <jlaska> any other objections to AcceptedBlocker
17:14:45 * jlaska works up #agreed
17:15:42 <jlaska> #agreed 723144 - AcceptedBlocker - Impacts default partition scenario and Alpha partition criteria
17:15:46 <adamw> ack
17:15:57 <tflink> ack
17:16:03 * jlaska ready with #undo if needed
17:16:23 <jlaska> seems like there is little question on this one
17:16:26 * jlaska moves on
17:16:35 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=723345
17:16:36 <buggbot> Bug 723345: unspecified, unspecified, ---, clumens, MODIFIED, Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given)
17:16:40 <jlaska> #info Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given)
17:16:51 <jlaska> #info affects the Alpha criteria - "The rescue mode of the installer must start successfully and be able to detect and mount an existing default installation "
17:16:58 * Viking-Ice jumps in
17:17:03 <adamw> hey viking
17:17:05 <jlaska> tflink and I +1'd this in the bug report
17:17:07 <jlaska> Greetings Viking-Ice
17:17:23 * jlaska works #agreed
17:17:44 <jlaska> proposed #agreed 723345 - AcceptedBlocker for F16Alpha - impacts rescue mode Alpha criteria
17:17:48 <adamw> yup, looks like a straightforward +1
17:17:48 <adamw> ack
17:18:05 <tflink> ack
17:18:32 <jlaska> ack from Cranes
17:18:36 <jlaska> #agreed 723345 - AcceptedBlocker for F16Alpha - impacts rescue mode Alpha criteria
17:18:55 <Viking-Ice> ack
17:18:57 <jlaska> #info Already fixed in anaconda-16.13-1
17:19:09 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723475
17:19:11 <buggbot> Bug 723475: unspecified, unspecified, ---, rvykydal, NEW, anaconda-16.12 - Unable to activate networking in anaconda (stage2)
17:19:15 <jlaska> #info anaconda-16.12 - Unable to activate networking in anaconda (stage2)
17:19:41 <jlaska> some discussion already on this one too
17:19:55 <jlaska> I believe this impacts the boot.iso install scenario for ALpha
17:20:01 <jlaska> "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media "
17:20:17 <jlaska> ... since NM isn't activating networking properly, you cannot access the online repos for install
17:20:30 <jlaska> does not affect non-network DVD install ... and can be worked around by booting with "asknetwork"
17:20:35 <Viking-Ice> hum think it's odd that alpha requires network to be present and working in the installer
17:21:01 <pjones> jlaska: it is a little odd that that criteria says "run" not "successfully complete"
17:21:06 <jlaska> Viking-Ice: yeah, it'd probably be less of an issue if all we shipped was DVDs
17:21:10 <adamw> pjones: you win a coconut
17:21:13 <adamw> i was just about to say that
17:21:14 <jlaska> hehe
17:21:16 <pjones> if we mean the latter, it should say the latter.
17:21:21 <adamw> i'm not entirely sure why we phrased it that way
17:21:30 <jlaska> well, we can use other criteria for this one too
17:21:32 <adamw> we do have explicit bits of the beta criteria which say that installing from network repos must work
17:21:34 <Viking-Ice> I would rather say this was a beta criteria
17:21:36 <jlaska> "The installer must be able to use at least one of the HTTP or FTP remote package source options "
17:21:43 <adamw> so obviously we chose not to make those alpha criteria
17:21:45 <jlaska> Viking-Ice: if we shipped only DVD's ... I'd agree
17:21:49 <adamw> oh, yes, there it is
17:22:06 <tflink> but it doesn't affect just the HTTP/FTP installs, no?
17:22:15 <tflink> using the boot.iso implies netinstall which requires network
17:22:18 <jlaska> the theme for Alpha is ... *any* default install from the shipped media must work
17:22:25 <jlaska> tflink: right
17:22:57 <pjones> also I think the fact that there's an easy workaround mitigates just how critical it is.
17:22:58 <adamw> okay, so, i'll see if that can be clarified at all, but seems we do expect remote install to work at this point. but...the workaround seems pretty simple and painless.
17:23:19 <jlaska> huh ... that's news to me
17:23:25 <tflink> for an alpha, yeah. the workaround isn't too bad
17:23:27 <adamw> what is?
17:23:39 <jlaska> remote installs not being desired for Alpha?
17:23:49 <adamw> i said 'do', not 'don't'.
17:24:10 <jlaska> adamw: okay, *that* makes much more sense :)
17:24:24 * jlaska adjusts ocular cavities
17:24:30 <pjones> I'm still thinking this doesn't need to be a blocker.  The workaround is trivial.
17:24:49 <jlaska> hmm ...
17:24:53 <Viking-Ice> nth ?
17:24:57 <jlaska> I think this also would impact bugzilla's coming in from anaconda
17:24:58 <pjones> Viking-Ice: yeah
17:25:12 <adamw> jlaska: that would be a good thing to check
17:25:17 <pjones> jlaska: maybe - but that's not in the criteria at all, is it?
17:25:25 <jlaska> "The installer must be able to report failures to Bugzilla, with appropriate information included "
17:25:30 <pjones> oh, huh, so it is.
17:25:37 <pjones> so we need to see if that works.
17:25:43 <jlaska> okay
17:25:51 <pjones> and if the workaround also fixes that ;)
17:25:55 <jlaska> but still, I think the spirit of the existing criteria is that this should work
17:25:58 <tflink> I thought that this bug came out of reporting crashes from anaconda
17:26:02 <jlaska> so if we decide the workaround is okay, we need to change the criteria
17:26:12 <tflink> we do?
17:26:16 <jlaska> tflink: you're right, I believe it was related
17:26:25 <adamw> the workaround would presumably work there, but obviously people aren't going to expect to have to workaround a network issue when doing a dvd install, so yeah, we might miss some bug reports
17:26:25 <adamw> i'm kinda on the fence with this one
17:26:46 <pjones> I don't think we need to change the criteria; the reason we've got a bunch of smart people making these decisions is to allow flexibility.
17:27:03 <bcl> the sooner we get bugreports in anaconda the better.
17:27:07 <jlaska> if the workaround was click this, then do this ... but it involves rebooting and entering a boot arg
17:27:14 <jlaska> that's not horrible at all, but meh
17:27:18 <jlaska> just feels ... sub-standard
17:27:30 <pjones> jlaska: well, maybe.  we could just change the bootloader config to include the boot arg by default.
17:27:34 <adamw> jlaska: no, we don't
17:27:56 <pjones> (though that could potentially be more work than fixing the bug)
17:27:56 <adamw> the criteria are written so that we can make a bug that infringes them, but for which there's an easy workaround, not a blocker.
17:28:00 <adamw> we've done it quite a few times in the past.
17:28:09 <jlaska> "reasonable workaround "
17:28:18 <jlaska> so it's just deciding if this is reasonable or not
17:28:28 <jlaska> I don't think it is since boot.iso requires networking in the default scenario
17:28:46 <jlaska> if this was more of a corner case, I'd be fine ... I'm not comfortable with a workraound for a default use case
17:28:55 <adamw> jlaska: if you read the common bugs before you start the install, you'd get to skip the 'try once and fail' step :P
17:29:10 <pjones> jlaska: we can make the bootloader config specify asknetwork
17:29:18 <tflink> adamw: that would be ideal, but how many people do that?
17:29:30 <jlaska> so if this prevents bugs from being filed, and requires workaround for boot.iso ... I think we need to fix it for Alpha
17:29:51 <jlaska> pjones: that's a valid short-term option ... but then DVD installers will complain (but it is short-term)
17:29:58 <tflink> I wouldn't say prevents but certainly discourages
17:30:18 <adamw> pjones: it's not a terribly difficult bug to fix is it, or anything?
17:30:21 <jlaska> tflink: well, I go with prevents because it requirse rebooting to get networking to work
17:30:25 <pjones> jlaska: yeah, but it's not the end of the world; installs will complete, bug reports will get filed.
17:30:26 <jlaska> by then, the bug is gone
17:30:29 <adamw> it's not like we're down to the wire here, we're just being our usual bureaucratic selves
17:30:41 <jlaska> adamw: we've got to debate something, right? :D
17:30:54 <jlaska> okay ... so we are deadlocked on this one
17:30:56 <Viking-Ice> jlaska, we used to be able to put the anaconda bug dumps on media like usb keys has that stopped working ?
17:30:57 <pjones> adamw: not really sure we've figured out what's going wrong, from reading the bug
17:30:57 <jlaska> unless we want to put it to a vote
17:31:10 <jlaska> Viking-Ice: don't know ... it'll be tested next week
17:31:11 <tflink> jlaska: like I said, discourages. but this is symantics .. not all that important. prevents is close enough
17:31:18 <jlaska> tflink: roger
17:32:02 <adamw> shall we punt till next week when we'll know about the bug filing scenario?
17:32:22 <jlaska> #info group debated whether workaround of booting with "asknetwork" is acceptable for Alpha
17:32:27 <adamw> cos i'm pretty sure i'd be -1 if only network installs were affected, but it might be different if bug filing when doing a dvd install is affected also.
17:32:42 * jlaska feels like we are changing our tune for previous alpha releases
17:32:58 <jlaska> but we have a team of voters here for a reason ... so I'm okay to be over ruled :)
17:33:08 <tflink> adamw: check out comment #1 - Description of problem:
17:33:08 <tflink> Anaconda 16.12 can not save traceback to bugzilla, which dues to the network
17:33:11 <tflink> problem, while the network is fine
17:33:43 <tflink> unless you were talking about saving traces to a disk and submitting them manually
17:34:11 <jlaska> going by the criteria, I believe it's intended to capture direct filing into bugzilla - "The installer must be able to report failures to Bugzilla, with appropriate information included "
17:34:14 <adamw> tflink: oh, missed that
17:34:20 <adamw> jlaska: yeah, that's the intent
17:34:38 <adamw> jlaska: i don't think we have a direct precedent for this, because it always comes down to judgement when there's a workaround
17:34:56 <jlaska> okay, proposals?
17:35:04 <Viking-Ice> NTH and revisit later
17:35:11 <adamw> +1 viking
17:35:12 <tflink> as much as I would like to see this fixed before alpha, would we block release if it wasn't fixed?
17:35:12 <jlaska> if it's NTH ... we won't revisit it later
17:35:17 <pjones> if we can wait a week, it's probably worth it to do so.
17:35:20 <jlaska> tflink: I would +1 that :)
17:35:29 <adamw> jlaska: if we didn't mark it AcceptedBlocker or RejectedBlocker we would
17:35:33 <adamw> because it would still be a proposed blocker
17:35:34 <jlaska> adamw: fair enough
17:35:39 <jlaska> adamw: ah right
17:35:54 <adamw> i'm all in favour of waiting and hoping it goes away
17:36:02 * adamw will owe pjones a beer if it magically disappears by next meeting
17:36:21 <pjones> it probably won't be me fixing it if it does
17:36:35 <pjones> (but I will accept beer.)
17:36:45 <jlaska> so what information would we need to decide whether it's accepted/rejected Alpha blocker?
17:36:55 <jlaska> or are we just hoping it goes away instead?
17:37:04 <pjones> well, we're hoping for more information, at least
17:37:18 <jlaska> pjones: of what, another use case that might be impacted?
17:37:26 <pjones> a diagnosis of the problem would be a good start.  some testing of the workaround in various scenarios would also be nice.
17:37:33 <tflink> whether a fix is likely before alpha, whether there are a number of lost bugs ...
17:37:52 <tflink> since the install media has been a bit MIA this week, I don't think many people have been trying it out
17:38:21 * jlaska feels comfortable with the install media impact at this point
17:38:29 <jlaska> but you're right, it hasn't had a lot of exposure yet
17:38:46 <Viking-Ice> revisit next week ?
17:39:05 <jlaska> proposed #agreed 723475 - review again next week, unable to reach consensus on nature of workarond
17:39:09 <tflink> I'd be fine with NTH, leave proposed blocker and see if we can get more info for next week
17:39:09 <pjones> this is a 2 day old report.
17:39:25 <tflink> pjones: it was spawned out of an older bug
17:39:34 <tflink> not that much older, though IIRC
17:39:43 <adamw> ack
17:39:52 <pjones> revisit.
17:40:18 <tflink> as long as we're requesting more details on the problem, ack
17:40:40 <jlaska> #agreed 723475 - unable to determine if workaround is acceptable for Alpha, review blocker status again next week with more details on failure
17:41:07 * jlaska removes his PITA hat ... and moves on to the next bug :)
17:41:17 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=725040
17:41:18 <buggbot> Bug 725040: unspecified, unspecified, ---, anaconda-maint-list, NEW, rawhide installs generic-release package, instead of fedora-release
17:41:21 <jlaska> #info rawhide installs generic-release package, instead of fedora-release
17:41:30 <jlaska> okay this one I wasn't sure about ... so I pushed it here for more eyes
17:41:45 <jlaska> shipping with generic-release I believe is *not* intended for any official media
17:41:50 <bcl> I think it might be a lorax thing.
17:41:56 <jlaska> but I don't know what breaks because of this
17:42:02 <jlaska> bcl: oh?
17:42:34 <bcl> does the install media have /etc/fedora-release, etc. on it?
17:42:37 <pjones> they both appear to be in the tree.
17:42:40 <pjones> hrm.
17:42:47 <tflink> what does this break?
17:42:47 <jlaska> bcl: hmm, I don't know ...
17:42:55 <adamw> the generic-* packages are supposed to be blocked from media composes
17:43:02 <bcl> In one of the lorax templates it is removing fedora-release and fedora-release-rawhide
17:43:10 <adamw> i believe that's releng's responsibility and happens 'manually' in the compose commands
17:43:18 <adamw> (or was, i dunno what impact lorax has)
17:43:25 <bcl> but I'm not totally sure which templates are applied.
17:43:25 <jlaska> bcl: build log for latest live nightly - http://koji.fedoraproject.org/koji/getfile?taskID=3223177&name=root.log
17:43:32 <pjones> so that does sound like it's probably lorax
17:43:42 <bcl> live is not lorax
17:43:54 <jlaska> bcl: and then I see it later installing generic-release (not fedora-release)
17:44:08 <jlaska> so ... I think this needs to be fixed, but I can't find criteria that we have for this
17:44:31 <jlaska> so I'd propose tentatively accepting and I'd draft up some alpha criteria that we cannot install generic-* ?
17:44:36 <tflink> I'm still not understanding the practical impact of having generic-release instead of fedora-release
17:44:36 <adamw> i remember adding some criteria for this lately
17:44:40 <adamw> i think it was past alpha
17:44:43 <jlaska> adamw: we have something for final, yeah
17:45:01 <jlaska> but it's more to ensure that the final version is bumped to *not* say Beta or pre-release
17:45:01 <adamw> yeah, it's final
17:45:19 <adamw> hm, yeah.
17:45:26 <pjones> tflink: logos all look like hotdogs.
17:45:42 <jlaska> pjones: perfect thanks!
17:45:44 <adamw> though i'd rather know the practical impact of this before deciding it has to be fixed. the -release packages contain the system id stuff, repo definitions and keys, basically
17:45:46 <jlaska> that's the criteria impacted for Alpha
17:45:48 <tflink> if that's the impact, why should it block release?
17:45:58 <tflink> for final, sure
17:45:58 <jlaska> "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 16), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the installer, graphical bootloader menu, firstboot, graphical boot, graphical login and desktop background. "
17:46:07 <pjones> because we want the fedora alpha release to look like fedora.
17:46:10 <jlaska> I think having the hot-dog grahpics would impact that criteria
17:46:24 <adamw> right. i suspect that's generic-logos rather than generic-release, but hey.
17:46:34 <pjones> we have actually had problems in the past where artwork changes later cause failures, so we'd like them in test releases if possible.
17:46:54 <jlaska> adamw: oh hmmm you're correct
17:47:00 <pjones> adamw: I'm... assuming it's generic-*
17:47:00 <jlaska> that might also be installed too ... checking
17:47:09 <adamw> jlaska: they tend to go together - either they're all right or they're all wrong
17:47:11 <adamw> pjones: yeah
17:47:16 <pjones> jlaska: should be; it's pulled in as a -release dep IIRC
17:47:20 <jlaska> adamw: right
17:48:04 <jlaska> huh, fedora-logos is installed
17:48:27 <jlaska> the only impact I know of right now is -> http://jlaska.fedorapeople.org/screenshots/Screenshot.png
17:48:37 <jlaska> and I'm sure other peoples scripts that rely on /etc/issue would break
17:48:54 <pjones> weeird.
17:49:14 <jlaska> so ... do we want to go with NTH ... or Blocker and I'll work up some criteria for review post-meeting?
17:49:22 <jlaska> (or rejected*)
17:49:24 <Viking-Ice> NTH
17:49:27 <tflink> NTH
17:49:32 <adamw> er
17:49:39 <adamw> if this affects the artwork it's definitely a blocker...
17:49:42 <jlaska> agreed
17:49:46 <bcl> NTH
17:49:52 <jlaska> I can't tell so far ... would need to retest on bare-metal
17:49:55 * adamw is still confused as to whether this is a live or regular installer issue
17:50:02 <jlaska> started as regular
17:50:04 <jlaska> I haven't tested live
17:50:09 <bcl> also test boot.iso vs. live.
17:50:32 <jlaska> proposed #agreed 725040 - AcceptedNTH for F16Alpha - leave on proposed blocker list until we can confirm this does not impact artwork
17:50:35 <tflink> jlaska: wouldn't looking at the plymouth splash be enough to tell on the artwork?
17:50:43 <jlaska> tflink: oh yeah ...
17:50:47 <jlaska> tflink: it says "Generic"
17:50:53 <jlaska> tflink: but it's a virt guest, so I don't get graqphics
17:50:59 <jlaska> but I think that means I'd get the hot-dog
17:51:00 <adamw> huh.
17:51:04 <satellit_> FYI: I just tried liveinst from Fedora-16-Nightly-20110722.09-i686-Live-soas.iso which boots properly has generic (with f15) installs fine but no firstboot cannot login as get "other" ends up at blue screen with bird in tree gdm
17:51:07 <jlaska> what's the way to force graphical boot in kvm guest again?
17:51:11 <adamw> the live image seems to have generic-release but fedora-artwork.
17:51:16 <adamw> i wonder if it's a version thing
17:51:23 <pjones> bcl: bug report appears to not be against live
17:51:37 <bcl> ok, that's good.
17:51:48 <jlaska> adamw: did you want to suggest a different #agreed ?
17:51:59 * adamw looking at livecd.log from the latest live nightly compose
17:52:53 <Viking-Ice> seriously is artwork allowed blocking the alpha release these days..
17:52:53 <adamw> if this affects -release rather than -artwork, not entirely
17:53:00 <adamw> since we don't really know the exact impact
17:53:03 <Viking-Ice> anyway I'm nth and or rejected
17:53:21 <jlaska> Viking-Ice: it sounds crazy ... but you have to start holding the line on bugs sooner or later ... they can't all wait to Final
17:53:28 <adamw> Viking-Ice: yes, it is; as anaconda team mentioned it can actually cause bugs, and branding is a serious consideration
17:54:02 <adamw> i note fedora-release-16-0.1 was built in february, and generic-release-16-0.1 in may. that might somehow have something to do with it, i guess. not sure how.
17:54:08 <tflink> wasn't there a last minute artwork issue with F15?
17:54:13 <jlaska> adamw: yeah, could be
17:54:19 <pjones> adamw: shouldn't.  version numbers are the same, etc., as usual.
17:54:24 <jlaska> k
17:54:32 <pjones> I think more likely the lorax compose is picking something wrong
17:54:40 <jlaska> alright ... I'm moving forward with proposed .. and we can test this further between now and TC1 to determine graphical impact
17:54:47 <adamw> pjones: i'm looking at a live compose, here, that's not lorax at all is it?
17:54:56 <adamw> okay
17:54:58 <jlaska> #agreed 725040 - AcceptedNTH for F16Alpha - leave on proposed blocker list until we can confirm this does not impact artwork
17:55:26 <pjones> adamw: don't think so... hrm.
17:55:27 <adamw> jlaska: well, i'd also like us to figure out exactly what impact it has, not just see if it affects artwork (i don't think it would)
17:55:41 <jlaska> patch?
17:55:47 <jlaska> (or toss it in #info)
17:55:59 <adamw> it may somehow affect another criterion. anyhow. moving on.
17:56:15 <jlaska> #info adamw noted this bug may impact more than just artwork ... further investigation needed
17:56:22 <adamw> pjones: check livecd.log at http://koji.fedoraproject.org/koji/taskinfo?taskID=3223177 and you can see it pulls generic-release
17:56:27 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723526
17:56:28 <pjones> indeed.
17:56:28 <buggbot> Bug 723526: high, unspecified, ---, mgracik, POST, firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot
17:56:40 <jlaska> #info firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot
17:57:00 <jlaska> I believe the criteria that brought this bug to the proposed list is ...
17:57:03 <jlaska> "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied "
17:57:20 <jlaska> if firstboot starts on every boot up, I believe it would affect that criteria
17:57:33 <adamw> yeah, that implies 'it shouldn't boot to firstboot again;
17:57:58 <adamw> so, +
17:57:58 <adamw> 1
17:58:04 <tflink> +1
17:58:12 <Viking-Ice> hum I though the systemd service files that I submitted to the firstboot guys disabled itself after successful run
17:58:25 <pjones> yeah, I'm not sure that's the method by which firstboot disables itself
17:58:47 <adamw> pjones: there's a belt and braces approach i think
17:59:00 <adamw> i believe it actually disables itself both ways
17:59:05 <jlaska> #agreed 723526 - AcceptedBlocker for F16Alpha - affects firstboot Alpha criteria by running firstboot on every boot-up
17:59:15 <adamw> jlaska: hold those horses...
17:59:18 <jlaska> #undo
17:59:18 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xce4f7ac>
17:59:25 <jlaska> hold up rusty
17:59:32 <adamw> it would be good to check if this actually results in firstboot running every boot after a clean install
17:59:52 <jlaska> well ... I just installed 3 times this morning ... and I see something different
18:00:01 <jlaska> firstboot doesn't start ... and I have to manaully enable it
18:00:09 <adamw> as i recall, what's supposed to happen is that when firstboot completes, it disables the firstboot service *and* writes NO into that config file
18:00:12 <jlaska> after that, it behaved correctly for the next, and following boots
18:00:25 <jlaska> adamw: yeah, that's my understanding
18:00:30 <adamw> after you manually enable it and run through it, does it keep running every boot after that?
18:00:44 <pjones> jlaska: okay, so that violates #14 instead of #15
18:00:50 <jlaska> adamw: it didn't appear to
18:00:53 <jlaska> pjones: right
18:00:57 <jlaska> I didn't file a bug yet for this behavior
18:01:03 <jlaska> Cranes has his limits
18:01:08 <adamw> okay
18:01:08 <adamw> so that sounds like there's a critical bug here but not this one...
18:01:17 <jlaska> could be this one might have magically been fixed
18:01:19 <pjones> just add it to the existing bug, since whoever's working on it will be working on the same part.
18:01:20 <jlaska> so new proposed ...
18:01:34 <adamw> (for the record, what happens - or should happen - if the firstboot service is enabled but that config file has NO in it is that the firstboot service starts the firstboot process, which reads that config file, sees the NO, and shuts itself right back down again)
18:01:56 <jlaska> proposed #agreed 723526 - Need more information to confirm whether bug exists after a *fresh* install
18:02:08 <adamw> yup
18:02:12 <adamw> +1
18:02:15 <Viking-Ice> systemctl disable firstboot.service should be sufficiant
18:02:18 <Viking-Ice> +1
18:02:39 <jlaska> also ... I'll file a new one, or repurpose this bug as pjones suggests, for the problem of firstboot not starting after install
18:02:52 <jlaska> any other ack/nak/patches?
18:02:55 <Viking-Ice> recent spec changes probably caused that one
18:03:04 <Viking-Ice> they drop the legacy sysv init script the other day
18:03:04 <robatino> i'll check if "systemctl disable firstboot.service" fixes it for me - my rawhide was installed around 15 alpha TC2, so certainly isn't new
18:03:14 <pjones> Viking-Ice: yeah, most likely.
18:03:34 <tflink> +1 to proposal
18:03:40 <jlaska> #agreed 723526 - Need more information to confirm whether bug exists after a *fresh* install
18:03:55 <adamw> and also if there are related bugs we can pile in
18:03:55 <jlaska> #action need confirmation whether firstboot is activated after a *fresh* install
18:03:55 <adamw> so, ack
18:04:16 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=718722
18:04:17 <buggbot> Bug 718722: unspecified, unspecified, ---, pjones, NEW, Mismatched or corrupt version of stage1/stage2
18:04:21 <jlaska> #info Mismatched or corrupt version of stage1/stage2
18:04:34 <jlaska> pjones: are you waiting on me to determine whether we can close this one out?
18:04:57 <pjones> no, I'm planning on looking at it monday
18:04:59 <Viking-Ice> that's an blocker
18:05:13 <pjones> yeah, it is a blocker.
18:05:54 <adamw> i recall last week we wondered about the impact of this, seems like we have more data on it now
18:05:56 <jlaska> I'm no longer seeing this problem with a fresh install ... does the issue remain?
18:06:43 * jlaska pauses for catch-up on bz updates
18:06:46 <pjones> the issue can only be triggered on an upgrade AFAIK
18:07:06 <pjones> (maybe?)
18:07:10 <pjones> I need to investigate more.
18:07:18 <Viking-Ice> hum does upgrade hit the alpha criteria
18:07:19 <adamw> if it only hits upgrades then it's not an alpha blocker, upgrades are beta
18:07:27 <pjones> jlaska: on a fresh install you're not getting grub 1 installed anyway
18:07:30 <jlaska> if it's upgrade (like installer upgrade), that'd give us until beta to resolve
18:07:32 <pjones> okay, so beta then.
18:07:34 <jlaska> pjones: that's right, I forgot
18:07:46 <pjones> I'm still looking at it next week :P
18:07:49 <jlaska> and we can CommonBugs a manual workaround
18:07:54 <jlaska> pjones: roger, thanks!
18:07:54 <Viking-Ice> yup rejected since this is an upgrade
18:08:09 <Viking-Ice> or moved to beta blocker
18:08:34 <adamw> if we're confident this is upgrade only, then -1 alpha, +1 beta
18:08:54 <jlaska> proposed #agreed 718722 - AcceptedBlocker for F16Beta, CommonBugs? - only impacts upgrades from F15 which is covered by beta criteria
18:09:04 <jlaska> if pjones uncovers something more nasty, we'll revisit
18:09:13 <tflink> ok, that works for me
18:09:51 <jlaska> #agreed 718722 - AcceptedBlocker for F16Beta, CommonBugs? - only impacts upgrades from F15 which is covered by beta criteria
18:09:56 <adamw> ack
18:10:14 <jlaska> btw ... if someone +1's the informal proposal, I've been just treating that as an ACK
18:10:25 <jlaska> if you'd prefer I wait for ack's on the formal proposal, I can
18:10:29 * jlaska looks at clock
18:10:40 <Viking-Ice> I think +1 should be fine
18:10:44 <jlaska> okay
18:11:01 <adamw> yeah
18:11:11 <jlaska> #info pjones plans to investigate and we'll revisit if the severity increases
18:11:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=723901
18:11:15 <buggbot> Bug 723901: unspecified, unspecified, ---, mgracik, NEW, pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install
18:11:19 <jlaska> #info pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install
18:11:31 <jlaska> so tflink and I discussed this a bit already, and he raised some good points
18:11:41 <pjones> I wouldn't be entirely surprised if this isn't related to the other issue.
18:11:49 <jlaska> pjones: yeah, could be!
18:11:55 <adamw> yeah, i expect it is
18:12:02 <jlaska> it's _possible_ that this might jsut go away when we branch
18:12:09 <adamw> i noticed when we were looking at it that generic-release's repo list is a lot shorter than fedora-release's
18:12:18 <pjones> yes.
18:12:19 <adamw> just do a repoquery -l on both and compare
18:12:25 <Viking-Ice> is this something that is anaconda related or after anconda has installed
18:12:42 <tflink> kind of anaconda related
18:12:51 <jlaska> Viking-Ice: well, the other bug (generic-release) is affecting post-install sine no fedora-release-rawhide was installed
18:12:54 <pjones> and also:
18:12:54 <pjones> eddie:~$ repoquery --enablerepo=rawhide --disablerepo=fedora,fedora-updates --requires fedora-release-rawhide
18:12:55 <pjones> fedora-release = 16-0.1
18:12:58 <tflink> anaconda just gives the option to restart instead of completing when doing a netinstall
18:13:10 <Viking-Ice> ah netinstall again
18:13:10 <jlaska> this one I believe is just anaconda
18:13:12 <pjones> so if you don't have fedora-release installed, you won't have rawhide repos enabled.
18:13:17 <jlaska> right
18:13:38 <pjones> hrm.
18:13:58 <jlaska> so I think this one is just a rel-eng issue that we'll want resolved
18:14:13 <jlaska> by rel-eng ... I mean compose-related (pungi,lorax etc...)
18:14:30 <adamw> as i read it this affects both
18:14:42 <jlaska> yeah, what I wasn't sure of ...
18:14:44 <adamw> you can't do a net install as it doesn't have any available repos
18:14:50 <adamw> and also, post install with the dvd, you'd wind up with no repos
18:14:51 <jlaska> was when we branch, whether this problem goes away again until F17/rawhide
18:14:58 <jlaska> adamw: well ...
18:15:02 <jlaska> you wind up with no fedora-release-rawhide
18:15:16 <adamw> jlaska: which contains the rawhide repo definitions.
18:15:30 <jlaska> but we'll be branched at TC1 ... so I wasn't sure if this would no longer apply then
18:15:34 <jlaska> if that makes sense
18:15:45 <adamw> jlaska: if this is caused by the fedora-release vs. generic-release bug, i can't see how branching would change anything
18:15:48 <adamw> though i might be missing something
18:16:02 * pjones wonders if this could somehow be related to betanag
18:16:11 <adamw> i don't know if we had this same problem in previous cycles
18:16:14 <jlaska> there's been quite a bit of change there lately
18:16:27 <jlaska> this is from a late F15 change right before finel
18:16:28 <jlaska> final
18:16:31 <jlaska> to remove the betanag
18:16:33 <jlaska> remember?
18:16:37 <pjones> what causes fedora-release-rawhide to get pulled in normally?
18:16:57 * jlaska isn't sure
18:17:03 <jlaska> no dgilmore lurking?
18:17:04 <Viking-Ice> I'm NTH if this only affects anaconda + network I'm +1 on blocker if this affects post installs
18:17:21 <jlaska> right now, at this moment, it affects post install
18:17:28 <jlaska> whether that'll still be true after we branch, I'm not sure
18:17:49 <Viking-Ice> so revisit the bug after branch ?
18:18:09 <jlaska> that's a possibility
18:18:12 <adamw> might help, i guess.
18:18:23 <adamw> i think we should definitely document the link to the fedora-release vs. generic-release bug
18:18:28 <adamw> and re-test this one after that one gets fixed
18:18:42 <jlaska> agreed ... and our standard matrix of tests should capture both use cases
18:19:11 <jlaska> proposed #agreed 723901 - revisit next meeting - impacts rawhide installs now, but unclear whether this will affect Branched (f16) media installs too
18:19:14 <jlaska> ack/nak/patch?
18:19:27 <jlaska> #info likely related to generic-release vs fedora-release troubles
18:19:43 <tflink> the only question I have is whether this would be worth dealing with now so that we don't hit it again for F17
18:19:51 <jlaska> agreed
18:19:57 <adamw> ack
18:19:57 <Viking-Ice> agreed
18:19:59 <jlaska> I guess nothing stopping us from resolving it now
18:20:05 <adamw> i think we'd better just get a clearer idea of what's going on first
18:20:19 <tflink> I'm not sure that its a blocker as is but if we hit this every release, it needs to be fixed at some point
18:20:23 <jlaska> and by "us", I mean the smarter minds of #anaconda
18:20:32 <jlaska> any other ack/naks?
18:20:56 <jlaska> once, twice ...
18:20:58 <tflink> I mean, I'm not sure its a blocker if it gets fixed at branch
18:21:06 <tflink> ack
18:21:12 <jlaska> #agreed 723901 - revisit next meeting - impacts rawhide installs now, but unclear whether this will affect Branched (f16) media installs too
18:21:17 <jlaska> thx!
18:21:23 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=690930
18:21:25 <buggbot> Bug 690930: unspecified, unspecified, ---, anton, ASSIGNED, microcode_ctl loops, impossible to boot
18:21:32 <Viking-Ice> ack on blocker
18:21:34 <jlaska> #info microcode_ctl loops, impossible to boot
18:21:56 <jlaska> Viking-Ice: which criteria is impacted?
18:22:13 <Viking-Ice> that would be failing to boot right
18:22:22 <adamw> what's happened here is a bug we previously accepted as a blocker has been re-opened but the problem isn't actually the same...
18:22:38 <Viking-Ice> then this one should be closed and a new one filed
18:22:39 <adamw> but i see some discussion in the bug that the maintainer then reverted the fix, which means the initial problem *did* then come back
18:22:41 <adamw> clear as mud!
18:22:49 <jlaska> heh
18:22:50 <Viking-Ice> oh I see
18:23:57 <pjones> http://yum.baseurl.org/wiki/CompareProviders <-- jlaska might want to add this to info for the previous bug
18:24:51 <pjones> so #4 and #5 probably do look interesting to the fedora-release case
18:25:00 * adamw goes to look at changelogs
18:25:00 <adamw> it seems like right now we have a choice between amd systems failing to boot, and intel systems not getting microcode updates
18:25:00 <adamw> until someone hits on the right magic formula to allow intel systems to get microcode updates and amd systems to be left alone
18:25:28 <pjones> the latter is definitely preferred over the former.
18:25:34 <adamw> Sonar_Guy: when this bug was filed, we were in the 'amd systems fail to boot' state
18:25:38 <adamw> erf
18:25:43 <adamw> that was just meant to be so:
18:25:44 <adamw> hehe
18:25:57 <adamw> then a 'fix' got committed which resulted in the 'everything boots, but intel doesn't get microcode updates' state
18:26:04 <brunowolff> Not just AMD, also old Intel.
18:26:12 <adamw> then yesterday, microcode_ctl-1.17-16.fc16 reverted that fix, so we're back to 'amd systems fail to boot'
18:26:12 <adamw> right
18:26:18 <Viking-Ice> anyway in either case amd or intel if the computer fails to boot I believe it's an blocker
18:26:39 <adamw> so yeah, with the current package, we're definitely back in blocker statet
18:26:48 <jlaska> amd not booting would seem to be of a higher impact than no microcode updates
18:26:52 <jlaska> </naive>
18:27:06 <adamw> and if no-one manages to fix it properly we should re-apply the broken fix, or do something else to squelch microcode_ctl until it can be made to work properly
18:27:09 <adamw> jlaska: yes, it is.
18:27:38 <adamw> so...long story short...+1 blocker
18:27:45 <Viking-Ice> +1 blocker
18:27:48 <tflink> +1 blocker
18:27:50 <jlaska> because of the number of systems affected, and it prevents boot, right?
18:28:07 <jlaska> +1 blocker to that
18:28:10 <adamw> yes.
18:29:00 <jlaska> #agreed 690930 - AcceptedBlocker - bootable AMD systems favored over intel microcode update support for Alpha ... if no fix available, re-apply broken fix to allow AMD systems to boot
18:30:11 <jlaska> okay, that's it for the proposed blockers
18:30:20 <jlaska> we have 1 proposed NTH, and 2 AcceptedBlockers
18:30:38 <jlaska> let's check-in on the acceptedblocker briefly
18:30:43 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=720034
18:30:44 <buggbot> Bug 720034: medium, medium, ---, schwab, NEW, Error: unsupported locale setting
18:31:35 <Viking-Ice> are those still not a blocker ?
18:31:41 <Viking-Ice> as in are these issues fixed?
18:31:49 <jlaska> we're on acceptedBlocker's now ... just checking in on status
18:31:53 <adamw> i don't see any changes since last week
18:32:02 <Viking-Ice> neither did I
18:32:12 <jlaska> well, firstboot started fine for me ... after I did 'systemctl enable firstboot-graphical.service'
18:32:18 <adamw> andreas has been marking duplicates but hasn't tried to fix anything...
18:32:22 <jlaska> maybe with some more testing we'll find this magically got fixed?
18:32:43 <tflink> either way, needs more testing and/or poking
18:32:49 <jlaska> any suggestions?
18:32:55 <jlaska> leave as is, and we'll visit again next week?
18:33:07 <adamw> if anyone wants to volunteer to look into it that'd be good i guess
18:33:10 <jlaska> note ... next meeting is our last meeting before Alpha RC1
18:33:20 <tflink> yep, request update and wait until next week
18:33:30 <tflink> I can ask for update. I'll be going though these bugs anyways
18:33:37 <jlaska> tflink: thanks, that's a good idea
18:33:56 <jlaska> #agreed 720034 - request updated status in bug and revisit/retest before next meeting
18:34:07 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=714478
18:34:08 <Viking-Ice> jlaska, firstboot is spec bug %post probably has if [ $1 -eq 0 ] instead of  [ $1 -eq 1 ]
18:34:08 <buggbot> Bug 714478: unspecified, unspecified, ---, kernel-maint, MODIFIED, CPU lockup during boot
18:34:42 <brunowolff> This one should be closable.
18:34:49 <brunowolff> I tested it last night.
18:34:57 <jlaska> Viking-Ice: if you are able to work up an updated firstboot with that fix, I'll include that in a repo and test
18:35:03 <jlaska> #info CPU lockup during boot
18:35:04 <adamw> brunowolff: did you check the kernel currently in rawhide works?
18:35:21 <jlaska> Update from brunowolff in the bz states ... "kernel-3.0-0.rc7.git10.1.fc16 is in rawhide this morning. I think this can
18:35:24 <jlaska> probably be closed now."
18:35:27 <brunowolff> I grabbed it from koji before the rawhide repo was ready.
18:36:02 <adamw> okay
18:36:08 <adamw> sounds good to close then
18:37:04 <jlaska> #agreed 714478 - brunowolff confirmed this issue is resolved in latest rawhide kernel, move to CLOSED
18:37:17 <jlaska> okay ... 1 Proposed NTH for Alpha
18:37:18 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723160
18:37:19 <buggbot> Bug 723160: unspecified, unspecified, ---, otaylor, NEW, Gnome-shell presents enormous warning dialog
18:37:23 <jlaska> #info Gnome-shell presents enormous warning dialog
18:37:39 <jlaska> I had a chance to test this in a KVM guest today ... and I'm not seeing the reported error that Kamil saw
18:37:42 <adamw> this looked like a fun bug
18:37:52 <adamw> haven't seen it on my native rawhide system either
18:37:53 <jlaska> I'm not sure if this magically fixed, or if my environment was different enough
18:38:05 <adamw> it would help to know exactly how kamil's kvm is configured
18:38:06 <Viking-Ice> and fixed as well anywho I dont think this one is an NTH even
18:38:27 <tflink> depends on how common it is, I think
18:38:52 <adamw> well, kparal's experience was pretty crappy
18:38:58 <adamw> if that was happening in all vms i'd be a bit worried
18:39:01 <adamw> but it doesn't see mto be the case
18:39:03 <jlaska> yeah, I think his experience would impact basically any desktop usage
18:39:09 <jlaska> so more testing?
18:39:19 <tflink> sounds like a plan to me
18:39:28 <adamw> yeah, if others aren't hitting this with straightforward install-into-vm we should ask kamil for more testing and details
18:39:33 <tflink> more testing to determine the number of impacted systems
18:39:42 <adamw> oh, he was just booting, not installing, seems
18:40:06 <tflink> yeah, livecd
18:40:25 <jlaska> #info Unclear on impact, could be bad if impacts desktop in all VMs
18:41:51 <Viking-Ice> I got one to propose as an blocker 724928 allthou I'm not sure how relevant it is since upstream has fix
18:42:02 <jlaska> okay, one sec ...
18:42:16 <jlaska> #agreed More testing of live images needed to determine scope of failure
18:42:32 <jlaska> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=724928
18:42:33 <buggbot> Bug 724928: unspecified, unspecified, ---, lpoetter, POST, Reboot ends with kernel panic on systemd abort()
18:42:42 <jlaska> Viking-Ice: thanks for raising this ... I just saw this too
18:43:20 <jlaska> I think this definitely hits the beta criteria - "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work "
18:43:41 <jlaska> esp since we recently adjusted that criteria to actually mean that the reboot/shutdown must work too
18:44:06 <jlaska> +1 for Beta
18:44:09 <Viking-Ice> hum I actually think we should move that beta criteria to an alpha one
18:44:49 <Viking-Ice> as in the shutdown reboot part
18:44:56 <adamw> yeah, it might be an idea to split them up
18:45:19 <adamw> for alpha, it should be possible to shut the system down cleanly; for beta, triggering from the desktop should work
18:45:20 <jlaska> so move shutdown/reboot to alpha criteria?
18:45:33 <adamw> if someone wants to work up a draft for that it'd be great
18:45:34 <jlaska> yeah, that makes sense to me
18:45:41 <jlaska> I'll include this in my other proposal
18:45:46 <Viking-Ice> great
18:45:53 <jlaska> unless Viking-Ice wants it :)
18:46:13 <Viking-Ice> no I got my hands full with sysvtosystemd feature
18:46:20 <Viking-Ice> and I mean hands full
18:46:24 <jlaska> #action jlaska - draft Alpha criteria to ensure that reboot/shutdown work as intended (desktop reboot/shutdown already covered in Beta)
18:46:30 <jlaska> what the heck, I've got nothing else going on ;)
18:46:48 <jlaska> okay, so should we tentatively agree to take this for Alpha then?
18:47:01 <adamw> sure
18:47:27 <jlaska> proposed #agreed 724928 - AcceptedBlocker for F16Alpha - tentatively accepted for pending alpha criteria for proper shutdown/reboot behavior
18:47:30 <jlaska> ack/nak/patch?
18:47:36 <Viking-Ice> ack
18:47:45 <tflink> ack
18:47:52 <adamw> ack
18:47:59 <jlaska> #agreed 724928 - AcceptedBlocker for F16Alpha - tentatively accepted for pending alpha criteria for proper shutdown/reboot behavior
18:48:08 <jlaska> #topic Open discussion - <your bug here>
18:48:53 <Viking-Ice> I got to run so later.
18:49:02 <jlaska> thanks Viking-Ice!
18:49:13 <jlaska> okay ... if no other topics, let's conclude this before we hit the 2 hour mark
18:49:20 <tflink> sounds good to me
18:49:25 * jlaska lights 1 minute fuse for #endmeeting
18:49:30 <tflink> 10 minutes before cloud sig mtng
18:50:18 <jlaska> 20-ish seconds until endmeeting
18:50:44 <jlaska> alright gang ... as always thanks for your time, input and analysis on the bugs
18:51:02 <jlaska> I'll send minutes to the list
18:51:05 <jlaska> #endmeeting