16:08:44 <jlaska> #startmeeting F13Beta blocker review
16:08:44 <zodbot> Meeting started Fri Mar 12 16:08:44 2010 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:08:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:08:58 <jlaska> #meetingname F13Beta-blocker-review
16:08:59 <zodbot> The meeting name has been set to 'f13beta-blocker-review'
16:09:06 <jlaska> #topic Gathering ...
16:09:38 <jlaska> I saw Oxf13, and I suspect we have a few folks lurking
16:10:22 <jlaska> anyone else here to help review the list of F13Beta bugs?
16:10:39 * mclasen lurks for questions
16:10:40 <adamw> woops
16:10:45 * adamw sortakindaforgotabit
16:10:55 <adamw> here sir!
16:11:01 <Oxf13> adamw: is that a german word?
16:11:08 <jlaska> adamw: not to worry, I have my phazers always set to annoy
16:11:18 <jlaska> mclasen: welcome
16:11:34 <jlaska> I imagine we'll pull in others as needed on a per-bug basis
16:11:37 <jlaska> #chair adamw
16:11:38 <zodbot> Current chairs: adamw jlaska
16:11:54 <jlaska> any objections to walking the list, sorted by component?
16:12:01 <adamw> go for it
16:12:04 * jlaska notes, his head spins jumping back and forth between components
16:12:19 <jlaska> adamw: okay if I drive?
16:12:46 * jlaska puts "How's my driving" sticker on bumper
16:13:02 <adamw> as long as you don't mind me clinging to the dash and squealing like a cheerleader!
16:13:12 <jlaska> please, and I encourage back-seat driving
16:13:13 <jlaska> :)
16:13:23 <jlaska> alright, I'll be working from https://bugzilla.redhat.com/showdependencytree.cgi?id=538274&hide_resolved=1 ... but sorted by component
16:13:48 <jlaska> #link http://tinyurl.com/yzmg5to
16:14:01 <jlaska> first up ... anaconda bugs
16:14:08 <jlaska> let's grab dlehman or clumens
16:14:40 * jlaska inviting
16:15:35 <jlaska> clumens: thanks for joining
16:15:39 <clumens> sure
16:15:45 <jlaska> we've got a few anaconda issues on the list, let's get started ...
16:15:47 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=565848
16:15:48 <buggbot> Bug 565848: medium, medium, ---, dlehman, ASSIGNED, LVMError: lvactivate failed for lv_root: Skipping volume group vg_test1148
16:16:33 <jlaska> this seems like a no brainer to me, it's documented at https://fedoraproject.org/wiki/Common_F13_bugs#existing-luks-volumes
16:16:53 <clumens> what's the purpose of this discussion?  figure out what should be a blocker and what shouldn't be?
16:16:53 <jlaska> attempting an install, on top of an already encrypted system will fail
16:17:08 <Oxf13> clumens: pretty much yes
16:17:16 <jlaska> clumens: ah thank you, yes ... to review the list and make sure what's on the list matches the beta criteria
16:17:24 <jlaska> #link https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
16:17:28 <clumens> okay i'm with you now.
16:17:54 <adamw> clumens: also to check on the status of the bugs we accept as blockers
16:18:01 <adamw> make sure they're on the road to getting fixed
16:18:27 <clumens> 565848 sure seems like blocker material to me
16:18:50 <adamw> agree
16:18:54 <jlaska> +1
16:19:16 <jlaska> we don't have specific criteria for the beta that states you must be able to unlock existing encrypted partitions, and install
16:19:22 <jlaska> but it's a fairly common use case
16:19:42 <clumens> this is exactly the sort of thing i want my automated storage testing to catch.
16:19:50 <jlaska> and considering installing with encryption is on the Alpha criteria
16:20:03 <jlaska> alright, so I think there' agreement on this  one
16:20:09 <jlaska> Oxf13 any concerns/worries?
16:20:27 <Oxf13> none, other than it hasn't seemed to be fixed yet and we knew about it pre-alpha
16:20:54 <jlaska> #agreed bug#565848 is a beta blocker
16:20:55 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=565848 medium, medium, ---, dlehman, ASSIGNED, LVMError: lvactivate failed for lv_root: Skipping volume group vg_test1148
16:21:13 <clumens> yeah i do not know the status of any potential fix, but it doesn't look like there's much in the works from reading the bug report.
16:21:49 <jlaska> when I spoke to dlehman about it originally, he seemed to understand the problem ... but would need him for guidance on what a fix would entail
16:22:09 <jlaska> anything else to do on this, other than check-in on it again next week?
16:22:26 <clumens> probably ought to mention to dlehman that it should be a priority.
16:22:51 <jlaska> okay ...
16:22:51 <clumens> he's been busy working on converting our branch management discussions into documentation, so it may have slipped his mind.
16:23:13 <jlaska> #action jlaska to summarize F13Beta blocker discussion in 565848 report for dlehman
16:23:34 <Oxf13> yeah, I'm not trying to criticize, I was just concerned that there wasn't movement on it yet
16:24:05 <jlaska> right on
16:24:09 <jlaska> alright ... next up ...
16:24:18 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=565879
16:24:19 <buggbot> Bug 565879: medium, medium, ---, anaconda-maint-list, MODIFIED, OSError: [Errno 2] No such file or directory: '/mnt/sysimage/None'
16:24:54 <jlaska> to quote Adam, some guy whose name rhymes with "Cranes Maska" filed this .. and it's in MODIFIED
16:25:05 <Oxf13> looks like we just need a build with this fix
16:25:22 <clumens> you should have had one, for quite a while now
16:25:27 <adamw> yeah i was about to say that
16:25:28 <jlaska> even better ... anaconda-13.27-1
16:25:36 <jlaska> I think the reporter (me) just need to confirm the fix
16:25:36 <adamw> if it was modified on 02-16 it should be testable by now
16:25:40 <adamw> yeah, that slacker
16:25:44 <jlaska> geez, no kidding!
16:25:46 <clumens> jlaska: this was filed during that couple days where you filed a million and i fixed a million.
16:25:59 <jlaska> clumens: lets make it a million + 1
16:26:12 <jlaska> #info suspect this issue is already fixed in F-13-Alpha
16:26:20 <clumens> you had an updates.img you were throwing things into, hence the last comment being a link to the patch
16:26:21 <jlaska> #action jlaska to retest and update bug
16:26:57 <jlaska> yeah, this was definitely fix ... I just didn't follow through with the accounting
16:27:08 <clumens> next!
16:27:15 <Oxf13> man, wouldn't it be nice if we had some sort of system that would notice an anaconda build, with bug numbers in the changelog, and modify the bugs it references accordingly
16:27:24 <jlaska> Oxf13: :)
16:27:34 <jlaska> alright, next ...
16:27:36 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568015
16:27:37 <buggbot> Bug 568015: medium, low, ---, anaconda-maint-list, MODIFIED, Both DMRAID and backing disks show up as selectable in step cleardisksel
16:27:38 <adamw> that's crazy talk, son
16:27:47 <jlaska> Cranes Maska again
16:27:55 <jlaska> good lord
16:28:07 <clumens> that guy
16:28:08 <jlaska> same batch of million fixes that clumens mentioned I believe
16:28:19 <jlaska> #info in MODIFIED and fixed in anaconda-13.30-1
16:28:25 <adamw> can you believe, some company was dumb enough to hire that guy?
16:28:28 <Oxf13> that guy needs to get on the ball.
16:28:37 <adamw> man, they're gonna regret THAT
16:28:42 <jlaska> I've already confirmed this puppy, will follow-up with the bz trail
16:29:05 <jlaska> adamw: this is pro bono work
16:29:07 <clumens> jlaska: one sec on that one.
16:30:04 <jlaska> #link http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=612d92b68c5deffad4ab9edf4d055b1cb1235ff9
16:30:04 <clumens> i don't see a reference to the bug number in git log.
16:30:26 <jlaska> ah, filed against RHEL6 too
16:30:33 <jlaska> so that bug# landed in the git log
16:30:42 <clumens> ah i should have put both bug numbers in the commit message.  sorry about that.
16:30:53 <jlaska> no worries ... once again, thank you git log
16:30:55 <clumens> i'm going to update the bug to say so.
16:31:15 <jlaska> I'll move it ot VERIFIED -> CLOSED ERRATA after you do that
16:31:27 <jlaska> #action jlaska confirmed this is fixed, will make appropriate changes in bugzilla
16:31:27 <clumens> done
16:31:38 <jlaska> thanks, next ...
16:31:53 <jlaska> btw ... I'm not evaluating these for F13Beta
16:31:58 <Oxf13> jlaska: you shouldn't have to #link to get links picked up in the log
16:32:14 <jlaska> Oxf13: okay ... I always forget whether I need to or not
16:32:30 <jlaska> if folks want to re-evaluate some of these issues filed during Alpha test that already have commits, we can
16:32:38 <jlaska> otherwise, I'll just keep going
16:32:44 <jlaska> dlehman welcome!
16:32:45 <Oxf13> jlaska: guess it doesn't hurt (:
16:33:02 <adamw> jlaska: just chug on
16:33:12 <adamw> if they're already fixed it's not worth arguing over whether they're blockers
16:33:37 <jlaska> we can dbl check for the next one ...
16:33:39 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568334
16:33:40 <buggbot> Bug 568334: medium, low, ---, anaconda-maint-list, MODIFIED, anaconda 13.31 exception report - KeyError: 'cleardiskssel'
16:34:15 <Oxf13> moar modified
16:34:20 <jlaska> #info already fixed in F-13-Alpha (anaconda-13.33-1)
16:34:34 <jlaska> This bug was causing upgrades to fail
16:34:51 <Oxf13> if it was fixed in alpha, why are new reports coming in as of the 11th?
16:35:08 <Oxf13> n/m, the last traceback was anaconda-13.32
16:35:09 <jlaska> checking git ...
16:35:11 <clumens> what version of anaconda was in the alpha?
16:35:27 <clumens> yeah, nevermind.
16:35:28 <Oxf13> clumens: excellent question.  I screwed up the koji tagging so I don't ahve that info handy
16:35:29 <jlaska> http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=c61f9d8842baab8431ed1bb10af799e624fe051a
16:35:42 <jlaska> 33-1 I think ... dbl checking
16:36:01 <Oxf13> 13.32-1 is what I see in the ALpha
16:36:26 <Oxf13> or at least in the bleed repo I used to compose the alpha
16:36:49 <jlaska> anaconda installer init version 13.32 using a serial console
16:36:57 <Oxf13> jlaska: 13.33 didn't land until March 4th.  There is no way it could have been in the Alpha
16:36:58 <jlaska> so this will need confirmation still
16:37:24 <jlaska> as for beta blocker potential ... "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation of the previous stable Fedora release, either via preupgrade or by booting to the installer manually "
16:37:33 <adamw> right, breaking upgrades is a perfect beta blocker case
16:37:56 <jlaska> all in favor?
16:38:58 <adamw> aye
16:39:05 <jlaska> Oxf13: dlehman/clumens?
16:39:29 <clumens> we're voting to make a blocker out of a bug we already believe to be fixed?  sure.
16:39:52 <pjones> clumens: if only all blockers could be so easy.
16:39:52 <Oxf13> hah
16:39:55 <jlaska> clumens: heh, odd I know ... just confirming our previous assertions hold
16:40:18 <jlaska> #agreed 568334 is a valid F13Beta blocker affecting upgrades
16:40:38 <jlaska> #action fix available in branched/13 awaiting confirmation
16:40:54 <jlaska> I can poke this along with my other tests
16:41:16 <jlaska> next ...
16:41:19 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568367
16:41:20 <buggbot> Bug 568367: medium, low, ---, msivak, ASSIGNED, Mounting disks read-only in rescue mode presents error
16:41:54 <jlaska> I believe this bug impacts the existing Beta criteria "#  The rescue mode of the installer must be able to detect and mount LVM, encrypted, and RAID (BIOS, hardware, and software) installations"
16:42:15 <jlaska> but the criteria are not explicit as to whether mounting read-write or read-only should succeed
16:42:23 <jlaska> but I'd still support this for Beta
16:42:33 <adamw> i'd say both, i'd forgotten it could do them both ways when writing that
16:42:52 <jlaska> I was going with that assumption when I added this one
16:43:08 <adamw> criteria fixed =)
16:43:23 <Oxf13> yeah, I'd support this one being a blocker
16:43:34 <jlaska> #info beta rescue mode criteria updated to include RW and RO access of existing storage
16:44:28 <jlaska> Howabout the gentlemen representing the great state of Installer?
16:44:38 <dlehman> I'm not sure anything is actually wrong with the mounted system in spite of the message
16:44:53 <Oxf13> right, it's likely we just need to catch those messages better
16:45:14 <dlehman> but it's trivial to skip the selinux voodoo when mounting read-only
16:45:17 <Oxf13> or rather not try to do selinux stuff on a ro fis
16:45:26 <clumens> dlehman: yeah, we just need to do it.
16:45:42 * dlehman is in favor
16:46:02 <jlaska> #agreed 568367 is a valid Beta blocker, impacts rescue mode read-only mounting of existing storage
16:46:09 <clumens> definitely something i've meant to get around to.
16:46:26 <jlaska> alright, we'll stay tuned to the bz and we can bug Cranes Maska to test this next week
16:46:56 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=569377
16:46:57 <buggbot> Bug 569377: medium, low, ---, hdegoede, ASSIGNED, CDROM install unable to eject disc - storage: error ejecting cdrom sr0: (5, 'Input/output error')
16:47:25 <jlaska> this is a weird one ... could be a edge case
16:47:46 <clumens> i'd like to see more reports of it, but it feels like a blocker to me.
16:47:49 <jlaska> basically, during a bare metal CDROM install ... it failed to eject the disc, and I had to manually eject the disc and remount the next disc
16:47:54 <adamw> waiting for input from some Maska guy
16:47:59 <jlaska> clumens: yeah, I'd feel comfortable with someone else hitting this
16:48:09 <jlaska> adamw: I don't believe this is waiting on me
16:48:17 <jlaska> or *cough* that Maska guy
16:48:32 <adamw> posts 9 and 10
16:48:42 <adamw> clumens says he already asked for the info, but i don't see the info anywhere
16:48:49 <jlaska> that feedback is in 9
16:49:08 <jlaska> oh wait, boy  I swear I got back on that one
16:49:13 <clumens> it needs one of us to reproduce it and dive in with the debugger.
16:49:27 <adamw> oh, the feedback for the python command is #5
16:49:31 <adamw> no feedback for the eject -v though
16:49:55 <jlaska> adamw: I'll post back, but one interesting thing I found was that eject was no longer available in F-13-Alpha
16:50:30 <jlaska> I was diffing the contents of install.img from the F-13-Alpha-RC4 and a previous install.img where I used the work around ... and it seems that some hal eject command went away ...
16:50:37 <jlaska> /usr/libexec/hal-storage-eject
16:50:49 <jlaska> I'm not sure if that also meant that the 'eject' command went with it
16:51:08 <jlaska> anyway, I'll add that to the bz
16:51:21 <Oxf13> eject might have gone away when busybox went away
16:51:25 <clumens> likely
16:51:36 <jlaska> #info needs to be reproduced on more systems
16:52:10 <jlaska> so, I'll retest with F-13-Alpha, on the same system ... if it's not happening again ... I'm fine closing this out until others hit this
16:52:41 <jlaska> I'd like to keep this on, and if we don't have any additional reports of this failure, we'll bump it off next week?
16:52:45 <jlaska> how's that sound?
16:53:01 <jlaska> Oxf13: clumens: is that bad that eject is missing?
16:53:11 <adamw> sure
16:53:19 <adamw> i'm not sure how many people are testing the split cd install though
16:53:21 <clumens> jlaska: nothing in anaconda calls it, though i suppose someone might want it in a %post script.
16:53:21 <adamw> i know i didn't
16:53:57 <mclasen> :q
16:54:02 <jlaska> #action Keep 569377 on the F13Beta list for 1 more week.  If no additional reports surface, consider removing from F13Beta (or closing)
16:54:22 <jlaska> if it's widespread, it would impact the existing Beta criteria ... "#  The installer must be able to use the CD and DVD local package source options "
16:54:31 <jlaska> sorry, I meant ...
16:54:32 <jlaska> "#  The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, multi-CD, and boot.iso install media "
16:54:41 <Oxf13> I suppose we should spin up a split media set with the latest anaconda to see if it's still an issue
16:54:53 <clumens> Oxf13: we should make sure we have a latest anaconda, then
16:54:55 <Oxf13> like when we are supposed to do the test compose.
16:54:58 <jlaska> Oxf13: I'd be happy to test that ... can we spin that once we get the RATS build?
16:55:05 <Oxf13> clumens: that's something I"ve been working with dlehman won.
16:55:11 <Oxf13> jlaska: should be able to yes
16:55:12 <clumens> ah, cool.
16:55:18 <clumens> i'll stay out of it then
16:55:27 <jlaska> Oxf13: want to action that?
16:55:43 <Oxf13> sure
16:55:55 <Oxf13> #action Oxf13 will deliver split media with RATS image builds
16:56:14 <jlaska> #action jlaska to retest split media on same hardware that originally reported the issue
16:56:31 <jlaska> #help Any testing of split media (CD) installs would be appreciated
16:56:38 <jlaska> alright ... next bug ...
16:56:51 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572489
16:56:52 <buggbot> Bug 572489: low, low, ---, rvykydal, NEW, Network is disabled on install
16:57:08 <clumens> this will be fun.
16:57:23 <jlaska> ah, this is the classic, network-less install doesn't start networking post-install ?
16:57:43 <adamw> i thought our position on that was that it's a feature.
16:57:46 <Oxf13> ... clicking the icon in the task bar is too hard?
16:57:53 <adamw> until there's a network tool in the installer, anyway.
16:57:58 <jlaska> https://fedoraproject.org/wiki/Common_F11_bugs#network-doesnt-connect
16:58:00 <jlaska> ?
16:58:05 <Oxf13> IIRC we kicked the network config tool /out/ of the installer
16:58:24 <clumens> we did.
16:58:33 <adamw> jlaska: it's in common_bugs because it was too late to add it to release notes
16:58:34 <clumens> now they want us to pull it back in, but call it networkmanager instead
16:58:38 <jlaska> adamw: right
16:58:43 <adamw> jlaska: but see the bottom link to the intended release note
16:58:47 <jlaska> ah okay
16:58:57 <adamw> it was going to be a release note because it was an intended change, not a bug.
16:59:05 <Oxf13> right, I don't see this as a bug
16:59:15 <Oxf13> NetworkManager is there, you just have to tell it what to do
16:59:20 <jlaska> clumens: lemme ask this, is the installer doing any network config writing in the network-less (DVD/CD) install case that would change the post-install NetworkManager behavior?
16:59:21 <Oxf13> it's not going to make assumptions for you
16:59:43 <Oxf13> jlaska: well, in a network install /etc/sysconfig/network-* files get written out
16:59:53 <Oxf13> that's how we trigger NetworkManager to do something
16:59:58 <Oxf13> in a networkless install, no files
17:00:07 <Oxf13> no data for NetworkManager to read from and act upon
17:00:18 <mclasen> it means no network in firstboot, right ?
17:00:29 <jlaska> NM used to autoconnect to wired network, is this the behavior change that people are bz'ing here?
17:00:38 <jlaska> ^--> I thought it did at least
17:00:38 <clumens> not everyone may be able to click on the icon, though.  this would hit people who are doing network auth, nfs, stuff like that.
17:00:42 <clumens> mclasen: correct.
17:00:47 <mclasen> with the possible consequence that you can't set up network auth, maybe
17:01:08 <clumens> right.  you can choose it, but it won't do anything.  there's a bug about that duped to the one under discussion.
17:01:29 <adamw> having the option to configure the network in the installer does seem like something of a no-brainer here
17:01:30 <mclasen> of course, my take on this is that firstboot should move into the session, but thats not for this meeting
17:01:32 <Oxf13> jlaska: that's a good question.
17:01:32 <adamw> why was it taken out?
17:01:58 <Oxf13> mclasen: is this a behavior change in NetworkManager when faced with no existing config?
17:02:07 <mclasen> I can't answer that
17:02:26 * mclasen goes to summon dcbw
17:02:30 <Oxf13> adamw: because duplication of code was bad, and anything beyond a simple configuration in anaconda was overboard.
17:02:55 <Oxf13> adamw: and because the network config tools we had at the time were all focused on system-config-network and the network service, which we weren't using in favor of NetworkManager
17:02:58 <jlaska> I don't think anaconda is the proper component for this issue, maybe dcbw can offer whether this is a valid bug for NM, or an intentional behavior change
17:02:59 <adamw> well, see the cases we're discussing above. if your environment needs networking to be running for you to login, it seems logical to configure it in the installer...
17:03:09 <Oxf13> adamw: or firstboot
17:03:21 <adamw> i thought we were trying to kill firstboot, in the end? people generally hate it.
17:03:25 <Oxf13> adamw: the point of the installer is to lay down packages, not do a ton of system configuration
17:03:27 <adamw> but sure, that would work too i guess
17:03:59 <jlaska> dcbw: welcome to the jungle
17:04:10 <jlaska> dcbw: we're discussing /topic bug
17:04:31 <clumens> we've had quite a few bugs from quite a few people on this "no network install implies no network post-install" bug.
17:04:40 * jlaska copy'n'paste previous comments for dcbw ...
17:04:48 <jlaska> 12:00:28   jlaska: NM used to autoconnect to wired network, is this the behavior change that people are bz'ing here?
17:04:52 <jlaska> 12:00:37   jlaska:  ^--> I thought it did at least
17:04:53 <jlaska> 12:01:57   Oxf13: mclasen: is this a behavior change in NetworkManager when faced with no existing config?
17:04:56 <jlaska> 12:02:07   mclasen: I can't answer that
17:04:58 <jlaska> </paste>
17:05:01 <jlaska> 12:02:26  * mclasen goes to summon dcbw
17:05:09 <dcbw> ummm
17:05:13 <dcbw> this has always been the case
17:05:17 <dcbw> standard DVD install
17:05:28 <dcbw> since you're installing from DVD, anaconda assumes you do not want to enable networking
17:05:35 <clumens> right
17:05:36 <dcbw> and thus writes ONBOOT=no to your ifcfg file
17:05:47 <clumens> "always" since a year or two ago, really.
17:05:52 <dcbw> so NM likewise does not enable your networking on boot
17:06:04 <dcbw> clumens: I thought this was how we'd always handled it though?
17:06:10 <dcbw> clumens: you only get network-by-default if you install over the network?
17:06:20 <clumens> dcbw: we used to have a network config screen in anaconda that you got regardless.
17:06:20 <dcbw> otherwise there are security questions
17:06:29 <dcbw> clumens: ah right
17:06:51 <Oxf13> so this doesn't seem like a recent change
17:07:08 <jlaska> so is this just a matter of clearing up (or reinforcing) expectations from a non-network install?
17:07:25 <adamw> does live CD behave same as DVD, btw?
17:07:33 <mclasen> is a livecd install a non-network install, btw ?
17:07:36 <adamw> i thought you wind up with a network connection at first boot if you install from live...
17:07:38 <adamw> mclasen: =)
17:07:45 <jlaska> adamw: mclasen: good question
17:07:49 <dcbw> adamw: I think there's some magic for that
17:07:49 <adamw> i'm fairly sure when you boot live, it auto-connects to the network
17:07:59 <adamw> then when you install it also connects when you boot
17:07:59 <dcbw> adamw: I don't believe it works the same way as the dvd install
17:08:05 <adamw> so our live / DVD behaviour seems inconsistent
17:08:11 <dcbw> in fact, I think the magic is just to delete any ifcfg files or something postinstall
17:08:20 <jlaska> adamw: what does ONBOOT= say for the live environment?
17:08:30 <jlaska> cause that's what is written out to the installed system, right?
17:08:38 <clumens> the livecd likely only follows the lead of whatever you did before running anaconda.
17:09:13 * jlaska prepares to ring the bell on this bug ...
17:09:19 <Oxf13> We likely force livecd to onboot=yes
17:09:32 <Oxf13> so really
17:09:35 <Oxf13> this is not a new issue
17:09:39 <adamw> let's just say for now that this clearly isn't a blocker bug, anyway
17:09:43 <Oxf13> nor is it one I feel qualifies for a Beta blocker
17:09:49 <adamw> although we could question whether it's really optimal behaviour
17:10:05 <Oxf13> adamw: not really our discussion to have
17:10:08 <Oxf13> at least not in this venue
17:10:09 <clumens> if we don't take it for f13, it's going to have to go in right at the beginning of f14.
17:10:09 <adamw> exactly
17:10:15 <adamw> hence 'could'
17:10:23 <mclasen> really more 'installation experience design' than 'beta blocker
17:10:29 <Oxf13> clumens: "take it" ?
17:10:48 <clumens> Oxf13: the behavior's definitely going to change, and the modification in question will be getting merged in eventually.
17:11:12 <jlaska> so ... what to do with the bz?  Remove it from F13Beta?  Howabout reassign or CLOSE it?
17:11:17 <Oxf13> clumens: I think that may fall under a feature freeze break discussion
17:11:19 <adamw> remove it from f13beta
17:11:26 <adamw> given the above discussion i don't think we should close it
17:11:31 <Oxf13> remove from 13-beta, mark with needs relnotes
17:11:33 * clumens would still like to see these modifications, but...
17:11:39 <jlaska> is anaconda the correct component to continue discussion of this?
17:11:48 <clumens> yes please leave it assigned to anaconda
17:11:51 <jlaska> okay ...
17:11:52 <dlehman> probably
17:11:59 <dcbw> unless we want to redefine how NM interprets ONBOOT, anaconda is the correct place
17:12:28 <jlaska> #agreed After discussion, agreed 572489 is not a F13 Beta blocker
17:12:47 <jlaska> #action Remove 572489 from F13Beta, continue discussion around user experience in bug
17:13:02 <jlaska> #action Set relnotes? for 572489
17:13:13 <jlaska> okay, that's the last of the anaconda bugs, let's move on
17:13:22 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=567346
17:13:23 <buggbot> Bug 567346: medium, low, ---, richard, ASSIGNED, gpk-update-viewer does not display changelogs nor updates packages
17:13:25 <clumens> laters
17:13:34 <jlaska> clumens: dlehman: thanks for your time gang
17:13:38 <jlaska> pjones: you too
17:13:48 <dcbw> I'll be on #fedora-desktop too if you need more for anything else
17:13:53 <adamw> thanks clumens / dcbw
17:14:05 <adamw> so, i've been hitting this bug without langpacks installed at all
17:14:07 <jlaska> ah, missed him ... well, thanks dcbw :)
17:14:25 <adamw> i've talked with hughsie about it. we're fairly sure the situation is simply that it fails if there's any dependency problem in the pending update set
17:14:48 <jlaska> adamw: if this is wide spread, it already qualifies as an Alpha blocker
17:14:51 <adamw> hughsie wasn't entirely sure what was going wrong, last time I checked with him...he logged into my system to do some diagnostics
17:15:16 <adamw> yeah, it should probably have been an alpha blocker, except we incorrectly thought it only happened if langpacks was installed.
17:15:38 * mclasen thinks the bug needs retitling
17:15:39 <jlaska> seems so yeah, this was a tough one to pinpoint with the repo contents changing during different re-tests
17:15:51 <mclasen> it is about upates not getting installed, at this point, right ?
17:15:53 <jlaska> adamw: can you adjust the title to match the latest findings?
17:16:06 <mclasen> and I've seen it happen yesterday, as well
17:16:06 <adamw> will do, and add a comment
17:16:18 <jlaska> adamw: thanks
17:16:25 <Oxf13> it should be trivially easy to setup a broken repo to test against
17:16:27 <adamw> mclasen: yep, the 'not displaying changelogs' was a separate, coincidental bug which got fixed already
17:16:30 <jlaska> #action adamw updating 567346 to reflect latest test results
17:16:46 <adamw> Oxf13: yeah, we should probably do that; just any kind of broken dep that --skip-broken would usually avoid is the trigger
17:16:55 <mclasen> unfortunately, hughsie seems not around today, so I don't have an update on that bug
17:16:57 <jlaska> #info 567346 seems unrelated to yum-langpacks plugin, occurs whenever dependency problems exist in enabled package repositories
17:17:21 <Oxf13> jlaska: to be fair, there was an issue with yum-lanpacks at the same time
17:17:34 <Oxf13> yum-langpacks would cause a broken-dep scenario when there wasn't one otherwise
17:17:42 <Oxf13> so it made this bug happen more often
17:17:46 <jlaska> Oxf13: yeah, good point
17:17:58 <mclasen> of course, one strategy is to just not release with broken deps...
17:18:03 <jlaska> mclasen: :)
17:18:08 <jlaska> alright, anything else to discuss for this bug?
17:18:11 <mclasen> but we need to make gpk give a clear error message there
17:18:29 <jlaska> check-in on this again next week?
17:18:42 <mclasen> I'll chat with hughsie on monday
17:18:49 <jlaska> mclasen: roger, thanks
17:18:50 <adamw> bug updated
17:19:05 <jlaska> #action mclasen and hughsie to discuss issue next week
17:19:12 <jlaska> alright, next up ...
17:19:16 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=568106
17:19:17 <buggbot> Bug 568106: medium, low, ---, pjones, NEW, Unable to enter grub menu in F-13-Alpha with console=ttyS0
17:19:43 <jlaska> as the title suggests, this was found during Alpha testing
17:19:54 <jlaska> we don't have an explicit criteria for this  (I don't think) ...
17:20:12 <jlaska> the problem is that whenever doing a non-graphical virt install ... you can't access the grub menu to change the boot options
17:21:05 <adamw> it's more or less caught by the "Beta Blocker Bugs" weasel paragraph though
17:21:14 <jlaska> I think this would be important to the virt folks, the workaround requires libguestfs to modify any grub.conf values in the guest (instead of adjusting them directly using grub menu)
17:21:29 <jlaska> adamw: which one is that?
17:21:30 <adamw> grub is critical path, and we can certainly argue this is high severity with no reasonable workaround
17:21:43 <jlaska> ah, I see
17:21:57 <adamw> jlaska: the paragraph right under the explicit requirements which we have to catch icky situations like this
17:21:58 <jlaska> pjones: we've talked about this one briefly, do you have any concerns?
17:22:09 <jlaska> adamw: ah!
17:22:42 <jlaska> Oxf13: any input?
17:23:24 <Oxf13> your definition of non-graphical, that means not using virt-viewer to view a non-graphical install?
17:23:35 <jlaska> Oxf13: no, you can use virt-viewer
17:23:40 <Oxf13> the install itself might not be graphical, but you could still be using virt-viewer.
17:23:47 <jlaska> I should clarify and say that any situation where grub is using serial output
17:23:48 <Oxf13> in those cases, I manage to interrupt grub
17:24:13 <jlaska> the non-serial output grub appears to behave normally
17:24:22 <jlaska> hold Shift, modify boot args etc...
17:24:25 <Oxf13> ok, so this really is limited to serial operation.
17:24:31 <jlaska> Oxf13: yeah, right on
17:24:47 <Oxf13> that... I'm not sure would be a beta blocker.  I'd like to get pjones' input on that
17:25:46 <jlaska> I'd support it in that it's a real pain in the butt to work around during our testing, the same way we've included cmdline and serial installs as Alpha tests
17:26:34 <jlaska> pjones might be @ lunch
17:26:34 <adamw> we took cmdline and serial out of the criteria though didn't we? at anaconda team's request
17:26:43 <jlaska> adamw: nope, left them in per request
17:26:45 * jlaska finds link ...
17:26:53 <jlaska> adamw: but I think it went out, then back in
17:27:03 <jlaska> https://www.redhat.com/archives/anaconda-devel-list/2010-February/msg00059.html
17:27:49 <jlaska> I'd say, let's leave it on, see if we can get feedback from pjones after the meeting
17:28:04 <jlaska> in the interest of moving in
17:28:08 <jlaska> s/in/on/
17:28:19 <jlaska> adamw: Oxf13: you okay with that?
17:28:40 <adamw> okay.
17:28:59 <Oxf13> sure
17:29:10 <jlaska> #info No consensus reached on F13Beta criteria
17:29:51 <jlaska> #info Needs feedback from pjones whether it is a Beta blocker or not
17:30:03 <jlaska> next ... and F12 bug ..
17:30:05 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=533746
17:30:06 <buggbot> Bug 533746: urgent, low, ---, kernel-maint, ASSIGNED, Fedora 12 livecd freezes at udev on Acer Aspire One D250
17:30:13 <Oxf13> yeah that thread talks about desire to test these things, I'm not sure teh desire to test == block the release if it's broken
17:31:00 <jlaska> Oxf13: fair point, there may be cases where things we need working for testing don't line up exactly with criteria.  I think that speaks to adamw's extra clause
17:31:22 <jlaska> Oxf13: hopefully we can follow-up on that with pjones later
17:31:39 <jlaska> adamw: I think beland added this bug, are you familiar with this one?
17:31:55 <adamw> it's a judgement call
17:31:57 <adamw> it *is* a bad bug
17:32:10 <Oxf13> eew yeah
17:32:17 <adamw> various models of Acer Aspire One (which is a very popular netbook series) just wedge hard at boot without a magic kernel parameter
17:32:20 * jlaska heard linville talkign about this yesterday
17:32:33 <Oxf13> I'm not inclined to block the release over it unless the kernel folks think they can have a fix for it in a reasonable amount of time
17:32:44 <adamw> basically the ssb module (which is the common code for broadcom network adapters, both broadcom wireless and wired adapters load ssb, then b43 or b44 depending)
17:32:52 <adamw> when ssb gets loaded, everything dies
17:32:56 <Oxf13> cute
17:33:06 <adamw> so a) by default you can't boot the thing
17:33:20 <adamw> and b) even after you find the magic workaround that makes it boot, ethernet will not work if it uses broadcom ethernet
17:33:25 <adamw> since the magic workaround is not to load ssb
17:33:41 <adamw> you can use the broadcom proprietary driver to get wireless working at least, but there's no ethernet workaround that i'm aware of.
17:33:53 <jlaska> ooh, this is a good one
17:34:00 <adamw> if anyone took any notice of Target bugs i'd say make this f13target
17:34:09 <adamw> but, as discussed on the list, no-one does. i suspect that's why beland made it a blocker
17:34:48 <jlaska> we have any data on how many systems are impacted?
17:34:57 <adamw> we could probably pull something out of smolt.
17:34:58 <jlaska> just a few Acer models ... or a whole range of hardware
17:35:22 <adamw> i think i've heard of one case of the same bug on a non-acer system, but mostly people notice it on Aspire Ones
17:36:02 <adamw> Aspire One is the best-selling netbook line period, though, last time i saw the stats.
17:36:27 <jlaska> that would support keeping it on the radar for now ... pending feedback from someone on the kernel side
17:37:12 <Oxf13> yeah, I'd vote to keep it on for now, to get the attention of the kernel folks
17:37:12 <jlaska> is this something that cebbert could help with?
17:37:40 <jlaska> #info i think i've heard of one case of the same bug on a non-acer system, but mostly people notice it on Aspire Ones
17:37:52 <jlaska> #info Aspire One is the best-selling netbook line
17:37:59 <adamw> in the end we would probably bump this if we can't get a fix for it, but we should definitely monitor it and try to get one
17:38:35 <jlaska> #agreed keep 533746 on the F13Beta list, pending feedback from kernel experts
17:38:48 <jlaska> anything else we can discuss on that?
17:39:11 * jlaska guesses no, and moves on
17:39:14 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=559290
17:39:18 <buggbot> Bug 559290: medium, medium, ---, lvm-team, ASSIGNED, LVMError: lvcreate failed for VolGroup/lv_root - 512M insufficient for Fedora install
17:39:34 <jlaska> ah, the minimum memory requirement
17:39:35 <adamw> there's somewhere near 1,000 systems that I think are of the affected type on smolt.
17:39:39 <adamw> (for the acer bug)
17:39:56 <jlaska> adamw: good data grab
17:40:23 <jlaska> for /topic ... I thought someone from the lvm team had an update they wanted tested
17:40:38 <jlaska> ah, comment#28
17:40:53 <jlaska> Oxf13: what's the best way to test that in the install path?
17:40:54 <Oxf13> yeah, it's a matter of getting that built in the right place
17:41:05 <Oxf13> do an f-13 build an I can do a test compose with it
17:41:06 <adamw> 1,328. though it's not a totally reliable count, the model names acer uses are pretty generic.
17:41:16 <adamw> okay, i'm onto the next bug now =)
17:41:33 <jlaska> sorry, I'm trying to get this closed out to free you guys up ... thanks for the data though
17:42:09 <jlaska> Oxf13: okay, I'll update the bug requesting an f13 build from agk ... needs to be in updates-testing, or they just need a build?
17:42:25 <jlaska> #info agk has a fc14 build available for test (lvm2-2_02_62-1_fc14)
17:44:19 <jlaska> #info updated bug requesting fc13 build so that rel-eng + QA can test using a install image
17:44:46 <jlaska> as for F13Beta ... I'd like this on the list ... with a resolution of improving lvm's memory footprint, or adjusting the documentation
17:44:49 <jlaska> any concerns?
17:45:04 <Oxf13> nope
17:45:29 <jlaska> #agreed Keep 559290 on F13Beta pending test results against new lvm2 build
17:45:30 <adamw> no, sounds good
17:45:44 <jlaska> thanks gang, okay hold on ... last one ...
17:45:48 <jlaska> #topic https://bugzilla.redhat.com/show_bug.cgi?id=572215
17:45:49 <buggbot> Bug 572215: medium, low, ---, jforbes, NEW, unhandled vm exit: 0x11 - while creating a guest using virt-install
17:46:49 <jlaska> This bug is surfacing during rats_install i386 tests
17:47:09 * Oxf13 has to step away for af ew
17:47:54 <jlaska> I think this needs some input from jforbes or markmc, but it appears to be an issue that's been reported and fixed upstream already
17:48:00 <jlaska> I'm uncertain why we're hitting this now though
17:48:17 <adamw> the criterion you referenced was sort of intended for 'normal' testing, rather than the rats environment...
17:48:30 <adamw> i.e. do you hit this if you just install a stock f12 desktop, run virt-manager, and try to install f13?
17:48:45 <jlaska> adamw: agreed, I'm still trying to confirm whether this is specific to rats and why
17:49:21 <jlaska> I'll need guidance from the virt folks for that
17:50:06 <jlaska> adamw: what do you recommend?  keep on the list pending additional info, or remove pending additional info?
17:50:22 <adamw> we can keep it for now i guess
17:50:42 <jlaska> I agree with you though, need to see how wide spread this problem is to consider it
17:51:10 <jlaska> I reinstalled that Fedora-12-i386 test system used in the RATS test, and the problem remains
17:51:23 <jlaska> so either a recent virt update on F-12, or something funky with RATS ... both possible
17:51:44 <jlaska> #action jlaska to continue investigating problem, will need guidance from virt folks
17:52:09 <jlaska> #agreed Keep 572215 on the list, and revisit next week.  If only impacts RATS environment, may consider dropping from F13Beta.
17:52:18 <jlaska> #topic Open discussion
17:52:24 <jlaska> Alright, I believe that's the last of F13Beta
17:52:28 <jlaska> (bugs that is)
17:53:01 <jlaska> do we need to look at F13Blocker for any beta candidates?
17:53:09 * jlaska peeks
17:53:50 <adamw> we could do a quick eyeball
17:54:15 <jlaska> I think bug#570302 should be a Beta Blocker
17:54:15 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=570302 medium, low, ---, hdegoede, ASSIGNED, Anaconda crashes on Intel BIOS RAID sets with pre-existing partitions
17:54:24 <jlaska> according to "#  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:55:53 <adamw> yeah, sounds like hans wanted to get the patch into beta
17:56:06 <adamw> we should also ask him if we should remove the workaround we added to the live cmdline for f12 i think
17:56:30 <adamw> i agree it should go on the beta list
17:56:51 <jlaska> adamw: do you mind adding that to the bz, I'm not as familiar with that live cmdline workaround
17:57:00 <adamw> sure
17:57:38 <jlaska> #agreed Move 570302 from F13Blocker to F13Beta
17:57:49 <adamw> just did it
17:57:57 <jlaska> thanks!
17:58:13 <jlaska> I feel like this yum-langpacks stuff should be ironed out in time for Beta (bug#569352)
17:58:14 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=569352 medium, medium, ---, petersen, ASSIGNED, Broken dependencies for 1:openoffice.org-langpack-en-3.2.0-12.7.fc13.x86_64
17:58:52 <adamw> feeling that it should be ironed out isn't the same as it being a blocker...
17:59:01 <adamw> would we delay the release if it was the last bug?
17:59:54 <jlaska> adamw: good point, we have criteria around no broken dependencies or conflicts in the Alpha criteria
18:00:04 <adamw> in the install media set
18:00:11 <jlaska> right
18:00:15 <adamw> and there aren't really any broken deps here exactly
18:00:29 <adamw> it's bad behaviour on the plugins part; it doesn't realize it should pull the language packs from the -testing repo
18:00:50 <adamw> which is a bug, sure, but more prominent in pre-release than post-release stage...if we wound up releasing f13 with this bug it wouldn't be *terrible*, given what we know about it right now, afaict
18:00:51 <jlaska> I agree, especially not that Jens marked the plugin as optional in comps, not default
18:01:19 <adamw> so i think it'd be nice to have it fixed but it shouldn't block beta and arguably may not block final...
18:01:35 <jlaska> with it no longer being installed by default, yeah I agree
18:01:41 <jlaska> bug#566425 will be interesting
18:01:42 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=566425 medium, low, ---, veillard, NEW, qemu: could not load kernel '/var/lib/libvirt/boot/virtinst-vmlinuz.bmav1g': Permission denied
18:02:05 <jlaska> not covered under the criteria presently
18:02:31 <jlaska> but impacts doing F13 guest installs on the F13 virt preview packages (which I believe means F13 virt guest+host)
18:03:13 <jlaska> but, it's on the list, so it won't get lost
18:03:26 <jlaska> adamw: anything concerning you on F13Blocker?
18:03:38 <adamw> i thought we had a criterion for f13 boot on f13?
18:03:43 <adamw> nope, not from a quick eyeball
18:04:20 <jlaska> adamw: I thought so too, but could only find F13 guest on F12 host
18:04:28 <jlaska> #  The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)
18:05:04 <jlaska> although, we'd likely want to ensure F13 can install+host it's own guests
18:05:13 <adamw> huh. i'm fairly sure we *meant* to cover the release-on-same-release case
18:05:16 <adamw> let's just add a criterion?
18:05:20 <jlaska> agreed
18:05:28 <jlaska> Final or Beta?
18:05:39 <jlaska> we should probably ask the virt gang
18:06:03 <adamw> beta
18:06:07 <adamw> for now
18:06:12 <adamw> they can bump it to final if they like
18:06:13 <adamw> i've added it
18:06:16 <jlaska> okay, I'll follow-up w/ jforbes after meeting
18:06:34 <jlaska> #info adamw added F13 virt host+virt guest to https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
18:06:37 <jlaska> adamw: thx
18:06:45 <jlaska> alrighty, I think we're done for today (only 2 hours later)
18:07:00 <jlaska> any other items to discuss before I call my friend #end_meeting ?
18:07:23 <jlaska> #action jlaska will follow-up with jforbes for thoughts on F13 virt guest+host as a Beta or Final criteria
18:07:33 * jlaska closing meeting in 30 seconds
18:07:35 <adamw> nope, we're good
18:07:47 <adamw> well we should move that 13-on-13 virt bug to f13beta now?
18:07:49 <adamw> to be consistent
18:08:05 <jlaska> adamw: ah yes, I'll go ahead and to that now
18:09:38 <jlaska> alright ... end of meeting gang ... thanks for your help :)
18:09:41 <jlaska> #endmeeting