[04:47] Good morning [07:29] good morning [07:54] Good Morning all :-) === Ursinha-afk is now known as Ursinha [09:03] asac: wrt. fixing the mediaplayer bugs> I noticed that the mediaplayer doesn't currently seem to work at all on mako; that might just be what the ap test fails on? [09:05] pitti: interesting [09:06] pitti: can you reply to the mail i sent? [09:06] for ue-leads [09:06] ? [09:06] asac: sure [09:11] hello, seems ubuntu-docviewer-app autopilot tests wont work.. I wonder if it something todo with my envoroment :/ [10:22] pitti: so stated the question: what should we do with the proposed dashboard in the context of our "stricly green" mission we run elsewhere? [10:22] gema said you might have better idea how to approach this [10:29] asac: TBH I don't understand the question [10:31] pitti: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ [10:31] we have lots of reds there [10:31] asac: that's right; we need package uploaders to actually pay attention to failures there [10:32] pitti: should we go serious about it if we see that happen? or just keep it FYI? [10:32] plus, we earn quite a number of failures from Debian which we need to keep up with fixing [10:32] I'm doing quite a lot, but doing this single-handedly is too much work [10:32] pitti: are the tests maintained by upstream that we run? [10:32] or do we always have to fix tests first? [10:32] asac: most of the ones that you see there are nontrivial to fix, so it's not something you'd do on a Friday [10:32] asac: no, these come from debian/ubuntu [10:33] pitti: can you give me an example of a test that is nontrivial to fix? [10:33] asac: if a package has failing tests, it won't move out of -proposed into saucy [10:33] what about firefox? [10:33] pitti: ok we do that? [10:33] asac: unless the release team overrides it [10:33] i assume we have a whitelist? [10:33] e.g. stuff we let through anyway? [10:34] yes [10:34] asac: firefox has worked for a while, but chrisccoulson stopped maintaining it AFAIK; saucy-adt-unity-firefox-extension has never been fixed to actually work as nobody bothers [10:35] pitti: but who added a not working pkg test in first place? [10:35] for extension [10:35] asac: people who don't ensure that they actually work? .. [10:35] pitti, the last time i looked, it was not even getting to the stage of running any of the firefox tests (ie, failing much earlier) [10:35] so let me rephrase: [10:35] 1. once we had an initiative in ubuntu/canonical to write autopkg tests [10:36] 2. those are the ones that we have now [10:36] 3. unfortunately a bunch were landed brokenly [10:36] asac: we are still getting new ones [10:36] 4. and we didn't calibrate our resources/priorities to ensure taht we could fix the ones that broke [10:36] the server team recently added like 20 [10:36] pitti, https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/lastCompletedBuild/ARCH=amd64,label=adt/artifact/results/summary.log [10:36] 5. since then we have people adding tests, but its an optional, nice to have thing? [10:36] i think i need someone like jibel to look at that really [10:37] chrisccoulson: well, this just says that running xpcshell-tests was killed after 4 hours [10:37] e.g. a service that folks can or can not use ... and where releaase team has to process bunch of stuff that nobody cared about? [10:37] i think i get the picture [10:37] :-P [10:37] pitti, but the same tests run fine on raring :/ [10:38] pitti, https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-mozillateam_firefox_next-firefox/ (that's identical) [10:38] chrisccoulson: so there is some compatibility break in saucy? [10:38] chrisccoulson: so, looks like a problem with a newer library? [10:38] chrisccoulson: it doesnt matter that they run there [10:38] chrisccoulson: today is today :) [10:39] asac: these days it's optional, yes (e. g. we don't yet require it as part of MIR) [10:39] gema, i guess there must be, as the 2 examples there are using the same firefox package [10:39] chrisccoulson: the test owner needs to debug and drive it and keep it working ... folks cannot assume that QA will always maintain everything you ever did :) [10:39] that doesnt scale [10:39] asac: but it's a nice way to keep your package working and avoid new dependencies breaking it [10:39] gema, we don't know exactly what until someone (me?) have a look at what's happening in the testing environment [10:39] asac: so they are quite popular [10:39] asac, the problem is, there is no firefox maintainer anymore ;) [10:39] jibel: I know, and that doesn't quite escale [10:39] pitti: but release team has to deal with broken shit and exceptions and manual poking etc. all the time I hear? [10:40] let's really try to get those sorted imo [10:40] asac: only if people ask them to do an override because they want to land a package even if it breaks some test [10:40] what we first need is to figure who owns which tests [10:40] e.g. who was the author [10:40] asac: I agree, it would be nice to clean this up; we once were down to 4 failures or so [10:40] lets do it [10:40] and lets go for always green [10:40] asac: we also get a lot of broken ones from debian [10:41] asac: an autopkgtest fixing hackfest with 3 people (server/desktop/qa) fulltime could do nicely [10:41] we need to do that forever [10:41] we can make a priority effort to start off [10:41] yes [10:41] asac: e. g. they mysql one has a single test failure, all others succeed; these should be able to get fixed, if nothing else by disabling that one test [10:41] but people are currently under constant fire :) so all i am doing right now is start talking and thinking [10:42] pitti: yeah. there are stories for every failyure. I think we just need to clearly identify who owns each of those [10:42] so we can get them fixed [10:42] if debian owns them, lets think [10:42] at least those that we own we can clear out [10:42] asac: yes, but we also need to allocate some serious time to actually work on them [10:43] asac: and clean up tests which nobody cares about and which have always been broken (oneconf, unity-firefox-extension, etc.) [10:43] pitti: lets really have a list, each test gets one owner, we socialize that list and then everybody fixes one. with quality team helping folks to be productive rather than doing all the work [10:44] i think during that process we will find apps that nobody cares about [10:44] asac: we need domain knowledge for a lot of the tests, but many can presumably be fixed by any (core?) dev given some time [10:44] some we can clean [10:44] some we have to ensure are cared for [10:44] asac: right; we had two hackfests for that, and in both we got some nice cleanup/fixes [10:45] pitti: yeah. that doesnt really work though. its far easier just to have a clear owner who is on the hook. otherwise, its always ending up on the shoulder of a few folks that work overly hard anyway [10:45] like you :) [10:45] asac: that, too [10:45] asac: but given the current number we are going to need some extra time anyway to get back to a good situation [10:45] asac: from then on it'll be continued maintenance which should be done by the actual uploaders/teams [10:46] pitti: is there a way we can find reasonable owners? if yo ucould help me with that, I will do some talking and see what other managers think :) [10:46] finding == checking who did the test .. if that was someone from qa, who is the package uploader? [10:46] chrisccoulson: we have the policy that stuff sticks to whoever did it last [10:46] :) [10:47] chrisccoulson: thats not a policy, but a general attitude of ubuntu [10:47] :) [10:47] so in that theory you are still the firefox maintainer no matter what you signed up for :) [10:47] asac: we can certainly go through the list and sort them into "desktop/server/foundations/QA" buckets (QA being the fallback for broken tests from Debian, or problems with infrastructure) [10:47] asac: want to do that now? [10:48] asac, yeah, i see how this works now, there's no escape for me ;) [10:51] asac: I'm going through them and bucket them [10:52] pitti: yeah. just keep zero stuff assigned to the QA team for now [10:52] i would like to have a bit more discussion about the debian ones [10:52] the ones that are essential we need to find an owner in a real engineering team i think [11:20] asac: ok, review done (http://paste.ubuntu.com/5910831/) [11:20] asac: I should perhaps send that to u-devel@? [11:21] let me see [11:21] gema: ^ FYI [11:21] pitti: in those teams, do we know who did the test/work last time (e.g. the name?) [11:21] or if you didnt put a name you say: these should be owned by someone from their team [11:21] but so far tehre was no owner? [11:22] asac: we can check in changelogs, but for now I only bucketed it to a particular developer where it's clear [11:22] asac: for the regresssions that are broken by a dependency it's not immediately clear who the owner is [11:22] pitti: ok. so you say it would be clear who would own "saucy-adt-apt-clone" for instance? [11:22] asac: e. g. ubuntu-release-upgrader didn't change, but update-manager did which broke the release-upgrader [11:23] asac: again, no; apt-clone itself didn't change, but saucy underneath changed [11:23] sure, but whoever owns apt-clone has to be the owner [11:23] in the sense that he has to drive it [11:23] his app got broken [11:23] asac: I think these either need to be fixed at regular "test fix days", or the teams' tech lead should own them and distribute [11:23] so he is the only sane choice if it comes to "who must care" :) [11:23] maybe the techlead [11:24] or manager [11:24] asac: teams' TL is a good default IMHO if there is no clear individual owner [11:24] yeah. i will get individual owners anyway ... or a pai [11:24] r [11:24] but techlead/manager should say [11:25] asac: I'll send the current list to u-devel@ to raise some awareness [11:25] cool! [11:25] :) [11:25] i cant participate there though :) [11:25] but didnt plan to anyway === Ursinha is now known as Ursinha-afk [11:28] asac: err, why can't you post to u-devel@? [11:29] pitti: i got booted from everything [11:29] because i didnt see the renew mail :) [11:29] i think ubuntu-devel is restricted to devs [11:30] anyway. this is for me more of an internal management team task anyway [11:30] needs some socializing that we want to green at all :) === Ursinha-afk is now known as Ursinha [11:30] asac: I can forward it to the internal ML afterwards if you want [11:31] no its fine. let me start to raise it and then we can bring results from u-devel into that discussion [11:31] will do it verbosely for today :) [11:31] (if we get to it) [11:35] asac: sent, with you in CC [11:35] cool [11:36] asac: and fwded to ue leads [11:36] balloons, there's a bug in the auto-resize testcase... [11:36] pitti: gratias [11:36] de nada [11:37] balloons, it implies that the "select drive list" with the movable bar always appears, but i didn't get that since i had some free space on the drive. === om26er is now known as om26er|afk === iahmad is now known as iahmad|afk === _salem is now known as salem_ [12:52] balloons, also, i really think live session and persistence should be two different tests [13:02] xnox, hey :-) SO i have re-written the autopilot tests, and they now exit if an error dialog of some kind appears. I also changed how it handles the wait between each page loading and the test should no longer get stuck there. in general they are all running really well on jibel's test runner. === iahmad|afk is now known as iahmad [13:05] people testing alpha 2 images, wondering if bug 1185396 is xubuntu-specific or if it affects everybody [13:05] bug 1185396 in gnome-system-tools (Ubuntu) "users-admin crashed with SIGSEGV in gst_user_profiles_get_for_user()" [Undecided,Confirmed] https://launchpad.net/bugs/1185396 [13:59] hello all [14:00] Hello, how are u? [14:01] how to join and get started testing? [14:02] OE4SKW, i would suggest starting here https://wiki.ubuntu.com/QATeam [14:03] OE4SKW, all the info on how you can help testing can be accessed from there [14:03] ok, thank u very much fer info [14:34] pitti: the dep8 failure for abi-compliance-checker is documented on debian bug 717806. Problem seems to be gcc 4.8. This used to work in Debian sid but never worked in Ubuntu as we were already using gcc4.8. [14:34] Debian bug 717806 in abi-compliance-checker "abi-compliance-checker: self-check fails with error "can't compile header(s)"" [Important,Open] http://bugs.debian.org/717806 [14:34] jodh: ah, thanks for the info [14:35] pitti: I'm keen we get this fixed as we're having to manual disable abi-c-c from being called in the upstart build atm. [14:37] pitti: btw - do you have a feel yet for how long it might take to implement the nested kvm feature in autopkgtest? [14:37] jodh: I started on making the master VM available, but that triggered a mysterious hang in the script [14:37] pitti: the lxc dep8 test failure looks like it might be an stderr output issue as the test *does* pass. [14:38] jodh: I need to debug this more, I planned this for tomorrow afternoon [14:38] pitti: does stderr output get dumped to $ADTRESULTSDIR by default? [14:38] jodh: yes, if a test outputs stderr, it will become an artifact [14:39] jodh: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/25/ARCH=i386,label=adt/ does have a stderr attachment [14:40] E: Couldn't create temporary file to work with /var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_saucy-security_Release - mkstemp (2: No such file or directory) [14:41] pitti: looks like that error is coming from apt. [14:42] yeah, I guess lxc-create calls that [14:43] pitti: I think it might be /usr/share/lxc/templates/lxc-ubuntu. [14:43] pitti: hmm - the lxc bzr branch is out-of-date. [14:44] jodh: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ shows that the very same version succeeded before, so it could certainly be a behaviour change in apt or some other underlying tool [14:44] jodh: I can just try and re-run it if it could help [14:45] but in between the runs there are 16 days; a lot has happened in that time [14:45] jodh: so it's quite plausible that something in https://launchpad.net/ubuntu/+source/apt/0.9.9.1~ubuntu1 broke lxc-create [14:46] lxc doesn't directly depend on apt, otherwise apt would have been held back for this [14:57] pitti, it is surprising how tests are dropped easily during package syncs, it happened twice already. I'm wondering if it is the case for other distro patches [14:57] jibel: yeah, that's why I'm rather insistant of letting exit status 8 count as failure [15:05] jibel: hm, the "mount: unknown filesystem type 'iso9660'" error in gvfs' autopkgtest is stunning -- isofs.ko is not even in linux-extras, and we should have that; it doesn't happen on my desktop, trying in run-adt-test now [15:10] pitti, isn't it caused by the crash of kmod? [15:10] oh yeah, that would be it [15:11] pitti, previous runs fail for different reasons [15:11] jibel: yes, that was due to "modprobe scsi_debug" not resolving symbols [15:11] jibel: I also couldn't reproduce this [15:11] it's still odd, "log" shows in my local test run that all the tests succeeded [15:11] and "run-adt-test -s gvfs" succeeds [15:12] jibel: I'll re-try this in the actual QA machines [15:12] ok [15:17] jibel: hm, it succeeds on albali, too; WTH [15:17] * pitti runs it again, perhaps this only happens on one of the other hosts [15:24] jibel: hm, it happened again, crazy [15:29] jibel: so it works on aldebaran and falls over on wazn.. [15:29] jibel: do you know whether anything is wrong with wazn? [15:29] ah, wazn is raring, aldebaran is precise [15:30] jibel: so this doesn't look like a saucy bug, but something with qemu/kernel which regressed in raring and was fixed in saucy [15:31] jibel: just to verify, could I temporarily disable wazn as a slave (how do I do that?) and re-run the test? [15:35] pitti, bring it offline === netcurli_ is now known as netcurli [16:16] knome: quick question [16:17] slickymaster, yes? [16:19] knome, I want to start on the translation of Xubuntu-docs, Saucy series. Do you think it's preferable to do it in LP (translations in Rosetta) or should I download the tarball and the upload the translation? [16:19] slickymaster, they both should give the same results. [16:20] knome: yeah, I know :) just asking what you think should be the best approach to do it? [16:20] slickymaster, just a note that i'm not sure if we can get the translations set up for saucy (or T), but we'll certainly hope to get to use them (as soon as possible) [16:21] knome: yes, it's quite big, but I'll try to do as much as I'll manage to [16:21] slickymaster, as long as you're the only one working on the translation for that specific language, i think it might be slightly better to work on it offline [16:22] slickymaster, not about having complete translations, more related to the technical side of being able to enable them to those who use non-english languages [16:23] knome, I see what you mean. Anyway as I'm a member of the portuguese translators team I'll mail them alerting them I'm working on it [16:24] slickymaster, sure :) [16:24] knome, thanks :) [16:24] np [16:42] ping balloons. I have some questions about the test case. [16:43] elopio, hey, I was going to see how it was going :-) [16:43] balloons: I tried to extract the common things, and just got some questions, no real code :) [16:43] balloons: what's the --desktop_file_hint for? [16:43] balloons, check your awaylog :P [16:45] knome, :-) xchat lied to me, sorry [16:50] elopio, where are you seeing that? [16:51] balloons: do we have any resources (e.g. wiki page) for smoke testing? No rush for an answer, I'll be doing some wiki editing on https://wiki.ubuntu.com/Testing/Activities a bit later. [16:51] phillw, smoke testing, smoke testing.. hm hmm hmm [16:52] also is there a page for hackfests? [16:52] so knome if I get what your saying, because you had enough free space already the installer just used it and didn't prompt you to resize, yes? that makes sense, and we should update :-) [16:52] phillw, https://wiki.ubuntu.com/QATeam/Hackfest [16:53] thanks, I'll get that added to Activities [16:53] ty :-) [16:53] balloons: on launch_test_installed. For exampe ubuntu_filemanager_app/tests/__init__.py [16:53] balloons, yup. [16:57] elopio, ahh, ok, gotcha :--) That I believe is intended for the desktop to utilize the proper icon etc, but I make very well be wrong [16:57] knome, ok, well we should update it then. Would you like to file a bug for it, or shall I? [16:58] on the live / persistence tests, well, they are always a subject of debate, so I don't mind having a discussion on them [16:59] balloons: I'm just wondering why do we launch the app with qmlscene instead of just calling the binary. That would make things clearer, but would require the apps to change the binary to receive arguments. [16:59] elopio, good question ;-) I don't know tbh.. and actually we should test the binary or the included source.. really is silly to test the installed bits of the binary [17:00] testing that makes no sense at all.. [17:00] I think it's good to be able to run the tests against the installed package, but I don't like the way we do it. [17:01] I'm not sure how to improve that, though. Maybe we can start just refactoring it to take the binary from a method that can be overwritten or changed easily. [17:01] elopio, yes, but we should invoke the binary as you say.. the hardcoded location is fragile and will break [17:04] balloons, i can do later... or if you have the time, go ahead [17:06] balloons, my argument for separating them is that the live session is a low-hanging fruit for anybody, or those who are doing other installation tests [17:06] balloons, however, reporting a result without the persistence part is kind of useless.. [17:06] balloons, and otoh, the persistence part is a big enough chunk to warrant its own test anyway [17:06] https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1205009 [17:06] Launchpad bug 1205009 in Ubuntu Manual Tests "Auto-resize iso test assumes drive has to be resized" [Undecided,New] [17:07] knome, filing a bug for that idea is probably sane as well.. I can file one now :-) [17:08] balloons, bug 1198466 :P [17:08] bug 1198466 in Ubuntu Manual Tests "Live Session Testcase calls for Startup Disk Creator" [Undecided,New] https://launchpad.net/bugs/1198466 [17:08] balloons, please do :) [17:11] https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1205013 [17:11] Launchpad bug 1205013 in Ubuntu Manual Tests "Persistence should be it's own testcase" [Undecided,New] [17:11] also commented on elfy's bug accordingly [17:12] thanks [17:13] balloons: is there anyway to make an alpha run last longer - in the end we got about 3 days :) [17:13] OR is there a way to run a particular snapshot for longer than a day? [17:13] the persistence test will always require usb-creator-gtk if we want to allow the "easy" way - and tbh, that's more like a prerequisite for the testcase rather than part of the test (eg. if there's a bug in usb-creator-gtk it's not really a bug in the testcase) [17:13] elfy, we are able to control that ourselves afaik [17:14] knome, agreed on the usb-creator-gtk [17:15] elfy, yes, I agree with knome, you should be able to fully control how long it runs, when it starts, etc [17:15] i haven't looked deeply enough into the issue to know how though [17:15] stgraber would know O:) [17:15] well, this is still a learning exercise.. so yea, :-) [17:15] balloons, howdy! [17:15] DanChapman, hello! [17:16] fwiw, it's not obvious from the tracker [17:16] fyi http://www.reddit.com/r/IAmA/comments/1j166z/hi_im_mark_shuttleworth_founder_of_ubuntu/ [17:21] knome: oh ok - didn't know that - much like the rest of the tools ;) [17:21] :) [17:22] as I said I looked for the manual :p [17:22] manual for the qa tracker... [17:22] I'll try and catch stgraber and have a chat about it [17:22] just manual would be an excellent start :p [17:23] elfy, knome sadly the manual got wiped on the wiki somehow.. [17:23] * balloons is still grieving [17:24] balloons: I'm not sure I believe there even was one :p [17:24] there was even a section for admins, but again, it's been lost [17:24] ask the IS if they have backups? [17:24] 'it got broke' is a likely excuse lol [17:24] you might even get an answer in less than a month :P [17:25] leave IS alone please - elfy more worried bout the forum :) [17:25] haha you 2 [17:25] finally no forums so elfy has more time for other things! [17:25] well - I wish :) [17:25] we should keep the forums closed;) [17:26] putting knome on ignore ... [17:26] i thought i already was [17:26] ha ha ha [17:27] i'm sure several community members secretly wish they could ignore me [17:27] and some already do ;) [17:31] :p [17:31] there is a team - they asked - I declined :) [17:31] declined what? [17:32] launchpad team we-have-knome-on-ignore? [17:32] elfy, hi. I've finished gThumb testscase and it's more than 200 lines long. Do you think that it could problematic? [17:32] and you were declined to join? [17:32] could be [17:33] slickymaster, you could split it in several tests if there is a sensible way to split... [17:33] elfy, truth is gThumb has a lot of features, menu options and toolbar buttons [17:34] elfy: kind of a small gmb one [17:35] knome, honestly I don't see how, without loosing consistency [17:37] then don't - push it let someone else have a look :) [17:37] knome: I was good enough to say I quite liked talking to you [17:37] elfy, ok, I'll do it tonight, after dinner [17:37] balloons: re: the lost wiki pages, can you not find them on google archive? Whilst a bit of a pain to re-format, it's better than nothing. [17:38] 'bye all. until later [17:39] balloons: re: smoke testing, the only thing I can find is dated 2008 :( https://wiki.ubuntu.com/Testing/ISO/Smoke [17:40] phillw, the basic idea for us nowadays is smoke testing the development release.. that is, installing and running the daily release.. better described as dogfooding I'd suppose :-) [17:40] all the testers who run saucy fulltime are doing this [17:41] do we have a dogfood guide? :;) [17:41] winalot do phillw [17:41] phillw, no it's something I've been lamenting for a little bit [17:41] pedegree chum is a fav in this house [17:42] I run lubuntu 13.10 as my 'production' machine ever since a fight between vBox and KVM killed my 13.04 :D [17:43] So, the page title would be "dogfooding" or "smoke testing" ? [17:45] hmm, elfy knome, maybe we can expand on this page: https://wiki.ubuntu.com/Testing/TestCaseAdmins/ManagementOverview [17:45] that page is a start - I saw that - it answered none of my questions :D [17:46] elfy, it was never intended to :-) But we could use it as a start [17:46] anyways, phillw , efly, knome.. I looked again, no avail.. consider it gone.. which is well enough. We can redo it [17:47] balloons: probably we need to look at making a few linked pages - I'm obviously an ideal candidate to work through what's missing lol [17:47] documenting the qatracker.. from and admin side and a testers side [17:47] I'll add it to my piece of paper that gets longer [17:47] i'll note to some extent it should be selfdocumenting [17:47] :) [17:48] I don't want a giant manual.. no one will read it or maintain it if so [17:58] good evening [17:59] it is here :) hope it is there too [18:02] I have trouble to run ubuntu-docviewer-app autopilot tests, seems it fail to run (_StringException) did I miss something? [18:21] xeranas, evening to you! [18:21] xeranas, so, what's the lp branch, I'll grab it and take a look with you [18:22] balloons: bzr branch lp:ubuntu-docviewer-app [18:22] balloons: I have problem run existing tests [18:23] xeranas, ohh, gotcha [18:24] xeranas, hmmmph.. I get CalledProcessError: Command '['which', '../../ubuntu-docviewer-app']' returned non-zero exit status 1 [18:24] balloons: same [18:24] balloons, what was the wiki page name? [18:24] well, it's not just you then :-) [18:24] knome, https://wiki.ubuntu.com/Testing/TestCaseAdmins/ManagementOverview [18:24] ? [18:25] xeranas, so let's look and see what's up [18:25] balloons, no, the lost manual [18:25] knome, that's the trouble.. I can't remember [18:25] we could try asking xdatap1 if he knows where it's at [18:25] knome, you know Paolo? he might have an idea [18:26] heh, i've even met him in person! [18:27] he helped create the admin side pages.. the tester side stuff was on wiki.ubuntu.com/Testing/QATracker [18:30] balloons: local_location on __init__.py defined as "../../ubuntu-docviewer-app" other test cases targeting *.qml file. and on launch_test_local there no "qmlscene" atribute. However when I tried change those it seems like they fall in infinite-loop. So not sure how it should be [18:32] http://web.archive.org/web/20130603050554/https://wiki.ubuntu.com/Testing/QATracker [18:32] balloons, does that look old enough? ` [18:33] https://wiki.ubuntu.com/Testing/CallforTesting/ and subpages what you looking for? [18:35] balloons: http://webcache.googleusercontent.com/search?q=cache:wiki.ubuntu.com/Testing/QATracker exists? [18:36] knome, phillw has already rezzed the qatracker page from google cache [18:36] the admin stuff though, I've no idea of the url so... [18:36] balloons, did you look at the link i gave you? [18:36] xeranas, yes, the launch code needs tweaked, I agree [18:37] or was it something even more [18:37] knome, yes, your archive link is more or less the page, minus the pics :-) [18:37] it's there again on wiki.ubuntu.com/Testing/QATracker [18:38] xeranas, so the issue with docviewer was/is it has to be launched differently because it needs command line arguments [18:40] I thought I recognised it :) [18:41] xeranas, so I [18:43] xeranas, so I'm playing with how it's launching and it doesn't complain anymore, but it doesn't launch the app :-) I'll keep tryuing [18:46] balloons: yea, here it is tricky part of autopilot [18:48] elopio and I were just talking about this actually [18:50] balloons: hackfest has been added to activities, just awaiting your decision on the title of the dogfooding / smoke testing page :) [18:51] hehe.. dogfooding works fine actually.. perhaps using it will be better since it won't be confusing anything with the other term [18:51] smoke testing is high level see if it blows up style testing.. it can be applied to anything [19:02] xeranas, so, for the moment, might be best to look at something else. We should file a bug stating the tests are broken though [19:05] xeranas, would you like to file it? https://bugs.launchpad.net/ubuntu-docviewer-app/+filebug [19:09] balloons: I'm bad on summary and descriptions writing, sometimes ppl have hard time to understand me [19:11] xeranas, ok, I'll file :-) [19:11] no worries! [19:11] evening dkessel, Letozaf_ [19:12] balloons: ok, thanks [19:13] balloons, evening :) [19:21] good evening balloons :) [19:22] hopefully the netsplit has finished :-) [19:22] pitti, asac, interesting discussion you had about the autopkgtests. i'd be willing to help with getting tests to work again, if that is needed. [19:23] although i too believe the developer teams should get a first chance of fixing the tests ;) [19:24] oh-oh.... bad net split [19:27] Letozaf_, what are you up to this evening? [19:28] balloons, I was running the music app tests so I can write more [19:30] Letozaf_, did you see: https://lists.launchpad.net/ubuntu-touch-coreapps/msg00516.html [19:31] there's been an on-going thread today about the music app [19:34] balloons, yes I saw something pass by, but could not read it, too much e-mails, so I didn't know about it :( I'm reading now [19:34] Letozaf_, :-) [19:35] balloons, victor told me that by email that there is a known issue and is documented in bug #1204711. [19:35] bug 1204711 in Ubuntu Music App "All 3 Autopilot tests fail" [Undecided,New] https://launchpad.net/bugs/1204711 [19:36] balloons, and that was what was happening to me :) [19:36] balloons, oh well! I will have to pick something else meanwhile :p [19:37] Letozaf_, did you have questions on the rss reader? === Ursinha is now known as Ursinha-afk [19:37] the dev is online right now :-) [19:37] balloons, could not branch it , it was not on the rss reader branch [19:38] balloons, if you tell me were to fetch the updated tests I will look at them now [19:38] xeranas, if your still about, hop in #ubuntu-touch-meeting [19:38] balloons, unless the last updates are in the branch now [19:38]