[00:24] sergiusens: sorry I forgot to put my test results at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/261804 [00:24] sergiusens: but yeah, it's a +1 for me as well [00:25] Chipaca is a review machine === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:00] good morning [07:11] good morning [08:36] Chipaca: hey, I think you had a idea how to make https://code.launchpad.net/~mvo/snappy/snappy-gettext nicer (?) i.e. how to get a import so that we can use G() or something similar short, or am I misremembering(?) [08:58] sergiusens: Hey - do you have any update on the review process for the ODROIDC OEM snap? It seems like it's stuck and i got no reply to my latest comments. [08:59] Good morning all; happy Eat Your Vegetables Day! [09:05] mvo: hey [09:05] mvo: yes [09:05] mvo: but only if you promise it'll only export one function (and ideally not something as collisiony as G(), but maybe i'm overthinking it) :) [09:06] Chipaca: we need two :) G() (or L() i don't care) and NG() (ngettext) [09:07] mvo: fair enough [09:07] i guess G and LG don't clash with anything right now [09:07] mvo: very easy to do, tbh; just import it with a . as we do with gocheck in the tests [09:09] Chipaca: heh, sure! great suggestion, thanks! [09:09] Chipaca: its one of these ideas thats obvious *once* you had it [09:10] \o/ [09:36] tyhicks: love your work on the CAP_NET_ADMIN thing, thank you! [09:49] longsleep: dholbach might be able to help you with the review related questions [09:51] rsalveti, hum... how=? [09:51] rsalveti, so mzanetti just asked me an interesting question ... how will phone devs develop system components on the phone once we have no dpkg support at all anymore ? [09:51] dholbach: store related review questions, thought you had review permission as well [09:52] rsalveti, yes, I do - I just wasn't sure if we had a process figured out for reviewing OEM snaps already [09:52] hm, right, that I don't know [09:52] dholbach: well i received some comments, but now the process seems to be stuck as nobody did answer lately :) [09:53] ogra_: I fail to related developing system components and dpkg here [09:53] *relate [09:53] "Supported architectures:Architecture independent" is likely wrong [09:53] rsalveti, today you build your stuff in a silo and then install the debs [09:53] let me take another look at the comments [09:53] dholbach: the only request i got was to rename it to odroid-community - i renamed it in the store only and i am not sure if that is the correct way of action [09:53] or re-build the packages locally [09:54] ogra_: right, if an app I'd imagine it would just be a simple snap, if part of core, I'd imagine you'd need to rebuild/reinstall the framework [09:54] and then install them ... [09:55] rsalveti, if the phone bits including the UI are in the core image ? [09:55] (which is how i understood the planned setup) [09:55] rsalveti, so if I want to test a small patch on unity I need to rebuild the framework? [09:55] ok, the severity of that really depends on what the framework is :D [09:55] i dont think it will be a framework ... unless rsalveti knows something new ... [09:55] for personal you would indeed just follow the current dev steps you do for phone [09:55] dpkg will be available [09:55] ah, "Architecture independent" might actually be right [09:56] rsalveti, so we will have special developer images that ship dpkg ? [09:56] once we move away from personal and get just core + snaps, then we'd need to find the right spot for your piece [09:56] i thought the masterplan was to completely get rid of it [09:56] can you elaborate on the "move away from personal" thing? [09:56] to me it looks like a dev changing core would have to re-build the whole image every time [09:57] ogra_: that is the masterplan, but I don't think that will be removed from personal [09:57] ok [09:57] as i understood some desktop discussions the plan was to only have dpkg fenced inside an lxc container we ship by default [09:57] mzanetti: so personal is a shortcut atm, since transforming everything into a snap (framework and apps), is a lot of work [09:58] jdstrand, beuno, sergiusens: regarding the odroidc oem snap decision: are you aware of anything else that needs to be done? is "arch independent" correct in this case? [09:58] so instead of doing that now, we created another base image that includes everything [09:58] (so you wouldnt have it available on the actual core system) [09:58] but if we keep it i guess thats fine then [09:58] longsleep, ^ I just went ahead and pinged some other folks who should know more [09:58] moving away from personal would mean start using the core + snaps (framework and apps) [09:58] longsleep, sorry for not being of more help here [09:58] rsalveti, you mean converting unity into a snap itself? [09:58] mzanetti: yup [09:59] dholbach: ok great thanks - no worries i am not really in any hurry as long as there is no way to handle the device part with the store. [09:59] mzanetti: how that will be done is not clear yet [09:59] rsalveti, ok. thanks for clarifying. [10:03] rsalveti, but personnal is still a snappy image and ro, so you can't dpkg things there [10:07] seb128: right, but that restriction already exists on phone images [10:07] the use case is for people already remounting things with rw [10:07] rsalveti, you can turn the phone rw by touching a file and rebooting, is that going to work on snappy? [10:08] seb128: that is still an open question (if we're going to offer something similar), but I'd imagine we don't want to do that [10:08] the logic is currently inside the initrd [10:08] not sure if for personal this is something you might want to offer [10:09] rsalveti, but you can mount -o remount rw? [10:09] seb128: if you have sudo access, sure [10:09] seb128, sure, why not [10:10] seb128, the initial question was just "what do we do if dpkg is gone" .... in which case you would have to install binary tarballs or some such [10:10] oh ok [10:10] mvo_: when tarmac complains about "there are additional revisions yadda yadda", it's the timestamp of the top-approval it's complaining about [10:10] well the snappy image is still built from debs [10:10] so no reason dpkg is gone [10:10] but since we will keep it for now even though the masterplan is to have it not in the images, we are fine [10:11] do we plan to stop using debs to build the images? [10:11] long term it will be gone, but by that time the desktop/phone will have switched to frameworks and snaps [10:11] no [10:11] not necessarily, but there is no need for dpkg to be installed [10:11] but we will likely remove dpkg at the end of the build [10:11] if we're not using it [10:11] (and a lot more) [10:12] i would imagine out core image to have only a third of the current size once we are done [10:12] if not even less [10:12] right [10:12] there is a card to investigate that [10:12] https://trello.com/c/JdwIFPwn/57-investigate-if-we-can-remove-apt-dpkg-from-the-image [10:12] yeah [10:12] rsalveti, right, it's just difficult to convince a deb system to remove dpkg :p [10:12] rm :) [10:12] well then no need to debs anymore [10:13] you can also cp [10:13] sure [10:13] perhaps we'll do that one day [10:13] but our infra is still built around packages today [10:13] right [10:13] so why not use them [10:14] on an embedded system where you are only interested in getting enough OS to boot, you dont really want the bloat [10:15] sure [10:15] the core image i envision will only have dash, systemd and a few snapp tools installed (and whatever is needed to make these run) [10:15] beuno: you around? [10:17] Chipaca: mvo_: I know sergiusens was having this issue the other day, but do you guys know why we cna't use --install=docker when creating images? looking at bug https://bugs.launchpad.net/snappy/+bug/1465879 [10:17] Ubuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed] [10:18] rsalveti: check snappy-devel [10:18] rsalveti: or, https://bugs.launchpad.net/snappy/+bug/1464486 [10:18] Ubuntu bug 1464486 in goget-ubuntu-touch (Ubuntu) "frameworks that install policies cannot be preinstalled" [Undecided,New] [10:19] rsalveti: we should confirm whether it happens with trunk snappy, as it's merged there [10:20] ah! maybe it's still needing u-d-f work [10:23] * rsalveti checks [10:24] rsalveti, Chipaca: it may just need a rebuild of u-d-f against current snappy (shared libs ftw :/) [10:25] guess also backporting https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802 ? [10:25] or just udf would be enough? (the rebuild) [10:33] Hello, I think there is a mistake in https://developer.ubuntu.com/en/snappy/guides/porting/ under "Snappy enablement basics and the device tarball." [10:33] it says: "system: directory shipping kernel modules that are only needed after the rootfs has been mounted;" [10:33] that is correct [10:34] what would you expect it to be ? [10:34] shouldn't it say modules that are needed before mounting rootfs? [10:34] no, these have to go into the initrd [10:34] ah, right [10:34] (though i'd always recommend that if you use a custom kernel you simply compile that stuff in, it is usually just something like ext4 support and the like) [10:43] The following packages have unmet dependencies: [10:43] ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.1.2-1+510~ubuntu15.10.1) but it is not going to be installed [10:43] E: Unable to correct problems, you have held broken packages. [10:43] ... from this mornings image build ... [10:43] did anyone look into that yet ? [10:43] (armhf and i386 images failed it seems) [10:45] rsalveti: it should work with the latest build already [10:46] rsalveti: or a rebuild of u-d-f I mean [10:46] sergiusens: morning :-) [10:46] we can check with Built-Using tags [10:46] good morning :-) [10:46] sergiusens: cool, guess we just need to upload a new udf and copy it over to our ppas [10:47] ogra_: hm, that version is in our ppa [10:48] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image [10:48] sergiusens: care to upload a new version once https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 gets merged? [10:48] amd64 built fine [10:48] tarmac is currently complaining about it [10:48] probably a timing error where the arch all side had not migtared [10:48] ogra_: yeah [10:48] i guess someone should just trigger a new build [10:48] rsalveti: yeah, gofmt, no sure how it happened, but it happened [10:49] rsalveti: maybe due to the files I just rebased but did not edit (I have goimports run as a PreWrite or whatever it was called in vim) [10:49] hm, but amd64 is failing quite frequently [10:49] https://launchpadlibrarian.net/209210238/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.1.2-1%2B511~ubuntu15.10.1_BUILDING.txt.gz [10:49] FAIL: touch_test.go:30: HTestSuite.TestUpdateTimestamp [10:49] mvo_: seems those unstable tests showing up again [10:50] this time for amd64 [10:50] rsalveti: heh, time based test failures ftw [10:50] * ogra_ triggers a new image [10:50] ogra_: amd64 is still ftbfs [10:50] sure, but that shouldnt make armhf and i386 fail [10:50] we we only care about armhf and amd64 atm [10:50] that package comes from the PPA ... [10:51] no proposed-migration there [10:51] so one of the main archs will fail [10:51] (or do we have it) [10:52] damn ! [10:52] * ogra_ read arm64 [10:52] there is another build in progress [10:52] someone triggered it [10:52] silly silly silly naming !!!!! [10:52] haha, /me does that all the time [10:52] well, i triggered one ... might be me [10:52] :-) [10:54] armd64 [10:54] well, at least they fail fast :) [10:55] (i386 is already done) [10:55] ricmm, on compiler level the naming is even worse ... [10:55] aargh64 [10:55] err [10:55] aarch64 [10:58] oh [10:58] amd64 succeeded [11:39] fgimenez: elopio where should I add an acceptance test for https://trello.com/c/PJE5oYAF/84-disabling-updates-and-auto-update-when-using-sideloaded-kernel-snaps ? [11:39] can any of you two help me get started? [11:39] sergiusens, oh, has that landed ? [11:39] * ogra_ needs to not forget to re-enable autopilot [11:39] ogra_: in process of [11:40] k, thanks [11:40] ogra_: got stuck in the pipeline === soee_ is now known as soee [11:41] sergiusens, currently we are adding them in _integration_tests/tests, see https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 [11:43] sergiusens, i'll push changes shortly to allow adding more than one test file, all of them are now in snappy_test.go [11:45] fgimenez: this doesn't drive image creation though, right? [11:47] sergiusens, yes, calling it with "go run _integration_tests/main.go" should do it all, compile debs, create image and call adt-run on it [11:49] fgimenez: nice, I need to create the image in a different way though [11:50] fgimenez: hmm, maybe for E2E but I can tamper with the image to set what I need [11:50] sergiusens, yep, it's not very configurable atm :) [11:53] fgimenez: should I go with the half test? [11:53] I would like to have E2E eventually though [11:56] sergiusens, how could this be setup? [11:57] Chipaca, hola [11:58] beuno: hola! [11:59] beuno: in CPI, the description is described as “Full description of the app's functionality.”. Is that one of the things entered via the online form, or is it extracted from the package? [12:00] Chipaca, yes. [12:00] Chipaca, extracted from the package, can be edited in the form [12:00] beuno: i'm confused a little, then [12:01] beuno: where is it extracted from? [12:01] beuno: "snappy build" loads it with the description from the readme [12:02] beuno: that is, it sets the manifest's description entry to the readme [12:02] to the second+ line of the readme [12:02] Chipaca, it parses it from the json [12:02] to all the non-blank lines after the first non-blank line in the readme [12:02] beuno: from the json manifest, yes? [12:03] beuno: can we make it not editable? [12:03] beuno: same place you get all the other metadata from? [12:03] Chipaca: for when time happens https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/personalCmd/+merge/262174 [12:03] beuno: because i'm confused, therefore, by the results from the store which seem to prepend the title to the description in the description [12:04] sergiusens, no, because then you need to re-upload a 800mb snap to fix a typo in the description [12:04] Chipaca, same place, es [12:05] Chipaca, I think it might merge 2 fields into the description [12:05] jayteeuk knows the details [12:05] beuno: also the title is not the title, it's the name? [12:05] seriously confused :) [12:05] It wasn't me! [12:05] beuno: right, but then the data is inconsistent as well [12:06] JamesTait: ehlo :) [12:06] sergiusens: holy, there are at least 5 branches waiting to be merged in goget [12:06] if you GET 'https://search.apps.ubuntu.com/api/v1/search?fields=title%2Cdescription&q=hello-world' [12:06] ubuntu-touch [12:06] beuno: or in other words, the local data is useless [12:06] Chipaca, 501 Syntax: EHLO hostname [12:06] 😉 [12:06] sergiusens: can we have an upload after merging https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 ? [12:06] JamesTait: ehlo chipaca [12:06] to split the personal stuff in another upload [12:07] rsalveti: yeah, didn't I says yes already :-P ? [12:07] sergiusens: just wanted to double confirm :P [12:07] JamesTait: if you GET the above uri [12:07] sergiusens, correct [12:07] JamesTait: and look at hello-world.canonical [12:07] rsalveti: split is new though... so one sec I'll set to needs review [12:07] sergiusens, the idea always was to take whatever the store told you instead of what the package says [12:07] JamesTait: or any of the others really [12:07] beuno: so why do all this packaging format if we don't need it? [12:08] sergiusens, initial seeding of the information [12:08] let's just remove icon. description, title, readme.md from the packaging [12:08] JamesTait: it seems to be setting title to ... something? and description to something else, neither of which match the title and description in the click manifest as far as i can tell [12:08] beuno: we can seed with an external file [12:08] no need for it to be part of the packaging if it's going to be useless data [12:08] mvo_: ^ [12:08] Chipaca, without having clicked on those links, let me first put pad.lv/1303354 out there. [12:09] Now let me click on the links and see what else I can add. [12:10] Chipaca, so, "look at hello-world.canonical" where? [12:10] JamesTait: in particular, the title is ... dunno what; the description is the \n-glomming of title and description [12:11] JamesTait: http://pastebin.ubuntu.com/11730186/ [12:12] beuno: sergiusens: easy way to fix that is to "fix" the package when edited [12:12] Chipaca, right, so the latter part of that is addressed by the bug I pasted above. [12:13] Chipaca, do you have a devportal link to that package? [12:13] JamesTait: i'll believe you, but i have no idea what the "app summary" or the "tagline" is, in this context [12:14] Chipaca, ew ew ew [12:14] no! [12:14] ew [12:14] JamesTait: id 1999 <- is that good enough? [12:14] no touching the binaries! [12:15] beuno: you'd rather confuse the user by letting them download things that when downloaded do not describe themselves as the things they chose to download did? [12:15] Chipaca, indeed it is. ☺ [12:15] Chipaca, or, you download the store's json when downloading the app and use that to display [12:15] beuno: you don't have to edit the binary, of course; you can also modify it on the fly when the user downloads it :-p [12:16] * beuno dims his laptop's screen to the minimum [12:16] The "Sorry, can't hear you!" approach. [12:18] beuno: that makes the client a lot harder, especially wrt uniformity of behaviour wrt sideloaded apps; it also n-uplicates information (we'd have the package.yaml, the click manifest, and the store manifest) [12:18] beuno: the data needs to be consistent though [12:18] I think it's bad design [12:18] beuno: and moves work to the client, which is underpowered and numerous [12:18] Chipaca, bear in mind that these models evolved from the old software centre ones, which were based on .deb packages. So tagline is the one-line description and app-summary is the full description. [12:19] JamesTait: http://www.brainlesstales.com/images/2013/Jul/bear-in-mind.jpg [12:19] Chipaca, in snap package terms, that maps to... hang on, checking. ☺ [12:21] deb-control(5) does not call it a tagline nor an app summary, either [12:21] Chipaca, so we make people upload 800mb to fix a typo or set a promo for their app? [12:21] short description and long description [12:21] beuno: we can also split the packaging if it's useless data as you said [12:22] the "metadata" doesn't need to be there [12:22] sergiusens: how is that different from downloading the store json? [12:22] beuno: but keep in mind the no caching rule, the store would be spammed by thousands of clients [12:22] Chipaca: oh, I'm talking about "on upload" [12:23] sergiusens: i'm talking about not understanding how that would be different for the client :) [12:23] Chipaca: the initial seeding problem [12:23] sergiusens: you mean the server would assemble the package from these bits? [12:23] Chipaca: oh, if the store stays this way the client gets more logic, and the store gets more load [12:24] ok, i'm going to move on for now, but this is a problem and needs addressing at some point [12:24] Chipaca: we'd download two bits; the store json (and icon) and the actual package (which would be a list of hashed files) [12:24] * Chipaca comes back [12:24] sergiusens: k [12:25] Chipaca: but let's break the lie about package.yaml and readme.md if it is just to "seed" [12:29] sergiusens: i didn't quite follow you there === chihchun is now known as chihchun_afk [12:29] beuno: tbh i'm starting to wonder whether having the click and snappy stores conjoined is still a good idea [12:29] we seem to be making things harder for ourselves as we go [12:30] Chipaca, I asked if I could double the team size and they counter-offered with taking away half [12:31] beuno: just in case it sounded that way, i'm not saying you or your team messed up; i do believe we've at each step collectively taken the shortest path to get places [12:31] as we should [12:32] Chipaca, :) [12:32] Chipaca, so what would you propose? [12:32] splitting away from parsing the json? [12:32] beuno: i'd propose coffee [12:32] :) [12:32] Chipaca, SOLD! [12:32] I like proposals like that. [12:33] beuno: wrt the store, is it the case that it and the cpi is getting riddled with click-vs-snappy complications? or is it still relatively unified? [12:34] JamesTait: ^ might be for you actually [12:34] * Chipaca puts on the kettle [12:35] Chipaca, I haven't seen keeping that backwards compatibility force us to make compromises [12:35] but JamesTait and nessita would have a more boots-on-the-ground answer [12:35] I'm a little out of touch with the big picture, tbh, but unless things have changed drastically the differences between handling a click package and a snap package are miniscule. === chihchun_afk is now known as chihchun [12:36] on the client side it is a little fiddly, and that's without trying to make the remote-vs-local thing go away [12:36] Like, we parse a yaml file instead of a json file, and we set the is_snap flag to True. [12:36] Chipaca, the phone went through the same remote-vs-local phase, FWIW [12:36] .... [12:36] JamesTait: you parse a yaml file? [12:36] JamesTait, we still parse the json [12:36] * May be simplifying slightly. [12:37] and snap packages copy over the yaml to json :) [12:37] “copy” [12:37] “yaml” [12:37] Chipaca, so, for the most part, we can't split the stores [12:37] because most of our deliverables apply to both [12:37] it sounds like the store is doing the least work, and we're all muddled on the client [12:38] which is not terrible, as long as we can resolve the local-vs-remote without further muddling (and which might explain why we didn't really jump at the download-another-json idea) [12:38] Chipaca, so I think the idea of downloadind a metadata blob from the store is a recurring thing [12:38] the flat namespace is a good example [12:39] another one will be the apparmor profile [12:39] which we'd like to split out and have the store attach to apps at some point [12:40] my guess is we'll end up downlading and storing a separate blob of metadata anyway [12:40] hello apt lists [12:41] :P [12:41] ogra_, you mean, parsing out of a file on one path instead of another? :) [12:42] well, i thought the scope of snappy was to get right of index files [12:42] also, if we're re-implementing apt, lets bring back dependencies! I think that's what makes it fun [12:42] *rid [12:42] beuno: i am not opposed to downloading and storing separate metadata*; i'm opposed to having three different metadata sources :) [12:43] ogra_, index files *with all apps in the archive* [12:43] ogra_, not the ones you have :) [12:43] Chipaca, SO PICKY! :) [12:43] Chipaca, agreed [12:43] * i'd quesiton whether it needs to be separate on disk, or could be on-the-fly glommed into an ar (to make debugging easier maybe) [12:44] +1 on having one source of information [12:44] Chipaca, so my naive mental model here is that you download the json blob from the store on download, refresh it every now and then, always query that for any metadata [12:44] fwiw, I dislike the idea of having metadata that is not reflected in the package. mostly on philosophical grounds right now (can not be version controlled for example and packages are no longer self-contained). but thats just me [12:45] plus its something we need to authenticated seperately, ideally having a gpg signature for the blob too [12:45] mvo_: that's why I asked for the store not to allow edits [12:45] beuno: "refresh it every now and then" is problematic [12:45] sergiusens: I like that better than the alternatives [12:45] beuno: otherwise, with you [12:45] beuno: mark said no caching [12:45] Chipaca, I'm sure cron accepts "now and then" as a parameter [12:45] especially since when we have delta downloads it won't matter if someone uploads a new version [12:45] mvo_: problem is delta uploads :) [12:46] sergiusens, I don't think he meant that. We've discussed downloading a metadata blob separate from the package many times [12:46] mvo_, it won't matter to the user [12:46] Chipaca: is it ;) we could make that work easily via snappy upload [12:46] mvo_, it'll matter to the developer uploading 800mb [12:46] beuno: right, but caching on the client he said no; ask lool ;-) [12:46] mvo_, and spamming 100k users with a no-op download to s/downlod/download [12:46] beuno: if we sign hashes.yaml thats a solvable problem [12:47] beuno: we spam even more users if we cron a apt-get update like snappy run [12:47] sergiusens, I'll bring it up, I think it will have been a different context [12:47] don't get me wrong I'm not totally opposed but I dislike it [12:47] i think there is a workable way [12:47] and I think it will come back and hunt is in bad ways [12:47] mvo_, I wouldn't cron, I'd update the list whenever you talk to the store, snappy update, etc [12:48] there will always be metadata outside of the package though [12:48] like reviews [12:48] right [12:48] and, again, we already have the flat namespace [12:49] all the metadata that the client might require while offline needs ot be in the package [12:49] well [12:49] that's the issue here [12:49] we disagree on that [12:49] ummm [12:50] maybe :) [12:50] lool: there is metadata you don't have when you're offline [12:50] Chipaca: yeah, like reviews, that's fine [12:50] yep, and all those don't need to live with the package [12:50] but you need things like the icon, the translated name [12:50] on disc [12:51] however, the package when the user creates it is a series of metadata chunks, and the binary itself [12:51] that's then sliced and diced into a .snap file [12:51] and signed [12:51] webdm ad click scope see a lot of problems with the current model fwiw [12:51] so you have a file that is, conceptually at least, a series of blobs and their signatures [12:52] s/see a lot of problems/haven't implemented separate metadata storage [12:52] when you download the package, the blobs get put in certain places, and you get the original package back again [12:52] maybe it's just confusing to have a general discussion on metadata and we only need to list the actual data and use cases [12:52] currently, the store treats the package itself as a single blob [12:52] however that does not need to stay that way [12:53] the store could treat it as a series of blob,sign pairs [12:53] and stream those [12:53] and then on unpack we'd put the metadata blob wherever, and would be none the wise [12:53] right [12:53] indeed we could [12:53] while on the server the metadata blob was stored in a database, instead of in disc, and editing happens right there [12:53] there is metadata that the store will provide that the package won't, like UUID [12:54] so the file you give the store might not match exact what is served back [12:54] and the overall signature also [12:55] but that gives an on-disc and on-the-wire format that are the same, and an in-store format that lets us edit metadata [12:55] * beuno nods [12:55] and it's all *almost* there [12:55] beuno: it's fine for the store to provide more data; it's bad for it to modify provided data [12:55] we've just not been thinking about it in these terms [12:55] sergiusens: why is it bad? [12:55] sergiusens, it isn't, the user is! [12:56] gosh this coffee is strong :) [12:56] and I don't want to force the user to re-upload 800mb to fix a typo, or even generate a new file and upload that [12:56] there's a nice web ui for them to do that [12:56]