| === chihchun is now known as chihchun_afk | ||
| === markusfluer1 is now known as markusfluer | ||
| === chihchun_afk is now known as chihchun | ||
| thos37 | 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? | 07:20 |
|---|---|---|
| santoshmahto | alecu: hi | 08:46 |
| hangun | zyga: hi , does your 3.10 patch be merged into release-2.22.3? | 08:59 |
| mup | PR snapd#2889 opened: errtracker: add support for error reporting via daisy.ubuntu.com <Created by mvo5> <https://github.com/snapcore/snapd/pull/2889> | 09:01 |
| zyga | hangun: hey | 09:19 |
| zyga | hangun: yes it has | 09:19 |
| hangun | zyga: that'w awewome | 09:20 |
| zyga | hangun: did it fix your issue? | 09:21 |
| hangun | zyga: I have upgrade the snap/snapd to 2.22.3 in my ubuntu 16.04, try it soon | 09:30 |
| mup | PR snapd#2890 opened: apparmor: added spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2890> | 09:43 |
| === chihchun is now known as chihchun_afk | ||
| Mirv | 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:24 |
| mup | PR snapd#2786 closed: interfaces: initial unity8 interface <Created by mikix> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2786> | 12:51 |
| mup | PR snapd#2790 closed: Add a check for an empty argv in snap-confine.c <Created by eriksjolund> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2790> | 12:55 |
| mup | PR snapd#2891 opened: interfaces/udev: added spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2891> | 12:55 |
| mup | PR snapd#2807 closed: snap: add new `snap switch` command <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2807> | 12:57 |
| hangun | zyga: hi | 13:01 |
| Son_Goku | mvo: hey | 13:02 |
| Son_Goku | 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 |
| mup | PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878> | 13:02 |
| hangun | zyga: the namespace issue is still in my board after upgrading snap to 2.22.3 veriosn | 13:03 |
| hangun | zyga: snap --version : snap 2.22.3 / snapd 2.22.3 series 16 / ubuntu 16.04 | 13:04 |
| hangun | zyga: on my board: I ran "snap version" command, it outputs " snap 2.22.3" | 13:06 |
| hangun | zyga: on my board: I ran "snap version" command, it outputs " snap 2.22.2" | 13:06 |
| hangun | zyga: host computer: snap version is 2.22.3 . target board: snap version is 2.22.2 | 13:08 |
| mvo | Son_Goku: nothing to do for you on your side, just looking into some high profile bugs, then this PR will get attention | 13:28 |
| zyga | hangun: hi | 13:35 |
| zyga | hangun: in that case can you tell me what error are you seeing now? | 13:35 |
| hangun | zyga: thanks. I do this commands: $ snap install hello-world. $ hello-world . Then it output error like this: | 13:46 |
| hangun | 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:47 |
| hangun | zyga: host computer: snap version is 2.22.3 . target board: snap version is 2.22.2 | 13:48 |
| hangun | zyga: core_1082.snap | 13:50 |
| zyga | hangun: can you please run "dmesg | grep DENIED" | 14:02 |
| hangun | zyga: http://pastebin.com/2xJZv3YF | 14:10 |
| om26er | 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:15 |
| ogra_ | om26er, use sudo and a sudoers.d file snippet ? | 14:16 |
| om26er | ogra_: I meant past sudo i.e. providing the password for snapd user | 14:17 |
| ogra_ | if you use sudo you dont get asked for a password | 14:17 |
| ogra_ | at least i dont | 14:17 |
| === hikiko is now known as hikiko|bbl | ||
| om26er | on desktop: | 14:18 |
| om26er | snap login om26er@gmail.com | 14:18 |
| om26er | Password of "om26er@gmail.com": | 14:18 |
| ogra_ | yeah, dont use login at all | 14:18 |
| ogra_ | then sudo just works | 14:18 |
| om26er | ogra_: need to login for very specific testing :) | 14:18 |
| ogra_ | on my desktop workstation i never logged in with snapd and can use all my scripts with sudo | 14:19 |
| ogra_ | ah, tricky then | 14:19 |
| om26er | ogra_: you can't download a private snap ;) | 14:19 |
| ogra_ | yeah, nothing i touch :) | 14:19 |
| zyga | hangun: looking | 14:25 |
| zyga | om26er: not that I know of | 14:26 |
| zyga | hangun: thanks | 14:33 |
| zyga | 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 |
| zyga | hangun: let me check one thing, I think it is applicable | 14:33 |
| zyga | hangun: and you can do a simple experiment locally to confirm | 14:33 |
| zyga | om26er: but you can login over the rest API I think | 14:34 |
| zyga | om26er: or more precisely -- login locally in any way and save the login data | 14:34 |
| hangun | zyga: how I do the experiment? | 14:36 |
| zyga | hangun: edit the apparmor profile for snap-confine | 14:36 |
| zyga | hangun: can you tell me if you have applied all of the apparmor patches to your kernel? | 14:36 |
| zyga | hangun: can you paste `find /sys/kernel/security/apparmor` please | 14:36 |
| santoshmahto | alecu : hi | 14:38 |
| alecu | santoshmahto: hi! | 14:38 |
| hangun | zyga: http://pastebin.com/7RfHaw0v | 14:39 |
| zyga | hangun: hmm, | 14:40 |
| zyga | hangun: can you come again tomorrow at this time, this is something that jdstrand knows best but he's off today (US holidays) | 14:40 |
| hangun | zyga: OK, thanks! it's a bit late in my timezone | 14:41 |
| zyga | hangun: I remember you reported the bug | 14:41 |
| zyga | 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:41 |
| zyga | hangun: jdstrand is very busy but I'm sure he can get back to you in a few days | 14:42 |
| zyga | hangun: I see two ideas to experiment: | 14:42 |
| zyga | hangun: check if you can get a more recent kernel | 14:42 |
| zyga | hangun: or check if your apparmor support in that kernel is what is in the ubuntu kernel now | 14:42 |
| zyga | hangun: I heard that apparmor is pretty self-contained and it is easy to port latest fixes | 14:42 |
| zyga | 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 |
| zyga | hangun: I bet that across the versions apparmor evolved | 14:43 |
| zyga | 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 |
| zyga | hangun: so maybe there's something simple we can do to make it work there | 14:43 |
| zyga | hangun: or maybe not and you need to port the more recent apparmor patches | 14:43 |
| zyga | hangun: but again, hard to say remotely | 14:43 |
| hangun | zyga: the apparmor patches may be out of date, I ported these patches more than half year ago. | 14:46 |
| zyga | hangun: I see | 14:48 |
| zyga | hangun: check out master and see what's there, maybe the delta is small | 14:48 |
| zyga | hangun: I'm not sure actuall, not a kernel developer | 14:48 |
| zyga | hangun: the 2nd idea is to disable apparmor in your build | 14:48 |
| zyga | hangun: no security but it'd start to do stuff | 14:48 |
| hangun | zyga: thanks | 14:49 |
| zyga | hangun: for that the easiest way actually is to change /etc/os-release so that it doesn't say ID=ubuntu | 14:49 |
| cappe | 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 |
| zyga | hangun: and re-build snap-conifne (it's not dynamic enough yet) | 14:49 |
| zyga | cappe: hey, can you tell us more about the environment you are in? which OS, version, snap --version, etc | 14:50 |
| cappe | 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 |
| cappe | snapversion 2.22.3 | 14:50 |
| cappe | snapd: unavailable :S | 14:51 |
| cachio | niemeyer, if you have any time, here there is a change to review in spread https://github.com/snapcore/spread/pull/25 | 14:51 |
| mup | PR spread#25: Adding capability to write xunit report with the task suites and results <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/25> | 14:51 |
| hangun | zyga: target board's snap veriosn is 2.22.2, it it OK? | 14:52 |
| zyga | hangun: yes, though we released .3 lately | 14:52 |
| zyga | cappe: can you look at what is the status of the service with "systemctl status snapd.service" | 14:53 |
| cappe | I have reinstalled snapd, does it take a reboot? | 14:53 |
| zyga | cappe: no, no reboot required | 14:53 |
| cappe | Failed to get properties: No such interface '' | 14:53 |
| zyga | cappe: oh, interesting | 14:53 |
| zyga | mvo: ^ | 14:53 |
| zyga | cappe: can you do: journalctl -u snapd.service | pastebnit | 14:54 |
| zyga | (install pastebin if you need to) | 14:54 |
| mvo | zyga: thank you | 14:54 |
| cappe | pastebnit? is that right spelled? | 14:55 |
| zyga | cappe: pastebinit is the package | 14:55 |
| zyga | cappe: sorry, I made a typo above | 14:55 |
| zyga | paste-bin-it without the dashes :) | 14:55 |
| cappe | http://paste.ubuntu.com/24034163/ | 14:56 |
| zyga | hmmm | 14:56 |
| zyga | empty | 14:56 |
| zyga | hmm | 14:57 |
| zyga | cappe: how about 'sudo systemctl start snapd.service' | 14:57 |
| cappe | same fail | 14:57 |
| cappe | Unknown unit: snapd.service | 14:58 |
| mup | PR snapcraft#1151 closed: channel maps: remove 'Series' from output <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1151> | 15:16 |
| cappe | mvo: I think you have encoutered this before, the solving of this issue, I'm reading about it at launchpad.net | 15:17 |
| cappe | did you guys solve it? | 15:17 |
| cappe | snap doesnt work: error: cannot communicate with server | 15:18 |
| cappe | that's the same error I have | 15:18 |
| cappe | (status: incomplete) guess not | 15:19 |
| mvo | cappe: unfortunately not, what is the bugnumber? | 15:20 |
| zyga | cappe: hmm, apt-cache policy snapd | 15:21 |
| mvo | (or apt list -a snapd) | 15:21 |
| cappe | Bug #1631514 reported by eduardo on 2016-10-07 | 15:22 |
| mup | Bug #1631514: snap doesnt work. error: cannot communicate with server <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1631514> | 15:22 |
| mup | PR snapcraft#1147 closed: snapcraft.yaml: 96boards: minimal changes to get a working kernel snap <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1147> | 15:22 |
| cappe | snapd/xenial-updates,now 2.22.3 amd64 [installerat] | 15:23 |
| cappe | snapd/xenial 2.0.2 amd64 | 15:23 |
| cappe | so I need to wait for a fix then? | 15:34 |
| zyga | cjwatson: hey, what can I do to sync one github repo to launchpad in a real-time manner | 16:00 |
| zyga | cjwatson: can I use some hook magic to trigger that? | 16:00 |
| zyga | cjwatson: a webook on the GH side to pull from LP | 16:00 |
| cjwatson | zyga: are you just trying to build a snap from a github repo? | 16:04 |
| ogra_ | cjwatson, https://code.launchpad.net/~snappy-dev/+snap/core moved to GH | 16:04 |
| zyga | cjwatson: we have a GH->LP mirror | 16:05 |
| zyga | cjwatson: and existing build pipeline in LP | 16:05 |
| zyga | cjwatson: I'd like to make the changes move faster for this repo | 16:05 |
| ogra_ | 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 |
| cjwatson | LP doesn't accept webhooks yet I'm afraid | 16:05 |
| ogra_ | cjwatson, any way to special-case this one branch to run on a shorter schedule at least ? | 16:05 |
| cjwatson | you can write something that accepts a webhook and calls the necessary API calls | 16:05 |
| cjwatson | no sorry | 16:05 |
| zyga | cjwatson: could I write a small service that gets poked by GH and then uses LP API to sync? | 16:05 |
| cjwatson | yes | 16:05 |
| zyga | cjwatson: thanks, I think that will do then | 16:06 |
| cjwatson | sounds like you should be able to use build.snapcraft.io once it's ready | 16:06 |
| zyga | cjwatson: can you point me to the API method for updating a git import? | 16:06 |
| zyga | cjwatson: yes, I think we want to | 16:06 |
| cjwatson | https://launchpad.net/+apidoc/devel.html#code_import-requestImport | 16:06 |
| zyga | cjwatson: does it just set up the (same) process? | 16:06 |
| zyga | cjwatson: or does it do something different at some level | 16:06 |
| cjwatson | that is part of it | 16:06 |
| zyga | cjwatson: or -- can we use it now? (build.snapcraft.io) | 16:07 |
| cjwatson | it doesn't use code imports, it has LP build directly from the GH repo instead | 16:07 |
| cjwatson | it's not quite ready | 16:07 |
| zyga | hmmmm | 16:07 |
| cjwatson | LP building directly from the GH repo *requires* webhooks, since LP has no way to detect pushes otherwise | 16:07 |
| ogra_ | 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 |
| zyga | cjwatson: could we change the recipe for the snap so that it only builds from GH and webhooks? | 16:08 |
| zyga | cjwatson: or woud something break today/ | 16:08 |
| cjwatson | ogra_: not in the current design | 16:08 |
| ogra_ | hrm | 16:08 |
| zyga | I think it's fine to keep the rest of the workflow as is | 16:08 |
| cjwatson | zyga: you might need to create a new snap, I forget | 16:08 |
| zyga | we just need the helper webhook-poke-lp service | 16:09 |
| cjwatson | zyga: please see the API docs though, I'm swamped with building BSI this week | 16:09 |
| zyga | OK | 16:09 |
| zyga | thanks for your help! | 16:09 |
| cjwatson | (we have a short deadline) | 16:09 |
| ogra_ | 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 |
| zyga | ogra_: it will say as is | 16:09 |
| zyga | ogra_: I'll just make the GH->LP push happen faster | 16:09 |
| ogra_ | zyga, well, regarding the snapcraft.io integration | 16:09 |
| zyga | and we can use that for gadgets as they have the same workflow | 16:09 |
| cjwatson | webhook -> code_import.requestImport is the smallest change for you, I think | 16:10 |
| zyga | ogra_: nah, we won't need that now | 16:10 |
| ogra_ | ok | 16:10 |
| zyga | as cjwatson said :) | 16:10 |
| mup | PR snapd#2892 opened: httputils: ensure User-Agent works accross redirects <Created by mvo5> <https://github.com/snapcore/snapd/pull/2892> | 16:13 |
| Son_Goku | 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:17 |
| mvo | Son_Goku: sure, on it | 16:25 |
| zyga | Son_Goku: hey o/ | 16:26 |
| Son_Goku | thank you | 16:26 |
| zyga | Son_Goku: we had a busy week-end | 16:26 |
| Son_Goku | did you now? | 16:26 |
| zyga | Son_Goku: I'm falling on my face but I'll tell you once the dust settles | 16:26 |
| zyga | Son_Goku: we'll do a post mortem | 16:26 |
| Son_Goku | something terrible happened? | 16:28 |
| Son_Goku | post mortem implies horribleness | 16:28 |
| zyga | Son_Goku: hehe, kind of, we did do a silly thing that quickly showed up on our radar | 16:28 |
| zyga | Son_Goku: don't do releases on friday they say :) | 16:28 |
| zyga | that's wise :D | 16:28 |
| Son_Goku | yes, we have a thing at work called "read only Fridays" | 16:29 |
| Son_Goku | don't do releases on Fridays, as no one likes the hell that it brings | 16:29 |
| Son_Goku | zyga: for now, be my merge monkey! https://github.com/snapcore/snapd/pull/2878 | 16:32 |
| mup | PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878> | 16:32 |
| zyga | Son_Goku: yeah, I justs asked gustavo to review it | 16:32 |
| zyga | Son_Goku: I need to finish a small branch that needs to go into 2.22.4 quickly | 16:32 |
| zyga | .4 because 2.22 had less luck | 16:33 |
| Son_Goku | mrrrrgh | 16:33 |
| niemeyer | Son_Goku: Heya | 16:33 |
| niemeyer | Son_Goku: Trying to understand the delta in licensing there | 16:33 |
| niemeyer | Son_Goku: What's the rationale for the v2 vs. v3? | 16:33 |
| Son_Goku | niemeyer: I want it to remain compatible with fedora-selinux | 16:34 |
| Son_Goku | I originally derived the structure from a selinux module from upstream selinux-policy | 16:34 |
| Son_Goku | there's literally no reason for me to break license compatibility | 16:34 |
| niemeyer | Son_Goku: If you derived code, shouldn't that be explicit in the (c) notice? | 16:35 |
| Son_Goku | it also allows for distributions deriving from fedora selinux policies to merge the module into their selinux policy package if they want | 16:35 |
| Son_Goku | hmm, probably | 16:35 |
| Son_Goku | I can add a line in the notice for Red Hat copyright | 16:35 |
| Son_Goku | though I didn't really use much in the way of "code" | 16:36 |
| Son_Goku | just the skeleton | 16:36 |
| niemeyer | 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:36 |
| niemeyer | 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 |
| niemeyer | Which means _that's_ the license "break" | 16:37 |
| Son_Goku | makefile is mine though | 16:38 |
| Fohlen- | heya there. I am using the python plugin and having some strange issues. The following is happening to me: http://pastebin.com/RZnQP3GY | 16:38 |
| niemeyer | Son_Goku: Sure.. for content you are creating for snapd, the normal thing to do is to license per the project license | 16:39 |
| Son_Goku | niemeyer: would this work "Skeleton derived from fedora selinux-policy, Copyright (C) 2016 Red Hat, Inc."? | 16:39 |
| niemeyer | Son_Goku: Sounds good | 16:39 |
| Son_Goku | adding it now | 16:39 |
| Son_Goku | one sec | 16:39 |
| Son_Goku | niemeyer: done, rewrote the commit for adding the header to include the extra comment | 16:42 |
| Son_Goku | https://github.com/snapcore/snapd/pull/2878/commits/f04da024b6221f539e50466ac7c6a0a21dcda837 | 16:42 |
| mup | PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878> | 16:42 |
| niemeyer | Looking again | 16:42 |
| EEight | Hi guys, I have a problem with snap and the interface camera: | 16:43 |
| EEight | sudo snap connect myapp:camera ubuntu-core:camera I have this error: snap "ubuntu-core" has no slot named "camera" | 16:43 |
| zyga | EEight: try sudo snap connect myapp:camera | 16:43 |
| zyga | EEight: that does the right thing and it finds the core snap (no longer called ubuntu-core) and the matching interface | 16:44 |
| EEight | will do but still when snapping it's not working automagically | 16:44 |
| EEight | https://bugs.launchpad.net/snapcraft/+bug/1609577 | 16:44 |
| mup | Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed <Snapcraft:New> <https://launchpad.net/bugs/1609577> | 16:44 |
| niemeyer | Son_Goku, zyga: Okay, we should eventually ask jdstrand to have a pass over this, but let's get it in now | 16:44 |
| Son_Goku | niemeyer: it has no effect for you guys anyway | 16:46 |
| Son_Goku | I didn't wire up the debian packaging to build the module | 16:46 |
| Son_Goku | mainly because I don't know how | 16:46 |
| niemeyer | Son_Goku: Well, of course it does.. that's why we're getting it in! :) | 16:46 |
| Son_Goku | well, you guys being ubuntu people :) | 16:46 |
| niemeyer | Son_Goku: We care about distros that depend on selinux too.. | 16:46 |
| Son_Goku | but yes, thanks | 16:46 |
| Son_Goku | well, the debian hardened guys will appreciate it once there is a snapd-selinux module for debian, too | 16:47 |
| Son_Goku | err, snapd-selinux package | 16:47 |
| niemeyer | +1 | 16:47 |
| Son_Goku | I did make it debian-safe :) | 16:47 |
| Son_Goku | I'm not mean, after all :P | 16:47 |
| EEight | 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 |
| zyga | Son_Goku: woot, thanks for working on this for so long :) | 16:48 |
| * Son_Goku sighs | 16:48 | |
| zyga | EEight: yes, your snap can contain a declaration that will make this happen by default | 16:48 |
| Son_Goku | I learned a lot about selinux verbiage | 16:48 |
| zyga | EEight: it is something the store can give you, I'm not sure what is the process for this | 16:48 |
| zyga | EEight: I think that jdstrand is the best person to ask; he should be around tomorrow | 16:49 |
| Son_Goku | niemeyer: I'd be super pleased if snapd's official dsc packaging also shipped the selinux module | 16:50 |
| zyga | Son_Goku: I think we can look at that for debian 10 | 16:50 |
| Son_Goku | zyga: it can also be available as stretch backports | 16:50 |
| niemeyer | Son_Goku: I don't know all the details involved, but on principle it certainly sounds fine | 16:50 |
| zyga | Son_Goku: yeah, I think we will polish it release by release | 16:54 |
| zyga | Son_Goku: it would be good to find someone that cares about debian and selinux there | 16:54 |
| === hikiko|bbl is now known as hikiko | ||
| Son_Goku | oh come on! | 17:09 |
| Son_Goku | I didn't even change anything and travis broke | 17:09 |
| Son_Goku | zyga, niemeyer: I hate travis :/ | 17:09 |
| zyga | Son_Goku: no that's us | 17:09 |
| zyga | Son_Goku: we did some shuffling with the core snap | 17:09 |
| zyga | Son_Goku: busy weekend | 17:09 |
| Son_Goku | ah | 17:09 |
| zyga | Son_Goku: we'll try to revert things to as they were over the next 18 hours | 17:09 |
| zyga | Son_Goku: that's why 2.22.4 goes out soon | 17:09 |
| zyga | Son_Goku: the store was hit with a bug where snapd would download stuff over and over | 17:09 |
| Son_Goku | those are the best bugs | 17:09 |
| zyga | Son_Goku: and we looked at preventing that, figuring out why it happens and fixing the issue | 17:09 |
| niemeyer | zyga: That's a massive failure.. what happened there? | 17:10 |
| zyga | niemeyer: in the spread test suite? | 17:10 |
| niemeyer | zyga: I mean, why is the test exploding in that way specifically? | 17:10 |
| niemeyer | Yeah | 17:11 |
| zyga | niemeyer: the core snap that is published now has no configure hook | 17:11 |
| zyga | niemeyer: and tests check for that | 17:11 |
| zyga | unless something new broke that was what was failing all day today | 17:11 |
| zyga | niemeyer: mvo wanted not to change the tests for that (federico suggested this) | 17:11 |
| niemeyer | zyga: Ugh :( | 17:11 |
| niemeyer | Yeah, well.. it does sounds sane.. we want this working | 17:11 |
| niemeyer | Let's get 2.22.4 out then | 17:12 |
| zyga | niemeyer: the idea is that now we send and update that gives us visibility into errors and should apply anywhere | 17:12 |
| zyga | niemeyer: and next we enable the configure hook | 17:12 |
| zyga | niemeyer: and see the actual errors | 17:12 |
| niemeyer | +1 | 17:12 |
| zyga | niemeyer: so after 2.22.4 is out we'll do .5 that just enables the hook | 17:12 |
| === JanC is now known as Guest41946 | ||
| === JanC_ is now known as JanC | ||
| fgimenez | 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:17 |
| fgimenez | if the test you run doesn't involve "snap set core", of course | 17:19 |
| mup | PR snapd#2893 opened: tests: bail out if core snap is not installed <Created by zyga> <https://github.com/snapcore/snapd/pull/2893> | 18:45 |
| mup | PR snapd#2892 closed: httputils: ensure User-Agent works accross redirects <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2892> | 19:34 |
| linggao | Hi where can I find a list of Ubuntu core relases and their dates? I am trying to trouble shooting something. thanks | 19:37 |
| King_InuYasha | zyga_: why did everything fail? https://github.com/snapcore/snapd/pull/2878 | 19:54 |
| mup | PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878> | 19:54 |
| King_InuYasha | oh | 19:54 |
| King_InuYasha | this is related to core snap funkiness | 19:54 |
| King_InuYasha | mrrr | 19:54 |
| linggao | Hi all, we are using current snap core (revision version 16.04.1 revision 1226), we got kernal panic when intalling our own snap. | 19:59 |
| linggao | 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:00 |
| linggao | btw, this is for PI2 and PI3. | 20:03 |
| kalikiana_ | linggao: snap list core will tell you the revision | 20:03 |
| kalikiana_ | If that's what you're asking | 20:03 |
| linggao | kalikiana_, I know the current version. I would like to get a history of the old revisions. | 20:04 |
| kalikiana_ | linggao: To check the previous revisions you can ls /snap/core/ | 20:09 |
| kalikiana_ | That's the best way I know of to see recent updates | 20:09 |
| kalikiana_ | 'snap changes' would be what I'd like to say, but it doesn't tell you that | 20:10 |
| linggao | kalikiana_, my node only has 1226. is there a web site that list all the revisions and their dates? | 20:12 |
| zyga_ | King_InuYasha: hey | 21:11 |
| King_InuYasha | hey | 21:11 |
| zyga_ | King_InuYasha: yeah, we're in an emergency a little and this is expected; it should be back to normal in a day | 21:11 |
| zyga_ | linggao: hey, what was the kernel panic? | 21:12 |
| zyga_ | linggao: you cannot download releases other than the one that is current I'm afraid | 21:14 |
| linggao | 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 |
| linggao | [336032.417227] pgd = b66fc000 | 21:15 |
| linggao | [336032.422448] [00000008] *pgd=21359831, *pte=00000000, *ppte=00000000 | 21:15 |
| linggao | [336032.432174] Internal error: Oops: 17 [#1] SMP ARM | 21:15 |
| zyga_ | linggao: can you report this please | 21:15 |
| linggao | zyga_, can we do `snap install --revision xxx core`? | 21:16 |
| zyga_ | linggao: no, you can only do that to the snap you own | 21:16 |
| zyga_ | linggao: also old core had the same kernel (kernel is a separate snap) | 21:16 |
| zyga_ | linggao: so I'm not sure that would help you | 21:16 |
| === Mani is now known as Guest46494 | ||
| linggao | zyga_, we know that upgrading to the latest kernel resoves this problem | 21:18 |
| zyga_ | linggao: as in latest mainline kernel? | 21:18 |
| zyga_ | linggao: do you use the official pi2/3 kernel snap or do you roll your own? | 21:18 |
| linggao | 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:19 |
| linggao | We build pi2 images based on your offical pi2/pi3 images. | 21:20 |
| linggao | IMAGE="ubuntu-16.04-preinstalled-server-armhf+raspi2.img" | 21:20 |
| linggao | URL="http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/$IMAGE.xz" | 21:20 |
| linggao | Now we have to run 'apt upgrade' to upgrade to the latest kernl to resolve that problem | 21:21 |
| linggao | It uesed to work. | 21:21 |
| zyga_ | linggao: ah, I thought you were using core images, those are classic images with snapd | 21:21 |
| linggao | That's why we susppect that core could be a problem. | 21:22 |
| zyga_ | linggao: in any case, please report the problem | 21:23 |
| zyga_ | linggao: attach the kernel log | 21:23 |
| zyga_ | linggao: attach the snap if you can | 21:23 |
| linggao | I have reported a similar problem with snap refresh. https://bugs.launchpad.net/snapd/+bug/1664368 | 21:24 |
| mup | Bug #1664368: snap refresh hangs on arm architecture <snapd:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1664368> | 21:24 |
| zyga_ | linggao: that seems to have been fixed | 21:25 |
| linggao | zyga_, when I do 'snap list' I see 'core'. Was core got installed when I install my own snap? | 21:27 |
| linggao | zyga_, my boss told me to figure out why the old kernel worked before. :( | 21:28 |
| mup | PR snapd#2894 opened: snapstate: allow for 10 retries for the core transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/2894> | 21:30 |
| zyga_ | linggao: yes | 21:31 |
| zyga_ | linggao: on a deb based system you can install the old kernel deb but those are not kept aroud either | 21:32 |
| zyga_ | linggao: if you have it just install it | 21:33 |
| zyga_ | linggao: or rebuild it from sure | 21:33 |
| linggao | 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 |
| zyga_ | linggao: well, that's a little odd, the kernel contains nothing that ia a part of the equation | 21:34 |
| zyga_ | linggao: you can just mount your squashfs without the core at all | 21:34 |
| zyga_ | linggao: if that oopses, it oopses, the kernel is broken | 21:34 |
| zyga_ | linggao: there's no core that you need to experiment with this | 21:35 |
| linggao | The reason we cannot support the new kernel yet is because it does not work with the onboard widi for pi3. | 21:35 |
| linggao | I meant wifi | 21:35 |
| zyga_ | linggao: did you report a bug about that too? | 21:35 |
| linggao | not yet. | 21:35 |
| linggao | zyga_, here is the whole story, maybe you can help us figure out why. We built our pi image on 01/14/2017 beased on http://cdimage.ubuntu.com/ubuntu/releases/16.04/release. It had kernel version 4.4.0-1009-raspi2. We have been testing our snap with this image successfuly until Feb 12th when we start seeing kernel panic during snap mounting. On our side, we have new rleases of for our snaps. We are trying to figure out what ar | 21:46 |
| linggao | e the variables that cause the kernel panic. | 21:46 |
| linggao | So base image is the same, the variables could be the new version of core or our snap. | 21:48 |
| zyga_ | linggao: do you update your images? | 21:49 |
| zyga_ | linggao: do you rebuild your snap or was it fixed and never ever ever touched since? | 21:49 |
| zyga_ | linggao: building squashfs is not very deterministic last time I looked | 21:50 |
| linggao | We did not upgrade the bease image (the upgrade was done when we build the pi image on 01-14-2017) | 21:50 |
| zyga_ | linggao: if you build a squashfs from same stuff you will not get the same output | 21:51 |
| linggao | We keep releasing new revisions for our snap. | 21:51 |
| zyga_ | linggao: maybe you found an interesting bug in the squashfs support | 21:51 |
| zyga_ | linggao: quick idea, copy your snap to a amd64 kernel | 21:51 |
| zyga_ | linggao: and see if that can be mounted | 21:51 |
| linggao | zyga_, no problem on amd64. | 21:52 |
| zyga_ | linggao: if that oopes on other architectures then preserve that snap | 21:52 |
| zyga_ | linggao: and please report the full backtrace | 21:52 |
| zyga_ | linggao: I don't know what realyl oopeses | 21:52 |
| zyga_ | linggao: do you have the stack trace? | 21:52 |
| zyga_ | linggao: does it reliably oopse on a pi3? | 21:52 |
| linggao | bte, after reboot the pi, the snap got intalled and can work. | 21:52 |
| linggao | yes, it always gets kernel panic on pi3 now. | 21:53 |
| zyga_ | linggao: perfect, keep that pi for analysis, report the issue, have some kernel people looking at it | 21:54 |
| zyga_ | linggao: make sure you can oops the kernel just by using mount | 21:54 |
| zyga_ | linggao: it's a pure kernel issue | 21:54 |
| zyga_ | linggao: and don't change the snap file, it really needs to be that one that oopes | 21:54 |
| zyga_ | linggao: if you show me the bug report with the kernel trace I can offer ideas but I'm not a kernel engineer | 21:56 |
| zyga_ | linggao: and if you can ooops just with mounting then the core snap is irrelevant | 21:56 |
| linggao | zyga_, the kernel trace is in that bug I have reported. https://bugs.launchpad.net/snapd/+bug/1664368. They told me to upgrade to the new kernel to see. | 21:57 |
| mup | Bug #1664368: snap refresh hangs on arm architecture <snapd:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1664368> | 21:57 |
| linggao | It is exactly the same. | 21:57 |
| zyga_ | linggao: looks like a bug in the mount system, there were plenty of those fixed | 21:58 |
| linggao | The new kernel works. But my boss asked me to find out why old one stopped working. | 21:58 |
| zyga_ | linggao: old one was buggy, that snap caused the bug to surface | 21:58 |
| zyga_ | linggao: not sure what you want to find out, check which changes landed to namespaces and mount propagatinon | 21:59 |
| zyga_ | linggao: but note that you must be able to cause this with mount alone | 22:00 |
| linggao | zyga_, because the new kernel does not work with the onboard wifi for pi3. :-) | 22:00 |
| zyga_ | linggao: if you do other things then maybe just new core version mounts more things than before | 22:00 |
| zyga_ | linggao: well, have some kernel peopel look at that | 22:00 |
| zyga_ | linggao: I don't know about this, we have people use wifi on the current kernel on pi3 all the time | 22:00 |
| zyga_ | linggao: even today I think ogra_ was doing this | 22:01 |
| linggao | zyga_, that's good to know. | 22:01 |
| zyga_ | linggao: if you want to see what may have changed in the core look at the changes to snap-confine | 22:02 |
| zyga_ | linggao: it's in github.com/snapcore/snapd | 22:02 |
| zyga_ | linggao: look at cmd/snap-confine there | 22:02 |
| zyga_ | linggao: pick your time window, the history contains all the code since day one | 22:02 |
| zyga_ | linggao: I don't remember when you said the first image was from | 22:03 |
| zyga_ | linggao: I wonder what version of snap-confine was used ont it | 22:03 |
| zyga_ | linggao: can you run /usr/lib/snapd/snap-confine --version? | 22:03 |
| linggao | snap-confine 2.20.1ubuntu1 | 22:04 |
| linggao | this is on pi2 which also had kernal panic. | 22:04 |
| zyga_ | linggao: and when it worked? | 22:04 |
| linggao | before Feb 8. | 22:05 |
| linggao | Jan 14 to Feb 8, it worked. | 22:05 |
| zyga_ | you'd have to map those to versions of snap-confine on the system | 22:05 |
| linggao | I think it broke sometime between Feb 8 to Feb 12. | 22:05 |
| zyga_ | linggao: note that core is irrelevant again | 22:06 |
| zyga_ | linggao: because snap-confine is a separate package | 22:06 |
| zyga_ | linggao: and snapd doesn't use the version from the core | 22:06 |
| zyga_ | linggao: let me know what you find otu | 22:06 |
| linggao | Is it part of the core (snap) ? | 22:06 |
| zyga_ | linggao: what? | 22:07 |
| zyga_ | linggao: snap-confine, yes, but it is not used | 22:07 |
| zyga_ | linggao: it is only used there if you are running an all-snap system | 22:07 |
| zyga_ | linggao: (aka a non-classic distro) | 22:07 |
| linggao | sorry, I just want to figure out when snap-confine got installed. | 22:07 |
| zyga_ | linggao: snap-confine is a dependency of snapd | 22:07 |
| zyga_ | linggao: and nowadays it is a single package | 22:07 |
| linggao | Was it built in my bease image or is it downloaded when my snap was installed. | 22:08 |
| zyga_ | linggao: so core (snap) is not interesting but snapd (debian package) is | 22:08 |
| zyga_ | linggao: it's a part of snapd | 22:08 |
| linggao | The date of /usr/lib/snapd/snapd is Jan 3. | 22:09 |
| linggao | That means it has not been changed. | 22:10 |
| zyga_ | linggao: can you mount your snap on the old kernel, without using snapd, to cause the oops? | 22:10 |
| zyga_ | linggao: just mount -o ro /path/to/some/snap /mnt | 22:10 |
| mup | PR snapcraft#1154 opened: Expose parallel_build_count to scriptlets (LP: #1666271) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/1154> | 22:11 |
| === King_InuYasha is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as King_InuYasha | ||
| zyga_ | Conan_Kudo: what's with the new identity? | 22:12 |
| linggao | zyga_, yes, I can. | 22:14 |
| zyga_ | linggao: then this is not core related IMHO, do you agree? | 22:14 |
| linggao | zyga_, I do not know enough to make a decision. :-) | 22:15 |
| zyga_ | linggao: remove all of snapd | 22:15 |
| zyga_ | linggao: and mount the snap | 22:15 |
| zyga_ | linggao: do you see that it is not core related now? | 22:16 |
| linggao | how to remove all of snapd? | 22:16 |
| zyga_ | linggao: just purge the package | 22:16 |
| zyga_ | linggao: apt remove --purge snapd | 22:16 |
| zyga_ | warning: this will remove all snaps | 22:16 |
| zyga_ | and all of their state | 22:16 |
| === King_InuYasha is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as King_InuYasha | ||
| linggao | zyga_, I removed the snapd and did mount again, it worked. | 22:22 |
| zyga_ | linggao: ah, that's interesting then | 22:41 |
| zyga_ | linggao: so it is not this that is causing the issue | 22:41 |
| mup | PR snapd#2894 closed: snapstate: allow for 6 retries for the core transition <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2894> | 22:57 |
| mup | PR snapd#2895 opened: first pass at client messaging around modes <Created by chipaca> <https://github.com/snapcore/snapd/pull/2895> | 23:12 |
| mup | PR snapd#2896 opened: Headers over redirects <Created by chipaca> <https://github.com/snapcore/snapd/pull/2896> | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!