[00:12] <mup> PR snapcraft#1354 opened: catkin plugin: fix pythonpath for catkin_find <Created by mrjogo> <https://github.com/snapcore/snapcraft/pull/1354>
[02:51] <mup> PR snapcraft#1353 closed: cli: default options for the implicit snap command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1353>
[03:51] <mup> PR snapcraft#1355 opened: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
[07:10] <morphis> mvo: ping
[07:11] <mvo> morphis: pong
[07:11] <morphis> mvo: how was the long weekend? :-)
[07:12] <mvo> morphis: very nice, thank you! for you as well?
[07:12] <morphis> mvo: yeah, happily quite sunny yesterday so a great end :-)
[07:13] <morphis> mvo: one quick question for you: should we ship the snap-repair systemd units on classic systems?
[07:15] <mvo> morphis: we don't need to, its disabled there anyway
[07:15] <morphis> mvo: good!
[07:15] <mvo> morphis: so far we use the same debs to build classic and core this is why they are included currently
[07:15] <morphis> yeah, guesses that already but let me exclude these units for other distros then
[07:15] <morphis> doesn't make much sense to have them installed there
[07:16] <mvo> morphis: +1
[07:16] <NicolinoCuralli> hi guy i need to use ssh-pass and i need to access /dev/tty : is serial-port the right interface?
[07:17] <morphis> NicolinoCuralli: for serial-port you need to define a slot on the gadget snap for that specific tty, if that is an option, then the answer is yes
[07:17] <NicolinoCuralli> thanks morphis
[07:18] <morphis> mvo: thanks
[07:18] <morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3427 ?
[07:18] <mup> PR snapd#3427: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427>
[07:19] <mvo> morphis: looking
[07:19] <mvo> morphis: thank you
[07:19] <mup> PR snapd#3427 closed: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3427>
[07:21] <zyga_> mvo: good morning!
[07:21] <mvo> hey zyga_!
[07:21] <zyga_> mvo: lots has happened since Friday :-)
[07:22] <morphis> zyga: morphis!
[07:22] <morphis> mvo: thanks
[07:22] <zyga_> hey hey :-)
[07:22] <mvo> zyga_: oh? tell me more? I'm slowly catching up (reading forum etc)
[07:23] <zyga_> mvo: mainly we know how to reproduce the error from last week
[07:23] <zyga_> mvo: looks like apparmor/lxd bug, still working on it (just got to the office)
[07:23] <zyga_> mvo: thank you for participating in the arch bug, I think the arch package needs to be improved slightly, I suspect we may be missing something simple just because the package is broken
[07:23] <mvo> zyga_: awesome!
[07:24] <zyga_> morphis: I wonder if we could do arch (after suse) CI next
[07:24] <morphis> zyga: why not, but lets land suse/fedora first :-)
[07:24] <mvo> zyga_: aha, thanks, the arch bug was a bit of a drive-by-comment. so the lock-error happens inside lxd?
[07:24] <morphis> zyga: I have mint on my list too
[07:24] <kunal> Hello dear community .... I need help regarding snapcraft of a python app
[07:25] <kunal> please help me
[07:25] <zyga_> mvo: not sure yet but what it looks like is that apparmor profile from the host confines the guest
[07:26] <morphis> kunal: best is if you post your specific question on https://forum.snapcraft.io
[07:26] <mvo> zyga_: great, thanks a lot for chasing this further. out of curiosity, how did you find this out?
[07:27] <zyga_> mvo: it was reported on the forum actually
[07:27] <mvo> zyga_: sweet
[07:27] <zyga_> mvo: so all the credits go to the reporter :)
[07:27]  * mvo takes a short tea break
[07:27] <morphis> zyga: why are you asking about ARch? anything specific?
[07:27] <zyga_> but forum is so nice to engage with, not like ML where you cannot reply to stuff you didn't see before easily
[07:27] <zyga_> morphis: to run spread tests on it
[07:28] <zyga_> morphis: even in nightly mode if we can
[07:28] <morphis> sure, but is there anything which brought this up or just in general?
[07:28] <zyga> morphis: ah, I wonder if the error reported on the forum is pointing out something deeper that's broken there
[07:28] <morphis> zyga: ?
[07:28] <kunal> My problem is - I am working on a snap for my python app... I am unable to understand why doesn't it download python packages available through apt-get
[07:29] <kunal> why doesn't snap download the python modules from main repository.
[07:31] <zyga> morphis: I mean this one https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884
[07:32] <zyga> kunal: hey, what did you expect to happen and how did you express this in your snapcraft yam?
[07:32] <zyga> yaml*
[07:32] <kunal> or if it does not download some module for python, then how will my program/app run. It only downloads from pypi . It may be a stupid type question, but dear community members ... I need your help here... Please help me
[07:32] <morphis> kunal: that hardly depends on how you structure your snapcraft.yaml
[07:33] <zyga> kunal: apt is available through "stage packages"
[07:33] <zyga> kunal: why do you prefer apt over python package index?
[07:34] <kunal> I specified/ included espeak under python-packages in my snapcraft.yaml but then it gave me an error... the same thing happend with scipy .
[07:34] <zyga> kunal: I think you should open a question on the forum, include the error message and relevant parts of your snapcraft.yaml
[07:36] <kunal> I do not prefer apt over pypi but i just want to know that if some python module is not dowloaded by snapcraft then, how will my program run , because it requires those python module at runtime...
[07:36] <morphis> zyga: did you finish the changes for snap-confine we talked about last week?
[07:37] <zyga> morphis: almost, I ended up finishing something I already got a review of
[07:37] <zyga> morphis: (which grew slightly so took whole day)
[07:37] <zyga> morphis: I finished making the structural changes but I need to comment on everything heavily to guide the reviewers
[07:38] <zyga> morphis: though on the bright side almost all changes are in snap-confine.c so it's not a revolution
[07:38] <morphis> zyga: ok
[07:44] <morphis> zyga, mvo, pedronis, Pharaoh_Atem: another review on https://github.com/snapcore/snapd/pull/3222 would be much appreciated, getting really tired of merging/fixing that with master again and again :-)
[07:44] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[07:46] <morphis> and the PR is now pending for nearly 1,5 months
[07:56]  * zyga_ sees re-exec disabled by user again
[07:57] <morphis> zyga: Linode has an prebuilt Arch image so shouldn't be much work
[08:01] <NicolinoCuralli> morphis: i tell you wrong device : i need to use a pty device from my snap: actually is it possible ?
[08:05] <zyga> NicolinoCuralli: each snap gets private ptys
[08:07] <NicolinoCuralli> zyga: i have an error as this : debug1: read_passphrase: can't open /dev/tty: No such device or address
[08:08] <NicolinoCuralli> it seems as if the command can't access the device
[08:21] <NicolinoCuralli> zyga: some hint on the problem?
[08:22] <zyga> I don't think you can open /dev/tty
[08:22]  * zyga looks
[08:22] <zyga> yep
[08:22] <zyga> it's not allowed
[08:24] <NicolinoCuralli> zyga: neither enabling a new interface?
[08:28] <zyga_> NicolinoCuralli: a new interface could allow it but I think it is disallowed for a reason now
[08:28] <zyga_> NicolinoCuralli: can you please start a forum topic
[08:29]  * zyga_ is busy with some other things now and cannot actively look at why /dev/tty was left out of current interfaces
[08:32] <NicolinoCuralli> zyga: thanks for your help : I find another solution to implement what I make with sshpass, but I think to start a forum topic for document this restriction
[08:44] <morphis> fgimenez: is there any specific reason why you're using -q for nc in the networking spread tests for snapd?
[08:46] <fgimenez> morphis: iirc it was meant to limit the time the test waits, let me check
[08:46] <morphis> fgimenez: as -q is not really portable across distributions
[08:48] <fgimenez> morphis: feel free to tweak it as needed, maybe we can do the same with another portable option, perhaps -w?
[08:48] <morphis> maybe
[08:48] <morphis> let me play with that
[08:57] <om26er> where can i find documentations about delta uploads ? I have been looking around but didn't find them also google doesn't bring up anything related to that.
[09:16] <fgimenez> hey zyga_, snapd#3430 should be fixed now for 14.04, i was getting http://paste.ubuntu.com/24791901/ after the error, pls take another look when you have a moment
[09:16] <mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
[09:17] <zyga> ok
[09:18] <zyga> hmm
[09:18] <zyga> not sure what to say
[09:20] <zyga> fgimenez: what think is missing is snap-confine's /snap sharing
[09:20] <zyga> fgimenez: is this done before snap-confine gets a chance to run?
[09:20] <ogra> fgimenez, ls /var/lib/snapd/snaps/core_*.snap will explode if there are more than one core snap (for whatever reason)
[09:22] <fgimenez> zyga: this is done after snapshoting the state, when restarting the units https://github.com/fgimenez/snappy/blob/cb71389e43b5aa0708715721faad1880c7629161/tests/lib/prepare.sh#L173
[09:23] <fgimenez> ogra: thx! at this point it is not expected to have more than one core, we are at a very early stage of suite preparation, but the check can indded be more robust, i'll push changes for that
[09:24] <ogra> :)
[09:25] <fgimenez> zyga: it is done also with the daemon stopped, not sure if that matters
[09:25] <zyga> fgimenez: is this easy to reproduce?
[09:25] <zyga> fgimenez: it should not matter
[09:25] <fgimenez> zyga: yep, from the branch seems to be very consistent
[09:25] <zyga> fgimenez: I'm happy to take a look after exploring the juju/lxd issue
[09:26] <fgimenez> zyga: great, thank you
[09:44] <pedronis> morphis: maybe I'm misreading but in snapd#3222 it seems you did exactly the opposite of what Gustavo asked
[09:44] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[09:47] <pedronis> morphis: https://github.com/snapcore/snapd/pull/3222#discussion_r116286335  soundes like ...Join(rootdir,... should be there, anyway I don't have a strong opinion, but sounds you need his re-review
[09:47] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[09:48] <morphis> pedronis: thanks, yeah I need his review again
[09:48] <morphis> pedronis: there are two different parts
[09:48] <morphis> there is CoreLibExecDir which never has a prefix
[09:49] <morphis> and in all others cases I am using dirs.StripRootDir like in https://github.com/snapcore/snapd/pull/3222/files#diff-6dd6f3a48b395a14870975240679b8cdR86
[09:49] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[10:00]  * zyga experiments with juju and has his head spinning
[10:00] <zyga> I think this is the perfect time for a coffee
[10:01] <tai271828_> haha
[10:07] <zyga> hey tai271828_ :)
[10:07]  * zyga looks at juju output and waits for more things to install
[10:07] <tai271828_> \o zyga did you get your coffee
[10:14] <mup> PR snapd#3434 opened: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
[10:16] <fgimenez> hi pedronis, we are missing another snap-id for staging, see ^^^, however i'm still getting an error after adding the right id http://paste.ubuntu.com/24792792/, i've just uploaded the same prod snap to staging, is something else missing?
[10:16] <zyga> tai271828_: yes I did
[10:16] <mup> PR core#35 closed: move xdg-open to proper paths <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core/pull/35>
[10:16] <mvo> if someone could have a second look at https://github.com/snapcore/core/pull/48 that would be great
[10:16] <mup> PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[10:17] <pedronis> fgimenez: you need to change the python in that test as well
[10:18] <fgimenez> pedronis: aha! thx on it
[10:18] <pedronis> fgimenez: sorry, not the python
[10:19] <pedronis> fgimenez: but the yaml has this:  environment:
[10:19] <pedronis>     TEST_SNAP_ID: aLcJorEJZgJNUGL2GMb3WR9SoVyHUNAd
[10:19] <fgimenez> pedronis: that should be addressed with the changes in snapd#3434
[10:19] <mup> PR snapd#3434: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
[10:20] <fgimenez> pedronis: hmm i see a typo in there, let me fix it
[10:22] <Chipaca> \o
[10:22]  * Chipaca appears in a cloud of post-physio exhaustion
[10:25] <ogra> clouds are the future i heard
[10:25] <zyga> unless it rains
[10:27] <Chipaca> I think people who used to gravitate towards torturer and executioner roles in the past now just pick up physio
[10:28] <Chipaca> "you'll feel a little stretch" <turns the rack wheel>
[10:28] <zyga> "you will fell a little sting"
[10:30] <fgimenez> pedronis: works fine now, sorry for the noise
[10:43] <mvo> flexiondotorg: hey, do you have an example app that uses gnome-keyring that could be used to do a real world test for a new interfaces for gnome-keyring?
[10:43] <flexiondotorg> Hi
[10:43] <flexiondotorg> I do.
[10:43] <flexiondotorg> Skype for Linux
[10:44] <zyga> flexiondotorg: skype for linux beta or the one that was de-comissioned just now/
[10:44] <mvo> flexiondotorg: great, where can I find the snapcraft.yaml to add the right ifcace for testing?
[10:44] <flexiondotorg> The new Electron version.
[10:44] <mup> PR snapd#3435 opened: interfaces: add password-manager-service implicit interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/3435>
[10:44] <flexiondotorg> ANd also Nylas Mail (the newer open source version), also Electron.
[10:45] <mvo> fgimenez: I have a new snap-test-security-service-consumer snap, what was the central place for those again so that they are all auto-build/uploaded?
[10:45] <flexiondotorg> mvo I'll just make sure both yamls are current.
[10:45] <flexiondotorg> Give me a few mins...
[10:46] <mvo> flexiondotorg: no worries, I will soon have lunch anyway, so no rush :)
[10:51]  * ogra glares at snapd 3432 ... how can a journald run on 14.04 (which doesnt have systemd)
[10:52] <zyga> ogra: snapd pulls it in
[10:52] <zyga> ogra: we have systemd on 14.04 but it is a special build
[10:52] <ogra> and that is a fully working systemd (providing logging )
[10:52] <ogra> i thought that was just a stub
[10:52] <zyga> ogra: oh, journald is there?
[10:52] <zyga> I thought journald did not work
[10:52] <zyga> nice :)
[10:52] <ogra> zyga, thats what i mean
[10:53] <ogra> how can https://github.com/snapcore/snapd/pull/3432 actually work on a 14.04
[10:53] <mup> PR snapd#3432: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432>
[10:53] <ogra> where we have no fully working systemd
[10:53] <ogra> (and thus no journald)
[10:54] <ogra> tvoss, is the 14.04 systemd thing actually starting a journald ??
[10:54] <ogra> (iirc you worked on that)
[10:59] <morphis> ogra: I doubt that
[11:02] <ogra> morphis, hmm, curious ... why is that needed then ...
[11:02] <morphis> not sure
[11:09] <zyga> lazyPower: hey, I'm trying to reproduce the issue we spoke of yesterday
[11:09] <zyga> lazyPower: how long should conjure-up be doing its thing?
[11:10] <zyga> lazyPower: I'm currently seeing "waiting for applicationto start"
[11:10] <zyga> lazyPower: juju status spews a lot of output, some things being active, some in maintenance
[11:10] <zyga> lazyPower: (it all means nothing to me unfortunately)
[11:13] <zyga> hmm, actually, I think it is making progress
[11:18] <fgimenez> mvo: thx for the heads up! we are uploading the source files here https://code.launchpad.net/~snappy-dev/snappy-hub/ and from there they are published to production, i'll register and upload it to staging
[11:19] <fgimenez> mvo: btw we need two more test snaps in prod undere the shared account, i'll ping you later about this
[11:21] <ogra> wow, someone still uses snappy-hub ?!?
[11:25] <pedronis> all our test snaps are built under it I think
[11:26] <pedronis> test snaps, as used by spread tests
[11:28] <ogra> ah ... interesting
[11:28] <ogra> i thogught even that was moved to GH
[11:28] <zyga> lazyPower: almost all apps are active now, I see that kubernetes-master is still "waiting"
[11:29] <zyga> lazyPower: with a message "waiting for kube-system podto start"
[11:29] <zyga> lazyPower: still looks OK-ish
[11:30] <zyga> lazyPower: I did start with snapd 2.25 as that's what I got after update from 2.0.10
[11:30] <zyga> lazyPower: I'll let this finish and try again with manually started 2.21
[11:30] <zyga> lazyPower: you said you had 2.21 on the host and 2.25 in lxd, can you explain which of the machines had 2.25 exactly? how can I check that?
[11:32] <zyga> lazyPower: in the end it failed with "step requires paswordless sudo"
[11:32] <zyga> and a python backtrace
[11:34] <zyga> in the end I can see a few denials that are not caused by snapctl
[11:34] <zyga> let me add this to the forum
[11:35] <morphis> pedronis: can I set the device-service.url configuration item for the gadget snap after the firstboot process still if the device does not have a serial-assertion yet?
[11:37] <pedronis> morphis: in which context?
[11:38] <morphis> pedronis: in a case where a customer has it's own local serial-vault and we have a generic image and we want to point that now to the local serial-vault
[11:38] <pedronis> morphis: well generic image will have a generic model
[11:38] <pedronis> something doesn't compute there
[11:39] <pedronis> generic in which sense?
[11:39] <morphis> generic in a sense of that we want to cover a bigger set of devices with the same image to save costs of doing n different images
[11:40] <morphis> so we have an image generic for a brand
[11:44] <pedronis> morphis: in principle atm yes,  device registration is retried
[11:44] <morphis> ok
[11:49] <lazyPower> zyga: thats an unrelated thing, conjure-up is trying to fetch snap packages required to maintain the application
[11:50] <lazyPower> zyga: i had 2.21 on the host, each container would have had 2.25. after upgrading to 2.25 on my host yesterday it appears to have resolved itself as well
[11:51] <ogra> sounds like a re-exec vs non-rexec issue
[11:52] <zyga> lazyPower: aha, I see
[11:52] <zyga> lazyPower: I'll do another pass now, using 2.21 on the host
[11:52] <zyga> lazyPower: I think the bug is still there, it is just masked by 2.25 on the host
[11:53] <lazyPower> masked huh :)
[11:54] <mvo> fgimenez: sounds good, thank you
[11:59] <iliv> hi, when I run "snap alias" command as an unprivileged user it displayes the following "error: access denied (try with sudo)". is this expected or a problem?
[12:00] <ogra> iliv, well, that will also be the message when you snap install and such
[12:00] <iliv> well, I'm reading this https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/ and it leads me to believe snap alias can be run as an unprivileged user (?)
[12:00] <ogra> iliv, it should also say that you can "snap login" instead of using only sudo ...
[12:01] <ogra> iliv, yes, an unprivileged user that used snap login before
[12:01] <iliv> hm
[12:02] <ogra> i dont think we support actual per-user aliases yet ... ( pedronis may correct me) which wouldnt need snap login or sudo
[12:03] <pedronis> aliases are global
[12:04] <iliv> pedronis, which user manages them? root?
[12:05] <pedronis> snapd so root
[12:05] <pedronis> iliv: anyway when 2.25/2.26 come out that blog post is not valid anymore
[12:06] <iliv> ogra, after issuing snap login I was able to "snap alias" as an unprivilged user
[12:06] <pedronis> things work differently
[12:06] <ogra> iliv, yeah :)
[12:06] <iliv> pedronis, I hope you guys will update it then
[12:06] <iliv> pedronis, btw I run 2.25
[12:06] <pedronis> davidcalle: hi, did you see my ping in the foru about that btw  ?
[12:06] <iliv> for both snap and snapd
[12:07] <pedronis> iliv: then you need to read: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/33
[12:07]  * zyga -> lunch
[12:08] <davidcalle> pedronis: I don't think I did :/
[12:08] <pedronis> davidcalle: we need a new post or to update the old one about aliases once 2.26 is on stable
[12:09] <pedronis> given that things have changed
[12:11] <iliv> davidcalle, and if you add now "snap login is required before running all the commands below" it can save some time anyone who is reading that blog post. no need to wait for 2.26.
[12:12] <davidcalle> iliv: good point
[12:12] <davidcalle> pedronis: what's the eta on this? Two weeks?
[12:14] <pedronis> davidcalle: don't know,  mvo what's the eta on 2.6.4 going stable ?
[12:20] <zyga> davidcalle: I think this is in the hands of fgimenez now
[12:23] <mvo> pedronis, davidcalle: no firm deadline but ASAP. we need QA approval from fgimenez and the CE team. AIUI the CE team is currently testing the new core (correct federico?)
[12:24] <fgimenez> mvo yep, the validation on beta was successful, it was promoted yesterday to candidate and now CE QA and Cert are validating it, as soon as they finish with it and you and JamieBen_ give your ok it can be promoted to stable
[12:25] <mvo> fgimenez: excellent ! thank you
[12:28] <iliv> hm okay, so I've just created an alias for postgresql93.psql and "whereis psql" points to /snap/bin/psql. However, when I run "psql --version" /usr/bin/psql is called. what gives?
[12:28] <iliv> here's my terminal history that illustrates this problem: https://dpaste.de/62Vk/raw
[12:28] <mup> PR snapd#3434 closed: tests: add staging snap-id <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3434>
[12:29] <iliv> oh, I see
[12:30] <iliv>  I needed to relogin
[12:30] <iliv> that's weird anyway
[12:30] <iliv> once I exited and relogined psql started to resolve to /snap/bin/psql
[12:31] <iliv> this looks like a bug to me. normally system wouldn't require a shell logout to pick up a new location of a binary.
[12:32] <iliv> ogra, pedronis davidcalle
[12:34] <ogra> iliv, did you have a deb installed before ?
[12:34] <iliv> correct
[12:34] <ogra> sounds more like bash is caching something to me then
[12:34] <ogra> (not really like a snap issue)
[12:35] <iliv> right
[12:35] <iliv> I have just been ables to reproduce it the other way around
[12:35] <iliv> i.e. install snap package first, then deb
[12:35] <iliv> same issue
[12:35] <ogra> but yeah, sounds like a bug ... would be nice to know if that also happens when you have a deb where a binary moves from /usr/bin to /bin or some such
[12:35] <iliv> I guess a shell logout/reinitialization is required after all
[12:36] <ogra> (to prove it isnt actually snap related)
[12:36] <iliv> mhm
[12:58] <pedronis> davidcalle: so sounds a bit less thant 2 weeks in the good, more like this one or the next
[12:59] <davidcalle> pedronis: sounds good, thanks. I'll be in the snapcraftio sprint this week, I'll make it part of it
[12:59] <pedronis> thank you
[12:59] <pedronis> let me know if you have questions
[13:00] <davidcalle> +1
[13:16] <zyga_> mvo: https://github.com/snapcore/snapd/pull/3370
[13:16] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[13:17] <zyga> mvo: that's the implicit pr, if this lands your pr won't have to change implicit anymore
[13:17] <zyga> mvo: and the last thing will be the base declaration
[13:22] <zyga> I cannot reconnect to the call
[13:23] <zyga_> I cannot re-connect
[13:33] <zyga_> fgimenez: hey
[13:33] <zyga_> fgimenez: I have one more idea about the 14.04 issue with mounted core
[13:33] <zyga_> fgimenez: I think /etc/mtab is a file, not a symlink to /proc/mtab
[13:33] <zyga_> fgimenez: and this is causing this issue
[13:34] <zyga_> fgimenez: if I'm right we may have to ensure we always keep those two in sync
[13:36] <fgimenez> zyga_: aha, that would make a lot of sense, when i try to unmount core it gives an error saying it wasn't mounted (that's the reason of the "|| true" in the PR), but it was reported by "mount"; after the call to umount all is good, seems that both versions are in sync
[13:36] <fgimenez> zyga_: and the original error messaage refers to mtab http://paste.ubuntu.com/24791901/
[13:36] <zyga> fgimenez: right, because on 14.04 mtab is a file maintained by userspace tools but later on it was changed to a symlink to kernel's mtab which is always correct
[13:38] <morphis> mvo: shouldn't the tests/main/snap-repair spread test case be ubuntu-core-* specific?
[13:38] <fgimenez> zyga_: should i raise a bug about this? also, about the PR, is there a better solution, maybe copying /proc/mtab to /etc/mtab?
[13:39] <zyga> fgimenez: I'm not sure yet, I think it is partially a "feature" of 14.04 but I wonder which changes triggered the problem now
[13:39] <zyga> fgimenez: if it is just affecting tests we can do something about it in spread, I wonder (and worry) about 14.04 outside of test environment
[13:40] <fgimenez> zyga_: the only difference is the call to snap-discard-ns core afaik
[13:40] <fgimenez> without it 14.04 doesn't give this error
[13:42] <mvo> morphis: yes, it should be
[13:43] <morphis> mvo: ok, will mark it as such
[13:43] <icey> so, after a forum post about getting a default alias (with several +1s), how long would be normal to wait? https://forum.snapcraft.io/t/ripgrep-aliased-as-rg/351
[13:47] <Chipaca> noise][: who deals with setting up aliases?
[13:48] <pedronis> jdstrand mostly
[13:48] <Chipaca> icey here has had a request for aliases open for over a month, with a +1 from jdstrand and niemeyer for nearly as long
[13:48] <Chipaca> that won't do :-(
[13:48] <icey> Chipaca: hence me coming to bug people about it :)
[13:49] <Chipaca> icey: yeah
[13:49] <Chipaca> icey: thanks!
[13:49] <Chipaca> so my question is, what do we do to avoid this from happening again
[13:49] <icey> maybe I shoudl make a forum/IRC bot to bug people when there are a lot of +1 (especially from some names) on the forums
[13:49] <zyga> Chipaca: I mentioned this once before but I really really think this should always be a bug on the snappy store project
[13:49] <icey> s/shoudl/should
[13:49] <zyga> https://launchpad.net/snapstore
[13:50] <noise][> zyga: i don't think that's the right place since my team doesn't handle those approvals
[13:50] <zyga> noise][: what do you suggest then?
[13:51] <Chipaca> right, if it's jdstrand, we need to bug him :-)
[13:51] <Chipaca> mup: pester jdstrand until morale improves!
[13:51] <mup> Chipaca: I apologize. I'm a program with a limited vocabulary.
[13:51] <noise][> need to chat w/jdstrand
[13:52] <noise][> the process is clearly leaky, but we've agreed (at least thus far) that we want the forum discussion for those requests, and not just a queue in the store
[13:52] <ogra> the prob with the forum discussions is that they vanish over time
[13:53] <ogra> (not physically but they simply scroll off the overview eventually)
[13:53] <zyga> noise][: maybe we just need both
[13:53] <ogra> some kind of remonder system would be nice there
[13:53] <zyga> noise][: file a bug and open a forum thread
[13:53] <icey> I wonder if there's some way to unite these two ideas, so that you have a forum discussion with some kind of queue that proposals can be removed from when handled
[13:53] <ogra> *reminder
[13:53] <zyga> mvo: hey, I read your new interface PR
[13:54] <zyga> mvo: I have two comments/suggestion
[13:54] <pedronis> people can bookmark things in the forum fwiw
[13:54] <mvo> zyga: excellent, I check them out
[13:54] <zyga> mvo: one is that you need to tweak tests to pass on fedora and other non-deb systems
[13:54] <jdstrand> icey, et al, let me look
[13:54] <zyga> mvo: ah, I didn't send them there :)
[13:54] <mvo> zyga: indeed
[13:54] <mvo> zyga: aha, ok :)
[13:54] <zyga> mvo: and the other one, which is just a suggestion, is to perhaps open a forum thread and document the interface there
[13:55] <zyga> mvo: my branch adds a DocsURL meta-data, so you can document the interface and people will be able to find that by saying "snap interface password-manager-service"
[13:56] <mvo> zyga: nice, I will do that
[13:56] <zyga> mvo: and if you +1 https://github.com/snapcore/snapd/pull/3370 we can also define implicitness through the meta-data, one less file to edit
[13:56] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[13:57] <Chipaca> jdstrand: icey: it looks like what happened is that the request came in just as we were (re)defining the process for this, and fell through the cracks
[13:57] <icey> Chipaca: I'm good at finding those cracks apparently :-P
[13:57] <mvo> zyga: thanks, I check that branch out now too
[13:57] <icey> and it wasn't high enough on my priority list to follow up on
[13:57]  * ogra hands icey  a pot with plaster to close them :P
[13:57] <zyga> mvo: thank you! note that those are just suggestions (the docs at least)
[13:58] <zyga> mvo: so don't feel blocked by this
[13:58] <jdstrand> Chipaca: well, we defined the process, but there is a not great part of circling around after a week. that didn't happen with this one. there are a couple of others I'm going to follow up on too
[13:59] <Chipaca> jdstrand: i panicked for a moment thinking we were leaving people in limbo, but it looks like i was wrong; sorry if i was too pushy or something there
[14:00] <jdstrand> Chipaca: the circling around bit did slip through so thank you for the reminder
[14:00] <icey> Chipaca: limbo can be relaxcing too ;-)
[14:00] <jdstrand> icey: as mentioning in the forum, sorry for the delay
[14:01] <jdstrand> menioned*
[14:01] <jdstrand> meh
[14:01] <icey> no worries jdstrand, partially on me too for not following up
[14:01] <jdstrand> mentioned*
[14:01] <ogra> i really think remindesr should be a forum feature ...
[14:01] <ogra> reminders
[14:10] <niemeyer> Heya
[14:11] <niemeyer> For the requests queue, we already have a check mark we use when the request is handled
[14:11] <niemeyer> What's missing is a proper view that lists only such requests so it's obvious what's pending
[14:11] <niemeyer> I think either a category or a tag will do
[14:12] <ogra> niemeyer, well, couldnt it also send some reminder mail if such a request is open and untouched for a certain amount of time ?
[14:12] <niemeyer> Perhaps "upcoming" + "jdstrand"?
[14:12] <ogra> (or a forum notification, doesnt need to be mail indeed)
[14:15] <niemeyer> I expect this list to never be empty.. anything over a week needs resolution or continued discussion until we resolve it
[14:16] <niemeyer> So it's more a continuous process than something we need to be reminded about
[14:18] <mup> PR snapd#3436 opened: tests: fix econnreset on staging <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3436>
[14:23] <ogra> k
[14:36] <mvo> stgraber: hey, I wrote a simple lxd snap integration test so that we don't break it accidnetly https://github.com/snapcore/snapd/pull/3372 - however I get errors on 14.04 and 16.04-32, one looks like this "error: Get http://unix.socket/1.0/operations/a59c76b5-5f7c-4b39-b8c8-05315404a32a/wait: EOF" the other one (14.04) s a timeout. are those platforms supposed to work? if so, what can I do to help debugging?
[14:36] <mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[14:41] <zyga_> mvo: I think 14.04 is not going to work (CC jdstrand )
[14:47] <jdstrand> if 14.04 is using the lts kernel, I don't know why it wouldn't work
[14:48] <jdstrand> assuming it has all the required debs installed
[14:59] <cachio_> mvo, the change to move the prepare_each_classic to project level has broken the upgrade tests
[14:59] <cachio_> mvo, I am gonna revert the change
[14:59] <mup> PR snapd#3428 closed: tests: add snap-confine privilege test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3428>
[14:59] <mvo> cachio_: ok, thanks for trying it!
[15:00] <cachio_> mvo, sure
[15:23]  * zyga reboots to test something
[15:33] <mup> PR snapd#3430 closed: tests: modify core before calling set <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3430>
[15:58] <iliv> davidcalle, I continue exploring aliases and I've just realised one doen't even need aliases: in snapcraft.yml to set up manual aliases. Was it different in some prior version to 2.25?
[16:07] <Pharaoh_Atem> morphis: I'll take a look at the PR later today
[16:08] <morphis> Pharaoh_Atem: thanks
[16:14] <stgraber> mvo: sorry, sprinting. We run daily tests of the LXD snap on 14.04 and 16.04, works on both for us.
[16:15] <stgraber> mvo: https://jenkins.linuxcontainers.org/job/lxd-test-snap/
[16:17] <zyga_> jdstrand: do you have a chance to give me a +1 here: https://github.com/snapcore/snapd/pull/3370
[16:17] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[16:20] <kyrofa> zyga, any idea what's happening here? https://askubuntu.com/questions/922484/how-to-install-telegram-snap-on-ubuntu-16-04-2
[16:23] <zyga_> kyrofa: looing
[16:24] <zyga_> well, DNS
[16:24] <zyga_> no idea why
[16:25] <kyrofa> That error is... awful
[16:25] <cachio_> mvo, the env cleanup PR passing
[16:26] <zyga_> kyrofa: yes, chipaca opened a thread about this already
[16:27] <zyga_> https://forum.snapcraft.io/t/network-ish-error-messages/862
[16:27] <zyga_> kyrofa: here ^
[16:33] <jdstrand> zyga_: probably a bit later today, if not first thing tomorrow
[16:45] <mvo> stgraber: thank you, what is the link to see the source of your test?
[17:37] <zyga_> niemeyer: the lock issue is unlocked: https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/19
[17:37] <zyga_> lazyPower: ^
[17:38] <lazyPower> zyga_: thats consistent with my findings
[17:38] <zyga_> lazyPower: can you explain why are you using lxd without apparmor?
[17:38] <zyga_> lazyPower: is this something that was recommended to you?
[17:38] <lazyPower> zyga_: namely because of flannel networking
[17:39] <zyga_> lazyPower: can you comment on the forum please, we can look for a solution together
[17:39] <zyga_> and I'm sorry it took so long to find
[17:39] <zyga_> niemeyer: my initial hunch was right (wrong profile) but the origin of the profile is very very unexpected
[17:40] <lazyPower> zyga_: certainly let me wrap up what i'm working on and i'll context switch back over to lend some detail
[17:40] <niemeyer> \o/
[17:41] <zyga_> lazyPower: thank you!
[17:57] <zyga_> JamieBennett: hey
[18:07] <Shannon_> might not be the best channel, but I'm trying to put snaps into a docker contrainer, and I'm having some problems.
[18:08] <lazyPower> zyga_: ok i hope that helps. i looped in some additional names on that thread to cover their specific domains if you have any questions about them specifically that i didn't answer in the generalized response.
[18:09] <zyga_> lazyPower: I saw, I already replied to your question
[18:09] <lazyPower> +1 understood
[18:09] <zyga_> lazyPower: I think we need to look at our options but I don't have a good idea of how to make it nice
[18:09] <zyga_> lazyPower: apart from disabling confinement for snap-confine on the host as well
[18:09] <lazyPower> yeah, i just want to make sure we aren't opening pandoras box in terms of both security and usability
[18:10] <lazyPower> i'm good at that for whatever reason, opening cans of worms i never intended to open.
[18:16]  * zyga_ calls it a dat
[18:16] <zyga_> day*
[19:01] <mup> PR snapcraft#1355 closed: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
[19:21] <cachio_> niemeyer, there?
[20:50] <nacc> so I just tried to update my classic snap to build on zesty 17.04 and got the following error https://launchpadlibrarian.net/322816537/buildlog_snap_ubuntu_zesty_amd64_git-ubuntu_BUILDING.txt.gz
[20:50] <nacc> specifically: W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu zesty InRelease: The following signatures couldn't be verified...
[21:25] <mup> PR snapcraft#1356 opened: common: find data files via sys.prefix <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1356>
[22:25] <sdrobertw> kyrofa: I still have that summary blog in the pipeline, been super busy. Maybe 1-2 more weeks please :) I will keep you posted once it is ready.
[22:26] <sdrobertw> kyrofa: have not forgot about it...
[23:29] <mup> PR # closed: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
[23:29] <mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
[23:32] <mup> PR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[23:35] <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>
[23:38] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[23:38] <mup> PR core-build#13 opened: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[23:38] <mup> PR # opened: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
[23:38] <mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
[23:38] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[23:38] <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>
[23:39] <mup> PR # opened: snapcraft#1183, snapcraft#1258, snapcraft#1277, snapcraft#1291, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1314, snapcraft#1316, snapcraft#1318, snapcraft#1331, snapcraft#1332, snapcraft#1335, snapcraft#1337, snapcraft#1340, snapcraft#1342, snapcraft#1343,
[23:39] <mup> snapcraft#1345, snapcraft#1346, snapcraft#1348, snapcraft#1349, snapcraft#1350, snapcraft#1352, snapcraft#1354, snapcraft#1356