[07:54] <zyga> o/
[08:25] <mup> PR snapcraft#1123 closed: Adding Fish shell source and IDEA IDE to gitignore <Created by joedborg> <Closed by joedborg> <https://github.com/snapcore/snapcraft/pull/1123>
[09:43] <cappe> It doesnt work very good, restartunit error, socket error and so on. Im on the latest ubuntu
[09:44] <cappe> i was here some weeks ago trying to solve the bug(?)
[09:44] <cappe> (at least report it)
[09:52] <morphis_> ogra_: ping
[09:52] <ogra_> morphis_, yo
[09:52] <morphis_> ogra_: didn't you enabled ALSA support for the pi sometime ago with a change in the config.txt?
[09:53] <ogra_> morphis_, well, audio device support, but yes ... all edge builds should have it
[09:54] <morphis_> ah only in edge
[09:54] <ogra_> well
[09:54] <ogra_> we cant update gadgets in stable ... so you wouldnt get it
[09:54] <morphis_> why that?
[09:55] <ogra_> because nothing in /boot gets updated on gadget upgrade
[09:55] <morphis_> ah right
[09:55] <ogra_> only snap.yaml (and i think gasget.yaml)
[09:55] <morphis_> that problem ..
[09:55] <morphis_> :-)
[09:55] <ogra_> morphis_, mvo was working on a config.txt inrterface, that might help around this
[09:55] <morphis_> I remember
[09:56] <morphis_> yeah saw those PRs but AFAIK it hasn't landed yet
[09:56] <ogra_> but i guess as long as the core-support interface is completely disable that wont work
[09:56] <morphis_> yeah
[09:56] <ogra_> even if it would land ... the base interface needs to come back first
[10:01] <morphis_> ogra_: ok, another thing with the latest gadget from edge for the pi3 I should be able to get Mir working, right?
[10:02] <ogra_> morphis_, i have mir kiosk running here, so yes
[10:02] <morphis_> great
[11:37] <mup> PR snapd#2940 opened: interfaces: use kmod and seccomp specs <Created by stolowski> <https://github.com/snapcore/snapd/pull/2940>
[12:03] <mup> PR snapd#2941 opened: Connectivity status interface <Created by xavi-garcia-mena> <https://github.com/snapcore/snapd/pull/2941>
[13:13] <Elleo> I seem to have got into a strange state where snapd refuses to acknowledge that an interface I'm working on exists; I've tried reverting to a known good commit but when installing snaps it still claims it's an unknown interface
[13:13] <Elleo> is there some sort of interface registry or anything that could have got into a bad state?
[13:14] <ogra_> Elleo, well, snapd re-execs to the snapd inside the core snap ...
[13:15] <ogra_> i belive your interface would have to exist inside there ... ( zyga ? )
[13:17] <Elleo> ogra_: is that a new change? this was working a couple of weeks ago
[13:18] <ogra_> not *that* new ... but also not really old ... i have to defer to zyga perhaps i'm wrong
[13:20] <zyga> Elleo: hey
[13:20] <zyga> Elleo: first of all, set SNAP_REEXEC=0
[13:20] <zyga> Elleo: otherwise your snapd will reexec and you won't see what you are hacking on
[13:20] <zyga> Elleo: second of all, is the interface supposed to be on the core snap or on a different snap?
[13:23]  * Chipaca waves at vds 
[13:24]  * vds waves back to Chipaca :)
[13:24] <Elleo> zyga: for different snaps, it's the maliit interface
[13:26] <Elleo> zyga: setting SNAP_REEXEC=0 fixes my problem, thanks :)
[13:34] <mup> PR snapd#2942 opened: tests: add core-snap-refresh test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2942>
[13:34] <zyga> Elleo: great :-)
[14:01] <didrocks> ogra_: hey! I thought the postgresql snap was using aliases (I need one example from tutorial), ideally doing aliases and config script. Do you have any idea handy?
[14:02] <ogra_> uhm ... i have neither ever used aliases nor ever used the postgres snap
[14:03] <didrocks> ogra_: ok, I'll create an example for it I guess :)
[14:04] <ogra_> didrocks, i know that samuele is our alias specialist though ... but he seems to be not on IRC
[14:04] <didrocks> ogra_: ah, I can wait for him to see if there is already an interesting example in the store
[14:05] <pedronis> didrocks: how aliases work will change again, there was some confiusion around the decision of the first implementation ... and we were asked to tweak how they works. the end result is that there will be nothing to do in the snap, it's something that developer will have to ask reviewers to setup
[14:05] <pedronis> anyway this will change in 2.24 (current estimate)
[14:06] <didrocks> pedronis: ok, thanks for the head's up. I'm only doing the consumer-side for now (snap user), so I guess that part won't change?
[14:06] <pedronis> *confusion around the decisions
[14:06] <ogra_> oops, seems i'm blind !
[14:06] <didrocks> ogra_: you're not *that* old :)
[14:06] <ogra_> (why did pe<tab> not properly expand ?)
[14:07] <pedronis> didrocks: it will change as well (users will be able to setup snaps but given that the snap itself will have no opinions they have to specify everything, unless has I said the snap has aliases setup in the store, then there is nothing to do, it's all automatic)
[14:07] <ogra_> didrocks, no, i just smell like it :P
[14:07] <pedronis> s/to setup snaps/to setup aliases/
[14:08] <didrocks> pedronis: oh interesting, ok, waiting for the change then…
[14:09] <pedronis> didrocks: so if something merits automatic aliases, it can be setup with the old way, and we will migrate it, but indeed I would not recommend asking users to play with them atm
[14:09] <didrocks> pedronis: ok, I'm just skipping that part of the tutorial for now
[14:09] <didrocks> (well, skipping writing it)
[14:10] <ogra_> or make it a one word tutorial "guess"
[14:10] <ogra_> ;)
[14:11] <didrocks> :)
[14:19] <Chipaca> ogra_— your tab completion probably doesn't expand on first tab if more than n options are available?
[14:20] <ogra_> well, i tabbed a few times
[14:21] <Chipaca> speaking of which, tab completion is a mystery wrapped in a conundrum, but the mystery is putrid and the conundrum is covered in hives
[14:21] <ogra_> hahaha
[14:22] <Chipaca> mup, poke bdmurray
[14:22] <mup> Chipaca: Plugin "ldap" is not enabled here.
[14:22] <Chipaca> ah
[14:22] <Chipaca> 6am still
[14:22] <Chipaca> anyway i'll take a break from this
[14:22] <ogra_> seems to be always 6am there
[14:22] <Chipaca> ogra_— i always get impatient about the same time i guess :-D
[14:23] <ogra_> or pacific time is actually on a fixed hour permanently :)
[14:53] <elopio> ppisati: I am back, and I am the test guy. How can I help you?
[14:57] <ppisati> elopio: https://github.com/snapcore/snapcraft/pull/1149
[14:57] <mup> PR snapcraft#1149: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1149>
[14:57] <ppisati> elopio: let's start with this one
[15:06] <elopio> ppisati: ok. That one timed out downloading a snap. There's an open bug for the store related to that. I've just retried it.
[15:06] <elopio> ppisati: you have to add unit tests to cover the code paths you added.
[15:15] <ppisati> elopio: so, is that being retried now or not?
[15:17] <ppisati> elopio: and, how about these other two:
[15:18] <ppisati> https://github.com/snapcore/snapcraft/pull/1150
[15:18] <mup> PR snapcraft#1150: kernel plugin: remove MAKEFLAGS from the environment <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1150>
[15:18] <ppisati> https://github.com/snapcore/snapcraft/pull/1148
[15:18] <mup> PR snapcraft#1148: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1148>
[15:23] <mup> PR snapd#2943 opened: many: only tweak core config if hook exists <Created by zyga> <https://github.com/snapcore/snapd/pull/2943>
[15:28] <elopio> ppisati: those two are green. I will trigger the autopkgtests there in a moment.
[15:33] <ppisati> elopio: while the other is still red for the open bug, right?
[15:37] <elopio> ppisati: the other should pass with a retry. You can add the tests, don't worry about that failure
[15:57] <kyrofa> Hey ogra_, do you have any recommendations for workaround for bug #1667865
[15:57] <mup> Bug #1667865: Unable to sideload large snap on DragonBoard <Snappy:New> <https://launchpad.net/bugs/1667865>
[15:58] <kyrofa> fstab has a big "do not edit" banner on it
[16:05] <ogra_> kyrofa, unmount /tmp
[16:05] <ogra_> (and reboot after installing the snap)
[16:06] <kyrofa> ogra_, that makes /tmp read-only
[16:07] <ogra_> huh ? shouldnt
[16:07] <kyrofa> error: cannot read POST form: open /tmp/multipart-072813492: read-only file system
[16:07] <ogra_> yeah
[16:07] <ogra_> hmm
[16:08] <ogra_> mount it to some place in /writable then
[16:09] <kyrofa> ogra_, there we go...
[16:10] <kyrofa> ogra_, what would you say is the ideal fix for that bug?
[16:10] <ogra_> well, snapd was supposed to have a fix ... by not using /tmp to unpack
[16:11] <kyrofa> Okay, agreed
[16:11] <ogra_> but i'm not sure if that has landed anywhere ...
[16:14] <mup> PR snapcraft#1162 opened: tests: pass the autopkgtest secret to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1162>
[16:24] <kyrofa> ogra_, let's say that work hadn't happened. Where is the ideal location to do this work?
[16:25] <ogra_> kyrofa, snapd i suppose
[16:25] <kyrofa> ogra_, I was thinking /var/tmp, thoughts?
[16:25] <kyrofa> ogra_, I mean on the filesystem
[16:25] <ogra_> oh, you mean the unpacking
[16:25] <ogra_> yeah, /var/tmp seems to be on disk by default alread
[16:25] <ogra_> y
[16:25] <kyrofa> Yeah I realize now I used "work" twice in the same sentence to refer to two different things :P
[17:29] <mup> Bug #1668349 opened: Classic snap fails to run  <Snappy:New> <https://launchpad.net/bugs/1668349>
[17:52] <mup> PR snapd#2944 opened: interfaces/builtin/alsa: add read access to alsa state dir <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2944>
[18:41] <mup> PR snapcraft#1162 closed: tests: pass the autopkgtest secret to the container <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1162>
[19:13] <mup> PR snapd#2943 closed: many: only tweak core config if hook exists <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2943>
[19:45] <lazyPower> kyrofa: hey there, i think you pinged me on friday re: my mail about etcd snap channel unable to find a revision
[19:47] <kyrofa> lazyPower, hmm... that was a long time ago. My memory isn't what it used to be ;)
[20:33] <mup> PR snapd#2945 opened: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2945>
[20:45] <lazyPower> kyrofa: thats true, but i'm  not positive that was you either :)
[21:17] <mup> PR snapd#2946 opened: interfaces: consistently use 'const' instead of 'var' for security policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2946>
[21:35] <zyga> jdstrand: hey, could you please have a look at https://github.com/snapcore/snapd/pull/2947/files
[21:35] <mup> PR snapd#2947: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
[21:35] <mup> PR snapd#2947 opened: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
[21:54] <mup> PR snapcraft#1163 opened: docs: update the directory where the API pages are generated <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1163>
[22:01] <jdstrand> zyga: I thought you were off this week?
[22:13] <zyga> jdstrand: starting tomorrow :)
[22:13] <zyga> jdstrand: one more https://github.com/snapcore/snapd/pull/2827
[22:13] <mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
[22:13] <zyga> jdstrand: I'd love to land that one
[22:13] <zyga> jdstrand: I did what you asked me to do, made a 2nd build of snap-confine
[22:14] <zyga> jdstrand: I have enough patches piledl locally to send one each day during all my holidays :)
[22:15] <zyga> jdstrand: the one about /etc/os-release is more important as people are hit hard by this issue (canonical-livepatch)
[22:15] <zyga> jdstrand: the scond one is just a +1 as I basically did what you asked all along
[22:15] <zyga> second*
[22:15]  * zyga wonders how a BT keyboard can be so terrible at multi-keypress
[22:16] <zyga> jdstrand: this one is really interesting: it begins the meaty part of snap-update-ns: https://github.com/snapcore/snapd/pull/2938
[22:16] <mup> PR snapd#2938: cmd/snap-update-ns: compute next action to transition mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/2938>
[22:16] <zyga> jdstrand: I'll merge master into it / rebase on master when I land https://github.com/snapcore/snapd/pull/2936
[22:16] <mup> PR snapd#2936: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <https://github.com/snapcore/snapd/pull/2936>
[22:16] <jdstrand> 2827 is already on my list
[22:16] <zyga> thank you!
[22:17] <zyga> I will be partially offline but I'll try to see what's going on next week
[22:17] <zyga> er
[22:17] <zyga> this week
[22:17] <zyga> tomorrow I just need to pack a few bits and not miss my plane :")
[22:17] <Pharaoh_Atem> hmm
[22:17] <zyga> Pharaoh_Atem: hey
[22:18] <Pharaoh_Atem> it seems stupid that you don't identify in /etc/os-release that ubuntu-core is like ubuntu
[22:18] <zyga> Pharaoh_Atem: well
[22:18] <zyga> Pharaoh_Atem: it's not
[22:18] <Pharaoh_Atem> but it is
[22:18] <zyga> Pharaoh_Atem: it is in some ways
[22:18] <Pharaoh_Atem> or add UBUNTUCORE_* IDs
[22:18] <zyga> Pharaoh_Atem: but it is so much read only that I think it is good to not identify like any other distro
[22:18] <zyga> (via ID_LIKE)
[22:19] <zyga> Pharaoh_Atem: though propose it, maybe ogra will agree and it gets merged
[22:19] <zyga> ogra_: ^ ID_LIKE=ubuntu for core
[22:19] <Pharaoh_Atem> uhh
[22:19] <Pharaoh_Atem> I'd do the following
[22:19] <Pharaoh_Atem> ID_LIKE=ubuntu debian
[22:19] <Pharaoh_Atem> UBUNTUCORE_ORIGVERSION=16.04
[22:19] <zyga> is is space-separated or comma-separated?
[22:19] <Pharaoh_Atem> space separated
[22:19] <zyga> isn't that ID_VERSION=16 ?
[22:20] <zyga> (16.04 is not a thing, core is just 16)
[22:20] <Pharaoh_Atem> I know
[22:20] <Pharaoh_Atem> but it's derived from 16.04
[22:20] <zyga> but it is 16, distinct series
[22:20] <Pharaoh_Atem> series 16 could move from derived on 16.04 to 16.10, etc.
[22:20] <zyga> no, it won't ever move
[22:20] <zyga> it will stay 16 forever
[22:20] <nacc> i don't think that's what the series means
[22:20] <zyga> we'll get 18 series but not 16.10
[22:20] <nacc> yeah what zyga said :)
[22:21] <zyga> Pharaoh_Atem: I think the more interesting question is this:
[22:21] <Pharaoh_Atem> except that you need something to match between livepatch and local
[22:21] <zyga> Pharaoh_Atem: once we have base snaps, where does /etc/os-release live? is it core or is it in the base snap?
[22:21] <Pharaoh_Atem> since you guys did the thing where you hardcode stuff
[22:21] <Pharaoh_Atem> zyga: it probably belongs in the base snap
[22:22] <Pharaoh_Atem> ideally, the core snap should only include snapd
[22:22] <zyga> Pharaoh_Atem: livepatch was hit by our bug where it could no longer realize where it is running on
[22:22] <zyga> Pharaoh_Atem: I think that bug is fixed with my PR (although devil in the details)
[22:22] <Pharaoh_Atem> the answer is not to go back to lsb-release, though
[22:22] <zyga> Pharaoh_Atem: as for core vs base I'm not sure; I think it could belong to both but it's not clear what that means
[22:22] <zyga> Pharaoh_Atem: no, I'll make sure it's not lsb_release
[22:23] <zyga> anyway, need to sleep and finish things
[23:12] <mup> PR snapd#2936 closed: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2936>
[23:13] <mup> PR snapd#2948 opened: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2948>