fedora-bugzappers
LOGS
18:05:56 <adamw> #startmeeting interim beta blocker bug review meeting 2010-09-14
18:05:56 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:06:03 <adamw> #intro
18:06:07 <adamw> #topic intro
18:06:21 <adamw> 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 <adamw> 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 <adamw> list we're working from: https://bugzilla.redhat.com/showdependencytree.cgi?id=611991&hide_resolved=1
18:07:23 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=608992
18:07:24 <buggbot> Bug 608992: medium, low, ---, dhuff, MODIFIED, Add "Boot system with basic video driver" option at the initial screen
18:07:40 <adamw> 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 <adamw> 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 <adamw> 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 <buggbot> Bug 633827: medium, low, ---, bcl, NEW, liveinst needs to pass --xdriver=* to anaconda when xdriver=* is in /proc/cmdline
18:11:05 <adamw> bcl said the fix 'shouldn't be hard to add', so that sounds positive.
18:11:23 <adamw> any notes on this one?
18:13:19 <adamw> ok, next
18:13:38 <adamw> 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 <adamw> #agreed 633827 adamw will test bcl's proposed fix and feed back to him
18:14:04 <adamw> #action adamw to test bcl fix for 633827
18:14:15 <notting> sorry, was grabbing some food & running errands
18:14:29 <adamw> no problem, we just got started, just about to start the second bug
18:14:49 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027
18:14:50 <buggbot> Bug 621027: medium, low, ---, tcallawa, ON_QA, Graphical screen in anaconda shows F-13
18:15:16 <adamw> so this is the bug for adding f14 branded images/logos
18:15:28 <adamw> we now have a proposed fix for this, which does put a proper branded graphic in anaconda
18:16:02 <adamw> 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 <adamw> anyone have any ideas on this one?
18:18:16 <jlaska> mizmo is offering 2 differenti mages for me to test
18:18:23 <jlaska> I'll try those out and see if that works better
18:18:49 <adamw> awesome, thanks
18:19:08 <adamw> #agreed 621027 fix is in but problem with live image bootloader background, jlaska to test potential fix from mizmo
18:19:09 <notting> is it a gray version of the logo, or just plain gray?
18:19:16 <adamw> #action jlaska to test 621027 fixes from mizmo
18:19:22 <adamw> notting: plain grey, as if it's a fallback for a missing image
18:21:12 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=622927
18:21:13 <buggbot> Bug 622927: medium, low, ---, rvykydal, MODIFIED, F14 Alpha RC2 - /etc/resolv.conf gets corrupted, cannot download packages
18:21:45 <adamw> this looks like it should be testable in TC1
18:21:53 <adamw> so we should just be able to ask orion to test TC1, confirm it's fixed, and close it off
18:22:49 <adamw> anything else on this?
18:23:50 <adamw> ok
18:24:01 <adamw> #agreed 622927 ask tester to verify fix in TC1 and close the bug
18:24:33 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627014
18:24:34 <buggbot> Bug 627014: high, low, ---, lpoetter, MODIFIED, systemd provided telinit does not work as advertised
18:25:26 <adamw> 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 <michich> yes, systemd-10 fixes it
18:26:46 <adamw> thanks michich
18:27:22 <adamw> only problem is that systemd-10 will be held up in bodhi until the network service regression is fixed
18:27:47 <notting> adamw: last i checked it was submitted to stable via karma
18:28:26 * adamw checks
18:29:02 <adamw> owch. that shouldn't have happened :/ need...bodhi...2.0...
18:29:27 <adamw> well, anyway, we can talk about it when we hit the network bug (630225)
18:30:15 <adamw> #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 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=627401
18:30:34 <buggbot> 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 <adamw> this is fixed in anaconda 14.17.1-1, confirmed by me (and others)
18:31:36 <jlaska> add me to the +1 confirm list :)
18:32:25 <michich> not in Bodhi yet?
18:32:31 <adamw> 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 <adamw> #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 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=628239
18:34:27 <buggbot> Bug 628239: medium, low, ---, bcl, NEW, Fedora 14 Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't blacklist nouveau
18:35:03 <adamw> i'm fairly sure this isn't valid as described
18:35:26 <adamw> 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 <dlehman> adamw: yeah, I'll probably be rebuilding this evening anyway so I'll just do the one update
18:35:58 <adamw> 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 <adamw> dlehman: cool, that works
18:36:40 <adamw> 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 <bcl> I tried to reproduce it here and it works fine for me.
18:37:41 <adamw> ok
18:37:59 <adamw> so yeah, for now i'd say let's not worry about this and wait for the reporter
18:38:30 <bcl> original report was with Alpha, so it likely got fixed by some other change.
18:38:34 <adamw> #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 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=628241
18:39:39 <buggbot> Bug 628241: urgent, low, ---, mgracik, ON_QA, Fedora 14 Alpha, post reboot installation steps not working
18:40:07 <adamw> this is fixed in firstboot-1.113-1.fc14 , i've tested it.
18:40:24 <notting> is that in stable yet?
18:41:20 <adamw> nope, needs pushing, it has necessary karma though
18:41:31 <adamw> https://admin.fedoraproject.org/updates/firstboot-1.113-1.fc14 - i posted a comment asking mgracik to push it
18:43:01 <adamw> if you can push it for him that'd get one thing off our tracking list
18:43:58 <notting> stable push wouldn't be until tonight anyway
18:44:01 <adamw> ok
18:44:17 <adamw> #agreed 628241 is fixed in firstboot-1.113-1, needs to be pushed stable
18:44:30 <adamw> #action mgracik or notting to push firstboot-1.113-1 stable
18:44:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=629719
18:44:41 <buggbot> Bug 629719: medium, medium, ---, anaconda-maint-list, NEW, FormatCreateError: ('invalid device specification', '/dev/md127p3')
18:44:55 <adamw> this one is a bit sticky
18:45:18 <adamw> we have one reporter, dlehman thinks he's doing something other than what he's claiming in the report
18:45:28 <adamw> ben boeckel says he hit the same bug, but on a system he can no longer poke
18:45:32 <dlehman> the other reporter didn't provide logs
18:45:44 <adamw> 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 <adamw> 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 <notting> why would you be installing onto 127 raid devices?
18:47:16 <dlehman> the fwraid device starts with three partitions
18:47:47 <adamw> notting: i doubt they are, i imagine the enumeration is some kind of quirk
18:48:08 <dlehman> 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 <dlehman> notting: it's something about mdadm and incremental assembly starting at 127 and going backwards to avoid collisions
18:49:23 <adamw> there *could* be other causes of that, though, right? some kind of bug which causes the device to disappear...
18:49:27 <notting> *boggle*
18:49:43 <dlehman> 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 <dlehman> 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 <adamw> not necessarily an anaconda bug
18:50:39 <adamw> perhaps something the kernel is screwing up
18:51:35 <adamw> 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 <adamw> 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 <dlehman> 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 <adamw> well, we do have the log from the second attempt in this case
18:53:57 <dlehman> or, as you mentioned earlier, a user uploading a log from a previous attempt as if it were from the latest
18:54:40 <adamw> right, but i asked about that and it doesn't seem to be what happened...
18:54:50 <adamw> jlaska: do we have hardware somewhere to do some RAID tests and see if we can hit this?
18:55:02 <adamw> jlaska: try and replicate the partition layouts sandro and ben used?
18:55:15 <jlaska> sorry, distracted ...
18:55:19 <jlaska> HW or BIOS raid?
18:55:30 <jlaska> this is BIOS RAID iirc, right?
18:55:30 <dlehman> 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 <dlehman> yes
18:56:52 <dlehman> isw raid
18:57:26 <jlaska> I've not had any problems with my standard BIOS RAID tests ... but it doesn't cover a lot of hardware
18:57:49 <adamw> jlaska: might be worth trying to use the partition layouts mentioned in the bug
18:58:11 <jlaska> I can try that ... but I suspect my setup is sufficiently different already
18:58:27 <jlaska> my devices are always named completely differently ...
18:58:28 <jlaska> e.g ...
18:58:48 <jlaska> ... nvidia_dbebefgap1
18:59:02 <adamw> ah, isw is intel
18:59:05 <adamw> so yeah, different...
18:59:17 <adamw> might you have a machine with intel bios raid lying around?
18:59:29 <jlaska> lying around no :(
18:59:43 <jlaska> I can put some calls out, but we're not going to get test feedback in the desired time frame
18:59:48 <adamw> ok
18:59:58 <jlaska> any hints as to whether this is device specific vs partition specific?
19:00:21 <adamw> 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 <jlaska> Should I put a call out to test@l.fp.org for anyone with Intel BIOS RAID?
19:00:33 <adamw> they weren't using exactly the same config: sandro has four disks, ben had two
19:01:17 <adamw> yeah, we can put out an ml call
19:01:25 <adamw> and maybe try and get sandro to try it one more time
19:01:47 <jlaska> the debate here seems to be how common this failure is, is that right?
19:01:48 <adamw> 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 <jlaska> the ol' hardware/site_config specific vs generic bug issue
19:02:05 <adamw> jlaska: well, how common, and whether it actually happens without the user doing something they shouldn't
19:02:11 <jlaska> right
19:02:21 <adamw> (poking the raid config in a console during install, which we very definitely don't support)
19:03:08 <adamw> does that action plan sound okay?
19:03:17 <dlehman> 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 <adamw> fair enough
19:03:45 <jlaska> 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 <dlehman> iow, I already looked for another explanation and found none
19:03:52 <jlaska> slip vs demote bug?
19:04:08 <adamw> given the above i'd say fallback plan is demote it
19:04:13 <adamw> if no-one else reports the same issue
19:04:57 <dlehman> that'd be my choice
19:05:08 <jlaska> adamw: found someone with matching hardware ... will see what we can uncover
19:05:15 <jlaska> I 3rd that choice
19:05:28 <adamw> ok, cool
19:05:35 <jlaska> 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 <adamw> #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 <adamw> grr
19:06:14 <adamw> #undo
19:06:14 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x2b7d36db4cd0>
19:06:20 <adamw> #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 <adamw> #action adamw or jlaska to send out ml testing call for 629719
19:06:55 <jlaska> adamw: I'll do that now
19:06:58 <adamw> cool thanks
19:07:00 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=630490
19:07:01 <buggbot> Bug 630490: medium, low, ---, lpoetter, ASSIGNED, disabled units still get bus activated
19:07:45 <michich> fixed in systemd-10
19:08:55 <adamw> notting: you're definitely okay with this one now?
19:09:08 <notting> i still think the nmcli behavior is wrong
19:09:24 <notting> but that can be tracked in the nm bug
19:09:29 <adamw> OK
19:09:50 <adamw> #agreed 630490 testing indicates this is fixed in systemd-10, can be closed when that goes stable
19:10:32 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=630952
19:10:33 <buggbot> Bug 630952: urgent, low, ---, notting, MODIFIED, Does not enable the prefdm and rc-local services
19:10:51 <notting> this is fixed in the systemd/initscripts/etc. update
19:12:08 <adamw> yeah, my test live image with these updated packages boots and installs fine
19:12:14 <adamw> another we can close when the update goes stable
19:12:35 <adamw> #agreed testing indicates 630952 fix is good, bug can be closed when systemd/initscripts update goes stable
19:12:58 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=631620
19:12:59 <buggbot> Bug 631620: medium, low, ---, lpoetter, ON_QA, ordering cycles exist (+ breaking them deletes wrong services)
19:13:32 <adamw> notting: are you happy with the fix for this?
19:13:45 <notting> well, he fixed it by dropping it from being a sysv service
19:13:51 <notting> which works
19:13:52 <adamw> 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 <notting> something probably poked it
19:14:44 <adamw> 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 <adamw> 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 <notting> not really. there may, of course, be other dependency loops that cause problems later
19:16:37 <adamw> right, but that's an unknown unknown =)
19:16:42 <adamw> (Thank you Dick!)
19:17:07 <adamw> anyone else want to jump in on this one?
19:18:14 <adamw> ok
19:18:26 <adamw> #agreed 631620 fix looks good in all important respects, can be closed when hal update is pushed
19:18:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632321
19:18:48 <buggbot> Bug 632321: medium, low, ---, notting, MODIFIED, claims to start ypbind, but doesn't
19:19:19 <adamw> i'm rather unfamiliar with this...bill, have you tested the fix?
19:19:28 <notting> there's a fix?
19:19:34 <notting> oh
19:19:44 <notting> sorry, there are two bugs with this title
19:19:55 <notting> yes, this particular issue is fixed. ypbind's then failing due to something else layter
19:20:12 <adamw> i just tried it and got 'Sep 14 20:19:39 vaioz ypbind: domain not found'
19:20:32 <adamw> but i don't really know what ypbind is/does, so =)
19:21:01 <adamw> notting: which is the other bug? doesn't seem to be on the blocker list
19:21:22 <notting> 632620
19:22:59 <adamw> ok
19:23:12 <adamw> 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 <adamw> 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 <notting> well, the first one was ypbind failing in all cases
19:24:06 <notting> the second bug is ypbind failing iff you're using the network service and dhcp
19:24:22 <adamw> ah, so yeah, that's a lot tighter
19:24:24 <notting> ypbind is an auth mechanism. NIS.
19:24:55 <adamw> ah, k. so if your network uses NIS, you need it.
19:25:47 <adamw> 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 <jlaska> do we have a reasonable workaround?
19:26:46 <adamw> 'use NetworkManager', presumably
19:27:11 <adamw> (or 'use static addressing')
19:27:17 <adamw> any others, bill?
19:28:10 <michich> rm /etc/dhcp/dhclient.d/nis.sh ?
19:28:18 <notting> that would also work
19:28:29 <adamw> sounds like we're just overflowing with reasonable workarounds :P
19:28:55 <jlaska> 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 <adamw> it's not on the list, actually
19:29:05 <notting> jlaska: it wasn't on the list
19:29:07 <adamw> but since it came up it seemed wise to consider whether it should be
19:29:21 <jlaska> apologies, that's what I get for being in 2 places at once
19:29:29 <adamw> so, for 632321 the fix is in, and we're comfortable with not adding 632620 to the list
19:29:40 <adamw> #agreed 632321 is fixed in systemd 10, can be closed when it goes stable
19:29:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632489
19:29:52 <buggbot> Bug 632489: medium, low, ---, rvykydal, MODIFIED, Fail to read package metadata after specifying repo=
19:30:19 <adamw> this one looks straightforward, a fix has been tested in an updates.img and will be in next anaconda build
19:30:28 <notting> (note: fesco. paying a little less attention now)
19:30:54 <adamw> notting: we're nearly done now
19:31:12 <adamw> only 4 more to go
19:31:19 <adamw> any wrinkles on 632489 or shall we move on?
19:32:00 <jlaska> seems in good shape
19:32:06 <jlaska> just pending a new build, right?
19:32:09 <adamw> yup
19:32:20 <adamw> #agreed 632489 fix has been tested in updates.img, next anaconda build will include it
19:32:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=632510
19:32:41 <buggbot> Bug 632510: medium, low, ---, clumens, MODIFIED, Installer exited abnormally when starting network in rescue mode
19:33:28 <adamw> looks like there'll be a fix for this in next anaconda
19:33:33 <adamw> next action should be for us to test it i guess
19:33:41 <jlaska> yeah, I see the commit in the correct f14-beta-branch in git
19:33:53 <adamw> of course we'd need a build to do that
19:34:52 <jlaska> right on
19:35:19 <adamw> 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 <adamw> jlaska: wdyt?
19:35:52 <adamw> i'm probably okay doing it in rc1
19:36:13 <jlaska> hrmm ...
19:36:46 <jlaska> 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 <jlaska> 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 <adamw> jlaska: aha! awesome
19:37:41 <jlaska> I was hoping he wouldn't see it :) ... any news is good news though
19:37:56 <adamw> #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 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=633234
19:38:06 <buggbot> Bug 633234: medium, low, ---, bcl, NEW, Previous grub entry is not overwritten after upgrade with creating new bootloader
19:38:35 <adamw> this is a new one, we hadn't considered its blockeriness yet
19:38:47 * jlaska loves that "word" :)
19:38:50 <dlehman> no news yet on this one. top of bcl's list
19:38:52 <adamw> it does seem like a blocker under the criteria
19:39:19 <jlaska> dlehman: bdonahue retested and it seems the problem went away upon the 2nd attempt
19:39:27 <jlaska> won't hijack meeting for this off-topic ... but just fyi
19:39:27 <dlehman> weird
19:39:51 * adamw has his money on some kind of intermittent kernel issue with the raid controller, but eh
19:40:03 <adamw> votes on blockeriness of 633234?
19:41:04 <dlehman> if it is easily reproducible, seems pretty blockerish
19:41:36 <adamw> looks pretty straightforward from the report, i wouldn't expect hurry to screw anything up
19:41:44 <adamw> and i can't really see how it'd be configuration-specific
19:42:01 <adamw> maybe if bcl can't reproduce it we would have to look harder at that
19:43:42 <adamw> jlaska: blocker yay or nay?
19:44:46 <jlaska> hrmmm
19:45:09 <jlaska> I don't know if the outcome differs whether you choose to update/skip/new bootloader when upgrading
19:45:36 <adamw> from the report it's specific to the 'new bootloader' case
19:45:44 <jlaska> ah okay
19:45:49 <jlaska> I'd support including this as a blocker
19:46:05 <jlaska> only cause I can see the preupgrade reports coming in that the installer constantly keeps booting
19:46:26 <adamw> the skip_bootloader and update_bootloader tests are listed as passes in the tc1 install validation matrix
19:46:29 <jlaska> seems easy to workaround, so if push comes to shove, we can document
19:46:41 <adamw> this one is listed as a failure by newgle1 and rhe (so obviously newgle could reproduce)
19:46:55 <jlaska> 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 <jlaska> so I'd agree w/ dlehman
19:47:11 <adamw> ok
19:47:29 <adamw> #agreed 633234 is a blocker, top priority for anaconda team, it seems reproducible by at least two testers
19:47:37 <adamw> #action anaconda team to try and investigate and fix 633234
19:48:19 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=633315
19:48:20 <buggbot> Bug 633315: medium, low, ---, dcbw, NEW, Connections not editable in nm-c-e in anaconda
19:48:55 <adamw> this is a new proposed blocker
19:48:59 <adamw> it doesn't feel terribly blocker-y to me
19:49:49 <adamw> 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 <poelcat> adamw: if you entered the wrong information on accident?
19:51:09 * poelcat is here now BTW :)
19:51:32 <adamw> 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 <adamw> so i'm a bit unsure about the impact
19:52:24 <poelcat> don't know
19:54:33 <adamw> dlehman: any idea?
19:54:38 <adamw> radek doesn't seem to be around
19:56:14 <dlehman> hmm, not sure why you'd need to edit the connection you used to get stage2
19:57:33 <adamw> yeah, that's my thought - if you're there, you must have a connection that's working...
19:57:37 <adamw> ...or not need one
19:57:48 <dlehman> seems like a bug, but not a blocker, to me
19:58:00 <adamw> unless i guess you're using boot.iso, which has stage2 but uses network to get packages?
19:58:12 <adamw> but then don't you get to configure the network earlier in that case?
20:00:42 <adamw> 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 <jlaska> seems like something to address post-beta, right
20:01:06 <jlaska> wouldn't want it to slip off the radar
20:01:23 * jlaska ergh ... need to step away ...
20:02:05 <adamw> we're nearly done\
20:02:24 <adamw> #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 <adamw> 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 <jlaska> well, I'd like to avoid another release where we can't properly configure the installed systems networking
20:04:07 <poelcat> what does the release criteria say?
20:04:09 <adamw> i meant not a nice-to-have for beta, fixing it after beta would probably be fine
20:04:11 <poelcat> around this topic?
20:04:17 <jlaska> adamw: oh right
20:04:26 <adamw> poelcat: it says you need to be able to do a network install. afaict, this bug doesn't impact that.
20:05:48 <poelcat> next bug?
20:06:33 <adamw> yup
20:06:42 <adamw> last bug!
20:06:45 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=633523
20:06:46 <buggbot> Bug 633523: medium, high, ---, bdpepple, NEW, Dependency issue block empathy installs in F14
20:06:57 <adamw> this is an obvious blocker as it breaks live image compose
20:07:04 <adamw> and regular image compose
20:07:08 <adamw> and all composes and default installs, really. =)
20:07:49 <poelcat> is bpepple around in #fedora-devel?
20:08:29 <adamw> he's marked as idle, we can ping him
20:08:55 <poelcat> i did
20:09:19 <adamw> 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 <poelcat> go for it
20:10:32 <adamw> ok
20:10:49 <adamw> so...i'd say this is an accepted blocker, we cc mclasen on the bug and ask for a rebuild asap
20:10:52 <adamw> ack?
20:10:54 <poelcat> ack
20:12:09 <adamw> okay, that's the list
20:12:29 <adamw> 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 <adamw> we have priorities for everyone now i think
20:12:51 <adamw> #agreed 633523 is an accepted blocker, we cc mclasen on the bug and ask for a rebuild asap
20:12:57 <adamw> #topic open floor
20:13:13 <poelcat> someone asked me to propose this bug https://bugzilla.redhat.com/show_bug.cgi?id=528232
20:13:15 <buggbot> Bug 528232: medium, high, ---, kernel-maint, NEW, Hang with EFI booting on iMac and Macbook Pro 6.2
20:13:26 <poelcat> i think it is disqualified under #4 of the beta release criteria
20:13:41 <poelcat> for being a blocker
20:14:01 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=528232
20:14:02 <buggbot> Bug 528232: medium, high, ---, kernel-maint, NEW, Hang with EFI booting on iMac and Macbook Pro 6.2
20:14:08 <bcl> Oh, that's a bummer. IIRC Apple has actually fixed EFI in the newer macs.
20:14:37 <adamw> on the existing criteria it's obviously not a blocker
20:14:45 <adamw> though it does seem we should periodically review that exception
20:15:25 <poelcat> adamw: what about for Final?
20:15:37 <adamw> the exception isn't overridden in final
20:15:41 <adamw> and final inherits the beta criteria
20:15:46 <adamw> so as things stand it's not a final blocker either
20:15:48 <poelcat> http://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria says nothing about EFI
20:16:03 <adamw> right, so since it doesn't directly override the beta criterion, the beta criterion stands for final
20:16:05 <poelcat> okay
20:16:20 <poelcat> i'll update the comments in the bug
20:16:26 <poelcat> in case someone else thinks it should be a blocker
20:17:16 <adamw> bcl: dlehman: any desire to revisit that criterion exception?
20:17:30 <adamw> 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 <bcl> nope.
20:17:34 <adamw> ok
20:18:09 <adamw> #agreed 528232 isn't a blocker, Macs are explicitly excepted from efi criterion in beta criteria
20:18:21 <bcl> 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 <dlehman> 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 <adamw> cool
20:19:35 <adamw> any other bugs?
20:19:47 <michich> adamw, you mentioned systemd bug 630225
20:19:49 <buggbot> 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 <adamw> it's not really a blocker per se (it only affects the network service and you can start it *after* boot)
20:20:42 <michich> ok
20:20:55 <adamw> 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 <adamw> so it indirectly affects our release
20:22:31 <adamw> i'll try and check in with lennart on that one
20:22:39 <adamw> #action adamw to check in with lennart on 630225
20:23:53 <adamw> i think that should do it...
20:25:11 <adamw> thanks for coming, everyone
20:25:17 <adamw> oh, hey
20:25:20 * adamw missed bpepple
20:25:36 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=633523
20:25:37 <buggbot> Bug 633523: medium, high, ---, bdpepple, ASSIGNED, Dependency issue block empathy installs in F14
20:26:04 <adamw> 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 <bpepple> 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 <bpepple> unfortunately, I'm being held up by the whole vala/folks crap.
20:27:10 <adamw> 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 <bpepple> 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 <bpepple> otherwise I'll just rebuild the current version and brace myself for the flurry of bugreports. ;-)
20:29:04 <adamw> =)
20:29:09 <adamw> thanks a lot
20:29:30 <adamw> #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 <bpepple> was that camel/evo soname change ever announced on the lists. It would have been great to got a heads up.
20:29:56 <adamw> i'm not sure
20:30:09 <notting> evo's been changing sonames a lot in development
20:30:28 <adamw> 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 <adamw> use it for five minutes?
20:31:24 <adamw> thank you, thank you, i'm here all week. tip your server
20:31:25 <poelcat> lol
20:31:39 <bcl> bada boom!
20:31:45 <adamw> okay, that really is the end, i think =)
20:32:23 <adamw> thanks again everyone
20:32:38 <adamw> #endmeeting