[00:05] <elopio> kyrofa: ugh, that sucks. I'm sorry you had to spend so much time on that.
[00:06] <kyrofa> elopio, I blame you. You asked for the change that broke the test
[00:06] <kyrofa> elopio, nahh, it was educational, for sure. I learned a lot about unittest :P
[00:07] <kyrofa> I updated the branch so it's running again, just to be doubly sure
[00:15]  * elopio sent a long message: elopio_2017-11-02_00:15:43.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/pGtjPKvKcSNwREOGnwTVeFFe>
[00:16] <elopio> kyrofa: ahh, you know me, always investing in your personal growth :D
[00:16] <kyrofa> Hahahaha
[00:17] <kyrofa> elopio, do you get the same error for cleanbuild?
[00:17] <kyrofa> Indeed, that sounds like a snapd issue
[00:18] <elopio> kyrofa, yes anything that calls lxc. It doesn't happen when running from the venv
[00:18] <kyrofa> Weird
[00:18] <kyrofa> Alright, dinner time here
[00:55] <sergiusens> kyrofa well, lesson is, you should run the full suite locally when things fail remotely ;-)
[00:56] <sergiusens> elopio mind triggering adt for everything under the sun on the 2.35 branch?
[00:56] <mlw> diddledan: hey dan, are you around?
[00:57] <sergiusens> kyrofa now that you rebased instead of adding an individual commit you should add an explanation in the PR
[00:59] <elopio> snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64
[00:59] <snappy-m-o> elopio: I've just triggered your test.
[00:59] <sergiusens> elopio do we support bionic?
[01:00] <elopio> sergiusens: is it ready? do-release-upgrade doesn't let me upgrade from a.
[01:01] <elopio> lxc doesn't have bionic either
[01:01] <sergiusens> elopio people are already on it
[01:01] <sergiusens> elopio didn't you see the ubuntu-devel list? Already open for development
[01:02] <elopio> sergiusens: how? latest daily live is from the 18: http://cdimage.ubuntu.com/daily-live/current/
[01:04] <sergiusens> elopio changing sources.list to bionic?
[01:06] <sergiusens> elopio we can already upload, debootstrap is the mechanism https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html
[01:15] <elopio> snappy-m-o autopkgtest 1650 bionic:amd6
[01:15] <snappy-m-o> Computer says nooo. See logs for details:
[01:15] <snappy-m-o>  Command '['/tmp/tmpmgtertxg/retry_autopkgtest.sh', '1650', 'bionic:amd6']' returned non-zero exit status 1
[01:15] <elopio> snappy-m-o autopkgtest 1650 xenial:amd64
[01:15] <snappy-m-o> elopio: I've just triggered your test.
[01:16] <elopio> ahh, damn
[01:16] <elopio> snappy-m-o autopkgtest 1650 bionic:amd64
[01:17] <snappy-m-o> elopio: I've just triggered your test.
[01:18] <elopio> apparently, it will run sergiusens
[01:19] <elopio> snappy-m-o autopkgtest 1650 bionic:armhf bionic:arm64
[01:19] <snappy-m-o> elopio: I've just triggered your test.
[01:44] <mup> PR snapd#4114 opened: interfaces: don't udev tag devmode or classic snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4114>
[01:57] <sergiusens> \o/
[02:46] <sergiusens> elopio look at the runaway output on zesty-amd64 :/
[02:50] <elopio> sergiusens: that's unfortunate. But well, it's probably time to close that socket properly.
[02:51] <elopio> it's weird that the socket is not opened for this test, but maybe it's just printed late or something.
[02:59] <elopio> if only I could reproduce it...
[04:52] <mup> PR snapd#4115 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via kernel <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4115>
[05:32] <mup> PR snapd#4116 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4116>
[06:16] <mup> PR snapcraft#1651 opened: tests: move the rest of ros demos tests to integration <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1651>
[06:27] <elopio> snappy-m-o autopkgtest 1651 xenial:amd64:integrationtests
[06:27] <snappy-m-o> elopio: I've just triggered your test.
[06:33] <zyga-solus> good morning
[06:42] <zyga-solus> good morning mvo
[06:43] <zyga-solus> mvo: we have a series of PRs from jamie for 2.29
[06:43] <zyga-solus> I'll be with you soon
[06:48] <mvo> zyga-solus: yeah, checking. I just approved 4114
[06:49] <pedronis> zyga-solus: mvo: hi
[06:49] <mvo> jdstrand: 4115 is not a 2.29 regression, its fallout from the changes in 2.28, right?
[06:49] <mvo> hey pedronis
[06:50] <zyga-solus> hello pedronis, how are you doing?
[06:50] <pedronis> ok, up early (for me) because we are waiting for people doing some work for the house
[06:50] <zyga-solus> mvo: 4115 was a general feature I believe, we always udev tagged devmode but we never did this at a scale introduced in 2.28
[06:51] <mvo> zyga-solus: yeah, 4115 is not a regression (technically)
[06:51] <zyga-solus> technically that is correct
[06:51] <pedronis> mvo: I  fixed the configure snapd branch (doing the simplest possible change I think), if you want to look,   it could be mergeable and we can do more in follows up
[06:52] <mvo> pedronis: cool, I have a look now. thanks for picking this up!
[06:52] <zyga-solus> mvo: please don't land 4114 just yet
[06:53] <pedronis> mvo: I also have a couple more PRs needing review but less urgent than jdstrand stuff obviously
[06:54] <mvo> zyga-solus: sure, I hold it back. whats your concern?
[06:54] <mvo> pedronis: thanks, your config fix looks good, I will go over the other two commits and then I think this gets my +1
[06:54] <mvo> pedronis: then I can do more reviews
[06:55] <zyga-solus> mvo: I want to see why tests are just for ubuntu, they should not be
[06:55] <zyga-solus> mvo: I'll test locally and push a change if they can work everywhere
[06:55] <zyga-solus> just eating breakfast
[06:55] <mvo> zyga-solus: cool, thanks
[06:55] <mvo> zyga-solus: I also saw test failures in 14.04/reexec in spread but maybe just a fluke
[06:56] <mvo> pedronis: hm, you are spot on about IgnoreHookError in configure-snapd. I think we need to make sure we do not fail hard if something is not working with the internal configure
[06:58] <pedronis> mvo: we set only on install/refresh of core, I suppose we could teach the handler to just log the error if some flag is set on the task
[06:58] <mvo> pedronis: yeah, I can prepare a followup with this fix
[07:00] <pedronis> mvo: ok, going to merge it
[07:01] <mvo> thanks!
[07:04] <pedronis> done
[07:05] <mup> PR snapd#4076 closed: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4076>
[07:22]  * zyga-solus is back now
[07:22] <mborzecki> morning everyone
[07:23] <zyga-solus> mborzecki: hello!
[07:23] <mborzecki> i'm the new guy, starting only today :)
[07:23] <zyga-solus> welcome :)
[07:23] <zyga-solus> mborzecki: we have mvo and pedronis around already
[07:24] <mborzecki> mvo: pedronis: hi
[07:24] <zyga-solus> mborzecki: pawel and john should join soon too
[07:24] <zyga-solus> (though perhaps john is off today, not sure)
[07:24] <zyga-solus> mborzecki: gustavo I believe is off this week
[07:24] <zyga-solus> mborzecki: sergio will join later today
[07:24] <pedronis> mborzecki: welcome!
[07:24] <mvo> hey mborzecki - welcome!
[07:25] <mborzecki> thanks
[07:26] <zyga-solus> mborzecki: fork and build the tree and look around
[07:26] <mborzecki> so how does it work from here? already got an email address, launchpad accounts and SSO work
[07:27] <zyga-solus> mborzecki: we're just starting with 2.29 release candidates
[07:27] <zyga-solus> mborzecki: great, you also need a github account as that's where the code is (but I'm sure you have one)
[07:27] <zyga-solus> mborzecki: mvo can add you to the team that owns snapd, I believe
[07:27] <mvo> mborzecki: a good starting point is probably to check if our "HACKING.md" is up-to-date ,)
[07:28] <mborzecki> ok, cool
[07:28] <zyga-solus> ha, excellent advice :)
[07:28] <mvo> mborzecki: i.e. if you can get started following that guide
[07:28] <mvo> mborzecki: and if its not up-to-date we appreciate PRs about the broken bits :)
[07:28] <mborzecki> ack
[07:29] <mvo> mborzecki: and if you have any questions or anything we are here for you!
[07:29] <zyga-solus> mborzecki: also tell us which distro your are using
[07:29] <mborzecki> haha, that's the interesting part, i'm using arch atm
[07:29] <zyga-solus> mborzecki: large chunk of the team is on various releases of ubuntu
[07:29] <zyga-solus> mborzecki: I'm on ... many :)
[07:29] <mvo> mborzecki: thats good, our instructions are probably lacking in this area
[07:30] <zyga-solus> mborzecki: I don't suppose you have arch commit access, do you?
[07:30] <mborzecki> i'll be sure to check them
[07:30] <mborzecki> zyga-solus: nope
[07:30] <zyga-solus> mborzecki: the current maintainer has abandoned our package so we're kind of stale there
[07:30] <mborzecki> iirc it's in community repo, right?
[07:30] <zyga-solus> that's correct
[07:31] <mborzecki> arch's rules of engagement we kind of weird last time I checked, but i could poke around and see if it's possible to do something like debians nmu
[07:31] <zyga-solus> mborzecki: I think we need to indicate the current maintainer as inactive but that requires a motion filed by a TU
[07:32] <zyga-solus> mborzecki: and then within some weeks there's a chance to remove that TU from the package and have another TU pick it up
[07:32] <mborzecki> hm, so i'm guessing you've already started the process, but it isn't going as smooth as expected?
[07:33] <zyga-solus> mborzecki: flexiondotorg was looking at this last time I think, I don't know more
[07:35] <mborzecki> fair enough, I'll start with trying to build the current master first and we'll take it from there
[07:39] <mborzecki> which go version do you use atm? i recall zyga-solus or niemeyer mentioning 1.6, is it still the case?
[07:39] <zyga-solus> mborzecki: we use different versions for each system actually, ubuntu 14.04 and 14.06 are on 1.6
[07:39] <zyga-solus> mborzecki: so that's the lowest common denominator
[07:39] <zyga-solus> mborzecki: on arch and on development versions of ubuntu we use the latest
[07:40] <zyga-solus> mborzecki: we also have almost everything in between, I think
[07:42] <mvo> mborzecki: minimal version is 1.6, not sure we care about less. it should build with everything 1.6+ if not thats a bug worth fixing
[07:43] <pedronis> mvo:  about reviews,   #4106 and #4111 are the main ones, Chipaca already did a first review
[07:43] <mup> PR #4106: 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>
[07:43] <mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[07:45] <pedronis> mvo: do you remember why we have both  switch-snap  and switch-snap-channel tasks?  they seems to do very similar but not quite identical things
[07:51] <mvo> pedronis: I think because of a race :/ iirc the snap switch command was actually coded long before it landed and in the meantime we probably did switch-snap-channel but the old switch thing did not get updated for it
[07:56] <pedronis> mvo: I see, indeed I noticed also the handler for one is in the wrong place
[07:56] <pedronis> mvo: I probably need to do something like switch-snap-channel for ignore-validation
[07:57] <mvo> pedronis: will you look at cleaning this up (just noticed the wrong place as well :/
[07:57] <mvo> pedronis: or shall I create a cleanup PR?
[07:58] <pedronis> mvo: is not too urgent, also they  really do slightly different things
[07:58] <pedronis> so needs a bit of thinking
[07:58] <pedronis> I can move the hanlder in a drive-by though
[08:00] <pedronis> mvo: they probably also need to be added to the change conflict task list
[08:02] <mvo> pedronis: +1
[08:06] <mvo> pedronis: silly question - do we have the inverse of --ignore-validation? just looking at 4111 and was wondering how this is reset
[08:09] <person112> Apologies if this isn't the right place to ask, but can interfaces be shimmed?
[08:09] <person112> As in, a snap that offers interfaces that simulate an empty 'Home' or a network that never opens a socket.
[08:09] <pedronis> mvo:  https://forum.snapcraft.io/t/make-ignore-validation-sticky-and-send-the-flag-over/2139/3  , the reverse of  "snap refresh --ignore-validation foo"  is just  "snap refresh foo"
[08:09] <mvo> pedronis: ta
[08:10] <pedronis> mvo: that's the input from Gustavo on the matter
[08:11] <pedronis> mvo: I double checked, because one  also changes the current SideInfo, switch-snap-channel and switch-snap are not interchangeable, we could add a flag but not sure worth the trouble at this point
[08:12] <mvo> pedronis: yeah, maybe a comment is enough to explain the subtle details
[08:13] <pedronis> I'll just do a small PR to move the handler closer to the other and add them conflict management
[08:14] <mvo> pedronis: sounds good
[08:14] <mvo> pedronis: and I see we test the reset of --ignore-validation, great (should have read all the way before asking :)
[08:15] <mvo> pedronis: 4111 is small enough to consider for 2.29.1, wdyt? how urgently does CE needs it?
[08:15] <pedronis> mvo: I think they would be happy if it's 4111, the server change was deployed yesterday
[08:15] <pedronis> sorry
[08:16] <pedronis> if it's in 2.29
[08:16] <pedronis> but I didn't promise it
[08:16] <mvo> pedronis: I milestoned it, for the fix from jdstrand we will need a 2.29.1 anyway so its a good target of opportunity (also low risk afaict)
[08:17] <person112> Also, is it posible to change auto-connect defaults for snaps?
[08:17] <pedronis> mvo: yea, I'm working on the follows up,  but as fix it's ok standalone
[08:18] <mvo> thanks pedronis
[08:18] <pedronis> mvo: I have a PR open about showing the flag in snap info,  and I'm working on setting/resetting the flag even if there's no update atm, like we do for channel
[08:19]  * mvo nods
[08:19] <pedronis> mvo: when do you think we will cut 2.30 ?
[08:21] <mvo> pedronis: early next week, but there are some important piece that are missing, i.e. the fix for the refresh-schedule we promised for 2.30
[08:21] <mvo> pedronis: mostly on my plate though
[08:21] <zyga-solus> mvo: early next week?
[08:21] <zyga-solus> mvo: I thought that would be only after 2.29 goes to stable
[08:22] <zyga-solus> mvo: ~3 weeks
[08:22] <mvo> zyga-solus: the schedule is that 2.29 goes to stable on Monday
[08:22]  * zyga-solus was hoping to have most of layouts in 2.30
[08:22] <zyga-solus> aha :)
[08:22] <zyga-solus> I guess 3.31 it is then
[08:22] <pedronis> mvo: I also have some stuff that we want in 2.30 because it was delayed already quite a bit
[08:22] <mvo> zyga-solus: check https://forum.snapcraft.io/t/the-snapd-roadmap/1973
[08:22] <pedronis> mvo: time to have the milestone to tag stuff?
[08:22] <mvo> pedronis: +1
[08:23] <mvo> pedronis: milestone added
[08:23] <pedronis> thank you
[08:23] <mup> PR snapd#4013 closed: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4013>
[08:24] <pedronis> mvo: marked thing accordingly (especially #4106 that I mentioned before)
[08:24] <mup> PR #4106: 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>
[08:46] <pedronis> mvo: I'm merging #4111,  it's one commit so it should be easy to cherry-pick for 2.29
[08:46] <mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[08:48] <mup> PR snapd#4111 closed: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[08:48] <mvo> pedronis: ta
[09:02] <zyga-solus> mvo: I pushed a patch to 4114
[09:03] <zyga-solus> mvo: I left some comments and I'm +1, I can also address them in a quick patch if you agree
[09:03] <mup> PR snapd#4117 opened: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4117>
[09:03] <pedronis> mvo: I created the cherry-pick ^
[09:03] <mvo> pedronis: \o/ thank you
[09:04] <mvo> zyga-solus: checking, thank you!
[09:04] <mup> PR snapd#4118 opened: overlord/snapstate: cleanups around switch-snap* <Created by pedronis> <https://github.com/snapcore/snapd/pull/4118>
[09:05] <mvo> zyga-solus: looks good, thanks
[09:06] <pedronis> mvo:  and cleanups ^
[09:07] <mvo> ta
[09:32] <mborzecki> all right, as expected the code builds just fine, the tests are mostly ok. there are some issues raised by shellcheck in tests/lib/snaps/test-snapd-service/bin/{start,start-other} and tests/lib/snaps/test-snapd-service/meta/hooks/configure
[09:32] <zyga-solus> mborzecki: nice, looks like some low hanging fruit to tweak
[09:32] <mborzecki> i can fix those, open a PR, and we'll get through the github accounts and stuff :)
[09:33] <zyga-solus> yep, sounds like a good plan
[09:33] <mborzecki> btw. noticed that you're not using gometalinter but rather just the individual tools
[09:34]  * zyga-solus never heard about gometalinter
[09:34] <mborzecki> https://github.com/alecthomas/gometalinter sort of a frontend/driver to all the linting/checking tools for go
[09:38] <pedronis> mvo: :( seems master is unhappy
[09:43] <mborzecki> do i need to signoff the commits?
[09:44] <zyga-solus> mborzecki: not really
[09:44] <zyga-solus> mborzecki: I love to but it's just me
[09:45] <mborzecki> ok, so another question, any email address or @canonical.com when signing off?
[09:45] <zyga-solus> again, no rule, I use a mix, depending on how I feel about the work
[09:45] <mborzecki> fair enough
[09:46] <mvo> pedronis: I noticed this earlier too, I have a look in a bit
[09:48] <pedronis> mvo: last one is snapd-reexec failure on 14.04 but I don't understand the issue
[09:48] <mup> PR snapd#4119 opened: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4119>
[09:49] <mborzecki> fyi my github handle is 'bboozzoo' :)
[09:49] <pedronis> mvo: seems we are installing the  same core  but don't expect that and don't get a restart
[09:49] <zyga-solus> mborzecki: reviewed
[09:50] <zyga-solus> mborzecki: I think you can remove the "have you signed the license agreement" stuff from your commit
[09:50] <pedronis> + prev_core=3377
[09:50] <pedronis> + snap install --dangerous /var/lib/snapd/snaps/core_3377.snap
[09:50] <pedronis> core 16-2.29+git446.aaee286 installed
[09:50] <pedronis> This leaves core tracking edge.
[09:50] <pedronis> + MATCH 'Requested daemon restart'
[09:51] <mborzecki> zyga-solus: i think it's only added by github PR templates, it's not part of the commit message
[09:51] <zyga-solus> it's added but when you open the PR you can still remove it
[09:51] <zyga-solus> you can hit the edit button and remove it still
[09:52] <mborzecki> done
[09:53] <mborzecki> btw. should I sign canonical CLA?
[09:56] <zyga-solus> mborzecki: I don't think you need now
[10:03]  * Chipaca looks around
[10:03] <zyga-solus> hey ho Chipaca
[10:03] <Chipaca> zyga-solus: hiya! how's things?
[10:03] <zyga-solus> Chipaca: our new colleague, mborzecki is around
[10:03] <mborzecki> Chipaca: hi there
[10:03] <Chipaca> i was trying to spot them but with 283 people it was hard
[10:03] <zyga-solus> Chipaca: damp
[10:03] <Chipaca> mborzecki: o/!
[10:04] <zyga-solus> Chipaca: but it might rain too :)
[10:04] <Chipaca> zyga-solus: it's officially "are the clothes damp, or just wet" weather here
[10:04] <zyga-solus> hehe :)
[10:05] <zyga-solus> I'm in a mood to visit UK and see
[10:05] <mborzecki> zyga-solus: is it not raining in warsaw yet?
[10:05] <zyga-solus> mborzecki: I think it stopped now
[10:06] <mborzecki> maybe it's buffering :/, damn weather
[10:06] <zyga-solus> mborzecki: "loading more rain" ;) I like that
[10:08] <mborzecki> ok, so what should look at now? go through PRs maybe?
[10:08] <zyga-solus> mborzecki: look around, we have plenty of PRs to review
[10:08] <zyga-solus> mborzecki: I think looking at that and asking questions is useful
[10:09] <zyga-solus> mborzecki: you can also check our roadmap on the forum (oh, and do sign up if you haven't already)
[10:10] <mvo> Chipaca: do you think https://forum.snapcraft.io/t/disk-usage-report/2372 might be a nice first task for mborzecki ?
[10:11] <Chipaca> mvo: that'll touch osutils, daemon, client, and cmd/snap at a minimum
[10:11] <Chipaca> mvo: but nothing particularly complex
[10:11] <Chipaca> mvo: so... yes, probably? unless we want them digging into the overlord straight away
[10:12] <mthaddon> hi there - I'm getting "cannot perform operation: mount --rbind /snap /snap: Permission denied" when running a snap I've installed inside an LXC - do I need to add the user to a particular group or something? (snap version 2.28.5 on 16.04)
[10:12] <zyga-solus> I think today should be a "figure out the code layout day"
[10:12] <zyga-solus> mthaddon: hey!
[10:12] <mthaddon> o/
[10:12] <zyga-solus> mthaddon: hmm hmm
[10:12] <zyga-solus> mthaddon: can you tell me if the container is privileged?
[10:12] <zyga-solus> mthaddon: as in, not confined at all?
[10:13] <zyga-solus> mthaddon: and can you tell me what is on the outside of the LXC container?
[10:13] <mthaddon> zyga-solus: I created the LXC with -c security.privileged=true. It's running on a xenial machine
[10:14] <zyga-solus> mthaddon: I think, (though stgraber could confirm) that it means there's no apparmor stacking in that case, so whatever is in the container is confined by what is on the outside
[10:14] <zyga-solus> mthaddon: which version of snapd do you have on the outside?
[10:15] <mborzecki> i'll look around the code and will try to get a custom built snapd up and running, then i can take a look at disk usage
[10:15] <mthaddon> 2.28.5 on the outside
[10:15] <mvo> Chipaca: thinking about suitable tasks currently not too hard but also reasonable interessting. do you have ideas?
[10:15] <zyga-solus> mthaddon: can you see if you had any apparmor denials?
[10:16] <mvo> mborzecki: cool, another interessting task might be to update the arch packaging (cc zyga-solus )
[10:16] <zyga-solus> oh, that's actually a very good idea
[10:16] <mvo> mborzecki: or fixing the current test failure in master :)
[10:17] <mvo> mborzecki: all interessting stuff :)
[10:18] <mup> PR snapd#4120 opened: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
[10:18] <mthaddon> zyga-solus: I see some, but not at the time of when I run the command that's triggering the error. I had some errors during attempted building of a snap and had to install squashfsfuse and restart the lxc to be able to build the snap (and have core installed), but it eventually worked okay
[10:18] <zyga-solus> mthaddon: I recall a case we investigated a good while back
[10:19] <zyga-solus> mthaddon: where the problem was that snapd in the inside of a privileged lxd container was actually confined by the apparmor profile of a very out of date snapd on the lxd host
[10:19] <zyga-solus> mthaddon: and we ended up saying that that is not supported much
[10:20] <mthaddon> is 2.28.5 very out of date?
[10:20] <zyga-solus> no, it's not
[10:20] <zyga-solus> I'm just trying to grok what may be going on
[10:21] <mthaddon> gotcha
[10:27] <mup> PR snapd#4121 opened: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>
[10:28] <zyga-solus> mvo: the 14.04 refresh-undo thing is a regression after the release recently?
[10:29] <mup> PR snapd#4122 opened: configstate: add support for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
[10:30] <mvo> zyga-solus: I'm not sure, I have not investigated yet
[10:30] <pedronis> mvo: I got the 14.04 snapd-reexec also on a PR
[10:30] <pedronis> it seems a real issue
[10:30] <pedronis> or something off with versions of things
[10:31] <mvo> pedronis: 4122 adds the ignore-hook errors to the internal configure (and some more tests, I think I will add more more tests
[10:31] <mvo> pedronis: yeah, I check that out
[10:31] <mthaddon> zyga-solus: should I file an issue for this somewhere to make it easier to follow up on?
[10:32] <mwhudson> mvo: /me points at debian packaging too :)
[10:32] <zyga-solus> mthaddon: I think we could use a detailed bug and I should have a look at that
[10:32] <mwhudson> mvo: mostly done, it just needs versions of dependencies checking
[10:32] <pedronis> mvo: I'll look at it in a bit
[10:32] <zyga-solus> hey mwhudson
[10:32] <mthaddon> zyga-solus: sure, LP or GH?
[10:32] <zyga-solus> mthaddon: LP please
[10:32] <mthaddon> ack
[10:33] <mvo> mwhudson: oh, the debian PR is updated, nice!
[10:33] <mvo> pedronis: no rush
[10:33] <mwhudson> mvo: uh not the PR against snapd, no :/
[10:33] <mwhudson> mvo: but the repo on alioth is
[10:34] <mwhudson> zyga-solus: hello
[10:34] <mwhudson> zyga-solus: i am going to bed :)
[10:34] <mvo> mwhudson: aha, ok
[10:34] <mvo> mwhudson: we should merge your packaging still :)
[10:34] <mvo> mwhudson: but another day, I guess its late for you
[11:00] <zyga-solus> pstolowski: hey
[11:01] <pstolowski> zyga-solus, hi!
[11:01] <zyga-solus> pstolowski: which PRs should I get started with to help you out?
[11:01] <pstolowski> zyga-solus, the two i've currently can be reviewed independently, and both are prerequisites for the upcoming ones, so pick any ;)
[11:02] <zyga-solus> ok, I'm going to go through 4120 then
[11:02] <pstolowski> zyga-solus, thanks in advance!
[11:14] <pedronis> pstolowski: I'll see to look at your branches as well this afternoon or tomorrow
[11:15] <pstolowski> thanks pedronis!
[11:39] <zyga-solus> man, my eyes fail me today
[11:50] <zyga-solus> mvo: there's going to be another tiny one for 2.29
[11:50] <zyga-solus> pstolowski you found an interesting bug
[11:51] <ogra_> popey, are you around ?
[11:51] <zyga-solus> pstolowski: 4120 done
[12:01] <ogra_> popey, how can i reack "oli" from askubuntu.com ... apparently he wants to delete all my recent snap related posts ... (i went over the 100s of long term unanswered snappy posts to point people to the forum)
[12:01] <ogra_> *reach
[12:02] <ogra_> seemingly that "breaks the rules of askubuntu, so I'm going to delete the most ..."
[12:03] <zyga-solus>  quick break
[12:03] <pstolowski> zyga-solus, thanks! ah, that, yeah, i rolled my eyes when I saw this, forgot to address it separately
[12:03] <zyga-solus> pstolowski: I'll handle the 2.29 change
[12:03] <zyga-solus> no worries
[12:03] <zyga-solus> I'm adding a new test with some reflection
[12:04] <pstolowski> cool
[12:07] <mvo> zyga-solus: oh, tell me more? but after lunch :)
[12:17] <mup> PR snapcraft#1652 opened: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>
[12:19] <sergiusens> snappy-m-o autopkgtest 1652 xenial:amd64
[12:19] <snappy-m-o> sergiusens: I've just triggered your test.
[12:27] <jdstrand> mvo: re 4115 and 4116> not a direct regression, no, but the bug is exacerbated by 2.28
[12:27] <zyga-solus> pstolowski: I have a test that catches the error now
[12:27] <zyga-solus> jdstrand: hey :)
[12:27] <zyga-solus> jdstrand: interesting iface bug pawel found today :)
[12:28] <jdstrand> zyga-solus: hey
[12:28] <jdstrand> zyga-solus: I haven't seen it yet (just woke up)
[12:29] <zyga-solus> jdstrand: I'll send a PR up in 10 minutes
[12:32] <mup> PR snapcraft#1651 closed: tests: move the rest of ros demos tests to integration <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1651>
[12:37] <zyga-solus> oh boy oh boy
[12:41] <sergiusens> oh man oh man
[12:41] <sergiusens> :-)
[12:55] <zyga-solus> mvo: two PRs up
[12:55] <mup> PR snapd#4123 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
[12:55] <mup> PR snapd#4124 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4124>
[12:56] <zyga-solus> pstolowski: please merge this into your PR and ensure it's all green
[12:56] <zyga-solus> pstolowski: thank you for finding it
[12:56] <zyga-solus> jdstrand: ^
[12:57] <zyga-solus> pstolowski: you will need trivial changes to type signature checks in the PR that changes them
[13:01] <popey> ogra_: there is a meta chat thing on askubuntu. I'd recommend dropping in there
[13:02] <popey> https://chat.stackexchange.com/rooms/201/ask-ubuntu-general-room
[13:02] <popey> You're being discussed
[13:04] <ogra_> heh
[13:08] <jdstrand> zyga-solus: oh, eww
[13:09] <jdstrand> zyga-solus: did you grep the source for other offenders?
[13:09] <zyga-solus> jdstrand: not exhaustively, I just pushed this
[13:10] <zyga-solus> jdstrand: I'm trying to see how far the bug goes
[13:10] <jdstrand> zyga-solus: grep PermanentSlot ./*.go|grep plug: just ofono
[13:11] <zyga-solus> jdstrand: beauty of dynamic typing :/
[13:13] <mlw> hey diddledan, are you around?
[13:13] <diddledan> yello
[13:13] <mlw> Could I possibly request you to add gimp-gmic and gimp-data-extras to the stage packages for the gimp snap?
[13:14] <mlw> The former more important than the latter.
[13:16] <diddledan> well the gimp snap compiles gimp from source, rather than repackaging the debian package, so gmic will need compiling too. I've given it a shot and had problems, but I can't remember where I got to
[13:17] <mlw> Ah, well thanks for looking.
[13:19] <zyga-solus> mthaddon: hey, did you report that bug by any chance?
[13:29] <pedronis> Chipaca: #4110 needs review for example (it's assertion but it's also small/clear hopefully)
[13:29] <mup> PR #4110: many:  have a timestamp on store assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/4110>
[13:30] <zyga-solus> mvo: I'll look at 14.04 now, maybe I can find something
[13:32] <mthaddon> zyga-solus: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/1729576
[13:32] <mup> Bug #1729576: cannot perform operation: mount --rbind /snap /snap: Permission denied <amd64> <apport-bug> <xenial> <snap (Ubuntu):New> <https://launchpad.net/bugs/1729576>
[13:32] <zyga-solus> mthaddon: thank you
[13:32] <zyga-solus> mthaddon: I'll check that after investigating master breakage now
[13:32] <mvo> zyga-solus: thank
[13:32] <mthaddon> ack
[13:33] <mvo> zyga-solus: you
[13:33] <mthaddon> zyga-solus: it's not blocking me, fwiw
[13:33] <om26er> flexiondotorg: hey! re: sublime-text and android-studio, did you upload them to the store ?
[13:38] <mup> PR snapd#4125 opened: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>
[13:43] <zyga-solus> jdstrand: question about security-device-cgroups-serial-port, why does it fail on fedora/opensuse/debian
[13:43] <zyga-solus> jdstrand: I'm staring at the interactive shell but I cannot figure it out just yet
[13:43] <zyga-solus> jdstrand: do you know the reason?
[13:49] <zyga-solus> mvo: interestingly 2.29 branches also fail
[13:49] <mlw> diddledan: I've put architectures: [amd64], in my snapcraft.yaml, and I've added the github repo via snapcraft.io. How come it's looking to build both i386 and armhf (the latter which fails) when I've only specified one arch?
[13:50] <diddledan> the architectures command doesn't actually say which architecture to build for. it says "this snap is compatible with". This is a bit of a weird situation
[13:51] <mlw> So how do I tell snapcraft.io not to bother with the others?
[13:51] <diddledan> you can't :-(
[13:51] <mvo> zyga-solus: fails where?
[13:51] <zyga-solus> mvo: on the 14.04 snapd-reexec test
[13:51] <zyga-solus> mvo: so this rules out anything in master recently
[13:51] <mvo> zyga-solus: yeah, I don't have anything in journalctl for the last change (core install, its change 6 for me)
[13:52] <zyga-solus> mvo: I'll report when I find something
[13:52] <mlw> Ok then. Well, last step is to figure out how to get the launcher configured correctly.
[13:52] <mvo> zyga-solus: funny enough, if `snap change 6|grep Restart` is used things look ok
[13:53] <mvo> zyga-solus: still very strange that it stopped working all by itself, no recent systemd chnage afaict (last is >2 weeks old)
[13:56] <zyga-solus> mvo: yes, I still find it puzzing
[13:58]  * Chipaca shakes his fist at everything
[13:58]  * Chipaca goes for a cuppa
[14:02] <kyrofa> sergiusens, elopio getting up to speed this morning. How's adt now? Can I help?
[14:02] <mup> PR snapd#4126 opened: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4126>
[14:02] <sergiusens> kyrofa should be on path with my quick fix on snapcraft#1652
[14:02] <mup> PR snapcraft#1652: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>
[14:02] <mvo> zyga-solus: above is a workaround but I'm not happy that I don't understand the root cause
[14:03] <mvo> zyga-solus: I think we need to get back to this at some point. but right now 2.29.1 takes priority
[14:03] <zyga-solus> mvo: aha
[14:03] <kyrofa> sergiusens, argh. Did we run into pyramid issues again?
[14:04] <sergiusens> it might be a while before we get a chance to run though, that's the queue length for the archive bionic 	1044 	- 	1086 	988 	335 	215
[14:04] <kyrofa> Once the test refactor lands (snapcraft#1638) we can fix that
[14:04] <zyga-solus> mvo: I have an idea, I will try it out now
[14:04] <mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
[14:04] <sergiusens> kyrofa no, with your skip implementation, the location of it, causing a cascading import effect
[14:04] <sergiusens> kyrofa well, things need to move out of __init__
[14:05] <sergiusens> we should also have one test package which is lean on auto importing
[14:05] <mvo> zyga-solus: tell me please :)
[14:06] <kyrofa> sergiusens, yeah, agreed
[14:07] <pedronis> mvo: seems it's also failing on 2.29
[14:08] <pedronis> also refresh-undo is failing, sometimes
[14:09] <mvo> pedronis: yeah, I have pushed a workaround for the failing test
[14:09] <mvo> pedronis: I don't understand the root cause yet though :(
[14:09] <mvo> pedronis: I am looking at refresh-undo now too (running locally to see if I can reproduce)
[14:12] <zyga-solus> mvo: sorry, some guests just arrived
[14:12] <zyga-solus> mvo: I used this to debug an issue on 14.04 earlier
[14:12] <zyga-solus> mvo: I hacked the systemd unit to redirect stdout/stderr to /var/log/snapd.log
[14:12] <zyga-solus> mvo: it is a low-tech solution to journald being broken
[14:12] <zyga-solus> mvo: I'll see what I get with that modification
[14:14] <zyga-solus> mvo: tests are in progress, I mainly want to ensure we see the restart log
[14:14] <zyga-solus> mvo: so that we know the workaround you proposed for .1 is OK
[14:14] <mvo> zyga-solus: ok, note that I pushed a workaround for the test, i.e. use snap change --last=install to get the logs. would still be nice to know why journalctl starts misheaving
[14:14] <zyga-solus> mvo: right, I want to ensure that workaround is safe for the time being
[14:14] <zyga-solus> mvo: I agree about wanting to get to the bottom of the problem
[14:15] <mvo> zyga-solus: \o/ thanks, we are in agreement
[14:15] <pedronis> Chipaca: #4112 is also ready for input
[14:15] <mup> PR #4112: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>
[14:16] <kyrofa> snappy-m-o, github subscribe 1652
[14:16] <snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1652 (tests: fork skip into snaps_tests).
[14:16] <mup> PR #1652: Correct interface connection JSON documentation (used an object inste… <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1652>
[14:19] <kyrofa> sergiusens, 2.34+git89.a25cfcc is in edge, but that commit is unknown to me
[14:20] <kyrofa> Do you know what it is?
[14:20] <sergiusens> kyrofa git pull -> "internal: more gracefully determine host OS (#1636)"
[14:20] <mup> PR #1636: snap: don't load unsupported implicit hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1636>
[14:20] <sergiusens> lol
[14:21] <sergiusens> default for pounding a number is snapd PRs, oh well
[14:21] <kyrofa> sergiusens, oh duh, I wasn't up to date. Sorry
[14:21] <mup> PR snapd#4124 closed: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4124>
[14:21] <kyrofa> Very good, we now have a snap that can be used on trusty, that's super exciting
[14:30] <elopio> kyrofa: sergiusens when is a good time for you to talk about snapcraft in the code-in? what about 16 UTC?
[14:32] <sergiusens> elopio is that an hour and a half from now?
[14:32] <elopio> sergiusens: yes
[14:32] <sergiusens> no that I am on gnome I have a hard time quickly looking at timezones :-P
[14:33] <sergiusens> when you say utc I home you mean real utc (not dst) ;-)
[14:33] <sergiusens> elopio can it be 1 hour 30 minutes further down?
[14:33] <ogra_> dsutc
[14:35] <elopio> sergiusens: so, now?
[14:36] <zyga-solus> hmm, me got no logs at all
[14:36] <zyga-solus> WTF
[14:37] <sergiusens> elopio further into the future, not the past :-)
[14:37] <sergiusens> move the pointer in time further from now, not closer (now is my reference)
[14:38] <elopio> sergiusens: 18UTC works for me.
[14:39] <sergiusens> elopio ok, can do if it is 30' at 18:30 as I have a knee appointment for this constant pain I've been having since I left for the past sprint
[14:42] <kyrofa> sergiusens, that's what you get for fighting with the aikido masters
[14:43] <elopio> 30 minutes should be enough to get us started and continue distributed. kyrofa what about you?
[14:44] <kyrofa> elopio, I'm there
[14:45] <elopio> ok, so if I understood correctly, from 18:30 to 19:00. I'll send the invite. Please correct it if I misunderstood.
[14:46] <kyrofa> Wait... I understood 1800-(1830-driving delta)
[14:47] <zyga-solus> mvo: drat
[14:47] <zyga-solus> mvo: I ran it with extra logging
[14:47] <zyga-solus> mvo: and it passed!!!
[14:47] <zyga-solus> mvo: I didn't merge your branch yet so it was on vanilla setup
[14:47] <zyga-solus> maybe it is really just random in some way
[14:48] <zyga-solus> (I honestly think 14.04 needs love)
[14:48] <elopio> sergiusens: do you mean start at 18:30 or finish at 18:30 ?
[14:49] <sergiusens> kyrofa elopio if I can pick, 17:30 to 18:00
[14:49] <sergiusens> or I will take the meeting from the waiting room ;-)
[14:50] <mvo> zyga-solus: i was seeing it reliable (4/4) in my 14.04 qemu spread runs
[14:51] <elopio> sergiusens: I have the community council meeting from 17 to 18.
[14:51] <elopio> kyrofa sergiusens there is still plenty of time for this, what about tomorrow, maybe at 17UTC?
[14:52] <zyga-solus> mvo: I was running linode (not enough ram for two vms)
[14:52] <zyga-solus> mvo: but it did fail each time earlier
[14:52] <zyga-solus> mvo: restarted at 15:47, let's see if it fails now
[14:57] <tpatel> Does private snap auto-update on the refresh schedule if new version is available?
[14:57] <mup> PR snapd#4127 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>
[15:03] <tpatel> Does private snap auto-update on the refresh schedule if new version is available?
[15:03] <mup> PR snapd#4128 opened: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4128>
[15:04] <kyrofa> tpatel, I thought so. Does that seem to not be the case?
[15:05] <kyrofa> tpatel, although I see this: https://forum.snapcraft.io/t/automatic-refresh-of-private-snaps/2530
[15:06] <kyrofa> Is that the behavior you're seeing?
[15:06] <tpatel> kyrofa: I have unit in the field for 7 days and I have new snap updated on the store past couple days and haven't seen it getting updated.
[15:07] <kyrofa> tpatel, please join in on that thread, then. I pinged a snapd dev there to try and get it some attention
[15:08] <tpatel> kyrofa, ok. I did not see any post for past 14 days on that thread so decided to raise my question here. Thanks though.
[15:09] <kyrofa> tpatel, the thread is waking up. Please do add your details there
[15:12] <jdstrand> mvo: note PR 4127. I didn't tag this one for 2.29 since I discovered it before anyone in nthe field noticed, but it has all the same qualities as 4115 and 4116 for inclusion
[15:12] <mup> PR #4127: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>
[15:13] <jdstrand> mvo: so, I'll leave it up to you
[15:14] <mvo> jdstrand: checking
[15:15] <mvo> jdstrand: looks good, thanks, I think we want this too, also looks reasonable small and safe
[15:15] <jdstrand> mvo: I agree. note that I am off tomorrow, back monday
[15:15] <jdstrand> mvo: thanks!
[15:15] <Chipaca> sergiusens: is there a way for snapcraft to make a snap private, or is it web-only?
[15:16] <mvo> jdstrand: thank you, special \o/ for all these fixes!
[15:16] <sergiusens> Chipaca `snapcraft register <snap-name> --private`
[15:16] <jdstrand> mvo: fyi, for 4114, 4415 and 4116, I'm getting unrelated spread test failures. linode:ubuntu-14.04-64:tests/main/snapd-reexec pretty consistently, but just now linode:ubuntu-core-16-64:tests/main/lxd failed
[15:17] <jdstrand> I've restarted builds several times. not sure if I should stop doing that
[15:18] <jdstrand> mvo: can you advise? ^
[15:18] <Chipaca> sergiusens: no, it's already registered
[15:19] <jdstrand> mvo: linode:ubuntu-core-16-64:tests/main/snap-auto-mount popped out in 4116
[15:19] <sergiusens> Chipaca then no, web only (or maybe not even there)
[15:19] <jdstrand> anyway, I'm happy to keep pressing restart build and see if one makes it if you want
[15:19] <sergiusens> Chipaca we have no APIs for this
[15:19] <Chipaca> sergiusens: it's doable on the web
[15:19] <Chipaca> sergiusens: ok
[15:20] <Chipaca> sergiusens: should we? :-)
[15:20] <Chipaca> it'd make explaining what i did easier (copy-paste from terminal vs saying where to click)
[15:20] <Chipaca> but, not important
[15:20] <mvo> jdstrand: I noticed the snapd-reexec and there is a PR up for it. the lxd one is new as is the snap-auto-mount
[15:21] <Chipaca> pedronis: do we have a way for the user to check if their macaroon is still valid?
[15:21] <jdstrand> mvo: yes, but those are intermittent. I've pressed 'restart build' multiple times and they only just popped up
[15:21] <jdstrand> maybe new PRs since I submitted were comitted...
[15:21] <jdstrand> committed*
[15:22] <zyga-solus> re
[15:22] <zyga-solus> it failed now
[15:22] <zyga-solus> looking
[15:22] <jdstrand> mvo: I think I'll just document that the failures are unrelated
[15:24] <pedronis> Chipaca: I'm not sure, this is not our most well worked out area
[15:24] <zyga-solus> jdstrand: hey
[15:25] <zyga-solus> jdstrand: quick request if you have the time today
[15:25] <zyga-solus> jdstrand: can you please look at that one method I mentioned earlier, the one that sets up tmpfs "overlay"
[15:25] <zyga-solus> jdstrand: I'll polish tests and everything else but if you disagree about the fundamental design of that I'd rather know earlier
[15:25] <zyga-solus> jdstrand: do you need pointers to the code?
[15:26] <pedronis> Chipaca: refresh itself doesn't gives back an error if your macaroon is expired, it just skips stuff
[15:26] <pedronis> we can probably do a bit better in the new API
[15:26] <Chipaca> pedronis: auto-refresh does not refresh private, for some reason
[15:26] <mup> PR snapd#4129 opened: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4129>
[15:27] <pedronis> Chipaca: auto refresh is not different from "snap refresh"
[15:27] <pedronis> except the user 0
[15:27] <pedronis> vs what you are
[15:27] <Chipaca> pedronis: ¯\_(ツ)_/¯
[15:27] <pedronis> Chipaca: we might have hit the  we don't refresh snaps as the user that installed them
[15:27] <pedronis> issue
[15:28] <pedronis> which we have ignored so far
[15:28] <pedronis> (it's a bit of a mess)
[15:29] <pedronis> there are a couple of approaches to that
[15:29] <Chipaca> pedronis: to unblock these people, should i tell them to snap login as root (without sudo)?
[15:29] <Chipaca> sounds horrible
[15:30] <pedronis> I don't know
[15:30] <pedronis> Chipaca: remind me why sudo wouldn't work?
[15:30] <Chipaca> pedronis: because we detect sudo and grab the actual user id
[15:30] <pedronis> ah
[15:31] <pedronis> so yes, maybe
[15:31] <pedronis> or they stay without updates
[15:31] <Chipaca> hmmm
[15:40] <Chipaca> pedronis: autorefresh is done with userID 0, so no
[15:40] <zyga-solus> mvo: ha
[15:40] <zyga-solus> mvo: I have a log
[15:40] <pedronis> Chipaca: no, what?
[15:40] <zyga-solus> mvo: and it looks suspicious
[15:40] <Chipaca> pedronis: doing snap login as root
[15:41] <pedronis> ?
[15:41] <mvo> zyga-solus: suspicious in what way? is it not resdtarting
[15:41] <Chipaca> pedronis: "should i tell them to snap login as root" <- no
[15:41] <zyga-solus> correct
[15:41] <pedronis> Chipaca: it would fix stuff no?
[15:41] <zyga-ubuntu> error: when trying to listen on /run/snapd.socket: socket "/run/snapd.socket" already in use
[15:41] <Chipaca> pedronis: the _snapd user_ is 0, not the system user
[15:41] <zyga-ubuntu> that's the error
[15:41] <zyga-ubuntu> then snapd dies
[15:41] <zyga-ubuntu> (I presume)
[15:41] <pedronis> Chipaca: ah, so whoever logged in first?
[15:42] <Chipaca> pedronis: no, that's 1
[15:42] <Chipaca> 0 is no-one
[15:42] <zyga-ubuntu> mvo: I used > rather than >> so I don't know anythin more, restarted now to get earlier logs
[15:42] <pedronis> Chipaca: mmh, ok
[15:42] <pedronis> so no, there's no workaround
[15:42] <pedronis> we need to fix all the things
[15:43] <zyga-ubuntu> mvo: perhaps we could consider doing this in 14.04 package
[15:43] <zyga-ubuntu> +ExecStart=/bin/sh -c "@libexecdir@/snapd/snapd >>/var/log/snapd.log 2>&1"
[15:43] <zyga-ubuntu> and add a logrotate.d entry
[15:44] <mup> PR snapd#4117 closed: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4117>
[15:45] <mvo> jdstrand: can we get 4114 targeted for 2.29 as well please? i.e. start from upstream/release/2.29 and cherry-pick the commits please
[15:46] <mvo> zyga-ubuntu: hmmm, interessting. and strange. so you get this error when it tries to restart?
[15:47] <zyga-solus> mvo: yes, that's the only thing in the log after the test
[15:47] <zyga-solus> mvo: I fixed the unit to append to the log now
[15:47] <zyga-solus> mvo: so we can know more in 15 minutes
[15:47] <mvo> cool
[15:47] <pedronis> Chipaca: I think we are converging toward the idea that private snaps are mostly for development, but this will bite also paid snaps
[15:48] <Chipaca> pedronis: what does "mostly for development" mean?
[15:49] <Chipaca> they still need to be refreshed, surely
[15:51] <pedronis> Chipaca: I don't know
[15:53] <jdstrand> zyga-solus: this popped out: http://paste.ubuntu.com/25873639/ on 17.10 classic with core from candidate
[15:54] <pedronis> Chipaca: anyway afaict this never worked, it's not a regression, no?
[15:54] <jdstrand> zyga-solus: I wasn't doing anything special. I can say that this snap plugs every interface via a corresponding command (I'm writing a spread test)
[15:54] <zyga-solus> jdstrand: hey
[15:54] <zyga-solus> jdstrand: mvo noticed this on the forum
[15:55] <zyga-solus> jdstrand: this is not a new bug but we fixed logging
[15:55] <jdstrand> zyga-solus: but ultimately just a missing rule
[15:55] <zyga-solus> jdstrand: logs from snap-update-ns now actually show up
[15:55] <jdstrand> that's nice :)
[15:55] <zyga-solus> jdstrand: thank you for looking at this!
[15:55] <jdstrand> zyga-solus: I'm trying to get my spread test working. will you fix the profile or shall I?
[15:56] <zyga-solus> jdstrand: note that we had a very very old rule for fonts that we never implemented but this was recently done by jamesh
[15:56] <pedronis> Chipaca: or maybe it worked when we were running refresh in a timer and if somebody did login as really root?
[15:56] <zyga-solus> jdstrand: I'm looking at 14.04 but I can switch to that next, feel free to ignore if you have more urgent things
[15:57] <cachio> mvo, any updates for the 29.1?
[15:58] <jdstrand> zyga-solus: I probably won't get to it today (lots to do before I go eow), but if I have time and I see you haven't done it, I'll try
[15:59] <zyga-solus> jdstrand: sounds good, I'll try to do it soon
[15:59] <zyga-solus> jdstrand: should be easy rule tweak
[15:59] <zyga-solus> jdstrand: spread test will be "hardest" ;-)
[16:00] <pedronis> mvo: did you merged the workaround for 14.04 ?
[16:01] <zyga-solus> pedronis: not yet
[16:03] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/4130
[16:03] <mup> PR #4130: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
[16:04] <Chipaca> pedronis: yeah, refresh timer + no sudo handling would make this work
[16:04] <mup> PR snapd#4130 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
[16:04] <jdstrand> mvo: do you want me to do the same for 4115, 4116 and 4127?
[16:04] <pedronis> Chipaca: we discussed killing the timer at some point though
[16:07] <zyga-solus> jdstrand: 4130 has unrelated changes
[16:07] <zyga-solus> jdstrand: please rebase -i and drop them
[16:08] <jdstrand> dang it
[16:08] <jdstrand> meh. cherry-pick didn't do what i wanted
[16:09] <kyrofa> jdstrand, what were you hoping it'd do?
[16:09] <sergiusens> meh, snapd tests flooded the adt queue
[16:09] <jdstrand> grab just my commit
[16:09] <Chipaca> pstolowski: when do cookies get cleaned up?
[16:10] <kyrofa> jdstrand, that's exactly what cherry-pick should do. What DID it do?
[16:10] <zyga-solus> mvo: I have a full log now
[16:10] <zyga-solus> mvo: we are *not* restarting
[16:10] <zyga-solus> mvo: I'll pastebin now
[16:10] <Chipaca> pedronis: we'd have to store the user id in state, right?
[16:10] <jdstrand> pulled in a bunch of stuff between 2.29 and master
[16:10] <pedronis> Chipaca: maybe,   or send all the macaroons we have and let the store figure it out
[16:11] <pedronis> something to do with the new api
[16:11] <Chipaca> pedronis: can we do that?
[16:11] <Chipaca> ah
[16:11] <zyga-ubuntu> http://paste.ubuntu.com/25873750/
[16:11] <jdstrand> I think anyway. redoing
[16:11] <mup> PR snapd#4130 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
[16:11] <kyrofa> jdstrand, what did you cherry-pick? A merge commit? :P
[16:11] <pstolowski> Chipaca, see removeSnapCookie in snapstate - discardSnap
[16:12] <pedronis> Chipaca: currently API take only one user macaroon (via header), but the new api could take multiple but not something we can do without discussing with store people
[16:12] <zyga-solus> mvo: ah, sorry, my grep was bad; we are restarting
[16:12] <zyga-solus> mvo: I think your workaround is safe for 2.29
[16:13] <jdstrand> kyrofa: no, the hash from my local branch
[16:13] <mvo> zyga-solus: cool, waiting for spread to actually run :/
[16:13] <Chipaca> pstolowski: ok, new question: why doesn't it work? :-)
[16:13] <zyga-solus> mvo: is there a topic where I can put this info? I can start a new one
[16:15] <mvo> zyga-solus: I think we need a new one
[16:16] <zyga-solus> doing that then
[16:16] <Chipaca> pstolowski: (i have 1 snap installed -- core -- and 59 cookies: 23 for core, the rest for snaps that i no longer have)
[16:17] <jdstrand> kyrofa: so I did: git checkout -b foo upstream/release/2.29 ; git cherry-pick <hash from my local branch based on upstream/master>. that pulled in other commits
[16:17] <pstolowski> Chipaca, oh. that's bad. I don't know without investigating. we have a spread test that checks that, should work...
[16:17]  * jdstrand reads man page
[16:19] <mvo> jdstrand: hm, what you did looks correct
[16:20] <pedronis> Chipaca: one thing to consider/issue, is that we don't have good spread tests for private snaps atm
[16:20] <pstolowski> Chipaca, hmm I can confirm I've a few leftovers on my system. but just one cookie file for core. what are the filenames of your cookies for core?
[16:20] <mvo> jdstrand: I can also help, waiting for tests anyway
[16:21] <kyrofa> jdstrand, yeah what you did sounds right
[16:22] <kyrofa> jdstrand, can you push your local branch? I'm curious now
[16:24] <jdstrand> actually, the local branch is ok. maybe I messed something up on the github end
[16:24]  * jdstrand tries again
[16:26]  * zyga-solus runs another 14.04 tes
[16:26] <zyga-solus> my earlier data had a flaw that was causing false positives, I may have a chance to see the real error now
[16:27] <Chipaca> pstolowski: the filenames of my cookies?
[16:27]  * sergiusens takes a lunch break
[16:27] <jdstrand> ok, yes. I thought it picked release/2.29 for the merge but it didn't, then confusion ensued
[16:27] <pstolowski> Chipaca, /var/lib/snapd/cookie/*
[16:27] <Chipaca> pstolowski: ah! i meant in staet
[16:27] <jdstrand> mvo, zyga-solus: https://github.com/snapcore/snapd/pull/4131
[16:27] <mup> PR #4131: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>
[16:27] <mup> PR snapd#4131 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>
[16:27] <Chipaca> state
[16:27] <mvo> jdstrand: \o/
[16:27] <Chipaca> pstolowski: in /var/libi/snapd/cookie i have snap.core
[16:28] <Chipaca> s/bi/b/
[16:28] <jdstrand> mvo: ok, did you want me to do the same for 4115, 4116 and 4127?
[16:28] <mvo> jdstrand: please
[16:28] <jdstrand> ok
[16:30] <pstolowski> Chipaca, okay, I see junk in my state as well :(
[16:30] <pedronis> Chipaca: we need to resurrect efforts in that area
[16:30] <pstolowski> Chipaca, the logic around snapst.Sequence doesn't work as expected, apparently
[16:31] <mvo> Chipaca: uh, junk?
[16:32] <Chipaca> mvo: yeah
[16:33] <Chipaca> pstolowski: it does work sometimes though, as i have no cookies for xbill :-)
[16:33] <pstolowski> Chipaca, is there any magic around snapst.Sequence == 0 or snapst.Sequence == 1? wrong assumptions on my side around them?
[16:33] <pedronis> well, junk, as in, too many cookies
[16:33] <pedronis> not random data
[16:33] <pstolowski> Chipaca, yeah, as I said, there is a spread test, but it's a very simple scenario apparently
[16:33] <pstolowski> mvo, snap cookies are not always removed and left in the state and on disk
[16:34] <mvo> pstolowski: hmmm, ok
[16:34] <pedronis> are they no removed? or are they created even when there's one?
[16:35] <pedronis> one almost never removes core
[16:35] <mup> PR snapd#4132 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4132>
[16:35] <pedronis> pstolowski: do we have a cooke per snap? or per revision?
[16:36] <Chipaca> i can confirm that it doesn't always work: i just installed a snap, removed it, and the cookie is still there
[16:36] <Chipaca> nothing refresh-ish about it :-)
[16:36] <pstolowski> pedronis, right. too many are created. there should be one per snap, regardless of how many revisions you have
[16:36] <Chipaca> (i was fearing it was some weird refresh thing -- but no)
[16:38] <pedronis> createSnapCookie doesn't check if there is one already afaict
[16:38] <mup> PR snapd#4133 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4133>
[16:39] <Chipaca> so now i've installed and removed the same snap twice, and the first time it left the cookie behind, the second it didn't
[16:39] <Chipaca> hmmm
[16:40] <Chipaca> hmmm
[16:40] <mup> PR snapd#4134 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4134>
[16:40] <pstolowski> pretty weird, i just tested with brand new snap, all was cleaned up.
[16:41] <Chipaca> HAH
[16:41] <pstolowski> pedronis, but do LinkSnap does check snapst.Sequence.. should only createCookie for first snap installed. unless this is wrong assumption about sequence
[16:41] <Chipaca> pstolowski: restart snapd between install and remove
[16:42] <Chipaca> we might be being too lazy wrt loading the cookies
[16:42] <Chipaca> dunno :-)
[16:43] <pedronis> pstolowski: install a snap, disable it, reenable it, it will create two cookies (for example)
[16:43] <jdstrand> mvo: ok, 4114, 4115, 4116, and 4127 all have PRs (4131-4134) which are milestoned to 2.29. let me know if you need anything else
[16:44] <Chipaca> delicious, delicious cookies
[16:44] <pedronis> I think
[16:44] <mup> PR snapd#4135 opened: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
[16:44] <pedronis> I mean, I fear there are corner cases, such that just using the len of the sequence is not enough
[16:45] <pedronis> or maybe not
[16:45] <pedronis> something is off for sure
[16:46] <Chipaca> pedronis: are you digging into this?
[16:46] <pedronis> not really
[16:47] <pedronis> what I see is that the code is naive, it will mutate the dict even or error
[16:47] <pedronis> that's usually not what we do
[16:48] <pedronis> we store things back into state usually only when we know the handler is succeding
[16:49] <mvo> jdstrand: thank you
[16:53] <pedronis> pstolowski: undoLinkSnap is strange there is code that check len sequence before we manipulate sequence and there is code doing the check after for something else
[16:54] <pstolowski> pedronis, Chipaca I think the main problem is in snapmgr.GenerateCookies, i think this is the main source of duplicates
[16:54] <pedronis> why would it be ?
[16:55] <pedronis> pstolowski: UnlinkCurrentSnap has no remove cookie
[16:55] <pedronis> that's also strange
[16:56] <Chipaca> it seems every time i start snapd i get more cookies
[16:56] <Chipaca> gah!
[16:56] <Chipaca> pstolowski: you're right
[16:56] <pstolowski> pedronis, the snap-cookies map uses cookieId as a key, GenerateCookies uses snap name as a key; I think this was changed at some point
[16:56] <Chipaca> pstolowski: yep, that's where these are coming from
[16:57] <pstolowski> and this method got out of sync
[16:57] <pedronis> :/ blargh
[16:57] <pstolowski> and perhaps there are edge cases as you say pedronis
[16:57] <Chipaca> but also, agreed about pedronis wrt cookies not getting cleaned up on handler failure
[16:57] <Chipaca> s/about/with/
[16:57] <Chipaca> pstolowski: in a handler every return error needs to undo everything the handler did in there
[16:57] <zyga-solus> drat 14.04
[16:58] <zyga-solus> systemd behaves super oddly
[16:58] <zyga-solus> quick coffee break
[16:58] <pstolowski> pedronis, Chipaca I'll work on a fix. but I'm abit unclear about doDiscardSnap vs UnlinkCurrentSnap, isn't discard snap the only place to do it?
[16:58] <pedronis> and there is something strange about unlink-current-snap vs its undo  (the latter create a cookie but the former doesn't remove it)
[16:58] <pedronis> pstolowski: it depends
[16:58] <pedronis> there are various way to it
[16:58] <pedronis> but whatever you do needs to be balanced
[16:59] <Chipaca> pstolowski: removing the 'break' in removeSnapCookie should go a long way to cleaning this up :-)
[16:59] <Chipaca> anyway. cuppa tea.
[16:59]  * Chipaca afk
[17:00] <pedronis> pstolowski: it's a bit late for me, but we can chat another day about this,  what I'm noticing is that the remove/creat don't seem symmetrics to me atm
[17:00] <pstolowski> Chipaca, I know I know...
[17:00] <pedronis> and also that we Set cookies into the state too early in the handlers
[17:00] <pstolowski> pedronis, k, thanks for taking a look at this.. I'll investigate further
[17:15] <mup> PR snapcraft#1653 opened: internal: don't reuse variable in OsRelease <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1653>
[17:15] <mborzecki> ok guys, i'm calling it a day
[17:31] <Chipaca> YESSS
[17:31] <Chipaca> it works
[17:31]  * zyga-solus hugs Chipaca 
[17:31] <Chipaca> zyga-solus: wait until you see it :-)
[17:31] <Chipaca> anyway, forum, and then eod
[17:33] <zyga-solus> I'm in 14.04 land
[17:33] <zyga-solus> getting closer
[17:33] <zyga-solus> feels very weird
[17:35]  * Chipaca hugs zyga-solus 
[17:35] <Chipaca> zyga-solus: you're needing them more than me!
[17:35] <zyga-solus> Chipaca: hehe
[17:35] <Chipaca> systemd *and* 14.04
[17:35] <zyga-solus> Chipaca: the 14.04 abyss hugs me all the time
[17:35]  * ogra_ wasnt aware there is a 14.04 solus 
[17:36] <zyga-solus> ogra_: offtopic, I recently installed windows on my thinkpad
[17:37] <ogra_> so where is the zyga-windows nick then ?
[17:37] <zyga-solus> ogra_: so ubuntu 17.10, vm with windows 10, WLS inside
[17:37] <zyga-solus> ogra_: to see what kind of "kernel" features are available :)
[17:37] <ogra_> heh
[17:37] <zyga-solus> ogra_: nah, I don't run irc from zyga-ubuntu-windows-wsl-ubuntu
[17:37] <zyga-solus> :D
[17:42] <mup> PR snapd#4131 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4131>
[18:06] <mup> PR snapd#4128 closed: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4128>
[18:08] <zyga-solus> mvo: that 14.04 bug is weird
[18:08] <zyga-solus> I have a feeling my changes are not being used
[18:08] <zyga-solus> I just added "trolololo" to a startup line to see if it shows up
[18:11] <mvo> zyga-solus: hm, ok
[18:12] <zyga-solus> mvo: 10 minutes to find ut
[18:12] <zyga-solus> out
[18:14] <zyga-solus> ha
[18:14] <zyga-solus> so curious now
[18:14] <zyga-solus> my changes in outer function are picked up
[18:15] <zyga-solus> those on the inner one are not, so I made a mistake
[18:15] <zyga-solus> looking
[18:16] <zyga-solus> ha
[18:16] <zyga-solus> I see it
[18:16] <zyga-solus> ok, let's see what this unfolds
[18:18] <zyga-solus> we seem to report one error incorrectly, swallowing the real problem
[18:24] <zyga-solus> mvo: OMG :)
[18:24] <zyga-solus> either it's a very simple bug
[18:24] <zyga-solus> or it's very non-tricky code
[18:24] <zyga-solus> er
[18:24] <zyga-solus> tricky code
[18:24] <zyga-solus> mvo: if you are still around, please open daemon.go
[18:25] <zyga-solus> hmmm
[18:25] <zyga-solus> actually, no :/
[18:25] <zyga-solus> darn
[18:25]  * zyga-solus keeps looking
[18:28] <mvo> zyga-solus: are you sure its not a external bug?
[18:28] <zyga-solus> mvo: no, just me making silly mistakes still
[18:28] <zyga-solus> mvo: that lead me astray
[18:28] <mvo> zyga-solus: to me it smeels like journalctl is swallowing data
[18:30] <zyga-solus> yes but attempting to see what's really going on lead me on a goose chase
[18:30] <zyga-solus> I should now have both correct logs _and_ not disturb socket activation
[18:31] <mvo> zyga-solus: great
[18:33] <mvo> zyga-solus: tests are really slow today, but I hope we can still do 2.29.1 tonight, lets see
[18:33] <zyga-solus> mvo: yeah, would be good to do that
[18:33] <zyga-solus> thank you for staying longer to ensure that
[18:36] <mvo> zyga-solus: there is new info from the libreoffice report in the "2.29 release cycle started" thread
[18:37] <zyga-solus> oh, great - looking
[18:37] <zyga-solus> aha
[18:37] <zyga-solus> I can fix those very quickly
[18:38] <zyga-solus> mvo: the bug is that we try rw sharing and the rules are for "ro" sharing
[18:39] <zyga-solus> oh, curious, we do request "ro"
[18:39] <zyga-solus> hmm
[18:42] <zyga-solus> oh
[18:42] <zyga-solus> silly
[18:43] <zyga-solus> jdstrand: around?
[18:44] <zyga-solus> jdstrand: can you please review https://github.com/snapcore/snapd/pull/4136
[18:44] <mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
[18:44] <zyga-solus> mvo: ^
[18:44] <mup> PR snapd#4136 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
[18:44] <zyga-solus> mvo: I'll write a spread test
[18:44] <zyga-solus> there's something weird still
[18:44] <zyga-solus> the denials says flags="rw, bind"
[18:44] <zyga-solus> but we definitely do "ro"
[18:44] <zyga-solus> so either a bug in apparmor logging or in snapd
[18:44] <zyga-solus> spread will show
[18:45] <mvo> zyga-solus: this is just a warning, right?
[18:45] <mvo> zyga-solus: fwiw, the refresh-undo test is also failing and it is also using journalctl output so I strongly suspect this is related
[18:46] <zyga-solus> mvo: this is a warning but the bug is real
[18:46] <zyga-solus> mvo: warning as in "I tried it and it failed"
[18:46] <mvo> zyga-solus: ok
[18:46] <zyga-solus> mvo: if we could have 4113 it would be easier to test
[18:46] <zyga-solus> I'll cherry pick that in and adjust the test to cover this case
[18:55] <zyga-solus> mvo: I pushed a spread test, let's see if it passes now
[18:55] <zyga-solus> mvo: I'll get back to 14.04
[18:55] <zyga-solus> mvo: if you want a low-risk .2 cherry-pick get the 1st commit from 4136
[18:55] <zyga-solus> mvo: but only if the spread test passes please
[19:02] <mvo> zyga-solus: ok, please add a PR based on 2.29 for this
[19:02] <mvo> zyga-solus: for this commit
[19:04] <zyga-solus> mvo: sure
[19:05] <zyga-solus> done
[19:05] <zyga-solus> IFF the other one passes please merge it
[19:06] <mup> PR snapd#4137 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>
[19:07] <zyga-solus> tagged and renamed
[19:45] <mvo> zyga-solus: thank you
[19:45] <zyga-ubuntu> mvo: I'll doze off until tests show something
[19:45] <zyga-ubuntu> mvo: from what I can see socket activation is not passing the right stuff when things fail
[19:46] <zyga-ubuntu> mvo: down to the environment, there's nothing there
[19:46] <zyga-ubuntu> mvo: I'll keep shrinking my debug changes to see if I broke it
[19:46] <zyga-ubuntu> but now, mental break
[19:49] <mup> PR snapd#4126 closed: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4126>
[19:53] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4136 has +1 from jdstrand (thank you!)
[19:53] <mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
[19:53] <jdstrand> np
[19:53] <zyga-ubuntu> mvo: the grammar aside (I'll fix that tomorrow) I think it's worth merging
[19:54]  * zyga-ubuntu restarted 14.04 test with no -reuse, to see what happens on a clean system
[19:57] <zyga-ubuntu> jdstrand: hey
[19:58] <zyga-ubuntu> jdstrand: not sure if you have time before you go
[19:58] <zyga-ubuntu> https://github.com/zyga/snapd/blob/feature/transparent-tmpfs/cmd/snap-update-ns/utils.go#L132
[19:58] <zyga-ubuntu> if you can just eyeball that quickly
[19:59] <zyga-ubuntu> and tell me if this is sane
[20:00] <zyga-ubuntu> (just one function)
[20:19] <zyga-ubuntu> mvo: thank you for merging master back into that fix RP
[20:19] <zyga-ubuntu> *PR
[20:22] <mvo> zyga-ubuntu: yeah, keen to get results
[20:22] <zyga-ubuntu> uh
[20:22] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4123/commits
[20:22] <mup> PR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
[20:22] <zyga-ubuntu> WTF?
[20:22] <zyga-ubuntu> this is weird
[20:23] <zyga-ubuntu> I'm 100% sure this was a rebased branch
[20:23] <zyga-ubuntu> with no other stuff in it
[20:23] <zyga-ubuntu> github playing tricks?
[20:24] <zyga-ubuntu> mvo: I removed 2.29 milestone from https://github.com/snapcore/snapd/pull/4136
[20:24] <mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
[20:24] <zyga-ubuntu> mvo: this one is for 2.29 https://github.com/snapcore/snapd/pull/4137
[20:24] <mup> PR #4137: cmd/snap-update-ns: fix mount rules for font sharing (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>
[20:29] <zyga-ubuntu> mvo: I force pushed on https://github.com/snapcore/snapd/pull/4123
[20:29] <mup> PR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
[20:41] <mvo> zyga-ubuntu: ok, thanks. but it looks not good, tests are not running
[20:44] <zyga-ubuntu> mvo: where?
[20:46] <zyga-ubuntu> 4123?
[20:46]  * zyga-ubuntu looks
[20:46] <mvo> zyga-ubuntu: nowhere, almost none of the 2.29 PRs has started :/
[20:47] <zyga-ubuntu> two failures on 4123, not sure if related to what we saw
[20:47] <zyga-ubuntu> yeah, maybe we should call it a night and just carry on tomorrow
[20:49] <mvo> yeah, it feels like it unfortunately
[20:53] <sergiusens> mvo are you doing adt?
[20:54] <sergiusens> there is starvation going on right now http://autopkgtest.ubuntu.com/running
[20:54] <mup> PR snapcraft#1654 opened: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>
[20:56] <mvo> sergiusens: travis
[20:57] <mvo> sergiusens: heh, bionic is doing it!
[20:58] <kyrofa> sergiusens, yeah, snap builders are starving too
[21:01] <mvo> zyga-ubuntu: I'm slightly sad but its no good, travis is too slow to wait for it, I will continue with this first thing in the morning
[21:01]  * mvo waves
[21:01] <zyga-ubuntu> mvo: o/
[21:01] <zyga-ubuntu> rest well
[21:02] <zyga-ubuntu> 2017-11-02 22:01:49 Cannot allocate linode:ubuntu-14.04-64: no powered off servers in Linode account exceed halt-timeout
[21:02] <zyga-ubuntu> well
[21:02] <zyga-ubuntu> linode tries to tell me to EOD
[21:02] <mvo> haha
[21:02] <zyga-ubuntu> more tomorrow
[21:02] <mvo> yeah
[21:12] <mup> PR snapcraft#1578 closed: project_loader: quote more environment variable values <bug> <Created by malept> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1578>
[21:14] <kyrofa> sergiusens, wait... we've been waiting all day and our test hasn't even started yet. Time to run the whole thing locally?
[21:15] <sergiusens> kyrofa have you seen the size of the queue?
[21:15] <kyrofa> Just now
[21:15] <kyrofa> Insane
[21:16] <kyrofa> Although not for xenial:amd64, and I don't see snapcraft in it
[21:16] <kyrofa> Which is interesting. Maybe I don't now how to use it
[21:17] <kyrofa> All I see there is systemd
[21:20] <zyga-solus> sergiusens: what is the size of the queue?
[21:20] <kyrofa> zyga-solus, autopkgtest.ubuntu.com/running
[21:21] <zyga-solus> oh
[21:21] <zyga-solus> 1K2
[21:22] <zyga-solus> what is huge vs ubuntu?
[21:22] <zyga-solus> bionic has 4K tests, man
[21:23]  * zyga-solus gets back to family, ttyl
[21:28] <jdstrand> zyga-solus: I didn't review it closely. the idea of putting something to the side so you can later get them seems ok in general. I can say that anything that is in the original is mounted twice (ie, in the original dir and then again on top)
[21:28] <jdstrand> and you won't be able to clean that up since they are underneath (assuming I didn't mis something)
[22:16] <zyga-solus> jdstrand: aha, interesting
[22:18] <zyga-solus> jdstrand: I'll think about the possible consequences
[22:18] <zyga-solus> tomorrow, if we have tests back, not sure about that seeing the queue size, I will make the PR proposable
[22:37] <sergiusens> zyga-solus it is too big to have it cleared tomorrow, I don't know if there is fair queuing in play or not, but the archive adt is humongous
[22:37] <sergiusens> kyrofa snapcraft is under the upstream tests queue
[22:37] <sergiusens> search for snapcraft-daily
[22:38] <kyrofa> Ah