15:01:31 <adamw> #startmeeting Fedora QA meeting 15:01:31 <zodbot> Meeting started Mon May 14 15:01:31 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:33 <adamw> #meetingname fedora-qa 15:01:33 <zodbot> The meeting name has been set to 'fedora-qa' 15:01:35 <adamw> #topic roll call 15:01:43 * pschindl is here 15:02:00 * satellit_ listening 15:02:15 * tflink is here 15:02:30 <adamw> oh goody, lots of people for blocker fun! 15:02:42 * kparal can't miss it 15:02:53 * jskladan tips his hat 15:03:14 * brunowolff is here 15:03:15 <adamw> how much do you generally tip your hat, anyway? 10%? 15:03:21 * nirik is lurking around 15:03:38 <tflink> adamw: depends on how quickly my hat brings me drinks and food 15:04:25 * maxamillion is here 15:04:55 <adamw> alrighty, let's get going 15:05:28 <adamw> #topic Previous meeting follow-up 15:05:39 <adamw> just the eternal topic on the list, "adamw to check in on Boxes test day once more" 15:05:53 <adamw> it's now set for 2012-05-17 and, who knows, may even happen then., 15:06:07 <kparal> exciting 15:06:11 <maxamillion> exciting indeed 15:06:15 <adamw> now both Duke Nukem Forever and Chinese Democracy exist, I have no idea what to compare it to. =) 15:06:23 <maxamillion> is there a wiki page for that test day? 15:06:36 <tflink> adamw: halflife 2 episode 3 15:06:43 <adamw> ooh, good one. 15:06:47 <maxamillion> equality in america? 15:06:49 <maxamillion> >.> 15:06:50 <adamw> https://fedoraproject.org/wiki/Test_Day:2012-05-17_Gnome_Boxes 15:06:50 <kparal> maxamillion: https://fedoraproject.org/wiki/Test_Day:2012-05-17_Gnome_Boxes 15:06:59 <adamw> ooh, political! 15:07:13 * maxamillion is very bitter about the NC crap even though he doesn't live there 15:07:29 * adamw is bitter about many things but aims to keep them out of QA meetings 15:07:29 <maxamillion> adamw, kparal: thanks for the linkage 15:07:36 <maxamillion> adamw: fair point 15:08:01 <adamw> #info "adamw to check in on Boxes test day once more": test day has been moved out once more and looks like it may actually happen now 15:08:28 <adamw> #topic Fedora 17 Final status/planning 15:08:32 <adamw> welp, here's the big one 15:08:40 <maxamillion> so gnome boxes is a front end to kvm? ... like virt-manager? 15:09:02 <adamw> maxam: more or less, yeah. also, vnc. 15:09:06 <maxamillion> rgr 15:09:10 <adamw> because it seemed to logically go together, apparently. 15:09:15 <tflink> adamw: I have IRC stuff prepped we want to do a blocker-review here 15:09:43 <adamw> yeah, at least the proposed blockers, i think 15:10:02 <adamw> #topic Fedora 17 Final status/planning: mini-blocker review 15:10:05 <adamw> take it away, tflink 15:10:39 <tflink> adamw: chair? 15:11:22 <adamw> shoot 15:11:24 <adamw> #chair tflink 15:11:24 <zodbot> Current chairs: adamw tflink 15:11:27 <adamw> #chair kparal 15:11:27 <zodbot> Current chairs: adamw kparal tflink 15:11:28 <tflink> #topic (820366) Cannot boot 17 Beta installer: /dev/root does not exist 15:11:29 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820366 15:11:29 <tflink> #info Proposed Blocker, NEW 15:11:30 <adamw> #chair maxamillion 15:11:30 <zodbot> Current chairs: adamw kparal maxamillion tflink 15:11:35 * j_dulaney waves 15:12:51 * tflink remembers talking with the reporter about this over IRC 15:13:14 <adamw> bcl seems baffled 15:13:20 <tflink> I still think that we need more info 15:13:29 <tflink> it would be helpful if the reporter could try a public mirror 15:13:31 <adamw> have you verified you can still do PXE installs fine? 15:13:48 <maxamillion> o.O' 15:13:53 <tflink> not with TC5, no 15:13:57 <tflink> TC4 worked, though 15:13:59 <j_dulaney> If bcl is baffled, then, wow 15:14:08 <kparal> I booted TC5 anaconda over PXE today, all fine 15:14:10 * j_dulaney did pxe with TC5 15:14:27 <kparal> I did not finish the installation though, just booted installer 15:14:31 <j_dulaney> What kparal said 15:14:38 <adamw> still, it booted 15:14:44 <kparal> yes 15:14:51 <kparal> i386 15:14:55 <adamw> i just wanted to be sure we had enough 'it works' confidence 15:14:56 <tflink> when I was talking with the reporter, he was attempting PXE with a different initrd/vmlinuz than was on the mirror he was using 15:15:03 <tflink> he kept changing that up, though 15:15:11 <adamw> in general i'd be okay with punting, but we don't really have a whole lot of punting room at this point 15:15:27 <adamw> i'm inclined to go -1 on the info that PXE works for at least two others and probably three 15:15:27 * j_dulaney is -1 blocker at this point 15:15:39 <tflink> we don't have enough information, what else can we do other than reject it? 15:15:54 <tflink> reject or punt 15:16:00 <pjones> I think we've actually seen, very infrequently, reports along these lines for past distros as well, and never could figure it out 15:16:23 <pjones> tflink: if nobody else can reproduce it, it certainly isn't a blocker 15:17:02 <adamw> pjones: i just worry about the case where we finally realize 'oh yeah, he has (some trivial difference in config to our other testers) and that triggers a genuine bug' 15:17:14 <tflink> pjones: assuming that we're not doing something different enough to not hit whatever the reporter is hitting 15:17:16 <adamw> but it doesn't seem like a huge likelihood at this point, and we can always re-vote it. 15:17:20 <tflink> true 15:17:39 <adamw> so, -1 15:17:48 <tflink> -1 15:17:52 * nirik is -1 given what we know currently 15:17:54 <pjones> adamw: and if he does - how much configuration is there really in terms of booting the network install image? I'm inclined to say you're talking about /misconfiguring/ something. 15:17:56 <brunowolff> -1 blocker 15:18:02 * pjones obs -1 as well 15:18:23 <kparal> -1 15:18:39 <adamw> pjones: true. 15:18:56 <tflink> proposed #agreed - 820336 - RejectedBlocker - Other testers have been unable to reproduce the issue described and with the information currently available, this is not severe enough to warrant blocker status. 15:18:59 <rbergeron> ack 15:19:17 <j_dulaney> ack 15:19:21 <kparal> ack 15:19:26 <pschindl> ack 15:19:28 <tflink> #agreed - 820336 - RejectedBlocker - Other testers have been unable to reproduce the issue described and with the information currently available, this is not severe enough to warrant blocker status. 15:19:32 <tflink> #topic (813648) gnome-shell shows blank windows on hardware lacking NPOT textures 15:19:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813648 15:19:38 <tflink> #info Proposed Blocker, MODIFIED 15:20:41 <tflink> was this pulled in to TC5? 15:21:29 <adamw> yipe! 15:21:32 <adamw> ironically as this bug came up, my entire desktop suddenly started blacking out 15:21:33 <adamw> two windows disappeared, then rapidly, all the other interface elements... 15:21:36 <adamw> tflink: I believe i put it in, yeah 15:22:00 <kparal> we need someone to test it 15:22:10 <tflink> adamw: yes, it was in the TC5 request 15:22:36 <drago01> kparal: easy to test on any hardware 15:22:50 <adamw> drago01: disable a GL extension? 15:22:51 <kparal> it needs to be old nvidia 15:22:52 <drago01> kparal: just run gnome-shell --cogl-debug=disable-npot-textures --replace 15:23:01 <j_dulaney> adamw: Yeah, I've had my whole screen blanking out then coming back, but not just under Gnome 15:23:03 <drago01> kparal: no 15:23:07 <kparal> ah 15:23:12 <drago01> kparal: you can force it to use that code path 15:23:20 * j_dulaney hasn't quite figured the cause, so no bug report just yet 15:23:20 <adamw> can you put that info in the bug / update request, drago? thanks! 15:23:55 * kparal is testing it 15:24:19 <tflink> so, any thoughts on blockery-ness? 15:24:23 <drago01> adamw: 1) ajax already did 2) don't seem to have enough powers to edit the update despite being provenpacker 15:24:37 <kparal> +1 blocker, we need to either fix or blacklist 15:25:01 <adamw> at the last meeting it looks like you kinda fudged this one 15:25:06 <adamw> took it as nth and left blocker status open 15:25:10 * j_dulaney is also +1 blocker 15:25:31 <adamw> fwiw i always figured that if we took the low VRAM bug as a blocker we should logically take this too: most hardware affected by low VRAM is also NPOT 15:25:34 <tflink> yeah, there wasn't a consensus on whether or not it was blocker material 15:25:42 <drago01> yeah having black textures instead of windows is a clear blocker 15:25:43 <drago01> +1 15:25:46 <adamw> so there's not much point fixing the low VRAM bug and not fixing this, because it'll help almost no-one 15:26:03 <adamw> just a few NV4x users like kparal 15:26:12 <tflink> if this was the last blocker bug left, would we slip for it? 15:26:38 <adamw> tflink: i would slip if for some reason we couldn't write a blacklist, yes. 15:26:44 <adamw> it'd take me 20 seconds to write a blacklist, of course. :) 15:26:48 * rbergeron grins 15:26:56 <tflink> don't we already have a blacklist, though? 15:27:01 <adamw> not for this hardware. 15:27:13 <adamw> er, possibly we do, actually. lemme check exactly what went into beta. 15:27:33 <adamw> yeah, we only blacklisted NV30 for beta. 15:27:43 <adamw> so I think we're actually trying to render Shell on NV10/NV20. 15:28:13 <kparal> I can confirm the fix using that reproducer 15:28:28 <brunowolff> I have an nv28 that I run in fallback mode that works fine. 15:28:39 <tflink> looks like we're mostly +1 blocker today 15:29:17 <adamw> brunowolff: but if you set it to Shell, it probably doesn't render it right? 15:29:18 <brunowolff> I think the actual effect is a blocker, but I don't know the number of people that will be affected. 15:29:52 <adamw> we could pull numbers from smolt. i'd ballpark it in the low single digits %age-wise. 15:30:05 <adamw> low single *whole* digits, though. :) 15:30:05 <brunowolff> I don't usually use the shell, because I don't like it. There was a point about a month ago where I used the shell by mistake and it broke things. 15:30:25 <pjones> adamw: .9 is plural. 15:30:48 <brunowolff> I haven't tried it again since. So I don't know the current status. 15:31:01 <tflink> proposed #agreed - 813648 - AcceptedBlocker - violates "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the co 15:31:15 <brunowolff> I think a few percent would be significant and worth blocking for. 15:31:18 <tflink> that criterion is too long :( 15:31:34 <adamw> tflink: yeah, i keep loading it up. 15:31:37 <adamw> ack 15:31:45 <brunowolff> ack 15:31:50 <kparal> ack 15:31:57 <drago01> tflink: just assign them numbers so that you can say violates cirterion #X 15:32:01 <j_dulaney> ack 15:32:27 <kparal> numbers change in time 15:32:31 <tflink> #agreed - 813648 - AcceptedBlocker - violates "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct pas 15:32:53 <tflink> #topic (820985) Searching for duplicate anaconda bugs while reporting exception against partner-bugzilla during install fails 15:32:56 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=820985 15:32:58 <tflink> #info Proposed Blocker, MODIFIED 15:33:02 <tflink> this is a pretty clear cut blocker to me 15:33:55 <adamw> well...what data do we lose? 15:33:57 <tflink> proposed #agreed - 820985 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" once bugzilla.redhat.com is upgraded 15:34:01 <adamw> the info that multiple people are hitting the bug, i guess 15:34:11 <tflink> adamw: duplicate reporting and it looks bad 15:34:11 <adamw> all the bugs would still get reported 15:34:26 * adamw just trying to be careful :) 15:34:38 <tflink> "hey, we hit this problem but we won't let you report it" 15:34:44 <kparal> sometimes the duplicate detection is totally wrong 15:34:53 <tflink> the failure mode doesn't say anything about why, just failes with issue (null) 15:35:24 <j_dulaney> Goes against the bug reporting criterion, I think 15:35:33 <adamw> tflink: where's that commit from? 15:35:34 * j_dulaney is +1 blocker 15:35:42 <tflink> adamw: libreport, I think 15:35:44 <adamw> j_dulaney: yeah, it's a conditional breakage of that criterion in the case of 'reporting a dupe bug' 15:35:52 <tflink> I don't think we have a new build yet, though 15:35:54 <kparal> ack 15:36:32 <adamw> tflink: note you'll want the next patch in the series too 15:36:39 <adamw> as the first one just unconditionally changes to 'id' 15:36:49 <adamw> so it'd break existing bugzilla instead =) the next one queries version and DTRT 15:36:54 <adamw> okay, ack. 15:36:57 <tflink> proposed #agreed - 820985 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" for detected duplicates once bugzilla.redhat.com is upgraded 15:37:05 <kparal> ack 15:37:08 <brunowolff> ack 15:37:15 <tflink> #agreed - 820985 - AcceptedBlocker - Violates the F17 alpha release criterion "The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" for detected duplicates once bugzilla.redhat.com is upgraded 15:37:24 <tflink> #topic (821122) repoclosure failure on 17.TC5 DVDs (zif) 15:37:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=821122 15:37:24 <tflink> #info Proposed Blocker, NEW 15:37:49 <adamw> well, ack, repoclosure. but how did this happen? 15:37:54 <adamw> dgilmore: ? 15:38:37 <adamw> hum. i see two versions of PackageKit in the file list. 15:38:49 <dgilmore> adamw: it failed because we exclude every javadoc package 15:39:00 <tflink> proposed #agreed - 821122 - AcceptedBlocker - Violates the Fedora 17 alpha 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" 15:39:03 <j_dulaney> +1 blocker 15:39:03 <adamw> this is PackageKit-zif. 15:39:03 <dgilmore> i tried a few things to pull in just the one requested 15:39:05 <j_dulaney> ack 15:39:08 <kparal> acl 15:39:14 <adamw> dgilmore: wrong bug. 15:39:19 <dgilmore> adamw: im going to have to remove the removal of javadoc packages 15:39:21 <brunowolff> Pungi will pull in all matches, so if two versions are available, I think you get both. 15:39:22 <tflink> #agreed - 821122 - AcceptedBlocker - Violates the Fedora 17 alpha 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" 15:39:24 <brunowolff> ack 15:39:30 <dgilmore> adamw: what bug is it? 15:39:31 <j_dulaney> kparal: Atlantic Coast Line 15:39:40 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=813648 . wrong version of PackageKit-zif on the DVD. 15:39:45 <dgilmore> adamw: the mysql one the package wasnt pushed to stable so we have bothe versions 15:39:50 <tflink> j_dulaney: access control list :) 15:40:10 <dgilmore> adamw: we exclude PackageKit-zif from being on the dvd 15:40:19 <adamw> well, that doesn't appear to be working 15:40:23 <adamw> i think i can see part of the answer 15:40:36 <adamw> PackageKit has an open-ended "Requires: PackageKit-backend" 15:40:51 <adamw> still, no, that doesn't explain why it'd pull an old zif...gr. 15:41:03 <adamw> oh hey, i linked the wrong bug. heh. 15:41:25 <brunowolff> dgilmore: I add some more info to bug 819138 that might allow us to exclude javadoc stuff without adding two many lines to the ks file. 15:41:37 <adamw> dgilmore: sorry, it's https://bugzilla.redhat.com/show_bug.cgi?id=821122 . still can't see why it'd happen, though. i'm guessing it's somehow related to both PK builds being on the DVD, but that's as far as I can getr. 15:41:41 <brunowolff> I haven't properly tested it thow. 15:41:46 * jskladan is back after interwebz failure 15:42:05 <dgilmore> adamw: there is a packagekit update in the bleed repo 15:42:17 <adamw> dgilmore: yes. 15:42:54 <dgilmore> adamw: some subpackage must have changed arch or something to cause both to be pulled in 15:42:54 <j_dulaney> So, why exactly are we bringing in two PK builds? 15:43:25 <adamw> j_dulaney: it sometimes happens when we want to pull in a new build from the side repo 15:43:31 <adamw> since the older build is still in the main repo 15:43:40 <j_dulaney> Ah 15:43:45 <adamw> depending on dependencies (hah), that can result in both winding up on the media 15:43:56 <dgilmore> adamw: and my run of repoclosure on the tc5 tree did not show any PackageKit issues 15:44:01 <adamw> dgilmore: i guess we can just see what happens with TC6/RC1 if we do a stable push first 15:44:06 * j_dulaney doesn't quite see how that makes sense 15:44:14 <dgilmore> Repos looked at: 1 15:44:14 <dgilmore> f17-TC5 15:44:14 <dgilmore> Num Packages in Repos: 3346 15:44:14 <dgilmore> package: 1:eclipse-jdt-4.2.0-0.20.I201205031800.fc17.x86_64 from f17-TC5 15:44:14 <dgilmore> unresolved deps: 15:44:16 <dgilmore> java-javadoc >= 1:1.7.0 15:44:19 <dgilmore> package: 1:mysql-connector-java-5.1.17-4.fc17.x86_64 from f17-TC5 15:44:21 <dgilmore> unresolved deps: 15:44:24 <dgilmore> libgcj_bc.so.1()(64bit) 15:44:26 <dgilmore> java-gcj-compat >= 0:1.0.31 15:44:29 <dgilmore> java-gcj-compat >= 0:1.0.31 15:44:31 <dgilmore> thats what i got and what i expected 15:44:55 <adamw> j_dulaney: see https://bugzilla.redhat.com/show_bug.cgi?id=819139 for one example of a case where it happens 15:45:07 <adamw> dgilmore: what do you think of the 'push it stable and try again' plan? 15:45:48 <dgilmore> adamw: i pushed stable what i could on friday 15:45:49 <adamw> we'd need more karma on https://admin.fedoraproject.org/updates/FEDORA-2012-7740 , everyone. 15:45:59 <adamw> yeah, we can get some karma in and do another. 15:46:38 <j_dulaney> Testing 15:46:40 <tflink> is FESCo right after us or is there an hour gap? 15:46:50 <kparal> FESCo is from 17 UTC 15:47:03 <fossjon> y wud a bug fix need karma lol just apply it man 15:47:06 <maxamillion> adamw: firing up a VM, should have karma in shortly 15:47:06 <tflink> ok, just making sure 15:48:00 <tflink> fossjon: assuming that your question was more serious than your phrasing - because it could cause regressions that are worse than the current situation 15:48:10 <j_dulaney> Dang it, getting mirror wonkiness 15:48:15 <dgilmore> adamw: the issue with PackageKit is the update dropped 5 subpackages 15:48:34 <j_dulaney> There we go 15:48:46 <adamw> dgilmore: i checked that zif was in there, though? 15:48:50 <dgilmore> well maybe not 15:49:09 <dgilmore> adamw: yeah seems we dropped the excluding of zif somewhere 15:49:15 <dgilmore> adamw: need to add that back 15:49:19 <adamw> okay 15:49:46 <tflink> that's all of the proposed blockers 15:49:59 <j_dulaney> packagekit updating, will test when complete 15:50:23 <adamw> can people vote on proposed NTH in the bug reports, please? 15:50:27 <adamw> i'll go through and gather up votes later 15:50:38 * nirik sees 820750 is bouncing back and forth between anaconda and desktop. Fun times. ;( 15:51:41 * tflink will put together a requested blocker karma/testing/voting email after this meeting 15:51:47 <dgilmore> adamw: but when i ran repoclosure on the TC5 tree i did not see https://bugzilla.redhat.com/show_bug.cgi?id=821122 15:51:56 <dgilmore> adamw: so i dont know how robitno did 15:52:28 * j_dulaney added PK karma 15:53:17 <adamw> dgilmore: ran it on the media not the tree? 15:53:18 <nirik> if it was excluded from the dvd, and they installed, repoclosure would see it as missing because only the old one is in the repos... 15:53:37 * adamw will brb, call of nature 15:53:44 <adamw> if someone wants to move on through the agenda, please do 15:53:48 <dgilmore> adamw: the tree is the media 15:53:50 <dgilmore> ls /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-* 15:53:51 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-0.7.4-1.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-gstreamer-plugin-0.7. 15:53:53 <adamw> note the go/no-go has been moved to thursday 15:53:55 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-0.7.4-2.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-gtk3-module-0.7.4-2.f 15:53:59 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-command-not-found-0.7.4-2.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-qt-0.7.4-2.fc17.x86_6 15:54:03 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-device-rebind-0.7.4-2.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-yum-0.7.4-2.fc17.x86_ 15:54:07 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-glib-0.7.4-1.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-yum-plugin-0.7.4-2.fc 15:54:11 <dgilmore> /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-glib-0.7.4-2.fc17.x86_64.rpm /srv/pungi/17.TC5/17-TC5/Fedora/x86_64/os/Packages/p/PackageKit-zif-0.7.4-1.fc17.x86_ 15:54:12 * kparal notes PackageKit-0.7.4-2.fc17 now has enough karma for stable repo 15:54:15 <dgilmore> thats pretty clearly not right though 15:54:33 <nirik> yeah. ;( 15:55:30 <tflink> anything else on this or are we good to move on? 15:56:10 <tflink> moving on, then :) 15:56:12 <tflink> #topic Upcoming QA Events 15:56:27 <tflink> looking a the agenda, there are 2 events coming up 15:56:41 <tflink> #info GNOME Boxes test day scheduled for 2012-05-17 15:56:50 * nirik has an item for open floor when that arrives. 15:57:03 * tflink hasn't looked into it himself but hears that it might actually happen this time 15:57:37 * jskladan sacrifices a pig... 15:57:48 <j_dulaney> Can I have the bacon? 15:57:58 <tflink> nirik: ok, will ping you @ open floor when we get there 15:58:00 * j_dulaney will actually do his job and promote it 15:58:22 <tflink> how confidant are we that it'll actually happen this time? 15:58:45 <tflink> they should probably update those media links :) 15:58:57 <tflink> I see test cases, though 15:59:02 <jskladan> pschindl might know, if he's still into that 15:59:10 <tflink> the matrix needs to be updated but that should be pretty easy 15:59:21 <pschindl> I wasn't working on it this week 15:59:43 <adamw> back 15:59:52 <tflink> but I'm not sure there is much we can do from our end right now 15:59:58 <pschindl> but I think it's on good way 16:00:17 <tflink> #action j_dulaney to actually do his job and promote the GNOME boxes test day 16:00:39 * j_dulaney is writing the blog post even now 16:00:47 <tflink> adamw: ok, I think we're pretty much done with discussing the GNOME boxes test day 16:02:24 <tflink> the only other thing is the go/no-go meeting on thursday 2012-05-17 16:02:35 <tflink> not much to say there, either 16:02:43 <tflink> need an RC, need testing :) 16:02:54 <tflink> I think that's it for upcoming events, though 16:02:57 <cmurf> when is RC expected? 16:03:07 <j_dulaney> Never 16:03:09 <tflink> cmurf: soon :) 16:03:22 <cmurf> I suspected this answer. 16:03:28 <adamw> #info go/no-go has been rescheduled to 2012-05-17 16:03:37 <adamw> cmurf: you can pick either. :P 16:04:00 <cmurf> Wait what are my choices again? 16:04:09 <tflink> "real soon now" and "never" 16:04:48 <j_dulaney> I was first with a reply, so my answer takes precedence 16:04:50 <j_dulaney> ! 16:04:53 <cmurf> These are binary options? 16:05:51 <adamw> oh, for the love of... 16:06:01 <spot> as thrilling as this is... 16:06:02 <adamw> now my desktop has hit another damn bug. sigh. 16:06:08 <adamw> #topic AutoQA update 16:06:14 <adamw> #info no news due to Final testing 16:06:19 <adamw> #topic open floor 16:06:24 <adamw> floor is open for an extremely limited engagement 16:06:29 <spot> 820973 16:06:35 <spot> can we revisit that quickly? 16:06:37 <cmurf> Bug 810104 needs to be reopened I think 16:06:41 <tflink> adamw: you missed a topic 16:06:42 <adamw> yes 16:06:54 <adamw> tflink: what did I miss? 16:06:55 <j_dulaney> tflink: He closed it 16:07:04 <tflink> adamw: pending RHBZ awesomeness 16:07:16 <adamw> tflink: oh. well, i thought you said we were done with upcoming events. 16:07:31 <tflink> I wasn't thinking of it as an upcoming event, I guess 16:07:41 <tflink> more of a question of how much we care about our current tools 16:07:52 <adamw> tflink: oh, you made it a sub-topic of upcoming events in the agenda. 16:08:00 * kparal is confused 16:08:01 <tflink> yeah, I screwed up the formatting 16:08:03 <adamw> #topic Open floor: https://bugzilla.redhat.com/show_bug.cgi?id=820973 16:08:22 <adamw> so, see comment #2, i'm okay with considering it not a blocker on the basis the menu item actually works as intende 16:08:22 <adamw> s 16:08:26 <adamw> intended. grr. 16:08:47 <kparal> no changes needed in software -> no bug 16:08:56 <j_dulaney> +1 16:08:58 * spot isn't even sure it merits a NTH, since no package update would be needed 16:09:01 * j_dulaney will go for that 16:09:02 <kparal> we can't force transmission upstream to create those pages 16:09:27 <adamw> yeah, i don't see what we can change as nth 16:09:37 <kparal> just close NOTABUG or CANTFIX 16:09:50 <j_dulaney> CANTFIX better 16:09:57 <tflink> CANTFIX seems closer in this case 16:10:03 <adamw> propose #agreed #820973 is no longer considered a blocker as the menu entry works as intended, but upstream has not yet written the online documentation to which it points 16:10:18 <jskladan> ack 16:10:19 <tflink> ack 16:10:23 <spot> ackity ack 16:10:23 <pschindl> ack 16:10:26 <kparal> ack 16:10:36 <j_dulaney> ack 16:11:09 <adamw> #agreed #820973 is no longer considered a blocker as the menu entry works as intended, but upstream has not yet written the online documentation to which it points 16:11:18 <adamw> someone suggested... 16:11:28 <adamw> #topic Open floor: https://bugzilla.redhat.com/show_bug.cgi?id=810104 16:11:56 <adamw> cmurf: oh, you. in general, please don't assume Macs ever behave like anything else. 16:12:09 <cmurf> I don't ever assume such craziness. 16:12:09 <adamw> has anyone yet tested writing TC4/TC5 to actual silver disc and booting it EFI on a non-mac? 16:12:37 * j_dulaney has no EFI h/w 16:13:04 * nirik neither. 16:13:05 <spot> adamw: there isn't too much non-mac EFI around, matthew might have some 16:13:09 <adamw> if not, let's leave it open to testing. the test is in the matrix anyway. 16:13:27 <adamw> spot: i have one. i think satellit does. 16:13:35 * tflink does as well 16:13:43 <spot> i stand corrected. 16:14:15 <adamw> #action adamw and tflink to check status of #810104 with TC5 16:14:21 <adamw> okay, back to... 16:14:32 <adamw> #topic Pending RHBZ upgrade 16:14:36 <adamw> you have the floor, tflink 16:14:57 <tflink> there is an upgrade to RHBZ scheduled for 2012-05-19 16:15:26 <tflink> I probably should have done this earlier, but I started testing stuff against the staging instance to make sure that stuff doesn't explode 16:15:29 <adamw> because, y'know, it's a great time to do that. 16:15:40 <tflink> at least it's not 2012-05-21 any more 16:15:43 <adamw> Reasons We Need A Fedora Bugzilla, #546633 16:16:00 <tflink> adamw: I hear a volunteer to setup and admin :) 16:16:10 <j_dulaney> LOL 16:16:15 <tflink> anyways, there is breakage 16:16:33 <tflink> there are going to be issues with libreport in released installers 16:16:40 <tflink> but I'm not so worried about that 16:16:57 <tflink> the script that makes the blocker bug wiki page will not work with the new RHBZ 16:17:20 <tflink> neither will the script I use to help with blocker review meetings 16:17:38 <tflink> there are other issues, but those are outside the scope of QA 16:17:40 <nirik> so, we just need to have f17 ready to go before then, right? ;) 16:17:42 * nirik runs 16:17:52 <kparal> is it hard to update those scripts? 16:17:55 <tflink> my question is - how useful is the blocker wiki page? 16:18:06 <kparal> I use it exclusively 16:18:10 <adamw> pretty useful. though sometimes problematic 16:18:16 <adamw> i found out recently it doesn't cover indirect blockers 16:18:18 <tflink> kparal: jlaska and I poked at it on friday, it won't be a trivial fix 16:18:28 <adamw> i.e. it doesn't list https://bugzilla.redhat.com/show_bug.cgi?id=819371 , because it doesn't block f17blocker directly 16:18:48 <tflink> there has been some talk about re-thinking that to be a little more sophisticated 16:18:56 <adamw> you can use custom bugzilla searches to do everything the page does functionally, but it's nowhere near as nice a layout. 16:18:58 <tflink> the wiki page or some replacement, I mean 16:18:58 <brunowolff> I once looked at doing something similar for verified bugs. 16:19:30 <tflink> so my question is - is making sure the wiki page works post RHBZ-upgrade important enough to do instead of some testing? 16:19:51 <tflink> or do we leave it alone for F17 and work on some sort of replacement for F18+ 16:19:56 <adamw> the other annoyance with the custom search approach is you have to keep making new searches for alpha, beta, final, next release alpha, beta, final, ad infinitum 16:19:59 <brunowolff> It looked possible to add recursive searching with a postgres backend, but I ended up doing other stuff instead of working on that. 16:20:00 <adamw> tflink: no. 16:20:13 <adamw> tflink: leave it alone until we sign off on f17. 16:20:15 <tflink> adamw: no? to what? 16:20:17 <j_dulaney> tflink: Leave it for f18 16:20:21 <adamw> it's not more important than testing. 16:20:37 <adamw> i can throw up some shared bugzilla searches for f17 final. 16:20:38 * jskladan is afk for a while 16:20:38 <j_dulaney> tflink: But, yeah, the wiki page is way useful 16:20:39 <kparal> I think it's enough to replace the wiki contents with links to bz queries once rhbz is updated 16:20:41 <tflink> adamw: I know that you think that way - AFAIK, you don't even like the current wiki page 16:20:45 <kparal> and fix it for f18 16:20:51 <adamw> tflink: er, that's not what i said? 16:21:04 <adamw> "<adamw> pretty useful. though sometimes problematic" 16:21:16 <tflink> adamw: ok, I'm mistaken 16:21:17 <brunowolff> Is there going to be an outage during the cut over for a significant amount of time? 16:21:22 * nirik nods. Shouldn't spend energy on this now, work on f17, _then_ work on fixing it or redoing it. 16:21:26 <tflink> brunowolff: 3 hours are planned 16:21:27 <nirik> brunowolff: it's 3 hours I think 16:21:50 <tflink> ok, works for me. just figured that I would bring it up so it isn't a surprise 16:21:57 <brunowolff> That's not too bad unless it hits a blocker meeting. 16:22:07 <tflink> brunowolff: it won't if we don't slip :) 16:22:21 <tflink> nvm, I misread 16:22:22 * j_dulaney sees that as unlikely 16:22:29 <tflink> the upgrade is on saturday 16:23:14 <adamw> oh good, i'm scheduled to drink myself into a coma on friday, so no conflicts! 16:23:16 <tflink> so it won't hit the blocker meeting on friday unless it is beyond epic :) 16:23:19 <nirik> yeah, but if we slip we will have no webpage or blockerscript tools... but I hope we can muddle along. 16:23:34 <tflink> nirik: if it's only a week, I can do it by hand 16:23:42 <nirik> yeah. 16:23:44 <adamw> that's how i always used to do it anyway. 16:23:54 <tflink> I/we/whomever 16:23:57 <nirik> and hopefully numbers of bugs would be small. 16:23:57 <j_dulaney> tflink: You've doomed us to an uber blocker meeting 16:23:59 <adamw> right 16:24:36 * j_dulaney notes that he may not be available for said meeting 16:24:55 * tflink will ask jlaska to stop running the script after the meeting on friday 16:25:13 <adamw> okay 16:25:26 <adamw> i'll put together some saved searches and send out a mail or something 16:25:33 <tflink> we'll figure out what we want to do post F17 16:26:46 <tflink> hopefully bodhi will work with the new RHBZ :) 16:27:01 <nirik> yeah, lmacken is going to be doing testing with it this week. 16:27:07 <nirik> hopefully no big issues. 16:27:20 <tflink> yeah, I'm hoping that isn't going to be a problem 16:27:39 <tflink> but considering what we were hitting on friday, I'm not sure how likely it is :'( 16:28:47 <j_dulaney> Why, oh why, are they doing it at this point in the release cycle? 16:28:49 <tflink> ok, that's all I wanted to bring up 16:29:34 <adamw> okay. 16:29:42 <adamw> j_dulaney: note that it's bugzilla.redhat.com . 16:29:43 <tflink> j_dulaney: the original F17 release was supposed to have happened already :) 16:29:48 <adamw> oh, and that. 16:29:54 <adamw> okay 16:29:57 <adamw> we did open floor already 16:30:03 <adamw> but let's just re-check 16:30:05 <tflink> adamw: nirik had something for open floor 16:30:12 <adamw> oh, and log that section 16:30:23 <nirik> oh yeah... 16:30:25 <adamw> #info Bugzilla will be upgraded to 4.2 on 2012-05-19 16:30:52 <adamw> #info this may cause problems for bug reporting from anaconda in older releases, and will break our 'current release blockers' wiki page and blocker meeting helper scripts 16:31:09 <adamw> #action adamw to create some shared bugzilla searches for F17 final blocker/nth to replace the wiki page 16:31:27 <adamw> #info tflink will look into options for the broken tools once f17 is signed off 16:31:33 <adamw> #topic Open floor 16:31:40 <brunowolff> I notice that bugmail is now going to come in html by default. I'll be turning that off (html) right away. 16:31:41 <adamw> what's up, nirik? 16:31:48 <nirik> so, I thought I would mention to QA folks: I was looking at updating boot.fedoraproject.org... it's been on my list for a long time. http://lists.fedoraproject.org/pipermail/infrastructure/2012-May/011721.html we can back it out if it causes problems easily. I don't know how many people use b.fp.o. There is no release critera affected. 16:32:07 <tflink> brunowolff: wait, what? really? damnation, I'll have to change that option, too 16:32:07 <nirik> but perhaps down the road we should add it to critera, etc. 16:32:18 <nirik> brunowolff: ? yuck 16:32:21 <adamw> nirik: yeah, it's like EC2 at present, not covered but probably should be. 16:32:27 <brunowolff> http://www.bugzilla.org/releases/4.2/release-notes.html#v42_feat_email 16:32:33 <tflink> adamw: isn't EC2 covered? 16:33:04 <nirik> anyhow, wanted to mention it, and get any feedback about it... and testing would of course be welcome after it's switched. 16:33:06 <tflink> as final - the Xen release criteria 16:33:33 <adamw> tflink: well, sorta indirectly, yeah. 16:33:54 <j_dulaney> nirik: Propose a test day 16:33:56 <tflink> adamw: EC2 was the reason we wrote that criterion, though 16:34:02 <adamw> that criterion probably wouldn't cover just some kind of error in our EC2 applicance image, though. well, burn that bridge when we get to it. 16:34:13 <adamw> not entirely. ec2 is one of the major reasons we accepted the principle of xen being a final blocker. 16:34:21 <j_dulaney> BURNING BRIDGES! 16:34:28 <adamw> but that was more 'use of fedora on ec2' than 'use of any specific image fedora project releases for ec2' 16:34:33 * j_dulaney is a pyro 16:34:37 <nirik> j_dulaney: sure... 16:34:41 <adamw> anyhow...we're way over time 16:34:48 <brunowolff> That's a good song. 16:35:00 <adamw> #info nirik will be updating boot.fedoraproject.org for F17, he welcomes input and testing 16:35:16 <nirik> ipxe should add lots of more hardware support, FYI. 16:35:24 <nirik> and some wireless even 16:36:06 <adamw> oh yay. 16:36:13 <adamw> okay...so, anything else? last call! 16:36:46 * nirik has nothing 16:37:04 <adamw> well FINALLY you're satisfied 16:37:05 <adamw> :P 16:37:08 <nirik> :) 16:37:36 <adamw> thanks for coming, all 16:37:38 <adamw> time to go bash some blockers 16:37:40 <adamw> #endmeeting