[03:50] <Makalak> guys is ubuntu touch repo being updated?
[03:51] <Makalak> since i cant seem to be able to get it to build
[03:51] <Makalak> i keep getting error about certain files missing.... and after i replace them, that leads to more errors down the line... certain types dont match etc...
[05:36] <JBar> Can I ask a Ubuntu Touch installation newb question here? I have already searched for an answer
[05:39] <lotuspsychje> !devices | JBar
[05:48] <J_Bar> what chat room do i go to for ubuntu touch install questions?
[05:52] <nhaines> J_Bar: depends on the device.
[05:57] <J_Bar> I just installed ubuntu touch to my nexus 4. It went without a hitch. Now, do I need to lock the bootloader after I am done installing it, or is that not even applicable?
[06:03] <nhaines> Not applicable.  Locking the bootloader just prevents you from flashing the device in the future (or until you unlock it).
[06:04] <nhaines> Unlocking it will cause the phone to erase your user data, though, so unless you have an actual security concern, you may want to just leave it unlocked.
[06:05] <J_Bar> Got it. Thank you very much.
[06:05] <nhaines> You're welcome.  Sorry for the delay.  Have a lot of windows open at the moment.  :)
[12:25] <henri> 1
[12:43] <E524> Hi all, happy new year! i don't understand, if i have my device in Developer mode, how can i update the system and it's programs? is there a good read for that?
[12:44] <E524> btw: i have dualboot on a nexus4 if this is important to my question
[12:48] <jgdx> E524, you can use ubuntu-device-flash
[12:48] <jgdx> however, I can't speak for dual booters.
[12:52] <E524> jgdx: thanks, at least i have the key-word i have to search for. google will take it form here ;)
[12:56] <jgdx> E524, right, I think that's in the phablet-tools package
[12:56] <jgdx> which includes gems like phablet-screenshot, phablet-shell and phablet-config :)
[13:00] <E524> jgdx: i see there is a lot to read :)
[14:07] <srwood> #ubuntu-us-tx
[14:31] <damn> help me seeting ubuntu emulator
[15:45] <bentech4you> i have installed ubuntu touch on my nexux 4 from devel channel. how can i enable ssh access.
[15:46] <bentech4you> ssh is running. but when i try to connect to that IP, i am getting error like no authentication mechanism or something liekt hat
[15:47] <bentech4you> is here anyone ? please help me to fix this
[16:30] <aquarius> Elleo, ping: you around?
[17:43] <CarlosMazieri> bentech4you: you can do: "adb shell" then "sudo setprop persist.service.ssh true"
[17:44] <CarlosMazieri> bentech4you: then restart the phone to sedw if that works
[19:50] <Elleo> aquarius: pong
[19:50] <aquarius> Elleo, ah, is ok now, I think I've solved it :)
[19:50] <aquarius> but cheers
[19:51] <Elleo> okay, cool :)
[19:53] <aquarius> progress being made on the community component store, too.
[19:53] <Elleo> aquarius: awesome
[19:53] <aquarius> since you're good with Qt stuff, do you have a little time over tonight or the weekend when I can pick your brains about how best to set it up?
[19:55] <Elleo> sure :)
[19:55] <aquarius> sweet. when's good for you?
[19:55] <Elleo> pretty much any time in the evenings or mornings over the next couple of days
[19:55] <aquarius> oh! cool
[19:56] <aquarius> well, then, here's the thing I'm trying to decide; what should "ucs install" actually do? Specifically, where should it put the component it downloads, and what do I the app developer then have to do to use that component?
[19:58] <aquarius> I personally think that in a perfect world I'd do "ucs install elleo/somecomponent" from the command line while inside an ubutnu sdk project, and that component would be downloaded and put in the folder ubuntu_component_store/elleo/somecomponent/qml/SomeComponent.qml, and then it would magically end up on the import path so that in any other QML file in my app I can just import SomeComponent 1.0.
[19:58] <aquarius> but I'm not sure if that's a correct thing to want -- I'm open to suggestions there -- nor am I sure if that's doable with qmldir magic
[19:59] <aquarius> (obviously it'd work the same way for binary components)
[19:59] <aquarius> how would *you* want it to work?
[19:59] <Elleo> yeah, doing everything automatically might be tricky
[20:00] <aquarius> Example: I create a simple pure QML app, with one main.qml file and that's it. I then want to add two components: sil/RedRectangle (which provides a Rectangle qml object which defaults to red, and is pure QML) and elleo/CommandShell (which provides a binary compiled CommandShell{} Item component).
[20:01] <aquarius> So I do "ucs install sil/RedRectangle; ucs install elleo/CommandShell", and $SOMETHING happens. What would we then want me to have to put in main.qml to import these things?
[20:02] <aquarius> 'import CommandShell 1.0'? ' import "ubuntu_component_store" '? something else?
[20:03] <Elleo> aquarius: I'd guess ideally you want to set the QML2_IMPORT_PATH or qmlscene's -I option to ubuntu_component_store/elleo/somecomponent/ so you can just import "somecomponent"
[20:03] <Elleo> which is something you'd probably do in the .desktop file
[20:03] <aquarius> so you think it's: import "somecomponent"
[20:03] <aquarius> not: import SomeComponent 1.0
[20:03] <aquarius> ?
[20:03] <aquarius> that is: we import a directory, not an actual component?
[20:03] <Elleo> import SomeComponent 1.0
[20:04] <aquarius> ah, OK
[20:04] <Elleo> aquarius: I wasn't really thinking of that side, just the path imports in that example
[20:05] <Elleo> and using QML2_IMPORT_PATH is probably preferable over qmlscene's options, since it'll be available to c++ apps as well then
[20:06] <Elleo> but you're also going to have to make sure those files get installed in the click build dir, which in your simple example might be the current directory anyway requiring no work, but is more likely to involve modifying the cmake/qmake files generated by the SDK
[20:06] <Elleo> since that's how most people are going to start their projects
[20:06] <aquarius> hrm
[20:06] <Elleo> which gets a bit more complicated
[20:06] <aquarius> click build just bundles up the whole folder, I think?
[20:07] <aquarius> QtCreator might pretend it can't see the files if they don't end up in CMakeLists.txt, perhaps
[20:07] <aquarius> which sounds annoying
[20:07] <Elleo> click build will bundle up everything that's in the dir it's run on
[20:07] <aquarius> although perhaps we can do the equivalent of "include: ubuntu_component_store/* !important"
[20:07] <Elleo> but QtCreator will do out of tree builds iirc, so it'll depend if those files get added to the dir QtCreator runs click build on
[20:09] <aquarius> ah, right
[20:09] <Elleo> you can probably have ubuntu_component_store/ containing it's own CMakeLists.txt and ucs.pro file or something, which we modify to handle all ucs components as they get added
[20:09] <aquarius> yeah, it copies stuff to ../build-some-long-stupud-name-whatever-ProjectName-Desktop-i386-whatever
[20:09] <aquarius> forgot about that
[20:10] <Elleo> then you'd just need to detect if it's a qmake or cmake project and add add_directory(ubuntu_component_store) or include(ubuntu_component_store/ucs.pri) or something to the main project file
[20:10] <aquarius> adding its own CMakeLists.txt which we dynamically update as components are installed sounds like a good idea
[20:10] <aquarius> (this is one of the reasons why I wanted to confine it to a separate folder)
[20:12] <Elleo> yeah, keeping it separate seems safest
[20:12] <aquarius> actually...
[20:13] <aquarius> the current folder is in the import path, right?
[20:13] <Elleo> yeah
[20:13] <aquarius> and stuff has to be on the import path in a folder structure which matches its name
[20:13] <aquarius> so can't we just import ubuntu_component_store.Elleo.SomeComponent 1.0?
[20:14] <Elleo> aquarius: I think we could if the qmldir defined the modulename that way, but I wouldn't swear to it
[20:14] <aquarius> and drop a qmldir file in ./ubuntu_component_store with "module ubuntu_component_store" in it?
[20:14] <Elleo> yeah, possibly
[20:14] <aquarius> http://doc.qt.io/qt-5/qtqml-modules-identifiedmodules.html *suggests* that this is the case
[20:14] <aquarius> (we can even call it 'module UCS' which is nicer ;))
[20:15] <Elleo> yeah
[20:15] <Elleo> doing it that way would avoid namespace issues when people create two components with the same name
[20:15] <aquarius> totally
[20:15] <aquarius> this seems doable
[20:15] <aquarius> I shall experiment to see if I have correctly understood import paths.
[20:15] <aquarius> and the cmake/qmake stuff.
[20:16] <Elleo> cool, let me know if you hit any snags :)
[20:16] <aquarius> will do. Might be tomorrow before I get to it :)
[20:16] <aquarius> this was helpful! cheers
[20:16] <Elleo> glad to be useful :)
[21:06] <wwwt> hi, i am new here
[21:08] <popey> hello wwwt
[21:08] <wwwt> probably question about samsung galaxy s3 has been rised few times but if someone show me the right way to move from android to ubuntu touch i promise to not ask more stupid questions
[21:09] <popey> !devices
[21:09] <popey> that page lists supported devices
[21:11] <wwwt> ok, so the lastes version is from 2013?
[21:11] <wwwt> latest*
[21:31] <aquarius> Elleo, so, imagine you've done "ucs install sil/RedRectangle", and now you want to use that new RedRectangle component in your QML file. Would you prefer: import "ubuntu_component_store"; SilRedRectangle {}       or      import ubuntu_component_store.sil.RedRectangle 1.0; RedRectangle {}      ?
[21:31] <aquarius> Elleo, I'm not sure I'm happy with either of them
[21:32] <aquarius> maybe: import "ubuntu_component_store/sil" as sil; sil.RedRectangle {}   ? (not sure if that can even work)
[21:34] <aquarius> Elleo, it'd be          import "ubuntu_component_store/sil" as Sil; Sil.RedRectangle {}             (namespaces have to begin with a capital letter)
[21:35] <aquarius> nik90_, also interested in your opinion on that
[21:36]  * nik90_ reads backlog
[21:38] <nik90_> aquarius: I would imagine importing "Ubuntu.Component.Store.Sil" as Sil; Sil.RedRectangle{} would work
[21:39] <nik90_> it follows the same format as the ubuntu sdk
[21:39] <aquarius> ooh, you think?
[21:39] <nik90_> import Ubuntu.Components.ListItems
[21:39] <nik90_> as ListItem
[21:39] <nik90_> and then ListItem.SubtitledP
[21:39] <aquarius> that needs versioning, though
[21:40] <aquarius> so it'd be: import ubuntu_component_store.sil 1.0 as Sil
[21:40] <aquarius> which can't work because there isn't one version number for all my components....
[21:40] <nik90_> hmm true
[21:41] <aquarius> So your options are, I think, these three (but please say what you *want* to type if it isn't any of them, and I'll see if it's doable!)
[21:42] <Elleo> aquarius: I have thought long and hard, and decided I don't really have a preference ;)
[21:42] <aquarius> 1. import "ubuntu_component_store"; SilRedRectangle {}
[21:42] <aquarius> 2. import ubuntu_component_store.sil.RedRectangle 1.0; RedRectangle {}
[21:42] <aquarius> 3. import "ubuntu_component_store/sil" as Sil; Sil.RedRectangle {}
[21:42] <aquarius> I do not like number 1; it means munging the component name to not have a dot in it.
[21:43] <aquarius> tbh I like number 2 the most, it's just a bit verbose.
[21:43] <nik90_> I would prefer option 2
[21:43] <nik90_> but we need to plan out how the versioning of components would work
[21:44] <aquarius> number 3 is OK, though, if everyone else prefers it -- my problem with it is that it *requires* capitalising the username, which looks weird.
[21:44] <Elleo> aquarius: as far as verbosity goes 2 is less verbose than 3 where it counts in actual usage, since RedRectangle/Sil.RedRectangle is what you'll be using everywhere whereas the import statement only happens once
[21:44] <aquarius> Elleo, yeah, and it's very clear where the component is coming from, too
[21:45] <Elleo> and 3 gets worse with usernames longer than Sil
[21:45] <nik90_> aquarius, Elleo: Btw it has to be Sil.RedRectangle{} when using that component in the code since multiple components could use the same name "RedRectangle" thereby leading to confusion
[21:45] <aquarius> nik90_, component versioning is fine -- we'll require a version number in the community component's manifest file (and define a storage place for one in the curated components), and then set that correctly in the qmldir file I create.
[21:46] <nik90_> ok
[21:46] <Elleo> nik90_: if you have two competing ones you could still do import ubuntu_component_store.sil.RedRectangle 1.0 as SilRedRectangle to disambiguate
[21:47] <nik90_> ack.
[21:47] <aquarius> nik90_, duplicate names is not a problem -- if you ucs install nik90/RedRectangle and sil/RedRectangle, then you do: import ubuntu_component_store.sil.RedRectangle 1.0 as S; import ubuntu_component_store.nik90.RedRectangle as N; N.RedRectangle{}; S.RedRectangle{}
[21:47] <aquarius> most of the time you won't have to -- only if you import two components with the same name but different authors, which ought to be pretty rare anyway :)
[21:47] <aquarius> OK. We'll go with version 2. :)
[21:48] <aquarius> is "ubuntu_component_store" too long, do we think? UCS would be nicer, but it's a bit more generic, especially since there must be a top-level folder named that.
[21:49] <aquarius> and requiring ubuntu_component_store makes it a bit more obvious.
[21:50] <nik90_> well you only require one import statement per file
[21:50] <nik90_> so I would go with ubuntu_component_store
[21:51] <aquarius> *nod*
[21:51] <nik90_> with a dot if possible
[21:51] <aquarius> OK, now to work out the harder bit, which is binary components and how to put them on the import path ;)
[21:52]  * nik90_ goes to read aquarius blog post for recap
[21:52] <Elleo> aquarius, nik90_: sorry, vm died so I probably missed stuff
[21:52] <aquarius> Elleo, we decided that option 2 was best :)
[21:52] <Elleo> okay, cool
[21:53] <nik90_> Elleo: u dint miss much..option 2 and import with "Ubuntu_Component_Store" and not "UCS" as it is too short
[21:53] <aquarius> I now need to work out where .so files need to live to end up on the import path :)
[21:54] <Elleo> aquarius: for automatic multiarch stuff I think you're limited to putting them in lib/<arch>/ I guess you might want to enforce some naming on the libs to avoid namespace conflicts though
[21:54] <Elleo> like libucssilredrectangle.so
[21:55] <aquarius> Elleo, do you know how that works? is lib/$arch/ on the import path becuase Qt puts it there or because Ubuntu puts it there?
[21:55] <aquarius> I wonder if I can do something with qmldir again as I have with QML things
[21:55] <Elleo> aquarius: I would assume ubuntu puts it there
[21:55] <Elleo> aquarius: but I don't really know anything about that side of things, that's just my suspicioun
[21:56] <Elleo> suspicion*
[21:57] <aquarius> aha, multi/lib/$arch according to balloons' click package thing
[21:58] <aquarius> but that may be where it is in the click package but not on the filesystem
[21:58] <aquarius> hrm
[21:59] <aquarius> I wonder who knows about this stuff? Colin will know something but I'm not asking him because he is not the Man any more. I can never get good answers out of bzoltan_ ;-)
[22:00] <aquarius> beuno, who knows about arch-specific stuff in QtCreator?
[22:01] <aquarius> aha, balloons' multi-arch click package is instructive
[22:01] <aquarius> although there is no multi folder in it, balloons, you big liar!
[22:19] <aquarius> goldarnit, something somewhere does some magic to put lib/$arch on the import path. I do not know if that's even doable with a pure QML project which doesn't have any cmake files or anything
[22:20] <aquarius> and it's hard to find information about this because half the docs, as usual, say that you should already have been using c++ and cmake and if you weren't then you are a loser. :(
[22:31] <aquarius> tedg, ping about how Unity actually launches a QML app: in particular, I think it adds lib/$arch folders to the import path, but I do not know *how* it does this, and you might.
[22:34] <nhaines> I think it also does a few thousand NOOPs before it launches the app.
[22:45] <aquarius> nhaines, ?
[22:49] <dobey> aquarius: i think they're added by qtubuntu plug-in
[22:50] <aquarius> dobey, there is stuff in the cmake files to add bits to the import path, but I do not think that the default setup for such projects builds them as qml plugins; they're qml extensions, which isn't quite the same thing.
[22:50] <dobey> huh?
[22:50] <dobey> pure qml things are not arch specific so lib/$arch is irrelevant
[22:51] <dobey> and i meant the plug-in to qt, not the qtcreator bits to make ubuntu-sdk
[22:51] <aquarius> dobey, ah, that's useful; I didn't know there was a plugin to qt
[22:51] <dobey> if you have pure qml components, then "components/" is added to the import path for those, iirc
[22:52] <aquarius> dobey, more importantly, projects without a cmake file at all (that is: pure qml projects) don't put any folder for compiled binary plugins onto the import path.
[22:52] <dobey> why wouldn't it have a cmake file?
[22:52] <aquarius> nah, components/ isn't added by magic; you import it with ' import "components" '. I understand that bit of it :)
[22:52] <nhaines> aquarius: just a slow launch joke.
[22:52] <aquarius> apps which only use qml don't need a cmake file, and don't have one.
[22:53] <aquarius> nhaines, ah, gotcha :)
[22:54] <dobey> well, the sdk is cheating there and using the qtcreator .qmlproject stuff, sure
[22:54] <aquarius> yeah. Third party components need to be an "Extension Plugin": http://doc.qt.io/qt-5/qtqml-tutorials-extending-qml-example.html#chapter-6-writing-an-extension-plugin -- a subclass of QQmlExtensionPlugin.
[22:55] <dobey> i think all the projects created by the sdk, for "ubuntu" projects, should have cmake files, and be relatively similar. becuase right now if you create a pure qml plug-in then later decide you need to add some c++, it's a huge pain in the arse to do
[22:55] <dobey> as you are apparently discovering
[22:56] <dobey> :)
[22:56] <aquarius> but this doesn't really deal with multi-arch stuff here; it deals with multi *platform* stuff OK, in that you define your plugin with a basename ("silplugin") and then Qt takes care of loading silplugin.so on Linux and silplugin.dll on Windows. But it doesn't deal with multiarch at all, which is annoying.
[22:56] <dobey> "this" ?
[22:56] <aquarius> so the Qt people are happy for me to build an app which can be deployed as-is to both Windows and x86 Linux, but not one which can be deployed as is to both ARM Linux and x86 Linux. Irritated.
[22:57] <dobey> well, that's a bit expected
[22:57] <dobey> you're trying to do something with ubuntu sdk apps
[22:57] <dobey> the upstream qt docs doesn't know anything about ubuntu sdk apps :)
[22:58] <aquarius> this is a Qt/QML thing; I'm not doing anything Ubuntu-specific here.
[23:01] <dobey> what are you trying to do exactly anyway? you are pulling random .so files out of .bzr as "components" (or whatever you're calling them), have a pure qml project, and are trying to import them, but the SDK won't add the import paths you need to add?
[23:02] <aquarius> sort of.
[23:03] <aquarius> If the whole world was x86_64, then what I would do is just drop the libMyComponent.so into ubuntu_component_store/MyComponent along with a qmldir file which said "plugin MyComponent", and then everything's fine: a QML file in that project can just do "import MyComponent 1.0", and everything works.
[23:05] <aquarius> The issue is that, of course, we need multiple versions of the component for different arches. So I *believe* that the Unity launcher executes a QML app with qmlscene and silently adds a "-I lib/$arch" parameter to make sure that the appropriate version of a plugin is imported.
[23:05] <dobey> unity doesn't do anything additional to launch apps
[23:05] <dobey> it simply does standard fd.o .desktop file launching stuff
[23:05] <aquarius> it might be in upstart-app-launch or something
[23:06] <dobey> i don't think it adds an -I to qmlscene
[23:06] <dobey> you can verify that by running such an app on the phone, and just poking at /proc to look at the process arguments for the pid
[23:06] <aquarius> or perhaps you're right and we do nothing at all in the launch process to put lib/$arch on the import path. If that's the case then either our Qt is patched to do it, or I can't see how any apps which import a plugin actually work (because the plugins aren't on the import path)
[23:07] <aquarius> ooh, that's a good thought, looking in /proc
[23:07] <aquarius> I'll do that.
[23:07] <aquarius> well, hm
[23:07] <aquarius> it is possible that we do something special for fat click packages, and I haven't got any
[23:07] <dobey> but i'm pretty certain the "lib/$arch" import path is added by the qtubuntu plug-in to qt
[23:08] <aquarius> that sounds useful
[23:08] <aquarius> is that added on the phone only? or would it also be the case on the desktop?
[23:08] <dobey> the plug-in should be installed if you have the sdk installed at least (not sure if it's installed by default otherwise, but probably is)
[23:09] <aquarius> I should note that I have tried dropping a compiled plugin into lib/$arch with a qmldir file and importing it, and it doesn't work. But I do not know if it's not supposed to work or if it is and I'm doing something wrong :)
[23:09] <aquarius> (specifically, the import statement doesn't find the plugin)
[23:11] <dobey> oh maybe it's not installed; i see qtubuntu-desktop wasn't installed on my machine anyway
[23:11] <dobey> at least i *think* that is what does the magic
[23:12] <dobey> aquarius: if you have latest terminal version installed on your phone, then it should be a fat click i think
[23:13] <dobey> hmm, or not
[23:14] <dobey> or click is doing magic to not install the irrelevant arch directories
[23:14] <dobey> but i suspect that's not the case
[23:15] <aquarius> but *something* weird is going on with imports. Because if I make a pure QML app, and then make pure QML components which are qmldir'ed onto the import path, and then run it *with qt creator*, it works... but "qmlscene main.qml" from bash fails to find the extra components.
[23:15] <dobey> right
[23:15] <aquarius> finding how anything works in qtcreator is a nightmare, though
[23:16] <dobey> look at your .desktop file and the .qmlproject file
[23:18] <aquarius> not quite what I meant. In Projects > Run there's a "Run configuration", and "QML Scene" is selected, which is fine... but I can't find what the "QML Scene" run configuration actually *does*. It doesn't seem to be editable, or listable; I think it might be hardcoded into Qt Creator.
[23:21] <dobey> if you build a click and install it on a device, does it work when you launch it from unity?
[23:25] <aquarius> as in, a multiarch click?
[23:25] <aquarius> I haven't tried that yet
[23:26] <dobey> as in whatever you claim works under qtcreator, but not when running just "qmlscene foo"
[23:26] <aquarius> good question
[23:26] <aquarius> I will try that
[23:27] <aquarius> also, there appears to be no way in qtcreator to list what a "run configuration" actually does, at all :(
[23:27] <dobey> i think a) the .desktop adds an -I for some directory, and b) the qtubuntu-desktop plug-in does soemthing (but i don't know which code might be adding it exactly, or if it's just apparmor doing)
[23:28] <aquarius> aaargh this is so infuriating
[23:29] <dobey> eh, this isn't even a /hard/ problem :)
[23:30] <aquarius> I both agree and disagree with that -- I am confident that what I'll actually need to do to resolve it is just add one line to one file somewhere and it'll all work. But this sort of problem, where you've got no idea where to even look, I always find a lot harder than ones where I know what to do but I need to work out complex stuff to actually do it :)
[23:32] <dobey> you shouldn't have to look anywhere to make it work
[23:32] <dobey> it should just work
[23:32] <aquarius> I agree. Nonetheless it does not :)
[23:33] <dobey> well, that said, i wouldn't expect opening a terminal and typing "qmlscene foo.qml" to necessarily work
[23:38] <aquarius> I wish I didn't always come up with this stuff in the dead air period at new year. )
[23:39] <dobey> well look at it this way. if you were doing the same thing with python, i wouldn't expect "python app.py" to work without adding the extra import paths either
[23:40] <aquarius> yeah. I don't mind that much that extra import paths are being added; I mind that they're being added by invisible magic that I can't find :)
[23:40] <dobey> are you trying to do something where you have a different import path, other than under lib/$arch, when running from a click package?
[23:41] <aquarius> no. I want whatever I do to work everywhere -- I do not want to have to set things up twice, once for running from qtc and once from an installed click.
[23:41] <aquarius> I am starting to believe that that's precisely how ubuntu sdk apps work, though
[23:42] <aquarius> am trying the pure-qml-import-components-with-qmldir thing in the emulator.
[23:42] <aquarius> aha!
[23:43] <aquarius> it works in the emulator
[23:43] <aquarius> but not with just "qmlscene main.qml". So we're doing *something* different somewhere.
[23:43] <aquarius> small piece of knowledge, but useful.
[23:44] <dobey> i still don't really understand what you're trying to do exactly
[23:45] <dobey> meh, i forget how to make the proc environ file readable
[23:47] <aquarius> you're right; no import magic going on with pure qml apps. It's all working correctly with just the qmldir stuff. Which is what I would expect to happen.
[23:47] <dobey> so on the phone, QML2_IMPORT_PATH and LD_LIBRARY_PATH have the click package's lib/$arch directory
[23:48] <aquarius> ooh! do they?
[23:48] <aquarius> how do you know? looking in /proc/X/env or something?
[23:48] <dobey> i'm guessing qtcreator probably adds the project dir to it
[23:48] <dobey> yes
[23:48] <dobey> ML2_IMPORT_PATH=/usr/lib/arm-
[23:48] <dobey> linux-gnueabihf/qt5/imports:/opt/click.ubuntu.com/.click/users/phablet/com.ubunt
[23:48] <dobey> u.terminal/lib/arm-linux-gnueabihf
[23:48] <dobey> gah terminals
[23:49] <aquarius> ugh, it's all one big long string
[23:49] <aquarius> ah, with nulls in.
[23:49] <dobey> it's a PATH-style varaible
[23:50] <aquarius> QML2_IMPORT_PATH=/usr/lib/i386-linux-gnu/qt5/imports:/opt/click.ubuntu.com/.click/users/phablet/com.ubuntu.developer.sil.simple-ui/lib/i386-linux-gnu
[23:50] <aquarius> indeed
[23:50] <aquarius> there's the lib folder
[23:50] <aquarius> so... what sets that, I wonder?
[23:51] <aquarius> there's nothing in the click package itself that sets it. It's being set by *something* in the app startup process
[23:53] <dobey> click-apparmor: /usr/bin/aa-exec-click
[23:53] <dobey> that's what sets it
[23:54] <aquarius> well found!
[23:54] <aquarius> right. So that's how it works on the phone
[23:54] <dobey> and when you install a click, the hook rewrites the Exec line
[23:55] <dobey> debs are not a supported target for ubuntu sdk apps
[23:55] <dobey> so if you want to do the same thing in a deb package, you need to manually add stuff to do that
[23:56] <aquarius> I'm not worried about deb packages. What I want is for that same path to be added to the QML2_IMPORT_PATH when running the app from Qt Creator.
[23:56] <aquarius> and how best to do that from a command-line utility
[23:57] <aquarius> projectname.qmlproject has importPaths in it -- I think it'd be best to tweak that
[23:58] <dobey> you could tweak the qmlproject yes
[23:58] <dobey> (i told you to look at the qmlproject file earlier :P)
[23:58] <aquarius> you did, and I did, and that's how I know it has importPaths in it :)
[23:59] <aquarius> I was hoping there was a way to do this which worked in both places (in qtc and in the deployed app), but there clearly isn't. :)