=== erkules_ is now known as erkules [09:05] Good morning all; happy Tuesday, and happy Ferret Day! 😃 [12:16] is there a repository with the yaml files that I can look at? specifically the OEM files? I'd like to try and modify the x86_64 and the BBB files. [12:17] tbr, sergiusens would know, but i think he is off this week [12:19] thanks anyway [12:19] probably the description in the sotre gives a hint [12:19] I have a BBB with an old Angstrom still on the mmc and a lenghty uboot env. I suspect that is messing with the stock BBB Ubuntu image, as I can't get that to boot. Has anyone else ever seen that issue? Does clearing the uboot environment fix it? That's my next experiment. [12:20] I find snappy extremely interesting, but at the same time if you want to go beyond the most basic things you immediately run in the concrete wall of undocumented everything [12:20] *store [12:20] yeah, we need to work on that ... [12:20] urgently [12:21] I explicitly don't blame, but I can download tarballs of "random binaries" where I have no idea about provenance, licensing, compliance, anything. [12:22] I know the u-boot/kernel sources must be _somewhere_, but where and how the tarball came to be is again "magic" [12:22] right [12:23] I offered to help make the BBB image flashable, but fail at step zero and by FSM I'm not a person to give up easily if there is lack of documentation. [12:23] i think snappy should grow some meta field for that ... like apt has with the Vcs-Bzr or Git tags [12:23] or some manifest or metadata output [12:23] right [12:24] something where one can follow the breadcrumbs [12:25] the fact that it's the third week in a row, where mostly everyone is not available doesn't help either. [12:26] yeah, they were all at a sprint [12:26] and this week is UOS... [12:27] next week we'll all be back to normal operations === dholbach_ is now known as dholbach [12:29] I think I had less problems to dive into MeeGo, set up my own OBS, rebuild the distro and have MIC spit out an image... [12:30] and by FSM that was a major pain in the back [12:37] ogra_: actually I have to correct myself. I find it upsetting that https://developer.ubuntu.com/en/snappy/guides/porting/ just points to a bag of binaries, with no checksum and no indication of GPL compliance. [12:38] yeah, thats definitely an issue [12:38] ogra_: no, not off this week [12:38] oh [12:38] i thought you were [12:38] sergiusens, well, can you help tbr ? [12:38] to find the right sources for OEM snaps [12:38] tbr: did you get the link? https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems if not [12:38] if there are issues with the docs, can you please file a bug at https://launchpad.net/developer-ubuntu-com/+filebug please? [12:39] sergiusens, and i think he has a valid point with the GPL compliance ... [12:39] tbr: u-boot sources -> lool [12:39] we need to find a solution for that [12:39] sergiusens: come again? what about u-boot source? [12:40] tbr: the kernel comes from the debs [12:40] tbr: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary [12:41] tbr: heh, lool is an irc nick :) [12:41] lol [12:41] tbr: http://people.canonical.com/~lool/snappy-bbb/build [12:42] lool: how about we package u-boot for bbb and stick it in our ppa and I can create script that just grabs all the pieces? [12:42] and assembles the oem package [12:42] sergiusens: perhaps we can just apply that to the u-boot package itself [12:42] it's just a config addition IIRC [12:43] lool: umm, so does that archive the git sources or at least logs the git hash somewhere? [12:43] lool: the patch? are we using the same git branch? [12:43] lool: or do I need to try and build from upstream until I get a matching binary? [12:46] tbr: it's 2014.10 + the patch [12:46] sergiusens: let's just put that patch there? [12:46] http://people.canonical.com/~lool/snappy-bbb/0001-Enable-SUPPORT_RAW_INITRD-to-load-initrd.img.patch [12:46] it's a one line config change [12:47] tbr: yeah, you can try building every single revision with different compilers [12:47] lool, well, it would still be nice to be able to get a summary of used source trees via a snappy command ... at least for the binaries that want to define them [12:47] ogra_: like you can do on Android [12:47] can you ? [12:47] no [12:47] heh [12:48] well, we're better than that :) [12:48] a lot of things would be nice :-) [12:48] the development experience is still TBD [12:48] we should offer a space for metadata like this at that point [12:48] there's a source meta already [12:48] snappy sources rpi2-oem [12:48] lool: ogra_ that's what the sources of sourcery is for [12:48] and that would give you a list for source locations ... [12:48] or some such [12:49] lool: ogra_ and readme.md is free for all text [12:49] or make get-sources [12:49] sergiusens: yup [12:49] for now: it's free-form, document things the way you want [12:50] something that puts you easily into something that /could/ be considered compliance by non anal people would be immensely appreciated. I'm not an GPL nazi and don't insist on GPLv2 compliance being only possible by mailing me a CD/DVD... [12:51] we only mail packets of punchcards anyway ;) [12:51] that more environment friendly than plastic disks [12:51] that I'd like to see, but won't pay the postage for. ;-> [12:52] heh [12:52] also things are a bit more clear now 'UBOOT_BRANCH="v2014.10"' is a misnomer, as it's a tag not a branch [12:53] that at least should narrow it down to /one/ state of the source tree, not an arbitrary point of a branch [13:02] one more question, where do I find the oem yaml files? is there a repository? [13:04] tbr, i thought the first branch sergiusens pointed to had them [13:05] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files [13:11] ogra_: yeah, missed that I had it open already [13:14] hmm, that doesn't seem to indicate any specific kernel [13:14] *sigh* [13:14] * tbr digs further down the rabbit hole [13:22] tbr, it uses the kernel from the archive [13:23] no magic involved here [13:23] http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary [13:23] during build it does "apt-get install linux" ... === elopio_ is now known as elopio [13:23] and that script above copies the binary bits around then [13:25] ogra_: can I telll from the image or some _publicly_ available log which package was used? [13:26] btw: where do I file a bug against releases.ubuntu.com? some of the images are not signed [13:27] lool, ping [13:28] I mean if there is a bug in the kernel I'd like to know if I'm filing a bug against linux-image-foo-arch-bar version 42.23.5-1 or 42.23.5-666 [13:29] uname -a [13:29] .oO(pleas don't tell me to string the vmlinu* file) [13:30] seriously? [13:31] anything wrong with that ? [13:31] I mean I know that I can use uname on a _running_ system or string it, but did snappy really abolish all metadata? [13:32] you'd file it against the linux product in LP and give the info of system-image-cli ... that would be the other option ... [13:32] the person triaging can from that deduct which kernel was used ... [13:33] denying me the possibility to try and easily figure it out myself. I mean it's great if canonical wants to sell consulting hours because nobody can figure it out, but on the other hand it might also have a bit of an impact on general adoption [13:34] nobody denies you [13:35] let me rephrase that: making debugging things a ginormous pain in the back because I have to ask about everything and hope that somebody maybe answers my plea for help. to word this a bit inflamatory. [13:35] you can go to system-image.u.c weed through the index files, find the right rootfs stamp for your rootfs, then weed through the lifevs build logs, find the matching LP build ID for your rootfs build, go to the LP build job and read the log to find the kernel version that was used in that particular build [13:36] so there are logs? [13:36] mwenning: Hey Mark. I have a BBB with an older uboot environment. That env is clearly f--king up my Snappy boot. Did you have any trouble getting your stable Snappy image to boot? [13:36] if you feel comfortable with that, you can indeed do it ... you asked how to file a bug though ... for that i'd just add uname -a or system-image-cli -i [13:37] yeah, I tend to provide patches with my bugs... [13:37] mwenning: If I just knew what variables were required, I'd fix it. I deleted all of them, but that failed too. Clearly there are dependencies. [13:37] mwenning: Could boot to uboot and do a "printenv" for me? That might solve it [13:37] well, i would take the shortcut and use uname -a ... there should be matching tags on teh git tree at kernel.ubuntu.com [13:39] is that documented somewhere? maybe it's a "no need to document things for snappy as it's documented elsewhere" thing? [13:39] mwenning: pong [13:40] tbr, what, ubuntu kernel development ? [13:40] not sure the tags and versioning are ... ask in #ubuntu-kernel i guess [13:43] ogra_: I mean something more like "how do I piece things together and how do I reproduce an image, find build logs, etc" [13:43] not yet, no ... and reproducing will be really hard, our image build infra is ratther complex [13:44] :( [13:44] i once wrote a tool for doing phone builds ... that could probably be re-vived for snappy [13:44] I'll try to summarize my points about lack of metadata and logs and such [13:45] and traceability of sources [13:45] https://launchpad.net/project-rootstock-ng [13:45] I hope filing against "snappy-ubuntu" is the right thing? there are so many places... [13:46] yeah, thats the generic landing place for snappy bugs [13:46] http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch would give you a rootfs tarball (if it would be modified for snappy) ... but thats only half the bits ... [13:47] the creation of the system-image out of that lives in the system-image server ... you would have to assemble that part yourself ... [13:48] and indeed it wouldnt be upgradeable since it wont be properly signed [13:52] so basically platform development is impossible unless you are privy to run your own builds on that aystem-image machine or just resort to screwing around with the files manually [13:52] well, you patch deb packages for platform development .... thats what it boils down to [13:54] since snappy is assembled from debs in the archive [13:54] (except for u-boot in the BBB case) [13:54] yeah, but you said I can't build my own image [13:55] right, for testing you would make it temporary writable, make sure your patch works, send a debdiff or bzr merge proposal (or a git one now that LP can do git) ... and get it in one of the next image builds [13:58] ogra_: we have a tool for building phone images too [13:59] https://launchpad.net/capomastro [14:04] /join #ubuntu-uos-plenary [14:04] oops [17:30] Anyone seen such: [17:30] 2015/05/05 17:29:25 WARNING: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=default --policy-groups=networking] failed [17:30] nymi-forgerock_1.0.1_all.snap failed to install: exec: "sc-filtergen": executable file not found in $PATH [17:30] sergiusens: ^ does that sound familiar? [17:31] jdstrand: ^ perhaps? [17:32] this is with: [17:32] ubuntu-core 2015-04-20 8 ubuntu [17:32] beagleblack 2015-04-21 1.7 canonical [17:34] lool: that's strange, it should be on the image [17:35] lool: hmm [17:35] lool: could you check whether you have sc-filtergen? [17:36] i'm assuming no, but another option is that your path got buggered :) [17:38] * Chipaca peers at nothal [17:38] @ping [17:38] Chipaca: pong [17:38] nothal: some of your plugins don't expect you to be called something else [17:39] @reviewlist [17:39] https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 | No reviews (less than a day old) [17:39] https://code.launchpad.net/~stephen-stewart/webdm/install-progress-ui/+merge/258267 | No reviews (less than a day old) [17:39] https://code.launchpad.net/~stephen-stewart/webdm/success-and-failure-messaging-view/+merge/258266 | No reviews (less than a day old) [17:39] https://code.launchpad.net/~stephen-stewart/webdm/bem-html-css-for-great-justice/+merge/258265 | No reviews (less than a day old) [17:39] https://code.launchpad.net/~sergiusens/webdm/sizeSupport/+merge/258144 | Approve: 1 (1 day old) [17:39] verterok: ça marche [17:39] verterok: except maybe it's missing the lp:snappy mps? [17:39] Chipaca: I didn't find it [17:39] Chipaca: where should it be? [17:39] lool: /usr/bin/ [17:41] Chipaca: nope [17:41] (BeagleBoneBlack)ubuntu@localhost:~$ ls /usr/bin/sc* [17:41] /usr/bin/scmp_sys_resolver /usr/bin/script [17:41] /usr/bin/scp /usr/bin/scriptreplay [17:42] hi, is there a workflow for creating raw (like dd) images of snappy+snaps, for automating the build of a reproducible "releasable image" for a product? [17:43] like ubuntu-core plus 2 or 3 snaps, all bundled together (without having to log in an load the snaps etc) [17:43] mbroadst, there is ... using ubuntu-device-flash ... it has an --install option that allows you to install snaps from the store at build time [17:44] lool: your core image is boken if not there [17:45] nothal: are you operational? [17:45] Chipaca: added snappy as a branch instead of project, maybe the multiple series confuses the bot [17:45] sergiusens: it should [17:45] sergiusens: ok; thanks [17:45] will reflash [17:57] * Chipaca -> dinner making and such [18:23] lool: what was your oem snap name for rpi2? [18:24] mvo: hey! [18:24] hey sergiusens [18:24] mvo: rested a bit? [18:24] sergiusens: yes, thanks! you too? [18:25] mvo: just a bit, I only arrived yeserday at 1AM, but took Monday off so feeling good and arrived to a bigger team today as well which felt good [18:28] sergiusens: heh, true that [18:31] mvo: btw, to think about https://walledcity.com/supermighty/building-go-projects-with-gb [18:35] sergiusens: want to enable bugs in webdm lp? [18:35] beowulf: no, why would I want bugs? [18:35] :-D [18:35] * sergiusens enables bug reporting [18:36] beowulf: done [18:49] sergiusens: ta [18:57] asac: I'll be a few minutes late [19:00] mvo: what was the hangout url? (you reached me on my phone the first time) [19:03] asac: ok am on [19:03] mvo: Poke on URL too [19:08] send it to you (both) [20:26] ooh, look: code i hope to never need: https://github.com/dutchcoders/xmlgen [20:36] Chipaca: speaking of which, i need some reviews :) [20:36] wha tac oincidence! [20:37] beowulf: explain to me why i need to review a 6k-line diff :) [20:37] ELI5, even [20:38] beowulf: what does .destroy({stuff: blah}) do? [20:38] beowulf: only destroy things that match? [20:39] Chipaca: stuff: blah? [20:39] beowulf: dataType: 'html' [20:40] Chipaca: dataType: html ==> https://bugs.launchpad.net/webdm/+bug/1452011 [20:40] beowulf: and if we fix that, this code will need to change? [20:40] Chipaca: explain to me why it's 6k if 4k was removed and ~600 added :) [20:40] Chipaca: yes [20:40] beowulf: no (easy) way around that? [20:41] Chipaca: around which? [20:41] beowulf: having to change it [20:41] Chipaca: dataType: html [20:41] beowulf: do you have an example of a query that returns an empty response? [20:41] beowulf: am i spamming you with too many questions? [20:41] Chipaca: PUTs used to, they don't anymore [20:41] Chipaca: you're well within thresholds atm [20:42] Chipaca: i added the {} empty note just in case, as it catches people out [20:42] ahh, gotcha [20:42] ok [20:43] i could fix this [20:43] anyway, approving the branch [20:43] Chipaca: i await your bikeshedding the 10 line diff in the next mp ;) [20:43] * Chipaca was trying to learn! bikeshedding is more fun tho [20:44] :D [20:45] beowulf: how would i go around running the js tests? [20:47] Chipaca: assuming you have cd www/ && npm install, karma start [20:47] Chipaca: i think i should put the test running into build.sh too [20:48] beowulf: i can do that in a bit if you want [20:48] Chipaca: feel free https://bugs.launchpad.net/webdm/+bug/1452027 [20:48] hehe [20:49] i didn't know this BEM thing [20:49] Chipaca: i also plan to move all the gulp, npm stuff into the project root https://bugs.launchpad.net/webdm/+bug/1452028 [20:51] Chipaca: BEM is kinda hard, but really helps keep CSS maintainable, among other things [20:51] mhmm [20:51] i have some hope of understanding the css :) [20:54] beowulf: should all error responses also be json? [20:55] Chipaca: everything [20:56] Chipaca: orthe client needs to know, otherwise it'll throw an error trying to parse text as json [21:01] * Chipaca looks at code that does fmt.Fprint(w, fmt.Sprintf(...)) and wonders if sergiusens knows about fmt.Fprintf [21:02] Chipaca: MP that please! [21:02] sergiusens: no [21:02] sergiusens: am killing it in a different way :) [21:03] sergiusens: making all errors be json [21:04] Chipaca: yes, I have that in scope, and would welcome [21:24] sergiusens: does your vi convert tabs to spaces? [21:24] Chipaca: no, my goimports runner [21:25] sergiusens: so if i change tabs to spaces in webdm's README.md, all is good? [21:25] Chipaca: save hook, pre buf write or however you want to call it [21:25] Chipaca: oh, yeah go for it [21:25] not in all of it [21:25] just in the bits that will make the here document work [21:25] :) [21:29] Chipaca: you can feel good now that I'm finally able to look at those MPs ;-) [21:29] Chipaca: for error response btw, if you are going to do that, not sure if it's best to expand the response struct or jst use that as it is [21:31] sergiusens: was tempted to put it in structs, but then thought it better to just send strings [21:33] sergiusens: huzzah for reviews, btw [21:35] sergiusens: build.sh fails complaining about www/public not existing; do i need to mkdir that? [21:36] Chipaca: hmmm, never saw that, did you do the npm install dance? [21:36] sergiusens: yep [21:36] sergiusens: got a few warnings, that i ignored [21:36] pm WARN engine imagemin@3.1.0: wanted: {"node":">=0.10.0","npm":">=2.1.5"} (current: {"node":"0.10.25","npm":"1.4.21"}) [21:36] s/^/n/ [21:37] and two about fsevents [21:37] three actually [21:38] Building web assets with gulp... [21:38] --gulpfile www/gulpfile.js [21:38] cp: cannot stat ‘www/public’: No such file or directory [21:38] sergiusens: ^ that's the full output of build.sh [21:39] Chipaca: npm install as the ready me says; I guess we can automate that in build.sh [21:39] Chipaca: but npm feels rather fragile from my little xp with it [21:39] sergiusens: i did the two npm installs [21:39] as per the readme [21:39] Chipaca: heh, then beowulf to the rescue [21:39] also had to mkdir ~/node, which i added to the readme [21:40] he always complains about go being broken; now we get to nag him :-) [21:40] mbuahaha [21:41] sergiusens: could you show me what an "npm install" run looks like for you? [21:42] Chipaca: sure [21:42] Chipaca: btw, if you build snappy, copy it to a kvm and replace /usr/bin/snappy, does everything still work for you? [21:42] Chipaca: I get this weird thing operation not supported [21:42] hello-world failed to install: unpack /tmp/hello-world788964914 to /apps/hello-world.canonical/1.0.14 failed with exit status 1 [21:43] sergiusens: as much as i tried, yes [21:43] during unpack [21:43] sergiusens: hm! anything in dmesg? [21:43] sergiusens: is that with trunk? [21:43] sergiusens: or with copyfile? [21:44] Chipaca: it's with the arch one (which includes copyfile), but I suspect I'll see the same with trunk [21:47] Chipaca: yeah, even trunk fails for me [21:47] sergiusens: works here on amd64 [21:48] hmmm [21:48] Chipaca: so it works except for unpack here [21:49] sergiusens: df ? [21:49] Chipaca: did you follow the npm instructions even if it didn't make sense? and are you running npm from the npm dir or the system wide one? [21:49] Chipaca: the problem is, if I revert to the original snappy binary everything is dandy [21:50] Chipaca: I wonder if it's trusty related since unpack does some syscalls [21:50] Chipaca: darn, forgot to set the buffer for the terminal, npm install overflowed [21:50] sergiusens: i'll start over with them npm malarkey [21:51] Chipaca: http://paste.ubuntu.com/10992420/ that's the end of it from a clean branch run from within ./www [21:52] that's fairly similar, alhtough i didn't have the "npm http" lines (maybe you've got debug on or sth) [21:54] Chipaca: I am running the latest npm bootstrapped from the system's npm [21:54] Chipaca: oh, maybe not [21:54] which npm [21:54] /usr/bin/npm [21:55] Chipaca: I do have /home/sergiusens/node/bin in my path (which only contains gulp) [21:55] yep, ditto [21:55] and npm --version is 1.4.21 here [21:55] that's apparently fairly old though [21:55] Chipaca: I have 1.3.10 [21:55] heh [21:55] sergiusens: and what do you have in www/public ? [21:56] Chipaca: however this worked fine when I was on vivid too [21:58] sergiusens: what do you have in www/public ? [21:59] Chipaca: s public only gets populated with gulp I believe since an npm install did nothing with public [21:59] Chipaca: http://paste.ubuntu.com/10992476/ [22:01] :( [22:04] waait [22:04] gulp thinks it's echo [22:04] something is rather wrong [22:06] right! [22:11] Chipaca: huh? [22:11] sergiusens: gulp thinks it's echo [22:11] not sure how that's happening [22:11] trying to debug :) [22:12] Chipaca: maybe some function you have somewhere [22:12] http://pastebin.ubuntu.com/10992554/ [22:12] not that [22:12] tried strace [22:12] Chipaca: does the npm dir precede the system ones? [22:12] 'which gulp' points to the right place [22:12] don't have a gulp alias nor function [22:13] strace shows that the right thing is exec'ed [22:13] threw it all away and started over [22:13] Chipaca: how about running it with the absolute path? [22:13] Chipaca: just proves npm is rather flaky :-P [22:14] dammit, same thing [22:15] Chipaca: added one comment to https://code.launchpad.net/~chipaca/snappy/copyfile/+merge/258078 [22:15] at the very end [22:15] durr [22:16] you are correct :) [22:16] * Chipaca fixes [22:17] sergiusens: fixed & pushed [22:22] wrt gulp, i'm an idiot; i didn't realize and it *wasn't* picking up the right gulp. sorry for the timewaste. [22:24] Chipaca: what was it picking up? [22:26] sergiusens: ~/bin/gulp [22:26] which was a symlink to /bin/echo [22:27] heh [22:27] Chipaca: one comment for https://code.launchpad.net/~chipaca/snappy/deprecated-architectures/+merge/258112 [22:27] Chipaca: and I'll let you set the commit message [22:28] sergiusens: you mean why not invert the if/else? [22:30] Chipaca: yes, the == nil is empty [22:30] Chipaca: one comment here too https://code.launchpad.net/~chipaca/snappy/description/+merge/258276 [22:30] sergiusens: no, the == nil is not empty [22:30] Chipaca: hmm, it looked empty here :-P let me refresh just in case [22:31] no need to refresh; you've just missed it [22:31] it's a white line in a sea of red and green [22:31] Chipaca: ah [22:31] ah [22:31] ah === benoitc_ is now known as benoitc [22:31] Chipaca: the all case! [22:32] Chipaca: how does not hal tell me what's next in queue [22:32] ? [22:32] sergiusens: @activereviews ? [22:33] @activereviews [22:33] Chipaca: No existe esa orden! [22:33] @reviewlist [22:33] https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 | No reviews (less than a day old) [22:33] https://code.launchpad.net/~chipaca/snappy/description/+merge/258276 | Needs Information: 1 (less than a day old) [22:33] https://code.launchpad.net/~chipaca/snappy/vendor/+merge/258272 | No reviews (less than a day old) [22:33] https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (13 days old) [22:33] @thank you [22:33] Chipaca: No existe esa orden! [22:33] @estúpida [22:33] Chipaca: No existe esa orden! [22:34] * Chipaca hugs nothal [22:34] * nothal hugs Chipaca [22:36] sergiusens: about "# blah", i don't think we're doing that [22:36] sergiusens: i mean, if in the readme.md you put “# yadda” as the first line, that goes in verbatim [22:37] Chipaca: that's bad /me things [22:37] thinks [22:38] the whole "make a half-arsed parser of the readme.md and use that to populate things that should be in the package.yaml anyway" is an excellent idea, we should do more of it [22:38] * Chipaca is being mean [22:38] * Chipaca stops [22:38] Chipaca: please no [22:38] Chipaca: I wish I was part of the team before this idea flourished :-) [22:39] sergiusens: we should make the readme be html, and parse it with regexps [22:41] Chipaca: that's what I was forced to do with cdimage fwiw, system-image was a welcomed addition in that respect ;-) [22:41] see? told you it was a good idea [22:41] * Chipaca runs [22:42] Chipaca: good thing that we can get rid of readme.md and I would make it top level as that's what github renders by default anyways [22:42] Chipaca: we just need to proposed it [22:42] sergiusens: we should. and add any and all fields to the package.yaml, i think [22:43] Chipaca: +1 on that [22:43] i *imagine* the reason for not having everything in there is to allow people to change the metadata without reuploading [22:43] Chipaca: then the readme.md in itself is useless [22:44] oh, the readme.md thing is wrong from any angle you look at it [22:44] harr harr [22:44] drat, being mean again. i said i'd stop [22:44] i blame you :) [22:45] Chipaca: trolling is contaigeous [22:45] Chipaca: can you merge trunk for https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 ? [22:45] ... maybe [22:49] sergiusens: merged and pushed [22:56] sergiusens: do you still need information on https://code.launchpad.net/~chipaca/snappy/description/+merge/258276 ? [22:58] Chipaca: no, you answered my question [22:59] Chipaca: maybe a TODO to get rid of it would be good though :-) [23:01] Chipaca: meh, maybe just a trello [23:04] Chipaca: oh, description is in the landing pipe, do you mind updating dependencies.tsv in https://code.launchpad.net/~chipaca/webdm/vendor-and-description/+merge/258281 ? [23:04] once the merge completes [23:05]