[06:14] <palasso> Hello, is there an RSS/Atom feed for this blog: https://snapcraft.io/blog ?
[06:56] <pstolowski> mornings
[07:00] <mvo> pstolowski: hey, good morning
[07:41] <mvo> pedronis: can I merge 5474 (the single task-runner PR) or does someone else should look at it first? it got two +1 now
[07:41] <pstolowski> yay!
[07:42] <pstolowski> mvo, would you have a moment to take a look at https://github.com/snapcore/snapd/pull/5433 (it's simple)?
[07:42] <mup> PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
[07:45] <mvo> pstolowski: sure, let me do this now
[07:56] <pstolowski> mvo: thanks!
[07:57] <pedronis> mvo: yes, can be merged, yes I will do a couple follow ups to see how it feelds to make some of those now often empty methods optional
[08:03] <pstolowski> merged
[08:04] <mvo> pedronis: \o/
[08:05] <mvo> hm, I want mup back
[08:07] <pstolowski> hmm indeed what happened to it?
[08:10] <Chipaca> mo'in
[08:16] <mvo> pstolowski: it got disabled when github was acting up some days ago
[08:17] <pstolowski> i see
[08:18] <mvo> a second review for 5542 would be great
[08:25] <Chipaca> mvo: +1
[08:26] <pedronis> github is a bit unresponsive for me today
[08:27] <Chipaca> pedronis: it's the universe way of telling you to head to hr.canonical.com and ask for the day off
[08:27] <pedronis> Chipaca: I have things to do also in gdocs, which work, too bad
[08:27] <pedronis> (and the forum as well)
[08:27] <Chipaca> pedronis: *that*'s the universe's way of saying https://www.youtube.com/watch?v=kdOPBP9vuZA
[08:30] <Chipaca> pedronis: it's the week after next that you're away for two weeks, right?
[08:31] <pedronis> yes
[08:31] <Chipaca> pedronis: ok
[08:31] <pedronis> from the 31st to be precise
[08:31] <pedronis> I'll be around Monday 30
[08:34] <Chipaca> pedronis: ack
[08:36] <Chipaca> filed go-flags#264 fwiw
[08:36]  * Chipaca hoped mup would point that to https://github.com/jessevdk/go-flags/issues/264 but, alas
[10:05] <kjackal> Hello snappy people! I facing a problem with building snaps from launchpad (LP) builders. I have a single snap, named microk8s, and I would like to release to edge from the code's master branch and to track 1.10/edge  from the code's  1.10 branch. I first created a snap for the master->edge path, but then when I select the 1.10 code branch and click "Create a new snap package" in the snap "Name: " I have to use the name "microk8s"
[10:05] <kjackal> again and this errors with "There is already a snap package owned by microk8s developers with this name."
[10:07] <kjackal> So, same snap release with LP builders from different code branches to different tracks is where I am loosing it.
[10:08] <kjackal> Should I go to the forum or is there something obvious I am missing?
[10:10] <kjackal> Let me ask on #launchpad as well
[10:18] <cjwatson> I've answered on #launchpad.
[10:19] <kjackal> thanks cjwatson
[10:29] <pedronis> Chipaca: mvo: I think I never noticed but it seems you cannot edit very old posts (that are not wikis) even as original author.
[10:35] <mvo> pedronis: interessting, I did not notice that yet
[10:38] <Chipaca> pedronis: do you have an example?
[10:39] <pedronis> Chipaca: yes, I was trying to update: https://forum.snapcraft.io/t/transactionality-locking-and-other-concurrency-coordination/50
[10:39] <pedronis> no edit button for me
[10:40] <Chipaca> pedronis: hmm, I see an edit button
[10:40] <pedronis> Chipaca: remember you have more powers than me
[10:40] <Chipaca> pedronis: but I need to expand the options to see it
[10:41] <Chipaca> pedronis: that is: to the left of Reply I see like, link, and ellipsis
[10:41] <Chipaca> pedronis: click the ellipsis, and in there i have edit
[10:41] <pedronis> no ellispsis for me
[10:41] <pedronis> I'm talking about the top post to be clear
[10:41] <Chipaca> yep yep
[10:42] <Chipaca> pedronis: and if i make it a wiki? would that help?
[10:42] <pedronis> Chipaca: not sure,   does the top post and the last makes sense?  do we fear people only reading the top one and being confused because SetBlocked is going away?
[10:43] <Chipaca> pedronis: if this is meant to document the topic, having half in the top and half at the bottom doesn't work, if that's what you're asking
[10:44] <pedronis> Chipaca: yea, that's what I fear,  the top post sounds very descriptive/prescriptive, not narrative of a moment in time
[10:44] <Chipaca> pedronis: if you reload, does it now let you edit?
[10:45] <pedronis> no
[10:45] <Chipaca> pedronis: and now
[10:46] <pedronis> yes
[10:46] <pedronis> you turned it into a wiki?
[10:46] <Chipaca> pedronis: ok. let me know if you want me to dewoke it
[10:46] <Chipaca> pedronis: yes. It's a reversible operation, and i can't make you admin, so ¯\_(ツ)_/¯
[10:46] <pedronis> Chipaca: I have an errand very soon but I can tweak it after
[10:46] <pedronis> and see from there
[10:47] <Chipaca> pedronis: ok
[10:47] <Chipaca> pedronis: I've got to go to the boys' school in a bit, and i might not be back online before your eod (but i'll be on later)
[10:47] <Chipaca> in fact i'm late!
[10:47]  * Chipaca runs
[10:49] <pstolowski> mvo: hey, i'm hitting core18 failure in my disconnect-hooks branch, and i'm most likely doing something wrong in the new world. the problem i've is disconnect failure - "Disconnect core:core-support-plug from snapd:core-support (internal error: connection "core:core-support-plug snapd:core-support" not found in state)". i'm probably missing some sort of remapping in the new code; any hints?
[10:51] <mvo> pstolowski: hm, this has the latest master?
[10:51] <mvo> zyga: -^
[10:51] <pstolowski> mvo: well, yes, but it's my branch with master changes merged
[10:51] <mvo> pstolowski: hm, hm, I need to look at this
[10:51] <pstolowski> mvo: so very likely something i'm not doinf or doing wrong
[10:52] <pstolowski> mvo: cause i've changed a lot wrt disconnects
[10:52] <mvo> pstolowski: or its a bug in the remapper
[10:52] <mvo> pstolowski: not unlikely as well
[10:53] <pstolowski> mvo: this is in code triggered on snap removals - i run "disconnect" tasks for all connections, and the handler expects connection in 'conns' in the state
[10:53] <pedronis> pstolowski: in theory getConns and setConns should do the job for you
[10:53] <pedronis> but I don't know if you have code by-passing them
[10:55]  * pedronis has some relatively quick errands now
[10:55] <pstolowski> pedronis: right; no, i'm not bypassing them
[11:00] <pstolowski> although, maybe my lookups on conns are invalid when it comes to snap names now? i've connection refs coming from repo; i look them up in conns retrieved via getConns()
[11:28] <pstolowski> ok, i suspect i need RemapSnapToState() as I look up manually constructed conn IDs .. testing
[12:53] <zyga> Hey
[12:53] <zyga> Sorry for not finishing the PR work last night mvo
[13:00] <mvo> zyga: good morning - now worries
[13:33] <thresh> does anyone know if mozilla plans to release asan-enabled firefox via snaps?
[14:11] <zyga> thresh: I don't know anything about that, perhaps popey knows
[14:50] <popey> Zyga. Sorry on vacation
[14:50] <popey> Kenvandine and willcooke  know about Mozilla things though
[15:13] <zyga> thanks
[15:34] <mbeneto> hi, has anybody seen kyrofa around lately?
[15:39] <mbeneto> or can anybody enable again the experimental channel "edge/classic-trusty"?
[15:40] <phocean> hi
[15:40] <phocean> any idea about this error when trying to launch a classic snap : "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
[15:40] <phocean> my guess is that it is an apparmor issue, but how to fix it ?
[15:41] <mbeneto> more details regarding the "edge/classic-trusty" channel here: https://forum.snapcraft.io/t/building-classic-snap-on-trusty-fails/5472/13
[15:41] <phocean> it happened after I uninstalled snapd by accident because of a dependencie, and then I reinstalled it
[15:48] <pstolowski> zyga ^
[16:32] <pedronis> pstolowski: the fix abour remapping still looks strange to me
[16:32] <pedronis> we are missing something
[16:42] <pedronis> mvo: we'll need to look into that ^
[16:45] <pstolowski> pedronis: thanks for keeping an eye on this
[16:48] <pstolowski> i think i will leave it at this point and revisit after i'm back from vacation
[16:52] <mvo> pedronis: ok
[17:02] <pstolowski> see you o/
[17:14] <zyga> what's the issue about the remapping you were talking about?
[17:17] <pedronis> zyga: pawel is hitting strange bugs in his new code in disconnect-hooks, he added some strange remapping that doesn't make much sense on its own, either there's a bug in the remapping or the new code, either way we need to understand
[17:17] <pedronis> we don't have a unit test, only failing spread tests, that the remapping that I don't understand seeems to fix
[17:17] <zyga> pedronis: I see, ok
[17:18] <zyga> thanks, I'll talk to pawel next week
[17:18] <pedronis> pawel is off
[17:18] <pedronis> for two weeks
[17:18] <pedronis> we'll need to dig but not today
[17:22] <zyga> oooh
[17:23] <zyga> pedronis: yeah, I see
[17:23] <zyga> I will be off on Monday
[17:23] <zyga> but then I need to task switch to fedora
[17:23] <zyga> and then I plan a week of holidays
[17:23] <zyga> so my best bet is to just work with you next week but not in full capacity
[17:23] <zyga> so that this part is fully bullet-proof
[17:26] <pstolowski|off> pedronis, zyga, mvo now that i think of it, i suspect this bug would be hit with existing discard-conns, if we had proper test. discard-conns is pretty liberal right now. with disconnect-hooks i'm essentially doing what discard-conns does, only more strict
[17:27] <zyga> pstolowski|off: are we hitting the state manually there
[17:28] <zyga> because all of connection load/store code applies mappings
[17:30] <pstolowski|off> zyga: i get conns via getConns in doDisconnect() - something we didn't do before. and i do this: https://pastebin.ubuntu.com/p/TYDZc3v8dC/ based on plug/slot refs from disconnect command
[17:31] <pstolowski|off> (the remapping part is the part that pedronis commented on above - the suspicious bit)
[17:31] <zyga> interesting
[17:31] <zyga> I don't think you need that
[17:31] <zyga> you should not need that
[17:31] <zyga> I'll look next week
[17:31] <zyga> I'm a bit tired despite it being 1:30PM
[17:31] <pstolowski|off> zyga: without that it fails
[17:32] <zyga> I see
[17:32] <zyga> I'll look next week
[17:32] <pstolowski|off> with that - it passes
[17:32] <zyga> we have another meeting coming up now
[17:32] <pstolowski|off> at least passes the spread test i iterated on
[17:32] <pstolowski|off> zyga: sure, i'm really of now as well.
[17:32] <pstolowski|off> zyga: safe trips!
[17:32] <zyga> thank you :)
[17:33] <mvo> pstolowski|off: enjoy your time off!
[17:33] <pstolowski|off> thanks!
[17:33] <mvo> zyga: and safe travels for you
[17:33] <zyga> thank you guys
[17:33] <zyga> enjoy your weekends with your families
[17:33] <zyga> I'll check if my legs fit :)
[18:18] <thiras> hello
[18:18] <thiras> gnome's default calculator doesn't start
[18:19] <thiras> https://paste.ubuntu.com/p/TXBY2nskGz/
[18:19] <thiras> here is the error log
[18:19] <thiras> i'm really get sick of this permission denied errors (i've experienced few more of them and solved with re-installing the snap packages)
[18:20] <thiras> it's 18.04
[23:34] <bmath> Hi all, having some trouble with snaps after a kernel upgrade.  Getting an error about how ptrace was denied in syslog.  I checked the apparmor config file and it looks like that capability should be allowed.  Is there a kernel setting I need to enable?
[23:49] <zyga> bmath: hey, can you please provide the output of "snap version"
[23:49] <zyga> bmath: since I'm boarding soon I won't be able to assist you please open a forum topic at forum.snapcraft.io and reference me there with @zyga syntax
[23:50] <zyga> bmath: ideally please also include the name of the snap that causes the issue and the output of `dmesg | grep DENIED`
[23:50] <zyga> bmath: I'll be here for a few more moments but expect any answers from me on Tuesday, I have a long way home and I will rest a little