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