[05:04] <mborzecki> morning
[05:06] <zyga> o/
[05:25] <mup> PR snapd#5178 closed: interfaces/builtin: initial version of the anbox-support interface <Complex> <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/5178>
[06:41] <mborzecki> we're at 41 PRs :(
[06:43] <mup> PR snapd#5253 closed: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
[06:55] <mborzecki> mvo: shall I land #5384 ?
[06:55] <mup> PR #5384: tests: update interfaces-timeserver-control to core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5384>
[06:58] <zyga> re
[06:58] <zyga> sorry, I was hacking late last night
[06:58] <zyga> just waking up now
[06:58] <zyga> looking now
[06:59] <zyga> merging
[07:00] <mup> PR snapd#5384 closed: tests: update interfaces-timeserver-control to core18 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5384>
[07:08] <pstolowski> mornings
[07:08] <mvo> mborzecki: yeah, if it has the needed +1 please
[07:08] <mvo> thanks zyga
[07:08] <mvo> pstolowski: good morning
[07:09] <mborzecki> pstolowski: hey
[07:12] <zyga> hey mvo
[07:12] <zyga> I fixed the layout issue you ran into
[07:12] <zyga> I will get myself into shape and send a patch
[07:18] <mvo> zyga: nice
[07:18] <mvo> zyga: what was it?
[07:27] <zyga> re
[07:27] <zyga> it was just this
[07:27] <zyga> but I want to still tweak this
[07:27] <zyga> I don't like the fact that it is allowed to fail
[07:28] <zyga> https://www.irccloud.com/pastebin/xXb1dxKK/
[07:28] <zyga> I also don't get it why it failed for you in particular
[07:37] <mvo> zyga: interessting
[07:37] <zyga> essentially, path ending in / is "bad"
[07:38] <zyga> let me try to make it okay without this hack
[07:45] <jamesh> zyga: hi.  do you have any suggestions on how to move forward with this branch? https://github.com/snapcore/snapd/pull/5271
[07:45] <mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
[07:45] <zyga> jamesh: hey!
[07:45] <zyga> jamesh: let me look please, I don't recall
[07:46] <zyga> hmm
[07:46] <zyga> it has two +1s
[07:47] <zyga> I'm a bit sleepy over late hacking but my gut feeling is that I will ask mvo or maybe mborzecki to look at it and then let's land it
[07:47] <zyga> mvo, mborzecki ^
[07:47] <mvo> zyga: sure
[07:47] <mvo> I have a look in a wee bit
[07:48] <jamesh> zyga: I think the main concerns are about behaviour on OpenSUSE, where the too-old xdg-desktop-portal and partial AppArmor support means it has the potential to reduce security
[07:48] <zyga> jamesh: on old opensuse there's no strong security
[07:48] <zyga> and on tumbleweed there's recent everything
[07:48] <zyga> I think we are fine on this front
[07:48] <zyga> jamesh: for context, I enabled apparmor on tumbleweed last week
[07:48] <zyga> but it is not enabled on any any leap release yet
[07:49] <jamesh> zyga: https://software.opensuse.org/package/xdg-desktop-portal shows too-old xdg-desktop-portal for all OpenSUSE releases
[07:49] <mup> PR snapd#5392 opened: snapstate,ifstate: wait for pending restarts before auto-connecting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5392>
[07:53] <zyga> jamesh: and we require 0.11?
[07:54] <jamesh> zyga: 0.11 is the first version with snap support, yes.
[07:54] <zyga> Mmm
[07:54] <zyga> Let me ask if 0.11 is coming to TW anytime soon
[07:55] <mborzecki> zyga: can you take another look at #5311 i've pushed some fixes hopefully it'll be green before cachio wakes up
[07:55] <mup> PR #5311: tests: start active system units on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>
[07:55] <jamesh> zyga: the issue was that on OpenSUSE, where we had file-level AppArmor confinement but no D-Bus mediation it the old versions exposed everything registered with the document portal
[07:56] <jamesh> the D-Bus APIs aren't much more or less secure in 0.10 vs 0.11 in this case.
[08:00] <zyga> mmm
[08:00] <zyga> well
[08:00] <zyga> well, at least we would have nicer UX since snaps would be detected
[08:01] <jamesh> my preferred solution would be to just add "Conflicts: xdg-desktop-portal < 0.11" to the OpenSUSE spec file
[08:02] <jamesh> so things things work when the new version rolls out, but we don't let people install insecure portals together with snapd
[08:03] <zyga> jamesh: 0.11 is not submitted to factory yet
[08:03] <zyga> jamesh: mmm
[08:03] <zyga> jamesh: but that could mean arbitrary amount of time
[08:03] <zyga> and also on leap that will be never
[08:04] <jamesh> or 15.1 maybe
[08:04] <zyga> perhaps, but I don't know the package update policy
[08:12] <zyga> jamesh: what should we do if this lands to master with this constraint (on packaging)
[08:12] <zyga> won't this block spread testing?
[08:14] <jamesh> zyga: at the moment we don't have any spread tests running against a full portal stack, so it hasn't been a problem yet
[08:14] <zyga> but won't this block the installation of the package?
[08:15] <zyga> I mean, if we put a constraint on a package that's not in the archive yet
[08:15] <zyga> all of suse spread testing will stop
[08:15] <jamesh> zyga: we never try to install the xdg-desktop-portal package in any of the tests
[08:15] <zyga> ahh
[08:15] <zyga> I see what you mean
[08:15] <zyga> although
[08:15] <zyga> if the portal package is installed by default anywhere this might be a problem
[08:16] <jamesh> https://flatpak.org/setup/openSUSE/ seems to indicate it isn't installed by default
[08:16] <zyga> ok then
[08:16] <zyga> but let's add this constraint to TW only
[08:16] <jamesh> (I can't think of a reason for xdg-desktop-portal to be installed currently if flatpak isn't)
[08:17] <mup> PR snapd#5393 opened: strutil: add PathIterator.Rewind <Created by zyga> <https://github.com/snapcore/snapd/pull/5393>
[08:18] <mup> PR snapd#5394 opened: strutil: support iteration over almost clean paths <Created by zyga> <https://github.com/snapcore/snapd/pull/5394>
[08:18] <zyga> mvo: ^ this should fix the issue you ran into
[08:19] <mup> PR snapd#5395 opened: don't review / don't land: just testing <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
[08:19] <jamesh> zyga: I imagine we could do some real xdg-desktop-portal spread tests in future, by using a fake version of the org.freedesktop.impl.portal.* D-Bus interfaces to avoid depending on a GUI
[08:22] <jamesh> zyga: fwiw, it doesn't look like there is any of xdg-desktop-portal or flatpak in SLES, so presumably they are more free to update those packages in point releases
[08:29] <zyga> jamesh: I don't know much about SLES, I tried to build snappy for SLE 12 but failed on missing build dependencies
[08:29] <zyga> I need to take the dog out now, it's almost 10:30 !
[08:30] <mvo> zyga: looking, thanks
[08:30] <jamesh> zyga: from what I can tell, OpenSUSE Leap is a combination of some packages taken directly from SLES, and some others layered on top.  My point was that it looks like xdg-desktop-portal is one of those packages not from the Enterprise distro, so easier to update
[08:30] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/5395/files#diff-485a172e36d1bd329b385818efa017b6 :)
[08:30] <mup> PR #5395: don't review / don't land: just testing <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
[08:30] <zyga> jamesh: ah, I see
[08:30] <zyga> jamesh: yes, I hope so, I will ask if anyone is interested in making that upate
[08:30] <zyga> in the end I can package it too :)
[08:31] <zyga> pstolowski: that path is a variation of the very first layout issue you found
[08:32] <pstolowski> zyga: nice
[08:36] <mvo> zyga: I will run the layout integration test with your PR5294
[08:54] <Chipaca> mo'in peeps. I'm going to be online but working on paperwork (taking a day off in hr for this crap). Shout if you can save me from the drudgery.
[08:55] <Chipaca> (boss-man still needs to approve though so it's tentative for now :) )
[08:55] <mvo> Chipaca: good luck
[08:55]  * mvo hugs Chipaca 
[08:55]  * Chipaca hugs mvo
[08:55] <Chipaca> I thought I had everything but they've added columns ¯\_(ツ)_/¯
[08:56] <Chipaca> anyhoo
[09:11] <zyga> Chipaca: take care and be careful with typos
[09:36] <mup> PR snapd#5393 closed: strutil: add PathIterator.Rewind <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5393>
[09:36] <zyga> mborzecki: I chose not to add a 2nd constructor because we can always do that and YAGNI for now
[09:36] <mborzecki> zyga: ack
[09:37] <mup> PR snapd#5394 closed: strutil: support iteration over almost clean paths <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5394>
[09:41] <mborzecki> pedronis: hi, niemeyer suggested changing StoreName() to InstanceSnap() in #5370, i thought about doing it in a followup PR so as not to pollute this one, but i'll squeeze it in the current one instead just to save on time
[09:41] <mup> PR #5370: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
[09:42] <niemeyer> mborzecki: This one PR is quite short and is where the functions are being introduced.. seems better to just do it there
[09:43] <niemeyer> mborzecki: Or do you mean everything else "StoreName"?
[09:43] <pedronis> niemeyer: that my question too?  are we changing   snap.Info.StoreName  to snap.Info.InstanceSnap ? that is a bit strange
[09:43] <mborzecki> niemeyer: the functions were introduced in #5363, but the diffstat is small 38 lines changed
[09:43] <mup> PR #5363: snap: introduce the instance key field <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
[09:44] <niemeyer> pedronis: No, that's strange indeed
[09:45] <niemeyer> pedronis: "Name" would be the most natural there still
[09:45] <mborzecki> SnapName() then?
[09:45] <niemeyer> mborzecki: Or that..
[09:45] <pedronis> SnapName() is what the assertion uses
[09:45] <pedronis> so there is precedent
[09:46] <pedronis> the issue is that we have snapName around the code base quite a lot
[09:46] <pedronis> those in many cases
[09:46] <pedronis> instanceName now
[09:46] <pedronis> but don't think we have done a rename
[09:46] <niemeyer> It's a different reason, but yeah, sounds okay to avoid "Name" being too obvious for cases we really mean InstanceName
[09:47] <niemeyer> pedronis: Yeah, we've been doing mainly the method, but left the vars behind
[09:48] <niemeyer> We can rename to instName or similar shortly.. I think as long as we have a strong convention we can easily fix
[09:48] <pedronis> yea, we can do a clean up
[09:49] <pedronis> it's 950 places
[09:49] <pedronis> but that can wait a bit
[09:49] <mborzecki> hm that would make a one large diff
[09:49] <pedronis> yea, I don't think you want to do it now, in that PR
[09:50] <pedronis> it's not urgent
[09:50] <pedronis> the methods are a more pressing issue
[09:51] <mborzecki> so we have StoreName(), InstanceSnap(), Snap() (?), SnapName()
[09:52] <pedronis> we do hae Snap() methods and they tend to return  a *snap.Info
[09:52] <pedronis> I'm personally ok with snap.Info.SnapName
[09:54] <mborzecki> ok, let's do snap.Info.SnapName() then, i'll push it to that PR to avoid another one
[10:01] <niemeyer> mborzecki: Let's please not do it in that PR
[10:01] <niemeyer> mborzecki: That PR is reviewed and unrelated
[10:01] <niemeyer> mborzecki: If you push more changes into it, the changes already reviewed and unrelated are blocked
[10:11] <mup> PR snapd#5396 opened: many: rename snap.Info.StoreName() to snap.Info.SnapName() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5396>
[10:11] <mborzecki> niemeyer: pedronis: ^^
[10:12] <mborzecki> i'll be landing 5370 when it becomes green
[10:12] <niemeyer> +				RealName: snapInfo.SnapName(),
[10:12] <niemeyer> Nice
[10:12] <mborzecki> niemeyer: yeah, it reads nice too
[10:14] <niemeyer> mborzecki: LGTM with just one detail tehre
[10:15] <pedronis> mborzecki: lunch here, I can look after
[10:15] <mborzecki> pedronis: sure, enjoy your lunch!
[10:18] <mborzecki> niemeyer: thanks, pushed
[10:34] <mborzecki> heh hit econnreset again
[10:35] <mborzecki> what if we built in a rate limiter in http download and limit it to say 1MB/s in that particular test?
[10:38] <mborzecki> there's juju/ratelimit package, which is already available in fedora/debian/ubuntu
[10:40] <zyga> mborzecki: how would that work?
[10:40] <mborzecki> zyga: stuff a rate limiting writer in the pipeline between reading from the body and writing to the disk
[10:41] <zyga> we could do that for an unit test
[10:42] <zyga> I don't understand how we could do that in a speread test
[10:43] <mborzecki> zyga: add the writer, into the pipeline if some env flag is set, eg SNAP_DEBUG_HTTP_RATE
[10:43] <zyga> mmm, yes that could work
[10:44] <zyga> it might be even more generic
[10:44] <mborzecki> low tech but well
[10:44] <zyga> snap set snapd.throttle.downloads=100KB/s
[10:44] <zyga> ish :)
[10:46] <pstolowski> could we maybe limit the rate by a QOS rule instead?
[10:47] <mborzecki> heh, i'd rather do go code  than touch tc :P
[10:47] <mborzecki> but yeah, that's another option
[10:48] <mup> PR snapd#5329 closed: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
[10:49] <pstolowski> mborzecki: man iptables-extensions - hashlimit looks promising
[10:50] <pstolowski> mborzecki: i prefer not to modify code for tests (if i've a choice)
[10:51] <mborzecki> pstolowski: isn't that just for matching?
[10:52] <pstolowski> mborzecki: yes you're right. yeah, tc might be the way to go
[10:53] <mborzecki> i can play with this a little
[10:55] <pstolowski> mborzecki: this article confused be about iptables - https://making.pusher.com/per-ip-rate-limiting-with-iptables/ - it seems he is using iptables + hashlimit to -j DROP packets when reaching limits
[10:56] <pstolowski> s/be/me
[10:56] <pstolowski> might not be the best way, but perhaps simple enough for the test
[10:57] <pstolowski> mborzecki: actually, perhaps we could applay iptables rule right at the start to simply kick in after x MB, instead of injecting it in a racy way
[10:58] <mborzecki> that could work
[10:58] <mborzecki> let me check it
[10:59] <pstolowski> yay, my usb2uart adapters arrived
[11:00] <pstolowski> going for lunch & to collect them
[11:00] <zyga> mvo: hey
[11:00] <zyga> mvo: around?
[11:00] <mborzecki> btw. fresh debian-9-64, 2018/06/26 10:59:48.646131 store.go:1555: DEBUG: Download succeeded in 6.997s (77MB/s).!!
[11:00] <pstolowski|lunch> mborzecki: wow!
[11:01] <mborzecki> subsequent downloads closer to 100MB/s - 99, 96, 95
[11:11] <mvo> zyga: almost on my way to lunch, what can I do for you?
[11:12] <mvo> pstolowski|lunch: we could also simply make snapt-test-huge bigger, I can double it
[11:12] <zyga> mvo: just wanted to ask if we should do one more patch, to translate explicit "core" to "snapd" on API requests, when snapd is the interface host
[11:13] <zyga> mvo: this would fix tests that do "snap disconnect foo:network core:network"
[11:16] <mvo> zyga: it sounds sensible, when you say api request you mean web api?
[11:16] <zyga> mvo: I mean daemon/api.go
[11:16] <zyga> mvo: though this would really happen in the interface manager
[11:17] <zyga> mvo: I'm trying to asses what is the next blocker for core18
[11:17] <zyga> if this is vague I can still hop onto another task that is close to completion and return to core18
[11:17] <zyga> (later)
[11:18] <mvo> zyga: can we use a lower layer for the translation than daemon/api.go?
[11:18] <zyga> yes, I would probably only do this in the interface manager
[11:18] <zyga> or even perhaps in the repository itself
[11:18] <zyga> since that makes it immune to state changes
[11:19] <mvo> zyga: that sounds good, +1 from me
[11:19] <zyga> ok, super
[11:20] <mvo> zyga: cool, I get lunch now
[11:20] <zyga> ok
[11:25] <zyga> hmm
[11:25] <zyga> I think we really really really need to update snapd in sid
[11:26] <mup> PR snapd#5370 closed: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
[11:29] <mup> PR snapd#4996 closed: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4996>
[12:05]  * zyga had to clean the kitchen sink, to filter the water, to fill the water tank, to make the coffee 
[12:05] <zyga> talk about kitchen debt ;)
[12:05] <zyga> jdstrand: good day
[12:20] <mborzecki> pstolowski|lunch: heh, no tc for us, i'm policing the ingress taffic, tc can't do that
[12:20] <mborzecki> pstolowski|lunch: got something ready, will be opening a PR soon(ish)
[12:21] <mborzecki> pstolowski: i'm actually slowing down all ingress traffic to 512kB/s, this will give us plenty of time to apply the rule in output chain
[12:33] <mup> PR snapd#5397 opened: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
[12:35] <pstolowski> mborzecki: nice
[12:35] <zyga> woah
[12:35] <zyga> nice work man!
[12:36] <zyga> let's see how it works :)
[12:36] <mborzecki> heh, yeah ;) hope it works
[12:37] <pstolowski> niemeyer: hey, do you agree with my comment re ForbiddenCommandError https://github.com/snapcore/snapd/pull/5326/files/ee3e078f94ba5ee11b5515eddabd40b9d1859c05#diff-82e84d8ad7fc634fbd6d18b5b61c4273 ?
[12:37] <mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
[12:37] <sergiusens> mvo: can you make `core` a valid base? or is that something Chipaca would normally do?
[12:38] <mvo> sergiusens: you mean type: base?
[12:39] <sergiusens> mvo: if I create a snap with `base: core` it is uninstallable
[12:39] <zyga> woah
[12:39] <zyga> interesting
[12:40] <jdstrand> hey zyga :)
[12:40] <sergiusens> probably because core is mixed thing and not really a base so it would need quirking or some sort of transition
[12:40] <zyga> jdstrand: hey :)
[12:41] <zyga> jdstrand: I sent https://github.com/snapcore/snapd/pull/5395 today
[12:41] <mup> PR #5395: interfaces: generalize writable mimic profile <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
[12:41] <zyga> I'm actually a little ashamed because I ended up not using the chopTree function in it, we can think about that
[12:42] <jdstrand> ok
[12:42] <zyga> or just move the docs over to this PR and drop chopTree
[12:42] <zyga> some of the way the rules look was made deliberatetely so that they read nice top-to-bottom
[12:42] <zyga> the code could be slimpler without this
[12:43] <mup> PR snapd#5383 closed: tests: tweaks for running the main tests on core18 <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5383>
[12:43] <zyga> I will also send updates to the adb support interface
[12:43] <zyga> I also recall that we had some issues with /proc/1/ns/mnt
[12:43] <zyga> and there's one case now that seems to be a good bet of what the issues is, using a vanilla kernel on ubuntu to support new hardware
[12:44] <zyga> I will give that a try but likely only tomorrow
[12:45] <zyga> jdstrand: apart from that nothing urgent, I'm trying to wrap up things ahead of a bigger change to the interface manager
[12:46] <mvo> sergiusens: aha, right - I think we need core16 for that
[12:46] <mup> PR snapd#5358 closed: tests: add spread test to ensure snapd/core18 are not removable <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5358>
[12:46] <mvo> sergiusens: let me see if I can create this
[12:49] <niemeyer> pstolowski: I'm not sure I understand what you mean there
[12:49] <niemeyer> pstolowski: The ForbiddenCommand type is not being used anywhere other than during instantiation
[12:50] <niemeyer> pstolowski: So when you say you need the type, where?
[12:50] <pstolowski> niemeyer: i mean in the error check in api.go: if e, ok := err.(*ctlcmd.ForbiddenCommandError); ok
[12:51] <niemeyer> pstolowski: Ah, I missed that indeed, sorry
[12:51] <niemeyer> pstolowski: Yes, +1 on your suggestion
[12:52] <pstolowski> niemeyer: okay, thanks. in the original PR I (ab)used ForbiddenCommand for that by implementing Error()
[12:52] <jdstrand> zyga: ok. istr there was an issue I said I was surprised wasn't on your list before I left, and you said you'd add it. I don't recall otoh what that was...
[12:52] <pstolowski> zyga: can you take 2nd look at https://github.com/snapcore/snapd/pull/5326 when you have moment?
[12:52] <mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
[12:53] <jdstrand> zyga: 07:37 < jdstrand> zyga: I was surprised to see that the 'profile not found' issue was not on your list. it seems I see at least once a day an issue where someone is hitting it
[12:53] <zyga> jdstrand: I don't have the hard facts yet, either the reporter I'm talking to will provide them or I can run a mainline kernel on my laptop and compare
[12:53] <jdstrand> ok, so that was on your list today. great
[12:53] <zyga> jdstrand: yeah, I recall that, this is why I'm giving you an update, we seem to have more information now
[12:53] <zyga> it's clearly related to a mainline kernel
[12:53] <jdstrand> zyga: nice! I'm not even close to caught up on emails yet
[12:53] <zyga> what is curious is that this hasn't happened in opensuse tumblweed with apparmor that I used for much of my work last week
[12:54] <zyga> so either opensuse took more patches (which is possible and I think jj mentioned that in the  presentation he gave at a suse conference)
[12:54] <zyga> or there's more to it :)
[13:02] <mup> PR snapd#5396 closed: many: rename snap.Info.StoreName() to snap.Info.SnapName() <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5396>
[13:28] <rbasak> How do I run snapcraft from its source tree? According to HACKING.md calling bin/snapcraft should just work, but I get https://pastebin.ubuntu.com/p/RsKtZ448nk/. Setting PYTHONPATH to the top of the tree doesn't seem to work either. Something to do with looping round through snapcraftctl?
[13:28] <mborzecki> mvo: zsh in non interactive shells uses /etc/zsh/zshenv
[13:29] <rbasak> I'm not using virtualenv if that matters.
[13:37] <mborzeck1> my link has died for a minute there
[13:48]  * cachio afk
[14:27] <mvo> mborzecki: thank you
[14:27] <mvo> mborzecki: there is no .d mechanism, right?
[14:27] <mborzecki> mvo: not that i'm aware of
[14:29] <mvo> mborzecki: yeah, thats slightly sad that we can't plug into anything
[14:29] <zyga> pstolowski: ack
[14:29] <zyga> (I'll review it next)
[14:29] <zyga> quick break
[14:32] <mup> PR snapcraft#2166 closed: project_loader: replace dict keys as well as values <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2166>
[14:59] <zyga> re
[15:00] <zyga> mvo: snapd reexec in debian is ok
[15:02] <zyga> pstolowski: hey, about those serial ports you got
[15:02] <zyga> how stable are they?
[15:03] <zyga> and do they have serial numbers
[15:03] <zyga> I also thought about a case we didn't discuss
[15:03] <pstolowski> zyga: stable? in what sense? no idea
[15:03] <zyga> imagine you re-plug a device, snapd understands that it is the same device we had before
[15:03] <zyga> pstolowski: but linux level things changed about it (e.g. different device path)
[15:03] <mup> PR snapd#5398 opened: tests: disable auto-refresh test on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5398>
[15:03] <mup> PR snapd#5399 opened: tests: moving install of dependencies to pkgdb helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5399>
[15:04] <zyga> oho, storm is coming
[15:05] <mup> PR snapd#5400 opened: spread.yaml: enable main and regression suite on core18 systems <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5400>
[15:08] <kyrofa> rbasak, try using a venv
[15:08] <pstolowski> zyga: yes, a valid scenario. we will find out a change in attributes and recreate the slot + re-estabish connections (if any). that assumes however we have a serial or can construct an equivalent of serial
[15:08] <pstolowski> zyga: i've just checked 2 adapters, one has serial (and it's not just zeros), the other doesn't
[15:09] <zyga> ha
[15:10] <zyga> cool
[15:10] <zyga> I'm glad you have that
[15:15] <mup> PR snapd#5401 opened: [RFC] asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5401>
[15:19] <mvo> zyga: thanks
[15:44]  * cachio lunch
[15:52] <mup> PR snapd#5402 opened: i18n: handle write errors in xgettext-go <Created by mvo5> <https://github.com/snapcore/snapd/pull/5402>
[15:55] <mup> PR snapd#5403 opened: many: use extra "releases" information on "revision-not-found-error" to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
[16:02] <mup> PR snapd#5404 opened: i18n: add canary checking to pot file extraction <Created by mvo5> <https://github.com/snapcore/snapd/pull/5404>
[16:08] <mup> PR snapcraft#2171 opened: {catkin,python} plugin: support cleaning <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2171>
[16:10] <mup> PR snapd#5405 opened: tests: do not mask errors in interfaces-timezone-control <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5405>
[16:15] <mup> PR core18#41 opened: Revert "static: add systemd environment generator to ensure PATH contains /snap/bin" <Created by mvo5> <https://github.com/snapcore/core18/pull/41>
[16:44]  * cachio afk
[17:11] <mup> PR snapcraft#2168 closed: build_providers: add ssh key managemet to the qemu build provider <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2168>
[17:29] <ogra_> mvo, is it wanted that setting a proxy adds a line without newline at the end to /etc/environment ?
[17:30] <ogra_> ogra@pi2:~$ cat /etc/environment
[17:30] <ogra_> PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
[17:30] <ogra_> http_proxy=localhost:8080ogra@pi2:~$
[17:31] <mvo> ogra_: hm, the missing newline sounds like a bug
[17:31] <mvo> ogra_: hopefully harmless
[17:36] <mvo> zyga: fwiw, the layout test with the latest master http://paste.ubuntu.com/p/nTqd6c4Zwc/
[17:37] <zyga> Is it reproducible?
[17:38] <mvo> zyga: not sure, probably on core18 but I can run again once the current run is done
[17:38] <zyga> Ah
[17:38] <zyga> Wait
[17:38] <zyga> Is /var/spool in Core18
[17:39] <zyga> mvo: can you try with https://github.com/snapcore/snapd/pull/5395
[17:39] <mup> PR #5395: interfaces: generalize writable mimic profile <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
[17:39] <mvo> zyga: heh, you mean, maybe we don't have it
[17:39] <mvo> zyga: let me check
[17:40] <mvo> zyga: http://paste.ubuntu.com/p/6cSTxzWw4Z/
[17:43] <mvo> zyga: I can try 5395 after the current run
[17:49] <zyga> OK
[17:49] <zyga> I left the house now, need to buy some food. I will try after I’m back
[18:19] <mvo> zyga: not urgent at all
[18:58] <zyga> re
[19:32] <mup> PR snapd#5406 opened: i18n: merge xgettext-canary and xgettext-robustness <Created by mvo5> <https://github.com/snapcore/snapd/pull/5406>
[19:39] <mup> PR snapd#5406 closed: i18n: merge xgettext-canary and xgettext-robustness <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5406>
[21:26] <mcphail> ondra: if I use your openhab snap on a pi3, should I also install your pi3-openhab gadget snap? If so, how do I "activate" that? (The documentation on gadget snaps is terribly opaque)
[21:38] <mup> PR snapd#5407 opened: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5407>
[22:18] <mup> PR snapcraft#2172 opened: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
[23:23] <kyrofa> zyga, I'm having trouble running snaps in lxc on my desktop: cannot remount /tmp/snap.rootfs_nMP7A9/var/lib/snapd/lib/vulkan as read-only: Permission denied
[23:45] <mup> PR snapcraft#2173 opened: tests: create basic integration test spread infrastructure <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2173>
[23:51] <kyrofa> niemeyer, eventually as the build VM stuff stabilizes, we'd like to test it in spread. Looks like google supports this (https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances), but it needs to be enabled
[23:52] <kyrofa> Since it can be done via the API, is that a switch spread can throw for us?
[23:52] <kyrofa> (perhaps it already is?)