[00:07] <mup> Bug #1774509 changed: system-user assertion should allow change-pw to be set <Snappy:Fix Released> <https://launchpad.net/bugs/1774509>
[06:19] <mborzecki> morning
[06:45] <mup> PR snapd#6140 closed: tests, fakestore: extend refresh tests with parallel installed snaps <Parallel installs ⛓> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6140>
[06:45] <mborzecki> mvo: hey
[06:45] <mvo> hey mborzecki
[06:47] <mup> PR snapd#5897 closed: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5897>
[06:48] <mup> PR snapd#6135 closed: packaging/arch: fix bash completions path <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6135>
[06:49] <mborzecki> mvo: can you take another look at https://github.com/snapcore/snapd/pull/6133 ?
[06:49] <mup> PR #6133: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6133>
[06:55] <zyga> Hey
[06:55] <zyga> I will be up within the hour
[06:56] <zyga> I pushed the essential snap confine patch for user mounts, I hope to move faster now
[07:04] <mvo> mborzecki: sure, will do
[07:04] <mvo> zyga: good morning and thank you
[07:09] <mborzecki> zyga: hey
[07:11] <zyga> Hi :-)
[07:11] <zyga> I want to fix prefix handling in packaging today
[07:11] <zyga> I’ll bug you about reviews
[07:59] <mborzecki> spread tests caught some errors downloading snaps
[07:59] <mborzecki> looks like cdn is slow/unresponsive
[08:02] <pstolowski> mornings
[08:02] <mborzecki> pstolowski: hey
[08:11] <mup> PR core18#90 opened: Placeholder files <Created by mvo5> <https://github.com/snapcore/core18/pull/90>
[08:18] <zyga> Hey Paweł!
[08:22] <BlackDex> 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] <mvo> 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] <pstolowski> BlackDex: snap revert --revision=.. as long as it's still on the disk
[08:36] <zyga> BlackDex: if the snap belongs to someone else we respect their choice to offer only published versions
[08:36] <zyga> BlackDex: this way developers have a more predicable support target
[08:37] <zyga> BlackDex: and there are fewer old releases with known bugs used
[08:40] <pedronis> mvo: hi, thanks for answering Jamie S posts about core18
[08:42] <mvo> pedronis: sure, yw
[08:53] <zyga> mvo: I must say I like Trello :)
[08:53] <zyga> is there a native app for it?
[08:54] <zyga> pedronis: what is the significance of the various trello labels?
[08:57] <mborzecki> oh, is trello up already/
[08:59] <zyga> mhm
[08:59] <zyga> I got a ping from mvo
[09:01] <mup> PR snapd#6141 closed: interfaces: export gpio pin in AppArmorConnectedPlug <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6141>
[09:04] <mvo> zyga: wuut? a ping from me?
[09:04] <zyga> mvo: yep, Trello said you added me to the board
[09:04] <zyga> so I noticed :)
[09:04] <mvo> zyga: that was a bit of an accident but its fine
[09:04] <mvo> zyga: I guess it happend when I added you to one of the cards
[09:04] <zyga> haha, I didn't know :)
[09:05] <mvo> zyga: but its not a secret so its fine, we all will get access soon (samuele is organizing this :)
[09:05] <zyga> super
[09:05] <zyga> I added two cards based on stuff that's happening
[09:05] <zyga> and added minimal info to the one you added me to :)
[09:07] <mup> PR snapd#6133 closed: tests: fix how pinentry is prepared for new gpg v 2.1 and 2.2 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6133>
[09:07] <pedronis> zyga: I added a couple of labels to one of your cards,  do we have a forum topic about user namespaces?
[09:07] <zyga> pedronis: we have multiple separate topics about various aspects of it
[09:07] <zyga> but not one specific post
[09:08] <mvo> 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] <zyga> do you want me to make a post in the #docs category?
[09:08] <pedronis> mvo: yes
[09:08] <pedronis> zyga: not immediately, but when is close to done yes
[09:08] <zyga> mvo: is putting PR links and small status updates ok or should all of those be elsewhere?
[09:08] <pedronis> I mean about user namespaces
[09:08] <zyga> pedronis: ok, will do
[09:08] <pedronis> zyga: PR links are fine
[09:08] <mvo> zyga: I think pr links, forum links etc are great
[09:08] <zyga> pedronis: last night I really got it moving, I was stuck on one aspect and fixed that
[09:09] <pedronis> attachment, PR links, checklists are fine
[09:09] <mvo> 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] <pedronis> descriptions, better if there's a forum post for anything that is large, needs to be visible (which is almost all things)
[09:09] <zyga> ok
[09:10] <zyga> I think we'll figure out what the right balance is in the next few days
[09:10] <pedronis> anyway that one is a bug, it should have a link to the bug at least
[09:10] <mvo> zyga: yeah, I think we will also talk about it during the standup
[09:11] <zyga> ok
[09:11] <zyga> which one is a bug?
[09:11] <pedronis> gpio stuff
[09:11] <zyga> ah
[09:11] <zyga> right
[09:14] <zyga> mvo: thanks for merging master into TW branch
[09:14] <zyga> we should see if this passes now
[09:15] <mup> PR snapd#6138 closed: overlord/ifacestate: use remapper when checking if system snap is installed <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6138>
[09:21] <pedronis> zyga: I added a skeleton checklist to your card
[09:22] <pedronis> feel free to tweak
[09:23] <zyga> looking
[09:23] <zyga> Thanks!
[09:23] <zyga> nice idea
[09:37] <mup> PR snapd#6146 opened: ifacestate/helpers: added SystemSnapName mapper helper method <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6146>
[09:40] <pedronis> pstolowski: I seems we really need a helper for  CurrentInfo(systemSnapName), I see you need it also for hotplug-disconnect
[09:41] <pstolowski> let me check and refresh my memory
[09:42] <pedronis> pstolowski: I made a comment in the PR itself
[09:42] <pedronis> clearer context
[09:42] <pstolowski> pedronis: oh yes, right, i can see that, thanks
[09:42] <pstolowski> will do
[10:01] <zyga> re
[10:03] <sparkiegeek> mi
[10:11] <mborzecki> https://paste.ubuntu.com/p/h3xskwxJfg/ how does that look?
[10:11] <pedronis> mborzecki: ?
[10:12] <mborzecki> pedronis: check the pastebin
[10:12] <pedronis> mborzecki: ?
[10:13] <mborzecki> pedronis: revision publish date/time for each channel
[10:13] <pedronis> we don't have the data
[10:13] <pedronis> afaik
[10:13] <pedronis> am I confused
[10:13] <sparkiegeek> given two ?s in a row, I'd say you were :)
[10:13] <mborzecki> pedronis: hm isn't created-at the date when given revision was created?
[10:14] <pedronis> mborzecki: yes, that's not the info that is asked
[10:14] <pedronis> the info is asked is when it was released into the channel
[10:14] <pedronis> we might actual want both
[10:14] <pedronis> mborzecki: that task need store work first
[10:14] <pedronis> mborzecki: are you without a next task?
[10:15] <mborzecki> pedronis: yeah, looking around currently, thinking about going back to centos to look into umount issues we saw, any suggestions are welcome
[10:15] <pedronis> mborzecki: yes, CentOS is a good next task at this point
[10:18] <mvo> 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] <pstolowski> added SystemSnapInfo helper to #6146
[10:37] <pstolowski> pedronis: ^
[10:37] <mup> PR #6146: ifacestate/helpers: added SystemSnapName mapper helper method <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6146>
[10:38] <pedronis> pstolowski: do we have already code to deal with when a hotplug device shows up the first time?
[10:38] <pedronis> I see PR for remove and update
[10:39] <pedronis> or is that in the big PR marked as blocked atm
[10:40] <pstolowski> 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] <pedronis> pstolowski: ok, does it do auto-connections as well? that was mentioned in the initial plan if I recall correctly
[10:46] <pstolowski> 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] <pstolowski> initially as udevmonitor init waits for system snap and will become active after a while
[10:48] <pedronis> pstolowski: I don't understand the first one, why 2 slots ?
[10:51] <pstolowski> 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] <pstolowski> pedronis: to solve this we should probably/maybe make candidate slots helper smarter and favor hotplug version of an interface?
[10:54] <pstolowski> pedronis: makes sense?
[10:55] <mup> PR snapd#6147 opened: cmd/snap-confine: use snap-discard-ns ns to discard stale namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6147>
[10:58] <cachio> mvo, hey, 2.36.1 in candidate channel
[10:59] <mvo> cachio: excellent news!
[10:59] <mvo> cachio: lets aim for release Monday or Tuesday
[10:59] <mvo> cachio: thank you!
[10:59] <cachio> mvo, yes, I hope that
[10:59] <cachio> yaw
[11:06] <pedronis> 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] <mup> PR snapd#6148 opened: cmd/snap-confine: remove unneeded unshare <Created by zyga> <https://github.com/snapcore/snapd/pull/6148>
[11:08] <pedronis> pstolowski: anyway, something to think about/discuss
[11:08] <mup> PR snapd#6149 opened: cmd/snap-confine: capture initialized per-user mount ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
[11:09] <pedronis> 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] <mup> PR snapd#6150 opened: cmd/snap-discard-ns: add support for --from-snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/6150>
[11:09] <pedronis> we need to think
[11:09] <pstolowski> 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] <zyga> 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] <pedronis> pstolowski: as, I said that plan sounds conceptually wrong
[11:10] <pedronis> given the nature of camera at the moment
[11:10] <pedronis> camera is all cameras, not one camera
[11:10] <pedronis> there's even a comment about this in it
[11:10] <pedronis> we need to see how to sort that out
[11:11] <pedronis> without breaking things
[11:12] <pedronis> pstolowski: there is this comment:  # Until we have proper device assignment, allow access to all cameras
[11:12] <zyga> pedronis: one idea is as follows
[11:12] <zyga> pedronis: keep the interface name as is
[11:12] <zyga> pedronis: change the implicit slot on core to be called "all-cameras"
[11:12] <pstolowski> pedronis: no, the hotplug variant of this interface gives access exactly to *one* camera
[11:12] <pedronis> pstolowski: yes, you did that
[11:12] <zyga> pedronis: hotplug interfaces will be named "camera-$foo" and will hold an attribute to specific camera
[11:12] <pedronis> but it doesn't fit completely
[11:13] <zyga> 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] <zyga> pedronis: the old logic is great for many snaps
[11:14] <pstolowski> 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] <pedronis> zyga: we probably cannot change the core slot name either
[11:15] <pedronis> somebody is probably connecting to it in some script
[11:15] <pstolowski> but yes we need to decide what to do to make new interfaces support hotplug without breaking compatiblity
[11:16] <pstolowski> we might need to keep old interfaces for a while
[11:16] <zyga> pstolowski: alternatively we do a flag day switch (camera is specific to camera) but teach auto-connect to connect *all* of them
[11:17] <zyga> pstolowski: so "cheese" will now connect to all cameras automatically
[11:17] <zyga> but the purpose of the camera interface is simple and specific
[11:17] <zyga> this feels cleaner IMO
[11:17] <zyga> but will have more complex "I want to revert snapd" semantics
[11:17] <pedronis> flag day, complex revert snaps, all those things don't sounds appealing to me
[11:18] <pedronis> it seems we have a complex problem on our hands, probably not something to discuss in irc right now
[11:18] <pedronis> we have ideas
[11:18] <zyga> +1
[11:18] <pstolowski> +2
[11:21] <mborzecki> 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] <pedronis> 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] <pedronis> s/least/list/
[11:33] <pstolowski> pedronis: right, will do
[11:46]  * zyga goes to fix quirks PR
[11:46] <zyga> please don't restart any user mount PRs
[11:58] <mborzecki> zyga: pony icon? :)
[11:59] <zyga> mborzecki: *mount* point
[11:59] <mborzecki> hahah
[12:04] <pstolowski> :D
[12:04]  * pstolowski school run + lunch
[12:24] <mup> PR snapd#6151 opened: snapd: allow snap-update-ns to read /proc/version <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6151>
[12:28] <zyga> mborzecki: offtopic
[12:28] <zyga> mborzecki: with connections API
[12:28] <zyga> mborzecki: I'd like to have a debug command like
[12:28] <zyga> snap debug is-connected
[12:28] <zyga> snap debug is-autoconnected
[12:28] <zyga> etc
[12:28] <zyga> for tests mainly
[12:29] <zyga> so that we can get away from the grepping snap interfaces
[12:29] <mborzecki> mhm
[12:29] <zyga> mborzecki: what do you think?
[12:29] <mborzecki> zyga: and the output yes/no? or just exit code?
[12:29] <zyga> exit code
[12:29] <mup> PR snapd#6152 opened: spdx: update licenses to current data <Created by mvo5> <https://github.com/snapcore/snapd/pull/6152>
[12:29] <zyga> could be more with --verbose or something like that
[12:29] <zyga> if snap is-connected core:network; etc
[12:48] <cachio> mvo, do we have an example to update the snap revision?
[12:48] <cachio> to avoid it is refreshed?
[12:48] <pedronis> 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] <mborzecki> pedronis: no, i don't recall, but iirc we're calling systemctl restart which waits
[12:53] <pedronis> mborzecki: yes, but we postpone the tasks after the hook
[12:53] <pedronis> there was some back and forth on that
[12:54] <pedronis> and user confusion
[12:54] <mborzecki> heh, i can imagine
[12:54] <mborzecki> pedronis: so what you're saying, say install hook does restart (?), the task is injected and all other tasks automatically get WaitFor() ?
[12:55] <pedronis> yes, we do something like that
[12:55] <pedronis> but I vaguely remember discussions that is was confusing/was breaking some expectations
[12:55] <pedronis> so should not be the default
[13:01] <pedronis> seems we didn't write down this, it will need to surface again on its own
[13:03] <zyga> red test day :/
[13:05] <BlackDex> mvo, pstolowski and zyga thx for the info! :)
[13:09] <cachio> zyga, we have new opensuse image
[13:09] <zyga> cachio: which one?
[13:09] <cachio> zyga, lets see if it fixes the errors
[13:09] <cachio> zyga, 43.2
[13:09] <zyga> 42.3?
[13:09] <cachio> I updated it after the PRs with the fixes were merged
[13:09] <zyga> there are no errors on 42.3 (well, non that fail tests that aren't disabled)
[13:09] <zyga> but let's see yeah
[13:10] <zyga> thanks!
[13:10] <zyga> is it published and live?
[13:10] <zyga> or do we need to opt into it?
[13:10] <cachio> I retrigerred some of the PRs and builds which have failed
[13:11] <cachio> you just need to rebuild if it errored
[13:11] <cachio> zyga, well, if the build took 50 minutes and it was errored because of that
[13:12] <zyga> ok
[13:12] <mborzecki> zyga: cachio: saw some issues with snap downloads in the morning
[13:12] <zyga> aha
[13:13] <cachio> mborzecki, yes, I saw some 503
[13:13] <cachio> mborzecki, did you see the same ?
[13:14] <mborzecki> cachio: there were errors pointing to fastly, sorry didn't grab them at the time
[13:17] <cachio> mborzecki, I also saw some errors downloading dependencies
[13:17] <cachio> on xenial
[13:17] <cachio> perhaps there are some network problems on gce
[13:17] <cachio> mborzecki, I am following this
[13:20] <pedronis> mborzecki: is this expected behavior, I suppose it is, but confusing:  https://bugs.launchpad.net/snapd/+bug/1803212 ?
[13:20] <mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
[13:21] <ijohnson> pedronis: I would say that is unexpected behavior (as the bug author :-) )
[13:22] <mborzecki> 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] <mborzecki> ijohnson: maybe if you do snap restart <snapname> we should not restart serices that are disabled
[13:23] <ijohnson> 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] <mborzecki> ijohnson: but if you do snap restart <snapname>.<svcname> we should restart it as requested
[13:23] <ijohnson> yes
[13:23] <mborzecki> yup
[13:23] <mborzecki> pedronis: what do you think?
[13:24] <pedronis> I don't know
[13:24] <pedronis> if need to step back a bit
[13:24] <pedronis> s/if/we/
[13:24] <pedronis> it feels we didn't finess the design of all of this enough
[13:24] <pedronis> the first time around
[13:25] <pedronis> mborzecki: we need to reach a consistent picture
[13:25] <pedronis> even if we deem some behaviors bugs vs features or things we need to continue doing
[13:28] <zyga> I bought two uSD cards to replace those that failed during weekend device fixup
[13:29] <zyga> I'll send my test results in case anyone wants to buy similar cards
[13:36] <pedronis> mborzecki: basically it's very easy to document that snap <service-command> <snap-name>  touches all services
[13:36] <pedronis> otoh it might not be what ones wants
[13:36] <pedronis> it also means enabled for services vs snaps have different nuances
[13:38] <ijohnson> 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] <mborzecki> pedronis: yeah, we're exposing systemd behavior this way
[13:39] <pedronis> ijohnson: what do you expect snap stop <snap> to do?
[13:40] <pedronis> anyway I'm writing something in the bug, I haven't made my mind up either way
[13:40] <ijohnson> hmm going point not sure
[13:41] <pedronis> 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] <ijohnson> thanks I'll look at it now
[13:42] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/6097#pullrequestreview-174864176
[13:42] <mup> PR #6097: interfaces/tests: MockHotplugSlot test helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6097>
[13:42] <mborzecki> 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] <mborzecki> s/more/mode/
[13:42] <mup> PR snapd#6153 opened: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
[13:43] <pstolowski> 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] <mup> PR #6071: ifacestate/hotplug: updateDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6071>
[13:48] <pstolowski> zyga: yes, it's the interface name
[13:49] <zyga> thanks!
[13:49] <mborzecki> cachio: i'm seeing no space left on device on amazon, something you were looking into earlier?
[13:50] <cachio> mborzecki, yes, do you have any logs?
[13:50] <cachio> mborzecki, it is really sporadic
[13:50] <mborzecki> cachio: https://travis-ci.org/snapcore/snapd/jobs/454850118
[13:53] <cachio> mborzecki, thanks
[13:54] <ijohnson> pedronis: replied
[13:55] <cachio> mborzecki, same error I saw last week
[13:55] <ijohnson> 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] <cachio> mborzecki, I also see many errors on xenial 32 trying to install dependencies
[13:56] <cachio> seems to be a network issue
[13:57] <cachio> at least the opensuse issue seems to be fixed
[14:02] <cachio> mborzecki, standup?
[15:06] <mborzecki> off to school to the parents meeting
[15:07] <mborzecki> zyga: added some tweaks for centos to call snap-discard-ns in snap-mgmt --purge, so far looking quite good
[15:08] <zyga> mborzecki: purge may run only when snapd is installed, right?
[15:09] <mborzecki> zyga: yes, that's how we do it on fedora, opensuse & arch
[15:09] <zyga> good, sounds great
[15:09] <zyga> lets do that instead of manual unmount
[15:09] <mborzecki> zyga: there's still a case when we try to remove a snap that is using layouts or similar (eg. parallel installs)
[15:09] <mborzecki> something to discuss tomorrow probably
[15:10] <zyga> ok
[15:12] <Chipaca> popey: let me know if I missed something from my call-for-testing topic
[15:12] <popey> hm?
[15:12] <popey> screenshots :D
[15:13] <popey> also, i see broken unicode
[15:13] <Chipaca> popey: where?
[15:13] <popey> https://usercontent.irccloud-cdn.com/file/srgcfcQf/Screenshot%20from%202018-11-14%2015-13-14.png
[15:13] <popey> works in a terminal, not in firefox (snap)
[15:14]  * Chipaca wonders if he has any unicode nickels to give
[15:14] <Chipaca> popey: does that improve?
[15:14] <clobrano> 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] <popey> your output needs to work on https://www.youtube.com/watch?v=9Qct8HWnXmY  :)
[15:14] <popey> Chipaca: fixed first one, other three still broken
[15:15] <Chipaca> good
[15:15] <Chipaca> i'll change the rest then
[15:15] <popey> good now
[15:15] <Chipaca> also wtf why doesn't your browser know how to display a 🗸
[15:15] <popey> thanks
[15:15] <Chipaca> even your terminal does
[15:15] <popey> nor does irccloud
[15:16] <Chipaca> remind me, is that something that runs in a browser?
[15:16] <popey> electron so kinda
[15:16] <Chipaca> it's BMP unicode
[15:16] <Chipaca> it should not not work
[15:16] <Chipaca> no excuses at this point
[15:16] <cachio> mborzecki, about this no space error
[15:16] <Chipaca> anyhow
[15:16] <Chipaca> popey: thanks
[15:16] <cachio> mborzecki, the vm has free space
[15:17] <cachio> mborzecki, it is like this mount point has not any space
[15:17] <cachio> mborzecki, I'll leave a loop trying to reproduce it
[15:18] <cachio> main.go:123: system does not fully support snapd: write /tmp/sanity-squashfs-702762208: no space left on device
[15:26]  * cachio lunch
[16:05] <zyga> tests absolutely suck today
[16:05] <zyga> mvo: so about that bug fix
[16:06] <zyga> mvo: everything is yellow
[16:06] <zyga> unless you disagree I'd like to spend a moment on other tasks
[16:08] <mvo> zyga: sure
[16:08] <zyga> ok
[16:08] <mvo> zyga: the gpio fix you mean? iirc there is nothing pending from you anyway, no? we just need tests to go green
[16:09] <zyga> yes
[16:19] <pedronis> mvo: I reviewed #6128
[16:19] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[16:23] <mvo> pedronis: thank you
[16:24] <zyga> pedronis: what do you mean by https://github.com/snapcore/snapd/pull/6128/files#r233513633
[16:24] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[16:25] <pedronis> that we can do affectedNames = append(affectedNames, snapName) before the for loop
[16:25] <zyga> oh, that's deliberate,
[16:25] <zyga> we sort the _other_ names
[16:25] <zyga> and then prepend the "principal snap"
[16:26] <zyga> so the list of snaps is otherwise ordered except for the first item
[16:26] <pedronis> ah
[16:26] <zyga> this was done to ensure that the impact in how things are setup is minimal
[16:26] <zyga> note that before we did setup on the principal snap
[16:26] <zyga> and then on the rest
[16:26] <pedronis> maybe the comment needs moving them
[16:26] <pedronis> *then
[16:26] <pedronis> given I was confused
[16:26] <zyga> sure, will do, just wanted to clarify that
[16:27] <pedronis> (otoh I might just be tired)
[16:30] <pedronis> mvo: not urgent but #6070 can merged, right?
[16:30] <mup> PR #6070: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6070>
[16:32] <mup> PR snapd#6154 opened: snap: enforce minimal snap name len of 2 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6154>
[16:32] <mvo> pedronis: yes, 6070 can be merged if you are happy with it
[16:33] <pedronis> mvo: I'm neutral on it :)
[16:34] <pedronis> mvo: anything else urgent needed from me?
[16:34] <mvo> pedronis: I think we are good for now :)
[16:34] <pedronis> ok, thx
[16:34]  * pedronis mostly eods
[16:35] <mup> PR snapd#6070 closed: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6070>
[16:36] <mup> PR snapd#6097 closed: interfaces/tests: MockHotplugSlot test helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6097>
[16:36] <zyga> mvo: the gpio fix can go to just edge
[16:36] <zyga> mvo: fire is over
[16:37] <pedronis> let's post to the bug when we a have edge build
[16:37] <pedronis> with the fix
[16:37] <zyga> +1
[16:43] <mvo> zyga: great, lets land it when its green and we can do the further bits in a followup (if it ever gets green :(
[16:43] <zyga> yep, I'm working on unit tests as a follow up
[16:43] <zyga> I just want gree
[16:43] <zyga> it's autumn on travis, everything is yellow and red ;)
[16:43] <zyga> will there be a winter pack with silver and blue colors next? :)
[16:44] <ppisati> sergiusens: when trying to run a single unit test (python3 -m unittest tests.unit.plugins.test_kernel.KernelPluginDefaulTargetsTestCase.test_default), i get this: http://paste.ubuntu.com/p/zyYthtwgkG/
[16:44] <ppisati> sergiusens: am i doing anything wrong or what?
[16:44] <ppisati> kalikiana: ^
[16:45] <sergiusens> ppisati: re-install pyyaml (the one listed in requirement.txt), but before that, install the yaml dev package
[16:46] <ppisati> sergiusens: so, i remove the pip, install yaml-dev and reinstall the pip? me tries
[16:46] <sergiusens> ppisati: yes
[16:48] <mvo> zyga: does lp #1802332 ring any bells?
[16:48] <mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:New> <https://launchpad.net/bugs/1802332>
[16:48] <zyga> checking
[16:48] <mvo> zyga: some denials in snap-update-ns
[16:49] <zyga> boy, can we please do markdown on lauchpad!
[16:49] <zyga> but back to the issue
[16:49] <ppisati> sergiusens: \o/ <- it worked!
[16:49] <sergiusens> glad it did, would of been bad if it hadn't 🙂
[16:50] <zyga> mvo: it does
[16:50] <zyga> at least it seems to
[16:50] <zyga> though 2.36.x should fix it
[16:50] <zyga> mvo: do you know if the reporter is on IRC?
[16:51] <mvo> zyga: I don't but if its fixed thats fine, ask him to refresh to candidate :)
[16:51] <zyga> mvo: no guartanee but I think this is a bug I fixed in 2.36 cycle
[16:52] <zyga> *guarantee
[16:52]  * zyga cannot spell
[16:58] <roadmr> guartanee was an awesome typo :)
[17:05] <mup> PR snapd#6144 closed: cmd: handle tumbleweed and leap in autogen.sh <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6144>
[17:05] <zyga> mvo: https://github.com/snapcore/snapd/pull/6154#pullrequestreview-174974102
[17:05] <mup> PR #6154: snap: enforce minimal snap name len of 2 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6154>
[17:06] <mvo> zyga: meh, thanks, will do
[17:06] <zyga> if you can please add // NOTE: comments cross linking them
[17:06] <zyga> I know of one in libsnap-confine-common
[17:07] <zyga> and I think there's one more in boostrap.go in snap-update-ns (sorry)
[17:07] <zyga> mvo: and triple check if snapcraft agrees
[17:10]  * mvo weeps a bit
[17:12]  * mvo is down to 64 "new" bugs in snapd not too bad
[17:16] <zyga> mvo: checking that fedora29 snap-exec bug now
[17:17] <zyga> mvo: you have N64 bugs :)
[18:19] <mborzecki> zyga: https://paste.ubuntu.com/p/b7df9M5QpK/
[18:19] <mborzecki> i'm leaving analyzing the log for tomorrow
[18:19] <zyga> ouh
[18:19] <zyga> ok
[18:20] <zyga> I'm homeworking with Iza
[18:20] <mborzecki> zyga: gl :)
[18:29] <zyga> mvo: f29 bug triaged
[18:29] <mup> PR snapcraft#2403 closed: project_loader: add git to build-packages for version: git <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2403>
[18:35] <mup> PR snapcraft#2406 opened: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>
[18:38] <zyga> jdstrand: hey, could you please look at the apparmor part of https://github.com/snapcore/snapd/pull/6123 - that's just a bunch of removals with non-controversial additions that were previously handled by a more generic wildcard: https://github.com/snapcore/snapd/pull/6123/files#diff-798ce6f0668878eda67847b4ab492745
[18:38] <mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
[19:20] <zyga> ondra: which version of avahi is best for production use?
[19:20] <zyga> they all have git-flavoured versions
[19:20] <zyga> and candidate seems recent than edge or beta
[19:45] <jdstrand> zyga: you probably saw I did that a little while ago
[19:46] <mvo> zyga: fc29?
[19:46] <mvo> zyga: what did you triage?
[21:53] <mup> PR snapcraft#2392 closed: ci: update travis.yaml to use xenial <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2392>
[22:20] <mup> PR snapcraft#2407 opened: build providers: preset the timezone <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2407>
[22:35] <mup> PR snapcraft#2408 opened: multipass: avoid stdin where possible <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2408>