=== ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/13/%23ubuntu-uds-core-1.html === stgraber_ is now known as stgraber === kitterma is now known as ScottK === _salem is now known as salem_ === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Click Framework handling | Url: http://summit.ubuntu.com/uds-1403/meeting/22221/core-1403-click-framework-handling/ [13:58] https://plus.google.com/hangouts/_/hoaevent/AP36tYe9ZYPzrxTId__au2dBIegrg3YnxJSGY5SSyBDCBvU9H6prWw?authuser=0&hl=en [13:58] lool: ^^ [13:59] morning folks [13:59] * ogasawara waves [14:00] I'm not really sure who owns this click framework handling session [14:00] lool, I believe [14:01] yes, he seemed to create it... yesterday? [14:01] maybe tuesday [14:02] just waiting a few mins folks [14:07] you are live [14:08] https://wiki.ubuntu.com/Click/Frameworks [14:12] will any of the base frameworks be backported to 14.04? say, 14.10 base frameworks? or is the train only going one way? [14:14] /all _3_ of them/ =))) [14:16] Do you know already when the new framework will be available in click chroots? [14:16] Do we plan on provide an SDL framework tag? [14:16] zyga-uds, almost sure it's a runaway train never coming back [14:16] Guessing games don't want to depend on html or qml. [14:17] so you cannot release stuff that gives new features on LTS releases, that's not good IMHO [14:17] zyga-uds, should of attended yesterday's session about stable core ;-) [14:19] zbenjamin: once this is all definitely agreed for real, and Qt 5.2 is landed - so I guess next week [14:19] lool: jdstrand: i guess "framework-qtwebkit" "framework-oxiede" [14:19] cjwatson: awesome! thx :) [14:20] xnox: noooo!!!!! :) [14:21] jdstrand: OKKKKKKKK!!!! :) [14:21] Can we just remove the symbols from the library? [14:21] it just should be on the deprecated/not supported list, just like any number of other apis [14:21] I mean, if we don't think app developers should use it, really no one should. [14:21] jdstrand: are we shipping qtwebkit on the phone image? just purge it from the ubuntu-touch images and be done with it. [14:21] tedg: we could probably do that now. I doubt we could when kde starts using qt5 [14:22] tedg: universe can use anything they want ;-) [14:22] yeah, we just don't want it to be used on touch [14:22] jdstrand: well, if upstream is abandoning qtwebkit too, by the time kde switches, it might be gone anyway? [14:22] We could split into a libqt and libqt-deprecated and just have the dpkg tools figure out which ones are needed. Touch could just not install the deperecated one. [14:23] the reviews tools warn on it. once oxide is in the archive, we can error on it if we want [14:23] but qtwebkit is also a separate binary package no? can't we just not put it on the phone image? [14:23] and the review tools are part of the sdk now, so, that is pretty strong prevention [14:23] but upstream is deprecating it but proposing a replacement as well [14:23] yep [14:23] rsalveti: upstream replacement is their own engine? [14:24] xnox: yes, kind of similar to oxide [14:24] they are developing a chromium content api based engine too [14:24] * jdstrand feels a question coming on [14:24] lool: cjwatson: well sdk-libs-dev is for the click chroot =) sdk-libs is runtimes only installed on the phone [14:24] here is why we are doing oxide: http://www.chriscoulson.me.uk/blog/?p=196 [14:25] we want oxide :-) [14:25] yes :) [14:25] I'd love to land it today if I could :-) [14:25] it is getting really close [14:25] jdstrand: and qt upstream doesn't want oxide? can't we submit oxide upstream ? =) [14:26] rsalveti: I don't think it ever hit the list, but we did benchmarks against qtwebkit-- oxide has very better support (like, everything works whereas on qtwebkit, it couldn't run all the tests), it pretty much blew away qtwebkit on performance on everything [14:26] rsalveti, just land it ! we can blame Qt5.2 for any breakage :) [14:26] haha :-) [14:27] jdstrand: awesome, good to know [14:27] I don't always have libraries pull in daemons, but when I do, it's mostly to harass xnox. [14:27] xnox: "Q: Isn’t Qt already switching to Blink?" "A: [14:27] I’m aware of Qt WebEngine, although this was announced after I’d already started work on this. However, whilst it’s great that somebody else is doing something similar, this would not solve our original problem – which is that we want something we can properly support for 5 years. [14:28] Also, Oxide isn’t particularly tied to Qt. It’s been designed to support new ports fairly easily (eg, I might add a Gtk port in the future) [14:28] " [14:28] xnox: we plan to share code, patches, expertise, etc where we can [14:28] xnox: sure - have you checked lately whether it's multiarch-coinstallable? [14:28] xnox: we'll probably need to make it sdk-libs-papi-dev etc. or something [14:29] cjwatson: i believe there are still unresolved pieces that cropped up. I'll double check. [14:29] rsalveti: the hardware acceleration is really pretty exciting. it was cool watching a HD Rush concert video on youtube on my phone :) [14:29] cjwatson: "papi" ?! (as in papi don't preach?!) [14:29] platform API [14:29] jdstrand: but is it using hardware acceleration for video decode? [14:29] cjwatson: oh, ok. [14:30] xnox: see https://wiki.ubuntu.com/Click/Frameworks [14:30] jdstrand:glad you liked our video [14:31] geddy: :) [14:31] lool, you shouldn't need to provision anything [14:31] rsalveti: ask chrisccoulson for details, but yeah, that is my understanding [14:33] cjwatson: right so -qml will install runtime libs without any "-dev" packages (headers), whereas -pappi will pull in "-dev" packages. [14:33] something like that ... we'll need to thrash out the package-level details [14:33] jdstrand: interesting, it'd need to use gstreamer to be accelerated, I believe you just used ffmpeg internally (and was fast enough to render a HD video) [14:33] -qml would need to install the qml bindings, -papi couldn't [14:33] *wouldn't [14:34] rsalveti: ffmpeg is purged from touch images, is oxide shipping it's own ffmpeg? [14:34] looking at questions [14:34] xnox: need to check [14:34] are there questions that we should cover now in the HO? [14:34] rsalveti: I recommend you talk to chris :) [14:34] * jdstrand hasn't been in deep on that [14:35] jdstrand: yeah :-) [14:35] geddy: so, I don't know if you are the actual Geddy Lee, but I am going to believe you are and say, you made my day :) [14:36] jdstrand:we are the priests! [14:38] can we have a meta 'dev' framework which is marked unstable and then tag/define at the end of the cycle? [14:39] I don't understand what value that would have [14:39] geddy: :) [14:40] we should just be able to update qtcreator to default to the newest available for 14.10 (say) when building an app against 14.10 [14:40] (which you'll only need to do if you're using facilities only available there, anyway) [14:40] jdstrand:now i just have to convince alex that suse is a dead end. and we won't even talk about neil's love for that redmond OS. [14:41] cjwatson, the sdk has removed components during development; so if I publish my app early in the cycle and care not to update it when things are removed, at the time of upload it would be compatible but not in the future [14:42] jdstrand, are there going to be more policy versions per framework? if not, can't it be implicit? [14:42] are there any questions around frameworks [14:43] sergiusens: I get that; but part of the point of declaring frameworks is that we can scan the store for stuff that's broken and rev it [14:43] sergiusens: a single dev framework would actually make that harder [14:44] we would have no idea what it actually referred to; and it would require pointlessly revving things for the tail-end of a cycle, since the last -devN framework would imply the same ABI as the final release [14:45] cjwatson, that last sentence convinced me fully [14:46] ok, good :) [14:47] ogasawara: THanks [14:47] And sorry for the late start [14:47] np [14:47] convinced was a stong word; but yeah [14:47] will this be summarized somewhere [14:47] router reconnected a couple of minutes before the hour [14:47] lool: ^^ [14:48] zyga-uds: wiki page + this hangout [14:54] How are we detecting whether the framework ABI changed? [14:54] Seems like per-image we could do some sort of automated capture? [14:55] https://plus.google.com/hangouts/_/hoaevent/AP36tYfjer1QM4nh5HLO8m_Vzu08XaxQsS7wGC7DeOyhqNHgyo-tQw?authuser=0&hl=en === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Carrier/OEM Customizations | Url: http://summit.ubuntu.com/uds-1403/meeting/22218/carrieroem-customizations/ [14:55] Carrier/OEM Customizations ^^ [14:58] https://plus.google.com/hangouts/_/hoaevent/AP36tYfjer1QM4nh5HLO8m_Vzu08XaxQsS7wGC7DeOyhqNHgyo-tQw?authuser=0&hl=en [14:58] did someone post the hangout link for this? I likely won't have a ton to add, but do have a question or two for the end [14:58] achiang: ^^ [14:58] ah [14:58] :) [15:02] live :-) [15:04] * zyga-uds worked on carrier image customization for a few years and will listen carefully looking for issues [15:04] bzr branch lp:savilerow [15:08] what i was always wondering was: what happens if we update the system underneath the customization, how to we make sure we dont trash the OEMs stuff ? [15:08] cwayne: we need to add the custom.prop feature at http://people.canonical.com/~achiang/ubuntu_savvy/ as well [15:09] is that already used ? [15:09] (i know we can process it already) [15:09] it can be used, yes [15:09] and it was for mwc [15:09] ogra_, you are on a channel that include the customizations [15:09] have we done some research on what carriers want to customize? [15:09] * zyga-uds has some ideas but that's just one drop of experience [15:10] sergiusens, so that channel is owned by the OEM ... which means that it will oonly get updated once the OEM also updates the tarball ? [15:10] achiang: I love demos [15:10] ogra_, that's political and I guess depends on achiang [15:10] sergiusens, which in the end means the OEM decides if security updtaes are even getting to users ? [15:10] not sure if the trbal is to be sent here or they get their own channel/server [15:11] well, it sounds like it would be somewhat pointless if we couldnt bypass the OEM for security fixes in the rootfs [15:12] ogra_, well the custom tarball could be a one time thing and it extends the ubuntu_commands [15:12] so I see no problem in it being a central thing [15:12] achiang: cwayne can you talk about how this approach preserves the update process and avoids conflicts in the archive [15:12] but that decision is political [15:12] right, i just try to understand how it works ... i would expekct us to be able to still independently provide a new rootfs [15:14] ogra_, well if you look at https://system-image.ubuntu.com/trusty-customized-demo/manta/index.json you'll see it's the same ubuntu rootfs [15:14] and the custom stuff is basically a drop on a specific location of the filesystem [15:14] sergiusens, right, my question is can we provide a new rootfs and the tarball will still cope [15:15] it should [15:15] sinnce i dont expect the OEM to update the tarball at the same frequency as we upgrade the rootfs [15:15] ogra_, look at one of the delta updates; it's only rootfs [15:15] ogra_, type: delta in the json [15:16] right .. [15:16] achiang, thanks ! [15:16] ogra_: the oem carrier might end up having a specific system-server, that would then use the same rootfs [15:16] but they might want to decide when to push updates to the user [15:16] ogra_, this only depends on that API that achiang is just talking about [15:16] so that can be better tested and so on [15:16] if it doesn't change; it will keep working [15:17] rsalveti, right, i dont really like that since they can hold back security fixes etc [15:17] rsalveti, yeah, but that's more politics than anything else [15:17] achiang: customizing the launcher is common on android [15:17] ogra_: sure, but I'd guess they need to test and validate before pushing updates [15:17] achiang, One thing that I think we don't have support for is custom APs. So as an AT&T customer I autologin to their Wifi network. [15:17] achiang: and we might want to allow for different launcher designs in this or that form factor [15:18] tedg: interesting point on custom APs [15:19] tedg, easy to fix by shipping the right NM config files [15:19] karni, It's a custom AP, but also protocol to login. If I'm not an AT&T customer I have to agree to T&C to get access. [15:19] * karni nod [15:19] indeed [15:21] I know we want to push down the rootfs for our users, but I'm just concerned how we'll validate that [15:22] we believe an update will not break anything, but we'd need to test for real to make sure we're good [15:23] cwayne: no worries :) [15:23] achiang: cwayne is the idea that the OEM would run this tool themselves? Or do we run it for them? [15:23] All, this is just a prototype, not a working solution yet. [15:23] ChickenCutlass: they run it [15:24] right [15:24] lool: tedg: thanks for the ideas, i've added them to the pad [15:24] ogra_: did we answer your question re: security? [15:25] achiang, half way, yes ... the OEM still runs an s-i server and needs to pick up the rootfs from us, or not ? [15:25] i.e. they can hold back security fixes [15:25] will we support users uninstalling/disabling some/all of the OEM content? [15:25] rsalveti: same image tests have to rerun on top of the custom image, with additional tests for the customized bits? [15:25] e.g. check that the custom bookmarks are indeed the expected ones [15:25] lool, yes [15:26] lool: yes [15:26] ogra_: I believe we release rootfs updates, not OEMs [15:26] lool: it's fine if we have a few devices, but once we increase that number, it'll be harder [15:27] karni, so we need to run the s-i server for them [15:27] karni, if the server is in their hands it will want to ship all pieces together (device, rootfs and customization tarballs) [15:27] is alex on irc here? what's his irc nick?! =) [15:27] will this be applicable for PC OEMs too? [15:27] xnox: achiang [15:27] which means they meed to import the rootfs [15:28] xnox: achiang [15:28] gQuigs, once desktop is converged enough to also use image based updates :) [15:28] ogra_: right [15:28] achiang: "oem-customize" ~= "cloud-init-style" =) [15:30] ogra_: it is not clear that the OEMs will host the s-i servers [15:30] k [15:30] ogra_: so i would say that question is still open [15:31] well, if we want to offer that feature, we should probably reconsider the s-i design [15:31] so that they only provide a customization server .... [15:31] rsalveti: I'm not sure why it gets harder; I mean, these devices have to be supported anyway, so it's about keeping the tests working; if you mean OEMs might stop caring, it's kind of the same problem no matter what (just like drivers support) [15:31] (for hardware and custom tarball ... but the rootfs comes from us) [15:32] achiang: "go!" [15:32] go ! [15:32] *snap* [15:32] cwayne: hold on with demoing while achiang is talking [15:32] achiang, Are you saying some OEMs run RHEL? [15:33] running click install on other systems may be interesting [15:33] ;-) [15:33] cwayne: whatever you're doing is all in a small thumbnail (unless you speak up) [15:33] I think it might actually be easier to just freeze the interfaces we care about and let Ubuntu Savvy reimplement them portably; not sure [15:33] lool: harder as we need to coordinate more stuff :-) and make sure we're not the ones entirely responsible for the testing side of it [15:33] rather than trying to port gobject-introspection to OS X ;-) [15:33] achiang, it's fast to write go [15:33] achiang: do you support QNX [15:34] lol [15:34] ChickenCutlass, only the unity8 version of QNX [15:35] fair enough :) [15:35] the other one got answered [15:37] that makes sense to me, thanks! [15:37] jdstrand: did you ahve a quesiont for us? [15:38] achiang: system update settings might be worth overriding too [15:39] achiang: well, I did, but it didn't seem to fit. it was bringing up the old mailing list discussion wrt to apparmor policy, udev, rules, etc [15:39] update frequency, automatic updates, update server etc. [15:39] achiang: click build is intended to work on any system that has python [15:39] which are customizable in the conf file [15:39] achiang: I intend to keep it that way [15:39] jdstrand, there's anothe session for that [15:39] achiang: but the rest of click has no such guarantees [15:39] jdstrand, later today [15:39] ah, ok, good [15:39] cjwatson: ack [15:39] achiang: (also this is theoretical rather than tried, but it shouldn't be hard to fix) [15:39] sergiusens: thanks [15:39] achiang, it's not a full full port ;-) [15:40] I'm not interested in click/go because I need to be able to provide a C API [15:40] achiang: nm, sergiusens told me there is another session on that [15:40] jdstrand, http://summit.ubuntu.com/uds-1403/meeting/22219/core-1403-hardware-handling-touch/ [15:40] achiang, Do we expect OEMs to significantly alter the base package set in any cases? i.e. a tablet manufacturer that wants to ship X11 support on their tablet. [15:40] jdstrand, next session covers HW decoupling [15:40] I'd caution anyone who's reimplementing it to be very very careful :) [15:41] tedg: what's X11 [15:41] yikes, please let's not reimplement click [15:41] x11 is not touch :P [15:41] you can then ship ubuntu desktop [15:42] ChickenCutlass, Enterprise features :-) [15:42] I guess I was more worried about supporting connecting to your network servers or some such. [15:42] Like I could see an IT focused device or something. [15:43] the terminal app is a special case; if it's to prevent them from using it; it's not going to work as they can still install it [15:43] if it's just considered _cruft_ in the image; it's fine either with the unregister or just not adding it [15:43] i'd say its not preventing use so much as not preinstalling [15:43] .... terminal-app by default was a silly idea [15:43] nah [15:44] terminal app is great [15:44] we should just give OEMs a discount to not remove it ;) [15:44] I don't think it's a silly idea [15:45] xnox, talk to the elders of the internet; they convinced the product owners to add it :-P [15:45] sergiusens: oh, i'm in big dept to the elders of the internet. I should shut up about this =) [15:45] * xnox quickly purges logs [15:46] we won't have X11 compatibility? so only QML apps will work? [15:46] gQuigs: on touch [15:46] gQuigs, Only things that support Mir. [15:46] gQuigs: but on desktop we will support X apps on top of Mir [15:46] exactly, failure would be to rebuild the rootfs [15:47] how would we do convergence then? [15:47] right, Xmir support is in, right? [15:47] gQuigs: probably not on mobile devices [15:47] it's not a technical limitations [15:48] on tablets it makes more sense... [15:48] it's more that you want mobile apps to be designed for touch, so you're looking at QML apps designed for this [15:48] or custom apps [15:48] gQuigs, it will be in for the phones that can become desktops [15:48] lool, The question is more about running your phone with a keyboard and monitor case. [15:48] but generally we wont ship XMir for "normal" phones [15:48] right, in which case you get the desktop experience [15:48] which might involve X [15:48] but there are many cases of convergens [15:48] So you'd need xmir, at least for a while. [15:48] *convergence [15:49] Not sure if we shouldn't define a framework for that. [15:49] thanks! [15:49] So apps that need it, could specify that they need it. [15:49] sounds good [15:49] achiang, Sounds good, thanks! [15:50] zyga-uds, do you have any particular areas of customization that we're missing? [15:55] https://plus.google.com/hangouts/_/hoaevent/AP36tYd8oAPzkFdRqF_9QBHXxAJwSNQkkUCZfWIyp2dGLwfuzYqoYQ?authuser=0&hl=en [15:55] ogra_, ChickenCutlass ^^ [15:55] for your next session === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Handling hardware solely from the android img files | Url: http://summit.ubuntu.com/uds-1403/meeting/22219/core-1403-hardware-handling-touch/ [16:01] https://plus.google.com/hangouts/_/hoaevent/AP36tYd8oAPzkFdRqF_9QBHXxAJwSNQkkUCZfWIyp2dGLwfuzYqoYQ?authuser=0&hl=en [16:01] argh [16:01] http://pad.ubuntu.com/uds-1403-core-1403-hardware-handling-touch [16:04] ogra_: sergiusens: keying onto android-system.img is a bad idea. In system-image update mode, custom-per-device things are shipped inside a device tarball. Adding !android things inside android-system.img sounds like a recipe for disaster =) [16:04] ogasawara, are you proposing bind mounting each and every file in the overlay ? do we ahve a view to how many that is, and the scalability of that [16:04] ogasawara, [16:04] argle [16:04] ogra_, [16:04] :) [16:04] ogra_: sergiusens: why not ship extra things in the device tarball? [16:04] xnox, that's the idea [16:05] xnox, what we discuss is how to make it available to the components tat need them [16:05] xnox, thats what we are discussion [16:05] xnox, oh, so device != android device (system.img) [16:05] xnox, the device tarball *is* system.img from android [16:05] whomever is typing, *please* mute yourself [16:05] ogra_, were overlay filesystems considered? [16:06] janimo`, those do not necessarily exist in the older kernels these devices have [16:07] apw, situation is improving though, as OEMs move to newer kernels. But good to know that is the main blocker and not some technical detail [16:07] since then we could have a single overlay not several bind mounts [16:07] several thousand potentially [16:07] apw, and we touch the kernels anyway [16:07] janimo`, i think stgraber tested with overlay stuff before designing the current solution [16:08] and we dont want to put such a penalty to porters [16:08] ogra_, would be good to have an analysis of that. We have too many bits of knowledge in people's heads only [16:08] ask stgraber he analyzed it [16:08] ogra_, could we consider inverting, ie make the root the writable bits, and symlink the non-modified bits into it [16:08] apw, from the initrd, yep [16:09] ogra_, i mention this cause we have had trouble with large numbers of mounts cause severe performance issues [16:09] ogra_: device tarball is _system.img from android, see for example are http://system-image.ubuntu.com/pool/device-456bc5a53bcbb0481be13acacc4de673433c4ea0255ffabe0cbc35925481715d.tar.xz [16:09] ogra_: that has boot.img, recovery.img and system image as a folder unpacked. [16:10] xnox, yeah, but I was slapped for not making the specific distinction :-) [16:11] xnox, thats what i said [16:11] xnox, boot.img isnt touchable for us ... (kernel and initrd) recovery isnt intresting ... so stuff needs to live in system.img [16:21] ChickenCutlass: we need a single process that works for both reference devices and products that go to shops [16:22] victorp_uds: totally agree. [16:23] ogra_: what you mean a true x86 device? [16:23] we have android running on a true x86 device :P [16:23] rsalveti, a desktop [16:24] ogra_, most of your examples are conf files, would your proposal work for binary files ( ie. libraries/plugins )? [16:24] awe, sure [16:24] bind mounts are bind mounts :) [16:24] they dont care which files you bind mount [16:24] sure... [16:24] for libs you would need an ldconfig run though [16:24] which makes it pretty complicated [16:25] but not necessarily for plugins [16:25] right [16:25] ( which is what I'm thinking of. eg. ofono dynamic plugins ) [16:25] yeah that should work just fine [16:26] root@ubuntu-phablet:/# ls /var/lib/lxc/android/pre-start.d/ [16:26] 10-no-adbd 25-process-overrides 40-brcm_patchram_plus-disable [16:26] 15-no-uchroot 30-no-surface-flinger [16:27] 10-no-adb is the generic script to always disable adb inside the container [16:27] 25-* is for developer use only to replace files inside the system.img [16:27] ogra_, to be honest we need to move that to android [16:27] 15-* is legacy [16:28] sergiusens, did ondra bribe you now ? [16:28] :) [16:28] ogra_, nope [16:28] ogra_, but the adb one is just dirty :-) [16:28] most can be just removed [16:28] 40-brcm_patchram_plus-disable is actually something i was hoping to get input from cyphermox [16:28] ogra_, surfaceflinger one is just a temporary thing [16:28] ogra_: :) [16:29] sergiusens, yeah. most can go [16:29] tarball again [16:29] and next thing is overlay [16:29] heh [16:30] ondra is this a drinking game? [16:30] tarball --> shot [16:30] victorp_uds we should :D [16:30] * victorp_uds drinks [16:33] ogra_: your hangout is fine considering your line speed :) [16:33] ogra you need to move [16:33] haha [16:33] ogra_, just build shit on chinstrap :P [16:33] xnox, OEMs would not want to build debs, but stick to the tools and processes they are familiar with [16:33] \o/ [16:33] ChickenCutlass:I want a faster internet too [16:33] ill take one while youre up [16:33] shot time [16:33] victorp_uds: no problem. [16:34] fast internet for everyone [16:34] janimo`: right, at the moment we expand everything to a flat tree. and compile the image. [16:34] xnox, the ansroid tree also has ubuntu hooks already, like hybris and platform-api [16:34] janimo`: we don't depend on /debs/ at all. [16:34] xnox, ok I misunderstood what you were avocating then [16:34] xnox, I thought we now have various udev rules and such in dev specific packages [16:34] like lxc-android-config [16:35] root@ubuntu-phablet:/# mount|grep system [16:35] /dev/loop1 on /android/system type ext4 (ro,relatime,data=ordered) [16:35] ondra, is that decided? Is the loop mounting only on nexus devices? [16:36] ogra_: 40-brcm_patchram_plus-disable we need to get rid of [16:36] cyphermox, yeah [16:36] ondra, why? The android build will be a different rebuild of the same tree [16:36] cyphermox, but i think your bluettoth reworking covers it., right ? [16:37] yes [16:37] great [16:37] it would, haven't started yet [16:37] next week [16:37] xnox: I think ondra is right that an update of android.img will cause hte whole file to be included [16:37] i'll add that info to the etherpade [16:37] ogra_: and just bringup bluetooth and wifi from the init.whatever, and have on the ubuntu root have just one single, extremely simple upstart job that pokes the standardly named android init job to start bluetooth [16:38] yeah [16:42] janimo`: no loop mounting on product [16:43] ogra_, how do these files get into the android.img? Are you proposing they go into a standard place, and where is that? [16:44] I dont quite get the big deal, I dont think we like loop mounting, we want to avoid it; it's either by technical constraint on existing device (nexus 7) or by lack of time that we havent moved to partitions [16:44] loop mounting is just a fallback feature [16:44] awe: we'd need to modify the upgrader script, inside the upgrade tarball, to look at those files and slap them on top of the read-only image. [16:44] * victorp_uds finished the bottle [16:44] cheers [16:45] ondra: but what about tarballs and overlays? [16:45] j/k [16:45] * ondra drinking :) [16:45] no mention of union filesystems so far! [16:45] lool: :) [16:46] ogra_: android system.img in the rootfs, imagine you get to repair shop which will try to fix your phone with flashing new Ubuntu version (mean formating rootf), bang you just bricked the phone :) [16:47] ondra, well, screw that shop if it doesnt use ubuntu-device-flash [16:47] :P [16:48] achiang, do a shot [16:48] cheers [16:51] ogra_: it's product for consumers and we need to think about entire life cycle of device [16:51] * ondra is getting drunk === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1403/core-1/ - http://irclogs.ubuntu.com/2014/03/13/%23ubuntu-uds-core-1.html [16:56] ogra_: copying files around? :) [16:57]