From Fedora Project Wiki

< QA‎ | Meetings


People present (lines said)

  • jlaska (184)
  • kparal (45)
  • wwoods (42)
  • maxamillion (31)
  • Viking-Ice (19)
  • jskladan (18)
  • tk009 (17)
  • zodbot (13)
  • skvidal (7)
  • jsmith (1)



Previous meeting follow-up

  1. maxamillion to draft up some proposed policy docs for qa FAS group membership
  2. jlaska / maxamillion to co-ordinate with sectool test day hosts tmraz, mbarabas and pvrabec who may be able to contribute
    • No traction this past week. Jlaska will reach out post-meeting to sectool test day

Fedora 13 Alpha test status

Alpha RC#4 is available for testing. Instructions for downloading and providing feedback available at:

Current list of unresolved bugs blocking the Fedora_13_Alpha_Release_Criteria ...

  • RHBZ #567346 - MODIFIED - gpk-update-viewer does not display changelogs nor updates packages
  • RHBZ #569377 - NEW - CDROM install unable to eject disc - storage: error ejecting cdrom sr0: (5, 'Input/output error')

kparal asked to review new bugs for Alpha criteria:

  • RHBZ #569352 - Broken dependencies for
    • Reassigned to Package-x-generic-16.pngyum-langpack and requesting feedback from Jens Petersen
  • RHBZ #569355 - Broken dependencies for 2:gimp-2.6.8-4.fc13.x86_64
    • Appears to be resolved CLOSED NEXTRELEASE

development/13 bug procedures

Discussed at the BugZappers meeting last week. Just want to remind folks about the process here. When closing Fedora 13 bugs, use resolution: CLOSED, status: ERRATA.

tk009 reminded the group that additional action items were needed. Join #fedora-meeting for the next BugZapper meeting to discuss further.

AutoQA Updates


  • wwoods informed the group that there is a working yum-based depcheck script available in git (see;a=blob;f=tests/depcheck/depcheck).
  • wwoods was working towards adding built-in tests for the script, but realizes that the same built-in tests used to validate yum behavior apply to depcheck, so there isn't need to re-invent the wheel.
  • Next steps involve thinking about how the updates test process workflow will look. Packages will need to land in some staging tag for depcheck to work it's magic, then tag the packages for the desired repo (updates or updates-testing).

Maxamillion asked whether there could there be something like "chain-test" that is similar to "chain-build" in koji?


  • kparal informed the group that another design discussion was held last week (see recap).
  • Kparal has begun working on use cases for resultsdb (see AutoQA_resultsdb_use_cases), and is discovering that the use cases are often about autoqa itself, not resultsdb.
  • jskladan also started drafting a db scheme (png or dia file).


  • jskladan finished the initscript checking test last week. No new updates to share
  • Had a discussion with benl who pointed out potential licensing issues with re-using tests. Might have to rework the licensing of the tests.

Install Automation

Updates include:

 1. support DVD boot, with virt-install --cdrom to create VM
 2. support local kickstart and remote kickstart file(http,ftp,etc...)
 3. user environment checking to run this script
 4. some requisite software package check before running
 5. use dogtail to pass args to kernel
 6. create an additional hard disk to upload and store kickstart file


  • jlaska - No updates to packaging. Investigating hosting a FAD to help focus packaging efforts without distraction.

Open discussion - <Your topic here>

  • Kparal provided updated test results on RHBZ #569352 and noted it is specific to Package-x-generic-16.pngyum-langpack.
  • Kparal and Jlaska discussed whether this was an Alpha blocker and decided to note it in CommonBugs and wait for Jens feedback to better assess the impact to Alpha testers.

Upcoming QA events

Action items

  1. maxamillion seeking input from the group for guidance on mentor responsibilities
  2. continued testing of bug#567346 to further isolate the failure conditions
  3. jlaska - update AutoQA_PatchProcess to include git repo

IRC transcript

