[05:16] morning [06:49] mborzecki: I see two failures in your PR and in one of my PRs related to arch: snap-run (that tests strace) and interfaces-timezone-control start failing it seems, did anything in arch change? [06:49] mborzecki: this is very recent, probably started ~during the night [06:49] mvo: systemd got updated recently, that may affect timedatectl [06:50] mvo: systemctl --version [06:50] systemd 239 [06:51] mborzecki: chipacas pr fails in the same two tests, so does mine [06:51] mvo: i can look into it [06:51] timedatectl is probably something silly [06:51] run --strace may be more interesting [06:52] (although i used it yday and saw no issues) [06:52] mborzecki: ok I just started snap-run with --debug to get an idea [06:52] mborzecki: I bet with the next master merge we will see master failing as well [06:52] mvo: yup, most likely [06:59] /var/lib/snapd/snap/strace-static/current/bin/strace: Unexpected wait status 0x8b [06:59] error: exit status 1 [07:00] aah it's using strace from snap [07:00] mborzecki: how can I install the system strace? [07:00] mvo: pacman -S strace [07:00] mborzecki: its using the snap as a fallback [07:01] mborzecki: aha! that worked [07:01] mborzecki: so I will add strace to the default packages for arch [07:01] mborzecki: one problem down .) [07:01] mvo: yes, please do [07:01] mvo: do we need to rebuild strace-static snap maybe? [07:01] mborzecki: thanks for your help with this one? [07:01] mborzecki: s/?/!/ === pstolowski|afk is now known as pstolowski [07:01] mborzecki: good idea, let me have a look at strace-static [07:02] mvo: i'm looking into timedatectl [07:02] mborzecki: it should be pretty recent but probably not enough so [07:02] mborzecki: \o/ [07:02] mornings [07:02] pstolowski: good morning [07:02] mvo: the package one is 4.23 [07:02] pstolowski: hey [07:03] mborzecki: hm, arch seems to have the same version [07:03] mvo: i meant the arch package one is 4.23, the one from strace-static is 4.20 [07:06] mborzecki: aha, ok [07:06] PR snapd#5480 opened: tests: add strace to default arch packages [07:09] mvo: that timedatectl problem seems to be some sort of race [07:12] mborzecki: interessting, maybe they changed the dbus communication or something and now it returns before all changes are made [07:13] hm [07:17] mvo: https://paste.ubuntu.com/p/jpts966WWh/ [07:18] mvo: set-ntp behaves the same [07:20] mborzecki: hm, so racy and we just need to loop over the output for a bit? [07:20] mvo: yes, adding it now [07:20] ta [07:25] good morning [07:25] I think yesterday was the sweet spot of sleep/work cycle, I feel rested and not sleepy [07:25] mvo: I woke up earlier but I was busy with housework [07:26] mvo: we can have a call shortly [07:26] zyga: sounds good, I will make a cup of tea and then I'm ready [07:27] zyga: I had to add https://github.com/snapcore/snapd/pull/5478/commits/304e27a5b3735f34ebd6ac85fdb0be431c3a50a4 to fix unit tests [07:27] PR #5478: many: run core18 tests [07:27] aha! [07:27] zyga: without that firstboot test fails, but my PR now only fails in two arch tests that are unrelated (and are in the process of being fixed) [07:27] hi, i want to know is the ubuntu core 16 is 32 bit or 64 bit architecture. please help me [07:27] I removed it because pedronis asked if we could use the production id instead [07:28] newbee: we support 4 architectures [07:28] zyga: yeah, we can do that too, just needs some reworks in the firstboot test [07:28] newbee: x86, x86_64, armv7 and aarch64 [07:28] newbee: two of thoes are 32bit and the other two 64bit [07:28] mvo: ok, let's add that to the todo list [07:28] mvo: can snap-ids be forged easily? [07:29] zyga: yeah [07:29] zyga: in tests [07:29] zyga: in the real world I think not [07:30] ok, so when i install the ubuntu core on Raspberry pi 3 model B(ARMv8), getting the error for serial communication. [07:30] zyga: very exciting! the integration PR has only 3 failures all in non-core18 [07:30] * mvo goes and makes a cup of tea to celebrate [07:33] is there any version for ARMv8 ubuntu core for raspberry pi 3 Model B. I have downloaded the ubuntu core from https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 and installed on Raspberry pi 3 model B [07:34] newbee: no because that board doesn't support ARMv8 in practice, [07:35] newbee: that is, the hardware is there but last time I checked the required early-boot code that toggles to aarch64 is not publicly available [07:36] newbee: all raspberry pi boards are (still) running in ARMv7 (except for those with older CPUs that use even older v6 instruction set) [07:38] Ok thanks, i have checked in the ubuntu release, found that ubuntu core version is 16, is there any other version available ? [07:39] newbee: we are working on the 18 release [07:39] newbee: it should be available a little bit before ubuntu classic 18.10 [07:40] so we have to wait to work on 64 bit (ARMv8 - Raspberry pi), am i right please correct me. [07:41] newbee: raspberry pi aarch64 mode is entirely up to the pi foundation, we have no influence over any release dates [07:42] newbee: I suspect it is more of a design decision to keep the ecosystem simple and unified around a pair of architectures (armv6+armv7) rather than three [07:42] newbee: you can get other devices today that run in aarch64 mode [07:42] mvo: ready when you are [07:44] :-).. actullay we have installed and ran our app in Intel NUC as per you guys guidlines, now we are trying for raspberry pi, please suggest me can i try in raspberry pi 2 [07:47] PR snapd#5481 opened: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 [07:47] mvo: ^^ [07:47] mvo: one quirk, both PRs (yours and mine) will fail on their own :P [07:48] mvo: can you merge yours? it failed on google:arch-linux-64:tests/main/interfaces-timeserver-control as expected [07:50] mborzecki: sure, I can merge yours or you merge mine === chihchun_afk is now known as chihchun [08:00] newbee, you really dont want to run armv8 on a 1GB RAM board ... v8 binaries allocate twice the amount of RAM by default when running [08:00] mvo: merge yours, it alreay ran, i'll restart the build on mine then [08:01] PR snapd#5482 opened: tests: fix tests on arch [08:01] newbee, what are the benefits you expect of running v8 on a Pi ? will you do a lot of number-crunching and heavy math operations on it ? [08:02] mborzecki: snap :) [08:09] mvo: ta [08:10] PR snapd#5481 closed: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 [08:16] mvo: I can't push branches to ~snappy-dev, but the source code to test-snapd-eds is in the snapd tree [08:20] pedronis: hi, could you do a quick sanity check on https://github.com/snapcore/snapd/pull/5426 in case something non-obvious is missing? [08:20] PR #5426: client, cmd/snap: pass snap instance name when installing from file [08:27] pedronis: o/ [08:29] mborzecki: yes, I plan to do reviews today [08:29] Chipaca: hi [08:29] pedronis: great, thanks! [08:30] PR snapd#5482 closed: tests: fix tests on arch [08:30] pedronis: #5479 is the scope pr [08:30] PR #5479: store, daemon, client, cmd/snap: expose "scope", default to wide [08:31] Chipaca: ah, thanks, I missed it (somehow) [08:31] PR snapd#5480 closed: tests: add strace to default arch packages [08:31] pedronis: I should've gone with a more clickbaity title maybe [08:32] Chipaca: I think is more of a case of too many PRs [08:32] Chipaca: I labeled that 2.34 - is that correct? [08:32] mvo: I believe so [08:33] excellent [08:33] jamesh: thank you, I will take care of it then [08:36] mvo: we need to pick the test fixes for 2.34 [08:36] mborzecki: indeed, let me do that [08:37] Chipaca: afaict scope=wide is only about risk, not finding other archs? am I missing something [08:37] pedronis: ah i might've misunderstood [08:38] let me test [08:38] pedronis: you are correct [08:38] pedronis: i'll fix that [08:40] Chipaca: +1 with a couple of wonderings, also related to that [08:40] pedronis: I thought the argument was about risks and architecture (ie have it be a driving force towards stable + multi-arch), but I misunderstand things a lot [08:40] Chipaca: I always saw it called "find edge and beta in search" [08:41] k [08:41] maybe there's a general misunderstanding, not sure [08:41] hi - I'm currently struggeling to get software running that loads plugins from /usr/lib/x86_64/ - it claims that it cannot find the libraries - what exactly am I missing there? [08:41] architectures was about info i guess [08:41] Chipaca: worth poking roadmr when is around [08:41] Chipaca: yes, indeed some errors cannot refert to info because info doesn't do multi-arch [08:41] phako: try 'snap run --shell your.app' and look in *that* /usr/lib [08:42] well they are in the squashfs [08:42] but let me check [08:42] phako: maybe your LD_LIBRARY_PATH is wrong then [08:42] hm, they are indeed missing from the shell [08:42] odd [08:42] PR snapd#5483 opened: tests: fix arch tests (2.34) [08:42] phako: the squashfs isn't at / [08:42] ah! [08:43] phako: so if they're in the squashfs they'll be under $SNAP [08:43] phako: so your library path should have something like $SNAP/usr/lib/yadda [08:43] not sure that works, might be that gphoto is looking for hardcoded paths [08:44] sec [08:44] phako: might be that you need to build it from source to look at the other paths then :-) [08:44] bah. :) [08:45] phako: if it's regular dynamic libs, setting LD_LIBRARY_PATH should work [08:46] phako: if it's doing plugins and dlopening stuff, it might be looking in more than one place (maybe via XDG_* env vars) [08:46] figuring out the latter is a lot of fun [08:46] well for shotwell I'm pretty sure it looks in the hardcoded libdir (fixable) for gphoto I'd actually have to check the code [08:46] (in the early days we even submitted patches to, iirc, xkb so you could override where it looked for stuff) [08:47] anyhoo, good luck :) [08:47] thx [08:49] mborzecki: #5426 looks fine, the questions are more what we will do in api.go. just left a small comment [08:49] PR #5426: client, cmd/snap: pass snap instance name when installing from file [08:52] mvo: what's blocking #5422 ? [08:53] PR #5422: devicestate: fix race when refreshing a snap with snapd-control [08:53] pedronis: aha, I think this one is good now, iirc yesterdays tests were unhappy, let me squash-nmerge it (and cherry-pick) [08:54] Chipaca: hah - gphoto2 actually has an environment variable for that. cool [08:54] PR snapd#5422 closed: devicestate: fix race when refreshing a snap with snapd-control [08:56] phako: winning [08:56] Chipaca: probably worth linking to the PR from the topic [08:56] 5476 needs a second review, maybe Chipaca has some cycles for this? [08:57] hmm, google:arch-linux-64:tests/main/interfaces-timeserver-control and google:arch-linux-64:tests/main/snap-run have failed twice in a row [08:57] very few 2.34 milestoned PRs left :) [08:57] mborzecki: do you know anything about that ^? [08:57] Chipaca: yeah, we fixed it this morning [08:57] mvo: i'll take a look [08:57] Chipaca: just merge msater [08:57] mvo: w00t [08:57] master even [08:57] no, no, now i'm going to merge msater [08:57] too late to change it [08:57] lol [08:58] * mvo hugs Chipaca [08:58] * Chipaca hugs mvo back [09:00] btw, is udev workin inside a snap? [09:02] pstolowski: ^ one for you i think === matteo| is now known as matteo [09:14] phako: no === chihchun is now known as chihchun_afk [09:18] zyga: we have a green run on 5478! [09:22] mvo: looking [09:23] mvo: wait, so holidays now? :D [09:26] zyga: :-D [09:27] mvo: so I need to squash things for 2.34? [09:28] pstolowski: k, thanks [09:30] Chipaca: just if they have a gazillion of commits [09:30] Chipaca: if they are not a single commit anyway, yes, easier to back-port [09:30] Chipaca: if you do the cherry-picking and proposing I don't mind [09:30] Chipaca: I mean, its just convenient [09:43] PR snapd#5476 closed: snapstate: make sure all *link-*snap tasks carry a snap type and further hints [09:45] bbiab [09:46] PR snapd#5484 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints (2.34) [09:46] mvo: ok, I have it [09:46] mvo: I will push in a moment [09:47] mvo: anoteher backport ^ [09:47] pedronis: yay [09:47] pedronis: thank you [09:53] still waiting for 5197 to get green [09:54] mvo: ok, ready now [09:54] pushing to two PRs [09:57] man, something is wrong with my network in ubuntu :/ [10:01] mvo: I pushed https://github.com/snapcore/snapd/pull/5439/commits/ca539763589fc20536dea6180cb25292ec55431c [10:01] PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate [10:02] mvo: I also pushed https://github.com/zyga/snapd/commits/feature/core18-snapd-implicit [10:02] mvo: out of that the essence of what I told you about is: https://github.com/zyga/snapd/commit/09bf3fb17fbad8db32e2b3e2bcca2af74c451733 [10:03] mvo: the part that I said was missing in the test branch is now done as https://github.com/zyga/snapd/commit/5deb5e89be201f07b80d7d3d8e953156beaaa958 [10:04] zyga: cool, I check in a sec [10:04] and there are some follow up clenaups there [10:06] mvo: my suggestion is to take your integration branch, yank all my prior patches that are not in master and add just https://github.com/snapcore/snapd/pull/5485 [10:06] PR #5485: testing: support for interfaces on core18 [10:06] PR snapd#5485 opened: testing: support for interfaces on core18 [10:07] mvo: the only remaining thing I strongly know about is remaping of outgoing API responses [10:12] mvo: so what's next, what should I focus on? [10:12] mvo: I have some branches I can work on for interfaces [10:13] mvo: we could also talk to pedronis to explain the approach we took [10:15] zyga: yeah, I think the next step is to sync with gustavo and samuele to get advice [10:15] zyga: I merge/run your PRs now in the integration branch [10:22] thank you [10:23] mvo: you can keep the one patch I didn't include here, the one that does simple remapping in the client [10:23] mvo: or one of the tests will fail, but this is not that important [10:39] zyga: $ snap interfaces -i network now shows: "snapd:network network-consumer" before it was showing ":network" [10:39] this is what I meant above ^ [10:39] it was client-side remapping that was -1 by pedronis [10:39] zyga: aha, ok [10:40] the code there is a bit weird IMO as it does cliend side remapping anyway (for system) [10:40] when will the urandom fix land in edge (or did it already) ? [10:41] (working on my kiosk images firstboot on a pi3 takes around 8min til mir-kiosk and chromium are seeded ... i just noticed wiggling the mouse cuts that down to 5min so there is some chance the fix will help with slow arm firstboot too) [10:42] (talking about the snapd workaround obviously ... ) [10:42] mvo: you can try this: [10:42] use "nick" to perhaps understand parts of snapd snap https://www.irccloud.com/pastebin/qHO4nsvj/ [10:42] ogra_: our fix does unfortunately not help with the real seeding issue [10:42] zyga: can https://github.com/snapcore/snapd/pull/5433 be turned into +1? ;) i'm happy to discuss why it's needed [10:42] PR #5433: interfaces/repo: added AllHotplugInterfaces helper [10:43] pstolowski: let me look [10:43] ogra_: when seeding happens for real we need real randomness and that will block until the kernel is fixed - what version of the kernel do you use? [10:43] zyga: that was the part that was NACKed ? [10:44] mvo: no, I did an explicit abbreviation of both "core" and "snapd" in cmd_interface* [10:44] mvo, whatever is in edge, one sec ... [10:44] mvo: to be clear I didn't nack, I'm just generally confused why we do that in the client and not the api [10:44] mvo: the nick idea is IMO broken [10:44] mvo: if we want system we had a PR for that [10:44] mvo, pi2-kernel 4.4.0-1092.100 (56) [10:44] if we don't want system, what do we want? core or snapd? [10:44] mvo: this is related to the question about for how long we should re map the outgoing state [10:44] (not related to rollbacks) [10:44] mvo: it seems a hack that started with core vs ubuntu-core [10:44] that is when we should show users that it is really snapd that holds the slots [10:44] ogra_: did that kernel get the crng change? I thought that was 4.8+ only [10:45] and then it kept growing [10:45] but is a bit unclear it's the right place for it [10:45] it just keeps growing [10:45] pedronis: the iteration of remapping is going to re-map the outgoing API as well [10:45] pedronis, zyga yeah, I will update the test and we can think about a better way [10:45] pedronis: that's hte only remaining part [10:45] pedronis: I agree, I would rather remove the nick concept altogether but I'm not sure why we introduced it [10:45] pedronis: i'm gonna land #5426 [10:46] PR #5426: client, cmd/snap: pass snap instance name when installing from file [10:46] zyga: maybe we are not talking about the same thing [10:46] (me is a bit confused) [10:46] pedronis: I think you are referring to an earlier RFC patch where I was abbreviating "snapd" like we abbreviate "core" [10:46] pedronis: on the client side [10:46] mvo, i dont think the 4.4 kernel had any issue, my hope was the dropping of getrandom() in some places in snapd might help in general here... but if the actual seeding isnt involved in that thats indeed moot [10:46] pedronis: is that correct? [10:47] well, we want to do that [10:47] the question is where to achieve it [10:47] PR snapd#5459 closed: cmd/snap: add 'debug paths' command [10:47] abbreviation was always client side [10:47] mvo: #5455 can be landed too? [10:47] I think to answer the how part we need to decide what to do long term [10:47] PR #5455: many: assorted shellcheck fixes [10:47] will we pretend core has the slots? [10:47] (not in the state but in the user-visible places) [10:47] zyga: I think the hack as it was existed because of core vs ubuntu-core [10:48] the hack being the nick concept? [10:48] PR snapd#5426 closed: client, cmd/snap: pass snap instance name when installing from file [10:49] zyga: no the fact that in the client we check for core, then it became ubuntu-core, then system (not even sure why) and now snapd [10:49] this is getting out of hand === pstolowski is now known as pstolowski|lucnh === pstolowski|lucnh is now known as pstolowski|lunch [10:49] pedronis: I think this grew out of the desire to have explicit and non-magic API and a bit of magic in the CLI to make users life easier [10:50] if we abbreviate on the server then this is an API break [10:50] but the api now is kind of magic anyway [10:50] because you can use core even if it doesn't exist [10:50] no? [10:50] it's magic on the way in, but not out? [10:50] yes, but that is backwards compatible [10:51] I plan to make it magic on the way out, yes [10:51] my only real issue now is how long we keep the magic [10:51] and if we can kill the nick concept once we decide [10:51] for state we can keep the magic indefinitely really [10:52] I'm not sure if there is real value in keeping the magic in the API for too long [10:52] (and the state should drop the magic once we have epochs and a single snapd that doesn't roll back) [10:52] zyga: to be fair I'm also not sure why we have: || slot.Snap == snap.UseNick("core") ? [10:52] when does the api return system there? [10:53] I don't think we ever do that [10:53] it feels like dead code IMO [10:53] let me check [10:53] pedronis: the interface repo which answers that query never talks about "system" [10:54] so perhaps just symmetric but unused code [10:54] yes, something is off there [10:54] yes, agreed [10:54] I'm happy to clean it up once there is agreement on what to do exactly [10:54] my gut feeling is: [10:55] remap both sides completely for now [10:55] PR snapd#5197 closed: cmd/snap: display a link to data privacy notice for interactive snap login

