17:00:01 <jlaska> #startmeeting F-15-Beta Blocker Review#2
17:00:01 <zodbot> Meeting started Fri Mar 18 17:00:01 2011 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:06 <mcepl> the real men don't use trackpads
17:00:10 <jlaska> #meetingname f-15-beta-blocker
17:00:10 <zodbot> The meeting name has been set to 'f-15-beta-blocker'
17:00:18 <jlaska> #topic Roll Call
17:00:38 * tflink is here
17:00:45 <jlaska> hey tflink
17:00:50 * nirik is lurking.
17:01:00 <jlaska> I konw rbergeron is pumped to get this meeting started
17:01:04 <jlaska> know, too
17:01:07 * adamw checks in from starbucks at the bottom of the mountain
17:01:14 * willy_1977 is around...
17:01:18 * rbergeron waves
17:01:36 <jlaska> adamw: willy_1977 rbergeron: hello
17:01:49 <rbergeron> howdy!
17:01:53 <jlaska> I'm guessing dgilmore is right now?
17:02:12 <rbergeron> I hope he Is.
17:02:16 * jsmith is here
17:02:24 * rbergeron waits for jlaska to add the missing word to that sentence
17:02:59 <jsmith> rbergeron: You too, eh?  My parser just segfaulted, and ABRT didn't catch it :-p
17:03:04 <jlaska> okay, let's get movin'
17:03:06 * tswsl1989 isn't a bugzapper, just interested
17:03:08 * brunowolff will be here for a bit less than an hour.
17:03:20 <jlaska> welcome tswsl1989 jsmith brunowolff :)
17:03:22 <jsmith> tswsl1989: No worries -- welcome!
17:03:34 <jlaska> #topic Intro
17:03:43 <jlaska> Just a reminder on why we are here ...
17:04:22 <jlaska> #info review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs
17:04:30 <jlaska> Some helpful links ...
17:04:32 <jlaska> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:04:46 <jlaska> #link https://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria
17:05:04 <jlaska> and the blocker bug links we'll use today ...
17:05:08 <jlaska> #link http://bit.ly/f15-beta-blocker-proposed
17:05:15 <jlaska> #link http://bit.ly/f15-beta-blocker-accepted
17:05:20 <jlaska> #link http://bit.ly/f15-beta-nth-proposed
17:05:26 <jlaska> #link http://bit.ly/f15-beta-nth-accepted
17:05:38 <jlaska> Any preference where to start?
17:05:49 <jlaska> beta-blocker-proposed ?
17:05:54 <adamw> +
17:05:54 <adamw> 1
17:05:58 <jlaska> #chair rbergeron adamw
17:05:58 <zodbot> Current chairs: adamw jlaska rbergeron
17:06:12 <rbergeron> *whew*
17:06:13 * rbergeron sits down
17:06:22 <rbergeron> yes. +1
17:06:24 <jlaska> okay, I'll start with f15-beta-blocker-proposed and go through the list sorted by component
17:06:27 * adamw continues on his chaise longue
17:06:43 <jlaska> :)
17:06:57 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683956
17:06:58 <buggbot> Bug 683956: unspecified, unspecified, ---, anaconda-maint-list, MODIFIED, raid creation doesn't do the right thing with --spares during kickstart
17:07:06 <jlaska> #info raid creation doesn't do the right thing with --spares during kickstart
17:07:45 <jlaska> Looks like this is in MODIFIED and pending the build of anaconda-15.23-1
17:07:45 <adamw> looks like "# The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot "
17:07:55 <adamw> and fix coming, so we don't need to worry much
17:07:57 <jlaska> +1
17:08:05 <adamw> +1 blocker, +1 move on :P
17:08:28 <jlaska> #agreed 683956 accepted as Final release blocker, will be fixed in anaconda-15.23-1
17:08:46 <jlaska> anyone want to give adamw a break from the role of bug updater?
17:09:11 <rbergeron> I can, though I'm far slower :)
17:09:21 <jlaska> #undo
17:09:21 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x28a7fdd0>
17:09:29 <jlaska> #agreed 683956 accepted as Beta release blocker, will be fixed in anaconda-15.23-1
17:09:35 * rbergeron goes to sit in her chaise lounge too
17:09:48 <jlaska> we can certainly tagteam the bz updates
17:10:06 <adamw> i don't mind doing it either
17:10:10 <adamw> it allows me to claim i actually did some work today
17:10:12 <adamw> :P
17:10:18 <tflink> if my bz-fu wasn't so weak, I would offer to help
17:10:25 * rbergeron hugs adamw for being freaking awesome
17:10:30 <jlaska> group hug!
17:10:46 <jlaska> adamw: mind grabbing that one then please?
17:11:06 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684283
17:11:07 <buggbot> Bug 684283: medium, medium, ---, akozumpl, NEW, TypeError: value is of the wrong type for this column
17:11:10 <jlaska> #info TypeError: value is of the wrong type for this column
17:11:15 <adamw> jlaska: done
17:11:45 <jlaska> adamw: thank you :)
17:11:54 <jlaska> this one I'm certain falls into the Final release criteria
17:12:11 <jlaska> but I added this for review as a Beta blocker for some input from the team
17:12:27 <jlaska> The final criteria is "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above "
17:12:39 <adamw> well for me this kinda hits beta
17:12:44 <jlaska> I'm trying to figure out if the problem is more wide spread though
17:12:46 <jlaska> adamw: agreed
17:12:46 <adamw> because the beta criteria imply being able to get to custom partitioning
17:12:50 <jlaska> yeah
17:13:01 <adamw> but it's a breadth-of-impact thing; what exactly do you need to hit this
17:13:16 <adamw> do we have an anacondian?
17:13:26 <jlaska> it could very well be related to previous disk partition layout
17:13:38 <jlaska> clumens: bcl?
17:14:20 <adamw> i'm guessing it depends on the content of the fields in the column to be displayed or something
17:14:23 <adamw> or the number of fields...
17:14:26 <jlaska> my worry is that it's not so much an installer bug than an interaction wijth some gtk changes
17:14:36 <jlaska> adamw: yeah, probably that too
17:14:46 <jsmith> It certainly looks to me like we need more information
17:14:51 <tflink> .682543 is listed as related
17:14:57 <adamw> yeah, i'd like to have this on the list and ask for more info
17:15:00 <tflink> .bug 682543 is listed as related
17:15:00 <zodbot> tflink: Error: '682543 is listed as related' is not a valid integer.
17:15:01 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=682543 medium, unspecified, ---, mclasen, ASSIGNED, [anaconda] pygobject2 ABI change breaks LVM editing in ananconda
17:15:11 <jlaska> adamw: jsmith okay
17:15:36 <jlaska> the question we need answered is if this happens for everyone, or just the reporters disk layout?
17:15:54 <adamw> well, exactly what is it you need to have to trigger this
17:16:09 <jsmith> jlaska: From that related bug (assuming it's the same bug), it's due to an API change in pygobject
17:16:15 <adamw> yeah
17:16:17 <jlaska> I thought that too
17:16:20 <jsmith> jlaska: And not a problem with the disk layout
17:16:23 <jlaska> but ales asked to keep it seperate until we figure that out
17:16:30 <adamw> but it's not really our problem exactly what the underlying _cause_ is
17:16:33 <adamw> at least at this point
17:16:37 * jlaska nods
17:17:19 <adamw> i'll also mail mclasen to explain this is a high-priority issue, since the bug assigned to him isn't marked as a blocker
17:17:26 <jlaska> proposed #agreed 684283 - not enough information to accept.  Request more information from anaconda on the conditions that lead to this failure
17:17:32 <adamw> maybe we should mark that one as blocker too
17:17:42 <jlaska> it's on the list for later discussion
17:17:42 <rbergeron> +1 to that.
17:17:45 <rbergeron> oh.
17:17:47 <adamw> ok
17:18:03 <tflink> +1
17:18:32 <brunowolff> +1
17:18:45 <rbergeron> +1 to proposal, then.
17:18:51 <jlaska> #agreed 684283 - not enough information to accept.  Request more information from anaconda on the conditions that lead to this failure
17:19:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=688306
17:19:15 <buggbot> Bug 688306: medium, unspecified, ---, rhughes, NEW, Update notification broken in current F15
17:19:22 <jlaska> #info Update notification broken in current F15
17:19:54 <adamw> "# The desktop default update manager must not periodically check for updates when the system is booted live, but must periodically check for updates when running on an installed system "
17:20:14 <jlaska> yup, I think this is fairly cut'n'dry
17:20:29 <adamw> yeah, not much to say. i know richard and matthias are aware and working on it.
17:21:11 <jlaska> proposed #agreed 688306 - AcceptedBlocker for Beta, rhughes + mclasen working to resolve issue
17:21:15 <adamw> ack
17:21:20 <brunowolff> +1
17:21:27 <rbergeron> +1
17:21:32 <tflink> ack
17:21:39 <jlaska> #agreed 688306 - AcceptedBlocker for Beta, rhughes + mclasen working to resolve issue
17:21:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=688305
17:21:49 <buggbot> Bug 688305: medium, unspecified, ---, bnocera, NEW, Update notification period should be shorter for pre-releases
17:21:58 <jlaska> #info Update notification period should be shorter for pre-releases
17:22:21 <jlaska> I don't think this qualifies for any beta criteria, but I added this for discussion/review
17:22:21 <adamw> i didn't really think this should be a blocker, but jlaska wanted to discuss it
17:22:26 <jlaska> heh
17:22:36 <rbergeron> lol
17:22:38 <adamw> it's not really that serious, it's just a notification thing.
17:22:49 <jsmith> I agree that this is more of a distro policy decision than a desktop environment decision
17:22:52 <jlaska> yeah, and now that I think of it ... here probably isn't hte place to have the discussion
17:23:02 <adamw> it could qualify as an nth issue, i guess.
17:23:09 <jsmith> Let's kick it to the desktop list, and mark it as NTH
17:23:14 <adamw> but really i think it's just something for fesco or devel list or something to kick around
17:23:25 <jlaska> yeah
17:23:29 <jsmith> (do we really want Gnome users to have different notification intervals than other desktops?)
17:23:41 <brunowolff> Wouldn't it make more sense to have things working like they are supposed to be at release?
17:23:51 <brunowolff> People can manually pull updates if they want.
17:24:19 <adamw> see above, not a discussion for this meeting i think :)
17:24:22 <jlaska> brunowolff: yeah, I see truth in that stmt too.  We have precedent for changing things just prior to release (fedora-release)
17:24:26 <jlaska> yes yes
17:24:31 <jlaska> okay, so ...
17:25:11 <jlaska> proposed #agreed 688305 AcceptedNTH for Beta.  However, discussion needs to happen on desktop@
17:25:28 <jlaska> ack/nak/patch?
17:25:32 <adamw> sure, ack.
17:25:38 <jsmith> ACK
17:25:46 <adamw> jsmith: do you want to kick off a desktop thread or should i?
17:25:53 <jsmith> adamw: Go for it!
17:25:56 <adamw> ok
17:26:10 * jlaska was expecting to initiate that ... so thanks :)
17:26:55 <tflink> ack
17:26:56 <jlaska> #action adamw volunteered to start discussion on 688305 at desktop@
17:27:03 <jlaska> #agreed 688305 AcceptedNTH for Beta.  However, discussion needs to happen on desktop@
17:27:10 <brunowolff> 0 Not keen on the idea, but seems low risk
17:27:40 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682543
17:27:42 <buggbot> Bug 682543: medium, unspecified, ---, mclasen, ASSIGNED, [anaconda] pygobject2 ABI change breaks LVM editing in ananconda
17:27:49 <jlaska> #info [anaconda] pygobject2 ABI change breaks LVM editing in ananconda
17:28:14 <jlaska> I believe this is that other gtk bug we referenced earlier
17:28:24 <tflink> yep, it is
17:28:30 <jsmith> That's correct
17:28:44 <jlaska> "Issue is caused by the ABI change from pygobject2-2.27.91-1.fc15 to
17:28:44 <jlaska> pygobject2-2.28.0-1.fc15. Updating this and only this package in a live session
17:28:47 <jlaska> launched from desktop-i386-20110308.00.iso causes anaconda to throw the
17:28:50 <jlaska> exception reported above."
17:29:01 <jlaska> so what is the presence of this bug blocking ...
17:29:02 * jlaska reading
17:29:37 <adamw> seems like it caused another anaconda bug
17:29:37 <clumens> editing certain partition setups
17:29:41 <jlaska> is this more involved than just doing a live install?
17:30:00 <jlaska> clumens: oh ... do we have enough info on the types of setups?
17:30:07 <adamw> this is basically the same bug, but in a different bit of the UI, afaict
17:30:33 <adamw> so if for whatever reason it didn't get fixed on pygobject side, this would be a different bit of code to fix in anaconda from the other bug, which is why anaconda team wants to keep them separate for nwo
17:30:35 <clumens> i think it is just a matter of trying to edit LVs
17:31:33 <jlaska> adamw: yeah, I was just trying to understand what steps lead to the failure
17:31:36 <adamw> right
17:31:49 <adamw> would any content in that column trigger this bug, clumens? or does it depend on some specific content?
17:32:01 <adamw> if this triggers any time you try to edit a setup with LVs in it, i'd certainly consider that a blocker
17:32:03 <clumens> any
17:32:19 * jsmith is inclined to make it a blocker then
17:32:31 <adamw> +1
17:32:45 <jlaska> agreed, but I don't see beta criteria that would fit this ... am I missing?
17:32:49 <jlaska> definitely final criterla
17:32:54 <jlaska> eck ... criteria
17:33:23 <adamw> jlaska: i'd count it as an implicit breach of "# The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot "
17:33:29 <adamw> you need to be able to access custom partitioning screen for that
17:33:48 <tflink> another one could be this alpha release requirement: "The installer must be able to complete an installation using IDE, SATA and SCSI storage devices, with the default file system and LVM"
17:34:14 <clumens> editing things makes it non-default
17:34:16 <adamw> tflink: that one doesn't require you to hit the custom partitioning screen, it's actually kinda meant to cover the 'just click through' case with common hardware
17:34:17 <jlaska> I don't think this falls under those Alpha criteria ... since it involves manual partition edits
17:34:41 <jlaska> adamw: I see ... if it was *implied* by that criteria ... I certainly missed it :(
17:34:53 <adamw> jlaska: my nickname is 'barracks room lawyer' :P
17:34:59 <jlaska> haha
17:35:16 <adamw> i accept that it's a bit of a stretch.
17:35:23 <jlaska> I'm going to be bold/stupid and suggest F15Blocker for - "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above "
17:35:28 <brunowolff> If it is supposed to be implied by that criteria, I suggest adding some explicit about custom partitioning.
17:35:38 <adamw> jlaska: that's clear, yeah.
17:36:00 <tflink> jlaska: yeah, I'm not convinced this falls into any beta requirements
17:36:07 <adamw> i guess if we're not inclined to accept my stretch, the question becomes 'do we actually want to require the custom partitioning step to work at beta stage'
17:36:08 <tflink> final sounds good
17:36:12 <adamw> and if the answer's yes, we add a criterion for that
17:36:19 <jlaska> adamw: right
17:36:20 <adamw> otherwise, it's a final blocker
17:36:37 <jlaska> I'm +1 Beta AcceptedNTH and Final AcceptedBlocker
17:36:48 <adamw> still, i am worried about that RAID criterion
17:37:03 <adamw> can you actually get into the custom partitioning screen to set up a RAID array, with this bug?
17:37:07 <jlaska> adamw: as for criteria, perhaps we add beta criteria that the installer must be able to recognize and re-use existing partition data?
17:37:16 <jlaska> adamw: good question!
17:37:25 <tflink> adamw: good point
17:37:32 <adamw> i'm trying to think through the workflow
17:37:33 <jlaska> adamw: now I see your "implied"
17:37:42 <jlaska> so actions ...
17:37:53 <jlaska> we need some RAID testing to determine if that case is impacted
17:37:55 <jlaska> if so ... Beta
17:37:56 <adamw> how do you get the installer to trigger the custom partition layout screen *without* a layout that has LVMs in it?
17:37:57 <jlaska> if not ... Final
17:38:09 <adamw> since the default layout involves LVMs...
17:38:34 <jlaska> adamw: choose custom on a setup that didn't have LVM previously
17:38:37 <adamw> i'm trying to think if any of the options you can select before you trigger the custom partitioning screen has an effect.
17:39:02 <adamw> anyway, +1 jlaska's last action proposal
17:39:47 <jlaska> proposed #agreed 682543 - tentatively AcceptedBlocker for Final, AcceptedNTH for Beta.  Need additional testing to determine if software RAID installs are impacted by this same issue.  If so ... Beta blocker
17:39:54 <jlaska> ack/nak/patch
17:39:56 <brunowolff> +1
17:39:57 <tflink> ack
17:40:24 <jlaska> #action jlaska once installer is working again, test 682543 by doing software RAID installs
17:40:38 <brunowolff> Can we do the encryption ones next?
17:40:42 <adamw> ack
17:40:52 <brunowolff> I have about 10 minutes before I have to leave.
17:40:54 <jlaska> #agreed 682543 - tentatively AcceptedBlocker for Final, AcceptedNTH for Beta.  Need additional testing to determine if software RAID installs are impacted by this same issue.  If so ... Beta blocker
17:41:13 <jlaska> brunowolff: what are the encrypted bugs?
17:41:28 <brunowolff> 678927
17:41:38 <jlaska> ah okay, I'll skip t othat
17:41:50 <brunowolff> And I might add 683835 before the next blocker meeting.
17:41:55 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678927
17:41:57 <buggbot> Bug 678927: unspecified, unspecified, ---, mgrepl, ASSIGNED, SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
17:42:03 <jlaska> #info SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition
17:42:22 <jlaska> mcepl: you still seeing this bug?
17:42:43 <brunowolff> I don't believe selinux is blocking boots any more (at least not that rule), but that there is still a
17:42:50 <brunowolff> race condition.
17:42:51 <adamw> so, dwalsh claims this is not an selinux issue, yes?
17:43:04 * jlaska hasn't seen this umounted /home issue in a few days
17:43:09 <brunowolff> I have about a 50% boot success rate.
17:43:09 <adamw> if so, we should re-assign this to an appropriate component
17:43:27 <jlaska> adamw: yeah, it seems dwalsh has done what was needed for this issue
17:43:42 <adamw> well, he claims selinux would never actually have blocked the operation anyway
17:43:42 <jlaska> brunowolff: and that's with the updated selinux-policy + relabel?
17:43:52 <jlaska> adamw: oh right, just alerted
17:43:55 <brunowolff> He fixed a couple of other denials that wren't actually blocking things.
17:44:19 <jlaska> to mcepl uploaded his log files ... I guess we need lennart's feedback on those?
17:44:28 <brunowolff> I haven't done a full relabel recently. But certainly could do that tonight.
17:44:51 <adamw> should we assign this to systemd as a next guess?
17:44:58 <jlaska> yeah, let's do that
17:45:05 <jlaska> with a needinfo? lennart
17:45:35 <jlaska> do we know enough to make a decision on blocker status?
17:45:41 <brunowolff> Next Friday I have a furlough day, so I'll be able to hang around the whole time.
17:45:56 <jlaska> brunowolff: thanks for taking the time to join today
17:46:12 <adamw> i think we're still kinda unclear on the status of this bug
17:46:26 <adamw> who else is running f15 with encrypted partitions?
17:46:28 <brunowolff> If you are here for long enough I might be back.
17:46:29 <adamw> i'm not. since i'm a bad, bad person.
17:46:32 * jlaska raises hands
17:46:38 <adamw> and seeing any issues?
17:46:49 <jlaska> I haven't seen them in a few days (with cold and warm boots)
17:47:02 <jlaska> But I can experiment and post feedback after meeting
17:47:12 <jlaska> mcepl really has some well organized logs now in the bz
17:47:21 * willy_1977 has to go too just wanted to show face this time try and get handle on the flow of things in bugzappers; see you around.
17:47:22 <brunowolff> I started the restorecon now, and will try a reboot tonight.
17:47:24 <jlaska> so I thnk that should be enough to get lennart started
17:47:28 <jlaska> brunowolff: thanks!
17:47:38 <adamw> willy_1977: this isn't really a bugzappers process to be honest :) but thanks for popping bty
17:48:09 <adamw> proposed action: re-assign this bug to systemd and ask lennart to look at it
17:48:11 <willy_1977> tbh just getting involved where I can... bit like a bad smell in that respect ;)
17:48:18 <jlaska> adamw: ack
17:48:29 <adamw> proposed ack: still not enough info on the circumstances of this bug to make a clear call on its blocker status, wait for feedback from lennart
17:48:41 <jlaska> ack
17:48:46 <brunowolff> +1
17:48:48 <adamw> er, proposed agreed :)
17:48:59 <jlaska> :)
17:49:04 <tflink> ack
17:49:06 <adamw> #action 678927 re-assign to systemd and ask lennart to look into this based on logs provided
17:49:17 <brunowolff> I'm leaving my chat window open, but it will be over an hour before I get back.
17:49:22 <adamw> #agreed 678927 still not enough info to clearly determine blocker status, waiting on feedback from lennart
17:49:25 <jlaska> thanks bruno
17:49:34 <jlaska> ready for next?
17:49:50 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679179
17:49:52 <buggbot> Bug 679179: urgent, unspecified, ---, jforbes, ASSIGNED, openbios-ppc subpackage, which qemu depends on, disappeared
17:49:58 <jlaska> #info openbios-ppc subpackage, which qemu depends on, disappeared
17:50:03 <jlaska> This has come up on several lists already
17:50:42 <jlaska> if the updated qemu is included on the DVD, which I think it is, this would impact Alpha criteria
17:50:48 <jlaska> Alpha - "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (CD/DVD) install "
17:51:29 <adamw> yeah. it also hits the beta virt criteria, obviously
17:51:39 <adamw> you can't run f15-on-f15 if you can't install a working virt setup in the host...
17:51:54 <jlaska> true true
17:51:57 <jlaska> okay ...
17:52:32 <adamw> so, what i heard on this is that the openbios sub-packages need 'special handling' to build
17:52:38 <adamw> and there's some kind of issue with that
17:52:49 <jlaska> hopefully this does *not* intersect with secondary arch stuff
17:52:51 <adamw> but still...we really need releng to take care of this.
17:53:02 <jlaska> so who owns this?
17:53:07 <jlaska> jforbes or rel-eng/dgilmore?
17:53:08 <adamw> i think it kinda does, i think the issue is you need to build the package on a ppc host. but imbw there.
17:53:27 <jlaska> ugh, that stinks
17:53:28 <adamw> i'm not 100% sure, but i think it's build process stuff. dgilmore, around?
17:53:39 <jlaska> adamw: hopefully he's not around ... and he's sleeping soundly
17:53:40 <jlaska> :)
17:53:42 <adamw> heh
17:53:43 <adamw> oh yeah
17:53:52 <adamw> damn spheres!
17:53:58 <adamw> #action make earth flat
17:54:09 <jlaska> proposed #agred 679179 - AcceptedBlocker for Beta.  Need input from dgilmore (rel-eng) on how to proceed
17:54:12 <jlaska> adamw:  nice :)
17:54:26 <jlaska> proposed #agreed 679179 - AcceptedBlocker for Beta.  Need input from dgilmore (rel-eng) on how to proceed
17:54:29 <jlaska> ack/nak/patch?
17:54:33 <tflink> adame: as long as there is a fence around the edge - I don't want to worry about falling off
17:54:38 <jlaska> heh
17:54:44 <adamw> ack, we should also probably find someone from ppc group to help
17:54:46 <tflink> ack
17:54:50 <adamw> per justin's comment #1
17:55:15 <jlaska> adamw: can you cc karsten hopp from ppc arch team?
17:55:22 <adamw> roger
17:55:45 <jlaska> karsten at dahat
17:55:51 <jlaska> ty!
17:56:20 <jlaska> #agreed 679179 - AcceptedBlocker for Beta.  Need input from dgilmore (rel-eng) on how to proceed
17:56:26 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679503
17:56:27 <buggbot> Bug 679503: unspecified, unspecified, ---, rstrode, NEW, plymouth doesn't always transition to gdm
17:56:33 <jlaska> #info plymouth doesn't always transition to gdm
17:56:52 <jlaska> I'm no longer seeing the issue I reported here
17:57:07 <jlaska> I'm fine with marking this CLOSED CURRENTRELEASE
17:57:25 <adamw> well, i'd like to see how nightlies are behaving
17:57:27 <adamw> has anyone run one lately?
17:57:47 <tflink> nope, but then again I don't think that I ever hit this personally
17:57:50 <adamw> there hasn't been a gdm build since i was hitting big issues building live images for the test days
17:57:59 <jlaska> ooh, that one
17:58:09 <adamw> can we leave this on for now with a #action for me to test latest nightly on my affected system?
17:58:18 <jlaska> no objections
17:58:50 <tflink> adamw: I thought that you were hitting more of a different bug with the test day image
17:59:15 <adamw> tflink: i was hitting multiple bugs, but iirc, one of them was considered to be this
17:59:21 <tflink> .bug https://bugzilla.redhat.com/show_bug.cgi?id=684053
17:59:21 <zodbot> tflink: Error: 'https://bugzilla.redhat.com/show_bug.cgi?id=684053' is not a valid integer.
17:59:22 <buggbot> Bug 684053: high, unspecified, ---, jmccann, NEW, GDM startup does not complete : gdm-simple-greeter: GLib-GObject-CRITICAL: g_object_ref: assertion `G_IS_OBJECT (object)' failed
17:59:23 <buggbot> Bug 684053: high, unspecified, ---, jmccann, NEW, GDM startup does not complete : gdm-simple-greeter: GLib-GObject-CRITICAL: g_object_ref: assertion `G_IS_OBJECT (object)' failed
17:59:42 * tflink fails at the buggbot usage
17:59:52 <adamw> well
18:00:04 <adamw> the bug i hit using newest gdm with no other changes was not that
18:00:13 <tflink> ok
18:00:15 <adamw> the image would boot to a console, gdm never managed to start at all
18:00:19 <adamw> the fix for that was to disable plymouth
18:00:36 <adamw> i then used an older gdm to try and avoid *another* bug, which was that gdm didn't manage to start gnome properly
18:00:42 <adamw> so yeah, it got messy.
18:00:50 <adamw> new proposal
18:00:55 <adamw> let's close this bug (679503)
18:01:07 <adamw> i'll check latest nightly on my test system, and if it still has problems, file them separately, for clarity
18:01:26 <jlaska> proposed #agreed 679503 - No longer seeing reported issue, file new bugs for any remaining plymouth->gdm transition errors
18:01:31 <adamw> ack
18:01:37 <tflink> ack
18:01:59 <jlaska> #agreed 679503 - No longer seeing reported issue (moved to CLOSED), file new bugs for any remaining plymouth->gdm transition errors
18:02:37 <jlaska> #action Testing against latest nightly needed to confirm plymouth->gdm transition works
18:02:41 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=684742
18:02:43 <buggbot> Bug 684742: unspecified, unspecified, ---, kzak, ASSIGNED, ImportError: /lib64/libcryptsetup.so.1: undefined symbol: uuid_generate
18:02:50 <jlaska> last, but not least
18:02:52 <jlaska> #info ImportError: /lib64/libcryptsetup.so.1: undefined symbol: uuid_generate
18:02:55 <clumens> everyone's favorite.
18:03:20 <jlaska> so .. as for blocker status, I *believe* this is preventing all installs
18:03:42 <jlaska> but I know clumens has a better understanding on the cause
18:03:51 <clumens> good news is we have a workaround in anaconda that appears to allow installs continue, bad news is evidence points to it being a glibc problem
18:04:12 <adamw> this looks icky
18:04:23 <clumens> yeah
18:04:28 <adamw> but just assessing the impact, looks like a clear blocker
18:04:30 <jsmith> Eeew...
18:04:36 <adamw> and you guys get to deal with deciding on how to fix it :)
18:06:01 <jlaska> so ... who has the ball on this one given the anaconda workaround is in place?
18:06:23 <adamw> i guess we approve this as a blocker until the anaconda workaround is in
18:06:28 <jlaska> #agreed 684742 - AcceptedBlocker for Beta.  Root cause points to some problems lurking in glibc
18:06:30 <clumens> i hold out no hope for a real resolution.
18:06:32 <adamw> after that it's not blocker any more, bug gets reassigned to glibc?
18:06:52 <clumens> fix is already in lorax
18:07:07 <jlaska> clumens: do we need mgracik to kick off a new build?
18:07:09 <adamw> which means...
18:07:34 <clumens> http://git.fedorahosted.org/git/?p=lorax.git;a=commit;h=eefd77e1b116a6821b402013983f64a1ae86d23b
18:07:37 <clumens> jlaska: we do
18:07:54 <jlaska> clumens: I pinged him this morning, but I may have just missed beer:30
18:08:24 <adamw> so basically with the next anaconda build, this will be 'fixed' from anaconda side
18:08:25 <jlaska> any provenpackager that could help fire off a build of this?
18:08:32 <jlaska> adamw: yeah, the next lorax build
18:08:33 <adamw> then change the summary, kick to glibc, and downgrade from blocker status
18:08:40 * adamw still doesn't know what the hell lorax is.
18:08:41 <clumens> in fact, first that commit neeeds to be pulled to f15-branch
18:08:55 <clumens> adamw: it's the thing that takes the place of all the tree-building crap in anaconda's scripts/ directory.
18:09:14 <adamw> oh, right.
18:09:15 <jlaska> adamw: it's used by pungi to create tehe install ISO's and pxeboot images
18:09:48 <jlaska> Howabout we clone this bug off to glibc, and accept the current lorax bug as a blocker?
18:10:06 <tflink> that sounds cleaner to me
18:10:08 <adamw> sounds good
18:10:16 <jlaska> #undo
18:10:16 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x2a50b510>
18:10:36 <jlaska> proposed #agreed 684742 - AcceptedBlocker for Beta.  Root cause points to some problems lurking in glibc, clone bug against glibc and await feedback
18:10:51 <clumens> bug is currently assigned to util-linux, hilariously.
18:11:20 <adamw> i'll clean it up
18:11:20 <jlaska> is there anyone who accepts electronic greetings who can kick off a lorax build with this fix?
18:11:23 <adamw> may take me a couple of minutes though
18:11:40 <clumens> jlaska: anyone in anaconda can, as you may remember from last time something like this came up.
18:11:45 <jlaska> yeah :(
18:12:04 <jlaska> I'm just anxious to get this out of the way so we can get some testing in prior to the test compose next week
18:12:10 <jlaska> (Tuesday iirc)
18:12:44 <clumens> understood.
18:12:47 <jlaska> I heard no nak's ... so going to #agreed
18:12:57 <jlaska> #agreed 684742 - AcceptedBlocker for Beta.  Root cause points to some problems lurking in glibc, clone bug against glibc and await feedback
18:13:15 <clumens> i was going to suggest we wait until monday and bug mgracik about it, but whatever.
18:13:29 <jlaska> clumens: instead of cloning?
18:13:35 <jlaska> or to do the build etc...
18:13:48 * adamw never understands why cloning a bug causes the clone to depend on the original
18:13:57 <clumens> jlaska: to do a build, etc.
18:14:01 <jlaska> me neither
18:14:05 <jlaska> clumens: that'll do
18:14:17 <jlaska> the people we need are all in sleepy TZ's at the moment
18:14:35 <jlaska> #action jlaska - update Beta TC1 rel-eng ticket to note new lorax build will be needed (and fast tracked)
18:14:45 <jlaska> okay, we are done with Blockers
18:14:48 <jlaska> yay!
18:14:51 <jlaska> </dance>
18:15:02 <jlaska> I have a list of 19 accepted blockers
18:15:05 <rbergeron> lol
18:15:14 <jlaska> many of them are in MODIFIED
18:15:22 <jlaska> and I'd like to skip them
18:15:27 <jlaska> any thoughts/comments/concerns
18:15:53 <jlaska> they are mostly queued up pending anaconda-15.23-1 I believe
18:16:02 <jlaska> clumens: what caused that build failure again?
18:16:08 <jlaska> clumens: is that something we need to get on the radar
18:16:20 <adamw> skip the anaconda modifieds
18:16:21 <clumens> jlaska: NM
18:16:31 <jlaska> ah, right!
18:16:37 <jlaska> before we dive into proposed ...
18:16:41 <jlaska> is that being tracked anywhere?
18:16:53 <clumens> just in the trac ticket, yeah?
18:16:53 <jlaska> anyone know what's the status of the NM rebase?
18:17:08 <adamw> god, no.
18:17:22 <jlaska> #link https://fedorahosted.org/fesco/ticket/572
18:17:23 <adamw> (except that somehow, SUSE seem to have it working.)
18:17:47 <jlaska> this is slippy all over it
18:17:49 * adamw doesn't see dcbw online.
18:17:51 <jlaska> s/is/has/
18:17:54 <adamw> yeah it's icky.
18:18:11 <adamw> i like how fesco decided to punt it for a week. that was great.
18:18:20 <clumens> you'd hate to have easy problems to solve.
18:18:24 <adamw> nothing better than last-minute discussions!
18:18:25 <clumens> that's just boring.
18:18:26 <adamw> decisions*
18:18:40 <jlaska> yes, that is unfortunate
18:19:02 <jlaska> okay, so we are in need of miracles for the Beta already :)
18:19:20 <jlaska> anything that needs to happen here to move this along ... or are we waiting on feedback from jirka
18:19:25 <adamw> so, what's the anaconda issue here? until networkmanager is either properly built as 0.9 or reverted to something older, we can't build anaconda?
18:19:37 * jlaska defers to clumens
18:19:56 <clumens> we can revert the patch in anaconda and rebuild.
18:20:17 <adamw> clumens: and has there been any testing at all of how the new NM actually works in anaconda?
18:20:22 <clumens> which we'd already decided to do.  i just need to stop being lazy.
18:20:24 <adamw> because if not, then...yeah. that does not inspire confidence.
18:20:39 <clumens> adamw: i don't know whether rvykydal did or not.
18:20:43 <adamw> whee.
18:20:55 <adamw> so i guess we have two issues here: we need to solve things in the short term to get an anaconda build out.
18:21:04 <jlaska> agreed
18:21:04 <adamw> and second, do we want to jump into the whole NM 0.9 ticket with a big bucket of NO.
18:21:09 <jlaska> #topic https://fedorahosted.org/fesco/ticket/572
18:21:26 <adamw> clumens: cool, so...do it :P
18:21:45 <jlaska> adamw: it works better when used with <arnold> tags
18:21:52 <adamw> sudo do it
18:22:12 * adamw in favour of jumping into the nm 0.9 ticket with a big bucket of NO. but not sure if it's a topic for this meeting, or test list.
18:22:14 <jlaska> #info NM-0.9 is causing a *lot* of pain and has potential to introduce a beta slip
18:22:29 <adamw> maybe we should document the ways it can cause a beta slip and add them to the ticket.
18:22:31 <clumens> yeah i can do that.
18:22:38 <clumens> er - the reverting.  not this other stuff.
18:22:42 <adamw> clumens: :)
18:22:59 <jlaska> #action clumens will revert NM-0.9 anaconda patches and submit build for testing
18:23:41 <adamw> should we discuss the other thing here, or on-list?
18:23:42 <jlaska> adamw: If we have no end in sight on Monday ... yes, it's rollback time imo
18:24:02 <jlaska> adamw: I'm fine here, but it's probably more appropriate outside this meeting
18:24:10 <jlaska> for the sake of our fingers and meeting fortitude :)
18:24:28 <adamw> also for the sake of me getting the hell up a mountain, so agreed!
18:24:35 <adamw> (before the clouds roll back in)
18:24:38 <jlaska> btw ... I like your ideas on listing why this change is a potential slipper
18:24:50 <jlaska> "Operation slopes"
18:25:08 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=678414
18:25:09 <buggbot> Bug 678414: high, high, ---, anaconda-maint-list, NEW, NFS ISO install fails during repo setup - umount.nfs4: /mnt/source: device is busy
18:25:14 <jlaska> #info NFS ISO install fails during repo setup - umount.nfs4: /mnt/source: device is busy
18:25:38 <jlaska> nothing shocking here ... just waiting on me or rhe to retest once we have a build
18:25:47 <jlaska> testing is blocked for the other issues already discussed
18:25:54 <clumens> cranes?  is that you?
18:26:06 <jlaska> #info Pending updated test results when new build available
18:26:09 <jlaska> clumens: the one and only
18:26:12 <jlaska> that bastard!
18:26:15 <adamw> ok, next bug!
18:26:36 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=677080
18:26:38 <buggbot> Bug 677080: unspecified, unspecified, ---, tcallawa, NEW, 'F14' artwork is shown during F-15 installation
18:26:49 <jlaska> I saw some movement on this with the design team, but haven't checked in recently
18:26:57 <jlaska> #info 'F14' artwork is shown during F-15 installation
18:27:33 <jlaska> #link https://fedoraproject.org/wiki/F15_Artwork
18:27:47 <jlaska> Work looks to have been started
18:28:35 <adamw> maybe we should contact design team and make sure they're aware of the deadlines
18:28:36 <jlaska> on the design-team schedule, this isn't due until next Friday
18:28:43 <jlaska> couldn't hurt
18:28:51 <adamw> we don't need the final artwork for beta, only generic
18:28:55 <jlaska> I'd love to see this *in* TC1, and not landing in RC1 for the first time
18:29:02 <adamw> yeah
18:29:05 <jlaska> point
18:29:17 <jlaska> I can ping design folks post-meeting
18:29:30 <adamw> okay, cool
18:29:39 <jlaska> #action jlaska - check-in with design team on status of 677080
18:29:55 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=682141
18:29:57 <buggbot> Bug 682141: unspecified, unspecified, ---, otaylor, NEW, gnome-shell failed to start when changing user language to Chinese(China)
18:30:04 <jlaska> #info gnome-shell failed to start when changing user language to Chinese(China)
18:30:32 <jlaska> This bug appears to be fixed upstream, and we are waiting on that fix to be included in Fedora
18:30:44 <adamw> so this is one we were unsure of last week, but based on the feedback it became a clear blocker and we marked it as such
18:30:52 <adamw> and yeah, seems like there's a fix to pull in
18:31:12 <adamw> so, action is on owen i guess
18:31:30 <jlaska> owen or mclasen ... I never know who does the builds?
18:31:53 <adamw> can be either, i think.
18:32:04 <jlaska> #info Bug appears to be resolved upstream, awaiting new build from owen of mclasen
18:32:17 <tflink> koji lists mclasen, otaylor and salimma as recent builders of gnome-shell
18:32:27 <jlaska> not to sound extremely lazy ... but do we need to ping on this too?
18:32:36 * adamw just did, in the bug.
18:32:43 <jlaska> adamw: danke :)
18:32:49 <jlaska> adam-bot
18:33:10 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683179
18:33:11 <buggbot> Bug 683179: medium, unspecified, ---, davidz, NEW, desktop- backgrounds package no longer sets the default Fedora background, due to changes in Gnome
18:33:23 <jlaska> #info desktop- backgrounds package no longer sets the default Fedora background, due to changes in Gnome
18:33:42 <jlaska> no updates since our check-in last week
18:33:44 <adamw> so this hasn't moved
18:33:56 <adamw> looks like Martin's waiting on a tip from mclasen
18:34:16 <jlaska> Martin?
18:34:45 <adamw> sourada
18:34:49 <jlaska> ah, thx
18:35:01 <adamw> who seems to be looking at this
18:35:06 <adamw> i can post a poke on the bug
18:35:15 <jlaska> can you adjust needinfo? also?
18:35:19 <adamw> ok
18:35:26 <jlaska> once again, ty
18:35:39 <jlaska> #info msourada looking for tips/guidance from mclasen on how to proceed
18:35:59 <jlaska> last one of the AcceptedBlockers ...
18:36:01 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486
18:36:03 <buggbot> Bug 679486: medium, low, ---, ajax, ASSIGNED, Unable to start graphical installer on RC1 KDE live image
18:36:10 <jlaska> #info Unable to start graphical installer on RC1 KDE live image
18:36:39 <clumens> ugh, that one's still around?
18:36:42 <adamw> still no movement
18:36:46 <jlaska> yes, and it must go away
18:36:58 <jlaska> same issue ... in need of a sharp stick?
18:37:15 <adamw> looks like it
18:37:47 <adamw> looks like ajax is point on this
18:38:10 <adamw> poke posted
18:38:44 <jlaska> #info Adamw updated the bz asking for status and reminding about upcoming Beta
18:38:52 <jlaska> #topic Open Discussion
18:39:07 <jlaska> We have two remaining links with potential bugs for review ...
18:39:13 <jlaska> NTH proposed and NTH accepted
18:39:22 <adamw> there's no real need to go over the accepted
18:39:25 <jlaska> I don't think we need to go through each list one-by-one
18:39:31 <jlaska> adamw: agreed ++
18:39:34 <adamw> well, proposed we need to evaluate. how long is it?
18:39:43 * jlaska looking over http://bit.ly/f15-beta-nth-proposed
18:39:57 <clumens> 128 bugs
18:39:59 <jlaska> ouch this will be a while ...
18:40:00 <jlaska> 2 bugs
18:40:29 <tflink> I was going to say, I'm only seeing 2
18:40:31 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=683548
18:40:32 <adamw> damnit, clumens. :)
18:40:33 <buggbot> Bug 683548: unspecified, unspecified, ---, akozumpl, POST, has two active workspaces
18:41:06 <jlaska> #info patch - https://www.redhat.com/archives/anaconda-devel-list/2011-March/msg00203.html
18:41:10 <adamw> what has two active workspaces? the installer?
18:41:12 <jlaska> Fixed rawhide: f851fc4636269a0f6a18bcd2f876d374c6e675f5.
18:41:19 <jlaska> adamw: metacity in the installer, yeah
18:41:20 <adamw> hey, gets my vote.
18:41:37 <clumens> i told him to go ahead and push to f15-branch, but he hasn't yet.  i can cherry-pick if urgent.
18:42:04 <jlaska> proposed #agreed 683548 AcceptedNTH, patch out on list, likely to be included soon
18:42:05 <adamw> doesn't seem urgent, i think nth is right for this one, which basically gives you folks power to handle as you like
18:42:18 <tflink> jlaska: ack
18:42:25 <adamw> ack
18:42:39 <adamw> we're happy for you to pull or not as you see fit
18:42:43 <jlaska> #agreed 683548 AcceptedNTH, patch out on list, likely to be included soon
18:42:52 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=687866
18:42:54 <buggbot> Bug 687866: unspecified, unspecified, ---, mgracik, ASSIGNED, Add yum-langpacks to anaconda environment
18:42:58 <jlaska> #info Add yum-langpacks to anaconda environment
18:43:23 <jlaska> I was NTH for Beta on this given that yum-langpacks always seems to cause hiccups
18:43:25 <clumens> that's committed to f15-branch, waiting on a build.
18:43:29 <jlaska> cool
18:43:34 <adamw> yup, looking at the description i'm +1 nth on this one for sure.
18:43:35 * jlaska hears base in the background
18:43:53 <tflink> +1 on nth
18:44:05 <jlaska> #agreed 687866 - AcceptedNTH for Beta.  Fix already in and pending build
18:44:14 <jlaska> #topic Open Discussion
18:44:31 <jlaska> Okay, are we ready to commence "project mountaintop"?
18:44:40 <jlaska> any bugs folks would like to nominate
18:44:41 <tflink> I don't know if this is the right place for this, but is anyone working on testing xen?
18:44:49 <tflink> since that is a beta blocker
18:45:00 <tflink> and it sounds like there were big changes in 2.6.38
18:45:02 <adamw> it's mostly there on the basis of 'if anyone complains we'll take it as a blocker'
18:45:09 <adamw> we don't have an explicit test for it though afaik
18:45:13 * jlaska checking ...
18:45:24 <jlaska> infra typically hits issues and files bugs on this one iirc
18:45:26 * adamw waits confidently to be wrong
18:45:40 <jlaska> nope ... we don't have it in the matrix
18:45:42 <jlaska> for 1 reason ...
18:45:47 <adamw> we have a install_to_kvm but nothing for xen.
18:45:56 <jlaska> Fedora doesn't have a xen dom0 solution
18:46:20 <tflink> no? http://fedoraproject.org/wiki/Features/XenPvopsDom0
18:46:27 <tflink> sounds like we do now
18:46:30 <wwoods> Are there tests for running under e.g. KVM, VirtualBox, etc
18:46:31 <jlaska> so we can add it, but it does require CentOS or RHEL (and honestly RHEL since this criteria if focused on covering infrastructure use)
18:46:32 <wwoods> tflink: nope
18:46:38 <adamw> 'percentage of completion: 30%'
18:46:53 <jlaska> tflink: if that feature completes, I will be a monkeys uncle!
18:46:58 <tflink> adamw: last updated 2010-10-29
18:46:59 * jlaska isn't sure what he just signed up for
18:47:27 <adamw> i'm not sure we need to discuss this further here, anyway
18:47:30 <jlaska> wwoods: just KVM, no Vbox (although we get a fair number of Vbox bug reports)
18:47:30 <adamw> it can go async?
18:47:34 <jlaska> sure
18:47:37 <adamw> vbox isn't in the criteria, either/
18:47:43 <jlaska> palabra
18:47:45 <adamw> (explicitly so)
18:47:50 <tflink> if we don't have test cases for it, why is it a release criteria?
18:47:57 <jlaska> tflink: see above ...
18:47:58 <wwoods> oh hm - the pvops feature has been around forever
18:48:00 <adamw> tflink: like jlaska said, because releng complains.
18:48:05 <jlaska> all of our infrastructure requires it
18:48:05 <adamw> er, infra.
18:48:15 <wwoods> I think it might actually have gotten into 2.6.37 though?
18:48:25 <tflink> it sounds like it made it into 38
18:48:27 <jlaska> wwoods: I know it got some recent movement, but I dont' know current status
18:48:32 * adamw is on a tight timeframe for Operation Washroom over here
18:48:34 <wwoods> you'd probably want to make the feature dependent on them writing some test cases
18:48:37 <wwoods> heh
18:48:38 <jlaska> anyway ... shout on test@ if we need to make adjustments
18:48:57 <jlaska> Last call ... 1 minute fuse set ...
18:49:04 <jlaska> #topic Last Call ...
18:49:35 <jlaska> 30 seconds ...
18:49:46 <clumens> yeah i have some critical, lengthy discussions.
18:49:58 * adamw whacks clumens with a two by four
18:50:02 <adamw> eat my dust, suckers
18:50:08 <jlaska> queue the blow gun
18:50:15 <jlaska> thanks everyone!
18:50:18 <jlaska> I'll send minutes to the list
18:50:22 <jlaska> #endmeeting