#ubuntu-autopilot 2014-10-02
<rpadovani> elopio, ping
<elopio> rpadovani: pong.
<rpadovani> elopio, about this MR, do you want I revert your changes or something else? I'm not sure on how manage it
<rpadovani> https://code.launchpad.net/~rpadovani/ubuntu-calculator-app/1365564/+merge/233400
<elopio> rpadovani: yes. Now the two methods in the Screen class called swipe_to_delete and _drag_pointing_device_to_delete should no longer be needed.
<elopio> it would be great if you remove them as part of your MP.
<rpadovani> elopio, gotcha, thanks
#ubuntu-autopilot 2014-10-06
<nik90> balloons: hey, sry you got that link to thomi's blog post about test coverage...I need to bookmark and do some quoting for my own blog post :D
<nik90> balloons: I forgot to bookmark it
<balloons> nik90, ahh, sure
<balloons> http://www.tech-foo.net/on-test-levels-and-coverage.html
<nik90> balloons: cool, thnx
 * thomi blushes
<veebers> Is there anyone that can point me in the right direction with this date handling code? I want to know why method 1. is an hour different to methods 2 & 3: http://pastebin.ubuntu.com/8510318/
<veebers> barry: if you have some spare cycles, perhaps you have some insight?^
<thomi> veebers: just got off the phone, sorry
<veebers> no worries thomi. I'm trying to get my head around why I'm seeing this hour difference. All the other issues I've come across i've been able to sort out, but this one isn't a push over
<thomi> veebers: if I had to guess, I'd say that 2 and 3 are in a TZ where DST has been applied, thus the differnt time
<thomi> whereas 1. doesn't have a TZ associated, so DST cannot be calculated
<thomi> that's my guess
<veebers> thomi: right, but they should be the same tz surely. Hmm ok, true, I just assumed it took localtime tz
<thomi> veebers: no, it has no timezone
<thomi> if you don't specify, you get a tz nieve object, which has no timezone, and so can't do DST calculations
<veebers> thomi: then I might be screwed :-\
<thomi> you're never screwed, you just haven't found the right workaround yet
<thomi> what's the issue?
<veebers> I guess it was just coincidence that all the other testing I did (UTC, NZ, US/Central) in differentimes worked out
<thomi> how's that?
<veebers> thomi: the issue is that datetime.fromtimestamp(2983579200) != autopilot.types.DateTime(2983579200)
<veebers> when the TZ is US/Pacific
<veebers> thomi: I'll point you at the test I'm looking at
<thomi> veebers: because the first is nieve, the second has a tz applied to it
<thomi> does the __eq__ op fail because one has a tz and the other doesn't, or because they represent different times?
<thomi> I guess it must be the latter
<veebers> thomi: sorry was updating the code, MP is here: https://code.launchpad.net/~veebers/autopilot/fix-1328600-large-datetime/+merge/236815 lines 33-58 are the DateTime creation (handling large timestamps) line 303 is the test I'm currently looking at
<balloons> oO
<veebers> balloons: is that a reaction to my code? :-)
<veebers> or the fact that we're still haven't solved this bug :-P
<balloons> veebers, no, just a comment on that fact there is code :-)
<balloons> I'm confident you've got it nailed now
<veebers> balloons: heh, I'm not :-| which is why I'm trying to get it sorted out. (I _was_ confident late last night, but this little issue raised its head)
<thomi> veebers: 51-52 look suspicous to me
 * veebers looks
<veebers> thomi: ah I think you are right. that looks like leftover code. gettz should cover that
<veebers> aye it does, removing it now.
<thomi> also, if you've hit a wall, you need to find some expert help. I don't have time this morning, I may have time this arvo though
<thomi> in the mean time, make sure you've touched base with max
<thomi> and you can also find some python help
<thomi> from #python, perhaps
<veebers> thomi: ack, thanks
#ubuntu-autopilot 2014-10-07
<elopio> veebers: https://code.launchpad.net/~elopio/autopilot/fix1257059-log_move/+merge/197438
 * veebers looks
