[02:36] <liuxg> I am now using snapcraft to build my project. I find that if I change my source codes, it does not pull automatically. I can pull it, but it seems that it does not automatically build it upon the dependency. how to deal with this?
[02:40] <elopio> liuxg: sounds like this one https://bugs.launchpad.net/snapcraft/+bug/1477904
[02:42] <liuxg> elopio, yes, I need to pull the code every time, it wastes time
[02:43] <liuxg> elopio, in fact, I want to compile  local source codes instead of pulling the code every time from the github, which takes a lot of time. sometimes, bzr projects are huge as well. I have to use snapcraft clean every time for a little change.
[02:46] <elopio> liuxg: yup, we have to fix that. sergiusens is working on sources, please leave your comments on the bug so he takes into account your use case.
[02:48] <sergiusens> liuxg, you are talking specifically about the go plugin, right?
[02:52] <sergiusens> liuxg, you are talking specifically about the go plugin, right?
[03:02] <sergiusens> elopio, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/1473333/+merge/277412
[03:03] <elopio> sergiusens: omw, things are happening :)
[03:03] <elopio> let me give it a try.
[03:04] <Bluefoxicy> okay why is there an amd64+generic and amd64-generic?
[03:04] <Bluefoxicy> http://releases.ubuntu.com/15.04/
[03:05] <elopio> sergiusens: you have a mess with the license headers in that project :)
[03:08] <sergiusens> elopio, you don't say? I copied this from go-dbus I think
[03:35] <Bluefoxicy> aw crud.
[03:35] <Bluefoxicy> there are no mirrors with snappy
[03:35] <Bluefoxicy> Hence it takes 1 hour to download
[03:36] <Bluefoxicy> oh wait it's 15.04 not 15.10
[03:58] <Bluefoxicy> and apt does not work
[03:58] <Bluefoxicy> neither does dpkg-reconfigure keyboard-configuration
[06:51] <liuxg> I have a executable binary called fswebcam (/usr/bin/fswebcam) in a snappy package, I want to use it to capture a picture as described in the https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/. I want to use golang to invoke it to capture a picture. How can I do it? currently, I am using the way at https://github.com/liu-xiao-guo/webcam-http/blob/master/api.go, is there anything wrong with it? thanks
[08:17] <fgimenez> good morning
[08:23] <mvo> hey fgimenez, good morning
[08:24] <fgimenez> hi mvo, how's the release going?
[08:27] <mvo> fgimenez: I think we are good, I was reading trello/tg/mail so far only but nothing that looks like a blocker so I will go ahead and do the promotion next
[08:30] <fgimenez> mvo, great! :) let me know if i can be of any help
[10:01] <JamesTait> Good morning all; happy Friday, and happy Kindness Day! 😃
[11:55] <mvo> fgimenez: if you have a moment, it would be great if you could do some smoke testing with the new webdm http://people.canonical.com/~mvo/tmp/webdm_0.10_all.snap
[11:56] <fgimenez> mvo, sure, on it
[12:21] <fgimenez> mvo, i'm getting this on kvm http://paste.ubuntu.com/13247033/, both rolling/edge and 1504/alpha, is it built for armhf?
[12:55] <mvo> fgimenez: checking, sorry, I just had build it before leaving for lunch
[13:43] <mvo> fgimenez: I had a unclean build env that caused this package to be broken, I uploaded a new version now that should be better.
[13:44] <fgimenez> mvo, ok thanks, i'll try it now
[13:45] <mvo> fgimenez: ups, sorry
[13:45] <mvo> fgimenez: the url is not quite correct, one sec
[13:47] <mvo> fgimenez: its actually now http://people.canonical.com/~mvo/tmp/webdm_0.10_multi.snap
[13:59] <fgimenez> mvo, ok thanks
[13:59] <mvo> fgimenez: fwiw, I did a quick test install on my bbb and it was fine
[15:05] <fgimenez> mvo all seems to be working fine except for the remove buttons, with any installed snap/framework, when i try to remove i get "ERROR: snappy package not found"
[15:06] <fgimenez> mvo, this is the body of the response from the server http://paste.ubuntu.com/13247844/, with a 500 error code
[15:09] <fgimenez> the status "uninstalled" is strange, i get this from the list of snaps http://paste.ubuntu.com/13247865/
[15:11] <sergiusens> elopio, https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/1473333/+merge/277412
[15:12] <sergiusens> I fixed all your comments
[15:14] <mvo> fgimenez: hm, interessting. so any removal fails right now. let me try
[15:17] <elopio> sergiusens: needs fixing.
[15:18] <sergiusens> elopio, nah
[15:18] <sergiusens> :-)
[15:19] <elopio> just drop the test. It's friday and QA knows it.
[15:19] <sergiusens> elopio, done ;-)
[15:20] <elopio> (that's a joke, of course. Don't drop the test :)
[15:20] <sergiusens> elopio, too late
[15:20] <sergiusens> elopio, just kidding ;-)
[15:20] <sergiusens> elopio, should be fine now
[15:22] <elopio> sergiusens: +1.
[15:29] <mvo> fgimenez: I can reproduce the error you see
[15:51] <mvo> sergiusens, Chipaca: if someone could help with  https://code.launchpad.net/~mvo/webdm/new-snappy/+merge/277433 that would be cool, hopefully something simple but with that branch fgimenez and I get "Error: snappy package not found" when trying to remove any snap. this seems to be workng ok with 0.9.4
[15:52] <fgimenez> mvo, sergiusens, Chipaca the server returns this http://paste.ubuntu.com/13247844/ with a 500
[15:54] <kyrofa> jdstrand, found another bug in snappy-debug. Is there a place to file bugs/submit MPs?
[16:01] <jdstrand> kyrofa: https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-debug
[16:01] <jdstrand> but just against the snappy project, but an MP is good enough for me
[16:03] <kyrofa> jdstrand, on its way!
[16:03] <kyrofa> ... right after standup
[16:15] <Chipaca> mvo: is it bad if I jot that down as a "do over the weekend" task?
[16:15] <Chipaca> mvo: or is this a blocker?
[16:17] <mvo> Chipaca: never
[16:17] <mvo> Chipaca: no, no not at all
[16:18] <longsleep> Chipaca: Do you have a minute, i might have found an issue with the firstboot service boot order change
[16:18] <mvo> Chipaca: I will see what I can do to control the damage, but only the "edge" channel of webdm is affected
[16:18] <mvo> Chipaca: and once the release is out I should have some cycles again
[16:19] <Chipaca> longsleep: certainly sir
[16:20] <longsleep> Chipaca: problem is that now some snap provided services can run before firstboot
[16:20] <longsleep> Chipaca: To be exact, the services which have no external networking, start on ubuntu-snappy.frameworks.target
[16:21] <sergiusens> Chipaca, mvo fgimenez maybe we can just start using the rest api for removal, DONE ;-)
[16:22] <sergiusens> mvo, oh, this is very specific to webdm and its build against new snappy APIs
[16:23] <Chipaca> longsleep: augh
[16:25] <longsleep> Chipaca: so i think, the snappy services need to wait on firstboot or something, not sure what happens when the frameworks target is run after firstboot instead of after run-hooks
[16:25] <mvo> sergiusens: heh, indeed, maybe I should venture a bit into JS land
[16:26] <longsleep> Chipaca: a crude workaround could be to add a fake external port to the snap which has config applied by firstboot, that makes such snaps to start after snappy-wait4network.service
[16:26] <Chipaca> it's starting to feel like a game of whack-a-mole
[16:26] <Chipaca> but without the cute eep sounds
[16:27] <Chipaca> i need to sit down with graphviz and some patience
[16:27] <Chipaca> or, well, somebody does :)
[16:29] <longsleep> Chipaca: i am adding the ugly details to bug 1511435
[16:32] <kyrofa> jdstrand, https://code.launchpad.net/~kyrofa/snappy-hub/snappy-debug_escape_regex_strings/+merge/277463
[16:37] <jerryG> any1 know about opengl on snappy?
[16:39] <jdstrand> mvo: https://github.com/ubuntu-core/snappy/pull/55#issuecomment-156482348
[16:39] <jdstrand> kyrofa: thanks!
[16:41] <mvo> thanks jdstrand
[16:41] <jdstrand> mvo: thank you :)
[16:41]  * jdstrand hugs mvo
[16:41]  * mvo hugs jdstrand
[16:42] <longsleep> sweet
[16:42] <jerryG> status of opengl support on snappy?
[16:42] <davmor2> jdstrand, mvo: man get a room alerady
[16:42]  * Chipaca hugs mvo and jdstrand
[16:42] <Chipaca> let's land that sucker
[16:42]  * mvo hugs Chipaca and davmor2
[16:42] <Chipaca> davmor2: you're just jealous of our love
[16:43] <longsleep> feel the love in snappy channel
[16:43]  * jdstrand hugs Chipaca, davmor2, mvo (again) and longsleep :)
[16:43] <Chipaca> jerryG: 無
[16:44] <davmor2> okay okay I feel the love, /me hugs everyone
[16:45] <jerryG> Chipaca: 为什么
[16:45] <jerryG> Chipaca: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001114.html
[16:47] <jerryG> Chipaca: :{
[16:49] <Chipaca> jerryG: you asked about “opengl support”. I can't even answer “no” to that question, because the question itself seems to assume things that aren't quite right
[16:49] <Chipaca> jerryG: hence, mu
[16:50] <Chipaca> jerryG: intel architecture snappy ships with the kernel-side gpu drivers, that are one part of what's needed for supporting opengl
[16:51] <Chipaca> jerryG: there is a mir snap, that i think uses those drivers, but would you consider that “opengl support”?
[16:51] <Chipaca> jerryG: there is no X in snappy, for example
[16:51] <Chipaca> jerryG: not today; possibly never? I don't know
[16:52] <jerryG> Chipaca: can i use sdl file with snappy ?
[16:52] <Chipaca> jerryG: what's a sdl file?
[16:56] <richmb> hello?
[16:58] <Chipaca> richmb: o/
[16:58] <zyga> hey
[16:59] <richmb> I had some questions about the apt-get(non-snappy) version of ubuntu core
[17:00] <richmb> https://wiki.ubuntu.com/Core
[17:00] <richmb> this wiki page hasn't been updated in a while, but the releases seem upto date
[17:01] <richmb> is this something that will be continued to be supported?
[17:01] <Chipaca> no idea; i work on snappy itself ¯\_(ツ)_/¯
[17:02] <richmb> we ran into some troubles trying to port snappy, but the ubuntu core rootfs was easy to bring up.
[17:04] <zyga> richmb: what are you porting to??
[17:04] <zyga> s/\?\?/?/
[17:05] <richmb> an Altera Cyclone V arm Soc
[17:05] <richmb> https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki
[17:06] <liuxg> when I am trying to run a snappy command, it complains "another snappy is running, try again later". what is the reason for this? it happened a few times to me.
[17:08] <ogra_> richmb, the ubuntu-core tarball has nothing to do with snappy, it is "just enough OS to run apt in a chroot" and is used for buildds and the like ... a snappy ubuntu-core rootfs has massively different content
[17:08] <ogra_> snappy image currently come fron system-image.ubuntu.com
[17:08] <ogra_> *images
[17:09] <richmb> I understand that.  I wanted to know if the ubuntu-core tarballs would be available for future ubuntu versions.  As the wiki page hasn't been updated in a while.
[17:10] <ogra_> richmb, you have to ask infinity in #ubuntu-devel ... it was never an official product i think
[17:12] <Chipaca> liuxg: every so often a snappy update runs automatically
[17:12] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy list
[17:12] <ogra_> Name        Date       Version Developer
[17:12] <ogra_> ubuntu-core 2015-11-13 3       ubuntu
[17:12] <ogra_> webdm       2015-11-13 0.9.4   canonical
[17:12] <ogra_> pi2         2015-11-13 0.16    canonical
[17:12] <ogra_> mvo, ^^^ looks all fine
[17:12] <liuxg> Chipaca, i really do not want it to update. how can I stop it?
[17:13] <Chipaca> liuxg: from memory: echo 'config: {ubuntu-core: {autoupdate: false}}' | sudo snappy config ubuntu-core - | grep auto
[17:13] <richmb> thanks orga
[17:13] <Chipaca> liuxg: although that might be autopilot instead of autoupdate, depending on what snappy you're running
[17:13] <SaMnCo-desktop> getting the exact same situation, it seems the auto update features are active by default
[17:14] <Chipaca> used to be called autopilot, becase we like confusing people ;-)
[17:14] <Chipaca> SaMnCo-desktop: yes
[17:14] <SaMnCo-desktop> Chipaca-  this is not cool. Back to Windows days where the system would reboot in the middle of an important task?
[17:14] <liuxg> Chipaca, it seems it is an update. at one time, it prompted me there would be reboot sth like that.
[17:15] <Chipaca> liuxg: yep
[17:15] <Chipaca> SaMnCo-desktop: https://github.com/ubuntu-core/snappy/blob/master/docs/autoupdate.md
[17:15] <Chipaca> SaMnCo-desktop: except, as i said, it might be called autopilot instead of autoupdate, depending on what you're running
[17:16] <SaMnCo-desktop> Chipaca-  yeah, I have autopilot on my BBBs and Rpi2
[17:16] <Chipaca> SaMnCo-desktop: and it's exactly like windows, except for everything
[17:16] <Chipaca> SaMnCo-desktop: :-)
[17:16] <SaMnCo-desktop> thx for the link, useful. Still, I would not have a behavior that forces the reboot of the system being active by default
[17:16] <Chipaca> SaMnCo-desktop: i mean, it's an option you can turn off, and it prints out how to abort the reboot if you're logged in
[17:17] <jerryG> Chipaca: sdl file is for opengl.  How do i make an image with intel opengl graphics drivers?
[17:17] <SaMnCo-desktop> What if it's my drone in the sky?
[17:17] <ogra_> SaMnCo-desktop, then turn it off :)
[17:17] <Chipaca> SaMnCo-desktop: if you're putting the default image on a drone in the sky, you're going to have a bad time
[17:17] <SaMnCo-desktop> ogra_-  I understand I can turn it off, I am just saying, something that reboots a device should not be active by default
[17:18] <Chipaca> sigh
[17:18] <liuxg> Chipaca, it will be finished once it is updated, right?
[17:18] <SaMnCo-desktop> but well, we don't have to agree on everything ;)
[17:18] <Chipaca> SaMnCo-desktop: yes, you're saying that. I disagree, because of several things
[17:18] <ogra_> SaMnCo-desktop, if you produce a drone you likely use your own oem snap and will define what config options are on in it
[17:18] <mvo> ogra_: \o/
[17:19] <Chipaca> SaMnCo-desktop: the biggest is that it's not really on by default; it's on if and only if the gadget snap you used to build the image sets it
[17:19] <mvo> ogra_: mail is out
[17:19] <ogra_> mvo, yay
[17:19] <SaMnCo-desktop> Chipaca-  so that means the images on the website have that active by default
[17:19] <Chipaca> SaMnCo-desktop: the default image has it on, because the default image is for developers and clouds, where you most likely want to keep things up to date (and if you don't, you know you don't, and you disable it)
[17:19] <SaMnCo-desktop> I just downloaded them this morning
[17:20] <Chipaca> SaMnCo-desktop: and it's already on a drone in the sky? wow you're fast
[17:20] <SaMnCo-desktop> :D
[17:20] <SaMnCo-desktop> It's just I have 7 devices, downloading tons of stuff, and I didn't know about this thing, and it just means I have to run my scripts all over again
[17:21] <SaMnCo-desktop> and it's slowww to run Docker / LXD stuff on BBBs...
[17:21] <ogra_> err
[17:21] <Chipaca> SaMnCo-desktop: why does an update mean you need to run your scripts again?
[17:21] <ogra_> yes :)
[17:21] <SaMnCo-desktop> Chipaca-  because it downloads stuff
[17:21] <ogra_> everythin is slow on a BBB
[17:22] <ogra_> except actual embedded stuff ...
[17:22] <Chipaca> SaMnCo-desktop: but the download doesn't vanish on update
[17:22] <SaMnCo-desktop> Chipaca-  it does on reboot though
[17:22] <SaMnCo-desktop> anyway
[17:22] <SaMnCo-desktop> that what scripts are for: automate stuff
[17:23] <Chipaca> SaMnCo-desktop: why does the download vanish on reboot?
[17:24] <SaMnCo-desktop> Chipaca-  I'm not following you. I had a docker image running, and a docker pull going on. The update killed Docker
[17:24] <SaMnCo-desktop> as a consequence, both actions went down
[17:24] <SaMnCo-desktop> and now the system is about to reboot. I can catch it (hopefully) but that means the system is not functional anymore
[17:24] <SaMnCo-desktop> and I'll have to restart the commands
[17:25] <SaMnCo-desktop> to start Docker and pull the images I want
[17:25] <Chipaca> ah, the download was interrupted by the reboot, and it doesn't know to resume, now i got it
[17:25] <Chipaca> i thought the download had finished
[17:25] <SaMnCo-desktop> yeah, it's a trivial bash script
[17:25] <SaMnCo-desktop> started remotely
[17:26] <Chipaca> SaMnCo-desktop: well, a few things. one is that if you're on stable, updates are infrequent (not more than once a week, and that's pushing it)
[17:26] <ogra_> well, supposedly once a month actually
[17:26] <Chipaca> SaMnCo-desktop: the other is that you can disable it, but if you do it's on you to run update every so often to make sure you're current
[17:26] <ogra_> we just had a few busy weeks
[17:26] <Chipaca> yeah
[17:27] <Chipaca> i said once a week because i think if we try to do more often than that mvo will undergo a phase change
[17:27] <Chipaca> not sure if he'll melt or just evaporate
[17:27] <Chipaca> but it won't be pretty
[17:27] <SaMnCo-desktop> ok
[17:28] <SaMnCo-desktop> the good side is that I now have a much more clever install / cluster management script for the next batch :)
[17:28] <Chipaca> :)
[17:28] <SaMnCo-desktop> if it had happened while I was afk, I would just have found things broken
[17:28] <SaMnCo-desktop> now I know how to fix it :)
[17:28] <Chipaca> SaMnCo-desktop: also, if you stop the reboot, the system isn't broken or inconsistent
[17:28] <ogra_> you should just put it in a snap
[17:28] <Chipaca> SaMnCo-desktop: the update is separate
[17:29] <SaMnCo-desktop> ogra_-  yep, that's the plan
[17:29] <Chipaca> SaMnCo-desktop: *also* also, note it updates everything, but only system updates cause the reboot
[17:29] <SaMnCo-desktop> but right now it's for my talk at DockerCon, I don't have a lot of time
[17:29] <Chipaca> ok, i'll stop chatting to you and let you get back to cussing the system into shape then
[17:30]  * Chipaca goes for some more tea
[17:30] <SaMnCo-desktop> :D have a good one
[17:33] <longsleep> Reading the changes in the latest 15.04 stable release, what is actually the snappy REST API and how do i accesss it?
[17:33] <longsleep> -s
[18:51] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/97
[19:30] <richmb> Are there any training or classes on snappy that could help with porting.
[19:35] <tedg> richmb: We've done a few Snappy clinics that might help: https://www.youtube.com/playlist?list=PL-qBHd6_LXWYm8qttcXaosAIzejTa5IPj
[19:51] <Chipaca> longsleep: wrt the REST API, hold on
[19:52] <Chipaca> longsleep: there's a pull request with docs
[19:52] <Chipaca> longsleep: but it is going to be revamped for 16.04
[19:53] <Chipaca> longsleep: i'll get you the link of my internet holds up
[19:54] <Chipaca> longsleep: https://github.com/chipaca/snappy/blob/rest-doc/docs/rest.md
[19:55] <Chipaca> longsleep: i'll expect to get to merging that over the weekend, or early next week
[19:56] <Chipaca> longsleep: in particular, the details of how to handle licensed snaps is going to be different real soon now
[21:58] <bago> hi all
[21:59] <frecel> bago: hey
[21:59] <frecel> lool: ping
[22:00] <bago> i have an android smart tv box and was wondering if it's ok to use the raspberry pi2 sd card ubuntu on it?
[22:00] <bago> or the beaglebone 1
[22:01] <bago> it is armv7 (cortex-a5)
[22:01] <frecel> I see no reason why that wouldn't work since it's just another external input
[22:02] <frecel> practically there is no difference between connecting a ps4 and a pi to your tv
[22:04] <bago> so the snappy armhf rpi2 img using win32diskimager should boot from sd?
[22:07] <frecel> bago: oh you just want to plug the sdcard to your tv
[22:07] <frecel> without the rasperry pi itself?
[22:08] <bago> no i want to run a persistent ubuntu on sd card but leave my android intact
[22:08] <bago> i'm not sure what board my tv box has
[22:08] <bago> it seems to be an odroid c1 with a tuner card
[22:10] <bago> would it help if i linked the url to the box?
[22:12] <bago> i basically want to run ubuntu on this http://www.smartvboxs.com/products/Amlogic-S805-Quad-core-1G-8G-Mali-450GPU-Android-4.4-VIGICA-C100S.html#.VkZgNHbhCJA
[22:13] <bago> kodibuntu ideally but ubuntu would be a good start
[22:17] <bago> is it possible to brick my device by trying?
[22:25] <tedg> Yes, and it probably won't work.
[22:25] <tedg> You really need to support the specific board when it comes to ARM stuff.
[22:25] <tedg> It's not like x86 where the CPU and BIOS are rather standardized.
[22:26] <bago> right so i'd have to port it to a new board?
[22:27] <tedg> Correct, what ever CPU/configuration/etc that box is using.
[22:28] <bago> how big would that be for an amateur?
[22:28] <tedg> Reasonably large, but everyone needs to start somewhere. :-)
[22:28] <bago> with a windows pc :)
[22:29] <tedg> But if there's no CynogenMod port or ASOP tree, it'll be nearly impossible.
[22:29] <bago> how would i find out if there is?
[22:29] <tedg> Google :-)
[22:31] <bago> i'm not really sure what board i'd google though tbh :)
[22:35] <bago> i have had openelec boot from sd card so i assume it must be possible, it had no wifi but i think the driver is available it's just it was compiled on a similar device
[22:53] <lool> frecel: pong
[22:54] <frecel> lool: there are rumors going around that you were working on getting snappy to run on an intel edison
[22:54] <frecel> did you have any succes with that?
[22:55] <lool> frecel: yes and no; it's on the "nice to complete someday" list, but I'm happy to give you pointers if you'd like to resurrect
[22:57] <frecel> I bought my edison to try building an ubuntu smartwatch so I would appreciate any help
[22:58] <lool> frecel: so basically the top thing that was missing was initrd loading and someway to repartition the device safely; with latest released image and the new flashing tool, it's all doable, but I didn't have time to assemble an image
[23:01] <frecel> lool: so at it's current state it just get's stuck in a reboot loop?
[23:11] <lool> frecel: there is no current image for edison
[23:19] <frecel> lool: did you document your work so far in any way? I have not done anything like this before so I'm not even entirely sure where to start to be honest
[23:21] <lool> frecel: so the latest bootloader also added support for the external SD card
[23:21] <lool> frecel: I'd start by creating an x86 SD card image and starting snappy manually with intel's kernel + snappy initrd + snappy rootfs from the u-boot prompt
[23:32] <Chipaca> lool: the edison uses uboot?
[23:32] <lool> Chipaca: yes