[00:12] PR snapcraft#1354 opened: catkin plugin: fix pythonpath for catkin_find [02:51] PR snapcraft#1353 closed: cli: default options for the implicit snap command [03:51] PR snapcraft#1355 opened: go plugin: filter the main packages go-packages are defined [07:10] mvo: ping [07:11] morphis: pong [07:11] mvo: how was the long weekend? :-) [07:12] morphis: very nice, thank you! for you as well? [07:12] mvo: yeah, happily quite sunny yesterday so a great end :-) [07:13] mvo: one quick question for you: should we ship the snap-repair systemd units on classic systems? [07:15] morphis: we don't need to, its disabled there anyway [07:15] mvo: good! [07:15] morphis: so far we use the same debs to build classic and core this is why they are included currently [07:15] yeah, guesses that already but let me exclude these units for other distros then [07:15] doesn't make much sense to have them installed there [07:16] morphis: +1 [07:16] hi guy i need to use ssh-pass and i need to access /dev/tty : is serial-port the right interface? [07:17] 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] thanks morphis [07:18] mvo: thanks [07:18] mvo: can you merge https://github.com/snapcore/snapd/pull/3427 ? [07:18] PR snapd#3427: interfaces/builtin: silence ptrace denial for network-manager [07:19] morphis: looking [07:19] morphis: thank you [07:19] PR snapd#3427 closed: interfaces/builtin: silence ptrace denial for network-manager [07:21] mvo: good morning! [07:21] hey zyga_! [07:21] mvo: lots has happened since Friday :-) [07:22] zyga: morphis! [07:22] mvo: thanks [07:22] hey hey :-) [07:22] zyga_: oh? tell me more? I'm slowly catching up (reading forum etc) [07:23] mvo: mainly we know how to reproduce the error from last week [07:23] mvo: looks like apparmor/lxd bug, still working on it (just got to the office) [07:23] 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] zyga_: awesome! [07:24] morphis: I wonder if we could do arch (after suse) CI next [07:24] zyga: why not, but lets land suse/fedora first :-) [07:24] zyga_: aha, thanks, the arch bug was a bit of a drive-by-comment. so the lock-error happens inside lxd? [07:24] zyga: I have mint on my list too [07:24] Hello dear community .... I need help regarding snapcraft of a python app [07:25] please help me [07:25] mvo: not sure yet but what it looks like is that apparmor profile from the host confines the guest [07:26] kunal: best is if you post your specific question on https://forum.snapcraft.io [07:26] zyga_: great, thanks a lot for chasing this further. out of curiosity, how did you find this out? [07:27] mvo: it was reported on the forum actually [07:27] zyga_: sweet [07:27] mvo: so all the credits go to the reporter :) [07:27] * mvo takes a short tea break [07:27] zyga: why are you asking about ARch? anything specific? [07:27] 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] morphis: to run spread tests on it [07:28] morphis: even in nightly mode if we can [07:28] sure, but is there anything which brought this up or just in general? [07:28] morphis: ah, I wonder if the error reported on the forum is pointing out something deeper that's broken there [07:28] zyga: ? [07:28] 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] why doesn't snap download the python modules from main repository. [07:31] morphis: I mean this one https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884 [07:32] kunal: hey, what did you expect to happen and how did you express this in your snapcraft yam? [07:32] yaml* [07:32] 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] kunal: that hardly depends on how you structure your snapcraft.yaml [07:33] kunal: apt is available through "stage packages" [07:33] kunal: why do you prefer apt over python package index? [07:34] 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] kunal: I think you should open a question on the forum, include the error message and relevant parts of your snapcraft.yaml [07:36] 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] zyga: did you finish the changes for snap-confine we talked about last week? [07:37] morphis: almost, I ended up finishing something I already got a review of [07:37] morphis: (which grew slightly so took whole day) [07:37] morphis: I finished making the structural changes but I need to comment on everything heavily to guide the reviewers [07:38] morphis: though on the bright side almost all changes are in snap-confine.c so it's not a revolution [07:38] zyga: ok [07:44] 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] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [07:46] and the PR is now pending for nearly 1,5 months [07:56] * zyga_ sees re-exec disabled by user again [07:57] zyga: Linode has an prebuilt Arch image so shouldn't be much work [08:01] morphis: i tell you wrong device : i need to use a pty device from my snap: actually is it possible ? [08:05] NicolinoCuralli: each snap gets private ptys [08:07] zyga: i have an error as this : debug1: read_passphrase: can't open /dev/tty: No such device or address [08:08] it seems as if the command can't access the device === chihchun_afk is now known as chihchun [08:21] zyga: some hint on the problem? [08:22] I don't think you can open /dev/tty [08:22] * zyga looks [08:22] yep [08:22] it's not allowed [08:24] zyga: neither enabling a new interface? [08:28] NicolinoCuralli: a new interface could allow it but I think it is disallowed for a reason now [08:28] 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] 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] fgimenez: is there any specific reason why you're using -q for nc in the networking spread tests for snapd? [08:46] morphis: iirc it was meant to limit the time the test waits, let me check [08:46] fgimenez: as -q is not really portable across distributions [08:48] morphis: feel free to tweak it as needed, maybe we can do the same with another portable option, perhaps -w? [08:48] maybe [08:48] let me play with that [08:57] 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] 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] PR snapd#3430: tests: modify core before calling set [09:17] ok [09:18] hmm [09:18] not sure what to say [09:20] fgimenez: what think is missing is snap-confine's /snap sharing [09:20] fgimenez: is this done before snap-confine gets a chance to run? [09:20] fgimenez, ls /var/lib/snapd/snaps/core_*.snap will explode if there are more than one core snap (for whatever reason) [09:22] 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] 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] :) [09:25] zyga: it is done also with the daemon stopped, not sure if that matters [09:25] fgimenez: is this easy to reproduce? [09:25] fgimenez: it should not matter [09:25] zyga: yep, from the branch seems to be very consistent [09:25] fgimenez: I'm happy to take a look after exploring the juju/lxd issue [09:26] zyga: great, thank you [09:44] morphis: maybe I'm misreading but in snapd#3222 it seems you did exactly the opposite of what Gustavo asked [09:44] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [09:47] 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] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [09:48] pedronis: thanks, yeah I need his review again [09:48] pedronis: there are two different parts [09:48] there is CoreLibExecDir which never has a prefix [09:49] and in all others cases I am using dirs.StripRootDir like in https://github.com/snapcore/snapd/pull/3222/files#diff-6dd6f3a48b395a14870975240679b8cdR86 [09:49] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [10:00] * zyga experiments with juju and has his head spinning [10:00] I think this is the perfect time for a coffee [10:01] haha [10:07] hey tai271828_ :) [10:07] * zyga looks at juju output and waits for more things to install [10:07] \o zyga did you get your coffee [10:14] PR snapd#3434 opened: tests: add staging snap-id [10:16] 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] tai271828_: yes I did [10:16] PR core#35 closed: move xdg-open to proper paths [10:16] if someone could have a second look at https://github.com/snapcore/core/pull/48 that would be great [10:16] PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` [10:17] fgimenez: you need to change the python in that test as well [10:18] pedronis: aha! thx on it [10:18] fgimenez: sorry, not the python [10:19] fgimenez: but the yaml has this: environment: [10:19] TEST_SNAP_ID: aLcJorEJZgJNUGL2GMb3WR9SoVyHUNAd [10:19] pedronis: that should be addressed with the changes in snapd#3434 [10:19] PR snapd#3434: tests: add staging snap-id [10:20] pedronis: hmm i see a typo in there, let me fix it [10:22] \o [10:22] * Chipaca appears in a cloud of post-physio exhaustion === chihchun is now known as chihchun_afk [10:25] clouds are the future i heard [10:25] unless it rains [10:27] I think people who used to gravitate towards torturer and executioner roles in the past now just pick up physio [10:28] "you'll feel a little stretch" [10:28] "you will fell a little sting" [10:30] pedronis: works fine now, sorry for the noise [10:43] 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] Hi [10:43] I do. [10:43] Skype for Linux [10:44] flexiondotorg: skype for linux beta or the one that was de-comissioned just now/ [10:44] flexiondotorg: great, where can I find the snapcraft.yaml to add the right ifcace for testing? [10:44] The new Electron version. [10:44] PR snapd#3435 opened: interfaces: add password-manager-service implicit interface [10:44] ANd also Nylas Mail (the newer open source version), also Electron. [10:45] 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] mvo I'll just make sure both yamls are current. [10:45] Give me a few mins... [10:46] 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] ogra: snapd pulls it in [10:52] ogra: we have systemd on 14.04 but it is a special build [10:52] and that is a fully working systemd (providing logging ) [10:52] i thought that was just a stub [10:52] ogra: oh, journald is there? [10:52] I thought journald did not work [10:52] nice :) [10:52] zyga, thats what i mean [10:53] how can https://github.com/snapcore/snapd/pull/3432 actually work on a 14.04 [10:53] PR snapd#3432: tests: clean journalctl logs on trusty [10:53] where we have no fully working systemd [10:53] (and thus no journald) [10:54] tvoss, is the 14.04 systemd thing actually starting a journald ?? [10:54] (iirc you worked on that) [10:59] ogra: I doubt that [11:02] morphis, hmm, curious ... why is that needed then ... [11:02] not sure [11:09] lazyPower: hey, I'm trying to reproduce the issue we spoke of yesterday [11:09] lazyPower: how long should conjure-up be doing its thing? [11:10] lazyPower: I'm currently seeing "waiting for applicationto start" [11:10] lazyPower: juju status spews a lot of output, some things being active, some in maintenance [11:10] lazyPower: (it all means nothing to me unfortunately) [11:13] hmm, actually, I think it is making progress [11:18] 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] mvo: btw we need two more test snaps in prod undere the shared account, i'll ping you later about this [11:21] wow, someone still uses snappy-hub ?!? [11:25] all our test snaps are built under it I think [11:26] test snaps, as used by spread tests [11:28] ah ... interesting [11:28] i thogught even that was moved to GH [11:28] lazyPower: almost all apps are active now, I see that kubernetes-master is still "waiting" [11:29] lazyPower: with a message "waiting for kube-system podto start" === koza|away is now known as koza [11:29] lazyPower: still looks OK-ish [11:30] lazyPower: I did start with snapd 2.25 as that's what I got after update from 2.0.10 [11:30] lazyPower: I'll let this finish and try again with manually started 2.21 [11:30] 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] lazyPower: in the end it failed with "step requires paswordless sudo" [11:32] and a python backtrace [11:34] in the end I can see a few denials that are not caused by snapctl [11:34] let me add this to the forum [11:35] 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] morphis: in which context? [11:38] 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] morphis: well generic image will have a generic model [11:38] something doesn't compute there [11:39] generic in which sense? [11:39] 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] so we have an image generic for a brand [11:44] morphis: in principle atm yes, device registration is retried [11:44] ok [11:49] zyga: thats an unrelated thing, conjure-up is trying to fetch snap packages required to maintain the application [11:50] 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] sounds like a re-exec vs non-rexec issue [11:52] lazyPower: aha, I see [11:52] lazyPower: I'll do another pass now, using 2.21 on the host [11:52] lazyPower: I think the bug is still there, it is just masked by 2.25 on the host [11:53] masked huh :) [11:54] fgimenez: sounds good, thank you [11:59] 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] iliv, well, that will also be the message when you snap install and such [12:00] 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] iliv, it should also say that you can "snap login" instead of using only sudo ... [12:01] iliv, yes, an unprivileged user that used snap login before [12:01] hm [12:02] i dont think we support actual per-user aliases yet ... ( pedronis may correct me) which wouldnt need snap login or sudo [12:03] aliases are global [12:04] pedronis, which user manages them? root? [12:05] snapd so root [12:05] iliv: anyway when 2.25/2.26 come out that blog post is not valid anymore [12:06] ogra, after issuing snap login I was able to "snap alias" as an unprivilged user [12:06] things work differently [12:06] iliv, yeah :) [12:06] pedronis, I hope you guys will update it then [12:06] pedronis, btw I run 2.25 [12:06] davidcalle: hi, did you see my ping in the foru about that btw ? [12:06] for both snap and snapd [12:07] iliv: then you need to read: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/33 [12:07] * zyga -> lunch [12:08] pedronis: I don't think I did :/ [12:08] davidcalle: we need a new post or to update the old one about aliases once 2.26 is on stable [12:09] given that things have changed [12:11] 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] iliv: good point [12:12] pedronis: what's the eta on this? Two weeks? [12:14] davidcalle: don't know, mvo what's the eta on 2.6.4 going stable ? [12:20] davidcalle: I think this is in the hands of fgimenez now [12:23] 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] 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] fgimenez: excellent ! thank you === JamieBen_ is now known as JamieBennett [12:28] 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] here's my terminal history that illustrates this problem: https://dpaste.de/62Vk/raw [12:28] PR snapd#3434 closed: tests: add staging snap-id [12:29] oh, I see [12:30] I needed to relogin [12:30] that's weird anyway === cpaelzer_ is now known as cpaelzer [12:30] once I exited and relogined psql started to resolve to /snap/bin/psql [12:31] 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] ogra, pedronis davidcalle [12:34] iliv, did you have a deb installed before ? [12:34] correct [12:34] sounds more like bash is caching something to me then [12:34] (not really like a snap issue) [12:35] right [12:35] I have just been ables to reproduce it the other way around [12:35] i.e. install snap package first, then deb [12:35] same issue [12:35] 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] I guess a shell logout/reinitialization is required after all [12:36] (to prove it isnt actually snap related) [12:36] mhm [12:58] davidcalle: so sounds a bit less thant 2 weeks in the good, more like this one or the next [12:59] pedronis: sounds good, thanks. I'll be in the snapcraftio sprint this week, I'll make it part of it [12:59] thank you [12:59] let me know if you have questions [13:00] +1 [13:16] mvo: https://github.com/snapcore/snapd/pull/3370 [13:16] PR snapd#3370: many: derive implicit slots from interface meta-data [13:17] mvo: that's the implicit pr, if this lands your pr won't have to change implicit anymore [13:17] mvo: and the last thing will be the base declaration [13:22] I cannot reconnect to the call [13:23] I cannot re-connect [13:33] fgimenez: hey [13:33] fgimenez: I have one more idea about the 14.04 issue with mounted core [13:33] fgimenez: I think /etc/mtab is a file, not a symlink to /proc/mtab [13:33] fgimenez: and this is causing this issue [13:34] fgimenez: if I'm right we may have to ensure we always keep those two in sync [13:36] 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] zyga_: and the original error messaage refers to mtab http://paste.ubuntu.com/24791901/ [13:36] 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] mvo: shouldn't the tests/main/snap-repair spread test case be ubuntu-core-* specific? [13:38] 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] 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] 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] zyga_: the only difference is the call to snap-discard-ns core afaik [13:40] without it 14.04 doesn't give this error [13:42] morphis: yes, it should be [13:43] mvo: ok, will mark it as such [13:43] 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] noise][: who deals with setting up aliases? [13:48] jdstrand mostly [13:48] 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] that won't do :-( [13:48] Chipaca: hence me coming to bug people about it :) [13:49] icey: yeah [13:49] icey: thanks! [13:49] so my question is, what do we do to avoid this from happening again [13:49] 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] Chipaca: I mentioned this once before but I really really think this should always be a bug on the snappy store project [13:49] s/shoudl/should [13:49] https://launchpad.net/snapstore [13:50] zyga: i don't think that's the right place since my team doesn't handle those approvals [13:50] noise][: what do you suggest then? [13:51] right, if it's jdstrand, we need to bug him :-) [13:51] mup: pester jdstrand until morale improves! [13:51] Chipaca: I apologize. I'm a program with a limited vocabulary. [13:51] need to chat w/jdstrand [13:52] 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] the prob with the forum discussions is that they vanish over time [13:53] (not physically but they simply scroll off the overview eventually) [13:53] noise][: maybe we just need both [13:53] some kind of remonder system would be nice there [13:53] noise][: file a bug and open a forum thread [13:53] 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] *reminder [13:53] mvo: hey, I read your new interface PR [13:54] mvo: I have two comments/suggestion [13:54] people can bookmark things in the forum fwiw [13:54] zyga: excellent, I check them out [13:54] mvo: one is that you need to tweak tests to pass on fedora and other non-deb systems [13:54] icey, et al, let me look [13:54] mvo: ah, I didn't send them there :) [13:54] zyga: indeed [13:54] zyga: aha, ok :) [13:54] mvo: and the other one, which is just a suggestion, is to perhaps open a forum thread and document the interface there [13:55] 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] zyga: nice, I will do that [13:56] 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] PR snapd#3370: many: derive implicit slots from interface meta-data [13:57] 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] Chipaca: I'm good at finding those cracks apparently :-P [13:57] zyga: thanks, I check that branch out now too [13:57] 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] mvo: thank you! note that those are just suggestions (the docs at least) [13:58] mvo: so don't feel blocked by this [13:58] 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] 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] Chipaca: the circling around bit did slip through so thank you for the reminder [14:00] Chipaca: limbo can be relaxcing too ;-) [14:00] icey: as mentioning in the forum, sorry for the delay [14:01] menioned* [14:01] meh [14:01] no worries jdstrand, partially on me too for not following up [14:01] mentioned* [14:01] i really think remindesr should be a forum feature ... [14:01] reminders [14:10] Heya [14:11] For the requests queue, we already have a check mark we use when the request is handled [14:11] What's missing is a proper view that lists only such requests so it's obvious what's pending [14:11] I think either a category or a tag will do [14:12]