f16-blocker-review
LOGS
17:00:56 <jlaska> #startmeeting F16-blocker-review
17:00:56 <zodbot> Meeting started Fri Aug  5 17:00:56 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:01 <jlaska> #meetingname F16-blocker-review
17:01:01 <zodbot> The meeting name has been set to 'f16-blocker-review'
17:01:11 <jlaska> #topic Roll Call
17:01:21 * nirik is lurking around.
17:01:28 <rbergeron> WOOOOOOOOOOOOOO
17:01:32 <adamw> yo.
17:01:35 <jlaska> lurkers, identify yourselves
17:01:37 * athmane is here, but dealing with $dayjob stuff
17:01:46 * rbergeron identifies herself
17:01:56 <jlaska> athmane: understood, thanks for joining
17:02:16 <clumens> my voice is my passport.  verify me.
17:02:26 <jlaska> nerd!
17:03:21 <jlaska> alright ... anyone else ... dgilmore robatino Viking-Ice tflink bruno?
17:03:38 * tflink is here
17:03:48 * robatino here, but can't really contribute (i don't have a F16 VM yet)
17:03:52 <adamw> clumens...verification...failed....death...to...impostor
17:03:56 <jlaska> robatino: okay
17:04:09 <clumens> oh no, guys with shotguns!
17:04:10 <jlaska> okay, let's get this party started
17:04:22 <jlaska> #topic Links
17:04:30 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:04:34 <jlaska> #link https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria
17:04:39 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:04:51 <jlaska> I'll start with proposed blockers ...
17:04:53 <Viking-Ice> I'm here
17:04:59 <jlaska> Hey Viking
17:05:03 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727501
17:05:04 <buggbot> Bug 727501: unspecified, unspecified, ---, dcbw, ASSIGNED, [regression] Changes to ifcfg files are not handled properly
17:05:12 <jlaska> #info [regression] Changes to ifcfg files are not handled properly
17:05:21 <adamw> this is a dependency of the 'can't start network during install' blocker, right?
17:05:42 <jlaska> I believe so, one of several issues that came out of that root cause
17:05:45 <dgilmore> jlaska: hola,
17:06:03 <jlaska> hey dgilmore!
17:06:43 <jlaska> I don't have a ton of details on how this fails, but what tflink highlights is one possible failure scenario
17:06:53 <adamw> it seems like there's a fix but we need an NM build with the fix
17:06:56 <jlaska> right
17:06:57 <adamw> i tried requesting one, but no movement yet
17:07:00 <jlaska> okay
17:07:15 <jlaska> The criteria referenced is the Alpha bug filing criteria ... "The installer must be able to report failures to Bugzilla, with appropriate
17:07:18 <jlaska> information included
17:07:18 <adamw> on the blockeriness - if we need this to be fixed before anaconda can do networking, obviously +1
17:07:20 <jlaska> "
17:07:41 <jlaska> btw ... anyone feeling anxious to volunteer to update the bugs as we go?
17:07:50 <tflink> I can
17:07:58 <Viking-Ice> I'm a -1 to this one actually and people should just save straces and what not to a usb stick in the installer
17:08:12 <Viking-Ice> it's an NTH from my pov
17:08:19 <jlaska> Viking-Ice: that's an option, but it's not what we decided on with the criteria
17:08:24 <jlaska> so it would require criteria adjustment
17:08:45 <jlaska> proposed #agreed 727501 - AcceptedBlocker for Alpha - impacts networking during installation, notably auto-filing problems to bugzilla
17:08:46 <tflink> the strange thing is that I haven't managed to hit this on either of the two TC1 installs I've done today
17:08:51 <jlaska> ack/nak/patch
17:08:56 <Viking-Ice> nak
17:09:07 <jlaska> tflink: from what I understand from Radek (installer side), it's also timing related
17:09:23 <tflink> ah, I must have gotten lucky then
17:09:49 <jlaska> Viking-Ice: so by naking, you also need to propose a criteria adjustment :)
17:10:11 <jlaska> I'm kidding, you don't ... but we'd need to resolve that inconsistency
17:10:12 <Viking-Ice> ok nak with criteria adjustment drop it or move this to beta
17:10:13 <tflink> I'm still confused by all of these NM bugs - can it be worked around by switching virtual terminals and bringing up the interface manually?
17:10:25 <jlaska> tflink: sort of
17:10:43 <jlaska> the only reliable workaround is booting with 'asknetwork' and enabling it during loader
17:10:46 <jlaska> iirc
17:11:15 <jlaska> I had difficulty getting it to work when manually enabling network ... last I tried
17:11:30 <jlaska> which is odd, usually you just 'dhclient eth0' and it's good to go
17:11:49 <jlaska> Viking-Ice: so you're rationale for nak'ing is that users should be saving tracebacks to USB keys instead?
17:12:02 <Viking-Ice> well personally I dont see why the purpose of this being a release criteria et all it's not like we update anaconda once we go GA..
17:12:05 <dgilmore> jlaska: likely some caching
17:12:12 <clumens> i consider save-via-network to be the primary mechanism
17:12:17 <jlaska> Viking-Ice: ^^
17:12:32 <Viking-Ice> well atleast it should not be an alpha criteria
17:12:33 <jlaska> dgilmore: yeah, could be
17:12:46 <adamw> Viking-Ice: the reasoning is that the point of alpha / beta is to do testing, i.e., to find what's broken. a big part of that is anaconda. and the main method for getting useful anaconda bug reports is anaconda's inbuilt debugging...
17:13:14 <Viking-Ice> cant anaconda offer to save to usb stick if there is no network present or will it just bork and reboot
17:13:32 <adamw> even if it can, that adds an extra step of complexity for people to actually file a report
17:13:34 <jlaska> Viking-Ice: you can use other methods for saving the traceback ... but the preference from the developers is networking
17:13:48 <jlaska> and from users ... it's just soooo much easier to debug when just going right into bz
17:14:15 <jlaska> ack/nak/patch?
17:14:21 <jlaska> I've got 1-nak, and nothing else
17:14:24 <tflink> another way of looking at it is that it does hinder the execution of test plans
17:14:33 <tflink> doesn't prevent but is a pain
17:14:38 <Viking-Ice> how so
17:14:44 <Viking-Ice> we did in the past an we are still here
17:14:48 <tflink> adding an extra step
17:14:49 <clumens> ack from me
17:14:50 <jlaska> Viking-Ice: no, we didn't
17:14:52 <adamw> jlaska: i'm already +1.
17:15:03 <jlaska> Viking-Ice: this criteria hasn't changed for several releases now
17:15:06 <adamw> did/didn't what?
17:15:13 <Viking-Ice> save to a usb stick
17:15:17 <Viking-Ice> manage without network
17:15:22 <jlaska> right, we're not saying that's not supported
17:15:35 <Viking-Ice> but we are depending the release on it
17:15:36 <jlaska> just that the preferred mechanism for all releases is saving tracebacks directly to bugzilla
17:15:52 <jlaska> yes, it's important that the installer support filing bugs directly to bugzilla
17:15:57 <tflink> ack
17:16:05 <Viking-Ice> dont get me wrong I understand the merrit of this I just dont agree with this being a release criteria
17:16:21 <jlaska> Viking-Ice: let's take it to the list
17:17:14 <jlaska> #info some debate as to the need for alpha criteria for anaconda saving tracebacks to bugzilla
17:17:20 <dgilmore> there is always cases where reporting directly to bugzilla is not possible
17:17:33 <jlaska> #agreed 727501 - AcceptedBlocker for Alpha - impacts networking during installation, notably auto-filing problems to bugzilla
17:17:56 <adamw> we could also cite "The installer must be able to use at least one of the HTTP or FTP remote package source options ".
17:17:58 <dgilmore> ipv6 only network, on  anetwork that doesnt allow access to the internet for a couple
17:18:00 <adamw> which implies 'working networking'.
17:18:08 <jlaska> yeah
17:18:21 * jlaska ready move on ... this is our *first* bug
17:18:24 <adamw> +1
17:18:32 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723475
17:18:33 <buggbot> Bug 723475: unspecified, unspecified, ---, rvykydal, NEW, anaconda-16.12 - Unable to activate networking in anaconda (stage2)
17:18:43 <jlaska> #info anaconda-16.12 - Unable to activate networking in anaconda (stage2)
17:18:46 <clumens> i'm unsure on whether this bug has any useful data in it anymore
17:19:00 <clumens> or if it's just linking to other bugs now
17:19:05 <jlaska> me neither ... I know Radek mentioned he wanted to track the NM change
17:19:06 <tflink> me neither - it seems to be just a tracker now
17:19:11 <jlaska> but I don't know if any anaconda changes are needed at all with this issue
17:19:41 <jlaska> shall we agree to demote this issue, in favor of tracking the previously accepted issue?
17:19:45 <adamw> i think having both kinda keeps the situation clear...
17:19:50 <adamw> but i don't really minsd.
17:19:58 <clumens> it doesn't really matter to me
17:20:07 <jlaska> clumens: would anaconda need a rebuild after NM is updated?
17:20:18 <jlaska> or just a fresh compose?
17:20:22 <clumens> jlaska: the images would need to be rebuilt, but not anaconda itself
17:20:25 <jlaska> gotcha
17:20:41 <jlaska> Any recommendations?
17:20:56 <adamw> so if we pull in an NM build with the fix and spin tc2/rc1 it should work?
17:21:05 * jlaska nods
17:21:13 <tflink> getting rid of it might make the list a little cleaner
17:21:18 <adamw> i guess just having the NM bug is fine then.
17:21:59 <jlaska> proposed #agreed 723475 - RejectedBlocker for Alpha - issue will be resolved with updated NM package, and new install images
17:22:03 <jlaska> ack/nak/patch?
17:22:13 <clumens> ack
17:22:50 <adamw> well, ack, but more we could just close it as a dupe than rejectedblocker.
17:22:59 <jlaska> that patch works for me
17:23:52 <jlaska> anyone else?
17:24:10 <jlaska> sold!
17:24:13 <rbergeron> lol
17:24:33 <jlaska> #agreed 723475 - CLOSED DUPLICATE of 727501
17:24:35 <dgilmore> jlaska: works for me
17:24:42 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727401
17:24:44 <buggbot> Bug 727401: unspecified, unspecified, ---, notting, ON_QA, repoclosure failure in 16-Alpha.TC1 DVDs
17:24:49 <jlaska> #info repoclosure failure in 16-Alpha.TC1 DVDs
17:25:09 <jlaska> this was tracking several deps problems, some of which were filed as different bugs
17:25:26 <jlaska> is this just a tracker now, or are there issues still be followed
17:26:06 <jlaska> The alpha criteria for this issue is pretty standard
17:26:07 <jlaska> "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install "
17:26:21 <jlaska> An updated vinagre package is available, thanks to a friendly provenpackager
17:26:25 <adamw> i don't think there's any sub-bugs.
17:26:31 <jlaska> okay
17:26:35 <Viking-Ice> do these need karma ?
17:26:39 <adamw> but there are separate updates for all of the packages mentioned in the bug, that i listed.
17:26:43 <adamw> Viking-Ice: some of them, yep
17:27:02 <jlaska> proposed #agreed 727401 - AcceptedBlocker - impacts repoclosure criteria for Alpha install media
17:27:05 <jlaska> ack/nak/patch
17:27:06 <dgilmore> +1
17:27:08 <Viking-Ice> ack
17:27:23 <rbergeron> ack
17:27:24 <adamw> ack
17:27:26 <jlaska> #info Karma needed - https://admin.fedoraproject.org/updates/vinagre-3.1.4-2.fc16
17:27:30 <tflink> of course my internet connection starts acting up when I need it - it had been good all day
17:27:35 <jlaska> #agreed 727401 - AcceptedBlocker - impacts repoclosure criteria for Alpha install media
17:27:41 <jlaska> tflink: ssshh, don't anger the interwebz
17:27:54 * tflink will go through and update bugs I miss(ed) later
17:28:11 <jlaska> #info Karma needed - https://admin.fedoraproject.org/updates/virt-viewer-0.4.0-2.fc16
17:29:47 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727428
17:29:48 <buggbot> Bug 727428: unspecified, unspecified, ---, dennis, NEW, Unable to read group information from repositories
17:29:56 <jlaska> #info Unable to read group information from repositories
17:30:36 <Viking-Ice> so is this still relevant ?
17:30:46 <jlaska> dgilmore: I think this is the bug that was hitting the invalid MirrorManager repo=fedora-16
17:30:51 <jlaska> which I think has since been resolved
17:31:05 <dgilmore> jlaska: its been resolved
17:31:05 <adamw> right, this looks like it's to do with mirrormanager needing an update.
17:31:10 <jlaska> Viking-Ice: I believe this is now fixed ... I *think*
17:31:15 <adamw> okay, so we can close it?
17:31:21 <jlaska> dgilmore: did we also add repo=fedora-16-Alpha.TC1 ?
17:31:25 <dgilmore> jlaska: it is ive confirmed its fixe
17:31:30 <dgilmore> jlaska: did not
17:31:30 <rbergeron> close it, baby! ;)
17:31:32 <rbergeron> oh
17:31:34 <jlaska> close it!
17:31:56 <jlaska> dgilmore: Are there any /.buildstamp version= considerations for TC2/RC1 ?
17:32:06 <jlaska> if so ... I guess we'd just open this back up (or a new bz)
17:32:12 <jlaska> no sense in discussing possible future bugs here
17:33:09 <jlaska> proposed #agreed 727428 - CLOSED CURRENTRELEASE - MirrorManager configuration updated, this issue no longer occurs
17:33:13 <adamw> ack
17:33:13 <jlaska> ack/nak/patch?
17:33:30 <Viking-Ice> ack
17:33:33 <tflink> ack
17:33:40 <jlaska> #agreed 727428 - CLOSED CURRENTRELEASE - MirrorManager configuration updated, this issue no longer occurs
17:33:52 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=728325
17:33:53 <buggbot> Bug 728325: unspecified, unspecified, ---, tcallawa, MODIFIED, Installer artwork shows F15 logo
17:33:55 <dgilmore> ack
17:34:05 <jlaska> #info Installer artwork shows F15 logo
17:34:17 <dgilmore> so this has been the case for the last few releases
17:34:21 <jlaska> dgilmore: sorry, as soon as I see 3 ... I move on
17:34:33 <dgilmore> its not been a blokcer previously
17:34:37 <dgilmore> jlaska: thats fine :)
17:34:38 <jlaska> well, it has been
17:34:38 <clumens> yes, it would be nice to solve this one and for all
17:34:38 <adamw> time and jlaska wait for no man
17:34:42 <jlaska> but ... we missed it last release
17:34:46 <jlaska> I missed it really
17:35:02 <jlaska> I didn't carry the criteria fwd into the F15 Alpha criteria pages ... it was something I listed on the retrospective
17:35:05 <Viking-Ice> hum which release criteria do the logo hit
17:35:07 <dgilmore> jlaska: i know f14 alpha shipped with f13 artwork, and pretty sure f15 alpha had f14
17:35:08 <jlaska> so that's one reason why we missed it
17:35:12 <adamw> if it says '15' in it then ack.
17:35:22 <jlaska> dgilmore: yup, that's why we have the criteria now
17:35:33 <jlaska> adamw: it does, and a fix is already in bodhi
17:35:36 <dgilmore> jlaska: im fine with that
17:35:37 <adamw> okay.
17:35:41 <tflink> I have anaconda from TC1 up right now, it says 15
17:35:43 <jlaska> awaiting oh so precious karma
17:35:46 <dgilmore> was going to suggest that its just nice to have
17:35:58 <Viking-Ice> yum needs karma allthou it fails autoqa
17:35:58 <dgilmore> but if we changed then im +1 to blocker
17:36:38 <jlaska> proposed #agreed 728325 - AcceptedBlocker for Alpha - Impacts Alpha release criteria that installer graphics must reference the release under test (not a previous release number)
17:36:52 <tflink> ack
17:37:09 <jlaska> #info Applicable Alpha criteria - "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 backgro
17:37:15 <Viking-Ice> nack logo glitches should not block the alpha release
17:37:29 <Viking-Ice> what's next wrong font blocks alpha
17:37:40 <jlaska> Viking-Ice: no, there's no criteria around the font
17:37:46 <Viking-Ice> ;)
17:38:09 <tflink> that sounds like another conversation for the lists since it would require modification to the release criteria
17:38:11 <jlaska> but the design team requested this criteria several releases ago after being disappointed we ship releases that include artwork with the *wrong* version
17:38:13 <Viking-Ice> but we should clean up our act it's a minor fix and should be done at branching
17:38:28 <Viking-Ice> cant the logo for F17 be fixed now ?
17:38:29 <jlaska> Viking-Ice: it is being done at branching
17:38:37 <adamw> Viking-Ice: the issue is that people tend to get confused if there's a reference to an actually wrong version number in the artwork
17:38:41 <jlaska> Viking-Ice: talk to spot ... I believe he's instrumented a more sustainable fix
17:38:45 <jlaska> tflink: agreed
17:38:51 <adamw> Viking-Ice: for alpha the artwork doesn't have to be absolutely right, it just has to not refer explicitly to an incorrect version number
17:39:04 <jlaska> better phrased, thanks
17:39:57 <jlaska> my box score ... 2 acks, 1 nak
17:40:19 <Viking-Ice> well this should be fixed elsewhere then in the release criteria for alpha yup an 2 tromps one
17:40:40 <jlaska> last call ..
17:41:21 <jlaska> Viking-Ice: if you want to discuss the criteria, please do bring it up on the list ... I just don't want to prolong the meeting longer than necessary discussing all the criteria
17:41:35 <adamw> it is a kinda borderline criterion.
17:41:38 <rbergeron> can't it just be nth?
17:41:48 <adamw> i think there's history of its implementation on the list, though, so worth going back over that when re-evaluating it.
17:41:49 <jlaska> it can ... we just remove the criteria
17:41:59 <rbergeron> for now anyway?
17:42:02 <adamw> anyway, we have a fix, so let's move on for now
17:42:07 <rbergeron> oh
17:42:09 <rbergeron> fixes are good
17:42:22 <jlaska> rbergeron: this is the bug I mentioned in the mail to you earlier today
17:42:26 <jlaska> with spot's fix
17:42:50 <jlaska> #agreed 728325 - AcceptedBlocker for Alpha - Fix available in bodhi that corrects the display of incorrect Fedora version number during install
17:43:02 <jlaska> next one should be easy ...
17:43:05 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=726977
17:43:06 <buggbot> Bug 726977: unspecified, unspecified, ---, dennis, ON_QA, fedora-release-16-0.7 not updated for Branched
17:43:08 <jlaska> #info fedora-release-16-0.7 not updated for Branched
17:43:10 <rbergeron> oh! indeed it is
17:43:11 <jlaska> Easy in that it's fixed
17:43:37 <jlaska> proposed #agreed 726977 - CLOSED CURRENTRELEASE - Fixed by fedora-release-16-0.9
17:44:02 <jlaska> If any new issues come out of the discussion dgilmore and adamw were having regarding keys, should those be handled as new bugs?
17:44:06 <jlaska> ack/nak/patch?
17:44:10 <Viking-Ice> ack
17:44:13 <tflink> ack
17:44:13 <adamw> ack
17:44:18 <rbergeron> ack.
17:44:31 <adamw> i actually updated fedora-release to 0.9 and it pulled in a new key, so that might have been the cause of my problem
17:44:35 <adamw> when i hit that i was on 0.8
17:44:48 <jlaska> oh I see
17:44:55 <jlaska> #agreed 726977 - CLOSED CURRENTRELEASE - Fixed by fedora-release-16-0.9
17:45:01 * jlaska checks the karma situation for that update
17:45:14 <jlaska> looks good
17:45:25 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723160
17:45:26 <buggbot> Bug 723160: unspecified, unspecified, ---, rstrode, NEW, Gnome-shell presents enormous warning dialog
17:45:32 <jlaska> #info Gnome-shell presents enormous warning dialog
17:45:39 <jlaska> Any updates on this issue since last week?
17:45:40 * jlaska reading
17:46:01 <tflink> not really, it sounds like kamil is still the only one hitting this for now
17:46:07 <Viking-Ice> hum which criteria does this fall under?
17:46:13 <jlaska> I haven't seen this with virt or bare metal
17:46:25 <tflink> but as adam mentioned in the bug, we don't have tc1 live images and it might be best to wait on this
17:46:33 <jlaska> Viking-Ice: I'm not sure ... I think the issue in question for this was that it was crashing X for kparal
17:46:43 <adamw> Viking-Ice: we kinda wanted to get more reproducers before getting into detail with that, but as described by kamil, it would make live pretty unusable on non-shell-capable hardware
17:47:00 <adamw> i think the best course is as i said in the bug - punt till we have tc1/rc1 lives to test
17:47:03 <dgilmore> adamw: 0.8 should never have existed
17:47:08 <Viking-Ice> adamw, yup we need more info
17:47:13 <Viking-Ice> and a working test images
17:47:28 <jlaska> proposed #agreed 723160 - No action required - Wait for updated test results against live images, if no new updates at next meeting, will reject
17:47:32 <jlaska> ack/nak/patch?
17:47:34 <adamw> ack
17:47:35 <Viking-Ice> ack
17:47:37 <tflink> ack
17:47:38 <rbergeron> ack
17:47:44 <jlaska> #agreed 723160 - No action required - Wait for updated test results against live images, if no new updates at next meeting, will reject
17:47:57 <jlaska> should we talk about the state of live images, or leave that for open discussion?
17:48:03 <adamw> later
17:48:04 <jlaska> (or just not talk about it ) :)
17:48:09 <jlaska> adamw: roger
17:48:16 <rbergeron> lol
17:48:20 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=725185
17:48:22 <buggbot> Bug 725185: medium, unspecified, ---, pjones, NEW, grubby doesn't add the initrd line at the kernel update
17:48:27 <jlaska> #info grubby doesn't add the initrd line at the kernel update
17:48:30 <jlaska> This should be easy too
17:48:35 <jlaska> I'll close it since it's fixed for me
17:48:50 <jlaska> I believe it should be in MODIFIED, since it was fixed prior to TC1
17:49:13 <jlaska> wait wait ... ignore the previous 3 comments
17:49:21 * jlaska thinking of a completely different grub2 bz
17:49:25 <jlaska> apologies
17:49:33 <Viking-Ice> dont think this actually was an alpha criteria either unless the system cant boot after install ( not an update )
17:50:40 <Viking-Ice> wondering if this is kernel related adamw did you test this with i686 kernels ( pae or not )
17:50:41 <jlaska> Viking-Ice: yeah, I *think* that was the concern
17:50:53 <adamw> ahh, interesting
17:50:58 <adamw> no, i'm x86-6
17:50:59 <adamw> 4
17:51:08 <jlaska> Viking-Ice: that is funny
17:51:20 <jlaska> the reporter has both PAE x86_64 kernels in their grub config
17:51:26 <tflink> I can try with i686 later today - waiting for TC1 to finish install
17:51:34 <Viking-Ice> Installing : kernel-PAE-3.0.1-1.fc16.i686   1/1
17:51:35 <Viking-Ice> grubby fatal error: unable to find a suitable template
17:51:48 <dgilmore> tflink: tc1 doesnt have a PAE kernel in the installer
17:52:03 <jlaska> dgilmore: it looks like this might be post-install yum'ing?
17:52:13 <adamw> oh, see the 'news flash' at the bottom
17:52:38 <Viking-Ice> anyway I dont think this hits the alpha criteria
17:52:43 <tflink> dgilmore: good to know. I can manually install PAE and try with non-PAE
17:52:50 <adamw> Viking-Ice: yeah, it's a bit borderline
17:52:53 <jlaska> not with the information we have right now
17:52:54 <Viking-Ice> from a looks of it it happens on update
17:52:57 <adamw> i wanted to be clear on the exact impact though
17:53:02 <jlaska> proposals?
17:53:07 <Viking-Ice> nack
17:53:17 <Viking-Ice> simple
17:53:36 <Viking-Ice> users systems are still bootable with the installed kernel
17:53:43 <adamw> i'm probably nack to blocker too...
17:53:54 <adamw> especially since it doesn't seem to be happening to everyone and needs *some* kind of circumstance to trigger
17:53:59 <dgilmore> jlaska: i think there is not enough data here
17:54:03 <tflink> I think it depends on which systems are affected. if its just PAE, -1 blocker
17:54:32 <clumens> someone should ask pjones about it specifically.  he doesn't always watch the bug list so closely.
17:54:44 <jlaska> clumens: would you mind pinging him?
17:55:01 <adamw> i think the grub2 thing is it
17:55:06 <clumens> sure
17:55:07 <adamw> i just confirmed that on my machine
17:55:12 <jlaska> which would be bad, no ... since grub2 is the default now
17:55:13 <jlaska> ?
17:55:13 <adamw> see the comment i just added to the bug
17:55:17 * jlaska reloads
17:55:18 <adamw> is it? i didn't think it was
17:55:22 <jlaska> it is
17:55:31 <jlaska> but if you yum upgraded from f15, it's not an issue
17:55:33 <jlaska> (or not the default)
17:55:56 <tflink> I got grub 2 on a minimal install of F16 this morning
17:55:59 <adamw> oh ok
17:56:04 <adamw> so it is a problem...
17:56:13 <dgilmore> if you upgade from f15 grub legacy should be used and updated correctly
17:56:18 <dgilmore> new installs get grub2
17:56:22 <adamw> ah yeah, comps-f16.xml has grub2
17:56:24 <jlaska> yeah, what dgilmore said
17:56:35 <jlaska> so the question is how common is this persons use case?
17:56:52 <Viking-Ice> did corben ( lwn writher ) mention similar issue on the test list early rawhide ?
17:56:54 <tflink> wouldn't this happen on all new F16 installs, then?
17:56:56 <jlaska> this will affect yum upgraders who attempt to transition to grub2 ?
17:56:57 <adamw> jlaska: er, as i understand it now, it'll affect all f16 installs
17:57:00 <dgilmore> jlaska: i guess its a matter of does a yum update get you grub2 installed
17:57:11 <dgilmore> i suspect that should e a  no
17:57:16 <dgilmore> be a no
17:57:20 <adamw> but not upgrades, unless we set up upgrades to switch from grub to grub2, which i don't believe we currently do.
17:57:22 <jlaska> adamw: I've had successful installs (all with grub2)
17:57:30 <adamw> jlaska: huh. maybe it's only if you have *both*?
17:57:37 * nirik had a install that worked fine here yesterday.
17:57:39 <jlaska> I think it's just yum upgrades from F15 -> F16 ... then install grub2, then install a kernel
17:57:41 <adamw> jlaska: oh, wait.
17:57:41 <tflink> jlaska: just install?
17:57:42 <dgilmore> adamw: im suspecting its only both
17:57:48 <adamw> jlaska: the *install* will work.
17:58:16 <dgilmore> adamw: and that the user would have to manullay choose to install grub2
17:58:18 <jlaska> oh, but yum install ofa kernel after ... will fail?
17:58:21 <adamw> sorry, back up a bit...jlaska, have you tried installing a kernel on a clean f16 (grub2) system and it worked?
17:58:29 <jlaska> adamw: I've not ... I can do that shortly
17:58:32 <adamw> if not, can you test that? it's easy
17:58:46 <adamw> "yum localinstall http://kojipkgs.fedoraproject.org/packages/kernel/3.0.1/1.fc16/x86_64/kernel-3.0.1-1.fc16.x86_64.rpm" should do the trick
17:58:47 <Viking-Ice> back to basic does fresh install leave users with working kernel ?
17:58:47 <jlaska> ... testing ...
17:58:55 <adamw> then check if that kernel has an initramfs line in grub.conf
17:58:57 <dgilmore> Viking-Ice: yes
17:59:00 <adamw> Viking-Ice: yes, i think we've established that.
17:59:07 * nirik tries here.
17:59:16 <adamw> Viking-Ice: i think it's worth making sure we know exactly what triggers this bug, though, so we can evaluate it for nth status if nothing else
17:59:29 <Viking-Ice> adamw, aggreed
17:59:31 <adamw> if it only happens if you have both grub and grub2 installed then it's not going to be a big deal
17:59:49 <clumens> 13:59 < pjones> clumens: hrm, looks like it has to do with having both grub and grub2 installed at the same time.
17:59:54 <clumens> 13:59 < pjones> So as soon as I get EFI switched over to grub2, I'm just going to conflict: them.
18:00:07 <dgilmore> ok
18:00:17 <adamw> right. if that's definitely the case, i think we can downgrade this, -1 blocker -1 nth
18:00:27 <dgilmore> yeah
18:00:30 <dgilmore> im with adamw
18:00:36 <Viking-Ice> me too
18:00:39 <jlaska> let's put that query out in the bz
18:00:42 <jlaska> wait for feedback to settle in
18:00:44 <tflink> yeah, same here
18:00:45 <jlaska> and then demote?
18:00:59 <jlaska> (or are we certain that's the cause ... and would like to RejectBlocker now)?
18:01:33 * nirik waits for dracut to finish running.
18:01:48 <adamw> if nirik's test comes out okay, i'm for rejectedblocker now.
18:01:51 <jlaska> package grub is not installed
18:01:51 <jlaska> grub2-1.99-0.2.fc16.x86_64
18:02:01 <jlaska> ^^^ and it has initrd lines for all kernels installed
18:02:03 <tflink> my VM upgrade went OK - have initrd line
18:02:15 <jlaska> # grep initrd /etc/grub2.cfg  initrd /initramfs-3.0.1-1.fc16.x86_64.img initrd	/initramfs-3.0.0-3.fc16.x86_64.img initrd	/initramfs-3.0.0-3.fc16.x86_64.img
18:03:07 <jlaska> proposed #agreed 725185 - RejectedBlocker - caused by having grub and grub2 installed at the same time, unsupported configuration and a future grub2 update with %obsolete grub
18:03:11 <adamw> ack
18:03:14 <jlaska> err %conflict I guess
18:03:24 <tflink> ack
18:03:40 <Viking-Ice> ack
18:03:50 <nirik> yp. ok here too.
18:04:07 <jlaska> note for later discussion ... if grub and grub2 %conflict ... would that introduce a alpha blocking file conflict
18:04:17 <jlaska> #agreed 725185 - RejectedBlocker - caused by having grub and grub2 installed at the same time, unsupported configuration and a future grub2 update with %conflict grub
18:04:29 <jlaska> as long as grub isn't on the ISO media, it'd be okay
18:04:33 <jlaska> NEXT!
18:04:43 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727402
18:04:44 <buggbot> Bug 727402: unspecified, unspecified, ---, than, MODIFIED, fileconflicts failure in 16-Alpha.TC1 DVDs - kate/kdesdk
18:04:48 <jlaska> #info fileconflicts failure in 16-Alpha.TC1 DVDs - kate/kdesdk
18:04:54 <Viking-Ice> I think that one is a clear blocker
18:04:58 <dgilmore> yep
18:05:02 <adamw> yeah, no-brainer, update needs karma and pushing
18:05:16 <jlaska> #info Karma needed - https://admin.fedoraproject.org/updates/kdesdk-4.7.0-1.fc16
18:05:34 <jlaska> #agreed 727402 - AcceptedBlocker for Alpha - impacts ISO media repoclosure
18:05:43 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727514
18:05:44 <buggbot> Bug 727514: urgent, unspecified, ---, jreznik, MODIFIED, Package Verne theming/branding for KDE
18:05:48 <jlaska> #info Package Verne theming/branding for KDE
18:06:36 <Viking-Ice> not a blocker from my pov..
18:06:51 <dgilmore> not a blocker from my pov for alpha
18:07:09 <jlaska> "But the imagery doesn't really refer to Lovelock explicitly, and there are no
18:07:12 <jlaska> version numbers in Fedora artwork (except for some Anaconda images) by design."
18:07:35 <jlaska> so I think this doesn't hit the Alpha artwork criteria given the spirit of the criteria
18:08:16 <jlaska> while this can be updated post-Alpha, seems like having it "right" on the Alpha media kit might make it a fine NTH
18:08:22 <tflink> spirit, yes. I'm planning to propose a patch to that criterion to make it more clear that it only applies to numbers
18:08:37 <adamw> yeah, i think it's fine as an NTH
18:08:44 <jlaska> tflink: ah good, thanks
18:08:48 <adamw> but doesn't really make a blocker
18:08:51 <jlaska> right
18:09:32 <jlaska> proposed #agreed 727514 - RejectedBlocker + AcceptedNTH for Alpha - doesn't impact Alpha artwork criteria, but would be nice to have finalized before RC ISO media
18:09:35 * maxineb gets home and catches a meeting in action :P
18:09:37 <adamw> ack
18:09:39 <Viking-Ice> ack
18:10:47 <dgilmore> ack
18:10:51 <tflink> ack
18:11:03 <jlaska> #agreed 727514 - RejectedBlocker + AcceptedNTH for Alpha - doesn't impact Alpha artwork criteria, but would be nice to have finalized before RC ISO media
18:11:24 <jlaska> #action tflink - proposing updated Alpha artwork criteria to make version requirement more explicit
18:11:26 <tflink> I forget, does F16blocker-kde block F16?
18:11:34 * jlaska doesn't recall
18:11:38 <adamw> tflink: usually, yeah.
18:11:46 <Viking-Ice> dont think so if it does it's because of historic reasons
18:12:01 <adamw> well, what happens is, any bug that goes on a ticket that itself blocks a release blocker ticket, we review
18:12:03 <dgilmore> pretty sure the answer is no
18:12:10 <adamw> dgilmore: pretty sure you're wrong =)
18:12:10 <tflink> OK, I'll have to come back to this one later if it does, then
18:12:25 <dgilmore> adamw: wouldnt be the first or last time
18:12:26 <adamw> so what usually happens is KDE team sets up a blocker and makes it block f16blocker
18:12:36 <adamw> then we see the tickets that go onto the KDE blocker, and review them
18:12:46 <adamw> if we reject them as blockers, then they get taken off the sub-blocker ticket
18:12:59 <jlaska> yeah, my script pulls in all dependencies into the Current_Release_Blockers wiki
18:13:01 <adamw> whew, that's a lot of blocking.
18:13:09 <jlaska> heh
18:13:13 <tflink> yeah, looking at the bug, it does block F16Blocker
18:13:13 <adamw> hope you understood what i'm getting at.
18:13:20 <jlaska> any further action needed here?
18:13:23 <tflink> so it doesn't affect alpha
18:13:25 <dgilmore> adamw: i do
18:13:32 <adamw> tflink: yeah.
18:13:46 <adamw> tflink: they could have sub-blockers for alpha and beta too if they wanted. it all works with the process.
18:14:21 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727583
18:14:22 <buggbot> Bug 727583: unspecified, unspecified, ---, dvlasenk, NEW, fileconflicts failure in 16-Alpha.TC1 DVDs  - report/libreport
18:14:29 <tflink> true, but I think I'll just leave this as is for now :)
18:14:30 <jlaska> #info fileconflicts failure in 16-Alpha.TC1 DVDs  - report/libreport
18:15:10 <dgilmore> we should block and remove the older one
18:15:23 * jlaska catching up on this issue
18:15:40 <dgilmore> im +1 to blocker
18:15:42 <jlaska> looks like adamw and jmoskovc were discussing this earlier today
18:15:49 <adamw> jlaska: basically jiri set libreport to obsolete report and figured all was good, but one way or another, report crept back in
18:15:50 <dgilmore> the correct fix should be total removal of report
18:16:05 <adamw> either because it got a version bump so the obsolete no longer triggered, or because of deps as i outlined in comment 7
18:16:14 <jlaska> adamw: ah, thanks
18:16:18 <adamw> as dgilmore says, correct fix is to get rid of report entirely, if that's what's supposed to be happening
18:16:37 <jlaska> what criteria is this ... the standard ISO media repoclosure?
18:16:43 <dgilmore> jlaska: yeah
18:17:00 <jlaska> proposed #agreed 727583 - AcceptedBlocker for Alpha - impacts Alpha ISO media repoclosure criteria
18:17:04 <jlaska> dgilmore: thx
18:17:06 <jlaska> ack/nak/patch?
18:17:09 <tflink> ack
18:17:16 <Viking-Ice> ack
18:17:20 <dgilmore> libreport-python-2.0.5-2.fc16.i686
18:17:23 <dgilmore> report-gtk-0.23-0.fc16.i686 /usr/lib/python2.7/site-packages/report/io/GTKIO.py /usr/lib/python2.7/site-packages/report/io/GTKIO.pyc /usr/lib/python2.7/site-packages/report/io/GTKIO.pyo
18:17:37 <dgilmore> ack
18:17:48 <jlaska> #agreed 727583 - AcceptedBlocker for Alpha - impacts Alpha ISO media repoclosure criteria
18:18:01 <adamw> ack
18:18:51 <jlaska> adamw: fyi, one of the install bugs on the current matrix should be resolved by this I suspect
18:18:54 <jlaska> 692433
18:19:08 <jlaska> that issue was linked from the installer save to bugzilla test case
18:19:24 <jlaska> tested by athmane and rhe
18:19:56 <jlaska> okay, ready to review the Accepted blockers
18:20:25 <jlaska> we don't need to debate these bugs, just check-in on status and see if anything canbe done to move them forward
18:20:28 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723901
18:20:29 <buggbot> Bug 723901: unspecified, unspecified, ---, mgracik, ON_QA, pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install
18:20:41 <jlaska> #info pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install
18:20:58 <jlaska> #link https://admin.fedoraproject.org/updates/pungi-2.9-1.fc16
18:21:05 <jlaska> Looks like this has the karma it needs now ... so this should be fine
18:21:08 <adamw> right
18:21:12 <Viking-Ice> yup
18:21:18 <adamw> i asked dgilmore if he can push all the pending blocker fixes which have sufficient karma
18:21:24 <adamw> that should let us close them off and clean up the list a bit
18:21:29 <jlaska> yeah, nice
18:21:33 * dgilmore will do that this arvo
18:21:36 <jlaska> this will probably fall to that list too ...
18:21:38 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=723144
18:21:39 <buggbot> Bug 723144: urgent, high, ---, prajnoha, MODIFIED, lvcreate not creating device nodes as needed
18:21:44 <jlaska> #info lvcreate not creating device nodes as needed
18:21:53 <jlaska> #link https://admin.fedoraproject.org/updates/lvm2-2.02.86-5.fc16
18:21:59 <adamw> yup, another one for which an update is pending
18:22:02 <dgilmore> +1 to blocker
18:22:07 <jlaska> I've confirmed the fix, smooge also tested the fix last night as well
18:22:12 <tflink> dgilmore: its already a blocker
18:22:20 * dgilmore fails
18:22:20 <tflink> we're going through the accepted blockers
18:22:25 <jlaska> dgilmore: we're just reviewing previously ACCEPTED blockers to see what else is needed
18:22:28 * dgilmore hides in his hole
18:22:33 <dgilmore> jlaska: ok
18:22:34 * jlaska adds karma
18:22:35 <adamw> yeah, you suck! :)
18:22:35 <tflink> hey, at least you agree with the previous decision :)
18:22:48 <Viking-Ice> dgilmore, you have a hole I only have a crypt :|
18:23:14 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=690930
18:23:15 <buggbot> Bug 690930: unspecified, unspecified, ---, anton, ASSIGNED, microcode_ctl loops, impossible to boot
18:23:36 <jlaska> adamw: I just like to wait, and be the one to push it over the karma threshold :)
18:23:45 <adamw> glory hog
18:23:50 <jlaska> #info microcode_ctl loops, impossible to boot
18:24:06 * adamw is a bit worried about this because now they're coming up with big shiny fixes
18:24:08 <jlaska> alright, we're over 100 comments in this bug
18:24:19 * adamw liked the nice, dependably-only-broken-a-bit state we had already..
18:24:25 <tflink> and it still doesn't sound like its been 100% solved
18:24:34 <adamw> so, there's a microcode_ctl update which just showed up this morning which is supposed to be all that and a bag of chips
18:24:51 <Viking-Ice> tflink, comment 108 suggest this is solved
18:24:56 <adamw> i.e. it should fix everything for everyone and make sure microcode updates work and the system always boots and free unicorns for all
18:25:11 <adamw> but i'd say we should only take a further update into the rc if we're really damn sure it works
18:25:22 <adamw> otherwise just stick with the 'known to be only a little bit broken' current state
18:25:40 <adamw> (as a refresher, we kept this bug on the list for observation, for just this kind of case; the _current_ state in f16 is working well enough for alpha)
18:26:16 <jlaska> anything else we need to do for this then?
18:26:16 <Viking-Ice> but does the update actually break anything mean is not the worst case scenario that things stay the same?
18:26:32 <adamw> Viking-Ice: it's a pretty drastic change, i think the worst case scenario could be just about anything
18:26:47 <Viking-Ice> dam that anything!
18:26:58 <adamw> heh
18:27:23 <adamw> jlaska: for now i'd say keep a close eye on the bug and the karma of the update
18:27:40 <adamw> if the update looks really good we can consider pulling it for tc2/rc1, otherwise we can leave it till post-alpha
18:27:54 <Viking-Ice> sounds like a solid plan
18:27:57 <jlaska> #info insert karma here -> https://admin.fedoraproject.org/updates/microcode_ctl-1.17-18.fc16
18:28:12 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=726744
18:28:13 <buggbot> Bug 726744: unspecified, unspecified, ---, extras-orphan, MODIFIED, at-spi-python has broken deps
18:28:16 <jlaska> #info at-spi-python has broken deps
18:28:37 <adamw> so this was just another case of issues caused by pyorbit disappearing
18:28:57 <jlaska> are we still in need of a pyorbit bodhi update request?
18:29:00 <adamw> so obviously this got fixed somehow for tc1, but as i commented at the end, i'm not entirely sure if pyorbit is really back in the repos for good yet, or if dgilmore just pulled it in sideways or something
18:29:52 <jlaska> dgilmore, any news on your end?
18:30:46 <Viking-Ice> should we just do what jlaska did in comment 3 to be on the safe side ?
18:31:33 <jlaska> uh oh, what did I do?
18:31:44 <jlaska> oh I see
18:31:50 <jlaska> yeah, that might be how we worked around it for TC1
18:31:53 * adamw wonders what happened to dgilmore
18:31:59 <adamw> i think we flipped his trauma switch
18:32:03 <jlaska> let's needinfo? this for dgilmore for now, and move on
18:32:23 <jlaska> he may have done was Viking-Ice suggested
18:33:01 <jlaska> #info feedback needed from dgilmore on 726744 - is a pyorbit update still required for F16 Alpha?
18:33:03 <Viking-Ice> adamw, I think he's hiding in hole o_O  any golfer around ?
18:33:10 <jlaska> heh
18:33:12 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=724928
18:33:13 <buggbot> Bug 724928: unspecified, unspecified, ---, lpoetter, POST, Reboot ends with kernel panic on systemd abort()
18:33:18 <jlaska> #info Reboot ends with kernel panic on systemd abort()
18:33:27 <Viking-Ice> "Fixed with systemd-31-2.fc16"
18:33:55 <adamw> yeah, this is just a case of making sure a new enough systemd is pulled in for the next compose
18:34:08 <jlaska> what's in Alpha now?
18:34:26 <jlaska> systemd-33-1.fc16
18:34:42 <Viking-Ice> that's the latest in koji
18:34:53 <jlaska> same for bodhi
18:35:18 <jlaska> #agreed 724928 - VERIFIED, fixed_in=systemd-31-2.fc16
18:35:28 <jlaska> ready for proposed NTH list?
18:35:33 <jlaska> clumens: this is mostly installer issues
18:35:38 <clumens> yep.
18:35:38 <adamw> jlaska: what was in tc1 was pre-fix, tc1 has the bug
18:35:38 <jlaska> are you available?
18:36:00 <clumens> i am standing by.
18:36:20 <jlaska> adamw: from what I can tell, the systemd in updates-testing (slated for 'stable') resolves the issue, is that right?
18:36:26 <jlaska> clumens: still standing
18:36:27 <adamw> jlaska: yes.
18:36:39 <jlaska> #info the systemd in updates-testing (slated for 'stable') resolves the issue
18:36:50 <jlaska> Okay, these next few are the proposed NTH bugs
18:36:51 <Viking-Ice> I personally think that all proposed bugs that have an clear beta criteria should be dropped as an alpha NTH
18:37:06 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727933
18:37:07 <buggbot> Bug 727933: high, unspecified, ---, bcl, POST, Installing onto an EFI system from an EFI USB stick fails when trying to use /boot/efi from the USB
18:37:14 <jlaska> #info Installing onto an EFI system from an EFI USB stick fails when trying to use /boot/efi from the USB
18:37:17 <adamw> Viking-Ice: why?
18:37:26 <adamw> Viking-Ice: because it's blocker for beta doesn't mean it can't be nth for alpha
18:37:50 <jlaska> Viking-Ice: also, the NTH's don't hold up the bus  ... if they aren't ready+tested in time ... they don't make it
18:38:08 <Viking-Ice> then we can make all bugs NTH right ;)
18:38:20 <adamw> Viking-Ice: no. nth means we think it's worth taking the fix through the alpha freeze.
18:38:40 <adamw> efi bugs look like a good example to me: we only require efi to work at beta, but if there's a fix ready for alpha, i'd say that's something worth taking
18:38:42 <jlaska> bugs which constitute infringements of the desktop-related Fedora_Release_Criteria as applied to non-default desktops
18:38:45 <jlaska> bugs which result in a system being unable to reach a graphical environment
18:38:48 <jlaska> significant installer bugs which do not meet the criteria to be blocker bugs
18:38:51 <jlaska> 
18:40:03 <jlaska> if the developer (bcl) is requesting NTH for Alpha, I'm not inclined to say no
18:40:15 <Viking-Ice> adamw, but we general dont do we cause we cant risk jeperdising the release in question thus NTH  should not be pulled...
18:40:15 <jlaska> that's kind of the point (or part of it), imo
18:40:19 <clumens> jlaska: bcl just posted a patch for this.  i can review and rebuild this afternoon.
18:40:37 <bcl> given that these make EFI *not work* they would be NTH as soon in the process as possible.
18:40:37 <adamw> Viking-Ice: the whole point of nth is to identify the fixes we think *are* worth pulling.
18:40:40 <jlaska> Viking-Ice: if it's considered invasive or disruptive, yeah ... we generally frown on those NTH updates
18:41:00 <adamw> bcl: do any of the efi fixes have much potential to screw up non-efi paths?
18:41:26 <bcl> I don't think so. And I've tested it successfully in a KVM.
18:41:53 <adamw> okay, so +1 nth for both efi fixes from me
18:42:01 <Viking-Ice> +1 from me
18:42:04 <tflink> +1
18:42:22 <jlaska> #agreed 727933 - AcceptedNTH for Alpha - non-invasive patch out for review, update can be available later today
18:42:36 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727951
18:42:38 <buggbot> Bug 727951: unspecified, unspecified, ---, rvykydal, ASSIGNED, nm-connection-editors shows "eth0" and "Wired connection 1"
18:42:40 <jlaska> #info nm-connection-editors shows "eth0" and "Wired connection 1"
18:42:55 <clumens> there was a patch, but we didn't like it.  i assume we'll have a new patch on monday.
18:42:55 <jlaska> This is a follow-up to some of the networking problems uncovered in an earlier bug
18:43:19 <jlaska> I think this meets the spirit of the NTH, and if a fix is available in time, I'd like to include this in the Alpha
18:43:31 <Viking-Ice> +1 from me
18:43:49 <jsmith> NTH +1 from me
18:43:51 <jlaska> net result ... nm-connection-editor lists duplicate network device names ... making it uncertain which device to actually select to activate networking
18:43:54 <tflink> +1 NTH
18:44:08 <adamw> +1 if the fix isn't too messy.
18:44:32 <adamw> but the impact of this isn't really too horrible, is it?
18:44:45 <jlaska> not, not devastating
18:44:50 <jlaska> no, not ...
18:44:59 <jlaska> it's just not clear which device actually is your real NIC that works
18:44:59 <adamw> so i might be -1 if the fix was complex
18:45:24 <jlaska> clumens: would you be comfortable rejecting this should the patch be invasive?
18:45:33 <jlaska> meaning, we leave it in your capable hands :)
18:45:36 <clumens> yeah
18:46:11 <jlaska> #agreed 727951 - AcceptedNTH for Alpha - impacts usability of nm-c-editor during installation, anaconda-devel will reject if patch considered too invasive
18:46:21 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=728007
18:46:22 <buggbot> Bug 728007: high, unspecified, ---, bcl, POST, EFI install fails with traceback - TypeError: '_sre.SRE_Match' object is not subscriptable
18:46:26 <jlaska> #info EFI install fails with traceback - TypeError: '_sre.SRE_Match' object is not subscriptable
18:46:44 <bcl> this is in my batch of EFI patches.
18:46:49 <jlaska> consensus in the bz is ...
18:46:49 <jlaska> +1 beta blocker, +1 alpha NTH
18:46:55 <clumens> bcl: are those patches all or nothing?
18:47:10 <adamw> jlaska: ack
18:47:15 <Viking-Ice> ack
18:47:17 <bcl> well, for EFI to install yes. but they are not inter-dependent.
18:47:40 <jlaska> I think we already have enough to ack for AlphaNTH ... /me works up #agreed
18:47:42 <clumens> so if we wanted EFI installs in the alpha, we'd need to grab them all
18:47:53 <jlaska> oh i see
18:48:28 <jlaska> #agreed 728007 - AcceptedNTH for Alpha - If tested fix available in time, will include for Alpha
18:48:40 <jlaska> one more EFI ...
18:48:42 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=728015
18:48:43 <buggbot> Bug 728015: high, unspecified, ---, bcl, MODIFIED, EFI Install fails with _non_linux_format_types error
18:48:49 <jlaska> #info EFI Install fails with _non_linux_format_types error
18:48:55 <jlaska> bcl ... you've had your sights on EFI this week :)
18:49:19 <bcl> yeah. took way more work that I expected.
18:49:22 <jlaska> same story as previous bugs ...
18:49:31 <Viking-Ice> yup ack on that as well
18:49:37 <jlaska> from the bug we have:  +2 beta blocker, +2 alpha nth
18:49:42 <Viking-Ice> +1 to beta +1 to nth
18:49:48 <jlaska> alrighty
18:50:05 <jlaska> #agreed 728015 - AcceptedNTH for Alpha - if tested fix is available in time, will include for Alpha
18:50:13 <jlaska> #topic http://bugzilla.redhat.com/show_bug.cgi?id=727946
18:50:14 <buggbot> Bug 727946: unspecified, unspecified, ---, mgracik, NEW, Request to add ModemManager to installer initrd.img
18:50:18 <jlaska> #info Request to add ModemManager to installer initrd.img
18:50:21 <clumens> we should be able to knock that whole pile out today, then.
18:50:30 <jlaska> yeah, that'd be good
18:50:42 <tflink> out of curiosity, why does modemManager need to be in initrd?
18:50:52 <jlaska> bcl: noted earlier in #anaconda that this issue really just resolves an error message during bootup
18:50:57 <adamw> so...the impact of this is trivial but the danger is also trivial...ehhh.
18:51:00 <jlaska> it's unclear whether *any* functionalityi s gained or lost by this bug
18:51:01 <Viking-Ice> hum sounds like something I would not like to see as NTH
18:51:01 <tflink> that seems to me to be something that wouldn't be needed until later
18:51:03 <adamw> i'm tempted to be -1 on principle.
18:51:10 <clumens> yeah me too
18:51:10 <Viking-Ice> -1 from me
18:51:17 <jlaska> sounds good to me
18:51:21 <clumens> if for no other reason than that i hate modems.
18:51:25 <adamw> haha.
18:51:26 <jlaska> haha
18:51:27 <tflink> -1 nth
18:52:02 <jlaska> #agreed 727946 - RejectedNTH for Alpha - rejected on principle and with authority!
18:52:14 * tflink is tempted to put that in bz
18:52:17 <adamw> heh
18:52:18 <jlaska> please do! :D
18:52:20 <jlaska> #topic Open discussion
18:52:49 <jsmith> Thanks again for everyone that contributed to the meeting, and stuck around for the end
18:53:00 <adamw> yeah
18:53:01 <jsmith> I know it was long, but we couldn't keep releases rolling without you folks!
18:53:07 <adamw> so...we still have tc2/rc1 question
18:53:11 <jsmith> Aye :-)
18:53:23 <adamw> thing is, i think we're actually kinda close to being able to do a rc1 now, right?
18:53:40 <dgilmore> adamw: i think we shoot for rc1
18:53:45 <jlaska> I'd say close, but it's not there
18:53:47 <adamw> the only two real action items i see are to get an NM build with the fix for networking
18:53:51 <adamw> and block report
18:54:04 * jlaska checks status of blocker bugs
18:54:11 <adamw> the other open, unmodified blockers are still uncertain (giant warning dialog) or just there for observation (microcode_ctl)
18:54:28 <jlaska> dgilmore: what's up with pyorbit?
18:54:36 <jlaska> e.g. bug#726744
18:54:37 <adamw> oh yeah, we needed some input on that
18:54:37 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=726744 unspecified, unspecified, ---, extras-orphan, MODIFIED, at-spi-python has broken deps
18:54:42 <tflink> I think that I missed one or two of the proposed blockers - will get them shortly
18:55:19 <dgilmore> jlaska: it was added back
18:55:31 <adamw> dgilmore: and it's actually in the right repos for sure?
18:55:35 <jlaska> dgilmore: so no pyorbit bodhi update is needed, it was manually pulled in?
18:55:44 <jlaska> adamw: I believe it's, fo sho
18:55:59 <dgilmore> jlaska: yes looks like halfline did not create a update for it
18:56:15 <adamw> okay, cool
18:56:19 <adamw> so yeah, i only see those two action items
18:56:28 <jlaska> sorry for being dense, so we still need a pyorbit update then?
18:56:28 <adamw> i can try and herd NM if someone else wants to herd report?
18:56:36 <dgilmore> adamw: i just pinged him to create said update
18:56:41 <jlaska> dgilmore: okay, thx
18:56:52 <jlaska> okay ... let's #info the remaining items preventing compose
18:57:08 <jlaska> #topic Discussion on RC1 readiness
18:57:35 <jlaska> #info pyorbit bodhi update required - dgilmore contacted halfline for help
18:57:38 <jlaska> what else?
18:58:16 * jlaska makes stuff up
18:58:41 <jlaska> #info Updated NetworkManager build required to resolve installer networking problems
18:58:59 <adamw> and report needs to be blocked
18:59:06 <adamw> (and we need to check any dependencies are satisfied by libreport)
18:59:21 <jlaska> #info report package needs to be blocked by rel-eng
18:59:36 <jlaska> adamw: help me out with an #info on that one
18:59:55 <Viking-Ice> just out of curiosity where does the tc2/rc1 question originate?
19:00:05 <jlaska> Viking-Ice: yesterday was the scheduled date for RC1
19:00:26 <jlaska> and a fair number of install ISO related things have changed
19:00:29 <jlaska> so we'd like updated test images
19:00:40 <jlaska> just trying to decide whether we've moved enough bugs along to get RC1
19:00:45 <Viking-Ice> ok let's shoot for rc1 then ;)
19:00:45 <jlaska> and if not ... it's TC2 timie
19:00:48 <jlaska> time
19:00:58 <jlaska> *anything* else?
19:01:15 <adamw> don't think so
19:01:16 <dgilmore> jlaska: nothing here
19:01:25 <adamw> let's try and get the outstanding stuff sorted today
19:01:26 <jlaska> dgilmore: when would you prefer to start building images?
19:01:29 <adamw> i'll go find an NM maintainer to bug
19:01:46 <jlaska> I'd like to know when we make a cut'off and decide TC2 or RC1
19:01:57 <jlaska> or is it okay if we go until Monday and don't have either yet
19:02:13 <tflink> it would be nice to have some updated image to test with
19:02:19 <dgilmore> jlaska: id like to try make something today
19:02:26 <dgilmore> to see if we can even compose
19:02:42 <Viking-Ice> uhum there was one thing
19:02:48 <jlaska> okay, so we'll plan on doing a compose today ... and if the stars line up ... it's RC1, otherwise TC2
19:02:51 <dgilmore> jlaska: though i suspect there will be a couple of stragling things that might hold us up
19:02:52 <Viking-Ice> which kernel version are we shipping
19:03:08 <dgilmore> Viking-Ice: whatever is currently stable :)
19:03:25 <jlaska> Also ... a reminder ...
19:03:38 <jlaska> #info 2011-08-10 (Wed) - Fedora 16 Alpha Go/No-Go Meeting
19:04:06 <Viking-Ice> dgilmore, kernel that do not have - "Disable CONFIG_BCMA since no driver currently uses it" will affect networking for some people ( like me hehe )
19:04:42 <jlaska> #topic Open discussion <your bug here>
19:05:01 <jlaska> any other bugs to review today?
19:05:04 <adamw> Viking-Ice: so having that enabled actually breaks networking?
19:05:26 <Viking-Ice> yup bug 727796
19:05:27 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=727796 low, unspecified, ---, kernel-maint, MODIFIED, bcma to block wl, b43 and maybe bcrm43xx in kernel 2.6.40
19:05:30 <nirik> random/not bug: any karma for abiword update appreciated... would be nice to be in stable so we could get several of the spins to compose.
19:05:31 <jlaska> there it is
19:05:32 <Viking-Ice> wi-fi in my case
19:05:52 <dgilmore> Viking-Ice: koji latest-pkg f16 kernel --quiet
19:05:52 <dgilmore> kernel-3.0.0-1.fc16                       f16                   kyle
19:05:59 <dgilmore> thats what we currently have
19:06:09 <adamw> Viking-Ice: i'd be +1 nth if you wanted to propose that one
19:06:11 <jlaska> #help Karma needed for abiword - https://admin.fedoraproject.org/updates/abiword-2.8.6-12.fc16
19:06:43 <jlaska> #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=727796
19:06:44 <buggbot> Bug 727796: low, unspecified, ---, kernel-maint, MODIFIED, bcma to block wl, b43 and maybe bcrm43xx in kernel 2.6.40
19:06:48 <adamw> https://admin.fedoraproject.org/updates/kernel-3.0.0-3.fc16 is sitting in updates
19:06:56 <Viking-Ice> yeah I would like to propose it but switching kernels at this point :|
19:06:57 <jlaska> #info s sitting in updates
19:07:01 <jlaska> #undo
19:07:01 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xf5e0f4c>
19:07:07 <jlaska> #info bcma to block wl, b43 and maybe bcrm43xx in kernel 2.6.40
19:07:07 <adamw> Viking-Ice: i think we're switching since tc1 anyway
19:07:31 <jlaska> anyone with a proposed #agreed ?
19:07:40 <Viking-Ice> ok I'll propose it and give my self ack ;)
19:07:47 <adamw> actually
19:07:53 <adamw> looks like 3.0.0-3 doesn't have the fix
19:08:04 <adamw> only 3.0.1-1 does, but that's borked; jwb is looking at fixing it now
19:08:49 <Viking-Ice> what's borked with 3.0.1-1 ?
19:09:00 <adamw> Viking-Ice: it looks for its modules.dep in the wrong place and can't load any modules...
19:09:50 <Viking-Ice> hum could we trigger a rebuild with the kernel we want to go with simply with Disable CONFIG_BCMA in place ?
19:10:00 <adamw> could, but it's a tad tricky i think
19:10:08 <adamw> since there's already a later-versioned update submitted
19:10:23 <jlaska> anything to handle here ... or shoudl we take this out of meeting?
19:10:27 <adamw> i guess we could ship with it broken and have the fix as an update...wireless isn't super critical
19:10:33 * jlaska in the dark on this issue, so open to suggestions
19:10:44 <Viking-Ice> nth discussion really
19:10:45 <adamw> Viking-Ice: do you know if it could possibly affect b44 (broadcom wired)?
19:11:13 <adamw> hum,doesn't look like it
19:11:15 <Viking-Ice> Dont know it affected this  BCM4313 802.11b/g LP-PHY
19:11:16 <adamw> their ID tables are different
19:11:46 <Viking-Ice> which is mine others I dont know really I mentioned this on the kernel list and someone else filed a bug about it
19:12:45 <Viking-Ice> so ack nack on nth ?
19:12:51 <Viking-Ice> and ack nack on rc1 compose ?
19:13:23 <adamw> okay, i just checked
19:13:41 <adamw> the four chips bcma claims are all wireless, and i think all wireless that only work with the sta driver
19:13:48 <adamw> so i think this isn't critical enough to be nth for alpha
19:13:57 <Viking-Ice> ok fine by me
19:14:01 <adamw> (afaict none of them is actually listed as working with b43)
19:14:20 <adamw> thanks for bringing it up though
19:14:23 <Viking-Ice> cant recall if I'm using something from fusion
19:14:29 <jlaska> proposed #agreed 727796 - RejectedNTH for Alpha - <insert something meaningful here>
19:14:39 <jlaska> patch would be prefered :)
19:14:40 <adamw> Viking-Ice: if you look at the alias lists for ssb / b43, and bcma, they don't match at all afaics
19:15:12 <adamw> jlaska: #agreed 727796 rejectednth - impact is only one four particular broadcom wireless adapters that don't work ootb in fedora anyway, can be worked around or fixed with a post-install kernel update
19:16:07 <Viking-Ice> did we solve the tc2/rc1 question
19:16:18 <Viking-Ice> I'm ack on rc1 compose
19:16:27 <Viking-Ice> and I think dgilmore as well
19:16:34 <Viking-Ice> so that's 2
19:16:41 <jlaska> #agreed 727796 rejectednth - impact is only one four particular broadcom wireless adapters that don't work ootb in fedora anyway, can be worked around  or fixed with a post-install kernel update
19:16:48 <jlaska> well ...
19:16:55 <adamw> Viking-Ice: i think we're shooting for rc1
19:16:59 <jlaska> right ...
19:17:02 <adamw> if we can't get to rc1 state pretty soon we might re-evaluate
19:17:08 <jlaska> assuming all the issues line up in time for dgilmore to compose
19:17:13 <jlaska> dgilmore: do you have a time ?
19:17:14 * dgilmore is ack for rc1
19:17:31 <Viking-Ice> so that's four acks shooting for rc1
19:17:34 <Viking-Ice> ?
19:17:35 <jlaska> dgilmore: when is your drop-dead I'm composing now time?
19:17:42 <dgilmore> jlaska: ill have some time this evening or in the morning to compose assuming we have all the fixes
19:17:55 <jlaska> hmm, I don't want it to wait that much longer
19:18:17 * jlaska worried that we'll be on Monday without any compose
19:18:18 <dgilmore> jlaska: ideally no more than 6 hours from now
19:18:23 <jlaska> dgilmore: okay
19:18:32 <dgilmore> jlaska: id prefer to do it tonight
19:18:37 <jlaska> okay,thanks
19:18:46 <jlaska> Viking-Ice: yeah, we all want RC1, but we need to line these bugs up
19:18:53 <Viking-Ice> yup
19:19:01 <dgilmore> jlaska: im going to mmcgraths 10am ish in the morning and will be afk for the day after that tomorrow
19:19:07 <jlaska> dgilmore: okay
19:19:20 <jlaska> #topic Open discussion - last call
19:19:28 <jlaska> any other business to discuss today?
19:19:36 <dgilmore> jlaska: if we dont get it today it would have to be 7am CDT or monday
19:19:39 <dgilmore> none
19:19:41 <jlaska> otherwise ... let's chase down these loose ends
19:19:58 <jlaska> dgilmore: thank you, that's helpful to have that info
19:20:08 * jlaska doesn't wait to leave you indefinitely waiting for bugs
19:20:23 * jlaska lights a 1 minute fuse
19:21:19 <adamw> oh, the other thing we need is feedback
19:21:22 <tflink> so what is the deadline for RC1?
19:21:30 <tflink> sorry, two meetings at once
19:21:35 <adamw> make sure all the updates for blocker fixes have at least +1 from a proventester (i think that's all we need at present)
19:21:41 <adamw> tflink: it was supposed to happen yesterday.
19:21:58 <adamw> tflink: if we're gonna compose it today, dgilmore wants everything ready within 6 hrs
19:22:15 <jlaska> #info Compose deadline 21:00 EDT - today
19:22:29 <tflink> are we going to do a TC if everything isn't ready?
19:22:37 <tflink> or just wait for monday
19:22:50 <jlaska> that was my understanding ... I think we could use *a* compose going into the weekend
19:23:16 <tflink> ok, I didn't see anything specific and was wondering
19:23:22 <jlaska> no, it's a good question
19:23:51 <jlaska> dgilmore: ?
19:23:52 <Viking-Ice> if we cant make rc1 we fall back to tc2 right ?
19:23:58 <adamw> i think we need the networking issue fixed at minimum to do a new compose
19:24:07 <adamw> but meh
19:24:31 <jlaska> adamw: so start with that, you probably already are
19:24:36 <jlaska> adamw: but agreed
19:24:36 <adamw> yeah, i am.
19:24:47 <jlaska> Viking-Ice: yes, I think that's ideal ... but could be wrong
19:24:47 <adamw> trying to find an NM maintainer. i guess you don't want me to do the build. =)
19:24:51 <dgilmore> jlaska: im going to call the next compsoe RC1
19:24:54 <jlaska> adamw: please no :)
19:25:03 <dgilmore> jlaska: since i have to name it something at compose time
19:25:10 <dgilmore> so im going to be optimistic
19:25:16 <jlaska> dgilmore: please only do that if all the accepted blockers are resolved when you do it
19:25:19 <adamw> dgilmore: well, if we have fixes for all acceptedblockers in the compose, we can call it rc1
19:25:23 <dgilmore> jlaska: sure
19:25:24 <adamw> dgilmore: if we don't, call it tc2
19:25:40 <dgilmore> adamw: will do
19:25:45 <dgilmore> adamw: but im being positive here
19:25:51 <dgilmore> and we will have RC1 :)
19:25:53 <jlaska> #info Plan is to focus on resolving AcceptedBlocker bugs and composing RC1 this evening
19:26:12 <jlaska> #info Fallback will be to compose TC2 if only NM blocker is fixed
19:26:33 <jlaska> #info Double secret fallback is to panic if no AcceptedBlocker bugs are resolved this evening
19:26:43 <jlaska> thanks everyone for your time today!
19:26:56 <jlaska> just remember, sausage is delicious
19:27:06 <jlaska> but the process is nasty
19:27:21 <jlaska> I'll follow-up with minutes to the list shortly
19:27:21 <Viking-Ice> fyi that sounds gay..
19:27:32 <jlaska> #endmeeting