[00:31] hey [00:32] so i would like to port ubuntu touch onto a galaxy tab 2 7.0 p3113 [00:32] help? [00:33] anyone [00:33] ? [00:34] quit [00:34] leave === chriadam|away is now known as chriadam === kyrios is now known as Guest40534 === chihchun_afk is now known as chihchun [06:17] rsalveti: hi, may i know if current ubuntu-touch already support dual screens or not? [07:16] good morning [07:25] dholbach: morning :) [07:26] hi shuduo :) [07:27] popey: could you please help me to push a bit this MR to land on the music app? https://code.launchpad.net/~canonical-platform-qa/music-app/fix1348055-do_not_depend_on_position/+merge/228051 [07:27] dholbach: hi, do you know recent build from devel channel is broken to boot with dualboot.sh on Nexus 7? [07:29] shuduo, I'm afraid I don't know - ogra_: ^ do you know? [07:30] no, sorry, it seems to work fine in the lab, tests ran and all [07:31] so it shoudl wrok [07:31] *work [07:32] ogra_: i can boot latest build of trusty on N7. latest of devel channel will fallback to android. :( [07:34] shuduo, latest devel image was 133 .... http://ci.ubuntu.com/smokeng/utopic/touch/flo/133:20140715.2:20140715.2/9079/ that are the test results for flo (N7) with that image ... seems it booted fine (a bunch of tests failed, but doesnt look earth shattering bad) [07:36] so if there are issues i would expect the dualboot app causes them [07:36] ogra_: i see the install-and-boot is passed. but do you know if it cover dualboot too? [07:37] no, we dont support any dual boot method, so we indeed dont test them+ [07:39] (up to the people that provide it to you) [07:40] ogra_: i got it. :( actually someone does wanna have a dualboot tablet [07:40] oh, i assume there are many people wanting dual boot support [07:41] ogra_: actually it worked good in previous builds. but broken in recent builds [07:41] and always works good on N4 [07:41] we might even provide it ourselves by default one day ... but today everyone is so busy to get the OS ready for the phones that will sell this year that there are simply no resources [07:41] ogra_: understood. [07:42] ogra_: do you know if current ubuntu touch support dual screens? [07:42] no, it doesnt [07:42] ogra_: ok.. got it. [07:43] (well, #ubuntu-mir might correct me, i'm not a mir dev, probably it does and i dont know ;) ) [07:44] ogra_: i see blueprint of mir is saying mir support multimonitor via xmir. so i suppose current ubuntu touch does not support it. :) [07:46] yeah, there is no working xmir for the phones yet ... it might work on the desktop indeed === chriadam is now known as chriadam|away [08:32] Good morning all; happy Tell An Old Joke Day! :-D [08:47] does anyone know how to run an click package application using command ubuntu-app-launch on the phone. I previous tried it worked. I do not know why it did not work any more. [08:51] seb128, hey, do you have time for a look at https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/1319044-carrier-design-dual-sim/+merge/227318 ? Thanks [08:51] mandel: heya, had a bit of a chat with ahayzen last night about some issues they're running into with downloads to the music app caused by bad file names, he's added the details to this bug: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1205355 [08:51] Launchpad bug 1205355 in ubuntu-download-manager "Content-Disposition is not used to get the file name" [Medium,In progress] [08:52] Elleo, yes, I have been ignoring that bug focused on others, is it affecting them really bad? [08:52] mandel: I know we discused the content-disposition file name stuff a bit in the past and it sounded like it would be quite time consuming, but I've added a comment to that bug report about a possible alternative solution specific to the browser that might be more doable [08:53] mandel: it basically stops them downloading any music from services that don't have the filename in the URL, as mediascanner is extension based [08:54] mandel: so all downloads from a lot of services like jamendo, etc. that just have a url like http://storage-new.newjamendo.com/download/track/1108495/mp32 fail to be recognised unfortunately [08:54] jgdx, hey, I can have a look, but I think Ken was going to review it (I asked him yesterday, he knows the sim stack/codebase better) [08:54] Elleo, because it is downloaded as mp32?? [08:54] mandel: yeah [08:55] seb128, ack [08:55] mandel: mediascanner ignores it because it's filename doesn't look like a music file [08:55] mandel: we work around it in the gallery for images and videos by adding the extension ourselves based on qt's mimetype detection, but music app is pure QML so isn't able to do that [08:55] Elleo, content-disposition is the way to go and I'll implement that no matter how time consuming it is, the issue will be present nevertheless if the content-disposition is not present [08:56] Elleo, what I mean is, you will have an issue if the server side does not send us that data [08:56] mandel: yeah [08:56] mandel: I think they also need to have a discussion with the mediascanner folks about their approach [08:56] Elleo, we can, as you mentioned add a hint for the extension, that is, if content disposition is not present, append .mp4 etc.. [08:56] mandel: but I think that'll be a much rarer case [08:56] Elleo, but that is a hack [08:56] Elleo, I'll get to content-disposition asap then [08:57] mandel: since most servers will either serve a URL of the form http://blah.com/music.mp3 or serve a url like http://blah.com/myservice/12323213 + a content-disposition header [08:57] so it'll at least be covering most major cases [08:57] mandel: thanks very much [08:58] Elleo, yes, I think the way to go is head request to get the content-disposition header (to ensure that we do not step on other files) if present, we are happy, if not present we user the url [08:58] mandel: yeah [08:58] Elleo, if the url is not correct, well, we will need to add something else, but lets do that later [08:59] mandel: yeah, having download manager report the mime-type as part of the final download object could be enough to let apps handle things better [09:00] or mime-type + suggested extension, since QML apps can move things via content-hub's bindings now [09:00] mandel: alternatively I guess we might just want to wrap Qt's mimetype stuff in QML and make it available as another module [09:01] Elleo, indeed.. that might mean that we have to change the api so that the finish signal provides the info and that would break a number of things [09:01] Elleo, we can add an api2 dbus api so that we mantain both [09:01] Elleo, I'd say, lets do the content-disposition for rtm, the other approach, which I like, should be done after [09:02] mandel: sounds good, I think ahayzen should be involved in any discussions for the future improvements too, since he knows more about what limitations they have internally and from mediascanner [09:02] Elleo, +1 [09:03] Elleo, I'm more than happy to make udm as robust as possible [09:05] mandel: yeah, I know it's a pain having to tackle this one, but it'll be a big improvement for things besides music app too, since we'll get much better filenames for a lot of image/video downloads too (e.g. all downloads from gmail are just a 32 bit md5sum or something at the moment) [09:06] mandel: so thanks for tacking it on :) [09:06] taking* [09:06] 32 char* [09:06] Elleo, sure, my pleasure to help with this, is something I knew about but was postponing :-/ [09:07] yeah, understandable, and I hadn't really considered the impact it'd have on music app until ahayzen raised the issue === shuduo is now known as shuduo_afk [09:27] -rw-r----- 1 phablet whoopsie 847942 Jul 22 19:58 /var/crash/_usr_bin_messaging-app.32011.crash [09:27] ev: i have that crash that didnt get submitted. shall i do something? [09:27] jus restart whoopsie and it will be sent? [09:27] asac: do you have a .upload file for it in that directory? [09:27] ev: no, neither .upload nor .uploaded [09:28] i have two other crashes that have both [09:28] asac: does manually running /usr/share/apport/whoopsie-upload-all create the .upload files? [09:29] * asac tries [09:29] seems its doing something /me waits [09:29] Collecting info for /var/crash/_usr_bin_messaging-app.32011.crash... [09:30] ev: what does that mean? interestingly i just had rebooted my phone, so i assume it should have run that on boot? [09:30] * asac thinks at that time wifi might not have been up yet [09:31] ev: now i get something waiting for upload or so [09:31] Marking /var/crash/_usr_bin_messaging-app.32011.crash for whoopsie upload [09:31] Waiting for whoopsie to upload reports (timeout: 1800 s) missing (remaining: 1800 s): /var/crash/_usr_bin_messaging-app.32011.uploaded missing (remaining: 1790 s): /var/crash/_usr_bin_messaging-app.32011.uploaded [09:31] that is looping [09:31] ev: normal? [09:32] * asac is on wifi [09:32] ping works also [09:32] * asac waits [09:32] * ev looks [09:33] ev: i think its buggy. that thing is just 800k of size and shouldnt take mor than a few secs to upload [09:33] dbarth: hello :) [09:33] asac: hi [09:34] dbarth: do you know about the webbrower-app showing only grey areas if you go to activity? [09:34] so I'm pretty sure I know the second bug you're running into, but I'm first trying to do some archeology to see why we turned what was a perfectly good set of asynchronous operations into something synchronous. [09:34] dbarth: e.g. i dont see any website surface there [09:34] asac: olivie was telling me he can't get thumbnails right now [09:34] asac: should have favicons instead [09:35] let me check the branches around [09:38] asac: so you can work through this in parallel, do you now have .upload files in /var/crash? If so, does `sudo restart whoopsie` result in .uploaded files existing in /var/crash? [09:38] asac: right, we have a branch in review to cache favicons and display them in the gray parts of the history [09:41] asac: if it keeps waiting, try restarting whoopsie; I had that a few months ago, it was due to the inotify bug [09:42] pitti: do you remember why we're waiting on whoopsie at all in whoopsie-upload-all? This seems weird to me. Apport should write the .crash file, whoopsie-upload-all should write the .upload file, and whoopsie should process the two and create the .uploaded. It should be asynchronous handoff, no? [09:43] ev: this was written for usage in CI, like the autopkgtest runner or MPs [09:43] ev: we need to block on the uploads to finish, as immediately afterwards we destroy the testbed or reset the phone [09:43] pitti: mm, wasn't whoopsie-upload-all written for the phone first, before CI was a thing? [09:43] they seem to me like two separate concerns [09:44] ev: I wrote it because we wanted to pick up crash reports from autopilot runs [09:44] you can run it with -t 1 to set the timeout to 1 second, and ignore the exit status [09:44] if you basically want async mode [09:45] or -t 0 even [09:45] ev: it was never really designed for calling manually, though; seems people now do that? [09:47] well, apport-noui calls /usr/share/apport/whoopsie-upload-all without arguments [09:48] presumably it should call it with -t 0? [09:48] err /etc/init/apport-noui.conf that is [09:48] ev: not sure -- don't we want at least some serialization there, to avoid running too much in parallel? [09:48] maybe we do [10:02] pitti: that strikes me as something better accomplished in the upstart job? Something akin to the old GTK trick of moving a timer slightly forward into the future every time you have an event, so you wait for things to settle before acting on it. [10:02] (that probably predates GTK by some significant amount of time, but that's where I first encountered it) [10:03] I don't know. I just worry that we've now made these things all dependent on one another, when they can better handle failure modes separately [10:14] ev: so, using -t 0 in the upstart job seems fine to me [10:14] oh, cool [10:14] doesn't solve the problem of whoopsie never getting triggered (above bug) [10:14] (that was an inotify problem, right?) [10:15] yeah, that's https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1340604 [10:15] Launchpad bug 1340604 in whoopsie (Ubuntu) "[phone] crash files are only uploaded on boot" [Undecided,New] [10:15] and yay, I get to make my first patch submission to apport in bloody ages [10:15] and in practice it shouldn't make a difference, as this is an "instance" job which can run in parallel anyway [10:15] ah right [10:16] pitti: ev: i restarted whoopsie, ran upload-all again [10:16] still not .uploaded [10:17] /var/crash/_usr_bin_messaging-app.32011.crash already marked for upload, skipping [10:17] yes, that's whoopsie-upload-all [10:17] if there's an .upload stamp, its job is done [10:17] hmm. but seems noone is uploading it [10:18] hm, does whoopsie has some verbose mode these days? a few months ago it was still awfully quiet [10:18] asac: can you pastebin /var/log/syslog? [10:18] in apport.log i see stuff like this: http://paste.ubuntu.com/7846754/ [10:18] not sure if thats related, but doesnt look too good [10:19] ev: http://paste.ubuntu.com/7846758/ [10:19] asac: unrelated, but indeed worrying -- that means that the kernel called apport and ripped the process away underneath it [10:19] while the kernel calls the core handler, the process ought to stay around [10:19] pitti: whats the symptom from such an error? we dont get a dump of a crash processed? [10:19] you could also `sudo stop whoopsie; sudo CRASH_DB_URL=https://daisy.ubuntu.com whoopsie -f` [10:19] e.g. no .crash file creation? [10:19] but if that happened, there's nothing that apport can do to create a .crash file anyway, so low prio [10:20] asac: yes, you won't get a crash file [10:20] ev: would that help getting to the bottom of the problem? [10:20] asac: and we can't find out what pid 7446 was [10:20] my primary objective is to help finding out whast buggy, not to get that upload done [10:20] asac: the "doesn't upload" is indeed the main concern here [10:20] pitti: ok. i guess that might be coming from our lifecycle magic? [10:20] as you did get a .crash report for another crash, so that's working in general [10:21] anyway, i have a crash file that apparently cannot be uploaded. let me know what info you need [10:21] asac: no, I don't think so; processes should be sleeping, not killed [10:21] asac: anyway, you can't kill a process while it's dumping core [10:21] would it help if i upload that somewhere? [10:21] so maybe something funky with the android kernel [10:21] ok, lets first check why the "simple" code that should upload this, doesnt do its job [10:21] asac: does ev's "run whoopsie in the foreground" command say anything? [10:21] ok if that helps, let me try [10:22] ideally that would tell what it tries to do, and perhaps spit out an error message [10:22] seems to work [10:22] http://paste.ubuntu.com/7846779/ [10:22] also got [10:22] Sent; server replied with: No error [10:22] Response code: 200 [10:22] now [10:22] so guess that worked [10:22] hmm [10:23] ev: pitti: anything you need? [10:25] hmmm interesting. If you kill the foreground process and sudo start whoopsie, then touch the .crash file, does the timestamp on .uploaded change? [10:25] I wonder if our daemonising code is busted. [10:26] ev: we could drop the "expect fork" and just run with -f? [10:26] simpler all around [10:26] ev: shall i just remove the .upload* files? [10:26] or is touch important? [10:26] and upstart logging should then work [10:26] pitti: yeah, seems reasonable [10:26] asac: sure, that's another way of doing it [10:26] but then do run whoopsie-upload-all again to create the .upload file [10:26] asac: remove the .uploaded, keep the .upload [10:27] or that ^ :) [10:27] timestamps didnt change yet. didnt remove anything, just touch [10:27] will wait a bit. [10:28] ev, asac: http://paste.ubuntu.com/7846812/ [10:28] then "sudo restart whopsie" [10:29] sudo restart whoopsie [10:29] and magically /var/log/upstart/whoopsie.log starts to exist and work [10:29] maybe that will already magically make the uploads work, but if not we should at least see why [10:31] ok /me changes conf [10:31] hmm. cannot write that conf file :) [10:32] sudo mount -o remount,rw / [10:32] pitti: can i go back to ro after? [10:32] yes [10:33] did that, waiting [10:33] no timestamp changes yet [10:34] asac: sudo tail -f /var/log/upstart/whoopsie.log [10:34] doesnt exist :( [10:35] odd [10:35] asac: ah, then you didn't restart whoopsie [10:35] double checked. the init has the right thing [10:35] asac: or perhaps try sudo stop whoopsie [10:35] sudo killall whoopsie [10:35] syslog, no? [10:35] sudo start whoopsie [10:35] whoopsie logs to syslog [10:35] ev: not any more with -f, then it goes into the upstart log [10:35] (I suppose) [10:35] oops [10:35] I mean, it does go to the upstart log [10:35] sorry, I came back and just read the bottom [10:35] you're right [10:36] not sure whether it additinally syslogs [10:36] ok now it uploaded [10:36] I missed the part where you gave him a diff to apply [10:36] restart didnt really work it seems [10:36] what does this mean? [10:36] yeah, restart might have gotten confused due to the forking change [10:36] asac: stop/kill/start ought to work though (that's what I did, even without the killall) [10:37] so this seems to work [10:37] * asac readds the expect [10:39] seb128: ping, I noticed that after flashing ubuntu touch, the time shown always default to UTC. Shouldn't it default to the local time? [10:39] nik90, not sure, there is a bug open about that though [10:40] pitti: should i keep init patched like this? [10:40] asac: what changed now? just that you get logging, or does the actual uploading work, too? [10:40] nik90, hum, I was thinking about bug #1289481, could be a different issue [10:40] bug 1289481 in ubuntu-system-settings (Ubuntu) "Default time zone is unlabelled" [Low,Triaged] https://launchpad.net/bugs/1289481 [10:40] before rebooting and going back to ro [10:40] pitti, asac: okay, so it sounds like the daemonise behaviour is broken. I'm happy to have it use -f until we get to the bottom of this. I'll make the change to the whoopsie upstart job. [10:40] pitti: the upload works [10:40] tried twice [10:40] seb128: it seems a bit weird that the user should come to the date&time settings to set his timezone manually [10:40] both time it just worked [10:41] asac: just at starting whoopsie, or also when it's already running? i. .e it picks up the new .upload? [10:41] nik90, sure, but you are talking to the wrong person there [10:41] asac: if ev agrees, I'd like to upload that whoopsie change, it's simpler anyway [10:41] nik90, settings are an UI to change settings, they don't run on start [10:41] pitti: i stop, start whoopsie [10:41] asac: so you can keep it [10:41] then it just reuploads [10:41] nik90, we need another service or unity8 or something to do the work if it needs to happen on start [10:41] nik90, but isn't that the job of the wizard? [10:42] seb128: I would think yes, but I dont remember seeing a slide in the welcome wizard which provdes that option [10:42] pitti: its wierd... stop and start doesnt return anymore [10:42] seb128: but I will talk to the designers and check the intended behavior [10:42] just sits there [10:42] nik90, the wizard is still incomplete though [10:42] nik90, sounds like the thing to do [10:43] nik90, thanks [10:43] asac: hm, that works here :/ [10:43] (with the modified job) [10:43] asac: you did drop teh "expect fork", did you? [10:43] yeah [10:43] that and added -f [10:43] * asac reboots and hopes the phone will start like this [10:44] 5 [10:44] 4 [10:44] 3 [10:44] 2 [10:44] ... [10:44] good bye phone :P [10:44] oh dear, alex rebooted himself -- human bodies can't take this very often! [10:44] lol [10:44] lol [10:46] ok the phone booted properly [10:46] * asac will keep eyes open for crashes [10:46] asac: now stop/start ought to work? [10:46] I suppose the "restart" left upstart in a weird state === Guest40534 is now known as KyriosBrastianos [10:54] pitti: ack. works now after reboot [10:59] ev: curious, curious [11:00] pitti: seems to point the finger at daemonize, no? [11:01] apparenlty [11:06] ev: so, not sure whether we should upload the -f; logging to /var/log/upstart/ might collide a bit with ogra's goal of logging everything to /var/log/syslog only [11:06] but then again, I suppose there are still tons of things that log to /var/log/upstart/ anyway? [11:07] pitti, oh, i didnt mean to drop logging for /var/log/upstart ... we only want all the system related logs from /var/log in a single file [11:07] ogra_: ah, ok [11:07] making them log as less as possible would be a goal for the upstart logs though [11:08] and we'll definitely not keep old logs around ... i'll mangle logrotate to only keep the current one === chihchun is now known as chihchun_afk === _salem is now known as salem_ [11:34] ev: seems we could upload that then, unless you or bdmurray want to investigate the daemonizing code? [11:41] pitti: happy to do that in parallel. Sorting an upload now [11:42] ev: oh, I can do that, just want to coordinate [11:42] oh cool [11:42] thanks [11:42] ev: the systemd unit does the same, btw [11:42] so logging/daemonizing/restarting can be handled properly by init [11:42] please do cite this conversation in the changelog, just so we have something to trace back to [11:43] yep (after lunch) [11:43] yeah [11:43] much appreciated [12:13] ev: pitti: so on the current error tracker i couldnt find a good retrace. is that because of the lack of dbgsym of universe? === alan_g is now known as alan_g|lunch [12:13] e.g. once we rebuild its all good? [12:14] asac: for what bucket identifier? [12:15] ev: armhf [12:16] ok unity-system-compositor is good'ish it seeems [12:16] but shows an error on top even though i see something that looks reasonable [12:17] guess we didnt have all, but enough to get some data [12:17] pitti: do we have a list of what needs rebuild somewhere? [12:17] * asac thinks would be great if that could be done before the next promotion [12:18] without deferring the promotion of course [12:18] Saviq: does that crash trace look useful for you? https://errors.ubuntu.com/problem/4516e6922810983409f4f3aa7df79aa7b97f87b3 [12:23] asac: I put a good errors.u.c. retrace in my summary mail from yesterday === salem_ is now known as _salem === MacSlow is now known as MacSlow|lunch [12:33] jgdx, morning, has your branch gotten approval or are we waiting for ken [12:37] my transfer indicator going a bit crazy === MacSlow|lunch is now known as MacSlow [12:48] asac, looks like bug #1347053 [12:48] bug 1347053 in mir (Ubuntu) "Clients are crashing with a fatal exception in MirSocketRpcChannel::send_message()" [High,Triaged] https://launchpad.net/bugs/1347053 [12:49] Saviq: ok good. so i guess thi crash would have been helpful? [12:59] asac, to the mir folk, probably [13:01] charles, just filed several transfer indicator bugs for you ;) [13:04] MacSlow: hey, you should have the archive grep results in your inbox [13:06] jdstrand, thanks! [13:07] asac: we don't have a list, no [13:08] MacSlow: you're welcome === alan_g|lunch is now known as alan_g === _salem is now known as salem_ === pete-woods is now known as pete-woods|lunch [14:01] jgdx, testing your branch on my desktop with phonesim [14:01] cellular data starts out as off, which i doubt it was off before i ran it [14:02] and changing cellular only works after i select a sim [14:02] which makes sense [14:02] i guess it starts out as off because it hasn't chosen a sim yet? [14:02] also, once setting that it doesn't always let me switch tech preference [14:03] 2014-07-24 10:00:31,262 - WARNING - file:///usr/share/ubuntu/settings/system/qml-plugins/cellular/Components/CellularDualSim.qml:116: TypeError: Cannot read property 'radioSettings' of null [14:03] jgdx, and i keep seeing that, maybe it's related [14:03] i need to step out for a few, bbs [14:07] jgdx, oh... and closing system-settings and starting it again, cellular data is off again [14:08] so you must not be getting that value from ofono at start? [14:08] or is that because we aren't storing which sim to use for cellular data? [14:12] kenvandine, phonesim cant do radiosettings [14:12] kenvandine, does not support that interface at all [14:13] * jgdx will be back later as well. === pete-woods|lunch is now known as pete-woods [14:14] jgdx, ah... ok, that makes this much harder to really test :) [14:14] * kenvandine really leaves now :) [14:14] al life === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g === dandrader is now known as dandrader|afk [14:52] hello. I'm search for a tablet with 8 inches, sim slot under 200 Euros where I can install ubuntu touch... any idea? thanks [14:55] pmcgowan, do you have a dual sim phone to test jgdx's branch? [14:55] faLUCE: the latest nexus 7 [14:56] cwayne: it is 7 inches, not 8 inches === gnu is now known as Guest13970 [15:02] kenvandine, I dont, rsalveti and tiago do [15:02] kenvandine, should be one in the mail to jgdx [15:04] pmcgowan, can you get me on the list to get one? [15:05] kenvandine, you are on the list for next batch, may be in the mail as well [15:06] cool [15:10] I really don't understand why nobody answers to a so simple question... is this channel dead? [15:11] faLUCE, i guess nobody has an answer [15:11] i know i don't know of one [15:12] kenvandine: the problem is that I don't know where to ask [15:23] reut === salem_ is now known as _salem === dandrader|afk is now known as dandrader [15:42] kenvandine: meanwhile ping tiago, he got the phone basically for dual sim work as well [15:43] rsalveti, i did === gatox is now known as gatox_lunch [15:50] does anyone know how to actually uninstall a click app? pkcon remove ... doesn't seem to work for me === boiko_ is now known as boiko [16:04] achiang, i have the runes somewhere gimme a bit [16:26] achiang, http://paste.ubuntu.com/7848420/ [16:28] ogra_: wow. so 'pkcon remove' doesn't do it but click unregister does... [16:28] very sneaky/strange [16:28] ogra_: danke [16:28] and you need the right name [16:28] (from click list) [16:29] ogra_: seems that should go into askubuntu [16:29] feel free :) [16:30] ha [16:30] who needs karma? ;) === _salem is now known as salem_ === jfelchne_ is now known as jfelchner === gatox_lunch is now known as gatox [16:50] cwayne: is there a nice simple way of converting a REST/JSON feed into a scope? [16:51] mhall119: not trivially, although depending on the api it could be pretty easy [16:52] cwayne: I'm thinking something like JsonListModel I have in QML [16:52] but I guess I can make do with something like simplejson in python === alan_g is now known as alan_g|EOD === kyrios is now known as Guest69589 [17:20] jgdx, ok, i just commented on your MP again, found a problem on my single sim device, easy fix [17:21] jgdx, otherwise it seems to work well for single sim [17:21] dobey: ping [17:22] bzoltan: hi [17:23] dobey: Hello. I have run into this https://askubuntu.com/questions/500601/how-to-create-an-ubuntu-touch-app-with-a-c-backend-and-a-qml-interface [17:23] dobey: you suggested the dude to file a bug :) [17:23] yes, well [17:23] dobey: well... he did [17:24] not being able to build a click package of a C++ app for ubuntu very clearly seems like a bug to me :) [17:25] dobey: creating click package for Desktop target is not supported yet by the SDK. The developer should select either an emulator or a real device as a target. All they need is to pay a little attention when the project is opened. It offers all the existing Kits to be linked to the porject. Or it can be later added to the project on the Project page. [17:26] dobey: The Kits are automatically created when a device is plugged in or an emulator is started. [17:27] bzoltan: if i open the sdk, and choose anything under the "Ubuntu" set of targets, should those not be Ubuntu SDK targets, as they are meant to be projects using the Ubuntu SDK? [17:27] dobey: I would suggest the developers who do not find their way with the SDK Tools to join here an ask [17:27] bzoltan: the bug seems to me that that item is a "desktop" target instead of an "ubuntusdk" target [17:28] dobey: I am not sure that I understand what you mean [17:29] dobey: when you create a template app the SDK offers you all the available Kits ... or you can make one later or you get one for free when an Ubuntu device is available. [17:30] dobey: A 14.04 desktop sadly is not a valid target. Trusty does not support apps packaged in click [17:30] bzoltan: if i open the sdk right now, create a new project and choose "App with QML extension library" it's only offering the Desktop kit [17:31] bzoltan: if i choose "App with Simple UI" it doesn't offer any kits at all during the creation wizard [17:31] bzoltan: if i choose "App with Simple UI" it doesn't offer any kits at all during the creation wizard [17:34] hmm === jfelchne_ is now known as jfelchner === dandrader_ is now known as dandrader === dandrader is now known as dandrader|afk [17:55] bzoltan1: anyway, i can reproduce the problem here. choosing "App with QML Extension Library" only has the "Desktop" kit available. that seems to be the issue that results in not being able to build a click package. [17:57] dobey: try to plug in a device or create/start en emulator. You will see new Kits. The SDK can not know what devices you want to target without seeing at least one [17:58] bzoltan1: I've managed to build an i386 scope binary and click package, how do I run it on the emulator? [17:58] bzoltan1: my phone has been plugged in for days. it does not show me the kit when creating the package. and i shouldn't need the device plugged in or an emulator set up, to be able to have a project that can build a click package, really [17:59] with my phone plugged in it still only shows "Desktop" [18:20] dobey: on the Devices tab you have your device with a large button what say Autocreate [18:21] dobey: the Kits are offered once when you open the projet. If you miss that than it is two click on the Project page [18:25] bzoltan: i am failing to understand why as a developer i have to go through all that to be able to build a package of my app. why can't i just create a project and have making a click just work? === dandrader|afk is now known as dandrader [18:28] dobey: you need to know what arch and release you click package targets [18:28] if it's pure QML, arch isn't a concern, but you mentioned using the template with a C++ extension [18:29] the issue then is being able to find enough information to properly build for that target, and that information isn't in the Host OS if you're running something other than the target arch and release [18:29] mhall119: so the bug is "click packages targetting multilpe archs don't exist yet" ? [18:30] that's part of it, the other part is knowing which "multiple archs" to target [18:31] well, we only really support armhf and i386 at the moment [18:31] so surely that's not a terribly hard problem to solve :) [18:31] we support amd64 too [18:32] there's an amd64 emulator? [18:32]