[00:14] <sergiusens> elopio the tests I will work on now, not that the previous test was covering much either :-P
[00:30] <zyga> wililupy: catch me tomororw please
[00:30] <zyga> mhall119: cool!
[00:32] <wililupy> np zyga. Thank you.
[03:31] <ePierre> Hi!
[03:31] <ePierre> I'm having troubles with a snap I installed and I want to remove.
[03:31] <ePierre> (I'm on Xenial)
[03:32] <ePierre> So I installed the Telegram snap by running "sudo snap install telegram-sergiusens"
[03:32] <ePierre> And then after using it a little I decided I wanted to remove it
[03:32] <ePierre> so I ran
[03:32] <ePierre> sudo snap remove telegram-sergiusens
[03:33] <ePierre> but then it complained about some stuff, and now I'm in limbo: the Telegram app is not available anymore, but I keep receiving notifications, and it still appears when doing `snap list`
[03:33] <ePierre> if I try to remove it again it says
[03:33] <ePierre> error: cannot remove "telegram-sergiusens": snap "telegram-sergiusens" has changes in progress
[03:34] <ePierre> and in systemctl, I see this error: "Failed unmounting Squashfs mount unit for telegram-sergiusens."
[03:34] <ePierre> what can I do?
[05:19] <olympionex> I'm trying to build a snap for 16.04 desktop that contains a driver library for a 3d camera.  Typically this library installs some udev rules for usb devices connected to the system.  Is there anyway to achieve the equivalent for my snap?
[07:11] <mvo> jdstrand, tyhicks if you could do a review of https://github.com/ubuntu-core/snap-run/pull/3/files that would be much appreciated
[07:13] <mvo> jdstrand, tyhicks and do you happen to have any idea about the apparmor env scrubbing?
[07:59] <pmp> ysionneau: regarding your ptmx-problem, could it be apparmor-profile-name problem?
[08:02] <pmp> ysionneau: I found this commit which has been integrated into 3.12: https://goo.gl/xcvOmU
[08:02] <pmp> ysionneau: in it they are doing profile-name mangling - slashes become dots
[08:03] <pmp> ysionneau: maybe it is not a mount-problem but a profile-name-problem
[08:04] <pmp> ogra_`: ayt?
[08:30] <ogra_`> pmp, hey
[08:32] <ysionneau> pmp: hmmmmm maybe, I'm not sure about this
[08:33] <pmp> ogra_`: hi, I think you are the one building the kernel snaps for rpi2?
[08:34] <ogra_`> yeah, note that i use the debs from the archive though, if you want the contents of the deb changed ppisati is your man
[08:34] <ogra_`> (i.e. actual kernel changes)
[08:35] <ogra_`> (deb's i shoudl say, it is more than one :) )
[08:35] <pmp> ogra_`: so if I need the .config and the snapcraft.yaml/snap.yaml ppisati is my man, as you say ;-) ?
[08:36] <ogra_`> http://paste.ubuntu.com/16630580/ funnily i just pasted a snippet from the build script yesterday ...
[08:36] <ogra_`> this is how we assemble the snap.yaml
[08:37] <ogra_`> if you grab the xenial-preinstalled-core-armhf.raspi2.kernel.snap from http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ you can use unsquashfs to extract the file to see the result
[08:38] <pmp> ogra_`: I build my kernel locally, I could just install it so that the snap.yaml will find all the bits and pieces?
[08:38] <ogra_`> for building locally i'd rather recommend using snapcraft
[08:39] <ogra_`> it has a kernel plugin that should do everything you need
[08:39] <pmp> yes, I saw the sergiusens article
[08:39] <pmp> then I only need a .config-file
[08:40] <pmp> bcm2709_defconfig does not activate apparmor - it seems
[08:41] <pmp> ogra_`: is xenial-preinstalled-core-armhf.raspi2.kernel.snap the snap which is downloaded by u-d-f?
[08:41] <ogra_`> the config is generated from different snippets at build time
[08:42] <pmp> yes, but on a standard kernel build the .config is stored along with the kernel-image - that would be sufficient
[08:42] <ogra_`> you can grab  https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/9738878/+files/linux-image-4.4.0-1010-raspi2_4.4.0-1010.13_armhf.deb (the last kernel in xenial as https://launchpad.net/ubuntu/+source/linux-raspi2 shows)
[08:43] <ogra_`> in there you find a /boot/config-$version usually
[08:43] <ogra_`> http://paste.ubuntu.com/16652276/
[08:43] <ogra_`> (i had it locally :) )
[08:44] <pmp> yes, thanks for all these pointers - quite hard to find my way through this jungle
[08:44] <ogra_`> yeah
[08:44] <ogra_`> we once had /proc/config.gz enabled in the arm kernels ... but somehow that got dropped
[08:45] <ogra_`> and the kernel snap doesnt allow copying the config into /boot
[08:46] <ogra_`> so it is kind of hard to get the default config from the official kernels ... we'll fix that while re-working the kernel snap :)
[08:47] <ogra_`> i also know that there is some work on a script going on that snapcraft should ship .... to parse the config and require all needed defaults
[08:47] <ogra_`> (but i think thats still in its early stages)
[08:49] <pmp> ogra_`: fyi, I need to update my kernel because of IIO-drivers only present in 4.6.0
[08:50] <ogra_`> pmp, hmm, you shoudl perhaps ask ppisati, he might be having a 4.6 work-branch somewhere already
[08:50] <pmp> ogra_`: my goal is to see what's missing in the standard snappy-interface to make it work
[08:50] <pmp> ogra_`: what timezone is ppisati?
[08:50] <ogra_`> europe
[08:53] <pmp> ysionneau: the problem is definitely in the kernel - this is the only difference between raspi2 and your device
[08:53] <pmp> ysionneau: our device ;-)
[08:54] <pmp> ysionneau: when you look at the code of apparmor in 3.10 you'll see a function adding slashes to paths-strings - maybe it is that.
[08:54] <ysionneau> ok let's try the patch you pasted :)
[08:55] <pmp> ysionneau: not sure it applies
[08:57] <zyga> o/
[08:58] <pmp> ysionneau: maybe try updating to 3.18 as a kind of brutal bisect for this issue - if you can
[09:00] <ysionneau> oh btw it seems we got an update we now have 3.10.96 kernel
[09:01] <pmp> ysionneau: That's what I saw yesterday
[10:00] <dholbach> salut didrocks - can you merge https://github.com/ubuntu-core/snappy-dev-website/pull/3?
[11:07] <mvo> jdstrand, tyhicks: nevermind, I found #1584069 so my questions about apparmor and AT_SECURE are answered
[11:29] <didrocks> dholbach: I didn't do it right away because of the "Looks good, just have a question
[11:29] <didrocks> "
[11:29] <dholbach> oh
[11:29] <didrocks> but it seems it's fixed now
[11:29] <didrocks> merging :)
[11:29] <dholbach> that was something... yes, it's fixed
[11:29] <dholbach> thanks!
[11:29] <didrocks> (merged)
[12:37] <jdstrand> sergiusens: we have 4 different mksquashfs bugs for resquash test. I've disabled the test until I have time to get back to it
[12:52] <noizer> Hi
[12:52] <noizer> stupid question where can I find the latest image of snappy
[12:53] <noizer> I want to try my snap on a clean new image
[12:58] <kyrofa> noizer, not a stupid question-- we're in a bit of a weird spot where we don't actually have images for snappy 16 right now (we will soon). You know you can use them on the desktop (or server), right?
[12:58] <noizer> kyrofa yes I know that but its for my raspberry pi 2
[12:58] <ogra_> you can still use ubuntu-device-flash from mvo's all-snaps dir
[12:59] <noizer> kyrofa: a bit ago i downloaded a snappy 16 image
[12:59] <ogra_> note that you will likley have to re-flash once we switched to new kernel and gadget definitions though
[13:01] <noizer> I know but is there a link where I can download the image ogra_
[13:01] <jdstrand> mvo: hey, I had a PR against ubuntu-core. do I need to re-request it against snapcore or is some other magic happening?
[13:01] <ogra_> didnt change sice i last gave it to you ;)
[13:01] <ogra_> http://people.canonical.com/~mvo/all-snaps/
[13:02] <ogra_> but really, better grab ubuntu-device-flash and roll an image yourself ... the ready-made ones are likely outdated
[13:02] <mvo> jdstrand: yeah @zyga has the details
[13:05] <sergiusens> good morning!
[13:05] <sergiusens> kyrofa how did the python3 plugin branch look like? (tests aside
[13:06] <kyrofa> sergiusens, hey there! I think it looks pretty good-- I need to look it over a little more carefully
[13:07] <sergiusens> kyrofa yeah. It is though a lot better than what was there before
[13:08] <noizer> ogra_:  Ok is that very difficult?
[13:12] <ogra_> noizer, sudo ./ubuntu-device-flash core 16 --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o my-shiny-image.img
[13:12] <noizer> okay thx xD
[13:18] <noizer> ogra_: pfff systemctl not found :s
[13:19] <ogra_> ?
[13:20] <noizer> need '/bin/systemctl to work
[13:20] <noizer> thats the error :s
[13:21] <ogra_> not sure what you mean
[13:21] <noizer> when I'm running you command i got that
[13:21] <noizer> thats on my virtual machine ubuntu
[13:24] <ogra_> noizer, http://paste.ubuntu.com/16654988/
[13:24] <ogra_> well, no idea what that is then
[13:24] <josepht> what is the proper plug for creating local sockets?  Is running the snap command as root via sudo going to cause a problem?
[13:25] <sergiusens> Chipaca` mind reviewing https://bugs.launchpad.net/snapcraft/+bug/1579931 ?
[13:25] <sergiusens> err
[13:25] <sergiusens> Chipaca` https://github.com/ubuntu-core/snapcraft/pull/510 this
[13:28] <noizer> ogra_: will try it on other system
[13:28] <ogra_> well, worst case just pull a pre-built one ...
[13:28] <kyrofa> josepht, no, running snap as sudo should be fine
[13:29] <kyrofa> josepht, without testing, you probably need network-bind
[13:30] <jdstrand> zyga: hi! mvo said there is some procedure to follow for moving existing PRs against ubuntu-core to snapcore?
[13:30] <noizer> ogra_: On what system are you trying to make it?
[13:30] <ogra_> thats a standard xenial install
[13:31] <noizer> but I try to build it on a ubuntu ( not snappy OS )
[13:31] <Chipaca`> sergiusens: hi
[13:37] <noizer> ogra_: on my snappy of my raspberry pi 2 i got a syntax error :s
[13:37] <ogra_> for what ?
[13:40] <noizer> ./ubuntu-device-flash.1: Syntax error: "(" unexpected ogra_
[13:40] <ogra_> dont run it on snappy :)
[13:40] <ogra_> you need a 15.10 (or newer) desktop or server install
[13:41] <noizer> ok but on my ubuntu desktop i got the /bin/systemctl that he doesn't find how can I install it?
[13:42] <noizer> owkey now i got 14.04 LTS
[13:48] <ypwong> beuno,  hi, my upload to the store is rejected, I wonder if this is actually a bug in the store? I have the details in https://bugs.launchpad.net/snappy/+bug/1584346
[13:48] <zyga> jdstrand: hey
[13:48] <zyga> jdstrand: well it involves git init
[13:48] <zyga> jdstrand: bzr fast-export --quiet --plain --git-branch snap-run . | git fast-import --quiet
[13:48] <zyga> jdstrand: (with some unpackaged code, last time I checked)
[13:49] <jdstrand> zyga: I wasn't talking about snap-run (but thanks!), I was talking about my gsettings PR
[13:49] <zyga> jdstrand: followed by rabase -i origin/master (the origin from github) to remove the patches that are upstream but were converted locally anyway
[13:49] <zyga> jdstrand: oh
[13:49]  * zyga re-reads
[13:49] <zyga> jdstrand: hmm, didn't those move automatically?
[13:49] <zyga> jdstrand: if no then I don't know anything about that
[13:49] <jdstrand> zyga: I don't know-- were the supposed to? if so, I'll just poke around
[13:50] <zyga> jdstrand: did yours move?
[13:50] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/1160
[13:50] <zyga> jdstrand: this moved for me
[13:50] <zyga> jdstrand: just edit your .git/config
[13:50] <zyga> jdstrand: sed the repo name
[13:50] <zyga> jdstrand: and you're good
[13:50] <jdstrand> it looks like it did
[13:50] <jdstrand> ok, that's fine. thanks!
[13:53] <jdstrand> mvo: can you remind how, when and where to use Closes: LP:NNNNNN. I wrote it down but I think I got it wrong based on PR changes from others
[13:53] <jdstrand> I think an SRU comment on one of my bugs might have been because I did it wrong
[13:54] <josepht> kyrofa: I've got both 'network' and 'network-bind'.  Specifically I'm referring to the nmap snap in the store
[13:55] <kyrofa> jdstrand, gbp dch uses `LP: #<bug>` by default
[13:55] <beuno> jdstrand, hi!  can you queue this up?  https://bugs.launchpad.net/snappy/+bug/1584346
[13:56] <kyrofa> Not sure what incantation mvo is using though
[13:56] <beuno> jdstrand, looking at it, that is  :)
[13:56] <jdstrand> beuno: that's a dupe of another bug
[13:57] <jdstrand> sergiusens: I'm still not clear on what to do on that ^ (libmvec.so)
[13:58] <sergiusens> jdstrand oh, it is a snapcraft bug from what I believe. In any case, I don't think it to be bad to allow those symlinks, they just point to libc versioned libs
[13:58] <sergiusens> and libc6 we support
[13:59] <jdstrand> sergiusens: you closed the review tools task on the python one, but that one may not be python...
[13:59] <jdstrand> sergiusens: ok, that is what I wanted to know. thanks!
[14:09] <jdstrand> roadmr (cc beuno): can you sync r666 for bug 1584346?
[14:09] <roadmr> jdstrand: sure thing
[14:10] <jdstrand> roadmr: thanks. curious, did the previously requested sync make it past staging?
[14:10] <roadmr> jdstrand: nope, I was planning on doing a deploy starting this week but I was off yesterday
[14:10] <jdstrand> Ok, thanks
[14:11] <roadmr> jdstrand: wait, r666? are you sure? 😈
[14:11] <jdstrand> hehe, I know, right?
[14:12] <roadmr> hehe yes :) no prob though
[14:15] <sergiusens> kyrofa btw, have you seen my comment here https://github.com/ubuntu-core/snapcraft/pull/502
[14:15] <sergiusens> ?
[14:16] <sergiusens> kyrofa you also have conflicts there ;-)
[14:17] <kyrofa> sergiusens, yeah I did, and it got me thinking. Since it's just copied through I don't actually care how it's parsed, but I care how it's validated, so now I'm thinking I'll make it a custom type and write a custom validator for it
[14:17] <kyrofa> Because yeah, this whole numeric/string thing is killing me
[14:17] <kyrofa> sergiusens, how do you feel about that solution?
[14:18] <sergiusens> kyrofa custom validator using the format checker? that seems fine
[14:19] <kyrofa> sergiusens, alright. Then we don't need to care about how yaml wants to parse it
[14:25] <mvo> jdstrand: the format for the changelog got discussed with niemeyer  a while ago, I wrote a custom snappy-dch to parse this stuff
[14:25] <kyrofa> mvo, have you guys considered writing a CONTRIBUTING.md covering that stuff?
[14:26] <mvo> kyrofa: I think we have a file like this, I don't think it has this in it though, the idea is really good
[14:26] <kyrofa> mvo, yeah you have one, but it doesn't discuss this stuff
[14:26] <jdstrand> mvo: yeah, I recall you telling me that and what to do, but I seem to have gotten it wrong. if I want snappy-dch to correctly parse for autoclosing, what do I need to do and where?
[14:27] <jdstrand> I'll take better notes this time
[14:28] <mvo> jdstrand: let me try to find the original conversation
[14:29] <sergiusens> zyga in order for you to be a more relaxed person, I will be snatching this from you https://bugs.launchpad.net/snapcraft/+bug/1581166
[14:41] <zyga> sergiusens: thank you :)
[15:29] <sergiusens> kyrofa so is that epoch stuff a future thing or are you going to update the branch?
[15:30] <kyrofa> sergiusens, just about done
[15:46] <seb128> qengho, hey there, you fontconfig issue ... is it https://bugs.launchpad.net/snapcraft/+bug/1576303 ?
[16:15] <kyrofa> Sorry sergiusens, epoch stuff is updated
[16:15] <kyrofa> sergiusens, jsonschema updates always take me a little while :P
[16:16] <sergiusens> kyrofa hope it doesn't conflict with https://github.com/ubuntu-core/snapcraft/pull/514
[16:17] <jdstrand> zyga: hey, so what is the plan for snap-run and series 16? I've got my seccomp arg filtering branch and need to know if I need to do it against both ubuntu-core/snap-run (shouldn't this be snapcore/snap-run?) and something else for xenial or just ubuntu-core/snap-run
[16:17] <kyrofa> sergiusens, I don't think it will, but it'll be easy to resolve if it does
[16:19] <jdstrand> mvo: perhaps you know? ^
[16:20] <sergiusens> kyrofa reviewed, looks good, I wonder why the 1.0 thing was tested before though
[16:23] <kyrofa> sergiusens, it probably shouldn't have. I think I was experimenting with how the multipleOf thing worked and never took it out
[16:24] <josepht> kyrofa: it looks like I needed 'network-control' as well
[16:24] <kyrofa> josepht, that's odd... you must be doing something other than just sockets
[16:25] <sergiusens> kyrofa btw, mind taking a look at 514?
[16:25] <kyrofa> sergiusens, but anyway, do you like that better than the previous validations?
[16:25] <kyrofa> sergiusens, yeah I'm actually looking at it now
[16:25] <sergiusens> kyrofa yes, this is much better
[16:25] <sergiusens> simpler
[16:26] <kyrofa> sergiusens, I finally feel like I've figured jsonschema out a little more
[16:26] <kyrofa> My previous attempts were working against it a bit
[16:53] <sergiusens> kyrofa yeah, this schema thing is kind of strange
[16:53] <sergiusens> kyrofa it would be nicer to get better raw data to construct nicer error messages
[16:53] <sergiusens> kyrofa btw, does this look weird to you https://github.com/ubuntu-core/snapcraft/pull/505 ?
[16:54] <kyrofa> sergiusens, we can do that with more formats over time if you like that approach
[16:54] <kyrofa> Oh right, I never actually commented on that one huh
[16:54] <kyrofa> sergiusens, wait... yeah
[16:54] <kyrofa> sergiusens, what happened here?
[16:55] <kyrofa> sergiusens, oh, old diff?
[16:55] <kyrofa> sergiusens, it just needs to be merged with master I think
[16:55] <sergiusens> kyrofa it looks like not only an old diff, but the only diff is about strict
[16:56] <sergiusens> going to try and ping elopio and see if he can click on "update branch"
[16:56] <kyrofa> Yeah it's due to my changing that commit
[16:57] <sergiusens> kyrofa darn, it has only been 1 hour since he said 2 hours :-)
[16:57] <kyrofa> Hahaha
[16:57] <sergiusens> kyrofa you should re create the PR ;-)
[16:58] <kyrofa> sergiusens, sure thing ;)
[17:07] <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/515
[17:50] <zyga> jdstrand: I'm not sure, I think we want to use it as soon as it is viable
[17:51] <zyga> jdstrand: we need the migration command on snapd
[17:51] <zyga> jdstrand: though we can actually land the package as-is as it has backwards compatible wrapper (ubuntu-core-launcher) that calls snap-run
[17:51] <zyga> jdstrand: (though it may not be possible to do that soon if we remove the binary command as an argument)
[17:55] <zyga> jdstrand: I would rather transition everything ASAP
[17:56] <jdstrand> that's fine
[17:56] <jdstrand> that makes it easier on me
[17:56] <jdstrand> I just have to do the one PR then
[17:56] <jdstrand> note, tyhicks said he'd do the arg filtering review this week
[17:57] <jdstrand> ah geez
[17:57] <jdstrand> it is now s/snapcore/CanonicalLtd/ ?
[17:57] <jdstrand> zyga: ^ ?
[17:59] <jdstrand> ok, apparently not yet
[18:00]  * jdstrand continues with ubuntu-core/snap-run
[18:03] <zyga> jdstrand: it will be soon
[18:03] <zyga> jdstrand: I cannot change htat
[18:11] <sergiusens> jdstrand is the fix for chromium content provider in -proposed already? or can you ping me when it is? Out of curiousity was it solved with a mount dance or with interface changes?
[18:15] <sergiusens> Saviq btw, did you snap refresh telegram-sergiusens already?
[18:16] <jdstrand> sergiusens: I mentioned the other day there are 4 things to address it. none have landed. one depends on zyga (shm preload), the seccomp arg filtering branch to land (in progress, hopefully will land this week), then seccomp arg filtering profile updates (dependent on other landing) and then another denial
[18:16] <Saviq> sergiusens, did not
[18:16] <jdstrand> I think that last one is non-fatal, but I'll be looking at that today
[18:17] <Saviq> sergiusens, thanks :)
[18:22] <sergiusens> jdstrand so 4 things for this and 4 for squashfs :-P
[18:24] <jdstrand> sergiusens: there is no shortage of things to do
[18:24] <jdstrand> I suspect one of those 4 things for squashfs is a dupe, but I need the snap to be sure
[18:25] <jdstrand> but as mentioned, the squashfs issue will not be painful for people-- the test is being disabled
[18:26] <sergiusens> jdstrand I can get you the yaml used to generate it
[18:28] <sergiusens> jdstrand use this branch of snapcraft https://github.com/ubuntu-core/snapcraft/pull/510 with http://paste.ubuntu.com/16644344/
[18:28] <sergiusens> or grab my deb from people.canonical.com:/home/sergiusens/snapcraft_2.8.8_all.deb
[18:31] <netphreak> Hi, guys ;)
[18:32] <sergiusens> jdstrand and here it is https://bugs.launchpad.net/click-reviewers-tools/+bug/1579931/comments/2
[18:32] <sergiusens> netphreak hey
[18:42] <netphreak> has classic shell returned to snappy?
[18:48] <kyrofa> netphreak, not yet, but we're working on it
[18:49] <netphreak> Any indication on, when?
[18:50] <kyrofa> netphreak, I'm not sure, maybe ogra_ knows
[18:51] <ogra_> i want to have the build side ready by end of this week
[18:51] <ogra_> then there are some bits on the snappy side needed i think
[18:52] <netphreak> ok cool.
[18:52] <netphreak> Are there any release dates for snappy?
[19:16] <sergiusens> he left, but the answer was, it is already released ;-)
[19:20] <jdstrand> sergiusens: thanks
[19:20] <jdstrand> sergiusens: I also added you to the card tracking the electron stuff