f17-final-blocker-review-2
LOGS
17:01:45 <tflink> #startmeeting f17-final-blocker-review-2
17:01:45 <zodbot> Meeting started Tue May  1 17:01:45 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:53 <tflink> #meetingname f17-final-blocker-review-2
17:01:53 <zodbot> The meeting name has been set to 'f17-final-blocker-review-2'
17:01:56 <tflink> #topic roll call
17:02:05 <tflink> anyone here for the blocker review meeting?
17:02:57 <cpuobsessed> present
17:04:01 <tflink> cpuobsessed: welcome
17:04:13 <tflink> crap, adam isn't even online ATM
17:04:17 * cpuobsessed hurry for me!
17:04:26 <cpuobsessed> hurray
17:04:35 <cpuobsessed> i mean for me
17:05:06 <tflink> well, if it's just the two of us - there's no point in even doing this :-/
17:05:10 <cpuobsessed> anyone else here?
17:05:22 <tflink> if they are here, they haven't said anything
17:05:42 * kalev tries to stay unseen.
17:05:52 <tflink> it's a public holiday in the czech republic today and lots of the usual suspects are there
17:06:18 <tflink> kalev: does that mean that you are or are not here for the meeting?
17:06:29 * tflink doesn't think that we'll make it though the whole list today
17:06:42 <tflink> it's getting obscenely long :'(
17:06:53 <cpuobsessed> that's three, everyone take out your osterhagen key
17:07:02 <kalev> tflink: just lurking, not planning to participate in the review
17:07:22 <cpuobsessed> tflink: reschedule or just skip?
17:07:23 <tflink> kalev: ok, that's what I figured but thought I would ask
17:07:31 <tflink> cpuobsessed: reschedule ... again
17:07:36 <tflink> I'll wait a few more minutes
17:07:45 <tflink> but the last email said Tuesday, 2012-05-02
17:07:58 <tflink> I can't imagine that the confusion is helping
17:18:53 <tflink> OK, I'm giving it 2 more minutes - if we don't get anyone else, I'll reschedule for tomorrow
17:20:05 <cmurf> I have a question while we wait
17:20:22 <tflink> cmurf: go for it
17:20:48 <cpuobsessed> not like we're doing anything else :P
17:20:57 <cmurf> final release requirement 3: standalone memory test utility. There isn't one for EFI booting. Is this blocking? Presently GRUB Legacy EFI on TC2 does not have such a utility.
17:21:46 <tflink> it could be, the GRUB EFI menus are certainly more sparse than the syslinux ones
17:22:57 <tflink> cmurf: can you file a bug against grub and mark it as blocking 752650 ?
17:23:08 <cmurf> yep
17:23:13 <tflink> thanks
17:23:18 <tflink> well, I give up for today
17:23:32 <tflink> #info Not enough attendees for quorum
17:23:52 <tflink> #info Rescheduling again for 2012-05-02 @ 17:00 UTC
17:24:14 <cmurf> what component?
17:24:21 <tflink> cmurf: grub
17:24:41 <cmurf> oh right 8-\ silly
17:25:55 <tflink> cpuobsessed: you still around
17:26:04 <cpuobsessed> yesh
17:26:19 * cpuobsessed sets his drink down
17:26:43 <tflink> sounds like we have a third person for ~ 40 minutes - I figure that getting a few of the blockers out of the way will help
17:27:44 <cpuobsessed> strike up the band!
17:27:52 * cpuobsessed stumbles over his chair
17:28:22 <cpuobsessed> fortunately work is slow
17:28:35 <tflink> well, I thought that jsmith would be joining us
17:29:30 <tflink> let's get the boilerplate out of the way
17:29:46 <tflink> #topic Introduction
17:29:56 <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:30:11 <tflink> Following the process of:
17:30:14 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:30:27 <tflink> The F17 release criteria are:
17:30:34 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:30:44 <tflink> I'll be working off of the following list of bugs:
17:30:51 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:31:06 <tflink> I know we're not going to get through all of this today, but for the sake of record ...
17:31:14 <tflink> #info 25 proposed blockers
17:31:14 <tflink> #info 11 accepted blockers
17:31:14 <tflink> #info 10 proposed blockers
17:31:24 <cpuobsessed> holy crap
17:31:26 <tflink> Let's get started with the proposed blockers
17:31:42 <tflink> cpuobsessed: no kidding, that's why I want to get this list pared down :/
17:31:48 <tflink> #topic (816509) 'Updates' notification not showing up in Gnome (F17 TC1)
17:31:51 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816509
17:31:54 <tflink> #info Proposed Blocker, NEW
17:32:08 <tflink> this seems like a pretty clear blocker to me
17:32:38 <cpuobsessed> especially considering the fact that i am running f17-tc2 and haven't seen the updates notification
17:32:54 <tflink> proposed #agreed - 816509 - AcceptedBlocker - Violates the F17 beta release criterion "The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system"
17:32:59 <tflink> ack/nak/patch?
17:33:09 <cpuobsessed> ack
17:34:41 <cpuobsessed> i just ran software update and have 50 updates, and no notifications in any tray
17:35:00 <cpuobsessed> definitely a bug
17:35:05 <tflink> cpuobsessed: can you add that to the bug when you get a chance?
17:35:23 <tflink> installation method, how long ago you installed, which desktop you're using etc.
17:35:29 <tflink> jsmith: you there?
17:35:35 <cpuobsessed> np
17:35:41 <tflink> thanks
17:37:16 <tflink> well, this is an obvious blocker - I guess that 2 acks will work
17:37:25 <tflink> #agreed - 816509 - AcceptedBlocker - Violates the F17 beta release criterion "The default update manager in release-blocking desktops must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system"
17:37:56 * tflink is looking for more obvious blockers
17:38:18 <cmurf> 816238
17:38:36 <cpuobsessed> updated 816509
17:38:47 <tflink> cpuobsessed: thanks
17:38:49 <akshayvyas> tflink, it happned with me on fedora 16 but is it really a bug
17:39:18 <cmurf> 816701 should also be uncontroversial obvious blocker
17:40:35 <cpuobsessed> cmurf: i don't believe so
17:40:43 <tflink> cmurf: I see where you're coming from but not sure I agree - it doesn't clearly violate any release criteria
17:40:51 <cpuobsessed> i have a bios system and having gpt table didn't affect anything
17:40:57 <tflink> akshayvyas: you mean the lack of updates notifications?
17:41:09 <akshayvyas> tflink yep
17:41:31 <tflink> cpuobsessed: it's a conditional violation - there are a bunch of systems out there (mostly laptops IIRC) that can't handle gpt+non-EFI
17:41:39 <cmurf> there are too many machines that do have problems with GPT, and the blacklisting isn't working
17:41:59 <cmurf> and the consequence of reversion is zero
17:42:07 <cpuobsessed> i was speaking from my perspective, my system is quite old
17:42:08 <tflink> akshayvyas: why do you think that it isn't a bug?
17:42:25 <tflink> yeah, I think that the GPT thing will likely be a blocker
17:42:26 <cpuobsessed> tflink: i think more data is needed
17:42:32 <akshayvyas> i might happen due to t network
17:42:42 <tflink> cpuobsessed: there is a bunch of data, it's just not in the bug
17:43:57 <cpuobsessed> how can i tell if i have gpt table? bios boot partition?
17:44:12 <cmurf> parted -l
17:44:15 <tflink> cpuobsessed: either that or use parted/fdisk
17:44:19 <cmurf> disklabel either GPT or MSDOS
17:44:27 <tflink> fdisk will complain if you have GPT and parted will tell you
17:44:43 <tflink> cmurf: you interested in sticking around for some blocker review?
17:44:52 <cmurf> for a bit
17:45:12 <tflink> cool, then we can keep going. just let us know when you leave :)
17:45:18 <cpuobsessed> gpt
17:45:44 <tflink> #topic (806166) Installation using DVD ISO dd'd to USB can't use USB as installation source
17:45:46 <cpuobsessed> core2duo compaq 6910p; just me of course
17:45:47 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=806166
17:45:50 <tflink> #info Proposed Blocker, ON_QA
17:46:00 <cpuobsessed> paf, i thought they fixed
17:46:13 <tflink> I'm +1 blocker on this even though it should be fixed
17:46:39 <tflink> ATM, dd is the only supported method for creating USB install media for non-fedora linux and OSX
17:46:40 <jsmith> +1 blocker
17:46:41 <cmurf> it's not working for EFI  i can vouch for that
17:46:46 <cpuobsessed> i mostly use dvd-rw now but have used usb; which most people probably do for testing
17:47:07 <cpuobsessed> ack
17:48:06 <cmurf> What's the criteria for dd, I'm not finding anything that literally requires that method. Although it makes sense for the reasons mentioned already.
17:48:28 <tflink> yeah, I was just looking
17:48:44 <cpuobsessed> iirc the install was supposed to be updated
17:48:46 <tflink> I thought that there was a USB criterion
17:49:33 <cmurf> not finding it in alpha, beta, or final
17:49:52 <tflink> proposed #agreed - 806166 - AcceptedBlocker - Conditional violation of the F17 final release criterion "The installer must be able to use all supported local and remote package source options" for USB media created with dd
17:50:20 <tflink> proposed #agreed - 806166 - AcceptedBlocker - Conditional violation of the F17 final release criterion "The installer must be able to use all supported local and remote package source options" for USB media created with dd - Since dd is the only currently supported method for USB install media creation for non-fedora linux and OSX, judged to be a blocker
17:51:27 <cpuobsessed> ack
17:52:01 <akshayvyas> i tried both realese alpha and beta on usb but it was live cd
17:52:36 <tflink> yeah, this particular issue is for non-live DVDs during installation
17:53:17 <cmurf> On 806166 has anyone tested this with TC2 since anaconda-17.23-1 should have fixed this (the EFI non-bootability probably still makes it block but that's not what this bug is about)
17:53:56 <tflink> cmurf: the EFI issue for DVDs is known, not sure what the bug is but that's an issue w/ pungi
17:54:16 <tflink> mkhybridiso isn't being run
17:54:38 <tflink> I think that's the command, anyways. The resultant DVD isn't hybrid-ized for EFI
17:56:03 <cmurf> OK so procedural question:  you block something if it violates requirements even if it's not clear whether the problem still occurs or not?
17:56:04 <tflink> any other ack/nak/patch on the proposal?
17:56:47 <tflink> yes. whether the issue is release blocking or not is solely depenent on the impact of the issue
17:56:56 <cmurf> got it
17:57:00 <tflink> if it is indeed fixed, it'll just be closed
17:57:05 <cpuobsessed> ack
17:57:31 <akshayvyas> https://bugzilla.redhat.com/show_bug.cgi?id=816410 this ne is fr uefi
17:58:06 <cpuobsessed> so we're not here to determine if it's fixed, just whether it's blocking
17:58:13 <tflink> yep
17:58:39 <tflink> just waiting for another ack before moving on
17:59:16 <tflink> akshayvyas: that's for livecds, the issue with installation DVDs is different
18:00:16 <jsmith> ACK
18:00:31 <tflink> #agreed - 806166 - AcceptedBlocker - Conditional violation of the F17 final release criterion "The installer must be able to use all supported local and remote package source options" for USB media created with dd - Since dd is the only currently supported method for USB install media creation for non-fedora linux and OSX, judged to be a blocker
18:00:57 <tflink> #topic (815827) Connection to root iSCSI disk is disrupted during boot
18:01:00 <cpuobsessed> read: netbook or other device without optical drive
18:01:00 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815827
18:01:02 <tflink> #info Proposed Blocker, NEW
18:01:11 <tflink> this is another by-the-books-blocker
18:01:18 * cpuobsessed doesn't know what iSCSI is
18:01:23 <cmurf> many of the media booting bugs need cleaned up titles. including candidate numbers is annoying.
18:01:36 <tflink> violates the F17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
18:01:49 <cpuobsessed> so be it
18:01:53 <cpuobsessed> ack
18:01:58 <tflink> cpuobsessed: it's a method of presenting a block storage device (disk) over the network
18:01:58 <cmurf> Yes, obvious blocker.
18:02:07 <jsmith> +1 blocker
18:02:28 <tflink> proposed #agreed - 815827 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
18:02:32 <tflink> ack/nak/patch?
18:02:33 <jsmith> ACK
18:02:40 <cpuobsessed> ack
18:02:43 <cmurf> haha am i voting?
18:02:57 <cpuobsessed> cmurf: you're just slow, vote
18:02:57 <tflink> cmurf: anyone here can vote
18:03:02 <cmurf> ack
18:03:06 <tflink> #agreed - 815827 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
18:03:12 * cpuobsessed pats cmurf on the back
18:03:30 <cpuobsessed> is iSCSI software or hardware dependent
18:03:50 <akshayvyas> its both its actully network dependent
18:03:52 <tflink> cpuobsessed: you can use either software or hardware for iscsi
18:03:55 <cmurf> both, but primarily software initiator
18:04:21 <tflink> #topic (816238) upgrade using boot.iso destroys EFI boot
18:04:21 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816238
18:04:21 <tflink> #info Proposed Blocker, NEW
18:04:21 <cpuobsessed> prolly not good to try on wifi g
18:04:42 <tflink> cpuobsessed: no, I'd suggest using iSCSI over a wired network if possible
18:04:56 <akshayvyas> tflink agree
18:05:04 <cpuobsessed> aight
18:05:26 <cpuobsessed> i've only got one efi machine; and i've put chromeos back on it
18:05:53 <akshayvyas> but i think its god to tempery mount iscsi insted of making fstab entry
18:06:05 <cmurf> +1 block on 816238
18:06:13 <tflink> akshayvyas: depends on your setup, I think
18:06:30 <tflink> if you have a stable network, I don't see any problems w/ having a statically mounted iSCSI lun
18:07:01 <tflink> I question the wisdom of ever booting from SAN/NAS but people do it
18:07:08 <akshayvyas> tflink yes but it needs proper conf
18:07:37 <tflink> dracut is realy good about mounting iSCSI luns @ boot and it tends not to be much of an issue
18:07:53 <tflink> well, dracut/systemd - it depends on which mount point we're talking about
18:08:20 <cmurf> hello 816238?
18:08:29 <tflink> bcl: I'm hoping that you're here for the EFI upgrade issue?
18:08:41 <tflink> cmurf: I was waiting for some input from the anaconda devs
18:08:55 <tflink> I'd rather not take this as a blocker without their input
18:09:21 <bcl> yeah, reading now.
18:11:10 <tflink> I'm probably +1 blocker on this, though
18:11:59 <bcl> seems like this belongs to grub2 or grubby, not anaconda. But it does look like a blocker to me -- upgrade your EFI system and can't boot is pretty clear.
18:12:38 <tflink> yeah, as adam put it - ignoring the bootloader should actually ignore the bootloader
18:12:46 <bcl> we also need to make sure all the grub2 tools are available in rescue.
18:13:04 <bcl> (there may be a bug for that, I'm still catching up)
18:13:20 <cmurf> this is on an EFI system though?
18:13:32 <tflink> oh yeah, I still don't understand that one. I couldn't reproduce those claims
18:13:47 <tflink> cmurf: yeah, EFI so it would be grub or grubby
18:14:03 * jsmith finishes reading the bug details
18:14:13 <cmurf> I'm confused because reproduce step 1 says to EFI boot, yet step 5 complains there's no grub*-install which is a GRUB2 thing
18:14:33 <bcl> I'll give it a try here if I have time today and see if I can nail it down more.
18:14:38 <jsmith> Yeah, I guess I'm think this is +1 blocker, but it's certainly a bit vague
18:14:42 <jsmith> Could use some more research
18:14:44 <cmurf> And Fedora is not using grub2-efi
18:14:48 <tflink> I wonder if the complaint is that there is no grub*-install in the chroot
18:14:51 * jsmith would be OK with punting it to a later meeting as well
18:15:00 <bcl> cmurf: I took that as meaning that tools for both grub versions are missing.
18:15:16 <cpuobsessed> i did the exact same thing on non-efi and it worked
18:15:21 <cmurf> OK
18:15:35 <tflink> I've tried it recently on EFI and the tools do exist outside the installed system on the boot.iso
18:15:55 <bcl> ok, good.
18:16:04 <tflink> but agreed that the tools part could probably use more testing - it's the "changing stuff it's not supposed to" part that worries me
18:16:13 <cmurf> yeah i agree
18:16:39 <bcl> adding tools is a template change in lorax so should be as safe as anything.
18:17:11 <cmurf> However, question: Is it a requirement that upgrades must either successfully upgrade or do no harm, to a system that has alpha or beta release on it?
18:17:30 <bcl> oh, I see what you mean. Well, grubby doesn't know that you said not to change things, so it does whatever it normally does when updating the kernel.
18:17:44 <tflink> proposed #agreed - 816238 - AcceptedBlocker - Conditional violation of F17 final release criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" where the upgraded system is EFI and t
18:18:06 <cpuobsessed> afaict upgrades are from previous release to new release
18:18:07 <cmurf> My question has been answered never mind.
18:18:07 <bcl> cmurf: I'd say not really. I'm mostly concerned with upgrades from f16.
18:19:11 <cpuobsessed> nack
18:19:18 <cmurf> I see the alphas/betas as entirely expendable installs, personally.
18:19:21 <tflink> proposed #agreed - 816238 - AcceptedBlocker - Conditional violation of F17 final release criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" where the upgraded system is EFI and t
18:19:28 <tflink> cpuobsessed: patch?
18:19:31 <cmurf> ack
18:20:01 <cpuobsessed> if it can be reproduced from an updated f16 install
18:21:00 <tflink> if it turns out that F16->F17 upgrade is not affected, we can remove blocker status
18:21:05 <cpuobsessed> all the notes indicate the upgrade was from one F17 to another; not a previoues F16
18:21:07 <tflink> or we can punt until more testing is done
18:21:14 <cpuobsessed> punt
18:21:41 <tflink> any other votes?
18:21:55 <cmurf> how about issue needinfo and keep it as a blocker
18:22:10 <tflink> I could go either way, honestly
18:22:10 <cmurf> if no new info next round, give it the boot print
18:22:28 <cpuobsessed> doesn't meet the criteria for blocker
18:22:29 <tflink> it needs more testing to clarify impact and all of the claims
18:22:46 <bcl> I'd like to know for sure if it happens when upgrading from f16. it probably does though.
18:22:49 <cmurf> it's already accepted as a blocker
18:22:49 <akshayvyas> tflink: +1
18:22:58 <tflink> ok, I'm fine with punting
18:23:04 <cmurf> Oh nevermind i can't read - sorry
18:23:09 <cpuobsessed> nmi
18:24:03 <tflink> proposed #agreed - 816238 - This appears to be a blocker but more testing is needed before we can come to a decision - Does this affect 16 to 17 upgrades and are the claimed missing tools actually missing? Ask for more info/testing and will revisit at next meeting.
18:24:07 <tflink> ack/nak/patch?
18:24:17 <cmurf> ack
18:24:20 <cpuobsessed> ack
18:24:31 <tflink> #agreed - 816238 - This appears to be a blocker but more testing is needed before we can come to a decision - Does this affect 16 to 17 upgrades and are the claimed missing tools actually missing? Ask for more info/testing and will revisit at next meeting.
18:25:57 <tflink> how is everyone feeling about time?
18:26:09 <cpuobsessed> how about https://bugzilla.redhat.com/show_bug.cgi?id=816493
18:26:10 <tflink> I think we've hit all the less-ambiguous blockers
18:26:21 <akshayvyas> tflink: i think it needs more testing
18:26:32 <tflink> cpuobsessed: I'm avoiding that one on purpose :)
18:26:58 <cmurf> i have a winner seeing as we've already done one iscsi block already: 815827
18:27:10 <tflink> a winner?
18:27:31 <cmurf> winner=obvious uncontroversial blocker
18:28:05 <cpuobsessed> there's nothing in the criteria that says that network time is required
18:28:10 <cpuobsessed> afaict
18:28:23 <tflink> yeah, but it can't be fixed with updates which makes it more blocker material
18:28:24 <cmurf> right, so I'd be -1 on 816493
18:28:30 <cmurf> and +1 on 815827
18:28:59 <tflink> ok, let's do these in order :)
18:29:03 <tflink> #topic (816495) Network time can't be enabled
18:29:03 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816495
18:29:03 <tflink> #info Proposed Blocker, ON_QA
18:29:54 <tflink> this is the original bug that spawned the ntp/chrony bugs
18:30:03 <tflink> crap, I got the wrong one
18:30:06 <tflink> #undo
18:30:06 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x252c1350>
18:30:08 <tflink> #undo
18:30:08 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x252c1cd0>
18:30:09 <tflink> #undo
18:30:09 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x252c1310>
18:30:30 <tflink> #topic (815748) Network time can't be enabled
18:30:30 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815748
18:30:30 <tflink> #info Proposed Blocker, ON_QA
18:30:37 <tflink> OK, got the right one this time
18:30:51 <tflink> this is the original bug that spawned the ntp and chrony bugs
18:31:30 <akshayvyas> but i dnt really get it configuring ntpd manually is nt working
18:31:38 <akshayvyas> how can it be possibe
18:32:42 <tflink> akshayvyas: not sure I understand
18:32:58 <tflink> AFAIK, enabling ntp in firstboot after install is not working
18:33:06 <tflink> due to the way that it is being enabled
18:33:21 <tflink> manually enabling ntpd and chronyd should still work
18:34:04 <cpuobsessed> i don't see the issue: http://fpaste.org/cHoI/
18:34:10 <cmurf> hmm so what constitutes "the default panel (or equivalent)"
18:34:25 <tflink> it's a little bit of a stretch, I think
18:34:43 <tflink> but my reading of it is that the time displayed on the panel may not be correct if ntp isn't enabled correctly
18:34:48 <cpuobsessed> does the panel keep time and display it correctly: yes
18:34:56 <cmurf> right
18:35:02 <cmurf> can you set it manually? yes
18:35:04 <cpuobsessed> then that could be an issue with your rtc
18:35:09 <cmurf> will an update fix network sync?
18:35:37 <tflink> not sure, but I don't think so
18:35:40 <cpuobsessed> looks like the latest update fixes ntp/chrony
18:35:59 <tflink> yeah, this should make it in before freeze
18:35:59 <cpuobsessed> -1 blocker for me
18:36:15 <cmurf> comment 4 implies to me that an update will fix this
18:36:51 <tflink> good point
18:37:24 <cmurf> maybe needinfo to lennart and confirm that an update will fix? or must it be fixed on release media?
18:37:44 <cpuobsessed> i feel the bottom line is "is network time a final criteria"?
18:38:03 <tflink> if it can be fixed with an update, I don't think it needs to be a blocker
18:38:07 <cmurf> well, i think yes if it's impossible for it to work for the entire fedora life cycle
18:38:19 <cmurf> if it can be fixed with update, i'm -1
18:38:29 <cmurf> if it can't be fixed, I'm +100 haha
18:38:30 <cpuobsessed> i have the latest systemd, and my time is working, chrony is running
18:38:33 <akshayvyas> tflink : +1 for update
18:38:52 <tflink> cpuobsessed: did you enable ntp from firstboot @ install time?
18:39:08 <cpuobsessed> tflink: always
18:39:50 <cmurf> I did too, let me boot a TC2 machine and see if it's working. I think this is fixed in TC2 honestly.
18:40:11 <tflink> proposed #agreed - 815748 - It sounds like the issue could be fixed with an update but this needs testing with the systemd/ntp/chrony updates - unless those updated don't fix the issue, will reject as a blocker for F17 final
18:40:27 <cmurf> ack
18:40:28 <tflink> proposed #agreed - 815748 - It sounds like the issue could be fixed with an update but this needs testing with the systemd/ntp/chrony updates - unless those updates don't fix the issue, will reject as a blocker for F17 final
18:40:32 <tflink> typo
18:41:02 <cmurf> ack
18:42:04 <cmurf> ps x | grep chrony
18:42:07 <cmurf> should that work
18:42:28 <tflink> systemctl status chronyd.service would be better, I think
18:42:53 <tflink> any other votes?
18:42:56 <akshayvyas> pa aux | grep chrony i will g with cmurf
18:43:00 <cmurf> ps aux | grep chrony I've got it
18:43:00 <akshayvyas> :)
18:43:30 <cmurf> it's running, and systemd reports its status as active
18:43:35 <cpuobsessed> i'm running F17-TC2 and chrony is working
18:43:40 <cmurf> this is TC2, time enabled with firstboot
18:43:50 <cpuobsessed> same here
18:44:02 <tflink> if you could add the reports to the bug, that would be awesome
18:44:39 <cpuobsessed> i think that because of the way chrony works, just because it says disabled in date/time settings; doesn't mean it's not running
18:45:02 <akshayvyas> +1 cpuobsessed
18:45:04 <tflink> I suppose that would be the part about the panel not working
18:45:26 <cpuobsessed> updated bug
18:45:52 <cpuobsessed> +1 tflink
18:46:11 <tflink> any more votes on the proposal?
18:46:15 <tflink> I see one ack
18:46:19 <cpuobsessed> nack
18:46:25 <tflink> cpuobsessed: patch?
18:46:29 <cpuobsessed> patch
18:46:37 <cpuobsessed> yes patch
18:46:41 <cmurf> i ack'd twice but it's moot, it's fixed
18:47:21 <tflink> maybe but at the moment, we're looking at the impact of the issue - not whether it's fixed or not :)
18:47:34 <tflink> cpuobsessed: what do you propose for a patch?
18:49:20 <cpuobsessed> wait, what does patch mean? patch will fix or patch to proposal
18:50:01 <tflink> patch means that you have a change to the proposal
18:51:21 <cpuobsessed> oh, then i stand by nack
18:51:54 <tflink> cpuobsessed: ok, what part of the proposal do you not like?
18:52:22 <cpuobsessed> i still don't feel it meets any blocking criteria
18:53:52 <cmurf> network time is not in critical path?
18:53:54 <cpuobsessed> ntp/chrony is not required to work, the panel still displays the correct time
18:54:47 <cmurf> if it were the case (which it's not) that network time non-functioning on install, could not be fixed with a future stable update, it would be a disaster.
18:55:01 <cmurf> the proposal only blocks if it can't be fixed with an update
18:55:17 <tflink> which it appears that it can
18:55:35 <cmurf> appears it can be fixed with an update, but also appears to be working and not need an update
18:55:40 <cmurf> so i agree with the proposal
18:56:05 <tflink> but you're right that there doesn't appear to be any 100% clear violation of the release criteria
18:56:34 <tflink> but like cmurf said, as long as it can be fixed by an update, it would be rejected as a blocker
18:56:47 <tflink> if it can't be fixed as an update, we'll end up re-visiting it
18:57:02 <cmurf> i'm not going by release criteria, i'm going by "final block bugs" under the criteria
18:57:03 <cpuobsessed> tflink: i see why you didn't want to look at this one
18:57:08 <akshayvyas> tflink +1
18:57:28 <cpuobsessed> my opinion, not a blocker
18:57:49 <tflink> so we have 2 acks (including me) and one nak
18:58:05 <tflink> akshayvyas: you have an opinion on the proposal?
18:58:09 <cpuobsessed> are we deadlocked?
18:58:38 <cmurf> network time is sure in a critical path package
18:58:39 <tflink> no, I just prefer to have more than a one vote margin if possible
18:58:52 <cmurf> if it is, and it cannot be fixed, that clearly is blocker
18:59:09 <tflink> cmurf: good point
18:59:41 <tflink> Any criticalpath bug that can't be fixed with an update is a blocker
18:59:51 <tflink> sorry, I appear to be slow ATM - you said that before
19:00:21 <akshayvyas> i think it will be fixed in update
19:00:24 <cmurf> i don't know if network time is critical path but if it is and can't be fixed with an update, totally a blocker
19:00:33 <cmurf> i think it's fixed now, it's in TC2, not a bug
19:00:52 <cpuobsessed> according to http://kojipkgs.fedoraproject.org/mash/branched-20120401/logs/critpath.txt neither chrony or ntp is there
19:01:29 <cmurf> surprising
19:01:33 <tflink> honestly, I just want to be done with this since it appears to be fixed anyways
19:01:40 <cmurf> out of sync time causes lots of problems
19:01:47 <tflink> and any decision is pretty much a moot point
19:01:51 <cmurf> well then punt and move on
19:02:02 <tflink> I tried that but got naked
19:02:14 <cmurf> oh really?
19:02:22 <cmurf> interesting response
19:02:35 <cpuobsessed> punt
19:03:07 <tflink> cpuobsessed: you're the one nak-ing
19:03:13 <tflink> :-P
19:03:21 <akshayvyas> cpuobsessed:: it seems like ntpd is nt enabled on bt
19:03:25 <akshayvyas> boot
19:03:38 <cmurf> is it possible this is only an i686 bug?
19:03:47 <cmurf> i'm on x86_64 and it works
19:03:49 <cpuobsessed> aight ack it
19:04:25 * cpuobsessed changes to ack but with reservations
19:04:31 <tflink> proposed #agreed - 815748 - It sounds like the issue could be fixed with an update but this needs testing with the systemd/ntp/chrony updates before a decision is made. Unless updates can't fix the issue, will reject as a blocker for F17 final as it isn't a clear violation of the F17 final release criteria
19:04:38 <tflink> any better?
19:04:55 <cmurf> how about we ask if it's still a bug?
19:05:00 <cmurf> supposed to be fixed
19:05:07 <tflink> it's still a bug either way
19:05:16 * cpuobsessed agrees
19:05:18 <tflink> but if it ends up being closed, it drops off the proposed blocker list
19:05:23 <cmurf> gotcha
19:06:00 <cmurf> leave it proposed, make it adamw's problem to resolve this question of critpath and whether it's blocking if it can't be updated
19:06:13 <akshayvyas> i dwnloaded f17 i686 tmrw and was running it on usb with ntpd service on
19:06:44 * tflink is assuming a general ack, then
19:06:49 <cmurf> ack
19:06:54 <cpuobsessed> ack
19:07:04 <cmurf> the suspense of the next bug is killing me
19:07:05 <tflink> #agreed - 815748 - It sounds like the issue could be fixed with an update but this needs testing with the systemd/ntp/chrony updates before a decision is made. Unless updates can't fix the issue, will reject as a blocker for F17 final as it isn't a clear violation of the F17 final release criteria
19:07:33 <tflink> cmurf: the next bug? which one did you have in mind?
19:07:51 <akshayvyas> cmurf : ??
19:07:56 <cmurf> 815827
19:08:32 <tflink> eh? we already did that one, didn't we?
19:08:42 <cmurf> different bug
19:09:18 <cmurf> hmm seems i could be confused
19:09:39 <cpuobsessed> same bug
19:09:44 <tflink> 14:03 < tflink> #agreed - 815827 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able  to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
19:09:45 <cmurf> oops yep
19:09:55 <cmurf> 817889
19:09:57 <akshayvyas> we did that ,yep
19:10:25 <akshayvyas> sowy not this one
19:10:44 <cpuobsessed> tflink: #agreed - 815827 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
19:10:59 <cpuobsessed> heh
19:11:09 <cmurf> this one
19:11:09 <cmurf> https://bugzilla.redhat.com/show_bug.cgi?id=817889
19:11:12 <cpuobsessed> tflink: not as slow as you thought?
19:11:26 <tflink> #topic (817889) boot menu lacks a memory test option when booting EFI computers
19:11:29 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=817889
19:11:32 <tflink> #info Proposed Blocker, NEW
19:11:41 <tflink> gah, this out-of-orderness is messing with me
19:11:57 <cpuobsessed> no-brainer, ack
19:11:57 <tflink> note to self - just do the bugs in order next time :)
19:12:05 <cmurf> ack
19:12:36 <tflink> proposed #agreed - 817889 - AcceptedBlocker - Violates the F17 final release criterion "All release media must include a standalone memory test utility. A boot menu option to launch this utility must be present and must work correctly."
19:13:23 * cpuobsessed has fired up his i686  VM
19:13:40 <tflink> ack/nak/patch on the proposal?
19:14:05 <cpuobsessed> ack
19:14:22 <cmurf> ack
19:14:30 <tflink> #agreed - 817889 - AcceptedBlocker - Violates the F17 final release criterion "All release media must include a standalone memory test utility. A boot menu option to launch this utility must be present and must work correctly."
19:15:28 <cmurf> you wana go back in order?
19:15:30 <cmurf> https://bugzilla.redhat.com/show_bug.cgi?id=804846
19:15:30 <tflink> #topic (816867) Kickstarting with nfs repo as installation source fails: no suitable images
19:15:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816867
19:15:35 <tflink> #info Proposed Blocker, NEW
19:15:37 <cmurf> oops
19:16:27 <cmurf> does it annoy anyone when someone proposes blockers but doesn't say why? that's supposed to be a requirement of proposing a blocker.
19:16:47 <tflink> supposed to be, yes
19:16:52 <tflink> almost nobody does it, though
19:17:03 <cmurf> so this is a PXE and/or kickstart bug
19:17:28 <tflink> This is a cnditional violation of "The installer must be able to use all kickstart delivery methods"
19:17:52 <cmurf> And beta criterial #5
19:18:03 <cmurf> It must be possible to install by booting the installation kernel directly, including via PXE, and correctly specifying a remote source for the installer itself,
19:18:28 <tflink> the PXE part appears to work sonewhat
19:18:40 <tflink> but it doesn't really get far enough to tell since the ks retrieval fails
19:18:44 <cmurf> what is a "delivery method"
19:18:59 <tflink> the method by which the installer grabs the kickstart file
19:19:10 <cmurf> and what is the method in this case? pxe?
19:19:12 <tflink> I'm just not 100% sure that nfs is supported
19:19:17 <cmurf> right
19:19:17 <cpuobsessed> the reporter should have include the kickstart file
19:19:35 <cmurf> is the delivery method nfs or pxe, looks like nfs for the file itself
19:19:40 <tflink> pxe doesn't have much to do with ks retrieval, just initial loading of the initrd and kernel
19:20:03 <cmurf> -1 blocker
19:20:13 <tflink> delivery methods for ks would be: local disk, http, nfs and some of the bizarre and exotic methods that we seem to support
19:20:21 <tflink> cmurf: why -1 blocker?
19:20:45 <tflink> this seems to be a clear blocker if nfs is a supported delivery method (I'm trying to ask about that now)
19:21:29 <cmurf> i'm -1 atm due to lack of information from the reporter
19:21:57 <cmurf> and i'm not finding nfs in crit path
19:22:05 <akshayvyas> needs more info i think cmurf +1
19:22:13 <cmurf> yeah
19:22:16 <tflink> what info does it need?
19:22:20 <cpuobsessed> nmi, punt
19:22:36 <tflink> this is an issue with either dracut, anaconda or anaconda-dracut which are not fixable w/ an update
19:22:45 <cpuobsessed> well the kickstart file would help
19:22:46 <cmurf> you are correct
19:22:58 <tflink> the content of the kickstart file is not really relevant
19:23:03 <cmurf> yeah i want the kickstart file and i also want to know if NFS is a "kickstart delivery method"
19:23:17 <tflink> yes, nfs is a supported kickstart delivery method
19:23:40 <cmurf> ok
19:23:46 <cmurf> so then the question is if it's anaconda's problem
19:24:09 <cmurf> only if anaconda is puking does beta release #8 apply
19:24:32 <tflink> proposed #agreed - 816867 - AcceptedBlocker - This is a violation of the F17 final release criterion "The installer must be able to use all kickstart delivery methods" - according to the anaconda team, NFS is a valid kickstart delivery method
19:24:41 <cpuobsessed> ack
19:24:57 <cmurf> patch
19:25:01 <tflink> cmurf: yeah, it is - we've had a bunch of similar bugs. this part of the loading process is handled by an anaconda-specific dracut module
19:25:03 <cmurf> ask for more info, kickstart file
19:25:09 <cmurf> then i'm +1
19:25:28 <cmurf> as in, approved as blocker and also needinfo kickstart file
19:25:35 <tflink> I don't understand why the contents of the ks file are needed
19:25:55 <cmurf> what do you bet it's going to get asked for by the anaconda team anyway?
19:25:57 <tflink> since the installer can't retrieve the file anyways
19:26:10 <cmurf> fair point...
19:26:19 <tflink> I'm pretty sure it won't - sandro knows what he's doing in general :)
19:26:27 <cpuobsessed> it looks like dracut grabbed the ks
19:26:40 <cmurf> dracut Warning: no suitable images
19:26:52 <cmurf> dracut Warning: Couldn't mount
19:26:54 <cpuobsessed> if the anaconda needs the file they'll ask for it
19:27:13 <cmurf> could actually be a pxe problem...
19:27:20 <cpuobsessed> no suitable images means it couldn't find the kernel or boot image
19:27:35 <cpuobsessed> could be, i'm not an expert on this subject
19:28:38 <cmurf> do we know there are no errors in the description 1, 2, 3?
19:29:25 <cmurf> i guess i'm a +1 because nfs is a kickstart delivery method and it should work
19:29:35 <cmurf> but i think the bug report is light on details for someone to reproduce this
19:29:45 <cmurf> and it kinda ought to be reproducible
19:29:50 <tflink> yeah, it is
19:29:58 <tflink> I might have misread it, too
19:30:09 <cmurf> misread what
19:30:36 <tflink> the bug - there was something in beta about repo= in ks not being supported yet
19:30:49 <tflink> not sure if that includes nfs
19:30:51 <akshayvyas> your kernel must include initramfs support. The ebuild will warn you if your kernel is missing the required options
19:31:31 <akshayvyas> thats what i see here 16.884325] dracut Warning: no suitable images
19:32:04 <tflink> that's probably a consequence of the nfs line in the kickstat
19:33:18 <cmurf> so it gets the kickstart file off nfs,  but it's having a problem finding repo images?
19:33:25 <cmurf> i think the kickstart file is needed
19:33:37 <cmurf> it's like it's not finding this nfs location
19:33:48 <tflink> maybe but I'd rather the anaconda devs decide that one
19:33:49 <cmurf> yet it found the nfs location for the ks file
19:34:01 <akshayvyas> does enabling initramfs will solve theissue
19:34:07 <tflink> which is on the same server as the repo
19:34:29 <tflink> akshayvyas: enabling the initramfs? I don't think you can disable it w/ the installer
19:34:48 <tflink> no initramfs == no installer
19:35:02 <tflink> since anaconda is embedded into the initramfs of the installation iso
19:35:08 <cmurf> heck this could be a permissions problem
19:35:17 <cmurf> could not mount
19:35:28 <cmurf> and then it doesn't find the repo because the path doesn't mount
19:35:30 <cpuobsessed> nmi
19:35:30 <akshayvyas> tflink agree
19:36:07 <cpuobsessed> nmi, punt
19:36:31 <cmurf> call me cynic but it's suspiciously light that it makes me wondering if it's proposed as blocker just to get attention/support
19:36:42 <cmurf> suspiciously light on report details
19:37:22 <cpuobsessed> tflink: if you say ack, then i'll ack
19:38:14 <cmurf> i agree as proposed
19:38:18 <tflink> proposed #agreed - 816867 - AcceptedBlocker - Violates the F17 beta release criterion "The installer must be able to successfully complete a scripted installation, using the installer's preferred scripting system, which duplicates the default interactive installation as closely as possible" - the use of nfs in a kickstart is a documented option and the kickstart is on the same NFS server as the repo specified
19:38:24 <cmurf> i just think there's a good chance this is not a bug
19:38:26 <cmurf> user error
19:38:28 <cpuobsessed> going strictly by criteria it's a blocker, if it turns out something else is to blame (setup/config on server) then it'll be closed at notabug
19:38:35 <tflink> not sure if that's right, but I didn't want to delete it
19:38:36 <cmurf> yeah
19:38:52 <tflink> I wonder if thie repo is properly formed
19:38:52 <cpuobsessed> ack
19:38:58 <cmurf> ack
19:39:15 <cmurf> looks like it 'couldn't mount" the repo location though
19:39:35 <tflink> which is what is making me think that this is another incarnation of "you're not using a complete repo"
19:39:40 <cpuobsessed> we can let anaconda/dracut decide
19:39:40 <tflink> which did change for F17
19:39:40 <cmurf> gotcha
19:39:50 <cmurf> yep that's probably it
19:40:09 <tflink> now to completely contradict myself from earlier and a third proposal
19:40:26 <cpuobsessed> ...and now for something completely different
19:40:30 <cpuobsessed> :D
19:41:03 <tflink> proposed #agreed - 816867 - We need more information before deciding whether or not this is a blocker - is a _complete_ repo (with images etc.) being used?
19:41:20 <tflink> so, punt - I suspect this is a dupe at best
19:41:39 <cmurf> ack
19:41:45 <cmurf> this preferred over previous proposal
19:42:37 <tflink> I promise this is the last one for this bug :)
19:43:26 <cpuobsessed> ack
19:43:47 <tflink> #agreed - 816867 - We need more information before deciding whether or not this is a blocker - is a _complete_ repo (with images etc.) being used?
19:45:05 <akshayvyas> tflink : +1
19:45:30 <tflink> #topic (799667) [abrt] gnome-settings-daemon-3.3.90.1-1.fc17: g_logv: Process /usr/libexec/gnome-settings-daemon was killed by signal 5 (SIGTRAP)
19:45:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799667
19:45:35 <tflink> #info Proposed Blocker, NEW
19:45:46 <tflink> I don't think that there is much to say on this one
19:46:58 <tflink> proposed #agreed - 799667 - Still no response from devs, no new reports for a while. If there are no new reports on this bug by next week - will assume that the hardware is not incredibly common and will reject as a blocker
19:47:05 <cmurf> +1
19:47:11 <cmurf> ack
19:49:27 <cmurf> ok so just reading 26, it seems blocker is contingent on number of users affected as well
19:49:52 <tflink> in general, yes
19:50:12 <cmurf> well
19:50:18 <tflink> if a bug requires specific hardware and that hardware isn't common - it generally isn't a blocker
19:50:19 <cmurf> considering there is a "design suite" specific spin
19:50:41 <cmurf> a wacom tablet is common for designers, i have one even though i'm not
19:50:50 <cmurf> this particular combination of tablet and pen?
19:50:52 <cmurf> wellll
19:50:56 <cmurf> nasty bug should get fixed
19:50:57 <cmurf> blocker?
19:51:00 <tflink> as I read this, it is only a specific wacom tablet
19:51:12 <cmurf> yeah it's a weak case for blocker
19:51:15 <tflink> a specific pen, rather
19:51:20 <cmurf> esp since the work around is plug unplug and play right?
19:52:10 <cpuobsessed> actually it looks like a fix is in place and they are just waiting for confirmation
19:52:32 <cmurf> yeah i'm a -1 to block on this
19:52:44 <cmurf> what release criteria would even apply?
19:53:04 <cpuobsessed> desktop won't load with the stylus plugged in
19:53:10 <cmurf> got it
19:53:16 <cmurf> -1
19:53:19 <cmurf> there's a work around
19:53:23 <jsmith> Right... ABRT on login, right?
19:53:26 <tflink> "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use"
19:53:35 <tflink> and it can't be fixed w/ updates in the livecd case
19:53:40 <cmurf> well common is the way out of this
19:53:54 <cmurf> is there a Live-Desktop spin that has design apps in it?
19:54:12 <tflink> the design suite does
19:54:26 <cmurf> I think it's install media, not Live
19:54:38 <tflink> which wouldn't be enough cause for blocking
19:54:45 <cmurf> I'm wrong, it's live. I just checked.
19:55:14 <cmurf> So I'm with adamw, it's not all wacom tablets. It's not just a particular tablet, it's a particular pen and tablet.
19:55:15 <tflink> someone may have a tablet plugged in to their system when trying a livecd
19:55:30 <cmurf> And work arounds are in effect, so maybe the live media doesn't get the fix but won't affect all wacom users anyway.
19:55:36 <akshayvyas> yep cmurf its live
19:56:30 <tflink> so what are the votes on blocker?
19:56:50 * tflink votes punt for another week, see if there are more reports
19:56:54 <cmurf> i'm on the fence. if it weren't for this in the last comment "These were very popular among the "low-end" wacom tablets so the affected users
19:56:54 <cmurf> could be numerous. " I'd vote -1
19:57:22 <cmurf> Who produces the design spin? They should be asked.
19:57:39 <tflink> cmurf: it wouldn't affect the blocker status of a bug
19:57:53 <tflink> unless I misunderstood you
19:57:53 <cmurf> if we know many people are negatively affected, it might
19:58:02 <tflink> yep, I misunderstood you
19:58:06 <cpuobsessed> not a blocker
19:58:53 <tflink> cmurf: not sure if you're voting -1, +1 or punt for 1 more week
19:58:58 <cmurf> If someone told us they estimated 50% of Design Suite target users were to experience a crash using Live media? what would we say?
19:59:42 <cmurf> I'm suggesting punt, and ask the Design Suite spin people what their take is on this problem for the usability of the DS spin. *shrug*
19:59:58 <akshayvyas> cmurf : +1
20:00:02 <tflink> so -1 blocker +2 punt
20:00:04 <tflink> so -1 blocker +3 punt
20:00:11 <cpuobsessed> punt
20:00:30 <tflink> #agreed - 799667 - Still no response from devs, no new reports for a while. If there are no new reports on this bug by next week - will assume that the hardware is not incredibly common and will reject as a blocker
20:00:49 <cpuobsessed> ack
20:01:13 <cmurf> ack
20:01:27 <tflink> how are you all feeling WRT time? We've been at this for ~ 3 hours
20:02:12 <cmurf> i may skip the next bug, need food
20:02:13 <tflink> I count 18 proposed blockers remaining
20:02:19 <akshayvyas> tflink :)
20:02:20 <cpuobsessed> bleh
20:02:25 <cmurf> but i'm presently in the kitchen so...
20:02:28 * jsmith has to go again
20:02:42 <cpuobsessed> continue tomorrow
20:02:50 <tflink> I'm OK with stopping here or after another bug or two
20:03:04 <cmurf> ok one more
20:03:08 <tflink> I didn't think we'd get through everything today and we've gotten farther than I thought we would
20:03:10 <cpuobsessed> one more
20:04:43 * tflink is looking for one that isn't going to be a hairy debate
20:04:44 <cpuobsessed> maybe setup a separate channel for bug reviews
20:05:06 <akshayvyas> cpuobsessed: +1
20:05:09 <tflink> the list isn't usually this long
20:05:30 <tflink> we just got a little behind from the first meeting of Final - lots of stuff got put off
20:05:35 <cmurf> especially at final tc2!
20:06:48 <tflink> gah, I don't really want to deal with most of the rest of these today
20:07:01 <tflink> pretty much everything left is either going to be closed in the next day or so
20:07:07 <tflink> or is going to be a long debate
20:07:14 * tflink proposed we stop here for the day
20:07:18 <tflink> proposes
20:07:24 <cmurf> agreed
20:07:29 <cmurf> cutting tomatoes
20:07:29 <akshayvyas> agree
20:07:36 <tflink> #topic Open Floor
20:07:41 <akshayvyas> cmurf: :)
20:07:52 <tflink> BTW, you guys are awesome for stepping up and helping with this
20:08:00 <tflink> I really appreciate it
20:08:33 <tflink> #info The list isn't fully reviewed but 3 hours is enough for one day
20:08:47 <tflink> #action tflink to translate meeting agreements into bugzilla
20:08:59 <cpuobsessed> .bug 815360
20:09:00 <tflink> #info May have another blocker review meeting before friday
20:09:01 <zodbot> cpuobsessed: Bug 815360 X crashes when switching users - https://bugzilla.redhat.com/show_bug.cgi?id=815360
20:09:26 <cpuobsessed> you've already commented on it
20:09:43 <cmurf> i read it earlier
20:09:44 <cmurf> -1
20:09:54 <cpuobsessed> not a blocker
20:10:08 <tflink> #undo
20:10:08 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x25298110>
20:10:08 <cpuobsessed> tflink: one more for the record
20:10:11 <tflink> #undo
20:10:11 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x1cf4df10>
20:10:15 <tflink> #undo
20:10:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x30612fd0>
20:10:19 <tflink> #undo
20:10:19 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x306128d0>
20:10:28 <tflink> #topic (815360) X crashes when switching users
20:10:29 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815360
20:10:29 <tflink> #info Proposed Blocker, NEW
20:10:38 <cmurf> -1
20:10:43 <cpuobsessed> -1
20:11:23 <akshayvyas> go with cmurf
20:11:23 <tflink> proposed #agreed - 815360 - RejectedBlocker  - This seems to be specific to VMs and the qxl driver - it could be fixed with an update and doesn't clearly hit any of the F17 release criteria.
20:11:33 <cmurf> ack
20:11:38 <cpuobsessed> ack
20:11:51 <tflink> #agreed - 815360 - RejectedBlocker  - This seems to be specific to VMs and the qxl driver - it could be fixed with an update and doesn't clearly hit any of the F17 release criteria.
20:12:06 <tflink> are there any other easy ones that I'm missing?
20:13:19 <tflink> #topic Open Floor
20:13:27 <tflink> #info The list isn't fully reviewed but 3 hours is enough for one day
20:13:31 <cmurf> unrelated question: some of these fail boot/install media bugs have titles that include "TC1" and "RC3" etc which is annoying, is there a way to get those cleaned up? redo the titles?
20:13:33 <tflink> #info May have another blocker review meeting before friday
20:13:42 <tflink> #action tflink to translate meeting agreements into bugzilla
20:14:28 <tflink> cmurf: sure, it's possible but the TC1 or RC3 can be useful information
20:14:57 <tflink> I assume that you're talking about stuff like #811438
20:15:07 <cmurf> seems like that should be in the version line rather than in the title
20:15:22 <cmurf> yes
20:15:37 <tflink> some of them could be removed, yes
20:16:01 <tflink> 811438 is a bad example since that refers to a specific version of a specific spin
20:16:07 <cmurf> yeah i understand
20:16:12 <cmurf> i'm thinking more of the EFI boot bugs
20:16:27 <cmurf> USB vs DVD vs Live vs dd'd vs livecd-iso-to-disk
20:16:30 <tflink> yeah, I should have chosen my example better
20:16:45 <cmurf> i'd like a standardized title because right now it's a CF
20:16:49 <akshayvyas> gotta read more on efi its really a mystry to me ryt noe :0
20:16:51 <tflink> I guess that I'm of the opinion that it's better to leave well enough alone unless its inaccurate
20:17:04 <tflink> if we go changing the titles, it might look like different bugs
20:17:19 <cmurf> akshayvyas: it sucks, lots of problems, huge numbers of bugs, and more code than base linux kernel
20:17:22 <cmurf> which is insane
20:17:27 <tflink> and if we wanted to correct all of the suboptimal bug titles ... good luck :)
20:17:48 <akshayvyas> yep i agree cmurf
20:17:58 <akshayvyas> tflink :)
20:18:11 <cmurf> yeah i was mostly asking about protocol. i dunno if i have privilege to edit other people's titles but at least the EFI booting ones I could standardize, i'll ask adamw if i continue to be irritated by it enough.
20:18:49 <cmurf> actually it may be an mjg question, if he's not irritated, i should let it go
20:19:53 <tflink> if the devs aren't complaining, I'm fine with leaving the titles alone - less autmated email :)
20:20:03 <cmurf> i'll probably get lazy and leave it alone. gonna go cut some more tomatoes.
20:20:19 <tflink> lazy can be good some times :)
20:20:32 <tflink> anyhow, if there are no other topics, I'll set the fuse for ~ 5 minutes
20:20:45 <cmurf> i'm out
20:20:46 <cmurf> cya
20:21:04 <tflink> thanks again for your help, everyone!
20:21:20 <jsmith> tflink: Sorry I kept getting pulled away :-(
20:21:26 <tflink> it's very much appreciated
20:21:34 <akshayvyas> cya sleep time ,nice to meet you all tflink ,cmurf and cpuobsessed
20:21:35 <tflink> jsmith: no worries, it happens
20:21:48 <tflink> akshayvyas: good night
20:22:02 <akshayvyas> thanks tflink :)
20:22:04 <akshayvyas> cya
20:23:13 <tflink> eh, 3 minutes is close enough to 5 ...
20:23:24 * tflink will send out minutes and secretarialize shortly
20:23:27 <tflink> #endmeeting