[00:09] NickZ, yeah that's a question for jdstrand [00:10] PR snapcraft#2263 opened: project: catch parent YAML exceptions [00:18] jdstrand: any progress on that feature since the last update? [04:22] PR snapd#5819 opened: tests: fix for nested test suite [04:40] PR snapcraft#2264 opened: Fix issue where cross compile target is ignored === cpaelzer_ is now known as cpaelzer [05:06] morning [06:18] Good morning [06:18] Is github working now? [06:19] zyga: good morning [06:19] zyga: it looks like it, I see a lot of green today [06:19] :-) [06:19] Great [06:20] PR snapd#5816 closed: overlord/assertstate: propagate TaskSnapSetup error [06:23] zyga: mvo: hey [06:24] mborzecki: good morning [06:29] PR snapd#5808 closed: snapd-env-generator: fix when PATH is empty or unset [06:35] pedronis: 5765 may be something you like, it splits bits of the store tests into their own file [06:38] #5777 triggers one annoying bug in wrappers and map iteration order [06:38] PR #5777: wrappers/services.go: don't start disabled services [06:49] PR snapd#5820 opened: wrappers: fix snap services order in tests [06:49] super simple ^^ [07:05] mborzecki: I'm curious about 5820 - I ran this test with -count 1000 and got no failure. is that a go 1.11 thing? [07:06] mvo: i was doing some changes on top of 5777 and it failed like this https://paste.ubuntu.com/p/6T3JVzK7fj/ [07:06] PR snapd#5803 closed: ifacestate: fix hang when retrying content providers === pstolowski|afk is now known as pstolowski [07:06] mornings [07:07] mvo: it's a bug nonetheless. info.Apps is a map, so the order of iteration is random-ish [07:07] pstolowski: hey [07:07] PR snapd#5804 closed: ifacestate: fix hang when retrying content providers (2.35) [07:07] mborzecki: yes, I'm just surprised we don't see it more often [07:08] mvo: wouldn't be surprised if changing some strings or order of operations in the test would be enough to trigger it [07:16] zyga: whats the status of 1791814 [07:16] zyga: do we need a fix for the interfaces issue in 2.35.2? [07:29] mvo: hi, I see, I need to finish something I was trying to finish yesterday before doing new reviews [07:29] pedronis: no problem, this was just a fyi [07:40] morning all [07:41] was up stupid late last night, so I might zonk off at some point (but y'all woke up to a lot more green PRs, so that's ok i guess) [07:47] mvo: re [07:47] mvo: sorry for the lag [07:47] mvo: there's a small PR but it's not critical [07:48] zyga: ok, I release 2.35.2 without that, we can always do a .3 [07:48] that's fie [07:48] fine [07:49] pedronis: hey, my plan for solving yesterday's issue is to check the wait-chain (using the helper mvo just landed) and not retry if i see setup-profiles ahead, wdyt? [07:50] pstolowski: ? [07:51] pstolowski: didn't you say this was setup-profiles of gopkg [07:52] you shouldn't need to follow the chain to know that [07:52] pstolowski: also it should be possible to write a test, right? [07:59] pstolowski: also I remember why we put auto-connect where we put it, because setup-profiles phase2 is a nop anyway in the new world [07:59] pstolowski: another approach would be to check if setup-profiles has the phase2 flag and ignore it [08:00] either way, I hope we don't need to follow the chain [08:01] pstolowski: you basically need an installingSnap like for the disconnect check? then the two are the same again? [08:01] pedronis: yes, it was setup-profiles of gopkg, but rather than checking if we have setup-profiles for same snap (which would also need to check if it's from same change i think), we would check if setup-profiles is waiting on us. [08:02] pedronis: but you're right about setup-profiles phase 2 being noop, i forgot that [08:04] pedronis: yeah, looking at if corePhase2 -> do nothing... seems to be most straightforward to ignore setup-profiles conflict in such case [08:05] pedronis: and of course test is possible and a must [08:06] thx [08:08] pstolowski: the tricky bit is that it needs to be a spread test with an old snapd, or we need to manually construct what an old InstallPath would build [08:08] in terms of tasks [08:10] pedronis: should be possible to have a spread test for just 16.04 system with snapd from distro, don't we do that already to test upgrades somewhere? [08:11] pstolowski: we do but I don't know which snapd we want, desktop images and cloud images vs archive have different versions [08:11] ah [08:11] we sru snapd into 16.04 [08:11] right [08:14] PR snapd#5821 opened: release: 2.35.2 [08:16] pstolowski: mvo maybe can help navigate that [08:16] thx [08:24] PR snapd#5770 closed: many: provide salt for generating instance-key in store requests [08:27] is jdstrand back today? [08:29] he should be [08:48] PR snapd#5820 closed: wrappers: fix snap services order in tests [09:03] https://twitter.com/ismonkeyuser/status/1039392972339523586 ;) [09:04] mvo: may 2.35.2 live long and prosper [09:06] PR snapd#5812 closed: snapstate: refactor tests to use SetModel* [09:06] PR snapd#5814 closed: daemon: fix snap list --all with parallel snap instances [09:15] pstolowski hey, there's a small conflict here: https://github.com/snapcore/snapd/pull/5497 [09:15] PR #5497: overlord/patch: patch for static plug/slot attributes [09:16] zyga: thanks! will fix in a bit [09:17] pstolowski: is this https://github.com/snapcore/snapd/pull/5680 something we ought to review? [09:17] PR #5680: [RFC] hotplug: handling of simple add/remove scenario [09:18] I need a 2nd review for https://github.com/snapcore/snapd/pull/5802 [09:18] PR #5802: cmd/snap-update-ns: introduce trespassing state tracking [09:19] zyga: this is RFC brach for high-level comments, i'm chopping smaller pieces from there into separate PRs [09:19] ah, ok [09:20] zyga: and it needs updating after existing hotplug PRs land [09:24] zyga: so the last decision is system/core fix goes to the `snap interfaces` command but the API stays right? [09:24] mborzecki: please land https://github.com/snapcore/snapd/pull/5713 once jdstrand ack's it [09:24] mborzecki: yes [09:24] PR #5713: many: mount namespace mapping for parallel installs of snaps

