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