| === otis is now known as Guest71571 | ||
| Guest71571 | 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 |
|---|---|---|
| Guest71571 | frustrated, I have an error message for my email, no ssh keys found... | 00:11 |
| Guest71571 | can anyone help me?? | 00:11 |
| === JanC is now known as Guest76305 | ||
| === JanC_ is now known as JanC | ||
| lool | mikedougherty: Hey! | 00:22 |
| lool | mikedougherty: Loïc Minier here | 00:22 |
| lool | 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 |
| lool | mikedougherty: the errors you reported wouldn't seem to relate to docker at all though | 00:23 |
| mikedougherty | hiyo! | 00:23 |
| lool | mikedougherty: it's pretty late here (CET) and I wont be around tomorrow morning, but otherwise IRC/email are all fine | 00:24 |
| mikedougherty | right, in fact very strangely i couldn't even find part of that error string in the source that i have installed | 00:24 |
| lool | mikedougherty: you'll also find lots of folks around here and on the snapcraft ML for generic questions not specific to docker | 00:24 |
| mikedougherty | in a straight xenial environment, things seem to be working fine. i probably should have tried it sooner | 00:25 |
| lool | that's good news | 00:25 |
| lool | mikedougherty: there were some recent changes to the docker snap that I should keep you up-to-date on | 00:26 |
| mikedougherty | 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:26 |
| lool | 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 |
| lool | with latest snapd (2.17), the docker interfaces get autoconnected | 00:27 |
| mikedougherty | interesting | 00:27 |
| lool | 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:27 |
| lool | this is to be fixed in the confinement but could also be fixed in docker snap for now | 00:28 |
| mikedougherty | that likely would have been the next thing i run into, so good to know before i run into that wall | 00:28 |
| mikedougherty | what would those changes be for the docker snap? | 00:28 |
| mup | Bug #1642090 opened: crontab like snaps or interfaces <Snappy:New> <https://launchpad.net/bugs/1642090> | 00:29 |
| lool | 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 |
| mikedougherty | i'll have a look through | 00:29 |
| lool | 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:30 |
| lool | 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 |
| mup | Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1626019> | 00:31 |
| lool | mikedougherty: (this cgroup finding issue is actually recent; this bug is much older) | 00:33 |
| lool | mikedougherty: got to get some sleep, tty soon | 00:33 |
| mikedougherty | sounds good! thanks for the info dump | 00:33 |
| mup | Bug #1642117 opened: symlinks to snap commands no longer working <Snappy:New> <https://launchpad.net/bugs/1642117> | 02:36 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#2266 closed: tests: run autopkgtests in the autopkgtest.ubuntu.com infrastructure <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2266> | 06:40 |
| mup | PR snapd#2280 closed: interfaces: miscellaneous policy updates (LP: #1639988, 1614269, 1639614, 1605216, 1629996, et al) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2280> | 06:45 |
| mup | PR snapd#2282 opened: interfaces: remove LegacyAutoConnect() from the interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/2282> | 07:08 |
| dholbach | hey hey | 08:02 |
| foxmask | bonjello | 08:05 |
| seb128 | hey dholbach! | 08:07 |
| dholbach | salut seb128 | 08:07 |
| didrocks | good morning dholbach, re seb128, hey foxmask | 08:07 |
| foxmask | didrocks: o/ | 08:08 |
| dholbach | salut didrocks | 08:08 |
| seb128 | re didrocks ;-) | 08:08 |
| foxmask | mince ca speak french alors ? :) | 08:08 |
| didrocks | foxmask: as dholbach speaks french very well, I would say yes :) | 08:10 |
| dholbach | pas du tout :) | 08:10 |
| didrocks | héhé | 08:10 |
| dholbach | j'ai oublié tout :-) | 08:11 |
| foxmask | ok forget what I said :) | 08:11 |
| zyga | good morning | 08:14 |
| mup | PR snapd#2283 opened: osutil: make RealUser only look at SUDO_USER when uid==0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2283> | 08:29 |
| mup | Bug #1642183 opened: GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Snappy:New> <https://launchpad.net/bugs/1642183> | 08:53 |
| flexiondotorg | Morning all :-) | 09:04 |
| flexiondotorg | didrocks, I updated my podpublish snap last night. | 09:05 |
| flexiondotorg | https://code.launchpad.net/~flexiondotorg/podpublish/+git/podpublish/+ref/master | 09:05 |
| flexiondotorg | And ran into an issue. | 09:05 |
| flexiondotorg | I can no longer build this snap on LP :-( | 09:06 |
| flexiondotorg | Because the LP build step has no network capability. | 09:06 |
| flexiondotorg | And it appears snapcraft is trying to download requirements it already had from the the pull step. | 09:07 |
| flexiondotorg | https://launchpadlibrarian.net/293608654/buildlog_snap_ubuntu_xenial_arm64_podpublish_BUILDING.txt.gz | 09:07 |
| flexiondotorg | I tried several things to work around this. | 09:07 |
| flexiondotorg | Putting everything from 'pip freeze' from my virtualenv into requirement.txt | 09:08 |
| flexiondotorg | Changing setup.py to not return any requirements when invoked for a bdist or build. | 09:09 |
| didrocks | 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 |
| flexiondotorg | I finally gave up at 2am and built a package locally and uploaded it to the store. | 09:09 |
| didrocks | I don't think that's something which is going to change in the forseable future | 09:10 |
| didrocks | but, the standards plugin should already comply with this, don't they? | 09:10 |
| flexiondotorg | So I did refactor setup.py to not request any requirements in the build step. | 09:10 |
| didrocks | hum, the issue is that you have multiple requirements.txt | 09:11 |
| didrocks | the python plugin will pick one and install everything for you in the pull step | 09:11 |
| didrocks | then, your requirements should be there once setup.py load them, shouldn't they? | 09:11 |
| didrocks | (maybe your setup.py tries to be too clever?) | 09:11 |
| flexiondotorg | But snapcraft appears to invoke pip bdist_wheel in the build step anyway. | 09:12 |
| flexiondotorg | Which attempts to download requirement that were already gathered in the pull step. | 09:12 |
| flexiondotorg | 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:12 |
| didrocks | 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 |
| didrocks | pip bdist_wheel doesn't redownload the requirements if they were already pulled (at least, on ubuntu make) | 09:13 |
| didrocks | I wonder if the issue isn't somewhere else | 09:13 |
| flexiondotorg | Download error on https://pypi.python.org/simple/cffi/: [Errno -2] Name or service not known -- Some packages may not be found! | 09:13 |
| flexiondotorg | Couldn't find index page for 'cffi' (maybe misspelled?) | 09:13 |
| flexiondotorg | Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found! | 09:13 |
| flexiondotorg | No local packages or working download links found for cffi>=1.4.1 | 09:13 |
| flexiondotorg | Those are lines from the build log in the build step. | 09:14 |
| flexiondotorg | cffi was download in the pull step. | 09:14 |
| flexiondotorg | I wonder if one the required packages is forcing a download. | 09:15 |
| didrocks | flexiondotorg: did you try to remove all the "*_requires" for now? | 09:15 |
| didrocks | in setup.py | 09:15 |
| flexiondotorg | didrocks, Yes, I tried that last nights. | 09:16 |
| didrocks | to at least test this isn't what causes distutils to repull | 09:16 |
| didrocks | didn't work, still the same? | 09:16 |
| flexiondotorg | That was how the process used to be. | 09:16 |
| zyga | flexiondotorg: I saw sergio work on this issue at the last sprint | 09:16 |
| zyga | flexiondotorg: ask him later today | 09:16 |
| flexiondotorg | zyga, OK. Thanks. | 09:16 |
| flexiondotorg | didrocks, To get podpublish building in LP (a couple of months back) I crippled setup.py to not return/request any requirements. | 09:18 |
| flexiondotorg | But that no longer works in this case. | 09:18 |
| didrocks | 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:18 |
| didrocks | flexiondotorg: ok, is it exactly the same failure than th one you pasted above in that case? (without those _require statements?) | 09:19 |
| flexiondotorg | June/July. | 09:19 |
| didrocks | ok, that makes sense time-wise at least | 09:20 |
| didrocks | let's see once Sergio is around as it seems he already worked on this for python | 09:20 |
| flexiondotorg | kyrofa, Helped me do the initial publishing to LP. | 09:20 |
| didrocks | (I only needed to change some things on npm/bower myself) | 09:20 |
| morphis__ | zyga: ping | 09:21 |
| flexiondotorg | And this was required, which no longer works :-( | 09:21 |
| flexiondotorg | https://git.launchpad.net/podpublish/commit/?id=ba69bf886f3125173af1b0b08d2862ab2f2e27d3 | 09:21 |
| didrocks | yeah, that should be what is working still nowdays | 09:22 |
| didrocks | do you have the corresponding exact launchpad build log link? | 09:22 |
| flexiondotorg | For when it worked? | 09:22 |
| didrocks | no, the first build that failed | 09:24 |
| didrocks | with those requires commented | 09:24 |
| mup | PR snapd#2282 closed: interfaces: remove LegacyAutoConnect() from the interfaces <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2282> | 09:25 |
| flexiondotorg | didrocks, I'll drop them again and rebuild to get a log. | 09:27 |
| mup | PR snapd#2271 closed: snap: add support for classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2271> | 09:29 |
| didrocks | flexiondotorg: thx! | 09:30 |
| mup | PR snapd#2284 opened: tests: add debug to all flaky expect tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2284> | 09:34 |
| zyga | morphis__: hey | 09:38 |
| bert269 | I installed Ubuntu core 16 on a Raspberry Pi and need to login local. How do I do tgat? | 09:39 |
| morphis__ | zyga: hey! | 09:40 |
| bert269 | I do not have another host I can SSH from. I tried my SSO credentials and it's not working either | 09:40 |
| bert269 | Hi | 09:41 |
| morphis__ | zyga: I am wondering if there are any plans around better process/service management inside snaps | 09:41 |
| morphis__ | zyga: having the problem right now that I need to restart one of my services from another | 09:41 |
| morphis__ | zyga: talking to systemd isn't possible and kill(..) too as using the process-control interface is quite too priviledged | 09:41 |
| zyga | morphis__: you can kill processes from your own snap | 09:42 |
| zyga | morphis__: I think we should allow talking to systemd to manage just the subset | 09:42 |
| zyga | morphis__: perhaps via snapctl | 09:42 |
| zyga | morphis__: but I don't know of any plans yet | 09:43 |
| morphis__ | zyga: I get a permission denied for a kill -TERM $PID call | 09:43 |
| morphis__ | because the kill syscall is denied | 09:43 |
| zyga | morphis__: odd, can you report that, I'll try to fix it today | 09:44 |
| morphis__ | zyga: I thought that is what we have https://github.com/snapcore/snapd/blob/master/interfaces/builtin/process_control.go for | 09:45 |
| morphis__ | zyga: so how is it supposed to work then if not using the process control iface? | 09:45 |
| zyga | morphis__: process control was for unconstrained process control | 09:46 |
| zyga | morphis__: you should be able to kill processes from your own apparmor label | 09:46 |
| zyga | morphis__: that's easy to do | 09:46 |
| morphis__ | zyga: ok, that would be awsome | 09:46 |
| zyga | s/kill/signal/ | 09:47 |
| morphis__ | zyga: using snap-confine 1.0.43 here | 09:47 |
| flexiondotorg | didrocks, Here you go: | 09:47 |
| flexiondotorg | https://launchpadlibrarian.net/293648430/buildlog_snap_ubuntu_xenial_amd64_podpublish_BUILDING.txt.gz | 09:47 |
| zyga | morphis__: that would be in apparmor profiles in snapd | 09:47 |
| zyga | morphis__: I don't think we need any snap-confine changes | 09:47 |
| morphis__ | ah | 09:47 |
| flexiondotorg | Built from: | 09:48 |
| flexiondotorg | https://git.launchpad.net/podpublish/commit/?id=edd30ec9016840e870f1c8e4c2fca516231b351b | 09:48 |
| morphis__ | zyga: let me check, maybe I can fix that myself | 09:48 |
| zyga | morphis__: look at the base profile, it should deny signals to unconfined labels | 09:49 |
| zyga | morphis__: and it should also allow signals to the same label | 09:49 |
| zyga | morphis__: same == the label of the snap | 09:49 |
| morphis__ | hm, it does already | 09:50 |
| mup | PR snapd#2242 closed: tests: do not use hello-world in our tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2242> | 09:50 |
| zyga | morphis__: what is the denial you see? | 09:50 |
| morphis__ | signal peer=(snap.@{SNAP_NAME}.*), | 09:50 |
| morphis__ | [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:50 |
| zyga | morphis__: is the service running as root and the signal sender as non-root? | 09:51 |
| zyga | morphis__: this is a different denial | 09:51 |
| zyga | morphis__: right? | 09:51 |
| zyga | morphis__: that's CAP_KILL | 09:51 |
| morphis__ | zyga: snap.wifi-ap.management-service is a systemd service so running as root | 09:51 |
| morphis__ | yeah | 09:51 |
| zyga | morphis__: so the signal is already allowed and this is a different problem | 09:51 |
| zyga | morphis__: you'd need your own tiny service that kills the other one | 09:52 |
| morphis__ | zyga: its actually mgmt-service -> fork ap.sh -> fork hostapd | 09:52 |
| morphis__ | ap.sh calls kill -TERM $HOSTAPD_PID | 09:53 |
| zyga | morphis__: in any case, I think you are good | 09:53 |
| morphis__ | zyga: why do I get then: | 09:54 |
| morphis__ | Nov 16 10:13:31 nirvana snap[11342]: ++ read DNSMASQ_PID | 09:54 |
| morphis__ | Nov 16 10:13:31 nirvana snap[11342]: ++ kill -TERM 11609 | 09:54 |
| morphis__ | Nov 16 10:13:31 nirvana snap[11342]: /snap/wifi-ap/x7/bin/ap.sh: line 48: kill: (11609) - Operation not permitted | 09:54 |
| morphis__ | actually I am not dropping capabilities anywere | 09:54 |
| zyga | morphis__: is the sender running as root? | 09:55 |
| morphis__ | yes | 09:55 |
| zyga | hmm | 09:55 |
| zyga | morphis__: the denial above is for permission bypass | 09:55 |
| zyga | CAP_KILL | 09:55 |
| zyga | Bypass permission checks for sending signals (see kill(2)). This includes use of the ioctl(2) KDSIGACCEPT operation. | 09:55 |
| zyga | morphis__: ah, is there an identical rule for signal reception? | 09:55 |
| zyga | morphis__: that a process can receive a signal from the same snap? | 09:56 |
| morphis__ | you mean in apparmor? | 09:56 |
| zyga | morphis__: if not, you are invincible ;-) | 09:56 |
| zyga | yes | 09:56 |
| morphis__ | rule says, "Allow apps from the same package to signal each other via signals" | 09:56 |
| morphis__ | zyga: https://paste.ubuntu.com/23484812/ | 09:57 |
| morphis__ | but looks like we need to allow cap_kill | 09:57 |
| zyga | morphis__: that's only half of the rule | 09:57 |
| zyga | morphis__: looks like a silly bug | 09:57 |
| zyga | morphis__: look at... | 09:57 |
| zyga | morphis__: no | 09:57 |
| zyga | morphis__: cap_kill == kill anything | 09:57 |
| zyga | morphis__: one sec | 09:58 |
| zyga | hmmm | 09:58 |
| morphis__ | isn't that the capability to call kill at all and further limitations are done through the apparmor rule? | 09:58 |
| zyga | I was partially wrong | 09:58 |
| zyga | morphis__: no, because cap_kill is like sudo, it's not something you should need here | 09:58 |
| morphis__ | ok | 09:58 |
| zyga | morphis__: https://github.com/snapcore/snap-confine/blob/master/src/snap-confine.apparmor.in#L318 | 09:58 |
| zyga | morphis__: the trouble is that signal implies singal (send,receive) | 09:59 |
| zyga | morphis__: so something else (not apparmor) is in the way | 09:59 |
| zyga | morphis__: can you tweak the profile locally | 09:59 |
| zyga | morphis__: make it say signal (send,receive) explicitly | 09:59 |
| morphis__ | sure | 10:00 |
| morphis__ | still the cap_kill deny | 10:00 |
| zyga | morphis__: can you triple check the UID of both processes? | 10:01 |
| zyga | morphis__: if this fails I'd ask jdstrand, no idea but I think cap_kill is the wrong answer | 10:01 |
| morphis__ | zyga: both root | 10:01 |
| morphis__ | zyga: let me open a bug for this | 10:02 |
| zyga | morphis__: thanks | 10:02 |
| zyga | morphis__: unless we drop all caps? | 10:03 |
| zyga | morphis__: and we're root but really without capkill | 10:03 |
| morphis__ | zyga: can I check the caps of a process somewhere? | 10:03 |
| zyga | yes | 10:04 |
| zyga | pscap | 10:04 |
| morphis__ | zyga: ah wait, there is a different problem | 10:06 |
| morphis__ | dnsmasq switches to nobody | 10:07 |
| morphis__ | hostapd not, but dnsmasq does | 10:07 |
| zyga | ha | 10:08 |
| morphis__ | let me change that | 10:09 |
| morphis__ | zyga: one other thing I wanted to ask you about, what is the classic confinement mode going to be? | 10:14 |
| zyga | morphis__: similar to no confinement at all | 10:16 |
| zyga | morphis__: we're meeting today to discuss some aspects | 10:16 |
| morphis__ | zyga: ok | 10:17 |
| morphis__ | zyga: so a more official "devmode by default" thing | 10:17 |
| zyga | morphis__: no, many changes apart from confinement | 10:18 |
| zyga | morphis__: no rootfs change | 10:18 |
| zyga | morphis__: and also (hopefully) snapcraft logic to use core snap for linker and libraries | 10:18 |
| morphis__ | ok | 10:18 |
| zyga | ogra_: on bbb, the first boot tasks fail for me with | 10:47 |
| zyga | 2016-11-16T10:46:47Z ERROR cannot deliver device serial request: unexpected status 400 | 10:47 |
| === hikiko is now known as hikiko|afk | ||
| zyga | mvo, Chipaca, pedronis: docker seems down, this means travis fails bootstrap and we cannot test | 11:05 |
| zyga | e.g. https://travis-ci.org/snapcore/snapd/jobs/176335410 | 11:05 |
| mup | PR snapd#2058 closed: interfaces: add ofono interface <Created by alfonsosanchezbeato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2058> | 11:17 |
| abeato | \o/ | 11:21 |
| abeato | Chipaca, https://github.com/snapcore/snapd/pull/2252 was approved too ;) | 11:22 |
| mup | PR snapd#2252: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252> | 11:22 |
| Chipaca | abeato: patience :-) | 11:23 |
| abeato | Chipaca, lol, just in case you did not see that one :p | 11:24 |
| abeato | and thanks | 11:24 |
| mup | 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 |
| mup | 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 |
| Chipaca | abeato: currently looking at 2083, I'll get there soon enough | 11:24 |
| abeato | cool | 11:24 |
| zyga | mvo: does this look good to you http://pastebin.ubuntu.com/23485134/ | 11:28 |
| zyga | mvo: you were doing some changes to make various versions of systemd test the same | 11:28 |
| oSoMoN | I’m trying to use the ubuntu-app-platform content interface, and getting the following error message when launching my app: | 11:34 |
| oSoMoN | 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 |
| oSoMoN | any idea what the problem is? | 11:34 |
| renato__ | oSoMoN, hey | 11:40 |
| oSoMoN | hey renato__ | 11:41 |
| renato__ | oSoMoN, you need to install a empty directory with name "ubuntu-app-platform" | 11:41 |
| oSoMoN | 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 |
| renato__ | 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 |
| renato__ | oSoMoN, yes probably the doc needs update | 11:42 |
| oSoMoN | renato__, thanks for the help, I’m trying that now | 11:44 |
| renato__ | mvo, hey could you help me with some apps that are stuck on store? | 11:47 |
| renato__ | jdstrand, hey, I saw that you approved my apps. Thanks. | 11:48 |
| Chipaca | matteo: #2193 has conflicts | 11:49 |
| renato__ | guys I am trying to remove a snap app, and I am getting this error | 11:59 |
| renato__ | 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 |
| renato__ | ant it never get removed | 12:00 |
| renato__ | zyga, any hint about this ^^^ | 12:18 |
| zyga | renato__: looking | 12:23 |
| zyga | renato__: were you using snap try? | 12:23 |
| zyga | renato__: you can snap abort the change | 12:23 |
| zyga | renato__: and (if it was snap try) restory the directory and the bind mount | 12:23 |
| zyga | renato__: to remove the snap | 12:23 |
| renato__ | zyga, no I am not using snap try. | 12:25 |
| renato__ | should I use that? | 12:25 |
| renato__ | zyga, how to use that? | 12:26 |
| zyga | renato__: no, if you are not using snap try then don't follow the rest of my advice | 12:26 |
| zyga | renato__: can you tell me what you did prior to this failure? | 12:26 |
| renato__ | zyga, not, sure just reboot the machine | 12:27 |
| renato__ | zyga, it is a vm | 12:27 |
| renato__ | zyga, I was just installing and removing app as normal. | 12:30 |
| renato__ | zyga, any workaround that I can use to continue working? :D | 12:35 |
| zyga | renato__: can you pastebin the output of "snap changes" please | 12:41 |
| renato__ | zyga, sure | 12:41 |
| renato__ | zyga, http://paste.ubuntu.com/23485397/ | 12:42 |
| renato__ | zyga, I have been trying to fix that as you can see in the changes. | 12:43 |
| zyga | renato__: how about "snap change 186" | 12:44 |
| renato__ | http://paste.ubuntu.com/23485400/ | 12:45 |
| renato__ | zyga, ^ | 12:45 |
| zyga | renato__: hmm, can you look at /snap/ubuntu-calendar-app/x1 | 12:46 |
| zyga | renato__: is that a mount point? | 12:46 |
| zyga | renato__: does "snap list" show it to be installed? | 12:46 |
| renato__ | zyga, ubuntu-calendar-app x1 broken | 12:46 |
| renato__ | zyga, yes the dir exists | 12:46 |
| zyga | renato__: is it empty | 12:47 |
| renato__ | yes | 12:47 |
| zyga | renato__: can you look at /var/lib/snapd/snaps | 12:53 |
| zyga | renato__: look for the sideloaded revision of this snap, is there a .snap file there? | 12:53 |
| renato__ | zyga, http://paste.ubuntu.com/23485419/ | 12:54 |
| renato__ | yes there is a snap for x1 version | 12:54 |
| zyga | renato__: ok | 12:54 |
| zyga | renato__: can you do systemctl status and look for the mount unit for that snap | 12:54 |
| zyga | renato__: (I don't remember the name) | 12:54 |
| zyga | renato__: then do systemctl status name-of-that-unit.mount | 12:54 |
| zyga | renato__: and see what the output is | 12:54 |
| zyga | tvoss: re, how's stuff? | 12:55 |
| renato__ | zyga, what I should look for, exactly? http://paste.ubuntu.com/23485428/ | 12:56 |
| zyga | renato__: ah, sorry that doesn't list mount units | 12:57 |
| zyga | renato__: can you go to /etc/systemd/system/ | 12:57 |
| zyga | renato__: you will be able to see the various .mount units | 12:58 |
| renato__ | yes | 12:58 |
| zyga | renato__: use that as a hint to systemctl status the right one (careful with quoting) | 12:58 |
| renato__ | snap-ubuntu\x2dcalendar\x2dapp-x1.mount | 12:58 |
| zyga | yes, that one | 12:59 |
| zyga | (crazy systemd escape requirements) | 12:59 |
| renato__ | zyga, http://paste.ubuntu.com/23485437/ | 12:59 |
| zyga | renato__: very insteresting | 13:00 |
| zyga | renato__: can you report that long with snapd version and kernel version please? | 13:00 |
| zyga | renato__: and don't change your system for a while | 13:00 |
| renato__ | zyga, :( | 13:00 |
| zyga | renato__: one more check, look at that snap file and see if it's empty by any chance? | 13:00 |
| zyga | renato__: (truncated etc) | 13:00 |
| zyga | renato__: I have to run to a standup now, ttyl | 13:01 |
| renato__ | zyga, yes it is empty: -rw------- 1 root root 0 nov 11 20:07 ubuntu-calendar-app_x1.snap | 13:01 |
| zyga | renato__: please include that in your report | 13:03 |
| zyga | renato__: I think this explains a lot | 13:03 |
| tvoss | zyga: a step further, tests/upgrade/basic breaks in a different way now: http://pastebin.ubuntu.com/23485459/ | 13:10 |
| zyga | tvoss: looking | 13:10 |
| zyga | hmm hmm | 13:10 |
| zyga | tvoss: is everything pushed? I'll pull and see | 13:11 |
| tvoss | zyga: yup | 13:11 |
| zyga | k pulling | 13:11 |
| renato__ | zyga, https://bugs.launchpad.net/snappy/+bug/1642257 | 13:11 |
| mup | Bug #1642257: Fail to remove app <Snappy:New> <https://launchpad.net/bugs/1642257> | 13:11 |
| zyga | renato__: thank you | 13:12 |
| zyga | renato__: did you have a power failure or something like that? | 13:12 |
| zyga | renato__: I wonder why that snap got empty | 13:12 |
| tvoss | zyga: --allow-downgrades is certainly needed in tests/upgrade/basic/task.yaml when instaling the previous version | 13:12 |
| renato__ | zyga, welcome. | 13:12 |
| mup | Bug #1642257 opened: Fail to remove app <Snappy:New> <https://launchpad.net/bugs/1642257> | 13:13 |
| renato__ | zyga, I am not sure. But since this is a vm. I could kill it by mistake | 13:13 |
| zyga | renato__: how many times did you install that snap, what is the time snap (roughly) | 13:13 |
| renato__ | zyga, Im testing the plataform content share. I installed a lot of snap in the last days | 13:14 |
| renato__ | What do you mean by "time snap"??? | 13:14 |
| zyga | renato__: time span, roughly how many hours/days | 13:14 |
| renato__ | zyga, a lot, probably more than 20 times a day | 13:15 |
| renato__ | not the same snappy, but different versions | 13:15 |
| davidcalle | 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:16 |
| zyga | sergiusens: are you up for the meeting in 10 minutes? | 13:20 |
| sergiusens | zyga I am awake, yes | 13:23 |
| zyga | sergiusens: great, see you soon | 13:23 |
| sergiusens | zyga thanks for the reminder, I am getting no notifications/reminders lately | 13:24 |
| renato__ | zyga, do I still need to keep my system freeze. Or can I somehow remove the broken package? | 13:33 |
| Elleo | 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:35 |
| jdstrand | mvo: woot! nice find for the lxc bug. curious-- am I entering the container wrong? | 13:39 |
| jdstrand | Elleo: let me check something | 13:40 |
| Elleo | jdstrand: okay, thanks | 13:40 |
| === hikiko|afk is now known as hikiko | ||
| jdstrand | 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 |
| mvo | jdstrand: well, sort of. sudo -u keeps some SUDO_* vars around that confused snapd, but really its a bug in snapd | 13:42 |
| pedronis | jdstrand: hi, we merged removing LegacyAutoConnect btw, mvo did the work | 13:42 |
| jdstrand | 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 |
| jdstrand | pedronis: I saw that | 13:43 |
| * jdstrand hugs mvo | 13:43 | |
| jdstrand | mvo: otoh, do you know of a better way to enter the chroot as non-root? | 13:43 |
| Elleo | jdstrand: ah right, shall I write an equivelant helper function in utils.go to handle that then? | 13:43 |
| jdstrand | Elleo: let me get you the commit that pulled it out | 13:43 |
| Elleo | jdstrand: ah, cool, thanks | 13:44 |
| pedronis | jdstrand: it was on my todo list but mvo graciously got there first | 13:44 |
| jdstrand | pedronis: yeah, it came up in a PR the other day that it was adding confusion | 13:45 |
| mvo | jdstrand: alternatively you could use "su -l -s /bin/sh" | 13:47 |
| mvo | jdstrand: "su -l -s /bin/sh your-user" of course | 13:47 |
| jdstrand | Elleo: dbus.SafePath() was not removed. 578d0c80f71c55c7b8a9e40382b62fd25dbd836d removed APP_ID_DBUS. you can add it back in interfaces/apparmor/template_vars.go. I think you should have SNAP_ID_DBUS for snap.name.app. I don't know if you need SNAP_NAME_DBUS for SNAP_NAME or not, but if you do, start with that name | 13:51 |
| jdstrand | mvo: yeah-- I was more thinking of an lxc-y way of entering it. thanks!' | 13:51 |
| liuxg | jdstrand, I have attached the .snap file for the input method. did you see it? thanks | 13:52 |
| jdstrand | Elleo: so SNAP_ID_DBUS -> APP_ID_DBUS and if needed SNAP_NAME_DBUS -> APP_PKGNAME_DBUS | 13:52 |
| jdstrand | liuxg: I haven't yet but will take a look | 13:52 |
| jdstrand | liuxg: thanks | 13:52 |
| liuxg | zyga, my colleague has a simple slot use case like http://paste.ubuntu.com/23485602/.. May I know whether it is fine for a snap app? thanks | 13:53 |
| jdstrand | Elleo: I'm not in love with 'SNAP_ID_DBUS' | 13:53 |
| liuxg | jdstrand, you are welcome. I think you probably did not build it successfully. the snap file is pretty big. | 13:53 |
| jdstrand | Elleo: lets do SNAP_LABEL_DBUS. I think that will fly better | 13:54 |
| jdstrand | liuxg: yeah, I ran snapcraft and a snap popped out. I didn't try to debug further | 13:54 |
| liuxg | jdstrand, my colleauge and I both successfully built the project. I think the source code should be fine :) | 13:55 |
| * jdstrand shrugs | 13:55 | |
| jdstrand | git clone followed by snapcraft | 13:56 |
| Elleo | jdstrand: okay, cool; thanks very much :) | 13:56 |
| liuxg | jdstrand, the UI is like http://imgur.com/a/fccq5, you can select the "search" button to input some Chinese characters. Should you have any problem with it, please let me know. thanks | 13:58 |
| timp | davidcalle: okay, thanks. | 14:01 |
| liuxg | jdstrand, if a snap uses "slot" instead of "plug" like the way in http://paste.ubuntu.com/23485602/, the snap will be subject to manual review, right? It in fact can access the audio hardware. | 14:04 |
| zyga | slangasek: hey, just FYI, it looks like arm64 build of snapd in sid is not migrated/up to date | 14:13 |
| matteo | Chipaca: I will rebase it | 14:13 |
| Chipaca | matteo: 'k | 14:13 |
| icey | I'm trying to use the rust plugin for snapcraft on launchpad, and I'm failing builds with a lot of missing dependencies: curl and file so far; should these be added to the rust plugin or somewhere else? | 14:17 |
| jdstrand | liuxg: re slots-- most of the time, yes. this is all defined in the basedeclaration.go file. the reason why is that the slot side gives privileged access to the system and need a snap declaration to allow it | 14:19 |
| jdstrand | liuxg: is this just a theoretical example or are you trying to work around a permissions problem that the pulseaudio slot happens to give you? | 14:19 |
| jdstrand | I guess it is an example base on the text in the snapcraft.yaml | 14:20 |
| mterry | If one of the packages in a stage-packages list is uninstallable, what does snapcraft do? (I'm maybe seeing that it quietly doesn't include that package?) | 14:20 |
| Elleo | /22 | 14:21 |
| flexiondotorg | Best lxd name for a cleanbuild e-v-e-r - snapcraft-easily-secure-gnu | 14:21 |
| icey | are the builders on launchpad restricting access to some egress? this builder grabbed the rust installer fine but couldn't resolve github.com to fetch dependencies: https://launchpadlibrarian.net/293675704/buildlog_snap_ubuntu_zesty_amd64_rust-hello_BUILDING.txt.gz | 14:22 |
| liuxg | jdstrand, yes, it is a demo example from my colleague. the script is like http://paste.ubuntu.com/23485745/, from my perspective, we normally only use plug instead of slot. I want to know what is the limitation of using slot in a snap app? thanks | 14:25 |
| flexiondotorg | icey, There is no network connectivy during the build step on LP, only the pull step. | 14:25 |
| popey | mterry: in my experience it just stops | 14:25 |
| icey | flexiondotorg: that's unfortunate, but not exactly surprising | 14:25 |
| mterry | popey: I see that for build-packages. But have hints that does different on stage-packages | 14:25 |
| flexiondotorg | icey, I'm hoping to discuss with sergiusens today. | 14:26 |
| mterry | At least a silo snap build quietly skipped it | 14:26 |
| flexiondotorg | I've got a Python package that won't build on LP, even though I've pulled everything in the pull step. | 14:26 |
| sergiusens | flexiondotorg oh, really? :-) | 14:26 |
| flexiondotorg | o/ | 14:27 |
| flexiondotorg | Yep. | 14:27 |
| flexiondotorg | I discussed with didrocks earlier. | 14:27 |
| flexiondotorg | I have a Python project. | 14:27 |
| qengho | icey: bring your dependencies in as other "part"s. | 14:27 |
| flexiondotorg | snapcraft pulls all requirements.txt in the pull step. | 14:27 |
| flexiondotorg | And then pulls again in the build step. | 14:27 |
| icey | flexiondotorg: what are the odds of network acecss during build? I can work around it by vendoring deps; qengho cargo (the tool used to build rust binaries) also generally handles dependency management and fetching | 14:28 |
| flexiondotorg | And the build fails. | 14:28 |
| flexiondotorg | icey, I've been told unlikey. | 14:28 |
| icey | flexiondotorg: then I'll continue with the idea of vendoring the deps into the project :-/ | 14:28 |
| qengho | icey: part: rustthing: after: [ partnamethatprovidesthethingyounormallydownload ] | 14:28 |
| liuxg | jdstrand, what is the fundamental difference between using a slot and using a plug? | 14:29 |
| qengho | One provides, one uses. | 14:29 |
| sergiusens | flexiondotorg ok, now I can type better without a baby between keyboard and parent :-) | 14:29 |
| flexiondotorg | sergiusens, Here is my snapcraft.yaml | 14:29 |
| icey | qengho: is it possible to have a part that just runs a bash command? | 14:29 |
| flexiondotorg | https://git.launchpad.net/podpublish/tree/snapcraft.yaml | 14:29 |
| sergiusens | flexiondotorg is it using a VCS dependency? I have a tentative solution for that | 14:29 |
| qengho | icey: Yes. You might have to make your own plugin, but yes, totally. | 14:30 |
| flexiondotorg | sergiusens, Here is the failure log | 14:30 |
| flexiondotorg | https://launchpadlibrarian.net/293648430/buildlog_snap_ubuntu_xenial_amd64_podpublish_BUILDING.txt.gz | 14:30 |
| flexiondotorg | Which still happens even after doing this: | 14:30 |
| flexiondotorg | https://git.launchpad.net/podpublish/commit/?id=edd30ec9016840e870f1c8e4c2fca516231b351b | 14:30 |
| icey | qengho: I can pmodify the Rust plugin to pull deps in the pull step...? | 14:31 |
| renato__ | jdstrand, hey, can I auto-connect to content-share interface? Somehow specify the auto-connect on snapcraft file? | 14:31 |
| flexiondotorg | sergiusens, I'm happy to help test/fix. I'm building snaps on my own computer like an animal right now ;-) | 14:31 |
| sergiusens | flexiondotorg hmm, I thought I resolved this bug... | 14:32 |
| sergiusens | flexiondotorg do we have a bug for this? | 14:32 |
| flexiondotorg | sergiusens, Not yet. I was waiting to talk with you first. | 14:33 |
| sergiusens | qengho icey we are going to allow scriplets in parts, stay tuned | 14:33 |
| icey | is it possible to ship a custom plugin with a snap? I'd love to test a change on the LP builder | 14:33 |
| icey | sergiusens: it kind of makes more sense (I think) in the rust plugin, as it's something that every rust snap will need to do on LP | 14:34 |
| sergiusens | flexiondotorg I know what the problem is; I thought I had fixed it, I guess I didn't | 14:34 |
| flexiondotorg | :-) | 14:34 |
| sergiusens | icey you can add a custom plugin to your snapcraft project | 14:34 |
| flexiondotorg | sergiusens, Do you want a new bug for this? | 14:34 |
| sergiusens | not sure what a custom plugin for a snap would mean | 14:35 |
| flexiondotorg | If so, on GH or LP? | 14:35 |
| sergiusens | flexiondotorg there is no bug :-) LP; GH issues are closed ;-) | 14:35 |
| sergiusens | flexiondotorg are you subscribed to snapcraft-announce? :-) | 14:35 |
| icey | sergiusens: can I overwrite a normal plugin within my project? or will I have to wait on it getting into snapcraft proper? | 14:35 |
| flexiondotorg | Yep, am subscribed. | 14:35 |
| sergiusens | icey copy the plugin | 14:36 |
| sergiusens | flexiondotorg https://github.com/snapcore/snapcraft end of page for link to tracker :-) | 14:36 |
| icey | sergiusens: copy to where? | 14:36 |
| sergiusens | icey http://snapcraft.io/docs/build-snaps/plugins | 14:37 |
| qengho | icey: If you add a parts/plugins/x-iceyplugin.py to your project, then you can use "iceyplu" in your YAML. | 14:41 |
| qengho | iceyplugin | 14:42 |
| sergiusens | flexiondotorg btw, any updates on the app indicator hack you had for me? | 14:42 |
| flexiondotorg | sergiusens, Trevinho see above ^ | 14:43 |
| flexiondotorg | sergiusens, Trevinho has been working on it. | 14:43 |
| qengho | When should we expect the configure hook to work in snappy on classic? | 14:43 |
| * Trevinho reads | 14:44 | |
| sergiusens | qengho once the latest snapd migrates into -updates | 14:44 |
| qengho | thx. | 14:45 |
| flexiondotorg | Trevinho, sergiusens is asking about the indicator icons in snaps. | 14:46 |
| jdstrand | liuxg: slots provide resources and slots consume them | 14:46 |
| jdstrand | liuxg: you might be interested in zyga's blog series: http://www.zygoon.pl/search/label/snappy | 14:47 |
| flexiondotorg | sergiusens, Here's you bug :-) https://bugs.launchpad.net/snapcraft/+bug/1642281 | 14:47 |
| mup | Bug #1642281: Unable to build python based snap on Launchpad <Snapcraft:New> <https://launchpad.net/bugs/1642281> | 14:47 |
| jdstrand | renato__: you cannot specify auto-connect in the snapcraft.yaml. content is supposed to auto-connect from the same publisher | 14:47 |
| Trevinho | sergiusens: so, I'm currently fixing the various qt-sni, appmenu-qt and libappindicators to work propery... This last one still has some problems if confined because interface didn't cover properly all the dbus methods, but jdstrand fixed it... However the idea is to save icons in readable places such as ~/.cache (or better when possible in xdg runtime dir) | 14:48 |
| Trevinho | so that unity can read them... | 14:48 |
| Trevinho | for themed icons, instead, we can just pass to compiz the proper $SNAP/usr/share/icons as theme path (or ~/.local/share/icons), and that will work | 14:49 |
| liuxg | jdstrand, yes, I have read that blog, and I even made the slot working. My question is whether it is fine to use a slot as the way in the snap example.. My understanding is that "slot" is normally used in a service provider, and it needs to be reviewed. | 14:50 |
| Trevinho | howver, I'm loving how I can distribute snaps with my patched libraries without having to worry about them to reach the distro :-D. | 14:50 |
| Trevinho | so sergiusens once I've the branches ready you could rebuild your telegram app properly | 14:50 |
| sergiusens | Trevinho oh, the telegram app uses forked Qt ;-) | 14:51 |
| Trevinho | sergiusens: well, appmenu-qt should be still there, isn't it? | 14:52 |
| Trevinho | sergiusens: I mean the implementation of the tray icon is still a plugin | 14:52 |
| jdstrand | liuxg: you use a slot if you are providing an implementation for that slot. you used the pulseaudio slot. this snap would be expected to provide pulseaudio functionality such that if something on the system used 'plugs: [ pulseaudio ]' that that snap would be fully functional | 14:53 |
| sergiusens | Trevinho http://paste.ubuntu.com/23485830/ | 14:53 |
| jdstrand | liuxg: think of interfaces as contracts between the slot side and the plugs side | 14:53 |
| Trevinho | sergiusens: I don't see any qt bit there... statically linked I guess, right? | 14:54 |
| jdstrand | liuxg: if the slots side isn't honring the contract (ie, in this case, using pulseaudio but (perhaps) not providing it, then it has broken the contract | 14:54 |
| liuxg | jdstrand, an interesting thing is that http://paste.ubuntu.com/23485745/ shows the result if "pulseaudio" slot is used that way. | 14:56 |
| zyga | jdstrand: hey | 14:56 |
| zyga | jdstrand: you may have noticed I pushed some patches into your branch | 14:56 |
| liuxg | jdstrand, the snap does not provide the implementation for the slot, but just uses it. So, this snap breaks the contract, and it is not the normal use case of slot? | 14:58 |
| icey | how long does it generally take for a commit that lands in master to be available on the LP builders? | 14:59 |
| mup | PR snapcraft#908 opened: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908> | 15:01 |
| jdstrand | liuxg: if the snap only uses the slot, you should use plugs, not slots | 15:03 |
| jdstrand | liuxg: you are correct-- a snap that does not provide the implementation for the slot should not use slots | 15:03 |
| jdstrand | zyga: I haven't circled all the way around yet, but yes | 15:04 |
| liuxg | jdstrand, what happens if a developer uses this way in the app? should we have some check for this when publishing the app? | 15:04 |
| jdstrand | liuxg: on upload, the snap would be flagged for manual review. then a reviewer would ask questions | 15:15 |
| liuxg | jdstrand, if there is no implementation of the interface, the snap will be rejected? thanks | 15:16 |
| qengho | Is there a way to safely ship a snap that has a configure hook? I'm worried that the current snapd poisons configure hooks for a while. I can never know if someone has a snapd that lets a hook exist. | 15:16 |
| zyga | qengho: I think you can use assumes stanza | 15:17 |
| zyga | qengho: "assumes: ..." | 15:17 |
| zyga | qengho: that snap won't install unless snapd supports a given feature | 15:17 |
| zyga | qengho: I think there's one for hooks | 15:18 |
| qengho | zyga: like, it isn't selected for install from the store then, and falls back? | 15:18 |
| zyga | qengho: but since 2.17 AFAIR we have dynamic assumes, so you can just say "assumes: snapd-2.17" | 15:18 |
| jdstrand | liuxg: yes, it would be rejected | 15:18 |
| zyga | qengho: if you add that to a snap and try to install it snapd will give you an useful message and stop | 15:18 |
| coreycb | sergiusens, hi, for openstack the upstream python projects have tox targets for generating some of the config files. they are typically just commands that are shipped either in the same source tree or in another python project. | 15:22 |
| qengho | zyga: so once I ship a version with a configure hook, users with some versions of snapd are stuck. The difference is they might learn why if they go type "snap {refresh,install}" in a terminal? | 15:22 |
| coreycb | sergiusens, we're thinking of extending the python plugin with an openstack plugin, but would be curious on your thoughts | 15:23 |
| qengho | I guess if their snapd is old enough, it might also still work without configure interface. | 15:24 |
| sergiusens | coreycb there's a feature coming that might help you out with this, but given you will have to copy paste this all over and an openstack plugin would be used in more than one project (it is openstack after all) a specific plugin would be just fine | 15:25 |
| sergiusens | coreycb you can inherit from the python one if needed | 15:26 |
| coreycb | sergiusens, what's the upcoming feature? | 15:27 |
| sergiusens | coreycb scriptlets for parts, prepare, build, install | 15:28 |
| sergiusens | err... parts: prepare, build, install | 15:28 |
| liuxg | jdstrand, thanks for your explanation :) | 15:28 |
| coreycb | sergiusens, ah right i've heard about that. would i be able to get my hands on a dev version of that? | 15:29 |
| zyga | qengho: well, core refreshes automatically | 15:29 |
| zyga | qengho: and they will be stuck with the old version | 15:29 |
| zyga | qengho: I think that is a very sensible behavior | 15:29 |
| mup | Bug #1583514 changed: firewall-control and ip[6]table_filter module loading <snapd-interface> <Snappy:Fix Released by stolowski> <https://launchpad.net/bugs/1583514> | 15:37 |
| jdstrand | liuxg: yw | 15:39 |
| Trevinho | sergiusens: anyway telegram usess libappindicator under the hood.... https://github.com/telegramdesktop/tdesktop/blob/master/Telegram/SourceFiles/platform/linux/linux_libs.cpp#L119 | 16:03 |
| zyga | tvoss: one observation that is interesting | 16:13 |
| zyga | tvoss: when the test failed, I ran "mount" | 16:13 |
| zyga | tvoss: qemu:ubuntu-14.04-64 .../tests/main/interfaces-mount-observe# mount | 16:14 |
| zyga | tvoss: that didn't show any of the preserved namespaces | 16:14 |
| zyga | tvoss: (the bind mounts from nsfs) | 16:14 |
| zyga | tvoss: ah, ignore me, it's just mount being dumb (smart) | 16:15 |
| zyga | 143 47 0:3 mnt:[4026532106] /run/snapd/ns/mount-observe-consumer.mnt rw - nsfs nsfs rw | 16:15 |
| zyga | it's there | 16:15 |
| matteo | Chipaca: I've refreshed the PR, but I have to edit the wiki as I had edited interfaces.md | 16:15 |
| matteo | but I'll do it only after the PR merge | 16:15 |
| zyga | hmm | 16:15 |
| zyga | tvoss: but interestignly, the /snap is not | 16:15 |
| zyga | qemu:ubuntu-14.04-64 .../tests/main/interfaces-mount-observe# systemctl status snapd-mount.service | 16:16 |
| zyga | Active: inactive (dead) | 16:16 |
| zyga | tvoss: maybe something eagerly cleans up | 16:16 |
| zyga | tvoss: (purge test?) | 16:16 |
| zyga | tvoss: and then we're broken | 16:16 |
| zyga | tvoss: what do you think? | 16:16 |
| zyga | tvoss: I'll remove the stop condition | 16:17 |
| zyga | tvoss: and make this a oneshot service | 16:17 |
| zyga | tvoss: just a longshot | 16:17 |
| tvoss | zyga: without a stop condition, we will run into issues in snapd.postrm | 16:17 |
| zyga | tvoss: will we? it's just a bind mount | 16:17 |
| zyga | tvoss: though... | 16:17 |
| zyga | tvoss: you mean removal of /snap? | 16:17 |
| tvoss | zyga that tries to remove /snap and the removal fails | 16:17 |
| tvoss | yup | 16:17 |
| zyga | tvoss: did you change that to be opportunistic? | 16:18 |
| tvoss | nope | 16:18 |
| zyga | tvoss: ok, so when should this be applied | 16:18 |
| zyga | tvoss: sorry, to rephrase | 16:18 |
| zyga | tvoss: when should this unit be "up" | 16:18 |
| zyga | tvoss: IMHO all the time (when snapd is installed) | 16:18 |
| zyga | tvoss: but the effect is clearly undone | 16:18 |
| tvoss | zyga: well, ideally before any snap specific mount job | 16:18 |
| zyga | anything in the restore scripts that might do this? | 16:19 |
| zyga | tvoss: yep | 16:19 |
| zyga | tvoss: maybe we can tie it to snapd.service? | 16:19 |
| tvoss | zyga: let me check @restore script | 16:19 |
| zyga | tvoss: before | 16:19 |
| zyga | tvoss: that would fix it | 16:19 |
| zyga | as long as nothing manually changes /snap | 16:19 |
| tvoss | are all mount units "after" snapd | 16:19 |
| zyga | and the unit should be oneshot and remainafterexit=yes | 16:19 |
| zyga | tvoss: .mount units? I think before actually | 16:19 |
| tvoss | and cleanup of /snap should be opportunistic? | 16:19 |
| zyga | snapd needs to read them | 16:20 |
| tvoss | ah, so we want all mount units to be after snapd-mount.service | 16:20 |
| zyga | tvoss: well... not strtictly, rbind should handle that | 16:21 |
| zyga | tvoss: the problem I saw right now is that the effect was undone by something | 16:21 |
| zyga | tvoss: I switched to oneshot units so that we can at least see if the unit is up or down next time it happens | 16:22 |
| tvoss | +1 | 16:22 |
| zyga | tvoss: but I think we should be "before snapd.service" | 16:22 |
| zyga | (not sure how to specify that yet) | 16:22 |
| tsdgeos | any reason a dbus call would fail to an existing dbus service if it's running in a non confined snap? | 16:22 |
| zyga | tvoss: I think the restore scripts do that | 16:22 |
| zyga | tsdgeos: yes, because confined processes cannot reach out to arbitrary dbus endpoints (including unconfined) | 16:23 |
| zyga | tsdgeos: look for apparmor denials in the journal | 16:23 |
| tsdgeos | zyga: even between processes on the same "unconfined snap"? | 16:23 |
| zyga | tsdgeos: there are no unconfined snaps | 16:23 |
| tsdgeos | ok :D | 16:23 |
| zyga | tsdgeos: a process in a snap cannot reach out to dbus services from outside that snap (confined or not) | 16:24 |
| tsdgeos | zyga: a little more help with "look for apparmor denials in the journal" ? | 16:24 |
| zyga | tsdgeos: look for the apparmor denials | 16:24 |
| zyga | tsdgeos: grep for DENIED :) | 16:24 |
| zyga | tsdgeos: and there's a snapd-debug snap AFAIK | 16:24 |
| zyga | tsdgeos: it helps but there's always the raw log | 16:24 |
| tsdgeos | zyga: where do i grep (yes i'm very newbie) | 16:25 |
| tsdgeos | i.e. where's the journal? | 16:25 |
| zyga | tsdgeos: journalctl | grep DENIED | 16:25 |
| tsdgeos | ah, tx | 16:25 |
| tvoss | zyga: aha, tests/lib/reset.sh purges a lot of stuff and only starts snapd.socket again | 16:26 |
| * zyga looks | 16:26 | |
| tvoss | zyga: at the very least, we should run snapd.prerm before snapd.postrm purge | 16:26 |
| tvoss | zyga: and do a systemctl start snapd-mount.service | 16:27 |
| zyga | tsdgeos: crashed again, different test (aaargh, the ordering) | 16:29 |
| zyga | er | 16:29 |
| zyga | tvoss: ^ | 16:29 |
| zyga | tvoss: checking service status | 16:29 |
| zyga | Active: active (exited) since Wed 2016-11-16 17:27:00 CET; 2min 36s ago | 16:29 |
| tsdgeos | sorry for starting with t :D | 16:29 |
| zyga | qemu:ubuntu-14.04-64 .../tests/upgrade/basic# cat /proc/self/mountinfo | grep /snap | 16:29 |
| zyga | 45 23 8:1 /snap /snap rw,relatime shared:1 - ext4 /dev/sda1 rw,data=ordered | 16:29 |
| zyga | this time it looks good | 16:30 |
| zyga | but the test still failed | 16:30 |
| tvoss | argh | 16:30 |
| zyga | tsdgeos: no worries :) | 16:30 |
| tvoss | zyga: ignore upgrade/basic for now, I haven't fixed that, yet | 16:30 |
| zyga | tvoss: so at least this much is better | 16:30 |
| tvoss | zyga: investigating after a round of meetins | 16:30 |
| zyga | internal error, please report: running "test-snapd-tools.echo" failed: cannot find installed snap "test-snapd-tools" at revision 3 | 16:30 |
| tvoss | zyga: yeah, thats the "snap list" reports broken packages | 16:30 |
| zyga | broken == snapd cannot read meta/snap.yaml | 16:31 |
| zyga | so unmounted or messed up mounts | 16:31 |
| zyga | I'll return to that test, trying the rest | 16:31 |
| zyga | so far, suspiciously green | 16:38 |
| tvoss | green is the new black | 16:39 |
| zyga | still good | 16:42 |
| zyga | just ran 2016/11/16 17:50:33 Restoring qemu:ubuntu-14.04-64:tests/main/postrm-purge... | 16:50 |
| zyga | so if stuff fails now it might be related | 16:50 |
| zyga | still green | 16:52 |
| zyga | tvoss: any idea if just doing this might have such a big impact? | 16:52 |
| zyga | http://paste.ubuntu.com/23486289/ | 16:53 |
| zyga | tvoss: another idea, have snapd do it :) | 16:53 |
| zyga | tvoss: before any any any operation | 16:53 |
| zyga | tvoss: on early startup | 16:53 |
| zyga | tvoss: read mountinfo and do the bind mount dance | 16:53 |
| zyga | tvoss: or from snap-confine's code (we parse mountinfo already) | 16:53 |
| zyga | tvoss: but that's after we are merged | 16:54 |
| zyga | (into snapd) | 16:54 |
| tvoss | zyga: yeah, so I think the unit is fine | 16:54 |
| tvoss | a bit ugly, but it gets the job done quite reliably | 16:54 |
| zyga | tvoss: it may bind mount /snap twice | 16:55 |
| zyga | tvoss: semi harmless but still ... | 16:55 |
| zyga | tvoss: ha | 16:56 |
| zyga | tvoss: 2016/11/16 17:54:22 Failed tasks: 1 | 16:56 |
| zyga | tvoss: just the - qemu:ubuntu-14.04-64:tests/upgrade/basic | 16:56 |
| zyga | I'll run another loop and commit this | 16:56 |
| tvoss | ack, great | 16:56 |
| zyga | tvoss: if it breaks on the upgrade job again I'll dig into it | 16:56 |
| zyga | tvoss: pushed | 16:56 |
| tvoss | zyga: ack and thx | 16:57 |
| zyga | the weird and invasive change made by github is probably the biggest collaborationi booster ever in foss community | 16:57 |
| tvoss | zyga: I'm not following for the "bind mount twice" argument | 16:57 |
| zyga | just push to all the pull requests!! | 16:57 |
| tvoss | zyga: you mean actually collaborating on something? | 16:57 |
| tvoss | ;) | 16:57 |
| zyga | tvoss: if the service breaks after rbind /snap but before --make-rshared | 16:57 |
| zyga | tvoss: exactly ;-) | 16:57 |
| tvoss | zyga: hmmm, I'm taking a note, usually pitti has some good advice to offer, too | 16:58 |
| zyga | tvoss: feels like a simple C program to write | 17:04 |
| zyga | (conditions apply) | 17:04 |
| tvoss | zyga: you mean to check mount info | 17:04 |
| zyga | tvoss: yes | 17:07 |
| zyga | tvoss: but snap-confine can | 17:07 |
| zyga | tvoss: (or the sources have api for that) | 17:07 |
| zyga | got an unrelated store failure, iterating | 17:08 |
| zyga | tvoss: I'me EODing, tests in flight | 17:28 |
| zyga | tvoss: what is the situation you see now? | 17:28 |
| mterry | sergiusens: I'm seeing a weird bug. When I'm building the u8 snap locally, webbrowser-app (directly listed in stage-packages) is included just fine. But when building in a silo, it's not included. Build log doesn't even mention it. https://launchpadlibrarian.net/293688704/buildlog_snap_ubuntu_xenial_amd64_unity8-session-silo_BUILDING.txt.gz | 17:32 |
| mterry | Do you know of any reasons snapcraft would silently exclude a stage-package? | 17:32 |
| kyleN | Hi. are qt apps snappable yet with strict? mine does not display without devmode and i notice devmode is common in playpen qt apps. | 17:36 |
| popey | kyleN: yes | 17:37 |
| kyleN | popey, is there an example snapcraft.yaml you can point me to? | 17:37 |
| popey | not sure, I don't really work on desktop stuff | 17:37 |
| popey | I have done a couple of personal snaps which include qt | 17:37 |
| popey | and they don't need devmode, I'm not sure why you'd think qt would need it | 17:38 |
| kyleN | popey. because when I set to devmode it displays, when I set to strict it does not actually display. I do add: after: [desktop/qt5]. any further tips? | 17:38 |
| popey | check what's failing with dmesg | grep DENIED | 17:39 |
| popey | also snappy-debug.security scanlog | 17:39 |
| popey | run ^ that, then start your app | 17:39 |
| popey | (in strict) | 17:39 |
| kyleN | popey, snappy-debug.security scanlog MYAPP | grep DENIED does not show much. wherease desmg shows a lot of DENIEDs. | 17:42 |
| kyleN | popey, on closer inspection I don't think the dmesg DENIEDs are related to my snap | 17:45 |
| popey | what exactly is appearing? | 17:46 |
| popey | and what happens when you run the app? | 17:46 |
| kyleN | I see evince and docker denieds which are not related. | 17:47 |
| kyleN | when I run my app in strict, I simply do not see a window for it. in devmode I do | 17:47 |
| popey | strace it? | 17:47 |
| popey | see what it stops on | 17:48 |
| kyleN | ok thanks for the tip | 17:49 |
| kyleN | popey, hmm: QXcbConnection: Could not connect to display :0 | 17:52 |
| kyleN | popey, yet I do have this: plugs: [unity7, x11, opengl, network-bind] | 17:52 |
| kyleN | anyway, enough to go on for now | 17:53 |
| popey | it's X11 I think? | 17:54 |
| popey | I have a horrid feeling it's case sensitive | 17:54 |
| === JanC is now known as Guest70154 | ||
| === JanC_ is now known as JanC | ||
| sergiusens | kyleN popey you can always run `snap interfaces` to verify it is connected | 18:47 |
| tvoss | zyga: catching up after dinner, hang on | 19:01 |
| zyga | tvoss: I'm spending time with kids now, sorry, just drop me messages | 19:14 |
| tvoss | Zyga, no worries, I'll keep you posted 😀 | 19:19 |
| mwhudson | davmor2: hey, i assume from the lack of noise that console-conf works for you now? | 19:31 |
| davmor2 | mwhudson: no sorry got moved onto something else I'll have a look in a minute | 19:32 |
| mwhudson | davmor2: ah ok | 19:32 |
| icey | sergiusens: when I run the apt command to install test dependencies (in hacking.md), I get unable to locate package python3-responses | 19:32 |
| icey | taking that out leaves me unable to run the unit tests | 19:32 |
| davmor2 | mwhudson: yeap works now | 19:36 |
| Trevinho | sergiusens: hey, how do organize a remote part? | 19:36 |
| Trevinho | I mean if I've a file locally that will override something on remote, I want not to stage the remote par t bits... but how can I do it? | 19:37 |
| davmor2 | mwhudson: damn you, you're fixing my bugs to quickly now I feel obliged to find more ;) | 19:48 |
| elopio1 | exit | 20:03 |
| mup | PR snapcraft#906 closed: indicators: support TERM=dumb <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/906> | 20:52 |
| sergiusens | Trevinho you use stage and snap keywords, not organize, unless you want to move it out of the way instead | 20:54 |
| Trevinho | sergiusens: yeah, I meant organizing in a general term.. not in the keyword... But still, I can't apply a such thing to a remote part, isn't it? | 20:55 |
| sergiusens | Trevinho yes you can | 20:56 |
| sergiusens | Trevinho it overrides do, so snapcraft define <part> to see if it defines anything and aggregate to that | 20:56 |
| Trevinho | sergiusens: mh, I'm missing the syntax then... | 20:56 |
| sergiusens | icey HACKING.md does not mention python3-responses, just pip3 install -r ... | 20:57 |
| sergiusens | icey debian/control however does, but it is not mentioned in HACKING.md | 20:57 |
| icey | sergiusens: look at the top... in the section titled: Test Dependencies | 20:57 |
| icey | - You'll need to add the following dependencies to run the tests. | 20:57 |
| icey | sudo apt install python3-flake8 python3-fixtures python3-testscenarios python3-mock python3-responses | 20:57 |
| sergiusens | icey oh look at that :-( | 20:58 |
| sergiusens | icey can I ask you to follow https://github.com/snapcore/snapcraft/blob/master/HACKING.md#installing-using-pip | 20:58 |
| icey | sergiusens: and I just filed a bug on LP because I apparently can't get the tests running on clean xenial either | 20:58 |
| icey | using the pip installer | 20:59 |
| sergiusens | icey python3-responses should be on xenial though | 20:59 |
| sergiusens | icey I am on xenial and reinstalled recently and did a test run on the pip instructions | 20:59 |
| icey | sergiusens: I first ran into that trying to test on trusty (my goto test docker box) | 20:59 |
| icey | sergiusens: following the pip instructions, I get AttributeError: python3: undefined symbol: archive_errno | 21:00 |
| sergiusens | icey oh, deb deps on trusty would be really out of date | 21:00 |
| sergiusens | icey you really want xenial | 21:00 |
| icey | sergiusens: agreed, and my real machine is on Zesty | 21:00 |
| sergiusens | icey oh... rpm support added that :-/ | 21:00 |
| icey | sergiusens: so... how do I run tests now? | 21:00 |
| Trevinho | sergiusens: oh, so with "snapcraft define desktop-qt5" (say) i see the part definition, but... then? | 21:00 |
| Trevinho | I mean I should redefine it locally? | 21:01 |
| sergiusens | icey can you try installing libarchive13 | 21:01 |
| sergiusens | icey apt install | 21:01 |
| sergiusens | Trevinho http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/ | 21:02 |
| icey | sergiusens: trying now | 21:02 |
| sergiusens | icey if it works I'll fix hacking.md right now | 21:03 |
| Trevinho | sergiusens: ok, great... thanks | 21:03 |
| icey | sergiusens: I don't mind submitting a PR to update that :) | 21:03 |
| icey | python3-pip would be a good suggestion as well, the base docker ubuntu:xenial image doesn't have it :) | 21:03 |
| sergiusens | icey I want to do more than add that dep | 21:04 |
| sergiusens | sounds good | 21:04 |
| icey | sergiusens: I figure it's not bad for me to update that since I'm going through installing stuff on a clean box to get it to work :) | 21:04 |
| Trevinho | sergiusens: just wondering why that isn't inside the official docs, though... :-) | 21:05 |
| icey | sergiusens: tests haven't finished yet but are running: https://github.com/snapcore/snapcraft/pull/909 | 21:07 |
| mup | PR snapcraft#909: update dependencies for running the tests <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/909> | 21:07 |
| mup | PR snapcraft#909 opened: update dependencies for running the tests <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/909> | 21:07 |
| sergiusens | icey great and ^ | 21:11 |
| sergiusens | ah, icey you did 909? This is what I had in mind https://github.com/snapcore/snapcraft/pull/910 | 21:11 |
| mup | PR snapcraft#910: Update HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/910> | 21:11 |
| icey | sergiusens: may want to look at my pull, there's 3 packages I've found so far needed to get tests happy on a clean xenial | 21:12 |
| sergiusens | icey just missing squashfs-tools I guess | 21:12 |
| icey | sergiusens: ack | 21:13 |
| mup | PR snapcraft#910 opened: Update HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/910> | 21:13 |
| mwhudson | davmor2: :) | 21:53 |
| mup | PR snapcraft#911 opened: Remove the outdated all snaps image set up for snaps tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/911> | 22:16 |
| mup | PR snapcraft#909 closed: update dependencies for running the tests <Created by ChrisMacNaughton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/909> | 22:40 |
| mup | PR snapcraft#910 closed: Update HACKING.md <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/910> | 22:40 |
| pitti | sergiusens: FYI, I just implemented bug 164183 (elopio was asking about that) | 22:50 |
| mup | Bug #164183: sata controller/drive reports exception Emask 0x10 SAct 0x0 SErr 0x40d0002 action 0x2 frozen <linux (Ubuntu):Expired> <https://launchpad.net/bugs/164183> | 22:50 |
| * pitti appends a missing '1'.. bug 1641831 | 22:57 | |
| mup | Bug #1641831: It's not possible to select the test to run from the github integration <Auto Package Testing:Fix Released by pitti> <https://launchpad.net/bugs/1641831> | 22:57 |
| sergiusens | pitti nice! | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!