[05:55] morning [06:11] google:ubuntu-18.04-64:tests/main/desktop-portal-open-file seems broken [07:16] Hey [07:16] I will be around shortly [07:21] zyga: hey [07:45] PR snapd#6538 opened: tests/main/desktop-portal-*: try to collect some debug output in the tests [08:01] hm in both test runs that failed, document portal test was executed before the desktop portal one [08:03] back now [08:04] kids sorted out, dressed, fed, combed, sent off to school, kitchen cleaned, dog handled - all good, let's work :) [08:04] mborzecki: I haven't looked at the tests yet but perhaps they leak processes that make things fail [08:05] all the portals need to be killed / unmounted across testing sessions [08:06] zyga: yeah, that's my guess [08:06] tweaked spread priorities to make it run the document portal test before desktop ones :/ [08:07] uh [08:07] sucks [08:08] anyways, i need coffee === pstolowski|sprnt is now known as pstolowski [08:08] hey o/ [08:08] hey pawel [08:09] zyga: i frogot to give you back your serial adapter; i can send it [08:09] oh [08:09] no worries :) [08:09] keep it [08:09] I have more at home [08:10] zyga: ok, next time [08:10] and they are 3euro each so no point in sending it anywhere :) [08:10] :) [08:12] pstolowski: hey [08:17] aand reproduced [08:18] mborzecki: what is it? [08:18] idk yet, just got the same backtrace as on travis [08:18] so running document-portal activation before the test made it fail [08:18] mborzecki: mount [08:18] mborzecki: ps aux [08:19] hmm https://paste.ubuntu.com/p/2CJ63xWDG4/ [08:20] that's expected! [08:20] unmount / kill them [08:24] hm xdg destkop portal is not starting for some reason [08:24] how are you starting it? [08:25] btw: the more I see this the more I'm inclined to require tests to clean up by themselves [08:25] we are wasting lots of time on prepare/restore [08:25] and it's not working [08:25] hahah https://paste.ubuntu.com/p/cpNrbBkBH7/ [08:25] woah :D [08:25] how did we miss that :) [08:25] test execution order probably [08:26] soemthing cleaned up too much or not enough [08:27] yup, apt install python3-dbus and it worked :P [08:30] zyga: heh https://paste.ubuntu.com/p/hfhSxpF7tT/ document portal activation is a bit eager with the cleanup [08:30] yeah [08:30] good catch [08:30] I wish we had tagging in spread [08:30] we could tag a test as "dirty" or "clean" [08:30] and work our way through the maze [08:31] hm idk, i'd like to run the test on a snapshot of the rootfs, something like systemd-nspawn does, or a subvolume you can discard afterwards [08:32] mborzecki: I would use that only to detect violations [08:32] we still need to run them in contexts where we cannot afford such luxury [08:32] but I strongly agree on a need for automatic verification [08:33] we leak processes, mount points, random files, cache, temp files, package changes, kernel settings [08:35] i suppose i'll leave the extra debug info in the tests [08:36] https://9to5mac.com/2019/02/25/bbedit-12-6-sandboxing-mac-app-store/ [08:37] this is curious, it's an IDE / developer editor that runs sandboxed on macos sandbox and will now be distributed by the app store [08:37] I wonder what the usability is like [08:49] pstolowski: can we detect gpio's via hotplug? [08:53] pushed a patch, #6538 should fix master once it lands [08:53] PR #6538: tests/main/desktop-portal-*: try to collect some debug output in the tests [08:53] thanks, looking [08:54] mborzecki: I was thinking if the debug section should run without "set -e" [08:54] we have to resort to silly || true or risk more failure [08:57] pstolowski: is #5962 the last of the hotplug series? [08:57] PR #5962: ifacestate/hotplug: hotplug handlers [08:58] I'll take one more stab at https://github.com/snapcore/snapd/pull/6111 [08:58] PR #6111: packaging/opensuse: move most logic to snapd.mk [08:59] mborzecki: yes (as far as feature is concerned; there is a spread test+serial port interface in a followup) [09:02] pstolowski: great :) i'll take a look at the PR now [09:11] mborzecki: ty! [09:12] Hey there, is there a way to make a 'team account'? I'm building some snaps for my company but having them be published using my name isn't very nice [09:12] zyga: good question, i'm not sure and familiar with gpio; fwtw this is what i see with udevadm info -e on rpi3 (not complete, just a snippet): https://pastebin.ubuntu.com/p/pqvFJkQyvx/ [09:12] *not familiar* [09:13] this is what the interface can get & process as part of hotplug [09:21] need to go out for a while [09:26] PR snapd#6539 opened: cmd, daemon: split out the common bits of mapLocal and mapRemote [09:26] moin moin [09:26] ^ PR from the fun flight home [09:29] pstolowski: hmm, that's new to me as well [09:29] Chipaca: hey :) [09:29] zyga: 'sup [09:29] pstolowski: are any of the values pointing to a /dev/XXX entry (perhaps via a symlink) [09:30] Chipaca: settling back in the office, all is good, yourself? [09:30] https://www.monkeyuser.com/2019/pivoting/ (no association to snapd, just funny) [09:34] zyga: going through reviews :-) [09:34] zyga: the only one i can find in udevadm output is referencing /dev/gpiomem, but that doesn't seem relevant for the gpio interface we have atm [09:34] yeah [09:34] gpio via memory mapped registers [09:34] oh well [09:36] PR snapd#6529 closed: daemon, client, cmd/snap: snap debug base-declaration [09:45] Chipaca: hi, it's a bit strange that a GET gets an "action" there ^ [09:45] pedronis: hi! [09:46] oh dear :-/ [09:46] Chipaca: I mean I understand where it's coming from, but is not the most appropriate term for something that should be idempotent [09:46] sorry [09:46] without effects (actually) [09:47] pedronis: would select= have been better? [09:47] dunno, we don't have another one of these really [09:49] Chipaca: select would be better, we use it already in other queries, no? a cutesy one could be "aspect" [09:49] debug which aspect (but as I said a bit too cute) [09:50] maybe [09:50] pedronis: yes, we use select=all and =enabled (for list), select=refresh or =private (for find), all and connected on interfaces, all, in-progress and ready on changes, … [09:50] select is always a filter tho [09:50] (bah, refresh is weird0 [09:51] Chipaca: your pick, it's debug after all, I'm happy with either "select" or "aspect" [09:52] I like aspect, but i like the consistency of select [09:52] hm [10:14] PR snapd#6540 opened: daemon, client, cmd/snap: debug GETs have actions, not aspects [10:15] wait I got that backwards [10:15] * Chipaca groans [10:17] Chipaca: changed [10:54] snap_mode=try means it hasn't rebooted after changing core/kernel/gadget, right? [10:54] Chipaca: I think so [10:54] Chipaca: bootloader changes that to trying [10:55] Chipaca: so snapd knows what's going on [10:56] so maybe that's the bit that's broken [10:57] what are you seeing? sorry, I'm deep in another topic and just responded because I saw the question [10:57] zyga: stay there :-) [10:57] zyga: i'm just talking to myself [10:57] tea helps :) [10:57] I'm drinking some now, it's not as warm as it was in the south [10:58] pedronis: on snapd stat, if snap_mode==try, we should set the restarting flag [10:58] start* [10:58] this'll probably break some of our tests [10:59] also, our minds [10:59] ¯\_(ツ)_/¯ [11:00] * Chipaca tries a reproducer [11:03] Chipaca: ? [11:03] Chipaca: I wouldn't solve the problem that way [11:03] pedronis: ok [11:03] Chipaca: too much conceptual change [11:06] Chipaca: boot ids seems still a bit more of a solid bit of info than our flags [11:08] Chipaca: let's have a chat later [11:14] hey all, I've got 2 approvals on this PR, can it land? https://github.com/snapcore/snapd/pull/6525 [11:14] PR #6525: interfaces/wayland: allow wayland server snaps function on classic too [11:16] greyback: yes [11:18] pedronis: should I just merge it [11:18] Chipaca: yes [11:18] boom [11:18] PR snapd#6525 closed: interfaces/wayland: allow wayland server snaps function on classic too [11:19] thanks guys [11:19] greyback: notice that it's ok because of jdstrand review, typically anything in interfaces/builtin needs that [11:19] not just 2 reviews [11:19] pedronis: understood. === chihchun_afk is now known as chihchun [11:34] zyga: i'm trying to understand the core-support plug/slot wrt to you comment in the migration-fix PR, checked some very old releases (2.14-2.16); it actually seems to be introduced for the "core" snap, not "ubuntu-core"? [11:36] pstolowski: oh? perhaps I was mistaken, if it was never present on ubuntu-core, does that simplify the bugfix? [11:40] zyga: most likely yes; we probably don't need to do anything special with it on undo (core back to ubuntu-core) since core-support is obsolete so will not appear on current core if we fail on transition and need to go back to u-c [11:41] pedronis: ^ do you think this makes sense? do you remember when did we introduce core-support? [11:54] re === mborzeck1 is now known as mborzecki [11:55] PR snapcraft#2486 closed: colcon plugin: support build-time chaining [12:05] mborzecki: how are you feeling? [12:11] pstolowski: ok, we need to chat about that PR in general [12:11] * pedronis finishing my lunch break [12:24] pedronis ok; btw core-support was added in 2.22 [12:30] pstolowski: it doesn't seem like ubuntu-core used it, it didn't in its last table release [12:30] and at that time core was [12:32] Lunch time [12:32] pedronis: yes, let's talk in the standup [12:35] wth just happend with freenode? [12:37] mborzecki: hmm looks fine here [12:38] * pstolowski lunch [12:52] pstolowski: zyga: I'm confused by the preexisting comment in that PR, wouldn't core and ubuntu-core profiles have different disk names? [12:57] niemeyer, hey, could you please add permission for [12:57] ERROR: (gcloud.compute.disks.snapshot) HTTPError 403: Required 'compute.zoneOperations.get' permission for 'projects/computeengine/zones/us-east1-b/operations/operation-1551185626188-582cb8c3acb08-df0e03b2-6722caa8' [13:00] may you help me to run the tests in snapcraft? I've installed all the system dependencies as README indicates, then created the venv, and installed all there as indicated, but when I run the tests I get a RuntimeError: Snapcraft requires PyYAML to be built with libyaml bindings [13:03] pedronis: let me look at the PR [13:03] Facu: perhaps your venv didn't built pyyaml because you were lacking C headers for the C shared library it depends on? [13:04] pedronis: which comment are you referring to? [13:05] is it https://github.com/snapcore/snapd/pull/6530#discussion_r259345905 ? [13:05] PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core [13:08] zyga, there's no complain at all in the install process: http://linkode.org/#NLIK5LANIbGcPu11FZcKy4 [13:09] Facu: I don't know, just a guess [13:10] zyga: I'm probably just confused [13:11] pedronis: I added the comment because I read this part [13:11] https://github.com/snapcore/snapd/pull/6530/files#diff-b88a3954d898e0a8ab681d98f1407a0fR344 [13:11] PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core [13:11] but after discussing with pawel I think there is no way that we can have plugs on ubuntu-core / core there [13:11] still, that was my reasoning at the time I added the comment [13:14] zyga: I forgot that profiles are generally per app/hook, and ubuntu-core had none afawu [13:15] pedronis: there was the "core-support" plug on the configuration hook but I forgot if it was present in ubuntu-core [13:23] pstolowski: will hotplug land for .38? [13:23] anyone wants to do a 2nd review of #6538? [13:23] PR #6538: tests/main/desktop-portal-*: try to collect some debug output in the tests [13:26] jamesh, hi [13:27] mborzecki: i think so, the plan was to land it by malta sprint. i need to check if mvo wants to take a look, then i can merge. thanks for re-review btw! [13:30] aand it's green [13:46] pedronis: https://forum.snapcraft.io/t/how-get-snap-set-property-list-snapd-api-extension/10155 [13:49] zyga: do you remember from what repo ubuntu-core was built? [13:49] pedronis: the snap? [13:49] let me look [13:50] https://launchpad.net/~snappy-dev/+snap/ubuntu-core [13:50] apparently this one https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk [13:51] zyga: never had hooks === alan_g_ is now known as alan_g [13:58] Chipaca: is that post formatting broken? it seems cut up [13:58] pedronis: not as much broken as nonexistent [13:59] I cannot parse bits of it [14:00] PR snapd#6538 closed: tests/main/desktop-portal-*: fix handling of python dependencies [14:00] Chipaca: pstolowski: standup? [14:02] yeah was fighting the setup [14:03] I added architecture tracking: https://snapstats.org/architectures [14:25] Chipaca: I asked the poster the review the formatting [14:37] PR snapcraft#2469 closed: cli: clean up snapcraft push output [14:51] Pharaoh_Atem: hey [14:51] around? [15:00] pedronis: seems like that forum topic is about config validation -- which we make impossible by not allowing you to -d the whole config [15:00] (we already have people asking for this) [15:03] Chipaca: do you have super powers to fix the formatting of that post? he reposted but the formatting is still broken [15:03] pedronis: I do [15:03] pedronis: I didn't because I doubt it'll make more sense, but if it'll help you I'll do it [15:03] Chipaca: unless it's really cut off [15:03] * Chipaca does it [15:03] pedronis: it's really cut off [15:03] ah [15:03] :/ [15:03] ok [15:04] nvm [15:04] pedronis: at least the PROBLEM section is now sensible :-) [15:07] Pharaoh_Atem: I think I got what you asked for on snapd.mk review, I will run one more round of spread and propose my changes back [15:15] damn, why the desktop test always have to be so flaky [15:15] mborzecki: leaking processes [15:15] google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser failed now [15:15] * diddledan spills some processes all over the carpet [15:18] wth is this? https://paste.ubuntu.com/p/CZJ4JqZ4qg/ [15:19] I'd say that's a paste of some terminal output *duck* [15:20] can't see what's going wrong though :-( [15:20] OSError: [Errno 38] Function not implemented: '/run/user/12345/doc/257d6b8c/file-to-write.txt' [15:20] just spotted it :-) [15:21] the portal is running though [15:26] wonder if it's because of python trying to truncate the file [15:29] * cachio lunch [15:43] duh, obviously the test works in isolation, even when repeating it a couple of times [15:44] mborzecki: think about system level solutions [15:44] how to find broken tests? [15:44] heisenbug [15:45] no, just order bug [15:45] tests don't clean properly [15:45] zyga: given it's ENOSYS, i'd guess it's from fuse as used by xdg-desktop-portal [15:45] aah [15:45] random order may put stuff that leaks stuff ahead of test that is affected by it [15:45] or document portal to be exact [15:45] mborzecki: yes [15:45] damn desktop tech [15:47] Pharaoh_Atem: https://github.com/snapcore/snapd/pull/6111 [15:47] can you re-review that please [15:47] PR #6111: packaging/opensuse: move most logic to snapd.mk [15:48] mborzecki: ^ perhaps you can have a look as well [15:48] the next thing to fix is to move golang hardening flags to a helper like I indended [15:48] then all of snapd.mk should be reusable [15:51] ever heard of snapd forgetting to generate a unit? https://discuss.linuxcontainers.org/t/containers-fail-to-start-after-server-upgrade-to-ubuntu-18-04-2-lts/4174/7 [15:51] snap.lxd.daemon.unix.socket is present, snap.lxd.daemon.service isn't. Doing a back and forth refresh between two channels fixed it (back to same rev that was broken) [15:51] stgraber: no [15:51] that's interesting [15:52] stgraber: can you ask for `snap changes` on the LXD forum? [15:52] perhaps there are some clues there === ErichEickmeyer is now known as Eickmeyer [15:53] zyga: output now included [15:54] it would be awesome if pasting something into the forum showed a clippy saying "perhaps you wanted to paste pre-formatted text" [15:54] "running service command" is interessting? [15:54] zyga: just a hunch, but that's probably ENOSYS i'm seeing https://github.com/flatpak/xdg-desktop-portal/blob/master/document-portal/document-portal-fuse.c#L718-L735 [15:54] ah yeah, I'm editing people's posts all the time :) [15:54] perhaps ask for "snap tasks NNN" for the ones that failed? [15:54] stgraber: same here, thank you for doing that :) [15:55] mborzecki: oh, nice catch [15:55] I didn't know the portal did not support that [15:57] mborzecki: ^ [15:57] zyga: updated [15:57] Chipaca: ^ do we clean up if a service refresh fails, with regards to unit files? [15:57] thanks, I see [15:58] zyga: stgraber: it's possible an in-task cleanup is wonky [15:59] feels like worth reporting, even to add a spread test to see it works forever [15:59] zyga: 'works forever' don't know which industry is that, but not this one :P [16:00] * zyga shrugs and writes medical-grade code ;-) [16:02] medical grade as in it makes you vomit? [16:03] * zyga inserts matrix reference with no-mouth neo [16:03] "so offensive it kills 99.9% bacteria" [16:04] pstolowski: did you find out how to check about the snap-confine profile? [16:04] pedronis: we talked about it, I gave a few suggestions that all should be sufficient to check this [16:05] ok, thx [16:05] pedronis: yes, but i'm fighting a spread test error after the change [16:09] afk for 30 min [17:04] pedronis: I fear the followup refactor commit on #6540 is bigger than the original :-) [17:04] PR #6540: daemon, client, cmd/snap: debug GETs ask aspects, not actions [17:07] Chipaca: looks good though [17:07] thank you [17:08] huzzah [17:09] HAH! the fix for service completion is in my 'git stash' [17:09] never pushed a PR with it :-( [17:09] pstolowski: was in meetings, can we help somehow? [17:10] pedronis: it's fine, thanks, will push in a moment [17:20] PR snapd#6541 opened: tests: change how dir is umounted on desktop-portal.sh [17:42] zyga: can you review the new tests added to #6530 [17:43] sure [17:43] PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core [17:43] looking [17:44] +1 [17:45] pedronis: I wish we had a "snap debug wait-for-change-type core-transition" or something like that [17:46] pedronis: if mvo does a release, I will package it first thing tomorrow [17:47] PR snapd#6542 opened: cmd/snap: fix `snap services` completion [17:56] cachio: hey [17:56] cachio: has the leap 42.3 image changed? [17:57] cachio: I thing we could use an update (just take stock 42.3 and run "zypper refresh && zypper dup" on it) [18:26] PR snapcraft#2483 closed: cli: Handle legitimate provider exec errors [18:35] PR snapcraft#2487 opened: Release changelog for 3.2 === pstolowski is now known as pstolowski|afk [18:51] Hey zyga, any idea why this doesn't work in LXD? https://paste.ubuntu.com/p/QT2mnJWZ5J/ [18:52] zyga, this works though: https://paste.ubuntu.com/p/zgf528P6sN/ [19:02] zyga, in progress [19:03] I almost have the tumbleweed image [19:04] but there are some permissions that are missing and untils those are not granted I can't publish the image [19:07] niemeyer, hey [20:09] cachio: ack, thank you [20:09] kyrofa: looking [20:09] zyga, I think the images will be ready tomorrow [20:10] I need those perms [20:10] kyrofa: I don't know how here doc are implemented but I'm sure you have a denial saying why it didn't work [20:10] kyrofa: most likely that shell opens a temporary file [20:10] kyrofa: and passes a fd to the child process as input [20:10] kyrofa: in the case it works the apparmor profile describes that file and allows snap-confine and bash to both use it [20:10] kyrofa: in the case where it does it is denied by the outer stacked profile [20:11] kyrofa: on the forum there are some discussions of "apparmor object delegation" but this is not implemented in the kernel or in userspace yet [20:11] kyrofa: so for now, it's a bummer and we can only fix it by adjusting lxd profile; not sure if the adjustment is sane from security point of view though [20:17] zyga, indeed, here are the denials (on the host): https://paste.ubuntu.com/p/4Sh6Hkf8sQ/ [20:18] kyrofa: report a bug on lxd with those details, perhaps it will be included [20:18] it would be good to check what is the temporary file name pattern [20:18] is it always sh-* [20:19] stgraber, does that sound like a lxd bug to you? Happy to report it [20:22] stgraber, uh, context: the fact that this doesn't work in LXD: https://paste.ubuntu.com/p/QT2mnJWZ5J/ [20:30] stgraber, with this type of denial on the host: https://paste.ubuntu.com/p/4Sh6Hkf8sQ/ [20:37] kyrofa: the file_inherit stuff is some kind of apparmor bug causing the profile in a container to have to be slightly more comprehensive than on the host [20:37] kyrofa: IIRC this is something we ran into with snaps a LONG time ago and which got fixed by adding the required allow rule in snapd generated profiles [20:38] the /apparmor/.null path is a bit odd though [20:49] stgraber, huh, so perhaps this used to work and regressed? [21:06] kyrofa: yeah, that's posssible, it could have been a change to the generated apparmor profile, can be a change to the kernel or a change to the apparmor parser [21:06] kyrofa: in all cases, you want someone from apparmor taking a look into this, jdstrand might know what's happening or jjohansen [21:06] kyrofa: the exact kernel you're running may also matter here [21:12] stgraber, alright, thank you! [21:17] pedronis: am I right to think we said we should make 'snap debug connectivity' use the GET path as well? [21:18] pedronis: (so everything listed under snap debug -h works without sudo) [21:41] PR snapcraft#2488 opened: cli: Fix traceback count check in error test [21:47] PR snapcraft#2489 opened: cli: Mock Raven client in error tests