16:00:05 #startmeeting QA meeting 16:00:05 Meeting started Mon Sep 14 16:00:05 2009 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:13 * dpravec is here :) 16:00:15 #topic gathering bodies 16:00:26 alright, which unfortunates have I snared in my nets? 16:00:56 * kparal is caught in the net 16:01:05 wwoods: kparal: oxf13: ping 16:01:09 hi, kamil 16:01:23 * wwoods appears in a puff of smoke 16:01:59 alrighty 16:02:20 #topic previous meeting followup 16:02:40 so for anyone who has only vague, possibly hallucinatory memories of our last meeting, there's a wrap-up at https://fedoraproject.org/wiki/QA/Meetings/20090831 16:03:32 for a quick item, the test-announce list is up and running and being used appropriately, so that's great, thanks again to dpravec for the idea 16:03:43 aside from that, there was one topic i definitely wanted to cover 16:03:50 #topic followup - zsync 16:04:14 that's my topic, alright 16:04:15 kparal: you were going to investigate the possibility of using zsync to reduce daily Rawhide image download sizes 16:04:22 i have written a blog: http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ 16:04:24 i think most of us probably saw your blog on the topic, but could you summarize? 16:04:27 :) 16:04:46 roughly about 40% of bandwidth can be saved by using zsync 16:04:52 kparal: awesome post - thanks for getting some hard data 16:04:55 measured on Fedora nightly images 16:05:12 #link http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ 16:05:19 (for the logs) 16:05:22 but I have talked to nirik and he said: 16:05:22 (16:59:19) nirik: kparal: we cannot use it until it's in fedora/epel. 16:05:22 (16:59:36) nirik: we don't use any non fedora/epel software if at all possible. 16:05:38 (17:02:27) nirik: kparal: ok. I had hoped the review request would have moved along somehow, but I don't think it has. ;( 16:05:57 i believe there's a problem involving a variant version of libz, right? 16:06:06 therefore although it would be interesting to use it, it seems that current policy is against it 16:06:15 yes, they use a forked library 16:06:23 same as rsync 16:06:31 what's the URL for the review request? 16:06:43 * kparal looking 16:06:55 https://fedorahosted.org/fesco/ticket/134 16:07:01 i believe that's it 16:07:02 #link https://fedorahosted.org/fesco/ticket/134 16:07:25 "zsync may not ship an embedded zlib " 16:07:49 adamw: I'm here. 16:07:53 there was: "Simo said that getting rsync/zlib into shape to use the system zlib and not break the on-wire format should not be hard." 16:07:54 sorry, I overslept 16:07:57 hi, oxf13 16:08:10 so if we're still interested in doing this, that looks like the avenue to follow up 16:08:22 are you aware of any technical problems with that, kparal? do you know if anyone's looking into it? 16:08:44 no, i haven't looked at it, i don't know 16:09:06 nirik could have more information though 16:09:14 * nirik looks up. 16:09:16 if you're still willing to push this further, that looks like the next avenue to go down :) 16:09:50 So, unless more has happened since I last checked, no one's contacted upstream rsync to see if they'll maintain a split out libz. 16:09:57 yeah, I think it was waiting for the packager(s) to talk with upstream for zsync and zlib and try and work something out. 16:10:30 adamw: Also, notting later corrected that it was someone other than simo (the package maintainer) who said it wouldn't be hard to make rsync use the standard zlib. 16:10:42 adamw: i think i will leave this task to more appropriate people, but i'm certainly interested in updates 16:10:54 it sounds to me like there may be a motivation gap here 16:11:21 is rsync still shipping a built-in zlib, at this point? is anyone specifically tasked with dealing with that? 16:11:27 My observation as well. 16:12:19 Nope and I don't think it will be without it blocking something. 16:13:18 hmm. that makes this somewhat more complicated. my inclination would be to try and get a discussion going with all stakeholders, or on -devel-list. any other ideas? 16:14:07 if not, i'll take an action item to follow up with you guys by email and see if we can come up with a strategy 16:14:23 on my blog Simon Wesp writes he tried to include zsync to fedora (https://fedoraproject.org/wiki/User:Cassmodiah). he could be also interested if we contact him 16:14:27 There's two ways forward -- either the forked zlib comes out into its own package or rsync/zsync figures out how to use the standard zlib. 16:14:31 yes, that's https://bugzilla.redhat.com/show_bug.cgi?id=490140 16:14:32 Bug 490140: medium, medium, ---, redhat-bugzilla, ASSIGNED, Review Request: zsync - Client-side implementation of the rsync algorithm 16:14:39 #link https://bugzilla.redhat.com/show_bug.cgi?id=490140 16:14:40 Bug 490140: medium, medium, ---, redhat-bugzilla, ASSIGNED, Review Request: zsync - Client-side implementation of the rsync algorithm 16:14:58 abadger1999: yes, what i'm interested in is how we get someone to actually start moving forward on one of those fronts :) 16:15:00 who's going to do the work for either of those is the question. 16:15:21 right. looks like we agree on the situation, we just need to figure out how to address it. ok. let's follow up on that after the meeting. 16:15:30 aside from that, on the larger topic, i did have one more question 16:16:02 assuming we got zsync in place and everything, how would we do it exactly? we've established we can save a decent amount of space between any two reasonably close images, but has anyone considered the most efficient system for providing particular deltas? 16:16:21 things would get out of hand rather fast from a storage / organization perspective if we tried to provide deltas from every image to every later image... 16:16:38 this is not about providing deltas 16:16:53 the zsync file is generated only from the source file 16:16:58 nothing more 16:17:00 oh, it works without providing delta files? ahhh. i misunderstood that. 16:17:02 ok, that makes it easier. 16:17:10 the differences are computed on the client 16:17:26 ok. from my side the topic's covered, then. any other comments? 16:17:31 the whole command it $zsyncmake -o bigfile.zsync 16:18:34 ok, then - moving on 16:18:43 wwoods, oxf13 - you guys ready to do an autoqa update? 16:18:52 I'm not.... 16:19:10 sure 16:19:13 we can do another topic first and come back to it later in the meeting if it'd help? 16:19:37 so autoqa is still doing its thing - see the results list 16:19:49 looks like our ppc host might be down - or maybe we didn't get a ppc tree today? 16:19:50 #topic autoqa update 16:19:53 I'll look into it 16:20:15 jlaska's on vacation for a couple weeks so I'm helping with autoqa monitor duties as well as development 16:20:26 (remember we had no meeting last week so anything from the last _two_ weeks is news) 16:20:37 anyway: https://fedorahosted.org/pipermail/autoqa-results/2009-September/thread.html 16:20:45 ooh let me check my records for a second 16:21:08 looks like no ppc images 16:21:21 Okay so: we fixed up the email output to show tracebacks when they happen 16:21:34 ooh. that's awesome. 16:21:42 fixed up the install test so it monitors both the serial console and the logs 16:21:57 I don't see images for any other arch either, so maybe I'm looking in the wrong place 16:22:06 install test will end immediately when it sees the "installation exited abnormally" message 16:22:19 wwoods: great news 16:22:29 Oxf13: so there's rats_sanity test results for today for x86_64 and i386 16:22:35 which indicates that the repodata updated, at the very least 16:22:40 both failed, though 16:22:48 repodata yes, images not so much it seems 16:23:11 right, no images appeared, which is why rats_install never even ran 16:23:14 https://fedorahosted.org/pipermail/autoqa-results/2009-September/000928.html 16:23:19 we have depsolving problems in the critpath 16:23:28 so we're on full red alert for today's rawhide 16:23:28 heh 16:23:30 python-cryptsetup-0.0.9-2.fc12.i686 from anacondarepo has depsolving problems --> Missing Dependency: libcryptsetup.so.0 is needed by package python-cryptsetup-0.0.9-2.fc12.i686 (anacondarepo) 16:23:34 Error: Missing Dependency: libcryptsetup.so.0 is needed by package python-cryptsetup-0.0.9-2.fc12.i686 (anacondarepo) 16:23:48 so, somebody fubared the critical path 16:24:22 nice to see how quickly autoqa can be used to pinpoint a problem :) 16:24:27 indeed 16:24:48 cryptsetup-luks got a soname bump on the 11th. 16:25:07 so it would be nice if there was a simple summary of these things.. like the 'israwhidebroken' page we've talked about 16:25:21 I started writing a TurboGears app to handle that stuff.. last week I guess? 16:25:30 and nobody bumped python-cryptsetup to match. 16:25:33 right, at the last meeting you had that on the list of 'things to do next' 16:26:06 I've got a personal git repo that contains the code I've been working on 16:26:28 which, er, I can't seem to find a good URL for at the moment 16:26:32 heh :) 16:26:45 wwoods: icannot open http://test1250.test.redhat.com/afe/ ... (connecting to ... for few minutes) 16:27:09 wait, maybe I'm wrong in my investigation. Need more time to look 16:27:25 ah: git://git.fedorapeople.org/~wwoods/israwhidebroken.git 16:27:41 no, I'm right. *sigh* 16:28:01 so far so good - it's doing FAS auth properly, has a list of the known rawhide tests, etc. 16:28:10 I'm working on automated result submission 16:28:23 wwoods: do you have publicly accessible web page with results? 16:28:28 dpravec: not yet, no 16:28:31 that's what I'm working on 16:28:40 also test1250 is gone - it changed hostname 16:28:48 it's test1185 now 16:29:02 god I really really want this holding ground between builds and rawhide so that we can run these test and throw out builds that break shit. 16:29:29 Oxf13: definitely, but we have to be confident in our tests first.. and have the tests running on something public 16:29:51 it would be pretty great if the rawhide tests could finish up by telling the builder whether or not to sync out the tree 16:30:15 we're much, much closer to that now 16:30:33 wwoods: I think it's too late by that point (sync the tree or not) 16:30:44 Oxf13: well, with the current watcher, yes 16:31:04 wwoods: the simple test of "does this build break deps", particularly in the critical path, should be an easy one to use to block builds from being tagged 16:31:25 ah, I see what you mean now 16:31:36 yeah, once we're more confident in the tests and the rest of the autoqa system, and it lives in the Infrastructure proper 16:31:39 then we can work on that 16:31:50 IIRC we have some hardware on order to get put in the lab for this 16:31:55 err s/lab/colo/ 16:31:59 alright, brainstorming we can do outside the meeting :) 16:32:06 but jlaska knows the details about that better than I do, so I can't say more 16:32:30 anyway - autoqa stuff is coming along, look for a public dashboard of rawhide status coming in the next few weeks 16:32:33 so any specific upcoming changes we didn't cover yet, or is it basically continuing to work on the israwhidebroken.com bits? 16:32:40 great 16:32:42 thanks a lot 16:32:43 also a public instance of the autotest/autoqa stuff 16:32:56 in the meantime keep watching the reports on the autoqa-results list 16:33:14 awesomeness 16:33:16 and if you need details about a failure ask someone @redhat to read (or get you) the detailed logs for a given test 16:33:47 #topic test day update 16:33:53 so this is my starring role! 16:34:18 aim the spotlight! fire the pyrotechnics! 16:34:25 =) 16:34:34 * adamw rises through the stage floor wearing a flowing white cape 16:34:44 so, uh :) 16:34:55 at the last meeting, the Sugar on a Stick test day was still upcoming 16:35:05 #link https://fedoraproject.org/wiki/Test_Day:2009-09-03_SoaS 16:35:22 I don't know if sdziallas is around...? 16:35:27 (he said meaningfully) 16:36:03 i guess not! 16:36:13 well, I was there, and it went off pretty smoothly. so that's nice. 16:36:15 * sdziallas is 16:36:18 ah, here he is :) 16:36:22 adamw: hey :) 16:36:26 anything in particular to report about the soas test day? 16:36:33 did you find it a useful event? 16:36:35 adamw: well, it was... awesome! 16:37:10 adamw: I think I should follow up with jlaska or you (and probably provide some e-mail report or so; sorry, I'm just a little swamped with work) 16:37:43 adamw: I provided pretty valuable feedback, helped us to get to know quite some bugs and even let us preview the semantic infra use in Fedora :) 16:37:44 we've been trying to send an email report on each test day out to -test-list - nothing dramatic, just a quick round-up and a list of bugs produced with the command on the SOP page 16:37:49 but it's not a big thing 16:37:54 ahhh yeah, semantic - i forgot about that 16:38:11 how did you find it? was it a good way for you to access the results? any problems with it? 16:38:19 adamw: sounds like it's something to work on (the report) 16:39:13 adamw: I do like the way. having set it up with mchua and jlaska in a sprint session just a day before the test day started, I guess it was somewhat time consuming. 16:39:21 sdziallas: the report is not that hard. read SOP - you will find some example and doc there 16:39:39 adamw: but I believe if it's properly set up and well designed, it could be an awesome possibility to provide feedback 16:39:49 great 16:40:00 i think if we used it regularly for each event we could probably streamline the setup process 16:40:15 * sdziallas nods; that would be great! 16:40:18 when jlaska is back we should probably get together and discuss the pros and cons, but sounds like it was a productive experiment! 16:41:13 adamw: yeah, definitely! I'd be happy to help there... (and mchua is prolly interested, too) 16:41:17 great, thanks a lot 16:41:58 so, from my side - last week was X.org test week 16:42:11 we had one test day each for nvidia, ati and intel 16:42:34 i haven't done a full follow-up yet - i'm planning to do that this week - but turnout was high and it was pretty lively for each day 16:42:55 jlaska was keeping count and mentioned there were over 100 bug reports generated from the three days in total, so that's...er...good, i suppose :) 16:43:30 so i'll be going through and triaging them, then doing an email report and following up on any really critical issues that emerged. 16:44:13 we have two test days coming up this week 16:44:22 from my side, wednesday will be audio/pulseaudio test day 16:44:44 i'm going to have to pull that one together rather quickly, i don't have a page up for it yet, but plan to get it all done by tomorrow at the latest. 16:45:12 adamw: that one is very important 16:45:33 dpravec: yeah, i know - unfortunately i had trouble getting it scheduled, due to the packed out test day schedule and lennart being quite busy 16:45:35 Xorg drivers and sound systems are typically big PITA for endusers 16:45:41 believe me, I know :) 16:45:48 that's why I wanted to do a sound test day, we haven't had one before 16:45:56 good 16:46:01 adamw: can i help somehow? 16:46:20 off the top of my head i don't know, but if something comes up while i'm working on it i'll let you know - thanks for the offerf 16:46:26 ok 16:46:32 of course, the usual - getting people to come out and get involved - is important 16:46:40 i will try 16:46:47 sound is one of those things like xorg which affects everyone, so if everyone could come along and get others to come too that'd be great 16:47:11 ok, aside from that, thursday will be virtualization test day 16:47:13 setup the page fast so we can announce it on community servers 16:47:22 yes, that's the first priority 16:48:11 virt test day has been organized mostly by markmc and jlaska, neither of whom are around, unfortunately 16:48:23 anyone here has been involved / knows much about that event? 16:48:31 #link https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization 16:49:09 markmc is online, i'm talking to him 16:49:14 can tell him to join 16:49:24 i'm helping him to build custom livecd 16:49:31 virtualisation is important for me 16:49:42 kparal: if you could that'd be great 16:50:04 it still sucks when you have virtual hosts on network and you want to use network manager... 16:50:23 say hello to markmc 16:50:32 hello to markmc 16:50:39 kparal, oh, not me ? :) 16:50:45 :) 16:50:55 hi mark :) 16:50:58 dpravec, what sucks ? 16:51:09 so we're doing a test day update, jlaska is away, so we need someone to tell us about virt test day on thursday 16:51:18 is the planning all in hand? 16:51:20 okay 16:51:21 having network manager combined with virtual hosts available on network 16:51:33 so, we're fleshing it out here https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization 16:51:51 idea is a developer is going to own each sub-page and will write test cases 16:52:00 e.g. https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization_libguestfs 16:52:01 well, having virtual hosts available on network is not really as easy as it should be 16:52:14 kparal is helping me build a livecd 16:52:30 and we'll give people instructions on how to mount (e.g. nfs) storage for guest images 16:52:40 excellent...looks good 16:52:50 apart from that, it should be a pretty standard test day 16:52:57 are there any areas where we (qa) could help you out at all? especially since jlaska's away now, anything we need to take up the slack on? 16:53:02 it went last time, but we tried to cover too much basic virt testing 16:53:08 so this time, it's mostly new features 16:53:17 except live migration which was horribly broken last time 16:54:03 adamw, not really; test cases and the livecd are the two big todo items 16:54:23 adamw, it'd be great if qa folks could watch the wiki pages and help clean up stuff as people add test cases maybe 16:54:38 * markmc thinks of anything else needing doing 16:54:47 ok - i will try and find time to give it a couple of look overs before the day, anyone else who likes to clean up wiki pages please do also :) 16:54:59 adamw, turning up on the day, of course would be great, but that's a given 16:55:09 as always 16:55:33 dpravec, https://fedoraproject.org/wiki/Features/Shared_Network_Interface 16:55:42 dpravec, I think that's basically what you mean 16:55:59 dpravec, we've a lot of the infrastructure in place for that in F12, but not quite there 16:56:09 ic 16:56:18 dpravec, https://fedoraproject.org/wiki/Features/Network_Interface_Management 16:56:37 for now i am using my own bridge and i live without NM 16:56:39 dpravec, we'll be updating these instructions: 16:56:39 http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging 16:56:52 dpravec, to use the virsh netif-* commands to set up a bridge 16:57:12 dpravec, you should be able to use nm - just make the bridge NM_CONTROLLED=no or whatever 16:57:24 i used howto from the last url you gave me 16:57:43 but its not good for novices :) 16:58:00 markmc: that didnt help much 16:58:02 details we can discuss outside of the meeting...we're running short on time :) 16:58:08 and firefox is telling me i am ofline :) 16:58:09 adamw, indeed, sorry 16:58:14 no problem 16:58:19 thanks a lot for the update 16:58:21 markmc: i am talking also to NM people 16:58:30 and i hope this will move, but i see it will take time 16:58:35 i think that's all on test days...there's no FnF test day upcoming 16:58:40 any other points on test days? 16:59:46 ok then 16:59:46 #topic open floor 16:59:58 open floor time! anyone have questions / concerns / suggestions to raise? 17:00:29 adamw: haven't read backscroll... did you mention blocker bug day this friday? 17:00:34 s/day/meeting 17:00:44 aha, indeed i didn't - sorry 17:00:56 thanks, poelcat: there will be another f12 beta blocker bug review meeting this friday 17:01:00 1600 UTC? 17:01:06 * poelcat will send announce and volunteer to run meeting unless someoe else wants to :) 17:01:19 adamw: 1500 UTC I think 17:01:38 poelcat: that would be awesome, thank you 17:01:44 yes... 8 PDT/11EDT/1500 UTC 17:02:01 there was a suggestion i remember seeing somewhere - we should go through f12blocker bugs as well as f12beta, to see if any need to be promoted 17:02:13 * poelcat defines "run meeting" as call out the bugs... you all have a better grasp of technical details :) 17:02:18 we did that for the alpha meetings, but forgot to do it at the first beta meeting 17:02:48 adamw: okay, i'll add that to the agenda and list of bugs to run through 17:02:57 great 17:02:59 hopefully f12block isn't too long 17:03:11 hopefully : 17:03:12 :) 17:03:16 that's why we finished in record time last friday :) 17:03:20 so yes, everyone please come out to the review meeting if you can - the more eyes the better 17:04:32 ok, any other open floor topics? 17:06:24 in that case... 17:06:32 * adamw waves gavel of doom 17:06:48 #endmeeting