[07:09] morning [08:02] good morning [08:06] mvo: zyga: hey [08:06] :-) [08:06] zyga: is https://github.com/snapcore/snapd/pull/9936 related to the debian bug? [08:06] PR #9936: interfaces: remove apparmor downgrade feature [08:06] yes [08:06] zyga: this one right? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500 [08:07] yes [08:08] i've left a note in the PR, tbh maybe we should start off by displaying a warning that confinement is partial/incomplete due to build config/runtime support [08:10] morning [08:10] pstolowski: hey [08:11] mborzecki I don't think that will help TBH [08:11] it will break tests on random output [08:12] tests can be fixed (we did that already once for cgroup v2, although i expect there would be more this time) [08:12] yeah but what's the value? [08:12] do you want to let eveyone know confinement is partial? [08:12] what is the next step? [08:13] confinement was _gone_ before and we said nothing [08:13] confinement is really partial with that patch, and now we want to say "actually, you may want to be careful" [08:15] pstolowski: can you take a look https://github.com/snapcore/snapd/pull/9933 ? [08:16] PR #9933: packaging/opensuse: sync with openSUSE packaging [08:18] zyga: it's still going to be partial with the full template, rules like unix(..) and dbus will not be enforced afaict, or if those are made `deny unix ..` they could be enforced in an incompatible way [08:19] yes, I'm fully aware of that [08:19] I think it's not my decision [08:19] I could only make the patch [08:20] zyga: sure, thanks for making the effort and opening a PR :) [08:20] tumbleweed dies on govendor sync? [08:22] zyga: haha, yes still, i should file this bug report for the kernel [08:22] (eventually) [08:23] zyga: works on my laptop though ;) === ogra_ is now known as Guest26551 [08:53] pstolowski: I did a first pass over pool.go in #9930, some bits seems to be missing though, so I didn't go deep on some pieces [08:53] PR #9930: asserts: pool changes and RefreshValidationSetAssertions method for validation-sets

