[00:05] kyrofa: ugh, that sucks. I'm sorry you had to spend so much time on that. [00:06] elopio, I blame you. You asked for the change that broke the test [00:06] elopio, nahh, it was educational, for sure. I learned a lot about unittest :P [00:07] 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 [00:16] kyrofa: ahh, you know me, always investing in your personal growth :D [00:16] Hahahaha [00:17] elopio, do you get the same error for cleanbuild? [00:17] Indeed, that sounds like a snapd issue [00:18] kyrofa, yes anything that calls lxc. It doesn't happen when running from the venv [00:18] Weird [00:18] Alright, dinner time here [00:55] kyrofa well, lesson is, you should run the full suite locally when things fail remotely ;-) [00:56] elopio mind triggering adt for everything under the sun on the 2.35 branch? [00:56] diddledan: hey dan, are you around? [00:57] kyrofa now that you rebased instead of adding an individual commit you should add an explanation in the PR [00:59] 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] elopio: I've just triggered your test. [00:59] elopio do we support bionic? [01:00] sergiusens: is it ready? do-release-upgrade doesn't let me upgrade from a. [01:01] lxc doesn't have bionic either [01:01] elopio people are already on it [01:01] elopio didn't you see the ubuntu-devel list? Already open for development [01:02] sergiusens: how? latest daily live is from the 18: http://cdimage.ubuntu.com/daily-live/current/ [01:04] elopio changing sources.list to bionic? [01:06] elopio we can already upload, debootstrap is the mechanism https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html [01:15] snappy-m-o autopkgtest 1650 bionic:amd6 [01:15] Computer says nooo. See logs for details: [01:15] Command '['/tmp/tmpmgtertxg/retry_autopkgtest.sh', '1650', 'bionic:amd6']' returned non-zero exit status 1 [01:15] snappy-m-o autopkgtest 1650 xenial:amd64 [01:15] elopio: I've just triggered your test. [01:16] ahh, damn [01:16] snappy-m-o autopkgtest 1650 bionic:amd64 [01:17] elopio: I've just triggered your test. [01:18] apparently, it will run sergiusens [01:19] snappy-m-o autopkgtest 1650 bionic:armhf bionic:arm64 [01:19] elopio: I've just triggered your test. [01:44] PR snapd#4114 opened: interfaces: don't udev tag devmode or classic snaps [01:57] \o/ === petevg is now known as petevg|afk [02:46] elopio look at the runaway output on zesty-amd64 :/ [02:50] sergiusens: that's unfortunate. But well, it's probably time to close that socket properly. [02:51] it's weird that the socket is not opened for this test, but maybe it's just printed late or something. [02:59] if only I could reproduce it... [04:52] PR snapd#4115 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via kernel [05:32] PR snapd#4116 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL [06:16] PR snapcraft#1651 opened: tests: move the rest of ros demos tests to integration [06:27] snappy-m-o autopkgtest 1651 xenial:amd64:integrationtests [06:27] elopio: I've just triggered your test. [06:33] good morning [06:42] good morning mvo [06:43] mvo: we have a series of PRs from jamie for 2.29 [06:43] I'll be with you soon [06:48] zyga-solus: yeah, checking. I just approved 4114 [06:49] zyga-solus: mvo: hi [06:49] jdstrand: 4115 is not a 2.29 regression, its fallout from the changes in 2.28, right? [06:49] hey pedronis [06:50] hello pedronis, how are you doing? [06:50] ok, up early (for me) because we are waiting for people doing some work for the house [06:50] 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] zyga-solus: yeah, 4115 is not a regression (technically) [06:51] technically that is correct [06:51] 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] pedronis: cool, I have a look now. thanks for picking this up! [06:52] mvo: please don't land 4114 just yet [06:53] mvo: I also have a couple more PRs needing review but less urgent than jdstrand stuff obviously [06:54] zyga-solus: sure, I hold it back. whats your concern? [06:54] 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] pedronis: then I can do more reviews [06:55] mvo: I want to see why tests are just for ubuntu, they should not be [06:55] mvo: I'll test locally and push a change if they can work everywhere [06:55] just eating breakfast [06:55] zyga-solus: cool, thanks [06:55] zyga-solus: I also saw test failures in 14.04/reexec in spread but maybe just a fluke [06:56] 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] 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] pedronis: yeah, I can prepare a followup with this fix [07:00] mvo: ok, going to merge it [07:01] thanks! [07:04] done [07:05] PR snapd#4076 closed: many: handle core configuration internally instead of using the core configure hook [07:22] * zyga-solus is back now [07:22] morning everyone [07:23] mborzecki: hello! [07:23] i'm the new guy, starting only today :) [07:23] welcome :) [07:23] mborzecki: we have mvo and pedronis around already [07:24] mvo: pedronis: hi [07:24] mborzecki: pawel and john should join soon too [07:24] (though perhaps john is off today, not sure) [07:24] mborzecki: gustavo I believe is off this week [07:24] mborzecki: sergio will join later today [07:24] mborzecki: welcome! [07:24] hey mborzecki - welcome! [07:25] thanks [07:26] mborzecki: fork and build the tree and look around [07:26] so how does it work from here? already got an email address, launchpad accounts and SSO work [07:27] mborzecki: we're just starting with 2.29 release candidates [07:27] mborzecki: great, you also need a github account as that's where the code is (but I'm sure you have one) [07:27] mborzecki: mvo can add you to the team that owns snapd, I believe [07:27] mborzecki: a good starting point is probably to check if our "HACKING.md" is up-to-date ,) [07:28] ok, cool [07:28] ha, excellent advice :) [07:28] mborzecki: i.e. if you can get started following that guide [07:28] mborzecki: and if its not up-to-date we appreciate PRs about the broken bits :) [07:28] ack [07:29] mborzecki: and if you have any questions or anything we are here for you! [07:29] mborzecki: also tell us which distro your are using [07:29] haha, that's the interesting part, i'm using arch atm [07:29] mborzecki: large chunk of the team is on various releases of ubuntu [07:29] mborzecki: I'm on ... many :) [07:29] mborzecki: thats good, our instructions are probably lacking in this area [07:30] mborzecki: I don't suppose you have arch commit access, do you? [07:30] i'll be sure to check them [07:30] zyga-solus: nope [07:30] mborzecki: the current maintainer has abandoned our package so we're kind of stale there [07:30] iirc it's in community repo, right? [07:30] that's correct [07:31] 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] mborzecki: I think we need to indicate the current maintainer as inactive but that requires a motion filed by a TU [07:32] 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] hm, so i'm guessing you've already started the process, but it isn't going as smooth as expected? [07:33] mborzecki: flexiondotorg was looking at this last time I think, I don't know more [07:35] fair enough, I'll start with trying to build the current master first and we'll take it from there [07:39] which go version do you use atm? i recall zyga-solus or niemeyer mentioning 1.6, is it still the case? [07:39] mborzecki: we use different versions for each system actually, ubuntu 14.04 and 14.06 are on 1.6 [07:39] mborzecki: so that's the lowest common denominator [07:39] mborzecki: on arch and on development versions of ubuntu we use the latest [07:40] mborzecki: we also have almost everything in between, I think [07:42] 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] mvo: about reviews, #4106 and #4111 are the main ones, Chipaca already did a first review [07:43] PR #4106: many: lookup and use the URL from a store assertion if one is set for use [07:43] PR #4111: many: make ignore-validation sticky and send the flag with refresh requests [07:45] 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] 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] mvo: I see, indeed I noticed also the handler for one is in the wrong place [07:56] mvo: I probably need to do something like switch-snap-channel for ignore-validation [07:57] pedronis: will you look at cleaning this up (just noticed the wrong place as well :/ [07:57] pedronis: or shall I create a cleanup PR? [07:58] mvo: is not too urgent, also they really do slightly different things [07:58] so needs a bit of thinking [07:58] I can move the hanlder in a drive-by though [08:00] mvo: they probably also need to be added to the change conflict task list [08:02] pedronis: +1 [08:06] pedronis: silly question - do we have the inverse of --ignore-validation? just looking at 4111 and was wondering how this is reset [08:09] Apologies if this isn't the right place to ask, but can interfaces be shimmed? [08:09] As in, a snap that offers interfaces that simulate an empty 'Home' or a network that never opens a socket. [08:09] 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] pedronis: ta [08:10] mvo: that's the input from Gustavo on the matter [08:11] 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] pedronis: yeah, maybe a comment is enough to explain the subtle details [08:13] I'll just do a small PR to move the handler closer to the other and add them conflict management [08:14] pedronis: sounds good [08:14] pedronis: and I see we test the reset of --ignore-validation, great (should have read all the way before asking :) [08:15] pedronis: 4111 is small enough to consider for 2.29.1, wdyt? how urgently does CE needs it? [08:15] mvo: I think they would be happy if it's 4111, the server change was deployed yesterday [08:15] sorry [08:16] if it's in 2.29 [08:16] but I didn't promise it [08:16] 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] Also, is it posible to change auto-connect defaults for snaps? [08:17] mvo: yea, I'm working on the follows up, but as fix it's ok standalone [08:18] thanks pedronis [08:18] 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] mvo: when do you think we will cut 2.30 ? [08:21] 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] pedronis: mostly on my plate though [08:21] mvo: early next week? [08:21] mvo: I thought that would be only after 2.29 goes to stable [08:22] mvo: ~3 weeks [08:22] 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] aha :) [08:22] I guess 3.31 it is then [08:22] mvo: I also have some stuff that we want in 2.30 because it was delayed already quite a bit [08:22] zyga-solus: check https://forum.snapcraft.io/t/the-snapd-roadmap/1973 [08:22] mvo: time to have the milestone to tag stuff? [08:22] pedronis: +1 [08:23] pedronis: milestone added [08:23] thank you [08:23] PR snapd#4013 closed: repo, daemon: use PlugInfo, SlotInfo [08:24] mvo: marked thing accordingly (especially #4106 that I mentioned before) [08:24] PR #4106: many: lookup and use the URL from a store assertion if one is set for use [08:46] mvo: I'm merging #4111, it's one commit so it should be easy to cherry-pick for 2.29 [08:46] PR #4111: many: make ignore-validation sticky and send the flag with refresh requests [08:48] PR snapd#4111 closed: many: make ignore-validation sticky and send the flag with refresh requests [08:48] pedronis: ta [09:02] mvo: I pushed a patch to 4114 [09:03] mvo: I left some comments and I'm +1, I can also address them in a quick patch if you agree [09:03] PR snapd#4117 opened: many: make ignore-validation sticky and send the flag with refresh requests (2.29) [09:03] mvo: I created the cherry-pick ^ [09:03] pedronis: \o/ thank you [09:04] zyga-solus: checking, thank you! [09:04] PR snapd#4118 opened: overlord/snapstate: cleanups around switch-snap* [09:05] zyga-solus: looks good, thanks [09:06] mvo: and cleanups ^ [09:07] ta [09:32] 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] mborzecki: nice, looks like some low hanging fruit to tweak [09:32] i can fix those, open a PR, and we'll get through the github accounts and stuff :) [09:33] yep, sounds like a good plan [09:33] btw. noticed that you're not using gometalinter but rather just the individual tools [09:34] * zyga-solus never heard about gometalinter [09:34] https://github.com/alecthomas/gometalinter sort of a frontend/driver to all the linting/checking tools for go [09:38] mvo: :( seems master is unhappy [09:43] do i need to signoff the commits? [09:44] mborzecki: not really [09:44] mborzecki: I love to but it's just me [09:45] ok, so another question, any email address or @canonical.com when signing off? [09:45] again, no rule, I use a mix, depending on how I feel about the work [09:45] fair enough [09:46] pedronis: I noticed this earlier too, I have a look in a bit [09:48] mvo: last one is snapd-reexec failure on 14.04 but I don't understand the issue [09:48] PR snapd#4119 opened: tests/test-snapd-service: fix shellcheck issues [09:49] fyi my github handle is 'bboozzoo' :) [09:49] mvo: seems we are installing the same core but don't expect that and don't get a restart [09:49] mborzecki: reviewed [09:50] mborzecki: I think you can remove the "have you signed the license agreement" stuff from your commit [09:50] + prev_core=3377 [09:50] + snap install --dangerous /var/lib/snapd/snaps/core_3377.snap [09:50] core 16-2.29+git446.aaee286 installed [09:50] This leaves core tracking edge. [09:50] + MATCH 'Requested daemon restart' [09:51] zyga-solus: i think it's only added by github PR templates, it's not part of the commit message [09:51] it's added but when you open the PR you can still remove it [09:51] you can hit the edit button and remove it still [09:52] done [09:53] btw. should I sign canonical CLA? [09:56] mborzecki: I don't think you need now [10:03] * Chipaca looks around [10:03] hey ho Chipaca [10:03] zyga-solus: hiya! how's things? [10:03] Chipaca: our new colleague, mborzecki is around [10:03] Chipaca: hi there [10:03] i was trying to spot them but with 283 people it was hard [10:03] Chipaca: damp [10:03] mborzecki: o/! [10:04] Chipaca: but it might rain too :) [10:04] zyga-solus: it's officially "are the clothes damp, or just wet" weather here [10:04] hehe :) [10:05] I'm in a mood to visit UK and see [10:05] zyga-solus: is it not raining in warsaw yet? [10:05] mborzecki: I think it stopped now [10:06] maybe it's buffering :/, damn weather [10:06] mborzecki: "loading more rain" ;) I like that [10:08] ok, so what should look at now? go through PRs maybe? [10:08] mborzecki: look around, we have plenty of PRs to review [10:08] mborzecki: I think looking at that and asking questions is useful [10:09] mborzecki: you can also check our roadmap on the forum (oh, and do sign up if you haven't already) [10:10] Chipaca: do you think https://forum.snapcraft.io/t/disk-usage-report/2372 might be a nice first task for mborzecki ? [10:11] mvo: that'll touch osutils, daemon, client, and cmd/snap at a minimum [10:11] mvo: but nothing particularly complex [10:11] mvo: so... yes, probably? unless we want them digging into the overlord straight away [10:12] 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] I think today should be a "figure out the code layout day" [10:12] mthaddon: hey! [10:12] o/ [10:12] mthaddon: hmm hmm [10:12] mthaddon: can you tell me if the container is privileged? [10:12] mthaddon: as in, not confined at all? [10:13] mthaddon: and can you tell me what is on the outside of the LXC container? [10:13] zyga-solus: I created the LXC with -c security.privileged=true. It's running on a xenial machine [10:14] 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] mthaddon: which version of snapd do you have on the outside? [10:15] 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] 2.28.5 on the outside [10:15] Chipaca: thinking about suitable tasks currently not too hard but also reasonable interessting. do you have ideas? [10:15] mthaddon: can you see if you had any apparmor denials? [10:16] mborzecki: cool, another interessting task might be to update the arch packaging (cc zyga-solus ) [10:16] oh, that's actually a very good idea [10:16] mborzecki: or fixing the current test failure in master :) [10:17] mborzecki: all interessting stuff :) [10:18] PR snapd#4120 opened: repo: use PlugInfo and SlotInfo for permanent plugs/slots [10:18] 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] mthaddon: I recall a case we investigated a good while back [10:19] 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] mthaddon: and we ended up saying that that is not supported much [10:20] is 2.28.5 very out of date? [10:20] no, it's not [10:20] I'm just trying to grok what may be going on [10:21] gotcha [10:27] PR snapd#4121 opened: overlord/snapstate: toggle ignore-validation as needed as we do for channel [10:28] mvo: the 14.04 refresh-undo thing is a regression after the release recently? [10:29] PR snapd#4122 opened: configstate: add support for snapstate.IgnoreHookError [10:30] zyga-solus: I'm not sure, I have not investigated yet [10:30] mvo: I got the 14.04 snapd-reexec also on a PR [10:30] it seems a real issue [10:30] or something off with versions of things [10:31] 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] pedronis: yeah, I check that out [10:31] zyga-solus: should I file an issue for this somewhere to make it easier to follow up on? [10:32] mvo: /me points at debian packaging too :) [10:32] mthaddon: I think we could use a detailed bug and I should have a look at that [10:32] mvo: mostly done, it just needs versions of dependencies checking [10:32] mvo: I'll look at it in a bit [10:32] hey mwhudson [10:32] zyga-solus: sure, LP or GH? [10:32] mthaddon: LP please [10:32] ack [10:33] mwhudson: oh, the debian PR is updated, nice! [10:33] pedronis: no rush [10:33] mvo: uh not the PR against snapd, no :/ [10:33] mvo: but the repo on alioth is [10:34] zyga-solus: hello [10:34] zyga-solus: i am going to bed :) [10:34] mwhudson: aha, ok [10:34] mwhudson: we should merge your packaging still :) [10:34] mwhudson: but another day, I guess its late for you [11:00] pstolowski: hey [11:01] zyga-solus, hi! [11:01] pstolowski: which PRs should I get started with to help you out? [11:01] zyga-solus, the two i've currently can be reviewed independently, and both are prerequisites for the upcoming ones, so pick any ;) [11:02] ok, I'm going to go through 4120 then [11:02] zyga-solus, thanks in advance! [11:14] pstolowski: I'll see to look at your branches as well this afternoon or tomorrow [11:15] thanks pedronis! [11:39] man, my eyes fail me today [11:50] mvo: there's going to be another tiny one for 2.29 [11:50] pstolowski you found an interesting bug [11:51] popey, are you around ? [11:51] pstolowski: 4120 done [12:01] 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] *reach [12:02] seemingly that "breaks the rules of askubuntu, so I'm going to delete the most ..." [12:03] quick break [12:03] zyga-solus, thanks! ah, that, yeah, i rolled my eyes when I saw this, forgot to address it separately [12:03] pstolowski: I'll handle the 2.29 change [12:03] no worries [12:03] I'm adding a new test with some reflection [12:04] cool [12:07] zyga-solus: oh, tell me more? but after lunch :) === JoshStrobl is now known as JoshStrobl|AFK [12:17] PR snapcraft#1652 opened: tests: fork skip into snaps_tests [12:19] snappy-m-o autopkgtest 1652 xenial:amd64 [12:19] sergiusens: I've just triggered your test. [12:27] mvo: re 4115 and 4116> not a direct regression, no, but the bug is exacerbated by 2.28 [12:27] pstolowski: I have a test that catches the error now [12:27] jdstrand: hey :) [12:27] jdstrand: interesting iface bug pawel found today :) [12:28] zyga-solus: hey [12:28] zyga-solus: I haven't seen it yet (just woke up) [12:29] jdstrand: I'll send a PR up in 10 minutes [12:32] PR snapcraft#1651 closed: tests: move the rest of ros demos tests to integration [12:37] oh boy oh boy [12:41] oh man oh man [12:41] :-) [12:55] mvo: two PRs up [12:55] PR snapd#4123 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) [12:55] PR snapd#4124 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot [12:56] pstolowski: please merge this into your PR and ensure it's all green [12:56] pstolowski: thank you for finding it [12:56] jdstrand: ^ [12:57] pstolowski: you will need trivial changes to type signature checks in the PR that changes them [13:01] ogra_: there is a meta chat thing on askubuntu. I'd recommend dropping in there [13:02] https://chat.stackexchange.com/rooms/201/ask-ubuntu-general-room [13:02] You're being discussed [13:04]