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