jlaska #startmeeting Fedora QA Meeting 16:00
zodbot Meeting started Mon Mar 1 16:00:14 2010 UTC. The chair is jlaska. Information about MeetBot at 16:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00
jlaska #meetingname fedora-qa 16:00
zodbot The meeting name has been set to 'fedora-qa' 16:00
jlaska #topic Gathering critical mass 16:00
* tk009 listens in 16:00
* kparal 16:00
jlaska greetings tk009 and kparal 16:01
jlaska maxamillion: howdy 16:02
jlaska is adamw coherent after yesterday? 16:02
* Viking-Ice takes a break from his daily activate from securing world domination and drops in.. 16:02
jlaska Viking-Ice: welcome 16:02
Viking-Ice and by activate I activity 16:03
Viking-Ice ken lee strikes again.. 16:03
jlaska wwoods around? 16:03
jlaska I see jskladan lurking too 16:03
* jskladan here 16:04
maxamillion jlaska: hi hi 16:04
jlaska greetings gents 16:04
jlaska alright, hopefully adamw and wwoods will join ... let's get started 16:04
jlaska #link 16:05
Viking-Ice adamw is probably wasted somewhere wearing the Canadian mascot uniform with empty keg and the gold.. 16:05
jlaska that's the proposed agenda 16:05
jlaska Viking-Ice: hopefully not passed out in a street somewhere :) 16:05
jlaska #topic Previous meeting follow-up 16:05
jlaska well, the hot news last week was the Alpha, so that may impact the items we were tracking 16:05
jlaska maxamillion, you're first up 16:05
jlaska #info maxamillion to draft up some proposed policy docs for qa FAS group membership 16:06
maxamillion ok, so I kinda ran with this a little ... 16:06
jlaska any progress or challenges on this front? 16:06
maxamillion I'm proposing calling those who are members of the group be called "Critical Path Wranglers" 16:06
maxamillion <--- I sent this email last Friday 16:06
maxamillion <--- here is my proposal (in *very* rough draft form) 16:07
jlaska nice! that totally slipped under my mail radar 16:07
* jlaska hopes meetbot includes those links 16:07
maxamillion I think you have to #link them 16:07
jlaska #link 16:08
jlaska #link 16:08
maxamillion :) 16:08
jlaska maxamillion: great stuff! Thanks for taking the lead, I'll queue that up for feedback on my end 16:08
jlaska maxamillion: anything you wanted to call out in the meeting? 16:08
maxamillion jlaska: nothing specific, just looking for feedback :) 16:09
tk009 I'd like to ask a questions 16:09
tk009 I see pick a entor 16:09
maxamillion tk009: fire away 16:09
tk009 mentor 16:09
tk009 do you already have entors lined up? 16:09
tk009 grr m key 16:09
tk009 mentors lined up that should have read 16:09
maxamillion tk009: no, that's the parth is FIXME ... I think we need to discuss that actually 16:10
tk009 mentors can be hard to come by but make a huge difference 16:10
maxamillion I think that any member of the QA FAS group or "Critical Path Wranglers" should be a potential mentor but it will simply be a "case by case" situation .... 16:10
jlaska maxamillion: do some groups document mentor responsibilities? 16:11
maxamillion jlaska: uhmm.... honestly not sure 16:11
maxamillion but that would be something we would probably need to outline 16:11
tk009 there is a fedora mentor group I think 16:12
Viking-Ice So we are going to reactivate the QA group (: 16:12
maxamillion Viking-Ice: yeah, its part of the no frozen rawhide bit 16:12
jlaska Viking-Ice: yeah, we now have a reason too 16:12
jlaska maxamillion: so should we keep this on the agenda for next week ... and work feedback on the list in the meantime? 16:13
maxamillion jlaska: I think that's a good idea and I think I might follow up this week with asking for some input from the group 16:13
jlaska #info mailing list feedback throughout the week 16:14
jlaska #action maxamillion seeking input from the group for guidance on mentor responsibilities 16:14
jlaska maxamillion: just an idea, I dunno if that's a requirement or not 16:14
jlaska nice work, thanks again for owning this 16:14
maxamillion jlaska: I think its a good path to follow, none better to ask for input than those who currently do :) 16:15
maxamillion thanks, np! 16:15
jlaska okay next item ... 16:15
jlaska #info jlaska / maxamillion to co-ordinate with sectool test day hosts tmraz, mbarabas and pvrabec who may be able to contribute 16:15
jlaska maxamillion: I'll fire this off after the meeting today ... apologies for delay 16:15
maxamillion jlaska: no worries 16:15
maxamillion I unfortunately admit that it slipped my mind :/ 16:16
jlaska maxamillion: I'll pull them in to see if they have any thoughts to share from their sectool work 16:16
jlaska alright ... that's all I had from last week 16:17
maxamillion sounds good! 16:17
jlaska anything else to cover before talking about F-13-Alpha? 16:17
maxamillion not that I can think of .... 16:17
jlaska alrighty ... moving on, stop me if there's more to discuss 16:18
jlaska #topic F-13-Alpha-RC4 test status 16:18
maxamillion will do 16:18
* maxamillion queues up things to throw at jlaska 16:18
maxamillion :) 16:18
jlaska maxamillion: aim high please 16:18
maxamillion lol 16:18
jlaska maxamillion: and don't ask Viking-Ice to shoot ... he's too accurate 16:18
jlaska #info Alpha RC#4 is available for testing. Instructions for downloading and providing feedback available on the wiki at ... 16:19
jlaska #link 16:19
jlaska #link 16:19
maxamillion on the topic of the F-13-Alpha-RC4 stuff, I had some internet troubles at home this weekend and wasn't able to pull down an image to do some testing on for Xfce but am going to try and get that done today 16:19
jlaska maxamillion: much appreciated, I see we have some KDE results now also 16:19
jlaska a hardy thank you to everyone for pitching in on testing last week (and prior) 16:20
jlaska An Alpha test summary should be going out later this week ... but my view of the blocker list shows 2 items 16:20
jlaska .bug 567346 16:21
zodbot jlaska: Bug 567346 gpk-update-viewer does not display changelogs nor updates packages - 16:21
jlaska and ... 16:21
jlaska .bug 569377 16:21
zodbot jlaska: Bug 569377 CDROM install unable to eject disc - storage: error ejecting cdrom sr0: (5, 'Input/output error') - 16:21
jlaska with regards to 567346 - kparal and jskladan noted that this might only occur when there are deps issues present in the repos? 16:21
kparal jlaska: just testing it now. and I believe so 16:22
jlaska kparal: that's a great data point 16:22
jlaska I'll try that after the meeting as well 16:22
jlaska #action continued testing of bug#567346 to further isolate the failure conditions 16:22
kparal jlaska: I have today added two bugs into the matrix: 16:23
jlaska With regards to bug#569377, I've only hit this on bare metal CDROM installs, which technically affect the Beta criteria 16:23
kparal jlaska: but didn't mark them as blockers 16:23
jlaska kparal: okay, let's review them ... 16:23
kparal 16:23
kparal 16:23
jlaska .bug 569352 16:24
zodbot jlaska: Bug 569352 Broken dependencies for - 16:24
jlaska .bug 569355 16:24
zodbot jlaska: Bug 569355 Broken dependencies for 2:gimp-2.6.8-4.fc13.x86_64 - 16:24
jlaska kparal: I wonder if that first issue is something funky with the langpack plugin? I was experiencing similar funkiness during last weeks langpack test day 16:24
kparal jlaska: I will try to disable the plugin 16:24
jlaska the gimp bug seems to be fixed already, that was fast 16:25
kparal should we mark the first one as blocker? 16:25
Viking-Ice I installed the depended oo-core --nodeps from koji then updated without a hitch 16:25
jlaska kparal: according to the Alpha criteria, deps and conflicts issues are limited to the media kit 16:26
jlaska eeew --nodeps ... bad Viking-Ice : 16:26
jlaska :) 16:26
kparal alright then 16:26
Viking-Ice hehe 16:26
jlaska kparal: but if it's something more pervasive with yum-langpack ... that might change things ... let's keep working it 16:26
* skvidal sighs - I have a dream of a world where the rpmdb records when people do stuff like that 16:26
jlaska skvidal: and emails their personal information to a public mailing list? 16:27
skvidal jlaska: or just threatens their pets 16:27
skvidal :) 16:27
jlaska skvidal: fine choice 16:27
Viking-Ice skvidal: already shoot mine 16:27
skvidal everytime you use --nodeps we kick your dog 16:27
jlaska we'll save continued discussion on this topic for #fedora-peta 16:28
Viking-Ice thank good it aint my balls.. 16:28
skvidal yes 16:28
skvidal sorry for the interruption 16:28
* skvidal goes back to lurking 16:28
jlaska hehe 16:28
jlaska kparal: thanks for the updated bugs 16:28
jlaska those are all the issues on the radar at this time 16:29
jlaska any other Alpha show stoppers folks want to bring up? 16:29
Viking-Ice there was an install issue with anaconda 16:29
Viking-Ice next next done 16:29
jlaska Viking-Ice: ? 16:29
Viking-Ice failed custom worked.. 16:29
jlaska got a bz or mailing list link? 16:29
* Viking-Ice goes looking for the bug report 16:29
jlaska okay 16:29
Viking-Ice .bug 567840 16:31
zodbot Viking-Ice: Bug 567840 LVMError: lvdeactivate failed for lv_swap: LV VolGroup/lv_swap in use: not deactivating - 16:31
jlaska Viking-Ice: ah 16:31
jlaska Viking-Ice: that is marked as resolved in RC#4, are you still hitting it? 16:32
jlaska Viking-Ice: there is an unresolved bug affecting partitioning on a system that already has encrypted partitions 16:32
jlaska .bug 565848 16:32
zodbot jlaska: Bug 565848 LVMError: lvactivate failed for lv_root: Skipping volume group vg_test1148 - 16:32
jlaska that's on the list for F13Beta at the moment 16:32
Viking-Ice .bug 567840 sorry wrong number.. 16:33
wwoods is that the "LVM + 512MB = kaboom" bug 16:33
zodbot Viking-Ice: Error: '567840 sorry wrong number..' is not a valid integer. 16:33
Viking-Ice .bug 567840 16:33
zodbot Viking-Ice: Bug 567840 LVMError: lvdeactivate failed for lv_swap: LV VolGroup/lv_swap in use: not deactivating - 16:33
wwoods ah 'kay 16:33
Viking-Ice sorry it's the same number lol 16:34
jlaska wwoods: oh good call, that might be 16:34
maxamillion jlaska: I have to run, I'll catch the rest on the mailing list from the minutes 16:34
Viking-Ice I need to retest with anaconda-13.32-1.fc13 16:34
jlaska maxamillion: thanks! 16:35
jlaska I can't find the bz at the moment ... but 512M (and even 768M) of memory are no longer sufficient for x86_64 installs 16:35
jlaska .bug 559290 16:35
zodbot jlaska: Bug 559290 LVMError: lvcreate failed for VolGroup/lv_root - 512M insufficient for Fedora install - 16:35
jlaska Viking-Ice: okay, we'll stay tuned to the blocker list for updates on that 16:36
kparal I have installed RC4 64bit with 768M 16:36
jlaska kparal: I've had luck with 768M also 16:36
jlaska I think adamw might have had issues w/ 768M in a live install ... not sure 16:36
kparal yes, the live install will probably need more 16:37
Viking-Ice well my laptop is i686 and has gig memory 16:37
jlaska definitely the previous documented minimum is insufficient ( 16:37
jskladan and i have RC4 64 bit up&running in KVM with 512M RAM :-D lucky me i guess :) 16:37
jlaska jskladan: using LVM? 16:37
jskladan but i did not install from livecd, thats true 16:37
jskladan i think so, i just went next next finish in installer 16:37
jlaska jskladan: wow, you are lucky then! :D 16:38
jlaska alright gang, we'll stay tuned to the blocker list for more updates 16:38
jlaska wanted to highlight a BugZappers meeting item ... 16:38
jlaska #topic Development/13 bug closure 16:38
jlaska tk009: still around? 16:38
tk009 yes 16:38
tk009 adamw was leading this item 16:39
jlaska tk009: Hey! I just wanted to highlight what you guys discussed in last weeks bugZappers meeting 16:39
tk009 however 16:39
tk009 =) 16:39
jlaska it looks like adamw has some follow-up items, but the decision was to close Fedora 13 bugs (aka development/13) as CLOSED ERRATA right? 16:40
tk009 correct 16:40
tk009 and we are going to rebase all rawhide bugs to f13 16:40
tk009 it should have been done already 16:40
jlaska excellent! 16:40
jlaska so for any questions or concerns, please join the BugZappers meeting tomorrow 16:41
jlaska #link 16:41
tk009 however fail on mine and adamws part. I will get with poelcat today once the wiki stuff is done to get with redhat eng for the rebase 16:41
jlaska #info the decision was to close Fedora 13 bugs (aka development/13) as CLOSED ERRATA 16:41
jlaska #info going to rebase all rawhide bugs to f13 16:41
jlaska #info Continued discussion during next BugZappers meeting 16:42
jlaska tk009: nice, thanks for the updates 16:42
jlaska alright, last planned topic was a brief check-in with everyone on autoqa ... 16:42
jlaska #topic AutoQA updates 16:42
jlaska wwoods, I've got you up first for your patch/devel policy thread 16:43
jlaska #info wwoods posted a development/patch policy proposal - 16:43
wwoods ah, okay. yes, I sent a mail to autoqa-devel with some proposed guidelines for autoqa development 16:43
wwoods the summary: 1) hooray for git, 2) if you have small patches, send them with git-send-email if possible 16:44
wwoods 3) if you have bigger changes, either clone the repo and send a patch set from your local branch 16:44
wwoods or ask and we'd be happy to help you make a personal branch in the public repo 16:44
wwoods and 4) wwoods is the maintainer/patchmaster for the 'master' branch, which represents our current production code 16:45
wwoods (although I happily delegate responsibility for applying patches to jlaska + kparal sometimes) 16:45
wwoods there hasn't been much controversy about the plan - and I've talked about it a bit with some folks who are more familiar with git-based development (e.g. kernel guys) 16:46
jlaska wwoods: you okay with being the master patch delegator? 16:46
kparal which was my question, if the delegation happens according to your (e.g. time) needs or we can judge by ourselves 16:46
wwoods kparal: assume that I'll handle all the patches, but if I get swamped I'll ask for help 16:46
wwoods at the same time, feel free to poke me if I seem to have dropped/lost an important patch 16:47
kparal wwoods: ok. I don't have a problem with the policy, I just want to understand it, so not to break it from the start :) 16:47
wwoods I'll freely admit that I'm probably going to forget or drop patches at some point, and I'd therefore like to be reminded of them if they're important 16:47
jlaska I see ping's on anaconda-devel-list for that sort of thing from time to time 16:48
wwoods probably it'll be like: "dude will you forgot this patch and it's really important" 16:48
kparal wwoods: and second suggestion was about private branches, imho it's easier if people create their own and publish it on e.g. fedorapeople, but you added that to the description above 16:48
wwoods "aw crap sorry, go ahead and apply that" 16:48
wwoods kparal: right - either they can have a local one and send patches/patchsets from that, they can publish their copy on their fedorapeople page 16:48
wwoods or if it's an ongoing process where they're constantly sending patches and merge requests it might make sense to keep their branch in the autoqa repo 16:49
kparal sure, ok 16:49
wwoods but yes, the fedorapeople suggestion is a good one 16:49
wwoods do you have a link to some instructions about the best way to publish a git repo on your fp page? 16:49
* jlaska once I clear out my local changeset ... I'll queue up a remote git branch 16:50
jlaska #link 16:50
kparal aw, jlaska was faster 16:50
kparal as always 16:51
jlaska kparal: nah, thank my firefox 16:51
wwoods nice, thanks 16:51
jlaska kparal: want me to add that link to the patch process wiki page? 16:51
kparal I think it's needed when you want to have "git://" access. but any http server is good enough 16:51
jlaska #action jlaska - update AutoQA_PatchProcess to include git repo 16:51
jlaska kparal: okay 16:52
wwoods so yeah, that's the policy. it all seems sound, so probably it will get put in the autoqa trac wiki and/or fp.o wiki.. somewhere 16:52
kparal autoqa trac wiki sounds good 16:52
jlaska We've got patch submission and branching currently documented at 16:52
jlaska but I can easily adjust or 16:53
jlaska move the content if needed 16:53
kparal I think it can coexist, it can just reference the policy 16:53
jlaska okay 16:53
jlaska alright, next topic? 16:53
wwoods sure 16:53
jlaska wwoods: I've got you for an encore show ... 16:53
jlaska what's the latest on the depcheck front? 16:54
jlaska #topic AutoQA updates - depcheck 16:54
wwoods no change - been working on other things 16:54
jlaska something called an Alpha I hear? 16:54
wwoods the current status is.. there's a working, yum-based depcheck script 16:54
wwoods it needs some basic testing but since it's using the yum code for its depsolving, and yum has its own set of unit tests for depsolving 16:55
wwoods we can assume that it's correctly depsolving the packages given 16:55
wwoods or at least doing it wrong in exactly the same way that yum does 16:55
jsmith wwoods: Link to said script? 16:55
jlaska #info there's a working, yum-based depcheck script in git 16:55
kparal :)) 16:55
wwoods;a=blob;f=tests/depcheck/depcheck 16:55
wwoods here's where things get complex: now that we have an algorithm to test, we need to figure out *what* to test 16:56
wwoods just testing every new build/update *by itself* will not work 16:57
wwoods we need some way of batching the new builds/updates and testing them as a group 16:57
jlaska wwoods: this is for updates from different src.rpm's that are dependent? 16:57
wwoods until the proposed group is proven to be closed with respect to the existing published repos 16:57
wwoods correct 16:58
wwoods handling this might require some changes to bodhi/koji 16:58
wwoods to have an intermediate tag to hold the pending/proposed new updates/builds 16:58
wwoods until such time as they pass depcheck and can actually be cleared for pushing 16:59
wwoods it requires some careful thought and testing and I haven't had time for it recently 16:59
wwoods hoping to get back to it.. this week, maybe 16:59
jlaska is this something you'd need to pull rel-eng into, or is this head down / loud music time? 17:00
wwoods the latter; it might prove to be easiest to keep the list of pending/held updates internal to autoqa 17:00
kparal wwoods: I think the "tag to hold" will go along with the prepared policy to do autoqa testing for each new package 17:00
jlaska kparal: indeed! 17:01
wwoods kparal: true - a good policy probably requires an intermediate tag between fresh, untested builds and stuff that passes autoqa 17:01
jlaska wwoods: okay, so just keep this is a regular check-in next week? 17:02
* wwoods a little confused 17:03
wwoods yeah, a checkin on this next week would be a good idea 17:03
jlaska #info testing multiple dependent packages still needs some careful thought 17:03
jlaska wwoods: sorry, yup that's what I meant 17:03
jlaska wwoods: thanks for the updates 17:04
jlaska #topic AutoQA updates - resultsdb 17:04
jlaska kparal, you want to give an update on this front? 17:04
* maxamillion is back 17:05
kparal ok, so, we had another discussion about the concepts of autoqa resultsdb 17:05
kparal I have started to write some use cases that could be helpful when designing the resultsdb 17:05
kparal nothing there yet, but it will be at 17:06
kparal I have something drafted already, but I found out that it is very often about autoqa itself, not about resultdb per say :) 17:06
jlaska #info Another design discussion held last week - 17:06
kparal *per se 17:06
jlaska I've got some nitrate feedback to provide this week 17:07
kparal great 17:07
kparal and jskladan started some drafting of db schema 17:07
jskladan and i made i draft of DB scheme from kamil's an mine thoughts - available here 17:07
kparal it will be also available somewhere on wiki and announced on autoqa-devel 17:08
jlaska nice, so we're doing a mailing list checkin on Friday again? 17:08
kparal we still have to discuss it, I had not much time to go through it 17:08
kparal jlaska: yes we can 17:08
jskladan the division to "resultdb" and "TCMS?" is made mainly for the sake of "dividing information" - i think, that the resultdb part is completely satisfactory for storing results 17:09
jskladan but one might like to have some metadata on tests 17:09
jskladan (that's the tcms part of the sheme) 17:09
jlaska jskladan: I see, thanks. I'd be curious how that lines up to what israwhidebroken uses now 17:10
jlaska in the interest of time, shall we move to the next topic? 17:11
jskladan haven't seen it yet (or it sliped my mind), so i do not know - any link? :) 17:11
jlaska kparal: jskladan anything else to highlight before Friday? 17:11
jskladan we can move on IMO 17:11
kparal that would be all 17:11
jlaska jskladan: jskladan;a=tree;f=front-ends/israwhidebroken;h=382dbdc09ac06415b6211f60c196273ebbf18743;hb=HEAD 17:11
jlaska thanks for the updates gang 17:11
jskladan jlaska: thx 17:11
jlaska #topic AutoQA - beakerlib 17:11
jlaska jskladan: I left this on the agenda, but not sure if there were any updates/concern you wanted to share 17:12
jskladan OK, last week i somehow finished the initscript checking thingie 17:12
jskladan but since then nothing new 17:12
jskladan i only spoke with benl about licenses 17:13
jskladan of the tests we'd like to re-use 17:13
jlaska Anything you want to track for the next meeting? 17:13
jskladan and he pointed out, that legal might have to revise the licenses and stuff 17:13
jskladan before pushing stuff upstream 17:13
maxamillion I might have come into this too late, but could there be something like "chain-test" that is similar to "chain-build" in koji? 17:14
maxamillion nvm, that was an old topic 17:14
* maxamillion was still scrolled up like a noob 17:14
jlaska maxamillion: no worries 17:14
jlaska jskladan: okay, we'll keep that on the radar 17:14
jlaska #topic AutoQA - install automation 17:15
jskladan that's all from me on this 17:15
jlaska jskladan: thanks, I'm already keeping you guys late, so I'm moving fast now :) 17:15
jlaska Folks on autoqa-devel probably saw this, but Liam is making good progress with the dvd install automation script 17:15
jlaska #link 17:16
jlaska the big change is the use of dogtail to automate passing kernel boot arguments to the DVD install 17:16
jlaska in addition to more test case cleanups 17:16
jlaska I spoke with Liam this morning (evening) and he's going to look into having the script prepare the at-spi (and X) environment needed for testing ... instead of relying on an existing root desktop session 17:17
jlaska and last up ... 17:17
jlaska #topic AutoQA - packaging 17:17
jlaska #info no updates 17:17
wwoods man, automating media-based installs is pretty huge 17:17
jlaska wwoods: and painful! :) 17:18
jlaska nothing great to share on the packaging front ... I'm working some other approaches to try and get some focused packaging time to knock this out in batch 17:18
jlaska I'm waiting to hear back from Max, but I think this would make a good FAD session 17:19
jlaska so hopefully I'll have more to share on that next week 17:19
jlaska alright ... that's all for AutoQA 17:19
jlaska open topic time ... 17:19
jlaska #topic Open Discussion - <your topic here> 17:19
jlaska Anything to discuss that we've not already touched on? 17:20
kparal yes 17:20
kparal .bug 569352 17:20
jlaska kparal: take it away 17:20
zodbot kparal: Bug 569352 Broken dependencies for - 17:20
kparal it's really problem of yum-langpacks plugin 17:20
jlaska #topic Open Discussion - 17:20
kparal do we consider that a blocker? and which blocker? 17:20
jlaska #link 17:20
* jlaska looking through 17:21
kparal I did a quick search over the release criteria and haven't found to which milestone should we assing bugs in accepted features 17:21
jlaska #info I did a quick search over the release criteria and haven't found to which milestone should we assing bugs in accepted features 17:22
jlaska iirc, the topic of bugs in features came up during our initial review of the criteria @ FUDCon 17:22
jlaska and it's completely slipping my mind right now 17:23
kparal ok, so what next? :) 17:23
jlaska kparal: Unless anyone else has ideas, I'll need to think on this one a bit 17:24
jlaska how'd you work around this problem? 17:24
kparal just disable the plugin 17:24
jlaska yum --disableplugin=langpack ? 17:24
kparal I have changed a config file 17:24
kparal I can try this too 17:25
jlaska well, I'll mark this as CommonBugs material so we can document the problem, and hopefully Jens can inspect the bz tonight and offer some thoughts on the plugin side of things 17:25
kparal --disableplugin works too 17:26
jlaska kparal: okay, thanks 17:26
jlaska kparal: let's line this up for documenting the issue ... I don't have a good enough handle on how many people this would affect right now 17:27
kparal it may appear at other packages too, I don't know the cause 17:27
kparal ok 17:27
jlaska yeah, I'll monitor this while you're out tomorrow and see what Jens can offer as for impact 17:27
jlaska #topic Open Discsussion - <your topic here> 17:28
jlaska kparal: thanks 17:28
jlaska anything else to run through during todays meeting? 17:28
jlaska alright .... end of meeting. Thanks everyone. 17:30
jlaska #endmeeting 17:30

Generated by 2.7 by Marius Gedminas - find it at!