16:01:30 #startmeeting f19beta-blocker-review-2 16:01:30 Meeting started Wed May 1 16:01:30 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:31 #meetingname f19beta-blocker-review-2 16:01:31 The meeting name has been set to 'f19beta-blocker-review-2' 16:01:31 #topic Roll Call 16:01:40 Who's ready for some blocker review fun time? 16:01:44 #chair adamw 16:01:45 Current chairs: adamw tflink 16:01:57 FUN!!!!! 16:02:00 * satellit listening 16:02:02 assuming we have enough people today with the holiday in the czech republic 16:02:36 * jreznik couldn't miss blocker fun just because of holidays... even he will be more "semi-present" ;-) 16:05:02 * nirik is lurking around. 16:06:24 * tflink waits a few more minutes in the hopes that more people will materialize 16:08:39 i think our transporter is down 16:10:11 increase power to the pattern buffers? 16:10:17 waiting a few more minutes and probably more people de-materialize - let's start :D 16:10:47 I canna' do it capn'. I just don't have the power! 16:10:57 * tflink attempts to channel scotty 16:11:15 hopefully we have enough to reach quorum, we'll see 16:11:44 #topic Introduction 16:11:50 Why are we here? 16:11:51 #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:12:07 #info We'll be following the process outlined at: 16:12:07 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:12:25 #info The bugs up for review today are available at: 16:12:25 #link http://qa.fedoraproject.org/blockerbugs/milestone/19/beta/buglist 16:12:34 #info The criteria for release blocking bugs can be found at: 16:12:34 #link https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria 16:12:37 #link https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria 16:12:39 #info Up for review today, we have: 16:12:46 #info 3 Proposed Blockers 16:12:46 #info 4 Accepted Blockers 16:12:46 #info 8 Proposed Freeze Exceptions 16:12:46 #info 2 Accepted Freeze Exceptions 16:13:03 if there are no objections, I'll start with the proposed blockers 16:13:07 let's call this meeting "blocker bug theory" meeting ! 16:13:21 jreznik: theory? 16:14:06 #topic (954371) F19 Alpha fedup hangs after booting 'System Upgrade' 16:14:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=954371 16:14:12 #info Proposed Blocker, fedup, ON_QA 16:14:42 oh, any volunteers for secretary duty? 16:14:48 sure 16:14:55 adamw: thanks 16:16:07 sounds like a blocker to me, but it also sounds fixed 16:16:39 i think we'll have to decide on a policy for handling 'blocker' bugs in fedup that affect the code from the previous release 16:17:08 we have a precedent from a few other bugs but it's probably going to crop up more often with fedup 16:17:14 but with that caveat, yeah, obviously a blocker 16:17:16 oh yeah, that's right 16:17:48 I thought that we took them as blockers but they don't block spins 16:18:09 yeah, that's the precedent. we should probably write it down somewhere, make it a bit more organized etc. 16:18:16 true 16:18:40 especially since it gets confusing which parts of fedup are in Fn and which parts are in Fn-1 16:19:01 yep, it could be confusing (and in reality, it is) 16:19:21 proposed #agreed 954371 - AcceptedBlocker - Violates the following F19 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." 16:19:58 ack 16:20:03 ack 16:20:36 any more ack/nak-patch? 16:21:12 * adamw kicks nirik 16:21:35 #agreed 954371 - AcceptedBlocker - Violates the following F19 beta release criterion: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." 16:21:48 #topic (946906) Gnome fails QA:Testcase_Desktop_Updates 16:21:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=946906 16:21:49 #info Proposed Blocker, PackageKit, NEW 16:22:00 if it's a clear blocker, I'm ok with only 2 acks 16:23:38 hrm, this sounds like a bit of a technicality 16:23:41 robatino's gonna come and join us 16:23:57 the notification is shown but no icon remains in the tray 16:24:04 i'm here already, but not watching constantly 16:24:12 that's not a blocker, that's just how GNOME wants it to be 16:24:22 the initial report was the blocker, but bob says he's not seeing that any more 16:24:23 oh, ok 16:24:24 yep, I think it's by design 16:24:39 comment #4 16:24:41 well, kinda by design. i mean, this whole thing isn't really well designed at present 16:24:57 but there's no point picking this particular fail out from the larger pile of fail that is gnome's current update experience for special treatment :) 16:25:11 i'm -1/-1 16:25:25 proposed #agreed 946906 - RejectedBlocker - It was confirmed that the notification is displayed on more recent releases - the issue about persistent tray icons is by design and thus, outside the scope of the blocker process 16:25:40 adamw: the design is no tray icons anymore - so by design :) 16:26:25 * tflink wonders what is supposed to replace tray icons now, but that can wait for another time/place 16:26:26 jreznik: no, it's not talking abouit a tray icon 16:26:46 jreznik: it's talking about the icons at bottom right of the overview 16:27:01 am I using the wrong terminology? 16:27:03 usually when you get a notification and don't do anything about it, it goes and sits at bottom right until you do something about it 16:27:21 the 'you have updates' notification doesn't do that, for whatever reason. but i don't think that's really worth caring a lot about 16:27:40 hence -1/-1 16:27:51 adamw: ok, I'll try to avoid talking about gnome as I know how it looks like, I try it sometimes to see where it is but don't know all aspect of how it behaves... 16:28:16 ack/nak/patch? 16:29:02 adamw: I understand what are you talking about now, thanks for clarification 16:29:18 but than patch - do not talk about try icon 16:29:24 yeah 16:29:34 let's see 16:29:36 after the dash... 16:29:56 proposed #agreed 946906 - RejectedBlocker - It was confirmed that the notification is displayed on more recent releases - the issue about persistent notification alerts is by design and thus, outside the scope of the blocker process 16:30:04 nack 16:30:13 * tflink waits for patch 16:30:21 it's probably not good to say 'by design', it might not be. this whole thing is just a mess in general 16:30:39 how about ... 16:30:47 proposed #agreed 946906 - RejectedBlocker - It was confirmed that the notification is displayed on more recent releases. Whether the notification should persist as an icon and what it should do is beyond the scope of the criteria 16:31:04 ack 16:31:15 proposed #agreed 946906 - RejectedBlocker - It was confirmed that the notification is displayed on more recent releases. Anything beyond the initial notification is outside the scope of the blocker process 16:31:30 oh, that's pretty what adamw wrote 16:31:37 pick one! 16:31:39 either is fine with me 16:31:40 ackt to either 16:31:42 i like yours 16:31:56 * jreznik should write the third version :) 16:32:12 yep, tflink's sounds better 16:32:37 #agreed 946906 - RejectedBlocker - It was confirmed that the notification is displayed on more recent releases. Anything beyond the initial notification is outside the scope of the blocker process 16:33:39 #topic (957554) preupgrade dependancy conflicts with fedup - preventing fedup upgrade path 16:33:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=957554 16:33:45 #info Proposed Blocker, PackageKit, NEW 16:34:25 how has nobody else hit this? 16:34:29 i don't have this problem 16:34:36 * tflink wonders if something else is at play here 16:34:36 does he have an old PK? 16:34:44 or a pk extension 16:35:26 either way, I'm definitely not +1 16:35:34 either punt for clarification or reject 16:36:10 does nayone have an f18 system handy? 16:36:15 other thoughts? 16:36:19 * tflink does 16:36:25 poke around 16:36:28 * adamw powers his up 16:37:30 fedup installs fine 16:38:41 you know what 16:38:41 i wonder if he's on f17 16:38:47 i think he tried to install f19 fedup on f18 16:39:02 f18's fedup doesn't obsolete preupgrade 16:39:23 or he's on f19 and upgrading to rawhide 16:39:36 oh no 16:39:39 i've got it now 16:39:48 this was a bug and it was fixed in 0.7.3-4 16:39:57 * Tue Apr 30 2013 Will Woods 0.7.3-4 - Dependency fix: can't Obsolete preupgrade until F19 :/ 16:40:32 the obsolete was added in 0.7.3-2 16:40:42 neither that nor -3 went stable, so this only affects updates-testing = not a blocker 16:41:07 * tflink installed on f18 just fine from updates-testing 16:41:20 yes 16:41:21 i wonder if this is an issue installing fedup on f19 16:41:24 updates-testing has 0.7.3-4 16:41:26 NOW 16:41:28 ok, -1 then 16:41:30 oh 16:41:31 but it didn't yesterday 16:41:31 ok 16:42:37 proposed #agreed 957554 - RejectedBlocker - This is currently not an issue for installing fedup on F18 and thus, does not violate any of the F19 beta release criteria. 16:43:42 that's fine, or you can change it to reflect that we can close the bug, which I just did. 16:43:56 (no need to wait for it to be pushed stable, as the broken one was only ever in testing.) 16:45:50 proposed #agreed 957554 - RejectedBlocker - This is currently not an issue for installing fedup on F18 and thus the bug can be closed 16:46:50 ack 16:48:47 since it's already closed ... 16:48:57 #agreed 957554 - RejectedBlocker - This is currently not an issue for installing fedup on F18 and thus the bug can be closed 16:49:10 ok, that's all of the proposed blockers on my list 16:49:48 on to the proposed FE 16:50:22 hrm, do we want to be doing these so early? 16:50:43 several of them seem like clear -1s to me, thoujgh 16:51:26 we can knock them off if we have the time, sure 16:51:28 we don't *need* to 16:52:49 go through the "feduped system still has fc18 packages" bugs? 16:53:18 I'm fine either way 16:54:47 #topic (957922) gstreamer-plugins-bad-free-0.10.23-13.fc18.i686 or gstreamer-plugins-bad-free-0.10.23-13.fc18.x86_64 remains following fedup f18 --> f19 as no f19 rpm exists 16:54:51 we can do that, but I'd like to leave soon 16:54:51 #link https://bugzilla.redhat.com/show_bug.cgi?id=957922 16:54:53 #info Proposed Freeze Exceptions, gstreamer-plugins-bad-free, NEW 16:55:32 not an FE, not really a bug 16:55:52 well, 'this package hasn't been rebuilt' is probably a bug, but i'm sure it's filed already. 16:56:18 proposed #agreed 957922 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:56:28 ack 16:56:42 ack 16:56:45 #agreed 957922 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:56:49 #topic (957924) gstreamer-plugins-good-0.10.31-5.fc18.i686 or gstreamer-plugins-good-0.10.31-5.fc18.x86_64 remains following fedup F18 --> f19 16:56:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=957924 16:56:54 #info Proposed Freeze Exceptions, gstreamer-plugins-good, NEW 16:57:02 proposed #agreed 957924 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:57:31 ack 16:57:32 #agreed 957924 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:57:48 2 more :-/ 16:57:51 #topic (957926) NetworkManager-pptp-0.9.3.997-3.fc18.i686 or NetworkManager-pptp-0.9.3.997-3.fc18.x86_64 remains following fedup f18 --> f19 due to lack of fc19.rpm 16:57:54 #link https://bugzilla.redhat.com/show_bug.cgi?id=957926 16:57:56 #info Proposed Freeze Exceptions, NetworkManager-pptp, NEW 16:58:05 proposed #agreed 957926 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:58:15 ack 16:58:15 er, 3 more 16:58:22 #agreed 957926 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:58:22 ack ack ack ack ack ack 16:58:29 tell me when i can stop acking :) 16:58:30 #topic (957931) perl-Carp-1.26-242.fc18.noarch remains following fedup f18 --> f19 upgrade 16:58:33 #link https://bugzilla.redhat.com/show_bug.cgi?id=957931 16:58:36 #info Proposed Freeze Exceptions, perl, MODIFIED 16:58:41 adamw: prepare the ACK cannon :) 16:58:56 well, accept all bugs of the same kind in batch... 16:59:00 proposed #agreed 957932 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:59:00 i'm just going to close all of these as dupes of the existing FTBFS bugs, assuming they have them 16:59:03 oops 16:59:08 proposed #agreed 957931 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:59:13 wrong bzid 16:59:22 use one of my ack stockpile 16:59:22 #agreed 957931 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:59:31 #topic (957935) ustr-1.0.4-13.fc18.i686 or ustr-1.0.4-13.fc18.x86_64 remain following fedup f18 --> f19 due to no ustr.fc19.rpm 16:59:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=957935 16:59:36 #info Proposed Freeze Exceptions, ustr, NEW 16:59:46 proposed #agreed 957935 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 16:59:58 * tflink assumes more bill-the-cat sounds 17:00:05 #agreed 957935 - RejectedFreezeException - fc18 packages remaining on a system upgraded to fc19 does not impact the usability of the system and thus does not qualify as a Freeze Exception 17:00:09 ok, done with that 17:00:17 on to the accepted blockers 17:01:11 * tflink is going to skip the oversized spin bugs unless someone objects 17:02:00 #topic (948099) Apper ignores "never check for updates" option (also on the live image) 17:02:02 no objections, it's now more spy work to find out what we can cut 17:02:03 #link https://bugzilla.redhat.com/show_bug.cgi?id=948099 17:02:06 #info Accepted Blocker, PackageKit, MODIFIED 17:02:33 and they were just filed, no real progress yet 17:02:52 the fix for this one should be in TC1 17:02:58 so we ought to be able to test it there 17:03:00 it sounds like this might be an interesting one - for now it's been hacked around but I wonder if that's going to affect the post-install 17:03:11 seems like fix does not work 17:03:27 and it's now workarounded - looking on the last comment by rex 17:03:30 ie, whether update notifications happen post-install 17:03:59 tflink: post install it should work 17:04:18 the thing is - apper does not respect "never check for updates" 17:04:40 ok, I'm not 100% clear on how live install works and whether removing the applet would transfer to the installed system 17:04:42 on live cd, apper kded module is disabled, but only for liveuser 17:04:54 tflink: applet is not removed 17:04:58 ah, I didn't see that part 17:04:59 ok 17:05:15 just kded module that takes care of checking for updates is disabled for live user on live system 17:05:21 #info it sounds like the issue has been worked around for now, will need testing 17:05:40 doesn't look like it needs much from us 17:06:19 yeah, i'm trusting them to be on top of that 17:06:36 #topic (958436) Fedora 19 Beta TC1 install images do not boot correctly - fall to an emergency shell 17:06:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=958436 17:06:40 * jreznik will check with rex/lukas 17:06:41 #info Accepted Blocker, systemd, NEW 17:06:45 sounds like TC1 is DOA? 17:06:53 * tflink hasn't tried it yet 17:07:55 non-lives are, yeahg 17:08:04 3 or 4 confirmations so far, nice job by andre to use the automatic blocker 17:08:13 i haven't had time to poke at it yet though 17:08:46 ok, sounds like nothing to do from here, though 17:09:00 #info this was just filed, nothing to do at this poitn 17:09:03 #undo 17:09:03 Removing item from minutes: 17:09:05 #info this was just filed, nothing to do at this point 17:09:07 well we can probably help diagnose, but we just didn't yet :) 17:09:15 in a blocker meeting? 17:10:01 oh i didn't mean that 17:10:05 * satellit KDE live x86_64 installs fine 17:10:07 * satellit Beta TC1 17:10:38 #info all non-live components to beta TC1 seem affected 17:10:58 I do believe that's all for today 17:11:02 unless I missed something 17:11:09 i also noted in the bug that i can't run the file conflicts test due to sudden excessive resource requirements. that would be an automatic blocker if it failed. other people with more resources than me need to check it 17:11:12 * satellit afk... 17:11:34 requires the DVD 17:11:36 ok, thanks guys - I have to leave now... 17:11:37 either way, it sounds like something is pretty broken in TC1 17:11:43 robatino: yeah, i saw that, i was kinda thinking 'let's fix the crash and see if the file conflicts test problem still happens then' 17:11:48 yeah, clearly 17:11:48 jreznik: thanks for helping on a holiday :) 17:11:59 +1! 17:12:05 #topic Open Floor 17:12:15 i got up to 85% before it failed, with 4 GiB RAM. it's possible that someone with 8 GiB or more might be able to finish it 17:12:29 Anything else that should be brought up in the meeting? 17:12:55 * tflink is still working to get the /current redirect updated on the tracking app 17:13:19 hit some stuff in infra that made testing the fix difficult but it looks to be resolved now 17:13:31 will hopefully get that fixed later today 17:14:00 * adamw can't think of anything 17:14:58 * tflink sets the qa-patented non-deterministic fuse and hopes to walk away with all his fingers 17:15:03 should also note that the file conflicts test was up to 6 problems detected before it failed. normally there would be 3, so it would be really good to find out what those problems are 17:15:39 but i couldn't see what they were since my resource-starved box gave up 17:16:04 robatino: okay. i've got ram coming out of my ears over here so i'll give it a shot later 17:16:10 thanks 17:16:35 still, might want to run it in a VT to be safe. for me it was swapping like crazy near the end 17:17:07 sure 17:17:42 Thanks for coming, everyone 17:17:50 * tflink will send out minutes shortly 17:17:52 #endmeeting