=== Ursinha-afk is now known as Ursinha === salem_ is now known as _salem [03:32] Noskcaj, ping [03:46] Noskcaj10, ping [04:17] Noskcaj10, tests are fully synced to rev189 [04:18] Hey hey balloons [04:18] goodnight smartboyhw :-p [04:18] LOL [04:18] ROFL! [04:18] I win! [04:18] balloons, meh:( [04:18] how are you? [04:18] I'll stay for a min :-) [04:18] balloons, great:) [04:19] how was your trip? find the UK interesting? [04:19] balloons, which autopilot tests would you recommend me to touch on? (Since many are completed it seems) and UK is great! [04:49] Good morning [06:19] smartboyhw, pong, i was at school [06:19] Noskcaj10, I can't seem to understand the structure of the .pot file, I just can't seem to get how the .ui.h thing works === Noskcaj10 is now known as Noskcaj [06:23] smartboyhw, Right now, i'm working with kirkland to fix the translations. I was just letting you know you "missed a spot" [06:23] Noskcaj, OK. Please work with him to fix the translations then:) [06:23] I might be busy these days. I've got a piano exam coming up on the 13th (ABRSM G8) [06:24] ok [06:24] Then if it is approved I will work on doc of another project [06:24] More useful than Testdrive (LOL)( === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === iahmad is now known as iahmad|afk [08:47] good morning all [08:49] knome, ping. Are you there? [09:07] jibel, pitti: adt-virt-lxc ready for review again in https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc/+merge/172856. It assumes cloud-init in the container, and defaults to "ubuntu" as the normal user inside the container. I'm not sure how that sits with merging into Debian. [09:08] But this should be good for testing, and I'd appreciate feedback on that. The catch is that Debian has no LXC template for a container that uses cloud-init, so I'm not sure how useful this will be to Debian right now anyway. [09:08] (though of course Debian users could use Ubuntu containers) [09:09] rbasak: ah, one needs cloud-init for a container? I thought the normal approach would be to debootstrap (I think that's what the templates do) [09:09] rbasak: but thanks for this! we can add some debian/rules magic to only install the backend on ubuntu builds [09:10] pitti: Ubuntu has "ubuntu" and "ubuntu-cloud" templates. "ubuntu" is debootstrap, "ubuntu-cloud" takes a cloud image with cloud-init in it. There's currently no general mechanism for knowing when a container is ready after it has been started, and adt-virt-lxc needs that. cloud-init provides boot-finished, so I'm using hta.t [09:11] hta.t? Left and right hands are out of sync! === iahmad|afk is now known as iahmad [09:11] rbasak: I broke my tongue trying to pronounce it! [09:11] It's only off-by-one :-P [09:13] I suppose I could "adduser autopkgtest" in the container actually. Then it'd be consistent. [09:13] But I still need the boot-finished signal in order to use debootstrapped containers without cloud-init. stgraber and hallyn were talking about some kind of standard mechanism for that. [09:14] But I think it's a bit far away at the moment, and using boot-finished works for now. [09:26] slickymaster, pong [09:28] knome, just a quick question. Remeber that yesterday we spoke about the typo in Xubuntu Docs? [09:28] yes [09:29] knome, well I already branch it and my question is in which file do I correct the typo? in the xml? [09:29] yes, the xml [09:29] anything that is in build/ will be ignored [09:30] knome, the one under xubuntu-docs/desktop-guide/C/ right? [09:30] slickymaster, that's right [09:31] knome, :) thanks. I push it by lunch´ [09:31] I'll [09:31] ok, thanks [09:31] knome, you don't have to thank me [09:47] rbasak: do you know if I can specify a particular boot device in cloud-init? [09:47] rbasak: for supporting nested VMs for jodh I want to pass the original pristine VM as a virtio drive to the "outer" VM, so that within the VM you can start a nested one (with a locally created overlay) [09:48] rbasak: passing that as -drive and building the VM on top of /dev/vdc seems more efficient than wasting memory for copying the VM image into the VM [09:48] rbasak: but sometimes the VM doesn't start up; that could be because it tries to boot from the wrong device, or that cloud-init works on the wrong device [09:50] pitti: good question [09:52] pitti: I'm not entirely sure. Checking with smoser might be an idea. I don't think cloud-init would do anything wrong here, and you should be able to force boot from /dev/vda from the qemu command line I think. But /dev/vdc's filesystem will have the same UUID as /dev/vda's filessytem. So could the initramfs be mounting the wrong root fs? [09:53] rbasak: hm, would it? I'm booting an image with an overlay [09:53] rbasak: oh, how can I force booting from /dev/vda? I was looking for that but didn't find it [09:53] Looking at a cloud image, /etc/fstab defines / as LABEL=cloudimg-rootfs [09:54] rbasak: "-boot order=c" doesn't work [09:54] rbasak: ah, that could be it then [09:54] So I think the initramfs will look for that, and find two filesystems with that label. [09:54] And one is read-only. [09:54] indeed, it boots fine in maybe 50% of the cases [09:55] Perhaps your "outer" VM needs to modify that to /dev/vda and rerun update-initramfs? But then you'll have two images, and hackery. [09:55] rbasak: argh, they indeed both have identical UUIDs and labels [09:55] rbasak: that would be it, thanks [09:55] It's a valid requirement, though. We should provide users with a way to do that. [09:56] rbasak: I'll think about it a bit, how to obfuscate the pristine r/o /dev/vdc enough [09:57] rbasak: the hint about label/uuid was spot-on, cheers [09:57] pitti: I was basing my understanding of boot order definiton upon what I can do from virt-manager, and I know that translates to the command line somehow. Looking at the manpage I assume that -boot order=c should work - now that you agree it's probably the label/uuid, is that consistent with your observations? [09:57] rbasak: in the worst case we have to scp the VM instead of passing it as -drive, it would just waste some 250 MB of RAM [09:58] pitti: how about attaching the disk after the outer guest has booted? [09:58] rbasak: it's a bit hard to see what the outer VM is doing, but it's very well possible that it was booting alright from /dev/vda [09:58] rbasak: it's plausible that the initramfs got confused and mounted the wrong rootfs, or that cloud-image worked on the wrong one, or possibly both [09:59] rbasak: attach after boot> that sounds like a nice trick, how does one do that to a running VM? [09:59] * rbasak looks [09:59] rbasak: I guess over its monitor? [10:00] Yeah [10:00] I'm not sure if you can hotplug a fixed disk like that though. [10:00] I should probably replace -monitor stdio with a named pipe or a bash fd [10:00] But it looks like you can do it for virtual cdrom hardware and USB [10:00] http://en.wikibooks.org/wiki/QEMU/Monitor [10:01] http://www.linux-kvm.org/page/Hotadd_pci_devices [10:01] rbasak: seems SCSI and virtio are fine, just not IDE (but who cares) [10:01] Great! [10:02] rbasak: thanks! [10:02] It still seems a bit hacky though. I'm interested to hear what smoser thinks. I'll send him the log of this as he's not on here. [10:02] No problem. I hope it works! [10:07] knome, As it turns out, the typo isn't present in the offline-packages.xml file. It's in the *.po files that the typo is present, which are the files that contain the translations [10:07] slickymaster, okay. in that case, i should probably update the translations [10:07] knome, I can just go ahead and correct the typos in all of those files [10:08] slickymaster, no need to - it's an automatic process [10:08] knome, okie dokie, I'll leave it in your hands [10:09] * knome tries to get to look at it before he leaves [10:12] rbasak: works nicely! now off to scripting that [10:12] \o/ [10:38] jodh, jibel, rbasak: bug 1158391 updated with a new patch; now with 50% more hacks and stability! [10:38] bug 1158391 in Auto Package Testing "ability to have a DEP-8 test run a test in a separate full system environment" [High,In progress] https://launchpad.net/bugs/1158391 [10:39] pitti, since you had 50% of boot failure, that makes 75% successful boots ;) [10:39] jodh, jibel: as discussed this doesn't yet contain a wrapper script to simplify the qemu-img / qemu run, as jodh potentially wanted to change the image before booting, or put other stuff in between; let's see how much of that we can generalize, and then provide a convenience script as a second step [10:39] jibel: darn, you got me there! rational arithmetic is hard! [10:40] pitti: thanks. Yes, I'm finishing up reworking my scripts to configure the vm on first boot atm... [10:40] jodh: ah, nice; did you run into the boot hangs with the previous patch? [10:41] pitti: alas, never got that far due to issues attempting to do crazy stuff in nbd-mounted chrooted vm images ;) [10:41] jodh: heh, no worries [10:42] jodh: if you are happy (for the first version) with the commands I gave in https://bugs.launchpad.net/auto-package-testing/+bug/1158391/comments/3, I think I can land this now [10:42] Launchpad bug 1158391 in Auto Package Testing "ability to have a DEP-8 test run a test in a separate full system environment" [High,In progress] [10:42] jodh: you'll need to loop over ssh, it'll fail while the sub-vm is still booting up [10:42] pitti: yup - they work for me :) [10:42] jodh: cool [10:43] pitti: yes, I'm building up a library of routines to do "ssh polling" and other such grossities [10:43] jodh: bin/testbed/wait_bootfinished [10:43] pitti: ah! :) [10:43] pitti: you could use a udev rule instead of that polling loop for the pristine_vm hotplug event, but it's probably not worth the effort. [10:43] jodh: that's for prepare-testbed, though, but it might have some overla0p [10:44] rbasak: well, then I'd still need to wait for teh rule to get executed [10:44] pitti: is there a command I can run to install the dep-8 Depends packages in the pristine VM? [10:44] Good point. [10:44] rbasak: I actually want to block run-adt-test until it appears (it's not noticeable anyway), so that we avoid chowning and running the test while it's not there yet [10:45] jodh: adt-run? [10:45] jodh: I guess at some point we'll need the whole run-adt-test machinery in the VM, so that you can use it to attack the nested VM :) [10:45] pitti: the patch looks good to me then [10:45] * pitti is reminded about the "Ship in a bottle" Star Trek NextGen episode [10:45] pitti: ok, so that then would require that I have the dep-8 tests execute conditionally (based on my ADT_ENVIRON_TYPE=nested variable as mentioned the other day). [10:46] pitti: again, works for me :) [10:47] I'm not sure the run-adt-test machinery is the appropriate thing to use inside the VM. But I guess that depends on the amount of reuse. If it's just to start sub-VMs and run stuff in them, then I think we should move that functionality to a more generic tool and put that in cloud-utils in the end. [10:47] jodh: ah right, it's not quite run-adt-test, as we don't want to run the controller script in the child VM again [10:48] jodh: but anyway, adt-run will install test depends; it might not be appropriate for the reason above, so perhaps calling pbuilder-satisfydepends directly is better for that case [10:49] Or just apt-get install? Why do we need the more complex depends syntax here? [10:49] pitti: but I've still got to install pbuilder in the pristine VM right? :) [10:49] jodh: no, these VMs have autopkgtest installed already [10:49] and consequently, pbuilder [10:49] jodh: we build them that way, after all :) [10:50] * jodh really should read the adt scripts at some point ;) [10:50] pitti: I don't think we should rely on that. We shouldn't depend on adt-virt-null any more than we have to. [10:50] jodh: it's the list in bin/prepare-testbed, the cloud-config bit [10:50] jodh: search for "packages:" [10:51] jodh: by pristine VM, do you mean the inner nested one? I think pitti is talking about the outer one. [10:51] rbasak: yes, but we still need adt-run, so our pristine VMs always have to have autopkgtest installed [10:51] rbasak: they are really identical [10:51] except of course we boot the outer one with an (initially empty) writable overlay [10:51] Oh I see. The image has these things preinstalled? [10:51] rbasak: yes, by way of "packages:" in cloud-config [10:52] Then the inner one might use a different cloud-config [10:52] well, at that point we don't generate VMs any more; everything is already instaled [10:53] I'm confused. Can we define some terms? [10:53] we don't actually want cloud-config to go and install required packages at each run; this only happens at "prepare-testbed" (which we run once a day), not for every test [10:53] rbasak: I guess cloud-config will actually consider the config again in the nested VMs, but as the packages are all installed already it has nothing to do [10:54] I see. So you create a new VM daily, use cloud-config to install things, then shut it down again? [10:54] Then you use a clone of that for every test? [10:54] Then you use a clone of that for every package? [10:54] rbasak: yes; we use the generated VM as a read-only backing of a qemu-img generated throwaway overlay [10:54] So that outer VM running the dep8 test will see autopkgtest and auto-package-testing installed. [10:55] And the inner VM started by the outer VM will also have these things preinstalled in its image. [10:55] correct [10:55] OK [10:55] it still uses cloud-init, but it should be mostly a no-op at this point [10:55] at least it's reasonably fast [10:55] Now I think that although these things are true, our tests shouldn't rely on this. [10:55] and I have actually used them while I was offline in a train [10:55] (well, with apt-cacher-ng for the actual tests) [10:56] Since I'd like to see adt-virt-null replaced with adt-virt-kvm eventually, and don't want us to lock in to the current adt-virt-null situation. [10:56] rbasak: well, that's fine; for now we don't promise that much about the child VMs, except that "they boot and you can log in and sudo" [10:56] The reason I don't like it is that by using adt-virt-null we're influencing the test environment in a way that the dep8 spec allows us not to do. [10:56] but it's the case that they are identical to the real autopkgtest VMs [10:56] Right. [10:57] rbasak: right, in particular we cannot currently run "breaks-testbed" tests [10:57] Yep [10:57] So if we want things installed in a dep8 test, we should use a Depends, or for the inner VM manage that part ourselves and make sure it is done. Even if we need autopkgtest and it's there already, since that might go away. [10:57] rbasak: so for now, I think we should let jodh play around with that stuff to get a better feel for what's still missing and how we want to wire this together [10:58] rbasak: yep [10:58] * jodh plays [10:58] OK :) [10:58] * pitti scratches off another item from is "stuff to get done OMGbeforeholidays" [10:58] pitti: thanks for your work! [10:58] rbasak: my pleasure; nice idea with the hotplugging! [10:59] I still don't like it. I've asked smoser for his opinion for when he wakes up. [10:59] jibel: so, mind if I land that and break the world? I'm here until tomorrow evening to deal with regressions/fires, at worst I'll back it out [10:59] I mean it works. It just seems like a workaround for something that ideally shouldn't be necessary. [10:59] rbasak: I can't say I'm that trilled by it, but it's at least efficient and seems to be reliable [11:00] It didn't occur to me that we have to worry about regressions. [11:00] rbasak: yesterday I was considering just scping the image, but you know how long such hacks tend to last [11:00] Perhaps this functionality should be limited to a dep8 Feature? [11:00] rbasak: I mean in the case that VMs suddenly hang or stop booting and we block autopkgtests with that [11:00] pitti, go ahead and break the world, you're on vacations tomorrow, that'll let me a week to fix it :) [11:00] jodh: not tomorrow yet [11:01] err, jibel ^ [11:01] Although atm, the tests still influence each other. With the current setup, it's more of a Feature for the entire test suite of a package, not one indiviual test. [11:10] jodh: assigned bug 1158391 back to you for further input what you would like to see [11:10] bug 1158391 in Auto Package Testing "ability to have a DEP-8 test run a test in a separate full system environment" [High,Confirmed] https://launchpad.net/bugs/1158391 [11:10] pitti: ok, thanks. [11:10] hmm, why is my ADTRESULTSDIR unset ? [11:10] jibel: world duly broken, I'll watch out for autopkgtest failures (well, I do that anyway..) [11:10] thank you === iahmad_ is now known as iahmad === _salem is now known as salem_ [13:19] pitti, rbasak i was reading http://irclogs.ubuntu.com/2013/08/01/%23ubuntu-quality.html#t09:47 [13:20] i dont have an easy way to convince an initramfs to boot off of one out 2 identical drives. [13:20] attach after boot should be fine. [13:21] the other way would be to boot with '-kernel' and '-initramfs' and '-append' with 'root=/dev/vda' [13:21] er.. whatever it was supposed to do (or even root=/dev/by-path/virtio/0/0 or whatever that would be) [13:22] we do boot by label, which is less than ideal, but booting by uuid woudln't even help you here. [13:23] the attach after boot is the cleanest path i think. [13:24] oh, the other thing.. pitti mentioned '250M' [13:24] thats a bad size i think. [13:24] as it implies that you've not uncompressed the qcow image [13:25] which means that all reads tothat disk go through cpu decompression [13:40] rbasak, how could you possibly "flag" that other disk ? [13:41] this really is not cloud specific in any way [13:41] other than being about 6 million times more likely to occur in a cloud [13:42] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/665235 [13:42] Launchpad bug 665235 in Ubuntu on EC2 "grub-legacy-ec2: attaching a volume to maverick instance may boot off it" [Wishlist,Triaged] [13:42] smoser: yeah it's probably an initramfs thing, not a cloud-init thing [13:42] smoser: maybe a way to tell the initramfs/mountall to ignore certain paths? [13:43] I'm not sure how we'd get that message through though. [13:43] well, not really. [13:43] It's sort of circular [13:43] yeah. [13:43] the hardest thing of this is that it is event driven [13:43] the finding of root= [13:44] udev sees it, adds a path, and 'wait-for-root' gets an event and mounts it because that added disk matched criteria [13:44] so you can't say "if i have 2 disks that are the same, then ..." [13:44] because, well, then you'd have to wait around some arbitrary time for the possibility of another disk appearing that matched that criteria [13:45] I'd like to say "/dev/vdc" (or /dev/disk/by-path/...) does not match your criteria. [13:45] Kernel cmdline seems appropriate, but if we can do root=/dev/vda and that works, perhaps that's my answer. [13:45] you can, but thats yucky [13:46] becauase then you have to just "know" the right kernel paramters [13:46] or inspect them. [13:46] Good point [13:46] or i have to publish them (which is only marginally better, but then implies that people *should* do this) [13:47] Anyway, I wondered if there was an easy solution, and/or if we care. Sounds like it's more complicated than it's worth. [13:47] consuming cloud images should not require knowing intimate details about the inconsistency of the linux kernel command line parameter system. [13:47] one option might be to use grub's env area [13:48] or MBR area [13:48] where we would allow reading of the 'root=' param from a well defined location inside the MBR. [13:48] MBR involves modifying the disk image though, at which point we might as well change the label. [13:48] grub woudl have to do it. [13:48] not so much though [13:48] and modifying the label doen'st really help so much as i might move to uuid :) [13:48] Perhaps the BIOS should have a config area for this stuff. [13:49] Doesn't UEFI do something like that? :) [13:49] and modifying the label would break boot of that image! [13:49] your mention of uefi is very relevant. [13:50] OOI, is there a UEFI-supporting qemu model? [13:50] in that MBR is not sufficent as i would ideally hope to sometime in the near future have cloud images that are uefi/mbr dual boot [13:50] yes, there is. [13:50] but thats not rreally any better. [13:50] its just changing the place that you look to use your intrinsic and brittle knowledge. [13:50] you see that bug above ? [13:50] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/665235 [13:50] Launchpad bug 665235 in Ubuntu on EC2 "grub-legacy-ec2: attaching a volume to maverick instance may boot off it" [Wishlist,Triaged] [13:51] that was the first time i went through this thought process :) [13:51] and punted. [13:52] root=/dev/*da1 [13:52] thats what we want :) [13:52] What if virtual machines always used /dev/vda as the root fs, and it was up to [13:52] right [13:52] root=/dev/*da1,LABEL=X [13:52] or uuid [13:52] it was up to the host to make sure that the first disk is first [13:53] oh, shoot. did we lose /dev/disk/by-path ? [13:53] i seem to recall that , and i dont have it here. [13:53] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1193705 [13:53] Launchpad bug 1193705 in systemd (Ubuntu) "[udev] /dev/disk/by-path missing" [Low,Incomplete] [13:53] so that wont be helpful [13:54] btw, cloud-localds needs genisoimage which doesn't recommend or suggest. [13:54] well it doesn't require it. [13:55] also qemu-utils for qemu-img [13:55] in the default use case it needs it [13:55] it does depend on it in saucy i think [13:55] unless i didn't upload [13:56] The problem remains in saucy [13:56] I just started a fresh instance based on a recent daily and upgraded everything [13:56] http://paste.ubuntu.com/5936522/ [13:56] so its in trunk [13:56] OK so it'll get there in the end. No worries :) [13:56] ah. but that iddn't make it to saucy. [13:57] rbasak, so... [13:57] this and your other tool [13:57] that you mentioend [13:57] the dependency creap of cloud-utils scares me [13:57] Yeah I need to finish it all [13:57] And adt-virt-kvm [13:57] Maybe split the package up? [13:57] so my long term plan is to move cloud-localds and some of the other things into [13:57] cloud-image-utils [13:57] or the like [13:57] yeah. [13:57] because you dont likely need genisoimage in your cloud image [13:58] so you're welcome to do that for me :) [13:58] i'd even depend on 'mtools' in cloud-image-utils [13:58] For nested kvm I do :) [13:58] well, that is a very specific use case of a cloud instance. [13:59] not necessarily a incorrect one. just probably not the most common [14:00] the kernel is the other area whwere we end up with feature creep [14:00] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1206961 [14:00] Launchpad bug 1206961 in linux (Ubuntu) "Include rbd and kvm modules in the virtual package" [Undecided,Confirmed] === salem_ is now known as _salem === _salem is now known as salem_ [14:01] that was the motivation for my discussion on dropping 'linux-virtual' and having 'linux-server' and 'linux-generic' where linux-server would include this sort of stuff, but would not include bluetooth and audio drivers. [14:01] anyway. [14:01] Yeah makes sense [14:01] Thanks for the discussion [14:26] smartboyhw, sorry I dozed off before we finished conversing last night it seems :-p check out: http://www.theorangenotebook.com/2013/07/automating-core-apps-how-we-doing.html [14:26] balloons, yeah === sfeole` is now known as sfeole === cr3_ is now known as cr3 === cr3 is now known as Guest98936 === Guest98936 is now known as cr3 [16:08] warm evening [16:17] dkessel, evening to you [16:20] * dkessel has 'run-adt-test' failing silently :/ [16:22] pitti, are you there? can you tell me why run-adt-test is (silently) failing here?: http://paste.ubuntu.com/5936933/ [16:23] hey dkessel [16:23] dkessel: sorry, didn't get to your mail yet [16:23] pitti: oh nvm - i guess i need to download the vm image again after the reboot.... [16:23] * dkessel remembers he had this before... last year [16:23] dkessel: you mean that immediately exits? [16:24] dkessel: I was just about to give your branch a try, but I don't have much time today any mor3e [16:25] pitti: yup, that exits quite immediately [16:25] dkessel: I don't have much experience with running adt-test as user [16:25] i. e. "anything could happen" [16:25] dkessel: nevermind, I mis-looked; it's run-adt-test [16:27] pitti: well if you could find some minutes the other day, that would be great... [16:28] dkessel: does /tmp/adt/disks/pristine-saucy-amd64.img actually exist? [16:28] dkessel: btw, I set BASEDIR=/home/martin-scratch/images/adt in ~/.adtrc, so that I don't keep losing my VMs [16:29] ahhh .adtrc... - yeah that was my problem... it was missing after reboot. thanks [16:31] I also have APTPROXY=http://10.0.2.2:3142 in there, to use apt-cacher-ng [16:31] together with -s, it's a real joy to see download and install taking seconds only :) [16:32] dkessel: I'm running the tests with run-adt-test now; the actual maven tests are running now [16:33] pitti, good hints with the environment variables :) - well let's see if it fails on your system too... [16:33] dkessel: yes, I get the same error [16:41] dkessel: when I run "sudo adt-run --built-tree=. --no-built-binaries --debug --- adt-virt-null" in the unpacked tree (in the VM) I get further [16:41] ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5:compile (default-compile) on project cli: Fatal error compiling: tools.jar not found: /usr/lib/jvm/java-7-openjdk-amd64/jre/../lib/tools.jar [16:42] dkessel: but this downloads from http://repo.jenkins-ci.org, so this would fail in the data center anyway [16:42] dkessel: shouldn't we have all these modules packaged already? [16:43] dkessel: I have absolutely no idea about the original error yet, I'll try to have a look tomorrow [16:43] * pitti waves good night, need to leave [16:43] pitti: night [19:04] balloons ! [19:04] hey m-b-o :-) [19:04] ok, so is autopilot confirmed installed now? [19:05] installing atm [19:05] it's about https://bugs.launchpad.net/ubuntu-weather-app/+bug/1207315 [19:05] Launchpad bug 1207315 in Ubuntu Weather App "Autopilot test failures when run on device" [Undecided,New] [19:05] ahh yes.. I get to look through popey's bugs in a few [19:06] I'm on the device via ssh. So I can start a testrun from there? [19:07] autopilot is now installed [19:08] m-b-o, yes, there's a nice wiki page talking about this. let me pull it up [19:09] got it running :) [19:09] m-b-o, I think this is the page I was looking for: https://wiki.ubuntu.com/QATeam/AutomatedTesting/UbuntuTouch [19:09] UInput: UInputError('"/dev/uinput" cannot be opened for writing',) [19:09] did you use phablet-test-run? [19:09] ballons: thanks! [19:10] autopilot run ubuntu_weather_app [19:11] balloons, HELLO. [19:11] balloons, we need your help :) [19:11] m-b-o, this page too: https://wiki.ubuntu.com/Touch/Testing/Autopilot. But you've got it going so :-) [19:11] balloons, can you re-enable the xubuntu product being visible in packages. ? [19:11] knome, ey-ey capt'n [19:11] ta [19:12] balloons, for me, it says status: active though, so please tell me if i should be able to do that myself [19:12] Xubuntu Desktop has you as owner and still active [19:12] knome, what are you having trouble with/ [19:13] balloons, it doesn't appear in the tracker... [19:13] knome, you should add a build for it.. and a milestone too [19:13] knome, so you can see all the milestones now for saucy.. I have a milestone for each app [19:13] aha... [19:13] you can do the same, or lump all your apps under one milestone [19:14] you see last cycle we had milestones for each testing event [19:14] that's the traditional way of doing it [19:14] how do i control milestones? [19:16] knome, do you have access? it's a tab [19:17] summary products testcases testsuites series builds [19:17] nice.. so you can't set product families or milestones [19:17] >__< [19:17] ok, well, I can. so how would you like it setup? [19:18] yes sad panda [19:18] is there any possibility i can get super cow powers? :P [19:18] look at the xubuntu desktop product - we all have it organized under that [19:18] have you been working with stgraber on the ui stuff? tell him you'd like super cow powers, haha.. he controls the acl's, but again you are already set as owner for xubuntu stuff in packages [19:19] as long as it shows up in the tracker for testing anyway you see it fit, we're happy [19:19] yes, but looks like i can't do much! [19:19] product families are silly.. and milestones can be static [19:19] builds are the most important [19:19] so you want a milestone for xubuntu? called what? [19:20] what are the milestones usually called? [19:20] from there you can edit the builds for apps you want to appear, etc [19:20] if it's the name that's showing up in the tracker frontpage "Xubuntu Desktop" would be good [19:21] this is just over-confusing because you have ten things and the name is the same for al! [19:21] *all [19:21] well step back for a moment from the craziness that is the package tracker. the iso tracker has milestones you know. saucy daily, saucy alpha 1, saucy beta, saucy final [19:22] historically the package tracker followed this line of thinking and name milestones for each testing event. So if we had a testing week, that was a milestone. If we had a specific call for testing, that was a milestone [19:22] generally, do you do multiple milestones for packages? [19:22] now, we've eschewed that and have milestones for the entire cycle; a bit like the dailies [19:23] right [19:23] perhaps we should push our thoughts a bit more on this [19:23] then the milestone should be called Saucy [19:23] make a proper daily milestone, add product families for apps, add slot things accordingly [19:23] yes... [19:23] oh please yes [19:23] lol.. iterations my friend.. [19:24] that seems to make a lot of sense. I think it's definitely worthy of a mockup [19:24] we can use the test site to do a quick trial run of how it could look [19:25] sure [19:25] let me turn up my desktop machine, this chair isn't comfortable [19:25] turn on too [19:26] http://packages.qa.dev.stgraber.org/ [19:28] knome, forgive me, but your getting some ubuntu packages assigned to xubuntu for test purposes :-p\ [19:28] fffst [19:28] ;) [19:28] you = xubuntu [19:29] basically, we have testsuites like "Xubuntu Office" [19:29] and "Xfce" [19:29] which contain several testcases, like Abiword, Gnumeric, ... [19:30] I'm a visual person, so let's start here and iterate ;-) [19:30] then we have the Xubuntu Desktop product [19:30]