16:00:07 <jlaska> #startmeeting Fedora QA Meeting
16:00:07 <zodbot> Meeting started Mon Aug 31 16:00:07 2009 UTC. The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:15 <jlaska> #topic gathering in lobby
16:00:44 * kparal is present
16:00:50 <jlaska> Hey folks ... let's do a quick show of hands
16:01:17 <kparal> dpravec is just making coffee/tea, otherwise present
16:01:23 * nirik is hanging out in the back.
16:01:46 <adamw> mornin
16:01:52 * fenris02 is waiting for the tea to be finished
16:01:54 <jlaska> kparal: nirik and dpravec_caffeine ... hello
16:02:08 <jlaska> adamw: fenris02: good mornin'
16:02:14 * psss is here, hi!
16:03:04 <jlaska> psss: hey there
16:03:10 <dpravec> jlaska: psss will be here only 30 minutes
16:03:27 <jlaska> dpravec: okay ... we've got autoqa lined up early in the agenda
16:03:28 * Oxf13
16:03:35 <jlaska> Oxf13: hey hey
16:03:56 <jlaska> is there a wwoods lurking in the shadows?
16:04:10 * wwoods is batman
16:04:15 <jlaska> LOL!
16:04:29 <jlaska> alrighty ... let's doo eeeet
16:04:47 <jlaska> #topic previous meeting follow-up
16:05:11 <jlaska> dpravec: I've got you up first ... how goes it with test-announce?
16:05:15 <jlaska> # [dpravec] - investigate creating fedora-test-announce mailing list for Test Days, other test events, schedule updates
16:05:55 <dpravec> ah, i almost forgot. but mailing list test-announce is ready to be used
16:06:22 <adamw> yay
16:06:29 <adamw> who's set as a moderator?
16:06:29 <dpravec> its moderated list with low traffic - so people will get info about testing without getting much spam
16:06:41 <dpravec> adamw: if i am not mistaken, you are
16:06:52 <jlaska> alright, I'll ask sdziallas to be our test candidate this week for sugar on a stick announcement
16:07:22 <jlaska> I forget, mailman uses a single admin passwd?
16:07:23 <adamw> is fedora-test-list subscribed to the announce list, as suggested last week?
16:07:54 <dpravec> adamw: hmm not yet, but i will try to fix this today/tomorrow
16:08:18 <dpravec> hmm i dont know how :)
16:08:42 <dpravec> ha, just subscribe it ;) heh
16:08:50 <dpravec> ok, will do
16:08:57 <Oxf13> yes, you can just subscribe it from the admin pages
16:09:12 <jlaska> dpravec: can you add me as a moderator as well?
16:09:20 * tk009 arrives late
16:09:20 <dpravec> yes, i already did
16:09:31 <adamw> hi iarlyy, tk009
16:09:32 <jlaska> dpravec: thanks ... I think that gets us decent TZ coverage
16:09:34 * iarlyy arrives late tool x)
16:09:42 <iarlyy> s/too
16:09:52 <jlaska> howdy iarlyy and tk009 :)
16:10:18 <tk009> =) J & A
16:10:27 <tk009> & I
16:10:28 <iarlyy> hey adamw jlaska
16:10:31 <jlaska> alrighty, I've got a few action items .. wil walk through quick ...
16:10:38 <jlaska> # [jlaska] - talk with Liam about how we can make the current install test plan more attainable/achievable in the given time frames
16:10:55 <jlaska> I didn't have a chance to catch up with Liam on this last week ... but will follow-up on this probably tonight
16:11:19 <jlaska> so I'll keep this on for next week ... and see if maybe Liam has any points he wants to address for the minutes as well
16:11:24 <jlaska> next ...
16:11:49 * jlaska just speeding through ... so shout for a stop
16:11:53 <jlaska> # [jlaska] - cleanup remaining test cases for dracut and send announcement
16:11:56 <dpravec> so, iam adding fedora-test-list@redhat.com to members, ok?
16:12:19 <jlaska> #action dpravec will subscribe fedora-test-list to test-announce
16:12:25 <jlaska> dpravec: I think that's how it works
16:12:51 <jlaska> #action jlaska - catch up with lili on some test plan changes for the upcoming F-12-Beta milestones
16:13:08 <dpravec> .. done
16:13:35 <jlaska> dracut test cases were in good shape ... with help from atodorov and jstodola
16:13:45 <jlaska> there is one missing still for root=udev-path ... but I need to test that first
16:14:09 <jlaska> next item ...
16:14:11 <jlaska> # [jlaska] - discuss bandwith implications of hosting nightly rawhide live images with fedora-infrastructure
16:14:21 <dpravec> https://admin.fedoraproject.org/mailman/listinfo/test-announce <-- maillist page
16:14:31 <jlaska> dpravec: thanks!
16:15:09 <jlaska> Oxf13, nirik: I spoke to mmcgrath on the fedora-admin briefly a little bit ago on the alt.fp.org bandwith
16:15:33 <Oxf13> ok
16:15:49 <iarlyy> we had problems with live images for f11
16:15:50 <iarlyy> ?
16:16:09 <jlaska> the summary is that there haven't been any issues reported yet, and he'd like to be kept in the loop when new milestone drops land
16:16:20 <tk009> no nightly rawhide iarlyy
16:16:26 * nirik is happy to adjust/change/whatever the live composes. Just let me know.
16:16:32 <adamw> did he have any numbers on how many downloads we've been getting on the nightly builds so far?
16:16:34 <jlaska> iarlyy: yeah, this is for hosting live images
16:16:48 <jlaska> adamw: I didn't ask, but I Think those would be reasonable to gather ... I can follow-up
16:17:03 <tk009> I've been using them and been happy
16:17:09 <nirik> I note that rawhide has been busted with broken deps for a bit now, so there have been no new images recently.
16:17:12 <jlaska> mmcgrath did note that they're interested in building a mirror to host content should any issues surface on that one system
16:17:18 <jlaska> nirik: yeah :(
16:17:20 <kparal> i have discussed with nirik the possibility for using zsync tool (http://zsync.moria.org.uk/) for downloading images. it is similar to rsync, but works on plain http. it saves time and bandwidth for users and servers. unfortunatelly zsync is not packaged yet for fedora, so the conclusion is it is not relevant yet
16:17:32 * mmcgrath actually just kickstarted said machine. It'll be ready by the next time you guys do this.
16:17:38 <jlaska> go mmcgrath!
16:17:48 <adamw> nirik: yeah, stuck in the middle of an openssl rebuild i think.
16:17:54 <Oxf13> kparal: for live images, rsync is actually the wrong thing to use
16:18:04 <nirik> kparal: we can't use it until it is. ;) There is also deltaiso's... and also any of this stuff needs multiple images around to delta, which means more disk space.
16:18:09 <Oxf13> kparal: it will make things far slower than just using plain http to download the entire file.
16:18:10 <adamw> i did get a finished update with --skip-broken today, but lots of packages were skipped. and i'm not sure it's going to work if i reboot =)
16:18:28 <Oxf13> deltas also aren't very useful I would think with live images
16:18:31 <kparal> Oxf13: ubuntu uses zsync for live images and it is great, you download only the differencies
16:18:32 <nirik> adamw: most things should be fixed today... just NM and a few others.
16:18:40 <Oxf13> kparal: Ubuntu's live images aren't like ours
16:19:29 * iarlyy agrees with Oxf13
16:19:30 <jlaska> kparal: should we hold on zsync until the open discussion?
16:19:33 <kparal> Oxf13: for example brno branch have so slow line sometimes, that i really doubt it could be any slower :)
16:19:40 <kparal> ok
16:19:42 * jlaska would like to dive into autoqa while psss is still around
16:20:00 <jlaska> kparal: if I forget, please throw something at me when we get to open discussion :)
16:20:11 <kparal> jlaska: sure, go ahead
16:20:17 <jlaska> kparal: okay, thanks
16:20:31 <jlaska> # [Oxf13] - will do a build of the new autotest version for testing.
16:20:40 <Oxf13> That was done
16:20:41 <jlaska> we've got a big DONE there ... thanks Oxf13!
16:20:46 <Oxf13> np
16:20:50 <jlaska> and the follow-on to that point ...
16:20:51 <jlaska> # [jlaska + wwoods] to test latest autotest build
16:21:11 <jlaska> still in progress on my end ... I'm using this opportunity to help document ...
16:21:13 <dpravec> i would love to install it too. i am having virtual machine ready
16:21:43 <jlaska> #action jlaska - complete autotest setup doc and post autotest-0.11 test feedback
16:22:02 <iarlyy> autotest? sorry what's?
16:22:20 <wwoods> http://fedoraproject.org/wiki/Autotest
16:22:35 <jlaska> I've got one more unassigned action item ... but will raise this at the end of the meeting
16:22:43 <adamw> iarlyy: have you not been reading FWN religiously? i am disappointed :)
16:23:03 <iarlyy> adamw, lately nops ;(
16:23:07 <jlaska> wwoods, cased on iarlyy's question ... sounds like a good opportunity for you to take it a way
16:23:15 <jlaska> #topic AutoQA update from wwoods
16:23:40 <wwoods> last week was DOCS WEEK woo
16:23:47 <wwoods> see http://fedoraproject.org/wiki/Category:AutoQA
16:23:52 * jlaska puts his hands in the air
16:24:12 <wwoods> http://fedoraproject.org/wiki/AutoQA is the main page for the Fedora AutoQA project
16:24:23 <wwoods> http://fedoraproject.org/wiki/Autotest has specific info about autotest and how we use it in AutoQA
16:24:38 <wwoods> http://fedoraproject.org/wiki/Writing_AutoQA_Hooks and http://fedoraproject.org/wiki/Writing_AutoQA_Tests explain how to write autoqa hooks and tests
16:25:06 <wwoods> but really, to write tests and hooks, you don't need to know anything about autoqa or autotest specifically
16:25:19 <wwoods> first you need a working test, or some working code to monitor for an event
16:25:28 <wwoods> then you write some wrapper code to make it work in AutoQA
16:25:28 * adamw waves it like he just don't care
16:25:33 <jlaska> ;)
16:25:42 <jlaska> wwoods: those are killer docs
16:25:55 <adamw> if anyone's wondering why i'm waving jlaska's hand, congratulations, you're more awake than me
16:26:01 <wwoods> http://fedoraproject.org/wiki/Install_and_configure_autotest talks a bit about setting up your own autotest instance if you wanted to run the autoqa code on your own
16:26:17 <kparal> wwoods: i'm just trying to modify autoqa to work even if you have only autotest-client, not server. i can be easier for hooks/tests developers (like me:))
16:26:19 * iarlyy many pages to ready... Love it! oww!
16:26:36 <jlaska> wwoods: I'll chat with you after the meeting, but anxious for your input on how to make that page (Install_and_configure_autotest) less painful to read
16:26:41 <wwoods> kparal: okay, but like I said - you don't need to know anything about autoqa to write tests
16:26:44 <wwoods> write the test first
16:26:53 <wwoods> then worry about autoqa wrapper code
16:27:00 <wwoods> same for hooks - write the watcher first
16:27:07 * iarlyy typo s/read/
16:27:24 <Southern_Gentlem> wwoods, i will be interested in this in the future as well for the re-spins
16:27:27 <kparal> wwoods: ok, that should be in bold text in some page :)
16:27:31 <wwoods> let me say that once more: you don't need autoqa or autotest to write tests.
16:27:34 <wwoods> at all.
16:28:19 <wwoods> I'll put some italics on "You should have a working test before you even start thinking about AutoQA."
16:28:42 <jlaska> kparal: that's probably my fault for suggesting looking at the code :(
16:28:42 <kparal> :) good
16:28:56 <dpravec> wwoods: psss is writing some sanity tests for rpm packages. we should talk about it later when we will have time
16:29:10 <kparal> jlaska: no problem, i liked to study it
16:30:11 <adamw> wwoods: i think you should make it flash. and have a kitten on it.
16:30:29 <psss> hi, guys! just wanted to make clear the status of fedora test-package-sanity project
16:31:09 <jlaska> psss: welcome
16:31:25 <dpravec> psss: ?
16:31:36 <psss> the original idea came from ondrej hudlicky: to prevent dependency problems...
16:32:02 <psss> we've just started looking around... and came across the autoqa project...
16:32:31 <dpravec> wwoods: so they do not need to care about autoqa much, they should just code tests?
16:32:54 <Oxf13> yes
16:33:02 <dpravec> ... which will be later easy to integrate
16:33:35 <wwoods> yes.
16:33:38 <psss> now, what/how can we help with?
16:33:45 <jlaska> psss: I suspect (wwoods can correct me if I get this wrong) that some of the support you'd need to initiate your tests would involve what kparal is looking at as well
16:34:21 <jlaska> with tests in hand, perhaps you guys might sync up on ideas for a watcher to initiate them?
16:34:41 <kparal> we can probably collaborate on creating the watcher for the packages
16:35:57 <jlaska> wwoods: we have two watchers now right?
16:36:01 <wwoods> right
16:36:09 <wwoods> it's a lot easier to write watchers once you have some tests in mind
16:36:15 <wwoods> because then you know what info the tests will need
16:36:24 <kparal> alright, therefore first goes the tests
16:36:26 <wwoods> obviously a post-koji-build watcher is going to need.. a URL to the new package(s)
16:36:47 <wwoods> but there might be other things you haven't thought of yet
16:37:11 <wwoods> so try writing the tests and then you'll have some concrete examples of what the tests need to know
16:38:13 <wwoods> and hopefully https://fedoraproject.org/wiki/Writing_AutoQA_Tests is a bit clearer now about the fact that you don't need any special knowledge or code from autoqa/autotest
16:38:46 <jlaska> kparal: I guess that ties into what you discussed earlier today ... about what conditions should rpmlint's rpmdiff test trigger a failure
16:38:56 <Oxf13> post-koji-build may depend on our message bus
16:39:01 <Oxf13> or some ugly email + postfix games
16:39:20 <Oxf13> but yes, come up with the tests first, we'll worry about how to trigger them after that
16:39:29 <wwoods> Oxf13: the interface between the watcher and autoqa being well-defined, we can write an ugly one as a proof-of-concept
16:39:33 <wwoods> until such time as we have the message bus
16:39:52 <wwoods> and we can replace the watcher without affecting autoqa/the tests
16:40:24 <jlaska> psss: do you have enough information to get started on your end?
16:40:54 <jlaska> psss: or at least enough docs to discern what the starting point should be?
16:41:19 <kparal> psss: if not, we can consult it tomorrow, just contact me :)
16:41:55 <psss> perhaps a question: when writing tests, we use BeakerLib
16:42:14 <psss> is the autotest framework be used in a similar way inside the tests?
16:42:28 <wwoods> not inside the test code itself
16:42:52 <wwoods> but the control file and test object are wrappers used by autotest to launch your test code
16:43:17 <psss> well, yes, but the test needs to log
16:43:21 <wwoods> autotest takes care of saving logs, test results, and other data
16:44:00 <wwoods> for example it defines a 'resultsdir' attribute that is the directory you should write logs to
16:44:22 <jlaska> does this fall into setup/precondition for the test itself ... does the test need to make sure the correct packages are available that it needs?
16:44:32 <jlaska> like ... 'is beaker-list installed?'
16:44:35 <wwoods> so for some tests we do "--logdir %s" % resultsdir
16:44:44 <jlaska> s/beaker-list/beaker-lib/
16:45:21 <wwoods> or the wrapper can just move the logs from wherever they're written to resultsdir after the test finishes
16:47:07 <jlaska> Shall we wrap-up on the autoqa update for today?
16:47:13 <wwoods> beaker-lib does some weird mixing of harness code and convenience code for testing
16:47:27 <jlaska> oops sorry, keep going wwoods
16:47:27 <dpravec> Oxf13: where are those new packages?
16:47:30 <wwoods> if you're using beaker-lib for convenience in writing your test, that's your decision
16:47:39 <Oxf13> jkeating.fedorapeople.org/infra/
16:47:43 <dpravec> ty
16:47:44 <wwoods> and you can install beaker-lib in setup(), or package it with the test
16:48:04 <wwoods> it doesn't matter, we can make it work, it's not that hard, just get the test working and worry about integration later
16:48:26 <psss> just wanted to make sure, we're not duplicating with beakerlib something which is integrated in autotest already...
16:48:27 <jlaska> sounds like the quote for the week ... "get the test working, and worry about integration later"
16:49:00 <wwoods> anyway, yeah. this week in autoqa: figuring out how to get data back out of the autotest frontend/RPC code so we can populate forms for israwhidebroken.com or similar things
16:49:44 <wwoods> https://fedorahosted.org/autoqa/milestone/israwhidebroken.com
16:49:47 <wwoods> that's the roadmap
16:49:54 <iarlyy> chromium can't open url above, ff is ok lol
16:50:18 <wwoods> good thing chromium isn't in Fedora then
16:50:23 <wwoods> sounds pretty buggy
16:50:48 <jlaska> wwoods: great, I hope to clean up that install guide a bit so that it meets the wwoods doc standard
16:50:52 <wwoods> heh
16:51:10 <Oxf13> iarlyy: my chromium can load it
16:51:10 <psss> ok, guys, will have to go... to sum up for myself: "get the test working" ;-)
16:51:11 <wwoods> I'll give it a read and make additions and/or send you notes
16:51:26 <jlaska> psss: thanks for joining today!
16:51:33 <psss> i will contant kparal for details about our possible cooperation...
16:51:43 <iarlyy> a yum repo will be good
16:51:48 <iarlyy> easy to install/update
16:51:55 <dpravec> when kamil will not be here,, you can talk to me
16:52:03 <jlaska> iarlyy: definitely, that's the plan once we get Oxf13 some test feedback on these updated packges
16:52:06 <psss> jlaska: my pleasure :)
16:52:14 <psss> ok, bye, guys!
16:52:17 <dpravec> bye, psss
16:52:36 <jlaska> okay ... that's a good update on autoqa ... let's move on to some QA events this week
16:52:59 <jlaska> #topic Test Day Updates - Dracut
16:53:06 <Oxf13> breakfast horizon is approaching for me.
16:53:16 <jlaska> thanks everyone for attending and contributing test results and/or bugs
16:53:30 <jlaska> I've got a draft test summary in the pipe and will send that to the list this afternoon
16:54:01 <jlaska> we still need feedback on bare metal (real hardware / non-kvm) ... so the existing test cases are available for any/all to contribute
16:54:21 <jlaska> #action jlaska - send dracut test day summary to fedora-test-list
16:54:48 <jlaska> any questions/comments on the dracut test day before we move on?
16:55:26 <jlaska> alrighty ... next up
16:55:32 <jlaska> #topic Test Day Updates - sectool
16:55:53 <jlaska> Eduard Beneš has organized a test day tomorrow for sectool
16:56:06 <fenris02> should it suggest pam_tally2 instead of _tally? should a default install pass level 5 ?
16:56:10 <jlaska> note, this is a QA sponsored test day ... but thanks to mclasen for loaning the fit'n'finish slot
16:56:33 <jlaska> #link https://fedoraproject.org/wiki/Test_Day:2009-09-01_Sectool
16:56:37 <adamw> ooh. i didn't know it was a qa test day. it looked odd for fnf :)
16:56:38 <jlaska> fenris02: is this for the sectool day?
16:56:52 <jlaska> adamw: mclasen has been kind to loan some of his open slots
16:56:57 <fenris02> jlaska, for sectool- i can ask on testday too of course
16:57:30 <jlaska> fenris02: Hmm, sorry ... I think you are more up to speed on that that me
16:57:39 <adamw> wiki page could do with an explanation of what sectool is, and possibly links to packages for F11?
16:58:06 <fenris02> sectool is in f10 too
16:58:13 <jlaska> adamw: good points
16:58:24 <jlaska> and a link to a live image to test with
16:58:37 <adamw> do we know what version XYZ is?
16:58:52 <jlaska> doh!
16:59:34 <jlaska> let's follow-up to Eduard's fedora-test-list announcement for the event
17:00:37 <jlaska> adamw: you mind following-up on the list with that?
17:01:12 <adamw> just to ask questions and get the info filled in? sure
17:01:29 <jlaska> #action adamw - to reply to sectool test day with some test day wiki improvements
17:01:32 <jlaska> adamw: thanks!
17:02:04 <jlaska> fenris02: feel free to do the same for _tally vs tally2 ... or you can join in if yo uhave time tomorrow
17:02:14 <jlaska> #topic Test Day Updates - sugar on a stick
17:02:18 <jlaska> #link https://fedoraproject.org/wiki/Test_Day:2009-09-03
17:02:26 * sdziallas waves, is about to update that page
17:02:30 <jlaska> this Thursday's will feature Sugar on a stick testing
17:02:42 <jlaska> sdziallas: I've got an email response to you inprogress
17:02:53 <sdziallas> jlaska: I just talked to Mel, we'll put the test cases (I have them almost ready) in the semantic infra on Wednesday
17:02:57 <sdziallas> jlaska: cool!
17:03:07 <adamw> awesome
17:03:10 <jlaska> sdziallas: oh very nice ... I'm anxious to see how that works out
17:03:25 <sdziallas> jlaska: I've been asking for volunteers from the Sugar-side to join us, but haven't heard anything back... but I'll try to get us some more folks
17:03:25 <jlaska> sdziallas: this is still using https://publictest6.fedoraproject.org/wiki right?
17:03:50 <sdziallas> jlaska: yeah, me too... curious to test it. yup, that's what I've been directed to.
17:03:51 <jlaska> sdziallas: do you need any special hardware for this ... or can anyone switch to the sugar desktop (or boot live sugar image) to test?
17:04:27 <adamw> jlaska: i believe the point is booting from the live image, that's what the project is about :)
17:04:29 <sdziallas> jlaska: well, basically anybody could yum groupinstall sugar-desktop. but Sugar on a Stick is more about booting an .iso from a USB key (or in a virtual machine)
17:04:55 <jlaska> adamw: heh, sorry ... yeah ;)
17:04:59 <sdziallas> adamw: yeah, right... if somebody has no other chance than yum groupinstalling, this might already help, too, though.
17:05:22 <sdziallas> (since we're basically using the packages from Fedora for that, so if there's a bug there, it's likely that we've it in SoaS, too)
17:05:37 * jlaska sternly looks at USB key on desk
17:05:39 <tk009> is a 4g usb key big enough to test?
17:05:46 <adamw> the hardware question stands, though - is it expected to run on any hardware?
17:05:50 <sdziallas> tk009: yup! even 2g should be enough...
17:05:51 <adamw> (or any hardware that runs fedora, at least)
17:06:35 <sdziallas> adamw: yeah. for any strange configurations, we decided to follow a "no-hacks"-policy, so we should be able to run SoaS on the same hardware than Fedora runs on.
17:07:27 <sdziallas> adamw: so the same points: the more RAM, the better. hard disk not necessarily required (unless you want to test the rebootless installer, which might eat babies, though).
17:08:20 <sdziallas> well, in case a machine isn't able to boot from USB, one would need a boot helper .iso, which just booted the USB key then... (I'll push such an image to the Sugar Labs servers today)
17:09:39 <jlaska> sdziallas: I'll follow-up after the meeting on that email
17:09:58 <sdziallas> jlaska: sure, cool :)
17:10:06 <jlaska> sdziallas: but feel free to find adamw or myself on #fedora-qa if there are any other issues that come up
17:10:30 <jlaska> okay ... last Test day topic ...
17:10:37 <sdziallas> jlaska: okey dokey... (I thought I had added #fedora-qa to my auto-login, but apparently xchat ate it)
17:10:52 <jlaska> no worries
17:10:54 <jlaska> #topic Test Day Updates - X drv week
17:11:07 <jlaska> adamw: so next week is the <suspense music> ... X test week, right?
17:11:36 <adamw> i believe it is! i should really add an intel day.
17:11:52 <adamw> but right now we have radeon and nouveau days on wednesday and thursday.
17:12:16 <jlaska> awesome, looking forward to those
17:12:20 <adamw> i haven't put the pages together yet, will do so soon. it will be similar to the f11 days - just general testing of the drivers' capabilities, find out where we're at, particularly with newer stuff like nouveau modesetting
17:12:40 <jlaska> hopefully be able to re-use a lot of your previous test cases?
17:12:45 <jlaska> s/be //
17:13:05 <dpravec> intel drivers are worse and worse each month
17:13:31 <dpravec> it was much better 2 years ago
17:13:34 <jlaska> dpravec: this will be a good chance to figure out how bad things are prior to the beta
17:13:53 <adamw> yeah, we'll be re-using test cases.
17:14:48 <jlaska> adamw: any issues/action you wanted to raise in the meeting today on that?
17:15:28 <adamw> not really, i don't think
17:15:35 <adamw> if anyone has ideas / suggestions please shoot :)
17:15:57 <jlaska> you're F-11 versions of these were very successful in terms of participation
17:16:37 <jlaska> dunno ... any updates to the xorg debugging guide needed in preparation to this?
17:16:48 <jlaska> any new files, or debugging boot args to consider for it
17:18:14 <jlaska> alrighty ... let's change over to open discussion
17:18:26 <jlaska> #topic Open discussion - zsync
17:18:40 <jlaska> #link http://zsync.moria.org.uk/
17:18:57 <jlaska> kparal: so what's the take-away for zsync?
17:19:08 <kparal> Oxf13: why do you think zsync etc is slower than full download? we have veery slow line, and scanning of previous image takes only 30sec
17:19:37 <kparal> we = brno branch
17:19:38 <Oxf13> because a Fedora live image is just an iso file with a squashfs imge file in it
17:20:00 <Oxf13> and the squasfs image file isn't lined up in a way that r/zsync can take advantage of only syncing the differences
17:20:32 <Oxf13> the data is essentially random, not useful with rsync
17:20:53 <jlaska> does this require some server-side data files to assist?
17:21:02 <jlaska> like delta-rpms and delta-isos?
17:21:20 <kparal> Oxf13: haven't really tried, so I can't say. i will probably try it with some live images, just for curiosity :) but if it is the way you say it, then it really can't help
17:21:30 <adamw> there's no practical way you can do a delta between two fedora-style live images, AIUI
17:21:44 <dpravec> kparal: squashfs is pretty heavy ;)
17:21:44 <kparal> jlaska: a small .zsync file is generated on the server side and downloaded by the client, that's all
17:21:49 <adamw> deltas work for installer-style Fedora images because they contain discrete package files, many of which don't change
17:22:08 <dpravec> i mean you will be hardly able to improve it - if all is in one squashfs image
17:22:17 <kparal> alright
17:22:41 <adamw> but as oxf13 says, our live images are, practically speaking, one big 600+MB file which contains a filesystem image, and if you tweak even the smallest thing in the image, the data is completely different as far as any kind of delta system is concerned
17:22:45 <adamw> right, jesse?
17:22:58 <Oxf13> that's my understanding
17:23:04 <jlaska> #idea Can zsync be used to improve download speed of rawhide live images?
17:23:42 <adamw> i suppose theoretically you could build a filesystem image tool and a delta tool which worked in such a way that you could generate a useful delta, but i'm not aware that any such thing exists at present...
17:23:47 <wwoods> as I understand zsync & squashfs, zsync isn't going to help anything at all
17:24:27 <dpravec> adamw: i see what you mean :D
17:24:30 <jlaska> #agree consensus is that zsync won't improve download speed since live images are a single squashfs image. May be useful for milestone ISO downloads where delta-iso is used
17:24:40 * jlaska playing with meetbot
17:24:48 <jlaska> #agreed consensus is that zsync won't improve download speed since live images are a single squashfs image. May be useful for milestone ISO downloads where delta-iso is used
17:24:49 <wwoods> someone should test this theory, though
17:25:04 <kparal> i think i will play with it tonight :)
17:25:07 <adamw> is that the time-honored version of 'someone' which means 'anyone but me'? :)
17:25:10 <wwoods> because the idea will keep coming back unless we have some data to back/disprove the assertion
17:25:21 * adamw uses that 'someone' a lot
17:25:33 <wwoods> adamw: usually people use 'we' for that
17:25:37 <adamw> hehe
17:25:40 <jlaska> #action kparal to test download zsync downloads
17:26:01 <wwoods> rsync actually works quite well on the normal DVD/CD images
17:26:02 <jlaska> well, too many 'download's in that stmt ... but you get the idea :)
17:26:13 <wwoods> but squashfs is going to get in the way
17:26:31 <jlaska> #topic Open discussion - <your topic here>
17:26:44 <jlaska> any other issues folks want to discuss in the meeting today?
17:27:00 <jlaska> favorite error messages?
17:27:04 <jlaska> missing test days?
17:27:09 <jlaska> :)
17:27:10 <fenris02> any thoughts on removing suid and using caps?
17:27:14 <dpravec> do you remember my ponny ? i think i can have one, but i will write about it next meeting
17:27:35 <adamw> yay
17:27:39 * adamw loves ponies
17:27:47 <jlaska> fenris02: is that mozilla specific?
17:27:55 * jlaska looking at http://www.mozilla.org/projects/security/components/ConfigPolicy.html
17:28:12 * jlaska figures google steered me wrong
17:28:21 <fenris02> jlaska, no, you can remove suid from ping, traceroute, cups, etc.. and replace with caps
17:28:41 <adamw> i think that's more suited to a development group discussion than QA group
17:28:45 <dpravec> thats interesting
17:29:00 <jlaska> fenris02: I think adamw hit the nail on the head there
17:29:05 <fenris02> it was slated to be in f12 according to the wiki so i asked :)
17:29:19 <jlaska> fenris02: if a larger change ... perhaps worthy of a feature page
17:29:21 <adamw> er, i may be missing the question :)
17:29:31 <jlaska> fenris02: is there a feature for this already?
17:29:37 * jlaska queues up FeatureList
17:29:38 <adamw> are you talking about https://fedoraproject.org/wiki/Features/LowerProcessCapabilities ?
17:29:41 <fenris02> moment, let me see if i can find it
17:30:06 <fenris02> quick-draw adam got it
17:30:11 <jlaska> hehe
17:30:23 <jlaska> #topic Open discussion - Features/LowerProcessCapabilities
17:30:45 <adamw> so what's the question about it?
17:30:46 <dpravec> let me remind, we have new mailing list ! low traffic announcments about testing events!
17:30:47 <jlaska> # Last updated: 2009-08-31
17:30:49 <jlaska> # Percentage of completion: 50%
17:30:50 <dpravec> https://admin.fedoraproject.org/mailman/listinfo/test-announce <-- maillist page
17:31:19 <fenris02> adamw, it hasnt moved, and isnt in f12a yet.
17:31:21 <jlaska> fenris02: is this just a status check on the feature for F12?
17:31:38 <fenris02> jlaska, pretty much
17:32:10 <wwoods> seems like "too late to complete for F12, defer to F13"
17:32:21 <adamw> yeah, me too
17:32:24 <wwoods> since we're past the feature freeze
17:32:30 <jlaska> 50% complete ... eeek
17:32:31 <adamw> it's a freaking nightmare from a qa perspective and we didn't ship it in alpha, so...ugh
17:32:40 <fenris02> wwoods, yeah, i was afraid of that
17:32:43 <wwoods> is that fact not widely known, or something?
17:32:51 <wwoods> it's past feature freeze. if it's not in now, it's not going in
17:32:59 <fenris02> jlaska, most of it's trivial, depends how much they want to implement
17:33:10 <adamw> it's been discussed somewhat on -devel-list
17:33:22 <adamw> i think there was some kind of suggestion of doing a small subset of the changes, but i forget the details
17:33:47 <jlaska> anyone interested in chasing down status on this feature w/ sgrubb and the FeatureWrangler?
17:34:20 <wwoods> I suppose if the work is already done for, say, the stuff that appears in a minimal install
17:34:26 <wwoods> then the feature could get split up
17:34:36 <jlaska> part#1 - F12, part#2 - F13
17:34:39 <jlaska> yeah
17:35:05 <fenris02> ping/traceroute are completely trivial. httpd is not exactly trivial. (for examples of each)
17:35:06 <jlaska> that's reasonable and we seem to be doing that more and more now with other features
17:35:18 <wwoods> but yeah, otherwise: not finished, past feature freeze, you now have 6 months to finish for F13, good luck
17:35:43 <jlaska> is this worth a check-in w/ the maintainer ... or does this get auto punted?
17:36:08 <jlaska> there are plenty on the list still that are not @ 100% complete
17:36:14 <jlaska> so this is a larger can of worms
17:36:27 <dpravec> also mtr is not useable by normal user...
17:36:31 <jlaska> all but 2 are @ 85% and higher
17:37:55 <jlaska> I think this will be an outstanding todo ... I don't know of any good ways to tackle this now (open to ideas)
17:38:18 <fenris02> there's quite a list of "easy" ones, but it would need rpm package changes. (eject killall modprobe ntpdate qemu route)
17:38:21 <jlaska> #idea should 'Lower Process Capabilities' be split into two features ... one for existing F12 work, and one for remaining F13 work
17:39:08 <jlaska> fenris02: do you want to reach out to sgrubb on this?
17:39:30 <fenris02> jlaska, sure, i'll see how i can help
17:39:34 <jlaska> I'll be happy to take it, unless 'someone' else would be better suited
17:39:59 <jlaska> fenris02: thanks, feel free to include me on the list ... I'm curious too
17:40:16 <jlaska> #action fenris02 - check-in w/ sgrubb on devel status of https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
17:40:26 <jlaska> okay ... let's wrap things up today
17:40:46 <jlaska> please follow-up to fedora-test-list@ or #fedora-qa should any new issues come up before next week
17:40:57 <jlaska> thanks all for your time :)
17:41:29 <adamw> yaay, we're free
17:41:30 <jlaska> #endmeeting