15:03:36 <adamw> #startmeeting Fedora QA meeting
15:03:36 <zodbot> Meeting started Mon May  7 15:03:36 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:39 <adamw> #meetingname fedora-qa
15:03:39 <zodbot> The meeting name has been set to 'fedora-qa'
15:03:43 <adamw> #topic roll call
15:03:50 <adamw> oy! roll! c'mere!
15:03:54 * mkrizek is here
15:04:00 * satellit_ listening
15:04:07 * Cerlyn is here
15:04:30 * tflink is here
15:05:16 <adamw> alrighty
15:05:26 <adamw> now, chaaaarge
15:05:41 <adamw> #topic previous meeting follow-up
15:05:49 <adamw> we just had one here - "pschindl to poke gnome-boxes devs about Thursday's test day"
15:06:01 <adamw> since that got postponed (again?) to this week, i guess it happened.
15:06:36 * kparal is in afk mode
15:07:06 <tflink> he pinged me last week about the test day
15:07:26 <tflink> I guess that there was some miscommunication on who was actually going to write the test cases and it didn't look as if everything was going to be done on time
15:07:58 <tflink> I haven't heard anything else since we moved the test day back a week, though
15:07:59 <adamw> so they pushed it out again, okay.
15:08:19 <adamw> #info pschindl followed up on Boxes test day, event was not prepared in time so was pushed out another week, needs checking up again
15:08:29 <adamw> #action adamw to check in on Boxes test day once more
15:08:38 <adamw> #topic Fedora 17 Final status/planning
15:08:53 <adamw> so...we're supposed to be rolling an RC tomorrow. this is looking somewhat unlikely =)
15:09:04 <adamw> of course, the blocker list is https://fedoraproject.org/wiki/Current_Release_Blockers
15:09:28 * tflink has a list of blockers that need to be retested w/ tc3
15:09:40 <tflink> hasn't finished fleshing out the 'how to test' part of it, though
15:10:13 <tflink> 14 blocker and NTH bugs that need to be retested w/ TC3 if they haven't been already
15:10:51 <adamw> shall we go through the proposed blockers that weren't covered on friday?
15:11:20 <tflink> have they moved much? I didn't see much activity on bz over the weekend
15:11:21 * pschindl is here (train has delay)
15:12:00 <tflink> the list seems to have re-populated, though
15:12:12 <adamw> there's 8 i can see
15:12:24 <adamw> pschindl: hiya, you didn't miss a lot, we covered your action item
15:12:41 <pschindl> so I'm late :(
15:13:21 <pschindl> adamw: any additional information needed?
15:13:25 <adamw> pschindl: nope, it was fine
15:13:30 <adamw> okay, so let's go for a mini blocker-review
15:13:41 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=819563
15:14:12 <adamw> i don't see a huge amount of info here, kparal...
15:14:14 <kparal> I reported this just right now
15:14:22 <kparal> the logs are there
15:14:42 <tflink> this sounds like another flavor of the time bug we saw earlier
15:14:51 <tflink> WRT fsck errors
15:15:03 <kparal> I need someone to re-test
15:15:04 <adamw> it seems like it's having some problem with an existing root partition / VG?
15:15:13 <kparal> I used "use all space"
15:15:17 <adamw> there's errors about /dev/mapper/vg-lv_root in storage.log and program.log
15:15:29 <adamw> tflink: which bug's that?
15:15:42 * tflink doesn't remember off hand, searches
15:17:32 <tflink> .bug 811706
15:17:36 <zodbot> tflink: Bug 811706 fsck errors during install from livecd if system time is too far behind - https://bugzilla.redhat.com/show_bug.cgi?id=811706
15:18:07 <tflink> I doubt that they're closely related - the timing of the error message just sounded familiar
15:19:06 <kparal> my VMs don't have system time shifted, I just checked
15:19:28 <tflink> those fsck errors are different, anyways
15:19:59 <adamw> sorry, dealing with a medical emergency
15:20:15 <tflink> adamw: I can continue the review if you #chair me
15:20:42 <tflink> that's weird - anaconda formats the lv then fsck says it's not ext4 when it attempts to mount it
15:21:02 <kparal> maybe it's mounted while formatting?
15:21:33 <tflink> doesn't look like it - there's some lv monkeying after formatting
15:21:57 <adamw> #chair tflink kparal
15:21:57 <zodbot> Current chairs: adamw kparal tflink
15:22:03 <kparal> can somebody do just a quick install of i686 live in VM?
15:22:08 <adamw> seems like an anaconda logic error
15:22:20 <adamw> don't have it here, and dl.fp.o is slow atm
15:22:20 <tflink> yeah, I can get one started once I download the live
15:22:40 <adamw> anyway, shall we agree needs more info and move on?
15:22:45 <kparal> let's just wait a day until somebody confirms or not
15:22:53 <adamw> propose #agreed need more info to determine state of 819563
15:22:56 <tflink> yeah, sounds liek a plan to me
15:22:58 <tflink> ack
15:23:06 <kparal> ack
15:23:07 <adamw> #agreed need more info to determine state of 819563
15:23:15 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=819371
15:23:25 <adamw> seems like an obvious blocker to me (note: calligra is the new name for koffice)
15:23:34 <adamw> so these are stock apps on the KDE live, crashing on launch
15:24:06 <kparal> +1 blocker, patch is coming
15:25:34 <tflink> proposed #agreed - 819371 - AcceptedBlocker - Violates the following F17 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use"
15:25:50 <adamw> ack
15:26:23 <kparal> ack
15:26:46 <tflink> #agreed - 819371 - AcceptedBlocker - Violates the following F17 final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use"
15:27:23 <tflink> in retrospect, I shouldn't have done that. Now it's not clear who's driving this thing :)
15:27:25 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=819140
15:27:32 * adamw elbows tflink out of the driver's seat
15:27:44 <adamw> repoclosure issue, +1 blocker.
15:28:02 * tflink wonders where zodbot is, though
15:28:08 <tflink> +1 blocker
15:28:30 <adamw> propose #agreed 819140 is accepted as a blocker per 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:29:20 <kparal> ack
15:29:26 <tflink> ack
15:29:31 <pschindl> ack
15:29:46 <adamw> #agreed 819140 is accepted as a blocker per 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:30:08 <adamw> there's two more repoclosure bugs, let's do those quick
15:30:16 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=819139
15:30:28 <adamw> tflink: zodbot never seems to work when we do a blocker review in here not -bugzappers
15:30:35 <kparal> ack ack
15:30:46 <adamw> propose #agreed 819139 is accepted as a blocker per 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:30:52 <tflink> ack
15:30:58 <adamw> #agreed 819139 is accepted as a blocker per 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:31:03 <kparal> repoclosure bugs are automatic acks I think
15:31:04 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=819138
15:31:10 <adamw> propose #agreed 819138 is accepted as a blocker per 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:31:17 <adamw> i don't think we have process for that, but i've done it before...
15:31:49 <kparal> ack
15:31:53 <adamw> #agreed 819138 is accepted as a blocker per 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:31:55 <tflink> ack
15:32:02 <adamw> satellit_: please quit ccing yourself to bugs, it's giving me inflight collisions =)
15:32:24 <satellit_> k
15:33:11 <adamw> satellit_: it's okay, just kidding
15:33:13 <tflink> adamw: says the man who has a habit of updating bugs while we talk about them
15:33:16 <adamw> i may have overridden some of them though
15:33:17 <adamw> tflink: heheh
15:33:23 <adamw> three to go
15:33:34 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=818935
15:33:53 <adamw> hum, didn't we talk about this friday? but i don't see a record
15:33:57 <adamw> it's kparal
15:34:04 <adamw> kparal's mysterious 'someone else is logged in' bug
15:34:13 <tflink> I think it's a split off of the two issues in the other bug
15:34:24 <tflink> so it's the same issue, just separated out into a new bug
15:34:33 <tflink> well, part of the same issue
15:34:40 <kparal> I still believe it's directly connected to https://bugzilla.redhat.com/show_bug.cgi?id=814690
15:34:51 <kparal> and that one bug received some development progress
15:35:09 <kparal> halfline found some issues in systemd
15:35:54 <kparal> but 818935 is sooo hard to reproduce
15:36:50 <adamw> i'm still probably -1 blocker if it's so hard to hit. though actually, i think i hit it yesterday.
15:37:20 <kparal> I think it would be ok to downgrade it to NTH
15:37:24 <adamw> i was very, very tired, so i'm not going to commit to everything. but afair, i got off the plane, booted up my system, ran yum update, read some mails and stuff, and went to shut down, and got the 'other people are logged in' dialog. oh, wait. i might have had a facebook open.
15:37:31 * adamw runs facebook as another user.
15:38:28 <kparal> does it help wrt privacy? :)
15:38:29 <adamw> so yeah, i guess i'm -1...
15:38:52 <tflink> yeah, -1 unless it starts happening more often
15:39:09 <adamw> kparal: basically, that's the idea. i have a 'facebook' user whose firefox profile only ever logs into facebook. my main user is configured to reject everything at all from facebook. read about it on a blog somewhere, so obviously it's a good idea .;)
15:39:47 * tflink makes note to write blog post about how firing people all the time is a bad idea
15:39:54 <adamw> heh
15:39:58 <adamw> that's okay, i don't read your blog
15:40:15 <kparal> ok, what about having it as NTH? any votes?
15:40:16 <tflink> my plans, they have been foiled!
15:40:20 <adamw> are we even NTH on this bug, though? i'm not sure it really hits live?
15:40:26 <adamw> have you ever seen it in a live boot?
15:40:30 <kparal> hmm
15:40:39 <tflink> I think the concern is the possibility of someone hitting this before updating
15:40:46 <kparal> you're right it doesn't really matter on live
15:40:46 <pschindl> I have hit this bug today
15:40:52 <pschindl> I'm +1 on NTH
15:41:02 <adamw> pschindl: have you hit it before?
15:41:15 <pschindl> adamw: long time ago
15:41:19 <kparal> on livecd you don't really care about it, liveuser is in wheel without password
15:41:26 <pschindl> it happened to me twice
15:41:32 <pschindl> as I remember
15:41:33 <adamw> pschindl: so like kparal, you see it very occasionally
15:41:37 <adamw> kparal: oh right
15:41:58 * kparal takes back NTH request
15:42:18 <kparal> let's -1 blocker it then
15:42:36 <kparal> and come on, I have to go soon
15:42:53 <adamw> ok
15:43:10 <akshayvyas> i think i am late
15:43:12 <adamw> propose #agreed 818935 is rejected as a blocker as it is fixable with an update and seems to occur very infrequently, some testers have never seen it
15:43:41 <kparal> ack
15:43:55 <tflink> ack
15:44:06 <adamw> #agreed 818935 is rejected as a blocker as it is fixable with an update and seems to occur very infrequently, some testers have never seen it
15:44:33 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=819492
15:44:41 <adamw> two doozies coming up, looks like :/
15:45:23 <kparal> I hit this one when I tried to copy a movie for my girlfriend. it never worked for her
15:45:23 <adamw> so this would be "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs" (final)
15:45:38 <adamw> seems pretty clearly +1 for me
15:45:47 <tflink> +1
15:45:58 <kparal> right, +1
15:46:18 <mkrizek> +1
15:46:34 <akshayvyas> +1
15:47:05 <adamw> propose #agreed 819492 is accepted as a blocker per criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs"
15:47:12 <pschindl> ack
15:47:17 <tflink> ack
15:47:21 <adamw> #agreed 819492 is accepted as a blocker per criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs"
15:47:33 <adamw> #topic Mini blocker review: https://bugzilla.redhat.com/show_bug.cgi?id=818378
15:48:58 <adamw> so, this is the 'can't install the i686 DVD' bug, basically
15:49:00 <adamw> AIUI anyway
15:49:09 <adamw> has everyone who's tried an i686 DVD install hit this? or is it more chancy?
15:49:21 <akshayvyas> this is kinda obscure bug
15:49:32 * satellit_ i have on vb
15:49:37 <robatino> i tried every kind of 32-bit install and hit it every time
15:49:43 * tflink is still downloading i686 media
15:49:43 <pschindl> me too
15:49:58 <adamw> akscram: '32 bit installs always explode' isn't exactly obscure =)
15:50:01 <akshayvyas> working god for me
15:50:16 <pschindl> I tried to install to i386 laptop and grub wasn't installed correctly everytime
15:50:17 <adamw> akshayvyas: did you use an x86_64 or i686 image?
15:50:37 <akshayvyas> adamw:i686 as my old p4 supports
15:50:45 <adamw> akshayvyas: with tc3?
15:50:51 <akshayvyas> yep
15:51:06 <adamw> still, even if one person got success, if two get multiple failures, that's bad enough to be blocker for me...
15:51:43 <tflink> it seems odd to be installing a 32bit distro to a DL560, though
15:51:58 * satellit_ has to do with OLPC tree?
15:52:00 <tflink> IIRC, they didn't come with anything but 64bit capable processors
15:52:20 <tflink> but I could be remembering wrong
15:53:15 <tflink> yes, I am remembering wrong - ignore me
15:53:15 <adamw> not sure we need to get too specific on this one, since grub and kernel folks are both on it
15:53:32 <akshayvyas> adamw: +1
15:53:36 <tflink> yeah, sounds like blocker material for now
15:53:42 <pschindl> I'm +1
15:53:59 <mkrizek> +1
15:54:38 <adamw> propose #agreed 818378 is a blocker per criterion "In most cases (see Blocker_Bug_FAQ), 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 the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode." - this breaks functional installation
15:54:38 <adamw> in lots of tested cases
15:54:53 <adamw> propose #agreed 818378 is a blocker per criterion "In most cases (see Blocker_Bug_FAQ), 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 the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode." - this breaks 32-bit install
15:54:56 <adamw> damn that criterion.
15:55:13 <adamw> maybe we should stick in another that just says 'installed systems should damn well boot' for reasons of shortness. :)
15:55:14 <tflink> unlcess our understanding changes, ack
15:55:34 <pschindl> ack
15:55:38 <mkrizek> ack
15:55:39 <akshayvyas> ack
15:56:30 <adamw> #agreed 818378 is a blocker per criterion "In most cases (see Blocker_Bug_FAQ), 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 the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode." - this breaks 32-bit install
15:56:34 <adamw> okay, that's the lot
15:56:59 <adamw> #topic Fedora 17 Final status/planning
15:57:03 <adamw> so, back on the general topic...
15:57:11 <adamw> #info tflink is planning a 'bugs that need re-testing' summary
15:57:14 <adamw> thanks for that tflink
15:57:41 <tflink> will be sending that out shortly
15:57:47 <adamw> anything else on strategy? i'm trying to deal with the whipping devs into line side of things now, aside from that all we can do is re-test fixes i think
15:58:13 <tflink> make sure that we get the test matrix filled out
15:58:21 <tflink> but that may already be done
15:58:29 * tflink hasn't checked this morning
15:58:34 <adamw> point
15:58:50 <tflink> the area that I'd like to see focus on is USB installation media
15:58:51 <adamw> it's pretty close, but still some more
15:59:08 <adamw> #info we still need to complete the TC3 matrix to find any other lurking blockers, no point waiting till the RC
15:59:16 <tflink> there have been a lot of changes there recently and I'm having a hard time keeping track of what works and what doesn't
15:59:21 <adamw> tflink: bcl and I are planning to work on that
15:59:40 <adamw> tflink: the high-level overview is that 17 should now be much like 16 only better (dd'ed images should boot via efi for e.g.)
15:59:51 <adamw> and dd'ed DVD images should find the packages
16:00:02 <adamw> all the malarkey about multiple partitions has gone, so just pretend it never happened
16:00:05 <tflink> stuff like this makes me think I'm not the only one who's lost: http://ask.fedoraproject.org/question/1614/why-does-a-fedora-usb-made-from-the-dvd-iso-still
16:00:38 <tflink> well, not lost but it would be nice to get everything straight soon
16:00:44 <akshayvyas> tflink: that's abut fc 16
16:00:48 <tflink> exactly
16:01:04 <tflink> but most of the responses are fixes for F17
16:01:12 <akshayvyas> yeah i see this since fc 15
16:01:17 <akshayvyas> tep
16:01:20 <akshayvyas> yep
16:02:58 <adamw> it's always been the case. f17 is the _first_ release where it should work.
16:04:02 <adamw> okay
16:04:07 <adamw> so, i guess we all know what we need to do
16:04:46 <adamw> #topic Upcoming QA events
16:05:04 <adamw> so as mentioned the RC compose is scheduled for tomorrow but that's not looking terribly likely...but let's do all we can to clear out the blocker list
16:05:10 <adamw> blocker review meeting on Friday, of course
16:07:00 <tflink> when is go/no-go?
16:07:05 <tflink> next week?
16:07:45 <tflink> next tuesday
16:08:16 <adamw> yeah
16:08:20 <adamw> so it's not on this week's list
16:08:36 <tflink> oh boy, lots to do before then
16:08:37 <adamw> other thing is the Boxes test day, i already gave myself an action item for that; looks like it's still not in shape.
16:08:49 <tflink> is boxes working yet?
16:09:00 * tflink still hasn't tried it
16:10:00 <pschindl> we are working on it
16:10:09 <adamw> me either. we put the anaconda memory requirement back down to 512 for the last build, which should help.
16:10:10 <pschindl> but lot of things still isn't working
16:11:04 * kparal leaves
16:13:58 * akshayvyas is leaving,have a great day adamw and tflink
16:13:59 <adamw> okay. so, anyway, i'll cover that
16:14:09 <adamw> seems like we're running over
16:14:13 <adamw> is there much autoqa news, tflink?
16:14:22 <tflink> nope, we've been testing F17
16:14:37 <adamw> okay
16:14:41 <adamw> #topic AutoQA update
16:14:50 <adamw> #info there is no news, autoqa team has been working on F17 validation
16:14:56 <adamw> #topic open floor
16:15:01 <adamw> anyone have anything for open floor?
16:16:24 <tflink> nothing here
16:18:34 <adamw> ok
16:18:37 <adamw> thanks for coming, all
16:18:44 <adamw> sorry for the overrun (pschindl, hope kparal doesn't mind :>)
16:18:49 <adamw> #endmeeting