17:00:44 <tflink> #startmeeting F16-Beta_blocker_review
17:00:44 <zodbot> Meeting started Fri Sep  9 17:00:44 2011 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:02 <tflink> #meetingname F16-beta_blocker_review
17:01:02 <zodbot> The meeting name has been set to 'f16-beta_blocker_review'
17:01:10 <tflink> #topic roll-call
17:01:18 * athmane is here
17:01:19 <tflink> who all do we have today?
17:01:35 <tflink> athmane, j_dulaney: hello and welcome
17:02:04 <j_dulaney> Wassup
17:02:22 <adamw> yo
17:02:42 <tflink> adamw: welcome to the party
17:03:20 <adamw> what have I told you about having fun?!
17:03:32 * nirik is lurking. ping if I can help with anything.
17:03:50 <tflink> adamw: that it is an absolute requirement?
17:04:46 <tflink> looks like we have a decent list again, so lets get started
17:04:53 <tflink> any volunteers to play secretary?
17:05:30 <Viking-Ice> Ok now that I can finally make my appearance what's unclear with the BindTo= and Requires= to to another units which results in hangs with try-restart and restarts of units
17:05:33 * brunowolff is here
17:05:54 <Viking-Ice> this will happen it's not a question of iff
17:06:11 <tflink> Viking-Ice, brunowolff: welcome, we're about to get started
17:06:20 <tflink> #topic Introduction
17:06:27 * j_dulaney has to be in class at 2, so he can't be secretary
17:06:41 <tflink> #link https://fedoraproject.org/wiki/Current_Release_Blockers
17:06:51 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:07:12 <tflink> why are we here?
17:07:15 <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:07:26 <tflink> any suggestions on what to start with?
17:07:37 <tflink> otherwise, I was planning to dive into the proposed blockers
17:07:53 * j_dulaney says start at the top
17:08:05 <j_dulaney> Of proposed blocker's, that is
17:08:45 <tflink> alrighty, here we go
17:08:50 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=736880
17:08:51 <buggbot> Bug 736880: high, unspecified, ---, hughsient, MODIFIED, packagekitd startup fails with 'undefined symbol: g_unix_signal_add_watch_full'
17:09:00 <tflink> #info packagekitd startup fails with 'undefined symbol: g_unix_signal_add_watch_full'
17:09:53 <tflink> looks like the release criterion in question is "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops"
17:10:01 * j_dulaney is going to say +1 for blocker
17:10:13 <tflink> I'm +1 blocker on this, too
17:10:19 <brunowolff> +1 blocker
17:10:28 <Viking-Ice> +1
17:10:42 <tflink> proposed #agreed - 736880 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:10:45 <adamw> ack
17:10:53 <brunowolff> ack
17:11:07 <Viking-Ice> ack
17:11:09 <tflink> #agreed - 736880 - AcceptedBlocker - The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops
17:11:19 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=733448
17:11:20 <buggbot> Bug 733448: medium, unspecified, ---, jmoskovc, ON_QA, abrt refuses to attach anaconda crash dump to automated anaconda bug reports
17:11:28 <tflink> #info abrt refuses to attach anaconda crash dump to automated anaconda bug reports
17:11:51 <j_dulaney> I'm going to say +1 on this, too
17:11:55 <Viking-Ice> me too
17:12:25 <tflink> a fix is ready, so blocker status may be academic but
17:12:44 <tflink> proposed #agreed - 733448 - AcceptedBlocker - The installer must be able to report failures to Bugzilla, with appropriate information included
17:12:45 <j_dulaney> This way it should make it into the next TC
17:12:47 <Viking-Ice> adamw, is right in comment12 that limitation/restriction should be handled in bugzilla ( or what ever receives it )
17:13:00 <tflink> j_dulaney: I'm pretty sure that it did make it into TC2
17:13:06 <tflink> also on the test boot.iso I made
17:13:07 <j_dulaney> Ok
17:13:08 <adamw> under the 'must be able to report anaconda bugs to bugzilla' criterion, i guess
17:13:19 <j_dulaney> Indeed
17:13:24 <adamw> so i'm +1 too
17:13:32 <j_dulaney> Ack for blocker (even if late)
17:13:37 <tflink> ack/nak/patch?
17:13:44 <Viking-Ice> ack
17:13:52 <tflink> #agreed - 733448 - AcceptedBlocker - The installer must be able to report failures to Bugzilla, with appropriate information included
17:14:01 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=728923
17:14:02 <buggbot> Bug 728923: unspecified, unspecified, ---, akozumpl, MODIFIED, Serial console is not configured
17:14:10 <tflink> #info Serial console is not configured
17:14:37 <tflink> I think that this has been fixed, for the most part
17:14:48 <Viking-Ice> hum do we have criteria that covers serial console setups ( both for physical and virtual )
17:14:54 <adamw> Viking-Ice: not exactly
17:14:55 <tflink> nope
17:15:03 <Viking-Ice> nth
17:15:04 <adamw> we've been punting on this one for a while
17:15:07 <j_dulaney> Which make this nth
17:15:11 <tflink> it was accepted as NTH and kept on the blocker list to keep an eye on it
17:15:19 <adamw> because serial console was in the alpha 'group' of install tests prior to the criteria re-write
17:15:23 <tflink> I'm OK with -1 blocker and asking for confirmation
17:15:25 <Viking-Ice> but we kinda have to make this a final criteria
17:15:27 <adamw> but we didn't incorporate it into the criteira
17:15:47 <Viking-Ice> atleast that's my take on it
17:15:51 <adamw> so as we've been saying it each meeting we need to decide whether we want it in the criteria, and if so, where...but we've been punting on it and hoping the bug goes away
17:15:54 <j_dulaney> adamw:  Maybe it should be?  (For list discussion)
17:15:57 <tflink> didn't we have a TODO from last week to propose a criterion about console?
17:16:09 <adamw> probably, and it was probably me, and i probably missed it...
17:16:32 <tflink> IIRC it was to either you or me - we both dropped the ball :)
17:16:44 <adamw> so, anyway, same deal as before
17:16:55 <adamw> this should be fixed, but we couldn't re-test in tc1 because of the 'all text installs are broken' bug
17:17:01 <adamw> now that's fixed in tc2, we should be able to re-test this
17:17:10 <tflink> proposed #agreed - 728923 - RejectedBlocker - This should be fixed, doesn't need blocker since it's NTH. Ask for confirmation of fix in bug.
17:17:16 <tflink> ack/nak/patch?
17:17:19 <adamw> sure, works for now.
17:17:20 <Viking-Ice> ack
17:17:21 <j_dulaney> ack
17:17:30 <tflink> IIRC, there were reports of serial installs mostly working
17:17:37 <tflink> #agreed - 728923 - RejectedBlocker - This should be fixed, doesn't need blocker since it's NTH. Ask for confirmation of fix in bug.
17:17:49 <Viking-Ice> hum there is even a question if this should be beta critera
17:17:49 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=730415
17:17:50 <buggbot> Bug 730415: unspecified, unspecified, ---, bcl, VERIFIED, kickstart with user --name=blah results in traceback
17:17:58 <tflink> #info kickstart with user --name=blah results in traceback
17:18:22 <tflink> I think this is another one where we wanted to clarify the criteria
17:18:29 <j_dulaney> Does this hit an existing criteria, or just a proposed?
17:18:30 * tflink can't remember if we got around to that yet, though
17:18:41 <tflink> j_dulaney: the ks criteria aren't incredibly clear
17:18:42 <adamw> doesn't hit any existing
17:18:44 <Viking-Ice> dont we have criteria that covers all kickstart options ?
17:18:59 <tflink> since it's VERIFIED, I'm all for -1 blocker
17:19:00 <Viking-Ice> I would think network install should cover that
17:19:01 <adamw> we didn't have any kickstart criteria until that list thread i started
17:19:10 <j_dulaney> Viking-Ice, not quite
17:19:33 <adamw> the only consensus that came out of the list thread was for the most basic 'reproduce a click-thru install' ks, which does not include --user
17:19:46 <Viking-Ice> ah right now I remember
17:19:57 <adamw> so as things stand, this doesn't hit a criterion. if we were all really worried about this bug, though, we could agree that there should be a criterion for --user, and tkae it on the basis that we'd add one.
17:20:08 <adamw> i think anaconda team was generally of the opinion that --user isn't hugely widely used, though
17:20:10 <j_dulaney> +1 for that
17:20:18 <tflink> proposed #agreed - 730415 - RejectedBlocker - Bug is now VERIFIED, discussion of blocker status is purely academic
17:20:37 <Viking-Ice> hum not sure
17:20:39 <adamw> tflink: well, since we want to set kickstart criteria based on 'case law', it's not entirely academic...
17:20:55 <tflink> point
17:21:04 <Viking-Ice> we should just cover the most commonly used kickstart options
17:21:13 <tflink> do we punt on this one again until we get more clarification on the criteria?
17:21:19 <adamw> we had this exact discussion last week, in fact
17:21:22 <adamw> and decided to make it RejectedBlocker
17:21:29 <Viking-Ice> then it's an rejectblocker
17:21:30 <adamw> so probably a fail on my/tflink's part in secretaryizing
17:21:40 <tflink> oh, didn't notice that
17:21:50 <adamw> who's secretarying this week, btw? i'll start, if no-one else wants to
17:22:01 <tflink> #info already RejectedBlocker, moving on
17:22:06 <j_dulaney> Alright, if that's the case, then I'm +1 for RejectedBlocker
17:22:07 <tflink> adamw: nobody volunteered
17:22:23 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=731177
17:22:24 <buggbot> Bug 731177: unspecified, unspecified, ---, dlehman, ASSIGNED, DeviceTreeError: MD RAID device md127 not in devicetree after scanning all slaves
17:22:31 <tflink> #info DeviceTreeError: MD RAID device md127 not in devicetree after scanning all slaves
17:22:41 <j_dulaney> +1 for blocker
17:23:01 <j_dulaney> I know it hits one, just can't remember the exact wording off the top of my head
17:23:02 <Viking-Ice> +1 for blocker
17:23:26 <Viking-Ice> installer one definitely
17:23:30 <tflink> "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:23:33 <tflink> I think
17:23:47 <adamw> well it doesn't quite hit that
17:23:56 <adamw> because it's more about handling *existing* RAID arrays
17:24:01 <j_dulaney> 12
17:24:10 <tflink> j_dulaney: alpha, beta or final?
17:24:12 <adamw> although you could argue that 'create and install to' can mean 'install to existing', i guess
17:24:14 <Viking-Ice> I would think that would not matter
17:24:19 <j_dulaney> beta
17:24:24 <tflink> yeah, that's it
17:24:28 <adamw> and actually...with the BIOS RAID stipulation, it kinda must
17:24:29 <tflink> "The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations "
17:24:37 <adamw> because an installer can't create BIOS RAID partitions...
17:24:41 <adamw> ooh, yeah, definitely hits that one.
17:24:46 <tflink> damn, I can't read again
17:24:51 <tflink> that's rescue mode
17:25:12 <adamw> well i think this would hit rescue mode too.
17:25:20 <j_dulaney> Indeed
17:25:28 * j_dulaney also mis-read
17:25:28 <adamw> but let's take it under the RAID criterion and declare that that includes installing to pre-existing RAID array.
17:25:35 <j_dulaney> +1
17:25:52 <j_dulaney> +1 for modifying the criteria to include existing
17:25:57 <tflink> proposed #agreed - 731177 - AcceptedBlocker - The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations
17:26:01 <Viking-Ice> ack
17:26:01 <tflink> ack/nack/patch?
17:26:02 <j_dulaney> ack
17:26:09 <adamw> ack
17:26:18 <brunowolff> ack
17:26:21 <tflink> do we want to modify the criteria so that it hits more clearly?
17:26:28 <tflink> I'm OK with things as they are
17:26:38 <tflink> #agreed - 731177 - AcceptedBlocker - The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations
17:26:43 <adamw> eh, i think it's clear enough. could be improved, i guess, but not high priority.
17:27:11 <j_dulaney> Canadians...
17:27:12 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735730
17:27:13 <Viking-Ice> if the install supports installing on raid it needs to support installing on all types of raid setup is my take on it
17:27:13 <buggbot> Bug 735730: unspecified, unspecified, ---, anaconda-maint-list, NEW, IOError: [Errno 2] No such file or directory: '/mnt/sysimage/boot/grub2/device.map'
17:27:16 <tflink> #info IOError: [Errno 2] No such file or directory: '/mnt/sysimage/boot/grub2/device.map'
17:27:46 <Viking-Ice> ack on blocker
17:28:10 <tflink> "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria"
17:28:50 <j_dulaney> +1
17:28:57 <adamw> yeah, seems clear enough
17:29:08 <tflink> proposed #agreed - 735730 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:29:13 <tflink> ack/nak/patch?
17:29:14 <Viking-Ice> ack
17:29:17 <adamw> should re-test with tc2, but i expect it'll still be broken
17:29:17 <adamw> ack
17:29:20 <brunowolff> ack
17:29:38 <tflink> proposed #agreed - 735730 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Request re-test with TC2.
17:29:47 <tflink> #agreed - 735730 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Request re-test with TC2.
17:30:07 * tflink assumed that adding the last line was OK
17:30:13 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735785
17:30:15 <buggbot> Bug 735785: unspecified, unspecified, ---, bcl, ASSIGNED, Upgrade Skip Bootloader broken
17:30:20 <tflink> #info Upgrade Skip Bootloader broken
17:30:52 * j_dulaney cannot find this in Beta criteria
17:30:58 <j_dulaney> Is it Final?
17:31:08 <tflink> upgrade is beta, no?
17:31:11 <Viking-Ice> it hits the same criteria as before right?
17:31:22 <tflink> yeah
17:31:28 <adamw> well, it's a type of upgrade, yeah.
17:31:29 <Viking-Ice> so that's an clear ack
17:31:39 <j_dulaney> But not the skip bootloader bit
17:31:54 <adamw> the criterion doesn't specify what you do with the bootloader.
17:32:03 <tflink> proposed #agreed - 735785 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:32:03 <Viking-Ice> upgrade is an upgrade
17:32:08 <adamw> so it becomes a judgment call: is this significant enough for us to consider it breaking the criterion.
17:32:14 <Viking-Ice> ack
17:32:24 <adamw> i'd say it is, especially since it's a longstanding test case that exercises an option that's in anaconda presumably for some kind of reason...
17:32:32 <j_dulaney> Alright
17:32:35 <j_dulaney> ack
17:32:47 <adamw> ack
17:32:55 <tflink> yeah, it's not the default option but it's not really hidden either
17:33:03 <tflink> #agreed - 735785 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
17:33:16 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=736527
17:33:17 <buggbot> Bug 736527: unspecified, unspecified, ---, anaconda-maint-list, NEW, anaconda fails to parse its own auto-generated kickstart file's partitioning ('tried to use undefined partition')
17:33:24 <tflink> #info anaconda fails to parse its own auto-generated kickstart file's partitioning ('tried to use undefined partition')
17:33:37 <j_dulaney> +1 for blocker
17:33:48 <Viking-Ice> lol,
17:33:56 <Viking-Ice> I go nth on that one
17:34:10 <Viking-Ice> we are talking about an kickstart file generated by anaconda after install
17:34:42 <Viking-Ice> still laughable thou
17:34:50 <tflink> wouldn't that fall under duplicating the interactive installation as closely as possible?
17:35:00 <adamw> it's arguable
17:35:02 <adamw> see my comment in the bug
17:35:23 <j_dulaney> Well, I must take my leace
17:35:25 <adamw> in a sense no, because it's not using the .ks file without modifying it, but in a sense yes, because the modification is only to automate one more step
17:35:30 <j_dulaney> c/leace/leave
17:35:35 <tflink> j_dulaney: thanks for helping out
17:35:37 <adamw> cya dulaney, thanks for the help
17:35:46 <j_dulaney> Righteo
17:35:49 <j_dulaney> Peace, y'all
17:35:54 <tflink> it sounds like there is a fix ready?
17:35:59 <Viking-Ice> yup
17:36:07 <adamw> yeah
17:36:15 <adamw> i need to find a moment to test it
17:36:18 <adamw> or anyone else can, of course ;)
17:37:16 * tflink is asking in #anaconda
17:37:22 <Viking-Ice> nth <--
17:37:24 <adamw> so, i think i'm +1 to this one
17:37:34 <adamw> thinking on a wider scale, automating the partitioning seems like something that'd commonly be done in a ks
17:37:44 <adamw> though i suppose it's quite easily workaroundable, by re-ordering the lines
17:37:46 <tflink> so we have +2 blocker, +1 nth
17:37:53 <brunowolff> +1 nth
17:37:55 <tflink> Viking-Ice: I assume you're -1 blocker, then?
17:37:59 <Viking-Ice> yup
17:38:05 <Viking-Ice> -1 blocker +1 nth
17:38:23 <adamw> and...it's more to do with the autogeneration in anaconda...if you were to handwrite a ks to duplicate a default install this bug wouldn't come up...
17:38:28 <adamw> hum, maybe i change to nth. =)
17:38:29 <tflink> confirmed with dlehman, potential fix is ready - after verification, he'll send it out for review
17:38:39 <brunowolff> But if there is a fix, it probably isn't worth sp[ending a lot of time deciding which to use.
17:38:43 <tflink> yeah, I think I'm more nth on this
17:38:48 <adamw> okay, let's go nth.
17:39:44 <tflink> proposed #agreed - 736527 - RejectedBlocker AcceptedNTH - Handwritted kickstart files still work, this only applies to auto-generated ones and therefore not a blocker
17:39:51 <adamw> good enough, ack
17:40:27 <tflink> #agreed - 736527 - RejectedBlocker AcceptedNTH - Handwritten kickstart files still work, this only applies to auto-generated ones and therefore not a blocker
17:40:38 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=736893
17:40:39 <buggbot> Bug 736893: medium, unspecified, ---, akozumpl, NEW, New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot
17:40:49 <tflink> #info New Install of Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot
17:41:11 <tflink> what's iBFT?
17:41:28 <tflink> ah, pretty much PXE for iSCSI
17:41:38 <Viking-Ice> +1 on blocker
17:41:48 <Viking-Ice> same case as before with raid
17:41:53 <Viking-Ice> now just iSCI
17:42:05 <tflink> I'm -1 on beta blocker, +1 beta nth and +1 final blocker
17:42:30 <tflink> final criterion - "The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel) "
17:42:32 <adamw> iscsi is final i believe
17:42:34 <adamw> yeah
17:42:40 <Viking-Ice> ok final it is
17:42:45 <adamw> so same as tflink, beta nth, final blocker
17:42:51 <Viking-Ice> ack on that as well
17:43:19 <tflink> proposed #agreed - 736893 - AcceptedBlocker (Final) AcceptedNTH (beta) - The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)
17:43:49 * tflink uses implied acks
17:43:54 <tflink> #agreed - 736893 - AcceptedBlocker (Final) AcceptedNTH (beta) - The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)
17:44:07 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=736530
17:44:08 <buggbot> Bug 736530: unspecified, unspecified, ---, dledford, NEW, mdadm fails to auto-start md arrays on f16-beta.tc1 live media due to avc denials
17:44:16 <tflink> #info mdadm fails to auto-start md arrays on f16-beta.tc1 live media due to avc denials
17:44:36 <adamw> this is pretty much the same RAID deal for live images
17:44:45 <adamw> installing to a pre-existing mdraid array (like an intel bios RAID array)
17:44:52 <Viking-Ice> I see but dont we have a set of selinux criterias that this falls under
17:44:53 <Viking-Ice> as well
17:45:00 <tflink> for final, I think
17:45:14 <tflink> In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login
17:45:34 <adamw> selinux is just the cause
17:45:43 <adamw> the symptom is 'you can't install to a pre-existing RAID array', same as the other bug
17:45:47 <Viking-Ice> yup
17:45:49 <adamw> doesn't really matter that the root cause is an selinux denial
17:45:54 <Viking-Ice> or the installer
17:46:04 <Viking-Ice> ack on blocker
17:46:32 <tflink> proposed #agreed - 736530 - AcceptedBlocker - 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:46:33 <adamw> actually, this is on the list through deps, it's not proposed directly
17:46:50 <tflink> yeah but it's causing issues with live, no?
17:46:50 <adamw> it's just a dep of https://bugzilla.redhat.com/show_bug.cgi?id=731177 and we already discussed that one
17:46:51 <buggbot> Bug 731177: unspecified, unspecified, ---, dlehman, ASSIGNED, DeviceTreeError: MD RAID device md127 not in devicetree after scanning all slaves
17:47:10 <adamw> so i think we can leave this one alone
17:47:22 <adamw> i think 731177 actually is for lives and there's another for non-live that's probably coming up...
17:47:32 <Viking-Ice> well the parent fix wont fix this one does it ( since it's selinux )
17:47:36 <Viking-Ice> ?
17:47:45 <tflink> I think that the non-live was already accepted
17:47:48 <adamw> no
17:47:53 <adamw> Viking-Ice: it's the other way around
17:47:58 <adamw> this one needs to be fixed before the parent is fixed
17:48:20 <Viking-Ice> ok
17:48:21 <adamw> really i dunno if a 'child' bug was appropriate as i don't think there are two interdependent problems but just one problem, but oh well
17:48:57 <Viking-Ice> we can just revisit it after the other one has been solved
17:49:05 <Viking-Ice> if necessary and leave it as is
17:49:07 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=736521 is for non-live
17:49:08 <tflink> I could go either way on this since it'll get fixed
17:49:08 <buggbot> Bug 736521: unspecified, unspecified, ---, kernel-maint, NEW, mdadm crash/oops when stopping array in installer environment
17:49:14 <adamw> i think we just leave 736530 alone
17:49:19 <adamw> it's not actually a proposed blocker in itself
17:49:22 <Viking-Ice> yup
17:49:24 <adamw> it just gets into the list as we considers deps
17:49:30 <adamw> so we don't really need to do anything with it
17:50:08 <adamw> so for clarity, 731177 is our 'install to pre-existing raid on live fails' bug, and 736521 is our 'install to pre-existing raid via traditional installer fails' bug
17:50:15 <adamw> 736530 we don't really need to worry about
17:50:20 <tflink> proposed #agreed - 736530 - Ignoring since it's a child of the actual blocker, needs to be fixed as part of rhbz#736530
17:50:26 <adamw> ack
17:50:36 <Viking-Ice> ack
17:50:43 <tflink> #agreed - 736530 - Ignoring since it's a child of the actual blocker, needs to be fixed as part of rhbz#736530
17:51:00 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=733455
17:51:01 <tflink> #info Kickstart error "Section does not end with %end"
17:51:01 <buggbot> Bug 733455: high, unspecified, ---, clumens, MODIFIED, Kickstart error "Section does not end with %end"
17:51:47 <adamw> this definitely doesn't hit our minimal criterion as it's to do with %include-ing another file
17:51:48 <tflink> this rejects properly formatted ks, right?
17:52:04 <adamw> so this is another 'case law' one, if we're really worried about this, we can add it to the criteria
17:52:18 <Viking-Ice> I dont think that is necessary
17:52:36 <Viking-Ice> I think this one is just regular bug that needs fixing as in reject blocker
17:52:37 <tflink> oh, I get it, I thought that putting the %end in the include was a workaround from having %end in the ks
17:53:00 <tflink> yeah, I'm nth on this, at the most
17:53:04 <adamw> yeah, this doesn't set off any major alarm bells for me
17:53:07 <adamw> nth as it's a visible installer bug
17:53:10 <tflink> I'd be worried about what it could do to stuff like cobbler
17:53:23 <Viking-Ice> yup same here
17:53:54 <adamw> wow, we're all agreeing today, must be something in the water =)
17:54:11 <Viking-Ice> dont ruin it ;)
17:54:13 <tflink> proposed #agreed - 733455 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria since it's working with %include but there are tools that use %include and it could be an ugly bug
17:54:25 <tflink> adamw: now you've gone and jinxed us
17:54:49 <Viking-Ice> nack! just kidding ack =)
17:54:56 <adamw> hehe
17:54:58 <adamw> ack
17:55:08 <tflink> #agreed - 733455 - RejectedBlocker AcceptedNTH - This doesn't hit any release criteria since it's working with %include but there are tools that use %include and it could be an ugly bug
17:55:20 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735013
17:55:21 <buggbot> Bug 735013: unspecified, unspecified, ---, lpoetter, NEW, Having unit B bound or required to unit A and restarting unit A while it's active results hang
17:55:28 <tflink> #info Having unit B bound or required to unit A and restarting unit A while it's active results hang
17:55:35 <tflink> Viking-Ice: this is the one you were talking about before, no?
17:55:39 <Viking-Ice> yup
17:55:43 <Viking-Ice> clear bug in my case
17:56:05 <tflink> I'm still a little unclear on the impact (as in number of packages)
17:56:27 <Viking-Ice> I dont see how that matters
17:56:38 * tflink is re-reading
17:56:49 <adamw> well, i don't think _number_ matters
17:57:02 <adamw> if we're confident _some_ package would hit this in an f15-f16 upgrade it should be a blocker
17:57:19 <Viking-Ice> if you would add for example Require= to mysql or httpd and update then mysql or update and the package runs try-restart or restart that will result in hang
17:57:22 <adamw> i think this may be a case like the ones we hit in Alpha
17:57:30 <adamw> where bugs hid behind each other
17:57:47 <adamw> i think right now we may be a bit hesitant on this one because we haven't seen it...but we probably haven't seen it because upgrades are broken
17:57:53 <brunowolff> Does it actually break updates or does this require a reboot after an update to fix running services?
17:57:59 <adamw> i do kinda suspect that, once upgrades are fixed, we'll suddenly find we're running into this bug
17:58:36 <adamw> i suppose it'd be easy enough to test a yum upgrade from f15 to f16 in a vm and see if it hits this
17:59:06 <Viking-Ice> brunowolff, did not test updating a package which I had unit bound or required to the update in question but this was reported upstream
17:59:21 <tflink> brunowolff: as I understand it, upgrades are broken not updates
17:59:27 <Viking-Ice> and the reporter there mention hitting this on updates/upgrades hence
17:59:32 <Viking-Ice> tflink, both
17:59:50 <Viking-Ice> if the package script runs try-restart or restart this will hang regular update or upgrade
17:59:52 <tflink> shouldn't we have seen this more by now, then?
18:00:04 <adamw> that's a point, i guess...
18:00:05 <Viking-Ice> we have more unit files in F16
18:00:13 <brunowolff> Broken in what sense? Does the upgrade not complete? (I didn't see that when I upgraded from F15 to rawhide a few months ago.)
18:00:16 <Viking-Ice> even more so after spot being on fire
18:00:22 <adamw> i think tflink is saying why haven't we seen it on f16 updates
18:00:26 <brunowolff> Does it just mess up running servuces?
18:00:39 <adamw> brunowolff: if it's as described it would cause the update/upgrade process itself to hang
18:00:51 <adamw> as the %post script would run an operation that hung, blocking up the whole process
18:00:54 <brunowolff> Thanks. Thank sounds like a blocker to me.
18:01:09 <adamw> but, as tflink points out, it doesn't seem like this is happening at all in f16 so far
18:01:29 <tflink> the last report was 2011-08-04
18:01:30 <Viking-Ice> from upstream report "Note that this is pretty bad as try-restart is run during %post on yum update,
18:01:30 <Viking-Ice> so if it hangs, the whole yum process waits on it, and if the user kills it, he
18:01:30 <Viking-Ice> ends up with an unfinished yum transaction and a potentially broken system."
18:01:43 <tflink> over a month ago, maybe its been fixed magically
18:01:46 <Viking-Ice> hence a clear blocker
18:01:59 <tflink> as described, I'm +1 blocker on this
18:02:04 <Viking-Ice> tflink, Lennart has not fixed this freeipa guys are waiting for that fix
18:02:06 <adamw> yeah...i think there's no real harm in taking this
18:02:07 <tflink> but it would be nice to have some recent repros
18:02:12 <Viking-Ice> since they depend on this working correctly
18:02:14 <adamw> it's safer than _not_ taking it
18:02:20 <tflink> very true
18:02:28 <adamw> Viking-Ice: can you make sure lennart fixes it soon?
18:02:45 <Viking-Ice> Lennart is on tour
18:03:04 <tflink> proposed #agreed - 735013 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
18:03:12 <Viking-Ice> ack
18:03:13 <brunowolff> ack
18:03:27 <adamw> ack
18:03:32 <tflink> #agreed - 735013 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria
18:03:33 <adamw> oh right
18:03:39 <adamw> will he be back in time to fix it?
18:03:44 <tflink> ok, I know that there was at least one blocker I missed
18:03:49 <Viking-Ice> adamw, Harald and Kay and Lennart will be dropping by at Red Hat hence you might be able to ping him about this
18:03:57 <adamw> we need all blockers fixed by sep 15th for the rc
18:04:06 <Viking-Ice> and harald about the dracut bug
18:04:35 <Viking-Ice> Let's make note on that on the bug
18:04:50 <tflink> #undo
18:04:50 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0xcc3c44c>
18:05:06 <Viking-Ice> ?
18:05:12 <tflink> #agreed - 735013 - AcceptedBlocker - The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Note that beta blocker bugs must be fixed by 2011-09-15 for the RC
18:05:17 <adamw> Viking-Ice: done
18:05:43 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=737118
18:05:44 <buggbot> Bug 737118: unspecified, unspecified, ---, mgracik, NEW, firstboot-text prevents system from booting
18:05:52 <tflink> #info firstboot-text prevents system from booting
18:06:41 <adamw> this is a blocker for me; we don't need firstboot-text to work, really, but we do need it not to interfere with regular boot of a text install
18:06:47 <tflink> note that for this, I'm not expecting firstboot-text to work (it would be nice, though) just that booting into multi-user should work, even if you have a graphical package installed
18:06:59 <Viking-Ice> I'm ack on this one it should not matter if you are doing minimal text install or full blown graphical install
18:07:22 <adamw> Viking-Ice: minimal isn't actually affected as it doesn't include firstboot
18:07:23 <tflink> I'm pretty sure that it affects live images, too
18:07:33 <adamw> but there are certainly cases where you would install with a package set that includes firstboot, and boot to runlevel 3
18:07:38 <tflink> but I need to retest because the symptoms changed between the graphics test iso and RC2
18:08:28 <adamw> and you can install 'without a graphical environment' but still with firstboot
18:08:35 <adamw> (that's why firstboot-text exists, after all)
18:08:42 <Viking-Ice> yup
18:08:47 <adamw> so, +1.
18:08:51 <Viking-Ice> +1
18:09:11 <tflink> proposed #agreed - 737118 - AcceptedBlocker - In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) 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. This includes correctly accessing any en
18:09:24 <tflink> hmm, that could have been shorter
18:10:21 <adamw> my fault for writing the criteria as if i'm getting paid by word
18:10:54 <tflink> otherwise, I'm fine with "booting into multi-user mode should work, even if a graphical desktop is installed"
18:11:45 <Viking-Ice> uhum that kinda might be a bit vague
18:12:00 <tflink> the proposed one or my shortened version?
18:12:08 <Viking-Ice> criteria one
18:12:23 <tflink> suggestions?
18:12:30 <Viking-Ice> I'm ack on the proposal
18:12:33 <adamw> right
18:12:44 <tflink> oh, you were saying that the criterion was vague
18:12:45 <adamw> oh wait
18:12:47 <adamw> wrong criterion
18:12:53 <adamw> that's the firstboot criterion
18:13:03 <Viking-Ice> <tflink> otherwise, I'm fine with "booting into multi-user mode should work, even if a graphical desktop is installed"
18:13:06 <adamw> the criterion is "When booting a system installed without a graphical environment, or when using
18:13:06 <adamw> a correct configuration setting to cause an installed system to boot in
18:13:06 <adamw> non-graphical mode, the system should boot to a state where it is possible to
18:13:06 <adamw> log in through at least one of the default virtual consoles"
18:13:06 <Viking-Ice> speaking of this
18:13:44 <Viking-Ice> any we might need  a set of target to test emergency.target multi-user.target graphical.target
18:13:45 <Viking-Ice> etc..
18:14:00 <tflink> proposed #agreed - 737118 - When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles
18:14:18 <adamw> ack
18:14:20 <Viking-Ice> ack
18:14:21 <tflink> #agreed - 737118 - When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles
18:14:44 <tflink> I think that's it for the proposed blockers
18:14:47 <tflink> did I miss any?
18:15:03 <adamw> i can do a quick search...
18:16:35 <adamw> nope, i don't see any.
18:16:45 <tflink> ok, on to proposed NTH then
18:16:54 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=733680
18:16:55 <buggbot> Bug 733680: high, high, ---, rvykydal, NEW, DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
18:17:05 <tflink> #info DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
18:17:44 <tflink> ah, secondary arch blocker, no?
18:18:16 <Viking-Ice> I would think so yes
18:18:24 <tflink> +1 nth
18:18:27 <adamw> um
18:18:28 <brunowolff> +1 nth
18:18:34 <adamw> don't we have a whole separate system for handling secondary arch blockers?
18:18:49 <adamw> we don't take them through this process as secondary arches don't follow the primary arch release schedule...
18:18:56 <adamw> that was the whole thing jlaska was working on
18:18:58 <tflink> adamw: not sure, it affects anaconda as a whole in this case
18:19:14 <brunowolff> Am I confusing the rules for sec arches with sec desktops?
18:19:36 <tflink> brunowolff: if you are, you're not the only one :)
18:19:37 <adamw> i think this should just be marked as blocking F16Betas390x
18:19:43 <adamw> brunowolff: tflink: i believe you are, yes
18:20:01 <Viking-Ice> ack on blocking F16Betas390x
18:20:36 <Viking-Ice> ( personally I dont think we should be making distinction between arches )
18:20:41 <tflink> proposed #agreed - 733680 - RejectedNTH - This is a secondary arch bug and should block F16Betas390x instead
18:21:34 <adamw> Viking-Ice: well, that's way above qa's pay grade.
18:22:48 <adamw> ack
18:22:51 <Viking-Ice> ack
18:22:57 <tflink> #agreed - 733680 - RejectedNTH - This is a secondary arch bug and should block F16Betas390x instead
18:23:11 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735437
18:23:12 <buggbot> Bug 735437: urgent, unspecified, ---, kernel-maint, MODIFIED, Kernel stops working since version 2.6.40-x | kernel BUG at drivers/media/media-entity.c:346!
18:23:21 <tflink> #info Kernel stops working since version 2.6.40-x | kernel BUG at drivers/media/media-entity.c:346!
18:24:13 <adamw> so this one just makes it impossible to boot on affected hardware
18:24:22 <brunowolff> Isn't that an F15 kernel?
18:24:29 <adamw> it affects f16 too
18:24:37 <Viking-Ice> rc5 ?
18:24:48 <adamw> rc5 should be fixed
18:24:58 <Viking-Ice> rc5 is what kernel team wants in beta
18:25:04 <adamw> yeah
18:25:12 <Viking-Ice> so problem solved it self ;)
18:25:14 <adamw> so, i'm +1 nth for this obviously
18:25:20 <Viking-Ice> +1 nth
18:25:39 <tflink> +1 nth (even though we have a F15 bug as NTH on F16)
18:25:41 <brunowolff> +1 nth
18:25:57 <adamw> tflink: one day bugzilla will handle multiple affected distros safely.
18:26:07 <adamw> on that same day, unicorns will fly out the pope's ass.
18:26:14 <adamw> s/safely/sanely/
18:26:30 <tflink> proposed #agreed - 735437 - AcceptedNTH - causes non-bootable systems
18:26:33 <adamw> ack
18:26:36 <brunowolff> ack
18:26:48 <tflink> #agreed - 735437 - AcceptedNTH - causes non-bootable systems
18:27:16 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=694639
18:27:17 <buggbot> Bug 694639: medium, urgent, rc, psabata, VERIFIED, lldpad has frequent timeouts on selects
18:27:29 <tflink> #info lldpad has frequent timeouts on selects
18:27:36 <adamw> this is the 'lldpad sucks my cpu!' bug
18:27:48 <tflink> and RHEL6
18:27:55 <adamw> as things stand this affects all live boots and installs from live, as lldpad is pulled into the live image package set
18:28:07 <adamw> oh, yeah.
18:28:17 <adamw> the wrong bug may have been proposed...
18:28:20 <adamw> i think there's a fedora bug
18:28:22 <tflink> we should probably clone this before accepting
18:28:27 <tflink> unless there is a fedora bug
18:28:44 <tflink> which would also explain the access denied on the next proposed NTH
18:28:50 <adamw> yeah, https://bugzilla.redhat.com/show_bug.cgi?id=701943 is the fedora bug
18:28:51 <buggbot> Bug 701943: medium, unspecified, ---, psabata, ON_QA, lldpad has frequent timeouts on selects
18:29:09 <Viking-Ice> aparently there is a fix upstream
18:29:18 <adamw> ah
18:29:21 <adamw> this is in through deps
18:29:25 <Viking-Ice> according to the rhel bug
18:29:26 <adamw> it's marked as blocking the fedora bug
18:29:37 <adamw> which is wrong, as there's no reason it needs to be fixed in rhel before being fixed in fedora
18:29:41 <tflink> #agreed 694639, 695943 - RejectedNTH, were not supposed to be reported as blockers since the're RHEL bugs
18:29:42 <adamw> probably a hangover from a clone
18:30:14 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=701943
18:30:15 <buggbot> Bug 701943: medium, unspecified, ---, psabata, ON_QA, lldpad has frequent timeouts on selects
18:30:25 <tflink> #info lldpad has frequent timeouts on selects
18:30:29 <Viking-Ice> +1 on nth
18:30:37 <Viking-Ice> i'm not sure this hit's any criteria
18:31:05 <adamw> no, we don't really have criteria for performance niggles
18:31:12 <adamw> but it's clearly NTH as we can't fix the lives with updates
18:31:15 <tflink> proposed #agreed - 701943 - AcceptedNTH - Doesn't hit any criteria but is a performance issue
18:31:21 <Viking-Ice> ack
18:31:38 <tflink> proposed #agreed - 701943 - AcceptedNTH - Doesn't hit any criteria but is a performance issue and affects live images which can't be fixed by updates.
18:31:44 <brunowolff> Well it affects live images, and I thought there was something about not easy to fix in update bugs. Though this would be more of a final, than beta thing.
18:31:54 <adamw> brunowolff: that's the NTH principle.
18:32:00 <adamw> ack
18:32:11 <tflink> #agreed - 701943 - AcceptedNTH - Doesn't hit any criteria but is a performance issue and affects live images which can't be fixed by updates.
18:32:33 <tflink> brunowolff: I can #undo if you disagree
18:32:44 <brunowolff> I agree with nth.
18:32:48 <tflink> ok
18:32:49 <jwb> apologize for being late.  aside from 735437, have there been any kernel bugs discussed?
18:32:52 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=733808
18:32:53 <buggbot> Bug 733808: high, unspecified, ---, tcallawa, ON_QA, Installer shrink function fails when asked to shrink an NTFS Partition
18:33:01 <tflink> #info Installer shrink function fails when asked to shrink an NTFS Partition
18:33:03 <brunowolff> I was a bit behind typing while new stuff was being said.
18:33:10 <tflink> haven't we already seen this one?
18:33:24 <brunowolff> I seem to remember it from last week.
18:33:29 <Viking-Ice> discussed while back both in irc and I think on the list
18:33:29 <adamw> sec
18:34:18 <adamw> 19:28:13 <tflink> #agreed 733808 - AcceptedNTH - Resizing partitions isn't supported but a small, tested fix would be accepted during freeze if it came to that
18:34:20 <adamw> that's from last week
18:34:21 <Viking-Ice> atleast I recall something mentioning wording on the criteria it should be shrink filesystem test not os test
18:34:24 <adamw> so, we just didn't update it
18:34:25 <adamw> will do
18:34:50 <tflink> #undo
18:34:50 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x10f67dac>
18:34:52 <tflink> #undo
18:34:52 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xe684c6c>
18:35:02 <Viking-Ice> jwb, discussed one I believe that is fixed with rc5
18:35:16 <tflink> I think that https://bugzilla.redhat.com/show_bug.cgi?id=734169 was also discussed last week
18:35:17 <buggbot> Bug 734169: unspecified, unspecified, ---, pjones, NEW, Updated syslinux theme for Fedora 16
18:35:36 <tflink> I can't remember what we decided to do about it, though
18:35:41 <Viking-Ice> jwb, 735437
18:35:46 <tflink> this is the "updated syslinux" tracker
18:35:47 <adamw> jwb: right, nothing else has come up. though i'm worried about this sluggish graphics performance with 3.1 kernels that's being discussed on test list. we should keep that out of the meeting thugh
18:35:56 <adamw> tflink: we accepted it
18:36:07 * Viking-Ice points out that hes hit with that sluggish performance
18:36:13 <adamw> oh wait
18:36:14 <jwb> Viking-Ice, yeah, that's the one i said "aside from ..."
18:36:17 <jwb> but thank you
18:36:20 <adamw> 19:01:40 <tflink> #agreed - 734169 - RejectedNTH - this is a tracker bug, will evaluate dependencies on their own
18:36:24 <adamw> we agreed to leave it alone as it's a tracker
18:36:35 <adamw> but actually that'll mean it keeps coming up, so we should mark it as accepted.
18:36:37 <tflink> yeah, that's what I was remembering
18:36:43 * adamw sucks
18:36:53 <jwb> adamw, see comment in 735268 for the sluggish thing
18:37:00 <tflink> adamw: you updating those or should I #action myself?
18:37:27 <adamw> tflink: i'm doing them
18:37:32 <tflink> ok, cool
18:38:34 <tflink> I'm only seeing the one accepted blocker that's beyond modified
18:38:46 <tflink> IIRC, we have a lot of verification to do
18:38:58 <tflink> at least when I went through that list on my own yesterday
18:38:59 <adamw> yeah
18:39:06 <adamw> we should look at accepted blockers that aren't modified
18:39:20 <adamw> i've been iterating over the list and a lot of it is just 'test with tc2 and confirm this is fixed'
18:39:31 <adamw> we should try and knock some of those off todayt
18:39:32 * Viking-Ice needs a nikotine break and a fresh cup of coffee
18:39:45 <adamw> 5 minute break before we go on to acceptedblockers?
18:39:58 <tflink> we only have 4 non-modified
18:40:14 <tflink> unless we want to go through them all, I'm for just getting it done now
18:40:21 * tflink won't fight a break, though
18:40:44 <brunowolff> I had a proposed NTH that I didn't see covered yet.
18:40:55 <adamw> okay, if it's just a few, let's carry on
18:40:58 <adamw> brunowolff: what's that?
18:41:25 <brunowolff> https://bugzilla.redhat.com/show_bug.cgi?id=737076
18:41:26 <buggbot> Bug 737076: unspecified, unspecified, ---, kernel-maint, NEW, Use after free issue in raid 1 driver
18:41:50 <tflink> brunowolff: that's marked as final NTH
18:42:11 <brunowolff> Because you normally a some hours before a crash and only few people will be using raid 1, I am not sure we want this as NTH.
18:42:33 <adamw> can it be fixed with an update?
18:42:39 <brunowolff> Hopefully it will be moot and the fix will be in before the freeze. But with the kernel.org mess it might not.
18:43:21 <jwb> i'm not entirely comfortable including the patch attached to the bug.  there isn't much we can do but wait for neil's patch to actually get into some tree somewhere
18:43:21 <brunowolff> It can be fixed in an update. In theory it might affect an install.
18:44:23 <tflink> put it off until we hit final, then?
18:44:32 <adamw> i think i'd be -1 on balance right now
18:44:49 <brunowolff> That's OK with me, I just wanted to run it by people as it was kind of borderline.
18:44:53 <adamw> yeah...
18:45:14 <tflink> OK, we'll leave it alone for now then
18:45:18 <tflink> brunowolff: thanks for bringing it up
18:45:24 <brunowolff> I have my machines fixed, so it isn't giving me grief now.
18:45:43 <tflink> 4 acceptedBlockers left
18:45:47 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=734791
18:45:48 <buggbot> Bug 734791: unspecified, unspecified, ---, dennis, NEW, Checksum files for Live have wrong name
18:45:55 <tflink> #info Checksum files for Live have wrong name
18:46:02 <adamw> so, seems like confusion reigns here.
18:46:26 <adamw> and i'm kinda of the opinion we should punt the whole mess over to releng. but as i recall, it's actually the case that we intend TC releases to have TC in the file names.
18:47:11 <tflink> yeah, I'm of similar mind
18:47:19 <adamw> it doesn't really strike me as a critical issue; wrong names in an RC would be
18:47:34 <adamw> bad torrent files would seem to be more worrying, but the bug isn't about those
18:48:31 <adamw> so...i'd say this bug as described is fixed in TC2
18:48:42 <adamw> as for TC2, the checksum file and image file names match
18:48:50 <adamw> whether they're 'right' or not, the biggest issue is that they should match
18:49:00 <adamw> i think we can close and ask andre to open new bugs for future problems
18:49:19 <tflink> proposed #agreed - 734791 - the checksum and image file names match, can close
18:49:45 <adamw> ack
18:50:06 <tflink> #agreed - 734791 - the checksum and image file names match, can close
18:50:16 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=718722
18:50:17 <buggbot> Bug 718722: unspecified, unspecified, ---, pjones, NEW, Mismatched or corrupt version of stage1/stage2
18:50:24 <tflink> #info Mismatched or corrupt version of stage1/stage2
18:51:08 <tflink> this seems to have stalled
18:51:13 <tflink> but no repros for a while, either
18:52:01 <adamw> there was some discussion of this one on #anaconda yesterday, i think
18:52:03 <adamw> trying to remember the context
18:52:44 <tflink> I'd say ask for updates and leave it for now
18:52:59 <tflink> is it still an issue? has the path forward been decided?
18:53:00 <adamw> #anaconda.09.log:09-09-2011 08:20:42 < dgilmore!~dgilmore@fedora/dgilmore: https://bugzilla.redhat.com/show_bug.cgi?id=718722 im hitting that bug trying to make ec images
18:53:01 <buggbot> Bug 718722: unspecified, unspecified, ---, pjones, NEW, Mismatched or corrupt version of stage1/stage2
18:53:15 <adamw> so, it seems to be impeding ec2 images. somehow. not entirely sure how.
18:53:44 <brunowolff> I thought the rolled back versions of grub were put out there. So I don't expect people to have problems with this, even though there is still an underlying problem.
18:53:47 <tflink> not sure, there haven't been any updates on the rel-eng ticket
18:53:57 <adamw> i think maybe add a needinfo
18:54:06 <adamw> brunowolff: rolled back versions...of what?
18:54:17 <tflink> I'll bring it up in the cloud sig meeting
18:54:23 <adamw> grub's up to grub-0.97-77.fc16.x86_64 now
18:54:24 <brunowolff> grub built with the older compiler.
18:54:50 <brunowolff> I thought I originally hit this with updates-testing in F15.
18:55:03 <adamw> so..maybe this will come up again now there's been a grub update?
18:55:03 <tflink> it surprises me that this is an issue, boxgrinder doesn't have a problem with it and I thought that they both used the same base tools
18:55:24 <brunowolff> I don't remeber if it made it to updates and then was further updated or if the update was dropped.
18:55:41 <tflink> either way, we need more info
18:55:44 <adamw> yeah
18:55:50 <adamw> let's throw a needinfo and some ccs in there...
18:55:53 <tflink> needinfo on dgilmore?
18:55:56 <adamw> yeah
18:55:58 <brunowolff> Though I haven't done a grub-install in a while.
18:56:48 <tflink> proposed #agreed - 718722 - we need more information on this. Supposedly its blocking EC2 composes and there haven't been updates for a while.
18:56:51 <brunowolff> I noticed it because I redid my disk partition layout on a mirrored system and needed to do a grub-install as part of that.
18:57:02 <tflink> #action tflink bring up 718722 in the cloudSIG meeting
18:57:41 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=734845
18:57:42 <buggbot> Bug 734845: unspecified, unspecified, ---, dennis, NEW, repoclosure failure in 16-Beta.TC1 DVDs
18:57:51 <tflink> #info repoclosure failure in 16-Beta.TC1 DVDs
18:57:54 <adamw> uh
18:58:02 <adamw> you didn't do the #agreed on the last one
18:58:06 <adamw> only proposed it
18:58:08 <tflink> #undo
18:58:08 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1859f22c>
18:58:10 <tflink> #undo
18:58:10 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x13410bac>
18:58:16 <tflink> #agreed - 718722 - we need more information on this. Supposedly its blocking EC2 composes and there haven't been updates for a while.
18:58:19 <tflink> thanks
18:58:24 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=734845
18:58:25 <buggbot> Bug 734845: unspecified, unspecified, ---, dennis, NEW, repoclosure failure in 16-Beta.TC1 DVDs
18:58:27 <tflink> #info repoclosure failure in 16-Beta.TC1 DVDs
18:59:25 <tflink> it sounds like we're ok on this one for now
18:59:48 <tflink> proposed #agreed - 734845 - No action needed, seems to be progressing well for now
19:00:26 <tflink> only one more after this
19:00:30 <tflink> we're almost done!
19:00:56 * tflink is about to take the initiative here
19:01:12 <tflink> #agreed - 734845 - No action needed, seems to be progressing well for now
19:01:23 <tflink> #topic https://bugzilla.redhat.com/show_bug.cgi?id=735016
19:01:24 <buggbot> Bug 735016: unspecified, unspecified, ---, hughsient, NEW, reboot halts after preupgrade
19:01:31 <tflink> #info reboot halts after preupgrade
19:01:54 <adamw> well, we should re-test 734845 against tc2.
19:02:00 <adamw> robatino will no doubt do that.
19:02:43 <adamw> we're waiting on hughsie to look at this one, seems like.
19:03:05 <tflink> sorry, cloud sig is talking about EC2
19:04:07 <adamw> i think all this needs is a ping-with-sharp-edges
19:04:50 <tflink> proposed #agreed 718722 - needs poking
19:05:04 <adamw> ack
19:05:36 <tflink> #agreed 718722 - needs poking
19:05:41 <tflink> ok, I think we're done!
19:05:48 <tflink> #topic open floor
19:05:59 <tflink> anything that should be covered?
19:06:15 <adamw> can't think of anything
19:06:28 <adamw> just everyone please focus on tc2 testing and confirming fixes of modified blockers
19:06:59 <tflink> think it's worth the effort to send out a request to start verifiying fixes?
19:07:14 <adamw> sure, it's worth your effort!
19:07:15 <adamw> :P
19:07:38 <tflink> so that's how it works
19:07:40 <tflink> I see
19:07:51 <tflink> anyhow, I don't think we need to be covering this in meetbot
19:07:58 <tflink> fuse is set for 1 minute
19:08:20 <tflink> #info next meeting will be next Friday 2011-09-16 at 17:00 UTC
19:08:26 <tflink> same bat time, same bat channel
19:09:11 <tflink> ok, thanks for coming everyone!
19:09:14 <tflink> Testing Time!
19:09:20 <tflink> #endmeeting