[06:35] <zyga-arch> o/
[06:52] <PhoenixMage> hey zyga-arch
[06:54] <zyga-arch> hey
[06:54] <PhoenixMage> what plugin can I use to manaully specify a config file
[06:54] <zyga-arch> config file?
[06:54] <PhoenixMage> instead of ./configure
[06:55] <zyga-arch> well, configure is not a config file :)
[06:55] <zyga-arch> are you using the autotools plugin today?
[06:55] <PhoenixMage> Sorry, I am lazy :P
[06:55] <PhoenixMage> I am for most things
[06:55] <zyga-arch> if your project is using auto{conf,make} then that's the right way
[06:56] <PhoenixMage> I was going to compile openssl
[06:56] <PhoenixMage> It uses ./config
[06:56] <zyga-arch> if you have some other executable that is "autotools like" then you may need a custom plugin or just use the make plugin and write a makefile with all the rules
[06:56] <zyga-arch> not a perfect example but... https://github.com/zyga/python0
[06:57] <zyga-arch> this uses makefile plugin to essentially do whatever you want
[06:57] <zyga-arch> note that openssl is probably in the core snap
[06:57] <zyga-arch> so you may not want to build it
[06:58] <PhoenixMage> I can probably use stage-packages
[07:00] <PhoenixMage> Compiling samba says it cant find openssl
[07:04] <zyga-arch> you probably want openssl-dev package or something alike
[07:06] <mwhudson> waiting for travis for 7 hours on https://github.com/snapcore/snapd/pull/3639 now
[07:06] <mup> PR snapd#3639: update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
[07:07] <zyga-ubuntu> hmm
[07:08] <zyga-ubuntu> odd
[07:08] <zyga-ubuntu> seems like travis bug
[07:08] <PhoenixMage> I thought that but openssl-dev doesnt exist anymore.. I'll have to track down the package
[07:08] <zyga-ubuntu> mwhudson: since vendor.json conficted I'd suggest resolving the conflict and pushing over
[07:08] <mwhudson> zyga-ubuntu: yeah fair enough
[07:10] <PhoenixMage> libssl-dev I love consistency
[07:11] <zyga-ubuntu> openssl is an empty dependency package
[07:11] <zyga-ubuntu> it depends on libssl1.0.0
[07:11] <zyga-ubuntu> s/empty/mostly empty/
[08:30] <zyga-ubuntu> ondra: hey
[08:56] <ondra> zyga-arch hey
[08:57] <ondra> zyga-suse or here?
[08:58] <zyga-ubuntu> ondra: commented and updated https://github.com/snapcore/snapd/pull/3624
[08:58] <mup> PR snapd#3624: interfaces/builtin: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624>
[09:01] <ondra> zyga-ubuntu just saw it, good comments and sorry for test code, I used some existing test code, but I guess it's evolving all the time
[09:02] <zyga-ubuntu> that's fine, I didn't expect anything else, the test code is really in disarray
[09:02] <zyga-ubuntu> but changing that globally takes some time, ~100 interfaces is a lot of tweaking
[09:02]  * zyga-ubuntu just saw one more thing to weak
[09:03] <zyga-ubuntu> fixed
[09:05] <zyga-ubuntu> ok, what's next..
[09:05] <zyga-ubuntu> Chipaca: 2nd review on https://github.com/snapcore/snapd/pull/3650 please
[09:05] <mup> PR snapd#3650: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650>
[09:05] <Chipaca> hadn't i already done this one?
[09:06] <Chipaca> sorry
[09:06] <zyga-ubuntu> morphis_: do you have a sec to eyeball https://github.com/snapcore/snapd/pull/3649
[09:06] <mup> PR snapd#3649: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649>
[09:06] <Chipaca> zyga-ubuntu: +1
[09:06] <zyga-ubuntu> Chipaca: thank you!
[09:06] <morphis_> zyga-ubuntu: let me check
[09:06] <zyga-ubuntu> Chipaca: almost down to zero patches for arch :)
[09:06] <Chipaca> zyga-ubuntu: I _had_ already done it, just forgotten to … you know, *do* do it
[09:06] <zyga-ubuntu> Chipaca: 2.27.1 will be a nice release
[09:06] <zyga-ubuntu> hahaha
[09:06] <zyga-ubuntu>  :D
[09:07] <mup> PR snapd#3650 closed: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3650>
[09:07] <zyga-ubuntu> Chipaca: btw, I read the chatter from last night and noticed you found the double utf8 encoding bug that broke assertions
[09:07] <zyga-ubuntu> Chipaca: really nice and ouch!
[09:08] <Chipaca> harrumph
[09:08] <pedronis> it should be fixed now
[09:08] <Chipaca> nothing nice about double encodes
[09:09] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3648 is simple as well
[09:09] <mup> PR snapd#3648: release: remove default from VERSION_ID <Created by zyga> <https://github.com/snapcore/snapd/pull/3648>
[09:09] <pedronis> Chipaca: they fix was easy, but also totally python3 meet http and surrender
[09:09] <zyga-ubuntu> pedronis: is the fix public to see somewhere?
[09:09] <zyga-ubuntu> or just ... to see somewhere?
[09:09] <pedronis> no
[09:10] <pedronis> anyway it was mostly  s/resp.txt/resp.contet/
[09:10] <pedronis> *content
[09:10] <pedronis> *text
[09:10] <zyga-ubuntu> aha
[09:10] <zyga-ubuntu> I see
[09:10] <zyga-ubuntu> django?
[09:10] <pedronis> no
[09:10] <morphis_> zyga-ubuntu: done
[09:11] <zyga-ubuntu> morphis_: thank you
[09:11] <pedronis> requests (I think)
[09:15] <abeato> has anybody seen something like this before?:
[09:15] <abeato> $ snap refresh --beta --ignore-validation network-manager
[09:15] <abeato> error: cannot perform the following tasks:
[09:15] <abeato> - Mount snap "network-manager" (218) (installation not allowed by "core-support" plug rule of interface "core-support")
[09:16] <zyga-ubuntu> morphis_: replied, thank you, I'll iterate!
[09:17]  * zyga-ubuntu needs to buy more than 4GB of ram
[09:24] <zyga-ubuntu> morphis_: will you have a sec to do one more? https://github.com/snapcore/snapd/pull/3622
[09:24] <mup> PR snapd#3622: tests: enable regression, upgrade and completion test suites for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3622>
[09:24] <morphis_> zyga-ubuntu: if you review my snapd-xdg-open PR again :-)
[09:26] <morphis_> zyga-ubuntu: done
[09:28] <zyga-ubuntu> morphis_: I will, thank you!
[09:28] <zyga-ubuntu> morphis_: basically today I will do just code reviews
[09:28] <morphis_> :-)
[09:28] <zyga-ubuntu> morphis_: and I may iterate a little on this huge PR https://github.com/snapcore/snapd/pull/3617 to tweak it to my preference
[09:28] <mup> PR snapd#3617: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>
[09:29] <morphis_> zyga-ubuntu: please talk with gerry before you do so
[09:29] <morphis_> he is actively working on that
[09:33] <zyga-ubuntu> morphis_: gerry is adglkh?
[09:33] <morphis_> yes
[09:33] <zyga-ubuntu> morphis_: is here around somewhere where I can talk?
[09:33] <zyga-ubuntu> (I never met him before)
[09:33] <morphis_> on slack :-)
[09:34] <zyga-ubuntu> uh
[09:34] <morphis_> asking him
[09:34] <zyga-ubuntu> morphis_: where is he from roughly (timezone)
[09:34] <morphis_> china
[09:34] <zyga-ubuntu> morphis_: and is he a canonical person?
[09:34] <morphis_> yes
[09:34] <morphis_> part of my team
[09:34] <zyga-ubuntu> why slack then? is irc blocked?
[09:34] <zyga-ubuntu> morphis_: if he can join here, please ask him
[09:34] <zyga-ubuntu> otherwise let me know how to join slack
[09:36] <morphis_> zyga-ubuntu: asked him to join here
[09:36] <zyga-ubuntu> thank you
[09:36] <zyga-ubuntu> I heard there is a crackdown on VPNs in china
[09:36] <zyga-ubuntu> so not sure how to talk to people there
[09:36] <zyga-ubuntu> why are you using slack currently?
[09:37] <zyga-ubuntu> gary-wzl77: hey!
[09:37] <zyga-ubuntu> gary-wzl77: nice to meet you, thank you for joining
[09:38] <zyga-ubuntu> gary-wzl77: and thank you for working on fixing that huge udev issue, that's quite some work
[09:38] <gary-wzl77> zyga-ubuntu: Thanks for your code review.
[09:38] <gary-wzl77> Yes,  I was told by Simon that you have sth to check with me about udev tagging.
[09:38] <zyga-ubuntu> gary-wzl77: I wanted to discuss a few ideas, mainly because that branch is huge (I'm still reviewing it)
[09:38] <gary-wzl77> sure
[09:38] <zyga-ubuntu> gary-wzl77: and that I wanted to de-compose it into pieces
[09:39] <zyga-ubuntu> gary-wzl77: if you don't mind me doing that I can work on the current state of the branch until the diff from there to master shinks to zero
[09:39] <gary-wzl77> Never mind :)
[09:40] <gary-wzl77> I'll submit changes later on per jamie's comments
[09:40] <zyga-ubuntu> gary-wzl77: I'll start with your improvement to common interface, then to individual interfaces that can be simplified with it
[09:41] <zyga-ubuntu> gary-wzl77: yes please, let's keep your PR open and iterating on the udev details
[09:41] <zyga-ubuntu> gary-wzl77: I'll work on the side, proposing small branches that land in master and also merging master back into your branch
[09:41] <gary-wzl77> Nice .thanks
[09:41] <zyga-ubuntu> gary-wzl77: so that it can shring in diff size
[09:41] <zyga-ubuntu> gary-wzl77: and then we can hopefully get to the point where everyone agrees and we can just merge it
[09:41] <gary-wzl77> RE: Interface simplified
[09:42] <gary-wzl77> I spoke to Jamie about it and I've been bit reluctant to do it for complex interface like mir, docker, browser-support and alike
[09:42] <zyga-ubuntu> gary-wzl77: I understand that given the nature of the bug we are in the red anyway until *all* the interfaces are fixed to use udev tagging
[09:42] <zyga-ubuntu> gary-wzl77: so I think it's fine to fix interface-by-interface
[09:43] <zyga-ubuntu> gary-wzl77: and even leave TODO/FIXME markers in things we know need love but are non-trivial to do
[09:43] <gary-wzl77> The reason is it will introduce a few code in common function(like connectedPlugAppArmor , connectedSlotAppArmor or permanent**) of commonInterface
[09:43] <gary-wzl77> That makes commonInterface a bit fat
[09:44] <zyga-ubuntu> that's fine
[09:44] <zyga-ubuntu> it's there to make most of the interface code easy to reason about
[09:45] <zyga-ubuntu> gary-wzl77: also, I recommend that you stick around on IRC (assuming it is not hard firewall-wise) and on the forum.snapcraft.io
[09:45] <gary-wzl77> sure:D
[10:29] <zyga-ubuntu> gary-wzl77: ok, starting now
[10:38] <gary-wzl77> zyga-ubuntu: sure thing, I also left a comment about spread-test in snap-confine. Would you mind to take a look if you find time-slot.
[10:39] <zyga-ubuntu> gary-wzl77: looking
[10:41] <zyga-ubuntu> gary-wzl77: huh, git.launchpad.net/snap-confine should be dead
[10:41] <zyga-ubuntu> gary-wzl77: which tests are you referring to?
[10:50] <gary-wzl77> zyga-ubuntu: just generic spread test in snap-confine folder, follow the guidance `make hack` and `run ./spread-prepare`
[10:50] <gary-wzl77> zyga-ubuntu: then we will have one dependency issue when building deb package along the way
[10:51] <zyga-ubuntu> gary-wzl77: in the snapd repo, in snapd/cmd/snap-confine folder?
[10:52] <zyga-ubuntu> hmmm
[10:52] <zyga-ubuntu> make hack should never be used for spread testing
[10:52] <zyga-ubuntu> can you point me to the tests you are thinking about?
[10:52] <gary-wzl77> yes
[10:52] <zyga-ubuntu> note that the spread tests in snap confine sub-directory are *not* working and need porting
[10:52] <gary-wzl77> Okay, that's it
[10:58] <gary-wzl77> zyga-ubuntu: I saw a few changes that we submitted recently improving the spread test for each interface.
[10:59] <gary-wzl77> Probably we need some tweaks then after we land udev tagging feature
[10:59] <zyga-ubuntu> definitely
[11:05] <mup> PR snapd#3657 opened: daemon, client, cmd/snap: implement snap start/stop/restart <Created by chipaca> <https://github.com/snapcore/snapd/pull/3657>
[11:06]  * zyga-ubuntu -> food
[11:09] <Chipaca> so, I'm stopping for lunch, and then I need to take one of the boys to the doctor. PR of services ops #n is up, hopefully alright and this PM I'll be working on completion.
[11:09]  * Chipaca out
[11:54] <kjackal__> Chipaca: ogra_: Hi again, do we have any news on https://bugs.launchpad.net/snappy/+bug/1687079 ?
[11:54] <mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:Confirmed> <https://launchpad.net/bugs/1687079>
[11:56] <ogra_> kjackal__, what would you expect as a fix beyond a more descriptive error (i doubt mainline will want to hardcode apparmor support) ?
[12:03] <kjackal__> ogra_: that bug spawned the discussion we had last week on having daemons wait for the completion of other services before they start up
[12:04] <kjackal__> ogra_: honestly I am not sure what the fix for the above bug should be
[12:05] <ogra_> oh, that one ... well, that discussion doesnt really look 100% related
[12:05] <ogra_> IIRC Chipaca offered to extend the systemd unit generation with options for that ...
[12:05] <kjackal__> ogra_: Chipaca: here is the problem we are facing: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/357
[12:05] <ogra_> (which should really be its own whishlist bug or even better a forum topic)
[12:07] <ogra_> kjackal__, better make it a forum thred, so it doesnt get lost
[12:07] <ogra_> *thread
[12:08] <kjackal__> ogra_: like this one: https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470 ?
[12:09] <ogra_> yeaah
[12:10] <ogra_> (that doesnt reflect any of the IRC discussion though)
[12:10] <ogra_> (IIRC there was aan offer from Chipaca for a fix ... )
[12:12] <kjackal__> ogra_: Chipaca: we said we would setup a meeting next week with your architect, to discuss what we can do about this issue. If I am not mistaken daemons on lxd will not survive a reboot.
[12:13] <ogra_> kjackal__, right, but i think he didnt know that niemeyer is (kind of) off this week ...
[12:13] <ogra_> it would help if the findings from the discussion would be in the thread though ...
[12:14] <ogra_> that forum topic is as undescriptive as it can be (like the bug :) )
[12:15] <ogra_> we will need it to end up with a specification what has to be implemented in snapd etc
[12:15] <ogra_> (and how)
[12:16] <kjackal__> The issue on github is the point where we gather all the info on the incident. Should I link it to the topic?
[12:18] <ogra_> kjackal__, i changed the title of the topic ... https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470
[12:18] <ogra_> can you flesh the content out a bit more instead of talking about random snaps and bugs ... (like what do we want to achieve, what has been discussed and offered as possible implementation)
[12:19] <ogra_> it should look more like a spec in the end
[12:20] <ogra_> that way the snapd guys can just grab it, nod it off and start working on it
[12:21] <kjackal__> ok, thanks ogra_
[12:21] <ogra_> kjackal__, http://paste.ubuntu.com/25239691/ from my IRC logs
[12:34] <zyga-ubuntu> kjackal__: which kernel are you using?
[12:36] <ogra_> zyga-ubuntu, not kernel related at all, see my paste
[12:36] <ogra_> (that linking of these bugs is totally confusing the issue)
[12:37] <ogra_> zyga-ubuntu, this is solely about snap services being able to wait for oother services to be up
[12:38] <ogra_> (essentially about allowing "After=*" in snapd units of snaps)
[12:38] <zyga-ubuntu> aha
[12:38] <zyga-ubuntu> ok then, not my problem today :)
[12:38]  * zyga-ubuntu gets back to interfaces
[12:39] <ondra> zyga-ubuntu double check changes I commented on, I'm not sure about two changes there
[12:41] <zyga-ubuntu> ondra: thank you, I will in a moment
[12:42] <ondra> zyga-ubuntu I might be wrong, just double checking :)
[12:43] <zyga-ubuntu> Chipaca: question, what kind of tab completion should I get out of http?
[12:43] <zyga-ubuntu> I don't see any
[12:44] <abeato> zyga- it possible to run a command from inside the snap inside the configure hook?
[12:45] <abeato> zyga-ubuntu,  it possible to run a command from inside the snap inside the configure hook?
[12:45] <zyga-ubuntu> ondra: replied
[12:45] <zyga-ubuntu> abeato: which command?
[12:45] <abeato> zyga-ubuntu, like using nmcli inside network-manager's configure hook
[12:45] <zyga-ubuntu> abeato: all hooks are arbitrary programs, so you can run anything you can otherwise run, remember that you are confined, as usual
[12:46] <zyga-ubuntu> abeato: one restriction is you should not run snap's exposed apps via /snap/bin/snap.app again
[12:46] <zyga-ubuntu> abeato: instead just run them directly via $SNAP/bin/app
[12:47] <abeato> zyga-ubuntu, it is strange because I get permissions error that should not happen if running it as root :  https://pastebin.canonical.com/195195/
[12:48] <zyga-ubuntu> oh please not that one
[12:48] <zyga-ubuntu> can you repaste to normal one, I don't have my token handy
[12:49] <abeato> zyga-ubuntu, http://paste.ubuntu.com/25239783/
[12:49] <zyga-ubuntu> thank you, looking
[12:49] <zyga-ubuntu> abeato: can you show me the snap.yaml please?
[12:50] <abeato> zyga-ubuntu, http://paste.ubuntu.com/25239786/
[12:50] <ogra_> abeato, i suspect you need to connect all the interfaces the snap uses first
[12:51] <abeato> ogra_, they are connected
[12:51] <zyga-ubuntu> ogra_: no, not that
[12:51] <zyga-ubuntu> abeato: so
[12:51] <ogra_> ok
[12:51] <zyga-ubuntu> abeato: notice that all the plugs are on the apps
[12:51] <zyga-ubuntu> abeato: the hooks don't get any
[12:52] <abeato> zyga-ubuntu, can I add plugs to the hooks?
[12:52] <zyga-ubuntu> you need to either define a plug at the top level (where it applies to everything)
[12:52] <niemeyer> Helloooo
[12:52] <ondra> zyga-ubuntu not sure I follow
[12:52] <zyga-ubuntu> or also add a hooks section and add specific plugs to your hook
[12:53] <zyga-ubuntu> ondra: look at that file, look at the symbols I replaced
[12:53] <ogra_> couldnt he call the apps as well ?
[12:53] <abeato> aha, did not know that
[12:53] <ondra> zyga-ubuntu why do we need then avahiControlConnectedSlotAppArmor twice there?
[12:53] <abeato> zyga-ubuntu, thanks, that is useful :)
[12:53] <zyga-ubuntu> ondra: before my replacements there were unused snippets
[12:53] <zyga-ubuntu> ondra: looking
[12:53] <ogra_> (if the apps are connected, calling them should work as well, no ?)
[12:53] <zyga-ubuntu> maybe some silly mistake on my end
[12:53] <zyga-ubuntu> ogra_: no
[12:53] <zyga-ubuntu> ogra_: the hooks have no slots
[12:53] <zyga-ubuntu> ogra_: according to that def
[12:53] <ondra> zyga-ubuntu and idea there was that control also includes rules from observe
[12:53] <zyga-ubuntu> oooooh
[12:53] <zyga-ubuntu> ondra: I'm blind
[12:54] <zyga-ubuntu> I didn't see the +
[12:54] <zyga-ubuntu> thanks!
[12:54] <ondra> zyga-ubuntu so it does not need to be defined same again there
[12:54] <zyga-ubuntu> yes, I don't know how I missed that :)
[12:54] <ogra_> zyga-ubuntu, why would i need slots ... if i have an app "foobar" that has a plug connected, my hook shoud be able to use foobar
[12:54] <zyga-ubuntu> ondra: still, I'm somewhat inclined to use a common one
[12:54] <zyga-ubuntu> and not do + on snippets
[12:54] <zyga-ubuntu> just call the helper twice
[12:54] <ogra_> (without any extra plugs or slots)
[12:54] <ondra> zyga-ubuntu don't worry I was staring at it for 5mins and even used string compare to make sure :D
[12:54] <zyga-ubuntu> ogra_: sorry, I meant plugs
[12:55] <zyga-ubuntu> ogra_: no, that's not how this is designed, the app may need super strong permissions
[12:55] <ondra> zyga-ubuntu ahh is that is possible then for sure calling helper twice is better
[12:55] <zyga-ubuntu> ogra_: and the hook can be separate
[12:55] <zyga-ubuntu> ogra_: like two apps can get two separate permissions
[12:55] <ogra_> is it any different to me executing the foobar app manually ?
[12:55] <ondra> zyga-ubuntu shall I do the change?
[12:55] <zyga-ubuntu> ogra_: each hook and app can have a separate set of plugs
[12:55] <zyga-ubuntu> ogra_: a plug is either connected or not
[12:55] <ogra_> hmm
[12:55] <zyga-ubuntu> ogra_: but the application of that connection is not the same to all executables
[12:56] <ogra_> i wouldnt expect it to work like that as a consumer
[12:56] <zyga-ubuntu> ogra_: whoever is making the snap can associate a particular app or hook with a particular set of plugs
[12:56] <zyga-ubuntu> ogra_: so that you can do privilege separation inside one snap
[12:56] <zyga-ubuntu> ogra_: where nmcli doesn't need the full power to run as network-manager
[12:56] <zyga-ubuntu> ogra_: and the same thing applies to the hook
[12:56] <zyga-ubuntu> ogra_: inside that snap only network manager itself needs that
[12:57] <zyga-ubuntu> ogra_: the hook and the cli tool just need the permission to talk to it
[12:57] <zyga-ubuntu> ogra_: depending on how you define a plug it is scoped to either everything in the snap (by defining a top-level plug)
[12:57] <zyga-ubuntu> ogra_: or to a specific set of apps (by refering to a plug from their definitions)
[12:57] <ogra_> right, and i would expect that if the cli tool is connected i could call out from any script to it to run it ... even if that script was a hook
[12:57] <zyga-ubuntu> ogra_: I think hooks have one more quirk but I'm not sure now
[12:57] <zyga-ubuntu> ogra_: right but he's not calling the CLI tool
[12:58] <zyga-ubuntu> ogra_: he's running the hook
[12:58] <zyga-ubuntu> and the hook runs as its own profile
[12:58] <ogra_> yes, what i suggested was calling the cli tool from the hook :)
[12:58] <zyga-ubuntu> ogra_: and we don't allow profile transitions
[12:58] <zyga-ubuntu> ogra_: note that the CLI tool has two "instances"
[12:58] <zyga-ubuntu> ogra_: the /snap/bin/network-manager.cli (say) is one
[12:58] <zyga-ubuntu> ogra_: and $SNAP/bin/nmcli is another
[12:58] <zyga-ubuntu> that's the same executable
[12:58] <zyga-ubuntu> but two profiles
[12:58] <zyga-ubuntu> well
[12:59] <zyga-ubuntu> one profile and one no-profile
[12:59] <ogra_> right
[12:59] <zyga-ubuntu> ogra_: the one in /snap sets the profile
[12:59] <zyga-ubuntu> (in /snap/bin)
[12:59] <ogra_> and i as a user of it would expect that my script can use $SNAP/bin/nmcli
[12:59] <zyga-ubuntu> the other one runs as whoever is running it (it inherits the profile)
[12:59] <ogra_> as long as all interfaces for it are cnnected
[12:59] <zyga-ubuntu> it can, but nmcli cannot talk to network manager because the hook doesn't have the permission to do so
[12:59] <ogra_> wether that script is a hook or some script in my lhomedir
[12:59] <zyga-ubuntu> because as the user (developer of the snap really) that is what was specified
[13:00] <ogra_> that seems duplicated to me
[13:00] <zyga-ubuntu> I don't understand the script in homedir aspect
[13:00] <zyga-ubuntu> ogra_: what exactly?
[13:00] <ogra_> the only person that can alter the hook is the developer of the snap anyway
[13:00] <zyga-ubuntu> ogra_: it's like having two apps in a snap
[13:00] <zyga-ubuntu> and defining a plug on just one of them
[13:00] <ogra_> so why do we need double confinement here
[13:00] <zyga-ubuntu> the other is not getting those permissions
[13:00] <zyga-ubuntu> that's exactly what is going on here
[13:00] <ogra_> shipped apps should just be callable from a hook
[13:00] <zyga-ubuntu> ogra_: it's not double confinement, it's *scoping* the confinement
[13:00] <ogra_> (as long as the app interfaces themselves are connected)
[13:01] <zyga-ubuntu> ogra_: they *are* with the permissions of the *hook*
[13:01] <zyga-ubuntu> and a hook is just as any other pap
[13:01] <zyga-ubuntu> *app
[13:01] <zyga-ubuntu> it has permissions derived from the plugs that apply to it
[13:01] <ogra_> well, call it "wrapped confinement" then :)
[13:01] <ogra_> its an extra level ...
[13:01] <zyga-ubuntu> and the only problem is that the *hook* was not defined as needing that permission (no plug) so it didn't et them
[13:01] <ogra_> and i dont get why we'd need that
[13:01] <zyga-ubuntu> no, you don't understand
[13:02] <zyga-ubuntu> the hook is not calling /snap/bin/nmcli
[13:02] <zyga-ubuntu> if it did there would be a different message
[13:02] <zyga-ubuntu> that this is not allowed
[13:02] <niemeyer> Chipaca, zyga-ubuntu: standup
[13:02] <zyga-ubuntu> oh
[13:02] <zyga-ubuntu> sorry
[13:02] <zyga-ubuntu> joiuning
[13:02] <zyga-ubuntu> ogra_: let's discuss this later
[13:03] <ogra_> i have one level of confinement in the app ... and another layer on top for the hook ... but i'm also the owner of the snap so i dont see the need for the extra confinement in the hook (just adds extra work for me to define additional slot/plug connections ... i have the power to do so anyway but need to separately declare it)
[13:03] <ogra_> zyga-ubuntu, yeah
[13:05] <ondra> zyga-ubuntu I just pushed change, let me know if this is better way
[13:09] <ogra_> nessita_, since you transferred the orangepi-zero gadget i have a giant red "REVOKED" at the top of my dashboard, is there any way to get rid of the snap from my dashboard oveview ?
[13:11] <zyga-ubuntu> ondra: thank you, I'll check after the call
[13:13] <ondra> zyga-ubuntu thanks :)
[13:13] <zyga-ubuntu> ogra_: those are not levels, those are scopes, each app and hook has its own confinement, you don't get any nested confinement in any place
[13:14] <ogra_> well, i need to declare confinement stuff twice when wanting to use foobar in my hook ... once for foobar itself and once for the hook
[13:14] <ogra_> what i mean is that any apps shipped inside the snap shouldnt require that to use them from the hook of the same snap
[13:15] <zyga-ubuntu> you *never* apply the conifnement to binaries in the snap
[13:16] <zyga-ubuntu> you only apply them to launchers (the command: section in each app)
[13:18] <ogra_> yes
[13:19] <ogra_> and my hook should be able to use them from the launchers ... thats what i mean
[13:19] <ogra_> without having to specify any additional confinement
[13:22] <zyga-ubuntu> it can, that's never the problem, the problem is that they cannot do what they want because how would we know what they need?
[13:22] <zyga-ubuntu> you can *exec* each binary in your snap
[13:22] <ogra_> no, then the interfaces for the app dont apply
[13:22] <zyga-ubuntu> nmcli talks over dbus with network-manager
[13:22] <zyga-ubuntu> binary != app
[13:22] <zyga-ubuntu> app is a command
[13:22] <zyga-ubuntu> what if I have two apps
[13:22] <zyga-ubuntu> that run one binary
[13:23] <zyga-ubuntu> with two different options
[13:23] <ogra_> right and there is an interface that applied if i call it as /snap/bin/nmcli
[13:23] <zyga-ubuntu> and two different permissions?
[13:23] <ogra_> *applies
[13:23] <zyga-ubuntu> yes but you cannot call that from inside a snap, that's explicitly denied
[13:23] <ogra_> instead of $SNAP/usr/bin/nmcli directly
[13:23] <ogra_> yes
[13:23] <ogra_> and thats what i'm debating ;)
[13:23] <zyga-ubuntu> that /snap/bin/nmcli should be allowed?
[13:23] <ogra_> an app shipped inside my own snap shouldnt be denied when called from inside that same snap
[13:24] <ogra_> so that i can use it from a hook without having to jump through hoops
[13:24] <zyga-ubuntu> man, that's not the problem
[13:24] <zyga-ubuntu> one sec
[13:24] <ogra_> indeed the dbus interface still needs to be connected for the app
[13:24] <ogra_> (which my hook cant do)
[13:26] <zyga-ubuntu> ogra_: http://pastebin.ubuntu.com/25239924/
[13:26] <ogra_> yeah
[13:26] <zyga-ubuntu> ogra_: what permissions would you expect to see if the hook runs bin/foo?
[13:26] <ogra_> well, my hook should run /snap/bin/a (or b)
[13:26] <ogra_> and the normal confinement for a or b should apply
[13:27] <ogra_> so that my hook doesnt need any different or separate confinement
[13:27] <zyga-ubuntu> right
[13:27] <zyga-ubuntu> that I agree with
[13:27] <zyga-ubuntu> but this is not allowed today for a few reasons
[13:28] <ogra_> and in that case the answer to alfonso above would have been use /snap/bin/nmcli and be done
[13:28] <ogra_> the thing is that the person writing the hook has the power to allow this anyway ...
[13:28] <ogra_> but needs to jump through more hoops by defining interfaces for the hook today
[13:29] <ogra_> apps declared in my snapcraft.yaml shoudl just be usable from my hook without extra work ... thats the point i'm making :)
[13:30] <zyga-ubuntu> ogra_: right, and that's, as I said, not allowed for a few reason
[13:30] <zyga-ubuntu> *reasons
[13:30] <ogra_> i dont see any security advantage of the current model
[13:30] <zyga-ubuntu> the primary reason was that it would be tempting to run run stuff from another snap
[13:31] <zyga-ubuntu> and at the point when snap-confine runs we don't have a way to reject just those
[13:31] <ogra_> well
[13:31] <ogra_> i didnt say ""allow calling something from another snap"
[13:31] <ogra_> just within the same snap
[13:31] <zyga-ubuntu> right, but at the time the request comes in there's not enough context to decide
[13:31] <zyga-ubuntu> so we reject all of them
[13:31] <ogra_> if the app and hook are inside the same ...
[13:31] <zyga-ubuntu> and we're back to square one
[13:31] <ogra_> ah
[13:32] <ogra_> so we'll need meore context :)
[13:32] <ogra_> *more
[13:32] <niemeyer> popey: ping
[13:35] <zyga-ubuntu> ondra: looks good, thank you for noticing :)
[13:35] <ondra> zyga-ubuntu thank  you for helping me with PR :)
[13:39] <cachio> ogra_, I try to configure my pi3 and I see -> Can’t find valid F2FS filesystem in 1th/sth superblock
[13:41] <cachio> any idea?
[13:46] <ogra_> cachio, thats nothing bad ... just the kernel looping over filesystems
[13:46] <cachio> ok
[13:46] <cachio> ogra_, tx
[13:46] <ogra_> like it also does for ext2 and ext before it actually mounts an ext4 FS
[13:47] <ogra_> *for ext2 and ext3
[13:47] <ogra_> that also spills some ugly messages
[13:47] <bub_> Humm, how do I install X?
[13:47] <bub_> X Window.. or some displayservice..
[13:48] <ogra_> you mean on UbuntuCore ?
[13:48] <ogra_> you cant
[13:48] <ogra_> there is not way X ever matches the security model
[13:48] <bub_> Aha, haha..
[13:48] <ogra_> there is a mir-kiosk snap that you can use for having kiosk apps (standalone fullscreen app)
[13:49] <bub_> yeah right, but no way we're going to get Qt with its graphiclibraries run on Ubuntu Core then I Guess
[13:49] <bub_> s/Guess/guess
[13:49] <ogra_> but indeed your app then needs to support mir
[13:49] <ogra_> Qt runs fine on mir-kiosk
[13:49] <popey> niemeyer: heya.
[13:49] <ogra_> in fact the demo apps are all Qt
[13:49] <popey> niemeyer: i guess i scheduled the meeting too early?
[13:49] <niemeyer> popey: Yo
[13:49] <niemeyer> popey: No, I was the one screwing up, sorry
[13:50] <niemeyer> popey: Do you want to have a quick catch up now?
[13:50] <bub_> ok, so mir-kiosk might save us.. tyty
[13:51] <ogra_> bub_, the guys in #ubuntu-mir might know more details
[13:51] <popey> niemeyer: unfortunately I'm a busy for the next 2.5 hours. After that? 16:30 UTC?
[13:51] <niemeyer> popey: Deal
[13:52] <popey> niemeyer: invite sent
[13:53] <niemeyer> popey: Thanks, talk soon
[13:58] <zyga-ubuntu> Chipaca: hey
[13:58] <zyga-ubuntu> around?
[13:58] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
[13:58] <mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
[13:58] <zyga-ubuntu> anyway, some small PR for quick landing, I'll iterate on next part
[13:58] <mup> PR snapd#3658 opened: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
[14:09] <cachio> ogra_, when I insert the sdcard it I showing a disk on /dev/mmcblk0
[14:09] <cachio> ogra_, but not /dev/mmcblk0p0
[14:09] <cachio> is that a problem?
[14:10] <cachio> it has two partitions p1 and p2 instead
[14:12] <zyga-ubuntu> gary-wzl77: around?
[14:12] <zyga-ubuntu> well, probably not on Friday
[14:13] <Chipaca> zyga-ubuntu: http's tab completer for bash is rather poor, it only offers options (i.e. type -, hit tab)
[14:13]  * zyga-ubuntu checks
[14:13] <zyga-ubuntu> nothing
[14:13] <mup> PR snapd#3659 opened: tests: fix install-hook test failure <Created by stolowski> <https://github.com/snapcore/snapd/pull/3659>
[14:13] <zyga-ubuntu> is that a thing that's out in stable core?
[14:13] <Chipaca> zyga-ubuntu: have you sourced complete.sh?
[14:13] <zyga-ubuntu> Chipaca: where is it?
[14:14] <Chipaca> zyga-ubuntu: /snap/core/current/usr/lib/snapd/complete.sh
[14:14] <pstolowski> cachio, ^ fix for the install-hook test failure, for master first. i'll propose fix for 2.27 too if that makes sense?
[14:14] <zyga-ubuntu> ah
[14:14] <zyga-ubuntu> Chipaca: right
[14:14] <zyga-ubuntu> we need "re-exec" for that
[14:14] <zyga-ubuntu> thanks
[14:14] <ogra_> cachio, what would you expect 0p0 to be ? :)
[14:14] <Chipaca> zyga-ubuntu: we wha?
[14:14] <zyga-ubuntu> Chipaca: sourced but nothing
[14:14] <zyga-ubuntu> Chipaca: (let's talk reexec later)
[14:14] <Chipaca> zyga-ubuntu: complete -p http
[14:14] <Chipaca> zyga-ubuntu: your trying it before probably loaded _minimal in there
[14:14] <ogra_> cachio, /dev/mmcblk0 is the device ... /dev/mmcblk0p1 is system-boot and /dev/mmcblk0p2 is writable ...
[14:15] <zyga-ubuntu> complete -F _minimal http
[14:15] <Chipaca> zyga-ubuntu: in which case, complete -r http
[14:15] <Chipaca> zyga-ubuntu: and try agian
[14:15] <ogra_> cachio, partitioning starts to count at 1 not at 0
[14:15] <ogra_> so it should all be fine as is
[14:15] <cachio> ogra_, ok, it was appearing p0
[14:15] <ogra_> that would be a massive kernel bug :)
[14:16] <zyga-ubuntu> Chipaca: that said:
[14:16] <zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ complete -r h
[14:16] <zyga-ubuntu> bash: complete: h: brak definicji dla uzupełnienia
[14:16] <zyga-ubuntu> (I set locale to english but... well)
[14:16] <gary-wzl77> zyga-ubuntu: yeah, still here :D
[14:16] <ogra_> ogra@pi3:~$ cat /proc/partitions |grep mmc
[14:16] <ogra_>  179        0    3921920 mmcblk0
[14:16] <ogra_>  179        1     131072 mmcblk0p1
[14:16] <ogra_>  179        2    3789779 mmcblk0p2
[14:16] <zyga-ubuntu> "no definitions for completion"
[14:16] <zyga-ubuntu> gary-wzl77: ah, nice, can you please have a look at
[14:16] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
[14:16] <mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
[14:16] <Chipaca> zyga-ubuntu: literally h, or http?
[14:17] <zyga-ubuntu> Chipaca: that was a typo, I did write http
[14:17] <gary-wzl77> zyga-ubuntu: sure
[14:17] <zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ complete -r http
[14:17] <zyga-ubuntu> bash: complete: http: brak definicji dla uzupełnienia
[14:17] <cachio> ogra_, ok, just trying to understand why it is showing the message that I told you before
[14:17] <Chipaca> zyga-ubuntu: and complete -p http?
[14:17] <ogra_> cachio, hmm, perhaps if you format the raw device instead of partitioning it at all you might get a p0 ... i never did such insanity ... (but could be that cameras or some such do that)
[14:17] <zyga-ubuntu> "przed wyruszenie w podróż należy zebrać drużyne"
[14:17] <zyga-ubuntu> Chipaca: -p says the same thing
[14:18] <Chipaca> zyga-ubuntu: ok so you dropped the _minimal definition
[14:18] <Chipaca> um
[14:18] <Chipaca> zyga-ubuntu: do you have two shells open and did the other -p in the other one?
[14:18] <cachio> ogra_, ok, just I wanted to make sure there was not an error on there
[14:18] <zyga-ubuntu> Chipaca: no, it's all in one shell
[14:18] <ogra_> no, the system SD should always have p1 and p2
[14:18] <zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ snap version
[14:18] <zyga-ubuntu> snap    2.26.14
[14:18] <zyga-ubuntu> snapd   2.26.14
[14:18] <zyga-ubuntu> series  16
[14:18] <zyga-ubuntu> ubuntu  16.04
[14:18] <zyga-ubuntu> kernel  4.8.0-58-generic
[14:18] <zyga-ubuntu> in case this is relevant
[14:19] <Chipaca> zyga-ubuntu: ok, what does “type _complete_from_snap” say
[14:19] <zyga-ubuntu> tons of stuff
[14:19] <zyga-ubuntu> the good thing
[14:19] <Chipaca> zyga-ubuntu: good
[14:19] <mup> PR snapd#3633 closed: overlord/devicestate: fix, don't assume that the serial is backed by a 1-key chain <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3633>
[14:19] <Chipaca> zyga-ubuntu: so now http -<tab> should do something
[14:19] <zyga-ubuntu> it's a function with the code
[14:19] <zyga-ubuntu> nope :)
[14:19] <zyga-ubuntu> it doesn't
[14:19] <zyga-ubuntu> what are we missing? :)
[14:20] <Chipaca> zyga-ubuntu: what revision of http do you have?
[14:20] <zyga-ubuntu> 21
[14:21] <Chipaca> zyga-ubuntu: what does “complete -p http” say _now_?
[14:21] <zyga-ubuntu> no definitions
[14:21] <Chipaca> zyga-ubuntu: what does “complete -p -D” say?
[14:21] <zyga-ubuntu> bash: complete: _DefaultCmD_: brak definicji dla uzupełnienia
[14:21] <zyga-ubuntu> (little by little I can teach you polish)
[14:21] <Chipaca> double to the you to the eff
[14:22] <Chipaca> zyga-ubuntu: ok, so, start a new shell
[14:22] <zyga-ubuntu> reday
[14:22] <zyga-ubuntu> ready*
[14:22] <Chipaca> zyga-ubuntu: complete -p -D
[14:22] <zyga-ubuntu> complete -F _completion_loader -D
[14:22] <Chipaca> zyga-ubuntu: now, source complete.sh
[14:23] <Chipaca> zyga-ubuntu: note: source, not run, source
[14:23] <zyga-ubuntu> k
[14:23] <zyga-ubuntu> done
[14:23] <Chipaca> zyga-ubuntu: complete -p -D
[14:23] <zyga-ubuntu> complete -F _complete_from_snap_maybe -D
[14:23] <Chipaca> zyga-ubuntu: http -<tab>
[14:23] <zyga-ubuntu> nothing
[14:23] <Chipaca> zyga-ubuntu: tab again
[14:23] <zyga-ubuntu> I'm tab-tab-tabbing
[14:23] <zyga-ubuntu> nothing
[14:23] <Chipaca> zyga-ubuntu: AGAIN
[14:24]  * Chipaca throws things
[14:24] <zyga-ubuntu> 12s of times actually
[14:24]  * zyga-ubuntu hugs chipaca
[14:24] <zyga-ubuntu> wanna hangout?
[14:24] <zyga-ubuntu> can it be locale somewhere
[14:24] <Chipaca> zyga-ubuntu: complete -p -D ?
[14:24] <zyga-ubuntu> or something like
[14:24] <zyga-ubuntu> complete -F _complete_from_snap_maybe -D
[14:24] <Chipaca> zyga-ubuntu: set -x
[14:24] <Chipaca> zyga-ubuntu: http -<tab><tab>
[14:24] <zyga-ubuntu> stuff flies
[14:25] <zyga-ubuntu> very chatty
[14:25] <Chipaca> zyga-ubuntu: _what_ stuff
[14:25] <zyga-ubuntu> wanna see?
[14:25] <zyga-ubuntu> sec
[14:25] <Chipaca> zyga-ubuntu: set +x now, for sanity
[14:25] <Chipaca> ;-)
[14:25] <Chipaca> zyga-ubuntu: please
[14:25] <zyga-ubuntu> http://pastebin.ubuntu.com/25240232/
[14:26] <zyga-ubuntu> gary-wzl77: if that looks ok to you +1 it please
[14:26] <zyga-ubuntu> gary-wzl77: I tweaked some things
[14:26] <zyga-ubuntu> I'll merge this into your branch and start iterating on interfaces (I did one as a sanity check)
[14:27] <Chipaca> zyga-ubuntu: that pastebin makes no sense to me
[14:27] <zyga-ubuntu> Chipaca: welcome to my world
[14:28] <zyga-ubuntu> at least you understand some of it
[14:28] <Chipaca> zyga-ubuntu: ok, try this
[14:28] <Chipaca> zyga-ubuntu: complete -F _complete_from_snap http
[14:28] <zyga-ubuntu> empty
[14:28] <zyga-ubuntu> technically
[14:28] <zyga-ubuntu> $ complete -F _complete_from_snap http
[14:28] <zyga-ubuntu> + complete -F _complete_from_snap http
[14:28] <zyga-ubuntu> (nothing else)
[14:29] <Chipaca> zyga-ubuntu: set +x
[14:29] <zyga-ubuntu> now really empty
[14:29] <Chipaca> zyga-ubuntu: does http -<tab> do stuff now?
[14:29] <zyga-ubuntu> YES!
[14:29] <zyga-ubuntu> wow
[14:29] <zyga-ubuntu> what changed?
[14:29] <zyga-ubuntu> I see some denials
[14:29] <Chipaca> zyga-ubuntu: could you pastebin “type _complete_from_snap_maybe”?
[14:29] <zyga-ubuntu> but it completes
[14:30] <zyga-ubuntu> http://pastebin.ubuntu.com/25240249/
[14:30] <Chipaca> zyga-ubuntu: and could you confirm that complete -p -D is still _complete_from_snap_maybe?
[14:30] <zyga-ubuntu> sie 04 16:29:25 fyke kernel: audit: type=1400 audit(1501856965.430:1150): apparmor="DENIED" operation="open" profile="snap.http.http" name="/etc/init.d/" pid=13425 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[14:30] <zyga-ubuntu> (unrelated denial)
[14:30] <zyga-ubuntu> nope
[14:30] <zyga-ubuntu> $ complete -p -D
[14:30] <zyga-ubuntu> bash: complete: _DefaultCmD_: brak definicji dla uzupełnienia
[14:30] <Chipaca> WTF
[14:30] <zyga-ubuntu> (in the same terminal)
[14:30] <zyga-ubuntu> and it still completes OK
[14:31] <Chipaca> yes now it's completing because of the -F
[14:31] <Chipaca> it's not going via the default
[14:31] <zyga-ubuntu> aha
[14:31] <Chipaca> zyga-ubuntu: ok, so now
[14:31] <Chipaca> zyga-ubuntu: compelte -r http
[14:31] <Chipaca> complete*
[14:31] <zyga-ubuntu> empty (typo corrected)
[14:31] <Chipaca> zyga-ubuntu: complete -F _complete_from_snap_maybe -D
[14:31] <zyga-ubuntu> empty as well
[14:31] <Chipaca> zyga-ubuntu: does that end up with http -<tab> working again?
[14:32] <zyga-ubuntu> it still works
[14:32] <zyga-ubuntu> it didn't break since I said *wow*
[14:32] <Chipaca> zyga-ubuntu: something is removing the default completer
[14:33] <Chipaca> zyga-ubuntu: (that's the -D one)
[14:33] <Chipaca> zyga-ubuntu: so if “complete -p -D” says there's no uzupełnienia, it's bad
[14:33] <zyga-ubuntu> that says
[14:33] <zyga-ubuntu> complete -F _complete_from_snap_maybe -D
[14:33] <Chipaca> zyga-ubuntu: something's unuzupełnieniaing it!
[14:34] <zyga-ubuntu> :') grammar
[14:34] <Chipaca> zyga-ubuntu: the great unuzupełnieniator!
[14:34] <zyga-ubuntu> hahaha
[14:34] <Chipaca> zyga-ubuntu: why “fyke” btw?
[14:34] <zyga-ubuntu> fyke is my x250
[14:35] <zyga-ubuntu> faroe is my t430
[14:35] <Chipaca> zyga-ubuntu: i mean, it's a bag net for catching fish
[14:35] <Chipaca> (in english i mean)
[14:35] <zyga-ubuntu> oh, I just pulled this out of the witcher 3 locations map
[14:35] <Chipaca> ah :) ok
[14:36] <zyga-ubuntu> http://witcher.wikia.com/wiki/Fyke_Isle
[14:36] <Chipaca> k
[14:36] <Chipaca> anyway, somehting needs fixing, but not sure what
[14:36] <Chipaca> i'll dig into it
[14:36] <zyga-ubuntu> (read that description)
[14:36] <zyga-ubuntu> it's fun :D
[14:36] <Chipaca> i've got a suspicion that needs checking out
[14:36] <gary-wzl77> zyga-ubuntu: I left one comment. please take a look.
[14:37] <zyga-ubuntu> gary-wzl77: thank you, looking now
[14:38] <cachio> niemeyer, I am planning to try a way yo reproduce the error on the reboot for ubuntu-core on linode, are you going to be available this afternon?
[14:38] <zyga-ubuntu> gary-wzl77: replied, thanks!
[14:38] <zyga-ubuntu> Chipaca: I feel like getting a coffee
[14:39] <zyga-ubuntu> do you need me now or can I just go>
[14:39] <niemeyer> cachio: Yeah, I have meetings early on, but then I'm available til the end of the day
[14:39] <zyga-ubuntu> Chipaca: and if you can +1 I'll land and iterate on some stuff
[14:39] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
[14:39] <mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
[14:39] <cachio> niemeyer, good, I'll ping you once I reproduce the error
[14:40] <zyga-ubuntu> Chipaca: and as for http itself, it would be great to make it not read /etc/init.d/
[14:41] <zyga-ubuntu> Chipaca: ok, I'm really going now, I'll be online in 20 minutes
[14:41] <zyga-ubuntu> just need to go downstairs to make the coffee there
[14:43] <gary-wzl77> zyga-ubuntu: Since we added kvm interface lately,  I'll update it to use my version of UDevConnectedPlug for the time being.
[14:43] <gary-wzl77> zyga-ubuntu: And will make some tweaks later after you PR is merged into master.
[14:44] <cachio> ogra_, getting the resize problem again https://paste.ubuntu.com/25240332/
[14:44] <cachio> does it help¡
[14:44] <cachio> ?
[14:46] <cachio> it is in the pi3
[14:46] <ogra_> cachio, i dont see a problem there (just normal fs corrections) ... what do "df -h" and "sudo sgdisk -p /dev/mmcblk0" show ?
[14:46] <ogra_> (and did you make sure the SD isnt mounted when dd*ing it ... etc etc ... )
[14:48] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[14:48] <mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[14:48] <cachio> ogra_, https://paste.ubuntu.com/25240354/
[14:48] <cachio> ogra_, I'll try again
[14:48] <ogra_> cachio, right, your partition table is broken once again ..
[14:49] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[14:49] <mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[14:49] <mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
[14:49] <mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[14:49] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[14:50] <mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[14:50] <mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
[14:50] <mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[14:50] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[14:52] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[14:52] <mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
[14:54] <mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[14:55] <mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
[14:55] <mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430, snapcraft#1432, snapcraft#1435
[14:56] <ogra_> cachio, perhaps you should file a bug and assign it to me to add more stuff to that log (i think it should perhaps run dh -f and sgdisk -p after the resize and dump that data into the log too )
[14:56] <mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[14:56] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[14:57] <ogra_> hmpf ... mup going mad again ?
[14:57] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[14:57] <mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[14:57] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[14:58] <mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[14:58] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[15:01]  * ogra holds the flyswatter over mup's head ...
[15:01] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[15:01] <mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
[15:01] <mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
[15:02] <ogra> :P
[15:03] <Chipaca> ogra: thank you
[15:04] <Chipaca> does this mean github is down again?
[15:21] <ogra> seems fine for my own branches
[15:21] <ogra> and i can open snapcore ones as well ... (at least via the website)
[15:25] <Saviq> hey all, can build.snapcraft.io accept a pre-existing snap name? one that I am a collaborator for?
[15:27] <Saviq> I've tried to register https://github.com/MirServer/mir-kiosk-apps, but it says mir-kiosk-apps is already taken and I may file a claim...
[15:27] <ogra> well if you want to take it over, file a claim
[15:28] <ogra> if you just want to upload ... just do it without claiming the name
[15:37] <Saviq> ogra: how do I do this with build.snapcraft.io? the repo is shown as "Not registered", when trying to register, it tells me that it's taken
[15:42] <ogra> hmm
[15:42] <ogra> thats a  question for evan ... who isnt much on IRC anymore recenly
[15:42] <ogra> try opening a forum thread i guess
[15:43] <ogra> (and ping him there)
[15:48] <Saviq> thanks, did so
[16:17] <cachio> ogra, after make snap refresh and reboot in the pi 3 I see this in the screen https://paste.ubuntu.com/25240921/
[16:18] <cachio> is it normal?
[16:18] <pstolowski> cachio, do need that fix for install-hook test for 2.27? or only master?
[16:18] <ogra> cachio, i have this with one SD card that is completely worn out due to too many write cycles to the bootloader config (it used to be my development card where i tested stuff and changed the config like ten times a day) ... smells like the SD is done (at least for booting, i guess you can use it fine in a camera for saving pictures still)
[16:18] <pstolowski> *do we*
[16:19] <cachio> pstolowski, if it is possible to add that to the nect RC should be great
[16:19] <pstolowski> cachio, sure, np, i'll propose a PR
[16:19] <cachio> pstolowski, great
[16:20] <cachio> ogra, ok, I'll try with another one
[16:20] <ogra> cachio, do you have that card in use for testing for long already ?
[16:20] <cachio> ogra, no so much
[16:20] <ogra> hmm
[16:21] <cachio> ogra, https://paste.ubuntu.com/25240943/
[16:21] <cachio> then I see this
[16:21] <ogra> yeah
[16:21] <ogra> thats notmal if it cant find any config anymore
[16:21] <ogra> the uboot.env is corrupt
[16:21] <ogra> *normal
[16:21] <cachio> ogra, ok, I'll try with another sdcard in that case
[16:22]  * cachio will need to buy new sd cards soon
[16:22] <ogra> the prob here is that the uboot.env always sits at the same sector on the card ... and if you re-write it a lot it gets worn out (that wont happen in nromal use )
[16:23] <cachio> ogra, ok, that makes sense
[16:23] <ogra> what you see there is just the hardcoded default boot process of uboot
[16:23] <ogra> (it falls back to netbooting )
[16:23] <pstolowski> cachio, PR #3661
[16:23] <ogra> your dhcp server obviously serves tftp btw :)
[16:23] <cachio> pstolowski, tx
[16:24] <cachio> ogra, I switched off/on the pi3 and I don't see the error anymore, I could log in
[16:25] <ogra> yeah
[16:25] <cachio> ogra, the problem was after restart it
[16:25] <ogra> it will show up after next kernel or core upgrade again
[16:25] <cachio> yes,
[16:25] <ogra> as soon as the uboot.env file gets written again
[16:25] <cachio> just want I need to test :(
[16:25] <ogra> you likely tested the rollback mechanism ;)
[16:26] <ogra> check with snap list ... and snap info what core and pi2-kernel say
[16:26] <cachio> hehehe, yes, unfortunately
[16:27] <cachio> ogra, snap changes is showing the error
[16:27] <ogra> yeah
[16:27] <cachio> I'll try with another sdcard
[16:27] <ogra> and snap info likely shows you that you are one revision behind on one of core or pi2-kernel
[16:27] <ogra> (whatever you updated before the reboot)
[16:28] <cachio> ogra, which sd card do you recommend for this kind of use
[16:28] <cachio> =
[16:28] <cachio> ?
[16:29] <cachio> ogra, which brand and type
[16:29] <ogra> i usually jjust randomly buy a cheap offer at my electronics discounter ... sandisk or transcend typically
[16:29] <ogra> i have a few 4GB ones in use but also 64G and 128G ones
[16:29] <cachio> ok
[16:30] <ogra> i dont think you can still easily buy 4G thogh ... i think 8 is the lowest atm
[16:30] <ogra> (at least here in germany ... it bought two new cards before london (that i didnt even unpack yet) and they didnt have smaller than 8 anymore)
[16:31] <cachio> ogra, ok, I'll try with 8GB ones
[17:07] <Chipaca> pedronis: have you EOWed yet?
[17:18] <pedronis> Chipaca: what's the question?
[17:18] <Chipaca> pedronis: i pushed code to the services branch, was wondering if it what you had in mind, but i'm this >< close from EOW myself as well :-)
[17:19] <pedronis> Monday :)
[17:20] <Chipaca> pedronis: :-)
[17:20] <Chipaca> pedronis: have a good'un!
[17:20] <pedronis> same
[17:21] <Chipaca> niemeyer, zyga, ogra, cachio, and you guys too!
[17:21] <Chipaca> \o
[17:21] <niemeyer> o/
[17:38] <superjonotron> does anybody know the official way to confiure network interfaces in ubuntu core 16?  have yet to find official documentation and files in /etc/network/interfaces.d folder do not seem to have any effect
[18:15] <Neeraj> I am not able to update the snap on dell 5000 GW did any one tried snap update
[18:46]  * zyga-arch returns
[18:54]  * zyga-arch will make lots of PRs like this: https://github.com/snapcore/snapd/pull/3662
[19:44] <cachio> niemeyer, running tests to detect reboot issue
[19:46] <niemeyer> cachio: Ok
[19:47] <Neeraj> hi anybody used DELL GW5000 "snap refresh " is not working
[19:57] <Facu> Neeraj, hello
[19:57] <Facu> Neeraj, you opened this?
[19:57] <Facu> https://forum.snapcraft.io/t/dell-gw5000-snap/1559
 yes
