17:00:19 <tflink> #startmeeting f18beta-blocker-review-8
17:00:19 <zodbot> Meeting started Wed Nov 14 17:00:19 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:19 <tflink> #meetingname f18beta-blocker-review-8
17:00:19 <zodbot> The meeting name has been set to 'f18beta-blocker-review-8'
17:00:23 <tflink> #topic Roll Call
17:00:31 <tflink> Who's ready for some blocker review fun time?
17:00:39 * jreznik is here, fun, fun
17:00:46 * nirik is lurking around.
17:01:10 * kparal here
17:02:39 * kparal inviting some people from #anaconda
17:03:36 <tflink> why is it that people start bugging me as soon as the meeting starts
17:04:23 <kparal> murphy's laws
17:04:59 <jreznik> tflink: sorry :D
17:05:13 <tflink> jreznik: it's not just you
17:05:18 <zodbot> Ticket notification - f18betablocker: [Bug 875474] Regression: no graphical display after plymouth update <https://bugzilla.redhat.com/show_bug.cgi?id=875474>
17:06:56 <tflink> any volunteers for secretary?
17:07:06 <tflink> adam is out for the day
17:07:12 * Martix pokes kparal
17:07:35 <kparal> I will
17:07:42 * kparal kicks Martix
17:07:42 <jreznik> good to hear adam is out at least sometimes!
17:07:43 <tflink> kparal: thanks
17:08:07 <Martix> .fires kparal
17:08:12 <akshayvyas> adam is feeling older now a days :)
17:08:23 <Martix> kparal: this is how it works ^
17:08:34 <tflink> Martix: you're just dead set on disrupting the meeting, aren't you :-P
17:08:51 <Martix> tflink: sorry :-P
17:08:56 <tflink> anywho, let's get this party started with some boilerplate
17:09:08 <tflink> party hats firmly in place? Good.
17:09:14 <tflink> #topic Introduction
17:09:20 <tflink> Why are we here?
17:09:20 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:09:29 <tflink> #info We'll be following the process outlined at:
17:09:30 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:09:37 <tflink> #info The bugs up for review today are available at:
17:09:37 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:09:42 <tflink> #info The criteria for release blocking bugs can be found at:
17:09:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:09:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:09:43 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:10:29 <tflink> up for  review today, we have:
17:10:32 <tflink> #info 6 Proposed Blockers
17:10:32 <tflink> #info 7 Accepted Blockers
17:10:33 <tflink> #info 6 Proposed NTH
17:10:33 <tflink> #info 15 Accepted NTH
17:11:00 <tflink> any objections to starting with the proposed blockers? (not that there ever are)
17:11:12 <akshayvyas> nope
17:11:17 <tflink> #topic (875393) TypeError: _refresh_device_cfg() takes exactly 3 arguments (2 given)
17:11:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875393
17:11:23 <tflink> #info Proposed Blocker, anaconda, VERIFIED
17:11:47 <kparal> it's verified but we still need to vote on it, because it's not stable
17:12:20 <kparal> see comment 28 for tldr summary
17:13:02 <tflink> we already have +1 from the comments
17:13:21 <akshayvyas> yep +1
17:13:27 <kparal> I'm also +1 blocker
17:13:35 * spstarr grins at that bug
17:14:02 <tflink> spstarr: that's dangerous, you don't know if it'll turn around and bite you :-D
17:14:10 <nirik> +1 blocker
17:14:13 <jreznik> +1 blocker
17:14:21 <spstarr> it seems fixed in 20121112_f18b-smoke18/
17:14:23 <kparal> I would use following criterion: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures..."
17:14:57 <tflink> proposed #agreed 875393 - AcceptedBlocker - Violates the following F18 alpha release criterion for machines without a working network connection at boot time: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures ..."
17:15:01 <kparal> or just don't use any particular one, just free-text explanation
17:15:10 <kparal> ack
17:15:11 <akshayvyas> ack
17:15:20 <spstarr> 875393 appears fixed in 20121112_f18b-smoke18
17:15:20 <tflink> we don't generally accept blockers w/o criteria violation
17:15:44 <spstarr> at least my use case now shows the network config dialog screen vs crash
17:15:45 <kparal> spstarr: yes it is
17:15:46 <tflink> spstarr: yep, it's VERIFIED just not stable yet - hence the blocker voting
17:15:50 <spstarr> ok
17:16:02 <tflink> any other ack/nak/patch?
17:16:08 <jreznik> ack (can't imagine better text)
17:16:19 <tflink> #agreed 875393 - AcceptedBlocker - Violates the following F18 alpha release criterion for machines without a working network connection at boot time: "The installer must boot and run on all primary architectures, with all system firmware types that are common on those architectures ..."
17:16:28 <tflink> #topic (876180) KeyError: None
17:16:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876180
17:16:28 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
17:16:50 <tflink> I love the descriptive titles we've been getting for libreport anaconda bugs in F18
17:17:03 <tflink> because KeyErrors are so hard to hit in python ...
17:17:37 <tflink> we have -1 from the bug comments
17:17:45 * nirik is also -1 blocker, +1 NTH
17:17:54 <Martix> +1 blocker
17:18:03 <tflink> Martix: criterion?
17:18:16 <tflink> assuming that I understand the bug, I'm also -1/+1
17:18:22 <Martix> tflink: installer should not crash?
17:18:44 <kparal> Martix: so what exactly do you need to do? is that custom partitioning only?
17:18:52 <tflink> Martix: sure, but this is beta - we can't block on every single potential installer crash
17:19:14 <jreznik> seems like not very common use case, -1/+1
17:19:14 <Martix> kparal: I need go to custom partition just to remove existing partitions
17:19:28 <Martix> kparal: I dont see another way
17:19:34 <jreznik> Martix: so it's not as described in comment #15?
17:20:06 <tflink> I can see how comment#15 could describe removing partitions
17:20:11 <jreznik> could you please provide more details/steps to reproduce?
17:20:26 <Martix> jreznik: AFAIK #15 comment is right
17:20:34 <akshayvyas> can we just make it need info
17:20:57 <tflink> we can, yes
17:21:04 <Martix> jreznik: I was poking around adv. partition and trying to find how to remove LUKS
17:21:19 <Martix> akshayvyas: I'm reporter :-P
17:21:24 <akshayvyas> how it is reproduced
17:21:33 <akshayvyas> steps to reprodus ??
17:21:56 <Martix> akshayvyas: not sure, second time I booted to Anaconda and tried to remove LUKS, it worked
17:22:21 <tflink> then lets reject as blocker - if it becomes more serious after more testing, repropose
17:22:28 <Martix> akshayvyas: as I said AFAIR, reproducer in comment #15 is right
17:22:30 <jreznik> Martix: well in this case you're unable to reproduce it, I'm more -1 blocker
17:22:59 <akshayvyas> Martix: ok i will go with you but still +1 nth
17:23:11 <Martix> jreznik: I think David Lehman have reproducer
17:23:19 <akshayvyas> as tflink said there is a workaround
17:23:29 <tflink> I said that?
17:23:29 <Martix> akshayvyas: fair enough
17:23:31 <akshayvyas> so i am +1 nth
17:23:39 <Martix> ok +1 NTH
17:23:44 <akshayvyas> someone siad not sure
17:23:48 <tflink> -1 on NTH voting
17:23:58 <kparal> -1 blocker +1 nth, please repropose if you find out it is very easy to hit/reproduce
17:24:26 * tflink seems to be outvoted, though
17:24:33 <kparal> tflink: why -1 nth? it's still crashing the manual partitioning, I would rather take that
17:24:46 <tflink> in a way that doesn't always seem reproducable
17:25:02 <kparal> dlehman's description seems to be reproducible
17:25:20 <kparal> dlehman: around? is 876180 easily reproducible?
17:25:43 <dlehman> it's not quite as trivial as I initially thought, but it is reliably reproducible
17:26:01 <kparal> dlehman: what do you think about blocker/nth status? serious enough?
17:26:18 <kparal> can the fix break a lot of other things?
17:26:27 <dlehman> certainly nth
17:26:32 <dlehman> weak -1 on blocker
17:26:34 <tflink> proposed #agreed 876180 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria for F18 beta but fixing installer crashes is preferred - a tested fix would be considered past freeze
17:26:40 <Martix> ack
17:26:42 <akshayvyas> ack
17:26:44 <kparal> ack
17:26:44 <dlehman> the fix is pretty safe
17:26:55 <tflink> #agreed 876180 - RejectedBlocker AcceptedNTH - This doesn't clearly hit any release criteria for F18 beta but fixing installer crashes is preferred - a tested fix would be considered past freeze
17:27:04 <tflink> #topic (876366) New kernel copies its args from the Upgrade System entry
17:27:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876366
17:27:04 <tflink> #info Proposed Blocker, fedup-dracut, NEW
17:27:19 <tflink> this is a fun one
17:27:34 <tflink> it's not reproducable every time for me but I'm +1 blocker on it
17:27:49 <tflink> it leads to a system that doesn't appear to boot post upgrade
17:27:52 <nirik> tflink: to be clear, fedup-dracut is the part thats in f18? ie, the f18 version needs fixed right?
17:28:00 <tflink> nirik: correct
17:28:08 <nirik> just making sure. ;)
17:28:18 <nirik> +1 blocker
17:28:28 <tflink> I was digging into this earlier this morning and I'm not sure the bug is entirely in fedup-dracut
17:28:46 <tflink> grub.cfg is fine going into the upgrade and fedup-dracut doesn't directly call grubby
17:29:03 <tflink> it is called as /sbin/new-kernel-pkg in kernel %%post
17:29:11 <jreznik> wwoods: are you around? ^^^
17:29:43 <kparal> I think this is a clear blocker
17:29:52 <tflink> jreznik: he's aware of the bug - I'm not sure farther discussion is going to help at the moment
17:30:10 * nirik nods.
17:30:11 <kparal> since jskladan hit it on first attempt, it is very likely to be broken for most people, if not all
17:30:14 <jreznik> tflink: ok
17:30:22 <tflink> oh, I hit it every single time on a minimal upgrade
17:30:35 <tflink> for some reason, I don't hit it on a graphical upgrade, though
17:30:49 <kparal> I believe he tried GNOME upgrade, not sure though
17:30:51 <jreznik> tflink: so it could be related? missing something in minimal install?
17:30:53 <tflink> not sure what exactly triggers it
17:30:54 <zodbot> Ticket notification - f18betanicetohave: [Bug 876180] KeyError: None <https://bugzilla.redhat.com/show_bug.cgi?id=876180>
17:31:46 <kparal> let's #propose
17:33:28 <tflink> proposed #agreed 876366 - AcceptedBlocker - This is relatively common and not difficult to reproduce - violates the following F18 beta release criterion: "... it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:34:07 <kparal> ack
17:34:08 <jreznik_> ack
17:34:18 <nirik> ack
17:34:24 <tflink> #agreed 876366 - AcceptedBlocker - This is relatively common and not difficult to reproduce - violates the following F18 beta release criterion: "... it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:34:32 <tflink> #topic (876319) Unable to use analog speakers with Asus Xonar DX
17:34:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876319
17:34:32 <tflink> #info Proposed Blocker, kernel, NEW
17:34:47 * tflink dreams of the day when people actually include criteria with blocker proposals :)
17:34:53 <tflink> -1 blocker
17:35:03 <jreznik_> -1 blocker
17:35:14 <akshayvyas> -1 blocker
17:35:18 <nirik> -1/-1
17:35:29 <kparal> -1 blocker, -1 nth, can be fixed by update
17:35:48 <tflink> proposed #agreed 876319 - RejectedBlocker - This doesn't violate any of the F18 beta release criterion and could be fixed by an update.
17:35:53 <akshayvyas> ack
17:35:53 <jreznik_> ack
17:36:38 <tflink> ack/nak/patch?
17:36:41 <kparal> should we reject as NTH as well?
17:36:50 <kparal> I know it's not proposed
17:36:58 <jreznik_> kparal: yep
17:37:02 <tflink> we could, I don't care much either way
17:37:12 <tflink> #agreed 876319 - RejectedBlocker, RejectedNTH - This doesn't violate any of the F18 beta release criterion and could be fixed by an update.
17:37:19 <tflink> whoops, forgot the proposed
17:37:26 <tflink> any objections? I can #undo
17:37:29 <jreznik_> tflink: I think it's ok
17:37:29 <kparal> let's agree on that afterwards :)
17:37:30 <kparal> ack
17:38:21 <nirik> ack
17:38:36 <tflink> #topic (876655) Lorax does not support building initramfs for fedup
17:38:36 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876655
17:38:36 <tflink> #info Proposed Blocker, lorax, NEW
17:39:03 <tflink> The problem here is that releng can't build the initramfs needed for upgrade until the code is in lorax
17:39:24 <wwoods> hi, I'm back
17:39:42 <tflink> to the best of my knowledge, the patches have been proposed but haven't been pulled to git or included in any official builds yet
17:39:44 <jreznik_> wwoods: hi :)
17:39:55 <tflink> +1 blocker
17:40:06 <nirik> sure, +1
17:40:07 <kparal> +1 blocker
17:40:09 <nirik> hi wwoods
17:40:09 <wwoods> so the 'new kernel gets copy of System Upgrade grubby config' - yeah, that's pretty easily fixable. we need to remove that boot entry anyway; just need to do it before the upgrade gets to the kernel package
17:40:24 <wwoods> was already working on code for that
17:40:27 <nirik> cool.
17:40:37 <jreznik_> +1 blocker
17:40:56 <wwoods> as for lorax: I sent the patches to dgilmore, as he requested
17:41:02 <jreznik_> wwoods: great, when do you expect the code to be packagable?
17:41:14 <wwoods> they're also public at https://github.com/wgwoods/lorax
17:41:16 <jreznik_> wwoods: I'll ping dgilmore or mgracik tmrw
17:41:22 <tflink> proposed #agreed 876655 - AcceptedBlocker - This prevents fedup from doing network upgrades and violates the following F18 beta release criterion: "... it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:41:28 <jreznik_> dgilmore: around? ^^^
17:41:40 <tflink> wwoods: I think the dgilmore was making some changes but I'm not 100% sure
17:41:45 * nirik very much doubts it. It's the middle of the night there.
17:41:52 <kparal> ack
17:41:58 <tflink> something about media based upgrades
17:42:08 <wwoods> I thought dgilmore was in the US? back in au then?
17:42:14 <jreznik_> nirik: ah, you're right :)
17:42:20 <nirik> he's in au currently.
17:42:20 <jreznik_> wwoods: he's in AU now
17:42:34 <tflink> he was back in the US for a while but I think he went back to AU a week or two ago
17:42:47 <wwoods> heh. someday I will surprise you all by being in a completely different timezone than you expect
17:42:58 <jreznik_> tflink: au, us, eu, us, au :)
17:43:01 <wwoods> "oh, didn't I tell anyone that I moved to Dublin?"
17:43:17 * tflink prepares GPS tracking dart for wwoods
17:43:29 <tflink> anyhow, more ack/nak/patch?
17:43:44 <wwoods> anyway I've tested the lorax patch in a VM and 'fedup-cli --device' Does The Right Thing and the upgrade worked (delta other bugs, of course)
17:43:56 <jreznik_> ack
17:44:18 <tflink> I've also tested the initrd generated by lorax and it works as well as one would expect the current packaged fedup-dracut to work
17:44:38 <tflink> #agreed 876655 - AcceptedBlocker - This prevents fedup from doing network upgrades and violates the following F18 beta release criterion: "... it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:44:46 <wwoods> tflink: so you said elsewhere "We're"
17:44:46 <wwoods> > still
17:44:49 <wwoods> > missing changes in git for the log issue"
17:44:55 <wwoods> ngh, evo
17:45:09 <tflink> wwoods: yeah, did you want the patch for the sync hack?
17:45:19 <tflink> unless I just missed the change
17:45:27 <wwoods> do you mean "the package is missing patches that are in git" or "git is missing some patches that I'm using"
17:45:38 <tflink> git is missing some patches that I'm using
17:45:54 <wwoods> and by "log issue" do you mean "output doesn't go to journal" or "journal doesn't get saved"
17:46:05 <tflink> journal and upgrade.log are empty after reboot
17:46:10 <wwoods> ah
17:46:29 <wwoods> sure - send me the patch for the sync hack
17:46:41 <tflink> will do, there is a change to the initrd to include sync; as well
17:46:46 <wwoods> I will put my name on it and a comment explaining my deep shame and regret
17:46:52 <tflink> instead of running $NEWROOT/usr/bin/sync
17:47:17 <wwoods> 'echo s > /proc/sysrq-trigger' should be equivalent
17:47:49 <tflink> that suggested fix led to crashing, a hung upgrade and a non-functional system after upgrade, though
17:47:56 <tflink> the entire thing, anyways
17:48:04 <tflink> but we're getting pretty far off track for the blocker review
17:48:21 <tflink> #topic (875474) Regression: no graphical display after plymouth update
17:48:21 <wwoods> tflink: no, that was doing 's', then 'u', then 'b'
17:48:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875474
17:48:21 <tflink> #info Proposed Blocker, plymouth, NEW
17:48:41 <tflink> wwoods: I can try it with just 's'
17:48:47 <wwoods> anyway. send me what you have and I'll have something committed and a new package.. probably later today?
17:48:55 <wwoods> tflink: that'd be very helpful
17:49:08 <tflink> good point, it was the forcing unmount and reboot that seemed to cause the issue
17:49:45 <jreznik_> I see halfline commented the bug report
17:50:42 <wwoods> tflink: do 'echo 1 > /proc/sys/kernel/sysrq' first, just to be sure
17:51:19 <wwoods> anyway.
17:51:20 <tflink> wwoods: ok, will do. should be able to test that pretty quick
17:51:22 <kparal> I think we need more info first. because I don't see the problem, so it's not completely generic. and we need to know whether rebuilding initrd fixes the problem
17:51:22 * wwoods steps aside
17:52:00 <tflink> kparal: plymouth upgrade doesn't trigger initramfs regeneration
17:52:23 <kparal> tflink: yeah, I know
17:52:28 <tflink> wait, I might be confused here
17:52:42 <kparal> so that might be the reason why I didn't see it
17:52:48 <kparal> or the reason why they still see it
17:52:53 <kparal> it depends when you update your kernel
17:53:16 * kparal firing up his VM
17:53:47 <tflink> on a side note, I was able to do an upgrade with plymouth-0.8.8.3 in the upgrade initramfs
17:54:35 * kparal rebuilding initrd
17:55:21 <kparal> works for me
17:55:37 <tflink> I can see how this would cause problems until initramfs is rebuilt, though
17:55:44 <tflink> assuming that I understand all this :)
17:55:44 <kparal> sure
17:56:05 <kparal> but that can't be fixed if you don't want to rebuild it after every plymouth update
17:56:13 <kparal> there are probably some reasons why we don't do that
17:56:26 * jreznik_ is completely lost now...
17:56:44 <tflink> plymouth changes like this are rather rare, I think
17:56:54 <kparal> I say we punt and ask whether dracut -f helps
17:57:03 <jreznik_> kparal: +1
17:57:06 <tflink> I assume that there is a problem when using the old plymouth in the initramfs with a newer installed plymouth
17:57:18 <tflink> either punt or reject
17:58:09 * kparal votes for punt
17:58:09 <tflink> proposed #agreed 875474 - We need more information on whether or not rebuilding the initramfs fixes the issue described here before deciding on blocker status
17:58:20 <tflink> I think this is already in stable as of last night, though
17:58:36 <kparal> it is stable, and the bug report complains about that particular build
17:58:49 <kparal> the build was intended to fix exactly this
17:59:00 <kparal> halfline: welcome
17:59:04 <halfline> hello
17:59:13 <kparal> halfline: can you shed a bit of light on 875474?
17:59:30 <halfline> nope
17:59:34 <kparal> I just proposed punt and ask whether dracut -f helps
17:59:47 <halfline> i think that's a good idea
17:59:56 <halfline> there was a problem
18:00:04 <kparal> halfline: do people generally have to wait for kernel update to have initrd rebuilt, when there is a plymouth problem like that?
18:00:04 <halfline> but it's supposed to be fixed in -3
18:00:14 <halfline> so there's really only two possibilities i guess
18:00:16 <halfline> 1) didn't get fixed
18:00:21 <halfline> 2) he doesn't have -3 in his initrd
18:00:28 <halfline> kparal: yea
18:00:45 <halfline> which is suboptimal but hard to fix
18:01:42 * kparal says punt
18:01:50 <tflink> ack/nak/patch?
18:01:56 <kparal> jreznik__: you're cloning
18:02:07 <tflink> we have 3 now :-D
18:02:08 <jreznik__> kparal: wifi vs docking station :(((
18:02:09 <kparal> tflink: sorry, overlooked #propose
18:02:19 <kparal> ack
18:02:22 <tflink> proposed #agreed 875474 - We need more information on whether or not rebuilding the initramfs fixes the issue described here before deciding on blocker status
18:02:31 <tflink> didn't change anything, just restated it
18:02:42 <kparal> ack
18:03:20 <akshayvyas> ack
18:03:22 <jreznik> well, if it's the same proposal, ack
18:03:30 <tflink> #agreed 875474 - We need more information on whether or not rebuilding the initramfs fixes the issue described here before deciding on blocker status
18:03:47 <tflink> #topic (873576) mdmonitor-takeover.service not started on boot because lorax disables it, results in parted hanging trying to inspect newly-created Intel fwraid RAID-1 array
18:03:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873576
18:03:53 <tflink> #info Accepted Blocker, lorax, NEW
18:04:13 <tflink> damnation, I copied the wrong bug
18:04:16 <tflink> #undo
18:04:16 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2f33b650>
18:04:18 <tflink> #undo
18:04:18 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x4ad63090>
18:04:20 <tflink> #undo
18:04:20 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x30305850>
18:04:34 <tflink> OK, that's all of the proposed blockers
18:04:51 * tflink might get pulled into the fesco meeting in a bit
18:04:52 <kparal> wohooo
18:05:20 <tflink> #chair kparal
18:05:20 <zodbot> Current chairs: kparal tflink
18:05:41 <kparal> should we end the meeting then?
18:05:42 <kparal> pause?
18:05:49 <kparal> or going on?
18:05:55 <tflink> we still have proposed NTH etc.
18:06:21 <kparal> let's do it
18:06:38 <tflink> and I don't know if they're even going to discuss fedup/freeze for long if at all
18:07:01 * tflink skipps 875393 since it was accepted as blocker
18:07:05 <tflink> #topic (874265) Installation Options screen is too wide for 1024x768 display in German
18:07:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874265
18:07:10 <tflink> #info Proposed NTH, anaconda, VERIFIED
18:07:47 <kparal> I'm +1 NTH here
18:07:52 <kparal> just translation change
18:08:05 <kparal> and it's verified already
18:08:38 <tflink> +1 NTH
18:09:26 * kparal pokes around
18:09:29 <tflink> proposed #agreed 874265 - AcceptedNTH - This is a minor translation and display issue and leads to better usability  - a tested fix would be considered past freeze
18:09:33 <kparal> ack
18:10:33 <kparal> we seem to be missing some voting manpower
18:10:36 <tflink> yep
18:10:40 <jreznik> germans should by better LCDs as it's hard to fit it to the screen (always)
18:10:52 <jreznik> seems like easy translation fix, ack
18:10:54 <tflink> and stop using VMs?
18:11:03 <kparal> jreznik: that's an engineering solution, I like it!
18:11:04 <tflink> #agreed 874265 - AcceptedNTH - This is a minor translation and display issue and leads to better usability  - a tested fix would be considered past freeze
18:11:19 <tflink> #topic (874753) Can't change keyboard layout in GDM by default
18:11:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874753
18:11:19 <tflink> #info Proposed NTH, control-center, NEW
18:12:33 <tflink> yay! The every-release-nonUS-keyboard-breaks-password kind of bug!
18:12:57 <kparal> btw, are we frozen yet?
18:13:00 <tflink> yeah
18:13:01 <jreznik> kparal: yep
18:13:17 <kparal> jreznik: was there an announcement?
18:13:22 <kparal> anyway, thanks
18:13:24 <jreznik> kparal: yes
18:13:38 * nirik made a devel-announce one
18:13:43 <jreznik> kparal: on devel-announce
18:13:51 <kparal> ah
18:13:55 <kparal> don't read that every day
18:13:56 <jreznik> nirik: I was surprised you freeze before fesco meeting but :)
18:14:24 * tflink still doesn't understand why we unfroze
18:14:25 <nirik> jreznik: the ticket was supposed to be if there were serious objections... I didn't see any in there.
18:14:29 <tflink> for a week
18:14:44 <kparal> this is funny: When you add new keyboard layout, change password using this layout and then remove this layout. You're stuck at Lock Screen
18:15:04 <kparal> however, it's a bit silly workflow
18:15:09 <tflink> that sounds a lot like self-inflicted pain
18:16:17 <kparal> I wouldn't like to have this as NTH. can be always updated. there is another problem with gdm and anaconda (anaconda not setting the layout used for installation), and that should be fixed, but not this one
18:16:34 <tflink> yeah, I'm thinking -1 NTH as well
18:16:56 <kparal> but maybe the bug I'm talking about is already fixed, I didn't have time to test it
18:17:01 <kparal> this one -1 nth
18:17:14 <tflink> wait, where do they talk about removing the layout?
18:17:46 <kparal> the lock screen case
18:17:55 <kparal> the gdm case is the original description
18:18:43 <tflink> does this affect installation?
18:19:00 <tflink> ie, if you install and set root password with a non-US keyboard layout, can you login from GDM?
18:19:00 <kparal> this bug, as it is written, doesn't indicate it
18:19:17 <kparal> tflink: I'll probably try that now, but that would be a different bug
18:19:32 <tflink> it would?
18:19:40 <tflink> not sure I follow
18:19:59 <tflink> the bug here is that adding keyboard layouts to gdm is non-obvious at best, right?
18:20:21 <kparal> yes. but I hope anaconda sets the default correctly
18:20:26 <kparal> so this bug report would apply just for new layouts
18:20:47 <tflink> point
18:21:34 <tflink> proposed #agreed 874753 - RejectedNTH - This could be fixed by an update and has a workaround if someone really wants to add a layout post-install for user creation.
18:21:46 <tflink> ack/nak/patch?
18:21:49 <Viking-Ice> you guys held blocker bug meeting with only what two three people adamw cancelled last one when it was so few...
18:22:14 <kparal> Viking-Ice: welcome. wanna help us?
18:22:15 * nirik notes he had to go to the fesco meeting, but was around eariler, as were a number of others.
18:22:34 <kparal> ack
18:22:52 <tflink> Viking-Ice: we had more people earlier
18:24:04 <Viking-Ice> kparal, Nope I'm gonna clock out I've been busy at work dealing with sweden
18:24:12 <Viking-Ice> tflink, you mean one more ;)
18:24:32 <Viking-Ice> (n)ack your self's out I'm off
18:25:03 <kparal> it is true that if no else appears, we could end the meeting and continue tomorrow or some other time. but we don't know there would be more people then
18:25:06 <tflink> someday, he's not going to be critical and argumentative ... when that day comes, I'm going to fall over from shock
18:25:28 * akshayvyas is back
18:25:44 <kparal> people don't change _that much_
18:26:05 <tflink> I didn't say permanently, just one time would be enough to cause that kind of shock
18:26:06 <kparal> akshayvyas: talking about 874753
18:26:24 <kparal> Martix: still around?
18:26:35 * akshayvyas is lookking at it
18:27:32 <Martix> kparal: yep
18:27:43 <kparal> Martix: talking about your bug
18:27:47 <Martix> Nice-to-have
18:28:01 <tflink> why? it can be fixed with an update
18:28:08 <kparal> Martix: our current status is "can be fixed by update and it is not very frequent scenario"
18:28:19 <kparal> gdm is a critical part of the system
18:28:58 <Martix> tflink: you can hit this bug before you update, we need to test it with firstsetup
18:29:23 <Martix> tflink: using non en_US keymap in firstsetup for inputing password
18:29:49 <tflink> you can hit lots of bugs before you update
18:30:13 <tflink> installing beta and not updating immediately is tempting fate, in general
18:30:23 <akshayvyas> Matrix: is it 100% reproduceable
18:30:24 <Martix> I have no idea if Anaconda or firstsetup set system keyboard correctly
18:30:32 <tflink> you can log in with the original user, no?
18:30:33 <Martix> akshayvyas: yes
18:30:48 <tflink> can you login on a VT?
18:31:15 <tflink> single mode?
18:32:10 * kparal is trying czech installation and broke anaconda in the process. sigh
18:32:50 <akshayvyas> i am +1 here
18:33:10 <tflink> so we're +1/-2 ?
18:33:31 <tflink> well, +2/-2 with Martix's implied +1
18:33:38 <tflink> so much for acking the proposal
18:33:48 <kparal> :)
18:33:51 <Martix> tflink: right :-D
18:34:18 <kparal> Martix: not funnny
18:34:23 <akshayvyas> #3 of Martix convinced me
18:34:34 <Martix> akshayvyas: great :-)
18:34:48 <kparal> it's Beta, people
18:34:53 <Martix> kparal: this wasn't my intention ;-)
18:35:06 <kparal> this is a very rare use case
18:35:07 <tflink> so we're deadlocked
18:35:19 <kparal> yes, punt and leave for next meeting
18:35:21 <tflink> unless we want to waste more time on this
18:35:47 <kparal> no
18:35:52 <tflink> #info we were unable to come to a conclusion on this bug - stuck at +2/-2 NTH. Will revisit when more people are present
18:36:01 <tflink> #topic (874761) "Log Out" and "Switch User" unavailable after creating second user account in "User Accounts"
18:36:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874761
18:36:07 <tflink> #info Proposed NTH, gnome-shell, NEW
18:36:45 <tflink> I think I'm also -1 NTH on this
18:36:57 <tflink> it shouldn't affect many live use cases and could be fixed by an update
18:37:42 <kparal> Martix: I don't understand the workaround
18:38:17 <tflink> I imagine it has something to do with forcing a refresh of user info in shell?
18:38:18 <kparal> and I also don't understand what 'stuck on' means in comment 1
18:38:29 <tflink> I wonder if a reboot would fix it, too
18:38:30 <kparal> does it mean available or missing?
18:38:44 <akshayvyas> i am -1 blocker
18:38:52 <kparal> Martix: have you tried rebooting?
18:39:00 <kparal> akshayvyas: it's proposed as nth
18:39:07 <Martix> kparal: no
18:39:27 <akshayvyas> oh sorry
18:39:30 <tflink> kparal: I think it refers to the ability to log out of a single user system
18:39:33 <akshayvyas> i am -1 NTH
18:39:46 <tflink> and how there is no situation where a single user would want to log out of a system
18:40:05 <Martix> kparal: workaround is simple: open User Accounts again, unlock and lock it
18:40:15 <tflink> so 'stuck on' means that the menu item stays available even when the second user is removed
18:40:28 <Martix> tflink: it doesn't work even when you create second user
18:40:40 <tflink> Martix: I was referring to mclasen's comment
18:40:48 <kparal> I find it ironic that when I argues sometimes it is necessary to log out even on a single user system because of broken applications, gnome developers told me "they should not be broken". now it's gnome shell that's broken
18:40:49 <tflink> which seems to be related but not quite teh same
18:41:08 <kparal> *argued
18:41:41 <tflink> yes, nothing is _EVER_ broken in a system
18:41:44 <kparal> I just wonder
18:41:46 <kparal> " All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work "
18:42:04 <tflink> it isn't offered, though
18:42:14 <kparal> that's nitpicking, really
18:42:25 <tflink> for this issue, yes it is :)
18:43:05 <kparal> but the fix can cause regressions
18:43:14 <kparal> let's commonbugs it
18:43:17 <tflink> any other votes?
18:43:17 <kparal> -1 nth
18:43:28 <tflink> why commonbugs?
18:43:54 <kparal> so it's just in the release notes
18:44:04 <kparal> it can be quite a visible bug on multiuser system
18:44:12 <tflink> proposed #agreed 874761 - RejectedNTH - This doesn't hit any common use cases for live images, has a relatively simple workaround and could be fixed with an update - rejected as NTH for F18 beta.
18:44:13 <kparal> not that Beta would be used much for multiple users, I guess
18:44:28 <Martix> +1 NTH Final?
18:44:44 <tflink> I'd still be -1 NTH at final
18:44:53 <kparal> Martix: we can certainly propose it right away, but let's skip the discussion now
18:44:55 * jreznik has to go to make Board call today :(
18:44:56 <kparal> too few people here
18:45:08 <kparal> ack
18:45:10 <akshayvyas> i am -1 NTH
18:45:15 <akshayvyas> ack
18:45:19 <kparal> personally I'd be +1 nth for final
18:45:24 <jreznik> ack (last one ;-)
18:45:26 <tflink> #agreed 874761 - RejectedNTH - This doesn't hit any common use cases for live images, has a relatively simple workaround and could be fixed with an update - rejected as NTH for F18 beta.
18:46:01 <tflink> do we have enough people to continue?
18:46:17 <akshayvyas> lets count :)
18:46:39 <jreznik> tflink: how many bugs do we still have?
18:46:50 <tflink> 2 proposed NTH
18:47:00 * jreznik would like to avoid sitting in the office by 11 pm :(
18:47:06 <kparal> let's leave it to the next meeting
18:47:07 * nirik is back
18:47:18 <jreznik> tflink: go on, I'll survive it if it's going to be fast enough :)
18:47:20 <tflink> 7 accepted blockers - but those don't need as much voting
18:47:31 <tflink> #topic (876258) mate files in updates-testing need to be NTH - MATE install does not work in DVD
18:47:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=876258
18:47:37 <tflink> #info Proposed NTH, mate-desktop, NEW
18:47:52 <tflink> +1 NTH - non-blocking DE
18:48:21 * nirik is unclear here...
18:48:24 <jreznik> tflink: I don't understand - do we have mate on dvd officially?
18:48:25 <tflink> proposed #agreed 876258 - AcceptedNTH - This prevents the install of MATE (non-blocking DE) from the DVD.
18:48:35 <rdieter> i think i just saw a commit come through from notting, essentially excluding mate from the DVD for space reasons, so the point may be moot at this point
18:48:35 <nirik> mate is not on the dvd.
18:48:35 <tflink> I think it's available as a DE in anaconda
18:48:41 <nirik> you would need to enable network repos.
18:48:47 <nirik> thats a mistake in tc8.
18:48:54 <tflink> ah, nvm then
18:49:05 <kparal> skip now?
18:49:06 <nirik> mate-polkit was pulled in because pungi pulls in everything.
18:49:22 <jreznik> and then mate-desktop was pulled in to tc7
18:49:42 <nirik> anaconda shows a group (or at least used to) if _ANY_ packages in that group are on the media.
18:50:00 <nirik> so, I think this is moot... you just need to enable network and it should work.
18:50:13 <tflink> proposed #agreed 876258 - RejectedNTH - MATE is not on the DVD and fixed packages are available in network repos.
18:50:25 <nirik> ack
18:51:06 <kparal> so it will be no longer displayed on DVD?
18:51:16 <tflink> sounds like that, yes
18:51:17 <nirik> unless you enable network repos.
18:51:27 <kparal> ok, ack then
18:51:31 <akshayvyas> ack
18:51:39 <tflink> #agreed 876258 - RejectedNTH - MATE is not on the DVD and fixed packages are available in network repos.
18:51:46 <tflink> #topic (847479) Kernel 3.5.0-2 and 3.5.1-1 nouveau driver causes Xorg to abrt after resume from RAM
18:51:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=847479
18:51:52 <tflink> #info Proposed NTH, xorg-x11-drv-nouveau, NEW
18:52:35 <tflink> Martix: does this affect F18?
18:52:52 * nirik is +1 NTH as long as it affects a variety of hardware.
18:53:19 <kparal> I have the latest kernel on my nouveau laptop and suspend works fine
18:53:24 * nirik reads more.
18:53:24 * tflink is -1 NTH unless there's something Im missing something here
18:53:44 <nirik> I don't see any f18 reports in there?
18:53:55 <tflink> I have a hard time seeing many people suspending while running a livecd
18:54:02 <kparal> this is reported against f17
18:54:13 * nirik changes to -1
18:54:14 <tflink> especially since on a beta livecd
18:54:29 <akshayvyas> -1 nth
18:54:32 <kparal> Martix: why is this proposed against F18, when it's F17 bug?
18:55:25 <tflink> proposed #agreed 847479 - RejectedNTH - It isn't clear that this affects F18, is unlikely to affect live images and could be fixed with an update
18:55:33 <jreznik> ack
18:55:35 <akshayvyas> ack
18:55:38 <nirik> ack
18:55:44 <tflink> #agreed 847479 - RejectedNTH - It isn't clear that this affects F18, is unlikely to affect live images and could be fixed with an update
18:55:46 <kparal> I would just remove the flag and say this has been proposed by mistake
18:56:13 <Martix> kparal: I have no idea, maybe its duplicate?
18:56:21 <kparal> Martix: you proposed it
18:56:29 <kparal> Martix: with no explanation whatsoever
18:56:37 <tflink> again :)
18:57:02 <tflink> proposed it as a blocker, removed blocker proposal and proposed NTH
18:57:50 <tflink> with no explanation for any of it that I'm seeing
18:57:58 * tflink doesn't think NTH proposal was a mistake
18:58:00 <kparal> Martix: nine-o-cat on you
18:58:17 <Martix> kparal: it was reported during X test week
18:58:21 <kparal> I don't really see how this affects F18
18:58:28 <jreznik> Martix: f18?
18:58:30 <akshayvyas> lets move on..
18:58:42 <tflink> OK, we're done with the proposed NTH
18:58:56 <tflink> time for some accepted blockers
18:59:08 <tflink> #topic (873762) [zh_CN] [zh_TW] installer hangs in Installation Summary when keyboard spoke clicked
18:59:10 <Martix> jreznik: yes, I found it in adamw report from this test week
18:59:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873762
18:59:13 <tflink> #info Accepted Blocker, anaconda, ON_QA
18:59:58 <kparal> this is waiting for a new compose
19:00:04 <kparal> we need livecds
19:00:11 <Martix> jreznik: http://lists.fedoraproject.org/pipermail/test-announce/2012-October/000527.html look for 847479
19:00:13 <kparal> I didn't see the problem on netinst
19:00:21 <kparal> but I saw a problem on TC8 livecd
19:00:28 <kparal> so waiting for TC9 livecd
19:01:04 <tflink> #info fix is available, waiting for new livecds for testing
19:01:14 <tflink> #info should be testable in the next TC/RC
19:01:21 <Martix> kparal: latest unofficial compose is uploading for KDE 4.9 Test Day, if you want to try, I have it already on my scratch space
19:01:30 <kparal> tflink: should I secretarialize (ignore spelling problems) also for these accepted bugs?
19:01:36 <tflink> #info problem doesn't manifest on livecds
19:01:51 <kparal> tflink: #undo, it does
19:02:09 <tflink> kparal: depends on the bug. usually only when we want to poke for more testing or status update
19:02:14 <tflink> #undo
19:02:14 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x47d09a50>
19:02:22 <kparal> tflink: ok
19:02:30 <tflink> #info seems to be fixed on netinstall but needs testing on livecds
19:02:33 <tflink> kparal: is that better?
19:02:37 <kparal> tflink: yes
19:02:45 <tflink> k, anything else on this bug?
19:02:49 <kparal> nope
19:03:00 <tflink> #topic (875364) Both 18 Beta TC8 install DVDs are > 4.7 GB
19:03:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875364
19:03:00 <tflink> #info Accepted Blocker, distribution, NEW
19:03:16 <tflink> this might be fixed
19:03:22 <tflink> I was asked to do a new smoke build to test
19:03:30 <tflink> right as the meeting started, so I haven't gotten to it yet
19:03:43 <tflink> #info some movement on this, may be fixed
19:03:54 <jreznik> kernel-debug and mate* blocked
19:03:59 <tflink> #info new smoke DVD or TC/RC needed to test
19:04:09 <jreznik> 875380 should fix it but nobody is sure right now
19:04:21 <tflink> I should try a DVD with the lorax that includes upgrade.img
19:04:37 <tflink> I suspect that's going to add ~ 20M to the DVD but I'm not sure
19:04:38 <jreznik> otherwise jnovy has a few ideas how to solve it if this won't be enough
19:04:57 <jreznik> tflink: kernel-debug means approx 27M less
19:05:07 <tflink> we'll see what happens
19:05:35 <jreznik> tflink: yep, please let the comment in the bug once you have smoke
19:05:36 <tflink> either way, nothing we really need to do here - there seems to be progress
19:05:42 <tflink> jreznik: will do
19:05:57 <tflink> anything else?
19:06:05 <jreznik> move on
19:06:10 <tflink> yessir
19:06:13 <tflink> #topic (872047) fedup-dracut builds do not exist in F18
19:06:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872047
19:06:13 <tflink> #info Accepted Blocker, fedup-dracut, ON_QA
19:06:25 <tflink> this is being worked on indirectly
19:06:43 <tflink> the current build in updates-testing needs stuff in order to solve other blocker issues
19:06:53 * nirik nods
19:07:01 <tflink> I need to test another patch for will after the meeting but we should have a new build later today
19:07:18 <jreznik> great, thanks tflink
19:07:55 <tflink> #info this is being worked on indirectly, waiting for another build before asking for karma to push fedup-dracut to stable
19:08:13 <tflink> #info should have a new build in the next day or so that can be pushed to stablre
19:08:16 <tflink> #undo
19:08:16 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x56ce3b50>
19:08:18 <tflink> #info should have a new build in the next day or so that can be pushed to stable
19:08:22 <tflink> typo
19:08:28 <tflink> #topic (873459) Upgraded system does not reboot if a kernel upgrade is part of the upgrade
19:08:31 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873459
19:08:34 <tflink> #info Accepted Blocker, fedup-dracut, ASSIGNED
19:08:45 <tflink> #info This is being worked on, most of the fixes for this are in upstream git
19:08:56 <tflink> #info waiting on one last patch before new packages are built
19:09:04 <tflink> #info should see new packages in the next day or so
19:09:26 <tflink> anything else?
19:09:30 * tflink assumes not
19:09:32 <jreznik> no
19:09:36 <tflink> #topic (873576) mdmonitor-takeover.service not started on boot because lorax disables it, results in parted hanging trying to inspect newly-created Intel fwraid RAID-1 array
19:09:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873576
19:09:41 <tflink> #info Accepted Blocker, lorax, NEW
19:10:31 <tflink> my understnading of this is that lorax failed to remove the service for F17, and everything worked
19:10:42 <tflink> now the service is being removed and no longer works
19:10:45 <tflink> anyhow ...
19:10:54 <tflink> #info this bug is now mostly triaged
19:10:56 <jreznik> something like that
19:11:01 <tflink> #info test boot.iso is available for testing
19:11:11 <jreznik> now we need someone with hw to test it
19:11:42 <jreznik> mdmon has to be runned somehow, does not matter if by anaconda, systemd service etc.
19:11:49 <tflink> adam should be back later today
19:12:05 <tflink> I'll try to test it but I suspect that I'm going to be busy with other stuff today
19:12:21 <tflink> anything else on this?
19:12:26 * jreznik does not have intel raid hw...
19:13:05 <tflink> moving on ...
19:13:08 <tflink> #topic (875380) fileconflicts failure on 18 Beta TC8 DVDs (texlive)
19:13:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875380
19:13:08 <tflink> #info Accepted Blocker, texlive, NEW
19:13:39 <tflink> #info still waiting for packages to be removed from F18
19:13:48 <tflink> #info will need testing @ next TC/RC
19:14:04 <nirik> they should be removed now.
19:14:12 <tflink> #undo
19:14:12 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1a6b3e90>
19:14:13 <tflink> #Undo
19:14:13 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x120cc910>
19:14:32 <tflink> #info the packages in question should be removed now
19:14:44 <tflink> #info this will need re-testing after the next TC/RC
19:14:49 <tflink> nirik: thanks
19:15:08 <tflink> I don't think there is anything else we need to do here
19:15:18 <tflink> that would be all of the bugs on my list
19:15:22 <tflink> anything I missed?
19:15:59 <tflink> then it's time for ...
19:16:03 <tflink> #topic Open Floor
19:16:11 <tflink> Other issues that should be brought up here?
19:16:15 * nirik has nothing.
19:16:41 * jreznik is ok too, seem the things are at least triaged and getting under control
19:16:44 <tflink> #info next blocker review meeting will be 2012-11-21 @ 17:00 UTC
19:16:54 <tflink> which might be a holiday for me
19:17:02 <tflink> I forget when thanksgiving is
19:17:28 * jreznik hopes we will have rc soon :)
19:17:40 <tflink> we'll cross that bridge when we get there
19:17:50 <tflink> if there's nothing else, fuse time
19:18:20 * tflink sets nondeterministic fuse for some [0,inf) time period
19:18:20 <jreznik> tflink: ;-) yep
19:18:28 <tflink> kparal: thanks for secretarializing
19:18:28 <akshayvyas> tflink:i think we are almost there anaconda is  working ok now
19:18:30 <jreznik> like 3...2...
19:18:37 <kparal> tflink: thanks for leading
19:18:50 <tflink> jreznik: there is no way to know ahead of time - it's nondeterministic
19:18:57 <kparal> and there's also the benefit that bugzilla doesn't send me all these emails
19:19:00 <tflink> Thanks for coming, everyone
19:19:13 <tflink> kparal: it's irritating me, caused some confusion already
19:19:19 <akshayvyas> tflink: Thanks :)
19:19:26 * tflink will send out minutes shortly
19:19:29 <tflink> #endmeeting