[03:32] <smartboyhw> Noskcaj, ping
[03:46] <smartboyhw> Noskcaj10, ping
[04:17] <balloons> Noskcaj10, tests are fully synced to rev189
[04:18] <smartboyhw> Hey hey balloons
[04:18] <balloons> goodnight smartboyhw :-p
[04:18] <smartboyhw> LOL
[04:18] <balloons> ROFL!
[04:18] <balloons> I win!
[04:18] <smartboyhw> balloons, meh:(
[04:18] <balloons> how are you?
[04:18] <balloons> I'll stay for a min :-)
[04:18] <smartboyhw> balloons, great:)
[04:19] <balloons> how was your trip? find the UK interesting?
[04:19] <smartboyhw> balloons, which autopilot tests would you recommend me to touch on? (Since many are completed it seems) and UK is great!
[04:49] <pitti> Good morning
[06:19] <Noskcaj10> smartboyhw, pong, i was at school
[06:19] <smartboyhw> 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
[06:23] <Noskcaj> smartboyhw, Right now, i'm working with kirkland to fix the translations. I was just letting you know you "missed a spot"
[06:23] <smartboyhw> Noskcaj, OK. Please work with him to fix the translations then:)
[06:23] <smartboyhw> I might be busy these days. I've got a piano exam coming up on the 13th (ABRSM G8)
[06:24] <Noskcaj> ok
[06:24] <smartboyhw> Then if it is approved I will work on doc of another project
[06:24] <smartboyhw> More useful than Testdrive (LOL)(
[08:47] <slickymaster> good morning all
[08:49] <slickymaster> knome, ping. Are you there?
[09:07] <rbasak> 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] <rbasak> 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] <rbasak> (though of course Debian users could use Ubuntu containers)
[09:09] <pitti> 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] <pitti> rbasak: but thanks for this! we can add some debian/rules magic to only install the backend on ubuntu builds
[09:10] <rbasak> 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] <rbasak> hta.t? Left and right hands are out of sync!
[09:11] <pitti> rbasak: I broke my tongue trying to pronounce it!
[09:11] <rbasak> It's only off-by-one :-P
[09:13] <rbasak> I suppose I could "adduser autopkgtest" in the container actually. Then it'd be consistent.
[09:13] <rbasak> 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] <rbasak> But I think it's a bit far away at the moment, and using boot-finished works for now.
[09:26] <knome> slickymaster, pong
[09:28] <slickymaster> knome, just a quick question. Remeber that yesterday we spoke about the typo in Xubuntu Docs?
[09:28] <knome> yes
[09:29] <slickymaster> knome, well I already branch it and my question is in which file do I correct the typo? in the xml?
[09:29] <knome> yes, the xml
[09:29] <knome> anything that is in build/ will be ignored
[09:30] <slickymaster> knome, the one under xubuntu-docs/desktop-guide/C/ right?
[09:30] <knome> slickymaster, that's right
[09:31] <slickymaster> knome, :) thanks. I push it by lunch´
[09:31] <slickymaster> I'll
[09:31] <knome> ok, thanks
[09:31] <slickymaster> knome, you don't have to thank me
[09:47] <pitti> rbasak: do you know if I can specify a particular boot device in cloud-init?
[09:47] <pitti> 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] <pitti> 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] <pitti> 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] <rbasak> pitti: good question
[09:52] <rbasak> 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] <pitti> rbasak: hm, would it? I'm booting an image with an overlay
[09:53] <pitti> rbasak: oh, how can I force booting from /dev/vda? I was looking for that but didn't find it
[09:53] <rbasak> Looking at a cloud image, /etc/fstab defines / as LABEL=cloudimg-rootfs
[09:54] <pitti> rbasak: "-boot order=c" doesn't work
[09:54] <pitti> rbasak: ah, that could be it then
[09:54] <rbasak> So I think the initramfs will look for that, and find two filesystems with that label.
[09:54] <rbasak> And one is read-only.
[09:54] <pitti> indeed, it boots fine in maybe 50% of the cases
[09:55] <rbasak> 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] <pitti> rbasak: argh, they indeed both have identical UUIDs and labels
[09:55] <pitti> rbasak: that would be it, thanks
[09:55] <rbasak> It's a valid requirement, though. We should provide users with a way to do that.
[09:56] <pitti> rbasak: I'll think about it a bit, how to obfuscate the pristine r/o /dev/vdc enough
[09:57] <pitti> rbasak: the hint about label/uuid was spot-on, cheers
[09:57] <rbasak> 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] <pitti> 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] <rbasak> pitti: how about attaching the disk after the outer guest has booted?
[09:58] <pitti> 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] <pitti> 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] <pitti> 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] <pitti> rbasak: I guess over its monitor?
[10:00] <rbasak> Yeah
[10:00] <rbasak> I'm not sure if you can hotplug a fixed disk like that though.
[10:00] <pitti> I should probably replace -monitor stdio with a named pipe or a bash fd
[10:00] <rbasak> But it looks like you can do it for virtual cdrom hardware and USB
[10:00] <rbasak> http://en.wikibooks.org/wiki/QEMU/Monitor
[10:01] <pitti> http://www.linux-kvm.org/page/Hotadd_pci_devices
[10:01] <pitti> rbasak: seems SCSI and virtio are fine, just not IDE (but who cares)
[10:01] <rbasak> Great!
[10:02] <pitti> rbasak: thanks!
[10:02] <rbasak> 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] <rbasak> No problem. I hope it works!
[10:07] <slickymaster> 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] <knome> slickymaster, okay. in that case, i should probably update the translations
[10:07] <slickymaster> knome, I can just go ahead and correct the typos in all of those files
[10:08] <knome> slickymaster, no need to - it's an automatic process
[10:08] <slickymaster> 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] <pitti> rbasak: works nicely! now off to scripting that
[10:12] <rbasak> \o/
[10:38] <pitti> jodh, jibel, rbasak: bug 1158391 updated with a new patch; now with 50% more hacks and stability!
[10:39] <jibel> pitti, since you had 50% of boot failure, that makes 75% successful boots ;)
[10:39] <pitti> 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] <pitti> jibel: darn, you got me there! rational arithmetic is hard!
[10:40] <jodh> pitti: thanks. Yes, I'm finishing up reworking my scripts to configure the vm on first boot atm...
[10:40] <pitti> jodh: ah, nice; did you run into the boot hangs with the previous patch?
[10:41] <jodh> pitti: alas, never got that far due to issues attempting to do crazy stuff in nbd-mounted chrooted vm images ;)
[10:41] <pitti> jodh: heh, no worries
[10:42] <pitti> 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] <pitti> jodh: you'll need to loop over ssh, it'll fail while the sub-vm is still booting up
[10:42] <jodh> pitti: yup - they work for me :)
[10:42] <pitti> jodh: cool
[10:43] <jodh> pitti: yes, I'm building up a library of routines to do "ssh polling" and other such grossities
[10:43] <pitti> jodh: bin/testbed/wait_bootfinished
[10:43] <jodh> pitti: ah! :)
[10:43] <rbasak> 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] <pitti> jodh: that's for prepare-testbed, though, but it might have some overla0p
[10:44] <pitti> rbasak: well, then I'd still need to wait for teh rule to get executed
[10:44] <jodh> pitti: is there a command I can run to install the dep-8 Depends packages in the pristine VM?
[10:44] <rbasak> Good point.
[10:44] <pitti> 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] <pitti> jodh: adt-run?
[10:45] <pitti> 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] <rbasak> 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] <jodh> 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] <jodh> pitti: again, works for me :)
[10:47] <rbasak> 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] <pitti> 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] <pitti> 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] <rbasak> Or just apt-get install? Why do we need the more complex depends syntax here?
[10:49] <jodh> pitti: but I've still got to install pbuilder in the pristine VM right? :)
[10:49] <pitti> jodh: no, these VMs have autopkgtest installed already
[10:49] <pitti> and consequently, pbuilder
[10:49] <pitti> jodh: we build them that way, after all :)
[10:50]  * jodh really should read the adt scripts at some point ;)
[10:50] <rbasak> 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] <pitti> jodh: it's the list in bin/prepare-testbed, the cloud-config bit
[10:50] <pitti> jodh: search for "packages:"
[10:51] <rbasak> jodh: by pristine VM, do you mean the inner nested one? I think pitti is talking about the outer one.
[10:51] <pitti> rbasak: yes, but we still need adt-run, so our pristine VMs always have to have autopkgtest installed
[10:51] <pitti> rbasak: they are really identical
[10:51] <pitti> except of course we boot the outer one with an (initially empty) writable overlay
[10:51] <rbasak> Oh I see. The image has these things preinstalled?
[10:51] <pitti> rbasak: yes, by way of "packages:" in cloud-config
[10:52] <rbasak> Then the inner one might use a different cloud-config
[10:52] <pitti> well, at that point we don't generate VMs any more; everything is already instaled
[10:53] <rbasak> I'm confused. Can we define some terms?
[10:53] <pitti> 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] <pitti> 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] <rbasak> I see. So you create a new VM daily, use cloud-config to install things, then shut it down again?
[10:54] <rbasak> Then you use a clone of that for every test?
[10:54] <rbasak> Then you use a clone of that for every package?
[10:54] <pitti> rbasak: yes; we use the generated VM as a read-only backing of a qemu-img generated throwaway overlay
[10:54] <rbasak> So that outer VM running the dep8 test will see autopkgtest and auto-package-testing installed.
[10:55] <rbasak> And the inner VM started by the outer VM will also have these things preinstalled in its image.
[10:55] <pitti> correct
[10:55] <rbasak> OK
[10:55] <pitti> it still uses cloud-init, but it should be mostly a no-op at this point
[10:55] <pitti> at least it's reasonably fast
[10:55] <rbasak> Now I think that although these things are true, our tests shouldn't rely on this.
[10:55] <pitti> and I have actually used them while I was offline in a train
[10:55] <pitti> (well, with apt-cacher-ng for the actual tests)
[10:56] <rbasak> 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] <pitti> 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] <rbasak> 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] <pitti> but it's the case that they are identical to the real autopkgtest VMs
[10:56] <rbasak> Right.
[10:57] <pitti> rbasak: right, in particular we cannot currently run "breaks-testbed" tests
[10:57] <rbasak> Yep
[10:57] <rbasak> 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] <pitti> 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] <pitti> rbasak: yep
[10:58]  * jodh plays
[10:58] <rbasak> OK :)
[10:58]  * pitti scratches off another item from is "stuff to get done OMGbeforeholidays"
[10:58] <rbasak> pitti: thanks for your work!
[10:58] <pitti> rbasak: my pleasure; nice idea with the hotplugging!
[10:59] <rbasak> I still don't like it. I've asked smoser for his opinion for when he wakes up.
[10:59] <pitti> 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] <rbasak> I mean it works. It just seems like a workaround for something that ideally shouldn't be necessary.
[10:59] <pitti> rbasak: I can't say I'm that trilled by it, but it's at least efficient and seems to be reliable
[11:00] <rbasak> It didn't occur to me that we have to worry about regressions.
[11:00] <pitti> rbasak: yesterday I was considering just scping the image, but you know how long such hacks tend to last
[11:00] <rbasak> Perhaps this functionality should be limited to a dep8 Feature?
[11:00] <pitti> rbasak: I mean in the case that VMs suddenly hang or stop booting and we block autopkgtests with that
[11:00] <jibel> pitti, go ahead and break the world, you're on vacations tomorrow, that'll let me a week to fix it :)
[11:00] <pitti> jodh: not tomorrow yet
[11:01] <pitti> err, jibel ^
[11:01] <rbasak> 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] <pitti> jodh: assigned bug 1158391 back to you for further input what you would like to see
[11:10] <jodh> pitti: ok, thanks.
[11:10] <jodh> hmm, why is my ADTRESULTSDIR unset ?
[11:10] <pitti> jibel: world duly broken, I'll watch out for autopkgtest failures (well, I do that anyway..)
[11:10] <jibel> thank you
[13:19] <smoser> pitti, rbasak i was reading http://irclogs.ubuntu.com/2013/08/01/%23ubuntu-quality.html#t09:47
[13:20] <smoser> i dont have an easy way to convince an initramfs to boot off of one out 2 identical drives.
[13:20] <smoser> attach after boot  should be fine.
[13:21] <smoser> the other way would be to boot with '-kernel' and '-initramfs' and '-append' with 'root=/dev/vda'
[13:21] <smoser> er.. whatever it was supposed to do (or even root=/dev/by-path/virtio/0/0 or whatever that would be)
[13:22] <smoser> we do boot by label, which is less than ideal, but booting by uuid woudln't even help you here.
[13:23] <smoser> the attach after boot is the cleanest path i think.
[13:24] <smoser> oh, the other thing.. pitti mentioned '250M'
[13:24] <smoser> thats a bad size i think.
[13:24] <smoser> as it implies that you've not uncompressed the qcow image
[13:25] <smoser> which means that all reads tothat disk go through cpu decompression
[13:40] <smoser> rbasak, how could you possibly "flag" that other disk ?
[13:41] <smoser> this really is not cloud specific in any way
[13:41] <smoser> other than being about 6 million times more likely to occur in a cloud
[13:42] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/665235
[13:42] <rbasak> smoser: yeah it's probably an initramfs thing, not a cloud-init thing
[13:42] <rbasak> smoser: maybe a way to tell the initramfs/mountall to ignore certain paths?
[13:43] <rbasak> I'm not sure how we'd get that message through though.
[13:43] <smoser> well, not really.
[13:43] <rbasak> It's sort of circular
[13:43] <smoser> yeah.
[13:43] <smoser> the hardest thing of this is that it is event driven
[13:43] <smoser> the finding of root=
[13:44] <smoser> udev sees it, adds a path, and 'wait-for-root' gets an event and mounts it because that added disk matched criteria
[13:44] <smoser> so you can't say "if i have 2 disks that are the same, then ..."
[13:44] <smoser> 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] <rbasak> I'd like to say "/dev/vdc" (or /dev/disk/by-path/...) does not match your criteria.
[13:45] <rbasak> Kernel cmdline seems appropriate, but if we can do root=/dev/vda and that works, perhaps that's my answer.
[13:45] <smoser> you can, but thats yucky
[13:46] <smoser> becauase then you have to just "know" the right kernel paramters
[13:46] <smoser> or inspect them.
[13:46] <rbasak> Good point
[13:46] <smoser> or i have to publish them (which is only marginally better, but then implies that people *should* do this)
[13:47] <rbasak> 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] <smoser> consuming cloud images should not require knowing intimate details about the inconsistency of the linux kernel command line parameter system.
[13:47] <smoser> one option might be to use grub's env area
[13:48] <smoser> or MBR area
[13:48] <smoser> where we would allow reading of the 'root=' param from a well defined location inside the MBR.
[13:48] <rbasak> MBR involves modifying the disk image though, at which point we might as well change the label.
[13:48] <smoser> grub woudl have to do it.
[13:48] <smoser> not so much though
[13:48] <smoser> and modifying the label doen'st really help so much as i might move to uuid :)
[13:48] <rbasak> Perhaps the BIOS should have a config area for this stuff.
[13:49] <rbasak> Doesn't UEFI do something like that? :)
[13:49] <smoser> and modifying the label would break boot of that image!
[13:49] <smoser> your mention of uefi is very relevant.
[13:50] <rbasak> OOI, is there a UEFI-supporting qemu model?
[13:50] <smoser> 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] <smoser> yes, there is.
[13:50] <smoser> but thats not rreally any better.
[13:50] <smoser> its just changing the place that you look to use your intrinsic and brittle knowledge.
[13:50] <smoser> you see that bug above ?
[13:50] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/665235
[13:51] <smoser> that was the first time i went through this thought process :)
[13:51] <smoser> and punted.
[13:52] <smoser> root=/dev/*da1
[13:52] <smoser> thats what we want :)
[13:52] <rbasak> What if virtual machines always used /dev/vda as the root fs, and it was up to
[13:52] <rbasak> right
[13:52] <smoser> root=/dev/*da1,LABEL=X
[13:52] <smoser> or uuid
[13:52] <rbasak> it was up to the host to make sure that the first disk is first
[13:53] <smoser> oh, shoot. did we lose /dev/disk/by-path ?
[13:53] <smoser> i seem to recall that , and i dont have it here.
[13:53] <smoser> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1193705
[13:53] <smoser> so that wont be helpful
[13:54] <rbasak> btw, cloud-localds needs genisoimage which doesn't recommend or suggest.
[13:54] <smoser> well it doesn't require it.
[13:55] <rbasak> also qemu-utils for qemu-img
[13:55] <rbasak> in the default use case it needs it
[13:55] <smoser> it does depend on it in saucy i think
[13:55] <smoser> unless i didn't upload
[13:56] <rbasak> The problem remains in saucy
[13:56] <rbasak> I just started a fresh instance based on a recent daily and upgraded everything
[13:56] <smoser> http://paste.ubuntu.com/5936522/
[13:56] <smoser> so its in trunk
[13:56] <rbasak> OK so it'll get there in the end. No worries :)
[13:56] <smoser> ah. but that iddn't make it to saucy.
[13:57] <smoser> rbasak, so...
[13:57] <smoser> this and your other tool
[13:57] <smoser> that you  mentioend
[13:57] <smoser> the dependency creap of cloud-utils scares me
[13:57] <rbasak> Yeah I need to finish it all
[13:57] <rbasak> And adt-virt-kvm
[13:57] <rbasak> Maybe split the package up?
[13:57] <smoser> so my long term plan is to move cloud-localds and some of the other things into
[13:57] <smoser> cloud-image-utils
[13:57] <smoser> or the like
[13:57] <smoser> yeah.
[13:57] <smoser> because you dont likely need genisoimage in your cloud image
[13:58] <smoser> so you're welcome to do that for me :)
[13:58] <smoser> i'd even depend on 'mtools' in cloud-image-utils
[13:58] <rbasak> For nested kvm I do :)
[13:58] <smoser> well, that is a very specific use case of a cloud instance.
[13:59] <smoser> not necessarily a incorrect one. just probably not the most common
[14:00] <smoser> the kernel is the other area whwere we end up with feature creep
[14:00] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1206961
[14:01] <smoser> 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] <smoser> anyway.
[14:01] <rbasak> Yeah makes sense
[14:01] <rbasak> Thanks for the discussion
[14:26] <balloons> 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] <smartboyhw> balloons, yeah
[16:08] <dkessel> warm evening
[16:17] <balloons> dkessel, evening to you
[16:20]  * dkessel has 'run-adt-test' failing silently :/
[16:22] <dkessel> pitti, are you there? can you tell me why run-adt-test is (silently) failing here?: http://paste.ubuntu.com/5936933/
[16:23] <pitti> hey dkessel
[16:23] <pitti> dkessel: sorry, didn't get to your mail yet
[16:23] <dkessel> 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] <pitti> dkessel: you mean that immediately exits?
[16:24] <pitti> dkessel: I was just about to give your branch a try, but I don't have much time today any mor3e
[16:25] <dkessel> pitti: yup, that exits quite immediately
[16:25] <pitti> dkessel: I don't have much experience with running adt-test as user
[16:25] <pitti> i. e. "anything could happen"
[16:25] <pitti> dkessel: nevermind, I mis-looked; it's run-adt-test
[16:27] <dkessel> pitti: well if you could find some minutes the other day, that would be great...
[16:28] <pitti> dkessel: does /tmp/adt/disks/pristine-saucy-amd64.img actually exist?
[16:28] <pitti> dkessel: btw, I set BASEDIR=/home/martin-scratch/images/adt in ~/.adtrc, so that I don't keep losing my VMs
[16:29] <dkessel> ahhh .adtrc... - yeah that was my problem... it was missing after reboot. thanks
[16:31] <pitti> I also have APTPROXY=http://10.0.2.2:3142 in there, to use apt-cacher-ng
[16:31] <pitti> together with -s, it's a real joy to see download and install taking seconds only :)
[16:32] <pitti> dkessel: I'm running the tests with run-adt-test now; the actual maven tests are running now
[16:33] <dkessel> pitti, good hints with the environment variables :) - well let's see if it fails on your system too...
[16:33] <pitti> dkessel: yes, I get the same error
[16:41] <pitti> 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] <pitti> 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] <pitti> dkessel: but this downloads from http://repo.jenkins-ci.org, so this would fail in the data center anyway
[16:42] <pitti> dkessel: shouldn't we have all these modules packaged already?
[16:43] <pitti> 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] <dkessel> pitti: night
[19:04] <m-b-o> balloons !
[19:04] <balloons> hey m-b-o :-)
[19:04] <balloons> ok, so is autopilot confirmed installed now?
[19:05] <m-b-o> installing atm
[19:05] <m-b-o> it's about https://bugs.launchpad.net/ubuntu-weather-app/+bug/1207315
[19:05] <balloons> ahh yes.. I get to look through popey's bugs in a few
[19:06] <m-b-o> I'm on the device via ssh. So I can start a testrun from there?
[19:07] <m-b-o> autopilot is now installed
[19:08] <balloons> m-b-o, yes, there's a nice wiki page talking about this. let me pull it up
[19:09] <m-b-o> got it running :)
[19:09] <balloons> m-b-o, I think this is the page I was looking for: https://wiki.ubuntu.com/QATeam/AutomatedTesting/UbuntuTouch
[19:09] <m-b-o> UInput: UInputError('"/dev/uinput" cannot be opened for writing',)
[19:09] <balloons> did you use phablet-test-run?
[19:09] <m-b-o> ballons: thanks!
[19:10] <m-b-o> autopilot run ubuntu_weather_app
[19:11] <knome> balloons, HELLO.
[19:11] <knome> balloons, we need your help :)
[19:11] <balloons> m-b-o, this page too: https://wiki.ubuntu.com/Touch/Testing/Autopilot. But you've got it going so :-)
[19:11] <knome> balloons, can you re-enable the xubuntu product being visible in packages. ?
[19:11] <balloons> knome, ey-ey capt'n
[19:11] <knome> ta
[19:12] <knome> balloons, for me, it says status: active though, so please tell me if i should be able to do that myself
[19:12] <balloons> Xubuntu Desktop has you as owner and still active
[19:12] <balloons> knome, what are you having trouble with/
[19:13] <knome> balloons, it doesn't appear in the tracker...
[19:13] <balloons> knome, you should add a build for it.. and a milestone too
[19:13] <balloons> knome, so you can see all the milestones now for saucy.. I have a milestone for each app
[19:13] <knome> aha...
[19:13] <balloons> you can do the same, or lump all your apps under one milestone
[19:14] <balloons> you see last cycle we had milestones for each testing event
[19:14] <balloons> that's the traditional way of doing it
[19:14] <knome> how do i control milestones?
[19:16] <balloons> knome, do you have access? it's  a tab
[19:17] <knome> summary products testcases testsuites series builds
[19:17] <balloons> nice.. so you can't set product families or milestones
[19:17] <knome> >__<
[19:17] <balloons> ok, well, I can. so how would you like it setup?
[19:18] <balloons> yes sad panda
[19:18] <knome> is there any possibility i can get super cow powers? :P
[19:18] <knome> look at the xubuntu desktop product - we all have it organized under that
[19:18] <balloons> 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] <knome> as long as it shows up in the tracker for testing anyway you see it fit, we're happy
[19:19] <knome> yes, but looks like i can't do much!
[19:19] <balloons> product families are silly.. and milestones can be static
[19:19] <balloons> builds are the most important
[19:19] <balloons> so you want a milestone for xubuntu? called what?
[19:20] <knome> what are the milestones usually called?
[19:20] <balloons> from there you can edit the builds for apps you want to appear, etc
[19:20] <knome> if it's the name that's showing up in the tracker frontpage "Xubuntu Desktop" would be good
[19:21] <knome> this is just over-confusing because you have ten things and the name is the same for al!
[19:21] <knome> *all
[19:21] <balloons> 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] <balloons> 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] <knome> generally, do you do multiple milestones for packages?
[19:22] <balloons> now, we've eschewed that and have milestones for the entire cycle; a bit like the dailies
[19:23] <knome> right
[19:23] <balloons> perhaps we should push our thoughts a bit more on this
[19:23] <knome> then the milestone should be called Saucy
[19:23] <balloons> make a proper daily milestone, add product families for apps, add slot things accordingly
[19:23] <knome> yes...
[19:23] <knome> oh please yes
[19:23] <balloons> lol.. iterations my friend..
[19:24] <balloons> that seems to make a lot of sense. I think it's definitely worthy of a mockup
[19:24] <balloons> we can use the test site to do a quick trial run of how it could look
[19:25] <knome> sure
[19:25] <knome> let me turn up my desktop machine, this chair isn't comfortable
[19:25] <knome> turn on too
[19:26] <balloons> http://packages.qa.dev.stgraber.org/
[19:28] <balloons> knome, forgive me, but your getting some ubuntu packages assigned to xubuntu for test purposes :-p\
[19:28] <knome> fffst
[19:28] <knome> ;)
[19:28] <balloons> you = xubuntu
[19:29] <knome> basically, we have testsuites like "Xubuntu Office"
[19:29] <knome> and "Xfce"
[19:29] <knome> which contain several testcases, like Abiword, Gnumeric, ...
[19:30] <balloons> I'm a visual person, so let's start here and iterate ;-)
[19:30] <knome> then we have the Xubuntu Desktop product
[19:30] <knome> let me get my head around it
[19:31] <balloons> ok, it's coming together here: http://packages.qa.dev.stgraber.org/qatracker/milestones/254/builds
[19:31] <balloons> ok, so the basic layout is setup now
[19:32] <knome> except the products shouldn't be named by apps
[19:32] <knome> that doesn't make sense for me
[19:32] <knome> if one app has one testcase, it should just be shown as a testcase, not have a testsuite named by it
[19:34] <knome> i think the xfce testsuite is the easiest
[19:34] <knome> we clearly have a lot of different small components for it
[19:34] <knome> and they share the xfce testsuite
[19:34] <knome> in the same way, firefox and thunderbird should be in a "xubuntu internet" testsuite
[19:34] <knome> does that make sense to you?
[19:38] <knome> balloons, ^
[19:38] <balloons> I'm swapping channels at the moment, and thinking :-)
[19:39] <balloons> so can we roll back for one moment
[19:39] <knome> sure.
[19:39] <balloons> what your describing is not possible atm
[19:39] <knome> why not?
[19:39] <knome> it clearly seems possible
[19:39] <balloons> if I understand properly.. but it might be
[19:39] <balloons> hence, roll back
[19:39] <balloons> haha
[19:39] <knome> just don't name the testuite "firefox"
[19:39] <balloons> so, does what is on the page make sense?
[19:40] <knome> anything that doesn't make sense is: http://packages.qa.dev.stgraber.org/qatracker/milestones/254/builds
[19:40] <knome> in the xubuntu product, we'd like to have subitems like "Xubuntu Office"
[19:40] <knome> (which would then have testsuites like abiword and gnumeric)
[19:40] <balloons> right, but those are the products being listed
[19:40] <knome> huh?
[19:40] <balloons> fileroller is a product
[19:40] <balloons> i made it a part of the xubuntu family
[19:40] <knome> in that case... where are the testsuites?
[19:41] <balloons> click the product, aka fileroller
[19:41] <balloons> and then the testsuites are listed
[19:41] <knome> right
[19:41] <knome> i see...
[19:41] <balloons> SO, you could make a internet xubuntu product
[19:41] <knome> well no, it's fine if the product is "Xubuntu Desktop"
[19:41] <balloons> Ill try mocking up one as you say
[19:41] <balloons> ohh.. your ok now?
[19:42] <knome> that's just *one level* of duplicating things
[19:42] <knome> yeah, i don't see families, so...
[19:42] <balloons> ok, so what should I tweak?
[19:44] <knome> in http://packages.qa.ubuntu.com/, no "Xubuntu" shows up
[19:44] <knome> if you could add a Xubutnu family (and add the "Xubuntu Desktop" product to that) and make it show up, i'd be happy
[19:46] <balloons> knome, well I want to keep pursing your ideas in the sanbox
[19:46] <balloons> so as the sandbox stands should we make changes?
[19:46] <knome> balloons, let me try to get my head around it again :D
[19:46] <balloons> make a xubuntu internet product family and list products under it?
[19:47] <balloons> make a xubuntu internet product in the xubuntu product family, and add firefox etc testsuites to it?
[19:47] <knome> so, the milestone would be "Saucy Daily" - that's good
[19:47] <balloons> knome, yea, we could choose something like that
[19:47] <balloons> hey Noskcaj join in the fun :-)
[19:47] <knome> no when i click that...
[19:47] <balloons> we're brainstorming on how we layout packages.qa.u.com
[19:47] <knome> can you explain two things:
[19:47] <Noskcaj> ok
[19:47] <knome> 1) what's the products filter on the left
[19:47] <knome> 2) what's the subtitles (table cells with dark bg)?
[19:47] <balloons> Letozaf_, hello to you also :-) I have good news.. adding a feed works again in rss reader
[19:48] <balloons> product filters are product families
[19:48] <Letozaf_> balloons, hello
[19:48] <balloons> they are the same as the table subtitles
[19:48] <Letozaf_> balloons, good
[19:48] <balloons> Product (Xubuntu) is a product family
[19:49] <balloons> under Product (Xubuntu), you see fileroller. that is a product, assigned to the xubuntu product family
[19:49] <knome> balloons, ok, so...
[19:49] <Letozaf_> balloons, I have done the swipe thing, but it doesn't work, can you have a look at it, it swipes on the top left side of the screen instead on the topic
[19:49] <knome> balloons, would it make sense that the product families were flavor names?
[19:49] <balloons> Letozaf_, sure send along the source
[19:50] <Letozaf_> balloons, ok, just a minute
[19:50] <balloons> knome, in the iso world that is how it's done. here, well that depends :-)
[19:50] <balloons> I just set it up to be a clone of how iso.qa.ubuntu.com is done
[19:50] <balloons> we should iterate and tweak from there
[19:51] <knome> balloons, i would do as we do it in ISO, to not confuse people
[19:51] <knome> when we refer to "product family", it should always be clear what we are referring to
[19:51] <Letozaf_> balloons, https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/checkswipe
[19:51] <knome> balloons, so yeah, the product families should be flavor names
[19:52] <knome> balloons, then, the product should be "Xubuntu Desktop" for example
[19:52] <balloons> ok, fair enough. Now, did you want to mess with the products themselves? in the iso world a product is an image
[19:52] <balloons> in the packages world a product is a package
[19:52] <knome> balloons, will autopilot tests show up in packages. too ?
[19:52] <balloons> knome, what do you mean show up? not by default no
[19:53] <knome> balloons, where are the autopilot tests reported+
[19:53] <knome> ?
[19:53] <balloons> we could setup something to push autopilot results to the tracker it's been done in the past
[19:53] <balloons> autopilot results are pushed to jenkins
[19:53] <balloons> depending on the test, it's spread around various jenkins instances
[19:53] <Letozaf_>  balloons it's in the test_remove_topic test
[19:53] <balloons> the idea is the qa dashboard should be the source for all the data
[19:54] <knome> balloons, would it make sense if the products were called "Xubuntu manual tests" ?
[19:54] <balloons> knome, so in theory you should see the collated results here: http://reports.qa.ubuntu.com/
[19:54] <knome> etc...
[19:54]  * Letozaf_ is doing an apt-get update and dist-upgrade
[19:55]  * Letozaf_ got the rssreader updates :)
[19:55]  * balloons checking
[19:55] <balloons> if you got the updates, feel free to push that new branch up :-)
[19:56] <balloons> Letozaf_, the branch seems to be missing the test_.py file?
[19:56] <Letozaf_> balloons, argh!! let me check
[19:56] <balloons> Letozaf_, lol.. no worries..
[19:56] <balloons> just bzr add if needed.. it's weird it's missing
[19:57] <Letozaf_> balloons, yes it's weired, I see other missing files though
[19:57] <knome> balloons, huh? :P
[19:57] <Letozaf_> balloons, let me push it againg with another name
[19:58] <balloons> knome, umm hmm.. xubuntu manual tests
[19:58] <knome> balloons, yes - that would avoid calling two levels with the same title
[19:58] <balloons> I could see that.. I don't think it would bother me at all..
[19:58] <balloons> knome, which 2 levels are the same now?
[19:58] <knome> balloons, product, testsuite, testcase :P
[19:58] <knome> balloons, THREE!
[19:59] <balloons> manual tests is a bit redudant as every product family would have it
[19:59] <knome> balloons, sure. but it's redundant to have a product called fileroller, with one testsuite called fileroller, with one testcase called fileroller
[19:59] <balloons> knome, let me try adding your other idea
[19:59] <balloons> i'll just play around and push things to that page :-)
[20:00] <knome> sure
[20:01] <balloons> knome, ok I added xubuntu office a couple ways
[20:01] <balloons> refresh and have a look
[20:02] <balloons> one under xubuntu product family and one as it's own product family
[20:02] <knome> the one under makes more sense to me
[20:02] <knome> so in http://packages.qa.dev.stgraber.org/qatracker/milestones/254/builds/27971/testcases, what are the table headers?
[20:02] <balloons> testsuites
[20:02] <knome> wjat
[20:03] <Letozaf_> balloons, this is strange, I did this:  bzr push lp:~carla-sella/ubuntu-rssreader-app/anotherSwipeCnt
[20:03] <knome> ... what's the xubuntu office then? product?
[20:03] <Letozaf_> balloons, and got this output: Using default stacking branch /+branch-id/717401 at chroot-68486096:///~carla-sella/ubuntu-rssreader-app/
[20:03] <Letozaf_> Created new stacked branch referring to /+branch-id/717401.
[20:03] <balloons> Letozaf_, that looks fine.. right? it made a new branch.. you could have push to your original
[20:04] <balloons> knome, we can change the names, lol.. i'm just trying to point out how the data is structed and how you can play with it
[20:04] <Letozaf_> balloons, oh yes ... missed a refresh of my browser :p
[20:04] <knome> balloons, let me open a pad :P
[20:04] <balloons> k
[20:04] <Letozaf_> balloons, I changed a looot of things so I thought it would be better to open another one
[20:05] <balloons> Letozaf_, ok, let me pull that one
[20:07] <balloons> Letozaf_, ok so i'll run and then look at the code.. I can see it :-)
[20:07] <knome> balloons, http://pad.ubuntu.com/WygoQzxF0h
[20:07] <knome> balloons, see, there's no redundancy (except the product one)
[20:08] <Letozaf_> balloons, ok thanks
[20:08] <knome> balloons, compare to the current structure (just added that)
[20:08] <balloons> Letozaf_, ahh i see.. it swipes too high is all
[20:09] <balloons> knome, looking
[20:09]  * Letozaf_ is looking at the code
[20:10] <knome> balloons, the point is, the user will need to click something 4 times to get to the abiword test anyway
[20:10] <knome> balloons, there will always be redundancy.
[20:10] <balloons> knome, i get your point.. the redundancy is sometimes important
[20:10] <knome> balloons, i don't see how it is important here
[20:10] <balloons> as not every product has a testsuite named after itself, then a testcase that is similar
[20:10] <balloons> however 99% do :-)
[20:11] <knome> if a product doesn't have a testsuite named after itself - then great - let's keep that
[20:11] <knome> but for xubuntu's POV, abiword *is* simply a testcase
[20:11] <knome> it isn't a testsuite
[20:11] <knome> and definitely not a product
[20:13] <balloons> again, packages tracker was made with the mindset product = package
[20:13] <balloons> we can change that, just history of how we got here
[20:13] <knome> sure
[20:13] <balloons> in practice your right.. everything is a 1 to 1 relationship and the structure is cumbersome
[20:13] <knome> i see your point on why that makes sense
[20:13] <Letozaf_> balloons, even if I change the lineY value it still swipes high
[20:13] <knome> it's just redundant, and it makes people confused as there are multiple levels of things and they all have the same titles
[20:13] <balloons> we made the structure to share data as much as possible..
[20:14] <balloons> right.. so this is a pretty big proposed change
[20:14] <knome> i understand that, and i see we will lose some of the shared data
[20:14] <balloons> knome, well let's see
[20:14] <knome> otoh, we can leave the biggests tests out of the xubuntu desktop product
[20:14] <balloons> testsuites can be shared
[20:14] <knome> eg. we can definitely test firefox under the firefox product
[20:14] <balloons> testcases can be shared
[20:14] <balloons> what are we losing out on/
[20:15] <knome> balloons, tracking if all tests are run
[20:15] <knome> balloons, if testcases are under two different products, each product count their own stats
[20:15] <balloons> right
[20:15] <knome> balloons, eg. 1 done/2 tests total
[20:15] <knome> that's the only thing we lose with this new structure
[20:15] <knome> but IMO that's a non-problem
[20:15] <balloons> atm, we're happy to get results from a multitude
[20:16] <balloons> i don't see it as such..
[20:16] <knome> sure, and i know the bugs are shared
[20:16] <knome> my point is
[20:16] <balloons> you saw my multi-flavor product family
[20:16] <knome> sure.
[20:16] <balloons> we could just use that right?
[20:16] <knome> exactly.
[20:16] <balloons> there's only a few apps that would go there
[20:16] <knome> we can group the worst tests there, like firefox
[20:16] <balloons> browsers, email clients?
[20:16] <knome> definitely
[20:16] <knome> yup
[20:16] <knome> also
[20:16] <knome> atm we share xfce with ubuntu studio
[20:17] <balloons> I was just going to say that
[20:17] <balloons> studio and mythbuntu
[20:17] <knome> but in all honesty, they can just go and report the xfce tests under our product
[20:17] <knome> at least studio
[20:17] <balloons> and ubuntu gnome now as well
[20:17] <balloons> very similar
[20:17] <knome> ubuntu gnome doesn't use xfce :P
[20:17] <Letozaf_> balloons, if I run the rssreader app I just updated from PPA I get : file:///usr/share/ubuntu-rssreader-app/ubuntu-rssreader-app.qml:7 "./listview": no such directory
[20:17] <knome> it uses gnome :P
[20:17] <balloons> lol.. no to ubuntu
[20:17] <knome> heh
[20:17] <knome> yeah
[20:17] <balloons> there will be more overlap there than normal for a flavor
[20:17] <balloons> perhaps perhaps
[20:17] <knome> but that's something UG/U need to resolve
[20:18] <knome> maybe UG should create a product that only had packages that are *unique* to them
[20:18] <balloons> of course, by 14.04 that woin't be the case
[20:18] <knome> sure
[20:18] <balloons> I would encourage the idea to test only packages specific to you under your flavor
[20:18] <knome> definitely.
[20:18] <balloons> the others can go into a multiflavor bucket
[20:18] <knome> that's why we would like a flavor-product
[20:18] <balloons> but I don't think that will be too big
[20:19] <balloons> ok ,so let's mock your proposed
[20:19] <knome> to make it clear which packages our testers need to test
[20:19] <balloons> I'll need some time to do it
[20:19] <knome> we don't want to have to maintain a list elsewhere...
[20:19] <knome> sure :)
[20:19] <knome> (it's pretty much done in the non-sandbox though ;))
[20:19] <balloons> Letozaf_, it might be broken in the ppa.. they just updated the source today
[20:19] <balloons> not sure when it built
[20:19] <balloons> it *shouldn't* be broken, but it's possible
[20:20] <knome> balloons, the only thing we lack in production is the Xubuntu product family.
[20:20] <Letozaf_> balloons, just wanted to try to add a feed but I'm not in a hurry :)
[20:20] <knome> balloons, and the Saucy Daily milestone.
[20:20] <balloons> Letozaf_, bzr merge lp:ubuntu-rssreader-app
[20:21] <balloons> that will merge with your source and you can try it :-)
[20:21] <Letozaf_> balloons, cool thanks
[20:23] <Letozaf_> balloons, I get bzr: ERROR: Working tree "/home/letozaf/autopilot-tests/ubuntu-rssreader-app/" has uncommitted changes (See bzr status).
[20:23] <balloons> you should commit first beforehand :-)
[20:23] <Letozaf_> balloons, wait I changed a line...
[20:24] <Letozaf_> balloons, it worked thanks
[20:26] <Letozaf_> balloons, cool it works now :P
[20:26] <Letozaf_> balloons, I tried to change the value of lineY in the code but the swipe is alway high and in the same place
[20:32] <knome> balloons, so did you process my input already? ;)
[20:32] <balloons> knome, lol, no debugging things
[20:41] <balloons> Letozaf_, playing around with it now
[20:41] <Letozaf_> balloons, thanks :p
[20:42] <knome> balloons, btw... you've mis-ID'd some tests in the branch.
[20:42] <knome> balloons, eg. there is already tests 1589->1592.
[20:46] <balloons> knome, I can't misid them, as they are set by the script.. haha
[20:46]  * knome slaps the script
[20:46] <balloons> but seriously if they are mis-id'ed it means someone or something duped them
[20:46] <balloons> I'm guessing humans
[20:47] <knome> aha.
[20:47] <knome> i'll fix that later today then.
[20:47] <knome> but let lderan fix the script.
[20:47] <lderan> :)
[20:51] <balloons> Letozaf_, ok so you have a select_many on the canonical topic
[20:52] <balloons> it would be better if we knew exactly what to select
[20:52] <Letozaf_> balloons, if I use select single I get an error :(
[20:52] <balloons> Letozaf_, sure.. hence we need to assign an objectName and go after the right one :-)
[20:53] <balloons> let me have a look in vis for a minute
[20:53] <Letozaf_> balloons, thanks
[20:56] <knome> balloons, elfy: i fixed the ID's on the branch.
[20:56] <balloons> ty
[20:56] <knome> np
[20:56] <balloons> Letozaf_, ok, looking looking :)
[20:57] <elfy> knome: ok - I'll work at getting the rest done asap then
[20:57] <knome> elfy, what rest? :)
[20:57] <Letozaf_> balloons,  :) I'm looking too ...
[20:57] <elfy> knome: oh ok ...
[20:58] <elfy> I just need to deal with the bugs then
[20:58] <elfy> thanks :)
[20:58] <knome> elfy, yup. np ;)
[20:59] <balloons> Letozaf_, so I see Standard, text with Canonical
[20:59] <balloons> looking at TopicTab.qml I want to see if things line up
[20:59] <Letozaf_> balloons, I used it, but don't remember why I discarded it ...
[21:00] <balloons> TopicTab.qml doeesn't seem to line up
[21:00] <Letozaf_> balloons, maybe because it did not have x and y properties
[21:00] <balloons> so this is coming from somewhere else
[21:00] <balloons> yes, the label is no good
[21:00] <balloons> all the x, y is 0 0
[21:00] <balloons> ;-p
[21:01] <balloons> ok, so looking deeper I see the labelvisual your going after
[21:01] <balloons> with coordinates :-)
[21:02] <Letozaf_> balloons, yep that's why I picked it
[21:02] <Letozaf_> balloons, but doesn't work with select single, only many
[21:02] <Letozaf_> balloons, :(
[21:03] <balloons> Letozaf_, if you ever have to use select_many it means your search isn't specific enough
[21:03] <balloons> your getting multiple matches back
[21:03] <balloons> and that's not going to work :-)
[21:03] <Letozaf_> balloons, true
[21:03] <Letozaf_> balloons, I didn't find anything else though
[21:03] <balloons> again, I want an objectname for each topic.. but I'm not finding it in the qml
[21:03] <balloons> Letozaf_, one thing you can do is multiple searches
[21:04] <balloons> so for instance you could do this
[21:04] <balloons> item = self.app.select_many('Standard', text = 'Canonical')
[21:04] <balloons>         return item.select_single('LabelVisual', text = 'Canonical')
[21:05] <Letozaf_> balloons, looks good
[21:05] <Letozaf_> I will try it
[21:05] <balloons> the idea is you can issue a select, then issue a select against the result set from the first select
[21:05] <balloons> and so on
[21:05] <balloons> again however I want to find this in qml and do it that way
[21:06] <balloons> ahh! there it is
[21:06] <balloons> d'oh
[21:06] <balloons> look in the feeds folder
[21:07] <balloons> the qml file is in there.. managetopicspage.qml
[21:07] <Letozaf_> balloons, ok found it
[21:09] <balloons> Letozaf_, so I added objectNames to those objects on the page
[21:09] <Letozaf_> balloons, I found only the Standard one
[21:10] <Letozaf_> balloons, where is the LabelVisual ?
[21:12] <balloons> Letozaf_, sometimes the object titles don't line up.. for instance you'll never see a QQuickLoader in qml.. they are spawned from the std qml files
[21:13] <balloons> perhaps a little confusing. I like to just assign some objectNames and then go into vis and look at the object I want and make sure it's named
[21:13] <Letozaf_> balloons, ok ...
[21:13] <balloons> then use the object name from looking at in in vis, combined with the assigned object name and you should be set
[21:14] <balloons> in this case, I would grab all the topics
[21:14] <balloons> then filter by the topic title you want, which can be a second select or property check or whatever
[21:15] <knome> 00:01  balloons: ok, so looking deeper I see the labelvisual your going after
[21:15] <knome> balloons, you're
[21:15] <balloons> I was doing so well..
[21:16] <knome> ;)
[21:16] <knome> or i just wasn't around
[21:16] <knome> weren't? blah. :)
[21:16] <balloons> Letozaf_, I think I've confused you, but here's what I would do
[21:16] <balloons> wasn't is correct
[21:16] <knome> oki.
[21:17] <Letozaf_> balloons, I tried but did not work :(
[21:17] <balloons>     ListView {
[21:17] <balloons>         id: manageTopicsList
[21:17] <balloons>         objectName: "topicList"
[21:18] <balloons>         item = self.app.select_many('QQuickListView', text = 'topicList')
[21:18] <balloons>         return item.select_single('LabelVisual', text = 'Canonical')
[21:19] <balloons> :-( syntax is wrong
[21:19]  * knome slaps balloons 
[21:19] <knome> use a pad
[21:19] <balloons> I'm so lazy
[21:19] <knome> (or get a(nother) room)
[21:19] <Letozaf_> balloons, :)
[21:19] <balloons> I do like the saying.. get a pad!
[21:20] <Letozaf_> balloons, lol
[21:20] <balloons> people displaying public affection could be yelled at, "get a room"
[21:20] <balloons> so it falls in line with that..
[21:20] <Letozaf_> balloons, lol lol
[21:20] <balloons> "get a  ..."
[21:20] <balloons> get a job ya bum, etc
[21:20] <balloons> anywyas///
[21:23] <knome> haha, yes ;)
[21:27] <Letozaf_> balloons, I think I understood what you did, I will try tomorrow it's getting late for me :)
[21:28] <Letozaf_> balloons, hope it will work :)
[21:28] <balloons> Letozaf_, I'm not getting an object after defining it
[21:28] <Letozaf_> balloons, :(
[21:28] <balloons> sad panda.. I'll keep chuggin along
[21:28] <balloons> that should work, so :-)
[21:29] <Letozaf_> balloons, I will try this tomorrow evening, and come back in case it doesn't work :)
[21:29] <Letozaf_> balloons, going to bed now :P
[21:29] <balloons> sleep well Letozaf_
[21:29] <Letozaf_> balloons, thanks for your help
[21:30] <Letozaf_> balloons, good night :)
[21:30] <knome> balloons, so... >:)
[21:39] <lderan> yes balloons :P