[00:04] sergiusens: elopio: failed to me even when not empty, this bug sucks [00:04] we need a smarter workaround [00:09] rsalveti: what failed? snappy-stamp? [00:10] sergiusens: the fat partition got corrupted even when the stamp is not 0 [00:10] so we need to go with ogra_'s solution [00:10] to use env + kernel cmdline [00:11] and do that under the initrd [00:11] rsalveti: I guess we can have some logic in lp:snappy to carry this change [00:11] right [00:12] rsalveti: I was just coming in to propose and do something like that for the fatwrite thing [00:12] rsalveti: I don't understand ogra's solution though; instead of a stamp file the env would be stored on disk? is that it? [00:13] rsalveti: env being snappy_ab, snappy_mode and snappy-stamp's replacement ? [00:13] trying to remember the details [00:14] but we can try something different as long we're not writing from the bootloader [00:14] we can read from the bootloader [00:14] and pass over arguments via kernel cmdline, for example [00:15] need to get off for dinner, try to propose something, otherwise we can talk tomorrow [00:15] rsalveti: well we need to write from the bootloader when something fails at that level [00:15] can't you just invert the logic? [00:16] if the file is not there, it means the previous boot didn't work [00:17] bbl [00:17] rsalveti: I guess, and that is a much simpler fix [00:17] rsalveti: but we can't reverse the logic at this stage === rcj` is now known as rcj [07:09] good morning [07:13] good morning === erkules_ is now known as erkules [08:33] Good morning all; happy Gummi Worm Day! 😃 === greyback__ is now known as greyback [09:53] JamesTait: i'm starting to suspect your days calendar is subsidised in part by haribo [10:18] Chipaca, now there's an idea! [10:19] JamesTait: you could save *dozens* on your kids' uni tuition! [10:19] lool, *tickle* [10:20] Chipaca, who said anything about the kids? [10:27] JamesTait: I did. Just now. Pay attention! [10:27] Yes, sire. Sorry, sir. [10:38] ogra_: hey [10:38] lool, did your patches for uboot ever make it upstream ? [10:38] ogra_: sorry was away yesterday, I see you were discussing some u-boot stuff with ricardo s [10:38] yeah [10:38] no idea, checking [10:38] it was a one line patch to the config [10:39] seems fatwrite is constantly corrupting the vfat ... we are looking of the newer uboot from the wily archive could perhaps help [10:39] *if the [10:39] ogra_: oh wow, that sucks [10:39] (and in general we'd like to base off an archive package) [10:40] I dont care about basing on archive TBH [10:40] well, you got everything in one central place there [10:41] ogra_: I dont see my patch merged upstream, but it seems to me the config includes were reworked in a way that enables this particular config [10:42] ogra_: we dont want to be the central place for firmware IMO [10:42] was it really just config ? i thought you needed some extra stuff for raw initrd [10:42] ogra_: no, just a config [10:42] ogra_: http://people.canonical.com/~lool/snappy-bbb/0001-Enable-SUPPORT_RAW_INITRD-to-load-initrd.img.patch [10:42] we want to be able to maintain the firmware for our supported imaes [10:42] and having that centralized makes it easier [10:43] nowadays, include/configs/am335x_evm.h includes include/configs/ti_am335x_common.h which includes include/configs/ti_armv7_common.h which defines CONFIG_SUPPORT_RAW_INITRD [10:44] ogra_: I dont think we want to maintain that firmware; also it's ok if we build it once and stop worrying about it [10:44] ah, cool. that was the thing i needed to knwo [10:44] I know this sounds extreme and contrary to our usual standards [10:44] but it's just make work where we have no value [10:44] well, we ship that firmware and we *wnat* to control it ... at least til we know it isnt bugy anymore [10:45] * ogra_ needs new kbd (or new fingers) [10:45] for now we only want fatwrite to work or find an alternative though :) [10:47] my idea was to ship a uboot.env by default that carries the values, but that needs some hackery if we want to change them from userspace after boot [10:47] ogra_: do you have a recipe to trigger the fatwrite issue? [10:48] lool, doing multiple rollback and update actions on a BBB 15.04 alpha image [10:48] the prob is also that the BBB can fall back to the internal uboot ... which has fatwrite enabled but is 8 months older than what we ship [10:49] ogra_: FYI, upstream commit we care about is: [10:49] so might even have other bugs [10:49] commit 6440b807399c81c3670f7c9805c917308cfdd5d3 [10:49] Author: Guillaume GARDET [10:49] Date: Mon Nov 3 14:26:17 2014 +0100 [10:49] ARM: TI: Enable raw initrd support [10:49] (my patch was produced later but on top of the previous u-boot release [10:49] right [10:50] ogra_: what's the symptom of the fatwrite issue? [10:51] corrupt files on the vfat ... kernel or dtb usually [10:51] morning [10:51] bug 1474126 is one of the current bugs with it [10:51] bug 1474126 in Snappy "failed to rollback from 15.04 alpha #4 to #3" [Critical,Confirmed] https://launchpad.net/bugs/1474126 [10:52] rsalveti confirmed that he never gets the issue when removing fatwrite from the process and hacking the a/b stuff manually instead [10:52] morning [10:53] ogra_: latest uboot doesn't help [10:53] ah, i feared that [10:53] i didnt see anything about it in the backlog [10:53] so we've likely found an u-boot bug, or we have a misconception [10:54] how do we deal with it? [10:54] i think fatwrite is used so rarely that it still has many bugs [10:54] lool: that is what is under discussion [10:54] dealing with it [10:54] ideally I'd like to not use fatwrite [10:54] lool, as i said, one option would be a uboot.env by default [10:54] I wonder whether it's by virtue of u-boot touching the MMC at all; that is, the abstraction of the MMC controller doing the writes might just result in corruption (dependent on the SD card brand) and then we need to go back to the drawing board [10:54] either invert the logic or get to another solution [10:54] but snappy needs to be able to disassemble and change it [10:55] last night rsalveti proposed inverting the logic (file not there for u-boot and file created by snappy) [10:55] but that isn't backwards compatible [10:55] u-boot needs to be able to write some flag [10:55] sergiusens: I don't think we can do any solution that is backwards compatible [10:55] and wont work for a/b [10:55] otherwise you have no u-boot retries [10:55] right [10:55] because we can't change the file that does the fatwrite [10:55] we can drop the u-boot retries if that's more pain than use [10:56] * ogra_ still thinks we should just use a uboot env var [10:56] what I thought was inverting the logic and giving the u-boot var via kernel cmdline [10:56] and touch the file from the initrd [10:56] fatread is fine, fatwrite is the problem [10:57] rsalveti: this is not enough [10:57] rsalveti: I mean, it's less than today [10:57] why? [10:58] we only check for the file to know if the boot succeeded or not [10:58] how do you record that you've attempted the boot? [10:58] kernel panics, board reboots, you're back to the same bootloader logic, how do you avoid the boot loop? [10:58] can't use save via env var in uboot? [10:59] there is no flash on BBB [10:59] so it's either over FAT, or we create a new u-boot environment partition on the emmc [10:59] we can even have redundant environment! :-) [10:59] but that diverges quite a lot from upstream u-boot [10:59] yeah [10:59] or we debug fatwrite / emmc issue and we find the issue [11:00] the only thing I don't like about that is that we'd be enforcing a newer u-boot (or patch) for everyone [11:01] gah, what was that [11:01] the stamp file can actually be touched from initrd, but the snappy_ab var needs to be dynamic and to be set before uboot tries to boot anything [11:01] so the kernel commandline doesnt buy you much [11:07] * ogra_ goes to find lunch [11:10] ogra_: lool rsalveti to be fair, we don't have this stamping logic for grub based systems [11:10] iirc [11:10] sergiusens: what do we do there? [11:10] sergiusens: we dont? [11:10] rsalveti: I'm not sure, wasn't involved (I think nothing), mvo do you know? [11:11] I thought we were writing to the grub environment and setting a/b from there [11:11] but never saw it [11:11] lool: yes, a/b we set, but we have nothing similar to the stamp file [11:12] we need a way to know that we should not continue trying to boot one specific kernel [11:12] lool: rsalveti ah, snappy_trial_boot [11:12] grubenv [11:12] the general problem is as follows: we want to demonstrate product-grade reliability across updates including kernel breakage, that relies on the bootloader being at least able to tell whether it's trying again or not; we're demo-ing on BBB [11:12] I see two ways out of this [11:12] path uboot [11:12] patch* [11:12] either we find another path to track the "retry"; for instance, we could use memory, but that's fragile [11:12] (e.g. trigger the reboot with some concept, much like "reboot to recovery" on android) [11:13] or we deliver a firmware which does what we want [11:13] and we drop the "upstream firmware" artificial constraint [11:13] well, we only need to move the backend off the vfat [11:13] which is just a constraint we're imposing on ourselves to be good citizens [11:13] i.e. into a uboot var [11:14] ogra_: that's fine with me, but then we need to use a patched bootloader to do this [11:14] why is that ? [11:14] sergiusens: so GRUB does implement the logic? good to know [11:14] i thought uboot can generally use env blobs [11:15] ogra_: hmm, perhaps it does support a raw environment at a fixed SD card offset, that might be a solution [11:15] another solution of this kind to consider is to ditch u-boot in favor of edk2 [11:15] lool, well, more a blob file [11:15] I think it supports that [11:15] lool, like on the rpi [11:15] ogra_: a blob file in a fs or in an offset? [11:15] ogra_: a blob file might be more reliable, but not sure [11:16] it doesnt have any requirements on the partitioning [11:16] I guess u-boot *might* be clever enough to overwrite the same blocks when updating the env file [11:16] but this might also be equally unreliable [11:16] you can use saveenv in the uboot script [11:16] it will properly update [11:16] but where would we save the blob? [11:16] ogra_: the question is whether it's any reliable [11:16] in uboot.env o the vfat [11:16] *on [11:16] if it's replacing an unreliable solution with another unreliable one, it's not a good deal IMO [11:16] right, but not sure if that is reliable [11:17] still writing in the fat partition [11:17] i thinnk it is as reliable as the uboot env is in general [11:17] as long as we can safely load that blob file we are fine [11:17] rsalveti: perhaps we can just add a sync/flush in the u-boot logic to shrink the window where the fs is getting corrupted? [11:18] I don't think it's a sync problem [11:18] but we can try [11:18] rsalveti: you sync ;-) it's an actual bug in the fat logic? [11:18] that would be worth fixing in any case [11:19] * lool notes that everyone focuses on u-boot since I agitated the edk2 broom [11:19] yeah, just that this is holding our stable release [11:19] * ogra_ already proposed to switch arm to grub yesterday [11:19] but, we're not going to be able to update the bootloader anyway [11:19] :P [11:19] so I believe we just release the stable image and try to fix the uboot issue [11:20] lool: what do you think? [11:20] * ogra_ wonders if thats not actually to serious to release with it [11:20] rsalveti: I think it's a fine way forward given the other things we need to think about [11:21] is this only hitting BBB/omap platforms? [11:21] I wonder whether it would affect the pi2 [11:21] lool, we dont support upgrades/rollbacks on any others [11:21] right [11:21] so no way to test [11:21] I personally like to think we will move to UEFI and replace this with the GRUB logic entirely [11:21] even on armhf ? [11:22] (who would be doing that grub port? ) [11:22] ogra_: lool: problem is, we can't update the bootloader [11:22] we don't have support for that [11:23] so even if we find the fix, we'd need someone to manually update it [11:23] or we add enough logic to handle that [11:23] which is kind of separating the upgrader from snappy [11:25] rsalveti: let's do a bootloader update snap [11:25] that's kind of the upgrader snap [11:25] we could call it update-manager.deb [11:26] because we want to update the upgrader before doing the upgrade [11:26] to work around issues in the upgrader code [11:26] rsalveti: well I think it's ok to say "we had a critical issue with BBB reliable updates; we recommend you dump+restore your installation as follows" with 16.04 [11:26] well, one of the lessons we learned with the pandaboard is that we should definitely be able to update the bootloader :) [11:27] i wonder why we make the same mistake again [11:27] but we need a working solution :-) [11:27] ogra_: right! [11:27] and why did we decide to not be able to update the snappy-update uboot script [11:27] we can have bugs anywhere [11:28] because it is dynamically created by udf today [11:28] but i guess it could just move into the snap [11:29] right, which is bad [11:30] so will send an email saying we're holding up the stable image until we are able to identify a fix for the bootloader [11:30] going with an env blob would enable us to actually drop all these files and have vars instead [11:30] ogra_: maybe something you can experiment [11:30] yes [11:32] grub uses the grubenv which is a magic file that can be written from grub [11:32] right, uboot.env would be the same [11:32] and there we do the same try-dance [11:33] the prob is that we need to touch the stamp after boot [11:33] so something in userspaxce needs to be able to modify the blob file [11:33] ogra_: yeah, grub has a save_env function for this [11:33] rsalveti: ogra_ in rolling snappy-system.txt can be updated fwiw [11:33] how does that work outside of the grub env ? [11:33] rsalveti: ogra_ just needs to go into the oem/gadget snap [11:34] uboot has a saveenv command too ... but that only works inside uboot [11:34] ogra_: oh, that works in both grub itself and the grub binary afaik [11:34] ogra_: shouldn't fw_saveenv work? [11:34] it might [11:35] ogra_: the implementation seems to be very simple, its a static 1k file, and it will simply update that, i.e. no grow/shrink and no filesystems like zfs where stuff might explode (or is checksumed) [11:35] that might explain why btfs and grubenv might be problematic [11:35] yeah [11:35] thats the idea for uboot.env too [11:35] the alternative idea? or the idea behing fatwrite? [11:36] the idea to replace fatwrite [11:36] theoretically we could even get rid of snappy-system.txt with that [11:36] ogra_: cool. if it works the same way as grub we could write a small helper that modifies the file making the same assumptions as grub [11:36] yeah [11:36] ogra_: i.e. no grow/shrink etc [11:36] i guess thats the missing bit atm [11:37] (beyond proving that the blob on top if a fat doesnt corrupt things as well :P ) [11:37] (i assume it doesnt, but this indeed needs testing) === dstokes_ is now known as dstokes [11:40] ogra_: alright, sent the email, on you now :-) [11:40] heh, ok [11:42] ogra_: writing the helper should be straightforward, aiui, the cluster size in fat32 is at least 2k so as long as thats enough we should be able to do the same as grubenv is doing in a single fat32 cluster [11:42] ogra_: but let me refresh my memory by looking at some actual documentation :) [11:45] mvo_, well, the uboot binary blob is a text file with uboot hearder afaik [11:45] we'd just need to remove the header and can edit it ... then re-add the header [11:46] or use fw_saveenv ... but i have to look if thats still working with current uboot ... [11:46] ok [11:46] ogra_: last I tried fw-saveenv wasn't working for me and lool gave me a fancy explanation [11:47] rsalveti: I say we delay release until this is fixed so new installs have a working solution [11:47] reduces the possible affected surface [11:48] can we actually change uEnv.txt in the snap (wwill it be upgraded ?) [11:49] since that has the logic to read snappy-system.txt ... so even if we cant update that file in 15.04 we could just leave it around but not use it anymore [11:51] mvo_: thanks for those tests! where/how to insert the mock partition thing was why I took so long [11:52] ogra_: in rolling yes [11:52] ogra_: in 15.04 no, but I can backport a fix [11:52] sergiusens, ah, what *can* we updae in 15.04 ? [11:52] not going to be straightforward due to all the refactoring that happened though [11:52] sergiusens: no problem, thanks for finding the issue, that was the hard part [11:53] sergiusens: yeah, already sent an email saying we're delaying the release [11:54] i just saw that email, how is fatwrite related to the base image? Is this not a u-boot issue? [11:55] i mean, i had to backport basically the whole fat driver for the ODROID u-boot to get rid of corruption. [11:57] longsleep, well, fatwrite is only used for the rollback/update logic of the core system... yes, it is a uboot issue [11:57] * ogra_ lols ... [11:57] so Commodore sells phones now [11:58] they dont look like breadboxes ! [11:59] ogra_: yes - so i fail to see how it is related to any release of the base system. U-Boot is specific to the hardware is it not? [11:59] longsleep, we ship our own uboot on the SD [11:59] ogra_: Ok - but specific for the BBB right? [12:00] specific to any of the debvices, yes [12:00] *devices [12:00] (every image ships a device specific uboot) [12:00] ogra_: and that u-boot does not have the latest fat drivers? [12:01] it does, but still causes corruption on the BBB [12:01] mhm [12:01] i see [12:01] and we want to get rid of the fatwrite bits altogether [12:01] that sounds good - it gave me lots of trouble :) [12:01] the plan is to have a uboot env in a file instead [12:01] If it helps, check if the u-boot really has all the commits i merged in https://github.com/longsleep/u-boot-odroidc/commits/master [12:02] so that we can use vars and saveenv instead ... [12:02] i hope very much that these commands are not some "rather" new feature of u-boot :) [12:03] no, the oldest ones :) [12:27] elopio: hey, in the title and description of 1474658 I think you at times mistyped 'hello-world-fwk' (which doesn't exist) for 'hello-dbus-fwk' (which does). not saying anything about the bug, just saying that reading the report is confusing because of that [12:33] good morning, [12:34] jdstrand: yes, at first it was my fault for mistyping it. [12:34] then it turned out to be a real bug. I forgot to update the title. [12:35] from fgimenez reply, I suppose that the result of search should include the origin. [12:35] but I'm not really sure why it works for hello-world without origin. [12:41] elopio: I think hello-world has an alias in the store [12:42] mmm, that would make sense. So I think I would like to see the origin as part of the name in the search output. [12:46] tedg: you around? [12:46] * ogra_ is waiting for him too ... for a phone question [12:47] ogra_: canté pri! [12:47] * Chipaca has no idea how to translate that [12:47] ogra_: something like "dibs!" [12:53] the translation to costa rican would be: "¡primas!". [12:56] elopio: i'm not sure where your female cousins come into it, but it sounds like a lot of fun. [12:56] puzzles me too. But I just do as the rest. [12:57] elopio: this might help: [12:57] http://buscon.rae.es/drae/srv/search?id=v0qAEEf8TDXX2jytCRSE|aiJ5mOGSxDXX2KPmUIAG [12:57] elopio: 20 definitions for "prima" [12:58] the beauty of spanish... ^_^ [13:22] fgimenez: a little style comment, we probably shouldn't use "get" in the function names: [13:22] http://golang.org/doc/effective_go.html#Getters [13:24] Then how to you get a getter for Git without a getGitGetter function? [13:24] mvo_, ICANHAZ your libxcb patch? [13:25] tedg: you just can't. go fmt will refactor it to panic. [13:25] elopio, That's it, we need to stick with Bazaar then. [13:25] +1. [13:26] * ogra_ notes that tedg is hiding from the #ubuntu-app-devel channel [13:26] Oh, didn't realize there was one... [13:28] elopio, why are the tests in snappy under a directory called "_integration_tests"? underscore feels weird [13:28] upperscore is harder to type :P [13:28] mterry: I found no way to exclude them from the unit test execution. [13:29] tedg: Chipaca probably has a better version if not I can pass you my original quick diff [13:29] 1 sec [13:30] elopio, huh. you mean "go test" was finding them? [13:30] uh, why did i just edit this :-/ [13:32] tedg: http://pastebin.ubuntu.com/11882626/ [13:33] Chipaca, Thanks! [13:33] meep [13:33] mterry: yes, go test ./... ignores the dirs beginning with underscore. [13:33] but this was just a quick solution. [13:34] elopio, cool, just curious :) [13:34] thanks for explaining :) [13:34] maybe we can put all the unit tests in the unit package, and use -filter unit [13:34] or maybe we can extend gocheck filter to have a -x. [13:35] tedg: point that variable to somewhere you've copied /usr/share/X11/xkb to [13:36] and it's mvo's patch; the only difference is that he said FOO, and I changed it to the more confusing XKB_CONFIG_ROOT [13:36] was tempted to make it XKB_RENDER_ENGINE [13:37] I'd really like it to be XKB_MEEP [13:37] tedg: XKB_MEEP_MEEP, and we call it the roadrunner patch [13:40] mterry: about functional tests for snapcraft, do you think we should install the snap in a snappy machine and run the binaries? or just check that the generated file seems correct? [13:41] elopio, so far I've just been testing that the files we would put in the snap are fine. But I can see the virtue in installing the snap in a snappy machine. Maybe not for all tests, but certainly when testing our final "make a snap" step [13:44] mterry: shouldn't be hard, in this case we just need to deploy a rolling edge snappy, and adt-run takes care of that. I'm thinking about running the examples, at least. === __bjf is now known as bjf [13:47] elopio, we have some integration tests already, using plainbox (in tests/plainbox) [13:47] elopio, but nothing that uses adt-run yet [13:47] elopio, for tests that want to download big things (like the go1.4 binary tarball)... how do we best do that in an automated way? [13:51] mterry: many options. But I'm inclined to run the big download at least once. So maybe do unit tests for all the parts faking the download, or one integration tests using a local source. This will be run on each MP. [13:51] and then we can have a daily suite that does the real thing, hitting the real server. [13:53] rsalveti, sergiusens, mvo_, so we seems to be missing a setting in the BBB binary ... #define FAT_ENV_FILE "uboot.env" [13:54] that allows it to boot the env blob [13:57] (it is funny, since most other TI targets actually have it set by default ... just am335x_* doesnt) [13:59] oh man [13:59] http://lists.freebsd.org/pipermail/svn-ports-head/2014-December/079896.html [14:00] -+#define FAT_ENV_FILE "uboot.env" [14:00] ++#define FAT_ENV_FILE "u-boot.env" [14:00] srysly ! [14:00] (yay for standadized names :( ... ) [14:15] ogra_: gotta love forks :-) [14:15] yeah... i'm more into spooning than into forking usually though :) [14:16] lool, so where exactly is the source we use for our uboot on the BBB [14:16] ogra_: it's 2014.10 + the patch I linked earleir [14:16] ogra_: comes from that readme I gave yesterday [14:16] lool, ah, mailine ? [14:17] *main [14:17] ogra_: http://people.canonical.com/~lool/snappy-bbb/build [14:17] ah, i only had seen the README :P [14:31] mvo_, I mentioned in an MR that I think assemble() should only wrap the binaries that are mentioned in package.yaml. I think I'll make a merge for that, FYI === bjf is now known as _jfb === _jfb is now known as _fjb [14:36] mterry: yeah, that makes perfect sense [14:36] mvo_, when we move the original executable out of the way... do you like ".real" as a suffix? or ".snapcraft"? Or ".orig" maybe? [14:37] mterry: hm, no strong opinion, .snapcraft is so specific it has the least risk of collisions :) but then, we should protect against this anyway, I don't really mind. .real is good enough for me [14:37] (but .orig is also fine) [14:37] mvo_, or we could make a new directory in the snap, snapcraft/ and put a wrapper in there, and modify package.yaml to point at our version [14:38] But maybe other parts of their code have hardcoded relative paths to their executable [14:39] But that should be fine... [14:39] They'd already be running under the right env [14:39] Well, .orig is less invasive for now [14:40] mterry: yep [14:40] mterry: silly question, how can I test inside ./snap ? would it make sense to generate the wrappers already in the stage where the ./snap is generated ? [14:41] mterry: I'm snappyfying libreoffice right now for bjoern :) [14:41] mvo_, maybe? I've used "snapcraft shell" to test inside stage/ [14:41] mvo_, are you kidding? :) [14:41] mterry: I am - mostly, I use the deb plugin to see how far I can get with just that :) [14:41] mvo_, for libreoffice, you'll almost certainly hit the hardcoded path problem [14:42] yeah [14:43] mvo_, do we want to add ld_preload logic to snapcraft? As an interim for the final bindmount/overlayfs solution? [14:44] jdstrand, did you notice the ML ? someone is asking about mounting his USB driver to extend the writable space ... do we have any story for such a use case yet ? [14:44] *drive [14:45] mterry: maybe as a option? its a pretty cool feature [14:50] mterry: just like you said :/ http://paste.ubuntu.com/11882956/ [14:50] * ogra_ notices elopio has an airtame too ... we need to talk the mir team into supporting that from the phone ;) [14:50] ogra_: it needs to be handle by a storage framework (access to a shared resource). touch is developing one. snappy doesn't have one at this time [14:50] mvo_, :( hardcoded paths are pervasive [14:50] ogra_: saviq offered on the forums to write an app. [14:50] yep [14:51] jdstrand, ok, i guess we need the same framework on both ... are the people designing that aware of this fact ? [14:51] iven the phone will switch to snappy eventually [14:51] ogra_: or, snappy could define something as part of its FHS and then app-specific rules could be added for the external storage. basically, someone needs to work with the architects to define something [14:51] right [14:51] ogra_: tvoss is designing it. he is on the architects team [14:52] would just be bad to have something on the phone that we have to throw away or re-write [14:52] ogra_: I don't think snappy was explicitly mentioned. this was more of a user-driven interaction type of thing with content-hub [14:53] i assume it would be nice if we could at least provide some hack for users so their device gets into fstab somehow [14:53] that with a change to the snappy FHS and we could create security policy for it [14:53] the guy asking actually only wants to use it in docker ... which i guess can be done via some configuration if the device is actually available or mounted [14:54] that is my understanding, yes [14:55] mterry: mvo_: hardcoded paths are pervasive, but we don't have to fix them all at once [14:55] * ogra_ would also like to use owncloud on his rpi ... [14:55] (with 1G writable space thats kind of pointless though) [14:55] elopio, yeah, I was even PM'ing with them for a bit about it but they went silent since [14:55] Saviq, well, is Mir even capable of doing such stuff ? [14:56] beyond vnc ... [14:56] ogra_, depends what you mean by "such stuff" [14:57] remote desktop ... [14:57] or desktop forwarding [14:57] ogra_, but, for what their mobile apps do (streaming content, not remote desktop), no mir support needed [14:57] (or phone forwarding) [14:57]