17:02:42 <tflink> #startmeeting f18final-blocker-review-6
17:02:42 <zodbot> Meeting started Wed Dec 19 17:02:42 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:42 <tflink> #meetingname f18final-blocker-review-6
17:02:42 <tflink> #topic Roll Call
17:02:42 <zodbot> The meeting name has been set to 'f18final-blocker-review-6'
17:04:53 * jreznik is here
17:06:08 * nirik is lurking around.
17:06:20 * satellit listening
17:09:35 <tflink> adamw: around?
17:10:57 * adamw is here
17:11:00 <adamw> sorruy
17:11:02 <adamw> writing a mail
17:11:07 <tflink> not acceptable
17:12:07 <tflink> would be nice to have another person or two but I guess we have enough to get started
17:12:14 <tflink> #chair adamw
17:12:14 <zodbot> Current chairs: adamw tflink
17:12:21 <tflink> #topic Introduction
17:12:36 <tflink> Why are we here?
17:12:36 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:12:43 <tflink> #info We'll be following the process outlined at:
17:12:43 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:12:49 <tflink> #info The bugs up for review today are available at:
17:12:49 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:12:55 <tflink> #info The criteria for release blocking bugs can be found at:
17:12:55 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:12:56 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:12:56 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:13:36 <tflink> #info the current number of blocker and NTH bugs is:
17:13:46 <tflink> #info 17 Proposed Blockers
17:13:46 <tflink> #info 18 Accepted Blockers
17:13:46 <tflink> #info 31 Proposed NTH
17:13:46 <tflink> #info 23 Accepted NTH
17:14:05 * nirik sighs. pretty grim.
17:14:24 <tflink> there are several proposed blockers that are probably easy rejects
17:15:04 <tflink> #info the number of bugs that are 'ready for discussion' today are:
17:15:10 <tflink> #info 8 Proposed Blockers
17:15:10 <tflink> #info 23 Proposed NTH
17:15:16 * kparal lurks
17:15:28 <tflink> kparal: lurking? slacker :-P
17:15:42 <kparal> I have one hour, then I have to leave
17:15:46 * adamw looks sadly at snow cascading down outside window
17:15:54 * adamw considers leaving in an hour too :P
17:16:06 * nirik also has snow falling here.
17:16:14 <tflink> same here
17:16:46 <tflink> any objections to starting with the proposed blockers?
17:17:48 * tflink assumes silence == no
17:17:56 <tflink> #topic (877658) [i18n] some storage-related error messages not marked for translation: "Not enough free space on disks for automatic partitioning"
17:17:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877658
17:18:01 <buggbot> Bug 877658: unspecified, unspecified, ---, anaconda-maint-list, NEW , [i18n] some storage-related error messages not marked for translation: "Not enough free space on disks for automatic partitioning"
17:18:02 <tflink> #info Proposed Blocker, anaconda, NEW
17:18:09 <tflink> oh, the list is actually sorted today
17:18:32 <tflink> so it should mostly match what is on the blocker tracking page
17:20:06 <tflink> sounds like a rather clear blocker to me
17:20:09 <kparal> so this is just about the storage strings
17:20:36 <tflink> proposed #agreed 877658 - AcceptedBlocker - Violation of the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
17:20:42 <adamw> yeah, reasonable
17:20:55 <adamw> and these are significant messages for installation
17:21:06 <nirik> +1 blocker
17:21:19 <jreznik> yep, vpodzimek is working on it - it's just bug, no intentions not to translate it
17:21:23 <jreznik> ack
17:21:30 <adamw> +1
17:21:37 <adamw> ack
17:21:39 <nirik> ack
17:21:49 <adamw> sorry if bit slow, testing a firewalld fix
17:21:57 <tflink> #agreed 877658 - AcceptedBlocker - Violation of the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
17:22:08 <tflink> #topic (883699) Changing LV name in custom partitioning crashes installer (TypeError: Argument 2 does not allow None as a value)
17:22:10 <jreznik> adamw: thanks for firewalld one, let me know
17:22:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=883699
17:22:13 <buggbot> Bug 883699: unspecified, unspecified, ---, dlehman, MODIFIED , Changing LV name in custom partitioning crashes installer (TypeError: Argument 2 does not allow None as a value)
17:22:14 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:23:10 <nirik> hum... not sure the blockeryness... I'm +1 NTH for sure.
17:23:36 <tflink> yeah, same here
17:23:37 <adamw> anaconda team has assumed it's nth, it seems :)
17:24:03 <adamw> apparently the length of the name doesn't matter
17:24:05 <kparal> 3. Change the volgroup name to "my_vg"
17:24:05 <adamw> per comment #18
17:24:08 <nirik> hum... it's not clear if it's only really long names... or just modifying any
17:24:10 <kparal> c#16 as well
17:24:25 <nirik> ok, if it's modifying any volume name, I'm +1 blocker.
17:24:26 <adamw> right, so i'm +1, as this is a perfectly normal thing, we offer the name field for a reason...
17:24:32 <kparal> +1 as well
17:25:30 <tflink> proposed #agreed 883699 - AcceptedBlocker - Violates the following F18 final release criterion when modifying any volume name in custom partitioning: " 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:25:36 <kparal> ack
17:25:39 <nirik> ack
17:27:16 <adamw> ack
17:27:26 <adamw> note to self: when testing a bug involving sshing from a VM to the host machine, do not then attempt to power down the VM from a terminal.
17:27:27 <tflink> #agreed 883699 - AcceptedBlocker - Violates the following F18 final release criterion when modifying any volume name in custom partitioning: " 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:27:58 <tflink> adamw: did you type the command in the wrong terminal?
17:28:07 * tflink has done that more than once :-/
17:28:14 <tflink> topic (888089) ValueError: A RAID0 set requires at least 2 members
17:28:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888089
17:28:14 <tflink> #info Proposed Blocker, anaconda, POST
17:28:16 <buggbot> Bug 888089: unspecified, unspecified, ---, dlehman, POST , ValueError: A RAID0 set requires at least 2 members
17:28:27 <adamw> tflink: i ran it in the terminal I was using in the VM to test sshing out to the host box...
17:28:50 <tflink> ouch, how much stuff did you lose?
17:29:24 <tflink> +1 blocker, I think
17:29:31 <adamw> oh, nothing much, just annoying.
17:29:32 <nirik> +1 blocker on this one...
17:29:42 <tflink> as stated in c#8, it either needs to not crash or reject the invalid operation
17:30:22 <adamw> +1 blocker, seems like a strange scenario, but whatever's wrong, it's bad.
17:30:37 <jreznik> +1
17:30:39 <adamw> (by strange i mean dlehman says one of the disks is full but cmurf says no)
17:30:58 <tflink> proposed #agreed 883699 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing"
17:31:13 <nirik> ack
17:31:36 <adamw> ack
17:31:48 <jreznik> ack
17:31:54 <tflink> #agreed 883699 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing"
17:32:02 <tflink> #topic (886061) 'fedora' or 'updates' repository error must be fatal, otherwise the upgraded system might be broken heavily
17:32:05 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886061
17:32:06 <buggbot> Bug 886061: unspecified, unspecified, ---, wwoods, NEW , 'fedora' or 'updates' repository error must be fatal, otherwise the upgraded system might be broken heavily
17:32:07 <tflink> #info Proposed Blocker, fedup, NEW
17:32:41 <kparal> c#16 is 'a short' summary
17:33:14 <jreznik> "shooort"
17:33:43 <kparal> tldr: not optimal, but because Will clarified what instrepo contains and that it can't fail, I think this doesn't have to be a blocker
17:33:51 <nirik> so, how hard would it be to make it fail on _any_ repo failure?
17:33:53 <kparal> maybe I've just given up
17:34:11 <kparal> nirik: a few lines of code, that wwoods is not willing to write
17:34:14 <adamw> thanks kparal
17:34:27 <nirik> well, I thought he wasn't willing to decide which ones are critical/required.
17:34:30 <kparal> nirik: c#13 contains my discussion with Will
17:34:35 <kparal> nirik: that's it
17:34:41 <adamw> i think -1 blocker then. NTH doesn't make a lot of sense for a fedup bug really
17:35:03 <nirik> but you don't have to decide to say "all of them" do you?
17:35:19 <kparal> nirik: I asked Will just to fail on 'fedora' or 'updates' repo failures
17:35:32 <kparal> he said the repo names might change and he's not willing to maintain it
17:35:42 <adamw> he didn't want to be the gatekeeper of what 'Important Repositories' are.,
17:35:44 <tflink> highlighting repo failures might be different, though
17:35:49 <nirik> right, I am saying as a compromise, fail on ANY one.
17:35:52 <adamw> anyway, we don't need to kick that whole ball o' wax around here so much
17:36:07 <adamw> nirik: the problem with that is third-party repos fail quite a lot...
17:36:24 <nirik> too bad. disable them then, or users problem.
17:36:33 <tflink> proposed #agreed 886061 - RejectedBlocker - With the changes in fedup coming for F18, this bug is no longer as serious as it was and thus, does not qualify for release blocking status for F18 final
17:36:39 <kparal> nirik: if you want to participate in finding the best solution, you're welcome. I just wanted improve the situation a bit, I'm not sure how to make it 100% bulletproof
17:36:53 * nirik can suggest that, dunno what wwoods will think.
17:37:09 <kparal> ack
17:37:26 <jreznik> it could be an improvement for the future, would be nice to have
17:37:26 <tflink> I'm still curious for more details on what happens with stuff from rpmfusion like akmod-nvidia but that wouldn't be a blocker
17:37:28 <jreznik> ack
17:37:39 <adamw> ack
17:37:47 <tflink> #agreed 886061 - RejectedBlocker - With the changes in fedup coming for F18, this bug is no longer as serious as it was and thus, does not qualify for release blocking status for F18 final
17:37:56 <tflink> #topic (875846) [i18n] "ON" and "OFF" not translated in switches on DVD (gtk30.mo not on DVD)
17:37:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875846
17:38:00 <buggbot> Bug 875846: unspecified, unspecified, ---, mgracik, ASSIGNED , [i18n] "ON" and "OFF" not translated in switches on DVD (gtk30.mo not on DVD)
17:38:01 <tflink> #info Proposed Blocker, lorax, ASSIGNED
17:38:11 <kparal> tflink: if you mean general update with rpmfusion, it works well. I've had vlc and codecs installed and it upgraded fine
17:38:31 <tflink> kparal: ok, that's what I thought but I hadn't done one myself yet
17:38:45 <tflink> stupid blocker bugs getting in the way
17:38:49 <kparal> tflink: I tried it when Beta was released
17:39:18 <kparal> wrt 875846: I think the slider is not a problem, it is graphically visible whether it is enabled or not
17:39:31 <kparal> but I think it also affects some OK/Cancel buttons
17:39:36 <adamw> this seems to be affecting a few GTK+ stock widgets
17:39:38 <kparal> the missing gtk30.mo file
17:39:49 <kparal> and OK/Cancel buttons are a problem
17:39:55 <kparal> if untranslated
17:39:57 <adamw> i suppose this is the kind of thing we might wave through at a go/no-go, but i'm ok with +1
17:40:30 <jreznik> kparal: yep, Ok/Cancel
17:40:33 <kparal> I'd make it conditional: if this affects more than the slider, +1 blocker. if it proves to be just the slider issue, the blocker is dropped
17:41:11 <adamw> seems easier just to fix it.
17:41:12 <tflink> or we could do NTH as well, the fix should be simple
17:41:23 <jreznik> tflink: +1
17:41:36 <adamw> new rule: we don't spend more time discussing any bug than it would take to fix. =)
17:41:39 <tflink> either way, let's just pick something and go with it
17:41:45 <tflink> proposed #agreed 875846 - AcceptedBlocker - Violates the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
17:41:56 <nirik> ack
17:42:12 <adamw> ack
17:42:21 <tflink> we can revisit later if it's not fixed and remove blocker status if needed
17:42:42 <jreznik> ack
17:43:09 <tflink> #agreed 875846 - AcceptedBlocker - Violates the following F18 final release criterion: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use"
17:43:19 <tflink> #topic (872851) [abrt] rhythmbox-2.98-4.fc18: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
17:43:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872851
17:43:23 <buggbot> Bug 872851: high, high, ---, bnocera, NEW , [abrt] rhythmbox-2.98-4.fc18: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
17:43:24 <tflink> #info Proposed Blocker, rhythmbox, NEW
17:43:47 <jreznik> work for me, problem in a non default enabled plugin
17:44:01 <jreznik> the replaygain plugin
17:44:21 <tflink> yeah, if it's not on the livecd I'm -1 on this
17:44:31 <jreznik> -1 blocker
17:44:36 <tflink> even if it is, I'm not sure I'd be +1
17:44:37 * nirik is also -1 if it's not on media / needs a non default plugin
17:44:45 <jreznik> tflink: even if it is, it does not matter, non default plugin
17:44:57 <adamw> assuming that interpretation is correct, -1
17:45:08 <adamw> though it'd be good to check that all the reporters had replaygain enabled. it's a lot of reporters.
17:45:08 <jreznik> big thanks goes again to halfline for desktop team, he helped me with it today
17:45:10 <tflink> jreznik: grey area, I think if it's easily enabled
17:45:25 <nirik> it might should be filed upstream as well.
17:45:27 <adamw> we're still beyond 'basic functionality' if you have to go and manually enable a plugin.
17:45:37 <nirik> I don't think the maintainer pays any attention at all to redhat bz.
17:45:38 <adamw> nirik: usually not worth worrying about with core gnome stuff, all the people are the same...
17:45:53 <tflink> proposed #agreed 872851 - RejectedBlocker - While rhythmbox is a default application, this bug requires installation and enabling of a non-default plugin and thus does not qualify for release blocking status for F18 final.
17:45:59 <jreznik> nirik: guess what he told me when I asked him today :)))
17:46:02 <adamw> not sure about 'installation'
17:46:17 <adamw> patch: scratch 'installation'
17:46:21 <nirik> right, he explictly ignores all those bugs. :)
17:46:22 <tflink> proposed #agreed 872851 - RejectedBlocker - While rhythmbox is a default application, this bug requires  enabling of a non-default plugin and thus does not qualify for release blocking status for F18 final.
17:46:29 <nirik> ack
17:46:31 <adamw> the plugin is part of RB and always available, it's just not enabled.
17:46:33 <jreznik> ack
17:46:33 <adamw> double space, but ack.
17:46:37 <kparal> ack
17:46:52 <tflink> #agreed 872851 - RejectedBlocker - While rhythmbox is a default application, this bug requires enabling of a non-default plugin and thus does not qualify for release blocking status for F18 final.
17:47:00 <tflink> #topic (861280) KDE Crashes or Hangs After Moving Konqueror Window Quickly
17:47:03 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=861280
17:47:05 <buggbot> Bug 861280: medium, unspecified, ---, bskeggs, NEW , KDE Crashes or Hangs After Moving Konqueror Window Quickly
17:47:06 <tflink> #info Proposed Blocker, xorg-x11-drv-nouveau, NEW
17:47:35 <jreznik> -1 blocker, -1 nth
17:47:36 <tflink> this sounds like it is too hardware limited to be a blocker and has some workarounds
17:47:59 <adamw> paul's card is a decade older than adam's, so they're very unlikely to be seeing the same bug, so focus on adam's report
17:48:01 * nirik nods.
17:48:04 <jreznik> workaround - do not move window quickly :)
17:48:16 <nirik> can also be fixed in a update hopefully
17:48:25 <adamw> in which case all we have is the initial report, no valid dupes, no info to suggest it's anything but a normal driver bug...-1
17:48:39 <nirik> -1 here too
17:48:47 <tflink> proposed #agreed 861280 - RejectedBlocker - This is very HW limited and thus, does not qualify for release blocking status.
17:49:24 <nirik> ack
17:49:49 <jreznik> ack
17:49:53 <adamw> ack
17:49:59 <tflink> #agreed 861280 - RejectedBlocker - This is very HW limited and thus, does not qualify for release blocking status.
17:50:06 <tflink> #topic (860022) AttributeError: preconf
17:50:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860022
17:50:06 <tflink> #info Proposed Blocker, yum, NEW
17:50:08 <buggbot> Bug 860022: unspecified, unspecified, ---, packaging-team, NEW , AttributeError: preconf
17:50:40 <tflink> this sounds like a timing issue to me
17:50:58 * nirik isn't clear on when this is triggered.
17:51:06 <jreznik> tflink: I talked to Zdenek, he prepared fix for yum - real bug is on anaconda side...
17:51:19 <jreznik> nirik: /me neither
17:51:20 <tflink> thread-unsafeness in anaconda's usage of yum, I think
17:51:34 <jreznik> tflink: yep
17:51:50 <nirik> sure, but how widespread is it?
17:51:56 <tflink> it sounds like it's more likely if you have a bunch of repos enabled
17:52:00 <nirik> does it happen at any particular part of the install?
17:52:08 <kparal> I haven't seen it
17:52:25 * nirik hasn't either
17:52:30 <tflink> I think that orion is doing ks installs
17:52:34 <jreznik> same here
17:52:58 <adamw> "I've got a lot of repos configured - I wonder if that helps trigger it."
17:53:01 <tflink> I suspect that you'd hit this during installation
17:53:27 <jreznik> definitely during installation
17:53:35 <jreznik> as yum is involved
17:53:41 <adamw> yes, that's what the screenshot shows.
17:53:48 <tflink> I meant installation vs configuring from hub
17:53:50 <adamw> "starting package installation process" then the tb.
17:53:54 <adamw> yes, i know.
17:53:55 <adamw> :)
17:54:05 <nirik> well, I'd say perhaps we punt and ask orion to try the updates.img ?
17:54:09 <tflink> so it would be after disk prep
17:54:14 <adamw> yes.
17:54:16 <nirik> and note how many repos, etc?
17:54:24 <kparal> +1 nth immediately, punt blocker
17:54:32 <adamw> yes
17:54:37 <adamw> was gonna suggest the same, it's at least NTH
17:54:58 * nirik nods. I'm good with that plan
17:55:25 * jreznik is ok with punting and asking for more info, we should have fix from both anaconda/yum sides... in any case
17:55:45 <tflink> proposed #agreed 860022 - AcceptedNTH - We need more information on how many repos are being used to trigger this and if the updates.img from comment#20 works before deciding on blocker status. However, this is bad enough to warrant NTH status - a tested fix would be considered past freeze.
17:56:13 <jreznik> ack
17:56:16 <nirik> ack
17:57:59 <kparal> ack
17:58:08 <adamw> ack
17:58:13 <tflink> #agreed 860022 - AcceptedNTH - We need more information on how many repos are being used to trigger this and if the updates.img from comment#20 works before deciding on blocker status. However, this is bad enough to warrant NTH status - a tested fix would be considered past freeze.
17:58:25 <tflink> OK, that's all of the proposed blockers I have marked as ready for discussion
17:58:37 <tflink> proposed NTH time?
17:59:15 <adamw> wait
17:59:24 <adamw> i see several proposed blockers in POST or MODIFIED which we haven't discussed. that seems odd.
17:59:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=886647
17:59:40 <buggbot> Bug 886647: high, unspecified, ---, rvykydal, POST , Anaconda throws exception trying to setup network if non-existing network --device is specified in kickstart
17:59:45 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=860525
17:59:47 <buggbot> Bug 860525: unspecified, unspecified, ---, dracut-maint, MODIFIED , dracut-pre-pivot[272]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs,
17:59:53 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=882212
17:59:55 <buggbot> Bug 882212: unspecified, unspecified, ---, mschmidt, POST , localectl set-x11-keymap: variant settings does not work
18:01:01 <tflink> how did the set-x11 one not get on this list?
18:01:02 <tflink> damnation
18:01:44 <tflink> we can go through them if you'd like
18:02:02 <adamw> yes, let's.
18:02:03 <tflink> the dracut bug _still_ has no explanation on how it affects installs over NFS
18:02:32 <tflink> #topic (860525) dracut-pre-pivot[272]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs,
18:02:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860525
18:02:37 <buggbot> Bug 860525: unspecified, unspecified, ---, dracut-maint, MODIFIED , dracut-pre-pivot[272]: mount: wrong fs type, bad option, bad superblock on /var/lib/nfs/rpc_pipefs,
18:02:38 <tflink> #info Proposed Blocker, dracut, MODIFIED
18:03:19 <tflink> I still don't understand the impact here
18:03:24 <tflink> no response to my questions
18:03:46 * jreznik is trying to ping harald
18:04:56 <adamw> with the reference to 'possible install errors' and the fact that this doesn't seem to have broken anything, i guess +1 nth at least
18:05:03 <adamw> retroactive nth!
18:05:15 <tflink> I think this update is marked as blocker for other reasons
18:05:17 <tflink> or I thought so
18:06:00 <adamw> probably
18:06:09 <adamw> okay, so maybe this one will just go away if we ignore it.
18:06:10 <tflink> it is: 874486
18:06:31 <adamw> technically this fix shouldn't have been put in the update, but i am beyond caring at this point.
18:06:38 <adamw> at least till someone breaks something.
18:06:49 <tflink> ?
18:07:03 <tflink> oh, nvm.
18:07:40 <tflink> so, thoughts?
18:07:59 <adamw> punt
18:08:06 <adamw> sorry for bringing it up
18:08:33 <tflink> you caught some others that were supposed to be "ready for discussion", so it wasn't for naught
18:09:34 <tflink> proposed #agreed 860525 - It still isn't clear how this impacts NFS installs, need more information before deciding on blocker status
18:10:03 <adamw> ack
18:10:19 * kparal needs to go
18:11:13 <tflink> #agreed 860525 - It still isn't clear how this impacts NFS installs, need more information before deciding on blocker status
18:11:17 <tflink> #topic (882212) localectl set-x11-keymap: variant settings does not work
18:11:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882212
18:11:21 <buggbot> Bug 882212: unspecified, unspecified, ---, mschmidt, POST , localectl set-x11-keymap: variant settings does not work
18:11:23 <tflink> #info Proposed Blocker, systemd, POST
18:11:40 <tflink> crap, fesco meeting started - not sure we have enough people to continue
18:12:26 <tflink> who all is still here and planning to participate other than adamw and me?
18:13:04 <adamw> at least +1 nth for this one
18:14:07 <tflink> oh yeah, that's why this isn't on the list of blockers ready to discuss
18:14:09 * jreznik is still here, just watching fesco meeting by one eye - they know how to surprise me :)
18:14:33 <tflink> because it isn't a blocker without more testing but is on the list of NTH ready for discussion
18:14:40 <tflink> +1 NTH
18:14:50 <adamw> ah okay.
18:16:07 <tflink> 888560 is already accepted NTH. didn't see the need to discuss it today
18:16:29 <tflink> the only one I really missed was 886647, I think
18:17:36 <tflink> proposed #agreed 882212 - AcceptedNTH - This does affect upgrades with yum which aren't recommended but aren't uncommon. A tested fix would be considered past freeze.
18:17:41 <adamw> ack
18:17:43 <jreznik> ack
18:17:49 <tflink> #agreed 882212 - AcceptedNTH - This does affect upgrades with yum which aren't recommended but aren't uncommon. A tested fix would be considered past freeze.
18:18:05 <tflink> #topic (886647) Anaconda throws exception trying to setup network if non-existing network --device is specified in kickstart
18:18:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886647
18:18:11 <buggbot> Bug 886647: high, unspecified, ---, rvykydal, POST , Anaconda throws exception trying to setup network if non-existing network --device is specified in kickstart
18:18:11 <tflink> #info Proposed Blocker, anaconda, POST
18:18:48 <adamw> per comment #16 i'm -1/+1
18:18:48 <tflink> sounds kind of -1/+1
18:19:23 <jreznik> after quick look -1/+1
18:19:56 <tflink> proposed #agreed 886647 - RejectedBlocker AcceptedNTH - This is too much of a corner case to take as a blocker but it can't be fixed with an update and a non-trivial number of people could hit this. A tested fix would be considered past freeze.
18:20:51 <jreznik> ack
18:21:20 <adamw> ack
18:21:33 <tflink> #agreed 886647 - RejectedBlocker AcceptedNTH - This is too much of a corner case to take as a blocker but it can't be fixed with an update and a non-trivial number of people could hit this. A tested fix would be considered past freeze.
18:22:18 <tflink> any others that I missed?
18:23:07 <adamw> there's some more info in https://bugzilla.redhat.com/show_bug.cgi?id=859867 since yesterday
18:23:09 <buggbot> Bug 859867: unspecified, unspecified, ---, vpodzime, ASSIGNED , Keyboard not set in minimal install
18:23:09 <adamw> reading through that now
18:24:00 <adamw> i think it still needs a bit of clearing up, though.
18:26:41 <tflink> which is mostly what my notes say :)
18:26:43 <adamw> i don't see any others
18:26:54 <tflink> which are available, btw :)
18:27:19 <adamw> but that would involve reading!
18:27:25 <adamw> onto nth?
18:27:56 <tflink> so there's no point in me spending at least an hour a day reading through bugs and figuring out if they're ready for discussion?
18:28:13 <adamw> i'm just being facetious
18:28:15 <jreznik> just a moment, need a short pause otherwise I'm not sure valgrind would find leak around me :D
18:28:22 <adamw> i didn't notice you'd updated since yesterday night
18:28:31 * adamw also needs some valgrind-proofing
18:29:19 <jreznik> it actually works quite well pinging people before blocker review for some of the proposed ones :))) at least to have overview and not to block meeting!
18:29:24 <tflink> adamw: yeah, I know. so was I.  and I did miss one
18:29:55 <tflink> I'm just looking forward to getting this list under control so I'm not spending so much time on blocker wrangling
18:30:06 <tflink> on to NTH!
18:30:51 <tflink> btw, I am sorting stuff by priority now. if a bug is more important, ping me and I'll bump it up on the list
18:31:04 <tflink> #topic (888107) Shell leaking memory with every interaction with the panel
18:31:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888107
18:31:09 <buggbot> Bug 888107: high, unspecified, ---, otaylor, NEW , Shell leaking memory with every interaction with the panel
18:31:10 <tflink> #info Proposed NTH, gnome-shell, NEW
18:31:41 <tflink> +1 NTH
18:32:29 <tflink> proposed #agreed 888107 - AcceptedNTH - This isn't quite a blocker but causes problems for lives, especially in lower memory situations. A tested fix would be considered past freeze.
18:34:14 <jreznik> ack
18:34:47 <adamw> ack
18:35:11 <tflink> #agreed 888107 - AcceptedNTH - This isn't quite a blocker but causes problems for lives, especially in lower memory situations. A tested fix would be considered past freeze.
18:35:21 <tflink> #topic (830181) Logout/shutdown/restart should be inhibited while Apper is performing updates
18:35:24 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=830181
18:35:26 <buggbot> Bug 830181: unspecified, unspecified, ---, hughsient, ASSIGNED , Logout/shutdown/restart should be inhibited while Apper is performing updates
18:35:26 <tflink> #info Proposed NTH, PackageKit, ASSIGNED
18:37:49 <adamw> i'm not sure I'm happy with major packagekit surgery as nth
18:37:58 <adamw> i think i'd prefer this kinda thing to go in pre-freeze
18:38:34 <tflink> yeah, I think this could be better fixed as an update
18:38:39 <tflink> it wouldn't affect lives
18:38:52 <jreznik> -1 nth
18:38:56 <tflink> -1 nth
18:38:59 <adamw> -1
18:39:16 <jreznik> end yeah, in sumarry - packagekit is the right place to put inhibition
18:40:02 <jreznik> no support for offline updates in Apper, low prio for dantti and also nobody from KDE SIG likes offline updates :))) (for offline updates question ;-)
18:40:29 <tflink> proposed #agreed 830181 - RejectedNTH - Taking PK fixes this close to release is unwise and since this bug wouldn't affect live images and thus could be fixed with an update - rejected as NTH for F18 final
18:40:37 <adamw> ack
18:41:37 <jreznik> ack
18:41:52 <tflink> #agreed 830181 - RejectedNTH - Taking PK fixes this close to release is unwise and since this bug wouldn't affect live images and thus could be fixed with an update - rejected as NTH for F18 final
18:42:01 <tflink> #topic (875567) anaconda doesnt set keyboard layout for LUKS password at reboot
18:42:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875567
18:42:06 <buggbot> Bug 875567: unspecified, unspecified, ---, vpodzime, MODIFIED , anaconda doesnt set keyboard layout for LUKS password at reboot
18:42:07 <tflink> #info Proposed NTH, anaconda, MODIFIED
18:43:41 <tflink> this might be a blocker, actually
18:44:04 <tflink> eh, borderline - c#9
18:44:38 <tflink> +1, though
18:44:54 <adamw> definite +1 nth
18:45:56 <tflink> proposed #agreed 875567 - AcceptedNTH - This is borderline blocker since LUKS passwords are affected but not all installations are affected by this. A tested fix would be considered past freeze.
18:46:24 <adamw> i wonder if this conditionality is somehow affecting those other keymap layout bugs?
18:46:42 <adamw> be nice to have more details, c#9 is a bit vague, what does 'provided by systemd-localed' mean exactly? what layouts are and are not in that group?
18:46:46 <adamw> ack
18:47:49 <adamw> patch looks to be https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-December/002350.html
18:49:33 <jreznik> adamw: I can talk to vratislav tmrw (in case he will be in the office)
18:49:39 <adamw> thanks...
18:49:42 <jreznik> but ack for now
18:49:57 <tflink> #agreed 875567 - AcceptedNTH - This is borderline blocker since LUKS passwords are affected but not all installations are affected by this. A tested fix would be considered past freeze.
18:50:02 <adamw> yeah, actually i think the possibility is a good one - this might fix whatever people are complaining about in those other bugs too
18:51:46 <tflink> #topic (876916) anaconda claims I don't have enough free space when I have
18:51:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876916
18:51:51 <buggbot> Bug 876916: unspecified, unspecified, ---, anaconda-maint-list, NEW , anaconda claims I don't have enough free space when I have
18:51:51 <tflink> #info Proposed NTH, anaconda, NEW
18:52:58 <adamw> i feel like we've had a bug for this before?
18:53:08 <adamw> anyway it's the old 'very borderline disk space' scenario...
18:53:09 <tflink> we've talked about it before
18:53:27 <adamw> i'm probably +1 nth for a clean small simple fix for the minimum space detection stuff
18:53:32 <tflink> or at least something similar - I think this bug was extracted out of another one
18:53:52 <tflink> yeah +1 NTH
18:53:56 * satellit would be nice to have a display showing anaconda's allocation ie how big a swap it is adding before it does it
18:54:07 * adamw pings clumens about this one
18:55:43 <adamw> we can go ahead and propose, i was just checking if he had the needed info
18:55:56 <tflink> proposed #agreed 876916 - AcceptedNTH - This isn't critical but it would be good to have effective minimum space detection and this can't be fixed with an update. A tested fix would be considered past freeze.
18:56:37 <jreznik> ack
18:56:49 <adamw> ack
18:56:55 <tflink> #agreed 876916 - AcceptedNTH - This isn't critical but it would be good to have effective minimum space detection and this can't be fixed with an update. A tested fix would be considered past freeze.
18:57:06 <tflink> #topic (882233) Chinese (Taiwan) shows Simplified Chinese instead of Traditional Chinese at left (native language view) side
18:57:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882233
18:57:11 <buggbot> Bug 882233: unspecified, unspecified, ---, anaconda-maint-list, ASSIGNED , Chinese (Taiwan) shows Simplified Chinese instead of Traditional Chinese at left (native language view) side
18:57:12 <tflink> #info Proposed NTH, anaconda, ASSIGNED
18:59:30 <tflink> this is an annoyance for Taiwaneese users but it sounds like we're not going to get a fix in time
18:59:30 <adamw> oh dear. my political antenna are going off here.
19:00:49 <adamw> well, whether we get a fix is kinda irrelevant
19:00:56 <adamw> i'm leaning +1 on this but i just want to check we got it 'right' in f17
19:01:16 <adamw> i.e. we won't be doing something *different* if we fix this (it's always slightly sensitive to change how we deal with china vs. taiwan stuff)
19:01:43 <tflink> I didn't think that traditional vs. simplified was that big of a deal
19:02:14 <adamw> in itself, no
19:02:43 <adamw> the problem is that the actual word here is 'Taiwan'...
19:03:02 <adamw> so the question is are we using the characters the Chinese would prefer to use to say 'Taiwan' or the characters the Taiwanese would prefer to use to say 'Taiwan'.
19:03:08 <tflink> yeah, I figured that separating out zh_cn vs zh_tw was more of an issue
19:03:23 <adamw> ah. in f17 we actually had 'Simplied' and 'Traditional', we didn't refer to the places. so it's a bit 'new territory'.
19:03:25 <tflink> what does that have to do with this bug? am I missing something?
19:03:33 <adamw> it *is* this bug.
19:03:37 <tflink> how so?
19:03:56 <adamw> well...i just said how so.
19:04:01 <adamw> i'm not sure how I could possibly rephrase it.
19:04:02 <tflink> I guess I'm just looking at it differently - as a "tw should have traditional instead of simplified"
19:04:18 <adamw> no, the bug is specifically about the characters used for a single 'word' on the language selection screen
19:04:23 <adamw> the word, in English, is Taiwan
19:04:49 <jreznik> uf
19:04:56 <adamw> right now, the Chinese characters we are using to write 'Taiwan' are the characters that China would use, as that's what our upstream reference (CLDR) states
19:05:09 <adamw> but Taiwanese people would expect to see the characters that Taiwan would use to write Taiwan. obviously.
19:06:14 <tflink> ok, I misunderstood the bug
19:06:20 <jreznik> I understand now
19:06:36 <tflink> I thought this was bout using traditional vs. simplified. not the character used for taiwan
19:06:51 <adamw> yeah, it's a bit confusing at first.
19:07:11 <adamw> i hate to be a coward but my instinct is not to touch this one with a bargepole.
19:07:18 <jreznik> but based on "This is not a blocker for F18, and for F19 I want to get rid of mangleMap" - do we want to invest the time to fix this?
19:07:49 <adamw> well, i mean, clumens was describing the situation at that point
19:08:07 <adamw> he wasn't declaring that it *shouldn't* be a blocker, he was saying that it hadn't been accepted as one.
19:08:22 <adamw> saying 'we shouldn't take this as NTH because clumens wrote a comment saying it wasn't one' is basically circular logic :)
19:08:29 <adamw> so ignore that comment in making our decision, i think.
19:08:58 <adamw> but i'm still -1, just because this is a bit sensitive.
19:10:16 <tflink> I'm probably closer to +1. I'm not saying that it should or shouldn't be fixed - just that it can't be changed with an update and is not what affected users expect
19:10:29 <adamw> well, that's a reasonable position too
19:10:30 <jreznik> especially when we lack that cultural info
19:10:31 <tflink> are likely to expect
19:10:32 <adamw> anyone want to split the tie?
19:10:41 <tflink> the political stuff is out of our hands
19:11:05 <jreznik> it is but let me check what's really true as I really don't know
19:11:29 <jreznik> and I remember similar bugs when half of nation prefer XY and second half YX
19:11:51 <adamw> the tricky thing here is that you have two entities who don't agree on what the nation is. :D
19:12:06 <tflink> true
19:12:07 <jreznik> adamw: yep, that's an instance of that XY and YX
19:12:32 <jreznik> and it's one nation for one group, two nations for another one
19:12:38 <adamw> right, that's what i meant.
19:12:49 <adamw> anyway...you're suggesting punt to check on the politicalities?
19:13:07 <niptiva> if the policy is to use CLDR, blame CLDR
19:13:15 <tflink> I think we're bumping into the "don't spend more time discussing than it would take to fix" rule :)
19:13:19 <adamw> true
19:13:34 <adamw> anaconda's policy isn't 'use CLDR' exactly, but 'use some Canonical External Resource, don't try and figure it out ourselves'
19:14:14 * adamw is ok with punting
19:14:27 <tflink> either way
19:15:17 <tflink> proposed #agreed 882233 - We would like to have more information on how bugs like this have been handled in the past - there isn't a clear universal answer which all parties would like. Will revisit when there's more info.
19:15:27 <adamw> ack
19:15:59 <jreznik> ack
19:16:13 <tflink> #agreed 882233 - We would like to have more information on how bugs like this have been handled in the past - there isn't a clear universal answer which all parties would like. Will revisit when there's more info.
19:16:22 <tflink> #topic (886463) Keyboard layout switching is confusing on LiveCD
19:16:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886463
19:16:22 <tflink> #info Proposed NTH, anaconda, MODIFIED
19:16:25 <buggbot> Bug 886463: unspecified, unspecified, ---, vpodzime, MODIFIED , Keyboard layout switching is confusing on LiveCD
19:17:30 <tflink> I'm OK with +1 on this
19:18:44 <adamw> reading
19:19:06 <adamw> adding a note seems safe and a good idea.
19:19:25 <adamw> we have lots of space on that screen so it probably won't cause any layout problems
19:19:29 <adamw> even in German translation...
19:19:51 <jreznik> lol
19:19:54 <jreznik> +1
19:20:06 <adamw> +1
19:20:37 <nirik> +1
19:20:38 <tflink> proposed #agreed 886463 - AcceptedNTH - Adding the warning message seems like a good idea without much risk. A tested fix would be considered past freeze.
19:20:58 <nirik> ack
19:21:35 <adamw> ack
19:21:48 <tflink> #agreed 886463 - AcceptedNTH - Adding the warning message seems like a good idea without much risk. A tested fix would be considered past freeze.
19:21:55 <tflink> #topic (887112) Existing Windows 7 appears under \'Unknown\' in Manual Partitioning
19:21:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887112
19:22:00 <buggbot> Bug 887112: unspecified, unspecified, ---, dlehman, NEW , Existing Windows 7 appears under 'Unknown' in Manual Partitioning
19:22:00 <tflink> #info Proposed NTH, anaconda, NEW
19:22:46 <tflink> I might be OK with this as NTH but it sounds unlikely to be fixed or looked at
19:23:49 <adamw> i'm not sure how sensitive the 'os detection' code is...
19:24:34 <adamw> i guess it's a bit academic if clumens doesn't think it's likely to happen, my instinct is -1 for safety
19:24:48 <tflink> I'm kind of +/- 0 NTH for this, would be nice to see but I don't think it's a big deal and not sure it's worth the risk
19:25:21 * nirik is a weak -1 on it too
19:25:49 <jreznik> not worth of the risk, -1
19:25:54 <tflink> proposed #agreed 887112 - RejectedNTH - While this might be a nice visual enhancement, it isn't a huge deal and represents a bit more risk than we'd like to see so late in the release.
19:26:10 <jreznik> ack
19:26:59 <adamw> ack
19:27:12 <tflink> #agreed 887112 - RejectedNTH - While this might be a nice visual enhancement, it isn't a huge deal and represents a bit more risk than we'd like to see so late in the release.
19:27:20 <tflink> #topic (888112) Yellow error display bar is incapable of wrapping long errors, they are too wide and overflow the side of the screen
19:27:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888112
19:27:25 <buggbot> Bug 888112: medium, unspecified, ---, clumens, VERIFIED , Yellow error display bar is incapable of wrapping long errors, they are too wide and overflow the side of the screen
19:27:26 <tflink> #info Proposed NTH, anaconda, VERIFIED
19:27:47 <tflink> already pulled, so somewhat academic
19:27:47 <adamw> oh goody, more retroactive action
19:27:53 <adamw> well wecould force it out again
19:27:56 <adamw> but i'm +1 obviously
19:28:00 <nirik> +1
19:29:26 <tflink> proposed #agreed 888112 - AcceptedNTH - This is a very useful visual enhancement without much risk and can't be fixed with an update. A tested fix would be considered past freeze.
19:30:40 <jreznik> ack
19:31:00 <adamw> ack
19:31:14 <tflink> #agreed 888112 - AcceptedNTH - This is a very useful visual enhancement without much risk and can't be fixed with an update. A tested fix would be considered past freeze.
19:31:24 <tflink> #topic (888603) Custom partitioning shouldn't let you set /boot as btrfs
19:31:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888603
19:31:28 <buggbot> Bug 888603: medium, unspecified, ---, dlehman, NEW , Custom partitioning shouldn't let you set /boot as btrfs
19:31:29 <tflink> #info Proposed NTH, anaconda, NEW
19:31:40 <nirik> I thought boot could be btrfs.
19:31:41 * nirik reads
19:31:42 <adamw> +1 on this as it's a safety check and a simple change
19:32:08 <nirik> doesn't grub2 support that? odd.
19:32:38 <nirik> but sure, that seems like a easy fix for it not working... +1
19:32:41 <tflink> proposed #agreed 888603 - AcceptedNTH - This is a safety check to disallow a non-obviously invalid operation and is relatively low risk. A tested fix would be considered past freeze.
19:32:57 <nirik> ack
19:33:16 <adamw> ack
19:33:30 <tflink> #agreed 888603 - AcceptedNTH - This is a safety check to disallow a non-obviously invalid operation and is relatively low risk. A tested fix would be considered past freeze.
19:33:43 <tflink> #topic (886556) missing icons in yumex & apper
19:33:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886556
19:33:43 <tflink> #info Proposed NTH, comps-extras, NEW
19:33:45 <buggbot> Bug 886556: unspecified, unspecified, ---, notting, NEW , missing icons in yumex & apper
19:34:10 <tflink> I could probably go either way on this
19:34:29 <tflink> what all is in comps-extras
19:34:51 <adamw> does this have to be in GA?
19:35:16 <tflink> it would be nice to have the icons work right after install
19:35:18 <adamw> i just pinged notting
19:37:10 <adamw> eh, if it's just about having them in when you first run yumex/apper...man, i could go either way
19:37:19 <adamw> it'd suck if it broke packagekit or something
19:37:54 <tflink> yeah, I think we're in a similar boat
19:39:18 <adamw> well without clear justification if we're on the fence we ought to lean -1
19:39:42 <tflink> true
19:41:00 <tflink> proposed #agreed 886556 - RejectedNTH - While this is a polish issue that would be good to fix, it's late in the release and the risk of taking this fix so late is not clearly low (could affect PK, apper etc.).
19:41:20 <adamw> ack
19:42:55 <tflink> other votes?
19:43:23 <nirik> ack
19:43:44 <tflink> #agreed 886556 - RejectedNTH - While this is a polish issue that would be good to fix, it's late in the release and the risk of taking this fix so late is not clearly low (could affect PK, apper etc.).
19:43:58 <tflink> we have 12 proposed NTH left on my list
19:44:05 <tflink> and we're at 2:45 for time
19:44:19 <tflink> any issues with just getting them done today?
19:44:33 <adamw> i'm ok to keep going for a bit
19:44:35 <nirik> lets get them over with
19:44:38 <tflink> #topic (855697) No way to change the language on Live
19:44:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=855697
19:44:38 <tflink> #info Proposed NTH, control-center, NEW
19:44:40 <buggbot> Bug 855697: unspecified, unspecified, ---, control-center-maint, NEW , No way to change the language on Live
19:44:44 <adamw> we can throw all dledford's together as a clump
19:45:58 <nirik> it doesnt sound like theres a fix available here...
19:46:05 <nirik> or even a sure idea how to move forward?
19:46:08 <adamw> yeah
19:46:13 <adamw> it seems a bit vague for me to be happy +1ing
19:46:25 <adamw> i don't mind +1ing a bug without _code_ ready, but it should at least be clear what the actual plan is
19:46:29 <nirik> yeah
19:46:43 <adamw> the fix for this could be to have a logout entry on the live menu permanently...or it could be a whole new app in the boot sequence...
19:47:08 <tflink> punt or reject?
19:47:11 * satellit how about a remix? with su -c 'yum install l10n-kickstarts'
19:47:18 <adamw> hold on
19:47:20 <adamw> check the upstream bug
19:47:24 <adamw> there seems to be a fix upstream...
19:47:38 <adamw> which is to show a logout button in the control center applet
19:47:46 <adamw> i'd vote +1 for backporting that probably
19:48:25 <nirik> yeah, I guess so, +1 if it's ready
19:48:36 <adamw> so i'm +1 if we clarify that what we're +1ing is a backport of the upstream fix which just adds a logout button to the region/language applet
19:48:47 <nirik> yep
19:50:23 <tflink> proposed #agreed 855697 - AcceptedNTH - While there are a couple ideas in the bug, there is an available fix upstream to add a logout button to the language/region applet - a tested fix would be considered past freeze but only if it is the fix from upstream - other fixes would need to be reproposed for NTH status
19:50:46 <adamw> ack
19:51:07 <nirik> ack
19:51:27 <tflink> #agreed 855697 - AcceptedNTH - While there are a couple ideas in the bug, there is an available fix upstream to add a logout button to the language/region applet - a tested fix would be considered past freeze but only if it is the fix from upstream - other fixes would need to be reproposed for NTH status
19:51:34 <tflink> #topic (873849) no keyboard shortcut for toggling keyboard layouts
19:51:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873849
19:51:35 <tflink> #info Proposed NTH, gnome-settings-daemon, NEW
19:51:36 <buggbot> Bug 873849: unspecified, unspecified, ---, bnocera, NEW , no keyboard shortcut for toggling keyboard layouts
19:53:46 <adamw> this seems vague and messy.
19:53:58 <adamw> -1 as it stands, no clear explanation of what precisely is broken here and what the proposed fix is.
19:54:04 <tflink> yeah, it looks like I tried to sort these too quickly
19:54:15 <tflink> I think that the broken part is pretty clear
19:54:27 <nirik> yeah, -1 without a clear idea of the solution.
19:54:30 <tflink> but there is no proposed fix and it doesn't look like there is developer interest
19:54:47 <adamw> i thought alt-space was the combo in gnome?
19:54:52 <adamw> hm, maybe not.,
19:55:01 <adamw> but yeah, we at least need input from desktop team. i'll poke them.
19:55:26 <tflink> this might just be another flamewar brought to fedora after gnome did something a user wasn't happy with
19:55:44 <adamw> anyway, -1 or punt i think
19:55:50 * nirik nods.
19:56:56 <adamw> maybe punt to give it a chance, in case gnome team look at it and go 'oh oops'
19:57:02 <nirik> sure
19:58:24 <tflink> proposed #agreed 873849 - It isn't completely clear what the fix for this might be or whether there is developer support for a fix. Will re-visit when more info is available
19:58:45 <adamw> ack
19:59:09 <nirik> ack
19:59:59 <tflink> #agreed 873849 - It isn't completely clear what the fix for this might be or whether there is developer support for a fix. Will re-visit when more info is available
20:00:13 <tflink> #topic (886077) Custom shortcut super+'char' writes the char or does nothing instead of execute demanded action
20:00:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886077
20:00:18 <buggbot> Bug 886077: unspecified, unspecified, ---, bnocera, NEW , Custom shortcut super+'char' writes the char or does nothing instead of execute demanded action
20:00:18 <tflink> #info Proposed NTH, gnome-settings-daemon, NEW
20:01:17 <tflink> I wonder if this is a dupe or related to the last bug
20:01:52 <adamw> possibly? but then, in this case it seems c-c lets you set the combo you want, but it doesn't work
20:02:26 <adamw> not sure about NTH for this, it's an inconvenience not a showstopper and it could be fixed with an update
20:03:11 <adamw> so going with the 'default to -1' mindset, i guess -1
20:03:30 <nirik> yeah, -1
20:04:58 <tflink> is super+a the way you're supposed to be able to switch layouts in shell?
20:05:35 <adamw> no, it's a shortcut he picked
20:05:40 <adamw> i'm talking about this in fedora-desktop atm
20:05:54 <adamw> it seems that they have a Grand Plan to make things better for 3.8, but there is a disinclination to do any quick fixes for f18
20:06:00 <tflink> ok, nvm
20:06:09 * nirik thinks thats sane... it's way late.
20:06:09 <adamw> i'm getting the feeling the situation is basically just sucky, there isn't a 'supposed to work' atm
20:06:26 <adamw> there isn't a default key combo and there isn't an 'accepted normal' one you can set, so petr was just picking something more or less arbitrary
20:06:46 <adamw> mclasen doesn't seem to think this one's a big issue, fwiw.
20:06:50 <adamw> <mclasen> adamw: I don't understand that at all, tbh - it has been clear for a long time that the shell has a special affinity to super and claims first rights to it
20:06:52 <tflink> proposed #agreed 886077 - RejectedNTH - While this is an inconvenience, it involves setting custom actions which is unlikely to affect live images and thus can be fixed with an update.
20:06:57 <adamw> (talking about 886077 there).
20:06:59 <adamw> ack
20:08:33 <jreznik> ack
20:08:43 <tflink> #agreed 886077 - RejectedNTH - While this is an inconvenience, it involves setting custom actions which is unlikely to affect live images and thus can be fixed with an update.
20:08:51 <tflink> #topic (888395) 3.6.11 update for kernel
20:08:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888395
20:08:51 <tflink> #info Proposed NTH, kernel, NEW
20:08:53 <buggbot> Bug 888395: unspecified, unspecified, ---, kernel-maint, NEW , 3.6.11 update for kernel
20:09:28 <tflink> the argument is a little weak here since fedup uses updates by default if you're doing a network upgrade
20:09:50 <nirik> are there any other critical things in the update?
20:09:52 * nirik looks
20:10:17 <adamw> -1 on general principles, we have enough stuff to worry about without some random kernel regression popping up.
20:10:20 <adamw> we have a kernel that's working, let's keep it.
20:10:28 <nirik> -1
20:10:32 <nirik> yeah
20:10:58 <jreznik> -1
20:11:06 <adamw> and as kkofler loves to point out, trying to keep the 'frozen' upgrade path working is a futile exercise
20:11:20 <adamw> f16/f17 will get bumped to 3.7 at some point anyhow, so what's the point
20:11:20 <tflink> proposed #agreed 888395 - RejectedNTH - This would only fix media sourced upgrades for a very short time and would not affect network sourced upgrades. Since there are no other critical reasons to upgrade the released kernel, rejected as NTH for F18 final.
20:11:25 <adamw> ackity ack
20:11:31 <nirik> ack
20:12:11 <jreznik> ack
20:12:14 <tflink> #agreed 888395 - RejectedNTH - This would only fix media sourced upgrades for a very short time and would not affect network sourced upgrades. Since there are no other critical reasons to upgrade the released kernel, rejected as NTH for F18 final.
20:12:22 <tflink> #topic (872162) error creating partitions on LVM volume created with allocation=0
20:12:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872162
20:12:26 <buggbot> Bug 872162: unspecified, unspecified, ---, libvirt-maint, ASSIGNED , error creating partitions on LVM volume created with allocation=0
20:12:27 <tflink> #info Proposed NTH, libvirt, ASSIGNED
20:13:00 <tflink> -1 NTH, I think
20:13:13 <tflink> wouldn't affect lives, could be fixed with an update, isn't the default path
20:13:42 <adamw> i'm not clear why this needs to break freeze, so yeah. i don't claim to completely understand it, but it feels -1.
20:14:23 <jreznik> -1
20:14:33 <nirik> -1
20:15:02 <tflink> proposed #agreed 872162 - RejectedNTH - This involves VM creation which is not likely to affect live images and isn't the default path for VM creation anyways. It could be fixed with an update and doesn't need to be pulled past freeze.
20:15:22 <nirik> ack
20:15:34 <adamw> ack
20:15:44 <jreznik> ack
20:16:10 <tflink> #agreed 872162 - RejectedNTH - This involves VM creation which is not likely to affect live images and isn't the default path for VM creation anyways. It could be fixed with an update and doesn't need to be pulled past freeze.
20:16:18 <tflink> #topic (884878) FirewallConfig in imgcreate/kickstart.py requires FirewallD
20:16:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=884878
20:16:23 <buggbot> Bug 884878: unspecified, unspecified, ---, bcl, NEW , FirewallConfig in imgcreate/kickstart.py requires FirewallD
20:16:24 <tflink> #info Proposed NTH, livecd-tools, NEW
20:17:26 <adamw> i guess i'm +1 to tweaking the scripts so spins can use static firewalling if they want, for f18 at least, if it's not too messy
20:17:34 <adamw> we can always roll back if the fix is screwed
20:18:21 <tflink> yeah, I'd be OK with this
20:18:37 <nirik> yep. +1
20:18:41 * tflink still doesn't fully understand how firewalld is better than iptables
20:18:51 <adamw> it has a D in the name!
20:19:01 <nirik> it's a floor wax and a dessert topping!
20:19:02 <adamw> 100% more D-ness
20:19:22 <tflink> proposed #agreed 884878 - AcceptedNTH - Enabling spins to ship without firewalld is desirable as long as the fix isn't too bad. A tested fix would be considered past freeze.
20:19:29 <adamw> ack
20:19:44 <tflink> it seems like a huge mess for little benefit
20:19:45 <nirik> ack
20:19:53 <tflink> #agreed 884878 - AcceptedNTH - Enabling spins to ship without firewalld is desirable as long as the fix isn't too bad. A tested fix would be considered past freeze.
20:20:01 <tflink> #topic (821221) ibus-setup language selection entries shadowed out
20:20:01 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=821221
20:20:01 <tflink> #info Proposed NTH, oxygen-gtk3, NEW
20:20:04 <buggbot> Bug 821221: medium, unspecified, ---, rdieter, NEW , ibus-setup language selection entries shadowed out
20:21:36 <tflink> hrm, probably should have marked this as needing more info
20:21:46 <tflink> I'd be ok with +1 in theory but the fix isn't clear
20:23:10 <adamw> reads
20:23:17 <tflink> wasn't there another bug about this, too?
20:23:24 <tflink> or something that was at least similar?
20:23:58 <adamw> hum, i don't recall another
20:24:04 <nirik> more pygobject3 stuff
20:24:05 <nirik> ?
20:24:25 <tflink> there was another bug about ibus and kde, I think
20:24:25 <nirik> anyhow, this looks kinda cosmetic... not good or ideal, but workaroundable.
20:24:31 <nirik> and fixable in updates?
20:24:35 <adamw> on the merits i'm ok with +1 if the fix is simple, it's a clear ui bug that presumably affects the lives
20:24:39 <adamw> well, livs
20:24:40 <adamw> live*
20:24:57 <tflink> I didn't think that the KDE lives even had IMEs in them
20:25:05 <tflink> which was part of the problem in the other bug
20:25:30 <tflink> something about the gnome ibus stuff being used instead of kde stuff since the IME things were trimmed from the live for space reasons
20:26:06 <adamw> ah
20:26:09 <adamw> then i'd be -1...
20:26:16 <adamw> yeah i remember that bug too
20:26:26 * adamw sees if he has a kde live lying around
20:28:10 * nirik is a weak -1 I guess.
20:28:22 <adamw> holy mother of god, kde has too many config options.
20:28:49 <tflink> I thought that was one of their selling points
20:28:55 <adamw> yeah, i can't seem to find any kind of ibus stuff in kde live.
20:29:11 <adamw> tflink: it sells to people with too much time on their hands, apparently
20:29:22 <adamw> since this doesn't affect lives, -1 i guess
20:29:42 <tflink> proposed #agreed 821221 - RejectedNTH - There appear to be no extra IMEs on the KDE live media and thus, this would not affect lives and could be fixed with an update.
20:30:13 <rdieter> kde live is expressly non-multilingual
20:30:19 <rdieter> fwiw
20:30:35 <adamw> rdieter: so you think this is the right call?
20:30:39 <rdieter> though our excuse "for space reasons" doesn't fly anymore, but that's our story and we're sticking to it
20:30:50 <adamw> heh. wilful denial of reality, i like it.
20:30:59 <adamw> you should get a job setting the fedora release schedule.
20:30:59 <rdieter> adamw: right call (for now), yes.  +1
20:31:06 <adamw> ack
20:32:30 <tflink> other ack/nak/patch?
20:32:40 <tflink> only 5 more bugs left today!
20:32:43 <tflink> after this one
20:33:05 <adamw> is that the dledford clump?
20:33:32 <tflink> oh, 5 + clump
20:35:58 <tflink> #agreed 821221 - RejectedNTH - There appear to be no extra IMEs on the KDE live media and thus, this would not affect lives and could be fixed with an update.
20:36:08 <tflink> #topic (875430) After installing unable to boot Fedora 18 with virtio-scsi after successfully installing using virtio-scsi driver (have to use virtio-blk to boot)
20:36:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875430
20:36:13 <buggbot> Bug 875430: urgent, unspecified, ---, virt-maint, NEW , After installing unable to boot Fedora 18 with virtio-scsi after successfully installing using virtio-scsi driver (have to use virtio-blk to boot)
20:36:14 <tflink> #info Proposed NTH, qemu, NEW
20:37:37 <adamw> seems like install failing with a particular kvm storage driver?
20:37:39 <adamw> not the default one
20:37:43 <tflink> yeah
20:37:46 <adamw> i guess +1 since it probably can't be fixed with an update, if the fix is simple
20:39:07 <nirik> ok, +1
20:40:35 <tflink> proposed #agreed 875430 - AcceptedNTH - Allowing non-primary storage drivers in a VM would be preferred and a relatively small, tested fix would be considered past freeze.
20:40:58 <adamw> ack
20:41:01 <nirik> ack
20:41:04 <jreznik> ack
20:41:29 <tflink> #agreed 875430 - AcceptedNTH - Allowing non-primary storage drivers in a VM would be preferred and a relatively small, tested fix would be considered past freeze.
20:41:37 <tflink> #topic (886208) systemd should mount efivarfs by default on UEFI machines
20:41:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886208
20:41:42 <buggbot> Bug 886208: unspecified, unspecified, ---, systemd-maint, NEW , systemd should mount efivarfs by default on UEFI machines
20:41:43 <tflink> #info Proposed NTH, systemd, NEW
20:43:40 <tflink> this is another bug about signing your own shim, I think
20:44:52 <adamw> oh good timing, i just talked to lennart about this one
20:45:03 <tflink> cool, what did he say?
20:45:20 <adamw> oh wait no i didn't. :)
20:45:51 <tflink> confusion reigns!
20:45:58 <adamw> i got mixed up between two tabs
20:46:33 <tflink> I think I'm -1 NTH on this but I don't remember how we handled the last signing bug
20:47:56 <tflink> oh, we took it as NTH
20:47:57 <adamw> i'm probably -1
20:48:02 <adamw> what was the last one?
20:48:07 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=886199
20:48:09 <buggbot> Bug 886199: unspecified, unspecified, ---, mjg59, ON_QA , mokutil calculates incorrect signature size
20:48:09 <adamw> and what was I smoking at the time?
20:48:27 <tflink> can't help you on that one :)
20:48:29 <adamw> oh, we had that pjones input on that one
20:48:58 <jreznik> yep
20:49:14 <adamw> josh says this one could go out as 0-day, and we're later in the cycle now, so i'm okay with -1.
20:49:37 <jreznik> ok, -1
20:49:42 * nirik nods, -1
20:50:22 <tflink> why was I +1 NTH on that last one?
20:50:28 <tflink> oh well
20:51:15 <tflink> proposed #agreed 886208 - RejectedNTH - This wouldn't affect the released version of F18 since it's for personal/private signing of shim and could be fixed with an update.
20:51:35 <jreznik> ack
20:51:55 <adamw> tflink: because of what pjones said probably.
20:51:56 <adamw> ack
20:52:16 <tflink> #agreed 886208 - RejectedNTH - This wouldn't affect the released version of F18 since it's for personal/private signing of shim and could be fixed with an update.
20:56:04 <tflink> #topic (879922) Fails to open from the Xfce menu.
20:56:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=879922
20:56:04 <tflink> #info Proposed NTH, xfce4-panel, NEW
20:56:07 <buggbot> Bug 879922: unspecified, unspecified, ---, kevin, NEW , Fails to open from the Xfce menu.
20:56:13 <nirik> ah yeah, this one
20:56:51 * nirik was waiting to hear if we could set StartupNotify=true
20:57:43 <tflink> it sounds like a NTH either way, though
20:57:52 <tflink> something that would block release on a primary DE?
20:58:02 <adamw> yeah, the issue is NTH on its merits
20:58:14 <adamw> setting startupnotify=true sounds like an ugly workaround not a fix, but that's just the monkey talking
20:59:03 <adamw> +1 in any case
20:59:18 * nirik will abstain since I'm involved here. ;)
20:59:26 <tflink> wait, I thought that the system-config-* stuff was going away
20:59:35 <adamw> it's been going away for the last decade
20:59:35 <tflink> or am I getting multiple things confused?
20:59:40 <nirik> some of it is... slowly.
20:59:43 <adamw> and shows all signs of a strong upcoming decade of continuing to be going away.
20:59:49 * nirik nods
21:00:00 <tflink> but it's still the default for xfce?
21:00:15 <adamw> they're still used in gnome for some stuff. they're really not at all obsolete.
21:00:26 <adamw> does xfce have a native applet for this?
21:00:30 * jreznik has killed a few s-c-* :)
21:00:39 <nirik> not for date I don't think.
21:01:05 <tflink> proposed #agreed 879922 - AcceptedNTH - Prevents system-config-date from working on XFCE which is the default date config mechanism for XFCE.
21:02:25 <adamw> ack
21:02:52 <tflink> #agreed 879922 - AcceptedNTH - Prevents system-config-date from working on XFCE which is the default date config mechanism for XFCE.
21:03:01 <tflink> #topic (849347) radeon driver cannot handle restarting xorg server sometimes (fails with: *ERROR* Failed to parse relocation -35!)
21:03:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849347
21:03:06 <buggbot> Bug 849347: high, unspecified, ---, xgl-maint, NEW , radeon driver cannot handle restarting xorg server sometimes (fails with: *ERROR* Failed to parse relocation -35!)
21:03:06 <tflink> #info Proposed NTH, xorg-x11-drv-ati, NEW
21:04:08 <tflink> I think this isn't common enough to justify NTH
21:04:45 <adamw> eh, bit late to be taking non-showstoppers for NTH at this point
21:04:46 <adamw> yeah
21:04:53 <adamw> it's not even a showstopper, only happens on restarting X
21:05:02 <adamw> so the impact on lives is small and install non-existent...
21:05:15 * nirik is -1
21:05:17 <jreznik> definitely -1
21:05:18 <adamw> -1
21:06:21 <tflink> proposed #agreed 849347 - RejectedNTH - This seems rather limited in the HW affected and doesn't happen all of the time - it's too late in the release process to be taking non-showstopper bugs for F18.
21:06:43 <jreznik> ack
21:06:44 <adamw> ack
21:06:46 <nirik> ack
21:07:10 <tflink> #agreed 849347 - RejectedNTH - This seems rather limited in the HW affected and doesn't happen all of the time - it's too late in the release process to be taking non-showstopper bugs for F18.
21:08:28 <tflink> I think we can take the last 4 as a group since they're related
21:08:55 <jreznik> group it, time to leave :)
21:09:46 <adamw> yup
21:09:53 <adamw> i have a mail from dledford for justification
21:10:00 <tflink> #topic (816073, 820154, 816389, 884274) rdma and srptools for F18
21:10:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=816073
21:10:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=820154
21:10:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=816389
21:10:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=884274
21:10:01 <buggbot> Bug 816073: high, unspecified, ---, dledford, ON_QA , failing reload-or-restart and reload-or-try-restart
21:10:05 <buggbot> Bug 820154: urgent, unspecified, ---, dledford, ON_QA , provide a native systemd unit file
21:10:06 <buggbot> Bug 816389: unspecified, unspecified, ---, dledford, ON_QA , ifcfg-ib / if-up breaks with valid ifcfg-ib0
21:10:06 <tflink> #info Proposed NTH, ON_QA
21:10:07 <buggbot> Bug 884274: urgent, unspecified, ---, dledford, ON_QA , provide a native systemd unit file
21:10:29 <tflink> adamw: I think you've been following this more than I have - I saw the email but haven't read it in depth yet
21:10:52 <adamw> well it boils down to be pretty simple
21:11:36 <adamw> this is support for fairly exotic storage (infiniband i believe)
21:11:48 <adamw> dledford wants to convert it to systemd so he isn't stuck maintaining sysv init throughout f18 cycle
21:11:54 <tflink> infiniband isn't storage, though
21:11:59 <adamw> d'oh.
21:12:00 <adamw> sorry.
21:12:09 <tflink> ib is a form of low-latency network
21:12:14 * nirik nods
21:12:25 <adamw> https://en.wikipedia.org/wiki/InfiniBand for idiot monkeys
21:12:26 <tflink> most common usage is in large computing clusters
21:12:26 <adamw> alright
21:12:43 <adamw> so, again, fundamental point - not going to break anything massively commonly used
21:12:45 <tflink> IIRC, it's faster than 10 gig ethernet
21:13:13 <adamw> by update policy, you can't switch from sysv to systemd with a post-release update - you're stuck with whatever you start the release with
21:13:36 <adamw> he already did all the conversion to systemd and wanted to get it in f18, but the update didn't get pushed before the freeze date. if we deny this he'll have to revert it all to sysv and unpush the update and do it again
21:14:06 <adamw> given that converting to systemd is a Good Thing, dledford knows what he's doing, and anyone using infiniband is likely grown-up enough to work around any teething issues, i'm okay with +1
21:14:11 <nirik> given that it's a kind of corner case, I'd be +1 to pulling it, provided there's enough karma. ;)
21:14:24 <tflink> yeah, I'm OK with +1 NTH
21:14:34 <adamw> the other thing in the update is a security fix, never bad to pull them into freeze
21:14:50 <tflink> ib is interesting but really expensive :-/
21:15:36 <adamw> so +1.
21:15:50 <adamw> i can sort out sensible responses to each particular bug, all the boring bureaucracy
21:16:46 <tflink> proposed #agreed 816073, 820154, 816389, 884274 - AcceptedNTH - Due to the nature of these changes, they cannot be pushed post-release due to updates policy, are unlikely to break anything else and contain security fixes. Builds would be considered past freeze if they had enough karma.
21:16:57 <nirik> ack
21:17:26 <adamw> ack
21:17:27 <tflink> #agreed 816073, 820154, 816389, 884274 - AcceptedNTH - Due to the nature of these changes, they cannot be pushed post-release due to updates policy, are unlikely to break anything else and contain security fixes. Builds would be considered past freeze if they had enough karma.
21:17:51 <tflink> that was the last of my list for today
21:18:01 <tflink> time for confetti!
21:18:02 <adamw> hoooray
21:18:03 <tflink> and cake
21:18:09 <jreznik> and hooome
21:18:14 <adamw> still 9 proposed blockers :/
21:18:24 <adamw> some of them might go away though.
21:18:28 <tflink> #topic next review meeting
21:18:32 <nirik> sheesh.
21:18:48 <tflink> as much as I'd like to do another review meeting tomorrow, I'm not sure if we'll have enough people
21:19:12 <adamw> i'll try to get people to karma stuff and do a stable push today
21:19:15 <adamw> should clean up the lists quite a bit
21:19:28 * nirik is happy to help push a karmaed stable list.
21:19:30 <tflink> I'm going to be unavailable for a meeting from about 17:00 until 23:00 tomorrow
21:19:33 <tflink> UTC
21:19:49 * nirik will be also not around from about the same period. ;)
21:19:53 <tflink> so if someone else wants to lead and there are enough other people around, that oculd work
21:20:02 <adamw> i can lead if we need to have one
21:20:10 <tflink> or we can just play it by ear
21:20:12 <adamw> i guess we'll need to make a call if we're making some sort of hero push for friday or just giving up
21:20:13 <adamw> yeah
21:20:16 <adamw> see how things look later
21:20:27 <nirik> how much more needs going over?
21:20:37 <nirik> 9 proposed blockers and anything that shows up?
21:20:55 <adamw> tflink: why wasn't https://bugzilla.redhat.com/show_bug.cgi?id=882976 on the list for discussion?
21:20:55 <tflink> #info the next blocker/nth review meeting will be scheduled as needed - maybe tomorrow or friday
21:20:57 <buggbot> Bug 882976: medium, unspecified, ---, ajax, MODIFIED , Pixman/Cairo leaks like crazy
21:21:05 <adamw> info is present, update is submitted...
21:21:07 <tflink> it is on the list, did I skip it?
21:21:12 <adamw> i don't recall us discussing it
21:21:16 <adamw> did i miss it?
21:21:37 <adamw> doesn't show in the log
21:21:50 <tflink> I could have skipped it by accident
21:22:00 <tflink> #topic (882976) Pixman/Cairo leaks like crazy
21:22:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882976
21:22:00 <tflink> #info Proposed NTH, pixman, MODIFIED
21:22:01 <buggbot> Bug 882976: medium, unspecified, ---, ajax, MODIFIED , Pixman/Cairo leaks like crazy
21:22:04 <adamw> +1 blocker, memory leaks are bad.
21:22:08 <adamw> the update looks nice and restricted.
21:22:14 <tflink> true but it's only fallback
21:22:34 <adamw> still, we do have people in fallback
21:22:39 <adamw> oh, not blocker
21:22:41 <adamw> +1 nth, sorry
21:22:54 <tflink> I'm not -1 on it, just not very strongly +1
21:23:06 <nirik> +1 here as well I guess... wonder if it affects evo in other DE's
21:23:55 <tflink> proposed #agreed 882976 - AcceptedNTH - Memory leaks are bad and this could affect live images, making it not possible to fix with an update in all cases. A tested fix would be considered past freeze.
21:23:58 <adamw> ack
21:24:05 <nirik> ack
21:24:13 <tflink> #agreed 882976 - AcceptedNTH - Memory leaks are bad and this could affect live images, making it not possible to fix with an update in all cases. A tested fix would be considered past freeze.
21:24:27 <tflink> OK, I hope that was the only bug on my list that I skipped over
21:24:44 <tflink> #topic Open Floor
21:24:57 <adamw> i don't see any others at a glance
21:24:58 <tflink> Any topics to bring up here to make the meeting last even longer?
21:25:01 <tflink> :)
21:25:40 <jreznik> we should also do the overview what's still missing to make RC... but after adamw's stable cleanup
21:25:53 <nirik> yeah, figure out chances of a rc
21:26:14 <tflink> my gut says the chances are slim this week :-/
21:26:16 <jreznik> otherwise it does not make sense to push on early jan go/no-go
21:26:32 <tflink> I'd be happy to be wrong, though
21:26:34 <jreznik> tflink: it does not look as bad from current blocker list
21:26:43 <jreznik> (accepted part)
21:26:55 <nirik> I guess we can see in the next day or two
21:26:59 <tflink> yep
21:27:33 <jreznik> just pinged #anaconda about this one - 875944 - I don't see any movement
21:27:33 <tflink> anyhow, we're at ~ 5.5 hours today so unless there are other topics, I'll set the fuse for some amount of time
21:28:24 <jreznik> 876716 should be ok with cracklib, 879187 sbueno should be working on this one today
21:28:45 <jreznik> and of course fedup-dracut
21:29:12 <tflink> yeah, I'd like to see more testing with fedup
21:29:39 <jreznik> so we can skip regular review meeting today and do a quick sync-up even with less folks, even for fedup you would be really welcomed...
21:29:52 <tflink> ?
21:29:53 <jreznik> if you could sum up current testing, it would be great
21:30:03 <tflink> isn't this the regular review meeting?
21:30:17 <jreznik> tflink: tmrw, sorry :) too late here
21:30:22 <tflink> no worries
21:31:07 <tflink> anyhow, I think we can continue conversation in qa
21:31:12 <jreznik> adamw: would it work for you? quick sync-up instead of regular review blocker one tmrw? at least to know the chances
21:31:15 <jreznik> tflink: yep
21:31:21 <adamw> sure
21:31:22 <tflink> Thanks for coming and hanging in through the log meeting everyone!
21:31:35 * tflink will send out minutes shortly
21:31:44 <tflink> #endmeeting