[00:03] <qengho> mariogrip: You might be able to. snapcraft is gaining the functionality, though not many plugins support it yet. The python plugin probably does the right thing (if no compiling!), but doesn't signal that it's right.
[00:03] <qengho> mariogrip: How involved do you want to get?
[00:07] <qengho> mariogrip: If not compiling, you can hack into the python2.py a new function.  def set_target_machine(self, machine): pass
[00:08] <qengho> That probably makes recent snapcraft work for you.
[00:08] <mariogrip> qengho: I tried architectures: [amd64, armhf] but when I try to install it on my rpi2 it fails to install
[00:08] <mariogrip> missing /tmp/* folder somehow
[00:08] <qengho> mariogrip: was that with "--target-arch armhf" ?
[00:10] <mariogrip> qengho: no I added  architectures: [amd64, armhf]  to snapcraft.yaml file and it made myapp_0.1_multi.snap
[00:12] <mariogrip> myapp_0.1_multi.snap failed to install: open /tmp/read-file088244561/unpack/meta/package.yaml: no such file or directory
[00:13] <qengho> mariogrip: Oh. Hrm. Sorry -- that is a bit of a mystery to me. I thought you were creating a specific arch snap from a different arch.
[00:23] <mariogrip> qengho: oh, I first thought i had to do that, since it outputted just amd64.snap when I ran it the first time
[00:28] <qengho> mariogrip: My suggestion above might not work, but I think it has a decent chance.  "snapcraft --help" and add that function to the python2 plugin.
[00:28] <qengho> that function is "set_target_machine".
[00:28] <qengho> ^^^^^^
[00:30] <mariogrip> qengho: I'll give it a try
[00:30] <qengho> mariogrip: My suggestion also implies removing the "architectures:" line from snapcraft.yaml .
[00:30] <qengho> ...I think.
[00:31] <qengho> mariogrip: I'm not an expert in this.
[00:34] <mariogrip> qengho: no difference, still says octoprint_0.1_multi.snap failed to install: open /tmp/read-file015824556/unpack/meta/package.yaml: no such file or directory when i try to install it :( but thanks anyway :)
[00:35] <qengho> mariogrip: that "multi.snap" part sounds suspicious, like you didn't change snapcraft.yaml, and did you use --target-arch ?
[00:36] <mariogrip> no, it was just an old copypaste i had, it says _amd64
[00:36] <mariogrip> I did not use --target-arch
[00:37] <qengho> :\
[00:37] <mariogrip> I haven't tried it on amd64. so it might be broken there also
[00:38] <mariogrip> the command snappy does not exist after an update for some reason
[00:38] <mariogrip> on my host
[00:38] <qengho> mariogrip: if your filename isn't "myapp_0.1_armhf.snap", then it's not going to work on an armhf machine, I bet.
[00:38] <qengho> mariogrip: "snappy" name is dead. Use "snap".
[00:39] <qengho> Bed time! Zzzz.
[00:39] <mariogrip> oh, i use snappy on my rpi... that might be why
[00:40] <mariogrip> the "new" snap uses xz tarballs....
[00:41] <qengho> The new new snap doesn't use tarballs at all.
[00:42] <mariogrip> that's might be why snappy install does not work with my app...
[00:43] <mariogrip> it worked with snap
[00:43] <qengho> mariogrip: Are you using 16.04 images?
[00:43] <mariogrip> yes
[00:43] <mariogrip> then, how do i make snap packages for snappy install
[00:44] <qengho> Your snapcraft should be v2. It should make squashfs images. They should install with "snap" (not snappy) on 16.04 snappy images.
[00:45] <qengho> mariogrip: A lof of that^ is new as of the last 6 weeks or so.
[00:45] <mariogrip> how do i build v1 packages?
[00:46] <qengho> I don't know. I think you need the kind of snapcraft and snappy that was in 15.10.
[00:46] <qengho> I don't think a v1 package would be good for very long. It was a kind of rough draft.
[00:47] <mariogrip> ah, ok. ill see if i find newer rpi images that has snap insted of snappy
[00:47] <mariogrip> qengho: thanks for your help :)
[00:49] <qengho> mariogrip: Welcome! I'm sorry it wasn't obvious. When your snapcraft v2 is making files with "armhf" in the name, you should be able to install those on rpi machines that have a "snap" command. That's what I think. Good luck.
[03:26] <NAto> good evening, anybody home?
[06:03] <netphreak> hi, guys!
[06:22] <dholbach> good morning
[06:44] <Gunther_> Good morning! Sorry to bother irc with this, but can anybody help me with this: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001729.html ?
[07:50] <davidcalle> Morning o/
[08:01] <shuduo> morning.
[08:02] <shuduo> i try to use u-d-f all-snaps version from ~people/mvo but it can't found gadget snap today. may i know what's wrong?
[08:03] <zyga> good morning
[08:37] <mvo> shuduo: there is a store bug currently that prevents u-d-f from working, sorry for that
[08:38] <mvo> shuduo: we are working on a fix or workaround currently
[08:38] <noizer> good morning
[08:40] <shuduo> mvo, may i know if there is an ETA for fix? we have some customers are evaluating 1604 image
[08:41] <mvo> shuduo: we aim for a fix/workaround by the end of today (so ~12h or so)
[08:42] <mvo> shuduo: unfortunately its not entriely trivial to fix
[08:42] <shuduo> mvo good to know. thanks!
[08:44] <shuduo> mvo: good luck
[08:55] <asac> o/
[08:56]  * asac wonders if the 4.4 kernel got ever rolled to stable channel for pi2 or if its a bug that i dont get that update
[09:42] <davidcalle> Trying to run snaps today results in "unable to bind /snap/ubuntu-core/current//lib32 to /lib32. errmsg: No such file or directory"
[10:02] <davmor2> ogra_: I just did snap install ubuntu-clock-app should I now see it somewhere on the system?
[10:05] <mvo> shuduo: I pushed a new u-d-f with a workaround for the store issue. note that you will need to build "edge" images with that and e.g. firstboot is not fully working yet
[10:06] <shuduo> mvo: okay. let me try it
[10:13] <ogra_> davmor2, afaik it shold install a.desktop file so you should find it in a dash search
[10:13] <davmor2> ogra_: nope
[10:14] <ogra_> asac, 16.04 never had an actual stable release
[10:14] <ogra_> you want the edge channel, that has 4.4 since months
[10:16] <shuduo> mvo: unfortunately new u-d-f does not work too. I ran it few times. once it report TLS timoeout. rest outputs same msg
[10:17] <mvo> shuduo: what commandline do you use?
[10:17] <shuduo> sudo ../ubuntu-device-flash core rolling --channel edge --gadget canonical-pi2.canonical --kernel canonical-pi2-linux.canonical --os ubuntu-core.canonical --verbose --developer-mode --enable-ssh -o rp2-test.img
[10:18] <mvo> shuduo: please drop the ".canonical" from the snaps and try again
[10:19] <ogra_> and you dont need --enable-ssh anymore
[10:20] <ogra_> (it is always enabled atm)
[10:20] <shuduo> mvo: it is working now. so no more .canonical in future? then I need update such information to others
[10:20] <ogra_> yes, there are a lot docs that need updating now :(
[10:21] <mvo> shuduo: yes
[10:23] <shuduo> mvo, will you update another version in next few days? then I can update all-working version to customer later since today is Friday. :)
[10:24] <mvo> shuduo: I am working on the fix right now, maybe in some minutes
[10:24] <shuduo> mvo good
[10:26] <ogra_> mvo, on that note, should we perhaps do a snapshot of all snaps to stable so we have at least an alpha quality image by release ?
[10:27] <ogra_> (i think we released one chunk to stable a few months ago which keeps people like asac stuck on old versions
[10:27] <ogra_> )
[10:29] <mvo> ogra_: yes, I think we should do that plus new alpha images
[10:29] <ogra_> mvo, i see there is still a snapd issue ... so after that landed ?
[10:29] <mvo> ogra_: which one?
[10:29] <mvo> ogra_: oh, the store bug
[10:29] <mvo> ogra_: yes
[10:30] <mvo> ogra_: that needs to land
[10:30] <ogra_> mvo, no, the migration
[10:30] <ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd
[10:31] <mvo> shuduo: please try again
[10:31] <shuduo> mvo: okay
[10:31] <mvo> ogra_: yeah, this is a issue because the autopkgtest environment does not allow access to the store
[10:32] <ogra_> mvo, right, i was just thinking we want the latest snapd in the images :)
[10:32] <ogra_> bfore pushing any buttons
[10:32] <mvo> yes
[10:36] <ogra_> ppisati, any chance that we see https://launchpad.net/ubuntu/+source/linux-meta-snapdragon/4.4.0.1009.1 land before the weekend ? there are livecd-rootfs changes that need to happen alongside to not forcefully pull from the PPA
[10:38] <cjwatson> mariogrip: Sounds to me like you might be better served by getting Launchpad to build the snap for you, since it supports all the combinations you're looking for.
[10:40] <ppisati> ogra_: it's more of an archive thing
[10:40] <ogra_> you mean some AA reviewing it ?
[10:40] <ppisati> ogra_: try to hassle an AA guy
[10:41] <ppisati> ogra_: it looks like it's in proposed
[10:41] <ogra_> yes
[10:41] <ogra_> since a while already
[10:41] <ppisati> ogra_: so it needs to be copied
[10:41] <ogra_> i just want to get rid of the hack in livecd-rootfs before release :)
[10:41] <ppisati> yeah, i understand
[10:42] <ppisati> ogra_: as soon as rtg / infinity show up, try to hassle them
[10:42] <mvo> !
[10:42] <ogra_> ?
[10:44] <ogra_> ppisati, hmm bug 1567379 is referred to by the excuses page ... and there is still a Canonical Kernel Team task that is only Confirmed
[10:44] <shuduo> mvo: i download again but seems it's same as previous one. md5sum is 4d582e995383d5a83f58e2e4a166ae19. can you let me know if it's that one?
[10:56] <mvo> shuduo: I pushed an updated version of the os snap that fixes the network failure I had in the previous image build
[10:58] <shuduo> mvo: may i know if it's for RPi2 only or also solved problem in x86?
[10:58] <mvo> shuduo: sorry, only amd64, let me fix rpi2
[11:00] <shuduo> mvo: okay.
[11:01] <mvo> shuduo: try now
[11:01] <mvo> shuduo: please
[11:02]  * mvo gets lunch
[11:02] <shuduo> mvo: still edge? will stable be fixed soon?
[11:04] <ogra_> shuduo, see above ... we'll do an alpha release to stable before release day
[11:04] <ogra_> (release is next week, so within the next 7 days)
[11:04] <shuduo> ogra_: okay. thanks.
[11:06] <ogra_> note though that there are still tons of changes pending for the next months (currently networking wont be configured because the config interface is completely gone til a re-implementation is ready)
[11:07] <ogra_> so the alpha you will get in stable might behave worse whan the months outdated stable image you would get today
[11:07] <ogra_> s/whan/than/
[11:16] <dholbach> davidcalle, looks like clock app can't connect to network manager or geoclue
[11:16] <dholbach> but that's about it
[11:16] <dholbach> mvo, nice work!
[11:17] <davidcalle> mvo: \o/
[11:24] <popey> dholbach: so kodi now produces a ton of apparmor denials.
[11:24] <popey> which is different
[11:24] <popey> davidcalle: also, thanks for telling me about apparmor notify
[11:45] <dholbach> and it didn't before?
[11:49] <popey> no, it would black screen and libgl error
[11:49] <popey> i added the opengl plug and now it fails with apparmor, I pastebinned into the snap this sheet for the record
[11:50] <popey> (I class this as progess)  😃
[11:58] <ogra_> ARGH !
[11:58] <ogra_> where is sergio
[11:59] <davmor2> ogra_: hiding from you
[11:59] <ogra_> yeah :(
[12:00] <zyga> ogra_: what's up?
[12:00] <ogra_> snapcraft 2.8 breaks image builds on s390x
[12:00] <ogra_> http://paste.ubuntu.com/15848428/
[12:14] <kyrofa> Good morning
[12:15] <ogra_> morning kyrofa
[12:15] <ogra_> kyrofa, do you know if sergio is out today ?
[12:16] <kyrofa> ogra_, I don't believe so, but he may be sleeping in a little-- it's been a long week!
[12:16] <ogra_> yeah
[12:16] <ogra_> sadly he broke snapcraft on s390x :(
[12:16] <ogra_> (which makes images fail)
[12:16] <kyrofa> 2.8?
[12:16] <ogra_> yeah
[12:16] <kyrofa> Trying to install cross-compilers?
[12:17] <ogra_> the issue looks liek it is trivially missing the arch name
[12:17] <ogra_> http://paste.ubuntu.com/15848428/
[12:17] <ogra_> KeyError: 's390x'
[12:18] <kyrofa> ogra_, ah, easy fix. And good timing, we're about to crank out 2.8.1 (2.8 sadly broke on several archs)
[12:19] <ogra_> heh, image builds only broke on that one arch ... all others are happily building along
[12:19] <kyrofa> ogra_, hmm... that's interesting. My run on arm busted trying to install cross compilers that didn't exist
[12:19] <ogra_> are they a hard dependency ?
[12:20] <kyrofa> ogra_, no, it was a bug
[12:20] <ogra_> i only run "apt-get install -y snapcraft" in the builds
[12:20] <kyrofa> ogra_, ah, no it's determined at runtime
[12:20] <ogra_> and then call "snapcraft snap snap"
[12:20] <ogra_> (for a pre-created dir structure)
[12:20] <ogra_> so that doesnt hit me then :)
[12:20] <kyrofa> Oh, that's probably it then
[12:20] <kyrofa> You already have the dir
[12:21] <ogra_> yeah
[12:21] <kyrofa> Lucky ;)
[12:21] <ogra_> for os snap thats easier to do :)
[12:21] <kyrofa> ogra_, mind making a bug fo rme? I'll make sure this is in 2.8.1
[12:21] <ogra_> ok
[12:22] <kyrofa> Morning sergiusens :)
[12:24] <ogra_> kyrofa, bug 1570835
[12:24] <kyrofa> Thanks ogra_!
[12:24] <kyrofa> And sorry about that
[12:24] <ogra_> no worries
[12:24] <ogra_> (i doubt that arch has many users :P )
[12:25] <shuduo-afk> ogra_, mvo i ran the new amd64 image in virt-manager. i can see snappy command exist but just snap. is it a new change? then how to use classic dimension?
[12:26] <ogra_> shuduo, yes, the snappy command is effectively gone (there are more bits that just vanished with this change for the moment ... they will come back in the next weeks)
[12:27] <ogra_> to use the classic dimension "sudo snap enable-classic" should still work
[12:27] <ogra_> stgraber, that reminds me, where do we stand with arm64 support for snappy classic ?
[12:28] <shuduo> ogra_: snap tell me enable-classic is unknown command...
[12:29] <shuduo> error: Unknown command `enable-classic'. Please specify one command of: ack, connect, disconnect, find, install, interfaces, known, list, login, purge, refresh or remove
[12:29] <ogra_> oh ? that usedf to work for me two days ago ... perhaps it has also been dropped then
[12:29] <ogra_> you are on the edge channel, right ?
[12:29] <shuduo> ogra_: yes
[12:29] <ogra_> (stable is pretty much useless atm)
[12:32] <zyga> jdstrand: I got devel mode to work :)
[12:32] <jdstrand> zyga: yay! did you use @complain for seccomp?
[12:33] <zyga> jdstrand: chceking :)
[12:33] <zyga> jdstrand: I ran hello-world.evil :)
[12:33] <zyga> jdstrand: yes, first line of seccomp is @complain
[12:33] <zyga> jdstrand: then the normal profile follows
[12:33] <zyga> jdstrand: I guess we have a winner :D
[12:34] <jdstrand> I ask cause I did an upload for ubuntu-core-launcher to support @complain (currently a synonym for @unrestricted until we can work out how to make seccomp actually complain)
[12:34] <jdstrand> this way you don't have to change snappy
[12:34] <zyga> jdstrand: yep, I saw the changelog
[12:34] <jdstrand> cool
[12:34] <shuduo> ogra_: so snappy and classic will come back in next week*S*. that means all customers evaluation be blocked in next weeks. :(
[12:34] <zyga> jdstrand: I think this will be a good release WRT security and interfaces
[12:35] <zyga> jdstrand: I'll try to spare a moment on the bluez interface when this lands
[12:35] <jdstrand> oh, it made it into the archive
[12:35] <jdstrand> nice
[12:35] <zyga> jdstrand: but I still have a few TODOs
[12:35] <zyga> jdstrand: do you know if anything that is in the store that didn't work before is public?
[12:36] <zyga> jdstrand: can I install something (without sideloading) that would show this to work?
[12:36] <zyga> jdstrand: (for x11 stuff, hello-world.evil works already)
[12:36] <jdstrand> zyga: 'this' meaning bluez?
[12:36] <jdstrand> what are we talking about?
[12:36] <zyga> jdstrand: no, I mean devel mode still
[12:36] <zyga> jdstrand: I;d like to see x apps working, with devel mode
[12:37] <jdstrand> I don't think anything in the store would work
[12:37] <jdstrand> because they are all using old-security
[12:37] <jdstrand> actually
[12:37] <jdstrand> that may work
[12:37] <jdstrand> since old-security gives you default confinement without unity7
[12:37] <jdstrand> zyga: ubuntu-calculator-app?
[12:37] <ogra_> shuduo, well, the "snappy 1.0" release is still a bit away and all fiocus has been moved to snappy on server/desktop installs for the 16.04 release ...
[12:37] <zyga> ohh
[12:38] <zyga> good idea
[12:38] <zyga> though that will work with confinement AFAIR
[12:38] <jdstrand> it shouldn't
[12:38] <jdstrand> unless you brought back old-security
[12:38] <jdstrand> the last I looked the uploads used security-template to get them to work
[12:38] <zyga> ah, right
[12:38] <zyga> I faked it to have unity7
[12:38] <zyga> :D
[12:38] <zyga> last Friday
[12:39] <jdstrand> ah
[12:39] <zyga> but that's gone now
[12:39] <shuduo> ogra_: yes, i understand. but we have few customer want to demo pre-release snappy early
[12:39] <ogra_> i definitely still have snap enable-classic here on an install from the 11th
[12:40] <ogra_> ubuntu@localhost:~$ snap
[12:40] <ogra_> error: Please specify one command of: ack, connect, destroy-classic, disconnect, enable-classic, find, install, interfaces, known, list, login, purge, refresh, remove or shell
[12:40] <shuduo> ogra_: i just use latest u-d-f to generate fresh new image from edge channel
[12:41] <ogra_> yeah, must have been dropped within the last few days
[12:41] <shuduo> ubuntu-core        16.04+20160415.05-01
[12:43] <ogra_> i dont really see that mentioned in any of the changelogs though
[12:45] <shuduo> ogra_: that's fine. i will communicate with customer a little more about "we are working on make snappy back" :)
[12:49] <josepht> ogra_: 9025e4b56b425ee11bc37216ff8551ce17101135 seems to be the commit that removed enable-classic.
[12:49] <ogra_> josepht, hmm, no changelog entry in the package
[12:59] <jdstrand> popey: what app did you try with opengl?
[13:02] <popey> jdstrand: kodi
[13:02] <popey> jdstrand: and Love
[13:05] <popey> jdstrand: basically copied your unity7/opengl plug entries for those two (and pushed)
[13:06] <jdstrand> popey: great. I updated the notes for kodi just now
[13:07] <jdstrand> popey: can you paste the apparmor denial (if any) for love in the pastebin in the spreadsheet?
[13:08] <popey> jdstrand: done
[13:08] <popey> also tried mame, which the mame.ini I can fix, not sure about the fontconfig
[13:09] <jdstrand> that's what I was afraid of
[13:10] <jdstrand> popey: I updated the love Notes
[13:10] <qengho> Isn't there a newer rpi2 image tham mvo's 4-February?
[13:10] <popey> jdstrand: against what? apparmor?
[13:10] <jdstrand> popey: I don't know how to solve /var/cache/fontconfig either. I think we need a desktop person to comment
[13:10] <ogra_> qengho, just build one yourself :)
[13:11] <qengho> Ah, ogra, you have a pi3 image! That's better.
[13:11] <jdstrand> popey: cause allowing 'w'rite access to a directory that the user can't write to is wrong (/var/cache/fontconfig/ unix perms won't allow writing to it)
[13:11] <jdstrand> popey: no, against snapd
[13:12] <qengho> Hmm, build one myself. Okay!
[13:12] <jdstrand> the interface needs to be updated
[13:12] <jdstrand> popey: ((almost) all apparmor policy is in snapd now)
[13:13] <ogra_> qengho, sudo ../ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2  -o test.img
[13:14] <ogra_> (with the latest u-d-f from mvo's all-snaps dir
[13:14] <ogra_> )
[13:14] <mvo> hey jdstrand, good morning
[13:14] <jdstrand> mvo: oh yes, you had something for me to look at
[13:14] <jdstrand> mvo: hi!
[13:15] <mvo> ogra_: with todays upload we should be able to do new images (once that upload is in the archive and we have os snaps from it)
[13:15] <mvo> jdstrand: yeah, no rush, its probably a sru at this point
[13:15] <ogra_> mvo, is enable-classic gone completely now ?
[13:15] <mvo> ogra_: just disabled for now, will come back RSN
[13:15] <ogra_> (thats rather bad for developers i guess)
[13:15] <ogra_> ok
[13:16] <mvo> yes, sorry, scarifices had to be made
[13:16] <ogra_> heh
[13:16]  * ogra_ wishes they had been made a month or two ago :P )
[13:16]  * mvo hugs ogra_
[13:16]  * ogra_ hugs mvo 
[13:19] <popey> jdstrand:
[13:19] <popey> gah, jdstrand https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860
[13:21] <zyga> jdstrand: ubuntu-calculator-app works
[13:26] <jdstrand> zyga: works in developer and does not without developer?
[13:26] <zyga> jdstrand: developer mode
[13:26] <jdstrand> nice
[13:28] <jdstrand> niemeyer, zyga: fyi, bug #1570860. while we can talk about the bug itself, I wanted to nail down the process for updating/adding interfaces. should there be a bug tag (eg, snapd-interfaces?). If a tag, we should all three of us subscribe to it
[13:28] <kyrofa> mvo, is SNAP_ARCH stable in the wrappers? And available on the desktop?
[13:33] <zyga> jdstrand: do we do anything with the device cgroup when we see @complain ?
[13:33] <zyga> jdstrand: as in, not jail the process from real devices?
[13:36] <jdstrand> zyga: no. @complain is a seccomp only thing like '(complain)' is an apparmor thing
[13:36] <mvo> kyrofa: yes, its fine, we do not plan to change the environment vars at this point, if its not in the deprecated sections its golden
[13:36] <zyga> jdstrand: right, so developer mode will be incomplete
[13:36] <zyga> jdstrand: for lots of stuff :/
[13:36] <zyga> jdstrand: I just tried it and a sample game doesn't start
[13:36] <zyga> jdstrand: what could we do to make that work still?
[13:37] <jdstrand> zyga: each security subsystem will need to do its own complain thing. a simple way to do it with udev is to comment out the rules in /etc/udev/rules.d/... for the app in complain mode
[13:37] <zyga> jdstrand: I don't understand how that would work, can you give me an example/
[13:37] <zyga> jdstrand: as in, how can I put *all* devices into a cgroup/
[13:37] <zyga> jdstrand: so that effectively, the app can always open anything in /dev
[13:37] <jdstrand> don't do that
[13:38] <jdstrand> remove the cgroup handling
[13:38] <zyga> jdstrand: wait, there is no cgroup handling right now
[13:38] <zyga> jdstrand: we don't make a default udev rule
[13:38] <jdstrand> remember, cgroups are only used if there is a udev assignment for the app in /etc/udev/rules.d
[13:38] <zyga> AAAH
[13:38] <jdstrand> zyga: right
[13:38] <zyga> okay
[13:38] <zyga> hmm, that's worrying then :)
[13:38] <jdstrand> so, complain mode is simply comment those rules
[13:38] <zyga> because the app still doesn't work
[13:38] <zyga> but at least I will see why
[13:38] <zyga> thanks for explaining thta!
[13:39] <jdstrand> np
[13:39] <kyrofa> Thanks mvo :)
[13:39] <jdstrand> is there an image with ubuntu-core-launcher 1.0.25.1?
[13:39] <jdstrand> mvo: maybe that is a question for you ^
[13:40] <jdstrand> zyga: are there denials? how is the app complaining?
[13:40] <mvo> jdstrand: the latest ubuntu-core snap should have it, let me double check. you can build the image yourself or I can upload one
[13:40] <zyga> jdstrand: the app just doesn't start
[13:40] <zyga> jdstrand: it's an opengl/openal game
[13:40] <zyga> jdstrand: as for syslog...
[13:40] <zyga> one sec
[13:40] <mvo> jdstrand: hm, not yet, let me build one
[13:41] <jdstrand> zyga: in addition to syslog, application output
[13:41] <zyga> jdstrand: no app output
[13:41] <zyga> jdstrand: I'd have to trace it to see
[13:41] <zyga> jdstrand: one sec
[13:41] <jdstrand> zyga: is there a seccomp kill?
[13:42] <jdstrand> perhaps you don't have seccomp 1.0.25.1
[13:42] <jdstrand> err
[13:42] <jdstrand> ubuntu-core-launcher 1.0.25.1
[13:42]  * jdstrand is wildly guessing
[13:42] <zyga> jdstrand: http://pastebin.ubuntu.com/15849375/
[13:42] <jdstrand> zyga: what game?
[13:42] <zyga> jdstrand: FEZ
[13:42] <zyga> jdstrand: I have a snap if you want to see it in private
[13:43] <jdstrand> yes, that would be good. between that and mvo's image, I can help
[13:45] <mvo> zyga: opengl? you are not on an nvivia system, are you?
[13:45] <zyga> mvo: I am
[13:45] <zyga> mvo: ah, I need something fresher (core?)
[13:45] <jdstrand> also, I noticed that the opengl interface doesn't have a test case
[13:45] <mvo> zyga: nvidia (with nvidia proprietary drive)
[13:46] <davidcalle> zyga: do you happen to have a snapcraft.yaml for it?
[13:46] <zyga> mvo: with free drivers
[13:46] <mvo> zyga: ok, that should work, let me try that
[13:46] <zyga> davidcalle: yes but it depends on having access to FEZ binary from humble bundle
[13:46]  * zyga should find a smaller example
[13:47] <davidcalle> zyga: yeah, I imagine, but it will be a great desktop example for dev.ubuntu.com, please share :) (I don't need the bin - I have it)
[13:47] <zyga> davidcalle: sure
[13:47] <zyga> davidcalle: I plan to snap about a dozen games I have
[13:47] <mvo> jdstrand: I have not looked at the tests in detail but when I looked last I found them to be duplicating what was already tested in the commonInterface code, i.e. nothing new was tested but maybe that has changed from when I looked last
[13:48] <davidcalle> zyga: :)
[13:48] <zyga> davidcalle: http://paste.ubuntu.com/15849436/
[13:48] <zyga> davidcalle: there's also a setup/ directory with
[13:48] <zyga> oh
[13:48] <zyga> i wonder if we generate desktop files
[13:49] <davidcalle> zyga: we supposedly do, haven't seen one, though
[13:49] <zyga> yep
[13:49] <zyga> I don't see one either
[13:49]  * zyga looks at what is needed
[13:49] <zyga> davidcalle: I'll share it when I have something really working :)
[13:49] <davidcalle> zyga: sure :)
[13:49] <jdstrand> mvo: I think that might be a discussion point for interface development
[13:50] <zyga> mvo: I think that we could drop most of the tests for commonInterface-using interfaces
[13:50] <mvo> jdstrand: yeah, happy to talk about it when the releas e is out
[13:51] <mvo> zyga: that was my feeling too, but its not important at this point :)
[13:51] <zyga> yep
[13:51] <mvo> just wanted to explain why I did not add new ones for this particular code
[13:53] <mvo> zyga: hm, the opengl using snap, could you push that somewhere?
[13:53] <mvo> zyga: so that I can try to reproduce the issue you see?
[13:54] <zyga> mvo: I use git to manage i, do you have a place I can stick a 350MB git repo?
[13:54] <zyga> a private launchpad git repo perhaps
[13:54] <mvo> zyga: hmmm, let me think for a sec
[13:54] <zyga> could be useful for storing games for development
[13:54] <zyga> this just for work *cough*
[13:54] <zyga> ;-)
[13:55] <popey> zyga: might be worth snappifying open source ones first
[13:56] <popey> rather than going for ones that are hard for others to contribute to
[13:56] <mvo> dholbach: could someone upload a new ubuntu-clock-app with the unity7,opengl interfaces ? that would be great
[13:56] <niemeyer> jdstrand: Having a tag sounds good
[13:56] <mvo> dholbach: and same for the calculator
[13:57] <zyga> popey: this was just a personal snap, I agree that using an open source one would be better but this one was useful for me and I had the game around; I'm not aware of any open source games actually (except openttd which is heavy on plugins)
[13:57] <popey> I've been snappifying a few
[13:57] <zyga> mvo: calculator now works with --devmode :)
[13:57] <ogra_> tuxracer :)
[13:57] <popey> zyga: in fact I find it preferable to hit things that have bigger impact, like frameworks
[13:57] <popey> or emulators
[13:57] <popey> because they add multiple games all at once.
[13:57] <popey> e.g. MAME and Love2D are the ones I looked at.
[13:58] <popey> along with Minetest
[14:01] <zyga> popey: I totally agree :)
[14:01] <popey> should my app have read access to $SNAP?
[14:01] <popey> because I put an ini file in there, but the app can't seem to see it. no apparmor denials
[14:01] <zyga> I think snapcraft has a bug somewhere
[14:01] <zyga> http://paste.ubuntu.com/15849583/
[14:01] <zyga> this is find . from the snap/ directory
[14:02] <zyga> what is $HOME/.../lib and lib64 doing there?
[14:02] <zyga> any snapcraft hackers around ^^^
[14:03] <mvo> zyga: nice
[14:03] <jdstrand> niemeyer, zyga: I added 'snapd-interface' to the bug. I just went to https://bugs.launchpad.net/ubuntu/+subscriptions and added a subscription to subscribe to the snapd-interface tag
[14:03]  * jdstrand does the same for https://bugs.launchpad.net/snappy/+subscriptions
[14:04] <zyga> jdstrand: how do I do that?
[14:04] <zyga> jdstrand: I don't see anything reltated to tags there
[14:04] <zyga> jdstrand: ah, I see
[14:04] <zyga> :)
[14:04] <jdstrand> zyga: select 'are added or changed in any way', then select 'bug must match this filter'
[14:05] <zyga> jdstrand: yep, I got that now
[14:05] <zyga> neat
[14:05] <zyga> I've been using launchapd since day one and I never sawthat
[14:05] <jdstrand> yeah, it wasn't there on day one :)
[14:05] <jdstrand> I forget when it came along, but I jumped on it when it did
[14:06] <zyga> snapcraft also generated this wrapper:
[14:06] <zyga> export LD_LIBRARY_PATH="$SNAP$SNAP/fez/lib:$SNAP$SNAP/fez/lib64:$LD_LIBRARY_PATH"
[14:06] <zyga> note the $SNAP$SNAP
[14:06] <zyga> 2nd snapcraft bug, the game may not launch simply because of those things
[14:09] <popey> davidcalle: got 5 mins to cast an eye on my mamedeb snap (latest snappy-playpen)? Dunno what I'm doing wrong here
[14:09] <popey>  /snap/mame/0/bin/launcher: 14: exec: /snap/mame/0/usr/games/mame -v -inipath /snap/mame/0: not found
[14:14] <morphis> jdstrand, zyga: started to confine network-manager now, but also getting
[14:14] <morphis> Apr 15 14:09:02 localhost.localdomain ubuntu-core-launcher[1180]: appname snap.network-manager.NetworkManager not allowed
[14:14] <davidcalle> popey: looking
[14:14] <morphis> jdstrand, zyga: suspect there is something wrong with the name but don't see what
[14:15] <jdstrand> hmm
[14:15] <jdstrand> can I see your snap yaml?
[14:15] <zyga> morphis: you cannot use dashes?
[14:15] <jdstrand> dashes have always been allowed
[14:16] <zyga> morphis: ah, no
[14:16] <morphis> jdstrand: sure
[14:16] <qengho> I use dashes. Confirmed they work.
[14:16] <zyga> morphis: all-lowr-case
[14:16] <zyga> morphis: use network-manager
[14:16] <zyga> morphis: and perhaps cli as 2nd ap
[14:16] <kyrofa> zyga, looks like whatever you snapped has an ldd linking to that lib, so snapcraft copied it in for you
[14:16] <zyga> morphis: this will give you network-manager (just like that) as the main app and network-manager.cli as a 2nd app
[14:16] <morphis> zyga, jdstrand: https://paste.ubuntu.com/15849745/
[14:17] <zyga> kyrofa: via rpath?
[14:17] <zyga> kyrofa: thanks, that's neat, just unexpected :)
[14:17] <kyrofa> zyga, the strip step crawls ldd
[14:17] <kyrofa> for every elf
[14:17] <jdstrand> const char *whitelist_re = "^[a-z0-9][a-z0-9+._-]+$";
[14:17] <jdstrand> we aren't allowing caps
[14:17] <morphis> I see
[14:17] <morphis> but if I remember well that worked before
[14:17] <qengho> "x----------------" is okay?
[14:18] <morphis> so the calculate of the appname must have changed
[14:18] <jdstrand> it may have
[14:18] <zyga> qengho: no, AFAIR it won't be allowed by snappy itself
[14:18] <kyrofa> zyga, yeah in most cases if you're using library-only stage-packages you can get rid of them and just use the -dev as a build-package and it'll be taken care of
[14:18] <zyga> kyrofa: this is a prebuilt game
[14:18] <zyga> kyrofa: I'm just packaging the binary bits as they are
[14:18] <morphis> jdstrand: thanks
[14:19] <qengho> zyga: is that wildcat, proof of concept, or Official™?
[14:19] <zyga> qengho: ?
[14:19] <kyrofa> zyga, mind pastebining ldd of whatever is linking to fez/lib/libmono?
[14:19] <qengho> zyga: that F game. Just curious.
[14:20] <zyga> qengho: ah, just a private snap for local testing
[14:20] <zyga> qengho: faster then downloading snaps all the time
[14:20] <jdstrand> morphis: so, right now use lower case
[14:20] <jdstrand> docs/meta.md is silent on the issue of if caps should be allowed
[14:20] <jdstrand> (for 'command')
[14:20] <zyga> kyrofa: http://paste.ubuntu.com/15849806/
[14:20] <morphis> jdstrand: ok
[14:21] <zyga> kyrofa: looking at the elf file now...
[14:21] <zyga>  0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/lib64]
[14:21] <zyga> hah
[14:21] <kyrofa> zyga, yeah, is that an rpath with origin?
[14:21] <kyrofa> Ah
[14:21] <zyga> so $ORIGIN is fooling snapcraft
[14:21] <zyga> :D
[14:21] <kyrofa> Indeed it is
[14:21] <kyrofa> Please log that bug
[14:21]  * zyga loves quirky elf features
[14:21] <kyrofa> Though I'm curious how we're going to deal with that...
[14:22] <zyga> kyrofa: there are more things like ORIGIN :)
[14:22] <zyga> kyrofa: I'd readelf the header myself
[14:22] <kyrofa> zyga, yeah we may have to
[14:22] <davidcalle> popey: when building the launcher part: No such file or directory: '/home/david/Desktop/snappy-playpen/mame/mamedeb/parts/launcher/build/mame.ini'
[14:22] <zyga> kyrofa: or assume that $ORIGIN expands to $(cwd) and undo the translation
[14:22] <zyga> anyway, I need to focus on my last branch for snappy today that's not started :
[14:22] <zyga> kyrofa: on github or lp?
[14:22] <kyrofa> zyga, LP please
[14:23] <davidcalle> popey: do you have a mame.ini you need to bzr add?
[14:23] <jdstrand> so, validateField is not correct for command
[14:23] <kyrofa> zyga, https://bugs.launchpad.net/snapcraft
[14:23] <popey> davidcalle: ahh, balls i need to add that to bzr
[14:23] <popey> one moment
[14:23] <davidcalle> popey: no bin/launcher either
[14:23] <morphis> zyga: are dashes allowed in interface names?
[14:23] <zyga> morphis: yes
[14:23] <morphis> ok
[14:24] <popey> davidcalle: it's launcher, it gets copied to bin/launcher
[14:24] <popey> it is there
[14:24] <davidcalle> Oh right :)
[14:24] <popey> davidcalle: pushed mame.ini
[14:25] <davidcalle> ack
[14:25] <popey> davidcalle: note the app works fine if you run it manually, outside of confinement with "/snap/mame/0/usr/games/mame -v -inipath /snap/mame/0"
[14:26] <zyga> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1570895
[14:26] <kyrofa> Thanks zyga :)
[14:27] <zyga> kyrofa: my pleasure :)
[14:27] <zyga> I'd like to snap my collection of GOG games
[14:27] <zyga> I think that would be a nice demo for some people
[14:31] <kyrofa> ogra_, if I were cross-compiling an s390x kernel what would I use as the ARCH? Just s390x?
[14:42] <qengho> Where's the bugtracker for myapps site?
[14:42] <davidcalle> popey: same error hee, your launcher lgtm :(
[14:43] <qengho> Oh, nevermind.
[14:43] <popey> davidcalle: odd, isn't it?
[14:48] <ogra_> kyrofa, i guess so
[14:49] <kyrofa> ogra_, how about the triplet on that system?
[14:50] <ogra_> i have no clue :)
[14:50] <ogra_> ask xnox perhaps
[14:50] <kyrofa> ogra_, heh. I've never even heard of this arch :P
[14:50] <ogra_> its a big black cabinet ;)
[14:50] <kyrofa> Hahaha
[14:50] <jdstrand> morphis (fyi mvo): bug #1570914
[14:51] <xnox> kyrofa, $ dpkg-architecture -as390x
[14:52] <kyrofa> xnox, perfect thank you :)
[14:52] <xnox> kyrofa, also note the https://wiki.debian.org/ArchitectureSpecificsMemo
[14:53] <kyrofa> xnox, favorited
[15:07] <kyrofa> ogra_, any chance you're in a position to try out a snapcraft branch?
[15:07] <kyrofa> ogra_, or is it all automated?
[15:08] <ogra_> i have no idea how you guys land snapcraft usually :)
[15:08] <ogra_> if there is a PPA build, we can copy it into the image PPA to do a test build
[15:08] <ogra_> (of an image)
[15:08] <kyrofa> ogra_, we just land to xenial universe nowadays
[15:09] <ogra_> well, the image PPA is my onlöy way to inject something into the build
[15:10] <kyrofa> ogra_, can I download whatever you're trying to snap?
[15:10] <kyrofa> Oh but it's running on a different arch, scratch that
[15:10] <ogra_> right
[15:10] <ogra_> it runs natively on x390s
[15:11] <ogra_> to test it we need to upload a newer snapcraft to the PPA and run an image build
[15:12]  * kyrofa wishes he had ssh access to one machine of every arch we support
[15:22] <jdstrand> beuno: can someone pull r630 to the store for bug #1570914
[15:22] <jdstrand> beuno: any time before release is fine
[15:27] <code1o6>  Hey guys I'm looking for manik
[15:27] <code1o6> has anyone seen him
[15:27] <beuno> roadmr, ^^^
[15:27] <roadmr> let's see
[15:28] <roadmr> beuno, jdstrand : sure, I'll get that rolling. It being a Friday, is it OK if this hits prod on e.g. Monday?
[15:28] <beuno> roadmr, yeah, of course
[15:29] <kyrofa> ogra_`, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/461 when you're able? Just to make sure those values look sane
[15:29] <roadmr> ok, working on it
[15:31] <ogra_`> kyrofa, hmm, dont you still want the gcc- prefix there ?
[15:31] <kyrofa> ogra_`, for the prefix? Isn't is the prefix _before_ "gcc" ?
[15:31] <ogra_`> (also, isnt it powerpc64el ?)
[15:31] <ogra_`> err
[15:32] <ogra_`> le
[15:33] <ogra_`> i see gcc-powerpc-linux-gnu gcc-powerpc64le-linux-gnu (on wily though)
[15:34] <kyrofa> ogra_`, yeah I get these from gcc-powerpc64-linux-gnu on xenial... but you're right, there are others as well
[15:34] <kyrofa> Hmm...
[15:34] <ogra_`> apt-cache search linux-gnu|grep ^gcc-[a-z]
[15:35] <kyrofa> ogra_`, yeah you're right
[15:35] <kyrofa> ogra_`, I need the el/le whatever one
[15:35] <ogra_`> yeah
[15:35] <kyrofa> Good catch!
[15:35] <ogra_`> :)
[15:35] <kyrofa> The rest look okay?
[15:35] <ogra_`> is there more than the one line ?
[15:36] <kyrofa> ogra_`, mainly the s390x entry
[15:36] <ogra_`> oh ... wasnt on the discussion page
[15:36] <kyrofa> ogra_`, here: https://github.com/ubuntu-core/snapcraft/pull/461/files#diff-4ce66781f48931ad7dc4792aaf9cbf9aR58
[15:37] <mvo> thanks jdstrand! are you on a fix for this already or shall I have a look?
[15:37] <kyrofa> ogra_`, now that I know the ppc stuff is totally broken I'll extract into another bug
[15:37] <ogra_`> kyrofa, the s390x part looks ok to me
[15:38] <kyrofa> ogra_`, okay very good, thank you!
[15:48] <mvo> jdstrand: the latest os snap in edge has the right ubuntu-core-launcher now
[15:48] <mvo> jdstrand: 1.0.25.1
[15:54] <jdstrand> mvo: woohoo! thanks :)
[15:55] <jdstrand> mvo: fyi, I just uploaded 1.0.26 for bug #1570914
[15:56] <mvo> jdstrand: \o/
[15:56] <jdstrand> mvo: there needs to be an input validation change in snapd that I wasn't planning on doing now (feel free to pick it up). see the bug for details
[15:56] <jdstrand> I think with the review tools change it would be ok to pick up in sru
[15:57] <jdstrand> so if you are working on urgent stuff, I suggest doing that instead
[15:57] <mvo> yes, I think so too
[15:57] <jdstrand> cool
[16:20] <jdstrand> mvo: curious, when is udf in the archive going to be updated for all snaps?
[16:20] <technocaveman> when was snappy ubuntu core released
[16:20] <technocaveman> ?
[16:22] <kyrofa> technocaveman, snappy ubuntu core 15.04 was released back with 15.04, but the newest version is based on 16.04 so it's technically not yet released
[16:23] <technocaveman> ok thanks i just needed to know for an assignment in which i mention it !
[16:24] <mvo> jdstrand: once the kernel/gadget yaml is finalized, so via an sru
[16:25] <ogra_`> jdstrand, in time for 18.04 ;)
[16:28] <morphis> jdstrand: thanks for filing that bug
[16:30] <ogra_`> mvo, we shlould perhaps also disable the system-image stuff ... else people will use the udf from the archive and wonder why they have so broken images :)
[16:30] <ogra_`> (though that can as well happen right after release)
[16:31] <zyga> jdstrand: recvfrom is not in network?
[16:32] <zyga> hmm, it is
[16:32] <zyga> hmm
[16:32] <zyga> jdstrand: kwi 15 18:32:35 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1460737955.225:449): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=25760 comm="TerrariaServer." exe="/snap/terraria-server/0/TerrariaServer.bin.x86" sig=31 arch=40000003 syscall=45 compat=1 ip=0xf7786f19 code=0x0
[16:33] <zyga> jdstrand: is that recvfrom or are my eyes fooling me?
[16:33] <mvo> ogra_`: the one from older archives you mean? good idea. xenial is fully disabled I think
[16:34] <ogra_`> mvo, yeah, we should delete the whole rolling subdir on the server though
[16:34] <mvo> +1
[16:35] <ogra_`> the last 16.04 images there are from jan 12 :)
[16:59] <jdstrand> zyga: recvfrom is in x11, bluez, firewall-control, network-bind, unity7 and network
[16:59] <zyga> jdstrand: yep, I've checked
[16:59] <jdstrand> zyga: scmp_sys_resolver 45
[16:59] <jdstrand> recvfrom
[16:59] <zyga> jdstrand: hmm
[16:59] <jdstrand> this is on amd64?
[17:00] <jdstrand> seems something didn't connect?
[17:00] <zyga> jdstrand: no, it connected, it was in the generated profile
[17:01] <zyga> jdstrand: anyway, ignore this
[17:01] <zyga> jdstrand: we'll tweak this later
[17:04] <jdstrand> morphis: np
[17:04] <morphis> jdstrand: working my way now through getting the network-manager snap back working, will come with some questions next week :-)
[17:05] <jdstrand> great :)
[17:07] <jdstrand> mvo: fyi, I just tried ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-bbb.img --gadget canonical-bbb --kernel canonical-bbb-linux --os ubuntu-core stable. is that supposed to work?
[17:09]  * jdstrand wonders what --size should be with bbb and rpi2 images
[17:09] <jdstrand> ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-pi2.img --gadget canonical-pi2 --kernel canonical-pi2-linux --os ubuntu-core stable didn't work either
[17:10] <jdstrand> I feel like I'm looking in the right part of the store...
[17:10] <jdstrand> oh maybe those need .canonical?
[17:11] <jdstrand> oh, no, I used 'stable' by mistake
[17:11] <jdstrand> nm
[17:12] <jdstrand> actually, --gadget canonical-bbb --kernel canonical-bbb-linux doesn't work
[17:13] <popey> are we going to get an official rpi3 image soon?
[17:14] <zyga> popey: ogra said "maybe"
[17:14] <jdstrand> mvo: both canonical-bbb and canonical-bbb-linux are in the store but seems they aren't published (they show yellow instead of green in the Progress column)
[17:14] <ogra_> popey, well, images are still a post 16.04 thing since gadget and kernel will be completely re-designed
[17:15] <ogra_> i might update it next week though
[17:15] <ogra_> (the one we have)
[17:24] <popey> awesome.
[17:24] <popey> look forward to updating my pis
[18:12] <kyrofa> ogra_, you still around?
[18:13] <ogra_> yep
[18:14]  * ogra_ is upgrading his laptop to xenial ... i might unconditionally disconnect from my ircproxy :) 
[18:15] <kyrofa> ogra_, I want to test out the kernel plugin. Any chance you know of a tree already setup for building kernel snaps that I can clone?
[18:15] <ogra_> only the 96boards one that is used in the example
[18:15] <kyrofa> ogra_, yeah that's the only one I know of as well
[18:16] <ogra_> but theoretically any kernel tree should work, no ?
[18:17] <kyrofa> Theoretically, yes
[18:17] <kyrofa> I'll go download the firmware for the 96boards one, since it's a known working one
[18:17] <ogra_> yeah
[18:24] <ogra_> bah, crap
[18:24] <ogra_> no more xchat in xenial !
[18:24]  * ogra_ has to live with the uglyness of xchat-gnome :((((
[18:25] <kyrofa> ogra_, nooooo
[18:26] <ogra_> crap ...
[18:26] <kyrofa> ogra_, any idea why?
[18:26] <ogra_> i think it is dead upstream and nobody ported it to a recent gtk version
[18:26] <kyrofa> Ah, too bad
[18:26] <mdeslaur> ogra_: try hexchat, it's an xchat fork
[18:26] <ogra_> this gnome thing has really to much white around it for my taste
[18:27] <ogra_> mdeslaur, will it just read my old config ?
[18:27] <mdeslaur> ogra_: I'm not sure, perhaps just need to rename the directory
[18:27]  * mdeslaur uses xchat-gnome
[18:33]  * ogra_ hugs mdeslaur 
[18:33] <ogra_> copying some files around and i have my old colorscheme in hexchat
[18:33] <mdeslaur> nice
[18:34] <zyga> hexchat?
[18:35] <zyga> ogra_: have you tried snapping it?
[18:35] <ogra_> heh, no
[18:36] <ogra_> hmm, a bit irritating that it actually adds real transparency ... xchat only had a fake mode
[18:36] <ogra_> suddenly there are icons :P
[18:37] <ogra_> (the few on my desktop)
[19:28] <mvo> jdstrand: yes, we have no canonical-bbb, just a beagleblack.mvo
[19:34] <jdstrand> mvo: huh, I saw something called canonical-bbb in the store
[19:42] <ogra_> jdstrand, not published
[19:42] <ogra_> it idles around there along with a bunch of other zombies
[19:43] <ogra_> (under the shared store account)
[19:43] <ogra_> sadly there is no remove button in the UI ...
[19:48] <jdstrand> I see
[19:48] <jdstrand> ogra_: is there a bbb kernel snap?
[19:49] <ogra_> jdstrand, the generic armhf one
[19:49] <ogra_> grmpf ... so virtulbox doesnt run anymore
[19:49] <jdstrand> cool, I'll update our docs
[19:50] <ogra_> dunno what the exact name is now
[19:50] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.kernel.snap would be the input file for it
[20:07] <mvo> jdstrand: yes, I uploaded it without knowing that we do not want it with this publisher
[20:07] <mvo> jdstrand: and yeah, I wish there was a remove button
[20:21] <ssweeny> It seems the snappy-debug snap needs to be updated: ubuntu@localhost:~$ sudo snap install snappy-debug
[20:21] <ssweeny> [-] Mount snap "snappy-debug"
[20:21] <ssweeny> error: cannot perform the following tasks:
[20:21] <ssweeny> - Mount snap "snappy-debug" (info failed for /tmp/snappy-debug383863688: open /tmp/read-file693482311/unpack/meta/snap.yaml: no such file or directory)
[20:50] <jdstrand> ogra_, mvo: ok (sorry, just trying to update the security team's documentation): this generated an image (didn't try to boot yet): ../udf/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-bbb.img --gadget beagleblack --kernel ./xenial-preinstalled-core-armhf.kernel.snap --os ubuntu-core rolling
[20:50] <jdstrand> ogra_, mvo: great! I was wondering if ./xenial-preinstalled-core-armhf.kernel.snap is in the store?
[20:52] <mvo> jdstrand: there is linux-armhf(.mvo ) in the store
[20:52] <mvo> jdstrand: that should work, not sure how recent it is though, I'm a bit behing with the image maintenance
[20:52] <jdstrand> mvo: sure, that's fine
[20:52] <jdstrand> mvo: do we expect linux-armhf to be regularly updated once things settle down?
[20:52] <ogra_> mvo, do i need to generate a different snap.yaml so you can use the cdimage snap ?
[20:53] <mvo> ogra_: probably, it does not have to be linux-armhf.mvo, it could be anyone…
[20:53] <josepht> mvo: you should be able to at least unplublish it, right?
[20:54] <mvo> jdstrand: a good question
[20:54] <mvo> jdstrand: I think so, but having something group maintained would be much better
[20:54] <mvo> josepht: yes, I can unpublish it
[20:55] <jdstrand> mvo: iirc, that is something of a community kernel. it seems that if there was automation that took security updates to the Ubuntu generic kernel and autosnapped these linux-foo kernels, that could be pretty painless for you and useful for people
[20:56] <ogra_> jdstrand, that is what the cdimage snaps are for
[20:56] <ogra_> there is just no autoupload yet
[20:57] <jdstrand> ogra_: ah, sounds like it is all in hand then :)
[20:57] <jdstrand> nice :)
[20:57] <mvo> jdstrand: yeah, exactly, its just a manual upload at this point
[20:57] <jdstrand> we are getting out of the me documenting things and into I'd like to use my bbb territory here :)
[20:58] <ogra_> elopio sid he has an easy jenkins way of uploading ... still need to talk to him about that
[20:58] <jdstrand> ok, well, it is late where you are-- don't let me distract you
[20:58] <jdstrand> have a nice rest of the evening and weekend ogra_ and mvo :)
[20:58] <ogra_> thanks, you too !
[20:58] <mvo> jdstrand: thanks, you too!
[20:58]  * mvo hugs jdstrand
[20:58]  * jdstrand hugs mvo and snaps ogra_ in the process
[20:59] <jdstrand> :)
[21:00] <ogra_> :)
[21:01] <jdstrand> oh heh
[21:01] <jdstrand> snags*
[21:01] <jdstrand> clearly I have been doing a lot of snappin' lately :)
[21:02] <ogra_> we all have :)
[21:06] <seb128> mvo, hey, is snap install supposed to create a .desktop in /var/lib/snappy/desktop? it doesn't do it it seems but I don't know if that regressed or if that should only be done when using the UI
[21:06] <mvo> seb128: its in /var/lib/snapd/desktop nowdays
[21:06] <mvo> seb128: which means we need to update our XDG bit, dang. thanks
[21:06] <seb128> mvo, XDG_DATA_DIRS has the wrong value then
[21:06] <seb128> right
[21:07] <seb128> yw!:
[21:07] <seb128> mvo, also it doesn't seem to work, I installed "ubuntu-calculator-app" and don't have any .desktop in there
[21:07] <mvo> seb128: fix on the way
[21:08] <seb128> the dir exists but is empty
[21:08] <mvo> seb128: I suspect the calculator is not shipping an desktop file
[21:08] <seb128> mvo, it does
[21:09] <mvo> seb128: try sudo snap install cap-test
[21:09] <mvo> seb128: the desktop file needs to be in meta/gui/
[21:10] <mvo> seb128: https://github.com/ubuntu-core/snappy/blob/master/docs/meta.md#dekstop-files
[21:10] <seb128> mvo, find says it has /snap/ubuntu-calculator-app/2/usr/share/applications/ubuntu-calculator-app.desktop
[21:10] <mvo> seb128: https://github.com/ubuntu-core/snappy/pull/1003
[21:10] <seb128> mvo, I see
[21:10] <mvo> seb128: yes, wrong location, sorry
[21:11] <mvo> seb128: we can fix this in the desktop-examples branch probably before the release
[21:11] <mvo> seb128: cap-test is a good example, small, simple and should fully work
[21:11] <mvo> (just not very sexy)
[21:11] <seb128> mvo, yeah, indeed works
[21:11] <seb128> oh well, that was not pointless
[21:11] <seb128> we found the wrong XDG env
[21:11] <seb128> mvo, thanks for fixing!
[21:12] <mvo> seb128: yeah, absolutely, thanks a ton for this
[21:12]  * mvo hugs seb128
[21:12] <seb128> yw :-)
[21:12]  * seb128 hugs mvo back
[21:45] <dpm> seb128, mvo, the calculator app does not ship a desktop file via snapcraft. I didn't get to put it under meta/gui. What it is incidentally shipping is the desktop file built as part of the upstream build, but that's as you've noticed in the wrong place
[21:45] <seb128> dpm, right
[22:08] <jdstrand> hrm
[22:09] <jdstrand> the network-bind plug isn't autoconnecting
[22:09] <jdstrand> this might've been what zyga was seeing
[22:09] <jdstrand> and I can't seem to make snap connect do what I want
[22:09] <jdstrand> I'll followup on monday
[22:47] <willcooke> in theory.... could SDoC work on Vivid
[22:48] <seb128> willcooke, define "theory", if vivid was updated to xenial? ;-)
[22:49] <kyrofa> seb128, hahaha
[22:50] <kyrofa> willcooke, I think it's pretty systemd heavy. That wasn't in vivid, was it?
[22:50] <willcooke> yeah it's in there
[22:50] <seb128> right, which is my comment about updating to xenial
[22:50] <seb128> it's not recent enough for snappy iirc
[22:51] <willcooke> kgunn ^
[22:51] <seb128> would need never kernel/systemd
[22:52] <kgunn> ack
[22:52] <seb128> newer even