[06:04] morning [06:05] PR snapd#6274 closed: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" (2.36) [06:09] PR snapd#6277 opened: centos: enable SELinux support on CentOS 7 (2.36) === pstolowski|afk is now known as pstolowski [07:59] morning! [08:00] pstolowski: hey [08:00] mvo: welcome back! [08:01] hey pstolowski and mborzecki ! thanks, glad to be back :) [08:02] PR snapd#6272 closed: overlord/snapstate: run 'remove' hook before 'auto-disconnect' [08:03] hey mvo o/, not resting today after travel? [08:04] pstolowski: I pushed that to the end of the week, I feel I need to take care of things first and see what happend while we were away and all that [08:05] zyga: also good morning to you :) [08:08] Good morning :-) [08:09] mvo: hi. I tried pushing an update to test-snapd-dbus-service last week that seems to have got stuck. Launchpad built it okay, but it never published. Is it waiting for "request manual review" by any chance? [08:10] mvo: how are you feeling? I though you planned on taking a swap day today [08:10] zyga: hey [08:10] o/ [08:11] jamesh: good morning (evening in your case I guess) - let me check what is going on there [08:11] zyga: I feel better, I will swap end-of-week-ish I want to see what I missed and if there is anything I can help unblocking today [08:12] mvo: by the way, your original PR was very helpful in putting together mine [08:12] jamesh: \o/ happy to hear that [08:13] jamesh: thanks for working on this feature! [08:13] mvo: although I've been running into some problems with my current design for activating system services not through systemd units [08:14] what kind of problems? [08:15] zyga: when doing non-systemd activation, the dbus-daemon-launch-helper program is spawned to start the daemon [08:15] zyga: it uses a simplified version of the config file parser that ignores the directive. That means it doesn't know about the extra servicedir I configure [08:16] everything works fine for session services and systemd activated services (both system and session) [08:16] in particular, this is a problem for 14.04 where we can't do systemd activated system services [08:16] jamesh: can you give me the url to the snap that was build but is not published please? I will investigate, I don't see anything in the need-review queue right now [08:17] mvo: the builds were done with this recipe: https://launchpad.net/~mvo/+snap/test-snapd-dbus-service [08:17] which says it should publish to edge [08:18] jamesh: thank you [08:19] zyga: one option would be to refactor the branch to comingle the service files in /usr/share/dbus-1/system-services with the rest of the ones from the system -- that might be a bit messier on core systems though [08:20] mborzecki: shall we merge https://github.com/snapcore/snapd/pull/6111 ? [08:20] neal didn't comment further [08:20] PR #6111: packaging/opensuse: move most logic to snapd.mk [08:20] mvo: proposal, could we do a 2.36.3 or 2.37 end of this week [08:21] zyga: works for me, you can try and ping him one last time today [08:21] it could go to non-stable snap channel and non-ubuntu distributions [08:21] mborzecki: I'm really happy to iterate on top, just not feel like postpoing helps [08:21] zyga: ok, so let's land it [08:21] zyga: maybe ask pstolowski to take a look too [08:21] that works :) [08:22] pstolowski: would you mind having a look at the PR above, last one before landing, it refactors the build system around opensuse [08:22] and adds a shared element that can be easily reused for arch and fedora [08:22] jamesh: might be something silly like a expired macaroon that prevents the published, the last upload of this snap was >1y ago. anyway, I re-authed and triggered a new build that should do an upload then [08:23] zyga: sure [08:23] jamesh: I keep you updated [08:23] zyga: yeah, 2.37++ [08:23] zyga: thanks for raising it [08:23] mvo: it would be lower risk [08:23] zyga: unless master is for some reason unfit for this [08:23] since not stable [08:23] mvo: yeah [08:23] mvo: but we could get some casual testing over xmas period [08:23] mvo: and a better feel of what 2.37.1 might look like [08:24] mvo: awesome. I've been running spread tests locally modified to use a local copy of the package, but that's only covering a couple of distros. It'll be good to see results on the others. [08:24] zyga: yeah, having 2.37 in candidate for christmas would be great [08:24] jamesh: yeah [08:24] jamesh: you can always mail/tg me btw in such case, I was at a sprint last week so couldn't be on irc [08:28] mvo: do you know how important 14.04 compatibility is for new features? [08:28] (on topic): mvo we should ask JamieBennett or other stakeholders if 14.04 support extends over the extended paid support period [08:29] jamesh: "Store upload failed: [08:29] Cannot upload new revisions for name=test-snapd-dbus-service [08:29] " (<- not very helpful, I will ask in the store channel) [08:30] jamesh: 14.04 we still need to support until it is EOL if we want support certain desktopish things that is unfortunate but not too terrible, our 14.04 work was always more server/cloud oriented [08:30] zyga: yeah, we were talking about ESM for snapd [08:31] mvo: on the desktop side, my branch is fine. However I thought it would be worth generalising it to system services too, and that's where the problems are [08:31] so that's something that might be interesting to server/cloud [08:31] zyga: its not clear yet, I am personally not a huge fan because of the support burden (I think if we do it we need another push at systemd and update it to at least 205 there). I think it comes down to how many esm users are interessted in snaps [08:31] jamesh: oh, ok [08:32] mvo: I'm in agreement [08:32] jamesh: thats interessting, what is 14.04 missing here? is systemd too old or something else? [08:32] but at the same time it is a new feature: it's not going to break any existing snaps [08:32] jamesh: thats good [08:33] mvo: as my branch is currently designed, services directly activated by the system bus fail due to not being able to find the .service files [08:33] mvo: on 14.04 systems, this means "all system services" [08:34] on other distros where the system bus is launched by systemd, we could just tell people to make the service a daemon and be done with it [08:34] jamesh: aha, I see. so on 14.04 it is a fundamental problem because the system dbus is launched via upstart? [08:35] mvo: yes. [08:35] * mvo nods [08:35] mvo: the other option is to refactor the branch to put service files in /usr/share/dbus-1 [08:35] that means we can't assume the directory is entirely under our control [08:36] and I'm not sure whether that's desirable on an ubuntu core system [08:37] jamesh: yeah, /usr is not writable on ubuntu-core systems [08:37] jamesh: does dbus look at any other dirs for this? /etc or /run ? [08:40] mvo: the man page seems to indicate will include /usr/local/share/dbus-1/system-services and /lib/dbus-1/system-services too [08:41] although both of those could contain other files [08:41] jamesh: the other files I'm less concerned about but all of those will be read-only on core :/ [08:42] mvo: my current approach was to configure an extra through a config file in /usr/share/dbus-1/system.d, but the simplified config parser dbus-daemon-launch-helper uses ignores the include directive so doesn't see it [08:43] mvo: we're fine for systemd activated services because they don't use launch-helper [08:46] anyone up for a 2nd review on https://github.com/snapcore/snapd/pull/6277 ? it's a backport to 2.36 [08:46] PR #6277: centos: enable SELinux support on CentOS 7 (2.36) [08:46] perhaps mvo? [08:46] since it's a stable backport [08:46] mvo: ^^ pretty please [08:47] jamesh: aha, I see. hm, I need to look at the PR I think, I don't have enough state loaded right now about the details [08:47] zyga: yeah, will do, let me open it [08:56] jamesh: i386/amd64 of the snap should be available now [08:57] mvo: thanks. [08:58] PR snapd#6277 closed: centos: enable SELinux support on CentOS 7 (2.36) [09:12] moin moin moin [09:12] hello sir [09:12] how tings? [09:12] splendid [09:12] woo! [09:12] * Chipaca runs to the bank with that [09:31] hey Chipaca ! great to "see" you :) [09:32] mvo: I'd say the same, except you shouldn't be here :-) [09:34] Chipaca: nah, its fine, I will bugger off at the end of this week instead :) === cpaelzer__ is now known as cpaelzer [10:14] Chipaca: idea, on a small terminal, snap list doesn't show revision and doesn't wrap [10:14] revision is really least useful part we show [10:29] zyga: I had adaptive output for things and it got -1'ed [10:30] boooo [10:30] I'm making a quick PR to look at [10:30] very dumb [10:30] but maybe enough :) [10:30] zyga: I tried to write it up in the forum, to explore finding a way out of it === chihchun_afk is now known as chihchun [10:36] mvo, hey [10:36] cachio: hey, great to see you - how are things? [10:36] 2.36.2 is ready to stable [10:37] cachio: \o/ if all is green and the store is happy I would say: lets do it :) [10:37] cachio: did we get some feedback from the desktop team, did they had a chance to try it as well? [10:37] mvo, nice, I'll ping store people [10:37] cachio: I know we got some +1 from advocay [10:37] PR snapd#6278 opened: cmd/snap: modularize snap list processing [10:38] mvo, I didn't get any feedback [11:08] cachio: ok, thanks, should be fine, they should run beta anyway :) [11:09] zyga: do you think you could look at 5845 again? iirc I addressed a lot (most?) of your comments [11:09] mvo, I was trying to reproduce the error installing the failing.snap in the failover test [11:10] mvo, https://paste.ubuntu.com/p/RF3SSzgNG8/ [11:10] mvo, it is failing and the test exits [11:11] cachio: thanks, looking [11:11] mvo, no extra info, then the system reboots [11:12] cachio: hm, this is interessting: "Dec 08 23:42:33 dec082230-921432 snapd[1773]: daemon.go:670: Waiting for system reboot" and then "Dec 08 23:45:07 dec082230-921432 systemd[1]: snapd.service: Watchdog timeout (limit 5min)!" [11:13] cachio: what is the name of the test again? and does it always fail or is this sometihng new? [11:14] failover [11:14] mvo, it was failing since some weeks [11:15] sporadically [11:15] PR snapd#6279 opened: interfaces: tweak deny-auto-connect policy tests [11:16] mvo, 2.36.2 is stable [11:17] running smoke test now [11:18] mvo: hey, will you find some time for review 1 or 2 of my hotplug PRs? [11:21] pstolowski: I hope so [11:21] pstolowski: there is some more going on (some core18 work and prepareing 2.37) but I will put this on my list [11:30] mvo: thanks [11:30] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37 [11:31] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37 [11:31] brb [11:31] mvo: fyi, it's #6100 and #6114 [11:31] PR #6100: overlord/ifacestate: hotplug-remove-slot task handler [11:31] PR #6114: overlord/ifacestate: handler for hotplug-disconnect task [11:32] mvo: https://github.com/snapcore/snapd/pull/6279/files is broken [11:32] PR #6279: interfaces: tweak deny-auto-connect policy tests [11:32] zyga: uh, sorry, looking [11:33] does it pass for you locally [11:33] unit tests [11:40] mvo Chipaca We had an adhoc update from zyga last week about the status of the fontconfg cache fixes. What is the ETA for that landing in stable? [11:42] zyga: silly me, I will fix the issue [11:43] Wimpress: all validations are done and core is ready, cachio will do the release once he gets green light from the store [11:43] mvo, I already did the release [11:44] cachio: \o/ [11:44] Wimpress: ^- here is your answer :) [11:44] did 2.36.2 *just* hit stable? [11:45] popey, yes [11:46] ok, I was confused. just updated and looked at wikipedia which said it was released last week [11:48] mvo: ah, FYI we learned that the fixes don't work on fedora [11:48] mvo: mborzecki has the details [11:48] 12:48, 29 November 2018‎ Herakleitoszefesu (talk | contribs)‎ m . . (6,865 bytes) +316‎ . . (Version 2.36.2; infobox formatting improvement) (undo | thank) Tag: 2017 wikitext editor [11:49] popey, I updated the release 2.36.1, then on 11/29 there was another update [11:49] \o/ I love me some fresh updates [11:50] popey, I don't know who did it [11:50] I usually do, glad someone else is :) [11:50] zyga: uh, that is sad [11:50] mborzecki: can you fill me in with the details what is missing on fedora? [11:51] mvo: fedora has cache in /usr/share/something [11:51] but I'll let you draw your own conclusions [11:51] mvo: aah yes, fedora has fc cache in different location, /usr/lib/fontconfig/cache iirc [11:51] mborzecki: woah, that is a strange location for a cache. very unfortunate as well :( [11:51] mvo: heh :P [11:52] mvo: note that the impact on strict and classic snaps is different [11:52] and some classic snaps also differ in impact [11:53] depending on how they are made [11:53] mvo: yeah, it's unfortunate, afaik it's only fedora (and rhel probably), arch uses /var/cache, zyga can tell something aboue opensuse, but iirc it's /var/cache too [11:53] tnere [11:54] there's no /usr/lib/fontconfig on opensuse for sure [11:57] pstolowski: replied to your questions on opensuse PR [11:57] thx [12:00] pstolowski: with the binary options we can also estimate the number of configurations that we need to support [12:00] zyga, mborzecki: I wonder what we can do, could we play tricks in snap-confine ? i guess that won't help with clasic confned snaps [12:00] mvo: my opinion is as follows: [12:00] zyga, mborzecki or will a relocatable format v7+uuid help? [12:00] mvo: the issue affects graphical snaps made on top of fedora29 base, our fc cache work doesn't help there [12:00] mvo: strict snaps based on core and core18 are not affected [12:01] zyga: aha, good point [12:01] mvo: but our extra cache may be seen as undesired, we could look at hiding it [12:01] mvo: the issue also affects some classic snaps [12:01] mvo: classic snaps that link with host fontconfig will not be affected by negative performance as cache will be populated by the host mechanism, they will also use the right cache, wherever that might may be [12:02] mvo: we MAY consider a system where where the native package with snapd has the equivalent of your cache mechanism [12:02] that always links to the native libraries [12:02] for the purpose of triggering that cache refresh [12:02] mvo: classic snaps that link to core snap will remain affected [12:02] mvo: but they will benefit from your mechanism [12:02] mvo: to make sure we fully improve the situation I would do the following: [12:03] (some of which are probably optional) [12:03] mvo: 1) we should run different cache mechanism for classic snaps and different for strict snaps [12:03] mvo: 2) for classic snaps we should run the host provided cache and the snapd provided cache [12:03] mvo: 3) the snapd provided cache *should* move to the base snap instead [12:04] mvo: and we should run the one matching the base snap of the classic snap being operated on [12:04] mvo: this would fix all the issues [12:04] mvo: let me know what you think [12:04] zyga: yeah, that sounds sensible [12:04] zyga: sgtm [12:04] I especially think 3 is important [12:04] since it means we can deprecate old cache and grow new ones [12:05] and solve the hypothetical f29 based apps in the same go [12:05] I would say that we may make it generic enough that snapd doesn't know it's fonts [12:05] maybe /meta/hooks/snap-installed [12:05] and then that does whatever is needed [12:05] it would be special because base snap hooks may run unconfined [12:05] but base snaps are privileged already [12:06] so I think this is reasonable, it is the same mechanism you implemented but associated with the correct entity [12:25] PR snapd#6280 opened: cmd/snap: make 'snap warnings' output yamlish [12:41] zyga, I felt like garbage all weekend (and Simon Peter did not help...) but I did manage to look over your yak-shaving PR [12:43] and? [12:46] hmm [12:46] prepare error on opensuse https://www.irccloud.com/pastebin/crnFHL37/ [12:47] some SNAFU [12:54] PR core18#94 closed: hooks: add cloud-init [13:10] ehh import cycles [13:10] refactoring selinux package, got a cycle snap -> dirs -> release -> selinux -> osutil -> dirs [13:11] off to pick up the kids [13:49] zyga, I left feedback [13:49] thanks, I will chec [13:49] check* [13:49] zyga, also, wtf is up with the opensuse golang compiler? [13:49] no idea [13:49] isn't -std a normal flag? [13:49] not broken on opensuse [13:50] er [13:50] on tumbleweed [13:50] at least since I updated this morning [14:17] PR snapcraft#2419 closed: project: state file path change [14:25] hi, I'm having an issue with multipass on xenial: https://paste.ubuntu.com/p/7HrZTvBh3k/ [14:25] it mentions incompatible openssl version [14:29] ackk: I pinged someone who can help you with that [14:29] mvo: we need to discuss the `.snapcraft` thing. Can you add the reasons for needing it to https://bugs.launchpad.net/snapcraft/+bug/1805219 ? [14:29] Bug #1805219: .snapcraft <19.04> <19.04-external> [14:30] mvo: I think I want to go with `snapcraft.yaml` at the root of the project and allowing a `.snapcraft` as the root for assets likes hooks, gui and such [14:40] sergiusens, thanks [14:49] ackk: hey, while our snap is confined "classic" we might stumble upon such problems, but we're moving towards strict confinement very soon so those should go away [14:50] Saviq, does multipass currently only work on bionic? [14:50] (this is a xenial host) [14:50] ackk: in any case, it should work on xenial, can you please file an issue here https://github.com/CanonicalLtd/multipass/issues/new and we'll try and fix asap [14:53] Saviq, https://github.com/CanonicalLtd/multipass/issues/518 [14:53] ackk: thank you! [14:53] Saviq, np [15:04] sergiusens: in a meeting, I opened the bug and have a look [15:04] Hi alan_g , short question concerning mir-Kiosk: I‘m running the chromium-mir-Kiosk snap on mir-Kiosk. After mir-Kiosk gets refreshed, the browser snap does not get restarted automatically. This leaves my device (meant to be always-on) with a black screen until I manually restart the chromium snap. Is this a problem specific to the chromium snap (Xwayland) or in general? And can I do something abo [15:04] ut it? Thanks! [15:09] * zyga -> quick context switch for taxes and dinner [15:19] Saviq, does multipass currently pick proxy options from the hosts' /etc/environment ? [15:20] Saviq, from the log I see it can't access cdimage.ubuntu.com, and this host has a proxy set [15:23] ackk: it's a systemd service, so no, it doesn't see that environment, you have to `snap set multipass proxy.http …` and similarly for https [15:23] Saviq, ah I see, thanks [15:23] dot-tobias, I'd imagine that's a problem with the chromium-mir-kiosk example. You do realise that's an example to work from, not a stable, supported snap? [15:25] Saviq, ah, so setting the proxy the daemon runs, but those opensssl errors are stil three [15:26] ackk: yeah it won't be able to access any https resources most likely [15:27] Saviq, fwiw I have the same errors on my cosmic machine [15:27] alan_g : Yes, I read that in the Ubuntu forums. Sorry to keep pestering you about that, it’s just I do not have a lot of understanding about the graphics stack and thus not the faintest idea where to start improving / integrating this into my snap … and regarding my question today, wanted to make sure it’s not a known issue with mir-Kiosk before I start sinking hours into debugging the chromium sn [15:27] ap 😊 again, sorry to keep bothering you. [15:27] Saviq, multipass seems to be working though [15:32] ackk: as long as it (multipass itself) doesn't need to access any https resources, it should work indeed [16:05] PR snapd#6281 opened: interfaces/builtin: add Multipass interfaces [16:28] * Chipaca loves that unplugging the headset now disables the trackpad [16:28] * Chipaca does not actually love it [16:28] * Chipaca needs to reboot [16:30] mvo, hey, is it any way to set the StartLimitInterval for a snap service? [16:30] Hello, I installed slack and ran it as root by mistake, how do I purge the configuration files? === jdstrand_ is now known as jdstrand [16:39] okamis: /root/snap/slack should be everything it saved [16:40] or, if ran through sudo, it might be /home/your_user/snap/slack - sudo doesn't change $HOME normally [16:41] mborzecki, do you kbiw if it is any way to set the StartLimitInterval for a snap service? [16:51] cachio: not according to https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335 [16:52] cachio: I think not :/ [16:52] cachio: afaik there's no way currently [16:52] mvo, ok, so I need to make it manually [16:53] mvo, i SEE https://paste.ubuntu.com/p/NdFRpYHHzP/ [16:53] on boards [16:54] at least on pi3 [16:54] cachio: what does journalctl -u test-snapd-daemon-notify.notify say? [16:54] cachio: the service shouldn't fail, provided the interface is connected at this stage [16:55] mvo, I am executing it again [16:56] mborzecki, not sure if when it fails the interface is connected [16:56] because part of this test is with the interface diconnected [16:56] PR snapcraft#2422 closed: clean: user friendly message when cleaning [16:57] cachio: yup, there should be an echo before, or maybe extend debug to show snap interfaces? [16:57] when the test fails the interface is disconnected [16:58] I already check that [16:58] mborzecki, could that be affecting? [16:59] joc: hey, what does this mean? https://www.irccloud.com/pastebin/Nh31ajqw/ [17:01] cachio: maybe, do you have a log from spread? [17:02] I have a debug session here [17:02] mborzecki, I just created it [17:02] mborzecki, what info could help? [17:03] mborzecki, this is the spread log [17:03] https://paste.ubuntu.com/p/dq7JgX7RmF/ [17:05] mvo, external:ubuntu-core-16-arm-32 .../tests/main/interfaces-daemon-notify# journalctl -u test-snapd-daemon-notify.notify [17:05] -- No entries -- [17:06] mvo, this could help [17:06] https://paste.ubuntu.com/p/CcmqqPsx34/ [17:06] mvo, this shows the start-limit-hit [17:11] cachio: if a test is breaking a service and such, and it doesn't do reset-failed, it'll sometimes not start [17:11] not sure if that's what you're seeing though [17:11] cachio: but that's what i had to do with the nfs-support test === pstolowski is now known as pstolowski|afk [17:12] Chipaca, the test is disconnecting the interface and trying to start the service [17:12] and checking the log contains denials [17:12] but those denials don't appear so the test fail [17:13] Chipaca, and the problem is that we are hitting the start limit [17:13] cachio: right [17:13] and it is just happenning on core for arm [17:14] Chipaca, what do you mean with "breaking a service"? [17:14] cachio: what's stopping the service, in this case? [17:16] cachio: about that fedora 29 bug, i think we'll have to remote the kernels manually [17:17] mborzecki, ok [17:17] I'll do that [17:18] cachio: something like this: `dnf autoremove -y $(rpm -qa kernel-core | sort -r | tail -1)` [17:18] Chipaca, the test stops the service [17:19] disconect -> stop -> loop with start [17:19] we check that snap logs contains denials [17:19] cachio: but [17:20] cachio: it seems the service is exiting with error after getting the permission denied [17:20] ah [17:20] cachio: the snap is buggy [17:21] cachio: the daemon says it's "simple", but it's not a daemon at all [17:22] Chipaca, this is the snap.yaml https://paste.ubuntu.com/p/NxtnkdYVjy/ [17:22] yes i'm looking at it here [17:22] Chipaca, why it is not a daemon? [17:22] it says "daemon: simple" [17:22] cachio: because it just runs a command and exits? [17:22] Chipaca, ahh, ok [17:23] cachio: and [17:23] cachio: a shell script exits with the exit status of the last command it executed [17:23] cachio: which means that this thing exits with error [17:23] so systemd tries to restart it a few times, and then gives up [17:23] so the test is a race between systemd restating the thing, and spread running the test [17:25] cachio: easiest fix, probably, is to add a "true" after the systemd-notify call in the script :-), and (optionally? but probably best) set "daemon: oneshot" [17:25] Chipaca, so we should make sure we exit 0 [17:25] I'll try with oneshot [17:26] k [17:26] Chipaca, thanks [17:26] cachio: let me know how it goes [17:44] Chipaca, one shot does not work [17:44] I think I made it work [17:45] oneshot fails to start [17:45] because the interface is not connected [17:45] so it exits with status 1 [17:45] cachio: you made the script not exit with error first? [17:45]