[04:21] <liuxg> I have configured my netplan to make the wifi working in my home on my dragon board. However, now I connect my board to an network cable in the office, the network is not working any more. Does it mean that we cannot make wifi and cable working at the same time?
[05:58] <mup> Bug #1647936 opened: Raspberry Pi 3: a small rainbow square on the top right of screen <Snappy:New> <https://launchpad.net/bugs/1647936>
[07:16] <liuxg> ogra_, ping
[07:40] <mup> Bug #1647950 opened: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware <Snappy:New> <https://launchpad.net/bugs/1647950>
[07:49] <vigo> morning snappy
[07:57] <vigo> mvo, Could you please share the candidate images link for testing? :)
[07:58] <mvo> vigo: http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/.pending/
[07:59] <vigo> mvo, yay!! thank you =)
[08:07] <dholbach> hey hey
[08:07] <seb128> hey dholbach!
[08:07] <dholbach> hi seb128
[08:32] <mup> Bug #1647992 opened: r620 core snap candidate change /etc/modprobe.d to "synced", and blacklist-watchdog.conf now cause rebooting every 7 min without iTCO_wdt module loaded <Snappy:New> <https://launchpad.net/bugs/1647992>
[09:48] <longsleep> Quick snap question, if a snap provides a binary to classic ubuntu, can the snap access files on the classic file system tree? I am only seeing apparmor DENIED whenever that binary tries it
[09:49] <Chipaca> didrocks, heya. Me again. Do you think you could get wireshark onto the pi to capture the whole thing? (or somewhere along the route to the pi)
[09:49] <Chipaca> longsleep, some but not all files
[09:50] <Chipaca> longsleep, what are you trying to access?
[09:50] <Chipaca> longsleep, no 'hidden' files, for example
[09:50] <longsleep> Chipaca: well i am trying out https://uappexplorer.com/app/hugo.hugo-authors - and the binary needs to access the files and folders from the static site, so you run it in the cwd of your site
[09:51] <longsleep> Chipaca: eg. it fails to read the config.toml file which is cwd/config.toml - it gets the absolute path right but then apparmor prevents read access
[09:52] <Chipaca> let's see...
[09:52] <longsleep> Chipaca: Snap support was added here https://github.com/spf13/hugo/pull/2443/files - and i wonder if i am just the first one to try or if i made a mistake
[09:52] <mup> PR spf13/hugo#2443: add snapcraft.yaml file <kind/enhancement> <Created by dholbach> <Closed by anthonyfok> <https://github.com/spf13/hugo/pull/2443>
[09:53] <Chipaca> ralsina, see? hugo uses snappy. Hint hint.
[09:53] <longsleep> Chipaca: yeah would be pretty awesome if it would work too :)
[09:53] <Chipaca> longsleep, details!
[09:54] <longsleep> hehe
[09:54] <longsleep> right
[09:54] <Chipaca> longsleep, is there an easy way to run it?
[09:54] <Chipaca> i mean, i just installed it, have no config.toml :-)
[09:55] <longsleep> sure, i think it can create one
[09:55] <longsleep> hold on a sec
[09:55] <tsdgeos> any idea what i may be doing wrong when trying to use the ubuntu-app-platform content interface?
[09:55] <tsdgeos> http://paste.ubuntu.com/23592699/
[09:55] <tsdgeos> t1mp: ↑
[09:56] <longsleep> Chipaca: hugo new site lala
[09:56] <longsleep> lala is the folder it would create, but it fails misterably :)
[09:56] <Chipaca> yeah, that worked
[09:56] <longsleep> oh really
[09:56] <longsleep> not for me
[09:56] <longsleep> ah
[09:56] <Chipaca> longsleep, you're holding it wrong
[09:56] <Chipaca> longsleep, hugo uses the 'home' interface
[09:56] <longsleep> Chipaca: i am on a fuse mount. Maybe thats the reason?
[09:57] <Chipaca> longsleep, which means it gets access to your home, except for dotfiles
[09:57] <longsleep> oh ok
[09:57] <longsleep> Chipaca: so when its not in home it fails
[09:57]  * longsleep tries in home
[09:57] <Chipaca> longsleep, fuse mounts are probably either /media (different interface) or something like ~/.gvfs/yadda (dotfile)
[09:57] <longsleep> Chipaca: you are right
[09:57] <longsleep> Chipaca: yes its in /media
[09:57] <longsleep> Chipaca: it works in $HOME
[09:58] <longsleep> Chipaca: anything i can do about it? I do not have enough storage in $HOME
[09:58] <Chipaca> longsleep, you could suggest to them to add whatever the interface was that gives you /media
[09:58]  * Chipaca doesn't remember
[09:58] <Chipaca> longsleep, or, you could bind-mount it into your home
[09:59] <longsleep> Chipaca: ok i see - thanks !
[09:59] <Chipaca> longsleep, the bind mount thing will not tolerate the fuse mount going away easily
[09:59] <Chipaca> but it should work
[10:00] <Chipaca> longsleep, if the fuse mount is a long-lived thing you could configure it to mount in your home directly
[10:00] <longsleep> Chipaca: yeah i understand
[10:00] <longsleep> Chipaca: no, encrypted USB device :P
[10:00] <Chipaca> LUKS-encrypted?
[10:00] <longsleep> yes
[10:01] <Chipaca> you can make that mount on boot, but yeah, a lot of work
[10:01] <longsleep> well its not connected all the time
[10:01] <tsdgeos> t1mp: ok, got it to work
[10:01] <Chipaca> longsleep, ah
[10:02] <Chipaca> longsleep, in any case, you don't need fuse for that, if you want to do the work you need to set up crypttab and fstab appropriately
[10:02] <longsleep> Chipaca: but i understand the problem now, and the snap basically works as long as the stuff is below $HOME
[10:02] <Chipaca> yep
[10:03] <longsleep> Chipaca: without fuse, how does one enter the passphrase for the key?
[10:03] <longsleep> Chipaca: i mean i have crypttab and all for the rootfs and there it prompts on bootup, but where would it prompt for optional devices on hotplug?
[10:03] <Chipaca> you get prompted for it, but I haven't tried doing it in a graphical environment
[10:04] <Chipaca> so, i don't know
[10:04] <Chipaca> sorry :-/
[10:04] <longsleep> Chipaca: fair enough - this is the snappy channel after all :)
[10:07] <didrocks> Chipaca: hum, that's going to be complex due to my current schedule, would be great if we have a prepared snap for that
[10:09] <ogra_> cjwatson, hmm, seems all core and ubuntu-core snaps failed to build due to what looks like a network error ...
[10:09] <ogra_> OSError: Tunnel connection failed: 403 Forbidden
[10:09] <ogra_> cjwatson, https://launchpadlibrarian.net/296915208/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz is an example build log
[10:21] <ogra_> Chipaca, i think bug 1647950 was something you were working on, right ? (is there a bug i can duplicate to  ?)
[10:21] <mup> Bug #1647950: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware <Snappy:New> <https://launchpad.net/bugs/1647950>
[10:22] <Chipaca> yes, a mo'
[10:25] <t1mp> tsdgeos: yes, I know what it wrong: https://bugs.launchpad.net/ubuntu-app-platform/+bug/1645731
[10:25] <mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
[10:25] <Chipaca> zyga, do you remember the bug # for the system-shutdown thing?
[10:25] <t1mp> tsdgeos: snappy bug. See https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ what is the correct order to install/connect to work around that for now.
[10:26] <t1mp> or Jamie's solution in his bug comment
[10:28] <Chipaca> ogra_, I'm pretty sure we have a bug for it; we certainly have a card and a few branches for it
[10:29] <Chipaca> ogra_, but as usual i can't find it; let's hope zyga or mvo can
[10:42] <tsdgeos> is this https://github.com/snapcore/snapcraft/pull/951 how one is supposed to do pull requests for snapcraft?
[10:42] <mup> PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
[10:43] <mup> PR snapcraft#951 opened: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
[11:06] <liuxg> ogra_, ping
[11:08] <liuxg> I used netplan to configure my wifi at home, then I went to my office. Since the wifi AP name is not right, I started to use a cable to connect my ubuntu coree device. However, I cannot find any IP address for the ubuntu core device even though I had a cable connected to it. is this a bug?
[11:09] <ogra_> liuxg, yo
[11:11] <liuxg> ogra_, I described my question above. is that a bug or a designed feature? thanks
[11:17] <ogra_> liuxg, well, if you disabled wired network it wont run
[11:18] <ogra_> if you did set a password you could do a local console login and run sudo console-conf to reconfigure it ...
[11:18] <liuxg> ogra_, do you mean I need to turn it on? I configured the netplan during the console-conf. How can I configure it again?
[11:18] <ogra_> but beyond this i dont see how you could get wired networking to work
[11:19] <ogra_> and during console-conf you configured wired network as dhcp client ?
[11:19] <liuxg> ogra_, during the console-conf, I just leave the default setting for the wired connection.
[11:20] <ogra_> well, not sure if thats enough ... thats a mwhudson question i guess
[11:20] <liuxg> ogra_, maybe not. I did not touch the default setting there. If that is the casse, would it be good to have the default setting for wired network as that?
[11:21] <ogra_> no, because you probably dont want wired to wsork for security reasons as a manufacturer ... defaulting to always have wired obtain an IP would be a bad idea here
[11:22] <liuxg> ogra_, ok. I see your point. but normally if I have a wired connection, in fact during the console-conf, I do not do anything there, and it starts to work directly.
[11:22] <liuxg> ogra_, so, I thought wired network connection came automatically without any manipulation.
[11:28] <ogra_> liuxg, iirc the firstboot code brings it up, but i'm not sure the config is applied to netplan if you dont take any action to do that in console-conf ... but as i said, thats an mwhudson question
[11:29] <liuxg> ogra_, thanks for your answering. mwhudson, what do you think of the issue? thanks
[11:45] <ralsina> Chipaca: Nikola has been snapped for MONTHS
[11:55] <mup> PR snapd#2425 opened: store: decode response.Body json inside retry loops <Created by stolowski> <https://github.com/snapcore/snapd/pull/2425>
[12:31] <renato__> mvo, sorry to disturb you again ;). Could you approve media-player-app and ubuntu-notes-app
[12:35] <mardy> pstolowski: hi! With snapctl, will it be possible to know the apparmor profile of the peer, when running inside an interface hook?
[12:50] <Chipaca> ralsina, d'oh :-)
[12:51] <Chipaca> ralsina, i typo'd my original `snap find`, i guess
[12:51] <ralsina> Chipaca: we also have a snap for coil, a nikola-based CMS
[12:51] <ralsina> that one is more experimental, tho
[12:54] <Chipaca> snap info tells me it's only in beta and edge :-)
[12:55] <Chipaca> is it really a CMS *for* Nikola, as its description says?
[12:55] <Chipaca> anyway. i've got a standup coming up
[13:03] <pstolowski> mardy, i'm not aware of such capability, sounds like something concerning apparmor more than snapd; perhaps jdstrand knows?
[13:03] <mvo> renato__: sure, soon
[13:05] <mardy> pstolowski: or, leaving apparmor aside, is it possible to somehow identify who's the snap which is connecting into your interface's slot?
[13:08] <pstolowski> mardy, that should be easily doable if required from interface hook, but syntax/semantics need to be defined
[13:12] <jdstrand> mardy: I know of no functionality in snapd for wrapping the libapparmor api. I don't know otoh if the rest api has anything about connected plugs to a snaps slot. maybe that is what interface hooks are for? kyrofa (or Chipaca) may know
[13:14] <mardy> jdstrand: yes, actually my original question was about interface hooks: I'll need a way from inside the unity8 snap to know what's the apparmor profile of the snaps connecting to the Online Accounts interface, so that I can add them to the ACL when the user enables them
[13:25] <pstolowski> mardy, so i think interface hooks will be able to expose this info during the execution of hooks, technically there is no challenge. it just needs to be defined in terms of how this is exposed
[13:27] <pstolowski> something we need to discuss with niemeyer, along other details of hooks currently in the review
[13:31] <jdstrand> mardy: you may want to read this: https://docs.google.com/document/d/1mwLfShu3K8LNa1cYySqhM0fp06TZoKygG0bs2KB9Z4I/edit# . That is something that tvoss and I came up with but it has not undergone review by niemeyer
[13:31] <mardy> pstolowski, jdstrand: thanks, reading...
[13:32] <jdstrand> niemeyer: hi! that document ^ is something we talked about me writing up ages ago but I never followed up with you after my meeting with tvoss since this is mostly about Personal and at the time Personal was far out
[13:32] <jdstrand> niemeyer: now Personal is here, so probably need to work through that. I'll let you decide on if before the end of year or not
[13:32] <jdstrand> zyga: that is probably something you would be interested in ^
[13:36] <zyga> jdstrand: looking
[13:36] <mardy> jdstrand: mmm... I'm not sure I like the proposal in that document... why does snapd need to be modified at all?
[13:36] <zyga> jdstrand: thank you
[13:36] <mardy> jdstrand: trust-store (and Online accounts) have their own storage for the ACLs
[13:37] <mardy> jdstrand: it can be maintained by whatever snap is providing the slot (unity8, in our case)
[13:37] <zyga> jdstrand: hey, are yon on rocket chat? https://rocket.ubuntu.com/
[13:37] <jdstrand> mardy: note the invariants
[13:37] <zyga> jdstrand: it's easy to join (just sso), it's browser based and has persistent ping history and other good ies
[13:37] <zyga> and it's public :)
[13:38] <jdstrand> zyga: and its browser based
[13:38]  * jdstrand joins
[13:38] <mardy> jdstrand: noted, and I don't see any conflict with what I'm suggesting
[13:40] <jdstrand> mardy: I added you, zyga, niemeyer, and pstolowski for comment (and edit) rights
[13:40] <mardy> jdstrand: thanks, will jump in right away :-)
[13:41] <jdstrand> mardy: feel free to comment. the design is based on direction from niemeyer
[13:41] <jdstrand> mardy: though again, he has not reviewed it yet, so still lots of time to comment, etc
[13:41] <jdstrand> mardy: also, this is specifically for *trust-store* and not online accounts which I understand is similar but different
[13:42] <jdstrand> but sufficiently similar in my mind that they should be considered in the same conversation
[13:43] <mardy> jdstrand: true, they are different in that location service connects the client to a system resource (the GPS), while OA connects the client to the user data (which in our case is stored by another snap (unity8) and not by the system
[13:43] <mardy> jdstrand: but I do believe that the solution for OA could be applied for the trust-store services too. Let's see...
[13:44] <jdstrand> mardy: this is meant to address multi-user. in fact it was written with pulseaudio microphone recording in mind
[13:44] <jdstrand> I think you might have been trying to express a different point there...
[13:45] <jdstrand> anyway, yeah-- let's get all the info in there
[13:51] <mardy> jdstrand: do I understand it correctly, that at the current stage, if user A manually connects a snap to the camera and user B launches that snap, the process started by user B will have access to the camera?
[13:53] <jdstrand> mardy (cc niemeyer): currently, yes. interface connections are at the system level. this document is about allowing a slot implementation to tie into snapd for mediating per-user connections
[13:54] <mardy> jdstrand: I'm starting to see the picture now
[13:57] <stgraber> mvo: hey there, why was https://bugs.launchpad.net/snappy/+bug/1628289 marked fix released?
[13:57] <mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
[13:57] <jdstrand> mardy (cc niemeyer): the gist of the document is: slot implementation 'foo' wants to provide a may to allow its services to some users but not others (via prompting or not, that doesn't matter). foo uses the trust-store library. the trust-store library under the hood talks to snapd. a user talks to foo, foo asks trust-store if this user is allowed, trust-store asks snapd, etc
[13:59] <mardy> jdstrand: all clear, I just don't see the reason for the latter point: trust store could have its own storage, just like it has on UT
[14:00] <jdstrand> mardy: that gets back to the invariant
[14:00] <mardy> jdstrand: mmm... which one?
[14:01] <jdstrand> mardy: 'Snapd should be the central authority for anything interface-connection related'. that came from guidance from niemeyer.
[14:02] <mardy> jdstrand: sure, that would still be the case: the interface between the client and the "service" snap (the one using trust store) would be autoconnected, and the interface between the service and the resource (e.g., GPS) would be manually connected via snapd
[14:02] <jdstrand> mardy: a nice feature of this approach is that a tool can be written to talk to snapd to manipulate all trust-store connections. ie, the trust-stores aren't siloed. they are in snapd. this makes it easy to see with one command all the user connections. it would help ubuntu-system-settings, etc
[14:03] <mardy> jdstrand: mmm... I think you are trying to solve two different issues with a single solution
[14:03] <jdstrand> mardy: I understand what you are saying. the storage doesn't have to be in snapd, but it is a feature that it is
[14:03] <jdstrand> mardy: please comment in the PR. this has not been approved and was following particular guidance
[14:03] <mardy> jdstrand: OK
[14:05] <mvo> stgraber: sorry, that was incorrect
[14:07] <mup> Bug #1628289 opened: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
[14:09] <jdstrand> zyga: can you send me a message on rocket?
[14:15] <zyga> jdstrand: yes
[14:15] <zyga> jdstrand: PM or @-mention?
[14:16] <mup> PR snapd#2426 opened: spread.yaml: run dmesg -c with sudo and log the id before running it <Created by plars> <https://github.com/snapcore/snapd/pull/2426>
[14:20] <jdstrand> zyga: I don't know. I closed my window to see what offline notifications look like. both?
[14:20] <zyga> OK
[14:22] <zyga> jdstrand: done
[14:24] <mardy> jdstrand: thanks for the replies! I think all what you wrote makes a lot of sense if interface connections continue to be per-system, but I hope that there are plans to change that, eventually?
[14:27] <jdstrand> mardy: there isn't a way to make them per user for the foreseeable future. apparmor policy is for the system, not per-user
[14:28] <jdstrand> mardy: therefore the trusted helpers continue to mediate their APIs like always
[14:28] <jdstrand> mardy: and this merely provides a way to move the storage to a central place
[14:29] <jdstrand> (for those trusted helpers that use trust-store)
[14:29]  * mardy thinks
[14:30] <jdstrand> mardy: I added a couple more comments to hopefully clarify. this isn't a radical change. this is adjusting the trust-store library to use snapd as its storage. that's it. with that, we can do cool things with tooling, etc
[14:30] <jdstrand> niemeyer: cc ^
[14:31] <jdstrand> niemeyer: also, sorry for all the pings, just want you to have all the context for whenever that spec is reviewed (again, doesn't have to be today)
[14:31] <jdstrand> zyga: if you sent anything, I didn't get them
[14:32] <jdstrand> zyga: via email. I logged in and see them
[14:40] <mup> Bug #1646479 opened: Unity8 applications require access to name=com.ubuntu.MenuRegistrar <snapd-interface> <Snappy:Triaged by jdstrand> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1646479>
[15:11] <cking> i'm getting 504 gateway timeouts whenever I attempt to upload updates to the snap store
[15:12] <ogra_> not only you
[15:13] <ogra_> but if you check via the store UI you will find your package got uploaded fine
[15:13] <cking> ogra_, i'm just trying to navigate on that website to check other snaps I've done and all I get is 504s
[15:14] <ogra_> go to the toplevel of the snap in the store (cut off rev/#### from the url)
[15:14] <ogra_> and you will see the revision landed fine
[15:14] <ogra_> at least thats the case for my LP builds
[15:15] <cking> heh, even that 504s on me
[15:15] <ogra_> wow, i can usually reach the toplevel
[15:16] <cking> oh, nth attempt and it worked
[15:16] <ogra_> heh
[15:16] <ogra_> its a game of patience :)
[15:16] <cking> doesn't feel that snappy to me
[15:16] <cking> no pun intended
[15:16] <ogra_> that is because the store still runs on classic :P
[15:20] <cking> ogra_, on a raspi2 I guess
[15:20] <ogra_> haha
[15:20] <ogra_> probably a pi1 with raspbian
[15:21] <cking> and the CPU clocked at 50% to make sure it don't get too toasty
[15:24] <ogra_> heh, yeah
[15:39] <alex-abreu> jdstrand, I was wondering abut the snapd-control / local snap install/connection issue we talked about a week ago, will the fix (if any) be in 2.19?
[15:43] <jdstrand> alex-abreu: I don't know. we talked about it extensively and Gustavo was going to work through a few things. I have a todo to talk to him today about it
[15:59] <alex-abreu> jdstrand, ok thx
[16:11] <seb128> sergiusens, hey, is snapcraft doing some magic to bring in libraries used by a binary you try to include?
[16:11] <mup> PR snapd#2422 closed: tests: re-enable snap-confine unit tests via spread <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2422>
[16:21] <lof_mt> Hi there. I am working through the snap tour and have little problems with "20-PARTS-PLUGINS/01-reusable-part/". Error: No CMAKE_CXX_COMPILER could be found.
[16:21] <lof_mt> Looks like the is a build dependency missing.
[16:23] <lof_mt> had to install build-essentials because of missing g++.
[16:23] <mup> PR snapd#2427 opened: cmd/snap-confine: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2427>
[16:24] <lof_mt> Please fix this. It is an easy problem to fix for me. But with a bit less experience i wouldn't be able to solve it.
[16:24] <zyga> jdstrand: poke on rocket :)
[16:24] <lof_mt> Is there a issue tracker for the tour?
[16:25] <zyga> jamiebennett: ^^
[16:26] <cwayne> zyga: is that pr what will allow us to call snaps from other snaps?
[16:26] <jamiebennett> lof_mt: Here please - https://github.com/ubuntudesign/snapcraft.io/issues
[16:27] <zyga> cwayne: no, that's classic confinement
[16:28] <zyga> cwayne: (super close, release is tonight)
[16:28] <jamiebennett> lof_mt: sorry, just looking at the backlog, the github page is correct for the tour working
[16:28] <zyga> cwayne: the other PR will be merged next cycle, I tried it and I think there are some bits missing still
[16:28] <jamiebennett> lof_mt: i.e. the page
[16:28] <jamiebennett> lof_mt: for the code itself, that is snapcraft - https://bugs.launchpad.net/snapcraft
[16:29] <cwayne> zyga: ah ok
[16:29] <zyga> cwayne: but I'll try to merge it anyway, we can see how far that gets us :)
[16:35] <lof_mt> What snap path belongs into a users $PATH?
[16:36] <nacc> lof_mt: there should be /snap/bin, added by /etc/profile.d/apps-bin-path.sh
[16:37] <lof_mt> nacc that only works if the user was create after snapd was installed right? (As the bash profile is already written)
[16:38] <nacc> lof_mt: no, /etc/profile (which is used at runtime) sources all .sh in /etc/profile.d (on ubuntu)
[16:39] <lof_mt> On debian too. But in both my users bash and zsh there is no snap path.
[16:40] <lof_mt> Must be a user not distro issue.
[16:41] <lof_mt> Thanks nacc
[16:41] <nacc> lof_mt: that seemds odd ... almost like profile isn't being read, then
[16:41] <nacc> lof_mt: but that'swhere i'd start; maybe try setting some other variable in /etc/profile (or a new.sh in /etc/profile.d) and see if your user sees it on re-login?
[16:42] <lof_mt> Works for my root user. Definitly messed the users bash profile up at some point. Haven't noticed because of zsh.
[16:42] <nacc> lof_mt: ok :)
[16:44] <stormchaser3000_> hello. i am trying to update my ubuntu gnome system and snapd wont set up during the installation or is takng a very very long time. is there any way i can fix this? and is this the right place to ask?
[16:50] <lof_mt> stormchaser3000_: The Ubuntu upgrade is finished?
[16:51] <stormchaser3000_> lof_mt: no. it just sits there saying Setting up snapd (2.16ubuntu3) ...
[16:51] <stormchaser3000_> no error message or anything
[16:51] <lof_mt> Is there a way to deploy gsettings schemas? Does the gtk3 "cloud part" anything of that for me? Or do i need to write a script that deploys the schemas?
[16:51] <lof_mt> stormchaser3000_: Graphical or cli update?
[16:51] <stormchaser3000_> cli
[16:52] <stormchaser3000_> ugh i will be back later have to go
[16:54] <lof_mt> Looks like it: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/1bff18219659caa849950858c6021eaa2289f1d0/common/desktop-exports#L102
[16:54] <lof_mt> But where do i put them?
[16:56] <lof_mt> Or is that only for making the plug work?
[16:59] <didrocks> lof_mt: you should just use the desktop parts, like destkop-gt3
[16:59] <didrocks> gtk3*
[16:59] <didrocks> it will build this script, then you only need to use command: desktop-launch <your-app>
[16:59] <didrocks> (and it will build the schemas as needed and such)
[17:00] <didrocks> + brings the deps
[17:00] <didrocks> lof_mt: some example and content: https://developer.ubuntu.com/en/blog/2016/07/06/announcing-new-snap-desktop-launchers/
[17:00] <didrocks> (note that desktop/gtk3 and others have been renamed desktop-gtk3 since this post)
[17:21] <lof_mt> Can i specify an ubuntu version with cleanbuild?
[17:26] <lof_mt> Or an existing lxd container
[17:32] <mup> PR snapd#2418 closed: snapstate/backend: add backend methods to manage aliases <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2418>
[17:32] <mhall119> is there a generic fix for relocating shared memory file creation location?
[17:32] <mhall119> snappy-debug says "adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*"
[17:33] <mhall119> but I'm hoing there's a workaround without patching or re-building the program
[17:33] <zyga> mhall119: no
[17:33] <mhall119> :(
[17:33] <zyga> mhall119: I looked at it multiple times
[17:33] <zyga> mhall119: maybe if we teach glibc about snappy
[17:34] <zyga> mhall119: but that changes semantics and exsitng software will break
[17:36] <stormchaser3000_> lof_mt: ok i am back
[17:36] <lof_mt> Did it ran through?
[17:37] <stormchaser3000_> ?
[17:37] <stormchaser3000_> no
[17:38] <lof_mt> Can you look in /var/log/dpkg.log ?
[17:38] <lof_mt>  tail /var/log/dpkg.log
[17:39] <stormchaser3000_> lof_mt: http://paste.ubuntu.com/23594390/
[17:40] <lof_mt> kill all apt and dpkg processes. We try to install it manually with dpkg, look for the error then continue with the rest.
[17:40] <lof_mt> This might be a better fit for #ubuntu
[17:41] <stormchaser3000_> ok
[17:42] <stormchaser3000_> lof_mt: that seems to have worked
[17:42] <stormchaser3000_> but i am not sure yet
[17:42] <stormchaser3000_> yep it worked
[17:42] <stormchaser3000_> thanks
[17:42] <sergiusens> seb128 yes
[17:43] <stormchaser3000_> (installing manually with dpkg -i)
[17:43] <lof_mt> stormchaser3000_:  What does that mean? Is snapd fully configured anyway?
[17:43] <stormchaser3000_> i think so. i downloaded the package and then installed it using dpkg -i
[17:43] <stormchaser3000_> and then it configured
[17:43] <stormchaser3000_> i think
[17:44] <stormchaser3000_> and then i run apt-get upgrade and then it tries to install snapd
[17:44] <stormchaser3000_> and it fails to configure
[17:44] <stormchaser3000_> i think. i am still waiting
[17:44] <stormchaser3000_> and sorry for spamming
[17:45] <stormchaser3000_> nope it isn't configuring
[17:47] <stormchaser3000_> and then it works when i manually install the package
[17:47] <stormchaser3000_> oh well. at least it works XD
[17:47] <lof_mt> Can you run md5sum on both files and compare if you get the same package? Or does the package name indicate a different version number?
[18:01] <lof_mt> about schemas again. They are installed in the right location. (/usr/share/glib-2.0/schemas/) on my local system. And on the build server they are in (prime/usr/share/glib-2.0/schemas/). But the application segfaults " GLib-GIO-ERROR **: Settings schema 'org.gnome.feedreader' is not installed"
[18:01] <lof_mt> i don't have any idea where else it has to be installed. :(
[18:01] <lof_mt> (non snap version from same git revision works.
[18:01] <lof_mt> )
[18:06] <zyga> lof_mt: it is because of chroot
[18:06] <zyga> lof_mt: http://www.zygoon.pl/2016/08/snap-execution-environment.html
[18:07] <niemeyer> alex-abreu, jdstrand: Yes, it should be in 2.19.. John has been on it
[18:08] <alex-abreu> niemeyer, ah awesome ! is there a PR for this?
[18:11] <niemeyer> alex-abreu: Yeah
[18:11] <niemeyer> alex-abreu: snapd#2415
[18:11] <niemeyer> snapd#2415
[18:11] <mup> PR snapd#2415: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <https://github.com/snapcore/snapd/pull/2415>
[18:12] <alex-abreu> thank you
[18:12] <lof_mt> zyga: i don't see how that is a problem. It should be the same path externally and internally. And both have the needed files.
[18:12] <zyga> lof_mt: prime/usr/share/whatever will end up as /snap/$SNAP_NAME/$SNAP_REVISION/usr/share/whatever
[18:12] <zyga> lof_mt: at runtime that is
[18:24] <lof_mt> zyga so the code can't open  /usr/… but needs to open $SNAP/usr/… ?
[18:24] <kyrofa> ogra_, ping
[18:25] <zyga> lof_mt: correct
[18:30] <lof_mt> Wasn't there an organise instruction for moving files around with snapcraft.yaml?
[18:36] <zyga> lof_mt: snapcraft organize can only organize files within $SNAP
[18:36] <zyga> lof_mt: you cannot currently put any contant at another location
[18:36] <zyga> lof_mt: and $SNAP expands to /snap/$SNAP_NAME/$SNAP_REVISION
[18:37] <zyga> *content
[18:43] <mup> PR snapcraft#952 opened: Add Features for Conditional Compilation <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/952>
[19:15] <renato__> jdstrand, what do you think about all telephony services. Should we have a telepathy exclusive for telepathy and another for telephony-service and history-service?
[19:16] <renato__> jdstrand, or should we include the telepathy permissions in each interface?
[19:17] <jdstrand> niemeyer: oh, John has been on it? I missed the decision. you were going to think about it over the weekend. what did you land on?
[19:28] <niemeyer> jdstrand: We're working on allowing dangerous to allow such connections
[19:28] <niemeyer> Will be on 2.20 though
[19:30] <zyga> jdstrand: can you +1 https://github.com/snapcore/snapd/pull/2427
[19:30] <mup> PR snapd#2427: cmd/snap-confine: add support for classic confinement <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2427>
[19:39] <alex-abreu> niemeyer, ah not 2.19?
[19:46] <jdstrand> niemeyer: ack, thanks!
[19:46] <jdstrand> zyga: I was reviewing it while you pinged me
[19:46] <jdstrand> zyga: I gave my feedback
[19:47] <jdstrand> +1 with an extremely minor request)
[19:49] <mup> PR snapcraft#921 closed: Add support for hooks <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/921>
[19:49] <mup> PR snapcraft#941 closed: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
[19:54] <MikeB_> Hi, can someone tell me how snaps are signed?  I can't find it in the documentation.  Long time snapcrafter, first time publisher.
[19:57] <jdstrand> niemeyer: also, just fyi, I think I responded to all your feedback in the dbus PR. it got a bit lengthy on the why and to detail an investigation as to if we could do something different, but I did at least distill it down to a few options. feel free to ask if you have any questions. fyi, I'm here all this and next week so it isn't critical for today or anything
[20:08] <wililupy> question: I'm getting the following error: cannot find signatures with metadata for snap when I try to install a snap, even in devmode? Any ideas?
[20:10] <wililupy> I'm also getting an error logging into the store: error: cannot get snap access permission from store: Post https://myapps.developer.ubuntu.com/dev/api/acl/: dial tcp: lookup myapps.developer.ubuntu.com on [::1]:53: read udp [::1]:42500->[::1]:53: read: connection refused
[20:13] <moritz_> How do i delete old versions of a snap?
[20:13] <wililupy> disregard. It was a DNS issue. I manually added 8.8.8.8 to /etc/resolv.conf and I can login to the store.
[20:14] <moritz_> snap remove --recision x7 it is
[20:15] <wililupy> I'm still getting the first error though.
[20:15] <cholcombe> sergiusens, how does the get_build_properties override work?
[20:16] <jdstrand> renato__: so, I haven't really thought this through. I don't really know the relationship between telepathy and telephony-service. iirc, history-service just needs to listen to one or both of them
[20:17] <jdstrand> renato__: are telepathy and telephony-service completed separate or do they interact with each other? is telephony-service a Canonical/unity8-only thing? iirc, history-service is a Canonical/unity8 thing
[20:17] <jdstrand> s/completed/completely/
[20:20] <renato__> jdstrand, from what I understand the telephony-service uses telepathy internally but the apps (messaging/dialer) talks with telepathy direct too
[20:22] <jdstrand> renato__: to me that suggests that they should be together, espcially if 'uses telepathy' is more than just some ipc calls (eg, plugin or something)
[20:23] <renato__> salem_, hey, could you give us some more information about telephony;/telepathy/history
[20:23] <salem_> renato__, sure
[20:24] <renato__> salem_, just pasted to you the backlog
[20:24] <wililupy> This is the only error in the syslog when I try to install the snap: Dec  7 20:23:10 localhost /usr/lib/snapd/snapd[2416]: daemon.go:170: DEBUG: uid=0;@ POST /v2/snaps 4.295801232s 400
[20:24] <renato__> jdstrand, I kind of agree to keep telepathy internally on the interfaces. But will niemeyer agree with that ;)
[20:25] <renato__> I remember that we have a similar discussion about the contact/calendar interface
[20:25] <salem_> renato__, both telephony-service, history-service and the apps talk to telepathy directly
[20:25] <jdstrand> renato__: well, he is a reasonable person. we'll come up with what we think is best, present and then have a chat
[20:26] <jdstrand> renato__: we did and I was thinking this maybe should be unity8-... too. let's see what the architecture is
[20:26] <jdstrand> salem_: how is that communication done? via some ipc mechanism (eg, dbus)?
[20:26] <salem_> jdstrand, dbus
[20:27] <salem_> jdstrand, apps also talk to telephony-service and history over dbus.
[20:27] <jdstrand> salem_: are telephony-service and history-service freestanding? ie, they don't plug into telepathy in some way do they?
[20:28] <cholcombe> anyone know how the plugin get_build_properties is supposed to work?
[20:28] <jdstrand> salem_: or put another way, are they three independent processes with independent dbus apis that happen to talk to each other?
[20:29]  * jdstrand thought he remembered telepathy being extendable but doesn't know the mechanism for that
[20:29] <salem_> jdstrand, exactly. they are independent processes. actually. telephony-service provides 3 binaries: handler, indicator and approver.
[20:30] <jdstrand> ok, so this does suggest three difference interfaces
[20:30] <jdstrand> (to me)
[20:31] <salem_> jdstrand, so, mission-control (which is the telepathy main process) does support plugins, which are shared objects.
[20:31] <jdstrand> salem_: do you know if telepathy on unity8 is a standard full-blown telepathy or are we only using a small subset of it?
[20:31] <jdstrand> salem_: that's it, I remember now. but telephony-service and history-service aren't using shared object plugins, correct?
[20:32] <salem_> jdstrand, no, they only talk to each other over dbus.
[20:32] <jdstrand> great
[20:33] <salem_> jdstrand, there is one open issue that telephony-service provides some protocol files that are read by the apps, but we are in a process of moving this to dbus as well
[20:33] <jdstrand> salem_: that would probably be best for working with snappy unless you were going to share them via the content interface
[20:34] <salem_> jdstrand, yes, that's why we are moving them to dbus.
[20:34] <jdstrand> salem_: what about my question regarding our use of telepathy (mission-control) on unity8?
[20:37] <salem_> jdstrand, sorry. I missed that question.. so unity8 imports a qml plugin from telephony-service that turns it into a telepathy-client to be able to display the call activity. But as it becomes a telepathy-observer, mission control will talk to unity8 over dbus as well.
[20:38] <salem_> jdstrand, unity8 is a telepathy client just like any other app (messaging-app or dialer-app)
[20:38] <jdstrand> salem_: ok, thanks
[20:38] <salem_> (and media-hub IIRC)
[20:38] <jdstrand> renato__: I suggest this: http://paste.ubuntu.com/23595117/
[20:39] <jdstrand> renato__: 3 services. telepathy stands alone. telephony-service and history-service can talk to telepathy and offer services to connecting clients
[20:40] <jdstrand> renato__: the names of these things may change as part of the PR process, but prepending unity8- for now
[20:40] <renato__> jdstrand, then apps will request access to telepathy + any other interface [history, telephony]
[20:41] <jdstrand> renato__: yes
[20:41] <renato__> salem_, will be possible to use history-service without telepathy?
[20:41] <salem_> renato__, not currently, it's telepathy based.
[20:42] <mup> PR snapd#2427 closed: cmd/snap-confine: add support for classic confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2427>
[20:43] <renato__> jdstrand, we kind of agree to use communication-history (history-service), communication (telephony-service).  what do you think? (unity8-communcation, unity8-communication-history)
[20:43] <jdstrand> renato__: there might be some attibutes in there. eg, by default an app can get safe telepathy apis but say, telephony-service might specify an attribute to get 'unsafe' apis. we'll know more in the PR
[20:44] <jdstrand> renato__: that seems fine
[20:44] <renato__> jdstrand, ok I will prepare the necessary changes on history and telephony service
[20:45] <renato__> salem_, thanks
[20:45] <renato__> jdstrand, thanks
[20:46] <jdstrand> renato__: the question then becomes, do we want to have telepathy be 'telepathy' or 'unity8-telepathy'. I think it depends on if we use telepathy like we do eds in Personal, or will we support the full-on mission-control5 for the world
[20:46] <moritz_> Do i need a plug for accessing ~/.config/my-app ~/.local/share/my-app?
[20:46] <jdstrand> renato__: I'll let you ponder that
[20:47] <renato__> jdstrand, ok telepathy interface is the next in the queue
[20:47] <jdstrand> moritz_: HOME is set to /home/user/snap/$SNAP_NAME/$SNAP_REVISION so in that sense, no. ~/.config/my-app is /home/user/snap/$SNAP_NAME/$SNAP_REVISION/.config
[20:47] <jdstrand>  /my-app
[20:48] <moritz_> So the user loses all configs when uninstalling the app?
[20:50] <renato__> moritz_, why do you want to keep the config after uninstall the app?
[20:51] <jdstrand> moritz_: yes. by design all files in the snap's area are removed on uninstall. you can use 'disable' instead of remove to make it unavailable to users on the system without removing data
[20:51] <renato__> this is something that I always complain on current debian dist. The config for olds apps are never removed
[20:52] <moritz_> renato__: i agree and disagree (the vim config argument). but this is not the place to discuss.
[20:52] <moritz_> thanks jdstrand
[20:52] <jdstrand> moritz_: I believe there is a bug on it if you want to weigh in
[20:52] <jdstrand> personally, I don't like the data loss part of it, but I understand the motivation
[20:53] <moritz_> If the app uses webkit do i need "browser-support"?  How much webbrowser is a webview? :)
[20:55] <jdstrand> moritz_: it depends on the webkit. qtwebkit needs something out of browser-support iirc. a simple renderer wouldn't. that interface is about supporting chromium content api (google chrome, chromium, oxide, electron, etc) and firefox
[20:56] <moritz_> Asking because of this error: Unable to fork a new WebProcess: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess" (No such file or directory)
[20:57] <moritz_> (yes i noticed the no such file, just though about potential issue still to come)
[21:00] <jdstrand> moritz_: it sounds like it isn't finding WebKitNetworkProcess where it wants to. that file is likely in /snap/$SNAP_NAME/$SNAP_REVISION/usr/lib/...
[21:01] <jdstrand> moritz_: I suggest using the desktop part. beyond that, I'm going to hand off to others with more experience working with GNOME libraries, etc on snappy
[21:02] <moritz_> Already using the desktop part. → https://github.com/lightonflux/feedreader-snap/blob/master/snapcraft.yaml
[21:03] <jdstrand> moritz_: you might ask didrocks when he comes back online if no one else answers
[21:06] <moritz_> I think i might need to add something in staging. The file is just not included in the snap (at all). But it is locally and in the gnome runtimes of flatpak.
[21:07] <sergiusens> cholcombe like https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/tar_content.py#L29
[21:08] <sergiusens> cholcombe it replaces the `pull|build-properties` from `shema`
[21:09] <cholcombe> sergiusens, ok.  So do I do the normal schema part in there as well to get access to the rust-feature yaml info?
[21:09] <sergiusens> cholcombe yeah, the schema part is fine and stays
[21:10] <sergiusens> cholcombe in retrospect, that method could of been an attribute but we'd have had precedent for adding logic in there
[21:10] <cholcombe> ok cool so i leave schema['properties']['rust-features'] and then later in get_build_properties i just return super().schema['properties']['rust-features'] ?
[21:10] <sergiusens> cholcombe yup
[21:11] <cholcombe> ok nice
[21:11] <cholcombe> should i move that code block out of the schema function also?
[21:11] <cholcombe> or does it need to be set in there also?
[21:19] <sergiusens> cholcombe you can move it out (the `pull-properties` and `build-properties` keys into `get_pull_properties` and `get_build_properties` plugin methods)
[21:19] <cholcombe> sergiusens, ok
[21:29] <moritz_> Can confirm that i forgot it libwebkit2gtk-4.0 as a staging package.
[21:41] <wililupy> Question: if the file exists, how can I use organize to overwrite the existing file?
[21:45] <kyrofa> wililupy, you can't, it'll conflict
[21:45] <kyrofa> wililupy, but you can filter the one that's there out of the part that's providing it
[21:46] <wililupy> kyrofa: I noticed that. How do I filter it out?
[21:46] <kyrofa> wililupy, if we're talking the `stage` step, use the `stage` keyword. If the `prime` step, use the `snap` keyword
[21:47] <wililupy> kyrofa: My source is a deb file. What I am doing now is running snapcraft build, then going into parts/part/install/opt/file/file.py and replacing it with a file.py that allows the snap to work.
[21:47] <wililupy> Then I run snapcraft snap to complete the snap.
[21:47] <kyrofa> wililupy, easy
[21:47] <kyrofa> wililupy, you're use the dump plugin I assume?
[21:48] <wililupy> kyrofa yes
[21:49] <kyrofa> wililupy, try this: http://pastebin.ubuntu.com/23595408/
[21:50] <kyrofa> wililupy, now that part will still have opt/file/file.py in its installdir, but it won't be included when that part is migrated to stage or prime
[21:50] <kyrofa> wililupy, so another part can provide it
[21:51] <wililupy> kyrofa, so remove the file from stage and snap and then use orgnaize to put the file in?
[21:51] <kyrofa> wililupy, use another part to put that file in. That may or may not involve the organize keyword
[21:56] <wililupy> kyrofa: http://pastebin.ubuntu.com/23595436/ Does this look right?
[21:57] <kyrofa> wililupy, no, `snap` is a list just like `stage` is
[21:57] <kyrofa> Not an object (like organize or filesets)
[21:59] <wililupy> kyrofa: Gotcha. So then I will use organize to put the file in under snap: ?
[21:59] <kyrofa> wililupy, we're missing each other a little, I think
[22:00] <kyrofa> wililupy, snapcraft isn't really going to help you if you want to replace a part's file _within the same part_
[22:00] <kyrofa> You'll need to do that as part of the build system
[22:00] <kyrofa> wililupy, you need to split this into two parts. One part with the file filtered out, and another that supplies the new file
[22:00] <wililupy> kyrofa: Ok. I see what your saying.
[22:01] <kyrofa> Does that make more sense?
[22:01] <wililupy> kyrofa create a new part and source the old part and use orgnaize to put the corrected python script in place.
[22:02] <kyrofa> wililupy, that's sounding right, but can you define "source the old part"?
[22:02] <wililupy> kyrofa: can I put in a feature request to have dump delete files? ;)
[22:02] <kyrofa> wililupy, that's exactly what the stage/snap keywords are for
[22:03] <kyrofa> wililupy, and they can be used by all plugins, not just dump
[22:05] <wililupy> kyrofa: I guess I'm not sure how I would source the previous part.
[22:06] <kyrofa> wililupy, I don't actually know what you mean by that :P
[22:06] <kyrofa> wililupy, so let me ask: you have a deb that includes opt/flexswitch/flexswitch
[22:07] <wililupy> I was thinking of creating another part in my snapcraft.yaml and under source, point to the parts/flexswitch and use the dump plugin.
[22:07] <kyrofa> wililupy, you don't want that one, though, you want another one
[22:07] <wililupy> But I don't think they will work.
[22:07] <kyrofa> wililupy, no, don't do that
[22:07] <kyrofa> wililupy, parts are supposed to be independent
[22:07] <kyrofa> wililupy, that "other one," from what I see in this YAML, is actually also contained within the deb. Is that correct?
[22:08] <wililupy> krofa: yes. the deb package includes opt/flexswitch/flexswitch, however, in a snap environment, it fails, so we have a python script with $SNAP and we want to put that one in place
[22:10] <kyrofa> wililupy, where is the "python script with $SNAP" ?
[22:10] <wililupy> its in the same directory as my snapcraft.yaml
[22:10] <kyrofa> wililupy, perfect-- completely independent of the other part
[22:11] <kyrofa> wililupy, make another part using the dump plugin and `source: .`
[22:11] <kyrofa> wililupy, then use organize to put it in the right place, and voila
[22:11] <wililupy> perfect
[22:11] <wililupy> I'll try that.
[22:14] <wililupy> kyrofa: http://pastebin.ubuntu.com/23595491/ Is this correct?
[22:15] <kyrofa> wililupy, yes, that looks perfect!
[22:15] <wililupy> kyrofa: Ok, time to test it out.
[22:26] <wililupy> kyrofa, so it built, but when I try to install it on my device, I get the following error: error: cannot find signatures with metadata for snap "flexswitch_1.0.0.174.6_amd64.snap"
[22:27] <kyrofa> wililupy, https://askubuntu.com/questions/822765/snap-install-failure-error-cannot-find-signatures-with-metadata-for-snap
[22:29] <wililupy> kyrofa, that did the trick.
[22:44] <mup> PR snapd#2428 opened: debian: add dependencies and build rules for snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2428>
[22:53] <moritz_> How do i tell my snap app (primary binary) to start a daemon from within the snap? At the moment it starts the binary from my system because the local copy is first in my PATH.
[23:12] <wililupy> Do we have an example of setting the LD_LIBRARY_PATH to a specific library directory in the snap? IE $SNAP/opt/file/lib/ ?
[23:16] <jdstrand> zyga: hey, fyi, I was looking at snap-confine in xenial-proposed and noticed that there are several files in debian/patches that are not applied in debian/patches/series and can therefore be removed