[09:24] mborzecki: I implemented that here: https://github.com/snapcore/snapd/pull/5818 [09:24] PR #5818: cmd/snap: handle "snap interfaces core" better [09:24] zyga: yeah, i'm looking it now [09:25] mborzecki: I think we will need one more change [09:25] mborzecki: once snapd is the holder [09:25] mborzecki: the mapper needs to keep translating "core" and "system" to "snapd" [09:25] mborzecki: right? [09:25] mborzecki: I will make a PR for that [09:29] zyga: probably, iirc the slots will appear on snapd now (pstolowski added the change?) but i'd expect the api to return 'system' there nonetheless [09:33] mborzecki: i haven't changed that, i think the initial bits come from zyga [09:33] mborzecki: the api does return "system" when "snapd" holds implicit slots [09:36] mvo: hey, yt? [09:38] zyga: you think you could extort a review from someone and land #5802 ? [09:38] PR #5802: cmd/snap-update-ns: introduce trespassing state tracking [09:39] PR snapd#5822 opened: wrappers: allow user mode systemd daemons [09:41] pstolowski: yes [09:41] pstolowski: s'up? [09:43] mvo: hey, i was discussing writing a spread test for yesterday's issue with pedronis (see above ~1h ago); i'd need a spread test for 16.04 running an old snapd binary (the one from desktop image i think) [09:44] mvo: do you know if we do anything like that already? [09:45] mvo: i basically need to run from an "old" state into new snapd [09:46] pstolowski: we have a upgrade test already [09:46] pstolowski: I have not looked into the details in a long time [09:46] pstolowski: there is also the option to use the snapd from the released 16.04 version [09:47] pstolowski: but thats 2.0.2 which is pretty ancient [09:48] pstolowski: tests/upgrade/basic/task.yaml - let me refresh my memory on this one [09:55] PR snapd#5823 opened: snapcraft.yaml: add workaround for LP:#1791871 [09:57] mvo: looking [10:00] mborzecki: I'd love to :) [10:01] mvo: can you have a look at 5802 perhaps? [10:02] mvo: right. the question is how to enforce a well known old version, not a newer one after SRUs [10:03] pstolowski: that is hard [10:03] pstolowski: what is the version we need? [10:03] mvo: some failures on https://github.com/snapcore/core18/pull/70 [10:03] PR core18#70: hooks: add rfkill [10:04] mvo: https://github.com/systemd/systemd/issues/10068 :) [10:05] mvo: i need to find out yet; it needs to be a version that creates setup-profiles tasks with core-phase-2=true; Gustavo had it with a fresh install of 16.04 [10:06] ok [10:06] zyga: aha, nice. /me hugs xnox [10:07] mborzecki: added test to https://github.com/snapcore/snapd/pull/5818 [10:07] PR #5818: cmd/snap: handle "snap interfaces core" better [10:07] mvo, hm? =) are people stalking me on github or something? [10:07] i just filed it. [10:07] mvo: Hi - does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 ring any bells with you? [10:07] Bug #1791907: Cannot build base snaps [10:08] It's pretty weird and I don't see how it can be launchpad-buildd's fault, but don't know where to reassign it [10:18] mvo: looking at debian changelog, it would need to be snapd <= 2.33 [10:29] pstolowski: hm, the best option is probably to download it from https://launchpad.net/ubuntu/+source/snapd/2.32.9 [10:29] pstolowski: i.e. "curl https://launchpad.net/ubuntu/+source/snapd/2.32.9/+build/14895451/+files/snapd_2.32.9_amd64.deb ; sudo apt install -y ./snapd_2.32.9_amd64.deb" [10:32] mvo: nice, is this something we can rely on to stay there for the lifetime of 16.04? [10:33] pstolowski: [10:33] pstolowski: yes [10:33] mvo: great, thank you! [10:34] pstolowski: yw [10:38] xnox: I'm following systemd on github [10:40] PR snapd#5821 closed: release: 2.35.2 [10:47] PR snapd#5819 closed: tests: fix for nested test suite [11:12] pstolowski: some comments on https://github.com/snapcore/snapd/pull/5807 [11:12] PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot [11:12] you wanted to land it quickly for conflict avoidance [11:15] zyga: yes, thank you, yesterday's issue caught all my attention [11:15] pstolowski: also some small feedback on the racy append fix: https://github.com/snapcore/snapd/pull/5817 [11:15] PR #5817: snapstate/tests: serialize all appeneds in fake backend [11:19] Sep 12 10:54:56 sep121046-033697 snapd[27140]: helpers.go:174: cannot regenerate seccomp profile for snap "core": signal: terminated [11:19] hmm [11:33] PR snapd#5824 opened: [WIP] fetch store assertions together and in the context of interpreting snap-declarations [11:40] zyga: thanks for the initial review of my branch. If you've got any ideas about how to wrangle a spread test for this kind of thing, I'm all ears. I haven't had any luck so far. [11:41] jamesh: I think that's tricky, we'd have to start systemd as a user session manager in tests somehow [11:41] jamesh: I don't have any ideas, perhaps it's doable, perhaps it's doable but requires extensive work [11:41] I fixed formatting and pushed to your branch to unbreak unit tests [11:41] PR snapd#5799 closed: Install snap-failure binary on Fedora [11:42] zyga: sorry about that. I pushed the branch up just before going out for a walk (wanted to get out of the house before it was dark) [11:42] no need to be sorry :) [11:43] It was nice to see how little I needed to change === pstolowski is now known as pstolowski|lunch [11:43] and I think some of the changes might be able to go away or be minimised further w.r.t. enable/disable [11:48] PR snapd#5806 closed: tests: fix install snaps test by adding link to /snap [11:49] How to get a snap publisher "verified" ? [11:49] om26er: not sure, is there anything about it on the forum? [11:51] https://forum.snapcraft.io/t/verified-developers/2005 [11:52] We haven't published details of that internal process om26er [11:53] We're not planning on verifying everyone. [11:56] jamesh: some tweaks for tests are probably needed to mock presence of a browser [11:56] https://api.travis-ci.org/v3/job/425653825/log.txt [11:58] PR snapd#5785 closed: tests,interfaces: run interfaces-account-control on UC18 [11:59] popey: we'd like to verify our company account at least. [12:02] oh, I could verify my own company too [12:33] oh man, time flies today [12:33] hello, I'm building a Python snap and getting this [12:33] The linker version '2.23' used by the base 'core' is incompatible with files in this snap: [12:33] At the priming stage [12:33] Any idea how to debug this? [12:34] if you are building natively then your host must match the base snap of the applications in your snap [12:34] in practice, if you don't say "base: core18" and build on ubuntu 18.04 you will see issues like this [12:35] Exactly, I'm using 18.04 as host [12:35] the universal remedy is to build in a container/vm but I'll defer to kyrofa or sergiusens for details [12:35] kravietz: just add "base: core18" [12:35] Let me try [12:35] this will make your snap execute against the ubuntu 18.04 runtime [12:35] so newer libraries and everything [12:35] and compatible linker :) === pstolowski|lunch is now known as pstolowski [12:53] zyga: it worked, thanks! === mborzeck1 is now known as mborzecki [12:53] kravietz: that's great, good luck :) [12:58] pstolowski: some conflicts in https://github.com/snapcore/snapd/pull/5817 [12:58] PR #5817: snapstate/tests: serialize all appends in fake backend [13:01] mborzecki: thanks, will fix in a moment [13:03] Chipaca: standup? [13:19] ijohnson: some responses on your branch [13:19] thank you for pushing it [13:37] mvo: remeber when you told me interpreter symlinks would be relative? :-) [13:38] (snapcraft) ubuntu@snapcraft-xenial-dev:~/source/keepalived$ ls /snap/core18/current/lib64/ld-linux-x86-64.so.2 -l [13:38] lrwxrwxrwx 1 root root 32 Apr 2 21:07 /snap/core18/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so [13:53] sergiusens: uh, let me fix this [13:53] sergiusens: this sounds like a regression from core18 vs core [13:54] sergiusens: while i have you here - my snapd builds are failing in LP currently with"The source has changed on disk." and "Build failed" in https://launchpadlibrarian.net/387957761/buildlog_snap_ubuntu_xenial_arm64_snapd-2.35_BUILDING.txt.gz [13:54] sergiusens: I tried to workaround with source-type: git [13:55] sergiusens: but no luck [13:55] sergiusens: I'm currently trying to trigger the build using the beta snapcraft (once I manage to convince lp-shell) [13:55] sergiusens: but that is only good for a one-off build :/ [13:55] sergiusens: any ideas what I can try? [14:10] mvo: can you try with edge? [14:11] mvo: this is something kyrofa has been working on, mind waiting an hour until he comes on? [14:11] mvo: or give me the source where snapcraft.yaml lives on [14:12] sergiusens: this comes from https://github.com/snapcore/snapd [14:12] sergiusens: and the build is https://code.launchpad.net/~mvo/+snap/snapd-2.35 [14:14] zyga: I refreshed the branch again, do you have any recommendations on a concise snap name for the test? [14:15] mvo: you probably do not need that plugin anymore as you can script most of that in override-build [14:15] mvo: but this is your issue https://github.com/snapcore/snapd/blob/master/parts/plugins/x_builddeb.py#L21 [14:16] mvo: if you want to continue that hack you will have to do more to not trigger "change detection" [14:17] sergiusens: hm, I added that because of lp: #1772584 [14:17] Bug #1772584: Having a "snap" directory with actual content causes build failures [14:18] sergiusens: I can play with override-build but last I worked on this having a populated "snap/" dir was a no-go and snapcraft would simply not work. but maybe that has changed? any hints welcome :) [14:18] mvo: yeah, snap directory is special in snapcraft as things in there trigger special behavior [14:19] just like debian/conrol means something [14:20] mvo: I'll let kyrofa go over that with you to find a good path forward [14:20] uhm, i thought snapcraft's advanced grammar was transparent, and i could exploit it whenever i expected a string, but i guess i was wrong: [14:20] http://paste.ubuntu.com/p/hHvJXvghR5/ [14:20] when i try this: [14:20] debian/conrol means nothing though as I managed to typo my point [14:20] sergiusens: ok, I understand that the naming of the dir is unfortunate - but at the same time, refactoring our code to call it notsnap would be unfortunate as well [14:20] http://paste.ubuntu.com/p/cpcnxm9Ttt/ [14:20] sergiusens: heh, no worries, I got your point [14:20] ijohnson: test-snapd-... not sure :) [14:20] * zyga gets dinner [14:21] mvo: you could always do your packaging out of tree, that might be cleaner [14:21] sergiusens: any idea? ^ [14:22] sergiusens: a separate repo you mean? one nice benefit from the current approach is that we get a new LP build every time our repo changes, not sure if that would be possible with an extra repo? [14:22] kyrofa: ^ [14:22] ppisati: that grammar thing needs to be enabled for that key, it is not for everything [14:22] mvo: LP has tracking for that for "source" entries in parts [14:23] build.snapcraft.io does at least, which means LP does too, just need to figure out where [14:23] if it is not automatic [14:23] sergiusens: uhm, ok, so i need to patch the kernel plugin to accept it - any example of plugin / key that was patched to accept it? so i can read it and learn what i have to do? [14:23] sergiusens: ok [14:24] sergiusens: I like that the snapcraft.yaml is git right now, but maybe I just need to get used to the idea to move it out [14:27] debian/control is a bad example anyway, since it's perfectly permissible and quite common practice to drop extra packaging-related helper files into debian/ [14:29] * mvo nods [14:30] sergiusens: no, LP has no such tracking. BSI handles this itself by having a poller script that parses snapcraft.yaml and looks for other parts to poll [14:30] cjwatson: it is, our problem is that we gave meaning to so many paths... and what you say is true as long as you do not squat ones that do have meaning [14:30] this is unfortunate for us because it blocks the snapd 2.35.2 snap release so having some agreement on the way forward would be good [14:30] cjwatson: thanks for confirming that [14:30] PR # closed: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758, [14:30] snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824 [14:30] perhaps you should define something under snap/ that snapcraft won't touch [14:30] for instance, I often put things under debian/local/ [14:31] cjwatson: in the case of mvo, it is an entire source tree [14:31] last I checked directories could contain directories :) [14:31] PR # opened: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5713, snapd#5714, snapd#5717, snapd#5724, snapd#5727, snapd#5739, snapd#5758, [14:31] snapd#5759, snapd#5762, snapd#5765, snapd#5768, snapd#5771, snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5802, snapd#5805, snapd#5807, snapd#5809, snapd#5811, snapd#5813, snapd#5817, snapd#5818, snapd#5822, snapd#5823, snapd#5824 [14:31] cjwatson: yeah, but in go, that would change the import path [14:31] that sort of approach would allow people to keep things that are essentially part of snap-specific packaging somewhere under snap/, which would be tidy, while not interfering [14:31] sergiusens: could we have logic like if os.path.exists(".snap"): ignore("snap") or something? [14:31] surely you could set GOPATH [14:32] sergiusens: or snap/.i-own-this-really or something? [14:32] mvo: so kyrofa is the person to talk to as he is taking care of this thing [14:33] sergiusens: ok, sorry, I thought it would need your architectural blessing or something. if not thats fine I will talk to him [14:33] cjwatson: snap dir lives next to another source dir they have that does "import <>/snap" [14:33] sergiusens: thanks for your help in any case! [14:33] mvo: no, it does not need my architectural blessing [14:34] ah, that's a bit different from the sort of thing I was thinking of [14:35] I do generally think that a subdir reserved for use by the packaging as opposed to snapcraft would be helpful [14:35] cjwatson: yes, this is a ver special snowflake case where they got around it by monkey patching our code base through an external plugin :-) [14:35] cjwatson: the snap/local seems like a very good idea we could move forward on that [14:36] kyrofa: ^ [14:36] kyrofa: so once you are around I would love to talk to you about 1772584 (after having pestered sergiusens way too long about it) [14:37] (It's true that name collisions in debian/ are possible, but in practice I've never run into them because they're basically always hidden behind debhelper compatibility level changes, at least if they're something that it's remotely plausible people might collide with by accident) [14:38] (and the debhelper maintainer tends to do test rebuilds to spot problems with major changes AIUI) [14:39] snapcraft has nothing like http://manpages.ubuntu.com/manpages/cosmic/en/man7/debhelper.7.html#compatibility%20levels AIUI ... [14:40] no, our plan was to introduce that with build environments but that item got killed off high above [14:41] cjwatson: speaking of testing, I switched some test jobs to use the snap and it seems they still use the deb (https://launchpad.net/~sergiusens/+snap/multipass-test). Are there any obvious mistakes here? [14:41] build environments would be kind of orthogonal I thought - this kind of thing in packaging toolchains is more about the semantics of the packaging [14:42] sergiusens: there's a bug where you have to request the builds using the API - the UI currently disregards auto_build_channels [14:42] build environment is not the vm thing [14:42] we were redesigning the yaml to be versioned, so you subscribe to certain semantics [14:42] combination of https://bugs.launchpad.net/launchpad/+bug/1791265, https://bugs.launchpad.net/launchpad/+bug/1791269, and https://bugs.launchpad.net/launchpad/+bug/1791272 [14:43] Bug #1791265: Manual snap builds don't allow for snapcraft/snapd channel selection [14:43] Bug #1791269: Options for automatic builds could be defaults for all builds in a snap [14:43] Bug #1791272: Manual snap builds could use a target channel override [14:43] ah, OK, well if it ever comes up again maybe you can get a less confusing name while you're there :) [14:43] we are planning on bring that versioning piece back, but next cycle [14:44] in the meantime, you should be able to use https://launchpad.net/+apidoc/devel.html#snap-requestBuilds [14:44] thanks for the bug pointers [14:44] explicitly passing the desired channels [14:44] or https://launchpad.net/+apidoc/devel.html#snap-requestAutoBuilds should work too [14:45] thanks [14:47] I'll try to get at least the worst of those bugs fixed soon - they are absolutely confusing [14:47] cjwatson: btw, someone proposed snap/x- as an ignore pattern [14:50] same idea but x- seems cumbersome compared to a subdirectory. I think you use x- in situations where you don't have other kinds of structure available [14:50] but it's your project :) [14:51] cjwatson: I wanted your opinion actually :-) and it is good [14:52] I don't think exact choice of name is super-important, but structure is nice [14:54] zyga: what about test-snapd-svcs-disable-install-hook as the name? [14:55] Yeah that sounds good [14:56]