=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [05:04] morning [05:06] o/ [05:25] PR snapd#5178 closed: interfaces/builtin: initial version of the anbox-support interface === Guest74533_ is now known as braderhart === chihchun_afk is now known as chihchun [06:41] we're at 41 PRs :( [06:43] PR snapd#5253 closed: snap: introduce new fields for parallel snap installation [06:55] mvo: shall I land #5384 ? [06:55] PR #5384: tests: update interfaces-timeserver-control to core18 [06:58] re [06:58] sorry, I was hacking late last night [06:58] just waking up now [06:58] looking now [06:59] merging [07:00] PR snapd#5384 closed: tests: update interfaces-timeserver-control to core18 === pstolowski|afk is now known as pstolowski [07:08] mornings [07:08] mborzecki: yeah, if it has the needed +1 please [07:08] thanks zyga [07:08] pstolowski: good morning [07:09] pstolowski: hey [07:12] hey mvo [07:12] I fixed the layout issue you ran into [07:12] I will get myself into shape and send a patch [07:18] zyga: nice [07:18] zyga: what was it? [07:27] re [07:27] it was just this [07:27] but I want to still tweak this [07:27] I don't like the fact that it is allowed to fail [07:28] https://www.irccloud.com/pastebin/xXb1dxKK/ [07:28] I also don't get it why it failed for you in particular [07:37] zyga: interessting [07:37] essentially, path ending in / is "bad" [07:38] let me try to make it okay without this hack [07:45] zyga: hi. do you have any suggestions on how to move forward with this branch? https://github.com/snapcore/snapd/pull/5271 [07:45] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [07:45] jamesh: hey! [07:45] jamesh: let me look please, I don't recall [07:46] hmm [07:46] it has two +1s [07:47] 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] mvo, mborzecki ^ [07:47] zyga: sure [07:47] I have a look in a wee bit [07:48] 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] jamesh: on old opensuse there's no strong security [07:48] and on tumbleweed there's recent everything [07:48] I think we are fine on this front [07:48] jamesh: for context, I enabled apparmor on tumbleweed last week [07:48] but it is not enabled on any any leap release yet [07:49] zyga: https://software.opensuse.org/package/xdg-desktop-portal shows too-old xdg-desktop-portal for all OpenSUSE releases [07:49] PR snapd#5392 opened: snapstate,ifstate: wait for pending restarts before auto-connecting [07:53] jamesh: and we require 0.11? [07:54] zyga: 0.11 is the first version with snap support, yes. [07:54] Mmm [07:54] Let me ask if 0.11 is coming to TW anytime soon [07:55] zyga: can you take another look at #5311 i've pushed some fixes hopefully it'll be green before cachio wakes up [07:55] PR #5311: tests: start active system units on reset [07:55] 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] the D-Bus APIs aren't much more or less secure in 0.10 vs 0.11 in this case. [08:00] mmm [08:00] well [08:00] well, at least we would have nicer UX since snaps would be detected [08:01] my preferred solution would be to just add "Conflicts: xdg-desktop-portal < 0.11" to the OpenSUSE spec file [08:02] so things things work when the new version rolls out, but we don't let people install insecure portals together with snapd [08:03] jamesh: 0.11 is not submitted to factory yet [08:03] jamesh: mmm [08:03] jamesh: but that could mean arbitrary amount of time [08:03] and also on leap that will be never [08:04] or 15.1 maybe [08:04] perhaps, but I don't know the package update policy === chihchun is now known as chihchun_afk [08:12] jamesh: what should we do if this lands to master with this constraint (on packaging) [08:12] won't this block spread testing? [08:14] 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] but won't this block the installation of the package? [08:15] I mean, if we put a constraint on a package that's not in the archive yet [08:15] all of suse spread testing will stop [08:15] zyga: we never try to install the xdg-desktop-portal package in any of the tests [08:15] ahh [08:15] I see what you mean [08:15] although [08:15] if the portal package is installed by default anywhere this might be a problem [08:16] https://flatpak.org/setup/openSUSE/ seems to indicate it isn't installed by default [08:16] ok then [08:16] but let's add this constraint to TW only [08:16] (I can't think of a reason for xdg-desktop-portal to be installed currently if flatpak isn't) [08:17] PR snapd#5393 opened: strutil: add PathIterator.Rewind [08:18] PR snapd#5394 opened: strutil: support iteration over almost clean paths [08:18] mvo: ^ this should fix the issue you ran into === chihchun_afk is now known as chihchun [08:19] PR snapd#5395 opened: don't review / don't land: just testing [08:19] 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] 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] jamesh: I don't know much about SLES, I tried to build snappy for SLE 12 but failed on missing build dependencies [08:29] I need to take the dog out now, it's almost 10:30 ! [08:30] zyga: looking, thanks [08:30] 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] pstolowski: https://github.com/snapcore/snapd/pull/5395/files#diff-485a172e36d1bd329b385818efa017b6 :) [08:30] PR #5395: don't review / don't land: just testing [08:30] jamesh: ah, I see [08:30] jamesh: yes, I hope so, I will ask if anyone is interested in making that upate [08:30] in the end I can package it too :) [08:31] pstolowski: that path is a variation of the very first layout issue you found [08:32] zyga: nice [08:36] zyga: I will run the layout integration test with your PR5294 [08:54] 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] (boss-man still needs to approve though so it's tentative for now :) ) [08:55] Chipaca: good luck [08:55] * mvo hugs Chipaca [08:55] * Chipaca hugs mvo [08:55] I thought I had everything but they've added columns ¯\_(ツ)_/¯ [08:56] anyhoo [09:11] Chipaca: take care and be careful with typos [09:36] PR snapd#5393 closed: strutil: add PathIterator.Rewind [09:36] mborzecki: I chose not to add a 2nd constructor because we can always do that and YAGNI for now [09:36] zyga: ack [09:37] PR snapd#5394 closed: strutil: support iteration over almost clean paths [09:41] 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] PR #5370: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag [09:42] mborzecki: This one PR is quite short and is where the functions are being introduced.. seems better to just do it there [09:43] mborzecki: Or do you mean everything else "StoreName"? [09:43] niemeyer: that my question too? are we changing snap.Info.StoreName to snap.Info.InstanceSnap ? that is a bit strange [09:43] niemeyer: the functions were introduced in #5363, but the diffstat is small 38 lines changed [09:43] PR #5363: snap: introduce the instance key field [09:44] pedronis: No, that's strange indeed [09:45] pedronis: "Name" would be the most natural there still [09:45] SnapName() then? [09:45] mborzecki: Or that.. [09:45] SnapName() is what the assertion uses [09:45] so there is precedent [09:46] the issue is that we have snapName around the code base quite a lot [09:46] those in many cases [09:46] instanceName now [09:46] but don't think we have done a rename [09:46] It's a different reason, but yeah, sounds okay to avoid "Name" being too obvious for cases we really mean InstanceName [09:47] pedronis: Yeah, we've been doing mainly the method, but left the vars behind [09:48] We can rename to instName or similar shortly.. I think as long as we have a strong convention we can easily fix [09:48] yea, we can do a clean up [09:49] it's 950 places [09:49] but that can wait a bit [09:49] hm that would make a one large diff [09:49] yea, I don't think you want to do it now, in that PR [09:50] it's not urgent [09:50] the methods are a more pressing issue [09:51] so we have StoreName(), InstanceSnap(), Snap() (?), SnapName() [09:52] we do hae Snap() methods and they tend to return a *snap.Info [09:52] I'm personally ok with snap.Info.SnapName [09:54] ok, let's do snap.Info.SnapName() then, i'll push it to that PR to avoid another one [10:01] mborzecki: Let's please not do it in that PR [10:01] mborzecki: That PR is reviewed and unrelated [10:01] mborzecki: If you push more changes into it, the changes already reviewed and unrelated are blocked [10:11] PR snapd#5396 opened: many: rename snap.Info.StoreName() to snap.Info.SnapName() [10:11] niemeyer: pedronis: ^^ [10:12] i'll be landing 5370 when it becomes green [10:12] + RealName: snapInfo.SnapName(), [10:12] Nice [10:12] niemeyer: yeah, it reads nice too [10:14] mborzecki: LGTM with just one detail tehre [10:15] mborzecki: lunch here, I can look after [10:15] pedronis: sure, enjoy your lunch! [10:18] niemeyer: thanks, pushed === chihchun is now known as chihchun_afk [10:34] heh hit econnreset again [10:35] what if we built in a rate limiter in http download and limit it to say 1MB/s in that particular test? [10:38] there's juju/ratelimit package, which is already available in fedora/debian/ubuntu [10:40] mborzecki: how would that work? [10:40] zyga: stuff a rate limiting writer in the pipeline between reading from the body and writing to the disk [10:41] we could do that for an unit test [10:42] I don't understand how we could do that in a speread test [10:43] zyga: add the writer, into the pipeline if some env flag is set, eg SNAP_DEBUG_HTTP_RATE [10:43] mmm, yes that could work [10:44] it might be even more generic [10:44] low tech but well [10:44] snap set snapd.throttle.downloads=100KB/s [10:44] ish :) [10:46] could we maybe limit the rate by a QOS rule instead? [10:47] heh, i'd rather do go code than touch tc :P [10:47] but yeah, that's another option [10:48] PR snapd#5329 closed: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing [10:49] mborzecki: man iptables-extensions - hashlimit looks promising [10:50] mborzecki: i prefer not to modify code for tests (if i've a choice) [10:51] pstolowski: isn't that just for matching? [10:52] mborzecki: yes you're right. yeah, tc might be the way to go [10:53] i can play with this a little [10:55] 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] s/be/me [10:56] might not be the best way, but perhaps simple enough for the test [10:57] 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] that could work [10:58] let me check it [10:59] yay, my usb2uart adapters arrived [11:00] going for lunch & to collect them [11:00] mvo: hey [11:00] mvo: around? [11:00] btw. fresh debian-9-64, 2018/06/26 10:59:48.646131 store.go:1555: DEBUG: Download succeeded in 6.997s (77MB/s).!! === pstolowski is now known as pstolowski|lunch [11:00] mborzecki: wow! [11:01] subsequent downloads closer to 100MB/s - 99, 96, 95 [11:11] zyga: almost on my way to lunch, what can I do for you? [11:12] pstolowski|lunch: we could also simply make snapt-test-huge bigger, I can double it [11:12] 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] mvo: this would fix tests that do "snap disconnect foo:network core:network" [11:16] zyga: it sounds sensible, when you say api request you mean web api? [11:16] mvo: I mean daemon/api.go [11:16] mvo: though this would really happen in the interface manager [11:17] mvo: I'm trying to asses what is the next blocker for core18 [11:17] if this is vague I can still hop onto another task that is close to completion and return to core18 [11:17] (later) [11:18] zyga: can we use a lower layer for the translation than daemon/api.go? [11:18] yes, I would probably only do this in the interface manager [11:18] or even perhaps in the repository itself [11:18] since that makes it immune to state changes [11:19] zyga: that sounds good, +1 from me [11:19] ok, super [11:20] zyga: cool, I get lunch now [11:20] ok [11:25] hmm [11:25] I think we really really really need to update snapd in sid [11:26] PR snapd#5370 closed: overlord/{config,snap}state: introduce experimental.parallel-instances feature flag [11:29] PR snapd#4996 closed: overlord/ifacestate: store and use revision with security profiles set [12:05] * zyga had to clean the kitchen sink, to filter the water, to fill the water tank, to make the coffee [12:05] talk about kitchen debt ;) [12:05] jdstrand: good day [12:20] pstolowski|lunch: heh, no tc for us, i'm policing the ingress taffic, tc can't do that [12:20] pstolowski|lunch: got something ready, will be opening a PR soon(ish) === pstolowski|lunch is now known as pstolowski [12:21] 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] PR snapd#5397 opened: tests/main/econnreset: limit ingress traffic to 512kB/s [12:35] mborzecki: nice [12:35] woah [12:35] nice work man! [12:36] let's see how it works :) [12:36] heh, yeah ;) hope it works [12:37] niemeyer: hey, do you agree with my comment re ForbiddenCommandError https://github.com/snapcore/snapd/pull/5326/files/ee3e078f94ba5ee11b5515eddabd40b9d1859c05#diff-82e84d8ad7fc634fbd6d18b5b61c4273 ? [12:37] PR #5326: api/snapctl: allow -h and --help for regular users [12:37] mvo: can you make `core` a valid base? or is that something Chipaca would normally do? [12:38] sergiusens: you mean type: base? [12:39] mvo: if I create a snap with `base: core` it is uninstallable [12:39] woah [12:39] interesting [12:40] hey zyga :) [12:40] probably because core is mixed thing and not really a base so it would need quirking or some sort of transition [12:40] jdstrand: hey :) [12:41] jdstrand: I sent https://github.com/snapcore/snapd/pull/5395 today [12:41] PR #5395: interfaces: generalize writable mimic profile [12:41] I'm actually a little ashamed because I ended up not using the chopTree function in it, we can think about that [12:42] ok [12:42] or just move the docs over to this PR and drop chopTree [12:42] some of the way the rules look was made deliberatetely so that they read nice top-to-bottom [12:42] the code could be slimpler without this [12:43] PR snapd#5383 closed: tests: tweaks for running the main tests on core18 [12:43] I will also send updates to the adb support interface [12:43] I also recall that we had some issues with /proc/1/ns/mnt [12:43] 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] I will give that a try but likely only tomorrow [12:45] jdstrand: apart from that nothing urgent, I'm trying to wrap up things ahead of a bigger change to the interface manager [12:46] sergiusens: aha, right - I think we need core16 for that [12:46] PR snapd#5358 closed: tests: add spread test to ensure snapd/core18 are not removable [12:46] sergiusens: let me see if I can create this [12:49] pstolowski: I'm not sure I understand what you mean there [12:49] pstolowski: The ForbiddenCommand type is not being used anywhere other than during instantiation [12:50] pstolowski: So when you say you need the type, where? [12:50] niemeyer: i mean in the error check in api.go: if e, ok := err.(*ctlcmd.ForbiddenCommandError); ok [12:51] pstolowski: Ah, I missed that indeed, sorry [12:51] pstolowski: Yes, +1 on your suggestion [12:52] niemeyer: okay, thanks. in the original PR I (ab)used ForbiddenCommand for that by implementing Error() [12:52] 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] zyga: can you take 2nd look at https://github.com/snapcore/snapd/pull/5326 when you have moment? [12:52] PR #5326: api/snapctl: allow -h and --help for regular users [12:53] 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] 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] ok, so that was on your list today. great [12:53] jdstrand: yeah, I recall that, this is why I'm giving you an update, we seem to have more information now [12:53] it's clearly related to a mainline kernel [12:53] zyga: nice! I'm not even close to caught up on emails yet [12:53] 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] 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] or there's more to it :) [13:02] PR snapd#5396 closed: many: rename snap.Info.StoreName() to snap.Info.SnapName() [13:28] 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] mvo: zsh in non interactive shells uses /etc/zsh/zshenv [13:29] I'm not using virtualenv if that matters. === pbek_ is now known as pbek [13:37] my link has died for a minute there === mborzeck1 is now known as mborzecki [13:48] * cachio afk [14:27] mborzecki: thank you [14:27] mborzecki: there is no .d mechanism, right? [14:27] mvo: not that i'm aware of [14:29] mborzecki: yeah, thats slightly sad that we can't plug into anything [14:29] pstolowski: ack [14:29] (I'll review it next) [14:29] quick break [14:32] PR snapcraft#2166 closed: project_loader: replace dict keys as well as values [14:59] re [15:00] mvo: snapd reexec in debian is ok [15:02] pstolowski: hey, about those serial ports you got [15:02] how stable are they? [15:03] and do they have serial numbers [15:03] I also thought about a case we didn't discuss [15:03] zyga: stable? in what sense? no idea [15:03] imagine you re-plug a device, snapd understands that it is the same device we had before [15:03] pstolowski: but linux level things changed about it (e.g. different device path) [15:03] PR snapd#5398 opened: tests: disable auto-refresh test on core18 [15:03] PR snapd#5399 opened: tests: moving install of dependencies to pkgdb helper [15:04] oho, storm is coming [15:05] PR snapd#5400 opened: spread.yaml: enable main and regression suite on core18 systems [15:08] rbasak, try using a venv [15:08] 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] zyga: i've just checked 2 adapters, one has serial (and it's not just zeros), the other doesn't [15:09] ha [15:10] cool [15:10] I'm glad you have that [15:15] PR snapd#5401 opened: [RFC] asserts: add (optional) kernel-track to model assertion [15:19] zyga: thanks [15:44] * cachio lunch [15:52] PR snapd#5402 opened: i18n: handle write errors in xgettext-go [15:55] PR snapd#5403 opened: many: use extra "releases" information on "revision-not-found-error" to produce better errors [16:02] PR snapd#5404 opened: i18n: add canary checking to pot file extraction [16:08] PR snapcraft#2171 opened: {catkin,python} plugin: support cleaning [16:10] PR snapd#5405 opened: tests: do not mask errors in interfaces-timezone-control [16:15]