f17-final-blocker-bug-review-1
LOGS
17:01:01 <tflink> #startmeeting f17-final-blocker-bug-review-1
17:01:01 <zodbot> Meeting started Fri Apr 20 17:01:01 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:01 <tflink> #meetingname f17-final-blocker-bug-review-1
17:01:01 <zodbot> The meeting name has been set to 'f17-final-blocker-bug-review-1'
17:01:06 <tflink> #topic Roll Call
17:01:34 * brunowolff is here
17:01:39 <tflink> who's ready for the wonderful fun that is the first final blocker review meeting
17:02:09 <brunowolff> At least I don't have to worry about taxes this weekend. I might actually get some Fedora stuff done.
17:04:12 <tflink> I'm just glad that I remembered to do mine - I didn't even think about it until last friday
17:04:17 * satellit_Tris55R listening
17:04:30 <tflink> satellit_Tris55R: welcome to the party
17:04:51 <satellit_Tris55R> : )
17:06:11 <tflink> any volunteers to play secretary?
17:08:15 * tflink is still waiting for enough people to have a quorum
17:09:07 <zaza224_> hello
17:09:23 <tflink> zaza224_: hello. you here for the blocker review meeting?
17:10:22 <Octayn> I am
17:10:27 <zaza224_> no, I just dropped in to see what was happening; I thought the meeting started at 21:00
17:10:35 <tflink> other than brunowolff, is anyone planning to vote? It sounded like most of the people are planning to be mostly lurking
17:11:08 <brunowolff> I plan to vote, but could get interrupted since I'm at work.
17:11:21 <adamw> yo
17:11:26 <adamw> i'm votin'
17:11:38 <tflink> adamw: I was wondering where you went :)
17:11:59 <adamw> i was trying to send you that email
17:12:03 <adamw> fighting the vagaries of gpg
17:13:11 <tflink> well, I suppose we should get started. if we lose quorum, we'll just have to start hunting down more people to help :)
17:13:47 <tflink> still don't have a volunteer to be secretary, though
17:13:55 <Octayn> What does that involve?
17:14:30 <tflink> Octayn: translating the decisions made here to bz (modifying the whiteboard and providing a summary of the decision)
17:15:26 <tflink> #topic Introduction
17:15:41 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:15:57 <tflink> We will be following the list of current blockers at:
17:16:03 <Octayn> I'm still a newb but I can do it if you hold my hand a little
17:16:10 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:16:40 <tflink> The process for the meeting is outlined at:
17:16:43 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:17:02 <tflink> And the release criteria for F17 are found at:
17:17:05 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:17:12 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:17:14 <brunowolff> Wow, this is going to be a long meeting I think.
17:17:16 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
17:17:21 <tflink> brunowolff: no kidding
17:17:29 <tflink> up for review today are:
17:17:37 <tflink> #info 31 proposed blockers
17:17:37 <tflink> #info 5 accepted blockers
17:17:37 <tflink> #info 10 proposed NTH
17:17:38 <adamw> tflink: i didn't catch up with secretaryizing the LAST meeting yet :/
17:17:42 <adamw> i'll do this one as we go along.
17:17:44 <adamw> oh holy shit.
17:18:26 <tflink> Octayn: do you have access to the whiteboard in BZ? I don't think that we ever got the wider bz permission thing figured out
17:18:47 <tflink> adamw: yeah, I'm regretting skipping the meeting last week
17:18:57 <tflink> but this list has been pretty long for a while
17:19:12 <tflink> unless there are any objections, I'm going to start with the proposed blockers
17:19:21 <Octayn> tflink: I don't believe so
17:20:02 <adamw> go for it
17:20:07 <adamw> tflink: i'll do the secretarying
17:20:18 <tflink> adamw: thanks
17:20:46 <tflink> Octayn: if you're interested in helping, we can get you the appropriate bz permissions after the meeting
17:20:56 <Octayn> tflink: sure, thanks!
17:21:05 <tflink> diving in ...
17:21:08 <tflink> #topic (755335) Shutting down while auto-updating breaks the system
17:21:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=755335
17:21:08 <tflink> #info Proposed Blocker, NEW
17:21:24 <adamw> Octayn: if you want to see what the secretaryization stuff looks like, just keep an eye on the bugs we discuss - look at each one a few minutes _after_ we finish discussing it and you should see a comment and a couple of changes to the blocks: and whiteboard: fields from me
17:22:12 <adamw> this one seems nasty.
17:22:13 <tflink> hrm, this sounds kind of nasty but I don't think it directly hits any of the release criteria
17:22:23 <adamw> when did we switch to auto-installing updates? 16?
17:22:34 <tflink> I didn't think we had switched to that
17:22:38 <adamw> final, 15: "All known bugs that can cause corruption of user data must be fixed or documented at Common F17 bugs"
17:22:48 <adamw> maybe a bit of a stretch, _probably_ can't hit that
17:22:57 <adamw> tflink: we auto-install security updates
17:23:32 <adamw> look at 'software settings', the box marked 'Automatically install:' - it's set by default to 'Only security updates', it was changed in 15 or 16 or so
17:24:02 <tflink> hrm, I guess that i've never noticed
17:24:10 <tflink> then again, I tend to avoid PK
17:24:38 <adamw> well, you can't really 'avoid' this, it just sort of happens
17:24:50 <adamw> (unless you remove packagekit, of course.)
17:25:27 <adamw> it's easy not to actually notice it happening, though, it doesn't really tell you what it's doing. sometimes when PK is blocking yum, it's because it's installing updates. hey, actually, i wonder if this is the cause of that bug about PK blocking yum 'too much'.
17:25:48 <tflink> that would fit
17:25:54 <adamw> how about alpha "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"?
17:26:05 <adamw> if you hit this bug, it can leave the rpm/yum database screwed, no more installing updates...
17:26:26 <brunowolff> The issue itself is fixable in an update. I am thinking this isn't a blocker.
17:26:27 <tflink> yeah, I think that I'm +1 blocker on this even if we have to shoehorn it in a bit
17:26:52 <adamw> brunowolff: that is a consideration, but it does seem like anyone doing an install from DVD has a reasonable chance at hitting this
17:27:08 <adamw> do a DVD install, boot the installed system up, click around a bit, (auto-update happens to kick off in background), shutdown, boom
17:27:36 <Octayn> Would using smaller transactions with rollbacks on shutdown help mitigate this?
17:27:44 <Octayn> Or is changing the transactions not something that can happen.
17:27:55 <brunowolff> Is this a regression from how things have been in the past?
17:28:14 <tflink> Octayn: I doubt that would happen this late in the release but that sounds like a possible solution
17:28:16 <adamw> i don't think we know that
17:29:05 <tflink> it sounds like we're at ~ +2/-1 ATM
17:29:08 <tflink> any other thoughts?
17:29:22 <adamw> brunowolff: the fact that we didn't do auto-update until f15 is significant, though
17:30:14 <tflink> if this has been possible for ~ 1 year and this is the first report, that says something for how common it is, though
17:30:33 <adamw> the bug was reported against 16 in november
17:30:49 <adamw> kparal's 'colleague' hit it and then kamil reproduced it and nominated it as blocker last week
17:30:55 <adamw> so that's three occurrences (one intentionally produced) at least
17:30:57 <tflink> ah, I missed that part
17:31:25 <adamw> other people may well have hit it and not known what happened - it's a long way from 'i rebooted and now my system doesn't seem to be working quite right' to 'hey, i must have shutdown while an automatic update was happening'
17:31:37 <adamw> especially since we don't give the user any info that an automatic update is happening...
17:31:40 <tflink> also true
17:31:53 <brunowolff> It may also be that most of the time a busted transaction doesn't hose the machine.
17:32:01 <adamw> since we don't triage every bug filed, it's hard to know if there are other filed bugs which actually were caused by this.
17:32:02 <adamw> brunowolff: yup
17:32:12 <adamw> or at least some of the time.
17:32:25 <tflink> proposed #agreed - 755335 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:32:38 <tflink> ack/nak/patch?
17:32:45 <adamw> ack
17:33:06 <brunowolff> I'm a pretty weak -1, so I don't object to being outvoted and will ack the proposal.
17:33:27 <adamw> i'd be open to changing to -1 if we get info from dan that this isn't as bad as it sounds, of course.
17:33:35 <tflink> same here
17:33:55 <tflink> #agreed - 755335 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:34:08 <tflink> #topic (810530) PackageKit locks out yum way too often & for too long
17:34:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810530
17:34:08 <tflink> #info Proposed Blocker, ASSIGNED
17:35:13 <tflink> I'm not sure this is so much a blocker as it is a feature request
17:36:13 <tflink> I think it's worse in F17 but I've hit this in F15 and F16, too
17:36:17 <brunowolff> I'm -1 blocker, though I will admit I don't like auto updates and disable them myself.
17:36:25 <tflink> possibly earlier releases that I'm not remembering off hand
17:36:49 <tflink> I think that I'm -1 blocker, -1 NTH
17:37:15 <brunowolff> I think the kind of people that manually run yum to do updates, should be able to turn off or slow down automatic updates.
17:37:18 <tflink> less -1 blocker than I am -1 NTH, though. This doesn't seem like something that we should be changing post-freeze unless it's a blocker
17:37:34 <tflink> yeah, my usual workaround is to kill the pk process
17:38:35 <adamw> Octayn: if you look at the previous bug now, you can see the 'secretaryization' changes
17:38:35 <adamw> tflink: if i'm right, the auto-security updates may explain this
17:38:49 <adamw> it would explain why it seems 'worse' lately
17:39:00 <adamw> we've had the repos frozen for like a month because of beta delays
17:39:08 <adamw> so there are probably a pile of updates in updates-testing marked as 'security'
17:39:18 <tflink> proposed #agreed - 810530 - RejectedBlocker RejectedNTH - While an annoyance, this doesn't hit any of the F17 release criteria and doesn't seem wise to take as an NTH fix
17:39:27 <adamw> so shortly after a new f17 beta install, you'll presumably have a fairly long-running PK process in the background installing security updates...
17:39:34 <adamw> i'm guessing that's what a lot of people have seen. but i'm not sure.
17:39:53 <adamw> i think ack...this one _does_ seem like it could be fixed with updates, too.
17:40:01 <brunowolff> ack
17:40:11 <tflink> #agreed - 810530 - RejectedBlocker RejectedNTH - While an annoyance, this doesn't hit any of the F17 release criteria and doesn't seem wise to take as an NTH fix
17:41:28 <tflink> For anyone who's interested/new -  if you have any questions about the process we're going through, feel free to ask. We like new people :)
17:41:38 <tflink> #topic (737508) grub2 cannot install when /boot is md and first partition starts at sector 63
17:41:41 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=737508
17:41:44 <tflink> #info Proposed Blocker, NEW
17:44:13 <adamw> i'm still -1 on this one, even with kparal's new reasoning.
17:44:24 <adamw> we just can't do enough to 'mitigate' this to make it reasonably release-blocking.
17:44:25 * tflink is still wading through the comments
17:44:52 <adamw> tflink: you probably only really need #56.
17:46:22 <tflink> yeah, I'm not sure about blocker on this
17:46:42 <tflink> putting /boot in LVM is non-default, no?
17:46:48 <adamw> yeah.
17:47:07 <adamw> i'd want to consider the windows criterion as a very narrow one
17:47:12 <tflink> then I'm a weak -1 on this
17:47:21 <tflink> it's too much of a corner case
17:47:26 <adamw> as long as we possibly _can_ get dual boot to work, that's good enough. we really can't go around trying to support every possible dual-boot permutation.
17:47:43 <tflink> agreed
17:48:42 <tflink> proposed #agreed - 737508 - RejectedBlocker - While this bug does affect dual-booting with windows - it's using a non-standard partition layout and was deemed too much of a corner case to take this as a blocker
17:48:46 <tflink> ack/nak/patch?
17:49:48 <brunowolff> Does this actually break existing setups, or just fail to install? I tried quickly reading through the bug, but it had a lot of notes and took a few twists.
17:50:10 <tflink> yeah, it sounds like there was some confusion in the middle there
17:50:13 <adamw> ack
17:50:29 <tflink> as I'm understanding it, the windows install would still work but the linux partition would be fubar
17:50:37 <tflink> s/partition/install
17:50:52 <brunowolff> If it is just fails to install, I don't think it is a blocker.
17:50:57 <tflink> or would the whole thing be fubar if you're using grub to chainload windows
17:51:21 <tflink> this should probably be documented, though
17:51:35 <tflink> do you have to do a custom layout if you're installing alongside windows?
17:52:05 <adamw> brunowolff: i think in most cases it shouldn't. it _might_ cause problems on upgrade, but even then, the old grub should usually work.
17:52:06 <adamw> the ultimate upshot of the bug is grub2 doesn't get installed to the MBR, but it shouldn't result in whatever was there previously being wiped. if what was there before was the Windows bootloader, I can't see why it wouldn't continue to work.
17:52:53 <brunowolff> ack (the proposal)
17:53:08 <tflink> #agreed - 737508 - RejectedBlocker - While this bug does affect dual-booting with windows - it's using a non-standard partition layout and was deemed too much of a corner case to take this as a blocker
17:53:14 <adamw> tflink: no, you don't.
17:53:39 <tflink> ok, I can't dual-boot on my current machine and I hadn't done it in a while
17:53:49 <adamw> tflink: if you know what you're doing, you resize the windows partition ahead of time so there's free space, or just leave free space when installing windows in the first place
17:53:49 <tflink> #topic (748209) KeyError: '/boot/efi': anaconda will try to do an EFI install if there is an existing EFI system partition but it has not been set as /boot/efi
17:53:52 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=748209
17:53:54 <tflink> #info Proposed Blocker, ON_QA
17:54:04 <adamw> then you can tell anaconda 'use free space' and it'll do a typical fedora filesystem layout - separate /boot, LVM root and /home - in the free space
17:54:18 <tflink> adamw: yeah, I usually install windows first in a limited area and install fedora in the remaining free space
17:54:19 <adamw> if you don't know what you're doing, you can try and resize NTFS partition during install, which also isn't 'custom layout;
17:54:34 <adamw> either of those ought to work, from the standpoint of this bug anyhow.
17:54:36 <tflink> oy, 3 bugs in 45 minutes ... nice and fast :)
17:54:54 <adamw> :/
17:54:59 <adamw> -1 on this. too corner case-y.
17:55:18 <adamw> oh, actually. hold that.
17:55:42 <adamw> humph. i am in two minds, apparently. =)
17:56:00 <adamw> so...it's bad form, like i said in my proposal. but it's probably not really serious enough to be blocking.
17:56:29 <adamw> it'll be fixed ahead of freeze anyway, so kinda academic. i either withdraw the proposal or vote -1, whichever.
17:56:30 <tflink> maybe more so as we get more uEFI systems but right now, I agree
17:56:48 <Octayn> It looks like there is already a fix, too?
17:56:54 <adamw> you still have to be installing alongside a native EFI install of something else and do something 'wrong' (though easy to get wrong) in manual partitioning to hit this.
17:57:09 <adamw> actually, you're probably more likely to get it wrong than right. but still, meh.
17:57:24 * adamw goes to lay in some beer
17:57:41 <tflink> proposed #agreed - 748209 - RejectedBlocker - This is too much of a corner case to block release for. Making a mistake in custom partitioning is required in order to hit this and it only affects EFI systems with pre-existing installs
17:57:45 <brunowolff> I'm leaning -1, but since its academic, I don't think we need to spend too much time on this one.
17:57:52 <brunowolff> ack
17:58:05 <tflink> on a related note, I'm wondering if we should do a test image w/  the new anaconda
18:00:01 <tflink> #agreed - 748209 - RejectedBlocker - This is too much of a corner case to block release for. Making a mistake in custom partitioning is required in order to hit this and it only affects EFI systems with pre-existing installs
18:00:07 <adamw> back
18:00:12 <tflink> #topic (784828) boot option 'noselinux' doesn't work
18:00:12 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=784828
18:00:12 <tflink> #info Proposed Blocker, ASSIGNED
18:00:46 <warren> Is it broken in F16 too?
18:01:02 <brunowolff> -1 blocker. You can use selinux=0 as a work around.
18:01:15 <tflink> warren: I don't think so, I believe this was due to noloader
18:01:40 <brunowolff> If fact Will's comment suggests that people should be usning selinux=0 inpreference to noselinix.
18:01:41 <tflink> brunowolff: does that actually work for installing w/o selinux?
18:02:18 <tflink> I read that as "this might change to selinux=0 in the future" rather than "it works today"
18:02:31 <brunowolff> I am not sure. The bug said using selinux=0 worked, but maybe this was in a different place?
18:03:05 * tflink missed that line - needs to start reading more slowly
18:03:23 <tflink> yeah, I'm probably -1 blocker on this too
18:03:39 * adamw seems to recall we have a criterion about this, don't we?
18:03:57 <tflink> I don't see it for F17, though
18:04:03 <tflink> I remember it for F16
18:04:53 <tflink> the one I was thinking of was for F16 final - "The installed system must run normally if the user chooses to install without SELinux "
18:05:02 <tflink> not quite what is here, though
18:05:26 <adamw> yeah
18:05:32 <adamw> and if there's a parameter that works anyway...-1
18:05:44 <tflink> proposed #agreed - 784828 - RejectedBlocker - There are no release criteria around being able to install w/o SELinux and using 'selinux=0' is an acceptable workaround
18:05:51 <adamw> ack
18:07:05 <brunowolff> ack
18:07:18 <tflink> #agreed - 784828 - RejectedBlocker - There are no release criteria around being able to install w/o SELinux and using 'selinux=0' is an acceptable workaround
18:07:32 <tflink> #topic (790348) If specified repo= doesn't contain package repository, fall back to default online repos
18:07:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=790348
18:07:38 <tflink> #info Proposed Blocker, NEW
18:09:48 <adamw> so afaict this is the bug for 'you can't specify an incomplete repo with repo=', basically
18:09:57 <tflink> sounds like a pretty clear blocker with the new criterion
18:10:11 <adamw> you should be able to specify a repo which only has squashfs.img in it, and pull packages from somewhere else. or a repo which has a few packages in it, and pull the rest of the packages from somewhere else. but you can't.
18:11:26 <adamw> so i'm +1, i think.
18:11:39 <brunowolff> +1 blocker
18:12:23 <tflink> proposed #agreed - 790348 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to r
18:12:31 <brunowolff> ack
18:13:10 <adamw> ack
18:13:17 <tflink> #agreed - 790348 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run.
18:13:20 <adamw> wow, this is some nice beer.
18:13:23 <tflink> #topic (800609) maximum window size is 800x600, should be full screen
18:13:26 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=800609
18:13:28 <tflink> #info Proposed Blocker, MODIFIED
18:13:52 <tflink> not sure this is a blocker
18:14:10 <brunowolff> -1 blocker, but it seems to have a fix, so i won't fight hard.
18:14:53 <tflink> proposed #agreed - 800609 - RejectedBlocker - This doesn't prevent the installer from functioning and doesn't hit any of the F17 release criteria
18:15:36 <brunowolff> ack
18:15:43 <Octayn> What are the criterion for a NTH?
18:15:54 <adamw> bcl proposed it as a blocker
18:16:01 <adamw> so i'd probably want to at least ask him why...
18:16:08 * adamw doesn't feel like he understands the bug entirely
18:16:44 <adamw> shouldn't this be closed anyhow?
18:16:54 <tflink> Octayn: there aren't many formal requirements around NTH, mostly that it would be impossible/difficult to fix with an update in addition to having enough impact to justify breaking freeze for a fix
18:17:19 <brunowolff> I'm not authorized to view the referenced bug.
18:17:22 <tflink> the blocker bugs for the non-primary DEs (XFCE, Sugar etc.) fall into this
18:18:02 <tflink> referenced bug?
18:18:17 <adamw> 750764
18:18:23 <tflink> nvm, I was looking at the wrong bug
18:18:25 <brunowolff> bug 750764
18:18:32 <adamw> brunowolff: it's a RHEL bug. i can't see any particular reason it's marked as confidential. it's just about bad handling of dual displays.
18:18:48 <tflink> I thought that we had a fedora bug about that, anyways
18:19:02 <brunowolff> I was wondering if it had more info on how fixed this actually is now?
18:20:33 <adamw> 800609 can be closed, according to bcl.
18:20:34 <adamw> so move on.
18:20:40 <adamw> whatever it was, it's in anaconda now. =)
18:21:05 * adamw closes bug
18:21:09 <brunowolff> ack
18:21:10 <tflink> yay for not knowing what's going on!
18:21:13 <adamw> yay
18:21:17 <adamw> now you know how i feel all the time!
18:21:40 <tflink> #info 800609 has been fixed and closed - it doesn't need to be evaluated as a blocker any more
18:21:58 <tflink> adamw: it doesn't matter if you know what you're doing ... as long as it looks like you do :)
18:22:13 <tflink> #topic (804846) dracut fails to retrieve network kickstart file, possibly PXE-specific, timing issue
18:22:16 <adamw> tflink: words to live by!
18:22:17 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804846
18:22:19 <tflink> #info Proposed Blocker, NEW
18:22:50 <tflink> I have yet to hit this in my PXE testing
18:23:32 <tflink> and I'm wondering if this is related to the PXE+incomplete repo thing
18:24:17 <adamw> i don't immediately see how, he seems to be using public repos
18:24:26 <brunowolff> This one sounds intermittant, which would be different.
18:24:30 <adamw> method=http://fedora.cora.nwra.com/development/17/x86_64/os/
18:24:54 <adamw> and k.wic used dl.fedoraproject.org
18:24:56 <brunowolff> The later comments suggest a problem with network setup.
18:26:22 <tflink> those options look funny, though
18:26:52 <tflink> do we have any docs on how the anaconda options are changing?
18:27:00 <adamw> method= is a synonym for repo=, iirc
18:27:15 <adamw> https://fedoraproject.org/wiki/Anaconda/Options
18:27:15 <tflink> I was looking at the inst.repo and inst.ks
18:27:26 <adamw> should be functionally identical to repo= and ks=
18:27:36 <adamw> wwoods wants them all to be prefixed with inst. in future, for some reason.
18:27:44 <tflink> _should_ - sure but is it?
18:28:21 <adamw> er, i think so. =)
18:28:35 <adamw> could just be some kinda timing thing?
18:28:39 * adamw has no handle on this.
18:29:09 <tflink> yeah, it might be timing or some other obscure thing w/ dracut
18:29:39 <tflink> it seems ironic to me that we moved to systemd to get away from obscure shell magic yet we seem to be diving head first into dracut
18:30:11 <tflink> punt until we have more data?
18:30:29 <tflink> just because I'm not seeing this doesn't mean that it isn't a bug or a blocker
18:30:45 <tflink> the confusion around new args for noloader isn't helping
18:31:17 <tflink> an interesting difference - I'm not using hostnames, just straight ipv4
18:31:24 <adamw> yeah, maybe try and get everyone to test with as close as possible to the same setup as possible and see what happens
18:31:36 <adamw> IPs?
18:31:37 <adamw> interesting
18:31:50 <tflink> could be a nameserver issue
18:32:31 <tflink> proposed #agreed - 804846 - We need more data on this before voting on it - it would be nice if the reporters could all test with as close to the same setup as possible
18:33:53 <brunowolff> ack
18:34:18 <adamw> ack
18:34:23 <tflink> #agreed - 804846 - We need more data on this before voting on it - it would be nice if the reporters could all test with as close to the same setup as possible
18:34:34 <tflink> #topic (806931) "network --device link --activate" in kickstart inside initrd.img breaks anaconda
18:34:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=806931
18:34:39 <tflink> #info Proposed Blocker, ASSIGNED
18:35:30 <tflink> I think this is already accepted
18:35:58 <tflink> nvm, I spoke too soon
18:36:43 <adamw> yeah...we don't have a criterion that covers kickstart contents, really
18:36:51 <adamw> it seems like a tricky area
18:37:53 <adamw> so..it seems like the bug here is 'if you use ks=file:/blah.cfg and specify network --device link --activate in the kickstart file, you get trouble'
18:37:58 <adamw> if the kickstart doesn't have that line you're okay
18:38:11 <adamw> if the kickstart has that line but you source it via http or nfs you're okay
18:38:13 <tflink> doesn't that suggesst that the syntax is invalid?
18:38:18 <tflink> oh
18:38:19 <adamw> no, it's valid syntax.
18:39:41 <tflink> with the criteria written as is, I'm -1 on this
18:40:53 <brunowolff> Since there are easy work arounds, I am -1 blocker.
18:41:17 <adamw> i'm with tflink..as things stand we don't cover this, but, maybe we want to.
18:41:29 <tflink> define workarounds - I don't think there is one for the install automation that hits this regularly
18:41:57 <tflink> adamw: the problem in my mind is how to phrase it. If we have a release criterion for anaconda syntax, that implies that we need to test everything
18:42:36 <adamw> yeah, it's a tricky area.
18:42:40 <tflink> either way, not a discussion we need to have here, I think
18:44:18 <tflink> proposed #agreed - 806931 - RejectedBlocker - This does not hit any of the release criteria as currently written - if the criteria change to make this a blocker, please re-propose
18:45:31 <adamw> ack
18:45:55 <Octayn> Why is secratarying needed? it seems the meetbot stuff is pretty consistent, is there something particularly bad about having an automated script do it?
18:46:05 <tflink> #agreed - 806931 - RejectedBlocker - This does not hit any of the release criteria as currently written - if the criteria change to make this a blocker, please re-propose
18:46:16 <tflink> Octayn: someone would have to write the code to go through and make the changes
18:46:29 <tflink> it's been on my list of stuff to do for a while but I've never gotten around to it
18:46:51 * Octayn can write code, what would it be an extension to meetbot?
18:47:15 <tflink> Octayn: i think it would be better as a standalone script since bugzilla logins would be needed
18:47:46 <tflink> #topic (811242) PXE and repo=nfs or repo=nfsiso freezes installer
18:47:46 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=811242
18:47:46 <tflink> #info Proposed Blocker, NEW
18:49:15 <tflink> this does seem like a pretty clear blocker with the new criterion
18:49:24 <adamw> seems like it...
18:49:27 <adamw> have you reproduced this
18:49:28 <adamw> ?
18:49:46 <tflink> proposed #agreed - 811242 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to r
18:49:52 <tflink> adamw: haven't tried, to be honest
18:50:03 <tflink> all my PXE testing has used http sourced repos
18:50:47 <tflink> my nfs setup is currently borked and I haven't spent the time to fix it
18:51:10 <brunowolff> ack
18:51:34 <Octayn> tflink: ping me about it later; I have free time
18:51:50 <tflink> Octayn: will do, I'd love to see more of this automated :)
18:52:22 <adamw> ack then
18:52:23 <tflink> #agreed - 811242 - AcceptedBlocker - It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself, using whichever protocols are required to work for package retrieval at the current phase (Alpha, Beta, Final). This must work if the remote source is not a complete repository but contains only the files necessary for the installer itself to run.
18:52:36 <tflink> #topic (814643) "Words" corrupting (all) odt documents.
18:52:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=814643
18:52:37 <tflink> #info Proposed Blocker, MODIFIED
18:53:30 <tflink> I don't think this is a blocker
18:53:41 <tflink> just got pulled in due to the kde blocker bug
18:53:46 <brunowolff> -1 blocker, -1 NTH
18:54:31 <tflink> well, it could hit "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. They must also have working Help and Help -> About menu items"
18:54:43 <tflink> since I think this part of the default KDE install
18:55:50 <adamw> yeah, that's probably why it's on there
18:56:00 <adamw> kde team only put stuff on KDEBlocker that they genuinely consider worthy of blocking release
18:56:24 <tflink> and it sounds like this is worthy if I'm understanding everything correctly
18:56:27 <adamw> i think 'calligra' is what koffice turned into
18:56:38 <adamw> yeah, I think I'm +1 here - this sounds like it can corrupt user data on a blocking spin, not good
18:57:01 <brunowolff> I have been convinced to switch to +1 blocker.
18:57:09 * tflink is +1 after thinking it through completely
18:57:49 <tflink> proposed #agreed - 814643 - AcceptedBlocker - Violates the following F17 final release criteria "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. They must also have working Help and Help -> About menu items" for KDE
18:57:54 <brunowolff> ack
18:58:32 <tflink> #agreed - 814643 - AcceptedBlocker - Violates the following F17 final release criteria "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. They must also have working Help and Help -> About menu items" for KDE
18:58:37 <tflink> #topic (802381) Port Printers panel to FirewallD1 API
18:58:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802381
18:58:42 <tflink> #info Proposed Blocker, MODIFIED
18:59:12 <tflink> has there been any movement on whether firewalld was going to be backed out for F17?
18:59:43 <tflink> sounds like there is a fix for this, though
19:00:17 <adamw> it's on the next fesco meeting agenda
19:00:43 <adamw> this obviously has more import if we keep firewalld as default, but even in that case i'm -1, i think
19:01:07 <adamw> it's annoying, but doesn't hit any criteria (we don't cover printing) and can be fixed in an update
19:01:14 <tflink> very true
19:01:42 <tflink> proposed #agreed - 802381 - RejectedBlocker - This doesn't hit any release criteria for F17 and could be fixed with an update
19:02:08 <brunowolff> ack
19:03:05 <tflink> #agreed - 802381 - RejectedBlocker - This doesn't hit any release criteria for F17 and could be fixed with an update
19:03:08 <tflink> #topic (748920) Setting back time breaks boot
19:03:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=748920
19:03:13 <tflink> #info Proposed Blocker, NEW
19:03:57 <tflink> as much as these tend to suck, I'm not sure about blocker
19:04:33 <adamw> sorry i'm a bit behind, catching up with secretarying
19:05:29 <tflink> yeah, I'm -1 blocker on this. it does
19:05:42 <tflink> 't hit any criteria that I can think of and could be fixed w/ update
19:06:39 <adamw> well, it's a conditional breakage of the 'system must boot' criterion
19:06:43 <adamw> if your system clock is off, it doesn't
19:06:52 <adamw> i'm not a clear -1 on this to be honest, it is a pretty crappy breakage
19:06:54 <tflink> if your system clock changes, you mean
19:07:14 <tflink> this has been fixed for the liveinstall case
19:07:16 <adamw> yeah
19:07:22 <adamw> there do seem to be quite a few people who've hit this
19:07:30 <tflink> and the only way you could hit this AFAIK is to change your system clock
19:07:39 <tflink> which is kind of stupid
19:07:43 <tflink> the bug, I mean
19:08:26 <tflink> if we couldn't fix w/ updates, I'd be more +1 on this
19:08:51 <adamw> mm...
19:10:03 <adamw> i guess i'm +/-0
19:10:07 <adamw> do we have any votes in the bug?
19:10:25 <tflink> I think that it's pretty safe to say that kamil is +1
19:10:37 <adamw> doesn't look like it
19:10:54 <adamw> note https://bugzilla.redhat.com/show_bug.cgi?id=798328 influences this
19:11:01 <adamw> as at present we have no rescue shell for you to run fsck from
19:11:07 <adamw> or something.
19:11:27 <tflink> I'm more +1 blocker on that one
19:11:32 <adamw> how about we punt this till a meeting where we have more representation?
19:11:49 <adamw> we don't have any devel/fpl/releng representation here, so i'm uncomfortable about making any controversial calls
19:11:50 <tflink> yeah, it's hard to do this with just 2 of us
19:11:59 <brunowolff> I am slightly -1 on this. I don't think it happens in enough cases to block the release.
19:12:22 <adamw> brunowolff: how are you on punting? :)
19:12:50 <tflink> proposed #agreed - 748920 - We need more information and opinions from devel before making a decision on this since it's not a clear violation of criteria but is still an ugly failure mode
19:12:58 <brunowolff> Footballs or the decision?
19:13:12 <brunowolff> ack
19:13:33 <tflink> #agreed - 748920 - We need more information and opinions from devel before making a decision on this since it's not a clear violation of criteria but is still an ugly failure mode
19:13:39 <tflink> brunowolff: footballs, of course :)
19:13:49 <brunowolff> I suck at punting footballs.
19:13:54 <tflink> #topic (808759) firewall-applet - Icon could not be loaded
19:13:54 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=808759
19:13:54 <tflink> #info Proposed Blocker, MODIFIED
19:15:40 <tflink> isn't this a rehash of the firewalld-has-no-gui issue?
19:15:54 <tflink> if so, I'm +1 on punt until FESCo decides on firewalld
19:15:55 <brunowolff> Is there a criteria on running gui apps from a terminal session?
19:16:38 <tflink> not that I'm aware of, no
19:16:49 <adamw> no, it's not about has-no-gui
19:17:03 <adamw> it's about the applet having no icon unless you have system-config-firewall installed, i think
19:17:14 <adamw> an applet with no icon is very difficult to distinguish from a non-existent applet =)
19:17:32 <adamw> i'm not sure the s-c-f thing is even true, but i'm not at my desktop so i can't check.
19:17:48 <tflink> would this hit "All Applications listed in the system menus (or equivalent) must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry", then?
19:17:57 <adamw> no
19:17:59 <adamw> that's about the menus
19:18:10 <adamw> if it hits anything it's "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use "
19:18:27 <adamw> if systemd is default then its applet is part of the default panel configuration, and if it's invisible that's not 'functioning correctly'...
19:18:46 <tflink> systemd?
19:19:23 <brunowolff> +1 blocker. But the bug claims there is a fix, so it's probably not a big deal either way.
19:20:00 <brunowolff> (Assuming they get an upstream update soon.)
19:20:02 <adamw> er, firewalld.
19:20:04 <tflink> proposed #agreed - 808759 - AcceptedBlocker - Violates the following F17 final release criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
19:20:07 <adamw> ack
19:20:11 <brunowolff> ack
19:20:18 <tflink> #agreed - 808759 - AcceptedBlocker - Violates the following F17 final release criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
19:20:35 <tflink> #topic (814696) When installing, after reboot only black screen with "X" cursor shows up instead of firstboot
19:20:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=814696
19:20:40 <tflink> #info Proposed Blocker, NEW
19:21:48 <tflink> hard to vote on w/o root cause
19:22:23 <tflink> ask for more info/testing and vote on next week, I think
19:22:36 <tflink> this could be any number of things but does sound blocker-ish
19:22:56 <adamw> problem with firstboot using kwin?
19:23:04 <adamw> you'd think it'd affect any kde-only install...
19:23:08 <brunowolff> I'm +1 blocker if this impacts most KDE users.
19:23:21 <adamw> but i'm pretty sure i tested that with beta and didn't see it.
19:23:28 <adamw> damn, wish i was on my desktop.
19:23:29 <tflink> same here
19:23:36 <brunowolff> There was a recent firstboot update.
19:23:49 <tflink> I can re-test
19:23:52 <adamw> report says "Fedora 17 Beta"
19:23:57 <adamw> i.e. not a nightly
19:24:04 <adamw> and they used live image, so no network repos
19:24:19 <tflink> but the dualboot part could be causing problems
19:24:20 <adamw> i guess i'm voting 'punt, investigate further'
19:24:23 <adamw> i don't see how
19:24:32 <tflink> just looking at how its different
19:24:59 <tflink> proposed #agreed - 814696 - We need more information and re-testing on this before deciding on blocker status
19:25:05 <brunowolff> ack
19:25:35 <brunowolff> I looked at the firstboot rpm changelog and didn't see anything that looked like a fix for this.
19:25:45 <adamw> ack
19:25:48 <tflink> #agreed - 814696 - We need more information and re-testing on this before deciding on blocker status
19:25:58 <tflink> brunowolff: it was just reported earlier today, though
19:26:12 <tflink> #topic (814220) Logomarks should be removed and replaced with text
19:26:12 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=814220
19:26:12 <tflink> #info Proposed Blocker, MODIFIED
19:27:15 <tflink> I have no idea where this falls wrt legal
19:27:33 <tflink> -1 blocker, +1 NTH
19:27:39 <brunowolff> Is this package in the default install?
19:27:54 <tflink> good question, I doubt that it's on the dvd
19:28:12 <tflink> but if its a legal issue, I imagine that releasing with the logos in a bad state would be unacceptable
19:28:29 <brunowolff> If not, then -1 blocker, -1 nth.
19:29:19 <adamw> -1 blocker, legal issues aren't covered by this process.
19:29:30 <adamw> as i read it, anyway, this is a case of trying to make things nicer for re-use of fedora
19:29:42 <adamw> we aren't going to get into legal trouble with anyone _else_ for using our own logos in the product, afaict.
19:30:06 <tflink> proposed #agreed - 814220 - RejectedBlocker - The blocker process does not cover legal issues
19:30:10 <adamw> oh
19:30:17 <adamw> unless it's talking about other distros' logos. but, eh.
19:30:18 <adamw> ack
19:30:55 <brunowolff> ack
19:30:57 <tflink> #agreed - 814220 - RejectedBlocker - The blocker process does not cover legal issues
19:31:10 <tflink> #topic (803434) [swell-foop] Help -> Content function is broken
19:31:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=803434
19:31:11 <tflink> #info Proposed Blocker, ASSIGNED
19:31:43 <tflink> this has been reported to be fixed
19:31:53 <tflink> waiting for the fix to go to  stable before closing
19:32:52 <tflink> which it hasn't yet
19:32:57 <tflink> pending push to stable
19:34:23 <tflink> proposd #agreed - 803434 - 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."
19:34:54 <adamw> huh. my name resolution seems to be playing up.
19:34:59 <adamw> but ack.
19:35:10 <tflink> name resolution?
19:35:18 <tflink> #agreed - 803434 - 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."
19:35:30 <tflink> #topic (799667) [abrt] gnome-settings-daemon-3.3.90.1-1.fc17: g_logv: Process /usr/libexec/gnome-settings-daemon was killed by signal 5 (SIGTRAP)
19:35:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799667
19:35:36 <tflink> #info Proposed Blocker, NEW
19:36:24 <adamw> tflink: this chat is working, but i can't seem to resolve any addresses. odd.
19:37:04 <adamw> oh, vpn connection died. sigh
19:38:16 <adamw> so this one causes GNOME to fail to start up if certain wacom tablets are connected, IIRC.
19:38:32 <adamw> i'm trying to remember if we ever precisely isolated the conditions to reproduce, i talked to olivier about it quite a bit.
19:38:33 * adamw checks logs
19:38:36 <brunowolff> How common our those?
19:38:37 <dgilmore> that seems clear blocker to me
19:38:50 <adamw> brunowolff: wacom tablets in general, pretty common.
19:40:13 <adamw> seems like the closest we got is 'specific sub-models of the Bamboo line;
19:40:43 <adamw> this is pretty borderline for me just because it's not a lot of hardware that's affected, and there's a 'workaround' (unplug the tablet)...but probably weak +1
19:42:11 <tflink> I'm about +/-0 on this for blocker
19:43:10 <brunowolff> Without knowing what fraction of people this affects, it's hard to decide.
19:43:32 <brunowolff> Definitely +1 NTH.
19:45:14 <adamw> should we just punt it?
19:45:22 <adamw> ideally it gets fixed and stops being a problem. =)
19:45:53 <tflink> there hasn;t been movement for a while, though
19:46:25 <tflink> NTH?
19:47:17 <brunowolff> We can at least mark the bug NTH for now, pending a later blocker decision.
19:47:25 <tflink> Works for me
19:47:27 <adamw> +1 to NTH and punt on blocker
19:47:38 <adamw> well, 'movement'...we basically know what the fix is
19:47:49 <adamw> i don't really know why it's taking time to land, afaict it's pretty much a solved problem
19:47:55 <adamw> i'll poke olivier in the rear
19:48:24 <tflink> proposed #agreed - 799667 - AcceptedNTH - It's not clear whether this affects enough HW to be a blocker but there is a fix that needs to be applied and is a bit nasty to hit right after install
19:48:51 <brunowolff> ack
19:49:33 <adamw> ack
19:49:41 <tflink> #agreed - 799667 - AcceptedNTH - It's not clear whether this affects enough HW to be a blocker but there is a fix that needs to be applied and is a bit nasty to hit right after install
19:49:49 <tflink> #topic (791130) segfault in _clutter_actor_finish_queue_redraw
19:49:49 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=791130
19:49:49 <tflink> #info Proposed Blocker, NEW
19:50:03 <tflink> sounds like there is fix that needs re-testing
19:52:27 <adamw> see https://bugzilla.redhat.com/show_bug.cgi?id=791130#c61
19:52:39 <brunowolff> This seems to have hit a lot of people doing different things, so I think it is general enough to justify blocker status.
19:52:48 <adamw> i'm somewhat -1 on taking shell crashes as blockers in general because the visible impact is pretty small, but a lot of people wanted to make it one
19:55:38 <adamw> rbergeron and tflink effectively voted +1 final at the beta review meeting.
19:56:06 <tflink> we could punt and hope that the update fixes this
19:56:16 <brunowolff> The bug reporting is probably the biggest impact on end users.
19:56:44 <brunowolff> It can be fixed up in an update except on live images.
19:57:37 <brunowolff> We can at least mark it NTH like the last bug.
19:58:11 * adamw is actually on a 'let's not just auto-NTH everything' campaign =)
19:58:26 <tflink> if we're going to take shell fixes post-freeze, I'd rather they be blockers
19:58:40 <adamw> right
20:00:21 <tflink> I'm + .5 blocker on this, I think - it's not horrible but looks really bad on lives
20:01:04 <brunowolff> I'm inclined to blocker as well for live images, but not really strongly.
20:01:29 <tflink> punt and hope it goes away?
20:01:30 <dgilmore> can we just remove gnome ;)
20:01:46 <tflink> something tells me that there would be resistance to that :-P
20:02:30 <dgilmore> i think its likely a blocker, and maybe fixed in updates-testing
20:02:54 <tflink> sounds like we're more +1 blocker than -1 blocker
20:02:55 * adamw votes 0
20:03:01 <adamw> i don't mind if we go blocker, really.
20:03:17 <dgilmore> id rather shell not crash
20:03:57 * tflink is looking for a criterion
20:06:29 <tflink> I'm not seeing one, though
20:07:11 <adamw> yeah, nothing obvious springs to mind.
20:07:38 <tflink> which makes it more NTH
20:08:14 <adamw> it doesn't crash in all cases right away, which nixes the 'abrt crash notification' criterion, and it doesn't make anything unusable.
20:08:30 <tflink> exactly, it mostly looks bad and is a bit of a pain
20:08:51 <adamw> can't think of any precedents either.
20:09:42 <tflink> so either punt or reject blocker and re-propose NTH
20:11:05 <adamw> punt it before we all die of old age.
20:11:07 <tflink> proposed #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evalued if not fixed with new update
20:11:24 <brunowolff> ack
20:11:39 <tflink> proposed #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evaluated if not fixed with new update
20:11:43 <tflink> fixed typo
20:12:20 <adamw> ack
20:12:24 <tflink> #agreed - 791130 - RejectedBlocker - This doesn't hit any release critera or precedents and therefore is not a blocker. Re-propose as NTH and it will be re-evaluated if not fixed with new update
20:12:49 <brunowolff> ack
20:12:50 <tflink> bah, 3 hours and we're barely halfway through
20:12:56 <tflink> #topic (804835) Failed to install GRUB2 into boot partition
20:12:56 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804835
20:12:56 <tflink> #info Proposed Blocker, NEW
20:13:17 <brunowolff> I'm -1 blocker on this one
20:13:51 <brunowolff> Pretty much for the same reason as for Beta
20:14:28 <tflink> yeah -1 blocker
20:14:33 <dgilmore> -1 blocker
20:15:07 <adamw> note that i was probably wrong at  beta, this is likely a real bug and not just a 'doctor it hurts'
20:15:13 <adamw> the workaround is a workaround, not the right way of doing things
20:15:29 <tflink> proposed #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation
20:15:34 <adamw> but still, the workaround _works_, and this is still not something we explicitly cover in criteria and something of a corner case, so still -1.
20:15:50 <adamw> patch: "This doesn't violate any of the F17 release criteria and is a non-standard method of installation, and there is a workaround available"
20:15:54 <tflink> proposed #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation - a workaround is available.
20:15:58 <adamw> ack
20:16:05 <adamw> we'll get the fix in anyway, though.
20:16:39 <brunowolff> ack
20:16:41 <tflink> #agreed - 804835 - RejectedBlocker - This doesn't violate any of the F17 release criteria and is a non-standard method of installation - a workaround is available.
20:16:48 <tflink> #topic (802106) ipw2200 bg doesn't work in f17
20:16:48 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802106
20:16:48 <tflink> #info Proposed Blocker, NEW
20:17:22 <tflink> I got the smolt data I needed for this, I just haven't gotten around to designing a query that answers the question of how many ipw2200 installs there were
20:18:53 <tflink> with the number of reports we have been seeing, I'm not sure about accepting this as a blocker w/o more data
20:19:26 <tflink> so I'd say punt and I'll get an answer to the "how many" question or reject
20:20:31 <adamw> i'm okay punting
20:21:07 <tflink> proposed #agreed - 802106 - we still need data on how many ipw2200 installs are registered in smolt - will vote once we have that data
20:21:22 <tflink> #action tflink to find better numbers on how many affected installs are in smolt
20:22:06 <adamw> ack
20:22:23 <tflink> #agreed - 802106 - we still need data on how many ipw2200 installs are registered in smolt - will vote once we have that data
20:22:32 <tflink> #topic (796479) firewalld conflicts with libvirt's default network
20:22:32 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=796479
20:22:32 <tflink> #info Proposed Blocker, ASSIGNED
20:23:48 <tflink> I think this depends entirely on whether firewalld remains on by default
20:23:55 <tflink> if it does, +1 blocker
20:23:59 <tflink> if not, -1 blocker
20:24:50 <adamw> yeah...it's fixable with an update, probably, but i think we want usable vm hosting ootb, really.
20:25:04 <adamw> we have to act for now as if firewalld is default, because it is.
20:25:08 <tflink> I suppose we could take it as a blocker
20:25:16 <tflink> if firewalld isn't on by default, it'd just be closed
20:25:40 <dgilmore> firewalld is supposed to be on by default
20:25:52 <dgilmore> so im +1 blocker
20:26:03 <tflink> proposed #agreed - 796479 - AcceptedBlocker - Violates the F17 beta release criterion "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology"
20:26:42 <adamw> ack
20:27:05 <tflink> #agreed - 796479 - AcceptedBlocker - Violates the F17 beta release criterion "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology"
20:27:09 <tflink> only 9 left
20:27:18 <tflink> #topic (813905) livecd-iso-to-disk does not create USB correctly from a DVD image
20:27:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813905
20:27:24 <tflink> #info Proposed Blocker, MODIFIED
20:27:32 <tflink> this one is a bit of a mess
20:27:44 <tflink> and I think a couple of things are being proposed
20:28:12 <tflink> the documentation needs to be cleared up around the --format issue
20:28:21 <tflink> which I think has been done already
20:28:47 <tflink> and I believe the bcl has added a warning if there is no --format and the partitioning is not correct
20:29:17 <tflink> since the previous behavior would make litd copy the iso to / if the partitions weren't right
20:29:37 <tflink> so I'm +1 blocker on the --format doc issue and warning
20:29:45 * dgilmore is +1 blocker
20:30:09 * adamw reads
20:30:10 <tflink> I'm -1 blocker on the other tangled issue about the inability to use a 1tb HDD as installation media without changing partitions
20:31:16 <adamw> +1 blocker that requirement to use --format should be enforced or at the least _documented_
20:31:23 <adamw> though it's a 'special blocker' as it's in livecd-tools
20:31:40 <tflink> yep, a non-spin-blocking release blocker
20:31:52 * tflink was tempted to call it a non-release-blocking release-blocker
20:32:21 <adamw> paging mr. kafka, cleanup in aisle #3
20:33:01 * nirik is around if he can help with anything.
20:33:20 <tflink> proposed #agreed - 813905 - AcceptedBlocker - The documentation needs to cover use cases that require --format and there needs to be a warning if the process is going to fail. The approved blocker does NOT cover any claims of lost functionality, though.
20:33:44 <tflink> ack/nak/patch?
20:34:15 <adamw> ack
20:35:11 <tflink> #agreed - 813905 - AcceptedBlocker - The documentation needs to cover use cases that require --format and there needs to be a warning if the process is going to fail. The approved blocker does NOT cover any claims of lost functionality - that would need to be filed in another bz
20:35:29 * tflink changed it slightly but didn't think it would be an issue, can #undo if needed
20:35:38 <tflink> speaking of which - something I should have done @ the start
20:35:41 <tflink> #chair adamw
20:35:41 <zodbot> Current chairs: adamw tflink
20:35:52 <tflink> #topic (799132) numastat is written in perl
20:35:52 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799132
20:35:53 <tflink> #info Proposed Blocker, ON_QA
20:37:12 <tflink> -1 blocker, I think
20:37:16 <adamw> yay a chaor
20:37:19 * adamw throws chair
20:37:30 * adamw should probably stop drinking
20:37:41 <adamw> heh. interesting summary.
20:37:46 * tflink is reminded of pro wrestling when someone talks about being #chaired
20:37:48 <adamw> 'tools written in perl ARE UNACCEPTABLE!'
20:37:56 <adamw> perl is a blocker
20:38:47 * adamw stands by comment #7 - 'this would be nice' isn't a blocker.
20:38:50 <adamw> -1
20:39:00 <tflink> proposed #agreed - 799132 - RejectedBlocker - As written, this bug does not hit any of the F17 release criteria
20:39:07 <nirik> this doesn't hit any critera I can think of. ;)
20:39:49 <nirik> ack
20:40:01 <tflink> we could always propose a release requirement that "it can't be written in perl"
20:40:10 <tflink> but that seems a bit ... odd to say the least
20:40:31 <tflink> #agreed - 799132 - RejectedBlocker - As written, this bug does not hit any of the F17 release criteria
20:40:38 <adamw> ack
20:40:53 <tflink> #topic (813548) pulseaudio terminates very often
20:40:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813548
20:40:53 <tflink> #info Proposed Blocker, NEW
20:42:53 <tflink> This doesn't seem to be affecting enough people to accept as a blocker yet but then again, it was first reported earlier this week
20:43:44 <tflink> proposed #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status
20:44:32 * adamw reading
20:44:46 <nirik> seems reasonable to me.
20:44:52 <brunowolff> ack
20:45:05 <brunowolff> (I got distracted for a while with work.)
20:45:14 <adamw> yeah...ack
20:45:18 <tflink> #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status
20:45:21 <adamw> of course, we should check if we can reproduce
20:45:44 <tflink> #undo
20:45:44 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x20ae7410>
20:46:16 <tflink> #agreed - 813548 - There haven't been enough reports of this to justify taking as a blocker - will wait another week to see if there are more reports before deciding on blocker status. It would be nice to see more testing on this
20:46:22 <tflink> #topic (804216) pungi doesn't use yum transactions, which is a problem with langpacks
20:46:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804216
20:46:27 <tflink> #info Proposed Blocker, NEW
20:46:28 <tflink> +1 blocker
20:46:36 <nirik> +1 blocker. should get fixed.
20:47:19 <tflink> proposed #agreed - 804216 - AcceptedBlocker - Violates the F17 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
20:47:33 <brunowolff> ack
20:47:38 <nirik> ack
20:47:46 <tflink> #agreed - 804216 - AcceptedBlocker - Violates the F17 final release criterion "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
20:47:49 <adamw> ack, kde updating is probably a 'critical path action'.
20:47:59 <adamw> let's hope no-one looks through this log and compares our logic to the beta go/no-go. =)
20:48:14 * adamw points all reading journalists at that shiny object outside the window there
20:48:14 <tflink> why not?
20:48:22 <adamw> oh yeah, that's a final criterion. whew.
20:48:33 * adamw puts down the beer
20:48:35 <tflink> #topic (799591) SELinux is preventing NetworkManager from 'read' access on the file /etc/sysctl.conf.
20:48:38 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799591
20:48:40 <tflink> #info Proposed Blocker, MODIFIED
20:48:49 <tflink> adamw: didn't you say you were going to do that a while ago? :-P
20:49:15 <adamw> tflink: promises, promises
20:49:18 <adamw> i said i SHOULD do it
20:49:20 <adamw> not that i WOULD
20:49:24 <tflink> point taken
20:49:54 <tflink> how soon after boot/login is this happening?
20:50:05 <adamw> i'm getting it at boot, i think.
20:50:07 <tflink> if it's NM, I assume pretty early in the process
20:50:19 <tflink> if so, a pretty clear blocker
20:50:25 <adamw> in f16, anyhow
20:50:30 <adamw> uh, i think it's fixed in f17
20:50:50 <adamw> i re-opened it because it's still happening in f16, just to poke mgrepl to push an update. but it probably shouldn't block 17.
20:51:04 <tflink> yep, I just noticed that
20:51:40 <tflink> #info this was fixed in F17 but re-opened when the same bug showed up in F16 - will remove from consideration for F17 final blocker
20:51:51 <tflink> #topic (740280) /dev/live no longer exists
20:51:51 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740280
20:51:51 <tflink> #info Proposed Blocker, NEW
20:53:13 <tflink> I'm a little confused on why this is a blocker
20:53:19 <adamw> breaks live image persistence
20:53:30 <tflink> oh
20:53:48 <adamw> also encrypted /home for live
20:54:44 <adamw> we don't have criteria for this, so it's hard to take it as is. but maybe we should.
20:54:52 <tflink> I don't think that we have a criteria for this, though
20:56:23 <adamw> as in, maybe we should have criteria
20:56:31 <tflink> I'd be leaning more towards "should be a blocker" even if we have to propose new criteria
20:56:53 <tflink> releasing with tools that create persistant overlays even though there is no chance of them working seems bad
20:57:06 <brunowolff> Would this be fixed in livecd-iso-to-disk? If so that could be done after release. But if the issue is in the ISO, it would be nice to have it fixed before release.
20:57:10 <nirik> f16 shipped this way? huh...
20:57:59 <tflink> or was it broken post-release?
20:57:59 <adamw> brunowolff: it's in livesys
20:58:09 <adamw> nirik: uh, i may have been wrong, we may have reverted it for f16 or some crap.
20:58:25 <nirik> yeah, I would have thought there would have been a large outcry.
20:58:30 <adamw> brunowolff: we couldn't fix it with a post-rel update i don't think
20:58:37 * nirik is +1 blocker. even if we need to make a new critera for it.
20:58:44 <adamw> i dunno how many people actually _use_ overlays. but yeah, i'd've figured to hear more about it.
20:58:56 <adamw> satellit_: you've tested overlay stuff right?
20:58:59 <adamw> what's the status?
20:59:20 * tflink wonders if this was covered in the usb-media test day
20:59:22 <adamw> comment #2 "move to F17... /dev/live is present again in F16"
21:00:08 <adamw> i was probably smoking crack in #15 or something.
21:00:34 <tflink> proposed #agreed - 740280 - This is not a blocker with the current release criteria, will re-evaluate if new criterion is accepted
21:00:56 <tflink> anyone feel like volunteering to propose a new criterion?
21:01:04 <satellit_> adamw Libeusb-creator work....overlay
21:01:23 <satellit_> works
21:01:36 <brunowolff> ack
21:01:38 <adamw> tflink: usually when we have strong consensus to propose a new criterion for a bug we either accept it as blocker pending the new criterion or punt, we don't reject it
21:02:11 <tflink> adamw: who said anything about rejecting it?
21:02:29 <satellit_> l=i-t-d creates persisent overlays for bios and EFI that work
21:03:07 <satellit_> have to go....sorry
21:03:17 <adamw> tflink: "not a blocker" read like rejecting to me
21:03:20 <adamw> satellit_: thanks
21:03:27 <adamw> so, according to satellit, overlays are somehow working anyway...
21:03:34 <satellit_> ye look at 4.1 test day
21:03:37 <adamw> maybe this got fixed up in livesys but not noted
21:03:39 <tflink> proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted
21:05:36 <adamw> patch to acknowledge unclear nature of impact?
21:06:38 <nirik> if overlays are working this is less severe... ;)
21:07:03 <tflink> proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted and
21:07:04 <adamw> right.
21:07:08 <adamw> ack
21:07:13 <tflink> proposed #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted
21:07:20 <tflink> extra 'and'
21:07:24 <nirik> ack
21:07:30 <tflink> #agreed - 740280 - This is not a blocker with the current release criteria but we feel that it should be if it is indeed impacting the ability to create persistent overlays for live images on USB. No status change WRT blocker status of this bug; will re-evaluate if new criterion is accepted
21:07:31 <brunowolff> ack
21:07:44 <tflink> #topic (798328) No rescue shell is offered for fsck errors
21:07:44 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=798328
21:07:44 <tflink> #info Proposed Blocker, NEW
21:08:24 <tflink> if there really is no fsck in the dracut shell, I'm +1 blocker
21:08:46 <tflink> wait, is this dracut shell or systemd rescue shell
21:09:02 <tflink> wasn't this an issue for F16, too?
21:09:56 <brunowolff> This is fixable in an update, and only comes into play when there is a problem with fsck.
21:10:36 <brunowolff> Unless problems are more common than I expect, I don't think this rates as a blocker.
21:11:41 <adamw> it's an icky area.
21:12:06 <adamw> i did hit this the other day, though, actually. and i was able to fix it all up from the boot process. so i got a console when i needed one.
21:12:41 * rbergeron doesnt think adamw should stop drinking
21:13:00 <adamw> rbergeron: hic
21:13:04 <tflink> I'm remembering something in F16 where you wouldn't get the rescue shell unless you rebooted
21:13:27 <tflink> but you would get the rescue shell after reboot
21:15:20 <adamw> didn't see that. but yeah, i remember something like that too.
21:15:26 <adamw> i think if i drink more it might help my memory.
21:16:59 <tflink> if we have a workaround, I'm ok with -1 blocker
21:17:25 <tflink> but either this or the system time bug probably needs to be fixed before release
21:17:35 <adamw> i'd feel more comfortable having kparal around, since he seems to understand it better.
21:18:36 <tflink> if you change the system time on the host, doesn't the VM pick that up?
21:19:06 * nirik sees sandeen just updated the time fsck bug
21:19:11 <adamw> i don't know. in some sense, i guess, yeah.
21:19:56 <tflink> I'm not comfortable rejecting this without more data
21:20:17 <tflink> releasing without an acceptable recovery mechanism seems like really bad form, even if it can be fixed w/ an update
21:20:58 <adamw> and if you hit the bug, how do you install the update...
21:21:13 <tflink> if a workaround like rebooting will get you to the recovery console, I'd be OK with that
21:21:23 <tflink> so I say punt and ask for more info
21:22:31 <tflink> proposed #agreed - 798328 - We need more information and testing on this before deciding on blocker status. While it could be fixed with an update, if you hit it before updating, that doesn't help. It would also be good to know if there are any possible workarounds for the issue
21:22:45 <adamw> ack
21:23:42 <nirik> ack
21:23:44 <tflink> #agreed - 798328 - We need more information and testing on this before deciding on blocker status. While it could be fixed with an update, if you hit it before updating, that doesn't help. It would also be good to know if there are any possible workarounds for the issue
21:23:55 <tflink> only 2 more proposed blockers!
21:24:04 <tflink> #topic (802552) wlan0: WPA: Failed to get master session key from EAPOL state machines - key handshake aborted
21:24:07 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=802552
21:24:09 <tflink> #info Proposed Blocker, NEW
21:24:41 <tflink> do we have an idea of how common this actually is?
21:25:33 <tflink> I see it as conditional breakage of "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
21:26:34 <adamw> never seen it...reading
21:26:45 <adamw> "WPA PEAP MSCHAPV2"
21:26:46 <adamw> ah.
21:26:56 * adamw goes to ping peter
21:27:11 * tflink thinks that this is what his university uses but they have almost no support for linux
21:27:26 <adamw> three dupes, and peter thinks it's a blocker...i trust him
21:27:33 <adamw> waiting for a ping reply now
21:30:03 <adamw> nothing doing
21:30:16 * adamw pings dcbw instead
21:30:22 <adamw> "I downgraded to the 0.2.fc17 and things work again."
21:30:25 <adamw> so this is a regression
21:31:11 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=811447 states "PEAP does not work"
21:32:22 <adamw> looks like any kind of EAP is broken with wpa-supplicant 1.0-0.3, and quite a few reporters. i'm going with +1 blocker.
21:32:34 <tflink> we could always revoke blocker status later
21:33:31 <adamw> yeah, nothing is permanent.
21:33:39 <tflink> proposed #agreed - 802552 - AcceptedBlocker - Conditional violation of the F17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" for PEAP wireless APs
21:33:49 <brunowolff> ack
21:33:57 <tflink> adamw: very philosophical :)
21:35:11 <adamw> hic
21:35:41 <adamw> ack
21:35:43 <tflink> #agreed - 802552 - AcceptedBlocker - Conditional violation of the F17 alpha release criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" for PEAP wireless APs
21:35:55 <tflink> #topic (810161) Regression: change to 16 bpp by default in virt breaks KDE Plasma desktop
21:35:58 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810161
21:36:01 <tflink> #info Proposed Blocker, NEW
21:37:20 <adamw> ehhh. it's a polish bug, ultimately. it's not broken. it's unintentionally pink.
21:37:26 * adamw is feeling pretty +/-0.
21:38:48 <tflink> yeah, I'm not strongly +1 on this
21:39:22 <tflink> I'm thinking not blocker - would consider NTH
21:39:28 <dgilmore> +1 blocker
21:40:14 <adamw> it's kinda 'how bad do we think a cosmetic bug in one of the common Fedora virt stack configs with one of the supported Fedora desktops is'.
21:40:31 <adamw> i guess i'd want more votes.
21:40:42 <adamw> damn conditional blockers.
21:41:01 <nirik> it would be really nice to fix... I'm def +1 NTH... might be blocker... it just looks bad
21:41:19 <adamw> it's easy to say 'hey, we got weeks to fix before final, let's just make it a blocker and make kevin happy', but that's kinda the easy out.
21:41:37 <adamw> would i want to hold the release for a week if this was go/no-go and everything else was good? ehhhhhh.
21:41:39 <adamw> maybe,
21:41:49 <tflink> probably not
21:42:26 <adamw> thought experiment, the bug is in gnome not kde...change anyone's mind?
21:42:33 <adamw> because it shouldn't. i'd still be kinda ehhh.
21:42:48 <tflink> I'd still say probably not
21:42:57 <nirik> I guess it's only virt, etc... +1 NTH tho.
21:43:04 <tflink> either way, it's a corner case that is as much a bug in the defaults for libvirt as anything
21:44:29 <adamw> the default seems to be set by a gconf key, btw. which may be why we get different people seeing different defaults.
21:44:51 <adamw> but i haven't investigated any reasons why it doesn't get changed with schema updates or why there seem to be two similarly named keys or what have you.
21:45:30 <adamw> i'd probably feel better having more votes, and maybe getting kevin in to orate.
21:45:37 <adamw> punt?
21:45:52 <tflink> we can do that, I guess
21:45:58 <nirik> there's possibly several ways to fix it... not that it matters for voting on it...
21:46:07 <tflink> I'm OK with RejectedBlocker and AcceptedNTH, though
21:46:18 <tflink> I just can't see slipping release for this
21:46:27 <adamw> i wouldn't lose any sleep, but i'm not feeling confident enough to cast a vote.
21:46:31 <tflink> taking a tested fix after freeze? Sure
21:46:45 <adamw> i guess by a strict interpretation of the criteria it's -1.
21:46:50 <adamw> since nothing is unusable.
21:46:56 <tflink> slipping release just because one of the primary DEs looks funny in one possible default virt env? No
21:48:07 <adamw> btw, let me at this point channel the spirit of KK in his absence to say we're all crazy and quite possibly evil too, and we're killing KDE.
21:48:47 <tflink> oh, I imagine this won't be the last we hear of this if it isn't fixed by freeze
21:49:16 <tflink> but as far as blocker is concerned - I'm seeing +1/-1/2x0
21:49:19 <fenrus02> you'll hear about simply because of this convo if nothing else.  he likes to comment :)
21:49:56 <tflink> any other votes?
21:50:05 <adamw> screw it, i like to argue with kevin, i'll make mine a -1 according to criteria.
21:50:08 <fenrus02> i dont know enough about the bug to even comment.  ~pass
21:50:15 <adamw> the bug just doesn't break stuff enough to constitute blockeriness.
21:50:26 <tflink> +1/-2/1x0
21:51:38 <tflink> proposed #agreed - RejectedBlocker AcceptedNTH - This is a cosmetic polish issue that only hits certain VM configurations - it doesn't clearly violate any of the release criteria and doesn't seem severe enough to justify slipping release for but a well tested fix would be considered after final freeze
21:52:38 <brunowolff> ack
21:53:08 <adamw> ack
21:53:17 <tflink> #agreed - RejectedBlocker AcceptedNTH - This is a cosmetic polish issue that only hits certain VM configurations - it doesn't clearly violate any of the release criteria and doesn't seem severe enough to justify slipping release for but a well tested fix would be considered after final freeze
21:53:28 * adamw dons asbestos bodysuit and starts scanning the horizon for incoming Kofler projectiles
21:53:40 * fenrus02 brings popcorn
21:53:48 <tflink> And that would be the last of the proposed blockers for today!
21:54:05 <tflink> just short of 5 hours
21:54:34 <tflink> we still have 9 proposed NTH
21:54:48 <tflink> any thoughts on powering through or leaving them for later?
21:55:36 <fenrus02> depends how quickly they can be run through really.  i highly doubt anyone wants to be around another 5hrs to talk about those right now
21:56:22 <tflink> well, if we keep going at the same rate, it would be ~ 1.5 hours
21:56:41 <tflink> we seem to be doing about 10 min per bug
21:57:44 <fenrus02> i've only got another hour or so before i need to run.
21:57:51 <adamw> let's just leave it for the next meeting.
21:58:00 <adamw> nth status isn't terribly important, and even less so outside of freezes.
21:58:02 <fenrus02> when is the next scheduled?
21:58:05 <adamw> next  friday
21:58:07 <tflink> next week
21:58:15 <adamw> so a mere 10 minutes from now, right? :)
21:58:15 <fenrus02> cool
21:58:22 <tflink> adamw: I won't fight you on that
21:58:44 <tflink> 10 minutes? I suppose that depends on how you define the week
21:58:58 <tflink> #topic Open Floor
21:59:20 <tflink> #info there were no objections to not reviewing the NTH this week. Will revisit next week
21:59:36 <tflink> I think we're in for another not-short meeting next week
21:59:37 <adamw> tflink: we've been here 6 days, 23 hours and 50 minutes, right?
21:59:40 <adamw> it sure feels like it =)
22:01:01 <tflink> anything that I missed or that anyone wants to bring up?
22:01:21 <adamw> god, no.
22:01:38 <tflink> #info Next blocker review meeting will be on 2012-04-27 @ 17:00 UTC
22:02:08 * tflink sets the fuse for ~ 5 minutes
22:02:16 <tflink> ... give or take 5 minutes :)
22:02:40 * adamw blows on fuse
22:06:14 * fenrus02 watches crickets chirp
22:06:31 <adamw> #endmeeting