[02:41] <mup> PR snapcraft#2089 closed: many: remove support for remote lxd per project containers <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2089>
[03:02] <mup> PR snapcraft#2091 closed: meta: soften warning about using passthrough <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2091>
[04:40] <zyga> good morning
[04:47]  * zyga notices https://github.com/apple/foundationdb/
[05:13] <mborzecki> morning
[05:31] <zyga> hey hey
[06:01] <mborzecki>  google cloud packages repo for fedora had their gpg keys change
[06:01] <mborzecki> i'm testing a fix
[06:15] <zyga> thanks
[06:15]  * zyga had a rough morning with upset daugher
[06:15] <zyga> daughter
[06:17] <mup> PR snapd#5076 opened: spread: auto accept key changes when calling dnf makecache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5076>
[06:17] <mborzecki> zyga: i've resarted the build in #5074, it failed synchronizing fedora repo
[06:17] <mup> PR #5074: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
[06:17] <zyga> mborzecki: ah, it's not ready yet
[06:17] <zyga> that's all right
[06:17] <zyga> I will force push a full fix and tests on top
[06:18] <mborzecki> ok
[07:20] <pstolowski> mornings
[07:26] <kalikiana> morning o/
[07:26] <pedronis> #5072 needs a 2nd review
[07:26] <mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
[08:04]  * zyga keeps fighting the bug that pawel found
[08:07] <Chipaca> zyga: new one?
[08:07] <zyga> no, still the same one
[08:07] <zyga> it's just tricky to get the rules right
[08:07] <zyga> I know what I'm missing
[08:07] <zyga> but iteration is a bit painful
[08:11] <pedronis> m-v-o is off today?
[08:11] <zyga> pedronis: yes
[08:11] <zyga> he said he'd be off yesterday IIC
[08:11] <zyga> IIRC
[08:12] <Chipaca> ye
[08:12] <Chipaca> s
[08:12] <Chipaca> yesteray he said he'd be off today and monday
[08:12] <pedronis> ah, ok
[08:12] <pedronis> thx
[08:17] <mup> PR snapd#5072 closed: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5072>
[08:17] <pedronis> zyga: merged  ^
[08:17] <zyga> nice, thank you!
[08:17] <zyga> so one less "snap try" bug
[08:18] <zyga> I think there are some other places that may need similar changes
[08:18] <zyga> like there's ReadInfo that takes a container
[08:18] <zyga> it has the same issues
[08:18] <pedronis> I'm not sure Broken  and Error should have the same value (we have more context when we use Broken but we can revisit later)
[08:18] <pedronis> zyga: we use it in much more precise contexts
[08:18] <pedronis> usually before we are installing something
[08:18] <pedronis> so we want the errors
[08:19] <zyga> mmm,
[08:19] <zyga> it's not clear that one will fail while the other will not
[08:19] <pedronis> ?
[08:19] <zyga> I mean, from reading the documentation and function name
[08:19] <zyga> it's error prone
[08:19] <pedronis> they both fail
[08:19] <pedronis> you didn't make not fail
[08:19] <zyga> yes but one returns different errors than the other
[08:20] <zyga> sorry, I said that in a confusing way
[08:20] <zyga> the code is almost the same but the error values are not
[08:20] <pedronis> one is about the installed snaps
[08:20] <pedronis> maybe the error name, comment is not quite right
[08:21] <pedronis> ReadInfo reads the snap information for the *installed* snap ...  that's always been documented like that
[08:22] <pedronis> but yes, BrokenSnapError doc is a bit insufficient
[08:24] <pedronis> it seems snap/info.go needs a general doc review,  some comments are out of date
[08:24] <zyga> yes, I agree
[08:24] <pedronis> like I see a mention of File that doesn't exist anymore
[08:24] <mborzecki> i think i'm doing the whole system-nickname-core wrong, i did a change to replace core with system in data returned by /v2/interfaces endpoint, but that feels wrong, if one is using this api endpoint then the data returned would change, but there would no change in api version
[08:25] <pedronis> yes, not sure we can do that
[08:25] <pedronis> not sure if a lot of external parties are using interfaces though
[08:25] <pedronis> on the other hand
[08:25] <mborzecki> instead should probably only accept system as nickname for core, and do the right thing as if 'core' was passed
[08:25] <pedronis> we are doing the new connections work
[08:26] <pedronis> and snap interfaces is going away
[08:26] <pedronis> so maybe we need to do it only in the new stuff
[08:27] <pedronis> zyga: I mean a not to look at snap/info.go docs at some point
[08:27] <pedronis> *a note
[08:27] <zyga> ack
[08:28] <pstolowski> pedronis: hey, quick question wrt to what Gustavo asked in the interface hooks review about deny-auto-connection and deny-connection; i see them consistently used in majority of base decls, so I presume they are not denied by default?
[08:28] <mborzecki> pedronis: so maybe this, on POST to /v2/interfaces dealias system to core, but when you just query the interfaces, at the client side, present core as system by default, unless someone asked for 'core' specifically
[08:28] <pedronis> pstolowski: the deny-connection bit is a bit strange,  given is a test interface we probably don't want auto-connect though
[08:29] <pedronis> pstolowski: it's a bit unclear  though given it's a test interface
[08:29] <mborzecki> so the output of the endpoints does not change, it still accepts the 'nickname', and a new client can act accordingly to user's query
[08:32] <pedronis> pstolowski: basically I don't think you want the deny-connection bit
[08:33] <pedronis> pstolowski: it's saying that it cannot be connect on core, but can be connected on classic
[08:34] <pstolowski> pedronis: right. indeed, it doesn't make sense to deny that
[08:46] <zyga> I have to go to school, sorry, daughter is trouble today
[08:48] <Chipaca> must be the weather
[08:55] <mborzecki> damn, when running daemon unit tests, 3 tests fail, if I run them separately, they all pass, something not cleaned up in teardown
[08:58] <Chipaca> _unit_ tests
[08:58] <Chipaca> wat
[08:58] <Chipaca> (granted the daemon unit tests are the worst)
[08:59] <mborzecki> Chipaca: daemon/api, exactly what i'm working on right now
[08:59] <Chipaca> mborzecki: i'm so sorry
[09:02] <mborzecki> it all started when i started mocking 'core' snap in one of the tests, new it's special but didn't expect this
[09:02] <mborzecki> s/new/knew/
[09:19] <zyga> re
[09:25] <mborzecki> shouldn't https://github.com/snapcore/snapd/blob/master/daemon/api_test.go#L3498 be cleaned up?
[09:29] <pedronis> there's no way atm, it could
[09:31] <mborzecki> pedronis: added this https://paste.ubuntu.com/p/9z58cTd53S/ and a corresponding call in api tests, so far it's not failing anymore
[09:34]  * Chipaca goes afk
[09:38]  * Chipaca returns
[09:48] <pstolowski> niemeyer: i've addressed your comments to interface hooks, with one open question; thanks for the review!
[10:05] <zyga> gah
[10:05] <zyga> darn
[10:05] <zyga> I need to think
[10:05] <zyga> this apparmor rule issue is terrible
[10:11] <pstolowski> zyga: which one? the xmas tree?
[10:11] <zyga> yes
[10:12] <pstolowski> oh
[10:12]  * pstolowski is going for a walk
[10:13] <mborzecki> zyga: see what you did :)
[10:14] <zyga> I would love to go for a walk myself
[10:14] <zyga> but I have to crack this issue
[10:14] <mborzecki> poor chap couldn't stand being reminded of that rule
[10:19] <mup> PR snapd#5076 closed: spread: auto accept key changes when calling dnf makecache <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5076>
[10:35]  * zyga -> break for pen&paper debugging
[10:43] <zyga> chop tree test https://www.irccloud.com/pastebin/t1Vah68j/
[10:44] <zyga> jdstrand: hey
[11:02] <zyga> Chipaca, mborzecki: can you please review https://github.com/snapcore/snapd/pull/3963
[11:02] <mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
[11:02] <zyga> it's got two +1s
[11:02] <zyga> but is important enough for extra reviews
[11:03] <Chipaca> zyga: lunch now, meeting after, then standup, then school run, so … after that?
[11:03] <zyga> sure
[11:03] <Chipaca> k
[11:16] <ogra_> zyga, ogra@acheron:~$ snap run snapcraft-forum
[11:16] <ogra_> cannot change profile for the next exec call: No such file or directory
[11:16] <ogra_> snap-update-ns failed with code 1: No such file or directory
[11:16] <ogra_> ogra@acheron:~$ snapcraft-forum
[11:16] <ogra_> cannot change profile for the next exec call: No such file or directory
[11:16] <ogra_> snap-update-ns failed with code 1: No such file or directory
[11:16] <ogra_> ogra@acheron:~$
[11:17] <zyga> ogra_: hey, what is snap version?
[11:17] <ogra_> (after a reboot on 16.04 ... whats going on there (other snaps seem to start though)
[11:17] <zyga> ls /var/lib/snapd/apparmor/profiles
[11:17] <ogra_> ogra@acheron:~$ snap version
[11:17] <ogra_> snap    2.32.3
[11:17] <ogra_> snapd   2.32.3
[11:17] <ogra_> series  16
[11:17] <ogra_> ubuntu  16.04
[11:17] <ogra_> kernel  4.13.0-38-generic
[11:17] <zyga> sudo cat /sys/kernel/security/apparmor/profiles
[11:17] <zyga> update to .5 (beta) and see if this is fixing it
[11:18] <ogra_> https://paste.ubuntu.com/p/fTz2QFW3wZ/
[11:18] <ogra_> ... refreshing ...
[11:18] <zyga> ogra_: what is snapcraft-forum
[11:18] <zyga> and why don't you have profiles for it
[11:18] <zyga> is it active?
[11:18] <zyga> is it mounted?
[11:19] <ogra_> its a sideloaded electron snap for the forum
[11:19] <ogra_> nothing fancy about it beyond that
[11:19] <zyga> mmm
[11:19] <zyga> you don't have any profiles for it
[11:19] <zyga> is it "snap try"
[11:19] <ogra_> (same snap runs fine on my desktop that i also rebooted today with latest updates)
[11:20] <ogra_> no, its just a sideloaded snap .. hasnt changed for 4-5 months, used daily
[11:20] <zyga> is it in /var/lib/snapd/snaps
[11:20] <ogra_> zyga, beta fxes it
[11:20] <zyga> and is it listed in 'snap list'?
[11:20] <ogra_> indeed it is
[11:20] <zyga> hmm
[11:20] <zyga> reboot a few times to see if this happens
[11:20] <ogra_> and it starts fine now with beta
[11:20] <zyga> I don't know why we'd _not_ show that snap
[11:20] <zyga> yeah because beta update regenerated profiles
[11:21] <zyga> but why was it missing?
[11:21] <zyga> can you show your snap changes?
[11:21] <popey> om26er: just fyi, sublime-text grew from zero users to over a thousand pretty much overnight
[11:21] <ogra_> i really cant reboot a few times now (thats always some effort to bring my scripts back up etc ... and i'm busy implementing fulld-disk-encryption)
[11:21] <zyga> popey: wow :D
[11:21] <popey> om26er: dunno if you did any marketing, but we didn't
[11:21] <zyga> that's pretty neat
[11:21] <ogra_> ogra@acheron:~$ snap changes
[11:21] <ogra_> ID   Status  Spawn                 Ready                 Summary
[11:21] <ogra_> 201  Done    2018-04-19T12:48:57Z  2018-04-19T12:49:01Z  Auto-refresh snap "snapcraft"
[11:21] <ogra_> 202  Done    2018-04-19T18:13:56Z  2018-04-19T18:14:00Z  Auto-refresh snap "snapcraft"
[11:21] <ogra_> 203  Done    2018-04-20T09:28:56Z  2018-04-20T09:28:59Z  Auto-refresh snap "snapcraft"
[11:21] <ogra_> 204  Done    2018-04-20T11:18:23Z  2018-04-20T11:18:55Z  Refresh "core" snap from "beta" channel
[11:21] <popey> i expect it'll be 2K next week.
[11:22] <zyga> ogra_: intersting
[11:22] <ogra_> nothing interesting in snap changes either
[11:22] <zyga> ogra_: I believe this is something serious
[11:22] <zyga> ogra_: sergiusens also reported this happening to another snap
[11:22] <popey> eclipse jumped about the same rate too!
[11:22] <zyga> on reboot we randomly don't see a given snap
[11:22] <ogra_> that sounds bad indeed
[11:22] <zyga> popey: share this with sublime-text upstream
[11:22] <popey> oh we will :D
[11:22] <zyga> ogra_: this is artful?
[11:22] <popey> once it plateaus a little
[11:22] <zyga> ah xenial
[11:23] <zyga> same As my test machine
[11:23] <ogra_> yeah, see snap version above :)
[11:23] <zyga> I tried to reproduce it but no luck
[11:23] <zyga> yeah :/
[11:23] <ogra_> using hwe kernel here
[11:23] <zyga> popey: did you see my classic analyser?
[11:23] <ogra_> (non-hwe on my desktop FWIW)
[11:23] <popey> i did, but didn't use it - i wasn't the one having problems
[11:23] <zyga> popey: sure but it's not the point
[11:23] <zyga> you can run sublime-text
[11:23] <zyga> and run that script on the process
[11:24] <zyga> to see which things are packaged incorrectly
[11:24] <zyga> even if it works for $person
[11:24] <popey> on, interesting
[11:24] <zyga> it doesn't mean it's correct
[11:24] <zyga> this let's you see what is wrong
[11:24] <zyga> try it :)
[11:24] <zyga> I want to snap that helper
[11:24] <zyga> but I need to convince jdstrand
[11:24] <zyga> or make it classically confined
[11:24] <zyga> but I'd rather just make interfaces powerful enough
[11:26] <ogra_> zyga, wow ... just looking at syslog ... there are other oddities ... see the hexchat messages https://paste.ubuntu.com/p/qQpCZ8fgRh/
[11:26] <zyga> Apr 20 13:18:44 acheron snapd[4918]: 2018/04/20 13:18:44.109729 helpers.go:217: cannot connect plug "gsettings"
[11:26] <zyga>  from snap "hexchat", no such plug
[11:26] <mup> PR #20: Feature/snapfs cleanup kernel assets <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/20>
[11:27] <ogra_> yeah
[11:27] <zyga> hmm, that happened just now
[11:27] <zyga> so
[11:27] <zyga> ogra_: "snap interfaces hex chat"
[11:27] <ogra_> snap interfaces shows them all connected fine
[11:27] <zyga> (without the space, sorry, spellchecker does this)
[11:28] <zyga> can you restart snapd and see if something similar happens (to any snap)
[11:28] <ogra_> oh
[11:28] <zyga> oh?
[11:28] <ogra_> :desktop-legacy  hexchat,shattered-pixel-dungeon,telegram-desktop,vlc
[11:28] <ogra_> :network         gping,hexchat,lxd,packageproxy,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,usbtop,vlc,wine2
[11:28] <ogra_> :network-bind    hexchat,mjpg-streamer,packageproxy,shattered-pixel-dungeon,telegram-desktop,usbtop,vlc,wine2
[11:28] <ogra_> :unity7          hexchat,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,vlc,wine2
[11:28] <ogra_> :x11             hexchat,shattered-pixel-dungeon,snapcraft-forum,vlc,wine2
[11:28] <ogra_> hexchat:hexchat  -
[11:28] <ogra_> no home
[11:28] <zyga> cat the hex chat's snap.yaml please
[11:28] <ogra_> (or pulse)
[11:28] <ogra_> its the one from the store ... one sec
[11:28] <zyga> maybe that's harmless now
[11:28] <zyga> maybe it just dropped those plugs
[11:29] <zyga> we have some code in 2.33 that will remove stale connections
[11:29] <ogra_> http://paste.ubuntu.com/p/VGNzX4hZRJ/
[11:29] <ogra_> interesting
[11:29] <ogra_> why does it look for pulse/home/gsettings if they are not defined
[11:29] <zyga> ogra_: because it remembered those were connected
[11:29] <zyga> that's fine, that's harmless
[11:29] <ogra_> ok
[11:30] <zyga> ok, if you see this issue again (not having apparmor profile) do let me know
[11:30] <ogra_> (not sure why they would be connected and now not anymre though)
[11:30] <ogra_> will do
[11:30] <zyga> well, they were connected at some point in time
[11:30] <zyga> so we remember that
[11:30] <zyga> and we never forget until you remove the snap :)
[11:30] <zyga> (but don't do that, that's silly)
[11:30] <zyga> as snap refreshes the set of interfaces can change
[11:31] <ogra_> sure, i get that ... but that snap hasnt changed in a month
[11:31] <ogra_> ogra@acheron:~$ snap info hexchat|grep refresh
[11:31] <ogra_> refreshed: 2018-03-19T06:50:55+01:00
[11:31] <sergiusens> ogra_, zyga, popey:  yes, I logged a bug on snapd for the profiles magically going away
[11:32] <ogra_> will it try connecting every reboot even though it should know the interfaces are gone after the first attempt ?
[11:32] <sergiusens> ogra_: https://bugs.launchpad.net/snapd/+bug/1764998
[11:32] <mup> Bug #1764998: profiles making a run for it <amd64> <apport-bug> <bionic> <snapd:Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1764998>
[11:33] <ogra_> (i know it is harmless but the probing surely wastes boot time every boot ... )
[11:33] <sergiusens> zyga and no, I am not going to beta, last time I did that I had to reinstall my entire system
[11:33] <ogra_> well, but that at least guarantees yu have a clean system every now and then :P
[11:33] <mup> PR snapd#5077 opened: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5077>
[11:34] <ogra_> sergiusens, beta solved it for me
[11:34] <zyga> ogra_: yes but it takes microseconds to check they are missing
[11:34] <zyga> sergiusens: !
[11:34] <sergiusens> ogra_: please add it to the bug :-P
[11:34] <pstolowski> zyga: the code that removes stale connections hasn't landed yet
[11:34] <zyga> sergiusens: what happened?
[11:34] <sergiusens> but no, no beta for me
[11:34] <sergiusens> zyga: there was a bug in core, my snaps stopped working and I had to spend the day reinstalling
[11:35] <pedronis> atm beta == candidate
[11:35] <pedronis> and candidate wil becomed stable ~Monday
[11:35] <zyga> could you not switch back to stable?
[11:35] <sergiusens> zyga: no, there was a bug where channel switching was broken in beta ;-)
[11:35] <pedronis> zyga: candidate and beta are the same right now
[11:35] <zyga> sergiusens: switch, refresh and revert well all broken?
[11:35] <zyga> pedronis: ack
[11:36] <sergiusens> zyga: refresh was, and yes, there was no way to move back, I troubleshooted with mvo at that time
[11:39] <jdstrand> pstolowski (cc pedronis): interfaces/policy/basedeclaration.go describes the thought behind stuff
[11:40] <jdstrand> pstolowski (cc pedronis): that states that deny-connection should be used with app-provided slots. grepping for deny-connection, I don't see anything that is *only* an implicit core slot that has deny-connection
[11:40] <pedronis> jdstrand: this the dummy test interface though
[11:40] <pedronis> it's a bit unclear what rules should applay to it
[11:41] <pedronis> it doesn't open anything
[11:41] <jdstrand> pstolowski: the one where it is both core and app, we should have:
[11:41] <jdstrand> deny-connection:
[11:41] <jdstrand>   on-classic: false
[11:41] <jdstrand> pedronis: what is the 'dummy test interface'?
[11:41]  * jdstrand is lacking context
[11:41] <pedronis> jdstrand: it's in a big PR  about interface hooks that you should probably read
[11:41] <pedronis> (tough it's big)
[11:41] <jdstrand> oh that one
[11:42] <jdstrand> I've let zyga know-- I am working on a couple of things with critical priority for Berlin so not able to get to that yet
[11:42] <jdstrand> with luck, next week
[11:42] <zyga> good luck jdstrand
[11:43] <pstolowski> jdstrand: yep. that's the interface i introduced strictly for testing purposes as it was the only way to test that interface hooks work end-to-end; it doesn't do anything
[11:43] <jdstrand> pstolowski: can you describe what the interface does? it sounds like like it literally does nothing. if it does nothing, there is no reason for it to have anything beyond:
[11:43] <jdstrand> allow-installation:
[11:43] <jdstrand>   slot-snap-type:
[11:43] <jdstrand>     -core
[11:44] <jdstrand> pstolowski: (in terms of security)
[11:44] <popey> jdstrand: i did as requested with signal-desktop last night, happy to follow up today. https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/13
[11:44] <pedronis> jdstrand: it attached to some test apps though, not core
[11:44] <jdstrand> pstolowski: ie, let connect and auto-connect. if you need it to do something else for test purposes, just do what you want
[11:44] <jdstrand> ok
[11:44] <jdstrand> -app
[11:44] <pedronis> but yes, it does notighin
[11:44] <jdstrand> - core
[11:45] <pedronis> and probably shouldn't auto-connect, mostly to avoud confusion, unless some tests really need that
[11:45] <jdstrand> pstolowski: is this supposed to mimic how other interfaces act, or it just needs something in the base decl and you're wondering what?
[11:46] <pedronis> jdstrand: notice  that the review request, or at least looking at it, was not particularly for this, is that that PR changes a bit how policy is enforced
[11:46] <jdstrand> pstolowski: (since it does nothing, I would argue that you can put anything you wnat in the base decl)
[11:46] <pedronis> jdstrand: because it now accounts for dynamic intrface attrs coming from hooks
[11:47] <pstolowski> jdstrand: it's an interface that has a few attributes both on slot and plug side; some are defined in snap's yaml and some have values dynamically created at runtime by slot/plug hooks. the slot of "dummy" interface is offered by test snap
[11:47] <jdstrand> popey: that is disappointing
[11:48] <jdstrand> pstolowski: ok, so it is meant to *only* be provided by the test snap, *not* ever core?
[11:49] <pstolowski> jdstrand: correct
[11:49] <jdstrand> pstolowski: I suggest:
[11:49] <jdstrand> dummy:
[11:49] <jdstrand>   allow-installation:
[11:50] <jdstrand>     slot-snap-type:
[11:50] <jdstrand>     - app
[11:50] <jdstrand>   deny-connection: true
[11:50] <jdstrand> then add a snap decl for your test snap
[11:50] <pedronis> pstolowski: is the snap local or from the store?
[11:51] <jdstrand> this would mimic what we typically would do. if you don't care about the the snap decl integration, you could drop the deny-connection bit, but add a comment as to why
[11:52] <jdstrand> pstolowski: also, I'm guessing this is for 2.33 and *not* 2.32.something?
[11:53] <pedronis> jdstrand: correct, this is 2.33 material
[11:53] <jdstrand> ok
[11:53] <cachio> niemeyer, today I'll be 5 minutes late in the standup
[11:53] <jdstrand> I will have it at the top of my list to review after the two critical things I'm working on
[11:53] <jdstrand> hopefully that translates to next week, though popey's url means possibly not
[11:54] <popey> jdstrand: would it help if I gave you the script / setup I'm using to build signal?
[11:54] <popey> so you don't block on me
[11:55] <jdstrand> popey: I'm probably going to need to have the full tree to build the thing to see what is happening. I mean, I can resquash, resquash, resquash, ... ad nauseum snaps big snaps and it works fine
[11:56] <popey> jdstrand: well, I clone, patch, build. But I automated it with a litte script in lxd
[11:56] <jdstrand> popey: it seems they are maybe doing something weird or there is a disparity in the squashfs-tools inside and outside the container
[11:56] <zyga> popey: is signal classic?
[11:56] <popey> no
[11:57] <jdstrand> popey: yes please. if it is public, can you just put that into the forum topic?
[11:57] <popey> ok
[11:58] <popey> lemme dist-upgrade my container, try and build again and see
[11:58] <pstolowski> pedronis: the snap is local
[11:58] <jdstrand> popey: oh, yes, please. we did have to patch squashfs-tools for symlinks, but that was *ages* ago
[11:59] <jdstrand> it would be awesome if that is all it was...
[11:59] <popey> only had a few updates, including snapcraft 2.41, but not squashfs-tools
[11:59] <popey> trying anyway
[11:59] <jdstrand> if you have the 2.41 deb in there, then probably not it
[11:59] <pstolowski> jdstrand: thanks for the suggestions
[12:01] <jdstrand> pstolowski: you're welcome. sorry I can't review sonner, but I'll get to it
[12:01] <jdstrand> popey: thanks for retesting btw
[12:01] <popey> np
[12:01] <popey> I want this fixed as much as you :)
[12:03] <jdstrand> popey: I'm not sure that's possible, but thanks! ;P
[12:03] <popey> haha
[12:04] <jdstrand> zyga: you keep referring to snapping a helper and convincing me. is this the environ access?
[12:04] <pstolowski> jdstrand: np and thanks
[12:04] <zyga> popey: would it be possible to do one-time upload of dev version of s-t to edge?
[12:05] <popey> zyga: yeah, I'll take a look.
[12:05] <zyga> jdstrand: it was ...
[12:05] <zyga> jdstrand: (more than that)
[12:05] <jdstrand> both of the things
[12:05] <jdstrand> let me look, I have that somewhere
[12:06] <jdstrand> basically, I didn't care for it
[12:06] <zyga> classic-snap-analyzer https://www.irccloud.com/pastebin/Sk6YiLvk/
[12:06] <zyga> I wanted to get environment to check if SNAP_NAME is set (to be smart about finding snap processes)
[12:06] <zyga> I wanted proc/pid/maps to see what is loaded
[12:06] <jdstrand> /proc/pid/maps and /proc/pid/environ
[12:06] <zyga> I think there are some misc files I could use but that's bare minimum
[12:07] <zyga> btw, did you know you can poll on /proc/pid/mounts? :)
[12:07] <zyga> it's cool, I didn't know
[12:07] <popey> :( failed again jdstrand
[12:07] <zyga> jdstrand: also consider /proc/pid/map_files/
[12:07] <zyga> it's very similar to maps but laid out differnetly
[12:07] <zyga> *differently
[12:08] <jdstrand> zyga: system-observe is wrong for both of those
[12:08] <zyga> jdstrand: maybe process-control? (or process-observe?)
[12:08] <zyga> (process-observe would be a new interface)
[12:09] <jdstrand> zyga: process-control is pretty specific about what it can do, and that does not include reading a process memory
[12:09] <zyga> note that this doesn't leak memory, just information about memory maps
[12:09] <jdstrand> so, yes, I think it would be a new interfacec, possible process-observe
[12:10] <zyga> jdstrand: if you agree I can make that happen
[12:10] <jdstrand> zyga: I know, but it is info that I'm not excited about snaps having about other snaps
[12:10] <zyga> sure
[12:10] <jdstrand> so it must be manually connected
[12:10] <zyga> it's specifically designed for doing that though
[12:11] <zyga> I mean, on this specific snap I would seek auto-connection
[12:11] <zyga> as the purpose is to improve the quality of snaps published by other teams
[12:11] <jdstrand> you could also simply make it a classic snap for the time being
[12:11] <zyga> yes but that feels like cheating :)
[12:11] <zyga> I want less classic
[12:11] <zyga> and better classic if needed
[12:12] <jdstrand> classic is ultimately about timing
[12:12] <jdstrand> we can roadmap something, but that doesn't mean it is prioritized to instantly appear
[12:13] <zyga> that's true
[12:13] <jdstrand> ie, if you need this to help people *today*, make it classic, then we can see to improve
[12:13] <mup> PR snapd#5078 opened: interfaces/builtin, daemon: cleanup mocked builtin interfaces in daemon tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5078>
[12:13] <zyga> yeah, that's a good point
[12:13] <jdstrand> and take classic away from the snap later
[12:13] <zyga> yep
[12:13] <zyga> I'll do that
[12:13] <zyga> it will help everyone now
[12:14] <jdstrand> zyga: feel free to do a PR for process-observe. I'm going to want to think about it though, which gets to 'classic today' since, aforementioned critical work
[12:14] <zyga> sure
[12:16] <jdstrand> zyga: was there something else from backscroll you needed to talk about? something about apparmor profiles disappearing?
[12:16] <zyga> jdstrand: no, that's it for today
[12:17] <jdstrand> \o/
[12:17] <zyga> we have two reports of that happening but both on 2.32.3
[12:17] <jdstrand> :)
[12:17] <zyga> and no way to reproduce now
[12:17] <zyga> so ... good :)
[12:17] <jdstrand> not that I don't enjoy talking to you :)
[12:17] <zyga> the feeling is mutual :)
[12:17] <zyga> I'm going to publish this snap
[12:17] <zyga> and get back to apparmor
[12:18] <popey> jdstrand: added build instructions to the forum
[12:18] <jdstrand> zyga: the only thing I was going to add was there are a) system-key changes (which should affect all profiles) and b) there is that 'broken' issue
[12:18] <zyga> ack
[12:18] <jdstrand> zyga: if it were related to 'a', that sounds like a race condition
[12:19] <jdstrand> but something with ensure dir state...
[12:19] <jdstrand> you've surely thought of that though
[12:19] <jdstrand> ok, moving on
[12:19] <jdstrand> popey: thanks!
[12:20] <jdstrand> popey: I'm probably not going to look at that today since electron snaps are not blocked currently (we disabled resquash), but that is one of the two critical priority items
[12:20] <jdstrand> so, definitely next week
[12:21] <popey> ok, no worries.
[12:26] <jdstrand> zyga: oh, and sun profiles
[12:26] <jdstrand> that's the other one. but again, you are obviously thinking about that
[12:26] <zyga> in the case ogra had the snap had no profiles present
[12:27] <zyga> none
[12:27] <zyga> and it is not easy to reproduce, no ideas yet
[12:32]  * kalikiana lunch
[12:37] <jdstrand> zyga: that suggests it maybe misdetected devmode. I wonder what journalctl has to say about that...
[12:38] <zyga> ogra_: can you look at the log of snapd.service from this boot
[12:38] <zyga> (all restarts but the whole boot please)
[12:40] <ogra_> zyga, https://paste.ubuntu.com/p/QVp4vpKg44/
[12:41] <zyga> is that since boot?
[12:42] <ogra_> yes
[12:42] <ogra_> i dont reboot that often (perhaps once a month or so)
[12:42] <ogra_> no reboots since we started talking ...
[12:55] <zyga> jdstrand: I sent classic-snap-analyzer to the store
[13:01] <zyga> jdstrand: https://forum.snapcraft.io/t/request-for-classic-confinement-classic-snap-analyzer/5057
[13:04] <zyga> https://www.irccloud.com/pastebin/TazWgkcg/
[13:07] <zyga> Chipaca: hey, standup?
[13:07] <Chipaca> zyga: meeting
[13:07] <zyga> ack, thanks
[13:08] <Chipaca> … and now I'm being called to the school
[13:12] <jdstrand> zyga: ack, approved. you still need to release to a channel
[13:12] <zyga> thanks
[13:22] <pstolowski> kyrofa: hey! can you help answer the question in the comments there https://github.com/wekan/wekan-snap/issues/45#issuecomment-383090374 ?
[13:24] <zyga> roadmr: is there a way to set "package title" from snap.yaml?
[13:25] <roadmr> zyga: mmm....
[13:26] <roadmr> what's even the title? is it the summary?
[13:27] <zyga> no
[13:27] <zyga> can you look at the snap "classic-snap-analyzer" in the store
[13:27] <zyga> It has a title now, "Classic snap analyser"
[13:27] <zyga> (z)
[13:27] <roadmr> oh
[13:27] <zyga> which is separate from summary and description
[13:27] <zyga> I didn't know that before
[13:28] <roadmr> zyga: I didn't either! ooh
[13:28] <zyga> magic :D
[13:28] <zyga> sergiusens: ^
[13:28] <zyga> niemeyer: ^ :) (what is a package title?)
[13:28] <roadmr> zyga: got the URL? I can't seem to find it :(
[13:29] <roadmr> zyga: oh nm found it
[13:31] <roadmr> zyga: don't you have an "Edit name" control next to that name?
[13:32] <zyga> yes, I edited the name already
[13:32] <roadmr> zyga: it's the "name", not the "package_name" attribute
[13:32] <zyga> well
[13:32] <zyga> the title
[13:32] <roadmr> right internally I see it as "name"
[13:33] <roadmr> its description is "application name"
[13:33] <zyga> roadmr: right, I wonder how this maps to snapcraft concepts
[13:33] <zyga> it is different from snap name
[13:33] <zyga> which is immutable there
[13:33] <roadmr> yeah
[13:33] <zyga> popey: https://forum.snapcraft.io/t/call-for-testing-and-usage-classic-snap-analyzer/5058
[13:33] <zyga> sergiusens: ^ FYI :)
[13:33] <popey> zyga: that post needs more words, to explain whats good or bad about the output :)
[13:34] <zyga> popey: suggestions welcome, can you tell me what you mean?
[13:34] <popey> at the moment it reads like "here's a thing that tells you something I know about but you don't"
[13:34] <popey> why should I care? (as a snap maker)
[13:34] <zyga> aha
[13:34] <zyga> indeed
[13:34] <zyga> well :)
[13:36] <zyga> popey: I updated the description
[13:36] <zyga> I can make the post into a wiki if you want to wordsmith it more
[13:37] <om26er> @popey: regarding sublime text install count, I only tweeted about it, thought didnt see any to that. Probably some blog picked that up.
[13:38] <om26er> *though
[13:41] <oSoMoN> jdstrand, hey, does this denial look any familiar to you? https://forum.snapcraft.io/t/libreoffice-6-0-3-not-so-stable/5032/16
[13:44] <kalikiana> re
[13:50] <jdstrand> oSoMoN: https://forum.snapcraft.io/t/libreoffice-6-0-3-not-so-stable/5032/17
[13:51] <oSoMoN> jdstrand, thanks!
[13:52] <oSoMoN> that makes sense, libreoffice wants to create a lock file next to the saved file, and the home interface doesn't allow that in $HOME (but it does in subdirectories)
[13:53] <jdstrand> oSoMoN: yeah. makes sense, but this sounds like an icky bug for you :\
[13:53] <jdstrand> I mean, you can patch it of course, but bummer
[13:53] <oSoMoN> yeah
[13:54] <oSoMoN> well at least understanding the issue and filing a bug report to track it is a good start
[13:54] <oSoMoN> and I didn't know of aa-decode, so I learnt something new today, that's a good day :)
[13:55] <niemeyer> zyga, roadmr: The title is a more unrestricted snap name
[13:56] <niemeyer> May be non-unique, may have spaces, typically capitalized
[13:56] <niemeyer> Foo Bar
[13:56] <roadmr> interesting :)
[13:56] <niemeyer> "title" is the field in snap.yaml
[13:57] <niemeyer> It was incorrectly used by gnome-software for some time as if it was a summary, which created some unfortunate data corruption
[13:58] <jdstrand> oSoMoN: :)
[14:08] <zyga> hmm
[14:08] <mup> PR snapd#4509 closed: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
[14:08] <zyga> classic-snap-analyzer has a license specified both in the store and in the yaml
[14:09] <zyga> and yet it shows up as "unknown" in gnome-software on 17.01
[14:10] <zyga> and shows no icon on bionic
[14:10] <zyga> hmm
[14:10] <zyga> on the other side bionic shows the license correctly
[14:12] <mborzecki> zyga: isn't that handled by snapd glib wrapper?
[14:12] <zyga> it is
[14:13] <zyga> it's okay now, maybe the data was stale for a while?
[14:13] <zyga> try it :)
[14:13] <zyga> the screenshot is very blurry
[14:13] <zyga> not sure what's wrong there
[14:14] <zyga> but I found a bug :-)
[14:14] <zyga> going to the channel I can see buttons to switch to candidate, beta or edge
[14:14] <zyga> but this snap only has stable
[14:15] <zyga> so ...
[14:44] <kyrofa> pstolowski, done, thank you for reaching out :)
[14:46] <zyga> popey: around?
[14:46] <popey> hello
[14:47] <zyga> popey: can you refresh classic-snap-analyzer to beta
[14:47] <zyga> and try the interactive mode
[14:47] <zyga> just pin it
[14:48] <zyga> run it then click on a window of any snap
[14:48] <zyga> it doesn't work on wayland I think
[14:48] <zyga> but works on X
[14:48] <popey> like any sane person, I don't use wayland
[14:48] <zyga> or it may
[14:48] <zyga> but I need to handle some errors when screen grab fails
[14:49] <zyga> :-)
[14:49] <popey> Selected window does not belong to a snap application
[14:49] <popey> this is a lie
[14:49] <zyga> oh
[14:49] <zyga> what did you try it on?
[14:49] <zyga> I'm getting the pid of the process
[14:49] <popey> slack
[14:49] <zyga> then look at the environment
[14:49] <zyga> checking
[14:49] <zyga> oh, indeed :D
[14:50] <zyga> tricky bastard ;)
[14:50] <zyga> thanks, I will keep looking
[14:50] <popey> :D
[14:50] <zyga> but there's progress
[14:51] <zyga> woah
[14:51] <zyga> it seems that slack is erasing its environment block
[14:51] <zyga> it's all zeros
[14:51] <zyga> that's interesting
[14:51] <zyga> well, I can test for that
[14:52] <zyga> this is why I published to beta :)
[14:52] <pstolowski> kyrofa: thank _you_!
[14:53] <popey> zyga: might want to think about that wording. indicating "breakage" when someone is using everything as designed isn't a good PR message
[14:55] <zyga> popey: as designed?
[14:55] <popey> the developer of the snap is using tools we made to build a snap. to imply breakage when using our tools isn't a good message
[14:55] <zyga> but it's true
[14:56] <zyga> our tools are imperfect
[14:56] <zyga> our users suffer
[14:57] <popey> Fix them
[14:57] <popey> Don't tell users *they* did something wrong when *our* tools are broken.
[14:57] <popey> Its completely wrong.
[14:58] <zyga> I don't think it can ever be perfect, it's a tough game, I'm not making the tools; I just made _a_ tool that allows anyone to inspect the problem
[14:58] <zyga> it will always be a catch-up game
[14:59] <popey> I'm not going to spend the afternoon arguing with you about the wording in an expert tool, but I strongly recommend you think more about the perception you're giving people _we_ speak to on a daily basis.
[14:59] <zyga> popey: ok, what would you suggest I say instead?
[15:00] <zyga> is this about the tone or the message in general?
[15:00] <popey> Firstly, who is the target audience, and what's the goal of the application?
[15:01] <popey> What message do you want to convey? "Hey, we can help you improve stability / reliability of your application with our cool utility"
[15:01] <popey> not "hey, our shit is broken, use this tool to find out how"
[15:01] <zyga> the target audience is an author of a classically confined snap
[15:01] <zyga> the goal is to allow detecting when the app only works because it uses a host library without anyone noticing because said library is on the developer's machine
[15:02] <popey> Tested with the code-insiders snap and it worked
[15:02] <popey> spat out a list of libraries.
[15:04] <zyga> so again, I'm happy to reword it to make that goal clear
[15:06] <popey> IMO it needs to clearly describe the problem, or potential problem, and outline how it can be resolved.
[15:07] <popey> rather than hand-wavy "its broken dude"
[15:08] <zyga> ack, I will try to rewrite the text around the app
[15:08] <popey> <3
[15:27] <mcphail> I'm being offered a snapd update from 2.29.4.2 to 2.32.3.2. Is this one which will fix the issue where I have to add process-control to some of my snaps to get sound working? It'll be cool if I can promote one of my games to stable, as it is waiting on that fix
[15:29] <zyga> popey: refresh please :)
[15:29] <zyga> mcphail: try it, I think that's the one
[15:30] <zyga> mcphail: we switched off SIGKILL on seccomp
[15:30] <zyga> mcphail: also try candidate which has more bug fixes (2.32.5) and will be in stable next week
[15:30] <zyga> popey: check if the reworded message is more useful
[15:31] <popey> mcphail: yes, 2.32* is the good snapd we have all been lusting for :)
[15:31] <mcphail> Brilliant! Cheers chaps
[15:32] <popey> zyga: hah, i get a different list of libraries now. much better text too, thank you!
[15:32] <zyga> yeah, I fixed some issues too
[15:32] <zyga> plus, it's really variable
[15:32] <popey> maybe put the forum link and docs before you click on a window?
[15:33] <popey> Because its a bit odd to be told how the app works after you have used it :)
[15:33] <zyga> but if you suspect something is super broken  please report that
[15:33] <zyga> ah
[15:33] <zyga> sure
[15:33] <zyga> good point :)
[15:40] <zyga> popey: refresh :)
[15:40] <zyga> provide feedback on the forum, I need to break and hop on a bike before the sun sets
[15:40] <zyga> popey: if you are happy with the output I can promote to stable
[15:41] <popey> refreshing
[15:42] <popey> sometimes snap refresh hangs for me for nearly a minute
[15:42] <popey> doesn't produce any output
[15:42] <popey> zyga: that's much better, thanks.
[15:44] <Son_Goku> zyga, can you look into this? https://bugzilla.redhat.com/show_bug.cgi?id=1570076
[15:44] <popey> i am installing fedora 28 right now to reproduce
[15:44] <Son_Goku> okay, cool, thanks popey
[15:45] <Son_Goku> I'm still working, so I can't do anything right now :(
[15:46] <zyga> I need to break now, I've been here all day
[15:46] <zyga> but yes, I will definitely look into this
[16:19] <mcphail> \o/ sound is working! Many thanks
[16:50] <popey> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1570076 - i left a comment - i can't reproduce it
[16:56] <zyga> popey: on a bije
[16:56] <zyga> Bike
[16:56] <popey> :)
[17:32]  * cachio afk
[17:45] <mup> Issue snapcraft#2093 opened: manifest.yaml does not indicate the release the snap was built on <Created by jdstrand> <https://github.com/snapcore/snapcraft/issue/2093>
[17:48] <jdstrand> ratliff: fyi ^ bug. I can assume xenial and most things will be ok, but we'll need to adjust when that is fixed
[18:59] <sergiusens> jdstrand: it seems that if you use refresh-mode or stop-mode, it needs to come with a daemon entry for the app
[18:59] <sergiusens> not sure you are verifying that in the review tools
[18:59] <jdstrand> sergiusens: yes, and I am
[18:59] <jdstrand> sergiusens: thanks for mentioning it
[19:00] <sergiusens> jdstrand: great then!
[19:11] <seb128> popey, on that fedora/snap bug you might want to ask for the XDG_DATA_DIRS value and if they use xorg/wayland session, also the .desktop are in /var/lib/snapd/desktop so worth asking the content of that dir
[19:12] <seb128> I would comment but it requires an account and I don't have one
[19:12] <mup> PR snapcraft#2094 opened: storeapi: better handle network errors and retries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2094>
[19:42] <popey> seb128: yeah, i checked the XDG_DATA_DIRS myself
[19:42] <popey> oh, they need to check, i see :)
[19:50] <om26er> whats the difference between ubuntu-core/current and /stable ?
[19:50] <om26er> http://cdimage.ubuntu.com/ubuntu-core/16/current/
[19:51] <om26er> and /stable
[19:52] <om26er> also, will there be a UbuntuCore 18, if so how will it be different from a fully update Core16 ?
[21:21]  * cachio EOW
[22:10] <mup> PR snapcraft#2092 closed: schema: allow refresh-mode and stop-mode <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2092>