<elopio> my tests are passing. I don't know why the others are failing. Any idea?
<veebers> elopio: hmm, which test? there is a test that started failing all of a sudden recently
<elopio> veebers: autopilot.tests.functional.test_ap_apps.QtTests.test_can_launch_upstart_app
<veebers> elopio: hmm just saw that in the log. No idea sorry, looks like the app failed to launch? Shame there is no useful log there, seems like an issue
<elopio> veebers: yes, failed to start. But well, when you are free you can take a look at the tests I added and tell me if that's what you expected.
<veebers> elopio: line 63 would be better as super().__init__(*args, **kwargs)
<veebers> elopio: or would you prefer comments in the MP
<elopio> veebers: it's the same to me.
<elopio> veebers: do I have to make it compatible with python 2 ?
<elopio> or just calling super() is ok?
<veebers> elopio: no, python3 all the way :-)
<elopio> :D
<elopio> updated.
<veebers> elopio: sweet cheers. Looks good with a cursory look. Will give a detailed review later on, just trying to clear my plate a little
<elopio> veebers: ok, thanks.
<elopio> veebers: hum, something goes crazy when I call supper instead of logging.Handler.
<elopio> maybe it was there for a reason. I'll investigate further a little later.
<veebers> elopio: ok, perhaps I missed something and made a bad recommendation
<elopio> oh, I know. Stupid
<elopio> I don't need the self parameter now.
<veebers> elopio: ah right, yeah :-)
#ubuntu-autopilot 2014-10-09
<balloons> elopio, if you could take a look and ack this design. I plan to gut all the other fixture stuff from the other apps and make them similar to this: https://code.launchpad.net/~nskaggs/ubuntu-calculator-app/drop-fixtures/+merge/237848
<balloons> I just put desktop mocking back in.. it will fail jenkins otherwise
<elopio> balloons: yes, fine for me. Look that you removed all the bad part of the set up :)
<elopio> ideally, even on desktop we would remove the patching. But for now it works fine and clean.
<elopio> balloons: only thing is that we need to clean the previous calculations somehow.
<balloons> elopio, yes I plan to remove /home patching when we solve the bug (aka new user or whatever). For now I had to put it back in as I said to support jenkins which will blow up as the /home dir there is not at all clean :-)
<balloons> thanks for the review
#ubuntu-autopilot 2014-10-13
<veebers> barry: Are you still around? I have a question for you. I'm trying to get a simple example up but I can give the general idea without it
<barry> veebers: just for a few more minutes.
<veebers> barry: ah ok, I'll probably end up firing you an email. I have a case where doing some datetime math gives me different results for 2 different timestamps depending on the order in which I use them
<barry> veebers: yep, shoot me an email
<veebers> i.e. do_something(timestamp_1); do_something(timestamp_2); the correct resulting timestamps are returned, but doing it the other way around the 2nd call returns a different timestamp (much better example to come :-))
#ubuntu-autopilot 2014-10-14
<veebers> barry: in case your still around :-) I filed a bug here for the issue I mentioned: http://bugs.python.org/issue22627
<barry> veebers: cool, nosied.  i'll try to look in more detail tomorrow
<veebers> barry: awesome cheers /me deletes email to barry :-)
#ubuntu-autopilot 2014-10-22
<elopio> veebers: pushed, and unit tested.
<veebers> elopio: awesome, cheers
#ubuntu-autopilot 2014-10-23
<veebers> thomi: would you agree that the launcher (NormalLauncher etc.) change code resolves this bug? https://bugs.launchpad.net/autopilot/+bug/1228121
<ubot5> Ubuntu bug 1228121 in Autopilot "AutopilotTestCase._kill_pid and _kill_process need refactoring" [Medium,Triaged]
#ubuntu-autopilot 2014-10-28
<dkessel> http://unity.ubuntu.com/autopilot/api/ contains outdated documentation - it looks like it might be wise to remove the old version? then googling "ubuntu autopilot api" will return http://developer.ubuntu.com/api/devel/ubuntu-14.10/python/autopilot/api/index.html, and not the outdated version....
#ubuntu-autopilot 2014-10-30
<veebers> balloons: you around?
<balloons> veebers, first day back, how are you?
<veebers> balloons: nice, how was your travel back? I'm ok thanks. I got back Wed arvo (Friday today), funnily enough I felt better yesterday than today. But still feel fine :-)
<balloons> ahh right, it's one week on locally for you
<veebers> balloons: Yeah, I stayed on for a couple of days and left DC Monday lunchtime
<veebers> balloons: I can't remember if I followed up this bug, but I take it from past conversations that this can be closed against autopilot? https://bugs.launchpad.net/autopilot/+bug/1379488
<ubot5> Ubuntu bug 1379488 in Ubuntu Calendar App "apparmor denial during test runs for /home/phablet/autopilot/fakeenv/*/.cache/QML/" [Undecided,New]
<balloons> veebers, so the AP work was to remove the click.rules rules we put in
<balloons> I believe that file is gone now, though the work remains. so autopilot should be no longer affected indeed
<veebers> balloons: oh, so they no longer exist as part of the remove from image :-)
<veebers> sweet, thanks balloons. I'll mark as invalid
<veebers> actually, perhaps fix released is better suited if it was the removal of the rules files
<balloons> veebers, well what happened to the click rules again? refresh my memory
<veebers> balloons: They were removed from autopilot-touch package
<balloons> veebers, right, and they went where?
<veebers> oh, and moved to dbus-properties-service (or something similar0
<veebers> so, they still exist
<veebers> so, I think I was to quick to suggest 'fix released'
<balloons> veebers, right so that bit of work needs to happen still. So wherever it's moved should be marked
 * balloons checks the bug
<veebers> balloons: right you are, I'll double check which package it actually went into
<balloons> thanks veebers. I'll update the bug to specify that the click.rules need to modified once the dependant bug lands
<balloons> veebers, rev 518 makes me smile!
<balloons> veebers, so I'm not sure where the rules went your mp doesn't mention a bug
<balloons> https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192
<veebers> balloons: ^_^ yeah working on a release today. Let me clarify where they went
<veebers> balloons: dbus-property-service
<Letozaf_> Hi guys I've got some problems with an autopilot test I am trying to write for telegram app, launching autopilot list or run on it says there are not tests, cannot figure out what's wrong, can someone help me ?
<veebers> Letozaf_: sure thing
<veebers> Letozaf_: Do you have a link to a branch of what you're trying to run?
<Letozaf_> veebers, thanks, here is the link: lp:~carla-sella/junk/libqtelegram_First_small_test
 * veebers looks
<veebers> Letozaf_: your __init__.py file is missnamed (has a space in the file name) ubuntu_telegram_app/tests/__init__\ .py should be ubuntu_telegram_app/tests/__init__.py
<veebers> Letozaf_: Once you make that change list will work (but currently raises a sytanx error exception, but you'll be able to work that out once you can actually list it :-) )
<Letozaf_> veebers, oooh!!! thanks, this was driving me mad :-)
<veebers> Letozaf_: heh, nw. I know the feeling :-)
<Letozaf_> veebers, :-P
<veebers> I've spent some time before wondering the same thing just to realise that my file name didn't start with 'test_' :-\
<Letozaf_> veebers, lol
#ubuntu-autopilot 2015-10-06
<ahayzen> Hi guys, autopilot is only available on linux based systems right, not say Windows or OS X ?
<veebers> ahayzen: correct, although only officially supported on Ubuntu it 'Should Just Work (tm)" on other linux systems
<ahayzen> veebers, cool thanks, i assume due to it using dbus a lot ?
<veebers> ahayzen: yes, due to it relying on dbus to work.
<ahayzen> right thanks for the info
<veebers> ahayzen: no worries, let us now if there is anything else that we can help with
<ahayzen> hehe :-)
#ubuntu-autopilot 2015-10-15
<ahayzen> balloons, ping
<balloons> ahayzen, pong
<ahayzen> balloons, So I have a LocationPane {} QML object which is actually just a ListView, and I have an autopilot class LocationPane(UbuntuUIToolkitCustomProxyObjectBase) ...
<ahayzen> ...but it doesn't appear to get any of the properties of the ListView? Any ideas what I've missed (something probably simple)
<ahayzen> The getter for the AP object is self.wait_select_single(LocationPane, objectName="locationPane" + str(index))
<ahayzen> I can see in Vis that it has the type (in the tree) LocationPane .. and on the right it shows all the correct properties as well
<ahayzen> balloons, i can provide code if it helps, its all just a bit strange really and i'm not sure what i've missed :-/
<balloons> ahayzen, at first glance that sounds all good
<balloons> are you not getting the right object though? sometimes those types like listivews have parent and child objects that can confuse
<ahayzen> hah i bet i'm not
<ahayzen> the weather app is a sortof minefield of nested listviews and other things at this part
<balloons> off the cuff, that's my guess. I seem to remember having similar issues at times
<balloons> try adding objectnames to stuff and grok the qml / read vis. You might need to get a parent object in order to get the listview controls you want
<ahayzen> yeah i think this might be the issue lol, i wonder what object i'm actually getting! lol
<balloons> you can also check the uitk AP helpers for how they do it. They have demo qml and tests for helpers
<ahayzen> oh no..
<balloons> that should help spell out how the listview works in qml so you can understand what to grab
<ahayzen> so in the locationPane.qml it has objectName: "locationListView" ... but where it is created it has LocationPane {objectName: "locationPane" + index}
<ahayzen> balloons, ok i appear to have fixed it :-)
<ahayzen> balloons, thanks for the help
<balloons> ahayzen, glad it's working
<balloons> Sometimes I suppose it's helpful to have someone repeat things to you. Glad it was easy enough to fix
 * ahayzen tries to work out if he can somehow get the QQuickFlickable so he can use swipe_to_top()
