=== chihchun_afk is now known as chihchun === bshah is now known as bshah[m] === bshah[m] is now known as bshah === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === kira is now known as Guest65397 [06:17] hi [08:00] hey zyga-ubuntu! good morning [08:07] hey mvo [08:07] sorry, a bit stiff [08:08] I decided to move back to the office [08:11] zyga-ubuntu: no worries - reviews for the 2.29 targeted PRs would be great [08:13] mvo: ack [08:14] PR snapd#4098 closed: snap-confine: allow reading uevents from any where in /sys [08:14] mvo: btw, I think we can close the 2.28 milestone now [08:15] mvo: about https://github.com/snapcore/snapd/pull/4095 [08:15] PR #4095: debian: make packaging/ubuntu-14.04/copyright a real file again [08:15] mvo: I think Pharaoh_Atem is 100% spot on here [08:16] mvo: shall I spend a while to make the copyright file non-fake today/ [08:16] mvo: I feel bad about this because debian/copyright is one of the most important parts of debian and ubuntu [08:16] zyga-ubuntu: ok, but lets not block 2.29 on this as its not a regression [08:17] mvo: tongue-in-cheek it is a regression since we started vendoring, we just get a free pass to ignore that in ubuntu, it seems [08:17] mvo: I'll get to work :) [08:17] zyga-ubuntu: not a regression comapred to 2.28 [08:17] zyga-ubuntu: but yeah, I think we are in agreemeent [08:18] PR snapd#4095 closed: debian: make packaging/ubuntu-14.04/copyright a real file again [08:19] sanity timeout expired: Interrupted system call [08:19] mvo: 6 seconds not enough? [08:20] zyga-ubuntu: I don't know what is going on :( [08:20] mvo: maybe we should not hold that lock on this long [08:20] zyga-ubuntu: makes me unhappy because it may mean we will run into autopkgtest issue on the distro [08:20] mvo: I wish I could reproduce this [08:20] PR snapd#4096 closed: spread: welcome bionic beaver [08:21] zyga-ubuntu: thanks for your merges. I cherry pick in parallel to 2.29 [08:21] ah, wait [08:21] 2.29~rc2 had the 6 second timeout change [08:21] PR snapd#4099 closed: merge 2.29~rc2 release back into master [08:21] so maybe that was still on the 3 second one [08:22] * mvo nods [08:29] PR snapd#4097 closed: interfaces/many: miscellaneous updates based on feedback from the field [08:30] mvo: about https://github.com/snapcore/snapd/pull/4078 [08:30] PR #4078: tests: new test to check interfaces after reboot the system [08:30] zyga-ubuntu: I thin for this one we need a 2.29 PR - 11 commits [08:30] mvo: we need the code to update mount units in the field, right? [08:30] mvo: yes, I was thinking the same thing after not squash merging it [08:30] mvo: I'll make one [08:30] zyga-ubuntu: is that the right PR number? but yeah we need this code to update the mount units in the fields but I think it should not block 2.29, no regression and 2.30 can have it [08:31] mvo: hmm, not sure, it's a serious bug that can stop people from operating servers [08:36] zyga-ubuntu: if we have a fix ready quickly it can be considered, in the meantime the workaround is to reinstall snapd 2.29 and things will work [08:36] PR snapd#4101 opened: interfaces/many: miscellaneous updates based on feedback from the field (2.29) [08:36] mvo: https://github.com/snapcore/snapd/pull/4101 is the backport [08:36] PR #4101: interfaces/many: miscellaneous updates based on feedback from the field (2.29) [08:36] mvo: I don't have a fix handy, let me see if there's a simple way to make that [08:37] ouch [08:37] man [08:37] back.hurt() [08:37] zyga-ubuntu: :( good luck [08:38] zyga-ubuntu: don't get me wrong, we want to fix that. but we also need to release and there is a reasonable workaround (dpkg --purge snapd ; apt install snapd) that we can release-note [08:39] mvo: purging sytem state [08:39] that's not a reasonable solution IMO [08:39] (disrupts production) [08:40] zyga-ubuntu: well, for people who are affected by the bug there is no system state because snapd did not work [08:40] zyga-ubuntu: and for the people who are not affected there is nothing to do [08:41] zyga-ubuntu: alternatively we could do something trivial in the trusty postinst? [08:41] zyga-ubuntu: like "sed s/[Unit]\n.../fix/" [08:43] PR snapcraft#1646 opened: sources: enforce default language in subversion info [08:44] mvo: not really, it's something that is broken but not each time [08:44] mvo: yeah [08:45] mvo: the postinst idea is not too shabby :) [08:53] zyga-ubuntu: unrelated question, if I have a snapName and a plugName, is there an easy way to check if that is connected (ie what api should I use for this)? [08:54] let me see [08:55] mvo: yes [08:55] mvo: you can use repo.Plug(snapName, plugName).Connections [08:56] mvo: what are you making? :) [08:57] mvo: on that note: http://turnoff.us/geek/what-your-code-looks-like/ [08:59] zyga-ubuntu: thank you! I work on snapd-control attributes, things get a bit messy because snapd control cannot import ifacestate nor does it have access to ifacemanager. I guess I think to think a bit how to cleanly untangle this [08:59] snapd-control attributes? [08:59] zyga-ubuntu: repo is initialized from the state? [08:59] yes [08:59] zyga-ubuntu: could I use it outside of ifacemanager? [09:00] the repository? [09:00] zyga-ubuntu: like what we did with configstate [09:00] zyga-ubuntu: yes [09:00] yes [09:00] I think so [09:00] zyga-ubuntu: cool [09:00] though locking [09:00] zyga-ubuntu: thats ok, the state lock should do it for us, no? [09:00] the ifacestate has an API that returns the repo [09:00] yes, the repo also has its own locking [09:01] zyga-ubuntu: so I guess I could move the repo/state code into ifacestate/repo and import that from both ifacestate and snapstate? [09:01] zyga-ubuntu: I imagine we will have more cases where a certain decision in snapstate is based on an interface connection [09:02] mmmm [09:02] move the interfaces/repo code to ifacestate? [09:03] unless that's really necessary I'd rather not move it, it's a huge change that would just be painful to do (unless we must) [09:03] zyga-ubuntu: there are bits that initialize repo from state, no?that live in ifstate right now? [09:03] yes, those live in ifacestate [09:03] zyga-ubuntu: I am thinking about just moving that small part into something that I can import from snapstate [09:03] ah [09:03] can you import ifacestate from snapstate? [09:04] I guess no, recursive [09:04] zyga-ubuntu: no, circular [09:04] drat [09:04] well, have a look [09:04] zyga-ubuntu: thats why I'm thinking about this split [09:04] zyga-ubuntu: it worked very well in configstate [09:04] I think the overlord split is bogus [09:04] because of go rules [09:04] they should all be able to access each other [09:04] but golang [09:04] zyga-ubuntu: yeah, its a bit annoying [09:18] mvo: well the usual approach is snapstate needs a predicate from othe *state, is for *state to set a hook on snapstate [09:19] mvo: that's how we do some of the install checks [09:19] and hi [09:19] pedronis: good morning [09:20] pedronis: yeah, I think it makes sense. especially now that I looked a bit closer it seems there is nothing that can easily be extracted [09:20] zyga-ubuntu: -^ [09:21] mvo: that's a good way to solve it, thank you for the insight pedronis! === chihchun is now known as chihchun_afk [09:26] mvo: you might to anyway stick the repo in the state cache (as we do for store and assertion db), I think it's only on the manager so far [09:27] *might need [09:28] mvo: unrelated, not super urgent question, what's the state of the work to support default-provider to install things like for base? I remember we discussed this at the really, but didn't any relevant PRs or merges, did I miss something [09:29] s/really/rally/ [09:31] pedronis: the default-provider should be in, let me double check, I worked on this during the sprint [09:33] pedronis: yeah, the repo in the manager is a bit problematic with the callback approach we are using. the callback works, I did a prototype but it shows the problem (NewInterfaceManager sets the snapstate.PlugConnected() which feels wrong) [09:34] we set callbacks that way for isolation between tests [09:34] mvo: maybe just expose the repository instead of one methof? [09:35] but I see it also "solves" the repo in manager issue [09:36] mvo: I'm very confused I don't see any mentions of default-provider in the code? am I looking at the wrong places? [09:37] pedronis: let me check [09:37] mvo: I think that didn't land as well [09:37] mvo: I saw PRs but I don't think we merged it [09:39] mvo: for context, I'm interested in that because of the discussion about what the new install/refresh API should support returning [09:39] mvo: at the rally we discussed always getting snap_yaml_raw for this? [09:39] pedronis: yeah https://github.com/snapcore/snapd/compare/master...mvo5:default-plugin-provider?expand=1 is what I have [09:40] pedronis: and indeed it looks like its not merged not even proposed :( [09:42] PR snapd#4090 closed: interfaces/mount: exspose mount.{Escape,Unescape} [09:42] PR snapd#4091 closed: cmd/snap-update-ns: allow fault injection to provide dynamic result [09:45] mvo: ah, ok, are you planning to work on more that? or did you it a blocker? or just shifted priorities? [09:45] *hit a blocker [09:46] PR snapd#4074 closed: partition/ubootenv: don't panic when uboot.env is missing the eof marker [09:48] mvo: either it's an important datapoint for the new api if we always need the full yaml in advance [09:54] PR core#62 closed: create xdg-settings inside the core snap [09:57] pedronis: I will pick it up again, it just go lost in $stuff :( [09:57] ok, thank you [10:04] mvo: I can now help smoke testing releases with a nvidia GPU [10:24] Chipaca, hi, any chance you could take a look at https://github.com/snapcore/snapd/pull/3916 ? [10:24] PR #3916: snap,wrappers: add support for socket activation [10:25] ackk: yes! thank you for reminding me [10:25] Chipaca, np, thanks for looking into it :) [10:54] ackk: small feedback from me [10:54] whee, we are at 19PRs [10:55] PR snapd#3976 closed: snap-confine: Support biarch Linux distribution confinement [10:58] Chipaca: hi, did you see the invitation from Facu to discuss about the new APIs later today? [10:58] pedronis: hiya [10:58] pedronis: yes [10:58] at my half three [11:12] pstolowski: I'm adding questions to 4013 [11:18] zyga-ubuntu, yep, thanks, looking/answering [11:20] ogra_: can we have some tests for snapcore/pi3-gadget [11:20] ogra_: enough to see that in "snapcraft" builds [11:21] ogra_: and that yaml is valid [11:33] zyga-ubuntu, thanks, how do I add a spread test? [11:34] ackk: look at tests/main/ [11:34] ackk: add a snap to tests/lib/snaps that shows this feature [11:34] ah cool, thanks [11:34] ackk: and add a directory to tests/main/ with task.yaml [11:34] look around for ideas, there are plenty of things there [11:34] if you need help just ask please [11:34] ok, thanks [11:44] anybody remember the limit on snap name length? [11:45] zyga-ubuntu, how can I run a single spread test locally? [11:46] ooh, pr updated mid-review [11:46] auch [11:46] ackk: you need a qemu image [11:46] ackk: put it in .spread/qemu [11:46] ackk: you can get some from https://spread.zygoon.pl/ [11:47] then you can run spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest [11:47] and where do I get spread ? :) [11:47] ackk: go install snapcore/spread/cmd/spread [11:47] (you may need deps) [11:48] well [11:48] ackk: go install github.com/snapcore/spread/cmd/spread [11:48] once you actually run spread locally do this: [11:48] SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest [11:48] this is more friendly [11:48] ackk: alternatively "curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz | tar xzv" if you trust that guy [11:48] oh, nice Chipaca ! :) [11:48] heh [11:48] ackk: also: read the HACKING.md [11:48] zyga-ubuntu, Chipaca thanks [11:49] ackk: run something else, just run all of main tests to ensure things work [11:49] ackk: zyga's spread.zygoon.pl images save you the adt step which can be slow [11:49] I need to refresh those :) [11:50] https://github.com/zyga/spread-qemu-images [11:51] ackk: half a review up [11:52] Chipaca, thanks [11:53] Chipaca: can you please look at 4092 [11:53] it's small and it's my last blocker [11:53] zyga-ubuntu: i'll take a look [11:54] Thank you :) [11:54] i need to go out for a bit real soon otherwise i won't be back in time for the standup [12:06] zyga-ubuntu, well, buildign in snapcraft tests the yaml automatically ... i'll see what i can do, a simple travis test should surely be easy [12:08] ogra_: yeah, that's what I was thinking about [12:08] ogra_: thank you! :) [12:09] np [12:12] * zyga-ubuntu break, back hurts too much today [12:12] pstolowski: can you do a 2nd trivial review on 4013 [12:12] er [12:12] :D [12:12] not on 4013 [12:13] on 4092 [12:21] zyga-ubuntu, sure, will do when back from lunch [12:22] zyga-ubuntu, the command line you gave me seems to be executing a whole bunch of tests, not just mine [12:22] pstolowski: thank you [12:22] ackk: can you paste your command? [12:22] oh, wait [12:22] I think my task.yaml is wrong [12:23] brb [12:33] re [12:43] mvo, Chipaca, pstolowski, pedronis: heads up, standup is one hour earlier now [12:47] zyga-ubuntu, https://travis-ci.org/ogra1/pi3-gadget [12:47] FYI [12:48] (i have other branches i want to land first, before merging this in) [12:52] checking [12:53] ogra_: whee, nice! [12:53] ogra_: maybe make apt installs less verbose [12:53] or use some trick to fold-hide it [12:53] but very nice indeed :) [12:54] well, if it doesnt fail, does anyone actually read the logs ? [12:54] (and if it fails you probably want to see all of it anyway) [12:54] i have a template ;) that makes it quick [12:55] ogra_: the fold makes it both available and out of one's way [12:55] (clicking around in webforms to enable travis for that tree took longer than adjusting the travis.yml) [12:56] ogra_: do you know of the travis CLI? [12:56] CLI ? nah, never needed it [12:57] but i'll look inot the folding ... and land the branch once i have all the splash branches in (i dont want to have to re-merge them with master) [12:57] thank you :) [12:57] np [12:58] will take a bit though ... i have meetings the next few hours [13:02] mvo, pstolowski: standup [13:03] oh [13:18] on the unpacking-my-backup-tarball side, gnome-boxes has terrible habit of naming each new VM "unknown" [13:18] I need to jump into those images and see what's what [13:18] silly silly gnome boxes [13:19] especially since you can name them in the UI already but that is just ignored [13:20] zyga-ubuntu: sorry, missed it due to lunch, [13:20] zyga-ubuntu: did it happen? DST change got me [13:20] mvo: yes [13:20] mvo: done and dusted [13:20] mvo: you get to do all the things now \o/ [13:21] /o\ [13:21] ackk: i hope my review didn't come across as overly harsh. Overall it's good! and thank you for doing that. [13:22] mvo, hi [13:22] there were some changes introduced in 2.29 [13:23] mvo, is it ready for a new run or I should wait? [13:24] cachio: I was waiting if the CE test turns out anything unexpected. but if that is green I will push 2.29-final I think [13:24] cachio: with the changes in 2.29, all very small and targeted [13:24] mvo, ok [13:25] mvo: yes, it happened [13:25] mvo: no worries, it was bound to affect someone [13:26] mvo: what about https://github.com/snapcore/snapd/pull/4101 [13:26] PR #4101: interfaces/many: miscellaneous updates based on feedback from the field (2.29) [13:26] cachio: do we have results from the automated testing yet? [13:26] mvo, for the last changes? [13:26] zyga-ubuntu: \o/ [13:27] cachio: for the beta core from friday [13:27] zyga-ubuntu: thank you [13:27] mvo, it is completed [13:27] mvo, my part [13:27] cachio: right, I mean, did we get feedback from the CE team about their automated testing yet? [13:27] PR snapd#4101 closed: interfaces/many: miscellaneous updates based on feedback from the field (2.29) [13:28] zyga-ubuntu: did we ever do thing so apps could use /run/ ? [13:28] mvo, no yet, their jobs are testing the last changes [13:28] mvo, I'll ask again [13:28] mvo: thanks [13:29] Chipaca: can you be more specific? see /run? write anything to /run? [13:29] mvo, the automated test should be executed but they didn't report that because there were some extra chnages after [13:30] cachio: hm, hm, would be nice to know if there was an issue or not. do you think you could find this out? [13:30] cachio: once we know that I will do a new 2.29 [13:30] mvo, I just sent an email [13:30] ta [13:30] PR snapd#4102 opened: tests: refactor and expand content interface test [13:31] spineau, hey [13:32] spineau, do you have the results for the build that was pushed on Friday? [13:32] cachio: in a meeting, wil lcheck [13:32] spineau, sure, tx [13:32] Chipaca, no worries. haven't had time to go through all your feedback, but thanks for looking into it [13:34] Chipaca, wrt allowing other paths for unix sockets, I think the idea is to have an initial implementation than can be later expanded. but you might want to check with niemeyer about what paths we need to support [13:41] zyga-ubuntu: create a file in /run/ (say /run/snap..blah) [13:41] ackk: niemeyer is away this week [13:41] Chipaca, i see [13:41] ackk: my problem with SNAP_DATA and SNAP_COMMON is that people have already come into issues with that [13:42] (it's too easy to hit the length limit) [13:42] I see [13:42] Chipaca: I agree that having people to have to repeat the snap name is problematic, otoh I don't see getting a decision/discussion without niemeyer around [13:42] to make things worse, systemd just ignores the entry if it's too long [13:43] otoh other snaps need to know the name too [13:43] so that's a problem either way [13:43] s/other snaps/consuming side software/ [13:45] I suppose one question is how does this mesh with the content interface from a offering/consuming pov [13:45] pedronis: agreed about decision/discussion needing gustavo [13:46] pedronis: and i wouldn't block this work on this point [13:48] Chipaca: hmmm, not sure, I'll check and get back to you [13:55] mvo, so far for the Friday release there are not issues from Cert [13:55] just missing some results from one device [14:03] snappy-m-o, autopkgtest 1642 xenial:amd64 [14:03] kyrofa: I've just triggered your test. [14:27] sergiusens, elopio kalikiana I have another meeting this morning, I may be late. Please start without me if I'm not there [14:42] zyga-ubuntu, any idea why it could happened? "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied" [14:42] I am running with sudo [14:42] Chipaca: fun, seems one of the test helpers in store_test was doing the wrong check since a while [14:43] cachio: 3.14? [14:43] cachio: if this is a 14.04 VM [14:47] zyga-ubuntu, yes [14:47] a jenkins one [14:47] cachio: it's runnin the trusty kernel still, you need to reboot it to get a xenial kernel [14:48] zyga-ubuntu, I'll try that, tx [14:48] * zyga-ubuntu -> lunch [15:00] pedronis: wrong how? [15:05] kalikiana: sergiusens: I'm alone. Are you coming? === cachio is now known as cachio_lunch [15:13] Chipaca: didn't check what it was supposed to check, seems no test was affected after fixing but a bit worrying [15:21] re [15:22] PR snapcraft#1587 closed: lifecycle: clean after deleting container [15:35] * Pharaoh_Atem blinks [15:35] apparently I was mentioned over the weekend? [15:35] or at least earlier today [15:37] zyga-ubuntu: oh, you mentioned me over debian/copyright [15:37] the only reason no one has *cared* thus far is because it's unbundled in Debian [15:37] otherwise it'd be rejected all the time [15:39] Pharaoh_Atem: I'll fix this soon, this is now bugging me too [15:39] how are you doing? [15:39] * Pharaoh_Atem sighs [15:39] I'm so busy and tired [15:40] I have had no time lately to evaluate what to fix in snapd selinux policy [15:40] and adding the dnf backend to snapcraft is still on my todo [15:45] Pharaoh_Atem: little by litte, I'm sick since yesterday, limping along slowly [15:53] PR snapd#4103 opened: snapstate: auto install default-providers for content snaps === cachio_lunch is now known as cachio [15:55] PR snapd#4092 closed: cmd/snap-update-ns: allow Change.Perform to return changes [15:58] trivial logging PR ^ [15:59] PR snapd#4104 opened: cmd/snap-update-ns: add logging to snap-update-ns [15:59] actually ^ [16:23] zyga-ubuntu, i had your 4092 opened and was adding a comment, but it landed in the meantime and github rejected me :/ [16:24] zyga-ubuntu, i was wondering if the code you removed of Keep case shouldn't be moved into Perform() to make it explicit what happens on Keep - in case new code gets added there [16:26] pstolowski: ah, sorry, I'm trying to push things forward [16:26] pstolowski: I think you can still comment on the specific code [16:26] pstolowski: as for Keep, you mean moving the return nil to Perfomr? [16:26] *Perform? [16:27]