[00:45] <rsalveti> sergiusens: did you delete the build recipe for goget-ubuntu-touch?
[02:00] <sergiusens> rsalveti: yes, as we now have proper releases for wily
[02:00] <sergiusens> rsalveti: it was a stop gap
[02:00] <rsalveti> sergiusens: got it
[02:01] <rsalveti> sergiusens: the released images are all including webdm, right?
[02:01] <sergiusens> rsalveti: wrt to click-ubuntu-policy asac was going with desperate measures and that's why I'm on trusty today ;-)
[02:01] <rsalveti> haha, got it
[02:01] <rsalveti> sergiusens: that's cool, you can validate the tools ppa tomorrow then
[02:02] <rsalveti> 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] <rsalveti> will deprecate beta
[02:04] <sergiusens> rsalveti: yay!
[02:04] <sergiusens> rsalveti: not tonight though :-)
[02:04] <rsalveti> sergiusens: nops, tomorrow
[02:30] <rsalveti> sergiusens: ubuntu-device-flash is actually failing for me =\
[02:30] <rsalveti> $ sudo ubuntu-device-flash core 15.04 --channel edge --enable-ssh --device generic_amd64 --output ubuntu-15.04-snappy-amd64-generic.img
[02:30] <rsalveti> Determining oem configuration
[02:30] <rsalveti> generic-amd64 failed to install: Unexpected status code 502
[02:31] <rsalveti> not sure if a problem with the store
[02:33] <miken> Yeah, there is a problem with the store (downloads) which ops are working on right now.
[02:33] <miken> rsalveti: ^
[02:34] <rsalveti> miken: oh, alright then :-)
[02:34] <rsalveti> guess that's the time to go to sleep
[02:44] <sergiusens> rsalveti: I think the store is down
[02:45] <rsalveti> sergiusens: yeah, perfect timing
[02:45] <sergiusens> rsalveti: I see those errors in click-sync too
[02:45] <rsalveti> sergiusens: before you get off, what is the right way to sideload webm?
[02:45] <rsalveti> there is the --install option but it says it's deprecated
[02:45] <rsalveti> and it also failed here
[02:48] <sergiusens> rsalveti: --install
[02:48] <sergiusens> rsalveti: or eventually the oem package would list webdm
[02:48] <rsalveti> right
[02:48] <sergiusens> rsalveti: but they would all fail the same way if the store is down
[02:49] <rsalveti> sergiusens: right
[02:49] <rsalveti> sergiusens: can I run that from my host even when creating the bbb image?
[02:49] <rsalveti> since it's a different arch
[02:49] <sergiusens> rsalveti: if you leave this for tomorrow morning I'll create oem package that include webdm
[02:49] <rsalveti> don't know the internals
[02:49] <rsalveti> sure
[02:49] <sergiusens> rsalveti: yes you can; we pick the architecture to install from from the architecture entry in the oem package
[02:50] <sergiusens> rsalveti: given fat packages, it's ofter irrelevant
[02:50] <rsalveti> great, was more worried if we had to execute something at the target arch
[02:50] <rsalveti> indeed
[02:50] <sergiusens> rsalveti: nah, it's all the same, it's an unpack, symlinks and the apparmor stuff is on first boot
[02:50] <rsalveti> awesome :-)
[02:51] <sergiusens> ok, going to bed now :-)
[02:51] <sergiusens> good night!
[02:51] <rsalveti> sergiusens: have a good night!
[02:52] <rsalveti> sergiusens: for you, for tomorrow: http://paste.ubuntu.com/11685208/
[03:50] <miken> rsalveti, sergiusens: downloads from the store should be working consistently now (thanks blahdeblah )
[03:50] <rsalveti> awesome
[03:50] <rsalveti> miken: thanks!
[04:22] <pitti> rsalveti: right, live-build or vmdebootstrap are convenient starting points for building images
[07:11] <fgimenez_> good morning
[07:25] <seb128> hey there
[07:25] <seb128> 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] <Chipaca> mo'in
[08:36] <davmor2> 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] <davmor2> 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] <davmor2> Chipaca: I know that feeling my back growls too, it's old age my friend ;)
[09:03] <JamesTait> Good morning all; happy Ball Point Pen Day! 😃
[09:31] <mvo> Chipaca: sorry, no seppuku for you, you are way too important! coffee it is
[09:54] <john-mcaleely> I have a noob question. reading: https://developer.ubuntu.com/en/snappy/guides/porting/
[09:54] <john-mcaleely> I think it states that the kernel needs to support:  multiv7_defconfig
[09:55] <john-mcaleely> 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] <ogra_> well, it needs to use the same options
[09:55] <john-mcaleely> does that mean I can say 'I need 3.7 or higher for easy porting with snappy'?
[09:55] <john-mcaleely> ogra_, that makes sense
[09:55] <john-mcaleely> ok, so am I right in thinking snappy uses the ubuntu vivid kernels today?
[09:56] <Chipaca> john-mcaleely: very
[09:57] <john-mcaleely> which looks like it might be 3.19 ?
[09:59] <plorenz> 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 <my package in version 0.2>" 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] <Chipaca> plorenz: that sounds like a bug
[09:59] <Chipaca> plorenz: in us
[09:59] <Chipaca> plorenz: are you on rollin'?
[10:00] <plorenz> Chipaca: i'm on ogra_'s RPi2 image
[10:00] <Chipaca> ogra_: was that cut from rolling?
[10:00] <ogra_> Chipaca, 15.04 edge
[10:01] <Chipaca> hmm, that shouldn't have my "don't build apparmor" bug
[10:01] <ogra_> 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] <ogra_> but i guess the two packages use different namespaces
[10:02] <ogra_> (.sidleoad vs .$developer)
[10:02] <plorenz> 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] <plorenz> ogra_: they are both .sideload
[10:02] <Chipaca> plorenz: what does 'snappy list' say?
[10:03] <plorenz> Chipaca: "rda-watchdog 2015-06-10 0.2     sideload"
[10:05] <Chipaca> plorenz: find /var/lib/apparmor -ls
[10:05] <plorenz> Chipaca: http://pastebin.com/J29TzWwr
[10:08] <Chipaca> plorenz: could you pastebin the systemd unit?
[10:09] <plorenz> Chipaca: you mean the file /etc/systemd/system/rda-watchdog_rda-watchdog_0.2.service ?
[10:09] <Chipaca> plorenz: yes
[10:09] <plorenz> sure- http://pastebin.com/AHusnvfm
[10:11] <Chipaca> /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] <Chipaca> that seems correct to me
[10:11] <Chipaca> the args are: qualified appname, apparmor profile, binary
[10:11] <Chipaca> plorenz: can you run that by hand and report back?
[10:11] <plorenz> 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] <Chipaca> ahhh
[10:12] <plorenz> (so version 0.1)
[10:12] <Chipaca> hm
[10:12] <Chipaca> yes
[10:12] <plorenz> running it by hand gives the same error as above
[10:12] <Chipaca> and i should have seen it the first time you said it, about the 0.1.5
[10:12] <plorenz> (aa_change_onexec failed with -1. errmsg: No such file or directory)
[10:13] <plorenz> :)
[10:13] <Chipaca> plorenz: try: sudo aa-clichook -f
[10:13] <Chipaca> aa-clickhook
[10:13] <Chipaca> not clichook
[10:13] <Chipaca> sorry :)
[10:14] <plorenz> Chipaca: no problem, i figured that one out ;) but i still get the same error
[10:15] <Chipaca> darn, and it's stupid-o'clock for most apparmor-savvy folks
[10:16] <plorenz> hehe :)
[10:16] <Chipaca> plorenz: pastebin "sudo apparmor_status" please
[10:16] <Chipaca> i'm working from the manpages here :)
[10:16] <plorenz> http://pastebin.com/nZFwZqwq
[10:17] <plorenz> Chipaca: no problem :) as long as i can help
[10:18] <Chipaca> plorenz: sudo apparmor_profile -a /apps/rda-watchdog.sideload/0.2/meta/rda-watchdog.apparmor
[10:19] <plorenz> Chipaca: that gives me a command not found error :/
[10:19] <Chipaca> because it's apparmor_parser
[10:19] <Chipaca> not apparmor_profile
[10:19] <Chipaca> sorry :)
[10:19] <plorenz> Chipaca: hehe - okay, it says "Unable to add "rda-watchdog.sideload_rda-watchdog_0.1".  Profile already exists"
[10:20] <plorenz> Chipaca: wait a second... i have my own apparmor profile included - maybe there's 0.1 somewhere
[10:20] <Chipaca> ooooh
[10:20] <Chipaca> looks like the profile is wrong
[10:20] <plorenz> Chipaca: aaargh - yes, it is :( sorry!
[10:20] <Chipaca> yeah
[10:21] <Chipaca> heh! no worries. TIL.
[10:21] <plorenz> thank you for your help :)
[10:23] <plorenz> it's working with version 0.3 now
[10:31] <fgimenez> hello everyone, quick question, can u-d-f be used to create images for bbb from the edge channel, 15.04 release?
[10:32] <fgimenez> 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] <fgimenez> but it doesn't boot (and no serial cable yet...)
[10:40] <Chipaca> fgimenez: aiui that should work
[10:40] <Chipaca> well, except the device part thing
[10:40] <Chipaca> never used that
[10:42] <Chipaca> fgimenez: want me to try with mine?
[10:42] <fgimenez> Chipaca, i've been following https://developer.ubuntu.com/en/snappy/guides/porting/, the image generated for the stable channel works fine
[10:44] <fgimenez> 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] <rickspencer3> is there any documentation on how to use snappy configure or how to set up my snaps so it works?
[11:32] <Chipaca> rickspencer3: did you read config.md?
[11:32] <rickspencer3> um
[11:32] <rickspencer3> Chipaca, can you tell me more?
[11:33] <Chipaca> 1 sec
[11:33] <Chipaca> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/config.md
[11:33] <Chipaca> it's probably also on developer.u.c but dunno where. dholbach?
[11:34] <fgimenez> Chipaca, after trying again it's booting just fine with edge, perhaps i missed before a sync command, thanks!
[11:34] <Chipaca> fgimenez: ah, good! because my sd card seems to have dieded
[11:34] <Chipaca> fgimenez: or maybe my sd reader. or maybe i need to reboot.
[11:35] <rickspencer3> Chipaca, so I write a program that takes standard input and outputs a yaml file?
[11:35] <Chipaca> rickspencer3: yep
[11:35] <rickspencer3> then snappy restarts the service, which presumably reads the new yaml and goes?
[11:35] <rickspencer3> Chipaca, seems like we could make a simple Go app for the handler, at least as a sample to get folks started
[11:36] <rickspencer3> or is there something available already to get me started?
[11:36] <rickspencer3> (maybe an example shell script?)
[11:36] <ogra_> i think sergiusens had one
[11:37] <ogra_> but it is essentially that ... create a yaml file snappy reads then
[11:37] <ogra_> (pretty awful if you ask me)
[11:38]  * ogra_ would like to see "snappy config <package> <key>=<value>" instead
[11:39] <rickspencer3> ogra_, oh, that is not how the command works?
[11:39] <ogra_> no, you need to pipe the yaml into it iirc
[11:39] <ogra_> or point it to the file
[11:39]  * ogra_ tries to find the example
[11:39] <rickspencer3> interesting
[11:39] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/config-example/bin/hello
[11:41] <dholbach> Chipaca, https://developer.ubuntu.com/en/snappy/guides/config-command/
[11:41] <rickspencer3> hmmmm
[11:41] <rickspencer3> dholbach, I saw that
[11:41] <rickspencer3> but there is no example of the user using the command
[11:41] <rickspencer3> nor any source code to show how to implement the hook
[11:42] <ogra_> snappy config <package> /path/to/yaml
[11:42] <rickspencer3> ogra_, right, and it looks like you can supply the yaml by just typing it on standard in
[11:43] <rickspencer3> I need clearer explanations and samples to do the correct implementation myself
[11:43] <rickspencer3> ogra_, so it looks like my hook needs to be a program that configures the snap
[11:44] <rickspencer3> in my case, my snap is configured with a yaml file
[11:44] <rickspencer3> 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] <rickspencer3> I know how to do this in Go, but what would you suggest for writing this?
[11:45] <rickspencer3> 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] <Chipaca> ogra_: you'd parse yaml with sh?
[11:50] <ogra_> i'd parse everything non-binary with shell :)
[11:53] <rickspencer3> ok
[11:53] <rickspencer3> I'm not too great with sh :/
[11:53] <rickspencer3> far from my forte
[11:54] <ogra_> well, then use whatever else you like ... but ship the interpreter if its an interpreter lang
[11:54] <rickspencer3> ogra_, no, I can try sh
[11:54] <rickspencer3> I want to do the best example implementation that I can
[11:55] <rickspencer3> it seems like reading a yaml file and updating it and then rewriting it should be doable
[11:58] <Chipaca> rickspencer3: note you'll be given your current config as stdin
[11:59] <Chipaca> rickspencer3: so if it's a simple transformation, maybe you can express it with sed
[11:59] <rickspencer3> uh
[11:59] <mvo> rickspencer3: is the rest of your app written in go as well?
[11:59] <rickspencer3> mvo, yes
[11:59] <rickspencer3> but, I would rather have a re-usable component
[11:59] <ogra_> well, then you need to handle the multiarch bit anyway
[12:00] <ogra_> as well as the compiling
[12:00] <ogra_> so shell wouldnt really be an advantage
[12:00] <rickspencer3> ogra_, well, I won't necessarily write all my apps with Go
[12:00] <sergiusens> rickspencer3: the reusable component part is complicated
[12:00] <sergiusens> rickspencer3: the external interface is yaml, but internally it can be anything
[12:01] <ogra_> rickspencer3, sure, but for a go app i would also use go for the config
[12:01] <rickspencer3> sergiusens, right, I get that
[12:01] <mvo> 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] <rickspencer3> my app reads a yaml file on startup
[12:01] <ogra_> the only advantage of shell is that you dont need to compile anything and it is always available
[12:01] <rickspencer3> so, I assumed the hook would write out that file
[12:01] <sergiusens> rickspencer3: e.g.; https://github.com/sergiusens/camlistore.snap/blob/master/meta/hooks/config
[12:01] <sergiusens> but that might not work in the future :-)
[12:02] <mvo> 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] <rickspencer3> mvo, I did not, but ... I thought using Python without including your own Python?
[12:04] <dholbach> mvo, https://bugs.launchpad.net/snappy/+bug/1463804 is the bug you asked me to file
[12:04] <sergiusens> rickspencer3: python is 15.04 material, guaranteed to stick
[12:04] <rsalveti> morning
[12:04]  * ogra_ would still not recommend using the system one ... 
[12:05] <ogra_> to keep your apps future proof
[12:05] <rsalveti> sergiusens: not sure it is guaranteed to stick
[12:05] <rickspencer3> yeah
[12:05] <rsalveti> who knows what is ahead of us :-)
[12:05] <sergiusens> rsalveti: on 15.04 yes
[12:05] <sergiusens> on rolling no
[12:05] <Chipaca> 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] <sergiusens> rsalveti: we said once something was released, everything on there would stick
[12:06] <rsalveti> sergiusens: right, I get that, but last time I asked about python nobody was completely sure
[12:06] <rsalveti> but I get your point
[12:06] <rsalveti> would still recommend not using the system one though, to avoid it being only compatible with 15.04
[12:07] <sergiusens> rsalveti: oh, but that's a developer choice
[12:07] <sergiusens> rsalveti: and that means we need to remove half of our example packages ;-)
[12:07] <rickspencer3> yeah, but I don't want to repackage everything for 16.04 if things change, so I'll probably go with sh
[12:07] <rsalveti> sergiusens: that might be a good idea, yeah
[12:07] <sergiusens> python3 in the apparmor allowance, so it's fine for 15.04
[12:08] <rsalveti> once ogra_ is done with the next python tutorial that includes the interpreter
[12:08] <ogra_> yeah, need to talk to ricmm today about that :)
[12:08]  * Chipaca should make an example using micropython
[12:10] <mvo> 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] <rickspencer3> hehe
[12:10] <rickspencer3> mvo, I just want to make sure that when I write stuff, it is the "right" stuff
[12:11] <rsalveti> fgimenez: you don't need to use --device-part=./device.tar.xz when creating the beagle image
[12:11] <rsalveti> unless you want to force your local device tarball
[12:11] <mvo> 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] <Chipaca> oooh
[12:11] <rsalveti> --oem beagleblack should already take care of all the dependencies
[12:12] <Chipaca> mvo: what blocks it?
[12:12] <mvo> rickspencer3: yeah, that is indeed the better approach :) I wonder if we should provide a go based helper for sh ?
[12:12] <ogra_> heh
[12:12] <mvo> Chipaca: I blame sergiusens https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560
[12:12] <Chipaca> mvo: *always* blame sergiusens
[12:13] <fgimenez> rsalveti, ok, much better, i'll update the notes in the pad
[12:13] <Chipaca> mvo: you'll have better-than-random chance of being right
[12:13] <ogra_> rsalveti, fgimenez waas trying ou the porting guide ...
[12:13] <ogra_> *out
[12:13] <mvo> 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] <sergiusens> mvo: Chipaca wat did i do?
[12:13] <ogra_> (device tarball makes sens then i guess)
[12:13] <ogra_> +e
[12:13] <mvo> Chipaca: heh :)
[12:14] <rickspencer3> mvo, I think that I should be able to use a standard place/name for the snap configuration yaml
[12:14] <Chipaca> sergiusens: mvo: i think we should put together a branch that did this, and put it up for discussion
[12:14] <rickspencer3> and then snappy automatically does config for me
[12:14] <rickspencer3> tbh
[12:14] <sergiusens> mvo: Chipaca oh; well it is unanswered ;-)
[12:14] <sergiusens> and WiP
[12:14] <rickspencer3> I don't see why I have to write a hook if I am not doing something custom
[12:14] <Chipaca> sergiusens: still blaming you
[12:15] <sergiusens> Chipaca: heh, this at least needs to be accompanied by proper documentation ;-)
[12:15] <Chipaca> rickspencer3: me, i think we should have "snappy set $package config=key:value" work
[12:16] <fgimenez> 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] <rsalveti> ogra_: right, if trying from the porting guide it's fine :-)
[12:16] <rsalveti> indeed, we don't have anywhere showing how to use ubuntu-device-flash
[12:16] <ogra_> fgimenez, for "just creating" you dont need the device bit
[12:17] <ogra_> it will simply pull it from the system-image server
[12:18] <fgimenez> ogra_, ok thx
[12:19] <mvo> rickspencer3: that is a good point
[12:20] <mvo> 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] <rickspencer3> mvo, I think I can simulate it in the meantime by writing sh script that "just works" in the meantime
[12:21] <rickspencer3> where "just works" == if you name your yaml file in a certain way, the script will handle reading and writing to it
[12:21] <sergiusens> rickspencer3: well, you can't guarantee shell scripting would be accesible in the future either
[12:21] <rickspencer3> (and interacting with the snappy config command, o course)
[12:21]  * sergiusens is trying to make a point
[12:21] <rickspencer3> sergiusens, really?
[12:21] <rickspencer3> sh may stop working?
[12:22] <sergiusens> rickspencer3: that is the mantra of rolling, anything, anything can stop working
[12:22] <rickspencer3> wow, I have trouble envisioning such a system and how it would work
[12:22] <sergiusens> rickspencer3: what I'm saying is that it's hard to plan for something that hasn't been released
[12:22] <rickspencer3> sergiusens, I think there are some things that we can predict better than others
[12:22] <rickspencer3> I think "you might have to package your own Python" is more likely than "you have to package your own sh"
[12:22] <rickspencer3> but, that said, noted
[12:23] <sergiusens> rickspencer3: right, but you might get something lesser than dash
[12:23]  * rickspencer3 nods
[12:23] <sergiusens> not compatible with whatever you script
[12:23] <rickspencer3> right,  I get it
[12:24] <ogra_> sergiusens, i think you can be sure that all shells we ever ship will be POSIX compliant at least
[12:24] <ogra_> ash, dash or busybox will all work with proper POSIX script
[12:25] <Chipaca> ogra_: depends how you configure busybox
[12:25] <Chipaca> :)
[12:26] <Chipaca> the smallest busybox shell was not very posix
[12:26] <ogra_> oh
[12:26] <ogra_> yeah, that might be
[12:26]  * Chipaca wins at pedantic
[12:26] <ogra_> indeed i assume the busybox binaries you can currently find in ubuntu
[12:27] <Chipaca> you could shave *kilobytes* by having it not support background processes, if i remember correctly
[12:27] <ogra_> gigantic !
[12:27] <ogra_> :)
[12:28] <sergiusens> mvo: btw, thanks for the reviews!!!!
[12:29] <sergiusens> :-D
[12:30] <mvo> sergiusens: your welcome
[12:30] <mvo> 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] <rickspencer3> mvo, I'll look right after this call
[12:32] <mvo> sure
[12:37]  * sergiusens wonders who the green dude is
[12:39] <Chipaca> that's rickspencer3 i think
[12:39] <Chipaca> the "restart your snap" makes me think so :)
[12:39] <rickspencer3> mvo, I did myt best to express myself
[12:39] <rickspencer3> sergiusens, Chipaca, yeah, that was me
[12:40] <rickspencer3> how did you know I was a dude?
[12:40] <Chipaca> rickspencer3: you have very masculine handwriting
[12:40] <rickspencer3> anyway, this is how I think the developer should be
[12:40] <rickspencer3> I think that we have the custom case implemented, but not documented holistically yet
[12:41] <rickspencer3> I *think* that I can write a walk through that teaches how to do it, though
[12:42] <sergiusens> I thought dude was gender neutral these days :-)
[12:43] <ogra_> what would be the female variant of dude ? dudette ?
[12:43] <rickspencer3> anywhoooo ...
[12:43] <Chipaca> 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] <rickspencer3> 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] <rickspencer3> https://msdn.microsoft.com/en-us/library/aa716527(v=vs.60).aspx
[12:44] <ogra_> crappy vivid :(((
[12:44] <rickspencer3> ^ dates me, but I always liked that they had that
[12:45]  * sergiusens installs vb6
[12:45] <rickspencer3> haha
[12:46] <ogra_> rickspencer3, what are the "conventional ways" ?
[12:46] <sergiusens> heh, maybe I should get back to work instead :-P
[12:46] <ogra_> you have so many possibilitied
[12:46] <ogra_> *possibilities
[12:46] <rickspencer3> ogra_, indeed, but ...
[12:46] <rickspencer3> there are conventions also
[12:46] <sergiusens> the conventional way is the no brainer snapcraft way ;-)
[12:46] <rickspencer3> I should be able to ask "what is the best way to do x"
[12:46] <rickspencer3> and  there should be an answer
[12:46] <ogra_> yeah, snapcraft for everyone !
[12:46] <rickspencer3> for a greenfield
[12:47] <rickspencer3> I think that we need to support two forks of developers
[12:47] <rickspencer3> and we are smartly focused on fork 1 now ... people who have apps that need to be converted to snaps
[12:47] <rickspencer3> but, even there, there are probably conventions
[12:48] <rickspencer3> and snapcraft will be the tool for those conventions :)
[12:48] <ogra_> we are literally just inventing these conventions
[12:48] <rickspencer3> but, I am in fork 2, I want to write new apps for IoT
[12:48] <rickspencer3> ogra_, I know
[12:48] <rickspencer3> :)
[12:48] <ogra_> once we have them we will indeed document them
[12:48] <rickspencer3> but, there is a lot of implicit knowledge in the development team now
[12:49] <rickspencer3> 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] <mvo> rickspencer3: +1 on better end-to-end tutorial
[12:54] <mvo> rickspencer3: ehh, s/better/an/ - 'cause there is none yet :)
[12:54] <rickspencer3> mvo, I have written a file uploader program that uses a yaml file for configuration
[12:54] <rickspencer3> I'll change it to use snappy config
[12:54] <rickspencer3> https://code.launchpad.net/~rick-rickspencer3/+junk/go-uploader
[12:55] <rickspencer3> then I can write a tutorial :)
[12:55] <mvo> 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] <mvo> rickspencer3: nice project
[12:56] <rickspencer3> mvo, sure
[12:56] <rickspencer3> all I want is that I can not worry about implementing snappy config
[12:56] <rickspencer3> if I follow the rules, I want snappy config to do the work for me
[12:57]  * mvo nods
[13:02] <mvo> 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] <rickspencer3> thanks mvo
[13:02] <rickspencer3> meanwhile, I work on a walkthrough for the "custom" solution
[13:02]  * mvo nods
[13:02] <rickspencer3> since we should at least explain that since it really works
[13:02] <mvo> yeah
[13:03] <rickspencer3> I need to do this for my home IoT Gateway, anyway
[13:39] <sergiusens> mvo: can you check https://code.launchpad.net/~sergiusens/snappy/upload/+merge/261563 again please?
[13:39] <mvo> sergiusens: sure
[13:40] <mvo> sergiusens: very impressive!
[13:41] <rickspencer3> mvo, so I am not actually sure where to put my file-upload.yaml
[13:41] <rickspencer3> do I put it next to the executable?
[13:41] <rickspencer3> i.e. in /bin/whateverarch/file-upload.yaml
[13:41] <rickspencer3> ?
[13:42] <mvo> rickspencer3: you mean right now with the current mechanism? the recommended place is in $SNAP_APP_DATA_PATH
[13:43] <rickspencer3> mvo, can you show me what that would like in the shell, i.e. appname/?
[13:44] <sergiusens> mvo: thanks
[13:45] <mvo> rickspencer3: something like "printf "key: value" > ${SNAP_APP_DATA_PATH}/myconfig.yaml" you mean?
[13:45] <mvo> rickspencer3: hope I did not misunderstand the question
[13:45] <rickspencer3> mvo, sorry, my question is even more basic
[13:46] <rickspencer3> my snap package has bin and meta, right?
[13:46] <mvo> yes
[13:46] <rickspencer3> so, is there a place in there that is normal for yaml to go?
[13:46] <rickspencer3> my bin is laid out with bin/amd64, bin/Arm
[13:46] <mvo> aha, just create a dir for that, config/ or etc/ or cfg/ or data/
[13:47] <mvo> and put your base config in there
[13:47] <sergiusens> kyrofa: how about a quick hangout?
[13:47] <rickspencer3> mvo, at the top level, so it is bin/ meta/ cfg/ ?
[13:47] <mvo> yeah
[13:47] <mvo> I think thats a sensible layout
[13:48] <rickspencer3> k
[13:48] <rickspencer3> thanks
[13:49] <rsalveti> mvo: thanks for starting the release notes :-)
[13:49] <rsalveti> mvo: elopio: fgimenez: sergiusens: ogra_: so it seems we're good to go, right?
[13:50] <rsalveti> ogra_: care to promote 82 into stable?
[13:50] <rsalveti> mvo: sergiusens: do you guys also know what needs to be done for promotion?
[13:50] <sergiusens> rsalveti: I tested with u-d-f but only last night, nothing today
[13:51] <kyrofa> sergiusens, I've got standup in a few minutes. Can I ping you after?
[13:51] <ogra_> rsalveti, after i rebuilt it with the changes we just discussed and tested it
[13:51] <ogra_> rsalveti, oh, you talk about the official image ?
[13:51] <sergiusens> rsalveti: prebuilts or promotion?
[13:51] <mvo> 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] <sergiusens> for prebuilts, after promotion
[13:56] <sergiusens> kyrofa sure
[13:57] <sergiusens> mvo: promotion is as on the phone, I bet ogra_ knows the flow
[14:01] <rsalveti> sergiusens: ogra_: not prebuitls, promotion itself
[14:01] <rsalveti> like we do for the phones
[14:01] <rsalveti> we basically need to promote 82 into stable
[14:01] <ogra_> right, thats just a call to copy-image but i need the exact channel names
[14:01] <rsalveti> and then I can create the pre-built images
[14:02] <rsalveti> yeah, would be nice to document that
[14:02] <rsalveti> I created the card https://trello.com/c/PUpWXouz/89-stable-release-checkpoints to be a placeholder for release related things
[14:04] <fgimenez> rsalveti, tested the full suite in kvm, "long" upgrade path (stable -> edge -1 -> edge), rollback and failed boot in bbb, no new issues
[14:05] <ogra_> rsalveti, mvo, do we promote whatever cruft is in 15.04/edge/generic_arm64 ?
[14:05]  * jdstrand wonders how plorenz had a version in "his own apparmor profile". Maybe he is using "security-policy" and didn't write the profile with the correct variables to be expanded via aa-profile-hook...
[14:05]  * jdstrand shrugs
[14:05] <ogra_> and do we promote azure images too ?
[14:06] <mvo> fgimenez: what does no *new* issues mean, do we have existing ones (sorry if this is a silly question)
[14:06] <mvo> ogra_: arm64? I doubt this even works :/ no idea why its there in the first place
[14:07] <ogra_> well, something gets regularly imported into edge :)
[14:07] <ogra_> whatever that is
[14:07] <sergiusens> ogra_: rsalveti mvo what do you think of http://snappy.asac.ws:9001/p/promotion
[14:07] <fgimenez> mvo, i mean that nothing new has arisen, sorry if it wasn't clear enough :)
[14:08] <ogra_> sergiusens, what is alpha ?
[14:08] <sergiusens> ogra_: a channel
[14:08] <ogra_> sergiusens, any why do we need it ?
[14:08] <mvo> fgimenez: cool, nothing new and nothing old so no known issues, thats  great, thanks a lot for the testing
[14:08] <ogra_> we test from edge
[14:08] <sergiusens> ogra_: to make sure the upgrade from what is in stable to what goes to edge is going to work
[14:09] <ogra_> well, creating channels is a slangasek thing i guess ...
[14:09] <ogra_> (i could poke around in the config but i have never added a new channel and would feel more comfortable if someone does that who has experience)
[14:09] <rsalveti> ogra_: sergiusens: right, we don't have an alpha at the moment
[14:10] <rsalveti> we can promote from edge to stable now and then work on creating the alpha
[14:10] <ogra_> ok
[14:10] <sergiusens> rsalveti: I know we don't, but it's an easy way to test the upgrade path as a final step
[14:10] <rsalveti> for now having alpha won't change anything, right?
[14:10] <rsalveti> sergiusens: how different that would be from stable -> edge?
[14:10] <sergiusens> rsalveti: doing a channel change triggers a full image update
[14:10] <rsalveti> sergiusens: right
[14:11] <ogra_> you have one test channel where you can try out automated upgrades fir4st
[14:11] <ogra_> makes sense
[14:11] <rsalveti> then we'd need to create it :-)
[14:11] <ogra_> right
[14:12] <elopio> buenos días
[14:15] <fgimenez> elopio, hey! good to see those "i" with accent around :)
[14:17] <elopio> fgimenez: :) how are you today?
[14:17] <elopio> davidcalle: I want to make some small changes on the guides that are not in the snappy branch. How can I edit those docs?
[14:19] <sergiusens> jdstrand: not sure it's my image, but is ReleaseName allowed? [ 3993.417227] audit: type=1107 audit(1433945875.311:61): pid=604 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="ReleaseName" mask="send" name="org.freedesktop.DBus" pid=1439 label="hello-dbus-fwk_srv_1.0.0" peer_label="unconfined"
[14:20] <davidcalle> elopio, you can have editor access on the website with the lp team: https://launchpad.net/~ubuntudeveloperportal-editors
[14:20] <elopio> dpm: can you please approve my membership there? ^
[14:21] <elopio> davidcalle: what's the review process? I would like you or somebody else to check what I change before it goes live.
[14:21] <fgimenez> elopio, fine, getting to know this bbb thing :)
[14:22] <jdstrand> mvo: hi! with the mtime patch from jjohansen, do we still need to have the meeting today?
[14:22] <davidcalle> elopio, when you edit a page, you are in "draft" mode, other editors have access to it, just ping me when you are done :)
[14:22] <rickspencer3> hmmm
[14:22] <dpm> elopio, done
[14:22] <elopio> davidcalle: dpm: thanks.
[14:22] <mvo> jdstrand: I thought I replied by mail, as far as I'm concerned we are fine and I don't need the meeting
[14:22] <rickspencer3> can anyone advise me on the best way to refer to a file path in Go code in a snap?
[14:22] <mvo> jdstrand: his patch is the outcome I had hoped for from the meeting
[14:23] <rickspencer3> is just using "../../data/" considered ok, or is there a better, more reliable way?
[14:23] <davidcalle> elopio, I have to run for ~1h , dpm or dholbach, do you mind sending the editors guide link to elopio?
[14:23] <dpm> davidcalle, already done :)
[14:23] <davidcalle> dpm :)
[14:23] <jdstrand> mvo: oh you did-- I'm still going through my inbox and I filtered on 'cache', but the subject said 'caching'
[14:23] <jdstrand> mvo: ok-- we may want to revisit this in the future, but I'll cancel the meeting for now
[14:23] <mvo> rickspencer3: its probably better to use "dir := os.Getenv("SNAP_APP_DATA_PATH")" (or any of the other ones)
[14:24] <mvo> jdstrand: revisit for a different approach like using hashes? as long as the functionatlity remians  I don't mind how its implemented :)
[14:24] <rickspencer3> thanks mvo
[14:24] <ogra_> sergiusens, rsalveti, alpha channel has been created (will show up with the next importer run)
[14:26] <jdstrand> mvo: no, I more meant make sure we are satisfying all of snappy's needs
[14:26] <ogra_> and there it is
[14:26] <jdstrand> rsalveti: I think you scheduled the apparmor caching meeting-- can you remove it?
[14:26] <mvo> jdstrand: ok
[14:26] <rsalveti> ogra_: and are we importing the current stable images in there?
[14:26] <rsalveti> jdstrand: sure
[14:27] <jdstrand> thanks
[14:27] <ogra_> rsalveti, it is a completely dead channel, only for manual copying
[14:27] <ogra_> rsalveti, but yes, i'm doing exactly that right now
[14:27] <rsalveti> ogra_: awesome
[14:27] <davidcalle> elopio, good luck! Feel free to ping me when I'm back if you have issues with the edition, some aspects of the cms can seem tricky the first time
[14:27] <elopio> davidcalle: will do.
[14:28] <ogra_> oh
[14:28] <ogra_> and i see, stable only has armhf and amd64
[14:28] <mvo> yes, thats ok
[14:28] <mvo> we never released a stable i386 yet
[14:29] <ogra_> ok, "alpha" now has the stable image 2 in it
[14:30] <ogra_> now everyone needs to install that ... and i can copy the latest from edge
[14:36] <rsalveti> http://www.ronpaul.com/wp-content/uploads/2015/03/its-happening.jpg \o/
[14:37] <ogra_> heh
[14:38] <mvo> haha
[14:42] <ogra_> hmm
[14:43] <ogra_> using --enable-ssh instead of --developer-mode refuses to use my oem snap
[14:43] <gatisp> Hi. I was wondering if there is a snappy command for selecting older core image version? I have freshly flashed device with a latest version, so there is nothing to rollback to, but maybe there are another ways to get older version? This part does not seem to be documented anywhere. Thanks.
[14:44] <ogra_> gatisp, ubuntu-device-flash has a --revision option that you could use to create an older image
[14:45] <gatisp> ah ok, will check. Did not know about that tool, I just downloaded the *.img file and dd-ed to Rpi2
[14:45] <ogra_> sergiusens, hulp ... how do i create an image without having my personal ssh key inside when i use a local oem snap ?
[14:46] <ogra_> Determining oem configuration
[14:46] <ogra_> 2015-06-10 14:45:29 ERROR snappy logger.go:199 pi2_0.13_all.snap failed to install: Signature verification failed with exit status 10
[14:46] <ogra_> pi2_0.13_all.snap failed to install: Signature verification failed with exit status 10
[14:46] <ogra_> (for details)
[14:48] <sergiusens> ogra_: ah, you can't
[14:48] <ogra_> damn
[14:49] <sergiusens> ogra_: sort of to avoid random non signed pkgs distributed
[14:49] <ogra_> sure, i get the reason
[14:49] <sergiusens> ogra_: well, build it from a user with no keys I guess
[14:49] <sergiusens> ogra_: that's a workaround :-P
[14:49] <sergiusens> ogra_: also, why not put your rpi snap into the store?
[14:49] <ogra_> will it then just give me a normal usr/password login ?
[14:49] <ogra_> yes, i was planning that
[14:50] <sergiusens> ah, you need to override anyways due to the device part
[14:50] <ogra_> i just have never done an oem snap :)
[14:50] <mvo> ogra_: fwiw, I created amd64/armhf image from the alpha channel now, so let me know once they can/should be upgraded
[14:50] <ogra_> sure, but it makes sense to eventually update the store one
[14:50] <sergiusens> ogra_: it should just work (random user no keys and --developer-mode)
[14:51] <ogra_> mvo, i wanted to make a call in the standup and once everyone who participates is ready i'll just copy edge on top and upgrades should magically happen
[14:51] <mvo> cool
[14:51] <ogra_> sergiusens, ok, i'll try that
[14:51]  * ogra_ guesses just moving ~/.ssh out of the way should be enough
[14:51] <sergiusens> beuno: if I have snappy pakage N available for release X and X+1, upload N+1 and only tag it for X+1, what happens to N that was on X
[14:51] <sergiusens> ?
[14:52] <sergiusens> beuno: I'm asking because the channels document mentions this is working already, but I don't think it is
[14:52] <beuno> sergiusens, not what it should
[14:52] <beuno> there's oversight there
[14:52] <beuno> where we need 2 versions of the app available at the same time for different releases
[14:52] <sergiusens> beuno: shouldn't it work though?
[14:53] <beuno> sergiusens, the newest version is the only one that will be available
[14:53] <beuno> so that's something we need to fi
[14:53] <sergiusens> more so since we are diverging 15.04 and rolling as days pass
[14:53] <beuno> indeed
[14:53] <beuno> sergiusens, can you file a bug pretty please?
[14:54] <sergiusens> beuno: ack
[14:54]  * sergiusens just uploaded the last * release compatible webdm
[14:55] <ogra_> Enabling developer mode...
[14:55] <ogra_> failed to obtain a public key for developer mode: open /home/ogra/.ssh: no such file or directory: no pub ssh key found, run ssh-keygen first
[14:55] <ogra_> aha
[14:55] <ogra_> that looks good then
[14:55] <ogra_> (but now i'm not sure which webdm i got :P)
[14:56] <sergiusens> beuno: bug 1463872
[14:57] <sergiusens> ogra_: you might want 0.9
[14:57] <ogra_> sergiusens, i know what i want
[14:57] <sergiusens> lol
[14:57] <ogra_> i just dont know what i got :)
[14:57] <ogra_> u-d-f doesnt tell me the version
[14:57]  * ogra_ will re-create after the meeting ... by then 0.9 should surely have promoted i guess
[14:58] <beuno> nessita, FYI bug 1463872
[14:58] <nessita> beuno, checking
[14:58] <sergiusens> beuno: also, your input on this is welcomed https://myapps.developer.ubuntu.com/dev/click-apps/2822/feedback/
[14:58] <kyrofa> sergiusens, alright, I'm out of meetings now. You available?
[14:59] <sergiusens> kyrofa: that was a long standup!
[14:59] <sergiusens> kyrofa: I now have mine :P
[14:59] <beuno> sergiusens, done
[15:00] <sergiusens> ty
[15:01] <kyrofa> sergiusens, we have it every day, and for some reason today my uncaffeinated mind thought it was a half hour earlier :P
[15:02] <kyrofa> sergiusens, I sat around wondering why people were so late for a while
[15:03] <kyrofa> sergiusens, anyway, the rest of my day is free. Just ping me when you've got some free time :)
[15:06] <sergiusens> kyrofa: ok, I'll ping after lunch if that's fine; what your timezone btw?
[15:07] <kyrofa> EST-- I'm in Virginia
[15:10] <nessita> sergiusens, beuno we don't support different version per releases, I think that will be possible with channels. Without channels, a package can have only one "live and valid" upload at a time
[15:10] <nessita> this is the same behavior as with frameworkds
[15:10] <nessita> beuno, the goal was to avoid developers neglecting older version in older frameworks
[15:11] <beuno> nessita, yes
[15:11] <beuno> I think releases are different
[15:11] <beuno> because they are built to co-exist
[15:11] <beuno> so we'll need to think about that
[15:11] <sergiusens> there is overlap with releases
[15:11] <sergiusens> right
[15:11] <sergiusens> as in support timeframe
[15:11] <nessita> beuno, right, currently releases are the same a frameworks with other name
[15:12] <nessita> beuno, so this new requirement combined with channels will be super extra interesting to design and implement
[15:12] <beuno> nessita, don't need to combine them
[15:12] <beuno> just FYI
[15:12] <nessita> "fun" fabian says
[15:12] <beuno> we'll figure out priorities
[15:12] <nessita> beuno, combined at code level, I mean :-)
[15:13] <beuno> nessita, this is why people become managers
[15:15] <nessita> beuno, to think about when priotitizing: are we allowing targetting different releases in each upload in each channel?
[15:16] <nessita> I mean, the index will soon start returning results for a specific channel only
[15:18] <beuno> nessita, we will need to allow uploading different binaries to different releases to different channels
[15:19] <Chipaca> mvo: https://github.com/google/gxui/blob/master/samples/progress_bar/main.go :-p
[15:19] <longsleep> sergiusens: If possible we can discuss OEM snap submissiong name scheme here as well (regarding ODROID snap sumission feedback on app 2822).
[15:19] <nessita> beuno, exactly, so, "boom in heads and in source code", but of course, always doable
[15:19] <nessita> beuno, let me add this to the backlog
[15:20] <beuno> nessita, thanks, sorry
[15:20] <mvo> Chipaca: oh? is that a new/different progress bar? I was too lazy to be honest to look for a different one than the "gb" i was using
[15:22] <elopio> utlemming: do you have some time today to talk about the testing your team does for the snappy cloud images?
[15:26] <mvo> sergiusens: re cache> one option might be to do what python-httplib2 is doing and cache transparently by storing the http headers (i.e. valid-until etc) plus the content and simply use that to check if the net needs to hit at all etc. that was used in s-c-agent
[15:28] <sergiusens> mvo: right, that was my last idea; transparent caching proxy, would solve all scopes in general
[15:29] <mvo> sergiusens: yeah, I used it quite successfuly in the past
[15:36] <Chipaca> we can construct a unique version number, thus: 2^(kernel #) + 3^(device #) + 5^(os #) + ... + prime_n^(# of part_n)
[15:37] <mvo> Chipaca: heh, indeed
[15:37] <ogra_> *********** I give everyone another 30mins to install an alpha image and in 30min i will copy over the edge image into the channel **************
[15:37] <Chipaca> mvo: wrt progress bars, i was kidding about gxui (it's too green yet). That program, when run, looks something like http://i.imgur.com/ta4AE1Q.gif
[15:37] <sergiusens> ogra_: so heavy
[15:37] <ogra_> (speak up if thats to short)
[15:37]  * Chipaca goes to get some tea
[15:38] <ogra_> sergiusens, i'm a drama queen ;)
[15:38]  * Chipaca didn't know we supported alphas, goes to dig his out of the attic
[15:38] <mvo> Chipaca: I don't even know what gxui is
[15:38] <ogra_> sergiusens, is webdm 0.9 published ?
[15:38] <sergiusens> ogra_: it should be, let me check
[15:39] <sergiusens> ogra_: search.apps.ubuntu.com/api/v1/package/webdm
[15:39] <sergiusens> it is
[15:39] <Chipaca> mvo: google's experimental green-as-a-Nezara-viridula cross-platform ui library
[15:39] <ogra_> sergiusens, awesome, thanks !
[15:39]  * ogra_ re-rolls the pi image
[15:42] <sergiusens> elopio: is the selftest stuff documented?
[15:49] <ogra_> no webdm ... and cloud-init spills errors on my new pi image :(
[15:49] <ogra_> �[  235.955313] cloud-init[832]: 2015-06-10 15:49:14,086 - url_helper.py[WARNING]: Calling 'http://192.168.2.2/latest/meta-data/instance-id' failed [50/120s]: request error [HTTPConnectionPool(host='192.168.2.2', port=80): Max retries exceeded with url: /latest/meta-data/instance-id (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x75e0b530>, 'Connection to 192.168.2.2 timed out. (connect timeout=50.0)'))]
[15:49] <ogra_> not sure why it wants to do a web request to my firewall
[15:50] <ogra_> seems it also never reaches the login prompt :/
[15:50] <ogra_> it prints that error for 10min now
[15:50] <Chipaca> ogra_: we're talking “ubuntu-device-flash core 15.04 --channel alpha -o 15.04-alpha.img --developer-mode”, yes?
[15:51] <ogra_> Chipaca, for the test ? yeah
[15:51] <ogra_> aha, now webdm started
[15:51] <ogra_> this delay is awful :/
[15:52] <ogra_> ogra@anubis:~/datengrab/rpi$ ssh ubuntu@webdm.local
[15:52] <ogra_> ssh: connect to host webdm.local port 22: Connection refused
[15:52] <ogra_> sigh
[15:56] <ogra_> sergiusens, so there seems to be no sshd running now
[15:57] <ogra_> hmpf
[15:57] <ogra_> and i cant log in on serial console either
[15:57] <sergiusens> ogra_: that's worrisome
[15:57] <ogra_> localhost login: ubuntu
[15:57] <ogra_> Password:
[15:57] <ogra_> Login incorrect
[15:57] <ogra_> thats what i get on serial
[15:58] <sergiusens> ogra_: it's broken here too...
[15:58] <sergiusens> preinstalled webdm that is
[15:58] <ogra_> well, webdm started eventually
[15:58] <ogra_> just took pretty long
[15:58] <ogra_> no login is more worrysome i think
[15:59] <sergiusens> aa_change_onexec failed
[15:59] <sergiusens> Chipaca: ^
[15:59] <sergiusens> do you know?
[15:59] <sergiusens> Chipaca: created with sudo ubuntu-device-flash core 15.04 --channel alpha --install webdm --output amd64-webdm.img
[16:00] <Chipaca> sergiusens: unless something is built against snappy trunk from last week, no
[16:00]  * Chipaca tries installing hello-world
[16:01] <Chipaca> things installed with snappy directly work
[16:01] <Chipaca> now to try webdm
[16:01]  * ogra_ notices that the icons for an installed snap vanish from the webdm UI 
[16:01] <ogra_> (showing the generic icon only)
[16:01] <ogra_> hmm, no
[16:02] <ogra_> snake is fine, only chatroom changes the icon after install
[16:02] <ogra_> so how do i get my login back now :(
[16:02] <ogra_> seems i need some random ssh key ?
[16:03] <ogra_> (since without any ssh key it doesnt seem to work at all)
[16:03] <Chipaca> sergiusens: confirmed, things installed with webdm are missing apparmor
[16:04] <Chipaca> sergiusens: meaning you've built it against snappy trunk
[16:04] <Chipaca> sergiusens: before the mangle branch landed
[16:04] <Chipaca> sergiusens: tut, tut
[16:04] <Chipaca> sergiusens: also, sorry :-/
[16:06] <sergiusens> Chipaca: well, it's u-d-f, not webdm
[16:06] <ogra_> 0.10 is a nicer version number anyway
[16:06] <Chipaca> sergiusens: what is?
[16:06] <sergiusens> Chipaca: I'm not suing snappy trunk for webdm
[16:06] <Chipaca> sergiusens: ah, you get that from the installed webdm?
[16:06] <sergiusens> Chipaca: yes
[16:06] <Chipaca> sergiusens: because i get that from packets installed from webdm
[16:07] <sergiusens> Chipaca: webdm is locked to launchpad.net/snappy    bzr     snappy_tarmac-20150507103214-pgd90adryua6v6wi   444
[16:07] <sergiusens> Chipaca: but this error is from webdm itself
[16:07] <Chipaca> and indeed i see the apparmor files
[16:07] <Chipaca> then why am i getting this error?
[16:07] <Chipaca> wat
[16:08] <Chipaca> ah, it's because i can't read
[16:08] <sergiusens> Chipaca: hmm, no symlinks in /var/lib/apparmor
[16:08] <Chipaca> rsalveti: a reminder that i'm away friday and monday
[16:09] <Chipaca> rsalveti: clearly you won't lose much :-/
[16:09] <sergiusens> rsalveti: we need a new snappy release and a u-d-f rebuild ^
[16:09] <Chipaca> sergiusens: why a snappy release?
[16:09] <sergiusens> Chipaca: u-d-f builds from snappy packages
[16:10] <sergiusens> Chipaca: if the apparmor stuff is broken in lp:snappy, we need a new snappy release to rebuild u-d-f
[16:10] <Chipaca> the error i see is about /tmp being wrong
[16:10] <sergiusens> Chipaca: so core launcher?
[16:10] <Chipaca> sergiusens: the apparmor stuff *was* broken in lp:snappy, but is now fixed
[16:10] <Chipaca> sergiusens: but this is in pre-update alpha channel
[16:10] <sergiusens> Chipaca: don't confuse me
[16:10] <Chipaca> sergiusens: so it's the known one
[16:10] <sergiusens> Chipaca: oh, right!
[16:10] <sergiusens> so confusing :-P
[16:11] <sergiusens> Chipaca: sorry
[16:11] <sergiusens> rollback rsalveti
[16:11]  * sergiusens goes for lunch
[16:11]  * Chipaca can't remember what the old rsalveti looked like
[16:11] <ogra_> more beardy
[16:12] <ogra_> sergiusens, so all is fine ?
[16:14] <ogra_> hmpf
[16:15] <ogra_> so even with a randomly generated key i cant get an ssh login now
[16:16] <ogra_> aha, IP works ... webdm.local doesnt
[16:16] <ogra_> funny, since it works in the browser
[16:17] <ogra_> ************** copying edge over to alpha *NOW* .... ****************
[16:17] <ogra_> you should see a version 3 now
[16:19] <Chipaca> yes
[16:20] <ogra_> happy upgrading then :)'
[16:22] <ogra_> ogra@anubis:~/datengrab/rpi$ ping webdm.local
[16:22] <ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
[16:22] <ogra_> WOAH !
[16:23] <ogra_> seems it is hopping between 254.193.204.33 and 192.168.2.25 ... how can .local ever resolve to a real address ?!?
[16:24] <conyoo> am i doing something wrong?
[16:24] <conyoo> sudo snappy rollback webdm
[16:24] <conyoo> panic: runtime error: invalid memory address or nil pointer dereference
[16:24] <conyoo> [signal 0xb code=0x1 addr=0x20 pc=0x5ca3b1]
[16:27] <ogra_> Jun 10 16:26:52 localhost kernel: [  859.165000] audit: type=1400 audit(1433953612.650:14): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chatroom.ogra_chatroom_0.1-8" pid=2159 comm="apparmor_parser"
[16:27] <conyoo> snappy list -v
[16:27] <ogra_> ERR
[16:27] <conyoo> webdm          2015-06-07 0.8
[16:27] <conyoo> webdm          2015-06-10 0.9        *
[16:27] <ogra_> why is that unconfined ?
[16:28] <Chipaca> conyoo: noice
[16:28] <Chipaca> conyoo: how did you get to that?
[16:29] <Chipaca> conyoo: in answer to your question though, maybe, but the panic is ours to fix
[16:29] <ogra_> well, would be interesting to know what HW that happens on
[16:31] <conyoo> Chipaca, i don't really know what i'm doing :)) i am just playing with snappy but i get this error when trying the rollback command. i was wandering if i'm using it wrong or it's just a bug :))
[16:31] <Chipaca> conyoo: it's a bug. steps to reproduce would be very helpful.
[16:32] <Chipaca> including, as ogra_ says, what hw this is
[16:32]  * rsalveti checking backlog
[16:32] <rsalveti> Chipaca: of course we're going to miss you :-)
[16:32] <rsalveti> Chipaca: but sure, please just add that in your calendar
[16:33] <Chipaca> rsalveti: i mean, because it seems i'm not tracking things properly at this point :-/
[16:33] <rsalveti> sergiusens: hm, still didn't check everything, but why do we need a release?
[16:33] <rsalveti> which bug did we find?
[16:33] <ogra_> rsalveti, an old one ... it was the wrong image
[16:33] <ogra_> (as i understand)
[16:34] <ogra_> (i.e. old stable)
[16:34] <Chipaca> separate issues
[16:34] <Chipaca> as i understood it at least (but see: tracking)
[16:34] <Chipaca> rsalveti: u-d-f is built against a snappy that has a bug
[16:34] <rsalveti> right
[16:34] <Chipaca> rsalveti: fails to do the apparmor hooks
[16:34] <Chipaca> rsalveti: that's u-d-f trunk (tools ppa?)
[16:35] <Chipaca> confirm with sergiusens tho
[16:35] <rsalveti> Chipaca: yeah, tools ppa and wily archive
[16:35] <conyoo> Chipaca, i just installed snappy with KVM using this tutorial https://developer.ubuntu.com/en/snappy/start/ and then sudo snappy install webdm sudo snappy update sudo snappy rollback webdm (i have the image installed since last week maybe, so i had webdm 0.7? 0.8 and now 0.9)
[16:35] <Chipaca> ahhhh
[16:35] <Chipaca> conyoo: could you confirm that after 'sudo snappy update' you have two webdms in the output of 'snappy list'?
[16:36] <Chipaca> one with .sideload, one without
[16:36] <ogra_> Chipaca, see above
 webdm          2015-06-07 0.8
 webdm          2015-06-10 0.9        *
