17:01:52 #startmeeting F16-final-blocker-review-4 17:01:52 Meeting started Fri Oct 21 17:01:52 2011 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:03 yo 17:02:05 #meetingname F16-final-blocker-review-4 17:02:05 The meeting name has been set to 'f16-final-blocker-review-4' 17:02:09 #topic roll call 17:02:22 Alrighty, who's ready for some blocker bug review awesomeness? 17:02:28 #chair adamw 17:02:28 Current chairs: adamw tflink 17:02:58 * adamw is ready freddie 17:03:15 (though i've been trying to get people to call me freddy knuckles) 17:03:34 adamw: ok, freddy 17:05:28 hrm, anyone else here for blocker review? 17:06:35 * jsmith is here 17:06:39 Sorry for being late 17:06:47 jsmith: no worries, we have 3 people now! 17:07:06 Awesome 17:07:18 * spot is here to help too, if needed 17:08:13 spot: cool, thanks. 3 people is generally the min we try to have but more doesn't hurt 17:08:22 ok, lets get this party started 17:08:35 #topic Introduction 17:08:46 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:09:05 there has been a little movement since I generated my lists, so this might be a little off but .. 17:09:14 #info 10 proposed blockers 17:09:23 #info 5 proposed NTH 17:09:31 #info 8 accepted blockers 17:09:46 We'll be working off of the following list of bugs: 17:09:58 BUGS 17:10:00 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:10:15 The release criteria pages are: 17:10:25 #link https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria 17:10:35 but alpha and beta release criteria are still valid 17:10:42 #link https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria 17:10:50 #link https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria 17:11:09 any objections to diving into the proposed blockers? 17:11:38 Nada. 17:11:48 well, alrighty then 17:11:50 #topic (719100) NetworkManager doesn't set hostname to value return from dhclient 17:11:53 #link http://bugzilla.redhat.com/show_bug.cgi?id=719100 17:11:55 #info Proposed Blocker, MODIFIED 17:13:00 i think this is meant to be proposed as NTH, not blocker 17:13:06 see comment #15 17:13:11 red_alert: is that right? 17:14:25 yeah, it sounds like it was marked blocker so it would be discussed here but meant to be proposed as a NTH 17:14:31 I'm ok with this as NTH 17:14:43 don't think it's blocker material, though 17:14:52 didn't find a criteria to block it properly, so NTH is fine :) 17:15:17 the worst outcome of this is 'hostname set by DNS doesn't work'? if so, yeah, NTH for me, not blocker 17:15:26 proposed #agreed - 719100 - AcceptedNTH - This is a regression from F15 and would be nice to have in the released installer 17:15:30 ack/nak/patch? 17:15:54 ACK 17:16:02 worst outcome is hostname is set to localhost.localdomain instead of the provided hostname :) bad, if you do puppet in %post ;) 17:16:30 but workarounds shouldn't be too hard 17:16:54 tflink: ack 17:17:02 Definitely sounds like a good NTH to me 17:17:11 #agreed - 719100 - AcceptedNTH - This is a regression from F15 and would be nice to have in the released installer 17:17:18 #topic (746573) AttributeError: 'NoneType' object has no attribute 'default' 17:17:21 #link http://bugzilla.redhat.com/show_bug.cgi?id=746573 17:17:24 #info Proposed Blocker, POST 17:17:55 this is wonderfully descriptive 17:18:52 If I'm understanding corectly: installing with DVD and replacing the installation repos results in a crash? 17:19:05 tflink: That's what it sounds like to me 17:19:23 tflink: I don't know if there's something special in the replacement repo that triggers it, though 17:19:33 * tflink wonders if this happens w/ netinstall, too 17:19:54 I'd like to get more feedback on this one from some anaconda folks, to be honest 17:19:59 the criterion I'm seeing is "The installer must be able to use all supported local and remote package source options" 17:20:39 * adamw asking for an anaconda dev to join 17:20:53 Sounds to me like it's probably a blocker, then... even though it sounds like a corner case 17:21:04 well, not necessarily 17:21:19 I guess there's an easy workaround (don't do that!) 17:21:21 the intent of that criterion is that you can install from dvd, you can install from nfs, you can install from ftp, you can install from http... 17:21:29 not that you have to be able to switch horses in midstream 17:22:07 so if this requires starting out meaning to do a dvd install then changing your mind at the repo selection screen it's not necessarily a blocker 17:22:27 if this is only deleting repos, I'm less inclined to think it's blocker 17:22:32 if we don't get any more input this looks a bit more NTH-y to me 17:22:39 if it happens when you ADD a repo, I'm more blocker 17:22:41 the patch reads "Regenerate tasklist when a repo is removed" 17:22:46 patch description* 17:22:46 tflink: Yes, the patch is for handing *deleting* a repo 17:22:54 so, seems a bit nth-y 17:23:04 I'm perfectly fine calling it NTH :-) 17:23:29 -1 blocker +1 nth i guess 17:23:48 proposed #agreed - 746573 - RejectedBlocker AcceptedNTH - Removing repos during installation is a bit of a corner case but still used 17:23:53 ack/nak/patch? 17:25:16 ACK 17:25:18 ack 17:25:24 #agreed - 746573 - RejectedBlocker AcceptedNTH - Removing repos during installation is a bit of a corner case but still used 17:25:30 #topic (747632) using iSCSI target as root filesystem results in kernel panic at boot 17:25:34 #link http://bugzilla.redhat.com/show_bug.cgi?id=747632 17:25:36 #info Proposed Blocker, MODIFIED 17:25:47 this was a fun one 17:26:04 long story short - using iSCSI target as root fails with a minimal install 17:26:07 clearly +1 blocker anyway as we have an explicit iSCSI criterion. 17:26:20 well, if it's minimal only that's a bit more blurry, but eh, still +1 17:26:28 dracut was trying to use wget, which isn't part of the minimal install 17:26:54 Yeah, but isn't curl part of the minimal install? 17:27:00 proposed #agreed - 747632 - AcceptedBlocker - "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:27:04 ack/nak/patch? 17:27:05 Anyhoo, not trying to tell others how to fix it -- 17:27:08 ACK 17:27:37 jsmith: an unrelated dracut module was being activated when it shouldn't have 17:27:43 ack 17:27:47 tflink: Yeah, reading that now 17:27:51 that is what was trying to use wget 17:28:01 #agreed - 747632 - AcceptedBlocker - "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)" 17:28:10 #topic (736993) error install bootloader with serial interface install 17:28:13 #link http://bugzilla.redhat.com/show_bug.cgi?id=736993 17:28:16 #info Proposed Blocker, NEW 17:28:40 * adamw is secretary-ing, btw 17:28:54 I think that the point of this is to decide whether or not we want serial console install issues to block or not 17:29:09 I'm pretty much +1 on this 17:29:26 yeah, we're back on deciding if serial console should be a release blocker. 17:29:51 I think I'm +1 on this one as well 17:29:53 AFAIK, it doesn't have any cloud implications as the cloud delivery platforms I'm aware of don't use anaconda 17:30:14 my reason for being +1 is that it interferes with datacenter-ish setups 17:30:22 Having spent way too many years doing remote installs (some over serial), I think it's still important 17:30:45 and it's blocking my ability to do install testing in the RH labs to get better HW coverage 17:30:49 if it's a reasonably well-used method, not something super-exotic which only ever gets used by crazy people like qa, then yeah, i'm okay with keeping the final criterion and +1 on this. 17:31:11 It gets used in real-life, yes :-) 17:31:24 I'd like it to be an alpha or beta blocker, to be honest 17:31:24 in f16 criteria currently it seems like we don't have an explicit criterion for serial console installs, afaict 17:32:05 so i think we should agree in principle to add a criterion 17:32:08 well, I think that we could accept it because it's interfering with test cases and testing for f16 17:32:19 but yeah, we should probably have a criterion for this 17:33:00 i don't like making bugs blockers because they interfere with our test cases, it's exactly the wrong way around 17:33:07 the test cases are meant to enforce the criteria, not vice versa 17:33:19 how about proposing to modify the following alpha criteria "The installer must be able to complete an installation using the text, graphical and VNC installation interfaces" to include serial? 17:33:20 i'm sure we've lost a criterion somewhere along the way 17:33:28 i don't like that 17:33:33 see how i remember it is this 17:33:43 that criterion exists because we specifically only wanted to support those three interfaces for alpha 17:33:49 and we wanted to support the other interfaces later (beta or final) 17:34:00 but somehow we either never wrote, or lost, the beta/final 'interface' criteria 17:34:02 I think serial is beta material, not alpha 17:34:10 anyway 17:34:25 for the purpose of this meeting we can agree in principle that we will add a beta or final criteria for the 'serial console' installation interface 17:34:28 and hence accept the bug as a blocker 17:34:30 agreed? 17:34:39 works for me 17:34:42 * spot nods 17:35:03 #info beta/final release criteria for serial console install will be added 17:35:11 * jsmith is fine either adding the criteria now or for F17 17:35:28 I don't have a strong preference either way 17:36:35 proposed #agreed - 736993 - AcceptedBlocker - There is no release criterion to cover this yet, but we agreed to add a beta/final release criterion soon to do so. 17:37:05 Sure, works for me 17:38:52 ack 17:39:06 #agreed - 736993 - AcceptedBlocker - There is no release criterion to cover this yet, but we agreed to add a beta/final release criterion soon to do so. 17:39:12 #topic (737508) grub2 cannot install when /boot is md and first partition starts at sector 63 17:39:16 #link http://bugzilla.redhat.com/show_bug.cgi?id=737508 17:39:18 #info Proposed Blocker, NEW 17:40:18 This still comes down to whether or not this is a 'workable' layout 17:41:03 is dlehman still on vacation? 17:41:32 nvm, I talked to him yesterday 17:41:34 What's the criteria on this one? 17:41:44 i've talked to pjones about this extensively this morning 17:41:48 "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 17:41:49 broad conclusion: likely not a blocker 17:42:00 the headline issue is pretty simple: it's not a workable partition layout, 17:42:04 This sounds like a corner case to me -- installing to an existing /boot shared by another OS, that just happens to be aligned improperly? 17:42:36 the alignment isn't exactly 'improper', really, but it doesn't leave enough space for grub2's core.img to fit behind it, and there's nothing we can do about that 17:42:45 we can't wave a magic wand and move the /boot partition and we can't magically compress core.img 17:43:08 the bug has essentially turned into a request for the 'pre-flight check' andy mentions in comment #1 17:43:15 ah, so it's not so much an alignment issue as an available space issue? 17:43:25 But anaconda can't know how much space grub will need, right? 17:43:29 which would be nice, but doesn't really hit any blocker criteria, and isn't something we can just patch in overnight 17:43:32 So I'm voting "not a blocker" 17:43:42 yeah, i'm -1 blocker, though we should probably document this 17:44:33 proposd #agreed - 737508 - RejectedBlocker - The layout described is not workable since /boot is too small for grub2 - a pre-flight check would be nice but not a blocker issue 17:44:38 ack/nak/patch? 17:44:53 ACK 17:44:55 patch 17:45:07 'would be nice' sounds like NTH to me 17:45:16 proposd #agreed - 737508 - RejectedBlocker - The layout described is not workable since the space between MBR and /boot partition is too small for grub2 - a pre-flight check would be nice but not a blocker issue 17:45:26 ah, ok 17:45:35 red_alert: i suspect any patch would be pretty intrusive unless upstream adds a simple '--preflight-check' option we could just call 17:45:45 red_alert: so i'm not sure i'd want to take it as nth _yet_ 17:45:46 red_alert: The pre-flight check is a wish, without any patch or agreement on how to do it 17:45:58 yeah, I don't think I'd want to take that past freeze 17:46:06 adamw: ah, I see...I thought this was something anaconda could check easily :) 17:46:08 if a really reliable-looking, small and non-intrusive patch shows up we could go nth at that point i think 17:46:11 ack to adamw's patch 17:46:12 red_alert: not at present, no 17:46:22 ACK 17:46:30 self-ack! 17:46:52 #agreed - 737508 - RejectedBlocker - The layout described is not workable since the space between MBR and /boot partition is too small for grub2 - a pre-flight check would be nice but not a blocker issue 17:47:04 #topic (743273) grub2 fails to install on IMSM raid device 17:47:04 #link http://bugzilla.redhat.com/show_bug.cgi?id=743273 17:47:04 #info Proposed Blocker, NEW 17:48:14 adamw: you were re-testing some of this, no? 17:48:23 do we have any more information on what's going on? 17:48:51 Still not clear to me what the issue is, but doesn't sound like a general blocker on all IMSM raid devices to me 17:49:00 no, we have another bug for that. ;) 17:49:06 so pjones tried to reproduce this but couldn't 17:49:22 i am going to try and reproduce again on my desktop after this meeting, as i can't use the laptop i first hit it on as a test box 17:49:42 so, punt again? 17:49:45 we _thought_ the reproducer here was 'install f15 to intel BIOS raid, upgrade to f16', but pjones tried that and it worked, so we need to try harder to reproduce 17:49:48 yeah, it's a punter. 17:50:11 pjones and i will try and figure _something_ out for monday. 17:50:30 but if it comes down to it this is one we'd probably fudge for an rc1 by leaving it proposed 17:50:32 proposed #agreed - 743273 - Still don't have enough information on this to make a decision, will hopefully have concrete repro cases and data early next week 17:51:04 ACK from me 17:51:14 seems sensible 17:52:13 ack 17:52:22 #agreed - 743273 - Still don't have enough information on this to make a decision, will hopefully have concrete repro cases and data early next week 17:52:31 #topic (746869) ibus cannot get the current keymap if the XKB has no group and no variant 17:52:34 #link http://bugzilla.redhat.com/show_bug.cgi?id=746869 17:52:36 #info Proposed Blocker, ON_QA 17:53:35 ACK as a blocker 17:53:40 yeah, same here 17:53:46 +1 blocker 17:53:49 This one is pretty clear-cut 17:54:38 proposed #agreed - 746869 - AcceptedBlocker - Makes the system unsable for japanese language users and violates the alpha criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user inter 17:54:51 ack/nak/patch? 17:55:10 ACK 17:55:13 ACK 17:55:29 * jsmith also notes that it appears to hit many ibus users, and not just japanese according to the comments in the bug 17:56:11 #agreed - 746869 - AcceptedBlocker - Makes the system unsable for japanese language users and violates the alpha criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. 17:56:18 #topic (747653) SELinux is preventing systemd-tty-ask from 'read' accesses on the file ask.lIE7zh. 17:56:21 #link http://bugzilla.redhat.com/show_bug.cgi?id=747653 17:56:24 #info Proposed Blocker, MODIFIED 17:56:32 having a dedicated input/ibus test case would be nice - not because it's not *somehow* covered yet but because it's not necessarily tested with the existing test cases that might cover this 17:57:31 yeah, that would be nice to have 17:57:32 +1 Blocker 17:58:06 proposed #agreed - 747653 - AcceptedBlocker - Interferes with unlocking of encrypted filesystems and violates "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 17:58:42 ACK 17:58:48 ack 17:58:52 ACK 17:58:59 #agreed - 747653 - AcceptedBlocker - Interferes with unlocking of encrypted filesystems and violates "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" 17:59:10 #topic (743022) F15->F16 yum update fails with IMSM (BIOS) raid 17:59:10 #link http://bugzilla.redhat.com/show_bug.cgi?id=743022 17:59:10 #info Proposed Blocker, NEW 17:59:34 -1 blocker, yum upgrade is not officially supported 17:59:59 I spoke too soon 18:00:00 the problem here is we're not entirely sure the yum nature of the upgrade was the important thing. 18:00:18 i've asked rbergeron to chase up systemd devs to give us some input on this bug 18:00:31 so punt while waiting for input? 18:01:06 proposd #agreed - 743022 - Still need developer input on this to determine whether it is a general issue or only with yum upgrades. 18:02:13 yeah. 18:02:23 but if we don't get any kind of info we might have to drop it. 18:02:26 I don't like the fact that we've said that for three weeks in a row 18:02:36 me either, but if the devs don't give us anything, there isn't much we can do. 18:02:40 hence the attempt to apply pitchforks. 18:02:48 Who is actually going to track down said developers? 18:03:00 Has someone sent them an email, asking them for feedback? 18:03:33 they get email from bz and choose to ignore it...rather track them down on irc ;) 18:04:33 from what adamw said, it sounds like rbergeron is doing the hunting 18:04:44 jsmith: i just said, above. rbergeron. 18:05:05 adamw: Sorry, I missed that 18:05:16 OK 18:05:25 #agreed - 743022 - Still need developer input on this to determine whether it is a general issue or only with yum upgrades. 18:05:33 #topic (747276) Error is occured when I try to start totem in Fedora 16 fallback mode (tested in virt-manager) 18:05:36 #link http://bugzilla.redhat.com/show_bug.cgi?id=747276 18:05:38 #info Proposed Blocker, NEW 18:05:52 I think this would hit "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:06:48 +1 blocker 18:07:05 (although I'm still not sure who is to blame here -- clutter, mesa, or totem) 18:07:58 i'm pretty sure it is totem assuming clutter is present and functional 18:08:38 Is that what swell-foop is doing as well? Because the crashes seem awfully similar 18:08:39 proposed #agreed - 747276 - AcceptedBlocker - Violates the final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:08:51 * spot will look at swell-foop 18:09:03 no, it's not what swell-foop is doing. 18:09:09 swell-foop crashed on everything, and that was fixed. 18:09:13 Ah, gotcha 18:09:27 Didn't notice that it had been fixed -- shows how often I play games 18:09:43 i'm +1 on the criteria on this one, but it may not be that straightforward to fix... 18:09:59 if clutter is relying on capabilities that software 3D doesn't support, and totem is relying on clutter, we're fairly boned. 18:10:23 totem-3.2.0/src/backend/totem-aspect-frame.c is explicitly using clutter. 18:10:25 did anyone already try to reproduce this with 3.2.1? there's quite many fixes in most new gnome-packages 18:11:51 it sounds like we're ACK overall? 18:12:02 3.2.1 doesn't seem to have any clutter related changes 18:12:25 red_alert: i tried it with tc2, so yes. 18:12:32 adamw: okay :) 18:12:36 tflink: ack :) 18:12:44 ack, yeah, but we may have to drop it if it's simply not practical to fix. 18:12:49 reluctant ACK from me as well 18:12:53 i'll try and get upstream clutter to provide an opinion 18:12:59 #agreed - 747276 - AcceptedBlocker - Violates the final release criterion: "All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items" 18:13:19 yeah, we'll have to deal with it if this becomes unrealistic to fix 18:13:30 OK, that's all of the proposed blockers 18:13:45 On to the proposed NTH!! 18:13:48 Whee! 18:13:53 #topic (747417) anaconda is ignoring kickstart --fsprofile when combined with --useexisting or --onpart 18:13:57 #link http://bugzilla.redhat.com/show_bug.cgi?id=747417 18:13:59 #info Proposed NTH, POST 18:14:11 +1 NTH 18:15:27 proposed #agreed - 747417 - This is a useful, straightforward patch that can't be fixed post-release 18:15:38 proposed #agreed - 747417 - AcceptedNTH - This is a useful, straightforward patch that can't be fixed post-release 18:15:57 ACK 18:16:00 ack 18:16:10 #agreed - 747417 - AcceptedNTH - This is a useful, straightforward patch that can't be fixed post-release 18:16:16 #topic (741045) /etc/default/grub is a config file and should not be overwritten at update 18:16:19 #link http://bugzilla.redhat.com/show_bug.cgi?id=741045 18:16:22 #info Proposed NTH, ON_QA 18:16:43 +1 NTH 18:16:46 this is annoying 18:18:01 mmf, i'm not sure it makes much sense to be nth, it can be fixed with an update 18:18:05 on second thought ... I'm not sure this needs to be t aken past freeze 18:18:14 if people just +1 the update it'll get in pre-freeze anyway. ;) 18:18:19 * tflink doesn't particularly care for NTH as we use it 18:18:28 yeah, -1 nth for me. 18:18:30 -1 NTH 18:18:31 the term, anyways 18:19:18 -1 NTH 18:19:19 proposed #agreed - 741045 - This issue is not critical and could be fixed post release and doesn't need to be taken past freeze 18:19:33 proposed #agreed - 741045 - RejectedNTH - This issue is not critical and could be fixed post release and doesn't need to be taken past freeze 18:19:34 ack 18:19:55 #agreed - 741045 - RejectedNTH - This issue is not critical and could be fixed post release and doesn't need to be taken past freeze 18:20:01 #topic (732654) during kernel update, grubby does not correctly update the "echo 'Loading ...' line 18:20:04 #link http://bugzilla.redhat.com/show_bug.cgi?id=732654 18:20:07 #info Proposed NTH, ASSIGNED 18:20:51 +1 NTH 18:21:33 well, again, this isn't an install time issue. it's an update issue. 18:21:36 so i don't see it as nth material. 18:22:25 I think of it as a polish issue 18:23:05 it's a polish issue, sure. how's that relevant to nth evaluation? 18:23:13 the bug _only_ happens when you do a yum kernel update 18:23:16 if it's a patch to grubby, does if affect initial install? 18:23:23 no, because initial install doesn't use grubby. 18:23:28 it uses mkconfig. 18:23:40 ah, ok 18:23:48 this only happens when grubby is copying the existing entry #0 for a new kernel, which happens when you yum install a new kernel. 18:24:28 IMHO we need to make sure there's a 0-day update available 18:24:43 as much as it would be nice to see this fixed, I agree that it isn't in nth land 18:25:19 red_alert: And that grubby gets updated before the kernel, right? 18:25:30 * jsmith changes his vote to -1 NTH 18:26:06 and remember, this has no actual practical impact. it's just a wrong message. 18:26:10 jsmith: uhm...I guess so :/ 18:26:20 proposed #agreed - 732654 - RejectedNTH - This is a polish issue that affects updates and could be fixed with a post-release update 18:26:25 jsmith: i don't think it's worth bothering with that. it's not like the bug breaks anything. 18:26:27 adamw: wrong version information can have a very practical impact in debugging ;) 18:26:31 adamw: Yeah, no practical impact, except confusion 18:26:35 red_alert: but it doesn't mean the output of uname -r is wrong. 18:26:51 the only thing that's wrong is a message you see for about 2s at boot time. 18:27:12 everything else you could query to find out what kernel you're using gives the right answer. it's just not a terribly critical bug. 18:27:24 it's a really simple patch, though 18:27:27 sure. 18:27:29 it's just not nth. 18:27:39 that doesn't mean that it should be taken past code freeze, though 18:27:40 tflink: ack 18:28:01 #agreed - 732654 - RejectedNTH - This is a polish issue that affects updates and could be fixed with a post-release update 18:28:12 #topic (747479) iscsi targets starting before network is up for non-critical mounts on boot 18:28:15 #link http://bugzilla.redhat.com/show_bug.cgi?id=747479 18:28:17 #info Proposed NTH, NEW 18:28:42 This one is borderline blocker since it does hit the final iSCSI criterion but only happens on minimal installs 18:29:25 Sounds like it's easily documented or worked around 18:29:33 I'm thinking NTH since it doesn't affect initial boot and the world won't end if this isn't fixed before release 18:29:53 Are we willing to risk accepting a change that might cause other problems? 18:30:06 Sounds like a one-liner in a couple of initscripts, right? 18:30:12 there should be a pre-freeze fix, the maintainer said that he's planning on making a new release this weekend 18:30:17 /opt is a non-essential filesystem 18:30:30 did you confirm this actually happens if you do the same with an essential filesystem? 18:30:34 i think systemd does handle them differently... 18:30:39 +1 NTH for me then 18:30:46 adamw: not sure what you're asking 18:30:57 well this doesn't violate the criterion exactly as described 18:30:59 no, this doesn't happen with an essential fs 18:31:01 the install succeeds, the system boots 18:31:05 hence the NTH 18:31:16 should minimal install actually support iscsi? doesn't exactly sound minimal to me 18:31:18 okay, cool. then definitely not blocker 18:31:20 the system doesn't boot with the layout specified @ install time 18:31:40 but it _boots_. 18:31:41 red_alert: why not? The parts are there 18:31:44 and you can presumably mount /opt manually. 18:31:58 brb 18:31:58 wouldn't an update fix this? 18:32:11 probably 18:32:22 if it can be fixed with an update i might even be -1 nth... 18:33:00 assuming that it was fixed w/ an update, the first boot would be missing part of the filesystem that would return after updating 18:33:55 are /home and /root essential in this context? 18:34:07 the issue is that iscsi is trying to start before network due to a change in how systemd interprets init script dependencies 18:34:27 so everything is pretty much set up correctly, just doesn't start propoerly 18:34:40 red_alert: yes, those would be started by dracut, not systemd 18:35:21 there is a blocker for that issue with a fix 18:35:22 * adamw is +/-0 18:35:58 I think that I'd be ok with NTH on this as long as it doesn't break non-minimal use cases 18:36:31 but not enough testing has been done with the fix to know if changing the depends in the init script will affect the NM use case 18:37:13 -1 NTH, but should be documented 18:38:16 I'm probably at +.5 on this 18:38:46 any other votes? 18:40:12 I assume that's a no 18:40:14 I gate it a +1 earlier 18:40:17 s/gate/gave/ 18:40:26 ah, I missed that 18:40:45 which means we're at +.5 18:41:11 I could always change my vote to +.5, which would put us at zero :-p 18:41:24 you're a helper! 18:41:56 I think +.5 is a very clear result :) 18:42:02 Better than 0 18:42:02 heh 18:42:35 so, we don't actually know what to do if no-one changes their vote. 18:42:42 we usually go by consensus. 18:42:53 +1 NTH 18:42:58 proposed #agreed - 747479 - AcceptedNTH - This isn't critical but does affect initial boot of certain systems. Fix will be considered ONLY if other related iSCSI use cases are well tested. 18:43:26 hrm, s/considered/accepted past freeze 18:43:53 okay. 18:44:03 ack 18:44:54 #agreed - 747479 - AcceptedNTH - This isn't critical but does affect initial boot of certain systems. Fix will be accepted past freeze ONLY if other related iSCSI use cases are well tested. 18:45:05 ok, that would be all of the proposed NTH 18:45:39 accepted blocker time! 18:46:02 #topic (668282) PackageKit yum backend uses incorrect encoding for dynamic category names, makes them show up with '?' characters in KPackageKit 18:46:05 #link http://bugzilla.redhat.com/show_bug.cgi?id=668282 18:46:07 #info Accepted Blocker, ASSIGNED 18:46:36 looks like we're getting somewhere on this one 18:47:44 not sure we need to do much, hughsie is turning out test patches 18:48:13 yeah 18:48:41 proposed #agreed - 668282 - There seems to be decent progress here, doesn't seem to need anything 18:49:14 ack 18:49:41 ack 18:49:43 #agreed - 668282 - There seems to be decent progress here, doesn't seem to need anything 18:49:48 #topic (728301) F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem 18:49:51 #link http://bugzilla.redhat.com/show_bug.cgi?id=728301 18:49:54 #info Accepted Blocker, ON_QA 18:50:28 sounds like this can be closed 18:50:38 yup, looks like it 18:50:43 but there might be another issue with cfg generation 18:51:15 nah, it was just a dupe of the preupgrade bug. 18:51:23 proposed #agreed - 728301 - has been verified, can close 18:51:34 ack 18:51:39 (actually i closed it already.) 18:51:41 #agreed - 728301 - has been verified, can close 18:51:50 #topic (740062) fcoe.py fails to detect FCoE NIC due to extraneous newline character 18:51:53 #link http://bugzilla.redhat.com/show_bug.cgi?id=740062 18:51:56 #info Accepted Blocker, MODIFIED 18:52:14 this still needs re-testing 18:52:53 +1, assuming it's fixed 18:52:59 proposed #agreed - 740062 - Fix is available, needs verification. Poke reporter and ask for results 18:53:09 ack 18:53:11 ACK 18:53:30 #agreed - 740062 - Fix is available, needs verification. Poke reporter and ask for results 18:53:35 #topic (736893) New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot 18:53:38 #link http://bugzilla.redhat.com/show_bug.cgi?id=736893 18:53:41 #info Accepted Blocker, ASSIGNED 18:54:33 looks like we finally got more info from the reporter 18:54:42 and need dev input now 18:55:11 proposed #agreed - 736893 - Received data from reporter, waiting for dev input 18:55:30 ACK 18:55:32 ack 18:55:32 ack 18:55:43 #agreed - 736893 - Received data from reporter, waiting for dev input 18:55:48 #topic (706756) No translation on Login-Page of the reboot-menu 18:55:48 #link http://bugzilla.redhat.com/show_bug.cgi?id=706756 18:55:48 #info Accepted Blocker, NEW 18:56:42 sounds like this was fixed and the tester needs to change language in a different place? 18:57:27 possibly. 18:57:40 it's a theory, i'm not guaranteeing anything. but i'd like more info from the reporter. 18:58:02 proposed #agreed - 706756 - Fix is available, waiting for testing. Ask for re-verification with more clarity on the method used to switch languages 18:58:17 proposed #agreed - 706756 - Potential fix is available, waiting for testing. Ask for re-verification with more clarity on the method used to switch languages 18:59:00 ack 18:59:25 ack 18:59:30 #agreed - 706756 - Potential fix is available, waiting for testing. Ask for re-verification with more clarity on the method used to switch languages 18:59:35 #topic (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2 18:59:39 #link http://bugzilla.redhat.com/show_bug.cgi?id=742226 18:59:41 #info Accepted Blocker, NEW 18:59:58 we have yet another reporter for this 19:00:12 I think that pjones was looking at it but had not been able to reproduce as of yet? 19:03:02 I would assume bcl is looking into it instead since he's reproduced it? 19:03:48 adamw: do you know what the status of this is? 19:03:54 sec 19:04:04 yeah, pjones is having trouble with his hardware for that one 19:04:09 bcl has hardware to reproduce and is looking at it 19:04:21 pjones can probably get hardware on monday and is going to try coding a no-look fix in the mean time 19:04:47 proposed #agreed - 742226 - Progress is being made on this, doesn't need anything ATM 19:05:19 ack 19:05:26 #agreed - 742226 - Progress is being made on this, doesn't need anything ATM 19:05:33 #topic (741950) F16: Can't use keyboard when installing F16-Alpha under Xen (regression) as guest 19:05:36 #link http://bugzilla.redhat.com/show_bug.cgi?id=741950 19:05:39 #info Accepted Blocker, MODIFIED 19:05:44 This might be able to be closed 19:05:52 I think that it's been tested with the official build 19:05:56 but nothing in bugzilla yet 19:06:32 proposed #agreed - 741950 - Can likely be closed, ask for verification with actual lorax build 19:06:35 we should ask for re-testing with tc2, yep 19:06:52 proposed #agreed - 741950 - Can likely be closed, ask for verification with actual lorax built initrd 19:06:59 #agreed - 741950 - Can likely be closed, ask for verification with actual lorax built initrd 19:07:07 #topic (743281) Disk encryption with national keymap doesn't work 19:07:07 #link http://bugzilla.redhat.com/show_bug.cgi?id=743281 19:07:08 #info Accepted Blocker, NEW 19:08:26 wow, that's a nasty one :/ 19:08:32 it sounds like some progress is being made on this one 19:09:20 yeah 19:09:33 and almost sounds like it only affects a small number of non-US keymaps 19:09:42 possibly czech only 19:09:46 well, i'm not sure we know the complete set yet. 19:09:57 "Slovak (qwerty)" doesn't work" 19:10:03 but then, slovak and czech are closely related, heh. 19:10:11 oh, "turkish" doesn't work. 19:10:18 which is fairly significant. 19:10:20 proposed #agreed - 743281 - Progress is being made, need input from s-c-k devs 19:11:09 ack 19:11:32 #agreed - 743281 - Progress is being made, need input from s-c-k devs 19:11:35 we do at least have a workaround - flip the keyboard mode before entering password, by pressing 'pause'. at least, that works for czech. 19:11:38 ack 19:11:40 ok, that would be everything 19:11:47 did I miss any bugs? 19:12:19 #topic open floor 19:12:34 I do have a questions for everyone, though 19:12:44 is there anything I can do to make these meetings go faster? 19:13:26 less detail in the proposals, etc.? 19:13:33 i think we're doing pretty well actually. 19:13:46 they're already shorter than f15 ones wer. 19:13:52 I guess I just get frustrated with all the wasted time 19:14:47 oh well, at some point I want to write an app to help run this so I can multitask, too :) 19:15:02 anyhow, if there are no other topics ... 19:15:16 i don't think the time's wasted... 19:15:19 nope, nothing here 19:15:39 adamw: for the meeting, no. it's the 2 minute pauses between proposal and votes that get to me 19:16:19 #info next blocker but review meeting will be 2011-10-28 @ 17:00 UTC 19:16:41 * tflink sets fuse for 4 minutes 19:16:59 just wanted to say that QA is really doing a great job...there's so many nasty and hard-to-catch bugs that got reported and progress looking very good :) 19:21:54 * tflink will send out minutes shortly 19:21:57 #endmeeting