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