[01:22] hey guys [01:22] allah is doing [01:22] sun is not doing allah is doing [01:22] to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [04:48] morphis_: night/morning [04:48] Son_Goku: morning! [04:49] I'm amazed I'm still up [04:50] :-) [04:50] morphis_: https://bugs.launchpad.net/snapd/+bug/1685626 [04:50] Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall [04:51] also, can you talk to someone on the LP team to reactivate rhbz integration? [04:52] I filed a bug about this against LP itself some time ago, but nothing happened... https://bugs.launchpad.net/launchpad/+bug/1678486 [04:52] Bug #1678486: Enable watching Red Hat Bugzilla bugs [04:53] Son_Goku: I can see what I can do [04:53] Son_Goku: to workaround #1685626 we can craft a simple shell script which does that job [04:53] Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall [04:54] Son_Goku: something like what zyga devtools are doing [04:54] ? [04:54] https://github.com/zyga/devtools/blob/master/reset-state#L44 [04:55] ah. I see [04:55] Son_Goku: https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/snapd.postrm [04:56] ... [04:56] that is a horrifying postrm [04:56] also, shouldn't this be prerm? [04:56] otherwise, terrifying things could happen... [04:57] why should it be prerm? [04:58] I mean, I guess if /snap isn't a registered directory to dpkg, it wouldn't matter either way [04:58] but making things disappear on the package manager sounds like a horrible idea [04:58] or the opposite case, preventing the package manager from cleaning up [04:59] that said, given that this is implemented in shellscript in two different places, it sounds like it really should be a command built into snapd [05:00] how would that be different other than that the postrm script would call `snap reset` [05:02] morphis_: consistently implemented? [05:02] though it wouldn't be possible for it to be postrm at that point [05:02] that is the only point, yes [05:02] since /usr/bin/snap would be gone by postrm time [05:02] and that is what make things tricky [05:02] well, that's what prerm is for [05:03] afaik, purge is propagated to prerm [05:03] sure but that might have consequences on the running system etc., however lets not discuss that here right now [05:03] anyway [05:03] I think for fedora we can go with a simple script for now [05:03] yeah [05:03] in the long run we can rework that and make it the same across all distros [05:03] when I'm not completely dead, I'll whip something up for snapd-2.24 [05:03] err [05:03] 2.25 [05:03] assuming it's going to be tagged this week or something [05:03] ok [05:04] Son_Goku: I am currently fixing all the failing unit tests on Fedora [05:04] if not, I'll put it together for snapd-2.24 [05:04] morphis_: okay :D [05:04] so patch for that is coming [05:04] excellent [05:04] sadly too late for 2.25 [05:04] as long as it gets merged into master, I don't mind carrying it for a release or two [05:06] morphis_, it might be able to land for 2.25 [05:06] the milestone isn't even halfway done [05:07] Son_Goku: the milestone is always in flux :-) [05:08] anyway, snapd 2.24 has propagated out to all Fedora releases [05:09] so when JamieBennett is preparing the announcement, he can announce both Fedora and Ubuntu at once [05:17] Son_Goku: nice! [05:17] whether he does... I dunno [05:17] Son_Goku: he will for sure :-) [05:32] morphis_, so I finally blew my top: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/75?u=conan_kudo [07:04] good morning [07:05] gurgle [07:07] Son_Goku: hey [07:07] Son_Goku: FWIW I agree on xdg-open [07:08] Son_Goku: not on the repo, one repo is convenient, but on the approach used [07:09] I am not looking forward to the day when the security team or the core dev team stops being able to understand where one ends and the other begins [07:10] morning [07:21] hmm, we seem to have a lot of DNS issues in linode [07:21] dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:34462->[::1]:53: read: connection refused [07:22] fgimenez: I saw you commented about this on the forum, do you have any idea what he cause may be? [07:22] zyga: nope, it started happening last week [07:24] fgimenez: maybe it is related to the rollout of the new store? [07:24] zyga, morphis_, I'm going to sleep now. I've been up for almost a whole day... [07:25] JamieBennett, snapd-2.24 is available in all released Fedora versions [07:25] Son_Goku: Awesome! [07:25] I would appreciate it if the formal snapd 2.24 announcement also included a blurb about Fedora alongside the typical Ubuntu stuff [07:25] zyga: maybe, i think that the first errors of this kind appeared last friday at ~ 5:00 utc, that's after the rollout right? [07:25] Son_Goku: Will do, thanks [07:26] Son_Goku: take care! thank you for everything! [07:26] JamieBennett, it was supposed to sync out Friday, but the Red Hat datacenter had a massive network outage [07:26] Son_Goku: I'll make sure it does :) [07:26] infra came back online Saturday, and everything sync'd out Sunday :) [07:27] anyway, must sleep, I have work in 6 hours! [07:27] Good whatever time of day it is for you guys. When I use shutdown interface - should I also use dbus plug to allow my snap to interact with systemd's dbus API or is interface enough by itself? [07:27] thanks Son_Goku [07:27] JamieBennett: you're welcome [07:27] sborovkov: checking [07:28] sborovkov: shutdown is enough, it lets you talk to systemd /logind [07:28] thanks [07:30] mvo: hey, about the repair assertion, can you tell me what you think about the idea to have wildcard support in the model field? [07:30] zyga: fixing the dns issue [07:31] zyga: that is leftover from trying to get a handle on the systemd bug we talked about friday [07:31] mvo: thanks! so it is a bug on our end! [07:31] mvo: ah, right [07:31] mvo: I recall you synced the real package [07:31] JamieBennett: do you want me to update https://forum.snapcraft.io/t/draft-snapd-2-24-available/245 with some lines about fedora or will you use a different draft for the announcement? [07:31] zyga: yeah, I reuploaded a "fixed" package that removes the offending patch [07:32] zyga: wildcard is fine [07:32] mvo: I was thinking if the assertion system supports such constructs [07:32] zyga: I think we shoudl do that, I will look into the repair assertion again now, add some more meat beside the assertion [07:32] (or tofu) [07:32] mvo: but I think that a wildcard is mandatory otherwise, I don't think it is sensible to issue lots of assertions for a common issue [07:32] haha, I love tofu [07:33] zyga: sure, the wildcard is nice. at the same time, there is still a lot to do, the wildcard is something I'm not super concerned about. we can always simulate that using the body script itself by doing a check via bash [07:34] zyga: I guess I'm trying to say that I don't consider it a blocker :) [07:34] mvo: that post is what I will use for the announcement so feel free to update it [07:34] JamieBennett: thanks, will do [07:35] mvo: good point about that [07:36] mvo: though shell scripting wise I think it's hard to ask snapd which model it is [07:36] zyga: yes, this is a good point, we should make this easier [07:37] zyga: actually snap known model should work [07:37] * mvo checks [07:37] mvo: yes but not unique [07:38] mvo: you can snap ack more models [07:38] zyga: indeed. anyway, I think we are in agreement, this will come [07:38] o/ [07:38] hey Chipaca, good morning! [07:38] Chipaca: morning, how are you feeling today? [07:39] mvo— morning! how's things? [07:39] zyga— a'ight! just a pesky cough left now \o/ [07:39] zyga— how are you? [07:40] good, returning home after school drop [07:40] Chipaca: all going well [07:41] Chipaca: I didn't find anything wrong in the tab-completion code, I will approve it soon [07:41] woo [07:44] * zyga walks home now, brb [08:07] mvo: I have some good news and some casual news, with the idea from last week I moved to the last problem in update-ns bag, that of shadowed mounts [08:08] zyga_: nice! [08:08] mvo: but I also wonder if this is something that is an actual blocker, I will try to land existing branches and move on to integration in snapd (so that it runs automatically) [08:08] mvo: and spread testing [08:08] mvo: the limited use cases of content so far should not be affected by this problem [08:08] mvo: (though theoretically they can) [08:09] mvo: but I want to see how this functions in the wild before we go and solve another non-trivial problem [08:09] mvo, hey! it would great to land #3197, are you still tweaking it? [08:09] zyga_: when can this happen? only if snaps do manual (out-of-band) mounts? [08:10] mvo: I'd like to land https://github.com/snapcore/snapd/pull/3138 [08:10] PR snapd#3138: interfaces/mount: add Change.Perform [08:10] pstolowski: should be ready, looked like there is a test failure, I need to lookwhat is going on [08:10] mvo: and https://github.com/snapcore/snapd/pull/3216 [08:10] PR snapd#3216: cmd/snap-update-ns: add actual implementation [08:10] mvo: I'll iterate to make tests green there, not sure why the first one failed (probably not related to the change) [08:11] zyga_: I am building a new core now, once that is finished we should have working tests again (the systemd change is then removed again) [08:12] zyga_: I have a look. I would also really like to see gustavo looking at this at some point but maybe this will happen today, he said he will want to do a review day on the 2.25 branches [08:13] mvo: so no luck with fixing the problem and getting pairty with xenial systemd? === zyga_ is now known as zyga [08:14] zyga: no, unfortunately not yet, there is one patch that we need to remove otherwise things fall apart on core [08:14] zyga: it seems to be a bit of a can of worms as I am only able to reproduce on linode, not in qemu [08:15] zyga: plus only on core and running core tests takes some extra time because of the setup it needs to do first etc. its a bit of PITA. [08:19] mvo: did you see the question from slangasek, about cloud-init? [08:23] zyga: I did but I did but I did not think about this yet. the ubuntu-core image disables cloud init and the errors happen inside the ubuntu-core image so I suspect cloud-init is not at play here but this is not well researched yet [08:55] mvo: is the new core built? [08:56] PR snapd#3220 opened: many: implement snap prefer (aliases v2) [08:56] zyga: yes, let me check if the store has it already [08:57] pedronis: what is "snap prefer"? [08:58] zyga: if there are conflicts enable the aliases of this snap and disable the aliases of conflicting ones [08:58] zyga: new core should be ready [08:59] mvo: thank you [08:59] pedronis: aha, I see [08:59] pedronis: interesting concept, so snaps can disagree on aliases [08:59] not snaps [08:59] pedronis: that's pretty cool as people will have their preferences [08:59] but yes in theory the store can give the same alias to more than one snap [08:59] ah? those are user aliaes only? [09:00] no, auto aliases [09:00] I mean the command will disable manual aliases, but there's no memory of manual aliases, they are either there or not [09:01] atm we have no such conflicts in the store fwiw [09:04] PR snapd#3216 closed: cmd/snap-update-ns: add actual implementation [09:06] morphis_— did you get to have a look at snapd#2969 as jdstrand requested way back when? [09:06] PR snapd#2969: interfaces: mediate netlink sockets via seccomp [09:08] jdstrand: Hi. Btw I am getting similar issue with dbus, I was getting when using pydbus before. When using shutdown interface I am getting "apparmor denied" because pydbus tries to do introspection :-( https://hastebin.com/inohabofad.vbs [09:09] sborovkov: aha, interesting [09:09] sborovkov: I think introspection should be allowed by default [09:10] fgimenez— as I count them snapd#3014 now has two +1's so it's gtg [09:10] PR snapd#3014: tests: add dbus interface spread test [09:10] Chipaca: not really [09:10] sborovkov: can you pastebin 'dmes | grep DENIED\ [09:11] zyga: [ 5560.678149] audit: type=1107 audit(1493024823.398:2127): pid=1037 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/login1" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.login1" pid=29564 label="snap.screenly-client.ping" peer_pid=1032 peer_label="unconfined" [09:11] sborovkov: thanks [09:12] zyga: is dbus-send command available from inside the snap? going to just call it manually from python as a workaround for now [09:12] sborovkov: you can add it to your snap [09:12] Chipaca: but added on my list for today [09:12] zyga: understood. [09:12] sborovkov: I think dbus introspection isn't allowed by the interface yet [09:13] snapd#3018 is short and sweet and needs a second review [09:13] PR snapd#3018: tests: add empty initrd failover test [09:15] morphis_: yeah I noticed. I am using pydbus though. It does not work without it. Couple of weeks ago I could not even get SystemBus(). Jdstrand added rule that allows introspection on itself which fixed the issue. [09:15] That seems pretty similar [09:15] sborovkov: was that for a different service? [09:15] Chipaca: about snapd#3014 yep, assuming mvo's review is an actual +1 yes, gtg [09:15] PR snapd#3014: tests: add dbus interface spread test [09:16] fgimenez— I read it that way [09:16] zyga— you seem to have an unaddressed comment from gustavo on snapd#3026, correct? [09:16] PR snapd#3026: cmd/snap-confine: use defensive argument parser [09:17] morphis_: well the issue was that you could not even obtain system bus in pydbus. It was doing introspection on itself. Just simple code bus = pydbus.SystemBus() [09:18] sborovkov: ok, for the systemd service you should be fine doing a direct call to the relevant method without introspection [09:18] morphis_: I think that introspection should be open by default [09:18] zyga: sure [09:19] morphis_: the problem is that pydbus uses introspection to know what methods are allowed and what the types are [09:19] zyga: however it needs to be activated for every service individually with our current setup [09:19] zyga: there is no way in pydbus to do an explicit dbus method call without introspection? [09:21] fgimenez: indeed, that was a +1 [09:21] mvo: great, thanks! [09:21] PR snapd#3014 closed: tests: add dbus interface spread test [09:26] PR snapd#3215 closed: tests: address review comments from #3186 [09:27] morphis_: everything is possible but perhaps a bit too hard [09:27] morphis_: I worked on pydbus extensions and I think it'd be just annoying to add [09:27] morphis_: I think we can allow introspection on all objects on all paths [09:27] morphis_: it's the interface that's constant [09:27] can somebody take a look at #3208? we need 2nd review, and it looks safe/non-controversial.. [09:28] pstolowski: thanks :) [09:28] zyga, any time ;) [09:29] * zyga has a headache today, wind kept waking me up all night [09:29] I'm adding spread tests for update-ns [09:33] speaking about spread tests... #3205 also needs 2nd review and should be safe to land [09:36] zyga: sure, but that would mean for 2.26 which may be too late for sborovkov [09:38] morphis_— 3205 is on the first page, not there yet [09:41] morphis_: I'll just use more simple lib for now :-) The one that does not require introspection [09:43] sborovkov: sounds good [09:52] pstolowski— what's snapd#3119 waiting for? [09:52] PR snapd#3119: interfaces: API additions for interface hooks [09:53] Chipaca, needs review from niemeyer [09:53] niemeyer needs a manager to play interference on him so he can get to all these PRs :-) [09:54] s/on/for/ [09:54] * Chipaca was not offering [09:55] zyga— you requested changes on snapd#3136 but have not re-reviewed [09:55] PR snapd#3136: snap-confine: add code to ensure that / or /snap is mounted "shared" [10:02] Chipaca: I know, we're waiting for the locking branch to land [10:03] Chipaca: so that mvo can use the new locking primitives [10:03] Chipaca: (or I can push a small change that uses them) [10:03] Chipaca: curiously the locking branch needs a 2nd review (mvo +1d it) [10:03] curious, curious [10:04] Chipaca: very :) [10:05] * zyga is in a slightly better mood as headache is wearing off [10:05] I need to fix some of the blinds to avoid wind rattling everything [10:07] zyga— next time, don't have your office inside a moored zeppelin [10:23] very steampunk of him [10:29] PR snapd#3221 opened: snap-repair: add `snap-repair run` [10:30] zyga could totally rock the steampunk mad scientist thing [10:43] pstolowski: question [10:43] pstolowski: so let's say we have connect [10:43] pstolowski: and connect hooks run [10:43] pstolowski: when should we correct the mount namespace [10:43] pstolowski: I'd say we should correct the mount namespace before the connect- hook runs the mount namespace must be already adjusted [10:52] zyga— snapd#3141 is green and you looked at it but didn't actually review it [10:52] PR snapd#3141: many: show available "tracks" in `snap info` [10:54] mup— you should totally use colours to include status for some of these things [10:56] PR snapd#3222 opened: many: fix test cases to work with different DistroLibExecDir [10:56] zyga: ^^ === morphis_ is now known as morphis [10:59] gah, https://forum.snapcraft.io/t/cant-install-snap-app/376/2 is another one of those "nil map" panics [11:00] Chipaca: https://github.com/snapcore/snapd/pull/3223 [11:00] PR snapd#3223: systemd: mount squashfs as read-only [11:00] Chipaca: is that the fixed one? [11:01] zyga— I think it was fixed, but I don't know where -- maybe you know more [11:01] PR snapd#3223 opened: systemd: mount squashfs as read-only [11:01] Chipaca: content.go one [11:01] Chipaca: and one more reason to review and land https://github.com/snapcore/snapd/pull/3208 [11:01] PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots [11:01] * zyga brb [11:02] Pharaoh_Atem: https://paste.fedoraproject.org/paste/Oy3r7PpWM9E19LSsBYNYHV5M1UNdIGYhyRLivL9gydE= [11:03] zyga— where are you seeing 'rw' next to a squash mount? [11:10] Chipaca: curious, now I don't [11:10] zyga— what about in 'snap try'? [11:11] let me dig because I'm sure I didn't write that patch out of the blue [11:11] Chipaca: no, I didn't try snap try [11:11] (and that's a good point) [11:11] ahq [11:11] aha [11:11] 665 658 7:7 / /snap/lonewolf/3 rw,relatime master:32 - squashfs /dev/loop7 ro [11:11] Chipaca: look at mountinfo [11:12] Chipaca: it is obviously confusing [11:12] Chipaca: there are two sets of options [11:12] Chipaca: mount options, where I do see rw, and superblock options where we see ro [11:13] Chipaca: obviously my patch means little (except for kernel bugs, if any) because the filesystem is readonly [11:13] Chipaca: but we were mounting a read-only filesystem without the read-only flag as you can see above [11:13] yeah [11:13] zyga— mount (at least the command) seems to have special-handling of known-ro filesystems like isowhatsit [11:14] Chipaca: are you sure? (I'm curious, I don't know) [11:14] Chipaca: I assumed that mount just looked at /proc/mounts [11:14] Chipaca: that shows less information [11:14] zyga— mount: /dev/loop5 is write-protected, mounting read-only [11:14] Chipaca: aha [11:14] Chipaca: well, I bet you could force-mount ext4 on top of the same loop device [11:15] so perhaps mount itself does the right stuff early on when it allocates a loopback device [11:15] zyga— in any case my question about try stands [11:16] ah, try doesn't have fstype=squash i guess? [11:16] zyga— but, would having ro,bind there work? [11:16] 'cause that would be good i think [11:16] Chipaca: yes, it would [11:16] make try more like the real thing from the outside [11:16] Chipaca: I didn't touch that part of the problem [11:17] Chipaca: when you try you get writable $SNAP (which is very odd) [11:17] mvo, hi, I hve this small fix for Core: http://people.canonical.com/~abeato/snappy/fix-wpa-conf-typo.diff [11:18] abeato: nice catch [11:18] abeato: can you propose that to github.com/snapcore/core [11:19] zyga, sure, is that the official way for proposing changes to core? [11:19] abeato: some things are still debs so changes there are made in the regular unregular way [11:19] abeato: but anything else, yes [11:19] zyga, got it, thanks [11:24] morphis— snapd#3156 has spread failures that i *think* are relevant to the branch itself [11:24] PR snapd#3156: many: support debian in our CI [11:25] zyga, hm, it does not look like that repo contains /lib/systemd/system/wpa_supplicant.service.d/snap.conf , maybe the debdiff is still needed for this change? [11:25] Chipaca: I know, and they are specific to that branch [11:25] abeato: aha, I think ogra_ is the one to know where this part goes [11:26] zyga, abeato: it goes into the ubuntu-core-conf deb in the image ppa [11:26] morphis— yup. I think the one from tests/main/completion is caused by whatever is causing the failure of tests/main/snap-sign [11:26] abeato, https://github.com/snapcore/core-build/ [11:27] morphis, ^^^ [11:27] initrd is landing there too (once i get PR reviews) [11:27] ogra_: thanks! [11:27] ogra_: is that the new origin of ubuntu-core-conf? [11:27] morphis, right [11:27] ogra_, ok, thanks [11:27] ogra_: that misses things [11:27] morphis, and will soon also be the upstream branch for initramfs-tools-ubuntu-core [11:28] ogra_: the .deb in the ppa has a wpa-supplicant.service.d directory in https://github.com/snapcore/core-build/tree/master/config/lib/systemd/system [11:28] ogra_, yeah, not in that repo :) ^^ [11:28] ogra_: so looks like something is broken [11:29] morphis, hmm, that was reviewed against the package source before it landed (i even had to re-do the PR because mvo found issues) [11:29] we dropped 3 obsolete bits ... but nothing wpa related [11:30] * ogra_ checks the PPA [11:30] ogra_: https://launchpadlibrarian.net/310101186/ubuntu-core-config_0.6.40+ppa42_0.6.40+ppa43.diff.gz [11:32] ogra_, /lib/systemd/system/snapd.generate-network-conf.service is missing too in the gihub repo [11:32] morphis, hmm, looks like mvo "just uploaded" ... [11:32] abeato, yeah [11:32] ogra_: the wpa thing is there for quite a long time [11:33] ogra_: ok, not that long but over a month: Wed, 08 Mar 2017 09:22:16 +0100 [11:33] not sure since when the git repo exists [11:34] morphis, march 29 [11:37] Chipaca: one more tweak https://github.com/snapcore/snapd/pull/3224 [11:37] PR snapd#3224: interfaces/mount: write current fstab files with mode 0644 [11:37] PR snapd#3224 opened: interfaces/mount: write current fstab files with mode 0644 [11:37] zyga— i'll get to it in a bit [11:37] i'm going to go have lunch [11:37] zyga— do reviews! [11:37] Chipaca: I should oto [11:37] too [11:38] morphis, looks like a mid-air crash ... http://paste.ubuntu.com/24447438/ [11:38] zyga— yes. [11:38] morphis, i'll adjust the branch [11:38] ogra_: thanks! [11:39] morphis, abeato ... please use the branch in the furture (indeed) ... [11:39] ogra_: +1 [11:45] zyga, yes, +1. the idea was that connect- hooks are executed after connection is set up and with correct security profiles are in place [11:45] zyga, as opposed to prepare- hooks [11:48] pstolowski: thanks for confirming that, I will make sure that this happens [11:48] PR core-build#7 opened: Sync deb