[00:07] Bug #1774509 changed: system-user assertion should allow change-pw to be set === jamesh_ is now known as jamesh [06:19] morning [06:45] PR snapd#6140 closed: tests, fakestore: extend refresh tests with parallel installed snaps [06:45] mvo: hey [06:45] hey mborzecki [06:47] PR snapd#5897 closed: interfaces/builtin: add device-buttons interface for accessing events [06:48] PR snapd#6135 closed: packaging/arch: fix bash completions path [06:49] mvo: can you take another look at https://github.com/snapcore/snapd/pull/6133 ? [06:49] PR #6133: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 [06:55] Hey [06:55] I will be up within the hour [06:56] I pushed the essential snap confine patch for user mounts, I hope to move faster now [07:04] mborzecki: sure, will do [07:04] zyga: good morning and thank you [07:09] zyga: hey [07:11] Hi :-) [07:11] I want to fix prefix handling in packaging today [07:11] I’ll bug you about reviews [07:59] spread tests caught some errors downloading snaps [07:59] looks like cdn is slow/unresponsive === pstolowski|afk is now known as pstolowski [08:02] mornings [08:02] pstolowski: hey [08:11] PR core18#90 opened: Placeholder files [08:18] Hey Paweł! [08:22] Hello there, can you install an older version of a snap by providing the version or something of a snap? And if so, how [08:29] BlackDex: if its your own snap (or a snap shared with you) you can "snap install --revision=xyz your-snap". snapcraft list-revisions your-snap will give you the mapping of revision and version [08:29] BlackDex: snap revert --revision=.. as long as it's still on the disk [08:36] BlackDex: if the snap belongs to someone else we respect their choice to offer only published versions [08:36] BlackDex: this way developers have a more predicable support target [08:37] BlackDex: and there are fewer old releases with known bugs used [08:40] mvo: hi, thanks for answering Jamie S posts about core18 [08:42] pedronis: sure, yw [08:53] mvo: I must say I like Trello :) [08:53] is there a native app for it? [08:54] pedronis: what is the significance of the various trello labels? [08:57] oh, is trello up already/ [08:59] mhm [08:59] I got a ping from mvo [09:01] PR snapd#6141 closed: interfaces: export gpio pin in AppArmorConnectedPlug [09:04] zyga: wuut? a ping from me? [09:04] mvo: yep, Trello said you added me to the board [09:04] so I noticed :) [09:04] zyga: that was a bit of an accident but its fine [09:04] zyga: I guess it happend when I added you to one of the cards [09:04] haha, I didn't know :) [09:05] zyga: but its not a secret so its fine, we all will get access soon (samuele is organizing this :) [09:05] super [09:05] I added two cards based on stuff that's happening [09:05] and added minimal info to the one you added me to :) [09:07] PR snapd#6133 closed: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 [09:07] zyga: I added a couple of labels to one of your cards, do we have a forum topic about user namespaces? [09:07] pedronis: we have multiple separate topics about various aspects of it [09:07] but not one specific post [09:08] zyga: ideally we don't keep state in the cards, so the nice explaination you put there would be ideally in the forum and the card just links to it (right pedronis?) [09:08] do you want me to make a post in the #docs category? [09:08] mvo: yes [09:08] zyga: not immediately, but when is close to done yes [09:08] mvo: is putting PR links and small status updates ok or should all of those be elsewhere? [09:08] I mean about user namespaces [09:08] pedronis: ok, will do [09:08] zyga: PR links are fine [09:08] zyga: I think pr links, forum links etc are great [09:08] pedronis: last night I really got it moving, I was stuck on one aspect and fixed that [09:09] attachment, PR links, checklists are fine [09:09] zyga: but updates I'm hesitant because the trello is not public so we lock out people, ideally its just a tool for us to track flow and all the information we track is public [09:09] descriptions, better if there's a forum post for anything that is large, needs to be visible (which is almost all things) [09:09] ok [09:10] I think we'll figure out what the right balance is in the next few days [09:10] anyway that one is a bug, it should have a link to the bug at least [09:10] zyga: yeah, I think we will also talk about it during the standup [09:11] ok [09:11] which one is a bug? [09:11] gpio stuff [09:11] ah [09:11] right [09:14] mvo: thanks for merging master into TW branch [09:14] we should see if this passes now [09:15] PR snapd#6138 closed: overlord/ifacestate: use remapper when checking if system snap is installed [09:21] zyga: I added a skeleton checklist to your card [09:22] feel free to tweak [09:23] looking [09:23] Thanks! [09:23] nice idea === chihchun_afk is now known as chihchun [09:37] PR snapd#6146 opened: ifacestate/helpers: added SystemSnapName mapper helper method === chihchun is now known as chihchun_afk [09:40] pstolowski: I seems we really need a helper for CurrentInfo(systemSnapName), I see you need it also for hotplug-disconnect [09:41] let me check and refresh my memory [09:42] pstolowski: I made a comment in the PR itself [09:42] clearer context [09:42] pedronis: oh yes, right, i can see that, thanks [09:42] will do === chihchun_afk is now known as chihchun [10:01] re [10:03] mi [10:11] https://paste.ubuntu.com/p/h3xskwxJfg/ how does that look? [10:11] mborzecki: ? [10:12] pedronis: check the pastebin [10:12] mborzecki: ? [10:13] pedronis: revision publish date/time for each channel [10:13] we don't have the data [10:13] afaik [10:13] am I confused [10:13] given two ?s in a row, I'd say you were :) [10:13] pedronis: hm isn't created-at the date when given revision was created? [10:14] mborzecki: yes, that's not the info that is asked [10:14] the info is asked is when it was released into the channel [10:14] we might actual want both [10:14] mborzecki: that task need store work first [10:14] mborzecki: are you without a next task? [10:15] pedronis: yeah, looking around currently, thinking about going back to centos to look into umount issues we saw, any suggestions are welcome [10:15] mborzecki: yes, CentOS is a good next task at this point [10:18] mborzecki: if you are interessted in the umount I tried to reproduce it (in vain) with plain mount in http://paste.ubuntu.com/p/3yfgGjqXGY/ [10:36] added SystemSnapInfo helper to #6146 [10:37] pedronis: ^ [10:37] PR #6146: ifacestate/helpers: added SystemSnapName mapper helper method [10:38] pstolowski: do we have already code to deal with when a hotplug device shows up the first time? [10:38] I see PR for remove and update [10:39] or is that in the big PR marked as blocked atm [10:40] pedronis: yes, it's in the big PR only, i haven't extracted it as it would need to be stacked on top of existing PRs [10:42] pstolowski: ok, does it do auto-connections as well? that was mentioned in the initial plan if I recall correctly [10:46] pedronis: yes, although there are two issues, one of which we discussed earlier (there needs to be exactly 1 candidate slot for autoconnect, but with first hotplug interfaces you will always have 2), second which i mentioned yesterday on standup (you probably missed that since you joined late) - if you have no snaps at all and core is installed automatically for you as a prerequisite, hotplug will not kick in at all [10:46] initially as udevmonitor init waits for system snap and will become active after a while [10:48] pstolowski: I don't understand the first one, why 2 slots ? [10:51] pedronis: because the first hotplug interfaces simply extend existing interfaces - look a the camera PR for example. you still have the "old" camera interface, and hotplug slots of "camera" interface appearing as well. so when you plug a camera you get generic camera interface and a hotplug slot for this specific camera. [10:53] pedronis: to solve this we should probably/maybe make candidate slots helper smarter and favor hotplug version of an interface? [10:54] pedronis: makes sense? [10:55] PR snapd#6147 opened: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces [10:58] mvo, hey, 2.36.1 in candidate channel [10:59] cachio: excellent news! [10:59] cachio: lets aim for release Monday or Tuesday [10:59] cachio: thank you! [10:59] mvo, yes, I hope that [10:59] yaw [11:06] pstolowski: is this specific to camera? something sounds wrong? is this because there is a generic camera device (that might or might not work) [11:06] PR snapd#6148 opened: cmd/snap-confine: remove unneeded unshare [11:08] pstolowski: anyway, something to think about/discuss [11:08] PR snapd#6149 opened: cmd/snap-confine: capture initialized per-user mount ns [11:09] pstolowski: the issue it that conceptuall camera is an interface to all cameras, so having two slots of it doesn't make sense [11:09] PR snapd#6150 opened: cmd/snap-discard-ns: add support for --from-snap-confine [11:09] we need to think [11:09] pedronis: it's a decision i think, i made camera hotplug for the existing interface instead of creating a new separate interface type (e.g "hotplug-camera") [11:10] I'm creating a bunch of PRs, I'll garden them, some of those have dependencies but I'll try to get that under control [11:10] pstolowski: as, I said that plan sounds conceptually wrong [11:10] given the nature of camera at the moment [11:10] camera is all cameras, not one camera [11:10] there's even a comment about this in it [11:10] we need to see how to sort that out [11:11] without breaking things [11:12] pstolowski: there is this comment: # Until we have proper device assignment, allow access to all cameras [11:12] pedronis: one idea is as follows [11:12] pedronis: keep the interface name as is [11:12] pedronis: change the implicit slot on core to be called "all-cameras" [11:12] pedronis: no, the hotplug variant of this interface gives access exactly to *one* camera [11:12] pstolowski: yes, you did that [11:12] pedronis: hotplug interfaces will be named "camera-$foo" and will hold an attribute to specific camera [11:12] but it doesn't fit completely [11:13] pedronis: teach auto-connect logic to prefer the all-cameras one unless a snap is marked as wanting the new behaviour via a plug attribute [11:13] pedronis: the old logic is great for many snaps [11:14] pedronis: but yes, the descriptions of interfaces are misleading and i was explaining this ~two weeks ago on a standup on an example of serial port ("allows access to all serial ports") [11:15] zyga: we probably cannot change the core slot name either [11:15] somebody is probably connecting to it in some script [11:15] but yes we need to decide what to do to make new interfaces support hotplug without breaking compatiblity [11:16] we might need to keep old interfaces for a while [11:16] pstolowski: alternatively we do a flag day switch (camera is specific to camera) but teach auto-connect to connect *all* of them [11:17] pstolowski: so "cheese" will now connect to all cameras automatically [11:17] but the purpose of the camera interface is simple and specific [11:17] this feels cleaner IMO [11:17] but will have more complex "I want to revert snapd" semantics [11:17] flag day, complex revert snaps, all those things don't sounds appealing to me [11:18] it seems we have a complex problem on our hands, probably not something to discuss in irc right now [11:18] we have ideas [11:18] +1 [11:18] +2 [11:21] funny situation with snapd in epel, it's there but it's not installable on centos because we're still waiting for 7.6 selinux-policy to be available in centos [11:30] pstolowski: it would be good to have a forum post that describes the problem, with a least of potential hardware interfaces that are affected, at least serial-port and i2c says thy all to access "a specific" device, camera and dvs says all [11:30] s/least/list/ [11:33] pedronis: right, will do [11:46] * zyga goes to fix quirks PR [11:46] please don't restart any user mount PRs [11:58] zyga: pony icon? :) [11:59] mborzecki: *mount* point [11:59] hahah [12:04] :D [12:04] * pstolowski school run + lunch [12:24] PR snapd#6151 opened: snapd: allow snap-update-ns to read /proc/version [12:28] mborzecki: offtopic [12:28] mborzecki: with connections API [12:28] mborzecki: I'd like to have a debug command like [12:28] snap debug is-connected [12:28] snap debug is-autoconnected [12:28] etc [12:28] for tests mainly [12:29] so that we can get away from the grepping snap interfaces [12:29] mhm [12:29] mborzecki: what do you think? [12:29] zyga: and the output yes/no? or just exit code? [12:29] exit code [12:29] PR snapd#6152 opened: spdx: update licenses to current data [12:29] could be more with --verbose or something like that [12:29] if snap is-connected core:network; etc === chihchun is now known as chihchun_afk [12:48] mvo, do we have an example to update the snap revision? [12:48] to avoid it is refreshed? [12:48] pstolowski: mborzecki: do you remember what was the last set of decisions we made about re(starting) services from hooks? I think we decided to make it synchronous by default? [12:53] pedronis: no, i don't recall, but iirc we're calling systemctl restart which waits [12:53] mborzecki: yes, but we postpone the tasks after the hook [12:53] there was some back and forth on that [12:54] and user confusion [12:54] heh, i can imagine [12:54] pedronis: so what you're saying, say install hook does restart (?), the task is injected and all other tasks automatically get WaitFor() ? [12:55] yes, we do something like that [12:55] but I vaguely remember discussions that is was confusing/was breaking some expectations [12:55] so should not be the default [13:01] seems we didn't write down this, it will need to surface again on its own [13:03] red test day :/ [13:05] mvo, pstolowski and zyga thx for the info! :) [13:09] zyga, we have new opensuse image [13:09] cachio: which one? [13:09] zyga, lets see if it fixes the errors [13:09] zyga, 43.2 [13:09] 42.3? [13:09] I updated it after the PRs with the fixes were merged [13:09] there are no errors on 42.3 (well, non that fail tests that aren't disabled) [13:09] but let's see yeah [13:10] thanks! [13:10] is it published and live? [13:10] or do we need to opt into it? [13:10] I retrigerred some of the PRs and builds which have failed [13:11] you just need to rebuild if it errored [13:11] zyga, well, if the build took 50 minutes and it was errored because of that [13:12] ok [13:12] zyga: cachio: saw some issues with snap downloads in the morning [13:12] aha [13:13] mborzecki, yes, I saw some 503 [13:13] mborzecki, did you see the same ? [13:14] cachio: there were errors pointing to fastly, sorry didn't grab them at the time [13:17] mborzecki, I also saw some errors downloading dependencies [13:17] on xenial [13:17] perhaps there are some network problems on gce [13:17] mborzecki, I am following this [13:20] mborzecki: is this expected behavior, I suppose it is, but confusing: https://bugs.launchpad.net/snapd/+bug/1803212 ? [13:20] Bug #1803212: snap restart starts disabled services [13:21] pedronis: I would say that is unexpected behavior (as the bug author :-) ) [13:22] pedronis: hm systemd allows you to do that too, imo it's probably a slight discrepancy between what users think enable/disable means and systemd's opinion [13:23] ijohnson: maybe if you do snap restart we should not restart serices that are disabled [13:23] yeah to me, if a service in a snap is disabled, it shouldn't ever be started unless by `snap start SNAP_NAME.svc` [13:23] ijohnson: but if you do snap restart . we should restart it as requested [13:23] yes [13:23] yup [13:23] pedronis: what do you think? [13:24] I don't know [13:24] if need to step back a bit [13:24] s/if/we/ [13:24] it feels we didn't finess the design of all of this enough [13:24] the first time around [13:25] mborzecki: we need to reach a consistent picture [13:25] even if we deem some behaviors bugs vs features or things we need to continue doing [13:28] I bought two uSD cards to replace those that failed during weekend device fixup [13:29] I'll send my test results in case anyone wants to buy similar cards [13:36] mborzecki: basically it's very easy to document that snap

