17:01:45 #startmeeting f17-final-blocker-review-2 17:01:45 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:53 #meetingname f17-final-blocker-review-2 17:01:53 The meeting name has been set to 'f17-final-blocker-review-2' 17:01:56 #topic roll call 17:02:05 anyone here for the blocker review meeting? 17:02:57 present 17:04:01 cpuobsessed: welcome 17:04:13 crap, adam isn't even online ATM 17:04:17 * cpuobsessed hurry for me! 17:04:26 hurray 17:04:35 i mean for me 17:05:06 well, if it's just the two of us - there's no point in even doing this :-/ 17:05:10 anyone else here? 17:05:22 if they are here, they haven't said anything 17:05:42 * kalev tries to stay unseen. 17:05:52 it's a public holiday in the czech republic today and lots of the usual suspects are there 17:06:18 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 it's getting obscenely long :'( 17:06:53 that's three, everyone take out your osterhagen key 17:07:02 tflink: just lurking, not planning to participate in the review 17:07:22 tflink: reschedule or just skip? 17:07:23 kalev: ok, that's what I figured but thought I would ask 17:07:31 cpuobsessed: reschedule ... again 17:07:36 I'll wait a few more minutes 17:07:45 but the last email said Tuesday, 2012-05-02 17:07:58 I can't imagine that the confusion is helping 17:18:53 OK, I'm giving it 2 more minutes - if we don't get anyone else, I'll reschedule for tomorrow 17:20:05 I have a question while we wait 17:20:22 cmurf: go for it 17:20:48 not like we're doing anything else :P 17:20:57 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 it could be, the GRUB EFI menus are certainly more sparse than the syslinux ones 17:22:57 cmurf: can you file a bug against grub and mark it as blocking 752650 ? 17:23:08 yep 17:23:13 thanks 17:23:18 well, I give up for today 17:23:32 #info Not enough attendees for quorum 17:23:52 #info Rescheduling again for 2012-05-02 @ 17:00 UTC 17:24:14 what component? 17:24:21 cmurf: grub 17:24:41 oh right 8-\ silly 17:25:55 cpuobsessed: you still around 17:26:04 yesh 17:26:19 * cpuobsessed sets his drink down 17:26:43 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 strike up the band! 17:27:52 * cpuobsessed stumbles over his chair 17:28:22 fortunately work is slow 17:28:35 well, I thought that jsmith would be joining us 17:29:30 let's get the boilerplate out of the way 17:29:46 #topic Introduction 17:29:56 #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 Following the process of: 17:30:14 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:30:27 The F17 release criteria are: 17:30:34 #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria 17:30:44 I'll be working off of the following list of bugs: 17:30:51 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:31:06 I know we're not going to get through all of this today, but for the sake of record ... 17:31:14 #info 25 proposed blockers 17:31:14 #info 11 accepted blockers 17:31:14 #info 10 proposed blockers 17:31:24 holy crap 17:31:26 Let's get started with the proposed blockers 17:31:42 cpuobsessed: no kidding, that's why I want to get this list pared down :/ 17:31:48 #topic (816509) 'Updates' notification not showing up in Gnome (F17 TC1) 17:31:51 #link http://bugzilla.redhat.com/show_bug.cgi?id=816509 17:31:54 #info Proposed Blocker, NEW 17:32:08 this seems like a pretty clear blocker to me 17:32:38 especially considering the fact that i am running f17-tc2 and haven't seen the updates notification 17:32:54 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 ack/nak/patch? 17:33:09 ack 17:34:41 i just ran software update and have 50 updates, and no notifications in any tray 17:35:00 definitely a bug 17:35:05 cpuobsessed: can you add that to the bug when you get a chance? 17:35:23 installation method, how long ago you installed, which desktop you're using etc. 17:35:29 jsmith: you there? 17:35:35 np 17:35:41 thanks 17:37:16 well, this is an obvious blocker - I guess that 2 acks will work 17:37:25 #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 816238 17:38:36 updated 816509 17:38:47 cpuobsessed: thanks 17:38:49 tflink, it happned with me on fedora 16 but is it really a bug 17:39:18 816701 should also be uncontroversial obvious blocker 17:40:35 cmurf: i don't believe so 17:40:43 cmurf: I see where you're coming from but not sure I agree - it doesn't clearly violate any release criteria 17:40:51 i have a bios system and having gpt table didn't affect anything 17:40:57 akshayvyas: you mean the lack of updates notifications? 17:41:09 tflink yep 17:41:31 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 there are too many machines that do have problems with GPT, and the blacklisting isn't working 17:41:59 and the consequence of reversion is zero 17:42:07 i was speaking from my perspective, my system is quite old 17:42:08 akshayvyas: why do you think that it isn't a bug? 17:42:25 yeah, I think that the GPT thing will likely be a blocker 17:42:26 tflink: i think more data is needed 17:42:32 i might happen due to t network 17:42:42 cpuobsessed: there is a bunch of data, it's just not in the bug 17:43:57 how can i tell if i have gpt table? bios boot partition? 17:44:12 parted -l 17:44:15 cpuobsessed: either that or use parted/fdisk 17:44:19 disklabel either GPT or MSDOS 17:44:27 fdisk will complain if you have GPT and parted will tell you 17:44:43 cmurf: you interested in sticking around for some blocker review? 17:44:52 for a bit 17:45:12 cool, then we can keep going. just let us know when you leave :) 17:45:18 gpt 17:45:44 #topic (806166) Installation using DVD ISO dd'd to USB can't use USB as installation source 17:45:46 core2duo compaq 6910p; just me of course 17:45:47 #link http://bugzilla.redhat.com/show_bug.cgi?id=806166 17:45:50 #info Proposed Blocker, ON_QA 17:46:00 paf, i thought they fixed 17:46:13 I'm +1 blocker on this even though it should be fixed 17:46:39 ATM, dd is the only supported method for creating USB install media for non-fedora linux and OSX 17:46:40 +1 blocker 17:46:41 it's not working for EFI i can vouch for that 17:46:46 i mostly use dvd-rw now but have used usb; which most people probably do for testing 17:47:07 ack 17:48:06 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 yeah, I was just looking 17:48:44 iirc the install was supposed to be updated 17:48:46 I thought that there was a USB criterion 17:49:33 not finding it in alpha, beta, or final 17:49:52 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 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 ack 17:52:01 i tried both realese alpha and beta on usb but it was live cd 17:52:36 yeah, this particular issue is for non-live DVDs during installation 17:53:17 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 cmurf: the EFI issue for DVDs is known, not sure what the bug is but that's an issue w/ pungi 17:54:16 mkhybridiso isn't being run 17:54:38 I think that's the command, anyways. The resultant DVD isn't hybrid-ized for EFI 17:56:03 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 any other ack/nak/patch on the proposal? 17:56:47 yes. whether the issue is release blocking or not is solely depenent on the impact of the issue 17:56:56 got it 17:57:00 if it is indeed fixed, it'll just be closed 17:57:05 ack 17:57:31 https://bugzilla.redhat.com/show_bug.cgi?id=816410 this ne is fr uefi 17:58:06 so we're not here to determine if it's fixed, just whether it's blocking 17:58:13 yep 17:58:39 just waiting for another ack before moving on 17:59:16 akshayvyas: that's for livecds, the issue with installation DVDs is different 18:00:16 ACK 18:00:31 #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 #topic (815827) Connection to root iSCSI disk is disrupted during boot 18:01:00 read: netbook or other device without optical drive 18:01:00 #link http://bugzilla.redhat.com/show_bug.cgi?id=815827 18:01:02 #info Proposed Blocker, NEW 18:01:11 this is another by-the-books-blocker 18:01:18 * cpuobsessed doesn't know what iSCSI is 18:01:23 many of the media booting bugs need cleaned up titles. including candidate numbers is annoying. 18:01:36 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 so be it 18:01:53 ack 18:01:58 cpuobsessed: it's a method of presenting a block storage device (disk) over the network 18:01:58 Yes, obvious blocker. 18:02:07 +1 blocker 18:02:28 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 ack/nak/patch? 18:02:33 ACK 18:02:40 ack 18:02:43 haha am i voting? 18:02:57 cmurf: you're just slow, vote 18:02:57 cmurf: anyone here can vote 18:03:02 ack 18:03:06 #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 is iSCSI software or hardware dependent 18:03:50 its both its actully network dependent 18:03:52 cpuobsessed: you can use either software or hardware for iscsi 18:03:55 both, but primarily software initiator 18:04:21 #topic (816238) upgrade using boot.iso destroys EFI boot 18:04:21 #link http://bugzilla.redhat.com/show_bug.cgi?id=816238 18:04:21 #info Proposed Blocker, NEW 18:04:21 prolly not good to try on wifi g 18:04:42 cpuobsessed: no, I'd suggest using iSCSI over a wired network if possible 18:04:56 tflink agree 18:05:04 aight 18:05:26 i've only got one efi machine; and i've put chromeos back on it 18:05:53 but i think its god to tempery mount iscsi insted of making fstab entry 18:06:05 +1 block on 816238 18:06:13 akshayvyas: depends on your setup, I think 18:06:30 if you have a stable network, I don't see any problems w/ having a statically mounted iSCSI lun 18:07:01 I question the wisdom of ever booting from SAN/NAS but people do it 18:07:08 tflink yes but it needs proper conf 18:07:37 dracut is realy good about mounting iSCSI luns @ boot and it tends not to be much of an issue 18:07:53 well, dracut/systemd - it depends on which mount point we're talking about 18:08:20 hello 816238? 18:08:29 bcl: I'm hoping that you're here for the EFI upgrade issue? 18:08:41 cmurf: I was waiting for some input from the anaconda devs 18:08:55 I'd rather not take this as a blocker without their input 18:09:21 yeah, reading now. 18:11:10 I'm probably +1 blocker on this, though 18:11:59 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 yeah, as adam put it - ignoring the bootloader should actually ignore the bootloader 18:12:46 we also need to make sure all the grub2 tools are available in rescue. 18:13:04 (there may be a bug for that, I'm still catching up) 18:13:20 this is on an EFI system though? 18:13:32 oh yeah, I still don't understand that one. I couldn't reproduce those claims 18:13:47 cmurf: yeah, EFI so it would be grub or grubby 18:14:03 * jsmith finishes reading the bug details 18:14:13 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 I'll give it a try here if I have time today and see if I can nail it down more. 18:14:38 Yeah, I guess I'm think this is +1 blocker, but it's certainly a bit vague 18:14:42 Could use some more research 18:14:44 And Fedora is not using grub2-efi 18:14:48 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 cmurf: I took that as meaning that tools for both grub versions are missing. 18:15:16 i did the exact same thing on non-efi and it worked 18:15:21 OK 18:15:35 I've tried it recently on EFI and the tools do exist outside the installed system on the boot.iso 18:15:55 ok, good. 18:16:04 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 yeah i agree 18:16:39 adding tools is a template change in lorax so should be as safe as anything. 18:17:11 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 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 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 afaict upgrades are from previous release to new release 18:18:07 My question has been answered never mind. 18:18:07 cmurf: I'd say not really. I'm mostly concerned with upgrades from f16. 18:19:11 nack 18:19:18 I see the alphas/betas as entirely expendable installs, personally. 18:19:21 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 cpuobsessed: patch? 18:19:31 ack 18:20:01 if it can be reproduced from an updated f16 install 18:21:00 if it turns out that F16->F17 upgrade is not affected, we can remove blocker status 18:21:05 all the notes indicate the upgrade was from one F17 to another; not a previoues F16 18:21:07 or we can punt until more testing is done 18:21:14 punt 18:21:41 any other votes? 18:21:55 how about issue needinfo and keep it as a blocker 18:22:10 I could go either way, honestly 18:22:10 if no new info next round, give it the boot print 18:22:28 doesn't meet the criteria for blocker 18:22:29 it needs more testing to clarify impact and all of the claims 18:22:46 I'd like to know for sure if it happens when upgrading from f16. it probably does though. 18:22:49 it's already accepted as a blocker 18:22:49 tflink: +1 18:22:58 ok, I'm fine with punting 18:23:04 Oh nevermind i can't read - sorry 18:23:09 nmi 18:24:03 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 ack/nak/patch? 18:24:17 ack 18:24:20 ack 18:24:31 #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 how is everyone feeling about time? 18:26:09 how about https://bugzilla.redhat.com/show_bug.cgi?id=816493 18:26:10 I think we've hit all the less-ambiguous blockers 18:26:21 tflink: i think it needs more testing 18:26:32 cpuobsessed: I'm avoiding that one on purpose :) 18:26:58 i have a winner seeing as we've already done one iscsi block already: 815827 18:27:10 a winner? 18:27:31 winner=obvious uncontroversial blocker 18:28:05 there's nothing in the criteria that says that network time is required 18:28:10 afaict 18:28:23 yeah, but it can't be fixed with updates which makes it more blocker material 18:28:24 right, so I'd be -1 on 816493 18:28:30 and +1 on 815827 18:28:59 ok, let's do these in order :) 18:29:03 #topic (816495) Network time can't be enabled 18:29:03 #link http://bugzilla.redhat.com/show_bug.cgi?id=816495 18:29:03 #info Proposed Blocker, ON_QA 18:29:54 this is the original bug that spawned the ntp/chrony bugs 18:30:03 crap, I got the wrong one 18:30:06 #undo 18:30:06 Removing item from minutes: 18:30:08 #undo 18:30:08 Removing item from minutes: 18:30:09 #undo 18:30:09 Removing item from minutes: 18:30:30 #topic (815748) Network time can't be enabled 18:30:30 #link http://bugzilla.redhat.com/show_bug.cgi?id=815748 18:30:30 #info Proposed Blocker, ON_QA 18:30:37 OK, got the right one this time 18:30:51 this is the original bug that spawned the ntp and chrony bugs 18:31:30 but i dnt really get it configuring ntpd manually is nt working 18:31:38 how can it be possibe 18:32:42 akshayvyas: not sure I understand 18:32:58 AFAIK, enabling ntp in firstboot after install is not working 18:33:06 due to the way that it is being enabled 18:33:21 manually enabling ntpd and chronyd should still work 18:34:04 i don't see the issue: http://fpaste.org/cHoI/ 18:34:10 hmm so what constitutes "the default panel (or equivalent)" 18:34:25 it's a little bit of a stretch, I think 18:34:43 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 does the panel keep time and display it correctly: yes 18:34:56 right 18:35:02 can you set it manually? yes 18:35:04 then that could be an issue with your rtc 18:35:09 will an update fix network sync? 18:35:37 not sure, but I don't think so 18:35:40 looks like the latest update fixes ntp/chrony 18:35:59 yeah, this should make it in before freeze 18:35:59 -1 blocker for me 18:36:15 comment 4 implies to me that an update will fix this 18:36:51 good point 18:37:24 maybe needinfo to lennart and confirm that an update will fix? or must it be fixed on release media? 18:37:44 i feel the bottom line is "is network time a final criteria"? 18:38:03 if it can be fixed with an update, I don't think it needs to be a blocker 18:38:07 well, i think yes if it's impossible for it to work for the entire fedora life cycle 18:38:19 if it can be fixed with update, i'm -1 18:38:29 if it can't be fixed, I'm +100 haha 18:38:30 i have the latest systemd, and my time is working, chrony is running 18:38:33 tflink : +1 for update 18:38:52 cpuobsessed: did you enable ntp from firstboot @ install time? 18:39:08 tflink: always 18:39:50 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 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 ack 18:40:28 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 typo 18:41:02 ack 18:42:04 ps x | grep chrony 18:42:07 should that work 18:42:28 systemctl status chronyd.service would be better, I think 18:42:53 any other votes? 18:42:56 pa aux | grep chrony i will g with cmurf 18:43:00 ps aux | grep chrony I've got it 18:43:00 :) 18:43:30 it's running, and systemd reports its status as active 18:43:35 i'm running F17-TC2 and chrony is working 18:43:40 this is TC2, time enabled with firstboot 18:43:50 same here 18:44:02 if you could add the reports to the bug, that would be awesome 18:44:39 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 +1 cpuobsessed 18:45:04 I suppose that would be the part about the panel not working 18:45:26 updated bug 18:45:52 +1 tflink 18:46:11 any more votes on the proposal? 18:46:15 I see one ack 18:46:19 nack 18:46:25 cpuobsessed: patch? 18:46:29 patch 18:46:37 yes patch 18:46:41 i ack'd twice but it's moot, it's fixed 18:47:21 maybe but at the moment, we're looking at the impact of the issue - not whether it's fixed or not :) 18:47:34 cpuobsessed: what do you propose for a patch? 18:49:20 wait, what does patch mean? patch will fix or patch to proposal 18:50:01 patch means that you have a change to the proposal 18:51:21 oh, then i stand by nack 18:51:54 cpuobsessed: ok, what part of the proposal do you not like? 18:52:22 i still don't feel it meets any blocking criteria 18:53:52 network time is not in critical path? 18:53:54 ntp/chrony is not required to work, the panel still displays the correct time 18:54:47 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 the proposal only blocks if it can't be fixed with an update 18:55:17 which it appears that it can 18:55:35 appears it can be fixed with an update, but also appears to be working and not need an update 18:55:40 so i agree with the proposal 18:56:05 but you're right that there doesn't appear to be any 100% clear violation of the release criteria 18:56:34 but like cmurf said, as long as it can be fixed by an update, it would be rejected as a blocker 18:56:47 if it can't be fixed as an update, we'll end up re-visiting it 18:57:02 i'm not going by release criteria, i'm going by "final block bugs" under the criteria 18:57:03 tflink: i see why you didn't want to look at this one 18:57:08 tflink +1 18:57:28 my opinion, not a blocker 18:57:49 so we have 2 acks (including me) and one nak 18:58:05 akshayvyas: you have an opinion on the proposal? 18:58:09 are we deadlocked? 18:58:38 network time is sure in a critical path package 18:58:39 no, I just prefer to have more than a one vote margin if possible 18:58:52 if it is, and it cannot be fixed, that clearly is blocker 18:59:09 cmurf: good point 18:59:41 Any criticalpath bug that can't be fixed with an update is a blocker 18:59:51 sorry, I appear to be slow ATM - you said that before 19:00:21 i think it will be fixed in update 19:00:24 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 i think it's fixed now, it's in TC2, not a bug 19:00:52 according to http://kojipkgs.fedoraproject.org/mash/branched-20120401/logs/critpath.txt neither chrony or ntp is there 19:01:29 surprising 19:01:33 honestly, I just want to be done with this since it appears to be fixed anyways 19:01:40 out of sync time causes lots of problems 19:01:47 and any decision is pretty much a moot point 19:01:51 well then punt and move on 19:02:02 I tried that but got naked 19:02:14 oh really? 19:02:22 interesting response 19:02:35 punt 19:03:07 cpuobsessed: you're the one nak-ing 19:03:13 :-P 19:03:21 cpuobsessed:: it seems like ntpd is nt enabled on bt 19:03:25 boot 19:03:38 is it possible this is only an i686 bug? 19:03:47 i'm on x86_64 and it works 19:03:49 aight ack it 19:04:25 * cpuobsessed changes to ack but with reservations 19:04:31 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 any better? 19:04:55 how about we ask if it's still a bug? 19:05:00 supposed to be fixed 19:05:07 it's still a bug either way 19:05:16 * cpuobsessed agrees 19:05:18 but if it ends up being closed, it drops off the proposed blocker list 19:05:23 gotcha 19:06:00 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 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