=== benfrancis0 is now known as benfrancis
[05:56] <mborzecki> morning
[05:57] <zyga-mbp> hey mborzecki 
[05:57] <zyga-mbp> how are you doing? :)
[05:57] <zyga-mbp> happy Thursday
[06:08] <mborzecki> zyga-mbp: hey, yeah finally thursday, just one more day
[06:09] <mardy> good morning mborzecki, zyga-mbp 
[06:10] <zyga-mbp> good morning mardy :)
[06:11] <mborzecki> mardy: hey, i've pushed an update to https://github.com/snapcore/snapd/pull/10860 and it looks like i fixed the sync & buffer corruption in tests 🙂 there's still a little problem with that signal thingy being null sometimes, haven't really seen it on real dbus, so i'm guessing it's something about partial reads in the tests
[06:11] <mup> PR #10860: sandbox/cgroup: wait for start transient unit job to finish <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10860>
[06:12] <zyga-mbp> woah, nie
[06:12] <zyga-mbp> *nice
[06:22] <ares0128> Hi, i want to create an agent which manages the snap updates. to do that i would need to connect to snapd-control slot. But how do i use it? I read that it is using javascript file. But i have no idea how to use it. Could some one help me.
[06:23] <zyga-mbp> ares0128 there's some logic that makes snapd go to managed mode and disable auto-updates
[06:23] <zyga-mbp> then you have to call the snapd APIs to issue specific requests, like update that snap or all snaps
[06:23] <zyga-mbp> whenever your software decides
[06:23] <zyga-mbp> there's a bit of guard-rails around that feature, it's meant for core devices only 
[06:25] <ares0128> i tried following this https://github.com/dbruno74/node-red-node-snapd and https://github.com/madintec/snapd-control
[06:25] <ares0128> but i dont know how to use these files
[06:25] <ares0128> yeah i am making a snap for ubuntu core
[06:25] <zyga-mbp> ares0128 that secodn thing is just a library, if you need javascript you can use it but that's not the point
[06:26] <ares0128> how do i call snapd APIs 
[06:26] <zyga-mbp> snapd has a socket
[06:26] <ares0128> it is through /run /snapd.socket
[06:26]  * zyga-mbp and a Go library to talk to it
[06:26]  * zyga-mbp the protocol is basically http over unix socket
[06:26]  * zyga-mbp the snap command actually talks to snapd over that socket
[06:26]  * zyga-mbp for snaps there's a second socket that lets snapctl talk to snapd 
[06:26] <ares0128> is there an example snap that i can refer to?
[06:26] <zyga-mbp> snapctl is the thing that snaps can use internally to manage parts of themselves
[06:27] <zyga-mbp> I don't recall but I'm sure there's something in the snapd test suite
[06:29] <zyga-mbp> ares0128 https://github.com/snapcore/snapd/blob/master/tests/main/interfaces-snapd-control-with-manage/task.yaml#L71
[06:29] <zyga-mbp> ares0128 you get a snap with snapd-control
[06:29] <zyga-mbp> you can set the snap set setting "system refresh.shedule" to "managed"
[06:30] <zyga-mbp> and from there on you can just use snap to tell snapd to do things
[06:30] <zyga-mbp> I think you can literally bundle the snap command as a quick test
[06:31] <zyga-mbp> typically there are management agents implemented in whatever language
[06:32] <zyga-mbp> they talk to snapd either through the go binary
[06:32] <zyga-mbp> or through the C library 
[06:32] <zyga-mbp> or through the Go library
[06:32] <zyga-mbp> there are official libraries to talk to snapd
[06:32] <zyga-mbp> and perhaps several unofficial ones 
[06:32] <zyga-mbp> but the bulk of the idea is that you switch refreshes to managed and then you drive the refreshes yourself
[06:33] <ares0128> so , i make a snap using go library that talks to snapd and chage the refresh to ,managed...
[06:37] <mardy> mborzecki: the Read() and Write() method of the testDBusStream, can they be invoked on the same object from two different threads?
[06:39] <mardy> (if so, you should protect that s.closed flag with a mutex)
[06:52] <zyga-mbp> and back :)
[07:00] <pstolowski> morning
[07:03] <mardy> hi pstolowski, mvo 
[07:03] <mvo> good morning mardy and pstolowski 
[07:03] <pstolowski> hey mardy and mvo
[07:08] <zyga-mbp> hey there pstolowski and mvo :)
[07:09] <mvo> good morning zyga-mbp 
[07:11] <mup> PR snapd#10844 closed: disks: add `Size(path)` helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10844>
[07:15] <pstolowski> hey zyga-mbp !
[07:16] <mup> PR snapd#10856 closed: osutil/disks: add Disk.KernelDevice{Node,Path} methods <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10856>
[07:49] <mborzecki> mardy: hm fixed that already with some refactor to Write() as the code wasn't correct, still no clue how we get that nil signal there, tbh i've been fighting with go modules at this point, modifyikg a forked library isn't exactly convenient now
[07:50] <mborzecki> mardy: can you take a look at https://github.com/snapcore/snapd/pull/10847 ?
[07:50] <mup> PR #10847: cmd/snap-confine: die when snap process is outside of snap specific cgroup <cgroupv2> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10847>
[07:52] <zyga-mbp> mborzecki small review
[07:52] <zyga-mbp>  /me is a bit afraid that tests.session is used so much in tests now
[07:52] <zyga-mbp> that thing is a gross hack
[08:26] <pstolowski> jamesh: https://github.com/stolowski/snapd/tree/notifications/monitor-closed
[08:26] <pstolowski> jamesh: the panic is in cmd/snap tests
[08:27]  * pstolowski dog walk, brb
[08:35] <pstolowski> re
[08:44] <jamesh> pstolowski: It's not clear that tomb.Context() does what we want here
[08:44] <jamesh> oh. maybe I'm wrong.  Let's see again
[08:46] <pstolowski> jamesh: fwtw just using context.Background() makes no difference as far as close panic is concerned
[08:47] <miguelpires> @mvo: can you merge https://github.com/snapcore/snapd/pull/10849 please? failures are unrelated AFAICT
[08:47] <mup> PR #10849: o/snapstate: prevent install hang if prereq install fails <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10849>
[08:47] <mvo> miguelpires: sure!
[08:49] <miguelpires> thanks
[08:51] <mup> PR snapd#10849 closed: o/snapstate: prevent install hang if prereq install fails <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10849>
[08:53] <jamesh> pstolowski: I think this is a bug in godbus
[08:53] <jamesh> and looks to still be a bug
[08:54] <pstolowski> oh
[08:54] <pstolowski> jamesh: as I said, maybe we could just not close() as a workaround
[08:55] <pstolowski> slightly bad, but we are exiting anyway
[08:55] <jamesh> If you call Conn.RemoveSignal(ch), then it is up to you to close the channel. If the D-Bus connection is closed, it closes all the signal channels
[08:56] <jamesh> I'm not sure how you could write correct code with those semantics
[08:58] <ogra> are there current known bugs with snap-device-helper ? i see a ton of errors on a pi4 (and how would i debug this ?)
[09:00] <ogra> https://paste.ubuntu.com/p/Qwr6NkD3d7/
[09:00] <ogra> (seems all related to the opengl interface)
[09:01] <ogra> (and i have to enforce SW rendering to make electron run (or use devmode))
[09:21] <jamesh> pstolowski: I filed https://github.com/godbus/dbus/issues/271 about the problem
[09:21] <jamesh> pstolowski: in the short term, leaving the channel unclosed with a comment pointing at that bug report is probably the best option
[09:22] <pstolowski> jamesh: awesome, thanks for digging into it and providing good explanation in the bug report!
[09:28] <zyga-mbp> jamesh nice one
[09:29] <jamesh> zyga-mbp: it'd be even nicer if I could think of a fix that wouldn't break compatibility...
[09:29]  * zyga-mbp jamesh I'm actually using that library as well; I'm in a bit of crunch mode before my release (6 weeks left) but I will think
[09:30] <jamesh> zyga-mbp: the best I can think of is to have a second version of RemoveSignal that closes the connection
[09:35] <zyga-mbp> jamesh would it be possible to use WIthSignalHandler and provide a different logic for AddSignal and RemoveSignal?
[09:35] <zyga-mbp> those seem to be dispatched with an interface
[09:36] <zyga-mbp> and ther's a way to set the signal handler per connection instance
[09:39] <jamesh> they abstracted a lot of things in godbus that they probably shouldn't have (e.g. serial number generation)
[09:39] <jamesh> but replacing the default implementation with one that implements different semantics seems like a bad idea
[09:45] <zyga-mbp> jamesh I wonder if upstream reacts quickly or not
[09:46] <zyga-mbp> there seems to be little traction 
[09:47] <jamesh> zyga-mbp: they've accepted pull requests from me, and I've helped review others. I think it is more a case of lack of time.
[09:47] <zyga-mbp> that's good then
[09:48] <jamesh> e.g. fixing the race conditions that used to exist in RemoveSignal
[09:51] <mup> PR snapd#10857 closed: osutil/disks: add Partition struct and Disks.Partitions() <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10857>
[09:53] <pstolowski> jamesh: i'm also now occasionally seeing [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x7ad006] on github.com/snapcore/snapd/desktop/notification.(*fdoBackend).processSignal(0xc0000c2820, 0x0, 0x0, 0x0, 0x0, 0x0) now in this code (after avoiding close), still a race somewhere
[09:54] <pstolowski> but maybe it's related to the new test i'm adding in usesession/agent
[09:58] <jamesh> pstolowski: I'm not sure. I didn't see any segfaults after removing the close() from what you'd posted earlier
[09:58] <jamesh> did it give you any more information than that?
[09:59] <pstolowski> jamesh: no, let's not worry about that right now, i may know more when I finish my test, may as well be a problem with my test code
[10:15] <mborzecki> https://github.com/snapcore/snapd/pull/10860 needs a 2nd review
[10:15] <mup> PR #10860: sandbox/cgroup: wait for start transient unit job to finish <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10860>
[10:16] <mborzecki> and https://github.com/snapcore/snapd/pull/10847 too
[10:16] <mup> PR #10847: cmd/snap-confine: die when snap process is outside of snap specific cgroup <cgroupv2> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10847>
[10:51] <mup> PR snapd#10853 closed: tests: use the latest cpu family for nested tests execution <Run nested> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10853>
[11:09] <mborzecki> zyga-mbp: https://build.opensuse.org/request/show/922347 if you have a minute
[11:31] <mup> PR snapd#10783 closed: [RFC, draft] tests: report stray tasks in spread test restore <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/10783>
[11:42] <zyga-mbp> mborzecki in a minute
[11:42] <zyga-mbp> mborzecki +1
[11:43] <mborzecki> thanks!
[11:43] <zyga-mbp> always a pleasure :)
[12:10] <mborzecki> this if fun: `c.Check(s.Stdout(), check.Matches, fmt.Sprintf(`(?sm)Usage:\s+snap %s(?: \[[^][]+\])*(?:(?: <[^<>]+>)+(?:\.\.\.)?)?$.*`, cmd), comment)`
[12:11]  * zyga-mbp I see robot emojis
[12:12] <mborzecki> zyga-mbp that's what more regexes look like
[12:12] <mardy> miguelpires: hi! I'm just pinging you to make sure you did see my comment on https://github.com/snapcore/snapd/pull/10836 (it's fine if you prefer the current implementation, just wanted to make sure you considered the alternative :-) )
[12:12] <mup> PR #10836: many: add experimental setting to move ~/snap to ~/.snap/data <Needs security review> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10836>
[12:22] <mup> PR snapd#10864 opened: mount-control: step 3 <⛔ Blocked> <Created by mardy> <https://github.com/snapcore/snapd/pull/10864>
[12:42] <mup> PR snapd#10865 opened: cmd/snap: improve snap run help message <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10865>
[12:49] <miguelpires> mardy: sorry, I meant to reply but then completely spaced. I replied now 
[13:52] <mup> PR snapd#10789 closed: tests: new test invariant to check no systemd user units running <Simple 😃> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10789>
[14:22] <mup> PR snapd#10789 opened: tests: new test invariant to check no systemd user units running <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10789>
[14:26] <pstolowski> mvo: could you please merge https://github.com/snapcore/snapd/pull/10846 ? unrelated failures
[14:26] <mup> PR #10846: desktop: implement gtk notification backend and provide minimal notification api <Created by stolowski> <https://github.com/snapcore/snapd/pull/10846>
[16:00] <mardy> is this the recommended way to mock interface connections, or is there another way which allows injecting a ConnectionState object? https://github.com/snapcore/snapd/blob/master/overlord/hookstate/ctlcmd/is_connected_test.go#L201-L208
[16:06] <pstolowski> mardy: yes that's how we do it
[16:22] <mup> PR snapd#10846 closed: desktop: implement gtk notification backend and provide minimal notification api <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/10846>
=== benfrancis0 is now known as benfrancis
=== mup_ is now known as mup
=== paulw2 is now known as PaulW2U
=== benfrancis4 is now known as benfrancis
=== paulw2 is now known as PaulW2U
[18:04]  * cachio_ akf
[18:04] <cachio_> afk
=== dbungert1 is now known as dbungert
[19:08] <mup> PR snapd#10866 opened: many: replace state.State restart support with overlord/restart <Created by pedronis> <https://github.com/snapcore/snapd/pull/10866>
[19:28] <mup> PR snapd#10858 closed: osutil/disks: add Disk.FindMatchingPartitionWith{Fs,Part}Label <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10858>
=== popey4 is now known as popey