| chatter29 | hey guys | 01:22 |
|---|---|---|
| chatter29 | allah is doing | 01:22 |
| chatter29 | sun is not doing allah is doing | 01:22 |
| chatter29 | 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 | 01:22 |
| Son_Goku | morphis_: night/morning | 04:48 |
| morphis_ | Son_Goku: morning! | 04:48 |
| Son_Goku | I'm amazed I'm still up | 04:49 |
| morphis_ | :-) | 04:50 |
| Son_Goku | morphis_: https://bugs.launchpad.net/snapd/+bug/1685626 | 04:50 |
| mup | Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall <cross-distro> <snapd:New> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1685626> | 04:50 |
| Son_Goku | also, can you talk to someone on the LP team to reactivate rhbz integration? | 04:51 |
| Son_Goku | I filed a bug about this against LP itself some time ago, but nothing happened... https://bugs.launchpad.net/launchpad/+bug/1678486 | 04:52 |
| mup | Bug #1678486: Enable watching Red Hat Bugzilla bugs <Launchpad itself:New> <https://launchpad.net/bugs/1678486> | 04:52 |
| morphis_ | Son_Goku: I can see what I can do | 04:53 |
| morphis_ | Son_Goku: to workaround #1685626 we can craft a simple shell script which does that job | 04:53 |
| mup | Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall <cross-distro> <snapd:New> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1685626> | 04:53 |
| morphis_ | Son_Goku: something like what zyga devtools are doing | 04:54 |
| Son_Goku | ? | 04:54 |
| morphis_ | https://github.com/zyga/devtools/blob/master/reset-state#L44 | 04:54 |
| Son_Goku | ah. I see | 04:55 |
| morphis_ | Son_Goku: https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/snapd.postrm | 04:55 |
| Son_Goku | ... | 04:56 |
| Son_Goku | that is a horrifying postrm | 04:56 |
| Son_Goku | also, shouldn't this be prerm? | 04:56 |
| Son_Goku | otherwise, terrifying things could happen... | 04:56 |
| morphis_ | why should it be prerm? | 04:57 |
| Son_Goku | I mean, I guess if /snap isn't a registered directory to dpkg, it wouldn't matter either way | 04:58 |
| Son_Goku | but making things disappear on the package manager sounds like a horrible idea | 04:58 |
| Son_Goku | or the opposite case, preventing the package manager from cleaning up | 04:58 |
| Son_Goku | 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 | 04:59 |
| morphis_ | how would that be different other than that the postrm script would call `snap reset` | 05:00 |
| Son_Goku | morphis_: consistently implemented? | 05:02 |
| Son_Goku | though it wouldn't be possible for it to be postrm at that point | 05:02 |
| morphis_ | that is the only point, yes | 05:02 |
| Son_Goku | since /usr/bin/snap would be gone by postrm time | 05:02 |
| morphis_ | and that is what make things tricky | 05:02 |
| Son_Goku | well, that's what prerm is for | 05:02 |
| Son_Goku | afaik, purge is propagated to prerm | 05:03 |
| morphis_ | sure but that might have consequences on the running system etc., however lets not discuss that here right now | 05:03 |
| Son_Goku | anyway | 05:03 |
| morphis_ | I think for fedora we can go with a simple script for now | 05:03 |
| Son_Goku | yeah | 05:03 |
| morphis_ | in the long run we can rework that and make it the same across all distros | 05:03 |
| Son_Goku | when I'm not completely dead, I'll whip something up for snapd-2.24 | 05:03 |
| Son_Goku | err | 05:03 |
| Son_Goku | 2.25 | 05:03 |
| Son_Goku | assuming it's going to be tagged this week or something | 05:03 |
| morphis_ | ok | 05:03 |
| morphis_ | Son_Goku: I am currently fixing all the failing unit tests on Fedora | 05:04 |
| Son_Goku | if not, I'll put it together for snapd-2.24 | 05:04 |
| Son_Goku | morphis_: okay :D | 05:04 |
| morphis_ | so patch for that is coming | 05:04 |
| Son_Goku | excellent | 05:04 |
| morphis_ | sadly too late for 2.25 | 05:04 |
| Son_Goku | as long as it gets merged into master, I don't mind carrying it for a release or two | 05:04 |
| Son_Goku | morphis_, it might be able to land for 2.25 | 05:06 |
| Son_Goku | the milestone isn't even halfway done | 05:06 |
| morphis_ | Son_Goku: the milestone is always in flux :-) | 05:07 |
| Son_Goku | anyway, snapd 2.24 has propagated out to all Fedora releases | 05:08 |
| Son_Goku | so when JamieBennett is preparing the announcement, he can announce both Fedora and Ubuntu at once | 05:09 |
| morphis_ | Son_Goku: nice! | 05:17 |
| Son_Goku | whether he does... I dunno | 05:17 |
| morphis_ | Son_Goku: he will for sure :-) | 05:17 |
| Son_Goku | morphis_, so I finally blew my top: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/75?u=conan_kudo | 05:32 |
| zyga | good morning | 07:04 |
| Son_Goku | gurgle | 07:05 |
| zyga | Son_Goku: hey | 07:07 |
| zyga | Son_Goku: FWIW I agree on xdg-open | 07:07 |
| zyga | Son_Goku: not on the repo, one repo is convenient, but on the approach used | 07:08 |
| Son_Goku | 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:09 |
| pstolowski | morning | 07:10 |
| zyga | hmm, we seem to have a lot of DNS issues in linode | 07:21 |
| zyga | dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:34462->[::1]:53: read: connection refused | 07:21 |
| zyga | fgimenez: I saw you commented about this on the forum, do you have any idea what he cause may be? | 07:22 |
| fgimenez | zyga: nope, it started happening last week | 07:22 |
| zyga | fgimenez: maybe it is related to the rollout of the new store? | 07:24 |
| Son_Goku | zyga, morphis_, I'm going to sleep now. I've been up for almost a whole day... | 07:24 |
| Son_Goku | JamieBennett, snapd-2.24 is available in all released Fedora versions | 07:25 |
| JamieBennett | Son_Goku: Awesome! | 07:25 |
| Son_Goku | I would appreciate it if the formal snapd 2.24 announcement also included a blurb about Fedora alongside the typical Ubuntu stuff | 07:25 |
| fgimenez | 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 |
| JamieBennett | Son_Goku: Will do, thanks | 07:25 |
| zyga | Son_Goku: take care! thank you for everything! | 07:26 |
| Son_Goku | JamieBennett, it was supposed to sync out Friday, but the Red Hat datacenter had a massive network outage | 07:26 |
| zyga | Son_Goku: I'll make sure it does :) | 07:26 |
| Son_Goku | infra came back online Saturday, and everything sync'd out Sunday :) | 07:26 |
| Son_Goku | anyway, must sleep, I have work in 6 hours! | 07:27 |
| sborovkov | 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 |
| JamieBennett | thanks Son_Goku | 07:27 |
| Son_Goku | JamieBennett: you're welcome | 07:27 |
| zyga | sborovkov: checking | 07:27 |
| zyga | sborovkov: shutdown is enough, it lets you talk to systemd /logind | 07:28 |
| sborovkov | thanks | 07:28 |
| zyga | 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 |
| mvo | zyga: fixing the dns issue | 07:30 |
| mvo | zyga: that is leftover from trying to get a handle on the systemd bug we talked about friday | 07:31 |
| zyga | mvo: thanks! so it is a bug on our end! | 07:31 |
| zyga | mvo: ah, right | 07:31 |
| zyga | mvo: I recall you synced the real package | 07:31 |
| mvo | 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 |
| mvo | zyga: yeah, I reuploaded a "fixed" package that removes the offending patch | 07:31 |
| mvo | zyga: wildcard is fine | 07:32 |
| zyga | mvo: I was thinking if the assertion system supports such constructs | 07:32 |
| mvo | 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 |
| mvo | (or tofu) | 07:32 |
| zyga | 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 |
| zyga | haha, I love tofu | 07:32 |
| mvo | 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:33 |
| mvo | zyga: I guess I'm trying to say that I don't consider it a blocker :) | 07:34 |
| JamieBennett | mvo: that post is what I will use for the announcement so feel free to update it | 07:34 |
| mvo | JamieBennett: thanks, will do | 07:34 |
| zyga | mvo: good point about that | 07:35 |
| zyga | mvo: though shell scripting wise I think it's hard to ask snapd which model it is | 07:36 |
| mvo | zyga: yes, this is a good point, we should make this easier | 07:36 |
| mvo | zyga: actually snap known model should work | 07:37 |
| * mvo checks | 07:37 | |
| zyga | mvo: yes but not unique | 07:37 |
| zyga | mvo: you can snap ack more models | 07:38 |
| mvo | zyga: indeed. anyway, I think we are in agreement, this will come | 07:38 |
| Chipaca | o/ | 07:38 |
| mvo | hey Chipaca, good morning! | 07:38 |
| zyga | Chipaca: morning, how are you feeling today? | 07:38 |
| Chipaca | mvo— morning! how's things? | 07:39 |
| Chipaca | zyga— a'ight! just a pesky cough left now \o/ | 07:39 |
| Chipaca | zyga— how are you? | 07:39 |
| zyga | good, returning home after school drop | 07:40 |
| mvo | Chipaca: all going well | 07:40 |
| zyga | Chipaca: I didn't find anything wrong in the tab-completion code, I will approve it soon | 07:41 |
| Chipaca | woo | 07:41 |
| * zyga walks home now, brb | 07:44 | |
| zyga_ | 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:07 |
| mvo | zyga_: nice! | 08:08 |
| zyga_ | 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 |
| zyga_ | mvo: and spread testing | 08:08 |
| zyga_ | mvo: the limited use cases of content so far should not be affected by this problem | 08:08 |
| zyga_ | mvo: (though theoretically they can) | 08:08 |
| zyga_ | mvo: but I want to see how this functions in the wild before we go and solve another non-trivial problem | 08:09 |
| pstolowski | mvo, hey! it would great to land #3197, are you still tweaking it? | 08:09 |
| mvo | zyga_: when can this happen? only if snaps do manual (out-of-band) mounts? | 08:09 |
| zyga_ | mvo: I'd like to land https://github.com/snapcore/snapd/pull/3138 | 08:10 |
| mup | PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138> | 08:10 |
| mvo | pstolowski: should be ready, looked like there is a test failure, I need to lookwhat is going on | 08:10 |
| zyga_ | mvo: and https://github.com/snapcore/snapd/pull/3216 | 08:10 |
| mup | PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216> | 08:10 |
| zyga_ | mvo: I'll iterate to make tests green there, not sure why the first one failed (probably not related to the change) | 08:10 |
| mvo | 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:11 |
| mvo | 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:12 |
| zyga_ | mvo: so no luck with fixing the problem and getting pairty with xenial systemd? | 08:13 |
| === zyga_ is now known as zyga | ||
| mvo | zyga: no, unfortunately not yet, there is one patch that we need to remove otherwise things fall apart on core | 08:14 |
| mvo | 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:14 |
| mvo | 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:15 |
| zyga | mvo: did you see the question from slangasek, about cloud-init? | 08:19 |
| mvo | 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:23 |
| zyga | mvo: is the new core built? | 08:55 |
| mup | PR snapd#3220 opened: many: implement snap prefer <snap> (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220> | 08:56 |
| mvo | zyga: yes, let me check if the store has it already | 08:56 |
| zyga | pedronis: what is "snap prefer"? | 08:57 |
| pedronis | zyga: if there are conflicts enable the aliases of this snap and disable the aliases of conflicting ones | 08:58 |
| mvo | zyga: new core should be ready | 08:58 |
| zyga | mvo: thank you | 08:59 |
| zyga | pedronis: aha, I see | 08:59 |
| zyga | pedronis: interesting concept, so snaps can disagree on aliases | 08:59 |
| pedronis | not snaps | 08:59 |
| zyga | pedronis: that's pretty cool as people will have their preferences | 08:59 |
| pedronis | but yes in theory the store can give the same alias to more than one snap | 08:59 |
| zyga | ah? those are user aliaes only? | 08:59 |
| pedronis | no, auto aliases | 09:00 |
| pedronis | I mean the command will disable manual aliases, but there's no memory of manual aliases, they are either there or not | 09:00 |
| pedronis | atm we have no such conflicts in the store fwiw | 09:01 |
| mup | PR snapd#3216 closed: cmd/snap-update-ns: add actual implementation <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3216> | 09:04 |
| Chipaca | morphis_— did you get to have a look at snapd#2969 as jdstrand requested way back when? | 09:06 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 09:06 |
| sborovkov | 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:08 |
| zyga | sborovkov: aha, interesting | 09:09 |
| zyga | sborovkov: I think introspection should be allowed by default | 09:09 |
| Chipaca | fgimenez— as I count them snapd#3014 now has two +1's so it's gtg | 09:10 |
| mup | PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014> | 09:10 |
| morphis_ | Chipaca: not really | 09:10 |
| zyga | sborovkov: can you pastebin 'dmes | grep DENIED\ | 09:10 |
| sborovkov | 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 |
| zyga | sborovkov: thanks | 09:11 |
| sborovkov | 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 |
| zyga | sborovkov: you can add it to your snap | 09:12 |
| morphis_ | Chipaca: but added on my list for today | 09:12 |
| sborovkov | zyga: understood. | 09:12 |
| morphis_ | sborovkov: I think dbus introspection isn't allowed by the interface yet | 09:12 |
| Chipaca | snapd#3018 is short and sweet and needs a second review | 09:13 |
| mup | PR snapd#3018: tests: add empty initrd failover test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3018> | 09:13 |
| sborovkov | 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 |
| sborovkov | That seems pretty similar | 09:15 |
| morphis_ | sborovkov: was that for a different service? | 09:15 |
| fgimenez | Chipaca: about snapd#3014 yep, assuming mvo's review is an actual +1 yes, gtg | 09:15 |
| mup | PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014> | 09:15 |
| Chipaca | fgimenez— I read it that way | 09:16 |
| Chipaca | zyga— you seem to have an unaddressed comment from gustavo on snapd#3026, correct? | 09:16 |
| mup | PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026> | 09:16 |
| sborovkov | 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:17 |
| morphis_ | sborovkov: ok, for the systemd service you should be fine doing a direct call to the relevant method without introspection | 09:18 |
| zyga | morphis_: I think that introspection should be open by default | 09:18 |
| morphis_ | zyga: sure | 09:18 |
| zyga | morphis_: the problem is that pydbus uses introspection to know what methods are allowed and what the types are | 09:19 |
| morphis_ | zyga: however it needs to be activated for every service individually with our current setup | 09:19 |
| morphis_ | zyga: there is no way in pydbus to do an explicit dbus method call without introspection? | 09:19 |
| mvo | fgimenez: indeed, that was a +1 | 09:21 |
| fgimenez | mvo: great, thanks! | 09:21 |
| mup | PR snapd#3014 closed: tests: add dbus interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3014> | 09:21 |
| mup | PR snapd#3215 closed: tests: address review comments from #3186 <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3215> | 09:26 |
| zyga | morphis_: everything is possible but perhaps a bit too hard | 09:27 |
| zyga | morphis_: I worked on pydbus extensions and I think it'd be just annoying to add | 09:27 |
| zyga | morphis_: I think we can allow introspection on all objects on all paths | 09:27 |
| zyga | morphis_: it's the interface that's constant | 09:27 |
| pstolowski | can somebody take a look at #3208? we need 2nd review, and it looks safe/non-controversial.. | 09:27 |
| zyga | pstolowski: thanks :) | 09:28 |
| pstolowski | zyga, any time ;) | 09:28 |
| * zyga has a headache today, wind kept waking me up all night | 09:29 | |
| zyga | I'm adding spread tests for update-ns | 09:29 |
| pstolowski | speaking about spread tests... #3205 also needs 2nd review and should be safe to land | 09:33 |
| morphis_ | zyga: sure, but that would mean for 2.26 which may be too late for sborovkov | 09:36 |
| Chipaca | morphis_— 3205 is on the first page, not there yet | 09:38 |
| sborovkov | morphis_: I'll just use more simple lib for now :-) The one that does not require introspection | 09:41 |
| morphis_ | sborovkov: sounds good | 09:43 |
| Chipaca | pstolowski— what's snapd#3119 waiting for? | 09:52 |
| mup | PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119> | 09:52 |
| pstolowski | Chipaca, needs review from niemeyer | 09:53 |
| Chipaca | niemeyer needs a manager to play interference on him so he can get to all these PRs :-) | 09:53 |
| Chipaca | s/on/for/ | 09:54 |
| * Chipaca was not offering | 09:54 | |
| Chipaca | zyga— you requested changes on snapd#3136 but have not re-reviewed | 09:55 |
| mup | PR snapd#3136: snap-confine: add code to ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136> | 09:55 |
| zyga | Chipaca: I know, we're waiting for the locking branch to land | 10:02 |
| zyga | Chipaca: so that mvo can use the new locking primitives | 10:03 |
| zyga | Chipaca: (or I can push a small change that uses them) | 10:03 |
| zyga | Chipaca: curiously the locking branch needs a 2nd review (mvo +1d it) | 10:03 |
| Chipaca | curious, curious | 10:03 |
| zyga | Chipaca: very :) | 10:04 |
| * zyga is in a slightly better mood as headache is wearing off | 10:05 | |
| zyga | I need to fix some of the blinds to avoid wind rattling everything | 10:05 |
| Chipaca | zyga— next time, don't have your office inside a moored zeppelin | 10:07 |
| pedronis | very steampunk of him | 10:23 |
| mup | PR snapd#3221 opened: snap-repair: add `snap-repair run` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3221> | 10:29 |
| Chipaca | zyga could totally rock the steampunk mad scientist thing | 10:30 |
| zyga | pstolowski: question | 10:43 |
| zyga | pstolowski: so let's say we have connect | 10:43 |
| zyga | pstolowski: and connect hooks run | 10:43 |
| zyga | pstolowski: when should we correct the mount namespace | 10:43 |
| zyga | pstolowski: I'd say we should correct the mount namespace before the connect- hook runs the mount namespace must be already adjusted | 10:43 |
| Chipaca | zyga— snapd#3141 is green and you looked at it but didn't actually review it | 10:52 |
| mup | PR snapd#3141: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141> | 10:52 |
| Chipaca | mup— you should totally use colours to include status for some of these things | 10:54 |
| mup | PR snapd#3222 opened: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 10:56 |
| morphis_ | zyga: ^^ | 10:56 |
| === morphis_ is now known as morphis | ||
| Chipaca | gah, https://forum.snapcraft.io/t/cant-install-snap-app/376/2 is another one of those "nil map" panics | 10:59 |
| zyga | Chipaca: https://github.com/snapcore/snapd/pull/3223 | 11:00 |
| mup | PR snapd#3223: systemd: mount squashfs as read-only <Created by zyga> <https://github.com/snapcore/snapd/pull/3223> | 11:00 |
| zyga | Chipaca: is that the fixed one? | 11:00 |
| Chipaca | zyga— I think it was fixed, but I don't know where -- maybe you know more | 11:01 |
| mup | PR snapd#3223 opened: systemd: mount squashfs as read-only <Created by zyga> <https://github.com/snapcore/snapd/pull/3223> | 11:01 |
| zyga | Chipaca: content.go one | 11:01 |
| zyga | Chipaca: and one more reason to review and land https://github.com/snapcore/snapd/pull/3208 | 11:01 |
| mup | PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208> | 11:01 |
| * zyga brb | 11:01 | |
| morphis | Pharaoh_Atem: https://paste.fedoraproject.org/paste/Oy3r7PpWM9E19LSsBYNYHV5M1UNdIGYhyRLivL9gydE= | 11:02 |
| Chipaca | zyga— where are you seeing 'rw' next to a squash mount? | 11:03 |
| zyga | Chipaca: curious, now I don't | 11:10 |
| Chipaca | zyga— what about in 'snap try'? | 11:10 |
| zyga | let me dig because I'm sure I didn't write that patch out of the blue | 11:11 |
| zyga | Chipaca: no, I didn't try snap try | 11:11 |
| zyga | (and that's a good point) | 11:11 |
| zyga | ahq | 11:11 |
| zyga | aha | 11:11 |
| zyga | 665 658 7:7 / /snap/lonewolf/3 rw,relatime master:32 - squashfs /dev/loop7 ro | 11:11 |
| zyga | Chipaca: look at mountinfo | 11:11 |
| zyga | Chipaca: it is obviously confusing | 11:12 |
| zyga | Chipaca: there are two sets of options | 11:12 |
| zyga | Chipaca: mount options, where I do see rw, and superblock options where we see ro | 11:12 |
| zyga | Chipaca: obviously my patch means little (except for kernel bugs, if any) because the filesystem is readonly | 11:13 |
| zyga | Chipaca: but we were mounting a read-only filesystem without the read-only flag as you can see above | 11:13 |
| Chipaca | yeah | 11:13 |
| Chipaca | zyga— mount (at least the command) seems to have special-handling of known-ro filesystems like isowhatsit | 11:13 |
| zyga | Chipaca: are you sure? (I'm curious, I don't know) | 11:14 |
| zyga | Chipaca: I assumed that mount just looked at /proc/mounts | 11:14 |
| zyga | Chipaca: that shows less information | 11:14 |
| Chipaca | zyga— mount: /dev/loop5 is write-protected, mounting read-only | 11:14 |
| zyga | Chipaca: aha | 11:14 |
| zyga | Chipaca: well, I bet you could force-mount ext4 on top of the same loop device | 11:14 |
| zyga | so perhaps mount itself does the right stuff early on when it allocates a loopback device | 11:15 |
| Chipaca | zyga— in any case my question about try stands | 11:15 |
| Chipaca | ah, try doesn't have fstype=squash i guess? | 11:16 |
| Chipaca | zyga— but, would having ro,bind there work? | 11:16 |
| Chipaca | 'cause that would be good i think | 11:16 |
| zyga | Chipaca: yes, it would | 11:16 |
| Chipaca | make try more like the real thing from the outside | 11:16 |
| zyga | Chipaca: I didn't touch that part of the problem | 11:16 |
| zyga | Chipaca: when you try you get writable $SNAP (which is very odd) | 11:17 |
| abeato | mvo, hi, I hve this small fix for Core: http://people.canonical.com/~abeato/snappy/fix-wpa-conf-typo.diff | 11:17 |
| zyga | abeato: nice catch | 11:18 |
| zyga | abeato: can you propose that to github.com/snapcore/core | 11:18 |
| abeato | zyga, sure, is that the official way for proposing changes to core? | 11:19 |
| zyga | abeato: some things are still debs so changes there are made in the regular unregular way | 11:19 |
| zyga | abeato: but anything else, yes | 11:19 |
| abeato | zyga, got it, thanks | 11:19 |
| Chipaca | morphis— snapd#3156 has spread failures that i *think* are relevant to the branch itself | 11:24 |
| mup | PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 11:24 |
| abeato | 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 |
| morphis | Chipaca: I know, and they are specific to that branch | 11:25 |
| zyga | abeato: aha, I think ogra_ is the one to know where this part goes | 11:25 |
| morphis | zyga, abeato: it goes into the ubuntu-core-conf deb in the image ppa | 11:26 |
| Chipaca | 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 |
| ogra_ | abeato, https://github.com/snapcore/core-build/ | 11:26 |
| ogra_ | morphis, ^^^ | 11:27 |
| ogra_ | initrd is landing there too (once i get PR reviews) | 11:27 |
| zyga | ogra_: thanks! | 11:27 |
| morphis | ogra_: is that the new origin of ubuntu-core-conf? | 11:27 |
| ogra_ | morphis, right | 11:27 |
| abeato | ogra_, ok, thanks | 11:27 |
| morphis | ogra_: that misses things | 11:27 |
| ogra_ | morphis, and will soon also be the upstream branch for initramfs-tools-ubuntu-core | 11:27 |
| morphis | 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 |
| abeato | ogra_, yeah, not in that repo :) ^^ | 11:28 |
| morphis | ogra_: so looks like something is broken | 11:28 |
| ogra_ | 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 |
| ogra_ | we dropped 3 obsolete bits ... but nothing wpa related | 11:29 |
| * ogra_ checks the PPA | 11:30 | |
| morphis | ogra_: https://launchpadlibrarian.net/310101186/ubuntu-core-config_0.6.40+ppa42_0.6.40+ppa43.diff.gz | 11:30 |
| abeato | ogra_, /lib/systemd/system/snapd.generate-network-conf.service is missing too in the gihub repo | 11:32 |
| ogra_ | morphis, hmm, looks like mvo "just uploaded" ... | 11:32 |
| ogra_ | abeato, yeah | 11:32 |
| morphis | ogra_: the wpa thing is there for quite a long time | 11:32 |
| morphis | ogra_: ok, not that long but over a month: Wed, 08 Mar 2017 09:22:16 +0100 | 11:33 |
| morphis | not sure since when the git repo exists | 11:33 |
| ogra_ | morphis, march 29 | 11:34 |
| zyga | Chipaca: one more tweak https://github.com/snapcore/snapd/pull/3224 | 11:37 |
| mup | PR snapd#3224: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/3224> | 11:37 |
| mup | PR snapd#3224 opened: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/3224> | 11:37 |
| Chipaca | zyga— i'll get to it in a bit | 11:37 |
| Chipaca | i'm going to go have lunch | 11:37 |
| Chipaca | zyga— do reviews! | 11:37 |
| zyga | Chipaca: I should oto | 11:37 |
| zyga | too | 11:37 |
| ogra_ | morphis, looks like a mid-air crash ... http://paste.ubuntu.com/24447438/ | 11:38 |
| Chipaca | zyga— yes.</serious face> | 11:38 |
| ogra_ | morphis, i'll adjust the branch | 11:38 |
| morphis | ogra_: thanks! | 11:38 |
| ogra_ | morphis, abeato ... please use the branch in the furture (indeed) ... | 11:39 |
| morphis | ogra_: +1 | 11:39 |
| pstolowski | 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 |
| pstolowski | zyga, as opposed to prepare- hooks | 11:45 |
| zyga | pstolowski: thanks for confirming that, I will make sure that this happens | 11:48 |
| mup | PR core-build#7 opened: Sync deb <Created by ogra1> <https://github.com/snapcore/core-build/pull/7> | 11:48 |
| ogra_ | sigh ... wha does that one include all other changes .. | 11:49 |
| ogra_ | *why | 11:49 |
| * ogra_ closes | 11:49 | |
| mup | PR core-build#7 closed: Sync deb <Created by ogra1> <Closed by ogra1> <https://github.com/snapcore/core-build/pull/7> | 11:50 |
| ogra_ | silly git :( | 11:50 |
| zyga | ogra_: just don't push silly patches ;-) | 11:50 |
| * zyga hugs ogra_ | 11:51 | |
| zyga | git can be confusing | 11:51 |
| mup | PR snapd#3225 opened: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 11:51 |
| niemeyer | Good mornings | 11:51 |
| zyga | niemeyer: hey | 11:52 |
| Son_Goku | moo | 11:53 |
| zyga | mvo: locking is now in place, we can return to /snap sharing | 11:55 |
| mup | PR snapd#3149 closed: cmd: make locking around namespaces explicit <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3149> | 11:55 |
| mvo | zyga: excellent, I will update my pr | 11:56 |
| zyga | mvo: thanks! | 11:56 |
| morphis | Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1444819 | 12:00 |
| mvo | zyga: pushed, lets see if tests are still happy | 12:00 |
| zyga | mvo: thanks! | 12:05 |
| zyga | mvo: I'll review it shortly | 12:05 |
| ogra_ | zyga, well, if i work on a new brasnch i expect it to not commit all other existing branches ... | 12:15 |
| abeato | ogra_, hey, have you already updated core-build? I still see the differences with the deb pkg | 12:18 |
| ogra_ | abeato, no, my git tree is messed up with other patches i need to fix that first | 12:27 |
| ogra_ | (and got dragged away into other things, it'll be fixed before EOD) | 12:27 |
| abeato | ogra_, ack, just wondering, not that I am in a big hurry :) thanks! | 12:28 |
| ogra_ | after all it is just book-keeping, the core snap uses the deb, not the tree :) | 12:28 |
| abeato | ogra_, does that mean I need to propose the debdiff still for the package? | 12:28 |
| ogra_ | abeato, i'll include it | 12:29 |
| abeato | great | 12:29 |
| Son_Goku | morphis: comments left | 12:33 |
| morphis | Son_Goku: I thought I cleaned all of the remaining references | 12:33 |
| Son_Goku | you've got at least an Obsoletes in there | 12:34 |
| morphis | right | 12:34 |
| morphis | Son_Goku: is gone now when you recheck the spec at the same location | 12:36 |
| mup | PR snapd#3223 closed: many: mount squashfs as read-only <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3223> | 12:49 |
| pedronis | niemeyer: standup? | 13:02 |
| jdstrand | sborovkov: ok | 13:10 |
| === petevg_afk is now known as petevg | ||
| zyga | mvo: I found another bug with re-exec | 13:31 |
| zyga | for snap-confine | 13:31 |
| ogra_ | zyga, https://forum.snapcraft.io/t/package-lists-for-distro-specific-core-base-snaps/378 | 13:40 |
| zyga | ogra_: replied | 13:45 |
| cwayne | zyga: heya, any update on that kernel landing? | 13:45 |
| zyga | cwayne: I didn't check yet | 13:46 |
| zyga | cwayne: I can propose a quick branch that targets 2.25 that re-enables this | 13:46 |
| Chipaca | jdstrand— I just noticed I hadn't requested you as a reviewer of snapd#3150 | 13:46 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 13:46 |
| * zyga needs to eat lunch now | 13:47 | |
| zyga | mvo: so quick fact, there's still something wrong in the code that syncs aa profile for snap-confine | 13:47 |
| Chipaca | jdstrand— I was just about to ask you if you'd been able to look at it before noticing :-/ | 13:47 |
| jdstrand | Chipaca: I haven't yet, but it is on my list | 13:47 |
| zyga | mvo: I strongly believe it is just in tests but the merge of locking into master will verify that assumption | 13:48 |
| zyga | mvo: I'll break for lunch and see if I can find this | 13:48 |
| Chipaca | jdstrand— ah, thank you | 13:50 |
| mvo | zyga: do you have more info? what is wrong with the snap-confine aa profile? | 13:54 |
| Son_Goku | ogra_: thanks for making that forum post about core snap | 13:55 |
| Son_Goku | I'll start taking a look at adjusting my core snap builder to include the necessary things you're asking for | 13:55 |
| morphis | Son_Goku: you have a core snap builder? | 13:56 |
| Son_Goku | I made one last October | 13:56 |
| Son_Goku | for RPM based distros | 13:56 |
| morphis | nice | 13:56 |
| Son_Goku | I can't *do* anything with it because snapd won't let me use it | 13:56 |
| morphis | Son_Goku: that depends :-) | 13:56 |
| Son_Goku | but at least I can make the stupid buggers | 13:56 |
| morphis | you could try to get a core system working with it | 13:57 |
| Son_Goku | https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap | 13:57 |
| Son_Goku | I made the tiniest core snaps I could because I didn't know what to put in there | 13:57 |
| Son_Goku | now that I have some idea, I can try to make a proper one | 13:57 |
| cwayne | zyga: thanks | 13:58 |
| mup | PR snapcraft#1276 opened: sources: validate unknown source-type in yaml <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1276> | 14:03 |
| mup | PR snapd#3018 closed: tests: add empty initrd failover test <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3018> | 14:07 |
| lutostag | curious if I can set an env variable to let snap know I am installing in a ci env, so the stats for a particular snap are not misleading | 14:24 |
| mup | PR snapd#3226 opened: snap-repair: add `snap-repair run` #3221 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226> | 14:27 |
| mup | PR snapd#3221 closed: snap-repair: add `snap-repair run` <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3221> | 14:28 |
| === JanC is now known as Guest16266 | ||
| === JanC_ is now known as JanC | ||
| === bdx_ is now known as bdx | ||
| morphis | niemeyer: if I create a modified debian image on Linode now can snapshot it? | 14:33 |
| niemeyer | morphis: Heya, yep | 14:37 |
| morphis | niemeyer: ok, let me spawn up one now | 14:37 |
| mvo | niemeyer: hey, do you think I should write a "base snaps" proposal in the forum to make it a bit clearer what the intend of those is? seems like there is some confusion | 14:38 |
| niemeyer | mvo: +1 | 14:38 |
| mvo | niemeyer: thanks, will do that | 14:38 |
| * ogra_ hugs mvo | 14:41 | |
| morphis | niemeyer: getting: 2017/04/24 16:42:32 Cannot allocate linode:debian-unstable-64: cannot create Linode disk with debian-unstable-64: you do not have enough unallocated storage to create this Disk (1200 requested, but only 0 available) | 14:42 |
| mvo | ogra_: yw, sorry about the confusion | 14:43 |
| morphis | niemeyer: any idea what the reason is for this? | 14:43 |
| niemeyer | morphis: What machine is this? | 14:43 |
| ogra_ | mvo, well, this is the time where i'm sad we dont still use blueprints ... they were awful but you had a clear plan ahead of starting any work :) | 14:43 |
| morphis | niemeyer: didn't even started one yet | 14:44 |
| morphis | niemeyer: my .spread-reuse.yaml is empty and just running $ spread -reuse -shell linode:debian-unstable-64: within my spread-images branch | 14:44 |
| zyga | re | 14:45 |
| niemeyer | morphis: This is running on a machine, though.. please paste the whole log | 14:45 |
| zyga | darn bug in modem support | 14:45 |
| zyga | 16:41 < zyga> mvo: thanks! | 14:45 |
| zyga | 16:41 < zyga> mvo: I'm somewhat confused myself, will we mount parts of the core snap into the base snap (snapctl)? | 14:45 |
| zyga | 16:43 < zyga> mvo: so I ran a quick test and the profile for snap-confine was stale | 14:45 |
| zyga | 16:43 < zyga> mvo: but perhaps that's resend/reuse in spread | 14:45 |
| zyga | 16:43 < zyga> mvo: I'm running a clean one to se | 14:45 |
| morphis | niemeyer: https://paste.ubuntu.com/24448247/ | 14:45 |
| niemeyer | morphis: Uh.. pretty awkward | 14:46 |
| mvo | zyga: aha, thank you. so the profile writen on the host in /etc/apparmor.d/snaps.core.999.usr.lib.snapd.snap-confine was stale? | 14:46 |
| morphis | niemeyer: let me retry with -vv | 14:46 |
| zyga | mvo: yes | 14:47 |
| zyga | mvo: but as I said, not sure if this is test preparation that's flaky in case of resend | 14:47 |
| zyga | mvo: discarded and running now | 14:47 |
| zyga | (not sure if will pass) | 14:47 |
| morphis | niemeyer: there we go: 2017/04/24 16:47:05 Creating disk on linode:debian-unstable-64 (Spread-14) with debian-unstable-64... | 14:47 |
| niemeyer | morphis: Done.. we had two machines with overallocated disks | 14:49 |
| morphis | niemeyer: ok let me try again | 14:49 |
| niemeyer | morphis: and we _only_ have those two machines.. everything else is busy running CI | 14:49 |
| morphis | ok | 14:49 |
| zyga | mvo: ok, empty test reproduced this; | 14:53 |
| zyga | mvo: let me dig in | 14:53 |
| zyga | mvo: but this may affect all kinds of PRs :/ | 14:53 |
| mvo | zyga: meh, sucks. keen to learn about the details, I can help with the fix | 14:55 |
| mvo | zyga: also, good that we find it now in tests and not in the wild :) | 14:55 |
| mvo | base snaps is described in the forum now, if it looks good I can write down an implemenation plan next | 14:56 |
| zyga | mvo: first modification of the profile for a while | 14:56 |
| zyga | mvo: the copied profile is definitely wrong but the other one is correct (the one in the package) | 14:57 |
| * zyga is puzzled | 14:57 | |
| zyga | aha | 14:57 |
| * zyga checks one more file | 14:57 | |
| zyga | mvo: so | 14:57 |
| zyga | mvo: the file in the core snap is wrong | 14:58 |
| zyga | mvo: we don't update that | 14:58 |
| zyga | mvo: so the derived one is also old | 14:58 |
| niemeyer | mvo: I've been cutting off the "RFC" sort of comment because that's somewhat implied from the forum context.. most things there are an opportunity for commenting, in a way | 14:58 |
| mvo | niemeyer: sure, thank you | 15:00 |
| niemeyer | mvo: No problem, just wanted to provide the rationale so it didn't feel abusive | 15:00 |
| niemeyer | I've also been attempting to make subjects not super long and avoid uppercasing (recall "IN PROGRESS" at least once for example), to improve browsing | 15:01 |
| ogra_ | mvo, so it would function like stacked chroots ? you have the "outer chroot" that is basically our core snap running snapd and then you have an "inner chroot" that is te base snap on top serving as execution env for the respective distro focused snap ? | 15:02 |
| pedronis | Chipaca: am I confused, or "snap info" is actively using the feature of setting channel="" ? | 15:03 |
| Chipaca | pedronis— you are not confused | 15:04 |
| pedronis | so we cannot kill that feature | 15:04 |
| pedronis | or paper it over | 15:04 |
| Chipaca | pedronis— it might no longer be necessary though? | 15:04 |
| pedronis | because of the channel map? | 15:05 |
| Chipaca | pedronis— 'snap info foo' needs to show info about foo even if there is no foo in stable | 15:05 |
| pedronis | yea, so we need it | 15:05 |
| zyga | mvo: I think I know what's wrong | 15:05 |
| zyga | mvo: testing the fix now | 15:05 |
| pedronis | Chipaca: my plan was to default to stable at that level but seems not possible | 15:05 |
| Chipaca | pedronis— sounds like it to me, but maybe there's a different way i don't know | 15:06 |
| Chipaca | yeah, for snap info we can't | 15:06 |
| mup | PR snapcraft#1277 opened: Handle revoked-uploads case on snap-developer revokes. <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1277> | 15:06 |
| zyga | mvo: yeah, | 15:07 |
| slangasek | zyga, mvo: if you /don't/ use cloud-init to provision your user when deploying it in the cloud, how do you provision your user? | 15:09 |
| zyga | mvo: question on the base snap, did you meant to say ubuntu-16.04 vs ubuntu-16? | 15:09 |
| zyga | slangasek: we have code that does this from the outside in the step that prepares a spread machine | 15:10 |
| zyga | slangasek: AFAIR | 15:10 |
| slangasek | zyga: hmm, I don't understand how that's meant to work "from the outside", that sounds like a security hole :) | 15:10 |
| zyga | slangasek: before it boots | 15:10 |
| zyga | slangasek: we do magic stuff | 15:10 |
| zyga | slangasek: (where it means I don't remember) | 15:11 |
| slangasek | hmm, well, the instructions mvo gave me don't do any magic stuff before booting | 15:11 |
| zyga | slangasek: what did those look like? | 15:11 |
| slangasek | zyga: the ones in the bug comment | 15:12 |
| zyga | slangasek: ok | 15:12 |
| pedronis | Chipaca: would having a AnyChannel bool on SnapSpec be saner? | 15:12 |
| morphis | niemeyer: I will try this again later today when we may be have more free instances | 15:13 |
| niemeyer | morphis: Ack | 15:14 |
| * niemeyer lunches | 15:14 | |
| niemeyer | Back shortly | 15:14 |
| Chipaca | pedronis— also note channel is explicitly set to "" if a revision is given | 15:14 |
| pedronis | Chipaca: yes | 15:14 |
| pedronis | that's ok | 15:14 |
| pedronis | Chipaca: my issue is that channel="" means stable sometimes in snapd, and sometimes it means any | 15:15 |
| pstolowski | pedronis, i've address your comments to #3171 | 15:16 |
| pedronis | Chipaca: so my idea is that AnyChannel true or Revision is set we set channel="" for the store, otherwise we take "" to mean stable | 15:16 |
| Chipaca | hmm, i thought we set it early to 'stable' to avoid this before | 15:16 |
| pedronis | Chipaca: we do in snapd the daemon, but not snapd all the places | 15:16 |
| Chipaca | which is how we got here, yah | 15:16 |
| Chipaca | pedronis— sounds fair | 15:16 |
| pedronis | Chipaca: I mean I can fix it higher up, I just fear that somebody will hit this again | 15:17 |
| Chipaca | pedronis— yeap | 15:17 |
| pedronis | ok, I'll try something along this lines and ping you for a review | 15:18 |
| pedronis | *these | 15:18 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/3227 | 15:20 |
| mup | PR snapd#3227: tests: copy .real profile as .real <Created by zyga> <https://github.com/snapcore/snapd/pull/3227> | 15:20 |
| mup | PR snapd#3227 opened: tests: copy .real profile as .real <Created by zyga> <https://github.com/snapcore/snapd/pull/3227> | 15:20 |
| * zyga needs a coffee | 15:30 | |
| zyga | eat lunch, not drink coffee, go back to start and suspsned | 15:31 |
| zyga | monopoly of life | 15:31 |
| mvo | zyga: thank you, looking | 15:33 |
| zyga | mvo: thanks! | 15:35 |
| zyga | mvo: also replied to your base snap post (thank you for posting it!) | 15:35 |
| mvo | ogra_: inner vs outer> I think we have not decided on all the details, one question for example is how Ubuntu Core will work, one way would be to have core with just snapd and ubuntu-core-16 as the base which also contian the booting bits. I will update the forum with some of the open questions | 15:36 |
| mvo | zyga: thank you! reading now | 15:37 |
| ogra_ | mvo, yeah, i didnt really take images into account at all ... that was all more focused on execution env for snaps | 15:37 |
| zyga | mvo: that commit message is totally meaningless, I wonder what happened when I wrote that!?! | 15:38 |
| * zyga is fixing it | 15:38 | |
| zyga | or something happened in VI | 15:39 |
| zyga | it's totally chopped in pieces | 15:39 |
| zyga | corrected | 15:43 |
| * zyga -> coffee | 15:43 | |
| Pharaoh_Atem | morphis: why are we using gnupg instead of gnupg2? | 15:44 |
| zyga | Pharaoh_Atem: I presume because of the CLI interface they provide | 15:51 |
| zyga | Pharaoh_Atem: gpg has terrible API story | 15:52 |
| Pharaoh_Atem | I'm aware | 15:52 |
| Pharaoh_Atem | gpg intentionally doesn't have an api | 15:52 |
| Pharaoh_Atem | if you want something with a semblance of one, you should use gpgme | 15:52 |
| * zyga never heard about gpgme | 15:53 | |
| Chipaca | does not sound like something you'd ask for on a first date | 15:54 |
| Pharaoh_Atem | zyga: https://www.gnupg.org/software/gpgme/index.html | 15:54 |
| Pharaoh_Atem | I'm rather surprised you didn't know about gpgme | 15:55 |
| * zyga will call his software ${somethingelse}made-easy | 15:55 | |
| zyga | Pharaoh_Atem: I didn't touch assertion code | 15:55 |
| cwayne | zyga: any chance that fix was in -75 kernel? | 15:56 |
| zyga | cwayne: didn't get to the checking part yet | 15:57 |
| zyga | cwayne: let's see | 15:57 |
| zyga | cwayne: -75? | 15:58 |
| zyga | cwayne: I see -49 now | 15:58 |
| * zyga wonders why opensuse made leap 41 and 42 and now switches to ...15 | 15:59 | |
| zyga | equally meaningless number | 15:59 |
| pedronis | Pharaoh_Atem: the plan is to possibly drop gpg at some point, it's not used at runtime, it's used at snap/device development time | 16:01 |
| Pharaoh_Atem | pedronis: that seems like a bad idea | 16:02 |
| Pharaoh_Atem | so it's not possible to digitally sign and verify those signatures at runtime? | 16:02 |
| pedronis | Pharaoh_Atem: we use the go libraries for that | 16:02 |
| Pharaoh_Atem | the horror never stops | 16:03 |
| mup | PR snapd#3228 opened: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3228> | 16:07 |
| pedronis | Chipaca: ^ | 16:07 |
| zyga | Pharaoh_Atem: I really don't understand your problem | 16:09 |
| zyga | Pharaoh_Atem: if we used python and "import cryptography" that would do exactly this I don't think you'd complain | 16:10 |
| zyga | Pharaoh_Atem: using libraries is a perfectly natural way of doing things | 16:10 |
| zyga | hmm | 16:12 |
| zyga | refresh delta from core fails now | 16:12 |
| zyga | presumably because new core mvo built | 16:13 |
| zyga | pedronis: the ensure TestEnsureLoopPrune test failed again | 16:21 |
| zyga | pedronis: I wonder if this has any correlation to the core snap builds? | 16:21 |
| Pharaoh_Atem | zyga: afaik, go libraries reimplement everything rather than using system resources | 16:25 |
| Pharaoh_Atem | python-cryptography and similar libraries don't attempt to reimplement crypto | 16:25 |
| Pharaoh_Atem | they just expose a nicer interface for already well-tested and well-vetted libraries | 16:26 |
| zyga | Pharaoh_Atem: such as? crypto in C is terrible | 16:26 |
| zyga | Pharaoh_Atem: also go didn't link to other things very well until recently | 16:26 |
| Pharaoh_Atem | crypto in general is terrible | 16:26 |
| Pharaoh_Atem | so it's not really worth blaming it on C or any other language | 16:26 |
| Pharaoh_Atem | crypto is one of the hardest things to implement "correctly" in any language | 16:27 |
| zyga | Pharaoh_Atem: yes but C has a class of issues that's impossible in go | 16:29 |
| zyga | Pharaoh_Atem: my point is that I think having a good language tends to see reimplementation of critical infra | 16:29 |
| Pharaoh_Atem | it's hard to beat how awful C can be :) | 16:29 |
| zyga | Pharaoh_Atem: and go is just one example of that | 16:30 |
| Pharaoh_Atem | when Go gives me nice shared libraries, then I'll concede | 16:30 |
| zyga | Pharaoh_Atem: not sure how the rust community has done this but I woudn't be surprised to see it | 16:30 |
| Pharaoh_Atem | you're right | 16:30 |
| zyga | Pharaoh_Atem: well, does java give you those (that you can use from C) | 16:30 |
| Pharaoh_Atem | but I don't particularly like that reusability is still awful in Rust | 16:30 |
| zyga | Pharaoh_Atem: shared library that's cross language is hard | 16:30 |
| zyga | Pharaoh_Atem: as languages get more stronger checks done at build and link time | 16:31 |
| Chipaca | jdstrand— o/ | 16:31 |
| * zyga reboots | 16:35 | |
| Chipaca | jdstrand— answered in-pr, thought i'd catch you here but never mind | 16:36 |
| Chipaca | wondering about %q. Probably best if i write a test to explain what i mean. | 16:37 |
| Chipaca | >sigh< | 16:37 |
| pedronis | zyga: it seems to be failing to the other side, like not that not enough time has passed, but too much | 16:46 |
| pedronis | s/to the other/from the other/ | 16:47 |
| pedronis | zyga: I mean chg1 was not just aborted but also removed it seems | 16:47 |
| pedronis | need to dig a bit more | 16:47 |
| mezzopiano | Hi everyone, a quick question -- I just installed docker via snap, and though the daemon is running and the snap-based interfaces are ok, I can't connect to it via the normal user, and root cannot stat the user's home directory. Usually I would simply add the user to the docker group so that it can interact with the daemon, but adding users to groups seems to be an as-yet unsolved problem (e.g. https://forum.snapcraft.io/t/snapp | 17:09 |
| mezzopiano | Could you give me a hint as to how to add docker access for a regular user? | 17:10 |
| mezzopiano | Any ideas are much appreciated. Thanks in advance! | 17:10 |
| mezzopiano | (btw, I'm running snap 2.23.6 [16 series] on ubuntu core) | 17:18 |
| niemeyer | There we go: https://forum.snapcraft.io/t/review-sprint-1/377 | 17:22 |
| mup | PR snapd#3227 closed: tests: copy .real profile as .real <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3227> | 17:23 |
| niemeyer | Wrote a small tool to update the statuses, so they should be more realistic and more frequently updated | 17:24 |
| mezzopiano | Just a subtle ping -- any hints whatsoever regarding the installation of docker within snappy core would be massively appreciated. I've now also tested the fancy new release candidate ( https://forum.snapcraft.io/t/call-for-testing-docker-snap/362 ), but to no avail. What might I be doing wrong? | 17:38 |
| kyrofa | mezzopiano, it might be worth posting in the forum | 17:41 |
| kyrofa | mezzopiano, you'll get more eyes | 17:41 |
| mezzopiano | kyrofa: Thanks, I haven't given up hope yet that I am missing something super-obvious. I will go to the forum eventually, but this can't be that hard, can it? | 17:43 |
| kyrofa | mezzopiano, it kinda depends on the snap, and I'm afraid I at least have zero familiarity with it | 17:47 |
| mezzopiano | Ok, success -- I found the new command docker.help (ships with the latest candidate), and that outlines a proper setup. Phew! | 17:50 |
| mezzopiano | kyrofa: Thanks for chiming in! | 17:51 |
| kyrofa | mezzopiano, ah, excellent! | 17:51 |
| kyrofa | mezzopiano, haha, I was no help, but you're welcome :P | 17:51 |
| mezzopiano | kyrofa: It helps a lot of times just to have somebody respond -- thanks for your patience :-) | 18:20 |
| kyrofa | Of course, any time | 18:20 |
| mezzopiano | Docker is now working beautifully as ever :-) . | 18:20 |
| kyrofa | Wonderful! | 18:20 |
| mup | PR snapd#3117 closed: tests: parameterize gadget snap channel <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3117> | 18:45 |
| pedronis | zyga: I'm saying tests failing like this: ERROR run hook "configure": cannot create lock directory /run/snapd/lock: Permission denied | 18:52 |
| zyga | pedronis: I fixed this in master earlier today | 18:52 |
| zyga | pedronis: if you merge it should be good | 18:52 |
| zyga | pedronis: unless you already have 12147158ce41c7c2c896c6645008476edeec4a69 and it still fails | 18:53 |
| zyga | pedronis: then I want to know because it may be something more | 18:53 |
| pedronis | zyga: I see, I thought at least one of my branches was really recent, but seems not, I will merged master into my branches and see how it goes | 18:56 |
| zyga | pedronis: thanks | 18:58 |
| * zyga fixes his spread tests to work, gee so many typos on "dry run" coding | 19:00 | |
| === bdx_ is now known as bdx | ||
| kyrofa | jdstrand, I've hit another issue running the nextcloud snap in lxc | 19:30 |
| kyrofa | jdstrand, php-fpm creates a worker to service requests, and then the worker goes away once it's done servicing | 19:30 |
| kyrofa | jdstrand, however, on lxc, this turns into a defunct process instead of actually going away | 19:31 |
| kyrofa | jdstrand, the end result is that Nextcloud can only seem to handle one request or so before never responding again | 19:31 |
| kyrofa | Any idea what could be causing this? | 19:32 |
| jdstrand | kyrofa: are there any denials? | 19:32 |
| kyrofa | None on the container itself, but there are plenty on the host | 19:33 |
| kyrofa | Here: | 19:34 |
| kyrofa | Ah, let me restart it again so I an get a good paste | 19:34 |
| kyrofa | jdstrand, here: http://pastebin.ubuntu.com/24449820/ | 19:36 |
| kyrofa | I don't really know how to parse those, though | 19:36 |
| jdstrand | kyrofa: I've not seen the peer="---" denial before. it seems like nextcloud in the container is trying to talk to itself via an anonymous socket and is getting blocked. I think we need jjohansen to look at that | 19:38 |
| * zyga looks too | 19:38 | |
| zyga | peer="---" | 19:39 |
| * zyga has no idea what that is | 19:39 | |
| jjohansen | kyrofa: what kernel? there was fix for this rolled out a while ago | 19:39 |
| zyga | jjohansen: was that fixed and undone when the whole apparmor changes were reverted? | 19:39 |
| jjohansen | zyga: the --- indicates that the peer has a label that is not visible | 19:40 |
| kyrofa | jjohansen, 4.4.0-72 | 19:40 |
| jjohansen | zyga: I'm looking | 19:40 |
| kyrofa | Looks like I can update to -75 | 19:41 |
| jdstrand | jjohansen: ok, not sure what you and zyga are talking about, but kyrofa and I were talking about the nextcloud snap running in lxd getting denials of this form: http://pastebin.ubuntu.com/24449820/ | 19:41 |
| jdstrand | jjohansen: see backscroll from a few minutes for context | 19:41 |
| jjohansen | jdstrand: that is precisely what we are talking about | 19:42 |
| jdstrand | ok. I don't know how zyga knows what kernel version kyrofa is running, but ok :) | 19:42 |
| jdstrand | ah, nm | 19:43 |
| jdstrand | I am doing too many things at once | 19:43 |
| jjohansen | kyrofa, zyga: so it went into 4.4.0-73 | 19:44 |
| kyrofa | Nice, updating then! | 19:44 |
| kyrofa | jjohansen, zyga jdstrand yep, that fixes it, no more defunct processes | 19:50 |
| kyrofa | Thank you all! | 19:51 |
| zyga | kyrofa: the real thanks go to jjohansen :) | 19:52 |
| zyga | jjohansen: hey, quick question, did you manage to make that branch that tracks apparmor patches against mainline? | 20:05 |
| jdstrand | jjohansen: nice! | 20:07 |
| jjohansen | zyga: there is http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/ | 20:08 |
| jjohansen | the v4.10-aa3.6-backport-to-vXXX branches are up to date zesty from a 5 weeks ago | 20:08 |
| jjohansen | however I don't have an update for 4.11 yet, and | 20:08 |
| jjohansen | v4.1, v4.0 are very much a wip, and I haven't taken it all the way back to 3.10 yet | 20:08 |
| zyga | jjohansen: I think the mainline based branch is the most intestesting one | 20:12 |
| jjohansen | sure, and sometime this/next week I'll add a 4.11 one | 20:18 |
| jdstrand | jjohansen: oh, hey, I guess the bug that was fixed was bug #1660832 ? | 20:19 |
| mup | Bug #1660832: unix domain socket cross permission check failing with nested namespaces <verification-done-xenial> <verification-done-yakkety> <apparmor (Ubuntu):Confirmed> <linux (Ubuntu):Fix Released> <apparmor (Ubuntu Xenial):Confirmed> <linux (Ubuntu Xenial):Fix Released> <apparmor (Ubuntu | 20:19 |
| mup | Yakkety):Confirmed> <linux (Ubuntu Yakkety):Fix Released> <apparmor (Ubuntu Zesty):Confirmed> <linux (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1660832> | 20:19 |
| jdstrand | it's funny because I just went back to looking at my inbox and that was the first thing there :) | 20:19 |
| jjohansen | jdstrand: yes | 20:19 |
| kyrofa | Haha | 20:19 |
| pedronis | niemeyer: niemeyer: master is broken on linode:ubuntu-core-16-64:tests/main/failover:emptyinitrd (I'm seeing that one failing also on my PRs), I think it was merged recently | 20:30 |
| pedronis | not sure if it's broken or just very flaky, or interacted with something that was merged | 20:31 |
| niemeyer | Oh noes | 20:31 |
| niemeyer | This test itself was just merged wasn't it? | 20:32 |
| pedronis | niemeyer: yes, very recent | 20:32 |
| pedronis | I think | 20:32 |
| pedronis | niemeyer: here's a failing run: https://travis-ci.org/snapcore/snapd/builds/225329709 | 20:32 |
| pedronis | mmh, it's failing with: ERROR cannot replace signed kernel snap with an unasserted one | 20:34 |
| pedronis | not sure how it passed | 20:34 |
| pedronis | initially | 20:34 |
| pedronis | unless I'm misreading the logs | 20:35 |
| niemeyer | pedronis: I suggest disabling the test and asking fgimenez to have a look tomorrow | 20:36 |
| pedronis | niemeyer: ah, it might an interaction with the other change about parametrizing channels | 20:36 |
| niemeyer | So we're not blocked on that otherwise | 20:36 |
| niemeyer | Yeah, could be | 20:36 |
| niemeyer | School run... back later | 21:01 |
| * zyga EODs | 22:27 | |
| mup | PR snapd#3137 closed: overlord: switch to aliases v2 tasks for install/refresh etc ops plus transition <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3137> | 23:15 |
| pedronis | niemeyer: merged my first PR together with disabling that test for now | 23:21 |
| niemeyer | pedronis: Sweet, thanks! | 23:21 |
| niemeyer | pedronis: I've included spread status on the latest review sprint board | 23:21 |
| niemeyer | pedronis: Only when they fail, specifically, so it's more visible | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!