18:33:07 <tflink> #startmeeting f18final-blocker-review-7
18:33:07 <zodbot> Meeting started Fri Dec 21 18:33:07 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:33:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:33:08 <tflink> #meetingname f18final-blocker-review-7
18:33:08 <zodbot> The meeting name has been set to 'f18final-blocker-review-7'
18:33:08 <tflink> #topic Roll Call
18:33:26 <tflink> who's ready for some impromptu blocker review?
18:34:02 <adamw> yo
18:34:18 <tflink> #chair adamw
18:34:18 <zodbot> Current chairs: adamw tflink
18:34:36 * satellit_e listening
18:35:30 * jreznik is on extremly slow network but I can't imagine something slower than bz, so it should work somehow
18:35:58 <tflink> jreznik: are you saying that bz tends to be slow some times?
18:36:19 <adamw> that's unpossible!
18:37:26 * nirik is here.
18:37:27 * fenrus02 waves
18:37:46 <tflink> sounds like we have enough to get started with the always popular and extremely exciting boilerplate
18:37:56 <tflink> #topic Introduction
18:38:03 <tflink> Why are we here?
18:38:03 <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.
18:38:11 <tflink> #info We'll be following the process outlined at:
18:38:11 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
18:38:16 * Martix_N9 is here
18:38:56 <tflink> #info The bugs currently proposed as blocker or NTH are available at:
18:38:56 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
18:39:39 <tflink> #info The bugs currently queued for discussion are listed at:
18:39:39 <tflink> #link http://tflink.fedorapeople.org/blockerbugs/sorted/blocker_bugs.html
18:39:42 <tflink> #link http://tflink.fedorapeople.org/blockerbugs/sorted/nth_bugs.html
18:39:46 <tflink> #info The criteria for release blocking bugs can be found at:
18:39:46 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
18:39:46 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
18:39:46 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
18:40:03 <tflink> #info At the moment, the total number of blocker/nth bugs is:
18:40:10 <tflink> #info 14 Proposed Blockers
18:40:10 <tflink> #info 13 Accepted Blockers
18:40:10 <tflink> #info 12 Proposed NTH
18:40:10 <tflink> #info 27 Accepted NTH
18:40:25 <tflink> #info Queued for discussion today are:
18:40:28 <tflink> #info 8 Proposed Blockers
18:40:28 <tflink> #info 23 Proposed NTH
18:40:46 <tflink> huh, that doesn't seem right
18:42:00 <adamw> we should probably go through all the proposed blockers today.
18:42:04 <adamw> no 'ready for discussion' filtering.
18:42:12 <tflink> works for me
18:42:15 * nirik nods
18:42:19 <tflink> give me one second to regenerate the list
18:42:37 * bcl waves
18:42:53 <tflink> #undo
18:42:53 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x15e2f410>
18:42:54 <tflink> #undo
18:42:54 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x15e2f510>
18:42:57 <tflink> #info 8 Proposed Blockers
18:42:57 <tflink> #info 10 Proposed NTH
18:43:03 * adamw notes bcl preparing the BIG RED NO hammer
18:43:24 <tflink> any objections to starting with the proposed blockers?
18:43:31 <tflink> without the "discussion" filter?
18:43:56 <tflink> #topic (889101) AttributeError: 'NoneType' object has no attribute 'removeMember'
18:43:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889101
18:44:00 <buggbot> Bug 889101: unspecified, unspecified, ---, dlehman, ASSIGNED , AttributeError: 'NoneType' object has no attribute 'removeMember'
18:44:01 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:44:53 <fenrus02> sounds like this was already patched?  which version of anaconda does the patch land in?
18:45:04 <tflink> the patch is ready, not in a build yet
18:45:45 <tflink> it's not clear what the problem actually is but the situation doesn't sound unreasonable and crashes are obviously bad
18:46:13 <jreznik> looking on the reproducer - the first one is quite unrealistic, second one looks more like a problem
18:46:23 * nirik is with jreznik
18:46:30 <tflink> yeah, I was thinking more of the second one
18:46:58 <tflink> dlehman: are there other situations you can think of where a user might hit 889101?
18:47:28 <tflink> at least NTH, leaning towards +1 blocker
18:47:28 <adamw> the reproducer seems like a sane case to me
18:47:35 <adamw> ditto
18:48:05 <dlehman> yeah, it's just adjusting the disk set of a raid device
18:48:20 <dlehman> pretty basic functionality for this ui
18:48:24 <nirik> ok, +1 then
18:48:26 <tflink> proposed #agreed 889101 - AcceptedBlocker - Violates the following F18 final release criterion: "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"
18:48:34 <jreznik> dlehman: thanks, +1 blocker
18:48:49 <jreznik> ack
18:49:03 <bcl> ackack
18:49:07 <nirik> ack
18:49:13 <tflink> #agreed 889101 - AcceptedBlocker - Violates the following F18 final release criterion: "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"
18:49:18 <tflink> #topic (873468) F18 Beta TC7: sometimes when booting netinst, hub comes up showing 'Nothing selected' for Installation Source and Software Selection
18:49:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873468
18:49:23 <buggbot> Bug 873468: unspecified, unspecified, ---, rvykydal, ASSIGNED , F18 Beta TC7: sometimes when booting netinst, hub comes up showing 'Nothing selected' for Installation Source and Software Selection
18:49:24 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:49:50 <tflink> this sounds like the last report is a bit different from the original
18:50:13 <tflink> not sure that issues with slower than expected dhcp on ipv6 are enough to block release over
18:50:32 <tflink> +1 nth, leaning towards -1 blocker
18:50:45 <bcl> I'd be +1 NTH. It doesn't always happen.
18:51:15 <jreznik> +1 nth, -1 blocker
18:51:44 <adamw> yeah, with current info
18:51:54 <nirik> yep. same here.
18:51:55 <adamw> though i haven't done many metal tests of final yet to see if i reproduce this
18:51:55 <tflink> proposed #agreed 873468 - RejectedBlocker AcceptedNTH - This doesn't happen all the time and seems to be limited to slower than expected dhcp with ipv6, not enough to justify blocking release over. However, it can't be fixed with an update and a tested fix would be considered past freeze.
18:52:05 <nirik> ack
18:52:10 <jreznik> ack
18:52:15 * nirik notes the 'workaround' could be documented if needed.
18:52:45 <tflink> proposed #agreed 873468 - RejectedBlocker AcceptedNTH - This doesn't happen all the time and seems to be limited to slower than expected dhcp with ipv6, not enough to justify blocking release over. However, it can't be fixed with an update and a tested fix would be considered past freeze. Should be at least documented as commonbugs if not fixed before release
18:52:49 <jreznik> mark it as commonbugs one in case we won't have nth fix?
18:53:25 <adamw> yeah
18:53:26 <adamw> ack
18:53:36 * tflink assumes that previous acks hold
18:53:37 * adamw might be a bit slow, juggling five things atm
18:53:42 <tflink> #agreed 873468 - RejectedBlocker AcceptedNTH - This doesn't happen all the time and seems to be limited to slower than expected dhcp with ipv6, not enough to justify blocking release over. However, it can't be fixed with an update and a tested fix would be considered past freeze. Should be at least documented as commonbugs if not fixed before release
18:53:52 <tflink> #topic (889330) crash when reclaiming space from disk containing member of incomplete md raid0
18:53:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889330
18:53:56 <buggbot> Bug 889330: unspecified, unspecified, ---, dlehman, ASSIGNED , crash when reclaiming space from disk containing member of incomplete md raid0
18:53:57 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
18:54:30 <tflink> +1 blocker
18:54:54 * jreznik is waiting for bz
18:55:21 <bcl> +1 since there is a patch
18:55:26 <jreznik> +1 blocker
18:55:29 <tflink> proposed #agreed 889330 - AcceptedBlocker - Violation of the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
18:55:34 <jreznik> it's by dlehman so...
18:55:55 <nirik> ack
18:56:02 <nirik> and belated +1
18:57:07 <adamw> ack
18:57:19 <adamw> if we're gonna try and handle incomplete devices we should succeed
18:57:24 <jreznik> ack
18:57:26 <tflink> #agreed 889330 - AcceptedBlocker - Violation of the following F18 beta release criterion: "The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."
18:57:31 <adamw> dlehman: have you checked for analogous issues with LVM?
18:57:31 <tflink> #topic (886314) MDRaidError: md_node_from_name failed: [Errno 2] No such file or directory: '/dev/md/root'
18:57:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886314
18:57:36 <buggbot> Bug 886314: unspecified, unspecified, ---, anaconda-maint-list, NEW , MDRaidError: md_node_from_name failed: [Errno 2] No such file or directory: '/dev/md/root'
18:57:37 <tflink> #info Proposed Blocker, anaconda, NEW
18:58:15 <dlehman> adamw: yeah, that probably applies to lvm as well
18:58:38 <dlehman> adamw: the fix is generic so should apply to both lvm and md
18:58:46 <adamw> ah okay.
18:59:06 <bcl> I'm not sure which anaconda version he's using. initial report was 18.36 which is pretty old.
18:59:08 * dlehman tried to reproduce 886314 and was unsuccessful
18:59:19 <adamw> anyone else tried it?
18:59:30 <dlehman> I've done many raid0, raid1, and raid10 installs in the last two weeks with no issues
18:59:42 <adamw> softraid?
18:59:47 <tflink> I haven't tried it, no
19:00:31 <adamw> bob's is the only result in the matrices for tc1,2 aor 3
19:01:03 <dlehman> yeah
19:02:28 <tflink> it sounds like this needs more testing to confirm whether or not it's still an issue
19:02:28 <adamw> i'd incline to punt with specific action item to re-test like today
19:02:29 <adamw> or -1
19:02:39 <adamw> we should make a conditional decision if we punt
19:02:45 <adamw> so someone can just test it, and then change status
19:03:01 <adamw> dlehman: you can't get anything from the logs btw?
19:03:04 * nirik nods, -1 for now, revisit if a better reproducter can be found?
19:03:23 * jreznik trusts dlehman so -1
19:03:54 <bcl> -1 not reproducible
19:04:10 <adamw> i can go with that, but i'll try and reproduce to be safe
19:04:18 <adamw> oh hey - dlehman, were you testing i386?
19:04:27 <dlehman> adamw: nothing obvious. suspected kernel/udev/timing/bs
19:04:40 <dlehman> x86_64 in virt (qemu/kvm)
19:05:02 <adamw> could be an arch thing
19:05:04 <adamw> i'll try it 32-bit
19:05:08 <tflink> proposed #agreed 886314 - RejectedBlocker - It sounds like this issue is not reproducable on more recent versions and therefore rejected as a blocker for F18 final. Please re-propose if a reproducing case is discovered.
19:05:19 <jreznik> adamw: pls try, we can with rejected and it can be reproposed, thanks
19:05:26 <adamw> ack
19:05:26 <jreznik> ack
19:05:42 <nirik> ack
19:05:43 <bcl> ack
19:05:47 <tflink> #agreed 886314 - RejectedBlocker - It sounds like this issue is not reproducable on more recent versions and therefore rejected as a blocker for F18 final. Please re-propose if a reproducing case is discovered.
19:05:56 <tflink> #topic (887539) FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
19:06:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887539
19:06:01 <buggbot> Bug 887539: unspecified, unspecified, ---, anaconda-maint-list, NEW , FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
19:06:02 <tflink> #info Proposed Blocker, anaconda, NEW
19:08:01 <bcl> Isn't this a dupe? And wasn't wipefs part of the problem?
19:08:04 <tflink> the version is newer than the lvm which was part of fixing 876789
19:08:18 <tflink> er, version of lvm
19:08:27 <adamw> right, we asked steve to check that
19:08:31 <adamw> see the last couple comments
19:08:32 <dlehman> oh, this one was related to incomplete lvm IIRC
19:09:31 <adamw> hum. /me tries to wrap head around
19:10:04 <adamw> the reproducer seems to be have two disks, and install f18 to each one separately, without the other involved, then stick them both in one machine and try to install again over the top
19:10:07 <adamw> with both disks
19:10:13 <adamw> where does the incomplete lvm come from?
19:10:38 <adamw> i'm probably +1 nth, but unless it's a more general bug which might happen in other cases, seems a bit corner-y for blocker
19:11:24 <tflink> yeah, same here unless I'm missing something
19:11:33 <dlehman> yeah, our handling for duplicate device names isn't air tight, but you have to be a bit of a jerk to test it a lot
19:11:34 <nirik> yeah, same here... +1 nth, -1 blocker. again could document a workaround like wiping disks before install.
19:12:14 <jreznik> -1 blocker, steve is corner case bug genius I'd say
19:12:23 <adamw> ah, so it's because both installs have the same LVM name, i see
19:12:29 <adamw> so the hostname setting would also ameliorate this, right?
19:12:53 <adamw> so yeah, -1 blocker
19:12:57 <bcl> -1, -1
19:12:59 <tflink> proposed #agreed 887539 - RejectedBlocker AcceptedNTH - While nasty, this seems like too much of a corner case to block the release of F18. However, a tested fix would be considered past freeze. Workaround should be documented if not fixed before release
19:13:05 <jreznik> +1 nth more for better handling of duplicated
19:13:06 <bcl> this is pretty convoluted.
19:13:24 <nirik> ack
19:13:41 <nirik> yeah, we could as a workaround say 'if you do this corner case, at least name your hosts differently' :)
19:13:59 <jreznik> ack
19:14:27 <tflink> yeah, I'm not so strongly nth if this isn't general enough to apply outside of the case listed in the bug
19:14:55 <adamw> it's kinda hard to conceive of the possible cases here, but they do seem pretty small.
19:15:13 <tflink> that is very corner-casey - wipe your disks before installing if the host names are the same and you combine the disks
19:15:18 <adamw> bcl: still, even if we accept it as NTH, you can just choose not to fix it. simple. :)
19:15:34 * nirik would be ok dropping it as nth too.
19:15:37 <adamw> acceptednth isn't a mandate that you must work on a fix, just a stamp that we'd consider accepting one if it showed up.
19:15:41 <bcl> right, but it adds to the nth list without really needing to.
19:15:48 <jreznik> tflink: as I said I'm more fix handling...
19:15:53 <adamw> okay. if you have no intention of actually fixing it, i'm fine with -1 nth.
19:15:58 <nirik> yeah, and we have bigger^Wblocker fish to fry
19:16:13 <tflink> so, -1 overall?
19:16:16 <adamw> sure
19:16:25 <nirik> yeah.
19:17:10 <tflink> proposed #agreed 887539 - RejectedBlocker RejectedNTH - While nasty, this seems like too much of a corner case to block the release of F18. It also seems too much of a corner case to take as NTH for F18 - workaround should be documented (use different hostnames, wipe disks before install)
19:17:19 <nirik> ack
19:18:10 <adamw> ack
19:18:14 <adamw> bcl: moved the bug to rawhide
19:18:24 <jreznik> ack
19:18:26 <tflink> #agreed 887539 - RejectedBlocker RejectedNTH - While nasty, this seems like too much of a corner case to block the release of F18. It also seems too much of a corner case to take as NTH for F18 - workaround should be documented (use different hostnames, wipe disks before install)
19:18:31 <tflink> #topic (860022) AttributeError: preconf
19:18:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=860022
19:18:36 <buggbot> Bug 860022: unspecified, unspecified, ---, bcl, NEW , AttributeError: preconf
19:18:36 <tflink> #info Proposed Blocker, anaconda, NEW
19:19:18 <tflink> any thoughts on how likely users are to hit this? it still sounds a bit like a timing bug
19:19:30 <tflink> that is made more likely with the 9 repos reported
19:19:34 <nirik> 8 repos. wheee
19:19:50 <adamw> i'm at least +1 nth
19:19:54 <adamw> how safe is it to take the fix, bcl?
19:20:08 <tflink> it's already accepted as NTH
19:20:15 <adamw> oh ok
19:20:31 <tflink> we just weren't sure it was easy enough to hit to justify blocking release
19:20:40 <adamw> bit hard to have the data
19:20:48 <adamw> bcl: is there a reason this fix hasn't gone into any of the recent builds?
19:21:06 <bcl> not approved as far as I could see.
19:22:50 <bcl> The change is a bit larger than I'd like at this point, but the reporter has tested it and it worked for me in a number of normal case installs.
19:23:19 <adamw> it's accepted as nth
19:23:27 <adamw> by 'approved' you mean per anaconda processes?
19:23:47 <jreznik> I'd say so
19:24:45 <tflink> either way, probably not a blocker?
19:24:57 <adamw> i think it's kinda hard to make a call
19:25:05 <adamw> but on the basis no-one else seems to have hit it till now, i'd incline -1 blocker
19:25:19 <jreznik> ok, -1 blocker
19:25:24 <bcl> adamw: how can I know it is accepted as nth?
19:25:30 <adamw> on the one hand it'd be nice to take the fix, on the other this feels like that kind of bug where we take the fix and it explodes NFS installs or something
19:25:34 <tflink> bcl: AcceptedNTH in the whiteboard
19:25:35 <adamw> bcl: it has AcceptedNTH in the whiteboard
19:25:42 <adamw> and it's in the 'accepted NTH' list on current blockers page
19:26:04 <bcl> tflink: uhm, no. I see an abrt hash.
19:26:07 <adamw> things can be in two groups on that page - just because it's in 'proposed blockers' doesn't mean that's the *only* place it is
19:26:10 <tflink> bcl: it's at the end
19:26:10 <adamw> bcl: look behind the abrt hash
19:26:28 <adamw> it's the second bug in 'Accepted NTH' on the blocker list, too.
19:26:29 <bcl> ah. well. that's kinda useless.
19:26:44 <adamw> i could start putting them at the front but i was scared that might screw up abrt so i don't.
19:26:56 <bcl> oh. I was seeing it in proposed blocker and not looking further.
19:26:59 <jreznik> http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist
19:27:09 <jreznik> probably easiest way to have an overview
19:27:11 <adamw> bcl: yeah, the groups aren't exclusive
19:27:12 <tflink> jreznik: I think he knows about that - he's reported bugs :)
19:27:23 <tflink> bugs against the tracker app, I mean
19:27:30 <jreznik> tflink: ah ok :)
19:27:40 <bcl> ok, I'll add it to tonight's build then. Thanks.
19:27:48 <jreznik> then he should know it track NTHs too :)))
19:27:57 <bcl> adamw: If abrt can't parse it then file a bug :)
19:28:07 <adamw> anyhow, are we going with -1 blocker on this?
19:28:18 <bcl> jreznik: the whole tracking process confuses me.
19:28:34 <tflink> proposed #agreed 860022 - RejectedBlocker - This doesn't seem to be common enough to justify blocking the release of F18. It is already accepted as NTH and a tested fix would be considered past freeze.
19:28:41 <adamw> ack
19:28:54 <tflink> bcl: yeah, it can be a little complicated
19:29:08 <jreznik> bcl: same here sometimes, bz is not very suitable for such use cases
19:29:18 <adamw> bcl: it really does just boil down to four categories per release point, i think the only confusion here was that you didn't know bugs can be proposed blocker and accepted nth at the same time. they can.
19:29:21 <jreznik> ack
19:29:34 <nirik> ack
19:29:37 <tflink> adamw: and the whiteboard part can be easy to miss
19:29:45 <tflink> #agreed 860022 - RejectedBlocker - This doesn't seem to be common enough to justify blocking the release of F18. It is already accepted as NTH and a tested fix would be considered past freeze.
19:29:54 <adamw> tflink: well the blocker list app means you don't really need to worry about that
19:30:11 <adamw> tflink: he already checked the blocker list app, he just stopped reading when he saw it in 'proposed blockers'
19:30:37 <tflink> #topic (859867) Keyboard not set in minimal install
19:30:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=859867
19:30:38 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
19:30:40 <buggbot> Bug 859867: unspecified, unspecified, ---, vpodzime, ASSIGNED , Keyboard not set in minimal install
19:31:07 <adamw> i *think* we can close this one now
19:31:22 <adamw> it's gotten a bit confused over the last few days, there seem to be several outstanding keymap issues which are getting mixed up
19:31:52 <adamw> but i think the remaining problems here are either split into other bugs, or pebkac (some testers didn't know how the cz-lat2 keymap works)
19:32:04 <nirik> cool.
19:32:09 <tflink> I don't understand the details of what is going on, so I'll defer to your judgement
19:32:23 <tflink> all of the details, anyways
19:33:10 <adamw> erf, there's https://bugzilla.redhat.com/show_bug.cgi?id=859867#c7
19:33:13 <buggbot> Bug 859867: unspecified, unspecified, ---, vpodzime, ASSIGNED , Keyboard not set in minimal install
19:33:14 <jreznik> fair enough
19:33:20 <adamw> i'm guessing that's a case of 889562
19:33:28 <adamw> vpodzime is replying on bz but doesn't seem to be on irc which is annoying
19:33:32 <adamw> is anyone in yelling range?
19:33:47 <bcl> I think they're pretty much done for the year.
19:33:57 <adamw> weaklings.
19:34:01 <bcl> lol
19:34:11 <adamw> i mean, he's replied to this bug today
19:34:15 <adamw> but hasn't been on irc that whole time afaics
19:34:34 <adamw> anyway, yeah, i think we can say the actual bug this was covering is fixed
19:35:00 <jreznik> adamw: it's 20:30 here and he's on PTO already
19:35:07 <jreznik> msivak sits next to me :)
19:35:43 <jreznik> adamw: because he's already on PTO, the reason why was not online...
19:35:59 <tflink> so are we thinking that this should be closed or do we want to punt?
19:36:26 <adamw> i think it can be closed.
19:36:27 * jreznik is waiting for bz to load
19:37:13 <adamw> jreznik: he transmitted the bug comment via RFC 1149? :)
19:37:52 * jreznik is asking msivak right now but he does not have any more info on this one
19:38:08 <jreznik> if you think it's closeable, close it
19:38:15 <tflink> #info the original report appears to be fixed and somewhat confused with other unrelated keymap issues. The bug will be closed but can be reopened if the original issue still exists
19:38:21 <tflink> unless we wanted to vote on it
19:38:25 * tflink can #undo
19:38:31 <adamw> basically this bug was being treated as covering the thing fixed in https://bugzilla.redhat.com/show_bug.cgi?id=859867#c3
19:38:33 <buggbot> Bug 859867: unspecified, unspecified, ---, vpodzime, ASSIGNED , Keyboard not set in minimal install
19:38:43 <adamw> i'm 99% sure all issues reported since then are separate bugs
19:39:12 <adamw> c#7 is the only one i'm not sure of; i'd guess it's a case of 889562, but i don't know how to test to make sure
19:39:41 <adamw> i don't know how you feed systemd-localed an X keymap and find out if it'll tell you the matching console keymap, which is what you need to do to find out if a bug is a case of 889562, aiui.
19:40:48 * tflink assumes that no complaints means no objections
19:40:54 <tflink> moving on ...
19:40:59 <tflink> #topic (889044) need to disable updates-testing for final
19:40:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889044
19:40:59 <tflink> #info Proposed Blocker, fedora-release, ON_QA
19:41:01 <buggbot> Bug 889044: unspecified, unspecified, ---, dennis, ON_QA , need to disable updates-testing for final
19:41:41 <tflink> I don't know what criterion we usually use for this, but +1 blocker since it needs to happen before release and before RCs
19:41:47 <bcl> does that also include flipping the release switch?
19:41:49 <jreznik> that's clear +1
19:42:04 <tflink> I think that usually happens with RC1, no?
19:42:42 <tflink> has the updates repo been populated yet?
19:42:43 <bcl> I've only been paying attention to smoke builds :)
19:43:03 <bcl> but I'm +1 on this
19:43:27 <adamw> +1`
19:43:51 <adamw> it wouldn't get truly populated till after go/no-go
19:43:53 <adamw> (iirc)
19:43:56 <nirik> updates is not populated until we are go.
19:44:02 <nirik> +1 on this
19:44:03 <adamw> but we usually stick a dummy package in there or something don't we, to avoid errors?
19:44:08 <tflink> proposed #agreed 889044 - AcceptedBlocker - While this doesn't directly violate any release criteria, it is part of the final release process and has to be finished before F18 is released
19:44:13 <nirik> it has empty repodata.
19:44:14 <adamw> ack
19:44:24 <nirik> ie, it's there, and valid, but has 0 packages in it.
19:44:26 <nirik> ack
19:44:32 <tflink> doesn't that make it unwise to turn off updates-testing right now, then?
19:44:48 <nirik> why?
19:45:01 <tflink> no updates until after go/no-go?
19:45:04 <nirik> updates/18/x86_64                                 Fedora 18 - x86_64 - Updates                                 0
19:45:11 <tflink> except for blocker/nth fixes
19:45:20 <tflink> eh, I suppose it doesn't matter all that much
19:45:28 * nirik doesn't get what the issue could be.
19:46:23 <adamw> yeah, me either
19:46:29 <tflink> making it more difficult to get update-worthy but not blocker or nth updates?
19:46:52 <tflink> I suppose you should probably know what updates-testing is if you're isntalling and using before actual release
19:47:04 <nirik> well, it would be a big hassle to have both updates and base repo promotion going at the same time.
19:47:05 <tflink> depends on if we slip and for how long if that does happen
19:47:18 <nirik> yeah.
19:47:38 <nirik> if you are trying to get the release out you should either reenable updates-testing or pick updates from there you want to test/karma
19:47:51 <tflink> oh, I wasn't suggesting that updates be populated, just wondering if it was a bit early to disable updates-testing
19:48:09 <tflink> but that's been done already and not a big enough concern to change anything at this point
19:48:32 <tflink> or discuss changes, even :)
19:48:40 <tflink> #topic (881624) After Update using fedup default system keyboard changes to US
19:48:42 <nirik> right, lets move on. ;)
19:48:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
19:48:45 <buggbot> Bug 881624: medium, unspecified, ---, wwoods, NEW , After Update using fedup default system keyboard changes to US
19:48:46 <tflink> #info Proposed Blocker, fedup, NEW
19:48:46 <adamw> tflink: btw there is a criterion for the updates-testing thing
19:48:47 <tflink> damnit
19:48:51 <tflink> #undo
19:48:51 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x21dc0d50>
19:48:54 <tflink> #undo
19:48:54 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x21dc0850>
19:48:54 <adamw> tflink: final criterion #25
19:48:55 <tflink> #undo
19:48:55 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x21dc0250>
19:49:03 <adamw> i put it in the bug comment, no biggy
19:49:12 <tflink> no agreed
19:49:14 * adamw goes for a valgrind check
19:49:24 <tflink> still waiting for another ack
19:50:00 <jreznik> ah, /me is confused now
19:50:09 <tflink> proposed #agreed 889044 - AcceptedBlocker - Violates the following F18 final release criterion: "A Package-x-generic-16.pngfedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned Package-x-generic-16.pnggeneric-release package must be available in the online release repository"
19:50:21 <tflink> fail
19:50:23 <tflink> #undo
19:50:23 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x30d49b90>
19:51:20 <tflink> #agreed 889044 - AcceptedBlocker - Violates the following F18 final release criterion: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository"
19:51:41 <tflink> #topic (881624) After Update using fedup default system keyboard changes to US
19:51:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881624
19:51:46 <buggbot> Bug 881624: medium, unspecified, ---, wwoods, NEW , After Update using fedup default system keyboard changes to US
19:51:46 <tflink> #info Proposed Blocker, fedup, NEW
19:52:12 <tflink> sounds like this might not be an issue any more
19:52:23 <tflink> but I haven't gotten around to trying it yet
19:52:48 <nirik> so, does this need changes in fedup? or fedup-dracut?
19:53:41 <tflink> probably fedup-dracut
19:53:56 <nirik> ok.
19:54:05 <tflink> well, if it's really a fedup isue
19:54:21 <tflink> I'd suspect grub-related scripts first, though
19:54:22 * nirik just wonders that because fedup would be f17 and outside really our blockery... but fedup-dracut is the f18 one and would be
19:54:31 <tflink> newkernel-pkg is the script in question, I think
19:55:19 <adamw> i don't think this is fedup at all, see my comment
19:55:20 <adamw> but imbw
19:55:22 <tflink> but I haven't looked for recent changes in the grub.cfg generation
19:55:32 <tflink> adamw: I suspect you're right
19:56:19 <adamw> afaics 882212 was to fix this with package scripts, and if we fix it with package scripts, it should work for fedup. in general we're not supposed to add magic to fedup specifically if it can be done in the packages...
19:56:44 * nirik nods.
19:57:27 <tflink> thoughts on punt pending verification of suspicions or reject?
19:57:27 <jreznik> so close this one?
19:57:42 <adamw> there's one case i worry about here, so just a tick
19:58:21 <adamw> yeah...there's the https://bugzilla.redhat.com/show_bug.cgi?id=875567 problem, i think
19:58:23 <buggbot> Bug 875567: unspecified, unspecified, ---, vpodzime, MODIFIED , anaconda doesnt set keyboard layout for LUKS password at reboot
19:58:48 <adamw> apparently in f18 we need to stick 'vconsole.keymap=foo' on the kernel cmdline to get the right keymap during boot (so for luks password entry)
19:59:02 <adamw> 875567 achieves that during install, but i don't think we have anything to do it during upgrade?
19:59:11 <tflink> I doubt it
19:59:56 <adamw> god. keymaps.
20:00:22 <adamw> i suppose we need someone to do an install of f17 in french or something and then upgrade it to f18 with fedup with the latest systemd and see what happens...
20:00:29 <tflink> that would be a fun fix
20:00:51 <tflink> we should get a new upgrade.img with the next TC
20:01:02 <tflink> or I can do it with the next smoke
20:01:21 <tflink> sounds like punt for testing, though
20:01:48 <adamw> well
20:01:53 <adamw> if we assume it's broken: do we count that as a blocker?
20:02:01 <adamw> i guess it kinda sucks if you have an encrypted non-US install
20:02:34 <tflink> yeah, I'd lean towards +1 blocker
20:02:51 <nirik> so to clarify...
20:03:13 <jreznik> in that case yes, but let's test it first
20:03:14 <nirik> it's upgrades where you are non english and have a encrypted parition, you get en on boot instead of your $lang?
20:03:48 <tflink> no, you get en on boot instead of your $lang but it could prevent booting if your LUKS pw was not compatible with an en-US layout
20:04:15 <jreznik> well it's what nirik said
20:04:24 <tflink> er, the resetting of layout would happen every time - it just might not be a blocker if it didn't interfere with passwords
20:05:10 <tflink> if the systemd update doesn't fix this, anyways
20:05:22 <adamw> i'll test it
20:05:39 <adamw> i feel kinda +1 on it but i'm worried a go/no-go meeting would override us. but eh.
20:05:44 <tflink> I don't think we have a new-enough upgrade.img available right now
20:05:47 * adamw doing an f17 french install atm
20:05:47 * nirik almost thinks this could be a document and drive on, but I guess it could hit more people than I think
20:05:57 <tflink> adamw: x86_64?
20:06:01 <jreznik> so punt for now?
20:06:03 <adamw> yeah
20:06:09 <tflink> I can grab the upgrade.img from smoke10 and make it available
20:06:12 <adamw> i'd like punts to be conditional
20:06:26 <adamw> so can we say 'punt but if it's as adamw thinks, it's a blocker'?
20:06:30 <adamw> that way i can do the testing then set the status
20:06:45 <adamw> tflink: why does the upgrade.img matter?
20:07:02 <adamw> isn't all this in the package scripts? so it just depends what version of the packages the upgrade process pulls?
20:07:19 <tflink> depends on if you need a specific version of systemd running for the scripts
20:07:31 <tflink> the version of systemd used is in the upgrade.img
20:07:32 <jreznik> for this one the issue is luks with password with non en characters - well, I still think it's nonsense to use non en characters for password
20:07:43 <jreznik> and I'd like to know impact, how many people do this?
20:07:53 <nirik> no way to be sure. ;)
20:08:05 <adamw> jreznik: it's not just non-en characters
20:08:07 <nirik> also it's non us layouts.
20:08:13 <adamw> jreznik: the characters are in different places on different layouts
20:08:19 * nirik nods.
20:08:23 <adamw> go look at a French keyboard; the alphabet letters are in totally different places
20:08:54 <adamw> if you set your password as 'monkeys' on a French keyboard, then try and enter it after the layout switches to U.S., what you wind up typing will be like ;onkeys
20:08:58 <jreznik> adamw: fair enough for french one, still you can think about it... keyboard status should be visible
20:08:58 <tflink> proposed #agreed 881624 - Waiting for testing to confirm suspicions about this bug. If it turns out that the keymap is not correctly set after upgrade, this would be a blocker. If the systemd update fixes the issue to the point where passwords work with a non en-US keymap, it will be rejected as a blocker
20:09:16 <adamw> jreznik: other layouts have the same thing, french is just the easiest example
20:09:20 <adamw> what if you use dvorak?
20:09:27 <adamw> ack
20:10:02 <tflink> adamw: am I missing something about this, then? do you not need that systemd update during the package upgrade process?
20:10:37 <tflink> er, to be installed prior to the package upgrade process starting
20:10:43 <nirik> I guess ack.
20:10:54 <tflink> I just can't seem to communicate today :-/
20:11:09 <tflink> let's try this again:
20:11:28 <adamw> tflink: you'd need that systemd in the update package set, sure.
20:11:34 <adamw> tflink: what i don't understand is why that means we need a new upgrade.img .
20:12:01 <tflink> doesn't the systemd version running during the package update process need to match the update mentioned in bug 882212?
20:12:02 <adamw> oh, wait
20:12:03 <adamw> iswym
20:12:03 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=882212 unspecified, unspecified, ---, mschmidt, ON_QA , localectl set-x11-keymap: variant settings does not work
20:12:07 <adamw> it may be the case, yeah
20:12:29 <tflink> the systemd version used during upgrade is completely dependant on the version used to build the upgrade.img
20:13:25 <tflink> any more ack/nak/patch?
20:14:19 <jreznik> ack, just waiting to make the "how to test" clear not to accept it as blocker when not needed
20:14:39 <tflink> jreznik: is it clear enough now?
20:15:31 * tflink assumes so
20:15:50 <tflink> #agreed 881624 - Waiting for testing to confirm suspicions about this bug. If it turns out that the keymap is not correctly set after upgrade, this would be a blocker. If the systemd update fixes the issue to the point where passwords work with a non en-US keymap, it will be rejected as a blocker
20:16:01 <tflink> #topic (889109) missing dependencies for imsettings
20:16:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889109
20:16:02 <tflink> #info Proposed Blocker, imsettings, ON_QA
20:16:03 <buggbot> Bug 889109: unspecified, unspecified, ---, tagoh, ON_QA , missing dependencies for imsettings
20:16:05 <tflink> -1 blocker
20:16:17 <tflink> issue with updates-testing, not a release blocking issue
20:16:20 <jreznik> tflink: yep
20:16:25 <tflink> has already been fixed, AFAIK
20:16:29 <nirik> yep
20:16:32 <nirik> -1 blocker
20:17:02 <tflink> proposed #agreed 889109 - RejectedBlocker - This is a dep issue which was contained in updates-testing, has already been fixed and wouldn't affect the release of F18.
20:17:09 <jreznik> ack
20:17:23 <adamw> ack
20:18:12 <tflink> #agreed 889109 - RejectedBlocker - This is a dep issue which was contained in updates-testing, has already been fixed and wouldn't affect the release of F18.
20:18:16 <nirik> ack
20:18:17 <tflink> #topic (881670) Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
20:18:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=881670
20:18:21 <buggbot> Bug 881670: unspecified, unspecified, ---, systemd-maint, ASSIGNED , Provide fedup hook to add x-systemd.device-timeout=0 to mount options for encrypted file systems that need a passphrase from the user
20:18:23 <tflink> #info Proposed Blocker, systemd, ASSIGNED
20:18:56 <tflink> I think we still don't have enough information to make a full call on this one
20:19:10 <tflink> I don't think it passes the 'last blocker' test, though
20:20:10 <nirik> yeah, -1 blocker, +1 nth here.
20:20:55 * jreznik is with nirik
20:20:58 <adamw> yeah, i've been -1 on these in general
20:21:11 <adamw> kparal is pretty keenly +1 though
20:21:15 * adamw puts on kparal mask
20:21:19 <nirik> I mean it's not ideal... but...
20:21:26 <jreznik> kparal, who is he?
20:21:27 <adamw> +1 blocker! these prompts should never timeout!
20:21:54 <jreznik> well, my batter is about to die soon... so -1 and keep going, move on!
20:21:58 <adamw> his rationale is in the original comment
20:23:45 <tflink> proposed #agreed 881670 - RejectedBlocker AcceptedNTH - This doesn't seem severe enough to justify blocking the release of F18 but a tested fix would be considered after freeze.
20:23:52 <adamw> ack
20:23:57 <nirik> ack
20:24:00 <jreznik> ack
20:24:07 <tflink> #agreed 881670 - RejectedBlocker AcceptedNTH - This doesn't seem severe enough to justify blocking the release of F18 but a tested fix would be considered after freeze.
20:24:10 <tflink> 2 more blockers
20:24:16 <tflink> #topic (889562) Console keymap set to "us" if you install with a keymap not provided by systemd-localed
20:24:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889562
20:24:21 <buggbot> Bug 889562: unspecified, unspecified, ---, systemd-maint, NEW , Console keymap set to "us" if you install with a keymap not provided by systemd-localed
20:24:22 <tflink> #info Proposed Blocker, systemd, NEW
20:24:41 <nirik> more keymap fun
20:25:24 <tflink> it would be nice to know how many keymaps are affected by this
20:25:36 <nirik> yeah, I have no idea on the scope here. ;(
20:26:21 <adamw> i can't figure out how to derive the scope, yeah :/
20:26:28 <adamw> i wish vpodzime was around
20:26:35 <adamw> i'm doing my best but i'm kind of stumbling around blindly here
20:26:48 <adamw> i don't know how different all this is to f17, how bad it is for non-en users, etc
20:27:04 * nirik looks at the systemd package.
20:27:07 <tflink> I'd say either punt or accept
20:27:17 <nirik> 67 keymaps in there in f18.
20:27:19 <adamw> localectl list-keymaps
20:27:31 <nirik> oh, right. wrong place.
20:27:43 <adamw> spits out 209 for me
20:27:50 <nirik> yeah.
20:27:51 <Martix_N9> jreznik is dead
20:27:52 <nirik> thats better.
20:27:59 <Martix_N9> out of juice
20:28:03 <nirik> Martix_N9: I hope not!
20:28:10 <adamw> french candian notably msising, which ties in with the bug
20:28:21 <Martix_N9> his lsotop suspended
20:28:21 <adamw> do we have a count of how many keymaps newUI offers?
20:28:30 <Martix_N9> laptop
20:29:18 * adamw goes anaconda-poking
20:30:00 <nirik> so, how many would make this a blocker? it's at least one now...
20:31:08 <tflink> I'd say that more than one common enough mapping would be enough
20:31:18 <jreznik_n9> reconnected from phone, sorry... /me is dead, st least battery
20:31:19 <adamw> i'm trying to figure out where anaconda gets its list of mappings
20:31:28 <adamw> so i can compare to what systemd knows
20:31:36 <adamw> anyone can help?
20:31:37 <adamw> bcl: ping
20:33:45 <bcl> err, yes? was sudoing a hamburger
20:33:50 <tflink> I imagine that this'll end up being a judgement call, though
20:33:52 <adamw> where does anaconda get its list of keyboard layouts?
20:34:07 <adamw> i'm trying to see how many it offers that systemd is missing (hence how many layouts are going to hit this bug)
20:34:19 <bcl> not really. I'd have to dig into the code.
20:34:25 <adamw> i have a list for systemd, i think, but can't find one for anaconda, except by transcribing it from the screen =)
20:34:36 <adamw> you cna probably dig into the code faster than i can
20:34:41 * adamw is currently thrashing around in keyboard.py\
20:34:56 * nirik too.
20:35:09 <bcl> I do know we added a manual mapping of things for f18. I'm not sure if that was translations or kbd though.
20:35:30 <bcl> you might have more success looking at commits than the code.
20:37:57 <nirik> I guess if we think just 1 of these is enough to block we have 1?
20:38:03 <nirik> or revist with more info...
20:38:48 <tflink> well, I doubt that any of the most common keymaps would be affected
20:38:49 <bcl> my totally english-centric opinion is that we shouldn't block for kbd/translation problems at this point.
20:38:50 <adamw> well we can just try being dumb and eyeballing it
20:39:18 * nirik would prefer not to block on this either, but I'm not sure how many people are going to hit it at all.
20:39:43 <bcl> other than luks pw entry, can't anything else be fixed manually in the installed system?
20:40:34 <tflink> unless your system passwords are affected
20:40:35 <nirik> sure, if you know en
20:40:36 <adamw> okay, here's a totally stupid test: I just counted 200 entries on the anaconda GUI and the scrollbar is clearly above halfway
20:40:54 <adamw> so anaconda is offering somewhere north of 400 keymaps
20:41:06 <adamw> systemd only knows 209, so we have a substantial discrepancy there
20:41:11 <bcl> nirik: right, or someone writes a guide on how to do it for whatever one is messed up. Not pretty, but possible.
20:41:38 <adamw> again just eyeballing so i could be wrong, but for instance, i don't see any arabic layouts in the systemd list, assuming they'd be 'ar' or something like that
20:42:18 <nirik> so, any fix would also need systemd to have the keymaps?
20:43:18 <adamw> anaconda lists 7 japanese keymaps, systemd seems to know one
20:43:46 <adamw> i'm kinda inclining towards at least provisional +1 for this, and ask people who know what the hell they're talking about to look at it
20:43:51 <adamw> i18n folks and systemd folks i guess
20:44:17 <nirik> yeah, more data.
20:44:34 <tflink> just punt or provisionally accept?
20:45:04 * nirik is on the fence about accepting until we know more the scope. I guess it's sounding more serious than first thought.
20:45:52 <tflink> proposed #agreed 889562 - AcceptedBlocker AcceptedNTH - We're missing some data here but from what we do know, this seems to affect enough locales to justify blocking release of F18 final. If it turns out to be less severe than it currently appears, it would be rejected as a blocker for F18 final
20:46:06 <tflink> I didn't think there were 7 japanese keymaps
20:46:12 <tflink> that were still being used, anyways
20:46:36 <adamw> ack
20:46:41 <adamw> well i mean that's the kind of input we need
20:46:52 <adamw> is anaconda's list too big? is systemd's too small? etc etc...
20:46:53 <nirik> yeah, it might be mostly dead wood somehow.
20:47:27 <nanonyme> is the keymap us during firstboot in this case, btw?
20:47:58 <nirik> I would think so, yeah.
20:48:40 <adamw> i think that'd be the X keymap, which is a different question
20:48:46 <adamw> i haven't looked at that yet, just been focusing on console
20:48:51 * jreznik_n9 does not have context of this discussion so not voting due to connection/battery issues, sorry
20:48:52 <nanonyme> I think I might have bumped into this with Finnish keymap yesterday with final TC3 if so
20:49:50 <nanonyme> the keymap-botchenness only was with firstboot, not with actual login so there's danger you input wrong password during firstboot
20:50:04 <adamw> i think that may well be yet a different issue.
20:50:12 <nanonyme> check, carry on then
20:50:17 <adamw> keymaps, such a pain in the ass.
20:50:29 <nirik> indeed.
20:50:51 <adamw> nanonyme: what you need to check to see if you're hitting this is /etc/vconsole.conf
20:51:01 <adamw> if it says KEYMAP=us you hit the bug
20:51:10 <adamw> if it says KEYMAP=fi or something then looks like you're fine
20:51:24 <tflink> it looks like anaconda gets it's list from X
20:51:25 <adamw> i see 4 finnish keymaps in both anaconda and systemd's list, so finnish looks like it's okay.
20:51:34 <tflink> still not sure where exactly, though
20:52:45 <adamw> anyway, i'm okay with the ack we have
20:52:49 <adamw> er, the proposal we have
20:52:50 <nanonyme> adamw, different bug then
20:52:55 <nanonyme> carry on
20:52:56 <adamw> nanonyme: oh boy fun.
20:53:06 <adamw> i guess i'll start looking at that firstboot vs. gdm thing as well...
20:53:26 <tflink> #agreed 889562 - AcceptedBlocker AcceptedNTH - We're missing some data here but from what we do know, this seems to affect enough locales to justify blocking release of F18 final. If it turns out to be less severe than it currently appears, it would be rejected as a blocker for F18 final
20:53:46 <tflink> #topic (882212) localectl set-x11-keymap: variant settings does not work
20:53:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=882212
20:53:50 <buggbot> Bug 882212: unspecified, unspecified, ---, mschmidt, ON_QA , localectl set-x11-keymap: variant settings does not work
20:53:51 <tflink> #info Proposed Blocker, systemd, ON_QA
20:53:53 <tflink> continuing with keymap happy fun time ...
20:54:11 <adamw> tflink: possibly /usr/share/X11/xkb/rules/base.lst
20:54:38 <adamw> this is the other problem with converting keymap on upgrade, i think.
20:56:19 <adamw> there's only one thing i'm unhappy about with this bug report
20:56:35 <adamw> so far as i can see, systemd %post doesn't actually call localectl or do anything like it to migrate the settings
20:56:55 <adamw> it just sources /etc/sysconfig/keyboard and dumps what it finds there into /etc/vconsole.conf
20:57:03 <adamw> though i wonder if the problem is when systemd then comes to *read* vconsole.conf
20:57:15 <adamw> maybe that fails and it falls back to US
20:58:56 <tflink> adamw: yeah, that looks right. it looks to me like anaconda is using libxklavier to get info on layouts and I _think_ that reads in xml from xkb
20:59:23 <adamw> so i don't understand jan's assertion that this is actually a problem for upgrades, unless i'm missing something
20:59:45 <adamw> don't suppose jan's still around?
21:01:06 <tflink> unless the format in /etc/sysconfig/keyboard is different from /etc/vconsole.conf?
21:01:21 <adamw> i just followed that up but i don't think so
21:01:44 <adamw> if anything, this is about mapping X layout to console layout, maybe systemd does that dynamically every boot or something? is that what systemd-localed is for? it all seems obscure to me, even after reading the docs
21:02:00 <adamw> we're around line 453 of systemd.spec here if you want to look
21:02:09 <adamw> it literally just does this:
21:02:09 <adamw> . /etc/sysconfig/keyboard >/dev/null 2>&1 || :
21:02:10 <adamw> ...
21:02:14 <adamw> [ -n "$KEYTABLE" ] && echo KEYMAP=$KEYTABLE >> /etc/vconsole.conf 2>&1 || :
21:02:34 <adamw> so if anything this can only be a problem when systemd goes to actually activate the config on boot
21:03:18 <adamw> did i mention yet how much I hate keymaps? because I really fucking hate keymaps.
21:05:28 <nanonyme> adamw, at least this is about post-boot keymaps and not eg disk encryption keymaps :) that'd be even more fun
21:06:05 <adamw> i guess i'm at least +1 nth just as it seems safer to have this fixed than not, but i wish i understood it more
21:06:54 <tflink> already accepted as NTH
21:07:45 <adamw> ah k
21:07:50 <adamw> let's just pull it as nth and move on
21:08:00 <tflink> reject, then?
21:08:02 <tflink> or punt
21:08:21 <tflink> I'm not sure about rejecting this yet without knowing more
21:09:13 <tflink> proposed #agreed 882212 - We don't understand this nearly enough to make a call on whether this should block release - it is already accepted as NTH and might be fixed. Will revisit if it continues to be an issue
21:09:21 <nirik> ack
21:09:42 <adamw> ack
21:09:58 <tflink> #agreed 882212 - We don't understand this nearly enough to make a call on whether this should block release - it is already accepted as NTH and might be fixed. Will revisit if it continues to be an issue
21:10:12 <tflink> OK, that's all of the proposed blockers that were on my list when we started
21:11:12 <tflink> it looks like ... 3 were added since we started
21:11:36 * nirik sighs
21:11:37 <adamw> let's add 'em
21:11:48 <tflink> one sec while I grab the new list
21:12:43 <tflink> #topic (889352) [i18n] translated string not displayed in Welcome dialog: "Set keyboard to default layout for selected language."
21:12:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889352
21:12:48 <buggbot> Bug 889352: unspecified, unspecified, ---, anaconda-maint-list, NEW , [i18n] translated string not displayed in Welcome dialog: "Set keyboard to default layout for selected language."
21:12:49 <tflink> #info Proposed Blocker, anaconda, NEW
21:13:19 <adamw> that seems like something you really want to have translated.
21:13:51 <tflink> proposed #agreed 889352 - 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"
21:14:04 <adamw> ack
21:14:18 <nirik> ack
21:14:47 <tflink> #agreed 889352 - 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"
21:14:52 <tflink> #topic (889585) should not offer to change boot disk from within custom storage spoke
21:14:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889585
21:14:57 <buggbot> Bug 889585: unspecified, unspecified, ---, dlehman, POST , should not offer to change boot disk from within custom storage spoke
21:14:58 <tflink> #info Proposed Blocker, anaconda, POST
21:15:30 <tflink> sounds like something which would be good to fix
21:15:36 <tflink> not sure about blocker but definitely NTH
21:16:59 <adamw> dlehman: what happens if you try?
21:16:59 <adamw> explosions and death, or what?
21:16:59 <adamw> just thinking if it may be a blocker not nth
21:16:59 <adamw> <dlehman> possible unbootable system
21:16:59 <adamw> <adamw> let's make it blocker nominee then.
21:17:07 <adamw> possible unbootable system is bad news.
21:17:12 <dlehman> right
21:17:22 <adamw> though happily, no-one ever seems to notice that option exists. :)
21:17:24 <nirik> yeah.
21:17:26 <dlehman> patch is already tested and approved
21:17:29 <tflink> criterion?
21:19:02 <tflink> the firstboot criterion from alpha?
21:19:24 <tflink> that's why I was leaning NTH - no criteria to worry about :)
21:19:30 <tflink> well, part of why
21:19:54 <tflink> "The installer must allow the user to select which of the disks connected to the system will be affected by the installation process. Disks not selected as installation targets must not be affected by the installation process in any way"?
21:20:25 <jreznik_n9> if anything could be nth, count with me...
21:22:22 <adamw> eh, NTH is fine i guess
21:22:27 <tflink> proposed #agreed 889585 - AcceptedNTH - Functionality to select the boot disk should work - since there is no code to do so in the custom partition spoke and the option exists elsewhere, removing it seems like a good option. A tested fix would be accepted past freeze.
21:22:29 <adamw> ack
21:23:10 <jreznik_n9> ack
21:23:27 <nirik> ack
21:24:11 <tflink> #agreed 889585 - AcceptedNTH - Functionality to select the boot disk should work - since there is no code to do so in the custom partition spoke and the option exists elsewhere, removing it seems like a good option. A tested fix would be accepted past freeze.
21:24:20 <tflink> #topic (888030) [i18n] some package set descriptions not translated
21:24:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=888030
21:24:20 <tflink> #info Proposed Blocker, comps, NEW
21:24:22 <buggbot> Bug 888030: unspecified, unspecified, ---, notting, NEW , [i18n] some package set descriptions not translated
21:24:58 <adamw> this doesn't seem serious enough to block on.
21:25:14 * nirik agrees
21:25:20 <tflink> +1 nth, though
21:25:21 <adamw> but nth, sure.
21:25:38 <nirik> it's already fixed tho. ;)
21:25:40 <nirik> just close it?
21:25:41 * jreznik_n9 nods
21:26:05 * nirik notes we should really have a way to freeze comps. ;)
21:26:06 <tflink> proposed #agreed 888030 - RejectedBlocker AcceptedNTH - This doesn't seem severe enough to block release but a tested fix would be considered past freeze.
21:26:29 <nirik> edit: close the bug and drive on? no need to keep it around?
21:27:09 <adamw> ack
21:27:17 <tflink> proposed #agreed 888030 - RejectedBlocker AcceptedNTH - This doesn't seem severe enough to block release but a tested fix would be considered past freeze. Since comps changes go through without packages, this bug can be closed.
21:27:21 <adamw> ack to the proposal or ack to close or both.
21:27:22 <adamw> ackackack
21:27:44 * nirik looks for the hairball
21:27:51 <nirik> sure, ack
21:27:53 <tflink> #agreed 888030 - RejectedBlocker AcceptedNTH - This doesn't seem severe enough to block release but a tested fix would be considered past freeze. Since comps changes go through without packages, this bug can be closed.
21:28:00 * nirik doesn't care, but the bug can be closed, it;s already done
21:28:06 <tflink> now that we've spent 3 hours with the proposed blockers ...
21:28:35 <nirik> perhaps we should pause to look at where we are now?
21:28:40 <tflink> nirik: it's nice to get some notice about comps changes though, we've been burned by unexpected changes in the past
21:28:41 <adamw> should be a resync in 2 minutes
21:29:06 <nirik> ie: can we make our current scheduled release still? or is it doomed?
21:29:27 <adamw> so, so doomed.
21:29:41 <adamw> or maybe i'm just being a pessimist :)
21:29:43 <nirik> note that we do have the 2nd and 3rd possibly... when people are back
21:29:50 <dlehman> to hell with f18. pass the eggnog.
21:30:13 <adamw> i thought go/no-go was 01-01?
21:30:20 <nirik> we could shift it?
21:30:23 <adamw> ack eggnog
21:31:17 <nirik> I wonder: should we consider no more NTHs?
21:31:37 <adamw> list is resynced
21:31:41 <tflink> I thought they shifted it a few days
21:31:47 <tflink> 01-03, I think
21:31:57 <tflink> nirik: some of them are important
21:32:00 <adamw> actually i'd like to wave through a few NTHs we have fixes for
21:32:20 <tflink> I have 11 NTHs on my list which are marked as ready for discussion
21:32:27 <nirik> sure, perhaps we do another batch and then close the gate? Just as a means to focus on blockers...
21:32:37 <tflink> 13 total proposed NTH
21:32:56 <tflink> I imagine that we'll have more as time goes on
21:33:03 <tflink> more that are worth getting in, anyways
21:33:20 <adamw> 889366 , 889570 , 873103 , 872851 are the ones i had listed as important
21:33:24 <adamw> yeah, iw ouldn't want to shut the gate
21:33:58 <nirik> ok, just an idea to try and make things more time efficent and have a release somday.
21:33:58 <tflink> I see 3 or 4 which come across as important
21:34:11 <nirik> anyhow, are we hitting these now? or ?
21:34:22 * nirik has to leave for a bit in a bit.
21:36:02 <tflink> my list was the same as adams wrt priority
21:36:02 <adamw> i'd like to hit the ones i listed at least
21:36:09 <tflink> do the 4 of those and call it a day?
21:36:50 <tflink> #topic (873103) Chinese input does not work after installation
21:36:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873103
21:36:51 <tflink> #info Proposed NTH, anaconda, ON_QA
21:36:52 <buggbot> Bug 873103: unspecified, unspecified, ---, vpodzime, ON_QA , Chinese input does not work after installation
21:37:24 <adamw> +1 nth
21:37:27 <adamw> for obvious reasons
21:37:28 <tflink> +1 nth - working chinese input post-install is a good thing
21:37:33 <nirik> yeah, +1 nth
21:38:39 <tflink> proposed #agreed 873103 - AcceptedNTH - Not a release blocking bug since it only affects one language but it can't be fixed with an update and there are lots of users who use the Chinese locales.
21:39:04 <adamw> ack
21:39:07 <nirik> ack
21:39:12 <tflink> #agreed 873103 - AcceptedNTH - Not a release blocking bug since it only affects one language but it can't be fixed with an update and there are lots of users who use the Chinese locales.
21:39:16 <tflink> #topic (889366) "Don\'t install the latest available software updates. Install the default versions provided by the install source above." checkbox does nothing, media installs don\'t default to installing updates
21:39:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889366
21:39:22 <buggbot> Bug 889366: medium, unspecified, ---, anaconda-maint-list, POST , "Don't install the latest available software updates. Install the default versions provided by the install source above." checkbox does nothing, media installs don't default to installing updates
21:39:23 <tflink> #info Proposed NTH, anaconda, POST
21:39:25 <tflink> +1 NTH
21:39:33 <nirik> +1 nth as I noted in bug.
21:39:39 <adamw> +1
21:40:24 <tflink> proposed #agreed 889366 - AcceptedNTH - This doesn't violate any F18 release criteria but could cause problems for bandwidth limited users and features should work if they are displayed as available.
21:40:41 <adamw> ack
21:40:43 <nirik> ack
21:40:48 <tflink> #agreed 889366 - AcceptedNTH - This doesn't violate any F18 release criteria but could cause problems for bandwidth limited users and features should work if they are displayed as available.
21:40:48 <adamw> oh, patch
21:40:52 <tflink> #undo
21:40:52 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x214c4990>
21:40:53 <adamw> oh well, n/m
21:40:59 <adamw> it doesn't really cause problems for anyone
21:41:09 <adamw> it's just the confusion. the checkbox does nothing, nothing at all
21:41:13 <adamw> dvd installs don't pull from updates
21:41:18 <adamw> whether you check it or not
21:41:28 <tflink> #agreed 889366 - AcceptedNTH - This doesn't violate any F18 release criteria but features should work if they are displayed as available.
21:41:34 <adamw> ack
21:41:40 <tflink> #topic (889570) Add help / instruction text for custom spoke
21:41:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=889570
21:41:41 <tflink> #info Proposed NTH, anaconda, POST
21:41:42 <buggbot> Bug 889570: medium, unspecified, ---, dlehman, POST , Add help / instruction text for custom spoke
21:42:16 <nirik> sure, it already exists?
21:42:31 <tflink> I think that they're doing a build with the help screen right now
21:42:42 <tflink> or will be shortly
21:42:45 <adamw> yeah, i told 'em to assume we'd +1 this
21:42:49 <nirik> +1 nth, would be good for more help text there.
21:42:59 <adamw> s/more/any/ :)
21:43:00 <adamw> +1
21:43:38 <tflink> proposed #agreed 889570 - AcceptedNTH - This doesn't violate any F18 release criteria but useful help messages for custom partitioning would hopefully help reduce confusion when doing custom layouts.
21:43:42 <tflink> +1, for the record
21:43:47 <adamw> ack
21:43:58 <jsmith> ACK
21:44:04 <adamw> it's a jsmith!
21:44:08 <nirik> ack
21:44:10 <tflink> #agreed 889570 - AcceptedNTH - This doesn't violate any F18 release criteria but useful help messages for custom partitioning would hopefully help reduce confusion when doing custom layouts.
21:44:14 <tflink> #topic (872851) [abrt] rhythmbox-2.98-4.fc18: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
21:44:16 <jsmith> adamw: Yeah, I'm doing three things at once, but trying to be helpful
21:44:17 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872851
21:44:18 <nirik> with a mighty ACK, jsmith joins the fun. ;)
21:44:19 <buggbot> Bug 872851: high, high, ---, john.j5live, ON_QA , [abrt] rhythmbox-2.98-4.fc18: Process /usr/bin/rhythmbox was killed by signal 11 (SIGSEGV)
21:44:20 <tflink> #info Proposed NTH, pygobject3, ON_QA
21:44:40 <adamw> i dunno why we didn't consider nth at the last meeting, but obviously it'd be nice to fix this for the live case
21:44:48 <adamw> playing music is something i can certainly imagine people doing with a live image
21:44:48 <jsmith> +1 NTH
21:44:55 <tflink> I still don't understand why this should be NTH
21:45:02 <tflink> the plugin causing the crash isn't on the livecd
21:45:04 <nirik> well, it's using a non standard plugin tho right?
21:45:11 <jreznik_n9> it's not nth
21:45:34 <jreznik_n9> and do not expect fix at all
21:46:06 <jreznik_n9> hadess just told me, I don't touch this one, sorry, find someone else
21:46:08 <tflink> -1 NTH unless I'm missing something
21:46:15 <jreznik_n9> -1 nth
21:46:19 <adamw> er, what?
21:46:19 <nirik> yeah, -1 unless I am misunderstanding it.
21:46:21 <adamw> we have a fix already
21:46:25 <adamw> and the plugin is on the live image
21:46:31 <adamw> as i already explained at the last meeting, it is part of rb
21:46:34 <nirik> comment 20: "This isn't really a blocker bug by the criteria, since we don't enable the ReplayGain plugin by default."
21:46:44 <tflink> ok, +1 NTH then
21:46:47 <nirik> so it is on there.
21:46:48 <tflink> I was mis-remembering
21:46:48 <adamw> rb comes with a default set of plugins. it's not enabled by default, but it's present, and replaygain is a common thing for music people to do.
21:46:50 <nirik> but it's not enabled
21:46:57 <adamw> sure. so it's not a blocker. but why not fix it?
21:47:02 <adamw> this is nth, not blocker.
21:47:13 <tflink> I know, I just didn't think the plugin was on the livecd
21:47:20 <adamw> was directed at nirik
21:47:20 <nirik> I guess. pygobject is pretty low in the stack... but ok
21:47:31 * nirik didn't think it was on the media either.
21:48:01 <tflink> you have a point, there
21:48:15 <tflink> do we know how big the fix was or if anything else came with it?
21:49:02 <adamw> https://bugzilla.gnome.org/show_bug.cgi?id=690514
21:49:03 <buggbot> Bug 690514: normal, Normal, ---, nobody, NEW, pyg_value_from_pyobject: support GArray
21:49:11 <adamw> http://bugzilla-attachments.gnome.org/attachment.cgi?id=231935
21:49:19 <nirik> sigh.
21:49:21 <adamw> it's all C to me...
21:49:27 <nirik> there's a newer build... with another patch added.
21:49:32 <adamw> we could always just push -5.
21:49:39 <nirik> https://admin.fedoraproject.org/updates/FEDORA-2012-20814/pygobject3-3.4.2-6.fc18
21:50:06 <adamw> though actually, copy/paste in sugar sounds nth-y in itself.
21:50:07 <nirik> it's another fix for the same bug?
21:50:21 <nirik> oh, no, bodhi copied from the old update. right.
21:50:36 <nirik> https://bugzilla.gnome.org/show_bug.cgi?id=656312
21:50:37 <buggbot> Bug 656312: normal, Normal, ---, gtk-bugs, UNCONFIRMED, gtk_clipboard_set_with_data/set_with_owner is binding-unfriendly
21:50:57 * jreznik_n9 is rereading fix, was not aware of current state
21:51:13 * adamw waves white flag on understanding that one
21:51:44 <nirik> yeah.
21:51:57 <adamw> anyway, we can always push -5 not -6 i think
21:52:03 <nirik> it's unclear what the impact of that one is.
21:52:04 <adamw> so we can vote on this bug and more or less ignore that one...
21:52:09 <nirik> true.
21:52:27 <adamw> there's a comment on it that says 'this is a blocker for us' but helpfully does not give any indication who 'us' are.
21:52:36 <adamw> sent from a gmail address, so you can't infer the project from the mail address. :)
21:52:51 <adamw> google suggests he's an OLPC dev, though
21:52:59 <adamw> ooh, lemme see if i can raise pbrobinson or satellit...
21:53:44 <adamw> anyway, i guess in theory i'm still +1 on the rb bug, but if the fix looks scary then i could change
21:54:03 <nirik> the fix to this orig bug is pretty small.
21:54:09 <tflink> yeah, I don't know enough to make the call on the scary-ness of the patch
21:55:02 <nirik> http://pkgs.fedoraproject.org/cgit/pygobject3.git/commit/?h=f18&id=14e44ae5618044ff20fc90d449a507384c30a7c1
21:55:13 <nirik> I guess it could be somewhat scary.
21:55:50 <nirik> I guess I am a weak -1... since it's not enabled by default and we could fix for installs in an update... ?
21:56:04 <tflink> yeah, it would just affect livecds
21:56:44 <tflink> I'm probably a weak -1, too. if the patch isn't too scary, I wouldn't fight it but my instict says to avoid non-critical pygobject changes this late
21:57:22 <adamw> i'm not gonna fight if you guys are -1
21:57:30 <adamw> you can always yum update in the live image if you really need it
21:58:11 <nirik> I mean, I could see playing with it to make sure your music plays or sound works, but would you really go in and enable plugins and do a bunch of stuff on a live boot?
21:58:25 <nirik> anyhow.
21:58:29 * nirik has to leave for a bit...
21:59:02 <tflink> proposed #agreed 872851 - RejectedNTH - While this bug would affect live images, the problematic plugin isn't enabled by default and the needed change is in pygobject which seems a little too risky to be changing so late.
21:59:32 <adamw> ack
21:59:47 <tflink> #agreed 872851 - RejectedNTH - While this bug would affect live images, the problematic plugin isn't enabled by default and the needed change is in pygobject which seems a little too risky to be changing so late.
21:59:47 <adamw> nirik: replaygain isn't a 'bunch of plugins', it's a pretty standard thing for many music listeners
21:59:57 <adamw> it normalizes the volume of a set of files with different volume levels
22:00:01 <tflink> adamw: but on a livecd?
22:00:13 <adamw> lsitening to music seems like a pretty obvious thing to do when you're playing with a live image, i guess?
22:00:18 <adamw> anyways
22:00:19 <adamw> acked
22:00:57 <tflink> I think that's going to be all for today since we've lost everyone else
22:01:30 <tflink> unless we want to go through the accepted blockers
22:02:48 <adamw> don't see the point of doing it in meeting form
22:02:55 <adamw> we may as well just work on them like we have been doing
22:03:20 <tflink> ok
22:03:23 <tflink> #topic Open Floor
22:03:33 <tflink> I assume that there are no other topics to bring up right now?
22:03:48 <tflink> not sure when the next blocker review will be
22:04:00 <tflink> not likely until after 2013-01-02
22:05:07 <tflink> #info No date set for the next blocker review meeting, will more than likely be after 2013-01-01
22:05:18 * tflink will send out minutes shortly
22:05:25 <tflink> Thanks for coming, everyone!
22:05:27 <tflink> #endmeeting