[00:04] jdstrand: Replied, sorry for the delay there [00:18] is my system messed up somehow? https://www.irccloud.com/pastebin/zgh6Nf9E/ === jamesh__ is now known as jamesh [04:59] morning [05:41] Good morning [05:41] I need to take the dog out and I will be back here shortly [06:25] * zyga reviews 5316 [06:51] PR snapd#5316 closed: store, et al: kill dead code that uses the bulk endpoint [06:52] whaa [06:52] I was reading it : [06:52] :-) [06:52] but that's fine [06:52] I guess I should make some coffee and meet with mvo then [06:53] zyga: yeah, but rush [06:54] rush or no rush? :D [06:54] zyga: no rush [06:54] zyga: sorry [06:54] zyga: I guess that is a sign that I need more tea [06:58] i think we're not picking up enough nvidia/cuda libraries [06:59] CUDA 9.1 runtime ships libcudart.so* which is not included in our globs === pstolowski|afk is now known as pstolowski [07:01] morning [07:01] mborzecki: I would love a proof of concept nvidia snap [07:02] zyga: this and the 'mesa' snap [07:02] mesa is slightly different [07:02] I don't know where it fits [07:02] is it all a bunch of .so files [07:02] or does it need to be in some weird specific spot [07:19] cuda sdk - merge 1.2GB download :/ [07:36] Bug #1639746 changed: Snap launching other snaps [07:54] hey all, where do I file bugs about emails from snapcraft.io? Thunderbird flags them as spoofing because of links pointing to a different place than they display. And then when viewing the online version, Firefox warns about it not being a fully safe connection (assets loaded via http) [07:55] Saviq: good question, I don't know honestly, perhaps popey or JamieBennett knows? [07:57] https://github.com/canonical-websites/snapcraft.io [07:57] Saviq: https://github.com/canonical-websites/snapcraft.io/ is a good place for it, make sure you tag @evandandrea and @lewciie [07:57] Thank you [07:58] * zyga thinks that it would be good to add a small piece of text to the page footer for this [07:58] maybe worth a small PR [07:58] thanks! [08:01] github is down or sth? [08:02] PR snapd#5322 opened: cmd/snap-confine: include CUDA runtime libraries [08:10] moin moin [08:10] mvo, mborzecki, zyga : do you want to take another look at https://github.com/snapcore/snapd/pull/5288 ? i'd like to land it and see if it improves situation; i've added a little more debug and also added rm -rf cleanup step before the test starts, in case we're reusing the machine and previous cleanup didn't work for whatever reason (i suspect this could explain our issues as I think in such case our caching kicks in and [08:10] we don't see retry on download, only on assertion fetch) [08:10] PR #5288: tests: econnreset/retry tweaks [08:11] looking [08:24] wanted to check cuda with snaps on arch, but the cuda package is installed under /opt/cuda, so our carefully crafter s-c globs basically went out the window [08:30] mvo: you around? [08:30] Chipaca: yes [08:31] mvo: you have dev access to the hello-world snap, yes? [08:31] Chipaca: let me check, yes [08:31] Chipaca: you have as well [08:31] I do? [08:31] Chipaca: sure, check your mail [08:31] ah [08:32] I've been invited to perhaps :-) [08:32] Chipaca: ;) [08:38] PR snapd#5323 opened: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect [08:41] hrmph, the hello-world data in the store tests has been edited in undocumented ways :-( [08:42] it's testing for content plugs that aren't there for ex [08:42] mborzecki: zyga had a suggestion for the InstanceName doc comment, you +1 it, are you applying it in the PR or when you actually implement the logic in a follow up? [08:43] pedronis: must have missed it, let me push a quick patch [08:43] Chipaca: I think we have grown more features that is fair to stick on hello-world :/ [08:43] pedronis: pff yeah, didn't stage it :( [08:44] pedronis: I know, and it's fine, but that's why there's a "download the json, and then " comment in the tests [08:44] grmbl, grmbl, *AND* grmbl. [08:45] I don't think I ever noticed that [08:45] it's probably/likely partly my fault, sorry [08:46] pstolowski: yeah, let's merge 5288 . [08:46] k, thanks [08:47] PR snapd#5288 closed: tests: econnreset/retry tweaks [08:48] mborzecki: np [08:54] mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5315/files [08:54] PR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErro… [08:54] I applied your suggestion now [08:55] Saviq: yeah, a github issue about the mails is best, thanks. [09:05] popey: https://github.com/canonical-websites/snapcraft.io/issues/729 https://github.com/canonical-websites/snapcraft.io/issues/730 [09:06] thanks Saviq [09:07] PR snapd#5324 opened: snap: run snap-confine from the re-exec location [09:33] life-changing: travis-ci.org##.ansi filter in ublock kills the cpu hungry log window and only leaves 'raw log' button [09:33] mvo: I saw that, I'm making progress on the system interfaces now === boxrick_ is now known as boxrick [09:36] zyga: nice [09:37] mvo: there's one more special case to handle [09:37] Morning mvo zyga [09:38] but we can do the smart thing as well (not touch it) [09:38] base policy [09:38] we should translate system back to core there [09:38] I've been asked by an ISV if it is possible to run snapd in Docker. [09:38] Wimpress: hello, how are you doing sir? [09:38] My frst thought is no, but I "think" I saw someone show me snapd working in Docker. [09:38] Wimpress: from what I know it is maybe possible but we don't test that today. It depends on how docker confines the container [09:39] and also what kind of distro is inside I suppose [09:39] yes, that's also a factor [09:39] So technically possible but not an "out of box" experience? [09:40] zyga: I had a few more thoughts about the "old portals" issue, which I've added to the PR: https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058 [09:40] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [09:41] zyga: in short, I agree that it is a problem but think we might have been overestimating how prevalent it is [09:43] jamesh: thank you for the write up and analysis, I think I tend to agree [09:43] let me think about this today and try to catch jdstrand later to discuss, we will reply there [09:52] pstolowski: couple small comments on the disconnect hooks one [09:58] PR snapd#5325 opened: interfaces: add Repository.AllInterfaces [09:59] pstolowski: https://github.com/snapcore/snapd/pull/5325 [09:59] small helper for upcoming branch [09:59] PR #5325: interfaces: add Repository.AllInterfaces [10:00] jamesh: question out of the blue: do you know how to tell gnome what 'app' a window is from? [10:00] jamesh: or how it does that for non-gnome apps? [10:00] jamesh: snapped apps don't have an 'app' in looking glass, and they don't have an icon, and I suspect it's the same thing [10:01] Chipaca: knowing gnome I'd not be surprised if it used google to search each time you open the activities screen [10:01] zyga: :) [10:01] Chipaca: I'm not sure exactly how gnome-shell links the windows to apps off the top of my head (or if it differs for Wayland vs. X11 apps), sorry. [10:01] The comment said /* Faster than scanning desktop files */ [10:02] jamesh: no problem [10:02] jamesh: I'll continue to ask random people in the street then [10:02] :) [10:02] I know the code in unity7 had some nasty hacks [10:03] * zyga thinks http://blog.lenovo.com/en/blog/the-new-thinkpad-p52/ is crazy cool [10:03] some of which persists in snapd with the BAMF_DESKTOP_FILE_HINT stuff [10:05] jamesh: the BAMF_ thing was to tie it into bamfdaemon, and some older apps also needed to set WMClass [10:05] jamesh: but gnome shell indeed seems to ignore both these things :-) [10:06] Chipaca: can we run gedit and see what it does [10:06] (bamfdaemon, i'm not surprised) [10:06] Chipaca: I suspect the best way to learn is just to observe a real app [10:06] I'd be completely unsurprised if it were something like "the desktop file needs to be named exactly like the binary" [10:06] also saddened [10:06] that is in fact the case AIUI [10:06] right. IIRC, bamfdaemon would read the environment of the process via /proc to look for that variable to make the link [10:07] Chipaca: all bugs are shallow ... eyes... sad... (pours more alcohol) [10:08] popey: do you know if there's a way to override that? [10:08] i do not, I comply [10:08] popey: how? [10:08] maybe the desktop: entry in snapcraft.yaml [10:08] Chipaca: only 20 separate implementations to check :-( [10:08] i always put the .desktop file in snap/gui [10:09] e.g. https://github.com/snapcrafters/opentoonz/tree/master/snap/gui [10:10] PR snapd#5324 closed: snap: run snap-confine from the re-exec location [10:10] popey: let me test that then [10:10] ok, thanks [10:10] would be nice not to have to do it [10:10] (but we always do) [10:13] huh [10:13] well i'll be jiggered [10:13] renaming the desktoop file to kiosceditor_kiosceditor did the trick [10:14] zyga: can you take another look at #5306? [10:14] PR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name [10:15] popey: https://forum.snapcraft.io/t/ubuntu-18-04-and-snap-issues/5832/8?u=chipaca [10:15] <3 [10:17] pedronis: in overlord/snapstate's fakeStore there's a bunch of code that uses a snap's channel to decide what to do [10:17] pedronis: but I'm killing channel (and anychannel) as arguments to snapinfo -- they're not used anywhere in non-test code [10:18] pedronis: do you think it'd be reasonable to give fakeStore an out-of-band way of knowing what's wanted of it? [10:18] mborzecki: sure [10:20] pedronis: (i think i might add channel back just for these tests, and kill it in a followup, as it'll get gnarly) [10:21] PR snapd#5326 opened: api/snapctl: allow -h and --help for regular users [10:23] mborzecki: is instance name and instance key the same thing, can they be used interchangeably? [10:24] zyga: AIUI instance name == name + "_" + key [10:24] zyga: foo_bar, foo_bar === instance name, foo === snap name, bar === instance key [10:25] thanks [10:27] pedronis: #5314 was updated, please take another look [10:27] PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs [10:33] mborzecki: done [10:35] another instance of [10:36] Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Mount process finished, but there is no mount. [10:36] Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Failed with result 'protocol'. [10:36] in mvo's branch [10:55] PR snapd#5324 opened: [RFC] snap: run snap-confine from the re-exec location [11:01] zyga: the snap-confine on core18 is a bit thorny, I wrote some options down in 5324 maybe we can chat after lunch about the pros/cons, nothing seems perfect but maybe the alternative plan in 5324 is worth persuing [11:01] ok, I'm reading your PR now [11:01] the system interfaces approach is clean so far [11:01] not finished yet but very simple what's going on (for now) [11:02] mvo ping [11:03] ondra: pong (but almost at lunch) [11:03] mvo sure, will try to be quick :) [11:03] mborzecki: thanks will look in a little bit [11:03] mvo have I missed something about pi3 kernel and dtb? [11:03] zyga: yeah, its not hard, just feels a bit "uneven" that we need to use different dirs for the profiles on classic and core and to reuse the snap profile dir [11:04] ondra: missed in what sense? I haven't looked at this in a while [11:04] mvo I'm getting a bit confused, so are we free to update kernel as much as we like and dtbs update correctly? [11:04] ondra: well, we unblocked the kernel updates a while ago because the dtb diff was just a single line in a serial port uart freq [11:04] mvo I thought we are not updating dtbs from kernel snap to system-boot at all [11:04] ondra: but of course if this changes and the diff becomes bigger we need to halt things again [11:05] ondra: we are not doing it in snapd, that is correct [11:05] ondra: I mean, we don't copy stuff around into /boot at this point [11:05] ondra: we have no code for this [11:05] mvo so we are not updating dtbs, but rather relying that kernel does not really change there [11:05] ondra: correct [11:06] ondra: yeah, its just so that people get kernel updates but we still have not tackled the dtb update problem [11:06] mvo can you please comment on that forum post? as Gustavo thinks there is no problem to solve, and I do not think this is correct assumption [11:07] ondra: That's not what was written there [11:07] ondra: do you have a link for me? [11:07] mvo: https://forum.snapcraft.io/t/proposal-to-enable-pi2-3-major-kernel-updates/5842/8 [11:07] niemeyer: ta [11:08] mvo: np [11:08] niemeyer you are claiming that we have updates flowing and there is no problem, but clearly we do not have dtb updates flowing [11:09] niemeyer so to me there seems to be mismatch in understanding what is actually updating [11:10] ondra: I specifically said: [11:10] a) The pi2 kernel had a major update just weeks ago, which disagrees with what was presented in the first few sentences [11:10] b) We have a design for dtb updates in place [11:10] c) If your needs are different, they need to be put into that design instead of besides it [11:11] PR snapd#5327 opened: store: switch store.SnapInfo to use the new v2/info endpoint [11:11] pedronis: ^ [11:11] d) If you do critical updates like this in hooks it will likely destroy systems in the future [11:11] e) We should have a meeting to discuss this [11:11] Chipaca: thx, will look [11:11] ondra: Which of these points is incorrect or unreasonable? [11:12] niemeyer I have been talking about this very problem with mvo in Berlin and he told we are still not updating dtbs when we update kernel, [11:12] niemeyer so you are telling we are updating dtbs? [11:12] mvo: is /etc/apparmor.d really read-only on core? [11:12] ondra: I said the pi2 kernel had a major update. Is that true or not? [11:12] zyga: yes [11:13] mvo: I see, well, that's okay [11:13] ondra: You're arguing with things I did not say [11:13] I mean, it's harder but we can manage [11:13] zyga: the trouble is that it has a bunch of subdirs [11:13] zyga: otherwise I would say we just make it writable [11:13] niemeyer was that update carefully crafted in a way it does not require dtb changes and can use old dtbs? [11:14] mvo: if we can move s-c profiles in all the cases to a new place I'm okay with that [11:14] ondra: we checked carefully that the new kernel would work fine with the old dtbs [11:14] niemeyer proposal is targeting issue when dtbs are not updated with kernel updates, you claim there is no such a problem [11:14] mvo: and we can consider deploying snapd.apparmor.service to core too, to be 100% sure that we have freedom here [11:14] niemeyer I do not agree with that [11:14] ondra: Which of the points above says that? [11:15] ondra: In other words, you're saying that yourself.. not me [11:15] zyga: interessting [11:15] mvo: this would allow us to use a directory such as /var/lib/snapd/apparmor/internal or whatever we want [11:15] mvo: and not clash in any wy [11:15] *way [11:15] niemeyer from forum "@ondra My understanding is that we have updates to pi2 boards flowing, and that the dtb problem in that specific case was a red-herring. " [11:15] zyga: I like internal/ [11:15] mvo: or ... [11:15] ondra: Exactly.. we had a pi2 kernel update just weeks ago [11:15] system ;) [11:15] niemeyer so you are saying there is problem [11:15] zyga: heh [11:15] mvo: but anyway, that's besides the point, let me read your branch carefully [11:15] ondra: I said we *DID UPDATE IT* [11:15] niemeyer and I can update kernel freely? [11:16] zyga: I think that is great input, we can probably move it all [11:16] ondra: THis is not theoretical [11:16] mvo: the service is already in place, we should see if we can just enable it (it's harmless) [11:16] niemeyer so you don't see problem that we cannot update dtbs? [11:16] mvo: that is, ship it and enable via the snapd.run-from-snapd-snap service [11:16] ondra: Why are you still making stuff up? [11:16] zyga: we need to extend it to cover system/ as well, right? [11:16] mvo: yes but it is our service [11:16] it's simple to extend [11:17] zyga: cool [11:17] and we can ship it in snapd snap [11:17] niemeyer because you are telling me there is no problem to solve [11:17] ondra: So you hate the blue color? [11:17] and it's a blessed shell script instead of one liner for the purpose of being shellchecked [11:17] zyga: I need to run for lunch, lets catchup afterwards (and/or feel free to write your thoughts into the open PR) [11:17] mvo: sure, go ahead [11:17] niemeyer OK whatever, clearly impossible to talk to you [11:18] ondra: Honestly, this is nuts.. I'm literally saying "let's please have a meeting to discuss your needs" and "if your needs are different let's integrate in the design" [11:18] ondra, niemeyer: I'm sure we are perfectly capable of solving the problem if we talk together, I really recommend that we have a call later today/tomorrow [11:18] zyga: That's literally the first thing I said :) [11:19] perhaps ondra is not aware of the existing plans or there is a technical detail that we are missing [11:19] Quoting: [11:19] """ [11:19] Nevertheless, we already have a design for the proper representation of dtbs that can be updated. Let’s please not cook a different solution without looking at that design first. Even if it’s incomplete for your needs, we should improve on it instead of besides it. Happy to discuss this in our next meeting. [11:19] """ [11:19] * zyga hugs niemeyer and ondra *together* [11:20] anyone looking at interfaces-calendar-service test flakiness? if not, i'll coz it's driving me crazy [11:20] pstolowski: there's a PR from cachio but I don't quite understand how that helps or what the problem is [11:20] pstolowski: I'd recommend diving into it , yeah [11:20] and it seems to happen on all kinds of systems so a small loop with debug would be good [11:20] oh ok, let me first check what did he do [11:20] thank you! [11:22] right.. it seems that retry didn't help, the PR failed on this test again [11:22] interesting [11:23] zyga: i think it's related to gvfs which does fuse internally [11:23] mmm [11:23] mborzecki: yeah, it feels like something is mounted there [11:23] otherwise rm would not fail [11:23] maybe worth trying is to kill gvfsd* in restore [11:23] but that's a long shot anyway :P [11:25] I think we need to reproduce and see what's there [11:26] pstolowski, the retry didn't work? [11:26] cachio: it seems to, your PR failed on travis [11:26] *so [11:29] but failed on a different test [11:29] there are 2 tests failing for the same reason [11:29] calendar and contacts [11:30] pstolowski, I was trying to see what it is locking the files inside [11:31] but when I debug it, it is already unlocked [11:31] cachio: when it fails, can you check if there's anything in that directory (gvfs-metadata) and if there are any gvfs processes alive, if so, kill them === chihchun is now known as chihchun_afk [11:37] mborzecki, running again to see [11:38] ok, i'm off to the kindergarten, bbl [11:40] PR core18#26 closed: hooks: add path [11:41] Chipaca: did a first pass, main point is that I think the helpers merit unit tests (also because the current shape of responses doesn't exercize all corners of them) [11:42] looks good though otherwise [11:53] * Chipaca ~> lunch [11:57] zyga: what did you want to talk about? a snapd-apparmor.service for core? [11:58] jdstrand: I'm not sure, yesterday or today/ [11:58] yesterday I only wanted to ask for a re-review of chopTree PR [11:59] there are some interface PRs in flight but I think those are handled well on elsewhere already [11:59] I'm sorry, I think the answer is "I'm not sure" [11:59] zyga: it seems https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058 [11:59] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [11:59] ah [11:59] yes, that's that! [12:00] so here I tend to agree with James, please think about it and let's discuss in the PR (since James is far away in terms of timezones) [12:00] zyga: but I would caution you on moving snap-confine to internal/. I mean, the idea of that is not bad in and of itself, but understanding why the profiles aren't being loaded in /etc/apparmor.d is important before suggesting a solution [12:00] zyga: do we understand the race/problem there? [12:01] zyga: as in, are we just kicking the can and going to see it happen with internal/ too? [12:01] jdstrand: this is a more subtle question, it is specific to core systems only [12:02] where we cannot write to /etc/apparmor.d [12:02] but need a place to store snap-confine profiles for snapd reexec [12:02] and using /var/lib/snapd/apparmor/profiles was undesired as it would need a new prefix not to clash with snap profiles [12:02] (but we could do that) [12:02] why are we reexecing on core? [12:02] this is the new work on a standalone snapd snap [12:02] where core18 or core16 is used for booting [12:03] but snapd is in a separate snap [12:03] (snapd.snap) [12:03] there's a new protocol for running that [12:03] but it involves writing a profile for snap-confine for a given snapd snap revision [12:03] mvo: I just realised there is a complication [12:03] it still isn't clear. why are we reexecing on core? [12:03] jdstrand: because core18 and core16 don't ship a snapd snap [12:03] er [12:03] snapd itseslf [12:04] I mean, core16 and core18 won't have snapd, so there is nothing to reexec [12:04] this isn't really reexecing, it needs a new name [12:04] so? [12:04] ok [12:04] so we will exec snap-confine from /snap/snapd/123/usr/lib/snapd/snap-confine [12:04] we need to generate a profile for that in snapd [12:04] and we need to store it persistently [12:04] but regardless of what it is called, snapd needs to put a snap-confine profile somewhere [12:04] and load it on boot [12:04] the question is where do we store it [12:04] and /etc/apparmor.d is read only [12:05] and has a host of other things inside that makes it harder for us to use as a sync directory [12:05] this is getting into the territory of why I thought the snapd snap should not be a normal app snap [12:05] it is not a normal app snap [12:05] but a new 'type: snapd' [12:06] ok, then that has evolved. last I heard it was [12:06] (new type is an interesting idea but it's orthogonal, it has special handling already) [12:06] it is not a normal app snap in the sense that it doesn't expose itself as a service [12:06] or snap as an app [12:06] it's all handled externally with snapd.run-from-snapd-snap.service [12:06] popey: remember that xps? something was burnt out getting power to the ram; £65 later i've got an xps [12:07] it is 'type: app' with special-casing. more and more as we go. that is orthogonal, but the more special casing, the more it shouldn't be 'type: app'. it isn't an app. it is a snap from managing and running apps [12:07] s/from/for/ [12:07] anyway [12:07] sure, put it in apparmor/internal, leave cache the same [12:07] jdstrand: ack, thank you [12:08] jdstrand: I agree about making it explicitly special and I think we will over time, this is just a way to hit core18 work on time [12:08] you will then need snapd-apparmor.service [12:09] jdstrand: yes, but as I said, it is just a proposal at this stage [12:09] note, I still consider /etc/apparmor.d as read-only a good property on core [12:09] mvo and I will talk about what the options are and then decide what to pursue [12:09] because it makes it impossible to mess with system policy, tunables and abstractions [12:09] jdstrand: yeah, I think that's fine too, it's just something we were not aware of a short while ago :) [12:10] we actively chose to have /etc/apparmor.d/cache read/write but /etc/apparmor.d read-only [12:10] PR snapd#5328 opened: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead [12:37] 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:38] hmm, indeed, I should look into it [12:39] zyga: thanks [12:39]