17:00:55 #startmeeting f18-alpha-blocker-review-2 17:00:55 Meeting started Fri Aug 10 17:00:55 2012 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:58 #meetingname f18-alpha-blocker-review-2 17:00:58 The meeting name has been set to 'f18-alpha-blocker-review-2' 17:01:04 #topic Roll Call 17:01:07 * nirik is lurking, but doing other things. please ping if I can help. 17:01:11 Who's here to join in the fun? 17:01:42 There are a couple of seemingly important libraries that got blocked in F18. These may affect rebuilds of critical components and hence could affect getting a release ready. 17:02:10 brunowolff: do you know which libs those are off hand? 17:02:39 Trying to remove either libfft or libimobiledevice takes a lot of key stuff with them. 17:03:04 I suppose we'll find out when TC1 is spun up :-/ 17:03:15 blocked? 17:03:28 * nirik looks 17:03:29 yo 17:03:30 Yes they appear to have been blocked. 17:04:37 i don't see any kind of notice related to them? 17:04:47 libimobiledevice failed the f18 mass rebuild, but... 17:04:59 They were probably on the FTBFS list. 17:05:22 there are not blocked that I see. 17:05:25 they're not in the mail 'Updated list (was: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18)' 17:05:34 brunowolff: you possibly are looking at the broken deps report from branched? 17:06:06 I am looking at my orphan (as not in repo) list. 17:06:25 what repo(s) are you pointing to? 17:06:43 A local copy of f18 (branched). 17:06:51 from when. 17:06:58 This morning. 17:07:06 I suspect from before dennis tagged in all those things that were not built in f18 17:07:06 http://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/Packages/l/ doesn't seem to have a libimobiledevice, it's true. 17:07:21 ah, it also has nothing with fc17. 17:07:22 yeah, they might not have landed in the last compose 17:07:31 * nirik notes he actually mailed the list about this. 17:07:49 the last compose might not have synced over, it should next time 17:07:56 OK, then I won't worry about it now. 17:07:58 or, heck, let me go try and make it. 17:09:04 yeah, they should appear... 17:09:09 not that they shouldn't also be fixed. 17:10:41 brunowolff: are you staying for the review meeting? 17:10:50 * tflink is trying to figure out if we have enough people 17:11:00 * Martix is here 17:11:02 Yeah. 17:11:02 * adamw is around. 17:11:25 cool, we have enough. let's get started with the wonderfully awesome boilerplate! 17:11:32 #topic Introduction 17:11:47 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:12:01 I am not feeling too well, but should be able to participate enough to be useful. 17:12:19 We'll be following the process outlined at: 17:12:19 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:12:19 The bugs up for review today are available at: 17:12:19 #link https://fedoraproject.org/wiki/Current_Release_Blockers 17:12:19 The criteria for release blocking bugs can be found at: 17:12:22 #link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 17:12:24 #link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria 17:12:31 #link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria 17:12:40 We have the following bugs to review: 17:12:43 #info 1 Proposed Blockers 17:12:43 #info 2 Accepted Blockers 17:12:43 #info 0 Proposed NTH 17:12:44 #info 0 Accepted NTH 17:13:05 The list of blocker bugs is available at: http://supermegawaffle.com/blockerbugs/current 17:13:22 soon to be moved to a fp.o domain, once I get it deployed 17:13:33 anyhow, any objections to starting with the proposed blocker? 17:13:41 tflink: actually have 2 Proposed Blockers 17:13:49 tflink: see the page 17:13:58 bah, it was added since I generated my list 17:15:12 #undo 17:15:12 Removing item from minutes: 17:15:14 #undo 17:15:14 Removing item from minutes: 17:15:15 #undo 17:15:15 Removing item from minutes: 17:15:17 #undo 17:15:17 Removing item from minutes: 17:15:26 #info 2 Proposed Blockers 17:15:26 #info 2 Accepted Blockers 17:15:26 #info 0 Proposed NTH 17:15:26 #info 0 Accepted NTH 17:15:42 #info (796479) firewalld conflicts with libvirt's default network 17:15:42 #link https://bugzilla.redhat.com/show_bug.cgi?id=796479 17:15:42 #info Proposed Blockers, ASSIGNED 17:15:44 Bug 796479: high, unspecified, ---, laine, ASSIGNED , firewalld conflicts with libvirt's default network 17:16:05 so, i couldn't really check this yet as we don't have any vaguely bootable f18 images 17:16:18 but in theory now we turned firewalld on again, it might start happening 17:16:55 oh, right, it also depends on the host, which makes things tricky as well 17:17:21 since we're in the middle of branching still i can't really upgrade to f18...if anyone has an f18 host already they could enable firewalld and check if a vm's networking works 17:17:48 * tflink doesn't have anything installed yet 17:18:02 otherwise we'll probably just have to punt this to next week 17:18:32 yeah, sounds like it to me 17:18:34 adamw: I just upgraded to F18, but I cant login to VT and GDM isnt starting, see next proposed blocker 17:18:58 only singleuser mode is reachable for me 17:19:37 apparently, I don't fix bugs if I don't write them down :-/ 17:19:41 #topic (796479) firewalld conflicts with libvirt's default network 17:20:24 #info requires an f18 host to be sure of current status, no-one here has an f18 host to test with yet 17:20:27 I have a couple of f18 systems, one of which I rebooted 3 days ago successfully. 17:20:29 proposed #agreed - 796479 - Due to being in the middle of branching, we don't currently have any install media to test this with. Will re-visit next week after we've had the opportunity to test it more 17:20:35 ack 17:20:45 #chair adamw 17:20:45 Current chairs: adamw tflink 17:21:05 #info requires an f18 host to be sure of current status, nobody here has an f18 host to test with yet 17:21:17 I should have thought a little harder before re-typing that 17:21:22 brunowolff: are you able to test this? 17:22:55 I am not sure what I need to do to test it. I am currently typing on a machine that is f18/rawhide from just before the branch. I haven't 17:23:35 brunowolff: iirc, just run a virt guest and see if it can get network access 17:23:45 but make sure the host is using firewalld 17:23:59 tried to update it today yet, since I was going to stay on rawhide and haven't got my local rawhide mirror updated yet. (I am grabbing f18/branched first to upgrade a couple of other machines.) 17:25:01 I have pretty old hardware (circa 2003), is that going to work on it? 17:25:14 brunowolff: can it do virt? 17:25:31 I don't think it has hardware support for it. 17:25:43 I haven't ever tried it before. 17:25:54 ok, probably not worth holding the meeting for then 17:26:03 yep 17:26:07 any other ack/nak/patch? 17:26:40 ack 17:26:58 #agreed - 796479 - Due to being in the middle of branching, we don't currently have any install media to test this with. Will re-visit next week after we've had the opportunity to test it more 17:27:07 #topic (841451) polkitd doesn't start in rawhide 17:27:08 #link https://bugzilla.redhat.com/show_bug.cgi?id=841451 17:27:08 #info Proposed Blocker, NEW 17:27:09 Bug 841451: unspecified, unspecified, ---, davidz, NEW , polkitd doesn't start in rawhide 17:27:47 cite: "When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should boot to a state where it is possible to log in through at least one of the default virtual consoles" 17:28:36 this bug block VT initialization and prevents GDM from starting 17:28:45 how widespread is this? 17:28:45 oh, i love those 'error: success' ones. 17:29:19 Martix: if you boot runlevel 3 you can probably get a console, i don't think it'll bother with polkit in that case. 17:29:26 but yeah, still a blocker. 17:29:51 assuming that it still happens to a fresh F18 install, yes 17:30:09 it sounds like the reporter was using a rawhide system that may or may not have been upgraded to F18 17:30:29 It's nopt running on my machine, but I was able to login about 3 days ago. (I am not sure if it was running then.) 17:30:51 I get the following: 17:30:53 # systemctl status polkitd.service 17:30:54 polkitd.service 17:30:54 Loaded: error (Reason: No such file or directory) 17:30:54 Active: inactive (dead) 17:31:17 i have that in a live image i span up a week ago, too. 17:31:34 brunowolff: I yum ditro-sync 'ed today to branched F18 17:31:51 Martix: and that's when you started seeing this bug? 17:32:39 tflink: distro-sync 'ed from F17, yes 17:33:25 Martix: does reinstalling polkit fix it for you? 17:33:52 tflink: should I reboot to runlevel 3 and try it? 17:34:55 Martix: having confirmation that a reinstall fixes it would be good 17:35:17 * tflink hesitates accepting this as a blocker without confirmation that it happens on F18 fresh installs 17:35:30 or with supported upgrade methods, for that matter 17:35:32 ok, give me a time 17:35:32 yeah...i think we might want to punt again. we really need some kinda image to test 17:35:53 upgrade is beta stuff, so theoretically if this happened on upgrade but not fresh install, it'd be beta blocker anyhow, not alpha. 17:36:30 proposed #agreed - 841451 - This seems like it could be blocker material but we need more information on whether it affects F18 fresh installs or supported upgrade methods before making a decision on blocker status 17:36:34 ack/nak/patch? 17:37:14 ack 17:38:16 It looks like polkitd is somethinf left over. The polkit service appears to start polkitd now. 17:38:35 # systemctl status polkit.service 17:38:36 polkit.service - Authorization Manager 17:38:36 Loaded: loaded (/usr/lib/systemd/system/polkit.service; static) 17:38:36 Active: active (running) since Tue, 07 Aug 2012 01:39:10 -0500; 3 days ago 17:38:36 Docs: man:polkit(8) 17:38:36 Main PID: 1623 (polkitd) 17:38:38 CGroup: name=systemd:/system/polkit.service 17:38:40 └ 1623 /usr/lib/polkit-1/polkitd --no-debug 17:38:42 Aug 07 01:39:10 bruno.wolff.to polkitd[1623]: Started polkitd version 0.107 17:38:44 Aug 07 01:39:10 bruno.wolff.to polkitd[1623]: Loading rules from directory /...d 17:38:46 Aug 07 01:39:10 bruno.wolff.to polkitd[1623]: Loading rules from directory /...d 17:38:48 Aug 07 01:39:10 bruno.wolff.to polkitd[1623]: Finished loading, compiling an...s 17:38:50 Aug 07 01:39:10 bruno.wolff.to polkitd[1623]: Acquired the name org.freedesk...s 17:38:52 Aug 07 01:39:25 bruno.wolff.to polkitd[1623]: Registered Authentication Agen...) 17:38:54 Aug 07 01:39:52 bruno.wolff.to polkitd[1623]: Unregistered Authentication Ag...) 17:38:56 Aug 07 01:40:25 bruno.wolff.to polkitd[1623]: Registered Authentication Agen...) 17:40:49 #info it appears as if polkitd is no longer used and polkit is the new service 17:40:57 #agreed - 841451 - This seems like it could be blocker material but we need more information on whether it affects F18 fresh installs or supported upgrade methods before making a decision on blocker status 17:41:34 OK, on to the accepted blockers even though I assume that they're both going to fall under the same "we have nothing to test with, punt til next week" resolution 17:41:38 #topic (835867) systemd-journald is running as kernel_t 17:41:38 #link https://bugzilla.redhat.com/show_bug.cgi?id=835867 17:41:39 #info Accepted Blocker, MODIFIED 17:41:39 Bug 835867: unspecified, unspecified, ---, systemd-maint, MODIFIED , systemd-journald is running as kernel_t 17:42:18 i'm about 99.9% sure this is fine now, but it'd be nice for the original reporters to chime in. 17:43:57 proposed #agreed - 835867 - It appears as if this has been fixed but none of the original reporters have confirmed the fix. Ask for re-testing and feedback. 17:44:02 ack/nak/patch? 17:45:20 On my system I get: 17:45:25 system_u:system_r:syslogd_t:s0 840 ? Ss 0:32 /usr/lib/systemd/syst 17:45:42 So it is running as syslogd_t here. 17:46:03 i don't really care what it's running as, the question is just whether the system boots okay in enforcing, afaict =) 17:46:25 I was able to boot 3 days ago in enforcing mode. 17:49:03 it still sounds a bit like we might want to wait for more confirmation, though 17:49:53 right. 17:50:50 #agreed - 835867 - It appears as if this has been fixed but none of the original reporters have confirmed the fix. Ask for re-testing and feedback. 17:51:01 #topic (844504) FTBFS in Rawhide with gphoto 2.5.0 17:51:02 #link https://bugzilla.redhat.com/show_bug.cgi?id=844504 17:51:02 #info Accepted Blocker, NEW 17:51:03 Bug 844504: urgent, unspecified, ---, tbzatek, NEW , FTBFS in Rawhide with gphoto 2.5.0 17:51:32 it sounds like there hasn't really been progress on this since last week 17:52:18 well, the *other* one was fixed 17:52:22 so devs are clearly working on it 17:52:41 back 17:52:48 someone mixed up those two bugs. gvfs has been fixed, shotwell not. 17:52:56 tflink: tbzatek is on PTO until September 10 17:53:28 844504 should be closed, and 844510 reopened. 17:53:31 Martix: good to know, it should probably be assigned to someone else, then 17:53:57 polkit.service is running after yum reinstall, VT login works, but GDM didnt started 17:53:58 ah crap 17:54:06 i just figured that jnovy screwed things up somewhat 17:54:13 yep. 17:54:14 hold on while i fix things 17:54:31 and BTW I'm unable to mount rootfs with current 3.6 kernel, so I used 3.4 17:55:30 brunowolff: what kernel version do you run? 17:55:56 3.6.0-0.rc1.git0.2.fc18.i686.PAE 17:56:17 brunowolff: do you use LUKS and LVM? 17:56:22 I stick with the nondebug kernels because I have a big performance hit otherwise. 17:56:46 I use luks, but not lvm. 17:57:06 root, home and swap are all encrypted. 17:57:29 OK, 844504 is closed; gvfs was fixed 17:57:40 844510 is re-opened; that's the correct 'active' bug, as shotwell is not yet fixed 17:57:55 #info 844504 is actually fixed; gvfs has been rebuilt. bug closed. 17:58:07 go ahead and topic up 844510, tflink 17:59:34 #topic (844504) FTBFS in Rawhide with gphoto 2.5.0 17:59:34 #link https://bugzilla.redhat.com/show_bug.cgi?id=844504 17:59:34 #info Accepted Blocker, NEW 17:59:36 Bug 844504: urgent, unspecified, ---, tbzatek, CLOSED ERRATA, FTBFS in Rawhide with gphoto 2.5.0 18:00:26 nope. 18:00:40 try it again. =) 18:00:40 damn it 18:00:45 #undo 18:00:45 Removing item from minutes: 18:00:47 #undo 18:00:47 Removing item from minutes: 18:00:49 #undo 18:00:49 Removing item from minutes: 18:01:27 #topic (844510) FTBFS in Rawhide with gphoto 2.5.0 18:01:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=844510 18:01:27 #info Accepted Blocker, NEW 18:01:29 Bug 844510: urgent, unspecified, ---, mclasen, ASSIGNED , FTBFS in Rawhide with gphoto 2.5.0 18:02:22 okey dokey 18:02:40 now that the patch has been "moved" ... 18:02:59 it sounds like there hasn't been much in the way of progress on this since last week 18:03:07 so, shotwell still needs fixing. as it says, 'Thomas Moschny is looking into it.' 18:03:10 (same comment, different bug) 18:03:31 well, I hadn't time and will not have until next week. 18:03:33 the urgency has been trasmitted upstream - http://redmine.yorba.org/issues/5553 18:03:57 thm_: that's still within schedule, though it means we'll have to drop shotwell from at least the first couple of tcs most likely 18:04:27 could ping upstream again, meanwhile. 18:05:50 okay. 18:05:52 #info This still isn't fixed, shotwell will likely need to be removed from the first couple F18 alpha TC/RCs 18:05:53 thanks for the update. 18:06:03 ahahahaha, RC. how you kid. 18:06:27 we'll get there eventually 18:07:09 if our livers hold out. 18:07:54 #info upstream is aware of the issue, seems willing to help us get something working for F18 18:08:00 anything else to mention on this bug? 18:08:22 what about a compat package as last rescue? 18:08:43 thm_: that's an option, yeah, but...it seems like a lot of work for a single package, really 18:08:56 thm_: i don't think it's really crucial to have shotwell on early alpha builds, tbh 18:09:05 ok. 18:09:29 cataloging your lolcats is not an alpha objective =) 18:09:50 lol. 18:09:59 what ?! why am I testing this stuff if I can't haz cheeseburger? 18:11:05 anyhow, I think that's it for the bugs today unless there are some that I missed 18:11:15 #topic Open Floor 18:11:32 #info As a reminder, the blocker meeting times will be changing starting next week 18:11:49 #info Future blocker review meetings will be on Wednesdays at 16:00 UTC 18:11:54 #undo 18:11:54 Removing item from minutes: 18:12:20 #info Future blocker review meetings will be on Wednesdays at 16:00 UTC (time will change with DST to keep consistency with the QA meetings) 18:12:38 any other topics to bring up? 18:12:51 nope...we're really waiting on composes to get crackin', sigh. 18:13:09 is there anything in particular that's blocking the compose? 18:15:14 I haven't heard much on the switch to livemedia-creator for the live images. 18:15:30 that's been on the back of my mind 18:15:55 I suppose that we're going to need to start testing it to see if it works at some point, though 18:16:18 the koji support still isn't there. ;( 18:16:37 this sounds like it's going to be fun :-/ 18:16:48 dgillmore was thinking perhaps just composing them manually for alpha and add support for koji when it's available 18:17:03 I think livemedia-creator needs ks changes too 18:17:15 I thought that there was still some question about whether it even worked for F18 yet 18:17:22 outside of koji, even 18:17:56 yeah, not sure. 18:18:16 current images made with livecd-creator I think can't start X right due to ordering. ;) 18:18:27 fun 18:18:49 I know that we dropped support for livemedia-creator in the image building app due to not being able to figure it out fast enough 18:19:00 but that's going to need to change soon 18:19:48 anyways, it sounds like there's nothing else to bring up at the moment 18:19:59 * tflink sets the fuse for [0,5] minutes 18:24:29 #info Next blocker review meeting will be 2012-08-15 @ 1600 UTC 18:24:43 Thanks for coming, everyone 18:24:49 * tflink will send out minutes shortly 18:24:53 #endmeeting