17:00:36 <tflink> #startmeeting f17-final-blocker-review-3
17:00:36 <zodbot> Meeting started Thu May  3 17:00:36 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:40 <tflink> #meetingname f17-final-blocker-review-3
17:00:40 <zodbot> The meeting name has been set to 'f17-final-blocker-review-3'
17:00:45 <tflink> #topic Roll Call
17:00:56 * kparal somewhat present
17:00:57 <tflink> Who's ready for some fun blocker review time?
17:01:29 <tflink> #chair adamw
17:01:29 <zodbot> Current chairs: adamw tflink
17:01:37 * adamw raises hand reluctantl
17:01:38 <adamw> y
17:02:23 * satellit_ listening
17:02:52 <tflink> kparal: I assume that you'll be only somewhat participating?
17:03:10 * akshayvyas here
17:03:25 <kparal> right
17:03:26 <tflink> akshayvyas: welcome
17:03:43 <akshayvyas> tflink: thanks :0
17:04:10 <akshayvyas> cpuobsessed is here :)
17:04:57 * tflink waits another minute before getting started
17:05:55 <tflink> ok, lets get started with some boilerplate
17:05:59 <tflink> #topic introduction
17:06:11 <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:06:26 <tflink> The process we'll be following is outlined at:
17:06:36 <tflink> #link #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:41 <tflink> #undo
17:06:41 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x3035f390>
17:06:48 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:06:58 <adamw> ten points
17:07:03 <tflink> The list of bugs that we'll be working off of is:
17:07:10 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:07:32 <tflink> The F17 final release requirements can be found at:
17:07:41 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
17:07:51 <tflink> Up for review today, we have:
17:07:58 <tflink> #info 13 proposed blockers
17:07:59 <tflink> #info 12 accepted blockers
17:07:59 <tflink> #info 10 proposed NTH\
17:08:28 <tflink> any volunteers to secretarialize?
17:09:05 <adamw> i'll do it
17:09:09 <tflink> thanks
17:09:22 <tflink> if there are no objections, I'll start with the proposed blockers
17:10:07 <tflink> silence == no objections
17:10:10 <tflink> #topic (816701) Anaconda should not default to gpt on BIOS systems
17:10:10 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816701
17:10:10 <tflink> #info Proposed Blocker, MODIFIED
17:10:44 <tflink> this has already been fixed, no?
17:10:49 <bcl> yep. 17.24-1
17:10:59 <tflink> ah, we have a new anaconda build, too?
17:11:03 <bcl> so I'm +1 :)
17:11:04 <akshayvyas> yeh
17:11:14 <akshayvyas> blc: +1
17:11:23 <bcl> and another later today, as well as new lorax and livecd-creator :)
17:11:28 <adamw> -1, this isn't a blocker, really. it's a perfectly sensible change and one i support. but it ain't a blokcer.
17:11:39 <adamw> or else we should be recalling f16. =)
17:11:49 <tflink> yeah, I was trying to figure out what criterion we might use for this
17:12:03 <tflink> I assume that existing systems with GPT will go on using GPT?
17:12:13 <tflink> after upgrade/update, I mean
17:12:21 <adamw> yeah, any change to this only affects fresh formats.
17:12:26 <bcl> yes, doesn't change existing systems, new install only.
17:12:46 <tflink> I'm -1 blocker as well
17:12:55 <red_alert> clearly -1 blocker
17:13:39 <tflink> proposed #agreed - 816710 - RejectedBlocker - While this is a sensible change, it doesn't hit any of the release criteria and we're still before the final code freeze
17:13:43 <tflink> ack/nak/patch?
17:13:47 <adamw> ack
17:13:48 <akshayvyas> what does that comment mean We already blacklist Lenovos because..
17:14:10 <adamw> akshayvyas: in f16, lenovos still got msdos disklabel (not gpt) because we knew most of them didn't handle gpt properly.
17:14:23 <tflink> gpt+bios
17:14:43 <akshayvyas> adamw: got ya
17:14:45 <adamw> right.
17:14:54 <tflink> gpt+efi is still valid
17:15:02 <tflink> will still be used, rather
17:15:09 <cpuobsessed> present
17:15:41 <tflink> ack/nak/patch?
17:15:51 <red_alert> ack
17:15:56 <akshayvyas> ack
17:16:12 <tflink> #agreed - 816710 - RejectedBlocker - While this is a sensible change, it doesn't hit any of the release criteria and we're still before the final code freeze
17:16:18 <tflink> #topic (814690) Users are not logged out correctly
17:16:19 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=814690
17:16:19 <tflink> #info Proposed Blocker, NEW
17:17:28 <adamw> tflink: oop
17:17:38 <adamw> you got 816710 for 816701
17:17:40 <tflink> adamw: ?
17:17:59 <tflink> crap
17:18:02 <tflink> #undo
17:18:02 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x23149f50>
17:18:04 <tflink> #undo
17:18:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x23149410>
17:18:06 <tflink> #undo
17:18:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x23149ad0>
17:18:09 <tflink> #undo
17:18:09 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x23149c50>
17:18:23 <tflink> #agreed - 816701 - RejectedBlocker - While this is a sensible change, it doesn't hit any of the release criteria and we're still before the final code freeze
17:18:25 <bcl> meetbot realy needs to be taught strings :)
17:18:31 <tflink> #topic (814690) Users are not logged out correctly
17:18:31 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=814690
17:18:31 <tflink> #info Proposed Blocker, NEW
17:18:39 <akshayvyas> bcl: +1
17:18:49 <tflink> after that mess of #undos
17:19:08 <akshayvyas> 814690 is a bug ?
17:19:18 <tflink> I'm still unsure of this one - the result is ugly but I'm not sure that it's a blocker
17:19:36 <tflink> logging out doesn't seem to be something many people would do on the livecds
17:19:48 <tflink> and it could be pretty much fixed with updates
17:19:48 <kparal> tflink: and on real systems?
17:19:48 <akshayvyas> he is trying to delete the user from root
17:20:15 <tflink> the only snag is if you hit this @ first login and can't reboot after updating
17:20:31 <kparal> trying to delete a user reproduces the problem 100%. logging out is broken just scarcely. can't find reproducer. but it is probably related
17:21:06 <kparal> if we fix user deletion, I believe we fix also logging out/rebooting
17:21:17 <kparal> well, logging out works every time
17:21:28 <kparal> rebooting/powering off requires admin password sometimes
17:21:46 <tflink> kparal: how often have you hit that?
17:22:02 <kparal> several times on 3 different machines during the last few weeks
17:22:09 <kparal> about once a week, maybe twice
17:22:24 <cpuobsessed> this doesn't seem to be a "normal" user activity
17:22:39 <kparal> rebooting?
17:22:54 <cpuobsessed> deleting an account
17:23:04 <tflink> cpuobsessed: this is also reported for rebooting w/o deleting the user account
17:23:05 <kparal> that is only a way how to detect the problem for sure
17:23:09 <kparal> yep
17:23:37 <cpuobsessed> i've never hit any problem rebooting
17:23:45 <akshayvyas> me 2
17:23:51 <tflink> while ugly, I have a hard time seeing a situation where someone hit this before updating and didn't have the adming password
17:23:52 <adamw> this seems a bit corner case-y to take as a blocker
17:24:01 <tflink> s/adming/admin
17:24:04 <kparal> I definitely saw that like "start machine -> log in -> do something -> power off -> please enter password, other users are logged in" . no user deletion in the middle
17:24:06 <adamw> especially since it seems to rely on fast user switching
17:24:15 <cpuobsessed> adamw +1
17:24:20 <adamw> kparal: but you have to switch accounts at least, right?
17:24:29 <adamw> i've _never_ seen this happen when just working with one account at a time.
17:24:30 <kparal> tflink: how can you be sure this will be fixed by zero-day updates?
17:24:32 <kparal> adamw: no
17:24:36 <kparal> no switching accounts either
17:24:46 <kparal> maybe packagekit is really involved
17:24:58 <kparal> I probably updated my system while logged in
17:25:01 <cpuobsessed> nfi?
17:25:01 <tflink> kparal: we can't
17:25:27 <tflink> but I could modify my statment to be users who upgrade right after release and don't have access to admin password
17:26:06 <cpuobsessed> tflink +1
17:26:08 <akshayvyas> I have two users - admin....what does that admin mean here i mean user user or rot user
17:26:10 <adamw> kparal: oh. that wasn't clear in the bug...
17:26:31 <adamw> well, i'd at least want someone else to reproduce this with no requirement for user switching or anything to take it as a blocker i think
17:26:53 <kparal> it just happens too infrequently :/
17:27:11 <tflink> akshayvyas: I'm a little fuzzy on the "admin" user in gnome but AFAIK it's equivalent to sudo powers
17:27:25 <cpuobsessed> reject as too "corner case-y" (as adamw said)
17:27:46 <mclasen> admin == wheel
17:27:56 <cpuobsessed> sounds like "you do this then do that then try this"
17:27:57 <kparal> right, in wheel group, I suppose
17:28:08 <tflink> proposed #agreed - 814690 - RejectedBlocker - While ugly, the consistent triggers are too much of a corner case to take this as a blocker and the other reproducers are too infrequent
17:28:12 <kparal> cpuobsessed: reproducer is uknown
17:28:27 <akshayvyas> so he specified two users in comment (I have two users - admin and another one)
17:28:48 <cpuobsessed> ack
17:28:49 <kparal> right, but yesterday I saw it on a single user machine
17:29:44 <red_alert> I'd rather allow a bit more time to get this reproduced and revisit it at a later time than just outright rejecting it
17:29:58 <adamw> we can always re-vote, but that may be an idea
17:30:07 <kparal> can some devel look into reasons why we can't delete accounts? that's 100% reproducible
17:30:19 <red_alert> sure, but once it's rejected things tend to get off the radar\
17:30:44 <akshayvyas> if we have tw users ie rot and normal user how can it be possible t delete normal user frm rot
17:31:02 <tflink> akshayvyas: root isn't counted as a user in this case
17:31:14 <tflink> it's two non-root users
17:31:17 <kparal> right
17:31:21 <akshayvyas> tflink so that admin means user user
17:31:35 <mclasen> kparal: just deleted a bunch - whats not working for you ?
17:31:36 <akshayvyas> ok got ya
17:31:36 <tflink> it means a non-root user with admin privelages
17:31:57 <kparal> sorry for being so fuzzy in the description
17:32:20 <tflink> I'm seeing one ack and one request for punt
17:32:21 <kparal> mclasen: could you try the reproducer from the description?
17:32:23 <tflink> any others?
17:33:05 <kparal> postpone and bother some devels to look at it
17:33:12 <akshayvyas> ack
17:33:26 <tflink> ha, now we're +2 punt and +2 ack
17:33:38 <red_alert> I'll also try to reproduce it either tomorrow or on Monday
17:33:55 <akshayvyas> red_alert: +1
17:33:56 <cpuobsessed> besides, just because it's rejected as a blocker doesn't make the bug go away, it still there and will get fixed
17:34:14 <kparal> cpuobsessed: yes, but it goes off the blocker list
17:34:53 <cpuobsessed> kparal: will it really lose that much visibility?
17:34:56 <red_alert> I think if the bug is rather common, we need to make sure it's fixed in either the release or in the zero day updates, therefore we'd need it on the blocker list
17:34:57 <tflink> proposed #agreed - 814690 - At the moment, this appears to be too much of a corner case to be a blocker but we want to give a bit more time for new reports and triage before making a final decision on blocker status
17:35:04 <adamw> ack
17:35:08 <red_alert> ack\
17:35:14 <kparal> ack
17:35:19 <tflink> #agreed - 814690 - At the moment, this appears to be too much of a corner case to be a blocker but we want to give a bit more time for new reports and triage before making a final decision on blocker status
17:35:26 <akshayvyas> ack
17:35:27 <cpuobsessed> ack
17:35:36 <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)
17:35:39 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=799667
17:35:42 <tflink> #info Proposed Blocker, NEW
17:36:10 <tflink> well, we have another report now
17:36:20 <tflink> and waiting on upstream to take the proposed fix
17:37:16 <tflink> I'm probably -.5 blocker on this
17:37:36 <cpuobsessed> sounds like it "could" be fixed at least zero day
17:37:45 <tflink> it's already NTH but I'm not sure that this is bad/common enough to be a blocker
17:38:02 <red_alert> that really only affects people with a wacom tablet?
17:38:06 <cpuobsessed> NTH sounds about right
17:38:17 <akshayvyas> red_alert: +1
17:39:11 <tflink> any other votes/thoughts on blockery-ness?
17:39:20 <mclasen> kparal: looks like a deja-dup bug - it leaves a process behind running as that user - that causes userdel to choke
17:39:23 <adamw> yeah, it only affects people with certain wacom tablets, but the effect is pretty bad: utter failure to load the desktop.
17:39:53 <kparal> mclasen: can it also cause the reboot 'please provide password' problems?
17:39:53 <cpuobsessed> only if it's plugged in at boot
17:40:09 <akshayvyas> cpuobsessed: right
17:40:28 <adamw> true
17:40:28 <tflink> cpuobsessed: true, but the cause of the login failure is pretty non-obvious
17:40:31 <adamw> yeah
17:40:37 <mclasen> kparal: don't think so, no
17:40:37 <adamw> i'm probably +0.1 blocker =)
17:40:45 <adamw> if everyone else is leaning not a blocker, i don't mind.
17:40:55 <cpuobsessed> not quite corner case, but most of the users with one will be using the design suite
17:41:09 <tflink> I forgot about the "can't login if the tablet is plugged @ boot" part
17:41:10 <red_alert> if it only breaks GDM/login but plugging in the tablet after logging in, I'm -1 blocker
17:41:27 <cpuobsessed> i'm thinking NTH
17:41:27 <akshayvyas> tflink: yeah we took that in last meeting
17:42:01 <cpuobsessed> it would be nice to fix but the workaround is easy enough
17:42:26 * tflink wonders how many people use tablets w/ livecds
17:42:38 <tflink> we were going to attempt to figure that out, weren't we?
17:42:44 * cpuobsessed enough to file a bug
17:42:57 <adamw> tflink: if you've got a tablet i don't see why you'd unplug it in order to install fedora.
17:43:13 <adamw> afaik people with tablets pretty much just leave them connected. unless it's a laptop, of course.
17:43:39 <tflink> adamw: I agree but I think I'm missing the point. I was wondering how many people using livecds (can't update) would hit this
17:44:39 <kparal> livecd is the default installation medium, right?
17:44:54 <cpuobsessed> kparal: not in my house
17:45:11 <kparal> well it seems quite hard to find dvd on fp.org website
17:45:17 <adamw> tflink: as kparal said. i'm thinking of people with tablets who go 'oh, i'll just download f17 and install it'.
17:45:27 <akshayvyas> i use it just ft alpha and beta final install with dvd
17:46:42 <cpuobsessed> the default link is for gnome live cd
17:46:42 <red_alert> the workaround is really easy to perform, though...most of the times we don't let a bug block the release it's because of workarounds that are much harder to apply, really
17:46:58 <tflink> assuming you had any idea what was going on, sure it's easy
17:47:21 <red_alert> sure, that's always the problem with common bugs/workarounds
17:47:53 <tflink> huh, I think my query is off but I'm only seeing 1 install with a wacom tablet for F16 and none for F15
17:47:54 <cpuobsessed> nobody read the common bugs until something doesn't work OOTB
17:48:00 <adamw> red_alert: yeah, it's the thing that makes me very slightly + - there's no obvious leap from 'fedora doesn't boot' to 'i should unplug my tablet'. but like i said it's a very weak preference.
17:48:14 <mclasen> kparal: http://bazaar.launchpad.net/~deja-dup-hackers/deja-dup/24/view/head:/monitor/README indicates that it is intentional on the part of the upstream maintainer...
17:49:25 <red_alert> so, are we going to sit here until a fix turns up or is there some voting? ;)
17:50:07 <tflink> sorry, trying to dig into how many tablets have been seen @ install time
17:50:25 <tflink> it sounds like most of us are slightly +
17:50:53 <akshayvyas> tflink: how much
17:51:27 <red_alert> the number of tablets and the number of affected tablets are different, too
17:51:51 <tflink> red_alert: different from what?
17:51:53 <cpuobsessed> -1 blocker
17:52:23 <cpuobsessed> a specific type of wacom tablet is affected
17:52:41 <red_alert> tflink: "all tablets" vs "all affected tablets"
17:52:56 <tflink> well, I'm seeing 2437 installs with something wacom related for F14
17:53:20 <adamw> cpuobsessed_afk: it's one of the more popular sets of wacoms. but yeah, it's still pretty narrow.
17:53:52 <tflink> but almost nothing for F15 and F16 which is wrong - lots of laptops have devices that identify as "wacom"
17:54:11 <akshayvyas> -1 bocker
17:54:14 <tflink> it sounds like we're more strongly -1 blocker
17:54:18 <akshayvyas> -1 blocker
17:55:06 <tflink> proposed #agreed - 799667 - RejectedBlocker - While this is ugly and the cause is not immediately obvious, it was deemed too much of a corner case to take as a blocker for F17 final
17:55:17 <adamw> sure.
17:55:20 <red_alert> ack
17:55:25 <akshayvyas> yep
17:56:15 <cpuobsessed_afk> ack
17:56:18 <tflink> #agreed - 799667 - RejectedBlocker - While this is ugly and the cause is not immediately obvious, it was deemed too much of a corner case to take as a blocker for F17 final
17:56:21 <tflink> #topic (815243) reset of gnome-shell starts NewtorkManager.service
17:56:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815243
17:56:26 <tflink> #info Proposed Blocker, NEW
17:57:18 <tflink> I'm probably still -1 blocker on this unless there is an affected spin that I'm not thinking of
17:57:34 <tflink> s/probably//
17:58:30 <adamw> yeah, -1 blocker, esp since we now have NM in minimal installs. it's obviously _wrong_, but i see no basis for blocker status.
17:58:48 <kparal> -1 blocker
17:59:19 <akshayvyas> -1 blocker
18:00:10 <tflink> proposed #agreed - 815243 - RejectedBlocker - This won't affect any of the livecds and could be fixed with an update.
18:00:14 <adamw> ack
18:00:21 <adamw> also, doesn't hit any criteria, really.
18:00:44 <cpuobsessed_afk> ack
18:00:53 <kparal> ack
18:01:24 <tflink> #agreed - 815243 - RejectedBlocker - This doesn't hit any of the release criteria, won't affect any of the livecds and could be fixed with an update.
18:01:44 <tflink> #topic (809111) grub2-probe fails during install
18:01:45 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809111
18:01:45 <tflink> #info Proposed Blocker, NEW
18:02:15 <tflink> I used the wrong criterion when proposing this
18:02:33 <tflink> it should be "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:03:10 <tflink> it would be nice to have input from the anaconda or grub devs, though
18:04:34 <tflink> unless there is some reason that this partition layout is invalid, I'm +1 blocker
18:04:50 <adamw> +1, particularly since it was reproduced with no /boot-on-RAID involved
18:05:34 <tflink> there's that, too
18:05:58 <akshayvyas> im not sure but i think its because of disk layout
18:06:08 <tflink> proposed #agreed - 809111 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:06:32 <pjones> it'd be nice to see if he still sees it running a newer build of grub2
18:06:37 <pjones> since there have been several since then
18:06:48 <adamw> ack
18:06:50 <adamw> we can ask that in the bug
18:07:01 <red_alert> tflink: ack
18:07:36 <pjones> I'm not really convinced this is a blocker, since it seems to work for everybody else - it seems likely to be specific to something going on on his machine
18:07:51 <adamw> mads seems to think grub2 rc4 might fix it
18:07:52 <pjones> but more data would certainly be welcome :)
18:07:54 <akshayvyas> pjones: +1
18:08:08 <adamw> pjones: well, there appear to be at least two reporters.
18:08:24 <adamw> pjones: unless sam's bug is different from fridjtof's, and he stole the report.
18:08:56 <pjones> yeah, hard to say
18:09:10 <akshayvyas> i am +1 blocker
18:09:30 <pjones> #c23 may also be an interesting point; I guess I'll look into fixing that (though I don't know why it'd make much difference here)
18:10:00 * tflink assumes that akshayvyas meant ack
18:10:13 <tflink> #agreed - 809111 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
18:10:22 <akshayvyas> yep tflink
18:10:37 <tflink> topic (804363) kmix crashes when pulseaudio exits
18:10:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804363
18:10:37 <tflink> #info Proposed Blocker, VERIFIED
18:10:57 <tflink> I'm -1 blocker, -1 NTH on this
18:11:15 <tflink> PA shouldn't be crashing enough for this to be a blocker
18:11:25 <tflink> but the report of PA issues is something different
18:12:16 <kparal> tflink: topic was not updated
18:12:55 <tflink> #undo
18:12:55 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1f5e94d0>
18:12:57 <tflink> #undo
18:12:57 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x1f5e9310>
18:13:03 <adamw> why is it reopened?
18:13:05 <tflink> #topic (804363) kmix crashes when pulseaudio exits
18:13:05 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804363
18:13:05 <tflink> #info Proposed Blocker, VERIFIED
18:13:09 <adamw> or, not closed?
18:13:12 <tflink> kparal: thanks
18:13:22 <tflink> good question
18:13:28 <kparal> do we need to vote when it's already verified and pushed to stable?
18:13:35 <tflink> both builds have been pushed to stable
18:14:13 <kparal> seems that Bodhi didn't update BZ
18:14:14 <tflink> c#23 seems to address my question about worthyness, though
18:14:49 <adamw> if the update is pushed, i think we just close the bug and move on...
18:14:58 <akshayvyas> i don't think we need to vote as both builts are pushed
18:15:02 <tflink> works for me
18:15:34 <tflink> proposed #agreed - 804363 - The affected builds have already been pushed to stable and the fix has been verified - no need for blocker status and will close the bug
18:15:46 <cpuobsessed> what's the link for blocker criteria?
18:15:56 <cpuobsessed> ack
18:16:14 <tflink> cpuobsessed: http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria
18:16:27 <cpuobsessed> 10Q
18:16:59 <adamw> ack
18:17:22 <tflink> #agreed - 804363 - The affected builds have already been pushed to stable and the fix has been verified - no need for blocker status and will close the bug
18:17:33 <tflink> #topic (817298) ipw2x00: backport patch for nl80211 cipher suite reporting
18:17:36 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=817298
18:17:39 <tflink> #info Proposed Blocker, ON_QA
18:18:29 <adamw> with the numbers, i'd be -1, i guess
18:18:35 <adamw> +1 nth
18:18:59 <kparal> summary: ipw2200 wifi devices were not able to connect to encrypted networks using fallback mode
18:19:08 <tflink> assuming that I didn't botch the query, anyways :)
18:19:29 * tflink is still resisting the temptation to do more data mining :)
18:19:39 <kparal> the kernel might not make it into stable before freeze, right?
18:19:49 <tflink> definitely +1 nth
18:20:16 <adamw> kparal: pretty unlikely not to make it.
18:20:30 <akshayvyas> comment 10 i think its fixed
18:20:45 <kparal> it is fixed
18:20:45 <tflink> if it only affects gnome fallback, I'm thinking -1 blocker
18:21:06 <akshayvyas> tflink: i will g with you
18:21:49 <kparal> I would rather see it in there. but no hard feelings
18:21:56 <akshayvyas> -1 blocker
18:22:03 <cpuobsessed> -1
18:22:11 <tflink> proposed #agreed - 817298 - RejectedBlocker, AcceptedNTH - This only affects a minority of hardware and only in fallback mode - deemed not common enough to justify blocker status but accepted as NTH.
18:22:19 <adamw> kparal: er, i mean, we'll almost certainly get it in. we usually wind up pulling kernel at some point.
18:22:28 <kparal> sounds good then
18:22:53 <kparal> ack
18:23:52 <adamw> ack
18:24:02 <tflink> #agreed - 817298 - RejectedBlocker, AcceptedNTH - This only affects a minority of hardware and only in fallback mode - deemed not common enough to justify blocker status but accepted as NTH.
18:24:13 <tflink> #topic (816495) Network time can't be enabled
18:24:13 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816495
18:24:13 <tflink> #info Proposed Blocker, ON_QA
18:24:23 <tflink> has anyone gotten this to work succcessfully?
18:24:40 <tflink> I was in the middle of trying it when the meeting started but it doesn't seem to be working for me
18:24:43 <akshayvyas> yep
18:25:10 <kparal> tflink: I confirmed the fix with chrony
18:25:21 <kparal> I think we should link all those three bugs here at once
18:25:24 <akshayvyas> ntp is nt installed after installing ntp it worked
18:25:54 <tflink> I think that the systemd one is already closed
18:26:03 <kparal> yes
18:26:05 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=815748
18:26:13 <tflink> #chair kparal
18:26:13 <zodbot> Current chairs: adamw kparal tflink
18:26:13 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=816493
18:26:21 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=816495
18:26:32 <kparal> these three are just copies
18:26:38 <kparal> systemd fixed, chrony fixed
18:26:43 <kparal> I didn't try ntp
18:26:50 <akshayvyas> i tried ntp
18:26:54 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=815748
18:26:54 <kparal> but I think it should be a blocker, because it's not installed by default
18:27:00 <kparal> chrony is, and that works
18:27:08 <akshayvyas> its in update testing
18:27:11 <kparal> the blocker tag was just copied from the master bug
18:27:11 <tflink> kparal: that's a different bug, though - isn't it?
18:27:33 <tflink> should or should not?
18:27:39 <kparal> shouldn't
18:27:40 <kparal> sorry
18:27:42 <cpuobsessed> if you do an upgrade from F16 does it switch to chrony or stay with ntp?
18:27:51 <kparal> cpuobsessed: good question
18:27:54 <adamw> you don't get firstboot on an upgrade.
18:28:01 <akshayvyas> cpuobsessed : nt sure
18:28:06 <adamw> is the bug here really simply firstboot? or is there more to it? i'm confused.
18:28:12 <kparal> adamw: but it was related to gnome system date config
18:28:14 <kparal> not firstboot
18:28:25 <akshayvyas> adamw: its just live cd i think
18:28:26 <adamw> ohh, right. sorry.
18:29:02 <cpuobsessed> either way the fix was pushed to testing
18:29:13 <akshayvyas> comment3
18:29:14 <kparal> systemd changed some workflow. now if you enable network time in gnome control panel, it should enable either chrony or ntp service, depending what you have installed
18:29:25 <tflink> kparal: did you test the fix w/ live install or DVD/netinst install?
18:29:28 <adamw> i'm not sure it's bad enough to be a blocker, though.
18:29:29 <kparal> rather start service than enable service, it uses some weird dependencies
18:29:48 <adamw> not having network time during a live boot is...meh...and for all other cases, it's eminently update-fixable.
18:29:57 <kparal> tflink: I tested on an already installed system, not a clean installation
18:29:58 <akshayvyas> kparal: what kind of deps
18:30:12 <kparal> systemd unit files dependencies
18:30:18 <tflink> adamw: my concern would be enabling ntp on a fresh install
18:30:23 <kparal> the service will not get enabled, but it will get started
18:30:32 <tflink> like in firstboot
18:30:51 <akshayvyas> it will be enabled
18:31:35 <akshayvyas> it was working
18:32:14 <kparal> tflink: I don't follow, fresh installs don't have ntp AFAIK. at least live ones
18:32:30 <kparal> we can re-test that of course
18:32:35 <akshayvyas> its fixed https://admin.fedoraproject.org/updates/FEDORA-2012-6798/ntp-4.2.6p5-2.fc17
18:32:51 <tflink> that brings up the question of why we ask about starting ntp in firstboot
18:32:56 <adamw> well...afai understand, i'm -1.
18:33:00 <kparal> akshayvyas: no one confirmed that
18:33:20 <kparal> tflink: so who asked that first?
18:33:52 <tflink> kparal: about why we do that when ntp isn't installed by default? It's not 100% related
18:34:44 <kparal> I don't really see a blocker here, clean installations work fine, network time can be enabled now. if anything else is broken (like upgrades), it can be fixed afterwards.
18:34:53 <kparal> at least we don't have any criteria like that for upgrades
18:35:37 <cpuobsessed> -1 blocker
18:35:41 <tflink> proposed #agreed - 816495 - RejectedBlocker - This doesn't clearly hit any of the release criteria and could be fixed with an update.
18:35:48 <adamw> ack
18:35:50 <kparal> ack
18:35:56 <cpuobsessed> ack
18:35:58 <tflink> #agreed - 816495 - RejectedBlocker - This doesn't clearly hit any of the release criteria and could be fixed with an update.
18:35:59 <akshayvyas> ack
18:36:08 <tflink> #topic (815413) Preugprade from F16 to F17 Beta does not regenerate pam.d/system-auth*, causing systemd-loginctl not to know about user sessions, breaking PulseAudio
18:36:11 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=815413
18:36:14 <tflink> #info Proposed Blocker, NEW
18:38:02 <tflink> I'm still +1 blocker on this but it needs more testing
18:38:39 <adamw> sound broken after preupgrade sounds blockerish, but i'm not familiar with the bug.
18:39:37 <cpuobsessed> anyone reproduce with Final-TC2?
18:40:01 <cpuobsessed> or rather latest builds or whatnot?
18:40:08 <akshayvyas> +1 blocker
18:40:54 <cpuobsessed> +1 blocker
18:40:59 <red_alert> pam_systemd missing from system-auth sounds like there will be more issues coming up, too
18:41:02 <red_alert> +1 blocker
18:41:27 <tflink> proposed #agreed - 815413 - AcceptedBlocker - Violates the F17 beta 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" however, this needs re-testing with newer builds an
18:42:09 <adamw> ackish
18:42:12 <adamw> split it into two
18:42:51 <tflink> proposed #agreed - 815413 - AcceptedBlocker - Violates the F17 beta 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"
18:43:16 <tflink> #info this needs to be re-tested with final TC2 or newer and with DVD upgrade
18:43:50 <adamw> ack
18:44:11 <cpuobsessed> ack
18:44:17 <akshayvyas> ack
18:44:25 <tflink> #agreed - 815413 - AcceptedBlocker - Violates the F17 beta 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"
18:45:14 <tflink> as we're getting close to the 2 hour mark - start thinking about whether we'd rather keep going until everything is finished or if we want to stop soon and re-conviene tomorrow
18:45:35 <tflink> there are 5 proposed blockers, 10 proposed NTH and 12 accepted blockers left
18:45:53 <tflink> #topic (813973) Preupgrade fails to build proper squashfs.img URL on boot with small boot partitions
18:45:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=813973
18:45:59 <tflink> #info Proposed Blocker, NEW
18:45:59 <cpuobsessed> go for the TD :P
18:46:17 <adamw> finish proposed blockers.
18:46:33 <tflink> is this even a bug?
18:46:58 <adamw> well, preupgrade failed, but...it all seems a bit confused.
18:47:10 <adamw> i'm still not sure how exactly dave decided the problem is 'small boot partition'.
18:47:11 <tflink> it's a 192M /boot
18:48:10 <adamw> well sure, he has a small boot partition.
18:48:15 <adamw> but do we know that's the cause of the bug he hit?
18:48:26 <tflink> point
18:48:30 <tflink> that url is weird
18:48:42 <akshayvyas> i don't think so
18:49:34 <adamw> wwoods: bcl: pjones: any ideas?
18:49:38 <akshayvyas> tflink this link is still not found error 404
18:49:46 <tflink> from the description "The URL string appears to be
18:49:48 <tflink> getting appended to itself and it drops to a debug shell with dracut"
18:49:59 <bcl> err.
18:50:02 <tflink> akshayvyas: yeah, but it looks like the url was appended to itself
18:50:15 <akshayvyas> yep
18:51:48 <bcl> oh.
18:51:58 <bcl> that's not how you specify stage2
18:52:16 <bcl> It points to a repo with .treeinfo or to the directory above LiveOS/
18:52:31 <bcl> if .treeinfo fails it falls back to LiveOS/squashfs.img
18:52:46 <adamw> so, why is this happening to this guy but preupgrade hasn't hit this in other tests?
18:53:00 <wwoods> does preupgrade use stage2=?
18:53:07 <bcl> well, I find it odd that it is specifying a http for stage2. is that normal?
18:53:31 <wwoods> that's the not-enough-/boot case, IIRC
18:53:31 <adamw> I think i posted some preupgrade params in that big beta bug we had
18:53:37 <bcl> [    0.000000] Command line: BOOT_IMAGE=/upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=128129ea-bfbc-4c74-b287-db9764f5fc11:/upgrade/ks.cfg stage2=http://mirror01.th.ifl.net/fedora/linux/development/17/x86_64/os/LiveOS/squashfs.img
18:53:40 <wwoods> or some kind of workaround
18:53:51 <bcl> from the dmesg in the bug.
18:53:56 <tflink> is that one of the workarounds for small /boot?
18:54:17 <bcl> might want to ask the preupgade maintianer.
18:54:28 <adamw> https://bugzilla.redhat.com/attachment.cgi?id=575326
18:54:34 <adamw> that's from my boot test
18:54:38 <adamw> beta test
18:55:07 <adamw> it specified a path to a squashfs.img file as well, but nothing exploded...
18:55:22 <adamw> oh, maybe that fails non-explosively and it falls back on the repo= location and works?
18:55:27 <adamw> but the http case fails worse?
18:56:36 <akshayvyas> well this is confusing
18:56:50 <akshayvyas> what caused this problm
18:58:34 <akshayvyas> i think this is bec of /boot: 74.5MB
18:59:10 <adamw> so if i'm understanding things right, preupgrade has a workaround if it thinks /boot is too small to stick stage2 there; it just writes a grub config to get stage2 over the network instead
18:59:32 <tflink> that looks right, assuming that the stage2= wasn't added by hand
18:59:39 <adamw> and my theory is that specifying stage2=http://some/path/squashfs.img fails harder than specifying stage2=hd:somedisk:/path/to/squashfs.img
19:00:07 <adamw> neither would actually _work_, but if the latter fails in some way that doesn't entirely blow things up, anaconda will fall back on the _correct_ repo= location to get squashfs.img from, right?
19:00:17 <adamw> so in the end it'll be okay
19:00:37 <adamw> but in the http case, the failure causes anaconda to bail. oh, or the repo= location doesn't have squashfs.img, so it doesn't work as a fallback.
19:00:56 <adamw> either way, it'd explain why it fails in the case of small /boot, and why the error is what it is.
19:03:20 <adamw> but...i could easily be wrong in there somewhere.
19:03:25 * cpuobsessed attaches his star to adamw's wagon
19:03:51 <adamw> note: this wagon not rated for hauling of astronomical bodies
19:03:59 <bcl> adamw: yes, if it can't fit stage2 image then it falls back to network.
19:04:06 <cpuobsessed> so preupgrade works unless you feed it garbage?
19:04:11 <bcl> so that's autogenerated.
19:04:27 <adamw> cpuobsessed: it fails in the case of /boot being too small for stage2, a case we try to handle. i think.
19:04:45 * cpuobsessed looks up install docs
19:05:49 <tflink> this is starting to sound blocker-ish, though
19:06:26 <bcl> preupgrade can be changed post-release.
19:06:47 <tflink> true but that just makes it a non-spin-blocking release-blocker
19:06:49 <adamw> bcl: right, for now we're still following the blocker process for it though, as my proposal on the ml met a mixed response
19:06:53 <bcl> anaconda 17.25 will have a fix for using stage2= with a missing .treeinfo
19:06:57 <cpuobsessed> The partition mounted on /boot/ contains the operating system kernel (which allows your system to boot Fedora), along with files used during the bootstrap process. For most users, a 250 MB boot partition is sufficient.
19:07:07 <adamw> i guess it kinda depends how badly we care about small /boot. how long have we defaulted to 500MB now?
19:07:19 <tflink> since F14, I think
19:07:24 * cpuobsessed has a 2Gb /boot
19:07:35 <bcl> but as it stands you can't use stage2 to point right at the image. We may want to change that as well...
19:07:47 <akshayvyas> so the possible reason is /boot
19:08:00 <cpuobsessed> the reporter should clean his /boot and try again
19:08:31 <bcl> no, preupgrade should pass the right params and/or anaconda should accept more stage2 variations.
19:08:51 <akshayvyas> cpuobsessed: +1
19:10:02 <tflink> yeah, +1 on preupgrade not using the wrong options
19:10:54 <cpuobsessed> +1 blocker
19:10:56 <adamw> cpuobsessed: not really 'clean'
19:11:10 <adamw> cpuobsessed: if you have a 200MB /boot it's often gonna be too small even if you've done nothing unusual
19:12:20 <adamw> yeah, it's clear we have actual code bugs here. just blocker status is a bit questionable
19:12:41 <adamw> i'm not sure small /boot is a big enough case any more to block on
19:12:49 <tflink> +1 NTH (assuming a well tested fix)
19:13:01 <tflink> what do we tell people with small /boot?
19:14:14 <bcl> I'm -1 blocker. preupgrade needs to be changed.
19:15:03 <cpuobsessed> tflink: how do you define "small boot"
19:15:17 <adamw> bcl: i don't see how those two statements relate to each other
19:15:20 <tflink> < 200M definitely
19:15:33 <cpuobsessed> install docs say 250M
19:15:36 <adamw> bcl: for now we have to treat bugs in preupgrade as if they can be blockers
19:15:45 <akshayvyas> -1 blocker
19:15:45 <bcl> preupgrade bugs aren't blockers are they? It can be changed independent of the isos.
19:15:46 <adamw> cpuobsessed: what's in the docs isn't as important as what anaconda does by default
19:15:47 <cpuobsessed> or at least recommends about 250Mb for most users
19:16:03 <tflink> bcl: they don't block spins, they can block release
19:16:08 <adamw> bcl: right now, they still are. i proposed making them not, but the proposal doesn't have clear support yet.
19:16:15 <bcl> ah, ok.
19:16:22 <bcl> well, whatever. I'm -1
19:16:36 <tflink> it sounds like we're mostly -1
19:16:40 <akshayvyas> -1
19:16:44 <tflink> NTH?
19:17:01 <tflink> wait, NTH doesn't really make sense here - scratch that
19:17:36 <adamw> yeah, skip nth.
19:18:33 <cpuobsessed> well, to have a smaller then recommended (according to install docs) you have to do a custom layout
19:18:38 <tflink> proposed #agreed - 813973 - RejectedBlocker - While this is ugly and violates the upgrade release criterion, 500M /boot has been the default for a while and most users are unlikely to hit this. This is deemed too much of a corner case to take as a blocker for F17 final
19:18:38 <cpuobsessed> special setup
19:18:50 <cpuobsessed> ack
19:19:01 <adamw> ack
19:19:31 <akshayvyas> ack
19:19:42 <tflink> #agreed - 813973 - RejectedBlocker - While this is ugly and violates the upgrade release criterion, 500M /boot has been the default for a while and most users are unlikely to hit this. This is deemed too much of a corner case to take as a blocker for F17 final
19:19:57 <tflink> #topic (813548) pulseaudio occasionally terminates
19:19:57 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=813548
19:19:57 <tflink> #info Proposed Blocker, NEW
19:20:17 <kparal> read last comment from lennart
19:20:59 <kparal> probably -1 blocker. if no one else sees the same, it's probably just my hw...
19:21:22 <tflink> punt for a week to verify?
19:21:30 <kparal> can't hurt
19:21:39 <kparal> it will give me some time to get further logs
19:22:15 <cpuobsessed> if the maintainer is saying probably not a blocker
19:22:33 <tflink> proposed #agreed - 813548 - At the moment, this looks to be HW specific and not a blocker but will wait another week to allow for more time to gather logs and triage
19:22:36 <akshayvyas> -1 blocker
19:22:49 <tflink> cpuobsessed: assuming that it's HW specific - we don't know for certain that he's right yet
19:22:50 <cpuobsessed> but  i guess any maintainer would say that
19:23:05 <kparal> ack
19:24:45 <cpuobsessed> i've got the same audio chip and haven't seen any problems
19:25:07 <tflink> any more ack/nak/patch?
19:25:28 <akshayvyas> ack
19:25:43 <cpuobsessed> ack
19:25:45 <tflink> #agreed - 813548 - At the moment, this looks to be HW specific and not a blocker but will wait another week to allow for more time to gather logs and triage
19:25:53 <tflink> #topic (740280) /dev/live no longer exists
19:25:53 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=740280
19:25:54 <tflink> #info Proposed Blocker, NEW
19:26:48 <tflink> I'm still not clear on whether this is actually broken or not
19:27:18 <adamw> indication is that it's not, but we need to be sure
19:27:23 <adamw> satellit_: around?
19:27:30 <satellit_Tris55R> yes
19:27:55 <satellit_Tris55R> /dev/live is used by fgross on lives
19:29:03 <satellit_> http://wiki.sugarlabs.org/go/Sugar_Creation_Kit#Sugar_on_a_Stick.2FSugar_Clone
19:29:57 <adamw> satellit_: fgross?
19:30:09 <adamw> the key question here afaik is 'does live persistence work'
19:30:54 <satellit_> /dev/live was a link to the installation partition on the Live USB, suchas /dev/sdc1,or /dev/sr0 on a Live CD/DVD.
19:31:16 <satellit_> Frederick Grose
19:32:06 <satellit_> livecd Digest, Vol 84, Issue 21 #1
19:32:16 <adamw> yes, we know what it was. but we don't care about it not existing _per se_. the question is, is any key functionality broken.
19:32:21 * satellit_ I have not used this
19:33:00 <tflink> so, we still need testing to figure out busted-ness
19:33:02 <adamw> oh, and we didn't propose the criterion as we said we would. whoops.
19:33:15 <adamw> comment #23 and #26 indicate there may be problems, i think
19:33:23 <adamw> reads like maybe /home persistence without an overlay won't work?
19:33:23 <satellit_> live persistence does work with l-i-t-d and usb-creator
19:34:07 <adamw> and getting persistence for /home via the overlay is non-optimal anyway, the point of the separate /home persistence is not to have the problem of exhaustion
19:34:29 <satellit_> I like liveinst to USB
19:35:14 * satellit_ I am not the one to answer this...sorry
19:35:27 <tflink> I thought you needed the overlay for persistent /home to work
19:36:12 <adamw> well from the docs i was editing earlier today...
19:36:37 <adamw> "For a truly persistent write-many (vs write-once) overlay, use the --home-size-mb option to create a home directory filesystem image for personal files. Unlike the primary system overlay image, the home.img can be re-used and loop mounted outside of the liveusb environment."
19:36:57 <adamw> maybe it can't be done without the overlay, but even then, it sounds like it may not be working as designed without /dev/live...
19:38:53 <satellit_Tris55R> tools_livecd-iso-to-disk.sh --reset-mbr --overlay-size-mb 500 --home-size-mb 700 --delete-home --unencrypted-home Fedora-17-Alpha-RC4-i686-Live-Desktop.iso /dev/sd(x)1
19:39:00 <akshayvyas> i think it needs more testing
19:39:02 <satellit_Tris55R> works for persistence
19:39:47 * satellit_Tris55R fgross recomended form
19:39:50 <adamw> i'm okay with more testing. and getting the fix in so we don't have to argue about it any more
19:39:57 <satellit_Tris55R> ok
19:40:14 <tflink> yeah, this is starting to sound like a corner case anyways
19:40:40 <akshayvyas> adamw: +1
19:40:50 <bcl> I *think* /dev/live is back in recent dracut. Booting a TC2 live to check.
19:41:19 <tflink> proposed #agreed - 740280 - This still needs more testing to figure out exactly what was broken and whether it is still broken. Will revisit and propose release criterion around persistent /home on liveusb
19:41:26 <tflink> eh
19:41:28 <adamw> ack
19:41:38 <akshayvyas> ack
19:41:40 <tflink> proposed #agreed - 740280 - This still needs more testing to figure out exactly what was broken and whether it is still broken. Will revisit after the testing has been done
19:41:59 <tflink> any volunteers to propose a release criterion for liveusb persistence?
19:42:37 <adamw> eh, throw it at me?
19:42:54 * satellit_ glad to test....
19:43:03 <tflink> #action adamw to propose new release criterion for persistent home on liveusb
19:43:20 <tflink> #agreed - 740280 - This still needs more testing to figure out exactly what was broken and whether it is still broken. Will revisit after the testing has been done
19:43:26 <tflink> only 2 more left ...
19:43:33 <tflink> #topic (817083) Language is not set with this tool
19:43:34 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=817083
19:43:34 <tflink> #info Proposed Blocker, ASSIGNED
19:44:46 <tflink> this is a not-quite-correct dialog message, right?
19:45:18 <tflink> unless there's something that I'm missing, I'm -1 blocker
19:45:24 <adamw> yeah, -1 blocker here.
19:45:36 <adamw> let's not get into discussing what s-c-l should do and what gnome should do and blah, this clearly ain't a blocker.
19:46:02 <akshayvyas> yeah -1 blocker
19:46:16 <tflink> proposed #agreed - 817083 - RejectedBlocker - This is much less severe than originally thought and after clarification, does not violate any of the release criteria and thus is rejected as a blocker for F17 final
19:46:24 <cpuobsessed> as far as languages go isn't that set at install time? as long as it installs the correct language?
19:46:39 <cpuobsessed> ack
19:46:47 <akshayvyas> ack
19:47:01 <tflink> cpuobsessed: not with live install, IIRC
19:47:35 * cpuobsessed needs more time with live images
19:47:59 <tflink> #agreed - 817083 - RejectedBlocker - This is much less severe than originally thought and after clarification, does not violate any of the release criteria and thus is rejected as a blocker for F17 final
19:48:07 <tflink> #topic (816842) reboot hangs with systemd-44-7.fc17
19:48:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=816842
19:48:08 <tflink> #info Proposed Blocker, ON_QA
19:48:27 <adamw> oh dear.
19:49:20 <akshayvyas> its fixed
19:49:32 <akshayvyas> comment 24
19:50:29 <adamw> oh yay.
19:50:34 <adamw> anyone confirm?
19:51:13 <tflink> no, it sounds like they're blaming a NM update for this having gotten worse
19:52:06 <tflink> so this bug might be fixed but there's another one now?
19:52:17 <adamw> well, 44-8 comes after the NM update...
19:52:45 * cpuobsessed is checking what version of systemd and NM he has
19:54:08 <cpuobsessed> Name        : systemd
19:54:10 <cpuobsessed> Arch        : x86_64
19:54:12 <cpuobsessed> Version     : 44
19:54:14 <adamw> don't paste the whole thing...
19:54:14 <cpuobsessed> Release     : 8.fc17
19:54:25 <cpuobsessed> no problems here
19:54:31 <cpuobsessed> 44-8.fc17?
19:54:47 <adamw> yeah, that's 44-8.
19:54:54 <adamw> i'm not on an f17 system atm, anyone else able to test?
19:55:37 <cpuobsessed> NetworkManager-0.9.4.0-8.git20120502.fc17
19:55:54 <cpuobsessed> shall i reboot?
19:56:14 <tflink> I have a F17 box here, will try
19:56:58 <cpuobsessed> i've got a ~40 sec boot time
19:57:01 <cpuobsessed> race
19:57:13 <tflink> it's taking a while to shutdown
19:57:43 <adamw> tflink: the systemd update notes a separate NM bug...
19:58:42 <tflink> how do you disable NM?
19:58:58 <tflink> just 'systemctl disable' before reboot?
20:00:15 <adamw> yeah
20:00:17 <adamw> or downgrade it i guess
20:01:21 <tflink> hrm, killing it didn't work
20:01:41 <cpuobsessed> ..and i'm back
20:01:57 <cpuobsessed> ~41 second boot that time
20:02:08 <adamw> tflink: you have the systemd update, right?
20:02:24 <cpuobsessed> 44-8 something
20:02:41 <tflink> i'm 90% sure that I do but I'm going to check as soon as this box comes back up
20:04:05 <tflink> no, I don't - I thought it was in updates-testing
20:04:20 <cpuobsessed> i thought i had it updated
20:04:51 <cpuobsessed> still on 44-7
20:05:01 <adamw> tflink: so, trry 44-8 and see if it's fixed...
20:05:54 <akshayvyas> adamw: +1 it's good to try ryt now
20:06:24 <cpuobsessed> it won't let me
20:06:33 <cpuobsessed> sudo yum update systemd
20:06:45 <cpuobsessed> no packages marked for update
20:07:29 <tflink> yeah, that seems to be making it worse
20:07:49 <adamw> so it didn't make it to the repo yet. get it from koji...
20:07:52 <adamw> tflink: 44-8 makes it worse?
20:08:01 <tflink> yep, even after killing NM
20:08:33 <tflink> i'll try rebooting again, maybe itll help to use the new systemd for loading
20:09:25 <akshayvyas> cpuobsessed: enablerepo update testing
20:09:45 <cpuobsessed> akshayvyas: it is enabled
20:10:05 <tflink> it's probably not in your mirror yet, then
20:10:19 <tflink> that seems to have done it
20:10:44 <cpuobsessed> Error: Protected multilib versions: systemd-44-7.fc17.i686 != systemd-44-8.fc17.x86_64
20:10:57 <cpuobsessed> did i download the wrong one?
20:10:58 <adamw> so you need to get the i686 version too.
20:11:01 <adamw> you have both.
20:11:07 <adamw> tflink: so you have decent reboots now?
20:11:09 <akshayvyas> yep cpuobsessed arch is diff
20:11:18 <tflink> yeah, it's fine after the first reboot
20:11:38 <akshayvyas> that means its fixed
20:11:43 <tflink> but this is with me killing NM before rebooting, though
20:11:58 <adamw> what happens if you enable NM? just for grins.
20:12:21 <cpuobsessed> i downloaded the right one
20:12:23 <tflink> yeah, I was about to try that
20:12:46 <adamw> cpuobsessed: you have *both* systemd packages installed.
20:12:58 <adamw> the NM update has already been downvoted into oblivion, fwiw.
20:13:01 <tflink> no problems with NM on
20:13:21 <adamw> so, looking good that this is fixed
20:13:31 <adamw> which is good info...
20:13:47 <adamw> as far as blocker status goes...if it was affecting _all_ shutdowns, then +1. i think for a while it only affected console-triggered ones?
20:14:24 <tflink> I thought that console triggered ones were the only way to avoid them
20:14:31 <tflink> the slow reboots, I mean
20:15:07 <adamw> oh. well, in that case, probably +1.
20:15:44 <tflink> at least that's how I'm reading it: telinit3 & reboot was a workaround
20:15:54 <tflink> sure, +1
20:16:27 <tflink> any suggestions for a criterion to use?
20:16:36 <adamw> the one cited in the report
20:16:42 <adamw> it says default shutdown methods should work
20:16:47 <adamw> arguably, taking 2 minutes to fire isn't 'working'
20:17:09 <tflink> mine wasn't quite that long but WFM
20:17:56 <tflink> proposed #agreed - 816842 - AcceptedBlocker - Violates the F17 beta release criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
20:18:27 <adamw> ack
20:19:15 <akshayvyas> ack
20:19:21 <tflink> #agreed - 816842 - AcceptedBlocker - Violates the F17 beta release criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
20:19:28 <tflink> ok, that's all of the proposed blockers
20:19:54 <tflink> I propose that we call it quits for the day and meet again tomorro to address any new blockers and go through the NTH and accepted blockers
20:20:35 <adamw> agreed!
20:20:43 <tflink> #topic open floor
20:20:46 <akshayvyas> agree :)
20:21:03 <tflink> Anything else that someone feels needs to be brought up?
20:22:06 <akshayvyas> yep a fc 16 bug
20:22:39 * tflink sets the fuse for [0,5] minutes
20:22:47 <akshayvyas> https://bugzilla.redhat.com/show_bug.cgi?id=766314
20:23:09 * tflink can't tell if you're being serious or not
20:23:40 <akshayvyas> im not sure but i think this bug is in f17 too
20:24:08 <adamw> transferring things via bluetooth isn't anywhere near release critical.
20:24:35 <tflink> so that's what it was doing
20:24:36 <akshayvyas> yep i think you are right adamw
20:24:39 * tflink wasn't sure
20:24:50 <tflink> fuse is still going
20:25:06 <adamw> tflink: obex anything is bluetooth.
20:25:21 <tflink> #info F17 final blocker review meeting #4 will be 2012-05-04 @ 17:00 UTC
20:25:39 <tflink> adamw: google was giving me vague answers
20:26:10 <tflink> Thanks for helping out everyone!
20:26:12 <akshayvyas> im nt sure but it worked for me after setenforce 0
20:26:25 <tflink> We'll get through this list tomorrow!
20:26:38 <cpuobsessed> i can't get systemd to update
20:26:39 <akshayvyas> tflink: im kay with that :)
20:26:51 <cpuobsessed> moving over to #fedora-qa
20:26:58 * tflink wonders if we're setting some sort of record for the number of blocker review meetings in 1 week
20:27:12 * tflink will send out minutes shortly
20:27:14 <tflink> #endmeeting