16:01:57 #startmeeting f19final-blocker-review-6 16:01:57 Meeting started Mon Jun 17 16:01:57 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:57 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:58 #meetingname f19final-blocker-review-6 16:01:58 #topic Roll Call 16:01:58 The meeting name has been set to 'f19final-blocker-review-6' 16:02:28 #chair adamw jreznik kparal 16:02:28 Current chairs: adamw jreznik kparal tflink 16:02:30 could we start today with that few accepted blockers not resolved yet first? I will have to leave shortly after 8 pm - and I got some details 16:02:32 * nirik is lurking 16:02:51 jreznik: I assume that's an hour from now? 16:02:58 2 hours 16:03:05 jreznik: fine with me, maybe tell us which ones specifically? 16:04:04 kparal: the three in NEW/ASSIGNED (except disable testing one) but we will see how fast we will be 16:04:11 so it's not the must :) 16:05:43 we seem to have the usual suspects, so I suppose we can get started 16:05:56 #topic Introduction 16:06:02 Why are we here? 16:06:02 #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 freeze exception bugs. 16:06:08 #info We'll be following the process outlined at: 16:06:08 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:14 #info The bugs up for review today are available at: 16:06:14 #link http://qa.fedoraproject.org/blockerbugs/current 16:06:21 #info The criteria for release blocking bugs can be found at: 16:06:22 #link https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria 16:06:24 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:06:27 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:06:30 #info Up for review today, we have: 16:06:35 #info 12 Proposed Blockers 16:06:35 #info 11 Accepted Blockers 16:06:35 #info 14 Proposed Freeze Exceptions 16:06:35 #info 19 Accepted Freeze Exceptions 16:07:10 any objections to starting with the accepted blockers today? 16:07:28 no :) 16:07:43 no 16:07:44 i'll secretaryify 16:07:49 adamw: thanks 16:07:57 * satellit_e listening 16:08:19 * tflink is going to skip the "disable u-t" bug 16:08:27 #topic (971191) DVD install option unavailable in TUI 16:08:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=971191 16:08:28 #info Accepted Blocker, anaconda, NEW 16:08:57 there appears to be no progress in bug for this one 16:09:23 so quick status update for this one - sbueno was at summit last week, she's aware of the bug and I'm trying to force her to raise priority for this one over usuall RHEL work 16:09:43 okay, thanks 16:10:35 not an answer I hoped for, will continue pushing on this one 16:10:39 #info devs are aware of this bug, waiting for update from them 16:11:05 #topic (971763) disable updates-testing 16:11:05 #link https://bugzilla.redhat.com/show_bug.cgi?id=971763 16:11:05 #info Accepted Blocker, fedora-release, ASSIGNED 16:11:09 bah 16:11:11 #undo 16:11:11 Removing item from minutes: 16:11:16 #undo 16:11:16 Removing item from minutes: 16:11:18 #undo 16:11:18 Removing item from minutes: 16:11:24 #topic (968951) g-i-s created user's accounts and settings are copied to new users created after g-i-s completes but before a reboot 16:11:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=968951 16:11:30 #info Accepted Blocker, gnome-initial-setup, NEW 16:11:48 i know this is being worked on upstream 16:12:02 looks like we're either waiting for an update or the update was not marked as fixing this bug 16:12:04 rui was trying to do upstream release today but during testing he found some architectural issues due to latest changes 16:12:15 i believe this message for me from earlier today was about this bug: 16:12:16 04:24:50> adamw: it's only one half of the fix. 16:12:16 04:25:06> adamw: i think Jasper/rtcm still need to do a g-i-s release for the other half 16:12:16 04:27:08> going to happen today 16:12:17 he's working for jasper to appear online to talk with him about it 16:12:38 [16:27] I have been trying to get a g-i-s release out 16:12:40 [16:28] but while testing it I found a problem that I've been debugging and it turns out that it's sort of an architectural problem from a few changes that Jasper made recently and now I'm waiting for him to show up online to discuss the best way to fix 16:13:14 #info devs are aware of the problem and are working on a fix, nothing for us to do here 16:13:27 #topic (969852) Software Update fails to update 16:13:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=969852 16:13:27 #info Accepted Blocker, gnome-packagekit, ASSIGNED 16:14:17 no recent update from hughsie 16:14:21 hughsie is working on this one 16:14:27 jreznik, i think it's a gtk bug, i've spent a few hours on it today and am now at the "just disable features to make it work stage" 16:15:24 #info devs are aware of the issue and are working on it - no significant updates yet 16:15:53 #topic (958426) 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) 16:15:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=958426 16:15:59 #info Accepted Blocker, LiveCD, NEW 16:16:30 it looks like this is in the same boat it was in last time we reviewed it 16:16:38 devs are aware of the issue, are working on it 16:17:00 * jreznik does not have any specific update for this one 16:17:25 #info devs appear to be aware of the issue and are continuing to work on getting the image size under 1GB 16:17:48 anything else here? 16:18:40 not from me, thanks for starting with accepted ones - even I did not bring any really good news... 16:19:06 thanks for checking on them 16:19:21 it does seem like we have a lot more blockers for final than we had for either alpha or beta 16:20:08 that's all of the accepted blockers not ON_QA or VERIFIED on my list, moving on to the proposed blockers 16:20:26 #topic (974643) console= not passed onto installed system 16:20:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=974643 16:20:26 #info Proposed Blocker, anaconda, NEW 16:20:49 there used to be 'serial' option required for F18 16:21:30 tflink: it's usually the case; a lot of people start testing at beta 16:21:38 and we accept a lot more blockers 16:21:41 not sure that this is a blocker, though 16:21:55 it seems pretty clear-cut to me 16:22:03 the question is - does it work with 'serial'? 16:22:05 even though it works with grub? 16:22:10 oh right i forgot 16:22:16 if this is syslinux only, fuhgeddaboutit 16:22:25 I'm not sure extlinux counts as a blocking issue 16:22:44 especially for non-primary bootloaders on a secondary arch 16:22:45 ah, works with grub, ok 16:23:12 well said 16:23:43 unless we have some reason to doubt bcl's test 16:23:45 er, extlinux rather. 16:23:50 primary aim of the feature was on cloud, so it's a new feature completely 16:24:04 yeah, no reason to doubt bcl's test 16:24:10 -1 16:24:19 yeah, not a regression, not the primary bootloader for arm and even if it was, arm is secondary arch 16:24:19 i might be +1 FE if the fix is very isolated 16:24:29 https://bugzilla.redhat.com/attachment.cgi?id=761490&action=diff 16:24:49 -1 FE, what about FE? it's touching bootloader but on the other hand seems to be easy fix (not tested) 16:24:52 it's inside class EXTLINUX so it can't break anything else afaics, so i guess +1 fe for early freeze at least 16:25:15 so the cloud folks can have their toy 16:25:38 proposed #agreed 974643 - RejectedBlocker - Serial console options are persisted for primary arch using grub and as such, this does not violate any release criteria and is not a blocker. 16:25:45 unless we wanted to do FE 16:26:14 adamw: it's ARM toy if FE accepted, it's not important for cloud toy 16:27:28 ack/nak/patch? 16:27:32 ack 16:27:42 ack 16:27:44 i'll ack that, or -1 blocker / +1 fe. 16:27:47 either way. 16:28:15 -1/+1 too 16:28:29 so ... mostly +1 FE? 16:28:35 ok with me 16:28:43 +1 FE 16:29:01 proposed #agreed 974643 - RejectedBlocker AcceptedFreezeException - Serial console options are persisted for primary arch using grub and as such, this does not violate any release criteria and is not a blocker. However, a tested fix would be considered past freeze. 16:29:08 ack 16:29:18 ack 16:29:41 ack 16:29:44 #agreed 974643 - RejectedBlocker AcceptedFreezeException - Serial console options are persisted for primary arch using grub and as such, this does not violate any release criteria and is not a blocker. However, a tested fix would be considered past freeze. 16:29:52 #topic (974711) Drop HAL and beefy install 'ad banners' for F19 final(?) 16:29:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=974711 16:29:58 #info Proposed Blocker, fedora-logos, NEW 16:30:32 I'm not sure we're in place to say what's acceptable as a banner 16:30:45 other than the F17/rawhide stuff showing up 16:31:21 the HAL banner is indeed confusing 16:31:38 FE sure, blocking - I'd say no, /me asked on #fedora-design if they could provide some new banners 16:32:01 the HAL one might even have copyright concerns for all I know 16:32:06 and the beefy banner, I kind of like it. I don't see it as a reference to F17 16:32:11 i mean, remember folks, we are at least pretending to be shipping an *operating system* here 16:32:13 yeah, the HAL banner bothers me more than the others - I hadn't even noticed the beefy reference 16:32:37 tflink: https://git.fedorahosted.org/cgit/fedora-logos.git/plain/rnotes/Make-Fedora-Better.jpg 16:32:38 you'd think that spot knew what he was doing when pushing the hal image 16:32:40 does it send much of a message of confidence if your operating system inexplicably shows you a reference to an evil computer during installation? 16:32:54 tflink: i always assumed it was simply a jokey placeholder 16:33:07 an evil computer telling you that it can't let you do something ... during install? 16:33:11 maybe invite bcl here? 16:33:18 why bcl? 16:33:27 this is all design AFAIK 16:33:28 don't they control which banners to pick? 16:33:49 I think they just pull files from fedora-logos 16:33:52 right 16:33:54 they have no idea about it 16:33:55 well, it's definitely up to design team 16:34:00 it just rotates through all the banners in a given directory 16:34:03 * jreznik ping ryan 16:34:09 pinged ryan :) 16:34:11 the contents of that directory are controlled by artwork/design team, it's in the fedora-logos package 16:34:30 (the banners look 90's anyway) 16:35:13 fortunately they show up just in English language :) 16:35:46 they don't show up if you're using a language other than English during install? 16:35:51 tflink: no 16:36:06 unless there's some localized package 16:36:20 definitely not in Czech 16:36:39 I suppose that's better than showing english-language "ads" for non-english installs 16:36:42 it's expected, the banners must have a localized versions first 16:37:21 well, +1 FE for sure and punt for blocker vote and ask artwork team 16:37:48 well, I'm ok with +1 FE, blockery thing is more up to design guys 16:37:55 fair enough 16:38:29 yeah, as much as I'm not a fan of the current ad set, I'm not sure it passes the 'last blocker' test 16:39:34 proposed #agreed 974711 - AcceptedFreezeException - This is a very visable polish issue that can't be fixed with an update post-release. Waiting on feedback from design team before making a decision on blocker status. 16:39:57 ack 16:40:15 ack 16:41:43 #agreed 974711 - AcceptedFreezeException - This is a very visable polish issue that can't be fixed with an update post-release. Waiting on feedback from design team before making a decision on blocker status. 16:41:57 adamw: btw, beefy was 17 not 18 16:42:16 #topic (974063) Ignore Google documents without a thumbnail URI 16:42:16 #link https://bugzilla.redhat.com/show_bug.cgi?id=974063 16:42:16 #info Proposed Blocker, gjs, ON_QA 16:43:00 ah 16:43:15 there used to be a crash for certain documents in google docs 16:43:17 not sure this is blocker material 16:43:28 not sure how widespread it was 16:43:48 now the crash is fixed, but gnome-documents suffer further issues 16:43:50 so the maximum possible impact of this is 'everyone who signs into a google account' 16:43:54 so it means it works for most of the documents? 16:44:09 yeah, I was just wondering about g-i-s and it's online account stuff 16:44:17 jreznik: it was crashing for documents for which google hasn't supplied a thumbnail 16:44:23 I don't know how often that happens 16:45:33 but it's "fixed" now, so I think we could skip this, just +1 FE to push the fix 16:45:37 +1 fe anyhow 16:45:41 well, the reporter doesn't like the fix 16:45:45 then it does not sound blocking for me, +1 fe to pull it in 16:46:02 adamw: it fixes the crash, but uncovers further issues 16:46:16 those further issues might not be connected 16:46:54 I wonder how many people actually really use gnome-documents 16:47:19 proposed #agreed 974063 - RejectedBlocker AcceptedFreezeException - This does not violate any of the F19 release criteria and is thus rejected as a release blocking bug for F19 final. However, a tested fix would be considered past freeze. 16:47:30 ack 16:47:32 it hasn't really worked the times I've tried to use it 16:48:01 i'm not sure rejectedblocker is right 16:48:17 we didn't really establish that it doesn't violate the 'apps must pass a basic functionality test' criterion 16:48:26 we just handwaved it per jreznik's suggestion 16:48:34 more accurate would be acceptedFE, leave blocker undecided 16:48:41 ok 16:49:04 adamw: well, seems like it's working mostly, no? at least this bug happened only for a few selected online documents 16:49:31 if there are other issues that are making the app not usable for basic functinality test, we should vote on that bug 16:49:35 propoed #agreed 974063 - AcceptedFreezeException - It isn't clear whether or not this violates any of the F19 release criteria and we're waiting for more info to make a decision on blocker status. However, a tested fix would be considered after freeze. 16:49:55 ack 16:49:56 jreznik: eh...i guess 16:50:05 ack to either then, jreznik convinced me 16:50:18 * tflink is more -1 16:50:29 kparal: thoughts? 16:50:40 are we discussing blocker vote now? 16:50:44 yep 16:51:14 -1 is fine, with the fix included. without the fix, I don't know how many people would be affected 16:51:38 probably quite a few 16:51:53 proposed #agreed 974063 - RejectedBlocker AcceptedFreezeException - This does not violate any of the F19 release criteria (GNOME Documents works in most cases) and is thus rejected as a release blocking bug for F19 final. However, a tested fix would be considered past freeze. 16:52:17 the other argument is that this could be fixed with an update 16:52:30 * Viking-Ice sneaks in late... 16:52:41 to be honest, I believe this app has never worked correctly 16:52:43 so ack 16:52:44 the non-network case is irrelevant in this situation as you need network to connect to google docs 16:52:54 kparal: that's been my experience :) 16:53:12 other ack/nak/patch? 16:53:37 ack but would be great to check the app and in case it really does not work - remove it from f19 default 16:53:39 ack 16:53:57 ack 16:53:59 #agreed 974063 - RejectedBlocker AcceptedFreezeException - This does not violate any of the F19 release criteria (GNOME Documents works in most cases) and is thus rejected as a release blocking bug for F19 final. However, a tested fix would be considered past freeze. 16:54:13 #topic (974778) Wrong locale set by g-s-d with single quote 16:54:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=974778 16:54:13 #info Proposed Blocker, gnome-settings-daemon, MODIFIED 16:55:16 if this is as bad as it sounds, +1 16:55:24 not sure about criterion, though 16:55:52 I'm surprised nobody else reported it, though 16:56:08 it's quite new 16:56:12 and it was reported on the list 16:56:27 +1 here 16:56:28 thread "F19 locale issue?" on devel@ 16:56:43 +1 16:57:09 +1 16:58:17 "that's causing lots of issues" from the bug was kinda vague so I didn't know what criterion to propose 16:58:31 yeah, that's what I'm trying to figure out ATM 16:58:52 invalid locale can cause many applications to malfunction 17:00:03 so, "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 non-english locales? 17:00:46 man do not work", "mosh complain and fail to connect due to wrong locale", and "all perl software send errors" 17:00:56 (from misc in #fedora-devel) 17:01:09 close enough for me. 17:01:10 "This can potentially break many applications" 17:01:16 is enough I think 17:01:47 yeah 17:01:53 should suffice 17:01:55 adamw: are the revised criteria coming? 17:02:10 kparal: at this point i think viking's right that it's too late to switch 17:02:13 so i shoved it down my priority list 17:02:19 ok 17:02:28 i'll still work on it if f19 quiets down, otherwise i'm on the validation treadmill 17:02:44 i think the 'all applications listed...' criterion should be fine 17:03:47 proposed #agreed 974778 - AcceptedBlocker - Violates the following F19 final release criterion for non-english installs: "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." 17:03:52 ack 17:04:02 ack 17:04:31 ack 17:04:34 #agreed 974778 - AcceptedBlocker - Violates the following F19 final release criterion for non-english installs: "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." 17:04:41 #topic (974038) [abrt] gnome-shell-3.8.3-1.fc19: wrapped_gobj_toggle_notify: Process /usr/bin/gnome-shell was killed by signal 5 (SIGTRAP) 17:04:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=974038 17:04:47 #info Proposed Blocker, gnome-shell, NEW 17:05:27 I really wish bugzilla made the external tracker comments into links 17:05:56 it's a link at the box 17:06:05 "External Trackers" bo 17:06:06 x 17:06:29 ah, I hadn't noticed that 17:07:15 anyhow, I'm not sure that 1/5 is enough to be a blocker 17:07:25 hmm why is there not a link to that upstream bug 17:07:35 Viking-Ice: see above :) 17:07:37 Viking-Ice: it's at the top of the bug 17:08:08 tflink: I also think that it hasn't caused any loss of functionality. gnome-shell probably just restarted 17:08:18 so -1 blocker is fine by me 17:08:26 well, the abrt notification criterion is a polish thing 17:08:36 it looks especially bad if 'the desktop' (shell) crashes on boot 17:08:48 1/5 is a bit minor though, and i've never seen this iirc 17:10:08 anyone else seen it? 17:10:24 I haven't been using lives much as of late 17:11:27 adamw, sorry not following when you are refering to 1/5 that means what exactly? 17:11:53 you mean 1 out of 5 boot tries? 17:11:55 Viking-Ice: seeing 1 out of 5 fries 17:11:57 tries 17:12:00 yeah, that's what kparal reporterd 17:12:10 -1 17:12:47 -1 17:12:52 -1 17:13:07 i'm ok with -1 unless we start getting more reports 17:13:19 FE might depend on what upstream says about the cause 17:13:52 ask them to propose as FE if they feel it's important 17:14:43 yep 17:16:48 proposed #agreed 974038 - RejectedBlocker - This doesn't seem to be happening often enough to justify blocking the release of F19. Please repropose as a blocker if more reports start coming in. If upstream is of the opinion that this is important, please propose as FE. 17:17:09 ack 17:17:17 ack 17:17:20 ack 17:17:32 #agreed 974038 - RejectedBlocker - This doesn't seem to be happening often enough to justify blocking the release of F19. Please repropose as a blocker if more reports start coming in. If upstream is of the opinion that this is important, please propose as FE. 17:17:41 #topic (974032) bug reporting doesn't work from LiveCD 17:17:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=974032 17:17:41 #info Proposed Blocker, python-meh, POST 17:19:47 -1 blocker 17:19:56 it directly fails our criteria 17:20:27 kparal: IIRC, he always votes -1 on bugs like this and has an issue with the criterion 17:20:32 please note the original issue changed. from an undeterministic issue to a python-meh problem 17:20:54 not being able to report failure at install time and block the final release due to it 17:20:56 tflink, ;) 17:21:38 +1 here 17:21:48 has anyone else seen this? 17:22:12 just try it, it's 100% reproducible 17:22:20 bug reporting simply doesn't work on Live 17:22:36 just follow https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla 17:23:34 +1 17:23:35 ok, I was under the impression that it wasn't all that reproducable 17:23:38 +1 17:24:00 I might not have been clear. the original issue was not reproducible, but the reporting problem failed always 17:24:48 proposed #agreed 974032 - AcceptedBlocker - Violates the following F19 alpha release criterion for live installs: "The installer must be able to report failures to Bugzilla, with appropriate information included." 17:24:59 ack 17:25:23 ack 17:25:41 ack 17:25:52 #agreed 974032 - AcceptedBlocker - Violates the following F19 alpha release criterion for live installs: "The installer must be able to report failures to Bugzilla, with appropriate information included." 17:26:03 #topic (974691) Since cleaning up from #974132, nothing gets written to /var/log/messages 17:26:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=974691 17:26:09 #info Proposed Blocker, rsyslog, NEW 17:26:49 adamw, the journal works fine right? 17:27:01 yes 17:27:09 is anyone else seeing this, or is it just me? 17:27:29 haven't really looked, to be honest 17:27:33 thus it does not violate the cited criteria 17:27:50 adamw: have you tried what's mentioned in comment 2? 17:27:57 kparal: not yet, hadn't got around to it 17:28:11 the journal covers"A system logging infrastructure must be available, enabled by default, and working."" 17:28:13 Viking-Ice: it's the "This must be done in accordance with relevant standards accepted by the Fedora Project." that concerns me 17:28:36 so I'd say punt for now? and give adamw time to try #2? 17:28:51 I'm plus on FE 17:29:12 * adamw trying to find lsb's logging stuff 17:29:18 well logging must work. I'm not sure we want to block on people who suffered from the previous rsyslog hiccup and manually removed some files 17:30:05 the whole implementation of rsyslog and syslog-ng is broken as is in the distribution and trying to fix it is stuck with FPC 17:30:09 kparal: journal works fine. 17:30:19 which is why I'm FE 17:30:22 + 17:30:32 hum, from a quick check, lsb doesn't say anything about logging... 17:30:40 yep 17:30:56 ah, maybe fgs 17:30:57 fhs 17:31:30 where is the sentence coming from? 17:31:33 http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARLOGLOGFILESANDDIRECTORIES 17:31:36 kparal: what sentence? 17:31:44 "This must be done in accordance with relevant standards accepted by the Fedora Project." 17:31:46 "The following files, or symbolic links to files, must be in /var/log, if the corresponding subsystem is installed:" 17:31:53 kparal: it's one of the 'notes' to the criterion 17:31:57 ah 17:32:06 in the old criteria it was part of the main criterion, i split it out in the rewrite to make the main criteria look cleaner 17:32:11 "messages system messages from syslogd" 17:32:21 so...if syslogd is installed, /var/log/messages must be there 17:32:40 so if this was really broken for all, i'd still be arguing for +1. but so far we don't have that data 17:32:41 maybe punt? 17:33:03 yeah, punt works for me 17:33:07 punt 17:33:10 punt works for me 17:33:45 https://fedoraproject.org/wiki/User:Johannbg/Packaging/LogFiles <-- for 600 components ( which of like only 3 depend on rsyslogd ) is whats needed to fix this 17:33:47 we can check this with fresh tc4 installs once we have a tc4 17:33:57 proposed #agreed 974691 - We need more data on how many people are affected by this bug and whether any of the listed workarounds work. Will revisit when more data is available. 17:34:00 ack 17:34:02 Viking-Ice: i don't think this bug is necessarily related to that... 17:35:16 adamw, not directly but having a criteria for something that is inherently not implemented in the distribution 17:35:21 might be ;) 17:35:53 well, sure, it's implemented 17:36:04 rsyslogd is designed to echo everything from the journal into /var/log/messages 17:36:09 there's your implementation right there =) 17:36:17 ack 17:36:34 but nothing depends on rsyslog in the first place ( or very few packages ) 17:36:46 it's in comps, though 17:36:53 so it will be in any regular install 17:37:05 people taking it out in kickstarts or 'yum remove'ing it doesn't violate the criterion 17:37:21 #agreed 974691 - We need more data on how many people are affected by this bug and whether any of the listed workarounds work. Will revisit when more data is available. 17:38:21 anywho fixing that is stuck in a pointing fingers loop fesco --> fpc, fpc --> fesco and the journal meets "A system logging infrastructure must be available, enabled by default, and working." 17:38:23 * tflink skips 964006 as it's already accepted, just not marked as such 17:38:36 #topic (973849) SELinux is preventing /usr/libexec/accounts-daemon from 'read' accesses on the directory /var/log. 17:38:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=973849 17:38:42 #info Proposed Blocker, selinux-policy-targeted, ON_QA 17:38:55 although I dont think Lennart filed a feature mentioning the journal would be enabled by default... 17:39:51 journal's been on by default for like...three, four releases? 17:39:56 i can do ' 17:40:03 'journalctl -a' just fine on an f17 box 17:40:03 +1 17:40:09 +1 obviously 17:40:16 adamw, persistant journal got enabled this release cycle 17:40:25 oh, it was just per-session before? 17:40:26 i see 17:40:38 yeah, i don't recall there being a feature for that 17:40:48 probably needs release notes'ing 17:40:55 * randomuser stirs 17:41:04 any references handy, Viking-Ice ? 17:41:05 you've got some good highlighting there 17:41:45 :) 17:42:03 * adamw resolves to work the phrase 'release notes' into as much conversation as possible 17:42:30 I'll have to actually write some highlighting scripts so I don't disappoint you :) 17:42:45 +1 - lots of people seem to be hitting this 17:42:48 randomuser, persistancy has been enabled by default from systemd 198-1 ( we patch that out for F18 ) for the journal stuff http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?id=5457175a7257203846385d90b3f6287f194e5065 17:42:55 as in, everyone in the world, and it blows up all their logs. 17:43:25 proposed #agreed 973849 - AcceptedBlocker - Violates the following F19 final release criterion: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" 17:43:29 Viking-Ice, that doesn't mean anything to me, but I can take it out of band 17:43:30 ack 17:43:51 ack 17:43:51 ack 17:43:58 #agreed 973849 - AcceptedBlocker - Violates the following F19 final release criterion: "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)" 17:44:13 #topic (974784) live image composing in koji broken 17:44:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=974784 17:44:13 #info Proposed Blocker, system-config-keyboard, NEW 17:44:32 +1 17:44:49 we will fix this in livecd-tools 17:45:06 AutomaticBlocker, right? 17:45:11 was not there a plan to deprecate all that system-config-foo stuff 17:45:17 yeah autoblocker 17:45:32 yeah, this could've been autoblocker 17:45:37 but +1 anyway 17:45:52 +1 17:46:46 proposed #agreed 974784 - AcceptedBlocker - This blocks the process for creating live images and we can't continue testing until it is fixed. Thus, accepted as a release blocking bug for F19 final. 17:46:53 ack 17:46:54 ack 17:46:56 ack 17:47:44 ack 17:48:21 #agreed 974784 - AcceptedBlocker - This blocks the process for creating live images and we can't continue testing until it is fixed. Thus, accepted as a release blocking bug for F19 final. 17:48:33 #topic (974198) missing letters on various anaconda screens with spice graphics 17:48:36 #link https://bugzilla.redhat.com/show_bug.cgi?id=974198 17:48:39 #info Proposed Blocker, virt-manager, NEW 17:49:03 this sounds pretty bad but it's not quite clear what the problem is yet 17:49:09 what causes it, rather 17:49:27 yeah this is bad 17:49:37 but we dont have any criteria I think that covers this 17:49:41 virt? 17:50:02 "The release must be able host virtual guest instances of the same release." 17:50:02 lbrabec reported a duplicate lately, let me see and find it 17:50:13 it's probably just on F19 host 17:50:15 tflink, that's the release not already an GA release 17:50:17 it doesn't seem to be that much of a stretch since qxl/spice is the default 17:50:52 tflink, as this might be fine on F19 and work as expected but be broken on F17/18 and I dont think our criteria covers that 17:50:54 Viking-Ice: or previous - I saw at least one report of the host being F19 17:51:08 but I'm +1 17:51:11 "The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release." 17:51:12 blocking this 17:51:16 the duplicate is here: https://bugzilla.redhat.com/show_bug.cgi?id=974040 17:51:18 if the problem is in the guest, anyways 17:51:47 but, it doesn't happen always. Lukas and Jan didn't see it before starting anaconda, no matter how they tried 17:51:57 after they ran anaconda, sometimes it appeared 17:53:04 I just start an app and I see 17:53:08 firefox for example 17:53:21 it literally gets unusable 17:54:00 Viking-Ice: F19 host? 17:54:14 let me try one more time to reproduce this 17:54:14 so I can confirm this both in anaconda and the live Gnome ( F18 ) 17:54:18 i think i was always testing with netinst 17:54:23 * adamw fires up the live 17:55:11 Viking-Ice: sorry, I'm still not sure what Fedora you have on your host 17:55:30 F18 is the host 17:55:32 as I said 17:55:41 ok. interesting, I never saw that with my F18 17:55:46 and I booted a lot of LiveCDs 17:56:10 booting and running application != the same thing 17:56:34 well guys complained about broken fonts in anaconda. I've never saw it 17:56:39 *seen 17:56:45 and last time I tested it it took firefox about 5 - 10 minutes of surfing before it became scrambled 17:57:17 seems to be serious enough 17:57:21 yeah 17:57:40 yeah, but I think we might be back to no directly applicable criterion, though 17:57:48 punt for more data or fudge? 17:59:53 you can argue install is kinda unusable if you hit the bug 18:00:35 heheh, anaconda crashed while reproducing this 18:01:00 d'oh :) 18:01:07 and damn, the integrated reporter is still not working, obviously 18:01:13 yeah, I'm not saying -1, just wondering which path to take 18:01:26 * adamw boots tc3 live, browses around a bit in firefox, still doesn't see teh bug 18:01:28 huh, it popped up, after a minute 18:01:55 it might be related to resolution, scaling or something 18:02:59 i guess 18:03:08 my guest is at 1024x768 in an appropriately-sized window 18:03:22 maybe punt for input from the X devs? 18:03:23 adamw, just because you dont see it does not mean it does not exist 18:03:24 http://picpaste.com/Screenshot_from_2013-06-17_17_58_57-TLblAN5e.png 18:03:38 I have it scaled down, since I have 12'' screen. I don't see the issue either. but Lukas and Jan both confirmed it 18:03:41 Viking-Ice: i know, but the point is whether it's a general issue or not, and if not, how widespread? and what's the trigger? 18:04:13 adamw, in this case it does not matter it's that serious it warrants to be a blocker 18:05:22 tflink: i'd go with the 'install isn't workable' argument if we're going to +1 it - if you look at the amount of text missing in viking's screenshot, you'd have difficulty working out what the hell was going on in the isnstaller 18:06:12 are we goin with +1 or punt? 18:06:39 i'm okay with either 18:07:03 ideally i'd like to know what the cause is so we can guess at how widespread it'd be, but +1 is not unreasonable 18:07:26 yeah, I'm definitely not -1 but it would be good to know more about what is going on 18:07:44 I dont think punting this solves anything 18:07:54 we do have enough data on the report from reporters 18:07:59 i'd be punting for input from the X devs as to what's causing it 18:08:10 ah true he just moved it 18:08:29 punt for now, I'll have to leave pretty soon... 18:09:14 though +1ing would probably get their attention 18:09:23 i'd be fine with +1 with an option to re-consider, really. it's clearly a bad problem. 18:09:32 yeah, that works for me, too 18:09:42 * kparal nods 18:10:20 yup 18:10:31 proposed #agreed 974198 - AcceptedBlocker - While the cause is still not 100% clear, this appears to be serious and widespread enough to justify blocker status. Violates the following F19 release criterion for live installs 18:10:35 bah 18:11:26 patch ;) 18:11:26 * jreznik is also ok with +1 now, seems like pretty reproducible, so consider my ack on whatever tflink proposes, has to go 18:11:34 proposed #agreed 974198 - AcceptedBlocker - While the cause is still not 100% clear, this appears to be serious and widespread enough to justify blocker status. Violates the following F19 release criterion for live installs in a VM using spice/qxl (installation screens are garbled, making the process difficult if not impossible: "The installer must be able to complete an installation using all supported interfaces" 18:11:47 ack 18:11:50 jreznik: that could be dangerous :) 18:12:00 probably trimmed, ")" missing 18:12:01 ack 18:12:12 kparal: no, it's a typo 18:12:15 ah, I get it 18:12:21 proposed #agreed 974198 - AcceptedBlocker - While the cause is still not 100% clear, this appears to be serious and widespread enough to justify blocker status. Violates the following F19 release criterion for live installs in a VM using spice/qxl (installation screens are garbled, making the process difficult if not impossible): "The installer must be able to complete an installation using all supported interfaces" 18:12:37 * Viking-Ice throws in another ack 18:12:38 ack 18:12:43 #agreed 974198 - AcceptedBlocker - While the cause is still not 100% clear, this appears to be serious and widespread enough to justify blocker status. Violates the following F19 release criterion for live installs in a VM using spice/qxl (installation screens are garbled, making the process difficult if not impossible): "The installer must be able to complete an installation using all supported interfaces" 18:12:44 ack 18:12:59 #topic (924162) A software selection with dependency errors is allowed to proceed if the dependency check runs twice 18:13:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=924162 18:13:05 #info Proposed Blocker, yum, NEW 18:14:23 didn't we cover this one already? 18:14:37 in Alpha 18:15:11 I'm +1 with this one 18:15:17 hrm, I thought we covered it on wednesday but that's rather unlikely as it was proposed after then 18:15:47 anything that can cause us wiping existing installation and delivering a non bootable system is a blocker to me 18:17:01 we rejected for alpha but it's reasonable to re-propose for final 18:19:01 i'm a bit reluctant to take it under the 'user data' criterion though, because it is inherently the case that the user doesn't mind us wiping anything that gets wiped 18:19:05 they explicitly told us to wipe it, in fact 18:19:21 the fact that we fail to install after that is unfortunate, but if they actually needed whatever was wiped, they wouldn't have wiped it 18:19:24 adamw: unless he relies on the fact that we install a new bootloader for him 18:19:25 adamw: true, but it leaves them without a working system 18:19:35 kparal: that's true 18:19:39 it could, anywyas 18:19:59 if I rely on having a new bootloader installed, I can mark the old boot partition to be removed 18:20:13 even though I keep the older system to be dual-bootable 18:20:21 it seems to me that you'd either have to use netinstall or manually enable network updates @ install time to hit this, though 18:20:21 or something like that 18:20:30 I don't have it thought out in detail 18:20:55 tflink: updates is not enabled by default? 18:21:06 kparal: not for live of DVD, AFAIK 18:21:18 let me check 18:21:18 s/of/or 18:22:05 yes, the checkbox "don't install updates" is enabled 18:22:11 can be easily disabled though 18:22:19 for DVD 18:22:32 netinst is a common enough case 18:22:35 (actually, that is quite a bad default, isn't it?) 18:22:40 yeah, I'm not sure that's enough to reject as a blocker - just adding info 18:23:14 kparal: i actually think it's correct. it is not a good idea to assume people want to download potentially several GB of data just because a network connection is available. 18:23:36 i guess i'm a weak +1 18:24:09 yeah, it's not all that likely but it could happen and the results could be really bad 18:25:12 I'm also weak +1 18:25:25 +1 - would consider stronger warning messages to be an acceptable fix to this, though 18:25:34 it's something I'd expect to work well in a final product 18:25:41 tflink: that seems to be all that's asked for 18:25:48 tflink: that's what I ask - an informed decision of the user 18:26:15 note that we'll need to knock some maintainer heads together for this one 18:26:26 the first time I hit this, I had no idea there is some problem. warning icon -> Done -> all OK, great 18:26:34 c#13 seems to ping it back to the anaconda team, but clumens re-assigned it to packaging-team-maint without further explanation on 06-13 18:27:32 any other thoughts on criterion other than "user data"? 18:28:16 i guess we can massage the 'user data' criterion to fit. 18:28:21 * adamw tries to see if he can find better 18:28:30 conditional violation of the dual boot criterion? 18:28:39 that'd also be a squeeze, though. user data is probably best. 18:29:02 conditional violation of: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 18:29:06 ? 18:29:13 but that's just as much of a stretch as the others 18:29:28 actually i kinda like that one better. i can write a better stretch for that one. 18:29:54 kparal: thoughts? 18:30:13 "All known bugs that can cause corruption of user data must be fixed or documented at Common F19 bugs" ? 18:31:20 I would argue that there is almost no risk of user data corruption here 18:31:36 the only case where user data would be lost is if /home would be formatted 18:31:49 help me imagine a situation where you lose an ability to boot to a second OS 18:31:59 in which case, the user specified it to be formatted 18:32:18 if /home isn't formatted, the data isn't lost - it just might be a PITA to get it back 18:32:45 bootloader install is *later*, isn't it 18:32:50 so this bug shouldn't wipe an existing bootloader 18:33:00 adamw: probably not 18:33:01 we're spending a lot of time on this, though 18:33:06 UEFI it would 18:33:22 since UEFI relies on the fat32 system partition 18:33:39 well, you're really supposed to *share* the ESP 18:34:00 but IIRC, you wouldn't end up with a dual-booting system post-install anyways 18:34:00 if you know what you're doing with UEFI you should simply be mounting the existing ESP as /boot/efi , not wiping it 18:34:09 yeah, i think we're still fixing that 18:34:10 grmph 18:34:18 do we think this needs a new criterion? 18:34:20 in the UEFI case 18:34:22 if so what would it be 18:34:22 ? 18:34:30 maybe if you have a bootloader inside the partition for say Suse, and you choose the remove the partition, because you expect Fedora to find Suse and boot from Fedora bootloader? 18:34:37 I'm OK with a conditional violation of the package set case 18:34:37 but it's a bit far-fetched 18:34:48 we really should just have a clause for blockers that dont fit any defined criteria 18:34:53 Viking-Ice: well, we do 18:35:00 we can use that if necessary, but i always hate breaking that glass 18:35:05 still, maybe it's the thing to do 18:35:11 this seems like too much of a corner case to have it's own criterion 18:35:19 "A bug in a Critical Path package that: 18:35:20 Cannot be fixed with a future stable update 18:35:20 Has a severity rating of high or greater and no reasonable workaround (see definition of severity and priority) " 18:35:49 i hate that cop-out clause because we _really_ don't use the severity stuff any more, and if we were going to apply it strictly we'd have to take like dozens of blockers, but maybe it's the best thing to do here 18:36:04 we can call this high severity and +1 it for that 18:36:05 "QA deems this issue serious enough to block the release for" 18:36:11 proposed #agreed 924162 - AcceptedBlocker - Violates the following F19 alpha release criteria for netinstalls when the main repos have depsolving errors, leading to a broken install: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 18:36:22 Viking-Ice: the criteria are an attempt to get away from that kind of completely arbitrary crap in the first place 18:36:31 ack 18:36:32 ack 18:36:52 ack, sure, whatever, let's move on 18:36:54 #agreed 924162 - AcceptedBlocker - Violates the following F19 alpha release criteria for netinstalls when the main repos have depsolving errors, leading to a broken install: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." 18:36:57 adamw, true and if we are required to use it then our criteria is to spesific 18:37:10 OK, that's all of the proposed blockers on my list 18:37:14 * kparal just proposed 975159 18:37:20 but we can leave that for later 18:37:25 so that the devs can see it 18:38:41 * tflink never knew that installing fedora was a religious activity 18:39:13 damn, did I mess up the english phrase? :) 18:39:15 * tflink is making fun of kparal's "I accept my faith" comment in 975159 18:39:35 I had it in Czech, so I translated roughly :) 18:39:52 "fate", ok 18:39:52 no worries, I know what you meant and I strongly suspect that the devs will too 18:39:54 close enough 18:40:23 * tflink would rather leave it for wed. to see if we can get more reproducers and/or dev input 18:40:31 sure 18:40:37 I'm still wondering who that dave is 18:40:49 it gonna be hard to reproduce, since in office we're connected through amsterdam 18:40:55 so I found this only when working from home 18:40:57 Viking-Ice: the ads? It's a famous line from 2001: a space odessy 18:40:57 isn't that the same error you saw first time you hit the libreport-doesn't-work bug? 18:40:59 right now 18:41:35 tflink, ah ok though it was related to some Dave on the Anaconda team 18:41:57 adamw: it seems different 18:42:09 but same cause, string formatting 18:42:13 okay 18:42:16 anyhow, punt is fine 18:42:18 anyway lets punt that new bug for input 18:42:25 it's famous in the US, anyways. not sure how well it works elsewhere in the world 18:42:41 i thought it was pretty big everywhere 18:43:08 * tflink didn't care for it - too many monkeys on the beach with a door 18:43:29 anyhow, we digress 18:43:33 on to the proposed FE! 18:43:42 bring it on!!! 18:43:52 let's prefer those with patches coming? 18:43:53 #topic (968808) Interlingua installs result in errors setting locale and apparent failure of g-i-s to create a user account 18:43:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=968808 18:43:58 #info Proposed Freeze Exceptions, anaconda, MODIFIED 18:44:21 yeah, we have 15 minutes left - I'll filter on staus 18:44:24 status 18:44:59 is this an fallout from that ' ' bug? 18:45:56 +1 FE 18:45:57 anyway +1 18:46:16 * tflink still doesn't understand why one would install with interlingua, but I suppose that's off topic 18:47:34 well, it was requested, so someone wants to do it 18:47:44 i tested the change quite a lot and it seems to work ok, so +1 18:47:44 what is the bug here, anyways? I'm a bit lost 18:48:49 proposed #agreed 968808 - AcceptedFreezeException - Locale issues post-install can be pretty ugly and would be best to fix before release. A tested fix would be considered after freeze. 18:48:56 ack 18:50:40 ack 18:51:10 #agreed 968808 - AcceptedFreezeException - Locale issues post-install can be pretty ugly and would be best to fix before release. A tested fix would be considered after freeze. 18:51:20 #topic (971050) initial-setup runs to completion on F19-TC1 but does not make any changes 18:51:23 #link https://bugzilla.redhat.com/show_bug.cgi?id=971050 18:51:26 #info Proposed Freeze Exceptions, initial-setup, POST 18:52:46 this is affecting arm only right 18:52:51 why would this be an i-s bug if there was a user created during install 18:52:59 not sure, that's how it was reported anyways 18:53:12 and did we decide all secondary arch as auto accepted FE? 18:53:33 I don't think we ever came to a decision on that 18:53:35 well, showstoppers in secondary arches are generally to be accepted as FE, was the principle 18:53:45 but we can reject them if we have a very good reason to do so 18:53:48 that's what we agreed at a blocker meeting 18:54:11 dgilmore, is this arm specific or do this affect ks in general ( thus might be a blocker ) ? 18:54:27 this doesn't seem like a ks issue 18:54:46 it's not even clear that i-s was run 18:54:49 the initial report is clear that this is an initial-setup issue, i don't quite get what vpodzime is talking about in c#2 but if we ignore that and just look at the problem, it sure sounds serious. +1 fe at least 18:54:51 tflink: it's perfectly clear 18:54:59 "on F19 TC1 arm XFCE image initial-setup started and i set time zone, root password and created a user" 18:55:23 ah, I misread it as being ambiguous about whether that was run during install or not 18:55:28 there is no 'install' 18:55:31 it's an ARM image; it's pre-built 18:55:40 +1 FE 18:55:45 the idea here is that i-s runs on first run of the image to set stuff up, since you can't do it 'during install' as there's no install 18:56:00 yeah 18:57:29 people pay attention! ;) 18:57:42 * adamw pokes tflink with the stick of pokiness 18:57:48 ? 18:57:55 it's on you to vote or propose something... 18:58:08 vik and i both voted +1 18:58:10 eh, as long as it's not too big of a change 18:58:18 we need lots of big change in i-s nayway :( 18:58:28 we still didn't get the 'skip things not done during install' changes 18:58:36 i'm trying to get the anaconda folks to review those 18:58:40 er, 'skip things done during install', rather 18:59:07 tflink, pretty vital to the arm people I would say 18:59:12 proposed #agreed 971050 - AcceptedFreezeException - This causes problems in the initial configuration of the ARM images and would be nice to fix prior to release. A tested fix would be considered after freeze. 18:59:14 ( to have this fixed ) 18:59:16 ack 18:59:18 ack 18:59:24 Viking-Ice: its not arm specific 18:59:39 #agreed 971050 - AcceptedFreezeException - This causes problems in the initial configuration of the ARM images and would be nice to fix prior to release. A tested fix would be considered after freeze. 19:00:47 #topic (971117) No processing for event 'report_Uploader' is defined 19:00:50 #link https://bugzilla.redhat.com/show_bug.cgi?id=971117 19:00:52 #info Proposed Freeze Exceptions, libreport, ON_QA 19:00:53 we're at the 3hr limit 19:00:54 last one? 19:01:00 yeag 19:01:18 there is one more proposed FE but yeah, we're at the 3hr mark 19:01:51 +1, sure, this isn't required to work but nice if it does 19:02:04 as I understand it, this enables "save tb to disk" for installer crashes 19:02:10 +1 here as well 19:02:13 +1 19:03:09 proposed #agreed 971117 - AcceptedFreezeException - The file reporter is not required to work in the event of an installer traceback but it can be rather useful and can't be fixed with a post-release update. A tested fix would be considered after freeze. 19:03:16 ack 19:03:27 ack 19:03:28 ack 19:03:40 #agreed 971117 - AcceptedFreezeException - The file reporter is not required to work in the event of an installer traceback but it can be rather useful and can't be fixed with a post-release update. A tested fix would be considered after freeze. 19:03:55 do we want to do the last proposed FE in post-ASSIGNED or call it a day? 19:04:35 what is it? 19:04:54 966517 19:05:04 which should be fixed already 19:05:20 let's do it 19:05:23 oh, it doesn't matter at all 19:05:25 it's a kickstarts change anyway 19:05:31 and we don't apply the freeze on kickstarts 19:05:33 and i already fixed it 19:06:07 * adamw unproposes it 19:06:12 ok, works for me 19:06:16 well looks like it needinfo with retest on tc3 anyway 19:06:29 since we're at the 3 hour mark, I do belive that it is time for ... 19:06:33 #topic Open Floor 19:06:44 Anything else which should be discussed today? 19:06:45 dam I thought beer 19:06:54 I got nothing 19:07:04 but beer 19:07:08 anything about f19 in general? 19:07:15 looks like we're about cleared up with the tc4 compose blockers, which is good 19:07:30 i'm a bit worried about landing the i-s changes 19:07:42 we've got 10 days till go/no-go so it is starting to get down to the wire 19:07:45 what about the big gnome update 19:08:11 did we include it or not ( been busy hence have not been able to attend previous meetings ) 19:08:18 freeze hits tomorrow, so that might end up bringing us more FEs 19:08:25 Viking-Ice: what big update? hasn't been one for a while 19:08:45 adamw, think it was 3.8.3 19:08:59 which was supposed to fix alot of issues 19:09:00 the last big update was 3.8.2 19:09:20 gnome-shell 3.8.3 was a small update with mutter, g-s-d and c-c 19:09:23 that's stable already 19:09:26 ah ok 19:10:08 i guess we need to get tc4 done and tested and as many updates pushed stable as we can then re-assess where we are and identify high priority stuff 19:10:20 adamw: since TC4 compose has not yet begun (has it?), will you include the new acceptedFEs into the request? 19:11:22 tc4 dvd/netinst is done 19:11:24 lives are coming 19:11:29 ah, ok then 19:11:33 i wouldn't want to change a lot more for it anyway it's already a huge build 19:11:39 best not put any more churn in 19:12:56 so yeah, let's get TC4 built and do all the testing we can, esp. the tests we haven't hit yet 19:13:01 i really need to do some RAID and UEFI testing 19:13:04 * tflink sets fuse for [0,5] minutes 19:16:39 hmm windows 30 seconds? 19:17:27 Viking-Ice: not sure I follow 19:18:00 I think he's referring to time estimates in Windows 19:18:24 either way, 19:18:32 Thanks for coming everyone! 19:18:38 * tflink will send out minutes shortly 19:18:40 #endmeeting