16:00:05 <adamw> #startmeeting QA meeting
16:00:05 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:13 * dpravec is here :)
16:00:15 <adamw> #topic gathering bodies
16:00:26 <adamw> alright, which unfortunates have I snared in my nets?
16:00:56 * kparal is caught in the net
16:01:05 <adamw> wwoods: kparal: oxf13: ping
16:01:09 <adamw> hi, kamil
16:01:23 * wwoods appears in a puff of smoke
16:01:59 <adamw> alrighty
16:02:20 <adamw> #topic previous meeting followup
16:02:40 <adamw> 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 <adamw> 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 <adamw> aside from that, there was one topic i definitely wanted to cover
16:03:50 <adamw> #topic followup - zsync
16:04:14 <kparal> that's my topic, alright
16:04:15 <adamw> kparal: you were going to investigate the possibility of using zsync to reduce daily Rawhide image download sizes
16:04:22 <kparal> i have written a blog: http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/
16:04:24 <adamw> i think most of us probably saw your blog on the topic, but could you summarize?
16:04:27 <adamw> :)
16:04:46 <kparal> roughly about 40% of bandwidth can be saved by using zsync
16:04:52 <wwoods> kparal: awesome post - thanks for getting some hard data
16:04:55 <kparal> measured on Fedora nightly images
16:05:12 <adamw> #link http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/
16:05:19 <adamw> (for the logs)
16:05:22 <kparal> but I have talked to nirik and he said:
16:05:22 <kparal> (16:59:19) nirik: kparal: we cannot use it until it's in fedora/epel.
16:05:22 <kparal> (16:59:36) nirik: we don't use any non fedora/epel software if at all possible.
16:05:38 <kparal> (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 <adamw> i believe there's a problem involving a variant version of libz, right?
16:06:06 <kparal> therefore although it would be interesting to use it, it seems that current policy is against it
16:06:15 <kparal> yes, they use a forked library
16:06:23 <kparal> same as rsync
16:06:31 <adamw> what's the URL for the review request?
16:06:43 * kparal looking
16:06:55 <kparal> https://fedorahosted.org/fesco/ticket/134
16:07:01 <kparal> i believe that's it
16:07:02 <adamw> #link https://fedorahosted.org/fesco/ticket/134
16:07:25 <kparal> "zsync may not ship an embedded zlib "
16:07:49 <Oxf13> adamw: I'm here.
16:07:53 <adamw> 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 <Oxf13> sorry, I overslept
16:07:57 <adamw> hi, oxf13
16:08:10 <adamw> so if we're still interested in doing this, that looks like the avenue to follow up
16:08:22 <adamw> are you aware of any technical problems with that, kparal? do you know if anyone's looking into it?
16:08:44 <kparal> no, i haven't looked at it, i don't know
16:09:06 <kparal> nirik could have more information though
16:09:14 * nirik looks up.
16:09:16 <adamw> if you're still willing to push this further, that looks like the next avenue to go down :)
16:09:50 <abadger1999> 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 <nirik> 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 <abadger1999> 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 <kparal> adamw: i think i will leave this task to more appropriate people, but i'm certainly interested in updates
16:10:54 <adamw> it sounds to me like there may be a motivation gap here
16:11:21 <adamw> is rsync still shipping a built-in zlib, at this point? is anyone specifically tasked with dealing with that?
16:11:27 <abadger1999> My observation as well.
16:12:19 <abadger1999> Nope and I don't think it will be without it blocking something.
16:13:18 <adamw> 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 <adamw> 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 <kparal> 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 <abadger1999> 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 <adamw> yes, that's https://bugzilla.redhat.com/show_bug.cgi?id=490140
16:14:32 <buggbot> Bug 490140: medium, medium, ---, redhat-bugzilla, ASSIGNED, Review Request: zsync  - Client-side implementation of the rsync algorithm
16:14:39 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=490140
16:14:40 <buggbot> Bug 490140: medium, medium, ---, redhat-bugzilla, ASSIGNED, Review Request: zsync  - Client-side implementation of the rsync algorithm
16:14:58 <adamw> 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 <abadger1999> who's going to do the work for either of those is the question.
16:15:21 <adamw> 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 <adamw> aside from that, on the larger topic, i did have one more question
16:16:02 <adamw> 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 <adamw> 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 <kparal> this is not about providing deltas
16:16:53 <kparal> the zsync file is generated only from the source file
16:16:58 <kparal> nothing more
16:17:00 <adamw> oh, it works without providing delta files? ahhh. i misunderstood that.
16:17:02 <adamw> ok, that makes it easier.
16:17:10 <kparal> the differences are computed on the client
16:17:26 <adamw> ok. from my side the topic's covered, then. any other comments?
16:17:31 <kparal> the whole command it $zsyncmake <bigfile> -o bigfile.zsync
16:18:34 <adamw> ok, then - moving on
16:18:43 <adamw> wwoods, oxf13 - you guys ready to do an autoqa update?
16:18:52 <Oxf13> I'm not....
16:19:10 <wwoods> sure
16:19:13 <adamw> we can do another topic first and come back to it later in the meeting if it'd help?
16:19:37 <wwoods> so autoqa is still doing its thing - see the results list
16:19:49 <wwoods> looks like our ppc host might be down - or maybe we didn't get a ppc tree today?
16:19:50 <adamw> #topic autoqa update
16:19:53 <wwoods> I'll look into it
16:20:15 <wwoods> jlaska's on vacation for a couple weeks so I'm helping with autoqa monitor duties as well as development
16:20:26 <adamw> (remember we had no meeting last week so anything from the last _two_ weeks is news)
16:20:37 <wwoods> anyway: https://fedorahosted.org/pipermail/autoqa-results/2009-September/thread.html
16:20:45 <wwoods> ooh let me check my records for a second
16:21:08 <Oxf13> looks like no ppc images
16:21:21 <wwoods> Okay so: we fixed up the email output to show tracebacks when they happen
16:21:34 <adamw> ooh. that's awesome.
16:21:42 <wwoods> fixed up the install test so it monitors both the serial console and the logs
16:21:57 <Oxf13> I don't see images for any other arch either, so maybe I'm looking in the wrong place
16:22:06 <wwoods> install test will end immediately when it sees the "installation exited abnormally" message
16:22:19 <dpravec> wwoods: great news
16:22:29 <wwoods> Oxf13: so there's rats_sanity test results for today for x86_64 and i386
16:22:35 <wwoods> which indicates that the repodata updated, at the very least
16:22:40 <wwoods> both failed, though
16:22:48 <Oxf13> repodata yes, images not so much it seems
16:23:11 <wwoods> right, no images appeared, which is why rats_install never even ran
16:23:14 <wwoods> https://fedorahosted.org/pipermail/autoqa-results/2009-September/000928.html
16:23:19 <wwoods> we have depsolving problems in the critpath
16:23:28 <wwoods> so we're on full red alert for today's rawhide
16:23:28 <wwoods> heh
16:23:30 <Oxf13> 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 <Oxf13> Error: Missing Dependency: libcryptsetup.so.0 is needed by package python-cryptsetup-0.0.9-2.fc12.i686 (anacondarepo)
16:23:48 <Oxf13> so, somebody fubared the critical path
16:24:22 <adamw> nice to see how quickly autoqa can be used to pinpoint a problem :)
16:24:27 <wwoods> indeed
16:24:48 <Oxf13> cryptsetup-luks got a soname bump on the 11th.
16:25:07 <wwoods> 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 <wwoods> I started writing a TurboGears app to handle that stuff.. last week I guess?
16:25:30 <Oxf13> and nobody bumped python-cryptsetup to match.
16:25:33 <adamw> right, at the last meeting you had that on the list of 'things to do next'
16:26:06 <wwoods> I've got a personal git repo that contains the code I've been working on
16:26:28 <wwoods> which, er, I can't seem to find a good URL for at the moment
16:26:32 <adamw> heh :)
16:26:45 <dpravec> wwoods: icannot open http://test1250.test.redhat.com/afe/  ...  (connecting to ...  for few minutes)
16:27:09 <Oxf13> wait, maybe I'm wrong in my investigation.  Need more time to look
16:27:25 <wwoods> ah: git://git.fedorapeople.org/~wwoods/israwhidebroken.git
16:27:41 <Oxf13> no, I'm right.  *sigh*
16:28:01 <wwoods> so far so good - it's doing FAS auth properly, has a list of the known rawhide tests, etc.
16:28:10 <wwoods> I'm working on automated result submission
16:28:23 <dpravec> wwoods: do you have publicly accessible web page with results?
16:28:28 <wwoods> dpravec: not yet, no
16:28:31 <wwoods> that's what I'm working on
16:28:40 <wwoods> also test1250 is gone - it changed hostname
16:28:48 <wwoods> it's test1185 now
16:29:02 <Oxf13> 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 <wwoods> Oxf13: definitely, but we have to be confident in our tests first.. and have the tests running on something public
16:29:51 <wwoods> 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 <wwoods> we're much, much closer to that now
16:30:33 <Oxf13> wwoods: I think it's too late by that point (sync the tree or not)
16:30:44 <wwoods> Oxf13: well, with the current watcher, yes
16:31:04 <Oxf13> 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 <wwoods> ah, I see what you mean now
16:31:36 <wwoods> 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 <wwoods> then we can work on that
16:31:50 <wwoods> IIRC we have some hardware on order to get put in the lab for this
16:31:55 <wwoods> err s/lab/colo/
16:31:59 <adamw> alright, brainstorming we can do outside the meeting :)
16:32:06 <wwoods> but jlaska knows the details about that better than I do, so I can't say more
16:32:30 <wwoods> anyway - autoqa stuff is coming along, look for a public dashboard of rawhide status coming in the next few weeks
16:32:33 <adamw> 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 <adamw> great
16:32:42 <adamw> thanks a lot
16:32:43 <wwoods> also a public instance of the autotest/autoqa stuff
16:32:56 <wwoods> in the meantime keep watching the reports on the autoqa-results list
16:33:14 <adamw> awesomeness
16:33:16 <wwoods> 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 <adamw> #topic test day update
16:33:53 <adamw> so this is my starring role!
16:34:18 <wwoods> aim the spotlight! fire the pyrotechnics!
16:34:25 <adamw> =)
16:34:34 * adamw rises through the stage floor wearing a flowing white cape
16:34:44 <adamw> so, uh :)
16:34:55 <adamw> at the last meeting, the Sugar on a Stick test day was still upcoming
16:35:05 <adamw> #link https://fedoraproject.org/wiki/Test_Day:2009-09-03_SoaS
16:35:22 <adamw> I don't know if sdziallas is around...?
16:35:27 <adamw> (he said meaningfully)
16:36:03 <adamw> i guess not!
16:36:13 <adamw> well, I was there, and it went off pretty smoothly. so that's nice.
16:36:15 * sdziallas is
16:36:18 <adamw> ah, here he is :)
16:36:22 <sdziallas> adamw: hey :)
16:36:26 <adamw> anything in particular to report about the soas test day?
16:36:33 <adamw> did you find it a useful event?
16:36:35 <sdziallas> adamw: well, it was... awesome!
16:37:10 <sdziallas> 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 <sdziallas> 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 <adamw> 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 <adamw> but it's not a big thing
16:37:54 <adamw> ahhh yeah, semantic - i forgot about that
16:38:11 <adamw> how did you find it? was it a good way for you to access the results? any problems with it?
16:38:19 <sdziallas> adamw: sounds like it's something to work on (the report)
16:39:13 <sdziallas> 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 <dpravec> sdziallas: the report is not that hard. read SOP - you will find some example and doc there
16:39:39 <sdziallas> 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 <adamw> great
16:40:00 <adamw> 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 <adamw> 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 <sdziallas> adamw: yeah, definitely! I'd be happy to help there... (and mchua is prolly interested, too)
16:41:17 <adamw> great, thanks a lot
16:41:58 <adamw> so, from my side - last week was X.org test week
16:42:11 <adamw> we had one test day each for nvidia, ati and intel
16:42:34 <adamw> 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 <adamw> 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 <adamw> 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 <adamw> we have two test days coming up this week
16:44:22 <adamw> from my side, wednesday will be audio/pulseaudio test day
16:44:44 <adamw> 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 <dpravec> adamw: that one is very important
16:45:33 <adamw> 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 <dpravec> Xorg drivers and sound systems are typically big PITA for endusers
16:45:41 <adamw> believe me, I know :)
16:45:48 <adamw> that's why I wanted to do a sound test day, we haven't had one before
16:45:56 <dpravec> good
16:46:01 <dpravec> adamw: can i help somehow?
16:46:20 <adamw> 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 <dpravec> ok
16:46:32 <adamw> of course, the usual - getting people to come out and get involved - is important
16:46:40 <dpravec> i will try
16:46:47 <adamw> 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 <adamw> ok, aside from that, thursday will be virtualization test day
16:47:13 <dpravec> setup the page fast so we can announce it on community servers
16:47:22 <adamw> yes, that's the first priority
16:48:11 <adamw> virt test day has been organized mostly by markmc and jlaska, neither of whom are around, unfortunately
16:48:23 <adamw> anyone here has been involved / knows much about that event?
16:48:31 <adamw> #link https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization
16:49:09 <kparal> markmc is online, i'm talking to him
16:49:14 <kparal> can tell him to join
16:49:24 <kparal> i'm helping him to build custom livecd
16:49:31 <dpravec> virtualisation is important for me
16:49:42 <adamw> kparal: if you could that'd be great
16:50:04 <dpravec> it still sucks when you have virtual hosts on network and you want to use network manager...
16:50:23 <kparal> say hello to markmc
16:50:32 <markmc> hello to markmc
16:50:39 <markmc> kparal, oh, not me ? :)
16:50:45 <dpravec> :)
16:50:55 <adamw> hi mark :)
16:50:58 <markmc> dpravec, what sucks ?
16:51:09 <adamw> 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 <adamw> is the planning all in hand?
16:51:20 <markmc> okay
16:51:21 <dpravec> having network manager combined with virtual hosts available on network
16:51:33 <markmc> so, we're fleshing it out here https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization
16:51:51 <markmc> idea is a developer is going to own each sub-page and will write test cases
16:52:00 <markmc> e.g. https://fedoraproject.org/wiki/Test_Day:2009-09-17_Virtualization_libguestfs
16:52:01 <dpravec> well, having virtual hosts available on network is not really as easy as it should be
16:52:14 <markmc> kparal is helping me build a livecd
16:52:30 <markmc> and we'll give people instructions on how to mount (e.g. nfs) storage for guest images
16:52:40 <adamw> excellent...looks good
16:52:50 <markmc> apart from that, it should be a pretty standard test day
16:52:57 <adamw> 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 <markmc> it went last time, but we tried to cover too much basic virt testing
16:53:08 <markmc> so this time, it's mostly new features
16:53:17 <markmc> except live migration which was horribly broken last time
16:54:03 <markmc> adamw, not really; test cases and the livecd are the two big todo items
16:54:23 <markmc> 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 <adamw> 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 <markmc> adamw, turning up on the day, of course would be great, but that's a given
16:55:09 <adamw> as always
16:55:33 <markmc> dpravec, https://fedoraproject.org/wiki/Features/Shared_Network_Interface
16:55:42 <markmc> dpravec, I think that's basically what you mean
16:55:59 <markmc> dpravec, we've a lot of the infrastructure in place for that in F12, but not quite there
16:56:09 <dpravec> ic
16:56:18 <markmc> dpravec, https://fedoraproject.org/wiki/Features/Network_Interface_Management
16:56:37 <dpravec> for now i am using my own bridge and i live without NM
16:56:39 <markmc> dpravec, we'll be updating these instructions:
16:56:39 <markmc> http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging
16:56:52 <markmc> dpravec, to use the virsh netif-* commands to set up a bridge
16:57:12 <markmc> dpravec, you should be able to use nm - just make the bridge NM_CONTROLLED=no or whatever
16:57:24 <dpravec> i used howto from the last url you gave me
16:57:43 <dpravec> but its not good for novices :)
16:58:00 <dpravec> markmc: that didnt help much
16:58:02 <adamw> details we can discuss outside of the meeting...we're running short on time :)
16:58:08 <dpravec> and firefox is telling me i am ofline :)
16:58:09 <markmc> adamw, indeed, sorry
16:58:14 <adamw> no problem
16:58:19 <adamw> thanks a lot for the update
16:58:21 <dpravec> markmc: i am talking also to NM people
16:58:30 <dpravec> and i hope this will move, but i see it will take time
16:58:35 <adamw> i think that's all on test days...there's no FnF test day upcoming
16:58:40 <adamw> any other points on test days?
16:59:46 <adamw> ok then
16:59:46 <adamw> #topic open floor
16:59:58 <adamw> open floor time! anyone have questions / concerns / suggestions to raise?
17:00:29 <poelcat> adamw: haven't read backscroll... did you mention blocker bug day this friday?
17:00:34 <poelcat> s/day/meeting
17:00:44 <adamw> aha, indeed i didn't - sorry
17:00:56 <adamw> thanks, poelcat: there will be another f12 beta blocker bug review meeting this friday
17:01:00 <adamw> 1600 UTC?
17:01:06 * poelcat will send announce and volunteer to run meeting unless someoe else wants to :)
17:01:19 <poelcat> adamw: 1500 UTC I think
17:01:38 <adamw> poelcat: that would be awesome, thank you
17:01:44 <poelcat> yes... 8 PDT/11EDT/1500 UTC
17:02:01 <adamw> 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 <adamw> we did that for the alpha meetings, but forgot to do it at the first beta meeting
17:02:48 <poelcat> adamw: okay, i'll add that to the agenda and list of bugs to run through
17:02:57 <adamw> great
17:02:59 <poelcat> hopefully f12block isn't too long
17:03:11 <adamw> hopefully :
17:03:12 <adamw> :)
17:03:16 <poelcat> that's why we finished in record time last friday :)
17:03:20 <adamw> so yes, everyone please come out to the review meeting if you can - the more eyes the better
17:04:32 <adamw> ok, any other open floor topics?
17:06:24 <adamw> in that case...
17:06:32 * adamw waves gavel of doom
17:06:48 <adamw> #endmeeting