=== otis is now known as Guest71571 [00:11] I am trying to install ubuntu core on raspberry pi 3 and I am stuck at entering email address from account in store... [00:11] frustrated, I have an error message for my email, no ssh keys found... [00:11] can anyone help me?? === JanC is now known as Guest76305 === JanC_ is now known as JanC [00:22] mikedougherty: Hey! [00:22] mikedougherty: Loïc Minier here [00:23] mikedougherty: a real Ubuntu xenial environment will be better than a docker environment albeit I had success building snaps in there (perhaps not the docker snap though) [00:23] mikedougherty: the errors you reported wouldn't seem to relate to docker at all though [00:23] hiyo! [00:24] mikedougherty: it's pretty late here (CET) and I wont be around tomorrow morning, but otherwise IRC/email are all fine [00:24] right, in fact very strangely i couldn't even find part of that error string in the source that i have installed [00:24] mikedougherty: you'll also find lots of folks around here and on the snapcraft ML for generic questions not specific to docker [00:25] in a straight xenial environment, things seem to be working fine. i probably should have tried it sooner [00:25] that's good news [00:26] mikedougherty: there were some recent changes to the docker snap that I should keep you up-to-date on [00:26] definitely something with my docker env. i'll try now on the same system in a similar docker environment, if that works then i'll blame my local system. if not, then likely a snapcraft-in-docker issue. [00:27] mikedougherty: the two main environments I'm testing it right now are: 1) plain Ubuntu Core series 16 (image made only of snaps - https://www.ubuntu.com/core) 2) Ubuntu classis – xenial + updates, comes with snapd preinstalled [00:27] with latest snapd (2.17), the docker interfaces get autoconnected [00:27] interesting [00:27] there's currently a bug breaking docker snap on Ubuntu Core; we think docker is trying to access the wrong cgroup mount point and confinement breaks it [00:28] this is to be fixed in the confinement but could also be fixed in docker snap for now [00:28] that likely would have been the next thing i run into, so good to know before i run into that wall [00:28] what would those changes be for the docker snap? [00:29] Bug #1642090 opened: crontab like snaps or interfaces [00:29] mikedougherty: https://lists.ubuntu.com/archives/snapcraft/2016-October/001382.html was the original announcement with reference to a google doc acting as a mini knowledge base for the docker snap [00:29] i'll have a look through [00:30] mikedougherty: I'm not sure how it's locating /sys/.../cgroups/cpuset from all mountpoints, perhaps try multiple ones or prefer a shorter path (both of which are a bit ugly); I haven't thought this through [00:31] mikedougherty: https://bugs.launchpad.net/snap-confine/+bug/1626019 is a bug describing the *opposite* problematic behavior which we worked aorund int he docker snap (see dockerd launcher), but that might not be needed anymore nowadays; the original issue of the mountpoints that should be cleaned up after confinement is setup stands [00:31] Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) [00:33] mikedougherty: (this cgroup finding issue is actually recent; this bug is much older) [00:33] mikedougherty: got to get some sleep, tty soon [00:33] sounds good! thanks for the info dump [02:36] Bug #1642117 opened: symlinks to snap commands no longer working === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:40] PR snapd#2266 closed: tests: run autopkgtests in the autopkgtest.ubuntu.com infrastructure [06:45] PR snapd#2280 closed: interfaces: miscellaneous policy updates (LP: #1639988, 1614269, 1639614, 1605216, 1629996, et al) [07:08] PR snapd#2282 opened: interfaces: remove LegacyAutoConnect() from the interfaces [08:02] hey hey [08:05] bonjello [08:07] hey dholbach! [08:07] salut seb128 [08:07] good morning dholbach, re seb128, hey foxmask [08:08] didrocks: o/ [08:08] salut didrocks [08:08] re didrocks ;-) [08:08] mince ca speak french alors ? :) [08:10] foxmask: as dholbach speaks french very well, I would say yes :) [08:10] pas du tout :) [08:10] héhé [08:11] j'ai oublié tout :-) [08:11] ok forget what I said :) [08:14] good morning [08:29] PR snapd#2283 opened: osutil: make RealUser only look at SUDO_USER when uid==0 [08:53] Bug #1642183 opened: GRUB shows "Trying to terminate EFI services again" and blocks boot for a while [09:04] Morning all :-) [09:05] didrocks, I updated my podpublish snap last night. [09:05] https://code.launchpad.net/~flexiondotorg/podpublish/+git/podpublish/+ref/master [09:05] And ran into an issue. [09:06] I can no longer build this snap on LP :-( [09:06] Because the LP build step has no network capability. [09:07] And it appears snapcraft is trying to download requirements it already had from the the pull step. [09:07] https://launchpadlibrarian.net/293608654/buildlog_snap_ubuntu_xenial_arm64_podpublish_BUILDING.txt.gz [09:07] I tried several things to work around this. [09:08] Putting everything from 'pip freeze' from my virtualenv into requirement.txt [09:09] Changing setup.py to not return any requirements when invoked for a bdist or build. [09:09] flexiondotorg: yeah, indeed, this change was wanted by the launchpad team. You need now to refactor to have this only in the pull step as you told [09:09] I finally gave up at 2am and built a package locally and uploaded it to the store. [09:10] I don't think that's something which is going to change in the forseable future [09:10] but, the standards plugin should already comply with this, don't they? [09:10] So I did refactor setup.py to not request any requirements in the build step. [09:11] hum, the issue is that you have multiple requirements.txt [09:11] the python plugin will pick one and install everything for you in the pull step [09:11] then, your requirements should be there once setup.py load them, shouldn't they? [09:11] (maybe your setup.py tries to be too clever?) [09:12] But snapcraft appears to invoke pip bdist_wheel in the build step anyway. [09:12] Which attempts to download requirement that were already gathered in the pull step. [09:12] As far as I can tell, it is not possible to build a snap in LP for Python package that ships a requirements.txt. [09:13] flexiondotorg: I'm pretty sure with a standard setup.py that was tested (or I hope so), sergiusens did refactor the plugin recently [09:13] pip bdist_wheel doesn't redownload the requirements if they were already pulled (at least, on ubuntu make) [09:13] I wonder if the issue isn't somewhere else [09:13] Download error on https://pypi.python.org/simple/cffi/: [Errno -2] Name or service not known -- Some packages may not be found! [09:13] Couldn't find index page for 'cffi' (maybe misspelled?) [09:13] Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found! [09:13] No local packages or working download links found for cffi>=1.4.1 [09:14] Those are lines from the build log in the build step. [09:14] cffi was download in the pull step. [09:15] I wonder if one the required packages is forcing a download. [09:15] flexiondotorg: did you try to remove all the "*_requires" for now? [09:15] in setup.py [09:16] didrocks, Yes, I tried that last nights. [09:16] to at least test this isn't what causes distutils to repull [09:16] didn't work, still the same? [09:16] That was how the process used to be. [09:16] flexiondotorg: I saw sergio work on this issue at the last sprint [09:16] flexiondotorg: ask him later today [09:16] zyga, OK. Thanks. [09:18] didrocks, To get podpublish building in LP (a couple of months back) I crippled setup.py to not return/request any requirements. [09:18] But that no longer works in this case. [09:18] flexiondotorg: when was the last time you tried a build on launchpad which passed btw? I don't rememer when this change was deployed, but at least, it's a couple of months (just trying to find if we had an email announcement) [09:19] flexiondotorg: ok, is it exactly the same failure than th one you pasted above in that case? (without those _require statements?) [09:19] June/July. [09:20] ok, that makes sense time-wise at least [09:20] let's see once Sergio is around as it seems he already worked on this for python [09:20] kyrofa, Helped me do the initial publishing to LP. [09:20] (I only needed to change some things on npm/bower myself) [09:21] zyga: ping [09:21] And this was required, which no longer works :-( [09:21] https://git.launchpad.net/podpublish/commit/?id=ba69bf886f3125173af1b0b08d2862ab2f2e27d3 [09:22] yeah, that should be what is working still nowdays [09:22] do you have the corresponding exact launchpad build log link? [09:22] For when it worked? [09:24] no, the first build that failed [09:24] with those requires commented [09:25] PR snapd#2282 closed: interfaces: remove LegacyAutoConnect() from the interfaces [09:27] didrocks, I'll drop them again and rebuild to get a log. [09:29] PR snapd#2271 closed: snap: add support for classic confinement [09:30] flexiondotorg: thx! [09:34] PR snapd#2284 opened: tests: add debug to all flaky expect tests [09:38] morphis__: hey [09:39] I installed Ubuntu core 16 on a Raspberry Pi and need to login local. How do I do tgat? [09:40] zyga: hey! [09:40] I do not have another host I can SSH from. I tried my SSO credentials and it's not working either [09:41] Hi [09:41] zyga: I am wondering if there are any plans around better process/service management inside snaps [09:41] zyga: having the problem right now that I need to restart one of my services from another [09:41] zyga: talking to systemd isn't possible and kill(..) too as using the process-control interface is quite too priviledged [09:42] morphis__: you can kill processes from your own snap [09:42] morphis__: I think we should allow talking to systemd to manage just the subset [09:42] morphis__: perhaps via snapctl [09:43] morphis__: but I don't know of any plans yet [09:43] zyga: I get a permission denied for a kill -TERM $PID call [09:43] because the kill syscall is denied [09:44] morphis__: odd, can you report that, I'll try to fix it today [09:45] zyga: I thought that is what we have https://github.com/snapcore/snapd/blob/master/interfaces/builtin/process_control.go for [09:45] zyga: so how is it supposed to work then if not using the process control iface? [09:46] morphis__: process control was for unconstrained process control [09:46] morphis__: you should be able to kill processes from your own apparmor label [09:46] morphis__: that's easy to do [09:46] zyga: ok, that would be awsome [09:47] s/kill/signal/ [09:47] zyga: using snap-confine 1.0.43 here [09:47] didrocks, Here you go: [09:47] https://launchpadlibrarian.net/293648430/buildlog_snap_ubuntu_xenial_amd64_podpublish_BUILDING.txt.gz [09:47] morphis__: that would be in apparmor profiles in snapd [09:47] morphis__: I don't think we need any snap-confine changes [09:47] ah [09:48] Built from: [09:48] https://git.launchpad.net/podpublish/commit/?id=edd30ec9016840e870f1c8e4c2fca516231b351b [09:48] zyga: let me check, maybe I can fix that myself [09:49] morphis__: look at the base profile, it should deny signals to unconfined labels [09:49] morphis__: and it should also allow signals to the same label [09:49] morphis__: same == the label of the snap [09:50] hm, it does already [09:50] PR snapd#2242 closed: tests: do not use hello-world in our tests [09:50] morphis__: what is the denial you see? [09:50] signal peer=(snap.@{SNAP_NAME}.*), [09:50] [73180.309289] audit: type=1400 audit(1479287611.329:127): apparmor="DENIED" operation="capable" profile="snap.wifi-ap.management-service" pid=11539 comm="ap.sh" capability=5 capname="kill" [09:51] morphis__: is the service running as root and the signal sender as non-root? [09:51] morphis__: this is a different denial [09:51] morphis__: right? [09:51] morphis__: that's CAP_KILL [09:51] zyga: snap.wifi-ap.management-service is a systemd service so running as root [09:51] yeah [09:51] morphis__: so the signal is already allowed and this is a different problem [09:52] morphis__: you'd need your own tiny service that kills the other one [09:52] zyga: its actually mgmt-service -> fork ap.sh -> fork hostapd [09:53] ap.sh calls kill -TERM $HOSTAPD_PID [09:53] morphis__: in any case, I think you are good [09:54] zyga: why do I get then: [09:54] Nov 16 10:13:31 nirvana snap[11342]: ++ read DNSMASQ_PID [09:54] Nov 16 10:13:31 nirvana snap[11342]: ++ kill -TERM 11609 [09:54] Nov 16 10:13:31 nirvana snap[11342]: /snap/wifi-ap/x7/bin/ap.sh: line 48: kill: (11609) - Operation not permitted [09:54] actually I am not dropping capabilities anywere [09:55] morphis__: is the sender running as root? [09:55] yes [09:55] hmm [09:55] morphis__: the denial above is for permission bypass [09:55] CAP_KILL [09:55] Bypass permission checks for sending signals (see kill(2)). This includes use of the ioctl(2) KDSIGACCEPT operation. [09:55] morphis__: ah, is there an identical rule for signal reception? [09:56] morphis__: that a process can receive a signal from the same snap? [09:56] you mean in apparmor? [09:56] morphis__: if not, you are invincible ;-) [09:56] yes [09:56] rule says, "Allow apps from the same package to signal each other via signals" [09:57] zyga: https://paste.ubuntu.com/23484812/ [09:57] but looks like we need to allow cap_kill [09:57] morphis__: that's only half of the rule [09:57] morphis__: looks like a silly bug [09:57] morphis__: look at... [09:57] morphis__: no [09:57] morphis__: cap_kill == kill anything [09:58] morphis__: one sec [09:58] hmmm [09:58] isn't that the capability to call kill at all and further limitations are done through the apparmor rule? [09:58] I was partially wrong [09:58] morphis__: no, because cap_kill is like sudo, it's not something you should need here [09:58] ok [09:58] morphis__: https://github.com/snapcore/snap-confine/blob/master/src/snap-confine.apparmor.in#L318 [09:59] morphis__: the trouble is that signal implies singal (send,receive) [09:59] morphis__: so something else (not apparmor) is in the way [09:59] morphis__: can you tweak the profile locally [09:59] morphis__: make it say signal (send,receive) explicitly [10:00] sure [10:00] still the cap_kill deny [10:01] morphis__: can you triple check the UID of both processes? [10:01] morphis__: if this fails I'd ask jdstrand, no idea but I think cap_kill is the wrong answer [10:01] zyga: both root [10:02] zyga: let me open a bug for this [10:02] morphis__: thanks [10:03] morphis__: unless we drop all caps? [10:03] morphis__: and we're root but really without capkill [10:03] zyga: can I check the caps of a process somewhere? [10:04] yes [10:04] pscap [10:06] zyga: ah wait, there is a different problem [10:07] dnsmasq switches to nobody [10:07] hostapd not, but dnsmasq does [10:08] ha [10:09] let me change that [10:14] zyga: one other thing I wanted to ask you about, what is the classic confinement mode going to be? [10:16] morphis__: similar to no confinement at all [10:16] morphis__: we're meeting today to discuss some aspects [10:17] zyga: ok [10:17] zyga: so a more official "devmode by default" thing [10:18] morphis__: no, many changes apart from confinement [10:18] morphis__: no rootfs change [10:18] morphis__: and also (hopefully) snapcraft logic to use core snap for linker and libraries [10:18] ok [10:47] ogra_: on bbb, the first boot tasks fail for me with [10:47] 2016-11-16T10:46:47Z ERROR cannot deliver device serial request: unexpected status 400 === hikiko is now known as hikiko|afk [11:05] mvo, Chipaca, pedronis: docker seems down, this means travis fails bootstrap and we cannot test [11:05] e.g. https://travis-ci.org/snapcore/snapd/jobs/176335410 [11:17] PR snapd#2058 closed: interfaces: add ofono interface [11:21] \o/ [11:22] Chipaca, https://github.com/snapcore/snapd/pull/2252 was approved too ;) [11:22] PR snapd#2252: interfaces: add unconfined access to modem-manager [11:23] abeato: patience :-) [11:24] Chipaca, lol, just in case you did not see that one :p [11:24] and thanks [11:24] PR # closed: snapd#1613, snapd#2083, snapd#2087, snapd#2104, snapd#2112, snapd#2113, snapd#2120, snapd#2128, snapd#2129, snapd#2153, snapd#2193, snapd#2194, snapd#2199, snapd#2200, snapd#2202, snapd#2209, snapd#2211, snapd#2215, snapd#2223, snapd#2226, snapd#2230, snapd#2234, snapd#2236, [11:24] snapd#2249, snapd#2251, snapd#2252, snapd#2256, snapd#2262, snapd#2263, snapd#2264, snapd#2268, snapd#2269, snapd#2270, snapd#2273, snapd#2274, snapd#2275, snapd#2276, snapd#2277, snapd#2278, snapd#2279, snapd#2281, snapd#2283, snapd#2284 [11:24] abeato: currently looking at 2083, I'll get there soon enough [11:24] cool [11:28] mvo: does this look good to you http://pastebin.ubuntu.com/23485134/ [11:28] mvo: you were doing some changes to make various versions of systemd test the same [11:34] I’m trying to use the ubuntu-app-platform content interface, and getting the following error message when launching my app: [11:34] cannot mount /snap/ubuntu-app-platform/8 at /snap/webbrowser-app/x1/ubuntu-app-platform with options bind,ro. errmsg: No such file or directory [11:34] any idea what the problem is? [11:40] oSoMoN, hey [11:41] hey renato__ [11:41] oSoMoN, you need to install a empty directory with name "ubuntu-app-platform" [11:42] renato__, okay. That’s not mentioned anywhere in the instructions to use the content interface, the doc needs updating (or is it a bug that will eventually be fixed') [11:42] oSoMoN, the interface you mount the content inside of this dir. The interface itself does not have permission to create dir on the app side. [11:42] oSoMoN, yes probably the doc needs update [11:44] renato__, thanks for the help, I’m trying that now [11:47] mvo, hey could you help me with some apps that are stuck on store? [11:48] jdstrand, hey, I saw that you approved my apps. Thanks. [11:49] matteo: #2193 has conflicts [11:59] guys I am trying to remove a snap app, and I am getting this error [12:00] 2016-11-16T08:59:06-03:00 ERROR cannot remove snap file "ubuntu-calendar-app", will retry in 3 mins: umount: /snap/ubuntu-calendar-app/x1: not mounted [12:00] ant it never get removed [12:18] zyga, any hint about this ^^^ [12:23] renato__: looking [12:23] renato__: were you using snap try? [12:23] renato__: you can snap abort the change [12:23] renato__: and (if it was snap try) restory the directory and the bind mount [12:23] renato__: to remove the snap [12:25] zyga, no I am not using snap try. [12:25] should I use that? [12:26] zyga, how to use that? [12:26] renato__: no, if you are not using snap try then don't follow the rest of my advice [12:26] renato__: can you tell me what you did prior to this failure? [12:27] zyga, not, sure just reboot the machine [12:27] zyga, it is a vm [12:30] zyga, I was just installing and removing app as normal. [12:35] zyga, any workaround that I can use to continue working? :D [12:41] renato__: can you pastebin the output of "snap changes" please [12:41] zyga, sure [12:42] zyga, http://paste.ubuntu.com/23485397/ [12:43] zyga, I have been trying to fix that as you can see in the changes. [12:44] renato__: how about "snap change 186" [12:45] http://paste.ubuntu.com/23485400/ [12:45] zyga, ^ [12:46] renato__: hmm, can you look at /snap/ubuntu-calendar-app/x1 [12:46] renato__: is that a mount point? [12:46] renato__: does "snap list" show it to be installed? [12:46] zyga, ubuntu-calendar-app x1 broken [12:46] zyga, yes the dir exists [12:47] renato__: is it empty [12:47] yes [12:53] renato__: can you look at /var/lib/snapd/snaps [12:53] renato__: look for the sideloaded revision of this snap, is there a .snap file there? [12:54] zyga, http://paste.ubuntu.com/23485419/ [12:54] yes there is a snap for x1 version [12:54] renato__: ok [12:54] renato__: can you do systemctl status and look for the mount unit for that snap [12:54] renato__: (I don't remember the name) [12:54] renato__: then do systemctl status name-of-that-unit.mount [12:54] renato__: and see what the output is [12:55] tvoss: re, how's stuff? [12:56] zyga, what I should look for, exactly? http://paste.ubuntu.com/23485428/ [12:57] renato__: ah, sorry that doesn't list mount units [12:57] renato__: can you go to /etc/systemd/system/ [12:58] renato__: you will be able to see the various .mount units [12:58] yes [12:58] renato__: use that as a hint to systemctl status the right one (careful with quoting) [12:58] snap-ubuntu\x2dcalendar\x2dapp-x1.mount [12:59] yes, that one [12:59] (crazy systemd escape requirements) [12:59] zyga, http://paste.ubuntu.com/23485437/ [13:00] renato__: very insteresting [13:00] renato__: can you report that long with snapd version and kernel version please? [13:00] renato__: and don't change your system for a while [13:00] zyga, :( [13:00] renato__: one more check, look at that snap file and see if it's empty by any chance? [13:00] renato__: (truncated etc) [13:01] renato__: I have to run to a standup now, ttyl [13:01] zyga, yes it is empty: -rw------- 1 root root 0 nov 11 20:07 ubuntu-calendar-app_x1.snap [13:03] renato__: please include that in your report [13:03] renato__: I think this explains a lot [13:10] zyga: a step further, tests/upgrade/basic breaks in a different way now: http://pastebin.ubuntu.com/23485459/ [13:10] tvoss: looking [13:10] hmm hmm [13:11] tvoss: is everything pushed? I'll pull and see [13:11] zyga: yup [13:11] k pulling [13:11] zyga, https://bugs.launchpad.net/snappy/+bug/1642257 [13:11] Bug #1642257: Fail to remove app [13:12] renato__: thank you [13:12] renato__: did you have a power failure or something like that? [13:12] renato__: I wonder why that snap got empty [13:12] zyga: --allow-downgrades is certainly needed in tests/upgrade/basic/task.yaml when instaling the previous version [13:12] zyga, welcome. [13:13] Bug #1642257 opened: Fail to remove app [13:13] zyga, I am not sure. But since this is a vm. I could kill it by mistake [13:13] renato__: how many times did you install that snap, what is the time snap (roughly) [13:14] zyga, Im testing the plataform content share. I installed a lot of snap in the last days [13:14] What do you mean by "time snap"??? [13:14] renato__: time span, roughly how many hours/days [13:15] zyga, a lot, probably more than 20 times a day [13:15] not the same snappy, but different versions [13:16] timp, quick heads-up, I've changed the snapcraft docs link in your qt snap blog post, to direct to /docs instead of /docs/snaps, the latter is a pretty weak page that's pending an overhaul [13:20] sergiusens: are you up for the meeting in 10 minutes? [13:23] zyga I am awake, yes [13:23] sergiusens: great, see you soon [13:24] zyga thanks for the reminder, I am getting no notifications/reminders lately [13:33] zyga, do I still need to keep my system freeze. Or can I somehow remove the broken package? [13:35] jdstrand: am I right in thinking there's nothing currently that does the equivelant of APP_ID_DBUS? The helper functions you pointed to me earlier in the week do the job of APP_PKGNAME nicely, but APP_ID_DBUS makes those values usable in dbus paths (e.g. snap.podbird.podbird -> snap_2epodbird_2epodbird) [13:39] mvo: woot! nice find for the lxc bug. curious-- am I entering the container wrong? [13:40] Elleo: let me check something [13:40] jdstrand: okay, thanks === hikiko|afk is now known as hikiko [13:42] Elleo: when we last spoke I was thinking only of the security label and had forgotten that trusted helpers sometimes use the security label in their paths and need something like APP_ID_DBUS [13:42] jdstrand: well, sort of. sudo -u keeps some SUDO_* vars around that confused snapd, but really its a bug in snapd [13:42] jdstrand: hi, we merged removing LegacyAutoConnect btw, mvo did the work [13:43] Elleo: my recollection is that this was removed from snappy because at the time nothing was using it (I mentioned we would need it for personal but it was decided we would just add it back later [13:43] pedronis: I saw that [13:43] * jdstrand hugs mvo [13:43] mvo: otoh, do you know of a better way to enter the chroot as non-root? [13:43] jdstrand: ah right, shall I write an equivelant helper function in utils.go to handle that then? [13:43] Elleo: let me get you the commit that pulled it out [13:44] jdstrand: ah, cool, thanks [13:44] jdstrand: it was on my todo list but mvo graciously got there first [13:45] pedronis: yeah, it came up in a PR the other day that it was adding confusion [13:47] jdstrand: alternatively you could use "su -l -s /bin/sh" [13:47]