[06:52] <zyga> good morning
[07:19] <zyga> https://github.com/ubuntu-core/snappy/pull/734
[07:54] <dholbach> good morning
[07:54] <zyga> dholbach: morning :)
[07:57] <dholbach> cześć zyga
[07:57] <dholbach> davidcalle, dpm, popey: https://bugs.launchpad.net/snapcraft/+bug/1537786 :)
[07:57] <zyga> tschus :-)
[07:57] <zyga> (if I recall correctly)
[07:58] <dholbach> tschüss :)
[07:58] <dholbach> but that's goodbye
[07:58] <dpm> morning dholbach, nice!
[07:58] <dholbach> 'hallo' should work though :)
[07:58] <zyga> oohhh
[07:58] <zyga> then I remember poorly :)
[07:58] <zyga> thanks for correcting me
[07:58] <zyga> (that was over a decade ago when I last learned german)
[07:59] <popey> dholbach: ooh
[08:02] <dpm> dholbach, do you happen to know which are the clean steps you can use? It seems the info is missing from 'snapcraft clean --help'
[08:04] <dholbach> dpm, I don't - but I assumed that the bug fix would allow snapcraft to figure out itself what needs updating and what doesn't
[08:06] <dholbach> dpm, ah now...
[08:06] <dholbach>     - pull
[08:06] <dholbach>     - build
[08:06] <dholbach>     - stage
[08:06] <dholbach>     - strip
[08:06] <dholbach>     - snap
[08:06] <dholbach> ^ that's the steps (from: snapcraft help plugins)
[08:21] <dpm> dholbach, thanks. https://github.com/ubuntu-core/snapcraft/pull/403
[08:34] <dholbach> nice one
[08:48] <davidcalle> dholbach: excellent!
[09:41] <Ram_> hi
[09:41] <Ram_> have anyone here ported snappy for an arm device?
[09:42] <ogra_> hey Ram_, yes, i have (multiple times)
[09:42] <Ram_> i'm facing a lot of trouble to do so
[09:43] <ogra_> well, lets go through them and fix them one by one then :)
[09:43] <Ram_> hi ogra! it's ur blog i'm following to achieve that ;)
[09:43] <ogra_> oh, thats very old
[09:43] <ogra_> i will write an up to date entry for 16.04 once it is out
[09:44] <Ram_> that is nice!
[09:44] <ogra_> (there have been very massive changes and 15.04 will be EOL soon)
[09:46] <Ram_> first of all I'm a beginner..
[09:46] <ogra_> we all were once ;)
[09:46] <Ram_> i do things by following the blog to port ubuntu core
[09:46] <ogra_> right, the new setup is not very well documented yet
[09:47] <ogra_> but i would actually recommend to go for 16.04, despite that
[09:48] <Ram_> okay!
[09:49] <Ram_> now i'm using an arm based device, which is having support for kernel v3.14
[09:49] <ogra_> in the new setup everything is a snap package (no more tarballs, even rootfs, kernel and the bootloader some as a snap)
[09:49] <ogra_> to do a port you need a gadget snap (bootloader) and a kernel snap for your device
[09:50] <ogra_> for an arm board you need a working uboot bootloader
[09:50] <ogra_> (we are preparing for boards that use grub too, but are not there yet)
[09:50] <Ram_> i got the u-boot.bin, and uImage
[09:51] <ogra_> did you build the uboot from source ? you will need some patches
[09:52] <ogra_> here is an example of a gadget snap (for the raspberry pi2 in this case) http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/pi2
[09:53] <ogra_> here is the patch that we use (it is just a few config options) http://paste.ubuntu.com/15472180/
[09:53] <ogra_> so first of all, build your uboot with these options enabled
[10:09] <asac> is there a best practice how to add a user needed for a snap on install?
[10:09] <ogra_> i doubt you can
[10:10] <ogra_> (and it would be nonsense, your services run as root and all files are chowned to root when building the snap)
[10:10] <ogra_> (we use the --all-root option to mksquashfs)
[10:12] <asac> hmm. so now i am wondering if this is a prob with my vm setup
[10:12] <asac> i am binding 8021 to 21
[10:12] <asac> and ftp into it then causes stuff like
[10:12] <asac> http://paste.ubuntu.com/15486216/
[10:13]  * asac tries running on same port as the bound port on host
[10:13] <ogra_> "Remote system type is UNIX."
[10:13] <ogra_> just use Linux then it will work
[10:14] <ogra_> *g*
[10:14] <ogra_> how are the file permissions of the dirs you access there ?
[10:14] <asac> those should be fine
[10:14] <asac> i think its because ftp opens new ports
[10:14] <asac> that then have no forward to the vm
[10:14] <asac> but thought passive on would fix that
[10:14] <ogra_> (seems also a bit odd that you end up in the toplevel dir of your snap ....)
[10:14] <asac> seems passive also creates new ports?
[10:15] <asac> !ls
[10:15] <ogra_> hmm, no idea
[10:15] <asac>  !ls shows the local host dir
[10:15] <asac> so thats fine
[10:15] <asac> ok guess i should go for the pi2 then next :)
[10:15] <asac> where i have proper network
[10:15] <asac> and see
[10:15] <ogra_> In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1).
[10:16] <ogra_> http://www.slacksite.com/other/ftp.html
[10:16] <ogra_>     FTP server's port 21 from anywhere (Client initiates connection)
[10:16] <ogra_>     FTP server's port 21 to ports > 1023 (Server responds to client's control port)
[10:16] <ogra_>     FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server)
[10:16] <ogra_>     FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)
[10:17] <ogra_> so you need more ports :)
[10:17] <asac> ok i could force fix this by specifying max abnd min pasv port
[10:17] <asac> saw those entries
[10:17] <asac> well... guess iits time to go beagle or pi2 now anyway
[10:17] <asac> just would love to not use ubuntu user for anonymous :)
[10:17] <asac> but cant create one automatically on install
[10:17] <ogra_> you cant see the ubuntu user from your snap
[10:17] <asac> maybe we should have one user per snap that you can then use for services etc.
[10:17] <ogra_> (i think)
[10:17] <asac> it can
[10:18] <asac> well it cant see the home
[10:18] <asac> buut it can see that that user exists in /etc/passwd
[10:18] <asac> it seems
[10:18] <asac> and tahts all that is needed for this
[10:18] <ogra_> i think jdstrand has a plan for system users in snaps ... but thats likely not 16.04 material
[10:18] <asac> also i ended up unconfined now :)
[10:19] <ogra_> you cant see the user in /etc/passwd, bhecause the user isnt in /etc/passwd ;)
[10:19] <ogra_> nss-extrausers ...
[10:19] <ogra_> i'm not sure how well getent() works ... might be possibel to use that
[10:19] <asac> odd
[10:19] <asac> but it works :)
[10:19] <asac> think its using libc
[10:19] <ogra_> *possible
[10:19] <asac> and that figures it
[10:20] <asac> i cant use a user that isnt avail
[10:20] <asac> but i can use ubuntu :)
[10:20] <asac> as my anon user
[10:20] <ogra_> yeah, then getent likely works
[10:20] <asac> which is good news... just would love to have my own user for that snap as i am using a dir somewhere in /var/lib anyway for the anon uploads
[10:21] <asac> nobody didnt work
[10:21] <asac> because /nonexistent doesnt exist
[10:21] <asac> wodner if i should just hack vsftpd more so it doesnt refuse to use nobody
[10:21] <asac> but *shrug*
[10:22]  * asac goes and turns the pi2 into a box that will go to living room
[10:22] <asac> the orange box one
[10:22] <ogra_> http://paste.ubuntu.com/15486252/
[10:22] <ogra_> thast my old server setup script ... there is also user creation in it
[10:23] <ogra_> (ignore the chfn messages btw)
[10:27] <asac> i must be that folks are stealing usb cables from me at events
[10:27] <asac> i never forsaw that i had troulbes finding one
[10:27] <asac> bought like 20 2-3 years back in a bundle ...
[10:27] <ogra_> heh, thats SD cards for me :)
[10:27] <asac> now i had to use a 20cm long one and the pi2 is hanging in the air
[10:28] <asac> yeah sd cards i accept
[10:28] <asac> but usb cables? wtf
[10:28]  * asac goes to amazon and orders more :)
[10:30] <asac> hmm. my pi2 doesnt see new updates
[10:30] <asac> guess i have to reflash
[10:30] <asac> ubuntu-core         2016-02-03 16.04.0-7.armhf
[10:30] <asac> ubuntu@localhost:~$
[10:30] <asac> that one
[10:30] <asac> getting https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
[10:31] <asac> and a coffee
[10:39] <popey> ogra_: downloaded your pi3 image and put on card, Booted up and the last thing I see on the console is "Started OpenBSD Secure Shell server" and if I ssh in, it asks for my password then hangs
[10:39] <popey> (I had raspbian on this before, so I know the pi itself is fine)
[10:40] <ogra_> popey, hmm, you should get a login prompt
[10:40] <ogra_> i definitely do here
[10:40] <popey> when does it do the partition resize?
[10:40] <popey> it's a 32GB card
[10:40] <ogra_> (i dont if i use the same image on a pi2 ... but thats a different issue)
[10:40] <ogra_> from the initrd
[10:40] <popey> ok
[10:40] <popey> so earlier than this
[10:41] <ogra_> takes about 15sec here for a 128G card
[10:41] <ogra_> so i'd imagine 32G to be really fast
[10:41] <popey> yeah, not that
[10:41] <ogra_> there is definitely a shell on HDMI
[10:41] <popey> yup
[10:41] <ogra_> if you ahve a cable around
[10:42] <popey> i am looking at the output from hdmi
[10:42] <ogra_> oh, i thought you look at serial, sorry :)
[10:43] <ysionneau> any idea on how to "debug" this? http://paste.ubuntu.com/15486342/
[10:43] <ysionneau> how can I understand what's going wrong?
[10:43] <popey> http://i.imgur.com/g5a63oZ.jpg ogra_
[10:43] <ogra_> and ssh with ubuntu:ubuntu doesnt work ?
[10:44] <popey> alan@homeserver:~$ ssh ubuntu@192.168.1.69
[10:44] <popey> ubuntu@192.168.1.69's password:
[10:44] <popey> been sat there for minutes
[10:44] <ogra_> yery weird
[10:45]  * popey reboots
[10:45]  * ogra_ does a fresh flash of his image
[10:45] <popey> i just grabbed the pi xz image you linked to in your mail
[10:46] <ogra_> ysionneau, where is your gadget source tree ?
[10:46] <ogra_> popey, yeah, thats what i'm flashing now
[10:47] <popey> hah, worked this time 😖
[10:47] <popey> i see a login prompt now, but didn't on first boot
[10:47]  * ogra_ will check that 
[10:47] <ysionneau> ogra_: it's not published but here is the content : http://paste.ubuntu.com/15486365/
[10:47] <ogra_> note that cloud-init can take quite long on first boot
[10:48] <ogra_> ysionneau, i guess it looks for a uboot binary somewhere
[10:48] <ogra_> or for a uEnv.txt ...
[10:49] <asac> mvo: is ubuntu-core         2016-02-03 16.04.0-7.armhf canonical
[10:49] <asac> really the latest?
[10:49] <popey> hm. trying to install a snap fails - just did "snap find owncloud" and it sees two results (one from kyrofa) and then if I "snap install owncloud" it just returns immediately and doesn't say anything
[10:49]  * asac apparently cleaned his previous SD for no reason
[10:50] <asac> mvo: nevermind... found and update
[10:50] <asac> mvo: are we doing diff downloads yet?
[10:50] <mvo> asac: if you use rolling/edge you get something newer, its been a while since we did a stable promotion
[10:51] <asac> mvo: so one thing i noticed: http://paste.ubuntu.com/15486382/
[10:51] <mvo> asac: no deltas yet will probably take a couple of weeks still
[10:51] <asac> you guys spit out "reboot" before stuff is synced to disk
[10:51] <asac> would have caused troubles i guess if i hard rebooted at that point
[10:51] <asac> had to wait in sync for 20 secs
[10:51] <mvo> asac: oh, that is interessting. it did not occour to me that people would do hard reboots
[10:51] <asac> could be its fixed in latest of course... thats the feb image in your peopl
[10:51] <mvo> asac: but of course this is a different world
[10:52] <asac> people do everything :)
[10:52] <mvo> it is not fixed, thanks for bringing it up
[10:52] <popey> no power switch on a pi :)
[10:52] <asac> also who knows if they get impatient if reboot command hags for a bit
[10:52] <asac> would be interesting to see how our tx update behaves
[10:52] <asac> if its not fully synched
[10:52] <asac> might try it sometimes when i want to have fun :)
[10:53] <ogra_> popey, so first boot works fine here ... it properly clears the screen and offers me a ligon prompt
[10:53] <ogra_> *login
[10:54] <asac> mvo: i need to update classic by myself right?
[10:54] <popey> hm, odd
[10:54] <asac> or is that now done in backgrounrd?
[10:54] <popey> ogra_: now I can't install any snaps on it
[10:54] <ogra_> ogra@anubis:~/datengrab/rpi3$ md5sum rpi3-all-snap.img.xz
[10:54] <ogra_> 07abd31a72f54cfa0c1ae8241073e3d0  rpi3-all-snap.img.xz
[10:54] <ogra_> popey, yeah, thats normal :P
[10:54] <popey> hah, ooookay
[10:54] <popey> why?
[10:54] <ogra_> snaps are only installable until the next security model renaming :P
[10:54] <popey> 07abd31a72f54cfa0c1ae8241073e3d0  rpi3-all-snap.img.xz
[10:55]  * popey blinks
[10:55] <ogra_> read: kyrofa neesd to update his owncloud snap again
[10:55] <ogra_> interfaces landed yesterday
[10:55] <ogra_> (the new security model)
[10:56] <ogra_> also the rootfs snap is from yesterday morning ... i shoudl probably re-build it with todays rootfs (there might again be more changes)
[11:01] <popey> ahhh
[11:15] <dholbach> davidcalle, I created a branch with the examples for the doc
[11:16] <dholbach> davidcalle, that might make it easier to keep them up to date and allow readers to get them all at once
[11:20] <kyrofa> Good morning
[11:20] <kyrofa> ogra_, ah, thanks for the heads up
[11:21] <kyrofa> ogra_, is that in edge? Or has it gone to stable?
[11:22] <ogra_> not yet in stable
[11:22] <ogra_> stable is weeks old
[11:26] <davidcalle> dholbach: yes of course, thanks :)
[11:28] <davidcalle> dholbach: how do I run a command on a source before starting eg. a cmake building?
[11:28] <dholbach> davidcalle, can you elaborate?
[11:28] <dholbach> or explain what you're trying to do?
[11:29] <davidcalle> dholbach: the source I'm trying should apparently use the autotools plugin, but before it runs ./configure (which is the first thing the autotools plugin does after getting the source), I need to run another command.
[11:32] <dholbach> mh... no idea
[11:33] <dholbach> kyrofa, ^ do you have a solution for such a case?
[11:34] <kyrofa> davidcalle, dholbach perhaps the simplest thing to do would be to ship a custom in-tree plugin that inherits from autotools and does what you want?
[11:35] <dholbach> of course... :)
[11:35] <dholbach> https://developer.ubuntu.com/en/snappy/build-apps/plugins/
[11:35] <dholbach> davidcalle, ^
[11:35] <davidcalle> kyrofa, dholbach: alright, looking into this, thanks :)
[11:37] <kyrofa> davidcalle, are you hitting this? https://bugs.launchpad.net/snapcraft/+bug/1551716
[11:39] <davidcalle> kyrofa: nope, it's just an extra build command that is required by the source
[11:39] <kyrofa> davidcalle, ah, okay interesting. Yeah, the custom plugin is probably the way to go, but that doc sorely needs to be updated. Maybe I'll do that this morning
[11:41] <davidcalle> kyrofa: alright, nothing urgent, I can move on to snapping something else for now, thanks!
[11:41] <davidcalle> (unless I manage to find my way with the doc of course ;) )
[11:43] <kyrofa> davidcalle, just don't worry about the `handle_source_options()` call
[11:43] <kyrofa> davidcalle, and the x-crafty.yaml is now done via the schema function
[11:45] <kyrofa> davidcalle, honestly you can mostly rip this off: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/autotools.py
[11:45] <davidcalle> kyrofa: that's what I'm doing and adding the command I need
[11:45] <kyrofa> davidcalle, perfect
[11:46] <davidcalle> kyrofa: I'll probably look later into doing proper inheritance, though, but I want the build part out of the way for now
[11:48] <ogra_> mvo, should "snappy install --allow-unauthenticated ..." work for os and kernel snaps (doesnt here, i got exclamation marks in snappy list after a reboot)
[11:50] <mvo> ogra_: hm, that should work, what does grub-editenv list output?
[11:50] <davidcalle> kyrofa: how do I define the name of my plugin, with the schema function? Do I still need to keep the plugin yaml file?
[11:50] <ogra_> mvo, no grub on my rpi3 :P
[11:50] <kyrofa> davidcalle, it's determined from the file name
[11:50] <ogra_> looking at serial i see it loading the right kernel on reboot though
[11:51] <davidcalle> kyrofa: alright :)
[11:51] <ogra_> mvo, aha, after a second reboot it is fine
[11:52] <ogra_> so there seems to be something wrong with the sequence
[11:55] <mvo> ogra_: fw_printenv iirc it is then :)
[11:55] <mvo> ogra_: but ok, if you rebooted the output will no longer be interessting
[11:55] <ogra_> http://paste.ubuntu.com/15486754/
[11:56] <ogra_> right ... i'll try tomorrow again :P
[12:07] <ogra_> oh, webdm works again (didnt yesterday)
[12:08] <ogra_> hmm, the store UI changed
[12:18] <kyrofa> Does ubuntu core use ntp?
[12:23] <ogra_> timedated iirc
[12:25] <kyrofa> Ah, I'm not familiar with that
[12:28] <zyga> kyrofa: part of systemd AFAIR
[12:29] <kyrofa> zyga, yeah seems so. Thanks guys!
[12:35] <kyrofa> zyga, ogra_ verified, and network time is on. Perfect
[12:51] <dholbach> dpm, if you rebuild the clock app snap, can you still launch it?
[12:51] <dholbach> I get: aa_change_onexec failed with -1. errmsg: Permission denied
[12:51] <davidcalle> kyrofa: one more question, pulling stage-packages is failing because of a silly "E:Unable to correct problems, you have held broken packages.", is there a container somewhere I can log into to fix this?
[12:52] <kyrofa> davidcalle, huh, no that stuff is way simpler than a container-- the packages are simply downloaded and unpacked. So there must be a dependency issue in the debs you're pulling?
[12:52] <dpm> dholbach, I don't know, I'll have to try next week. Preparing to leave now
[12:52] <dholbach> dpm, ok, sounds good
[12:52] <dholbach> dpm, have a great time!
[12:53] <davidcalle> kyrofa: oh ok, I was assuming it was somehwere special, sounds good
[12:53] <dholbach> davidcalle, is it libubuntutoolkit5 vs libubuntutoolkit5-gles or something?
[12:54] <davidcalle> dholbach: nope, the list being awfully long, I haven't found which one exactly yet :)
[12:54] <jdstrand> ogra_, asac: "i think jdstrand has a plan for system users in snaps" - I don't. the only thought I had was that if we did optional uids for a snap, we'd need seccomp arg filtering
[12:55] <dholbach> davidcalle, ok
[12:55] <ogra_> jdstrand, ah, i thought you wanted to add them inside the snap somehow
[12:56] <jdstrand> I might've mentioned I could imagine yaml to opt-in
[12:56] <kyrofa> davidcalle, maybe fire up an lxc and try to install them all?
[12:56] <jdstrand> but I'm not driving it and there is no design
[12:56] <jdstrand> I did suggest it would be a nice feature
[12:56] <ogra_> i surely dont think snap users should be added to the system passwd db though ... it would have to be some pre-snap overlay thing
[12:56] <ogra_> *per-snap
[12:57] <ogra_> thanks for clearifying though
[13:13] <kyrofa> So jdstrand sounds like interfaces finally landed in edge? If I'm using old-interface's network-listener, what does that become?
[13:16] <jdstrand> plugs: [network]
[13:20] <kyrofa> jdstrand, ah that simplifies things. And network-bind is the service side of it?
[13:20] <jdstrand> indeed
[13:29] <jdstrand> kyrofa: note, those are the only two right now. there are MPs for the other 12
[13:29] <jdstrand> err, PRs
[13:30] <kyrofa> jdstrand, awesome
[15:55] <kyrofa> ogra_, say I want to ship a Snappy-powered device that will be on the open internet. Obviously I don't want to ship with the default ubuntu/ubuntu creds. What is the recommended way of dealing with this?
[15:57] <qengho> kyrofa: There shouldn't be a network listener, right?
[15:57] <ogra_> kyrofa,  we dont have any recommended way yet ...
[15:57] <kyrofa> qengho, well that's a little in flux right now. If running 16.04 edge, it's just the listener interface. If 16.04 stable, it's the network-listener thing
[15:58] <ogra_> technically you shouldnt have ssh running ... practically all 16.04 images currently have it
[15:58] <ogra_> so for now, change the password
[15:58] <kyrofa> ogra_, what if I actually DO want SSH running, but want to lock it down a little more?
[15:59] <qengho> kyrofa: I mean there should be no way for someone to use the default password One Day.
[15:59] <kyrofa> qengho, oh man I totally misunderstood you :P
[16:00] <ogra_> kyrofa, copy a key in place and disable password auth completely in /etc/ssh/ssh_config
[16:00] <kyrofa> ogra_, is that something I can do in the image?
[16:00] <ogra_> manually, yeah
[16:01] <kyrofa> ogra_, kpartx, modify, dd again?
[16:01] <ogra_> nah, after first boot
[16:02] <ogra_> i mean you could kapratx/dd it and all, but it would be the same key everywehere ... so thats a rather useless attempt
[16:02] <ogra_> *kpartx
[16:02] <kyrofa> ogra_, right, duh. Hmm...
[16:13] <dholbach> davidcalle, we should talk on tuesday and figure out how we finish this guide
[16:13] <dholbach> first thing :)
[16:14] <davidcalle> dholbach: +1, I'm interested into reshaping - at least - the intended layout for examples, taking into account evan's email.
[16:15] <dholbach> yep
[16:16] <davidcalle> dholbach: first thing coming to mind is a list of "I want to ... " bullet points and one example for each need we recognize.
[16:17] <dholbach> +1
[16:36] <renat> Hi guys! It's Renat from Screenly=)
[16:39] <renat> I'm trying to run our programs on the new built image and getting "seccomp_load failed with -22" error
[16:39] <beuno> jdstrand, ^
[16:40] <qengho> renat: do your programs uses seccomp filters, inside?
[16:40] <jdstrand> I know the problem
[16:41] <jdstrand> renat: does it work if you uninstall the snap and then reinstall?
[16:41] <renat> beuno, qengho, jdstrand, hello=)
[16:41] <jdstrand> hi :)
[16:41] <renat> let me try to reinstall it
[16:43] <renat> jdstrand, no. didn't help
[16:43] <rajen> Hi, Is there any 16.04 Snappy documentation available. All the documentation on https://developer.ubuntu.com/en/snappy/guides/ points to 15.04 model
[16:43] <jdstrand> renat: can you paste the output of 'cat /var/lib/snappy/seccomp/profiles/<snapname>...' into paste.ubuntu.com?
[16:43] <renat> qengho, yes. I set up it for other app using plugs system
[16:44] <renat> jdstrand, sure. 3 min
[16:45] <renat> jdstrand, https://paste.ubuntu.com/15488307/
[16:46] <jdstrand> interesting, that isn't what I expected to see
[16:46] <jdstrand> renat: can you paste the output of 'grep audit /var/log/syslog'
[16:46] <renat> It used to work with older image I built
[16:48] <renat> jdstrand, https://paste.ubuntu.com/15488327/
[16:48] <qengho> renat: those parts are stirred often, in development.
[16:50] <qengho> "brk" is a dangerous syscall? So, malloc doesn't work?
[16:50] <jdstrand> qengho: I think you misread that
[16:51] <jdstrand> # end dangerous syscalls
[16:51] <jdstrand> ...
[16:51] <jdstrand> brk
[16:51] <jdstrand> we allow brk
[16:51] <renat> Yes, brk is allowed.
[16:52] <jdstrand> renat: if you do 'cat /var/lib/snappy/seccomp/profiles/<snapname>...' is there a final newline?
[16:52] <renat> jdstrand, 2 newlines=)
[16:52] <jdstrand> ok
[16:52] <jdstrand> let me try to reproduce locally
[16:53] <jdstrand> renat: can you paste the output of 'snappy info'
[16:54] <qengho> Oh!
[16:54] <renat> jdstrand ubuntu@localhost:~$ sudo snappy info
[16:54] <renat> release: core/rolling
[16:54] <renat> architecture: armhf
[16:54] <renat> frameworks:
[16:54] <renat> apps: screenly-client.sideload
[16:54] <renat> ubuntu@localhost:~$ sudo snappy info
[16:54] <renat> release: core/rolling
[16:54] <renat> architecture: armhf
[16:54] <renat> frameworks:
[16:54] <renat> apps: screenly-client.sideload
[16:54] <renat> https://paste.ubuntu.com/15488370/
[16:54] <renat> Oh.... Sorry
[16:54] <jdstrand> no worries
[16:54] <jdstrand> what about snappy list?
[16:55] <renat> https://paste.ubuntu.com/15488375/
[16:55] <ogra_> i think i saw such an error from the core launcher these days ... havent seen it again with newer images though
[16:55] <renat> screenly-oem-pi2 is an image bult from canonical-pi2.canonical version 3.2
[16:56] <renat> Hello, ogra_!
[16:56] <ogra_> hey
[16:56] <ysionneau> I added the uboot.env but it's still failing :x
[16:56] <ysionneau> I tried to read the strace results ... I could not get the reason clearly
[16:56] <renat> I'm trying with older image. 10 min.
[16:57] <ogra_> renat, canonical-pi2.canonical is a gadget snap ... i was talking about later ubuntu-core
[16:57] <jdstrand> renat: what is the output of sha256sum /usr/bin/ubuntu-core-launcher
[16:58] <renat> ogra_, understood. I use ubuntu-core snap automatically downloaded during the build process.
[16:59] <ogra_> right, thats a rather old one
[17:00] <ogra_> (somewhere around feb.)
[17:01] <jdstrand> ogra_: hey, I have a core/rolling image, but it is using the os snap from monday. is there a newer os snap somewhere? how would I generate an image to use it?
[17:01] <jdstrand> renat: 11:57 < jdstrand> renat: what is the output of sha256sum /usr/bin/ubuntu-core-launcher
[17:02] <jdstrand> renat: (on the broken image)
[17:02] <jdstrand> ogra_: this is for qemu amd64
[17:02] <renat> jdstrand, 5 min please. I'm re-flashing an image=(
[17:03] <ogra_> jdstrand, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ :)
[17:03] <ogra_> (indeed onyl for sideloading ... )
[17:06] <jdstrand> ogra_: is xenial-preinstalled-core-amd64.tar.gz a qemu raw image?
[17:06] <ogra_> jdstrand, no, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-amd64.os.snap is an ubuntu-core os snap :)
[17:07] <jdstrand> ogra_: I'm able to sideload that in a running image?
[17:07] <ogra_> not sure if that works on one where it was initially not sideloaded ...
[17:07] <ogra_> it works on my locally built one with a simple "sudo snappy install --allow-unatuthenticated ..."
[17:08] <jdstrand> ok
[17:08] <jdstrand> and same with the kernel?
[17:08] <ogra_> yep
[17:08] <jdstrand> ok, let me try that
[17:09] <jdstrand> shoot it does't work
[17:09] <jdstrand> /tmp/xenial-preinstalled-core-amd64.os.snap failed to install: package "ubuntu-core" is already installed with developer "canonical" your developer is "sideload"
[17:10] <jdstrand> ogra_: how do I generate an image from those snaps?
[17:10] <jdstrand> sorry, I've not had to do this before
[17:10] <ogra_> use mvo's u-d-f
[17:10] <renat> jdstrand, aa74d0040f626c2d090ae99d1534924cf6d4e905f5939fbadf179eff3950f12a  /usr/bin/ubuntu-core-launcher
[17:11] <jdstrand> renat: this is on an image that is busted?
[17:11] <ogra_> with --gadget pointing to canonical-pc ... --os ponting to the os snap and --kernel pointing to canonical-pc-linux or a downloaded kernel snap
[17:11] <renat> jdstrand, yes. That image doesn't work
[17:11] <jdstrand> renat: ok, I'm going to try to reproduce locally
[17:11] <renat> I tried with older image, and it worked successfully. So it's not related to screenly-client snap.
[17:12] <jdstrand> ogra_: thanks, where is canonical-pc?
[17:12] <ogra_> in the store
[17:12] <renat> jdstrand, thanks. I built that image today. Less than 4 hours ago.
[17:12] <ogra_> just use --gadget canonical-pc
[17:12] <jdstrand> oh and it'll fetch it
[17:12] <jdstrand> ok
[17:12] <ogra_> it shoudl download it
[17:12] <jdstrand> ogra_: http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash ?
[17:13] <ogra_> yep
[17:17] <ogra_> ysionneau, could be that u-d-f checks for an existing boot-assets dir in the gadget snap ... try moving your uboot.env file in such a subdir (and adjust the snap.yaml)
[17:18] <ysionneau> ah ok, will try thanks
[17:18] <ysionneau> those stuff really should be documented (but I know it's in the pipe :p)
[17:19] <ogra_> itsd not onyl in the pipe, it is also supposed to change (again)
[17:19] <ogra_> EEEK !
[17:19] <ogra_> CPP     xbmc/ApplicationPlayer.o
[17:19] <ogra_> g++: internal compiler error: Killed (program cc1plus)
[17:19] <ogra_> Please submit a full bug report,
[17:19] <ogra_> with preprocessed source if appropriate.
[17:19] <ogra_> *sniff*
[17:19] <ogra_> that was after 4h compiling kodi on the rpi3 :(
[17:19] <ysionneau> 18:17 < ogra_> ysionneau, could be that u-d-f checks for an existing boot-assets dir in the gadget snap ... try moving your uboot.env file in such a subdir  < I've just tried, same error
[17:20] <jdstrand> hrmm
[17:20] <jdstrand> ogra_: --gadget canonical-pc
[17:20] <jdstrand> Determining gadget configuration
[17:20] <jdstrand> expected 1 gadget snaps, found 0
[17:20] <ogra_> jdstrand, try appending .canonical
[17:20] <ogra_> i thought that was aliased
[17:20] <ysionneau> ogra_: that's where cross compilation is convenient :p
[17:20] <ogra_> ysionneau, nah
[17:21] <jdstrand> that did it
[17:21] <jdstrand> thanks!
[17:21] <ogra_> it would be the same toolchain ... wouldnt help
[17:21] <ogra_> (not with an ICE at least)
[17:21] <ysionneau> it would help for the "after 4h compiling" :p
[17:21] <ogra_> yeah, its not like i am in a hurry :)
[17:21] <renat> Guys, could you tell, please, where can I find snap download uris for os and kernel snaps?
[17:22] <ogra_> the build just runs on the side on an unused pi3 ;)
[17:22] <renat> I found couple by "guessing". https://public.apps.ubuntu.com/anon/download/canonical/ubuntu-core.canonical/ubuntu-core.canonical_16.04+20160321.17-37_armhf.snap
[17:22] <ogra_> renat, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the dailies
[17:22] <ogra_> for an rpi you want xenial-preinstalled-core-armhf.raspi2.kernel.snap  and xenial-preinstalled-core-armhf.os.snap
[17:23] <renat> Ahh... Really? They used to work before=)
[17:23] <renat> ogra_, let me try. Thanks!
[17:24] <ogra_> the others you posted work too
[17:24] <ogra_> (they are the same, just uploaded to the store by hand ... so they are usually a few days older )
[17:32] <jdstrand> renat: ok, using the kernel and os snaps in http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ I cannot reproduce on amd64
[17:34] <renat> jdstrand, thanks. I will try re-create snaps. Let me see if that snaps will fix the issue.
[17:35] <jdstrand> renat: I think what happened is you grabbed a new kernel snap and an old os snap. the ubuntu-core-launcher needs to be 1.0.20 to work with the latest Ubuntu kernels. we'll see what your snaps say
[17:35] <jdstrand> s/snaps/new flash/
[18:07] <renat> jdstrand, how can I know ubuntu-core-launcher version?
[18:08] <renat> Unfortunately - it still doesn't work with the same error.
[18:09] <jdstrand> renat: that is why I asked for the sha256sum
[18:09] <jdstrand> renat: actually, there is a manifest file
[18:09] <jdstrand> renat: is this what you used: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.manifest
[18:10] <jdstrand> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.os.snap
[18:10] <renat> Yes. This is the file I used to build image.
[18:10] <renat> The 2nd one.
[18:11] <jdstrand> can you do sha256sum /usr/bin/ubuntu-core-launcher again?
[18:11] <renat> https://paste.ubuntu.com/15489051/
[18:12] <renat> 837ab5d35b9d2f757ef85ce51a10bd6084c5b122af829e3fe12ebef35af7cee3  /usr/bin/ubuntu-core-launcher
[18:13] <jdstrand> ok, that is what is in 1.0.20
[18:13] <jdstrand> renat: since this is a whole new image, can you paste the output of 'cat /var/lib/snappy/seccomp/<snap>...
[18:15] <renat> Sire
[18:15] <renat> Sure
[18:17] <renat> jdstrand, https://paste.ubuntu.com/15489090/
[18:17] <jdstrand> ok
[18:18] <jdstrand> renat: can you paste the output of 'grep audit /var/log/syslog'?
[18:18] <renat> jdstrand, which kernel version should I use to work with previous versions of ubuntu-device-flash tool?
[18:19] <renat> https://paste.ubuntu.com/15489095/
[18:19] <jdstrand> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.raspi2.kernel.snap should be fine
[18:21] <jdstrand> renat: can you file a bug?
[18:21] <renat> jdstrand, yes. I will investigate the issue a little first.
[18:21] <renat> Thanks for help.
[18:21] <renat> Disconnecting.
[18:21] <jdstrand> renat: one other thing
[18:22] <jdstrand> renat: can you install the hello-world app, then run hello-world.env?
[18:22] <renat> Doing
[18:23] <renat> The same error, jdstrand
[18:23] <jdstrand> ok, then it isn't your app
[18:24] <jdstrand> renat: actually, I can lead you through a rather complicated process to see if it is the launcher
[18:24] <jdstrand> renat: do you have time?
[18:50] <rootx_> hello