15:00:55 #startmeeting Fedora QA meeting 15:00:55 Meeting started Mon Aug 27 15:00:55 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:58 #meetingname fedora-qa 15:00:58 The meeting name has been set to 'fedora-qa' 15:01:13 morning, folks, who's here for some QA? 15:01:19 #topic roll call 15:01:26 * tflink is here 15:01:48 * maxamillion is here 15:02:32 * spoore is here 15:02:38 * brunowolff is here for about 25 minutes 15:03:03 * nirik is lurking in the back 15:03:35 alrighty 15:03:50 #topic Incomplete anaconda functionality for Fedora 18 15:04:11 so, in case anyone missed it, i filed a fesco ticket: https://fedorahosted.org/fesco/ticket/941 15:04:53 anaconda team said that live install functionality will not be in place for alpha on current schedule, which is obviously an infraction of the release criteria 15:05:36 the ticket was updated ~ 20 minutes ago to say that there is code, but it has had 0 testing and beta is a more realistic target 15:05:48 i outlined the possible responses in terms of shipping Alpha in the ticket...for this meeting, the idea is to air the issue and see if we want to provide any input/recommendations as a team 15:06:35 adamw: is there really any options or input/recommendations we can offer? if its not ready, its not ready .... its possible I'm misunderstanding, but I don't know that there's anything we can really do 15:06:37 also that lmc is working and has been working for the most part (aside from a small window) to the best of bcl's knowledge but I don't think that's the issue right now for lives in composes 15:07:44 maxam_: well, for instance, we could say we as a team feel as viking_ice does - that the release should get a substantial slip because anaconda's just not ready, and this is only one symptom of that 15:08:10 ah 15:08:19 * nirik notes one more week slip puts us in US thanksgiving week. 15:08:26 heh 15:08:33 this should be good 15:08:53 tflink: the issue is that it's not integrated into koji and usable by releng for doing official composes. you can run it, and produce a live image. but releng really want to be able to run it through koji, in a completely clean environment, for reproducibility. 15:09:15 like I said, I don't think that lmc working or not is the issue ATM 15:09:23 we haven 15:09:36 maxamillion: or we could say that we don't think it's such a major issue, and we think we should go ahead on current schedule and ship non-installable lives 15:09:59 we haven't touched the matrices much yet, I doubt that one more week is going to be enough at this point even if we decided to release alpha w/o live install 15:10:04 maxamillion: that kind of thing...just do we, with whatever experience/wisdom we have as qa, have a strong feeling about which way fesco ought to jump on the question 15:10:07 non-installable live images would completely negate the spins project 15:10:26 I don't think that should be considered an option 15:10:41 er, when i say 'ship', i mean for alpha; obviously the plan would still be for them to be installable at beta and final. 15:10:50 ah 15:10:53 I think for alpha just being able to run them live is enough. We don't even produce all of the live images for alpha and beta. 15:11:09 even if we went the route of pushing off newui until F19, I wonder if all of the tooling would be updated fast enough to make that work this week 15:11:14 ok, I misunderstood the impact 15:11:26 not to mention the delay and extra work for the anaconda devs 15:12:19 I don't think newui should be pushed off until F19, I think if anything that F18 just needs to be slipped further out .... but I'm not entirely convinced that's necessary 15:12:55 tflink: yeah, i don't think 'go with oldui' is a good plan to keep us on the current schedule, but it's a possible 'cut the losses' plan if we think newui is just terminally not cooked yet and this problem is just one symptom 15:13:01 How far are people willing to slip the F18 release for the new anaconda? 15:13:10 i think johann's right in that we need to consider the wider question of newui's overall readiness here 15:13:12 maxamillion: I still think that finishing the matrices this week is practical 15:13:23 s/is/is not/ 15:14:12 I don't think that attempting to dictate a schedule or goal for the anaconda team is entirely realistic, wouldn't switching back to oldui for F18 be a considerable amount of work at this poitn? 15:14:16 point* 15:14:25 brunowolff: are you asking us for our opinions, or wondering how others outside qa would feel about that? 15:14:42 Wondering more about outside people. 15:14:47 maxam_: yes, it would. it's not a free action. 15:15:04 adamw: your tab completion doesn't like me ;) 15:15:11 heh 15:15:23 adamw: my question to that would be "is the anaconda team even willing to do that?" 15:15:25 maxamillion: I'm not familiar enough with the anaconda code for details, but I'd be surprised if it wasn't very expensive - at least a week delay if they went along with it 15:15:37 I think in with defer anaconda we can probably guess how far we need to slip (probably 1-2 more weeks). If we try to stick with the newui, things seem a lot more unknown. 15:15:38 maxamillion: if fesco told them to do that, they wouldn't have a choice, i guess... 15:16:12 brunowolff: yeah, that's probably the most significant benefit of the oldui option. 15:17:42 personally, i'm not a huge fan of the oldui idea, to be honest 15:17:56 i do think that from a qa angle, the mandated slip option has a lot of things to like 15:18:24 I'm not a fan of the oldui option either 15:18:25 to me it feels like newui really is rather behind, and this isn't the only sticky problem we're likely to hit if we keep trying to keep to the schedule and doing one-week slips while we firefight 15:18:47 if we go the mandated slip route, would we lift freeze for a bit? 15:18:57 yeah, that's the key question with that option, what to do about the freeze 15:19:22 if we lift it we introduce opportunities for instability, if we don't lift it then we're frozen for an awful long time and have a huge dump on unfreeze 15:19:30 * tflink is of the opinion that if we're slipping another 2-3 weeks, we should lift freeze for at least a week 15:19:38 It would be nice for rawhide users to lift the freeze. Some updates don't get to rawhide otherwise. 15:19:42 adamw: any more instability than we already have? 15:19:50 the other option would be to pull certain big updates through the freeze - like gnome, for instance 15:19:54 tflink: yeah. 15:20:35 I guess I don't see much point in keeping the freeze that long since it would delay and frustrate other developers when we're going to be waiting a while for anaconda anyways 15:21:12 so yes, it might introduce instability but avoiding said instability is going to come at a cost in frustration and annoyance from devs and possibly users 15:21:26 is it worth holding everyone else back because we're waiting for anaconda? 15:21:40 what's everyone else's feeling on the wider question? who's got alarm bells ringing about how well things will come out if we keep on the planned schedule, and who's relaxed? 15:22:17 adamw: I don't like the idea of selectively pulling big updates like gnome through because you're going to have a slippery slope of upset folks who think their updates need in vs. others 15:22:19 I also have some soname rebuilds waiting for a library update to clear testing. Probably some others are in this situation. 15:22:28 maxamillion: yeah, that option could get political. 15:22:44 see, this is the problem with qa, you're all too damn even-handed 15:22:46 adamw: political/flamey 15:23:01 lol 15:23:22 I suggest talking to anaconda and get an estimate for when they can reasonably be ready for alpha and look at doing a multiweek slip to accommadate tham or falling back to the oldui. 15:23:24 we should make fesco a recommendation that causes maximum inconvenience to developers and it's fesco's job to come up with a compromise that disappoints everyone! that's how rule by committee is meant to work! 15:23:32 The final call there wouldn't be our decision. 15:24:12 I think it depends on how hard we're pushing to get the matrices completed - I sincerely doubt that we're going to be ready with only 1 week more slip and I see little value in re-evaluating so often 15:24:40 adamw: I think this is mostly a side effect of the fact that almost everyone here wears many hats and everyone tries to think about it from the viewpoints they have to entertain while wearing their non-qa hat ;) 15:24:47 tflink: when you say 'completed'....we aren't required to run every test for alpha, just all the alpha-level tests 15:24:58 s/hat/hats 15:24:58 we try to do them all, but we can sign off on a release with just the 'alpha' tests completed 15:25:30 true, still not convinced of the wisdom of slipping only one more week at this point 15:26:07 if we keep freeze, 2 weeks might be enough. if we lift freeze, I bet it would be more like 3 15:26:28 yeah, that was my thinking about that line too 15:26:57 if we're going to lift freeze, we should do it soon 15:27:42 so it sounds like no-one really feels strongly enough about any one option for us to come down as a team behind it and say 'this is what we recommend', but we can say there's some options we definitely don't like...does that sound like a reasonable summary? 15:27:44 Is FESCO not meeting this week? It might be hard to get a quick response from them. 15:28:02 brunowolff: yeah, LPC is a problem. they're discussing the issue in the ticket rather than meeting. 15:28:54 adamw: I think that slipping week-by-week is a bad idea 15:28:58 it sounds like we're not keen on going back to oldui, and though it would cause us as a team no problems, we're not too keen on a mandated slip without a freeze lift 15:28:58 I think we can say we don't think one week is going to be enough whichever way we go with ananaconda. 15:29:21 tflink: it sounds like, by elimination, you'd prefer to do a planned long slip with a freeze lift. 15:29:37 There seems to be at least some sentiment amoung the group if we are going to slip 2+ weeks, we should have a short unfreeze period. 15:29:42 yeah. 15:30:06 adamw: planned longer slip - definitely. probably a freeze lift too but I don't feel as strongly about that part 15:30:09 I need to go to a work meeting. 15:30:09 * nirik notes this gets us into december for release... unless we somehow shorten something else. 15:30:43 I suppose we could just skip alpha altogether but I'm not sure that's a great idea 15:31:20 * nirik would not like that... if we wanted to think that way, a alpha with non installable live media would be much better. 15:31:22 * adamw trying to synthesize a list of recommendations for people to vote on 15:32:32 adamw: split them up into separate items? revert to pre-newui, slip more than one week, lift freeze 15:32:40 ? 15:32:42 tflink: yeah, that's what i'm doing 15:33:27 so far i've got this 15:33:33 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30. 15:33:36 2. We don't believe that reverting to oldUI is a great idea. 15:33:39 3. We are generally of the opinion that a planned slip longer than 2 weeks should be accompanied by a period where the release freeze is lifted. 15:34:22 if those work, i'm wondering whether to add a '4. We favour the option of a 3 or more week slip with a 1 or more week freeze-lift period', or just leave it as-is, where that's more or less implied 15:34:32 or if we should water it down a bit 15:34:39 thoughts? 15:35:40 how many of the anaconda devs are at LPC? 15:35:50 my impression was basically everyone but jesse 15:35:56 jesse said something about being left holding the can 15:36:30 then I'd be more for the 3 or more week slip 15:36:40 if they're mostly at LPC, I don't think this week counts 15:37:14 +1 15:37:22 which could possibly give releng enough time to get lmc working in koji 15:37:40 * adamw is clarifying in #anaconda at present 15:38:51 well, part of the problem with lmc in koji is that it assumes you want to use libvirt and such... and it's 'script' interface doesn't work. 15:39:40 okay, so lpc is not as much of a problem as we thought 15:39:50 dcantrell, pjones and bcl are the ones out 15:41:35 so in theory we can get builds this week; still, jkl appears to be still tracing out the consequences of that showstopper we've been stuck on for a week. 15:41:42 * nirik notes also that fesco doesn't meet this week, so we will need to push to get votes/action in ticket, which can sometimes be challenging. ;) 15:42:05 so best case: 1 week slip probibly? 15:42:06 it would be nice for fesco to make a decision by thursday, tbh. 15:42:29 yeah, we're almost baking in another slip at this point, unless we all think the next anaconda build will be the magic one which hits all release criteria. 15:42:34 if you believe that, i've got this bridge for sale... 15:43:13 * nirik nods 15:43:36 * tflink thinks that one more slip is a bit on the optimistic side 15:43:45 but then again, I'm a bit of a cynic 15:43:53 =) 15:44:09 s/cynic/realist/ 15:44:18 i agree, but then, even if we do a planned slip at this point it doesn't rule out more slips at beta and final. we have issues with uncertainty here :/ 15:44:23 granted, they are basically synonyms these days 15:44:31 does anyone want to take a shot at better recommendations than my three? or shall we just go with those? 15:44:59 I'm good with those 15:45:02 brb ... in dire need of more coffee 15:45:17 I'm in favor of adding your #4 15:45:39 I doubt that will be the option chosen, but it makes #3 seem less drastic 15:45:47 hah. you're a politician too. 15:46:24 in my experience, choosing release dates has more to do with politics than anything, anyways 15:46:26 ok, let's make it all official, two parts seems like it'd be best 15:46:44 first: propose #agreed we submit the three recommendations drafted above to the fesco ticket 15:46:53 vote! 15:46:59 what about the 4th? 15:47:22 that's the second proposal 15:47:30 i figured this one will go through easy, it's just a prelim 15:47:34 then we vote on taking the 4th =) 15:47:47 ok, just checking before voting 15:47:49 +1 15:48:31 who else is alive 15:49:04 brno folks are away until wed 15:49:16 I think we lost everyone else, too 15:49:19 :( 15:49:25 nirik was still soldiering on until two minutes ago 15:49:34 I think that maxamillion will be back in a minute or so 15:49:37 but i guess he finally couldn't take the qa jungle heat any mor 15:49:38 e 15:49:41 he said something about coffee 15:49:42 ha. 15:49:45 speaking of... 15:50:23 I think your 1-3 are reasonable... 15:50:32 ok, so that's a +1 15:50:35 one of the other interesting side effects of a long slip is the time between F18 and F19 15:50:41 * adamw waits for maxam 15:50:44 tflink: yep. 15:50:54 yeah, i don't think we have to consider all those implications though, that's a fesco/board job i guess. 15:50:58 the next cycle will need to be shorter, or move our 'traditional' dates. 15:51:26 back 15:51:35 got a vote on proposal #1? 15:52:00 +1 15:52:05 ok 15:52:13 #agreed we submit the three recommendations drafted above to the fesco ticket 15:52:32 adamw: you might want to #info those so that they show up in minutes 15:52:33 propose #agreed we submit the proposed fourth recommendation, moderately in favour of a longer slip with a freeze lift 15:52:46 tflink: oh yeah. 15:52:55 probably before the agreed 15:52:59 #undo 15:52:59 Removing item from minutes: 15:53:13 #info for the record, the recommendations are: 15:53:25 #info 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30. 15:53:32 #info 2. We don't believe that reverting to oldUI is a great idea. 15:53:44 #info 3. We are generally of the opinion that a planned slip longer than 2 weeks should be accompanied by a period where the release freeze is lifted. 15:53:52 #agreed we submit the three recommendations drafted above to the fesco ticket 15:54:02 * rbergeron also notes we are running into holidays, etc., particularly thxgiving in the us ... sorry to just drop in 15:54:26 propose #agreed we submit the proposed fourth recommendation: "4. We favour the option of a 3 or more week slip with a 1 or more week freeze-lift period" 15:54:33 +1 15:54:38 rbergeron: i mostly think that's for fesco to consider rather than us 15:54:44 +1 15:54:44 * rbergeron nods 15:54:47 rbergeron: one week slip gets us in thanksgiving week. More than that gets into december 15:54:53 yep 15:54:56 we're not deciding the issue, just providing an official qa recommendations 15:55:04 recommendation* 15:55:05 Fedora: X-Mas Edition ... >.> 15:55:06 assuming that we don't slip for beta or final, either 15:55:08 errr 15:55:11 Fedora: Winter Edititon 15:55:14 tflink: hahahahahaha 15:55:18 :D 15:55:20 Winter Solstice Edition 15:55:24 :) 15:55:28 * tflink has visions of a spherical cow w/ a santa hat in his head 15:55:36 s/his/its/ 15:55:44 and a gift containing a snake 15:55:44 that would be *awesome* 15:55:45 nirik: what's your feeling? 15:56:06 I'm not sure I favor that personally. ;) 15:56:30 the recommendation, the santa hat, the snake, or all three? :) 15:56:31 I'm not sure I like the idea, either. I just think it's the best option at this point 15:56:42 if we could do 1 or 2 weeks slip, IMHO I would find that better... 15:56:52 but not sure how likely that will be 15:57:49 suppose that depends on how likely you are to accept that miracles are a reality 15:57:51 so that feels like 2 +1s and a -0.5 15:58:07 probably not strong enough to pass on such a strong point as representing the team 15:58:20 we're missing a lot of people, too 15:58:30 of course, the +1s could state their personal opinions in the ticket. so maybe we should just go with that. 15:59:31 ok, are we all talked out or does anyone want to kick the can some more before we go into good ol' blocker review mode 15:59:32 ? 15:59:47 or wait until we have more people before suggesting #4? 16:00:05 i don't think any more people are going to show up to this meeting 16:00:05 that'll take me a minute to get ready. I'm not sure why it keeps catching me by surprise 16:00:22 I didn't mean at the meeting 16:00:27 does the anaconda team have a fairly firmed up list of "what's left" at this point? 16:00:31 we could always bring it up again next week if the ticket is still open, but that would be a problem in itself 16:00:36 tflink: i can float it on the list for sure, 16:00:54 rbergeron: i'm not sure they have an official one, that's one thing jreznik is pushing for, which i'd agree with 16:01:13 the next big pain point is the upgrade code, i suspect. 16:01:34 that will likely be our big ass-kicker at beta point. 16:02:06 #action adamw to float proposed recommendation #4 on the mailing list and add it to the ticket if it gets sufficient support 16:02:34 me too, just to be more specific about what other milestones are, how likely those are... seems silly to delay for one aspect of the feature if the rest will also turn into need-another-2-weeks :/ 16:02:42 * rbergeron shuts up now :D 16:03:12 rbergeron: fesco should definitely consider that if they plump for the planned slip option, yeah. we would definitely want to try and make it the only slip, that would be the idea. 16:03:24 so try and pin anaconda team down to how far behind they are and how much time they need to be really on top of things. 16:03:37 include upgrade code, too 16:03:43 * tflink wasn't thinking about that yet 16:03:55 i'd ideally want the slip to be long enough that they would have all the required features *written* by the end of the slip, and we'd be spending the rest of the cycle just testing them, as it should be. 16:04:03 adamw: and if you guys have concerns re: any other specific aspects of testing - that is useful to have in the ticket 16:04:05 this whole 'writing the code as we validate it' thing is not working out too well. =) 16:04:25 i would think anyway 16:04:31 rbergeron: roger 16:04:33 * rbergeron = not in fesco obviously 16:04:36 :D 16:04:40 but your very word is law 16:04:43 LAW 16:05:12 lame and womanly? large and waffles? 16:05:23 * rbergeron hangs out for blockers 16:05:28 your very word is waffles? 16:05:37 not sure what that means :) 16:05:38 oh, should we throw in a different #4 - that we agree with jaroslav that it would be a really good idea to get a specific list from anaconda team of what's written, what still needs writing, and what isn't going to be written? 16:06:05 or is that too much fiddling? 16:06:10 probably not necessary.... 16:06:22 okay, ignore me. let's blocker review. 16:06:26 i think nobody will disagree :D 16:06:37 I think it would be nice to see 16:06:47 #topic Fedora 18 Alpha mini blocker review 16:06:56 tflink: i'll just throw it in as 'deep background', easier that way. 16:07:13 adamw: can you #chair me? 16:07:25 #chair tflink 16:07:25 Current chairs: adamw tflink 16:07:29 #chair rbergeron 16:07:29 Current chairs: adamw rbergeron tflink 16:07:45 * tflink is planning to just do the proposed blockers and NTH today 16:07:55 #info 8 Proposed Blockers 16:08:04 #info 2 Proposed NTH 16:08:09 yeah, we're over time already 16:08:10 starting with the proposed blockers ... 16:08:16 we'll probably have to move into -1, unless we're quick. 16:08:28 fesco isn't meeting today 16:08:32 #topic (851212) error: cannot invoke setopt() - perform() is currently running 16:08:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=851212 16:08:37 #info Proposed Blockers, POST 16:09:11 oh right, it's fesco that always kicks us out. 16:10:13 I'm not sure about blocker on this but +1 nth 16:10:31 well, a crash at the language selection screen is bad news 16:10:36 true 16:10:44 but is an intermittant crash a blocker for alpha? 16:11:03 yeah, probably needs more data 16:11:15 if other people start hitting it then i'd be +1 16:11:20 +1 nth for sure 16:11:30 are you -1 blocker or punt? 16:11:47 nth/more data 16:11:50 sounds like #851207 might be masking more occurances, though 16:11:53 punt 16:12:26 roger 16:12:28 hi andre 16:12:32 we're just cranking up blocker review 16:12:44 i'm fine with accept as NTH, punt on blocker 16:13:13 proposed #agreed 851212 - AcceptedNTH - This sounds kind of nasty but we need more data on how often it happens before deciding on blocker status for F18 alpha. More crashes could be masked by #851207. 16:13:20 +1 16:13:20 ack/nak/patch? 16:13:54 ack 16:14:17 ack 16:14:20 #agreed 851212 - AcceptedNTH - This sounds kind of nasty but we need more data on how often it happens before deciding on blocker status for F18 alpha. More crashes could be masked by #851207. 16:14:31 #topic (851220) EFI syslinux contains wrong path to kernel pair 16:14:32 #link https://bugzilla.redhat.com/show_bug.cgi?id=851220 16:14:32 #info Proposed Blockers, ASSIGNED 16:15:31 multibug :D 16:16:10 +1 blocker 16:16:29 Entertainingly mistitled 16:17:02 proposed #agreed 851220 - AcceptedBlocker - Violates the following F18 alpha release criteria for EFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:17:06 ack 16:17:08 I bet that's too long, again 16:17:15 nope, that one made it. 16:17:25 ack 16:17:27 cool, I should really figure out the max chars that can be in one line 16:18:11 510 16:18:40 can vary by server though also :D 16:18:44 ack 16:18:46 #agreed 851220 - AcceptedBlocker - Violates the following F18 alpha release criteria for EFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:18:55 rbergeron: sounds like you've hit this in the past :) 16:19:02 the # of chars thing, I mean 16:19:13 tflink: yes, but google is also awesome 16:19:15 #topic (849982) The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3 16:19:18 #link https://bugzilla.redhat.com/show_bug.cgi?id=849982 16:19:20 #info Proposed Blockers, NEW 16:19:36 rbergeron: you mean that I should have googled for the answer to my question? That sounds like too much work :) 16:19:44 oh, right, we punted this to talk to design team. then, er, did anyone talk to design team? 16:19:47 i didn't. oops. 16:20:11 yeah, I was wondering about that too 16:20:15 punt until wed? 16:20:36 AFAIK, we still don't have an installable gnome DE 16:21:01 re-punt, if no-one got new info. 16:21:46 #info still waiting on information on or conversation with artwork/design team, will re-evaluate at next blocker meeting if new information is available 16:22:04 #topic (851207) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist 16:22:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=851207 16:22:09 #info Proposed Blockers, NEW 16:23:01 this sounds like blocker for me 16:23:14 how does it differ from 851212? 16:23:21 just cos he saw this one twice? :) 16:23:49 sounds like a lock versus wrong method issue 16:23:52 to me, at least 16:24:14 wrong method/improper call 16:24:25 oh, man, you're going to get all technical on me?! 16:24:38 ok, seriously, fair point 16:25:01 "The installer must be able to complete package installation with the default package set for each supported installation method"? 16:25:03 ah, more ipv6 stuff, looks like 16:25:08 from the tb anyhow 16:25:10 adamw: maybe he would have seen it a third time if he hadn't hit 851212? 16:25:17 pick a criterion. that one works. 16:25:22 rbergeron: yeah, it kinda looks that way. 16:25:54 * rbergeron suspects kamil might just be underscoring the fact that workaround isn't an option 16:25:55 proposed #agreed 851207 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:26:06 ack 16:26:23 ack 16:27:18 #agreed 851207 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:27:37 #topic (851295) splitsep doesn't correctly handle variables with escaped spaces 16:27:40 #link https://bugzilla.redhat.com/show_bug.cgi?id=851295 16:27:43 #info Proposed Blockers, MODIFIED 16:28:16 pretty clear blocker 16:28:49 proposed #agreed 851295 - AcceptedBlocker - Violates the following F18 alpha release criterion for USB media: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:28:50 it'd help to have a less cryptic explanation of this, in a way, but it does sound like it can break lots of things 16:29:02 I think it breaks USB media mostly 16:29:30 if it does in fact break usb i'm happy with that criterion 16:29:52 IIRC, litd specifies stage2 which doesn 16:29:59 t work when the path gets mangled 16:30:11 i thought at present litd wasn't appending any parameters 16:30:13 but imbw there 16:30:32 makes 2 of us, I could easily be wrong on my understanding 16:30:49 meh, we're way behind anyhow 16:30:56 let's just take it on that basis and we can modify later if needs be. 16:30:57 but I suppose that it would break network isntalls if it doesn't break USB 16:31:01 ack then 16:31:10 yeah, it's really just a case of which criterion we go for. 16:31:24 although, that might make it beta. eh. 16:31:31 #agreed 851295 - AcceptedBlocker - Violates the following F18 alpha release criterion for USB media: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:31:50 I thought that we needed at least 1 of ftp/http at alpha 16:32:03 nvm, different wording 16:32:12 well it'd only be a problem if you specify a repo on the kernel command line, aiui. 16:32:17 not if you do it interactively. 16:32:25 yeah, it's more of a PXE issue 16:32:25 oh well, move on! 16:32:27 yep 16:32:45 #topic (851274) Traceback during install - mount: /dev/sr0 is already mounted or /run/install/repo busy 16:32:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=851274 16:32:47 #info Proposed Blockers, ASSIGNED 16:33:13 we never acked this yet? 16:33:19 well, +1, obviously. 16:33:24 yep, same here 16:33:33 "The installer must be able to complete package installation with the default package set for each supported installation method"? 16:33:59 * jreznik is reading backlog 16:34:28 proposed #agreed 851274 - AcceptedBlocker - Violates the following F18 alpha release criterion for netinstall images: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:34:32 ack/nak/patch? 16:34:59 ack 16:35:38 #agreed 851274 - AcceptedBlocker - Violates the following F18 alpha release criterion for netinstall images: "The installer must be able to complete package installation with the default package set for each supported installation method" 16:36:06 #topic (851500) UEFI boot: failure reading sector 0x40 from `cd0'. 16:36:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=851500 16:36:06 #info Proposed Blockers, NEW 16:37:05 hrm, not sure there's enough info here yet 16:37:16 the later comments make it sound like a bit of an obscure problem 16:38:05 yeah, i'm -0.5 on this 16:38:24 I guess the question comes down to punt or reject? 16:38:42 i think reject and ask him to file the kernel panic 16:38:59 I've got a patch for 851500 16:39:13 Ah, it's even uploaded already 16:39:28 mjg59: are the 'failure reading' error message and the kernel panic connected? 16:39:33 Yes 16:39:33 that's the key question here 16:39:40 The kernel panics because there's no initramfs 16:39:43 ah, that makes it much more +1. 16:39:59 definitely +1 nth 16:40:01 pjones uploaded the patch on August 15th 16:40:09 * rbergeron is nth here as well 16:40:12 mjg59: how common is the issue likely to be? is it specific to a model, a firmware or what? 16:40:13 So should just need a newer grub2-efi tagged in 16:40:25 adamw: It's a timing issue. Depends on how good your CD drive is. 16:40:35 Short version: Intel can't write code for shit 16:41:03 Their ahci driver times out when doing large reads from slow media. Like the 20MB initramfs off a CD. 16:41:38 so you need to be on an intel ahci system (but that's...a lot of systems), in uefi mode, with a not-too-great cd drive. the t420 apparently meets those criteria and is reasonably common, i guess. 16:41:55 We were hitting it on about 20% of tested systems 16:41:55 mjg59: i don't see this issue referenced in the grub2 changelog anywhere 16:42:05 c1a25d07e636b5164c7ae225fbd395baed464af5 16:42:06 is the patch definitely in the f18 grub2 tree? 16:42:12 "Work around AHCI firmware bug in efidisk driver" 16:42:17 20% seems quite a lot for me 16:42:48 adamw: Seems to be here 16:42:52 ah, k 16:43:15 is 20% enough for blocker? 16:43:20 * tflink is on the fence 16:43:22 20% of uefi installs 16:43:31 definitely +1 NTH, not so sure about blocker yet 16:43:36 Like I said, the bug is fixed, just needs to be tagged 16:43:44 right, so it's pretty academic 16:43:46 how many people do we expect to use uefi? 16:43:56 jreznik: quite small atm. 16:43:57 in a fantasy world or in reality? 16:44:00 Enough that you've already flagged some UEFI-specific bugs as blockers 16:44:00 but getting ever bigger. 16:44:52 I'm going to go with +1 nth, -1 blocker 16:45:06 there are acceptable workarounds (USB) and it only hits 20% of systems 16:45:16 yeah, agreed 16:45:28 mjg59: don't worry, this is just bureaucracy, either way the fix goes in. 16:45:36 in fact it'd be going in anyway as we're already pulling that update for another nth issue. 16:45:42 so just #agreed it and let's move on =) 16:45:48 * rbergeron puts up +1 nth in her window with pretty red tape 16:45:50 okm +1 16:46:02 * adamw just wanted to check the 'fix' didn't go into tc3 already and hence it wasn't working 16:46:06 rbergeron: blue one here! 16:46:13 i kinda thought we had -5 in tc3. but i was wrong, it's slated for tc4. 16:46:20 proposed #agreed 851500 - RejectedBlocker AcceptedNTH - This does affect the booting of the installer on ~ 20% of UEFI systems but only with optical media. Since USB is an acceptable workaround, accepting as NTH, rejecting as blocker 16:46:21 jreznik: mine was for the red tape of bureaucracy ;) 16:46:23 ack 16:46:36 well, usb would be an acceptable workaround if *it* worked =) 16:47:13 details ... 16:47:27 other ack/nak/patch? 16:48:14 i think we have implied acks... 16:48:20 adamw: USB should work for dded media, just not litd 16:48:37 #agreed 851500 - RejectedBlocker AcceptedNTH - This does affect the booting of the installer on ~ 20% of UEFI systems but only with optical media. Since USB is an acceptable workaround, accepting as NTH, rejecting as blocker 16:48:55 #topic (849389) uefi boot fails on Asus motherboards 16:48:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=849389 16:48:55 #info Proposed Blockers, ON_QA 16:49:20 This should be fixed in the kernel, again just needs tagging 16:50:08 seems to affect quite a lot of systems 16:50:12 sounds like a blocker to me 16:50:12 and less workaroundable than the last one 16:50:14 +1 blocker for me too 16:51:05 proposed #agreed 849389 - AcceptedBlocker - Violates the following F18 alpha release criterion for UEFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:51:09 * jreznik would like to be more consistent but understands it's harder to workaround... 16:51:11 ack/nak/patch? 16:51:12 * rbergeron can't tell if this is only asus motherboards (as implied by bz title) or ... bigger? 16:51:24 I would be that it's bigger 16:51:29 s/be/bet/ 16:51:29 bet* 16:51:36 yeah, from the later comments it looks more general 16:51:42 okay 16:51:48 * tflink only has asus UEFI systems to test on, though 16:51:53 just confirming 16:52:31 it doesn't matter if we accept it as blocker (and it seems like we are going to accept it as blocker) 16:52:36 It's pretty much only Asus 16:52:48 It's a specific firmware bug 16:53:01 ah, that might change things 16:53:16 are there enough asus UEFI systems out there to warrent blocker status? 16:53:22 Other people might have independently come up with the same bug, but we haven't seen any evidence of it 16:53:27 ah 16:53:30 * tflink takes a guess that there are 16:53:35 sigh, i hate these bureaucratic ones 16:53:42 let's just default to nth, it moves things along 16:53:44 yep 16:54:02 proposed #agreed 849389 - AcceptedNTH - Violates the following F18 alpha release criterion for Asus UEFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 16:54:06 if it turns into a problem somehow we can re-do it 16:54:10 nack 16:54:18 patch? 16:54:27 don't cite a blocker criterion for acceptednth :) 16:54:39 +1 for nth, to be consistent with previous one 16:54:52 +1 nth 16:55:18 propose #agreed 849389 - AcceptedNTH - breaks install on a subset of UEFI systems, not enough to be absolutely clearly a blocker 16:55:26 proposed #agreed 849389 - AcceptedNTH - Causes the installer to be non-bootable for Asus UEFI systems, doesn't seem to be enough systems to justify as blocker at this point in time 16:55:41 ack ack, flip a coin 16:55:56 if it affects ASUS only, then ack for tflink's one 16:56:10 adamw: since when do we not cite criterion for NTH? It does violate the release criteria, just not on enough systems to justify full blocker 16:56:17 then again, I don't care enough to discuss ATM 16:56:31 #agreed 849389 - AcceptedNTH - Causes the installer to be non-bootable for Asus UEFI systems, doesn't seem to be enough systems to justify as blocker at this point in time 16:56:38 OK, that's all of the proposed blockers 16:56:54 tflink: well, if you cite a criterion, best to explain why that doesn't make it a blocker. 16:56:58 or else it reads kind of weird. 16:57:20 yay 16:57:22 two proposed nth? 16:57:34 ok, I figured that "for Asus UEFI systems" was enough but either way, it's done :) 16:57:46 yep, two of them 16:57:54 #topic (851323) anaconda tries to poke /etc/chrony.conf at the end of install even if chrony wasn't in the installed package set 16:57:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=851323 16:58:00 #info Proposed NTH, POST 16:58:23 definitely +1 NTH on this 16:58:44 I think it could be somewhat blockery, though since it interferes with log copying post-install 16:58:46 at least NTH 16:59:07 i don't think we have any criterion for log copying 16:59:14 +1 nth obviously 16:59:38 proposed #agreed 851323 - AcceptedNTH - While the installed system is bootable after hitting this, it looks really bad and can interefere with other post-isntall tasks like log copying 16:59:46 there's patch, so should be ok with NTH 17:00:07 * rbergeron has to bail for famsco meeting/budget fun, sorry 17:00:16 jreznik: in theory, that shouldn't affect NTH/blocker decisions 17:00:21 rbergeron: is that in here? 17:00:38 ack/nak/patch? 17:00:38 tflink: no 17:00:43 sorry :) 17:00:48 ack 17:00:53 ok, just making sure we weren't getting in the way 17:00:59 rbergeron: money, money, money! 17:01:03 #agreed 851323 - AcceptedNTH - While the installed system is bootable after hitting this, it looks really bad and can interefere with other post-isntall tasks like log copying 17:01:17 #topic (851653) NTPconfigError: Cannot replace the old config with the new one (Invalid cross-device link) 17:01:20 #link https://bugzilla.redhat.com/show_bug.cgi?id=851653 17:01:23 #info Proposed NTH, POST 17:01:47 isn't this a dupe of #851323? 17:01:54 tflink: agreed - we don't necessarily want to bring in something that's NTH - it could still run the risk of breaking things and causing worse problems / slips... 17:02:35 rbergeron: we don't have to take NTH fixes if they exist 17:02:51 * rbergeron nods 17:03:06 * rbergeron thinks she worded her sentence wrong, should probably just focus on one meeting 17:03:09 lol 17:03:18 but the last one causes an installer crash, which would be best to avoid - assuming that's what you were talking about 17:03:26 tflink: this isn't a dupe, no 17:03:31 i think i was trying to say "jus because there's something doesn't mean it will be nice to have 17:03:42 something = patch :) 17:04:27 tflink: this bug claims that even if chrony is in the installed package set, anaconda still crashes, with a different error 17:04:35 tflink: i'm not sure this one is a 100%er, though 17:04:46 didn't others get successful installs which didn't crash at the end? 17:05:11 not sure, I had other problems with anything outside a minimal install 17:05:22 adamw: I'm in touch with Martin, I can ask him for more info - how to reproduce it 17:05:47 punt? 17:06:07 they are currently testing new anaconda, reporting it to rawhide (bureaucracy)... so I asked him to clone it for F18... 17:06:51 yeah, i'd say punt on this for more details on exactly what triggers it 17:07:41 yep 17:07:53 the bug's in POST, but i can't see the patch offhand 17:07:59 proposed #agreed 851653 - It isn't clear exactly how this bug is triggered and it'd be nice to see more details before making a decision on NTH 17:08:03 sometimes hard to match up anaconda-patches-list topics with bug #s :/ 17:08:18 ack/nak/patch? 17:08:34 https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000803.html maybe 17:08:47 suggests this might be " Don't crash if someone gives us bad timezone" 17:09:21 i'll ask in the bug, anyhow. 17:09:21 ack 17:09:30 #agreed 851653 - It isn't clear exactly how this bug is triggered and it'd be nice to see more details before making a decision on NTH 17:09:39 OK, I think that's it for the proposed blocker/nth 17:09:51 Is audio needed for alpha? 17:10:13 I don't think so 17:10:22 There is a problem with USB audio in the 3.6-rc2.git2 kernel. 17:10:28 [sorry to intrude .. no FESCO meeting today right?] 17:10:46 audio is beta 17:10:52 rwmjones: right] 17:10:55 thanks 17:10:56 rwmjones: that is my understanding, yes 17:11:17 okay, i think we're done with mini blocker review? 17:11:20 FESCo is on holydays :) 17:11:22 yep 17:11:22 anyone have anything we missed? 17:11:52 OK. I don't think it should be NTH, though if we slip a few weeks it might get pulled in with other kernel fixes. 17:11:56 nothing I'm aware of, no 17:12:39 ok 17:12:42 so very quickly... 17:12:45 #topic open floor 17:12:53 any other business, just in case anyone feels the meeting hasn't been long enough? 17:13:03 brunowolff: few weeks? it's scary... ... ... !!!! 17:13:34 nothing big from me, might send request for feedback of reskinning of blocker tracking app if I get it done 17:13:40 adamw: sorry for missing the anaconda part - I agree and I'll try to be pushing more there... 17:13:53 that'll depend on how much time is available this week, though 17:14:19 jreznik: np, thanks 17:14:24 reminder to weigh in on the #4 rec. to FESCo on live installs etc? 17:14:26 * adamw sets fuse for X minutes 17:14:30 or is that going out to test@ 17:14:31 ? 17:14:38 tflink: i'll mail the list, i actioned myself. 17:14:57 ok, couldn't remember the outcome of that. just checking 17:15:42 adamw: fire it! 17:15:48 #endmeeting