[08:53] pstolowski: bunch of questions there [08:54] pedronis: ok, thanks [09:03] good morning pedronis [09:28] cjwatson: fyi, I followed up on that bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500#22 [09:28] PR #22: add travis status to README.md [09:28] Thanks! [09:56] PR snapd#9933 closed: packaging/opensuse: sync with openSUSE packaging [10:06] PR snapd#9937 closed: tests/lib/prepare.sh: split reflash.sh into two parts [10:58] Bug #1915807 opened: No splash screen in uc 20 for RPI [12:04] ogra@ubuntu:~$ snap install unifi --edge [12:04] error: cannot perform the following tasks: [12:04] - Start snap "unifi" (7) services ([start snap.unifi.unifi.service] failed with exit status 1: Job for snap.unifi.unifi.service failed because the control process exited with error code. [12:04] See "systemctl status snap.unifi.unifi.service" and "journalctl -xe" for details. [12:04] ) [12:04] ... not helpful ... [12:04] ogra is that the controller? [12:05] (the hook failed, so it didnt install at all ... pointing me to systemctl status will only return "not found" ) [12:05] zyga, well, yeah, someones first attempt at least 😉 and arm64 only [12:05] https://github.com/hairychris/unifi-snap [12:06] i'm more wondering about the error message ... [12:37] mvo: can you cherry pick https://github.com/snapcore/snapd/pull/9935 ? [12:37] PR #9935: data/selinux: allow system dbus to watch /var/lib/snapd/dbus-1 [12:38] mborzecki: sure, in a meeting [12:42] PR snapd#9935 closed: data/selinux: allow system dbus to watch /var/lib/snapd/dbus-1 [12:54] pstolowski: I tried to answer your wondering about account-keys in tests, but maybe I *am* missing something [13:01] pedronis: thanks. do you mean we always try to udpdate account & account-key by design? [13:01] pstolowski: yes, we always ask the store if there are new revisions of any of the prereqs [13:01] pstolowski: that's logic in pool [13:01] pedronis: ah, ok that explains it then [13:02] i thought some of them never change [13:09] pstolowski: no, there are scenarios for all of them to possibly change, rare but possible [13:10] pedronis: ack, thanks, that solves my confusion [13:43] Hi, any why I get "Failed to load plugin: properties failed to load for kernel: Additional properties are not allowed ('kernel-initrd-core-base' was unexpected)" when using a similar snapcraft.yaml as rockpi? [13:44] Under the same circumstances too (using lxc as ogra suggests in his README) https://github.com/ogra1/rockpi-n10-kernel [13:44] Here is my snapcraft.yaml: https://github.com/boundarydevices/ubuntu-core/blob/20-armhf/kernel/snapcraft.yaml [13:44] gbisson, note the plugin subdir in that tree [13:45] i'm using ondra's UC20 kernel plugin in that tree [13:45] ogra: oh I see [13:45] ogra: should I just copy that plugin folder then [13:45] which has some UC20 specific adjustments [13:45] yeah [13:45] or use a git submodule [13:46] ogra: it's still unclear to me how to get the uc20-ready initrd properly generated [13:47] https://github.com/kubiko/snapcraft-kernel-plugin [13:47] ogra: thanks! [13:47] you dont generate it ... it comes from some pre-built thing that xnox generates regulary ... the kernel plugin *can* re-pack that to add extra firmware or modules though [13:48] that then based on the initrd-firmware and nitrd-modules options in snapcraft.yaml (not sure about the correct names of these options from the top of my head) [13:51] s/based/bases/ [13:54] ok, can you also explain the --destructive-mode, I couldn't find what this means [13:55] nvm found it, just not in the snapcraft --help [13:55] it means it will destructively change the host setup if needed [13:56] whcih is why you should use it only in a clean lxd container [13:56] never on the host itself ... [13:56] but is it really necessary? [13:57] I mean, when it's not there it seems to kick multipass which creates the VM for you no? [13:57] yes, else snapcraft will forcefulyl try to buiuld in a multipass VM [13:58] (it will surely work, but it is painful to use VMs during development) [13:58] --destructive-mode means you can immediately build in your tree and see results without spinning up VMs [13:59] ok, fair enough, hopefully that was my last missing piece to release a uc20 for all our platforms [13:59] (after the 20 track is created) [14:00] last thing, can you confirm you only override the toolchain because the rockpi kernel is obsolete (and most likely don't build with gcc9 or 10) [14:00] yes [14:01] you should be able to simply use the cross gcc for newer kernels and non hacked up BSPs 🙂 [14:01] note you rae rather on your own with the gadget for now, that rockpi N10 thing is a spare time project and my spare time is rare til end of the month [14:02] perfect, that's what I do, just wanted to make sure there wasn't another reason ;) [14:02] nope thats the only reason ... and it is an awful hack too ... 🙂 [14:02] oh i know, I've been on my own on that core20 upgrade, and I have to say it has been much more painful than core16 & core18 ever were [14:03] yes, everything changed [14:03] but thanks for all your answers, you definitely helped a lot [14:03] (trying to find my way around as well atm) [14:05] sorry I keep on asking questions: has anyone ever got Mir working on any i.MX platform? (Vivante GPU) [14:31] gbisson, try #mir-server for that [14:43] ogra: yes but I don't know where to feed the Vivante libraries, because it won't work without them [14:43] the guys in #mir-server should know 😉 [14:45] oh you meant the irc channel ha! I thought you meant the mir-server snap ;-) [14:45] 🙂 [14:46] i would expect it to ship the evnativ driver by default though [14:47] (and to kind of work with that) [14:59] yeah unfortunately that won't be the case, etnaviv mesa libraries only work on etnaviv driver, since NXP kernel uses vivante driver instead... [14:59] right, then you will likely need yur own fork of mir-kiosk ... and add it to your brand store [15:00] (or convince the mir team to ship vivante but i'm not sure they will be willing to do that) [15:01] yes I don't expect vivante to be part of the generic package, but a mir-viv-kiosk would be nice [15:15] I now get this when booting up: "assertion is signed with expired public key "blah"" [15:16] how come my key expired? Seems to be properly there in 'snap keys', plus I can upload to the store ok which I believe checks the key [15:17] replace your RTC battery 😛 [15:18] (which i'm indeed sure you have plenty on your boards 😛 ) [15:18] urgh [15:18] really? [15:18] can't it get the time from the network? [15:19] there is some code in systemd-timesyncd that is supposed to set the clock to a more proper date ba default, but there ere issues ... i think xnox was working on a fix [15:19] *by default [15:19] ok thanks, let me try that [15:19] you get the time from the network once the entwork is up [15:20] but the key check happens earlier in the boot IIRC [15:20] that said, try with wired network, perhaps your chances are better there [15:21] (we ship a default dhcp setup for eth0 that should come up earlier than wlan, with luck thats enough) [15:23] ogra: thanks I confirm it works! [15:23] great [15:23] once I get the 20 track for gadget/kernel I can release an image [15:23] not sure what the bug number was, but i knwo there is a bug open for the systemd fix [15:24] (and i guess xnox isnt watching the channel here to give it to you from the top of his head ) [15:25] that's ok, I want to use stable channel anyway for the issue, it will be part of the known issues that should disappear later [15:25] yeah, thats the spirit with UC20 🙂 [15:32] PR snapd#9912 closed: snap: provide a useful error message if gdbserver is not installed [15:38] ogra: finally I got my platform fully booted up and installed properly, thanks again for the help! [15:41] congrats ! [16:19] do you guys remember the name of that thing that lets you deploy openstack or k8s quickly [16:19] it had a catchy name [16:19] but it flew out of my head [16:20] conjure-up I think? [16:20] juju? [16:21] conjure up! [16:21] thank you cjwatson :) === ijohnson is now known as ijohnson|lunch [22:23] PR snapcraft#3437 opened: extensions: check that the platform snap is connected in desktop extensions and bail out if not (LP: #1915712)