17:00:41 <jlaska> #startmeeting Fedora 15 Blocker Review 17:00:41 <zodbot> Meeting started Fri Apr 15 17:00:41 2011 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:51 <jlaska> #meetingname f-15-blocker-review 17:00:51 <zodbot> The meeting name has been set to 'f-15-blocker-review' 17:00:57 <jlaska> #topic Roll Call 17:00:59 <jlaska> oh it's on 17:01:22 <adamw> like donkey kong 17:01:22 <jlaska> anyone brave enough to join our first of several marathon meetings? 17:01:24 * mclasen thinks f15 with a dash looks odd 17:01:42 * tflink is here 17:01:48 * adamw will give you two hours 17:01:56 <adamw> then i have an appointment with 20cm of fresh snow 17:02:05 <jlaska> haha, let's move fast then 17:02:11 <clumens> so sick of snow. 17:02:29 <jlaska> it's not so bad when joined with flavored syrup 17:02:42 <adamw> not the yellow stuff, though 17:02:43 <clumens> whiskeycone! 17:02:55 <jlaska> rbergeron: dgilmore: around and feeling blockery? 17:03:29 <clumens> blocked up? 17:03:31 * jlaska waits 1 more minute 17:03:34 <jlaska> clumens: :D 17:03:45 <jlaska> this release needs some fiber 17:04:27 <jlaska> okay, let's get moving 17:04:34 <jlaska> #topic Intro 17:04:38 <jlaska> For the logs ... 17:04:42 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:04:45 <jlaska> #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:05:10 <jlaska> #info We are meeting to review proposed and accepted *final* release blockers to determine whether they impact the release criteria, and are getting the attention they need 17:05:15 <jlaska> #link https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria 17:05:25 <jlaska> I'd like to start with the accepted this time if that's okay 17:05:38 <tflink> fine with me 17:05:39 <jlaska> There are only 4 bugs affecting 4 components. 17:05:41 <adamw> +1 17:05:56 <jlaska> #topic https://bugzilla.redhat.com/676114 17:06:00 <jlaska> #info iscsi --target kickstart option not actually used 17:06:16 <clumens> that Current_Release_Blockers link is pretty fancy. 17:06:30 <jlaska> clumens: it even shows the hot dog in the unlikely event we have no blockers 17:06:37 <adamw> it's witchcraft, and we should burn it. 17:06:46 <jlaska> agreed! 17:06:59 <jlaska> okay, so this bug is already in MODIFIED, and will be in the next build 17:07:21 <jlaska> it touches on, but doesn't strictly impact, the final release partitioning criteria 17:07:24 <jlaska> "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above " 17:07:27 <tflink> isn't it already in the build? 17:07:34 <jlaska> sorry ... "The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices " 17:07:39 <tflink> it sounds like the fix in question was in 15.23 17:07:43 <adamw> erm, a better one is "# The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices " 17:07:45 <jlaska> tflink: heck yeah, you are right 17:08:00 <tflink> I'm wondering if this can be closed 17:08:03 <adamw> though the bug does seem to be more specific than that 17:08:34 <adamw> ales noted "Proposing this as a blocker, user might end up installing on a different iscsi 17:08:35 <adamw> drive then intended." 17:08:50 <jlaska> tflink: I just asked for some extra test feedback from the reporter 17:08:52 <adamw> actually...we already reviewed this one 17:08:57 <adamw> "Discussed at 2011-03-11 blocker review meeting. Agreed that this is a final 17:08:57 <adamw> release blocker under criterion "The installer must be able to complete an 17:08:57 <adamw> installation using IDE, SATA, SCSI and iSCSI storage devices"." 17:08:58 <jlaska> oh? 17:09:09 <adamw> so i'm not sure we need to spend much time on it, really, especially if it's fixed already. 17:09:12 <jlaska> oh right ... duh, I'm started with accepted 17:09:17 <jlaska> yup, let's move on here 17:09:31 <jlaska> #info Appears to be resolved in F-15-Beta 17:09:36 <adamw> ack 17:09:38 <jlaska> #info Asked reporter for additional feedback 17:09:44 <clumens> yeah that fix has been for a good long time. 17:09:57 <jlaska> proposed #agreed will moved to CLOSED ERRATA next week if not VERIFIED 17:10:15 <jlaska> #agreed 676114 will moved to CLOSED ERRATA next week if not VERIFIED 17:10:22 <jlaska> next up ... 17:10:29 <jlaska> #topic https://bugzilla.redhat.com/679814 17:10:36 <jlaska> #info [abrt] gnome-user-share-2.30.2-4.fc15: do_pre_parse_initialization: Process /usr/libexec/gnome-user-share was killed by signal 6 (SIGABRT) 17:10:54 <jlaska> last abrt comment is from 2011-03-28 17:10:58 <jlaska> wonder if this is "fixed" 17:11:05 <tflink> yeah, I haven't seen this for a while 17:11:50 <adamw> and none with a version later than Discussed at 2011-03-11 blocker review meeting. Agreed that this is a final 17:11:50 <adamw> release blocker under criterion "The installer must be able to complete an 17:11:50 <adamw> installation using IDE, SATA, SCSI and iSCSI storage devices". 17:11:51 <adamw> grrr 17:12:00 <adamw> later than gnome-user-share-2.30.2-4.fc15 17:12:06 <rbergeron> HAI! 17:12:11 <jlaska> proposed #agreed 679814 - problem no longer occurs, recommend moving to CLOSED ERRATA 17:12:15 <jlaska> ack/nak/patch 17:12:21 <jlaska> rbergeron: hey there! 17:12:23 <tflink> ack 17:12:30 <adamw> current is gnome-user-share-2.91.6-1.fc15 17:12:33 <adamw> ack 17:12:47 <adamw> who's secretaryizing, btw? 17:12:59 <tflink> adamw: either you or me, I assume 17:13:05 <jlaska> adamw: I'll do it all post-meeting again ... unless someone wants to do it live 17:13:07 <adamw> i can, since you did last week 17:13:32 * jlaska thankful to anyone who grabs it first :) 17:13:47 <adamw> i've got it 17:13:54 <jlaska> thank you 17:14:01 <tflink> adamw: actually, think you did it last week but I'm certainly not going to fight you for it :) 17:14:07 <jlaska> #agreed 679814 - problem no longer occurs, recommend moving to CLOSED ERRATA 17:14:34 <adamw> nope, last week was you 17:14:41 * jlaska did it last week 17:14:47 <jlaska> moving on 17:14:49 <jlaska> #topic https://bugzilla.redhat.com/684214 17:14:53 <adamw> and by you i mean jlaska! 17:15:03 <jlaska> cranes did it 17:15:06 <jlaska> #info [abrt] libmtp-examples-1.0.5-2.fc15: op_reset_device: Process /usr/bin/mtp-detect was killed by signal 11 (SIGSEGV) 17:15:06 <tflink> ha, we were both wrong :) 17:15:14 <jlaska> another abrt crash, let's see ... 17:15:27 <adamw> there's an update for this, just needs to get pushed 17:15:43 <jlaska> someone called adamwill provided positive karma alreay 17:15:48 <adamw> it has been submitted for stable, it'll get in as soon as the freeze is lifted 17:16:07 <jlaska> perfect, this will just fall off the list then 17:16:13 <adamw> yeah, no action required 17:16:21 <jlaska> #info Submitted for stable, will land when freeze is lifted 17:16:29 <jlaska> #topic https://bugzilla.redhat.com/689260 17:16:41 <jlaska> #info [abrt] nautilus-2.91.91-1.fc15: gtk_action_group_add_action: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV) 17:16:59 <jlaska> similar, I wonder if this is still happening 17:17:19 <tflink> yeah, no testing after the last request or abrt reports, either 17:17:21 <adamw> we asked for feedback from mat, didn't get anything 17:17:33 <adamw> this is one we could also try and reproduce, i guess 17:18:00 <adamw> i know i almost never run nautilus usually... 17:18:45 * jlaska just tested the procedure in comment#3 ... it works for me 17:19:02 <mclasen> certainly works here 17:19:33 <jlaska> proposed #agreed 689260 - appears to be resolved as of F-15-Beta. Recommend closing bug, and reopen if the problem resurfaces 17:19:35 <adamw> it reads kinda like it was intermittent 17:19:36 <jlaska> ack/nak/patch? 17:19:39 <adamw> but ack 17:19:42 <tflink> ack 17:20:03 <mclasen> or ask cosimoc if he remembers fixing this crash, specifically 17:20:48 <jlaska> I can ping cosimoc after meeting and update the bug accordingly 17:20:58 <adamw> sounds good 17:21:08 <jlaska> #action jlaska - ping cosimoc whether a fix for 689260 was included in nautilus 17:21:31 <jlaska> #agreed 689260 - appears to be resolved as of F-15-Beta. Jlaska will contact cosimoc to see whether bug was fixed in recently nautilus 17:21:39 <jlaska> okay, now to proposed blockers ... 17:21:44 <jlaska> first up ... anaconda 17:21:48 <jlaska> #topic https://bugzilla.redhat.com/676551 17:21:51 <clumens> guess i'll pay attention again 17:22:00 <jlaska> #info no prompt for mediacheck 17:22:01 <jlaska> clumens: :) 17:22:26 <jlaska> this should already be included in F-15-Beta 17:22:38 <jlaska> I think we can close this out ... although I'm trying to understand the latest feedback in the bz 17:22:49 <clumens> since roughly february, yes 17:23:22 <adamw> yeah 17:23:22 <jlaska> clumens: do you understand what styler is asking for in the bz? 17:23:34 <adamw> i think it got delayed by the bug with 32-bit media checking which surfaced once the media check showed up 17:23:38 <adamw> but we have that tracked as a separate bug 17:23:54 <jlaska> roger 17:24:14 <adamw> oh, steve is claiming there should be mediacheck for netinst 17:24:20 <clumens> jlaska: he's complaining that we're not offering mediacheck for netinst, which makes no sense 17:24:28 <clumens> "Could booting the installer always detect a one-character change to 17:24:28 <clumens> isolinux.cfg, say?" 17:24:31 <adamw> because some files on the netinst image are used in install but not part of the pre-mediacheck boot, so they could be corrupt 17:24:34 <clumens> doesn't matter, loaded before anaconda ever runs 17:25:05 <adamw> clumens: well, his test seems valid 17:25:16 <adamw> he intentionally corrupted the file and tested that the installer boots but the install fails... 17:25:20 <jlaska> is this something we need to break off into a new bz, or part of the initial request? 17:25:40 <adamw> i think a separate bz is a good idea, though. 17:25:43 <adamw> since we're clearly into new territory. 17:25:49 <clumens> i don't see him say his install fails 17:25:54 <adamw> clumens: true, just noticed that 17:26:02 <clumens> notabug as far as i'm concerned 17:26:17 <adamw> so, let's close this one out and ask him to file a new one and it can get argued out there, but it doesn't need to be a blocker 17:26:40 <jlaska> proposed #agreed 676551 - Mediacheck prompt now enabled in F-15-Beta. Move to CLOSED ERRATA. Additional requests should be filed as a new bugzilla 17:26:41 <adamw> propose #agreed original bug is fixed, so close this and ask steve tyler to report a new issue for his concern about netinst 17:26:44 <adamw> ack to either 17:26:52 <jlaska> ack 17:27:13 <tflink> ack 17:27:41 <jlaska> #agreed 676551 - Mediacheck prompt now enabled in F-15-Beta, move bug to CLOSED ERRATA. Ask steve tyler to report a new issue for his concern about netinst 17:27:59 <jlaska> #topic https://bugzilla.redhat.com/678413 17:28:06 <jlaska> #info NFS ISO installs require the presence of .treeinfo 17:28:12 <jlaska> Oops, this is already fixed 17:28:14 * jlaska moves to VERIFIED 17:28:22 <jlaska> and then CLOSED ERRATA 17:28:49 <adamw> jlaska: "I'll leave this in ON_QA until we can complete a 17:28:49 <adamw> full NFS ISO installation without requiring a .treeinfo file." 17:28:53 <adamw> jlaska: is that the case now? 17:28:56 <jlaska> proposed #agreed 678413 - Already fixed in F-15-Beta, moved to CLOSED ERRATA 17:28:59 <jlaska> adamw: you got it 17:28:59 <adamw> as far as blocker status goes, it's a nobrainer 17:29:02 <adamw> okay, cool 17:29:02 <adamw> ack 17:29:27 <tflink> ack 17:29:32 <jlaska> #agreed 678413 - AcceptedBlocker, already fixed in F-15-Beta, moved to CLOSED ERRATA 17:29:54 <jlaska> #topic https://bugzilla.redhat.com/678675 17:29:59 <jlaska> #info RuntimeError: Unable to locate a needed executable: 'brcm_iscsiuio' 17:30:14 <jlaska> This was causing iSCSI installs to fail 17:30:19 <jlaska> but has since been resolved 17:30:27 <jlaska> and we can mark it VERIFIED as well 17:30:29 <adamw> okay, so ack for blocker status 17:30:35 <jlaska> you betcha 17:30:42 <jlaska> #info The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices 17:30:57 <adamw> we've confirmed that it's fixed? 17:31:08 <jlaska> proposed #agreed 678675 - AcceptedBlocker, already confirmed fix against F-15-Beta. Move to VERIFIED -> CLOSED ERRATA 17:31:11 <jlaska> adamw: yes 17:31:15 <jlaska> I'll comment to that in the bz 17:31:19 <adamw> ack 17:31:20 <tflink> ack 17:31:23 <adamw> that's okay, i'll do it 17:31:53 * jlaska holds off 17:32:07 <jlaska> adamw: we've got matrix results to back up if you need a linky 17:32:11 <adamw> yeah i see it thre 17:32:18 <adamw> it's fine, i just blamed it on you :) 17:32:29 <jlaska> #agreed 678675 - AcceptedBlocker, already confirmed fix against F-15-Beta. Move to VERIFIED -> CLOSED ERRATA 17:32:49 <jlaska> I would to! 17:32:49 <clumens> crank through 'em 17:32:57 <jlaska> #topic https://bugzilla.redhat.com/695389 17:33:06 <jlaska> #info Traceback when writing a kickstart for an unused lvm-on-raid (TypeError: 'NoneType' object is not subscriptable) 17:33:29 <adamw> +1 blocker per jlaska's comment 17:33:29 <clumens> not in a build yet 17:33:41 <adamw> and since a fix is committed, no other action needed 17:33:51 <jlaska> #info will be available for testing in anaconda-15.28-1 17:34:17 <jlaska> proposed #agreed 695389 - AcceptedBlocker, fix will arrive in next anaconda build 17:34:30 * jlaska likes the git hashes for both master and f15-branch 17:34:37 <jlaska> hey brunowolff 17:34:45 <tflink> ack 17:34:48 <adamw> ack 17:34:50 <brunowolff> I just got back from running errands. 17:35:00 * jlaska takes MODIFIED as implicit ack from clumens 17:35:05 <clumens> HELLS YEAH ACK 17:35:11 <jlaska> #agreed 695389 - AcceptedBlocker, fix will arrive in next anaconda build 17:35:17 <jlaska> #topic https://bugzilla.redhat.com/696724 17:35:32 <jlaska> #info findFirstIsoImage doesn't return the right value 17:35:40 <clumens> this is one spot wants. i have no idea why this hasn't happened in all hdiso installs yet. 17:35:42 <jlaska> clumens escalated one, what's that about? 17:36:04 <adamw> do we explicitly test HD ISO install>? 17:36:08 <adamw> i.e. is it in the matrix? 17:36:16 <clumens> if not, that'd explain it 17:36:31 <jlaska> adamw: yeah, tested and passed 17:36:39 <clumens> how in the hell 17:36:43 <jlaska> #link https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive 17:36:43 <adamw> we have nfs iso 17:36:55 <adamw> hum. 17:37:05 <jlaska> that case should be renamed HDISO 17:37:18 <adamw> well, if the fix is correct, we don't need to worry too much, i guess 17:37:28 <adamw> we can accept it as a blocker on the basis that we can't guarantee hd iso installs will work without it 17:37:30 <clumens> it's definitely a bug, yes. 17:37:50 <adamw> the fact that they seem to is probably a bug in reality 17:37:53 <jlaska> #info The installer must be able to use all supported local and remote package source options 17:37:58 <adamw> and will be reported to the creator 17:38:53 <adamw> so i'm +1 blocker 17:38:56 <jlaska> #info Unclear how F-15-Beta HD-ISO installs succeed while this bug is present 17:39:18 <jlaska> proposed #agreed 696724 - AcceptedBlocker for Final, appears to impact HD-ISO installs 17:39:30 <dgilmore> jlaska: hello 17:39:36 <jlaska> dgilmore: greetings! 17:39:37 <clumens> spot will be happy. 17:39:44 <jlaska> a happy spot should be in the criteria 17:39:49 <clumens> this will allow him to do horrible, horrible things. 17:39:51 <jlaska> the spot-clause 17:40:11 <jlaska> #agreed 696724 - AcceptedBlocker for Final, appears to impact HD-ISO installs 17:40:13 <tflink> ack 17:40:14 <jlaska> no objections, I went with it 17:40:22 <clumens> outstanding. i'll do a build later today. 17:40:42 <jlaska> clumens: thanks 17:40:44 <jlaska> #topic https://bugzilla.redhat.com/693504 17:40:48 <clumens> jlaska: no problem 17:40:59 <jlaska> #info "chkconfig NetworkManager off" does not disable the legacy NetworkManager script 17:41:29 * jlaska reading 17:42:10 <adamw> i'm not seeing any blocker criteria hit here 17:42:28 <adamw> it seems like the current status of this bug is that everything is doing what it's supposed to, but the output of chkconfig informational commands is misleading 17:42:36 <adamw> it lists sysv services that are overridden by systemd services 17:42:45 <adamw> so it may lead you to believe some services are enabled which in fact are not 17:42:51 <jlaska> and there is difficulty mapping old runlevels to systemd 17:43:19 <jlaska> If lennart comes up with something, I can't see why we should object 17:43:27 <jlaska> NTH ... or just RejectedBlocker? 17:43:39 <adamw> i'd reject this, it's not something i'd want to be twiddling with in a final RC 17:43:45 <adamw> if lennart comes up with a fix before we freeze for final, fine 17:43:48 <adamw> otherwise let's leave it alone 17:44:02 <adamw> we do still have an unfrozen period between beta release and final freeze, right? 17:44:04 <adamw> when stuff like this can land? 17:44:21 <brunowolff> Yes 17:44:22 <jlaska> I believe so 17:44:36 <adamw> okay, then yeah, i don't think this is a good nth candidate really 17:45:23 <adamw> it could be fixed with a post-release update if it doesn't make it for final, with proper unhurried testing, too 17:45:42 <jlaska> proposed #agreed 693504 - RejectedBlocker and RejectedNTH. No impact to existing criteria 17:45:55 <tflink> ack 17:46:35 <brunowolff> +1 17:46:55 <adamw> +1 17:47:04 <jlaska> #agreed 693504 - RejectedBlocker and RejectedNTH. No impact to existing criteria 17:47:22 <jlaska> #topic https://bugzilla.redhat.com/696832 17:47:28 <jlaska> #info Default Install of F15-desktop does not contain fedora desktop as default 17:47:41 <tflink> update has dependency issues 17:47:51 * tflink just tried to test it 17:48:08 <jlaska> #info The proposed final Fedora artwork must be included and enabled by default for the installer, graphical boot, firstboot, graphical login and desktop background. All Fedora artwork must be consistent with the proposed final theme, and if any artwork contains a graphical version number, the version number used must match the Fedora release number. Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the fi 17:48:34 <jlaska> pooh, we need a test in one of our matrices for this stuff 17:48:51 <adamw> yeah, we should 17:49:03 <jlaska> #action jlaska - note in retrospective that a test case is needed to capture fedora artwork criteria 17:49:14 <jlaska> I think this is pretty clear ... 17:49:33 <jlaska> proposed #agreed 696832 - AcceptedBlocker, impacts final release criteria 17:49:34 <adamw> yeah, ack for blocker (you can argue whether it hits the alpha or final criterion, but it clearly hits one or the other) 17:49:37 <adamw> ack 17:49:43 <brunowolff> +1 17:49:45 <adamw> and tflink, please note the issue with the update 17:50:01 <tflink> will do, new update has already been proposed 17:50:17 <jlaska> #agreed 696832 - AcceptedBlocker, impacts final release criteria (and possibly Alpha criteria as well) 17:50:39 <jlaska> next two bugs are tracking bugs ... I'm skipping them 17:51:01 <jlaska> well ... hrmm, okay, I should walk these also 17:51:20 <jlaska> going off the script for a moment ... 17:51:26 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683145 17:51:28 <buggbot> Bug 683145: high, unspecified, ---, rhughes, NEW, [abrt] gnome-packagekit-2.91.90-1.fc15: g_settings_schema_new: Process /usr/bin/gpk-prefs was killed by signal 6 (SIGABRT) 17:51:41 <jlaska> #info [abrt] gnome-packagekit-2.91.90-1.fc15: g_settings_schema_new: Process /usr/bin/gpk-prefs was killed by signal 6 (SIGABRT) 17:51:43 <adamw> F15Blocker-xfce should not block F15Blocker. 17:51:49 <adamw> it should block F15-accepted. 17:52:08 <jlaska> ah, correct 17:52:22 <jlaska> shall we continue with these 3 bugs, and eval them as NTH? 17:52:25 <adamw> yeah 17:52:48 <adamw> procedure in this kind of case, btw, is that if we feel it doesn't meet the NTH criteria, we drop it from the blocker bug 17:52:51 <jlaska> is there much to discuss ... I think by design we'll take these as NTH? 17:53:04 <adamw> well, by my interpretation we still hold the responsibility of evaluating the issue 17:53:09 <adamw> but usually nirik is going to get it right 17:53:13 <jlaska> right on 17:53:28 <adamw> in this case, it seems clear cut, it hits "# All applications listed under the Applications menu or category must start successfully " for the Xfce spin 17:53:34 <adamw> (and probably LXDE too) 17:53:36 <jlaska> yup 17:53:41 <adamw> so i'm +1 nth 17:54:06 * nirik looks up. 17:54:12 <jlaska> proposed #agreed 683145 - AcceptedNTH, impacts final criterai for XFCE spin (and possibly LXDE) 17:54:42 <nirik> ah, that. ok. 17:54:57 <brunowolff> +1 17:55:02 <tflink> ack 17:55:32 <adamw> nirik: i adjusted the XFCE blocker bug to block F15-accepted; if you hit any bugs in Xfce testing that you think actually do qualify as general release blockers, please just tag them as blocking F15Blocker directly 17:55:45 <nirik> sure. Sounds reasonable 17:56:05 <jlaska> #agreed 683145 - AcceptedNTH, impacts final criterai for XFCE spin (and possibly LXDE) 17:56:16 <jlaska> #info Adamw adjusted the XFCE blocker bug to block F15-accepted; if you hit any bugs in Xfce testing that you think actually do qualify as general release blockers, please just tag them as blocking F15Blocker directly 17:56:28 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694889 17:56:30 <buggbot> Bug 694889: unspecified, unspecified, ---, cwickert, ON_QA, GTK+ 3 applications are not themed 17:56:34 <jlaska> #info GTK+ 3 applications are not themed 17:56:56 <adamw> another xfce-specific one 17:57:05 <mclasen> fyi, wrt to the gpk bug: richard is on vacation this week, and I believe the next one 17:57:10 <mclasen> and I'll be gone next week 17:57:17 <adamw> as an obvious polish issue, +1 NTH 17:57:42 * nirik notes that clearlooks was dropped, so we need to figure out what to do there too... 17:57:54 <dgilmore> nirik: its already underway 17:58:03 <nirik> and we have added Adwaita 17:58:07 <dgilmore> gnome-themes is dropping its Requires 17:58:07 <adamw> mclasen: you mean...the week we re-arranged the final GNOME 3 test day to happen? 17:58:23 <adamw> mclasen: you could have mentioned that, in either of the threads I posted about re-arranging the final GNOME 3 test day. :/ 17:58:35 <mclasen> adamw: scheduling is hard... 17:58:37 <adamw> heh 17:58:47 <jlaska> #chair adamw 17:58:47 <zodbot> Current chairs: adamw jlaska 17:58:48 <adamw> off-topic for this meeting anyways, sorry 17:58:53 <nirik> dgilmore: yeah. xfce ks used it directlry. :( 17:59:01 <dgilmore> ahh ok 17:59:18 <jlaska> so what's the basis for taking this as NTH? 17:59:23 <adamw> obvious polish issue 17:59:32 <adamw> can't sensibly be addressed in a post-release update (as it'll still happen on live) 17:59:37 <jlaska> okay 18:00:10 <jlaska> proposed #agreed 694889 - AcceptedNTH. Polish issue that can't easily be addressed post-release update 18:00:19 <tflink> ack 18:00:25 <dgilmore> 1 18:00:30 <dgilmore> + 18:00:37 <brunowolff> +1 18:00:41 <jlaska> #agreed 694889 - AcceptedNTH. Polish issue that can't easily be addressed post-release update 18:00:52 <jlaska> last XFCE proposed NTH ... 18:00:54 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694897 18:00:55 <buggbot> Bug 694897: unspecified, unspecified, ---, cwickert, ASSIGNED, Icons missing in desktop menu 18:00:59 <jlaska> #info Icons missing in desktop menu 18:01:19 <adamw> again, hits a release criterion 18:01:20 <adamw> "# All Applications listed in the desktop menus must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry " 18:01:28 <adamw> so, per policy, no-brainer NTH 18:02:04 <jlaska> proposed #agreed 694897 - AcceptedNTH, impacts application icon criteria for XFCE spin 18:02:17 <tflink> are just the icons missing, or the parts of the menu? 18:02:29 <adamw> just the icon missing is sufficient to hit the criterion 18:02:47 <tflink> point 18:02:48 <jlaska> menu entries without an icon 18:02:49 <tflink> ack 18:03:23 <jlaska> #agreed 694897 - AcceptedNTH, impacts application icon criteria for XFCE spin 18:04:07 <jlaska> okay, back to proposed blockers 18:04:08 <jlaska> #topic https://bugzilla.redhat.com/676520 18:04:13 <jlaska> #info [abrt] empathy-2.91.6.1-3.fc15: g_list_length: Process /usr/bin/empathy-accounts was killed by signal 11 (SIGSEGV) 18:04:34 <adamw> should we add AcceptedBlocker to the other tracker (dep tracker) jsut to get it off the list? 18:04:58 <jlaska> adamw: I skipped that for now ... 18:05:02 <jlaska> can we revisit that next week? 18:05:11 * jlaska filed that tracker, and plans to autofile a lot of bugs into it 18:05:17 * mclasen could not reproduce 676520 last night 18:05:45 <adamw> sure 18:05:45 <jlaska> I guess, if they manifest on the DVD, I'll move them to the blocker list 18:06:22 <jlaska> Thank you John Watzke for escalating the bug with criteria 18:06:22 <adamw> yeah, i've run empathy a few times in the last month and didn't hit this 18:06:25 <adamw> i'd say it's fixed 18:06:59 * tflink just tried, no crashy 18:07:00 <adamw> propose acceptedblocker, closed errata 18:07:09 <jlaska> ack 18:07:15 <tflink> ack 18:07:17 <mclasen> adamw: it only counts if you run it with a11y turned on, but yeah 18:07:52 <adamw> okay. we'll get a new report if anyone else hits it, i guess. 18:08:25 <jlaska> #agreed 676520 - AcceptedBlocker, appears to be resolved as of F-15-Beta. Recommend moving to CLOSED ERRATA 18:08:46 <jlaska> #info mclasen noted this bug only occurs when a11y is enabled 18:08:50 <jlaska> #topic https://bugzilla.redhat.com/675652 18:09:05 <jlaska> #info Can't start alternative (non-default) DE with gdm-2.91.6-2.fc15 18:09:22 <jlaska> oops, I neglected to add the appropriate whiteboard field on this last time 18:09:35 <jlaska> or, a long time ago (02-18) 18:09:38 <adamw> the bug reported here has been fixed for a while, we can close it 18:09:40 <mclasen> jlaska: well, I didn't notice it occur at all; but the codepath is related to a11y 18:09:46 <jlaska> mclasen: okay 18:09:46 <adamw> gdm has a session chooser 18:10:12 <jlaska> I don't think I've seen it in F-15 ... does it appear only when multiple DE's are available? 18:10:22 <adamw> dunno, i've seen it though. 18:10:27 <adamw> don't have f15 here to have a look 18:10:42 <jlaska> proposed #agreed 675652 - AcceptedBlocker. Recommend CLOSED ERRATA as this has been resolved for some time 18:10:49 <jlaska> ack/nak/patch? 18:11:07 <tflink> ack - I don't remember seeing this on my gnome + kde system (using gdm) 18:11:45 <adamw> ack 18:11:52 <jlaska> #agreed 675652 - AcceptedBlocker. Recommend CLOSED ERRATA as this has been resolved for some time 18:12:01 <adamw> tflink: so, you can choose KDE to log in on said system, right? 18:12:10 <jlaska> Anyone want to #action examining the current state of the DE chooser? 18:12:22 <adamw> well, if tflink says yes to my question i think we've done that :) 18:12:50 <tflink> adamw: yeah, last time I tried 18:12:51 <mclasen> just copy a second desktop file in /usr/share/xsessions, and the session chooser will appear 18:12:58 * mclasen has seen it before 18:13:16 <adamw> okay, so we're good there. 18:13:19 <tflink> I can try it again to make sure 18:13:21 <jlaska> cool 18:13:31 <mclasen> this feature is actively used by shell hackers to look into their jhbuild sessions 18:13:39 <jlaska> clever 18:13:39 <mclasen> log into, even 18:13:55 <jlaska> #topic https://bugzilla.redhat.com/678236 18:14:00 <jlaska> #info User list sometimes not visible on greeter 18:14:15 <mclasen> I haven't been able to reproduce that, recently 18:14:20 <jlaska> oh I see ... we already acceptedNTH this one 18:14:21 <adamw> we've accepted this as NTH for beta, but not evaluated as final blocker 18:14:26 <adamw> i'm still seeing this 18:14:29 <dgilmore> saw it yesterday 18:14:29 <jlaska> but I didn't remove the blocks:Blocker 18:14:30 <jlaska> me too 18:14:32 <dgilmore> I saw it 18:14:32 <adamw> on my installed system, and on test installs 18:14:40 <adamw> jlaska: it's proposed as blocker for final 18:14:41 <mclasen> if people are still seeing this, I recommend bothering halfline once he's back from his honeymoon 18:14:55 <jlaska> adamw: oh oh, /me looks for undo button 18:14:55 <dgilmore> mclasen: its still an issue 18:15:09 <dgilmore> #undo 18:15:15 <jlaska> adamw: prepare for bz mail spam 18:15:20 <adamw> it's kinda borderline, to me...it doesn't really completely break anything, but it's a pretty big problem 18:15:22 <mclasen> dgilmore: any chance to catch a stacktrace of the greeter when it crashes ? 18:15:37 <dgilmore> mclasen: i did not try 18:15:47 <mclasen> actually, maybe try the accountsservice 0.6.9 update I just built today 18:15:51 <jlaska> not sure if it's related, but I see interesting results when I restart sssd while gdm is waiting for user/password 18:15:54 <dgilmore> i just know i had to select other and type in the user name 18:15:55 <mclasen> it has a crash fix related to removing users 18:16:08 <adamw> mclasen: that sounds like a good candidate 18:16:10 <dgilmore> i did notice that it chose gnome as the session even though i never use it 18:16:16 <jlaska> adamw: what were your thoughts around criteria for this one? 18:16:53 <adamw> it's hard to massage it into the criteria 18:17:03 <mclasen> dgilmore: it should certainly remember your last selection 18:17:05 <adamw> it's more of a candidate for the cop-out clause 18:17:08 <jlaska> is this more the lack of a feature we've all come to expect? 18:17:18 <mclasen> dgilmore: if it doesn't that would be a bug, probably not a blocker though 18:17:25 <adamw> but it doesn't really match that either (it could be fixed in an update) 18:17:32 <adamw> so...we're short of valid reasons to accept this as a blocker 18:17:35 <dgilmore> mclasen: pretty regullary thats been dropped. i should try work out why and file a bug 18:17:44 <jlaska> does this impact live autologin? 18:17:50 <tflink> adamw: does this still show up in livecd? 18:17:56 <jlaska> if so, I think that's a valid blocker 18:17:59 <tflink> i thought it was, at least at one point 18:18:00 <jlaska> otherwise, punt! 18:18:05 <mclasen> greeter issues can't really affect autologin 18:18:09 <adamw> good question, i'm not sure. 18:18:12 <mclasen> since there is no greeter in autologin 18:18:21 * adamw kinda lost track of autologin in general 18:18:25 <adamw> does the beta actually autologin? 18:18:31 * adamw remembers it always dumping you at gdm 18:18:32 <jlaska> iirc, yes 18:18:41 <adamw> but imbw 18:18:58 <tflink> when i tried the beta rc2 livecd, autologin worked 18:19:02 <adamw> okay... 18:19:23 <adamw> maybe we should have an intern boot beta rc2 a few dozen times and see what happens :P 18:19:33 <adamw> so, let's see...i think this is a no-brainer NTH 18:19:34 <jlaska> test@ ? 18:19:36 * mclasen gotta run, will be around again later in the afternoon, if any questions come up 18:19:41 <jlaska> mclasen: thanks! 18:19:43 <adamw> for blocker, maybe depends on impact on live boot 18:19:45 <adamw> thanks mclasen 18:19:48 * mclasen will check the resulting blocker list tonight, otherwise 18:20:06 <adamw> jlaska: yeah, test@ is a good idea 18:20:15 <adamw> ask if anyone's been dumped to an empty gdm when booting the live image 18:20:20 <jlaska> if no one wants it, I'll send that post-meeting 18:20:34 <adamw> so...shall we mark as accepted NTH and still proposed blocker and revisit next week? 18:20:42 * tflink can do the email 18:20:49 <jlaska> #action tflink - request test feedback on autologin experience with F-15-Beta-RC2 18:20:54 <jlaska> tflink: rockin' thank you :) 18:21:02 <jlaska> adamw: yeah, that sounds safe to me 18:21:04 <jlaska> ack 18:21:28 <jlaska> proposed #agreed 678236 - AcceptedNTH for file, leave blocks:F15Blocker for discussion at next meeting 18:21:32 <jlaska> proposed #agreed 678236 - AcceptedNTH for final, leave blocks:F15Blocker for discussion at next meeting 18:21:37 * jlaska likes words 18:21:43 <adamw> ack 18:22:02 <brunowolff> +1 18:22:07 <tflink> ack 18:22:09 <jlaska> #agreed 678236 - AcceptedNTH for final, leave blocks:F15Blocker for discussion at next meeting 18:22:37 <jlaska> #topic https://bugzilla.redhat.com/695446 18:22:45 <jlaska> #info What the FEDORA? 18:23:09 <adamw> if unintentional, as the existence of an update implies, this hits the final artwork criteria. 18:23:11 <jlaska> I wasn't sure what the intended icon was supposed to be here 18:23:15 <adamw> (as the artwork criteria depend on intention) 18:23:16 <jlaska> right on 18:23:18 <jlaska> #info The proposed final Fedora artwork must be included and enabled by default for the installer, graphical boot, firstboot, graphical login and desktop background. All Fedora artwork must be consistent with the proposed final theme, and if any artwork contains a graphical version number, the version number used must match the Fedora release number. Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the fi 18:23:22 <adamw> so, given there's an update for it, +1 blocker 18:23:26 <jlaska> ack 18:23:53 <tflink> ack 18:24:24 <tflink> the title of the bug is bad, but that's a bit off-topic 18:24:41 <jlaska> #agreed 695446 - AcceptedBlocker for final - Pending bodhi update implies this indeed was an unintentional change, and impacts the final release artwork criteria 18:24:42 <adamw> yeah, if anyone wants to make it more boring but useful, go ahead 18:25:03 * jlaska takes credit for suggesting the off-color $subject 18:25:05 <clumens> not to mention meatless 18:25:33 <jlaska> it was my new shock campaign for bz's to get them on the radar faster 18:25:54 <jlaska> #topic https://bugzilla.redhat.com/676437 18:25:59 <jlaska> #info Build gjs against the standalone SpiderMonkey package 'js', not XULRunner's copy 18:26:06 <adamw> for me, this doesn't hit any blocker criteria 18:26:19 <jlaska> is this related to the 'js' dependency issue? 18:26:21 <adamw> kinda 18:26:28 <jlaska> impacts depsclosure on DVD? 18:26:32 * jlaska tossing it out there 18:26:34 <adamw> the dep issue is the result of a change which was introduced as a precursor for that 18:26:40 <adamw> s/that/this bug/ 18:26:42 <jlaska> okay, so it's a few steps removed 18:26:45 <adamw> but this bug isn't a good place to track that dep issue 18:27:04 <jlaska> wasn't there another, more appropriate, bz 18:27:05 * jlaska looking 18:27:09 <adamw> the dep issue only happens if someone tries to *fix* this bug; if we leave it alone, no dep isssue :) 18:27:11 <adamw> probably 18:27:27 <jlaska> oh I see 18:27:40 <jlaska> and by itself, the bug this is intending to fix is not a criteria blocker? 18:27:48 <adamw> the impact of this particular bug is as caillon outlines it: as things stand, gnome 3 depends on firefox, so when firefox gets an update, we need to rebuild bits of gnome 3, and they figure that's not optimal 18:27:55 <adamw> i'd agree, but it also doesn't hit any criteria i can see 18:28:13 <jlaska> seems like a valid NTH candidate given this does impact update ability, in an indirect manner 18:28:18 * dgilmore doesnt think its a blocker 18:28:28 <dgilmore> and its something that could be resolved post release 18:28:31 <tflink> could we fix it with updates? 18:28:38 <dgilmore> tflink: yes 18:28:40 <adamw> well, in a way, but i'm ambivalent on NTH, because i don't see that we gain anything vs. fixing with an update 18:28:40 <jlaska> hmm, yeah I guess so 18:28:52 <dgilmore> adamw: same her 18:28:54 <dgilmore> here 18:28:55 <jlaska> so ... 18:29:02 <jlaska> we'll take a fix before freeze if available on this one 18:29:06 <jlaska> otherwise ... post-release 18:29:07 <tflink> if getting js into F15 isn't going to be an issue, I'm of the same mind 18:29:22 <adamw> tflink: it wouldn't be, packages can be added even post-release if appropriate 18:29:36 <adamw> so...yeah, +1 to jlaska proposal 18:29:43 <adamw> it's an important issue, but it doesn't really match NTH 18:29:54 <jlaska> proposed #agreed 676437 - RejectedBlocker + RejectedNTH. Does not impact release criteria and can be resolved as an update. Will accept fix prior to freeze if available + tested 18:30:04 <tflink> ack 18:30:26 <brunowolff> +1 18:30:42 <adamw> ack 18:30:57 <jlaska> #agreed 676437 - RejectedBlocker + RejectedNTH. Does not impact release criteria and can be resolved as an update. Will accept fix prior to freeze if available + tested 18:31:12 <jlaska> #topic 18:31:53 <jlaska> #topic https://bugzilla.redhat.com/685142 18:32:02 <jlaska> #info Menu problems with fallback mode 18:32:29 <jlaska> I agree with taking this change, but not sure what criteria this affects 18:33:47 <adamw> yeah...we don't have any criteria requiring anything specific to be in the menus 18:34:10 <adamw> if the lack of something in the menus made it impossible to meet other criteria that would qualify, i'm not sure this does though 18:34:12 <jlaska> gpk-application missing from the GNOME fallback menu, would that impact a users ability to update their system 18:34:19 <adamw> yeah, that's what i was about to suggest 18:34:40 <adamw> we could argue it hits "# The installed system must be able to download and install updates with yum and PackageKit " but it's a stretch 18:34:42 <jlaska> documenting 'yum install' from a terminal in fallback mode would kind of suck 18:34:51 <adamw> that criterion doesn't specify anything about how easy it needs to be to run PackageKit... 18:34:56 <adamw> just that it needs to work 18:34:56 <jlaska> true 18:35:07 <adamw> well, the workaround would be 'hit alt-f2 and run blahblah' 18:35:22 <jlaska> well, while I welcome the fix, this doesn't clearly violate any existing criteria 18:35:25 <adamw> given that we have a fix for this i think we can just lowball it and move on 18:35:37 <jlaska> reject it, and move on? 18:35:41 <adamw> let's accept it as NTH and move on, if we were closer to release and had no fix i'd be more worried 18:35:47 <jlaska> roger 18:35:54 * jlaska working #agreed 18:36:30 <jlaska> proposed #agreed 685142 - AcceptedNTH - Does not impact any release criteria, nor does it prevent a user from upgrading using yum or PackageKit. Will take a tested fix if available 18:36:54 <tflink> ack 18:37:02 <jlaska> #agreed 685142 - AcceptedNTH - Does not impact any release criteria, nor does it prevent a user from upgrading using yum or PackageKit. Will take a tested fix if available 18:37:08 * jlaska goes with adamw + tflink's acks 18:37:16 <jlaska> feel free to nak while I work on next #topic 18:37:32 <jlaska> #topic https://bugzilla.redhat.com/674895 18:37:47 <jlaska> #info [abrt] gnome-power-manager-2.91.5-2.fc15: Process /usr/bin/gnome-power-manager was killed by signal 11 (SIGSEGV) 18:38:10 <jlaska> I think this has long since been resolved 18:38:15 <jlaska> mclasen asked for recent test feedback 18:38:26 <adamw> this looks like a no-brainer blocker, but hasn't been reported for a while 18:38:30 <adamw> can anyone do a quick test? 18:38:36 <adamw> just open system settings and click Power 18:38:36 * jlaska just confirmed 18:38:42 <adamw> okay, so let's accept as blocker and close it 18:39:02 <jlaska> looks good here with control-center-3.0.0.1-3.fc15.x86_64 18:39:02 <jlaska> gnome-power-manager-3.0.0-1.fc15.x86_64 18:39:06 <jlaska> ack 18:39:07 * tflink just tried it, too. opening the power management panel => no crashy 18:39:34 <tflink> ack 18:39:37 <jlaska> #agreed 674895 - AcceptedBlocker, appears to be long since resolved. Recommend CLOSED ERRATA 18:39:49 <jlaska> #topic https://bugzilla.redhat.com/684218 18:39:57 <jlaska> #info [abrt] gnome-shell-2.91.91-1.fc15: gjs_object_from_g_object: Process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV) 18:40:26 <jlaska> I saw this a month ago, but haven't hit this at all recently 18:40:43 <jlaska> only oddball crash I had was when doing a gpk-application install of @Virtualization yesterday 18:40:52 <adamw> gnome-shell respawns on crashes 18:40:59 <adamw> so for me, any crash in shell is not automatically a blocker 18:41:07 <adamw> it's a polish issue, which makes it a judgement call (how common is it) 18:41:20 <adamw> only a crash which it couldn't recover from would auto-block for me 18:41:25 <jlaska> oh right, so my crash was different then (I suspect gpk-application logged me out, instead of prompting to logout -- or X crashed) 18:41:30 <jlaska> okay 18:41:51 <adamw> yeah, if you wind up back at gdm it's not (only) a shell crash, i think 18:42:08 <adamw> (btw, top tip - run abrt-gui as root occasionally to check for crashes in things which run as root) 18:42:17 <adamw> like X 18:42:22 <jlaska> proposed #agreed 684218 - RejectedBlocker, moved to CLOSED ERRATA - gnome-shell crashes are recoverable, and likely don't block existing criteria 18:42:25 <jlaska> adamw: right 18:42:41 * jlaska meaning to go back and test that after dequeueing some other items 18:42:43 <adamw> given that this one seems to happen only intermittently and not to many people, i'd be -1 blocker 18:42:58 <tflink> and it hasn't been re-reported in a month 18:43:04 <jlaska> right 18:43:05 <adamw> i'm not sure about closing it right off, it might be best to check with desktop team first if they believe this to be fixed 18:43:20 <adamw> but we could do that and ask if any reporter has seen the same crash lately, and revisit closing it later 18:43:32 <tflink> sounds like a plan to me 18:43:34 <adamw> also -1 nth for me, since it could be fixed fine with an update 18:43:46 <jlaska> UPDATED proposed #agreed 684218 - RejectedBlocker - check with reporter + mclasen to see if this has been resolved recently 18:43:59 <tflink> ack 18:44:31 <jlaska> #agreed 684218 - RejectedBlocker - check with reporter + mclasen to see if this has been resolved recently 18:44:45 <jlaska> eew, this next one will be fun 18:44:47 <jlaska> #topic https://bugzilla.redhat.com/689012 18:44:54 <jlaska> #info Very hard to resize a window 18:45:10 <jlaska> oh, window border, not window icons ... okay 18:45:21 <tflink> hmm, I think it's easier than my F14 openbox setup, but that isn't saying much :-D 18:45:37 <jlaska> heh 18:45:54 <jlaska> I can't see blocking the release for this one either - given existing criteria 18:46:05 <jlaska> nor NTH, as this can be fixed in an update 18:46:08 * jsmith doesn't see it as a blocker 18:46:09 <jlaska> what am I missing? 18:46:21 <adamw> is this even a regression? 18:46:33 <adamw> in a quick test, the border on windows in my f14 install seems to be about 4 pixels as well. 18:46:40 <adamw> and there's a drag handle in lower right on f15 still, yes? 18:46:55 <adamw> yeah, exactly 4 pixels in f14 with default theme (clearlooks). 18:47:06 <adamw> so yeah, -1 blocker, -1 nth for me too 18:47:19 <tflink> adamw: not on all windows 18:47:24 <jlaska> proposed #agreed 689012 - RejectedBlocker + RejectedNTH - does not impact any final release criteria. Will include a tested fix prior to freeze. 18:47:35 <tflink> ack 18:47:35 <brunowolff> +1 18:47:35 <jlaska> yeah there are some modal dialogs that have non-existent borders? 18:47:51 <jsmith> +1 to proposal 18:47:52 <jlaska> but Iguess those are intentionally non-resizable 18:47:55 <tflink> oh, I was just talking about the drag handle in the corner 18:48:00 <tflink> FF doesn't have one 18:48:02 <jlaska> tflink: oh yeah, you're right 18:48:16 <jlaska> #agreed 689012 - RejectedBlocker + RejectedNTH - does not impact any final release criteria. Will include a tested fix prior to freeze. 18:48:34 * jlaska moving along 18:48:36 <jlaska> #topic https://bugzilla.redhat.com/674799 18:48:38 <tflink> neither does virt-manager. I'm sure there are more 18:48:42 <jlaska> #info Isn't dragged in for upgrades 18:49:06 <adamw> tflink: maybe gtk+2 apps. file that one separately i guess 18:49:19 <jlaska> aaah 18:49:31 <tflink> adamw: is everything supposed to have the drag bar? 18:49:43 <adamw> tflink: i think any normal app should, yeah 18:49:50 <adamw> in F14, firefox has a handle 18:50:06 <adamw> virt-manager doesn't... 18:50:13 <tflink> per-app setting maybe? F15 has FF4 18:50:21 <adamw> yeah it may be an ff4 thing actually 18:50:25 <adamw> they played with the status bar in ff4 18:50:29 <adamw> so...even less worried. 18:50:37 <jlaska> any take aways before we move on? 18:50:42 <jlaska> #action or #info 's 18:50:55 * tflink makes a note to look into this a bit more ... later :) 18:51:01 <jlaska> okay 18:51:11 <adamw> i've noted the bug 18:51:18 <tflink> but I imagine that there is nothing to not about it 18:51:23 <tflink> s/not/note 18:51:28 <adamw> next bug! 18:51:29 <jlaska> for $topic bug, I don't recall whether this package was installed or not ... I've kicked off a test in the background 18:51:36 <adamw> i'm behind schedule here :P 18:51:45 <jlaska> I'm not sure how, or whether, this affects artwork in any way 18:51:58 <jlaska> we don't have criteria that the upstream artwork must be final and included 18:52:00 <adamw> i would hazard a guess that this has changed quite a bit since the bug was filed 18:52:14 <jlaska> yeah, it's an oldie 18:52:22 <adamw> i think we should ask for more info on the impact of this, and punt to next week 18:52:39 <jlaska> proposed #agreed 674799 - request test and impact feedback in bug - leave on list for next meeting 18:52:44 <adamw> ack 18:52:46 <tflink> I can try it when I test the default background thing 18:52:48 <tflink> ack 18:53:59 <jlaska> #agreed 674799 - request test and impact feedback in bug - leave on list for next meeting 18:54:11 <jlaska> #topic https://bugzilla.redhat.com/658387 18:54:18 <jlaska> #info Patch to allow mbkernel and mbargs to be read from /etc/sysconfig/kernel 18:54:37 <jlaska> "Adding as a Fedora 15 blocker because FESCO has accepted the Xen pvops Dom0 18:54:40 <jlaska> feature for Fedora 15" 18:54:51 <jlaska> I think we just drop the feature from the list, rather than block the release for the feature, no? 18:54:54 <jlaska> or is that FESCO's call? 18:55:02 <tflink> I thought that we already put this feature off 18:55:17 <adamw> that's our policy at present - non-implemented features don't block the release 18:55:21 <tflink> we did, searching for link 18:55:23 <jlaska> it's been moved to FeaturePageIncomplete 18:55:38 <jlaska> rbergeron - dropped from F15 - moving back to featurepageincomplete category 18:55:41 <adamw> so, this looks like -1 from any angle 18:55:43 <jlaska> punt! 18:55:53 <tflink> http://lists.fedoraproject.org/pipermail/xen/2011-April/005430.html 18:56:04 <jlaska> #agreed 658387 - RejectedBlocker - Feature dropped from F-15 release 18:56:23 <jlaska> #topic https://bugzilla.redhat.com/668063 18:56:29 <jlaska> #info Grubby does not handle "template" that uses module keywork properly 18:56:48 <jlaska> btw ... if I'm moving too fast, or you feel a vote wasn't considered ... we can easily slow down... just shout 18:57:03 <rbergeron> yes 18:57:11 <rbergeron> dropped :) 18:57:15 <jlaska> same issue for $topic bug 18:57:21 <tflink> yep 18:57:33 <jlaska> #agreed 658387 - RejectedBlocker - Feature dropped from F-15 release 18:57:41 <jlaska> #topic https://bugzilla.redhat.com/696510 18:57:47 <jlaska> #info need a dependency in ibus-gtk3 for imsettings-gnome 18:57:48 <adamw> ditto with last bug 18:57:54 <adamw> oof, i'm too slow :) 18:58:11 <jlaska> "The impact on missing this fix would be that the behavior on selecting immodule 18:58:14 <jlaska> on GTK+ applications totally becomes unpredictable. we should avoid this 18:58:17 <jlaska> regression on f15." 18:58:21 <jlaska> I think this bug is affected by the recently adjusted upgrade criteria? 18:58:39 <jlaska> Possibly the beta criteria ... "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria " 18:58:50 * jlaska notes the last bit "The upgraded system must meet all release criteria" 18:59:13 <adamw> well, the change is the new wiggle clause: 18:59:14 <adamw> "There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgment and refer to precedent to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by the issue, th 18:59:14 <adamw> e severity of the case when the issue is encountered, and the ease or otherwise with which the issue can be avoided by both informed and uninformed users. " 18:59:24 <adamw> which basically says 'if it's an i18n issue we argue about how important it is' 18:59:30 <tflink> how often is this happening 18:59:39 <tflink> it looks like it was just reported a couple of days ago 18:59:40 <adamw> it would happen on all upgrades 18:59:40 <jlaska> adamw: good point, yeah 18:59:42 <adamw> aiui 18:59:47 <adamw> the exact impact is less clear 18:59:58 <adamw> "the behavior on selecting immodule 18:59:58 <adamw> on GTK+ applications totally becomes unpredictable" 19:00:01 <jlaska> perhaps we should ask for more info one how this failure manifests? 19:00:10 <adamw> i'm not entirely sure what 'totally unpredictable' means, but it doesn't sound good 19:00:20 * jsmith wonders if he's the only one having trouble parsing that impact 19:00:24 <adamw> on the face of it it means 'it's a lottery what input method you get', which is kind of a major problem :) 19:00:27 <adamw> jsmith: no, you're not 19:00:39 <adamw> i think asking for clarification on the impact is a good idea 19:01:13 <jlaska> proposed #agreed 696510 - Unclear impact to release criteria - Request more information in bug, and review at next meeting 19:01:18 <tflink> ack 19:01:46 <jlaska> anyone else? 19:01:48 <jsmith> ACK 19:02:06 <brunowolff> +1 19:02:09 <jlaska> thanks 19:02:11 <jlaska> #agreed 696510 - Unclear impact to release criteria - Request more information in bug, and review at next meeting 19:02:36 <jlaska> #topic https://bugzilla.redhat.com/693809 19:02:48 <jlaska> #info no imsettings-gnome installed on upgrading 19:02:51 <tflink> this is at least related 19:02:54 * jlaska experiencing deja vu 19:02:56 <tflink> to the previous bug 19:02:58 <adamw> i think it's the same bug. 19:03:26 <adamw> although: 19:03:26 <adamw> "Anyway, I strongly feel that the real bug is that this message exists at all." 19:03:28 <tflink> I think this bug is more about the warning message instead of the cause 19:03:35 <jlaska> yeah 19:03:35 <adamw> yeah 19:03:57 <adamw> this is kind of a design argument 19:04:15 <jlaska> yup, not sure this has any impact on criteria 19:04:21 <adamw> chris thinks it's a bad idea to have such a message at all, akira thinks it's necessary for people who are trying to set up an input-method dependent language and have screwed it up somehow 19:04:28 <adamw> given that, i wouldn't see it as a blocker 19:04:38 <jlaska> what's the appropriate forum for them to duke it out? 19:04:45 <jlaska> bz, elsewhere? 19:04:48 <adamw> this bug is fine i think 19:04:54 <adamw> we should update the summary though 19:05:36 <jlaska> proposed #agreed 693809 - RejectedBlocker + RejectedNTH - does not impact release critera, can be fixed as an update - Will accept a tested update prior to Final freeze 19:05:54 <adamw> ack 19:05:55 <tflink> ack 19:06:02 <brunowolff> +1 19:06:05 <jlaska> #agreed 693809 - RejectedBlocker + RejectedNTH - does not impact release critera, can be fixed as an update - Will accept a tested update prior to Final freeze 19:06:35 <jlaska> adamw: did you want to change the topic as well, while updating? Confusing warning dialog on login from im-settings ? 19:06:45 <adamw> i did 19:06:49 <jlaska> roger 19:06:53 <jlaska> #topic https://bugzilla.redhat.com/692187 19:07:04 <jlaska> #info /etc/rc.d/init.d/netfs: line 47: mdadm: command not found 19:07:26 <jlaska> I raised this, but I don't think it qualifies now 19:07:32 <jlaska> we don't have criteria for a clean boot.log? 19:07:39 <jlaska> besides, it's fixed already 19:07:48 <adamw> yeah, did it actually result in anything not working</ 19:07:50 <adamw> ? 19:07:52 <adamw> if not, i'd say no blocker. 19:07:55 <jlaska> not that I could tell 19:08:08 <adamw> okay, so -1 blocker, not too worried since there's a fix in. 19:08:20 <jlaska> proposed #agreed 692187 - RejectedBlocker - already fixed in proposed update 19:08:29 <tflink> ack 19:08:54 <jlaska> #agreed 692187 - RejectedBlocker - already fixed in proposed update 19:09:04 * jlaska included ack's from me + adamw in that mix as well 19:09:10 <jlaska> #topic https://bugzilla.redhat.com/695280 19:09:14 <jlaska> hmm, a docs bug 19:09:18 <jlaska> #info Installer unable to find correct dvd from nfsiso repository containing a set of images 19:10:21 <jlaska> I agree with clumens on the use case here ... I think we just need to circle back and update any test cases and docs 19:10:27 <jlaska> but whether that's a release blocker, I don't think so 19:10:30 <adamw> yeah...it works if you do it 'as intended', so i don't think it's a blocker 19:11:02 <jlaska> #action jlaska - review NFSISO test and install-guide to ensure desired .ISO is the only ISO in directory 19:11:20 <tflink> it would be nice to have fixed before release, but yeah. not a blocker 19:11:25 <jlaska> proposed #agreed 695280 - RejectedBlocker - documentation bugs do not impact existing release criteria 19:11:28 <jlaska> ack/nak/patch? 19:11:31 <tflink> ack 19:11:34 <adamw> ack 19:11:35 <brunowolff> +1 19:11:52 <jlaska> tflink: agreed, I'll poke at that afterwards 19:11:55 <jlaska> #agreed 695280 - RejectedBlocker - documentation bugs do not impact existing release criteria 19:12:28 <jlaska> okay, we've hit the KDE blocking tracker bug ... shall we walk that list? 19:12:31 <jlaska> 4 bugs 19:12:45 <adamw> yeah 19:12:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=661395 19:12:52 <buggbot> Bug 661395: medium, low, ---, peter.hutterer, ASSIGNED, some keyboard options/layouts (set via system-config-keyboard) make gdm/kdm input non-functional 19:12:55 <jlaska> #info some keyboard options/layouts (set via system-config-keyboard) make gdm/kdm input non-functional 19:13:11 <jlaska> oldie 19:13:32 <jlaska> I'd think updated test feedback from the Beta is in order here 19:13:43 <adamw> this seems to be a generic blocker, not just kde 19:13:51 <adamw> (it's proposed on its own merit as well as via kde blocker) 19:13:58 <jlaska> okay 19:14:01 <adamw> this is another one that hits the new weasel clause 19:14:17 <adamw> but given the impact is pretty nasty, as described i'd be +1 blocker 19:14:18 <jlaska> heh, yeah 19:14:28 <jlaska> this comes down to # of affected users? 19:14:34 <jlaska> and I'd wager it's high on this 19:14:42 <adamw> yeah 19:14:45 <adamw> well 19:14:49 <tflink> assuming it's not fixed 19:14:54 <jlaska> right on 19:14:57 <tflink> no reports since 2011-02-18 19:15:03 <adamw> there's two issues here too (s-c-k setting invalid layouts, and X not falling back well when that happens) 19:15:28 * jlaska doesn't see rex in channel 19:15:40 <adamw> i propose we accept as a blocker but ask for an update 19:15:46 <adamw> see if anyone's changed anything here yet 19:15:51 <jlaska> works for me, revisit next week 19:15:54 <jlaska> ack 19:15:57 <tflink> yeah, that makes sense 19:16:13 <jlaska> #agreed 661395 - AcceptedBLocker - Request updated test feedback in bug, and monitor for progress 19:16:22 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683629 19:16:24 <buggbot> Bug 683629: low, unspecified, ---, than, NEW, KWin doesn't start up in firstboot, error message: Configuration file "/root/.kde/share/config/kdedrc" not writable 19:16:28 <jlaska> #info KWin doesn't start up in firstboot, error message: Configuration file "/root/.kde/share/config/kdedrc" not writable 19:17:23 * jlaska reading ... 19:17:43 <jlaska> an annoying error dialog during firstboot, but it doesn't appear to blocker firstboot 19:17:46 <jlaska> still, it's ugly 19:17:55 <jlaska> seems like a valid NTH 19:18:10 * jlaska looking for Blocker criteria this hits 19:18:48 <jlaska> sketchy, but possibly affects ... "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login" 19:18:56 <adamw> criterion is "# In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to 19:18:56 <adamw> create a working user account " 19:18:58 <jlaska> although, this isn't an AVC 19:19:26 <jlaska> adamw: Does this prevent running firstboot, it seems like firstboot works fine 19:19:40 <jlaska> but you get this ugly error ... does that hit the "without unintended user intervention" 19:19:43 <jlaska> ah yes 19:19:45 * jlaska answers own q 19:19:55 <jlaska> that makes it blocker I believe 19:20:14 <jlaska> proposed #agreed 683629 - AcceptedBlocker - Affects firstboot release criteria 19:20:14 <tflink> eh, I'm not as sure if firstboot works and you just have to click through the error 19:20:29 * tflink is still reading, if you have to change the file 19:20:31 <adamw> tflink: the criterion is a polish one, it's meant to mean that you don't have to deal with ugly selinxu denials 19:20:42 <adamw> it's a *bit* of a massage as the error box isn't actually an selinux avc, but it's CAUSED by one 19:20:50 <adamw> i'm okay taking it as a blocker under a stretch of that criterion 19:20:57 <adamw> but it's not exactly what the criterion intended :) 19:21:02 <jlaska> adamw: you're taking it for the AVC criteria? 19:21:17 <jlaska> it seems to be covered under a clause in the firstboot criteria you posted "without unintended user intervention" 19:21:31 <jlaska> err, no, that's meant to capture having to start firstboot manually I think 19:21:38 <jlaska> well ... ack/nak/patch ? :) 19:21:40 <adamw> well we can also take it as a stretch there :) 19:21:43 <adamw> let's ack for now 19:21:45 <tflink> +0 19:21:49 <adamw> in the interests of GETTING THE HELL OUT OF HERE 19:21:52 <jlaska> haha 19:22:02 <brunowolff> +0 for blocker 19:22:07 <brunowolff> +1 for NTH 19:22:19 <jlaska> ~ 15 bugs remaining 19:22:35 <tflink> should have been more clear: +0 blocker, +1 NTH 19:22:51 <jlaska> if this same dialog was present in GNOME, woudl the result be the same? 19:23:12 <tflink> if you just had to click though it? I think so. 19:23:22 <adamw> we have two +1 blockers and no -1 19:23:35 <tflink> if you had to switch virt terminals and modify files, I'd say its definately a blocker 19:23:40 <jlaska> I count +2 NTH, +2 blocker 19:23:55 <jlaska> anyone want to break the tie? 19:23:56 <jlaska> :) 19:24:49 <jlaska> at the very least, I think we have enough to include it for NTH then 19:24:53 <jlaska> unless someone changes or adds a vote 19:25:06 <adamw> the +1 nth doesn't imply -1 blocker 19:25:12 <adamw> so i think we can just take it as a blocker for now 19:25:15 <adamw> we can argue about it later if we have to :) 19:25:18 <tflink> yeah, that makes sense 19:25:21 <jlaska> okay 19:25:31 <tflink> since both NTH were +0 blocker, not -1 19:25:43 <brunowolff> That's correct, I wouldn't object strongly if it was marked as a blocker. I just think NTH is better. 19:25:50 <jlaska> #agreed 683629 - AcceptedBlocker - Kind-a-sort-a-almost impacts firstboot and AVC-boot criteria 19:25:53 <tflink> same here 19:26:01 <jlaska> that makes sense, thx all 19:26:16 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684214 19:26:18 <buggbot> Bug 684214: unspecified, unspecified, ---, triad, ON_QA, [abrt] libmtp-examples-1.0.5-2.fc15: op_reset_device: Process /usr/bin/mtp-detect was killed by signal 11 (SIGSEGV) 19:26:22 <jlaska> #info [abrt] libmtp-examples-1.0.5-2.fc15: op_reset_device: Process /usr/bin/mtp-detect was killed by signal 11 (SIGSEGV) 19:26:24 <adamw> we already discussed this 19:26:26 <tflink> didn't we already do this one? 19:26:32 <adamw> as it's proposed on its own as well 19:26:36 <adamw> so, move on! 19:26:39 <jlaska> yay! 19:26:42 <jlaska> #info already discussed 19:26:47 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684846 19:26:49 <buggbot> Bug 684846: unspecified, unspecified, ---, tbzatek, NEW, gnome-keyring not working in KDE 19:26:52 <jlaska> #info gnome-keyring not working in KDE 19:27:14 <tflink> hmm, no reports since 2011-03-14 19:27:22 <adamw> this hits "# Saving passwords in the desktop default keyring (if the desktop implements one), and retrieving passwords from the keyring, must work" more or less 19:27:24 <jlaska> this appears to be fixed upstream since 03-09 19:27:33 <tflink> XFCE, too? 19:27:38 <adamw> technically gnome-keyring isn't KDE's *default* keyring, but it is used in KDE and some apps will use it in preference to KDE's 19:27:44 <adamw> yeah, but xfce is a non-blocking desktop. 19:27:51 <tflink> true 19:27:54 <adamw> i'd say acceptedblocker, and ask if it's resolved.\ 19:28:04 <jlaska> proposed #agreed 684846 - AcceptedBlocker - impacts default desktop keyring criteria for KDE 19:28:13 <tflink> yeah, that works for me 19:28:14 <tflink> +1 19:28:16 <jlaska> proposed #agreed 684846 - AcceptedBlocker - impacts default desktop keyring criteria for KDE, request updated test feedback from report 19:28:41 <jlaska> #agreed 684846 - AcceptedBlocker - impacts default desktop keyring criteria for KDE, request updated test feedback from report 19:28:45 <jlaska> good'n'uff 19:28:58 <jlaska> back to the main list ... 19:28:59 <jlaska> #topic https://bugzilla.redhat.com/680542 19:29:36 <jlaska> really? 19:29:40 <jlaska> haha ... https://bugzilla.redhat.com/attachment.cgi?id=491336&action=diff 19:29:49 <adamw> yeah, that kicks ass. 19:29:54 <adamw> there is kinda a genuine problem here 19:30:02 <adamw> down to the change in anaconda so there's no stage1 any more 19:30:19 <jlaska> increasing our minimum memory requirement? 19:30:20 <tflink> what is that supposed to be? 19:30:21 <adamw> when we had a two-stage install, the first stage had really small memory requirements, and has nice code that tells you if you don't have enough memory to complete an install 19:30:30 <tflink> the ascii art, I mean 19:30:33 <adamw> now we don't really have a two-stage install any more, this isn't possible 19:30:35 <jlaska> tflink: testing in F14 showed 768 was a reliable lower limit 19:30:35 <adamw> tflink: the hot dog! 19:30:46 <tflink> oh, i see it now 19:30:50 <jlaska> adamw: oh right, good call 19:30:53 <brunowolff> Woods has done some stuff to try to reduce the minimum size back down a bit. 19:30:55 <adamw> if you don't have enough memory, you don't get a polite dialog, you get the kernel vomiting all over your screen 19:31:05 <jlaska> brunowolff: I think that work is going into rawhide though? 19:31:11 <adamw> there doesn't appear to be a practical way to do much about this, though 19:31:19 <adamw> in practice, i think the best we can do is try and get the release notes updated 19:31:21 <brunowolff> I am not sure, I haven't been following it closely. 19:31:49 <adamw> i mean, in theory the kernel could be hacked up to treat this crash specially or something, but ew. 19:32:14 <jlaska> how does this affect criteria, or do we need to make criteria adjustments? 19:32:15 <tflink> yeah, I imagine a bunch of people are going to hit this, though 19:32:27 <adamw> it doesn't really hit the criteria afaict 19:32:27 <tflink> considering how often we get that question in #fedora-qa 19:32:32 <jlaska> or do we just bring this to release notes? 19:32:35 <adamw> and given all we can do about this is a doc change, there's no point making it a blocker 19:32:39 * tflink not suggesting that we patch the kernel for it 19:32:44 <adamw> we should do what we can to get docs updated, though 19:32:46 <brunowolff> I did a live install a few days a ago to a laptop that I thought had on 512 MB. I can double check that quickly. 19:33:00 <adamw> brunowolff: live install is a bit different, i think. though it's still hairy. 19:33:08 <adamw> a 32-bit live install into 512MB may survive, i guess. 19:33:24 <jlaska> recommendations? 19:33:28 <tflink> so, more testing and documentation 19:33:31 <adamw> -1 blocker, on practical basis 19:33:31 <tflink> ? 19:33:36 <adamw> do what we can to fix up docs 19:33:48 <jlaska> anyone interested in chasing this down with the release notes? 19:33:54 <adamw> at least change the 'system requirements' in the release notes, and try and get a little paragraph in about this (though it may be hard as the docs are frozen) 19:33:59 <adamw> me 19:34:04 <adamw> i've already said i will in the bug 19:34:15 <adamw> if we can't get a paragraph into release notes, we can throw it into commonbugs. 19:34:22 <jlaska> proposed #agreed 680542 - RejectedBlocker - no criteria impacted, will follow-up with a release notes change 19:34:26 <jlaska> adamw: great, thank you 19:34:38 <tflink> ack 19:34:58 * jlaska assumes adamw is an ack 19:35:03 <jlaska> brunowolff: ? 19:35:40 <jlaska> #agreed 680542 - RejectedBlocker - no criteria impacted, will follow-up with a release notes change 19:35:53 <jlaska> #topic https://bugzilla.redhat.com/693442 19:35:57 <adamw> ack 19:36:01 <brunowolff> Yes, that laptop only has 512MB. 19:36:16 <brunowolff> A live install could potentially be a suggested work around. 19:36:30 <tflink> either way, it sounds like some testing is in order 19:36:37 <tflink> to see what we can reliably install on? 19:36:55 <jlaska> agreed 19:37:00 <adamw> this is another haigh special 19:37:11 <adamw> we need a bit more info about how weird your config needs to be before you hit it 19:37:15 <adamw> it obviously ain't affecting everyone 19:37:22 <adamw> though i do love that he's testing out network corner cases like this 19:37:33 <jlaska> sky2 driver ... hmm 19:38:25 <tflink> sky2 == marvell, no? 19:38:43 <jlaska> I don't recall 19:38:45 <tflink> nvm, not just marvell 19:38:50 <jlaska> I can ping gospo on this afterwards 19:38:52 <tflink> http://wiki.debian.org/sky2 19:39:03 <jlaska> but sounds like we need more information to decide 19:39:06 <adamw> so, punt till we have more info? 19:39:08 <jlaska> all sky2 drivers, or just this one 19:39:09 <jlaska> yeah 19:39:10 <tflink> yep 19:39:13 <brunowolff> +1 19:39:39 <jlaska> #agreed 693442 - NEEDINFO - Request and review additional information at next meeting 19:39:50 <jlaska> #action jlaska - ping gospo about sky2 bug 693442 19:39:51 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=693442 medium, unspecified, ---, kernel-maint, NEW, NETDEV WATCHDOG: em1 (sky2): transmit queue 0 timed out 19:39:59 <jlaska> #topic https://bugzilla.redhat.com/681898 19:40:14 <adamw> so we had a quick look at this for the beta, but said we'd re-evaluate for final 19:40:35 <tflink> update is pending, needs testing 19:40:56 <adamw> yeah. we should adjust the summary to make this less confusing 19:41:08 <jlaska> and this is attempting to resolve the security hole now? 19:41:25 <adamw> yes, the update _reverts_ making the directory world-writeable 19:41:42 <adamw> i'm kinda +/-0 on this one, i get the feeling we've probably shipped with similar issues before 19:41:53 <jlaska> what you don't know, can't hurt you! :) 19:41:53 <adamw> it's a fill-the-disk-up DoS 19:42:07 <adamw> so it affects traditional multi-user systems with a malicious local user...eh 19:42:22 <brunowolff> It's also fixable in an update. And DOS on live images shouldn't be a problem. 19:42:35 <adamw> if you look at the security update history for any consumer linux distro, we generally suck at not having local DoS vulns. but obviously it's good to fix them when we can. 19:42:44 <adamw> brunowolff: there's lots of ways to DoS a live image in any case :) 19:42:54 <brunowolff> I would say this is NTH. 19:42:56 <adamw> i guess i'd be +1 nth, -1 blocker on the above basis 19:43:19 <adamw> we don't have criteria here, also. 19:43:21 <jlaska> proposed #agreed 681898 - RejectedBlocker + AcceptedNTH - local DOS doesn't impact existing criteria, pending update available for testing 19:43:21 <adamw> though maybe we should. 19:43:23 <adamw> ack 19:43:30 <tflink> ack 19:43:32 <brunowolff> +1 19:43:38 <jlaska> #agreed 681898 - RejectedBlocker + AcceptedNTH - local DOS doesn't impact existing criteria, pending update available for testing 19:43:47 <jlaska> 11 left 19:43:52 * jlaska has a hard stop coming up :( 19:44:02 <jlaska> #topic https://bugzilla.redhat.com/656093 19:44:08 <jlaska> #info [abrt] nautilus-2.91.2-1.fc15: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV) 19:44:18 <jlaska> oldie 19:44:36 <tflink> wow, this is old 19:45:06 <jlaska> did this get put onto the wrong blocker list during the last release? 19:45:25 <adamw> it has an fc15 tag. so, i'd say no. 19:45:40 <tflink> yeah, abrt said it was fc15 19:45:46 <jlaska> yeah 19:45:46 <adamw> and it's me, so obviously it can't be wrong. =) 19:45:49 <tflink> rawhide at the time? 19:45:51 <adamw> i think this was right after i jumped to rawhide. 19:46:01 <tflink> adamw: we would never doubt you :) 19:46:01 <jlaska> adamw: Cranes welcomes you to his domain! 19:46:21 <adamw> no-one's hit this for a while and we have an auto-mount test in the desktop criteria, so people should have been testing this. 19:46:26 <adamw> i'm happy with closing it. 19:46:30 <tflink> same here 19:46:46 <jlaska> proposed #agreed 656093 - CLOSED NEXTRELEASE - Old bug affecting F14, no longer occurs in F15 19:46:50 <jlaska> or ERRATA 19:46:54 <jlaska> whichever is appropriate 19:47:21 <adamw> it was never an f14 bug 19:47:23 <adamw> but otherwise, yes 19:47:24 <brunowolff> I suggest not mentioning F14. 19:47:32 <adamw> i only ever hit this with f15 packages 19:47:43 <jlaska> proposed #agreed 656093 - CLOSED NEXTRELEASE - No longer occurs in F15 19:47:46 <jlaska> proposed #agreed 656093 - CLOSED ERRATA - No longer occurs in F15 19:47:47 <brunowolff> +1 19:47:51 <adamw> i did closed errata, but yes :) 19:47:52 <tflink> +1 19:47:55 <jlaska> #agreed 656093 - CLOSED ERRATA - No longer occurs in F15 19:48:06 <jlaska> #topic https://bugzilla.redhat.com/697008 19:48:10 <jlaska> #info Include the latest ntfs-3g package in the final F-15 compose 19:48:12 <adamw> -1, doesn't hit any criteria. 19:48:30 <adamw> i think spot thinks it needs to be a blocker to get in, but it doesn't. 19:48:45 <adamw> also -1 nth, as it's not something we should tinker with late in cycle unless we have a clear blocker to fix. 19:48:57 <jlaska> adamw: is he raising it here since it affects anaconda? 19:48:58 <brunowolff> +1 to what Adam said. 19:49:13 <tflink> yeah, +1 here too 19:49:14 <jlaska> meaning, even if we pull this in prior to freeze, it could backfire 19:49:23 * jlaska +1 also 19:49:54 <jlaska> #agreed 697008 - RejectedBlocker + RejectedNTH - does not impact any release criteria 19:49:56 <tflink> well, what bugs were fixed if this is meant as a fix for anaconda? 19:50:13 <tflink> ack, still 19:50:18 <jlaska> tflink: no, I believe since it replaces ntfsprogs (which anaconda uses), there is risk 19:50:27 <jlaska> if I understood it right 19:50:36 <tflink> if we missed something, it can be raised in the bug and we can re-review 19:50:42 <jlaska> yup, sure 19:50:57 <jlaska> #topic https://bugzilla.redhat.com/696240 19:51:05 <jlaska> #info report is filing Fedora 15 installer bugs against rawhide (not Fedora 15) 19:51:43 <jlaska> this almost hits the alpha criteria "The installer must be able to report failures to Bugzilla, with appropriate information included" 19:52:01 <jlaska> bugs reported by the 'report' tool are being reported against rawhide, not 15 19:52:05 <jlaska> I know this affects anaconda 19:52:14 <jlaska> and probably setroubleshooter as well 19:52:29 <adamw> sorry, starbucks wifi died 19:52:30 <adamw> i guess we agreed -1 to both on ntfs bug? 19:52:35 <jlaska> adamw: yeah 19:52:48 <jlaska> adamw: we discussed spots intentions for marking it as a blocker, andwill move that to the bz 19:52:57 <adamw> but it'd be fine for him to land it before final freeze hits. 19:53:07 <jlaska> adamw: I'd be fine as long as we test it in a private boot.iso first 19:53:14 <jlaska> since it replaces ntfsprogs which anaconda uses 19:53:19 <jlaska> (at least I thought it did) 19:54:12 <adamw> it's fine before freeze for me... 19:54:12 <jlaska> so this bug deals with autofiling anaconda (and possibly setroubleshooter) bugs against rawhide, when they should be against version=15 in bugzilla 19:54:36 <jlaska> I think this hits alpha criteria ... "The installer must be able to report failures to Bugzilla, with appropriate information included" 19:54:41 <jlaska> and proposed it for Final 19:54:56 <adamw> -1, as it can report them 19:55:03 <adamw> they wind up in the wrong place, but we could fix that 19:55:05 <jlaska> "appropriate information included" 19:55:11 <adamw> hmm, arguable =) 19:55:16 <brunowolff> How easy is it to fix the bugs after the fact? 19:55:17 <jlaska> and all bugs would be filed against rawhide 19:55:18 <adamw> iswym, though 19:55:25 <adamw> brunowolff: we could gin up a query to do it, i think 19:55:26 <jlaska> brunowolff: easy to fix, pita to detect 19:55:37 <adamw> but yeah, not super easy 19:55:44 <adamw> i'll change to a +/-0 19:55:50 <adamw> definitely NTH 19:55:54 <jlaska> we'll be searching attachments for anaconda-15.* 19:56:09 <jlaska> I can handle NTH, since this isn't resolvable in an update 19:56:11 <adamw> the practical impact wouldn't be huge, remember 19:56:19 <adamw> since we wouldn't be able to *fix* installer bugs in 15 anyway 19:56:20 <jlaska> right, just cursing from clumens 19:56:24 <adamw> the fixes would wind up in f16 anyway 19:56:30 <jlaska> hmm, good point 19:56:46 <adamw> but yeah, i',m +/-0 blocker, +1 nth 19:57:01 <adamw> installer team have an opinion? 19:57:06 <jlaska> proposed #agreed 696240 - AcceptedNTH - arguably impacts Alpha criteria, will accept tested fix if available 19:57:20 <brunowolff> +1 for the proposal 19:57:22 <tflink> ack 19:57:23 <adamw> ack 19:57:36 <jlaska> #agreed 696240 - RejectedBlocker + AcceptedNTH - arguably impacts Alpha criteria, will accept tested fix if available 19:57:39 * jlaska clarifies 19:57:42 <clumens> i'd certainly prefer to see it fixed 19:58:04 <clumens> but in my bug searching, i don't usually look at the Version: field so much as the "anaconda $version exception report" info 19:58:15 <jlaska> there we have it 19:58:19 <jlaska> #topic https://bugzilla.redhat.com/694256 19:58:25 <jlaska> #info SELinux is preventing /sbin/iscsid from 'create' accesses on the directory iscsi. 19:59:03 <jlaska> AcceptedBlocker and appears to be fixed in newer policy 19:59:29 <adamw> it's not marked acceptedblocker, but yeah, +1 19:59:34 <brunowolff> +1 19:59:43 <jlaska> adamw: sorry, that was my proposal 19:59:54 <jlaska> proposed #agreed 694256 - AcceptedBlocker - impacts iSCSI and AVC-boot criteria - fix available for testing 20:00:04 <brunowolff> +1 20:00:12 <tflink> what criterion does this impact? 20:00:30 <adamw> final iSCSI criterion i believe 20:00:41 <jlaska> "The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices " 20:00:44 <jlaska> #info The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices 20:00:47 <adamw> "So during installation, I set up my /home on an iscsi device. After the 20:00:47 <adamw> installation, /home was never mounted (and systemd is actually stuck with 20:00:47 <adamw> activating RAID/LVM/etc during bootup so I had to remove /home from fstab). 20:00:47 <adamw> " 20:00:55 <tflink> is this during install or creating a target? 20:00:58 <adamw> later in the criteria we specify that installed systems must actually work 20:01:08 <jlaska> tflink: during boot 20:01:27 <tflink> ok, missed that 20:01:29 <tflink> ack 20:01:43 <jlaska> depends if we consider this "most cases" ... In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login 20:01:58 <jlaska> #agreed 694256 - AcceptedBlocker - impacts iSCSI and AVC-boot criteria - fix available for testing 20:02:35 <jlaska> tflink or brunowolff: would one of you mind picking up the remaining 7 proposed blockers? I have to drop off for an hour. 20:02:49 <adamw> i'm nearly done too, out of battery :/ 20:02:50 <jlaska> The next bug is system-config-services on https://fedoraproject.org/wiki/Current_Release_Blockers 20:02:54 <adamw> 14.8% remaining 20:02:58 <adamw> +1 on 682001, hits "# 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 " and this is an important app 20:02:59 <tflink> sure 20:03:04 <adamw> #topic +1 on 682001, hits "# 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 " and this is an important app 20:03:06 <adamw> grrr! 20:03:08 <adamw> #undo 20:03:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x32800c10> 20:03:11 <jlaska> #chair tflink 20:03:11 <zodbot> Current chairs: adamw jlaska tflink 20:03:12 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682001 20:03:14 <buggbot> Bug 682001: unspecified, unspecified, ---, nphilipp, ASSIGNED, s-c-services - all read and disabled 20:03:18 <adamw> +1 from me 20:03:30 <jlaska> thanks all ... I'll be back and will handle the minutes later one 20:04:12 <tflink> what criterion? 20:05:05 <adamw> see my comemnt a few minutes back 20:05:07 <adamw> +1 on 682001, hits "# 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 " and this is an important app 20:05:12 <tflink> nvm, I understand more now 20:05:45 <brunowolff> Yeah +1 blocker. This seems to be a high risk bug then. 20:05:58 <tflink> proposed #agreed 682001 - AcceptedBlocker - impacts basic usability 20:06:01 <adamw> ack 20:06:05 <brunowolff> +1 20:06:10 <tflink> #agreed 682001 - AcceptedBlocker - impacts basic usability 20:06:42 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=692230 20:06:43 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=692230 20:06:44 <buggbot> Bug 692230: unspecified, unspecified, ---, lpoetter, NEW, Non-root iSCSI volumes are not mounted on boot 20:06:46 <buggbot> Bug 692230: unspecified, unspecified, ---, lpoetter, NEW, Non-root iSCSI volumes are not mounted on boot 20:06:50 <tflink> #undo 20:06:50 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1f240290> 20:06:51 <adamw> hehe 20:06:53 <adamw> this one seems a bit unclear 20:07:28 <adamw> pity jlaska is gone 20:07:35 <adamw> not sure if it hits critical partitions on iscsi 20:07:43 <adamw> the tested case is non-critical ones 20:07:52 <adamw> but i'm not sure that's the only possible case... 20:08:00 <adamw> anyone have a good undetstanding of this? 20:08:07 <adamw> clumens: ^^ 20:08:39 <adamw> comment #11 looks core 20:09:22 <adamw> i'm kinda tempted to ask for a clearer evaluation of impact from jlaska and clumens and punt this one? 20:09:29 <tflink> yeah, same here 20:09:55 <tflink> proposed #agreed - 692230 - need more information, will revisit next week 20:10:00 <brunowolff> +1 20:10:01 <tflink> ack/nack/patch? 20:10:22 <adamw> ack 20:10:33 <tflink> #agreed - 692230 - need more information, will revisit next week 20:10:41 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=695407 20:10:43 <buggbot> Bug 695407: unspecified, unspecified, ---, lpoetter, NEW, Must not continue boot until pass-phrase has been entered 20:11:20 <tflink> is this another strain of the luks bug we saw ~ alpha time? 20:11:28 <brunowolff> I don't think so. 20:11:40 <adamw> kinda depends exactly how badly things get broken, but i imagine this screws things up quite bad, as services which try to start with the /home partition unaccessible are likely to have trouble... 20:11:44 <brunowolff> I think the issue is that the reporter thinks the timeout is a bug. 20:11:47 <adamw> no, seems like something new 20:12:00 <brunowolff> I know I had issues when the timeout was around 30 seconds. 20:12:09 <brunowolff> I think it is longer now. 20:12:14 <adamw> yeah...i think there's a timeout because the encrypted partition may not be critical 20:12:28 <adamw> so...again i'm kinda unclear here 20:12:36 <adamw> also i have to leave :/ battery nearly dead 20:12:37 <tflink> same here 20:12:44 <brunowolff> Arguably there shouldn't be a timeout for some mount points. 20:12:53 <adamw> can you guys finish off? and punt anything that's not clear...jlaska and i can come back through teh bugs later and chip in then 20:13:01 <brunowolff> I don't see this as either a blocker or NTH though. 20:13:04 <tflink> OK 20:13:04 <adamw> brunowolff: if that's rpactical, yeah 20:13:23 <adamw> +1 brunowolff 20:13:25 <brunowolff> I wouldn't be surprised to see it closed WONTFIX. 20:13:30 <tflink> not with our current criteria 20:13:49 <clumens> sorry - wasn't paying attention. i think we have the makings of a plan on that iscsi thing, but certainly nothing completely set yet. 20:14:10 <adamw> propose #agreed having a timeout is not a blocker or NTH issue, though better behaviour is possible 20:14:12 <tflink> proposed #agreed - 695407 - rejected blocker, rejected NTH - does not hit criteria 20:14:16 <adamw> ack to either 20:14:18 <brunowolff> +1 20:14:29 <tflink> ack 20:14:45 <tflink> #agreed - 695407 - rejected blocker, rejected NTH - does not hit criteria but better behavior would be preferred 20:15:01 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=696320 20:15:02 <buggbot> Bug 696320: unspecified, unspecified, ---, lpoetter, NEW, After text-mode iSCSI install and boot, firstboot-text and getty are both running - unable to login on console 20:16:37 <brunowolff> This seems like a blocker. 20:16:52 <tflink> yeah, looking for criteria that it hits 20:17:01 <tflink> since this is firstboot, not install 20:17:07 * tflink doesn't think that they're the same 20:17:14 <tflink> or grouped the same, rather 20:18:03 <tflink> proposed #agreed - 696320 - AcceptedBlocker - impacts installation on iSCSI 20:18:13 <tflink> I'm going to go with "The installer must be able to complete an installation using IDE, SATA, SCSI and iSCSI storage devices" 20:18:20 <brunowolff> +1 20:18:38 <tflink> +1 20:19:09 <tflink> #agreed - 696320 - AcceptedBlocker - impacts installation on iSCSI 20:19:25 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=644739 20:19:26 <buggbot> Bug 644739: medium, low, ---, jhorak, ON_QA, Thunderbird does not handle user defaults in applications 20:20:29 <tflink> I'm not sure that this hits any release criteria 20:20:45 <brunowolff> I am not sure about blocker, but I think it's a NTH. 20:21:19 <tflink> yeah, it sounds like this is an issue in F14, too 20:21:26 <brunowolff> The app isn't complete broken, so I don't think it hits the all apps must work. 20:21:46 <tflink> an annoyance, sure but not a blocker 20:22:11 <brunowolff> But the effect is annoying enough that I'd risk a fix during the freeze. 20:22:43 <tflink> proposed #agreed - 644739 - RejectedBlocker, AcceptedNTH - does not keep anything from functioning but is a polish issue and an annoyance 20:22:50 <brunowolff> +1 20:23:05 <tflink> #info does not hit release criteria but a polish issue 20:23:07 <tflink> +1 20:23:14 <tflink> #agreed - 644739 - RejectedBlocker, AcceptedNTH - does not keep anything from functioning but is a polish issue and an annoyance 20:23:28 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678656 20:23:30 <buggbot> Bug 678656: unspecified, unspecified, ---, rdieter, ON_QA, Shouldn't use user's defaults.list 20:24:10 <tflink> what exactly is the effect of this bug? 20:24:24 <brunowolff> I don't really understand this one either. 20:24:44 <brunowolff> We probably need to ask for an impact assessment and review it again next week. 20:24:51 <tflink> yep 20:25:20 <tflink> proposed #agreed - 678656 - not clear on the impact of this bug, need more info and will revisit next week 20:25:29 <brunowolff> +1 20:25:33 <tflink> +1 20:25:53 <tflink> #action tflink to update 678656 to ask for more info 20:26:01 <tflink> #agreed - 678656 - not clear on the impact of this bug, need more info and will revisit next week 20:26:18 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=661395 20:26:20 <buggbot> Bug 661395: medium, low, ---, peter.hutterer, ASSIGNED, some keyboard options/layouts (set via system-config-keyboard) make gdm/kdm input non-functional 20:26:26 <tflink> whee! last proposed blocker! 20:26:40 <tflink> wait, we've already done this one 20:26:51 <tflink> since it was kde-blocker and final-blocer 20:26:54 <tflink> blocker 20:27:14 <tflink> #undo 20:27:14 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x27e0bb50> 20:27:25 <brunowolff> It did look pretty familiar. 20:27:33 <brunowolff> I was going to ask if it was a clone. 20:27:48 <tflink> nope, just a side-effect of how the wiki page is done 20:28:03 <brunowolff> So were done for today? 20:28:07 <tflink> feel like going through the proposed NTH? 20:28:24 <brunowolff> I can go on a bit. 20:28:36 <tflink> eh, lets just get through them 20:29:02 <tflink> #info end of proposed blockers 20:29:07 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694765 20:29:09 <buggbot> Bug 694765: unspecified, unspecified, ---, dcbw, NEW, Can't connect to WPA2 Enterprise networks 20:29:31 <tflink> sounds like this has been fixed or we need more info 20:29:50 <tflink> what version of NM was in beta TC1? 20:30:00 <mclasen> I think there is still something to fix there 20:30:07 <mclasen> what I described was more a workaround 20:30:38 <tflink> mclasen: you can still use the NM connection gui, though right? 20:30:49 <brunowolff> I think this should be NTH as it would be annoying for live images in some environments. 20:31:18 <tflink> do you remember how we handled the hidden wireless network issue from last week? 20:32:03 <brunowolff> Does this also affect installs? 20:32:31 <brunowolff> Hidden wireless got at least NTH, but I don't remember if it got blocker. 20:32:42 <brunowolff> This is a very similar situation. 20:32:43 <tflink> proposed #agreed - 694765 - AcceptedNTH since it is an annoyance and should work 20:32:52 <brunowolff> +1 20:32:55 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=691139 20:32:57 <buggbot> Bug 691139: unspecified, unspecified, ---, dcbw, ON_QA, NetworkManager 0.8.997 doesn't connect to hidden wireless network 20:33:01 <tflink> we ended up making it NTH 20:33:04 <tflink> +1 20:33:21 <tflink> #info an annoyance and similar to 691139 - NTH 20:33:30 <tflink> #agreed - 694765 - AcceptedNTH since it is an annoyance and should work 20:33:43 <brunowolff> That was for beta, so at least NTH. 20:33:52 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=693302 20:33:54 <buggbot> Bug 693302: medium, medium, ---, rvykydal, NEW, static network kickstart configuration having --device specified with MAC tracebacks (KeyError: '00:0c:29:09:85:fa') 20:33:57 <tflink> true 20:34:47 <tflink> I'd say at least NTH for this one 20:35:09 <brunowolff> Yeah. 20:35:13 <tflink> I wonder if we have any test cases for this 20:35:25 <brunowolff> It seems like a rare use case for a blocker. 20:35:48 <tflink> yeah, it could be under "The installer must be able to use the HTTP, FTP and NFS remote package source options" 20:35:55 <tflink> but like you said, I don't think this is very common 20:36:46 <tflink> proposed #accepted - 693302 - AcceptedNTH, close to hitting release criterion but seems to be an edge case 20:36:53 <brunowolff> +1 20:36:56 <tflink> +1 20:37:19 <tflink> #info close to hitting alpha release criteria - "The installer must be able to use the HTTP, FTP and NFS remote package source options" but doesn't seem to be common 20:37:26 <tflink> #accepted - 693302 - AcceptedNTH, close to hitting release criterion but seems to be an edge case 20:37:44 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662800 20:37:46 <buggbot> Bug 662800: medium, low, ---, andreas.bierfert, ASSIGNED, geolocation plugin is linked against both gtk2 and gtk3 20:38:19 <jsmith-brb> Hmmmn... not sure which criteria that might hit 20:38:19 <tflink> is geolocation a default package? 20:38:50 <brunowolff> I am not sure of the impact of this one. 20:39:05 <jsmith> Reading the ticket, it doesn't seem to be anything that would qualify as blocker 20:39:09 <tflink> it sounds like the plugin would be unreliable 20:39:14 <tflink> jsmith: we're on NTH now 20:40:01 <tflink> I think that this could be fixed before final, no? 20:40:19 * tflink is still a little unclear on how the freeze process works between beta release and final 20:40:32 <jsmith> tflink: Sorry for the noise :-/ 20:40:34 <brunowolff> People are supposed to use restraint. 20:40:42 <tflink> jsmith: no worries :) 20:41:03 <brunowolff> jsmith: pleas keep chiming in. We're down to just 3 including you now. 20:41:35 <jsmith> brunowolff: Will do, as I'm able -- still trying to crank out a press release for the beta 20:41:35 <tflink> proposed #accepted - 662800 - RejectedNTH - tested fix would be accepted before freeze 20:41:55 <brunowolff> There is a final freeze when RCs start getting produced. 20:42:06 <brunowolff> +1 20:42:22 <tflink> +1 20:42:30 <tflink> #accepted - 662800 - RejectedNTH - tested fix would be accepted before freeze 20:42:53 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683265 20:42:55 <buggbot> Bug 683265: unspecified, unspecified, ---, harald, ASSIGNED, u3 device on Sandisk Cruzer 8G USB Drive hangs Fedora 15 Alpha boot 20:43:51 <tflink> I'm not sure about this one 20:44:10 <tflink> it seems to happen only if you create liveUSB using dd and would require a dracut fix 20:44:52 <tflink> but IIRC, there are other things that are requesting dracut changes ATM 20:45:02 <brunowolff> I haven't tested using dd of live images for a while. 20:45:06 <tflink> can't remember if they were fixed for beta or not 20:45:38 <tflink> are you reading this the same way I am? That it only affects usb live images created with dd? 20:45:56 <tflink> I haven't seen this in any of the liveUSB images that I've created with the liveusb-creator recently 20:45:58 <brunowolff> I am not sure. 20:46:33 <brunowolff> I am also wondering if it is hardware dependent, since there is a mention of U3 (is that a USB 3.0 deveice?). 20:46:48 <tflink> proposed #agreed - 683265 - request for more info on impact and cause. Will revisit next week 20:46:53 <tflink> good point 20:46:56 <brunowolff> +1 20:47:11 <tflink> #info need more info on cause, whether or not this is related to USB 3.0 HW 20:47:14 <tflink> +1 20:47:21 <brunowolff> I don't know if being able to dd a live image is a release criteria. 20:47:23 <tflink> #agreed - 683265 - request for more info on impact and cause. Will revisit next week 20:47:45 <tflink> #action tflink to update 683265 with request for more information 20:48:01 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662791 20:48:02 <buggbot> Bug 662791: medium, low, ---, pbrobinson, NEW, links against both gtk2 and gtk3 20:48:12 <tflink> another "links against gtk2 and gtk3" bug 20:48:37 <jsmith> Yeah... most likely because of libchamplain 20:48:47 <jsmith> +1 to whatever we did to the last one :-) 20:49:04 * tflink looks 20:49:35 <brunowolff> The other one didn't crash, it was just unreliable. 20:50:08 <tflink> is this part of the default install? 20:50:10 <brunowolff> Is this package installed by default? 20:50:59 <tflink> not on the F15 desktop I installed yesterday 20:51:19 <brunowolff> I don't seem to have it installed, and I have lots of stuff installed. But if it is recent, I wouldn't necessarily have grabbed it, since I use yum to do upgrades. 20:51:47 <jsmith> No, I don't think it's part of a default installation 20:51:48 <brunowolff> Then I think this is neither NTH nor blocker. 20:52:00 <tflink> proposed #agreed - 662791 - RejectedNTH: does not impact release criteria and not installed by default. Tested fix will be accepted before freeze if ready 20:52:03 <tflink> same here 20:52:05 <tflink> +1 20:52:07 <brunowolff> +1 20:52:16 <tflink> #agreed - 662791 - RejectedNTH: does not impact release criteria and not installed by default. Tested fix will be accepted before freeze if ready 20:52:32 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662801 20:52:34 <buggbot> Bug 662801: medium, low, ---, triad, NEW, links against both gtk2 and gtk3 20:52:36 * jlaska back 20:52:47 <jsmith> Yay, another... 20:52:52 <jsmith> jlaska: Welcome back :-) 20:52:57 <tflink> yeah, I think this is going to be the same thing 20:53:07 <jsmith> ACK 20:53:07 * jlaska catches up 20:53:08 <tflink> jlaska: welcome, welcome 20:53:30 <tflink> more non-default programs that are linking against gtk2 and gtk3 20:53:41 <brunowolff> I have that one installed, but don't know if it is by default. 20:53:51 <mclasen> its not 20:54:31 <tflink> I'd lean more towards -1 NTH, then. a tested fix would be accepted, though 20:54:36 <brunowolff> That makes it easy, another neither NTH nor blocker, since it isn't in the default install. 20:55:16 <tflink> proposed #agreed - 662801 - RejectedNTH: not a default program and can be fixed with update. Tested fix will be accepted if ready before freeze 20:55:21 <brunowolff> +1 20:55:25 <tflink> +1 20:55:33 <jlaska> +1 20:55:43 <tflink> #agreed - 662801 - RejectedNTH: not a default program and can be fixed with update. Tested fix will be accepted if ready before freeze 20:55:58 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=653709 20:56:00 <buggbot> Bug 653709: high, low, ---, bnocera, NEW, Gtk-ERROR **: GTK+ 3 symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported 20:56:20 <tflink> sounds like a fix is ready for testing on this one 20:56:30 <jlaska> move this to ON_QA? 20:56:48 <tflink> maybe, the message was for today, not sure about status of update 20:57:06 <tflink> and the impact is really low (noise in .xsession-errors) 20:57:29 <brunowolff> If the only effect is the error log, I don't see this being either an NTH or a blocker. 20:57:51 <tflink> yep, checking update status 20:58:07 <tflink> wait, this is pending stable but is failing upgradepath 20:58:38 <brunowolff> Is there an F16 build for it? 20:58:46 <jlaska> not yet 20:58:48 <tflink> I don't see one 20:58:53 <jlaska> there is, but it's older 20:58:59 <jlaska> Latest package: gnome-user-share-2.91.6-1.fc16 20:59:00 <jlaska> Error: Requested package must be less than or equal to the latest package 20:59:16 <brunowolff> I got a sort of spurious error for a package that didn't have an F16 build, since the F16 version was the old version. 20:59:27 <tflink> ok, sounds like an autoqa issue on that one 20:59:50 <tflink> but I'd say -1 NTH, -1 blocker. not serious enough, fix available for testing 21:00:01 <jsmith> tflink: ACK 21:00:09 <brunowolff> +1 21:00:35 <jlaska> I'm unclear on the impact still, if it's just .xsession noise, or something else 21:00:36 <tflink> proposed #agreed - 653709 - RejectedNTH: only adds noise to .xsession-errors, not serious. Fix available for testing and could use karma 21:00:39 <jlaska> ack for now 21:01:05 <tflink> #agreed - 653709 - RejectedNTH: only adds noise to .xsession-errors, not serious. Fix available for testing and could use karma. Can revisit if it turns out to be more serious 21:01:26 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662794 21:01:28 <buggbot> Bug 662794: medium, low, ---, rpm, NEW, linked against both gtk2 and gtk3 21:01:39 <mclasen> jlaska: we are blocking f15 updates that cause problems for rawhide upgrades ? 21:01:44 <mclasen> that seems backwards to me 21:01:51 <jlaska> mclasen: no, not at all ... it's just advisory at this point 21:02:11 <tflink> I'm wondering if that is something to look into on our part 21:02:14 <jlaska> mclasen: but we do need to figure out how to make this less painful for maintainers to properly upgrade 21:02:21 <mclasen> anyway, I've asked tbzatek to go over all gnome packages and make sure we build all f15 things for rawhide 21:02:23 * tflink makes note to look at it later 21:02:24 <mclasen> long overdue... 21:02:49 <jlaska> tflink: yeah, it's partly something we can do in autoqa (including updates-testing from other repos), and partly a policy issue I think 21:03:01 <jlaska> anyway, off topic 21:03:06 <jlaska> mclasen: thanks for talking to tbzatek 21:03:22 <brunowolff> More of the same. Is gnomeradio in the default install? 21:03:23 <tflink> this sounds like another non-default package that is crashing because it's linked to gtk2 and gtk3 21:04:17 <mclasen> gnomeradio is not in the default install 21:04:24 <tflink> proposed #agreed - 662794 - RejectedNTH: Not installed by default and can be fixed by an update post-release. Tested fix would be accepted before freeze 21:04:25 * jlaska thankful notting filed these issues, but I agree, they don't meet existing criteria 21:04:28 <brunowolff> +1 21:04:29 <jlaska> ack 21:04:30 <tflink> ack/nack/patch? 21:04:35 <jsmith> ACK 21:04:44 <tflink> #agreed - 662794 - RejectedNTH: Not installed by default and can be fixed by an update post-release. Tested fix would be accepted before freeze 21:04:54 <tflink> 3 more 21:04:58 <jlaska> yay! 21:05:05 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=681582 21:05:07 <buggbot> Bug 681582: medium, unspecified, ---, lvm-team, NEW, lvm-monitor of snapshot hangs at reboot/shutdown 21:05:13 <jlaska> "I think this qualifies as a NTH for Fedora 15 Final. We have no existing 21:05:16 <jlaska> criteria that cover the use of LVM snapshots." 21:05:17 <tflink> I'm +1 NTH on this one 21:05:19 <jsmith> +1 to NTH 21:05:40 <jlaska> Clyde is a great install tester for us, and it's a valid bug ... we just don't have criteria for snapshots 21:06:00 <tflink> proposed #agreed - 681582 - AcceptedNTH, this is a pain and could cause users to think that their system is broken 21:06:02 <brunowolff> +1 to NTH 21:06:05 <jlaska> and for Fedora, snapshots seem rather corner-case-like (imo) 21:06:08 <jlaska> tflink: ack 21:06:19 <tflink> ack/nack/patch? 21:06:34 <tflink> #agreed - 681582 - AcceptedNTH, this is a pain and could cause users to think that their system is broken 21:06:44 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694928 21:06:46 <buggbot> Bug 694928: medium, unspecified, ---, dmalcolm, ON_QA, "import decimal" fails in Turkish locale with "KeyError: 'ROUND_CEiLiNG'" 21:06:54 <jlaska> this came up during the recent go/no_go meeting 21:06:55 <jlaska> "Proposing as nice-to-have for final (it doesn't quite hit blocker criteria, 21:06:58 <jlaska> - adamw 21:07:01 <jlaska> IMO), we will document for Beta. The fix will certainly get in for final anyway 21:07:04 <jlaska> if it's submitted now." 21:07:40 <tflink> cool, it looks like there is a fix in 21:07:56 <dmalcolm> fwiw there might be other sw using the decimal module, so it might break other things beyond anaconda 21:08:13 * jsmith is torn on this one 21:08:25 <jlaska> jsmith: torn on blocker or nth? 21:08:50 * dmalcolm suspects it was broken in F14 also; checking now 21:09:04 <jsmith> jlaska: On blocker -- it's definitely NTH 21:09:24 <jlaska> jsmith: if we want it to be blocker, I believe we need updated/new criteria 21:09:29 <jsmith> jlaska: I didn't feel strongly that it was a Beta blocker, but for the final, I hate to see Anaconda crashes 21:09:30 <tflink> proposed #agreed - 694928 - AcceptedNTH: causes problems in anaconda and possibly other sw but doesn't clearly hit any release criteria. Fix has been submitted and needs testing 21:09:32 <jsmith> I know... 21:09:38 <dmalcolm> looks like the bug is still present in F14's python, fwiw 21:09:38 <tflink> sorry, that might have been a bit early 21:09:52 <jsmith> No worries... 21:10:00 <jsmith> OK, +1 for NTH 21:10:23 <tflink> ack/nack/patch? 21:10:26 <dmalcolm> 'BEEFY_MiRACLE' 21:10:27 <brunowolff> +1 21:10:29 <jlaska> nb provided some good data in the go/no_go meeting for how far along we are translated in turkish 21:10:32 <jlaska> +1 21:10:48 <tflink> #agreed - 694928 - AcceptedNTH: causes problems in anaconda and possibly other sw but doesn't clearly hit any release criteria. Fix has been submitted and needs testing 21:10:54 * jlaska still trying to figure out how to incorporate transifex data into lang issues 21:11:00 * tflink assumes 'BEEFY_MiRACLE' == +1 21:11:13 <jlaska> heh 21:11:22 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=662788 21:11:24 <buggbot> Bug 662788: medium, low, ---, mclasen, NEW, linked against both gtk2 and gtk3 21:11:29 <tflink> woo! last proposed NTH 21:12:10 <jsmith> Not sure it's in the default install (even though seahorse might be) 21:12:19 <tflink> hmm, this one might be more default but is another "crash because linked to gtk2 and gtk3" 21:12:39 <tflink> I don't have seahorse-preferences but I do have seahorse and seahorse-daemon 21:13:27 <jsmith> +1 to our favorite treatment 21:13:38 <tflink> yeah, I'm leaning that way, too 21:14:24 <tflink> proposed #agreed - 662788 - RejectedNTH: seahorse-plugins is not a default package and this can be fixed with an update. Tested fix would be accepted before freeze. 21:14:29 <tflink> ack/nack/patch? 21:14:32 <jsmith> ACK 21:14:32 <jlaska> It doesn't appear to be installed in the live image ... not that answers the @default install q 21:14:42 <jlaska> ack 21:14:48 <brunowolff> Are you sure it's not in the default install? 21:14:58 <tflink> I don't have it installed 21:15:12 <tflink> and this is a pretty-fresh F15 default desktop 21:15:15 <brunowolff> OK, then +1 for the same as the others. 21:15:25 <tflink> I have seahorse but not the exact package that is mentioned in the bug 21:15:48 <tflink> and the gui starts up without crashing (not sure how to start the daemon, though) 21:16:15 <tflink> #agreed - 662788 - RejectedNTH: seahorse-plugins is not a default package and this can be fixed with an update. Tested fix would be accepted before freze 21:16:25 <tflink> cool, that would be all of the proposed NTH 21:16:30 <jsmith> w00! 21:16:33 <jlaska> awesome, nice work everyone! 21:16:36 <jlaska> this was a killer meeting 21:16:40 <jsmith> No kidding... 21:16:44 <jlaska> the first of the final blockers is always the worst 21:16:46 <tflink> whee! 4 hours! 21:16:46 <brunowolff> And I thought I was going to miss most of the meeting being a 1/2 hour late! 21:16:53 <jlaska> brunowolff: hah! 21:16:56 <tflink> err, b+ hours 21:17:01 <tflink> s/b/4 21:17:11 <jlaska> I'd like to propose open-discussion for the mailing list 21:17:15 <jlaska> :) 21:17:26 <tflink> #topic open discussion - any other issues? 21:17:35 <brunowolff> I won't be getting Fridays off again for a while, so my participation will be more limited for the upcoming blocker meetings. 21:17:37 <tflink> or you can take over again :) 21:17:56 <brunowolff> I'll at least try to be available for questions for any stuff I can fix. 21:18:04 <jlaska> brunowolff: thanks for the heads up, and many thanks for helping us through this one 21:18:08 * jsmith doesn't have anything else to add, besides a huge "thank you" for everyone involved 21:19:04 <tflink> well, if there aren't any more topics, I'll set the fuse for 1 minute 21:19:05 <jlaska> nothing here ... thanks all, I'll send minutes tothe list 21:19:30 <jlaska> tflink: thanks for driving :) 21:19:39 <tflink> jlaska: np, all sorts of fun 21:19:44 <jlaska> heh 21:19:46 <tflink> I'm not as good at it as you are, though 21:20:08 <jlaska> flattery will get you everywhere! :D 21:20:26 <jlaska> okay, let's end this puppy 21:20:37 <tflink> #endmeeting