[16:36] <conyoo> Chipaca, yep snappy list -v
[16:36] <conyoo> Name           Date       Version    Developer
[16:36] <conyoo> ubuntu-core    2015-04-23 2          ubuntu*
[16:36] <conyoo> config-example 2015-05-16 1.0.6      canonical*
[16:36] <conyoo> mc             2015-06-09 3-4.8.13-3 sideload*
[16:36] <conyoo> snake          2015-05-29 0.0.5      mectors*
[16:36] <conyoo> webdm          2015-06-07 0.8
[16:36] <conyoo> webdm          2015-06-10 0.9        *
[16:36] <conyoo> generic-amd64  2015-04-23 1.1
[16:36] <conyoo> generic-amd64  2015-05-10 1.1.1      *
[16:37] <Chipaca> conyoo: no, without -v
[16:38] <conyoo> Chipaca, snappy list
[16:38] <conyoo> Name           Date       Version    Developer
[16:38] <conyoo> ubuntu-core    2015-04-23 2          ubuntu
[16:38] <conyoo> config-example 2015-05-16 1.0.6      canonical
[16:38] <conyoo> mc             2015-06-09 3-4.8.13-3 sideload
[16:38] <conyoo> snake          2015-05-29 0.0.5      mectors
[16:38] <conyoo> webdm          2015-06-10 0.9
[16:38] <conyoo> generic-amd64  2015-05-10 1.1.1
[16:38] <Chipaca> hmm
[16:41] <elopio> sergiusens: what do you mean with selftest stuff? mvo wrote some things on the README.
[16:41] <elopio> are you after something more than that?
[16:42] <elopio> dpm: should I ask davidcalle for reviews on the docs, or anybody from the community team?
[16:42] <elopio> or maybe just wait for somebody to go through the docs in draft.
[16:44] <slangasek> seb128: we just need to agree a name for the channel
[16:46] <rsalveti> ogra_: sergiusens: Chipaca: I'm still confused if we need to rebuild udf or not (and if that will affect the image)
[16:46] <rsalveti> (sorry, also in a call)
[16:49] <rsalveti> ogra_: did you find out why you had the ssh/login/cloud-init issues?
[16:49] <ogra_> rsalveti, well, it seems unhappy with no key at all
[16:49] <ogra_> rsalveti, i generated a fake key and it works now
[16:50] <rsalveti> hm, alright
[16:50] <ogra_> i also added the promotion info to http://snappy.asac.ws:9001/p/promotion for the moment
[16:50] <ogra_> (i guess we need some proper place for that later)
[16:51] <rsalveti> ogra_: awesome
[16:51] <rsalveti> yeah, I can move things around
[16:52] <elopio> zyga_: could we use checkbox to record all the inputs and outputs to the terminal?
[16:52] <dpm> elopio, primarily davidcalle, but feel free to ask myself of dholbach too
[16:52]  * ogra_ goes downstairs, dont try to catch me on the other server :)
[16:54] <conyoo> Chipaca, and after that error, webdm stops working even if i restart. the only way to recover is to remove webdm and reinstall
[17:05] <zyga_> elopio: outputs, yes, inputs no (but it's easy if you'd really want to)
[17:05] <zyga_> elopio: we don't give you a pty though
[17:05] <zyga_> elopio: but it's all doable
[17:06] <zyga_> elopio: and as a bonus, we record timings
[17:06] <zyga_> elopio: so you can replay a session as it happened
[17:06] <zyga_> elopio: with realistic timings between events
[17:06] <elopio> zyga_: I'm not sure if I really want to. Just thinking here.
[17:06] <zyga_> elopio: what are you trying to build/achieve?
[17:06] <elopio> zyga_: it might be nice a snap that records an exploratory testing session.
[17:07] <zyga_> elopio: for that, I'd use off-the-shelf asci/terminal recorders
[17:07] <zyga_> elopio: though if you want to automate that :)
[17:07] <zyga_> elopio: or to let devs see replays of each test
[17:07] <zyga_> elopio: plainbox can help you with that
[17:08] <plars> anyone have issues trying to use snappy-remote on a device rather than over qemu? with an rpi I'm getting 'ssh: could not resolve hostname : Name or service not known", but there's not a lot of context for the error... I've even tried setting up my key in authorized_keys on the device.
[17:09] <ogra_> plars, what rpi image is that ?
[17:09] <elopio> zyga_: I might also want the thing to suggest areas to test. Not quite sure about this either.
[17:09] <plars> ogra_: it's the one from you :)
[17:09] <elopio> zyga_: just ideas. Do you know a good recorder I can try?
[17:09] <plars> ogra_: from http://people.canonical.com/~ogra/snappy/raspberrypi2/
[17:09] <zyga_> plars: does ssh over the raw ip work?
[17:09] <plars> zyga_: yes
[17:09] <ogra_> plars, well, that was initially generated using my ssh key ... send me the snap and i can install it for you :P
[17:09] <zyga_> elopio: I used a few in the past
[17:09] <zyga_> elopio: though I don't know if they're foss
[17:09]  * zyga_ looks
[17:10] <plars> ogra_: it's not enough to just add my key?
[17:10] <zyga_> elopio: https://asciinema.org/
[17:10] <ogra_> plars, the next image is generated with a fake key ... (but that will likely not fix this issue)
[17:10] <zyga_> elopio: (random google)
[17:11] <ogra_> plars, yeah, you should be able to put your key in place and use the --pub-key option for snappy-remote i guess
[17:11] <plars> ogra_: I still get that error even with --pub-key
[17:12] <plars> ogra_: I also tried giving it a hostname, because the default seems to be "localhost"
[17:12] <plars> still no luck
[17:12] <elopio> https://github.com/cortezcristian/terminal-recorder
[17:12] <elopio> this looks shiny :)
[17:13] <zyga_> 	snappy-remote --url=ssh://$(deploy_target) install ./$(snap_pkg)
[17:13] <zyga_> plars: ^^ that's how I deploy my snap
[17:13] <plars> zyga_: that's exactly what I'm doing
[17:14] <zyga_> plars: I can also ssh to bb1.lan directly
[17:14] <zyga_> plars: (ssh config is setup)
[17:14]  * zyga_ wonders if he has two irssi sessions :P
[17:14] <zyga_> hmm
[17:14] <zyga_> no?
[17:14] <ogra_> plars, http://paste.ubuntu.com/11691282/
[17:15] <zyga_> odd
[17:15] <ogra_> plars, use ubuntu@ ..
[17:16] <ogra_> hmpf
[17:16] <plars> ogra_: yes, tried that too... I wish I knew where it was trying to look up a hostname and which hostname it was trying to look up
[17:16] <ogra_> ogra@styx:~$ ping webdm.local
[17:16] <ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
[17:16] <ogra_> hmpf
[17:16] <ogra_> i really dont get how it can return such an IP
[17:20] <ogra_> plars, well, it definitely works for me using the IP and ubuntu@
[17:21] <plars> ogra_: ok, I'll keep messing with it. I really wish snappy-remote had a --please-give-me-a-useful-error-message flag though
[17:21] <ogra_> lol, yeah
[17:48] <ogra_> sergiusens, hmm, while i have the open/manage button in webdm now, the description is still the wrong one
[17:48] <sergiusens> ogra_: well the description is the one from the package, not the store; they are supposed to be unique
[17:48] <sergiusens> once installed that is
[17:48] <ogra_> from where in the package ? it doesnt come from readme.md it seems
[17:49] <sergiusens> ogra_: is tis ogra's chatroom one?
[17:49] <ogra_> yeah
[17:49] <ogra_> the icon is also broken :/
[17:49] <ogra_> there are related errors in syslog for the icon though
[17:49] <ogra_> (that might be my fault)
[17:50] <sergiusens> ogra_: did you push the edge to alpha already?
[17:50] <ogra_> sergiusens, yep
[17:50] <sergiusens> ogra_: neat, revno 3, right?
[17:51] <ogra_> yeah
[17:51] <sergiusens> ogra_: autopilot worked at least :-)
[17:51] <ogra_> btw, i think promoting from alpha to stable might not be clever ... it might result in a different delta ... i'll do the final promotion from edge
[17:53] <sergiusens> ogra_: I guess that's fine, not sure why the delta would be different though
[17:53] <ogra_> yeah,. me neither ... just a gut feeling
[17:55] <rsalveti> ogra_: sergiusens: so how is alpha looking? it seems to work fine here at my kvm image
[17:55] <rsalveti> what else do we need to do before promoting it to stable?
[17:55] <ogra_> nothing i guess
[17:56] <ogra_> i'd like to hear feedback for a BBB from someone though
[17:56] <ogra_> elopio, ^^ ?
[17:56] <rsalveti> yeah, elopio, can you give us a hand with that?
[17:56] <rsalveti> I'm still waiting for mine
[17:57]  * ogra_ wonders if we have any avahi specialist in the company ... 
[17:57] <ogra_> i'm really confused that webdm.local for me resolves to some public address
[17:57] <ogra_> that shouoldnt be possible
[17:57] <elopio> ogra_: let me flash it.
[17:58] <ogra_> elopio, flash #2 ... we want to test the upgrade (which is why i held back #3 for 1h)
[17:58] <ogra_> (in the alpha channel)
[17:58] <elopio> sudo ubuntu-device-flash --revision=2 --verbose core --output=snappy.img --developer-mode --channel=alpha 15.04 --oem=beagleblack
[17:59] <elopio> ogra_: looks good? ^
[17:59] <ogra_> pitti, hey, you know stuff about avahi, right ?
[17:59] <ogra_> elopio, yeahm that looks fine
[17:59] <ogra_> autopilot should offer you an upgrade relatively quick
[18:01] <sergiusens> ogra_: what's wrong with avahi?
[18:02] <ogra_> ogra@styx:~$ ping webdm.local
[18:02] <ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
[18:02] <ogra_> sergiusens, ^^
[18:02] <sergiusens> ogra_: is that your IP?
[18:02] <ogra_> (the device has 192.168.2.25 ... )
[18:02] <ogra_> sergiusens, the external one ? hmm
[18:02] <sergiusens> ogra_: are there more interfaces?
[18:03] <ogra_> my external one is 79.223.149.242
[18:03] <sergiusens> ogra_: I'm trying to nail down a possible bug report ;-)
[18:03] <ogra_> no, there shouldnt be any other interfaces
[18:03] <ogra_> sometimes i actually get the right IP
[18:04] <sergiusens> ogra_: anything in sudo journalctl --no-pager -u webdm_snappyd_0.9.service |pastebinit.mvo
[18:04] <rsalveti> that's super weird
[18:04] <ogra_> and webdm.local works well in the browser
[18:04] <rsalveti> try tracing the routing tables
[18:04] <sergiusens> ogra_: more than one device?
[18:04] <ogra_> well, i suspect rather my network than the webdm install
[18:04] <ogra_> sergiusens, not that i know of
[18:04] <rsalveti> maybe your isp router is also called webdm :P
[18:04] <ogra_> only the Pi should run
[18:05] <rsalveti> is the store that slow for you guys as well?
[18:05] <rsalveti> hard for me to get more than 40kb/s
[18:05] <rsalveti> unless kvm is doing something
[18:06] <ogra_> sergiusens, http://paste.ubuntu.com/11691505/
[18:07] <ogra_> installing pastebinit was pretty fast for me just now
[18:07] <ogra_> Installing pastebinit.mvo
[18:07] <ogra_> Starting download of pastebinit.mvo
[18:07] <ogra_> 52.57 KB / 52.57 KB [[18:07] <ogra_> Done
[18:10] <sergiusens> rsalveti: I switched to slower network this weekend and it is a bit slower, but not too slow
[18:10] <rsalveti> might be my network
[18:10] <rsalveti> sergiusens: no fiber anymore?
[18:10] <sergiusens> rsalveti: ah, store is slow 45.58 KB/s
[18:10] <sergiusens> rsalveti: vdsl
[18:10] <rsalveti> right, that's what I'm getting
[18:11] <ogra_> must be your continent :)
[18:11] <rsalveti> probably
[18:11] <sergiusens> rsalveti: I have fibertel (fiber) which is unplugged now; hired to services to deal with outages
[18:11] <rsalveti> where is the server located?
[18:11] <rsalveti> would guess europe as well
[18:11] <ogra_> london ?
[18:11] <rsalveti> sergiusens: got it
[18:12] <rsalveti> ogra_: there is a pi2 snap from lool, do you know what that is?
[18:13] <ogra_> rsalveti, his first try i guess
[18:13] <ogra_> i'll have to find out how to replace that
[18:13] <sergiusens> ogra_: I don't see anything strange in the paste; except maybe ::1 is not a good idea
[18:13] <ogra_> (since it is namespaced)
[18:14] <rsalveti> ogra_: right, yeah, it's just showing as an app snap it seems
[18:14] <ogra_> sergiusens, well, only if you use v6
[18:14] <ogra_> a simple ping on cmdline should only use v4
[18:14] <rsalveti>  ERROR: pi2.lool failed to install: package name with namespace not supported
[18:14] <rsalveti> :-)
[18:14] <ogra_> yeah
[18:15] <rsalveti> lool: ^^
[18:15] <sergiusens> ogra_: that is localhost, so if anyone gets it they get the wrong thing :P
[18:15] <sergiusens> rsalveti: lool's package should be wiped
[18:15] <ogra_> sergiusens, sure, but that shouldnt cause such weird behavior
[18:15] <sergiusens> ogra_: no, not the one you see
[18:15] <rsalveti> sergiusens: who can do that besides lool ?
[18:15] <ogra_> the store-master :)
[18:15] <ogra_> zuul :)
[18:16] <sergiusens> rsalveti: you see that in the store?
[18:16] <rsalveti> guess beuno then
[18:16] <sergiusens> beuno: it is
[18:16] <rsalveti> sergiusens: webdm
[18:16] <ogra_> it is in the store, yes
[18:16] <sergiusens> either that or create an alias
[18:16] <sergiusens> but the alias of pi2 is not easily taken ;-)
[18:17] <beuno> wut wut?
[18:17] <ogra_> all your fault !
[18:17]  * beuno throws gasoline everyone
[18:17] <beuno> you won't be able to prove it
[18:17] <ogra_> :)
[18:18] <ogra_> beuno, we want to get rid of the pi2 package from the store
[18:18] <beuno> I can do that
[18:18] <beuno> do you just want the alias, or to kill the app all together?
[18:19] <ogra_> i guess kill it for now ... not sure it should be in the store at all (you need a device tarball anyway atm)
[18:19] <ogra_> rsalveti, ^^^?
[18:19] <sergiusens> unpublish or untick 15.04-core and rolling-core ;-)
[18:21] <rsalveti> ogra_: beuno: yeah, just kill it
[18:21] <beuno> sergiusens, ogra_, rsalveti, unpublished
[18:22] <ogra_> yay
[18:22] <mvo> last minute issues?
[18:22] <rsalveti> beuno: thanks
[18:22] <rsalveti> now I guess you can publish the rpi2 oem
[18:22] <rsalveti> mvo: nops, just waiting elopio to validate the bbb image
[18:22] <beuno> tips not included
[18:22] <rsalveti> with the alpha channel
[18:24] <mvo> aha, cool
[18:26] <sergiusens> Chipaca: mvo rsalveti I grabbed latest image, built with "sudo ubuntu-device-flash core 15.04 --channel alpha --install webdm --output amd64-webdm.img"
[18:26] <sergiusens> and I see webdm not being able to launch due to aa_change_onexec -> no such file or directory
[18:27] <ogra_> weird, works for me on the RPi
[18:27] <rsalveti> works fine after installing webdm, guess the problem is with the sideload part then?
[18:27] <sergiusens> ogra_: I'm on trusty
[18:27] <rsalveti> let me try reproducing that
[18:27] <ogra_> sergiusens, me too
[18:27] <rsalveti> ogra_: are you using the tools ppa?
[18:27] <rsalveti> and did you update to the latest udf?
[18:27]  * sergiusens is on the tools ppa
[18:29] <ogra_> 0.21-1+173~ubuntu15.04.1build1 ...
[18:29] <rsalveti> ogra_: yeah, not the one from the tools ppa
[18:29] <rsalveti> which is why it might be working for you
[18:29] <sergiusens> I think we need to release the latest ubuntu-snappy into wily and rebuild u-d-f with that...
[18:29] <ogra_> yeah, outdated .. apt-cache policy says 0.23-0ubuntu1 is the candidate
[18:30] <rsalveti> sergiusens: is fix already in trunk?
[18:30] <rsalveti> if so I can release and upload
[18:30] <sergiusens> rsalveti: if you can reproduce
[18:30] <rsalveti> yeah, trying
[18:30] <sergiusens> rsalveti: well Chipaca implied that earlier, but I was confused with the alpha thing
[18:30] <rsalveti> alright, was able to at least create the image with --instlal now
[18:31] <rsalveti> sergiusens: Jun 10 18:30:42 localhost systemd[1]: webdm_snappyd_0.9.service: main process exited, code=exited, status=1/FAILURE
[18:31] <rsalveti> where can I get the logs for webdm?
[18:32]  * sergiusens runs /lastlog journal
[18:32] <sergiusens> rsalveti:  sudo journalctl --no-pager -u webdm_snappyd_0.9.service
[18:32] <rsalveti> Jun 10 18:30:42 localhost.localdomain ubuntu-core-launcher[834]: aa_change_onexec failed with -1
[18:32] <rsalveti> Jun 10 18:30:42 localhost.localdomain ubuntu-core-launcher[834]: . errmsg: No such file or directory
[18:32] <sergiusens> yeah, same
[18:33] <sergiusens> rsalveti: let me locally build u-d-f here with the latest snappy
[18:33] <rsalveti> sergiusens: great
[18:33] <rsalveti> if that works we can just upload and do the release dance
[18:34] <ogra_> hmm, i guess i need to re-gen the Pi image then
[18:35] <elopio> how can I reduce the timer for the autopilot? I don't want to wait 25 minutes.
[18:37] <sergiusens> elopio: edit the systemd job and refresh
[18:41] <elopio> sergiusens: but then I would have to make the partition writable. Shouldn't it be possible to configure it?
[18:41] <davidcalle> elopio, hey, it was longer than expected :) Any issues with the edit?
[18:42] <sergiusens> elopio: making it configurable wasn't a requirement
[18:42] <elopio> davidcalle: no. I just updated the version number in https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam
[18:42] <elopio> could you please review it?
[18:43] <davidcalle> elopio, sure
[18:43] <elopio> sergiusens: it's a requirement for automation. But we can discuss about it if/when we write end-to-end tests for autopilot.
[18:46] <davidcalle> elopio, at first glance, I only see 1.0.1 -> 1.0.2 changes, that's right?
[18:47] <sergiusens> rsalveti: please release the latest ubuntu-snappy :-D
[18:49] <rsalveti> sergiusens: alright, all good then?
[18:49] <davidcalle> elopio, in any case, I don't see any issues, feel free to push the publish button :)
[18:50] <elopio> davidcalle: that's right. I thought I couldn't push the publish button myself...
[18:50] <davidcalle> elopio :)
[18:50] <davidcalle> elopio, you have my permission :p
[18:51] <elopio> davidcalle: I hate it that you can't search on the editor.
[18:51] <elopio> oh, you can. Scratch that.
[18:51] <elopio> I just had to move to the source view.
[18:52] <sergiusens> rsalveti: yeah
[18:53] <davidcalle> elopio, the wysiwyg editor itself is... ok-ish, I tend not to use it
[18:59] <slangasek> seb128: the channel name that sergiusens proposed on the list was ubuntu-personal/rolling/edge.  This looks reasonable to me from the server side; but who should ack the name product-wise? willcooke?
[19:16]  * mvo added a is dd target already mounted sanity check to godd and calls it a day
[19:21] <lool> rsalveti: yeah, that's one of the things that needs to be changed while rebuilding: dropping the namespace; actually snappy should support them in 15.10 eventually, but in 15.04 it didn't
[19:21] <lool> sergiusens: shall I unpublish my package or something?
[19:22] <rsalveti> lool: already removed by the store master
[19:22] <lool> eh
[19:28] <rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.1.1-0ubuntu1
[19:28] <rsalveti> will do another upload for udf once it gets published in proposed
[19:29] <rsalveti> and powerpc is indeed fine again it seems
[19:32] <sergiusens> yup
[19:39] <elopio> ogra_: I'm in alpha #3. Do you want me to check something special in here?
[19:41] <ogra_> elopio, if the upgrade worked we're all fine
[19:43] <rsalveti> elopio: if nothing exploded it is already a good sign
[19:43] <elopio> rsalveti: I only explode things on tuesdays.
[19:45] <rsalveti> sergiusens: it seems you forgot to push the release tag/commit for goget-ubuntu-touch
[19:45] <rsalveti> guess just needs to change from UNRELEASED to wily and then call debcommit -r
[19:46] <rsalveti> sergiusens: I can do that now
[19:46] <sergiusens> rsalveti: hmm, sure, thanks
[20:04] <tedg> mterry, Okay, I've got one. What about devpacks that include the same dependencies?
[20:04] <tedg> mterry, Like for instance a Ubuntu SDK devpack would include Qt, but potentially there could be a Qt Devpack. What if the build.yaml specified both.
[20:04] <tedg> ?
[20:05] <mterry> tedg, ok...
[20:05] <tedg> And, worse case, what if they have different versions of Qt in them.
[20:05] <mterry> tedg, so devpacks need some smarts, right?  to detect if they've already installed a dependency before
[20:05] <mterry> tedg, if they are keeping Qt in the same place, they may notice that they don't have to do anything
[20:05] <mterry> tedg, if they aren't, we have two copies of Qt
[20:06] <mterry> Although one could compile it differently from the other, even if they install in same place
[20:06] <tedg> mterry, I guess this might be enough of an edge case that we let the developer handle it.
[20:06] <tedg> Yeah, for instance they might be the same version, but with a small patch.
[20:06] <mterry> tedg, I'm leery of crafting an enormous dependency resolution system
[20:06] <tedg> Me too
[20:07] <tedg> Perhaps it just generates an error.
[20:07] <tedg> "Can't install libraries: file conflicts"
[20:08] <mterry> tedg, and we'd detect that?
[20:09] <tedg> mterry, No the devpack itself would
[20:09] <mterry> tedg, but how would it know it was another devpack that installed it, vs just a previous install of Qt that it did
[20:09] <tedg> mterry, It wouldn't, and we wouldn't, we'd just have to generate an error that we can't copy the file(s).
[20:10] <mterry> tedg, but we want to allow using dirty build envs (where the devpack has previously installed qt).  Otherwise every time you build, you have to freshly install qt
[20:10] <tedg> mterry, I don't think we can track which files in the buildenv go to which devpack.
[20:10] <mterry> tedg, so the devpack has to be tolerant if Qt is already there, it wouldn't know it was from another devpack necessarily
[20:11] <tedg> I guess it could *assume* as it's unlikely to be anything other than another devpack putting it there :-)
[20:11] <tedg> But it certainly wouldn't know which one.
[20:11] <mterry> tedg, or have best practices for devpacks to install Qt under a namespace
[20:11] <mterry> tedg, but then if two want to install it, it gets done twice
[20:12] <mterry> tedg, but in either case, we couldn't say something like "Can't install libraries: file conflicts"
[20:12] <tedg> Yeah, okay. Crazy idea: what if we generated a hashes.yaml after every devpack operation. Then we *could* track who the owner of the file was, and could make the error better.
[20:13] <tedg> We'd have to hash the entire buildenv each time to see if the files changed.
[20:13] <tedg> On the scale of: eating Nutella to volcano surfing, how crazy is that?
[20:14] <mterry> tedg, or have devpacks be able to resolve dependencies via other devpacks (or at least the core devpack?)  -- i.e the Ubuntu SDK would say "tell the core devpack to install Qt" and a Python module that needs Qt would do same thing?
[20:14] <mterry> tedg, wouldn't solve all problems...  but most?
[20:15] <mterry> tedg, I guess I don't know if the core devpack would be able to receive a "install Qt" command
[20:15] <mterry> that seems complicated
[20:15] <tedg> Yeah, it seems like we start building a dependency system. It would be nice if devpacks had the same ethos as the rest of snappy.
[20:15] <tedg> So they're basically bundling everything they need.
[20:15] <mterry> tedg, right, monolithic
[20:16] <mterry> tedg, which makes me think that each devpack would install its own namespaced version of Qt
[20:16] <mterry> (if there were two Qt devpacks)
[20:16] <tedg> Yeah, I think that makes sense. You could in theory want that, perhaps not for Qt, but something like OpenSSL.
[20:18] <tedg> Then it becomes critical for devpacks to be able to modify the runtime environment to do things like ensuring their version ends up in the LD_LIBRARY_PATH
[20:19] <tedg> I don't think we want each devpack adding its own shell wrapper :-)
[20:28] <rsalveti> the problem with dependencies is that the makes everything harder when reproducing the builds
[20:28] <rsalveti> and handling such conflicts
[20:28] <rsalveti> because it becomes a combination of things
[20:28] <rsalveti> maybe we could have a qt devpack, but the ubuntu one whould ship its own qt as part of it
[20:29] <rsalveti> guess we can just try some smarter thing to identify possible conflicts
[20:36] <tedg> Yeah, curious if we couldn't deduplicate there. Like notice that I'm hardlinking all the same file.
[20:40] <rsalveti> build env size is cheap right?
[20:40] <rsalveti> guess the major issue is understanding what the linker/compiler will use
[20:44] <tedg> Yeah, and if it tries to link two versions of the *almost* same lib bad things may happen.
[20:44] <tedg> Not sure it's a problem we can solve for folks though.
[20:44] <tedg> (without building a full dependency system)
[20:47] <ogra_> rsalveti, i'll go afk now, leave me a note about the promotion and i'll do it tomorrow morning (if nobody does it at night)
[20:48] <rsalveti> ogra_: I'll try to do in a few
[20:48] <rsalveti> ogra_: your notes should be good I guess
[20:48] <rsalveti> let me quickly check
[20:48] <ogra_> i didnt add the actual promotion like ... you should copy from edge to stable in the last step
[20:49] <rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/edge generic_amd64 82
[20:49] <rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/edge generic_armhf 82
[20:49] <rsalveti> ogra_: right?
[20:49] <rsalveti> ops
[20:49] <ogra_> heh
[20:49] <ogra_> close :)
[20:49] <rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/stable generic_amd64 82
[20:49] <rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/stable generic_armhf 82
[20:49] <ogra_> yeah
[20:49] <rsalveti> ogra_: what is the -k?
[20:49] <ogra_> i thought you'd build a new one
[20:49] <ogra_> -k means "keep the version number"
[20:50] <rsalveti> yeah, then this should be good
[20:50] <rsalveti> ogra_: we're just waiting udf to publish
[20:50] <ogra_> i wanted the initial version for the upgrade test to be identical to whats in stable
[20:50] <rsalveti> the image should still be good
[20:50] <rsalveti> got it, cool
[20:50] <ogra_> so i kept the 2
[20:50] <rsalveti> then yeah, should have everything under control
[20:50] <rsalveti> ogra_: thanks so much
[20:50] <ogra_> cool
[20:50] <rsalveti> enjoy :-)
[20:50] <ogra_> pfft, i didnt do anything
[20:51] <ogra_> (and just saw an awful football game :P )
[20:51] <ogra_> (GER - USA ... 1:2 )
[20:58] <rsalveti> oh, usa got a strong team this year as well
[20:58] <rsalveti> we won yesterday
[21:40] <rsalveti> sergiusens: elopio: ogra_: I think we're good to go, new tools available at https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
[21:40] <rsalveti> created an image with --install=webdm and worked fine
[21:41] <rsalveti> will brb, but I guess we can finally release it
[22:06] <bladernr_> Hey, where should I file bugs about the snappy docs at developer.ubuntu.com?
[22:07] <bladernr_> https://developer.ubuntu.com/en/snappy/tutorials/using-snappy/ specifically, snappy list results in an error as the snappy command doesn't support list
[22:07] <bladernr_> http://pastebin.ubuntu.com/11692654/
[22:19] <bladernr_> when someone gets around: https://bugs.launchpad.net/snappy/+bug/1464021
[23:20] <elopio> bladernr_: hum, snappy list works for me.
[23:21] <elopio> what version are you using?
[23:22] <elopio> I suppose it's an old one, because when I do snappy versions it tells me it's deprecated and I should use list.