[06:03] <zyga> good morning
[06:23] <Faults> Goooood morning!
[06:36] <zyga> I need to run an errand
[06:36] <zyga> Daughter forgot homework
[06:36] <zyga> Going to school
[07:00] <pstolowski> mornings
[07:03] <mvo> hey pstolowski
[07:12] <abeato> 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] <mvo> abeato: let me look, I think it should be supported but let me double check
[07:16] <mup> PR snapd#5899 closed: tests: shellchecks, final round <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5899>
[07:16] <mvo> abeato: we added connections in 2.34 so this should work
[07:17] <abeato> mvo, ok, do you think there is something wrong in my yaml?
[07:18] <mvo> abeato: hm, this looks correct. what do you see? just nothing?
[07:19] <abeato> mvo, nothing
[07:19] <mvo> abeato: and the snapids are part of the seeding and all that?
[07:19] <zyga> abeato: show me log for snapd please
[07:19] <abeato> yes, all are in the seed
[07:19] <zyga> Typically this happens because the plug is removed by snapd
[07:19] <abeato> zyga, https://paste.ubuntu.com/p/JtmwzBpHy8/
[07:19] <zyga> Hey everyone
[07:19] <mvo> hey zyga
[07:20] <zyga> Is that the complete log?
[07:20] <abeato> zyga, what I get when I do "snap install my-gadget"
[07:20] <zyga> Mmm
[07:21] <zyga> What is the interface that misbehaves?
[07:21] <mup> PR snapd#5896 closed: snapcraft.yaml: set grade to stable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5896>
[07:21] <abeato> zyga, serial port
[07:21] <zyga> Hmmm
[07:22] <zyga> So you see it in “snap interfaces”
[07:22] <mvo> zyga: do you think #5909 needs a review from jamie? it looks so trivial
[07:22] <mup> PR #5909: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
[07:22] <zyga> Probably not
[07:23] <zyga>  
[07:23] <abeato> zyga, https://paste.ubuntu.com/p/HVWxNTPYJh/
[07:23] <mup> PR snapd#5909 closed: allow network_control to also use /sbin/iw <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5909>
[07:23] <zyga> mvo: I fixed the release blocker for cosmic
[07:23] <mvo> 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] <mvo> zyga: \o/
[07:23] <zyga> mvo: we need a back port for the release branch
[07:23] <zyga> I will prepare one
[07:24] <mvo> zyga: amazing, is it in master already?
[07:24] <zyga> yes
[07:26] <abeato> mvo, zyga hm, found this: https://paste.ubuntu.com/p/TNdQSpZ8jp/
[07:26] <zyga> 2018-10-03T16:38:36Z INFO gadget connect: ignoring missing slot THBWLoSEcoDOBe1W15W9uHxF8nadSiWn:ttymxc-0
[07:27] <zyga> gadget ID vs gadget name?
[07:27] <zyga> feels like either:
[07:27] <zyga> the slot being removed by sanitize
[07:27] <zyga> or bug in id / name mapping
[07:28] <zyga> mvo: https://github.com/snapcore/snapd/pull/5914
[07:28] <mup> PR #5914: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5914>
[07:29] <zyga> mvo: I started working on a spread test for this last night
[07:29] <zyga> but it's a bit complex so I'm not done yet
[07:29] <abeato> 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] <zyga> abeato: aha
[07:29] <mup> PR snapd#5914 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5914>
[07:29] <abeato> zyga, so I think I need to manually add an assertion for that to be able to test
[07:29] <zyga> I don't know if this applies but auto-connections are only done when installing with assertions
[07:30] <abeato> zyga, yeah, makes sense
[07:30] <abeato> zyga, mvo, thanks now I have enough directions on how to fix this
[07:31] <zyga> mvo: I tried to review and land things yesterday
[07:31] <abeato> zyga, can I use a gadget name instead of the ID? would that need an assertion?
[07:31] <zyga> abeato: I honestly don't know
[07:31] <zyga> I didn't write the auto-connection for gadget code
[07:31] <zyga> let me look
[07:32] <abeato> ok
[07:32] <zyga> abeato: we resolve snapd ID to snap name
[07:33] <zyga> abeato: I just realised that unless you have an assertion your snap will not have an ID
[07:33] <dot-tobias> 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] <zyga> dot-tobias: sorry, cannot spare the time for that now, perhaps ogra can help?
[07:34] <abeato> yeah, you need a snap-delcaration for that
[07:35] <zyga> abeato: one more possibility
[07:35] <zyga> abeato: look at your state.json
[07:35] <ogra> dot-tobias, whats exactly your problem ?
[07:35] <zyga> if there is an existing connection data with the undesired flag set
[07:35] <zyga> we won't auto-connect
[07:36] <abeato> alright, will check that
[07:36] <zyga> abeato: actually, scratch that
[07:36] <zyga> the error messages you pasted
[07:36] <zyga> they clearly indicate that the gadget doesn't have the given slot
[07:36] <zyga> can you paste the gadget's snap.yaml please?
[07:36] <dot-tobias> 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] <ogra> 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] <zyga> abeato: but I think I also see a bug
[07:37] <zyga> mvo: when resolveSnapIDToName cannot find a snap declaration it returns ... "", nil
[07:37] <zyga> no error
[07:37] <ogra> dot-tobias, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
[07:38] <dot-tobias> ogra: Ok, you mean edge image for core or just mir-kiosk?
[07:38] <zyga> empty snap name
[07:38] <dot-tobias> ogra: Gotcha 😊
[07:38] <zyga> that feels buggy
[07:38] <ogra> o mean that image :)
[07:38] <abeato> zyga, https://paste.ubuntu.com/p/B43RYC3Y5w/
[07:38] <ogra> s/o/i
[07:38] <zyga> pedronis: ^ AFAIK you wrote that, do you think this is desired?
[07:38] <mvo> zyga: not even a log message, that looks like we need to fix it
[07:39] <dot-tobias> 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] <zyga> I'm 99% sure it's sanitisation discarding those slots
[07:39] <ogra> dot-tobias, ah, it might not, i'm working with sil2100 and ondra_ on getting the B+ to work this week
[07:40] <ogra> dot-tobias, we bumped the firmware on edge yesterday, but i'm not sure about the kernel yet
[07:41] <ogra> 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] <zyga> abeato: can you show me all the changes again please
[07:42] <zyga> abeato: unfortunately both serial ports and leds would be allowed by the code in master so it's probably something else
[07:42] <abeato> zyga, https://paste.ubuntu.com/p/RwYtYnv6nc/
[07:43] <dot-tobias> 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] <zyga> abeato: can you find THBWLoSEcoDOBe1W15W9uHxF8nadSiWn in snap declarations known to snapd on that device?
[07:44] <abeato> 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] <pedronis> zyga: that's the it in that sentence?
[07:45] <zyga> pedronis: gadget auto-connect code, specifically the resolveSnapIDToName function
[07:45] <zyga> it doesn't return an error with the ID cannot be found
[07:45] <zyga> returns an empty string
[07:45] <zyga> caller doesn't check for that
[07:45] <pedronis> I think it was designed like that
[07:45] <pedronis> we just log don't error
[07:46] <pedronis> saying the plug or slot doesn't exist
[07:46] <ogra> 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] <zyga> but what's the point of attempting to connect ":foo" ?
[07:46] <zyga> it's equivalent to "system:foo"
[07:46] <zyga> that's incorrect
[07:46] <pedronis> zyga: ?
[07:46] <pedronis> that is handled at a different level
[07:46] <zyga> 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] <zyga> the slot _will_ resolve empty snap name to the system/core/snapd snap
[07:47] <dot-tobias> ogra: Great, thank you very much!
[07:47] <zyga> so if you say "connect $gadget_id:foo" it effectively means, when the gadget assertion is missing, connect system:foo
[07:47] <zyga> I think that's unexpected
[07:47] <pedronis> did we change some other code
[07:47] <pedronis> and miss a test
[07:47] <zyga> specifically?
[07:47] <pedronis> in repo
[07:47] <ogra> 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] <zyga> look at ifacestate's handlers.go:1118
[07:48] <zyga> that just calls repo.Slot, that does auto-detection when slot snap name is empty
[07:48] <pedronis> zyga: let me look at code
[07:48] <zyga> in this case it failed because the particular slot name was not something the core provides
[07:48] <zyga> but I think the semantics is undesired
[07:49] <zyga> we should treat err != nil and slotSnapName == "" equally
[07:49] <pedronis> zyga: you are reapeting yourself
[07:49] <zyga> (same for the plug side)
[07:49]  * zyga stops
[07:49] <mvo> ogra: hm, we do have cold-plug code, hrm, hrm
[07:49] <pedronis> let  me look at ode
[07:49] <pedronis> code
[07:50] <ogra> 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] <ogra> 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] <mvo> ogra: can you please check "journalctl -u snapd.autoimport.service"
[07:52] <pedronis> zyga: repo.Slot/repo.Plug don't do that? unless we store core using "" as name there?
[07:53] <zyga> ah, you are correct, sorry about that
[07:53] <zyga> ResolveConnect does that
[07:54] <zyga> but plain Plug/Slot does not
[07:54] <pedronis> I agree is a bit fragile, but Plug/Slot have been naive like that since forever
[07:54] <ogra> mvo, there we go ... i guess it iss the order of processing on first boot https://paste.ubuntu.com/p/DzZHMWq9pv/
[07:54] <pedronis> tbh I don't remember why I didn't write more explicit code
[07:55] <zyga> pedronis: I think in light of what you said this is correct
[07:55] <zyga> we should probably error explicitly earlier though, with a clearer error message
[07:55] <zyga> that is, when either of the resolve things fail
[07:55] <mvo> ogra: yeah, thats it
[07:55] <zyga> it's a different thing to say "snap foo has no slot bar"
[07:55] <pedronis> zyga: that no, we decided not to fail
[07:55] <zyga> than "cannot find snap with ID ...."
[07:55] <ogra> mvo, here iss the manual re-plug https://paste.ubuntu.com/p/XvjzMNGYdz/ jut for refrernce
[07:56] <pedronis> but only log
[07:56] <zyga> not fail as in abort
[07:56] <zyga> I'm just saying that the error message is confusing
[07:56] <pedronis> that was an explicit discussion with gustavo
[07:56] <zyga> continue there is fine
[07:56] <pedronis> you mean, make the snapid is wrong error explict
[07:56] <mvo> 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] <ogra> mvo, well, i'm logged in enough to give you these logss ;)
[07:57] <mvo> ogra: heh
[07:57] <zyga> yep, something like this:
[07:57] <ogra> (timestamps are UTC btw)
[07:57] <zyga> https://www.irccloud.com/pastebin/giitgNDO/
[07:57] <mvo> ogra: aha, I get it - this replug you did when you already had the system-usern, right?
[07:57] <zyga> pedronis: I agree that log + continue is better than error
[07:58] <mvo> 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] <ogra> mvo, well, it is a virgin boot ... but the key was plugged in during that
[07:58] <ogra> so yeah, parts might exist already
[07:59] <zyga> pedronis: perhaps the log could even become a warning to make device makers aware of possibly overlooked log message
[07:59] <ogra> oh geez !
[07:59]  * ogra stomps foot
[07:59] <ogra> 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] <ogra> how iu hate it when i forget to sset the exec bit for complex to build snaps
[08:00] <ogra> ARGHGH!!!
[08:04] <Chipaca> ogra: is that thing referenced by the yaml?
[08:04] <ogra> Chipaca, "thing" ?
[08:05] <Chipaca> ah
[08:05] <Chipaca> desktop-launch
[08:05] <Chipaca> drat
[08:05] <ogra> it is, yeah
[08:05] <Chipaca> ogra: if the yaml said 'run this thinig' directly, you'd get an error earlier
[08:05] <Chipaca> ideally at build, but we're not there yet
[08:05] <pedronis> 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] <ogra> i re-wrote it from scratch and forgot to set the exec bit
[08:06] <zyga> pedronis: agreed
[08:06] <ogra> Chipaca, ogra@anubis:~/datengrab/appliances/dashkiosk-client-browser:master$ grep command snap/snapcraft.yaml
[08:06] <ogra>     command: desktop-launch xwayland-dashkiosk-launch chromium.launcher
[08:06] <ogra> sadly it is only a wrapper in a wrapper
[08:07] <ogra> thats not anything snapcraft can catch
[08:07] <ogra> 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] <Chipaca> mvo: mo'in
[08:11] <Chipaca> mvo: I was having trouble sleeping last night again, so I tried to bring your --format branch up to date
[08:12] <Chipaca> mvo: remember how I suggested to use the json names for things?
[08:12] <Chipaca> mvo: I was wrong, I think, unless we want to rewrite the template engine :-/
[08:13] <zyga> hey Chipaca, thank you for the review last night :)
[08:13] <Chipaca> mvo: because now instead of {{.Name}} you can do {{.name}}, but instead of {{.InstallDate}} you need  to do … {{ index . "install-date" }}
[08:14] <Chipaca> mvo: so, I was wrong, let's not do that
[08:14] <pedronis> Chipaca: then it's a bit annoying though, we would need to document all the names again
[08:15] <Chipaca> 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] <Chipaca> pedronis: this is user-facing documentation though
[08:15] <pedronis> Chipaca: ?
[08:15] <Chipaca> pedronis: as opposed to developer-facing
[08:16] <Chipaca> 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] <pedronis> Chipaca: ah
[08:16] <dot-tobias> ogra: re mir-kiosk & chromium: Works perfectly on edge image, thank you very much!
[08:16] <pedronis> Chipaca: btw was this requested by somebody? (me doesnt remember)
[08:16] <Chipaca> pedronis: yep
[08:17] <Chipaca> low priority though
[08:17] <Chipaca> still fun
[08:20] <pedronis> Chipaca: what do we do with Publisher?
[08:22] <Chipaca> 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] <Chipaca> right now, if you do {{.publisher}} you get e.g. "{canonical canonical Canonical verified}" or "{H5KLLP4UAnXs3naD386UN9B1IAW3aBZv chipaca John Lenton unproven}"
[08:23] <pedronis> or ?
[08:23] <pedronis> ah, sorry
[08:23] <Chipaca> two examples :)
[08:23]  * Chipaca pours pedronis another coffee
[08:23] <pedronis> it's been a rough morning
[08:24] <pedronis> Chipaca: but it would be Publisher now again?
[08:24] <Chipaca> yeah, probably
[08:24] <Chipaca> OTOH
[08:24] <pedronis> Chipaca: mmh
[08:25] <Chipaca> another approach would be to have publisher being the above object, and separate ShortPublisher and LongPublisher for the pretty ones
[08:25] <Chipaca> or, just make publisher be short publisher
[08:25] <Chipaca> as long is only really for info
[08:25] <pedronis> bur somebody might want to print the account id
[08:25] <Chipaca> yes
[08:25] <pedronis> .publisher.AccountID ?
[08:25] <mvo> Chipaca: oh, nice, thanks for looking into all of this
[08:25] <pedronis> .Publisher.AccountID
[08:25] <Chipaca> I could give publisher a String but still leave its things accessible
[08:26] <Chipaca> that should work
[08:26] <pedronis> anyway lots of stuff to document
[08:26] <Chipaca> whoo yes
[08:26] <Chipaca> still, we're in no rush for it :)
[08:26] <pedronis> still wonder the win vs --json or something
[08:27] <mvo> yeah, maybe the complications are not worth it, even though I really like it
[08:27] <Chipaca> I agree the biggest burden for us is in documenting everything
[08:27] <Chipaca> especially because it'll be ongoing
[08:27] <pedronis> yes
[08:29] <Chipaca> giving it --json that printed either one object per line, or pretty-printed json-seq, would let people do this using jq
[08:29] <Chipaca> we could document that instead
[08:33] <Chipaca> simulate it with: http snapd:///v2/snaps | jq -c '.result | .[] '
[08:36] <Chipaca> using it would look like: snap list --json | jq -r '.name + "\t" + .version'
[08:37] <pedronis> which looks painful
[08:37] <Chipaca> or, | jq -r '"\(.name)\t\(.version)"'  if you'd rather interpolate than build
[08:37] <Chipaca> a little
[08:37] <Chipaca> OTOH, it's json, go nuts :)
[08:38] <Chipaca> OTO²H, I fear all this might be a lot of work when introducing fields
[08:38] <Chipaca> that is, when introducing the fields argument to list et al, ie having the client choose fields
[08:38] <Chipaca> we'd either neet to understand the template well enough to know which fields to ask for, or ask for all
[08:39] <Chipaca> maybe the answer should be 'snap install http, and skip the middleman'?
[08:39] <pedronis> Chipaca: we would need some support in client for a api passthrough
[08:42] <pedronis> Chipaca: actually, I don't think I understood your last comment
[08:42] <Chipaca> pedronis: the one about 'snap install http'?
[08:42] <pedronis> the one before
[08:42] <pedronis> about the work to add a field
[08:42] <ogra> 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] <ogra> s/dge/edge/
[08:43] <mup> PR snapd#5914 closed: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5914>
[08:44] <Chipaca> pedronis: say 'snap list' only asks for the fields it is going to show
[08:44] <Chipaca> pedronis: but then we have 'snap list --format'
[08:44] <Chipaca> 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] <Chipaca> I like none of these options
[08:44] <pedronis> Chipaca: ah
[08:45] <pedronis> with --json we are forced to ask all fields
[08:45] <Chipaca> TBH for list it's not bad, but you know we'll be asked for 'snap find --format' next :)
[08:45] <pedronis> yes
[08:45] <pedronis> that's also why I'm not 100% sure we want to go down this path
[08:45] <Chipaca> the fourth alternative would be to have --fields
[08:45] <Chipaca> (which is slightly ew)
[08:46] <Chipaca> pedronis: yes, about --json. Which makes the "talk to the api" more attractive
[08:46] <Chipaca> there, of course you need to say fields :)
[08:46] <Chipaca> or you get the default set, for now
[08:46] <dot-tobias> ogra: Great, looking forward to it! And thank you for the amazing work you're (all) doing.
[08:46] <pedronis> Chipaca: anyway I'm sure we could argue that --format is only for list
[08:47] <pedronis> if you want to play with find talk to the api
[08:47] <ogra> dot-tobias, well, thanks for using it ... the work wouldnt make  sense without people like you ;) its a win-win ...
[08:48] <Chipaca> 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] <pedronis> (I also don't want to help much more bash code come into the world :) )
[08:48] <Chipaca> pedronis: to the store api, even :-D
[08:48] <wgrant> Chipaca: https://bugs.launchpad.net/snapstore/+bug/1795841
[08:48] <Chipaca> wgrant: cheers
[08:49] <pedronis> Chipaca: there is, I created it
[08:49] <Chipaca> pedronis: what about zsh code
[08:49] <Chipaca> :-D
[08:49]  * Chipaca doesn't use zsh, but a lot of people are happy with it
[08:49] <pedronis> fish code
[08:50] <pedronis> anyway snap find --format is a slippery slope (so is snap info --format maybe)
[08:50] <Chipaca> in uni we wrote a shell we called dijsh, the dijkstra shell, which was different because it had 'goto'
[08:50] <Chipaca> pedronis: agreed
[08:59] <Saviq> niemeyer: hey, what was your data processing tool again? the jq-inspired one?
[09:05] <Chipaca> Saviq: ymes
[09:05] <Chipaca> Saviq: snap instlal ymes
[09:06] <Chipaca> no
[09:06] <Chipaca> jmes
[09:06] <Chipaca> Saviq: ^
[09:12]  * zyga breaks for errand
[09:12] <niemeyer> Saviq: bend
[09:12] <niemeyer> Saviq, Chipaca: jmes has a number of issues
[09:13] <niemeyer> Suggest not using it
[09:14] <Chipaca> ah
[09:15] <ogra> 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] <mup> Bug #1784025: Support for the RaspberryPi 3 B Plus board <linux-raspi2 (Ubuntu):Confirmed> <linux-raspi2 (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1784025>
[09:16] <ogra> (asuming 4.15 will "just work" anyway)
[09:16] <ogra> +s
[09:23] <Chipaca> sorry if you missed me: middle clicked with my palm (grr annoying)
[09:30] <Saviq> bend!
[09:30] <Saviq> thanks :)
[09:31] <mup> PR snapd#5915 opened: allow calling netplan generate/apply after changing its config <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915>
[09:31] <Saviq> niemeyer: is there a snap?
[09:34] <niemeyer> Saviq: No, not yet
[09:40] <ppisati> ogra: yeah, it was fixed in xenial end of July / beginning of August
[09:40] <ppisati> ogra: bionic had support for the rpi3b+ since its inception
[09:41] <ogra> ppisati, right, thats what i thought so it should be good to be fix-released
[09:43] <ppisati> ogra: uhm, there's a script that does that, let me ask
[09:43] <ppisati> ogra: the xenial side is marked as fix released
[09:43] <ppisati> ogra: bot sure why the 'main' part is still confirmed
[09:44] <ogra> yeah, just not the toplevel one
[09:44] <ogra> prob is that in a bug search only the toplevel shows up
[10:05] <mvo> 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] <mup> PR #5911: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <https://github.com/snapcore/snapd/pull/5911>
[10:06] <mup> PR snapd#5911 closed: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5911>
[10:20] <abeato> zyga, mvo fyi connections worked after providing assertions for the snap :)
[10:27] <zyga> That is great to know abeato
[10:27] <zyga> mvo: checking
[10:28] <zyga> mvo: we looked at that
[10:28] <zyga> It would require changing yaml package
[10:28] <zyga> We = Chipaca and me
[10:32] <mvo> zyga: aha, ok. thanks for this
[10:32] <mvo> abeato: yay
[10:34] <zyga> I think it is a good idea
[10:34] <zyga> Just needs more wor
[10:41] <mup> PR snapd#5916 opened: data: run snapd.autoimport.service only after seeding <Created by mvo5> <https://github.com/snapcore/snapd/pull/5916>
[10:42] <mvo> ogra: the auto-import issue you reported earlier should be fixed with this: -^
[10:42] <ogra> yeah, just saw the mnail pop in here
[11:11] <zyga> re
[11:25] <Chipaca> mvo: zyga: it would actually require work in the unyamler of the containing struct
[11:26] <Chipaca> which is doable, but … this way is not super clean, but is ingenious in its simplicity
[11:27] <Chipaca> the other would feel a lot like spooky action at a distance
[11:39] <zyga> Chipaca: yeah
[11:39] <zyga> I'm happy I got away with one type :)
[11:39] <zyga> so overall, with the patch size, it's great value for diff :)
[11:40] <zyga> ok
[11:40] <zyga> back to overlayfs
[11:44] <jamesh> is there anything more that needs to be done to get https://github.com/snapcore/snapd/pull/5271 merged?
[11:44] <mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
[11:45] <thresh> good morning
[11:45] <thresh> 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] <thresh> or is it already filled out?
[11:45] <jamesh> I think it all the pending review comments have been addressed, and spread tests are passing
[11:46] <Chipaca> thresh: was that one about statx?
[11:47] <Chipaca> zyga looked at that
[11:47] <zyga> jamesh: hey
[11:47] <zyga> jamesh: looking
[11:47] <zyga> no, I think it is all good
[11:47] <jamesh> zyga: thanks
[11:47] <zyga> 2.36 material?
[11:47] <thresh> Chipaca, yeah
[11:47] <zyga> jamesh: is it ready to be in the release today?
[11:48] <jamesh> zyga: I think so.  I think all the perf issues are addressed
[11:48] <zyga> mind if I squash-merge it?
[11:48] <jamesh> whatever is easiest for you
[11:48] <zyga> cool, let me do that and prepare a back port then
[11:49] <Chipaca> zyga: do we want such a big thing in so close to release?
[11:49] <zyga> this is a question for mvo in the release branch
[11:49] <Chipaca> ah, true
[11:49] <Chipaca> ok
[11:50] <zyga> jamesh: btw, Gustavo asked about "portals-missing"
[11:50] <Chipaca> zyga: after that, could you update thresh on the statx thing?
[11:50] <zyga> ah, sorry
[11:50] <zyga> I misread the statement in the PR
[11:50] <zyga> LGTM
[11:50] <zyga> Chipaca: yes
[11:50] <jamesh> niemeyer added the 2.36 milestone to the PR, so presumably he's okay with it
[11:51] <Chipaca> AFAIR it was something like: qt said no to a patch, seccomp said the same, so we're SOL?
[11:51] <Chipaca> i might've misunderstood though
[11:51] <mup> PR snapd#5271 closed: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5271>
[11:51] <zyga> thresh: no update on our side but Qt has agreed to remove statx from qt itself until glibc supports it explicitly, then it should be only used when more recent seccomp is used
[11:51] <thresh> oh that's nice
[11:51] <zyga> thresh: there are plans to improve the situation for older systems but it's not really ready yet
[11:51] <zyga> thresh: in the meantime we will add statx to our profiles and, if you have recent seccomp, it will be allowed
[11:52] <zyga> the plan is to use snap-seccomp from core as a low-tech solution
[11:52] <zyga> and eventually transition, perhaps, to in-house profiles
[11:52] <zyga> but that's not the immediate future
[11:53] <thresh> zyga, and by "qt agreed" you mean ubuntu packaging or upstream qt?
[11:53] <zyga> upstream qt
[11:54] <thresh> thakns!
[11:54] <thresh> err thanks!
[11:54] <Chipaca> zyga: they said no to a patch, but agreed to fix it?
[11:55] <Chipaca> or did i get that bass-ackwards?
[11:55] <zyga> Chipaca: they said no to a small patch but agreed to postpone using the feature until glibc ships it
[11:55] <zyga> then presumably seccomp is fixee
[11:55] <Chipaca> ah
[11:55] <Chipaca> so what does thresh do?
[11:55] <zyga> not sure
[11:57] <mup> PR snapd#5917 opened: cmd/snap: attempt to start the document portal if running with a sess… <Created by zyga> <https://github.com/snapcore/snapd/pull/5917>
[11:57] <zyga> jamesh: backport pushed
[11:59] <zyga> mvo: when do you plan to make the next point release? today?
[12:03] <thresh> I think glibc 2.28 added statx
[12:04] <thresh> I'm going to poke KDE Neon folks to remove statx support from their Qt build meanwhile since that's the one I'm using
[12:04] <zyga> and, perhaps by coincidence, we can support statx there
[12:04] <thresh> thank you for the update, much appreciated!
[12:05] <zyga> thresh: sorry it's not perfect, I'll propose the change to enable statx in cosmic
[12:05] <thresh> np no software is perfect zyga
[12:05] <Chipaca> except ed
[12:05] <thresh> no grave bugs with 16.04-based snap yet, too, so it's R&D more or less
[12:14] <zyga> thresh: https://github.com/snapcore/snapd/pull/5918
[12:14] <mup> PR #5918: many: allow using statx by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5918>
[12:14] <mup> PR snapd#5918 opened: many: allow using statx by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5918>
[12:14] <zyga> mvo: ^ I marked this as 2.36 candidate
[12:14] <zyga> mvo: we don't have google support for cosmic yet, right?
[12:14] <zyga> mvo: only qemu/autopkgtest?
[12:18] <Chipaca> zyga: looks like it
[12:19] <Chipaca> zyga: but I think we use the standard images? maybe just adding the stanza works :-)
[12:19] <Chipaca> cachio would know better though
[12:19] <zyga> mmm, perhaps
[12:19] <zyga> I'll double check with qemu image and chat with cachio about adding one
[12:19] <zyga> cachio: can we get a 18.10 image in google? it would help with testing
[12:34] <cachio> zyga, yes
[12:35] <cachio> zyga, I'll create it today
[12:35] <zyga> splendid, thank you!
[12:35] <cachio> zyga, np
[12:41] <Chipaca> mvo: was your "this looks fine" on #5907 a +1?
[12:41] <mup> PR #5907: overlord/snapshotstate: chown the tempdir <Simple> <📸󠁟̻> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5907>
[12:44] <mup> PR snapd#5919 opened: overlord: don't make become-operational interfere with user requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5919>
[12:50] <Chipaca> pedronis: why does become-operation being retried imply other things don't need to conflict with it?
[12:52] <pedronis> Chipaca: because it actually doesn't change any snap, the retry means that if it's relevant snap goes way too bad
[12:52] <pedronis> we will retry
[12:52] <pedronis> that logic doesn't apply to anything else
[12:52] <zyga> can someone with forum edit powers go and fix formatting on this post please: https://forum.snapcraft.io/t/snap-from-jar/5529/43
[12:52] <mup> PR snapd#5907 closed: overlord/snapshotstate: chown the tempdir <Simple> <📸󠁟̻> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5907>
[12:52] <mvo> Chipaca: it was a +1, just watned to wait for the answer about my tests question
[12:52] <Chipaca> mvo: thanks :)
[12:53] <Chipaca> pedronis: ok
[13:35] <pedronis> Chipaca: master is broken with a shellcheck error
[13:36] <pedronis> I suppose something that landed recently has a shellcheck error that wasn't spotted
[13:36] <pedronis> when it landed
[13:36] <Chipaca> pedronis: fixing
[13:37] <pedronis> Chipaca: to be clear, not your fault, but I know you are into shellcheck
[13:37] <pedronis> or so I vaguely remember
[13:37] <Chipaca> :)
[13:38] <Chipaca> pedronis: the shellcheck spread test, or the shellcheck static check?
[13:39] <pedronis> Chipaca: https://travis-ci.org/snapcore/snapd/jobs/437115506
[13:39] <Chipaca> the spread shellcehck
[13:39] <Chipaca> looking
[13:46] <pedronis> thx
[13:46] <pedronis> mvo: my small fix is red because of that ^
[13:48] <mvo> pedronis: looking
[13:49] <pedronis> mvo: Chipaca is fixing I think, but means master is red atm
[13:49] <mvo> ta
[13:49] <Chipaca> yes
[13:49] <Chipaca> mvo: the problematic pr is the portal activation one :)
[13:50] <Chipaca> which should've been merged with master before doing that last merge
[13:50] <Chipaca> ¯\_(ツ)_/¯
[13:50] <Chipaca> an easy fix
[13:50] <mvo> Chipaca: we can enforce in GH that things must be up-to-date before merging but that will be a burden of its own
[13:50] <Chipaca> not worth it imo
[13:51] <Chipaca> how often do we break master because of this?
[13:52] <Chipaca> mvo: niemeyer: should I merge #5888, or should I close it?
[13:52] <mup> PR #5888: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>
[13:52] <mup> PR snapd#5920 opened: tests/main/document-portal-activation/task.yaml shellcheck fix <Created by chipaca> <https://github.com/snapcore/snapd/pull/5920>
[13:52] <Chipaca> pedronis: mvo: ^ fix
[13:53] <mvo> Chipaca: thank you
[14:00] <pedronis> mvo: I'll need to backport my fix to both 2.35 and 2.36 (once we can land it)
[14:00] <popey> zyga: should opensuse 15.0 work? (it doesn't for me). https://docs.snapcraft.io/core/install-opensuse
[14:00] <popey> it says "Repository 'snappy' is invalid" when I add it on OpenSUSE 15
[14:01] <popey> (modified the line to use the 15.0 directory from http://download.opensuse.org/repositories/system:/snappy/ )
[14:07] <mvo> pedronis: its probably just a cherry pick, no?
[14:07] <mvo> pedronis: if it applies cleanly no need to backport I can just to the cherry picking
[14:09] <mup> PR snapcraft#2317 closed: tests: add spread suite for plainbox plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2317>
[14:18] <mup> PR snapcraft#2319 opened: plugins: remove the tar-content plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2319>
[14:24] <mup> PR snapcraft#2316 closed: storeapi: Use structured data for the conflicted current value <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2316>
[14:26] <pedronis> mvo: hopefully, new tests sometimes give problems
[14:28] <ackk> hi, I'm trying to use build-snaps to get go 1.11 to build a part, but it seems that the build phase prefers the distro go over the snap one. is there way to change that?
[14:29] <sergiusens> ackk: what version of snapcraft? AFAIK we had contributions from mvo   to have this fixed
[14:29] <sergiusens> and that lives on 2.43.1 at least
[14:29] <ackk> sergiusens, well I'm running cleanbuild so it's using stable I think
[14:30] <ackk> sparkiegeek, I am using edge here, but not specifying to use edge to cleanbuild
[14:30] <zyga> popey: not sure, the infra was down lately and the package needs an update that we cannot ship because $reasons (packaging woes)
[14:30] <ackk> err sergiusens ^
[14:30] <zyga> popey: I am working on fixing that but with low priority lately
[14:30] <mup> PR snapcraft#2321 opened: tests: add spread suite for plainbox plugin (#2317) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2321>
[14:30] <zyga> popey: though with some progress
[14:30] <popey> ok
[14:31] <zyga> popey: I see that the download servers are responding as my suse box has successfully updated now
[14:31] <zyga> but the version of snapd in the repo is old and out of date
[14:31] <zyga> i have an updated version but it was impossible to build for a while
[14:31] <niemeyer> cachio: Works?
[14:31] <zyga> so that's the state
[14:31] <cachio> niemeyer, yes
[14:32] <niemeyer> cachio: Sweet
[14:32] <cachio> niemeyer, tx
[14:33] <ackk> sergiusens, so I am using 2.43.1
[14:42] <mup> PR snapd#5921 opened: spread-shellcheck: use threads to parallelise <Simple :smiley:> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5921>
[14:42] <Chipaca> aw that sucks
[14:42]  * Chipaca fixes
[14:43] <Chipaca> #5921
[14:44] <mup> PR #5921: spread-shellcheck: use threads to parallelise <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5921>
[14:44] <Chipaca> mucho bettero
[14:48] <mup> PR snapd#5920 closed: tests/main/document-portal-activation/task.yaml shellcheck fix <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5920>
[14:48] <Chipaca> pedronis: master fixed ^
[14:54] <sergiusens> ackk: go plugin or a different one?
[14:55] <ackk> sergiusens, godeps one
[14:55] <sergiusens> ackk: support not there yet, mind creating a bug for that?
[14:57] <ackk> sergiusens, sure. fwiw I tried overriding the PATH before calling snapcraftctl build but it doesn't work
[14:57] <ackk> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1796109
[14:57] <mup> Bug #1796109: godeps plugin doesn't use go from build-snaps <Snapcraft:New> <https://launchpad.net/bugs/1796109>
[14:58] <sergiusens> ackk: snapcraftctl runs inside snapcraft, so environment is not going to stick
[14:58] <ackk> I see
[15:02] <ackk> sergiusens, maybe related, the snap has version: git  and the actual version of the snap comes out as "git"
[15:03] <sergiusens> ackk: file name or actual version set in the snap? Can I see logs?
[15:03] <ackk> sergiusens, filename for sure, I'm rebuilding now
[15:04] <sergiusens> ackk: check prime/meta/snap.yaml, that's what matters
[15:11] <ackk> $ snap install --dangerous ./candid_git_amd64.snap
[15:11] <ackk> error: cannot read snap file: invalid snap version "v1.0.0-alpha4+git17.1d2e580-dirty": cannot be
[15:11] <ackk>        longer than 32 characters (got: 33)
[15:12] <ackk> sergiusens, oops :) ^
[15:12] <ackk> but it shows the version is actually ok
[15:12] <popey> that is quite a version string!
[15:13] <ackk> popey, well TBF the tag is only v1.0.0.0-alpha4, the rest is from snapcraft
[15:13] <mup> PR snapd#5922 opened: Revert "spread: put openSUSE to manual" <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/5922>
[15:26] <sergiusens> ackk: do something like this instead https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml#L68
[15:27] <ackk> sergiusens, for the internal version?
[15:28] <sergiusens> ackk: https://discourse-docs.staging.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
[15:28] <sergiusens> ackk: there are no anchors on there yet, so you will need to hit page down
[15:28] <sergiusens> or end, to get, to the last section
[15:29] <ackk> sergiusens, fwiw if I build with snapcraft edge the version is correct
[15:30] <sergiusens> ackk: using `version: git`? That code has not changed across stable and edge...
[15:31] <mvo> zyga: hey, I was thinking about the systemd protocol mount error again - you suspected mount itself iirc, I did a small script (http://paste.ubuntu.com/p/Dy95dMFgDq/) that does a load of mounts in parallel but I can't reproduce the failure with this - am I missing something ?
[15:31] <ackk> sergiusens, could it be because of cleanbuild vs build?
[15:31] <zyga> mvo: perhaps
[15:31] <zyga> mvo: I found the bug in C
[15:32] <zyga> mvo: just didn't have time to wrap that up and propose a fix upstream
[15:32] <ackk> sergiusens, or because I now committed so now there's no -dirty suffix anymore
[15:32] <zyga> mvo: I can share the details but perhaps in private
[15:32] <sergiusens> ackk: which one is which? -dirty shows up when non commited code exists
[15:32] <sergiusens> ackk: yeah, that would do it
[15:32] <mvo> zyga: it was about loopctx_find_unused?
[15:32] <mvo> zyga: sure
[15:33] <ackk> sergiusens, I mean I made 2 changes from when I only had "git" in the filename, 1) committed changes 2) ran "snapcraft" instead of "snapcraft cleanbuild"
[15:33] <sergiusens> ackk: the docs I pointed you to allow you to control better what to show and takes (so we do not need to be guessing if folks are using signed tags or not)
[15:35] <ackk> sergiusens, thanks
[15:37] <ackk> sergiusens, do you know if the change to support go build-snaps in godeps is only a matter of PATH?
[15:39] <sergiusens> ackk: yes, the `-` represent how it is solved today in the go plugin and the `+` on how it will work for when using bases https://pastebin.com/zzgDzdxf
[15:40] <sergiusens> ackk: I would need to sort of just cherry-pick on the original implementation into the godeps plugin for our legacy branch for you to see results today
[15:40] <sergiusens> ackk: but yes, it is somewhat PATH related.
[15:42] <ackk> sergiusens, I see
[16:04] <kyrofa> zyga, do you have any docs on layouts? Gonna work on adding support
[16:05] <zyga> kyrofa: indeed we have
[16:05] <zyga> https://forum.snapcraft.io/t/snap-layouts/7207
[16:12] <niemeyer> zyga: What's the plan for making sure the test mentioned in https://github.com/snapcore/snapd/pull/5912 doesn't get lost?
[16:12] <mup> PR #5912: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <⚠ Critical> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5912>
[16:13] <zyga> niemeyer: I'm working on it since yesterday
[16:13] <zyga> moving onto spread now
[16:13] <zyga> (from hacking around on my local system)
[16:14] <niemeyer> zyga: Cool, thanks
[16:37] <Chipaca> mvo: should I squash #5096?
[16:37] <mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5096>
[16:38] <Chipaca> wait no
[16:38] <Chipaca> #5906
[16:38] <mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
[16:39] <pedronis> Chipaca: think so
[16:40] <Chipaca> me too (but i don't like squashes) :)
[16:40] <Chipaca> ah well
[16:40] <Chipaca> oh, bah, spread isn't even started yet
[16:50] <Chipaca> zyga: https://lwn.net/Articles/767547/
[16:52] <zyga> oooooh
[16:52] <zyga> ooh
[16:52] <zyga> I think I need a moment here
[16:53] <zyga> with those we could throw away 80% of the C / go magic
[16:55] <zyga> thank you
[16:56] <Chipaca> zyga: any year now
[16:58] <zyga> Chipaca: "In this particular case, it turns out that part of the problem is the result of the fact that the container runtime in question is written in Go:"
[16:58] <zyga> that's true in our case as well
[16:59] <zyga> anyway, definitely something to read in detail later
[16:59] <Chipaca> zyga: this being lwn you have links to the lkml threads and all
[16:59] <Chipaca> zyga: happy reading :)
[17:05] <mvo> Chipaca: please squash it
[17:06] <Chipaca> mvo: ack
[17:09]  * zyga breaks for family time
[17:21] <cachio> zyga, cosmic image in progress
[17:33]  * cachio afk
[17:48] <Chipaca> zyga: what man section should snap-confine be in? and snap-discard-ns? (the latter is in section 5 right now which is Very Wrong)
[17:48] <Chipaca> this is on Ubuntu,  dunno elsewhere
[17:53] <Chipaca> also snapd-env-generator in the wrong section
[17:53] <Chipaca> augh
[17:55] <pedronis> Chipaca: is that even well defined? they are not path
[17:55] <pedronis> *on path
[17:58] <pedronis> Chipaca: anyway it's either 1 or 8
[17:59] <pedronis> Chipaca: I suppose snap-discard-ns could go in 8
[18:29] <zyga> Chipaca: 1 perhaps
[18:29] <zyga> but it's not on PATH so I put it in 5
[18:30] <mup> PR snapcraft#2321 closed: tests: add spread suite for plainbox plugin (#2317) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2321>
[18:36] <pedronis> Chipaca: postgres seems to have a bunch of binaries only in /usr/lib but they are under 1
[18:36] <pedronis> fwiw
[18:48] <mup> PR snapd#5919 closed: overlord: don't make become-operational interfere with user requests <⚠ Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5919>
[18:50] <vidal72[m]> what's ETA for stable core18? roughly
[18:54] <mup> PR snapd#5923 opened: overlord: don't make become-operational interfere with user requests (2.35) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5923>
[18:55] <mup> PR snapd#5924 opened: overlord: don't make become-operational interfere with user requests (2.36) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5924>
[18:57] <pedronis> ok, created the cherry-picks for 2.35/36
[18:59] <mup> Bug #1796165 opened: seeded snaps never cleaned up. <Snappy:New> <https://launchpad.net/bugs/1796165>
[19:00] <Chipaca> pedronis: yep. But it's not about /usr/lib or not, it's about 'is this for a user, or for an admin'
[19:00] <Chipaca> pedronis: (snap is for an admin, in general)
[19:00] <Chipaca> zyga: 5 is for files, like /etc/passwd, not for tools
[19:32] <mup> PR snapd#5925 opened: interfaces/docker-support: add rules to read apparmor macros for 2.35 release <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5925>
[19:41] <mup> PR snapd#5922 closed: Revert "spread: put openSUSE to manual" <Simple 😃> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5922>
[19:42] <mup> PR snapd#5905 closed: store: gracefully handle unexpected errors in 'action' response <Simple 😃> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5905>
[19:50] <mup> PR snapd#5918 closed: interfaces/seccomp: allow using statx by default <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5918>
[19:51] <mup> PR snapd#5898 closed: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5898>
[19:51] <Chipaca> pedronis: what's up with #5712? seems GTG?
[19:52] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[19:52] <pedronis> Chipaca: needs more tests
[19:53] <pedronis> Chipaca: notice that both branches you just merged had +1 with requests of tweaks from me
[19:53] <mup> PR snapd#5901 closed: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5901>
[19:54] <Chipaca> er
[19:54] <Chipaca> pedronis: one was about findSnapOfManualAlias but and other renames which sounds like a separate concern
[19:54] <Chipaca> pedronis: in any case sorry :-/
[19:54] <pedronis> Chipaca: yes
[19:54] <pedronis> Chipaca: the other one was a fix for the log
[19:55] <Chipaca> ah drat
[19:55] <Chipaca> i'd _seen_ that
[19:55] <Chipaca> :-(
[19:55] <Chipaca> sorry again
[19:55] <Chipaca> i should go have dinner and stop breaking stuff
[19:55] <pedronis> Chipaca: is not breaking stuff, but I also don't want to start voting changes request for small things
[19:56] <pedronis> to avoid this
[19:56] <Chipaca> right
[19:56] <Chipaca> I'm usually more careful
[19:56]  * Chipaca ~> something to eat
[19:56] <pedronis> Chipaca: anyway the log fix is throwing a couple of [] in the mix
[20:02] <mup> PR snapd#5925 closed: interfaces/docker-support: add rules to read apparmor macros for 2.35 release <Created by anonymouse64> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5925>
[20:15] <mup> PR snapcraft#2319 closed: plugins: remove the tar-content plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2319>
[20:27] <ijohnson> jdstrand: thanks for merging that docker PR, any idea when the next 2.35 release will have that?
[20:39] <zyga> Chipaca: can I land 5908?
[20:39] <mup> PR snapcraft#2308 closed: plugins: remove the copy plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2308>
[20:46] <Chipaca> zyga: what's the .keep file?
[20:49] <zyga> a placeholder so that we have a directory entry
[20:52] <mup> PR snapd#5926 opened: store: tweak unmatched refresh result error log <Created by pedronis> <https://github.com/snapcore/snapd/pull/5926>
[20:52] <Chipaca> ah
[20:53] <mup> PR snapd#5908 closed: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5908>
[20:53] <zyga> thanks!
[20:53] <zyga> I have a follow up now
[20:53] <Chipaca> zyga: could you review #5926?
[20:53] <mup> PR #5926: store: tweak unmatched refresh result error log <Created by pedronis> <https://github.com/snapcore/snapd/pull/5926>
[20:53] <zyga> sure
[20:53] <Chipaca> zyga: it's  my fault that even exists :)
[20:53] <pedronis> Chipaca: btw did you squash those PR you merged? they were meant for 2.36 as well
[20:54] <Chipaca> pedronis: the ones that were tagged, yes
[20:54] <Chipaca> pedronis: targeted i mean
[20:54] <zyga> is it just wording change?
[20:54] <Chipaca> zyga: yes
[20:54] <zyga> pedronis: I have a way to get non-squashed PRs easily into the release branch
[20:54] <zyga> a git feature
[20:55] <zyga> I showed it to mvo a while ago
[20:55] <zyga> (offtopic: mac spellchecker consistently renames mvo to moo, I think it knows mvo's background ;-)
[21:01] <pedronis> Chipaca: we need to remember to create the cherrypicks then
[21:01]  * pedronis -> rest
[21:03] <Chipaca> pedronis: I'm hoping mvo keeps track of things with the milestone :)
[21:03] <Chipaca> otherwise, uff
[21:03] <zyga> Chipaca: I pushed one more fix but I'm not expecting anyone to review it today
[21:03] <Chipaca> s/hoping/expecting/
[21:03] <Chipaca> zyga: to who?
[21:03]  * Chipaca is owl
[21:03]  * zyga scratches head
[21:04] <zyga> Chipaca: yes :)
[21:04] <pedronis> Chipaca: we do have a list of closed stuff
[21:04] <zyga> Chipaca: we need to review 2.36 milestone closed branches with him
[21:04] <mup> PR snapd#5927 opened: cmd/snap-update-ns: remove empty placeholders used for mounting <Created by zyga> <https://github.com/snapcore/snapd/pull/5927>
[21:04] <pedronis> but not sure
[21:05] <Chipaca> if I were in mvo's position, i'd have gotten through seven cans of kick-butt today, with all these sudden targeted PRs
[21:05] <Chipaca> just sayin'
[21:06] <zyga> Chipaca: we need anonymous branch authors ;)
[21:06]  * zyga needs to go to bed 
[21:06] <zyga> ttyl guys
[21:29] <mup> PR snapd#5906 closed: snap, client, daemon, store: use and expose "media" more <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5906>
[22:31] <Chipaca> cachio: you around?
[23:01] <mup> PR snapcraft#2322 opened: project_loader: add build-environment part property <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2322>
[23:16] <mup> PR snapd#5928 opened: cmd: put our manpages in section 8 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5928>