[00:00] https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258325 just for beowulf [00:05] sergiusens: i'm not sure i've been clear in my answer to your question in json-respones [00:05] sergiusens: holler if not :) [00:41] Chipaca: last mp needs prereq ;-) [01:58] hi snappy guys, anyone around? === c74d3 is now known as _8680_ === _8680_ is now known as c74d === erkules_ is now known as erkules [07:25] Good morning all o/ [07:54] ppisati: hey [07:55] ppisati: the bcm patchset for pi2 ... does that defeat the multiplat property of our kernel? [07:55] ppisati: yes, the bcm bsp is not multiplatform-ready [07:55] ops [07:56] asac: ^ [07:56] ppisati: someone said you did a more minimalistic patchset? [07:57] i assume that is also not multiplat? [07:57] asac: ??? - it's the bcm bsp rebased, it's the same stuff [07:57] i guess making something multiplat is nothing that can be done with reasonble effort? [07:57] ppisati: ah ok. hanks [07:58] ppisati: is there a list of socs that are good for multiplat with dtb upstream.? [08:03] asac: dunno if you can reuse something of that code, and then there's the 'legal problem' of the missing sign-off - we don't knwo where that code come from, etcetc [08:04] asac: AFAIK there isn't a 'support soc' list - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Kconfig [08:04] asac: follow the Kconfig under the 'menu "Multiple platform selection"' [08:05] asac: these are all multiplatform (and indeed we turn on as mane as we can already in -generic) [08:05] asac: but their supports vary [08:05] asac: and then's there's the rest of the hardware on the boards to take in consideration [08:15] ppisati: do you have a list of those that we enable? [08:15] yeah in know that the experience will vary quite a lot :) [08:27] shouldnt snappy be making current/ directories? [08:27] because mine only has the version numbers, no current [08:27] (for data files) [08:41] hawkowl: not in data dirs [08:41] okay [08:41] so, how do i have a current/ data dir? [08:42] hawkowl: where? [08:42] on the filesystem I guess? [08:43] hawkowl: sorry, are you asking how come you have one, or how would you go around getting one? [08:43] the latter [08:43] because I want one :) [08:43] hawkowl: you wouldn't [08:43] hawkowl: why would you want one? [08:43] to store mutable and persistent local state? [08:43] sounds like you're doing something wrong [08:44] hawkowl: you use $SNAPP_APP_DATA_PATH [08:44] right [08:44] hawkowl: that gets copied over on upgrade [08:44] uh [08:44] okay, that sounds interesting [08:45] um, sorry [08:45] hawkowl: $SNAP_APP_DATA_PATH [08:45] hawkowl: SNAPP_* is deprecated :) [08:46] hawkowl: you also have $SNAP_APP_USER_DATA_PATH, fwiw [08:46] hawkowl: hello-world.env prints all these out [08:46] or it would if not for a bug wrt tmpdirs [08:46] hmm [08:46] mvo: tmpdir [08:46] mvo: i see a card about creating them [08:46] mvo: but i thought we wanted to set up a namespace and use that [08:50] Chipaca: a private mount of tmp? yes, thats the plan [08:50] Chipaca: iirc there was still some dir that was not created I need to double check the card [08:51] mvo: we've got a problem in the current implementation, afaict [08:51] mvo: where some things will create their tempdir as root (e.g. webdm) [08:51] mvo: and then you try to use hello-world.env and it can't create a tempdir because /tmp/snaps is owned by root :) [08:52] Chipaca: *autsch* [08:52] Chipaca: morning, i added a comment to www-tests about an option to run without xfvb, feel free to tell me no :) [08:53] beowulf: would you also want to reuse an existing karma server thing? [08:53] beowulf: does the way i'm running it reuse it, or does it kill it? [08:53] Chipaca: hmm, i don't think so [08:54] Chipaca: let me see [08:54] beowulf: does --single-run kill the browser window even if the test fails? [08:54] i might not have dug into this as much as it warranted [08:55] mvo: so, should i add a private /tmp/, or should i add $UID to the tempdir? [08:55] Chipaca: with an existing karam instance running and listening, 'karma start --single-run' does as you expect it to (start a new browser, run tests, close new browser) [08:55] (I'm assuming that's what you want/expect) [08:55] i expect nothing [08:56] * beowulf tries failing test [08:57] Chipaca: with failing test, same outcome, running karma watch reports failure, new instance reports failure and exits [08:57] beowulf: in any case, perhaps the best way is allowing you to override the whole command [08:58] ie ( cd www && ${JS_TESTER:-xvfb-run yadda-yadda yadda} ) [08:58] Chipaca: maybe, i don't use build.sh very often [08:59] Chipaca: i build www and scp to an existing webdm, so it's only when i need to update anything go-like that i run build [08:59] beowulf: i'm reading that as a "yes". Holler if you're trying to politely say "that's a stupid idea" [09:00] beowulf: it's run-tests, not build.sh, fwiw [09:01] * beowulf clears rubs eyes [09:01] Good morning all; happy No Homework Day! 😃 [09:04] JamesTait: \o/ [09:07] beowulf: does the json-responses branch behave as you expect? [09:07] hmm okay so if i'm writing some docs for a user [09:08] the app needs to write a .pid, so, I need to cd somewhere that it can write [09:08] where should it cd to? [09:09] hawkowl: should that pid be in tmp (non-persistent) or data (persistent)? [09:09] hawkowl: (why would you cd to the dir to make the .pid?) [09:09] Chipaca: testing now [09:09] * Chipaca hugs beowulf [09:12] Chipaca: remind me what i do to make sure i have all deps? [09:13] beowulf: build.sh should sort that out for you [09:13] beowulf: that is, if build worked, you had all the deps [09:13] Chipaca: http://pastebin.ubuntu.com/10996220/ [09:13] or was that run-checks [09:14] beowulf: yeah, run-checks is the bit that sorts that out [09:14] beowulf: if you don't/can't run the whole run-checks, godeps -u dependencies.tsv [09:15] Chipaca: so... run-checks, tell me about this [09:15] beowulf: assuming you have GOPATH and PATH set up right, just ./run-checks [09:16] Chipaca: private temp is prefered but $UID for tempdir sounds simpler and quicker for now(?) [09:16] beowulf: if you don't, then GOPATH=path/to/folder/holding/src/ PATH=..../src/bin ./run-checks [09:17] Chipaca: run-checks fails with the same error http://pastebin.ubuntu.com/10996230/ [09:18] hmmm [09:19] * Chipaca tests locally [09:19] Chipaca: in my GOPATH, launchpad.net/webdm is a symlink to ~/workspace/canonical/webdm [09:19] beowulf: i'm afraid you need to merge trunk; let me confirm [09:20] Chipaca: never be afraid [09:20] beowulf: i'm terrified [09:20] beowulf: but also, right [09:20] beowulf: bzr merge lp:webdm and all is good [09:20] should update a single file, dependencies.tsv [09:20] :) [09:22] Chipaca: \o/ [09:23] Chipaca: however... build works, run-checks does not (same failure) [09:23] but i have what i need, so na-na-na [09:28] * Chipaca fixes run-checks [09:50] Chipaca: https://code.launchpad.net/~stephen-stewart/webdm/json-responses/+merge/258355 [09:50] Chipaca: so, we've exposed some inconsistency in the use of 'message', which until now really meant 'something bad happened' [09:51] beowulf: we've exposed it, or we've started being inconsistent? [09:52] Chipaca: we've started being inconsistent, but consistency was maybe bad? [09:52] beowulf: tell me more though; i've tried to make it more consistent, not less :) [09:52] Chipaca: for example, a failed install returns a 200 with a message, which the client interprets as an error and shows the error view [09:52] Chipaca: now, a PUT also returns a message, which the client ... blah blah [09:53] Chipaca: so, maybe the webdm shouldn't return 200's for errors [09:53] :) [09:53] beowulf: it ... shouldn't [09:53] beowulf: where is it doing that? [09:53] Chipaca: so i think your branch is correct, and we need to change what exists [09:54] i tried to make it return the right status except in the most dire case [09:54] well, 'most dire'; when the json encoder falled over [09:54] i can also address that case if you're seeing it 'in real life' though [09:54] (and for PUT, am already doing so) [09:55] Chipaca: so, in my webdm docker will fail to install and has a nice error message, but the response is a 200 [09:56] Chipaca: i can screenshare if that makes it easier, but you should see for yourself if you try lp:~stephen-stewart/webdm/json-responses [09:56] looking at the code, that doesn't make sense :) [09:56] unless something weird is going on [09:56] and that *never* happens, amirite [09:56] :) [09:57] Chipaca: want to hangout and you can show me where i'm probably reading somethign wrong :) [09:57] beowulf: i'm in a coffee shop, so not sure if hangout will work, but can give it a try [09:57] oh wait, no camera and no mic unless i reboot [09:58] beowulf: screenshare should work though [09:58] Chipaca: bark twice for yes [09:59] beowulf: what's the 'nice error message'? [10:00] beowulf: try again! :) [10:01] beowulf: wasn't logged in to hangouts with my canonical account on my laptop [10:01] just on my phone, where i would not have been able to screenshare as much [10:02] Chipaca: https://plus.google.com/hangouts/_/canonical.com/chipaca-beowulf-to-the-death === bigcat is now known as bigcat[off] [10:04] beowulf: so, "accepted" is not, actually, an error [10:04] Chipaca: yep [10:04] ahh [10:04] but that is [10:05] yes [10:05] Chipaca: make sense? [10:05] yes. this is not that. [10:05] ok. [10:07] riiiiight [10:07] cmd/snappy/handlers needs the same treatment [10:09] i think [10:09] maybe [10:09] * Chipaca is not familiar enough with this code yet [10:13] sergiusens: webprogress is closing errorchan from the receiving end (this is wrong) [10:17] beowulf: what's the url that you were GETting from the progress bar? [10:25] beowulf: how about now === bigcat[off] is now known as bigcat [10:26] beowulf: (that is: json-responses should now return a 5xx when install fails) [10:26] sergiusens: you probably want to take another look at json-responses :) [10:27] Chipaca: /api/v2/packages/docker [10:27] beowulf: yep yep, figured it out in the end :) [10:28] Chipaca: looking [10:28] beowulf: merged trunk also, just for you [11:01] ogra_: question how will snappy make use of the no rebooting kernels from 4.0? I'm assuming it will be important for things like fridges that they don't turn off :) [11:05] davmor2, heh, no idea yet, i guess we'll use the feature somehow [11:19] mvo_: you around? [11:19] Chipaca: yes, almost ready for lunch though [11:19] mvo_: me too :0 [11:19] mvo_: so, about /tmp [11:19] Chipaca: what can I do for you? [11:19] mvo_: completely private, or bound-mounted from /tmp/some/thing ? [11:20] Chipaca: I think ideally completely private [11:20] mvo_: advantage of the latter is that we can dig in the tmp if we need it [11:20] Chipaca: hm, good point [11:20] Chipaca: lets do that for now [11:20] ok :) [11:20] this'll need changes on the snappy side as well, either way [11:20] making it not bound is a trivial change, post hoc [11:24] jdstrand: you around? [11:28] jdstrand: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 [11:28] mvo_: ^ but needing jdstand's input wrt it not actually, you know, working :) [11:29] (it's probably the unshare syscall getting blocked) [11:30] May 6 11:29:30 localhost kernel: [ 838.228966] audit: type=1326 audit(1430911770.184:17): auid=1000 uid=1000 gid=1000 ses=4 pid=899 comm="ubuntu-core-lau" exe="/usr/bin/ubuntu-core-launcher" sig=31 arch=c000003e syscall=272 compat=0 ip=0x7f06ba6a68e7 code=0x0 [11:30] ^ like so, see :) [11:30] Chipaca: what does scmp_resolve_syscall 272 print for this syscall? I guess unshare? [11:30] Chipaca: do you do that before the seccomp is setup? [11:31] mvo_: do i get a prize if it's "unshare"? [11:31] Chipaca: ignore me, I should look at the code instead of asking silly questions [11:31] because it's "unshare" :) [11:31] Chipaca: push it before seccomp is setup :) [11:31] mvo_: um. i should probably just [11:31] yeah [11:31] * Chipaca does that [11:51] a'ight! much better. Now getting an apparmor error :) [11:56] @reviewlist [11:56] https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | No reviews (less than a day old) [11:56] https://code.launchpad.net/~stephen-stewart/webdm/json-responses/+merge/258355 | No reviews (less than a day old) [11:56] https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258331 | No reviews (less than a day old) [11:57] https://code.launchpad.net/~chipaca/webdm/json-responses/+merge/258324 | Approve: 1 (less than a day old) [11:57] https://code.launchpad.net/~jamesodhunt/snappy/install.yaml/+merge/256925 | Needs Information: 1, Needs Fixing: 1 (14 days old) [11:58] jdstrand: [Wed May 6 11:50:43 2015] audit: type=1400 audit(1430913044.380:15): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/bin/ubuntu-core-launcher" name="/tmp/" pid=847 comm="ubuntu-core-lau" flags="rw, private" [11:58] beowulf: can karma run with a test based browser? [11:58] sergiusens: "test based"? [11:59] sergiusens: text based? [11:59] Chipaca: mvo_ watch out with unshare and 3.4 kernels [11:59] Chipaca: like lynx? [11:59] Chipaca: text of course, glad to see you are paying attention :-) [11:59] sergiusens: 1. find a text browser that does xmlhttprequest [11:59] sergiusens: 2. there is no 2, you're still on 1 [11:59] sergiusens: 3. stop lying [11:59] sergiusens: do you want headless, like phantomjs [12:00] or sort of headless, like casper(gecko) [12:01] or... [12:01] assuming you don't mean lynx [12:01] beowulf: sergiusens: phantomjs sounds like would obviate the need for xvfb [12:01] Chipaca: yes [12:01] Chipaca: casper still needs xvfb but is heading in that direction [12:01] Chipaca, wget --header="X-Requested-With: XMLHttpRequest" -qO- $URL [12:01] :P [12:02] lel [12:02] beowulf: btw, this one is waiting on your ack https://code.launchpad.net/~chipaca/webdm/json-responses/+merge/258324 [12:03] sergiusens: we've iterated on that one [12:03] sergiusens: and i've added IsError to snapPkg [12:03] sergiusens: you probably want to take a look [12:03] sergiusens: Chipaca: i can ack, or i can push a friend for it so errors work and then ack [12:04] but i'm in meetings so it might be a while [12:04] beowulf: no hurry; we might want to tweak it some more anyway [12:05] beowulf: oh, I like that IsError although not all of the errors are internalservererrors [12:05] err Chipaca I mean ^ [12:06] sergiusens: i agree; also you probably want to expose errors from other places as well? [12:06] not sure tho :) [12:06] * Chipaca does not know the codebase well enough yet [12:07] sergiusens: IsError is the minimum for the problem beowulf pointed out (wrt not getting error codes when errors happened), but it's probably part of a bigger family that requires more expressiveness [12:08] isError means 'tell the user about this {{ message }}' [12:08] Chipaca: for an installation instance, this is the only place [12:08] Chipaca: oh, so it needs to be json encoded according to beowulf [12:08] nope nope [12:09] because is error iff error status [12:09] wrt "richer interface", maybe making it an int and setting the status from inside progress [12:10] but that's a little ... alabama-ish level of familiarity [12:12] Chipaca: I don' know how to respond to that [12:13] sergiusens: the part about setting an http status from inside webprogress being incestuous, or the part about error being univocal with an error http status? [12:13] Chipaca: but wrt to installation, errors only come from there. If snappy install gave fine grained errors for everything we could start using internal status codes for easier debugging, but the text should be good enough for now [12:13] Chipaca: about alabama [12:16] sergiusens: i don't know how to move forwards with this either :-/ [12:17] Chipaca: I think it's fine for now [12:20] sergiusens: \o/ [12:22] mvo_: I'm not sure who I talked to yesterday, but I'd love to move to git but only if we have tarmac support [12:22] sergiusens: aha, so tarmac does not do git right now? [12:22] mvo_: I also want to move to gb instead of go get/build as soon as it's a bit stable [12:22] mvo_: I am mostly sure it doesn't [12:23] mvo_: afaik it was designed to work on launchpad [12:26] sergiusens: I guess we could just find dobey and ask :) [12:27] it was very much designed for bzr as well [12:27] mvo_: I just grepped the sources, no git [12:29] beuno: maybe you were thinking of svn :-p [12:30] ew. [12:31] beuno: cvs then! [12:31] * beuno mutes this channel for an hour [12:31] sergiusens: meh, yeah, I just looked at the code and it looks like adding git is quite a bit of work :/ [12:31] * Chipaca didn't get to mention rcs [12:32] mvo_: yeah, we can probably branch (err clone) and get started with something that gets the job done [12:32] mvo_: using launchpad lib and some git primitives [12:33] * Chipaca afk for a bit [12:34] sergiusens: yeah, with a bit of luck its really just "class Branch" that needs a git equivalent [12:36] hm, maybe not I see some more bzrlib imports [12:36] mvo_: it's full, not sure it's worth adapting tarmac to this, once we have webhooks we open the door for a better world :-) [12:38] indeed [12:39] looking forward for webhooks [12:42] sergiusens: zyga voiced some interesst in this as well (tarmac & git) fwiw [12:44] Chipaca: is the ubuntu-core-launcher still failing for you? if so, should I have a look? [12:52] Chipaca: simple pimple for you https://code.launchpad.net/~sergiusens/webdm/sortResults/+merge/258375 [13:05] Chipaca: I am working on mknod support for snappy right now (so that we can support the ubuntu-core tarfile, I wonder if the new copyfile using sendfile needs a update for this as well? the "old" cp -a coped with that, but I guess the new one needs some update? [13:08] sergiusens: I got questions about the rest interface, do we have anything like a draft already? I guess not but wnated to ask anyway [13:09] mvo_: no, only what was originally done for pure webdm [13:10] mvo_: which you reviewed a while back [13:10] * mvo_ nods [13:10] mvo_: I was going to look at that tomorrow and Friday [13:12] mvo_: the launcher is failing wiht apparmor error (as pasted to jdstrand above) [13:14] mvo_: note CopyFile does not replace cp -a (it doesn't deal with symlinks either fwiw) [13:15] mvo_: clickdeb/deb.go's tarCreate is doing its own thing (which handles symlinks) [13:16] mvo_: and the data directory copy is still done with cp [13:16] Chipaca: aha, excellent, thanks a bunch [13:16] mvo_: we could make a CopyThing that handles arbitrary filesystem objects [13:16] it would be quite fun actually [13:16] but we haven't [13:17] when you see CopyFile , read CopyRegularFile if you will [13:17] ta [13:23] info.Mode()&os.ModeDevice) != 0 || (info.Mode()&os.ModeCharDevice) != 0 [13:23] mvo_: info.Mode() & (os.ModeDevice | os.ModeCharDevice) != 0 ? === dholbach_ is now known as dholbach [13:24] Chipaca: good point [13:24] whatever is more readable tho [13:30] mvo_: want to include named pipes while you're at it? [13:32] mvo_: that'd be a 'p' prefix, and os.ModeNamedPipe [13:33] yeah, I guess we need to add them all step by step, can add them now (phonecall right now) [13:33] mvo_: https://code.launchpad.net/~mvo/snappy/snappy-refactor-progress-pkgname/+merge/258373 could use a commit message [13:35] Chipaca: I'll need to change webdm if that change comes through [13:35] sergiusens: i know [13:35] sergiusens: i can do it for you though :) [13:36] Chipaca: I'm doing a small refactor to that part of webdm for package removal though ;-) [13:36] sergiusens: perfect timing, then :D === leandrosansilva_ is now known as leandrosansilva2 === leandrosansilva_ is now known as leandrosansilva2 === leandrosansilva2 is now known as joseeee === joseeee is now known as joseeeee === joseeeee is now known as leandrosansilva_ === leandrosansilva_ is now known as leandrosansilva2 [13:53] Chipaca: indeed, thanks, added that now :) [13:58] if you want to join the snappy roundtable session at uos, join us in #ubuntu-uos-core [13:58] and http://summit.ubuntu.com/uos-1505/meeting/22491/snappy-roundtable/ :) [14:50] mvo_: did you push it? [14:51] Chipaca: beowulf https://plus.google.com/hangouts/_/hoaevent/AP36tYfHZBi84WKZ-0wOaKVBAs8XrHT-vTYsPw9WeCO44hNSADN1ow [14:53] Chipaca: ups, I meant the commit message, the other stuff I need to still do [14:53] Chipaca: in the UOS session right now [14:56] mvo_: and i guess you're heading into the next one [14:57] Chipaca: yeah [14:57] sergiusens: what what? [14:58] beowulf: what what what? [14:58] sergiusens: i followed the hangout link, but i was all alone :( [14:59] beowulf: Chipaca arg, lolz, that was supposed to be an MP link! [15:00] beowulf: Chipaca https://code.launchpad.net/~sergiusens/webdm/deletePackage/+merge/258394 [15:00] video editing for geeks ? [15:00] there :-) [15:00] "merge these two hangouts" :) [15:01] hate, hate hate hate, diffing structs forced upon me by silly formatting and non-whitespace-ignoring bzr [15:01] * Chipaca looks at the diff manually [15:04] sergiusens: conflict :) [15:04] Chipaca: you mean the alignment thing for members? [15:04] Chipaca: conflict of what, interest? [15:04] :-P [15:04] sergiusens: changes to the same struct (for vendor and description) [15:05] sergiusens: uninstalling --> installed in status [15:05] sergiusens: next GET is 'uninstalled' [15:05] beowulf: hmmm, let me check that [15:06] sergiusens: all other attributes are as 'uninstalled' (icon, download_size) [15:06] but the package status appears wrong until the next GET [15:07] so, mostly success :) [15:08] * beowulf makes note to remove uninstall progress bar [15:08] beowulf: I think I fixed that, pushing [15:09] beowulf: pushed [15:10] Chipaca: I did a bzr merge lp:snappy and no conflicts [15:10] Chipaca: vendor and description has landed already though, right? [15:10] sergiusens: but you marked your branch as depending on json-responses [15:10] sergiusens: wfm, +1 [15:11] sergiusens: so maybe it conflicts against that :) [15:11] Chipaca: yeah, I merged it into this, that's why (so the view is nicer) [15:11] sergiusens: right, but then i changed it and you didn't remerge i guess [15:12] Chipaca: as in, I might have done it the hard way, but I started out with bzr branch lp:webdm; bzr merge lp:json-responses; work; push [15:12] Chipaca: I'll remerge [15:12] sergiusens: ... i dunno, dude :) [15:13] sergiusens: json-responses now landed; beowulf's json-responses coming up [15:13] Chipaca: ack, almost done, but another meeting coming up [15:14] Chipaca: ignore :) [15:15] Chipaca: i have a follow up to better handle error messaging in the ui, is what i meant [15:15] Chipaca: fix merge conflict, which is just the struct spacing [15:15] srsly [15:15] s/better handle/fix [15:15] Chipaca: and pushed [15:55] Chipaca: https://code.launchpad.net/~sergiusens/webdm/snappyUpdateDeps/+merge/258406 there [15:56] and beowulf ^ easy way to solve your go get misery ;-) [15:58] sergiusens: http://bazaar.launchpad.net/~chipaca/webdm/filter-by-type/revision/119 ? [16:00] sergiusens: +1'ed yours [16:00] sergiusens: are there tests for allPackages, or should i just propose this as is? [16:02] Chipaca: no, I failed to write tests that drive the handler; I need to do these asap [16:03] * sergiusens adds missing :-/ [16:03] sergiusens: so, i should propose that as is? [16:04] Chipaca: writing a test for this doesn't seem that hard, I can write some tests and propose against your MP [16:04] MP/branch [16:05] you write all those words, but all i'm reading is "YES!" [16:05] https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 [16:07] mvo_: https://code.launchpad.net/~mvo/snappy/snappy-hashes-yaml-for-devices/+merge/258372 missing a commit messag [16:07] mvo_: eam [16:07] augh [16:08] eam: nothing, sorry [16:08] :) [16:13] * beowulf goes for food [16:13] beowulf: how dare you! [16:21] mvo_: needs-fixing'ed your branch [16:21] * Chipaca apologises profusely [16:24] does someone have a recent apparmor template example for 15.04? [16:24] unconfined is what I'm looking for; syntax from earlier doesn't work anymore [16:24] complains about policy_groups [16:57] Chipaca: are you going to add that phantomjs stuff to https://code.launchpad.net/~chipaca/webdm/www-tests/+merge/258331 ? [17:10] Chipaca: needs-fixing is fine, thanks for the review (hope its not uber stupid what I did wrong) [17:13] Chipaca: excellent review, I will look at this tomorrow, I was looking into gnu_dev_{major,minor} which uses long long as input but gnu_dev_makedev does indeed only take ints, I will fix :) [17:33] Chipaca: btw, I now remember the namespace issue we created when removing the . for frameworks and oem packages and not saving that information anywhere https://code.launchpad.net/~chipaca/webdm/filter-by-type/+merge/258408 [17:38] mvo_: we have no local searching, do we? or is activesnapbynames a lazy match? [17:39] sergiusens: sounds like you want to use snappy.Dirname(part) as the Name of the snapPkg [17:39] sergiusens: klopt dat? [17:41] Chipaca: I might have missed snappy.Dirname or maybe haven't payed attention [17:41] Chipaca: my problem is more related to remotes [17:41] sergiusens: snappy.Dirname returns the name for frameworks and oems, and name+namespace otherwise [17:42] sergiusens: it's the name of the directory above the version tree [17:42] thing [17:42] Chipaca: everything is still an app until we reupload everything [17:42] we could probably set it for you, if you super needed to [17:43] but it'd be better not to have that inconsistency [17:43] Chipaca: so for uninstalled apps/frameworks I don't know how it will land on the system to keep the resource name the same [17:44] sergiusens: if things magically change names between them being on the store and being installed, everything is terrible :) [17:44] Chipaca: so just disable that for now is my summary to avoid hacks [17:44] Chipaca: they do ;) [17:44] sergiusens: that == the commented out bit? [17:44] ex-commented out [17:44] ex-commented out-to be [17:44] should now instead be ex-(ex-commented out-to be)-to be [17:45] Chipaca: they do because we stripped out origin from installed fw and oem packages so we have to refer to packages in different ways [17:45] origin == namespaces [17:46] the inconsistencies in naming are getting crazy too [17:46] yes, we need to address that [17:46] post-iot :) [17:47] sergiusens: pushed [17:55] beuno: well, the inconsistencies exist until everyone reuploads anyways [17:55] mvo_: *unsigned* long long, even then, fwiw [18:40] Chipaca: can we do a ho in a bit? [18:59] sergiusens: yes [19:05]