[20:00] <Neeraj> yes
[20:00] <Facu> Neeraj, sorry, I already commented on the forum
[20:01] <Facu> Neeraj, most surely is this (transient) problem: a new version was released for that snap, but still not verified, and (because of a bug) we're failing to serve it properly.
[20:01] <Facu> Neeraj, bug is recorded here: https://bugs.launchpad.net/snapstore/+bug/1707206 , it's already fixed, but still not in production (will be rolled out first days next week)
[20:02] <Neeraj> Facu, thanks for the update
[20:05] <Neeraj> Facu is their any way to install sanp classic for now
[20:06] <Facu> Neeraj, the problem is on refresh, on install it should work ok
[20:07] <Neeraj> Facu you mean to say that after sucessfull refresh the installation of classic will work
[20:08] <Facu> Neeraj, mmm... I say that if you do "snap install something" it will work, that the bug I'm talking about is exposed when you do "snap refresh something"
[20:08] <Facu> Neeraj, currently you can not do "snap install something"?
[20:09] <Facu> (maybe there's another problema and I'm misleading)
[20:10] <Neeraj> Facu you are correct I guess after refreshing the installation should work ::: the error is "ERROR snap "classic" assumes unsupported features: snapd2.23 (try to refresh the core snap)"
[20:11] <noise][> Neeraj: ah, so your device is quite a bit behind on core updates
[20:11] <Facu> Neeraj, I see
[20:12] <noise][> Neeraj: what does `snap version` and `'snap info core` show?
[20:13] <Neeraj> noise snap version is "  snap --version snap    2.17 snapd   2.17 series  16"
[20:13] <noise][> ok, very far behind then :/
[20:14] <Neeraj> Noise : once I execute "snap info core" i get error :: error: unknown command "info", see "snap --help"
[20:14] <noise][> When Facu's fix lands hopefully Mon/Tues that should unblock your 'core' snap refresh and then let you install classic
[20:14] <noise][> sorry for the inconvenience
[20:15] <Neeraj> thanks
[20:25] <cachio> niemeyer, Spread-50
[20:26] <cachio> <IP_ADDRESS>
[20:26] <niemeyer> cachio: Okay, what should I look for?
[20:27] <cachio> the output in the console
[20:27] <cachio> it is not starting after reboot
[20:27] <cachio> niemeyer, I need to know what is showing the linode console
[20:29] <cachio> niemeyer, or if you can save the disk should be nice too
[20:30] <niemeyer> cachio: http://paste.ubuntu.com/25242314/
[20:31] <cachio> niemeyer, nice
[20:31] <cachio> No space left on device
[20:32] <niemeyer> Yep
[20:33] <cachio> niemeyer, which disk are we using for core runs?
[20:33] <cachio> on linode
[20:33] <niemeyer> cachio: This is what happens before the panic:
[20:33] <niemeyer> + mount -t tmpfs none /tmp
[20:33] <niemeyer> + cp /bin/busybox /tmp
[20:33] <niemeyer> + cp /home/image/all-snap-amd64.img /tmp
[20:33] <niemeyer> cachio: So it's not actually adisk
[20:33] <niemeyer> cachio: The tmpfs is too small
[20:33] <niemeyer> Not enough memory
[20:34] <cachio> I see
[20:34] <niemeyer> cachio: Problem most likely is that all-snap being too large
[20:34] <niemeyer> cachio: Sorry, that's obvious.. what I actually mean is
[20:34] <niemeyer> cachio: The problem most likely is that somehow we're leaving trash around during the test run, and then trying to pack it into that file
[20:35] <niemeyer> cachio: let me try to give you a debug environment on that machine.. just a second
[20:35] <cachio> niemeyer, good, thanks
[20:40] <cachio> niemeyer, in this case, the machine did not run any test before the reboot
[20:40] <cachio> so, I don't think there is any trash
[20:48] <niemeyer> cachio: Your spread is still running, right?
[20:48] <cachio> niemeyer, it is on travis
[20:49] <cachio> niemeyer, if you can save the disk should be great
[20:49] <cachio> it will be killed in few minutes
[20:49] <niemeyer> cachio: Oh, ouch
[20:49] <niemeyer> cachio: Glad you warned me ;)
[20:52] <niemeyer> cachio: Okay, the machine should be up again now
[20:52] <niemeyer> cachio: root has the same password
[20:52] <niemeyer> cachio: It's a pristine 16.04 image, though
[20:52] <niemeyer> cachio: Original disk is under /dev/sdc
[20:52] <niemeyer> cachio: Have fun! :)
[20:55] <cachio> niemeyer, I don't have the password :)
[20:55] <cachio> how do I get it?
[20:55] <niemeyer> cachio: Now you do
[20:56] <cachio> niemeyer, :)
[20:56] <cachio> tx
[21:03] <niemeyer> cachio: School run, will bbiab
[21:03] <cachio> niemeyer, np
[21:43] <niemeyer> cachio: Back.. any news?
[21:44] <cachio> niemeyer, not yet, trying to reproduce it
[22:39]  * zyga-suse EOWs
[23:34] <cachio> niemeyer, the only thing I see is that /tmp is not being cleaned before reboot
[23:34] <cachio> and as the first thing the system does when reboots is to mount /tmp
[23:35] <niemeyer> cachio: How would that be relevant?
[23:35] <cachio> in /tmp already are a lot of things
[23:37] <niemeyer> cachio: But how would that matter?
[23:38] <cachio> niemeyer, it is mounting /tmp on memory
[23:39] <cachio> so if /tmp has data, it will waste memory on that data
[23:40] <cachio> niemeyer, perhaps I am missunderstanding the script
[23:40] <niemeyer> cachio: Isn't it mounting a tmpfs on /tmp?
[23:40] <cachio> yes
[23:40] <cachio> niemeyer, or at least it is doing > mount -t tmpfs none /tmp
[23:41] <niemeyer> cachio: SO how is the data in the underlying /tmp relevant?
[23:41] <cachio> niemeyer, is it going to memory that data?
[23:42] <cachio> I mean RAM memory?
[23:43] <niemeyer> cachio: Yeah, tmpfs is supposed to keep the data in memory
[23:45] <cachio> niemeyer, my point is that previous to do that, we are storing data in /tmp, this data will go to the RAM, so perhaps when we try to copy the all-snap-amd64.img we go out of memory
[23:45] <niemeyer> cachio: That's not how mounting works
[23:46] <cachio> niemeyer, ok, my bad in that case
[23:46] <niemeyer> cachio: Once you mount something over a mountpoint, the data under the mounted filesystem just stays there
[23:47] <cachio> niemeyer, ok
[23:51] <niemeyer> What's the size of the data file?
[23:52] <cachio> niemeyer, should be about 300 MB
[23:53] <cachio> niemeyer, let me check
[23:54] <cachio> trying to run the test on that machine but getting a problem
[23:54] <cachio> Run configure hook of "core" snap (run hook "configure": cannot stat /var/lib/snapd/seccomp: No such file or directory)
[23:55] <cachio> niemeyer, and the dir exists