=== jamesh_ is now known as jamesh === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:03] good morning [06:23] Goooood morning! [06:36] I need to run an errand [06:36] Daughter forgot homework [06:36] Going to school === chihchun_afk is now known as chihchun [07:00] mornings [07:03] hey pstolowski [07:12] mvo, hey, is the 'connections' stance (gadget.yaml) supported in the current stable core? I'm trying https://paste.ubuntu.com/p/t5dsmHC8Yk/ but does not seem to do anything [07:15] abeato: let me look, I think it should be supported but let me double check [07:16] PR snapd#5899 closed: tests: shellchecks, final round [07:16] abeato: we added connections in 2.34 so this should work [07:17] mvo, ok, do you think there is something wrong in my yaml? [07:18] abeato: hm, this looks correct. what do you see? just nothing? [07:19] mvo, nothing [07:19] abeato: and the snapids are part of the seeding and all that? [07:19] abeato: show me log for snapd please [07:19] yes, all are in the seed [07:19] Typically this happens because the plug is removed by snapd [07:19] zyga, https://paste.ubuntu.com/p/JtmwzBpHy8/ [07:19] Hey everyone [07:19] hey zyga [07:20] Is that the complete log? [07:20] zyga, what I get when I do "snap install my-gadget" [07:20] Mmm [07:21] What is the interface that misbehaves? [07:21] PR snapd#5896 closed: snapcraft.yaml: set grade to stable [07:21] zyga, serial port [07:21] Hmmm [07:22] So you see it in “snap interfaces” [07:22] zyga: do you think #5909 needs a review from jamie? it looks so trivial [07:22] PR #5909: allow network_control to also use /sbin/iw [07:22] Probably not [07:23] [07:23] zyga, https://paste.ubuntu.com/p/HVWxNTPYJh/ [07:23] PR snapd#5909 closed: allow network_control to also use /sbin/iw [07:23] mvo: I fixed the release blocker for cosmic [07:23] abeato: are the snaps part of the seeding? do you have a "journalctl -u snapd" after the seeding and snap changes, snap change 2 [07:23] zyga: \o/ [07:23] mvo: we need a back port for the release branch [07:23] I will prepare one [07:24] zyga: amazing, is it in master already? [07:24] yes [07:26] mvo, zyga hm, found this: https://paste.ubuntu.com/p/TNdQSpZ8jp/ [07:26] 2018-10-03T16:38:36Z INFO gadget connect: ignoring missing slot THBWLoSEcoDOBe1W15W9uHxF8nadSiWn:ttymxc-0 [07:27] gadget ID vs gadget name? [07:27] feels like either: [07:27] the slot being removed by sanitize [07:27] or bug in id / name mapping [07:28] mvo: https://github.com/snapcore/snapd/pull/5914 [07:28] PR #5914: interfaces/apparmor: handle overlayfs snippet for snap-update-ns [07:29] mvo: I started working on a spread test for this last night [07:29] but it's a bit complex so I'm not done yet [07:29] zyga, now that I think about it, there is no actual assertion for the gadget, as when I built the image I used a local gadget snap, while the other are downloaded with the other corresponding assertions [07:29] abeato: aha [07:29] PR snapd#5914 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns [07:29] zyga, so I think I need to manually add an assertion for that to be able to test [07:29] I don't know if this applies but auto-connections are only done when installing with assertions [07:30] zyga, yeah, makes sense [07:30] zyga, mvo, thanks now I have enough directions on how to fix this [07:31] mvo: I tried to review and land things yesterday [07:31] zyga, can I use a gadget name instead of the ID? would that need an assertion? [07:31] abeato: I honestly don't know [07:31] I didn't write the auto-connection for gadget code [07:31] let me look [07:32] ok [07:32] abeato: we resolve snapd ID to snap name [07:33] abeato: I just realised that unless you have an assertion your snap will not have an ID [07:33] Can someone help me out with figuring otu why mir-kiosk + chromium-mir-kiosk won't work as described in https://tutorials.ubuntu.com/tutorial/ubuntu-web-kiosk#0 ? Running latest core stable on a pi3, mir-kiosk stable and chromium-mir-kiosk --beta. I also tried various candidate/edge combinations from earlier posts in https://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424/82 [07:34] dot-tobias: sorry, cannot spare the time for that now, perhaps ogra can help? [07:34] yeah, you need a snap-delcaration for that [07:35] abeato: one more possibility [07:35] abeato: look at your state.json [07:35] dot-tobias, whats exactly your problem ? [07:35] if there is an existing connection data with the undesired flag set [07:35] we won't auto-connect [07:36] alright, will check that [07:36] abeato: actually, scratch that [07:36] the error messages you pasted [07:36] they clearly indicate that the gadget doesn't have the given slot [07:36] can you paste the gadget's snap.yaml please? [07:36] ogra: The tutorial states that after installing the two snaps, I should see a fullscreen webpage. Which is not the case. Mir-kiosk's VT is set to 4 (default), but my tty4 just shows a black screen with a tiny rainbow box in the upper right corner. [07:37] dot-tobias, oh, wait, you said stable ... try with the edge image i think stable does not have all the bells and whistles for graphics support [07:37] abeato: but I think I also see a bug [07:37] mvo: when resolveSnapIDToName cannot find a snap declaration it returns ... "", nil [07:37] no error [07:37] dot-tobias, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ [07:38] ogra: Ok, you mean edge image for core or just mir-kiosk? [07:38] empty snap name [07:38] ogra: Gotcha 😊 [07:38] that feels buggy [07:38] o mean that image :) [07:38] zyga, https://paste.ubuntu.com/p/B43RYC3Y5w/ [07:38] s/o/i [07:38] pedronis: ^ AFAIK you wrote that, do you think this is desired? [07:38] zyga: not even a log message, that looks like we need to fix it [07:39] ogra: Does that image also support the Pi3B+ already, or do I need to fumble with the firmware files like with the stable Core image? (Just out of curiosity) [07:39] I'm 99% sure it's sanitisation discarding those slots [07:39] dot-tobias, ah, it might not, i'm working with sil2100 and ondra_ on getting the B+ to work this week [07:40] dot-tobias, we bumped the firmware on edge yesterday, but i'm not sure about the kernel yet [07:41] dot-tobias, though if stable worked for you with just updating the firmware, edge should be similar to what you did manually over there :) [07:41] abeato: can you show me all the changes again please [07:42] abeato: unfortunately both serial ports and leds would be allowed by the code in master so it's probably something else [07:42] zyga, https://paste.ubuntu.com/p/RwYtYnv6nc/ [07:43] ogra: Ok, thanks for the info. Maybe it'll still work 😄 B+ support for my project can wait a few weeks. Will test the kiosk stuff with a Pi3B in the meantime. Is there a forum topic / sth else to follow along with the B+ progress? [07:43] abeato: can you find THBWLoSEcoDOBe1W15W9uHxF8nadSiWn in snap declarations known to snapd on that device? [07:44] zyga, no, it is what I tould you above, this is happening because I built the image wiht a local gadget snap, no assertion [07:44] zyga: that's the it in that sentence? [07:45] pedronis: gadget auto-connect code, specifically the resolveSnapIDToName function [07:45] it doesn't return an error with the ID cannot be found [07:45] returns an empty string [07:45] caller doesn't check for that [07:45] I think it was designed like that [07:45] we just log don't error [07:46] saying the plug or slot doesn't exist [07:46] dot-tobias, https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 i'll update that thread once we know it works (my b+ only arrives on the weekend so the turnaround time in testing is a bit slow) [07:46] but what's the point of attempting to connect ":foo" ? [07:46] it's equivalent to "system:foo" [07:46] that's incorrect [07:46] zyga: ? [07:46] that is handled at a different level [07:46] I'm saying that it is more than logging, when resolve ... returns an empty string we carry on and attempt to find the slot [07:46] the slot _will_ resolve empty snap name to the system/core/snapd snap [07:47] ogra: Great, thank you very much! [07:47] so if you say "connect $gadget_id:foo" it effectively means, when the gadget assertion is missing, connect system:foo [07:47] I think that's unexpected [07:47] did we change some other code [07:47] and miss a test [07:47] specifically? [07:47] in repo [07:47] pedronis, when using a system user asertion from USB with the USB stick plugged in before first boot, it never creates a password, i have to re-plug the stick to make that happen (works fine if i dont forget to unplug the USB key and only plug it in later) [07:48] look at ifacestate's handlers.go:1118 [07:48] that just calls repo.Slot, that does auto-detection when slot snap name is empty [07:48] zyga: let me look at code [07:48] in this case it failed because the particular slot name was not something the core provides [07:48] but I think the semantics is undesired [07:49] we should treat err != nil and slotSnapName == "" equally [07:49] zyga: you are reapeting yourself [07:49] (same for the plug side) [07:49] * zyga stops [07:49] ogra: hm, we do have cold-plug code, hrm, hrm [07:49] let me look at ode [07:49] code [07:50] mvo, well, i pre-seed 5 snaps ... that puts the system under heavy load (takes about 20min for first boot (subsequent ones take 30sec)) ... might be related [07:50] though probably not ... given that it just works immediately when i re-plug ... even if the system is still seeding [07:52] * mvo nods [07:52] ogra: can you please check "journalctl -u snapd.autoimport.service" [07:52] zyga: repo.Slot/repo.Plug don't do that? unless we store core using "" as name there? [07:53] ah, you are correct, sorry about that [07:53] ResolveConnect does that [07:54] but plain Plug/Slot does not [07:54] I agree is a bit fragile, but Plug/Slot have been naive like that since forever [07:54] mvo, there we go ... i guess it iss the order of processing on first boot https://paste.ubuntu.com/p/DzZHMWq9pv/ [07:54] tbh I don't remember why I didn't write more explicit code [07:55] pedronis: I think in light of what you said this is correct [07:55] we should probably error explicitly earlier though, with a clearer error message [07:55] that is, when either of the resolve things fail [07:55] ogra: yeah, thats it [07:55] it's a different thing to say "snap foo has no slot bar" [07:55] zyga: that no, we decided not to fail [07:55] than "cannot find snap with ID ...." [07:55] mvo, here iss the manual re-plug https://paste.ubuntu.com/p/XvjzMNGYdz/ jut for refrernce [07:56] but only log [07:56] not fail as in abort [07:56] I'm just saying that the error message is confusing [07:56] that was an explicit discussion with gustavo [07:56] continue there is fine [07:56] you mean, make the snapid is wrong error explict [07:56] ogra: the manual replug worked? I ask because: "Oct 04 07:53:35 dashkiosk systemd-udevd[6850]: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 1." [07:57] mvo, well, i'm logged in enough to give you these logss ;) [07:57] ogra: heh [07:57] yep, something like this: [07:57] (timestamps are UTC btw) [07:57] https://www.irccloud.com/pastebin/giitgNDO/ [07:57] ogra: aha, I get it - this replug you did when you already had the system-usern, right? [07:57] pedronis: I agree that log + continue is better than error [07:58] ogra: I think I have an idea what to do about the coldplug case, I need to think a little bit more but I should have something actionable soon [07:58] mvo, well, it is a virgin boot ... but the key was plugged in during that [07:58] so yeah, parts might exist already [07:59] pedronis: perhaps the log could even become a warning to make device makers aware of possibly overlooked log message [07:59] oh geez ! [07:59] * ogra stomps foot [07:59] Oct 04 07:42:50 dashkiosk dashkiosk-client-browser.dashkiosk-browser[6400]: /snap/dashkiosk-client-browser/9/bin/desktop-launch: line 511: exec: /snap/dashkiosk-client-browser/9/bin/xwayland-dashkiosk-launch: cannot execute: Permission denied [08:00] how iu hate it when i forget to sset the exec bit for complex to build snaps [08:00] ARGHGH!!! [08:04] ogra: is that thing referenced by the yaml? [08:04] Chipaca, "thing" ? [08:05] ah [08:05] desktop-launch [08:05] drat [08:05] it is, yeah [08:05] ogra: if the yaml said 'run this thinig' directly, you'd get an error earlier [08:05] ideally at build, but we're not there yet [08:05] zyga: anyway I don't there is bug, we could improve the logged error (and maybe make the code less fragile if repo changes) [08:05] i re-wrote it from scratch and forgot to set the exec bit [08:06] pedronis: agreed [08:06] Chipaca, ogra@anubis:~/datengrab/appliances/dashkiosk-client-browser:master$ grep command snap/snapcraft.yaml [08:06] command: desktop-launch xwayland-dashkiosk-launch chromium.launcher [08:06] sadly it is only a wrapper in a wrapper [08:07] thats not anything snapcraft can catch [08:07] i could add a check to the build ... but if i had thought of that i would also have thought of setting +x ;) [08:11] mvo: mo'in [08:11] mvo: I was having trouble sleeping last night again, so I tried to bring your --format branch up to date [08:12] mvo: remember how I suggested to use the json names for things? [08:12] mvo: I was wrong, I think, unless we want to rewrite the template engine :-/ [08:13] hey Chipaca, thank you for the review last night :) [08:13] mvo: because now instead of {{.Name}} you can do {{.name}}, but instead of {{.InstallDate}} you need to do … {{ index . "install-date" }} [08:14] mvo: so, I was wrong, let's not do that [08:14] Chipaca: then it's a bit annoying though, we would need to document all the names again [08:15] mvo: also: the help needs i18n'ing, and putting it in the struct means we can't, so I was wrong about that as well [08:15] pedronis: this is user-facing documentation though [08:15] Chipaca: ? [08:15] pedronis: as opposed to developer-facing [08:16] pedronis: i mean, the only place we've documented (some of!) these names is in the API docs, which aren't user-facing [08:16] Chipaca: ah [08:16] ogra: re mir-kiosk & chromium: Works perfectly on edge image, thank you very much! [08:16] Chipaca: btw was this requested by somebody? (me doesnt remember) [08:16] pedronis: yep [08:17] low priority though [08:17] still fun [08:20] Chipaca: what do we do with Publisher? [08:22] pedronis: I was going to make the publisher you get in the template have two additional attributes (or methods), for long and short [08:22] right now, if you do {{.publisher}} you get e.g. "{canonical canonical Canonical verified}" or "{H5KLLP4UAnXs3naD386UN9B1IAW3aBZv chipaca John Lenton unproven}" [08:23] or ? [08:23] ah, sorry [08:23] two examples :) [08:23] * Chipaca pours pedronis another coffee [08:23] it's been a rough morning [08:24] Chipaca: but it would be Publisher now again? [08:24] yeah, probably [08:24] OTOH [08:24] Chipaca: mmh [08:25] another approach would be to have publisher being the above object, and separate ShortPublisher and LongPublisher for the pretty ones [08:25] or, just make publisher be short publisher [08:25] as long is only really for info [08:25] bur somebody might want to print the account id [08:25] yes [08:25] .publisher.AccountID ? [08:25] Chipaca: oh, nice, thanks for looking into all of this [08:25] .Publisher.AccountID [08:25] I could give publisher a String but still leave its things accessible [08:26] that should work [08:26] anyway lots of stuff to document [08:26] whoo yes [08:26] still, we're in no rush for it :) [08:26] still wonder the win vs --json or something [08:27] yeah, maybe the complications are not worth it, even though I really like it [08:27] I agree the biggest burden for us is in documenting everything [08:27] especially because it'll be ongoing [08:27] yes [08:29] giving it --json that printed either one object per line, or pretty-printed json-seq, would let people do this using jq [08:29] we could document that instead [08:33] simulate it with: http snapd:///v2/snaps | jq -c '.result | .[] ' [08:36] using it would look like: snap list --json | jq -r '.name + "\t" + .version' [08:37] which looks painful [08:37] or, | jq -r '"\(.name)\t\(.version)"' if you'd rather interpolate than build [08:37] a little [08:37] OTOH, it's json, go nuts :) [08:38] OTO²H, I fear all this might be a lot of work when introducing fields [08:38] that is, when introducing the fields argument to list et al, ie having the client choose fields [08:38] we'd either neet to understand the template well enough to know which fields to ask for, or ask for all [08:39] maybe the answer should be 'snap install http, and skip the middleman'? [08:39] Chipaca: we would need some support in client for a api passthrough [08:42] Chipaca: actually, I don't think I understood your last comment [08:42] pedronis: the one about 'snap install http'? [08:42] the one before [08:42] about the work to add a field [08:42] dot-tobias, good to hear, we'll make sure to have the dge stuff tested and released for early next week so you can switch to stable again [08:43] s/dge/edge/ [08:43] PR snapd#5914 closed: interfaces/apparmor: handle overlayfs snippet for snap-update-ns [08:44] pedronis: say 'snap list' only asks for the fields it is going to show [08:44] pedronis: but then we have 'snap list --format' [08:44] pedronis: so either we inspect the format and ask for those fields, or we ask for all the fields, or not all fields will show up [08:44] I like none of these options [08:44] Chipaca: ah [08:45] with --json we are forced to ask all fields [08:45] TBH for list it's not bad, but you know we'll be asked for 'snap find --format' next :) [08:45] yes [08:45] that's also why I'm not 100% sure we want to go down this path [08:45] the fourth alternative would be to have --fields [08:45] (which is slightly ew) [08:46] pedronis: yes, about --json. Which makes the "talk to the api" more attractive [08:46] there, of course you need to say fields :) [08:46] or you get the default set, for now [08:46] ogra: Great, looking forward to it! And thank you for the amazing work you're (all) doing. [08:46] Chipaca: anyway I'm sure we could argue that --format is only for list [08:47] if you want to play with find talk to the api [08:47] dot-tobias, well, thanks for using it ... the work wouldnt make sense without people like you ;) its a win-win ... [08:48] wgrant: the thing that maciej found yesterday about the store returning an error for a snap in context and not action, is there a store-side bug for it? [08:48] (I also don't want to help much more bash code come into the world :) ) [08:48] pedronis: to the store api, even :-D [08:48] Chipaca: https://bugs.launchpad.net/snapstore/+bug/1795841 [08:48] wgrant: cheers [08:49] Chipaca: there is, I created it [08:49] pedronis: what about zsh code [08:49] :-D [08:49] * Chipaca doesn't use zsh, but a lot of people are happy with it [08:49] fish code [08:50] anyway snap find --format is a slippery slope (so is snap info --format maybe) [08:50] in uni we wrote a shell we called dijsh, the dijkstra shell, which was different because it had 'goto' [08:50] pedronis: agreed [08:59] niemeyer: hey, what was your data processing tool again? the jq-inspired one? [09:05] Saviq: ymes [09:05] Saviq: snap instlal ymes [09:06] no [09:06] jmes [09:06] Saviq: ^ [09:12] * zyga breaks for errand [09:12] Saviq: bend [09:12] Saviq, Chipaca: jmes has a number of issues [09:13] Suggest not using it [09:14] ah [09:15] ppisati, shouldnt this be fix released ? https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1784025 (the toplevel status tricked me to belive it is still not in) [09:15] Bug #1784025: Support for the RaspberryPi 3 B Plus board

