[01:56] <ahoneybun> anyone with a BQ phone around?
[06:25] <dholbach> good morning
[07:03] <liuxg> is there anyway to tell the platform in QML app? for example, I want to know whether it is running on the desktop or on a real phone? this is useful to save the data into the right path on different platforms.
[10:18] <mivoligo> hi, what's the proper way to detect phone orientation in a QML app?
[10:25] <dholbach> beuno, I had a look at https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.modern-yaml/+merge/258791 and it looked good to me, but because it's quite substantial, maybe you or somebody on your team could have a look too?
[11:10] <sturmflut2> I'm working on a new version of my "Ubuntu Touch app wishlist and status", if you have updates, additions or corrections, please keep me informed.
[11:10] <sturmflut2> https://sturmflut.github.io/ubuntu/touch/2015/04/24/ubuntu-touch-app-wishlist-april-2015/
[11:25] <Benno-007> sturmflut2: Bug: Wishlist: Your app wishlist needs a changelog. ;)
[11:26] <sturmflut2> Benno-007: Yeah, I was thinking about that as well. Any ideas on how to present it so it doesn't get confusing?
[11:26] <sturmflut2> Benno-007: Maybe I should just add the word "NEW" in bold or something
[11:29] <Benno-007> sturmflut2: I trust in your decision. ;) Or we will grump AFTER your decision. A simple thing would be a list new/ changed and the last 1-3 updates only and then delete old changes.
[12:02] <DS-McGuire> dholbach, Like the latest designs for help?
[12:02] <dholbach> DS-McGuire, yes, very much so
[12:02] <dholbach> DS-McGuire, I'm so sorry for not having them posted around earlier.
[12:02] <dholbach> I was a bit busy the last days. :-/
[12:02] <dholbach> let me look into that now :)
[12:02] <DS-McGuire> dholbach, Don't worry about it. :)
[12:03] <dholbach> thanks a lot for prodding :)
[12:06] <DS-McGuire> not a problem ahah!
[12:14] <dholbach> DS-McGuire, I'll CC you on the mail
[12:14] <DS-McGuire> Thank you :)
[12:15] <justCarakas> sturmflut2: I like it but I cant find uMetronome on my phone, only uClick. And I'm also waiting on a DB meter
[12:16] <sturmflut2> justCarakas: uMetronome 1.4 depends on the ubuntu-sdk-15.04 framework, your phone probably doesn't have that framework version.
[12:21] <justCarakas> indeed it doesn't
[12:22] <justCarakas> a bit sad that it's ahead of the stable channel
[12:24] <DS-McGuire> dholbach, Heads up the link in the email doesn't link to anything.
[12:26] <dholbach> DS-McGuire, thanks, fixed :)
[12:27] <DS-McGuire> dholbach, No problem :)
[13:25] <mcphail> Hi. Are any of the Component Store people around? I can't seem to upload to community store
[13:35] <dholbach> JamesTait, ^ can you suggest somebody who can help?
[13:35] <dholbach> mcphail, what's the issue you're seeing?
[13:38] <mcphail> dholbach: "ucs submit lp:~njmcphail/foo/bar" gives a length error (with html markup) saying my browser is configured incorrectly and the request has been rejected due to possibility of CSRF. Something is wrong in the infrastructure there!
[13:38] <popey> mcphail: that's nik90 you need
[13:38] <mcphail> *lenghty
[13:38] <popey> component store != our store.
[13:38] <mcphail> aargh - can't type today
[13:39] <dholbach> oh ok, JamesTait: unping
[13:39] <JamesTait> dholbach, I don't think I know what the component store is.
[13:40] <JamesTait> dholbach, heh, no worries. ☺
[13:40] <dholbach> thanks popey
[13:40] <justCarakas> dholbach: doesn't unpinging result in a second ping :D
[13:40] <popey> HUMOUR FAILURE MODE 9
[13:40] <JamesTait> justCarakas, it's a toggle switch. 😝
[13:40] <mcphail> dholbach: yes, sorry. Usually nik90 and Stuart are on here but haven't seen them
[13:41] <dholbach> ok
[13:41] <justCarakas> JamesTait: very interesting, I must use an outdated client not to have this functionality :p
[13:42] <popey> mcphail: stuart is on twitter :)
[13:42] <justCarakas> JamesTait: you might know the answer to my question: is there still an official web appstore in the works will it be the uappexplorer ?
[13:42] <mcphail> popey: I'm not :)
[13:42] <JamesTait> justCarakas, I just have one of these installed on my desktop that gets activated by IRC pings: http://media.giphy.com/media/lFjHs5txoK50Y/giphy.gif
[13:43]  * popey summons a 2nd level Langridge invocation spell....
[13:43] <JamesTait> justCarakas, there is, AFAIK, but I don't have a timeline.
[13:43] <justCarakas> JamesTait: does it rune the IoT version of ubuntu ? :p
[13:44] <JamesTait> justCarakas, of course!
[13:44] <justCarakas> JamesTait: you should sell it :p I think it could be a nerd hit :p
[13:44] <JamesTait> 😃
[13:45] <justCarakas> JamesTait: I know of a site where you could launch such a crazy thing, its called kickstarter :p
[13:45] <sturmflut2> Are there still plans to add SMB/FTP/SFTP/etc. support to the File Manager or Content Hub? There was some talk about SMB support for the File Manager, but that was months ago.
[13:45] <JamesTait> justCarakas, I thought indiegogo was the cool one these days? 😉
[13:46] <popey> sturmflut2: yeah, in progress
[13:46] <JamesTait> justCarakas, * other crowd funding sites are available. 😝
[13:46] <sturmflut2> popey: "Just" SMB or anything else too?
[13:46] <popey> smb for now
[13:47] <sturmflut2> popey: Thanks, noted.
[13:47] <justCarakas> JamesTait: http://www.quickmeme.com/img/de/de3d43c558b56f5284c9fde1e5ea9cdda386f8e65562f0f63364574ce3d0356b.jpg
[13:48] <JamesTait> justCarakas, Snappy-powered carpet?
[13:49] <justCarakas> would fit nice in the store with a fridge :p
[13:49] <justCarakas> JamesTait: is it an airplane, Is it a bird, no, it is Ubuntu Carpet
[13:54] <aquarius> popey, pong
[13:54] <popey> that spell worked then
[13:54] <popey> mcphail: ^
[13:54] <popey> thanks aquarius
[13:54] <popey> 14:38 < mcphail> dholbach: "ucs submit lp:~njmcphail/foo/bar" gives a length error (with html markup) saying my browser is  configured incorrectly and the request has been rejected due to possibility of CSRF. Something is wrong in the  infrastructure there!
[13:55] <aquarius> huh. Maybe submissions are broken.
[13:55] <mcphail> popey: Ta!
[13:56] <aquarius> mcphail, I am looking into it
[13:56] <mcphail> aquarius: cheers
[13:56]  * mcphail is impressed with popey's magical powers of invocation
[13:58] <aquarius> ok, try it now?
[13:58] <aquarius> it is possible that the server just shut down or something :)
[13:59] <mcphail> aquarius: I'll need to wait until after work, but thanks!
[14:00] <aquarius> bear in mind that the Component Store is planning to be fairly seriously reworked, after the UOS discussion, so experimenting with it is fine but I wouldn't dedicate a lot of your life to it just yet; things will likely change
[14:00] <mcphail> aquarius: yes - this is something like a 6-line component for experimentation purposes
[14:00] <aquarius> cool
[14:01] <aquarius> note that you obviously have to pass it a real launchpad url ;)
[14:01] <mcphail> aquarius: yep :)
[14:01] <aquarius> I suspect that pythonanywhere shut down a server which doesn't get hit for a while
[14:01] <aquarius> which is fair play, since I'm on some sort of dodgy free plan ;)
[14:01] <mcphail> ha
[14:02] <mcphail> aquarius: any plans to support git branches?
[14:03] <aquarius> I didn't restart the server; all I did was try hitting http://sil.pythonanywhere.com/submit in a web browser which took a while and then (correctly) complained that GET isn't allowed for that URL; that seems to have woken the server up. :)
[14:03] <mcphail> aquarius: I'll try caressing that URL if it doesn't work later
[14:04] <aquarius> mcphail, probably yes, now that Launchpad supports them, although it's not likely to get done until after the reimplementation work takes place
[14:04] <mcphail> of course :)
[14:04] <mcphail> learning bzr is another little hurdle
[14:06] <aquarius> mcphail, I understand, yep, for which sorry. But LP didn't do git when I wrote this stuff, and making ucs understand git branches requires a whole bunch of changes to detect what a branch is and deal with it :)
[14:06] <mcphail> aquarius: it wasn't a criticism!
[14:09] <aquarius> I hadn't thought about git branches, but you are completely right that UCS should support them. I don't know what the LP API looks like for them, so that'll take some working out, but it seems like a sensible thing to do at some point!
[14:10] <mcphail> aquarius: would be a good one for a wishlist. I don't have any preference for one over the other, but I suspect more people know git than bzr
[14:11] <aquarius> agreed. However, I suspect that the first question asked after we start supporting git will be "why do I have to push to launchpad, can't I use github?" to which the answer will be "nope, because we rely on LP for authentication and anti-spam stuff". :)
[14:11] <mcphail> aah
[14:11] <mcphail> that _was_ goint to be the next question... :)
[14:12] <aquarius> tolja. :)
[14:12] <aquarius> You will note that there is no authentication required when submitting to UCS. This is because we only support Launchpad branches, and if you can put a branch on Launchpad, then that authenticated you, so we don't have to.
[14:13] <aquarius> Similarly, I can't "unsubmit" a component of yours, or override it, because I can't edit your Launchpad branch.
[14:13] <mcphail> aquarius: the thing about Launchpad, is creating a new project is relatively "scary". There is no namespacing etc
[14:13] <aquarius> mcphail, indeed. I use junk branches for that: you can bzr push lp:~mcphail/+junk/some-name without creating a project.
[14:14] <aquarius> I do this precisely *because* creating a project is so heavyweight. :)
[14:14] <mcphail> aquarius: I should really have done that
[14:15] <aquarius> the LP people give you the stink-eye for it, though, because junk branches can't be merged or branched or anything, so it's a bit naughty. :)
[14:16] <mcphail> aquarius: can you update a junk branch or do you have to create a new one?
[14:16] <aquarius> you can update it, yep!
[14:16] <mcphail> aah. OK
[14:19] <mcphail> so, do git repos on launchpad function as "superbranches" of a central project?
[14:19] <aquarius> I don't know
[14:19] <aquarius> haven't looked at the git stuff at all :)
[14:21] <mcphail> yeah - just wondering what would happen if I uploaded a git version of someting like ubuntu-calendar-app. I wonder if it ends up in a different namespace in some way
[15:48] <aquarius> chrisccoulson, ping
[15:48] <davidcalle> stephwil_, hello, are you around?
[15:48] <stephwil_> Hi yes i am
[15:49] <chrisccoulson> aquarius, I have a hunch about the last comment on https://github.com/GoogleChrome/voice-memos/issues/1
[15:49] <stephwil_> how can i help?
[15:49] <chrisccoulson> (we don't flush profile data when the browser is suspended)
[15:49] <aquarius> chrisccoulson, cool. I am happy to file a bug, but I don't know what it should say other than "waaaah waah this doesn't work and I don't know why and you probably can't replicate it", which is not helpful ;)
[15:50] <davidcalle> stephwil_, do you have an ETA for the news scopes guide? Some changes are being made to the dev workflow for scopes, and we are going to release these changes later this week (both in sdk code and dev.ubuntu.com tutorials), what's your ETA for the scopes guide and do you mind waiting a few days if it's imminent?
[15:52] <chrisccoulson> aquarius, yeah, so ogra_ and tedg tell me that we should be flushing profile data when the application is told it's going in to the background
[15:53] <chrisccoulson> I bet that's one of your problems
[15:54] <aquarius> chrisccoulson, that may certainly be related. But I've also refreshed the page a zillion times but it's not getting the new code. This is something to do with serviceworker caching, I'm sure, but it's really hard to debug that because you can't inspect serviceworker internals over a remote debug connection, and webbrowser-app disallows about: URLs :(
[15:54] <stephwil_> Hey David, I'm going to pass you on to Patricia Davila, she the UX lead on Scopes at the moment. She's not aware of any changes?
[15:55] <chrisccoulson> aquarius, chrome://serviceworker-internals should work (although you need at least Oxide 1.7, I believe)
[15:55] <chrisccoulson> (I just tried that here)
[15:55] <aquarius> ooh, I can use a chrome: url?
[15:55] <chrisccoulson> yep
[15:55] <aquarius> although I'm on RTM
[15:55] <chrisccoulson> aquarius, https://launchpad.net/~phablet-team/+archive/ubuntu/ppa (if you want to upgrade packages)
[15:55] <aquarius> woo! serviceworker internals works!
[15:56] <chrisccoulson> aquarius, chrome://gpu works too, and in trunk (1.8), chrome://tracing works :)
[15:57]  * aquarius unregisters the service worker ;)
[15:58] <aquarius> grrrr
[15:58] <aquarius> still don't have the new code :(
[15:58] <davidcalle> stephwil_, ok, just fyi, no changes required on what you've done, I just want to avoid a situation where you release something, people are amazed (because it looks great), get into scopes dev, and then we change stuff in tutorials and the SDK when they are starting to use them.
[15:59] <aquarius> maybe I can wipe the cache
[15:59] <aquarius> chrome://cache doesn't work :
[15:59] <aquarius> :(
[16:00] <chrisccoulson> Yeah, chrome://cache is part of the browser
[16:00] <chrisccoulson> We get all of the ones that are part of content
[16:00] <aquarius> ah
[16:00] <chrisccoulson> We could have our own implementations of those
[16:00] <aquarius> now being driven nuts by why I'm not getting the new code :(
[17:45] <mcphail> aquarius: UCS working now - cheers!
[17:47] <aquarius> mcphail, winner :)
[17:48] <mcphail> aquarius: out of interest, why does "ucs search" request my public ssh key? Is it part of the lp/bzr requirements?
[17:48] <aquarius> yep
[17:49] <aquarius> when you submit a component to ucs, it updates The Big List Of All Components, which is stored in Launchpad
[17:49] <aquarius> when you ucs search, it downloads the Big List with bzr, and searches it locally
[17:49] <aquarius> so, in order to fetch the List, it uses bzr, and so asks for your key details
[17:50] <mcphail> aquarius: could it handle an anonymous/http download instead to avoid asking for the key? I hate having to use an ssh agent and my passphrase is long
[17:50] <aquarius> Honest answer: I don't know
[17:50] <mcphail> :)
[17:51] <mcphail> fair enough!
[17:51] <aquarius> it's possible to get http downloads from launchpad, but I suspect you may have to be logged in to launchpad first, so you don't gain anything.
[21:29] <Dubstar_04> is there a appid and token avaiable for push notification testing?
[21:53] <ahoneybun> looking for a BQ phone user for some help
[21:54] <mcphail> ahoneybun: can I help?
[21:55] <ahoneybun> mcphail: sure!
[21:55] <ahoneybun> I'm trying to fix the scaling on my app to fix the device better
[21:55] <ahoneybun> *fit
[21:55] <mcphail> ahoneybun: link?
[21:55] <ahoneybun> the app is in the store 'uBeginner
[21:56] <ahoneybun> you can also search 'wiki' to find it
[21:56]  * ahoneybun downloads the Ubuntu SDK atm
[21:58] <mcphail> ahoneybun: just installed. Yes, the front page overspills. Does it need to be a flickable or something?
[21:58] <ahoneybun> perhaps, or fix the height of each button
[21:58] <ahoneybun> I set the width but not the height
[21:58] <mcphail> ahoneybun: that'll just break for the next device...
[21:59] <ahoneybun> no it will scale for each device
[21:59] <ahoneybun> if I do it right
[21:59] <ahoneybun> QML is awesome like that
[21:59] <ahoneybun> Qt in general
[21:59]  * mcphail is not so sure
[22:00] <ahoneybun> popey: ping pong
[22:00] <ahoneybun> mcphail: how are the other pages?
[22:00] <mcphail> ahoneybun: from a desgin point of view, is it essential everything is present on one screen?
[22:01] <mcphail> ahoneybun: other ones fit fine
[22:01] <ahoneybun> mcphail: don't think I would have enough buttons to justife a whole new tab
[22:01] <mcphail> ahoneybun: not a new tab - just allow scrolling
[22:02] <ahoneybun> unless I center everything on each tab, then I would not waste  lot of space
[22:02] <ahoneybun> I'll look at the api once I get the SDK and kits installed
[22:02]  * ahoneybun had to reinstall
[22:03] <mcphail> ahoneybun: i think a flickable is the way forward. You don't want to crush lots of buttons together
[22:04] <ahoneybun> true and adding that is not hard  (I think)
[22:04] <ahoneybun> should just be a option
[22:15] <ahoneybun> installing the Kit
[22:37]  * ahoneybun thinks the Ubuntu SDK might break his system
[22:38] <mcphail> ahoneybun: it won't break it. It will only make it sweat a bit :)
[22:38] <ahoneybun> mcphail: it replaced a few packages with different versions is what is scaring me
[22:39] <mcphail> ahoneybun: you on 15.04 or 14.04?
[22:40] <ahoneybun> 15.04
[22:41] <mcphail> ahoneybun: been fine on 15.04 here
[22:42] <mcphail> ahoneybun: DanChapman has been running it in a docker container, which would provide a bit of insulation if you are really worried
[22:49] <ahoneybun> its already installing and unpacking so
[22:53] <mcphail> ahoneybun: ppa-purge should sort things out if you need to go back, but it has been fine for me