[10:55] drop system nick idea (why do we have it if this is the only instance of the "system" term in the whole interfaces and we explicitly chose not to do a "system" snap that holds slots) [10:55] once epochs land migrate the state [10:55] once we feel like it stop talking about core as host in the API and start to refuse "connect foo:network core:network" [10:56] that's my rough idea that is least disruptive and most consistent [10:56] PR snapd#5440 closed: snapstate: allow setting "refresh.timer=managed" [10:56] zyga: well, we have it for symmetry with the use in gadget defaults [10:57] also now connections accepts it too [10:57] interesting [10:57] hmm [10:57] well, maybe that should say snapd instead? [10:57] I mean, it's half half now [10:57] it's even the only spelling [10:57] not all the way in [10:57] well, we decided not to use snapd [10:57] for defaults [10:57] it was an explicit decision [10:58] system was to be used there (among other things iirc) [10:58] zyga: the issue is essentially core, snapd in the end are implemetnation details [10:58] if we keep exposing them, we keep needing to migrate people away [10:59] pedronis: this feels like a one way mapping though, people ask for system, get snapd [11:00] pedronis: it is also odd that you see system as a snap name [11:00] but it's not installed, has no info, etc [11:00] it feels okay if this is an "alias" of some sort [11:00] well, it's odd that system plugs are on a snap or another [11:00] lots of things are odd [11:00] perhaps but at least it is a real snap you can see [11:01] it really doesn't matter which as long as we are clear about the semantics, my point is that right now we are not clear because it's sometimes system, sometimes core [11:01] and with the introduction of snapd it's a growing complexity problem [11:01] the api talks about "core" [11:01] the users see "system" [11:02] remember as well that we planned to deprecate that api/comamnd [11:02] wasn't pawel working on something else called connections? [11:02] this is not just here, it's also visible in the new api [11:02]