[00:45] sergiusens: did you delete the build recipe for goget-ubuntu-touch? [02:00] rsalveti: yes, as we now have proper releases for wily [02:00] rsalveti: it was a stop gap [02:00] sergiusens: got it [02:01] sergiusens: the released images are all including webdm, right? [02:01] rsalveti: wrt to click-ubuntu-policy asac was going with desperate measures and that's why I'm on trusty today ;-) [02:01] haha, got it [02:01] sergiusens: that's cool, you can validate the tools ppa tomorrow then [02:02] sending one email now with the remaining tasks we need for the release, and one is testing that https://launchpad.net/~snappy-dev/+archive/ubuntu/tools is useful on trusty [02:02] will deprecate beta [02:04] rsalveti: yay! [02:04] rsalveti: not tonight though :-) [02:04] sergiusens: nops, tomorrow [02:30] sergiusens: ubuntu-device-flash is actually failing for me =\ [02:30] $ sudo ubuntu-device-flash core 15.04 --channel edge --enable-ssh --device generic_amd64 --output ubuntu-15.04-snappy-amd64-generic.img [02:30] Determining oem configuration [02:30] generic-amd64 failed to install: Unexpected status code 502 [02:31] not sure if a problem with the store [02:33] Yeah, there is a problem with the store (downloads) which ops are working on right now. [02:33] rsalveti: ^ [02:34] miken: oh, alright then :-) [02:34] guess that's the time to go to sleep [02:44] rsalveti: I think the store is down [02:45] sergiusens: yeah, perfect timing [02:45] rsalveti: I see those errors in click-sync too [02:45] sergiusens: before you get off, what is the right way to sideload webm? [02:45] there is the --install option but it says it's deprecated [02:45] and it also failed here [02:48] rsalveti: --install [02:48] rsalveti: or eventually the oem package would list webdm [02:48] right [02:48] rsalveti: but they would all fail the same way if the store is down [02:49] sergiusens: right [02:49] sergiusens: can I run that from my host even when creating the bbb image? [02:49] since it's a different arch [02:49] rsalveti: if you leave this for tomorrow morning I'll create oem package that include webdm [02:49] don't know the internals [02:49] sure [02:49] rsalveti: yes you can; we pick the architecture to install from from the architecture entry in the oem package [02:50] rsalveti: given fat packages, it's ofter irrelevant [02:50] great, was more worried if we had to execute something at the target arch [02:50] indeed [02:50] rsalveti: nah, it's all the same, it's an unpack, symlinks and the apparmor stuff is on first boot [02:50] awesome :-) [02:51] ok, going to bed now :-) [02:51] good night! [02:51] sergiusens: have a good night! [02:52] sergiusens: for you, for tomorrow: http://paste.ubuntu.com/11685208/ [03:50] rsalveti, sergiusens: downloads from the store should be working consistently now (thanks blahdeblah ) [03:50] awesome [03:50] miken: thanks! [04:22] rsalveti: right, live-build or vmdebootstrap are convenient starting points for building images [07:11] good morning === tvoss|dinner is now known as tvoss [07:25] hey there [07:25] slangasek, hey, still up? any suggestion on how to get the personnal image on the system-image channels? [07:26] * seb128 replied to emails before going to bed in case that would help to have things going during the european night but doesn't see a follow up in the morning :-/ [08:35] mo'in [08:36] Moe's Inn, mo'in the lawn, doing impressions of cows.....oh Morning Chipaca [08:37] * Chipaca ignores the inane remarks, and considers seppuku, or more coffee [08:38] Chipaca: I'm only part way through my first coffee is my excuse and I'm sticking to it [08:39] * Chipaca growls back [08:40] Chipaca: I know that feeling my back growls too, it's old age my friend ;) [09:03] Good morning all; happy Ball Point Pen Day! 😃 [09:31] Chipaca: sorry, no seppuku for you, you are way too important! coffee it is [09:54] I have a noob question. reading: https://developer.ubuntu.com/en/snappy/guides/porting/ [09:54] I think it states that the kernel needs to support: multiv7_defconfig [09:55] niave browsing of the kernel tree suggests to me that's exisited (for arm) in versions 3.7 and higher of the kernel [09:55] well, it needs to use the same options [09:55] does that mean I can say 'I need 3.7 or higher for easy porting with snappy'? [09:55] ogra_, that makes sense [09:55] ok, so am I right in thinking snappy uses the ubuntu vivid kernels today? [09:56] john-mcaleely: very [09:57] which looks like it might be 3.19 ? [09:59] hi - i've got a problem with updating snaps that are installed manually. i've installed my app's snap version 0.1 (containing a custom apparmor profile) and then used "snappy install " to update to a new version. the files and directories seem to be correct, but the daemon process won't start anymore with this error: "aa_change_onexec failed with -1. errmsg: No such file or directory" [09:59] plorenz: that sounds like a bug [09:59] plorenz: in us [09:59] plorenz: are you on rollin'? [10:00] Chipaca: i'm on ogra_'s RPi2 image [10:00] ogra_: was that cut from rolling? [10:00] Chipaca, 15.04 edge [10:01] hmm, that shouldn't have my "don't build apparmor" bug [10:01] well, i know that apparmor doesnt regenerate the profile if youo dont bump the version ... but that doesnt seem to be the case here [10:02] but i guess the two packages use different namespaces [10:02] (.sidleoad vs .$developer) [10:02] interestingly, i can see a file "/sys/kernel/security/apparmor/policy/profiles/rda-watchdog.sideload_rda-watchdog_0.1.5" - but i guess this should rather be 0.2 ? [10:02] ogra_: they are both .sideload [10:02] plorenz: what does 'snappy list' say? [10:03] Chipaca: "rda-watchdog 2015-06-10 0.2 sideload" [10:05] plorenz: find /var/lib/apparmor -ls [10:05] Chipaca: http://pastebin.com/J29TzWwr [10:08] plorenz: could you pastebin the systemd unit? [10:09] Chipaca: you mean the file /etc/systemd/system/rda-watchdog_rda-watchdog_0.2.service ? [10:09] plorenz: yes [10:09] sure- http://pastebin.com/AHusnvfm [10:11] /usr/bin/ubuntu-core-launcher rda-watchdog.sideload rda-watchdog.sideload_rda-watchdog_0.2 /apps/rda-watchdog.sideload/0.2/bin/rda-watchdog [10:11] that seems correct to me [10:11] the args are: qualified appname, apparmor profile, binary [10:11] plorenz: can you run that by hand and report back? [10:11] Chipaca: maybe the wrong profile was loaded? in dmesg i see this after installing the updated snap: "operation="profile_replace" profile="unconfined" name="rda-watchdog.sideload_rda-watchdog_0.1"" [10:12] ahhh [10:12] (so version 0.1) [10:12] hm [10:12] yes [10:12] running it by hand gives the same error as above [10:12] and i should have seen it the first time you said it, about the 0.1.5 [10:12] (aa_change_onexec failed with -1. errmsg: No such file or directory) [10:13] :) [10:13] plorenz: try: sudo aa-clichook -f [10:13] aa-clickhook [10:13] not clichook [10:13] sorry :) [10:14] Chipaca: no problem, i figured that one out ;) but i still get the same error [10:15] darn, and it's stupid-o'clock for most apparmor-savvy folks [10:16] hehe :) [10:16] plorenz: pastebin "sudo apparmor_status" please [10:16] i'm working from the manpages here :) [10:16] http://pastebin.com/nZFwZqwq [10:17] Chipaca: no problem :) as long as i can help [10:18] plorenz: sudo apparmor_profile -a /apps/rda-watchdog.sideload/0.2/meta/rda-watchdog.apparmor [10:19] Chipaca: that gives me a command not found error :/ [10:19] because it's apparmor_parser [10:19] not apparmor_profile [10:19] sorry :) [10:19] Chipaca: hehe - okay, it says "Unable to add "rda-watchdog.sideload_rda-watchdog_0.1". Profile already exists" [10:20] Chipaca: wait a second... i have my own apparmor profile included - maybe there's 0.1 somewhere [10:20] ooooh [10:20] looks like the profile is wrong [10:20] Chipaca: aaargh - yes, it is :( sorry! [10:20] yeah [10:21] heh! no worries. TIL. [10:21] thank you for your help :) [10:23] it's working with version 0.3 now [10:31] hello everyone, quick question, can u-d-f be used to create images for bbb from the edge channel, 15.04 release? [10:32] i'm using this sudo ubuntu-device-flash --verbose core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz [10:33] but it doesn't boot (and no serial cable yet...) [10:40] fgimenez: aiui that should work [10:40] well, except the device part thing [10:40] never used that [10:42] fgimenez: want me to try with mine? [10:42] Chipaca, i've been following https://developer.ubuntu.com/en/snappy/guides/porting/, the image generated for the stable channel works fine [10:44] Chipaca, if you can give it a try it would be very helpful :) is there a log of the failed boots? i feel blind without this serial cable... [11:27] is there any documentation on how to use snappy configure or how to set up my snaps so it works? [11:32] rickspencer3: did you read config.md? [11:32] um [11:32] Chipaca, can you tell me more? [11:33] 1 sec [11:33] rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/config.md [11:33] it's probably also on developer.u.c but dunno where. dholbach? [11:34] Chipaca, after trying again it's booting just fine with edge, perhaps i missed before a sync command, thanks! [11:34] fgimenez: ah, good! because my sd card seems to have dieded [11:34] fgimenez: or maybe my sd reader. or maybe i need to reboot. [11:35] Chipaca, so I write a program that takes standard input and outputs a yaml file? [11:35] rickspencer3: yep [11:35] then snappy restarts the service, which presumably reads the new yaml and goes? [11:35] Chipaca, seems like we could make a simple Go app for the handler, at least as a sample to get folks started [11:36] or is there something available already to get me started? [11:36] (maybe an example shell script?) [11:36] i think sergiusens had one [11:37] but it is essentially that ... create a yaml file snappy reads then [11:37] (pretty awful if you ask me) [11:38] * ogra_ would like to see "snappy config =" instead [11:39] ogra_, oh, that is not how the command works? [11:39] no, you need to pipe the yaml into it iirc [11:39] or point it to the file [11:39] * ogra_ tries to find the example [11:39] interesting [11:39] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/config-example/bin/hello [11:41] Chipaca, https://developer.ubuntu.com/en/snappy/guides/config-command/ [11:41] hmmmm [11:41] dholbach, I saw that [11:41] but there is no example of the user using the command [11:41] nor any source code to show how to implement the hook [11:42] snappy config /path/to/yaml [11:42] ogra_, right, and it looks like you can supply the yaml by just typing it on standard in [11:43] I need clearer explanations and samples to do the correct implementation myself [11:43] ogra_, so it looks like my hook needs to be a program that configures the snap [11:44] in my case, my snap is configured with a yaml file [11:44] so I need a hook that parses the yaml file, then updates it with the new content that the user specified with the snapppy config command [11:44] I know how to do this in Go, but what would you suggest for writing this? [11:45] Go worries me because then I would have to compile the hook, and then deal with multi-arch [11:49] * ogra_ hasnt rolled packages with config hooks yet ... but i would use shell and parse the yaml [11:49] ogra_: you'd parse yaml with sh? [11:50] i'd parse everything non-binary with shell :) [11:53] ok [11:53] I'm not too great with sh :/ [11:53] far from my forte [11:54] well, then use whatever else you like ... but ship the interpreter if its an interpreter lang [11:54] ogra_, no, I can try sh [11:54] I want to do the best example implementation that I can [11:55] it seems like reading a yaml file and updating it and then rewriting it should be doable [11:58] rickspencer3: note you'll be given your current config as stdin [11:59] rickspencer3: so if it's a simple transformation, maybe you can express it with sed [11:59] uh [11:59] rickspencer3: is the rest of your app written in go as well? [11:59] mvo, yes [11:59] but, I would rather have a re-usable component [11:59] well, then you need to handle the multiarch bit anyway [12:00] as well as the compiling [12:00] so shell wouldnt really be an advantage [12:00] ogra_, well, I won't necessarily write all my apps with Go [12:00] rickspencer3: the reusable component part is complicated [12:00] rickspencer3: the external interface is yaml, but internally it can be anything [12:01] rickspencer3, sure, but for a go app i would also use go for the config [12:01] sergiusens, right, I get that [12:01] rickspencer3: TBH the yaml config and the lack of sh based tools bother me as well, I wrote a python based xpath like yaml thing in one of the config examples, but its really not great [12:01] my app reads a yaml file on startup [12:01] the only advantage of shell is that you dont need to compile anything and it is always available [12:01] so, I assumed the hook would write out that file [12:01] rickspencer3: e.g.; https://github.com/sergiusens/camlistore.snap/blob/master/meta/hooks/config [12:01] but that might not work in the future :-) [12:02] rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example-bash/meta/hooks/ but you probably saw this already [12:03] mvo, I did not, but ... I thought using Python without including your own Python? [12:04] mvo, https://bugs.launchpad.net/snappy/+bug/1463804 is the bug you asked me to file [12:04] Ubuntu bug 1463804 in Snappy "Convert click manifest to package.yaml automatically" [Undecided,New] [12:04] rickspencer3: python is 15.04 material, guaranteed to stick [12:04] morning [12:04] * ogra_ would still not recommend using the system one ... [12:05] to keep your apps future proof [12:05] sergiusens: not sure it is guaranteed to stick [12:05] yeah [12:05] who knows what is ahead of us :-) [12:05] rsalveti: on 15.04 yes [12:05] on rolling no [12:05] sergiusens: mvo: rsalveti: what if we added support to the core launcher so that, if told to exec a directory, we exec directory/$arch ? [12:05] rsalveti: we said once something was released, everything on there would stick [12:06] sergiusens: right, I get that, but last time I asked about python nobody was completely sure [12:06] but I get your point [12:06] would still recommend not using the system one though, to avoid it being only compatible with 15.04 [12:07] rsalveti: oh, but that's a developer choice [12:07] rsalveti: and that means we need to remove half of our example packages ;-) [12:07] yeah, but I don't want to repackage everything for 16.04 if things change, so I'll probably go with sh [12:07] sergiusens: that might be a good idea, yeah [12:07] python3 in the apparmor allowance, so it's fine for 15.04 [12:08] once ogra_ is done with the next python tutorial that includes the interpreter [12:08] yeah, need to talk to ricmm today about that :) [12:08] * Chipaca should make an example using micropython [12:10] rickspencer3: yeah, I'm cheap and I know it will continue to work on 15.04. but 16.04+ its all up in the air [12:10] hehe [12:10] mvo, I just want to make sure that when I write stuff, it is the "right" stuff [12:11] fgimenez: you don't need to use --device-part=./device.tar.xz when creating the beagle image [12:11] unless you want to force your local device tarball [12:11] Chipaca: I'm in favour for auto-magic for multi-arch, i.e. find the right binary, setup LD_LIBRARY_PATH - there is even a branch for that [12:11] oooh [12:11] --oem beagleblack should already take care of all the dependencies [12:12] mvo: what blocks it? [12:12] rickspencer3: yeah, that is indeed the better approach :) I wonder if we should provide a go based helper for sh ? [12:12] heh [12:12] Chipaca: I blame sergiusens https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560 [12:12] mvo: *always* blame sergiusens [12:13] rsalveti, ok, much better, i'll update the notes in the pad [12:13] mvo: you'll have better-than-random chance of being right [12:13] rsalveti, fgimenez waas trying ou the porting guide ... [12:13] *out [12:13] rickspencer3: I mean, something that helps you extract your config a bit like this python-yaml-helper but as part of the system. wdyt? [12:13] mvo: Chipaca wat did i do? [12:13] (device tarball makes sens then i guess) [12:13] +e [12:13] Chipaca: heh :) [12:14] mvo, I think that I should be able to use a standard place/name for the snap configuration yaml [12:14] sergiusens: mvo: i think we should put together a branch that did this, and put it up for discussion [12:14] and then snappy automatically does config for me [12:14] tbh [12:14] mvo: Chipaca oh; well it is unanswered ;-) [12:14] and WiP [12:14] I don't see why I have to write a hook if I am not doing something custom [12:14] sergiusens: still blaming you [12:15] Chipaca: heh, this at least needs to be accompanied by proper documentation ;-) [12:15] rickspencer3: me, i think we should have "snappy set $package config=key:value" work [12:16] ogra_, i was taking it as a reference for creating bbb images with u-d-f, it's the only place in the guides where i find this mentioned [12:16] ogra_: right, if trying from the porting guide it's fine :-) [12:16] indeed, we don't have anywhere showing how to use ubuntu-device-flash [12:16] fgimenez, for "just creating" you dont need the device bit [12:17] it will simply pull it from the system-image server [12:18] ogra_, ok thx [12:19] rickspencer3: that is a good point [12:20] rickspencer3: looks like when we designed this we optimized for the uncomon case :/ for the sake of flexibility. let me try to draft something [12:20] mvo, I think I can simulate it in the meantime by writing sh script that "just works" in the meantime [12:21] where "just works" == if you name your yaml file in a certain way, the script will handle reading and writing to it [12:21] rickspencer3: well, you can't guarantee shell scripting would be accesible in the future either [12:21] (and interacting with the snappy config command, o course) [12:21] * sergiusens is trying to make a point [12:21] sergiusens, really? [12:21] sh may stop working? [12:22] rickspencer3: that is the mantra of rolling, anything, anything can stop working [12:22] wow, I have trouble envisioning such a system and how it would work [12:22] rickspencer3: what I'm saying is that it's hard to plan for something that hasn't been released [12:22] sergiusens, I think there are some things that we can predict better than others [12:22] I think "you might have to package your own Python" is more likely than "you have to package your own sh" [12:22] but, that said, noted [12:23] rickspencer3: right, but you might get something lesser than dash [12:23] * rickspencer3 nods [12:23] not compatible with whatever you script [12:23] right, I get it [12:24] sergiusens, i think you can be sure that all shells we ever ship will be POSIX compliant at least [12:24] ash, dash or busybox will all work with proper POSIX script [12:25] ogra_: depends how you configure busybox [12:25] :) [12:26] the smallest busybox shell was not very posix [12:26] oh [12:26] yeah, that might be [12:26] * Chipaca wins at pedantic [12:26] indeed i assume the busybox binaries you can currently find in ubuntu [12:27] you could shave *kilobytes* by having it not support background processes, if i remember correctly [12:27] gigantic ! [12:27] :) [12:28] mvo: btw, thanks for the reviews!!!! [12:29] :-D [12:30] sergiusens: your welcome [12:30] rickspencer3: how does http://snappy.asac.ws:9001/p/snappy-config-simplify look? as a straw-man - feel free to remove my germanism in there (and/or improve the entire approach :) [12:30] mvo, I'll look right after this call [12:32] sure [12:37] * sergiusens wonders who the green dude is [12:39] that's rickspencer3 i think [12:39] the "restart your snap" makes me think so :) [12:39] mvo, I did myt best to express myself [12:39] sergiusens, Chipaca, yeah, that was me [12:40] how did you know I was a dude? [12:40] rickspencer3: you have very masculine handwriting [12:40] anyway, this is how I think the developer should be [12:40] I think that we have the custom case implemented, but not documented holistically yet [12:41] I *think* that I can write a walk through that teaches how to do it, though [12:42] I thought dude was gender neutral these days :-) [12:43] what would be the female variant of dude ? dudette ? [12:43] anywhoooo ... [12:43] sergiusens: ogra_: depends where you are; some places it's neuter; other places, yes, dudette [12:43] * rickspencer3 moves on before a sjw shows up [12:44] * ogra_ sighs about his laptop doing another emergency shutdown due to overheating :( [12:44] I wonder if we need to design an end to end tutorial that includes all of the conventional ways of building an app for snappy? [12:44] https://msdn.microsoft.com/en-us/library/aa716527(v=vs.60).aspx [12:44] crappy vivid :((( [12:44] ^ dates me, but I always liked that they had that [12:45] * sergiusens installs vb6 [12:45] haha [12:46] rickspencer3, what are the "conventional ways" ? [12:46] heh, maybe I should get back to work instead :-P [12:46] you have so many possibilitied [12:46] *possibilities [12:46] ogra_, indeed, but ... [12:46] there are conventions also [12:46] the conventional way is the no brainer snapcraft way ;-) [12:46] I should be able to ask "what is the best way to do x" [12:46] and there should be an answer [12:46] yeah, snapcraft for everyone ! [12:46] for a greenfield [12:47] I think that we need to support two forks of developers [12:47] and we are smartly focused on fork 1 now ... people who have apps that need to be converted to snaps [12:47] but, even there, there are probably conventions [12:48] and snapcraft will be the tool for those conventions :) [12:48] we are literally just inventing these conventions [12:48] but, I am in fork 2, I want to write new apps for IoT [12:48] ogra_, I know [12:48] :) [12:48] once we have them we will indeed document them [12:48] but, there is a lot of implicit knowledge in the development team now [12:49] most of my questions do have answers, it's just really really hard to get them written down, especially when 60% of it could easily change in a week ;) [12:53] rickspencer3: +1 on better end-to-end tutorial [12:54] rickspencer3: ehh, s/better/an/ - 'cause there is none yet :) [12:54] mvo, I have written a file uploader program that uses a yaml file for configuration [12:54] I'll change it to use snappy config [12:54] https://code.launchpad.net/~rick-rickspencer3/+junk/go-uploader [12:55] then I can write a tutorial :) [12:55] rickspencer3: as for the config - does it sound acceptable if I change (2) so that your app reads from a SNAP_CONFIG_FILE environment? the reason I ask is that ideally /apps/$pkg/$ver/ is a bit of a read-only space and we want to verify that its unaltered on disk. so separating the config into a different dir would be nice. also its useful to keep the original config around for a 3-way merge (but that could be done in different ways of course) [12:56] rickspencer3: nice project [12:56] mvo, sure [12:56] all I want is that I can not worry about implementing snappy config [12:56] if I follow the rules, I want snappy config to do the work for me [12:57] * mvo nods [13:02] rickspencer3: I created a trello card for your suggestion so that it won't get lost https://trello.com/c/XHloYivT - I think its a really good idea to make this simpler [13:02] thanks mvo [13:02] meanwhile, I work on a walkthrough for the "custom" solution [13:02] * mvo nods [13:02] since we should at least explain that since it really works [13:02] yeah [13:03] I need to do this for my home IoT Gateway, anyway [13:39] mvo: can you check https://code.launchpad.net/~sergiusens/snappy/upload/+merge/261563 again please? [13:39] sergiusens: sure [13:40] sergiusens: very impressive! [13:41] mvo, so I am not actually sure where to put my file-upload.yaml [13:41] do I put it next to the executable? [13:41] i.e. in /bin/whateverarch/file-upload.yaml [13:41] ? [13:42] rickspencer3: you mean right now with the current mechanism? the recommended place is in $SNAP_APP_DATA_PATH [13:43] mvo, can you show me what that would like in the shell, i.e. appname/? [13:44] mvo: thanks [13:45] rickspencer3: something like "printf "key: value" > ${SNAP_APP_DATA_PATH}/myconfig.yaml" you mean? [13:45] rickspencer3: hope I did not misunderstand the question [13:45] mvo, sorry, my question is even more basic [13:46] my snap package has bin and meta, right? [13:46] yes [13:46] so, is there a place in there that is normal for yaml to go? [13:46] my bin is laid out with bin/amd64, bin/Arm [13:46] aha, just create a dir for that, config/ or etc/ or cfg/ or data/ [13:47] and put your base config in there [13:47] kyrofa: how about a quick hangout? [13:47] mvo, at the top level, so it is bin/ meta/ cfg/ ? [13:47] yeah [13:47] I think thats a sensible layout [13:48] k [13:48] thanks [13:49] mvo: thanks for starting the release notes :-) [13:49] mvo: elopio: fgimenez: sergiusens: ogra_: so it seems we're good to go, right? [13:50] ogra_: care to promote 82 into stable? [13:50] mvo: sergiusens: do you guys also know what needs to be done for promotion? [13:50] rsalveti: I tested with u-d-f but only last night, nothing today [13:51] sergiusens, I've got standup in a few minutes. Can I ping you after? [13:51] rsalveti, after i rebuilt it with the changes we just discussed and tested it [13:51] rsalveti, oh, you talk about the official image ? [13:51] rsalveti: prebuilts or promotion? [13:51] rsalveti: I don't know, I think there is a mail from steve somewhere how that works, but documenting it would be good I think [13:51] for prebuilts, after promotion === joet is now known as josepht [13:56] kyrofa sure [13:57] mvo: promotion is as on the phone, I bet ogra_ knows the flow [14:01]