[06:35] <dholbach> good morning
[06:37] <dpm> morning dholbach, morning all
[06:39] <dpm> hi zbenjamin, I'm trying to build a click package for lp:ubuntu-filemanager-app, but Qt Creator complains that there is no manifest.js file, when in fact there is. This is a core app for which I changed the manifest explicitly to work with Qt Creator, and the click build was working until recently. Any ideas what could be going on?
[06:39] <dholbach> hola dpm
[06:39] <dpm> hey :)
[06:40] <zbenjamin> dpm: do you have a branch i can test?
[06:40] <dpm> zbenjamin, the one I just gave you -> lp:ubuntu-filemanager-app
[06:41] <dpm> let me give you the message I got when I tried building the click last night
[06:43] <dpm> that's it: http://pastebin.ubuntu.com/7320254/
[06:43] <zbenjamin> oh click complains about that
[06:44] <zbenjamin> dpm: what package do i need for that: taglib/attachedpictureframe.h
[06:44] <zbenjamin> libtag1-dev
[06:44] <dpm> zbenjamin, taglib1-dev
[06:45] <dpm> or the other way round, yes :)
[06:46] <dpm> zbenjamin, another issue I noticed is that QtC still overwrites the existing manifest.json, although now it only does it for the maintainer. Shall I report a separate bug for that? -> http://pastebin.ubuntu.com/7320263/
[06:47] <zbenjamin> dpm: hm it did not for me
[06:47] <zbenjamin> dpm: maybe some corner case
[06:47] <dpm> let me try to do a fresh checkout to see if I can reproduce
[06:48] <zbenjamin> dpm: Successfully built package in './com.ubuntu.filemanager_0.3_armhf.click'
[06:48] <zbenjamin> dpm: worked for me, do you have CLICK_MODE=on in the build settings?
[06:49] <dpm> zbenjamin, uh, no, I don't. Is that needed now?
[06:49] <zbenjamin> dpm: yes, CLICK_MODE is not set automatically anymore
[06:50] <zbenjamin> dpm: we realized that CLICK_MODE is just not required for the templates, the average app dev does not need to create deb packages and click packages
[06:51] <dpm> zbenjamin, ok, yeah I understand the reasoning. Before I set it, though, another question: why do I now have 2 Ubuntu armhf kits? One "regular" and the other one "Run locally"?
[06:51] <dpm> and which one do I use?
[06:53] <zbenjamin> dpm: hm, did you ever compile the plugin yourself? that usually happens if you have 2 qtc instances that have different paths to the scripts.
[06:53] <dpm> zbenjamin, believe me, I don't really have a strong desire for compiling QtC or any of its plugins :)
[06:53] <zbenjamin> dpm: can you check if there are also 2 toolchains?
[06:54] <dpm> yeah, just a sec
[06:54] <zbenjamin> dpm: Options -> Build & Run -> Compilers
[06:55] <dpm> zbenjamin, thanks. Here's what it looks like on my system -> http://i.imgur.com/wOdrne0.png
[06:55] <zbenjamin> dpm: weird and both kits point to the same Compiler?
[06:56] <zbenjamin> dpm: then you can just delete one
[06:58] <dpm> zbenjamin, they seem to point to the same compiler, yes. So I'll go ahead and delete one -> http://i.imgur.com/hQxMIuB.png
[06:58] <zbenjamin> dpm: yeah delete the newer one so you projects will still have the settings
[06:58] <zbenjamin> dpm: i wonder where that problem comes from ....
[06:59] <dpm> no idea, perhaps it was something I did, but I wouldn't know what
[06:59] <dpm> ok, now onto setting the CLICK_MODE variable...
[07:00] <dpm> zbenjamin, I'm now on Projects > UbuntuSDK for armhf > Build. Do I set CLICK_MODE=on in "CMake arguments"?
[07:01] <zbenjamin> dpm: -DCLICK_MODE=on
[07:01] <dpm> ok
[07:02] <dpm> building now...
[07:04] <dpm> zbenjamin, ok great, now it built the click, thanks :) One thing to notice is that it didn't overwrite manifest.json this time, but it did overwrite apparmor.json -> http://pastebin.ubuntu.com/7320329/
[07:05] <zbenjamin> dpm: yeah it did a rewrite with the correct contents
[07:06] <dpm> will it rewrite every time, or only if it detects that the content is not correct?
[07:10] <justCarakas> Good morning all
[07:10] <justCarakas> any idea when there will come a branch for ubuntu touch utopic unicorn
[07:11] <dpm> hi justCarakas, soon :)
[07:11] <justCarakas> dpm: thx, will it be possible to switch from the 14.04 devel branch to the new one or isn't that necessary
[07:13] <dpm> justCarakas, I'm not sure how easy it will be to do the switch, you might want to ask on #ubuntu-touch for that
[07:13] <justCarakas> dpm: thx
[07:14] <justCarakas> dpm: do you know of plans of a systems for i18n for HTML5 apps
[07:16] <dpm> justCarakas, there is one in the works done by a community member, daker
[07:17] <justCarakas> awesome :D
[07:17] <dpm> zbenjamin, ok, it seems I'm not being lucky with QtC since I came back from holiday. While it tells me that my device is connected and ready to use in the Devices tab under options, I cannot get my app to run on it. When I hit Ctrl+R I get this -> http://pastebin.ubuntu.com/7320375/ - any ideas?
[07:17] <justCarakas> looking forward to it,
[07:18] <justCarakas> i use a js library now but I cant use the translation stuff from ubuntu than
[07:22] <zbenjamin> dpm: try to click refresh on the devices page
[07:23] <zbenjamin> dpm: the device is green? you can see that on the icon over the run button, if there is a small green circle its ready
[07:24] <dpm> zbenjamin, I clicked "Redetect devices" on the Devices page and Qt Creator crashed. I had this same behaviour yesterday. The device button was always red in the main QtC left bar, but on the Devices tab under the Options dialogue it was green and "Ready to use"
[07:24] <dpm> I've also switched cables to rule out a faulty cable
[07:24] <dpm> same result
[07:28] <zbenjamin> dpm: if the button is red it won't work , but if it goes green in the options page its a refresh issue, the options page copies all devices and reinitializes it again
[07:29] <dpm> zbenjamin, yeah, so I guess that the main issue is that refreshing crashes QtC, so I can never get it to work
[07:29] <zbenjamin> dpm: huh, it crashes... you really have no luck ,....
[07:30] <dpm> yup, every time
[07:30] <zbenjamin> dpm: thats weird :/
[07:31] <zbenjamin> dpm: and without debug symbols we can not see what it is :(. Must be some special case
[07:32] <zbenjamin> dpm: start qtc with the device detached and attach it later
[07:32] <zbenjamin> dpm: maybe that works
[07:32] <zbenjamin> dpm: its no real solution but maybe a workaround
[07:33] <dpm> zbenjamin, I've tried all combinations, but I always seem to get the crash. Here's an extract of the CLI output of QtC when it crashes: http://pastebin.ubuntu.com/7320455/
[07:34] <zbenjamin> dpm: hm ok detach all devices, remove them from the devicesmanager, restart, detach them and let  QtC pick them up
[07:34] <zbenjamin> dpm: that looks like the device is not known in the device manager but it thinks it is
[07:36] <dpm> zbenjamin, ha, that worked! I can see the device in green in the left sidebar. Will try to run the app on the device now..
[07:36] <zbenjamin> dpm: ok good :)
[07:39] <dpm> zbenjamin, ok, we're making progress: now the deployment worked, but it didn't manage to run the app -> http://pastebin.ubuntu.com/7320480/ is this related to the fact that I've got 2 run configs (filemanager, ubuntu-filemanager-app)? I'm not sure why or which one I should pick
[07:41] <dpm> it seems the QtC script tries to launch the app from ~/dev_tmp/filemanager, but it copied the files to ~/dev_tmp/com.ubuntu.filemanager
[07:42] <zbenjamin> i'm going to try it
[07:50] <zbenjamin> dpm: well the desktop file says EXEC=filemanager, which means the code awaits the binary to be in the root of the click package
[07:51] <zbenjamin> dpm: seems the click launcher sets PATH to the bin directory :/ which the launcher code does not obviously
[07:52] <dpm> zbenjamin, yeah, in the click package the binary is in lib/<arch>/bin
[07:53] <zbenjamin> dpm: i need to set that path, however you can workaround it by hardcoding the Exec path there for now, sorry
[07:54] <dpm> zbenjamin, no big deal for now - do you want me to file a bug for it?. However, I still don't understand why there are 2 run configs
[07:54] <zbenjamin> dpm: every plugin in QtC can create its own runconfig, i can not interfere with that sadly :/
[07:56] <dpm> zbenjamin, what does that mean? That one of the runconfigs is not valid? Which one should I use?
[07:57] <zbenjamin> dpm: yes, thats the case, the problem is that cmakeplugin will automatically create a runconfig if the project creates a executable and the connected device is a linux device
[08:01] <dpm> zbenjamin, sorry for the basic questions, but I need to make sure I understand this to be able to answer developers when they ask about it. So is the cmakeplugin not our fork of the original plugin? Why don't we have control over the runconfigs that are created? And as it stands now, which one of the two runconfigs should we tell developers to ignore/delete?
[08:02] <zbenjamin> dpm: the problem is first if i make cmakeplugin stop to create runconfigs it will break other projects taht use RemoteLinux devices but not our plugin
[08:03] <zbenjamin> dpm: cmakeplugin has no knowledge if a project is a ubuntu project or not
[08:03] <dpm> ok, gotcha so far
[08:03] <zbenjamin> dpm: which one to choose is harder, maybe i should prefix it with ubuntu-<runconfigname>
[08:06] <dpm> zbenjamin, rather than adding the prefix, is there a way to automatically select the right config?
[08:06] <zbenjamin> dpm: i could use some trickery i gues
[08:07] <dpm> zbenjamin, and for the file manager app, which runconfig should I be using: 'filemanager' or 'ubuntu-filemanager-app'?
[08:09] <zbenjamin> ubuntu-filemanager-app, its the one that has no options
[08:09] <zbenjamin> dpm: i set up working dir automatically thats why you can not change it in our runconfigs
[08:10] <dpm> zbenjamin, cool, thanks. Will try to hardcode the path to the executable in the .desktop file now to see if I can get it to run
[08:20] <DanChapman> Good Morning
[08:31] <dpm> morning DanChapman
[08:31] <dpm> mzanetti, around?
[08:31] <mzanetti> dpm: hey
[08:32] <dpm> hey, morning, do you have a few mins for a couple of general Qt questions?
[08:32] <mzanetti> dpm: sure
[08:34] <dpm> mzanetti, cool, thanks. So the file manager app is similar to reminders in the sense that it's got a QML frontend and a C++ plugin backend. Recently we merged the two repos (previously they were in two different branches), but now I cannot get the app to find the plugin that we ship in the same package
[08:35] <dpm> Looking at reminders, it does not set any special import dirs, but still it finds the plugin shipped in the click package
[08:36] <dpm> i.e. the executable is on lib/arm-linux-gnueabihf/bin, and the plugin is on lib/arm-linux-gnueabihf
[08:37] <dpm> mzanetti, howcome the reminders app finds the plugin that it's on ../Evernote, if there are no specific additional import paths defined anywhere?
[08:38] <mzanetti> dpm: src/app/main.cpp:41: importPathList.append(QDir::currentPath() + "/../plugin/");
[08:39] <mzanetti> without having verified it, I think this might be it. ^
[08:39] <dpm> mzanetti, I saw that, but that's not the installation path of the plugin, is it?
[08:39] <dpm> I thought that would only be needed at runtime on the desktop
[08:39] <mzanetti> hm, yep... you're right
[08:39] <dpm> that seems to be the build path, rather than the installation path
[08:41] <dpm> then perhaps the lib/arm-linux-gnueabihf location within a click installation is added by default to the list if import paths, but that doesn't explain why the file manager plugin cannot be found
[08:42] <dpm> ah
[08:42] <dpm> the lib is called libfolderlistmodel.so
[08:43] <dpm> and the qmldir file says:
[08:43] <dpm> module org.nemomobile.folderlistmodel
[08:43] <dpm> plugin nemofolderlistmodel
[08:43] <dpm> I'm wondering if the lib and the plugin line should be called the same and that's why the plugin cannot be found?
[08:44] <mzanetti> dpm: yes. it needs to be the same
[08:45] <mzanetti> dpm: well, if the lib is called libfoobar.so, the qmldir file needs to say "foobar"
[08:45] <dpm> mzanetti, yeah, let me try that
[08:56] <dpm> aha, that was it, yes. Thanks mzanetti
[08:57] <mzanetti> np
[09:09] <dpm> popey, when you've got a minute, could you review this one -> https://code.launchpad.net/~dpm/ubuntu-filemanager-app/fix-libname/+merge/217007
[09:16] <popey> dpm: sure...
[09:23] <popey> dpm: i opened the cmakelists and it didn't prompt me to install an armhf kit
[09:24] <popey> dpm: i get this https://imgur.com/dCZBIak
[09:27] <justCarakas> no jamesTait today ?
[09:38] <dpm> popey, sorry, I was otp, looking now...
[09:45] <dpm> popey, it seems you don't have a chroot to do armhf builds in Qt Creator yet, so it doesn't show you the kit. I've now added the instructions on how to create one at https://code.launchpad.net/~dpm/ubuntu-filemanager-app/fix-libname/+merge/217007
[09:46] <popey> dpm: indeed I don't
[09:47] <popey> ---Click exited with errors, please check the output---Error executing command as another user: Not authorized
[09:47] <popey> ☹
[09:47]  * popey starts again
[09:48] <popey> ok, now I get a sudo prompt...
[09:48] <dpm> popey, yeah, IIRC, that's part of the creation of the chroot
[09:48] <dpm> popey, the good news is that you only need to create it once and you can then use it for all projects you open in QtC. If it's too much of a hassle, the other option for checking that the branch works is simply to install the .click I added as a URL in the MP
[09:55] <popey> dpm: i already did that and it worked on the device
[09:55] <popey> wanted to do both
[09:55] <dpm> ok, cool :)
[09:56] <popey> i had no idea about these armhf kits!
[09:58] <dpm> popey, yeah, they're pretty cool, it makes it really easy to cross-compile and create click packages :)
[10:04] <popey> dpm: i get this when I ctrl+r https://imgur.com/zOPI2VH
[10:05] <dpm> popey, you need to follow the steps to install libtag1-dev in the MP's description
[10:05] <popey> i did that
[10:06] <popey> dpm: ah, i had the lib in the armhf chroot, but not on my desktop
[10:07] <dpm> popey, you don't need to have it on your desktop, let me have a look at your screenshot again
[10:07] <dpm> ah, I see...
[10:07] <dpm> popey, on the icon just above the play button on the left bottom corner of QtC
[10:08] <dpm> click on it and select the UbuntuSDK kit
[10:08] <dpm> you're now compiling the app on your desktop using the desktop kit
[10:08] <dpm> but you want to compile it in the arm chroot using the UbuntuSDK kit
[10:08] <popey> ah
[10:09] <dpm> zbenjamin, ok, filed bug 1312094 - I think that should then cover all of the issues we discussed earlier, thanks for the help!
[10:09] <ubot2> Launchpad bug 1312094 in qtcreator-plugin-ubuntu "Cannot run cmake projects on the device" [Undecided,New] https://launchpad.net/bugs/1312094
[10:21] <popey> battling with getting stuff into the device
[10:22] <popey> :-1: error: Could not connect to host: Server rejected key.
[10:22] <popey> Is the device connected and set up for network access?
[10:22]  * popey tries another device I've not futzed with
[10:29] <popey> dpm: zbenjamin on my device I get the above error after just plugging it in and trying to deploy from sdk to it..
[10:33] <dpm> popey, I had issues too, I had to delete the device from Qt Creator. Try this: 1) Detach all devices 2) Go to Tools > Options > Devices and delete all "Ubuntu Device" entries, 3) Restart Qt Creator and 4) Reattach your device and let Qt Creator configure it for you
[10:33] <dpm> see the conversation around 8:17 your time this morning for more details
[10:39] <popey> k
[10:42] <popey> hmm, now I get "No executable specified". when I try to run..
[10:42] <popey> i have modified the Exec line in desktop.in
[10:43] <popey> hmm, seems i needed to hit the button and select com.ubuntu.filemanager above the play button...
[10:47] <popey> dpm: now it can't find the manifest.json
[10:48] <popey> dpm: sorry, not seen all these issues before, thought it would just be a case of checking out your branch and pressing "play"
[10:53] <popey>  click: error: directory "/tmp/build-fix-libname-UbuntuSDK_for_armhf_GCC_ubuntu_sdk_14_04_trusty-Default/.ubuntu-sdk-deploy" does not contain manifest file "manifest.json"
[10:54] <dpm> wait, I had this issue this morning too
[10:54] <dpm> popey, oh, are you trying to build the click package too?
[10:55] <popey> well, i tried that, but I'm just pressing ctrl+r in qtc
[10:55] <dpm> ah, yeah, I see, the build needs the click variable to be set too, just a sec
[10:57] <dpm> popey, you can do the following: 1) go to the Projects tab 2) click on the "Build" subtab of the "UbuntuSDK for armhf..." tab 3) Then go to the "CMake arguments" text field and add "-DCLICK_MODE=on" without the quotes
[11:03] <popey> \o/ dpm
[11:03] <popey> builds and runs on device
[11:03] <dpm> *\o/*
[11:04] <popey> nice one.
[12:14] <dpm> thanks popey, would you mind top-approving https://code.launchpad.net/~dpm/ubuntu-filemanager-app/fix-libname/+merge/217007 then?
[12:14] <popey> done
[12:20] <dpm> awesome
[12:21] <dpm> popey, next step is to get it working again with click-buddy, probably this evening. Unfortunately we'll loose the ability to build the click with Qt Creator
[12:21] <dpm> but happy to make the change if it helps testing prior to the store upload
[12:27] <pmcgowan> dpm, bzoltan can we please align click-buddy with qtc
[12:28] <bzoltan> dpm: why would we loose the ability to build the click with Qt Creator?
[12:29] <dpm> bzoltan, pmcgowan, zbenjamin and I had a conversation about it last week. The core apps that use cmake have a manifest.json.in file that gets variables expanded during builds
[12:30] <dpm> that is not easy to make compatible with the manifest editor in QtC
[12:30] <dpm> bbl, call
[12:30] <pmcgowan> bzoltan, can you track a bug on this
[12:30] <bzoltan> dpm: in that case the click-body should use a different solution
[12:31] <zbenjamin> i disagree here, that should work with click buddy, the cmake project files just need to correctly install the manifest.json file, i doubt it depends on the manifest.json.in file name
[12:31] <zbenjamin> click-buddy also just does a make install in a local directory and packages its contents afaik
[12:32] <zbenjamin> dpm: bzoltan ^
[12:32] <bzoltan> pmcgowan:  I am familiar with the topic and we had discussions about it ... sadly yet again  a showcase example that things change under/behind the SDK and so force use to implement quick and dirty hackarounds to provide the same features.
[12:33] <pmcgowan> bzoltan, so I don't know the proper resolution but need to align
[12:37] <zbenjamin> dpm: our solution was to name the manifest.json.in file manifest.json and put it into the project root. You still can use it as a configure file in cmake it does not care about the naming
[12:39] <sergiusens> dpm: you can use click-buddy and a manifest.json in the project root
[12:39] <sergiusens> dpm: and do some sedding to add the bits we use for ci (for core apps)
[12:40] <sergiusens> bzoltan: this was implemented in october last year fwiw; the click-buddy thing i just sugar coating
[12:40] <sergiusens> s/i/is/
[12:41] <bzoltan> sergiusens:  OK... sorry :) I thought there is a new change
[12:41] <sergiusens> no, it's the same thing going on
[12:41] <bzoltan> sergiusens:  we had talked about it by then  too
[12:41] <sergiusens> yes
[12:41] <sergiusens> it's something I was hoping to tackle during sprint time so we can align easier
[12:42] <sergiusens> but if it is really pressing, we can do it sooner rather than later
[12:49] <pmcgowan> sergiusens, just want to avoid the need to choose which tool from us people use, should not be a choice, they should all work
[13:42] <dpm> sergiusens, bzoltan1, sorry, I just got off the phone. Yeah, I know click-buddy can work with manifest.json on the root directory. Picking the filemanager example it's the variable expansion bit that does not work with click-buddy (or that I can't figure out how to get working). Let me have another look at it now
[13:43] <sergiusens> dpm: you can go back to hardcoding it
[13:43] <sergiusens> if it comes to it
[13:43] <bzoltan1> dpm: OK. I checked it and as zbenjamin said there should not be any problem
[13:44] <dpm> sergiusens, yeah, hardcoding is what I've had to do now, but IIRC from what I tried last week, click-buddy expects a valid bzr revision to be set in the manifest
[13:44] <dpm> and that's where it complained
[13:44] <dpm> sergiusens, you can have a look at lp:ubuntu-filemanager-app and see where it fails
[13:44] <zbenjamin> why can't you substitute? does cmake require a input file to end with .in?
[13:45] <sergiusens> zbenjamin: I don't see a reason it should
[13:45] <dpm> zbenjamin, that's what I'm going to try next. The .in ending for files that are to be generated is a convention, not a requirement
[13:45] <zbenjamin> dpm: yeah thats what i thought too
[13:46] <dpm> although it might be a bit confusing to have a source file with variables to be expanded and the same file name with the variables resolved, with the same name
[13:47] <sergiusens> zbenjamin: will qtc flush out the unknown json entries?
[13:49] <zbenjamin> sergiusens: no i think it should just ignore them
[13:49] <zbenjamin> sergiusens: but it still has to be valid json
[14:01] <dpm> fginther, do you have any ideas why https://code.launchpad.net/~dpm/ubuntu-filemanager-app/fix-libname/+merge/217007 initially passed the test and then after top-approving without changes it failed?
[14:04] <sergiusens> zbenjamin: dpm given the prior hypothesis and proven true; there should be no issues with what was suggested; we would just need to define the click namespace, name, et.al. in the manifest and not through expansion; just keeping the x- entries as expanded elements
[14:16] <dpm> sergiusens, zbenjamin, is this what you were thinking of? https://code.launchpad.net/~dpm/ubuntu-filemanager-app/click-everywhere/+merge/217056
[14:17] <zbenjamin> dpm: yeps
[14:20] <sergiusens> zbenjamin: dpm yes; the same logic applied to the apparmor stuff
[14:21] <dpm> sergiusens, but the apparmor.json file does not really need variable substitution, right?
[14:21] <sergiusens> dpm: 28         "vcs-bzr": "lp:ubuntu-filemanager-app", I guess I missed that; this was also overrideable
[14:21] <sergiusens> dpm: I don't think it does
[14:21] <sergiusens> dpm: there's an apparmor profile per appname
[14:22] <sergiusens> dpm: oh wait; let me check for real
[14:22] <dpm> ok
[14:23] <sergiusens> dpm: yeah, hooks per appname are defined in manifest.json and point to the correct relative path to the apparmor.json
[14:23] <sergiusens> dpm: this means you will have to hardcode the desktop file et.al. as well
[14:24] <sergiusens> dpm: and in case of the filemanager, we will also need to hardcode architecture
[14:24] <dpm> sergiusens, so far I'm hardcoding everything I can except for @BZR_REVNO@
[14:24] <sergiusens> dpm: ok
[14:24] <dpm> at least to prove it all works
[14:25] <dpm> then we can do substitution of further variables if needed
[14:25] <sergiusens> dpm: I wonder if we can create a var list from that manifest to use as vars in cmake so we set those in one place only
[14:26] <dpm> sergiusens, not sure I can follow: what advantages would that bring as opposed to declaring them in the top CMakeLists.txt file?
[14:27] <dpm> the manifest and the vars would still be in 2 different files, right?
[14:29] <sergiusens> dpm: to declare them in one location only
[14:29] <dpm> where would the location be?
[14:30] <sergiusens> dpm: the manifest is now
[14:31] <dpm> yeah, right now they're defined in CMakeLists.txt and expanded in manifest.json. Where would you put them in the future?
[14:32] <dpm> sergiusens, ok, now that it seems to work in Qt Creator, I'm trying to use click-buddy with the same build dir as QtC - Running
[14:32] <dpm> $ click-buddy --dir ../build-fix-libname-UbuntuSDK_for_armhf_GCC_ubuntu_sdk_14_04_trusty-Default/ --arch armhf
[14:32] <dpm> shows me the help for click-buddy, why is that? Do I need to specify the framework too?
[14:32]  * dpm tries
[14:33] <dpm> no joy
[14:38] <sergiusens> dpm: you will have to run it from the source dir I think
[14:39] <dpm> sergiusens, I was told by zbenjamin that if I do a cmake run from the source dir, it will break my QtC setup. Does click-buddy builds in there or does it do the build somewhere else in a temp dir?
[14:40] <sergiusens> dpm: then that's something we need to fix
[14:40] <dpm> so I'm back to square 1
[14:41] <dpm> I'll try in any case :)
[14:42] <zbenjamin> sergiusens: hmm? i thought click-buddy creates a builddir
[14:42] <zbenjamin> sergiusens: builddir=$(mktemp -d)
[14:43] <dpm> yeah, I think it might have done. It seems to have worked in any case
[16:43] <dpm> balloons, you've got filemanager mail :)
[16:44] <balloons> dpm, I saw your MP's..
[16:44] <balloons> I was excited to see the bzr revno issue was the only one
[17:21] <balloons> ahayzen, ping
[17:21] <ahayzen> balloons, pong
[17:21] <balloons> ahayzen, can you confirm https://code.launchpad.net/~nskaggs/music-app/fix-1292044/+merge/211637 so it can merge? :-)
[17:22] <ahayzen> balloons, i'll have a look at it tonight i need to run some other AP tests anyway :)
[17:22] <balloons> ahayzen, marvelous ty
[17:22] <ahayzen> balloons, damn coursework getting in the way of fun :/
[17:23] <balloons> hah.. well, this is the last bit of it, so keep on it for a couple more weeks
[17:24] <ahayzen> balloons, yep for this year then can have loads of fun in the summer break :)
[18:19] <pedro_r_marques> I'm trying to build a source package on ubuntu... i've  <pkg>.debian.targ.gz <pkg>.dsc <pkg>.orig.tar.gz how do i test them ?
[18:27] <sarnold> pedro_r_marques: if you just want to build this one package just this one time, check out dpkg-buildpackage -- if you want to build packages on a regular basis, I suggest setting up schroot and sbuild, they will help you get nicely repeatable builds
[18:27] <pedro_r_marques> sarnold: thank you for the pointers
[18:28] <pedro_r_marques> i was going down the path of using pbuilder
[18:32] <sarnold> some folks do like pbuilder, but sbuild is closer to the buildds, so it's the method I've been using :)
[18:52] <rickspencer3> o/ all
[19:28] <rickspencer3> mhall119, are there any docs on using download manager in my app?
[20:15] <aquarius> so, popey was asking about having a Touch app start a second process (basically, doing 'system("some-binary &")' from Qt
[20:15] <aquarius> is that allowed?
[20:16] <aquarius> this might be a jdstrand/mdeslaur question about apparmor, or a tvoss question about the app lifecycle
[20:16] <popey> e.g. a local client and server separate binaries on the phone, part of one app started via upstart
[20:17] <mdeslaur> I believe it should be allowed, yes, if they are both in the same package and the same private directory
[20:17] <aquarius> perhaps all my app's processes are in a cgroup and the app lifecycle thing suspends the whole cgroup?
[20:17] <jdstrand> it is fine from a confinement perspective, but app lifecycle won't allow it
[20:17] <mdeslaur> oh, that I know absolutely nothing about, sorry
[20:17] <aquarius> mdeslaur, yeah, this is "the app ships two binaries" -- it's not running something it doesn't own
[20:17] <aquarius> jdstrand, ah. so, what happens if I start a second process?
[20:18] <jdstrand> it will run until the app is backgrounded, at which point the process group will be sent STOP
[20:18] <jdstrand> (or worse)
[20:18] <aquarius> ah
[20:18] <aquarius> that's fine though
[20:18] <popey> thats fine, surely.
[20:18] <aquarius> as long as the whole cgroup is started again when the app is foregrounded
[20:18] <jdstrand> I think UAL was updated to put everything in a cgroup recently... not sure. I'm not an expert on app lifecycle
[20:18] <popey> i only want MyApp which contains "MyApp Server binary" and "MyApp Client binary"
[20:19] <popey> where Client is started as part of Myapp from upstart, and that immediately checks for and launches Server
[20:19] <popey> then connects to it
[20:19] <aquarius> jdstrand, the use case here is that the "app" is two binaries -- a tiny web server, and an html container, and the HTML in the HTML container connects to the webserver.
[20:19] <jdstrand> I think you would need to handle the state for the second app (ie, you might have to start it yourself since you were the one that started it in the first plac
[20:19] <jdstrand> place
[20:19] <popey> its not a second app
[20:19] <popey> its two binaries in one app
[20:20] <jdstrand> that's what I meant
[20:20] <popey> ah okay
[20:20] <jdstrand> second process
[20:20] <popey> aquarius: sounds like someone needs to test this ☻
[20:21] <jdstrand> popey: on a totally unrelated note, but since I have you-- istr you said you like blabble?
[20:21] <aquarius> popey, it might be easier to just have one process which is both the server and the container -- http://stefanfrings.de/qtwebapp/index-en.html seems to be a Qt C++ webserver which is maintained and up-to-date. It would mean that you have to write a noddy C++ programme to put this in and start the web container, rathe than just using the built-in web container, but if you can find a C++ Qt person that ought to
[20:21] <aquarius>  be trivial
[20:21] <popey> jdstrand: i do
[20:21] <aquarius> on a second unrelated note...
[20:21] <popey> not played for a while though.
[20:21] <aquarius> how do I find out the version number of the most recently promoted phone release?
[20:21] <jdstrand> popey: you will like the next upload then-- I translated the blabble dictionary for UK and added the sowpods word list
[20:21] <popey> \o/
[20:21] <popey> Huzzah
[20:22] <jdstrand> (there are other niceties as well)
[20:22] <popey> is that a hint that you want me to review it ㋛
[20:22] <aquarius> (I can't just try an OTA upgrade because I'm dual-booting, which doesn't do OTA upgrades)
[20:22] <jdstrand> heh
[20:22] <jdstrand> sure! but I haven't uploaded it yet
[20:22] <popey> aquarius: people.canonical.com/~ogra/touch-image-stats/ is the raw
[20:22] <jdstrand> I'll definitely do it over the weekend if not sooner
[20:22] <popey> cool
[20:23] <aquarius> popey, ah, that's semi-useful, but I don't think I can know from that whether one has been promoted or not? I bet ogra_ knows the answer to this :)
[20:23] <popey> just finding it
[20:24] <popey> aquarius: system-image.ubuntu.com/ubuntu-touch/devel/mako/ also raw
[20:24] <popey> but.. from that 303 is latest
[20:24] <popey> but not worth updating to from previous promoted, its only got a few clicks (as can be seen from ogra_ link above)
[20:24] <popey> i.e. there have been no chances since last thursday
[20:24] <aquarius> popey, ahahaha! So I should look at http://system-image.ubuntu.com/ubuntu-touch/trusty/mako/ which is the trusty list
[20:25] <popey> ya
[20:25] <aquarius> and thus I can see that 303 is in the trusty queue
[20:25] <popey> ya
[20:25] <aquarius> and I'm on 296. So I can check the changes files above to see whether it's worth it.
[20:25] <aquarius> Nice one :)
[20:25] <popey> there's json in there too somewhere, you could probably write an app which told you in an indicator or something ☻
[20:26] <aquarius> brill. thank you :)
[20:29] <aquarius> nice. I shall remember how to check whether there's a new promoted image now: http://system-image.ubuntu.com/ubuntu-touch/trusty/mako/ to find out what's been promoted, and people.canonical.com/~ogra/touch-image-stats/ to find out what happened in that image. Cool. :)
[20:35] <pmcgowan> aquarius, btw I curse you and your Riddling
[20:35]  * aquarius grins
[20:35] <aquarius> you are not alone in that. :)
[20:35] <pmcgowan> I am stuck very early on
[20:35] <aquarius> how early? If you're using the Ubuntu version, and you're stuck on level 4, I am prepared to tell you the answer.
[20:35] <aquarius> anything else, no hints. :)
[20:36] <pmcgowan> well I am at 4 indeed, but I dont want to be stupid
[20:36] <aquarius> it's not stupid
[20:36] <aquarius> it was made clear to me, after release, that that clue is very, very British specific
[20:36] <aquarius> which I did not realise.
[20:36] <pmcgowan> I even thought of that
[20:36] <pmcgowan> but didnt get it yet
[20:36] <aquarius> I changed it for the iOS/Android versions
[20:36] <aquarius> but not the Ubuntu version.
[20:36] <pmcgowan> lol
[20:37] <aquarius> So, if you want a hint, I can give you a hint :)
[20:37] <pmcgowan> maybe british is enough
[20:37] <pmcgowan> so far it wasnt though
[20:38] <pmcgowan> aquarius, is beer involved?
[20:38] <aquarius> pmcgowan, well... if you decide you want a hint, here is a hint, rot13ed so that you can choose to not read it until you want to: zntcvrf
[20:38] <aquarius> am prepared to hint for that clue because it's basically unfair if you're not lucky enough to be British ;)
[20:39] <pmcgowan> lucky?
[20:39] <aquarius> indeed :)
[20:39] <pmcgowan> hehe
[20:40] <pmcgowan> thanks will try once more before opening the hint
[20:40] <aquarius> no worries.
[20:44] <beuno> I am waiting for paid apps to be allowed
[20:44] <beuno> and will unpack the riddling app
[20:44] <beuno> and sell an answers to riddling app
[20:44] <beuno> ka-ching
[20:45] <pmcgowan> brilliant
[21:03] <pmcgowan> aquarius, btw the app exposes a bug on latest, if the screen goes off, then the field wont take focus again to get the osk up
[21:04] <pmcgowan> not suer its the app or OSK or toolkit
[21:04] <aquarius> pmcgowan, hrm
[21:04] <aquarius> that used to work
[21:04] <aquarius> so if it now doesn't, that's a regression bug in the toolkit, in my opinion
[21:04] <aquarius> but perhaps I was donig something wrong before
[21:05] <pmcgowan> thats the question
[21:05] <pmcgowan> have not yet seen it elsewhere
[21:11] <Elleo> aquarius: I still never got passed El Paso, curse you ;)
[21:13] <aquarius> Elleo, lots of other people got stuck there too...
[21:13] <aquarius> there is some discussion of it on reddit threads
[21:13] <Elleo> yeah, I'm too stubborn to try and cheat
[21:14] <Elleo> plus I have to start over after doing a --wipe a while back
[21:14] <Elleo> should have thought to backup my riddling progress, it was the only important thing on the phone ;)
[21:14]  * aquarius laughs!
[21:15] <aquarius> the game is not *that* big; you can type in all the answers in about five minutes
[21:15] <aquarius> I know this because I've done it :)
[21:15] <Elleo> heh
[21:15] <aquarius> I have the advantage of not having to re-research them all every time, though
[21:15] <Elleo> yeah
[21:17] <pmcgowan> aquarius, would never have gotten that, but I'm cruising now
[21:18] <aquarius> pmcgowan, yeah -- that's why the hint, because that clue is just flat out unfair if you're not from here. I didn't realise that when I wrote it
[21:18] <aquarius> but I did when every single person in America complained ;)
[21:18] <Elleo> heh
[21:18] <pmcgowan> so fix our version!
[21:19] <Elleo> personally I think a british bias is a great feature ;)
[21:19] <pmcgowan> yeah we need answers in u1db
[21:19] <aquarius> pmcgowan, the reason I haven't is that the android/ios versions are phonegap; I could completely redo the Ubuntu version as phonegap too, but that's a bunch of work which I don't have a lot of time to do, and it works at the moment :)
[21:19] <aquarius> the answers are in u1db ni the Ubuntu version ;)
[21:19] <pmcgowan> ah
[21:19] <pmcgowan> but not syncd yet - thats my problem
[21:20] <pmcgowan> aquarius, we are looking for good phonegap apps if you got some
[21:20] <pmcgowan> would be curious your experience with that
[21:22] <aquarius> pmcgowan, when I do Riddling 2 (or whatever comes next) it'll be phonegap, and for Ubuntu, Android, and iOS
[21:23] <pmcgowan> aquarius, so far we have few apps using it, so would be good to know its worth keeping it up, was hoping more apps would be ported
[21:24] <aquarius> *nod*
[21:42] <aquarius> Is there an sftp app for phone yet?
[21:48] <aquarius> if not I may have to put one together so I can get books on the phone :)
[21:49] <aquarius> popey, that's actually relevant to our question above, because I'm not writing it in c++, so I'd shell out to an sftp binary...
[21:49] <popey> and then you'd be unable to write to anywhere that the books app can see
[21:50] <aquarius> no no, I'll download it and then content hub the downloaded thing
[21:50] <aquarius> that's precisely how I get books into ibooks.
[21:50] <popey> oh
[21:50] <popey> ok
[21:51] <aquarius> I think I'll have to handle the download myself with the binary, rather than using the download service, because the download service is for http, not for sftp
[21:51] <aquarius> which would be sad, but not critical.
[21:51] <LeartS> Hi guys! I just downloaded the trunk of a dimple desktop app that has been "dead" for years because I wanted to try to add indicator support. (as it is now it's impossible to use the app menu).
[21:52] <aquarius> and I'd need a tiny amount of C++ to run the binary. (This is another perfect example of a component: I'd love to be able to do "ucs install binary-runner" and have it install a tiny component which provides a QML widget to run a binary that I shipped :))
[21:52] <LeartS> So I downloaded the trunk, opened the main .py file, added a simple `import appindicator` at the start and launched it to see if it gave some import error -> the indicator was already working
[21:53] <LeartS> like, 100% implemented. Any material/tutorial/guide on this?
[22:48] <aquarius> jdstrand, on the subject of running a second binary from my app, I'd like to run ssh. There's already an ssh binary on the device. What app confinement settings do I need to ask for to allow me to run it? (I'm OK if this means extra scrutiny in the app store, or that it can't go into the app store at all)
[22:50] <Elleo> aquarius: in the very worst case I expect you could set the template to unconfined in your app armor .json file
[22:50] <Elleo> presumably finer grained stuff should be possible
[22:50] <Elleo> as I think the terminal app runs under confinement doesn't it?
[22:50] <sarnold> aquarius: you'd probably want to add '/usr/bin/ssh ix,' sorts of rules to the profile, and I don't tihnk we've allowed that in the slightest...
[22:50] <Elleo> so maybe have a look at what that does
[22:51] <aquarius> ooh, good thought, the terminal app
[22:51] <Elleo> not certain that it's confined, but it'd be a good thing to check
[22:53] <aquarius> how do I type a Ctrl in the terminal app?
[22:54] <jdstrand> we don't allow ix in the policy. either run the app with the unconfined template or ship it as part of your package
[22:54] <jdstrand> aquarius: long press the screen gives you some things
[22:54] <jdstrand> aquarius: you can also enable various panels from the bottom toolbar
[22:56] <aquarius> hahahaha!
[22:56] <aquarius> I forgot about the terminal app
[22:56] <aquarius> who needs an sftp app? not me
[22:56] <aquarius> I can just ssh from the terminal app and forward a port
[22:56] <aquarius> victory!
[22:57] <sarnold> \o/
[22:59] <aquarius> now all I need is for the browser to be able to download things and offer them via the content hub, and for beru to be able to accept books via the content hub. Fantastic.
[22:59] <aquarius> another step closer to victory
[23:00] <aquarius> although it is a personal victory and one which does not help other Ubuntu phone owners :(
[23:01] <aquarius> also, the terminal app shows you what you're typing in
[23:01] <aquarius> even if it's a password
[23:01] <aquarius> I understand why it does it, but it's pretty disconcerting to see my password on the screen :)
[23:03] <sarnold> aquarius: yikes it does? that doesn't sound right :)
[23:03] <sarnold> aquarius: can you please file a bug on that to make sure it doesn't get lost? :)
[23:07] <popey> aquarius: known bug
[23:07] <popey> bug 1307386
[23:07] <ubot2> Launchpad bug 1307386 in Ubuntu Terminal App "Terminal should not use assistive technologies" [Undecided,New] https://launchpad.net/bugs/1307386
[23:07] <aquarius> ah cool
[23:07] <sarnold> popey: yay thanks :)
[23:08] <aquarius> I like that it shows me text as I type it -- it's like mosh
[23:08] <aquarius> and I'd like it to show me password text as I type it, but then replace with * :-)