[00:53] PR snapcraft#937 opened: Incorporate all part properties into state tracking [01:18] When I run refresh-bits ala git@github.com:zyga/devtools, I get an error about not having systemd installed? (running zesty) [03:46] Bug #1646333 opened: bind mounts related to content interface plugs remain stale on snap disconnect/connect or snap updates [03:53] PR snapd#2391 opened: Discard mount namespace on a content i/f plug connect/disconnect === chihchun_afk is now known as chihchun === Ian|zh_CN is now known as IanLi-AFK [07:38] bonjello [07:57] PR snapd#2390 closed: tests: do not use external snaps [07:57] hey hey [07:57] o/ [07:58] hey dholbach zyga, how are you? [07:59] salut seb128 [07:59] doing all right - how about you? [07:59] I'm good thanks :-) [08:49] seb128: hey, I'm good :-) how are you? [09:07] zyga, I'm good thanks ;-) [09:32] guys, snapcraft should never use one of my libs from /usr to end up in the snap but instead use the libs from the .deb files it downloads, no? [09:35] I would intuitively expect the .deb files to take priority [09:36] because i think i found a case in which is not happening [09:36] which i have to say was unexpected [09:38] tsdgeos: that's a bug [09:38] tsdgeos: without knowing the details I can't say whether it's a bug in snapcraft, or in your yaml [09:41] Chipaca: how would the yaml make that happen? [09:42] tsdgeos: if the lib needed isn't in the deb you download (or maybe even if it's in the deb but needs the library path tweaked by postinst) [09:44] ok [09:45] Bug #1646415 opened: cannot run configure hook [09:48] Bug #1646415 changed: cannot run configure hook [10:43] PR snapd#2392 opened: partition: add support for native grubenv read/write and use it [11:02] ng [11:02] good morning [11:02] hey caio1982 [11:11] hi, I get ❯ env LANG=C ./electron-quick-start ./electron-quick-start: line 6: cd: /lib/node_modules/electron-quick-start: No such file or directory ./electron-quick-start: line 7: /bin/npm: No such file or directory [11:12] I tried this example http://bazaar.launchpad.net/~3v1n0/+junk/electron-quick-start-snap/files [11:19] mvo, hi, could you approve this MR? https://myapps.developer.ubuntu.com/dev/click-apps/6062/rev/21/ [11:26] renato__: sure [11:27] mvo, thanks [11:45] PR snapd#2393 opened: interfaces/apparmor: use distinct apparmor template for classic [11:52] PR snapd#2372 closed: interfaces/seccomp: add support for classic confinement === __alecu__ is now known as alecu [13:00] mvo, could you approve two more packages: https://myapps.developer.ubuntu.com/dev/click-apps/6019 rev 7 and 8 [13:12] mvo, same for address-book-app: https://myapps.developer.ubuntu.com/dev/click-apps/6010 rev 19 and 20 [13:21] ogra_ ping [13:21] hey ondra [13:22] ogra_ hi, this would be simple one, in shell script, what is best reliable way to detect app is running as snap? [13:23] hmm ... check the path of the binary ? [13:23] something like that [13:23] there is a bunch of $SNAP_ variables you could look for [13:23] how about check is SNAP_COMMON exist? [13:23] SNAP_NAME or SNAP_VERSION .... [13:24] ogra_ is it something we will keep for foreseeable future? [13:24] i guess so [13:24] ogra_ OK, then I will stick to those :) [13:24] ogra_ cheers! [13:24] install hello-world, run hello-world.sh ... [13:24] then check the env [13:25] (or there is even a hello-world.env i think) [13:25] ogra_ yeah there is [13:31] jdstrand, renato__: I approved https://myapps.developer.ubuntu.com/dev/click-apps/6010/ - what is needed to make this automatic? [13:32] mvo, I know that jdstrand is working on it. I am not sure about the status [13:32] renato__: aha, sure, thats fine then [13:33] mvo, could you approve 6019 too? [13:34] renato__: I did, didn't i? [13:34] mvo, no still blocked [13:36] renato__: oh, you are right [13:36] mvo, thanks [13:49] should I push a BS commit to trigger the autopgktests on this again, or maybe merge in master for the commit to get the fix from master? https://github.com/snapcore/snapcraft/pull/908 [13:49] PR snapcraft#908: Let Rust plugin fetch dependencies in pull [13:49] mvo, sorry to keep disturbing you, but 6019 rev 9 still blocked :( [13:51] renato__ (cc mvo): you need to request a manual review [13:51] renato__: it doesn't show up in the list unless you do that [13:52] jdstrand, humm sorry I miss this one [13:52] renato__: and the person who pushes that button can't then approve it [13:52] (so it can't be us) [13:52] mvo: I handled it [13:52] thanks [13:52] renato__: done [14:00] jdstrand: thanks, was in a meeting === mup_ is now known as mup [14:12] sergiusens, kyrofa I've discovered a bug with source-type: deb [14:12] Want to find out if it is known. [14:13] If you use a deb as source and that deb has sym-links in it, the link names are created as directories in the snap. [14:14] In my use case the binary is trying to load a lib which is effectively doesn't exist. === chihchun is now known as chihchun_afk [14:23] PR snapd#2394 opened: snap: show last update time [14:26] PR snapcraft#938 opened: store: return specific error when already owned === jamespag` is now known as jamespage [14:32] mvo, could you comment on https://github.com/snapcore/snapweb/pull/101 ? [14:32] PR snapweb#101: replace find vs findone [14:36] PR snapd#2395 opened: make state and squashes immutable when appropriate [14:39] alex-abreu: let me have a look [14:47] jdstrand: hello, I have a question about this bug https://bugs.launchpad.net/ubuntu-ui-toolkit-examples/+bug/1645377 [14:47] Bug #1645377: AppArmor policy error for networking at initialization, even with the correct network plug.

