[06:17] <Guest65397> hi
[08:00] <mvo> hey zyga-ubuntu! good morning
[08:07] <zyga-ubuntu> hey mvo
[08:07] <zyga-ubuntu> sorry, a bit stiff
[08:08] <zyga-ubuntu> I decided to move back to the office
[08:11] <mvo> zyga-ubuntu: no worries - reviews for the 2.29 targeted PRs would be great
[08:13] <zyga-ubuntu> mvo: ack
[08:14] <mup> PR snapd#4098 closed: snap-confine: allow reading uevents from any where in /sys <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4098>
[08:14] <zyga-ubuntu> mvo: btw, I think we can close the 2.28 milestone now
[08:15] <zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/4095
[08:15] <mup> PR #4095: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4095>
[08:15] <zyga-ubuntu> mvo: I think Pharaoh_Atem is 100% spot on here
[08:16] <zyga-ubuntu> mvo: shall I spend a while to make the copyright file non-fake today/
[08:16] <zyga-ubuntu> mvo: I feel bad about this because debian/copyright is one of the most important parts of debian and ubuntu
[08:16] <mvo> zyga-ubuntu: ok, but lets not block 2.29 on this as its not a regression
[08:17] <zyga-ubuntu> 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] <zyga-ubuntu> mvo: I'll get to work :)
[08:17] <mvo> zyga-ubuntu: not a regression comapred to 2.28
[08:17] <mvo> zyga-ubuntu: but yeah, I think we are in agreemeent
[08:18] <mup> PR snapd#4095 closed: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4095>
[08:19] <zyga-ubuntu> sanity timeout expired: Interrupted system call
[08:19] <zyga-ubuntu> mvo: 6 seconds not enough?
[08:20] <mvo> zyga-ubuntu: I don't know what is going on :(
[08:20] <zyga-ubuntu> mvo: maybe we should not hold that lock on this long
[08:20] <mvo> zyga-ubuntu: makes me unhappy because it may mean we will run into autopkgtest issue on the distro
[08:20] <zyga-ubuntu> mvo: I wish I could reproduce this
[08:20] <mup> PR snapd#4096 closed: spread: welcome bionic beaver <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4096>
[08:21] <mvo> zyga-ubuntu: thanks for your merges. I cherry pick in parallel to 2.29
[08:21] <zyga-ubuntu> ah, wait
[08:21] <zyga-ubuntu> 2.29~rc2 had the 6 second timeout change
[08:21] <mup> PR snapd#4099 closed: merge 2.29~rc2 release back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4099>
[08:21] <zyga-ubuntu> so maybe that was still on the 3 second one
[08:22]  * mvo nods
[08:29] <mup> PR snapd#4097 closed: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4097>
[08:30] <zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/4078
[08:30] <mup> PR #4078: tests: new test to check interfaces after reboot the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4078>
[08:30] <mvo> zyga-ubuntu: I thin for this one we need a 2.29 PR - 11 commits
[08:30] <zyga-ubuntu> mvo: we need the code to update mount units in the field, right?
[08:30] <zyga-ubuntu> mvo: yes, I was thinking the same thing after not squash merging it
[08:30] <zyga-ubuntu> mvo: I'll make one
[08:30] <mvo> 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] <zyga-ubuntu> mvo: hmm, not sure, it's a serious bug that can stop people from operating servers
[08:36] <mvo> 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] <mup> PR snapd#4101 opened:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
[08:36] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4101 is the backport
[08:36] <mup> PR #4101:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
[08:36] <zyga-ubuntu> mvo: I don't have a fix handy, let me see if there's a simple way to make that
[08:37] <zyga-ubuntu> ouch
[08:37] <zyga-ubuntu> man
[08:37] <zyga-ubuntu> back.hurt()
[08:37] <mvo> zyga-ubuntu: :( good luck
[08:38] <mvo> 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] <zyga-ubuntu> mvo: purging sytem state
[08:39] <zyga-ubuntu> that's not a reasonable solution IMO
[08:39] <zyga-ubuntu> (disrupts production)
[08:40] <mvo> zyga-ubuntu: well, for people who are affected by the bug there is no system state because snapd did not work
[08:40] <mvo> zyga-ubuntu: and for the people who are not affected there is nothing to do
[08:41] <mvo> zyga-ubuntu: alternatively we could do something trivial in the trusty postinst?
[08:41] <mvo> zyga-ubuntu: like "sed s/[Unit]\n.../fix/"
[08:43] <mup> PR snapcraft#1646 opened: sources: enforce default language in subversion info <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1646>
[08:44] <zyga-ubuntu> mvo: not really, it's something that is broken but not each time
[08:44] <zyga-ubuntu> mvo: yeah
[08:45] <zyga-ubuntu> mvo: the postinst idea is not too shabby :)
[08:53] <mvo> 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] <zyga-ubuntu> let me see
[08:55] <zyga-ubuntu> mvo: yes
[08:55] <zyga-ubuntu> mvo: you can use repo.Plug(snapName, plugName).Connections
[08:56] <zyga-ubuntu> mvo: what are you making? :)
[08:57] <zyga-ubuntu> mvo: on that note: http://turnoff.us/geek/what-your-code-looks-like/
[08:59] <mvo> 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] <zyga-ubuntu> snapd-control attributes?
[08:59] <mvo> zyga-ubuntu: repo is initialized from the state?
[08:59] <zyga-ubuntu> yes
[08:59] <mvo> zyga-ubuntu: could I use it outside of ifacemanager?
[09:00] <zyga-ubuntu> the repository?
[09:00] <mvo> zyga-ubuntu: like what we did with configstate
[09:00] <mvo> zyga-ubuntu: yes
[09:00] <zyga-ubuntu> yes
[09:00] <zyga-ubuntu> I think so
[09:00] <mvo> zyga-ubuntu: cool
[09:00] <zyga-ubuntu> though locking
[09:00] <mvo> zyga-ubuntu: thats ok, the state lock should do it for us, no?
[09:00] <zyga-ubuntu> the ifacestate has an API that returns the repo
[09:00] <zyga-ubuntu> yes, the repo also has its own locking
[09:01] <mvo> 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] <mvo> zyga-ubuntu: I imagine we will have more cases where a certain decision in snapstate is based on an interface connection
[09:02] <zyga-ubuntu> mmmm
[09:02] <zyga-ubuntu> move the interfaces/repo code to ifacestate?
[09:03] <zyga-ubuntu> 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] <mvo> zyga-ubuntu: there are bits that initialize repo from state, no?that live in ifstate right now?
[09:03] <zyga-ubuntu> yes, those live in ifacestate
[09:03] <mvo> zyga-ubuntu: I am thinking about just moving that small part into something that I can import from snapstate
[09:03] <zyga-ubuntu> ah
[09:03] <zyga-ubuntu> can you import ifacestate from snapstate?
[09:04] <zyga-ubuntu> I guess no, recursive
[09:04] <mvo> zyga-ubuntu: no, circular
[09:04] <zyga-ubuntu> drat
[09:04] <zyga-ubuntu> well, have a look
[09:04] <mvo> zyga-ubuntu: thats why I'm thinking about this split
[09:04] <mvo> zyga-ubuntu: it worked very well in configstate
[09:04] <zyga-ubuntu> I think the overlord split is bogus
[09:04] <zyga-ubuntu> because of go rules
[09:04] <zyga-ubuntu> they should all be able to access each other
[09:04] <zyga-ubuntu> but golang
[09:04] <mvo> zyga-ubuntu: yeah, its a bit annoying
[09:18] <pedronis> mvo: well the usual approach is  snapstate needs a predicate from othe *state, is for *state to set a hook on snapstate
[09:19] <pedronis> mvo: that's how we do some of the install checks
[09:19] <pedronis> and hi
[09:19] <mvo> pedronis: good morning
[09:20] <mvo> 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] <mvo> zyga-ubuntu: -^
[09:21] <zyga-ubuntu> mvo: that's a good way to solve it, thank you for the insight pedronis!
[09:26] <pedronis> 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] <pedronis> *might need
[09:28] <pedronis> 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] <pedronis> s/really/rally/
[09:31] <mvo> pedronis: the default-provider should be in, let me double check, I worked on this during the sprint
[09:33] <mvo> 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] <pedronis> we set  callbacks that way for isolation between tests
[09:34] <zyga-ubuntu>  mvo: maybe just expose the repository instead of one methof?
[09:35] <pedronis> but I see it also "solves" the repo in manager issue
[09:36] <pedronis> 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] <mvo> pedronis: let me check
[09:37] <zyga-ubuntu> mvo: I think that didn't land as well
[09:37] <zyga-ubuntu> mvo: I saw PRs but I don't think we merged it
[09:39] <pedronis> mvo: for context, I'm interested in that because of the discussion about what the new install/refresh API should support returning
[09:39] <pedronis> mvo: at the rally we discussed always getting snap_yaml_raw for this?
[09:39] <mvo> pedronis: yeah https://github.com/snapcore/snapd/compare/master...mvo5:default-plugin-provider?expand=1 is what I have
[09:40] <mvo> pedronis: and indeed it looks like its not merged not even proposed :(
[09:42] <mup> PR snapd#4090 closed: interfaces/mount: exspose mount.{Escape,Unescape} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4090>
[09:42] <mup> PR snapd#4091 closed: cmd/snap-update-ns: allow fault injection to provide dynamic result <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4091>
[09:45] <pedronis> mvo: ah, ok,  are you planning to work on more that? or did you it  a blocker? or just shifted priorities?
[09:45] <pedronis> *hit a blocker
[09:46] <mup> PR snapd#4074 closed: partition/ubootenv: don't panic when uboot.env is missing the eof marker <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4074>
[09:48] <pedronis> mvo: either it's an important datapoint for the new api if we always need the full yaml in advance
[09:54] <mup> PR core#62 closed: create xdg-settings inside the core snap <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/62>
[09:57] <mvo> pedronis: I will pick it up again, it just go lost in $stuff :(
[09:57] <pedronis> ok, thank you
[10:04] <zyga-ubuntu> mvo: I can now help smoke testing releases with a nvidia GPU
[10:24] <ackk> Chipaca, hi, any chance you could take a look at https://github.com/snapcore/snapd/pull/3916 ?
[10:24] <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[10:25] <Chipaca> ackk: yes! thank you for reminding me
[10:25] <ackk> Chipaca, np, thanks for looking into it :)
[10:54] <zyga-ubuntu> ackk: small feedback from me
[10:54] <zyga-ubuntu> whee, we are at 19PRs
[10:55] <mup> PR snapd#3976 closed: snap-confine: Support biarch Linux distribution confinement <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3976>
[10:58] <pedronis> Chipaca: hi, did you see the invitation from Facu to discuss about the new APIs later today?
[10:58] <Chipaca> pedronis: hiya
[10:58] <Chipaca> pedronis: yes
[10:58] <Chipaca> at my half three
[11:12] <zyga-ubuntu> pstolowski: I'm adding questions to 4013
[11:18] <pstolowski> zyga-ubuntu, yep, thanks, looking/answering
[11:20] <zyga-ubuntu> ogra_: can we have some tests for snapcore/pi3-gadget
[11:20] <zyga-ubuntu> ogra_: enough to see that in "snapcraft" builds
[11:21] <zyga-ubuntu> ogra_: and that yaml is valid
[11:33] <ackk> zyga-ubuntu, thanks, how do I add a spread test?
[11:34] <zyga-ubuntu> ackk: look at tests/main/
[11:34] <zyga-ubuntu> ackk: add a snap to tests/lib/snaps that shows this feature
[11:34] <ackk> ah cool, thanks
[11:34] <zyga-ubuntu> ackk: and add a directory to tests/main/ with task.yaml
[11:34] <zyga-ubuntu> look around for ideas, there are plenty of things there
[11:34] <zyga-ubuntu> if you need help just ask please
[11:34] <ackk> ok, thanks
[11:44] <Chipaca> anybody remember the limit on snap name length?
[11:45] <ackk> zyga-ubuntu, how can I run a single spread test locally?
[11:46] <Chipaca> ooh, pr updated mid-review
[11:46] <Chipaca> auch
[11:46] <zyga-ubuntu> ackk: you need a qemu image
[11:46] <zyga-ubuntu> ackk: put it in .spread/qemu
[11:46] <zyga-ubuntu> ackk: you can get some from https://spread.zygoon.pl/
[11:47] <zyga-ubuntu> then you can run spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest
[11:47] <ackk> and where do I get spread ? :)
[11:47] <zyga-ubuntu> ackk: go install snapcore/spread/cmd/spread
[11:47] <zyga-ubuntu> (you may need deps)
[11:48] <zyga-ubuntu> well
[11:48] <zyga-ubuntu> ackk: go install github.com/snapcore/spread/cmd/spread
[11:48] <zyga-ubuntu> once you actually run spread locally do this:
[11:48] <zyga-ubuntu> SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest
[11:48] <zyga-ubuntu> this is more friendly
[11:48] <Chipaca> ackk: alternatively "curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz  | tar xzv" if you trust that guy
[11:48] <zyga-ubuntu> oh, nice Chipaca ! :)
[11:48] <ackk> heh
[11:48] <Chipaca> ackk: also: read the HACKING.md
[11:48] <ackk> zyga-ubuntu, Chipaca thanks
[11:49] <zyga-ubuntu> ackk: run something else, just run all of main tests to ensure things work
[11:49] <Chipaca> ackk: zyga's spread.zygoon.pl images save you the adt step which can be slow
[11:49] <zyga-ubuntu> I need to refresh those :)
[11:50] <zyga-ubuntu> https://github.com/zyga/spread-qemu-images
[11:51] <Chipaca> ackk: half a review up
[11:52] <ackk> Chipaca, thanks
[11:53] <zyga-ubuntu> Chipaca: can you please look at 4092
[11:53] <zyga-ubuntu> it's small and it's my last blocker
[11:53] <Chipaca> zyga-ubuntu: i'll take a look
[11:54] <zyga-ubuntu> Thank you :)
[11:54] <Chipaca> i need to go out for a bit real soon otherwise i won't be back in time for the standup
[12:06] <ogra_> 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] <zyga-ubuntu> ogra_: yeah, that's what I was thinking about
[12:08] <zyga-ubuntu> ogra_: thank you! :)
[12:09] <ogra_> np
[12:12]  * zyga-ubuntu break, back hurts too much today
[12:12] <zyga-ubuntu> pstolowski: can you do a 2nd trivial review on 4013
[12:12] <zyga-ubuntu> er
[12:12] <zyga-ubuntu> :D
[12:12] <zyga-ubuntu> not on 4013
[12:13] <zyga-ubuntu> on 4092
[12:21] <pstolowski> zyga-ubuntu, sure, will do when back from lunch
[12:22] <ackk> zyga-ubuntu, the command line you gave me seems to be executing a whole bunch of tests, not just mine
[12:22] <zyga-ubuntu> pstolowski: thank you
[12:22] <zyga-ubuntu> ackk: can you paste your command?
[12:22] <ackk> oh, wait
[12:22] <ackk> I think my task.yaml is wrong
[12:23] <zyga-ubuntu> brb
[12:33] <zyga-ubuntu> re
[12:43] <zyga-ubuntu> mvo, Chipaca, pstolowski, pedronis: heads up, standup is one hour earlier now
[12:47] <ogra_> zyga-ubuntu, https://travis-ci.org/ogra1/pi3-gadget
[12:47] <ogra_> FYI
[12:48] <ogra_> (i have other branches i want to land first, before merging this in)
[12:52] <zyga-ubuntu> checking
[12:53] <zyga-ubuntu> ogra_: whee, nice!
[12:53] <zyga-ubuntu> ogra_: maybe make apt installs less verbose
[12:53] <zyga-ubuntu> or use some trick to fold-hide it
[12:53] <zyga-ubuntu> but very nice indeed :)
[12:54] <ogra_> well, if it doesnt fail, does anyone actually read the logs ?
[12:54] <ogra_> (and if it fails you probably want to see all of it anyway)
[12:54] <ogra_> i have a template ;) that makes it quick
[12:55] <zyga-ubuntu> ogra_: the fold makes it both available and out of one's way
[12:55] <ogra_> (clicking around in webforms to enable travis for that tree took longer than adjusting the travis.yml)
[12:56] <zyga-ubuntu> ogra_: do you know of the travis CLI?
[12:56] <ogra_> CLI ? nah, never needed it
[12:57] <ogra_> 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] <zyga-ubuntu> thank you :)
[12:57] <ogra_> np
[12:58] <ogra_> will take a bit though ... i have meetings the next few hours
[13:02] <zyga-ubuntu> mvo, pstolowski: standup
[13:03] <pstolowski> oh
[13:18] <zyga-ubuntu> on the unpacking-my-backup-tarball side, gnome-boxes has terrible habit of naming each new VM "unknown"
[13:18] <zyga-ubuntu> I need to jump into those images and see what's what
[13:18] <zyga-ubuntu> silly silly gnome boxes
[13:19] <zyga-ubuntu> especially since you can name them in the UI already but that is just ignored
[13:20] <mvo> zyga-ubuntu: sorry, missed it due to lunch,
[13:20] <mvo> zyga-ubuntu: did it happen? DST change got me
[13:20] <Chipaca> mvo: yes
[13:20] <Chipaca> mvo: done and dusted
[13:20] <Chipaca> mvo: you get to do all the things now \o/
[13:21] <mvo>  /o\
[13:21] <Chipaca> ackk: i hope my review didn't come across as overly harsh. Overall it's good! and thank you for doing that.
[13:22] <cachio> mvo, hi
[13:22] <cachio> there were some changes introduced in 2.29
[13:23] <cachio> mvo, is it ready for a new run or I should wait?
[13:24] <mvo> 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] <mvo> cachio: with the changes in 2.29, all very small and targeted
[13:24] <cachio> mvo, ok
[13:25] <zyga-ubuntu> mvo: yes, it happened
[13:25] <zyga-ubuntu> mvo: no worries, it was bound to affect someone
[13:26] <zyga-ubuntu> mvo: what about https://github.com/snapcore/snapd/pull/4101
[13:26] <mup> PR #4101:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
[13:26] <mvo> cachio: do we have results from the automated testing yet?
[13:26] <cachio> mvo, for the last changes?
[13:26] <mvo> zyga-ubuntu: \o/
[13:27] <mvo> cachio: for the beta core from friday
[13:27] <mvo> zyga-ubuntu: thank you
[13:27] <cachio> mvo, it is completed
[13:27] <cachio> mvo, my part
[13:27] <mvo> cachio: right, I mean, did we get feedback from the CE team about their automated testing yet?
[13:27] <mup> PR snapd#4101 closed:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4101>
[13:28] <Chipaca> zyga-ubuntu: did we ever do thing so apps could use /run/ ?
[13:28] <cachio> mvo, no yet, their jobs are testing the last changes
[13:28] <cachio> mvo, I'll ask again
[13:28] <zyga-ubuntu> mvo: thanks
[13:29] <zyga-ubuntu> Chipaca: can you be more specific? see /run? write anything to /run?
[13:29] <cachio> mvo, the automated test should be executed but they didn't report that because there were some extra chnages after
[13:30] <mvo> 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] <mvo> cachio: once we know that I will do a new 2.29
[13:30] <cachio> mvo, I just sent an email
[13:30] <mvo> ta
[13:30] <mup> PR snapd#4102 opened: tests: refactor and expand content interface test <Created by zyga> <https://github.com/snapcore/snapd/pull/4102>
[13:31] <cachio> spineau, hey
[13:32] <cachio> spineau, do you have the results for the build that was pushed on Friday?
[13:32] <spineau> cachio: in a meeting, wil lcheck
[13:32] <cachio> spineau, sure, tx
[13:32] <ackk> Chipaca, no worries. haven't had time to go through all your feedback, but thanks for looking into it
[13:34] <ackk> 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] <Chipaca> zyga-ubuntu: create a file in /run/ (say /run/snap.<snapname>.blah)
[13:41] <Chipaca> ackk: niemeyer is away this week
[13:41] <ackk> Chipaca, i see
[13:41] <Chipaca> ackk: my problem with SNAP_DATA and SNAP_COMMON is that people have already come into issues with that
[13:42] <Chipaca> (it's too easy to hit the length limit)
[13:42] <ackk> I see
[13:42] <pedronis> 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] <Chipaca> to make things worse, systemd just ignores the entry if it's too long
[13:43] <pedronis> otoh other snaps need to know the name too
[13:43] <pedronis> so that's  a problem either way
[13:43] <pedronis> s/other snaps/consuming side software/
[13:45] <pedronis> I suppose one question is how does this mesh with the content interface from a offering/consuming pov
[13:45] <Chipaca> pedronis: agreed about decision/discussion needing gustavo
[13:46] <Chipaca> pedronis: and i wouldn't block this work on this point
[13:48] <zyga-ubuntu> Chipaca: hmmm, not sure, I'll check and get back to you
[13:55] <cachio> mvo, so far for the Friday release there are not issues from Cert
[13:55] <cachio> just missing some results from one device
[14:03] <kyrofa> snappy-m-o, autopkgtest 1642 xenial:amd64
[14:03] <snappy-m-o> kyrofa: I've just triggered your test.
[14:27] <kyrofa> sergiusens, elopio kalikiana I have another meeting this morning, I may be late. Please start without me if I'm not there
[14:42] <cachio> 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] <cachio> I am running with sudo
[14:42] <pedronis> Chipaca: fun, seems one of the test helpers in store_test was doing the wrong check since a while
[14:43] <zyga-ubuntu> cachio: 3.14?
[14:43] <zyga-ubuntu> cachio: if this is a 14.04 VM
[14:47] <cachio> zyga-ubuntu, yes
[14:47] <cachio> a jenkins one
[14:47] <zyga-ubuntu> cachio: it's runnin the trusty kernel still, you need to reboot it to get a xenial kernel
[14:48] <cachio> zyga-ubuntu,  I'll try that, tx
[14:48]  * zyga-ubuntu -> lunch
[15:00] <Chipaca> pedronis: wrong how?
[15:05] <elopio> kalikiana: sergiusens: I'm alone. Are you coming?
[15:13] <pedronis> Chipaca: didn't check what it was supposed to check, seems no test was affected after fixing but a bit worrying
[15:21] <zyga-ubuntu> re
[15:22] <mup> PR snapcraft#1587 closed: lifecycle: clean after deleting container <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1587>
[15:35]  * Pharaoh_Atem blinks
[15:35] <Pharaoh_Atem> apparently I was mentioned over the weekend?
[15:35] <Pharaoh_Atem> or at least earlier today
[15:37] <Pharaoh_Atem> zyga-ubuntu: oh, you mentioned me over debian/copyright
[15:37] <Pharaoh_Atem> the only reason no one has *cared* thus far is because it's unbundled in Debian
[15:37] <Pharaoh_Atem> otherwise it'd be rejected all the time
[15:39] <zyga-ubuntu> Pharaoh_Atem: I'll fix this soon, this is now bugging me too
[15:39] <zyga-ubuntu> how are you doing?
[15:39]  * Pharaoh_Atem sighs
[15:39] <Pharaoh_Atem> I'm so busy and tired
[15:40] <Pharaoh_Atem> I have had no time lately to evaluate what to fix in snapd selinux policy
[15:40] <Pharaoh_Atem> and adding the dnf backend to snapcraft is still on my todo
[15:45] <zyga-ubuntu> Pharaoh_Atem: little by litte, I'm sick since yesterday, limping along slowly
[15:53] <mup> PR snapd#4103 opened: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
[15:55] <mup> PR snapd#4092 closed: cmd/snap-update-ns: allow Change.Perform to return changes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4092>
[15:58] <zyga-ubuntu> trivial logging PR ^
[15:59] <mup> PR snapd#4104 opened: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/4104>
[15:59] <zyga-ubuntu> actually ^
[16:23] <pstolowski> zyga-ubuntu, i had your 4092 opened and was adding a comment, but it landed in the meantime and github rejected me :/
[16:24] <pstolowski> 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] <zyga-ubuntu> pstolowski: ah, sorry, I'm trying to push things forward
[16:26] <zyga-ubuntu> pstolowski: I think you can still comment on the specific code
[16:26] <zyga-ubuntu> pstolowski: as for Keep, you mean moving the return nil to Perfomr?
[16:26] <zyga-ubuntu> *Perform?
[16:27] <pstolowski> zyga-ubuntu, yes, `if action == Keep ... ` would make the intention readable
[16:28] <zyga-ubuntu> pstolowski: I can squeeze that into the logging PR (4104)
[16:32] <cachio> mvo, confirmed that Cert team did not find any issue in the Friday's build.
[16:33] <mup> PR snapd#4105 opened: snap-seccomp: skip in-kernel bpf tests for socket() in trusty/i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4105>
[16:33] <mvo> cachio: great, I just found one last issue on trusty/i386 and pushed a PR, once that is in we are good
[16:33] <mvo> jdstrand: if you have a moment, a look at 4105 would be great.
[16:34] <cachio> mvo, great
[16:34] <mvo> jdstrand: last piece for the 2.29 release
[16:37] <zyga-ubuntu> mvo: so are we getting a beta today?
[16:37] <jdstrand> mvo: ack, done
[16:38] <zyga-ubuntu> hey jdstrand, good day
[16:39] <jdstrand> zyga-ubuntu: hello :)
[16:39] <mvo> zyga-ubuntu: yeah, 2.29-final to beta and hopefully all the way to stable
[16:39] <mvo> zyga-ubuntu: well, not today to stable :)
[16:39] <zyga-ubuntu> mvo: fingers crossed
[16:39] <zyga-ubuntu> let's hope this one is not another .8
[16:39] <mvo> zyga-ubuntu: yes!
[16:39] <mvo> zyga-ubuntu: and yes!
[16:51] <mup> PR snapd#4106 opened: many: lookup and use the url from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
[17:00] <pstolowski> zyga-ubuntu, can you take another look at #4013?
[17:00] <mup> PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
[17:07] <kyrofa> elopio, how to I subscribe to autopkgtests again?
[17:08] <elopio> snappy-m-o github subscribe 1643
[17:08] <snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1643 ([WIP] tests: run daily autopkgtest in travis).
[17:08] <mup> PR #1643: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1643>
[17:08] <elopio> kyrofa ^
[17:11] <kyrofa> snappy-m-o, github subscribe 1642
[17:11] <snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1642 (tests: move the plainbox test to the integration suite).
[17:11] <mup> PR #1642: many: pass device to store <Created by matiasb> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1642>
[17:11] <kyrofa> Wait...
[17:12] <kyrofa> Oh that was confusing
[17:12] <kyrofa> Got it, thanks elopio :)
[17:16] <zyga-ubuntu> snappy-m-o: make me a coffee
[17:16] <snappy-m-o> Command ":" / ": make" not found.
[17:16] <zyga-ubuntu> do I need to use sudo?
[17:17] <ogra_> nah, fakeroot
[17:20] <ogra_> (it is helloween ... you use costumes, not sudo)
[17:24] <diddledan> haha. I like that
[17:36] <ogra_> oh, this is lovely https://www.konsulko.com/yaml-and-device-tree/
[17:45] <om26er> flexiondotorg: Hello! mind throwing some views on https://forum.snapcraft.io/t/classic-confinement-for-android-studio/2634 ?
[18:11] <zyga-ubuntu> ogra_: that would give me a decaff coffee :D
[18:12] <mup> PR snapd#4105 closed: snap-seccomp: skip in-kernel bpf tests for socket() in trusty/i386 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4105>
[18:12] <zyga-ubuntu> ogra_: hell-o-ween?
[18:14] <zyga-ubuntu> speaking about coffee
[18:14] <zyga-ubuntu> I really want one now
[18:14] <zyga-ubuntu> darn you
[18:17] <mup> PR snapd#4107 opened: release: snapd 2.29 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4107>
[18:27]  * Chipaca EODs
[18:39] <sergiusens> is the forum down just for me?
[18:41] <kyrofa> sergiusens, working for me
[18:41] <sergiusens> hmmm
[18:41] <kyrofa> sergiusens, no no, I lied
[18:41] <kyrofa> It was working like three minutes ago when I visited this page though
[18:41] <sergiusens> ok, I'll ask is
[18:43] <sergiusens> kyrofa btw, have you seen what got moved to 2.35? :-)
[18:43] <kyrofa> sergiusens, ah! I had not
[18:43] <kyrofa> sergiusens, that's kind of a big change, you sure?
[18:43]  * sergiusens relocates as he started that thinking internet had died and it was only the forum
[18:44] <kyrofa> Hahaha
[18:44] <sergiusens> kyrofa sort of needed to be able to properly release a no "patched" version which would work on pypi
[18:44] <kyrofa> Ah ha
[18:44] <sergiusens> kyrofa the big change is patchelf ;-)
[18:44] <sergiusens> this is minor in comparison
[18:44] <kyrofa> Oh man, that's 2.35? No kidding, let's land everything
[18:45]  * sergiusens looks to the side at his time machine and wonders why it ain't working
[18:45] <sergiusens> I just need time
[18:45] <sergiusens> kyrofa well we cannot succesfully SRU if not
[18:45] <sergiusens> unless we make it a snap only release, then let's do that now ;-)
[18:45] <kyrofa> Oh, autopkgtests?
[18:46] <sergiusens> yes
[18:46] <kyrofa> Dang
[18:58] <ogra_> hmm, is the forum down or is it me ?
[18:59] <mvo> ogra_: hm, looks down indeed
[19:13] <zyga-ubuntu> forum is down
[19:18] <sergiusens> zyga-ubuntu yeah, look above
[19:18] <sergiusens> zyga-ubuntu also asked is
[19:19] <sergiusens> zyga-ubuntu but I have a suspicion it is not under their supervision
[19:21] <cmars> is forum.snapcraft.io down?
[19:21] <ikey> error: unknown command "oi-you-there", see "snap --help"
[19:21]  * ikey tried
[19:21] <cmars> duh, just read scrollback. ok, not just me :)
[19:22] <zyga-ubuntu> ikey: hey, quick question, is there any delta you have left?
[19:22]  * jdstrand also notices forum seems down
[19:23] <ikey> zyga-ubuntu, erm i think all my PRs went in
[19:23] <ikey> but ima need to rebase
[19:23] <ikey> 2.28.5 i spose
[19:23] <ikey> and see how things be
[19:23] <ikey> im guessing 2.28.x wont have any of my PRs in it
[19:26] <zyga-ubuntu> ikey: 2.28.x is stable now so would be good to have
[19:26] <ikey> ack
[19:27] <ikey> plus i want solus 4 to support snapd in the SC
[19:27] <ikey> i.e. land my branch
[19:28] <sergiusens> elopio kyrofa so you think patch the world and pip as package should go to 2.36? If so, let's get this process started
[19:29] <kyrofa> sergiusens, your call, but it's already a pretty good-sized release
[19:29] <kyrofa> We're still battling autopkgtest anyway
[19:29] <sergiusens> kyrofa let's do it then, we can navigate the SRU, it won't be more broken than before
[19:29] <sergiusens> kyrofa only for artful+
[19:29] <kyrofa> sergiusens, good deal
[19:30] <elopio> yes, please release :)
[19:30] <sergiusens> kyrofa still, focus on that PR, if we need a small 2.36 with only the elf and this stuff so be it
[19:31] <kyrofa> sergiusens, alrighty
[19:33] <sergiusens> kyrofa for which, dig deep into it ;-) Maybe just enable the failing tests on travis if that is the problem and see if it all works when ran on itself
[19:34] <kyrofa> sergiusens, I'm assuming we're talking about the BlockingIOError issues? Yeah I'm launching into subprocess
[19:34] <kyrofa> Launching myself, I mean. I guess that was ambiguous :P
[19:35] <kyrofa> Giving preference to autopkgtests though, we have a few PRs in flight that hopefully greenify them
[19:36] <kyrofa> Work should be done though
[19:37] <sergiusens> kyrofa yes, exactly that
[19:37] <sergiusens> kyrofa which PRs?
[19:37] <kyrofa> snapcraft#1642
[19:37] <mup> PR snapcraft#1642: tests: move the plainbox test to the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1642>
[19:38] <kyrofa> and snapcraft#1644 I think (right elopio?)
[19:38] <mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
[19:38] <kyrofa> Definitely the first though
[19:38] <sergiusens> kyrofa oh, those two, yeah
[19:39] <sergiusens> been waiting on those to be green for most of the day today
[19:39] <kyrofa> *sigh*
[19:40] <sergiusens> forum is back everyone
[19:40] <sergiusens> kyrofa this seems to down your alley https://forum.snapcraft.io/t/encountering-problems-when-packaging-rviz/2659
[19:41] <kyrofa> sergiusens, yeah he emailed me first, I asked him to post on the forum-- I'm all over it
[19:41] <kyrofa> Unfortunately the forum went down moments afterward, so of course our conversation continued over email :P
[19:42] <sergiusens> seems simple enough to solve, but getting an idea of why it didn't feel like the tool to solve the problem could be taken back in as feedback
[19:43] <kyrofa> Couldn't agree more
[19:44] <kyrofa> Perfect timing too, as we're revamping errors
[19:50] <sergiusens> kyrofa also for you LP: #1728481
[19:50] <mup> Bug #1728481: CXX_Flags not generated properly for catkin plugin <catkin-plugin> <snapcraft> <Snapcraft:New> <https://launchpad.net/bugs/1728481>
[19:50] <kyrofa> Yeah I saw that, I'll look into it after this
[20:06] <mup> PR snapd#4107 closed: release: snapd 2.29 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4107>
[20:56] <jdstrand> stgraber: hey, not sure you saw but if you plugs system-observe with the lxc command, this denial will go away (in 2.29+): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=16717 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[20:59] <stgraber> jdstrand: I saw your earlier ping, but that doesn't make any sense
[20:59] <stgraber> jdstrand: the only thing that snap.lxd.lxc does is call aa-exec -p unconfined
[20:59] <stgraber> jdstrand: after that we don't have any apparmor confinement, so I'm confused as to why we'd trigger that denial in the first place
[20:59] <stgraber> jdstrand: also, that denial is listed under "snap-exec", not "lxc"
[21:05] <mwhudson> jdstrand: (or anyone else) hey, does this look familiar at all? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880174
[21:05] <mwhudson> "libGL error: No matching fbConfigs or visuals found" / "libGL error: failed to load driver: swrast" on debian with nvidia
[21:06] <mwhudson> ah it's also here https://forum.snapcraft.io/t/debian-and-nvidia-issue/2583
[21:26] <mup> PR snapcraft#1642 closed: tests: move the plainbox test to the integration suite <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1642>