[07:10] <shuduo> morning, i'm trying to stitch a customized image with my own kenrel snap. i modified 96boards-kernel of snapcraft-examples then i use latest u-d-f and specify --kernel=./96boards-kernel.snap. Now u-d-f reports "Installing ./96boards-kernel.snap
[07:10] <shuduo> failed to install "./96boards-kernel.snap" from "edge": ./96boards-kernel.snap failed to install: invalid snap name: "96boards-kernel"
[07:10] <shuduo> anything wrong?
[07:14] <shuduo> ogra_, zyga : ^^
[07:15] <zyga> shuduo: cannot start with digits
[07:16] <zyga> shuduo: kernel-96boards
[07:16] <zyga> shuduo: try that instead
[07:16] <zyga> shuduo: :-)
[07:16]  * zyga is off today, going to the airport soon
[07:17] <zyga> shuduo: if the name bugs you please report a bug on snappy, we could perhaps lift the restriction, no promises though
[07:20] <morphis> zyga: ping
[07:21] <zyga> hey hey
[07:21] <zyga> how are you morphis
[07:21] <morphis> zyga: fine :-)
[07:21] <shuduo> zyga: thanks. will try it. so snapcraft-examples/examples/96boards-kernel should going to change acccordingly, right?
[07:21] <morphis> and you?
[07:21] <morphis> getting forward with ubuntu-image?
[07:21] <zyga> shuduo: hmmmm, if it worked before then I'm puzzled
[07:22] <zyga> morphis: yep, slowly, I was still working on other tasks, I talked to slangasek and barry last night
[07:22] <zyga> morphis: gave them my shell prototype, I will try to make it less of a prototype now (less magic blobs, more things that can be built)
[07:22] <zyga> morphis: 09:22 < zyga> morphis: yep, slowly, I was still working on other tasks, I talked to slangasek and barry last night
[07:23]  * zyga wonder how that got pasted...
[07:24] <morphis> :-)
[07:24] <morphis> zyga: you remember what we said about i2c interface in the meeting about interfaces for RTM?
[07:24] <zyga> yes
[07:24] <zyga> do you have a patch for that? :-)
[07:26] <morphis> zyga: not yet, but someone who needs it for a sensor snap on the pi
[07:26] <morphis> zyga: we dropped it from the list, right?
[07:27] <pmp> morphis: sorry for the instrusion: "sensor snap on the pi" .. via iio?
[07:27] <pmp> morphis: hi - first of all
[07:27] <morphis> pmp: hey! :-)
[07:27] <morphis> lpotter is working on that
[07:27] <zyga> morphis: yes we did
[07:27] <morphis> not sure what it actually uses to talk with the hardware I just go i2c from lpotter so far :-)
[07:28] <morphis> pmp: you're working on something similar?
[07:28] <pmp> morphis: I will need to make a snap which will access sensors via iio - at one point in time
[07:29] <morphis> zyga: from what I saw so far the way would be to just put a generic i2c interface into snapd allowing access to /dev/i2c*
[07:29] <pmp> morphis: prototyping on the pi and then make it work on the real target
[07:29] <morphis> pmp: afaik lpotter as a working prototype already which runs mostly fine in devmode
[07:31] <pmp> morphis: hmm, not sure what you mean, I'm not using RTM (don't even know what it is, related to ROS?), I just have a simple user-app which will access sensors via IIO
[07:31] <morphis> pmp: RTM is just a version of snap* stuff
[07:32] <zyga> morphis: https://github.com/snapcore/snapd/pull/1231
[07:32] <zyga> morphis: just wrote one quickly, didn't test it
[07:32] <morphis> pmp: the snap lpotter is working on is exactly doing this but will be an example of how you can do such things on a device
[07:32] <zyga> morphis: no, I'd imagine a specific interface instance for each controller
[07:32] <zyga> morphis: and all controllers would be described by the gadget snap
[07:33]  * zyga -> afk (15 min)
[07:33] <morphis> zyga: I see
[07:34] <zyga> morphis: we could have a i2c-control (global) and i2c (per controller device node)
[07:35] <zyga> morphis: and later on we could grow a slot level attribute that says if the controller actually speaks smbus or i2c or whatnot
[07:35] <zyga> morphis: but this should be good as a starting point
[07:35] <zyga> afk for real
[07:41] <shuduo> zyga: ping
[07:42] <shuduo> zyga: seems digital name issue is gone after name changed. now new error msg is "failed to install kernel can not extract kernel assets: cannot determine bootloader"
[07:44] <shuduo> zyga_: seems digital name issue is gone after name changed. now new error msg is "failed to install kernel can not extract kernel assets: cannot determine bootloader"
[07:46] <pmp> morphis: how to not lose track of the changes made by lpotter? (I'm not working on snappy everyday) Do you have a link?
[07:46] <morphis> pmp: not yet, need to wait for lpotter to be back
[07:47] <pmp> lpotter == Lorn Potter?
[08:05]  * zyga -> away
[08:05] <zyga> see you in the evening
[10:35] <flexiondotorg> I'm trying to create a source build snap package of Pluma.
[10:35] <flexiondotorg> I need to pass some configure options to autotools.
[10:36] <flexiondotorg> The documentation says I should ConfigFlags: but that snapcraft throws an error when I use that.
[10:37] <flexiondotorg> Issue while loading plugin: properties failed to load for pluma: Additional properties are not allowed ('configFlags' was unexpected)
[10:41] <flexiondotorg> Documentation is wrong, the snapcraft source shows it should be configflags:
[12:41] <sergiusens> flexiondotorg mind logging a bug or a quick PR to fix that?
[12:43] <flexiondotorg> sergiusens, What is the source repo for the documentation? I'll submit a PR
[12:46] <sergiusens> flexiondotorg in most cases just https://github.com/ubuntu-core/snapcraft
[12:47] <flexiondotorg> sergiusens, Thanks.
[12:47] <sergiusens> flexiondotorg the sources have a docstring (which is used for `snapcraft help <plugin-name>`
[12:47] <sergiusens> flexiondotorg and if you saw it on the website, look at the docs dir
[12:55] <flexiondotorg> sergiusens, Here's your PR :-) https://github.com/ubuntu-core/snapcraft/pull/521
[12:57] <sergiusens> flexiondotorg thank you!
[13:02] <flexiondotorg> sergiusens, You're welcome.
[13:54] <kyrofa> sergiusens, I'm babysitting didrock's branches while he's off, so let me know if something needs to be changed and I'll repropose
[14:00] <sergiusens> kyrofa oh, he's off? Well, there is one thing in 506 then
[14:01] <kyrofa> sergiusens, the package is still called snapcraft-examples... what transition are you referring to?
[14:01] <sergiusens> kyrofa arf, my mind was thinking everything was getting renamed :-P
[14:02] <kyrofa> sergiusens, heh-- yeah seems he was pretty careful about breakage
[14:02] <kyrofa> sergiusens, he even left the examples tests, but redirected them to demos
[14:03] <sergiusens> kyrofa yeah, I saw that part
[14:03] <sergiusens> kyrofa I'll build a deb from this and see how it goes
[14:03] <kyrofa> sergiusens, ah, yeah that's probably a good call
[14:10] <sergiusens> kyrofa any idea why this diff looks weird https://github.com/ubuntu-core/snapcraft/pull/509/files ?
[14:10] <kyrofa> sergiusens, it needs a real rebase I'm afraid. Looks like he merged with master right before I fixed that bad commit
[14:11] <kyrofa> That's what it looks like anyway
[14:12] <josepht> reviewers: could some give my pi2 nmap snap a quick review (needs network-control for running with sudo) https://myapps.developer.ubuntu.com/dev/click-apps/4710/rev/27/
[14:12] <josepht> *someone
[14:44] <sergiusens> kyrofa check 506 again ;-)
[14:46] <davidcalle> jdstrand: I've left a comment on the sec doc, p31
[14:47] <kyrofa> sergiusens, on it
[14:47] <sergiusens> jdstrand about taking over, does that really fall into snapcraft? I would think the launcher would be the right project
[14:52] <sergiusens> kyrofa one more comment added
[14:54] <jdstrand> sergiusens: I'm not sure what zyga had in mind. I'll let you two battle it out
[15:03] <kyrofa> sergiusens, interesting... in debian/rules he has dh_compress -Xusr/share/doc/snapcraft-examples/demos . You're saying that directory isn't actually valid?
[15:13] <sergiusens> kyrofa it is valid, but debian/snapcraft-examples.examples magles; build and see
[15:13] <sergiusens> kyrofa build, install and see
[15:14] <kyrofa> sergiusens, do you want them in /usr/share/doc/snapcraft-examples/demos instead of examples?
[15:14] <kyrofa> sergiusens, yeah I see that they're in the same spot as they used to be
[15:15] <sergiusens> kyrofa yeah, and the documentation gets weird, because if you git clone you cd into demos if you apt install you cd into examples
[15:16] <sergiusens> kyrofa maybe we should just kill the examples/demos as a package; do you know if that was the idea?
[15:16] <sergiusens> and then move to providing the real "examples"
[15:16] <sergiusens> and tell everyone to grab the demos from the demos page
[15:16] <elopio> sergiusens, kyrofa: https://github.com/ubuntu-core/snapcraft/pull/511 all green. Do you like it?
[15:17] <kyrofa> sergiusens, the goal of his work is to just have that `snapcraft-examples` command that generates the basic examples. But that command actually needs to be shipped in snapcraft, not snapcraft-examples
[15:19] <kyrofa> So this branch's purpose was really to just make room for the "examples" that will be copied into cwd by that command
[15:20] <sergiusens> elopio I am reading that code now
[15:21] <sergiusens> kyrofa yeah, but if you "copy" you will also copy the "demos"
[15:21] <kyrofa> I don't think his goal was/is to kill the snapcraft-examples package. Though it might get a little confusing if the command mark wants is "snapcraft-examples"
[15:22] <sergiusens> kyrofa my suggestion is to change debian/snapcraft-examples.examples to debian/snapcraft-examples.install and tell it to install demos/* to /usr/share/doc/snapcraft-examples/demos
[15:22] <sergiusens> kyrofa do you feel up to that?
[15:22] <kyrofa> sergiusens, yeah, easy
[15:22] <Dinkz> Hello !
[15:22] <Dinkz> I was trying to install snappy into my Raspberry Pi-2
[15:22] <Dinkz> and got it installed.
[15:22] <Dinkz> NOw, I want to install adb into it.
[15:22] <kyrofa> sergiusens, have you seen this by the way? It might answer some questions: https://github.com/ubuntu-core/snapcraft/pull/513
[15:23] <kyrofa> I've not actually reviewed it yet
[15:23] <sergiusens> kyrofa or when is didrocks back? We can land this as is, but needs to have some resolution next week
[15:23] <kyrofa> sergiusens, monday I believe
[15:23] <elopio> Dinkz: hello
[15:23] <Dinkz> Hello Elopio
[15:23] <kyrofa> sergiusens, up to you. I've fixed the ros example test already, happy to fix the deb issue as well, and I can remake the PR
[15:24] <elopio> Dinkz: you would have to make a snap package for adb. We don't have it yet. And there's also the concept of "classic dimension", that will come back soon.
[15:25] <Dinkz> Thank you very much, Elopio ! What is classic dimension ?
[15:26] <sergiusens> elopio looks good, just added a minor TODO comment
[15:26] <kyrofa> elopio, chroots can be used for now, for what it's worth
[15:26] <elopio> Dinkz: it's like a container that will let you run "apt install adb"
[15:26] <sergiusens> kyrofa let me look at the follow up PR
[15:27] <elopio> sergiusens: I'll report a bug for the missing test.
[15:27] <Dinkz> Thanks a lot Elopio !
[15:30] <sergiusens> kyrofa ok I saw it, execute as agreed upon but...
[15:30] <sergiusens> kyrofa look at https://github.com/ubuntu-core/snapcraft/pull/513/commits/f57d1203dfa1dc136338a99b9dcdf7bc9fa3300c
[15:31] <sergiusens> kyrofa I always disliked the fact our examples landed in docs, maybe make the rule install in /usr/share/snapcraft/demos
[15:31] <kyrofa> sergiusens, indeed, they need to be in snapcraft itself (not the demos though)
[15:31] <kyrofa> Okay, can do
[15:31] <sergiusens> kyrofa I'll approved elopio's PR, looks like a dream, maybe rebase in a bit too ;-)
[15:32] <kyrofa> sergiusens, heh, sounds good
[15:32] <elopio> fgimenez: https://plus.google.com/hangouts/_/canonical.com/qa I miss you
[15:33] <elopio> sergiusens: hum, one thing about the TODO. My idea is that devs run against the fake in their machines, but jenkins runs against staging in PRs. The jenkins run will hit the status page more than once, for sure.
[15:34] <elopio> do you still want a test on the fake that hits the status more than one
[15:34] <elopio> *once
[15:34] <sergiusens> elopio ok, I am just thinking about unit test coverage :-P
[15:34] <sergiusens> kyrofa I am divided :-/
[15:34] <sergiusens> kyrofa don't change yet
[15:34] <sergiusens> just push the fix for the lone ros wolf
[15:35] <kyrofa> sergiusens, haha, I was just about to push!
[15:35] <kyrofa> sergiusens, alright will do
[15:35] <sergiusens> kyrofa I will solve this with didrocks when he gets back
[15:40] <kyrofa> sergiusens, alright: https://github.com/ubuntu-core/snapcraft/pull/522
[16:04] <elopio> sergiusens: this branch doesn't deal with unit test coverage yet. We'll get there in the others.
[16:08] <elopio> fgimenez: all check conflicts solved.
[16:11] <fgimenez> elopio, great dropping a comment in the next one..
[16:22] <kyrofa> sergiusens, I think https://github.com/ubuntu-core/snapcraft/pull/509 is ready to go, and should probably land before the examples so he doesn't need to update again
[16:23] <kyrofa> (assuming you want it in 2.10 of course)
[16:24] <sergiusens> kyrofa yeah, too bad I didn't notice the missing bug for this though
[16:24] <sergiusens> kyrofa we should create one and add it into the "merge and squash" comment
[16:24] <kyrofa> sergiusens, argh, I missed it as well. We can
[16:24] <kyrofa> Yeah exactly
[16:25] <kyrofa> I was about to say just that
[16:25] <sergiusens> kyrofa if you want to, go ahead, if not I'll do it in a bit
[16:25]  * sergiusens is working through some lunch
[16:30]  * elopio afk, swimming lessons.
[16:52] <balloons> sergiusens, apparently we need to migrate shoutirc to lounge; https://github.com/thelounge/lounge
[17:14] <sergiusens> balloons we don't need to, it is a nice alternative to snap
[17:14] <sergiusens> balloons lounge is a free for all shout fork. It also means it could be buggier ;-)
[17:15] <sergiusens> and or lack a clear roadmap. Feel free to get it snapped though!
[17:15] <balloons> sergiusens, yea, indeed. But I'm migrating over since it solves all the longstanding bugs and has all the contributors minus the original author :-)
[17:15] <balloons> So I would like a snap.. It will more or less be a clone of yours, so that's fun
[17:15] <balloons> *fine
[17:15] <sergiusens> balloons what bugs, the offline one?
[17:16] <balloons> yea, I just hit it again today. Super annoying
[17:16] <sergiusens> balloons I was going to look into it, but I just have no time :-P
[17:16] <sergiusens> balloons I haven't hit it ever, yet
[17:16]  * sergiusens crosses fingers now
[17:16] <balloons> LOL
[17:16] <balloons> it's silent, but deadly. It's been a good long while since it happened to me
[17:17] <sergiusens> kyrofa so now the ros demo fails http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/746/console
[17:18] <sergiusens> balloons ok, might get to it during the weekend ;-)
[17:46] <mhall119> hey everyone, how do I connect a snap's "home" plug ?
[17:47] <mhall119> bah, nevermind, I had my arguments backwards
[18:02] <kyrofa> mhall119, some of those bits were covered here by the way: http://summit.ubuntu.com/uos-1605/meeting/22682/anatomy-of-a-snap/
[18:03] <mhall119> thanks kyrofa
[18:03] <mhall119> ok, I've got two KDE apps now that both throw the same udev apparmor complaint when running in --devmode
[18:03] <kyrofa> mhall119, can I see the pastebin?
[18:04] <mhall119> kyrofa: http://paste.ubuntu.com/16713644/ first line specifically
[18:05] <tyhicks> mhall119: the important part is apparmor="ALLOWED"
[18:05] <mhall119> kyrofa: FWIW, an upstream KDE developer tries building and running the kcalc snap, but he doesn't get the udev access error
[18:05] <tyhicks> mhall119: that message is telling you that AppArmor would have blocked the action if you weren't running in devmode
[18:05] <jdstrand> mhall119: add the 'opengl' interface
[18:05] <mhall119> tyhicks: right
[18:06] <jdstrand> I'm guessing the person seeing that access is using an nvidia system
[18:06] <tyhicks> mhall119: sorry, thought you were thinking that AppArmor was blocking something
[18:06] <mhall119> but why is krita or kcalc (or any KDE app I assume now) accessing udev anyway? And why isn't the upstream dev seeing it
[18:06] <mhall119> tyhicks: it works in --devmode, but dies on launch otherwise with "Bad system call"
[18:06] <jdstrand> mhall119: ^
[18:06] <kyrofa> mhall119, different hardware I'd assume
[18:06] <mhall119> if I can get rid of that, I think these might run without --devmode
[18:06] <mhall119> jdstrand: all intel
[18:07] <jdstrand> mhall119: you have all intel?
[18:07] <mhall119> I'm all intel and see the rror
[18:07] <jdstrand> hmm
[18:07] <mhall119> the upstream, I don't know
[18:07] <jdstrand> perhaps the intel drivers also trigger it
[18:07] <kyrofa> mhall119, what is the syscall that causes it to barf?
[18:07] <jdstrand> mhall119: add the opengl interface
[18:07] <mhall119> kyrofa: no idea, and I don't know how to find out
[18:07] <mhall119> jdstrand: already have it
[18:07] <kyrofa> jdstrand, snappy-debug is back... right?
[18:08] <jdstrand> it is
[18:08] <mhall119> jdstrand: plugs: [X11, unity7, home, opengl, network
[18:08] <kyrofa> mhall119, are you familiar with snappy-debug?
[18:08] <mhall119> nope, tell me more :)
[18:08] <jdstrand> that should be x11
[18:08] <kyrofa> mhall119, oh, it will become your best friend
[18:08] <kyrofa> mhall119, snap install snappy-debug
[18:08] <mhall119> are there docs on how to use it on developer.ubuntu.com? (if not, hint hint)
[18:09] <kyrofa> mhall119, not that I know of-- snappy-debug was pulled for a while so we removed docs so as to not confuse people
[18:09] <kyrofa> mhall119, we'll get it back in there
[18:09] <mhall119> ok, snappy-debug installed
[18:10] <jdstrand> opengl gave a different access
[18:10] <jdstrand> we don't currently allow /run/udev/data/**
[18:11] <kyrofa> mhall119, now run `sudo snappy-debug.security scanlog` in one terminal and exercise the snap in the other
[18:11] <kyrofa> When it dies due to seccomp, snappy-debug's output should help
[18:11]  * jdstrand notes that snappy-debug doesn't yet handle dbus denials
[18:11] <jdstrand> but it'll of course handle seccomp just fine
[18:11] <kyrofa> jdstrand, good to know, thank you
[18:12] <jdstrand> I also suspect that the /run/udev access is noise
[18:12] <mhall119> heh, snappy-debug is giving apparmor notifications now
[18:12] <kyrofa> mhall119, indeed, it does that too
[18:12] <kyrofa> mhall119, like I said: best friend
[18:12] <jdstrand> mhall119: if it is working in devmode, I suggest filing a bug against snapd with the snapd-interface tag
[18:12] <kyrofa> thank jdstrand
[18:13] <mhall119> kyrofa: you didn't tell me to connect stuff :-P
[18:13] <kyrofa> mhall119, eh?
[18:13] <mhall119> sudo snap connect snappy-debug:log-observe ubuntu-core:log-observe
[18:13] <kyrofa> mhall119, haha, ah sorry!
[18:13] <kyrofa> mhall119, I've not actually used it in snappy 16
[18:13] <jdstrand> he didn't have too-- snappy-debug told you to :)
[18:13] <mhall119> jdstrand: this is true, and quite helpful
[18:14] <mhall119> kyrofa: output from snappy-debug scanlog: http://paste.ubuntu.com/16713961/
[18:15] <mhall119> kyrofa: was I supposed to install snappy-debug with --devmode?
[18:15] <jdstrand> no
[18:15] <kyrofa> mhall119, did you try sudo?
[18:15] <jdstrand> it works fine without --devmode
[18:15] <mhall119> kyrofa: mhall@mhall-thinkpad:~/projects/Ubuntu/snaps$ sudo /snap/bin/snappy-debug.security scanlog 2>&1 | pastebinit
[18:15] <mhall119> ^^ is what I ran
[18:16] <kyrofa> mhall119, congratulations, you're surpassed my snappy-debug knowledge :P
[18:16]  * mhall119 doesn't *feel* like a winner
[18:16] <kyrofa> jdstrand should know more though
[18:16] <jdstrand> there is a bug
[18:16] <jdstrand> I'll fix it now
[18:16] <jdstrand> mhall119: can you email me your syslog?
[18:17] <jdstrand> mhall119: feel free to truncate it to today
[18:17] <jdstrand> mhall119: grep audit /var/log/syslog > /tmp/audits
[18:17] <jdstrand> gzip /tmp/audits
[18:17] <jdstrand> send me /tmp/audits.gz
[18:21] <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/522 is green
[18:21] <jdstrand> mhall119: are you sending me that?
[18:25] <mhall119> jdstrand: sorry, was distracted by shiny new gadgets in the mail, working on the log now
[18:25] <sergiusens> kyrofa commented
[18:25] <sergiusens> kyrofa but yeah, +1 ;-)
[18:27] <mhall119> jdstrand: send, it wasn't very big so I didn't gzip it
[18:29] <jdstrand> thanks
[18:29] <jdstrand> mhall119: ok, can you do 'grep 1326 /var/log/syslog'
[18:30] <jdstrand> mhall119: I'll show you how to figure out the seccomp denial yourself
[18:30] <mhall119> that sounds like work :)
[18:30] <jdstrand> well, you can give me a sec
[18:30] <jdstrand> mhall119: is your system amd64? i386?
[18:32] <kyrofa> sergiusens, man, I've been slacking on actually looking at commits for bugs lately. You and elopio have been spoiling me
[18:32] <mhall119> i386 (don't laugh)
[18:32] <jdstrand> mhall119: this is the log entry:
[18:32] <jdstrand> May 26 13:14:23 mhall-thinkpad kernel: [181943.002409] audit: type=1326 audit(1464286463.789:7470): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=23870 comm="krita" exe="/snap/krita/100003/usr/bin/krita" sig=31 arch=40000003 syscall=102 compat=0 ip=0xb7700c31 code=0x0
[18:33] <lpotter> pmp: morphis the sensors snap for rpi is not using iio. RTIMULib talks firectly to i2c_x
[18:33] <jdstrand> mhall119: see where it sayd 'syscall=102'? do 'scmp_sys_resolver 102'
[18:33] <jdstrand> mhall119: that will give you the syscall (snappy-debug does that for you)
[18:33] <mhall119> socketcall?
[18:34] <jdstrand> ah yes, that is bug #1576066
[18:34] <mhall119> well, at least it's not a new bug :)
[18:34] <jdstrand> no, and it has a card, just haven't gotten to it yet
[18:34] <mhall119> it would also explain why I hit it and the KDE guy didn't, he's likely on amd64
[18:34] <jdstrand> yep
[18:35] <kyrofa> sergiusens, would you say this PR and didrock's next one relate to the same issue? In which case maybe the second one should reference it?
[18:35] <jdstrand> mhall119: you can workaround it by adding 'socketcall' to /var/lib/snapd/seccomp/profiles/snap.your.app
[18:35] <mhall119> jdstrand: who do I need to ply with alcohol to get it prioritized?
[18:36] <jdstrand> mhall119: it's high priority, it is just at the point where there are too many high priority things for too few people
[18:36] <kyrofa> jdstrand, that sounds like snappy in general :P
[18:37] <mhall119> jdstrand: just add 'socketcall' to the bottom of the profile?
[18:37] <jdstrand> mhall119: yes
[18:37] <jdstrand> that's it
[18:37] <jdstrand> do that, then start the app
[18:37] <mhall119> do I need to restart or trigger a re-parse or anything?
[18:37] <jdstrand> nope
[18:38] <jdstrand> mhall119: with apparmor you do cause there is something to load into the kernel. with seccomp, the launcher does all that for you
[18:39] <jdstrand> tyhicks: thoughts on the socketcall card? it seems correctly prioritized but people are still hitting it. we could just allow it until the card is complete, but it should also be noted this isn't blocking people using devmode
[18:40] <tyhicks> jdstrand: is the fix blocked on seccomp arg filtering?
[18:40] <mhall119> jdstrand: awesome, that did it!
[18:40] <mhall119> I can now run krita.snap without --devmode
[18:40] <jdstrand> tyhicks: no
[18:41] <mhall119> I still get a udev warning, but otherwise it seems to all work
[18:41] <jdstrand> tyhicks: once we backport seccomp to xenial, i386 systems with >= 4.3 kernels just start working (aiui)
[18:41] <jdstrand> mhall119: yeah, those udev denials are usually just noise
[18:42] <mhall119> scary looking noise though
[18:42] <tyhicks> jdstrand: backport seccomp? you mean seccomp arg filtering?
[18:42]  * tyhicks is looking at the card now
[18:43] <jdstrand> tyhicks: in other words, when all the conditions are right (glibc is updated, seccomp is updated, kernel is updated), i386 acts like other archs and doesn't need socketcall
[18:43] <tyhicks> jdstrand: I thought we decided to take care of this with seccomp arg filtering instead of touching glibc
[18:43] <jdstrand> tyhicks: no. libseccomp needs some patches for i386 to not need socketcall. that needs to go with glibc changes (already in xenial) and >=4.3 kernels
[18:44] <jdstrand> we don't need to touch glibc
[18:44] <jdstrand> it is already touched
[18:44] <tyhicks> oh
[18:44] <jdstrand> xenial has that change
[18:44] <jdstrand> the kernel has the change
[18:44] <jdstrand> it is just that seccomp needs a change
[18:44] <jdstrand> granted, I've not proved all that, but that is what people in the bug have said
[18:45] <jdstrand> cause for me to prove it would be to do the work, which is prioritized under other stuff :)
[18:45] <sergiusens> kyrofa yeah, I think both should so we know it's the same line of work
[18:45] <sergiusens> kyrofa same bug for both PRs
[18:45] <kyrofa> sergiusens, so it's okay to have two changelog entries for the same bug?
[18:46] <tyhicks> jdstrand: since devmode unblocks people, I think the socketcall fix is still prioritized appropriately
[18:46] <sergiusens> kyrofa yeah
[18:46] <kyrofa> sergiusens, sounds good
[18:47] <jdstrand> tyhicks: aiui, arg filtering could help a little, but then we'd still want this change to differentiate between AF_* types which we can't do with socketcall (one of the reasons for arg filtering)
[18:47] <jdstrand> tyhicks: ok, that was my thought as well. mhall119 ^
[18:49] <mhall119> I don't like using --devmode to work around bugs that aren't in the apps themselves, but I understand why other things are higher priority
[18:49] <tyhicks> jdstrand: you're right - we wouldn't be able to differentiate between different socket types
[18:51] <jdstrand> mhall119: it isn't deprioritized, it is just prioritized below a few other things. don't worry, we'll get there
[18:53] <jdstrand> mhall119: I see the issue with snappy-debug. you do need to install it with --devmode for the moment. I'll fix the log-\observe interface
[18:59] <mhall119> jdstrand: I understand, thanks
[19:09] <morphis> lpotter: good to know!
[19:09] <morphis> jdstrand: can you have a look at the modem-manger interface proposal?
[19:22] <jdstrand> morphis: I have it on my todo, yes
[19:38] <mhall119> are there any more snappy-clinics scheduled?
[19:38] <morphis> jdstrand: awesome!
[19:39] <sergiusens> elopio any idea how this could happen http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/750/console ?
[19:44] <sergiusens> balloons I think that until recently I was disconnected
[19:46] <nimoov> Are there 'plugs' that enable access to '/tmp' and/or a custom defined path?
[19:46] <sergiusens> nimoov /tmp is really private to a snap, you get /tmp in a private mount namespace
[19:47] <nimoov> Is it possible to get system /tmp?
[19:53] <kyrofa> nimoov, can you explain what you're trying to accomplish?
[19:54] <nimoov> I have build LLVM/Clang in snap, and I want to use it in an IDE(CLion). The problem is that the cmake binary, from my LLVM/Clang snap, doesn't have access to the same /tmp as the user. This is needed by CLion to test cmake.
[20:08] <elopio> sergiusens: to leave the record here, the mosquitto publisher failed to deliver the message to the subscriber. Could be a fluke, because the example has nothing of high-reliability. Or there could be a problem in classic blocking it, I'll take a look to discard this one.
[20:10] <beowulf> if i wanted a writeable area for a snap, where would i find one? :)
[20:11] <sergiusens> beowulf $SNAP_USER_DATA and $SNAP_DATA for user and system respectively (the latter being a service)
[20:11] <beowulf> sergiusens: ta
[20:19] <jdstrand> mhall119: fyi, https://github.com/snapcore/snapd/pull/1236
[20:36] <jdstrand> sergiusens: fyi: https://bugs.launchpad.net/snapcraft/+bug/1586162
[20:47] <nimoov> q
[20:48] <jdstrand> beuno: fyi, I'm getting 504s going to https://myapps.developer.ubuntu.com/dev/click-apps/
[20:49] <sergiusens> jdstrand well, according to yaml syntax that is a number, not a string. It needs " for it to be interpreted as a string
[20:50] <sergiusens> jdstrand that said, we can ignore yaml parsing and try and force it to string
[20:51] <beuno> jdstrand, hm
[20:51] <beuno> noise][, nessita, roadmr, ^
[20:51] <beuno> (it's looking like I will as well, I guess a timeout?)
[20:51] <nessita> jdstrand, are you with the canonical share account?
[20:52] <nessita> beuno, this is a known issue for admins or accounts with too many packages, fix will be done soon, workaround is to visit other URL not /
[20:52] <nessita> beuno, can you access https://myapps.developer.ubuntu.com/dev/click-apps/search/ ?
[20:53] <beuno> nessita, so jdstrand has too many packages?
[20:53] <sergiusens> elopio on retesting I got a spurious error http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/850/testReport/junit/tests/TestSnapcraftExamples/test_demo_godd_/
[20:53] <jdstrand> nessita: I was just hitting the site. I was logged in with shared, logged out, then was going back to login with personal
[20:53] <noise][> beuno: there's just a recent and nasty performance bug on the main page
[20:55] <jdstrand> sergiusens: the joys of yaml. I went to 0.21 to avoid it
[20:55] <nessita> beuno, the canonical shared account has
[20:55] <nessita> jdstrand, can you browse / with your personal account?
[20:55] <jdstrand> nessita: no. I logged out and getting a 504 trying to login
[20:55] <jdstrand> I don't see anything
[20:55] <nessita> hum
[20:56] <jdstrand> it spins then after a while shows the 504 page
[20:56] <nessita> jdstrand, how many packages do you own?
[20:56] <jdstrand> (and by 'it', I mean firefox's page load indicator)
[20:56] <nessita> jdstrand, can you open https://myapps.developer.ubuntu.com/dev/click-apps/53/ ?
[20:56] <jdstrand> less than 10
[20:56] <jdstrand> but I'm not logged in
[20:57] <jdstrand> it shouldn't be thinking about that yet
[20:57] <nessita> jdstrand, can you browse https://myapps.developer.ubuntu.com/logout/
[20:57] <jdstrand> I see that
[20:57] <jdstrand> that was the page I saw after I logged out
[20:57] <jdstrand> then I went to Sign in or register
[20:58] <jdstrand> shall I do that now?
[20:58] <nessita> jdstrand, I'm lost, were you able to login?
[20:58] <jdstrand> no
[20:58] <nessita> perhaps you did login but / can not be sown
[20:58] <jdstrand> hehe
[20:58] <nessita> shown*
[20:58] <jdstrand> I *was* logged in from earlier today
[20:58] <nessita> jdstrand, how do you know you are not logged in? :-D
[20:58] <jdstrand> I logged out
[20:59] <jdstrand> then I wen to login
[20:59] <jdstrand> 504
[20:59] <nessita> jdstrand, what do you see if you hit https://myapps.developer.ubuntu.com/dev/click-apps/53/ ?
[21:00] <jdstrand> I went to do signin/register and finally I saw the openid page and am logged in
[21:00] <jdstrand> weird
[21:00] <jdstrand> I tried for several minutes
[21:00] <jdstrand> to answer your specific question, I can see that page (now)
[21:00] <jdstrand> (permy)
[21:01] <nessita> jdstrand, so we have a bug for the / (which is really /dev/click-apps/) that we will fix soon, a bad set of queries
[21:01] <nessita> jdstrand, so I can give you the direct links to your apps
[21:01] <nessita> to unblock you
[21:02] <jdstrand> nessita: ok, now when I login with the shared account, I see the issue you are describing
[21:02] <jdstrand> nessita: can you give me the direct link to snappy-debug?
[21:02] <jdstrand> nessita: from the shared account?
[21:03] <nessita> sure
[21:03] <nessita> jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/3644/
[21:03] <jdstrand> thanks!
[21:03] <nessita> o/
[21:04] <nessita> jdstrand, sorry for this, will are working on making this better
[21:05] <jdstrand> no worries-- thanks for working on the issue
[21:06] <jdstrand> mhall119: fyi, I added something to snappy-debug for socketcall to help make it more discoverable. you still need -devmode for snappy-debug until that PR I pointed you at lands
[21:29] <sergiusens> kyrofa want to rebase https://github.com/ubuntu-core/snapcraft/pull/513 ?
[21:35] <mhall119> jdstrand: what do you mean make it more discoverable?
[21:45] <jdstrand> mhall119: if someone is using snappy debug and they hit socketcall, it points them at the bug
[21:45] <jdstrand> mhall119: and the bug has a workaround it in
[21:46] <mhall119> oh, ok
[21:59] <vejmarie> hi
[22:00] <vejmarie> not sure to be at the right place, but I am trying to build up a snap using snapcraft on xenial
[22:00] <vejmarie> and I am stuck with an error from ubuntu-core-launcher
[22:00] <vejmarie> which doesn't find properly python :(
[22:02] <vejmarie> my wrapper into the snap works properly
[22:02] <vejmarie> I am trying to snap FreeCAD a complex piece of code
[22:03] <vejmarie> does somebody can explain me what ubuntu-core-launcher does ?
[23:49] <qengho> vejmarie: the launcher sets up the security contexts and closes file descriptors and such.
[23:49] <vejmarie> yes this is what I am slowly discovering
[23:49] <vejmarie> FreeCAD is a complex piece of code written in C++, which is wrapping python interpreter and dlopen a huge amount of sharelibs
[23:50] <vejmarie> currently if I am launching the wrapper generated by hand it works
[23:51] <vejmarie> if I am launching the snap (which is launching the wrapper through ubuntu-core-launcher) I am having python init issue like if the standard way python discover it's environment doesn't work