[00:01] balloons: ok merge requests done for FF and TB [00:03] balloons: also ManualStyleGuide is immutable :( [01:04] komputes, ohh really? you can't edit? you sure your logged in? [01:21] balloons: sorry to say, but I took my eye off the bug, and it is now again a problem for us human testers... bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674 [01:21] Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] [01:46] yes, I ran into that one as well [01:49] fenrw: I can only apologise, I thought it had been sorted. I do try to keep up with the VM issues:'( [01:50] :-( [01:51] phillw: it was the first test I ran, I thought it was a problem with the VM at first (ran from testdrive/kvm) I ran it on aquemu next and it was fine [01:52] balloons: with that many confirming it, I mistakenly thought it was .... "Yeah, they will get it fixed". I lost out. [01:53] balloons: of course, I could always ask as to why our canonical type person never followed the bug to completion :P [01:56] fenrw: I do seem to have become the guy to push VM bugs, But in all honesty, I cannot keep with them all, I do follow those that affect me and any of the testers who nag me. [02:01] what is the best course to take when running a test and you hit a bug like that? [02:02] phillw: === Ursinha is now known as Ursinha-afk [02:07] fenrw: nag me and balloons :D [02:09] fenrw: the -release team do cut me a lot of slack (i.e., they do allow me to nag them over such things) [02:11] phillw: okay, I will test again tomorrow ;-) [02:12] with VBox 4.2 arriving, and test drive hopefully being able to use it. With the KVM issue I am kept caught sort of busy. But, that is not a real complaint. I just want you guys to have the testing tools that you prefer. [02:13] well it's good to test on multiple VMs as that shows [02:14] I'm a KVM person, but I do appreciate that others prefer such as VBox. [02:16] fenrw, with any bug you find, it's best to keep up with it.. report and ensure the folks responsible have what;s needed to fix i [02:16] then just follow up over time and when the fix is ready, help confirm it [02:16] With Vbox 4.2 arriving, I have the 'fun' of teaching people about LVM's. http://en.wikipedia.org/wiki/Logical_volume_management [02:18] balloons: once Vbox 4.2 arrives fully and test drive supports it. I do think we need to tell people about LVMs [02:18] I marked that it affects me, i'll continue to watch it [02:22] phillw: how will LVM affect things? [02:22] SergioMeneses it seems the ubiquity bug has been sorted, but we have a regression in KVM. Please try in Vbox [02:23] phillw, I'm downloading it [02:24] fenrw: instead of having to reboot each time you make a new extended partition area, you can make an new area without needing to re-boot. [02:25] balloons: sorry, i wasn't logged in, thx [02:25] komputes, :-) [02:26] LVM and KVM are very closely tied together in how they work. They also run as the system that makes cloud computing possible. [02:28] fenrw: They are parts of the kernel, that being the low level part of linux. that makes a computer work. Both KVM and LVM are 'in the system', they just need turning on. [02:28] hey komputes ! [02:28] balloons, \o [02:28] LVM and KVM are not related at all. [02:29] hm, I don't know much technically behind KVM, Vbox, etc. Mostly have experience with VMWare [02:29] LVM - does disk management, such that you can treat multiple block devices as a pool of available space and allocate slices. [02:29] ola SergioMeneses [02:30] xnox: LVM is built into the linux kernel? [02:30] komputes, hola! hablas español? [02:30] KVM - does virtualisation aka faking enough for a different linux kernel to believe it's booting on a real system. [02:30] SergioMeneses: um poco [02:30] xnox: KVM is buily into the linus kernel? [02:30] LVM sounds like a feature for multiple VMs on a single host utilizing a SAN [02:30] phillw: it's a kernel module, but so is btrfs and a module for your webcam. [02:31] SergioMeneses: so I got started on my own branch and made some changed to FF and TB [02:31] fenrw: My main machine is installed on lvm, cause it allows me to make snapshots and use snapshot as scratch throw away space for packaging building. [02:31] xnox: so, as I said that they are built in, where was I wrong? [02:32] LVM and KVM are no tied together at all. as they are complete different sub-systems / features. [02:32] s/no/not/ [02:32] xnox: I did not say that, i said that they work together? [02:33] komputes, mmmm [02:33] " LVM and KVM are very closely tied together in how they work" [02:33] lvm is implemented on windows, sun, mac osx etc. it's quite a generic concept https://en.wikipedia.org/wiki/Logical_volume_management [02:34] komputes, pm [02:34] see you there [02:34] kvm is one way to do virtualisation, xen virtualbox vmware are different ways to achieve virtualisation [02:34] xnox: yes, they are both available in the kernel and need no tweaking of the kernel to have them function? I was not trying to split hairs :D [02:35] they require some kernelspace modules, but they are mostly user-space utilities. [02:35] xen is an overlay, now out dated. It uses an overlay to access the kvm area. [02:35] just by having a linux kernel - without lvm2 command-line binary you will not be able to do anything with lvm volumes. [02:36] xen is rapidly developed and has features that are not available in kvm. [02:36] and hardly can be called an overlay. [02:37] xnox: xen is not built into the kernel. [02:37] sure it is. [02:37] one needs xen kernel modules for dom0 support [02:38] where is smartboy? [02:39] xnox: http://blog.codemonkey.ws/2008/05/truth-about-kvm-and-xen.html [02:40] I'm not wanting an argument, just what is current for new-commers === Ursinha-afk is now known as Ursinha [02:44] phillw: two years later xen dom0 support got merged as part of 2.6.37 and 2.6.39 kernels. phillw, 5 years is a long time. [02:45] compare raring with hardy [02:45] 3.5 now... [02:45] xnox: I do want an argument! [02:46] *DO NOT* [02:46] the job's I see, ask for KVM. [02:48] somewhere in here, LVM and xen got interchanged and can't tell who or for what :) [02:52] fenrw: join the club... LVM is a system that is more easy to use than extended partitions. I've had to hold off as I was awaiting VBox 4.2 to arrive and test drive be able to use it. [02:54] testdrive is pretty nifty, does it delete the VM when you close it? [02:54] I don't see a way to load an existing VM from it, so I am assuming so [02:57] I need to read the config file again :) [02:57] it gets a bit complicated. If you have extended partitions you can make a new one and do a live boot (real machine). Using areas with the virtual machines you can allocate an area on the hard drive similar to Wubi [02:58] The reason of using a section of hard disk (LVM) is that it will remain after a fail. [03:00] as xnox has had to really talk me through getting a log from my KVM system, in words of on syalble. He's best at saying if it can be done from VBox and from having a system that is not LVM per machine. [03:03] hmmm, lost me on that last part [03:04] it is 03:00 here , the questions and comments here tonight to need addressing so we can better let new testers know what is best helpful for getting results from a failed install. [03:05] phillw, it works! :) using Vbox [03:06] fenrw: I'll book some time with xnox, who is far more experienced than I am. If he can explain it to me, I can then write it up so anyone can understand it :) [03:07] SergioMeneses that's great, just means we have a regression on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674 [03:07] Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] [03:07] One step forward, one step back :D [03:08] phillw, I think so xD [03:08] I haven't gotten testdrive and vbox to work yet [03:08] btw we have the same bug about the slides :S [03:09] fenrw: have a chat with SergioMeneses, he is best placed to help you with VBox [03:10] I might give it a try loading without testdrive and make sure it works that way first [03:10] or, not make sure, but see [03:12] fenrw, I use testdrive to get the isos, then I open Vbox and choose the iso ~/cache/testdrive/iso [03:12] but you can use both, it is not a big deal :) [03:13] I tried that, I'm getting an error about pae both ways [03:13] phillw, lubuntu installer has not background [03:13] fenrw, which error? [03:13] kernal requires the following features not present on the CPU: pae [03:14] unable to boot - please use a kernal appropriate for your CPU [03:15] fenrw, here is the solution http://askubuntu.com/questions/164764/virtual-pc-error-unable-to-boot-please-use-a-kernel-appropriate-for-your-cpu [03:16] or this one http://www.linuxliveusb.com/en/help/faq/virtualization/154-unable-to-boot-please-use-a-kernel-appropriate-for-your-cpu [03:16] $ arch [03:16] i686 [03:16] installing raring-desktop-i386.iso [03:16] which works on aqemu [03:16] I'll take a look at those [03:17] balloons, phillw busy? [03:17] fenrw, :) [03:17] SergioMeneses, bedtime for moi [03:17] balloons, ok.. dont worry [03:18] balloons, we have the new testcase for thunderbird now :D [03:19] SergioMeneses, yay! [03:19] https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1115645 [03:19] Launchpad bug 1115645 in Ubuntu Manual Tests "Test Needed: Thunderbird" [Medium,In progress] [03:19] SergioMenenses, It looks like the second one might help, I've ran into the first one as well when i tried to install the AMD64 version.. to be honest not sure why my arch says i686 when it's an AMD x2 64bit [03:19] you can check it tomorrow :D [03:19] yea, i have several things to merge looks like [03:19] very good work [03:19] fenrw, dont worry, take your time :D [03:19] balloons, and thanks to komputes for his help :) [03:20] Glad to help. [03:21] thanks SergioMeneses, clicking that checkbox fixed it :) [03:22] fenrw, jejeje nice [03:26] I booted the raring-desktop-i386 vbox to a live disk and got a system program problem detected [03:30] fenrw, ? [03:30] balloons: I'll try to look out for the test naming convention next time [03:30] looks like colord-sane crashed [03:37] I wonder if it has to do with the 32-bit/16-bit color warnings vbox was giving me earlier [03:39] fenrw, mmmm... sounds rare, I dont have any issue like that [03:39] phillw, ? ↑↑↑↑ [03:44] I'm having a hard time clicking on the bottom bug here: http://packages.qa.ubuntu.com/qatracker/milestones/256/builds/37168/testcases [03:45] the one that links to 1127331 [03:45] Anyone else can reproduce? [03:49] * SergioMeneses can not find his yubikey [03:51] komputes, same for me :( https://launchpad.net/ubuntu-qa-website/+filebug Although there is an existing bug with the rollover pop-ups already (they cutoff). might want to link them [03:52] balloons, is it broken? [03:52] it doesnt work for me [03:56] balloons: https://bugs.launchpad.net/ubuntu-qa-website/+bug/1035503 ? [03:56] Launchpad bug 1035503 in Ubuntu QA Website "Bug description yellow boxes exceed browser window dimensions." [Low,Confirmed] [03:56] komputes, yes that's the one [03:56] komputes, ++ [03:56] k, I'm really really off now.. had to post to g+ :-_) [03:56] g-night [03:57] balloons, good night! [03:58] night SergioMeneses [03:58] night balloons [03:59] komputes, \o [04:27] I only get the error when booting with vbox to a live session (I haven't tried a full install yet in vbox) [04:28] (colord-sane crashed) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [04:42] fenrw, which iso are you testing? [04:42] ubuntu-daily? [04:42] Sergiomeneses raring-desktop-i386 [04:42] yeah [04:42] ubuntu [04:46] fenrw, look all bugs for live-session http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/38045/testcases/1303/results [04:47] check if your error is there [04:50] ok guys! bed time... see you later [06:26] Good morning [06:37] evening pitti [07:07] jibel: do you have an idea why inotify doesn't work in the jhbuild container? [07:07] jibel: e. g. tail -f always shows that error, and turns out that it's also the very likely cause for the e-d-s failure [07:20] jibel: confirmed [07:20] jibel: googling does show some hits with "too many open files" if there are many containers, but this only runs a handful [07:51] pitti, good morning [07:51] pitti, correct, max_users_instance is set to 128, I'll increase to 512 [07:54] pitti, can you retry the test [08:03] bonjour jibel [08:04] jibel: ah, I was going to ask you to try that, thanks [08:04] trying [08:04] \o/ [08:04] both tail and evolution-source-registry are happy again [08:05] Yay! [08:05] merci === Ursinha is now known as Ursinha-afk [08:09] jibel: that was the sysctl on the rabisu host, not within the container, right? [08:09] pitti, right, on the host. [08:10] I added the change to sysctl.d/60-custom.conf to preserve the setting on reboot [08:19] jibel: for webkit, could that be "webkit" vs. "WebKit" confusino somewhere? [08:20] hi, that's me again ;) [08:20] anyone good at autopilot? i am having some basic configuration issues, i think [08:20] jibel: (currently doing a manual jhbuild buildone webkit to see whether it's actually failing) [08:20] pitti, that'd be surprising becuase we use the names returned by jhbuild, so they should be consistent [08:21] gosh, this is an unholy fast machine [08:21] it compiles faster that it can scroll through byobu/ssh [08:25] $ jhbuild run pkg-config --modversion webkitgtk-3.0 [08:25] 1.11.5 [08:25] jibel: ^ ok, so it does build on the machine at least \o/ [08:26] jibel: I'll see whether I can reproduce that in automatic mode [08:28] jibel: so jenkins pulls current status/results from rabisu every 10 minutes, right? [08:28] pitti, 2 minutes [08:29] hm, https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/ looks like 10 [08:29] I usually get the "latest builds" in batches with roughtly the same time, around :02, :11, :12, etc. [08:29] ah, let me check that [08:30] jibel: no worries, it's fine; I just want to understand how that works, i. e. jenkins regularly gets a file from rabisu? [08:30] url check schedule: */2 * * * * [08:31] but there is the publisher in-between so maybe that adds a delay [08:31] ah [08:32] pitti, so every 2 min, jenkins checks if a *.revno file has changed and start a new job if it did [08:32] those in /var/log/jenkins/ [08:32] pitti, this job checks *.state files for the result and stops when it's pass/fail or unstable [08:32] pitti, /var/log/jhbuild/ [08:32] err, /var/log/jhbuild of course [08:33] pitti, and collect the log file on completion [08:33] I did it this way because of the very restricted policy between the lab and the rest of the work [08:34] jibel: how does it determine "changed"? [08:34] world [08:34] mtime since last call? [08:34] pitti, it checks the content which is the revision number of the module + a timestamp [08:35] jibel: ah, so if that's later than $last_run, it considers it as "has a new build"? [08:35] pitti, initially I used only the state file, and I think I should go back to only use it [08:37] pitti, if that's later than $last_run, it will start a job, and finish immediately with the result of $last_run [08:38] pitti, it's really hackish [08:40] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-baobab/100/artifact/baobab.log [08:40] meh, I wonder if we should run with --distclean and install ccache [08:40] I've seen issues like that a lot [08:41] * pitti wonders whether -C/--try-checkout also cleans the source tree, checking [08:41] ok, jhbuild doesn't call git clean-tree anywhere [08:42] argh, my bad, it's "clean", not "clean-tree" [08:47] jibel: so it seems we already call jhbuild with -C [08:53] pitti, yes, but I think this option should completely wipe the source tree [08:53] right, it should [08:53] jibel: ignore me for now, I think that might be an actual regression [08:53] I'm doing a local build and investiage [08:53] hah, it is [08:54] * pitti heads bugzillawards [08:56] hm, force_checkout already calls self._wipedir(buildscript, self.srcdir) [08:56] jibel: yes, doesn't help [08:56] could anyone help with autopilot? ^__^ [08:56] jibel: the error occurs on a fresh checkout, it's an actual bug [08:56] ok [08:57] * pitti ^5s jibel [08:58] * jibel ^5s pitti back [08:59] havryliuk, usually autopilot gurus hang out in this channel later in the day, like middle of the afternoon (european time) [09:00] jibel, i see, thanks, will chase them later ;) [09:10] jibel: I pushed the fix into baobab, now waiting for jhbuild to finish :) [09:12] awesome :) [09:12] meh, it keeps resetting my changed checksums in jhbuild.modules without actually rebuilding === yofel_ is now known as yofel [10:36] jibel: could you help me understand some mechanics here? [10:37] jibel: so I pushed that baobab commit (593bd4), and jhbuild-data/jhbuild.modules now has that [10:37] but /var/log/jhbuild/baobab.* still has the old revision [10:38] jibel: that means that jhbuild is past the "checkout" stage, but didn't get round to building it yet, right? [10:38] (gnome/checkout/baobab/ is also current, i. e. at 593bd) [10:38] pitti, correct, old version was jhbuild.modules.bak:baobab (2d89dd812410e8fa03fd98076707917cc7c835ea) [10:38] *nod* [10:38] pitti, new version is jhbuild.modules:baobab (593bd4016a3bfa5f46804eaea7b9f91c72ac3b38) [10:39] and it is still in the queue jhbuild.updates:baobab (593bd4016a3bfa5f46804eaea7b9f91c72ac3b38) [10:39] jibel: oh, thanks for pointing out ~/jhbuild-data/jhbuild.updates [10:39] that's useful [10:40] so folks is in there, too [10:40] webkit is still acting up, though [10:40] ok, I'll let that batch build, and try to reproduce some other failures [10:41] pitti, so it has detected the update but there are lot of packages queued [10:41] jibel: ok, what I thought; thanks for confirming [10:41] parallel builds will help with that [10:42] pitti, BTW +1 for ccache, go ahead if you want to install it, or I'll do it later today [10:43] jibel: doing now [10:46] jibel: what do you prefer, adding PATH definition to .bashrc or jhbuild.cron? [10:46] I think jhbuild.cron is better, then we won't forget to set it up [10:46] pitti, I don't mind, do what you prefer [10:52] jibel: https://code.launchpad.net/~pitti/charms/raring/jhbuild/ccache/+merge/150010, I locally updated jhbuild.cron, too [10:55] pitti, thanks [10:55] jibel: nice, fixing inotify fixed more failing tests (polkit, realmd) [10:59] pitti, nice catch on this one :) [11:09] jibel: btw, that branch doesn't yet have your sysdeps cleanups, right? [11:10] jibel: we need to install the "check" package in manual sysdeps (gdm needs it), want an MP from me? [11:14] pitti, no I haven't updated it yet, no need for an MP unless there is lot more. I added to the list of packages to update [11:14] jibel: merci [12:31] people, has anyone arrived that could help with autopilot? c: === yofel_ is now known as yofel [13:42] jibel: tail: inotify cannot be used, reverting to polling: Too many open files [13:42] argh, that again! [13:42] jibel: it's like something is leaking inotify usage, or could it be that the other runnign containers are suddenly using more? [13:42] jibel: can we bump this to 5000 or so? [13:43] pitti, I'll bump it significantly and we'll search what's leaking inotify [13:43] jibel: oh, https://code.launchpad.net/~pitti/charms/quantal/jhbuild/jhbuild_from_git/+merge/130365 -> that should go to /raring now, presumably? [13:44] pitti, I merged it into raring [13:44] ah great, thanks [13:44] max_user_instances bumped to 8000 [13:44] jibel: branch set to "merged" [13:45] jibel: ok, I guess that needs the container to restart [13:45] I'm shutting down all the other containers [13:46] pitti, ah, there might be another limit for the user [13:48] pitti, I disabled cron and will restart the container after the current run [13:49] jibel: ah, or that; I was going to wait until ibus finished install, and then kill it and reboot [13:50] well, there's some 20 more modules to go, let's let it finish [13:52] that's fine too [13:53] pitti, just tell me before rebooting i'd like to find the culprit [13:53] jibel: do you know a way to shop all open inotify handles? [13:57] pitti, I think that without something like auditd it's impossible, there is nothing reported by lsof the uses so many handles [13:57] yeah, I was already checking that [14:09] ah, figured out totem-pl-parser failure [14:11] jibel: building third-last module [14:11] jibel: we are missing libquvi-dev, but that ought to come in through sysdeps; I modified the upstream totem-pl-parser bug accordingly (should be fixed in jhbuild) [14:12] I think far [14:12] Oops, typp [14:13] I think Raring will be the first development release that has never broken for me [14:13] really, never? [14:13] wow [14:14] Indwed [14:14] Indeed * [14:14] Autopkgtest have made a difference [14:14] Has* [14:15] vibhav, that's awesome:) [14:15] Awesome indeed [14:15] 2013-02-22 14:15:01 : jhbuild.cron Ended [14:15] jibel: want to do something before rebooting? [14:15] eek, it's running again, /me kills [14:16] jibel: now nothing is running on the box except getty, sshd, and udevd, and inotify is still broken; so I guess that does need a reboot to pick up the changed sysctl [14:17] pitti, reboot the host you mean? [14:17] jibel: no, reboot the container [14:17] pitti, ok, no problem [14:18] jibel: you asked me to tell you before I reboot the container [14:18] pitti, right, and there's no problem you can reboot :) [14:20] jibel: oh, neither WebKit nor realmd are in jhbuild-data/jhbuild.modules [14:20] jibel: that might have something to do with our problems? [14:21] pitti, did you restart the container ? [14:21] jibel: yes [14:21] tail: inotify cannot be used, reverting to polling: Too many open files [14:21] eek [14:21] :/ [14:21] WTH [14:21] jibel: so maybe we need to restart rabisu [14:21] pitti, I'm tempted to restart the host [14:23] jibel: 7 minutes until cron kicks in again :) [14:41] jibel: thanks for rebooting; inotify seems happy again at least [14:42] oh, rebooting again apparently [14:42] pitti, forgot something before previous boot, sorry [14:42] np [14:42] pitti, I didn't think you'd login so promptly [14:42] oh, it was uptime 7 mins, I just thought I check whether it's already rebooted; no harm done [14:43] pitti, so that'd mean inotify leak is on the host [14:43] jibel: or perhaps in one of the other containers? [14:44] they were all down [14:44] could be an issue with lxc though [14:45] stgraber, have you ever heard of inotify handles leak with LXC? [14:46] stgraber, I mean you set inotify watch on the guest and they are not freed properly [14:47] pitti, this time it's really up [14:47] thanks [14:48] jibel: nope but I've seen quite a few machines running out of inotify handles so it wouldn't be completely surprising [14:48] stgraber, do you know a way to track that apart from setting an audit trail on the whole filesystem? [14:49] jibel: so I'm still puzzled why WebKit and realmd don't appear in ~/jhbuild-data/jhbuild.modules, but that sounds like a problem for Monday [14:51] pitti, I don't understand [14:51] $ jhbuild list | grep WebKit [14:51] WebKit [14:51] it should be there, the python script does nothing else than this [14:52] I suspect a bug in my code :) === _salem is now known as salem_ === Ursinha-afk is now known as Ursinha [15:05] jibel: ugh @ jhbuild-data/jhbuild.updates, seems it wants to rebuild the world again === Ursinha_ is now known as Ursinha [15:10] jibel: ah, but realmd isn't in jhbuild list either, maybe it just fell out of the dependency chain [15:10] jibel: so we'd need to clean up the jenkins job? [15:10] jibel: yep, got removed on November 22 [15:11] pitti, ok, I'll add an auto-clean, but removal on the public instance will be manual [15:29] pitti, afternoon to you [15:29] hey balloons, how are you? [15:29] Hey balloons [15:29] I'm pointed out umockdev to some of our autopilot test writers. One is trying to use it to simulate a camera plug/unplug [15:30] having some issues however, so I thought I'd ping you [15:30] sadly she's around after your EOD normally [15:30] hey smartboyhw ! [15:31] balloons, I think I should go and merge plars's Nexus7 testcase.... But now we need the Ubuntu Touch ones:P [15:31] smartboyhw, yes I'm trying to merge all the goodies coming on [15:31] balloons, LOL [15:31] for plars, I have to make the new testcase on the tracker too, since it's new [15:32] balloons: yeah, I see the scrollback every morning.. [15:32] balloons, add oil [15:32] balloons: maybe email works better; I need to leave in some 15 minutes, too [15:32] pitti, :-) Great, so any thoughts? I can re-summarize. Yes, I figured email questions would serve you best [15:33] smartboyhw, balloons: yeah, would be nice to get them in asap, but please make sure they look sane. I'm waiting to get my nexus7 back so I had to work from memory [15:33] plars, OK:) [15:33] balloons, you do merge or I do it? [15:33] but we're trying to write a shotwell ap test -- you think umockdev would be a good fit to help? [15:33] jibel: question, why does /var/log/jhbuild/gnome-shell-extensions.state say "running"? it's not running AFAICS, and the log on https://jenkins.qa.ubuntu.com/job/jhbuild-amd64-gnome-shell-extensions/195/? is complete [15:33] smartboyhw: on the subject of ubuntu touch tests - yes, those should be coming pretty soon. I don't think we have daily builds out there yet, so once we do those will become important. [15:33] plars, yes, :-) smartboyhw go ahead and do the merge. I'll do the tracker pieces and merge it to that [15:33] balloons: "ap" == "app" or "access point"? [15:33] ap= autopilot [15:34] balloons: it can record and simulate PtP cameras quite fine, yeah [15:34] balloons: I noticed she tried with the mtp tools, that's most likely not going to work [15:34] most cameras only speak PtP [15:34] so you need "gphoto2", or better, trace shotwell when it's talking to an actual camera [15:34] ok.. i was thinking about justnot using mtp.. [15:34] it was having trouble [15:35] so just umockdev record ptp operations instead then? [15:36] balloons: yes; best with the application that you actually want to test (it's mostly record & replay) [15:36] balloons: should work with the gphoto2 tool as well, if you record enough operations (such as retrieving files, etc.) [15:37] but probably easiest to umockdev-record ... shotwell [15:37] pitti, ok, hmm.. I may have to get my feet wet [15:37] ohh nice.. [15:37] so literally record shotwell's behavoir [15:38] cool, we'll have to give those things a try and let you know [15:38] pitti, weird, looking at the logs I don't see the reason [15:38] jibel: I guess the "running" state makes it appear as red, but that's probably just a followup issue [15:40] balloons, after you put it in change Bug 1127287 to Fix Committed:) [15:40] bug 1127287 in Ubuntu Manual Tests trunk "Testcase needed: Ubuntu Nexus 7 image installation" [Wishlist,In progress] https://launchpad.net/bugs/1127287 [15:40] plars, the merge is in [15:41] good bye everyone, have a nice weekend! [15:42] * balloons waves to pitti [15:42] smartboyhw, plars adding them now [15:43] balloons, :) [15:44] balloons, I like that conversion script:P [15:46] ohh plars btw, https://wiki.ubuntu.com/QATeam/ContributingTestcases/ManualStyleGuide [15:47] pitti, the test was running, jenkins failed to fetch the state file when the container went down. So the check exited with a non-zero exit code [15:47] pitti, and have a nice week end [15:51]