<balloons> oO
<ahayzen> http://people.canonical.com/~nskaggs/autopilot-sdk-helpers.html#ubuntuuitoolkit.QQuickFlickable.swipe_to_top
<ahayzen> a ListView is a Flickable as well, so if i can somehow unconfuse AP :-)
<balloons> well if you have to, clone the method and tweak it so it works. Then it's a simple matter of requesting the patch into the helpers
<ahayzen> hah but i still think this is not picking up the fact its a listview/flickable
<ahayzen> balloons, i inherit from UbuntuUIToolkitCustomProxyObjectBase right? or do i put the fact its a ListView there ?
<ahayzen> balloons, ah i think i really wanted class LocationPane(QQuickListView): .. that seems to be acting better :-)
#ubuntu-autopilot 2015-10-19
<gang65> Hi
<gang65> Something goes wrong with Ubuntu-Clock build
<gang65> http://6014050377:8080/job/ubuntu-clock-app-autolanding/320/
<gang65> It hangs for few days
<gang65> http://6014050377:8080/job/ubuntu-clock-app-autolanding/
<veebers> Hi gang65 is there anything in the log that might help? At what point does it start to hang (application start, trying to click on an element etc.)
<gang65> It seems it is waiting for other Node:
<gang65> http://6014050377:8080/job/ubuntu-clock-app-autolanding/320/console
<gang65> The build does not even started
<veebers> gang65: as in jenkins is looking for another node? Who maintains this jenkins instance?
<veebers> gang65: if the build doesn't start it sounds like a jenkins / infrastructure issue. I'm not sure who's the best person to contact re: that. Depends on who runs the jenkins instance
<gang65> I think baloons
<veebers> gang65: Ah right; sorry I can't help with that, you may have to wait until balloons comes back online
#ubuntu-autopilot 2015-10-20
<jgdx> After migrating to Ubuntu.Components 1.3, autopilot can no longer find "Label" in System Settings. Using the vis, it seems they are now called UCLabel?
<jgdx> Is this a known issue?
<balloons> jgdx, interesting. Should have a look at the bugs and see
<balloons> is a helper failing, or just your tests? And it's likely not an 'issue' so much as intended
<balloons> i believe they are trying to use unique object names
<jgdx> balloons, a local helper (in system settings).
<jgdx> balloons, the recommendation from sdk team: do not use âLabelâ to find labels (if I read that right).
<balloons> jgdx, ahh. Yea, so no bug for the ui-toolkit helpers (which I wouldn't expect to see, as they try and keep it updated)
<jgdx> prob not
<jgdx> but if people follow the âGood Exampleâ from [1], they might fall into the same trap as me when migrating to 1.3. [1]Â https://developer.ubuntu.com/api/autopilot/python/1.5.0/guides-good_tests/
<balloons> jgdx, specifically what on that page?
<jgdx> balloons, save_button = self.select_single('Button', objectName='btnSave') for example. When using the uitk the Button name isn't API
<jgdx> or so I'm told
<balloons> would they rather see self.select_single(objectName='btnSave') or something else
#ubuntu-autopilot 2015-10-21
<jgdx> balloons, right, I think that's exactly what they want to see
<marka13> How would I go about viewing the landscape debug logs during node bootstrapping?  I am at the point of deploying openstack but the machine bootstraps, reboots, and then has no network connectivity?
<marka13> during boot, i can see it is assigned an ip?
<balloons> marka13, you'll probably want #ubuntu-server
#ubuntu-autopilot 2015-10-22
<marka13> isn't this channel for landscape/autopilot?
<brendand> marka13, nope
<brendand> marka13, rather remarkably they managed to clash with a project name *already used* in Ubuntu/Canonical :P
<brendand> Apple calling their launcher thingy Launchpad is one thing...
#ubuntu-autopilot 2015-10-26
<dobey> how do i figure out why adt-run is hanging when i try to run autopilot tests with it?
<dobey> elopio: come back to the dark side. we miss you
<elopio> dobey: heh, I miss you too :)
<elopio> dobey: adt-run -d -s gives more information and lets you log into the testbed after it times out.
<dobey> elopio: it doesn't get far enough for that i don't think
<dobey> Services restarted successfully.
<dobey> that's the last message printed, where it hangs
<dobey> it never times out
<dobey> that's with a vivid image
<elopio> dobey: paste the output you get with -d.
<dobey> i can't run with a utopic image, because utopic is eol :-/
<elopio> if it doesn't time out, sounds like something bad in autopkgtest.
<dobey> and i can't create a wily image. it seems to just hang
<dobey> and i don't know how to create an ubuntu-rtm image
<dobey> yeah, -d doesn't show anything additional there
<dobey> top shows qemu is doing stuff, but no messages on console
<dobey> :(
<elopio> dobey: with the snappy ssh script, if you pass -b it prints the vm boot console.
<elopio> not sure what test bed you are using.
<dobey> i'm trying to run the pay-ui click autopilot tests with adt-run
<dobey> qemu has a serial console socket, but i'm not sure how to connect to it
<dobey> but i can't seem to open it with tail or minicom
<dobey> minicom: cannot open /tmp/adt-virt-qemu.9bhk7o7g/ttyS1: No such device or address
<dobey> meh
<elopio> dobey: for qemu, the option is --show-boot
<dobey> option to what?
<elopio> dobey: to redirect the vm boot messages to your terminal. adt-run ... --- qemu --show-boot ...
<elopio> that should show more info. Not sure useful info, but more.
<dobey> doesn't work here
<dobey> adt-virt-qemu: error: unrecognized arguments: --show-boot
<dobey> and -d there doesn't show naything
<dobey> and this was working fine 6 months ago when i last ran this stuff :(
<elopio> um, I am on vivid but have adt-run from wily. Maybe this is new.
<elopio> but well, you shouldn't be surprised it stops working after 6 months without running it :)
<dobey> why? i haven't changed distro versions. i haven't modified the image i'm testing on. the click package hasn't changed (though i'm trying to add new tests for making a bug fix now)
<dobey> it shouldn't just stop working
<dobey> the only thing this tells me is that i should just scrap all autopilot tests everywhere, because nobody actually uses these tools, so they're totally unreliable
<dobey> and unreliable tests (and the tools needed to run them), are a waste of time
<elopio> dobey: +1 to that. If nobody is running the tests daily, they are worthless.
<elopio> however, I would suggest to fix them and start running them daily, of course.
<dobey> elopio: there's no need to run the tests daily if changes aren't being made daily
<dobey> i shouldn't have to run my own tests daily to ensure that the tools used to run those tests aren't breaking
<elopio> dobey: you should run the tests against the development image, which changes daily.
<dobey> nope
<elopio> well, that's probably another problem. If the error is in qemu + image, nobody is running that combination either.
<dobey> well, it's also not like i'm running the latest packages in development ubuntu all the time either
<dobey> i'm doing this on an LTS host
<dobey> i think there have been some security updates for qemu, but i wouldn't expect that to break things
<elopio> there's also the chance that it has never worked.
<elopio> but well, there are so many projects involved in this that things are delicate and break in unexpected ways.
<dobey> well i know it worked because i ran the tests
<dobey> and i refused to land the autopkgtest stuff in the click until i had it working reliably
<elopio> I get an error creating the chroot as explained in the README ^_^
<elopio> many broken things.
<elopio> none of them your fault, I bet.
<elopio> but if you don't run your tests daily, you won't find when somebody breaks your stuff, and you won't be able to make sure that they don't break it again.
<dobey> i shouldn't have to manually run my tests daily
<dobey> if the tests should be run manually, then it should be done via CI, where the image builds automatically run the autopkgtests configured for all the packages installed by default on that image
<elopio> yes. By you I don't mean *just you*. Your team, somewhere, ideally automatically. But every day, that's the important part.
<dobey> i have to disagree
#ubuntu-autopilot 2015-10-27
<dobey> bah. systemd :(
#ubuntu-autopilot 2015-10-29
<Guest17444> hello. can someone help how can I run autopilot from a source code? could not find any instruction. thanx
<dobey> from the autopilot source tree? or run the tests in some project using autopilot?
 * ahayzen wonders if is possible to connect Vis to an app running on the device rather than the desktop
<ahayzen> balloons, when you have been running the music-app autopilot tests on the new jenkins has the mocking been working correctly?
#ubuntu-autopilot 2016-10-24
<brandor5> Hello everyone... I'm looking to test openstack with autopilot and was curious if 16.04 was supported? the autopilot webpage is still instructing to use 14.04
#ubuntu-autopilot 2016-10-26
<brandor5> Hello everyone: I'm trying to use autopilot to install openstack... after pluggin in my maas info and hitting continue i get the following error: "error: flag provided but not defined: --up-tools"
<brandor5> anyone have any idea what's going on?
<brandor5> anyone?

{'channel': 'ubuntu-autopilot', 'month': 10}