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