=== chihchun is now known as chihchun_afk === markusfluer1 is now known as markusfluer === chihchun_afk is now known as chihchun [07:20] I’m just discovering that Intel Joule I2C and UART ports that work in Core beta 4 don’t work in Desktop (which makes sense). Is the source for the kernel and kernel modules in Snappy available somewhere publically? We’d like to be able to use the latest Intel Joule support in Desktop. Is it possible to run a Snap-based kernel in Desktop? [08:46] alecu: hi [08:59] zyga: hi , does your 3.10 patch be merged into release-2.22.3? [09:01] PR snapd#2889 opened: errtracker: add support for error reporting via daisy.ubuntu.com [09:19] hangun: hey [09:19] hangun: yes it has [09:20] zyga: that'w awewome [09:21] hangun: did it fix your issue? [09:30] zyga: I have upgrade the snap/snapd to 2.22.3 in my ubuntu 16.04, try it soon [09:43] PR snapd#2890 opened: apparmor: added spec === chihchun is now known as chihchun_afk [12:24] heads up that QA is about to approve promoting UAP #34 (amd64) to stable channel. for this particular version it has already been in beta/candidate too so this is about the beta -> stable in practice. [12:51] PR snapd#2786 closed: interfaces: initial unity8 interface [12:55] PR snapd#2790 closed: Add a check for an empty argv in snap-confine.c [12:55] PR snapd#2891 opened: interfaces/udev: added spec [12:57] PR snapd#2807 closed: snap: add new `snap switch` command [13:01] zyga: hi [13:02] mvo: hey [13:02] mvo: is there anything you'd like me to do to my PR to merge the selinux policy module in? https://github.com/snapcore/snapd/pull/2878 [13:02] PR snapd#2878: Merge SELinux policy module [13:03] zyga: the namespace issue is still in my board after upgrading snap to 2.22.3 veriosn [13:04] zyga: snap --version : snap 2.22.3 / snapd 2.22.3 series 16 / ubuntu 16.04 [13:06] zyga: on my board: I ran "snap version" command, it outputs " snap 2.22.3" [13:06] zyga: on my board: I ran "snap version" command, it outputs " snap 2.22.2" [13:08] zyga: host computer: snap version is 2.22.3 . target board: snap version is 2.22.2 [13:28] Son_Goku: nothing to do for you on your side, just looking into some high profile bugs, then this PR will get attention [13:35] hangun: hi [13:35] hangun: in that case can you tell me what error are you seeing now? [13:46] zyga: thanks. I do this commands: $ snap install hello-world. $ hello-world . Then it output error like this: [13:47] zyga: error: can not perform the following tasks: cannot bind-mount the mount namespace file /proc/4598/ns/mnt - hello-world.mnt : permission denied [13:48] zyga: host computer: snap version is 2.22.3 . target board: snap version is 2.22.2 [13:50] zyga: core_1082.snap [14:02] hangun: can you please run "dmesg | grep DENIED" [14:10] zyga: http://pastebin.com/2xJZv3YF [14:15] zyga: hey! is there a way to login to snapd without a prompt for password ? aka a way to pass password through stdin or something ? [14:16] om26er, use sudo and a sudoers.d file snippet ? [14:17] ogra_: I meant past sudo i.e. providing the password for snapd user [14:17] if you use sudo you dont get asked for a password [14:17] at least i dont === hikiko is now known as hikiko|bbl [14:18] on desktop: [14:18] snap login om26er@gmail.com [14:18] Password of "om26er@gmail.com": [14:18] yeah, dont use login at all [14:18] then sudo just works [14:18] ogra_: need to login for very specific testing :) [14:19] on my desktop workstation i never logged in with snapd and can use all my scripts with sudo [14:19] ah, tricky then [14:19] ogra_: you can't download a private snap ;) [14:19] yeah, nothing i touch :) [14:25] hangun: looking [14:26] om26er: not that I know of [14:33] hangun: thanks [14:33] hangun: the 3.10 work I did dind't include apparmor so you got one bug less but still one bug to worry about [14:33] hangun: let me check one thing, I think it is applicable [14:33] hangun: and you can do a simple experiment locally to confirm [14:34] om26er: but you can login over the rest API I think [14:34] om26er: or more precisely -- login locally in any way and save the login data [14:36] zyga: how I do the experiment? [14:36] hangun: edit the apparmor profile for snap-confine [14:36] hangun: can you tell me if you have applied all of the apparmor patches to your kernel? [14:36] hangun: can you paste `find /sys/kernel/security/apparmor` please [14:38] alecu : hi [14:38] santoshmahto: hi! [14:39] zyga: http://pastebin.com/7RfHaw0v [14:40] hangun: hmm, [14:40] hangun: can you come again tomorrow at this time, this is something that jdstrand knows best but he's off today (US holidays) [14:41] zyga: OK, thanks! it's a bit late in my timezone [14:41] hangun: I remember you reported the bug [14:41] hangun: oh, perhaps send an email out with all the details (the bug report is fine, let's just add more data to it) [14:42] hangun: jdstrand is very busy but I'm sure he can get back to you in a few days [14:42] hangun: I see two ideas to experiment: [14:42] hangun: check if you can get a more recent kernel [14:42] hangun: or check if your apparmor support in that kernel is what is in the ubuntu kernel now [14:42] hangun: I heard that apparmor is pretty self-contained and it is easy to port latest fixes [14:43] hangun: the issue feels kernel related but without a way to experiment locally it's hard for me to say exactly what is wrong [14:43] hangun: I bet that across the versions apparmor evolved [14:43] hangun: and that the profile we have for snap-confine (that's what the error is about) is tuned for the latest version we use [14:43] hangun: so maybe there's something simple we can do to make it work there [14:43] hangun: or maybe not and you need to port the more recent apparmor patches [14:43] hangun: but again, hard to say remotely [14:46] zyga: the apparmor patches may be out of date, I ported these patches more than half year ago. [14:48] hangun: I see [14:48] hangun: check out master and see what's there, maybe the delta is small [14:48] hangun: I'm not sure actuall, not a kernel developer [14:48] hangun: the 2nd idea is to disable apparmor in your build [14:48] hangun: no security but it'd start to do stuff [14:49] zyga: thanks [14:49] hangun: for that the easiest way actually is to change /etc/os-release so that it doesn't say ID=ubuntu [14:49] I'm having issues with snap and snapd. trying to use it, it states it cannot communicate with server localhost, snapd-snap.socket cannot be found [14:49] hangun: and re-build snap-conifne (it's not dynamic enough yet) [14:50] cappe: hey, can you tell us more about the environment you are in? which OS, version, snap --version, etc [14:50] Linux silver 4.4.0-63-generic #84-Ubuntu SMP Wed Feb 1 17:20:32 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [14:50] snapversion 2.22.3 [14:51] snapd: unavailable :S [14:51] niemeyer, if you have any time, here there is a change to review in spread https://github.com/snapcore/spread/pull/25 [14:51] PR spread#25: Adding capability to write xunit report with the task suites and results [14:52] zyga: target board's snap veriosn is 2.22.2, it it OK? [14:52] hangun: yes, though we released .3 lately [14:53] cappe: can you look at what is the status of the service with "systemctl status snapd.service" [14:53] I have reinstalled snapd, does it take a reboot? [14:53] cappe: no, no reboot required [14:53] Failed to get properties: No such interface '' [14:53] cappe: oh, interesting [14:53] mvo: ^ [14:54] cappe: can you do: journalctl -u snapd.service | pastebnit [14:54] (install pastebin if you need to) [14:54] zyga: thank you [14:55] pastebnit? is that right spelled? [14:55] cappe: pastebinit is the package [14:55] cappe: sorry, I made a typo above [14:55] paste-bin-it without the dashes :) [14:56] http://paste.ubuntu.com/24034163/ [14:56] hmmm [14:56] empty [14:57] hmm [14:57] cappe: how about 'sudo systemctl start snapd.service' [14:57] same fail [14:58] Unknown unit: snapd.service [15:16] PR snapcraft#1151 closed: channel maps: remove 'Series' from output [15:17] mvo: I think you have encoutered this before, the solving of this issue, I'm reading about it at launchpad.net [15:17] did you guys solve it? [15:18] snap doesnt work: error: cannot communicate with server [15:18] that's the same error I have [15:19] (status: incomplete) guess not [15:20] cappe: unfortunately not, what is the bugnumber? [15:21] cappe: hmm, apt-cache policy snapd [15:21] (or apt list -a snapd) [15:22] Bug #1631514 reported by eduardo on 2016-10-07 [15:22] Bug #1631514: snap doesnt work. error: cannot communicate with server [15:22] PR snapcraft#1147 closed: snapcraft.yaml: 96boards: minimal changes to get a working kernel snap [15:23] snapd/xenial-updates,now 2.22.3 amd64 [installerat] [15:23] snapd/xenial 2.0.2 amd64 [15:34] so I need to wait for a fix then? [16:00] cjwatson: hey, what can I do to sync one github repo to launchpad in a real-time manner [16:00] cjwatson: can I use some hook magic to trigger that? [16:00] cjwatson: a webook on the GH side to pull from LP [16:04] zyga: are you just trying to build a snap from a github repo? [16:04] cjwatson, https://code.launchpad.net/~snappy-dev/+snap/core moved to GH [16:05] cjwatson: we have a GH->LP mirror [16:05] cjwatson: and existing build pipeline in LP [16:05] cjwatson: I'd like to make the changes move faster for this repo [16:05] the prob is that we would now always have to click the import button on the branch to make sure everything is in sync [16:05] LP doesn't accept webhooks yet I'm afraid [16:05] cjwatson, any way to special-case this one branch to run on a shorter schedule at least ? [16:05] you can write something that accepts a webhook and calls the necessary API calls [16:05] no sorry [16:05] cjwatson: could I write a small service that gets poked by GH and then uses LP API to sync? [16:05] yes [16:06] cjwatson: thanks, I think that will do then [16:06] sounds like you should be able to use build.snapcraft.io once it's ready [16:06] cjwatson: can you point me to the API method for updating a git import? [16:06] cjwatson: yes, I think we want to [16:06] https://launchpad.net/+apidoc/devel.html#code_import-requestImport [16:06] cjwatson: does it just set up the (same) process? [16:06] cjwatson: or does it do something different at some level [16:06] that is part of it [16:07] cjwatson: or -- can we use it now? (build.snapcraft.io) [16:07] it doesn't use code imports, it has LP build directly from the GH repo instead [16:07] it's not quite ready [16:07] hmmmm [16:07] LP building directly from the GH repo *requires* webhooks, since LP has no way to detect pushes otherwise [16:08] will it still have a build button ? so you dont have to bump the tree every time you want to trigger a build ? [16:08] cjwatson: could we change the recipe for the snap so that it only builds from GH and webhooks? [16:08] cjwatson: or woud something break today/ [16:08] ogra_: not in the current design [16:08] hrm [16:08] I think it's fine to keep the rest of the workflow as is [16:08] zyga: you might need to create a new snap, I forget [16:09] we just need the helper webhook-poke-lp service [16:09] zyga: please see the API docs though, I'm swamped with building BSI this week [16:09] OK [16:09] thanks for your help! [16:09] (we have a short deadline) [16:09] zyga, well,we still want scheduled builds and the ability to build on demand ... we need to make sure thats still existing if we move over [16:09] ogra_: it will say as is [16:09] ogra_: I'll just make the GH->LP push happen faster [16:09] zyga, well, regarding the snapcraft.io integration [16:09] and we can use that for gadgets as they have the same workflow [16:10] webhook -> code_import.requestImport is the smallest change for you, I think [16:10] ogra_: nah, we won't need that now [16:10] ok [16:10] as cjwatson said :) [16:13] PR snapd#2892 opened: httputils: ensure User-Agent works accross redirects [16:17] mvo, I'd appreciate if the selinux PR could be merged as soon as reasonably possible, since I'm working on a dependent PR to add centos/fedora packaging to snapd repo [16:25] Son_Goku: sure, on it [16:26] Son_Goku: hey o/ [16:26] thank you [16:26] Son_Goku: we had a busy week-end [16:26] did you now? [16:26] Son_Goku: I'm falling on my face but I'll tell you once the dust settles [16:26] Son_Goku: we'll do a post mortem [16:28] something terrible happened? [16:28] post mortem implies horribleness [16:28] Son_Goku: hehe, kind of, we did do a silly thing that quickly showed up on our radar [16:28] Son_Goku: don't do releases on friday they say :) [16:28] that's wise :D [16:29] yes, we have a thing at work called "read only Fridays" [16:29] don't do releases on Fridays, as no one likes the hell that it brings [16:32] zyga: for now, be my merge monkey! https://github.com/snapcore/snapd/pull/2878 [16:32] PR snapd#2878: Merge SELinux policy module [16:32] Son_Goku: yeah, I justs asked gustavo to review it [16:32] Son_Goku: I need to finish a small branch that needs to go into 2.22.4 quickly [16:33] .4 because 2.22 had less luck [16:33] mrrrrgh [16:33] Son_Goku: Heya [16:33] Son_Goku: Trying to understand the delta in licensing there [16:33] Son_Goku: What's the rationale for the v2 vs. v3? [16:34] niemeyer: I want it to remain compatible with fedora-selinux [16:34] I originally derived the structure from a selinux module from upstream selinux-policy [16:34] there's literally no reason for me to break license compatibility [16:35] Son_Goku: If you derived code, shouldn't that be explicit in the (c) notice? [16:35] it also allows for distributions deriving from fedora selinux policies to merge the module into their selinux policy package if they want [16:35] hmm, probably [16:35] I can add a line in the notice for Red Hat copyright [16:36] though I didn't really use much in the way of "code" [16:36] just the skeleton [16:36] Son_Goku: Yeah, that's the right thing to do.. we still have the option to relicense as v3 per the license terms itself, but then it'd actually be a more clear departure [16:37] Son_Goku: As it is now it's awkward, because it looks like you're creating code yourself and contributing into snapd with your own license [16:37] Which means _that's_ the license "break" [16:38] makefile is mine though [16:38] heya there. I am using the python plugin and having some strange issues. The following is happening to me: http://pastebin.com/RZnQP3GY [16:39] Son_Goku: Sure.. for content you are creating for snapd, the normal thing to do is to license per the project license [16:39] niemeyer: would this work "Skeleton derived from fedora selinux-policy, Copyright (C) 2016 Red Hat, Inc."? [16:39] Son_Goku: Sounds good [16:39] adding it now [16:39] one sec [16:42] niemeyer: done, rewrote the commit for adding the header to include the extra comment [16:42] https://github.com/snapcore/snapd/pull/2878/commits/f04da024b6221f539e50466ac7c6a0a21dcda837 [16:42] PR snapd#2878: Merge SELinux policy module [16:42] Looking again [16:43] Hi guys, I have a problem with snap and the interface camera: [16:43] sudo snap connect myapp:camera ubuntu-core:camera I have this error: snap "ubuntu-core" has no slot named "camera" [16:43] EEight: try sudo snap connect myapp:camera [16:44] EEight: that does the right thing and it finds the core snap (no longer called ubuntu-core) and the matching interface [16:44] will do but still when snapping it's not working automagically [16:44] https://bugs.launchpad.net/snapcraft/+bug/1609577 [16:44] Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed [16:44] Son_Goku, zyga: Okay, we should eventually ask jdstrand to have a pass over this, but let's get it in now [16:46] niemeyer: it has no effect for you guys anyway [16:46] I didn't wire up the debian packaging to build the module [16:46] mainly because I don't know how [16:46] Son_Goku: Well, of course it does.. that's why we're getting it in! :) [16:46] well, you guys being ubuntu people :) [16:46] Son_Goku: We care about distros that depend on selinux too.. [16:46] but yes, thanks [16:47] well, the debian hardened guys will appreciate it once there is a snapd-selinux module for debian, too [16:47] err, snapd-selinux package [16:47] +1 [16:47] I did make it debian-safe :) [16:47] I'm not mean, after all :P [16:48] zyga: yes it's working when sudo snap connect myapp:camera - but of course I cannot ask my user to run this command. Is there a way to make it works out-of-the-box? [16:48] Son_Goku: woot, thanks for working on this for so long :) [16:48] * Son_Goku sighs [16:48] EEight: yes, your snap can contain a declaration that will make this happen by default [16:48] I learned a lot about selinux verbiage [16:48] EEight: it is something the store can give you, I'm not sure what is the process for this [16:49] EEight: I think that jdstrand is the best person to ask; he should be around tomorrow [16:50] niemeyer: I'd be super pleased if snapd's official dsc packaging also shipped the selinux module [16:50] Son_Goku: I think we can look at that for debian 10 [16:50] zyga: it can also be available as stretch backports [16:50] Son_Goku: I don't know all the details involved, but on principle it certainly sounds fine [16:54] Son_Goku: yeah, I think we will polish it release by release [16:54] Son_Goku: it would be good to find someone that cares about debian and selinux there === hikiko|bbl is now known as hikiko [17:09] oh come on! [17:09] I didn't even change anything and travis broke [17:09] zyga, niemeyer: I hate travis :/ [17:09] Son_Goku: no that's us [17:09] Son_Goku: we did some shuffling with the core snap [17:09] Son_Goku: busy weekend [17:09] ah [17:09] Son_Goku: we'll try to revert things to as they were over the next 18 hours [17:09] Son_Goku: that's why 2.22.4 goes out soon [17:09] Son_Goku: the store was hit with a bug where snapd would download stuff over and over [17:09] those are the best bugs [17:09] Son_Goku: and we looked at preventing that, figuring out why it happens and fixing the issue [17:10] zyga: That's a massive failure.. what happened there? [17:10] niemeyer: in the spread test suite? [17:10] zyga: I mean, why is the test exploding in that way specifically? [17:11] Yeah [17:11] niemeyer: the core snap that is published now has no configure hook [17:11] niemeyer: and tests check for that [17:11] unless something new broke that was what was failing all day today [17:11] niemeyer: mvo wanted not to change the tests for that (federico suggested this) [17:11] zyga: Ugh :( [17:11] Yeah, well.. it does sounds sane.. we want this working [17:12] Let's get 2.22.4 out then [17:12] niemeyer: the idea is that now we send and update that gives us visibility into errors and should apply anywhere [17:12] niemeyer: and next we enable the configure hook [17:12] niemeyer: and see the actual errors [17:12] +1 [17:12] niemeyer: so after 2.22.4 is out we'll do .5 that just enables the hook === JanC is now known as Guest41946 === JanC_ is now known as JanC [17:17] zyga, niemeyer if you need to do a quick local spread run just commenting out the "snap set core refresh.disabled=true" lines in tests/lib/prepare.sh is enough for getting the current master working [17:19] if the test you run doesn't involve "snap set core", of course [18:45] PR snapd#2893 opened: tests: bail out if core snap is not installed [19:34] PR snapd#2892 closed: httputils: ensure User-Agent works accross redirects [19:37] Hi where can I find a list of Ubuntu core relases and their dates? I am trying to trouble shooting something. thanks [19:54] zyga_: why did everything fail? https://github.com/snapcore/snapd/pull/2878 [19:54] PR snapd#2878: Merge SELinux policy module [19:54] oh [19:54] this is related to core snap funkiness [19:54] mrrr [19:59] Hi all, we are using current snap core (revision version 16.04.1 revision 1226), we got kernal panic when intalling our own snap. [20:00] We'd like to use an old snap core, how do we find out the old core rease dates so that we can pick the core that was working for us? [20:03] btw, this is for PI2 and PI3. [20:03] linggao: snap list core will tell you the revision [20:03] If that's what you're asking [20:04] kalikiana_, I know the current version. I would like to get a history of the old revisions. [20:09] linggao: To check the previous revisions you can ls /snap/core/ [20:09] That's the best way I know of to see recent updates [20:10] 'snap changes' would be what I'd like to say, but it doesn't tell you that [20:12] kalikiana_, my node only has 1226. is there a web site that list all the revisions and their dates? [21:11] King_InuYasha: hey [21:11] hey [21:11] King_InuYasha: yeah, we're in an emergency a little and this is expected; it should be back to normal in a day [21:12] linggao: hey, what was the kernel panic? [21:14] linggao: you cannot download releases other than the one that is current I'm afraid [21:15] zyga_, kernel panic happend when mounting our snap. (on pi2 and pi3). [336032.404195] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [21:15] [336032.417227] pgd = b66fc000 [21:15] [336032.422448] [00000008] *pgd=21359831, *pte=00000000, *ppte=00000000 [21:15] [336032.432174] Internal error: Oops: 17 [#1] SMP ARM [21:15] linggao: can you report this please [21:16] zyga_, can we do `snap install --revision xxx core`? [21:16] linggao: no, you can only do that to the snap you own [21:16] linggao: also old core had the same kernel (kernel is a separate snap) [21:16] linggao: so I'm not sure that would help you === Mani is now known as Guest46494 [21:18] zyga_, we know that upgrading to the latest kernel resoves this problem [21:18] linggao: as in latest mainline kernel? [21:18] linggao: do you use the official pi2/3 kernel snap or do you roll your own? [21:19] But we are trying to go back to see where the problem was. It used to work. We are trying to figure out if it was because of our own snap. [21:20] We build pi2 images based on your offical pi2/pi3 images. [21:20] IMAGE="ubuntu-16.04-preinstalled-server-armhf+raspi2.img" [21:20] URL="http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/$IMAGE.xz" [21:21] Now we have to run 'apt upgrade' to upgrade to the latest kernl to resolve that problem [21:21] It uesed to work. [21:21] linggao: ah, I thought you were using core images, those are classic images with snapd [21:22] That's why we susppect that core could be a problem. [21:23] linggao: in any case, please report the problem [21:23] linggao: attach the kernel log [21:23] linggao: attach the snap if you can [21:24] I have reported a similar problem with snap refresh. https://bugs.launchpad.net/snapd/+bug/1664368 [21:24] Bug #1664368: snap refresh hangs on arm architecture

[21:25] linggao: that seems to have been fixed [21:27] zyga_, when I do 'snap list' I see 'core'. Was core got installed when I install my own snap? [21:28] zyga_, my boss told me to figure out why the old kernel worked before. :( [21:30] PR snapd#2894 opened: snapstate: allow for 10 retries for the core transition [21:31] linggao: yes [21:32] linggao: on a deb based system you can install the old kernel deb but those are not kept aroud either [21:33] linggao: if you have it just install it [21:33] linggao: or rebuild it from sure [21:34] zyga_, our theory is that since we still use the old kernel, and things get broken, it must be core whcih might be new that caused the kernel panic. That's why I was looking for old cores to test our theory. [21:34] linggao: well, that's a little odd, the kernel contains nothing that ia a part of the equation [21:34] linggao: you can just mount your squashfs without the core at all [21:34] linggao: if that oopses, it oopses, the kernel is broken [21:35] linggao: there's no core that you need to experiment with this [21:35] The reason we cannot support the new kernel yet is because it does not work with the onboard widi for pi3. [21:35]