15:00:19 #startmeeting Fedora QA meeting 15:00:19 Meeting started Mon Sep 10 15:00:19 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:23 #meetingname fedora-qa 15:00:23 The meeting name has been set to 'fedora-qa' 15:00:25 #topic roll call 15:00:35 morning folks, who's around to chase the f18 unicorn? 15:01:03 UNICORNS!!!! 15:01:07 * satellit listening 15:02:05 * Cerlyn watches 15:02:09 * brunowolff is lurking for about 20 minutes and then has to go to a work meeting. 15:02:13 * pschindl is here 15:02:36 is it pony unicorn? 15:03:07 * jreznik is here to chase the snake 15:03:29 ouch 15:03:41 * nirik is lurking 15:03:55 Perhaps those calling it a Spherical Cow have never seen a unicorn before 15:03:59 eeexcellent 15:03:59 jreznik: snake? I thought that we were talking about unicorns 15:04:04 jreznik picked a bad release to become the program manager! 15:04:37 adamw: channeling mr. burns are we? 15:04:42 * adamw pretends to wait for more people while actually making coffee 15:04:48 i *always* channel mr burns 15:04:50 .fire tflink 15:04:53 adamw fires tflink 15:05:45 tflink: unicorn snake? 15:06:04 * nb is lurking 15:06:33 jreznik: http://4.bp.blogspot.com/_3IBfde2A9L8/TIVUuLrUpRI/AAAAAAAADsQ/trjM02LXkkE/s1600/pony-magic.png ? 15:07:28 * maxamillion is here 15:07:58 alrighty, maxamillion's here, we can start! 15:08:01 =) 15:08:25 #topic Fedora 18 status check / mini blocker review 15:08:47 so i was kinda hoping we'd have an rc1 already by today, but no-one was around to do an anaconda build over the weekend 15:09:07 when we do get the new build, though, it should be in significantly better shape than tc6 15:09:09 #chair tflink 15:09:09 Current chairs: adamw tflink 15:09:49 adamw: ok, thanks for info 15:09:49 go/no-go is on thursday so we need to nail down testing on the next build fast to make sure we can hit the date (finally) 15:09:57 * cpuobsessed is sitting in the back corner 15:10:28 that's pretty much it, any other general f18 thoughts? 15:10:38 adamw: are anaconda guys working on a new build or poking is needed? 15:10:58 bug #845745 15:11:12 jreznik: haven't checked in with them yet, i only just woke up 15:12:06 cpuobsessed: what about it? 15:12:46 narrowed the breakage between 3.5.0-0.rc0.git6 and git7; so maybe those of us with certain ATI GPUs can start testing again 15:13:05 okay... 15:13:23 alright, are we ready for the mini-blocker review? 15:13:43 adamw: fire away captain 15:13:57 will saying 'no' help? 15:14:01 fire? where?! where?! abandon shop! 15:14:05 kparal: absolutely not. 15:14:09 I thought so 15:14:11 =) 15:14:17 kparal: was worth a shot ;) 15:14:18 #topic Fedora 18 - mini blocker review 15:14:24 over to you, cap'n flink 15:14:36 (we're all captains on this ship. it's suffering from severe rank inflation.) 15:14:49 #info 12 Proposed Blockers 15:14:49 #info 11 Accepted Blockers 15:14:49 #info 5 Proposed NTH 15:14:49 #info 5 Accepted NTH 15:15:03 #topic (855289) Dri files are missing in lorax ( /usr/lib64/dri/foo-dri.so: cannot open shared object file: No such file or directory ) 15:15:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=855289 15:15:08 #info Proposed Blockers, ON_QA 15:16:42 this is an icky one, viking is convinced this is causing a showstopper for him, but bcl isn't so sure this is the problem 15:16:51 no-one else seems to have chipped in yet 15:17:29 there is one more comment from Marcos 15:17:45 one other person chimed in, but it sounds like that might have been another instance of #854688 15:18:00 yeah, if it doesn't happen when you use English, it's not this bug. 15:19:12 I think I haven't tested TC6 DVD over USB. so I can't really say it doesn't happen to me 15:19:18 sounds like we might need more information but it's already part of the next lorax build 15:19:25 i don't think the medium is relevant to the bug 15:19:32 yep 15:19:33 graphics hardware conceivably could be, though 15:19:53 tflink: the question is whether we pull that lorax build or not 15:19:59 nothing else needs it - in fact this is the only change in it 15:20:02 we can ask them to retest with latest lorac but as bcl is not sure it's cause by missing dri... but... 15:20:12 jreznik: the problem is you can't really 're-test with latest lorax' 15:20:15 well, not easily 15:20:20 you have to build your own install image 15:20:26 lorax is used in the image compose process 15:20:43 we could build a test image pretty easily to see if that fixes things 15:20:49 if viking hasn't done so already 15:21:06 maybe that'd be best 15:21:13 adamw: in next tc/rc? 15:21:22 viking's usually pretty available so he should be able to test it quickly 15:21:25 but of course, sooner better 15:21:39 #action tflink to build test image w/ new lorax to test #855289 15:21:53 so punt on this till we have results from testing? 15:21:55 if this does indeed fix what viking was seeing - do we want to accept as a blocker 15:21:58 ? 15:22:19 punt is a better option than a conditional vote, I suppose 15:22:43 since we have another review on wednesday 15:22:59 proposed #agreed 855289 - It's not clear how widespread this problem is or whether the dri files will fix it - will revisit after more testing 15:23:04 ack/nak/patch? 15:23:53 ack as we can't do anything before we have more data... 15:24:03 ack 15:24:04 ack 15:24:12 #agreed 855289 - It's not clear how widespread this problem is or whether the dri files will fix it - will revisit after more testing 15:24:21 #topic (854471) anaconda stop at the "Error checking storage configuration" 15:24:25 #link https://bugzilla.redhat.com/show_bug.cgi?id=854471 15:24:27 #info Proposed Blocker, NEW 15:24:57 this is waiting for developer action. but I'm afraid storage.log is missing 15:25:42 yep :( 15:25:46 that's the most important log... 15:26:01 I tried to ping twu but he was already gone. we can put another needinfo there 15:26:43 proposed #agreed 854471 - Still missing information needed to triage, not completely sure of cause. Will revisit when there is more information available. 15:26:46 just 2 people reported that they saw this. it has probably very limited scope 15:26:57 ack 15:27:26 ack 15:27:43 ack 15:27:44 #agreed 854471 - Still missing information needed to triage, not completely sure of cause. Will revisit when there is more information available. 15:27:52 #topic (854586) F18 KDE Live (alpha TC5) Configure network dialogue isn't accessible in Anaconda 15:27:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=854586 15:27:57 #info Proposed Blocker, ON_QA 15:28:33 * tflink needs to leave for a bit 15:29:06 * adamw will carry on 15:30:08 so, i think what's been clarified since last week is you likely need a wireless connection to hit this 15:31:00 oh...or maybe i've got that wrong 15:31:01 I don't think so. is this the bug where you hit configure and it crashes? no matter whether live or DVD? 15:31:11 then you can do it with wired networking as well 15:31:14 * jreznik does not understand the bug 15:31:45 the reproducer is in https://bugzilla.redhat.com/show_bug.cgi?id=854586#c17 15:32:04 kparal: i'm fairly sure i tested in the last meeting and it didn't crash for me: clicking the configure button resulted in nothing happening, but no crash 15:32:19 adamw: hmm, you may be right 15:32:35 i think this may be specific to live images which don't include nm-c-e 15:33:11 then for live it's not a bad idea to depend on native DE network manager 15:33:17 and disable network spoke 15:33:25 I still believe it's worth +1 blocker, even it fails just for wifi 15:33:35 or +1 nth at least 15:33:39 i'm kinda leaning nth not blocker 15:33:42 (we already took it as nth) 15:33:46 but i'd like to be clearer... 15:33:59 * jreznik is more nth too and with no network spoke in live anaconda solution 15:34:21 the 'fix' for this in 18.6.6 is "require nm-connection-editor" 15:35:03 not sure it makes sense to have live de nm configuration and then nm-c-e one, it's quite confusing but good for alpha I guess 15:35:17 propose we just leave it as nth since the fix is in 18.6.6 anyhow 15:35:25 ok 15:35:32 fine with me 15:36:03 propose #agreed as this affects only more advanced network configuration in certain live environments, where it can be worked around by using the live environment's network configuration tools, this remains NTH and is rejectedblocker 15:36:06 er 15:36:14 propose #agreed as this affects only more advanced network configuration in certain live environments, where it can be worked around by using the live environment's network configuration tools, #854586 remains NTH and is rejectedblocker 15:36:29 ack 15:36:31 ack 15:36:47 ack 15:37:05 #agreed as this affects only more advanced network configuration in certain live environments, where it can be worked around by using the live environment's network configuration tools, #854586 remains NTH and is rejectedblocker 15:37:38 oh, foo, i don't have tflink's neat script-y thing 15:37:42 one sec, lemme see if i can find it 15:38:47 ha ha. 15:38:49 #topic (855285) "AttributeError: 'module' object has no attribute 'addMacros' 15:38:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=855285 15:38:49 #info Proposed Blockers, MODIFIED 15:39:52 so what does this break? 15:40:07 per the description, "fix livecd-to-iso alpha network usb thumbdrives installs" 15:40:56 but we don't know whether it breaks dd too 15:41:09 yeah 15:41:12 * adamw is asking clumens 15:41:31 * kparal watching 15:42:57 clumens says "should affect all yum-based installs" 15:43:10 assuming 'yum-based install' means 'just about anything', sounds +1 blocker-y to me... 15:43:25 yep 15:43:34 yeah, isn't everything other than preupgrade yum-based? 15:43:46 who knows 15:43:49 hey, you're not here! 15:43:55 nope, not here 15:44:32 * jreznik does not see tflink 15:44:45 propose #agreed #855285 is accepted as a blocker per criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 15:44:56 tflink: do you have a hideous beard and shades? 15:45:22 ack 15:45:27 any installation that uses yum to install packages, not live 15:45:31 adamw: I suppose hideous depends on personal taste, but no shades 15:45:43 why aren't we seeing this outside of USB, though? 15:46:11 if it affects all yum-based installs, shouldn't it be causing more problems for DVD and netinstall? 15:46:30 what i want to know is, why am i debating a figment of my imagination? 15:47:21 adamw: schizofrenia 15:48:00 it just bugs me that this is supposedly affecting only USB installs 15:48:32 unless I'm missing something, the scope of this should be much larger than litd or dd 15:48:58 the code is conditional 15:49:00 tflink: if it's all yum based install and yum based means what clumens told at anaconda, yeah, it should have broader scope 15:49:09 http://www.fpaste.org/NC23/ 15:49:18 perhaps that 'if...else' is only fulfilled in a USB context 15:49:46 if not selinux, hmm 15:50:06 but i really don't want to waste too much time on it... 15:50:11 since it's in 18.6.6 anyhow 15:50:34 yeah, it just bugs me that something checking for readability of a fs would only work on USB 15:50:55 since RO media should still be read-able 15:51:15 clyde kunkel hit it too (dupe) 15:51:20 and clumens seemed happy to pull it 15:51:34 it's a typo fix, though and already in the next build. so like adam said, not worth debating much 15:51:37 ack 15:53:46 one more ack? 15:54:18 you convinced me, ack 15:55:14 #agreed #855285 is accepted as a blocker per criterion "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 15:55:21 are you taking back over, invisible man>? 15:55:30 either way 15:55:44 #topic (854962) Installed system messed up with live stuff 15:55:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=854962 15:55:44 #info Proposed Blocker, ON_QA 15:56:11 it sounds like the issue here is that live install replicates the livecd instead of doing a proper install? 15:56:23 ie, liveuser autologin, no firstboot, anaconda still present 15:56:36 tflink: yep 15:56:49 i included a very thin blocker rationalization in https://bugzilla.redhat.com/show_bug.cgi?id=854962#c12 15:56:54 you can vote +1 if it convinced you =) 15:57:16 I'm OK with blocker on this 15:57:18 +1 15:57:38 adamw: my understanding skills are not good enough to understand it :) but I agree, it's a blocker 15:57:43 +1 15:58:01 it's fixed, just how do we want to pull firstboot into live system/installed live system? 15:58:02 jreznik: there is a special part of my brain labelled 'convoluted blocker justifications' 15:58:24 proposed #agreed 854962 - AcceptedBlocker - Violates the following F18 alpha release criterion for live installs: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user accoun 15:58:28 * jreznik tried to read it several time and gave up :) 15:58:39 proposed #agreed 854962 - AcceptedBlocker - Violates the following F18 alpha release criterion for live installs: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account" 15:59:08 ack 15:59:09 ack 15:59:12 ack 15:59:18 #agreed 854962 - AcceptedBlocker - Violates the following F18 alpha release criterion for live installs: "In most cases, a system installed according to any of the above criteria must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. The firstboot utility must be able to create a working user account" 15:59:28 #topic (855481) Root password is empty after install from live image without completing root pw spoke in anaconda 15:59:31 #link https://bugzilla.redhat.com/show_bug.cgi?id=855481 15:59:33 #info Proposed Blocker, POST 16:00:03 tflink: for previous bug, how do we plan to ship firstboot in live? 16:00:43 jreznik: not sure I follow you - firstboot should be on the lives for install 16:00:45 jreznik: same way we always have, as a package on the live image? 16:00:55 jreznik: it's set up not to run when booting live 16:01:34 * satellit soas live starts firsboot.... 16:02:28 so this is another one which the criteria don't really cover... 16:02:32 tflink: it's not available on tc6 lives, so it's not runned after the bug is fixed... or should the other comps bug fix it? 16:02:41 we don't have a criterion saying 'root should have a password' :) 16:02:55 jreznik: probably the comps thing. you can't rely at all on any tc6 package set. 16:03:08 jreznik: I don't remember where the issue was, but it could be affected by the same thing that wasn't pulling in firstboot earlier 16:03:22 either spin-kickstarts or comps 16:03:49 yep, just raising it as an issue 16:04:04 I did not report bug because of tc6 breakage, to be aware only 16:05:00 let's move on :) 16:05:07 so, what do we want to do with 855481? 16:05:12 it really hits no criteria afaict 16:05:25 we can make it nth 16:05:28 propose a criterion 16:05:40 or take it through the escape hatch 16:06:09 what did we do about root pw for non-live installs? 16:06:31 what do you mean? 16:07:22 didn't we take that as a blocker? 16:07:40 when you couldn't set root pw on the non-live installs (bringing in the root pw spoke) 16:07:57 because it made text installs inaccessible 16:08:04 this doesn't make anything inaccessible, rather the contrary :) 16:08:10 adamw: :) 16:08:19 the result of this bug is a root account you can log into without entering a password 16:08:23 not a root account you can't log into 16:08:30 I could go either way on this one, to be honest 16:08:31 yep, that's the difference 16:08:47 it could be a huge security issue 16:08:47 probably more towards +1 NTH, -1 blocker though 16:08:52 i worry that i'm maybe overcontorting on this one 16:09:11 I can't see blocking release because root pw isn't set on lives 16:09:18 are we trapped so far inside the criteria that we're at a point where anyone else would look at it and say 'well OBVIOUSLY that should be a blocker'? 16:09:19 we should have criteria for this and it should be blocker 16:09:20 release -> alpha release 16:09:24 but now nth is good too 16:10:22 proposed #agreed 855481 - RejectedBlocker, AcceptedNTH - Does not violate any F18 alpha release criterion but a root password set during live install should go through to the installed system 16:10:28 adamw: I'd say anyone else would say it's a blocker :) not a good idea to not be aware that your system has no root password and it's accessible from everywhere 16:10:35 ack, for now 16:10:37 ack 16:10:39 jreznik: yeah, that's what i'm worried about 16:10:54 * kparal reminds we don't have to have criteria to accept something as a blocker. criteria just helps in contentious issues 16:11:22 kparal: well, it needs to hit the criteria or the escape clause 16:11:25 (the one under the criteria) 16:11:57 we have different opinions then 16:12:00 nevermind, ack 16:12:11 #agreed 855481 - RejectedBlocker, AcceptedNTH - Does not violate any F18 alpha release criterion but a root password set during live install should go through to the installed system 16:12:27 #topic (854818) livecd-creator needs secure boot support 16:12:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=854818 16:12:27 #info Proposed Blocker, MODIFIED 16:12:53 -1 blocker, unsure about NTH 16:13:07 this seems like a boarderline bad idea to be pulling in so late 16:13:11 -1 blocker +1 nth 16:13:18 but the traditional installers already support it 16:13:28 parity would be nice 16:13:40 we need to have it included rather sooner than later, so that it can be tested properly 16:13:51 btw, is some SB hardware out there yet? 16:14:09 kparal: it's really hard to get one... but would be great to get some hw for you guys 16:14:35 if there is a possibility someone will test it in Fedora space, having it in Alpha would be nice 16:15:07 yeah, i think the benefit of having it testable in alpha is significant 16:15:18 good point 16:15:20 +1 NTH 16:15:26 pjones: ping, would it be possible to get some sb enabled hw for fedora qa guys? 16:15:45 +1 16:16:15 yep I agree with you, +1 nth as I was the guy who said SB in alpha or not at all :) -1 blocker but +1 nth 16:17:25 proposed #agreed 854818 - RejectedBlocker, AcceptedNTH - While the lack of SB functionality doesn't violate any F18 alpha release criteria, it is a feature of F18 and already present in the non-live installers. SB would be useful to have in alpha for testing and thus thus bug is accepted as NTH for F18 alpha. 16:17:33 ack 16:17:36 jreznik: last time we counted, there were 6 of us in a 5-seat cubicle having 13 computers in total. one more computer is not a big deal :) 16:17:53 ack 16:17:56 jreznik: I don't have any way to get hardware other than just new development machines 16:18:07 (which I can't order so much as just show up sometimes) 16:18:20 the Brno Power Company's best customers 16:18:32 jreznik: though I think there are a couple of machines on the market they could /buy/ at this point 16:18:34 or give a recommendation for hw for qa to obtain it? 16:18:53 btw ack 16:18:59 #agreed 854818 - RejectedBlocker, AcceptedNTH - While the lack of SB functionality doesn't violate any F18 alpha release criteria, it is a feature of F18 and already present in the non-live installers. SB would be useful to have in alpha for testing and thus thus bug is accepted as NTH for F18 alpha. 16:19:11 #topic (855560) F18 KDE Live (alpha TC6) Very high CPU usage under KDE 16:19:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=855560 16:19:11 #info Proposed Blocker, NEW 16:19:47 I' 16:19:51 m not sure this is a blocker 16:19:57 I think this is just the debug kernel 16:20:01 I see it on all my machines 16:20:05 all video drivers 16:20:12 video performance is awful 16:20:22 but still usable 16:20:34 yeah, i'd like more info from the reporter but i'm inclined to -1. 16:20:39 jreznik: pretty much anything that claims it'll be able to run windows 8 /should/ have it, I /think/ 16:20:54 -1 blocker 16:21:28 pjones: ok, kparal do you think you could get some budget? or I can try to ask for some for you :) 16:21:32 proposed #agreed 855560 - RejectedBlocker - This seems to be caused by the debug kernel used until the beta release and thus, not much of a bug. If it turns out to be something other than the debug kernel, please re-propose as a blocker. 16:21:42 ack 16:21:54 ack 16:21:57 * tflink has a machine that should be SB capable 16:22:11 ack 16:22:16 (there is some discrepancy between being windows 8 logoed, which requires sb on by default, and being able to upgrade to windows 8 on the machine) 16:22:19 #agreed 855560 - RejectedBlocker - This seems to be caused by the debug kernel used until the beta release and thus, not much of a bug. If it turns out to be something other than the debug kernel, please re-propose as a blocker. 16:22:44 #topic (855644) F18 KDE Live (alpha TC5) Anaconda custom partition setup: no access to existing LVM/LUKS volumes 16:22:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=855644 16:22:50 #info Proposed Blocker, NEW 16:23:44 we still haven't adjusted Alpha requirements, as pschindl proposed. so we still require LVM and LUKS to work under Alpha 16:23:47 * kparal just reminds 16:24:01 I didn't think that custom partitioning was planned much for alpha 16:24:09 yeah, i mentioned this is another proposed blocker 16:25:02 i think we should probably check with #anaconda if this is feasible 16:25:18 ah, and "existing Linux partitions" is in Alpha criteria too 16:26:09 kparal: frankly i'd rather we don't try to apply that criterion as it stands 16:26:12 it just isn't applicable to newUI 16:26:21 we need to decide where we want to draw the alpha and beta lines for newUI from scratch 16:27:08 ok. the only requirement I have is that anaconda doesn't confuse the user saying it can do something and then perform something completely different. but I don't think it needs to be able to do existing partitions and LVM/LUKS in Alpha 16:28:16 my instinct is also -1, but i'd like to be able to quantify it a bit more... 16:28:18 tflink? 16:29:05 pretty much what kparal said, doesn't need to be there but would be nice if it didn't appear as it should work instead of us saying "well, that isn't working for alpha" 16:30:27 sounds like we have some criteria proposals to do/finish, though 16:31:15 yeah 16:31:45 sounds like we're trending -1 but not convinced of ourselves :) 16:33:02 proposed #agreed 855644 - While this does qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified 16:33:10 it anaconda says "sorry can't do that" it's OK. if it erases the whole disk instead, it not OK 16:33:31 ack 16:33:43 ack 16:33:45 ack 16:33:54 #agreed 855644 - While this does qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified 16:34:08 #topic (855646) F18 KDE Live (alpha TC5) Anaconda custom partition setup: missing volume/device identification 16:34:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=855646 16:34:13 #info Proposed Blocker, NEW 16:35:00 pretty much the same as the last bug, I think 16:35:25 yep 16:35:36 agree 16:36:08 yeah, though i'm more clearly -1 on this one... 16:36:09 #agreed 855646 - While this does qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified. 16:36:15 yay for recycling! 16:36:18 belay that 16:36:34 it's not so clearly a violation of the criteria as the last one 16:36:40 i'd say s/does/may/ 16:37:19 #agreed 855646 - While this may qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified. 16:37:36 alrighty 16:37:44 or we could just reject it, I suppose 16:38:12 meh, we can do it again wed 16:38:15 when there'll be more people 16:38:15 but I'm not clear on how the UI would work if there is no consistency in /dev/ names 16:38:23 k, works for me 16:38:28 it could at least filter out the device you're installing from 16:38:28 ack/nak/patch? 16:38:32 which it ought to do anyhow 16:38:38 er, you did #agreed 16:38:41 not propose #agreed 16:38:47 so we have two agreements now 16:39:20 oh, whoops 16:39:22 #undo 16:39:22 Removing item from minutes: 16:39:24 #undo 16:39:24 Removing item from minutes: 16:39:34 proposed #agreed 855646 - While this may qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified. 16:40:05 ack 16:40:09 ack 16:40:29 moi 16:40:52 vous? 16:41:08 #agreed 855646 - While this may qualify as a blocker according to the F18 alpha release criterion as written at this time, we feel that the blocker criteria should be modified to better reflect what is reasonable to expect from anaconda and this should not be an alpha blocker. Will re-visit once appliciable criteria have been voted on and modified. 16:41:22 #topic (855824) vesa driver is not used on Live 16:41:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=855824 16:41:22 #info Proposed Blocker, NEW 16:42:26 so i suspect what's going on here is that xdriver= isn't being honored 16:42:26 this might end up being a beta blocker 16:42:29 but nomodeset is 16:42:43 in practice nomodeset will ensure vesa is used on just about any bit of real hardware 16:42:47 so i'm -1/-1 16:43:07 are there docs that need to be updated, then? 16:43:11 we can fiddle with the graphics in a KVM in enough other ways that the menu entry being broken isn't a real problem 16:43:16 docs? 16:43:27 test cases for booting into vesa 16:44:13 should we just move this to F18Beta? 16:44:21 tflink: no, the test case is correct 16:44:34 adamw: well it could mention the VM case 16:44:35 brb, call of nature 16:44:51 nah, i wouldn't want to change the test fase 16:44:52 case 16:44:58 proposed #agreed 855824 - RejectedBlocker - 'nomodeset' should be working in place of vesa and when booting into a vm, the device type can be changed as an easy workaround in place of booting w/ vesa driver. Since this isn't a direct violation of F18 alpha release criteria and there are easy workarounds - rejected as blocker for F18 alpha 16:45:01 the test case is correct and the menu entry *ought* to work in KVMs 16:45:06 ack/nak/patch? 16:45:08 nack 16:45:16 the fact that it doesn't is a genuine bug 16:45:20 i just don't think it's an important one 16:45:30 ok 16:45:32 tflink: the menu entry in question passes the parameters 'nomodeset xdriver=vesa' 16:45:45 i think the bug here is that nothing's honoring the 'xdriver=vesa' part of that 16:46:03 but in practice, on almost everything except a KVM, the 'nomodeset' part, these days, will result in the vesa driver being used anyway 16:46:18 seems like it works on real hw 16:46:18 so should I re-propose this for later milestones or not? 16:46:31 Back In The Day it wouldn't have done, as the native drivers still had UMS code. but nowadays, for all common hardware, the drivers don't have UMS code, so when 'nomodeset' is passed, X winds up falling back to vesa 16:46:49 kparal: up to you. i'd vote -1 at any point, assuming my understanding above is correct, but that's just one vote :) 16:47:18 proposed #agreed 855824 - RejectedBlocker - While there is a bug here, it only affects VMs. Since using 'nomodeset' is a possible workaround for either bare metal or VMs and when booting into a VM, the device type can be changed - there are easy workarounds in place of booting w/ vesa driver specified. Since this isn't a direct violation of F18 alpha release criteria and there are easy workarounds - rejected as blocker for F18 alpha 16:47:31 ack 16:47:45 ack 16:49:05 #agreed 855824 - RejectedBlocker - While there is a bug here, it only affects VMs. Since using 'nomodeset' is a possible workaround for either bare metal or VMs and when booting into a VM, the device type can be changed - there are easy workarounds in place of booting w/ vesa driver specified. Since this isn't a direct violation of F18 alpha release criteria and there are easy workarounds - rejected as blocker for F18 alpha 16:49:11 #topic (855784) packagekit waits for authentication 16:49:14 #link https://bugzilla.redhat.com/show_bug.cgi?id=855784 16:49:16 #info Proposed Blocker, NEW 16:49:59 this will require multiple people to re-verify 16:50:27 it works for jreznik in a clean installation. I have upgraded system (since TC4 or so) and it doesn't 16:50:34 yeah, sounds like a punt for now while waiting for more testing/workarounds/verification 16:50:52 yep, clean installation of live + latest packagekit = works for me 16:51:24 jreznik: how do you install Live when it fails to boot on missing initrd? 16:51:47 kparal: it works in kvm 16:51:48 proposed #agreed 855784 - This may not affect new installs and may have other workarounds. Needs more testing and/or reproduction before making a decision on blocker status for F18 alpha - will revisit. 16:52:12 jreznik: interesting 16:53:11 this is a kind of follow-on from https://bugzilla.redhat.com/show_bug.cgi?id=854209 ? 16:53:23 ack, anyhow 16:53:26 adamw: yes 16:53:45 any other ack/nak/patch? 16:54:17 adamw: that's different but it could be related to policy kit selinux one 16:54:22 as it's tc4 updated... 16:54:44 ack 16:55:04 #agreed 855784 - This may not affect new installs and may have other workarounds. Needs more testing and/or reproduction before making a decision on blocker status for F18 alpha - will revisit. 16:55:11 OK, that's all of the proposed blockers 16:55:34 any objections to skipping the accepted blockers and just doing the proposed NTHs? 16:55:43 +1 16:56:07 +1 16:56:36 OK, 2 +1s -> objections -> time to go through all of the accepted blockers :-P 16:56:42 * tflink is joking 16:56:52 #topic (852792) [Configure] button in network spoke doesn't work (nm-c-e fails to run) 16:56:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=852792 16:56:58 #info Proposed NTH, ASSIGNED 16:58:02 wow, going back and forth between the blocker page mockups and the currently active page is really jarring 17:00:04 well, this seems confused as hell. 17:01:47 it sounds to me like c#12 might be a different bug 17:02:47 yeah 17:02:55 i think i might be able to test this out locally 17:03:01 and provide better info to re-vote later 17:03:11 but I'm OK with the original bug being NTH, assuming that I understand what's going on 17:03:14 works for me 17:03:37 if this is truly why the 'configure' button in liveinst does nothing in the GNOME spin, then yeah, probably +1 17:04:01 proposed #agreed 852792 - There seems to be quite a bit of confusion in the bug about what exactly is going on here - will revisit once the issue is clarified and re-tested 17:04:08 this is only lives? 17:04:38 nvm, just potentially related 17:04:43 ack/nak/patch? 17:05:39 ack 17:06:06 looks like we may have lost almost everyone else 17:06:20 how could they possibly leave when we're having so much fun?! 17:06:22 * jreznik is still here 17:06:44 i'd like to get at least the next two proposed nth accepted 17:06:50 they're pretty important for non-blocking spins 17:06:55 * tflink plays jeopordy music in the bkground 17:07:23 time's up 17:07:32 #agreed 852792 - There seems to be quite a bit of confusion in the bug about what exactly is going on here - will revisit once the issue is clarified and re-tested 17:07:43 #topic (855465) osmo depends on libsyncml, which currently cannot be installed (f18/rawhide) 17:07:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=855465 17:07:48 #info Proposed NTH, ON_QA 17:08:03 +1 NTH 17:08:04 +1 nth, fixed, karma +1 from me 17:08:31 +1 17:08:33 +1 nth 17:08:34 simples! 17:09:14 proposed #agreed 855465 - AcceptedNTH - Prevents creation of LXDE spin which becomes NTH as LXDE is a secondary DE. 17:09:30 ack/nak/patch? 17:10:02 ack 17:10:12 ack 17:10:19 ack 17:10:20 #agreed 855465 - AcceptedNTH - Prevents creation of LXDE spin which becomes NTH as LXDE is a secondary DE. 17:10:25 #topic (855470) lxdm should ship a systemd preset to ensure it's enabled after install 17:10:28 #link https://bugzilla.redhat.com/show_bug.cgi?id=855470 17:10:31 #info Proposed NTH, NEW 17:10:57 proposed #agreed 855465 - AcceptedNTH - Prevents booting of LXDE spin after installation from livecd which becomes NTH as LXDE is a secondary DE. 17:11:07 er, that's not quite right 17:12:34 proposed #agreed 855465 - AcceptedNTH - Prevents booting of graphical DM for LXDE spin after installation from livecd - since violations of F18 release criteria for secondary DEs are NTH by definition. 17:12:41 damnation, I did it again 17:12:52 proposed #agreed 855470 - AcceptedNTH - Prevents booting of graphical DM for LXDE spin after installation from livecd - since violations of F18 release criteria for secondary DEs are NTH by definition. 17:12:59 third time's the charm, I suppose 17:13:04 or the hazards of recycling 17:13:13 can I ack now? 17:13:19 is it safe? 17:13:28 it's never safe ... 17:13:35 * tflink looks around, all paranoid 17:13:47 ack 17:13:53 ack 17:13:54 ack 17:14:02 #agreed 855470 - AcceptedNTH - Prevents booting of graphical DM for LXDE spin after installation from livecd - since violations of F18 release criteria for secondary DEs are NTH by definition. 17:14:12 #topic (855510) TC5: Cannot get past "Booting in ...... in 0 seconds" screen on iMac 2011 (booting from USB) 17:14:15 #link https://bugzilla.redhat.com/show_bug.cgi?id=855510 17:14:17 #info Proposed NTH, NEW 17:14:50 does this qualify for alpha? 17:15:15 either way, needs more info 17:15:31 USB creation method, mostly 17:15:32 we can test Mac Mini if it helps 17:15:44 TC5 was before some EFI fixes 17:16:01 anyway, yeah, needslotsofinfo 17:16:59 let's give action item to jskladan, he has the Mac on his desk ;-) 17:17:00 proposed #agreed 855510 - This needs much more information before making a decision on NTH - method used for creating the USB stick for one. There have also been EFI related fixes since TC5, retesting with a >= TC6 would also be helpful. 17:17:20 * kparal loves proposing action items for other people 17:17:32 kparal: i se what you did there :) 17:17:45 #action kparal to propose action item to get jskladan to do kparal's work for him 17:17:49 jskladan: you want to play with the Mac anyway, I know you 17:18:02 aaaaw, that's true :) 17:18:10 he accepted! 17:18:27 anyhow, any ack/nak/patch so we can be done with this meeting? 17:18:36 ack 17:18:51 #undo 17:18:51 Removing item from minutes: 17:19:04 patch: for 30% of his salary ;) 17:19:07 ack 17:19:25 #agreed 855510 - This needs much more information before making a decision on NTH - method used for creating the USB stick for one. There have also been EFI related fixes since TC5, retesting with a >= TC6 would also be helpful. 17:19:36 last proposed NTH ... 17:19:39 #topic (855477) Many icons missing when running anaconda within a live Xfce image 17:19:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=855477 17:19:45 #info Proposed NTH, NEW 17:20:01 +1 NTH 17:20:16 nice pictures 17:20:20 +1 nth 17:20:45 it's just cosmetic ;) 17:20:50 proposed #agreed 855477 - AcceptedNTH - While the installer is still usable in XFCE, it looks terrible and looks broken. XFCE is a non-primary DE and thus, this is not a blocker. 17:21:01 ack/nak/patch? 17:21:06 fwiw this may be an xfce bug not anaconda 17:21:11 note all the missing icons in the xfce tray 17:21:15 but hey, i'd be +1 nth either way 17:21:21 huh. 17:21:28 I didn't see any of that on the last nightly I tried. 17:21:40 ack 17:21:56 * nirik can test again with todays. Recent ones had gdm in them 17:22:09 other ack/nak/patch? 17:22:11 nirik: yeah, it may depend on exactly waht comps i got 17:23:34 * tflink reaches for the spiky 2x4 of timely voting "encouragement" 17:23:47 ack 17:24:02 #agreed 855477 - AcceptedNTH - While the installer is still usable in XFCE, it looks terrible and looks broken. XFCE is a non-primary DE and thus, this is not a blocker. 17:24:14 OK, that would be all of the proposed blockers and NTH on my list 17:24:32 and since we seem to have lost most interest, I do believe that we're done with the "mini" blocker review 17:24:45 "mini" :) 17:25:29 whew 17:25:32 thanks tflink 17:25:44 i propose we just end this meeting here, since we've lost a lot of people 17:25:53 i don't see any value in discussing criteria changes with this few bodies 17:26:05 let's do this just in case.... 17:26:09 agreed 17:26:18 * kparal sees corpses all around... 17:26:21 #info release criteria topic is postponed due to length of previous segment and lack of people 17:26:24 #topic open floor 17:26:26 anyone for open floor? 17:26:42 * jreznik is corpse now... 17:26:59 * tflink will have a new draft of the blocker tracking page to send out (hopefully) soon 17:27:08 looks lots different from the previous versions 17:27:25 what bits we currently miss for rc? 17:28:30 jreznik: a new anaconda build is all really 17:28:45 though we might need to do something about partitioning 17:30:58 * adamw sets fuse for 3 mins 17:31:42 adamw: I see icons fine in todays nightly xfce... 17:31:53 so might have been some comps issue or something. 17:31:55 do nightlies use updates-testing? 17:33:15 no 17:33:32 probably comps then yeah. 17:33:37 we'll see what tc7/rc1 spits out. 17:33:49 * nirik nods 17:36:26 okay! 17:36:33 let's get back to something vaguely resembling work 17:36:36 thanks for coming all 17:36:38 #endmeeting