[00:21] hi kot [00:21] hi kotux [00:25] hey phillw, what's the current plan for lubuntu manual? [00:27] hi kotux we seem to have decided upon the version of LaTex to use, Jonathan is going to start populating the bzr branch [00:28] Cool. Where can I find information to start helping? [00:28] kotux: I'm just waiting on Jonathan to publish the install script. [00:30] oh ok [00:33] kotux: JasonO Jonathan is not on-line at the moment, I'll email him. [00:34] Alright [00:36] phillw, has there been any activity around quickshot lately? [00:38] kotux: Thomas is looking into it. I have a python guy possibly available to assist, but have not been asked to get assistance. [02:08] hi i cant hear anything on my username but on others i can [02:08] oops [05:14] Good morning === oleg is now known as Guest17482 [06:51] good morning [08:57] pitti, did you look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711209 in autopkgtest? [08:57] Debian bug 711209 in autopkgtest "autopkgtest: build-needed restriction doesn't actually run tests in built tree" [Normal,Open] [08:58] jibel: no, not yet; but I probably should, it seems my workaround in umockdev only works in run-adt-test, but not in Jenkins for some reason [08:58] pitti, okay, I'll see if I can fix it. [08:59] umockdev's debian/tests/upstream currently has [08:59] # work around broken "build-needed" behaviour (Debian #711209) [08:59] Debian bug 711209 in autopkgtest "autopkgtest: build-needed restriction doesn't actually run tests in built tree" [Normal,Open] http://bugs.debian.org/711209 [08:59] cd $ADTTMP/../../ubtree0-build/real-tree [08:59] that fails in jenkins [09:00] but I was hoping for a clarification what this flag should really mean [09:00] jibel: it seems it conflates two distinct things: building the *tests* for running against the installed system, or building the package and installing the *built debs* to run the tests against [09:15] balloons, ping [09:47] Good morning :-) === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik [12:01] jibel: did you have a chance to look at the logs I left you on IRC? [12:02] regarding otto [12:03] shadeslayer, hey, nope, sorry I didn't see you left logs on IRC. What are they ? [12:03] hmm ... when trying out otto + kubuntu I get : lxc container failed to recieve answer for command [12:03] also : lxc container failed to send command [12:04] it does mount the ISO from what I could tell [12:04] and also made the lxc container [12:04] that was on raring btw [12:05] shadeslayer, ah, that's a generic error and lxc logs nothing when using the API (bug 1181136) . lxc-start -n should be more verbose. [12:05] bug 1181136 in lxc (Ubuntu) "Empty log file when a container is started with the API" [Medium,Confirmed] https://launchpad.net/bugs/1181136 [12:05] okay, lemme try [12:05] basically this message means that the container failed to start :) [12:06] I can see that :P [12:06] I just couldn't figure out why because there was nothing in the log files [12:07] jibel: is there a way to make it not kill my current X session? [12:07] because whenever I ran sudo bin/otto start saucy-otto it killed my host lightdm and X [12:09] shadeslayer, not in the current state because it uses VT7, the same then lightdm. To make it not kill the current session, we'd need to add vt8 and make lightdm start on this VT inside the container. Patches welcome :) [12:09] okay, will have a go at that [12:11] jibel: http://paste.kde.org/772274/ [12:12] pitti, did you already run umockdev testsuite run once successfully with autopkgtest and your workaournd? [12:13] shadeslayer, chroot: failed to run command ‘useradd’: No such file or directory [12:14] there is no useradd command on the livecd ? === _salem is now known as salem_ [12:15] lemme check the manifest [12:15] manifest says : passwd 1:4.1.5.1-1ubuntu4 [12:15] so it should be there [12:15] that's weird, from the trace the squashfs is not mounted [12:16] sounds like a bug [12:16] jibel: yes, as I said it works fine locally; I tried run-adt-test -skPS file://`pwd` umockdev [12:17] * pitti tries "run-adt-test -s umockdev", it's published now [12:17] jibel: nvm, apparmor issue, I forgot to run the apparmor commands there [12:18] + chroot /var/lib/lxc/saucy-otto/rootfs useradd --create-home -s /bin/bash ubuntu [12:18] useradd: user 'ubuntu' already exists [12:18] jibel: new log http://paste.kde.org/772286/ [12:19] lines 81 to 83 [12:23] shadeslayer, for the error lxc-start: Error setting memory.memsw.limit_in_bytes to 2560M you'll need to enable swap resource control or remove this config paramter from lxc.defaults/config [12:23] shadeslayer, swap resource control will guard you against killing your host if something goes wrong with the test [12:24] I have enough memory :P [12:24] to enable it set swapaccount=1 on the kernel boot command line (change it permanently in in /etc/default/grub then run update-grub) [12:24] shadeslayer, okay, I easily killed test machines with 8GB or more [12:24] your pick [12:24] O_O [12:25] 8 GB's? :O [12:27] autopilot run -r -rd /tmp/videos unity [12:27] run it twice and it'll use more than 10GB [12:39] shadeslayer, RELEASE is extracted from the image, I don't understand why it would fail. What's image are you using and what is its checksum? [12:50] jibel: latest kubuntu saucy image [12:50] jibel: got it to work [12:50] kinda [12:51] lightdm starts, it shows the ubuntu user, but I can't input anything via the keyboard [12:55] jibel: df68d11b44b23bbef8ac42af59196105 is the md5sum [12:55] shadeslayer, thanks, I'll try with this image [12:56] * shadeslayer ponders how this will work on EC2 [13:25] stgraber: pign [13:25] ping [13:26] cjohnston: pong [13:27] stgraber: do you know how often the iso tracker updates its list of bugs? [13:27] or, more accuratly, the bug data.. [13:28] cjohnston: every 10 minutes for milestones marked as testing, every hour for milestones marked as released and once a day for disabled/archived milestones [13:28] cool. thanks [13:31] stgraber: is the script gaining anything by being authenticated? [13:32] cjohnston: yes, the script comments on bugs and add tags, so if you use that feature, it needs a valid auth token [13:32] gotcha.. ty again [13:32] (for ISO bugs we add iso-testing and add a comment with a URL back to a tracker page listing all results related to the bug number) [13:33] Interesting.. [13:50] apw: I finally got to install your kernel today, I am not completely convinced the saucy image I have works, but anyway [13:51] apw: do you have any insights on this error: http://paste.ubuntu.com/5761460/ [13:58] gema: tried apt-get -f install? The error says you're missing wireless-crda so running apt-get -f install should install that for you and finish installing the new kernel [13:59] yep, I did [13:59] and i still don't see what apw added on sysfs, so I am not sure what I am missing [13:59] gema, you don't install kernels in the image anyhow do you to use them, you have to abootimg them into the boot partition [13:59] apw: ok, do you have any instructions on how to do that? [14:00] apw: (I rather not break my n4 by doing something silly) === salem_ is now known as _salem === _salem is now known as salem_ [14:09] Hi guys! [14:18] apw: if you don't have time I can get help from ogra on this one [14:22] https://wiki.ubuntu.com/Kernel/Dev/AndroidKernel [14:22] gema, ^^ is hwat i use, the bit about abootimg [14:23] apw: thanks === alesage|afk is now known as alesage [14:37] Guys, a few questions regarding manual tests [14:37] 1. who is going to run the manual tests written by the community? [14:38] 2. I cloned the bar repo on my hard drive, and there are only manual tests for a handful of applications [14:38] ePierre, hello. We as a quality community team run the manual testcases [14:38] for instance, no tests for Gimp for the moment [14:38] we run them normally on a regular basis during the cycle [14:38] does it mean no one as ever written manual tests for Gimp before? [14:38] ok [14:39] ePierre, yes there isn't one for gimp but you could help add one [14:40] but [14:40] there is not one for 13.10? [14:40] or there never were any, even for previous versions? [14:40] check out the bugs list to see all of the needed testcases [14:40] yes, I am checking this page right now :) that's why I pointed out Gimp [14:40] http://bugs.launchpad.net/ubuntu-manual-tests/+bug/1183009 [14:41] Launchpad bug 1183009 in Ubuntu Manual Tests "Test Needed: Gimp" [Undecided,New] [14:41] yes it means nothing exists for gimp -- not just for 13.10. [14:41] oh wah [14:41] but when did you start making this quality process then? [14:42] (no reproaches or anything, I'm just curious) [14:42] and in that case, shouldn't we add the version number in the test case? [14:42] so you can see the repository of tests has grown a lot since earlier this year, but still has needs :-) [14:42] so that someone willing to update the tests would know against what version this test has been written [14:42] ? [14:43] ePierre, you mean a version number of the package in question? [14:43] yes for instance [14:43] cause for instance [14:43] when a package changes the test fails and we update it [14:43] Gimp is not installed by default [14:43] the tracker retains the old testcase and old result [14:44] on ubuntu gimp is not installed by default [14:44] but how do you know what version was used to write and run the test? [14:44] sorry yes, on the original flavour :) [14:44] everything listed on the bugs list is a default application for at least one flavour [14:44] we started by getting tests for all the default ubuntu apps and now are branching out to get the flavors too [14:45] ok I see [14:45] the version that was used to write the test? we always write the first version against ubuntu development [14:45] ok [14:45] but say I commit a test case today [14:45] and it's not updated anymore for 3 months [14:45] and in those 3 months, Gimp sees one or two updates [14:46] I do see point for concern about versioning but it's not been an issue [14:46] ePierre, yes indeed that could happen [14:46] say current version is 2.8.1, and after 3 months it's 2.8.3 [14:46] ok [14:46] right [14:46] and odds are your test won't be broken [14:46] that's why I was proposing to write the version number somewhere in the test case [14:46] ok I see [14:46] if gimp decided to re-write everything then perhaps [14:46] so when people run this test again in three months [14:47] it will still work, but they will be testing a newer version [14:47] if it fails, it's either because there is indeed a bug in Gimp, or there is an issue with the test case itself [14:47] ok I see [14:47] we have had major UI changes on a default app [14:47] so manual test cases are to test pretty simple steps for the moment, right? [14:48] the nautilus testcase had to be updated. however it served us for a couple cycles and the new one is likely to do the same [14:48] once a test is written we endeavor as a team to keep it up to date and add to it if needed [14:48] ePierre, we try and have our manual tests hit the big stuff of the application [14:49] or something that has caused regressions/bugs in the past [14:49] ok [14:49] since Gimp is still test-free, I'll start with the big features [14:50] and how can I know about the most annoying bugs/regressions for Gimp in the past? [14:50] (for Gimp or for anything in general?) [14:51] if you don't know, then you can ask as you are doing, or check the buglist on gimp. i can't remember gimp ever giving us specific regressions or trouble so i think your fine [14:51] basically when we hit a nasty bug during the cycle for gimp we might decide to add it if we think it could occur again and us testing something would prevent it [14:52] this isn't a common thing persay, just something we can do [14:52] as far as developing an initial version of a test you needn't worry about it ;-) [14:52] get the big features in there [14:53] thanks ePierre ! let me know if you need anymore help [14:54] thanks for your clarifications! [14:54] can I assign the Gimp issue to me in launchpad? [14:54] ePierre, yes indeed go for it [14:54] ok [14:54] DanChapman, howdy siir [14:54] how's the new laptop? [14:56] to name the test cases, do I do it myself? like gmp-001 etc.? [14:56] or will it be done automatically? [14:57] ePierre, yes you can number each one inside the file if you wish [14:57] the testcase itself will be given an id automatically [14:58] have you see the wiki guide? [14:58] ok [14:58] yes I'm reading it at the same time [14:58] I knew about the test case ID [14:58] was not sure about inside the test case :) [14:58] thanks! [15:01] balloons, can you put this one on reddit? ;) http://developer.ubuntu.com/2013/06/help-making-the-ubuntu-touch-core-apps-rock-solid/ [15:02] balloons: when writing the test steps, should I write prerequisites too? [15:02] dpm, sure [15:02] like for Gimp, say I want to test opening a big file [15:02] I may want to put an URL to the file for reference [15:04] ePierre, I was speaking of this reference for style guidehttps://wiki.ubuntu.com/QATeam/ContributingTestcases/ManualStyleGuide [15:04] hopefully your questions are addressed there.. if not, I'll expand that page :-) [15:04] ok, I'll have a look, thanks! [15:04] ePierre, what do you mean for prereq's too?. [15:06] hm [15:06] say my test is to make sure Gimp can open an image [15:06] if I just say open an image [15:06] morning chilicuil [15:06] the guy running the test may open a 32x32 pix image, and everything works fine [15:06] but I may open a 50 MB picture [15:06] that may crash Gimp [15:06] in both cases [15:07] we would have followed the same test steps [15:07] yet different result [15:07] if I specify the prerequisite is this 50MB picture [15:07] then everyone will run the same test [15:07] you know what I mean/ [15:07] ? [15:07] ePierre, yes I understand [15:07] ePierre, i'd imagine big images could have their own test [15:08] or am I being too picky here? [15:08] yes, true [15:08] a first test could be to open an image [15:08] and another test would be for instance opening a very big image over the internet [15:08] (cause there is such a feature in Gimpa after all) [15:08] ePierre, you could certainly specify opening a big picture if you wish.. however, part of the community testing of the testcase means that we'll all have slightly different setups [15:09] ok [15:09] ok ok [15:09] :) [15:09] I'l start with more simple tests [15:09] we can always refine them later on [15:10] ePierre, yes indeed.. iterating is the way to go [15:11] knome how are you today? [15:11] feeling better now I hope [15:11] balloons, fine - let me get back to you after our meeting :) [15:31] balloons: I'm going to take this one [15:31] https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1188732 [15:31] Launchpad bug 1188732 in Ubuntu File Manager App "Autopilot Testcase Needed: Test opening a directory" [Undecided,In progress] [15:31] elopio, excellent [15:31] balloons: My first Gimp test is to check I can open an image [15:32] it's called gmp-001 [15:32] elopio, if possible have a look at the emulator I tried to make for these and let me know your thoughts [15:32] in a lot of following tests, I will need to have an image open [15:32] balloons: is it on the filemanager branch? [15:32] Hello everybody ! Is someone here working on a testcase for Ubuntu-Docviwer-App ? [15:32] elopio, lp:~nskaggs/+junk/ubuntusdk_autopilot_emulator [15:32] can I just say, in my gmp-002 test case for instance: Run gmp-001 --> gmp-001 passes. [15:32] balloons: ack. I will. [15:33] and then proceed to the rest of gmp-002 test steps? [15:33] elopio, the full details are here: https://plus.google.com/104307250302998042813/posts/XCaRM6W4Cnx [15:33] ty :-) [15:33] Oranger, hello! [15:33] balloons: Hey ! :) [15:34] Oranger, no one is working on ubuntu doc-viewer atm [15:34] I was just sharing the emulator for these qml tests if your curious to write one.. check out the g+ link I pasted [15:34] balloons: Ok :) Because if someone do, I can help [15:35] balloons: Oh good, yes I will have a look [15:35] ePierre, yes you can say the pre-req is to have run an earlier test [15:35] ePierre, in general the tests are run in order so it's not an issue :-) [15:36] ok [15:36] thanks [15:36] also, if you need a specific image to test with you can check out the example content.. or even have people screenshot there desktop and create one [15:42] balloons: the emulator looks really useful. But how would we share it between projects? [15:42] elopio, well that's an open question. I wanted to have some folks try using it and get feedback on what might be missing and see if it's useful, etc [15:43] atm we've just branched it and put it into the sourcetree of the project using it [15:43] balloons: I'll copy the parts I will use in this test [15:43] and when we have it in a common project, just let me know and I'll update. [15:43] elopio, so if you take a look you can incorporate it into the test setup so it's just a file you can update [15:44] Hey balloons it still hasn't arrived!!! :-( So im trying to do it on an old box I have, but its a bit to old for the job I think :-) will keep battling with it. ANd keep an ear out for that delivery man aswell ;-) [15:44] the question is -- is having a versioned file you can pull to update at any point enough./ [15:44] DanChapman, ohh sorry to hear mate! [15:44] elopio, so for instance nik90 and I added it to ubuntu-clock and he's using it there [15:45] you modify the __init.py__ to include it and through it in the emulators folder along with something like your main_window.py emulator, etc [15:46] I was gonna get my self a thinkpad would have arrived on monday, but thought no i'll get myself a sputnik, regretting it at the moment, hope the wait is worth it [15:46] then all he has to do to get a new version is re-pull the branch [15:46] balloons: yes. I'm on it. It will make things a lot easier than I thought :) [15:48] Oranger, so have you ever tried writing an autopilot test for ubuntu-docviewer? [15:49] I see there is a basic setup for autopilot on your project already.. Care to give it a whirl with me? I'll help :-) [15:49] balloons: No I don't, I didn't have the time for ^^' [15:50] balloons: Yes of course :) [15:50] Oranger, alright.. so looking over the buglist, let's see [15:53] Oranger, can we try something simple like opening a file? https://bugs.launchpad.net/ubuntu-docviewer-app/+bug/1188757 [15:53] Launchpad bug 1188757 in Ubuntu Document Viewer App "Autopilot Testcase Needed: Test opening a text file" [Undecided,New] === mmrazik is now known as mmrazik|afk [15:54] balloons: Yes :) This testcase will change soon because the way docviewer is opening a file is temporary, but for training why not ! [15:55] ok great.. So let me branch the code and see how it works.. then we'll automate it :-) [15:55] well actually I don't think the branch has been updated since my last pull :-0 [15:56] nope :) [15:56] i'm currently working on the update, but it's a big update, that's why nothing was added ^^' [16:04] do you know where can I get this package from? [16:04] qtdeclarative5-nemo-qml-plugins-folderlistmodel [16:05] is it in qtdeclarative5-*? [16:05] qtdeclarative5-folderlistmodel-plugin? [16:06] ok balloons , I have pushed my Gimp tests to my repo, and proposed it to be merged [16:06] it's rev 123 [16:06] ePierre, excellent I'll review in a moment [16:06] Oranger, ok I think I'm all setup [16:06] (I tested the file against the tidying up script and it's clean) [16:06] ePierre, perfect :-) [16:06] it's time for bed here, but I'll keep doing this later [16:07] ePierre, thanks mate! [16:07] balloons: Ok :) [16:07] balloons: I have that one installed. But I get file:///home/elopio/workspace/ubuntu/ubuntu-filemanager-app/trunk/ubuntu-filemanager-app.qml:20 module "org.nemomobile.folderlistmodel" is not installed [16:07] in the meantime, should I just de-assign the bug from me, or should I keep it? [16:07] elfy, see 2 manual tests in already today ;-p [16:07] xubuntu ones? [16:07] ePierre, keep it if you're definitely getting back to it [16:07] :p [16:08] elfy, one xubuntu one [16:08] ok then I'll keep it for the moment [16:08] and the next could be yours [16:08] balloons: cool :) [16:08] my what? [16:08] balloons, btw, give elfy all the permissions he asks for :P [16:08] knome, elfy scares me.. of course he gets what he wants [16:08] lol [16:08] I'm off for tonight. Bye everyone! [16:08] haha:) [16:09] ePierre, night! [16:12] ok Oranger, so how can I open a text file.. do I have to pass it as an argument? [16:13] balloons: For the time being yes ! But you have to pass it as an absolute path [16:13] This is something I have to fix.. [16:14] ohh, that's why it failed :-) Ok [16:15] balloons: Ahah, sorry. I should write it on the README ^^ [16:19] Oranger, odd it doesnt' like me [16:19] I remember using it before [16:19] I'm trying to open the README from the branch using doc-viewer [16:19] somebody knows the Arto Jalkanen's nick on IRC? [16:20] balloons: It should work :) [16:20] mhall119? [16:24] Oranger, qmlscene ubuntu-docviewer-app.qml path/to/file [16:24] balloons: Nop. ubuntu-docviwer-app path/to/file [16:25] ahh :-) [16:25] like every core apps, you don't have to use qmlscene :) [16:25] ok perfect [16:33] Oranger, ok, so I think what we'll do is write a test to open the file, but function out the file open as a common function because we'll need it later [16:34] in addition since we have to use absolute filenames, I'll generate a temp file for us to use [16:34] that way we have the absolute path [16:36] balloons: Sound good :) [16:36] balloons: But we really need to generate a temp file to use absolute path ? [16:37] we could include test data.. but how are we to know where the test is being run from [16:37] we're stuck copying it to /tmp [16:37] well, I'm being silly [16:37] your right [16:42] balloons: Ok :) So, how can we start writing it .? [16:42] Oranger, ok so I've made some small tweaks to your base setup with autopilot [16:43] so we commit those, then share a pad to hack on? [16:43] http://pad.ubuntu.com/VHU5Nu253n [16:44] hello Vasudevan ! [16:45] Hi balloons, good morning [16:45] Oranger, so I'll hack away in here: http://pad.ubuntu.com/VHU5Nu253n [16:45] join in :-) [16:48] hello SergioMeneses [16:48] so Vasudevan how's nautilus treating you? [16:48] no luck yet - I will copy the code to past in a minute [16:48] balloons, hi! how's everything? [16:49] I tried to use a tool called gtkparasite, does not run on saucy [16:50] google code had some patch for it - tried to apply that (both #5 and #6)and still did not work [16:50] Vasudevan, I'm not sure why you need that tool? [16:51] ballons, it is supposed to dump out the props of a gtk child window for quick debugging [16:52] when you click on a widget , it will show its internal id, label, name etc [16:53] ahh.. probably needs accesibility stuff anyway [16:53] you can use the vis tool, but I agree it's cubersome at times [16:53] SergioMeneses, not too bad, yourself/ [16:55] is there a way to inspect with the vis an app running in qmlscene? [16:55] balloons, still working but all fine here :D [16:55] elopio, there is [16:57] ok guys see yoo soon, lunchtime here [16:58] elopio, [16:58] autopilot launch -i Qt qmlscene /path/to/file.qml [16:58] autopilot vis [16:58] thanks balloons. [17:00] Oranger, I'm hacking on the init.py to make setup behave [17:01] balloons: ok :) [17:03] Hi DanChapman [17:07] bah, the only horrible thing about copy paste python [17:07] spaces matter :-( [17:08] BALLONS :P [17:11] balloons: that shows me just a QQuickView, not the whole app tree :( [17:12] mmmm.. not sure what you need that might be missing, but the folks on #ubuntu-autopilot might be able to point you further.. if not, bug filing time [17:12] samgabbay, hello [17:12] broccoli, howdy [17:13] Oranger, bah, this is annoying [17:13] I'm not sure off the top of my head how to get this call to work properly [17:13] balloons: I'm doing some research to find out how to make it work too.. [17:14] the executable isn't working [17:14] the executable ? [17:14] can't we just use qmlscene? [17:14] it won't start ? [17:14] autopilot is throwing up on me [17:15] balloons: Currently not, in a near future yes. Ubuntu-docviewer use a modified qmlscene :/ [17:15] Oranger, yes launch_test_application fails [17:16] balloons: With qmlscene, it will not work, that's sure [17:17] balloons: This is the ubuntu-docviewer-app binary that send the file to open to qml [17:20] right but autopilot can't find it [17:20] it's not there [17:21] in the root folder of the branch, what's providing the binary? [17:21] you see I'm just passing ubuntu-docviewer-app as the app to start and it fails [17:22] balloons: Yes I see it [17:23] balloons: Hum.. You compiled by "hand" ? [17:28] Hey Vasudevan :-) [17:29] Oranger, what do you mean by hand? [17:30] I'll push the whole branch :-) [17:30] balloons: my suggestion for the sdk emulator is to make it an abstract parent for the real view emulators [17:30]