[09:16] (asuming 4.15 will "just work" anyway) [09:16] +s [09:23] sorry if you missed me: middle clicked with my palm (grr annoying) [09:30] bend! [09:30] thanks :) [09:31] PR snapd#5915 opened: allow calling netplan generate/apply after changing its config [09:31] niemeyer: is there a snap? [09:34] Saviq: No, not yet [09:40] ogra: yeah, it was fixed in xenial end of July / beginning of August [09:40] ogra: bionic had support for the rpi3b+ since its inception [09:41] ppisati, right, thats what i thought so it should be good to be fix-released [09:43] ogra: uhm, there's a script that does that, let me ask [09:43] ogra: the xenial side is marked as fix released [09:43] ogra: bot sure why the 'main' part is still confirmed [09:44] yeah, just not the toplevel one [09:44] prob is that in a bug search only the toplevel shows up [10:05] zyga: thanks for your layouts typo detection backoprt pr. one comment https://github.com/snapcore/snapd/pull/5911#discussion_r222581386 - I merge it now (writing here so that the comment won't get lost in the merge) [10:05] PR #5911: snap: detect layouts vs layout in snap.yaml (#5869) [10:06] PR snapd#5911 closed: snap: detect layouts vs layout in snap.yaml (#5869) [10:20] zyga, mvo fyi connections worked after providing assertions for the snap :) [10:27] That is great to know abeato [10:27] mvo: checking [10:28] mvo: we looked at that [10:28] It would require changing yaml package [10:28] We = Chipaca and me [10:32] zyga: aha, ok. thanks for this [10:32] abeato: yay [10:34] I think it is a good idea [10:34] Just needs more wor [10:41] PR snapd#5916 opened: data: run snapd.autoimport.service only after seeding [10:42] ogra: the auto-import issue you reported earlier should be fixed with this: -^ [10:42] yeah, just saw the mnail pop in here [11:11] re [11:25] mvo: zyga: it would actually require work in the unyamler of the containing struct [11:26] which is doable, but … this way is not super clean, but is ingenious in its simplicity [11:27] the other would feel a lot like spooky action at a distance [11:39] Chipaca: yeah [11:39] I'm happy I got away with one type :) [11:39] so overall, with the patch size, it's great value for diff :) === chihchun is now known as chihchun_afk [11:40] ok [11:40] back to overlayfs [11:44] is there anything more that needs to be done to get https://github.com/snapcore/snapd/pull/5271 merged? [11:44] PR #5271: cmd/snap: attempt to start the document portal if running with a session bus [11:45] good morning [11:45] should I file a bug so https://forum.snapcraft.io/t/unknown-syscall-when-running-an-18-04-built-snap/7094/9 would get fixed? (re: statx whitelisting in core18) [11:45] or is it already filled out? [11:45] I think it all the pending review comments have been addressed, and spread tests are passing [11:46] thresh: was that one about statx? [11:47] zyga looked at that [11:47] jamesh: hey [11:47] jamesh: looking [11:47] no, I think it is all good [11:47] zyga: thanks [11:47] 2.36 material? [11:47] Chipaca, yeah [11:47] jamesh: is it ready to be in the release today? [11:48] zyga: I think so. I think all the perf issues are addressed [11:48] mind if I squash-merge it? [11:48] whatever is easiest for you [11:48] cool, let me do that and prepare a back port then [11:49] zyga: do we want such a big thing in so close to release? [11:49]