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