[00:05] <a__> hi
[00:07] <a__> the snappy guide starts off with the command snappy info, but in fact I get a login prompt - what is the username/password?
[06:44] <didrocks> good morning!
[08:07] <dholbach> good morning
[08:08] <didrocks> hey dholbach!
[08:09] <dholbach> salut didrocks
[08:10] <dholbach> didrocks, shall we talk tomorrow at 10:30 or 11?
[08:10] <dholbach> not sure if we'll require thibautr, but we could invite him too
[08:12] <didrocks> dholbach: not possible to have one catching up discussion today even?
[08:12] <zyga> good morning :)
[08:12] <didrocks> the earlier, the better ;)
[08:12] <didrocks> hey zyga
[08:12] <dholbach> oh sure... maybe in the afternoon?
[08:12] <didrocks> dholbach: good to me, pick a time
[08:12] <dholbach> 16:30 or something?
[08:13] <didrocks> dholbach: hum, I have to leave at 17:15 today
[08:13] <didrocks> so that's not going to work I'm afraid :p
[08:13] <dholbach> ok, that should work - we'll make it quick then ;-)
[08:13] <dholbach> oh?
[08:13] <dholbach> can't we talk for 30m?
[08:13] <didrocks> dholbach: hum, I would prefer that we schedule it before, so that I don't have rush of last minutes email before leaving tonight
[08:13] <dholbach> 15:30 - 16:00 then?
[08:13] <didrocks> wfm!
[08:13] <didrocks> will david c. be around?
[08:14] <didrocks> (to show up what he worked on if he has anything already?)
[08:14] <dholbach> I don't know
[08:14] <didrocks> but you know about the progress, right?
[08:14] <dholbach> I thought we'd also talk about the "getting feedback" bit I mentioned in my mail
[08:14] <dholbach> I know what I worked on
[08:15] <didrocks> dholbach: I got feedback from most of managements (olli, rick…) at mwc
[08:16] <dholbach> right...
[08:50] <ysionneau> morning!
[09:13] <noizer> Good morning
[10:03] <noizer> Hi guys, I have a question about skills
[10:03] <noizer> can i make my own custom skill
[10:04] <noizer> The skill just need to execute the wrapper executables of an other snap
[10:17] <noizer> Is someone active on the last day of februari xD
[10:19] <zyga> thanks mvo  :)
[10:19] <zyga> noizer: not directly, you'd have to discuss this and propose a pull request to snappy
[10:19] <zyga> noizer: and I suspect that running an exec from one snap from another snap is a no-go
[10:20] <zyga> noizer: perhaps if you tell us what the goal is, we can suggest an alternative
[10:20] <mvo> zyga: yw!
[10:20] <zyga> noizer: and FYI, today skills are called interfaces :)
[10:20] <noizer> hahah right xD
[10:21] <zyga> mvo: can I do something to help land https://github.com/ubuntu-core/snappy/pull/518
[10:21] <noizer> zyga I will make something how i can explain my problem to you
[10:21] <zyga> mvo: ?
[10:21] <zyga> noizer: note that you can prototype a new interface in isolation, but you won't be able to use it in snaps that go into the store really
[10:21] <zyga> noizer: so the earlier you know what you need the easier the road ahead is
[10:23] <noizer> zyga I know what i want just i will make a quick draw on my whiteboard en explain it to you
[10:24] <mvo> zyga: if it looks good I think the next step is to update all the integration test packages and rerun the integration test suite. it seems jenkins is a bit unhappy today so maybe not the best time? I would really like to land this only if jenkins is green
[10:24] <mvo> zyga: maybe you can check if https://github.com/mvo5/snappy/commit/806756730b1a04ace671aea202fb0c8517b46131 is ok?
[10:25] <mvo> zyga: no more git grep -i skill so we should be good in the branch :)
[10:25] <zyga> mvo: sure, understood
[10:26] <zyga> mvo: as for jenkins, let's see what happens next, if all else fails we can run integration tests locally
[10:30]  * zyga pushed https://github.com/ubuntu-core/snappy/pull/546
[10:31] <noizer> zyga http://imgur.com/orqlhRD. Here you got a easy drawing how it needs to work. In the middle there is a main snap. This snap needs to controll all installed snaps. So he needs to start stop other snaps. So an very easy interface for users
[10:31] <noizer> But is would be easy that i can call the wrapper out of my own main snap
[10:32] <zyga> noizer: so you _can_ run other apps
[10:32] <zyga> noizer: in the same snap
[10:33] <zyga> noizer: you don't need interfaces for that
[10:33] <zyga> noizer: I would just suggest to call the raw executables, not the snappy-generated wrappers
[10:33] <zyga> noizer: try that
[10:33] <noizer> is that possible?
[10:33] <zyga> noizer: yes
[10:33] <noizer> hmmm that should be nicee
[10:34] <zyga> mvo: offtopic, upstream merged go-flags patch
[10:34] <zyga> mvo: it's low priority but if I prepare the debian patch, will you sponsor this for me?
[10:34] <noizer> but is it not a little bit better to call the wrapper?
[10:35] <zyga> noizer: no
[10:35] <zyga> noizer: in fact you cannot do that
[10:35] <noizer> zyga ok xD
[10:35] <mvo> zyga: I wonder if we should just push a new upstream release maybe? how much else did change?
[10:35] <noizer> zyga thx
[10:35] <zyga> noizer: the wrapper translates unconfined and vanilla environment to the confined snappy environment
[10:35] <mvo> zyga: last release in xenial is 20160218
[10:36] <zyga> mvo: thanks, I was about to complain about lack of tags upstream
[10:37] <ogra_> mvo, can we sync the version numbers among the arches ? i have actually a script i could run by cron (as interim) that could convert the tarballs daily
[10:38] <ogra_> but with that we end up with the same version string across all snaps (which is probably wanted anyway, but currently the store has massively varyimg versions for ubuntu-core)
[10:38] <mvo> ogra_: yeah, I like that
[10:43] <zyga> mvo: not much: http://paste.ubuntu.com/15242051/
[10:43] <zyga> mvo: (it took me forever to compute that, failing at the github ui first)
[10:44] <mvo> zyga: that looks like a new upstream is the simplest option
[10:44] <zyga> mvo: there's my patch and a trivial fix
[10:51] <mvo> so lets do this route
[11:02] <zyga> Chipaca: http://paste.ubuntu.com/15242182/
[11:03] <zyga> Chipaca: some commands use 3rd person objective while some commands use imperative mode
[11:03] <zyga> Chipaca: what's the mode we want?
[11:07]  * zyga pushed https://github.com/ubuntu-core/snappy/pull/547
[11:38] <sergiusens> zyga, mvo has the interfaces work landed into an image?
[11:43] <mvo> sergiusens: not yet, there is a branch for this but its not in yet, but almost
[11:43] <zyga> sergiusens: some, most notably old-security is still not merged
[11:43] <zyga> sergiusens: I suspect it will be all in today
[11:43] <sergiusens> zyga, mvo thanks; I'll keep track of https://bugs.launchpad.net/snapcraft/+bug/1549427
[11:44] <sergiusens> so please update when it makes it
[11:46] <zyga> sergiusens: I saw that, I'va ssigned part to myself
[12:32] <kyrofa> Good morning
[12:34] <noizer> Good morning xD
[12:35] <ogra_> moaning ...
[12:38] <kyrofa> ogra_, not a good morning?
[12:38] <ogra_> kyrofa, lots of mail from last week to wade through ... the curse of having been at a conference
[12:39] <kyrofa> ogra_, oh brutal, yeah I bet
[12:39] <ogra_> (742 MPs in my "merges" mail folder ... 1200 in "bugs" etc etc ... )
[12:39] <kyrofa> ogra_, hey, quick question-- I just flashed the dragon image onto an SD card, but when I boot the lights just remain solid and nothing happens. I was about to connect the serial board to see if it's complaining about anything, but have you seen that?
[12:39] <kyrofa> Yikes
[12:40] <ogra_> kyrofa, hmm, did you use the very latest of my images ?
[12:40] <ogra_> there was an issue with the board when no serial board was attached, that was worked around in the latest image
[12:41] <kyrofa> ogra_, dragonboard-rolling-edge-251.img.xz ?
[12:41] <ogra_> (and will be actually fixed with the next u-boot (thanks ppisati btw !!!) )
[12:41] <ogra_> kyrofa, oooh, no, thats ancient
[12:41] <kyrofa> ogra_, that might be the issue :P
[12:41] <ogra_> and my other one was moved away prior to the dragon announcement
[12:42] <kyrofa> ogra_, no longer here then? http://people.canonical.com/~ogra/snappy/dragonboard/
[12:42] <ogra_> i wonder if i can put it back ... sadly olli is off so i cant ask him for permission
[13:22] <ogra_> mvo, what happened to the branding of the shell prompt that we had in the 15.04 images, is that gone for good or just missing yet in all-snaps
[13:23]  * ogra_ finds it hard to actually know which board he is working on now that all of them say "ubuntu@localhost" ... with a handfull of boards runnning and a ssh terminal open on each it gets quite confusing
[13:25] <mvo> ogra_: stevebiscuit was working on the branding part recently but let me double check about the shell branding
[13:27] <ogra_> it is indeed only an issue if you run multiple different boards ... so perhaps not that important
[13:35] <noizer> zyga I tried it now to call an executable from an other snap but it doesn't work
[13:36] <mvo> ogra_: uploaded a fix, will be part of the next ubuntu-core update
[13:36] <ogra_> mvo, cool
[13:36]  * ogra_ remomembers he needs to add rfkill to writable-paths before next os snap 
[13:43] <ogra_> done :)
[13:45] <zyga> noizer: you cannot run apps from other snaps, just from your own
[13:45] <zyga> noizer: what do you want to do and why?
[13:45] <zyga> noizer: maybe I can help somehow
[13:46] <ogra_> yeah, the correct answer would be to bundle everything you need into the same snap and manage it internally there
[13:46] <noizer> zyga I explained you earlier this day xD but here got it . I want a main snap. This snap needs to start other programs (snaps)
[13:47] <noizer> zyga http://imgur.com/orqlhRD
[13:47] <zyga> noizer: that diagram confused me
[13:47] <zyga> noizer: it has one snap and many apps
[13:47] <zyga> noizer: that _is_ allowed
[13:47] <zyga> noizer: running any apps from other snaps is not
[13:47] <zyga> noizer: if you control all the snaps just bundle everything
[13:47] <zyga> noizer: there are no "library snaps"
[13:48] <zyga> noizer: note that snap is the package
[13:48] <zyga> noizer: and app is something you can run in a snap
[13:48] <noizer> zyga ow wait you got 100 snaps with 1 main snap this main snap can start every snap on you device
[13:48] <zyga> noizer: snap == package, app == executable
[13:48] <zyga> noizer: a snap cannot have any snaps
[13:48] <noizer> sorry I did some mistakes for my vocabulary xD
[13:49] <zyga> noizer: so do you know what I mean now?
[13:49] <noizer> wait is that possible you have now the OS and that i build everything on my OS and then install snaps and that the build on my OS (not in a snap) can manage the snaps
[13:50] <noizer> zyga I know what you mean but I don't think you understand me correctly
[13:51] <zyga> noizer: wha you describe sounds more like ubuntu personal
[13:51] <zyga> noizer: where you just have a desktop and can pick apps to run
[13:51] <zyga> noizer: currently we don't allow this in ubuntu core
[13:51] <noizer> yes but the advantage of snappy that every snap is seperate from each other
[13:51] <zyga> noizer: I'd suggest emailing snappy-app-devel mailing list with the details of what you want to build
[13:52] <zyga> noizer: (that is true in personal as well)
[13:52] <zyga> noizer: and perhaps others can suggest what to do
[13:58] <noizer> zyga ok I will give it a shot
[13:59] <ogra_> mvo, hmm, did the all-snaps u-d-f change the --install option ? i just built a dragonboard image with --install webdm.canonical ... it finished fine and i also saw it installing webdm ... but:
[13:59] <ogra_> ubuntu@localhost:~$ snappy list|grep webdm
[13:59] <ogra_> ubuntu@localhost:~$
[14:00] <ogra_> http://paste.ubuntu.com/15243621/ is the build log
[14:01] <mvo> ogra_: hm, no recent changes there
[14:01] <ogra_> weird
[14:01] <mvo> ogra_: anything in ls /snaps?
[14:02] <ogra_> ubuntu@localhost:~$ ls /snaps/webdm.canonical/
[14:02] <ogra_> 0.15
[14:02] <ogra_> ubuntu@localhost:~$
[14:02] <ogra_> no current link
[14:03] <ogra_> GRRR !
[14:03] <ogra_> Rejected:
[14:03] <ogra_> Unable to find distroseries: xernial
[14:03] <ogra_> Further error processing not possible because of a critical previous error.
[14:03] <ogra_> ubuntu-core-config (0.6.38) xernial; urgency=medium
[14:04]  * ogra_ fixes
[14:08] <ogra_> silly xernial ... doesnt exist :P
[14:20] <sergiusens> fgimenez, seems like the jenkins thing is not completely fixed; I guess you can hand over to elopio_ now
[14:20] <sergiusens> but there was only 1 succesful run so far
[14:20] <sergiusens> ogra_, what are you pushing though? maybe push to distroseries 'ogra' ;-)
[14:21] <kyrofa> sergiusens, yeah what's going on with https://github.com/ubuntu-core/snapcraft/pull/344?
[14:21] <sergiusens> kyrofa, seems some of the backend is dead; I had one succesful run this morning though
[14:21] <kyrofa> sergiusens, I tried all weekend. Made me cry
[14:21] <ogra_> sergiusens, indeed, i should push to omnious ogra :)
[14:22] <sergiusens> kyrofa, same thing; the error doesn't even help
[14:22] <kyrofa> sergiusens, no kidding
[14:22] <sergiusens> didrocks, here's the thing I'd mention I'd try out from SCaLE in case you want to look; it is very deep dive https://github.com/ubuntu-core/snapcraft/pull/335
[14:23] <sergiusens> kyrofa, elopio_ since weekly is cancelled I guess we will do a regular standup
[14:23] <kyrofa> sergiusens, sounds good
[14:23] <didrocks> sergiusens: oh nice! I'm going to give it a look (tomorrow morning probably)
[14:24] <fgimenez> sergiusens, elopio_ yep, the instances still look bad http://paste.ubuntu.com/15243858/
[14:24] <sergiusens> didrocks, thanks; any ideas for improvement welcome
[14:25] <sergiusens> fgimenez, have you tried pinging IS directly on #is?
[14:26] <fgimenez> sergiusens, sure :) http://paste.ubuntu.com/15243874/
[14:27] <sergiusens> fgimenez, oh, so end of week maybe? :-P but really :-(
[14:29] <fgimenez> sergiusens, hopefully it won't take too long, we have had issues like this before and they were solved quite quickly
[14:30] <kyrofa> sergiusens, dang... maybe start running locally and merging without?
[14:31] <kyrofa> sergiusens, I'll be 2 minutes late
[14:57] <sergiusens> kyrofa, oh, integration tests happening there or not?
[14:57] <kyrofa> sergiusens, yeah they will
[14:58] <kyrofa> I'll get the examples tests running locally, merge that other one, then write the integration tests and ping you
[15:04] <ysionneau> zyga: any idea how to run a snap app in gdbserver?
[15:04] <ysionneau> the app segfaults and I wanna know why
[15:05] <zyga> ysionneau: hmmm, interesting
[15:05] <ysionneau> I already have gdbserver on the target, but since there is the sandboxing...
[15:05] <zyga> ysionneau: you can patch the wrapper script
[15:05] <ysionneau> and I cannot run the wrapper with gdb
[15:05] <ysionneau> ah yes
[15:05]  * ysionneau stupid
[15:05] <zyga> ysionneau: or just setup a manually crafted script that runs gdb and your app via ubuntu-core-launcher
[15:06] <zyga> ysionneau: or try it from the unconfined shell first, maybe you can test it better this way
[15:06] <ysionneau> my snap needs some lib
[15:06] <ysionneau> so I cannot run it without the wrapper which sets all the env
[15:06] <zyga> ysionneau: you can
[15:07] <zyga> ysionneau: the wrapper isn't magic, look at what it does
[15:07] <zyga> ysionneau: just set the right environment variables
[15:07] <zyga> ysionneau: you can try the whole wrapper with or without ubuntu-core-launcher (again, by manually hacking the wrapper script)
[15:07] <ysionneau> ack
[15:07] <zyga> ysionneau: though the launcher (not the wrapper, the actual launcher) does some interesting things that may be a factor too
[15:08] <zyga> ysionneau: I'd suggest trying without the launcher, just with altered environment
[15:08] <zyga> ysionneau: and do take advantage of classic dimension, apt-get install all the support tools and use them on the outside
[15:10] <kyrofa> ysionneau, or grab a core dump and analyze it with gdb separately
[15:16] <ogra_> ysionneau, you can use the classic shell and attach to the PID as well :)
[15:19] <ogra_> (oh, zyga said so already)
[15:24] <ace139> hi, I just installed snappy core for my RPi2, as it does not come with wifi support out of the box, could someone tell me what packages I need to install to get the wifi working ?
[15:27] <ogra_> ace139, what wifi card is that ? the hw should definitely be recognized on the latest images
[15:27] <zyga> ace139: it should work out of the box, just edit /etc/network/interfaces.d/wlan0
[15:27] <zyga> ace139: and add typical ifupdown wlan config there
[15:28] <zyga> ace139: quick test is to run ifconfig -a
[15:28] <ogra_> ubuntu@localhost:~$ cat /etc/network/interfaces.d/wlan0
[15:28] <ogra_> allow-hotplug wlan0
[15:28] <ogra_> iface wlan0 inet dhcp
[15:28] <ogra_>     wpa-ssid grawert.net
[15:28] <ogra_>     wpa-psk XXXXXXXX
[15:28] <zyga> ace139: if you see wlan0 or something like that that will be a good sign that the hardware is supported
[15:28] <ogra_> that is what i use here (on a dragonboard with builtin WLAN though)
[15:29] <ogra_> (and indeed XXXXXXX is actually my wpa key)
[15:29] <ace139> ogra_, zyga the wifi adapter I am using, is not sensed somehow.
[15:29] <ace139> I have made changes to the interfaces.d/wlan0
[15:30] <zyga> ace139: does it work on your regular ubuntu
[15:30] <ace139> zyga, yes, and on raspbian too
[15:30] <ogra_> ace139, what chipset is that then, and what image (old 15.04 or the newer 16.04 ones)
[15:31] <ace139> ogra_, 15.04
[15:31] <ogra_> (though both latest images should ship a ton of wifi drivers)
[15:31] <zyga> ace139: try 16.04
[15:31] <ace139> zyga, can I get a link ?
[15:32] <zyga> ace139: https://github.com/zyga/devtools/blob/master/ubuntu-image
[15:32] <zyga> ace139: try that :)
[15:32] <ogra_> ace139, the latest and greatesd should be at http://people.canonical.com/~mvo/all-snaps/
[15:32] <ogra_> or try zyga's tool to build one
[15:32] <ace139> zyga, ogra_ thanks, let me try
[15:32] <zyga> :)
[15:32]  * zyga smells raspberry pi 3 in the mail tomorrow
[15:32] <zyga> snif snif
[15:33] <zyga> fresh hardware :)
[15:33] <ogra_> tell us about the wlan then :)
[15:33] <zyga> I really want to be able to build my gadged and kernel nsaps
[15:33] <zyga> snaps*
[15:33] <ogra_> its a shame it cant actually do 64bit from the start
[15:33] <zyga> for my work on interfaces and for doing community ports of other boards I have
[15:33] <zyga> ogra_: hehe, given what pi1 was I'm super positive they will get there
[15:34] <ogra_> definitely
[15:34] <zyga> ogra_: remember how crappy it was in the beginning
[15:34] <zyga> ogra_: and it makes sense to ship hardware before the software
[15:34] <ogra_> i dont, i only started using pi's with pi2
[15:34] <zyga> ogra_: well, all the blobs, the uncertain situation of the kernel
[15:34]  * ogra_ doesnt care much about HW that cant run ubuntu :P
[15:34] <mojo> hi
[15:34] <zyga> ogra_: now it's all upstream and the GPU is getting fantastic work done in the open
[15:34] <zyga> mojo: hey
[15:34] <ogra_> yeah
[15:35] <ogra_> dragonboard actually has a free driver though :)
[15:35] <zyga> ogra_: is dragonboard using ardeno or something else?
[15:35]  * zyga lost track
[15:35] <ogra_> (but a similar crappy closed bootloader made out of blobs)
[15:35] <ogra_> zyga, yeah ... so freedreno should just work
[15:35] <zyga> ogra_: mmm, nice
[15:35] <zyga> it's amazing what so few people can make
[15:36] <ogra_> yeah
[15:36] <zyga> all the gpu hacking, folks fit in a bigger lift together
[15:36] <Guest36587> a quick questions guys, can ubuntu core snappy run on a i386 system?
[15:36] <zyga> (hope they use the stairs though)
[15:36] <zyga> Guest36587: yes
[15:36] <ogra_> i wish i would have been able to go to linaro connect to actually talk to the people to get this working in snappy OOTB
[15:36] <zyga> Guest36587: use https://github.com/zyga/devtools/blob/master/ubuntu-image to build a 16.04 based image
[15:36] <zyga> Guest36587: good luck
[15:36] <zyga> ogra_: the one in bangalore?
[15:36] <zyga> ogra_: when is it? I think ~week(s) from now?
[15:36] <ogra_> yeah, i386 didnt get much attention yet ... might be a matter of luck
[15:37] <ogra_> zyga, right
[15:37] <Guest36587> can it be installed as regular ubuntu image on a SD card?
[15:37] <ogra_> Guest36587, you dd it to the SD and boot
[15:37] <zyga> Guest36587: just "dd" it to anything that your machine boots from, it can be a HDD as well
[15:37] <ogra_> right
[15:37] <zyga> Guest36587: or you can use it to start a VM
[15:37] <zyga> ogra_: is it too late for you to go?
[15:37] <ogra_> zyga, asac stole my ticket :P
[15:38] <zyga> aaahh
[15:38] <zyga> hehe, I knew that asac was going
[15:38] <Guest36587> ok. thank you i will give it a try.
[15:38] <ysionneau> 16:16 < ogra_> ysionneau, you can use the classic shell and attach to the PID as well :) < yep but it's not a daemon and it crashes right away
[15:38] <ogra_> zyga, but then asac will have to implement freedreno in the dragonboard images, so all is fine :P
[15:38] <zyga> ysionneau: use gdb and run your program from gdb, then you can see why
[15:38] <zyga> ysionneau: or enable core dumps and inspect the core later
[15:39] <zyga> ogra_: haha, I'm sure asac will love that
[15:39] <ogra_> for sure :)
[15:39]  * zyga spent all weekend staring at elf sections and program headers and x86 disassembly
[15:39] <zyga> but core files is something I have yet to play with
[15:39] <zyga> I haven't touched a core file in a decade
[15:43] <Guest36587> when running the script i get error unenxpected  "(" error on line 391
[15:44] <zyga> Guest36587: oh, let me see
[15:44] <zyga> Guest36587: hmm, the script has 214 lines
[15:44] <zyga> Guest36587: can you show me what you did please?
[15:44] <zyga> Guest36587: if I broke it I'll happily fix it :)
[15:44]  * zyga should add travis CI to the script
[15:45] <Guest36587> ok i did copied the script selected options i386 - then vanilla
[15:45] <zyga> Guest36587: can you pastebin the output of the script?
[15:45] <zyga> Guest36587: or just the error perha
[15:45] <zyga> ps
[15:45] <Guest36587> ok sec
[15:47] <Guest36587> Building image... /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391: 1: /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391: Syntax error: "(" unexpected
[15:47] <zyga> Guest36587: ahhh
[15:47]  * zyga looks
[15:48]  * zyga tries to reproduce
[15:48] <zyga> Guest36587: what is your host OS?
[15:48] <Guest36587> ubuntu 15.04 running on vbox
[15:48] <zyga> Guest36587: I was testing this on Ubuntu 16.04 (xenial)
[15:48] <zyga> Guest36587: I suspect 15.04 works as well though
[15:49] <zyga> I can check that in a moment, trying to reproduce the issue now
[15:49] <Guest36587> well i can install xenial and give it a try
[15:49] <zyga> Guest36587: can you check what is inside /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391
[15:50] <zyga> Guest36587: and perhaps one more thing:
[15:50] <zyga> Guest36587: can you pleas add 'set -x' to the top of the script (without the quotes)
[15:50] <Guest36587> seems like a data file
[15:50] <zyga> Guest36587: re-run it and pastebin the whole log
[15:50] <zyga> Guest36587: ok
[15:50] <zyga> Guest36587: my run will finish in a moment
[15:50] <Guest36587> ok let me set debug on it
[15:50] <zyga> Guest36587: so far all is good
[15:51] <zyga> (a few more minutes)
[15:52] <kyrofa> ogra_, since the pi3 has a 64-bit processor, can we still run 64-bit ubuntu core on there even if the standard OS is only 32-bit?
[15:53] <Guest36587> ok so running debug on script:
[15:53] <Guest36587> + udf=/root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 + chmod +x /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 + [ -n  ] + [ -n  ] + [ -n  ] + test -z ubuntu-core.canonical + test -z canonical-pc-linux.canoni
[15:53] <zyga> Guest36587: thanks
[15:53] <zyga> Guest36587: please pastebin everything
[15:53] <zyga> Guest36587: (copy paste and paste it to paste.ubuntu.coM)
[15:54] <Guest36587> Building image... + exec sudo /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 core rolling --channel edge --kernel canonical-pc-linux.canonical --os ubuntu-core.canonical --gadget canonical-i386.canonical -o i386.img /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f1
[15:55] <Guest36587> ca7df71501035f7391: 1: /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d7
[15:55] <Guest36587> and the rest of it
[15:55] <Guest36587> he have a limited buffer here
[15:56] <zyga> Guest36587: it just built fine for me
[15:56] <zyga> Guest36587: you can try this:
[15:57] <zyga> Guest36587: ./ubuntu-image --no-developer-image i386
[15:57] <zyga> Guest36587: ./ubuntu-image --no-developer-image i386 | pastebinit
[15:57] <zyga> Guest36587: ^^ this command will be non-interactive (apart from sudo) and will paste the output (though not the error streams)
[15:57] <zyga> Guest36587: ./ubuntu-image --no-developer-image i386 2>&1 | pastebinit
[15:57] <zyga> perhaps this one
[15:58] <zyga> Guest36587: for example this is a session I just ran to test it:
[15:58] <zyga> http://pastebin.ubuntu.com/15244574/
[16:00] <Guest36587> hmmm
[16:00] <Guest36587> i'm missing something here
[16:00] <Guest36587> ubuntu-image i guess
[16:00] <Guest36587> :D
[16:00] <zyga> ?
[16:01] <Guest36587> i need to install it
[16:01] <zyga> ubuntu-image should run without any extra deps beyond what ubuntu-device-flahs (which it downloads) requires
[16:01] <Guest36587> somehow
[16:01] <zyga> Guest36587: the only thing that I can think of are tools like kpartx
[16:02] <Guest36587> i belive its simpler then that ;)
[16:02] <zyga> oh?
[16:02] <Guest36587> yup i dont have ubuntu device flash installed :O
[16:02] <Guest36587> noobie
[16:02] <Guest36587> ;)
[16:03] <zyga> Guest36587: that is normal
[16:03] <zyga> Guest36587: ubuntu-image downloads a special version
[16:03] <zyga> Guest36587: the version you can install won't work (though perhaps it will help to install other dependencies)
[16:03] <zyga> Guest36587: try installing it anyway and re-run ubuntu-image
[16:04] <Guest36587> but wait i was expecting that after installing ubuntu-device-flash, ubuntu-image would get installed
[16:04] <Guest36587> but no it seems that i need some aditional software
[16:07] <zyga> Guest36587: why would you expect that, ubuntu-image is a script that is not packaged anywhere
[16:08] <zyga> Guest36587: I'm not sure what happened or what actually caused that error to show up, try again (after you've installed ubuntu-device-flash)
[16:08] <zyga> Guest36587: or get a pre-made image from http://people.canonical.com/~mvo/all-snaps
[16:08] <zyga> (AFAIR)
[16:09] <Guest36587> thank you
[16:10] <zyga> Guest36587: good luck :)
[16:11] <Guest36587> ;)
[16:13] <ysionneau> zyga: if I want to allow an app to open some usr/lib/lib.so (via dlopen), I added /usr/lib/lib.so in the read-paths in security-override, is it the right way?
[16:13] <ysionneau> I cannot give the absolute path since it's in /snaps/name/some_hash/
[16:15] <dholbach> kyrofa, sergiusens: with the ros plugin gone, should the ros doc go as well?
[16:15] <zyga> ysionneau: hmmm
[16:15] <zyga> ysionneau: you _should_ be able to dlopen anything in your snap
[16:16] <kyrofa> dholbach, oh no-- there were two ros plugins, the useless one was removed
[16:16] <dholbach> ah no... it's updated
[16:16] <ysionneau> fyi when the app dlopen, it segfaults
[16:16] <dholbach> thanks kyrofa
[16:16] <kyrofa> dholbach, though the one on dev.ubuntu.com needs to be updated-- want me to do it?
[16:16] <zyga> ysionneau: I assume /usr/lib/lib.so is actually relative to your installed snap
[16:16] <dholbach> kyrofa, no, I'll do it
[16:16] <zyga> ysionneau: what's the deny you get (tip, check syslog)
[16:16] <kyrofa> dholbach, okay :)
[16:16] <dholbach> kyrofa, working through the whole list now :)
[16:16] <kyrofa> dholbach, heh, good luck!
[16:18] <ysionneau> I get this in syslogs zyga http://pastebin.com/szMDAht0
[16:19] <ysionneau> I cannot see any deny, except from ulogcatd
[16:19] <ysionneau> the name of my app here is "wifid"
[16:21] <ysionneau> if in my code I do dlopen("/usr/lib/libfoo.so"); it will be able to open a lib in /snaps/wifid.sideload/INcVRgETGKeR/usr/lib/wifid/ ?
[16:22] <ysionneau> or should it be dlopen("libfoo.so") :o
[16:22] <zyga> ysionneau: you don't run with a chroot, you have to read appropriate $SNAP.. environment variable and dlopen stuff relative to that
[16:22] <ysionneau> oh, so the app needs to know it runs in a "snap" env
[16:23] <zyga> ysionneau: yes
[16:23] <ysionneau> that's not transparent
[16:23] <ysionneau> ok
[16:23] <zyga> ysionneau: or use a relative path
[16:23] <zyga> ysionneau: btw, offtopic: Feb 29 16:11:23 localhost kernel: wifid[1240]: unhandled level 1 translation fault (11) at 0x68730000, esr 0x83000005
[16:23] <zyga> ysionneau: this doesn't look good
[16:23] <ysionneau> it crashes in the dlopen()
[16:23] <zyga> ysionneau: we've patched some common things to understand snappy better (bluez, network-manager), have a look at the approach taken there
[16:24] <zyga> ysionneau: basically we look at the relevant environment and change compiled-in constants to variables/functions
[16:24] <ysionneau> like env variable?
[16:27] <plars> ev: are things happier with spi today?
[16:29] <ysionneau> btw when I run as a non-root my snappy app I get this weird message now =>  mkdir: cannot create directory ‘/home/ubuntu/snaps/wifid.sideload/INcWOCRAPaVT’: permission denied
[16:30] <zyga> ysionneau: yes, exactly
[16:30] <zyga> ysionneau: that looks like an outdated security profile, it was fixed a while ago
[16:31] <zyga> ysionneau: if that's on 16.04 then just do sudo snappy update and reboot
[16:31] <zyga> ysionneau: if that persists bug jdstrand_ about it (it should work)
[16:31] <kyrofa> zyga, if it was run as root then the permissions won't work for non-root
[16:31] <zyga> kyrofa: if it was run as root then it would have $HOME set to /root
[16:32] <ysionneau> ah yes it's 16.04
[16:32] <zyga> kyrofa: we don't do what happens on ubuntu, "sudo foo" runs with home set to /root
[16:32] <zyga> kyrofa: same with background apps (services)
[16:32] <kyrofa> zyga, you sure about that? When was that change made?
[16:32] <zyga> kyrofa: yes
[16:32] <zyga> kyrofa: a while ago, it was announced on snappy-devel by gustavo
[16:32] <ysionneau> sudo snappy update just returns to shell
[16:32] <zyga> ysionneau: which version do you have (of ubuntu-core) (tip: snappy list)
[16:33] <ysionneau> 2016-02-22 16.04.0-10.armhf
[16:33]  * zyga checks 
[16:33] <ysionneau> it's weird because I could swear a few minutes ago I was able to run it as non-root without having this weird error
[16:33] <zyga> hmm, odd
[16:34] <zyga> and you don't see DENIED errors in syslog?
[16:34] <kyrofa> zyga, so bug #1466234 is resolved?
[16:34] <ysionneau> hmmm or maybe I was root previously ...
[16:34] <zyga>  ohhhh
[16:34] <zyga> kyrofa: perhaps not :)
[16:34] <zyga> kyrofa: jdstrand_ would konw
[16:34] <kyrofa> zyga, :)
[16:34] <zyga> know*
[16:35] <zyga> kyrofa: but it is consistent with what I said (as in background apps seeing /root not /home/ubuntu)
[16:35] <ysionneau> zyga: that's the last syslog lines http://pastebin.com/YU2zAApz
[16:35] <zyga> kyrofa: just another bug :)
[16:35] <kyrofa> zyga, indeed, services run as root and use /root. However, unless that bug is fixed sudo works like it always has
[16:35] <zyga> I see Feb 29 16:27:35 localhost kernel: audit: type=1400 audit(1456763254.990:16): apparmor="DENIED" operation="open" profile="ulogcatd.sideload_foreground_INcOORXgeaYG" name="/sys/devices/virtual/misc/ulog_main/logs" pid=1434 comm="ulogcat" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[16:35] <zyga> kyrofa: true, true
[16:35] <kyrofa> (and $HOME=/home/ubuntu)
[16:36] <zyga> ysionneau: what is /sys/devices/virtual/misc/ulog_main/logs?
[16:37] <ysionneau> that's related to the ulogger kernel module we have
[16:37] <ysionneau> it's some kind of android logcat driver clone
[16:37] <ysionneau> I'm running ulogcat because wifid is printing debug to this
[16:37] <ysionneau> that's how I could trace it was going fine until doing the dlopen()
[16:37] <zyga> ok
[16:38] <zyga> ysionneau: I'm not sure what's going on TBH, I don't see any other denies there and it seems you are just crashing later
[16:38] <zyga> ysionneau: try with gdb
[16:42] <ogra_> kyrofa, seems the kernel lacks any support for 64bit yet, so for now it is 32 all the way ... once broadcom released patches we should be able to run both
[16:43] <kyrofa> ogra_, alright good to know, thanks :)
[16:43] <ogra_> (though the device comes with the same set of drawbacks the pi2 or pi1 had ... like overloaded USB hubs etc ... )
[16:44] <ogra_> seems the design didnt change much
[16:44] <ogra_> (except that you now also have a BT and WLAN device eating up your USB speed)
[16:45] <zyga> ogra_: pi2 has much better electric stuff around usb hub as compared to pi1
[16:45] <zyga> ogra_: otherwise agreed :)
[16:45] <ogra_> zyga, better ... yeah ..
[16:46] <zyga> ogra_: well, it doesn't die of overcurrent when you plug a dongle anymore
[16:46] <ogra_> does it survive taking pictures with flash now or is it still shy ? :P
[16:48] <zyga> ogra_: hehe not sure, I'd have to look if they changed it over from bare die
[16:48] <ogra_> i guess a cheap layer of paint would even already help
[16:58]  * zyga has only 3 more patches to rebase
[16:58] <zyga> woot :)
[16:59]  * ogra_ is sad to see kyrofa removed the useless ros plugin ... now people cant build useless robots anymore 
[17:01] <kyrofa> ogra_, :P
[17:01] <ogra_> :)
[17:01] <sergiusens> zyga, I thought you weren't allowed to rebase ;-)
[17:01] <ogra_> stuck in spain forever :)
[17:03] <zyga> sergiusens: it's my demo branch
[17:03] <zyga> ogra_: hehe
[17:03] <zyga> sergiusens: I love to rebase :)
[17:04] <zyga> and merge would be hell with all the renames
[17:08] <ysionneau> I'm able to reproduce the issue with a small binary which only does printf() + dlopen()
[17:09] <ysionneau> the segfault + the need to run as root
[17:11] <zyga> ysionneau: plesae file a bug and attach that to the report
[17:12] <ogra_> hmm, dlopen ...
[17:12] <ogra_> does that respect LD_LIBRARY_PATH at all ?
[17:13]  * ogra_ has a blurry recollection there was some issue with dlopen
[17:14] <zyga> ogra_: doens't n-m use dlopen?
[17:14] <ogra_> no idea
[17:14] <tedg> zyga: I was looking at the interfaces REST interface, and I think the connections object needs an "app" field as well, no?
[17:15] <zyga> tedg: hey, mmm, we know about apps internally but we're not exposing that over the REST API
[17:15] <tedg> zyga: We need to know about it externally :-)
[17:15] <zyga> tedg: technically each plug and slot knows about apps that are affected
[17:15] <tedg> zyga: Specifically so we know which apps we can launch.
[17:15] <zyga> tedg: sure, please raise this with gustavo, I'm sure we can do this
[17:15] <zyga> tedg: I actually explicitly erase this so doing it should be simple
[17:15] <ysionneau> I'm not entirely sure if this bug comes from my environment or not
[17:16] <tedg> Seems like he's not here.
[17:16] <ysionneau> maybe it's because of my build system (alchemy)
[17:16] <zyga> tedg: hmm?
[17:16] <zyga> tedg: who is "we" there?
[17:16] <tedg> zyga: UAL
[17:16] <zyga> tedg: all apps can be launched, no?
[17:16] <zyga> tedg: in any case, I can trivially do this if it helps you out
[17:16] <zyga> tedg: I have a big overhaul branch that fixes this
[17:16] <zyga> tedg: and to expose apps I'd litterlaly have to write two lines
[17:16] <zyga> tedg: I can give you a branch for testing if you're interested
[17:17] <tedg> zyga: Cool. I need to get more basics working first, so you may land it before I would get ready for it.
[17:17] <tedg> zyga: But I'll ping you if that becomes my blocker.
[17:17] <zyga> (plus all the tests that it would affect :)
[17:17] <zyga> tedg: cool
[17:17] <tedg> Heh, tests are always a problem ;-)
[17:17] <zyga> tedg: as a sanity check: you'd GET /2.0/interfaces
[17:18] <zyga> tedg: and you'd see a single object having {"plugs": ..., "slots": ...}
[17:18] <ysionneau> if I package a libc and libdl in my snap, will it use the libc of the system? or the one I packaged in my snap?
[17:18] <zyga> tedg: each of those dots would be a list of Plug or Slot objects
[17:18] <tedg> ysionneau: Depends on your LD_LIBRARY_PATH, but by default it would be the one in your package. But you could change that.
[17:18] <zyga> tedg: each of those having an optional "connections" attribute with a list of SlotRef and PlugRef (respecitvely)
[17:19] <zyga> tedg: and those just have a pair of attributes "snap" and "slot" or "plug" (respectively)
[17:19] <zyga> tedg: you'd find "apps" with a list of apps that are affected on each Plug and Slot objects there (not ...Refs)
[17:19] <zyga> ysionneau: I suspect yours
[17:20] <tedg> zyga: Yeah, exactly. I dont' care if it's an array there or there is an entry for each app. Either way works for me.
[17:20] <zyga> ysionneau: though I don't know for sure, you can always package your dynamic linker there so you have total cotrol
[17:20] <zyga> control*
[17:20] <zyga> tedg: I have a branch with all of this, I'll push it for reference
[17:20] <zyga> tedg: one sec (just one more patch to rebase)
[17:20] <tedg> zyga: Could we put version there as well? Then I could get the full AppID with one call.
[17:21] <tedg> I was expecting 1+n, but 1 would be better :-)
[17:21] <ysionneau> zyga: I think I packaged lots of stuff, I should have a very controled env here :o
[17:22] <zyga> tedg: ah, interesting point
[17:22] <ysionneau> http://pastebin.com/uRiXN9se
[17:22] <zyga> tedg: not today but yeah, I'm actually making more bits available there now (as a part of the rebase)
[17:22] <zyga> tedg: though I suspect gustavo may object more on this end, please bring it up with him first
[17:22] <zyga> tedg: as this is clear cross-manager responsibility
[17:23] <zyga> tedg: and perhaps the REST api will change (again) to address that
[17:23] <zyga> tedg: right now we don't leak any information that belongs to the snap manager
[17:23] <zyga> tedg: and apps and versions are a part of that
[17:23] <zyga> tedg: so I see what you want and I'm just saying the road there may be curvy
[17:23] <tedg> zyga: Sure, and it'd only be in UAL, so it'd be an optimization. Not something we'd bubble up to Unity/etc. So it is something we can do later without bothering them.
[17:24] <tedg> zyga: Generally that makes it less pressing. We can see how costly it is.
[17:24] <zyga> tedg: what does UAL stand for?
[17:24] <tedg> zyga: Ubuntu App Launch
[17:24] <zyga> what is that?
[17:24] <ogra_> the wrapper we run to set up the env
[17:25] <tedg> zyga: Basically the library that coordinates application launching for Unity/URL DIspatcher/etc.
[17:26] <zyga> tedg: I see
[17:26] <zyga> ok
[17:26] <sergiusens> jdstrand, hey should this be allowed by default? https://bugs.launchpad.net/snapcraft/+bug/1544236
[17:49] <plars> noise][: are things better with spi today?
[17:50] <plars> noise][: I tried to submit an image, but it doesn't look like the agent ever picked up a test opportunity from it
[17:50] <plars> noise][: is there some way to hunt that down? The id from the submission is 44e8d447-c36a-4e2d-8ff8-d6c9325a4083
[17:51] <noise][> plars - can you query the test progress for that id?
[17:51] <plars> noise][: I can do that through spi? do you have an example?
[17:53] <noise][> plars- check Querying Test Progress part of the api doc
[17:56] <plars> noise][: hmm, it says provfail but I didn't see it come through in the local logs... let me try again
[17:59] <plars> noise][: strange, it seems to be attempting it this time. There isn't any other agent configured with that platform type, so this is the only one that could have even attempted it
[18:00] <noise][> if you got a PICKED_BY_AGENT event, and result posted, _some_ agent did it :)
[18:00] <noise][> and you can see what agent_id picked it
[18:05] <ace139> Can anyone help me about installing vim in snappy core, whenever i run sudo snappy install vim, it says package not found
[18:07] <kyrofa> ace139, vim isn't packaged for Snappy
[18:07] <ogra_> sudo snappy enable-classic; snappy shell classic ... then you can use apt inside the classic shell ... there is no vim snappy package
[18:07] <kyrofa> ace139, which version of Ubuntu Core are you running?
[18:07] <kyrofa> ace139, if you're running 16.04, what ogra_ says
[18:07] <ogra_> i think we pointed him to 16.04 earlier today ;)
[18:08] <kyrofa> ace139, that vim-tiny or whatever isn't good enough for you, eh? ;)
[18:08] <ogra_> people are so spoiled nowadays :)
[18:08] <ogra_> wanting cursor keys to work and such :)
[18:09] <kyrofa> ogra_, that's all fixable with a good .vimrc and stuff
[18:09] <kyrofa> ogra_, my mantra is set nocompatible and backspace=2
[18:09] <ogra_> i just get along with the defaults usually
[18:10] <ogra_> often enough my installs dont survive long enough for making such changes anyway
[18:10] <ogra_> my vim on desktop has quite a huge vimrc though
[18:11]  * ogra_ calls it a day
[18:11] <kyrofa> Bye ogra_ :)
[18:15] <ace139> kyrofa, sorry got disconnected. so, can anyone help me install vim in snappy ?
[18:15] <kyrofa> ace139, heh, welcome back
[18:15] <kyrofa> ace139, vim isn't packaged for snappy, you'd need to do it in the classic dimension (assuming you're on 16.04)
[18:16] <ace139> kyrofa, I am in 15.04
[18:16] <kyrofa> ace139, ah, okay. What functionality are you looking for beyond the vim-tiny?
[18:16] <ace139> kyrofa, just installed snappy, official site is providing that only
[18:17] <ace139> kyrofa, I need to configure the wifi, which is not working, needed to write the conf file. but the vi editor is giving me headache,
[18:17] <kyrofa> Ah, since you can't move around in edit mode and whatnot?
[18:18] <ace139> kyrofa, I cannot use the backspace to delete as in vim
[18:18] <kyrofa> ace139, try pasting the contents of this into ~/.vimrc : http://pastebin.ubuntu.com/15245593/
[18:18] <kyrofa> ace139, then try again. Does it make it better?
[18:18] <ace139> kyrofa, just a sec
[18:19] <ace139> kyrofa, life saver :)
[18:20] <elopio> I'm back. I had to reinstall quassel, so I lost all the backlog :(
[18:20] <kyrofa> ace139, we're here for ya ;)
[18:20] <kyrofa> elopio, ah, welcome!
[18:20] <elopio> I'm sorry if anybody pinged me and I didn't reply. You can try again.
[18:20] <ace139> kyrofa, I was not aware that .vimrc works for vi too
[18:20] <kyrofa> ace139, indeed
[18:20] <ace139> kyrofa, any suggestions how to get my wifi up and running
[18:21] <ace139> kyrofa, doing ifconfig doesn't show a thing
[18:21] <ace139> kyrofa, eth0 and loopback is there tough
[18:22] <ace139> kyrofa, I was thinking about writing a wlan0 in /etc/network/interfaces.d/
[18:22] <kyrofa> ace139, what hardware are you using?
[18:23] <ace139> its a TP-LINK
[18:23] <ace139> TL-WN722N
[18:23] <kyrofa> ace139, I have the dragonboard here and writing a wlan0 in /etc/network/interfaces.d did the trick for me
[18:24] <ace139> kyrofa, maybe I should give a try to.
[18:27] <ace139> kyrofa, I am in luck I guess. Its detected.
[18:27] <kyrofa> ace139, excellent!
[18:28] <ace139> now supplying the credentials in the wpa_suppliant.conf
[18:28] <ace139> kyrofa, hope it works
[18:31] <jdstrand> sergiusens: I think what is happening is with the move to interfaces/skills/capabilities, the 'network-client' cap is not automatically being added if nothing is specified
[18:31] <jdstrand> sergiusens: that is a change over 15.04 behavior. I don't think it was intentional, but it is probably worth discussing
[18:32] <ace139> kyrofa, tighvncserver works here ?
[18:33] <kyrofa> ace139, you'll probably need to package it as a snap
[18:33] <ace139> kyrofa, I guess so, package is not found here.
[18:33] <ace139> kyrofa, anyother vnc server you can suggest ?
[18:34] <kyrofa> ace139, I don't believe any have been packaged
[18:34] <kyrofa> ace139, but check the store
[18:34] <kyrofa> ace139, it's always changing
[18:34] <ace139> kyrofa, well I am not having a GUI here
[18:34] <ace139> kyrofa, just was able to get into the Pi doing ssh
[18:35] <ace139> kyrofa, okay, thanks for all the help. Need to find some way out, atleast the connection is up !
[18:36] <kyrofa> ace139, SSH should work as well
[18:36] <ace139> kyrofa, can I visit store using ssh ?
[18:36] <ace139> means the CLI mode ?
[18:36] <kyrofa> ace139, oh, I see what you're saying now. No, but in 15.04 you should be able to use snappy search
[18:36] <kyrofa> ace139, you can also install webdm and visit from another computer
[18:37] <ace139> I have been trying like $snappy search vnc, is returning nothing
[18:37] <kyrofa> ace139, yeah, then I doubt there is anything
[18:37] <ace139> kyrofa, webdm is already installed
[18:37] <kyrofa> ace139, ah, then from your dev machine visit the tp-link's ip address using the port 4200
[18:38] <ace139> kyrofa, not quite understand the procedure you are telling.
[18:39] <ace139> I have a TP Link adapter for WIFI, plugged it in the Pi.
[18:39] <kyrofa> ace139, ah haha, sorry, let me try that again
[18:39] <kyrofa> ace139, from your dev machine visit the snappy device's ip address using the port 4200
[18:39] <ace139> kyrofa, please ! :)
[18:40] <ace139> okay
[18:40] <kyrofa> Using a browser, by the way
[18:40] <kyrofa> webdm is a web app for package management
[18:41] <sergiusens> elopio, can you reply to my previous comment?
[18:41] <ace139> kyrofa, working
[18:41] <ace139> kyrofa, there is a snappy store like the one in ubuntu
[18:42] <kyrofa> ace139, indeed
[18:43] <sergiusens> elopio, kyrofa, https://github.com/ubuntu-core/snapcraft/pull/350
[18:43] <ace139> kyrofa, its nice to explore. Have worked with Raspbian earlier. Its more user friendly I would say.
[18:44] <ace139> kyrofa, you have a owncloud-server package there ?
[18:44] <elopio> sergiusens: which comment? where?
[18:44] <kyrofa> ace139, I do, yes
[18:44] <ace139> kyrofa, thats awesome !
[18:46] <ace139> clear
[18:46] <ace139> oops
[18:51] <sergiusens> elopio, I was just kidding :-)
[18:51] <elopio> sergiusens: that was mean.
[18:51] <kyrofa> sergiusens, hahahahaha
[19:07] <elopio> only one autopkgtest proxy error left \o/
[19:26] <sergiusens> elopio, how are you fixing these?
[19:28] <elopio> sergiusens: I'm not. I just complain to RT, wait, and they get back with more holes in the firewall.
[19:29] <kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/351
[19:31] <elopio> kyrofa: what do you think of install-to?
[19:32] <kyrofa> elopio, makes me think a directory should be provided
[19:34] <elopio> kyrofa: ok. +1 :)
[19:34] <kyrofa> elopio, yeah, no perfect solution it seems
[19:35]  * kyrofa thinks something is wrong when one's SD cards are larger than one's flash drives
[19:36] <kyrofa> There must be a bigger one around here somewhere..
[19:59] <plars> noise][: ok, I think I see the problem... one of the agents I have with a different platform name is picking it up
[20:00] <plars> noise][: does it now ignore the platform?
[20:02] <noise][> plars: yes, routing is only by what products the agent has access to now
[20:03] <plars> noise][: oh... sorry I'm still wrapping my head around all this, so I have some dumb questions. Doesn't that mean I need a different lp id for each platform?
[20:15] <jerryG> will gdb be re-added to snappy-debug?  Why was it removed?
[20:15] <kyrofa> jerryG, it was never there
[20:16] <jerryG> kyrofa: it was there for 0.1
[20:16] <kyrofa> jerryG, but yes, it's intended to be there eventually. Oh? I guess that was before my time
[20:16] <jerryG> kyrofa:  will it be added in time for the 16.04 release... or not till after?
[20:17] <kyrofa> jerryG, that's probably a better question for jdstrand and mvo
[20:19] <jerryG> kyrofa: ok thanks.
[20:20]  * jdstrand defers to mvo
[20:20] <jdstrand> I believe the plan is once all the details are worked out with the store, multiple archs, etc, he might upload arch-specific snaps
[20:21] <sergiusens> elopio, kyrofa so jenkins is down during the weekend and travis during the week
[20:22] <kyrofa> sergiusens, I see that...
[20:22] <kyrofa> sergiusens, can we get travis pro or something?
[20:26] <mvo> yeah, we can upload arch specific snaps now, someone just needs to sit down and write some snapcraft.yaml to pick the right stuff out of gdb :)
[20:26] <mvo> I think we can't have valgrind due to the way it interacts with libc :/
[20:33] <kyrofa> sergiusens, how would you feel about having snapcraft do some sort of cpu detection and enable parallel builds for the plugins that support it?
[20:34] <kyrofa> Is there a downside?
[20:36] <sergiusens> kyrofa, there shouldn't be; we even had a MP once iirc
[20:36] <kyrofa> sergiusens, okay. Low priority of course, but it'd be nice
[20:44] <longsleep> hey folks, are the arm snappy disk images somewhere which directly boot in qemu?
[21:01] <aatchsion> Hey guys, Mycroft is thinking about delivering on the PI 3 after the recent FCC Spec leak. If we can get our hands on some, do you have any plans for an image? They have built-in wifi and bluetooth!
[21:02] <beuno> aatchsion, not yet, it's unclear when/if we'll be able to support it (they are scarce for everyone :))
[21:03] <aatchsion> yeah, for sure. We don't want to have a pi zero type of situation
[21:03] <aatchsion> just a thought
[21:29] <sergiusens> elopio, kyrofa can you try and restart https://travis-ci.org/ubuntu-core/snapcraft/jobs/112667860 ?
[21:30] <kyrofa> sergiusens, I just tried. It claims it was successful, but I see no immediate change
[21:31] <kyrofa> sergiusens, there it goes
[22:03] <sergiusens> kyrofa, thanks
[22:40] <sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/353
[22:40] <sergiusens> it will be a long wait to know when this is good to go though
[22:40] <sergiusens> I hope travis calms down 2 or 3 hours from now
[22:44] <kyrofa> sergiusens, I just learned something interesting. Both of the projects that don't work with DESTDIR do so because they used another variable for that purpose (for example, INSTALL_ROOT). These projects work fine with the prefix change, but I wonder if it might be better to support variables other than DESTDIR instead? Cleaner solution?
[22:45] <kyrofa> sergiusens, or should we keep the prefix capability?
[23:29] <sergiusens> kyrofa, the problem with setting prefix is that we might fall into a 'also set the rpath' situation
[23:29] <sergiusens> both use INSTALL_ROOT ?
[23:30] <kyrofa> sergiusens, yeah that's possible, though at least that's easy enough to disable with current configflags
[23:30] <jerryG> mvo: does snappy debug 0.1's gdb work?... I'm having permission issues when attempting to use
[23:31] <kyrofa> sergiusens, no, one uses INSTALL_ROOT and another does something totally differently. That particular project seems quite broken in that regard, really
[23:31] <kyrofa> sergiusens, but it looks like other people use INSTALL_ROOT as well (qmake, for example)
[23:31] <kyrofa> sergiusens, but still, I wouldn't say it's any sort of standard