[14:48] jdstrand: that app just wants to download something from internet, for that it should not need to use the network-manager interface right? [14:48] any ideas why it currently needs that? [14:54] popey, hey, could you review this? https://code.launchpad.net/~renatofilho/ubuntu-calculator-app/unity8-snap/+merge/312260 [14:56] renato__: why do you need unity7 and unity8? [14:57] timp, the unity8 session that tedg is working needs unity8 interface. And unity7 is to keep it compatible with unity7 [14:59] renato__: ah, ok. Will we need to add unity8 to all GUI apps? [14:59] timp, I think so [15:00] renato__: hmm.. and all GUI apps also need opengl I guess. So maybe we should find out if it is possible for [platform] to also imply [opengl, unity7, unity8] [15:00] I don't know if it would work if we simply add those plugs to the ubuntu-app-platform snap. [15:02] sergiusens: ^how would we do that? [15:02] timp, I am not sure about that. I think that is ok to explicitly say which interface you app request. S [15:02] timp, and some apps can be ready only for unity7 [15:03] renato__: but if you use the platform snap, you'll need all those plugs [15:03] timp, some apss can uses plataform and does not have any ui [15:03] renato__: ah, that's true. [15:03] hmm [15:03] well the core of the platform (at least the dependencies that we put in there first) is the UITK [15:04] timp, i can have a app that only uses qtcore or network, etc.. [15:04] hmm [15:04] yeah [15:04] but would you use the platform snap then? Platform has a lot more than just qt. [15:04] but if you don't want to compile qt, then currently the platform snap is what you need to use. [15:04] timp, if the plataform is part of the system already. I do not see why not use that [15:07] That really depends on the use case. [15:07] if I have a gadget that only runs my app problably I can pack qt on it. [15:07] yes [15:07] renato__: ok. We can leave it as it is for now then :) [15:09] popey, one more: https://code.launchpad.net/~renatofilho/ubuntu-clock-app/unity8-snap/+merge/312263 [15:13] timp: you are right, it shouldn't need network-manager. It is (almost certainly) only accessing network-manager to see if the network is available. this is a very longstanding conversation regarding Qt and network-manager and is precisely why connectivity-api was developed. see bug #1341548 [15:13] Bug #1341548: Online detection does not work with confined apps on Nexus 4

[15:13]

