| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 05:04 |
|---|---|---|
| zyga | o/ | 05:06 |
| 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> | 05:25 |
| === Guest74533_ is now known as braderhart | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | we're at 41 PRs :( | 06:41 |
| 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:43 |
| 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:55 |
| 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:58 |
| zyga | merging | 06:59 |
| 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:00 |
| === pstolowski|afk is now known as pstolowski | ||
| 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:08 |
| mborzecki | pstolowski: hey | 07:09 |
| 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:12 |
| mvo | zyga: nice | 07:18 |
| mvo | zyga: what was it? | 07:18 |
| 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:27 |
| zyga | https://www.irccloud.com/pastebin/xXb1dxKK/ | 07:28 |
| zyga | I also don't get it why it failed for you in particular | 07:28 |
| mvo | zyga: interessting | 07:37 |
| zyga | essentially, path ending in / is "bad" | 07:37 |
| zyga | let me try to make it okay without this hack | 07:38 |
| 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:45 |
| zyga | hmm | 07:46 |
| zyga | it has two +1s | 07:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| zyga | jamesh: and we require 0.11? | 07:53 |
| 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:54 |
| 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:55 |
| jamesh | the D-Bus APIs aren't much more or less secure in 0.10 vs 0.11 in this case. | 07:56 |
| zyga | mmm | 08:00 |
| zyga | well | 08:00 |
| zyga | well, at least we would have nicer UX since snaps would be detected | 08:00 |
| jamesh | my preferred solution would be to just add "Conflicts: xdg-desktop-portal < 0.11" to the OpenSUSE spec file | 08:01 |
| jamesh | so things things work when the new version rolls out, but we don't let people install insecure portals together with snapd | 08:02 |
| 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:03 |
| jamesh | or 15.1 maybe | 08:04 |
| zyga | perhaps, but I don't know the package update policy | 08:04 |
| === chihchun is now known as chihchun_afk | ||
| 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:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| mup | PR snapd#5393 opened: strutil: add PathIterator.Rewind <Created by zyga> <https://github.com/snapcore/snapd/pull/5393> | 08:17 |
| 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:18 |
| === chihchun_afk is now known as chihchun | ||
| 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:19 |
| 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:22 |
| 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:29 |
| 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:30 |
| zyga | pstolowski: that path is a variation of the very first layout issue you found | 08:31 |
| pstolowski | zyga: nice | 08:32 |
| mvo | zyga: I will run the layout integration test with your PR5294 | 08:36 |
| 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:54 |
| 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:55 |
| Chipaca | anyhoo | 08:56 |
| zyga | Chipaca: take care and be careful with typos | 09:11 |
| 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:36 |
| 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:37 |
| 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:41 |
| niemeyer | mborzecki: This one PR is quite short and is where the functions are being introduced.. seems better to just do it there | 09:42 |
| 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:43 |
| niemeyer | pedronis: No, that's strange indeed | 09:44 |
| 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:45 |
| 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:46 |
| niemeyer | pedronis: Yeah, we've been doing mainly the method, but left the vars behind | 09:47 |
| 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:48 |
| 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:49 |
| pedronis | it's not urgent | 09:50 |
| pedronis | the methods are a more pressing issue | 09:50 |
| mborzecki | so we have StoreName(), InstanceSnap(), Snap() (?), SnapName() | 09:51 |
| 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:52 |
| mborzecki | ok, let's do snap.Info.SnapName() then, i'll push it to that PR to avoid another one | 09:54 |
| 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:01 |
| 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:11 |
| 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:12 |
| niemeyer | mborzecki: LGTM with just one detail tehre | 10:14 |
| pedronis | mborzecki: lunch here, I can look after | 10:15 |
| mborzecki | pedronis: sure, enjoy your lunch! | 10:15 |
| mborzecki | niemeyer: thanks, pushed | 10:18 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | heh hit econnreset again | 10:34 |
| mborzecki | what if we built in a rate limiter in http download and limit it to say 1MB/s in that particular test? | 10:35 |
| mborzecki | there's juju/ratelimit package, which is already available in fedora/debian/ubuntu | 10:38 |
| 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:40 |
| zyga | we could do that for an unit test | 10:41 |
| zyga | I don't understand how we could do that in a speread test | 10:42 |
| 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:43 |
| 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:44 |
| pstolowski | could we maybe limit the rate by a QOS rule instead? | 10:46 |
| mborzecki | heh, i'd rather do go code than touch tc :P | 10:47 |
| mborzecki | but yeah, that's another option | 10:47 |
| 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:48 |
| pstolowski | mborzecki: man iptables-extensions - hashlimit looks promising | 10:49 |
| pstolowski | mborzecki: i prefer not to modify code for tests (if i've a choice) | 10:50 |
| mborzecki | pstolowski: isn't that just for matching? | 10:51 |
| pstolowski | mborzecki: yes you're right. yeah, tc might be the way to go | 10:52 |
| mborzecki | i can play with this a little | 10:53 |
| 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:55 |
| pstolowski | s/be/me | 10:56 |
| pstolowski | might not be the best way, but perhaps simple enough for the test | 10:56 |
| 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:57 |
| mborzecki | that could work | 10:58 |
| mborzecki | let me check it | 10:58 |
| pstolowski | yay, my usb2uart adapters arrived | 10:59 |
| 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 is now known as pstolowski|lunch | ||
| pstolowski|lunch | mborzecki: wow! | 11:00 |
| mborzecki | subsequent downloads closer to 100MB/s - 99, 96, 95 | 11:01 |
| mvo | zyga: almost on my way to lunch, what can I do for you? | 11:11 |
| 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:12 |
| zyga | mvo: this would fix tests that do "snap disconnect foo:network core:network" | 11:13 |
| 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:16 |
| 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:17 |
| 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:18 |
| mvo | zyga: that sounds good, +1 from me | 11:19 |
| zyga | ok, super | 11:19 |
| mvo | zyga: cool, I get lunch now | 11:20 |
| zyga | ok | 11:20 |
| zyga | hmm | 11:25 |
| zyga | I think we really really really need to update snapd in sid | 11:25 |
| 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:26 |
| 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> | 11:29 |
| * 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:05 |
| 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:20 |
| === pstolowski|lunch is now known as pstolowski | ||
| 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:21 |
| 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:33 |
| pstolowski | mborzecki: nice | 12:35 |
| zyga | woah | 12:35 |
| zyga | nice work man! | 12:35 |
| zyga | let's see how it works :) | 12:36 |
| mborzecki | heh, yeah ;) hope it works | 12:36 |
| 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:37 |
| mvo | sergiusens: you mean type: base? | 12:38 |
| sergiusens | mvo: if I create a snap with `base: core` it is uninstallable | 12:39 |
| zyga | woah | 12:39 |
| zyga | interesting | 12:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| zyga | I will give that a try but likely only tomorrow | 12:44 |
| zyga | jdstrand: apart from that nothing urgent, I'm trying to wrap up things ahead of a bigger change to the interface manager | 12:45 |
| 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:46 |
| 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:49 |
| 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:50 |
| niemeyer | pstolowski: Ah, I missed that indeed, sorry | 12:51 |
| niemeyer | pstolowski: Yes, +1 on your suggestion | 12:51 |
| 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:52 |
| 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:53 |
| 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 :) | 12:54 |
| 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:02 |
| 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:28 |
| rbasak | I'm not using virtualenv if that matters. | 13:29 |
| === pbek_ is now known as pbek | ||
| mborzeck1 | my link has died for a minute there | 13:37 |
| === mborzeck1 is now known as mborzecki | ||
| * cachio afk | 13:48 | |
| 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:27 |
| 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:29 |
| 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:32 |
| zyga | re | 14:59 |
| zyga | mvo: snapd reexec in debian is ok | 15:00 |
| zyga | pstolowski: hey, about those serial ports you got | 15:02 |
| zyga | how stable are they? | 15:02 |
| 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:03 |
| zyga | oho, storm is coming | 15:04 |
| 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:05 |
| 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:08 |
| zyga | ha | 15:09 |
| zyga | cool | 15:10 |
| zyga | I'm glad you have that | 15:10 |
| 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:15 |
| mvo | zyga: thanks | 15:19 |
| * cachio lunch | 15:44 | |
| mup | PR snapd#5402 opened: i18n: handle write errors in xgettext-go <Created by mvo5> <https://github.com/snapcore/snapd/pull/5402> | 15:52 |
| 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> | 15:55 |
| mup | PR snapd#5404 opened: i18n: add canary checking to pot file extraction <Created by mvo5> <https://github.com/snapcore/snapd/pull/5404> | 16:02 |
| mup | PR snapcraft#2171 opened: {catkin,python} plugin: support cleaning <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2171> | 16:08 |
| 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:10 |
| 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:15 |
| === pstolowski is now known as pstolowski|afk | ||
| * cachio afk | 16:44 | |
| 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:11 |
| ogra_ | mvo, is it wanted that setting a proxy adds a line without newline at the end to /etc/environment ? | 17:29 |
| 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:30 |
| mvo | ogra_: hm, the missing newline sounds like a bug | 17:31 |
| mvo | ogra_: hopefully harmless | 17:31 |
| mvo | zyga: fwiw, the layout test with the latest master http://paste.ubuntu.com/p/nTqd6c4Zwc/ | 17:36 |
| zyga | Is it reproducible? | 17:37 |
| 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:38 |
| 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:39 |
| mvo | zyga: http://paste.ubuntu.com/p/6cSTxzWw4Z/ | 17:40 |
| mvo | zyga: I can try 5395 after the current run | 17:43 |
| zyga | OK | 17:49 |
| zyga | I left the house now, need to buy some food. I will try after I’m back | 17:49 |
| mvo | zyga: not urgent at all | 18:19 |
| zyga | re | 18:58 |
| mup | PR snapd#5406 opened: i18n: merge xgettext-canary and xgettext-robustness <Created by mvo5> <https://github.com/snapcore/snapd/pull/5406> | 19:32 |
| 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> | 19:39 |
| 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:26 |
| mup | PR snapd#5407 opened: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5407> | 21:38 |
| mup | PR snapcraft#2172 opened: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172> | 22:18 |
| 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:23 |
| mup | PR snapcraft#2173 opened: tests: create basic integration test spread infrastructure <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2173> | 23:45 |
| 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:51 |
| 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?) | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!