15:01:47 <adamw> #startmeeting Fedora QA Meeting
15:01:47 <zodbot> Meeting started Mon Sep 19 15:01:47 2011 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:52 <adamw> #meetingname fedora-qa
15:01:52 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:56 <adamw> #topic Roll Call
15:02:11 <adamw> morning everyone, who's here?
15:02:53 * athmane is around
15:02:54 * brunowolff is here
15:03:32 * kparal and pschindl are today double-booked
15:04:05 <adamw> how dare you book something else at the same time as the QA meeting
15:04:07 <adamw> HOW DARE YOU, is ay
15:04:24 <maxamillion> blasphemy!!!!
15:04:42 * maxamillion hopes nobody notices he's been double booked for roughly 5 months
15:04:45 <maxamillion> >.>
15:04:50 <kparal> :D
15:04:56 <adamw> oh, i noticed. your co-ordinates are programmed into the orbital laser
15:05:16 <maxamillion> adamw: :D
15:05:29 <maxamillion> silly $dayjob getting in the way
15:05:41 <adamw> alright, i guess we'll move along
15:05:43 <maxamillion> if only I didn't have bills or need coffee and food
15:05:48 <adamw> #topic previous meeting follow up
15:05:52 <brunowolff> So how does oen get uh observation time on the orbital laser?
15:05:55 <adamw> maxamillion: what, they don't take Fedora poker chips?
15:05:55 <maxamillion> (notice that coffee was listed first)
15:06:01 <maxamillion> adamw: if only!
15:06:10 <adamw> brunowolff: funny you should ask - it involves buying me lots of beer...
15:07:03 <adamw> so we had one for tflink - #action tflink to ping python-yourls reviewer to get the process moving again
15:07:07 <adamw> anyone know if that got done?
15:07:50 <kparal> tflink is not around today?
15:08:06 <kparal> he's on #fedora-qa
15:08:51 <adamw> he seems idle
15:09:01 <adamw> good-for-nothing little...
15:09:06 <adamw> :P
15:09:22 * adamw goes to look for the bug report
15:09:32 <kparal> let's come back to this item when he connects
15:10:25 <adamw> bug hasn't been touched since 733692, so it looks like there' sstill an issue
15:10:29 <adamw> erf.
15:10:35 <adamw> since 08-30
15:10:42 <adamw> #action adamw to check in with tflink about python-yourls
15:11:07 <adamw> #chair athmane
15:11:07 <zodbot> Current chairs: adamw athmane
15:11:16 <adamw> just in case i die of exhaustion in my chair...
15:11:37 <adamw> there was also #action adamw to summarize this response for the fesco trac ticket (in the context of the updates policy), which I did
15:11:47 <adamw> oh, actually, we should talk about that.
15:11:56 <adamw> #topic previous meeting follow-up: updates policy
15:12:08 <adamw> so if anyone else was around for the fesco meeting, you'll know the result was that the policy wasn't changed
15:12:19 <adamw> but it's all going to be okay because we're going to get more proventesters and do more proven testing!
15:12:29 * kparal is relieved
15:12:33 <adamw> so...if you're a proven tester, do more testing. ;) and go make more proven testers. ask your parents how.
15:12:53 <brunowolff> nirik is trying to organize weekly pt meetings.
15:12:54 <adamw> kparal: the 'get more proventesters and do more proven testing' bit appears to be up to us, so don't get too comfortable. ;)
15:12:59 <adamw> yes, indeed
15:13:00 * nirik looks up.
15:13:09 <nirik> Yeah, wed! be there! :)
15:13:12 <adamw> everyone be nice to nirik and show up at his meetings. *pets head*
15:14:12 <adamw> if anyone has ideas about how to get more proven testing - either by getting more testers, getting testers to do more testing, or making the whole process more efficient - please do share on the list. or just go ahead and do whatever your brilliant idea is. :)
15:14:27 <adamw> we'll probably come back to this in a more organized way after beta...but anyone have ideas/thoughts now?
15:14:32 <nirik> we will see if it has any critical mass moving forward. If nothing else we can test and karma stuff for an hour.
15:15:15 <adamw> yup.
15:15:52 <adamw> alright then, back to...
15:15:57 <adamw> #topic previous meeting follow up
15:16:13 <adamw> i see "#action tflink find out current status of virtualization test day" - dunno if that got done, but the virt test day happened and appeared to be very active.
15:16:20 <brunowolff> If people discuss how to test particular packages (which seems to be blocking some testing), documenting that for future occurances would be nice.
15:16:38 <adamw> brunowolff: as a package-specific test case!
15:16:55 <adamw> https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation
15:17:22 <maxamillion> adamw: +1
15:17:47 <adamw> and finally "#action nirik look into why grub2 isn't showing up as critpath in bodhi" - nirik, did you?
15:18:00 <maxamillion> random side note, I think it would be nice to have a link to a package test plan available on the package's pkgdb listing (once there's enough material for it to be warranted)
15:19:14 <adamw> maxamillion: sure, it'd be good to have it in sensible places other than just bodhi
15:19:39 <adamw> not sure who to ask about that...dunno who maintains those pages
15:20:01 <maxamillion> adamw: I think abadger1999 maintains pkgdb
15:20:04 <maxamillion> abadger1999: ping
15:20:30 <abadger1999> maxamillion, adamw: You rang?
15:20:39 <adamw> quick phone line
15:21:04 <adamw> abadger1999: ^^^^
15:21:10 <maxamillion> abadger1999: what adamw said :)
15:21:53 <abadger1999> https://admin.fedoraproject.org/pkgdb/acls/name/grub2
15:22:04 <abadger1999> grub2 is marked critpath in devel, not in f14/15
15:22:20 <abadger1999> hm... it is marked critpath in f16
15:22:44 <abadger1999> maybe the bodhi code to pull from pkgdb wasn't updated b/c of the freeze.
15:23:04 <abadger1999> package test plans... what are we talking about?
15:23:06 <abadger1999> a url?
15:23:13 <lmacken> abadger1999: correct, I'm going to push an updated critpath list in soon though
15:23:15 <abadger1999> and is it constructable from a template?
15:23:51 <maxamillion> abadger1999: its more an idea right now than anything
15:24:00 <abadger1999> <nod>
15:24:12 <abadger1999> The code changes are different depending on what it is.
15:24:13 <adamw> abadger1999: bodhi does it already
15:24:18 <maxamillion> abadger1999: but we were wondering if there would be a way to link to the test cases (once they exist) like we do to the package source, builds, etc.
15:24:19 <adamw> so lmacken can tell you
15:24:30 <adamw> maxamillion: we already do it with bodhi, so it ought to be possible
15:24:52 <abadger1999> adamw:  if its a templatable url, then we can just add it to thelinks at the top of a pkgdb package page.
15:25:08 <maxamillion> adamw: ahhh ok :)
15:25:20 <maxamillion> adamw: I didn't know it was already being done with bodhi
15:25:27 * maxamillion is a tad behind the curve
15:26:14 <abadger1999> adamw: If it's a url that we only want to exist if there actually is a test plan then we'd also need to modify the database and the code to put in that link would be a little different.
15:27:07 <abadger1999> adamw: and we'd need a way for package maintainers to edit it, probably.... I'm thinking it would be easiest to add to pkgdb-cli at first.
15:27:37 <abadger1999> the webui needs to be rewritten to use a !Mochikit javascript library so it's harder to add things to than the command line interfaces
15:27:38 <adamw> abadger1999: a 'test plan' is just a set of pages in a specific category on the wiki
15:27:51 <abadger1999> adamw: right... but what do you want to expose?
15:27:54 <adamw> abadger1999: so what you do if you want to 'show the test plan' is simply display a list of all those cases
15:28:03 * jskladan1 finally got the d**ned irc working, sorry for the delay
15:28:07 <adamw> it's therefore inherently modifiable because you can always put new pages into wiki categories
15:28:12 <abadger1999> adamw: are you okay with a test plan link that goes to an empty category?
15:28:26 <maxamillion> jskladan1: welcome :)
15:28:39 <abadger1999> adamw: If so, very easy to implement.
15:28:59 <adamw> see https://admin.fedoraproject.org/updates/FEDORA-2011-11370 for e.g. , under 'test plan'
15:29:19 <adamw> abadger1999: we don't really want to link to the category directly, but for pkgdb to do what bodhi does, and actually list out the appropriate test cases
15:29:23 <adamw> well, i'd think
15:29:28 <adamw> we can work out the details later, though...
15:29:36 <adamw> where should we raise a ticket?
15:29:36 <abadger1999> adamw: ahh... then it's tougher.
15:29:44 <abadger1999> adamw: where do you want it displayed?
15:30:11 <abadger1999> adamw: probably have to look at the bodhi code and steal whatever screen scraper code it's using as well.
15:30:18 <adamw> dunno yet. it's maxa's idea, and he just had it, afaik :)
15:30:26 <adamw> abadger1999: it doesn't use screen scraper code, it queries wiki
15:30:37 <abadger1999> adamw: oooh.... and that's buggy code :-(
15:30:48 <adamw> hmm?
15:31:04 <abadger1999> adamw: I thought you were showing me what a package without test cases looked like
15:31:17 <abadger1999> adamw: b/c the list of test cases is invisible in chromium
15:31:19 <lmacken> abadger1999: by "steal" you mean "move into python-fedora" ?
15:31:24 <lmacken> :)
15:31:51 <adamw> abadger1999: that means there's two candidates for where the buggy code might be...;)
15:31:52 <abadger1999> lmacken: I'm not sure.... I don't know that I'd want a screen scraper in python-fedora -- but if it's querying the wiki then it could go into client.wiki
15:32:09 <lmacken> abadger1999: screen scraper? where?
15:32:11 <adamw> lmacken: it's already in python-fedora , isn't it?
15:32:17 <adamw> and i already said, it's not a screen scraper.
15:32:35 <lmacken> adamw: I wrote a fedora.client.Wiki module, but this test-case specific code jlaska wrote, and I ended up pushing into bodhi
15:33:10 <adamw> oh right.
15:33:31 <adamw> anyway...i repeat the ticket question, as i'm looking anxiously at the clock and we have a fun blocker list to get to.
15:36:17 <adamw> #action maxamillion to follow up with abadger1999 on the idea of linking from pkgdb to the list of package-specific test cases for a package
15:36:43 <adamw> alright...let's move on to:
15:36:47 <adamw> #topic Beta preparation
15:36:58 <adamw> in a nutshell, we're screwed! now, someone help me out of this damn nutshell.
15:38:56 <adamw> #info https://admin.fedoraproject.org/updates/FEDORA-2011-11370
15:38:58 <adamw> grrr.
15:39:02 <adamw> #undo
15:39:02 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x19639c8c>
15:39:07 <adamw> #link https://fedoraproject.org/wiki/Current_Release_Blockers
15:39:48 <adamw> we're still looking at more or less the same blockers we were on friday, with some new proposals
15:40:00 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=738803
15:40:24 <adamw> mgrepl has submitted a new attempt at fixing this: it appears to be a shot at the underlying issue, rather than a band-aid like dan's
15:40:47 <adamw> so we need to test that; i can put up a live image, built using it, after the meeting
15:40:57 <adamw> anyone have any other input on that one?
15:42:56 * adamw taps mic
15:43:05 <adamw> is this thing on?
15:44:11 <adamw> brunowolff: kparal: athmane: nirik: where'd everybody gooo...
15:44:14 <maxamillion> adamw: yes
15:44:16 <maxamillion> :)
15:44:32 <adamw> whew, i was starting to feel all alone.
15:44:42 <nirik> adamw: sorry, sidetracked fixing something. ;)
15:44:53 <nirik> hopefully this new fix will work out.
15:45:00 <adamw> so looks like there's not much on this one other than re-test.
15:45:22 <adamw> #agreed 738803 needs re-testing, adamw to build a live with it included
15:45:29 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=737731
15:46:31 <adamw> for this one we need https://admin.fedoraproject.org/updates/FEDORA-2011-12733 to be in the images on the public mirrors, aiui
15:46:36 <adamw> and for that, it needs to be pushed stable
15:46:48 <adamw> and for that, we need releng...nirik: dgilmore: lil help?
15:47:14 * nirik didn't do any of that this weekend... dgilmore could today? or I could later if given a list of updates that have karma.
15:48:32 <adamw> nirik: https://admin.fedoraproject.org/updates/FEDORA-2011-12733 and https://admin.fedoraproject.org/updates/FEDORA-2011-12730 are the crucial bits to be able to test that preupgrade now works as intended
15:49:03 <nirik> ok.
15:49:10 <dgilmore> adamw: ?
15:49:16 <adamw> dgilmore: nirik's got it, i think
15:49:38 <nirik> well, better if dgilmore did it, but I can if he's busy.
15:50:13 <adamw> dgilmore: see above - we really need anaconda and pykickstart pushed stable (or at least, do whatever you have to do so they're included in the images preupgrade uses)
15:50:50 <dgilmore> adamw: ok
15:50:56 <adamw> ok
15:51:17 <adamw> #agreed need releng to push out updated anaconda and pykickstart into the images used by preupgrade before we can test this
15:51:19 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=737118
15:51:27 * kparal is back
15:51:33 <adamw> bad news, we've had no plymouth or systemd help on this one
15:51:43 <adamw> good news, mgracik will do a build that just disables firstboot-text today
15:51:53 <adamw> yay for the big hammer
15:51:57 <nirik> when I looked on saturday, kernel and mutter also had karma. There may be others now. ;)
15:52:04 <nirik> cool
15:52:12 <adamw> nirik: sure, these are the really essential ones though - they stop us re-testing the preupgrade bug
15:53:13 <adamw> so nothing much we can do here for the present, look out for and test the big-hammer build when it lands
15:53:37 <adamw> #info 737118 waiting for mgracik to do a dumb fix for this so we can test it
15:54:03 <adamw> we have a few proposed blockers to go through
15:54:05 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=738964
15:57:28 <kparal> do I read that correctly that anaconda offers wrong disk to install the bootloader at/
15:57:29 <kparal> ?
15:57:43 <adamw> yes, it seems like it
15:57:47 <adamw> viking has kinda muddied things up a bit
15:58:04 <kparal> has he reproduced it or is it a different issue?
15:58:35 <adamw> but this specific case looks like, if you install from the traditional installer written to a usb stick, it won't offer to write the bootloader to the 'mbr' of the actual target disk. and, apparently, it creates the bios boot partition on the usb stick it's installing from.
15:58:49 <adamw> kparal: i think his 1) and 2) are reproductions, 3) is something else
15:58:56 <adamw> but it's hard to be sure.
15:59:08 <adamw> we should definitely get more people to test this: write the dvd image to a usb stick then try and install from it
15:59:13 <kparal> I find this sentences hard to read. anyway, I think installing from USB stick should be supported and functional
15:59:19 <kparal> *his
15:59:37 <kparal> I can test it tomorrow
15:59:44 <adamw> tomorrow  be too late, arrr ;)
15:59:52 <adamw> go/no-go is wed, we really need a new build today
16:00:02 <adamw> i'll try and look at this one later
16:00:07 <kparal> ok
16:00:08 <adamw> anyone else?
16:01:19 <adamw> zoiks. okay.
16:01:38 <adamw> #agreed 738964 looks like installing from dvd image written to usb causes issues with bootloader installation, needs more testing to verify
16:01:45 <satellit_> adamw: I will do DVD to USB test and install to USB HD if you like...
16:02:02 <adamw> satellit_: thanks...it probably doesn't matter what the desired target device is, but the more info the better
16:02:10 <satellit_> ok
16:02:41 <adamw> the most interesting bits are 'does it create a bios boot partition on the target disk' (tell it to 'use entire space' if you can) and 'what places does it allow you to install the bootloader'
16:04:02 <adamw> as to whether it's a blocker...i think it probably is, if it can be reproduced reliably; we do overall seem to support writing the dvd to a usb stick, though it always seems to cause one problem or another
16:04:06 <adamw> i remember having a similar discussion at alpha
16:04:13 <adamw> anyone else have a vote?
16:04:27 <kparal> +1
16:04:52 <kparal> optical media are outdated
16:05:13 <drago01> optical media should die die die die already
16:05:53 <brunowolff> I think we'd like install images to work from USB devices. If we don't treat it as a blocker now, I think we should in the future.
16:06:09 <adamw> okay...i guess that's +3, let's accept it as blocker on the basis that it's valid as described, if not, we can re-visit
16:06:31 <adamw> #agreed 738964 is a blocker if it's inhibiting all installs from traditional installer image written to usb stick; we need to verify this
16:08:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=737774
16:09:22 <brunowolff> I am still seeing digikam blocked with updates-testing enabled. So I don't think it's fixed.
16:09:27 <robatino> isn't that basically the same as 738735?
16:09:32 <adamw> yes
16:09:43 <adamw> it doesn't need to be a blocker in its own right; 738735 depends on it
16:09:48 <adamw> brunowolff: what's the error if you try to update it?
16:09:55 <kparal> brunowolff: what do you mean by "blocked"?
16:10:24 <kparal> you mean depsolving problems, right?
16:10:55 <brunowolff> Just a sec...
16:12:14 <brunowolff> I started an install. My memory is that there is a lot of output referring to opencv, but I'll try to trim it down here.
16:13:20 <adamw> okay, please update the bug
16:13:37 <adamw> #agreed 737774 does not need to be a blocker in its own right as it already blocks 738735
16:14:03 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=739258
16:14:11 <adamw> this one would be a blocker if valid as described, but i haven't hit it
16:14:17 <robatino> 738735 should probably be against digicam since that's what needs an update
16:14:18 <adamw> has anyone else seen firstboot run on the live image?
16:14:37 <brunowolff> I added the output to https://bugzilla.redhat.com/show_bug.cgi?id=738735
16:14:48 <adamw> robatino: the current setup is fine - 738735 is for the rc1-specific repoclosure issue, and depends on the bug which tracks the issue that's actually causing the repoclosure
16:14:49 <brunowolff> It wasn't all that much output.
16:14:51 <adamw> makes sense to me
16:15:12 <robatino> ok, i'll leave it alone
16:15:14 <brunowolff> It's possible there is an update which hasn't hit updates-testing yet which fixes things.
16:15:46 <adamw> okay
16:15:48 <kparal> which bug# are we discussing now?
16:16:02 <adamw> we should be discussing 739258 =)
16:16:06 <adamw> all of that was related to the last bug, though.
16:16:15 <kparal> ok
16:16:24 <adamw> jsmith claimed he saw firstboot fire on the live image, i haven't seen that, and i've booted the live image about 10,000 times this weekend, feels like.
16:17:20 <kparal> I haven't seen that
16:17:24 <kparal> pschindl neither
16:17:57 <adamw> man, this reporter is full of crack...'jared smith'? if that even IS his real name
16:18:04 <adamw> :P
16:18:33 * kparal double-checking i686 Live
16:18:58 <kparal> nope
16:19:11 <drago01> adamw: btw. (semi ot but we decide whether 738977 is a beta blocker or not later in the meeting?)
16:20:23 <kparal> I must say I never used livecd-iso-to-disk. it may be related to that
16:20:26 <adamw> drago01: it's not proposed as one right now, but consider that a proposal
16:20:31 <adamw> kparal: i always do
16:20:33 <adamw> kparal: you just dd?
16:20:39 <kparal> adamw: right
16:20:47 <drago01> adamw: ok
16:20:50 <kparal> works like charm
16:20:59 <adamw> roger. i use livecd-iso-to-disk and i haven't seen it, either, though. i think jared did something wrong. =)
16:21:12 <kparal> let's ask him to re-test once more
16:21:19 <adamw> i suppose he might have inadvertently deleted 'liveimg' from the kernel parameters.
16:21:21 <adamw> yeah, i will
16:21:32 <kparal> maybe he booted from his hard disk by some mistake?
16:21:34 <kparal> no idea
16:21:53 <adamw> #agreed 739258 would be a blocker as described, but no-one besides jsmith seems able to reproduce; ask him to re-test and provide more details
16:22:52 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=739591
16:23:09 <adamw> this is a brand-spanking new one elad just threw on the list
16:23:15 <adamw> he did an f15->f16 upgrade and sound is broken
16:23:30 <adamw> sounds like a candidate for further testing
16:23:42 <kparal> I haven't tried sound yet
16:24:10 <kparal> pschindl says it worked for him in TC2
16:24:33 <brunowolff> It isn't a general f16 sound issue as I have sound right now.
16:24:47 <kparal> of course there can be zillions reasons why it fails just for someone
16:25:20 <kparal> someone who knows something about audio should ask for more audio-related details
16:25:56 <kparal> logs, hardware listings, etc
16:26:09 <adamw> pschindl1: on an upgrade from f15?
16:26:16 <kparal> +1 to needinfo
16:26:27 <kparal> adamw: nope, clean install
16:26:30 <adamw> ok
16:26:35 <adamw> this is likely an upgrade-specific issue
16:26:43 <adamw> so we need more people to test upgrading
16:26:48 <kparal> and +1 to re-test, right :)
16:26:49 <pschindl1> adamw: I made only clean install
16:27:11 <pschindl1> and as I remember, sound is working well
16:29:34 <adamw> alright, so: add that to the list of things to test - do an upgrade install and check sound
16:29:53 <adamw> #agreed 739591 need more info on the failure and need to see if others can reproduce on upgrade from f15 to f16
16:30:18 <adamw> #topic http://bugzilla.redhat.com/show_bug.cgi?id=739345
16:31:52 <kparal> if it block install media creation, it's a no-brainer, isn't it?
16:32:46 <adamw> ayup.
16:32:55 <adamw> can't build images if the image build builder doesn't build.
16:33:11 <adamw> (how many images would an image build build if an image builder could build...)
16:33:22 <adamw> oh, look, tongue twisters work when you're typing too.
16:34:32 <adamw> so, +1 blocker for me
16:34:35 <adamw> and kparal too
16:34:37 <adamw> any others?
16:34:47 <brunowolff> +1
16:35:09 <brunowolff> I checked for syslinux-vesa-splash in spin-kickstarts and didn't see that string there.
16:35:24 <brunowolff> Name changes have hosed live images in the past.
16:35:55 <adamw> uf, nice catch. we'll have to check live image compose too.
16:36:00 <adamw> can you comment in the bug?
16:36:20 <adamw> #agreed 739345 is a blocker as it causes problems with image compose
16:36:26 <brunowolff> syslinux could still have issues with a name change. I am not sure how to quick test that.
16:36:53 <adamw> wouldn't just building a live image with the offending fedora-logos be a good enough test?
16:37:49 <brunowolff> Yes, but I was trying to think of something I could do in a minute.
16:38:03 <brunowolff> You'd probably want to try to boot as well as compose.
16:38:36 <brunowolff> I think syslinux has a config file that points to images that might not get used until booting.
16:40:09 <brunowolff> Side note: digikam 2.0.0-4.fc16 from koji is installing for me. So that issue will be fixed once it's really in stable.
16:40:34 <adamw> right.
16:41:19 <adamw> oop, missed one confirmed blocker
16:41:20 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735866
16:41:31 <adamw> which we still just have no useful maintainer response on. anyone else have new data?
16:43:08 <kparal> that is very weird. I never received any of those comments after my comment was posted
16:43:13 <kparal> anyway I don't have any new data
16:44:06 <adamw> kparal: somehow you're not on the cc list
16:44:16 <kparal> adamw: I just added myself manually
16:44:45 <kparal> adamw: I believe I saw that on DVD install media, yes
16:47:31 <brunowolff> The two minute timeout might be systemd related. That's about how long it waits for me to enter keys on boot and will continue without mounting devices if I take too long.
16:47:41 <adamw> brunowolff: no, it's not: it's coded into udevadm.
16:47:56 <adamw> what 'udevadm settle' does is simply wait for the udev queue to empty, then return success
16:48:10 <adamw> or return failure if waits for a specific period and the queue doesn't empty
16:48:21 <adamw> the default timeout is 120 secs, you can pass a parameter to udevadm to change it
16:48:32 <kparal> it happens too infrequently to test it well
16:48:35 <adamw> systemd's default service timeout is 90 secs.
16:49:01 <adamw> kparal: yeah, it's an annoying bug.
16:49:20 <kparal> there were times where I encountered it 5 times in a row
16:49:31 <kparal> and now nothing, not once
16:49:33 <adamw> #agreed no new info on 735866, still waiting for a reliable reproducer or developer feedback
16:50:21 <adamw> one bug i have on my list that's not proposed as a blocker, and then the other one that was proposed earlier...
16:50:22 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=731356
16:50:32 * satellit_ dd 8GB USB of f16 DVD RC1 is booted and installing to usb 250 GB HD now...
16:51:32 <adamw> this one's another issue encountered when writing the dvd iso to usb stick
16:52:01 <adamw> so, another one to look out for when testing that path
16:52:53 <adamw> anyone else ever seen this one?
16:53:02 <kparal> nope
16:53:36 <adamw> yay, more worrying-but-uncertain bugs.
16:53:41 <adamw> okay, just wanted to flag this one up.
16:53:53 <adamw> #agreed 731356 another potential issue when installing from dvd-to-usb, everyone please test
16:54:13 * kparal is tired and wants to go home. let's wrap it up!
16:54:22 <adamw> yeah, this should be the last one
16:54:23 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=738977
16:54:27 <adamw> as proposed earlier
16:55:07 <kparal> interesting bug
16:55:07 <adamw> i'm not sure i see this one: i think when i tested install f15, upgrade to f16, update kernel, reboot, it booted to the new kernel
16:55:17 <adamw> but my everyday f16 machine is on grub1 so i'm not sure
16:55:25 <kparal> I don't think it relates to dist-upgrade
16:55:32 <kparal> just simple kernel upgrade
16:55:42 <adamw> kparal: see last step
16:56:14 <kparal> this one?
16:56:15 <kparal> 4) Due to 1) user ends running the vulnerable kernel even though he had updated
16:56:15 <kparal> to the one with the security fix.
16:56:19 <adamw> so i did an f15->f16 upgrade which left me with kernel rc3, then i did a 'yum update' which installed rc5 and rebooted, and it gave me rc5
16:56:24 <drago01> adamw: I did 1) install f16 from live cd 2) yum update 3) reboot
16:56:27 <adamw> kparal: no, the 'last step' in my line ' 'update kernel'
16:56:30 <drago01> adamw: 4) old kernel
16:56:33 <adamw> hum, interesting
16:56:36 <adamw> maybe it's a live thing
16:56:39 <adamw> more testing required!
16:56:57 <drago01> adamw: what does your grub config state as default?
16:57:04 <adamw> drago01: i blew that vm away days ago.
16:57:13 <drago01> adamw: ok
16:57:15 <adamw> it's probably had about fifteen installs since then =)
16:57:26 <kparal> I think you must use "saved" option
16:57:31 <kparal> for this bug to manifest
16:57:39 <kparal> I don't know whether it's the default setting
16:57:50 <adamw> well, let's do a bit more testing to see
16:57:56 <adamw> does anyone want to vote yet?
16:57:58 <drago01> kparal: the whole bug is about saved being the default
16:58:11 <kparal> drago01: ah, you're right
16:58:17 <brunowolff> I don't think its a blocker.
16:58:31 <kparal> definitely can be solved post-release
16:58:42 <adamw> are we sure about that?
16:59:05 <adamw> (it can be fixed post-release)
16:59:15 <adamw> could we do an update which changed a grub config option for existing installs?
16:59:21 <mjg59> adamw: Fesco's in 60 seconds?
16:59:27 <adamw> mjg59: we're about done
16:59:30 <drago01> well yeah assuming grubby writes out the config
16:59:34 <mjg59> adamw: Great
16:59:53 <adamw> okay...let's vote on this one in comments, don't want to take a hurried -1
17:00:02 <adamw> aaand we'd better get out of fesco's way, that's the whole list anyhow
17:00:10 <adamw> anyone have a really urgent topic?
17:00:16 <adamw> you got -10 seconds to raise it
17:00:25 <adamw> paging dr. who
17:00:34 <kparal> I remember that 1 hour meetings used to be considered long...
17:00:41 <adamw> #agreed 738977 needs more testing and voting
17:00:44 <adamw> #endmeeting