16:40:43 <tflink> #startmeeting f18final-blocker-review-5
16:40:43 <zodbot> Meeting started Mon Dec 17 16:40:43 2012 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:40:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:40:44 <tflink> #meetingname f18final-blocker-review-5
16:40:44 <zodbot> The meeting name has been set to 'f18final-blocker-review-5'
16:40:44 <tflink> #topic Roll Call
16:41:23 <tflink> who's ready for our now-daily blocker review fun time?
16:41:29 <tflink> #chair adamw kparal
16:41:29 <zodbot> Current chairs: adamw kparal tflink
16:41:31 * jreznik is here
16:41:43 <adamw> fun...levels...critical
16:42:18 * tflink goes to get some plastic sheets in case adamw explodes
16:43:13 * kparal here
16:43:35 * nirik is lurking, but busy... ping if I can help with anything.
16:44:15 * mkrizek is here
16:44:19 * pschindl is here
16:44:33 * satellit_e listening
16:46:23 <tflink> so. many. bugs.
16:46:42 <tflink> anyhow, let's get started. I think we have enough people
16:46:53 <tflink> #topic Introduction
16:46:58 <tflink> Why are we here?
16:46:58 <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.
16:47:04 <tflink> #info We'll be following the process outlined at:
16:47:05 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:47:10 <tflink> #info The bugs up for review today are available at:
16:47:10 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:47:17 <tflink> #info The criteria for release blocking bugs can be found at:
16:47:17 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
16:47:17 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
16:47:17 <tflink> #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
16:47:58 <tflink> #info 22 Proposed Blockers
16:47:58 <tflink> #info 12 Accepted Blockers
16:47:58 <tflink> #info 38 Proposed NTH
16:47:58 <tflink> #info 9 Accepted NTH
16:47:59 <tflink> #info 13 Proposed Blockers marked Ready for Discussion
16:48:30 <tflink> and actually, 1 NTH which should probably be a blocker
16:48:55 <tflink> unless there are objections, I'm planning to go through the blockers ready for discussion before moving on to NTH
16:49:29 <adamw> works for me
16:49:38 <tflink> #topic (883075) fedup upgrading is too quiet
16:49:38 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=883075
16:49:38 <tflink> #info Proposed Blocker, fedup-dracut, ASSIGNED
16:49:39 <bugbot_> Bug 883075: low, unspecified, ---, wwoods, ASSIGNED , fedup upgrading is too quiet
16:50:21 <tflink> the idea here was to get one bug as a blocker that covered what we considered blocking for F18 upgrades
16:50:42 <tflink> instead of getting too far into the details of either plymouth or systemd (depending on which method we're talking about)
16:50:53 <adamw> sounds good
16:51:01 <jreznik> so it goes well with  879295
16:51:04 <tflink> c#3 sums up my current understanding better
16:51:06 <adamw> i think we were solidly +1 blocker on the general idea that we needed some kind of feedback from upgrading
16:51:08 <adamw> so +1
16:51:12 <kparal> +1
16:51:13 <tflink> +1
16:51:21 <mkrizek> +1
16:51:27 <jreznik> adamw: well, which bug? this one or the plymouth one to take as a blocker?
16:51:49 <kparal> jreznik: this one is a generic one "fix something to provide details"
16:51:52 <nanonyme> hmm, am I eligible for voting here? ;) +1 for this one
16:51:59 <adamw> this one. the point is to take this one so we don't wind up specifically blocking on plymouth or systemd.
16:52:03 <jreznik> kparal: ok, +1
16:52:16 <adamw> nanonyme: anyone can vote, all votes are weighed by a highly complex and subtle algorithm
16:52:21 <nanonyme> hehe
16:52:29 <tflink> adamw: they are?
16:52:37 <adamw> tflink: yes. they are. get to work on it.
16:52:37 <kparal> nanonyme: also called "adam's decision"
16:52:47 <tflink> but skynet's not done yet
16:52:58 * jreznik thought adamw is instance of skynet
16:53:11 * fenrus02 lulz .. skynet blocked.
16:53:16 <adamw> phase plasma rifle in forty watt range
16:53:30 <tflink> proposed #agreed 883075 - AcceptedBlocker - Violates the following F18 final release criteria in spirit due to lack of user-facing progress information: "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 all officially recommended upgrade mechanisms..."
16:53:40 <kparal> ack
16:53:43 <jreznik> ack
16:53:53 <fenrus02> ack
16:53:54 <adamw> ack
16:53:56 <mkrizek> ack
16:54:00 <tflink> #agreed 883075 - AcceptedBlocker - Violates the following F18 final release criteria in spirit due to lack of user-facing progress information: "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 all officially recommended upgrade mechanisms..."
16:54:06 <tflink> #topic (887236) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 3: ordinal not in range(128)
16:54:09 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887236
16:54:11 <bugbot_> Bug 887236: unspecified, unspecified, ---, anaconda-maint-list, NEW , UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 3: ordinal not in range(128)
16:54:12 <tflink> #info Proposed Blocker, anaconda, NEW
16:54:51 <kparal> funny
16:54:52 <kparal> +1
16:54:59 <tflink> this sounds to me like installation in several non-english languages doesn't work well
16:55:08 <tflink> kparal: funny how?
16:55:14 <kparal> tflink: doesn't work at all
16:55:23 <fenrus02> that was lang= en_us
16:55:27 <kparal> "This exception occurs before the Installation Summary is displayed."
16:55:29 <adamw> 'doesn't work well' in the sense of 'crashes entirely'
16:55:31 <adamw> :P
16:55:37 <nanonyme> ascii? seriously? +1
16:55:42 <adamw> fenrus02: huh?
16:56:09 <fenrus02> oh, i see.  top says en_US, c9 says other langs .. including g8 .. +1 block
16:56:16 <tflink> nanonyme: it's not all that hard to hit ascii errors in python w/ non-roman alphabets
16:56:26 <kparal> nanonyme: python2 has pretty poor defaults when it comes to unicode
16:56:36 <adamw> so +1.
16:56:39 <nanonyme> tflink, yeah, imo we should just use UTF-8 for *everything*
16:56:43 <mkrizek> +1
16:57:00 <jreznik> +1 and ask anaconda team to rewrite it to c++ :)
16:57:06 <nanonyme> (ie en_US.UTF-8 instead of en_US and so)
16:57:09 <fenrus02> jreznik, WIN
16:57:19 <tflink> proposed #agreed 887236 - AcceptedBlocker - Violates the following F18 final release criterion for several well-used non-english languages: "The installer must be able to complete an installation using all supported interfaces"
16:57:25 <kparal> ack
16:57:28 <fenrus02> ack
16:57:48 <adamw> ack
16:57:50 <mkrizek> ack
16:57:51 <pschindl> ack
16:57:58 <tflink> #agreed 887236 - AcceptedBlocker - Violates the following F18 final release criterion for several well-used non-english languages: "The installer must be able to complete an installation using all supported interfaces"
16:58:02 <tflink> #topic (886502) create grub.cfg even when not installing bootloader
16:58:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886502
16:58:06 <bugbot_> Bug 886502: high, unspecified, ---, anaconda-maint-list, NEW , create grub.cfg even when not installing bootloader
16:58:07 <tflink> #info Proposed Blocker, anaconda, NEW
16:58:35 <cmurf> -1 blocker, +1 nth
16:58:59 <fenrus02> i dont see this as a blocker really.
16:59:05 <tflink> yeah, I'm thinking similarly: +1/-1
16:59:07 <fenrus02> -1 block, +1 nth
16:59:09 <tflink> whoops
16:59:13 <tflink> I meant -1/+1
16:59:20 <jreznik> tflink: ! :)
16:59:25 <jsmith> -1/+1 from me
16:59:25 <jreznik> -1/+1
16:59:38 <mkrizek> -1 blocker
16:59:39 <adamw> -1/+1 , not sure why this was proposed blocker
16:59:55 <fenrus02> adamw, inherited tag from the looks of it?
17:00:02 <cmurf> aksident
17:00:12 <cmurf> yeah probably
17:00:13 <kparal> -1/+1
17:00:33 <adamw> yeah.
17:00:35 <tflink> proposed #agreed 886502 - RejectedBlocker AcceptedNTH - This doesn't clearly violate any F18 release criteria but it would be good to verify that the files exist during install w/o bootloader and can't be fixed with a post-release update. A tested fix would be considered past freeze.
17:00:44 <kparal> ack
17:00:46 <mkrizek> ack
17:00:47 <adamw> patch
17:00:47 <fenrus02> ack
17:00:55 <adamw> don't like that 'verify'
17:00:55 <jreznik> ack
17:01:16 <tflink> adamw: suggestions?
17:01:20 <jsmith> adamw: How would you change it?
17:01:30 <adamw> This doesn't violate any F18 release criteria but it would help multibooters to generate the config during install w/o bootloader and can't be fixed with a post-release update. A tested fix would be considered past freeze.
17:01:31 <tflink> ensure?
17:01:35 <cmurf> "be good to create the files during install"
17:01:38 <fenrus02> "but it would be nice to ensure the files exist" ?
17:01:52 <adamw> sigh
17:01:52 <cmurf> well they need to be created first
17:02:02 <adamw> This doesn't violate any F18 release criteria but it would help multibooters if we generate the config file during install w/o bootloader and can't be fixed with a post-release update. A tested fix would be considered past freeze.
17:02:12 <adamw> cmurf: that's what it means.
17:02:20 <fenrus02> adamw, +1
17:02:31 <jsmith> WORKSFORME
17:02:40 <tflink> proposed #agreed 886502 - RejectedBlocker AcceptedNTH - This doesn't clearly violate any F18 release criteria but it would help multibooters if we generate the config during install w/o bootloader and this can't be fixed with a post-release update. A tested fix would be considered past freeze.
17:02:50 <adamw> ack
17:02:52 <cmurf> ack
17:02:52 <jsmith> ACK
17:02:55 <pschindl> ack
17:03:02 <tflink> #agreed 886502 - RejectedBlocker AcceptedNTH - This doesn't clearly violate any F18 release criteria but it would help multibooters if we generate the config during install w/o bootloader and this can't be fixed with a post-release update. A tested fix would be considered past freeze.
17:03:08 <tflink> #topic (869841) attempts to resize ufs partitions
17:03:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=869841
17:03:08 <tflink> #info Proposed Blocker, anaconda, POST
17:03:10 <bugbot_> Bug 869841: unspecified, unspecified, ---, dlehman, POST , attempts to resize ufs partitions
17:03:53 * jreznik is waiting for bz...
17:03:59 <tflink> same here
17:04:07 * cmurf did think it was possible for the bz to get any slower than last week...
17:04:26 <fenrus02> tflink's c21 sums it up nicely imho
17:04:49 <jreznik> we could just throw dice to see blocker bug status in case bz does not work
17:05:03 <adamw> my dice came up 7.8
17:05:06 <adamw> what does that mean?
17:05:13 <cmurf> jreznik: i think this is a way better idea than daily reviews!
17:05:17 <fenrus02> "The installer's custom partitioning mode must be capable of the following ...  Rejecting obviously invalid operations without crashing."
17:05:26 <cmurf> cute, a proxy error
17:05:28 <tflink> ooh, proxy error
17:05:40 * jsmith got the proxy error as well
17:05:53 <tflink> this meeting might have been cut short :-/
17:06:02 <tflink> lets wait a bit before calling it, though
17:06:16 * cmurf has one die handy for rolls
17:06:31 * adamw goes to yell at someone
17:06:33 * tflink doesn't see any scheduled downtime for right now
17:06:52 <fenrus02> $ echo $[RANDOM%6]
17:06:52 <fenrus02> 5
17:07:18 <cmurf> what is comment 21? can someone who has access post it?
17:07:27 <fenrus02> cmurf, sure, moment
17:07:47 <fenrus02> http://www.fpaste.org/tRNH/raw/
17:07:48 <cmurf> UFS is not resizeable is it?
17:08:02 <fenrus02> cmurf, no, but anaconda is marking it as if it can
17:08:07 <adamw> hrm
17:08:08 <cmurf> +1 blocker
17:08:19 <adamw> still, how often are these going to be around?
17:08:20 <cmurf> based on beta criterion
17:08:25 <adamw> and how terrible is this really?
17:08:28 <fenrus02> adamw, bsd?  any mac
17:08:36 <adamw> true, i guess
17:08:40 <cmurf> OS X has not used UFS in eons
17:08:46 <tflink> max isn't UFS
17:08:48 <adamw> i'm not sure it'd pass the go/no-go smell test
17:08:50 <fenrus02> oh, n/m then.
17:08:55 <cmurf> but it is default for FreeBSD
17:09:10 <tflink> there was a report involving BTRFS as well
17:09:14 <cmurf> possibly OpenBSD
17:09:32 <cmurf> btrfs can be resized up or down
17:09:48 <cmurf> In any case, the installer shouldn't crash so I'm still +1 blocker
17:10:01 <fenrus02> cmurf, resizing btrfs is not what causes alarm on that bz imho.  resizing some $unknown fs is.
17:10:36 <cmurf> if it doesn't support resizing it would fail, and presuambly the failure is what causes the crash
17:10:53 <adamw> right, i'm assuming it doesn't nerf any data
17:10:57 <fenrus02> _nod_  and should bail gracefully without a crash
17:11:05 <tflink> yeah, it just tries to resize FS that it doesn't know how to resize and crashes
17:12:05 <cmurf> i'm assuming it would be difficult to nerf data since anaconda calls fs specific resize commands
17:12:43 <adamw> right.
17:12:54 <cmurf> so there are two bugs in a way, 1 the misidentification of a non-resizable fs, and 2 the crash.
17:12:57 <jreznik> it should not crash but it's not blocker worthy, I'd say
17:13:09 <jreznik> cmurf: yep
17:13:23 <jreznik> and 1) would probably solve 2)
17:13:31 <cmurf> jreznik: i agree it's not blocker worthy except for the release criterion says no crashing
17:13:54 <cmurf> actually funny enough the no crashing policy is for custom partitioning isn't it
17:14:10 <cmurf> is this bug happening in "guided" or "custom"
17:14:56 <tflink> and now we're at 503s
17:16:31 <tflink> back up for me
17:16:36 <adamw> cmurf: we should probably adjust the criterion
17:16:44 <adamw> i'm still supposed to be revising the partitioning criteria, but enotime
17:16:47 <adamw> oh yay.
17:16:58 <tflink> and faster than usual
17:17:24 <cmurf> tflink: not for me it's still hung up
17:17:35 <adamw> i think you just caught a reset
17:17:52 <cmurf> Got it
17:18:03 <cmurf> based on the initial entry it's clear this is the guided path
17:18:03 <cmurf> not custom
17:18:05 <cmurf> -1 blocker
17:18:12 * jreznik is reading bz
17:19:01 <adamw> i wouldn't -1 just because the criterion says 'custom', we should probably read it as applying to guided too. but i'm not sure this is serious enough to block on
17:19:49 <cmurf> based on c20 i'd be surprised if a fix isn't already on the way
17:20:31 <cmurf> ok so -1 blocker, +1 nth
17:21:01 <adamw> -1/+1
17:21:04 <kparal> the important question is when it crashes - before it touches disk or after?
17:21:23 <jreznik> kparal: it was answere I'd say
17:21:34 <adamw> well, it could happen after other operations, i guess
17:21:42 <tflink> kparal: I assume that would depend on the order in which things are done
17:21:47 <adamw> but still, is that so terrible? you can just reboot and redo
17:22:00 <adamw> well, maybe if the fs isn't resizeable at all you'd be stuck...m
17:23:32 <adamw> just got a refresh out of bugzilla...
17:23:50 <kparal> or let's ask differently - can it make my other OS unbootable and fail to install?
17:23:50 <tflink> same here
17:24:11 <cmurf> ok so here we
17:24:13 <cmurf> oops
17:24:21 <tflink> kparal: it doesn't sound like that to me but I'm probably not the best person to aswer that :)
17:24:23 <cmurf> the storage.log indicates changes have been made to the disk
17:25:07 <kparal> executing action: [7] Destroy Format msdos disklabel on disk sdb (id 6)
17:25:17 <tflink> sure, but I think kparal's question ends up being the important one
17:26:23 <cmurf> since new anaconda is so threaded, what are the chances the crash happens when repartitioning is occurring?
17:26:28 <adamw> well i mean it's theoretically possible
17:26:29 <kparal> if it can have adverse affect on my other OS, just because it didn't understand the file format, that could be a blocker. otherwise just nth is fine
17:26:42 <kparal> *effect
17:26:52 <cmurf> even if the mistaken resize doesn't happen, if the partition map is corrupt, then the prior system may not be bootable
17:26:53 <adamw> if you plan an install that wipes one OS, resizes another, and installs fedora in the space, then the OS set for wipe would get wiped...but I can't think of a less weird scenario
17:27:12 <adamw> i can't see why you'd have an existing OS and resize one of its partitions but destroy another
17:27:18 <adamw> i may be missing a case though.
17:27:46 <tflink> it sounds like we're broadly -1/+1
17:27:52 <kparal> probably
17:28:15 * jreznik agrees
17:28:27 <jsmith> -1/+1 from me
17:28:31 <adamw> yeah
17:28:41 <adamw> if someone comes up with a more plausible data destruction scenario i'd change vote, but -1/+1 for now
17:28:50 <kparal> of course it would be nice to add a comment and ask dlehman to raise this issue again if there are some important use cases we overlooked
17:28:52 <cmurf> -1/+1 with escalation for a data loss case
17:29:06 <cmurf> kparal: agreed
17:29:08 <jsmith> kparal: +1
17:29:17 <tflink> proposed #agreed 869841 - RejectedBlocker AcceptedNTH - While this is a technical violation of the release criteria, it seems to be a bit too much of a corner case to justify blocking release for. However, it can
17:29:22 <tflink> hit enter early
17:29:37 <jreznik> "it can hit enter early" /me reads
17:29:40 <tflink> proposed #agreed 869841 - RejectedBlocker AcceptedNTH - While this is a technical violation of the release criteria, it seems to be a bit too much of a corner case to justify blocking release for. However, it can't be fixed with an update post-release and a tested fix would be considered past freeze
17:29:52 <jreznik> ack
17:29:58 <cmurf> ack
17:30:15 <kparal> ack
17:30:34 <mkrizek> ack
17:30:38 <adamw> ack
17:30:39 <tflink> #agreed 869841 - RejectedBlocker AcceptedNTH - While this is a technical violation of the release criteria, it seems to be a bit too much of a corner case to justify blocking release for. However, it can't be fixed with an update post-release and a tested fix would be considered past freeze
17:30:52 <tflink> #topic (875944) Shrink function in 'Reclaim space' dialog does not allow user to specify target size, automatically picks smallest possible size
17:30:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875944
17:30:56 <bugbot_> Bug 875944: unspecified, unspecified, ---, anaconda-maint-list, NEW , Shrink function in 'Reclaim space' dialog does not allow user to specify target size, automatically picks smallest possible size
17:30:57 <tflink> #info Proposed Blocker, anaconda, NEW
17:31:15 <cmurf> this is icky
17:32:01 <cmurf> +1 block. it needs to be fixed or removed. the resulting original OS whose fs was resized is now so small as to be functionally useless.
17:32:37 <kparal> I'm +1 here, even though it's a more design problem than buggy code. shrink needs to ask how much or be available only in manual partitioning mode
17:33:01 <adamw> it's a design flaw, yeah.
17:33:10 <jsmith> I'm +1 here as well
17:33:23 <adamw> +1 blocker per my rationale in the bug
17:33:31 <mkrizek> +1 blocker
17:33:44 <adamw> we usually don't take resize bugs as blockers, but that's more for the 'the resize attempt failed for X reason' case than 'our resize interface is fundamentally stupid'
17:34:06 <tflink> criterion thoughts? I'm not sure the windows one is best here
17:34:31 <kparal> it's a good one. it makes windows essentially unusable
17:34:50 <kparal> it's not what users expect from this function
17:35:01 <adamw> we don't really have any other criteria relating to other OSes unfortunately
17:35:08 <adamw> using the partitioning criteria would be just as much of a wiggle
17:35:34 <jsmith> While I don't have the criteria memorized, I think it's an obvious example of not playing nice with co-located OSes
17:36:09 <jsmith> And isn't that what this meeting is for -- to make sure the "spirit of the law" and the "letter of the law" somehow jive?
17:36:16 <tflink> proposed #agreed 875944 - AcceptedBlocker - Violates the following F18 final release criteria by making other installed OSs so small, they are practically unusable after a relatively short time: "#topic (875944) Shrink function in 'Reclaim space' dialog does not allow user to specify target size, automatically picks smallest possible size
17:36:22 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=875944
17:36:23 <bugbot_> Bug 875944: unspecified, unspecified, ---, anaconda-maint-list, NEW , Shrink function in 'Reclaim space' dialog does not allow user to specify target size, automatically picks smallest possible size
17:36:24 <tflink> #undo
17:36:24 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x142391d0>
17:36:26 <tflink> #undo
17:36:26 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x22183290>
17:36:28 <tflink> #info Proposed Blocker, anaconda, NEW
17:36:30 <tflink> damn it
17:36:45 * adamw plays muzak
17:36:52 <adamw> we are experiencing technical difficulties, please do not adjust your set
17:37:04 <tflink> proposed #agreed 875944 - AcceptedBlocker - Violates the following F18 final release criteria by making other installed OSs so small, they are practically unusable after a relatively short time: "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working"
17:37:10 <tflink> and that would be too long
17:37:18 <kparal> tflink: nope
17:37:22 <cmurf> ive got closed quotes
17:37:30 <kparal> ack
17:37:33 <cmurf> ack
17:37:36 <adamw> ack
17:37:45 <adamw> it's an acceptable wiggle by our current lax standards =)
17:37:49 <tflink> #agreed 875944 - AcceptedBlocker - Violates the following F18 final release criteria by making other installed OSs so small, they are practically unusable after a relatively short time: "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working"
17:37:50 <jreznik> ack
17:37:52 <mkrizek> ack
17:37:54 <kparal> maybe we should mention removing Shrink from guided mode is enough
17:38:08 <cmurf> agreed
17:38:12 <jreznik> kparal: +1
17:38:24 <cmurf> patch - remove or fix
17:38:49 <kparal> I think adamw will mention that in the comment
17:38:55 <kparal> no need to patch
17:39:09 <tflink> yeah, I was thinking the same thing - not sure it needs to be here in the #agreed
17:39:41 <adamw> yeah
17:39:45 <adamw> i'll clean that up
17:40:04 <cmurf> btw this bug is the impetus for bug 885921 which actually blows up the windows volume on a resize (separate cause but for me the bug we just agreed on 100% causes the obliteration of the Windows volume)
17:40:05 <bugbot_> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=885921 high, medium, ---, aavati, NEW , [RFE] Re-factor Marker Framework to support incremental backup using commercial backup solutions
17:40:28 <tflink> #topic (885385) Strange race in livecd creation
17:40:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885385
17:40:28 <tflink> #info Proposed Blocker, livecd-tools, ON_QA
17:40:29 <bugbot_> Bug 885385: unspecified, unspecified, ---, bcl, ON_QA , Strange race in livecd creation
17:40:32 <cmurf> rats
17:40:39 <cmurf> 885912 sorry!
17:41:45 * nirik has more info on this if anyone needs it.
17:41:52 <tflink> this has been causing problems for releng in livecd creation
17:41:53 <nirik> it causes livecd composes to randomly fail.
17:43:06 <adamw> since we can just keep re-firing till it works i'm not sure this is technically a blocker
17:43:18 <tflink> yeah, but definitely +1 NTH
17:43:26 <adamw> i mean if this was the day of go/no-go and we had an RC that passed all tests, and we'd built the live images by re-trying until it worked, would we block release for this?
17:43:29 <adamw> that doesn't seem to make any sense.
17:43:32 <adamw> but +1 NTH for sure.
17:44:18 <cmurf> +1 nth
17:44:20 <tflink> anyone +1 blocker?
17:44:58 <jreznik> as adamw pointed out - with RC, it's not a blocker
17:45:16 <adamw> nirik: am i missing anything there?
17:45:17 <jreznik> it could cause a problem when we would need something in the last minute, so +1 nth, sure
17:45:49 <nirik> right, it could be worked around, but just very frustrating.
17:45:58 <nirik> so, sure, +1 NTH.
17:45:59 <tflink> proposed #agreed 885385 - RejectedBlocker AcceptedNTH - This doesn't cause compose failures every time and thus isn't enough to block release. However, getting reliable composes is important and a tested fix would be considered past freeze.
17:46:01 <nirik> the fix works BTW.
17:46:11 <nirik> ack
17:46:22 <jreznik> ack
17:46:31 <jreznik> nirik: great!
17:46:48 <adamw> ack
17:46:58 <tflink> #agreed 885385 - RejectedBlocker AcceptedNTH - This doesn't cause compose failures every time and thus isn't enough to block release. However, getting reliable composes is important and a tested fix would be considered past freeze.
17:47:02 <tflink> #topic (886647) Anaconda throws exception trying to setup network
17:47:04 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886647
17:47:05 <bugbot_> Bug 886647: high, unspecified, ---, anaconda-maint-list, NEW , Anaconda throws exception trying to setup network
17:47:06 <tflink> #info Proposed Blocker, anaconda, NEW
17:48:14 <tflink> I thought we already had a blocker for a similar issue
17:48:15 <adamw> we don't really seem to have necessary info here
17:48:20 <adamw> this is a separate bug from that.
17:48:24 <kparal> needinfo
17:48:31 <adamw> that one was fixed, and this one has a different trace.
17:48:36 <tflink> adamw: you were the one who requested discussion
17:49:44 <adamw> "though we'll need more detail on the exact problem here to evaluate it"
17:49:49 <adamw> what we don't have yet, so...yeah.
17:50:09 <cmurf> is this just driver related? the syslog isn't indicating an interface at all that i can see.
17:50:13 <tflink> proposed #agreed 886647 - While potentially serious, there is not currently enough information to make a decision on blocker status. Will revisit when more information is available.
17:50:24 <kparal> ack
17:50:27 <tflink> adamw: I guess I parsed the meaning differently than you intended
17:50:34 <adamw> ack
17:50:41 <tflink> "this needs more info but needs to be discussed"
17:50:45 <tflink> oh well :)
17:51:19 <cmurf> how about getting lspci from the reporter and confirm/deny there are even drivers
17:51:35 <adamw> well, yeah, that's more or less the plan.
17:51:37 <cmurf> wait a minute this is a vbox guest
17:51:42 <adamw> but we don't need to spend time here talking about it
17:52:00 <tflink> ack/nak/patch?
17:52:04 <tflink> I see 2
17:52:21 <cmurf> ack
17:52:23 <tflink> #agreed 886647 - While potentially serious, there is not currently enough information to make a decision on blocker status. Will revisit when more information is available.
17:52:32 <tflink> #topic (886061) core fedora repository error must be fatal, otherwise the upgraded system might be broken heavily
17:52:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886061
17:52:36 <bugbot_> Bug 886061: unspecified, unspecified, ---, wwoods, NEW , core fedora repository error must be fatal, otherwise the upgraded system might be broken heavily
17:52:37 <tflink> #info Proposed Blocker, fedup, NEW
17:52:50 <jreznik> ack and I'll ping vpodzime/rvykydal tmrw to talk about it in details...
17:53:12 <kparal> wwoods replied here, but I think we still need more info
17:53:43 <kparal> e.g. "But we can also talk about missing fedora-updates.repo. Doesn't that break the upgrade path for many packages, if you don't have "updates" downloaded?"
17:54:07 <adamw> i'm still somewhat confused here
17:54:12 * adamw votes whatever kparal and tflink vote
17:54:16 <tflink> I'm still not sure this would break someone's system as described
17:54:31 <tflink> I'd be more interested to see what happened if there was a download error
17:54:47 <tflink> if the repo isn't available - the upgrade isn't going to do squat even if you do reboot
17:55:27 <tflink> if you were missing a critical package or 2, that might make for interesting breakage
17:55:27 <kparal> tflink: how come? I simulated it and it half-upgraded my system
17:56:09 <kparal> tflink: package download errors are not a problem, I tested it. the whole fedup process is aborted
17:56:18 <kparal> just the repo errors are a problem
17:56:21 <adamw> the problem would be if it gets one repo but not another, right?
17:56:28 <adamw> say it manages to get 'updates' but not 'fedora'
17:56:28 <kparal> adamw: right
17:56:29 <adamw> or vice versa
17:56:32 <kparal> adamw: right
17:56:35 <adamw> well, vice versa wouldn't be so bad
17:56:47 <kparal> except upgradepath problems
17:57:11 <kparal> esentially that would work the same (bad) as dvd upgrades in the past
17:57:16 <tflink> yeah, I was misunderstanding something
17:57:16 <adamw> yeah.
17:57:23 <jreznik> ah, ok, I got it now
17:57:25 <kparal> but yes, missing 'fedora' repo is more of a problem
17:57:42 <kparal> because some packages might not be in 'updates', just in 'fedora'
17:57:49 <kparal> if  you miss 'fedora', you don't have them
17:58:00 <tflink> especially right after release
17:58:22 <kparal> let's say it's systemd case. you will have everything .fc18 except systemd, which will  be .fc17. can it break the system?
17:58:25 <kparal> who knows
17:58:38 <tflink> that sounds nasty
17:58:43 <tflink> with the journald change
17:58:58 <kparal> or it can be xorg, or gdm, or anything
17:59:00 <tflink> IIRC, the system still boots though
17:59:05 <tflink> I've seen that before
17:59:11 <kparal> I'm not sure whether it will explode on missing dependencies or something, I don't know
17:59:12 <tflink> but it doesn't mean that it isn't a problem
17:59:49 <adamw> so if you can hit that case, yeah, i'm worried
18:00:19 <tflink> as time goes on, it'll be harder and harder to hit
18:00:19 <kparal> but wwoods says the automatic instrepo will point to fedora 18 release mirror (with package repository), so the issue could be mitigated
18:00:32 <tflink> I think he misunderstood your concerns, to be honest
18:00:45 <tflink> or not, maybe I'm just slow this morning
18:00:56 <kparal> well I still think it's damn easy to abort the fedup process, if a core fedora repo is not available
18:01:25 <tflink> he does have a point - if instrepo isn't used, fedup wouldn't get to the point where you could reboot
18:01:38 <tflink> er, reboot and start an upgrade
18:01:48 <tflink> unless there were some strange repo errors in the middle of prep
18:01:57 <kparal> tflink: I think it will be used, it will be just set automatically, no need to specify it by hand
18:02:21 <tflink> kparal: define "it will be used"
18:02:37 <tflink> it will pull from the fedora repo
18:02:46 * kparal searching
18:02:55 <tflink> so if the repo that you find is down, you won't be able to get the initramfs or the kernel either
18:03:29 <kparal> tflink: yes, like that. instrepo error is fatal, definitely
18:03:51 <kparal> but 'fedora' and 'updates' errors are not fatal yet
18:03:55 <tflink> it might still get the updates and could possibly alter the boot menu to add "system upgrade" (I don't think it would get that far, though)
18:04:06 <tflink> but if you rebooted, the upgrade wouldn't start
18:04:18 <tflink> true, but I'm not sure this is release-blocking right now
18:04:20 <tflink> bad, yes
18:04:31 <tflink> common enough that we should block over ... not so sure
18:05:08 <kparal> well I'm sure it doesn't happen often. but I found it because it happened to me
18:05:21 <tflink> sure, I think that's more common
18:05:28 <kparal> anyway, I think I should ping wwoods for more feedback first
18:05:40 <tflink> but @ release, I don't see this as being incredibly common
18:05:58 <adamw> let's make a decision, time's a-spendin'
18:06:17 <tflink> if there's no --instrepo specified by hand, the only way to hit this is to have some sort of network hiccup at the wrong time and not pay attention to your output
18:06:35 <kparal> tflink: not really, it's a single line among thousands
18:06:42 <kparal> > No upgrade available for the following repos: fedora
18:06:46 <kparal> that's all output you'll see
18:06:54 <tflink> right now, yes
18:06:56 <tflink> at final, no
18:07:12 <kparal> I don't follow
18:07:14 <tflink> you'd have to hit it at just the right time to get that @ final
18:07:32 <kparal> let's punt and discuss separately from the meeting
18:07:38 <tflink> with the MM changes, fedup will use the fedora repo for upgrade packages and the initramfs/kernel pair
18:07:47 <tflink> if the repo is not available, fedup will blow up
18:08:00 <tflink> and even if it didn't, the system upgrade option wouldn't be bootable
18:08:32 <tflink> unless your timing was so bad that there were network issues that didn't affect the initramfs/vmlinuz pair
18:08:43 <kparal> I believe the code for 'fedora' and 'updates' repo won't change, just the code handling --instrepo
18:08:57 <tflink> which is somewhat irrelevant to this bug
18:09:09 <kparal> this bug is about broken 'fedora' repo :)
18:09:32 <tflink> sure but the blocker part is about the odds of ending up with a borked system
18:09:44 <tflink> I'm not convinced that it's incredibly likely after release
18:09:50 * adamw taps fingers, examines watch
18:09:56 <kparal> I don't really know
18:10:11 <kparal> I think we're speculating too much now
18:10:20 <kparal> punt and wait/query for more info
18:10:24 <tflink> I don't but I'm fine with moving on
18:11:06 <adamw> ack to punt
18:11:13 <tflink> proposed #agreed 886061 - There is too much confusion around this to make a decision on blocker status right now. will continue conversation outside the meeting and re-visit later.
18:11:19 <kparal> ack
18:11:23 <jsmith> ACK
18:11:28 <adamw> punt to clarify the issue to wwoods and ask for a clear evaluation on whether this may result in a broken system after release
18:11:30 <adamw> ack
18:11:47 <tflink> adamw: was that an ack or a patch?
18:13:16 * tflink assumes that it was an ack for the sake of time
18:13:20 <tflink> #topic (886705) live cd should include qemu-guest-agent package
18:13:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886705
18:13:20 <tflink> #info Proposed Blocker, spin-kickstarts, NEW
18:13:21 <bugbot_> Bug 886705: unspecified, unspecified, ---, kanarip, NEW , live cd should include qemu-guest-agent package
18:13:51 <tflink> assuming I understand the bug, -1/-1
18:14:09 <tflink> it doesn't hit criteria and there are reasonable workarounds
18:14:18 <tflink> ie. use the shutdown function from inside the VM
18:14:32 <tflink> or don't use the livecd as a source for the VM
18:14:33 <cmurf> -1/-1
18:14:47 <adamw> well, i mean, controlling your VMs with virsh is a perfectly reasonable thing to do. it's why we have those commands in libvirt...
18:15:01 <adamw> i can kinda see NTH. i think qemu-guest-agent actually gets us some other neat stuff, like cut-n-paste in the guest.
18:15:10 <adamw> but eh, i can go either way. definitely -1 blocker.
18:15:29 <tflink> how much does this add to the lives?
18:15:44 <tflink> I'm just not sure it's enough to justify mucking with the lives this late
18:15:57 <adamw> "qemu-guest-agent is only 285k installed"
18:16:03 <tflink> deps?
18:16:20 <adamw> dunno
18:16:31 <kparal> -1 blocker, +0 nth
18:16:42 <adamw> as this is spin-kickstarts / comps, btw, it doesn't even really _need_ a freeze exception since they don't freeze...but it's nice someone's following protocol...
18:16:44 <tflink> what about the other spins like kde or XFCE?
18:17:04 <nirik> everything is under size currently AFAIK
18:17:25 * nirik is -1 blocker, we could just do it for nth tho
18:17:33 <tflink> I can think of at least one person who would be upset about this ... but that isn't new in that particular persons' case
18:18:23 <tflink> I'm still somewhat -1 nth unless this is a far more common use case than I think it is
18:19:11 <tflink> is anyone more than +0 NTH?
18:19:21 * nirik doesn't feel strongly about it really. We have much bigger fish to fry
18:19:28 <tflink> yep
18:19:54 <tflink> it sounds like we're mostly +/- 0
18:19:55 <adamw> i'm still +1, but i don't really hate a -1 choice.
18:20:23 <tflink> I'm just about the opposite, -1 but I'm not going to fight it much
18:21:27 <adamw> toss a coin!
18:21:33 <kparal> if you need someone to cut it, I'm +1 nth
18:21:55 <adamw> hm, did you see comment #1?
18:21:56 <adamw> "When shutting down the host, it is therefore necessary to have a means to put the guest into shutdown (S5) rather than just suspend (S3).  However, since the ACPI shutdown option does not trigger a shutdown, the guest needs some other way to know when the host needs it to shut down cleanly"
18:22:09 <adamw> so i think the case here is that you have a VM running and you shut down the host
18:22:28 <adamw> that's supposed to tell the guests to shut down, but apparently it doesn't work properly for fedora guests unless the guest agent is installed
18:22:30 <adamw> eh, anyway.
18:22:33 <tflink> ok, I'm mostly -1 due to the part about the non-updatable part of this being a rare corner case
18:22:41 <adamw> reasonable
18:22:56 <tflink> but it sounds like we're more +1 than -1
18:23:11 <kparal> should I revert back to my original +0 nth?
18:23:22 <tflink> then we're more 0 overall
18:23:32 <tflink> either way, let's get this done with
18:24:45 <tflink> proposed #agreed 886705 - RejectedBlocker AcceptedNTH - This doesn't clearly violate any of the F18 release criteria and thus is rejected as a blocker. However, the livecd cannot be updated post-release so a tested fix would be considered past freeze.
18:25:00 <tflink> at some point, it might be wise to get strict about NTH changes, though
18:25:09 <adamw> ack
18:25:18 <tflink> we have 1 full 100% week before release as currently scheduled
18:25:46 <kparal> ack
18:26:20 <tflink> I think we lost everyone again
18:26:30 * nirik would prefer to land as many acceptable NTH's like today.
18:26:31 <nirik> ack
18:26:46 <tflink> #agreed 886705 - RejectedBlocker AcceptedNTH - This doesn't clearly violate any of the F18 release criteria and thus is rejected as a blocker. However, the livecd cannot be updated post-release so a tested fix would be considered past freeze.
18:26:49 * kparal needs to go now
18:27:00 <tflink> at the rate we're going, we're not going to get through the NTH list today
18:27:13 <tflink> kparal: thanks for helping out
18:27:16 <tflink> #topic (887363) cloud-init 0.7.1 change prevents creation of ec2-user
18:27:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887363
18:27:16 <tflink> #info Proposed Blocker, cloud-init, ON_QA
18:27:18 <bugbot_> Bug 887363: unspecified, unspecified, ---, gholms, ON_QA , cloud-init 0.7.1 change prevents creation of ec2-user
18:27:26 <tflink> I think this is a pretty clear blocker
18:27:28 <tflink> +1
18:27:59 <adamw> +1
18:28:24 * tflink has a feeling that our meeting productivity just went out the window now that kparal left
18:28:31 * nirik reads
18:29:01 * nirik hates the ec2 user, thought cloud folks were going to drop it. But I guess it's too late now.
18:29:32 <tflink> I thought that it was the ec2 way of doing things
18:29:37 <tflink> or do other distros not do that?
18:29:43 <tflink> it's been a while since I used EC2
18:29:44 <adamw> "We kinda need it in the release itself so we can make the EC2 images."
18:29:53 <adamw> we don't really need to discuss whether we like this mechanism or not
18:29:56 * adamw tries to hurry things along
18:30:14 <tflink> true, but it doesn't really violate the criteria to the letter :-D
18:30:15 <nirik> http://lists.fedoraproject.org/pipermail/cloud/2012-December/002038.html
18:30:27 <tflink> the release does still run on xen
18:30:48 <adamw> sigh
18:30:54 <adamw> learn to fudge, damnit :)
18:31:03 <tflink> that was the plan
18:31:17 <tflink> just saying that it technically isn't a 100% clear violation
18:31:23 <tflink> either way, anyone -1?
18:31:28 * nirik is +0/+1, but happy to bow to your +1s
18:31:56 <tflink> nirik: what are the odds of not needing ec2-user before release?
18:32:13 <nirik> well, even if so, it would need a update to do that...
18:32:22 <nirik> so fixing this is probibly less intrusive
18:32:52 <tflink> proposed #agreed 887363 - AcceptedBlocker - Violation of the following F18 final release criterion for EC2 images: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0"
18:33:05 <adamw> ack
18:33:18 <nirik> ack
18:33:29 <tflink> it seems odd that they're just figuring out the EC2 issues now, though
18:34:10 <tflink> on a side note, do we start lowering the 'ack' bar to get through the list, find more people or adjurn for the day?
18:34:27 <tflink> since there are just 3 of us and I'm not sure how busy nirik is
18:34:47 <nirik> always busy, but I can try and pay more attention.
18:34:55 <nirik> we could ping other channels for more folks?
18:35:09 <tflink> we have 3 more blockers on the 'to be discussed' list
18:35:53 <adamw> 3 people is enough for ack
18:35:56 <adamw> let's get through the blockers
18:36:17 <tflink> #agreed 887363 - AcceptedBlocker - Violation of the following F18 final release criterion for EC2 images: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0"
18:36:24 <tflink> #topic (887539) FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
18:36:27 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887539
18:36:29 <bugbot_> Bug 887539: unspecified, unspecified, ---, anaconda-maint-list, NEW , FormatDestroyError: error wiping old signatures from /dev/sdb2: 1
18:36:30 <tflink> #info Proposed Blocker, anaconda, NEW
18:37:10 <tflink> this feels a little like a "doctor it hurts" issue to me
18:37:16 <tflink> nth ... maybe
18:37:21 <tflink> blocker, not so much
18:37:52 <tflink> didn't we have another bug for this, anyways?
18:37:58 * jreznik is back
18:38:15 <adamw> it's a similar tb to another one yeah
18:38:17 <jreznik> tflink: yep, part of that lvm
18:38:18 <adamw> the one i kept hitting with raid
18:38:26 <jreznik> or raid, sorry
18:38:27 <nirik> yeah, this seems like a pretty corner case.
18:38:37 <jreznik> jes wants this fixed...
18:38:59 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=876789 is the other bug
18:39:01 <bugbot_> Bug 876789: unspecified, unspecified, ---, lvm-team, ON_QA , FormatDestroyError: error wiping old signatures from /dev/md/Volume0_0p2: 1
18:39:03 <adamw> already accepted as a blocker
18:39:25 <jreznik> well, ok - so it can be closed as dupe
18:39:29 <nirik> yeah, that seems like the blocker part of this one...
18:39:35 <nirik> format not formatting.
18:39:58 <tflink> I thought it was something like "ignoring part of the uuid"
18:40:28 * adamw will check with anaconda
18:40:37 <tflink> ignoring part of the info which made it possible to differnetiate between the disks, anyways
18:40:42 <tflink> so punt?
18:41:07 <jreznik> punt and get more info from anaconda/jes
18:41:10 <tflink> or reject?
18:41:21 <nirik> or close this one as a dupe?
18:41:45 <adamw> punt for status check is fine with me
18:41:47 <tflink> proposed #agreed 887539 - We need more information on whether this is a dupe of #876789 before making a decision on blocker status. will re-visit later
18:42:04 <jreznik> maybe add the possibility of dupe?
18:42:21 <tflink> jreznik: not sure I follow you
18:42:29 * adamw talking with anaconda folks atm
18:42:36 <jreznik> tflink: ah, sorry, blind...
18:42:40 <nirik> ack
18:42:49 <jreznik> onion smell around...
18:42:50 <jreznik> ack
18:43:05 <adamw> <bcl> adamw: Isn't that the wipefs doesn't work on active devices anymore issue?
18:43:45 <jreznik> so retest with tc3?
18:43:50 <adamw> anyway, ack
18:43:54 <adamw> i now know what to ask in the bug
18:44:00 <tflink> #agreed 887539 - We need more information on whether this is a dupe of #876789 before making a decision on blocker status. will re-visit later
18:44:11 <tflink> #topic (885912) Resize of NTFS partition results in partition smaller than the filesystem, broken Windows install
18:44:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885912
18:44:15 <bugbot_> Bug 885912: high, unspecified, ---, anaconda-maint-list, NEW , Resize of NTFS partition results in partition smaller than the filesystem, broken Windows install
18:44:16 <tflink> #info Proposed Blocker, anaconda, NEW
18:44:41 * nirik waits for bz
18:45:41 <nirik> still waiting for parsing the test data here?
18:45:42 <cmurf> +1 blocker, the NTFS volume is nerfed
18:45:57 <tflink> is this another case of the "resize in autopart may not be a great idea" thing?
18:45:57 * nirik wonders if this is a libparted bug, not anaconda
18:46:06 <jreznik> tflink: looks like
18:46:25 <adamw> well it's sort of a consequence i think
18:46:32 <cmurf> For unknown reasons (to me), anaconda is setting partition size in the MBR smaller than ntfsresize.
18:46:36 <adamw> it probably only happens when you're trying to shrink the partition close to its minimum size
18:46:49 <adamw> which probably people wouldn't do if the installer didn't force them to
18:47:01 <cmurf> Then it proceeds to obliterate the last dozen to several hundred sectors which are now in some other partition.
18:47:02 <adamw> but it is a separate bug, really. resizing to a small size ought to *work*.
18:47:46 <adamw> this is a fairly clear +1 under the 'corruption of existing data' bug if nothing else for me
18:48:18 <cmurf> In my cases it was only 34 sectors that got hosed so repairing the file system was possible, but in other cases it's much more than this.
18:48:22 <tflink> yeah, I probably wouldn't fight +1
18:48:32 * nirik nods.
18:49:01 <tflink> I can see this being downgraded if the "resize in autopart" thing is dropped, though
18:49:08 <adamw> yeah, me too
18:49:14 <adamw> though i'd much prefer they fix it than drop it
18:49:23 <adamw> and if this is still possible, it's still a pretty rude bug
18:49:55 <cmurf> FWIW Microsoft's chkdsk will not repair the fs. You have to do it with ntfsfix then use chkdsk.
18:50:01 <jreznik> fix would be nice but any workaround (like drop resize autopart) would work for me
18:50:02 <cmurf> So yes, it's rude.
18:50:43 <tflink> proposed #agreed 885912 - AcceptedBlocker - Violation of the following F18 release criterion: "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs"
18:50:58 <cmurf> Well it's unclear that a larger fs is inherently exempt from this bug because what's causing it is the partition size is set wrong. Unclear is why it's set wrong. But it looks like an alignment computation related error.
18:51:32 <nirik> ack
18:51:36 <cmurf> ack
18:51:56 <adamw> ack
18:52:03 <jreznik> ack
18:52:18 <tflink> #agreed 885912 - AcceptedBlocker - Violation of the following F18 release criterion: "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs"
18:52:28 <tflink> #topic (887357) workaround for for appliance creation in koji
18:52:28 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887357
18:52:28 <tflink> #info Proposed Blocker, device-mapper-multipath, ASSIGNED
18:52:29 <bugbot_> Bug 887357: unspecified, unspecified, ---, bmarzins, ASSIGNED , workaround for for appliance creation in koji
18:52:49 <nirik> this is related to the livecd thing, except in this case it always fails. ;)
18:53:39 <nirik> producing ec2 images is part of our release, right? if so, then +1 blocker since we need this to do that.
18:53:56 <cmurf> multipath is pushed to F19 along with other enterprise storage? yes?
18:53:57 <tflink> proposed #agreed 887357 - AcceptedBlocker - Violates the following F18 final release criterion by blocking the creation of cloud images: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0"
18:54:10 <tflink> cmurf: in the installer, yes
18:54:10 <nirik> ack
18:54:15 <adamw> if we consider ec2 images a critical deliverable, sure.
18:54:18 <adamw> ack
18:55:10 <tflink> adamw: I don't think this would be limited to ec2
18:55:25 <adamw> that's the known consequence, though?
18:55:26 <tflink> but IIRC, that's the only cloud image we're producing right now
18:55:30 <cmurf> +1
18:55:37 <cmurf> ack
18:55:39 <jreznik> ack
18:55:46 <tflink> #agreed 887357 - AcceptedBlocker - Violates the following F18 final release criterion by blocking the creation of cloud images: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0"
18:55:52 <nirik> well, that image can be used in other clouds too. ;)
18:56:10 <tflink> OK, that would be all of the proposed blockers that I've marked for discussion
18:56:25 <tflink> I'm open to suggestions on what to do next
18:56:38 <tflink> if we're really doing daily meetings, we could just adjurn for the day (over 2 hours)
18:56:46 <tflink> or we could hit some NTH
18:57:04 <tflink> wait, do I have my times right?
18:57:18 * nirik would love to accept the 2 NTH's that deal with broken deps so we could push them stable and not have broken deps in the branched tree. ;)
18:57:21 <tflink> yes, I can count. Just over 2 hours right now
18:57:32 <jreznik> nirik: ok
18:57:39 <tflink> nirik: do you have bzids handy?
18:57:43 <jreznik> let's do a few top nths
18:58:09 * nirik looks
18:58:14 <adamw> high priority nth would be nice
18:58:17 <cmurf> i could use food so if there's a gap that'd be nice
18:58:21 <adamw> anything with a fix
18:58:25 <cmurf> but high priority NTH does need to get sorted
18:58:29 <nirik> 886329
18:59:18 <jreznik> cmurf: me is multitasking blocker bug review and cooking dinner :)
18:59:51 <cmurf> jreznik: i would also but i'm out of raw materials
19:00:21 <tflink> nirik: is 886734 the other one you're thinking of?
19:00:23 <nirik> I can't find a bug on the other one.
19:00:25 <nirik> https://admin.fedoraproject.org/updates/FEDORA-2012-20266/marble-4.9.4-2.fc18
19:00:27 <nirik> is the update
19:01:19 <jreznik> we can solve also pygobject3 bug
19:01:37 <tflink> as long as someone has a better idea of what's going on there than I do
19:01:46 <tflink> we can do easy ones, though
19:01:50 <tflink> #topic (886329) fedmsg-0.6.3 is a broken dependency.
19:01:50 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886329
19:01:50 <tflink> #info Proposed NTH, fedmsg, MODIFIED
19:01:52 <bugbot_> Bug 886329: unspecified, unspecified, ---, rbean, MODIFIED , fedmsg-0.6.3 is a broken dependency.
19:02:19 <nirik> this is a leaf package, fixes broken dep...
19:02:31 <tflink> -1 unless I'm missing something
19:03:52 <jreznik> do we usually do this cleanup?
19:04:22 <adamw> no, but i like it
19:04:37 <adamw> spot decided to do it this release, just as a Cool Thing To Do i think
19:04:45 <nirik> it would be nice to release a tree with no broken deps.
19:04:56 <adamw> i'm willing to take stuff as nth to make the final frozen repo 100% consistent, i think it's a nice goal, and shouldn't hurt anything for packages not on media
19:05:04 <adamw> oh hey, there goes bz again.
19:05:13 <adamw> oh, back
19:05:16 * nirik is with adamw.
19:06:02 <adamw> so +1
19:06:07 <tflink> I'm still -1 on this, it opens the door to more stuff that we shouldn't be taking but I'm not going to fight it too hard
19:06:07 <jreznik> well, makes sense +1
19:06:20 <tflink> it isn't on the DVD, it can be fixed with an update
19:06:33 <adamw> well, 'the frozen repo is not consistent' cannot be fixed with an update by definition.
19:06:58 <tflink> ok, I'm not +1 on that, either
19:07:20 <tflink> but I count +3, though?
19:07:32 * nirik nods.
19:08:13 <tflink> proposed #agreed 886329 - AcceptedNTH - There is a desire to release a final frozen repo without dep issues, even if they don't affect the F18 media. A tested fix would be considered past freeze.
19:08:20 <nirik> ack
19:08:34 <adamw> ack
19:08:36 <jreznik> ack
19:08:58 <nirik> .bug 887990
19:08:59 <bugbot_> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=887990 unspecified, unspecified, ---, rdieter, MODIFIED , 1:python-marble-4.9.4-1.fc18.x86_64 requires sip-api(8) >= 0:8.1
19:09:00 <zodbot> nirik: Bug 887990 1:python-marble-4.9.4-1.fc18.x86_64 requires sip-api(8) >= 0:8.1 - https://bugzilla.redhat.com/show_bug.cgi?id=887990
19:09:01 <tflink> #agreed 886329 - AcceptedNTH - There is a desire to release a final frozen repo without dep issues, even if they don't affect the F18 media. A tested fix would be considered past freeze.
19:09:06 <nirik> is the newly filed marble broken dep
19:09:42 <adamw> +1 then, for consistenc
19:09:43 <adamw> y
19:09:51 <adamw> oh, no #topic yet
19:10:31 <tflink> #topic (887990) 1:python-marble-4.9.4-1.fc18.x86_64 requires sip-api(8) >= 0:8.1
19:10:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887990
19:10:35 <bugbot_> Bug 887990: unspecified, unspecified, ---, rdieter, MODIFIED , 1:python-marble-4.9.4-1.fc18.x86_64 requires sip-api(8) >= 0:8.1
19:10:37 <tflink> #info Proposed NTH, marble, MODIFIED
19:10:41 <adamw> +1
19:10:48 <nirik> +1
19:11:07 <tflink> #agreed 887990 - AcceptedNTH - There is a desire to release a final frozen repo without dep issues, even if they don't affect the F18 media. A tested fix would be considered past freeze.
19:11:13 <tflink> oops, that was supposed to have a proposed
19:11:21 * tflink will undo if there are any naks or patches
19:11:34 <adamw> ack
19:12:21 <jreznik> ack
19:12:34 <nirik> ack
19:13:07 <tflink> what is our goal to get through today?
19:13:25 <tflink> are we stopping at 3 hours or are we trying to get through everything with a fix today?
19:13:31 <nirik> not sure. If we want to power on, I can hang around...
19:13:43 <tflink> we're at ~ 2.5 hours right now
19:13:55 * adamw has some others to go through if people will hang around
19:13:57 <adamw> i just made a list
19:14:00 <tflink> my list is not organized for has/doesn't have fix
19:14:21 <jreznik> let's to pygobject3 now and it could be the last one :)
19:14:28 <tflink> yeah, that was on the short list
19:14:34 <adamw> i just manually eyeballed a list of important ones
19:14:35 <adamw> that's on it, yeah
19:14:39 <cmurf> let's push on for a bit
19:14:39 <adamw> 874378
19:14:41 * nirik is ok with adamw's list, whatever it is.
19:14:52 <adamw> i'll call out numbers for ya tflink
19:15:07 <tflink> adamw: can you pm me the numbers so I can get the list ready?
19:15:10 <adamw> sure
19:15:12 <tflink> or list them here, either way
19:15:16 <tflink> #topic (874378) firewalld caused minimal install to grow substantially between Alpha and Beta TC7: firewalld deps are pretty heavy
19:15:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=874378
19:15:21 <bugbot_> Bug 874378: medium, unspecified, ---, twoerner, ON_QA , firewalld caused minimal install to grow substantially between Alpha and Beta TC7: firewalld deps are pretty heavy
19:15:22 <tflink> #info Proposed NTH, firewalld, ON_QA
19:16:08 <adamw> +1
19:16:12 <adamw> reducing dep load is good
19:16:18 <cmurf> +1
19:16:19 <nirik> so the fix here is to pygobject3... to make it so for firewalld it doesn't pull in cairo/X, but doesn't break everything else that uses it.
19:16:20 <jreznik> +1 as pygobject3 fix is required by fesco as part of feature process
19:16:23 <nirik> +1
19:16:31 <jreznik> nirik: yep
19:18:31 * adamw readies the tflink poking stick
19:19:20 * cmurf throws a donut at tflink to increase his blood sugar
19:19:22 <tflink> ok
19:19:32 <tflink> this seems like an odd fix, though
19:19:40 <adamw> it was pretty carefully researched.
19:20:11 <tflink> proposed #agreed 874378 - AcceptedNTH - This reduces the dependencies on a minimal install so that cairo and X aren't pulled in for firewalld
19:20:17 <adamw> ack
19:20:21 <nirik> ack
19:20:43 <jreznik> patch - as requested by FESCo (just to make clear why we need it)
19:21:16 <adamw> i'd be +1 without anything from fesco
19:21:18 <adamw> just on the merits
19:21:37 <tflink> proposed #agreed 874378 - AcceptedNTH - This reduces the dependencies on a minimal install so that cairo and X aren't pulled in for firewalld as requested by FESCo
19:22:51 * tflink assumes that the acks still hold
19:22:58 <tflink> #agreed 874378 - AcceptedNTH - This reduces the dependencies on a minimal install so that cairo and X aren't pulled in for firewalld as requested by FESCo
19:23:11 <tflink> #topic (885541) Renew-Subscription spam in /var/log/cups/access_log
19:23:11 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=885541
19:23:11 <tflink> #info Proposed NTH, kde-print-manager, ON_QA
19:23:12 <bugbot_> Bug 885541: unspecified, unspecified, ---, rdieter, ON_QA , Renew-Subscription spam in /var/log/cups/access_log
19:24:10 <cmurf> kindof icky but seems fixable after the fact
19:24:27 <adamw> is it on the live images? i forgot to check that
19:24:29 <adamw> anyone have a KDE live handy?
19:24:32 <rdieter> it is
19:25:05 <tflink> I'm OK with nth if this is spamming logs on the livecd
19:25:17 <adamw> +1 then
19:25:23 <cmurf> agreed +1
19:25:23 <nirik> +1 here also
19:25:38 <jreznik> +1
19:26:00 <tflink> proposed #agreed 885541 - AcceptedNTH - This is spamming logs on the KDE live image which could cause problems with overlays or ramdisks. A tested fix would be considered past freeze.
19:26:15 <jreznik> adamw: we switched to it
19:26:17 <adamw> yeah, i can see this in a Beta live boot
19:26:19 <adamw> ack
19:26:24 <jreznik> ack
19:26:27 <nirik> ack
19:26:34 <tflink> #agreed 885541 - AcceptedNTH - This is spamming logs on the KDE live image which could cause problems with overlays or ramdisks. A tested fix would be considered past freeze.
19:26:43 <tflink> #topic (886734) Obsolete subpackage system-config-printer-kde in the F18 repository
19:26:47 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886734
19:26:48 <bugbot_> Bug 886734: urgent, unspecified, ---, than, ON_QA , Obsolete subpackage system-config-printer-kde in the F18 repository
19:26:49 <tflink> #info Proposed NTH, kdeadmin, ON_QA
19:26:49 <tflink> +1 NTH for consistency
19:27:11 <cmurf> +1nth
19:27:34 <tflink> proposed #agreed 886734 - AcceptedNTH - It would be nice to not have obsoleted packages in the frozen repo. A tested fix would be considered past freeze.
19:27:51 <nirik> ack
19:28:14 <adamw> ack
19:28:37 <tflink> there are 3 more bugs on adam's list, BTW
19:29:02 <adamw> actually a few bonus ones after that - we should blanket declare all size problems NTH
19:29:10 <adamw> there's like 3 or 4 bugs for non-blocking lives being oversize
19:29:32 * nirik is looking at the xfce one now. sigh.
19:29:33 <jreznik> ack
19:29:40 <tflink> adamw: you should send the bzids :)
19:29:42 <adamw> actually the next bug is probably skippable
19:30:03 <adamw> yeah, we can skip the livecd-tools one as we took 885385
19:30:13 <tflink> #topic (872468) Thai font missing from installer environment
19:30:13 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=872468
19:30:13 <tflink> #info Proposed NTH, lorax, ON_QA
19:30:15 <bugbot_> Bug 872468: medium, unspecified, ---, mgracik, ON_QA , Thai font missing from installer environment
19:30:19 <tflink> +1
19:30:26 <adamw> +1 , always bad to break a language
19:30:57 <tflink> proposed #agreed 872468 - AcceptedNTH - It's not good form to break a language in the installer. A tested fix would be considered past freeze.
19:31:11 <nirik> +1
19:31:13 <nirik> ack
19:31:27 <cmurf> ack
19:31:33 <adamw> ack
19:31:58 <tflink> #agreed 872468 - AcceptedNTH - It's not good form to break a language in the installer. A tested fix would be considered past freeze.
19:32:06 <tflink> #topic (886733) live images built with livecd-creator 18.13 have major SELinux problems (SELinux is preventing /usr/libexec/colord from 'write' accesses on the directory colord.)
19:32:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886733
19:32:11 <bugbot_> Bug 886733: unspecified, unspecified, ---, mgrepl, MODIFIED , live images built with livecd-creator 18.13 have major SELinux problems (SELinux is preventing /usr/libexec/colord from 'write' accesses on the directory colord.)
19:32:12 <tflink> #info Proposed NTH, selinux-policy, MODIFIED
19:32:19 <adamw> there's a whole chunk of selinux stuff
19:32:31 <adamw> but i just pulled out one bug we can say 'this is NTH, let's take the latest build which doesn't appear to bork anything'
19:32:52 <adamw> i think right now we're still on -50 in stable, we should pull something newer, but we don't want anything between -50 and -66 as various things were borked in all the intermittent builxcs
19:33:17 <tflink> what all went into -66?
19:33:30 <tflink> it sounds like they're putting stuff in there without being blocker/nth issues
19:33:49 <adamw> yeah, they do that, but i'm generally ok with it as long as it's loosening perms
19:34:04 <adamw> the other major stuff is the problems with live image creation
19:34:12 <adamw> see all the qemu-kvm bugs that are fixed in the update
19:34:29 <tflink> so we're OK with it for certain packages but not others?
19:34:29 <adamw> we should test -66 before we actually pull it, of course
19:35:02 <tflink> votes?
19:35:03 <adamw> i think selinux-policy is a slight special case in that there's this constant cycle of bug reported / policy loosened
19:35:16 <adamw> it seems a bit much to ask them to maintain a branch at beta/final time, every time
19:35:26 <adamw> and usually it's to our benefit to pull in the loosenings
19:35:44 <adamw> i'd want to be tighter on it after we pull -66, but i think for now we should just get a new build in so long as it doesn't cause major pain, then go from there
19:35:49 <adamw> +1 obviously
19:35:57 <tflink> other votes?
19:36:07 <nirik> could this be fixed post release?
19:36:07 <adamw> -50 is really pretty ancient by now
19:36:23 <adamw> the issues with building live images, no, obviously.
19:36:27 <nirik> I guess we are hosed if we need a new one for something else.
19:36:36 <adamw> i have kinda lost track of what all was broken in -50, that's so long ago now
19:37:26 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=886187 is also proposed as NTH
19:37:27 <bugbot_> Bug 886187: unspecified, unspecified, ---, mgrepl, MODIFIED , SELinux denials prevent mokutil from working
19:37:39 <adamw> which prevents you enrolling your own SB keys
19:37:50 <nirik> which version is that fixed in?
19:37:51 <tflink> but that's fixable post-release
19:37:56 <adamw> if anyone would be happier taking that one - if we take that one, though, we have to take this one, so we don't pull a selinux-policy update which stops us rolling live images...
19:38:02 <adamw> true.
19:38:10 <adamw> is anyone seriously wanting to ship final with -50?
19:38:14 <adamw> it just seems a bit obstinate...
19:38:46 <adamw> i guess i can waste some time to look through the changelogs and try to propose every bug i find between -50 and -66 which i think should be nth, but geesh.
19:38:47 * nirik just doesn't want more things broken, but ok, +1...
19:38:48 <tflink> proposed #agreed 886733 - AcceptedNTH - while not absolutely critical, it would make a positive difference in the livecds and is not entirely fixable post-release. A tested fix would be considered past freeze.
19:38:58 <nirik> ack
19:39:09 <cmurf> ack
19:39:23 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=873355 relates to xen
19:39:24 <adamw> ack
19:39:25 <bugbot_> Bug 873355: unspecified, unspecified, ---, mgrepl, CLOSED CURRENTRELEASE, avc:  denied  { read } for  pid=12901 comm="xend" name="para.img" dev="dm-1" ino=1443697 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
19:39:33 <adamw> oh, hey, -60 went stable
19:39:39 <tflink> #agreed 886733 - AcceptedNTH - while not absolutely critical, it would make a positive difference in the livecds and is not entirely fixable post-release. A tested fix would be considered past freeze.
19:39:45 <adamw> so now we *do* need this specific one to be nth. since -60 results in borked lives. so yay.
19:40:09 <tflink> OK, the next one is a bit non traditional but it'll save time
19:40:34 <tflink> #topic Oversize issues for secondary DE spins
19:40:54 <tflink> #info Covers 887120 , 887991 , 853590
19:41:09 <adamw> and any others that crop up later
19:41:20 <nirik> yeah, I am puzzled how they grew.
19:41:24 <adamw> in general: we should say that any non-blocking spin being oversize is automatically NTH and can be marked as such without explicit discussion
19:41:27 <tflink> proposed #agreed In principle, we agree that oversize issues for secondary DE spins are accepted as NTH
19:41:28 <nirik> by a lot. during freeze.
19:41:38 <adamw> nirik: spin-kickstarts and comps aren't frozen, remember
19:41:40 <adamw> langpacks?
19:41:44 <tflink> proposed #agreed In principle, we agree that oversize issues for secondary DE spins are accepted as NTH without explicit discussion for F18
19:41:45 <adamw> ack
19:41:55 <nirik> sure, I know, but I watch those...
19:42:26 * nirik will dig around on it.
19:42:28 <nirik> ack
19:42:29 <adamw> thanks
19:42:34 * adamw just found one more
19:42:42 <adamw> er, not a size issue, another bug to do after this
19:42:42 * tflink is +1 on this, for the record
19:42:58 <tflink> #agreed In principle, we agree that oversize issues for secondary DE spins are accepted as NTH without explicit discussion for F18
19:43:02 <tflink> adamw: bzid?
19:43:03 <adamw> final bug to do - https://bugzilla.redhat.com/show_bug.cgi?id=887996
19:43:06 <bugbot_> Bug 887996: high, unspecified, ---, anaconda-maint-list, NEW , liveinst fails in f18 Soas TC3 Could not open x display - no protocol specified
19:44:16 <tflink> #topic (887996) liveinst fails in f18 Soas TC3 Could not open x display - no protocol specified
19:44:19 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=887996
19:44:20 <bugbot_> Bug 887996: high, unspecified, ---, anaconda-maint-list, NEW , liveinst fails in f18 Soas TC3 Could not open x display - no protocol specified
19:44:21 <tflink> #info Proposed NTH, anaconda, NEW
19:44:44 <tflink> blocks SoaS install, right?
19:44:48 <satellit> yes
19:44:48 <tflink> if so, +1 NTH
19:44:56 <jreznik> +1 nth
19:45:28 <tflink> proposed #agreed 887996 - AcceptedNTH - This breaks install of SoaS which, as a secondary DE, is a NTH issue for F18 final.
19:45:39 <tflink> ack/nak/patch?
19:46:11 <adamw> ack
19:46:11 <nirik> ack
19:46:42 <tflink> #agreed 887996 - AcceptedNTH - This breaks install of SoaS which, as a secondary DE, is a NTH issue for F18 final.
19:46:51 <tflink> OK. I do believe that is it for today
19:47:14 <tflink> Anything I missed?
19:47:29 <adamw> nope, it'd be nice to cover dledford's pile of bugs, but i should get some clarification from him on those first
19:47:34 <adamw> i'll try and do that for tomorrow
19:47:37 <nirik> oh...
19:47:44 <tflink> yeah, I'll be better prepared for tomorrow as well
19:47:45 <nirik> what about the ocaml thing? was that already accepted?
19:48:23 * nirik looks
19:48:44 <tflink> I don't remember, to be honest
19:49:08 <nirik> hum.
19:49:16 <nirik> .bug 877128
19:49:18 <bugbot_> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=877128 high, low, ---, rjones, ON_QA , Ocaml tries to allocate a ridiculous amount of memory
19:49:19 <zodbot> nirik: Bug 877128 Ocaml tries to allocate a ridiculous amount of memory - https://bugzilla.redhat.com/show_bug.cgi?id=877128
19:49:38 <nirik> it never got nominated?
19:49:39 <nirik> :(
19:49:42 <adamw> whoops, sorry, missed that
19:49:46 <adamw> it's nominated as beta blocker
19:49:52 <nirik> neat.
19:49:58 * nirik gets in his time machine and...
19:50:14 <tflink> beta nth
19:50:14 <adamw> we should do it
19:50:16 <tflink> not blocker
19:50:19 * adamw fixes that up
19:50:24 <adamw> ok, it's now nominated as final NTH
19:50:33 <adamw> or will be when bugzilla responds
19:50:37 <agrimm> sorry, guys, I'm new to this meeting and process - just looked through the logged to see if my NTH was discussed.  seems like not
19:51:06 <agrimm> are you just covering a subset?
19:51:16 <adamw> yes, a very arbitrarily chosen one
19:51:22 <adamw> since we're already spending like 3 hours a day on these meetings
19:51:26 <adamw> let's do 877128 ?
19:51:29 <agrimm> ok, no problem, then
19:51:30 <agrimm> thanks
19:51:37 <adamw> which one was yours?
19:51:43 <agrimm> .bug 886963
19:51:45 <bugbot_> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=886963 unspecified, unspecified, ---, mspaulding06, ON_QA , Update eucalyptus to 3.2
19:51:46 <zodbot> agrimm: Bug 886963 Update eucalyptus to 3.2 - https://bugzilla.redhat.com/show_bug.cgi?id=886963
19:51:56 <tflink> #topic (877128) Ocaml tries to allocate a ridiculous amount of memory
19:51:56 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=877128
19:51:56 <tflink> #info ProposedNTH, ocaml, ON_QA
19:51:58 <bugbot_> Bug 877128: high, low, ---, rjones, ON_QA , Ocaml tries to allocate a ridiculous amount of memory
19:52:00 <agrimm> not a blocker at all.  rbergeron simply suggested proposing it
19:52:21 <adamw> okay, thanks
19:52:28 * nirik is +1 NTH on this one.
19:52:33 <adamw> so on ocaml...it looks like we kinda have to take this, even though it sucks.
19:52:34 <adamw> +1
19:53:04 <tflink> I don't pretend to understand why it has to be fixed before release but will go along with it
19:53:29 <tflink> but some justification would help for the summary
19:53:38 <adamw> true
19:53:41 <nirik> it could affect (although I don't know if it does) xen
19:53:52 <nirik> but thats more xen dom0 side...
19:53:58 <adamw> llvm and xen i think
19:54:10 <nirik> llvm might be more critical.
19:54:25 <nirik> but I don't know if the bug actually hits there.
19:54:47 <nirik> is unison on the media?
19:54:54 <tflink> I don't think so
19:54:56 <adamw> me either. i just know those are the two packages we found as critpath.
19:55:00 * adamw pinged rwmjones
19:55:06 <adamw> if we're going to take this we need to do it asap i think
19:55:10 <nirik> yes.
19:55:13 <adamw> punt would be a bad option
19:55:30 <nirik> in fact we should really try hard to get all the accepted nth's karmed and pushed asap.
19:55:39 <nirik> and then stop accepting them. ;)
19:56:35 <nirik> punt asking for better justification?
19:57:30 <cmurf> i have an nth in mind that should be easy but today vs tomorrow probably won't make a bit of difference
19:58:39 <tflink> is breaking ABI enough justification?
19:59:13 <adamw> there are exceptions in the update SOP for doing updates for API breaks...
19:59:37 <tflink> sure but it would be nice not to do that with a 0-day update
19:59:54 <adamw> i guess we can wave it through for the ABI thing, whatever.
19:59:55 <tflink> I'm still a little uncomfortable with this - I don't have any idea what all this could affect
20:00:35 <tflink> I didn't know graphviz had ocaml in it
20:00:37 * nirik thinks it's likely pretty safe, but also not sure it couldn't be a 0 day now.
20:01:26 <adamw> rwmj didn't respond/
20:01:56 <nirik> punt to tomorrow?
20:02:50 <adamw> i guess.
20:03:09 <adamw> i can't find any reasoning in bug or in thread as to why it has to go into release.
20:03:10 * nirik is a weak +1 to taking it, but punting is also fine
20:03:39 <tflink> proposed #agreed 877128 - We're not quite sure why this has to be fixed before release, will re-visit when there is more justification available
20:04:02 <nirik> ack
20:04:19 <adamw> ack
20:04:25 <cmurf> ack
20:04:34 <tflink> #agreed 877128 - We're not quite sure why this has to be fixed before release, will re-visit when there is more justification available
20:04:44 <tflink> OK, I think that's all for today since we're over 3 hours
20:04:58 <tflink> #topic Open Floor
20:05:08 <tflink> Anything else that needs to be brought up today?
20:05:39 <adamw> we could do agrimm's
20:05:47 <adamw> it didn't look that important from the summary but there's a wrinkle in the bug report
20:05:54 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=886963
20:05:56 <bugbot_> Bug 886963: unspecified, unspecified, ---, mspaulding06, ON_QA , Update eucalyptus to 3.2
20:06:05 <tflink> yeah, I was probably -1 on that
20:06:42 <adamw> well, read it
20:06:56 <adamw> "Also, the eucalyptus 3.1.2 package which is currently in the F18 repo has a couple of critical bugs, including incorrectly formatted systemd macro usage in the preun script which causes uninstall / update attempts to fail."
20:06:57 <tflink> yeah, definitely a strong -1
20:07:13 <adamw> if the current package has a bug that makes updates fail, then we can't really cleanly fix this bug with an update...
20:07:54 <nirik> icky
20:08:17 <tflink> I really don't like poking at jboss, hibernate and spring this late
20:08:17 <adamw> maybe we could split that out and say _that's_ the nth bug, but then they'd just push this update to fix it, so...eh.
20:08:29 <adamw> well it's the jboss/hibernate/spring people who want us to do it
20:08:39 <tflink> it is?
20:08:46 <tflink> I thought this was for  euca
20:08:50 <adamw> oh, sorry, i thought andy was to do with that.
20:08:52 <agrimm> it's a combination
20:08:53 <adamw> true.
20:09:11 <agrimm> mgoldmann also wants updates for jboss which are conflated with this
20:09:30 <tflink> I'm still strongly -1 on this unless I'm missing something
20:09:56 <tflink> I suppose I should change the topic, though
20:10:14 <tflink> #topic (886963) Update eucalyptus to 3.2
20:10:14 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=886963
20:10:14 <tflink> #info Proposed NTH, eucalyptus, ON_QA
20:10:15 <agrimm> the only reasons to do it are 1) the 3.1 package is broken, and 2) a minor version bump as a 0-day looks silly
20:10:16 <bugbot_> Bug 886963: unspecified, unspecified, ---, mspaulding06, ON_QA , Update eucalyptus to 3.2
20:11:00 <adamw> agrimm: how bad is the problem with updates/uninstalls?
20:11:01 <agrimm> but that timing on the bump is my fault, not yours, of course.  I just didn't get coordinated with mgoldmann fast enough
20:11:07 <adamw> is it just 'you get an error message spat out' or something worse?
20:11:15 <agrimm> adamw, ummm, the pre script fails
20:11:21 <agrimm> you have to rpm -e --noscripts
20:11:43 <adamw> i'd probably be +1 nth on *that*.
20:12:00 <adamw> tflink, wdyt?
20:12:03 <tflink> yeah, I'd be +1 nth on a fix for that, I just don't like the other stuff coming along
20:12:06 <nirik> how many other changes are there in this tho?
20:12:21 <adamw> well in theory if we take that as nth they could do a smaller fix for it, though i don't know if they would.
20:12:51 <adamw> we can vote -1 on this and ask them to split that out, i guess.
20:13:03 <adamw> i'm ok with -1 on the general 'we want a higher version' bug.
20:13:12 <agrimm> adamw, ok, we need to talk about hibernate separately then
20:13:26 * nirik is a weak +1 I guess... but notes the update has 0 karma so far.
20:14:04 <tflink> i'd say -1 for now
20:14:49 * agrimm wonders if eucalyptus 3.1 can simply be pulled from the release entirely, and 3.2 can just be a 0-day addition
20:14:54 <adamw> -1 to this one.
20:14:58 <adamw> agrimm: not...really.
20:15:01 <tflink> proposed #agreed 886963 - RejectedNTH - While the packaging bug mentioned here would be enough for NTH, it would need to be separated out by itself instead of as part of a version upgrade for multiple components. Would re-consider for a separated out fix
20:15:06 <adamw> ack
20:15:21 <nirik> ack
20:15:52 <tflink> #agreed 886963 - RejectedNTH - While the packaging bug mentioned here would be enough for NTH, it would need to be separated out by itself instead of as part of a version upgrade for multiple components. Would re-consider for a separated out fix
20:15:59 <tflink> #topic Open Floor
20:16:20 <tflink> unless there are other topics that have to be brought up today, I propose we be done
20:16:47 <tflink> we're over 4 hours for qa meetings today
20:17:18 <tflink> #info Next blocker/NTH review meeting will be tomorrow, 2012-12-18 at 17:00 UTC
20:17:31 * adamw is fine with being done
20:18:24 * tflink sets fuse for some period of time
20:18:31 * tflink will send out minutes shortly
20:18:42 <tflink> Thanks for coming everyone!
20:18:45 <tflink> #endmeeting