[01:28] <cjwatson> hm, I forgot to rebase netcfg for some reason
[12:41] <Jemt> Hello again, folks.
[12:43] <Jemt> A quick question regarding initrd. As mentioned earlier, I use the Live CD to boot Ubuntu installations on USB sticks. The USB stick, however, may be upgraded over the months, resulting in a new Initrd being created. Will Ubuntu always work if I boot it using an older version of Initrd? The kernel is hold back, so that's never upgraded
[12:44] <Jemt> I fear that packages somehow may depend on new functionality in the newly created initrd. This probably won't be available if the system is booted using an older version of initrd
[12:44] <cjwatson> packages other than the kernel may cause the initramfs to be regenerated
[12:44] <Jemt> Yes, I know - e.g. udev
[12:45] <cjwatson> if you're talking about just a stable release though, and forcibly hold the initramfs back (e.g. by never copying it out to the top level of the USB stick), you should be OKK
[12:45] <cjwatson> OK
[12:45] <cjwatson> just don't try to do that across updates between releases
[12:46] <Jemt> But as you mentioned, any package may force initrd to be re-generated. Don't you think that's because they require changes to initrd to work properly ?
[12:55] <Jemt> I was also considering holding back changes to initrd somehow, but really, almost any package could have it regenerate. I would probably have to disable the update manager to keep that from happening
[13:19] <Jemt> cjwatson: Is it possible to have a custom script run after package installations? I need something to trigger my "restore" script which will do "ln -s /boot/old-initrd /initrd.img"
[13:27] <Jemt> Nonsens... I just realized something. Holding it back on the USB stick is not the solution, since the older initrd on the Live CD is still used to boot the USB stick
[13:28] <Jemt> What I need, is to make sure the USB stick will always boot with the "old" kernel and initrd on the Live CD, even though the USB stick is up-to-date
[13:58] <Jemt> cjwatson: I found evidence to support what you said (not that I don't trust you :-)). /etc/initramfs-tools/update-initramfs.conf contains an option to disable updates to initrd. So it is unlikely that packages will break if the "old" initrd is used.
[13:59] <Jemt> Option is called "update_initramfs={yes/all/no}


[09:01] <Mirv> ok, now everything should be properly compiled, I can start device testing + try to get also unity8 stack cu2d tests to run
[09:08] <didrocks> Mirv: excellent! :)
[09:08] <didrocks> still not sil2100. I'm starting to be worry
[09:10]  * didrocks sent a mup sms
[09:31] <didrocks> popey: joining?
[09:31] <popey> is that the time!
[09:31] <popey> sorry
[09:31] <didrocks> it definitively is :)
[09:37] <popey> bug 1262607 really is quite annoying
[09:46] <Mirv> ok finally I have the right bugs bookmarked..
[10:54] <ogra_> didrocks, do we know if the proposed Mir branch will have the fix for bug 1258056 ? else i have to postpone the nested Mir migration for the session stuff
[10:54] <didrocks> ogra_: I know there are something for nested Mir
[10:55] <ogra_> ah, great
[10:55] <ogra_> it is really annoying that these bugs have no distro task at all so one can see if it landed in the archive or not
[10:56] <didrocks> ogra_: I just bzr branch lp:mir, bzr merge that associated branch and:
[10:56] <didrocks> Nothing to do.
[10:56] <didrocks> so it will be there
[10:56] <ogra_> great
[10:56] <didrocks> ogra_: if it landed in the archive and is associated to a branch, it should have a distro task
[10:56] <didrocks> cu2d opens it to track
[10:56] <didrocks> so it's not in yet :)
[10:56] <ogra_> took 30min of my workday to dig through several different branches where a simple bug task would just have told me
[10:57] <didrocks> well, talk to upstream ;)
[10:57] <ogra_> yeah, i guess i should
[11:05] <psivaa> ogra_: didrocks: reverting apport and whoopsie-preferences did not help make the mako connected tests pass.
[11:05] <psivaa> but i am having trouble reverting lxc-android-config
[11:05] <ogra_> what is the issue ?
[11:05] <psivaa> getting 'unable to make backup link of `./lib/udev/rules.d/70-android.rules' before installing new version: Invalid cross-device link' when installing the previous version of that
[11:06] <ogra_> aww
[11:06] <ogra_> yeah, that wont work then, dpkg uses hardlinks ... hardlinks dont work across partition boundaries iirc
[11:06] <ogra_> you should be able to manually hack the files it changed though
[11:06] <psivaa> ogra_: http://pastebin.ubuntu.com/6714223/ for more info..
[11:06] <ogra_> without reverting the package
[11:07] <psivaa> ok, i'll try that then. thanks
[11:08] <ogra_> http://launchpadlibrarian.net/161740340/lxc-android-config_0.125_0.126.diff.gz
[11:08] <ogra_> /etc/system-image/writable-paths
[11:13] <cjwatson> hard links> yes, this is another reason why attempting to make individual files writable is fundamentally doomed
[11:13] <cjwatson> this *has* to be done at the directory level only
[11:47] <psivaa> ogra_: didrocks: reverting lxc-android-config does not help either.. i am now installing on a different mako to see if there is any improvement
[11:48] <didrocks> psivaa: yeah, and meanwhile I would suggest as well trying to flash the failing mako with the previous image as well
[11:48] <ogra_> well, apport was only a straw ... since the changelogs didnt show anything else that could be at fault
[11:48] <ogra_> was there an android change ?
[11:48] <ogra_> iirc the last upload didnt make it out of proposed (at least when i looked last night)
[11:49] <didrocks> ogra_: the android change AFAIK was in 117
[11:49] <ogra_> i thought it was still sitting in proposed
[11:49] <didrocks> 116:20140107:20131223.2
[11:49] <didrocks> 117:20140107.1:20140107.1
[11:50] <didrocks>          ^ it's the last bug, right?
[11:50] <didrocks> bit*
[11:50] <didrocks> :20140107.1
[11:50] <ogra_> https://launchpad.net/ubuntu/trusty/+source/android/20131202-2236-0ubuntu7
[11:50] <ogra_> sigh
[11:50] <ogra_> i wish these numbers would be connected in any way
[11:50] <ogra_> but yeah, looks like it has the new android
[11:51] <didrocks> ok, so it's not part of what failed on 117
[11:52] <Mirv> Saviq: didrocks: it currently looks like I'm getting a crash with Unity8 with the new Mir 0.1.3 repeatedly when running phablet-test-run -n unity8. backtraced it https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1267065
[11:52] <didrocks> kgunn: as well, FYI ^
[11:52] <didrocks> Mirv: ok, concentrate on the other landings then
[11:53] <Saviq> Mirv, can you attach your unity8.log please?
[11:53] <Mirv> didrocks: I mostly concentrate on Qt but I try to get powerd also on the side
[11:53] <didrocks> Mirv: would be nice to have powerd released today
[11:53] <Mirv> Saviq: isn't the upstart log there automatically already?
[11:54] <Mirv> Saviq: the threadstack trace mentions Mir in there
[11:54] <Mirv> didrocks: ok, I'll update on it later
[11:54] <didrocks> thx!
[11:54] <Saviq> Mirv, it is, sorry
[11:55] <Saviq> Mirv, did you keep your screen on?
[11:55] <Saviq>   what():  could not activate surface with eglMakeCurrent
[11:55] <Saviq> greyback, that's↑happening when display is off, right?
[11:56] <greyback> Saviq: yes. I think if screen off, you start unity8, then try to turn on screen, that happens too
[11:57] <Saviq> Mirv, it's best if you go "powerd-cli display on bright" when running the test suites
[11:57]  * Saviq tries
[11:57] <Mirv> Saviq: just screen on & unlocked + phablet-test-run -n unity8. of course eventually the screen is black, I guess after the crash and when the rest of the tests then fail.
[11:57] <Saviq> Mirv, yeah, but that crash is a result, not the cause
[11:58]  * Saviq tests
[12:02] <Saviq> Mirv, basically what happens: unity8 gets stopped, but takes a long time to exit (that's something we still need to investigate - either it's a crash and apport collects data or it's just unity8 taking a long time to exit)
[12:02] <Saviq> Mirv, long enough that screen suspends
[12:03] <Saviq> Mirv, subsequent tests crash due to screen being off - and that's the .crash file you got
[12:20] <Mirv> Saviq: I guess a crash is something that shouldn't happen anyhow, but yes thanks for the powerd-cli tip I'll add it to my testing plan. currently testing powerd from a clean slate + trying to get that %=!"$ qtdeclarative snapshot problem understood.
[12:20] <Saviq> Mirv, of course, unity8/mir should start fine with screen off, that's a known bug
[12:21] <Saviq> and it has a nice round number - bug #1235000
[12:39] <Saviq> Mirv, yeah, 25 unity8 tests passed with screen on
[12:39] <Saviq> and no crash
[12:42]  * kgunn is doing morning house duties but reading scrollback on mir testing
[12:50] <Mirv> didrocks: packaging ack http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_powerd_0.13+14.04.20140108.1-0ubuntu1.diff
[12:51] <Mirv> Saviq: I didn't need that last year, but yes I could retest after reflashing, I just fear I don't have time to run all tests today anymore but I should be able to upgrade Mir again and run unity8 at least
[12:52] <Mirv> Saviq: that = powerd-cli
[12:52] <didrocks> Mirv: +1
[12:54] <Mirv> thanks
[12:57] <Saviq> Mirv, that's because we (upstart) killed unity8 after 5s before - no time for screen to suspend
[12:57] <Saviq> Mirv, i.e. bug #1260379
[12:57] <Saviq> Mirv, but also bug #1262879
[12:58] <Saviq> Mirv, i.e. smoke testing keeps the screen on throughout the whole suite
[12:59] <xnox> Saviq: one can raise kill timouts on per job basis.
[13:00] <xnox> (or via .override file during tests)
[13:00] <Saviq> xnox, that is per-job
[13:00] <Saviq> xnox, https://code.launchpad.net/~nicolas-doffay/unity8/upstart-kill-fix/+merge/198931
[13:01] <xnox> cool =)
[13:01] <xnox> Saviq: why not simply adjust the stock unity8.conf, if you are changing that by default anyway.
[13:03] <xnox> Saviq: since that .override will not be used btw in the default testing, since a different .override is dropped in the user directory. And upstart only applies "one best .override" on top of "one best .conf"
[13:03] <Saviq> xnox, we don't want people actually *using* the phone to have to wait 30s
[13:04] <Saviq> xnox, what "different .override"?
[13:06] <xnox> Saviq: but that's  what you did anyway =)
[13:06] <xnox> Saviq: so user-session jobs are loaded from: ~/.config/upstart/ , $XDG_CONFIG_DIRS/upstart, /usr/share/upstart/session/. Whichever first one is found.
[13:07] <xnox> Saviq: then a second pass is searched in all the same locations for $name.override, and is applied on top.
[13:08] <xnox> Saviq: so a default install, at the moment, will have /usr/share/upstart/session/unity8.conf and /usr/share/upstart/session/unity8.override, which are merged together in memory and then the job is started with _all_ those parameters.
[13:08] <xnox> Saviq: so your change did make 30s timeout across the board, always.
[13:09] <Saviq> xnox, we only install it with the unity8-autopilot package
[13:09] <xnox> Saviq: if you look into lp:ubuntu-test-cases/touch however, it drops an unity8 overrides to start unity in testability mode. Since, as far as I remember, it uses .override file and thus overrides the global one you created.
[13:09] <xnox> Saviq: and unity8-autopilot is not on the default image?
[13:09] <Saviq> xnox, nope
[13:11] <Saviq> xnox, I didn't know about the other override, that should include the kill timeout change, too, then
[13:11] <Saviq> let me mention bug #1262879 again...
[13:11] <xnox> Saviq: let me first find for sure where it is.
[13:12] <xnox> Saviq: utils/target/unlock_screen.py:    os.system('echo "exec unity8 -testability" > ~/.config/upstart/unity8.override')
[13:13] <xnox> Saviq: in lp:ubuntu-test-cases/touch
[13:13] <xnox> Saviq: I think it's best for lp:unity8 to add "exec unity8 -testability" to unity8.override (now that you are shipping an override file) and drop unity8.override from any/all test-harnesses.
[13:14] <xnox> Saviq: is -testability actually at all needed / supported these days?
[13:15] <xnox> Saviq: i get a lot of:
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'e'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 's'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'a'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'b'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'i'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'l'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'i'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'y'
[13:15] <xnox> and then "Testability driver loaded"
[13:15] <ogra_> xnox, pastebinit !
[13:15] <ogra_> (and thats normal)
[13:15] <xnox> ogra_: why is that normal to specify option, which doesn't exist?
[13:16] <ogra_> i mean the output is
[13:17] <xnox> ogra_: no that is not normal, to self-induce invalid  / obsolete options. Just wait for qmlscene or any app use one of those single letter options and explode.
[13:17] <ogra_> xnox, it is in all test logs since day one like that
[13:17] <ogra_> which makes it a "normal" output for me since it does not affect anything
[13:18] <ogra_> (i agree it is crap, but it shouldnt cause any issues, all test logs have it since forever)
[13:19] <Saviq> xnox, the preferred way is to export QT_LOAD_TESTABILITY=1
[13:33] <Mirv> didrocks: Saviq: kgunn: ok I've resumed Mir 0.1.3 testing with Saviq's tip and everything seems ok so far. I look if I get the remaining tests done and/or update the chart for others to continue from where I left off.
[13:33] <Saviq> Mirv, thanks!
[13:35] <didrocks> excellent!
[13:41] <balloons> cprov, can you look at why this is failing to autoland? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906. We had to re-run yesterday before it would work, but I'm not sure why
[13:41] <cprov> balloons: will do
[13:49] <cjohnston> balloons: it has failing tests
[13:49] <cprov> balloons: testing are failling
[13:49] <fginther> morning
[13:50] <balloons> cjohnston, cprov I see that, but tim was thinking something wasn't right.. And nothing has changed since yesterday. Anyways, I'll send it back to him, thanks
[13:52] <Mirv> didrocks: in case all fine, could you pre-ack packaging changes? http://www.multiurl.com/l/gHX (couldn't find better for clickable links)
[13:52] <Mirv> I see dialer-app and messaging-app are also broken in image 118, which is "good" in the sense that the failures I saw were not from Mir
[13:53] <Mirv> (image 118 test results)
[13:56] <timp> cprov: hello
[13:56] <timp> cprov: I understand you were talking to balloons about https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/ ?
[13:56] <cprov> balloons: we found a problem in the testing env, apparently qmlscene crashed
[13:56] <timp> epaste, I mean this one: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/
[13:56] <balloons> cprov, :-p
[13:56] <balloons> gl
[13:56] <cprov> hi timp
[13:56] <ogra_> cprov, !!!
[13:56] <timp> cprov: ah. I guessed something like that :) all tests failed on a missing dbus
[13:57]  * ogra_ hugs cprov
[13:57] <cprov> ogra_: hey hey, good to see you again!
[13:57] <ogra_> yeah, same :)
[13:57] <cprov> timp, balloons: bear with me while the experts look at a solution.
[13:58] <timp> cprov: sure, thanks
[14:07] <cprov> timp: do you remember a similar problem in the past ? related, possibly, to a Mir regression ?
[14:08] <timp> cprov: I remember that we had this problem a lot in the past
[14:08] <timp> let me think if I remember what caused it; may be mir-related
[14:08] <cprov> timp: right, fginther is investigating it
[14:08] <timp> cprov: perhaps the screen was not activated?
[14:09] <timp> kalikiana_: ^ do you remember what was causing this kind of failures for us? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/
[14:09] <fginther> cprov, timp here's the bug I was thinking of: https://bugs.launchpad.net/qtubuntu/+bug/1243665
[14:09] <timp> elopio_: ^ perhaps you worked on these kind of failures? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/
[14:10] <psivaa> didrocks: ogra_: "base-passwd from 3.5.29 to 3.5.30" appears to be the reason for the mako connected test failures
[14:11] <timp> fginther: I'm not sure. I saw the failures a lot and if I recall correctly they were happening at random. But I didn't investigate it further. I guess that was kalikiana_ or elopio_ , or someone in the CI team
[14:11] <cjwatson> psivaa: *perks up*
[14:11] <cjwatson> psivaa: log?
[14:11] <fginther> timp, my IRC logs show that I was discussing this with kalikiana_ last month
[14:11] <kalikiana_> timp: yes I think this is the qubuntu bug. the error is in the logs before the python error
[14:12] <ogra_> psivaa, wow
[14:12] <ogra_> thats curious
[14:12] <cjwatson> ogra_: it was a fairly substantial change
[14:12] <psivaa> cjwatson: i dont have specific logs.. but reverting that make the test pass
[14:12] <cjwatson> though this is the first problem I've heard of from it and I've been watching
[14:12] <timp> kalikiana_: so the bug came back today..
[14:12] <cjwatson> psivaa: I'm going to need some kind of log of the failure
[14:13] <psivaa> cjwatson: i know it wont be helpful but it's http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-messaging-app-autopilot/15/console vs http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-messaging-app-autopilot/16/console
[14:13] <psivaa> but let me check if there is anything in the auth.log
[14:13] <fginther> kalikiana_, timp any idea why it's still showing up? has it not been fixed?
[14:15] <kalikiana_> timp: fginther I recall it was "fixed" when fginther and I were looking at it and https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1262982 is still open because only part of the problem was addressed
[14:16] <cjwatson> right, so assuming base-passwd was upgraded successfully, the difference is that a bunch of system users that never should have had valid login shells (a long-standing security issue) now really don't have valid login shells
[14:16] <kalikiana_> greyback was offering to try to reproduce, that's the last I remember
[14:19]  * cprov leaves for a quick lunch and will brb
[14:19] <cjwatson> psivaa: auth.log might well be helpful, indeed
[14:19] <greyback> kalikiana_: could you log a bug with unity-mir, giving me steps to try to reproduce it? Just for my records (as I forgot about this)
[14:19] <greyback> timp: ^^
[14:20] <timp> greyback: I don't know how to reproduce it, I only saw the failing tests in an MR that I was reviewing
[14:21] <fginther> greyback, we have another qmlscene crash here: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/
[14:21] <timp> fginther: do you know if it is an existing bug or do we need a new one?
[14:21] <greyback> fginther: the output from unity8 in those cases is valuable. Is it possible to get that?
[14:22] <greyback> as unity8 usually will say why it rejects the connections in it's own logs
[14:22] <timp> greyback: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/artifact/results/log/unity8.log ?
[14:22] <kalikiana_> greyback: this is there https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1262982
[14:22] <fginther> timp, I don't know if this relates to the prior bug, could someone trace the crash file?
[14:23] <fginther> (someon who might know what to look for :-) )
[14:24] <timp> fginther: I don't know what you mean with that. Is there some specific log file that jenkins gives us that someone needs to have a look at?
[14:24] <fginther> timp, the qmlscene crash file
[14:24] <greyback> kalikiana_: ah, thanks
[14:24] <fginther> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/artifact/results/crash/_usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash
[14:24] <fginther> there's also a unity8 crash
[14:25] <timp> fginther: that's a job for someone in the unity8 or mir team?
[14:25] <timp> fginther: I'm looking at it but it doesn't mean much to me
[14:26] <greyback> timp: there's no "REJECTED" error messages, meaning unity8 isn't explicitly rejecting any applications, so that's not the cause of the crash
[14:26] <greyback> timp: but that log has lots of unity8/mir crashes, which doesn't look right not me at all
[14:26] <greyback> s/not/to/
[14:27] <greyback> fginther: for that case, I'm suspecting a mir failure causing clients to crash
[14:28] <greyback> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
[14:28] <greyback>   what():  compositor_acquire would block; probably too many clients.
[14:28] <greyback> never seen that before anyway. Will need Mir team help
[14:30] <fginther> greyback or timp, can you file a bug if one doesn't already exist?
[14:34] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715060/ is the auth.log with v30
[14:34] <psivaa> http://pastebin.ubuntu.com/6715062/ is with v29 (passing one)
[14:35] <cjwatson> ok, so what's trying to su to nobody?
[14:35] <timp> greyback: ^ can you report the bug if needed? I don't really know what's going on
[14:35] <kalikiana_> but there is a bug…
[14:36] <cjwatson> psivaa: where would I find the top-level test scripts being run here?
[14:37] <greyback> timp: I'm extending that bug
[14:37] <timp> kalikiana_: that's why I said "if needed" :)
[14:37] <timp> greyback: ok, thanks
[14:38] <psivaa> cjwatson: http://bazaar.launchpad.net/~phablet-team/messaging-app/trunk/view/head:/tests/autopilot/messaging_app/tests/test_messaging.py contains the tests
[14:39] <cjwatson> hm, that's not the cause ...
[14:40] <cjwatson> could be utah, but utah seems to use sudo to get at the "nobody" user and sudo apparently doesn't care that the target user doesn't have a login shell
[14:40] <psivaa> cjwatson: utah is not involved here
[14:41] <psivaa> hmm probably it does.. not sure :)
[14:42] <cjwatson> psivaa: where does generic-mediumtests-runner-mako live
[14:42] <cjwatson> ?
[14:43] <psivaa> cjwatson: http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-runner-mako/
[14:43] <cjwatson> psivaa: I mean the code
[14:43] <cjwatson> the actual test runner itself
[14:44] <greyback> fginther: timp can either of you tell me, is unity8 restarted for each and every test?
[14:45] <psivaa> cjwatson: http://bazaar.launchpad.net/~canonical-ci-engineering/jenkins-launchpad-plugin/autopilot-testrunner-touch-saucy/files
[14:45] <psivaa> i think that's where it is. and if that's what you're looking for :)
[14:49] <cjwatson> psivaa: maybe ... it would be useful if you happened to have a jenkins console log that matches your auth.log dump, so that I can compare timestamps usefully between them
[14:49] <cjwatson> I'm flailing
[14:50] <cjwatson> I guess I know it comes before the unlock_screen.py call in run_all_autopilot.sh
[14:52]  * cjwatson tries grepping his oldish emulator tree
[14:54] <dobey> didrocks: https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736
[14:55] <didrocks> dobey: did you try it with SRU mode, dest ppa and so on?
[14:55] <didrocks> (I don't see tests for those cases)
[14:57] <dobey> didrocks: didn't know there were extra tests for those. i can add them if they are necessary. what is "SRU mode" though?
[14:57] <didrocks> dobey: there is a dest ppa but it's not reflected in versioning (the +series is different, that's it)
[14:58] <didrocks> dobey: should be transparent for you, just look at the test cases, I'm sure there is one for dest ppa at least, not sure for SRU mode (there is none if it's transparent to it)
[14:58] <cjwatson> psivaa: or failing that, perhaps I could have a tarball of all of /var/log/ ?  Ideally from the failing case, but the successful case would be better than nothing
[14:59] <dobey> didrocks: ok
[14:59] <cjwatson> I've grepped all the source I can think of and can't find this su call
[15:00] <didrocks> dobey: with that, I'm happy to approve your merge, will count on you to support it if further issues are involved though :)
[15:00] <psivaa> cjwatson: just a reboot prints this in auth.log without any tests being run.
[15:00] <psivaa> http://pastebin.ubuntu.com/6715183/
[15:00] <didrocks> (I still don't like we are introducing inconsistencies but if some upstream are puzzled about the packaging, they will talk to you I guess)
[15:00] <psivaa> but i'll get the tarball
[15:00] <cjwatson> psivaa: ok, that usefully rules out a bunch of stuff
[15:01] <didrocks> dobey: I guess you need to test for a second release the same day as well
[15:01] <dobey> didrocks: ok
[15:01] <rsalveti> didrocks: Saviq: not sure if a regression, just moved bug 1267076 to unity8
[15:02] <didrocks> rsalveti: oh indeed, not sure either. Will try to flash an older one
[15:02] <didrocks> Saviq: tell us if you have any idea
[15:04] <didrocks> psivaa: cjwatson: what do you think about, if we can't find the reason (which is probably in the testing tool with invalid usage) in 1 or 2 hours to revert the change and take some quiet time to continue the investigation? Does it makes sense Colin?
[15:05] <Saviq> didrocks, not a regression
[15:06] <Saviq> didrocks, bug #1240408
[15:06] <didrocks> Saviq: I never had enough music icons to create the carroussel. I should add more I guess :)
[15:06] <didrocks> ok, thanks Saviq, rsalveti ^
[15:06] <Saviq> didrocks, yeah I know
[15:06] <didrocks> Saviq: I'll let you dupe it?
[15:06] <Saviq> didrocks, already done
[15:06] <didrocks> sooo quick :)
[15:08] <fginther> greyback, unity8 is restarted and the phone is rebooted between test suites, but not between individual test cases
[15:10] <rsalveti> awesome, thanks!
[15:10] <greyback> fginther: thanks for the clarification.
[15:13] <psivaa> cjwatson: just sent an email with the logs
[15:18] <psivaa> cjwatson: also, http://ci.ubuntu.com/smokeng/trusty/touch/mako/118:20140108:20140107.1/5941/messaging-app-autopilot/ has some logs attached at the bottom
[15:19] <cjwatson> didrocks: ETA 20min to upgrade my device to a vaguely recent devel, after which I should stand a better chance
[15:19] <cjwatson> psivaa: thanks
[15:20] <didrocks> thanks, keep us posted
[15:21]  * ogra_ finds the discovery that we have anything su'ing to nobody worrying enough :)
[15:22] <didrocks> ogra_: nobody isn't a friend of yours? :)
[15:22] <cjwatson> ogra_: quite
[15:22] <ogra_> didrocks, i dont like perfect people ... :P
[15:22] <cjwatson> the trivial workaround is to pass "-s /bin/sh" to su, once we find the call
[15:23] <didrocks> ahah
[15:23] <cjwatson> assuming we don't find that it's better to use a different user
[15:23] <ogra_> yeah, i would prefer the latter
[15:23] <cjwatson> well
[15:23] <cjwatson> running things as nobody isn't necessarily wrong - what would be wrong is if it ended up using any files
[15:23] <cjwatson> but we'll see
[15:23] <cjwatson> sorry, I mean owning any files
[15:24] <ogra_> yeah
[15:24] <cjwatson> hopefully it's reproducible on grouper
[15:29] <psivaa> cjwatson: assume you are not running the test to reproduce the issue. phonesim is needed to run that particular failing test
[15:33] <cjwatson> psivaa: no need since you established that the su call is visible on a simple reboot
[15:34] <psivaa> cjwatson: ack, confirmed that again
[15:50] <cjwatson> bah, there's no indication of that su call in auth.log on grouper
[15:50]  * cjwatson tries devel-proposed
[15:50] <ogra_> on what device do you see that su call ?
[15:51] <cjwatson> ogra_: mako
[15:51] <cjwatson> (apparently)
[15:51] <cjwatson> ogra_: can you see if you have it?
[15:51] <ogra_> maguros pvrsrv thing that runs on the android side does weird stuff to get the graphics driver up ...
[15:51] <ogra_> ah, mako, k
[15:51] <cjwatson> this doesn't look like android-side
[15:51] <ogra_> right
[15:51] <cjwatson> if it were, it surely wouldn't have been affected by a base-passwd change
[15:52] <ogra_> root@ubuntu-phablet:/# grep su /var/log/auth.log
[15:52] <ogra_> root@ubuntu-phablet:/#
[15:52] <ogra_> thats my mako, recent promoted image, upgraded today
[15:53] <ogra_> (note my mako is my actual phone, i wont run tests on it, but popey has a test device he could run tests on)
[15:53] <cjwatson> I suppose it could be due to some set of installed test packages
[15:54] <cjwatson> psivaa: any chance you could run "grep -wr nobody /" on a device exhibiting this, and show me the result?
[15:54] <psivaa> cjwatson: sure 1 sec
[15:55] <cjwatson> I can partially revert if I have to, but I'd really rather chase this down as the change made all trusty systems more secure
[15:56] <popey> cjwatson: happy to run whatever tests on my phone
[15:56] <cjwatson> popey: do you see "Successful su for nobody by root" in /var/log/auth.log?
[15:58] <dobey> didrocks: more tests added on https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736 ; i didn't see any existing stuff for "sru mode" and i'm not sure how it would apply in this case (i think it would be transparent since the series is different anyway, as you said)
[15:59] <popey> cjwatson: under what circumstances?
[15:59] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715504/ is the output of that.
[15:59] <cjwatson> popey: to start with, just as it is
[15:59] <popey> no
[16:00] <popey> i see no reference to "nobody" in that log
[16:00] <cjwatson> popey: then after running the messaging-app tests and rebooting
[16:00] <psivaa> cjohnston: please note that the lines with Documents are copied old auth.logs
[16:00] <didrocks> dobey: looking good. Mind if I have a deeper look my tomorrow morning? Want to finish some stuff tonight
[16:00] <cjwatson> yeah, I know
[16:00] <popey> ok
[16:01] <cjwatson> psivaa: I think it might have got stuck at /proc or /sys
[16:01] <cjwatson> psivaa: could you try "grep -wr nobody /usr /var"?
[16:04] <dobey> didrocks: sure
[16:06] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715544/
[16:07] <cjwatson> /usr/bin/with-ofono-phonesim:su nobody > /etc/ofono/phonesim.log <<EOF 2>&1 &
[16:07] <cjwatson> bing
[16:07] <didrocks> dobey: thanks for the patch!
[16:08] <dobey> didrocks: sure. i just wanted proper support for native daily release versions :)
[16:10] <cjwatson> psivaa: Please try http://paste.ubuntu.com/6715569/ - the latter part should apply to /usr/bin/with-ofono-phonesim
[16:11] <cjwatson> popey: I think you can stand down now, thanks
[16:11] <popey> ok
[16:22] <cjwatson> psivaa: any luck?
[16:23] <psivaa> cjwatson: running the test.
[16:23] <cjwatson> psivaa: I should have mentioned that you probably need to reboot after applying that patch
[16:23] <psivaa> cjwatson: the tests do that already
[16:23] <cjwatson> ok
[16:24] <didrocks> psivaa: the change is in the test runner?
[16:24] <cjwatson> the change is in ofono-phonesim, see above
[16:24] <psivaa> cjwatson: and it fixes. the test pass :)
[16:24] <cjwatson> yay
[16:24] <didrocks> ok, thanks
[16:24] <cjwatson> uploaded
[16:24] <didrocks> excellent :)
[16:25] <cjwatson> https://launchpad.net/ubuntu/+source/ofono-phonesim/1.19-0ubuntu7
[16:26] <cjwatson> urgh, competing with the test rebuild
[16:27] <cjwatson> if only we had more arm64 hardware ...
[16:44] <cjwatson> didrocks: I think maybe I should cancel one of the test rebuilds to make room here - I assume you want to get back to green this evening?
[16:45] <didrocks> cjwatson: if possible, so that we have an image kicked soon
[16:45] <didrocks> cjwatson: otherwise, the cronjob at 2 am UTC will kick it
[16:45] <ogra_> 3am
[16:45] <ogra_> :)
[16:48]  * didrocks is lost in time
[16:50] <ogra_> if it is only one of time ans space thats still ok ... both is bad though
[16:50] <ogra_> s/ans/and/
[16:53] <didrocks> ;)
[16:53] <didrocks> space is ok
[16:53] <didrocks> well… I guess
[17:00] <balloons> fginther, ping
[17:00] <fginther> balloons, pong
[17:01] <balloons> fginther, can you help me rebuild konsole-qml-plugin in https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily?
[17:02] <balloons> we don't have a trusty build for it
[17:02] <fginther> balloons, actually there is one, but it has saucy in the name
[17:03] <didrocks> ogra_: joining?
[17:03] <ogra_> didrocks, no :P
[17:03] <balloons> fginther, hehe.. so the 10-30 is the name eh? anyways, we need a build against the newer libs in trusty
[17:04] <fginther> balloons, ack, I'll try a fresh build
[17:10] <fginther> balloons, is this the correct branch? lp:ubuntu-terminal-app/plugin
[17:10] <balloons> fginther, yes I believe so
[17:12] <didrocks> ogra_: tsssss
[17:12] <ogra_> heh
[17:14] <balloons> didrocks, I did notice you have dialer app assigned to me.. it's not a core app
[17:15] <didrocks> balloons: oh sorry, yeah I know, typo :)
[17:15] <didrocks> balloons: will fix in next one, thanks!
[17:15] <balloons> which is to say, I've not handled issues in the past, heh :-)
[17:15] <didrocks> balloons: no worry, I pinged directly Bill on that one in fact
[17:15] <didrocks> the typo was just on the email
[17:22] <balloons> :-)
[17:30] <timp> what's wrong here? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-amd64/2113/console
[17:31] <timp> ERROR: No artifacts found that match the file pattern "work/output/*.deb". Configuration error?
[17:31] <timp> ERROR: 'work/output/*.deb' doesn't match anything, but 'output/*.deb' does. Perhaps that's what you mean?
[17:31] <timp> it seems to fail when installing packages before running tests?
[17:49] <balloons> cprov, what happened with this? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[17:52] <cjohnston> timp: looks like there is a dbus issue
[17:53] <cjohnston> balloons: isn't that the same one as earlier?
[17:54] <balloons> cjohnston, yes.. I just don't know what happened with it. I see it's still failing
[17:55] <cjohnston> balloons: it hasn't run again since last we talked has it?
[17:55] <balloons> cjohnston, I'm not sure.. I had to hit some meetings and left it with timp
[17:55] <cjohnston> PS Jenkins bot (ps-jenkins) wrote 4 hours ago:
[17:55] <balloons> was something wrong on the ci end?
[17:56] <balloons> that's the question
[17:56] <cjohnston> no..
[17:56] <balloons> kk, so it is test failures then..
[17:56] <cjohnston> _usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash <--
[17:56] <cjohnston> balloons: my understanding is that crash is the issue
[18:00] <balloons> I see the pending build btw fginther for konsole-qml-plugin, ty
[18:18] <kenvandine> robru, can you review https://code.launchpad.net/~ken-vandine/ubuntu-html5-theme/0.1+13.10.20130916-0ubuntu2/+merge/200722
[18:19] <kenvandine> alesage, can you look at this failure, gcov related
[18:19] <kenvandine> https://jenkins.qa.ubuntu.com/job/unity-trusty-amd64-autolanding/67/console
[18:19] <alesage> kenvandine, willdo
[18:20] <kenvandine> alesage, thx
[18:23] <robru> kenvandine, done
[18:24] <kenvandine> oh... you did it last night... since mine :)
[18:24] <kenvandine> i proposed branches for all of the out of sync packages yesterday :)
[18:24] <kenvandine> most are merged already though
[18:24] <robru> kenvandine, oh ok
[18:26] <kenvandine> alesage, i have another one that is failing because it finds lcov 1.10 and gcov.m4 doesn't list 1.10 as a valid version
[18:26] <kenvandine> alesage, should i just update the gcov.m4 file?
[18:26] <kenvandine> alesage, or is there more to it than just adding the version?
[18:26] <alesage> kenvandine, yes I think just update the version
[18:27] <kenvandine> cool, thx
[18:28] <kenvandine> robru, humm... you did dee as well
[18:28] <kenvandine> but dee ftbfs in ci tests
[18:28] <kenvandine> because of the lcov version
[18:29] <robru> kenvandine, oops, yeah, I didn't realize you'd done any. so I just did a couple that i saw
[18:29] <alesage> kenvandine, yes that's going to be a problem all over :/
[18:29] <kenvandine> haha... we did discuss it in the meeting yesterday :)
[18:29] <alesage> kenvandine, need to upstream that gcov.m4 file somewhere
[18:29] <kenvandine> https://code.launchpad.net/~ken-vandine/dee/1.2.7+13.10.20130924.1-0ubuntu2/+merge/200719
[18:29] <kenvandine> robru, can you review that one?
[18:29] <kenvandine> i merged trunk so it won't conflict with your change
[18:29] <kenvandine> but hopefully will build in CI now
[18:30] <robru> kenvandine, done
[18:30] <kenvandine> thx
[18:30]  * kenvandine hopes it passes
[18:31] <kenvandine> alesage, let me know what you figure out on with the unity build
[18:31] <kenvandine> that one looks weird, unrecognized gcovr format
[18:31] <robru> kenvandine, https://code.launchpad.net/~unity-team/libqtdbusmock/trunk/+activereviews is this the same scenario as libqtdbustest? pete-woods says only the changelog changes were necessary, but didn't comment for this project (which is an identical change)
[18:31] <kenvandine> yeah
[18:31] <kenvandine> i saw that too
[18:31] <kenvandine> i'll revert the rules change there too
[18:31] <robru> kenvandine, ok, ping me and i'll approve the changelog change then.
[18:31] <alesage> kenvandine looking at, will report
[18:33] <kenvandine> robru, pushed
[18:33] <robru> kenvandine, done
[18:36] <kenvandine> ok, bamf needed the gcov.m4 change too
[18:37] <kenvandine> https://code.launchpad.net/~ken-vandine/bamf/0.5.1+14.04.20131125-0ubuntu2/+merge/200723
[18:37] <kenvandine> robru, ^^
[18:42] <robru> kenvandine, done
[18:42] <kenvandine> thx
[18:45] <timp> 18:52:54 < cjohnston> timp: looks like there is a dbus issue
[18:45] <timp> cjohnston: yes, but the code changes don't touch dbus. is it an issue with jenkins?
[18:46] <timp> cjohnston: why dbus? It says some deb files are missing. I don't see any failed tests
[18:47] <cjohnston> timp: I'm wondering if there is a crash like the other one?
[18:48] <alesage> kenvandine gcovr log items may be red herring: last successful build (65) also had gcovr complaints; `mkdir` operation failure at the very end appears to be the culprit
[18:49] <alesage> fginther, does this look at all familiar?  https://jenkins.qa.ubuntu.com/job/unity-trusty-amd64-autolanding/67/console
[19:11] <fginther> alesage, I think I know what's happening here, give me a few minutes to get it fixed
[19:12] <balloons> sergiusens, ping
[19:12] <alesage> fginther, thanks kenvandine ^^
[19:13] <cjohnston> fginther: can you take a look at https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-amd64/2113/console please
[19:19] <kenvandine> alesage, fginther: thx
[19:19] <fginther> cjohnston, I can fix that, thanks for the info
[19:20] <cjohnston> timp: ^
[19:22] <timp> fginther: you'll fix the ERROR: No artifacts found that match the file pattern "work/output/*.deb". Configuration error?
[19:22] <timp> fginther: cool. do you know what caused it?
[19:24] <fginther> timp, it's fixed (at least this case, I have some others to correct). One of the CI tools was automatically updated and it resulted in a mismatch in behavior
[19:24] <timp> ok, thanks
[19:55] <sergiusens> balloons, pong
[20:00] <balloons> sergiusens, solved it myself heh. I swear everytime I ping to ask you something I end up figuring it out.. :-p
[20:00] <sergiusens> balloons, hey, that's how I operate as well :-)
[20:01] <cyphermox> robru: kenvandine: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/apps-test-packages/+merge/200900 ?
[20:24] <kenvandine> cyphermox, looking
[20:24] <kenvandine> cyphermox, approved
[20:30] <cyphermox> thanks
[22:08] <sergiusens> fginther, can we get lp:goget-ubuntu-touch under ci now?
[22:08] <fginther> sergiusens, sure
[22:11] <sergiusens> fginther, let me get greedy and ask for lp:usensord too :-)
[22:11] <fginther> sergiusens, what are these used for (so I know what cu2d stack to use)?
[22:11] <sergiusens> fginther, usensord should go in the same place platform-api is
[22:12] <sergiusens> fginther, goget-ubuntu-touch where phablet-tools lives
[22:15] <fginther> sergiusens, are these ready for daily-release?
[22:19] <sergiusens> fginther, they'd need packaging review; but they are fairly ready
[22:19] <sergiusens> fginther, as in from the team
[22:20] <fginther> sergiusens, in that case I'll prep them for upstream merger now so as not to wait on a packaging review
[22:20] <sergiusens> fginther, sounds good
[22:32] <kgunn> fginther: just curious...can we determine/backtrack like which exact device (mako) a test was run on ?
[22:33] <kgunn> just curious we saw one mako we were suspect of prior to break...took it out, but put it back
[22:33] <kgunn> just wondering if it might be biting us again
[22:33] <kgunn> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/226/console
[22:33] <fginther> kgunn, yes, the device name is in the console log, one of the first few lines
[22:33] <fginther> mako-04cb53b598546534
[22:34] <kgunn> yep found it...thanks fginther
[22:35] <fginther> kgunn, if you suspect a bad device, we can remove it from the main pool and attempt some focused tests
[22:36] <kgunn> fginther: thanks...i'll just keep an eye on this mp...see if it fails again and monitor the device...if "he" remains a prob...i might ping you tomorrow
[22:36] <fginther> kgunn, ack