| === chihchun is now known as chihchun_afk | ||
| === philipballew is now known as philip | ||
| BullFrog13x4 | exit | 05:38 |
|---|---|---|
| jibel | Good morning | 06:13 |
| === chihchun_afk is now known as chihchun | ||
| jibel | pitti, unattended-upgrades and ubunut-release-upgrader autopkgtests failed with a permission denied. It could be a change in autopkgtest 2.5, did you have a look? | 06:19 |
| pitti | jibel: not yet, but I will | 06:19 |
| pitti | still digging through morning IRC/email | 06:19 |
| pitti | jibel: oh, just saw that you became a member, congratulations! well deserved | 06:21 |
| jibel | pitti, Yay, thanks for your support :) | 06:22 |
| pitti | jibel: no immediate idea, I'll reproduce locally and investigate | 06:25 |
| jibel | pitti, that's a change in 2.5, -build directory is own by root instead of the test user | 06:49 |
| jibel | for exmaple | 06:49 |
| jibel | adtlog.2.4.log:143092 8 -rw-r--r-- 1 ubuntu ubuntu 4401 Sep 9 17:39 /tmp/adt-run.N9WStu/ubtree0-build/real-tree/test/.coverage | 06:49 |
| ubot5 | Ubuntu bug 4401 in wing (Ubuntu) "wing: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4401 | 06:49 |
| jibel | adtlog.2.5.log:144002 8 -rw-r--r-- 1 root root 4401 Sep 9 17:39 /tmp/adt-run.qDeeZc/ubtree0-build/real-tree/test/.coverage | 06:49 |
| pitti | jibel: right, will track down | 06:54 |
| === chihchun is now known as chihchun_afk | ||
| DanChapman | good morning ! :-) | 07:46 |
| elfy | morning DanChapman | 07:46 |
| DanChapman | howdy elfy o/ | 07:46 |
| jibel | DanChapman, good morning | 08:06 |
| DanChapman | jibel, good morning :-) | 08:06 |
| DanChapman | how are you? | 08:07 |
| jibel | DanChapman, re. ubiquity crash, I filed bug 1254996 which contains a better crash file but retracing will probably fail | 08:07 |
| ubot5 | bug 1254996 in autopilot (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Critical,Confirmed] https://launchpad.net/bugs/1254996 | 08:07 |
| jibel | DanChapman, I'm fine, how are you | 08:07 |
| jibel | ? | 08:07 |
| jibel | DanChapman, I'll generate another crash file with latest updates applied | 08:07 |
| DanChapman | jibel, i'm good thanks :-) awesome thanks, I was struggling to get any logs yesterday. So it turns out its an autopilot bug? should autopilot-gtk be linked to that bug aswell? | 08:18 |
| jibel | DanChapman, autopilot or a change in gtk, there has been an upload 4 days ago | 08:20 |
| === iahmad is now known as iahmad|afk | ||
| jibel | DanChapman, ah it's fine, we have a good trace | 08:21 |
| jibel | DanChapman, to generate a crash file on a system from CLI when Desktop is not responding for example, you can run apport-cli <path_to_crash> ;type (V)iew then (K)eep and copy the crash file to another system. Finally from this other system run ubuntu-bug <path to crash> | 08:25 |
| === chihchun_afk is now known as chihchun | ||
| pitti | jibel: dbus-test-runner: same problem (before you check) | 08:52 |
| pitti | jibel: still investigating; tricky bug, I didn't actually change any chown or copy steps, that must have been another unobvious side effect | 08:53 |
| DanChapman | jibel, ahh I see I was trying to (S)end it instead. I'll remember that thanks :-) | 08:55 |
| === iahmad|afk is now known as iahmad | ||
| pitti | jibel: ah, got it; the bug was there all the time, just shadowed in the case of how we call adt-run; yay AutoFile magic.. | 09:43 |
| jibel | pitti, what is it? | 09:43 |
| pitti | jibel: it didn't chown the test tree when copying down when using --user | 09:44 |
| pitti | jibel: that happens to work with the null runner and AutoFile, as that remembered it already copied down the tree | 09:44 |
| pitti | but it would have never worked with schroot/lxc runners | 09:44 |
| jibel | pitti, nice catch. Good thing you removed the magic :) | 09:46 |
| pitti | jibel: 2.5.1 uploaded to sid and trusty | 09:47 |
| pitti | I'll retry the tests once it's published in proposed | 09:47 |
| jibel | pitti, thanks | 09:47 |
| pitti | (it also has a test now) | 09:47 |
| jibel | pitti, do you think you'd have time to look at bug 1254996 | 09:48 |
| jibel | ? | 09:48 |
| ubot5 | bug 1254996 in autopilot (Ubuntu) "ubiquity crashed with SIGSEGV in GtkNode::MatchStringProperty()" [Critical,Confirmed] https://launchpad.net/bugs/1254996 | 09:48 |
| pitti | jibel: will do | 09:49 |
| pitti | jibel: oh, run-ubiquity-test does everything necessary to boot the iso in KVM etc.? | 10:16 |
| jibel | pitti, it does | 10:16 |
| jibel | you just need an iso and it'll run the default english installation | 10:16 |
| pitti | jibel: can I run this inside KVM, to be able to test with a fixed libautopilot-gtk? | 10:16 |
| jibel | pitti, I didn't try that | 10:17 |
| pitti | jibel: ok, let me look at the trace first | 10:17 |
| jibel | pitti, but you could hack autopilot/ubiquity-autopilot-runner/custom-installation/iso-override/usr/local/bin/run-autopilot.sh to install it | 10:18 |
| jibel | and put deb somewhere in the custom-installation directory | 10:19 |
| jibel | custom-installation/iso-override even | 10:20 |
| pitti | jibel: is the entire iso-override/ copied to the VM? | 10:20 |
| jibel | pitti, yes | 10:20 |
| pitti | jibel: then I could just put the .so in the right place | 10:20 |
| jibel | pitti, exactly | 10:20 |
| pitti | jibel: is that copied after installing autopilot and friends? | 10:20 |
| jibel | pitti, ah no, autopilot would be installed afterwards | 10:20 |
| jibel | and overwrite it | 10:20 |
| pitti | ok, .deb then | 10:20 |
| jibel | or copy the .so somewhere in the override and in run-autopilot copy it over the version installed by autopilot | 10:21 |
| pitti | (this=0x37e9218, name=..., value=...) | 10:21 |
| pitti | thanks gdb for precisely showing me what I actually want to know! | 10:21 |
| jibel | heh, I thanked it for tat too :) | 10:22 |
| jibel | +h | 10:22 |
| pitti | jibel: btw, I started working on an adt-virt-qemu as a side project | 10:22 |
| jibel | pitti, did you talked to rbasak, because he intended to work on it too? | 10:22 |
| pitti | jibel: with that we can support proper "breaks-testbed" tests, and don't need to install/wait for autopkgtest inside the VM, and simplify run-adt-test | 10:23 |
| pitti | jibel: I will; so far it's just initial investigations to learn how to write one | 10:23 |
| pitti | rbasak: ^ FYI | 10:23 |
| rbasak | pitti: I have a tool that wraps libvirt and simplestreams that is most of it. uvtool, in universe, that provides a command called uvt-kvm. | 10:23 |
| pitti | jibel: I'm shamelessly stealing from run-adt-test, of course | 10:23 |
| pitti | rbasak: ah, I'm trying to write that in a way to be useful for Debian | 10:24 |
| rbasak | pitti: it lets you start a COW instance from a cloud image. | 10:24 |
| jibel | pitti, I was wondering if libvirt wouldn't be a better option than pure qemu, because it'd be easier to start VMs with a specific definition | 10:24 |
| rbasak | pitti: it only really *requires* libvirt and cloud-init. Debian has both of those, right? | 10:24 |
| jibel | and there are python bindings for libvirt to may make things easier to glue with autopkgtest | 10:25 |
| pitti | jibel: yeah, probably; so far I really just invested an hour or so in it, to figure out how to build proper auxverb/shstring commands | 10:25 |
| rbasak | pitti: you could in theory have an outside script construct a Debian image qcow image that uses cloud-init, and then have uvtool use that. | 10:25 |
| jibel | rbasak, they have both, but Debian doesn't have pre-built cloud images, do they? | 10:26 |
| jibel | so you'd need to debootstrap a debian image and prepare it to boot with cloud-init | 10:26 |
| rbasak | jibel: nope. But you could construct them locally. | 10:26 |
| rbasak | jibel: right. | 10:27 |
| jibel | rbasak, and that's the bug part of the works :) | 10:27 |
| jibel | big | 10:27 |
| rbasak | It's not that hard, is it? | 10:27 |
| rbasak | deboostrap, chroot and install cloud-init. That should be it I think. | 10:27 |
| rbasak | I've not tried, though. | 10:27 |
| jibel | it is not hard, but it takes a lot of time because there are always tons of details to fix | 10:27 |
| pitti | it seems the minimal assumption so far is that the VM needs sshd running, a specified user, and an ssh key | 10:28 |
| pitti | but that shouldn't be different with libvirt | 10:28 |
| rbasak | OK. uvtool does require cloud-init. | 10:28 |
| jibel | then you must configure cloud-init to use a nocloud provider, configure the bootloader, prepare networking, default user, access policy, keys, .... | 10:29 |
| rbasak | I don't intend to change that. cloud-init is useful, which is why we have it, and so I don't want to have to continuously work around that usefulness because I want native compatibility with Debian. | 10:29 |
| pitti | adt-virt-qemu (or -libvirt) wouldn't *build* an image, that needs to be a separate script (like prepare-testbed) | 10:29 |
| === chihchun is now known as chihchun_afk | ||
| pitti | rbasak: oh, I think it's great for constructing base images | 10:29 |
| pitti | I just want to provide an ADT runner which doesn't work in the "inside out" fashion that run-adt-test is these days | 10:30 |
| pitti | if adt-run controls the VM from outside, we can revert, track state between tests, and even do reboots | 10:30 |
| pitti | (hello jodh :) ) | 10:30 |
| jibel | rbasak, I'm investigating options to replace vmbuilder for auto-upgrade-testing, is uvtool stable enough in saucy to replace it? | 10:30 |
| pitti | and it shouldn't be that hard to write, given that we already figured out all the details with run-adt-test | 10:30 |
| pitti | rbasak: so uvtool is a tool for the VM construction side, not for communicating with it, right? | 10:31 |
| pitti | rbasak: the latter would be libvirt | 10:31 |
| rbasak | pitti: yes, more or less. It helps with construction and destruction, as a wrapper around libvirt, cloud-init userdata and handling volume imports from published Ubuntu images automatically. | 10:32 |
| pitti | jibel: anyway, this was mostly triggered by looking at run-ubiquity-test | 10:32 |
| pitti | rbasak: cool, thanks for pointing out; I wasn't aware of it | 10:32 |
| rbasak | pitti: so you just describe on the CLI what you want (eg. --run-script-once my_startup_script.sh --ssh-public-key-file some/other/id_rsa.pub) | 10:33 |
| rbasak | also things like --disk ... and --bridge br0 | 10:33 |
| rbasak | Some of those options end up in the libvirt domain definition; some get stuffed into cloud-init userdata. | 10:33 |
| rbasak | I also want to add things like --enable-proposed and --install-packages | 10:33 |
| rbasak | (relatively trivial to do things now with the structure I have; so far I add options on request quite quickly) | 10:34 |
| rbasak | pitti: it seems to be mostly bug free. https://bugs.launchpad.net/uvtool/+bug/1251296 is the biggest one right now and I have a fix almost ready for it. | 10:34 |
| ubot5 | Ubuntu bug 1251296 in uvtool "stat error messages during sync" [High,New] | 10:34 |
| rbasak | I meant jibel: it seems to be mostly bug free. https://bugs.launchpad.net/uvtool/+bug/1251296 is the biggest one right now and I have a fix almost ready for it. | 10:34 |
| rbasak | jibel: the API seems reasonably stable now, too. I still want to be able to change something without locking myself in to something forever, but I think it'll be easy to change consumers in the archive as required. | 10:35 |
| rbasak | One issue is that the postinst expects libvirtd to be running and not be broken. Some people not testing in clean environments have hit that. | 10:37 |
| pitti | jibel: ok, test fun finished; it immediately shut down the VM, I didn't see whether or not it finished | 10:45 |
| pitti | jibel: /tmp/ubiquity.tests/results/var/crash/ is empty | 10:46 |
| pitti | /tmp/ubiquity.tests/results/console == http://paste.ubuntu.com/6478372/ | 10:46 |
| pitti | jibel: where can I see the crash? | 10:47 |
| jibel | pitti, you can use the file config/testrunner.cfg as example and disable shutdown | 10:47 |
| jibel | when it crashes there is a crash file in /var/crash | 10:47 |
| pitti | jibel: ah, so it doesn't always crash | 10:48 |
| pitti | the stack trace is ath the final } of the function | 10:48 |
| pitti | so I guess, some automatic C++ deallocation; I'll stare at the code for a bit | 10:48 |
| DanChapman | pitti the odd test still passes more are failing than passing on jenkins atm | 10:48 |
| jibel | apparently not, for example https://jenkins.qa.ubuntu.com/job/ubiquity_ap-ubuntu_devel_daily-test_english_default/ | 10:49 |
| jibel | crashed on i386 but pass on amd64 | 10:49 |
| pitti | ah, I tried on amd64 | 10:49 |
| pitti | jibel: adt-run happy again, *phew*; sorry for the mess | 10:50 |
| jibel | pitti, thanks for fixing it :) | 10:50 |
| pitti | jibel: I have a hypothesis what could happen, now I need to be able to reproduce | 11:09 |
| pitti | DanChapman, jibel: roughly when do you see the crash? i. e. at which page in ubiquity? or does it happen at different places? | 11:09 |
| jibel | pitti, I could reliably reproduce this morning with the image on my machine, if you have a .so I can test it | 11:09 |
| DanChapman | pitti it is always on the transition to the slideshow/progress bar page | 11:10 |
| pitti | ah, I'm past that in my third run | 11:10 |
| DanChapman | Depending on flavor thats either coming from userinfo or U1 page | 11:11 |
| DanChapman | ah ok... the worst scenario i tested yesterday was ubuntu-gnome, using the test_nonenglish_encrypt_lvm test | 11:11 |
| DanChapman | pitti ^^ it was a guaranteed crash yesterday | 11:12 |
| * DanChapman tries today | 11:12 | |
| jibel | pitti, on Ubuntu Desktop amd64, it crashed when the slideshow started | 11:17 |
| pitti | jibel: http://people.canonical.com/~pitti/tmp/libautopilot.so goes into /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libautopilot.so | 11:17 |
| pitti | jibel: that's trusty, right? (I tried on current trusty daily) | 11:17 |
| pitti | sorry, third run just finished successfully (with unpatched ap-gtk) | 11:18 |
| jibel | pitti, Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131125) | 11:18 |
| pitti | I can't claim that I understand the crash, but this change is the only potential hiccup that I can imagine | 11:19 |
| pitti | jibel: ah, I have 26 here | 11:19 |
| pitti | jibel: let me get 25 | 11:19 |
| * pitti feeds the rsync hamsters | 11:20 | |
| jibel | pitti, running with image 25 and your patched lib | 11:25 |
| pitti | jibel: runnning 25 unpatched here now | 11:29 |
| jibel | slideshow running and installation in progress | 11:30 |
| jibel | run #1: pass | 11:35 |
| pitti | jibel: can reproduce with 25 indeed | 11:36 |
| pitti | weird that it doesn't happen with 26 | 11:36 |
| pitti | jibel: you installed the library how? | 11:37 |
| pitti | jibel: if it's any easier, I can build a .deb with a higher version | 11:37 |
| jibel | pitti, http://paste.ubuntu.com/6478537/ | 11:38 |
| jibel | and put the lib into autopilot/ubiquity-autopilot-runner/custom-installation/iso-override/usr/local/bin/ | 11:38 |
| pitti | aah, nice | 11:38 |
| jibel | it was not really the purpose of the tool :) | 11:38 |
| pitti | jibel: ok, running while I grab some lunch | 11:40 |
| jibel | pitti, enjoy your lunch | 11:41 |
| jibel | there are several unity-gtk updates in 26 maybe that's the difference | 11:41 |
| pitti | it's a totally dubious crash anyway | 11:41 |
| pitti | I googled for the C++ std:string semantics, and assigning a char* does copy the string | 11:41 |
| pitti | there's nothing obviously wrong with the code | 11:42 |
| pitti | but I dropped std:string now and replaced it with good old g_strcmp() | 11:42 |
| pitti | as the function is half C and half C++, maybe that confuses something | 11:42 |
| pitti | jibel: my first run passed, starting a second now | 12:18 |
| DanChapman | pitti, \o/ | 12:19 |
| pitti | DanChapman: jibel also had a successful run with it; I guess we both do three runs each, and if they all succeed we declare it fixed | 12:21 |
| DanChapman | pitti ok using image 25?? | 12:21 |
| pitti | DanChapman: yes, as it doesn't seem to crash with 26 | 12:21 |
| pitti | (I tried three times0 | 12:21 |
| pitti | ) | 12:21 |
| DanChapman | pitti, ack | 12:22 |
| jibel | pitti, 3 successful run with 25 and your patch | 12:30 |
| pitti | third one almost done | 12:33 |
| DanChapman | pitti, first 2 successful 3rd just starting | 12:33 |
| pitti | DanChapman: ah, you try image 1125 with my lib, too? | 12:34 |
| DanChapman | pitti indeed :-) | 12:34 |
| pitti | jibel, DanChapman: 3/3 success on 1125 with my patch | 12:34 |
| jibel | pitti, excellent. So I'll guess this is a message to rewrite unity in good old glib style | 12:35 |
| jibel | ;) | 12:35 |
| pitti | heh | 12:35 |
| pitti | https://code.launchpad.net/~pitti/autopilot-gtk/fix-1254996/+merge/196703 | 12:40 |
| * pitti now submits to the verdict of Jenkins | 12:40 | |
| pitti | DanChapman: so, I hope we'll land that by tomorrow; but I hope you are unblocked now as it doesn't seem to crash on 26? | 12:40 |
| DanChapman | pitti, great thanks, I think the issue is still there with 26 https://jenkins.qa.ubuntu.com/view/All/job/ubiquity_ap-xubuntu_devel_daily-test_nonenglish_default/ which I will test that locally in a min patched and unpatched. But the patch unblocks me locally anyway. Thanks | 12:45 |
| pitti | DanChapman: ah, so maybe I was just lucky three times | 12:46 |
| DanChapman | pitti, I think you was, I had 5 clear successes in a row with 25 yesterday then not a single one after that :-D | 12:47 |
| pitti | Computers are reliable, software is reproducible, and the earth is flat | 12:50 |
| jibel | balloons, DanChapman finally https://jenkins.qa.ubuntu.com/view/Ubiquity/ | 12:55 |
| xnox | pitti: pick any two? =) | 12:55 |
| jibel | there are unnecessary jobs that will be removed from the public instance | 12:55 |
| pitti | xnox: oh, I pick stracciatella and pistachio then! | 12:56 |
| xnox | sprinkles and cream? I guess i was thinking "Software Development - on time, on budget, to spec; pick any two" | 12:57 |
| pitti | heh | 12:57 |
| pitti | xnox: s/software// | 12:57 |
| pitti | it's not like buildings or planes or trains would be any different :) | 12:58 |
| xnox | refactoring skillz++ | 12:58 |
| pitti | although certain Berlin airports managed to violate all three :) | 12:58 |
| xnox | well in London, the first crossrail proposal was made in 1941, approved in 2004, reapproved with larger budget and longer timelines in 2005, now they are actually reducing scope, delayed and raising additional funding. | 13:00 |
| xnox | so it's best and worst =) of all projects =) | 13:01 |
| DanChapman | jibel awesome! that makes checking results easier :-) Just incase you hadn't noticed Lubuntu tests aren't running yet ;-p | 13:08 |
| jibel | DanChapman, yes, I just realized that, checking | 13:08 |
| jibel | DanChapman, actually they fail because apt cache is locked when it tries to install additional packages | 13:14 |
| jibel | E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) in run.log | 13:14 |
| jibel | I'll verify this condition and retry a few times to make it more robust | 13:15 |
| jibel | we should probably protect the test against the fatal hash sum mismatch error | 13:16 |
| === ara is now known as Guest1754 | ||
| jibel | DanChapman, I think it is because it starts simultaneously with update-notifier which checks if a new release is available | 13:20 |
| jodh | pitti: a delayed "hi" :) | 13:31 |
| === ara_ is now known as ara | ||
| === ara is now known as Guest55288 | ||
| === Guest55288 is now known as ara_ | ||
| === Ursinha-afk is now known as Ursinha | ||
| pitti | rbasak, jibel: do you happen to know how to add some files to a qemu image without root? | 14:38 |
| pitti | rbasak, jibel: qemu-nbd works as non-root if you have it listen to a port instead of connecting to /dev/nbd*, but are there some clients for that which you know of? | 14:38 |
| jibel | pitti, kpartx needs root. Did you try libguestfs? | 14:41 |
| jibel | I don't know about nbd clients | 14:41 |
| pitti | jibel: kpartx only works with raw images, though, not with qcow? | 14:41 |
| jibel | pitti, that's right | 14:41 |
| pitti | jibel: I didn't try libguestfs | 14:42 |
| elopio | good morning good quality people. | 14:43 |
| pitti | hey elopio | 14:44 |
| jibel | Hi elopio | 14:44 |
| jibel | pitti, nbd-client would be an nbd client? :) | 14:45 |
| jibel | I never tried nbd | 14:46 |
| pitti | jibel: yes, but debconf/root/etc. | 14:46 |
| jibel | ah | 14:46 |
| pitti | jibel: it seems to be the only way to access a qemu image | 14:46 |
| jibel | other than an hexadecimal editor | 14:47 |
| pitti | jibel: I'd prefer planting a shell on /dev/ttyS1 over assuming that the VM always has a running network and ssh (as you may want to fiddle with the latter in tests) | 14:47 |
| pitti | also, it would be nice to drop teh requirements of "need to know an user name", "need to have an SSH key", etc. | 14:48 |
| pitti | n | 14:48 |
| jibel | pitti, agreed, and it also has the benefit to provide greater control over the testing environment | 14:50 |
| rbasak | pitti: I like the serial idea. | 14:51 |
| pitti | jibel: can you do two overlays? | 14:51 |
| pitti | jibel: i. e. <ro base image> <one overlay with the autopkgtest hacks> <the r/w temp overlay> | 14:51 |
| jibel | pitti, yes, that's what we do with otto | 14:51 |
| rbasak | I don't like libguestfs. It basically uses KVM to start a VM as non-root. Feels like a sledgehammer on a nail. But I don't know of any other solution. | 14:51 |
| pitti | ther's qemu-img convert; I can create a raw image as user relatively easily | 14:51 |
| pitti | rbasak: yes, and it's rather heavy | 14:52 |
| pitti | jibel: cool, I'll try that then | 14:52 |
| * pitti is in a hacking mood this afternoon | 14:52 | |
| * rbasak thinks about adding serial shell support to uvtool | 14:52 | |
| elopio | cgoldberg: I've sent you the invite to the talks. | 14:52 |
| elopio | please check I didn't mess with the timezone again :) | 14:53 |
| rbasak | pitti: I'd really like a one command adt-virt-kvm/qemu/uvtool/whatever that a user can use directly using adt-run and supports break-testbed. Is this what you're working on, or will you need support scripts from auto-package-testing? | 14:55 |
| pitti | rbasak: once you have any VM, this is what I'm working on | 14:55 |
| rbasak | What do you mean by "any VM"? | 14:55 |
| pitti | rbasak: unfortunately, for the cloud images you need to specify two drive images (as they always need the seed image) | 14:56 |
| rbasak | Well, that's what uvtool wraps :) | 14:56 |
| pitti | but that's due to how we build "our" base images | 14:56 |
| rbasak | It's cloud-init, which is fast becoming the accepted way of doing things. | 14:56 |
| pitti | rbasak: well, if you have any Debian/Ubuntu VM, I'd just like adt-run ... --- adt-virt-kvm /path/to/image | 14:56 |
| rbasak | It's not Ubuntu-specific. | 14:56 |
| pitti | or, in our case, /path/to/baseimage /path/to/cloudseed | 14:56 |
| rbasak | I'd like apt-get install <stuff> && adt-run ... --- adt-virt-uvtool trusty. | 14:57 |
| pitti | rbasak: my first prototype uses ssh to communicate, and thus needs to know an username and ssh key | 14:57 |
| pitti | but I don't like that | 14:57 |
| rbasak | With no other support or set up scripts required. | 14:57 |
| pitti | rbasak: yeah, once we have adt-virt-qemu, we can think about auto-creating base images | 14:57 |
| rbasak | Well, in the Ubuntu case, we publish official base images. | 14:57 |
| pitti | but you don't want to create a new VM each time you run a test, so we need the intermediate -qemu runner, too | 14:58 |
| rbasak | From my perspective, Debian not doing so necessitates a workaround, rather than being the primary form. | 14:58 |
| pitti | extending that to build the VM (with either a new runner, or a new option) is the next step, and sounds interesting | 14:58 |
| pitti | so, instead of /path/to/image we could support an "uvtool:trusty" argument, possibly with a --cache-dir or so | 14:59 |
| pitti | s/instead of/in addition to/ | 14:59 |
| rbasak | Can we use VM snapshots via libvirt? Or do you not want to use libvirt? | 14:59 |
| pitti | but still, I really don't want to make strong assumptions about the VM | 15:00 |
| rbasak | (for virt reset, for breaks-testbed, to avoid starting a VM) | 15:00 |
| rbasak | I think you're getting too low level. | 15:00 |
| pitti | if you have an existing Ubuntu or Debian desktop installation, or something else you hacked on yourself, this should still be useful for running tests i | 15:00 |
| rbasak | I think it makes sense to use higher pieces in the stack where they support the functionality you need, rather than reinventing it. | 15:00 |
| pitti | n | 15:00 |
| rbasak | uvtool supports --backing-image-file. | 15:00 |
| cgoldberg | elopio, lightning talk is tomorrow? I thought it was today for some reason, and was ready to go :) | 15:01 |
| rbasak | I think that should be the uncommon case, though. | 15:01 |
| cgoldberg | elopio, but no prob.. tomorrow is better | 15:01 |
| pitti | still, I don't want to bind this to exactly one type of VM, ubuntu specific, and with making a lot of assumptions (network, ssh, cloud-init, etc.) | 15:01 |
| elopio | cgoldberg: great :) | 15:01 |
| pitti | as these are all pieces which you might actually want to test | 15:01 |
| rbasak | Network and ssh I agree with. We could use serial terminal to fix that. | 15:01 |
| pitti | we already had a case where NetworkManager tests tore down eth0 and the whole test hung | 15:02 |
| rbasak | cloud-init I don't agree with. It is the accepted way of setting up a VM. We should use it. | 15:02 |
| pitti | the thing that currently is too hard is to access/modify a VM image | 15:02 |
| pitti | once I get an additional init.d script in there, accessing the VM is trivial; there's not much to reinvent there | 15:02 |
| rbasak | Are you aware of mount-image-callback? In cloud-image-utils. | 15:02 |
| elopio | I'll send more invitations. balloons, now that we have practices with a couple of talks, I think it would be nice to invite all the QA community. | 15:02 |
| rbasak | Admittedly it currently needs root. | 15:02 |
| pitti | yeah | 15:03 |
| pitti | I'd like to avoid that | 15:03 |
| pitti | as we want to run it in the data center on machines where we don't have root | 15:03 |
| rbasak | I really feel that you're reinventing the wheel, here. | 15:03 |
| rbasak | I'd like to implement an adt-virt-uvtool. It's one of the use cases I had in mind when I wrote adt-virt-uvtool. | 15:03 |
| rbasak | Now that uvtool exists, it is trivial to implement. | 15:03 |
| pitti | rbasak: well, adt-run's assumption is: I have a pipeline to the testbed; with that it can do everything | 15:03 |
| rbasak | adt-run also requires the virt driver to have a mechanism to create the testbed, and to roll it back (for breaks-testbed). And destroy, obviously. | 15:04 |
| pitti | right | 15:04 |
| pitti | that's what we already do in run-adt-test | 15:04 |
| rbasak | This should be quick to be useful to developers. It should be one command. It should not require previous setup. | 15:04 |
| rbasak | run-adt-test does not meet these requirements. | 15:05 |
| pitti | not require, but support | 15:05 |
| pitti | I want pre-prepared images, not downloading/building images for each test | 15:05 |
| pitti | (yes, I guess you can do that) | 15:05 |
| pitti | rbasak: sure, for starting/controlling qemu uvtool sounds nice, I'll look at it | 15:05 |
| rbasak | With uvtool you download a pre-prepared image once. | 15:05 |
| pitti | rbasak: does that support debian VMs? | 15:06 |
| rbasak | It requires cloud-init. | 15:06 |
| pitti | hmm | 15:06 |
| rbasak | I don't want to be dragged along by Debian not publishing cloud images with cloud-init. | 15:06 |
| rbasak | Or not publishing easily consumable metadata for downloads. | 15:06 |
| pitti | fair enough :) | 15:06 |
| rbasak | I'm not saying that we shouldn't support Debian; we should. | 15:07 |
| === ara_ is now known as ara | ||
| rbasak | But we (server team) are actively working on this stuff. In my mind, we're the upstream and leading the way for cloud image consumption. | 15:07 |
| rbasak | So, to me, supporting Debian not doing cloud-init and not publishing cloud images and not publishing cloud image metadata is a workaround. | 15:07 |
| rbasak | We can support that, with --backing-image-file. | 15:07 |
| rbasak | And a script to generate a suitable Debian image. | 15:08 |
| rbasak | (assuming that cloud-init works OK) | 15:08 |
| pitti | well, our ubuntu desktop images aren't cloud-initified either | 15:08 |
| rbasak | Perhaps uvtool could have an option to not use cloud-init. | 15:08 |
| pitti | (and they are ready-to-work VM images) | 15:08 |
| balloons | elopio, yes, and they are archived, so that is useful as well | 15:08 |
| rbasak | You'd lose the handy options to do stuff in the VM. | 15:08 |
| balloons | would you want to do it in the form of an onair session? | 15:08 |
| rbasak | But with serial shell support expected in the VM, you'd still be able to get to it. | 15:09 |
| pitti | right | 15:09 |
| pitti | which is a much weaker assumption than "has network", "has ssh", and "has cloud-init" | 15:09 |
| pitti | and even "has network all the time" | 15:09 |
| pitti | we currently cannot do any autopkgtest which touches the network, not even with breaks-testbed | 15:10 |
| pitti | rbasak: so I just wanted to tinker around a bit whether it's feasible to do everything through ttyS{1,2} | 15:10 |
| pitti | it may well turn out to not work, but let's see :0 | 15:10 |
| pitti | also, it seems that preparing VM overlays as non-root would be useful in other places too | 15:10 |
| rbasak | AIUI, it should work, albeit perhaps slow. | 15:11 |
| rbasak | pitti: OK. Can we sync when you're done experimenting? I don't want to duplicate effort here. | 15:11 |
| pitti | rbasak: sure | 15:11 |
| pitti | rbasak: btw, my init script is essentially | 15:13 |
| pitti | (setsid sh </dev/ttyS1 >/dev/ttyS1 2>/dev/ttyS2) & | 15:13 |
| pitti | I put that into the overlay, and can run minicom from outside just fine (and a second netcat for stderr) | 15:13 |
| rbasak | Will you need to do some other env setup there? | 15:14 |
| rbasak | Perhaps "login -f root"? Though maybe from the host rather than the guest. | 15:14 |
| pitti | rbasak: not really; other things (conceivably creating a temporary user for adt-run if you run as user) can be done from adt-virt-qemu through that shell | 15:15 |
| pitti | one just needs to get a foot into the door | 15:15 |
| rbasak | Yes; that's what I mean by "from the host". | 15:15 |
| rbasak | I'm interested in the speed you get there, though. Be sure to use virtio for the serial hardware in the guest. But how long will it take to transfer a gig that way? | 15:16 |
| pitti | yeah, that's my primary concern | 15:16 |
| pitti | we might possibly do something like adding a second eth and using that for data transfer, and using the serial terminal just for controlling and running commands | 15:17 |
| pitti | adt-run doesn't need to transfer much while a test is running; just for coyping in the package, and copying out the results | 15:18 |
| rbasak | But then you need a network again. | 15:18 |
| rbasak | Oh, I see. | 15:18 |
| pitti | and during copying there are no tests interfering | 15:18 |
| rbasak | So you assume the network is good before and after a test. | 15:18 |
| rbasak | So the test will need to restore the network in the passing case, but that should generally be true for all tests? | 15:19 |
| pitti | not assume, we need to set it up that way (and tear down the second eth during the test) | 15:19 |
| pitti | rbasak: no, we always need the serial terminal (and possibly the qemu monitor, but that's no problem) to control the network | 15:19 |
| pitti | this is all rather difficult, indeed | 15:19 |
| pitti | and we certainly need to make some assumptions like "tests don't remove the "ip" binary" | 15:20 |
| pitti | perhaps we can live with assuming that the tests don't tear down an "adteth0" interface which the setup creates, and use that as the one and only channel | 15:22 |
| pitti | (static IP and netcat0 | 15:22 |
| cgoldberg | robotfuel, ping ... | 15:22 |
| robotfuel | cgoldberg: hi | 15:22 |
| cgoldberg | robotfuel, those benchmarks tests you have with a dashboard... | 15:22 |
| cgoldberg | robotfuel, do you pull data from jenkins for the dashboard, or does jenkins push the data somewhere to store? | 15:23 |
| robotfuel | cgoldberg: it gets pulled from jenkins | 15:23 |
| cgoldberg | robotfuel, do any run against a device? | 15:24 |
| cgoldberg | rather than a vm/desktop | 15:24 |
| robotfuel | cgoldberg: only desktops | 15:24 |
| cgoldberg | robotfuel, k thanks | 15:24 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| TheLordOfTime | ;ping | 17:17 |
| TheLordOfTime | oops sorry | 17:17 |
| TheLordOfTime | balloons, ping, if you're not busy, if you are i'll ask you later. just trying to figure out who to ask questions to about the ubuntu touch stuff that's drifting around the mailing list | 17:21 |
| balloons | TheLordOfTime, howdy | 17:24 |
| TheLordOfTime | balloons, are you keeping up with the ML discussions? There's a -devel -touch and -quality discussion about them not filing bugs against repo packages, is this just people being ignorant of how LP's bug systems work? | 17:26 |
| TheLordOfTime | s/touch/phone/ | 17:26 |
| TheLordOfTime | or are they using a separate tracker system? (I ask because anything bug related makes me a little interested, but I know nothing about how the phone dev stuff is) | 17:26 |
| TheLordOfTime | oh, and good day to you all, too. | 17:27 |
| TheLordOfTime | :) | 17:27 |
| TheLordOfTime | forgot to be courteous to everyone else today D | 17:27 |
| TheLordOfTime | :D | 17:27 |
| balloons | TheLordOfTime, Ursinha mentioned it yesterday but I was engrossed in other things. I saw the posts and glanced at them | 17:28 |
| TheLordOfTime | so i should probably touch base with Ursinha? | 17:28 |
| Ursinha | TheLordOfTime, hey | 17:29 |
| balloons | They want to make it clearer to keep track of bugs, etc | 17:29 |
| balloons | and yes :-) | 17:29 |
| TheLordOfTime | Ursinha, where're your bugs ending up now, Launchpad, upstream trackers, or some other tracker system? | 17:29 |
| Ursinha | the thing is that some bugs were overlooked because there wasn't a clear policy about where to file bugs | 17:29 |
| Ursinha | TheLordOfTime, all of our bugs are in Launchpad :) | 17:29 |
| TheLordOfTime | Ursinha, and the upstream projects are on Launchpad? | 17:30 |
| Ursinha | the point is their target, the upstreams projects in Launchpad or the Ubuntu source packages in Launchpad | 17:30 |
| TheLordOfTime | Ursinha, if the answer to my last question is yes... | 17:30 |
| TheLordOfTime | you can add a bug to an ubuntu package as well as upstream | 17:30 |
| Ursinha | TheLordOfTime, I believe all of the upstreams that are part of Touch yes | 17:30 |
| Ursinha | they can be found in launchpad | 17:30 |
| TheLordOfTime | Ursinha, but i meant are they on Launchpad | 17:30 |
| TheLordOfTime | if the upstreams trackers' are all on Launchpad... | 17:30 |
| TheLordOfTime | and also all the packages are listed on Launchpad... | 17:30 |
| Ursinha | TheLordOfTime, yes, the discussion is that we always need an ubuntu bugtask, if the upstreams prefer we can also add an upstream bugtask | 17:31 |
| Ursinha | yes, all packages are on launchpad because they're part of the Ubuntu main archive | 17:31 |
| TheLordOfTime | Ursinha, are all your bug filers and testers aware you can add an ubuntu bug task against the package, or against upstream, depending on how they were filed, after the fact? | 17:31 |
| TheLordOfTime | not saying they all aren't, but i was purely curious | 17:32 |
| Ursinha | TheLordOfTime, that's what we're discussing in that mailing list thread | 17:32 |
| Ursinha | :) | 17:32 |
| * TheLordOfTime is about 3 messages behind, let me catch up | 17:32 | |
| Ursinha | we need to be sure the policy is known and documented so whoever wants to file bugs can be pointed to that | 17:32 |
| Ursinha | everything is on Launchpad, it's a matter of deciding if we're using upstreams tasks as well or not | 17:33 |
| TheLordOfTime | mmm | 17:34 |
| TheLordOfTime | Ursinha, okay, i was under the impression half the testers were unaware they could set it against both after the fact | 17:36 |
| Ursinha | TheLordOfTime, right | 17:36 |
| Ursinha | Launchpad in this sense is really nice so we have one bug and several affected parts | 17:37 |
| Ursinha | packages or projects | 17:37 |
| Ursinha | like for instance bug 1 | 17:37 |
| ubot5 | bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 | 17:37 |
| TheLordOfTime | right | 17:37 |
| Ursinha | there's half a million affected parts :P | 17:37 |
| TheLordOfTime | heheh | 17:37 |
| Ursinha | some upstreams decided to disable reporting bugs directly, deciding to use only the distro package | 17:39 |
| TheLordOfTime | Ursinha, typically, my "If in doubt" fallback is to immediately compare what's in the repositories and what's in trunk upstream or at least the latest release of upstream on the same track as whatever's included in the repos by version, and if there's a substantial delta between what you're reporting against and what's upstream, don't file the upstream task, but you can also take the flip of that... | 17:39 |
| TheLordOfTime | and just file both anyways, until upstream tells you to stop | 17:39 |
| TheLordOfTime | but that usually can cause tension, and of course, I'm not in the ubuntu touch scope, i merely triage bugs under the ubuntu bug guidelines | 17:40 |
| Ursinha | TheLordOfTime, well, if you're using ubuntu than first thing would be to report it against the ubuntu package, not upstream | 17:40 |
| TheLordOfTime | mhm | 17:40 |
| Ursinha | after that if upstream thinks it's relevant they add another bugtask | 17:40 |
| TheLordOfTime | Ursinha, indeed, as is typical triage / how to file a bug | 17:40 |
| TheLordOfTime | mhm | 17:40 |
| Ursinha | but the rule of gold is if you found a bug in the distro, file a bug against the distro package | 17:40 |
| TheLordOfTime | Ursinha, as it should be :) | 17:40 |
| Ursinha | :) | 17:40 |
| TheLordOfTime | Ursinha, so then the only issue you're hung up on then... | 17:41 |
| TheLordOfTime | is when to file an upstream bug. | 17:41 |
| TheLordOfTime | or rather, add an upstream task | 17:41 |
| Ursinha | that's what we're discussing there :) because some people weren't reporting the bug against the ubuntu package at all | 17:41 |
| TheLordOfTime | Ursinha, if i may voice a basic opinion, if testers want to test and see if it needs an upstream task, test against upstream | 17:41 |
| TheLordOfTime | ahhh | 17:41 |
| Ursinha | so first thing is we need to agree on doing that no matter what | 17:42 |
| TheLordOfTime | well those people are at fault, tie them down and indoctrinate them :P | 17:42 |
| Ursinha | haha | 17:42 |
| Ursinha | second thing is to think about the upstreams and if they find value in using the upstream tracking | 17:42 |
| TheLordOfTime | you might reach out to the commonly-filed-against upstreams and ask them | 17:42 |
| TheLordOfTime | i'm probably not adding anything, but i'm merely trying to figure out where you guys are standing :) | 17:43 |
| TheLordOfTime | ... back in a bit, coffee run | 17:43 |
| Ursinha | TheLordOfTime, that's what I aimed by sending that email, I added -touch and -devel to the loop, I believe all upstreams were reached that way | 17:44 |
| TheLordOfTime | heheh | 17:45 |
| TheLordOfTime | Ursinha, i'd say then the ball is in upstream's court, they can either respond, or just drop the ball, and if they do drop the ball on that, then I'd take the view, if it were my call, to say "Only file against the Ubuntu package, and nothing else" | 17:46 |
| Ursinha | ☕ | 17:46 |
| TheLordOfTime | except where someone's testing against upstream trunk and reproducing it there too | 17:46 |
| TheLordOfTime | BTW, 0x0000 is lol | 17:46 |
| * TheLordOfTime points at unicode that isn't matched to any characters xD | 17:47 | |
| Ursinha | lol | 17:47 |
| Ursinha | that was supposed to be a hot beverage char | 17:47 |
| TheLordOfTime | :P | 17:47 |
| TheLordOfTime | Ursinha, emoji? | 17:47 |
| Ursinha | TheLordOfTime, http://www.fileformat.info/info/unicode/char/2615/index.htm | 17:47 |
| TheLordOfTime | ahhhh, the smell of brewing coffee... awesome. | 17:47 |
| TheLordOfTime | (sorry i'm a high-level coffee addict... the smell of coffee is amazing to me) | 17:48 |
| elfy | pfft | 17:48 |
| TheLordOfTime | elfy, 12 cups yesterday | 17:48 |
| TheLordOfTime | that's how much i had | 17:48 |
| TheLordOfTime | ... and that was just in 12 hours | 17:48 |
| elfy | 2 gallons here | 17:48 |
| TheLordOfTime | woah damn elfy | 17:49 |
| elfy | of tea | 17:49 |
| TheLordOfTime | lol | 17:49 |
| Ursinha | haha | 17:49 |
| elfy | you should know better :D | 17:49 |
| TheLordOfTime | well... I did overdose on coffee a while back... | 17:49 |
| TheLordOfTime | it was finals week and i had to be up for four days.... | 17:49 |
| TheLordOfTime | and i kinda started binge-drinking espresso... the day after that was bad... | 17:49 |
| TheLordOfTime | but i digress | 17:50 |
| TheLordOfTime | Ursinha, yeah, i think you're on the right track dictating the bug filing policies, i have one question: some of your testers and devs are testing upstream trunk separately from the repos right? | 17:51 |
| Ursinha | TheLordOfTime, the idea with continous integration is to have trunk as close as possible of what's in the distro | 17:51 |
| TheLordOfTime | Ursinha, true, but i meant constantly testing, always pulling and building and testing from upstream when there's even a minor delta | 17:52 |
| TheLordOfTime | because if there are people doing that, then those would be the ones who could say whether something needs an upstream task, if they are able to reproduce there too. | 17:52 |
| Ursinha | that happens automatically (for most projects) when a change is being integrated to trunk, and the next step is to be pushed to distro | 17:52 |
| TheLordOfTime | ... dear god not again, balloons, the cosmic rays are breaking the mailing list systems again... | 17:53 |
| TheLordOfTime | i have four of the same message >.> | 17:53 |
| Ursinha | what's up? | 17:53 |
| Ursinha | lol wat | 17:53 |
| TheLordOfTime | Ursinha, i have four of the same message on the last message on that thread. | 17:54 |
| TheLordOfTime | three of the same last message just showed up in my inbox for no reason :/ | 17:54 |
| * TheLordOfTime blames those pesky cosmic rays interacting poorly with the mailing lists | 17:54 | |
| TheLordOfTime | Ursinha, it's either cosmic rays or the mailing lists hate me | 17:55 |
| Ursinha | haha | 17:55 |
| TheLordOfTime | i tried to send something to -bugsquad once, after my emails were registered, and it bounced even though the address was listed as being able to send | 17:55 |
| TheLordOfTime | thats happened to me once on the -quality ML too but meh | 17:56 |
| TheLordOfTime | meh, i'll just delete the dupes | 17:58 |
| TheLordOfTime | Ursinha, thanks for filling me in on the full context of what's with that topic on the ML :) | 17:58 |
| Ursinha | TheLordOfTime, no problem :) | 17:59 |
| TheLordOfTime | everything bug related in -quality piques my interest, since my primary focus is general bug triage :) | 17:59 |
| Ursinha | great :) | 17:59 |
| TheLordOfTime | oh that reminds me, balloons, ping | 17:59 |
| TheLordOfTime | balloons, where's the bugsquad/QA merge in terms of being completed/processed/approved-by-CC | 17:59 |
| TheLordOfTime | Ursinha, you know how i said the mailing lists must hate me? I lied... | 18:02 |
| TheLordOfTime | apparently its my SMTP and IMAP servers that hate me | 18:02 |
| TheLordOfTime | because i'm getting multiple messages in duplicate triplicate and quadruplicate :/ | 18:02 |
| elfy | I get the same now TheLordOfTime | 18:02 |
| Ursinha | TheLordOfTime, so it seems you are surrounded by hate | 18:03 |
| Ursinha | oh technology | 18:03 |
| TheLordOfTime | Ursinha, either that or i've become a source for cosmic ray radiation | 18:03 |
| * TheLordOfTime shrugs | 18:03 | |
| TheLordOfTime | elfy, oh so it's the INTERNET that's broken, not just my stuff? | 18:03 |
| TheLordOfTime | Oh good, I thought I broke my servers for a moment xD | 18:04 |
| TheLordOfTime | meh, i'm gonna go restart the smtp and imap processes... | 18:05 |
| TheLordOfTime | maybe that'll make the thing work | 18:05 |
| balloons | TheLordOfTime, I used to filter out my own messages on accident. I've sorted that out, so I know the mailing list pain :-) | 18:17 |
| * TheLordOfTime heard a beep, peeks at his system | 18:17 | |
| TheLordOfTime | balloons, heh. | 18:17 |
| TheLordOfTime | brb, i need to dig the car out of the snow... | 18:17 |
| * TheLordOfTime grumbles profanities about the snow | 18:18 | |
| TheLordOfTime | well, at least get some of the snow out of the way so i can get out of the driveway | 18:18 |
| dkessel | good evening | 18:29 |
| dkessel | balloons, i got a mail from phillw stating that http://packages.qa.ubuntu.com/qatracker/testcases/1613/info can be removed ... the package is not part of the default installation anymore | 18:29 |
| elfy | balloons: ^^ THAT might cause the whole thing to fall apart for lubuntu's desktop package tests if it's just removed - remember what happened with our stuff ... | 18:32 |
| balloons | dkessel, evening to you | 18:33 |
| * dkessel o/ | 18:33 | |
| elfy | hi dkessel :) | 18:33 |
| dkessel | hey elfy | 18:33 |
| balloons | dkessel, we should document the proceedings a bit.. a bug report perhaps? :-) | 18:34 |
| balloons | elfy, I'll make sure not to zonk your stuff | 18:34 |
| balloons | just want to be sure there's a trail to follow | 18:35 |
| * knome drops small bits of cookies on balloons' floor | 18:35 | |
| dkessel | hehe knome | 18:36 |
| elfy | balloons: that's not what I meant - I'd assume you'd not go and break something I'd have to send knome after :P) | 18:36 |
| elfy | was just saying that removing a testcase from a testsuite is what caused us to have archived testsuites in package tracker | 18:36 |
| knome | elfy, that bug should've been fixed, and only appropriate if you want that testcase being non-archived in another testsuite | 18:37 |
| elfy | well yea - I'm just saying what happened - I didn't follow it for long enough to see if it got fixed or just repaired ;) | 18:38 |
| knome | isn't that the same thing? ;) | 18:38 |
| elfy | not at all | 18:38 |
| knome | heh | 18:38 |
| elfy | fixed - doesn't happen again/repaired - fixed this one this time, don't do it again :D | 18:38 |
| knome | hah | 18:39 |
| knome | well it was fixed by the awesome stgraber | 18:39 |
| elfy | :) | 18:40 |
| balloons | well hello knome ! | 18:53 |
| balloons | I should have noticed the cookie crumbs | 18:54 |
| DanChapman | elfy https://jenkins.qa.ubuntu.com/view/Ubiquity/view/Xubuntu/ will make viewing results easier for you :-) | 18:54 |
| elfy | nice :) | 18:56 |
| * elfy sends DanChapman a cookie | 18:56 | |
| knome | elfy, that the one you picked up from balloons' floor? | 18:56 |
| elfy | sssh | 18:56 |
| * DanChapman dips it in his cuppa | 18:57 | |
| * DanChapman just spat all over the desk | 18:57 | |
| elfy | DanChapman: shake it first ... | 18:57 |
| elfy | too late :| | 18:57 |
| DanChapman | lol | 18:57 |
| elfy | so they are failing then according to jenkins ? | 18:57 |
| DanChapman | elfy yeah wee discovered a bug yesterday in autopilot a fix should land hopefully tomorrow so in the next couple of days they 'should' go green | 18:58 |
| elfy | right | 18:59 |
| elfy | just in time for me to see some green lights to show the xubuntu team at the thursday meetng hopefully | 18:59 |
| elfy | and I'll grab lderan before hand to find out if autopilot for us is a but thumbs down again this cycle | 19:00 |
| dkessel | hehe knome | 19:19 |
| dkessel | so, is there anything to do about the testcase I wrote about above? | 19:19 |
| balloons | dkessel, no.. I'll take care out if.. you can confirm it's good in a moment | 19:37 |
| dkessel | balloons, ok thanks | 19:37 |
| balloons | whew.. the random sentences spewing out today | 19:38 |
| dkessel | hehe. big fingers today? :) | 19:38 |
| balloons | it means my mind is everywhere I think | 19:38 |
| balloons | alright.. I think we are good | 19:39 |
| dkessel | yup, gone. fine | 19:39 |
| === thomi_ is now known as thomi | ||
| balloons | excellent | 19:40 |
| balloons | I don't even think I blew anything up for elfy | 19:41 |
| balloons | sadly... | 19:41 |
| dkessel | too bad ;) | 19:41 |
| balloons | buonsera Letozaf_. come stai? | 20:16 |
| Letozaf_ | balloons, buonasera :D bene e tu ? | 20:16 |
| balloons | bene! Fixed 3 core apps last night :-) | 20:17 |
| Letozaf_ | balloons, wow! you done a great job :) | 20:17 |
| Letozaf_ | balloons, witch ones? | 20:17 |
| balloons | file manager, rss reader and calendar. Trying to keep everything green | 20:18 |
| balloons | we got really close but the work we did before uds didn't quite get us all the way there | 20:18 |
| Letozaf_ | balloons, rss reader yay! :D | 20:19 |
| Letozaf_ | balloons, well we will have to keep them green now | 20:19 |
| balloons | yes, I'm cutting a hard line | 20:20 |
| Letozaf_ | balloons, I have a test for music app, it works on the desktop, if it works on the device I will propose merge, but first I will have to flash the right image to my device for testing | 20:21 |
| === salem_ is now known as _salem | ||
| balloons | Letozaf_, wonderful! | 20:23 |
| Letozaf_ | balloons, wait, let's see if it works on the device first :P | 20:24 |
| Letozaf_ | balloons, they always first work on desktop :P | 20:24 |
| balloons | dkessel, Letozaf_, knome elfy, other lurkers :-) I was just having a look at this tool, http://reqorts.qa.ubuntu.com/reports/qa/qa-touch.html, and wondered if some custom views for our purposes would be useful to everyone | 20:24 |
| elfy | balloons: well I am glad that worked - we're going to be looking at ours shortly - so needed someone to test that :p | 20:25 |
| balloons | for instance, have view for entire team so we can see what bugs we have opened. have a view for installer/image bugs. Have a view for bughug days, etc | 20:25 |
| elfy | oooh | 20:25 |
| balloons | autopilot tests / issues as well | 20:25 |
| elfy | that would be excellent if you could have a user defined search term | 20:26 |
| balloons | that's off the top. I can think of triage uses as well, but I'm less well versed | 20:26 |
| elfy | I could say look for xubuntu trusty iso | 20:26 |
| elfy | kind of thing | 20:26 |
| elfy | date fields perhaps | 20:26 |
| balloons | live search isn't so much an option, as this is a report, not a launchpad replacement :-) | 20:28 |
| elfy | even if it was generic - but split flavours up from the general thing - kind of like that does with canonical/cordova etc | 20:28 |
| balloons | but filtering is possible, and so, defined filters can work | 20:28 |
| balloons | yes, filters for flavors makes sense | 20:28 |
| balloons | and would be well defined | 20:28 |
| elfy | yep | 20:28 |
| elfy | I have to look at iso/package tracker every now and again to see what everyone else is seeing :) | 20:29 |
| elfy | balloons: when I want to look atm - I drag the archived test results and manually look at what bugs we've reported - takes ages ... | 20:30 |
| balloons | elfy, ugh yea | 20:32 |
| knome | it IS a bummer there is no "list all the bugs" mode in the trackers, just "hover over" | 20:33 |
| elfy | knome: yep | 20:33 |
| elfy | balloons: sooo - Xubuntu would like that :D | 20:33 |
| Letozaf_ | balloons, what if I wanted to see all the core apps bugs for instance | 20:35 |
| Noskcaj | Does anyone think they could help me with transmission-gtk's autopilot test? I've pushed my terrible first attempt to lp:~noskcaj/ubuntu-autopilot-tests/transmission | 20:36 |
| dkessel | yay, lubuntu on tv... on a german series i am just watching :) | 20:37 |
| Noskcaj | :) | 20:38 |
| Noskcaj | I think i saw ubuntu on person of interest, no other shows yet | 20:38 |
| dkessel | gotta leave.. good night folks... | 20:47 |
| balloons | dkessel, lubuntu even? cool! | 20:47 |
| balloons | Noskcaj, sure i'll have a look | 20:48 |
| balloons | Dan isn't around, he's the gtk master :-) | 20:48 |
| Noskcaj | balloons, I think transmission or gtk is having an issue. Even with my lack of skill and using both self.app and app_proxy, it doesn't really work as i would have expected | 20:49 |
| balloons | Noskcaj, it's possible.. not every gtk app is happy to be introspected | 20:49 |
| Noskcaj | i think transmission is though. Every xfce app dooesn't though | 20:49 |
| Noskcaj | maybe i should try transmission-qt | 20:50 |
| balloons | Noskcaj, qt is much saner for instropecting | 20:50 |
| balloons | but let's see | 20:50 |
| Letozaf_ | balloons, must I tell Victor about the music app merge proposal or you ? | 21:26 |
| balloons | Letozaf_, when you propose it shows up on the radar for everyone :-) | 21:26 |
| Letozaf_ | balloons, ok so I won't tell anyone :P | 21:27 |
| balloons | Letozaf_, haha, you can mention it, I'm just saying :-) | 21:27 |
| Letozaf_ | balloons, :P | 21:27 |
| balloons | Noskcaj, btw, Gtk-Message: Failed to load module "autopilot" | 21:28 |
| balloons | you get the same? | 21:28 |
| balloons | Noskcaj, you can see with a simple launch check | 21:30 |
| balloons | autopilot launch -i Gtk transmission-gtk | 21:30 |
| balloons | Gtk-Message: Failed to load module "autopilot" | 21:30 |
| Letozaf_ | balloons, failure :( | 21:36 |
| balloons | Letozaf_, ? ohh the mp | 21:39 |
| balloons | Letozaf_, ohh that's easy | 21:40 |
| balloons | it's a pep8 thing | 21:40 |
| balloons | + pep8 --repeat --show-source . | 21:40 |
| balloons | ./tests/autopilot/music_app/emulators.py:106:29: E712 comparison to True should be 'if cond is True:' or 'if cond:' | 21:40 |
| balloons | if item.enabled == True: | 21:40 |
| balloons | ^ | 21:40 |
| balloons | ./debian/music-app-autopilot/usr/lib/python2.7/dist-packages/music_app/emulators.py:106:29: E712 comparison to True should be 'if cond is True:' or 'if cond:' | 21:40 |
| balloons | if item.enabled == True: | 21:40 |
| Letozaf_ | balloons, ok let me fix that | 21:41 |
| Letozaf_ | balloons, done, I will push it | 21:42 |
| Letozaf_ | balloons, done, going to bed now! hope it works otherwise I will fix it tomorrow | 21:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!