[03:27] <much13> Just grabbed the alpha. How can I tell if I'm using Unity 2D? And where can I toggle it on the login screen?
[04:52] <munch13> Is it a known issue that Software Center's crashing?
=== Guest37602 is now known as jpds
[09:49] <mvo> jibel:  good morning! the upgrade-tester looks really unhappy this monring, it appears that it can not find the rootfs anymore after the upgrade, the UUID is still in grub though. I have not debugged this further yet, so far I saw it on server-lts, I run a local server upgrade now to see if its showing the same
[09:51] <jibel> mvo, I re-ran ubuntu, kubuntu and edubunt which failed and they passed
[09:51] <mvo> jibel: oh, interessting. maybe its fixed already then
[09:52] <jibel> mvo, I tried to run 2 tests in parallel on each server maybe that's it
[09:54] <mvo> could be, but if I would love to figure out why it happens, it should be possible to run them in parallel
[09:54] <jibel> mvo, for server-lts there is really a problem, it doesn't reconnect to the vm after the test
[09:54] <mvo> jibel: right, I think that is what I was seening
[09:55] <jibel> mvo, I re-ran them to make sure they were not broken but I'll do further testing today. I'd love to use more power out of these machines
[09:55] <mvo> yeah, me too
[09:55] <mvo> keep me updated please :)
[09:57] <jibel> mvo, sure :)
[11:06] <jibel> mvo, the problem when 2 upgrade tests starts simultaneously is that they get the same vnc and ssh port
[11:07] <jibel> mvo, we could either introduce a random waiting period at the start of the test, or use some kind of lock mechanism
[11:08] <brendand> mvo - hi
[11:10] <mvo> jibel: oh, ok. that makes sense, I will ponder about it a bit
[11:10] <mvo> brendand: hi
[11:11] <brendand> mvo - i've been trying the test deb files in gdebi, it seems most of them are designed to test error scenarios. are there any in there that install cleanly?
[11:15] <mvo> brendand: I don't think there is, that would be really useful test indeed, this may work with something like fakechroot as a user even
[11:18] <jibel> mvo, k, for the moment I decreased the number of executors to 1 per host.
=== _salem is now known as salem_
[11:20] <brendand> mvo - the fakechroot is for installing the test packages without spoiling the environment, right?
[11:24] <mvo> brendand: yeah, fakeroot and fakechroot are probably usful for a test like this
[11:25]  * brendand thinks DebFileApplication is becoming hard to test :)
[11:28] <brendand> mvo - ok, that's a good tip. thanks
[11:34] <mvo> yw
=== fader_ is now known as fader
=== bladernr_afk is now known as bladernr_
=== yofel_ is now known as yofel
[15:30] <salem_> cr3, hi, just pushed the initial qt4 frontend code to lp:~tiagosh/checkbox/qt4
[15:34] <roadmr> salem_: \o/ thanks!! I'll have a look
[15:35] <salem_> roadmr, ah, there you are, I was trying to remember you nickname :)
[15:35] <roadmr> salem_: heh yes!
[15:35] <munch13> I swear, cheese has worked before on my webcam. Anyone else having libv4l issues in Precise?
[15:36] <salem_> roadmr, it only implements the basic, and probably the ui is not equals the gtk one, but soon I will implement the rest.
[15:37] <munch13> nm, think i found the bug report
[15:39] <stgraber> munch13: what's the bugnumber? I was looking for it yesterday but couldn't find it (I know I saw it in my bugmail a few days ago :))
[15:41] <munch13> stgraber: possibly 359045, but it looks kind of old
[15:42] <stgraber> yeah, I'd have expected something >890000 :)
[15:52] <roadmr> salem_: I sent you a merge request with a couple of tiny changes to that branch
[15:52] <roadmr> salem_: it's looking great so far!
[16:00] <salem_> roadmr, sorry, I was out for lunch
[16:00] <salem_> roadmr, cool.. I thought I had included __init__.py
[16:01] <roadmr> salem_: I didn't see it, but it's easy to add, it may even be faster for you to do the changes manually than merge my branch :)
[16:01] <salem_> roadmr, ah, got it, it is an empty file, so in my diff it was not included.. my bad.
[16:02] <roadmr> salem_: yes, argh, I don't know if it can contain anything, because empty files confuse the hell out of diff
[16:02] <roadmr> salem_: that's also probably what happened with the file mode 755, diff also doesn't handle those very well
[16:02] <salem_> hehe, no problem.. I can add it
[17:10] <charlie-tca> jibel: thanks for marking the bug a dup. Am running the same install on hardware and can not reproduce
[17:12] <jibel> charlie-tca, thanks for reporting it :) this bug is really ugly, it seems to happen essentially on i386 VMs running on amd64 hosts and it is not always reproducible.
[17:12] <charlie-tca> what a great opportunity for someone to excel, then!
[17:14] <rickspencer3> charlie-tca, we're working on it, it's not an easy one, that's for sure
[17:15] <charlie-tca> At least we can still use hardware installations.
[17:16] <charlie-tca> Any other information I can try to get if I can reproduce it, even in VBox?
=== nagappan_ is now known as nagappan
[17:27] <jibel> charlie-tca, no that's fine. We have isolated the code triggering the bug and been able to reproduce it in a controlled environment. now that's up to the kernel team to track that guy.
[17:28] <charlie-tca> jibel: thanks.
[17:28] <jibel> charlie-tca, yw
[18:20] <salem_> roadmr, ping, still there?
[18:22] <alourie|laptop> hello
[19:02] <roadmr> salem_: here, was out having lunch but I'm back, how can I help?
[19:05] <salem_> roadmr, I have some questions regarding checkbox behavior. Everytime I run, it starts gathering some system information and then reboots the whole system, is this expected?
[19:05] <roadmr> salem_: yes :)
[19:05] <roadmr> salem_: let me explain :)
[19:05] <salem_> roadmr, hehe ok
[19:05] <roadmr> salem_: if running from source, it will not use a whitelist unless you specify one explicitly
[19:06] <roadmr> (whitelist = a list of the jobs I actually want to run)
[19:06] <roadmr> salem_: so without a whitelist, it will simply get all the jobs defined in the jobs/ directory, eventually hitting the "bootchart" job which requires rebooting the system to collect bootchart data - this is why it behaves like that
[19:07] <roadmr> salem_: in order to run with the default whitelist as used when the package is installed, run bin/checkbox-qt -W data/whitelists/default.whitelist
[19:07] <roadmr> salem_: when the package is installed, a script is created that automatically does this, that's why you don't see this if you run the installed checkbox-gtk for instance
[19:07] <salem_> roadmr, ahh, now it makes sense :)
[19:08] <roadmr> salem_: yep, there's one more thing that affects behavior here
[19:08] <roadmr> salem_: notice how checkbox-gtk first gathers some system information, then shows a tree list of tests for you to select
[19:09] <roadmr> salem_: checkbox-qt doesn't have that yet, and so after the gathering phase it goes straight into running all the jobs in the whitelist
[19:09] <roadmr> salem_: for the selection list to work, I think the show_tree method has to be implemented in the user interface
[19:10] <salem_> roadmr, yes, I am on my way to add it, but need to figure out a way to do it yet
[19:10] <roadmr> salem_: ok, that's probably one of the more involved methods to implement
[19:12] <salem_> roadmr, ok, cool! thanks for the explanation.
[19:13] <roadmr> salem_: no problem, I'm here to help :)
=== bladernr_ is now known as bladernr_afk
=== bladernr_afk is now known as bladernr_
=== salem_ is now known as _salem