[06:08] Good morning [06:19] morning [06:22] Hey [06:22] How are you? [06:23] zyga: fine, thanks [06:24] zyga: it's cold outside :/ [06:24] Yeah [06:24] I was walking with the dog for two hours last night [06:25] All the way until midnight [06:25] zyga: nice [06:31] mborzecki: quick review to start the day? https://github.com/snapcore/snapd/pull/6587 [06:31] PR #6587: interfaces/apparmor: factor out test boilerplate [06:31] zyga: sure, why not [06:34] mborzecki: I changed some of the test function names but that is all sensibile in the follow-up patch [06:48] mborzecki: pushed [06:52] zyga: thanks! [06:52] thanks [06:52] I will push something that enables apparmor on all of suse next [06:53] then I'll look at debian [06:53] I think we can handle debian (and derivatives), suse (and derivatives if any) to cover most of apparmor land [07:05] mborzecki: https://lwn.net/Articles/782786/ [07:05] maybe mvo should apply [07:05] ;D [07:21] zyga: hi, when are you going to address 6360 feedback ? [07:21] pedronis: hi [07:22] pedronis: most likely today [07:22] guys, think we can land this now if everyone is happing with the current phrasing? https://github.com/snapcore/snapd/pull/6556 [07:22] PR #6556: cmd/snap: hide 'interfaces' command, show deprecation notice [07:22] pedronis: I already started yesterday but haven't finished yet [07:25] mborzecki: I didn't see all the bikeshedding there [07:26] good morning [07:27] mborzecki: hey, yay (or :cry:) at 6585 [07:27] mborzecki: I fear the new sentence is too long [07:27] hey pedronis [07:28] mborzecki: I would like John input on htat [07:29] *that [07:29] hey mvo [07:30] mborzecki: I commented there [07:30] pedronis: thans [07:30] hey zyga [07:30] mvo: hi [07:31] mvo: quick review to start the day? https://github.com/snapcore/snapd/pull/6587 [07:31] PR #6587: interfaces/apparmor: factor out test boilerplate [07:31] zyga: sure [07:31] (when typing this the mouse focus was still on mutt - typing random chars into mutt is really scary) [07:32] mvo: lol [07:32] yes [07:32] kind of like vi but then git prevents critical damage [07:32] no such thing for mutt [07:33] mvo: do you want to travel more, apply now for the position of debian leader: https://lwn.net/Articles/782786/ [07:33] zyga: *cough* [07:34] zyga: and no [07:34] :D [07:34] join debian they said [07:34] see the world the said [07:34] zyga: but it would be interessting, pushing some ideas to moderinize things would be nice [07:34] zyga: hahaha [07:34] yeah [07:34] mvo: I see the reference was recognized :) === pstolowski|afk is now known as pstolowski [08:06] morning [08:13] hey pawel [08:37] PR snapd#6587 closed: interfaces/apparmor: factor out test boilerplate [08:38] PR snapd#6580 closed: cmd/snap-confine: drop unused dependency on libseccomp [08:41] PR snapd#6588 opened: interfaces/apparmor: partial confinement on openSUSE [09:14] zyga: did you change 6575 since I reviewed it? [09:15] pedronis: I applied the changes you asked for, fixed a typo that broke he build then merged master and pushed [09:15] I then noticed that I left duplicate include line and force pushed to clear it [09:15] that's all [09:16] zyga: no, sc_init_invocation was not there when I reviewed it [09:16] oh? but it is added before your review? [09:16] no [09:17] please double check, perhaps you reviewed a view that was stale [09:17] it is so according to the github timeline [09:17] zyga: you force pushed, not point debating this [09:17] yes, I said that [09:18] but that was in the morning after some things landed and the branch conflicted [09:18] you can compare the revisions if you want [09:19] anyway I removed my +1 [09:20] zyga: yeah, 6575 changed quite a bit since I looked at it - or so it felt to me this morning but I have not looked at the details [09:20] slightly sad because the previous one was ready for merging afaict [09:21] mvo: I implemented the changes you suggested [09:21] mvo: and made it clear in the log as well [09:22] zyga: my emails says that stuff was pushed 20 hours ago, and my review was 21 hours ago [09:22] but as I said hard to tell with force push [09:22] pedronis: but that force push was done this morning [09:22] and after I pushed yesteray I was happy to see your review [09:23] zyga: sorry, I'm confused, in 6575 I just wrote "looks good" - am I mixing something up? [09:23] I'm 100% sure github showed this the same way before i did that in the morning [09:23] mvo: we discussed this durinig the standup and you suggested that I put additional patches to the same branch [09:23] pedronis: hello, sample output of new timings to discuss - https://paste.ubuntu.com/p/gXrk8sBwwB/ - contains timings of some tasks, ifacemgr startup, snapmgr ensure loop (nb, do we really run ensure so often?). combines doing/undoing times from tasks [09:24] pedronis: this is especially clear since the three patches starting with cmd/snap-confine: tweak ordering of fields in sc_invocation are added in response to your review [09:25] zyga: oh, sorry. my bad then. maybe we can go back to the point in time (via a PR) that had the +1 from pedronis and the "looks good" from me and then land those bits easily? [09:25] zyga hey [09:25] zyga wanna talk about those PR for gadget snaps? [09:26] mvo: but the unclear aspect is what pedronis actually had reviewed [09:26] zyga unless you already had chat with pedronis [09:26] ondra: hey, I asked about it yestereday [09:26] zyga: I didn't review the init helper [09:26] ondra: I don't know what I can do to help [09:26] maybe it was stale [09:26] whatever [09:26] zyga yeah I was already off when I saw you message [09:26] it needs a review from scratch from both of us [09:26] zyga nothing apart of +1 :D [09:27] ondra: I don't fully understand the consequence of that, it is something perdronis should look at first [09:27] zyga I think rest is on foundation [09:27] zyga yeah we already talked with him [09:30] zyga: if I have too be honest I find snap-confine is starting to be too much split out in helpers, it's a maze to follow [09:31] I'm sure they all make sense locally but if in a 2nd time you need to find out what's going on is a chase [09:35] mborzecki: I pushed a tweak to the interfaces deprecation pr [09:35] pedronis: ^ [09:35] pedronis: let me know when/if you have a moment to discuss this [09:35] Chipaca: thanks! [09:36] pstolowski: we call ensure loop each 5 mins but also each time we need to run more task with EnsureBefore(0) [09:36] Chipaca: is fill() aware of a sequence '..' and will not break it? [09:36] mborzecki: it is not [09:37] mborzecki: ¯\_(ツ)_/¯ [09:37] I mean, breaking it isn't ideal but isn't the end of the world either [09:37] Chipaca: fits unboken in my term so :) [09:38] mborzecki: also breaks just right on 80 [09:38] mhm [09:38] Chipaca: I don't understand how using fill helps [09:39] it's going to take up vertical space anyway [09:39] pedronis: your issue was with vertical space, not with improper word-splitting? [09:39] yes [09:39] pedronis: https://paste.ubuntu.com/p/7qzSqPM4Zc/ [09:39] ah, right, EnsureBefore(0) [09:40] pedronis: but the deprecation is only shown on 'snap interfaces' [09:40] pstolowski: we really need to be careful with it [09:40] pedronis: which is not concerned with vertical space [09:41] Chipaca: no, but is a table [09:41] pedronis: so? [09:41] the message goes to stderr [09:42] I know [09:42] we are still eating 3 lines [09:42] seems too much [09:43] grah [09:43] Chipaca: have you by an chance implemented our TabWriter? [09:44] pstolowski: we don't have a TabWriter [09:44] pstolowski: why? [09:44] pstolowski: we do have a tabWriter, I think, that wraps TabWriter [09:44] as a helper function i mean [09:44] not as a type [09:45] Chipaca: 'snap interfaces' is deprecated and replaced by the 'snap connections' command. is 79 [09:45] pedronis: in English [09:45] Chipaca: they we just hide it [09:45] Chipaca: ah, nvm, it's a standard go lib thing [09:45] thne [09:45] Chipaca: then we just hide it [09:46] pedronis: I don't understand why [09:46] I don't understand why 3 lines are too many, on a command that produces 121 lines of output by default [09:47] Chipaca: it doesn always produces 121 lines [09:48] Chipaca: consider snap interfaces gnome-logs [09:48] pedronis: ok [09:48] pedronis: so what's the issue [09:52] Chipaca: we started here "The 'snap interfaces' command is deprecated, try the new 'snap connections'." [09:54] pedronis: yes [09:54] i don't mind going back to the first version [09:55] We could even go with [09:55] 'snap interfaces' is deprecated; use 'snap connections'. [09:55] this incorporates all the feedback so far [09:55] works for me [09:55] pedronis: ^^ wdyt? [09:56] Chipaca: +1 [09:56] mborzecki: I'll push the change, plus adding the notice to the long help [09:56] (fwiw) [09:57] Chipaca: thank you! [09:57] I updated 6401 fwiw [09:58] Chipaca: the last version is very long, but it's all facts, it doesn't recommend anything [09:58] (except implicitly) [09:59] pedronis: the _last_ version? “'snap interfaces' is deprecated; use 'snap connections'.”? [09:59] Chipaca: the last version in the PR [09:59] pedronis: you ok with the last one here? i think it covers all the issues we've come across so far [10:00] Chipaca: it's very terse [10:01] sorry, that's not the problem [10:01] I'd also add [10:01] NOTE this command is deprecated and has been replaced with the 'connections' [10:01] command. [10:01] to the longHelp [10:01] thanks [10:12] Chipaca: have we goon too far the other way around though? is the new one too prompt? [10:14] pedronis: nah, it's fine [10:14] pedronis: adding 'please' and 'try' are both problematic for reasons degville explained in the pr [10:15] Chipaca: wondering if we want "the new" , issue with that is that at some point we would need to remove "new" because is untrue [10:16] pedronis: I really think it's fine as is [10:16] ok [10:28] PR snapd#6589 opened: daemon: support returning assertion information as JSON with the "json" query parameter [10:29] Chipaca: ^ something for you when you have a bit of time [10:29] * Chipaca looks at next year's calendar [10:29] ok [10:30] heh [10:30] :-) [10:54] PR snapcraft#2499 closed: many: support for "base: core" in snapcraft.yaml [10:56] mvo, here is another core18 regression https://bugs.launchpad.net/snappy/+bug/1819629 [10:56] Bug #1819629: no default locale in core18 causes pam errors [10:56] Bug #1819629 opened: no default locale in core18 causes pam errors [10:57] ogra: thanks - that sounds hopefully straightforward to fix, maybe sil2100 can give 1819629 a stab [10:59] yeah, just some "echo C.UTF-8 >/etc/default/locale" somewhere would be enough [10:59] (in the build) [11:00] Oh, indeed [11:01] ogra, sil2100 yeah, the new build system has a "static" dir, we could simply drop static/etc/default/locale into the core18 tree and its fixed :) [11:01] awesome [11:02] sil2100, also https://forum.snapcraft.io/t/cant-find-the-spi-interface/7523 ... you might need to pull the latest upstream into the CanonicalLtd branch for the pi3 gadget SPI interface fix [11:03] i wonder if we could put the snapcore/pi3-gadget tree to rest somehow witout breaking all the forks of it (not sure if github supports re-owning branches and keeps the references) [11:26] zyga what happens when I change base in snap between revisions, will snapd correctly run new revision agains different base? [11:27] ondra: when all processes of that snap terminate, yes [11:28] zyga is there way to check what base it's working [11:28] ondra: yes, sure, just nsenter and look === alan_g_ is now known as alan_g [11:29] zyga hmm for me refresh failed, because I think in post-refresh hook it collided on libc versio [11:30] ondra: can you provide a reproducer? [11:31] zyga testing now, let me make sure I have it all right [11:31] ondra: you can set SNAPD_DEBUG=1 and see what happens [11:31] but I don't know how to set that to see hook output [11:32] ondra: there's a spread test for this feature if you want to see how it behaves [11:32] zyga I get hook error and that indicates there was libc collision, but let me validate clean install first [11:33] https://github.com/snapcore/snapd/blob/master/tests/main/stale-base-snap/task.yaml [11:33] jamesh, hey [11:34] jamesh, yesterday I was working with a test error [11:34] jamon, [11:34] jamesh, the test desktop-portal-filechooser on snapsd [11:34] jamesh, https://paste.ubuntu.com/p/wMhG5vdyzK/ [11:35] the test just fails like this on ubuntu 18.04 [11:35] zyga OK so install opengrok from stable, then try to refresh to edge [11:36] the error itself is that the snap can't write in the mount dir because of lack of permissions [11:36] jamesh, any idea if this has been already seen/reported? [11:37] zyga stable is with core16, edge it base core18, there is libpthread library which depends on libc version, this is used in post-refresh hook, which fails [11:37] jamesh, in ubuntu 18.10 works fine [11:37] zyga clean install from edge works [11:37] zyga so only difference I can think og [11:39] ondra: perhaps something was still running? [11:39] it's interesting [11:39] that post refresh hook can run with old libc [11:39] I mean [11:39] it's possible to craft this [11:39] so that it will happen as you described [11:39] perhaps snapd should disallow base changes that don't discard the mount namespace [11:40] pedronis: ^ [11:40] zyga so post-refresh runs with previous base? [11:40] ondra: please report this [11:40] ondra: yes, it is possible that this happens [11:40] ondra: when an app is still active [11:40] ondra: or perhaps hooks don't depend on their teremination and we start post refresh hook while another hook is running [11:40] zyga doesn't it stop all services before refresh? [11:40] ondra: it does, but there are hooks and apps [11:41] those can run longer [11:41] and there are enduring services [11:41] it warrants a bug [11:41] this is funny actually [11:41] zyga there should not be any app running, so just hooks [11:41] because it means we cannot correctly refresh in some cases [11:41] ondra: perhaps more than one bug then (base awareness across refresh and hook ordering) [11:41] zyga have you managed to reproduce it? [11:41] no [11:42] I have not tried [11:42] I just explained how it is 100% possible to do that [11:42] zyga right :) [11:42] ondra: curious, what was the base change? [11:42] core -> core18 [11:42] or back? [11:44] zyga core->core18 [11:46] zyga a bit related, what is correct base in snap.yaml for core16? core16 or core? [11:51] ondra: and is libc incompatible across that hop? [11:52] zyga I'm using custom libpthread which I ship in snap, so it's missing things from libc [11:54] ahh [11:55] zyga this is error I'm getting mkdir: relocation error: /snap/opengrok/34/lib/x86_64-linux-gnu/libpthread.so.0: symbol __tunable_get_val, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference [11:59] ondra: please report a bug, after an errand later today I will write a test that reproduces thiis [11:59] ondra: it's unfortunate because it's a design omission [12:00] zyga sure I will file bug for it [12:00] thank you for another interesting case :-) [12:01] zyga you are welcome :) [12:11] zyga: we always run at most one hook per single snap [12:11] at a time [12:12] pedronis: and we consider the hook "done" when the initial process exits [12:12] zyga: ? [12:12] pedronis: we probably can craft a hook that leaves a background process behind [12:12] probably [12:12] is that the case here though? [12:13] PR snapd#6562 closed: timings: base API for recording timings in state [12:13] no, I don't think so, unless that was accidentally what had occurred [12:13] but regardless of what happened here the issue of running a revision that clearly demands base snap X with the stale base snap Y needs addressing [12:13] yes [12:13] shouldn't stale detection find that out? [12:14] different base, different device? [12:14] it is different [12:14] I bet it's not changed because the namespace is still used [12:14] howerver here I'd argue that different base snap name should be detected [12:14] but we have no logic to recover base snap name from the mount namespace [12:15] (or if it can be done, in general, reliably, apart from parsing path names) [12:20] pstolowski: the doc comments in the branch you merged still say Timing a lot [12:20] instead of Span [12:20] unless I'm confused [12:22] pedronis: uhm you're right, sorry.. i'll address in a followup, this doc will be updated anyway with new helpers [12:22] pstolowski: yes, fine for a follow up [12:26] Chipaca: the failure on the deprecate interface PR is real, something going with xgettext-go [12:26] and the warning [12:26] panic: unknown type: interfacesDeprecationNotice [12:27] * Chipaca kills all tests [12:27] pedronis: I'll fix [12:27] after lunch tho [12:27] :) [12:29] niemeyer: https://pbs.twimg.com/media/D1dQcvqXcAAaQKs?format=jpg&name=large [12:30] since you were asking about this yesterday [12:30] mvo, is it ok to move 2.37.4 to stable right? [12:30] Chipaca: There we go.. :) [12:30] anyone up for a review on #6485 ? [12:30] PR #6485: interfaces/seccomp: regenerate changed profiles only [12:41] mborzecki: it has grown quite a lot [12:41] mborzecki: I can enqueue that for later today [12:42] I need to leave in ~15 minutes [12:42] thanks! [12:42] mborzecki: enqueued :) [12:44] mborzecki: it would be easier to review if the new package added was its own PR [12:45] pedronis: i can split it [12:45] mborzecki: if it's not too much painful, I would prefer, it would go faster on the review side that way [12:46] * zyga goes to the doctor === ricab is now known as ricab|lunch [12:50] cachio: let's chat about 2.37.4 in the standup [12:51] pedronis, ok [13:02] Chipaca: https://github.com/snapcore/snapd/pull/6556#issuecomment-471990121 could that be because of ; in the message? [13:02] PR #6556: cmd/snap: hide 'interfaces' command, show deprecation notice [13:02] mborzecki: no, we use ; elsewhere [13:02] mborzecki: it's probably the i18n.G() of const === nessita_ is now known as nessita [13:03] checking now [13:03] off to pick up the kids [13:04] how [13:04] how does update-pot work any more [13:04] ogra / mvo: I'm trying to rebase my fork of ogra's kiosk gadget snap (https://github.com/ogra1/pi-kiosk-gadget) onto the core18-related changes of the “universal Pi gadget snap” (https://github.com/snapcore/pi-gadget). Building the core18 gadget works fine, but my Pi 3B does not boot at all … green LED flickers shortly and then dies, no HDMI output whatsoever. I tried to selectively apply changes from both repos from the point where [13:04] they diverted (commit 013c2931230a4b4de419080f8499fca27c51727d), but no success. Do you know if the current revision of the universal Pi gadget works? [13:04] 'go install' now installs binaries in ~/bin/ [13:04] :-| [13:04] dot-tobias, got a link to your current code ? [13:05] oh wait, no, i have GOBIN set for some reason [13:05] hrmm [13:05] arent you in england ? shouldnt that be GOWASTEBASKET instead ? :P [13:06] ogra: https://en.oxforddictionaries.com/definition/bin [13:07] ogra: 'rubbish bin' is british (vs 'trash') [13:07] oops [13:07] ogra: bloody europeans, coming over here, stealing our language [13:08] lol [13:11] ogra: https://gitlab.com/glancr/gadget-snap-pi-kiosk/ -> master builds fine with LXD container without base (though the attempt to feed mir-kiosk the whole config file does not validate in ubuntu-image); branch core18-WIP has the core18 changes in snapcraft.yaml: https://gitlab.com/glancr/gadget-snap-pi-kiosk/commit/d91cc2386af0da24a8942e52053469f4b920ec7b (other files can be ignored) [13:13] dot-tobias, the linux-modules package contains dtb files ?!? [13:14] (i highly doubt that) [13:14] is that a change made by you or did you copy it from the universal branch ? [13:15] ogra: Got that from the snapcore/pi-gadget upstream, see https://github.com/snapcore/pi-gadget/blame/988ee427691177de5cee84370b096be3c6a07951/snapcraft.yaml#L89 [13:16] but that would indeed explain why it's not booting … (I have close to zero knowledge about this stuff, so apologies and thank you for beginner explanations in advance 😊 ) [13:18] dot-tobias, ok, i checked, devicetrees are in that package, so this is fine [13:20] o dont see anything else significant that could prevent booting apart from the fact that you use the distro compiler, but that should be v7 or newer anyway in bionic [13:20] s/o/i/ [13:21] how does your prime folder look like after build ? [13:21] you should fine the RPi bootloader blobs in there as well as uboot2.img and uboot3.img [13:21] re: compiler: yeah, that's what I gathered from https://github.com/snapcore/pi-gadget/pull/9 [13:21] PR pi-gadget#9: RFC: use ubuntu cross gcc to build uboot [13:21] let me check [13:22] actually in prime/boot-assets/ [13:23] $ ls ../../pi3/pi3-gadget/prime/boot-assets/ [13:23] bcm2709-rpi-2-b.dtb bcm2710-rpi-cm3.dtb cmdline.txt COPYING.linux fixup.dat fixup_x.dat overlays start_cd.elf start.elf uboot.bin [13:23] bcm2710-rpi-3-b.dtb bootcode.bin config.txt fixup_cd.dat fixup_db.dat LICENCE.broadcom psplash.img start_db.elf start_x.elf [13:23] thast what you want to see [13:23] *that's [13:23] Ok, thanks. Rebuilding the snap just to be sure, BRB [13:26] ogra: Side-note – Do you happen to know how I can feed a multiline file to a “defaults” entry in gadget.yaml? I'm trying to accomplish setting mir-kiosk's display config file through the device hook (see https://forum.snapcraft.io/t/prepare-device-hook-questions/9626/5?u=tobias , current attempt at https://gitlab.com/glancr/gadget-snap-pi-kiosk/blob/master/gadget.yaml#L12) [13:27] dot-tobias: > will mangle things for you [13:27] dot-tobias: also the quotes are spurious [13:27] dot-tobias: paste your yaml into http://yaml-online-parser.appspot.com to see what works :-) [13:29] dot-tobias: note these are comments about the yaml itself, I don't know if what you're trying to do should work :-) [13:29] i'm also not sure if the mir team has even tested this [13:29] probably ask in #mir-server [13:30] I tried with a pipe before and the parser complained while building the snap, but maybe I did something else wrong. The online parser shows valid JSON with \n linebreaks at least, will test with ubuntu-image 😊 Yeah, but having a valid yaml result is at least one step closer to the goal 😄 Thank you! [13:32]