[04:32] <mup> PR snapcraft#2733 closed: cmake plugin: support disable-parallel option <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2733>
[06:30] <mborzecki> morning
[07:03] <zyga> hey
[07:03] <zyga> I'm sick but I will try to get some work done today
[07:04] <zyga> no promises, it's a day off
[07:05] <pstolowski> mornings
[07:06] <mborzecki> zyga: pstolowski: hey
[07:07] <zyga> hey :)
[07:07] <mborzecki> zyga: why don't you type in /quit in your irc client ;)
[07:07] <zyga> I hate being sick
[07:07] <zyga> mborzecki, that's a good question
[07:07] <mborzecki> :P
[07:07] <mborzecki> heh :P
[07:08] <zyga> well, that was interesting
[07:25] <pedronis> pstolowski: 2.41+ has the unset option support ? or was it 2.40+ ?
[07:27] <pedronis> degville: pstolowski: I'm adding some mention of how unsetting work to https://forum.snapcraft.io/t/system-options/87 as well
[07:32] <pstolowski> pedronis: 2.41
[07:32] <pedronis> pstolowski: thx, it's what I used, were there bugs with it and system that we fixed only in 2.42 ?
[07:35] <pstolowski> pedronis: and thanks for updating the forum; nb i announced it before here https://forum.snapcraft.io/t/configuration-of-snaps-new-commands-for-unsetting/13118 and updated the docs (links in the annoncement)
[07:35] <pedronis> pstolowski: yes, I saw the new docs, but somebody at some asked in the system options how to unset them
[07:35] <pedronis> and we had some example at the top of how to set/get, so just added unset and ! there too
[07:36] <pedronis> anyway degville is free to tweak/remove if he deems it annoying
[07:38] <pstolowski> pedronis: yes, there was a bugfix for system i made on 11th Sep (so not in 2.41), but it was minor - you could unset unknown (unsupported) options and it wouldn't complain, whereas snap set errors out in such cases
[07:38] <pedronis> ok, thx
[07:39] <ogra> pedronis, moaning ... :) ... i assume there are no plans to turn Ubuntu Core into multi-user systems ? .... https://forum.snapcraft.io/t/passwd-command-error-in-app-snap/13408/7
[07:41] <degville> pedronis: thanks for letting me know about the updates! I'll take a look.
[07:51] <pedronis> degville: unrelated, did you see this: https://forum.snapcraft.io/t/is-snapd-forward-compatible-with-new-app-interfaces/10498/4
[07:57] <degville> pedronis: ah, thanks. I'll update the snap.yaml reference.
[08:04] <Chipaca> moin moin
[08:22] <zyga> degville: do you know who maintains https://ubuntu.com/download/iot/kvm ?
[08:24] <ogra> zyga, at the very bottom there is a "report a bug on this site" (most right option)
[08:25] <zyga> thanks!
[08:30] <pedronis> Chipaca: hi,  could you pin this from jdstrand for some reasonable time: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418
[08:30] <Chipaca> pedronis: how much is reasonable time?
[08:30] <Chipaca> a month?
[08:30] <Chipaca> six?
[08:31] <Chipaca> 3 years, like the first crusade?
[08:31] <mup> Bug #1626986 changed: snapd should allow snaps to define systemd unit alias names <snapd:Triaged> <https://launchpad.net/bugs/1626986>
[08:31] <mup> Bug #1627218 changed: snap refresh does not pull the latest betas <snapd:Incomplete> <https://launchpad.net/bugs/1627218>
[08:31]  * ogra hugs Chipaca .... i was really a bit lost with that passwd thread
[08:31] <pedronis> Chipaca: 3 weeks
[08:32] <Chipaca> pedronis: pinning until oct 21, ie the first monday after 3 weeks
[08:32] <pedronis> thx
[08:34] <mup> Bug #1627643 changed: oops on pi3 (seemingly wlan related) <Snappy:Invalid> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
[08:35] <Chipaca> pedronis: there's also "banner" topics which are even more prominent, fwiw
[08:36] <Chipaca> there can only be one banner topic, there can be multiple pinned ones
[08:36] <Chipaca> currently there are two globally-pinned topics; the other is the "welcome!" one
[08:36] <pedronis> Chipaca: ok, pinning seems fine though
[08:43] <Chipaca> pedronis: the policy PR always uses current for boot.InUse, which is wrong :-| need to change the api, probably
[08:43] <Chipaca> explicit revision needed or sth
[08:45] <degville> zyga: probably the web design team (sorry for the delay, I'm actually on a swap day and I've biked over to the cinema).
[08:53] <Chipaca> pedronis: ok, advice needed: currently (in the PR) CanRemove takes a boolean 'all'. What's actually needed is *either* that boolean, *or* the index into Sequence (or the revision meant to be removed, but the index makes it unnecessary to return a lookup error). I could: 1. add a parameter, 2. change the boolean to an index, -1 meaning all; 3. change the boolean to a *Revision, nil meaning all; 4. ad-hoc opts struct that would need validating and thus
[08:53] <Chipaca> add an error return. Leaning to (2) myself.
[08:53] <Chipaca> 5. somehting else i didn't think of :)
[08:54] <pedronis> Chipaca: variation on 2? pass a revision with unset meaning all?
[08:55] <pedronis> well really 2+3
[08:55] <Chipaca> pedronis: and add an error return / change it from returning bool to error, nil==ok (gives us error message) (feels like big api change, maybe squash the error and do the error return later)
[08:55] <Chipaca> yes this is stream-of-conciousness irc
[08:56] <pedronis> Chipaca: remember it's used in exactly one place
[08:56] <Chipaca> unset meaning all sgtm fwiw
[08:56] <pedronis> so I would add the error now
[08:57] <Chipaca> pedronis: we have a TODO to report *why* you can't remove, so I'd change it to return an error with the why while I'm at it
[08:57] <Chipaca> instead of the bool i mean
[08:57] <pedronis> ok
[08:57] <Chipaca> ok! on it
[08:57] <Chipaca> pedronis: is CanRemove still the right name for something that returns error?
[09:03] <mborzecki> hmm yum command line argument parsing seems broken
[09:03] <pedronis> Chipaca: we tend to use Check for those situations but I'm not sure we are super consistent, maybe grep ?
[09:03] <pedronis> I mean Check*
[09:03] <Chipaca> yah, will do
[09:04] <mborzecki> centos guys have pushed a systemd build that potentially fixes the issue we've been seeing, but passing --enablerepo=fasttrack in our pkgdb.sh seems to behave rather funny
[09:08] <Chipaca> sigh, need to tweak the api of boot.InUse :-)
[09:08] <Chipaca> more coffee first
[09:28] <mup> Bug #1632508 changed: Get a way to differentiate uninstall/shutdown from snap update in stop script <libvirt> <lxd> <openstack> <snapd:Triaged> <https://launchpad.net/bugs/1632508>
[09:28] <mup> Bug #1633111 changed: Missing API documentation for /v2/snaps/[name] POST <snapd:New> <https://launchpad.net/bugs/1633111>
[09:29] <zyga> Chipaca: is the REST api documented on the forum?
[09:29] <Chipaca> zyga: no, the wiki
[09:31] <zyga> Chipaca: the github wiki?
[09:31] <zyga> ah, I see it at https://github.com/snapcore/snapd/wiki/REST-API
[09:32] <Chipaca> zyga: and, it's always out of date :-|
[09:32] <Chipaca> but, it's a good place to start
[09:32] <Chipaca> zyga: why?
[09:33] <zyga> Chipaca: when spread churns I'm looking at bugs https://bugs.launchpad.net/snapd/+bug/1633111
[09:33] <mup> Bug #1633111: Missing API documentation for /v2/snaps/[name] POST <snapd:Fix Released> <https://launchpad.net/bugs/1633111>
[09:44] <mup> Bug #1635011 changed: /v2/changes/ is not documented in rest.md <snapd:Fix Released> <https://launchpad.net/bugs/1635011>
[09:44] <mup> PR snapd#7523 opened: sandbox/selinux: move SELinux related bits from 'release' to 'sandbox/selinux' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7523>
[09:45] <mborzecki> zyga: ^^^
[09:45] <zyga> mborzecki: ack
[09:47] <mup> Bug #1647139 changed: CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-12520/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/qucs-spice && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128
[09:47] <mup> http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 <build> <lp> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1647139>
[09:47] <zyga> mborzecki: +1
[09:47] <mborzecki> zyga: seccomp is the last bit that's still under release
[09:47] <mborzecki> not for long though :)
[09:50] <mup> Bug #1697770 changed: can't run juju from snap: "Too many levels of symbolic links" <snapd:Won't Fix> <https://launchpad.net/bugs/1697770>
[09:53] <mup> Bug #1740130 changed: Use XDG set profile folders <Snappy:Invalid> <https://launchpad.net/bugs/1740130>
[10:02] <pedronis> Chipaca: can help with those questions you sent in the PR? notice that gadget doesn't apper in any boot env stuff, so not sure how in use would help
[10:02] <Chipaca> pedronis: d'oh. ok, for gadget. What about kernel?
[10:02] <Chipaca> pedronis: we're checking both
[10:03] <mup> PR snapd#7524 opened: tests: add unit test for gadget defaults with a multiline string <Created by stolowski> <https://github.com/snapcore/snapd/pull/7524>
[10:03] <pedronis> Chipaca: both, what both?
[10:03] <pedronis> or which both?
[10:03] <Chipaca> pedronis: boot.InUse and model.Kernel
[10:04] <pedronis> that sounds ok
[10:04] <Chipaca> pedronis: isn't it redundant?
[10:04] <pedronis> doesn't InUse need a revision?
[10:04] <Chipaca> pedronis: yes
[10:05] <pedronis> so what if it's all
[10:05] <Chipaca> pedronis: (although i've modded it locally to take unset to mean 'any'
[10:05] <Chipaca> hmmm
[10:05] <Chipaca> maybe i've overcomplicated things then :-)
[10:05] <pedronis> yes
[10:05] <pedronis> likely
[10:05] <Chipaca> :-)
[10:06] <pedronis> if all,  check model,  if revision check in use
[10:06] <pedronis> something like that?
[10:06] <Chipaca> yeah, i'll make that explicit
[10:06] <Chipaca> just so i don't forget again
[10:07] <pedronis> core, boot base and kernel should have similar rules
[10:07] <pedronis> (except core has rules for classic too)
[10:26] <pedronis> pstolowski: I updated #7468 and answered sthe comments
[10:26] <mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
[10:26] <pstolowski> ty
[10:27] <zyga> ah
[10:27] <zyga> I learned something about mount namespaces just now
[10:27] <zyga> man that stuff is tricky
[10:27] <zyga> it's just super tricky
[10:28] <zyga> on the upside this is invaluable to fixing bugs
[10:28] <zyga> details shortly, let me write them down
[10:34] <mup> PR snapd#7522 closed: httputil: set user agent for CONNECT <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7522>
[10:36] <mborzecki> anyone with power to cherry-pick and push to 2.42?
[10:38] <zyga> 2.42 the branc?
[10:38] <zyga> anyone
[10:38] <zyga> the release? it's an SRU
[10:38] <zyga> I must misunderstand your question
[10:38] <mborzecki> zyga: hm afaik direct git push to the repo only works for mvo
[10:39] <zyga> oh, that's new then
[10:39] <zyga> I guess you can propose a PR instead
[10:39] <zyga> just target 2.42
[10:39] <mborzecki> mhm, opening right now
[10:39] <pstolowski> yeah, why not PR?
[10:39] <mborzecki> pstolowski: bc we don't need to run spread then
[10:40] <pstolowski> mborzecki: bad bad ;)
[10:40] <zyga> naughty :)
[10:40] <mup> PR snapd#7525 opened: tests: disable {contacts,calendar}-service tests on Arch Linux (2.42) <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7525>
[11:10] <Chipaca> pedronis: so... https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate_test.go#L11132
[11:10] <Chipaca> pedronis: i just broke that test :-|
[11:14] <Chipaca> granted it passed by accident before, but it feels like an actual case we want to work
[11:14] <Chipaca> that is: current boot kernel is not (no longer) the model kernel, you shouldn't be able to 'snap remove' it yet
[11:14] <Chipaca> actually could be no longer or not yet, either way
[11:22] <pedronis> Chipaca: sorry, how did it work before and how doesn't anymore?
[11:22] <Chipaca> pedronis: as per above, i no longer call boot.InUse if the revision is unset
[11:23] <Chipaca> pedronis: it worked up to this point because i'd use snapst.Current as the revision for InUse
[11:24] <Chipaca> pedronis: sounds like i do need to tweak boot.InUse to check any when unset (could be in a separate pr)
[11:24] <pedronis> Chipaca: I'm not sure that test make sense
[11:25] <Chipaca> that would make life easier :-)
[11:26] <mup> Bug #1845636 opened: connect-plug-i2c hook failing <Snappy:New> <https://launchpad.net/bugs/1845636>
[11:26] <pedronis> if there is a kernel-to-be in a remodel conflicts should prevent to remove it, toward the end of the remodel it becomes in use (at which point checking for any on the other side doesn't) and at the very end we atomically switch the model
[11:27] <pedronis> the current kernel  is still the one from the model except inside the remodel itself
[11:27] <pedronis> until the remodel is done
[11:27] <pedronis> at some earlier point as I said it stops to be in use
[11:28] <mup> PR snapd#7526 opened: cmd/snap-confine: allow digits in hook names <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7526>
[11:28] <pedronis> Chipaca: we let you remove by revision only non-current revisions no?
[11:29] <mup> Bug #1845636 changed: connect-plug-i2c hook failing <snapd:In Progress by zyga> <https://launchpad.net/bugs/1845636>
[11:29] <Chipaca> pedronis: correct
[11:30] <pedronis> Chipaca: it might be that we need to turn that description I just made into a set of CanRemove tests
[11:30] <pedronis> or really Remove tests
[11:30] <pedronis> that show you can remove what you expect at various points of the switching
[11:30] <Chipaca> with a remodel going on you mean?
[11:30] <pedronis> well doesn't mean to be a real one
[11:30] <pedronis> but to simulate something close enough
[11:31] <pedronis> afaict the test you pointed at doesn't correspond to a possible state
[11:31] <pedronis> (unless bugs)
[11:35] <mup> Bug #1638988 changed: Cannot run spread hello world on all-snaps image <snapd:Triaged> <https://launchpad.net/bugs/1638988>
[11:37] <Chipaca> zyga: don't we have an interface for lxc?
[11:38] <zyga> Chipaca: not one that would allow you to run lxc-the-command-line-tool
[11:38] <zyga> Chipaca: that's a general property btw
[11:38] <Chipaca> zyga: even if you shipped it?
[11:38] <Chipaca> zyga: just lxc, not lxd
[11:38] <mup> Bug #1638796 changed: mir clients that use cpu renderable surfaces don't work under confinement <snapd:New> <https://launchpad.net/bugs/1638796>
[11:39] <zyga> Chipaca: if you shipped it it might work but that's not what the bug is about
[11:39] <Chipaca> zyga: i've got my spread-snap-contributor hat on
[11:39] <zyga> Chipaca: casual combination of tools shipped as snaps is not supported
[11:39] <zyga> Chipaca: when that combination is packaged as a snap
[11:40] <zyga> Chipaca: if we expand spread to talk to lxc/d directly it's something to consider but I think that's not high priority
[11:40] <mup> PR snapd#7527 opened: interfaces/input: support confined snaps accessing keyboard and mouse directly <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7527>
[11:40] <Chipaca> zyga: i don't understand what you mean there
[11:40] <Chipaca> zyga: spread has an lxd backend
[11:40] <Chipaca> we already expect it to talk to it
[11:41] <zyga> Chipaca: yes but that backend just invokes lxc as a new process
[11:41] <zyga> Chipaca: if we agree on that, that's exactly what is not supported in snapd
[11:41] <Chipaca> zyga: right, so if we ship lxc in the spread snap, that should work if we get the interface
[11:41] <zyga> Chipaca: yes, that's correct
[11:41] <Chipaca> zyga: sounds like an easy win, i'll see if i find time to do it
[11:42] <zyga> Chipaca: if you want to, sure. I was just triaging old bugs as I wait for spread runs
[11:42] <zyga> Chipaca: IMO we should explore how not changing the spread snap to ship lxc could be supported
[11:42] <zyga> Chipaca: it's a more complex problem though
[11:42] <zyga> Chipaca: involving lots of variables like API stability of the cli, passing resources, observing children termination, etc
[11:43] <zyga> Chipaca: it would, however, allow us to handle this generally
[11:43]  * zyga looks at the next PR
[11:54] <zyga> Chipaca: IMO osutil.StreamsEqual is buggy
[11:54] <Chipaca> zyga: oh? do tell
[11:54] <zyga> Chipaca: it uses ReadAtLeast with a buffer size of 16K
[11:55] <zyga> ah, sorry
[11:55] <zyga> just scrolled down to see the error handling :E
[11:56] <Chipaca> zyga: you mean the one that comes right after the six-line comment explaining the situation?
[11:56] <zyga> yeah, I was scrolling down and reached the pair of ReadAtLeast
[11:56] <zyga> and got curious about the buffer size
[11:56] <zyga> anyway, go have lunch, sorry for the noise
[11:57] <Chipaca> 👋
[12:16] <mup> PR snapd#7528 opened: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>
[12:20] <pedronis> not quite simple but not too big ^
[12:20] <pedronis> something sergiusens pointed out
[12:46] <mup> PR snapd#7521 closed: [RFC] many: use --root as first arg to systemctl everywhere <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7521>
[12:56] <zyga> pedronis: I will skip the standup, conflict
[12:57] <pedronis> zyga: I will also be in the conflict
[12:57] <zyga> ok :)
[12:57] <pedronis> Chipaca will drive the standup today
[13:06] <sergiusens> Chipaca: wrt spread lxd, if you ship the lxc binary and your lxd backend is a non local remote, you don't need any interface
[13:07] <sergiusens> Chipaca: heh, using local would only require being able to talk to the socket
[13:18] <mup> PR snapcraft#2732 closed: project: use os.sched_getaffinity instead of multiprocessing.cpu_count <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2732>
[13:37] <zyga> jdstrand: can you please enqueue https://github.com/snapcore/snapd/pull/7421
[13:37] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
[13:37] <zyga> jdstrand: you reviewed that before, v2 is simpler and should be good-to-go
[13:38] <pedronis> zyga: I think he is swapping today
[13:38] <zyga> pedronis: yeah, I was just checking since he's away on IRC
[13:38] <zyga> that's fine
[13:39] <zyga> I'll ask next week
[13:58] <cwayne> kenvandine: ok so the fix did indeed seem to work, let us know if you run into any more issues (or whenever you want us to add new snaps :D)
[14:09] <mup> PR snapd#7526 closed: cmd/snap-confine: allow digits in hook names <Bug> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7526>
[14:48] <zyga> Chipaca: hey
[14:48] <zyga> Chipaca: I have a question about osutil/cmp_test.go
[14:48] <zyga> Chipaca: can you please look at TestCmp there
[14:49] <zyga> Chipaca: the buffer size is fixed but the payload (file size) varies
[14:49] <zyga> Chipaca: am I reading that right?
[15:08] <pstolowski> pedronis: i think failures on #7528 are real, tests/main/base-invalid-type needs updating
[15:08] <mup> PR #7528: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>
[15:08] <pedronis> pstolowski: quite possible
[15:09] <pedronis> but somebody just restarted it
[15:09] <pedronis> (not me)
[15:09] <pedronis> so I cannot look
[15:10] <pedronis> or I'm very confused
[15:10] <Chipaca> zyga: yes
[15:10] <zyga> Chipaca: thanks
[15:10] <zyga> I'm almost done with that PR
[15:10] <zyga> I removed my implemenetation
[15:10] <zyga> added one extra check into yours
[15:10] <zyga> and kept the set of tests
[15:10] <pstolowski> pedronis: hmm not me
[15:13] <pedronis> zyga: I moved the 'snap run --explain' notes to the forum: https://forum.snapcraft.io/t/snap-run-explain/13427
[15:13] <zyga> pedronis: nice, thank you
[15:14] <pstolowski> pedronis: the status is still visible: https://api.travis-ci.org/v3/job/590391360/log.txt
[15:14] <ijohnson> pedronis, pstolowski: not me either
[15:14] <pedronis> I was just confused by travis
[15:14] <pedronis> I see the problem now
[15:15] <pedronis> Chipaca: can CanRemove PR be reviewed again? or still WIP? (would not happen today)
[15:16] <zyga> pedronis: can I give it a stab at implementing a super-simple version of that over weekend? I'm going to stay at home sick anyway
[15:16] <zyga> pedronis: or would you rather give it to someone else
[15:16] <mup> PR snapd#7520 closed: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7520>
[15:17] <pedronis> zyga: how far are we from wrapping up robustness?
[15:18] <zyga> pedronis: I need some jamie time for the reviews, probably a day or so
[15:18] <zyga> pedronis: it is that and app awareness next week
[15:18] <zyga> pedronis: I think I can do new stuff now
[15:19] <pedronis> zyga: you could start to sketch --explain but might likely have to give it to somebody else to finish depending
[15:19] <zyga> ok
[15:19] <pedronis> it's lower priority than the other things on your plate
[15:19] <pedronis> basically
[15:19] <zyga> pedronis: ack
[15:21] <pstolowski> zyga: what's the plan re https://github.com/snapcore/snapd/pull/6174 ?
[15:21] <mup> PR #6174: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>
[15:22] <zyga> pstolowski: I'll fix it up next week
[15:22] <zyga> or perhaps today if I finish the pass over other PRs
[15:22] <zyga> pstolowski: needs some deconflicting/rebasing
[15:23] <pstolowski> ok, thanks
[15:27] <pstolowski> pedronis: btw my #7355 is redy for reviews again
[15:27] <Chipaca> pedronis: I recentl pushed to the canRemove pr, i think it's good to go but i thought so yesterday and then spread failed :-)
[15:27] <mup> PR #7355: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
[15:29]  * zyga -> lunch
[15:29] <pedronis> Chipaca: ok
[15:30] <pedronis> pstolowski: thanks, probably will look at it on Monday at this point
[15:30]  * ijohnson will miss TGIF, still in middle of reviewing 7355
[15:30] <pstolowski> ijohnson: take a break ;)
[15:30] <pstolowski> ijohnson: btw appreciate it!
[15:31] <Chipaca> pedronis: i just spotted a bug i think
[15:31] <Chipaca> pedronis: :-( i'll comment on it in case you get to review it before i fix it
[15:32] <Chipaca> at the very list it points to a missing test
[15:32] <Chipaca> least*
[15:32] <Chipaca> oh dear me
[15:35]  * Chipaca takes a break
[15:39] <Chipaca> ahem. For real now.
[16:18] <pedronis> pstolowski: I did this: https://github.com/snapcore/snapd/pull/7469/commits/700ce5a5d816c37901e686fd689f586b40dbc2e5 in the next PR
[16:18] <mup> PR #7469: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>
[16:22] <zyga> ondra: offtopic
[16:22] <zyga> ondra: I have a thing I wanted to show you
[16:23] <zyga> ondra: I wrote it earlier this week, perhaps it could be something useful to your team
[16:23] <zyga> ondra: check this out please https://gist.github.com/zyga/2210f334115645a0014e1ecce22a944c
[16:23] <zyga> ondra: it's a tool for extracting SD card image off a running system
[16:23] <zyga> ondra: and streaming it to a nearby computer
[16:24] <zyga> ondra: there's some "pre-preparation" step that's missing in the script itself (dd if=/dev/zero of=zero bs=4M; rm zero;) but we can consider polishing the script some more
[16:25] <pstolowski> pedronis: ty!
[16:25] <zyga> ondra: it works on core18, can easily work on core16 (I didn't try) and most importantly, on windows / linux / mac on the receiving end
[16:25] <zyga> ondra: so anyone can easily capture an image and send it for analysis
[16:25] <zyga> ondra: on windows just double-click on the script and continue (install python first)
[16:26] <zyga> ondra: on other systems it's more generic
[16:32] <ondra> zyga that looks interesting!
[16:33] <ondra> nice one
[16:34] <zyga> ondra: I have some more ideas to make it robust but I wanted to share a quick prototype with an user that needed it
[16:35] <zyga> Chipaca: I changed some code you wrote in https://github.com/snapcore/snapd/pull/7484 -- perhaps you could do a review over cmp.go there
[16:35] <mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
[16:36] <zyga> ondra: if you end up using it and give it a life please tell me :)
[16:38] <ondra> zyga we might use that as we go closer to production and need to debug special cases
[17:15] <Chipaca> zyga: I might take a peek over the weekend
[17:15] <Chipaca> right now, it's beer o'clock
[17:16] <Chipaca> meaning it's go-get-the-supermarket-stuff o'clock, first
[17:16] <Chipaca> put-the-pizza-in-the-oven o'clock
[17:16] <Chipaca> that kinda stuff
[17:16] <Chipaca> have a great weekend y'awl
[17:16] <Chipaca> ijohnson: you too, when your time comes
[17:16] <Chipaca> :)
[17:16] <Chipaca> 👋
[17:18] <mup> PR snapd#7528 closed: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7528>
[17:41] <mup> PR snapd#7529 opened: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/7529>
[17:47] <zyga> pedronis: I was about to look at 7529 but I think I am too tired today
[18:02] <mup> Bug #1639984 changed: Granting incorrect access in the shutdown interface in snapd <snapd:Triaged> <https://launchpad.net/bugs/1639984>
[18:02] <mup> Bug #1640281 changed: Conflict - Telemetry project, Snap, uses snapd and snapctl <snapd:Triaged> <https://launchpad.net/bugs/1640281>
[18:05] <mup> Bug #1641752 changed: request for snap interface that expose userspace device APIs <snapd:Confirmed> <https://launchpad.net/bugs/1641752>
[18:07]  * zyga stops triaging bugs and EODs
[18:07] <zyga> it's 8PM anyway ...
[18:07] <zyga> ttyl, enjoy your weekends everyone
[18:08] <mup> Bug #1640114 changed: configure hook output not accessible <snapd:Confirmed> <https://launchpad.net/bugs/1640114>
[18:08] <ijohnson> bye zyga, hope you feel better
[18:08] <zyga> ijohnson: thank you :)
[19:48] <pedronis> zyga: that one is simple in itself but is at the end of a long chain
[20:57] <joedborg> afternoon all, i'm still having trouble debugging my configure hook - is there anyway I can see the output of the hook (snapd seems to swallow -x and echos etc)
[20:57] <joedborg> and  it's not shown in the snapd journal
[20:58] <ijohnson> joedborg: unfortunately no, not unless your configure hook exits with exit code 1
[20:58] <ijohnson> but if it always does that, then you can't install the snap
[20:59] <joedborg> ijohnson: can i run it within a snap shell? `sudo snap run --shell`
[21:00] <joedborg> ijohnson: ah yes, looks like i can :)
[21:01] <ijohnson> yes you should be able to
[21:05] <joedborg> ijohnson: is there any plan to be able to float errors / feedback from hooks?  if not, I might raise an LP
[21:10] <ijohnson> no not really, hooks aren't really meant for that kind of thing, but feel free to file an LP bug
[21:15] <ijohnson> joedborg: actually what you're looking for are snap warnings, see https://forum.snapcraft.io/t/warnings/7599
[21:17] <joedborg> ijohnson: that looks promising, but i need more immediate feedback for validating of `snap set`
[21:21] <joedborg> ijohnson: i guess the set-health is the best way
[21:34] <ijohnson> joedborg: well if you are validating snap set, couldn't you just exit1 if it's wrong?
[21:34] <ijohnson> then the user sees the output
[21:36] <joedborg> ijohnson: yeah, i've got with `set-health` as it's more about getting 2 required configs set (as well as validating).  i have noticed that there's no record of `blocked` message in `snap warnings`