16:00:03 #startmeeting F13Blocker Review 16:00:03 Meeting started Fri Apr 30 16:00:03 2010 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:11 #meetingname f-13-blocker-review 16:00:11 The meeting name has been set to 'f-13-blocker-review' 16:00:19 #topic Gathering critical mass 16:00:34 *yawn* 16:00:43 indeed 16:01:14 we maybe without adamw for the meeting, so we'll need to make due 16:01:30 who else is here for the F13Blocker meeting? 16:01:59 * rdieter is here 16:02:01 oh I know you're all here ... don't be shy 16:02:05 rdieter: welcome :) 16:02:24 * nirik is lurking. 16:02:34 nirik: howdy 16:02:48 anyone from the installer side ... I don't see dcantrell or dlehman around today 16:04:42 clumens: hey hey 16:04:56 yo 16:05:22 okay ... I've got a few different bug lists I'm tracking (un-MODIFIED and MODIFIED) ... but for simplicity, we'll just use the main tracker 16:05:29 #link https://bugzilla.redhat.com/showdependencytree.cgi?id=507681&hide_resolved=1 16:05:59 I'm going to walk that list of bugs, sorted by component http://tinyurl.com/33hyx44 16:06:22 alright, i'm here 16:06:23 and bursting through the large paper team logo ... adamw! 16:06:34 slightly delayed by a half hour walk from the train station 16:06:39 adamw: welcome ... we're just starting 16:06:50 and the fact that either this place is excessively firewalled or my home systems are all down 16:07:22 For folks new to this meeting, there is a guide to explain the format at http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:07:38 For folks who have done this before ... I'm sorry, but we have to do it again 16:08:22 I'd like to skip the MODIFIED and ON_QA bugs today ... how to people feel about that? 16:08:34 fine with me 16:08:35 instead, I'd like to mass update each of those bugs requesting test feedback 16:09:21 I've got a single +1 16:09:30 any -1's ... . . . 16:10:02 alright ... skipping MODIFIED and ON_QA bugs 16:10:05 first up ... 16:10:11 #topic https://bugzilla.redhat.com/show_bug.cgi?id=587698 16:10:12 Bug 587698: medium, low, ---, jmoskovc, NEW, new abrt icons for f13 16:11:03 this is linked to from 584041 - (f13artwork) Fedora 13 icon and artwork polish bug 16:11:34 notting and mizmo discussed this last week in #fedora-devel 16:12:18 this actually hits the regular release criteria, we have a desktop criterion for icon consistency 16:12:41 #info # All Applications listed in the desktop menus must have icons which have a consistent appearance and sufficiently high resolution to not appear blurry 16:13:11 are these just new fancy icons, or addressing a real icon consistency problem? 16:13:57 not sure, the report does mention consistency 16:14:06 okay, calling mizmo in 16:14:45 from reading a few of the bugs, I'd have to say consistency too 16:14:53 okay, so we've got 2 +1's 16:14:56 * jraber is here. 16:15:04 jraber: welcome 16:15:32 +1 16:15:41 alright, sold to the highest bidder! 16:15:58 #agreed 587698 affects desktop icon consistency criteria, is a valid release blocker 16:16:07 jlaska: hi! 16:16:08 adamw: are you up for handling the bz notes? 16:16:12 mizmo: thanks for joining :) 16:16:14 sure 16:16:19 mizmo: we were just discussing /topic bug 16:16:26 ah 16:16:34 general agreement was this impacts the release criteria around desktop icon consistency 16:16:35 i'm in the process of adding more icon bugs - i hope that's okay 16:16:47 we've been getting more in from the gnoe-artists 16:16:50 s/gnoe/gnome 16:17:03 mizmo: it's OK to add bugs, but only if somebody is going to fix them in time (: 16:17:07 which is seriously short. 16:17:18 mizmo: do you anticipate these all being integrated by next Tuesday? 16:17:24 jlaska: i hope so :( 16:17:27 Oxf13: can you confirm the date to have these in ^^^ ? 16:17:51 well RC phase starts next week. 16:17:56 mizmo: okay, as it stands, /topic bug would be something we'd hold the release for in they are still unresolved 16:18:01 provided we get the bugs closed 16:18:11 absolute latest we should start RC phase is the 6th 16:18:11 i don't know for every case. making the icons consistent is a really difficult job because it involves so many different maintainers 16:18:27 ive been trying to get problem icons identified, new icons created, and bugs filed over the past month 16:18:39 brb, grabbing something to eat at the desk. 16:18:45 mizmo: would you classify these icon changes as 'must have' items for F13, or 'nice to have'? 16:19:12 jlaska: well, understanding my perspective is on making an awesome user experience for fedora - 16:19:24 jlaska: i think we really at a minimum need 100% consistent icons for the default spin install 16:19:34 im only filing these for icons that appear in the default install 16:19:41 mizmo: indeed, we have that in the criteria 16:19:49 agreed, and I think that's captured by the criteria on https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria 16:19:52 but i understand from another perspective it might be more of a nice-to-have 16:20:10 however.... the positive impact i think is really worth it 16:20:19 bug updated, i'm trying vaguely to make up a standardized format for the bug notes this week... 16:20:31 adamw: awesome, stock responses! :) 16:20:37 anything else to discuss on this bug? 16:20:55 once ... 16:20:56 im going to be filing more, would it be helpful for me to drop urls somewhere as i file them? 16:21:00 i expect to be done this afternoon 16:21:09 mizmo: as long as they're linked to your tracker bug, you should be good 16:21:13 mizmo: just make them block F13Blocker 16:21:13 okay cool 16:21:20 twice ... 16:21:22 also we have an open floor bit at the end of the meeting 16:21:30 where we ask if anyone has other bugs to mention 16:21:32 right, Sho_ has a few items queued up for open discussion 16:21:33 mizmo: my question is though, is it realistic to expect these issues to be fixed by Tuesday? 16:21:35 you could always note them there. 16:21:52 note: end of meeting may be quite a long way away. =) though the hotel stops serving dinner in 4hrs 40... 16:21:53 * jlaska wonders if meetbot has a way to save discussion items for later 16:21:53 Oxf13: when i've gotten a hold of a maintainer it's never taken longer than a day to get the stuff in 16:22:07 adamw: no better motivator to move this along :) 16:22:22 mizmo: ok, so then we won't immediately worry about slippage 16:22:43 * Sho_ has time, luckily :) 16:22:52 okay, next bug ... 16:22:55 clumens: anaconda time 16:23:00 skipping a few MODIFIED bugs ... 16:23:09 mizmo: thanks for joining and bringing us up to speed! 16:23:23 #topic https://bugzilla.redhat.com/show_bug.cgi?id=534066 16:23:26 Bug 534066: medium, low, ---, anaconda-maint-list, NEW, Anaconda does not assign correct root partition to boot windows 16:23:26 :) my pleasure 16:23:50 we finally have the data we need for that, just need to write the fix 16:24:08 given Ubuntu's recent dual boot fiasco, we should not screw that up 16:24:17 okay, so still a blocker, same status as last week 16:24:25 #agreed 534066 status unchanged since last week, still with anaconda team to provide a fix 16:24:32 we'll put top men on it. 16:24:38 as an aside, they found this bug, and respun isos on the /day of the release/ 16:24:44 clumens: strengthen those algorithms! 16:24:45 and still posted those isos 16:24:51 Top Men. 16:24:55 jlaska: how's that for QA heartburn? 16:24:57 Oxf13: yup, please don't ask me to do that :) 16:25:08 Oxf13: not in our current state 16:25:09 wouldn't dream of it 16:25:21 okay, next bug ... 16:25:23 Oxf13: a slip means rename the release for them ;) 16:25:27 didn't we more or less do that for f12, oxf13? 16:25:37 * adamw was so frazzled at that point his memory is not entirely clear 16:25:46 adamw: no. 16:25:53 #topic https://bugzilla.redhat.com/show_bug.cgi?id=504986 16:25:55 Bug 504986: medium, medium, ---, anaconda-maint-list, ASSIGNED, F11 x86-64 LiveUSB backtrace 16:25:57 oh yeah, it was just the last go/no-go day. feh, easy. 16:26:10 adamw: since I've been at the helm, we've never respun final release isos on the day of release. That screws mirrors. 16:26:29 (notably Ubuntu didn't respin all of the ISOs, so you can get lucky/unlucky depending on what you install from, also fun) 16:26:36 last week we decided ... 16:26:39 #agreed 504986 is a valid blocker, anaconda team to investigate + fix 16:26:46 i've just updated the summary of this bug to not be so bleedin' misleading 16:27:14 adamw: ah, good 16:27:47 looks like dlehman is still diagnosing the failure conditions 16:27:49 for the record, we ascertained last week we've had reports of this bug with f11, f12 and f13, if you check the traces in the dupe and their versions 16:28:17 from his last comment it looks like perhaps stickster's case is a valid reproducer, which would obviously help 16:28:53 definitely 16:29:31 any changes from our conclusions last week/ 16:29:53 * jlaska notes ... it's ASSIGNED to anaconda-maint-list@ ... should be dlehman? 16:29:59 don't think so, we're waiting on the fix 16:30:27 #info No changes from last week, waiting on problem determination and fix 16:30:44 #info still assigned to anaconda-maint-list@ ... needs a person? 16:30:48 #topic https://bugzilla.redhat.com/show_bug.cgi?id=531629 16:30:50 Bug 531629: medium, low, ---, anaconda-maint-list, ASSIGNED, RuntimeError: Returning partitions to state prior to edit failed 16:31:10 last week we decided ... 16:31:11 jlaska: you can reassign it if you'd like 16:31:14 make sense 16:31:16 #agreed 531629 remains a blocker, with anaconda team for action 16:31:35 clumens: okay, assigning to dlehman (poor guy was last to touch it) 16:31:57 531629 looks like it should be modified? 16:32:15 last comment "The fix should actually be in anaconda-13.37-1 in case that makes testing 16:32:15 easier for anyone." 16:32:16 indeed it does! 16:32:54 needs retesting...that cmaska guy has a reproducer for this 16:33:03 maybe he could swoop in and do some testing ;) 16:33:14 i'm beginning to doubt whether he even exists 16:33:22 have faith, my friend 16:33:24 adamw: it's about time! 16:33:33 just light up the Maskasignal 16:33:43 clumens: you can confirm this is in the right f13-branch primed for testing goodness? 16:34:38 #info appears to be fixed in anaconda-13.37-1 and ready for retest 16:35:29 jlaska: anaconda-13.39 is the current version on f13-branch, so i would say it's correct. 16:36:14 okay, let's move this to MODIFIED (or ON_QA) and it'll land in my batch retest update 16:36:48 okay updated 16:37:11 Next un-MODIFIED anaconda bug ... 16:37:12 #topic https://bugzilla.redhat.com/show_bug.cgi?id=569469 16:37:13 Bug 569469: medium, medium, ---, dlehman, NEW, ValueError: Cannot remove non-leaf device 'vda5' 16:37:50 sorry, got disco'ed 16:38:00 adamw: please, no 70's references 16:38:06 heh 16:38:38 last week we agreed jlaska would retest this issue 16:38:39 disco stu don't advertise 16:38:54 clumens: well done 16:39:12 #info testing of 569469 is still inprogress 16:39:27 I've gone through the F-13-Final-TC1 RAID tests earlier today, so I'm ready to reproduce this issue 16:39:52 if I can no longer reproduce this issue, I'll remove it from F13Blocker, as per previous agreement 16:40:05 then here's hoping 16:40:14 i'll drink to that 16:40:18 #action jlaska to retest 569469. If problem resolved, remove from F13Blocker 16:40:21 but not at minibar prices 16:41:15 next up ... an issue we all know and love ... 16:41:18 #topic https://bugzilla.redhat.com/show_bug.cgi?id=571900 16:41:19 Bug 571900: medium, low, ---, mgracik, NEW, Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha - 16:42:08 ok I took that one just to find out that it wasn't my fault ... 16:42:22 anaconda seems not to write the config data out to disk 16:42:36 well, that's something 16:42:47 just one release where we don't have an i18n keyboard bug 16:42:49 is that too much to ask? 16:42:52 ball's coming your way, clumens! 16:43:10 it gets past clumens! 16:43:13 and going by the fact that a) it can has bad side effects (not being able to enter passwords) b) can NOT be fixed past release 16:43:19 I'd say +1 to blocker 16:43:24 *post 16:44:03 yeah, i think it ought to be a blocker. 16:44:15 is there a reasonable workaround? 16:44:29 use an english keyboard 16:44:48 he said reasonable ;) 16:45:01 that's reasonable from where i sit! 16:45:34 * adamw notes the 'old curmudgeon's seat' note on the back of clumens' chair 16:45:47 i'm not aware of one, drago? 16:45:55 kids these days, with their weird new keyboard layouts 16:46:24 okay, so no reasonable workarounds exist 16:46:47 adamw: not really other than do a vt switch and edit the config files before rebooting the installer 16:46:58 hmmm 16:47:42 is fixing this now going to be extremely disruptive? 16:47:54 probably not 16:47:55 does not fit into "reasonable" ... so as clumens is already used to have to deal with such bugs for every release ... just leave it to him ;) 16:47:56 * jlaska thinking about late plymouth and gdm changes in F12 16:48:10 alrighty ... about to #agreed on this one 16:48:48 #agreed 571900 is a valid release blocker with no reasonable workaround 16:48:54 agreed - here's a quarted, by a new keyboard 16:49:17 #topic https://bugzilla.redhat.com/show_bug.cgi?id=568528 16:49:18 Bug 568528: medium, low, ---, msivak, ASSIGNED, firewall --disabled still produces a blocking /etc/sysconfig/iptables 16:49:29 clumens: i think you'd better use it yourself 16:49:41 now now gents 16:49:45 ;) 16:49:47 we all know keyboards cost 2 quarters 16:49:53 ah, this bug. 16:50:07 iirc, the underlying change you were waiting for got done this week 16:50:12 so the ball's back to anaconda team 16:50:14 Thomas indicates a build is available for test in updates-testing 16:50:28 the "we're not going to do what you suggested - hey let's do that thing he suggested" bug 16:50:44 #help Karma feedback needed on system-config-firewall - http://admin.fedoraproject.org/updates/system-config-firewall-1.2.25-1.fc13 16:51:19 it has +2 already, isn't a critpath update apparently 16:51:37 so one more gets it through? 16:51:44 depends if they set auto-karma 16:51:49 * jlaska nods 16:51:55 but since it's not critpath, update creator can push it any time 16:52:03 clumens: what's the right path forward for 568528? 16:52:49 * adamw notes s-c-f appears to work, adds a +1 16:52:53 jlaska: msivak needs to work up a patch that makes use of the new s-c-firewall flag 16:54:01 okay ... unless objections, I'll mark as still a blocker and waiting on complimentary fix 16:54:32 #agreed (Meeting topic: F13Blocker Review) 16:54:36 ergh 16:54:38 #undo 16:54:39 Removing item from minutes: 16:54:39 i can do it 16:54:57 adamw: go for it 16:55:27 #agreed 568528 a valid release blocker, s-c-firewall fix is in, waiting on anaconda change to support new option 16:56:24 okay, that's the last of the anaconda bugs 16:56:32 skipping the Tracking bugs ... 16:56:47 clumens: I believe there may still be installation related issues. If you are able, would love to have you lurk 16:57:10 #topic https://bugzilla.redhat.com/show_bug.cgi?id=579515 16:57:11 Bug 579515: medium, medium, ---, jmagne, NEW, ESC still requires ifd-egate. 16:57:16 jlaska: i'm going to sit in front of the computer anyway, might as well 16:57:43 clumens: heh, thank you :) 16:58:18 #info adamw pinged this issue last week, reminding maintainer a new package is needed for F13 16:58:24 i believe the updates may now have been submitted...let me check 16:58:47 iirc, this bug is related to the boot spewage about ifd-gate 16:59:30 esc: https://admin.fedoraproject.org/updates/esc-1.1.0-12.fc13?_csrf_token=e4a8429a5eec792a0877ac20180a48104d01ea16 16:59:33 gr 16:59:39 https://admin.fedoraproject.org/updates/esc-1.1.0-12.fc13 17:00:40 sorry, bodhi's slow right now... 17:01:17 adamw: one sec ... can you #info #agreed as needed 17:01:35 #info esc update pending: https://admin.fedoraproject.org/updates/esc-1.1.0-12.fc13 17:02:00 looks like the coolkey update went through already (that's related bug #567325) 17:02:02 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=567325 medium, low, ---, rrelyea, NEW, ifd-egate uses deprecated udev rules syntax 17:02:19 so all we need is for the esc update to be pushed to stable and then ifd-egate can be orphaned 17:03:07 #info all we need is for the esc update to be pushed to stable and then ifd-egate can be orphaned 17:03:30 * jlaska back 17:03:43 adamw: thx 17:04:08 #topic https://bugzilla.redhat.com/show_bug.cgi?id=587704 17:04:09 Bug 587704: medium, low, ---, stickster, NEW, f13 new icon for fedora-release-notes 17:04:31 not sure if there's anything else to add here 17:04:37 this touches on the earlier discussion with mizmo 17:04:47 yeah, likely very similar rationale 17:05:10 Love the icons ... would like to see them go through the matrix before the RC 17:05:40 anyway 17:06:03 #agreed 587704 is a valid release blocker impacting default desktop icon consistency 17:06:24 next up ... firstboot 17:06:27 #topic https://bugzilla.redhat.com/show_bug.cgi?id=583818 17:06:28 Bug 583818: medium, low, ---, mgracik, NEW, workstation.png should be updated to newest icon theme 17:07:03 that doesn't look very firstbooty! 17:07:05 also blocking bug#f13artwork 17:07:10 oh, wait, it is. heh 17:07:26 mizmo is on a roll! 17:08:09 any concerns, otherwise I'll apply the same reasoning as previous icon issues 17:08:40 seems fine 17:08:43 * jlaska doesn't actually know where the firstboot icon shows up (the alt windowlist from inside firstboot)? 17:08:44 i can update the bug 17:08:54 #agreed 583818 is a valid release blocker impacting default desktop icon consistency 17:08:57 adamw: please 17:09:03 i think this is an icon displayed within firstboot? not sure 17:09:15 ah maybe 17:09:23 another big firstboot artwork bug .... 17:09:25 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586575 17:09:25 which makes it not really hit the criteria... 17:09:26 Bug 586575: medium, low, ---, mgracik, NEW, F13 New artwork for firstboot sidebar 17:09:50 right, yeah, hold up, these are a bit different 17:09:56 as they aren't application menu icons 17:10:05 er, foot menu icons. you know what i mean. 17:10:12 The Foot! 17:10:15 those are the only ones our current criteria care about directly 17:10:20 rdieter: thanks for the alsa-tools addition 17:10:33 adamw: right, there is a thread on design-team about this 17:10:52 I don't think you can say we don't care about firstboot look/feel though 17:11:00 no, but we're kinda outside process here 17:11:39 we have an informal system of allowing other teams to have their own tracker bugs which block f13blocker, essentially giving them discretion to choose blocker items per their own criteria...which seems to mostly work but isn't really covered by criteria / process for these meetings 17:12:10 I think it goes back to "I'll know a release blocker when I see it" 17:12:20 adamw: my concerns around this late change were around strings and what code changes were required to accomodate the graphics 17:12:22 we could just say for now that we'll let f13artwork / kde team blockers / whatever ride, and trust those teams... 17:12:51 and then review them as judgment calls if they become problematic (aren't fixed as we near rc stage) 17:12:59 adamw: I wouldn't do that unless said teams were onhand for these review meetings 17:13:00 adamw: +1 17:13:18 adamw: how do you define "near" ? :) 17:13:34 this all needs to be done by Tuesday 17:13:38 poelcat: on our usual standards, about two hours after oxf13 first tries to build the images is 'near' =) 17:13:51 adamw: there's really only a few days left 17:13:54 on the other hand, if they get punted only if close to rc, then they aren't really blockers, are they? 17:14:03 rdieter: agreed! 17:14:11 rdieter: yeah, exactly, that's my worry here; we're being quite inconsistent 17:14:25 shall we pull mizmo in again? 17:14:34 we're being quite strict with 'direct' blockers that we feel we have control over, but we don't really have a good process for these indirect, other-team-managed blockers 17:15:22 suggestions? 17:15:25 jlaska: well, sure, what are we going to ask her? i'm sorry, i'm being awkward but don't have a clear path forward... 17:15:52 so ... we don't have release criteria for these firstboot changes, right? 17:16:05 jlaska: set some highlevel release critiera now for F13 as it relates to these other things... make more detailed criteria for F14 17:16:10 i don't believe any of our current criteria cover in-app polish issues like this, no 17:16:25 adamw: so then it's not a blocker 17:16:42 my rough suggestion: adjust f13artwork to block f13target instead of f13blocker, but clarify that we will accept artwork team fixes up until tuesday at least 17:17:05 adamw: I think that's sound ... 17:17:33 as always, as rdieter says, if we wouldn't actually delay the release for these problems, they're not blockers; that's the ultimate test 17:17:46 2 points for rdieter :) 17:17:47 maybe we can get mizmo in just to see if they're okay with that? 17:18:53 wouldn't hurt 17:18:56 asking 17:19:53 anything artwork related that is an actual blocker - i.e. foot menu icon issues - can be set to block f13blocker directly (i already did that with the earlier issue) 17:20:16 if we were missing an icon at firstboot, I'd consider that a blocker 17:20:17 if there is disagreement on the assessed importance of this issue ... isn't that where FESCO comes into play to provide direction 17:20:28 these types of coverage is about things that are going to show up for just about everybody 17:20:32 eg the default foot icons 17:20:52 firstboot shows up for just about everybody, so if it's not looking good, that's a blocker in my book, because everybody is going to see it 17:21:33 Oxf13: it looks like it looked for F-12, and all F-13 milestones 17:22:10 jlaska: I blow by it not looking at it. 17:22:30 i don't really stare at it, but i don't remember anything about it looking really horrible 17:22:37 so we have nothing in our release criteria about firstboot? 17:22:44 https://fedoraproject.org/wiki/Design/F13_Firstboot_Polish 17:23:14 I vote we move this to F13Target, noting there are no current release criteria supporting holding the release for this 17:23:26 if that changes ... we can reevaluate 17:23:50 we've reached the time limit for this bug anyway 17:24:02 or have someone (outside of this meeting) propose release critiera and re-evaluate against said criteria later 17:24:19 yeah, that's sound 17:24:21 it seems we often try to hide behind release critiera 17:24:22 jlaska: +1 17:24:34 Oxf13: I'll stand in front of them :) 17:24:42 and say "oh that issue doesn't match criteria" instead of saying "oh, maybe we have a hole in our criteria that this issue highlights" 17:24:56 Oxf13: poelcat just noted we may have a hole in the criteria 17:25:02 and that we should handle that outside this meeting 17:25:06 Oxf13: i'm not trying to do that, but we should cover it under process - if we think this kind of issue should be a blocker, then we should add a criterion for it 17:25:21 Oxf13: i'm not against adding a criterion at all, i was just trying to make sure we keep everything consistent 17:25:51 okay so ... we have an action to follow-up on a release criteria changes 17:25:55 well, first release criteria is that no blocker bugs remain, so we always have an out. We can deem something a blocker, even if there is no current criteria that would also state that. 17:26:00 for this particular case i think we need to take a more careful look at what firstboot actually looks like, and perhaps get more info from mizmo 17:26:02 and then we need to decide whether to leave this, or move it to F13Target in the interim 17:26:22 adamw: ok, who is the "we" 17:26:54 Oxf13: the 'we' that represents this meeting =) i guess we don't really have an official name for that capacity 17:27:09 anyone want to take an action item to follow-up with the design team and mizmo on this? 17:27:20 ok... I finally read the wiki page 17:27:26 jlaska: well this specific issue has not been directly designated f13blocker, it is only indirectly a blocker (via f13artwork) 17:27:39 and in my opinion, this is a Feature level change that should have been done months ago 17:27:49 not something to be changing the week before RC 17:27:56 i do think we can't just accept a team's entire tracker as a release blocker like that, i do want to change f13artwork not to block f13blocker 17:28:10 adamw: that was my suggestion earlier 17:28:21 yep, just reiterating and making sure we don't lose that 17:28:25 cool 17:28:37 so ... shall we vote for moving this to F13Target? 17:29:02 where 'this' is f13artwork, not 586575? yes 17:29:32 no, we agreed on the icon changes already 17:29:44 shall we move 586575 to F13Target ? 17:30:04 well we don't have to 'move' it if we adjust f13artwork 17:30:07 ok, how did the wiki link come up? 17:30:19 the bug in /topic I think /is/ a blocker, it should match the theme of everything else 17:30:36 and since it is viewed by everyone, having it not match is a glaring issue that will be seen by everybody 17:30:47 okay, we can't agree here ... I'll start a thread with mizmo outside this meeting 17:30:54 we need to move on 17:31:01 and even though we don't have release criteria that covers firstboot, I still feel that the issue of the sidebar graphic is a blocker 17:31:17 the /rest/ of the UI changes linked by the wiki may not be, but that's not what we're discussing right now 17:32:05 +1 to jlaska: let's move on for now 17:32:45 #action jlaska to send email to mizmo requesting further feedback on 586575. No current release criteria impacted by this change 17:32:58 I'll do this after the meeting 17:33:19 fwiw the other f13artwork bugs look like reasonable blocker candidates from a quick scan, so we shouldn't have so much trouble with those 17:33:35 #topic https://bugzilla.redhat.com/show_bug.cgi?id=584603 17:33:36 Bug 584603: medium, low, ---, jreznik, ON_QA, goddard KDM and KSplash themes broken 17:34:35 rdieter: you might have more insight here 17:34:48 looks like a bodhi update is available with a fix 17:34:52 oops, this is ON_QA ... bad jlaska 17:35:02 yes, it's good, and queue'd for stable I think 17:35:23 #help Karma feedback needed. Please help http://admin.fedoraproject.org/updates/goddard-kde-theme-13.0.1-1.fc13 17:35:27 rdieter: thanks 17:35:45 #info 584603 looking good, queue'd for stable 17:35:58 #topic https://bugzilla.redhat.com/show_bug.cgi?id=568106 17:36:00 Bug 568106: medium, low, ---, bcl, NEW, Unable to enter grub menu in F-13-Alpha with console=ttyS0 17:36:16 okay, this is an oldie, but bcl pointed out something obvious that I missed when filing this 17:36:37 the grub.conf timeout value has changed from F-12 to F-13 from timeout=5, to timeout=0 17:36:50 timeout=0 means you can never enter the grub menu to make changes 17:36:58 unless you hold a key down 17:37:01 nope 17:37:11 Oxf13: this is specific to serial console 17:37:19 Oxf13: otherwise you are spot on 17:37:25 Right, I was commenting in the general case, not the serial case. 17:37:30 As far as I can tell the timeout of 0 has been there for a while. It seems to depend on something called chainlist 17:37:38 Oxf13: hh I see, apologies 17:38:12 can we change serial console install to set timeout=5? 17:38:20 or is there no way to get that granular? 17:38:29 adamw: bcl suggested that, but was confirming why it was changed in the first place 17:38:50 i think it was a boot speed / 'polish' change (don't show everyone a boot menu every time) 17:39:02 that's the general case yes 17:39:16 but i'm not sure there was ever a really clear explanation, just lots of argument about whether it was a 'problem' 17:39:30 it's an opinion thing 17:39:49 (which I happen to share the opinion that not showing the menu gives a much nicer boot time experience) 17:39:56 with the timeout you don't get the menu, you get a countdown with the name of the default being booted. 17:40:42 true, yswim though. 17:40:49 related: if you'be booting with vnc can you get a keypress in at the right time? 17:41:04 bcl: define "booting with vnc" 17:41:20 bcl: in my testing, when booting with a physical console ... it behaved as expected with a keypress to display the grub menu 17:41:23 if you mean virt-guests vnc output, then yes, since you can even access the "bios" level stuff of a virt guest with a keyboard over vnc 17:41:40 Oxf13: I haven't used vnc with the myself, so I'm not sure :) 17:41:52 virt-viewer defaults to vnc 17:42:10 ... at least with remote virt systems, which is what my setup is here 17:42:17 not sure about local guests, but that might be vnc as well 17:42:29 ok, so serial console is the only problem. I'll see if there is a way to test for that. 17:42:38 bcl: confirmed, yes virt-viewer (VNC) on a guest with a display adapter works properly when holding a key a boot 17:42:47 ok, cool. 17:43:27 okay, based on the new information, what's the decision for this bug? 17:43:32 now, this timeout change went in a number of releases ago 17:43:42 so I don't think this is a regression from F12 17:43:46 Oxf13: for F12, it was timeout=5, for F13 it is timeout=0 17:43:49 do we have any data that says otherwise? 17:43:56 jlaska: .... are you sure about that? 17:44:03 yes 17:44:22 jlaska: I'm not sure it was 5 for f12 17:44:28 what's the exact impact of the bug? in a typical serial console install do you actually _need_ to get to the boot menu for some reason? 17:44:37 bcl: I confirmed yesterday ... I can confirm again 17:44:57 ahh, ok. 17:44:58 adamw: impact ... when doing a serial install (or headless virt guest) ... you can't enter the grub menu 17:44:58 bootdisk/i386/grub.conf:timeout 5 17:45:25 wait, that's still in f13-branch too 17:46:50 jlaska: as i said, though, is there a _need_ for that? 17:46:57 * Oxf13 struggles to figure out where this is set in anaconda 17:47:12 twisty passages 17:47:14 adamw: my uses here are in adjusting the kernel boot args, in the event of boot failures 17:47:19 or changing to use another kernel 17:47:38 I see this is a troubleshooting/debug impediment for serial console users 17:47:52 how numerous are the virt serial console users though? 17:48:03 well, I suppose this hits real hardware too 17:48:23 but we can releasenotes that if you're doing a serial setup, increase your grub timeout 17:48:35 yeah, and jforbes (virt) confirmed with having this as a F13Blocker 17:48:46 we can pull him in for an assessment on impact to virt 17:48:53 jlaska: what does your grub.conf look like for the serial console? Is there a terminal line with a timeout? 17:48:58 Oxf13: well, the impact is at a point where you _can't_ adjust it: install time and first boot time 17:49:31 oh, nm, its in the bug. 17:49:54 bcl: we're looking at the same code (: 17:49:59 So it looks like it sets the serial timeout to 5 seconds, so I'm not sure why it isn't working. 17:50:17 Maybe timeout should be set to 5 when self.serial == 1 17:50:23 perhaps grub ignores that line if the master timeout=0 17:50:24 would be happy to have others confirm this 17:50:33 my inclination for this bug is it's not a blocker, fwiw. 17:50:49 needing to access the grub menu at install time or first boot on a serial console install just seems too niche. 17:50:57 adamw: yeah I don't have specfic criteria for this 17:51:03 jforbes: what's your take? 17:51:25 well, if the boot is hosed you don't have any way to get to grub in that problem case. 17:52:00 I think it's a trivial amount of code change to make timeout=5 in the serial case 17:52:14 i don't mind fixing it if we can, but that doesn't mean it's a blocker 17:52:17 given jlaska's experience that changing timeout to 5 fixed it for him, I'd vote for setting it to 0 normally and setting it to 5 when serial is enable.d 17:52:23 yeah 17:52:23 jlaska: I don't know that serial console has ever been a very high priority 17:52:42 sure, that seems like a reasonable fix, and if we can fix it, let's take the fix. but i don't think i'd actually block the release if it wasn't fixed... 17:52:43 jforbes: okay 17:52:49 jlaska: but the fix is simple, and not invasive 17:52:53 adamw: I'd agree, not a blocker and pretty simple to fix. 17:52:59 adamw: nice, yeah I can live with that 17:53:10 so shall we drop it to target with a note we'll take the fix if it's in time? 17:53:50 #agreed 568106 not considered a release blocker, move to F13Target. Willing to take fix if available 17:53:53 let's dooeet 17:54:34 jforbes: bcl: thanks folks :) 17:54:45 Patch sent. 17:54:55 mizmo: is back ... objections to revisiting the firstboot sidebar issue for no more than 10 minutes? 17:56:21 adamw: Oxf13 ^^^ ? 17:56:32 okay. 17:56:40 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586575 17:56:42 Bug 586575: medium, low, ---, mgracik, NEW, F13 New artwork for firstboot sidebar 17:56:48 mizmo: thanks for joining again 17:56:55 no prob 17:57:16 we couldn't reach consensus on this issue. There aren't currently any release criteria we could identify that would warrant holding the release for this issue 17:57:24 wait is that the right bug?> 17:57:27 that's the for the sidebar 17:57:32 well, it's a bit more complex than that 17:57:45 it was the polish bug in question right? 17:57:52 it wasn't necessarily this specific issue we were discussing particularly, we were talking more generally. 17:58:01 no, the bug in topic when we were arguing is the side bar graphic. 17:58:05 https://bugzilla.redhat.com/show_bug.cgi?id=586578 17:58:06 Bug 586578: medium, low, ---, mgracik, NEW, F13 merge welcome and license info screens in firstboot 17:58:09 oh okay 17:58:14 Oxf13: sure, it was, but that wasn't what i was really worrying about. 17:58:21 * Oxf13 throws up his hands 17:58:39 the final artwork for f13 has been late - some folks had committed to doing it then didn't end up having time 17:58:41 i thought that was rather clear from...the things i was saying? you know, if you read them. 17:58:52 if we're going to have an argument, cna we at least agree upon that which we are arguing about? 17:59:01 i didn't realize that wasn't clear. 17:59:05 so ive been putting together the final splashes and banners like the firstboot one at the last inute 17:59:12 all the time i was talking about the general blocker process, not some single specific bug. 17:59:29 * Oxf13 waits for adamw to finish 17:59:36 as far as this specific bug goes, i agree that instinctively it ought to be a blocker, and we should add a criterion for that 18:00:00 something along the lines that all relevant artwork (ideally specify the set) should be consistent with the theme chosen for the release 18:00:20 that's good 18:01:23 Oxf13: is that okay? sorry, i didn't realize we were talking at cross-purposes earlier 18:01:41 5 minutes left on this topic 18:01:43 adamw: sure, that's basically what I said before 18:01:46 shall we #agreed for /topic bug? 18:02:03 sure 18:02:04 both that the /topic bug is a F13 blocker, and that we need to create criteria that covers it in the future. 18:02:09 we can discuss the bigger process issues out of meeting 18:02:21 excellent 18:02:41 thanks :) 18:02:41 mizmo: I will note that some of the other changes you have proposed, such as changing text and ordering in firstboot, it's waaaaaaay to late to do that for F13, and I'd reject the changes. 18:02:43 #agreed 586575 is a valid release blocker. 18:02:50 Oxf13: really? :( 18:03:01 Oxf13: but i got the translators' approval 18:03:17 mizmo: it's past string freeze, it's past feature freeze, it's like 2 days away from RC phase. That's just entirely the wrong time to be making changes like that. 18:03:20 #agreed conditionally agreed in a new release criteria - all relevant artwork (ideally specify the set) should be consistent with the theme chosen for the release 18:03:29 i got approval one or two days past string freeze 18:03:31 and it's not a feature 18:03:49 most of the strings, by the way, are legal and by policy are not translated 18:03:54 #action group to decide w/mizmo if f13artwork should be used only for issues agreed to be blockers, or if f13artwork should be changed to block f13target and individual bugs which are in fact blockers set as blockers directly 18:04:00 adamw: thx 18:04:05 (the above is just so i don't forget to clarify that later, out of meeting) 18:04:14 mizmo: once again, thank you :) 18:04:30 we'll come bug you again after the meeting to iron out the criteria 18:04:32 okay 18:04:34 cool 18:04:36 later 18:04:39 mizmo: did the translation team realize that you wouldn't be landing text until the day before RC phase? 18:04:45 annnnd she's gone. 18:05:03 let's take those questions as the bugs come up...(if they're in the list) 18:05:07 they aren't 18:05:11 ah. 18:05:18 and this is a good retrospective topic 18:05:22 well, anyway, my dinner time's a-wastin' =) 18:05:27 #topic https://bugzilla.redhat.com/show_bug.cgi?id=567325 18:05:28 Bug 567325: medium, low, ---, rrelyea, NEW, ifd-egate uses deprecated udev rules syntax 18:05:38 this is the companion bug to the earlier one about esc 18:05:45 well, really, the esc bug is the companion 18:06:02 still waiting on the maintainer to submit a bodhi update? 18:06:05 same story as i said there - we're now just waiting on the esc update to go stable before we can orphan ifd-egate 18:06:34 567325 discusses coolkey; that update's gone stable already 18:06:35 so this still requires action once the update goes stable 18:06:38 so we don't need to worry about it 18:06:39 yes 18:06:55 once the esc update goes stable, this bug gets the ball back, and teh required action is to orphan ifd-egate 18:06:58 at that point we can close the bug 18:07:33 however, even if we didn't manage to orphan it in time for final, as long as the updates both go through i don't think ifd-egate should wind up on any images or default install 18:07:40 so it wouldn't bother the criteria 18:07:49 so i _think_ we can make this not-a-blocker as soon as the esc update goes in 18:08:17 can someone just take a quick look at comps and check if ifd-egate is listed directly at all? i don't have it on this laptop 18:08:56 * jlaska looking at cvs.fedoraproject.org ... 18:09:03 isn't comps in git now? 18:09:50 it is 18:09:53 (in git) 18:10:01 ah, yes it is 18:10:16 hum, just noticed a wrinkle 18:10:33 ifd-egate is one of four packages which supply 'pcsc-ifd-handler' 18:10:35 * jlaska doesn't see ifd-egate in comps 18:10:37 which is required by pcsc-lite 18:10:51 i suppose it's possible ifd-egate wins that race, for composes? 18:11:15 the other candidates are ctapi-cyberjack-pcsc, pcsc-lite-openct, ccid 18:11:39 ccid would likely win 18:11:45 adamw: so you're wondering if other packages would pull in ifd-egate? 18:11:53 either way, as soon as it's possible to block ifd-egate, I'll block it. 18:12:02 actually the compose would pull in /all/ those potential solvers 18:12:10 okay 18:12:11 but the install would likely pick ccid 18:12:11 ah 18:12:29 what #actions are needed here? 18:12:29 still, we probably don't want it showing up on the images, so yeah, we should block it asap 18:13:01 i think oxf13 to block ifd-egate when possible 18:13:18 and i guess me to update the bug and re-request ifd-egate be orphaned when the esc update is complete 18:13:56 #action Oxf13 to block ifd-egate to prevent showing up on F13 media 18:14:24 #action adamw to update 567325 and re-request ifd-egate be orphaned when the esc update is complete 18:14:59 alright next ... 18:15:15 #topic https://bugzilla.redhat.com/show_bug.cgi?id=585250 18:15:16 Bug 585250: medium, low, ---, notting, ON_QA, /var/spool/gdm/force-display-on-active-vt not created with KDM 18:16:25 needs testing, looks like 18:16:26 nice, this got moved to ON_QA 18:16:49 #help Karma feedback needed - http://admin.fedoraproject.org/updates/initscripts-9.02.2-1 18:16:53 it should even be fairly simple to test the actual bug: boot to KDE and check it starts on vt1 18:17:04 #help Karma feedback needed - http://admin.fedoraproject.org/updates/initscripts-9.10-1.fc13 18:17:17 Virt bug are release blocker or not ? 18:17:28 Kyril: if the impact the release criteria 18:17:41 #info testing needed, fix available in bodhi 18:17:49 Kyril: depends what you mean. might be best just to ask about the specific bug you're interested in when we hit open floor 18:18:05 * jlaska drives to the open discussion ... 18:18:07 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586685 18:18:09 Bug 586685: medium, low, ---, twoerner, NEW, iptables prevents ssh login to newly installed smachine 18:18:42 this is the one we talked about on the list 18:18:58 I thought this already was fixed? 18:19:03 I'm talking about this bug, 0xf13 suggested to tag it as F13Beta 18:19:04 https://bugzilla.redhat.com/show_bug.cgi?id=585689 18:19:05 Bug 585689: high, low, ---, jforbes, NEW, qemu-kvm: malloc.c:3096: sYSMALLOc: Assertion failed 18:19:21 Not sure what's going on but i'm being able to reproduce it, always. It kill the VMs 18:19:27 Kyril: we'll get to that one. 18:19:31 apparently, in f12 and previous releases, you could ssh in to a newly installed machine as root immediately... 18:19:49 (this does still hang on the question of whether the network's up after boot, of course) 18:20:03 I don't really care for now since i don't put my computer in hibernation ;) 18:20:14 anyways 18:20:16 sorry, the problem I was thinking about, bug#583986 18:20:18 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=583986 medium, low, ---, twoerner, ON_QA, lokkit creates firewall in selinux only mode 18:20:43 jlaska: i think i wasn't entirely sure whether they were the same bug 18:20:57 Kyril: we'll come to your bug in the open-discussion. If you can, please hang around until then. Otherwise, you can reply to the meeting announcement with the bug and release criteria you feel are impacted by the issue 18:21:26 https://bugzilla.redhat.com/show_bug.cgi?id=568528 is the 'parent' bug for the lokkit thing 18:21:27 Bug 568528: medium, low, ---, msivak, ASSIGNED, firewall --disabled still produces a blocking /etc/sysconfig/iptables 18:21:34 adamw: it's working for me here (ssh as root after F-13 install) 18:21:44 lemme dbl check the kicsktart file used 18:21:52 that talks about doing a kickstart install with firewall --disabled...but i suppose the bug may in fact have been wider and causing this problem too 18:21:55 # Firewall configuration 18:21:55 firewall --disabled 18:22:11 jlaska : when is the open-discussion ? 18:22:23 what kind of firewall config are you supposed to get ootb, if you don't specify it manually at all? 18:22:36 Kyril: after we've gone through the whole bug list 18:22:39 which is taking a while 18:23:00 adamw: it differs from live install vs media install 18:23:38 jlaska: okay...when you say it's 'working for you', with what stuff exactly? 18:23:52 adamw: ignore that ... it was a kickstart install with firewall --disabled 18:24:10 well, that's not supposed to work (that _is_ bug 568528) 18:24:12 someone will need to confirm this issue after a media install 18:24:13 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=568528 medium, low, ---, msivak, ASSIGNED, firewall --disabled still produces a blocking /etc/sysconfig/iptables 18:25:02 tony's report claims the default firewall config blocks port 22, basically 18:25:15 that's likely something new 18:25:24 we should ask more details about exactly what mode of install he used? what behaviour do we expect? do we ever expect port 22 to be blocked out of the box? if so, when? 18:25:50 I'll confirm my findings with a manual install of F-13-Final-TC1 and post to the b 18:25:53 ok 18:25:53 bz 18:26:15 i'll post an urgent needinfo 18:26:50 i'm still honestly not sure what our intended behaviour is here; assuming the network's up (which is only the case on network installs?), we expect the installed system to be immediately remote accessible, directly as root? 18:27:05 if I'm reading anaconda firewall.py correctly, we default to having ssh enabled. 18:27:12 I believe so .. but confirmation needed 18:27:16 okay 18:27:58 easy enough to test here. 18:28:24 okay ... so we'll leave this on the list 18:28:30 request more info from reporter 18:28:40 and likely we'll all be testing this too 18:28:42 sound good? 18:29:01 k 18:29:16 bug updated 18:29:22 #agreed 586685 more information needed from reporter ... unable to determine problem impact. Remain on F13Blocker pending feedback 18:29:41 #action retest 586685 attempt a default install and post firewall rules in bz 18:30:26 #topic https://bugzilla.redhat.com/show_bug.cgi?id=584229 18:30:27 Bug 584229: medium, low, ---, ajax, NEW, Kernel 2.6.33.2-57.fc13.x86_64 fails to show DVI display 18:31:52 looks like hansg set this as a blocker a couple of days ago 18:32:07 i think we should pull ajax in for this if he's around 18:33:42 looks like this affects a rather specific hardware setup - systems which implement a DVI connector via a somewhat janky pseudo PCI-E daughterboard 18:33:52 but the impact is rather severe 18:34:21 there would be a workaround for this, but it'd require some moderate level xorg.conf hackery which may be tricky to document precisely... 18:34:52 adamw: such systems are pretty common (new laptops with ironlake graphics) 18:34:56 i can't easily estimate exactly how much hardware's likely to be affected by this 18:34:58 drago01: ah, thanks 18:35:33 adamw: oh wait no 18:35:40 that does make it rather important. and it's a regression from Beta (introduced in the big intel drm backport) 18:35:40 adamw: sorry confused it with another issue 18:35:54 drago01: yeah that sounded odd...this should be desktops, right? not laptops 18:36:25 adamw: the number of graphics bugs seems infinite in this cylce ... 18:36:45 drago01: it's infinite every cycle; we never get close to fixing them all for any release 18:36:52 drago01: all we can do is cream off the most important 18:37:04 adamw: ;) 18:37:13 ajax doesn't seem to be around 18:37:28 he's around, just otherwise busy 18:37:31 i'm really on the fence with this one. definitely would like to see a fix 18:38:29 i think from the description that this actually breaks console output too, with kms on, which makes working around it all the more complex... 18:38:45 yeah that's problematic 18:39:13 * adamw just had a peripheral thought - when you select the VESA mode for anaconda, does it add nomodeset as a kernel parameter 18:39:34 ah heya ajax, thanks for coming 18:39:42 we're on https://bugzilla.redhat.com/show_bug.cgi?id=584229 18:39:43 Bug 584229: medium, low, ---, ajax, NEW, Kernel 2.6.33.2-57.fc13.x86_64 fails to show DVI display 18:40:00 label vesa menu label Install system with ^basic video driver kernel vmlinuz append initrd=initrd.img xdriver=vesa nomodeset 18:40:11 jlaska: ah, good. 18:40:13 adamw: yes it does add nomodeset when you select "VESA" from syslinux 18:40:43 i think i have that one fixed, just needs a kernel build with the fix and testing. 18:40:49 ajax: any feel for how wide the impact of this bug is likely to be (i don't know how many systems use this daughterboard setup)? 18:40:55 and...you just pre-empted my second question : 18:40:56 :) 18:41:59 any DVI port on an intel chip is actually SDVO 18:42:05 they don't have native DVI 18:42:18 that makes it a blocker 18:42:21 so, laptop docks, anything built into the laptop... 18:42:33 so, anything with an intel chip and DVI is going to hit this? 18:42:37 yeah 18:42:38 eew 18:42:44 okay, definite blocker then 18:42:52 * jlaska doesn't hesitate 18:43:09 #agreed 584229 is a valid blocker. Impacts any Intel chip with DVI 18:43:19 ajax: just so you know, the goal date we're working with is tuesday (4th may) 18:43:24 yep 18:43:31 ajax: but if you have a fix then obviously as soon as you upload it the burden's on testers 18:44:14 #info ajax believes he has a fix, should be able to upload a kernel for testing soon 18:44:26 okay, ready to move on? 18:44:59 #topic https://bugzilla.redhat.com/show_bug.cgi?id=577059 18:44:59 Bug 577059: medium, low, ---, jforbes, ASSIGNED, HSM Failure while ejecting disc images on KVM guest 18:45:30 ah, looks like recent updates from jforbes 18:45:43 " This happens in F-12 guests as well, yet seems to work fine from the anaconda 18:45:46 disc tester, leading me to believe that hal may be involved. The kvm monitor 18:45:49 shows a correct status in all cases (disc is successfully detached). " 18:46:30 ajax: thanks a lot - we may have more issues under xorg-x11-drv-intel later, won't get there for a while though 18:46:53 I don't have a lot of confidence in making changes around the disc eject path again 18:47:41 * adamw doesn't have much of a handle on this 18:47:57 jforbes: what's your take on the blocker-ness of this bug? 18:48:18 are there other failure conditions besides virt multi-disc cdrom installs? 18:48:20 jlaska: my opinion has changed a bit 18:48:39 jlaska: yes, it is ejection of an iso, but this is not a new bug or regression, F-12 suffers from it as well 18:48:54 jlaska: and the fix will be in qemu, not kernel, so I can get a fix out zero day 18:49:09 oh interested, yes 18:49:18 interest _ing_ 18:49:41 jlaska: FWIW, this has never worked that I can find 18:49:46 i think if the fix doesn't have to go into the images, it's not a blocker... 18:50:13 jforbes: really? we've been using this behavior to develop an automated cd swapping test 18:50:24 Yeah, the fix won't even be on the images, qemu isnt on there 18:50:25 but that was against F-12 virt 18:50:37 okay, shall we move this to target then? 18:50:43 jlaska: Ahh, then it is the updated HAL in F13 that triggers it 18:51:21 so this is just a side effect of the hal-ectomy? 18:51:35 jlaska: Actual swapping of CDs works on the md5sum test, so it is the HAL polling that triggers it, but it is qemu that is responding incorrectly which is actually wrong 18:51:43 jlaska: yeah, and I would agree, move to target 18:51:54 okay, jforbes thanks for the debug! 18:52:30 #agreed 577059 can be moved to F13Target. Will be releases as a qemu day-0 update 18:52:38 #undo 18:52:39 Removing item from minutes: 18:52:42 #agreed 577059 can be moved to F13Target. Will be released as a qemu day-0 update 18:52:56 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586916 18:52:57 Bug 586916: high, low, ---, kernel-maint, NEW, Unable to decrypt disk on F-12 x86_64 install on T410: required "rdblacklist=aesni-intel" 18:53:50 added by cebbert 18:54:20 "Ray Strode told me this is an issue with hardware crypto support" 18:55:10 it is affecting new i3/i5/i7 systems and nahelem-ex 18:55:28 the obvious fix would be to disable aesni-intel and enabling it via update once fixed 18:55:45 but afaik kylem was looking at this 18:56:31 well, the affected systems do seem to warrant F13Blocker 18:57:22 i'd definitely want to take a fix for this 18:57:27 I'm +1 for this as a blocker 18:57:32 it's pretty borderline whether it's a blocker, i could go either way...+/-0 18:57:51 yeah what I wanted to say if we cannot fix it in time we should just disable it for now 18:57:59 it is a simple config change 18:58:06 this would impact all new nahelems right? 18:58:10 that seems like the sane approach for now 18:58:19 what does hardware encryption support win us, just performance? 18:58:30 a huge speed boost 18:58:41 okay, but point is, it doesn't change fundamental behaviour 18:58:51 so it's safe to ship with it disabled and enable when it's fixed 18:59:14 * jlaska can't answer 18:59:21 asking drago01 =) 18:59:29 figured ... just noting :) 18:59:39 adamw: yeah it will behave like on any other cpu 19:00:05 okay 19:00:33 which might get bad press when p****x does idiotic benchmarks but well ... 19:01:06 any -1's for blocking on this? 19:01:21 but anyway ... we shouldn't release with the current status ... either fix or disable 19:01:30 none here 19:01:51 #agreed 586916 is a valid release blocker. 19:01:59 bug updated 19:02:04 #info recommend either fixing or disabling aesni-intel for F-13 19:02:14 #topic https://bugzilla.redhat.com/show_bug.cgi?id=572771 19:02:15 Bug 572771: high, high, ---, kernel-maint, NEW, Thaw doesn't work after hibernate with F-13 19:03:14 this is the hibernate issue raised by Oxf13 19:03:41 so the question is whether there is a systemic problem with hybernate 19:03:52 in general we haven't accepted hardware-specific suspend/hibernate bugs as blockers 19:03:56 right 19:04:03 comment #9 seems to suggest this isn't systemic 19:04:26 i don't use hibernate much, only sleep. sleep seems broken on this x60 when in docking station, but works when out of it, and works on my home desktop 19:04:42 can't test hibernate as i don't have space for a swap partition, heh 19:04:42 I put it on the list for review, expecting that it would not be accepted 19:04:50 * jlaska testing hibernate 19:04:51 if it was a systemic issue, perhaps, but this appears to not be such 19:05:04 I don't use it either ... can't do that to my poor SSD ;) 19:05:35 frankly i'm less inclined to accept hibernate bugs as blockers anyway, as hibernation is pretty freaking pointless, but that may be personal prejudice =) 19:05:58 well, I think we can focus on the systemic nature of the problem 19:06:15 #agreed 572771 is not a valid release blocker. 19:06:22 you tested and it works for you? 19:06:28 #info does not appear to be a systemic problem affecting all hibernate 19:06:31 there's also the point this can be fixed post-release, of course. 19:07:26 I don't have problems taking a fix for it ... just not blocking if only a small subset of systems are impacted 19:07:57 F13Target seems appropriate in this case? 19:08:32 yeah 19:08:40 well, i'd want the fix to be fairly small at this point 19:09:06 agreed 19:09:25 bug updated 19:09:44 #topic https://bugzilla.redhat.com/show_bug.cgi?id=583790 19:09:46 Bug 583790: medium, low, ---, tbzatek, NEW, remove .desktop entry in applications > system tools 19:10:11 this is another polish issue, but does hit a criterion 19:10:28 duplicate menu entries 19:10:30 "No application may unintentionally appear twice in the menus. In particular, things under System must not appear under Applications" 19:10:49 no objections here 19:10:51 yeah. the criterion has a _bit_ of wiggle room (it depends how you define 'application'), but i think it's appropriate to consider this infringing. 19:11:13 any -1's out there? 19:11:18 GNOME's paradigm is clearly for you to browse to a place, not to consider nautilus an application you launch. 19:12:22 heh, dutch TV has the world snooker championships. was not expecting that. 19:12:33 +1 blocker. 19:12:35 let's agreed and move on, i'm hungry =) 19:12:49 #agreed 583790 is a valid blocker 19:12:54 #info No application may unintentionally appear twice in the menus. In particular, things under System must not appear under Applications 19:13:09 #topic https://bugzilla.redhat.com/show_bug.cgi?id=567978 19:13:10 Bug 567978: medium, high, ---, dcbw, ASSIGNED, Unable to activate network in loader with [*] Enable IPv6 support 19:13:19 no changes here ... dcbw notes this is a high-priority item 19:13:53 I still believe this impacts anyone doing a network install ... and we need to either not select IPV6 by default, or fix the underlying issue 19:14:44 I can pull in dcbw for an update if others have concerns 19:14:56 yeah, i think it'd be good to hear from dan and make sure he's aware of the tuesday date 19:15:01 okay ... 19:15:33 pinged 19:16:07 if I don't hear back, we can move on in a few minutes 19:16:11 ok 19:16:27 any objections or concerns around blocker worthiness? 19:17:03 nope 19:17:38 though i'm surprisd we're not seeing more reports of this if it really hits any attempted network install 19:18:01 true ... it could be the network we have that exposes the issue 19:18:18 there are 2 other dups on this issue 19:18:51 i did bring a usb stick for emergency testing, but there's no wired network in the hotel 19:19:22 okay, I vote we keep this on the list, ping the bz and move on 19:19:34 okay 19:19:51 #agreed 567978 will remain a F13Blocker. 19:20:21 #info Awaiting further updates from dcbw 19:20:37 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586511 19:20:42 Bug 586511: medium, low, ---, ssorce, NEW, [abrt] crash in samba-client-0:3.5.2-59.fc13: Process /usr/bin/smbclient was killed by signal 11 (SIGSEGV) 19:21:33 seems well-described and clearcut 19:21:39 yeah, kudos to the reporter 19:21:39 it doesn't precisely hit any of our criteria... 19:21:48 I hate it ;) 19:21:57 drago01: the criteria or the bug? :) 19:22:02 this may be a good example of an issue that's serious but can be fixed in an update 19:22:07 jlaska: the bug 19:22:08 adamw: definitely! 19:22:25 any objections? 19:22:58 i'm marking the other bugs noted in the report as dupes... 19:23:01 well yeah I also found that reverting to F-12's libsmbclient works 19:23:14 hope simo is around to get this pushed through 19:23:16 (note there are atleast 2 dupes) 19:23:54 i think we can obviously take the fix for release if it's ready in time 19:24:25 anyone besides simo we can cc on the bug? 19:24:28 * adamw checks 19:24:44 who's gd? 19:24:46 simo might be around in #fedora-devel 19:25:12 adamw: gdeschner@redhat.com 19:25:46 heh 19:25:51 * adamw runs straight into oxf13 19:26:00 bodies everywhere 19:26:05 :) 19:26:45 looks like gd and jlayton are already in CC, as co-owners 19:27:18 okay 19:27:30 want to wait for simo, or get closer to dinner? 19:27:32 let's move on for now...i'll ping the report 19:27:36 if he comes we can circle back 19:27:58 * jlaska notes ... dcbw still agrees on fixing the previous issue and is actively working the problem 19:28:34 #agreed 586511 not a release blocker. Does not impact existing release criteria 19:28:52 #agreed move 586511 to F13Target, accept fix if available in time 19:29:04 #topic https://bugzilla.redhat.com/show_bug.cgi?id=586910 19:29:06 Bug 586910: high, low, ---, bdpepple, NEW, Please update telepathy-gabble to 0.9.11 in F13 19:30:10 interesting, as we sort of explicitly don't cover the non-default spins in the blocker process 19:30:11 according to sebastian, this down-level package is causing the SOAS spin to fail 19:30:18 but given the impact it seems reasonable to take it 19:30:22 is this used by anything else? 19:30:48 used, yes, critical not likely 19:30:53 adamw, I am here now 19:31:14 simo: Hi there ... we'll wrap-up /topic bug and return to the samba issue 19:31:36 jlaska: is SoaS actually a Fedora spin? I thought it wasn't even a spin, but a separate product with its own lifecycle? 19:31:45 is this the age-old ... would we block releasing Fedora for a spin? 19:31:49 if so it doesn't seem reasonable to take this as an f13blocker, but if it's an official f13 product it does seem so 19:32:07 adamw: it's not listed on spins.fp.org 19:32:15 well we didn't last time with the lxde issue, but i thought that was pretty ugly. for real f13 spins i would want to block for a complete meltdown. 19:32:27 adamw, what's the deadline? 19:32:39 adamw, next week all samba devs will be in germany for SambaXP 19:32:43 simo: see the bug comment: deadline to get the package in for final release is next tuesday 19:32:51 simo: but to get it in as a zero-day update you have a bit more wiggle space 19:32:59 adamw, but I guess we can work from there to solve this specific issue 19:33:14 current day-0 deadline is May 18 19:33:21 simo: it does look like the fix is really simple, so if you could just commit it and submit a build over the weekend or from the conference we could do the testing and validation and probably the push to stable 19:33:26 adamw, then you should ping Günther 19:33:34 adamw, I will be traveling Sun/Mon anyway 19:33:57 don't think we're familiar with Günther =) what's his address, to add him to the CC? 19:34:18 or wait, is he 'gdeschner'? 19:34:23 adamw, he is in CC already 19:34:24 adamw: yeah 19:34:26 adamw, yes 19:34:39 adamw, but ping him on IRC 19:34:45 simo: gotcha, thanks 19:34:47 (he is gd on IRC) 19:35:09 adamw, do you still need me ? 19:35:19 #action adamw to ping gd directly on irc re: 586511 19:35:23 simo: i think that was all, thanks! 19:35:32 thank you, bb 19:36:05 so, back to #topic... 19:36:07 adamw: you made a distinction between spins and products? 19:36:17 that wasn't my intention =) 19:36:34 i was drawing a distinction between all the builds that are actually part of F13 (spins and the boot.iso and DVD images) 19:36:48 and things that are based on it but aren't really part of the F13 release...which AIUI is SoaS's status 19:36:48 is SOAS one of the "Spins" I'm supposed to produce this time around? 19:36:55 i don't believe it is 19:36:59 then TARGET 19:37:05 SOAS? 19:37:12 Sugar on a Stick 19:37:14 i believe it's produced by another group and they have used different release dates and even variant packages in the past 19:37:17 ah 19:37:19 so don't see why they can't here 19:37:39 ahem. 19:37:41 SOAS is a F13 spin 19:37:45 https://fedoraproject.org/wiki/Releases/13/Spins 19:37:58 ah, didn't check there ... 19:38:03 * jlaska looked at spins.fedoraproject.org 19:38:16 so I alter my previous vote, and say +1 to blocker 19:38:55 # repoquery --whatrequires telepathy-gabble 19:38:55 sugar-presence-service-0:0.88.0-1.fc13.noarch 19:38:55 empathy-0:2.30.1-2.fc13.x86_64 19:39:35 oh crap 19:39:40 * adamw just got done updating the bug 19:39:46 time to post a 'please disregard' =) 19:41:05 #help Karma test feedback needed - https://admin.fedoraproject.org/updates/telepathy-gabble-0.9.11-1.fc13 19:41:43 I'm on the fence here, but willing to go along 19:42:04 i'm +1 given the lxde experience from f12 19:42:21 having news sites re-post our 'oops, the image is completely useless' blog post didn't feel good 19:42:53 yeah, I'm +1 to that ... just not sure this tight coupling with spins is a good thing 19:43:00 but that's a different topic for another time 19:43:04 it's not in the criteria, but i'd want to take bugs that completely torpedo the viabilit of any official spin as blockers, i think. 19:43:35 #agreed 586910 remains on F13Blocker. No specific release criteria exist, but presence of bug makes SOAS spin unusable 19:44:36 btw, it would also impact the desktop spin somewhat - i believe it'd break jabber support in our stock im client (empathy) 19:45:06 #topic https://bugzilla.redhat.com/show_bug.cgi?id=578965 19:45:07 Bug 578965: high, low, ---, bskeggs, NEW, nouveau driver does not work with geforce 6100 19:45:17 just that for Sugar, collaboration is a huge part of the intended use case, and it's implemented via jabber (all those modes in Sugar where you can see and interact with other Sugar-running machines in the vicinity) 19:45:35 adamw: ah, good to know 19:45:57 WhatMeWorry raised /topic bug on #fedora-qa this morning 19:46:30 it seems to be a strictly single-adapter bug 19:46:36 in general we don't take those as blockers 19:46:38 there's no dupes... 19:46:48 good, I wanted your review on this one 19:46:59 wasn't sure if this was a large range of adapters affected 19:47:10 of course, that relies on me or darktama _catching_ dupes, and i honestly haven't kept up very well lately 19:47:51 previous releases,you often could rely on nomodeset as a fallback 19:47:59 is there a recommended X fallback now? (vesa)? 19:48:02 let me do a quick sweep through open bugs to see if there's any obvious candidates 19:48:17 vesa would be it. we've always said nomodeset would disappear at some point, though. 19:48:34 and we can't realistically patch ums back in at this point. 19:48:54 adamw: certainly, I wasn't suggesting. Just wasn't sure what the fallback was now 19:49:43 there's no equivalent. the reason it worked was simply because you got to use the old UMS code instead of KMS. now that code just ain't there. so yeah, you've lost a potential workaround path. 19:51:41 i see two other complete X fails for nouveau in f13, but neither looks like a dupe of this 19:51:54 three complete-fail adapters isn't actually a bad record, comparing to previous releases 19:52:02 so...i don't think we have something huge going on here 19:52:26 alrighty 19:52:28 so i'm -1 to this as a blocker 19:52:34 Oxf13: ? 19:52:38 drago01: ? 19:52:44 sorry I was deep in investigation mode 19:52:53 * drago01 reads scrollback 19:53:22 yeah, I'm -1 on blocker 19:53:35 yeah -1 does not seem to affect many systems 19:53:53 okay 19:54:26 but if we can get a fix in time 19:54:30 we should let it in 19:54:34 #agreed 578965 is not a valid release blocker. Failure is specific to one NVidia adapter. No reports of widepread failures from other NVidia adapters 19:54:47 I'd want to make sure that the patch is isolated 19:54:52 we've been burned by those before 19:55:23 yeah 19:55:26 #info would consider as a 'nice to have' fix, but would need high confidence the changes don't impact working drivers 19:55:39 last one on my list 19:55:41 #topic https://bugzilla.redhat.com/show_bug.cgi?id=582468 19:55:42 Bug 582468: medium, low, ---, peter.hutterer, ASSIGNED, X server uses the wrong configuration directory 19:56:23 Last week, we left this at #agreed 582468 is a blocker, looks fixed except two updates require proventester karma 19:56:25 i think we can drop this from blocker now? we pushed the important updates through 19:56:50 only fpit needs karma 19:56:56 all the other updates went through already afaics 19:57:00 did I miss one? 19:57:31 I still see /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf 19:57:39 on my system ... but maybe I haven't installed the right update 19:57:52 looks like a compose bug 19:57:52 file /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is not owned by any package 19:57:54 jlaska: well no 19:57:54 Oxf13: territory 19:58:03 jlaska: this file is autogenerated 19:58:05 "This version is not in stable. Although this version was in updates-testing, it is no longer is there and the current version in stable is 0.8-4-1. " 19:58:09 i.e not owen by any rpm 19:58:10 drago01: ah 19:58:13 so it isn't moved 19:58:28 the new system-setup-keyboard should write it to the correct place 19:58:44 *owned 19:58:44 hrm. 19:58:44 * adamw has 0.8.5-1... 19:58:45 I see 19:58:49 let's see if that comment's actually ocrrect 19:59:05 same version ehre 19:59:06 here 19:59:07 repoquery does show only 0.8.4 19:59:17 # locate 00-system-setup-keyboard.conf 19:59:17 /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf 19:59:17 /etc/xorg.conf.d/00-system-setup-keyboard.conf 19:59:27 what's missing from where? 19:59:35 Oxf13: nothing is missing 19:59:39 drago01: wiat 19:59:42 it may be 19:59:43 the file is being generated at runtime 19:59:51 I meant what update is missing from which location 19:59:53 so you might end up having to 19:59:54 drago01: not the file, the correct package may be missing from repos 19:59:57 ah 20:00:05 * adamw checks a mirror 20:00:06 *two 20:00:55 slow mirror link... 20:00:59 that bug is a bit of a mess. What packages are we looking for? 20:01:05 Oxf13: system-setup-keyboard 0.8.5-1 20:01:13 that's the good version 20:01:17 0.8.4-1 is the bad old one 20:01:26 what's the noise about the drv packages? 20:01:35 not noise, they're all part of the same issue 20:01:47 all packages which had .conf files in the directory concerned 20:02:06 the mirror i'm checking seems to have 0.8.4-1, not 0.8.5-1 20:02:20 fucking race conditions and obsleted updates 20:02:33 * adamw wonders if we can hack up some kind of script to compare bodhi and mirrors before going final 20:02:44 i'm worried there'll be another update which has this kind of problem, and we won't catch it 20:02:47 well it's not that 20:02:59 the problem is there were two system-setup-keyboard updates in the mix 20:03:05 one was pushed one day, an older one was pushed later 20:03:10 ah, that case 20:03:10 so the older one wins 20:03:44 I've adjusted the tagging, should resolve itself on the next branch compose 20:03:47 which should be in a few hours 20:03:47 but still, i just mean check for cases where bodhi and the composed repos disagree about the latest approved update, so we can check each case out before going final 20:03:50 since it fell over last night. 20:03:55 ok, cool 20:04:00 so i think we can drop this bug from the blocker list 20:04:02 adamw: I've asked lmacken to do that repeatedly 20:04:18 Oxf13: ah 20:04:24 but you can't assume "highest nvr is the one we want" 20:04:39 no, so that's why i said 'check each case out; 20:04:41 i.e. manually 20:04:52 but at least we'd have a list to work from 20:05:38 anyway, OT 20:05:42 i've removed the bug from the blocker list 20:05:45 so...we're done with the list 20:05:55 so this was a case of multiple update confusion? 20:05:56 finally. 20:06:00 jlaska: yes 20:06:25 sorry, can someone post a summary ... was updating that iptables port:22 bug 20:07:07 #agreed 582468 no longer a blocker as updates have been pushed for all important packages, only fpit remains and it is not important 20:07:17 jlaska: I did some research on that one and have more data if you care 20:07:31 Oxf13: feel free to #info 20:07:37 Oxf13: oh oh, the iptables bug 20:07:40 sure 20:07:54 we can follow up in the bz 20:08:01 let's see what open-discussion has lurking 20:08:09 jlaska: it's a combo of two problems. 1) the bug we know, lokkit creates a firewall stub when using it for seilnux settings. 20:08:33 jlaska: 2) anaconda will not overwrite an existing firewall config when it goes to write out firewall config. SO it runs into the stub written by 1), and skips. 20:08:42 * jlaska can't wait to have tests associated with each anaconda-ks.cfg 20:08:42 ergo we never get our appropriate firewall stuff written out 20:08:53 Oxf13: nice job 20:09:02 this will actually prevent /any/ firewall settings from being written out 20:09:07 a far more serious bug. 20:09:14 indeed 20:09:21 but it should be fixed already, just have to confirm 20:09:39 cool, thanks for the update. I'm cc'd so I'm happy to test if needed 20:09:42 #topic Open discussion - bring out your bugs 20:10:16 Sho_ mentioned 2 bugs to me privately 20:10:18 .bug 572281 20:10:19 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=572281 medium, low, ---, richard, NEW, preupgarde fc12->fc13 fail 20:10:21 jlaska: Bug 572281 preupgarde fc12->fc13 fail - https://bugzilla.redhat.com/show_bug.cgi?id=572281 20:10:22 Bug 572281: medium, low, ---, richard, NEW, preupgarde fc12->fc13 fail 20:10:36 did we discuss the x corruption / crash bugs? 20:10:43 .bug 587378 20:10:44 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=587378 medium, low, ---, richard, NEW, No rpms are downloaded 20:10:44 jlaska: Bug 587378 No rpms are downloaded - https://bugzilla.redhat.com/show_bug.cgi?id=587378 20:10:45 ugh yes, preupgrade is in a "state" 20:10:46 Bug 587378: medium, low, ---, richard, NEW, No rpms are downloaded 20:10:54 drago01: skipped over because they're MODIFIED/ON_QA 20:11:11 though we may have to do a roundup of those on monday...there's a lot 20:11:31 adamw: ok, I have good and bad news 20:11:33 so the new preupgrade (0.15) didn't help? 20:11:49 * adamw really has to go and eat dinner, like, now 20:11:53 adamw: no, these came up from yesterdays test day 20:12:10 it's preupgrade, so having it block F13 isn't exactly appropriate 20:12:11 but anyway ... it is still a mess 20:13:23 jlaska: well, we did for f12. we wanted preupgrade working before we did the release. we had the bug block f12blocker but let it ride past the compose date, as long as it was fixed by release date. 20:13:37 right, sorry, that's what I meant 20:13:43 it's not needed for compose, but for release date 20:14:35 so preupgrade seems to function fine under ideal conditions, but is *very* fragile still, and these 2 bugs are an indicator 20:14:46 I'll probably add 587378 to F13Blocker, since there were multiple reports of this yesterday 20:15:38 .bug 587627 is another common one 20:15:39 jlaska: Error: '587627 is another common one' is not a valid integer. 20:15:39 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=587627 medium, low, ---, richard, NEW, Kickstart file is not generated when no space for install.img 20:15:58 so I'll add these to the list, and try to catch up with hugshie for his thoughts 20:16:08 any other topics to discuss here? 20:16:14 * jlaska will close out in several minutes 20:17:14 if ya'll have karma to give, give it soon. I'm going to lunch, then do an 13 updates push, then kick off another branched compose 20:17:28 hopefully that'll roll up some of these modified and ON_QA things 20:17:31 Oxf13: another compose? 20:17:47 oh ... branched == development/13 nightly compose? 20:17:50 yes 20:17:58 it fell over last night due to unsigned rpms 20:18:11 ah 20:18:16 * nirik goes to run fedora-easy-karma 20:18:26 okay folks ... I'm calling end of meeting 20:18:28 but now it only takes 3 hours, so it's not terrible to re-do 20:18:33 thanks everyone for your time, I know these are tough 20:18:45 go forth and eat 20:18:48 but these do pay off! 20:19:06 as always, please feel free to respond to the meeting minutes with any additional concerns/issues 20:19:21 adamw: thanks for the bz notes 20:19:24 #endmeeting