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