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