fedora-bugzappers
LOGS
14:58:39 <jlaska> #startmeeting F-12 Beta Blocker Bug Review
14:58:39 <zodbot> Meeting started Fri Oct  2 14:58:39 2009 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:58:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:58:49 <jlaska> #chair adamw
14:58:49 <zodbot> Current chairs: adamw jlaska
14:59:05 <jlaska> #topic Gathering warm bodies ...
14:59:15 * stickster is lurking
14:59:19 <jlaska> someone please queue the muzak and we'll get started soon
14:59:30 <jlaska> feel free to say 'hello' for the logs
15:00:05 <adamw> hello, logs
15:01:37 <jlaska> we'll get things started in a few minutes ... waiting a few more minutes for critical mass
15:01:55 <jlaska> I see we got notting lurking ... that's 'a good thing [tm]'
15:02:01 <adamw> mclasen: notting: ping
15:02:18 * mclasen is here, but goes for coffee
15:02:23 <notting> ... yes?
15:02:55 * thomasj lurking
15:03:04 <adamw> notting: haha, we caught you
15:03:06 <jlaska> thomasj: welcome
15:03:12 <adamw> you are now officially present for the blocker review meeting
15:03:19 <thomasj> Hello :)
15:03:20 <denise> jlaska, I'm here
15:03:27 <jlaska> denise: howdy!
15:03:31 <adamw> hi denise
15:03:45 * SMParrish lurking in the shadows
15:04:01 * steved hides in the corner.... :)
15:04:10 * jlaska turns on the corner light
15:04:12 <adamw> jlaska: i'd say we've gone all critical up in this mass
15:04:14 <jlaska> welcome steved and SMParrish
15:04:17 <jlaska> let's get movin!
15:04:29 <adamw> is that the approved phraseology?
15:04:31 <jlaska> I'm going to start walking down the bugs at ...
15:04:34 <jlaska> #link https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1
15:04:43 <jlaska> adamw: perhaps get'r'done is more appropriate
15:04:51 <adamw> heheh
15:04:54 <jlaska> okay ... first up ...
15:04:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=516042
15:04:57 <buggbot> Bug 516042: medium, low, ---, rvykydal, MODIFIED, Unable to add NFS yum repo during installation
15:05:40 <adamw> going on the last two comments i suspect it's fixed...
15:05:52 <jlaska> with possible new bugs coming soon it seems?
15:06:07 <jlaska> it's MODIFIED right ... yeah
15:06:16 <adamw> hopefully they'll be gone by now, but yeah
15:06:23 <jlaska> I'll see if I can test this after the meeting and follow up w/ kparal on Monday
15:06:29 <adamw> great
15:06:36 <jlaska> any other action needed on this?
15:07:05 <notting> (sorry, i'm double booked. may not be paying too much attention)
15:07:18 <jlaska> #action jlaska to retest using anaconda-12.32 and post feedback into 516042
15:07:39 <jlaska> #action kparal to assist with filing any additional failures on the repo dialogs next week
15:07:57 <jlaska> okay next up ...
15:08:00 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=519237
15:08:01 <buggbot> Bug 519237: medium, low, ---, kzak, ASSIGNED, -bash: cannot set terminal process group (-1): Inappropriate ioctl for device
15:08:14 <jlaska> this is probably tops on my annoying bugs list
15:08:44 <adamw> recent discussion seemed to suggest progress is happening, though
15:08:44 <jlaska> affecting any console=ttyS0 installs (virt, remotely managed systems including ppc, blades etc...)
15:09:10 <jlaska> yeah, I posted some test feedback on the latest packages earlier, it didn't seem to change the result ... unless I missed a step
15:09:17 <jlaska> lemme see if kzak is around ...
15:09:23 <adamw> the thought occurs that perhaps you need to rebuild the initrd?
15:09:42 <jlaska> oh duh ... I didn't think about that ... thx
15:09:45 <adamw> really just guessing, though
15:10:10 <jlaska> I'll restest with that ... either way I think it goes back to the maintainer for next steps, right?
15:10:32 <jlaska> #action jlaska to retest updated util-linux packages in 519237 using a rebuilt initrd
15:10:59 <adamw> well if it's fixed i don't think it needs to go back does it? :)
15:11:07 <jlaska> they've got to tag etc...
15:11:22 <jlaska> so ... is it a beta blocker ...
15:11:34 <denise> jlaska, pinged kzak to look again
15:11:46 <jlaska> it's probably low on the severity ... but high on visibility/annoyance imo
15:11:56 <jlaska> denise: great, thank you
15:12:08 <adamw> jlaska: i'm still not clear on what the actual impact is?
15:12:19 <jlaska> any time you hit <ctrl>-c from the shell ... it reboots
15:12:29 <adamw> erk. i see.
15:13:07 <adamw> it's kind of on the bubble for me
15:13:08 <adamw> anyone else?
15:13:53 <jlaska> I think I'm more annoyed by it since all of my testing is from remotely managed systems using serial consoles (virt, blades, ppc etc...)
15:14:02 <jlaska> but that might not be common, I don't know
15:14:05 <jlaska> lemme ask crobinso
15:14:27 <denise> but will be common for servers certainly, so good to fix it now ...
15:15:08 <jlaska> hey crobinso thanks for joining
15:15:11 <crobinso> np
15:15:22 <jlaska> question about /topic bug
15:15:38 <jlaska> curious what your take is on impact to virt users
15:15:59 <jlaska> the affected users here are those accessing systems using a serial console (e.g. console=ttyS0)
15:16:23 <jlaska> the impact is when you type: <ctrl>-c on the connected console ... it seems to reboot the system
15:17:16 <jlaska> I do most of my testing using console= ... so I hit it all the time ... but I'm curious how common serial console use is for virt users
15:17:25 <jlaska> nirik: howdy
15:18:12 * nirik waves hello.
15:18:38 <crobinso> jlaska: casual users understandably don't use it, but lots of developers will be affected. if it can reasonably fixed I think it should be.
15:19:07 <jlaska> crobinso: cool, thanks for your input
15:19:35 <jlaska> so with denise and crobinso feedback, I think that's enough to keep this on the list for the beta ... objections?
15:20:09 <adamw> ok by me
15:20:28 <jlaska> perhaps we need to revisit should this updated package not resolve the core issue
15:21:04 <jlaska> #agree keep 519237 on the F12Beta list ... impacts developers and servers
15:21:22 <jlaska> #action jlaska will retest after rebuilding the initrd with the updated packages installed
15:21:41 <adamw> i think it's #agreed isn't it?
15:22:13 <jlaska> oops yeah thx
15:22:17 <jlaska> #agreed keep 519237 on the F12Beta list ... impacts developers and servers
15:22:25 <jlaska> okay, next up ...
15:22:27 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=522675
15:22:28 <buggbot> Bug 522675: high, low, ---, kernel-maint, ASSIGNED, mouse,keyboard don't work when boot from LiveCD
15:23:11 <adamw> i'm really not sure about this on
15:23:11 <adamw> e
15:23:17 <adamw> i don't think we have much of a feel for its impact
15:23:44 <adamw> i booted yesterday's x86-64 live image and my USB mouse and PS/2 keyboard worked okay...
15:23:46 <jlaska> nor do I ... and Liam is away on holiday right now ... so we'd need to find another reproducer
15:23:54 <jlaska> I booted i686 this morning
15:24:27 <adamw> this is specific to x86-64 so far as we know (all affected were running x86-64 and liam says he booted i686 on the same machine and it worked)
15:24:55 <jlaska> recommendations?
15:24:57 <adamw> andy's problem looks pretty different to me, which means liam seems to be the only confirmed sufferer
15:25:07 <adamw> on balance i'm for dropping it unless we hear from others
15:26:09 <jlaska> #help anyone experiencing problems with USB keyboard/mouse ... please add thoughts to bug#522675
15:26:10 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=522675 high, low, ---, kernel-maint, ASSIGNED, mouse,keyboard don't work when boot from LiveCD
15:26:35 <jlaska> with the information we have right now ... I don't have objections
15:27:01 <jlaska> hopefully cebbert's feedback helps get Liam a bit further along
15:27:48 <jlaska> #action remove from F12Beta and continue working this issue
15:28:06 <jlaska> anyone want to volunteer to update the bz?
15:28:32 <adamw> will do
15:28:38 <jlaska> adamw: many thanks
15:28:51 <jlaska> alrighty ... next up
15:28:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526158
15:28:57 <buggbot> Bug 526158: medium, low, ---, kernel-maint, NEW, font of f12 beta terminal is very big
15:30:04 <jlaska> denise: looks like clumens is seeing this issue as well
15:30:28 <Oxf13> I'm here on my phone. Having kernel issues on the laptop
15:30:42 <jlaska> I can confirm, but recent feedback from IBM is they aren't too concerned about VGA related issues on ppc64 since the common connectivity is through a management console
15:30:46 <jlaska> Oxf13: welcome!
15:31:05 <adamw> Oxf13: beta blocker type kernel issues? :)
15:31:17 <denise> jlaska, yes, and he had workround
15:31:35 <jlaska> workaround was to change vt's iirc?
15:31:40 <adamw> yeah, comment #1
15:31:47 <Oxf13> adamw: Sorta. Iwlagn spiking the CPU after a few minutes of uptime and use
15:31:48 <adamw> given that there's a usable workaround i'd suggest demoting this
15:32:00 <jlaska> okay, I'm going to drop this from F12Beta and add a comment
15:32:03 <jlaska> insert objections here
15:32:24 <denise> works 4 me
15:32:49 <jlaska> #agreed remove bug#526158 from F12Beta  ... reasonable workaround exists and specific to VGA on ppc64
15:32:51 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526158 medium, low, ---, kernel-maint, NEW, font of f12 beta terminal is very big
15:33:10 <jlaska> #action jlaska to remove 526158 from F12Beta
15:34:02 <jlaska> okay ... next up
15:34:05 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526208
15:34:07 <buggbot> Bug 526208: low, low, ---, skvidal, ASSIGNED, preupgrade failed from old release(f10, f11)
15:35:01 <adamw> looks pretty blocker-y to me unless we find a workaround, i think we want our approved upgrade methods working at this point
15:35:46 <jlaska> so preupgrade is official now?
15:35:50 * jlaska queues up install-guide
15:36:13 <Oxf13> Would like to get at least one other person to repro
15:36:15 <adamw> i believe it's the recommended in-place install method, isn't it?
15:36:35 <adamw> uh, in-place upgrade
15:36:40 <jlaska> stickster: do you have a link to the in-draft F12 install guide?
15:36:41 <Oxf13> Yes
15:36:50 <stickster> jlaska: Let me see
15:37:19 <stickster> http://docs.fedoraproject.org/drafts.html
15:37:33 <jlaska> nice, thank you
15:37:58 <stickster> jlaska: I'm going to have to run afk now
15:38:34 <jlaska> http://docs.fedoraproject.org/install-guide/f12/en-US/html-single/#d0e17809
15:38:48 <jlaska> that was more for my own edification ... but cool, it's documented now too
15:39:38 <jlaska> so we need more feedback on affected users?
15:40:39 <jlaska> Hey wwoods, thanks for joining
15:40:41 <wwoods> 'sup?
15:40:46 <Oxf13> Or somebody to reproduce
15:40:51 <jlaska> we're reviewing the /topic bug for it's F-12-Beta blocker worthiness
15:41:04 <adamw> its :)
15:41:06 <jlaska> since you're familiar with the code, I was curious if you had insight as to the impact
15:41:29 <jlaska> adamw: yeah yeah ;)
15:41:34 * jlaska locates his oxford manual
15:41:42 * adamw learned something interesting about apostrophes the other week
15:41:45 <adamw> i'll edificate you later
15:41:51 <wwoods> so yeah there's no traceback in there
15:41:52 <jlaska> hah
15:42:05 <wwoods> someone else needs to attempt to reproduce by running it from a terminal
15:42:38 <jlaska> and this is testing preupgrade from F-10 -> F-11 right?
15:42:50 <jlaska> which might apply also to F-12 when it's pre-upgradable?
15:43:14 <Oxf13> I thought it was going from 11 to rawhide
15:43:17 <adamw> um i think he was testing from f-11 to rawhide
15:43:24 <Oxf13> I have a friend who just did 10 to 11 and that worked fine for him
15:43:36 <adamw> "F12-beta-tc"
15:43:55 <adamw> i can test this if no-one else can, but i suspect it'd be more efficient for someone in an office with copies of f11 lying around and a fast f12 download
15:44:06 <jlaska> cool, okay same thing here ... Rui will be out until the 8th as well
15:44:12 <wwoods> 10 to 11 is fine
15:44:18 <wwoods> it's 11 to 12 that's the problem
15:44:23 <jlaska> let's queue the meetbot batsignal ...
15:44:31 <wwoods> I'm installing F11 on a spare machine right now
15:44:52 <jlaska> #help Help testing preupgrade from F-11 -> rawhide is needed ... please update bug#526208 with your findings
15:44:54 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526208 low, low, ---, skvidal, ASSIGNED, preupgrade failed from old release(f10, f11)
15:45:00 <wwoods> is there an RDU-local URL for the F12b test compose"?
15:45:08 <jlaska> so we leave this on ... awaiting test results?
15:45:17 <adamw> i'd say so
15:45:24 <jlaska> wwoods: sure ... I've got a cobbler url ... will find shortly ...
15:45:46 <jlaska> #agreed Bug#526208 remains on the list and awaits additional testing to provide traceback
15:45:57 <jlaska> next up ...
15:46:00 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526320
15:46:01 <buggbot> Bug 526320: medium, low, ---, notting, ASSIGNED, ppc64.img and ppc32.img missing from tree
15:46:26 <jlaska> Oxf13: for this, I think we should consult the industry standard terms for a beta
15:46:42 <adamw> don't see much to say here, i think it's clearly a blocker and waiting on a fix...
15:46:56 <jlaska> 'cause, the impacted users of ppc32.img and ppc64.img is probably low ... but it bothers me slightly that they were present in the Alpha and might be missing for Beta
15:47:09 <jlaska> adamw: oh okay ... cool, I thought I'd have to push hard on this one :)
15:47:14 <Oxf13> jlaska: I'm still working on this one
15:47:20 <Oxf13> I'd consider it a beta blocker of a kind
15:47:26 <Oxf13> if we care about ppc
15:47:28 <adamw> i think no matter the number of users, ppc is a supported platform, we can't have install images just suddenly go missing in the final pre-release, doesn't seem like an option to me
15:47:47 <jlaska> agreed ... thx Oxf13 + adamw
15:47:56 <adamw> Oxf13: we've already solved the 'do we care about ppc' issue by not caring about it for f13, but for f12 we have to :)
15:48:08 <Oxf13> I have no jury duty today so I can work on this all day long
15:48:24 <jlaska> #agreed Bug#526320 remains a F12Beta blocker - can't have install images go missing for a primary arch
15:48:25 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526320 medium, low, ---, notting, ASSIGNED, ppc64.img and ppc32.img missing from tree
15:48:46 <jlaska> #action Oxf13 will continue working 526320 for root cause
15:48:56 <jlaska> alrighty ... next up
15:49:02 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526380
15:49:03 <buggbot> Bug 526380: medium, low, ---, xgl-maint, NEW, Xorg update kills graphics
15:49:54 <jlaska> I belive this is fixed now but the bz state is still in NEW
15:50:15 <jlaska> confirmation of fix in comment#10 and comment#11
15:50:38 <Oxf13> ok, so this should be MODIFIED until that build is tagged
15:50:44 <Oxf13> unless it is already tagged
15:50:55 <adamw> right
15:51:09 <adamw> change done
15:51:29 <Oxf13> actually one later than that is already tagged
15:51:35 <Oxf13> so this can be CLOSED->RAWHIDE
15:51:37 <adamw> ok
15:51:44 <jlaska> #agreed bug#526380 remains on blocker list ... newer package already tagged
15:51:45 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526380 medium, low, ---, xgl-maint, MODIFIED, Xorg update kills graphics
15:52:00 <jlaska> #action move 526380 to CLOSED -> RAWHIDE as a newer package is already available
15:52:19 <adamw> Oxf13: what's the ticket URL?
15:52:19 <jlaska> adamw: you got that change too?
15:52:26 <adamw> yeah if i can get the ticket from oxf13
15:52:40 <Oxf13> I don't know what the ticket url is but, I see a newer one already tagged with f12-beta
15:52:46 <adamw> okay...
15:53:02 <Oxf13> https://fedorahosted.org/rel-eng/ticket/2250
15:53:16 * adamw notes that trac's search functionality stinks
15:53:27 <Oxf13> it got tagged yesterday, so it should be in today's rawhide for verification
15:53:42 <jlaska> I updated to it from the static repo this morning
15:53:48 <jlaska> I can boot with kms again ... yay
15:54:01 <Oxf13> adamw: really? I searched for "xorg-x11" and it was the first hit
15:54:07 <jlaska> alrighty ... next up ...
15:54:12 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526470
15:54:13 <buggbot> Bug 526470: medium, low, ---, harald, NEW, NFSv3 mounting broken in dracut netboot
15:54:32 <Oxf13> This should be fixed multiple ways
15:54:52 <Oxf13> a) code fix tagged to force v3 mounting in dracut, and b) nfs-utils change reverted to use v3 first
15:55:26 <adamw> anyone with the setup to test?
15:55:35 <Oxf13> warren has
15:55:45 <adamw> are the fixes tagged?
15:55:46 <jlaska> steved is this one you can help with?
15:55:55 <Oxf13> adamw: yes, they got tagged yesterday
15:56:20 <adamw> Oxf13: hum, on the tagging topic - the rawhide change mail for today is empty
15:56:27 <adamw> (except for the deps report)
15:56:38 <adamw> bug in the mail, or bug in the compose?
15:57:00 <Oxf13> probably a bug in the mail
15:57:21 <Oxf13> cause I got a lot of files
15:57:27 <adamw> ok
15:57:31 <adamw> so we can mark this as modified at least
15:57:32 <adamw> and NEEDSRETESTING?
15:57:39 <Oxf13> /srv/mirror/development/i386/os/Packages/xorg-x11-server-Xorg-1.6.99.903-2.fc12.i686.rpm  came across in my sync
15:57:49 <Oxf13> adamw: sounds right
15:58:14 <jlaska> sounds like no question as to whether it's a blocker or not
15:58:22 <Oxf13> repodiff fell over.
15:58:33 <Oxf13> jlaska: well, nfsroot in dracut is not exactly critical
15:58:39 <steved> jlaska: I'm here...
15:58:39 <Oxf13> but I think we've fixed it anyway
15:59:15 <Oxf13> adamw: yeah, repodiff command failed for some reason
15:59:27 <steved> Oxf13: on nfs-utils?
15:59:45 <Oxf13> steved: I don't think it had anything to do with nfs-utils
15:59:50 <jlaska> do these changes have any possibility of making things worse for the beta?
16:00:12 <Oxf13> jlaska: no
16:00:20 <Oxf13> jlaska: well, the nfs-utils one no
16:00:26 <adamw> 'force v3 mounting in dracut'...what if the server's v4?
16:00:28 <Oxf13> I don't know what was done to dracut
16:00:39 <Oxf13> I only guessed at forcing v3
16:00:41 <adamw> ah
16:00:42 <Oxf13> it may just be setting up the nfs config file to assume v3
16:00:48 <adamw> who'd know about the change?
16:01:02 <steved> yes '-o v3' works
16:01:08 <Oxf13> warren or harald
16:01:18 <steved> I told warren
16:01:36 <Oxf13> - mount nfs3 with nfsvers=3 option and retry with nfsvers=2
16:01:52 <adamw> neither warren nor harald appear to be around :/
16:01:57 <steved> not when the version is specified on the command line
16:02:02 <Oxf13> of course, there are a shitton of other changes here, didn't notice that before :/
16:02:26 <steved> Oxf13: when the version is specified in the config file yes,
16:02:50 <steved> Oxf13: that was one of those late breaking patches
16:03:12 <Oxf13> Ok, I'm a tad bit confused here.
16:03:33 <steved> about what?
16:03:39 <Oxf13> about what you're talking about
16:03:53 <steved> ok lets step back....
16:03:55 <jlaska> Have we decided whether 526470 is a valid Beta blocker?
16:03:57 <Oxf13> steved: the changelog entry I pasted was from dracut
16:04:24 <steved> Oxf13: ok... I see the confusion...
16:04:47 <Oxf13> jlaska: I think the dracut mounting nfsv3 itself is not necessarily a blocker, but it is a symptom of a larger issue, which is a blocker
16:04:47 <adamw> jlaska: i'd say it is
16:04:56 <adamw> like jesse said
16:04:58 <Oxf13> jlaska: the larger issue was that nfs-utils defaulted to trying v4 mounts.  That change has been reverted.
16:05:04 <steved> Oxf13: it seems from that changelog that dracut will be doing the version retry... what I was talking about is how things generally retry
16:05:16 <Oxf13> before that change was reverted, dracut was modified.
16:05:29 <Oxf13> whether or not that modification will break things now that nfs-utils has reverted remains to be tested
16:06:06 <jlaska> sounds like warren already has the setup to help provide feedback here
16:06:25 <Oxf13> yeah, but he's not online that I can see
16:06:30 * jlaska doesn't see warren online
16:06:40 <Oxf13> so this NEEDSRETESTING
16:06:41 <mclasen> he's not in the office
16:06:44 <Oxf13> and MODIFIED
16:06:53 <Oxf13> notting might be able to setup such a rig
16:06:55 <adamw> already done
16:07:00 <adamw> (the changes on the bug, i mean)
16:07:32 <Oxf13> I have to step out for a second and fetch breakfast
16:07:38 <Oxf13> back in about 5 or less
16:07:49 <jlaska> #agreed bug#526470 represents a larger issue related to the nfs-utils defaulting to v4 mounts (and then reverting).  This issue should remain a blocker and needs retesting
16:07:50 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526470 medium, low, ---, harald, MODIFIED, NFSv3 mounting broken in dracut netboot
16:08:30 <jlaska> #action Provide test root=nfs:... test feedback for bug 526470
16:08:40 <jlaska> okay ... that's it with the list
16:08:47 <jlaska> I'm going to refresh though, since I know there are changes
16:09:00 <adamw> there are
16:09:05 <adamw> someone just threw the mdadm bug on there
16:09:10 <jlaska> okay ...
16:09:10 * steved adds him set to bz526470
16:09:12 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=517260
16:09:13 <buggbot> Bug 517260: medium, low, ---, anaconda-maint-list, ASSIGNED, liveinst fails at partitioning screen
16:09:23 <jlaska> I'm hitting this today on 3 out of 3 live installs
16:09:32 <jlaska> this was formerly closed and seems was already on F12Beta
16:09:42 * mclasen throws https://bugzilla.redhat.com/show_bug.cgi?id=526652 in the ring
16:09:43 <buggbot> Bug 526652: urgent, urgent, ---, rstrode, ASSIGNED, Boot fails on encrypted system since 2.6.31.1-52.fc12
16:10:06 <jlaska> mclasen steved: cool, I'll hit those bugs too as I walk the refreshed list
16:10:26 <adamw> steve added himself to the CC for a bug we already looked at :)
16:10:36 <adamw> jlaska: i'd say that's clearly a blocker, denise?
16:10:40 <jlaska> denise: think someone can look at the reopened /topic bug?
16:10:46 <denise> adamw, i agree
16:10:55 <denise> jlaska, will find a victim
16:10:58 <Oxf13> I'm running 2.6.31.1-56.fc12.x86_64 with encrypted root right now
16:11:03 <jlaska> heh ... 'lucky recipient'
16:11:20 <jlaska> #agreed reopened bug 517260 is a valid blocker
16:11:22 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=517260 medium, low, ---, anaconda-maint-list, ASSIGNED, liveinst fails at partitioning screen
16:11:39 <jlaska> #action denise will help gather some devel feedback on the issue
16:11:46 <jlaska> okay next up ...
16:11:49 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=523862
16:11:50 <buggbot> Bug 523862: urgent, low, ---, dledford, ASSIGNED, mdadm craps at boot
16:12:31 <jlaska> denise: this is the md issue we were discussing yesterday?
16:12:33 <adamw> this seems pretty blocker-ish to me, especially since we have multiple reports
16:12:36 <Oxf13> I have md capable systems here
16:12:56 <denise> jlaska, probably one of them
16:13:03 <jlaska> greenlion: this is your bug, iirc
16:13:20 <greenlion> jlaska, yep. I was hitting it
16:13:28 <jlaska> okay, what action is needed here to move this forward?
16:13:58 <adamw> i think it's on the developer now
16:14:09 <adamw> the reports look pretty good to me, they come with tracebacks and all
16:14:10 <greenlion> jlaska, downgrading mdadm will work, in extreme case...
16:14:39 <jlaska> #agreed bug 523862 is a valid beta blocker
16:14:40 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=523862 urgent, low, ---, dledford, ASSIGNED, mdadm craps at boot
16:14:53 <adamw> who can light a fire under doug? :)
16:15:37 <jlaska> #action feedback needed from dledford on 523862
16:15:59 <jlaska> I think that might be peterm, I don't recall
16:16:08 <denise> jlaska, yes
16:16:21 <jlaska> I can reach out to doug and peter for guidance
16:16:44 <denise> jlaska I can also point dan williams at Intel at the bz and see if he recognizes
16:17:11 <jlaska> cool, thanks
16:17:23 <jlaska> #action denise and jlaska reaching out for helpers
16:17:39 <jlaska> okay, I think we're good to proceed to next bz ...
16:17:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526535
16:17:52 <buggbot> Bug 526535: medium, low, ---, dcbw, NEW, [abrt] crash detected in NetworkManager-gnome-1:0.7.996-3.git20090928.fc12
16:18:37 <adamw> only one reporter
16:18:41 <greenlion> this is my bug too - could someone either confirm it or disprove. there are other crashes reperted for NetworkManager-gnome too
16:19:03 <adamw> rpm -q NetworkManager-gnome
16:19:10 <mclasen> it doesn't crash here...
16:19:10 <greenlion> NetworkManager-gnome-0.7.996-3.git20090928.fc12.x86_64
16:19:13 <adamw> left or right-clicking on the icon doesn't crash it
16:19:30 <Oxf13> I'm a pretty heavy user of nm and I don't get any crashes either
16:19:33 <greenlion> well, not a blocker then, good :)
16:19:41 <Oxf13> so it doesn't seem systemic
16:20:04 <adamw> well...if it's happening to two people i'm worried
16:20:04 <jlaska> mclasen: anything interesting from the backtrace?
16:20:07 <adamw> it'd be nice to figure out the cause
16:20:48 <adamw> i'm asking dan if he can join
16:20:48 <mclasen> nothing I could make out
16:20:54 <jlaska> I'd feel comforable if the backtrace could get a once over to determine impact
16:21:00 <mclasen> I'll poke dcbw
16:21:02 <greenlion> other similar simptom: https://bugzilla.redhat.com/show_bug.cgi?id=526572
16:21:04 <buggbot> Bug 526572: medium, low, ---, dcbw, NEW, [abrt] crash detected in NetworkManager-gnome-1:0.7.996-3.git20090928.fc12
16:21:05 <adamw> mclasen: done already
16:21:11 <mclasen> ah, ok
16:21:17 <jlaska> dcbw: welcome :)
16:21:22 <jlaska> you are in high demand!
16:21:46 <dcbw> so looking at that backtrace, I rewrote that code on Wednesday to fix a bug jrb found
16:22:15 <dcbw> I want to fix one other bug where passwords don't get shown in the connection editor, then I'd like to do a rebuild
16:22:34 <mclasen> yeah, that needs fixing
16:22:41 <adamw> how dangerous are the changes? chances of causing regressions?
16:23:03 <Oxf13> dcbw: planning on a build today?
16:23:15 <dcbw> Oxf13: I'd like to, yes
16:23:20 <Oxf13> ok
16:23:31 <dcbw> Oxf13: then I need to fix a bunch of stuff in modem-manager
16:23:41 <Oxf13> dcbw: critical to the beta?
16:23:41 <dcbw> but that's completely unrelated to this
16:23:43 <Oxf13> ok
16:23:48 <dcbw> Oxf13: probably not critical to a beta
16:23:54 <adamw> dcbw: so bottom line you expect to have this fixed with the changes you'd like to commit?
16:24:16 <adamw> dcbw: also, is 526572 the same bug? i can't tell from the traces (not good at reading 'em :>)
16:24:42 <dcbw> adamw: the specific fix for that bug is http://git.gnome.org/cgit/network-manager-applet/commit/?id=c962d9fa4baf040798e57ae0eaccaa7ccaa3ab53
16:25:06 * dcbw looks at 526572
16:25:42 <dcbw> yeah, looks same, I'll dupe
16:25:46 <adamw> k
16:25:58 <adamw> finally...what's the actual impact of this bug? because it seems inconsistent
16:26:04 <adamw> it's not affecting everyone but seems to be more than one person
16:26:18 <adamw> does it need a certain circumstance to happen? certain number of APs showing up in the list or something?
16:26:23 <jlaska> I think we have a new question being asked forfuture meetings as well ... do we accept 'nice to haves' for critpath packages?
16:28:20 <adamw> i think that's icky :/ depends how nice and how dangerous?
16:28:21 <mclasen> jlaska: I'm pretty sure some of the other fixes in dcbws build are more than nice-to-haves...
16:28:27 <dcbw> adamw: if you want the less-invasive fix for that, we could just do http://git.gnome.org/cgit/network-manager-applet/commit/?id=44f9d86819645161ad884f69b32db8096f7c62a9
16:28:42 <dcbw> adamw: and roll the larger commit in later
16:29:19 <adamw> personally i am somewhat leery about dumping large changes into networkmanager at this point, to be honest, yeah, since it is pretty critical to the out-of-the-box user experience
16:29:34 <mclasen> adamw: of course it depends, but then this is a beta freeze, not a final freeze
16:29:37 <adamw> but what do others think?
16:29:40 <jlaska> dcbw: is that painful to push out just that fix?
16:29:46 <dcbw> jlaska: no
16:30:05 <adamw> gotta go pick up a parcel from downstairs, brb
16:30:17 <dcbw> I don't mind doing a rebuild with just that fix, then I'll keep fixing up the other stuff for a post-beta rebuild
16:30:22 <jlaska> I'm in favor of the simpler fix for the beta and the nice-to-have post beta ... but there's always the argument that we want the code closest to final in the beta to get the most testing
16:30:33 <mclasen> makes no sense to me
16:30:45 <mclasen> wouldn't the risk of landing the other fixes later be even greater ?
16:30:58 <jlaska> I don't think we can turn around enough testing before the beta RC to give enough confidence in the other changes
16:31:18 <mclasen> jlaska: beta rc ? which one is it now ?
16:31:38 <jlaska> mclasen: that's the milestone we are working towards now ... cutting a release candidate for the beta
16:31:58 * mclasen had no idea that betas have release candidates
16:32:05 <mclasen> release engineering is weird and wonderful
16:33:09 <mclasen> then lets land the other fixes in the beta for the release candidate
16:33:15 <greenlion> mclasen, seems beta freeze and final freeze are same things
16:33:16 <adamw> =)
16:33:41 <jlaska> okay ... so what's the best route to get confidence in these changes for the beta?
16:33:51 <adamw> mclasen: that is a reasonable point...if we're going to land the changes it's probably as good to land them now as later
16:34:00 <jlaska> (just to make sure it's in a test-able / usable state for the beta)
16:34:59 <jlaska> and a contigency plan should stuff hit the fan would to rollback to a NM with just that assert removed ... how's that?
16:35:08 <adamw> sure
16:35:25 <adamw> so let's get the change in ASAP so we can all do some testing on it
16:35:37 <jlaska> cool, mclasen or dcbw ... would either of you mind following up to the minutes I'll send with a link to the new packages and possible some things you'd want tested?
16:35:50 <jlaska> (or you can tell us what needs retesting and we can send)
16:36:14 * mclasen appoints dcbw for that
16:36:46 <jlaska> #agreed after good discussion around related changes, the group agreed to accept a fix for bug#526535 and several other NM changes that would be good to get broad testing from beta testers
16:36:46 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526535 medium, low, ---, dcbw, NEW, [abrt] crash detected in NetworkManager-gnome-1:0.7.996-3.git20090928.fc12
16:37:13 <dcbw> jlaska: by which we mean not just the one-line fix, but the commit that redoes some of the menu setup?
16:37:29 <jlaska> dcbw: yeah, that was my understanding ... mclasen?
16:37:36 <adamw> yes
16:37:47 <mclasen> yeah, I'd like to get at least the 'keys not shown' fix as well
16:38:04 <dcbw> mclasen: yeah, thats what I was working on this morning, then going to fix a bunch of stuff in modem-manager
16:38:27 <jlaska> cool, good discussion on that one folks ... always good to exercise caution
16:38:35 <jlaska> okay, refreshing my bz page again ...
16:38:49 <jlaska> looks like no new additions
16:38:53 <jlaska> #topic open discussion
16:39:06 <jlaska> Any other bugs folks would like to review for beta-ness?
16:39:07 * dcbw will fix keys not shown as well, then rebuild pacakges, then follow up on the jlaska's mail with link to packages
16:39:07 <adamw> did we talk about https://bugzilla.redhat.com/show_bug.cgi?id=526652 yet?
16:39:12 <buggbot> Bug 526652: urgent, urgent, ---, rstrode, ASSIGNED, Boot fails on encrypted system since 2.6.31.1-52.fc12
16:39:32 <jlaska> dcbw: thanks for joining (and the action items)
16:39:38 <jlaska> #action dcbw will fix keys not shown as well, then rebuild pacakges, then follow up on the jlaska's mail with link to packages
16:39:50 <dcbw> np
16:39:56 <jlaska> okay ... let's wrap up in 4 minutes ...
16:40:22 <adamw> jlaska: um, see above
16:40:29 <Oxf13> did we talk about mclasen's crypt bug?
16:40:31 <adamw> we still need to look at 526652 as someone proposed earlier
16:40:34 <jlaska> adamw: oh sorry, completely missed it :(
16:40:44 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526652
16:40:46 <buggbot> Bug 526652: urgent, urgent, ---, rstrode, ASSIGNED, Boot fails on encrypted system since 2.6.31.1-52.fc12
16:41:24 * jlaska finds another bug after this to discuss
16:41:32 <Oxf13> and in case it was missed, my system is currently booting with encrypted /
16:42:09 <mclasen> from the last comments, it seems not entirely clear if this was just some transient interaction between plymouth and other packages, or if the latest plymouth is broken for real
16:42:18 <adamw> Oxf13: with plymouth enabled?
16:42:25 <Oxf13> adamw: yeah
16:42:27 <mclasen> unfortunately, my plymouth guy has called in sick today...
16:42:29 <adamw> mclasen: yeah, that's my take too
16:42:30 <Oxf13> the 'fill in the logo' plugin
16:42:39 <adamw> if it's still a bug it seems like a blocker, but things seem...confused right now
16:42:58 <Oxf13> we should have found this during media testing
16:43:03 <Oxf13> if any encrypted installs were done
16:43:10 <Oxf13> I'll make sure to try an encrypted install today
16:43:13 <jlaska> and they were
16:43:23 <jlaska> during both test runs, and during yesterdays test day
16:43:58 <mclasen> and they succeeded ?
16:44:10 <adamw> i'd say we add it to the list in case there's a genuine problem here
16:44:10 <adamw> but ask for clarifications
16:44:25 <Oxf13> adamw: I'd vote for adding it if anybody can reproduce it with fresh installs
16:44:29 <jlaska> mclasen: yeah, I don't have any feedback from those tests similar to what's reported here
16:44:50 <mclasen> ok, I'll see if I can get hold of halfline over the weekend to get his input
16:45:00 <adamw> Oxf13: i think we should add it to the list for now regardless, or else there's a chance it slips through the cracks; even if we suspect it's not really going to be a problem, we can add it and remove it once we're sure
16:45:20 <Oxf13> meh, that seems disingenuous
16:45:32 <adamw> twaugh's online ATM
16:45:33 <jlaska> well, if we kick it off the list ... we won't look at it
16:45:35 <adamw> should we see if we can pull him in?
16:45:40 <jlaska> yeah
16:45:48 <Oxf13> jlaska: we would if we try to do encrypted installs and they fail
16:46:03 <Oxf13> jlaska: which it seems like we'd need to do before /really/ considering this a blocker
16:46:12 <wwoods> so uh, quick summary - looks like preupgrade is working but the UI isn't updating
16:46:35 <adamw> i pinged twaugh
16:47:07 <adamw> Oxf13: it's possible there's some wrinkle here which explains why we don't see it, but wouldn't make it not a blocker...
16:47:11 <adamw> hi twaugh
16:47:15 <twaugh> Hi there
16:47:20 <adamw> we're arguing about 526652 :)
16:47:36 <wwoods> I've got two upgrades running right now but the 'download packages / write metadata' step is waaay fast when the package payload is all on a gigE link
16:47:38 <adamw> first, are you still seeing it with today's rawhide? because we do regular tests with encrypted root and haven't seen it, and jesse doesn't see it on his personal system either
16:47:58 <twaugh> I was seeing it this morning before updating
16:48:15 <twaugh> I can reinstall the kernel package now (to redo the initrd) and test it...
16:48:21 <adamw> that'd be helpful yep
16:48:28 <twaugh> Two minutes...
16:48:31 <adamw> the other question - is there anything at all unusual about your setup that you can think of?
16:48:36 <adamw> ok, will wait till you get back :)
16:48:36 <twaugh> Oh...
16:48:43 <twaugh> No, not really
16:49:01 <twaugh> It's a standard encrypted installation, all done through anaconda, with one exception:
16:49:28 <twaugh> I have an extra SATA disk since the anaconda installation, which I created an encrypted FS on with gnome-disk-utility
16:49:45 <twaugh> That's set in /etc/crypttab, and in /etc/fstab, and mounted on /mnt/backup at boot
16:49:53 <adamw> okay...
16:50:11 <twaugh> I could try disabling that to see if it's relevant?
16:50:12 <adamw> well it'd be great if you can test it with a re-generated initrd as you suggest
16:50:17 <adamw> and even greater if you could possibly test without that disk?
16:50:17 <adamw> yes :)
16:50:32 <adamw> one test at a time of course - if you don't experience it even with the disk connected after regenerating, that'd be fine
16:50:32 <twaugh> OK, two minutes...
16:51:09 <jlaska> so we'll wait for feedback from twaugh ... or would folks like to move on?
16:51:43 <jlaska> I've got another bug that stickster suggested as a regression
16:52:10 <jlaska> #action twaugh going to retest 526652 to further isolate the root cause
16:52:28 <Oxf13> sure
16:52:36 <adamw> we can discuss another bug while he's away i guess
16:52:41 <jlaska> alrighty ...
16:52:45 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=518880
16:52:46 <buggbot> Bug 518880: medium, medium, ---, bnocera, NEW, totem no longer searching for plugins
16:53:38 <jlaska> mclasen, looks like you've got some insight on this already
16:53:47 <mclasen> we're going to get a new gst-plugins-base release on monday
16:53:52 <mclasen> that will include some fixes
16:54:05 <mclasen> not sure if it will include enough to fix codec installation
16:54:13 <mclasen> but bastien is waiting for that release anyway
16:54:33 <Oxf13> that doesn't seem beta blocker ot me
16:54:42 <Oxf13> particularly if we're not going to get a fix until Monday or later
16:55:07 <jlaska> yeah ... if we held for it ... that would likely introduce a slip
16:55:08 <mclasen> we're watching the upstream progress on fixing this
16:55:21 <mclasen> but we don't really want to pull in patches before they are considered ready for upstream
16:55:34 <jlaska> this seems like a good post-beta candidate then based on that
16:55:40 <adamw> yeah, i think it's final blocker but not beta blocker
16:56:20 <jlaska> #agreed 518880 remains a final F12Blocker but isn't appropriate to block beta.
16:57:12 <wwoods> so by the way, the preupgrade bug is arguably not eligible to block F12 since it's a bug in an F11 package
16:57:34 <Oxf13> wwoods: good to know
16:57:36 <wwoods> the fix will involve pushing out a new package to F11-updates, and there's no reason to hold up the F12 push process for that
16:57:49 <Oxf13> Now, did I miss something earlier, or did we go over the missing firstboot bug?
16:57:58 <jlaska> wwoods: sweet, thanks for the quick feedback
16:57:58 <adamw> i don't think that's a sensible rule
16:58:05 <wwoods> yes, ideally we want a fix for that bug before F12Beta goes live, but technically there's no F12 fix needed
16:58:20 <wwoods> so delaying the *compose* makes no sense
16:58:25 <adamw> in this case it could not be a blocker, but just because the bug has to be fixed in f11, it doesn't mean it couldn't possibly block the release of f12, or an f12 pre-release - the important thing is the experience the bug affects
16:58:26 <wwoods> delaying *release* is a different story
16:58:47 <adamw> wwoods: as i understand it, release blockers are what we're doing here.
16:59:02 <adamw> i don't consider setting 'f12beta' on a bug to block the beta's compose, i consider it to block the beta's release...am i wrong?
16:59:06 <wwoods> generally though release blockers are understood to also be compose blockers
16:59:13 <Oxf13> adamw: it blocks the compose
16:59:17 <adamw> hmm. interesting process issue :)
16:59:23 * mclasen thinks that is splitting hairs
16:59:24 <jlaska> yeah ... I can see both sides here
16:59:29 <wwoods> we could totally compose and mirror F12b and just not flip the bit until the preupgrade fix is live in F11
16:59:32 <Oxf13> adamw: can't get into RC stage, until blocker bugs are either closed or MODIFIED
16:59:32 <jlaska> compose is more of our internal method for delivering the bits
16:59:38 <adamw> it may be somewhat overkill to introduce some complex process to deal with that wrinkle when this is the first time we've hit it, though
16:59:41 <wwoods> *if* we actually decided this was a release blocker
16:59:46 <jlaska> but the users just care about the release as a whole
16:59:53 <adamw> wwoods: right, i'm discussing the general issue here, not this specific case
16:59:54 <jlaska> wwoods: does this bug block any preupgrade use?
16:59:59 <jlaska> or more of a UI nit?
17:00:17 <wwoods> jlaska: technically it functions but the UI completely doesn't update for what's usually a couple hours of downloads
17:00:30 <wwoods> everyone will assume it's hung and file bugs
17:00:30 <wwoods> it'll suck
17:00:31 <jlaska> oh ... hrmm, eeew
17:00:46 <mclasen> the ui is part of the functionality
17:01:38 <jlaska> this seems like something we'd want to coordinate an updated package in F-11 for in the near term (prior to F12 final)
17:02:00 * mclasen drops out to test logout
17:02:00 <Oxf13> even if you get it out there, there will be people who don't install the latest updates before doing the pre-upgrade
17:02:08 <adamw> yeah, that is quite bad. so i see the problem that we don't do the compose unless all blockers are fixed, but equally, how can we ensure the _release_ doesn't happen with the bug still in it if we don't set it as a beta blocker?
17:02:18 <adamw> er, still in f11*
17:02:34 <Oxf13> adamw: we play intelligent people who double check such things
17:02:45 <adamw> Oxf13: that sounds implausible ;)
17:02:49 <jlaska> seems fine to me to keep it on F12Beta  (or F12Blocker) list even though it's a different product version
17:02:59 <jlaska> products have dependencies ... this is just one of them, no?
17:03:08 <wwoods> or it can be left as a *release* blocker but we'll just have to remember that we can proceed with compose/push despite it
17:03:22 <Oxf13> right, we either play intelligent people and ignore the fact it is on the blocker list for the compose, or we play intelligent people and double check the update went out before we push the release.
17:03:24 <adamw> well, either way it comes down to someone being smart
17:03:24 <adamw> yeah
17:03:47 <jlaska> so ... Beta or Final ... did we decide?
17:03:53 <adamw> if this starts happening with regularity in future we can design a process so we don't stuff it up, but for now being intelligent works =)
17:04:11 <adamw> jlaska: i'd say beta - people WILL test it, and as wwoods says, if they do, they'll assume it's broken and file bugs, and we will be sad
17:04:13 <adamw> so let's just fix it
17:04:24 <Oxf13> right, beta is the time to test such things like preupgrade
17:04:55 <jlaska> cool, nice work gang ... thanks for the quick feedback wwoods
17:05:03 * adamw notes it's easy to say things like 'let's just fix it' when you're not doing the fixing =)
17:05:24 <jlaska> #agreed bug 526208 represents a valid F-11 preupgrade package bug that should be fixed for F-12-Beta release
17:05:25 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526208 low, low, ---, skvidal, ASSIGNED, preupgrade failed from old release(f10, f11)
17:05:26 * adamw also wonders if we killed twaugh's machine
17:05:39 <jlaska> that's my next q ... who owns that ... skvidal?
17:06:21 <wwoods> pretty much
17:06:27 <jlaska> can someone follow-up with Seth for to confirm?
17:06:31 <jlaska> s/for //
17:06:41 * jlaska likey to typey
17:07:35 <adamw> wow, jlaska went all 19th century on us there
17:09:05 <twaugh> (took a while longer than I anticipated...)
17:09:26 <adamw> np np :)
17:09:27 <adamw> what are the results?
17:09:34 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=526652
17:09:35 <buggbot> Bug 526652: urgent, urgent, ---, rstrode, ASSIGNED, Boot fails on encrypted system since 2.6.31.1-52.fc12
17:09:36 <twaugh> The answers about bug #526652: still happens with current rawhide, no difference with extra disk disconnected and removed from fstab/crypttab
17:09:37 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526652 urgent, urgent, ---, rstrode, ASSIGNED, Boot fails on encrypted system since 2.6.31.1-52.fc12
17:10:25 <twaugh> Tried with dracut-002-11.gita8a3ca51
17:10:39 <twaugh> and plymouth-0.8.0-0.2009.29.09.1
17:10:45 <wwoods> jlaska: I'll check with seth
17:11:26 <Oxf13> twaugh: that's really strange.  I've got nearly the same setup and I boot fine
17:11:29 <adamw> twaugh: erg. thanks. so we don't know why it's happening to you but not to oxf13 / our test beds...
17:11:41 <Oxf13> yeah, this still seems very isolated
17:12:30 <adamw> were you able to get any kind of diagnostics on it?
17:12:38 <twaugh> No, they scroll by way too fast for me to capture
17:13:07 <twaugh> Don't know if harald's added any extra debugging to the latest dracut build
17:13:07 <jlaska> wwoods: thx!
17:13:37 <jlaska> we may have already discussed this ... workarounds?
17:13:58 <adamw> twaugh: the end of the bug seems to be indicating the problem is more in plymouth? is that still accurate for you? it works without rhgb?
17:14:14 <twaugh> It still works fine without rhgb on the command line...
17:14:20 <nirik> twaugh: see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems ?
17:14:25 <adamw> well, that's good, at least we have a workaround
17:14:26 <twaugh> an interesting new development today is that I *do* get the Device or resource busy error message...
17:14:33 <twaugh> but the boot continues fine after that
17:14:56 <twaugh> nirik: yes, rdinitdebug would be perfect if it would add delays to the messages
17:15:20 <nirik> add a 'vga=something' to get more lines?
17:15:34 <twaugh> nirik: good plan
17:15:38 <adamw> nirik: if he's using modesetting he's already getting as many lines as his monitor can give, i think
17:15:53 <nirik> perhaps.
17:15:57 <twaugh> adamw: ah, but I'm not: could that be related?
17:16:04 <adamw> related to the bug, i don't see how
17:16:14 <adamw> but it does mean you could get a higher resolution as nirik suggests, i guess :)
17:16:39 <adamw> you could try it with modesetting, just for kicks, i guess. why do you have it disabled?
17:16:50 <twaugh> I guess if the worst comes to the worst I'll have to try to get serial/parallel console going
17:16:57 <adamw> i suppose it _does_ change the plymouth path so it could have something to do with it, now i think about it...
17:17:06 <jlaska> I've got to step out folks ... do we want to reach a conclusion on this and work it out of meeting ... or can someone close out the meeting when finished discussing here?
17:17:14 <twaugh> adamw: some X bug
17:17:16 <adamw> sure, i'll close it out when we're done with this bug
17:17:20 <jlaska> adamw: thx
17:17:23 <jlaska> you've got chair iirc
17:17:28 <twaugh> adamw: I'll investigate that next week
17:17:34 <adamw> twaugh: hum. if you could try with kms that might be interesting i guess. only other difference i can think of to our test scenarios, at least
17:17:36 <adamw> ok
17:17:50 <adamw> on balance i'm for dropping this from beta blocker since we do have a usable workaround and we can't reproduce it on other systems
17:17:54 <twaugh> OK
17:17:57 <adamw> other opinions?
17:18:13 <adamw> oh, i mean, not promoting it to beta blocker :)
17:18:21 <jlaska> the workaround does it for me ... okay with not having it as a beta blocker
17:18:58 <Oxf13> ditto
17:19:33 <adamw> ok, made a change to the bug
17:20:05 <adamw> #agreed #526652 does not get promoted to beta blocker as it is not reproducible on other systems and a workaround is available
17:20:13 <adamw> thanks a lot for the help twaugh
17:20:19 <twaugh> No problem
17:20:47 <adamw> ok, does anyone have any other bug to raise, or should we end the meeting?
17:21:49 <Oxf13> did anybody talk about the lack of firstboot?
17:22:00 <adamw> i don't recall it coming up
17:22:31 <adamw> bug #?
17:24:13 <adamw> ...
17:24:40 <wwoods> two successful preupgrades (one in virt, one on bare metal) complete
17:24:44 <Oxf13> I don't know if there is a bug yet
17:24:49 <wwoods> definitely just a UI problem
17:24:51 <Oxf13> I just noticed that my kickstart install didn't popup firstboot
17:24:53 <adamw> wwoods: ok
17:25:11 <adamw> hum. didn't actually think about that last time i did an install...
17:25:27 <adamw> anyone else done an install recently and noticed one way or the other?
17:25:53 <Oxf13> I /thought/ I saw some chatter about it, but I can't recall where
17:25:56 <Oxf13> need a brain grep
17:26:18 <adamw> without a bug # or more details not sure we can do much about it right now but it sounds worrying...
17:26:59 <Oxf13> yeah, it'd be a real blocker
17:27:21 * wwoods fires off an F12 install to verify
17:27:26 <Oxf13> ah
17:27:35 <Oxf13> firstboot ERROR: X server failed to start
17:27:53 <Oxf13> then a traceback from RuntimeError: X server failed to start
17:28:13 <Oxf13> error: unexpectedly disconnected from boot status daemon
17:28:26 <adamw> sounds like bad interaction with plymouth maybe
17:28:29 <Oxf13> I've seen this before
17:28:35 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=526842 ?
17:28:36 <buggbot> Bug 526842: medium, low, ---, clumens, NEW, Firstboot not run after installation
17:28:50 <adamw> yes, that's it
17:29:02 <adamw> well, i'd vote we promote it to beta blocker then
17:29:52 <Oxf13> me too
17:30:34 <adamw> ok, will do...
17:30:56 <adamw> i'll ask clumens if he can give us a status update
17:31:02 <Oxf13> I just talked to him
17:31:06 <Oxf13> he kind of needs to talk to the plymouth folks
17:31:11 <Oxf13> the main one is out sick
17:31:25 <adamw> ah ok
17:31:52 <adamw> ok, so...we raise to beta blocker, and it's currently on clumens/plymouth team?
17:32:19 <adamw> #agreed 526842 becomes a beta blocker, action is on developers (clumens+plymouth team)
17:33:07 <Oxf13> yep
17:33:32 <adamw> thanks for catching that one
17:34:53 <adamw> ok, so, meeting end take #2 :)
17:34:57 <adamw> any final points?
17:36:04 <adamw> ok then! thanks all
17:36:08 <adamw> #endmeeting