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