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