[05:02] morning [06:58] PR core#89 closed: hooks: fix 30-fix-timedatectl.chroot to DTRT when running on non-core devices === pstolowski|afk is now known as pstolowski [06:58] mornings [06:58] good morning [06:58] hey mborzecki [06:58] hey pstolowski [06:58] I'm just settling in [06:58] what a terrible morning :| [06:58] it's cold and wet and raining [06:59] pstolowski: mvo: zyga: hey [06:59] but that's just today, it will get better soon :) [06:59] cold here, no rain though [06:59] I'm _outside_ [06:59] zyga: haha :P [06:59] not enough space to work indoors :D [06:59] I will run make in a loop to keep me warm [06:59] zyga: wear some kalosze :P [07:00] wellington boots is the english name? [07:00] zyga, mborzecki: good morning [07:07] mborzecki: i wonder if "galoshes" has the same etymology as kalosze? [07:07] mcphail: where did you hear it? [07:08] galoshes are rubber overshoes/boots [07:14] ok, breakfast and then work [07:14] mcphail: hah, quite possible, probably sharing the same roots, my dictionary says polish kalosze came from italian caloscia, while for english galoshe i'd probably look for french roots (?) [07:18] heh italian wiki mentions caloscia coming from french galoche [07:19] ah! good find :) [07:25] mvo: back to remapping [07:26] * zyga unchecks "use transparency from system theme" to make white gnome-terminal actually white and not dim gray :P [07:28] guys, have you already enabled 2fa in github? [07:33] zyga: yay, for some reason - google:ubuntu-core-18-64:tests/main/snap-disconnect [07:33] [07:33] zyga: its all in core18-all-fixes-all-tests [07:33] mborzecki: I did some time in the past but disabled it later [07:33] why, do we have to use it by policy now? [07:33] mvo: what about it? [07:34] zyga: it failed, I have not looked into the why yet [07:34] zyga: I merged your latest bits (I think at least) [07:34] I will finish with this PR [07:34] oh [07:34] merged where? master [07:34] or into the helper branch [07:35] zyga: into the core18-all-fixes-all-tests branch [07:35] ok [07:35] zyga: looking into a timezone control failure now first though [07:35] mvo: I'd like to land the remapping through master [07:36] zyga: oh, absolutely [07:36] the helper branch has so much stuff it's hard to reason about sometimes [07:36] zyga: this is just a test ground [07:36] yep [07:36] zyga: I cherry picked only [07:36] zyga: so maybe that was the problme [07:40] mvo: would you mind if i pushed a fix to #5436? [07:40] PR #5436: tests: add basic integration test for spread hold [07:44] mborzecki: not at all, please go ahead [07:44] mborzecki: uh, silly me, thanks for spotting the typo [07:44] snap snap :) [07:50] we need another review on https://github.com/snapcore/snapd/pull/5432 [07:50] PR #5432: cmd/snap-confine: fix snaps running on core18 [07:50] mborzecki: ^ perhaps you? [07:51] mvo: I opnened the remapping PR, I will now focus on unit testing while spread is running [07:52] PR snapd#5439 opened: overlord/ifacestate: translate "core" <=> "snapd" as appropriate [07:52] mvo: it's the even more simple version of what you saw last week [07:53] mvo: have you seen the mail from neal? [07:53] sent yesterday at 16:22 [07:53] zyga: yeah, but have not really read it yet [07:54] zyga: i keep thinking i should update snapd in debian and then finding something else to do [07:55] mwhudson: yeah, I feel I should do it too [07:55] i think some new deps need ITPing, sigh [07:57] that's likely, we haven't been paying the ITP tax for a while [07:57] it's not hard, just boring [07:57] maybe i can dedicate some time to it after 18.04.1 is done [08:02] brb [08:19] somewhat less rain now [08:32] PR snapd#5440 opened: snapstate: allow setting "refresh.timer=managed" [08:37] zyga: replied to the question from neal, the only thing we do with nsswitch.conf is a bind mount into the snap client [08:37] yeah, I replied as well, not on bugzilla as I cannot log in for some reason, I will reset my account later to fix that [08:38] I think since there is no confinement some snaps may be fiddling with stuff [08:38] but really why would they re-label something is unknown to me [08:38] zyga: I suspect the re-label is a side-effect of e.g. editing the file maybe? [08:38] maybe [08:38] I don't know how labeling in selinux is expected to work [08:38] is everything selinux aware or things break [08:39] or is there some magic that makes vim just work without selinux specifc code in it [08:39] I suspect the label is some default inherited from a parent directory [08:39] maybe the fact that squashfs doesn't ship extended attributes and get some default labels is a factor [08:40] hmm, bunch of refresh deltas spread tests failing [08:49] travis log display is utter garbage [08:49] it is so slow I cannot imagine we're the only one complaining about it [08:53] zyga: we probably abuse it a bit too much [08:54] i just click on raw as soon as it lets me [08:54] yeah, probably optimized for 20 lines of output [08:54] yeah, but even _that_ is slow to render [08:54] (I mean, the raw button) [09:02] anyone wants to take a look at #5435? simple but lengthy review [09:02] PR #5435: overlord/snapstate: introduce path to fake backend ops [09:03] btw. got 2 travis jobs that failed becase of 'no input received in 10 minutes' [09:03] restated both already [09:03] same [09:04] though not restarted becaue working on more tests to push [09:04] augh [09:04] what's up Chipaca ? [09:04] things that don't work as expected in Go because reasons [09:04] in this case, umask :-) [09:05] anyway, i'm off to the gym [09:05] bbiab [09:05] enjoy [09:05] * zyga enjoys 13C [09:05] i won't, but i am enjoying my back not complaining all the time [09:05] so, ¯\_(ツ)_/¯ [09:05] yeah [09:05] that's creepy [09:06] zyga: what's creepy? [09:07] Chipaca: what's the issue with umask? [09:07] one sec [09:07] Chipaca: per thread/process again? [09:07] mborzecki: only affects current thread [09:07] yes [09:07] omg [09:07] * zyga looks for pastebin of pictures [09:07] we need a separate goroutine for creating files/dirs :) [09:08] Chipaca: https://imgur.com/a/MPXcDyj [09:09] zyga: you don't have fonts-takao-pgothic? [09:09] apparently :D [09:09] PR core#90 opened: hooks: fix silly copy/paste error from PR#89 [09:09] this is in irccloud so maybe font issue? [09:10] there is a thread about some apparently broken font sharing [09:12] another stalled job [09:12] https://travis-ci.org/snapcore/snapd/builds/399031115?utm_source=github_status&utm_medium=notification [09:13] * zyga tries to understand the interface manager test setup code, lots of stuff there [09:14] Error executing google:arch-linux-64:tests/main/refresh-delta-from-core [09:20] PR core#90 closed: hooks: fix silly copy/paste error from PR#89 [09:21] * zyga is slowly warming up thanks to hot coffee and loads of blankets [09:24] hm, tests broken? all recent runs are "!" [09:34] mvo: we noticed, timeouts for !known reason [09:35] zyga: :( [09:35] zyga: ok [09:47] pstolowski: pushed a fix to #5434 [09:47] PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames [09:52] mborzecki: thanks [10:12] oh, I see the mail now [10:12] * zyga goes to enable 2fa on gh [10:14] yeah i just did [10:14] although i wonder if i'm actually part of canoni org on gh [10:14] i'm definately in snapcore org [10:15] anyway... probably a good idea anyway [10:17] ok,ddone [10:34] another failed run wrt deltas [10:36] 2018-07-02 10:24:42 Cannot allocate google:ubuntu-core-16-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout [10:36] mvo: I'm slowly making progress on testing the new ifacestate code [10:36] * Chipaca hugs mvo [10:36] also more normal conditions now, with no rain and slowly raising temp [10:37] gah, phone call. Need to step out for an hour more or less. [10:37] * Chipaca should really have a shower before meeting people irl [10:38] * Chipaca compromises [10:47] Chipaca: I wonder if the compromise is on time or on people [10:48] or does it involve showering a fraction of some kind [11:03] i should probably add a label for parallel installs PR, there's quite a few of them [11:05] what happens when a snap becomes inactive wrt snapstate [11:05] is Active= false set [11:05] or do we also change Revision/Channel when that happens? [11:09] Chipaca: I appreciate the hug! any particular reason? or just sympathy for the broken tests? [11:24] brb [11:37] mvo: https://www.youtube.com/watch?v=OawrlVoQqSs [11:38] mvo: in particular for pointing out that MATCH only reads its input once [11:38] mvo: but in general, because why not [11:38] * mvo hugs Chipaca [11:39] Chipaca: haha :) [11:40] zyga: a compromise in that i'd be a little bit later than was expected of me, but i'd also be a little less smelly [11:41] zyga: IOW a quick wash rather than a shower or nothing [11:49] zyga: in which context? === pstolowski is now known as pstolowski|denti [11:54] dentist apointment, will probably miss the standup [11:55] pstolowski|denti: godspeed [12:03] pedronis: I was looking at "representative" test cases for mocking state in my tests [12:03] pedronis: I will show you soon in a PR diff [12:05] zyga: during a refresh we just set Active = false and remove the current link (see doUnlinkCurrentSnap ) [12:06] zyga: disable does that plus remove-profiles [12:06] ah, that's good then [12:06] thank you! [12:07] zyga: only discard and link-snap move/change Current [12:10] PR snapd#5441 opened: many: expose publisher's validation throughout the API [12:11] mvo, pedronis: initial PR with snapd/core connection re-mapping [12:11] https://github.com/snapcore/snapd/pull/5439 [12:11] PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate [12:12] I will now get some food and then focus on adding higher-level tests [12:23] hmm, somehting's taking forever to reboot [12:23] * Chipaca kills it and starts over [12:25] Moins [12:33] niemeyer: moin moin. How's things? [12:34] Chipaca: Yo.. pretty good.. weekend was nice.. raining like crazy outside but I don't have to be there.. can't complain.. :) [12:35] rain is nice when you don't need to be in it, yes :-) [12:35] here we've been having ~30C sunny days, which is awesome [12:35] (the locals are melting though) [12:51] niemeyer: hi, i tried making a case for not changing the name on the socketcan PR, if it doesnt convince you I can make the change though - also available for a call for next few hours if you want [12:51] joc: Thanks, yeah, a call would be nice to figure out the other details [12:51] joc: What's your tz? [12:51] joc: My next couple of hours are meetings [12:52] niemeyer: if the details are around exactly what permissions to grant i think having jdstrand would be useful [12:52] niemeyer: i'm in London [12:52] cachio: how long does the intial reboot of google:ubuntu-core-16-64 usually take, do you know offhand? [12:53] Chipaca, no [12:53] didn't measure it [12:53] i'm one of the locals who is melting [12:53] joc: How's 17:30 your time? [12:54] niemeyer: yep, fine [12:54] joc: Thanks, I'll put something in the calendar [12:54] joc: melting? in UK? [12:55] * zyga joined the standup early [12:55] mborzecki: can you come, I want to see if my connection is OK [12:55] yep! but my liquefaction point is quite low ;) [12:56] zyga: joining [12:56] thx [13:20] Chipaca: interesting [13:22] function foo() { cat; }; function bar() { a=$(cat); echo "$a"; }; foo < /etc/passwd | wc -l ; bar < /etc/passwd | wc -l ; a=$(cat /etc/passwd); echo "$a" | wc -l; a=(cat /etc/passwd); echo $a | wc -l [13:22] Chipaca: ^ so newlines are ok [13:22] but you must do quoting correctly [13:23] zyga: we might (although I checked and it seemd ok) [13:25] zyga: we're doing: local stdin="$(cat)"; echo "$stdin" | grep -q -E "$@" || { echo "error..." } [13:26] Chipaca: what if we did `grep --color=never '^test' /etc/passwd > ...` [13:26] Chipaca: it's probably already doing iastty() but who knows :/ [13:27] s/iastty/isatty/ [13:27] mborzecki: even if that shell were using an alias (i don't think noninteractive shells are), --color=auto means it's not doing it on stdout that isn't a tty [13:27] yeah [13:27] but, we could [13:27] we could also say \grep instead of grep [13:28] mborzecki: lots of things to try, if only it weren't stuck :-) [13:28] and then it's magically fixed and we don't know why [13:38] Chipaca, cachio I have reproduced it locally, it reboots, no spread about and no network in the VM (I logged in via the virtual serial interface) [13:38] Chipaca: could you look at #5441 when you have a moment [13:38] PR #5441: many: expose publisher's validation throughout the API [13:39] pedronis: need to go to the boys' school, but will look on my return [13:39] thx [13:39] Chipaca, cachio fwiw, it looks like netplan is misisng in edge right now [13:39] mvo, so seems to besame issue we already saw for core 18, right? [13:40] cachio: yeah, I saw that with core18 when I was developing on it and had no working network config yet [13:42] cachio: I think I know what is going on, I'm rebuilding the core snap now, lets see if that fixes things, I tell you more once the build ran [13:42] ok [13:43] pedronis: actually had a few minutes and, well, +1 :-) [13:43] PR snapcraft#2167 closed: many: detect local source changes [13:43] * zyga -> taking the dog out === pstolowski|denti is now known as pstolowski [13:55] mvo, could be affecting some dependencies that we are installing to those imafes? [13:55] images [13:57] cachio: yes, I think thats exactly the problem [13:57] cachio: if the rebuilds does it I will add code to the image build to ensure it fails if the dependencies do not work [13:59] mvo, so, we need netplan as an estra dependency? [14:05] mvo, tell me if I need to revert the last image [14:06] cachio: give me 5 more minutes, running a test now [14:06] cachio: maybe it was just core that was busted, if so I will push a PR with a test in the core build script to ensure this won't happen again [14:10] mvo, nice [14:19] PR core#91 opened: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image [14:44] mvo: that ppa is all that was needed? [14:45] mborzecki: yeah, I think so, I'm looking at spread now to see if I can create a test case for the no-output issue [14:46] magic :) [14:46] mborzecki: heh, for some people thats their first name ;) [14:46] hippie kids though ... [14:46] :) [15:01] * zyga testing [15:02] * Chipaca tea [15:20] * cachio lunch [15:39] pedronis: #5441 gtg [15:39] PR #5441: many: expose publisher's validation throughout the API [15:39] thx [15:46] PR snapd#5441 closed: many: expose publisher's validation throughout the API [15:49] PR snapd#5442 opened: many: expose publisher's validation throughout the API (2.34) [15:49] mvo: I created the backported cherry-pick for it ^ [15:55] pedronis: thank you [16:00] mvo: question, should I aggregate all snapd-interfaces patches in one PR where they can be realistically tested or shall we land smaller PRs and wait till enough are present to write bigger tests [16:01] zyga: what is pending? I mean beside the work on 5439? [16:01] zyga: ideally smaller ones and we test via the core18-all-tests pr [16:03] mvo: I'd like to write unit tests but now I think I need more from the PR with "snapd-makes interfaces show up" [16:03] specifically, to write more useful tests for PR 5439 [16:04] PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate [16:04] zyga: ok, I think also we need more, I merged 5439 and it fails on core18, but maybe I can whitelist the snap-connect test on core18 [16:04] zyga: let me try this [16:05] cachio, niemeyer : I think the spread reboot hang issue is found https://github.com/snapcore/spread/pull/61 [16:05] PR spread#61: client: fix dialOnReboot() if the remote does not reply [16:05] cachio: I tested using a spread qemu test that "rm -f /etc/interfaces.d/*; REBOOT" [16:06] mvo: Wow, nice debugging there, thank you! [16:07] niemeyer: thank you, it was fun to debug. I am looking into a unit test now [16:30] mvo: I'm cherry-picking patches from the WIP branch to improve [16:30] zyga: \o/ [16:31] niemeyer, cachio I pushed PR#62 to spread with a simple unit test, let me know if I you prefer to clean it up a bit more, this was the smallest diff I could come up with for the test [16:31] joc: https://meet.google.com/muo-bdbu-fgo?authuser=0 [16:31] mvo: Thank you [16:32] niemeyer: and no rush, I know you are super busy [16:38] zyga: https://pagure.io/flock/issue/24 [16:39] interesting, we should attent [16:39] attend* [16:47] mvo: No problem, and thanks for the test.. curious to see how you've put that in.. I thought it'd be trickier to have the ssh reboot semantics tested [16:49] Hi. I have installed a service using snap and then found it runs as root. Is this expected behavior? I understand snap uses apparmor for security, so this _might_ be OK. [16:50] ElDiabolo: hey, this is expected, yes [16:51] ElDiabolo: the service runs with seccomp profile limiting the system calls it can use, it runs in a device cgroup which limits the system devices that it can access and (on many systems) it also runs with an apparmor profile which limits many things including files that can be read or written, network operations that can be performed, ipc operations that can be performed and more [16:53] PR snapd#5443 opened: interfaces: treat "snapd" snap as type:os [16:54] zyga, Ah, OK. It does however break with several decades of unix tradition. My first reaction to this was "we won't use that". [16:55] zyga, I don't want to start a discussion on that, just wanted to point out that people with a certain experience will ract the same. [16:55] mvo, pedronis: I think this is ready to review and could land quickly (5443) [16:55] s/ract/react/ [16:55] zyga, thx for the info. [16:56] ElDiabolo: instead of using unix users for privilege separation we use way more things that actually separate apps from the system and from each other; The reaction is understood, eventually we should teach ps and friends to display various confinement labels to make this clearer [16:57] zyga: ElDiabolo: ftr we will be adding run-this-service-as-a-user support at some point (but it's not on the roadmap yet) [16:58] ElDiabolo: right, this will create non-root users for certain snap services but really, it's just for compatibility (some software checks for this) than actual sandboxing because it's an opt-in from a snap developer [16:59] Thx. Train arrives, I'm out. [16:59] also some open questions as support for high uids is iffy [16:59] :-) [16:59] speaking of trains, I need to go make dinner [16:59] ttfn [16:59] one of my laptops used to be called iffy [16:59] zyga: was it super reliable [17:00] yes but was very ugly [17:00] it was a CE test laptop [17:00] still have it in a box somewhere [17:00] zyga: CE as in Windows CE? or as in Customer Engineering? [17:02] as custeng [17:02] it's pink [17:03] zyga: aha, I think this might be the missing piece [17:03] zyga: feel free to merge into core18-all-tests and push [17:03] mvo: I'm chopping the WIP branch, one more and I'll close it [17:03] each of the new pieces should be mergably by itself [17:04] and then you can drop all my patches from the integration branch and just merge (rebase) master [17:04] ok [17:15] * zyga -> quick supper [17:49] back, [17:49] not used to doing dishes by hand sans a dishwasher but what can I do ;-) [18:41] mvo, hey [18:41] Irunning sru I see a weird error just on artful [18:41] using ubuntu software [18:42] I see segfault when I search "snapd" in ubuntu software [18:42] and it closes [18:44] mvo, still researching it [18:44] the rest of the validation is done and it is ok [19:01] cachio: thanks! thats strange [19:04] mvo, https://docs.google.com/document/d/1WZqYRPNeXIsjgB68GyhMTHY3F5Jema2zEp850wbP9OQ/edit?usp=sharing [19:05] mvo, these are the results [19:12] cachio: thanks, I have a look in a bit or in my morning [19:13] sure, I'll try to reproduce it with a new vm [19:13] * zyga still works on unit tests and refactoring to make it easier [19:13] cachio: see if journald says anything about where gnome-software crashes if you can [19:14] zyga, dame info [19:14] than syslog [19:30] jdstrand: Do you have a moment for us to catch up today? [19:31] PR snapd#5438 closed: many: run all of main against core18 [19:32] niemeyer: yeah. note I responded to the 'can' PR [19:33] niemeyer: I think we'd want joc too since I not particularly familiar with 'can' [19:33] niemeyer: we kinda came up with the approach together [19:34] jdstrand: I had a good call with him today already [19:34] jdstrand: We can do a quick sync and follow up with him later [19:37] jdstrand: https://meet.google.com/tos-ipox-piw [19:37] ok, just a sec [19:41] dang it. darn webcam [19:57] zyga, well [19:58] I can reproduce the seg fault on a clean machine [19:58] but not need to update snapd [19:58] I installed artfull desktop [19:58] search for snapd [19:58] and that0s it [20:25] mvo, core snap 2.33.1 in stable channel [20:29] PR snapd#5444 opened: coreconfig: add support for `snap set core network.disable-ipv6` [20:29] cachio: yay, thank you [20:32] mvo, sru completed [20:33] the issue I found is not related to 2.33.1 [20:33] it is present in old snapd versions as well [20:37] PR snapd#5445 opened: tests: add artful for sru validation on google backend [20:38] PR snapd#5444 closed: coreconfig: add support for `snap set core network.disable-ipv6`