17:01:40 <tflink> #startmeeting F17-beta-blocker-review-5
17:01:40 <zodbot> Meeting started Fri Apr  6 17:01:40 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:40 <tflink> #meetingname F17-beta-blocker-review-5
17:01:40 <zodbot> The meeting name has been set to 'f17-beta-blocker-review-5'
17:01:46 <tflink> #topic roll call
17:01:55 * brunowolff is here
17:01:57 <tflink> who's ready for some mind-blowing blocker review fun?
17:03:03 <adamw> yo
17:04:23 <tflink> brunowolff, adamw: welcome to the party!
17:04:51 <brunowolff> At least it's a slow Friday here today.
17:05:18 <brunowolff> Hopefully we'll get next week off from blocker meetings.
17:05:32 <tflink> brunowolff: helped by the fact that it's a holiday for NA based RH employees :)
17:06:03 <tflink> yeah, here's to hoping for no more beta slippage
17:06:42 * tflink waits a few more minutes, hoping for at least 1 more person
17:09:20 <tflink> hrm, I'm thinking that we're not going to get any more ... lets get started with the 3 of us
17:09:58 <tflink> boilerplate time!
17:10:03 <tflink> #topic introduction
17:10:13 <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:10:28 <tflink> Will be following the list of blocker bugs at:
17:10:37 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:10:58 <tflink> The process is outlined as:
17:11:06 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:11:18 <tflink> And the criteria for beta release are:
17:11:26 <tflink> #link https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
17:11:32 <tflink> Up for review today, we have:
17:11:41 <tflink> #info 2 proposed blockers
17:11:41 <tflink> #info 2 accepted blockers
17:11:41 <tflink> #info 8 proposed NTH
17:11:59 <tflink> unless there are objections, I'm going to start in with the proposed blockers
17:12:36 <jskladan> hi there!
17:12:48 * jskladan is a bit late, dinner took longer than expected
17:12:55 <tflink> #topic (804835) Failed to install GRUB2 into boot partition
17:12:55 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804835
17:12:55 <tflink> #info Proposed Blocker, NEW
17:12:57 <buggbot> Bug 804835: unspecified, unspecified, ---, anaconda-maint-list, NEW, Failed to install GRUB2 into boot partition
17:14:24 <brunowolff> Reading this I am not sure if this pilot error or a real bug.
17:14:48 <tflink_> crap, having network problems again and I lost my other irc session
17:14:54 <brunowolff> Is chain loading really broken, or are people expecting chain loading to be automatically set up for them?
17:16:16 <jskladan> brunowolff: nope, at least in pschindl's case
17:16:20 <adamw> from the number of people saying 'it worked with f16' i'm saying probably the former
17:17:08 <adamw> frankly, though, i'm of a mind to reject it because they didn't damn well propose it a week ago. why the hell propose it now? just to give me indigestion?
17:17:09 <adamw> :P
17:17:21 <tflink_> does anyone know if it's possible to add a chair if I can't access my other session?
17:18:33 <adamw> no idea
17:18:59 <adamw> jskladan: is kparal around?
17:18:59 <brunowolff> It doesn't look like you made anyone else chair, so I don't think we can do it.
17:19:13 <tflink_> yeah, I forgot to do that before I lost access to my session
17:19:26 * tflink_ figured that the network glitches were taken care of :-/
17:20:02 * tflink_ goes looking for an admin
17:20:09 <brunowolff> Maybe /msg nickserv release can free up your other nick?
17:20:27 <jskladan> adamw: IMHO not
17:20:31 <tflink_> brunowolff: the other IRC session is still active - I just lost access to the machine that its running on
17:21:04 <fenrus02> tflink: auth to zodbot as your same user with the second nick?  iirc, it should give you the same perms
17:21:16 <brunowolff> The release command might still be able to release that. Though I only use when I forget to /id in 30 seconds.
17:21:41 <tflink> #chair tflink_
17:21:42 <zodbot> Current chairs: tflink tflink_
17:22:01 <tflink_> #chair adamw
17:22:01 <zodbot> Current chairs: adamw tflink tflink_
17:22:20 <adamw> i think this may actually be a 'dependency' issue
17:22:29 <adamw> i think you can't chainload 2.00~beta2 from 1.99
17:22:45 <adamw> just guessing, but - looking at http://ubuntuforums.org/showthread.php?t=1307385 , which looks rather similar, where people are trying to chainload grub2 from grub1
17:26:09 <tflink> I could see the argument that this falls under custom partitioning for final
17:26:57 <adamw> it's bootloader, not partitioning
17:27:09 <adamw> i'd say it's a conditional breakage of whatever 'system must boot' criterion you want to cite
17:27:10 <tflink> I know, I'm just interpreting it liberally
17:27:12 <adamw> =)
17:27:28 <brunowolff> Is the bug in grub 1.99 or 2.00 beta2?
17:27:37 <adamw> my suspicion is there isn't really a bug
17:27:38 <adamw> in either
17:28:04 <adamw> i just think you can't 'chainload' between different grub versions; if you google you hit quite a lot of those 'core.img' recommendations for doing this
17:28:06 <tflink> I guess I'm just wondering if this is a beta blocker
17:28:14 <adamw> tflink: well i'm trying to figure that out :)
17:28:51 <adamw> it would help if pjones were around :/
17:29:11 <tflink> adamw: then I'll leave you to it
17:29:43 <adamw> if i'm right, then i'm -1 blocker
17:29:53 <adamw> i think this is just another artifact of grub2's design
17:30:18 <brunowolff> Since there's a work around and people need to manually tweak this case anyway, I think we could get away with a common bugs entry.
17:31:01 <adamw> yeah, that's another sensible way of looking at it...
17:31:29 <adamw> really the only difference between my reading and yours is whether you call it 'the right way to do it' or a 'workaround' :)
17:32:13 <brunowolff> I think it's really late to be doing a grub2 upgrade. If there was a targeted patch, that would be worth considering.
17:35:17 <adamw> there's no upgrade to do, we're at the latest upstream version.
17:36:41 <adamw> pjones is awake in #anaconda now, asking for his opinion
17:39:39 <adamw> shall we table this one while we wait for pjones, and circle back?
17:39:52 <jskladan> adamw: yes please :)
17:39:59 <tflink> sound ok to me
17:40:00 * nirik arrives late, reads back up
17:40:14 <tflink> #info discussion is tabled until we get more input from developers
17:40:23 <tflink> #topic (810451) Logging out crashes i686 LiveCD system
17:40:24 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810451
17:40:24 <tflink> #info Proposed Blocker, NEW
17:40:26 <buggbot> Bug 810451: unspecified, unspecified, ---, xgl-maint, NEW, Logging out crashes i686 LiveCD system
17:43:01 <adamw> erf. well, this is icky.
17:43:12 <tflink> so, this is a conditional breakage of "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
17:43:22 <tflink> does this happen on bare metal, too?
17:43:50 <tflink> sounds like it probably would
17:43:57 <jskladan> tflink: see comment 17
17:43:57 <nirik> hum.
17:44:19 <tflink> jskladan: thanks, I didn't see that
17:44:28 <nirik> seeing the link to bug 810447 I wonder if switching that selinux bool makes it work.
17:44:30 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=810447 unspecified, unspecified, ---, mgrepl, NEW, SELinux is preventing gdb from using the 'ptrace' accesses on a process.
17:45:05 <brunowolff> I suspect that the selinux issue happens after the crash.
17:45:20 <nirik> yeah, but wonder if it's somehow preventing it from moving on.
17:45:38 <adamw> i'd be more inclined to suspect the shell segfault.
17:45:46 <adamw> still, should be easy enough to check...
17:45:50 * adamw grabs the 32-bit live
17:46:04 <nirik> ~/.xsession-errors might have some more clues...
17:46:36 <adamw> anyone have it downloaded already?
17:46:44 * tflink checks
17:47:10 <tflink> not rc3, no
17:47:38 <adamw> 2:30 on my download
17:47:51 <adamw> this is kinda borderline...i'm really sitting on the fence
17:48:39 <tflink> yeah, it's certainly not a clear blocker
17:49:06 <brunowolff> If it is just in the live environment, this doesn't seem like a beta blocker.
17:49:23 <tflink> I'd probably be +1 nth, though
17:49:26 <nirik> and it works ok once installed...
17:49:57 <adamw> well, there are some valid use cases cited in the bug.
17:50:56 <tflink> yeah, mostly the "not knowing about alt for shutdown" part for me
17:51:32 * nirik nods.
17:51:37 <adamw> well, and the complete system crash/poweroff is a bit icky.
17:51:51 <jskladan> adamw: Not to be a 'anti-qa' person, but is "now knowing about the alt key for shutdown" really a case for that criterion
17:51:58 * jskladan aaa ninja'd
17:52:19 * nirik is leaning toward blocker...
17:52:33 * adamw booting a VM now
17:52:34 <tflink> jskladan: looks bad, mostly - bad first experience
17:53:38 <tflink> but I suppose that doesn't answer your question about the criterion
17:53:46 <adamw> wow. my first try reproduced the 'VM just flat powers off' case. that's pretty crazy
17:53:52 <jskladan> tflink: and I'd block final for this, of course... but being a devil's advocate, all the ways to shut down the system do work
17:54:04 <jskladan> if you get to them :D
17:54:28 <tflink> yeah, I get a useless system when I attempt to logout
17:54:54 <adamw> setenforce Permissive doesn't help
17:55:00 <adamw> second try powered the system off too
17:55:02 <adamw> that's pretty nuts.
17:55:44 <nirik> wonder if this came in with the gnome 3.4 gdm?
17:55:52 <tflink> selinux=0 works for me
17:55:55 <adamw> i really hope not.
17:55:57 <adamw> tflink: huh.
17:56:03 <adamw> so maybe it came in with selinux policy :P
17:56:33 <nirik> try a 'setsebool -P deny_ptrace off' ?
17:56:54 <adamw> ah, yup, selinux=0 helps.
17:57:06 <fenrus02> no avc's ?
17:58:02 <adamw> fenrus02: it's hard to catch it, because it's a live boot, and the symptom is 'the system flat powers itself off'.
17:58:19 <adamw> nirik: testing
17:58:32 <fenrus02> erg.  and using semanage -DB with a persist overlay doesnt update audit.log?
17:58:47 <tflink> nirik: works better
17:59:01 <adamw> tflink: not here...it powered off again
17:59:07 <tflink> I get tossed back into the live session instead of being powered off
17:59:24 <adamw> tflink: the report says that 'sometimes' that happens instead of the poweroff
17:59:56 <tflink> yep, I hit it when I tried logging out again
18:00:03 <adamw> tflink: can you grab the avc and trace from that system before....oh.
18:00:15 <tflink> oops
18:00:19 <tflink> I'll keep trying it
18:00:24 <tflink> it was ptrace, though
18:01:12 <adamw> anyhow, seems like we all reproduce this...
18:01:18 <adamw> it's icky enough that i'm probably +1 blocker
18:01:27 * nirik nods. me too. +1 blocker
18:01:59 <brunowolff> +0 beta blocker, +1 NTH, +1 final blocker
18:02:24 <fenrus02> does it only happen on livemedia?
18:02:39 <adamw> fenrus02: yeah, only when booting live. but it's a pretty crazy bug.
18:02:41 <fenrus02> if it's only live, then adjust policy in %post.  if it's both, i would +1 blocker
18:03:02 <tflink> i686 only, too
18:03:16 <fenrus02> erg.  that's getting to be a narrow testcase.
18:03:32 <fenrus02> unfortunately, 32bit is still more commonly downloaded
18:03:58 <tflink> proposed #agreed - 810451 - AcceptedBlocker - hits the F17 beta release criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work" for i686 live images
18:04:08 <adamw> ack
18:04:12 <nirik> ack
18:04:43 <fenrus02> ack
18:04:54 <tflink> #agreed - 810451 - AcceptedBlocker - hits the F17 beta release criterion "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work" for i686 live images
18:05:10 <tflink> I assume we're ready to circle back to the bootloader issue?
18:05:21 <adamw> sure
18:05:33 <tflink> #topic (804835) Failed to install GRUB2 into boot partition
18:05:33 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=804835
18:05:33 <tflink> #info Proposed Blocker, NEW
18:05:35 <buggbot> Bug 804835: unspecified, unspecified, ---, anaconda-maint-list, NEW, Failed to install GRUB2 into boot partition
18:06:08 <adamw> so pjones is strongly of the opinion it's not a blocker, same thought process as me and bruno - you have to manually configure such a set up anyway, and so it's really just a case of knowing the right way to do it
18:06:29 <adamw> he's not 100% sure atm but he thinks it may be just what i suggested - the 'right way' to chainload grub2 is to boot core.img , not use the chainloader command.
18:06:40 <adamw> so, given that, i'm definite -1.
18:06:51 <tflink> same here, -1 blocker
18:07:23 * nirik is -1 blocker too, but might be nice to document the way to do it for those that need to.
18:07:46 <jskladan> ^^
18:07:54 <brunowolff> -1 blocker
18:08:52 <tflink> proposed #agreed - 804835 - RejectedBlocker - This is not clearly a bug and no matter what, the desired outcome requires manual setup. Add documentation for the correct way to use multiple grubs and commonbugs for F17 beta
18:09:21 <brunowolff> ack
18:09:38 <nirik> well, not sure it's all that common a bug, perhaps the grub2 wiki page? but sure, ack.
18:09:53 <tflink> nirik: you have a point there
18:09:56 <adamw> nirik: commonbugs is still the right place for it, though
18:10:34 <jskladan> ack, +1 to commonbugs
18:10:39 * nirik doesn't care too much, just think it would be good in a more general place.
18:11:04 <tflink> #agreed - 804835 - RejectedBlocker - This is not clearly a bug and no matter what, the desired outcome requires manual setup. Add documentation for the correct way to use multiple grubs and commonbugs for F17 beta
18:11:17 <brunowolff> Well for Beta we want it in common bugs, since people will expect to see issues documented there.
18:11:26 <tflink> nirik: the docs could be in a common place and the commonbugs entry would just point to those updated docs
18:11:40 <nirik> yes, but after it's likely to still be something some subset of people hit.
18:11:43 <nirik> sure.
18:12:03 * adamw got the AVC for the i686 bug
18:13:30 <tflink> nice, does it match the one that kparal mentioned?
18:14:15 <adamw> yeah, he actually filed it as 810447, mine came up as a dupe of that
18:14:20 <adamw> so i made that a dupe of 810451
18:16:58 <tflink> ok, that's it for the proposed blockers
18:17:09 <tflink> sorry for the delay, trying to do too many things at the same time
18:17:36 * adamw pinged mgrepl
18:17:54 <tflink> any objections to going through all the proposed NTH?
18:18:25 <adamw> how many are there?
18:18:37 <tflink> 8
18:18:46 <adamw> eh, sure.
18:18:58 <tflink> #topic (809123) Unable to login to desktop after upgrading to NM-0.9.4-1.git20120328.fc16
18:19:01 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809123
18:19:02 <buggbot> Bug 809123: high, unspecified, ---, dcbw, ON_QA, Unable to login to desktop after upgrading to NM-0.9.4-1.git20120328.fc16
18:19:03 <tflink> #info Proposed NTH, ON_QA
18:19:41 <tflink> +1 nth
18:20:14 <adamw> so, pretty much this is 'Shell crashes if run with NetworkManager disabled
18:20:15 <adamw> '
18:20:42 <adamw> i'd kinda like to fix it, it would be nice if the new NM didn't have a couple of other unrelated commits, though
18:21:22 <tflink> now that I'm thinking harder about this, there was a report of non-bootable install yesterday
18:21:28 <fenrus02> does nm do bridging yet?
18:21:39 <tflink> the reporter didn't seem interested in debugging, though so it's not clear what was going on
18:21:54 <tflink> from what little I saw, I wouldn't rule out NM causing the boot hang
18:22:46 <brunowolff> I think we could live with this being fixed in an update.
18:23:08 <adamw> yeah, that is one point - you're unlikely to disable NM *within a live boot*
18:23:19 <tflink> yeah, good point
18:23:22 <tflink> didn't think about that one
18:23:28 * nirik nods, agrees with brunowolff
18:23:59 <fenrus02> does this affect any other desktop spin?
18:24:54 <nirik> fenrus02: I think it can, but I've not tested it doing so yet.
18:25:01 <nirik> (re: bridging)
18:25:42 <adamw> fenrus02: i don't think so, though the bug is an obvious error in NM code that i guess could theoretically cause other issues
18:25:50 <fenrus02> i saw it was slated for 17, but not completed.  if it is not completed or non-functional, than the desktop needs to work on an installed system without NM.
18:26:30 <fenrus02> livecd - as bruno said, it not likely to have NM removed for any quantity of userbase
18:26:34 <tflink> fenrus02: true but can you think of a reasonable use case where someone would want to disable NM on a live?
18:26:45 <adamw> fenrus02: sure, but if we're talking 'installed system', after updates is fine really
18:26:45 <tflink> yay timing!
18:26:52 * fenrus02 ^5s tflink :)
18:27:49 <tflink> ok, so it sounds like we're pretty much -1 nth on this
18:27:55 <tflink> despite my earlier vote
18:27:56 <brunowolff> -1 NTH
18:28:09 <adamw> yeah, thinking about it, -1/-1
18:28:16 <adamw> let's get the update approved though
18:28:19 <adamw> so it's a 0-day for beta
18:28:31 * nirik nods. -1
18:29:48 <tflink> proposed #agreed - 809123 - RejectedNTH - The use cases affected by this bug are easily fixed as an update
18:30:08 <jskladan> ack
18:30:37 <nirik> ack
18:30:49 <adamw> ack
18:30:57 <tflink> #agreed - 809123 - RejectedNTH - The use cases affected by this bug are easily fixed as an update
18:31:06 <tflink> #topic (809864) unable to yum update because of clutter
18:31:06 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=809864
18:31:06 <tflink> #info Proposed NTH, ON_QA
18:31:08 <buggbot> Bug 809864: unspecified, unspecified, ---, kalevlember, ON_QA, unable to yum update because of clutter
18:31:38 <tflink> this isn't part of the giant gnome update, then?
18:31:57 <kalev> Nope, this one is separate
18:32:05 <adamw> but i think it's fixed in the 3.4 update isn't it?
18:32:07 <fenrus02> yum dist-upgrades are not normally supported ..
18:32:12 <adamw> oh, no, i was thinking of another.
18:32:26 <nirik> well, given that yum update isnt' a supported update method and given that this should be fixed when it goes stable... ?
18:32:28 <tflink> fenrus02: but they're common enough that it's hard to ignore things that break them
18:32:44 <adamw> i think anaconda forces this kind of situation somehow
18:32:46 <jskladan> just a side note:  "Steps to Reproduce: 1. install F15 2. yum upgrade to F17"
18:32:53 <adamw> nirik: comment #6
18:32:54 <fenrus02> adamw, it breaks deps to update
18:32:57 <tflink> wouldn't a yum upgrade pull this in anyways?
18:33:02 <adamw> "I suspect the DVD upgrades with Anaconda might also be affected, so it would be nice to have the fix on the media."
18:33:02 <nirik> we do usually do stable pushes again after beta is go, but before it's released...
18:33:17 <nirik> ah, missed that.
18:33:24 <jskladan> if i remember correctly, we don't support N+2 upgrade, or am I reading the bug wrong?
18:33:27 <nirik> might be nice to know if thats really the case.
18:33:28 <adamw> but like i said, i think anaconda forces this kind of dep issue somehow - i think it just does skip-broken
18:33:29 <fenrus02> also, for yum dist-upgrades, you need to 1) install f15. 2) update f15.  3) upgrade
18:33:46 <adamw> so it may be that it actually works okay
18:34:10 <fenrus02> jskladan, preupgrade and dvd support N+2
18:34:19 <kalev> jskladan: it affects F15->F16->F17 updates the same way, even if you update to F16 as a first step
18:34:21 <fenrus02> jskladan, yum dist-upgrade is not supported at all (in theory)
18:34:30 <adamw> yeah, i think i'm kinda 'i'd like someone to test this with a dvd upgrade and then we'll see' on this one
18:35:00 * nirik nods.
18:35:13 <nirik> also, the clutter update contains some boxes fixes?
18:35:44 <brunowolff> I'm -1 NTH on this. It will be fixed with an update, and people that do yum upgrades pretty always have to deal with a few of these in any case.
18:35:50 <tflink> as long as we don't end up pulling boxes in on this, too
18:36:09 <tflink> I'm thinking pretty much the same thing as adam is on this one
18:36:20 <nirik> well, I'm more worried that the boxes fix will bollox something else...
18:36:21 <tflink> -1 if it doesn't affect DVD upgrades
18:36:36 <adamw> yeah, it's only a possibility if it hits DVD.
18:36:49 <nirik> -1 unless DVD upgrades need it here too.
18:37:03 <fenrus02> DVD or preupgrade really
18:37:14 <fenrus02> -1 if it's only yum-dist-upgrades
18:37:36 <adamw> fenrus02: preupgrade doesn't use media, it's the same case as yum.
18:37:45 <tflink> proposed #agreed - 809864 - Waiting to see if this affects DVD upgrades from 15->17 as well - will revisit after testing
18:38:11 <fenrus02> adamw, not sure about that.  preupgrade force installs some things and does operate very differently than just yum
18:38:34 <jskladan> tflink: ack
18:38:37 <brunowolff> ack
18:38:42 <nirik> ack
18:38:44 <fenrus02> adamw, too many cases where preupgrade fails, but yum dist- works
18:38:56 <adamw> fenrus02: i mean, so far as nth is concerned: preupgrade pulls everything from mirrors.
18:39:00 * fenrus02 nods
18:39:13 <tflink> #agreed - 809864 - Waiting to see if this affects DVD upgrades from 15->17 as well - will revisit after testing
18:39:15 <adamw> so just pushing updates stable is what you need for preupgrade.
18:39:25 <tflink> #topic (803430) [swell-foop] Game is not working
18:39:25 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=803430
18:39:25 <tflink> #info Proposed NTH, ON_QA
18:39:27 <buggbot> Bug 803430: unspecified, unspecified, ---, rstrode, ON_QA, [swell-foop] Game is not working
18:39:41 <kalev> This is fixed by the GNOME 3.4 update
18:39:48 <tflink> -1 NTH
18:39:50 <adamw> so, we can close it.
18:39:54 <nirik> cool.
18:39:55 <tflink> or that, too
18:40:05 <adamw> oh, did releng manage to push it stable yet?
18:40:07 <kalev> it will get closed automatically when this update hits stable
18:40:11 <tflink> #info this has been fixed by the gnome 3.4 update, can close after final verification
18:40:14 <fenrus02> is that update pushed to rc4 ?
18:40:21 <tflink> fenrus02: should be in rc3
18:40:25 <fenrus02> (so that it ends up fixed on livecd)
18:40:30 <nirik> no, I can't get it to push. ;(
18:40:41 <nirik> it will be on produced media tho, as it's in the side repo for composes.
18:40:48 <tflink> oh, I answered the wrong question
18:40:52 <adamw> yeah. so, we can just move on from this one.
18:40:56 <fenrus02> nirik, so it is not found on livecd?
18:41:00 <adamw> yes, it is.
18:41:03 <nirik> yes, it is.
18:41:07 <tflink> #topic (806693) swell-foop missing icon in Applications menu
18:41:08 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=806693
18:41:08 <tflink> #info Proposed NTH, ON_QA
18:41:09 <buggbot> Bug 806693: unspecified, unspecified, ---, rstrode, ON_QA, swell-foop missing icon in Applications menu
18:41:11 <fenrus02> if it is on the livecd, it needs to have hte update
18:41:13 <kalev> This one is fixed with the GNOME 3.4 update as well
18:41:21 <tflink> yeah, just going through them all
18:41:23 <nirik> cool. nice. ;)
18:41:26 <tflink> #info this has been fixed by the gnome 3.4 update, can close after final verification
18:41:37 <tflink> #topic (810104) F17 Beta RC3 live image not bootable via EFI when written to an actual disc
18:41:40 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810104
18:41:41 <buggbot> Bug 810104: medium, high, ---, bcl, NEW, F17 Beta RC3 live image not bootable via EFI when written to an actual disc
18:41:42 <nirik> fenrus02: the gnome 3.4 update has already been pulled in...
18:41:42 <tflink> #info Proposed NTH, NEW
18:41:49 <fenrus02> nirik, awesome
18:42:01 <tflink> +1 NTH
18:42:06 <tflink> this slipped through the cracks, I think
18:42:29 <adamw> yeah, +1 here - fixes for making things EFI bootable are usually pretty isolated and can't break anything else, and it obviously can't be fixed with an update
18:43:05 <tflink> proposed #agreed - 810104 - AcceptedNTH - This fixes several EFI related bugs and can't be fixed as an update post-release
18:43:08 <nirik> +1 NTH
18:43:12 <brunowolff> +1 NTH
18:43:12 <jskladan> ack
18:43:20 <brunowolff> ack
18:43:22 <nirik> ack
18:43:25 <tflink> #agreed - 810104 - AcceptedNTH - This fixes several EFI related bugs and can't be fixed as an update post-release
18:43:34 <tflink> #topic (810039) ntfsresize cannot run in F17 Beta RC3 anaconda because of missing library
18:43:37 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810039
18:43:39 <buggbot> Bug 810039: high, unspecified, ---, bcl, MODIFIED, ntfsresize cannot run in F17 Beta RC3 anaconda because of missing library
18:43:40 <tflink> #info Proposed NTH, MODIFIED
18:44:00 <fenrus02> compose issue, just add the missing so?
18:44:07 <adamw> it's more a case of 'not remove' than 'add'
18:44:14 <tflink> +1 nth
18:44:24 <adamw> i'm +1 as the fix is pretty safe - it's just a change to pungi or lorax (i always forget which) not to strip out the lib
18:44:25 <tflink> not sure we'll get a new lorax build in time, though
18:44:30 <tflink> lorax
18:44:59 <brunowolff> +0 even though it's safe, the use case for beta seems pretty limited
18:44:59 <nirik> +1 nth
18:45:20 <tflink> proposed #agreed - 810039 - AcceptedNTH - This doesn't cause any horrible breakage in the installer but can't be fixed post-release and is a relatively safe fix
18:45:24 <adamw> brunowolff: well, it's 'install alongside windows', which is common enough.
18:45:50 <nirik> there's a non 0 set of early adopters that seem to jump on right at beta it seems like.
18:46:22 <fenrus02> "resize ntfs" is pretty common
18:46:31 <adamw> yeah, it's a reasonably common jumping-on point.
18:46:48 <fenrus02> "beta" is when the big jump happens - media hype, userbase starts etc..
18:46:53 <fenrus02> something magical about the label
18:47:09 <tflink> well, beta is the new final :)
18:47:16 <tflink> all of the cool kids use beta ...
18:47:18 <adamw> heh
18:47:20 <fenrus02> tflink, heh
18:47:28 <brunowolff> Not for me, I switch stuff over at alpha.
18:47:39 <fenrus02> brunowolff, brave :)
18:47:44 <fenrus02> though, someone has to
18:47:53 <adamw> ack
18:48:10 <fenrus02> ack
18:48:13 <tflink> #agreed - 810039 - AcceptedNTH - This doesn't cause any horrible breakage in the installer but can't be fixed post-release and is a relatively safe fix
18:48:24 <tflink> 2 more
18:48:25 <brunowolff> I'll trust you goes have a better idea on how often this and ack the proposal.
18:48:35 <tflink> #topic (810083) dd'ed Fedora 17 Beta RC3 images are not EFI bootable
18:48:35 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810083
18:48:35 <tflink> #info Proposed NTH, NEW
18:48:37 <buggbot> Bug 810083: medium, unspecified, ---, dennis, NEW, dd'ed Fedora 17 Beta RC3 images are not EFI bootable
18:48:56 <adamw> same as the other efi issue, really
18:48:59 <tflink> isn't this a dupe of 810104?
18:49:04 <adamw> well, not the same cause, but same situation
18:49:05 <fenrus02> anything that affects efi boot is not fixable via update really
18:49:06 <adamw> bcl says no
18:49:22 <adamw> this affects DVD/netinst too, which aren't built with livecd-creator, so it must be some other reason
18:49:29 <brunowolff> +1 NTH
18:49:46 <tflink> oh yeah, forgot the live/dvd change
18:50:05 <tflink> I thought we fixed this,though - something about a tool not being run during pungification
18:50:10 <tflink> either way +1 NTH
18:50:25 <adamw> basically with rc3, only EFI bootable cases are 'anything written with livecd-iso-to-disk' and 'DVD / netinst written to shiny silver disc'
18:50:39 <adamw> any dd'ed image isn't EFI bootable, and lives are not EFI bootable if written to disc
18:51:03 <adamw> +1
18:52:01 <tflink> proposed #agreed - 810083 - AcceptedNTH - The DVDs should be EFI bootable when dd'd and this can't be fixed post-release with an update
18:52:03 <nirik> +1 NTH
18:52:12 <fenrus02> +1
18:52:21 <jskladan> ack
18:52:23 <brunowolff> ack
18:52:47 <nirik> ack
18:52:49 <tflink> #agreed - 810083 - AcceptedNTH - The DVDs should be EFI bootable when dd'd and this can't be fixed post-release with an update
18:52:56 <tflink> #topic (805017) Segmentation fault in anaconda when switching TTYs
18:52:56 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=805017
18:52:56 <tflink> #info Proposed NTH, ASSIGNED
18:52:57 <buggbot> Bug 805017: high, unspecified, ---, airlied, ASSIGNED, Segmentation fault in anaconda when switching TTYs
18:53:55 <brunowolff> I'm still +0 NTH on this one.
18:54:56 <brunowolff> But I'm not a big VM user due to ancient hardware.
18:54:59 <fenrus02> i dont see how this is an anaconda issue. just fix in updates?
18:55:09 <adamw> fenrus02: well, the nth case is live images
18:55:16 <adamw> if we fix it in updates it'll always be broken in beta live images
18:55:20 <adamw> but...meh. i'm not married to it.
18:55:47 <fenrus02> adamw, it looks to me like a simple qxl driver issue - unrelated to any installer or livecd
18:56:06 <tflink> fenrus02: but the qxl driver is baked into the livecds
18:56:08 <nirik> do we have a fix in hand?
18:56:29 <tflink> I don't think so
18:56:35 <adamw> nope. i doubt it's getting fixed in time anyway.
18:56:42 <adamw> but in theory, that doesn't affect evaluation of nth status.
18:56:46 <nirik> yeah, don't see one. I guess I'm +1 NTH, but doubt it will make it. ;)
18:57:14 <jskladan> nirik: ^^
18:58:06 <tflink> proposed #agreed - 805017 - AcceptedNTH - This could create some messy issues on the lives and in that case, can't be fixed by an update
18:58:08 <nirik> although... if the fix turns out to be invasive, it could mess up other things, it's hard to say.
18:58:11 <tflink> ack/nak/patch?
18:58:25 <tflink> nirik: we don't have to pull it in if its marked NTH
18:58:33 <nirik> true.
18:58:35 <nirik> so, ack
18:58:42 <tflink> we can always revoke NTH-ishness if it looks like it'll be a problem
18:58:47 <adamw> ack
18:58:59 <adamw> and we can make a game-time decision not to pull an NTH fix that looks too messy, too.
18:59:23 * nirik nods.
19:00:01 <tflink> #agreed - 805017 - AcceptedNTH - This could create some messy issues on the lives and in that case, can't be fixed by an update
19:00:09 <tflink> OK, that's it for the proposed NTH
19:00:17 <tflink> We still have 2 accepted blockers
19:00:25 <tflink> but they should be quick
19:00:33 <tflink> #topic (810005) network installs fail due to incorrect parsing of command line parameters
19:00:36 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810005
19:00:38 <buggbot> Bug 810005: urgent, unspecified, ---, anaconda-maint-list, MODIFIED, network installs fail due to incorrect parsing of command line parameters
19:00:38 <tflink> #info Accepted Blocker, MODIFIED
19:00:51 <tflink> I did a PXE boot with a test image, so this appears to be fixed for the PXE case
19:01:01 <tflink> I'm getting set up for a preupgrade test, too
19:01:04 <fenrus02> fixed in rc4 then hopefully :)
19:01:08 <tflink> but that's the next bug
19:01:16 * jskladan as always, 9PM seems to be a good time to go home on friday ;) see you around on monday, gang!
19:01:34 <tflink> jskladan: isn't monday a holiday for you?
19:01:42 <adamw> night jskladan!
19:01:49 <tflink> jskladan: thanks for coming!
19:01:55 <adamw> yup, this should be fixed.
19:02:03 <jskladan> tflink: aaa, holiday! I forgot, that would be weird monday in empty office :D
19:02:25 <tflink> #info this should be fixed with anaconda-17.19-1, initial tests verify fix
19:02:41 <tflink> #topic (810391) During preupgrade, anaconda tries to mount target system's /boot partition after dracut has already done so
19:02:44 <tflink> #link http://bugzilla.redhat.com/show_bug.cgi?id=810391
19:02:45 <buggbot> Bug 810391: urgent, unspecified, ---, anaconda-maint-list, MODIFIED, During preupgrade, anaconda tries to mount target system's /boot partition after dracut has already done so
19:02:46 <tflink> #info Accepted Blocker, MODIFIED
19:03:00 <tflink> #info this should be fixed by anaconda-17.19-1
19:03:09 * tflink is in the process of a quick smoke test
19:03:30 <tflink> obviously, we would need to do a real preupgrade test before closing it
19:03:44 <tflink> but it would be nice to see if there are other potential issues lurking before we request RC4
19:04:02 <adamw> well, we need to get the i686 live crash thing fixed too.
19:04:02 <tflink> #action tflink to run a preupgrade smoke test before RC4 is requested
19:04:04 <adamw> since we took it as a blocker.
19:04:42 <tflink> true but I wasn't trying to imply that this is the only issue
19:04:53 <tflink> just one of the more annoying ones to test :)
19:05:18 <tflink> any other thoughts on this?
19:05:34 * tflink assumes not
19:05:44 <tflink> ok, that would be all the bugs I'm seeing
19:05:48 <tflink> did I miss anything?
19:06:06 <kalev> I forgot to mention something earlier at the clutter DVD upgrade NTH discussion
19:06:12 <kalev> < nirik> well, I'm more worried that the boxes fix will bollox something else...
19:06:17 <kalev> there are actually two different clutter builds: clutter-1.10.0-3 adds the obsoletes to make upgrades work, and clutter-1.10.0-4 has obsoletes + the boxes layout fix
19:06:24 <nirik> yep.
19:06:46 <nirik> so we could pull the -3 only, but it's not got an update currently as the -4 one obsoleted it.
19:06:47 <tflink> ok, so pulling in the -3 build should have no affect on boxes?
19:07:23 <kalev> yes
19:07:43 <brunowolff> Didn't boxes get taken out of comps?
19:07:53 <adamw> yes.
19:07:56 <tflink> I suppose that this would have made more sense as
19:08:00 <tflink> #topic open floor
19:08:18 <tflink> #info the clutter-1.10.0-3 build does not include any fixes for boxes
19:08:38 <tflink> #undo
19:08:38 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2f7f3310>
19:08:52 <nirik> to be clear, I'm not worried about boxes. I'm worried about the changes to clutter for fixing boxes would affect something else that uses clutter. ;)
19:09:06 <tflink> #info the clutter-1.10.0-3 build does not include any fixes for boxes but has no update because it is obsoleted by clutter-1.10.0-4 which does contain boxes-related changes
19:09:18 <brunowolff> So are we worried that the fixes for boxes might break something else even if boxes isn't installed?
19:09:30 <tflink> yeah, a little
19:09:32 <nirik> that was my concern/.
19:09:56 <nirik> I don't know how big a concern it is... but it would sure be not nice to pull it and break something.
19:10:37 <kalev> the Boxes fix isn't important to have on media anyway, since Boxes got taken out and is thus easily fixable by updates
19:10:56 <brunowolff> Yeah. I don't know what the changes are like, so I don't have an opinion of how risky they are. I just wanted to make sure I understood what the concern was about.
19:11:15 <tflink> but we might want to be careful about pulling in -3 to RC4
19:11:24 <tflink> can obsoleted updates be pushed to stable manually?
19:11:46 <nirik> no.
19:11:53 <tflink> darn
19:11:55 <nirik> you have to unpush the newer one and resubmit the old one.
19:12:04 <tflink> wouldn't that get messy?
19:12:54 <brunowolff> That doesn't seem like that big of a deal. It seems better than making a new build without the latest changes.
19:13:40 <adamw> regardless, i think we need to find out if there's actually nay problem with a dvd upgrade first.
19:13:42 * adamw runs one
19:13:43 <tflink> either way, it's something to keep in mind
19:13:46 <nirik> not too messy, just unpush, resubmit, get karma, get stable, resubmit old one.
19:13:46 <tflink> true
19:14:02 <tflink> I was thinking more for users that already have it installed
19:14:06 <tflink> but either way
19:14:24 <tflink> I have one other question - did we ever figure out the whole "no sugar on DVD" thing?
19:14:35 <brunowolff> It will show up as an orphan for them for a little bit.
19:15:00 <nirik> tflink: yes, it's never been on the dvd...
19:15:17 <nirik> but something in it's comps group is now, so it appears as a group in anaconda.
19:15:18 <tflink> nirik: thanks, just found the bug
19:15:24 <nirik> I think we just were going to add it to the dvd.
19:15:26 <adamw> we pulled it into rc3 dvd, though.
19:15:27 <adamw> we did.
19:15:31 * nirik nods.
19:15:44 <tflink> we should probably patch spin-kickstarts, though :)
19:15:46 <adamw> i didn't test whether installing it from dvd actually works, but eh
19:15:59 <tflink> patch/update
19:16:39 <tflink> ok, I think that's it
19:16:51 <adamw> i'll update the clutter bug in the comments and we can vote there
19:16:59 <tflink> sounds like a plan
19:17:00 <adamw> rc4 is awaiting a fix for the i686 crash
19:17:16 <tflink> #info RC4 is waiting for a fix for the i686 live crash
19:17:47 <tflink> #info There is currently no blocker review meeting scheduled for next week, will be scheduled if beta slips
19:18:00 * tflink sets fuse for ~3 minutes
19:19:19 <tflink> close enough
19:19:27 <tflink> Thanks for coming everyone!
19:19:34 * tflink will send out minutes shortly
19:19:36 <tflink> #endmeeting