17:01:30 <tflink> #startmeeting f18final-blocker-review-4
17:01:30 <zodbot> Meeting started Wed Dec 12 17:01:30 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:30 <tflink> #meetingname f18final-blocker-review-4
17:01:30 <tflink> #topic Roll Call
17:01:30 <zodbot> The meeting name has been set to 'f18final-blocker-review-4'
17:01:45 <tflink> Who's here for some blocker review fun time?
17:02:24 * jreznik hides
17:02:37 <tflink> that's an option? I wish I had known that
17:02:45 * tflink runs but can't hide
17:03:09 * jreznik is going to catch tflink
17:03:12 * kparal is hungry
17:03:21 <tflink> jreznik: I thought you were hiding
17:03:45 <jreznik> tflink: you never know where I am hiding - so you never know where I can catch you!
17:04:49 * satellit listening
17:04:58 <jreznik> anyone else around? adamw, Viking-Ice...
17:05:11 <kparal> don't wake the dragon...
17:07:00 * tflink waits, hoping that we get at least 1 more person
17:08:54 * adamw here
17:08:57 <adamw> sorry, cleaning up hairballs
17:09:01 <kparal> should we invite some folks from #anaconda?
17:09:20 <Viking-Ice> I'm pretty busy @dayjob so I dont know how much I can attend today
17:09:25 <tflink> adamw: that sounds like you might need to go to the doctor
17:10:19 <adamw> not MY hairballs.
17:10:24 <adamw> those I donate to the Smithsonian.
17:12:06 <tflink> wow, someone thinks they're important :-P
17:12:11 <tflink> #chair adamw kparal
17:12:11 <zodbot> Current chairs: adamw kparal tflink
17:12:50 <tflink> OK, I think we have enough people to get started
17:13:22 <tflink> #topic Introduction
17:13:27 <tflink> Why are we here?
17:13:27 <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:13:33 <tflink> #info We'll be following the process outlined at:
17:13:33 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:13:39 <tflink> #info The bugs up for review today are available at:
17:13:39 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:14:05 <tflink> #info note that due to the length of the current blocker list, we'll be working off the bugs marked for discussion at:
17:14:20 <tflink> #link http://tflink.fedorapeople.org/blockerbugs/sorted/sortedBlockers.html
17:14:32 <tflink> #info The criteria for release blocking bugs can be found at:
17:14:32 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:14:32 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:14:32 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:15:09 <tflink> In total, we currently have:
17:15:43 <tflink> #info 24 Proposed Blockers
17:15:43 <tflink> #info 21 Accepted Blockers
17:15:43 <tflink> #info 35 Proposed NTH
17:15:43 <tflink> #info 6 Accepted NTH
17:15:58 <tflink> #info 12 proposed blockers ready for discussion
17:16:30 <tflink> Any objections to starting with the proposed blockers marked ready to discuss?
17:16:48 * kparal says go!
17:16:48 <jreznik> no objections
17:17:05 <tflink> #topic (885284) grub is not installed in an all defaults autopart installation, system not bootable
17:17:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885284
17:17:10 <buggbot> Bug 885284: high, unspecified, ---, anaconda-maint-list, MODIFIED , grub is not installed in an all defaults autopart installation, system not bootable
17:17:11 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:17:33 <kparal> +1 blocker
17:17:42 <kparal> completely clean disk -> no grub installed
17:17:47 <tflink> yeah, this seems like a pretty clear blocker
17:18:09 <Viking-Ice> +1 blocker
17:18:12 <jreznik> +1 blocker
17:18:31 * tflink looks for criterion
17:18:46 <kparal> "must boot" criterion
17:18:59 <adamw> +1
17:19:43 <kparal> technically we are voting on a build that is not stable. but I don't think it matters in the case of anaconda
17:19:55 <tflink> proposed #agreed 885284 - AcceptedBlocker - Violates the following F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode..."
17:20:11 <kparal> ack
17:21:46 <jreznik> ack
17:22:37 <Viking-Ice> ack
17:22:47 <adamw> ack
17:22:50 <tflink> #agreed 885284 - AcceptedBlocker - Violates the following F18 alpha release criterion: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode..."
17:22:57 <tflink> topic (879046) MacBookPro i7:EFI boot of TC-1 dd live-desktop USB: Anaconda does not create a bootable USB HD  after install finishes
17:23:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=879046
17:23:01 <buggbot> Bug 879046: medium, unspecified, ---, mjg59, ASSIGNED , MacBookPro i7:EFI boot of TC-1 dd live-desktop USB: Anaconda does not create a bootable USB HD  after install finishes
17:23:02 <adamw> kparal: makes sure we don't push it stable too.
17:23:02 <tflink> #info Proposed Blocker, mactel-boot, ASSIGNED
17:24:38 <tflink> if I'm understanding correctly, this would keep any install on apple hardware from booting post-install
17:24:38 <kparal> so is this an issue just with dd?
17:24:51 <tflink> it doesn't sound like it
17:24:52 <kparal> and why he says "bootable USB HD"?
17:24:56 <Viking-Ice> -1 nth
17:25:00 <Viking-Ice> mean +1 nth
17:25:01 <kparal> does it work on internal HDD?
17:25:14 <tflink> I think he does a lot of installs to external HDs
17:25:37 <kparal> adamw: do you know more details?
17:25:38 <Viking-Ice> in anycase dd can be fixed via update
17:25:53 <adamw> just a sec, catching up with the last bug
17:25:54 <Viking-Ice> and this is specific to mac's hw
17:26:08 <tflink> I don't think this is a problem with dd
17:26:16 <tflink> it's a problem with the boot mechanism as installed by anaconda
17:26:16 <adamw> Viking-Ice: from what mjg59 told me this is not hw-specific
17:26:20 <adamw> but it would be good to check in
17:26:30 <tflink> adamw: isn't it specific to apple hw?
17:26:33 <kparal> we can definitely try to reproduce, we have Mac Mini in office
17:26:51 <tflink> do we want to punt for more info?
17:26:59 <adamw> tflink: well yeah, but I mean it's not specific to any particular model
17:27:06 <adamw> i'm asking mjg59 now, we'll get an answer if he's around
17:27:19 <jreznik> kparal: please do and we can punt it for now until we will get more info...
17:27:28 <Viking-Ice> but it's spesific to mac which is probably less used under fedora then graphical cards
17:27:57 <Viking-Ice> and we waived those various graphics cards
17:28:08 <kparal> Viking-Ice: depends whether we can fix it easily or not
17:28:20 <kparal> graphics drivers we can not
17:28:37 <Viking-Ice> ben and david gone?
17:29:06 <adamw> <adamw> mjg59: is it correct to say that https://bugzilla.redhat.com/show_bug.cgi?id=879046 is a generic issue with mactel installs?
17:29:08 <buggbot> Bug 879046: medium, unspecified, ---, mjg59, ASSIGNED , MacBookPro i7:EFI boot of TC-1 dd live-desktop USB: Anaconda does not create a bootable USB HD  after install finishes
17:29:20 <adamw> <mjg59> adamw: Correct
17:29:24 <adamw> on that basis, +1 from me.
17:29:33 <tflink> +1
17:30:14 <adamw> oh, sigh, there was a clarification question
17:30:15 <kparal> and I assume we have someone who is able to fix this
17:30:22 <adamw> <adamw>  none of them will work until it's fixed - the HW and install mechanism don't matter?
17:30:25 <adamw> we already have the fix.
17:30:29 <tflink> a fix is available, no?
17:30:29 <Viking-Ice> weak +1 nth for me
17:30:47 <Viking-Ice> let's pull in the fix but not block the release...
17:31:08 <kparal> +1 blocker from me, it breaks all macs and we already have a fix
17:32:09 <kparal> if situation changes (patch doesn't work and it's really hard fix properly) we can re-evaluate
17:32:17 <tflink> I see +3/-1 blocker, any other votes?
17:32:26 * tflink assumes that Viking-Ice is -1
17:33:00 <Viking-Ice> yup -1 blocker +1 nth just trying to figure out how apple hw is good enough to block the release while intel/nvidia and ati graphics are not /me searches for consistency
17:33:08 <jreznik> kparal: in such case I'm +1 and re-evaluate in case of issues, but definitely +1 nth
17:33:59 <tflink> proposed #agreed 885284 - AcceptedBlocker - Violates the following F18 alpha release criterion for Apple hardware: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode..."
17:34:17 <kparal> ack
17:34:41 <adamw> Viking-Ice: if 'all nvidia graphics' were broken obviously that'd block release.
17:34:44 <adamw> 'one nvidia card' is rather different.
17:34:45 <adamw> ack
17:34:59 <jreznik> patch - add that re-evaluate part as kparal requested
17:35:44 <tflink> why not just punt blocker and accept NTH, then?
17:35:57 <adamw> punt for what? whether the update works?
17:35:58 <kparal> I think that that part applies just to about any bug. if we discover new information, the resolution can change
17:36:08 <adamw> if the bug's fixed it's a blocker, if it's not fixed it isn't? seems pointless
17:36:11 <adamw> if the update works it'll be closed
17:36:42 <tflink> sure, we can revisit but I think that's implicit with any of the blocker/nth bugs
17:37:15 <jreznik> well, adamw is right... /me is just getting more - everything is ticking bomb :) go on
17:37:31 <tflink> jreznik: so is that an ack?
17:37:36 <jreznik> ack
17:37:47 <tflink> #agreed 885284 - AcceptedBlocker - Violates the following F18 alpha release criterion for Apple hardware: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode...".
17:37:55 <tflink> #topic (866887) Anaconda defaults keyboard layout to US for all languages
17:37:58 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=866887
17:38:00 <buggbot> Bug 866887: unspecified, unspecified, ---, vpodzime, MODIFIED , Anaconda defaults keyboard layout to US for all languages
17:38:01 <tflink> #info Proposed Blocker, anaconda, MODIFIED
17:38:43 <kparal> I have created a summary in c24
17:38:59 <kparal> as agreed on Monday
17:39:20 <tflink> my current understanding is that this is is to change anaconda's behavior back to what it was WRT keyboard layout selection @ install time
17:39:27 <tflink> not sure it's a blocker, though
17:39:51 <kparal> -1 blocker from me
17:39:56 <kparal> but +1 nth
17:40:01 <kparal> since it's freeze time now
17:40:14 <jreznik> -1 blocker/+1 nth
17:40:37 <adamw> agreed, -1/+1
17:40:59 * tflink is -1/+1 for the record
17:41:10 <jreznik> checkbox is not probably the most elegant solution but...
17:42:09 <tflink> proposed #agreed 866887 - RejectedBlocker AcceptedNTH - While this doesn't directly violate any of the F18 release criteria, it is a non-obvious annoyance for users of non-US keyboards. A tested fix would be considered past freeze.
17:42:28 <adamw> ack
17:42:35 <kparal> ack
17:43:14 <Viking-Ice> ack
17:43:46 <tflink> #agreed 866887 - RejectedBlocker AcceptedNTH - While this doesn't directly violate any of the F18 release criteria, it is a non-obvious annoyance for users of non-US keyboards. A tested fix would be considered past freeze.
17:43:53 <tflink> #topic (885004) DeviceCreateError: ("Can't have overlapping partitions.", 'vda1')
17:43:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885004
17:43:58 <buggbot> Bug 885004: unspecified, unspecified, ---, dlehman, VERIFIED , DeviceCreateError: ("Can't have overlapping partitions.", 'vda1')
17:43:59 <tflink> #info Proposed Blocker, anaconda, VERIFIED
17:44:11 <kparal> that's verified, skip?
17:44:25 <tflink> whoops, yeah
17:44:29 <tflink> #undo
17:44:29 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x11db9590>
17:44:31 <tflink> #undo
17:44:31 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x176c7510>
17:44:32 <tflink> #undo
17:44:32 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x176c7550>
17:44:45 <tflink> #topic (886061) core fedora repository error must be fatal, otherwise the upgraded system might be broken heavily
17:44:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886061
17:44:50 <buggbot> Bug 886061: unspecified, unspecified, ---, wwoods, NEW , core fedora repository error must be fatal, otherwise the upgraded system might be broken heavily
17:44:51 <tflink> #info Proposed Blocker, fedup, NEW
17:44:52 <adamw> wait
17:45:00 <adamw> why are we skipping proposed VERIFIED?
17:45:04 <adamw> i thought we skipped accepted verified
17:45:11 <adamw> well, guess it doesn't matter too much.
17:45:18 <tflink> either way
17:46:44 <adamw> yeah, go ahead
17:47:18 <kparal> if would be great to have wwoods' feedback here. but I think technically the issue is valid
17:47:19 <tflink> kparal: was the upgrade.img and vmlinuz downloaded in this case?
17:47:37 <kparal> tflink: yes, there was no problem with instrepo, just fedora.repo failed to work
17:48:11 <tflink> then I'm probably +1 blocker
17:48:15 <kparal> I managed to upgrade into a system with fc17 kernel
17:48:34 <tflink> but I suspect that fedup would have explodified after reboot without borking the system
17:48:54 <Viking-Ice> +1 blocker
17:50:01 <adamw> this seems pretty bad, yeah
17:50:25 <adamw> be interesting to know how different this is to preupgrade behaviour, though
17:50:39 <tflink> true
17:50:40 * adamw pings wwoods
17:51:40 <kparal> we can discuss in #devel if wwoods is present and come back to it in a while
17:51:49 <Viking-Ice> yup
17:52:23 <adamw> yeah, either +1 or punt till later in the meeting or next meeting
17:52:29 <jreznik> ok and would be great to find out how preupgrade sorted this - but even it wouldn't be regression, it is still bad bug
17:53:39 <kparal> well one option is to try again a few times, second option is to halt and ask user to try later. it can be combined
17:53:41 <tflink> thoughts on which way to go?
17:53:48 <tflink> punt vs +1
17:53:52 <kparal> adamw: wwoods responding?
17:53:55 <adamw> nothing from wwoods yet
17:54:36 <kparal> let's punt
17:56:07 <tflink> it doesn't sounds like anyone is saying 'no punt'
17:56:42 <tflink> proposed #agreed 886061 - This sounds like a blocker but we'd like to get more developer input before making a decision on blocker satus
17:56:45 <tflink> proposed #agreed 886061 - This sounds like a blocker but we'd like to get more developer input before making a decision on blocker status
17:56:45 <jreznik> and keep trying to get more info from wwoods...
17:56:49 <tflink> spelling
17:56:50 <Viking-Ice> I say no to 'no punt'
17:56:54 <Viking-Ice> ack
17:57:07 <kparal> ack
17:57:14 <kparal> I have put needinfo on wwoods in that bugreport
17:58:14 <jreznik> ack
17:58:23 <tflink> #agreed 886061 - This sounds like a blocker but we'd like to get more developer input before making a decision on blocker status
17:58:34 <tflink> #topic (886319) ImportError: No module named lib.space
17:58:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886319
17:58:34 <tflink> #info Proposed Blocker, anaconda, NEW
17:58:36 <buggbot> Bug 886319: unspecified, unspecified, ---, anaconda-maint-list, MODIFIED , ImportError: No module named lib.space
17:58:57 <tflink> I believe this has been fixed or is about to
17:59:18 <tflink> IIRC, the anaconda build last night failed due to a missing makefile change associated with lib.space
17:59:27 <Viking-Ice> ah
17:59:33 <Viking-Ice> +1 blocker
17:59:37 <kparal> +1
17:59:56 <tflink> Assuming I understand this all, +1
17:59:58 <adamw> +1
18:01:54 <jreznik> seems +1 for me too
18:01:57 <tflink> proposed #agreed 886319 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
18:02:02 <adamw> ack
18:02:03 <kparal> ack
18:02:05 <Viking-Ice> ack
18:02:24 <jreznik> ack
18:02:28 <tflink> #agreed 886319 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
18:02:43 <tflink> #topic (886199) mokutil calculates incorrect signature size
18:02:43 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886199
18:02:43 <tflink> #info Proposed Blocker, shim, NEW
18:02:45 <buggbot> Bug 886199: unspecified, unspecified, ---, mjg59, NEW , mokutil calculates incorrect signature size
18:03:07 <tflink> my question here is whether the blocker process is right for this one
18:03:25 <tflink> IIRC, SB is a feature. We don't block for feature completion
18:03:42 <kparal> what's the impact?
18:03:51 <tflink> SB doesn't work, I think
18:04:06 <kparal> or just private certs don't work?
18:04:14 <Viking-Ice> punt to fesco
18:04:22 <adamw> it's kinda twin-track
18:04:26 <tflink> kparal: that's a good question. not sure
18:04:36 <adamw> we *could* take SB as a final blocker on grounds of conditional 'installer must boot' violation
18:04:42 <adamw> we chose not to for beta, but we could for final
18:04:44 <kparal> ping jwb?
18:04:53 <adamw> then if we don't, we kick it to fesco
18:05:08 <Viking-Ice> I think we should just punt this to fesco
18:05:11 <nirik> fesco has already determined that working SB is a blocker.
18:05:21 <jreznik> yep, SB is standard blocker now
18:05:21 <Viking-Ice> oh in that case +1 blocker
18:05:26 <tflink> sure, but that's still outside the blocker process
18:05:32 <jreznik> tflink: why?
18:05:36 <tflink> we have no release criteria for features
18:05:37 <Viking-Ice> flink must boot
18:05:43 <adamw> jreznik: we separate feature process from release validation usually
18:05:44 <Viking-Ice> mean tflink
18:05:50 <jreznik> fesco said - SB is blocker and it has to boot
18:05:50 <adamw> though with a feature like this it becomes muddy
18:06:03 <tflink> then they can block release on this
18:06:05 <nirik> whatever process you want to do. we could have fesco just stamp blocker on it... or whatever
18:06:19 <adamw> i don't mind us taking it or fesco doing it, really.
18:06:21 <tflink> I'm not going to fight it too much, though
18:06:31 <jreznik> adamw: yep, as FESCo said - SB is required boot method -> so the criterion system has to boot applies
18:06:31 <Viking-Ice> let's just stamp it blocked by fesco
18:06:36 <adamw> tflink: it's a bit muddy for this one as a failure of the feature *is* a failure to install on relevant hardware
18:06:43 <tflink> I'd say punt for now
18:06:46 <adamw> jreznik: if they specifically put it that way, +1
18:06:50 <Viking-Ice> we probably need to update the criteria to cover secure boot in F19
18:06:52 <tflink> not sure it's worth blocking if the MS cert works
18:07:02 <adamw> oh yeah, we still have that to establish
18:07:08 <jreznik> tflink: yep, if MS one works, it's not blocker
18:07:50 <tflink> proposed #agreed 886199 - We need more information on whether this affects more than secondary certs before making a decision on blocker status. Will revisit later.
18:07:53 <tflink> I'
18:08:00 <tflink> I'd probably be +1 NTH, though
18:08:09 <adamw> <pjones> just private/personal signatures
18:08:11 <adamw> (from privmsg)
18:08:17 <adamw> on that basis, -1 / weak +1 nth
18:08:34 <tflink> yeah, same here
18:08:49 <Viking-Ice> with my qa hat -1/-1
18:09:04 <tflink> Viking-Ice: why -1 NTH?
18:09:07 <kparal> -1/+1. private certs will be important for people wanting to play with it
18:09:11 <tflink> I suppose this could be fixed with an update
18:09:12 * jreznik just pinged jwb
18:09:22 <tflink> I don't think you can install a private cert in anaconda
18:09:27 <Viking-Ice> tflink, private/personal signatures
18:09:47 <Viking-Ice> what if there is something wrong with those signatures
18:09:52 <Viking-Ice> how can we test it etc...
18:09:58 <jreznik> ah I see pjones reply - -1/-1 (as tflink said - it could be fixed with an update probably)
18:09:59 <adamw> pjones says he *thinks* it can be 0-day but it'd be better to pull it in
18:10:10 <adamw> and since it doesn't affect anything but SB, pretty safe to poke it
18:10:20 <tflink> Viking-Ice: huh? this is a bug about the ability to install _any_ signatures
18:10:22 <Viking-Ice> well not if it breaks SB
18:10:26 <adamw> fixed build is ready to go if we vote NTH
18:10:46 * Viking-Ice swings to a weak +1 nth
18:10:52 <Viking-Ice> since there is a fix...
18:10:57 <tflink> I see +3/-1 NTH
18:11:00 <tflink> nvm, slow
18:11:44 <tflink> proposed #agreed 886199 - RejectedBlocker AcceptedNTH - This doesn't viiolate any F18 release criteria but would be better to pull in before release in case secureboot is affected. A tested fix would be considered after freeze.
18:11:56 <Viking-Ice> ack
18:12:14 <jreznik> ack
18:12:28 <jwb> hi.  i'm running the fesco meeting, but i can try and answer anything further that comes up on the bugs i proposed
18:12:32 <adamw> ack
18:12:47 <adamw> jwb: we'll ping you if needed, thanks!
18:13:10 <tflink> #agreed 886199 - RejectedBlocker AcceptedNTH - This doesn't viiolate any F18 release criteria but would be better to pull in before release in case secureboot is affected. A tested fix would be considered after freeze.
18:13:17 <tflink> #topic (885912) Final-TC1 Auto Partition will not produce working Dual Boot
18:13:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885912
18:13:22 <buggbot> Bug 885912: unspecified, unspecified, ---, anaconda-maint-list, NEW , Final-TC1 Auto Partition will not produce working Dual Boot
18:13:23 <tflink> #info Proposed Blocker, anaconda, NEW
18:13:42 <tflink> I'm -1 on this - it sounds like an available space issue
18:15:02 <Viking-Ice> I'm -1 personally ( since I'm against that dualboot criteria ) but our criteria is our criteria hence +1
18:15:06 <kparal> do I understand correctly that windows is missing in grub menu?
18:15:30 <pjones> I don't see how this could be a blocker at all - that's not something we've supported in the past
18:15:35 <pjones> kparal: yeah
18:15:37 <pjones> I think so anyway
18:15:44 <kparal> it's blocker per criterioa
18:15:56 <Viking-Ice> " The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working
18:15:56 <Viking-Ice> "
18:16:10 <pjones> The bootloader can do that.  It is not configured to.
18:16:24 <pjones> Also the latter option appears to still work
18:16:37 <kparal> the latter?
18:16:48 <pjones> leave it untouched.  you can opt not to install the bootloader.
18:17:06 <Viking-Ice> "If I use a 30GB disk and reduce windows to 18GB and have 12GB for Fedora then dual isntall fails.  If I use a 40GB disk and reduce windows to 28GB and have 12GB for Fedora then Dual Install Works."
18:17:11 <tflink> I didn't think that was working ATM but that's a different but and might have been fixed already
18:17:12 <Viking-Ice> size issue for sure
18:17:46 <kparal> it might be relevant to https://bugzilla.redhat.com/show_bug.cgi?id=875944, yes
18:17:49 <buggbot> Bug 875944: unspecified, unspecified, ---, anaconda-maint-list, NEW , shrinking Windows partition creates an unusable dual-boot setup
18:17:51 <adamw> if it's only a shrink issue then -1
18:17:55 <pjones> tflink: fair
18:18:14 <adamw> the criterion explicitly specifies existing free space because we don't want to block on shrink problems
18:18:28 <tflink> good point
18:18:31 <tflink> -1
18:18:33 <Viking-Ice> but is it an shrink or size or both?
18:18:50 <adamw> i'm not sure we have enough data
18:18:54 <adamw> i'm either -1 or punt i guess
18:18:58 <Viking-Ice> punt for more data
18:20:28 <tflink> other thoughts?
18:20:49 <kparal> the criterion says free space, but it doesn't say I can't use anaconda to shrink the existing partition
18:20:56 * jreznik is not sure he understand it correctly...
18:21:21 <kparal> adamw: so the criteria is violated if I used gparted first and then use anaconda, but not violated if I shrink using anaconda?
18:21:21 <adamw> kparal: it's intended to specifically not cover that.
18:21:31 <Viking-Ice> let's punt and try to determine what's causing this exactly then make informed decision based on those findings
18:21:35 <adamw> kparal: assuming the windows install still worked post gparted-shrink, yes
18:21:53 <adamw> kparal: the entry conditions are that you have a working windows install and enough free space for a new fedora install
18:22:21 <kparal> hmm, I'm OK with seeing it this way, but we should clearly state this is CommonBugs or somewhere
18:22:30 <kparal> I don't think this is clearly communicated to the users
18:22:34 <Viking-Ice> that does not explain the size problem unless 12GB is not enough for fedora these days ( which it should be plenty )
18:22:49 <adamw> Viking-Ice: if it's to do with size it's on the *windows* side not the fedora one
18:22:54 <kparal> s/is/in
18:23:00 <adamw> note that fedora gets 12GB in both cases: it's the size of the windows partition that's different
18:23:28 <adamw> kparal: if you shrink with anaconda and hit a bug that's clearly not to do with the shrinking it can be a blocker bug, it's just that anaconda team doesn't want us to block on shrink problems
18:23:33 <kparal> I have seen weird windows resizing issues too, but grub always worked for me
18:23:42 <Viking-Ice> ah see it now could also be the manual vs auto partitioning problem
18:24:03 <adamw> Viking-Ice: https://bugzilla.redhat.com/show_bug.cgi?id=885912#c5
18:24:05 <buggbot> Bug 885912: unspecified, unspecified, ---, anaconda-maint-list, NEW , Final-TC1 Auto Partition will not produce working Dual Boot
18:24:27 <adamw> ah, yeah, later he starts talking about auto vs. manual
18:24:30 <kparal> my opinion is that anaconda should not offer ntfs resizing if they don't want to deal with the issues
18:24:31 <adamw> without much detail
18:24:39 <adamw> seems like a definite punt.
18:25:23 <adamw> i don't see how it could really have much to do with partitioning as the os-detect stuff is just part of grub and not to do with our partitioning code, but hey. maybe we're running mklabel when we shouldn't or something.
18:25:32 <tflink> proposed #agreed 885912 - It isn't completely clear what is causing this issue and depending on the details, this may or may not be a blocker. Will revisit when more information is available.
18:25:37 <adamw> ack
18:25:37 <Viking-Ice> ack
18:25:40 <adamw> i can do some poking of this
18:25:47 <kparal> adamw: I think broken resize can break os-detect detection
18:25:50 <Viking-Ice> poke away
18:25:57 <kparal> ack
18:26:00 <adamw> #action adamw to poke windows multiboot (885912), see if he can reproduce and identify the trigger
18:26:16 <adamw> kparal: the resize seems more of a plausible candidate to me, yeah, but we need to check
18:26:49 <tflink> #agreed 885912 - It isn't completely clear what is causing this issue and depending on the details, this may or may not be a blocker. Will revisit when more information is available.
18:26:53 <kparal> adamw: you might find some additional pointers in my story (875944)
18:27:01 <tflink> #topic (853636) poor checking of storage config against software set space needs
18:27:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=853636
18:27:05 <buggbot> Bug 853636: unspecified, unspecified, ---, dlehman, MODIFIED , poor checking of storage config against software set space needs
18:27:06 <tflink> #info Proposed Blocker, anaconda, MODIFIED
18:28:06 <kparal> this is a nasty bug
18:28:13 <Viking-Ice> agreed
18:28:25 <kparal> anaconda will happily try to create and install to 1MB / partition
18:28:47 <adamw> this seems somewhat messy
18:29:00 <adamw> claims that the reports are different bugs, people with huge / partitions...
18:29:19 <kparal> I see just the last comment to say that
18:29:20 <adamw> anyone have a clear story on this one?
18:29:26 <kparal> but the original issue should be still valid
18:29:40 <adamw> c#15 says 2GB /
18:29:46 <kparal> just create a very small / (a mistake or insufficient knowledge) and anaconda accepts it
18:29:53 <tflink> adamw: I think that there may have been more going on in the report that was deemed different
18:29:54 <kparal> then breaks in the middle of the process
18:30:47 <Viking-Ice> +1 blocker
18:30:50 <adamw> but if issue as described by kparal still exists, sure, +1
18:30:50 <Viking-Ice> "The installer must be able to install each of the release blocking desktops, as well as the minimal package set, with each supported installation method "
18:30:55 * kparal testing quickly
18:30:59 <adamw> isn't there a better one in the partition criteria for beta?
18:31:03 <adamw> something about rejecting obviously invalid
18:31:53 <tflink> rejecting without crashing
18:31:59 <adamw> right
18:32:27 <kparal> I have just "mistakenly" created 100 MB / instead of 100 GB /. installation started fine
18:32:32 <tflink> proposed #agreed 853636 - AcceptedBlocker - Violates the following F18 beta release criterion for partitions too small for installation: "
18:32:38 <tflink> proposed #agreed 853636 - AcceptedBlocker - Violates the following F18 beta release criterion for partitions too small for installation: "The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing"
18:32:39 <kparal> and soon it "crashed"
18:32:48 <Viking-Ice> ack
18:32:49 <kparal> partitions were created
18:33:02 <kparal> then it announced I don't have enough space
18:33:02 <tflink> I think that failed mid-installation and crashed are OK synonyms in this particular case
18:33:17 <kparal> ack
18:33:36 <jreznik> ack
18:33:51 <tflink> #agreed 853636 - AcceptedBlocker - Violates the following F18 beta release criterion for partitions too small for installation: "The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing"
18:33:52 <adamw> tflink: well, it's a crash. you get a traceback and the crash handler.
18:34:12 * satellit saw it here http://wiki.sugarlabs.org/images/4/40/Error_Msg-Disk_too_small.png
18:34:15 <tflink> adamw: yes. I know they're different. I was thinking "spirit of the criterion"
18:34:16 <kparal> adamw: it looks different, I don't think it's a crash. no libreport window
18:34:25 <tflink> honestly, I think this is worse than crashing
18:34:33 <adamw> oh, okay.
18:34:40 <adamw> either way, still ack.
18:36:06 <tflink> gah, I thought I was still waiting for acks
18:36:13 <tflink> #topic (869978) %packages --default doesn't install default system, but minimal one
18:36:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869978
18:36:17 <buggbot> Bug 869978: unspecified, unspecified, ---, bcl, MODIFIED , %packages --default doesn't install default system, but minimal one
18:36:18 <tflink> #info Proposed Blocker, anaconda, MODIFIED
18:36:44 <adamw> so this is back on the menu since we decided to just do kickstart bugs on a case-by-case basis
18:36:52 <adamw> so we have no goalposts here, it's just Subjective Opinion Time!
18:37:19 <kparal> the fix is ready, just not committed
18:37:46 <kparal> I already voted in c8, +1 blocker
18:37:48 <Viking-Ice> +1 blocker
18:37:51 <tflink> I'm definitely +1 NTH
18:38:23 <tflink> I hesitate on +1 blocker due to lack of criterion but I'm not -1 blocker on this
18:38:49 <jreznik> so let's pull it in as NTH
18:39:08 <adamw> tflink: well we explicitly decided to vote on kickstart bugs on a purely case-by-case basis, and have no criteria. that was a conscious decision
18:39:17 <adamw> so it doesn't seem to make sense to say you don't want to vote +1 because there's no criterion
18:39:24 <tflink> ok, if we're already in that boat, I'm +1
18:39:41 <adamw> i'm definitely +1 nth, say +0.5 blocker
18:39:46 <Viking-Ice> so we have 2 +1 blocker and 2 +1 nth
18:39:47 <tflink> it was precident and I forgot that we had already decided to be case by case
18:39:58 <Viking-Ice> mean 3+1 blocker
18:40:15 <Viking-Ice> forgot to count my self
18:40:50 <Viking-Ice> people focus keep focusing...
18:41:11 <adamw> i think we're pretty clearly +1 blocker now
18:41:21 * adamw pokes tflink with the official pokey stick
18:41:22 <jreznik> +1 nth, seems the rest is in the +1 blocker mood, so +1 blocker to make it clear
18:41:49 <tflink> dear lord you people are impatient
18:42:01 <tflink> proposed #agreed 869978 - AcceptedBlocker - While there is no specific criterion for kickstart directives for F18, they are being decided on a case-by-case basis - this bug was determined to be common/serious enough to justify release blocking status.
18:42:06 <Viking-Ice> ack
18:42:18 * tflink hits adamw with the "be more patient" tazer
18:42:20 <adamw> just trying to make sure we don't lose momentum :)
18:42:22 <adamw> zzzzap
18:42:32 <adamw> ack
18:42:40 <jreznik> ack
18:42:44 <kparal> ack
18:42:47 <tflink> #agreed 869978 - AcceptedBlocker - While there is no specific criterion for kickstart directives for F18, they are being decided on a case-by-case basis - this bug was determined to be common/serious enough to justify release blocking status.
18:42:54 <tflink> #topic (885853) systemd-upgrade.target is copied to the upgraded system, rendering it unbootable
18:42:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885853
18:42:59 <buggbot> Bug 885853: unspecified, unspecified, ---, wwoods, NEW , systemd-upgrade.target is copied to the upgraded system, rendering it unbootable
18:43:01 <tflink> #info Proposed Blocker, fedup-dracut, NEW
18:43:31 <Viking-Ice> clear blocker
18:43:38 <tflink> how so?
18:43:54 <kparal> breaks "boot" ability
18:43:56 <tflink> I'm not saying that it isn't a blocker, just not so convinced it's so clear
18:44:04 <tflink> with one report?
18:44:09 <tflink> in this bug, anyways
18:44:13 <kparal> well I tested it twice
18:44:23 <kparal> three times, actually. once with multiple kernels
18:44:37 <adamw> we seem to have lots of reports of fedup success though
18:44:40 <tflink> which means that everyone is hitting it?
18:44:54 <adamw> oh, it's single kernel
18:44:57 <tflink> anyways, I'm splitting hairs
18:44:59 <kparal> well it's not much probably to hit it on a real system, since you have multiple kernels
18:45:07 <kparal> single kernel is just on clean netinst install
18:45:10 <adamw> yeah
18:45:14 <Viking-Ice> unless you clean up your kernels
18:45:15 <adamw> which is kind of an artificial test case
18:45:35 <adamw> Viking-Ice: do you know of people who always just keep a single kernel installed? offhand i can't think of ever meeting anyone who does that
18:45:44 <kparal> I agree it's very hard to hit. but some people might clean their kernels due to space constraints or something
18:46:16 <kparal> it might not be worth to block the release on though
18:46:17 <adamw> i guess I'm +1 nth, not sure on blocker
18:46:22 <Viking-Ice> we used to have 100mb boot partition
18:46:24 <kparal> I would be fine with commonbugs
18:46:29 <adamw> right, and this is an F17-side bug
18:46:44 <adamw> i'd probably be okay with fixing this after release in the F17 packages if it came to that
18:46:45 <Viking-Ice> small vm ?
18:47:04 <Viking-Ice> yeah if this is a client bug it can be updated
18:47:06 <jreznik> kparal, adamw: +1
18:47:32 <kparal> this is F17-side bug, so we don't have to vote nth really
18:47:44 <tflink> yeah, either blocker or not. nth won't affect it
18:47:45 <Viking-Ice> ok -1/-1
18:47:45 <kparal> blocker will ensure it will get fixed. otherwise we can just hope
18:48:19 <adamw> 'blocker' status for this means that we require an f17 update to be shipped before f18 goes out
18:48:28 <adamw> so yeah, nth doesn't matter.
18:48:39 <adamw> i guess weak -1 for me, i just don't see this hitting many people at all
18:48:53 <kparal> I see it same as adamw
18:48:53 <adamw> and it's workaroundable if you do hit it, we can commonbugs it
18:49:22 * kparal just commonbugs'd it
18:49:30 <Viking-Ice> commonbug it
18:50:20 <tflink> proposed #agreed 885853 - RejectedBlocker - This doesn't seem likely to impact many real world systems and it is workaround-able in the worst case. Not severe enough to justify release blocking status but it should at least be documented as a commonbug
18:50:22 <jreznik> +1 c'mmonbug
18:50:27 <jreznik> ack
18:50:30 <adamw> ack
18:50:32 <kparal> ack
18:50:32 <Viking-Ice> ack
18:50:40 <tflink> #agreed 885853 - RejectedBlocker - This doesn't seem likely to impact many real world systems and it is workaround-able in the worst case. Not severe enough to justify release blocking status but it should at least be documented as a commonbug
18:50:59 <tflink> #topic (884833) exiting from advanced user creation program in firstboot breaks firstboot
18:51:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=884833
18:51:05 <tflink> #info Proposed Blocker, firstboot, NEW
18:51:11 <buggbot> Bug 884833: unspecified, unspecified, ---, msivak, NEW , exiting from advanced user creation program in firstboot breaks firstboot
18:51:23 <kparal> this one is fun
18:51:39 <kparal> I forgot to create a screenshot to illustrate it
18:52:15 <tflink> can't you install w/o root password?
18:52:29 <kparal> tflink: not anymore
18:52:33 <tflink> that seems to be a little corner-casey for blocker, though
18:52:33 <kparal> AFAIK
18:53:09 <kparal> well the problem is that you can either closed the advanced user account window with a X button or File->Exit. some people are used to use the latter
18:53:20 <kparal> *close
18:53:36 <Viking-Ice> and the default is not to create root hence...
18:53:38 <Viking-Ice> +1 blocker
18:53:40 <tflink> so this is only if you do file->exit instead of the X button
18:53:45 <kparal> tflink: yes
18:53:51 <adamw> Viking-Ice: eh? you're required to create a root account since beta
18:53:58 <kparal> Viking-Ice: a standard user account is not created. root account is not affected
18:54:01 <adamw> but you can't log in as root via gdm...
18:54:10 <kparal> no that you can't. gdm is empty
18:54:12 <kparal> no user
18:54:23 <kparal> you can use just tty2
18:54:25 <adamw> you could get in at a console, yeah
18:54:27 <adamw> still, it's pretty rude
18:54:31 * adamw is on the fence here
18:54:38 <Viking-Ice> adamw, yeah I know root is not listed in  gdm
18:54:38 <adamw> i suspect it might not pass the go/no-go meeting smell test
18:54:39 <kparal> and reboot doesn't run firstboot again
18:55:20 <Viking-Ice> I'm thinking noobs here
18:55:38 <kparal> well the perfect noobs won't go into the dialog in the first place
18:55:44 <kparal> unless they wander around
18:55:50 <Viking-Ice> which they do ;)
18:55:57 <Viking-Ice> hey what's this <click>
18:56:01 <kparal> which they sometimes do because they want to learn LINUX
18:56:11 <Viking-Ice> but mostly because they can ;)
18:56:14 <adamw> yeah, never underestimate the power of idiocy
18:56:45 <Viking-Ice> advanced users can just use cli ;)
18:57:04 <kparal> I'm about +0.5
18:57:09 <adamw> definite +1 nth for sure
18:57:16 <kparal> didn't we have similar firstboot issue lately? what was it?
18:57:28 <tflink> I'm +1 NTH, not so sure about blocker htough
18:57:45 <Viking-Ice> "In most cases (see Blocker_Bug_FAQ), 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 the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct
18:57:45 <Viking-Ice> passphrase is supplied. The firstboot utility must be able to create a working user account "
18:58:22 <tflink> and in most cases, it does
18:58:25 <adamw> 'must be able to' is the problem there, i mean, clearly it is.
18:58:43 <tflink> I don't think that the actions here are "most cases"
18:59:36 <Viking-Ice> how many users do you think realize how to re-enable firstboot or create a user account from the cli
19:00:06 <tflink> very few for re-enabling firstboot, more for the CLI option
19:00:10 <adamw> i think we agree that this kinda sucks for a noob who stumbles across it
19:00:12 <Viking-Ice> given that this is an gui and users can accident y find themselves in this situation I'm +1
19:00:17 <adamw> it's just a question of how common that's likely to be
19:00:21 <adamw> is this new in f18, even?
19:00:34 <tflink> good question, have no idea
19:00:35 <adamw> if we shipped earlier releases with this problem i'd be -1, as it hasn't caused terrible pain
19:01:12 <Viking-Ice> how big of a problem is fixing this
19:01:25 <Viking-Ice> simply remove that file>quit from firstboot
19:01:38 <kparal> Viking-Ice: it's system-config-users tool
19:01:41 * adamw does test f17 install
19:01:43 <kparal> that's initiated by firstboot
19:01:49 <kparal> adamw: that will take a lot of time
19:01:50 <Viking-Ice> kparal, mean that
19:01:51 <adamw> right, we can't just rip the menu item out
19:01:58 <adamw> kparal: eh, it's reasonably fast with a dvd
19:02:01 <kparal> read c2
19:02:07 <adamw> it has to be fixed firstboot side
19:02:31 <kparal> I think it can be fixed in an hour or two. but that's just my guess
19:02:37 <adamw> well, doesn't 'have to', but that looks cleaner to me
19:02:38 <kparal> python can catch exit signals just fine
19:02:58 <adamw> given the description i'd guess this exists in previous releases
19:03:04 <adamw> but it'd be nice to be sure - i'm at 400/1200 atm
19:03:16 <kparal> adamw: is that a SSD system?
19:03:29 <adamw> yes.
19:03:39 <kparal> I have to ask my company to provide me with one
19:03:41 <adamw> oh, well, actually, the backing for this VM is on an HD, though
19:03:55 <adamw> still seems to work pretty fast.
19:04:10 <adamw> SSDs are awesome though. everyone should have one.
19:04:12 <kparal> but my increased effectivity would result in doubled proposed blockers :)
19:04:35 <kparal> *efficiency, I think that's the right term in English
19:04:39 * adamw makes note: sneak into kparal's office and replace all his systems with 4200RPM laptop hard disks
19:04:56 <adamw> so i'm -1 if this existed previously, about 0 if it didn't
19:04:58 <tflink> adamw: I have some ancient IDE disks we could use
19:05:07 <adamw> 800/1200
19:05:19 <Viking-Ice> adamw, fyi you cant rely on firstboots previous behavior
19:05:24 <tflink> some busted ones, even. that'll slow him down :-D
19:05:33 <adamw> oh, i got a pile of those
19:05:35 <Viking-Ice> I think it has been mocked with every release cycle
19:05:54 <adamw> Viking-Ice: mocked, sure, but i don't recall seeing many or any reports of this, and i troll the forums a lot
19:06:01 <Viking-Ice> I'm willing to swing to +1 nth
19:06:08 <adamw> usually if a bug is a big deal for people i see a ton of it
19:06:55 <Viking-Ice> since an hour or two can save a lot of noob users from pain and bad initial experience
19:07:16 <Viking-Ice> and I have yet to find a noob that bothers to read the release notes
19:07:22 <Viking-Ice> and commonbugs
19:07:39 <kparal> Viking-Ice: it's an hour or two from an anaconda developer, which steals the time from something else :)
19:07:54 <adamw> 1100/1200
19:08:06 <Viking-Ice> kparallike that bug is "stealing" from our time now?
19:08:16 <Viking-Ice> without space ;)
19:08:27 <kparal> something like that
19:10:00 <adamw> post-install...the moment of truth arrives!
19:10:05 <adamw> Viking-Ice: what, you're not glued to my running commentary?
19:10:37 <Viking-Ice> no I was staring at the final block list trying to figure out how tflink is ordering the bugs in this meeting
19:10:53 <kparal> adamw: you should know that currently you have to click File->Exit twice to introduce the forced exit, or click it once and then click the X button. both exits it
19:10:54 <Viking-Ice> so I could count how many where left
19:11:05 <kparal> adamw: the first click does nothing
19:11:12 <adamw> okay
19:11:14 <tflink> this is the last one on my list of proposed blockers for discussion
19:11:20 <adamw> oh, cool.
19:11:32 <adamw> sigh, post-install...so...long
19:11:34 <tflink> I haven't even looked @ the NTH bugs, though
19:12:08 <tflink> Viking-Ice: the ordering is rather random right now - I don't have any sorting on the list of stuff to discuss
19:12:17 <Viking-Ice> we should just dedicate one meeting to go through those
19:12:28 <tflink> yeah, I was thinking pretty much the same thing
19:12:40 <kparal> we can't discuss all NTH ones, it's just un-doable. we will have to go just through the modified ones
19:12:50 <tflink> we're already over 2 hours today and have 35 proposed NTH
19:13:00 <Viking-Ice> tflink, what ever you use or what ever whomever holds this meeting to order the bugs it makes most sense to me that the blocker bug list should be order identically
19:13:17 <adamw> exact same behaviour in f17.
19:13:26 <adamw> takes two clicks on File / Exit, then firstboot crashes
19:13:29 <adamw> oh - but my created user exists
19:13:39 <kparal> heh, a twist!
19:13:40 <Viking-Ice> tada
19:13:41 <adamw> seems odd to me that it wouldn't in f18, have we confirmed that?
19:13:49 <tflink> Viking-Ice: sure but that takes time
19:13:49 <adamw> oh hey
19:13:56 <adamw> i wonder if it exists but is hitting that UID filter thing?
19:14:05 <adamw> now I have to do a test f18 install? :)
19:14:07 <kparal> adamw: I haven't confirmed that particularly
19:14:23 <Viking-Ice> punt and later roast with adamw findings
19:14:28 <adamw> anyway, i'm still pretty -1, but punt is fine
19:14:31 <kparal> I think I can run just firstboot manually from an existing F18
19:14:51 * adamw kicks off test f18 install
19:14:57 <adamw> i'm up for a few NTH now, dunno bout anyone else
19:15:15 <tflink> let's do the 2 which are MODIFIED at least
19:15:17 <adamw> i guess for NTH we can always pick through the list and vote in bug for any we particularly think should be +1
19:15:44 <adamw> god, when you run one then the other, newui really does feel nicer.
19:16:07 <Viking-Ice> I'm bailing I'm still at work and I have to be here back 04:00 - 05:00 or there about in the morning for an upgrade
19:16:57 <tflink> Viking-Ice: thanks for helping out. sounds like you have some fun times planned for tomorrow morning :)
19:17:12 <adamw> thanks viking
19:18:22 <Viking-Ice> tflink, depends if something breaks or not and I wind up with 500 people on my back ( just local to this building not counting global users that are using this system )
19:18:44 <Viking-Ice> and that's why I have one way ticket to bora bora
19:19:06 <tflink> which is why I try to avoid sysadmin stuff when I can :)
19:19:25 <Viking-Ice> later
19:19:57 <kparal> adamw: so my user exists. I tried with system-config-users 1.3.1-1 and 1.3.3-1
19:20:11 <kparal> but it was not a clean install
19:20:39 <adamw> right, but it's not as bad as though
19:20:40 <adamw> t
19:20:40 <tflink> so what do we want to do on this one?
19:20:44 <tflink> punt or reject?
19:20:52 <adamw> if it existed in f17 and the user exists after the crash, -1
19:21:01 <adamw> the key functionality of firstboot is user creation, the rest is just icing
19:21:03 <kparal> well I can't confirm a clean installation
19:21:13 <adamw> i'm in the middle of one
19:21:18 <adamw> actually, on post-install again
19:21:25 <kparal> let's wait a while then
19:21:55 <kparal> heh, I discovered some other bug, gdm or something. totally unrelated
19:22:36 <adamw> i love when that happens.
19:23:45 <adamw> created user exists in f18 too
19:23:56 <adamw> i can log in fine
19:23:56 <kparal> great
19:24:08 <adamw> so f18 behaviour is same as f17, and a user you create in s-c-u does exist: clear -1 for me
19:24:16 <kparal> -1/+1
19:24:19 <adamw> not even sure i'm +1 nth
19:24:32 <adamw> as poking firstboot just to fix this might not be worth the danger
19:24:36 <adamw> but i wouldn't hate it
19:24:37 <kparal> hm
19:24:46 <kparal> the only screen that is skipped is NTP, right?
19:24:50 <adamw> i think we can count viking as -1/+1 too given his comments before leaving
19:24:58 <adamw> i think so, yeah, since smolt is dead
19:24:59 <tflink> yeah, that sounds right
19:25:30 <kparal> adamw: ok, but there is one other use case
19:25:44 <kparal> adamw: if you open the dialog and then want to close it, without using it
19:25:50 <kparal> then you don't have the user
19:25:59 <kparal> that's why I did when I reproduced it
19:26:35 <kparal> why do I feel like making our life more difficult?
19:26:59 <adamw> that just feels too cornery now
19:27:06 <adamw> and was still the same in f17
19:27:09 <adamw> i think i'm -1/-1
19:27:20 <tflink> -1/-.5
19:27:25 <kparal> I think I'm -1/+1 because of that corner case
19:27:43 <kparal> if it is tested properly, not a last-minute patch
19:28:36 <adamw> reject as blocker, punt on nth till we see a patch?
19:28:45 <kparal> ok
19:29:56 <tflink> what's the difference on waiting for a patch to decide on NTH and taking it as NTH now?
19:30:19 <adamw> we don't just +1 if a patch shows up.
19:30:22 <adamw> we evaluate the patch.
19:30:31 <adamw> plus it gets us out of this bug. :)
19:30:42 <tflink> aren't we supposed to evaluate the patch before pulling NTH anyways?
19:30:47 <adamw> yeah, we are.
19:30:51 <tflink> proposed #agreed 884833 - RejectedBlocker - This behavior existed in F17 and wasn't a huge problem. It seems like too much of a corner case to block release over for F18 final.
19:30:58 <adamw> ack
19:31:03 * tflink left out the NTH part on purpose
19:31:29 <kparal> "it might still be applicable for NTH, if the patch is small and safe"?
19:31:46 <kparal> why leave it out? msivak might want to know
19:31:55 <kparal> whether to work on it or not
19:31:59 <adamw> so we can agree on the rejectedblocker at least
19:32:11 <adamw> we can keep arguing about nth or just punt it for a meeting with more people or whatever
19:32:18 * kparal just added a comment to that bug
19:32:23 <kparal> ack
19:32:27 <tflink> proposed #agreed 884833 - RejectedBlocker - This behavior existed in F17 and wasn't a huge problem. It seems like too much of a corner case to block release over for F18 final. NTH status would be considered depenging on the size/impact of the fix.
19:32:34 <tflink> proposed #agreed 884833 - RejectedBlocker - This behavior existed in F17 and wasn't a huge problem. It seems like too much of a corner case to block release over for F18 final. NTH status would be considered depending on the size/impact of the fix.
19:32:36 <kparal> ack
19:32:38 <tflink> spelling
19:33:23 <adamw> ack
19:33:44 <tflink> jreznik: still here?
19:33:58 <jreznik> yes and no, fesco/board...
19:34:44 <tflink> oh well. I guess 2 acks will be enough
19:34:52 <tflink> #agreed 884833 - RejectedBlocker - This behavior existed in F17 and wasn't a huge problem. It seems like too much of a corner case to block release over for F18 final. NTH status would be considered depending on the size/impact of the fix.
19:35:12 <tflink> OK, that's all the blockers I have marked for discussion
19:35:26 <adamw> seems we're a bit low on people for NTH, but i'm happy to do the modifieds at least
19:35:29 <tflink> do we want to try for the 2 MODIFIED NTHs with just 3 of us?
19:36:07 <kparal> tflink: yes
19:36:13 <tflink> #topic (854904) Quitting Anaconda in LiveCD reboots machine
19:36:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854904
19:36:13 <tflink> #info Proposed NTH, anaconda, MODIFIED
19:36:15 <buggbot> Bug 854904: unspecified, unspecified, ---, clumens, MODIFIED , Quitting Anaconda in LiveCD reboots machine
19:36:21 <tflink> I would LOVE to see this fixed
19:36:36 <adamw> +1
19:36:40 <tflink> +1
19:36:41 <kparal> I'm just afraid whether they won't fix it as the last time - closing installer window would reboot machine
19:36:52 <adamw> it sounds like this went in already
19:36:59 <adamw> has anyone tried with TC1? or a smoke?
19:37:08 <kparal> adamw: doesn't work yet
19:37:11 <tflink> no lives for smoke builds
19:37:19 <kparal> +1
19:37:35 <adamw> if it didn't work in tc1 we should set back to assigned...
19:37:50 <kparal> I'm almost sure
19:38:01 <tflink> what build is it in?
19:38:31 <tflink> proposed #agreed 854904 - AcceptedNTH - This is an annoyance that would be nice to fix but can't be fixed with an update. A tested fix would be considered past freeze.
19:38:44 <kparal> ack
19:39:05 <kparal> but we should clear Fixed in version field
19:39:12 <kparal> not fixed yet
19:39:26 <adamw> 18.31 allegedly
19:39:27 <tflink> how do we know?
19:39:30 <adamw> which was like the second post-beta build
19:39:34 <adamw> way earlier than what's in tc1
19:39:37 <adamw> ack
19:39:39 <tflink> yep
19:39:45 <tflink> #agreed 854904 - AcceptedNTH - This is an annoyance that would be nice to fix but can't be fixed with an update. A tested fix would be considered past freeze.
19:39:50 <tflink> #topic (854722) autologin doesn't work in GDM
19:39:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=854722
19:39:50 <tflink> #info Proposed NTH, gdm, MODIFIED
19:39:51 <buggbot> Bug 854722: unspecified, unspecified, ---, rstrode, MODIFIED , autologin doesn't work in GDM
19:40:30 <kparal> +1 here. it was very inconvenient for KDE, is it better now?
19:40:32 <tflink> +1 - autologin is the intended behavior
19:40:46 <adamw> this seems really old
19:40:59 <adamw> but then i recall it failing way past september
19:40:59 <kparal> hmm, yes it does
19:41:04 <tflink> has it been fixed?
19:41:06 <kparal> it still fails
19:41:09 <adamw> so maybe there's an issue they missed...
19:41:27 <kparal> or it didn't go stable
19:41:37 <adamw> a gdm update went stable in november
19:41:47 <adamw> and there doesn't appear to be a gdm in updates-testing
19:42:17 <adamw> anyway i'm +1
19:42:49 <tflink> proposed #agreed 854722 - AcceptedNTH - autologin on live images is the intended behavior and can't be fixed with an update post-release. A tested fix would be considered past freeze.
19:42:54 <kparal> ack
19:43:09 <adamw> TC1 doesn't autologin for me
19:43:12 <adamw> i'll set it back to assigned
19:43:15 <adamw> ack
19:43:18 <kparal> thanks
19:43:25 <tflink> #agreed 854722 - AcceptedNTH - autologin on live images is the intended behavior and can't be fixed with an update post-release. A tested fix would be considered past freeze.
19:43:40 <tflink> OK, that's all of the MODIFIED nths
19:44:16 <tflink> any objections to calling it done for the day?
19:44:24 <kparal> none
19:44:26 <tflink> #topic Open Floor
19:44:37 <tflink> I'd like to get through the NTHs before monday, though
19:44:54 <tflink> any thoughts on when (or when not) to schedule another review meeting?
19:44:58 <tflink> I was thinking tomorrow
19:45:16 <adamw> do we have a hostname bug?
19:45:27 <tflink> as a blocker?
19:45:32 <adamw> or nth
19:45:36 <adamw> i can't see one, which seems worrying
19:45:46 <tflink> I don't think so, but I haven't been through the NTH bugs yet
19:46:19 <adamw> looking at the current blockers page and searching for hostname shows nothing
19:46:30 <kparal> what hostname bug?
19:46:42 <adamw> there's no GUI option to set hostname
19:46:46 <adamw> which some people are really unhappy about
19:46:50 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=856456
19:46:51 <buggbot> Bug 856456: unspecified, unspecified, ---, rvykydal, NEW , Anaconda no longer has option to set hostname in UI
19:47:04 <adamw> oh hey, someone failed at nth nomination - they did it the wrong way around
19:47:53 <adamw> can we vote on that one? it seems like an important one
19:47:56 * adamw is +1
19:48:03 <tflink> we only have 3 people, though
19:48:28 <adamw> for nth
19:48:32 <adamw> it was okay for the other two, why not this?
19:49:17 <tflink> because a fix isn't pending for this one
19:49:23 <tflink> #topic (856456)  Anaconda no longer has option to set hostname in UI
19:49:23 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=856456
19:49:23 <tflink> #info Proposed NTH, anaconda, NEW
19:49:25 <buggbot> Bug 856456: unspecified, unspecified, ---, rvykydal, NEW , Anaconda no longer has option to set hostname in UI
19:49:29 <tflink> then again, neither is the GDM one
19:49:43 <kparal> +1 nth
19:50:03 <adamw> i'm just picking this one out as one i'd like to get the voting done for :)
19:50:04 <tflink> +1 nth
19:50:11 <adamw> and i know anaconda team is working on it
19:50:14 <tflink> I don't understand our lack of consistency sometimes
19:50:22 <tflink> but whatever :)
19:50:44 <adamw> well i mean the reason we decided to only vote on MODIFIED is just because the list is way too long to vote on all of them, right?
19:50:53 <adamw> it's not that we think we _shouldn't_ vote on them, just a convenience measure
19:51:00 <tflink> adamw: I meant why this is NTH but the firstboot one isn't
19:51:31 <adamw> it's a regression in anaconda functionality and the firstboot one is precisely the behaviour we've probably shipped with for every release?
19:51:38 <tflink> proposed #agreed 856456 - AcceptedNTH - This is a change in functionality from F17 that many users expect and can't be fixed with an update post-release. A tested fix would be considered past freeze.
19:51:41 <kparal> adamw: actually I'd like to propose exactly that once F18 is out and we have some time. I don't see a reason why to vote on bugs that are 90% likely not to get any attention anyway
19:51:44 <adamw> and anaconda is getting major surgery on an ongoing basis anyway, but firstboot isn't
19:52:02 <kparal> not this case, of course
19:52:04 <adamw> kparal: well, sometimes people won't bother working on a bug unless they know the fix would be accepted. but we can discuss that outside the meeting
19:52:06 <adamw> ack
19:52:16 <kparal> adamw: sure, I account for that
19:52:20 <tflink> eh, I still don't follow why we're waiting on a patch to determine NTH status on the firstboot issue but this one can be NTH without having any idea what the fix is
19:52:23 <adamw> tflink: firstboot is basically 'done' already so i think it has a higher bar to being poked at this point
19:52:44 <tflink> kparal: ack/nak/patch?
19:52:45 <adamw> tflink: i only proposed punting on firstboot because we seemed to be split, it was taking a long time, and it didn't look like anything was going to create a consensus
19:52:55 <kparal> tflink: sorry, ack
19:53:05 <tflink> #agreed 856456 - AcceptedNTH - This is a change in functionality from F17 that many users expect and can't be fixed with an update post-release. A tested fix would be considered past freeze.
19:53:12 <tflink> kparal: np, I'm being a bit impatient :)
19:53:23 <tflink> OK, back to ...
19:53:28 <kparal> tflink: I forgot I didn't vote
19:53:29 <tflink> #topic Open Floor (part 2)
19:53:39 <adamw> kparal: on the live image reboot/quit bug - i just added a comment, TC1 behaviour seems sane, can you add details if you think something's still broken? thanks
19:53:55 <kparal> adamw: what do you mean by sane?
19:54:01 <kparal> Reboot doesn't reboot, right?
19:54:04 <kparal> it just quits anaconda
19:54:41 <adamw> i don't see a button labelled reboot.
19:54:46 <adamw> i just see a button labelled quit. which quits.
19:54:48 <kparal> no? I have to check that
19:54:55 <adamw> yeah, please do :)
19:54:59 * adamw has nothing else for open floor
19:55:06 <tflink> time for the next meeting?
19:55:23 <tflink> can either of you think of a reason not to do it tomorrow?
19:56:01 <kparal> tflink: NTHs?
19:56:13 <tflink> yeah, to at least get started on the nths
19:57:26 <adamw> well a reason not to do it is that i'm spending more time in review meetings than doing any freaking testing, but eh
19:57:29 <adamw> tomorrow works for me
19:57:40 <kparal> since we have some free time now, basically what I wanted to propose is: deal with NTHs only once they have a patch or the developer asks us whether it is likely to be accepted. because nominations from random people don't ensure the developer will touch that
19:57:45 <tflink> adamw: I'm not doing a whole lot other than going through bugs and meetings either :-/
19:58:05 <kparal> in this context I consider NEW NTHs a bit unproductive
19:58:13 <adamw> i just worry about the case where developer is silently waiting for NTH decision
19:58:30 <adamw> i kinda like my idea of us just doing in-bug +1s on the ones we think are important to take, but eh
19:58:33 <kparal> adamw: yes, that's the problem, because our current F18 practice is that we evaluate it first
20:00:00 <kparal> so we should probably continue in F18 with our current practice and propose and announce changes before the next cycle
20:00:05 <tflink> we could send an email out to devel@ asking for input on bugs that devs would be open to fixing given NTH satus
20:00:20 <tflink> but I suspect that wouldn't lead anywhere productive
20:01:52 <kparal> I'm fine either taking the hard way of reviewing all of them, or just letting them in proposed state forever until we are pinged or it is in >=MODIFIED
20:01:57 <tflink> eh, I don't think we're going to get much farther in meeting
20:02:31 <kparal> we certainly need to adjust some workflows because we don't keep up with it anymore
20:02:48 <tflink> yeah, I don't think you're going to get many arguments there
20:02:48 <kparal> maybe we are more productive filing those, or other people are, I don't know
20:02:59 <adamw> it'd be interesting to know how much of that is related to f18 craziness and how much is just increasing use of the process
20:03:17 <adamw> if f19 turns out to be the 'quiet' release it's currently planned to be it'd make an interesting comparison base
20:03:47 <adamw> if we get a ton of bugs even for f19 then that'd definitely indicate use of the process is scaling beyond our ability to handle it this way
20:04:20 <tflink> well, not all of the proposed NTHs are anaconda
20:04:23 <tflink> not even most
20:04:41 <tflink> but it could just be the length of F18
20:05:03 <kparal> they filed a bit throughout the cycle, yes
20:06:27 <adamw> and we didn't knock them off as we went along because of the length of the blocker list
20:06:32 <tflink> so, meeting or no meeting for the NTHs?
20:06:34 <adamw> we've just let them pile up
20:06:37 <tflink> yeah, true
20:07:12 <tflink> as much as I'd rather not, I think it might best to just go through the NTHs
20:07:27 <tflink> I can try to review them for obviousness before the meeting
20:07:36 <kparal> what about a mass-comment to all of them?
20:07:38 <tflink> but it'll mean that I'm even farther behind on fedup testing
20:08:03 <adamw> i'm okay with a meeting where we try to go quick, or in-bug voting
20:08:08 <tflink> it wouldn't take too long to read through and ask for justification for anything that isn't clear
20:08:45 <kparal> a mass-comment would ask the developers to reply if they have capacity and willingness to work on this particular issue before F18 release date
20:08:58 <kparal> just an idea
20:09:21 <tflink> that might work - only discuss the bugs that get positive responses
20:09:34 <tflink> how long do we wait for devs to respond, though?
20:09:41 <kparal> that's basically the crux of my soon-to-be-proposed change for NTH process
20:09:52 <kparal> 2 days?
20:10:03 <tflink> so review on monday?
20:10:29 <adamw> sure
20:10:38 <kparal> yes, probably monday
20:10:38 <tflink> or friday, depending on how many responses we have by then
20:10:53 <kparal> yep
20:11:02 <kparal> adamw: you're right, Reboot is now Quit
20:11:04 <tflink> ok, that works
20:11:31 <tflink> #info There will be an NTH review meeting at some point in the next week, time TBD
20:11:45 <tflink> kparal: are you planning to do the mass comment or should I?
20:12:01 <kparal> tflink: please do, I plan to go to sleep :)
20:12:11 <tflink> kparal: quitter :-P
20:12:28 <kparal> only Adam and Chuck Norris don't need to sleep
20:12:38 <kparal> there's no shame in that for mere mortals
20:12:51 <tflink> #action tflink to comment on all proposed NTH, asking for dev input on whether or not a fix is even practical for F18 final
20:13:04 <tflink> what is this sleep thing of which you speak?
20:13:19 <tflink> anywho, I think that's all for today
20:13:24 <tflink> any other topics to bring up?
20:13:51 * tflink assumes not
20:14:04 * tflink sets fuse for something just short enough to run away from
20:14:12 * tflink will send out minutes shortly
20:14:15 <tflink> #endmeeting