18:05:56 #startmeeting interim beta blocker bug review meeting 2010-09-14 18:05:56 Meeting started Tue Sep 14 18:05:56 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:05:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:06:03 #intro 18:06:07 #topic intro 18:06:21 so, this meeting is just to go through the blocker list and try and make sure we're on top of everything, given that RC compose is due soon 18:06:46 given that i'm going to look at modified and on_qa bugs as well as new, since we need to make sure those fixes are correct and on track for rc inclusion 18:07:09 list we're working from: https://bugzilla.redhat.com/showdependencytree.cgi?id=611991&hide_resolved=1 18:07:23 #topic https://bugzilla.redhat.com/show_bug.cgi?id=608992 18:07:24 Bug 608992: medium, low, ---, dhuff, MODIFIED, Add "Boot system with basic video driver" option at the initial screen 18:07:40 this is one i'm tracking closely: it's adding a 'basic video driver' option to the live image, like we have on traditional installer images 18:08:45 we have a livecd-tools build that correctly adds a menu option now. however, installing doesn't correctly configure the X driver. 18:10:15 bcl is looking at that in https://bugzilla.redhat.com/show_bug.cgi?id=633827 . i think all we can do here is make sure the livecd-tools build makes beta (i'm working on that with bruno) and make sure dlehman/bcl know that if the anaconda side fix is going to make the beta it needs to be in an f14 anaconda build tomorrow or so 18:10:16 Bug 633827: medium, low, ---, bcl, NEW, liveinst needs to pass --xdriver=* to anaconda when xdriver=* is in /proc/cmdline 18:11:05 bcl said the fix 'shouldn't be hard to add', so that sounds positive. 18:11:23 any notes on this one? 18:13:19 ok, next 18:13:38 oh, bcl has a fix, so next job is me to test it, then anaconda team to include it in next f14 anaconda build 18:13:53 #agreed 633827 adamw will test bcl's proposed fix and feed back to him 18:14:04 #action adamw to test bcl fix for 633827 18:14:15 sorry, was grabbing some food & running errands 18:14:29 no problem, we just got started, just about to start the second bug 18:14:49 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027 18:14:50 Bug 621027: medium, low, ---, tcallawa, ON_QA, Graphical screen in anaconda shows F-13 18:15:16 so this is the bug for adding f14 branded images/logos 18:15:28 we now have a proposed fix for this, which does put a proper branded graphic in anaconda 18:16:02 jlaska and I both got live images with grey bootloader backgrounds when we tested the fix, though. next action is probably for jlaska/me and the fedora-logos and livecd-tools maintainers to investigate that 18:17:16 anyone have any ideas on this one? 18:18:16 mizmo is offering 2 differenti mages for me to test 18:18:23 I'll try those out and see if that works better 18:18:49 awesome, thanks 18:19:08 #agreed 621027 fix is in but problem with live image bootloader background, jlaska to test potential fix from mizmo 18:19:09 is it a gray version of the logo, or just plain gray? 18:19:16 #action jlaska to test 621027 fixes from mizmo 18:19:22 notting: plain grey, as if it's a fallback for a missing image 18:21:12 #topic https://bugzilla.redhat.com/show_bug.cgi?id=622927 18:21:13 Bug 622927: medium, low, ---, rvykydal, MODIFIED, F14 Alpha RC2 - /etc/resolv.conf gets corrupted, cannot download packages 18:21:45 this looks like it should be testable in TC1 18:21:53 so we should just be able to ask orion to test TC1, confirm it's fixed, and close it off 18:22:49 anything else on this? 18:23:50 ok 18:24:01 #agreed 622927 ask tester to verify fix in TC1 and close the bug 18:24:33 #topic https://bugzilla.redhat.com/show_bug.cgi?id=627014 18:24:34 Bug 627014: high, low, ---, lpoetter, MODIFIED, systemd provided telinit does not work as advertised 18:25:26 lennart seems to be working on this and testers are testing it, given the last few comments we can probably close it or drop it from blocker list with 10-2 18:26:22 yes, systemd-10 fixes it 18:26:46 thanks michich 18:27:22 only problem is that systemd-10 will be held up in bodhi until the network service regression is fixed 18:27:47 adamw: last i checked it was submitted to stable via karma 18:28:26 * adamw checks 18:29:02 owch. that shouldn't have happened :/ need...bodhi...2.0... 18:29:27 well, anyway, we can talk about it when we hit the network bug (630225) 18:30:15 #agreed 627014 looks like major issues are fixed, we can drop it from blocker list or close it when 10-1+ is accepted 18:30:32 #topic https://bugzilla.redhat.com/show_bug.cgi?id=627401 18:30:34 Bug 627401: medium, low, ---, clumens, MODIFIED, please create systemd default.target symlink pointing to /lib/systemd/system/runlevelX.target instead of /etc/systemd/system/runlevelX.target 18:31:10 this is fixed in anaconda 14.17.1-1, confirmed by me (and others) 18:31:36 add me to the +1 confirm list :) 18:32:25 not in Bodhi yet? 18:32:31 dlehman: note the latest update request for anaconda is 14.17-1, which misses this fix...we probably need a new build after 14.17.1-1 for other bugs anyway though so it's not a huge thing 18:34:02 #agreed 627401 is fixed in anaconda 14.17.1-1, anaconda team need to submit that or a later build to bodhi 18:34:26 #topic https://bugzilla.redhat.com/show_bug.cgi?id=628239 18:34:27 Bug 628239: medium, low, ---, bcl, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau 18:35:03 i'm fairly sure this isn't valid as described 18:35:26 i tested it with tc1 netinst.iso and got a properly configured installed system: xorg.conf specified vesa, and nomodeset was in the kernel params. 18:35:47 adamw: yeah, I'll probably be rebuilding this evening anyway so I'll just do the one update 18:35:58 for now we're waiting for more info from the reporter, but given what we know about it atm, i expect we'll be dropping this from the blocker list 18:36:01 dlehman: cool, that works 18:36:40 dlehman: bcl: are you actually aware of any bugs in the 'basic graphics driver' handling for traditional installs? or no thoughts on this one without more info from reporter? 18:37:12 I tried to reproduce it here and it works fine for me. 18:37:41 ok 18:37:59 so yeah, for now i'd say let's not worry about this and wait for the reporter 18:38:30 original report was with Alpha, so it likely got fixed by some other change. 18:38:34 #agreed 628239 does not appear to be valid as described, waiting on more info from reporter, but unless we learn something new, looks like this isn't a blocker 18:39:38 #topic https://bugzilla.redhat.com/show_bug.cgi?id=628241 18:39:39 Bug 628241: urgent, low, ---, mgracik, ON_QA, Fedora 14 Alpha, post reboot installation steps not working 18:40:07 this is fixed in firstboot-1.113-1.fc14 , i've tested it. 18:40:24 is that in stable yet? 18:41:20 nope, needs pushing, it has necessary karma though 18:41:31 https://admin.fedoraproject.org/updates/firstboot-1.113-1.fc14 - i posted a comment asking mgracik to push it 18:43:01 if you can push it for him that'd get one thing off our tracking list 18:43:58 stable push wouldn't be until tonight anyway 18:44:01 ok 18:44:17 #agreed 628241 is fixed in firstboot-1.113-1, needs to be pushed stable 18:44:30 #action mgracik or notting to push firstboot-1.113-1 stable 18:44:40 #topic https://bugzilla.redhat.com/show_bug.cgi?id=629719 18:44:41 Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3') 18:44:55 this one is a bit sticky 18:45:18 we have one reporter, dlehman thinks he's doing something other than what he's claiming in the report 18:45:28 ben boeckel says he hit the same bug, but on a system he can no longer poke 18:45:32 the other reporter didn't provide logs 18:45:44 so it looks like some kind of a valid bug but possibly hard to figure out an impact or fix given current situation 18:46:36 just so we're all on the same page, what is it in the logs that makes you suspicious of the description? 18:47:10 why would you be installing onto 127 raid devices? 18:47:16 the fwraid device starts with three partitions 18:47:47 notting: i doubt they are, i imagine the enumeration is some kind of quirk 18:48:08 we log mounting of ext4 fs on md127p3, then a minute or two later when we try to zero out the filesystem on it in the process of activating new storage configuration the device node is no longer there 18:48:57 notting: it's something about mdadm and incremental assembly starting at 127 and going backwards to avoid collisions 18:49:23 there *could* be other causes of that, though, right? some kind of bug which causes the device to disappear... 18:49:27 *boggle* 18:49:43 in between unmounting the fs on md127p3 and trying to zero out the same filesystem we do not do anything to the device 18:50:34 there could be, I suppose. seems like it would happen for someone other than a person who already admitted to switching to tty2 to run fdisk while anaconda was running 18:50:34 not necessarily an anaconda bug 18:50:39 perhaps something the kernel is screwing up 18:51:35 still, you were pretty clear about asking him to re-test without doing that, and he was very explicit that he *hadn't* done it 18:52:01 in my experience, reporters who think they know better generally just tell you they did it again even though you told them not to, or they fudge the issue and don't mention it; they don't flat out *lie* about it 18:53:27 that's generally been my experience too, but it wouldn't be the first time a user said "I did this differently and it still happened!" when the second failure was in fact completely different 18:53:44 well, we do have the log from the second attempt in this case 18:53:57 or, as you mentioned earlier, a user uploading a log from a previous attempt as if it were from the latest 18:54:40 right, but i asked about that and it doesn't seem to be what happened... 18:54:50 jlaska: do we have hardware somewhere to do some RAID tests and see if we can hit this? 18:55:02 jlaska: try and replicate the partition layouts sandro and ben used? 18:55:15 sorry, distracted ... 18:55:19 HW or BIOS raid? 18:55:30 this is BIOS RAID iirc, right? 18:55:30 syslog shows the selinux init for md127p3, then 49 seconds later it shows this: 09:04:30,551 INFO kernel: md127: p1 p2 18:55:50 yes 18:56:52 isw raid 18:57:26 I've not had any problems with my standard BIOS RAID tests ... but it doesn't cover a lot of hardware 18:57:49 jlaska: might be worth trying to use the partition layouts mentioned in the bug 18:58:11 I can try that ... but I suspect my setup is sufficiently different already 18:58:27 my devices are always named completely differently ... 18:58:28 e.g ... 18:58:48 ... nvidia_dbebefgap1 18:59:02 ah, isw is intel 18:59:05 so yeah, different... 18:59:17 might you have a machine with intel bios raid lying around? 18:59:29 lying around no :( 18:59:43 I can put some calls out, but we're not going to get test feedback in the desired time frame 18:59:48 ok 18:59:58 any hints as to whether this is device specific vs partition specific? 19:00:21 if ben really hit the same bug it can't be hugely specific. although perhaps they have the same motherboard or something 19:00:23 Should I put a call out to test@l.fp.org for anyone with Intel BIOS RAID? 19:00:33 they weren't using exactly the same config: sandro has four disks, ben had two 19:01:17 yeah, we can put out an ml call 19:01:25 and maybe try and get sandro to try it one more time 19:01:47 the debate here seems to be how common this failure is, is that right? 19:01:48 and dlehman, maybe you can spend a half hour assuming the reporter is innocent as anything and see if you can figure any other explanation for what happened :) 19:01:59 the ol' hardware/site_config specific vs generic bug issue 19:02:05 jlaska: well, how common, and whether it actually happens without the user doing something they shouldn't 19:02:11 right 19:02:21 (poking the raid config in a console during install, which we very definitely don't support) 19:03:08 does that action plan sound okay? 19:03:17 adamw: I arrived at the notion that he was messing w/ fdisk because there was no other plausible explanation, aside from "random disappearance of partitioned md device nodes" 19:03:44 fair enough 19:03:45 adamw: sounds like best we can do right now ... do we have a fall-back plan for this should we have no new information? 19:03:49 iow, I already looked for another explanation and found none 19:03:52 slip vs demote bug? 19:04:08 given the above i'd say fallback plan is demote it 19:04:13 if no-one else reports the same issue 19:04:57 that'd be my choice 19:05:08 adamw: found someone with matching hardware ... will see what we can uncover 19:05:15 I 3rd that choice 19:05:28 ok, cool 19:05:35 the group is certainly working tails+butts off to get to the bottom, so it's not for lack of concern/effort 19:06:05 #action 629719: we suspect reporter malfeasance, plan is to try and replicate in office, send out ml call to see if anyone else can, and ask reporter to try once more; if we get no more info on this bug will demote it 19:06:13 grr 19:06:14 #undo 19:06:14 Removing item from minutes: 19:06:20 #agreed 629719: we suspect reporter malfeasance, plan is to try and replicate in office, send out ml call to see if anyone else can, and ask reporter to try once more; if we get no more info on this bug will demote it 19:06:33 #action adamw or jlaska to send out ml testing call for 629719 19:06:55 adamw: I'll do that now 19:06:58 cool thanks 19:07:00 #topic https://bugzilla.redhat.com/show_bug.cgi?id=630490 19:07:01 Bug 630490: medium, low, ---, lpoetter, ASSIGNED, disabled units still get bus activated 19:07:45 fixed in systemd-10 19:08:55 notting: you're definitely okay with this one now? 19:09:08 i still think the nmcli behavior is wrong 19:09:24 but that can be tracked in the nm bug 19:09:29 OK 19:09:50 #agreed 630490 testing indicates this is fixed in systemd-10, can be closed when that goes stable 19:10:32 #topic https://bugzilla.redhat.com/show_bug.cgi?id=630952 19:10:33 Bug 630952: urgent, low, ---, notting, MODIFIED, Does not enable the prefdm and rc-local services 19:10:51 this is fixed in the systemd/initscripts/etc. update 19:12:08 yeah, my test live image with these updated packages boots and installs fine 19:12:14 another we can close when the update goes stable 19:12:35 #agreed testing indicates 630952 fix is good, bug can be closed when systemd/initscripts update goes stable 19:12:58 #topic https://bugzilla.redhat.com/show_bug.cgi?id=631620 19:12:59 Bug 631620: medium, low, ---, lpoetter, ON_QA, ordering cycles exist (+ breaking them deletes wrong services) 19:13:32 notting: are you happy with the fix for this? 19:13:45 well, he fixed it by dropping it from being a sysv service 19:13:51 which works 19:13:52 i tested the 'fixed' hal on my system and in my test live image and saw no regressions, but hal still ran on boot, contrary to lennart's assertion 19:14:26 something probably poked it 19:14:44 on my system, sure, but in a live image seems odd. but yeah, i asked if there's a way of telling if anything poked hal. 19:15:15 do you have any concerns about the way the fix was done? i suppose the good thing about my test is it shows the dbus activation sure works. =) 19:15:42 not really. there may, of course, be other dependency loops that cause problems later 19:16:37 right, but that's an unknown unknown =) 19:16:42 (Thank you Dick!) 19:17:07 anyone else want to jump in on this one? 19:18:14 ok 19:18:26 #agreed 631620 fix looks good in all important respects, can be closed when hal update is pushed 19:18:45 #topic https://bugzilla.redhat.com/show_bug.cgi?id=632321 19:18:48 Bug 632321: medium, low, ---, notting, MODIFIED, claims to start ypbind, but doesn't 19:19:19 i'm rather unfamiliar with this...bill, have you tested the fix? 19:19:28 there's a fix? 19:19:34 oh 19:19:44 sorry, there are two bugs with this title 19:19:55 yes, this particular issue is fixed. ypbind's then failing due to something else layter 19:20:12 i just tried it and got 'Sep 14 20:19:39 vaioz ypbind: domain not found' 19:20:32 but i don't really know what ypbind is/does, so =) 19:21:01 notting: which is the other bug? doesn't seem to be on the blocker list 19:21:22 632620 19:22:59 ok 19:23:12 well, logically speaking, it one's a blocker so's the other, i don't think we yet decided either way though 19:23:27 so, what's the basis for this being a blocker? is ypbind needed to get an internet connection in some cases or something? 19:23:54 well, the first one was ypbind failing in all cases 19:24:06 the second bug is ypbind failing iff you're using the network service and dhcp 19:24:22 ah, so yeah, that's a lot tighter 19:24:24 ypbind is an auth mechanism. NIS. 19:24:55 ah, k. so if your network uses NIS, you need it. 19:25:47 i guess this comes down to a judgment call, then...are people on NIS networks who need to use the network service and dhcp sufficiently numerous to block the beta 19:26:36 do we have a reasonable workaround? 19:26:46 'use NetworkManager', presumably 19:27:11 (or 'use static addressing') 19:27:17 any others, bill? 19:28:10 rm /etc/dhcp/dhclient.d/nis.sh ? 19:28:18 that would also work 19:28:29 sounds like we're just overflowing with reasonable workarounds :P 19:28:55 as long as we have a reasonable workaround, and can document the issue on CommonBugs and have a fix coming soon after Beta ... I don't think it's unreasonable to move this off the list? 19:29:01 it's not on the list, actually 19:29:05 jlaska: it wasn't on the list 19:29:07 but since it came up it seemed wise to consider whether it should be 19:29:21 apologies, that's what I get for being in 2 places at once 19:29:29 so, for 632321 the fix is in, and we're comfortable with not adding 632620 to the list 19:29:40 #agreed 632321 is fixed in systemd 10, can be closed when it goes stable 19:29:51 #topic https://bugzilla.redhat.com/show_bug.cgi?id=632489 19:29:52 Bug 632489: medium, low, ---, rvykydal, MODIFIED, Fail to read package metadata after specifying repo= 19:30:19 this one looks straightforward, a fix has been tested in an updates.img and will be in next anaconda build 19:30:28 (note: fesco. paying a little less attention now) 19:30:54 notting: we're nearly done now 19:31:12 only 4 more to go 19:31:19 any wrinkles on 632489 or shall we move on? 19:32:00 seems in good shape 19:32:06 just pending a new build, right? 19:32:09 yup 19:32:20 #agreed 632489 fix has been tested in updates.img, next anaconda build will include it 19:32:40 #topic https://bugzilla.redhat.com/show_bug.cgi?id=632510 19:32:41 Bug 632510: medium, low, ---, clumens, MODIFIED, Installer exited abnormally when starting network in rescue mode 19:33:28 looks like there'll be a fix for this in next anaconda 19:33:33 next action should be for us to test it i guess 19:33:41 yeah, I see the commit in the correct f14-beta-branch in git 19:33:53 of course we'd need a build to do that 19:34:52 right on 19:35:19 so i guess either we take 17.2-1 into rc1 on trust and test it there, or try and get a quick boot.iso to verify it before the rc build 19:35:39 jlaska: wdyt? 19:35:52 i'm probably okay doing it in rc1 19:36:13 hrmm ... 19:36:46 would be nice to confirm ahead of time, but not a *hard* requirement ... it'll be a lesson learned if RC1 comes and it's not fixed 19:37:13 dlehman: adamw: bdonahue (in westford) was able to duplicate tehe Intel BIOS RAID issue ... will be uploading his traceback to the BZ soon 19:37:22 jlaska: aha! awesome 19:37:41 I was hoping he wouldn't see it :) ... any news is good news though 19:37:56 #agreed 632510 fix is in, needs a new build to test it; can either be a quick test boot.iso or we can test it in rc1 19:38:05 #topic https://bugzilla.redhat.com/show_bug.cgi?id=633234 19:38:06 Bug 633234: medium, low, ---, bcl, NEW, Previous grub entry is not overwritten after upgrade with creating new bootloader 19:38:35 this is a new one, we hadn't considered its blockeriness yet 19:38:47 * jlaska loves that "word" :) 19:38:50 no news yet on this one. top of bcl's list 19:38:52 it does seem like a blocker under the criteria 19:39:19 dlehman: bdonahue retested and it seems the problem went away upon the 2nd attempt 19:39:27 won't hijack meeting for this off-topic ... but just fyi 19:39:27 weird 19:39:51 * adamw has his money on some kind of intermittent kernel issue with the raid controller, but eh 19:40:03 votes on blockeriness of 633234? 19:41:04 if it is easily reproducible, seems pretty blockerish 19:41:36 looks pretty straightforward from the report, i wouldn't expect hurry to screw anything up 19:41:44 and i can't really see how it'd be configuration-specific 19:42:01 maybe if bcl can't reproduce it we would have to look harder at that 19:43:42 jlaska: blocker yay or nay? 19:44:46 hrmmm 19:45:09 I don't know if the outcome differs whether you choose to update/skip/new bootloader when upgrading 19:45:36 from the report it's specific to the 'new bootloader' case 19:45:44 ah okay 19:45:49 I'd support including this as a blocker 19:46:05 only cause I can see the preupgrade reports coming in that the installer constantly keeps booting 19:46:26 the skip_bootloader and update_bootloader tests are listed as passes in the tc1 install validation matrix 19:46:29 seems easy to workaround, so if push comes to shove, we can document 19:46:41 this one is listed as a failure by newgle1 and rhe (so obviously newgle could reproduce) 19:46:55 but feels like if we have cycles to investigate and understand the failure so we can at least document it, we should make an attempt 19:47:03 so I'd agree w/ dlehman 19:47:11 ok 19:47:29 #agreed 633234 is a blocker, top priority for anaconda team, it seems reproducible by at least two testers 19:47:37 #action anaconda team to try and investigate and fix 633234 19:48:19 #topic https://bugzilla.redhat.com/show_bug.cgi?id=633315 19:48:20 Bug 633315: medium, low, ---, dcbw, NEW, Connections not editable in nm-c-e in anaconda 19:48:55 this is a new proposed blocker 19:48:59 it doesn't feel terribly blocker-y to me 19:49:49 well, hmm...maybe...is there a case where you'd need to edit an existing connection to make the network install work? 19:51:02 adamw: if you entered the wrong information on accident? 19:51:09 * poelcat is here now BTW :) 19:51:32 poelcat: could you make it to this stage of install in that case? this stuff is all new, aiui, we didn't have nm-c-e in anaconda before 19:51:37 so i'm a bit unsure about the impact 19:52:24 don't know 19:54:33 dlehman: any idea? 19:54:38 radek doesn't seem to be around 19:56:14 hmm, not sure why you'd need to edit the connection you used to get stage2 19:57:33 yeah, that's my thought - if you're there, you must have a connection that's working... 19:57:37 ...or not need one 19:57:48 seems like a bug, but not a blocker, to me 19:58:00 unless i guess you're using boot.iso, which has stage2 but uses network to get packages? 19:58:12 but then don't you get to configure the network earlier in that case? 20:00:42 shall we say we reject it as a blocker for now, and ask radek to re-propose with more details if he thinks it's a blocker? 20:01:00 seems like something to address post-beta, right 20:01:06 wouldn't want it to slip off the radar 20:01:23 * jlaska ergh ... need to step away ... 20:02:05 we're nearly done\ 20:02:24 #agreed 633315 doesn't seem like a blocker, we will reject it for now and ask radek to re-propose if he has a reason for it to be one 20:02:44 i'd propose we also don't consider it a 'nice to have', on the principle of not poking anaconda any more than we have to around releases... 20:03:33 well, I'd like to avoid another release where we can't properly configure the installed systems networking 20:04:07 what does the release criteria say? 20:04:09 i meant not a nice-to-have for beta, fixing it after beta would probably be fine 20:04:11 around this topic? 20:04:17 adamw: oh right 20:04:26 poelcat: it says you need to be able to do a network install. afaict, this bug doesn't impact that. 20:05:48 next bug? 20:06:33 yup 20:06:42 last bug! 20:06:45 #topic https://bugzilla.redhat.com/show_bug.cgi?id=633523 20:06:46 Bug 633523: medium, high, ---, bdpepple, NEW, Dependency issue block empathy installs in F14 20:06:57 this is an obvious blocker as it breaks live image compose 20:07:04 and regular image compose 20:07:08 and all composes and default installs, really. =) 20:07:49 is bpepple around in #fedora-devel? 20:08:29 he's marked as idle, we can ping him 20:08:55 i did 20:09:19 if it's just a straight rebuild, anyone on desktop team could do it, we can probably cc mclasen on the bug to get a quick response 20:09:42 go for it 20:10:32 ok 20:10:49 so...i'd say this is an accepted blocker, we cc mclasen on the bug and ask for a rebuild asap 20:10:52 ack? 20:10:54 ack 20:12:09 okay, that's the list 20:12:29 looks like we're mostly good, a lot of fixed bugs will get closed as soon as the packages are pushed leaving us just a few to work 20:12:41 we have priorities for everyone now i think 20:12:51 #agreed 633523 is an accepted blocker, we cc mclasen on the bug and ask for a rebuild asap 20:12:57 #topic open floor 20:13:13 someone asked me to propose this bug https://bugzilla.redhat.com/show_bug.cgi?id=528232 20:13:15 Bug 528232: medium, high, ---, kernel-maint, NEW, Hang with EFI booting on iMac and Macbook Pro 6.2 20:13:26 i think it is disqualified under #4 of the beta release criteria 20:13:41 for being a blocker 20:14:01 #topic https://bugzilla.redhat.com/show_bug.cgi?id=528232 20:14:02 Bug 528232: medium, high, ---, kernel-maint, NEW, Hang with EFI booting on iMac and Macbook Pro 6.2 20:14:08 Oh, that's a bummer. IIRC Apple has actually fixed EFI in the newer macs. 20:14:37 on the existing criteria it's obviously not a blocker 20:14:45 though it does seem we should periodically review that exception 20:15:25 adamw: what about for Final? 20:15:37 the exception isn't overridden in final 20:15:41 and final inherits the beta criteria 20:15:46 so as things stand it's not a final blocker either 20:15:48 http://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria says nothing about EFI 20:16:03 right, so since it doesn't directly override the beta criterion, the beta criterion stands for final 20:16:05 okay 20:16:20 i'll update the comments in the bug 20:16:26 in case someone else thinks it should be a blocker 20:17:16 bcl: dlehman: any desire to revisit that criterion exception? 20:17:30 i believe we added it because you felt there was no way we could make it work on macs, though my memory's a bit fuzzy 20:17:31 nope. 20:17:34 ok 20:18:09 #agreed 528232 isn't a blocker, Macs are explicitly excepted from efi criterion in beta criteria 20:18:21 f13 works on my macbook as long as I install rEFIt first, so if it doesn't get fixed that will (maybe) still be a solution. 20:18:51 I'd be against any criteria that enforce working macs, simply because there are too many variants and configurations and broken firmwares, and.... 20:19:31 cool 20:19:35 any other bugs? 20:19:47 adamw, you mentioned systemd bug 630225 20:19:49 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=630225 medium, low, ---, lpoetter, MODIFIED, Service network isn't started on boot 20:20:28 it's not really a blocker per se (it only affects the network service and you can start it *after* boot) 20:20:42 ok 20:20:55 but there's a reasonable argument that systemd 10 shouldn't go stable till it's fixed, as it's a regression in systemd 9 and 10 vs 8 20:21:00 so it indirectly affects our release 20:22:31 i'll try and check in with lennart on that one 20:22:39 #action adamw to check in with lennart on 630225 20:23:53 i think that should do it... 20:25:11 thanks for coming, everyone 20:25:17 oh, hey 20:25:20 * adamw missed bpepple 20:25:36 #topic https://bugzilla.redhat.com/show_bug.cgi?id=633523 20:25:37 Bug 633523: medium, high, ---, bdpepple, ASSIGNED, Dependency issue block empathy installs in F14 20:26:04 bpepple: this is a simple one, i think, just looks like empathy needs to be rebuilt - we just needed to make sure you know it needs fixing asap (probably tomorrow) as it's a beta blocker, and submitting to bodhi immediately 20:26:27 adamw: yeah, I saw it. I can rebuild it, but it would be preferrable to update it to the latest version since there are some nasty bugs in that version of empathy. 20:26:42 unfortunately, I'm being held up by the whole vala/folks crap. 20:27:10 bpepple: if you can get the version bump done by tomorrow we can take it, but otherwise can you just push a rebuild for now? 20:28:35 adamw: yeah, I'll see if I can get some of the rel-eng team to move vala & folks into the buildroot tonight. 20:28:59 otherwise I'll just rebuild the current version and brace myself for the flurry of bugreports. ;-) 20:29:04 =) 20:29:09 thanks a lot 20:29:30 #action bpepple will try to get an empathy version bump done, if this isn't possible he will do a rebuild for tomorrow 20:29:47 was that camel/evo soname change ever announced on the lists. It would have been great to got a heads up. 20:29:56 i'm not sure 20:30:09 evo's been changing sonames a lot in development 20:30:28 at a quick search through -devel i don't see one 20:30:57 * jsmith figures out how to hang OpenOffice on an F13 box :-( 20:31:14 use it for five minutes? 20:31:24 thank you, thank you, i'm here all week. tip your server 20:31:25 lol 20:31:39 bada boom! 20:31:45 okay, that really is the end, i think =) 20:32:23 thanks again everyone 20:32:38 #endmeeting