17:03:19 <tflink> #startmeeting f18beta-blocker-review-7
17:03:19 <zodbot> Meeting started Wed Nov  7 17:03:19 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:19 <tflink> #meetingname f18beta-blocker-review-7
17:03:19 <zodbot> The meeting name has been set to 'f18beta-blocker-review-7'
17:03:24 <tflink> #topic Roll Call
17:03:28 * kparal here
17:03:30 <jreznik> kparal: so you changed UTC :)
17:03:31 * pschindl is here
17:03:32 * jreznik is here
17:03:37 * nirik is lurking
17:04:22 <tflink> wow, that was quick :)
17:04:57 * Cerlyn is here
17:05:25 <tflink> I believe that we have enough to get started
17:05:35 <tflink> anyone want to volunteer to play secretary?
17:06:00 * jreznik can't today, multitasking two meetings :(
17:07:02 <kparal> I can try. I should just add comments to bugzilla, right?
17:07:03 * adamw is here, just got out of the shower
17:07:18 <tflink> kparal: yeah, that and change bug status as needed
17:07:36 <kparal> well, if adamw is here, I'll gladly give up this priviledge :)
17:07:44 <tflink> either way :)
17:08:00 * kparal spells privilege properly
17:08:06 <adamw> eh, sure, i'll do it.
17:09:13 * satellit listening
17:09:28 <tflink> ok, boilerplate time
17:09:34 <tflink> #topic Introduction
17:09:43 <tflink> Why are we here?
17:09:43 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
17:09:50 <tflink> #info We'll be following the process outlined at:
17:09:50 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:09:56 <tflink> #info The bugs up for review today are available at:
17:09:56 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
17:10:03 <tflink> #info The criteria for release blocking bugs can be found at:
17:10:03 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
17:10:04 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
17:10:04 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
17:10:16 <tflink> Up for review today, we have:
17:10:19 <tflink> #info 5 Proposed Blockers
17:10:19 <tflink> #info 11 Accepted Blockers
17:10:19 <tflink> #info 3 Proposed NTH
17:10:19 <tflink> #info 40 Accepted NTH
17:10:37 <tflink> wow, that's a lot of accepted nth
17:10:54 <tflink> any objections to starting with the proposed Blockers?
17:11:03 <jreznik> no objection, go on
17:11:21 <tflink> #topic (873224) TypeError: cannot concatenate 'str' and 'NoneType' objects
17:11:21 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873224
17:11:21 <tflink> #info Proposed Blocker, anaconda, NEW
17:12:44 <jreznik> seems like -1 beta blocker but for final - not to blow up
17:12:45 <tflink> it sounds like this is an issue with anaconda blowing up if a degraded RAID array is encountered
17:13:34 <kparal> it is quite similar to my case of incomplete LVM
17:13:45 <kparal> we decided +1 Beta NTH, +1 Blocker Final, IIRC
17:14:01 <tflink> that works for me
17:14:15 <jreznik> same for me
17:14:32 <kparal> let's propose
17:15:00 <adamw> +1 to that
17:15:08 <adamw> actually
17:15:13 <adamw> -1 to that. not nth. not now. too late.
17:15:21 <tflink> kparal: do you recall which criterion was used?
17:15:32 <adamw> we really need to start focusing on blockers at some point.
17:15:46 <jreznik> adamw: +1 nth to be consistent with lvm but you're right
17:15:54 <kparal> tflink: 869185
17:17:07 <tflink> proposed #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the following F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the
17:17:14 <adamw> ack
17:17:32 <jreznik> ack
17:17:35 <kparal> of the <cut>
17:17:41 <kparal> ack
17:18:13 <tflink> proposed #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:18:31 * tflink really needs to figure out a better way of doing this, the trial and error is no good
17:18:46 <tflink> either that or figure out how to get the max length increased
17:18:53 <tflink> #agreed 873224 - RejectedBlocker (beta), AcceptedBlocker (final) - While anaconda doesn't support degraded RAID arrays, it shouldn't crash when one is encountered and is a conditional violation of the F18 final release criterion: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above"
17:18:59 <tflink> #topic (868535) AttributeError: 'NoneType' object has no attribute 'get'
17:19:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868535
17:19:04 <tflink> #info Proposed Blocker, anaconda, VERIFIED
17:19:59 <tflink> damnation, this is verified
17:20:03 <tflink> #undo
17:20:03 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x16015210>
17:20:04 <tflink> #undo
17:20:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x16015110>
17:20:06 <tflink> #undo
17:20:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1f002510>
17:20:15 <tflink> #topic (873459) Upgraded system does not reboot if a kernel upgrade is part of the upgrade
17:20:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873459
17:20:20 <tflink> #info Proposed Blocker, fedup-dracut, NEW
17:20:23 <kparal> well verified but not accepted
17:20:24 <tflink> this one. fun times
17:20:28 <tflink> kparal: it's NTH
17:20:40 <kparal> tflink: ah
17:20:43 <tflink> we can go over it as a blocker but I figured it didn't matter a whole lot
17:20:52 <kparal> ok
17:20:55 <jreznik> tflink: reason?
17:21:06 <Viking-Ice> hm was that an nth when the installer did not reboot?
17:21:06 <tflink> jreznik: reason for ...?
17:21:20 <jreznik> tflink: you mean for the previous undo bug, I get it now
17:21:41 <tflink> I can go back if anyone wants to
17:21:57 <kparal> no it's fine
17:22:12 <jreznik> to clean the list but...
17:22:18 <jreznik> clean up
17:22:22 <tflink> ok, back to the fedup funtime broken rebooted system bug
17:22:42 <tflink> basically, there are issues with fedup that are most prominent when a kernel upgrade is involved
17:23:00 <adamw> do we know where the fix for this is going to come next?
17:23:06 <tflink> I have yet to see an upgrade w/ kernel update that didn't end in a non-bootable system
17:23:16 <Viking-Ice> thats a blocker right
17:23:41 <tflink> I'm seeing other issues with a bare-metal upgrade and kvm/qemu that might be related but I'm not certain of that
17:23:44 <kparal> mkrizek reported today he managed to successfully upgrade F17
17:24:19 <Viking-Ice> +1 blocker
17:24:25 <tflink> if you don't get a kernel upgrade (which you won't right now if you don't specify a side repo or updates-testing during upgrade), you won't hit the most obvious symptoms of this
17:24:36 <kparal> upgrade broken, +1 blocker
17:25:09 <jreznik> +1 blocker
17:25:12 <adamw> yeah, we can hardly rely on not getting a kernel upgrade
17:25:24 <adamw> +1 blocker on the face of it, my only question is the usual one with fedup, do we need to fix this in the frozen packages.
17:25:27 <jreznik> do we have a test matrice for upgrades?
17:25:28 <adamw> which never seems to get a clear answer :)
17:25:36 <adamw> jreznik: it's at the bottom of the install matrix.
17:25:53 <tflink> adamw: it depends on what we end up doing for the upgrade initramfs
17:25:58 * nirik is also +1 blocker... no idea where the problem is tho
17:26:00 <tflink> which I still don't have a clear answer on
17:26:09 <kparal> jreznik: we don't have a test case yet
17:26:22 * tflink is working on a test plan and test cases
17:26:42 <jreznik> kparal: would be great to have one, so we will be able to track success rate
17:26:48 <kparal> adamw: it's not there, we commented out preupgrade test cases
17:26:54 <kparal> (and anaconda ones)
17:27:11 <tflink> the last time I talked to will about it, he was looking into including the upgrade bits in the regular installer initramfs but was hitting problems with lvm being disabled
17:27:21 <kparal> jreznik: once it doesn't require black magic, we can write a test case :)
17:27:30 <adamw> kparal: oh, well we can uncomment them again at some point.
17:27:41 <tflink> the last I heard, we might get a separate initramfs for upgrade generated by lorax but I have no idea about that status
17:27:42 <kparal> adamw: but they are still obsolete
17:27:55 <tflink> like I said, I'm working on the test cases
17:27:59 <adamw> tflink: but this is related to the stuff in the initramfs either way?
17:28:06 <tflink> adamw: yes
17:28:26 <tflink> without question, this is an issue with stuff that is in the initramfs and not part of the stuff that's in F17
17:28:44 <adamw> then +1 blocker for sure
17:28:51 <tflink> but like kparal said, I'd rather have less black magic and hacky-ness before we turn everyone loose on fedup testing
17:29:41 <Viking-Ice> I think this one is agreed
17:29:41 <tflink> I'm keeping track of the worst bugs and current process here: https://fedoraproject.org/wiki/QA:Fedora_18_Upgrade_Testing
17:29:50 <adamw> Viking-Ice: yeah
17:29:53 <tflink> I can only do one thing at a time
17:30:52 <Viking-Ice> should not that info be in a fedup testday
17:31:01 <tflink> proposed #agreed 873459 - AcceptedBlocker - This is a violation of the following F18 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:31:07 <Viking-Ice> ack
17:31:08 <kparal> ack
17:31:22 <adamw> ack
17:31:25 <tflink> why is it that I get poked when I'm not fast enough but nobody else is bothered when there are delays in votes or acks?
17:31:32 <tflink> #agreed 873459 - AcceptedBlocker - This is a violation of the following F18 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:31:35 <adamw> eh? no-one's poking anyone
17:31:43 <tflink> Viking-Ice: fedup test day?
17:31:54 <Viking-Ice> yeah that wiki page
17:32:06 <tflink> which information, it should be pretty up to date
17:32:22 <Viking-Ice> btw we usally did create a wikipage on our own wiki namespace then move it to the official one once accepted
17:32:31 <Viking-Ice> https://fedoraproject.org/wiki/QA:Fedora_18_Upgrade_Testing
17:32:39 <tflink> if it's missing something, let me know. I can take a look at it after the meeting
17:33:00 <tflink> Viking-Ice: I was more interested in getting everything written down at the time
17:33:10 <tflink> if I messed up the wiki policy, I apologize
17:33:22 <tflink> #topic (873576) parted hangs trying to inspect newly-created Intel fwraid RAID-1 array
17:33:25 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873576
17:33:28 <tflink> #info Proposed Blocker, kernel, NEW
17:33:36 <kparal> Viking-Ice: that's needless bureaucracy, especially in this case
17:34:13 <Viking-Ice> let's move on I'm not in the mood of yet another things you red hatters thing is needless
17:34:13 <adamw> tflink: there's no policy i'm aware of. it's fine to just create a page on the wiki to provide information on something. we have all kinds of random pages like that.
17:34:54 <Viking-Ice> adamw, I guess you had not started when we where working like that then
17:35:28 <adamw> Viking-Ice: do you have to be so negative? tflink was working on testing fedup so he created a page to share his knowledge.
17:35:35 <Viking-Ice> allthou I think I recollect you fixing my spelling few times before moving it under the official one but I might be confusing you for James
17:35:53 <adamw> being overly negative about that isn't going to encourage tim to create a 'proper' page in future, it'll just encourage him not to create anything at all.
17:36:03 <adamw> because then you won't have anything to complain about.
17:36:21 <Viking-Ice> adamw, I only pointed out that we usually created that page under our own namespace before moving it under the official one
17:36:42 <Viking-Ice> in any case let's move on
17:36:51 <kparal> Viking-Ice: we waste most of the time talking to you when you complain about _anything that happens_
17:36:53 <tflink> yes, lets
17:37:20 <kparal> so let's keep that at least outside of the meeting
17:37:21 <tflink> we can debate wiki policy and namin later
17:37:27 <tflink> let's get through the blockers
17:38:04 <adamw> Viking-Ice: oh, sorry, i missed the part about namespace drafts, i thought we were still talking about a test day.
17:38:30 <adamw> so i would like it if someone else could try and reproduce this, but finding people with intel fwraid when you want to always seems oddly hard.
17:38:53 <tflink> I can try. my box with intel fwraid was being used for fedup testing until this morning
17:39:12 <tflink> it took a while to dig that upgrade out of non-bootable hell :)
17:39:16 <adamw> ah, mkovarik reproduced at least
17:39:31 <kparal> yep, just typing that
17:39:47 <Viking-Ice> +1 blocker
17:39:56 <adamw> so i'm more comfortable about making this a blocker
17:40:29 <adamw> conditional violation of "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " , in the case of Intel fw RAID-1 or RAID-5.
17:40:38 <adamw> raid-0 works, but that's hardly an alternative :)
17:40:55 <jreznik> it affects also raid-5
17:40:58 <tflink> proposed #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1: "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:40:59 <jreznik> that dupe
17:41:01 <adamw> yeah, i wrote that.
17:41:05 <Viking-Ice> ack
17:41:07 <CRCinAU> adamw: I use RAID0 for ALL my backups ;)
17:41:10 <adamw> ack (or add raid5)
17:41:11 <pschindl> ack
17:41:13 <kparal> ack
17:41:15 <tflink> proposed #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1/RAID5: "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:41:15 <adamw> CRCinAU: :P
17:41:19 <tflink> missed the RAID5 part
17:41:29 <kparal> consider acked
17:41:35 <tflink> #agreed 873576 - AcceptedBlocker - Violates the following F18 beta release criterion for Intel FW RAID1/RAID5: "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:41:40 <jreznik> Jes is in Barcelona, LinuxCon, he can take a look on Friday
17:41:50 <tflink> #topic (844167) Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
17:41:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=844167
17:41:56 <tflink> #info Proposed Blocker, selinux-policy, MODIFIED
17:42:11 <tflink> this one, again :)
17:42:19 <Viking-Ice> yeah that punter
17:42:30 <adamw> did you manage to figure out whether it affects fedup yet?
17:42:31 <tflink> I finally got this tested with fedup
17:42:34 <adamw> or still blocked on that?
17:42:35 <adamw> yay!
17:42:36 <tflink> I don't think so, no
17:42:55 <tflink> I'm seeing other issues with the VM but I don't think it's related to this bug
17:43:12 <tflink> the VM starts and suddenly kills due to qemu errors
17:44:13 <adamw> i think if you hit this bug the system will start up at least
17:44:29 <tflink> error: qemuMontiroIO:606 : internal error End of file from monitor
17:44:30 <adamw> but you might not be able to log in via gdm, and a few other things are screwy. but you do get a booted system.
17:45:07 <adamw> if you have enough time when the system starts up, you could check if the 'polkitd' user exists.
17:45:19 <tflink> there is a crash but abrt hit problems and didn't finish collecting the crash
17:45:38 <tflink> after much coaxing, the upgraded virthost does boot
17:45:53 <tflink> the shutdown I'm talking about is in the VM on the upgraded virthost
17:46:16 <adamw> oh, i see.
17:46:26 <tflink> both qemu and polkitd users exist
17:46:53 <tflink> I think this is either fixed or didn't affect fedup
17:48:13 <tflink> but there are still quite a few workarounds needed to get a working upgraded system
17:48:42 <tflink> including an extra one on this upgrade that I want to reproduce before filing
17:49:01 <adamw> okay, but it sounds like we can take this particular bug out of blocker consideration. finally.
17:49:05 <adamw> -1 blocker!
17:49:21 <Viking-Ice> -1 blocker throw it in the trash
17:49:32 <Viking-Ice> and let's hope it does not resurface ;)
17:50:03 <adamw> amen
17:50:04 <tflink> proposed #agreed 844167 - RejectedBlocker - After testing with fedup, this either appears to not affect that process or has been fixed in selinux-policy. Thus, rejecting as a blocker for F18 beta.
17:50:11 <adamw> ack
17:50:12 <pschindl> ack
17:50:13 <kparal> ack
17:50:19 <tflink> #agreed 844167 - RejectedBlocker - After testing with fedup, this either appears to not affect that process or has been fixed in selinux-policy. Thus, rejecting as a blocker for F18 beta.
17:50:36 <tflink> alrighty, I think that's all of the proposed blockers
17:50:55 * kparal likes
17:51:09 <tflink> time for some proposed NTH
17:51:14 <tflink> #topic (873865) langsupport groups not getting added
17:51:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873865
17:51:14 <tflink> #info Proposed NTH, anaconda, POST
17:52:26 <kparal> I think mkrizek reported he received F18 KDE without all necessary language packs
17:52:37 <tflink> I thought that we already had an NTH for this
17:52:40 <kparal> and he had to install them manually
17:53:13 <kparal> tflink: maybe 868869?
17:53:15 <adamw> tflink: this is a different but similar bug
17:54:11 * tflink is probably OK with this as NTH
17:54:21 <kparal> I don't really know what is the difference between the two, but missing fonts can be very problematic
17:54:23 <tflink> it sounds like the change is minimal
17:55:02 <kparal> +1 nth
17:55:10 <Viking-Ice> +1 nth
17:55:53 <tflink> proposed #agreed 873865 - AcceptedNTH - While not a blocker, it would be good to have all the needed fonts for non-english installs.
17:56:09 <kparal> ack
17:56:18 <adamw> ack
17:56:21 <pschindl> ack
17:56:32 <tflink> #agreed 873865 - AcceptedNTH - While not a blocker, it would be good to have all the needed fonts for non-english installs.
17:56:41 <tflink> #topic (872989) gnome-screenshot does not work in fallback mode
17:56:41 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872989
17:56:41 <tflink> #info Proposed NTH, cairo, ON_QA
17:57:24 <tflink> not so sure about taking a cairo fix this close to release
17:57:44 <Viking-Ice> me neither
17:57:51 * tflink is leaning towards -1 NTH since this only shows up in fallback mode
17:58:00 <tflink> most people should be able to run shell, even in VMs
17:58:24 <tflink> other thoughts?
17:58:26 <kparal> but some graphics adapter issues might trigger fallback mode, and you may want to screenshot them
17:58:31 <kparal> this is tricky
17:59:12 <kparal> other tools are working, like ksnapshot
17:59:14 <Viking-Ice> -1 nth
17:59:31 <Viking-Ice> fallback mode is supposed to be deprecated anyway right
17:59:34 <Viking-Ice> with 3.6
17:59:41 <tflink> true but is the subset of users that are 1) running livemedia and 2) running a system that gets them into fallback mode. enough to justify taking a cairo fix this late?
17:59:51 <kparal> is it used in safe graphics mode I believe
18:00:03 <adamw> no
18:00:09 <adamw> you'd get software rendered shell in that case
18:00:17 <kparal> ok, that's good
18:00:21 <adamw> aiui the only case where you get fallback mode any more is when you have a blacklisted adapter
18:00:30 <adamw> since we still haven't fixed it so that blacklisted adapters go to llvmpipe
18:00:31 <kparal> I would rather not take cairo update then
18:01:36 <tflink> proposed #agreed 872989 - RejectedNTH - While a potential issue, the only way that this can be hit is if you're running livemedia on a blacklisted adapter. This doesn't seem as if it would affect enough users to justify taking a cairo fix this late in beta.
18:01:47 <pschindl> akc
18:01:48 <adamw> ack
18:01:49 <pschindl> *ack
18:01:58 <kparal> ack
18:02:00 <tflink> #agreed 872989 - RejectedNTH - While a potential issue, the only way that this can be hit is if you're running livemedia on a blacklisted adapter. This doesn't seem as if it would affect enough users to justify taking a cairo fix this late in beta.
18:02:09 <tflink> #topic (873342) RuntimeError: no window manager available
18:02:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873342
18:02:09 <tflink> #info Proposed NTH, firstboot, ON_QA
18:03:15 <tflink> there is already one +1 NTH from the comments
18:03:35 <tflink> I'm +1 NTH as well, it breaks MATE installs and MATE is a non-release-blocking DE
18:03:46 <kparal> adamw: I don't get comment 17
18:04:01 <adamw> msivak updated firstboot, and dan updated mate-window-manager
18:04:05 <kparal> aha
18:04:13 <adamw> it seems like they both need updating to fix the bug, or something.
18:04:25 <adamw> oh, it was leigh, not dan.
18:04:31 * nirik notes fesco meeting in #fedora-meeting for anyone from qa that wants to provide input
18:04:38 <tflink> proposed #agreed 873342 - AcceptedNTH - This breaks MATE installs and as a non-release-blocking DE, this is NTH. A tested fix would be accepted past freeze.
18:04:43 <adamw> the mate-w-m update adds "Provides: firstboot(windowmanager)"
18:04:46 <Viking-Ice> ack
18:04:47 <adamw> ack
18:04:57 <kparal> ack
18:05:18 <Viking-Ice> is anyone actually maintaining mate btw?
18:05:52 <kparal> people seem to be active around mate
18:05:57 <kparal> I don't remember any names
18:06:20 <adamw> leigh and dan, i thought.
18:06:31 <adamw> yeah, search 'mate' in bodhi and you get plenty of packages from those two.
18:06:49 <adamw> Viking-Ice: if you mean upstream, i think the answer is 'yes, but there is lots of scepticism about whether they have the expertise to keep it going long term'.
18:07:07 <Viking-Ice> yeah I was thinking upstream
18:07:18 <adamw> i don't really have the details but right now i think it's been mostly a '
18:07:22 <adamw> 'run sed on the entire codebase' deal
18:07:34 <Viking-Ice> I thought Gnome and most other DE developers gave a big fat warning doing things this way
18:07:41 <adamw> i'm not sure they have the expert coders to be able to deal with stuff like consolekit->systemd migration and so on
18:07:48 <adamw> but i guess time will tell.
18:08:27 <jlk> adamw: ok, the fix for 873865 just went into master upstream.  Would like to get it into the beta to avoid bugs about odd missing packages in non-english installs.
18:08:29 <Viking-Ice> dont tell me fesco did not make that an absolute requirement before acceptance <sigh>
18:08:44 <jlk> adamw: worst it can do is add a few extra packages to some installs
18:09:23 <adamw> jlk: we're doing NTH review now, actually.
18:09:29 <adamw> tflink: are you pausing the meeting for fesco?
18:09:30 <kparal> jlk: we accepted that as NTH
18:09:42 <jlk> oh, awesome.
18:09:46 <tflink> sorry, trying to do two things at the same time
18:09:58 <tflink> #agreed 873342 - AcceptedNTH - This breaks MATE installs and as a non-release-blocking DE, this is NTH. A tested fix would be accepted past freeze.
18:11:18 <adamw> jlk: just did the bureaucracy on it.
18:11:28 <jlk> just pushed it :)
18:11:40 <jlk> I'll join in for the bug review.
18:13:03 <kparal> jlk: the meeting is now a bit paused because of fesco discussion in #fedora-meeting
18:13:13 <jlk> gotcha
18:26:03 * adamw munches popcorn
18:26:13 <adamw> this is like american politics. terrifying yet fascinating.
18:28:59 <Viking-Ice> not really
18:29:19 <Viking-Ice> they should lift the freeze set date and stop worrying about holidays
18:30:55 <Viking-Ice> jlk, how diverged has the code between beta and final become in anaconda?
18:31:38 <Viking-Ice> is it not better to lift freeze and slip few weeks and pull those changes in and iron out the remaining issue once that has been done?
18:33:51 <jlk> Viking-Ice: hard to say, not super diverged.
18:34:50 <Viking-Ice> we would be better of with an unfreeze and an pull and freeze again at later date then freeze slip week at a time
18:35:53 <jlk> I agree.
18:45:18 <adamw> yeah, like i said in the meeting, i don't think unfreezing is going to bring in any massive regressions to the TCs/RCs.
18:49:55 <rishi> adamw: ping
18:50:41 <adamw> rishi: yo.
18:50:46 <adamw> did you catch that link earlier?
18:50:54 <rishi> adamw: No.
18:51:14 <adamw> rishi: https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation
18:52:45 <kparal> adamw: ah, so that' the page. it's kinda hard to find it just by following links from QA page
18:52:53 <adamw> yeah, it kinda is
18:53:23 <kparal> adamw: ideally we could link it from Bodhi
18:53:26 <adamw> the short version is, 'add the test case to Category:Package_(packagename)_test_cases'
18:53:34 <adamw> kparal: sure, ask luke
18:54:44 <rishi> adamw: Cool.
18:55:04 <adamw> rishi: the mechanism is simple, explaining/promoting it turned out not to be :( at least to me
18:55:05 <kparal> tflink: should we end the meeting or will we continue it?
18:55:06 <adamw> improvements welcome...
18:55:14 <rishi> Looking at http://fedoraproject.org/wiki/Category:Package_yum_test_cases as an example
18:55:17 <adamw> yeah i think we may as well continue, not sure we can provide much more input to fesco...
18:55:38 <tflink> kparal: we're done with all the proposed bugs
18:55:51 <tflink> if we're going to unfreeze, there is little point of reviewing the accepted blockers
18:56:39 <kparal> open floor then?
18:56:47 <adamw> oh, we finished proposed nth?
18:56:52 <adamw> tflink: why?
18:57:00 <adamw> we still need to work on fixing blockers whether we're frozen or not...
18:57:34 <tflink> adamw: good point
18:57:50 <adamw> what the freeze affects is mainly nth
18:57:50 <tflink> either way, let's wait until this part of the fesco meeting is done
18:57:59 <adamw> when we're unfrozen there's not much point worrying about nth
18:58:06 <adamw> but it's always worth worrying about blockers
18:59:57 <rishi> Why does https://fedoraproject.org/wiki/Category:Package_gnome-shell_test_cases have all these non-gnome-shell components? Is it meant to cover entire GNOME?
19:00:23 <Martix> rishi: I can fix that
19:01:28 <rishi> Martix: I created a new Category:Package_gnome-online-accounts_test_cases
19:01:30 <rishi> Is that ok?
19:01:48 <rishi> Shall I go ahead and create one for empathy, and so on?
19:02:21 <Martix> I think this category is too narrow, maybe we can create Gnome 3 Applications category
19:03:17 <rishi> Martix: Yeah, or maybe just rename the gnome-shell category to gnome for the moment and dump everything there.
19:03:23 <rishi> We can narrow it later?
19:03:40 <kparal> Martix: the Package_ categories are used in Bodhi
19:04:05 <kparal> Martix: see https://admin.fedoraproject.org/updates/FEDORA-2012-16988
19:04:09 <Martix> I'm finishing some test cases, we can discuss wiki categories later :-)
19:04:24 <kparal> Martix: so only include gnome-shell test cases in Package_gnome-shell category
19:04:32 <Martix> kparal: >>> rishi
19:04:34 <rishi> kparal: Ok.
19:05:07 <adamw> kparal: martix: yeah, that looks right.
19:05:13 <adamw> worth checking the history t osee who put them all in there
19:05:15 <adamw> oh
19:05:23 <Martix> kparal: I'll clean that later
19:07:54 <Martix> adamw: I used other test cases as a template for writing news and didn't cared about categories, will fix when I finish more visible things related to tomorrows Test Day
19:08:41 <Martix> anyway, please try and review test cases marked with {{result|pass}}
19:09:07 <kparal> Martix: just remove the categories and it's fixed, that's trivial change
19:09:54 <kparal> anyway, we finished proposed bugs, I'm leaving
19:10:16 <Martix> kparal: I envy you :-)
19:10:26 <kparal> I guess the fesco discussion may still take a long time
19:10:51 <adamw> yeah, let's get the meeting done
19:11:13 * tflink will start but still wants to watch the resolution on beta freeze entrance
19:11:52 * tflink will skip any VERIFIED bugs
19:11:56 <tflink> #topic (872446) ValueError: new size same as old size
19:11:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872446
19:11:56 <tflink> #info Accepted Blocker, anaconda, ON_QA
19:13:32 <nirik> jreznik_: are you going to send out announcements about unfreeze/schedule change?
19:13:50 <adamw> some of these probably *are* verified and just keep getting squelched by fucking bodhi
19:14:06 <tflink> does this need re-testing?
19:14:06 <jreznik_> nirik: yep, I'll do it
19:14:07 <adamw> this one's slightly special though
19:14:20 <adamw> i think the current status here is that some cases of this are fixed, but not all
19:14:37 <nirik> jreznik_: thanks.
19:14:39 <adamw> now we're unfrozen it's probably less important, but i asked bcl for feedback in #31 and didn't get it yet
19:15:12 <tflink> so, poke bcl again and/or wait for more testing?
19:15:51 <Viking-Ice> given that we are unfrozen it's a question if we dont punt all blocker bug meetings until next week?
19:16:17 <tflink> Viking-Ice: we still need to handle blockers - they don't get any less blockery
19:16:30 <nirik> yeah, go/no-go should get punted, and possibly other meetings.
19:16:35 <jreznik_> nirik: yep
19:16:53 <jreznik_> for blocker meetings - should stay
19:16:58 <nirik> and I guess infra is unfrozen, so wheee. ;)
19:17:18 <tflink> #info still waiting on information from devs in bug about whether the most recent report is just a corner-case
19:18:12 <tflink> anything else on this one?
19:18:24 <adamw> not really
19:18:24 <Viking-Ice> tflink, the anaconda guys are going to be pulling in fixes from master to beta so to me we should punt meetings until they have and we have an update to post for reporters to test to see if fixes have been applied
19:18:57 <adamw> Viking-Ice: pulling from master won't really change things wrt any blockers, since the stuff that's in post-beta is everything that's not a blocker or nth fix, by definition.
19:19:37 <tflink> Viking-Ice: I disagree. the earlier we find/approve blockers and poke fixes that may have stalled, the less likely we are to have a panic right before release or slip again
19:19:48 <tflink> #topic (872739) AttributeError: 'NoneType' object has no attribute 'get'
19:19:48 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872739
19:19:48 <tflink> #info Accepted Blocker, anaconda, ON_QA
19:20:21 <tflink> looks like this needs testing
19:20:32 <adamw> this is VERIFIED
19:20:38 <adamw> just got squelched by bodhi
19:21:03 <tflink> #info this is actually VERIFIED, was moved back to ON_QA by bodhi
19:21:21 <tflink> #topic (872791) TypeError: Argument 1 does not allow None as a value
19:21:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872791
19:21:22 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
19:21:47 <adamw> failed QA in 18.26.
19:21:53 <adamw> i need to reproduce it and add the tb.
19:22:07 <adamw> can be reproduced just by installing in German, for me (i built a live to test)
19:22:24 <tflink> #info this failed QA for anaconda-18.26
19:22:31 * jlk steps out to lunch
19:22:33 <tflink> #info waiting for reproduction, logs and traceback
19:22:56 <tflink> #topic (867593) installer must stop relying on being able to tell kpartx to use a disk/partition delimiter
19:22:59 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=867593
19:23:02 <tflink> #info Accepted Blocker, anaconda, ON_QA
19:23:24 <tflink> #info this needs re-testing to check the fix
19:23:48 <adamw> tflink: from someone with multipath or dmraid, note, which may be tricky
19:23:50 <tflink> assuming that I understand the HW requirements here, I can probably do this later today
19:23:55 <adamw> i have it in needinfo YOU at present :)
19:24:22 <tflink> yeah, I need to figure out whether I have the HW to do this or not - I suspect not if you don't have the HW, though
19:25:03 <adamw> well i don't have any multipath anything
19:25:10 <adamw> i kinda thought you did or had access to one in beaker or smth
19:25:12 <tflink> I think I have a box that uses dmraid
19:25:24 <adamw> ah, that's the other option...dmraid is any *non* intel fw raid
19:25:38 <adamw> nvidia fwraid is a common choice
19:25:39 <tflink> yeah, I have a box with NVRAID and another with promise
19:25:43 <adamw> ah, that should do it then
19:25:53 <adamw> i only have intel fwraid and then *hw* raid
19:25:56 * tflink has way too much HW :-/
19:26:21 <tflink> anywho, I'll get to that later today
19:26:38 <tflink> #action tflink to re-test w/ dmraid
19:26:49 <tflink> #topic (869391) LUKSError: luks device has no key/passphrase
19:26:49 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869391
19:26:49 <tflink> #info Accepted Blocker, anaconda, ON_QA
19:27:44 <tflink> looks like this still needs testing
19:27:50 <tflink> I'm not seeing any VERIFIED in the history
19:28:13 <tflink> #info a fix is available, more testing is needed
19:28:17 <adamw> yeah. shouldn't be too hard to re-test.
19:28:26 <tflink> #info request testing in bug
19:28:47 <tflink> #topic (873463) TypeError: sequence item 1: expected string, DiskDevice found
19:28:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873463
19:28:47 <tflink> #info Accepted Blocker, anaconda, MODIFIED
19:30:02 <tflink> it sounds like testing was done on the fix but it still needs re-testing on a released anaconda
19:30:15 <adamw> yeah, i need an image with 18.26 to confirm
19:30:21 <adamw> or 18.27.
19:30:56 <tflink> adamw: smoke 15 is done but I forgot to say anything last night
19:31:18 <tflink> haven't had the chance to test it myself and satellit seemed to be hitting some issues with it
19:31:35 <adamw> ah
19:31:40 <tflink> #info the fix has been tested in isolation but this still needs testing with a released anaconda
19:32:25 <tflink> we have an 18.27?
19:32:50 <tflink> #topic (868834) can't use package section in kickstart
19:32:51 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=868834
19:32:51 <tflink> #info Accepted Blocker, anaconda, ON_QA
19:33:12 <tflink> sigh, another squelched VERIFIED
19:33:23 <tflink> #info this is actually VERIFIED, was moved back to ON_QA by bodhi
19:33:51 <adamw> tflink: we don't have 18.27, but we will
19:33:58 <adamw> since we're unfreezing the idea is to kick anaconda back to master and kinda 'reset'
19:34:00 <tflink> #topic (872047) fedup-dracut builds do not exist in F18
19:34:00 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872047
19:34:00 <tflink> #info Accepted Blocker, fedup-dracut, ON_QA
19:34:08 <adamw> so do an 18.27, a smoke16 (presumably), and see where we stand
19:34:27 * tflink wishes that the image building service was working, would love to trigger smoke builds on any successful anaconda build
19:34:48 <tflink> as long as I'm in fantasy land, ponies anyone?
19:34:58 <tflink> they're mighty tasty :-P
19:35:33 <Viking-Ice> Sorry busy at fesco meeting and kinda need to run home now from work I'm starving
19:35:34 <tflink> not sure what to do about this one. we do have fedup-dracut builds in F18 right now
19:35:56 <tflink> so technically, we could move it to VERIFIED and wait for karma
19:36:18 <tflink> but I'd be more -1 karma on the current build
19:36:49 <tflink> any thoughts?
19:36:51 <adamw> not sure we have to care too much at this point.
19:36:54 <adamw> so long as we know where we are.
19:37:04 <adamw> it's just bureaucracy with the current state of fedup.
19:37:37 <tflink> yeah, I'm not testing from the currently packaged version, anyways
19:37:48 <tflink> but the upgrade.img on fedorapeople is built from that
19:37:50 <tflink> either way
19:38:19 <tflink> #info there are now fedup-dracut builds in f18 updates-testing
19:38:38 <tflink> #info move to VERIFIED and wait for a build to be pushed to stable
19:38:50 <tflink> #topic (872361) parted shouldn't de-reference symlinks for named md devices(?) - this is blocking Intel fwraid support for F18 Beta
19:38:53 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872361
19:38:55 <tflink> #info Accepted Blocker, parted, VERIFIED
19:39:13 <tflink> oops
19:39:15 <tflink> #undo
19:39:15 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x5f933d50>
19:39:17 <tflink> #undo
19:39:17 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x47a09d90>
19:39:19 <tflink> #undo
19:39:19 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1996db50>
19:39:28 <tflink> #topic (873387) After minimal install there is no login prompt on tty1
19:39:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=873387
19:39:28 <tflink> #info Accepted Blocker, systemd, NEW
19:40:09 <tflink> looks like there is active conversation in the comments, work is ongoing
19:40:42 <adamw> i asked spot to look at this yesterday
19:40:55 <adamw> that comment from bill came pretty early yesterday, so i'm not sure the pace is as frantic as i'd like
19:41:05 <adamw> but hey, on the positive side, this will almost certainly magically go away now we're unfreezing
19:41:19 <tflink> #info testing and some investigation is going on
19:41:30 <tflink> adamw: the slow pace or the bug?
19:41:41 <adamw> the bug.
19:41:45 <adamw> since it doesn't happen with netinst
19:42:01 <adamw> i bet that when we pull everything into stable, this'll magically disappear with tc8
19:42:38 <tflink> #info retest with TC8 once everything has been pulled into stable, this may be fixed since it doesn't happen with netinstall
19:42:56 <tflink> ok, I think that's all of the bugs on the list for today
19:43:00 <tflink> did I miss anything?
19:43:10 <adamw> gin?
19:43:55 <tflink> I didn't really miss that, wasn't looking for it :)
19:43:58 <tflink> beer, maybe
19:44:26 <tflink> #topic Open Floor
19:44:54 <Martix> rishi: thanks for your changes, feel free to modify/create test cases marked with {{result|fail}}
19:45:13 <Martix> rishi: I need to leave now, see you tomorrow!
19:45:20 <tflink> CRCinAU wanted to bring up the following bug as a possible final blocker
19:45:24 <rishi> Martix: Have a nice evening!
19:45:32 <Martix> rishi: thanks
19:45:36 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=872608
19:45:59 * tflink doesn't quite know what to say about it, though
19:46:06 <thunderbirdtr> How can I set virt-manager network bridge it ? I set for my wifi card but I can't see local IPs in my virt-F18  ? any help hand please ?
19:46:44 <tflink> it doesn't sound like a blocker to me, but I could be wrong
19:48:00 <tflink> anyhow, it doesn't sound like there are people jumping to comment
19:48:34 <tflink> #info if there are bugs that could be blockers, please propose them - preferrably with a criterion that the bug is violating
19:48:42 <tflink> if there's nothing else ...
19:49:08 <tflink> #info next blocker bug review meeting will be on 2012-11-14 @ 17:00 UTC
19:49:25 <tflink> I think, it's at 17:00 UTC now since my announcement was corrected
19:49:33 <tflink> either way ...
19:50:08 * tflink sets fuse for some discrete value GEQ 0
19:50:16 * tflink will send out minutes shortly
19:50:22 <tflink> Thanks for coming everyone!
19:50:26 <tflink> #endmeeting