=== pbek_ is now known as pbek [07:00] Mornings [07:56] hey ho [07:57] let's go [08:06] morning :-) [08:06] overcast but warm today [08:07] Chipaca: I wrote down my thoughts on daemon-notify: https://forum.snapcraft.io/t/its-a-little-bit-hard-to-use-daemon-notify-for-sd-notify/6366 === alan_g|EOD is now known as alan_g [08:07] also did a tweet storm on twitter :) [08:07] zyga: I saw your tweets [08:07] zyga: also yesterday's [08:07] zyga: keep it up :-) [08:07] thank you for the encouragement :) [08:07] I was wondering if those are useful [08:08] and how long I will keep it up [08:12] uh, Guido resigned from Python [08:12] that's a biggie [08:13] zyga: he got his calendar wrong, it's not april 1 [08:13] maybe it's some crazy dutch version of april fool's [08:13] I envision he will pick up gardening now [08:13] or sheep [08:13] like april fool's but more racist [08:14] so, the bottom line is [08:14] if you do something for fun and love [08:14] don't let others tell you how [08:14] I cannot imagine how he must feel [08:16] zyga: and now you know why snapd team doesn't have a line manager [08:42] zyga: is there any particular reason you're doing long tweet threads rather than blog posts recently? [08:43] popey: experimenting with the format mainly [08:43] If you collated those tweets together, they'd probably make great blog posts for snapcraft.io/blog [08:43] popey: I may do both actually, since the text can live in two places [08:43] mmm, I can do that [08:43] we'd love to have more content there which is technical and approachable [08:43] I'll do a hybrid twitter/blog post today and we can see how that can show up on snapcraft.io [08:44] we make quite a bit of effort to get the blog posts out there. your tweets will die overnight, "nobody" will see them [08:44] the blogs will live on, and can be re-shared (if they're evergreen) [08:44] evergreen? [08:44] timeless [08:45] ah [08:45] well afaiu zyga's is tweeting about work in progress work [08:45] yes, it's not the kind of post to return in 3 weeks [08:45] right, some are, some aren't [08:45] but yeah, it's easier to read on a blog so I will aggregate as posts as well [08:45] all code will be written and deleted and then rewritten (maybe) [08:45] but putting it on twitter from an account nearly nobody follows means nobody sees it [08:46] if the goal is just braindump fair enogh :) [08:46] I refreshed https://github.com/snapcore/snapd/pull/5307 [08:46] but if you want the content out there, I'd encourage blogging and working with us to promote them :) [08:46] PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional [08:46] it should go green soon [08:46] popey: I want it out there, it was just me experimenting with the format really [08:47] and as evening memory save for tomorrow (but a blog does that too) [08:47] :) gotcha [08:48] and thank you for noticing, this is important to me [08:48] <3 [09:37] pstolowski: hey [09:37] do you need https://github.com/snapcore/snapd/pull/5433 ? [09:37] PR #5433: interfaces/repo: added AllHotplugInterfaces helper [09:37] or has that changed since we discussed last? [09:38] Chipaca: last chance to see https://github.com/snapcore/snapd/pull/5446 in case you want before I merge it [09:38] PR #5446: coreconfig: add support for `snap set core network.disable-ipv6` [09:38] it's green and has +2 [09:39] zyga: that should be 'system' though, right [09:39] in any case, go for it [09:39] should it? [09:39] I can chance it to system [09:39] zyga: I mean, in user-facing docs [09:39] ahh [09:39] I see what you mean now [09:40] zyga: yes i need it, it's independent of udev bits we discussed [09:40] I misunderstood that as "snap set core system.disable-ivp6" [09:40] zyga: internally right now it's core, but system is what we should talk about because system is core now but coreXYZ later [09:40] Chipaca: totally agreed [09:40] Chipaca: I will tweak the spread test [09:41] in a world of iot customers ask for an off switch for ipv6 [09:44] in some distant future the core snap version 1664 will be easy to confuse with 16-64 but perhaps nobody will use embedded 64bit address space anymore [10:10] Chipaca: I added a test for system snap for the ipv6 config now, thank you! [10:10] I will merge when green [10:11] zyga: 🆗 [10:12] zyga: or should I say 🆗👌💯 [10:25] I feel emoji deficient now [10:28] * zyga is enjoying fresh coffee [10:29] pressure must be low today, I'm more sleepy than usual [10:53] PR snapd#5505 opened: interfaces/hotplug: udevadm output parser [10:55] PR snapd#5506 opened: cmd/snap: add a green check mark to verified publishers [10:57] ^^^ look maw, it's terminfo's stupid inbred cousin! === pstolowski is now known as pstolowski|lunch [11:43] * zyga forgot to eat breakfast today [12:04] Break === pstolowski|lunch is now known as pstolowski [12:21] Mmmm, I feel tired somehow [12:21] pedronis: what do think about the branch? [12:21] zyga: what branch? [12:22] The remapping one [12:22] zyga: I added comments there [12:22] a while ago [12:22] Oh, super. Let me look [12:22] Thank you! === Guest28394 is now known as devil__ [12:25] Replied just now [12:27] I will deal with the coffee and add mapper that returns system in the API layer. We may need to differentiate the state and API mappers though, to keep rollback around (so that state is always mapping “snapd” to “core” on disk) [12:28] This is also a chance to rename the incoming outgoing words [12:28] To do explicitly talk about state loading/saving and API requests/responses [12:29] in test-snapd-tools.publisher expected 'canonical', got 'Canonicalâœ“' [12:29] I�Unicode [12:29] Woah? [12:29] Hehehe [12:29] But ... why? [12:29] zyga: why what? [12:29] Is the real value ascii [12:29] Why did it get corrupted [12:30] zyga: answering that requires investigation [12:30] zyga: did the python checker get it wrong? did the log print it wrong? is the browser using the wrong encoding? etc etc [12:31] Because software sucks and we’ll all pick up gardening instead ;-) [12:31] I vote for python [12:31] zyga: I name myself BGFL [12:32] Since Guido left python started throwing Unicode errors on all 7 bit ascii values [12:32] zyga: for _this_ one, my money is on the browser [12:32] Dead hand system (aka dead snake) [12:32] zyga: confirmed, it's the browser; log file is fine [12:32] in test-snapd-tools.publisher expected 'canonical', got 'Canonical✓' [12:34] HAH! suse's default locale is not UTF-8ish [12:34] for suse: in test-snapd-tools.publisher expected 'canonical', got 'Canonical*' [12:39] PR snapd#5498 closed: snap: support hook environment [12:39] obs-build defaults to POSIX / C, even though openSUSE itself defaults to C.UTF-8 [12:39] zyga, Chipaca ^ [12:40] King_InuYasha: I wonder why our spread box isn't getting that one [12:40] * Chipaca spins it up to check [12:42] one of the reasons very recent python has the automatic UTF-8 upgrade stuff [12:49] hmm [12:49] bad restore codE? https://www.irccloud.com/pastebin/d59S4fs6/ [12:51] PR snapd#5504 closed: interfaces/pulseaudio: be clear that the interface allows playback and record [12:51] King_InuYasha: in opensuse 42 that we run spread on in GCE, LANG=POSIX, with just LC_CTYPE=en_US.UTF-8 [12:51] what even is LANG=POSIX [12:52] 'in the lang of posix where the standards lie [through their teeth]' [12:57] that definitely needs to be POSIX.UTF-8 :P [12:57] how else would you get standardized umlauts [12:57] PR snapd#5494 closed: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs [13:06] Chipaca: POSIX is an alias for C [13:57] niemeyer: can you add https://forum.snapcraft.io/t/tio-request-for-classic-confinement/6209 to your list of considerations for classic? [13:58] jdstrand: Of course, thanks [13:58] thanks [13:58] hi. is it possible to change the mode (jailmode/devmode/classic) of an installed snap ? [14:00] smoser: it is not [14:00] smoser: well [14:00] smoser: 'snap refresh' can do it [14:00] smoser: but 'snap switch' cannot [14:00] smoser: why? [14:01] jsut curious mostly. [14:01] https://github.com/smoser/pdftk/issues/1 [14:01] one solution to that is to instlal with --devmode (i think) [14:02] smoser: devmode stops you from getting updates though [14:02] smoser: that won't work cause devmode also uses the mount namespace and snap-specific /tmp [14:02] heh, and what jdstrand said [14:02] right. [14:03] smoser: what i've done when I had things in tmp is use bash's <()'s [14:03] thanks jdstrand . so the only solution there is "don't use /tmp" [14:04] smoser: so instead of pdftk infile outfile, pdftk <(cat infile) >(cat > outfile) [14:05] well the snap should be able to write to its stdin and stdout anyway [14:05] so you shouldnt need the (cat) [14:05] smoser: ah, if pdftk handles stdin/stdout, sure [14:05] just snap-program /tmp/my-output [14:06] you might want to double-check that, since apparmor revalidates access to open fds [14:06] i yeah.. i hit that somewhere. it works sometimes. [14:06] so it's at least potentially the sort of thing that might not work even though it feels like it should [14:06] zyga: can you take a look at #5451? [14:06] i went looking for where i found it. thought i reported it, cbut coudnt find it. [14:06] PR #5451: interfaces: honor static attributes when reloading conns [14:09] https://bugs.launchpad.net/snappy/+bug/1766667 [14:09] Bug #1766667: commands in a container cannot write to inherited filehandles such as stdout [14:09] is that in the worng place ? [14:11] smoser: i'll move it to snapd, but no [14:11] smoser: (snappy is the catchall for snapd + snapcraft + etc etc, in lp) [14:13] I'll leave it to jdstrand to figure out if it's actually snapd or lxd-in-a-snap or what :-) [14:14] Bug #1766667 changed: commands in a container cannot write to inherited filehandles such as stdout [14:49] pstolowski: yes [14:51] * Chipaca afk for a bit [15:03] pedronis: hey, I updated https://github.com/snapcore/snapd/pull/5491 [15:03] PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd [15:03] I swiched the helpers to be functional now [15:03] switched* [15:03] I'm looking if we can cheaply translate differently inside and outside to get "core" in state, "snapd" in memory and "system" in the API [15:03] I think so, just making the changes now [15:04] zyga: ok, thank you [15:10] pedronis: question on api naming: [15:10] https://www.irccloud.com/pastebin/0wawqbLN/ [15:11] I tried to come up with useful names for the state vs api remappers [15:11] what do you think? [15:12] pedronis: basically I'm open to suggestions as I'm making that change anyway [15:13] the names seem reasonable [15:15] great, I'll run with those, thank you [15:24] How do I list all files in all snaps in the database? [15:24] is there a database I can download? [15:25] (like apt-file/apt's Contents.gz) [15:31] scientes: there is not currently a manifest such as that [15:32] scientes: what for? [15:33] command-not-found [15:33] there is definitely nothing client side like Packages.gz (or the apt list files which are the local equivalents), this is all handled store side [15:33] scientes: what about command-not-found? [15:34] scientes: (we already have commant-not-found integration) [15:34] when I rewrote it ( https://github.com/shawnl/command-not-found/ ), there was comments that it should support snap [15:34] I re-wrote it to avoid the python dependency [15:34] scientes: oh! hi :-) [15:36] scientes: the person that did the majority of the integration with cnf is away this week [15:36] i'll look at the source [15:36] scientes: but, not command-not-found itself has grown support for being extended [15:36] scientes: and snap uses that extension point [15:36] oh i c [15:36] I say "has grown", but we were instrumental to that growth [15:37] does it increase the latency, given that it has to make a network request for every command_not_found hook? [15:37] scientes: it does not have to make a network request [15:37] scientes: the list of all commands _is_ available [15:37] scientes: the list of all files is not [15:37] oh i c that is better [15:38] scientes: if you have snapd on your system, you can look at the database, /var/cache/snapd/commands.db [15:38] scientes: snapd refreshes that periodically [15:39] scientes: all command-not-found does is then call (via an extension mechanism that I don't know offhand), e.g., “snap advise-snap --command tmnationsforever” [15:39] do you know what format that is? [15:39] scientes: boltdb [15:40] scientes: the integration made it into 18.04, but has not been backported, fwiw [15:40] yeah im' running 18.04 [15:40] cool [15:40] looks like boltdb is deprecated [15:41] so 'command_not_found_handle tmnationsforever' should show you [15:41] scientes: whatever the new thing is called, it's the same [15:42] scientes: bbolt [15:43] scientes: before you start looking into that database, keep in mind that the cnf extension mechanism was at least in principle built to also support flatpak [15:44] anyhow, back to work for me [15:44] thanks [15:47] PR snapd#5507 opened: Changes to network-control interface [15:51] zyga: I will re-review on Monday morning if you push there [15:51] yes, I will, just getting dinner now [15:51] thank you! [15:51] pstolowski: I will also look at the patch PR next week [15:54] pstolowski: 5502 it's maybe something you could look at when you have time [16:32] * Chipaca encourages spread to finish so he can EOW [16:38] pedronis: yes i started looking at it === pstolowski is now known as pstolowski|afk [17:01] * zyga is "lucky" [17:01] every time I go out for a walk it rains [18:06] PR snapcraft#2179 closed: cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated [18:53] what's the cross-section between snapd-control interface and classic? [18:53] if a snap uses classic, can it do snapd-control stuff? or is snapd-control isolated even from a classic snap? [18:55] roadmr: if it has bits that run as root, yes [18:55] ohh I see pedronis [18:56] pedronis: and we have no way of knowing whether it does stuff as root, right? [18:56] pedronis: so to ask another way: if a snap asks "I need either classic or snapd-control", we would prefer to grant snapd-control as it's less powerful than classic? (but I understand it's still quite powerful and dangerous) [18:57] roadmr: yes, but it depends, there are factors of trust at play, also snapd-control is not useful for something like a compiler or an ide [18:57] and snapd-control gives you those powers in fully confined (core) systems as well [18:58] pedronis: right, I'm thinking about the case of a snap that wants classic to be able to interact with snapd [18:58] yes, no classic on core [18:58] ahh interesting, noise][ [18:58] roadmr: it probably should instead make a case to get snapd-control [18:59] talk to snapd is a case for snapd-control, not for classic [18:59] (taken by itself) [18:59] pedronis: right. OK, so that's guidance we can provide to developers in this case [18:59] roadmr: I mean we shouldn't give classic to something we wouldn't give snapd-control, if the situation is talk to snapd [19:00] that said we are very reluctant to grant snapd-control for anything in the global store [19:00] totally [19:01] noise][: yes, but in general we have been reluctant with any manage the system kind of thing so far [19:01] in the global store [19:01] (afaiu) [19:01] I don't see classic vs snapd-control changing that equation [19:01] noise][: yep, I remember that... so without guarantees that snapd-control will be granted, if someone wants classic and when asked why, says "so my snap can manage/add/remove/update snaps", we can say "the right thing to use is snapd-control" - but to reiterate, snapd-control use is evaluated on its own merits [19:02] terrific, well this is enough info for what I wanted to know :) thanks both [19:08] pedronis: I got the state<=>memory<=>api mapper working, playing with more tests but it looks very good [23:37] * zyga wraps up for the week