[15:17] jdstrand: so I will be required to use connectivity-api whenever I access the network, even when I use the [network] plug already? [15:24] in which channel should I ask about snap store reviews and automatic publishing of LP projects to the store? [15:24] maybe here? [15:25] here :) [15:25] Ok. :) I configured https://launchpad.net/~ubuntu-sdk-team/+snap/ubuntu-ui-toolkit-examples to automatically upload a snap on the edge channel in the store, but on https://myapps.developer.ubuntu.com/dev/click-apps/6427/rev/3/ it appears in the Release channel [15:25] ^is that a bug? [15:25] renato__: no idea, sorry [15:25] renato__: did you trace the calls from that failure back to base policy? [15:26] ignore my question. It was already answered somewhere else timp: that's not a channel name, that's the action button to release it into channels [15:26] heh [15:26] i was about to ask what you mean with release channel [15:27] ogra_: new channels, there's one every weekend ;) [15:27] matrix keeps changing [15:27] heh [15:27] ogra_: right :) [15:28] who can I kick to review the ubuntu-ui-toolkit-examples snap in the store? [15:28] Hello. snap store seems to be very slow. I get constant timeouts when clicking on revision? Any idea what's up with it? [15:30] timp: if your app is trying to check if the network is available, it will need to plugs something else, yes. if it is using network-manager, it needs to plugs network-manager (that will require a snap interface manual connect), if it is using connectivity-api, it needs to plugs it (that will be auto-connected) [15:30] timp: note that connectivity-api interface isn't available yet. it is part of the Ubuntu Personal work. I don't know the status [15:31] jdstrand: so if you use network you will always need network-manager or connectivity-api? [15:31] zyga: fyi, you mentioned not looking for other occurences of the i2c bug. I just did. i2c is the only thing not using utils.go and utils.go is fine [15:31] I assume when you use the network, it will check whether that's available. [15:32] timp: plenty of apps need only 'plugs: [network]'. your app is trying to be smart and as a result it needs to plugs something else [15:32] (in addition to network) [15:33] jdstrand: good to know, thank you [15:33] timp: in Ubuntu Touch, we put connectivity-api in the network policy group. the core snap does not have the connectivity-api daemon in it, so it will be provided via a snap. as such, you will need to 'plugs: [network, connectivity-api]' on snappy (whenever connectivity-api is available) [15:33] jdstrand: I'm iching to rewrite interfaces internally as we discussed, maybe over xmas :) [15:33] itching* [15:34] zyga: heh, please make sure that the policy remains easily auditable within the codebase. that's all tyhicks and I are asking :) [15:35] jdstrand: This is the full app http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/examples/jokes/jokes.qml [15:35] jdstrand: as agreed :) [15:35] It does not seem to do anything smart, I guess the XMLHttpRequest(); does that then. [15:35] jdstrand: I'd definitely do that to ensure my sanity :) [15:35] I'm just thinking how to make it easy for developers to use that. [15:36] I don't know the details of what the XMLHttpRequest object does, just trying to snap the UITK examples. [15:37] timp: if this is for qtubuntu apps, seems reasonable to default the snapcraft.yaml to use 'plugs: [network, connectivity-api]' just like for click it use '"policy_groups": ["network"]' [15:37] timp: in the sdk [15:40] jdstrand: yes, it is a qtubuntu app (using the ubuntu-app-platform snap) with "network" int he policy groups. [15:41] jdstrand: I'll add a note in my snapcraft.yaml to add that when the connectivity-api is done. Let's see if I can find the bug for that. [15:47] ogra_: Still looking at this week for that Azure bug? [15:48] Odd_Bloke, bug 1639878 ? [15:48] Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v [15:48] ogra_: Yep. [15:48] (new kernel snap is in edge with the modules included) [15:48] Oh, I must not be subscribed, I hadn't seen updates. [15:48] Fail. [15:49] not sure when the next release is planned though ... mvo might know [15:49] then it should hit stable [15:51] ogra_: next release is next thursday [15:51] Odd_Bloke: -^ [15:51] :) [15:52] Cool, thank you both! [15:52] ogra_: I think we can bump the kernel to beta now (if it booted) and then I can ask qa to test it [15:53] mvo, yeah, though we are missing an updated rpi2 one it seems [15:53] dragon and pc broth had updates since my vacation [15:53] pi not [15:54] ok [15:54] not sure what keeps it in proposed ... ppisati ? [15:54] but we can indeed push the others up to beta [15:57] ogra_: thank you! [15:58] mvo, btw this wont be added back to 2.18 right ? https://github.com/snapcore/snapd/pull/2394 [15:58] PR snapd#2394: snap: show last update time [15:59] alex-abreu: correct, this is targeted for 2.19 [15:59] mvo, ok thx [15:59] (which is just one week away :) [15:59] mvo, even better thx :) [16:31] PR snapd#2396 opened: tests: fix incorrect restore of the current symlink [16:32] jdstrand: can you join a call about classic confinement and the store now? [16:34] flexiondotorg, just ANY symlink? [16:34] flexiondotorg, not known by me anyway [16:35] flexiondotorg, ah, wait, LP: #1634813 [16:35] Bug #1634813: Symbolic links inside .deb pulled as directories [16:35] kyrofa, Yep, that is the issue. [16:35] I'll subscribe to that. [16:36] I've got a fix in progress. [16:36] flexiondotorg, thanks for the poke. Ah! You know what the issue is? [16:36] kyrofa, The issue is apt_install.extractall() doesn't do the right thing. [16:37] The Tar() class in internal/sources.py does the right thing, so can be the basis of a fix. [16:37] Good deal. Happy to investigate if you're short on time, let me know? [16:38] Well, I'll be leaving the office in a bit. [16:39] flexiondotorg, alright I'll take a look once I'm done with my current PR [16:39] kyrofa, Thanks. [16:39] I'm just finishing something else too. [16:40] flexiondotorg, thanks for the pointers :) [16:40] In the Tar() class you'll see the _extract() method. That is what I was going to reimplement for the Deb() class. [16:44] Howdy all - setting up snappy, however the key on my ubuntu one account was dsa - and I can't SSH in with it because it is a rejected protocol. Anyway to trigger the snappy device to redownload my ssh public keys? [16:45] (without logging in or running a fresh install) [16:50] ogra_, do you know the answer to that question? ^^ [16:57] nope [16:57] i saw the question before ... have never used a dsa key [16:57] (i think someone asked the same at the beginning of the week) [16:59] kyrofa, sounds more liek a question to some store person :) [16:59] *like [17:00] ogra_, indeed, thank you. nessita, are you around? [17:01] mvo, you might be able to help with that as well. Is there any way to trigger Ubuntu Core to re-download SSH keys? 1) as a logged in user, and 2) without being able to login? [17:08] kyrofa, around otp, could you repeat the question? [17:10] niemeyer: can you meet now for snap decl talk>? [17:10] jdstrand: Yep, is your mic working agian? [17:10] https://hangouts.google.com/hangouts/_/canonical.com/base-declaration [17:10] niemeyer: I'll get it to work. can you start a new hangout and I'll join? [17:10] ok [17:12] niemeyer: it says I am the first to join [17:12] nessita, sure thing-- bitpushr had a dsa key on his SSO, so when Ubuntu Core fetched the keys that's all it got, and it doesn't work. If he's since uploaded an rsa key, do you know if there's a way to re-trigger the key download? [17:22] kyrofa, hum, I have no idea, the store is not involved in that part [17:22] other than providing an API to get all the public sshs for an emai; [17:22] email* [17:23] nessita, yeah, me neither :( . Alright, thanks for your time! [17:33] kyrofa, :-) [17:33] kyrofa: you have same issue? [17:33] kyrofa: refreshing keys is still a TODO afaik [17:33] bitpushr, I'm afraid not, I use rsa keys [17:34] It would be a good idea to refresh them on boot at least [17:34] I thought it might but it does not [17:34] pedronis, so what is the path forward. A reinstall? [17:34] I don't know [17:35] No worries, but I would like to put that in as a feature request. Would also help handle expired keys, updated keys, etc [17:35] This was an old key I had [17:35] flexiondotorg will look into it [17:36] flexiondotorg but we are using the python deb extraction implementation [17:41] jdstrand, could you approve messaging-app package in the store: https://myapps.developer.ubuntu.com/dev/click-apps/6192 rev 4 e 5 [17:45] bitpushr: I created this https://bugs.launchpad.net/snappy/+bug/1646559 [17:45] Bug #1646559: should periodically refresh ssh keys that were obtained from SSO/store for local users [17:45] Bug #1646559 opened: should periodically refresh ssh keys that were obtained from SSO/store for local users [18:00] Thank you pedronis [18:07] renato__: looking now. sorry was in meetings [18:12] jdstrand, np. thanks [18:40] tyhicks, jdstrand: https://github.com/snapcore/snap-confine/pull/199 [18:40] PR snap-confine#199: Add error support code [18:41] this is a prelude to https://github.com/snapcore/snap-confine/commit/f7ee6df44916109731ce8a611ff57d9a70954b56 [18:42] and on top a small patch that adds --classic support [18:44] PR snapcraft#900 closed: ftp source support [18:47] which is https://github.com/snapcore/snap-confine/commit/6f289caa3a7adcfcedef25c13378fb9bd5de2f95 [18:47] PR snapcraft#939 opened: Replace coveralls with codecov [18:47] I got a +0.5 from mvo on telegram, I'd love a review from you [18:47] one more branch and I'll switch to that for parsing command line [18:48] and then (no-op) classic can be dput to a image ppa [18:48] PR snapd#2387 closed: asserts: introduce auto-aliases header in snap-declaration [18:51] PR snapd#2396 closed: tests: fix incorrect restore of the current symlink [18:52] PR snapd#2369 closed: snap: disable support for socket activation [19:26] PR snapcraft#940 opened: Implement delta uploads in push [19:58] niemeyer, do you have an update on the snapd-control & install/connect issue for local snaps? [20:02] alex-abreu (cc niemeyer): we had a meeting today. we are getting close to having an answer [20:03] jdstrand, ok it will be backported to 2.18 right ? [20:03] alex-abreu: that is the intent, yes [20:04] jdstrand, thank you, ... any eta? [20:04] alex-abreu: well, no since we don't have the answer yet [20:05] but getting there. once we've worked through the answer, someone will send something to the list [20:05] jdstrand, ok, ... thank you [20:05] is there anny chance of (non-root) installable snaps? [20:09] icey, probably not, at least not in the near future [21:30] jdstrand: Are the snap confine tools closing all the file descriptors? [21:30] jdstrand: Trying to pass one through and it's not making it... [21:37] jdstrand: hey [21:37] tedg: not that I can see [21:37] jdstrand: wow, you are here :) [21:38] jdstrand: Hmm, okay, must be messing something else up :-) [21:38] tedg: no, but remember there are snap-run snap-exec there as well [21:38] tedg: being in go they may do that in the runtime [21:38] tedg: can you show me a reprouction test case? [21:38] Uhg, yeah. [21:38] Not really right now, I have things heavily modified to recreate it. [21:38] jdstrand: hey, is there a chance for you to look at https://github.com/snapcore/snap-confine/pull/199 today [21:38] PR snap-confine#199: Add error support code [21:39] tedg: even a small test case I can run locally would be great [21:39] tedg: e..g something hacked in shell [21:40] zyga: Let me chase down a couple other threads first, might be me screwing things up as well. [21:41] Bug #1646625 opened: on first boot rpi2 cannot configure (core16) [21:41] tedg: that's ok, it's pretty late for me anyway, if you share something I can tinker with I'll try to help you out tomorrow [21:42] zyga: looking at that PR I would want to spend some time with it (more than I have this afternoon). I can look at it first thing tomorrow [21:42] zyga: if you need it sooner, perhaps tyhicks could look at it, but I don't know what he has going on [21:42] jdstrand: thanks, if you want more context look at https://github.com/snapcore/snap-confine/branches (specifically https://github.com/snapcore/snap-confine/tree/arguments ) [21:43] https://github.com/snapcore/snap-confine/commit/a84be35d70be79b6f92dd192d40a82f6f0717856 [21:43] this patch [21:46] zyga: what is the motivation of this patch? [21:46] zyga: hey - those look a little more like code churn than a PR that we should drop other stuff and review today [21:47] maybe I'm missing something [21:48] (it is really nice to have non-fatal error message handling) [21:48] tyhicks: it's okay, you don't have to review it today [21:48] tyhicks: well, fatal message handling has the nice benefit that you know you fail closed [21:48] jdstrand: argument parsing is going to grow a little and I didn't want to add more hackery to main() [21:49] jdstrand: and I wanted to write code that can follow one style of error handling and die()/death in proper places [21:49] jdstrand: that's true [21:49] jdstrand: and lastly I wanted something that can be unit tested a little bit better [21:49] zyga: what arguments are being added? [21:49] jdstrand: --classic [21:49] jdstrand: but I be we'll need more soon [21:49] jdstrand: e.g. --base to switch base snaps [21:50] jdstrand: perhaps --revision to not care about current symlinks [22:09] * zyga EODs [22:09] good night everyone [22:14] PR snapcraft#937 closed: Incorporate all part properties into state tracking [23:08] PR snapcraft#937 opened: Incorporate all part properties into state tracking [23:39] Bug #1545871 opened: Be able to query with multiple terms