[03:03] <mup> PR snapcraft#1178 opened: tests: make the kernel unit tests architecture independent <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1178>
[07:16] <Mirv> kyrofa: the bug's example links - both mine and Tim's, are modified qmake plugins. so yes, QTDIR, LIBS, QMAKE_LIBS, QMAKE_LIBDIR, INCLUDEPATH, QML_IMPORT_PATH, QML2_IMPORT_PATH would be the ones that would need to optionally allow custom path in addition to the defaults in the current qmake plugin
[08:02] <mup> PR snapd#3009 closed: interfaces/builtin: small refactor of dbus tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3009>
[08:32] <mup> PR snapd#2947 closed: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2947>
[08:47] <mup> Bug #1671386 opened: cannot run a snap shell <Snappy:New> <https://launchpad.net/bugs/1671386>
[09:09] <mup> PR snapd#3010 opened: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
[10:21] <mup> Bug #1671386 changed: cannot run a snap shell <Snappy:Invalid> <https://launchpad.net/bugs/1671386>
[10:40] <mup> PR snapd#3007 closed: merge the 2.23.1 release back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3007>
[10:42] <mup> PR snapd#2974 closed: many: add new (hidden) `snap debug ensure-state-soon` command and use in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2974>
[11:12] <Son_Goku> meep
[11:47] <gbisson> hi all, I'm trying to make an ubuntu image for Boundary Devices platforms (NXP i.MX-based). I've started off the roseapple-pi and built an image ok but have several questions.
[11:48] <gbisson> 1) when looking at 'snap changes' when booted up, I can see "Initialize device" in Doing state
[11:48] <gbisson> it gets stuck there and I don't where to look in order to change that
[11:49] <gbisson> 2) do I need to upload the gadget/kernel snaps to my dev portal so that it is recognized properly?
[11:49] <gbisson> (asking cause the snap list show a rev of x1 with no developer name)
[11:51] <gbisson> 3) when booting up I can see a bunch of "mkdir: can't create directory '/root/writable/system-data//etc/xxx', is that normal?
[11:57] <gbisson> hmm, regarding 1 I can now see the log: ERROR cannot deliver device serial request: unexpected status 400
[11:57] <mup> Bug #1671446 opened: content interface behaves different if tried an operation before connecting the interface <Snappy:New> <https://launchpad.net/bugs/1671446>
[12:01] <gbisson> ok, so according to https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02253.html this error is normal
[12:02] <gbisson> since my device hasn't been pushed to canonical yet
[12:06] <mup> Bug #1569581 changed: snapd no longer detects apparmor changes on upgrade <Snappy:Fix Released by zyga> <apparmor (Ubuntu):Triaged by jdstrand> <snapd (Ubuntu):Triaged> <apparmor (Ubuntu Xenial):Triaged by jdstrand> <snapd (Ubuntu Xenial):Triaged> <https://launchpad.net/bugs/1569581>
[13:45] <cachio> tyhicks, any news about the dbus tests?
[13:55] <Rumple> Can a (non-core) interface be provided in a snap?
[13:56] <kalikiana_> Rumple: Snaps can implement interfaces, provided snapd declares it
[13:57] <kalikiana_> What sort of interface is it?
[13:58] <Rumple> kalikiana_: awesome, I wish to access /sys/class/hwmon & /sys/dev - it's a fancontroller (fancon)
[13:59] <Rumple> kalikiana_: can you point me to some documentation on including an interface, I haven't been able to find any
[14:03] <Rumple> kalikiana_: sorry misread you, there is no interface that provides the access
[14:04] <kalikiana_> Rumple: Have a look at interfaces/builtin/basedeclaration.go in snapd, pulseaudio for example can be provided by the system or a snap, lxd is only implemented by a snap
[14:04] <kalikiana_> You'll want to add a new interface exposing what you need
[14:04] <mup> Bug #1581610 changed: snap connect/disconnect does not abort when an error occurs <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1581610>
[14:04] <mup> Bug #1665590 changed: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1665590>
[14:05] <kalikiana_> Rumple: Although it sounds like you mainly need access to those devices? No extra service implementing them?
[14:06] <Rumple> kalikiana_: correct. I would use --classic but stable branch does not allow that (without manual review')
[14:11] <King_InuYasha> sergiusens: hey, it's been a long time!
[14:11] <King_InuYasha> haven't seen you around here in a while
[14:11] <kalikiana_> Rumple: Maybe double-check with jdstrand which is more sensible
[14:13] <Rumple> kalikiana_: thanks I'll give it a try
[14:24] <Jasem[m]> so I tried to make a snap for my app (KStars), and I install KF5 content snap, but when I start the program (kstars), I get error while loading shared library: libKF5Crash.so.5: cannot open shared object file
[14:27] <mup> PR snapcraft#1176 closed: demos, tests: remove the tomcat demo snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1176>
[14:46] <qengho> Anyone have a trick for a upstream project that doesn't honor the INSTALL_ROOT env var to its "make" invocation?
[14:48] <qengho> I see "make-install-var" yaml key. I'm not sure it takes anything.
[14:48] <qengho> fg
[14:49] <sergiusens> Jasem[m]: you need to publish as the same publisher as the kde5-frameworks one or maybe manual connect to the content interface slot for kde-frameworks5
[14:50] <sergiusens> qengho: that allows you sets you up to use prefix instead
[14:50] <Jasem[m]> sergiusens: how do I do that? manuall connect the content interface?
[14:50] <Jasem[m]> sergiusens: I just looked in my /snap directory, have ubuntu-core, kde5-frameworks-5, and kstars
[14:51] <Jasem[m]> in kstars, there is /snap/kstars/current/kf5 but empty, and of course /snap/kstars/current/usr/lib/* does not have libKF5Crash.so provided by the kde-frameworks-5 snap
[14:52] <qengho> Ah, "artifacts" yaml key. Got it.
[14:53] <nuclearbob> I'm not sure who to ask about this (maybe ogra_ ?) but I'm trying to auto-import a system-user assertion on a virtual machine, and in the logs I see things proceeding up to the api call to create the user, but the user doesn't actually get created
[14:56] <mup> Bug #1671511 opened: snap run --shell <snap> should ignore env vars such as PROMPT_COMMAND <Snappy:New> <https://launchpad.net/bugs/1671511>
[15:06] <tyhicks> cachio: no, sorry, I've been busy with security updates this week and haven't been able to get enough breathing room to look into perf testing
[15:13] <Jasem[m]> so I ran snap interfaces kde-frameworks-5
[15:14] <Jasem[m]> but got nothing, no Slot/Plug!
[15:14] <Jasem[m]> also ran snap interfaces kstars and got only some of the plugs specified in the snapcraft.yaml file, the rest (camera, serial-port, pulseaudio) not listed
[15:17] <sergiusens> Jasem[m]: maybe it isn't connected to anything and doesn't show? http://paste.ubuntu.com/24146456/
[15:18] <Jasem[m]> sergiusens: so I connect it to kstars ? sorry never done this before
[15:19] <sergiusens> Jasem[m]:  snap connect kstars:<plug-name> kde-frameworks-5:<slot-name>
[15:19] <Jasem[m]> sergiusens: let me run that and check
[15:19] <sergiusens> don't know your plug-name and slot-name you can check in my paste
[15:21] <Jasem[m]> sergiusens: error: cannot perform the following tasks:
[15:21] <Jasem[m]> - Connect kstars:kde-frameworks-5-plug to kde-frameworks-5:kde-frameworks-5-slot (cannot connect plug "kde-frameworks-5-plug" from snap "kstars", no such plug)
[15:23] <Jasem[m]> This is what I get from 'snap interfaces kstars' https://paste.kde.org/prugyftgz
[15:25] <elopio> didrocks: davidcalle: I was making a snap for bitcoin and found that most of the other cryptocoins out there are just forks. So I think it would be really useful to have a tutorial to snap bitcoin. What do you think?
[15:27] <Jasem[m]> sergiusens: here is my snap if you want to test it yourself: http://indilib.org/jdownloads/snap/kstars_2.7.5_amd64.snap
[15:32] <didrocks> elopio: I would prefer we cover the per-topic tutorials first
[15:32] <didrocks> once we are done, yeah, real life use case can be useful
[15:32] <davidcalle> elopio: is it an electron app?
[15:32] <didrocks> if it serves a real purpose directly, we can turn it into that topic
[15:32] <didrocks> like electron
[15:33] <elopio> davidcalle: no. It's qt, a daemon and a cli.
[15:33] <didrocks> oh, interesting topic
[15:33] <didrocks> but yeah, can be once we covered the basics
[15:33] <didrocks> (unless you volounteer to write it)
[15:33] <davidcalle> can you port it to Electron?
[15:34] <davidcalle> (kidding)
[15:34] <elopio> didrocks: not me, but a guy from the community. Should I tell him to start writing it and maybe publish it somewhere else while the basic tutorials are in place?
[15:35] <didrocks> elopio: no, he could just coordinate with us (we can flush out together the titles/structures)
[15:35] <didrocks> I'm happy to help
[15:36] <elopio> didrocks: cool. If I fail to convince him, I'll do it myself.
[15:36] <elopio> the only problem I see is that we need to apply a tiny patch in the source code. But I hope that snappy will give us a workaround.
[15:37] <didrocks> elopio: \o/
[15:37] <didrocks> yeah :)
[16:03] <Rumple> How long does 'manual review' take, and does it occur on every release (classic confinement snap in stable branch)?
[16:24] <mup> PR snapcraft#1179 opened: godeps plugin: add git to build-packages <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1179>
[16:37] <flexiondotorg> seb128 didrocks Have you ever tried using classic confinement and the desktop helpers?
[16:37] <flexiondotorg> This combination results in desktop-launch not found.
[16:50] <mup> PR snapd#3011 opened: tests: remove core_name variable <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3011>
[16:51] <didrocks> flexiondotorg: I didn't, but you need to say bin/desktop-launch I think
[16:52] <didrocks> I opened a bug about it, was set as "low" priority (at least having an error message)
[16:52] <flexiondotorg> I'll give that a go. I think I been here before ;-)
[16:55] <mup> PR snapcraft#1178 closed: tests: make the kernel unit tests architecture independent <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1178>
[16:55] <mup> PR snapd#3001 closed: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3001>
[16:57] <gbisson> hi all, what would be the best type to package firmware (wifi, bt, etc..) inside its own snap?
[16:58] <kyrofa> gbisson, I don't quite understand the question
[17:00] <gbisson> kyrofa: I need to had some firmware files to my image
[17:00] <sergiusens> gbisson: kernel snap
[17:00] <gbisson> kyrofa: from what I can see there's a firmware section to the kernel snap
[17:00] <gbisson> but I'm asking if it can be in its own snap
[17:01] <gbisson> so you can update the firmware files without updating the kernel basically
[17:02] <kyrofa> gbisson, hmm, I doubt it, but sergiusens might know some more about how that's structured
[17:02] <gbisson> kyrofa: thanks! I'm not sure to understand the motivation behind forcing the firmware to be with the kernel snap
[17:02] <kyrofa> gbisson, unfortunately I'm afraid I don't either, but I'm sure there's a reason
[17:03] <kyrofa> gbisson, I don't have as much experience with kernel snaps as I'd like
[17:03] <kyrofa> gbisson, ppisati may have some insight into this as well
[17:09] <elopio> stgraber: hey, I haven't received a confirmation from you on the calendar. Are we still up for the testing day tomorrow?
[17:13] <stgraber> elopio: yeah, all good
[17:14] <gbisson> sergiusens: ppisati: anymore detail on this limitation about the firmware?
[17:14] <gbisson> sergiusens: ppisati: also, does it have to be in a tar-content? or can it be from a folder?
[17:15] <sergiusens> gbisson: from whatever valid source you have
[17:16] <sergiusens> kyrofa: gbisson the reason for it all to be together is predictability
[17:18] <elopio> stgraber: \o/
[17:20] <gbisson> sergiusens: thanks for the clarification although I'm still not convinced (what is the difference with a regular Ubuntu system where each fw has its own package)
[17:22] <gbisson> sergiusens: this also avoids installing firmware you don't need, which is useful for embedded systems with some space constraints
[17:22] <sergiusens> davidcalle: do we have docs going over the differences in Ubuntu Core? ^
[17:23] <sergiusens> gbisson: I suggest going to the mailing list and bringing up your concenrs there
[17:24] <gbisson> sergiusens: I know the difference between Ubuntu and Snappy, I meant the difference in predictability between the two
[17:28] <sergiusens> gbisson: then why are you asking these questions?
[17:31] <gbisson> sergiusens: I'm not saying I know it all, I just wanted to point that my question was only about "why is predictability an argument for Snappy and not Ubuntu" and not "what are all the difference between the 2"
[17:32] <gbisson> sergiusens: anyway I'll add the firmware inside the kernelsnap as it's supposed to be, thanks
[17:37] <sergiusens> gbisson: what I mean is, ask these questions on the mailing list; the whys will be answered there
[18:24] <mup> Bug #1670749 changed: classic confinement requires manually setting PATH and PYTHONPATH <openstack> <Snappy:Invalid> <https://launchpad.net/bugs/1670749>
[20:17] <pmcgowan> jdstrand, hey, testing the confined version and getting one denial still accessing mir, did I miss something
[20:17] <pmcgowan> Mar 09 20:15:29 patsdragon audit[5240]: AVC apparmor="DENIED" operation="capable" profile="snap.mir-kiosk.mir-kiosk" pid=5240 comm="Mir/IPC" capability=21  capname="sys_admin"
[20:22] <mup> Bug #1670749 opened: classic confinement requires manually setting PATH and PYTHONPATH <openstack> <Snappy:New> <https://launchpad.net/bugs/1670749>
[20:33] <pmcgowan> jdstrand, nm, somehow lost the kiosk changes
[20:55] <mup> PR snapd#3012 opened: [interfaces] Enable location.Service.Provider in dbus policy <Created by vosst> <https://github.com/snapcore/snapd/pull/3012>
[21:01] <mup> PR snapcraft#1180 opened: tests: support snap directory in external tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1180>
[21:10] <mup> PR snapcraft#1179 closed: godeps plugin: add git to build-packages <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1179>
[21:27] <Odd_Bloke> Can anyone point me at an example of using seed.yaml to seed snaps for installation on first boot?  I'm struggling to get it to work (on zesty, classic).
[21:27] <Odd_Bloke> I have the snap I want installed in /var/lib/snapd/seed/snaps/ and the assertion that was downloaded by `snap download` at /var/lib/snapd/seed/assertions/.
[21:28] <Odd_Bloke> My seed.yaml is 'snaps: [ "hello-world_27.snap" ]' (but formatted more like yaml).
[21:29] <Odd_Bloke> snapd tells me I need a model assertion, and I'm not sure how to produce one in this one-off case.
[21:43] <Jasem[m]> can you install a GUI app on Ubuntu Core?
[21:43] <Odd_Bloke> OK, I've found http://people.canonical.com/~vorlon/amd64-generic-model.assertion but then I hit "devicemgr: cannot find account-key (9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn): assertion not found" and I'm not sure how to fetch that assertion.
[21:44] <slangasek> huh
[21:45] <Odd_Bloke> Presumably due to "sign-key-sha3-384: 9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn" in that assertion.
[21:46] <slangasek> have the keys rotated or something?
[21:46] <slangasek> Odd_Bloke: you probably want to 'snap known' the model assertion, now that this interface exists, instead of using my one-time cached one
[21:48] <Odd_Bloke> slangasek: `snap known model` gives nothing; perhaps you meant `snap ack /var/lib/snapd/seed/assertions/model.assert`?  That gives the same error.
[21:50] <slangasek> Odd_Bloke: 'snap known model series=16 brand-id=canonical model=pc-amd64 --remote' - ok, the model hasn't changed.  so instead, you need 'snap known account-key public-key-sha3-384=9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn --remote' to grab the account-key assertion from the store
[21:50] <pmcgowan> Jasem[m], yes, for example https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
[21:50] <pmcgowan> jdstrand, about?
[21:51] <slangasek> Odd_Bloke: but I think you probably don't want the pc-amd64 assertion here, since that enforces gadget+kernel and I assume you're trying to seed onto classic?
[21:51] <Odd_Bloke> slangasek: I am, yeah.
[21:51] <Odd_Bloke> Was just sort of looking around for model assertions I could steal from.
[21:51] <slangasek> Odd_Bloke: which loops back around to a question from mvo on one of the bugs about how to do seed.yaml for classic
[21:52] <Jasem[m]> pmcgowan: well I need to run KStars which is a KDE application, so that's not possible?
[21:52] <slangasek> https://bugs.launchpad.net/snappy/+bug/1609903/comments/7
[21:52] <mup> Bug #1609903: Enable the installation of snaps in a classic chroot <cpc> <Snappy:New> <https://launchpad.net/bugs/1609903>
[21:52] <slangasek> Odd_Bloke: ^^ I don't know what the "needed" assertions are for seed.yaml on classic
[21:52] <slangasek> but I'm sure you don't want the pc-amd64 model assertion
[21:53] <pmcgowan> Jasem[m], it may work following the approach there as its a qt app and thats what that demo shows, not sure what else KStars needs
[21:53] <Odd_Bloke> slangasek: OK, fair enough.
[21:54] <Odd_Bloke> This sort of question was much easier to get answered in my old timezone. :p
[21:54] <Jasem[m]> pmcgowan: It need Qt5+KF5 so obviously X11
[21:55] <pmcgowan> Jasem[m], there is a QPA plugin directly to MIR that does not require X11, but you do not get a window manager
[21:57] <Jasem[m]> pmcgowan: well, a minimal desktop environment is required. I guess Ubuntu Core is not the solution I'm looking for. Maybe Ubuntu Mate would do
[21:58] <pmcgowan> Jasem[m], yes core is not quite ready for a full desktop, we are working toward it
[21:59] <Jasem[m]> pmcgowan: If I use Ubuntu Mate, but install my app as a snap, it still would get the benefit of snaps like if I update it on the store, then users would get the updates atomically?
[22:00] <pmcgowan> Jasem[m], yes
[22:03] <Odd_Bloke> slangasek: I continued poking at it, and I think those model assertions need s/TBD/canonical/.
[22:04] <Odd_Bloke> But, of course, making those changes means that the signature doesn't validate.
[22:04] <slangasek> Odd_Bloke: right, those are not the official assertions (not sure why the ones published there have that) - the official assertion is the one retrievable by 'snap known model series=16 brand-id=canonical model=pc-amd64 --remote'
[22:06] <Odd_Bloke> OK, now I get to "state ensure error: devicemgr: cannot seed a classic system with an all-snaps model" as we would expect.
[22:06] <Odd_Bloke> The system works!
[22:06] <slangasek> :)
[22:06] <Odd_Bloke> Just not currently in my favour.
[22:09] <Mario__> hi all! I'm evaluating Rocket Chat using snap. I want to now if there is some, let's say, convinient way to backup the current installation before applying major configuration changes to the app. Perhaps it's just about taring the app directory below snap.
[22:15] <Odd_Bloke> slangasek: Is there a way I can list model assertions that the store has?
[22:15] <slangasek> Odd_Bloke: you can query by attributes; I don't believe you can list
[22:18] <qengho> Mario__: Find the SNAP_DATA (or SNAP_COMMON), and copy it. For a daemon, you are guaranteed that the dir there has the only files the package changed, because snap disallows anything else.
[22:19] <Mario__> thanks a lot qengho
[22:19] <Odd_Bloke> slangasek: Hmph, I need to know the model of a model assertion to query for it.
[22:19] <Odd_Bloke> So I can't see if we have any classic assertions.
[22:21] <slangasek> right
[22:22] <Odd_Bloke> Am I able to create my own model assertion, or will snapd choke because my key isn't in the store's web of trust?
[22:23] <kyrofa> Odd_Bloke, it'll choke, but you can get your key there
[22:24] <kyrofa> Odd_Bloke, follow this tutorial, you'll see what I mean: https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#0
[22:34] <Odd_Bloke> kyrofa: Thanks!
[22:40] <Odd_Bloke> It worked! \o/
[22:41] <Odd_Bloke> kyrofa: One piece of feedback on that tutorial: "you will find it on your account page" <-- it wasn't immediately obvious to me how to get to my account page to find this
[22:41] <kyrofa> Odd_Bloke, the account ID, you mean?
[22:42] <Odd_Bloke> kyrofa: Yep, sorry, should have given more context.
[22:42] <kyrofa> Odd_Bloke, you may wonder how I knew exactly what you were talking about: I ran into the same thing :P
[22:42] <Odd_Bloke> ^_^
[22:42] <kyrofa> Odd_Bloke, so yeah, agreed
[22:43] <Odd_Bloke> Not sure if you're the person to feed back to, but this is what happens when you're helpful. ;)
[22:43] <kyrofa> I think probably either didrocks or davidcalle
[22:46] <davidcalle> Odd_Bloke: that's a fair point, do you mind filing an issue about it? https://github.com/canonical-websites/tutorials.ubuntu.com/issues
[22:47] <Odd_Bloke> davidcalle: Sure thing.
[22:47] <davidcalle> Thanks!
[22:50] <Odd_Bloke> davidcalle: https://github.com/canonical-websites/tutorials.ubuntu.com/issues/137
[22:52] <davidcalle> Nice, ty
[23:05] <kyrofa> jdstrand, could I borrow your eyes for a minute? The nextcloud snap has a bug against it that I can't quite figure out: https://github.com/nextcloud/nextcloud-snap/issues/221
[23:06] <kyrofa> jdstrand, oparoz is saying that it reminds him of a snap-confine issue from a while back, but I'm fuzzy
[23:49] <mup> PR snapcraft#1157 closed: repo: support versioned stage-packages <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1157>
[23:58] <mup> PR snapcraft#1177 closed: sources: update documentation for source-subdir <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1177>