16:00:53 <adamw> #startmeeting Fedora QA meeting
16:00:53 <zodbot> Meeting started Mon Feb 20 16:00:53 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:57 <adamw> #meetingname fedora-qa
16:00:57 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:08 <adamw> #topic roll call
16:01:23 * j_dulaney is in a good mood today
16:01:28 <adamw> .moar bugs everyone
16:01:28 <zodbot> here everyone, have some more bugs
16:01:31 * kparal is slammed with a table
16:01:35 * jskladan has quite a lot of cats now :)
16:01:35 * mkrizek present
16:01:40 * pschindl is here
16:02:01 <jreiser> is observing, with Q for bugzilla [at end]
16:02:02 <adamw> oh, god, jskladan is turning into that weird neighbour with the cats.
16:02:06 * tflink is present
16:02:42 <jskladan> http://www.youdopia.com/wp-content/uploads/2011/06/crazy-cat-lady-meme-generator-feel-guilty-about-giving-one-cat-more-attention-than-others-b3e697.jpg.png
16:02:53 <adamw> hehe
16:03:33 <adamw> alrighty
16:03:38 <adamw> any latecomers will be summarily fired
16:03:43 <adamw> #topic previous meeting follow-up
16:04:15 <adamw> "kparal to check with releng on the status of daily installer image builds for RATS testing"
16:04:20 <kparal> done
16:04:24 <adamw> what's the news?
16:04:31 <kparal> daily composes are created
16:04:41 <kparal> here
16:04:42 <kparal> http://dl.fedoraproject.org/pub/fedora/linux/development/17/
16:04:51 <kparal> if it is not there, the build process failed
16:04:53 <kparal> as I was told
16:04:56 <adamw> sounds about right
16:05:02 <kparal> for i386 everything is in place
16:05:09 <kparal> for x86_64 there is a bug in lorax
16:05:14 <kparal> I reported that and it was fixed
16:05:22 <kparal> but not yet updated on the compose server it seems
16:05:30 <kparal> so x86_64 .treeinfo is not present
16:05:46 <adamw> okay
16:06:06 <adamw> so once that's pushed, we should actually be able to set rats up to fire every day automatically?
16:06:14 <kparal> it already does
16:06:19 <kparal> for i386
16:06:24 <kparal> http://autoqa-stg.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=rats_install
16:06:25 <j_dulaney> Coolio
16:06:33 * kparal hopes that link is accessible for everyone
16:06:47 <j_dulaney> Seems to be
16:07:00 <adamw> beans of much coolness
16:07:06 <j_dulaney> All the tests but one are failed, though
16:07:06 <nirik> the composes run in a mock chroot using the dist... so it would need the new anaconda/lorax to be in stable/base repo. ;)
16:07:08 <kparal> I'll say a few words about it and autoqa update topic
16:07:12 <j_dulaney> And the one non-fail is a crash
16:07:28 <adamw> it looks like it hits the bug where anaconda can't shut down correctly after completion
16:07:42 <adamw> so everything is happening correctly in fact
16:07:47 <kparal> adamw: it's the bug with the serial console and bootloader
16:07:53 <adamw> ah
16:07:54 <kparal> which is AFAIK a different bug
16:08:01 <adamw> I see "Traceback will follow cleanup messages."
16:08:04 <adamw> but no traceback
16:08:37 <kparal> ok, have a look here: http://autoqa-stg.fedoraproject.org/results/24213-autotest/qa06.qa.fedoraproject.org/rats_install/results/stage2.log
16:08:37 <adamw> #info kparal found that daily composes do happen, at http://dl.fedoraproject.org/pub/fedora/linux/development/17, and now RATS is set up to run daily against that compose
16:08:47 <kparal> There was an error installing the bootloader. │[10;15H[1K │ The system may not be bootable.
16:08:51 <kparal> at the end
16:08:58 <kparal> not pretty output really :)
16:09:17 <adamw> eek
16:09:25 <adamw> how do you get to there, though? I don't see any link to that
16:09:41 <adamw> i see it if i manually go to http://autoqa-stg.fedoraproject.org/results/24213-autotest/qa06.qa.fedoraproject.org/rats_install/results/
16:09:46 <kparal> it's... complicated :) link to full.log
16:09:51 <kparal> http://autoqa-stg.fedoraproject.org/results/24213-autotest/qa06.qa.fedoraproject.org/rats_install/results/full.log
16:09:57 <kparal> and then link to "All results"
16:09:57 <adamw> oh, yeah, 'all results'
16:10:03 <kparal> http://autoqa-stg.fedoraproject.org/results/24213-autotest/qa06.qa.fedoraproject.org/rats_install/results/
16:10:04 <adamw> well, i guess that's kinda there. :)
16:10:07 <adamw> okay, awesome, thanks!
16:10:26 <kparal> still lot to improve, but basics are working
16:10:33 <kparal> you're welcome
16:11:00 <j_dulaney> kparal:  Could you make it so the results aren't all on one line?
16:11:29 <adamw> we're conserving line feeds
16:11:30 <kparal> I have no idea, it's intercepting everything serial console outputs
16:11:41 <adamw> give a larvage, save a line feed
16:11:48 <kparal> I can look into that
16:11:54 <kparal> or pester hongqing
16:12:12 <kparal> probably yes, some newlines missing
16:13:50 <adamw> okely dokely
16:14:02 <adamw> #topic Fedora 17 Alpha status review
16:14:09 <adamw> so, let's take a look at where we are with alpha
16:14:19 <adamw> somehow go/no-go week has snuck up on us and we still have piles of blockers, le sigh
16:15:04 <adamw> looking at the accepted blockers, they're all really okay except https://bugzilla.redhat.com/show_bug.cgi?id=787461
16:15:51 <adamw> we really need to get the fix for that soon as we need to do some testing and find out if it fixes all the various symptoms noted in the bug
16:16:47 <tflink> adamw: I assume that we're mostly waiting for a new anaconda build/update?
16:17:04 <j_dulaney> It seems to be hit or miss on what symptoms are actually experienced
16:17:34 <adamw> tflink: yup
16:18:05 <adamw> j_dulaney: yeah. in theory all the symptoms _could_ be explained by the bug bcl's fixing, but i'd like to be sure that really is what's causing them.
16:18:07 <j_dulaney> For instance, on test install I did, instead of rebooting, the vm powered off
16:18:27 <j_dulaney> With another test install, the CPU locked up
16:18:27 <adamw> tflink: or even an updates.img would be useful i guess
16:18:47 <tflink> yeah, that's what I meant by update
16:19:04 * tflink wonders if that is a better way to start since the turnaround is faster and no new ISO is needed
16:19:20 <adamw> yeah, if we could get on
16:19:21 <adamw> e
16:19:25 <adamw> i just poked bcl
16:19:26 <tflink> assuming that the updates mechanism is working, anyways
16:19:36 <adamw> #info adamw poked bcl to request an eta on 787461
16:19:43 <adamw> oh, right. point. i think it still isn't.
16:20:31 <tflink> which would be another blocker, no? Or has the new updated.img requirement not gone through yet?
16:21:14 <adamw> as of one hour ago, it has.
16:21:58 <adamw> so yeah, that's another damn thing to worry about. whee.
16:22:09 <adamw> the other unaddressed blocker is jskladan's https://bugzilla.redhat.com/show_bug.cgi?id=787744 ...
16:22:29 <jskladan> adamw: which probably is just some weird interaction with pxe
16:22:39 <jskladan> since i'm unable to reproduce it with 'regular' boot media
16:22:43 * adamw checking cmdline with DVD
16:22:57 <tflink> pxe is still alpha blocker material, isn't it?
16:23:57 * j_dulaney ran into an issue with SELinux blocking NetworkManager, but that was an update.  Still, that may be something to watch out for
16:24:22 <adamw> tflink: i don't know if we have a definite call on that
16:24:43 <tflink> yeah, I don't see it mentioned explicitly
16:25:29 <adamw> it doesn't come under any of the wildcards i can see either
16:25:43 <adamw> it's not a "local or remote package source" or an "interface" really, it's a boot method
16:26:02 <j_dulaney> What about the Plymouth issue?
16:26:08 <adamw> one thing at a time, please
16:26:27 <j_dulaney> Come on, adamw, multitasking!
16:26:37 <jskladan> tflink: adamw: it depends, if you take the  "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled.", then it's a blocker, but IMHO the criterion is used a bit liberately
16:26:43 <adamw> .fire j_dulaney
16:26:43 <zodbot> adamw fires j_dulaney
16:26:53 <j_dulaney> Yay, I can go home
16:27:12 <adamw> jskladan: well, the installer *can* complete an installation with all those options. just so long as you don't try and pxe boot. =)
16:27:21 <jskladan> yup
16:27:27 <adamw> jskladan: but the idea is that that criterion is specifically about the partitioning methods.
16:27:58 <jskladan> if you ask me, i'd not block alpha on this
16:28:07 <j_dulaney> +1
16:28:13 <adamw> we may as well vote on it, yeah
16:28:32 <tflink> do we block any of the releases on it? Final at least, I assume
16:28:39 <adamw> we can consider it a conditional infraction of any number of criteria, but only in the specific case of PXE boot - at least that's our current thinking
16:28:51 <adamw> tflink: final sounds about right
16:28:58 <j_dulaney> Indeed
16:29:11 <adamw> anyone want to argue for PXE boot blocking alpha?
16:29:27 <tflink> maybe beta
16:29:33 <tflink> but no, not alpha
16:29:40 <adamw> okey dokey
16:30:11 * jskladan yay, blocker solved
16:30:14 <jskladan> :)
16:30:16 <adamw> propose agreed 787744 is not an Alpha blocker: it appears to affect PXE boot only, and we don't consider that critical enough to block Alpha
16:30:25 <jskladan> ack
16:30:36 <adamw> QA: solving blockers with the big red NO since 2005
16:30:42 <j_dulaney> +1
16:30:59 <tflink> ack
16:31:06 <adamw> #agreed 787744 is not an Alpha blocker: it appears to affect PXE boot only, and we don't consider that critical enough to block Alpha
16:31:40 <adamw> okay, so we have a couple of proposed blockers we should probably vote on too
16:32:12 <adamw> #topic F17 Alpha status review: mini blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=794899
16:32:23 <adamw> j_dulaney: you're hired again, it's plymouth time
16:32:31 <j_dulaney> Booh
16:32:54 <adamw> this seems pretty straightforward blocker to me, it hits a criterion smack in the face
16:33:01 <j_dulaney> Indeed
16:33:07 <adamw> try an encrypted install, you can't boot because plymouth isn't there to pop up the prompt
16:35:03 <jskladan> adamw: IMHO the LUKS query is there
16:35:20 <jskladan> just lost among all the other text
16:35:37 <adamw> hum, that's a possibility
16:35:47 <adamw> has anyone tested just kinda 'blindly' entering the passphrase?
16:36:01 <jskladan> IMHO it should be enough to smack enter
16:36:16 <jskladan> and you'll get "wrong passphrase, please enter correct password"
16:36:17 <kparal> that would violate the criterion anyway, wouldn't it?
16:36:22 <jskladan> or something like that
16:36:24 <jskladan> prompt
16:36:31 <j_dulaney> Put that as a note in the bug?
16:36:33 <brunowolff> I am able to boot F17 with encrypted devices.
16:36:41 <jskladan> but i'd need someone to try it out
16:36:50 <brunowolff> I did so with an updated system about 40 minutes ago.
16:36:53 * j_dulaney tries
16:37:31 <brunowolff> I do have updates-testing enabled and I pulled in the rc4 kernel and drcaut from this morning. So it's a bit different.
16:38:05 <adamw> brunowolff: was this a fresh install of f17?
16:38:14 <brunowolff> I also had one case (I rebooted a couple of times) where I had to enter a password for each device, rather than reusing the password.
16:38:33 <brunowolff> No it was a yum upgrade about a week ago.
16:38:36 * j_dulaney is doing a fresh install with encrypted fs
16:39:00 <adamw> brunowolff: yum upgrade won't hit this bug, since it's about package set present on the images / installed on installation
16:39:09 <adamw> i.e., you almost certainly have plymouth installed
16:39:34 <adamw> j_dulaney: me, too. let's race.
16:39:48 * jskladan likes race conditions!
16:39:52 <brunowolff> Oh. I remember that. I actually saw that and was puzzled when I was able to removed plymouth without taking most of the system with it.
16:40:09 <brunowolff> I made sure I didn't reboot until I was able to reinstall it.
16:41:01 <adamw> in any case...i'm pretty sure we want to fix this somehow for rc3, call it blocker or nth
16:41:15 <adamw> not having plymouth installed doesn't seem like a good way to go :)
16:41:18 <j_dulaney> adamw is probably on faster hw and will win
16:41:29 <brunowolff> (When I have conflicts I normally remove the packages blocking updates rather than deferring the updates.)
16:41:35 <adamw> shall we just accept it as a blocker, or does anyone strongly not want to take it?
16:41:57 * jskladan is pro-blocker, just offering possible workaround
16:42:00 <tflink> nth might be more appropriate if you can indeed get past the prompts by blindly entering password
16:42:13 <j_dulaney> Indeed
16:42:31 <j_dulaney> If it can be worked around, we don't want to slip, do we?
16:42:45 * j_dulaney notes that live CDs don't seem to have plymouth, either
16:42:49 <adamw> well...i'm not sure how great it looks telling people to just keep typing their passphrase until the boot pops up. =)
16:43:02 <adamw> j_dulaney: yeah, same thing.
16:43:27 <tflink> adamw: true but how do we justify the potential of blocking the release due to that bug?
16:43:36 <brunowolff> Can't we just add a requires from some other package that we know will be installed? People can worry about the best way to do this later.
16:43:56 <kparal> the criteria shouldn't mean "if you can practice black magic, they don't apply"
16:44:03 <tflink> brunowolff: I think that's how F16 pulled it in - dracut required plymouth
16:44:26 <brunowolff> Why not do that as a temporary solution?
16:44:43 <tflink> it would still need to be blocker/nth in order to be pulled in to RC3
16:45:01 <adamw> brunowolff: it's easy enough to fix, which is why i don't want to kick the bug around too much
16:45:21 <adamw> tflink: ultimately the question is 'how obvious does a workaround have to be', i guess
16:45:22 <tflink> kparal: true, but where is the line drawn. There is a rather simple workaround, even if we don't like it
16:45:34 <adamw> tflink: we didn't actually test if there's a workaround yet...
16:46:04 * tflink isn't so much anti-blocker as pro-consistency with how we define blocker/NTH
16:46:09 <kparal> if all users are able to use that workaround without studying release notes, I'm for it
16:46:45 <tflink> I'm definitely +1 NTH, though
16:46:58 <jskladan> kparal: depends, whether you blindly hit enter, when something seems to be stuck /me does
16:47:08 <adamw> okay, to fix the logjam, let's accept it as nth for now and leave blocker status open
16:47:12 <tflink> encouraging users to blindly type in passwords is a bad precedent to set
16:47:14 * kparal quotes "without unintended user intervention"
16:47:23 <tflink> adamw: works for me
16:47:27 <jskladan> adamw: +1
16:47:33 <j_dulaney> +1
16:47:45 <adamw> propose #agreed 794899 is accepted as NTH, blocker status left undetermined as we are investigating how workaround-able the bug is
16:47:49 <j_dulaney> If workaround works, then closer blockerness
16:47:56 <tflink> ack
16:47:58 <j_dulaney> ack
16:48:12 <kparal> I'm +1 blocker +1 nth, whatever wins
16:48:15 <tflink> we should probably start pestering people about comps or dracut, though
16:48:27 <jskladan> adamw: ack
16:48:39 <j_dulaney> .whoowns dracut
16:48:39 <zodbot> j_dulaney: dracut-maint
16:48:51 <j_dulaney> Well, that was informative
16:49:06 <adamw> harald owns dracut.
16:49:10 <adamw> he doesn't want a dep on plymouth.
16:49:19 <adamw> so we either add one in plymouth-scripts , or put it in comps.
16:49:44 <j_dulaney> plymouth-scripts is logical
16:49:55 <j_dulaney> .whoowns plymouth-scripts
16:49:55 <zodbot> j_dulaney: No such package exists.
16:50:49 <adamw> plymouth is halfline.
16:50:52 <adamw> #agreed 794899 is accepted as NTH, blocker status left undetermined as we are investigating how workaround-able the bug is
16:51:11 <adamw> #topic F17 Alpha status review: mini blocker review: bugzilla.redhat.com/show_bug.cgi?id=795164
16:51:17 <adamw> so this is the other blocker we have to vote on
16:51:40 <adamw> drago's somewhat vague keymap issue
16:51:42 <j_dulaney> -1 blocker, +1 nth
16:51:46 * kparal likes the bug title
16:51:51 <adamw> has anyone else tried non-US keymaps and had issues?
16:52:08 * kparal didn't try
16:52:55 <kparal> someone from brno can easily verify it tomorrow
16:53:07 <kparal> I can, for example :)
16:53:31 <kparal> do we have some criterion for that?
16:53:47 <j_dulaney> Not Alpha
16:53:49 <adamw> the 'wiggle paragraph' is more or less originally for keymap issues
16:54:03 <tflink> I don't think it's specific but we do seem to hit keymap issues at some point for every release
16:54:06 <adamw> "There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others..."
16:54:30 <adamw> basically, we decided it was hell to try and write a specific criterion for it, and instead we'd add that wording so we could take keymap bugs as judgment calls
16:54:49 <tflink> so, more triage needed
16:55:00 <kparal> do you see layout indicator when logging in?
16:55:04 <kparal> if you don't, it's tricky
16:55:05 <adamw> yeah, it would be good to know if others can reproduce, if other keymaps are affected etc
16:55:24 <adamw> but we are working to a tight time frame here
16:55:29 <adamw> so we really need to figure that all out today
16:55:53 <adamw> good lord this install is taking forever.
16:55:58 <j_dulaney> Indeed
16:56:33 <j_dulaney> I'm at just under 1/2 done
16:57:39 <kparal> without further information I would say +1 nth, commonbugs if not fixed
16:57:44 <adamw> propose #agreed need more data to determine blocker status of 795164, we should test whether others can reproduce and what keymaps are affected today and re-vote via bug comments
16:58:00 <tflink> adamw: ack
16:58:20 <j_dulaney> ack
16:58:31 <jskladan> ack
16:59:30 <adamw> #agreed need more data to determine blocker status of 795164, we should test whether others can reproduce and what keymaps are affected today and re-vote via bug comments
16:59:58 <adamw> okay, we're running long so let's skip the nth
17:00:27 <adamw> #topic Release criteria & validation test update round-up
17:00:51 <adamw> we can also compress this one - i was gonna kick in a quick summary of all the changes that have been implemented recently as part of the retrospective work
17:03:48 <adamw> so lessee, we now require all installation interfaces to work at final, we've tweaked the installer bug reporting criterion, dropped efidisk.img test case, added a criterion for memtest to be present, require updates.img from HTTP to work, required checksums to be provided, and re-jigged the level of quite a lot of test cases in the validation matrix to properly reflect the criteria
17:04:14 <adamw> we also have a spanking new set of USB boot test cases from josef
17:04:32 <adamw> did anyone have any concerns or queries about that big pile o' changes?
17:04:45 <j_dulaney> Not I
17:06:15 <adamw> #info we now require all installation interfaces to work at final, we've tweaked the installer bug reporting criterion, dropped efidisk.img test case, added a criterion for memtest to be present, require updates.img from HTTP to work, required checksums to be provided, and re-jigged the level of quite a lot of test cases in the validation matrix to properly reflect the criteria, and we have a big set of new USB boot test cases
17:07:59 <adamw> moving along!
17:08:05 <adamw> #topic Upcoming QA events
17:08:22 <adamw> we don't really have any 'events', but the go/no-go is on wed, so we'll want to get rc3 done today or tomorrow and tested
17:08:36 <adamw> good thing is, at alpha we have far fewer tests that need to be done
17:08:54 <adamw> first test days are coming up in a couple of weeks, is everything peachy in test day land j_dulaney?
17:09:11 <j_dulaney> adamw:  I need to poke a couple of people
17:09:16 <j_dulaney> adamw:  Otherwise, yes
17:09:34 <adamw> cool. is that dnssec one on your list for followup?
17:09:41 <j_dulaney> Indeed
17:09:48 * j_dulaney thinks that looks bloody cool
17:10:19 <adamw> awesomeness.
17:11:34 <adamw> #topic AutoQA update
17:11:41 <adamw> kparal: want to speed through this one?
17:11:46 <adamw> #chair tflink kparal
17:11:46 <zodbot> Current chairs: adamw kparal tflink
17:12:06 <kparal> well the most important change was rats_install
17:12:13 <kparal> we already discussed that one
17:12:21 <kparal> basically it seems working well
17:12:28 <kparal> some polish is still needed of course
17:12:41 <kparal> and we're stuck at serial console bootloader bug
17:13:15 <kparal> apart from that, it runs every day and performs an automated installation
17:13:28 <adamw> #info rats_install is now up and running daily and reporting results
17:13:37 <kparal> #link http://autoqa-stg.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=rats_install
17:14:31 <kparal> I might spend this week on finding F17 blocker bugs, so I don't have any further progress planned
17:14:39 <kparal> but I'd like to release AutoQA 0.8 soon
17:15:09 <adamw> no, don't do that.
17:15:13 <adamw> we don't need to find any *more* blockers.
17:15:16 <jskladan> kparal: going to submit few blockers 3 hours before meeting? :))
17:15:17 <adamw> we've got quite enough already ;)
17:15:25 <kparal> I haven't even started!
17:15:43 <adamw> jskladan: quick, take away kparal's power cord and tie him up
17:16:06 <j_dulaney> adamw:  Can't you actually fire him?
17:16:19 <kparal> my notebook today died, I suspect jskladan or pschindl
17:16:26 <adamw> j_dulaney: i haven't paid him for months, he just keeps showing up
17:16:53 * jskladan blaims karma
17:17:14 <j_dulaney> adamw:  Doesn't that apply to me as well?
17:17:21 <adamw> well, *I* wasn't going to say it
17:17:21 <kparal> tflink actually had some ideas regarding automated testing by using a different approach, maybe he'll write up some email
17:17:48 <kparal> anyway, that's all from autoqa I think
17:17:54 <adamw> okely dokely
17:18:18 <adamw> #topic open floor
17:18:18 <tflink> kparal: yeah, I got distracted at the end of last week with some bugs
17:18:48 <adamw> #info tflink has grand plans, again
17:18:54 <kparal> :)
17:19:07 <tflink> adamw: you have no idea. I don't talk about all my grandiose ideas :)
17:19:11 <j_dulaney> edos
17:19:24 <j_dulaney> It's cool stuff
17:19:31 <adamw> tflink: for the record, invading Russia has historically usually ended poorly
17:19:51 <j_dulaney> Just don't do it in the winter
17:20:04 <tflink> adamw: will keep that in mind
17:21:14 <adamw> anything else for open floor?
17:21:16 * satellit_ FYI 783712  wireless works on KDE-sugar HD install after much updating  : ) do not know what fixed it
17:21:52 <j_dulaney> Kernel
17:22:20 <adamw> the wireless issue was a kernel bug?
17:22:44 <j_dulaney> Indeed
17:23:05 <adamw> viking-ice thinks it's ConsoleKit
17:23:28 <j_dulaney> At least, that's what I have been told
17:23:34 <j_dulaney> Is that it was kernel
17:23:34 <Viking-Ice> yup
17:23:43 <j_dulaney> Hmm
17:24:14 <Viking-Ice> nm complained about missing consolekit and there are atleast 3 bug reports against nm in F17 that are duplicates of that problem
17:24:23 <adamw> i know kernel dropped the use of bleeding-edge wireless modules on feb 15 because it was causing too many problems
17:24:54 <adamw> we're probably going to get git7.2 into rc3, which has that wireless change
17:25:07 <adamw> so if we also get ConsoleKit pulled in somehow...that should hit both angles
17:25:36 <j_dulaney> One of the recent kernels wouldn't boot
17:25:43 <j_dulaney> So, beware that
17:25:54 <j_dulaney> I think it was depreciated rather quickly
17:26:03 <j_dulaney> Never got out of updates testing
17:26:09 <adamw> 7.1, i think it was
17:26:19 <Viking-Ice> speaking of kernel to add to the NTH for 3.3 rc4 It works just fine on my laptop ( totally error free )
17:27:20 <adamw> okay, so let's close with the alpha laundry list...
17:27:26 <adamw> we need to:
17:27:33 <adamw> 1) decide on a way to get plymouth in
17:27:42 <adamw> 2) triage the keymap issue
17:27:59 <adamw> 3) test the fix for 787461 - http://bcl.fedorapeople.org/updates/787461.img
17:28:09 <adamw> 4) decide what to do about ConsoleKit
17:28:39 <adamw> i think that's 'all'
17:28:42 <brunowolff> Note that the first rc4 build has debugging off and shouldn't be used for alpha.
17:29:04 <adamw> oh, forgot to note, bcl says updates.img should be fine with the current anaconda code, it's only the not-let-landed noloader branch where updates.img support is broken
17:29:22 <tflink> that one should be lots of fun
17:29:35 <tflink> but we don't have to worry about it much til' beta
17:29:35 <Viking-Ice> brunowolff, they turned of debugging hum why ?
17:29:49 <Viking-Ice> they must have done so at request I believe
17:30:33 <adamw> Viking-Ice: they turn off debugging for one build per kernel release
17:31:16 <Viking-Ice> adamw, yeah but dont they only do that for the final release as in when 3.3 should have been released ?
17:32:27 <adamw> no, it's always been at rc stage.
17:32:38 <adamw> well, 'always'...they only started doing it this cycle.
17:33:15 <Viking-Ice> anyway they themselves requited nth which included the rc4 release so they themselves have to create another build with it turned back on =)
17:33:49 <adamw> i don't think we need rc4 to satisfy the nth
17:34:00 <adamw> rc3.git7.2 should be fine
17:34:05 <adamw> and is the current update
17:34:41 <Viking-Ice> ok they just did not want to experience abrt dupe fest
17:35:00 <adamw> i think git7.2 fixes that.
17:35:19 <Viking-Ice> ok let's move along
17:35:20 <adamw> okay, let's wind this puppy up
17:35:24 <satellit_> +1 on git 7.2 for wireless
17:35:26 * j_dulaney hasn't noticed that bug with git7.2
17:35:32 <adamw> looks like we're getting PA and NM builds with the CK fixes
17:35:55 <adamw> anything else, or shall we all go start drinking?
17:35:56 <j_dulaney> The only worry I have is I had some SELinux issues with NM
17:36:50 <Viking-Ice> do we request selinux to report no errors for alpha?
17:36:59 <adamw> j_dulaney: no, but if the errors actually break stuff that's bad
17:37:01 <Viking-Ice> makes sense to default to permissive mode for the spin
17:37:18 <Viking-Ice> we  get the reports without breakage
17:38:12 <j_dulaney> adamw:  SELinux broke NM
17:38:27 <adamw> j_dulaney: erf. that may be a problem since we want to pull a newer NM build to fix the wireless issue
17:38:29 <j_dulaney> This was an update, and I haven't been able to reproduce
17:38:46 <j_dulaney> adamw:  I don't think it was a NM update that broke
17:38:49 <adamw> j_dulaney: so as things stand I'd expect RC3 to include selinux-policy -89 and NM https://admin.fedoraproject.org/updates/FEDORA-2012-1909/NetworkManager-0.9.3-0.2.git20120215.fc17
17:39:00 <adamw> j_dulaney: if you can reproduce with those two packages, let us know...
17:39:05 <adamw> i'll check it also
17:39:09 <j_dulaney> adamw:  Roger
17:39:25 <adamw> thanks for the heads-up
17:39:35 <adamw> did you file the selinux alert?
17:40:19 <j_dulaney> adamw:  Not yet, will do, though
17:40:38 <adamw> yeah, dan may have thoughts.
17:40:59 <j_dulaney> adamw:  I was trying to get a better grip on what was happening
17:41:38 <adamw> alrighty, one more try to escape
17:41:44 * adamw sets fuse for one minute
17:41:48 <jskladan> adamw: http://memegenerator.net/instance/14918673
17:42:36 <adamw> jskladan: we should probably block that site from the brno internet connection, i think your productivity would increase 250% ;)
17:42:57 <kparal> futile attempt
17:43:32 <j_dulaney> He'll just proxy into fedorapeople
17:44:16 <jskladan> aaaand, the minute has expired, i guess
17:44:20 <adamw> ding!
17:44:22 <jskladan> http://memegenerator.net/instance/14918742
17:44:23 <adamw> thanks everyone
17:44:33 * adamw gags jskladan
17:44:35 <kparal> :D
17:44:35 <adamw> #endmeeting