17:10:51 <kparal> #startmeeting Fedora QA meeting 17:10:51 <zodbot> Meeting started Mon Nov 12 17:10:51 2012 UTC. The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:10:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:11:01 <Viking-Ice> or let's just skip this since you are so buys 17:11:02 <Viking-Ice> busy 17:11:11 <kparal> #meetingname fedora-qa 17:11:11 <zodbot> The meeting name has been set to 'fedora-qa' 17:11:25 <kparal> #topic Mini-blocker review 17:11:34 <tflink> chair? 17:11:41 <kparal> #chair tflink 17:11:41 <zodbot> Current chairs: kparal tflink 17:11:43 <tflink> thanks 17:12:03 * tflink hopes to get this done quick, has a fedup patch to test 17:12:05 <tflink> #topic (875364) Both 18 Beta TC8 install DVDs are > 4.7 GB 17:12:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875364 17:12:06 <tflink> #info Proposed Blocker, distribution, NEW 17:12:49 <kparal> " The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements " 17:12:59 <kparal> +1 blocker 17:13:24 <robatino> +1 blocker 17:13:54 <robatino> mrbatavia: sorry for the confusion, a meeting just resumed in this channel. it should be over soon and we can resume 17:13:56 <tflink> proposed #agreed 875364 - AcceptedBlocker - Violates the following F18 beta release criterion: "#topic (875364) Both 18 Beta TC8 install DVDs are > 4.7 GB 17:13:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875364 17:14:00 <tflink> whoops 17:14:03 <tflink> #info Proposed Blocker, distribution, NEW 17:14:05 <tflink> #undo 17:14:05 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x3555f90> 17:14:08 <tflink> #undo 17:14:08 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x47ebc2d0> 17:14:10 <mrbatavia> robatino: ok 17:14:35 <tflink> proposed #agreed 875364 - AcceptedBlocker - Violates the following F18 beta release criterion: "#topic (875364) Both 18 Beta TC8 install DVDs are > 4.7 GB 17:14:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875364 17:14:40 <tflink> #info Proposed Blocker, distribution, NEW 17:14:41 <tflink> #undo 17:14:41 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x4d25f690> 17:14:42 <tflink> #undo 17:14:43 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x16acb050> 17:14:45 <tflink> WTF? 17:15:01 <tflink> proposed #agreed 875364 - AcceptedBlocker - Violates the following F18 beta release criterion: "The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements" 17:15:16 <tflink> ack/nak/patch? 17:15:24 <kparal> ack 17:15:25 <mkrizek> ack 17:15:36 <robatino> ack 17:15:36 <nanonyme> ack 17:15:40 <tflink> #agreed 875364 - AcceptedBlocker - Violates the following F18 beta release criterion: "The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements" 17:15:50 <tflink> #topic (810040) F17/F18 xen/kvm/vmware/hyperv guest won't start gnome-shell if fprintd is present 17:15:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=810040 17:15:55 <tflink> #info Proposed Blocker, gnome-shell, ASSIGNED 17:17:34 <kparal> Viking-Ice: you say it affects all virt technologies, but I've never seen it. does it affect it only under specific circumstances? 17:17:34 <tflink> I'm a little confused about this - is this an F18 bug? 17:17:54 <kparal> it started as F17 bug and then found in F18 as well 17:18:10 <Viking-Ice> have you tried it on xen 17:18:40 * jreznik never saw that either, on kvm 17:18:41 <Viking-Ice> and this affects all other virtualization technologies 17:18:44 <kparal> Viking-Ice: no, I use KVM. but you say it affects KVM either 17:18:44 <tflink> xen issues don't generally block beta 17:19:20 <jreznik> Viking-Ice: all? 17:19:50 <tflink> is the problem that gnome shell won't start in a VM if there are missing deps on the virthost? 17:20:54 <jlk> also could it be SPICE vs VNC ? 17:20:55 <tflink> no, that's not it 17:21:11 <Viking-Ice> a bit more info on 828166 17:21:33 <tflink> jlk: it affects vbox and hyperv, though. I doubt that it's a VNC/Spice issue unless I'm misunderstanding something 17:21:42 <jlk> ah 17:21:44 <Viking-Ice> usb related 17:22:29 * jreznik is pinging halfline 17:22:29 <kparal> so this happens if I remove USB bus from my VM? 17:22:32 * jlk backs away 17:22:51 <jreznik> halfline: hi 17:22:55 <halfline> hello 17:22:58 <Viking-Ice> hm seems to be fixed upstream 17:23:21 <tflink> ok, so the short version is that neither gnome-shell nor gdm will start if there is no USB bus in the VM and fprintd is installed 17:23:24 <jreznik> halfline: what's the status of 810040? 17:23:41 <Viking-Ice> status in F18 17:23:48 * jreznik saw you upstream commit... 17:24:21 <halfline> hmm 17:24:52 <halfline> i only vaguely remember this issue 17:24:55 <halfline> one moment 17:26:56 <halfline> so i guess what must be going on is 17:27:21 <halfline> we try to talk to fprintd, but fprintd isn't running 17:27:25 <halfline> dbus tries to activate fprintd 17:27:37 <halfline> and then it exits before taking a name on the bus 17:27:42 <halfline> something like that 17:28:04 <halfline> since it never takes a name on the bus, the dbus activation never finishes, and it (I suppose) times out after the default 20 seconds 17:28:29 <halfline> maybe that 20 seconds is longer than gnome-session is willing to wait for gnome-shell to proceed and then fail whale? 17:28:33 <halfline> just a theory 17:28:37 <halfline> will need to investigate 17:28:53 <kparal> why does only someone see it? 17:29:00 <kparal> never happened in my VM 17:29:10 <jreznik> halfline: we are trying to understand impact now, how it's related to virt. machines... I haven't seen it on kvm 17:29:21 <tflink> kparal: sounds like the USB bus issue - if you create a VM w/o a USB bus, you'd hit this 17:29:29 <jreznik> kparal: same here but seems it happens... but probably very limited 17:29:33 <halfline> kparal: do you run qemu-kvm manually ? 17:29:43 <kparal> halfline: no, virt-manager 17:29:44 <tflink> creating a default VM in VMM or with virt-install will create a USB bus by default 17:29:54 <kparal> can somebody check whether it affects default VM in VirtualBox? 17:29:55 <tflink> at least, that's how I'm reading this 17:30:01 <halfline> kparal: so virt-manager probably sets up the needed guest device to prevent fprintd from tanking 17:30:16 <halfline> i doubt this affects anyone but people who run qemu manually 17:30:36 <tflink> sounds like several hyperv and esx users are affected as well 17:30:44 <Viking-Ice> along with virtualbox 17:30:50 <jreznik> tflink: well, then i'ts vm misconfiguration? it definitely should not cause this issue but seems like very limited impact 17:30:52 * satellit virtualbox 4.2.4 works do not see it 17:31:03 <kparal> satellit: thanks 17:31:03 <Viking-Ice> the workaround is all over the internet remove fprint 17:31:07 <halfline> let me just look in the fprintd code really quick 17:31:09 <jlk> sounds like it could probably be worked around, but isn't a show stopping bug 17:31:18 <jlk> s/could/should/ 17:31:26 <tflink> yeah, I'm leaning towards -1/-1 ATM 17:31:45 <Viking-Ice> jlk it seems to prevent users from running vm as an guest in *all* virtualsolutions 17:32:07 <Viking-Ice> mean running fedora as an vm guest and 17:32:25 <jlk> aren't we seeing people here say that virtmanager started guests are fine, as are virtualbox 4.2.4? 17:32:43 <tflink> I read it as, it prevents gdm and/or shell from running in VMs with a specific, non-default configuration. seems to be hypervisor agnostic 17:32:54 <kparal> I think this mainly affects enterprise solutions, like cloud services etc, right? home users don't start VMs without USB 17:33:13 <tflink> and I suspect that few cloud users need gdm or shell 17:33:32 <kparal> good point 17:33:42 <halfline> so the issue is this code: 17:33:51 <halfline> → r = fp_init();• │~ 17:33:51 <halfline> → if (r < 0) {• │~ 17:33:51 <halfline> → → g_warning("fprint init failed with error %d\n", r);• │~ 17:33:51 <halfline> → → return r;• │~ 17:33:55 <halfline> → }• 17:33:57 <halfline> where fp_init has: 17:34:03 <halfline> → r = libusb_init(&fpi_usb_ctx);• 17:34:04 <halfline> → if (r < 0)• 17:34:04 <halfline> → → return r;• 17:34:05 <Viking-Ice> tflink, what makes you think this is only cloud releated ? 17:34:07 <kparal> I think we should either punt and ask cloud SIG for feedback, or give it -1 Beta blocker, +1 Final blocker, and maybe +1 Beta NTH 17:34:18 <Viking-Ice> I'm +1 nth 17:34:24 <tflink> Viking-Ice: when did I say it was only cloud related? 17:34:29 <halfline> the fix is probably to fp_init after taking a name on the bus 17:34:35 <halfline> would be good to pull hadess into this discussion 17:34:37 <Viking-Ice> tflink, sorry not you kparal 17:34:39 <halfline> since he's the fprintd guy 17:34:57 <jlk> halfline: that's getting far into the "how do we fix it" rabbit hole. 17:35:08 <jlk> halfline: this meeting is mostly concerned with impact, and whether the bug should block Beta or not 17:35:48 <tflink> #info this is an issue with VMs not being able to start gdm and/or gnome shell if fprind is installed in the guest and the VM has no USB bus 17:36:04 <jlk> I'm -1 blocker. 17:36:06 * jreznik is -1 beta blocker 17:36:19 <halfline> i'd say -1 to beta blocker, but the fix is probably a simple as http://paste.stg.fedoraproject.org/1678 17:36:25 * tflink is -1 beta blocker, too 17:36:26 <jreznik> but would be nice to have it fixed by final as it's long term issue 17:36:55 <Viking-Ice> nth status since this might affect everyone that try to run Fedora beta as an guest in vm ? 17:37:01 <jreznik> halfline: how confident are you with the fix? 17:37:42 <jreznik> Viking-Ice: might affect everyone but seems it affects only a few people... but it's long standing one 17:37:45 <tflink> I'm still -1 NTH unless I'm misunderstanding something here. I don't think this affects enough users to take past freeze for beta. final, probably. beta? not so sure since this could arguably be fixed with an update 17:38:19 <halfline> jreznik: not confident at all. reading it over I see i made a mistake in it 17:38:36 <jreznik> halfline: ok, then I'm -1 NTH 17:38:53 <Viking-Ice> but dualbooting is fine as a blocker lol 17:38:54 <jreznik> as it's closely related to login and gdm... 17:39:33 <jlk> Viking-Ice: I'm not convinced this hits "every vm user" 17:39:34 <tflink> Viking-Ice: I suspect that there are more people dualbooting than running gdm in a VM w/o USB and it's a lot harder to fix dualbooting issues with an update (if it's even possible) 17:40:06 <tflink> other NTH votes? 17:40:12 <Viking-Ice> tflink, you cant fix this so easally with an update if the UI crashes 17:40:19 <kparal> if there is a large deployment service that uses F18 Beta, it probably installs from network, and this can be fixed with an update 17:40:25 <tflink> Viking-Ice: boot into single mode, run 'yum update' 17:40:33 <Viking-Ice> at least we cant release final with the bug in place since we dont update the GA release 17:40:40 <jreznik> yep, definitely not -1 blocker, -1 nth but would be nice to have fix by final... 17:40:51 <Viking-Ice> tflink, yeah so many users that want try fedora know how do to that 17:41:13 <tflink> Viking-Ice: again, I sincerely doubt that many people trying fedora are running gdm and VMs w/o USB 17:41:28 <kparal> Viking-Ice: I really don't believe too many users run VMs without USB and don't know how to update the machine 17:41:31 <jreznik> tflink: yep, move on I'd say with bug resolution 17:41:51 <halfline> jreznik: more confident about this one: http://paste.stg.fedoraproject.org/1679 17:42:06 <halfline> i'll move the bug to fprintd 17:42:21 <Viking-Ice> halfline, great thanks 17:42:30 <jreznik> halfline: ok, thanks! comment it in the bug 17:43:08 <tflink> proposed #agreed 810040 - RejectedBlocker, RejectedNTH - This only affects graphical installs in VMs without a USB bus. It seems uncommon enough to not warrant blocker or NTH status for F18 beta. Please re-propose as final NTH/blocker for reconsideration if this is not fixed otherwise by then. 17:43:23 <jreznik> ack 17:43:23 <tflink> ack/nak/patch? 17:43:33 <Viking-Ice> ack 17:44:15 <kparal> ack 17:45:08 <tflink> #agreed 810040 - RejectedBlocker, RejectedNTH - This only affects graphical installs in VMs without a USB bus. It seems uncommon enough to not warrant blocker or NTH status for F18 beta. Please re-propose as final NTH/blocker for reconsideration if this is not fixed otherwise by then. 17:45:16 <tflink> #topic (875380) fileconflicts failure on 18 Beta TC8 DVDs (texlive) 17:45:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875380 17:45:17 <tflink> #info Proposed Blocker, texlive, NEW 17:45:45 * nirik notes these should be fixed tomorrow/next compose. 17:45:55 <tflink> is texlive on the DVD? 17:46:18 <nirik> some parts of it are. 17:46:38 <tflink> seems like a pretty clear blocker, then 17:46:38 <nirik> they had those other packages blocked, but only in rawhide. They had to be blocked in f18 as well 17:47:05 <tflink> proposed #agreed 875380 - AcceptedBlocker - Violates the following F18 alpha release criterion: "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:47:11 <nirik> ack 17:47:16 <Viking-Ice> ack 17:47:17 <kparal> ack 17:47:20 <jreznik> ack 17:47:27 <tflink> #agreed 875380 - AcceptedBlocker - Violates the following F18 alpha release criterion: "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:47:30 <jreznik> thanks nirik for a quick fix :) 17:47:39 <tflink> OK, I think that's all of the proposed blockers 17:48:51 <tflink> If there's nothing else, I think that we can move on to ... 17:48:55 <tflink> #topic Open Floor 17:49:16 <satellit_e> https://bugzilla.redhat.com/show_bug.cgi?id=875393#c20 17:50:40 <Viking-Ice> satellit_e, what do you want us to do with this bug? 17:50:44 <kparal> satellit_e: does it mean it's enough to have network cable unplugged and anaconda crashes immediately on start? 17:50:45 <tflink> satellit_e: I think that has been fixed in git, should be in the next anaconda build? 17:50:49 <zodbot> Ticket notification - commonbugsrss: [Bug 875003] after setting invalid installation source, "closest mirror" is broken <https://bugzilla.redhat.com/show_bug.cgi?id=875003> 17:51:07 <tflink> yeah, should be in the next anaconda build 17:51:22 <satellit> it changed in last few anacondas work ok before 17:51:59 <satellit> thanks 17:52:14 <tflink> anything else? 17:52:27 <Viking-Ice> not from me 17:52:49 <tflink> I mentioned this before, but if you're going to test fedup, please read this wiki page: https://fedoraproject.org/wiki/QA%3AFedora_18_Upgrade_Testing 17:52:58 <tflink> it should be up to date 17:52:59 <satellit> kparal: yes 17:54:17 <tflink> unless there is anything else ... 17:54:20 <kparal> I think it could be a blocker, but let's leave it to Thursday 17:54:56 * kparal sets fuse to 1 minute 17:55:09 * tflink runs away 17:55:27 * kparal hits the button 17:55:46 <kparal> thanks everyone 17:55:49 <kparal> #endmeeting