[00:59] sergiusens, elopio snapcraft#1638 looks good (I reviewed it previously as well), but I notice no adt has run. It's kind of a big re-org, think it's a good idea? [00:59] PR snapcraft#1638: tests: reorganize unit and integration suites to make them easier to split for travis [01:01] kyrofa: let me update the other one so they run on the nightly [01:02] elopio, so don't land this yet? [01:03] kyrofa: ah, I thought it was landed already. Well, I guess we are in no hurry because it's already EOD. Let me trigger a few, and we land tomorrow morning. [01:04] Yeah that seems reasonable. And gives me an opportunity to test the new subscriptions [01:04] where's the bot? [01:11] snappy-m-o autopkgtest 1638 xenial:armhf xenial:amd64 [01:11] elopio: I've just triggered your test. [01:13] snappy-m-o github subscribe 1638 [01:13] elopio: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis). [01:13] PR snapcraft#1638: tests: reorganize unit and integration suites to make them easier to split for travis [01:13] I'm now sure if the subscribe thing is working. [01:14] snappy-m-o, github subscribe 1638 [01:14] kyrofa: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis). [01:14] elopio, yeah me neither, but I wasn't before, either [01:14] Now we know that is MUST ping us either way [01:41] snappy-m-o, github subscribe 1638 [01:41] sergiusens: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis). [01:41] PR snapcraft#1638: tests: reorganize unit and integration suites to make them easier to split for travis [01:41] elopio kyrofa by default I think the bot should just go ahead and ping (all of us or at least the author) [01:42] sergiusens, it's not smart enough to tie github users to IRC nicks [01:42] I guess it would work for us though, just use the same [01:43] sergiusens, we recently updated it to ping us on failure OR success though [01:43] kyrofa we can make a manual "team" map. [01:43] Yeah that would be easy as well [06:02] good morning [06:27] mvo: morning [06:27] hey mborzecki [06:28] mborzecki: how are you? [06:28] good, thank you [06:28] sorry to bugging you early morning but would you mind taking a look at https://github.com/snapcore/snapd/pull/4235 ? [06:28] PR #4235: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidRe… [06:28] mborzecki: sure [06:29] this is the last thing that's currently blocking unit tests on arch [06:29] mborzecki: aha, ok. sure, I have a look. I'm still slightly puzzled why its needed but I will poke at it a bit (and may come back with questions) [06:29] ok [06:30] pedronis: thanks a lot for 4222! [06:49] mborzecki: I just checked the test, the issue is that the test is using /snap unconditionally when it needs to use dirs.SnapMountDir (silly test). so http://paste.ubuntu.com/25979289/ fixes the test for me without the need to do the mocking (its also more correct). could you please double check and if it also works for you just patch -R the current diff and force push the smaller diff? [06:50] mborzecki: or not force push just keep it as a regular commit [06:50] mborzecki: and when can squash-merge it [06:50] thanks, i'll check it locally and let you know [06:51] thanks [07:07] mvo: the snippet you posted works locally ;) i'll push changes shortly [07:07] mborzecki: yay, thank you [07:15] mvo: revert & patch are pushed now, thanks for the hint on fixing this, no need to go through the silly mock/restore trampoline :) [07:17] mborzecki: thanks! indeed but the real silliness was in the test to hardcode the /snap prefix [07:40] o/ === mardy_ is now known as mardy [08:46] mvo: hi, was this fixed: https://forum.snapcraft.io/t/spread-cron-is-not-running-snapd-vendor-sync/2739 ? [08:48] pedronis: yes, this is working again. [08:49] pedronis: cachio fixed it some days ago and it seems to be ok, I just checked the build history [08:50] mborzecki: btw, do you know the status of the lxd issue? I guess zyga worked late(?) [08:51] mvo: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/62 we're waiting for a patch from zyga [08:51] other than that g+s [08:51] mborzecki: thank you [08:52] what's the plan for .4 release? [08:54] mborzecki: we do it as soon as we have a patch, ideally today [08:57] mvo: are you going to do a separate PR for checking pending refreshes when refreshes are managed? [08:58] mvo: using #4232 basically [08:58] PR #4232: store: add support for flags in ListRefresh() [08:58] pedronis: either way is fine with me, I can separate it out or put it into the main one, whatever is easier to review for you [08:59] mvo: it's going to be a separate cycle, right? separate PR would seem better in that case [09:00] pedronis: I hope we can get it in for 2.30 [09:00] ? [09:00] pedronis: but separate is fine with me, probably easier to review [09:01] I don't think we can merge the rest without that, afaiu, so it needs to be in 2.30 [09:01] pedronis: yes, then we are in agreement. I misunderstood when you said separate cycle [09:01] I mean separate cycle [09:01] in the sense of the scheduling inside snapd [09:01] pedronis: yes, I think so [09:02] pedronis: that seems to make most sense [09:02] ok [09:02] I think we are in agreement [09:03] pedronis: cool, its my next task, I hope to get something ready by EOD [09:03] pedronis: firefox 57 happend and all my extension (not all, but almost) are dead so I had a bit of unplanned fixtime on this this morning :( [09:03] pedronis: anyway, I get back to schedule (and review feedback fixing and code reivews) [09:04] it's ok, anyway it's still a bit until 2.30 beta? or I'm reading the roadmap wrong? [09:04] s/I'm/am I/ [09:04] pedronis: we still have a bit of time yes [09:05] pedronis: its adjusted for .4 :/ [09:05] mvo: is just me of mborzecki stuff seems a bit unlikey for 2.30 [09:05] pedronis: also autopkgtests on i386 are failing access the board for unknown reasons [09:05] pedronis: refresh timers? [09:05] pedronis: its unlikely :) but reflecting what is being worked on, I think its ok if it moves to 2.31 [09:05] time servers [09:05] services [09:06] mvo: ok, was just confused [09:06] pedronis: no worries :) [09:06] time servers... you made my hear skip a beat :) [09:06] mborzecki: it's was a comment on you or anything, just a bit confused because it will take a while to code and get through review, especially given we would like to clean up the current stuff too [09:07] no worries :) [09:10] mvo: I want to produce a couple of small PRs about things I mentioned yesterday at standup then I will look at your main PR again [09:12] pedronis: sounds good [09:13] PR snapd#4239 opened: tests: more debug info for classic-ubuntu-core-transition [09:51] PR snapd#4240 opened: spread.yaml: increase workers for opensuse to 3 [09:56] PR snapcraft#1638 closed: tests: reorganize unit and integration suites to make them easier to split for travis === __chip__ is now known as Chipaca [10:14] o/ [10:14] sorry for being so late, I need to balance my sleep/wake cycle :/ [10:14] zyga-ubuntu: hey [10:17] zyga-ubuntu: hi. I pushed through some changes to my user-mounts PR (rebasing on master and converting it to use snap-update-ns). It probably still isn't quite right, but it seems to handle the simple cases I tried. [10:17] hey zyga-ubuntu ! good morning [10:17] jamesh: hey! thank you for doing that, I saw the notification and I'll have a look today [10:18] jamesh: what are your next plans? [10:18] mvo: hey, sorry :| [10:18] mvo: but but, were on one page of PRs :) [10:18] zyga-ubuntu: I'd like to try and get portals working [10:18] jamesh: what bits are missing? [10:19] so updating those branches from months back, probably folding it into the desktop interface [10:19] zyga-ubuntu: :) [10:20] zyga-ubuntu: we just need to merge one, e.g. the opensuse one and we are back on a single page [10:20] zyga-ubuntu: the user-mounts thing is the main missing infrastructure. We might run into some issues with how we change $XDG_RUNTIME_DIR though [10:21] parts of document portal expect certain paths to be the same inside and outside the mount namespace. [10:21] jamesh: please update the forum thread with your plans; I'm slowly getting layout code in place and I can help [10:22] today I'm a bit dizzy for complex things but I should have fresh head on Monday [10:24] mvo: not sure if you were following the LXD discussion last night, I'll do what we agreed with jdstrand; make snap-confine setgid, drop the gid part early on and only restore it for that single freeze operation [10:24] mvo: I should have that ready in ~1.5 hours [10:24] mvo: hopefully by EOD we can push to beta [10:25] zyga-ubuntu: \o/ [10:25] zyga-ubuntu: I'm trying to understand a pkgtest failure on i386 in parallel, worst case is that we need to disable one test in autopkgtest (ubuntu-core-transition is failing *only* on i386) [10:26] zyga-ubuntu: so +1 for a .4 [10:26] only on i386, curious [10:26] mvo: thank you, good luck [10:29] mvo, hey, what's up with https://github.com/snapcore/snapd/pull/4063 ? [10:29] PR #4063: tests: add new kernel refresh/revert test for spread-cron [10:31] zyga-ubuntu: took a deeper look into https://forum.snapcraft.io/t/installing-vscode-snap-on-arch-linux/2871/5 imo there's something wrong with what's shipped in the snap, my best guess those libs are pieces of fedora userspace [10:32] mborzecki: vscode is a classic snap [10:32] mborzecki: no namespace magic, problems [10:32] zyga-ubuntu: hi, what's the status of #4109 [10:32] PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields [10:32] pedronis: it's not critical, just something I found while hacking [10:33] pedronis: there's a cleanup that I could move out of the function [10:33] pedronis: and a fix itself [10:33] pedronis: other than that not sure [10:33] pstolowski: meh, no time yet for this [10:33] mvo, ah, ok, no pressure, just checking [11:24] zyga-ubuntu, hey [11:26] zyga-ubuntu, I have defined for a test this snap https://github.com/sergiocazzolato/snapd/blob/tests-interface-network-status/tests/lib/snaps/test-snapd-network-status-provider/snapcraft.yaml [11:27] zyga-ubuntu, but I am getting some denials when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider" === JoshStrobl|zzz is now known as JoshStrobl [11:28] cachio: hmm [11:28] cachio: what kind of denials [11:30] zyga-ubuntu, https://paste.ubuntu.com/25980351/ [11:30] aha [11:30] is this blocking the test? [11:30] it seems that snap wants to look at the mount table [11:30] that should be handled by mount-observe [11:30] not sure why it needs it, just saying [11:31] zyga-ubuntu, I already tried that [11:31] owner @{PROC}/@{pid}/mounts r, [11:31] mount-observe grants this [11:31] what did you try? [11:32] yes, let me try again [11:32] Chipaca, hello! is this clear what we want wrt to environ in commands here https://forum.snapcraft.io/t/papercuts-mouth-sized-bugs/228 ? [11:35] zyga-ubuntu, I plug mout-observe and I see this https://paste.ubuntu.com/25980371/ [11:35] cachio: is this test looking at its own mount table? [11:36] the rule says 'owner' [11:36] no [11:37] it is trying just to own the com.ubuntu.connectivity1.NetworkingStatus dbus interface [11:37] cachio: I'm sorry but I don't know why it would also try to access the mount table [11:44] pstolowski: what do you mean? [11:45] zyga-ubuntu, I have to go to the doctor [11:45] cachio: ok [11:45] zyga-ubuntu, I'll be 5-10 minutes late for the standup [11:46] pstolowski: the one about them being too restrictive? [11:47] Chipaca, no; do we want to interpolate "command: FOO=$SNAP/bar actual_command" or "command: env PATH=$SNAP/usr/local/bin:$PATH desktop-launch" ? [11:47] pstolowski: me, i'd explore something like: first, support having env vars as arguments to commands (even the first argument). Second, support arbitrary arguments but with no quoting nor escaping (so just disallow '"\) [11:48] pstolowski: and third, make commands be either a string, or a list; if a list, pass to exec as is [11:48] the reason for not getting into quoting and such is because it's a nightmare [11:49] and the list approach makes it not needed [11:49] (the list would take quotes and backslashes and pass them through) [11:49] um [11:49] pstolowski: answering your question there, no that's not the idea at all [11:49] pstolowski: commands already have an environment [11:50] that is, apps have an environment [11:50] pstolowski: this is about support “command: foo $BAR $BAZ” [11:51] PR snapcraft#1742 opened: lxd: always remove tmp_dir after execution [11:51] it's possible that work is already done though; not sure [11:51] Chipaca, ok, that should work if I read the code correctly [11:51] that post is old [11:51] Chipaca, yeah, and it originated from https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/6 [11:52] Chipaca, I'm trying to understand if what's done or not, there were a couple of aspects discussed there, I'm unclear what do we want at the end [11:54] pstolowski: I think there is still work to be done here, but i've not looked in a while as i say [11:55] * kalikiana time for a break [11:56] popey: is the mailspring snap doing something wrong, or do none of the desktop integration bits work for anybody? [11:56] i mean system tray and notifications, in particular [11:57] (my indicators don't even work for regular apps for whatever reason but that's another discussion)) [11:58] Chipaca, I see, thanks [12:16] Chipaca indicators fail completely for me, OSD works fine for mailspring [12:24] Chipaca: what version of Ubuntu? [12:25] popey: 16.04 [12:25] zyga-ubuntu / mvo your favorite topic! https://forum.snapcraft.io/t/vdpau-support-in-snaps-on-nvidia/2876 [12:25] :) [12:25] popey: i thin right now lxd is more favourite [12:25] also my keyboard is dying :-( [12:29] ikey|zzz: hey, regarding your forum post (https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/4), both zyga and I responded to you (so not talking into the void). we need an architect to participate in the discussion, hence the open question to niemeyer in that topic [12:29] * ogra_ hands Chipaca https://www.massdrop.com/buy/xmit-hall-effect-mechanical-keyboard [12:31] * popey bans ogra_ for posting massdrop links, which will cause the collapse of the economy as we all buy them [12:31] hahaha [12:33] also, that import duty [12:33] ogra_: i've got a lot of nice keyboards! the one that's dying is the one for my tablet (that i'm currently on) [12:34] ah, thats bad indeed [12:34] well, the above is indistructable ... (at least the switches) [12:34] pedronis: hey, I think that the base declaration is correct and the spread test failure, while real, is the right behavior [12:35] jdstrand: my point is mostly that people that were testing snaps doing this will need to change their tests [12:35] pedronis: "Then the plug is connected by default" [12:35] the test should be adjusted [12:36] because they don't get autoconnection for their --dangerous install anymore [12:36] I understand that [12:36] just making clear this will be a "regression" for them [12:36] that is the correct behavior. there are 5 snaps that use this [12:37] I know [12:37] so I can communicate that to them and in documentation [12:37] ok [12:37] I fixed the integration test already [12:37] but it does mean the spread test needs to be adjusted [12:37] I did that [12:37] I think we are getting other spurious failures now [12:37] oh I missed that [12:38] * jdstrand looks [12:38] it's just taking too long [12:38] there's a PR by mvo that could help with that [12:48] mvo: we still got prepare failures in you add opensuse workers PR :/ [12:48] *your [12:49] pedronis, have we sync'd the Fedora 27 VM base image to the current Fedora 27 GA? [12:49] and resync'd Rawhide to a recent snapshot of it? [12:50] no clue [12:50] I'm not on top of that [12:50] PR snapd#4241 opened: store: bit less aggressive retry strategy [12:50] who is? [12:50] mvo, zyga-ubuntu, cachio [12:51] maybe [12:51] Chipaca: could you look at #4241 (it's tiny) [12:51] PR #4241: store: bit less aggressive retry strategy [12:51] Son_Goku: cachio is working on updating the debian images, we alredy said that other images must follow [12:51] sure [12:52] pedronis: +1 [12:52] thx [13:20] PR snapd#4242 opened: panic early if snapd is pointed to staging but staging keys are not compiled-in [13:26] mvo: I'll push the branch in a moment, just want to see it work one more time [13:26] mvo: do we need to disable the opensuse tests until we understand more? [13:26] pedronis: +1, also for fedora if that is broken and would impede release [13:26] Son_Goku, zyga-ubuntu the new fedora images will be ready early next week [13:27] cool [13:37] mvo, zyga-ubuntu the debian images are not updated yet [13:45] Hi [13:45] No matching distribution found for python-distutils-extra (from snapcraft) [13:45] I am getting this when doing pip install snap craft on ubuntu [13:45] How do I work around this? === petevg is now known as petevg_afk [13:57] mvo: can you look at https://github.com/snapcore/snapd/pull/4230/commits/7722c0404b97fa0ac119acb495caa62c3f5ab321 please [13:57] PR #4230: tests: add test to run snap inside lxd as a user [14:01] sborovkov `pip install -r https://raw.githubusercontent.com/snapcore/snapcraft/master/requirements.txt` python-apt and -distutils-extra are not on pypi [14:02] sergiusens, thanks [14:02] zyga-ubuntu: sure, looking [14:03] jdstrand, hey [14:03] zyga-ubuntu: looks good, thank you [14:05] jdstrand, I am creating s snap with this https://paste.ubuntu.com/25980439/ [14:05] jdstrand, this is the python code: https://paste.ubuntu.com/25981110/ [14:05] jdstrand, and when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider" [14:05] I see this denial [14:05] jdstrand, https://paste.ubuntu.com/25980371/ [14:06] jdstrand, any idea what could be the reason? [14:08] jdstrand: can you look as well please, that's the thing you suggested last night [14:08] cachio: does the snap fail to work with that? most often that is a noisy denial and not a problem. The snap could plugs the mount-observe interface to get rid of it [14:09] cachio: python is one of those environments that does that (noisy denial but works otherwise) [14:10] jdstrand, ok [14:10] I'll check that [14:11] zyga-ubuntu: sure [14:14] jdstrand, https://paste.ubuntu.com/25981162/ [14:14] jdstrand, it is not from a snap [14:14] i'm calling it a day, have a nice weekend everyone [14:38] cachio: thanks for checking 4240 - is there something we can do to help the opensuse tests to run faster again? [14:39] cachio: i.e. caching the downloads and storing that in our test-image or something? [14:39] mvo, I think the best we can do is to update regularly the images [14:39] so all the provisionning part is reduced almost to 0 [14:40] mvo, I'll work on that next week [14:40] I'll need a new key for this [14:42] cachio: ok, thanks [14:42] cachio: should we disable opensuse until then? [14:43] elopio kyrofa updating the tests from other branches takes a bit [14:44] mvo, I'll take a look to opensuse [14:44] cachio: thank you [14:44] mvo, not sure why it is failing noe [14:44] now [14:44] it is a timeout in the prepare trying to install dependencies [14:45] mvo, it shouldn't happen [14:52] PR snapd#4243 opened: tests: disable classic-ubuntu-core-transition on i386 temporarly [14:53] mvo: tests/main is green, let's release this [14:53] can everyone available please review 4230 [14:53] zyga-ubuntu: which one is green? [14:53] mvo: (tests/main ran locally) [14:54] zyga-ubuntu: for what PR (sorry, I lack context somehow) [14:54] mvo: 4230 [14:54] zyga-ubuntu: don't we need a +1 from jamie first? [14:54] mvo: right, that's why I asked for reviews :) [14:55] zyga-ubuntu: aha, ok. yeah, +1 for releasing asap [14:55] good morning. [14:55] zyga-ubuntu: but it looks like your PR will fail on opensuse :/ only 3 min left and [14:55] 80 tests to run [14:56] oh drat [14:56] mvo: well, this is master [14:56] zyga-ubuntu: yeah [14:56] mvo: shall we disable suse or shall we bump the number of workers by one? [14:56] mvo: we can do a tailored PR in 2.29 [14:57] zyga-ubuntu: adding a worker was not enough, I'm in favor of disabling [14:57] zyga-ubuntu: but cachio said he is looking into it [14:57] mvo: ok [15:01] mvo, zyga-ubuntu I am reproducing the error here [15:01] we can disable it until the problem is fixed [15:01] do we have any idea why it might be slower? [15:02] no yet, waiting for the timeout yet [15:02] zyga-ubuntu, let's disabe opensuse, then we can enable it again [15:15] zyga-ubuntu, mvo I tested here and it worked [15:15] perhaps is a temporal issue === cachio is now known as cachio_lunch [15:17] cachio_lunch: did oyu test on linode? [15:25] sergiusens, do we want to determine a landing order for these other PRs? [15:25] (so we know which ones to fix first) [15:30] zyga-ubuntu: you have review feedback for 4230 [15:30] looking [15:30] zyga-ubuntu: let me know if you want help :) [15:30] yes, was just going to ping you on that :) [15:30] zyga-ubuntu: but looks straightforward [15:30] thank you jdstrand [15:45] mvo: testing and I'll push in a sec [15:49] PR snapcraft#1743 opened: catkin plugin: support building entire workspace [15:51] mvo: did you disable suse? [15:51] mvo: I'd like to pull master and then push this [15:52] mvo: you can, I think, just git push the backend to manual [15:52] mvo: to save us some time [15:55] mvo: I pushed, please merge/squash [15:56] jdstrand: https://github.com/snapcore/snapd/pull/4230/files [15:56] PR #4230: tests: add test to run snap inside lxd as a user [15:57] * zyga-ubuntu needs to play with those real/effective/saved ids thing more === cachio_lunch is now known as cachio [15:59] zyga-ubuntu, I tested on linode [15:59] zyga-ubuntu, I executed again the change to add a new worker for suse [16:00] let's see if it fails again [16:00] if it fails I'll disable opensuse [16:01] zyga-ubuntu: done. sorry I forgot something in my suggestion (teeny change) [16:01] jdstrand: aha [16:02] jdstrand: pushed :) [16:03] * zyga-ubuntu needs to run === zyga-ubuntu is now known as zyga-afk [16:03] jdstrand, https://paste.ubuntu.com/25981162/ [16:03] jdstrand, it is not from the tests [16:03] * kalikiana dinner time [16:04] mvo: please get this to beta tonight if we can [16:04] mvo: I'll be back in some hours [16:05] zyga-afk: I will push for it [16:11] elopio, one issue with the refactor now that I'm using it: it tells me tests are skipped, but doesn't say it's because they were slow [16:11] Before the refactor it was helpful and said "skipping slow test" or something like that [16:11] zyga-afk: once tests are in I will run the machinery [16:11] zyga-afk: thanks a bunch of fixing this! [16:15] mvo: I did another pass on managed, but didn't see your last commit, now I saw, I think the placement of that code is problematic [16:16] *saw it [16:16] kyrofa oh, if that is happening, I'd agree [16:16] Alright, fixing [16:17] kyrofa also, rebase on top of new master [16:17] kyrofa I did minor piggybacking on that last merge (sorry, but sorry) [16:17] cratliff, catkin-tools has finally landed! [16:18] kyrofa and take extra care on your rebases/merges as things need to manually move on your side for tests to keep on running ;-) [16:18] sergiusens, yeah I'm working through the ament one now [16:18] Basically, if you added any new test files, they need to move, but if you modified ones that were already there, you're mostly there [16:19] PR snapcraft#1593 closed: catkin tools plugin: add catkin tools support [16:21] mvo: we can discuss options on Monday === ikey|zzz is now known as ikey [16:26] mvo: do you need anything more from me today? [16:29] pedronis: thank you, I think I'm fine, I will baby-sit the build and do 2.29.4 [16:31] kyrofa: how weird. Please report a bug, and I'll look at it as soon as I'm over with the call for testing. [16:31] flexiondotorg: popey: can I send a coschedule post linking to the call for testing? https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880 [16:33] PR snapd#4244 opened: disabling opensuse until timeout issue is fixed