touches all services [13:36] otoh it might not be what ones wants [13:36] it also means enabled for services vs snaps have different nuances [13:38] pedronis: speaking for the snap that I posted in the bug report (edgexfoundry) our snap has 16 services (soon to be 20) and if `snap restart` doesn't respect enable/disable then the feature will be effectively useless for us and to issue a restart of all services would be a giant pain because of the dependencies between the services [13:38] pedronis: yeah, we're exposing systemd behavior this way [13:39] ijohnson: what do you expect snap stop to do? [13:40] anyway I'm writing something in the bug, I haven't made my mind up either way [13:40] hmm going point not sure [13:41] ijohnson: I asked a couple of questions in the bug, please do write there what you expect if you have some time to think about it [13:42] thanks I'll look at it now [13:42] pstolowski: https://github.com/snapcore/snapd/pull/6097#pullrequestreview-174864176 [13:42] PR #6097: interfaces/tests: MockHotplugSlot test helper [13:42] pedronis: i think there was also a quirk regarding restart related to refresh more, where we basically discourage from doing `systemctl restart snap...` [13:42] s/more/mode/ [13:42] PR snapd#6153 opened: tests: use mock-gpio.py in enable-disable-units-gpio test [13:43] zyga: thanks, looking [13:46] * zyga pstolowski: in https://github.com/snapcore/snapd/pull/6071/files is the interface argument to updateDevice the actual interface name (not plug or slot name) [13:46] PR #6071: ifacestate/hotplug: updateDevice helper [13:48] zyga: yes, it's the interface name [13:49] thanks! [13:49] cachio: i'm seeing no space left on device on amazon, something you were looking into earlier? [13:50] mborzecki, yes, do you have any logs? [13:50] mborzecki, it is really sporadic [13:50] cachio: https://travis-ci.org/snapcore/snapd/jobs/454850118 [13:53] mborzecki, thanks [13:54] pedronis: replied [13:55] mborzecki, same error I saw last week [13:55] mborzecki: apparently I misread that user on the forum, did your PR changing how services are started on install not also change how services are handled on `snap restart`? Regardless of whether disabled services should be started with `snap restart`, they should be started in topological sort order like on install [13:56] mborzecki, I also see many errors on xenial 32 trying to install dependencies [13:56] seems to be a network issue [13:57] at least the opensuse issue seems to be fixed [14:02] mborzecki, standup? === chihchun_afk is now known as chihchun === chrisccoulson_ is now known as chrisccoulson [15:06] off to school to the parents meeting [15:07] zyga: added some tweaks for centos to call snap-discard-ns in snap-mgmt --purge, so far looking quite good [15:08] mborzecki: purge may run only when snapd is installed, right? [15:09] zyga: yes, that's how we do it on fedora, opensuse & arch [15:09] good, sounds great [15:09] lets do that instead of manual unmount [15:09] zyga: there's still a case when we try to remove a snap that is using layouts or similar (eg. parallel installs) [15:09] something to discuss tomorrow probably [15:10] ok [15:12] popey: let me know if I missed something from my call-for-testing topic [15:12] hm? [15:12] screenshots :D [15:13] also, i see broken unicode [15:13] popey: where? [15:13] https://usercontent.irccloud-cdn.com/file/srgcfcQf/Screenshot%20from%202018-11-14%2015-13-14.png [15:13] works in a terminal, not in firefox (snap) [15:14] * Chipaca wonders if he has any unicode nickels to give [15:14] popey: does that improve? [15:14] hi o/, latest Yaru snap builds on Travis are broken with this error https://travis-ci.org/ubuntu/yaru/builds/454222505, which seems related to version-script. Looking at snapcraft forum, my understanding is that this is somehow deprecated, is there something I need to update on Yaru yaml? [15:14] your output needs to work on https://www.youtube.com/watch?v=9Qct8HWnXmY :) [15:14] Chipaca: fixed first one, other three still broken [15:15] good [15:15] i'll change the rest then [15:15] good now [15:15] also wtf why doesn't your browser know how to display a 🗸 [15:15] thanks [15:15] even your terminal does [15:15] nor does irccloud [15:16] remind me, is that something that runs in a browser? [15:16] electron so kinda [15:16] it's BMP unicode [15:16] it should not not work [15:16] no excuses at this point [15:16] mborzecki, about this no space error [15:16] anyhow [15:16] popey: thanks [15:16] mborzecki, the vm has free space [15:17] mborzecki, it is like this mount point has not any space [15:17] mborzecki, I'll leave a loop trying to reproduce it [15:18] main.go:123: system does not fully support snapd: write /tmp/sanity-squashfs-702762208: no space left on device === chihchun is now known as chihchun_afk [15:26] * cachio lunch [16:05] tests absolutely suck today [16:05] mvo: so about that bug fix [16:06] mvo: everything is yellow [16:06] unless you disagree I'd like to spend a moment on other tasks [16:08] zyga: sure [16:08] ok [16:08] zyga: the gpio fix you mean? iirc there is nothing pending from you anyway, no? we just need tests to go green [16:09] yes [16:19] mvo: I reviewed #6128 [16:19] PR #6128: overlord/ifacestate: setup security backends phased by backends first