=== zarcade_droid is now known as Guest19897 === devil is now known as Guest39994 === ShibaInu is now known as Shibe [03:04] Bug #1761363 opened: Add interface to access to Zeitgeist [04:57] morning [05:11] PR core-build#11 closed: remove cruft from the writable-paths [05:11] PR core-build#22 closed: unit testing for sync_dir() [05:11] PR core-build#26 closed: move most of the customization into the core snap build [05:12] PR core-build#11 opened: remove cruft from the writable-paths [05:12] PR core-build#22 opened: unit testing for sync_dir() [05:12] PR core-build#26 opened: move most of the customization into the core snap build === devil is now known as Guest38148 [05:59] PR core-build#11 closed: remove cruft from the writable-paths [05:59] PR core-build#22 closed: unit testing for sync_dir() [05:59] PR core-build#26 closed: move most of the customization into the core snap build [06:00] PR core-build#11 opened: remove cruft from the writable-paths [06:00] PR core-build#22 opened: unit testing for sync_dir() [06:00] PR core-build#26 opened: move most of the customization into the core snap build [06:14] good morning [06:22] mvo: morning [06:22] mborzecki: hey! how are you? anything interessting happend in the early morning? [06:23] mvo: nope, casually browsing through reviews [06:23] mvo: any leads on the mounting thing from yesterday? [06:25] mborzecki: yes, the reason was eventually figured out by zyga and pedronis. there is some connection related state we only keep in memory and when snapd restarts this state is lost so we need to store more in the state [06:26] nice [06:27] Hey ho [06:27] mborzecki: there are some complications apparently, I did not follow all the details [06:28] Sorry for being late. I had to sleep longer [06:28] zyga: hey [06:28] mborzecki: I think we need to revert, cachio did a great deal of testing and we think its safe [06:28] Well. Had to sleep [06:28] zyga: no worries, same here [06:29] Coffee, walk the dog, then coding [06:29] We need new top-level structure in the state to fix the issue [06:30] I can explain why when I am at my desk [06:33] PR snapd#4971 closed: errtracker: add more fields to aid debugging [06:36] PR snapd#4985 opened: errtracker: add more fields to aid debugging === Mirv_ is now known as Mirv [06:59] hi === pedronis` is now known as pedronis === pstolowski|afk is now known as pstolowski [07:00] mornings [07:06] mvo: hi, don't know if you saw the logs but we have both a very specific issue with the snapctl socket, but also likely a general issue with all operations on a snap at the same time we operate on its base (if the op involves running things like hooks or starting services) [07:06] buenos dias [07:10] 2018-04-05 09:09:46 Preparing google:arch-64 (google:arch-64 (apr050907-716531))... yay! [07:11] Hey Pedronis, good morning [07:14] morning zyga [07:15] pedronis: aha, no, I did miss this part of the conversation [07:15] good morning pstolowski, did you see my test run from last night? [07:15] mvo: yes, thank you [07:16] pstolowski: afaiu is because of the placement , being after setup-profiles is too early for those tasks [07:16] pstolowski: I have the system still in this state, I can do another run to see if it consistent, but I wanted to keep it for now in case there is anything that might help understanding it [07:17] pstolowski: doInstall puts them after link-snap [07:17] pedronis: mvo yep, i saw your comments on irc yesterday, investigating this [07:17] pedronis, mvo is it possible to install lxd as the first snap and force core from edge? [07:19] pstolowski: not with the stable deb, not really, you could use the enterprise proxy locally, except that the stable deb doesn't support it [07:20] pstolowski: mvo: as I said, maybe we should add a envvar to control the channel from which we get core (or any base), but that will only help this sort of testing going forward [07:21] mvo: should we do a HO in a bit to see where we are, we need a bit to decide which bugs needs fixing for 2.32.x and which can wait [07:21] pedronis: sounds good [07:24] pedronis: we need to wait for zyga too [07:25] mvo: how exactly did you provoke the errnostate? [07:25] PR core#38 closed: Add another pi-config option [07:25] PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build [07:25] HO sounds good [07:26] and back now [07:26] I can have a call [07:26] PR core#38 opened: Add another pi-config option [07:26] PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build [07:29] pstolowski: so it seems the fix for the inject task is to put the auto-connect a bit later (after link-snap) - thats my naive view at least - or do you think there is more too it? [07:30] mvo: just trying to trigger the problem with edge from core atm but unclear how [07:32] pstolowski: what I did yesterday is essentially: 1. git checkout upstream/release/2.29 2. modify it so that defaultBaseSnapsChannel is "edge" 3. sudo systemctl stop snapd snapd.socket && go build && sudo ./snapd && sudo systemctl start snapd 4. snap install lxd [07:32] pstolowski: with an empty state of course [07:32] pstolowski: e.g. on 17.10 apt purge snapd first and then install it [07:32] * zyga is in the standup HO [07:32] pstolowski: https://paste.ubuntu.com/p/BxmxD3VFCD/ contians a rough outline of the above including the diff I used [07:33] pstolowski: trouble is of course that you cannot test anything local wit hthat method, only testing after it landed in edge :( [07:33] mvo: thanks (in HO too) [07:53] moin moin [08:10] sometimes i hate pacman -Syu vs -Sy when installing packages :/ [08:12] mborzecki: what's the difference? [08:12] mvo: did you see the (fleeting) PR about dropping privileges, yesterday? [08:12] Chipaca: I did but didn't look, sorry [08:12] mvo: no worries, it didn't work :-) === cpaelzer_ is now known as cpaelzer [08:13] Chipaca: haha [08:13] mvo: but, thing is, there's a bug that that pr was trying to fi [08:13] fix* [08:13] mvo: (FWIW the approach tehre would work from Go 1.10 on! so let's go there someday) [08:13] Chipaca: `-Syu foo` does a full system ugprade and installs foo, just doing `-Sy foo` will install foo but if its dependencies are already installed they will not get updated, which in turn may or may not hurt you badly [08:13] mvo: https://bugs.launchpad.net/snapd/+bug/1761193 [08:13] Bug #1761193: ~/.snap/ not available for root on some systems [08:13] still don't get why it's so hard to record versioned library dependencies [08:15] mvo: so... I could change the code to use 'su' to touch that file, but it feels icky [08:15] Chipaca: in a meeting right now, let me get back in a bit [08:15] mvo: yeah no worries, i'll brain dump and you read and respond when you're able [08:15] +1 [08:18] mvo: the ops we need to do on the file are read, write, and remove. 'su'ing to cat and rm works. The other approach is to use cgo, and do the setuid/setgid in a C thread we manage ourselves. I have tested neither of these approaches, and both seem rather unpalatable, so I think I'd go with the less sophisticated one =) [08:19] mvo: i think :-) [08:19] or we could move to go 1.10 \o/ [08:23] mborzecki: that manpage looks terrifying =) [08:24] Chipaca: pacman? [08:24] yeah [08:24] that was a nice case of internet counselling session [08:24] zyga: ? [08:25] zyga: BTW thank you once again for having your lab machines; last night I was able to help a customer thanks to that [08:25] Chipaca: woot! [08:25] Chipaca: that's awesome, let me know if I can expand it to be more useful in some way [08:26] Chipaca: ask mvo about how we're doing :) [08:26] zyga: oh, your counselling session was the same as mvo's meeting? [08:26] yes :D [08:31] Chipaca: reading now, thanks for tackling this issue! [08:32] Chipaca: +1 for su - even though it feels fugly === zarcade_droid is now known as Guest26743 [08:33] mvo: ok [08:33] Chipaca: what exactly do we need to do to that file? we need to append (and create if needed) and remove? [08:33] mvo: and read [08:34] mvo: not append, i think -- just create, read and remove [08:34] Chipaca: ok [08:35] mvo: another approach would be to not report the error to the user, ie any error on reading the file gets ignored [08:35] mvo: but that will make it hard to debug [08:36] I'll take a stab at using su, let's see how it goes :-) [08:37] Chipaca: thank you [08:38] Chipaca: we could also have helper that does the things we need doing and we just spawn that with su. but yeah, I'm sure it is interessting [08:39] mvo: that actually better than cat and rm, i'll do that [08:43] mvo: (to be clear, it's better because the 'write' case is hard to do properly otherwise) [08:43] * mvo nods [08:49] hi there! [08:49] I have a quick question about the snap store [08:50] is snapcraft 2.39.2 still supported by the store? [08:50] (I'm trying to push and release a snap with this version) [08:56] * jlorenzo sees 2.40.x is still marked as pre-version https://github.com/snapcore/snapcraft/releases [08:57] is anybody aware of a server-side change that produces blank errors like this one https://tools.taskcluster.net/groups/GYT_nZNyQzGn7wjcwBTajw/tasks/fFIauoJaQQCFAYJVeQqheg/runs/0/logs/public%2Flogs%2Flive_backing.log#L892 ? [09:00] kalikiana: ^ [09:01] snap refresh foo --amend seems to have broken for me recently [09:01] I get error: cannot communicate with server: Post http://localhost/v2/snaps/mame: EOF [09:01] that kind of thing every time I try and refresh a local snap into the store [09:02] running snapd 2.32.2 [09:07] pretty sure flexiondotorg also had the same issue [09:09] Yes, I've seen that --amend isn't working yesterday. [09:09] let me look [09:13] am i missing something or is this check exactly the same as one below https://github.com/snapcore/snapd/blob/master/tests/main/manpages/task.yaml#L14 ? [09:18] popey: I just tried with hte hello snap and snap refresh --amend worked for me, what snaps are you using? [09:19] I tried with a few, mame for example and signal-desktop, which I'd built locally then pushed to the store [09:21] PR snapd#4985 closed: errtracker: add more fields to aid debugging [09:27] popey: thanks, I will try harder then [09:29] popey: aha! signal-desktop reproduces it [09:30] \o/ [09:33] popey: I think its because its not in stable, obviously a bug and I think I know what it is [09:33] ooh, interesting [09:33] (I did pass --beta) fwiw [09:35] popey: yeah, this is not passed to the right place unfortunately [09:35] popey: so two things to fix: not crash, pass channel [09:37] ok. thanks [09:37] shall i file a bug? [09:40] jlorenzo: Hmmm haven't seen that before. Looking [09:43] kalikiana: thanks! Last time I saw the same error was when we were using snapcraft 2.25. Back then, Ken VanDine told me to upgrade to the latest version, which solved it [09:46] popey: either way is fine, I have a fix locally, just need to write proper tests for it [09:47] https://bugs.launchpad.net/snapd/+bug/1761435 [09:47] Bug #1761435: Can't refresh some local snaps to store snaps with --amend [10:05] diddledan: I'm running irccloud-desktop from edge, yay! Thanks! [10:10] diddledan: I have fixed the icon (changed 512x512 to 256x256 should do it) and will check the next build when it comes out. If fixed we shoul push to stable, right? [10:12] mvo: back to hacking hten [10:27] got a weird problem with arch and spread tests that use dbus, when we install a snap eg test-snapd-network-status-provider, those will generate dbus policy files, then the test fails because the provider service is denied owning the name on the bus, the only way to fix it is to systemctl reload dbus.service [10:28] now the questions are, why does it work elsewhere and should we reload the service automatically? [10:35] mborzecki: hm, afaik the daemon does a inotify watch on the dirs where we drop files [10:35] mborzecki: but maybe there is a config file in your case missing, let me double check [10:36] mborzecki: what is the dir? [10:37] mborzecki: no, there is no config file we use so it ought to work [10:39] mvo: /etc/dbus-1/system.d [10:40] mvo: weird, i see --enable-inotify passed explicitly to dbus configure [10:40] mborzecki: this is on arch? or a more general problem? maybe its not monitoring that dir for some strange reason on arch [10:40] mvo: it's on arch, there's a couple of tests failing because of this [10:46] hmm similar issue reported for avahi https://bugs.archlinux.org/task/55738 [10:50] PR snapd#4986 opened: snapstate: fix `snap refresh --amend` when the snap is not available in stable [10:52] mvo: I changed the code in this ^ one in my new api work [10:56] pedronis: oh, cool, I can run my test on the new PR to see if it fully fixes it [10:56] pedronis: or base a new fix on top of your new-api work [10:56] pedronis: also - I need to finish that review :/ sorry for letting you wait for so long [10:57] mvo: I think it should be fixed, because there is not more snapNameToID [10:58] pedronis: neato, I will run my updated test to double check. that test is useful in any case [11:00] mvo: in the new world amend is an install, not a refresh [11:00] talking to the store at least [11:01] pstolowski: how it's going? [11:02] pedronis: thanks, test is running now, I will either debug or push a PR with the updated test (I think its good to excercise the != stable path) [11:05] pedronis: almost there i think; i've added similiar inject code into doLinkSnap for snap!=core, restricted the one in doSetupProfiles to core snap-phase2 only. what's missing is restricting link-snap more [11:05] adjusted the tests, all passing atm [11:06] thanks [11:12] pedronis: I'm working on the state changes, I will have some skeleton to review soon [11:18] PR snapd#4987 opened: tests: add test to ensure `snap refresh --amend` works with different channels [11:23] zyga: did you say yesterday that the userd unit test panics? [11:24] yep [11:24] zyga: did you resolve that? [11:24] nope [11:24] it's been that for months [11:24] oh? [11:24] it hasn't -- i've been running the full test suite and it passed [11:24] https://www.irccloud.com/pastebin/qKbODxHV/ [11:24] no idea [11:24] it happens for me for _some_ reason [11:24] but maybe there's a missing dep that i had on my other machine that's missing here [11:25] jamesh: you around? [11:25] mvo: so seems the new code deals better with --amend (it's more regular, not extra calls, so not unexpected) [11:25] mvo: i think i know what's happening, there's no /etc/dbus-1/system.d on clean install because arch does not like empty dirs, so if dbus calls intify_add_watch(.., "/etc/dbus-1/system.d"..) it will fail and the error probably gets swallowed [11:26] mvo: but yes we need to decide what to do about 4900 and get it at least on master soon, if we need to prepare the cherry-pick for 2.32.4 [11:31] standup is at 3pm right? [11:37] I think so [11:37] mborzecki: yes [11:45] PR snapd#4988 opened: snapstate, ifacestate: inject auto-connect tasks try 2 [11:45] cachio: i'm close to having all of the tests passing on arch (all of those that can run ofc) [11:47] pedronis, mvo https://github.com/snapcore/snapd/pull/4988 [11:47] PR #4988: snapstate, ifacestate: inject auto-connect tasks try 2 [11:48] mborzecki, great news [11:49] mborzecki, I am working on the script to update that image [11:49] mborzecki, it should be ready today [11:51] zyga, hey, should we unblock this one right? https://github.com/snapcore/snapd/pull/4832 [11:51] PR #4832: tests: move fedora 27 to google backend [11:51] cachio: please see comment from mborzecki there [11:51] oh, not there perhaps [11:51] we need 7 more days [11:52] before the package propagates [11:52] yup [11:52] https://github.com/snapcore/snapd/pull/4980 [11:52] PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" [11:52] zyga, ah, ok [11:52] so next week [11:52] idk if voting speeds up the process [11:52] I think so [11:53] kalikiana: do you want me to file a bug in https://bugs.launchpad.net/snapstore, in the meantime? [11:54] jlorenzo: Yes, please. Sorry for my delayed response. I narrowed this down in the code but still need to confirm the actual cause. [11:54] np! [11:59] pstolowski: lgtm, comment could say more about placement [11:59] left some notes [11:59] in the PR [12:00] is the standup now, or later, today? [12:00] later [12:01] ok :) [12:02] off to pick up the kids from school, bb for standup [12:03] kalikiana: https://bugs.launchpad.net/snapstore/+bug/1761488 [12:03] Bug #1761488: snapcraft 2.39.2 failed to release a snap: snapcraft.storeapi.errors.StoreReleaseError: [12:03] pedronis: thanks === pstolowski is now known as pstolowski|lunch [12:05] * zyga is super sleepy, needs coffee [12:06] zyga: btw I was thinking that the fix for the issue will have interactions with the double setup-profiles we do for core [12:07] zyga: we basically do AddSnap twice for core but it works because in the old world we restart in the middle [12:07] mmm, but is that an issue, all we will record is the revision then [12:07] zyga: well you said we cannot do AddSnap twice [12:08] now we will do at restart and then again in the 2nd setup-profiles [12:08] which will fail? [12:08] I don't think it will, setup profiles removes the snap and adds it again [12:08] this essentially refreshes the state of the repo [12:08] this is in helpers.go in ifacemgr [12:08] one sec [12:09] ah, it does remove? [12:09] yes [12:09] and that doesn't fail if the snap is not there? [12:09] to have consistent view of that snap for setpu [12:09] I don't know [12:09] but I don't suppose so [12:09] https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L175 [12:10] looking at remove snap now [12:10] remove never fails [12:10] that's good [12:10] https://github.com/snapcore/snapd/blob/master/interfaces/repo.go [12:10] it only fails if the thing is connected, which is shouldn't be [12:10] so it's good [12:10] we disconnect the snap as well [12:11] https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L169 [12:11] just prior to calling remove snap [12:11] I think we are good === ahasenac` is now known as ahasenack === ahasenack is now known as Guest7888 [12:16] * zyga explores how the state access works and how the raw json messages behave [12:24] zyga: mmh, maybe we don't new state [12:24] ohhh? [12:25] zyga: we always do setup-profiles -> link-snap (this make sense because setup-profiles is the "activating" of the ifacestate world) [12:29] pedronis: and? [12:29] zyga: so we are interested in all active snaps, and all snaps with a pending (not ready) link-snap that is waiting on a done setup-profiles [12:29] the revision in the sna-setup of those tasks [12:29] so we could look through the state and fish that [12:29] yes [12:30] it has it's pro and cons as usual [12:30] but who would do this? the interface repo on startup [12:30] or setup profiles? [12:30] or snap manager [12:30] feels cross-manager [12:30] * zyga finds working with state to be hard [12:30] the get/set marshal/unmarshal [12:30] just done as a replacement of ActiveInfos [12:30] the raw messages [12:31] SnapsWithProfiles [12:31] ah, that makes sense [12:31] it would break if we started putting stuff between setup-profiles and link-snap [12:31] but I would question such a move === Guest7888 is now known as ahasenack [12:36] I'll play with the state variant first [12:36] but I think your solution is better for upgrades [12:36] it would have 0 "borken" moments [12:37] * kalikiana lunch [12:37] *broken [12:37] yea, the state solution and revert worry me a bit [12:37] not because problems are likely but if they appear they will be very confusing [12:38] yes, it feels like something that would warrant epoch [12:38] and epochs and customers are another thing [12:40] when we are more tools and time we can explore the idea of a more generalized concept of readiness [12:41] and then we could use that instead of looking at changes [12:41] s/are more/have more/ [12:41] but looking at changes seems attractive if a bit delicate, right now [12:57] zyga: I'm exploring a bit how that would look like [12:59] popey: hey, do you know if the remmina developer hangs out here? [13:00] popey: or where the remmina snap developer can be found? === pstolowski|lunch is now known as pstolowski [13:01] pedronis: standup? [13:02] cjwatson: hi! curious when snapcraft 2.40 will be in LP builds (if it isn't already)? [13:03] jdstrand, Trevinho submitted the snapcraft file upstream and seems to still care about it some maybe he can help you? [13:04] PR snapd#4989 opened: tests: add arch to CI [13:05] jdstrand: when it's in xenial-updates [13:05] cjwatson: ok, it is in xenial-updates [13:05] jdstrand: then builds will use it (unless oddly-configured) [13:06] it seems remmina is not using LP [13:06] cachio: 2018-04-05 14:32:39 Successful tasks: 225 ^^^ [13:07] I look forward to when we can see where a snap build comes from (and, if LP, the build log) === Eleventh_Doctor is now known as Pharaoh_Atem [13:11] jdstrand: i do not off hand [13:14] Issue snapcraft#2031 closed: Inconsistent results when building, cleaning stage and rebuilding [13:14] PR snapcraft#2047 closed: pluginhandler: organize in build instead of stage [13:19] popey: I just filed an upstream bug [13:20] ok cool. [13:21] jdstrand: is there anything else needed on emoj - I am still getting rejection mails about the x11 desktop thing [13:23] jdstrand, sorry, I dropped offline, I was saying that maybe Trevinh_o can help you [13:39] zyga: found the cause of my userd panic and it was totally my code =) === iMadper` is now known as iMadper [13:41] pstolowski: tests for 4988 failed again, this time because opensuse is out of diskspace. so feel free to push any further changes to this branch [13:43] https://forum.snapcraft.io/t/cannot-create-directory-tmp-snap-rootfs-var-lib-snapd-lib-gl32-permission-denied/4868/4 has anyone seen it on their 16.04 systems? [13:50] mvo: ok [14:06] popey, the irccloud icon is an electron icon, so I've forced it in PR https://github.com/snapcrafters/irccloud-desktop/pull/7 [14:06] PR snapcrafters/irccloud-desktop#7: fix desktop icon [14:10] jdstrand: next launchpad-buildd and snapcraft releases combined should handle that [14:10] * zyga enjoys self-made lunch [14:11] jdstrand: actually not sure it even needs a new snapcraft release, just launchpad-buildd [14:12] diddledan: oh bum, sorry [14:12] cjwatson: nice! :) [14:13] no probs :-) [14:13] I've just resolved the conflict so it's pushbutton mergable [14:13] * popey pushes the button [14:13] PR snapd#4990 opened: many: implement a poor man's privileges drop, use for auth.json [14:13] I originally fixed it the way you did, but that icon seems to be the electron stock icon rather than the irccloud icon, so I've bundled the proper icon now [14:14] you're right, i have the electron icon here now :) [14:14] if this works shall i push to stable? [14:14]